Tuscany Samples

isn't <java.interface /> mandatory for a <service />?
- removed the line and ran the test case and it passed
- SL - No, if you remove the interface.java element the runtime will derive the interface by looking at the service implementation
<tuscany:binding.rmi uri="rmi://localhost:8099/CalculatorRMIService"/>
- what does the uri attribute mean?
- is it the uri where the service can be found? from what i understood tuscany will also deploy the service and make it available, what if the host is not localhost?
- SL - you can use the uri to configure the binding to create the RMI endpoint at a certain address. If you omit it Tuscany should create a default endpoint address

what is enabling the loading of the .composite files? don't see any scaDomain...
SL - In some of the samples (the ones based on the calculator scenario) we've separate the contribution module from the launcher module. In normal circumstances this is reslistic as people will develop contributions and then deploy them to a runtime. In the sample case there are a number of different launchers that start the Tuscany runtime in different ways and all should be able to run all of the contributions although there are some restrictions at the moment.

what would be the differences between <binding.ws /> inside <service/> and inside <reference />
- SL - the binding inside the service confiures the protocol over which a component service is exposed. The binding inside the reference configures the protocol over which a component access a service provided elsewhere.
is the one in <service> exposing the webservice and the one in <reference> specifying where the reference can be found?
- SL - yes
what triggers the webservice to be deployed?
- SL - deploying the contribution to the Tuscany runtime.

what are the differences between this sample and sample-contribution-binding-sca-calculator?
- SL - at the moment there is no difference but you have probably noticed that we have started grouping the samples in directories that describe which SCA feature the sample is specifically demonstrating. It just so happens that this contribution uses implementation.java

<listener><listener-class>org.apache.tuscany.sca.host.webapp.TuscanyContextListener</listener-class></listener>
- is this loading the tuscany runtime?

how is the domain injected on the client side (web page)? i see the calls are made directly from the html/jsp page, how is the page aware of the services it can call? it just receives a list of the services and their metods, or what is the format? i'm referring to things like:
- componentContext.getService("service").sayHello(document.getElementById('name').value, sayHelloResponse); in javascript
- <sca:reference name="service" type="sample.HelloworldService" /> in JSP

how is implementation.spring working? only the spring file is specified, what if there were multiple beans inside?
could there be the bean instantiation done with spring and only the wiring with tuscany?

how did var catalog = new tuscany.sca.Reference("catalog"); get imported?
in store.composite why does implementation.widget need binding.http but a servlet or jsp hasn't binding.http specified?
isn't this desktop application? Running Launch.java starts a Jetty server...

ran mvn jetty:run, opened _http://localhost:8080/sample-store-webapp/_ and i'm getting "TypeError: Cannot call method 'get' of undefined"

how is tuscany runtime loaded in tomcat when deploying a war for instance. to be more specific, how is tomcat made aware of tuscany nature of the project?
- SL - If you choose the package the Tuscany runtime inside the WAR then there is a Tuscany filter that's configured in the web.xml file. There is also some deeper Tuscany integration in which case the Tomcat runtime itself is updated to understand Tuscany contributions in which case you don't need to package the Tuscany runtime inside the contribution war