Re: [XmlSchema] Pluggability for XSD import/include resolvers?
Hi, Raymond, We encountered the same problem when implementing SDO's XSDHelper. Where we used EMF's xsd tool package for resolve xsd. Wherein we just implemented our own XSDSchemaLocator and added it to the resource's adapters, then we can do everything in locating the import/include xsd. It works fine. I don't know if XmlSchema have any thing alike. - Original Message - From: "Mike Edwards" <[EMAIL PROTECTED]> To: Sent: Wednesday, July 25, 2007 9:33 PM Subject: Re: [XmlSchema] Pluggability for XSD import/include resolvers? > Raymond, > > How does this relate to the contribution resolution mechanism described > by the SCA specifications? > > Yours, Mike. > > Raymond Feng wrote: >> Hi, >> >> We currently use XmlSchema to load XSDs. To resolve the import/include >> directives using our schemes, we provide an implementation of >> org.apache.ws.commons.schema.resolver.URIResolver and set it to >> org.apache.ws.commons.schema.XmlSchemaCollection. It works well if the >> schemaLocation attribute for the or is set. >> >> Now we would like to handle the cases where the schemaLocation attribute >> is not present. For example, http://ns1"/>. >> Without the schemaLocation, we resolve the import/include by namespace. >> In this case, we already have a map keyed by namespace for a list of >> XmlSchema objects loaded from a catalog or other files and we want to >> reuse them. Would it be possible to open the >> XmlSchemaCollection.getSchema(SchemaKey) method so that we can >> override/customize the behavior to associate existing XmlSchema >> instances to a SchemaKey? BTW, using a singleton of XmlSchemaCollection >> to keep the schema map is not always feasible. >> >> Another observation is that a NPE will be thrown if the >> URIResolver.resolveEntity() returns null. Is there any way to disable >> the aggressive resolving/loading of import/include? >> >> [EMAIL PROTECTED] >> Raymond Feng >> Apache Tuscany >> >> - >> 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] >
Re: Resolving WSDL/XSD import/include for SCA contributions
Hi, Raymond: I also noticed the same problem when testing Tuscany two days ago. I'm not familiar with WSDL4j. When I looked into the codes, my fist response is replacing WSDLLocator, as you mentioned. While the ugly thing is that WSDLLocator return InputSource instead of some sort of placeholder/delegate. We rough thought is use some sort of lazy-import/include way to get around this problem(If you can't stop the aggressive resolveing, you cheat it). So you might want a dummy WSDLDefinition for return instead of implementing a dummy InputSource. You just record the location of the wsdl file in the read() phase, and resolve all the recorded wsdl files in the resolve() phase, then replace the dummies with the real ones. This can promise you to have the right InputSource. The last thing I want to do is implements your own WSDLFactory and WSDLReader by subclassing the default. What's more, SDO has its XSDHelper to parse all the xsd files to load all SDO types they need ( That is to say, some SDO implementation may registered their own XSDDocumentProcessor). So the Tuscany may need some kind of mechanism to allow delegating the resolving of namespace in wsdl to SDO's TypeHelper.(That is why I prefer the use of namespace to schemaLocation) Another problem we saw in WSDL in Tuscany is WSDLOperation. Where multiple output parts is not supported explicitly. Then what if some service return an array of objects as return? - Original Message - From: "Raymond Feng" <[EMAIL PROTECTED]> To: Sent: Wednesday, July 25, 2007 10:29 AM Subject: Re: Resolving WSDL/XSD import/include for SCA contributions > Hi, > > Please see my comments inline. > > Thanks, > Raymond > > - Original Message - > From: "Jean-Sebastien Delfino" <[EMAIL PROTECTED]> > To: > Sent: Tuesday, July 24, 2007 6:46 PM > Subject: Re: Resolving WSDL/XSD import/include for SCA contributions > > >> Two questions inline. >> >> >> Raymond Feng wrote: >>> Hi, >>> >>> I'm working on the artifact processing of WSDL/XSD from SCA >>> contributions, especially for the import/include directives. I would like >>> to share what I have so far to get your feedback. >>> >>> Let's assume we have the following artifacts ([1][2]). >>> >>> * helloworld-service.wsdl (definition) imports helloworld-interface.wsdl >>> * helloworld-interface.wsdl (inline schema) imports greeting.xsd >>> * greeting.xsd includes name.xsd >>> >>> For the import/include, we could have different ways to use the >>> "location" attribute for a WSDL . Please note the SCA spec says >>> the explicit location attribute should be honored. If it's not present, >>> then we use the namespace-based resolution defined by SCA. >>> >>> 1. location="helloworld-interface.wsdl" (relative to the base document >>> where the import is defined) >>> 2. location="/wsdl/helloworld-interface.wsdl" (relative to a SCA >>> contribution) >>> 3. location="http://example.com/helloworld-interface.wsdl"; (absolute URL >>> pointing to an external resource) >>> 4. location="" or location is not present: Use the namespace to resolve >>> the imported definition >> >> Is location="" even valid? I didn't think so. > > I have clarified this on the follow-up e-mail. The location attribute is > required for . "" doesn't seem to be a valid URI. > > The absence of schemaLocation for and are valid > though. > >> >>> >>> We have two options here: >>> >>> a) Plugin a tuscany-specific resolver for WSDL4J >>> (javax.wsdl.xml.WSDLLocator) and XmlSchema >>> (org.apache.ws.commons.schema.resolver.URIResolver). >>> >>> This option can handle location case 1, 2 and 3. For 2, we probably need >>> some context from the contribution service. >>> >>> The difficulty is that both resolvers expect to take an InputSource. For >>> location case 4 (empty or not present), we don't have a corresponding >>> InputSource. >> >> I was going to respond with a long list of pros-cons for both options, >> then deleted all my comments to ask a simple question :). Why can't we >> return an InputSource for the contents of the imported document? >> > > Well, for the import/include that can be resolved to a document, we return > the InputSource. I have said that it works for location case 1, 2 and 3. But > if the import/include only doesn't have the schemaLocation attribute, what > InputSource should we return? > > A related question, for an artifact processer that loads multiple artifacts > following the import/include directives, how can we avoid the duplicate > loading? For example, we have a.wsdl imports b.wsdl, both a.wsdl and b.wsdl > are in the same contribution and they are processed by the WSDL artifact > processor. We probably don't want to load b.wsdl twice in this case. > >>> To make WSDL4J happy, we might be able to provide a dummy InputSource >>> pointing to a byte array which contains the empty definition (AFAIK, null >>> InputSource won't work) and then resolve the imported definition by Q
Re: XSDDocumentProcessor visibility
+1. Maybe there's more modules intrested in the xsd. SDO's types are also defined in xsd files. Can multiple DocumentProcess register to the same doc type? - Original Message - From: "Venkata Krishnan" <[EMAIL PROTECTED]> To: Sent: Monday, July 23, 2007 1:38 AM Subject: Re: XSDDocumentProcessor visibility > +1. since I imagine xsd documents is not something that is only used > with wsdls. > > - Venkat > > On 7/22/07, Luciano Resende <[EMAIL PROTECTED]> wrote: >> Looks like XSDDocumentProcessor is not being registered with the >> proper artifact extension point, and it's being only available >> internally to the WSDLDocumentProcessor. Should we register it with >> the extension point to make it more widely available ? >> >> -- >> Luciano Resende >> Apache Tuscany Committer >> http://people.apache.org/~lresende >> http://lresende.blogspot.com/ >> >> - >> 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] >
Re: StackOverflowException when mutual reference exist
I mean that composite A has a component which uses composite B as an implementation and that composite B has a component which uses composite A as an implementation . I think this use case is fairly common, eg. [Employee] has a property refer to [Company] and [Company] has a property refer to it's [Employee]s. And when these two java components are in different composites, I'll have to define mutual referenced composite files above. - Original Message - From: "Mike Edwards" <[EMAIL PROTECTED]> To: Sent: Monday, July 09, 2007 4:37 PM Subject: Re: StackOverflowException when mutual reference exist > Huang, > > Can you clarify what you mean please? > > What configuration of composites are you using? > > Yours, Mike. > > Huang Kai wrote: >> I'm in the case 2. >> :( >> It's error-prone >> >> - Original Message - >> From: "Simon Laws" <[EMAIL PROTECTED]> >> To: >> Sent: Friday, July 06, 2007 11:11 PM >> Subject: Re: StackOverflowException when mutual reference exist >> >> >>> On 7/6/07, Mike Edwards <[EMAIL PROTECTED]> wrote: >>>> Huang, >>>> >>>> I assume that by "reference" here, you mean a service reference? If >>>> that is so, it should work. >>>> >>>> If you mean that composite A has a component which uses composite B as >>>> an implementation and that composite B has a component which uses >>>> composite A as an implementation - then this IS an illegal cyclical >>>> usage and should generate an error. >>>> >>>> Yours, Mike. >>>> >>>> Huang Kai wrote: >>>>> When CompositeA has reference to CompositeB while CompositeB also has >>>> reference back to CompositeA, CompositeBuilderImpl.build(composite) seems >>>> went into endless loop. >>>>> I'm not very sure whether it's a bug or this kind of reference is >>>> illegal? >>>> >>>> - >>>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>>> For additional commands, e-mail: [EMAIL PROTECTED] >>>> >>>> Mike >>> For clarification. In the first case is the assumption that the application >>> will ensure that messages do not pass round the loop forever. >>> >>> Simon >>> > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] >
Re: Need spec defined Databindings? Was: (TUSCANY-824) DataBinding: Is it a concern of Programming Model vs. Assembly?
+1. :-) - Original Message - From: "Mike Edwards" <[EMAIL PROTECTED]> To: Sent: Friday, July 06, 2007 9:34 PM Subject: Need spec defined Databindings? Was: (TUSCANY-824) DataBinding: Is it a concern of Programming Model vs. Assembly? > Folks, > > OK, finally, I bite ;-) > > The question for me is whether we need the SCA (Java) spec to define > some standard metadata (typically annotations) for databindings of > services & references. > > I make the assumption that for much of the time, it is possible to work > out the required databinding simply by inspection of the types of the > parameters involved. If you find an SDO object, if you find a JAXB > object, etc. > > So is the real issue the case where mixed types of data objects turn up? > Or are there ambiguous cases where you can't tell what the kind of > object is? > > I suppose that we can take two views of cases like these: > > a) Don't go there, it's not valid. > > b) OK, annotate your code enough to tell us exactly what you expect to > happen. > > If we want to go down the second path, then I'm happy to carry back > requirements to the SCA Java WG, but I'd really like an appreciation of > just how common this case is likely to be. > > Views please > > > Yours, Mike. > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] >
Re: StackOverflowException when mutual reference exist
I'm in the case 2. :( It's error-prone - Original Message - From: "Simon Laws" <[EMAIL PROTECTED]> To: Sent: Friday, July 06, 2007 11:11 PM Subject: Re: StackOverflowException when mutual reference exist > On 7/6/07, Mike Edwards <[EMAIL PROTECTED]> wrote: >> >> Huang, >> >> I assume that by "reference" here, you mean a service reference? If >> that is so, it should work. >> >> If you mean that composite A has a component which uses composite B as >> an implementation and that composite B has a component which uses >> composite A as an implementation - then this IS an illegal cyclical >> usage and should generate an error. >> >> Yours, Mike. >> >> Huang Kai wrote: >> > When CompositeA has reference to CompositeB while CompositeB also has >> reference back to CompositeA, CompositeBuilderImpl.build(composite) seems >> went into endless loop. >> > I'm not very sure whether it's a bug or this kind of reference is >> illegal? >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> Mike > > For clarification. In the first case is the assumption that the application > will ensure that messages do not pass round the loop forever. > > Simon >
Re: Need SCA Notification
Hi:
Sorry for the tardiness. I put my comments inline.
- Original Message -
From: "Simon Laws" <[EMAIL PROTECTED]>
To:
Sent: Wednesday, June 27, 2007 10:57 PM
Subject: Re: Need SCA Notification
> On 6/25/07, Huang Kai <[EMAIL PROTECTED]> wrote:
>>
>> Hi, all:
>> I think a notification mechanism useful to let spi provider know what
>> is going on in the SCA container.
>> A notification should be sent when
>> Contribution/Composite/Component/Artifact start or stop. Ofcoz stop() method
>> in implementationProvider,bindingProvider,.. can do some work, while some
>> resources may be shared by or not relavant to any particular provider(
>> like .composite file or .class file).
>> So how about adding a notification interface? And
>> ContributionServiceImpl may be responsible for sending the notification?
>>
>> this interface may look like:
>>
>> public static interface ContributionListener{
>> void addContribution(Contribution contribution);
>> void removeContribution(Contribution contribution);
>> void addComposite(Contribution contribution, Composite composite);
>> void removeComposite(Contribution contribution, Composite composite);
>> void addComponent(Contribution contribution, Component cmp);
>> void removeConmponent(Contribution contribution, Component cmp);
>> void addArtifact(Contribution contribution, DeployedArtifact model);
>> void removeArtifact(Contribution contribution, DeployedArtifact model);
>> }
>>
>> Anyone think alike?
>
>
> Hi
>
> I think you are on the right track here. Generally we need to get much
> better at capturing and presenting the actions/events associated with a
> running Tuscany runtime. Your list above is a great stating list of the
> static configuration type events we might expect. We could extend this to
> included other interesting things, for example, extensions loaded, composite
> errors found, service resolution events or even implementation specific or
> binding specific events such as the URLs of endpoints that are activated.
> Have you come across anything else which it would be useful to raise an
> event for?
>
A recent example is that we want to manually update an implementation file(like
a wsdl), without affecting other artifacts. And notifying the corresponding
ArtifactorProcessor to reload it seems straightforward, compared with
restarting the whole Tuscany.
I agree that a comprehensive event mechanism is needed for a SOA framework. And
surely implemenation can raise event of their own if the event has the right
format.
> From an implementation point of view I don't think I would define a single
> static interface. I would spin it around and define an event interface and
> then allow events to be passed to some event service from where ever in the
> runtime the event is generated. To describe specific events we could define
> an event data structure and specialise this for the events we decide are
> required. In this way we build up a catalog of events. It may be that some
> other open source project defines such an event infrastructure but I would
> have to go and do a few searches to find out. Do you know of anything that
> would fit the bill?
>
The interface I mentioned in last letter is just a rougth thought. Event is
apparently much better.
I did a quick search in sourceforge, but haven't found any usable project.
> In the case where Tuscany is tightly embedded we may want to wrap the event
> service and provide an api to the embedding system but this should be fairly
> easy to do. Do you have specific examples of how the events would be used?
> Or any thoughts about how the events should be delivered?
>
I think by listening to event/notification providers can be coordinated in a
more flexible way. You can't know in advance who will be interested in such
event as WebServicePortClosedEvent, or a more generic event like
ArtifactUpdatedEvent( this event may sent by an implementatioProvider if it
find some sidefile has been touched, and want to notify the ModelResolver about
this change).
This event mechanism needn't to be very complicated. We could start easily.
> As an aside I've been thinking similar thoughts with respect to the
> distributed runtime work [1]. I haven't gone to the level of thinking about
> events dealing specifically with composites, components and artifacts but no
> doubt that could be useful for monitoring and controlling the activity of a
> runtime node.
>
> In the distributed runtime code that is checked in to trunk such events are
> not explicitly presented but I have implement an example of how we could
> implement this. For example, I need to p
StackOverflowException when mutual reference exist
When CompositeA has reference to CompositeB while CompositeB also has reference back to CompositeA, CompositeBuilderImpl.build(composite) seems went into endless loop. I'm not very sure whether it's a bug or this kind of reference is illegal?
Need SCA Notification
Hi, all:
I think a notification mechanism useful to let spi provider know what is
going on in the SCA container.
A notification should be sent when
Contribution/Composite/Component/Artifact start or stop. Ofcoz stop() method in
implementationProvider,bindingProvider,.. can do some work, while some
resources may be shared by or not relavant to any particular provider( like
.composite file or .class file).
So how about adding a notification interface? And ContributionServiceImpl
may be responsible for sending the notification?
this interface may look like:
public static interface ContributionListener{
void addContribution(Contribution contribution);
void removeContribution(Contribution contribution);
void addComposite(Contribution contribution, Composite composite);
void removeComposite(Contribution contribution, Composite composite);
void addComponent(Contribution contribution, Component cmp);
void removeConmponent(Contribution contribution, Component cmp);
void addArtifact(Contribution contribution, DeployedArtifact model);
void removeArtifact(Contribution contribution, DeployedArtifact model);
}
Anyone think alike?
[jira] Commented: (TUSCANY-1346) Resolution to TUSCANY-1332 assumes a closed top-level composite that does not support addition of new components
[ https://issues.apache.org/jira/browse/TUSCANY-1346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12507557 ] Huang Kai commented on TUSCANY-1346: How about re-resolving the original and newly added components in a seperate thread, and replace all the old components when the resolvement is done. My rough thought is: Clone all the components, and do the rewiring work in the cloned compnents, but keep all the implementationProvider/bindingProvider/scopeContainer refer to the same instance to keep their states unchanged. > Resolution to TUSCANY-1332 assumes a closed top-level composite that does not > support addition of new components > > > Key: TUSCANY-1346 > URL: https://issues.apache.org/jira/browse/TUSCANY-1346 > Project: Tuscany > Issue Type: Bug > Components: Java SCA Assembly Model, Java SCA Core Runtime, Java SCA > Embedded Runtime >Affects Versions: Java-SCA-0.90, Java-SCA-0.91 >Reporter: Matthew Sykes > > The resolution to TUSCANY-1332 involved exploitation of the composite include > function to "include" all known deployable composites into the domain such > that the components contained within the deployable composites would be wired > together when the domain level composite was activated. While this resolved > the issues of wiring across multiple composites contained within different > contributions, this approach requires that the system know of all composites > that may be part of the domain at the time the domain is activated. > When embedding Tuscany in a server runtime, however, deployment and > activation of composites may occur after the domain is activated. With the > current implementation that is contained with EmbeddedSCADomain, runtimes > that consume Tuscany would have to stop and restart the domain composite to > deploy and activate new components and their services. While this may be > appropriate for small systems, it's not workable in complex environments. > I believe Tuscany needs a wiring and activation model that is more dynamic > such that components can be added to (or removed from) the domain and wired > after the domain composite was initially activated. This flexibility would > have implications to the way wiring is done and how multiplicity is validated > as the shape of the domain changes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
How to add contribution to an existing domain
Hi all: How do I add a contribution to an existing domain, without creating a new domain? And I have no way to get a ContributionService instance in current domain before I can call its contribute() or remove() method (IMHO, it should has a update() method). I think it's neccesary to have a API to get current ContributionService in a domain.
Re: (SCA)How can get the service by composite service name
So, as I understand, once a element is defined in a composite file,
this component is treated as service by default.
If one can access service just by getService("componentName/serviceName"),
there will be no need to define for service exposed by component ?
And there's no way to hide a component in composite from being accessed, even
this component is used solely for reference?
- Original Message -
From: "Jean-Sebastien Delfino" <[EMAIL PROTECTED]>
To:
Sent: Friday, June 01, 2007 12:15 AM
Subject: Re: (SCA)How can get the service by composite service name
> [snip]
> Raymond Feng wrote:
>> Hi,
>>
>> By the SCA spec, when a deployable composite is added to the SCA
>> domain, it's "included" by the logical SCA domain composite. As a
>> result, all top-level components must have unique names.
>>
>> Thanks,
>> Raymond
>>
>> - Original Message - From: "Huang Kai" <[EMAIL PROTECTED]>
>> To:
>> Cc: "???" <[EMAIL PROTECTED]>; "jiaoly" <[EMAIL PROTECTED]>; "??"
>> <[EMAIL PROTECTED]>
>> Sent: Thursday, May 31, 2007 2:03 AM
>> Subject: Re: (SCA)How can get the service by composite service name
>>
>>
>>> I understood. It seems so.
>>>
>>> While this raise another question: Tuscany seemed skipped the
>>> 'composite' layer and direct access component service, then how to
>>> access services in two composites within same domain?
>>>
>>> like this:
>>>
>>>
>>>
>>> CompositeA.composite:
>>>
>>> http://www.osoa.org/xmlns/sca/1.0";
>>> targetNamespace=http://www.globalfinance.com/NASDAQ";
>>> name="NASDAQ">
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> CompositeB.composite:
>>>
>>> http://www.osoa.org/xmlns/sca/1.0";
>>> targetNamespace=http://www.globalfinance.com/HongKong";
>>> name="HongKong">
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> ---
>>>
>>>
>>>
>>> When these two composite all loaded in one SCADomain.
>>>
>>> How do I get StockQuoteService supplied by CompositeB or CompositeA?
>>>
>>> How can SCADomain.getService(Class, String) handle such name conflict?
>>>
>>>
>>>
>
> Adding composites to a domain is described in section 1.10.6.1.
>
> 3075 1.10.6.1 add To Domain-Level Composite
> 3076 This functionality adds the composite identified by a supplied URI
> to the Domain Level
> 3077 Composite. The supplied composite URI must refer to a composite
> within a installed contribution.
> 3078 The composite's installed contribution determines how the
> composite’s artifacts are resolved
> 3079 (directly and indirectly). The supplied composite is added to the
> domain composite with
> 3080 semantics that correspond to the domain-level composite having an
> statement that
> 3081 references the supplied composite. All of the composite’s
> components become top-level
> 3082 components and the services become externally visible services (eg.
> they would be present in a
> 3083 WSDL description of the domain).
>
> So in your example you could do:
>
> CompositeA.composite:
>
> http://www.osoa.org/xmlns/sca/1.0";
> targetNamespace=http://www.globalfinance.com/NASDAQ";
> name="NASDAQ">
>
>
>
>
>
>
>
>
>
>
>
> CompositeB.composite:
>
> http://www.osoa.org/xmlns/sca/1.0";
> targetNamespace=http://www.globalfinance.com/HongKong";
> name="HongKong">
>
>
>
>
>
>
>
>
>
>
> Then call domain.getService(StockQuote.class,
> "NasdaqStockQuoteServiceComponent") and
> domain.getService(StockQuote.class, "HongKongStockQuoteServiceComponent").
>
>
> Hope this helps.
>
> --
> Jean-Sebastien
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
[jira] Created: (TUSCANY-1319) contribution meta documents not merged
contribution meta documents not merged -- Key: TUSCANY-1319 URL: https://issues.apache.org/jira/browse/TUSCANY-1319 Project: Tuscany Issue Type: Bug Components: Java SCA Assembly Model Reporter: Huang Kai in SCA spec 1.10.2.2 write: "...accommodate this, it is also possible to have an identically structured document at META-INF/sca-contribution-generated.xml. If this document exists (or is generated on an as-needed basis), it will be merged into the contents of sca-contribution.xml, with the entries in sca-contribution.xml taking priority if there are any conflicting declarations." Tuscany seems won't load sca-contribution-generated.xml if sca-contribution.xml exists. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
How to add multiple contribution to tuscany?
Hi, all: I got several question when looking into Tuscany's codes: 1)MULTIPLE CONTRIBUTION IMO, a contribution is a deployment unit, so a domain should be allowed to have more than one contribution. While Tuscany only handles one contribution. -- DefaultSCADomain: // Look for META-INF/sca-contribution.xml contributionArtifactPath = Contribution.SCA_CONTRIBUTION_META; contributionArtifactURL = classLoader.getResource(contributionArtifactPath); --- Should it be "classLoader.getResources(contributionArtifactPath)" for multiple contributions? And following codes doesn't handle multiple contribution neither. Like 'ContributionServiceImpl.addContribution', is called only once. 2)CONTRIBUTION META DOCUMENT MERGING in SCA spec 1.10.2.2 write: "...accommodate this, it is also possible to have an identically structured document at META-INF/sca-contribution-generated.xml. If this document exists (or is generated on an as-needed basis), it will be merged into the contents of sca-contribution.xml, with the entries in sca-contribution.xml taking priority if there are any conflicting declarations." Tuscany seems won't load sca-contribution-generated.xml if sca-contribution.xml exists. 3)CONTRIBUTION IMPORT/EXPORT Tuscany do resolved 'import' and 'export' in 'sca-contribution.xml'. If only one contribution is resolved, as said in (1), import/export become meaningless. 4)CONTRIBUTION META EXTENSION contribution meta document resolving hard-coded xml element name , not as extensible as DefaultURLArtifactProcessorExtensionPoint used else where. see also SCA spec 1.10.2.2 "...For example, can be used can be used to export java definitions, in which case the namespace should be a fully qualified package name."
Re: (SCA)How can get the service by composite service name
I understood. It seems so. While this raise another question: Tuscany seemed skipped the 'composite' layer and direct access component service, then how to access services in two composites within same domain? like this: CompositeA.composite: http://www.osoa.org/xmlns/sca/1.0"; targetNamespace=http://www.globalfinance.com/NASDAQ"; name="NASDAQ"> CompositeB.composite: http://www.osoa.org/xmlns/sca/1.0"; targetNamespace=http://www.globalfinance.com/HongKong"; name="HongKong"> --- When these two composite all loaded in one SCADomain. How do I get StockQuoteService supplied by CompositeB or CompositeA? How can SCADomain.getService(Class, String) handle such name conflict? - Original Message - From: "Jean-Sebastien Delfino" <[EMAIL PROTECTED]> To: Sent: Wednesday, May 30, 2007 12:24 PM Subject: Re: (SCA)How can get the service by composite service name > Comments inline. > > Huang Kai wrote: >> Yes, the codes seems does so. >> But it's rather strange to access a service not by 'service name' exposed by >> compoiste, but by directly accessing component nested in a composite. >> > > Here's a little more info that will help explain that design: > > - When a composite is added to a domain, it is actually included in it, > so there is really no nesting. Components declared in the composite > become top level components as if they had been directly declared in the > composite describing the entire domain. This process is described in the > SCA assembly spec 1.0 in section 1.10.6.1: > 1.10.6.1 add To Domain-Level Composite > 3076 This functionality adds the composite identified by a supplied URI > to the Domain Level > 3077 Composite. The supplied composite URI must refer to a composite > within a installed contribution. > 3078 The composite's installed contribution determines how the > composite’s artifacts are resolved > 3079 (directly and indirectly). The supplied composite is added to the > domain composite with > 3080 semantics that correspond to the domain-level composite having an > statement that > 3081 references the supplied composite. All of the composite’s > components become top-level > 3082 components and the services become externally visible services (eg. > they would be present in a > 3083 WSDL description of the domain). > > - Services offered by components in the composite become visible, and > can be addressed in a form consistent with what you would say in the > target of an SCA wire or reference, as described in section 1.6.4 of the > SCA assembly spec: > 1613 The reference element of a component and the reference element of a > service has a list > 1614 of one or more of the following wire-target-URI values for the > target, with multiple values > 1615 separated by a space: > 1616 • / > 1617 o where the target is a service of a component. The specification > of the service name > 1618 is optional if the target component only has one service with a > compatible interface > > As the spec says "the target is a service of a component". A service is > not really offered by a composite, it is offered by a component. A > composite service declaration is just a statement that a service offered > by a component should be promoted / made visible to the next level of > composition, when the particular composite is used as a (composite) > component implementation (using an element). > The service promoted by the composite service will then be offered by > that new component. > > Also, some components only offer one service for a given interface. In > that case you don't have to specify the service name, the component name > is sufficient to get the service matching the requested interface. > > So in your particular example: > - CalculatorServiceComponent is a top-level component. > - getService(CalculatorService.class, "CalculatorServiceComponent") is a > short form for getService(CalculatorService.class, > "CalculatorServiceComponent/CalculatorService"), you don't need to > specify the service name as CalculatorServiceComponent only provides one > service. > > Hope this helps. > >> - Original Message - >> From: "Simon Laws" <[EMAIL PROTECTED]> >> To: >> Sent: Friday, May 25, 2007 10:03 PM >> Subject: Re: (SCA)How can get the service by composite service name >> >> >>
Re: (SCA)How can get the service by composite service name
Yes, the codes seems does so. But it's rather strange to access a service not by 'service name' exposed by compoiste, but by directly accessing component nested in a composite. - Original Message - From: "Simon Laws" <[EMAIL PROTECTED]> To: Sent: Friday, May 25, 2007 10:03 PM Subject: Re: (SCA)How can get the service by composite service name > Hi Tony, > > I'm assuming you are using the sample CalculatorClient style code try to > access the service, i.e. the part that uses the scaDomain to get a local > reference to a component service. > >CalculatorService calculatorService = >scaDomain.getService(CalculatorService.class, > "CalculatorServiceComponent"); > > I just took a look at the code and currently the code behind this method > only looks at the components available in the domain composite when looking > for the named service, i.e. It's looking for a component and a service it > provides rather than a composite service that refers to a component service. > The term service is a little confusing in this regard in my opinion. > > Regards > > Simon >
How to make Tuscany SDO available in Websphere or other server?
We wanna use tuscany sdo in application that runs on websphere 6. Unfortunatelly we found it conflicts with websphere's own sdo api jar( actually an emf sdo jar : org.eclipse.emf.commonj.sdo_2.1.0.v200609210005.jar). Since websphere's own jar has higher privillege when loading classes, tuscany's sdo spec api jar won't take effect. What made it worse is that those sdo api in emf is out of date, eg. calling Type.isAbstract() throws NoSuchMethodError. And, it uses old-fashion "Class.forName( "commonj.sdo.impl.HelperProviderImpl").newInstance()" to find sdo impl instead of reading "META-INF/services/commonj.sdo.impl.HelperProvider", which make it impossible to use tuscany's sdo impl. Did anyone encounter similiar problem?
