[jira] Updated: (TUSCANY-2239) Support for mutually-exclusive intents
[ https://issues.apache.org/jira/browse/TUSCANY-2239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Greg Dritschler updated TUSCANY-2239: - Attachment: tuscany-2239-CompositeWireBuilder.patch Support for mutually-exclusive intents -- Key: TUSCANY-2239 URL: https://issues.apache.org/jira/browse/TUSCANY-2239 Project: Tuscany Issue Type: New Feature Components: Java SCA Core Runtime Reporter: Greg Dritschler Assignee: Venkatakrishnan Attachments: tuscany-2239-CompositeWireBuilder.patch, tuscany-2239.patch The SCA Policy specification does not provide a means to define intents which are mutually exclusive. This is a noticeable omission when considering the intents in the SCA Transaction specification which are mutually exclusive by nature (managedTransaction vs. noManagedTransaction, propagatesTransaction vs. suspendsTransaction). There is a need to be able to define intents which are mutually exclusive and for the exclusion to be checked by the SCA runtime to avoid the error of specifying exclusive intents on a single artifact. In addition, there should be rules defined for the handling of mutually exclusive intents which are attached at different levels of a composite or a hierarchy of composites. I have attached a patch to provide the capability to define mutually exclusive intents. This is achieved using a new @excludes attribute on the intent/ element in definitions.xml. For example: intent name=propagatesTransaction constrains=implementation excludes=suspendsTransaction/ @excludes is a list of intents which are mutually-exclusive with the named intent. In order to be effective, a reciprocal definition needs to be made as shown below. intent name=suspendsTransaction constrains=implementation excludes=propagatesTransaction/ The patch makes no assumptions about the relationship of qualified intents to the base intent. Therefore exclusive relationships between qualified intents need to be spelled out. intent name=noManagedTransaction constrains=implementation excludes=managedTransaction managedTransaction.global managedTransaction.local/ A key part of the patch is that there now are two types of intent inheritance with respect to exclusive intents. There is a default inheritance between certain hierarchical elements within a composite. For example consider this snippet from a composite: component name=C1 requires=propagatesTransaction reference name=r1/ reference name=r2/ reference name=r3 requires=suspendsTransaction/ /component In this case the first two references inherit the default intent propagatesTransaction from the component element. However the third reference does not inherit it because it specifies an exclusive intent suspendsTransaction which overrides the component-level default. The second type of inheritance is used when inheriting intents from an implementation (e.g. introspected Java code, or an implementation composite). In this case the intents of the implementation cannot be overridden. Consider this example: component name=D1 implementation.composite name=CZ1/ reference name=r1 requires=suspendsTransaction/ /component Let's assume CZ1 contains the component C1 shown earlier and that it promotes the component reference C1/r1 as r1. C1/r1 has the intent propagatesTransaction. This intent is considered a requirement of the implementation and it cannot be overridden by the using composite. Therefore D1 is in error. -- 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]
[jira] Updated: (TUSCANY-2239) Support for mutually-exclusive intents
[ https://issues.apache.org/jira/browse/TUSCANY-2239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Greg Dritschler updated TUSCANY-2239: - Attachment: (was: tuscany-2239-CompositeWireBuilder.patch) Support for mutually-exclusive intents -- Key: TUSCANY-2239 URL: https://issues.apache.org/jira/browse/TUSCANY-2239 Project: Tuscany Issue Type: New Feature Components: Java SCA Core Runtime Reporter: Greg Dritschler Assignee: Venkatakrishnan Attachments: tuscany-2239-CompositeWireBuilder.patch, tuscany-2239.patch The SCA Policy specification does not provide a means to define intents which are mutually exclusive. This is a noticeable omission when considering the intents in the SCA Transaction specification which are mutually exclusive by nature (managedTransaction vs. noManagedTransaction, propagatesTransaction vs. suspendsTransaction). There is a need to be able to define intents which are mutually exclusive and for the exclusion to be checked by the SCA runtime to avoid the error of specifying exclusive intents on a single artifact. In addition, there should be rules defined for the handling of mutually exclusive intents which are attached at different levels of a composite or a hierarchy of composites. I have attached a patch to provide the capability to define mutually exclusive intents. This is achieved using a new @excludes attribute on the intent/ element in definitions.xml. For example: intent name=propagatesTransaction constrains=implementation excludes=suspendsTransaction/ @excludes is a list of intents which are mutually-exclusive with the named intent. In order to be effective, a reciprocal definition needs to be made as shown below. intent name=suspendsTransaction constrains=implementation excludes=propagatesTransaction/ The patch makes no assumptions about the relationship of qualified intents to the base intent. Therefore exclusive relationships between qualified intents need to be spelled out. intent name=noManagedTransaction constrains=implementation excludes=managedTransaction managedTransaction.global managedTransaction.local/ A key part of the patch is that there now are two types of intent inheritance with respect to exclusive intents. There is a default inheritance between certain hierarchical elements within a composite. For example consider this snippet from a composite: component name=C1 requires=propagatesTransaction reference name=r1/ reference name=r2/ reference name=r3 requires=suspendsTransaction/ /component In this case the first two references inherit the default intent propagatesTransaction from the component element. However the third reference does not inherit it because it specifies an exclusive intent suspendsTransaction which overrides the component-level default. The second type of inheritance is used when inheriting intents from an implementation (e.g. introspected Java code, or an implementation composite). In this case the intents of the implementation cannot be overridden. Consider this example: component name=D1 implementation.composite name=CZ1/ reference name=r1 requires=suspendsTransaction/ /component Let's assume CZ1 contains the component C1 shown earlier and that it promotes the component reference C1/r1 as r1. C1/r1 has the intent propagatesTransaction. This intent is considered a requirement of the implementation and it cannot be overridden by the using composite. Therefore D1 is in error. -- 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]
[jira] Updated: (TUSCANY-2239) Support for mutually-exclusive intents
[ https://issues.apache.org/jira/browse/TUSCANY-2239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Greg Dritschler updated TUSCANY-2239: - Attachment: tuscany-2239-CompositeWireBuilder.patch Support for mutually-exclusive intents -- Key: TUSCANY-2239 URL: https://issues.apache.org/jira/browse/TUSCANY-2239 Project: Tuscany Issue Type: New Feature Components: Java SCA Core Runtime Reporter: Greg Dritschler Assignee: Venkatakrishnan Attachments: tuscany-2239-CompositeWireBuilder.patch, tuscany-2239.patch The SCA Policy specification does not provide a means to define intents which are mutually exclusive. This is a noticeable omission when considering the intents in the SCA Transaction specification which are mutually exclusive by nature (managedTransaction vs. noManagedTransaction, propagatesTransaction vs. suspendsTransaction). There is a need to be able to define intents which are mutually exclusive and for the exclusion to be checked by the SCA runtime to avoid the error of specifying exclusive intents on a single artifact. In addition, there should be rules defined for the handling of mutually exclusive intents which are attached at different levels of a composite or a hierarchy of composites. I have attached a patch to provide the capability to define mutually exclusive intents. This is achieved using a new @excludes attribute on the intent/ element in definitions.xml. For example: intent name=propagatesTransaction constrains=implementation excludes=suspendsTransaction/ @excludes is a list of intents which are mutually-exclusive with the named intent. In order to be effective, a reciprocal definition needs to be made as shown below. intent name=suspendsTransaction constrains=implementation excludes=propagatesTransaction/ The patch makes no assumptions about the relationship of qualified intents to the base intent. Therefore exclusive relationships between qualified intents need to be spelled out. intent name=noManagedTransaction constrains=implementation excludes=managedTransaction managedTransaction.global managedTransaction.local/ A key part of the patch is that there now are two types of intent inheritance with respect to exclusive intents. There is a default inheritance between certain hierarchical elements within a composite. For example consider this snippet from a composite: component name=C1 requires=propagatesTransaction reference name=r1/ reference name=r2/ reference name=r3 requires=suspendsTransaction/ /component In this case the first two references inherit the default intent propagatesTransaction from the component element. However the third reference does not inherit it because it specifies an exclusive intent suspendsTransaction which overrides the component-level default. The second type of inheritance is used when inheriting intents from an implementation (e.g. introspected Java code, or an implementation composite). In this case the intents of the implementation cannot be overridden. Consider this example: component name=D1 implementation.composite name=CZ1/ reference name=r1 requires=suspendsTransaction/ /component Let's assume CZ1 contains the component C1 shown earlier and that it promotes the component reference C1/r1 as r1. C1/r1 has the intent propagatesTransaction. This intent is considered a requirement of the implementation and it cannot be overridden by the using composite. Therefore D1 is in error. -- 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]
[jira] Commented: (TUSCANY-2239) Support for mutually-exclusive intents
[ https://issues.apache.org/jira/browse/TUSCANY-2239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12590785#action_12590785 ] Greg Dritschler commented on TUSCANY-2239: -- I have attached a new patch for CompositeWireBuilderImpl. Support for mutually-exclusive intents -- Key: TUSCANY-2239 URL: https://issues.apache.org/jira/browse/TUSCANY-2239 Project: Tuscany Issue Type: New Feature Components: Java SCA Core Runtime Reporter: Greg Dritschler Assignee: Venkatakrishnan Attachments: tuscany-2239-CompositeWireBuilder.patch, tuscany-2239.patch The SCA Policy specification does not provide a means to define intents which are mutually exclusive. This is a noticeable omission when considering the intents in the SCA Transaction specification which are mutually exclusive by nature (managedTransaction vs. noManagedTransaction, propagatesTransaction vs. suspendsTransaction). There is a need to be able to define intents which are mutually exclusive and for the exclusion to be checked by the SCA runtime to avoid the error of specifying exclusive intents on a single artifact. In addition, there should be rules defined for the handling of mutually exclusive intents which are attached at different levels of a composite or a hierarchy of composites. I have attached a patch to provide the capability to define mutually exclusive intents. This is achieved using a new @excludes attribute on the intent/ element in definitions.xml. For example: intent name=propagatesTransaction constrains=implementation excludes=suspendsTransaction/ @excludes is a list of intents which are mutually-exclusive with the named intent. In order to be effective, a reciprocal definition needs to be made as shown below. intent name=suspendsTransaction constrains=implementation excludes=propagatesTransaction/ The patch makes no assumptions about the relationship of qualified intents to the base intent. Therefore exclusive relationships between qualified intents need to be spelled out. intent name=noManagedTransaction constrains=implementation excludes=managedTransaction managedTransaction.global managedTransaction.local/ A key part of the patch is that there now are two types of intent inheritance with respect to exclusive intents. There is a default inheritance between certain hierarchical elements within a composite. For example consider this snippet from a composite: component name=C1 requires=propagatesTransaction reference name=r1/ reference name=r2/ reference name=r3 requires=suspendsTransaction/ /component In this case the first two references inherit the default intent propagatesTransaction from the component element. However the third reference does not inherit it because it specifies an exclusive intent suspendsTransaction which overrides the component-level default. The second type of inheritance is used when inheriting intents from an implementation (e.g. introspected Java code, or an implementation composite). In this case the intents of the implementation cannot be overridden. Consider this example: component name=D1 implementation.composite name=CZ1/ reference name=r1 requires=suspendsTransaction/ /component Let's assume CZ1 contains the component C1 shown earlier and that it promotes the component reference C1/r1 as r1. C1/r1 has the intent propagatesTransaction. This intent is considered a requirement of the implementation and it cannot be overridden by the using composite. Therefore D1 is in error. -- 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]
[jira] Created: (TUSCANY-2246) Update DefaultContextFactoryExtensionPoint to use ServiceDiscovery
Update DefaultContextFactoryExtensionPoint to use ServiceDiscovery -- Key: TUSCANY-2246 URL: https://issues.apache.org/jira/browse/TUSCANY-2246 Project: Tuscany Issue Type: Improvement Components: Java SCA Core Runtime Reporter: Greg Dritschler Change DefaultContextFactoryExtensionPoint to use ServiceDiscovery to find implementation of context factory. -- 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]
[jira] Updated: (TUSCANY-2246) Update DefaultContextFactoryExtensionPoint to use ServiceDiscovery
[ https://issues.apache.org/jira/browse/TUSCANY-2246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Greg Dritschler updated TUSCANY-2246: - Attachment: tuscany-2246.patch Update DefaultContextFactoryExtensionPoint to use ServiceDiscovery -- Key: TUSCANY-2246 URL: https://issues.apache.org/jira/browse/TUSCANY-2246 Project: Tuscany Issue Type: Improvement Components: Java SCA Core Runtime Reporter: Greg Dritschler Attachments: tuscany-2246.patch Change DefaultContextFactoryExtensionPoint to use ServiceDiscovery to find implementation of context factory. -- 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]
[jira] Created: (TUSCANY-2239) Support for mutually-exclusive intents
Support for mutually-exclusive intents -- Key: TUSCANY-2239 URL: https://issues.apache.org/jira/browse/TUSCANY-2239 Project: Tuscany Issue Type: New Feature Components: Java SCA Core Runtime Reporter: Greg Dritschler The SCA Policy specification does not provide a means to define intents which are mutually exclusive. This is a noticeable omission when considering the intents in the SCA Transaction specification which are mutually exclusive by nature (managedTransaction vs. noManagedTransaction, propagatesTransaction vs. suspendsTransaction). There is a need to be able to define intents which are mutually exclusive and for the exclusion to be checked by the SCA runtime to avoid the error of specifying exclusive intents on a single artifact. In addition, there should be rules defined for the handling of mutually exclusive intents which are attached at different levels of a composite or a hierarchy of composites. I have attached a patch to provide the capability to define mutually exclusive intents. This is achieved using a new @excludes attribute on the intent/ element in definitions.xml. For example: intent name=propagatesTransaction constrains=implementation excludes=suspendsTransaction/ @excludes is a list of intents which are mutually-exclusive with the named intent. In order to be effective, a reciprocal definition needs to be made as shown below. intent name=suspendsTransaction constrains=implementation excludes=propagatesTransaction/ The patch makes no assumptions about the relationship of qualified intents to the base intent. Therefore exclusive relationships between qualified intents need to be spelled out. intent name=noManagedTransaction constrains=implementation excludes=managedTransaction managedTransaction.global managedTransaction.local/ A key part of the patch is that there now are two types of intent inheritance with respect to exclusive intents. There is a default inheritance between certain hierarchical elements within a composite. For example consider this snippet from a composite: component name=C1 requires=propagatesTransaction reference name=r1/ reference name=r2/ reference name=r3 requires=suspendsTransaction/ /component In this case the first two references inherit the default intent propagatesTransaction from the component element. However the third reference does not inherit it because it specifies an exclusive intent suspendsTransaction which overrides the component-level default. The second type of inheritance is used when inheriting intents from an implementation (e.g. introspected Java code, or an implementation composite). In this case the intents of the implementation cannot be overridden. Consider this example: component name=D1 implementation.composite name=CZ1/ reference name=r1 requires=suspendsTransaction/ /component Let's assume CZ1 contains the component C1 shown earlier and that it promotes the component reference C1/r1 as r1. C1/r1 has the intent propagatesTransaction. This intent is considered a requirement of the implementation and it cannot be overridden by the using composite. Therefore D1 is in error. -- 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]
[jira] Updated: (TUSCANY-2239) Support for mutually-exclusive intents
[ https://issues.apache.org/jira/browse/TUSCANY-2239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Greg Dritschler updated TUSCANY-2239: - Attachment: tuscany-2239.patch Support for mutually-exclusive intents -- Key: TUSCANY-2239 URL: https://issues.apache.org/jira/browse/TUSCANY-2239 Project: Tuscany Issue Type: New Feature Components: Java SCA Core Runtime Reporter: Greg Dritschler Attachments: tuscany-2239.patch The SCA Policy specification does not provide a means to define intents which are mutually exclusive. This is a noticeable omission when considering the intents in the SCA Transaction specification which are mutually exclusive by nature (managedTransaction vs. noManagedTransaction, propagatesTransaction vs. suspendsTransaction). There is a need to be able to define intents which are mutually exclusive and for the exclusion to be checked by the SCA runtime to avoid the error of specifying exclusive intents on a single artifact. In addition, there should be rules defined for the handling of mutually exclusive intents which are attached at different levels of a composite or a hierarchy of composites. I have attached a patch to provide the capability to define mutually exclusive intents. This is achieved using a new @excludes attribute on the intent/ element in definitions.xml. For example: intent name=propagatesTransaction constrains=implementation excludes=suspendsTransaction/ @excludes is a list of intents which are mutually-exclusive with the named intent. In order to be effective, a reciprocal definition needs to be made as shown below. intent name=suspendsTransaction constrains=implementation excludes=propagatesTransaction/ The patch makes no assumptions about the relationship of qualified intents to the base intent. Therefore exclusive relationships between qualified intents need to be spelled out. intent name=noManagedTransaction constrains=implementation excludes=managedTransaction managedTransaction.global managedTransaction.local/ A key part of the patch is that there now are two types of intent inheritance with respect to exclusive intents. There is a default inheritance between certain hierarchical elements within a composite. For example consider this snippet from a composite: component name=C1 requires=propagatesTransaction reference name=r1/ reference name=r2/ reference name=r3 requires=suspendsTransaction/ /component In this case the first two references inherit the default intent propagatesTransaction from the component element. However the third reference does not inherit it because it specifies an exclusive intent suspendsTransaction which overrides the component-level default. The second type of inheritance is used when inheriting intents from an implementation (e.g. introspected Java code, or an implementation composite). In this case the intents of the implementation cannot be overridden. Consider this example: component name=D1 implementation.composite name=CZ1/ reference name=r1 requires=suspendsTransaction/ /component Let's assume CZ1 contains the component C1 shown earlier and that it promotes the component reference C1/r1 as r1. C1/r1 has the intent propagatesTransaction. This intent is considered a requirement of the implementation and it cannot be overridden by the using composite. Therefore D1 is in error. -- 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]
[jira] Created: (TUSCANY-2171) binding.sca bindingType in definitions.xml not used if SCA binding is created during build phase
binding.sca bindingType in definitions.xml not used if SCA binding is created
during build phase
Key: TUSCANY-2171
URL: https://issues.apache.org/jira/browse/TUSCANY-2171
Project: Tuscany
Issue Type: Bug
Components: Java SCA Core Runtime
Affects Versions: Java-SCA-1.0.1
Reporter: Greg Dritschler
I have a definitions.xml file which defines a bindingType for binding.sca.
bindingType type=sca:binding.sca mayProvide=propagatesTransaction/
I have a composite which uses an intent on a reference.
reference name=daService target=DataAccessComponent
requires=propagatesTransaction/
The reference does not have a binding.sca element. In this case the binding
model object is created by CompositeConfigurationBuilderImpl.createSCABinding()
which is shown below.
private SCABinding createSCABinding() {
SCABinding scaBinding = scaBindingFactory.createSCABinding();
IntentAttachPointType bindingType =
intentAttachPointTypeFactory.createBindingType();
bindingType.setName(BINDING_SCA_QNAME);
bindingType.setUnresolved(true);
((PolicySetAttachPoint)scaBinding).setType(bindingType);
return scaBinding;
}
This method creates an IntentAttachPointType which is unresolved. There is no
code to resolve the IntentAttachPointType to the real one. As a result the
PolicyComputer uses the unresolved IntentAttachPointType model and does not
realize that binding.sca provides the intent needed by the reference.
Discussed on tuscany-dev here:
http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg28903.html
--
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]
[jira] Created: (TUSCANY-2172) Removing a contribution that has a definitions.xml file leaves the definitions in place
Removing a contribution that has a definitions.xml file leaves the definitions in place --- Key: TUSCANY-2172 URL: https://issues.apache.org/jira/browse/TUSCANY-2172 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-1.0.1 Reporter: Greg Dritschler A contribution may contain a definitions.xml document that defines intents and/or policy sets. When such a contribution is removed, I would expect these definitions to be removed from the runtime. Discussed on tuscany-dev here: http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg29138.html -- 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]
[jira] Created: (TUSCANY-2092) ConcurrentModificationException in ExtensibleContributionListener
ConcurrentModificationException in ExtensibleContributionListener - Key: TUSCANY-2092 URL: https://issues.apache.org/jira/browse/TUSCANY-2092 Project: Tuscany Issue Type: Bug Reporter: Greg Dritschler java.util.ConcurrentModificationException at java.util.AbstractList$SimpleListIterator.next(Unknown Source) at org.apache.tuscany.sca.contribution.service.ExtensibleContributionListener.contributionAdded(ExtensibleContributionListener.java:40) at org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.addContribution(ContributionServiceImpl.java:389) at org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.contribute(ContributionServiceImpl.java:202) The problem occurs if two threads try to add a contribution simultaneously. DefaultContributionListenerExtensionPoint does not synchronize the list of listeners. In particular loadListeners does not prevent multiple threads from trying to load the list of listeners. One thread completes first while the other is still loading. This leads to the exception shown above when a thread tries to iterate the listener list. -- 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]
[jira] Created: (TUSCANY-2069) Missing serialization in DirectedGraph
Missing serialization in DirectedGraph -- Key: TUSCANY-2069 URL: https://issues.apache.org/jira/browse/TUSCANY-2069 Project: Tuscany Issue Type: Bug Components: Java SCA Data Binding Runtime Affects Versions: Java-SCA-1.0.1 Reporter: Greg Dritschler I have a service with a web service binding that processes its input using an SDO. The service works fine with one client. It also works fine if it is driven once by one client and then driven by multiple clients. But if it is driven initially by multiple clients (2 is enough), various failures occur in org.apache.tuscany.sca.databinding.impl.DirectedGraph. It appears there is a lack of synchronization in this class. Failure 1 - NPE java.lang.NullPointerException at org.apache.tuscany.sca.databinding.impl.DirectedGraph$Node.access$400(DirectedGraph.java:188) at org.apache.tuscany.sca.databinding.impl.DirectedGraph.getShortestPath(DirectedGraph.java:314) at org.apache.tuscany.sca.databinding.DefaultTransformerExtensionPoint.getTransformerChain(DefaultTransformerExtensionPoint.java:302) at org.apache.tuscany.sca.databinding.impl.MediatorImpl.getTransformerChain(MediatorImpl.java:162) at org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate(MediatorImpl.java:76) at org.apache.tuscany.sca.core.databinding.transformers.Input2InputTransformer.transform(Input2InputTransformer.java:183) at org.apache.tuscany.sca.core.databinding.transformers.Input2InputTransformer.transform(Input2InputTransformer.java:59) at org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate(MediatorImpl.java:88) at org.apache.tuscany.sca.core.databinding.wire.DataTransformationInterceptor.transform(DataTransformationInterceptor.java:192) at org.apache.tuscany.sca.core.databinding.wire.DataTransformationInterceptor.invoke(DataTransformationInterceptor.java:89) at com.ibm.ws.soa.sca.runtime.impl.RuntimeExtensionManager.invokeNextInterceptor(RuntimeExtensionManager.java:211) at com.ibm.ws.soa.sca.runtime.impl.RuntimeExtensionManager.processMessage(RuntimeExtensionManager.java:96) at com.ibm.ws.soa.sca.runtime.impl.RuntimeTuscanyInterceptor.invoke(RuntimeTuscanyInterceptor.java:154) at org.apache.tuscany.sca.binding.ws.axis2.Axis2ServiceProvider.invokeTarget(Axis2ServiceProvider.java:852) at org.apache.tuscany.sca.binding.ws.axis2.Axis2ServiceInOutSyncMessageReceiver.invokeBusinessLogic(Axis2ServiceInOutSyncMessageReceiver.java:119) at org.apache.axis2.receivers.AbstractInOutSyncMessageReceiver.invokeBusinessLogic(AbstractInOutSyncMessageReceiver.java:42) at org.apache.axis2.receivers.AbstractMessageReceiver.receive(AbstractMessageReceiver.java:96) at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:147) at org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUtils.java:275) Failure 2 - timeout (code is probably looping) WTRN0124I: When the timeout occurred the thread with which the transaction is, or was most recently, associated was Thread[WebContainer : 0,5,main]. The stack trace of this thread when the timeout occurred was: java.util.HashMap.findNonNullKeyEntry(Unknown Source) java.util.HashMap.putImpl(Unknown Source) java.util.HashMap.put(Unknown Source) org.apache.tuscany.sca.databinding.impl.DirectedGraph.getShortestPath(DirectedGraph.java:296) org.apache.tuscany.sca.databinding.DefaultTransformerExtensionPoint.getTransformerChain(DefaultTransformerExtensionPoint.java:302) org.apache.tuscany.sca.databinding.impl.MediatorImpl.getTransformerChain(MediatorImpl.java:162) org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate(MediatorImpl.java:76) org.apache.tuscany.sca.core.databinding.transformers.Input2InputTransformer.transform(Input2InputTransformer.java:183) org.apache.tuscany.sca.core.databinding.transformers.Input2InputTransformer.transform(Input2InputTransformer.java:59) org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate(MediatorImpl.java:88) org.apache.tuscany.sca.core.databinding.wire.DataTransformationInterceptor.transform(DataTransformationInterceptor.java:192) org.apache.tuscany.sca.core.databinding.wire.DataTransformationInterceptor.invoke(DataTransformationInterceptor.java:89) com.ibm.ws.soa.sca.runtime.impl.RuntimeExtensionManager.invokeNextInterceptor(RuntimeExtensionManager.java:211) com.ibm.ws.soa.sca.runtime.impl.RuntimeExtensionManager.processMessage(RuntimeExtensionManager.java:96) com.ibm.ws.soa.sca.runtime.impl.RuntimeTuscanyInterceptor.invoke(RuntimeTuscanyInterceptor.java:154)
[jira] Created: (TUSCANY-1949) import.sdo element is not resolved if it follows a property element
import.sdo element is not resolved if it follows a property element --- Key: TUSCANY-1949 URL: https://issues.apache.org/jira/browse/TUSCANY-1949 Project: Tuscany Issue Type: Bug Components: Java SCA Assembly Model Affects Versions: Java-SCA-1.0 Reporter: Greg Dritschler Priority: Minor I have an SCA composite that uses both a property element and an import.sdo element. If the property element appears before the import.sdo element as shown below, then the application fails during execution when it tries to create an SDO. composite ... component ... property name=p type=xsd:stringXYZZY/property /component dbsdo:import.sdo .../ /composite If I reorder the elements as shown below then the application works. composite ... dbsdo:import.sdo .../ component ... property name=p type=xsd:stringXYZZY/property /component /composite I found the problem in CompositeProcessor. When a property element is found, it calls a method readPropertyValue. This method consumes the property end element so CompositeProcessor won't see it. Since CompositeProcessor does not see the property end element, it does not clear the property method variable. Then when it processes the import.sdo element, it sees the property variable is non-null and mistakenly associates the import.sdo extension with the property instead of with the composite. I was able to work around the problem by clearing the property variable after the readPropertyValue call as shown below. (There are actually two such calls, one for component level and one for composite level, and I cleared it in both cases.) // Read the property value Document value = readPropertyValue(property.getXSDElement(), property.getXSDType(), reader); property.setValue(value); composite.getProperties().add(property); property = null; // **WORKAROUND** -- 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]
[jira] Commented: (TUSCANY-1949) import.sdo element is not resolved if it follows a property element
[
https://issues.apache.org/jira/browse/TUSCANY-1949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12555995#action_12555995
]
Greg Dritschler commented on TUSCANY-1949:
--
Can property elements have extension elements? If not maybe the correct
solution is to remove the code that tries to associate extensions with
properties?
// Add the extension element to the current
// element
if (callback != null) {
callback.getExtensions().add(extension);
} else if (contract != null) {
contract.getExtensions().add(extension);
} else if (property != null) {
property.getExtensions().add(extension);
} else if (component != null) {
component.getExtensions().add(extension);
} else {
composite.getExtensions().add(extension);
}
import.sdo element is not resolved if it follows a property element
---
Key: TUSCANY-1949
URL: https://issues.apache.org/jira/browse/TUSCANY-1949
Project: Tuscany
Issue Type: Bug
Components: Java SCA Assembly Model
Affects Versions: Java-SCA-1.0
Reporter: Greg Dritschler
Priority: Minor
I have an SCA composite that uses both a property element and an import.sdo
element. If the property element appears before the import.sdo element as
shown below, then the application fails during execution when it tries to
create an SDO.
composite ...
component ...
property name=p type=xsd:stringXYZZY/property
/component
dbsdo:import.sdo .../
/composite
If I reorder the elements as shown below then the application works.
composite ...
dbsdo:import.sdo .../
component ...
property name=p type=xsd:stringXYZZY/property
/component
/composite
I found the problem in CompositeProcessor. When a property element is found,
it calls a method readPropertyValue. This method consumes the property end
element so CompositeProcessor won't see it. Since CompositeProcessor does
not see the property end element, it does not clear the property method
variable. Then when it processes the import.sdo element, it sees the
property variable is non-null and mistakenly associates the import.sdo
extension with the property instead of with the composite.
I was able to work around the problem by clearing the property variable after
the readPropertyValue call as shown below. (There are actually two such
calls, one for component level and one for composite level, and I cleared it
in both cases.)
// Read the property value
Document value =
readPropertyValue(property.getXSDElement(), property.getXSDType(), reader);
property.setValue(value);
composite.getProperties().add(property);
property = null; // **WORKAROUND**
--
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]
[jira] Updated: (TUSCANY-1765) Component implementation has wrong intent
[ https://issues.apache.org/jira/browse/TUSCANY-1765?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Greg Dritschler updated TUSCANY-1765: - Attachment: TUSCANY-1765.patch BaseJavaImplementationImpl.equals is modified to call its superclass ComponentType.equals. ComponentType.equals is modified to compare required intents. Component implementation has wrong intent - Key: TUSCANY-1765 URL: https://issues.apache.org/jira/browse/TUSCANY-1765 Project: Tuscany Issue Type: Bug Components: Java SCA Assembly Model Affects Versions: Java-SCA-0.99 Reporter: Greg Dritschler Priority: Minor Attachments: TUSCANY-1765.patch Suppose there is a composite with multiple components that use the same implementation class but different implementation intents, as shown below. composite xmlns=http://www.osoa.org/xmlns/sca/1.0; name=CompositeX component name=ComponentA implementation.java class=test.DataServiceImpl requires=managedTransaction.none/ /component component name=ComponentB implementation.java class=test.DataServiceImpl requires=managedTransaction.global/ /component /composite In this case the components will share a common Implementation model object because only the class name is being used to determine whether a component's implementation is the same as another's. This means one of the components will have the wrong implementation intents recorded in the model. -- 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]
[jira] Created: (TUSCANY-1765) Component implementation has wrong intent
Component implementation has wrong intent - Key: TUSCANY-1765 URL: https://issues.apache.org/jira/browse/TUSCANY-1765 Project: Tuscany Issue Type: Bug Components: Java SCA Assembly Model Affects Versions: Java-SCA-0.99 Reporter: Greg Dritschler Priority: Minor Suppose there is a composite with multiple components that use the same implementation class but different implementation intents, as shown below. composite xmlns=http://www.osoa.org/xmlns/sca/1.0; name=CompositeX component name=ComponentA implementation.java class=test.DataServiceImpl requires=managedTransaction.none/ /component component name=ComponentB implementation.java class=test.DataServiceImpl requires=managedTransaction.global/ /component /composite In this case the components will share a common Implementation model object because only the class name is being used to determine whether a component's implementation is the same as another's. This means one of the components will have the wrong implementation intents recorded in the model. -- 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]
[jira] Created: (TUSCANY-1554) Support alternate WorkScheduler implementations
Support alternate WorkScheduler implementations --- Key: TUSCANY-1554 URL: https://issues.apache.org/jira/browse/TUSCANY-1554 Project: Tuscany Issue Type: Improvement Components: Java SCA Core Runtime Affects Versions: Java-SCA-0.90 Reporter: Greg Dritschler Priority: Minor A patch is submitted that allows Tuscany's implementation of the WorkScheduler SPI, Jsr237WorkScheduler, to be plug-replaced by another implementation. The patch uses the mechanism created in revision 564364 which allows the implementations of registry objects to be created dynamically based on a metadata file. In order to simplify things, I took the position that the WorkManager is now a private implementation detail of the WorkScheduler. This avoids the need for the dynamic registry object creation mechanism to support a specialized WorkScheduler constructor. The only use of the WorkManager outside the WorkScheduler was a destroy() call in ReallySmallRuntime. I moved the destroy() method into the WorkScheduler interface. -- 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]
[jira] Updated: (TUSCANY-1554) Support alternate WorkScheduler implementations
[ https://issues.apache.org/jira/browse/TUSCANY-1554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Greg Dritschler updated TUSCANY-1554: - Attachment: Tuscany-1554.patch Support alternate WorkScheduler implementations --- Key: TUSCANY-1554 URL: https://issues.apache.org/jira/browse/TUSCANY-1554 Project: Tuscany Issue Type: Improvement Components: Java SCA Core Runtime Affects Versions: Java-SCA-0.90 Reporter: Greg Dritschler Priority: Minor Attachments: Tuscany-1554.patch A patch is submitted that allows Tuscany's implementation of the WorkScheduler SPI, Jsr237WorkScheduler, to be plug-replaced by another implementation. The patch uses the mechanism created in revision 564364 which allows the implementations of registry objects to be created dynamically based on a metadata file. In order to simplify things, I took the position that the WorkManager is now a private implementation detail of the WorkScheduler. This avoids the need for the dynamic registry object creation mechanism to support a specialized WorkScheduler constructor. The only use of the WorkManager outside the WorkScheduler was a destroy() call in ReallySmallRuntime. I moved the destroy() method into the WorkScheduler interface. -- 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]
[jira] Created: (TUSCANY-1242) Provide a runtime which supports multiple composites
Provide a runtime which supports multiple composites Key: TUSCANY-1242 URL: https://issues.apache.org/jira/browse/TUSCANY-1242 Project: Tuscany Issue Type: Improvement Components: Java SCA Standalone Runtime Reporter: Greg Dritschler The current runtime implementations are capable of starting a single composite only. This isn't very usable outside a standalone environment. -- 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]
[jira] Updated: (TUSCANY-1242) Provide a runtime which supports multiple composites
[ https://issues.apache.org/jira/browse/TUSCANY-1242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Greg Dritschler updated TUSCANY-1242: - Attachment: jira.patch The patch is a first step at providing a Tuscany runtime that supports multiple composites. I decided to break the logic in SimpleRuntimeImpl.start into separate methods for adding a contribution and deploying components. The method signatures are based on the way the code in SimpleRuntimeImpl.start() currently works. Clearly these aren't the method signatures we want in the end. However the code to support the contribution service and to resolve the model discrepancies is still in progress, so it is difficult to come up with better interfaces right at this moment. I also added methods to SimpleRuntimeImpl to support undeploying components and removing a contribution. Again I expect the signatures to evolve. I changed DefaultSCARuntime to call the new methods in SimpleRuntimeImpl appropriately. The names of these two classes perhaps are backwards -- DefaultSCARuntime perhaps should provide the basic runtime infrastructure and SimpleRuntimeImpl perhaps should be the class that provides a simple runtime capable of running one contribution. However I decided not to rename things at this point to make it easier to accept the patch. Other changes: * ContributionServiceImpl uses an ArtifactResolver to resolve artifacts in contributions. The problem is that the default implementation DefaultArtifactResolver doesn't know how to isolate artifacts by contribution. As a temporary workaround, I changed ContributionServiceImpl to use a transient DefaultArtifactResolver during resolution processing. Follow on work will be needed to work out the correct relationship between the ContributionService, a Contribution, and an ArtifactResolver. * BuilderRegistryImpl was using the ComponentManager to keep lists of SCAObjects and model objects for the deployer to be able to correlate them. These lists are really a temporary workaround for relating the different models. Furthermore the lists are transient and don't need to be kept after a deploy completes. For that reason I moved the lists from the ComponentManager to the DeploymentContext. I expect the lists will go away altogether when the model relationship issues are resolved. * I moved the code which sets up SimpleCompositeContextImpl from SimpleRuntimeImpl to DefaultSCARuntime. This is something that belongs on the thread of execution. DefaultSCARuntime knows the application is going to run on the current thread. SimpleRuntimeImpl shouldn't assume that. * I removed the tuscanySystem member variable in SimpleRuntimeImpl, which pointed to the single composite that start() handled before. Since the runtime has to handle more than one composite, this variable doesn't make sense anymore. I had to change some of the code that was using tuscanySystem to do component lookups. * I removed the use of SimpleRuntimeInfo which didn't seem to be serving much purpose anymore. Provide a runtime which supports multiple composites Key: TUSCANY-1242 URL: https://issues.apache.org/jira/browse/TUSCANY-1242 Project: Tuscany Issue Type: Improvement Components: Java SCA Standalone Runtime Reporter: Greg Dritschler Attachments: jira.patch The current runtime implementations are capable of starting a single composite only. This isn't very usable outside a standalone environment. -- 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]
[jira] Created: (TUSCANY-940) Test cases for scope, callback, oneway
Test cases for scope, callback, oneway -- Key: TUSCANY-940 URL: http://issues.apache.org/jira/browse/TUSCANY-940 Project: Tuscany Issue Type: Test Components: Java Spec APIs Affects Versions: Java-Mx Reporter: Greg Dritschler Submission of basic integration tests for @Scope, @Callback, @Oneway, and @Remotable. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-940) Test cases for scope, callback, oneway
[ http://issues.apache.org/jira/browse/TUSCANY-940?page=all ] Greg Dritschler updated TUSCANY-940: Attachment: itest.zip Test cases for scope, callback, oneway -- Key: TUSCANY-940 URL: http://issues.apache.org/jira/browse/TUSCANY-940 Project: Tuscany Issue Type: Test Components: Java Spec APIs Affects Versions: Java-Mx Reporter: Greg Dritschler Attachments: itest.zip Submission of basic integration tests for @Scope, @Callback, @Oneway, and @Remotable. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-936) HttpSessionScopeContainer requires a session to exist
HttpSessionScopeContainer requires a session to exist - Key: TUSCANY-936 URL: http://issues.apache.org/jira/browse/TUSCANY-936 Project: Tuscany Issue Type: Bug Components: Java SCA Core Affects Versions: Java-Mx Reporter: Greg Dritschler Priority: Minor In M1, the HttpSessionScopeContainer was able to lazy-initialize an HTTP session. (Look at the class LazyHTTPSessionId to see how it worked.) Now the HttpSessionScopeContainer requires a preexisting session. If a session does not exist, a NullPointerException occurs when it tries to look up the instance using a null key. InstanceWrapper ctx = wrappers.get(key); The problem can be circumvented by creating a session in the web app client. JSPs have sessions by default. Servlets can call getSession(true) to ensure a session exists before invoking an SCA component that requires session scope. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-921) wire element in SCDL causes UnrecognizedElementException
wire element in SCDL causes UnrecognizedElementException
--
Key: TUSCANY-921
URL: http://issues.apache.org/jira/browse/TUSCANY-921
Project: Tuscany
Issue Type: Bug
Components: Java SCA Core
Affects Versions: Java-Mx
Reporter: Greg Dritschler
Using a wire element in a composite results in an exception.
org.apache.tuscany.spi.loader.UnrecognizedElementException:
{http://www.osoa.org/xmlns/sca/1.0}wire
[{http://www.osoa.org/xmlns/sca/1.0}wire]
Context stack trace: [application]
at
org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistryImpl.java:90)
at
org.apache.tuscany.core.implementation.composite.CompositeLoader.load(CompositeLoader.java:81)
at
org.apache.tuscany.core.implementation.composite.CompositeLoader.load(CompositeLoader.java:55)
at
org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistryImpl.java:92)
at
org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistryImpl.java:109)
at
org.apache.tuscany.core.implementation.composite.CompositeComponentTypeLoader.loadFromSidefile(CompositeComponentTypeLoader.java:65)
at
org.apache.tuscany.core.implementation.composite.CompositeComponentTypeLoader.load(CompositeComponentTypeLoader.java:57)
at
org.apache.tuscany.core.implementation.composite.CompositeComponentTypeLoader.load(CompositeComponentTypeLoader.java:39)
at
org.apache.tuscany.core.loader.LoaderRegistryImpl.loadComponentType(LoaderRegistryImpl.java:159)
at
org.apache.tuscany.core.deployer.DeployerImpl.load(DeployerImpl.java:101)
at
org.apache.tuscany.core.deployer.DeployerImpl.deploy(DeployerImpl.java:76)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-922) Target instance is not cached in reference proxy
Target instance is not cached in reference proxy Key: TUSCANY-922 URL: http://issues.apache.org/jira/browse/TUSCANY-922 Project: Tuscany Issue Type: Bug Components: Java SCA Core Affects Versions: Java-Mx Reporter: Greg Dritschler Priority: Minor The invocation handler and target invoker have code to support caching the target instance to avoid doing a container lookup every time the target is invoked. However no code exists to turn caching on. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-923) @Scope(REQUEST) causes ScopeNotFoundException
@Scope(REQUEST) causes ScopeNotFoundException --- Key: TUSCANY-923 URL: http://issues.apache.org/jira/browse/TUSCANY-923 Project: Tuscany Issue Type: Bug Components: Java SCA Core Affects Versions: Java-Mx Reporter: Greg Dritschler Using @Scope(REQUEST) in an implementation class causes the following error at build time. [INFO] [INFO] Scope object factory not registered for scope [REQUEST] [INFO] [INFO] Trace org.apache.tuscany.spi.component.ScopeNotFoundException: Scope object factory not registered for scope [REQUEST] at org.apache.tuscany.core.component.scope.ScopeRegistryImpl.getScopeContainer(ScopeRegistryImpl.java:65) at org.apache.tuscany.core.implementation.java.JavaComponentBuilder.build(JavaComponentBuilder.java:75) at org.apache.tuscany.core.implementation.java.JavaComponentBuilder.build(JavaComponentBuilder.java:52) at org.apache.tuscany.core.builder.BuilderRegistryImpl.build(BuilderRegistryImpl.java:115) at org.apache.tuscany.core.implementation.composite.CompositeBuilder.build(CompositeBuilder.java:93) at org.apache.tuscany.core.builder.BuilderRegistryImpl.build(BuilderRegistryImpl.java:115) at org.apache.tuscany.core.deployer.DeployerImpl.build(DeployerImpl.java:115) at org.apache.tuscany.core.deployer.DeployerImpl.deploy(DeployerImpl.java:81) RequestScopeObjectFactory is not registering with the ScopeRegistry. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
