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: tuscany-dev@ws.apache.org 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: tuscany-dev@ws.apache.org 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 import. 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 import.wsdl. doesn't seem to be a valid URI. The absence of schemaLocation for xsd:import and xsd:include 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 QName during the resolve() phase. b) Disable the import/include resolving feature and re-link the related
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: tuscany-dev@ws.apache.org 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 xsd:import or xsd:include is set. Now we would like to handle the cases where the schemaLocation attribute is not present. For example, xsd:import namespace=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: 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: tuscany-dev@ws.apache.org 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: tuscany-dev@ws.apache.org 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: tuscany-dev@ws.apache.org 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: StackOverflowException when mutual reference exist
I'm in the case 2. :( It's error-prone - Original Message - From: Simon Laws [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org 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 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: tuscany-dev@ws.apache.org 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: Need SCA Notification
Hi:
Sorry for the tardiness. I put my comments inline.
- Original Message -
From: Simon Laws [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
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 provide configuration information to
each node in the distributed runtime so have chosen to install a system
SCA assembly to manage this for me. It currently only has one component in
it (ComponentRegistry) but allows me to build a configuration interface
without worrying about how that interface is accessed either locally or
remotely. I'm eating our own cooking here!
We could do the same
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 component 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 service 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: tuscany-dev@ws.apache.org 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: tuscany-dev@ws.apache.org 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: composite xmlns=http://www.osoa.org/xmlns/sca/1.0; targetNamespace=http://www.globalfinance.com/NASDAQ; name=NASDAQ component name=StockQuoteServiceComponent implementation.java class=com.ibm.stock.StockQuoteServiceImpl/ /component /composite CompositeB.composite: composite xmlns=http://www.osoa.org/xmlns/sca/1.0; targetNamespace=http://www.globalfinance.com/HongKong; name=HongKong component name=StockQuoteServiceComponent implementation.java class=com.lenovo.stock.StockQuoteServiceImpl/ /component /composite --- 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 include 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: composite xmlns=http://www.osoa.org/xmlns/sca/1.0; targetNamespace=http://www.globalfinance.com/NASDAQ; name=NASDAQ component name=NasdaqStockQuoteServiceComponent implementation.java class=com.ibm.stock.StockQuoteServiceImpl/ /component /composite CompositeB.composite: composite xmlns=http://www.osoa.org/xmlns/sca/1.0; targetNamespace=http://www.globalfinance.com/HongKong; name=HongKong component name=HongKongStockQuoteServiceComponent implementation.java class=com.lenovo.stock.StockQuoteServiceImpl/ /component /composite 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]
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: composite xmlns=http://www.osoa.org/xmlns/sca/1.0; targetNamespace=http://www.globalfinance.com/NASDAQ; name=NASDAQ component name=StockQuoteServiceComponent implementation.java class=com.ibm.stock.StockQuoteServiceImpl/ /component /composite CompositeB.composite: composite xmlns=http://www.osoa.org/xmlns/sca/1.0; targetNamespace=http://www.globalfinance.com/HongKong; name=HongKong component name=StockQuoteServiceComponent implementation.java class=com.lenovo.stock.StockQuoteServiceImpl/ /component /composite --- 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: tuscany-dev@ws.apache.org 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 include 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 • component-name/service-name 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 implementation.composite 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: tuscany-dev@ws.apache.org 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
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, export.java can be used can be used to export java definitions, in which case the namespace should be a fully qualified package name.
[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 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?
