On 7/28/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > > [snip] > ant elder wrote: > >> 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. > > > > > [snip] > > Ok I'll get started on that. > > >>>> 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? > > > > If we're talking about a domain URI, this is typically model information > that can be hosted in a Top level Composite or Domain Composite or > Domain model object, whatever we want to call it. If I understand the > spec correctly, the cardinality is: 1 Domain -> 1 base URI per protocol > used in the domain. The ExtensionPointRegistry is associated with a > Runtime instance, not tied to a Domain. I'll propose a new model object > to host that domain-wide configuration.
Sounds good to me. I'm assuming when you say runtime instance here you mean something like, ReallySmallRuntime. Can you say if you have in your mind some specific scenarios that leverage the difference between the domain model and runtime as they exist in the code at the moment, for example, by starting more than one runtime for a domain model. I'm happy if the answer is "not at the moment" and that it is just good architecture practice to separate these clearly distinct parts of the solution. [snip] > > > >> 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)? > > > > > Right, we have multiple options for HTTP hosts so it's interesting to > report which one is used. > > It looks like we have only one implementation for RMI or JMS at this > point. So I was not thinking about spending time reporting which one is > used right now... I'll be happy to spend time sorting out which one is > used when we get to a point where we have multiple implementations for > these. > > >>> 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? > > > > Sure! Where is it? The scenario I'm most interested in is running > Tuscany outside of a Web container, so I'd like to see if I can use and > add to what you have started in that environment. distribution/webapp/src/main/webapp/scaDomainInfo.jsp -- > Jean-Sebastien > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
