Hi, Is the definitions.xml (sec 1.8, line 2490 of Assembly spec) a good place to define the domain uri for various schemes for an SCA Domain.
- Venkat On 7/28/07, Simon Laws <[EMAIL PROTECTED]> wrote: > On 7/28/07, Simon Laws <[EMAIL PROTECTED]> wrote: > > > > > > > > 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] > > > > > > > > I forgot to say that, for completeness, we should extend the cardinality a > little to be accurate for the distributed case. > > 1 Domain -> n Nodes -> 1 base URI per protocol used in the node/domain. > (see [1]) > > So the logical domain will have n base URIs per protocol. This doesn't > affect the change you are proposing immediately (the cardinality you give is > true of the part of the domain that is at each node) but I wanted to extend > this to distributed domains. > > Simon > > [1] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Terminology > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
