[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.
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.
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?
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.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
