On 7/26/07, Simon Laws <[EMAIL PROTECTED]> wrote:
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.
All those sound good, and just to add one more, i think there's a bug (unless its been fixed recently) in the standalone jetty/tomcat runtimes so that the port in a endpoint url is used but only for the first endpoint. So if you have two binding uri's http://localhost:8080/foo and http://localhost:8085/bar then both services are exposed on the same one port and its just whichever port happened to get processed first. 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?
Thats the way it works right now yes. Its like for example Axis2 or DWR which have ready to run WAR distributions that you just download and deploy and they have some sample applications in the repository (sca-contributions folder) and users just add their own to that. Or we could do something else, maybe have a maven archetype so its easy to create an application maven project for sca webapps. ...ant
