Thats pretty interesting. Though there's so little detail about definitions.xml I find it hard to work out what its for, could any spec people give a be more detail about this?
One thing it talks about is using bindingType and implementationType elements to add new extensions, should we really be using these as part of the extension SPI? ...ant On 7/29/07, Venkata Krishnan <[EMAIL PROTECTED]> wrote: > > 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] > >
