On 7/26/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > > [snip] > ant elder wrote: > > On 7/26/07, Simon Laws <[EMAIL PROTECTED]> wrote: > >> > >> 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 > > +1 to print the URIs of the endpoints of the services activated by > Tuscany. > > >> > >> 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? > >> > > I think that these URIs should be determined as part of the process of > combining wires and uris specified at different levels in the SCA > assembly. If the correct URIs are determined once as part of this > process, a binding provider should be able to just call > binding.getURI(), without having to calculate it at all, on its own or > even calling a central URI calculator method.
Agreed. Something like this would be a vast improvement. And its the best way to make sure it works consistently across all binding extensions. >> > >> 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. > > I'm not quite getting this part... the extension point registry is > well... a registry for extension points, an extension point contains > extensions (multiple extensions), I can't quite see how a URI calculator > utility is an extension point. I'm guessing this is just being used as a way to pass base uri infomation around as to date we don't really have a way to handle system config data. Whats an alterantive to using this registry? >> > >> We should try and catch the case where an absolute URL is specified > that > >> doesn't match the result of the "URI Calculator". > > +1 > > >> > >> 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. > >> > > I guess it should be sufficient to report if we run in Jetty or Tomcat, > right? And there's webapp's or the hotupdate webapp, and doesn't this also include non http things like rmi host (and jms host if we ever get one of those)? > > > 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. > > Yes, I've bumped into this one several times too... so I'd like to > volunteer to fix it. > > It looks like adding prints is under way too. > > In addition I'd like to do the following. When Tuscany starts, make a > Web Page available with its status, http://localhost:9090 for example, > and on that page say Hello Tuscany has started or something like that, > plus: > 1. display the top level components started > 2. display the services available and their endpoints > 3. display the extensions loaded in the runtime > > I'll probably do 1 and 2 first, leaving 3 for later, depending on how > useful people think it is. > > If there's no objection, I'd like to add this sometime before the end of > the week. There's already a start of exactly this distribution/webapp which i'd planned to develop further, would you help? ...ant
