Hi Ant, Working with the policy framework, the definitions.xml is the file that lists all the intents and policysets that are applicable for an SCA Domain. The Policy Fwk specs talks quite a bit about the contents of this file - such as things like the BindingType, ImplementationType etc.
As for having these in the SPI, I have started off with some abstractions for these in https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/policy/src/main/java/org/apache/tuscany/sca/policy as part of the PolicyFramework things which is still work in progress. Once I have some thing substantial we could work on moving some things as SPI. Having looked at definitions.xml before, it just about rung a bell in the context of this discussion. Not sure if the specs folks are going to like this proposition ;-) - Venkat On 7/30/07, ant elder <[EMAIL PROTECTED]> wrote: > 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] > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
