Ant, you beat me too it;-) Having spent time yesterday trying to figure out how URLs are handled with the web app host I feel the pain. Some comments inline
Simon On 7/26/07, ant elder <[EMAIL PROTECTED]> wrote:
This is becoming one of the most often asked about and (i think) one of the most confusing parts of using Tuscany, so how about we try to fix things up a bit? One problem is its just really hard to see where servlets get registered. These days I often run with a local mod to servlet host that just does a System.out.println of each servlet registration. Maybe I should just commit that for now and we can delete it when we have some logging strategy in place?
+1 - I use a registry inspector component that I shove into the SCDL I'm testing but it's more complicated to use that just having the printout in place Another problem is all our bindings work differently. So <binding.ws/>, <
binding.rmi/> <binding.jms/> <binding.jsonrpc/> etc all result in a service being available at a different endpoint. Also the uri attribute on those bindings all work differently so uri="foo" for some bindings would be treated as relative uri, for others an absolute one. What we need is a bit of code that implements section 1.7.2.1 of the assembly spec which all bindings then use. (a generic version of Axis2ServiceProvider.computeActualURI). Didn't this come up once before and something was changing in the runtime binding for this?
And we need some configuration that describes the base URIs for each domain. The base URI information is part of the topology description but it doesn't get used yet so we need to get it into the SCADomain. It should be configuratin of the "URI calculator" which could be in the extension registry so that all bindings can get at it. We should try and catch the case where an absolute URL is specified that doesn't match the result of the "URI Calculator". We should report is what extension is hosting each protocol. As we have multiple options in some cases this can be confusing if you have your classpath wrong. Another problem is the runtime base uri is changing for our different
environments, for example the standalone Jetty runtime has an empty base uri, where as the sample webapp ones have things like /services/ or other samples /SCA/. That is user configurable in the web.xml, but how about at least in all our samples we change that to be consistent?
+1 to sample consistency. Re. the base uri. The least we can do is report which base uris are in operation for each binding/environment. A confusion for me is knowing which of the many pieces of information that can be specified wins. Again if we trap the case where what is specified doesn't match what the runtime calculates the uri should be then that would be a great help. Another kind of related problem is the way we require sca application
developers to know the intimate details of the structure of the Tuscany build - you want to use web services you must add a <dependency> for tuscany-binding-ws-axis2, if using Java components then you need to add tuscany-implementation-java-runtime, etc for all the other things you may want to use. We got the J2SE samples so you don't need to know any of that, i think we could do the same for webapps. For example one way would be like the distribution/webapp module strawman we have. That enables sca applications to require no dependencies at all on any tuscany modules, you just build your application jar using only things related to your application and drop it into the webapp sca-contributions folder and it just works. Would that be a better approach than what we do today for webapps?
Not sure yet. What's the mode of operation with the distribution/webapp module? You deploy a distribution/webapp war and then deploy application jars to the sca-contributions folder? ...ant
---------- Forwarded message ---------- From: ant elder <[EMAIL PROTECTED]> Date: Jul 26, 2007 9:59 AM Subject: Re: Services and WSDL files To: [EMAIL PROTECTED] On 7/26/07, Simon Laws <[EMAIL PROTECTED]> wrote: > > On 7/26/07, Radim Kolarik <[EMAIL PROTECTED] > wrote: > > > > Hi Reymond, > > > > Thank you for your reply. > > > > How do I run the example if it is deployed to a web server, such as > > Tomcat? I found an information about TuscanyServlet, which needs to be > > in web.xml file, which I have now. > > > > Let's say that my server's root context and web app context URL is > > http://localhost:8080/myWebApp . What do I have to add after this URL > > to be able to access the application? According to SCA spec, the web > > service WSDL should be available if the URL ends with ?wsdl. But if I > > type http://localhost:8080/myWebApp/?wsdl in the browser, I get an > > exception: > > > > SEVERE: Servlet.service() for servlet TuscanyServlet threw exception > > java.lang.IllegalStateException: No servlet registered for path: / > > at org.apache.tuscany.sca.webapp.TuscanyServlet.service( > > TuscanyServlet.java:57) > > at > > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter ( > > ApplicationFilterChain.java:290) > > at org.apache.catalina.core.ApplicationFilterChain.doFilter( > > ApplicationFilterChain.java:206) > > at org.apache.catalina.core.StandardWrapperValve.invoke ( > > StandardWrapperValve.java:230) > > at org.apache.catalina.core.StandardContextValve.invoke( > > StandardContextValve.java:175) > > at org.apache.catalina.core.StandardHostValve.invoke ( > > StandardHostValve.java:128) > > at org.apache.catalina.valves.ErrorReportValve.invoke( > > ErrorReportValve.java:104) > > at org.apache.catalina.core.StandardEngineValve.invoke( > > StandardEngineValve.java:109) > > at org.apache.catalina.connector.CoyoteAdapter.service( > > CoyoteAdapter.java:261) > > at org.apache.coyote.http11.Http11Processor.process( > > Http11Processor.java :844) > > at > > org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process( > > Http11Protocol.java:581) > > at org.apache.tomcat.util.net.JIoEndpoint$Worker.run( > > JIoEndpoint.java :447) > > at java.lang.Thread.run(Thread.java:595) > > > > I did some debugging on this and it seems that the servlet tries to > > obtain a mapping from a Map, which is empty. Is this a bug or am I > > just missing something in my .composite file or WSDL? > > > > Also, did you create the WSDL file manually or did you use any > > generation tool provided by Tuscany? > > > > Thanks, > > Radim > > > > On 7/25/07, Raymond Feng <[EMAIL PROTECTED]> wrote: > > > Hi, Radim. > > > > > > I'm not very sure if we already have the support to deploy an SCA > > service as > > > a web service without WSDL. If not, that's something we want to > support > > for > > > sure. > > > > > > We have a sample to demonstrate the usage of SCA, web service and SDO. > > > It > > > seems to be what you are looking for. You can see the sample code at: > > > > > > https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/helloworld-ws-sdo > > > > > > > > > Thanks, > > > Raymond > > > > > > ----- Original Message ----- > > > From: "Radim Kolarik" < [EMAIL PROTECTED] > > > > To: < [EMAIL PROTECTED]> > > > Sent: Wednesday, July 25, 2007 7:38 AM > > > Subject: Services and WSDL files > > > > > > > > > > Hi, > > > > > > > > Is it necessary to supply wsdl file if I want to deploy an SCA > service > > as > > > > a > > > > web service? Or can Tuscany generate the file "on the fly"? > > > > > > > > If I need to supply the file myself, what would be the best way to > > > > generate > > > > the file? Is it possible to generate the file for SDOs, if they are > > > > service > > > > parameters or if a service returns an SDO object as its result? > > > > > > > > Thanks, > > > > Radim > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > Hi Radim > > Someone else is asking a similar question [1]. As part of this I made a > sample [2] to experiment with exposing web services through the web app > container. There are a few wrinkles in getting this to work. To make it > work > I hand created WSDL conatining a service URL that matched where I knew the > > service was going to be deployed. For example. > > In the sample [2] the URL that is registered with the web app relates to > the > single service that is described in the .composite file [3] > > <component name="AddServiceComponent"> > <implementation.java class="calculator.AddServiceImpl"/> > <service name="AddService"> > <interface.java interface="calculator.AddService" /> > <binding.ws > wsdlElement="http://calculator#wsdl.port(AddService/AddSoapPort)< http://calculator#wsdl.port%28AddService/AddSoapPort%29> > < http://calculator/#wsdl.port%28AddService/AddSoapPort%29>"/> > </service> > </component> > > And, in this case, takes its value from the WSDL service description [3] > > <wsdl:service name="AddService"> > > <wsdl:port binding="tns:AddSoapBinding" name="AddSoapPort"> > > <wsdlsoap:address > location=" http://localhost:8080/sample-calculator-webapp-ws/services/AddService > "/> > </wsdl:port> > </wsdl:service> > > I.e, I see the value. > > http://localhost:8080/sample-calculator-webapp-ws/services/AddServiceregistered > in the WebAppServletHost > > The important thing here is that the URL I hand edited into the WSDL file > matches the URL that the web app is deployed at. In my case I'm deploying > the WAR to tomcat and it ends up at > http://localhost:8080/sample-calculator-webapp-ws > . The web.xml file maps "/services" to the TuscanyServlet so that appears > too and finally the name of the service. > > Now this all feels a little complicated to me, I.e Reading the spec I > would > expect just to be able to specify a service name and have the runtime > construct the URL automatically for me. In fact this is how I think the > TuscanyServlet is coded, in that it only looks for registered servlets > based > on path info, and what I think the assembly spec says. The problem is it > doesn't appear to be easy to configure the .composite file with just path > info and also keep axis happy. I've tried a few things, e.g. > > <binding.ws> > < binding.ws uri="..."> > > But Axis complains. So maybe someone (Raymond?) can tell us what the magic > > rune is to make this work but for the time being the code in trunk works > for > the sample. I have opened JIRA TUSCANY-1481 on this so we have a marker > but > it sounds like you are making some progress debugging so feel free to > attach notes if you feel it's appropriate. > > Regards > > Simon > > > [1] http://www.mail-archive.com/tuscany-user%40ws.apache.org/msg01434.html > > Note. There are a couple of mails missing off this thread that I didn't > send to the user list by accident. Just forwarded them now so hopefully > the > archive will catch up sortly > [2]http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/calculator-webapp-ws/ > > > [3]http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/calculator-webapp-ws/src/main/resources/Calculator.composite > [4]http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/calculator-webapp-ws/src/main/resources/wsdl/add.wsdl > > See: http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200707.mbox/browser and: http://incubator.apache.org/tuscany/sca-java-bindingws.html Basically, if you reference the WSDL port it will use that, otherwise the url is constructed from the component name, service name and binding URI. I find for services its easiest to just leave it all out eg ,< binding.ws/>, in which case the uri will be the [webappSerletUrl]/componentName/serviceName, and for references to explicitly use the uri attribute, eg <binding.ws uri=" http://somehost/someService"; /> ...ant
