[jira] [Closed] (TUSCANY-4036) WSDL service names are duplicated when user does not provide WSDL
[ https://issues.apache.org/jira/browse/TUSCANY-4036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws closed TUSCANY-4036. --- Resolution: Fixed Fix Version/s: Java-SCA-2.0 Applied at revision: 1304746. Thanks for the patch Greg. WSDL service names are duplicated when user does not provide WSDL - Key: TUSCANY-4036 URL: https://issues.apache.org/jira/browse/TUSCANY-4036 Project: Tuscany Issue Type: Bug Affects Versions: Java-SCA-2.0 Reporter: Greg Dritschler Assignee: Simon Laws Priority: Minor Fix For: Java-SCA-2.0 Attachments: TUSCANY-4036.patch Scenario: An SCA composite has multiple components which * use binding.ws * do not provide a WSDL document via the wsdlElement attribute * implement the same Java interface In this case, for each web service binding, WSDLServiceGenerator takes the WSDL Definition that is generated by Interface2WSDLGenerator and adds a WSDL service and port to it. In this scenario where multiple components implement the same interface, the resulting WSDL services have the same definition namespace (which is derived from the Java package name) and the same local name (which is derived from the Java class name). This may make it difficult for the runtime to tailor the WSDL to support component-specific policy. This problem does not exist when the user does provide WSDL (either via wsdlElement or interface.wsdl). In that case WSDLServiceGenerator creates a new WSDL Definition with a modified namespace that includes the component name. This is possible because the generated WSDL can import the user's WSDL document. It is more difficult to do this in the problem scenario because WSDLServiceGenerator is already working with a generated document that has no physical location for the import to refer to. An alternate solution is for WSDLServiceGenerator to include the component name in the WSDL service name. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (TUSCANY-4033) Interface matching code in EndpointReferenceBinderImpl fails doing a wsdlgen
[
https://issues.apache.org/jira/browse/TUSCANY-4033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Laws closed TUSCANY-4033.
---
Resolution: Fixed
Fix Version/s: Java-SCA-2.0
Fix applied at revision: 1304327
Interface matching code in EndpointReferenceBinderImpl fails doing a wsdlgen
Key: TUSCANY-4033
URL: https://issues.apache.org/jira/browse/TUSCANY-4033
Project: Tuscany
Issue Type: Bug
Components: Java SCA Assembly Model
Affects Versions: Java-SCA-2.0
Reporter: Vijai Kalathur
Assignee: Simon Laws
Fix For: Java-SCA-2.0
If I have a service interface which does not contain a no-arg default
constructor and try to do a remote service invocation to that service, the
invocation fails when the haveMatchingInterfaceContracts method in
EndpointReferenceBinderImpl tries to generate a WSDL. Since the interface
does not contain a no-arg constructor, the wsdl gen fails. We might have to
update something in this check
if (endpointReferenceContract.getClass() !=
endpointContract.getClass() ||
endpointReferenceContract.getNormalizedWSDLContract() != null ||
endpointContract.getNormalizedWSDLContract() != null) {
endpointReferenceContract =
((RuntimeEndpointReference)endpointReference).getGeneratedWSDLContract(endpointReferenceContract);
endpointContract =
((RuntimeEndpoint)endpoint).getGeneratedWSDLContract(endpointContract);
}
to not generate the wsdl in certain cases.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (TUSCANY-4031) IntentNotSatisfiedAtBuild warning occurs when reference uses an intent provided by binding
[ https://issues.apache.org/jira/browse/TUSCANY-4031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws closed TUSCANY-4031. --- Resolution: Fixed Fix Version/s: Java-SCA-2.0 Applied at revision: 1304507. Thanks for the patch Greg. IntentNotSatisfiedAtBuild warning occurs when reference uses an intent provided by binding -- Key: TUSCANY-4031 URL: https://issues.apache.org/jira/browse/TUSCANY-4031 Project: Tuscany Issue Type: Bug Affects Versions: Java-SCA-2.0 Reporter: Greg Dritschler Assignee: Simon Laws Priority: Minor Fix For: Java-SCA-2.0 Attachments: TUSCANY-4031.patch ComponentPolicyBuilderImpl.checkIntentsResolved() checks when intents used by an Endpoint are provided by the binding. It should do the same for intents used by an EndpointReference. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (TUSCANY-4032) Remote getService() lookup with only component name fails when target has a callback
[ https://issues.apache.org/jira/browse/TUSCANY-4032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws closed TUSCANY-4032. --- Resolution: Fixed Fix Version/s: Java-SCA-2.0 Fix applied at revision: 1304510 Remote getService() lookup with only component name fails when target has a callback Key: TUSCANY-4032 URL: https://issues.apache.org/jira/browse/TUSCANY-4032 Project: Tuscany Issue Type: Bug Components: Java SCA Assembly Model Affects Versions: Java-SCA-2.0 Environment: All OS Reporter: Vijai Kalathur Assignee: Simon Laws Fix For: Java-SCA-2.0 If I deploy a composite with the following component component name=SCAJFrontendComponent implementation.java class=test.bindings.sca.FrontendImpl/ service name=FrontendService interface.java interface=test.bindings.sca.intf.FrontendService/ binding.sca / /service reference name=backendService target=SerializationBackendComponent interface.java interface=test.bindings.sca.intf.SerializeBackendService callbackInterface=test.bindings.sca.intf.SerializeCallback/ callback binding.sca / /callback /reference /component and try to do a getService lookup using just the component name on a different JVM, the lookup fails saying there are multiple services in the component and I need to specify a service name. The check in DefaultEndpointFinder to check if the endpoint service is a callback service doesn't seem to be working in the remote case. I think the code in the EndpointProcessor needs to be updated to include some attribute to indicate that the service is a callback service when it's getting serialized. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (TUSCANY-4035) Application could possibly fail to start if multiple threads are loading the same schema
[ https://issues.apache.org/jira/browse/TUSCANY-4035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws closed TUSCANY-4035. --- Resolution: Fixed Fix Version/s: Java-SCA-2.0 Applied at revision: 1304516. Thanks for the patch Kaushik. Application could possibly fail to start if multiple threads are loading the same schema Key: TUSCANY-4035 URL: https://issues.apache.org/jira/browse/TUSCANY-4035 Project: Tuscany Issue Type: Bug Reporter: Kaushik Mukherjee Assignee: Simon Laws Fix For: Java-SCA-2.0 Attachments: TUSCANY-4035v2.patch This was an issue in Tuscany 1.x and is likely an issue in the 2.x code as well. The fix in 1.x was to synchronize schema loading across all XSDModelResolvers. Starting multiple applications simultaneously can lead to an exception such as: org.apache.ws.commons.schema.XmlSchemaException: Schema name conflict in collection. Namespace: http://my.namespace at org.apache.ws.commons.schema.SchemaBuilder.handleXmlSchemaElement(SchemaBuilder.java:223) at org.apache.ws.commons.schema.SchemaBuilder.build(SchemaBuilder.java:202) at org.apache.ws.commons.schema.XmlSchemaCollection.read(XmlSchemaCollection.java:424) at org.apache.ws.commons.schema.XmlSchemaCollection.read(XmlSchemaCollection.java:347) at org.apache.ws.commons.schema.XmlSchemaCollection.read(XmlSchemaCollection.java:379) at org.apache.tuscany.sca.xsd.xml.XSDModelResolver.loadOnDemand(XSDModelResolver.java:204) at org.apache.tuscany.sca.xsd.xml.XSDModelResolver.aggregate(XSDModelResolver.java:240) at org.apache.tuscany.sca.xsd.xml.XSDModelResolver.resolveModel(XSDModelResolver.java:114) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (TUSCANY-4028) Don't duplicate intents in Java implementation model
[ https://issues.apache.org/jira/browse/TUSCANY-4028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws closed TUSCANY-4028. --- Resolution: Fixed Change committed at revision 1301369 Don't duplicate intents in Java implementation model Key: TUSCANY-4028 URL: https://issues.apache.org/jira/browse/TUSCANY-4028 Project: Tuscany Issue Type: Bug Components: SCA Java Runtime Affects Versions: Java-SCA-2.0-Beta3 Environment: All Reporter: Simon Laws Assignee: Simon Laws Fix For: Java-SCA-2.0 We have code in CompositeProcessor that caches intents and copies them back into the JavaImplementationModel. Add a check so that intents that are already present are not duplicated. I think this code is a hang over from when we used to share implementation models. If I remove it though I get test failures so for now I'm fixing the symptom. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (TUSCANY-4027) EndpointFinder is ineffective
[ https://issues.apache.org/jira/browse/TUSCANY-4027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws closed TUSCANY-4027. --- Resolution: Fixed Fix Version/s: Java-SCA-2.0 Thanks for the patch Greg, Committed at revision: 1299664 EndpointFinder is ineffective - Key: TUSCANY-4027 URL: https://issues.apache.org/jira/browse/TUSCANY-4027 Project: Tuscany Issue Type: Bug Affects Versions: Java-SCA-2.0 Reporter: Greg Dritschler Assignee: Simon Laws Priority: Minor Fix For: Java-SCA-2.0 Attachments: TUSCANY-4027.patch SCAClientFactoryImpl calls the EndpointFinder to find a matching endpoint. If the endpoint returned by EndpointFinder is local to the same JVM, SCAClientFactoryImpl then calls RuntimeComponentImpl.getServiceReference() which calls ComponentContextImpl.createSelfReference(). If the client's URI does not include a binding name, ComponentContextImpl picks the first binding. This supercedes whatever selection was made by the EndpointFinder. I am attaching a patch that fixes the issue. It constructs a full URI based on the selection made by the EndpointFinder and passes that to RuntimeComponentImpl.getServiceReference(). This exposed another issue. The scaclient-api itest tests that a getService() using component name only is rejected with a ServiceRuntimeException if the target component implements multiple services. This is because it is ambiguous which service is desired (SCAClientFactoryImpl does not do interface matching). This was being enforced in ComponentContextImpl, but with the above fix that isn't possible since it now gets a fully-specified URI. In order to fix this, I added a check into DefaultEndpointFinder. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (TUSCANY-4025) Give registry contribution listeners a chance to retireve the contribution info before removing it
[
https://issues.apache.org/jira/browse/TUSCANY-4025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Laws closed TUSCANY-4025.
---
Resolution: Fixed
Fix committed at revision: 1298469
Give registry contribution listeners a chance to retireve the contribution
info before removing it
--
Key: TUSCANY-4025
URL: https://issues.apache.org/jira/browse/TUSCANY-4025
Project: Tuscany
Issue Type: Bug
Components: SCA Java Runtime
Affects Versions: Java-SCA-2.0-Beta3
Environment: All
Reporter: Simon Laws
Assignee: Simon Laws
Fix For: Java-SCA-2.0
In our DomainRegistryImpl class we have
public void uninstallContribution(String uri) {
contributionDescriptions.remove(uri);
for (ContributionListener listener : contributionlisteners) {
listener.contributionRemoved(uri);
}
}
It should wait until the listeners have been called before removing the
contribution description.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (TUSCANY-3054) Introduce JavaInterfaceFactory impl employing caching of JavaInterface(s) based on Class
[ https://issues.apache.org/jira/browse/TUSCANY-3054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws closed TUSCANY-3054. --- Resolution: Fixed Fix Version/s: Java-SCA-1.x Been look at this with a view to copying the change to 2.x but it looks like we already do the caching that's cintained in ClassCachedJavaInterfaceFactory Introduce JavaInterfaceFactory impl employing caching of JavaInterface(s) based on Class Key: TUSCANY-3054 URL: https://issues.apache.org/jira/browse/TUSCANY-3054 Project: Tuscany Issue Type: Improvement Components: Java SCA Java Implementation Extension Reporter: Scott Kurz Priority: Minor Fix For: Java-SCA-1.x Nothing's broken .. just suggesting a better-performing impl. Will checkin shortly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (TUSCANY-4020) Still some hard coded message strings in the code
[ https://issues.apache.org/jira/browse/TUSCANY-4020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws closed TUSCANY-4020. --- Resolution: Fixed I've moved any hard coded messages I could find to properties files at revision: 1295144 Still some hard coded message strings in the code - Key: TUSCANY-4020 URL: https://issues.apache.org/jira/browse/TUSCANY-4020 Project: Tuscany Issue Type: Bug Components: SCA Java Runtime Affects Versions: Java-SCA-2.0-Beta3 Environment: All Reporter: Simon Laws Assignee: Simon Laws Fix For: Java-SCA-2.0 Some code still contains hard coded message strings. For example, see BaseAssemblyProcessor ComponentTypeDocumentProcessor CompositeDocumentProcessor CompositeProcessor -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (TUSCANY-4018) JMS TransportServiceInterceptor using wrong values to set JMS headers in producer
[ https://issues.apache.org/jira/browse/TUSCANY-4018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws closed TUSCANY-4018. --- Resolution: Fixed Committed at revision: 1291715. Thanks for the patch Jennifer. JMS TransportServiceInterceptor using wrong values to set JMS headers in producer - Key: TUSCANY-4018 URL: https://issues.apache.org/jira/browse/TUSCANY-4018 Project: Tuscany Issue Type: Bug Components: Java SCA JMS Binding Extension Affects Versions: Java-SCA-2.x Reporter: Jennifer A Thompson Assignee: Simon Laws Fix For: Java-SCA-2.x Attachments: Tuscany-4018.patch In TransportServiceInterceptor.invokeResponse is setting the effective TimeToLive, Priority in the response message, but when the values are set in the producer, the values from the request are used, potentially leading to an incorrect value. So the following: // Set jms header attributes in producer, not message. int deliveryMode = requestJMSMsg.getJMSDeliveryMode(); producer.setDeliveryMode(deliveryMode); int deliveryPriority = requestJMSMsg.getJMSPriority(); producer.setPriority(deliveryPriority); long timeToLive = requestJMSMsg.getJMSExpiration(); producer.setTimeToLive(timeToLive); Should be: // Set jms header attributes in producer, not message. producer.setDeliveryMode(responseJMSMsg.getJMSDeliveryMode()); producer.setPriority(responseJMSMsg.getJMSPriority()); producer.setTimeToLive(responseJMSMsg.getJMSExpiration()); -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (TUSCANY-3459) JSON-RPC (and other) binding fails if Interface is marked as remotable only in the composite
[
https://issues.apache.org/jira/browse/TUSCANY-3459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Laws closed TUSCANY-3459.
---
Resolution: Fixed
I applied the patch at revision: 1291191 which should provide a general
solution to this by allowing the interface remotable status to be overriden.
JSON-RPC (and other) binding fails if Interface is marked as remotable only
in the composite
-
Key: TUSCANY-3459
URL: https://issues.apache.org/jira/browse/TUSCANY-3459
Project: Tuscany
Issue Type: Bug
Components: Java SCA Integration Tests
Affects Versions: Java-SCA-2.x
Reporter: Luciano Resende
Assignee: Luciano Resende
Fix For: Java-SCA-2.x
Attachments: 3459.patch
public interface Catalog {
Item[] get();
}
component name=VegetablesCatalog
implementation.java class=services.sca.FruitsCatalogImpl/
service name=Catalog
interface.java interface=services.Catalog
remotable=true/
tuscany:binding.jsonrpc
uri=http://localhost:8085/VegetableCatalog; /
/service
/component
at $Proxy7.get(Unknown Source)
at services.sca.CatalogAggregatorImpl.get(CatalogAggregatorImpl.java:40)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at
org.apache.tuscany.sca.implementation.java.invocation.JavaImplementationInvoker.invoke(JavaImplementationInvoker.java:115)
at
org.apache.tuscany.sca.binding.sca.provider.SCABindingInvoker.invoke(SCABindingInvoker.java:61)
at
org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(JDKInvocationHandler.java:236)
at
org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(JDKInvocationHandler.java:106)
at $Proxy7.get(Unknown Source)
at
org.apache.tuscany.sca.performance.CatalogRemoteJsonRPCTest.testCatalog(CatalogRemoteJsonRPCTest.java:46)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
at junit.extensions.TestDecorator.run(TestDecorator.java:32)
at junit.extensions.RepeatedTest.run(RepeatedTest.java:30)
at com.clarkware.junitperf.ThreadedTest$TestRunner.run(Unknown Source)
at java.lang.Thread.run(Thread.java:637)
Caused by: org.jabsorb.serializer.UnmarshallException: element 0 no
serializer found that can unmarshall java.lang.String to services.Item
at
org.jabsorb.serializer.impl.ArraySerializer.unmarshall(ArraySerializer.java:216)
at org.jabsorb.JSONSerializer.unmarshall(JSONSerializer.java:692)
at org.jabsorb.client.Client.invoke(Client.java:226)
at org.jabsorb.client.Client.invoke(Client.java:156)
at
org.apache.tuscany.sca.binding.jsonrpc.provider.JSONRPCClientInvoker.invoke(JSONRPCClientInvoker.java:60)
at
org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(JDKInvocationHandler.java:236)
at
org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(JDKInvocationHandler.java:106)
... 27 more
Caused by: org.jabsorb.serializer.UnmarshallException: no serializer found
that can unmarshall java.lang.String to services.Item
at org.jabsorb.JSONSerializer.unmarshall(JSONSerializer.java:705)
at
org.jabsorb.serializer.impl.ArraySerializer.unmarshall(ArraySerializer.java:209)
... 33 more
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (TUSCANY-4016) NodeImpl startComposite forgets about a composite if there is a failure on start
[
https://issues.apache.org/jira/browse/TUSCANY-4016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Laws closed TUSCANY-4016.
---
Resolution: Fixed
Fix Version/s: Java-SCA-2.0
At revision: 1291234 I committed a fix and a test. On closer inspection it
turns out that we added code to the Activator a while back to stop providers if
there is a failure on start. So the extra stop added here may not do anything
but it won't do any harm. Moving the stopped composite to the stopped list does
allow the unused contributions to be unloaded if the appropriate operation is
called.
NodeImpl startComposite forgets about a composite if there is a failure on
start
Key: TUSCANY-4016
URL: https://issues.apache.org/jira/browse/TUSCANY-4016
Project: Tuscany
Issue Type: Bug
Components: SCA Java Runtime
Affects Versions: Java-SCA-2.0-Beta3
Environment: All
Reporter: Simon Laws
Assignee: Simon Laws
Fix For: Java-SCA-2.0
org.apache.tuscany.sca.impl.NodeImpl does the following on start
public void startComposite(String contributionURI, String compositeURI)
throws ActivationException, ValidationException, ContributionReadException {
String key = contributionURI+/+compositeURI;
if (startedComposites.containsKey(key)) {
throw new IllegalStateException(composite already started: +
compositeURI);
}
DeployedComposite dc = stoppedComposites.remove(key);
if (dc != null) {
dc.start();
startedComposites.put(key, dc);
and the following on stop
String key = contributionURI+/+compositeURI;
DeployedComposite dc = startedComposites.remove(key);
if (dc != null) {
dc.stop();
stoppedComposites.put(key, dc);
} else {
If an error is thrown on start it won't be in startedComposites but some of
the providers may have been started. So even in the failure case we should
consider the composite partially started so that it can be stopped correctly.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (TUSCANY-2735) Testing case where interface extends other that use Generics
[ https://issues.apache.org/jira/browse/TUSCANY-2735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws closed TUSCANY-2735. --- Resolution: Fixed Fix Version/s: Java-SCA-2.0 Patch applied to 2.x at revision: 1291283. Thanks Rodolfo. Testing case where interface extends other that use Generics Key: TUSCANY-2735 URL: https://issues.apache.org/jira/browse/TUSCANY-2735 Project: Tuscany Issue Type: Test Components: Java SCA Integration Tests Affects Versions: Java-SCA-1.3.2 Environment: Ubuntu, Tuscany SCA 1.3.2, jrockit_150_11 Reporter: Rodolfo Dias Assignee: Rodolfo Dias Priority: Minor Fix For: Java-SCA-2.0, Java-SCA-2.x Attachments: ServicesTest.diff, itest-services-1.3.2-JIRA-2735.jar, itest-services-1.3.2-src-jira-2735.jar Project itest-service not test case where interface extends other that use Generics. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (TUSCANY-3859) tuscany generated wsdl: namespace prefix for the attribute base is missing
[ https://issues.apache.org/jira/browse/TUSCANY-3859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws closed TUSCANY-3859. --- I believe this is fixed now as I applied the 1.x/TUSCANY-3298 fixes to 2.x and took the WSDL verify tests from 1.x and added them to the wsdlgen itest on 2.x. tuscany generated wsdl: namespace prefix for the attribute base is missing Key: TUSCANY-3859 URL: https://issues.apache.org/jira/browse/TUSCANY-3859 Project: Tuscany Issue Type: Bug Affects Versions: Java-SCA-1.6.1 Reporter: Antonio De Berardis Assignee: Simon Nash Fix For: Java-SCA-1.x I have a problem when I let tuscany generate the wsdl for a service. Namespace prefix for the attribute base is missing. If I have an object that extends another object, the schema generated should be: ... xs:complexType name=myObjChild xs:complexContent xs:extension base=tns:myObj ... but i got ... xs:complexType name=myObjChild xs:complexContent xs:extension base=myObj ... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (TUSCANY-3838) PolicyHandler.afterInvoke() is skipped when AxisFault occurs
[ https://issues.apache.org/jira/browse/TUSCANY-3838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws closed TUSCANY-3838. --- I believe this is fixed now. The policy runtime is slightly different in 2.x when compared to 1.x. In 2.x we have policy interceptors on the operation wire and on the binding wire and the binding wire providers get the opportunity to configure the binding. In the exception case the exception, wrapped in a Message object, should flow back along the wire and through the interceptors in the same way as a non-exception response does. PolicyHandler.afterInvoke() is skipped when AxisFault occurs Key: TUSCANY-3838 URL: https://issues.apache.org/jira/browse/TUSCANY-3838 Project: Tuscany Issue Type: Improvement Components: Java SCA Policy Affects Versions: Java-SCA-1.6 Environment: Windows 2003. Reporter: Gang Yang Assignee: Simon Nash Fix For: Java-SCA-1.x Attachments: code-snippet.txt When AxisFault is generated from invoking a remote service using WS binding, the reference side PolicyHandler.afterInvoke() is not called. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (TUSCANY-4015) JMSBindingProcessor's writeActivationSpecProperties uses wrong attribute name
[
https://issues.apache.org/jira/browse/TUSCANY-4015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Laws closed TUSCANY-4015.
---
Resolution: Fixed
Change comitted at r120. Thanks for the patch Vijai.
JMSBindingProcessor's writeActivationSpecProperties uses wrong attribute name
--
Key: TUSCANY-4015
URL: https://issues.apache.org/jira/browse/TUSCANY-4015
Project: Tuscany
Issue Type: Bug
Components: Java SCA JMS Binding Extension
Affects Versions: Java-SCA-2.x
Reporter: Vijai Kalathur
Assignee: Simon Laws
Attachments: JIRA-4015.patch
The writeActivationSpecProperties method in JMSBindingProcessor uses wrong
attribute name for activationSpec. It should be using jndiName instead of
name.
if ( asName != null asName.length() 0) {
writer.writeAttribute(name, asName);
}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (TUSCANY-4011) Callback binding gets overriden and other issues
[ https://issues.apache.org/jira/browse/TUSCANY-4011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws closed TUSCANY-4011. --- Resolution: Fixed Closing as change was committed at rev1242412 Callback binding gets overriden and other issues Key: TUSCANY-4011 URL: https://issues.apache.org/jira/browse/TUSCANY-4011 Project: Tuscany Issue Type: Bug Components: SCA Java Runtime Affects Versions: Java-SCA-2.0-Beta3 Environment: All Reporter: Simon Laws Fix For: Java-SCA-2.0 I've noticed that any callback binding configuration provided in the SCDL is not present when the binding is used. It's because the binding is overridden by the callback endpoint created by the service binding. Only the URI is required so we can take this out of the binding created by the service binding and set it on the callback binding. In trying to work out what was going on here I noticed a couple of other things that I'd like to improve: - The code here is complicated by the thought that a single CallbackServiceReference might be used to contact multiple callback endpoints. This is no longer the case. For STATELESS components a new set of callback proxies (and hence CallbackServiceReference) is created for each new incoming message, because that's what happens with STATELESS components. For COMPOSITE components a new callback proxy is created for each call through the RequestContext object. Hence there is always a new CallbackServiceReference instance for each incoming call and related callback target. I believe the current complexity can be removed so that the CallbackServiceReference only every refers to one callback endpoint - There is an opportunity for further optimization if a binding is prepared to be responsible for resetting it's reference target address in the callback case. For example, if we provide a field in the forward message where a service binding can place the callback URI then we can remove the EPR clone in the CallbackServiceReference and have the callback reference binding take the target address out of the callback message. This need a bit of thought so I'll open a separate JIRA for it when I get to looking at it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (TUSCANY-3932) Callbacks don't work in the distributed domain
[ https://issues.apache.org/jira/browse/TUSCANY-3932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws closed TUSCANY-3932. --- Resolution: Fixed Am closing this now as I think the specific issue is solved. I've opened TUSCANY-4011 as a follow up with some other callback issues/improvements Callbacks don't work in the distributed domain -- Key: TUSCANY-3932 URL: https://issues.apache.org/jira/browse/TUSCANY-3932 Project: Tuscany Issue Type: Bug Components: SCA Java Runtime Affects Versions: Java-SCA-2.0-Beta3 Environment: All Reporter: Simon Laws Assignee: Simon Laws Fix For: Java-SCA-2.0 The callback wire calculation currently requires knowledge of the service runtime. This will not be available in the distributed case where the Endpoint matched by and retrieved from the registry will not have a built runtime behind it. We need to refactor this based on the configuration available in the SCDL written to represent a remote Endpoint. Of particular interest is callback bindings that are generated vs callback bindings that are specified by the user. If a user specifies a binding this should automatically be available in the reference node as it will be written be default when the Endpoint is written out. Automatically generated callback bindings, usually generated to match the forward binding, won't be in that list and won't get written out so we need to address that. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (TUSCANY-4005) Ambiguous wire target is not reported as an error
[ https://issues.apache.org/jira/browse/TUSCANY-4005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws closed TUSCANY-4005. --- Resolution: Fixed Fix Version/s: Java-SCA-2.0 Change committed at revision: 1239597 Ambiguous wire target is not reported as an error - Key: TUSCANY-4005 URL: https://issues.apache.org/jira/browse/TUSCANY-4005 Project: Tuscany Issue Type: Bug Affects Versions: Java-SCA-2.0 Reporter: Greg Dritschler Assignee: Simon Laws Priority: Minor Fix For: Java-SCA-2.0 I have a component reference with a target that includes only a component name. reference name=xyz target=MultipleServiceComponent/ The target component has multiple services. According to the following text in the assembly specification, the target component must have one and only one service with a compatible interface. 1844 If service-name is not present, the target component MUST have one and only 1845 one service with an interface that is a compatible superset of the wire source's 1845 interface and satisifies the policy requirements of the wire source, and the SCA 1846 runtime MUST use this service for the wire. [ASM60048] This implies to me that if there are multiple services with compatible interfaces, I should get an error. This does not happen. Instead the first match is taken. It's unclear to me why there needs to be only one match. If there are multiple matches that satisfy the interface and the policy requirements, it seems like using any of the matches is just as good. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (TUSCANY-3910) Ensure that JAX-WS wrapper generation occurs before databinding introspection to avoid need for @RequestWrapper, etc. to set databinding
[ https://issues.apache.org/jira/browse/TUSCANY-3910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws closed TUSCANY-3910. --- Resolution: Fixed Fix Version/s: Java-SCA-2.0 Reversed the order of the processors and applied changes similar to those from TUSCANY-3804 at revision: 1229088 Ensure that JAX-WS wrapper generation occurs before databinding introspection to avoid need for @RequestWrapper, etc. to set databinding Key: TUSCANY-3910 URL: https://issues.apache.org/jira/browse/TUSCANY-3910 Project: Tuscany Issue Type: Improvement Components: SCA Java Runtime Affects Versions: Java-SCA-2.0 Reporter: Scott Kurz Assignee: Simon Laws Fix For: Java-SCA-2.0 Say I have a wrapped-style WSDL interface which I want to map to Java intf: Node greetDOM(Node name); Our databinding introspection will correctly mark the input/output with DOMDataBinding. The JAXWSJavaInterfaceProcessor will generate the wrappers since they are not already present from the Java perspective. Then there is some more function in WrapperJavaInterfaceProcessor to promote the parm/returnVal databindings to the wrapper-level databindings. However, while in 1.x this always ran after the wrappers were generated, in 2.x the order isn't so determined because of the way we factored out the addition of the interface processors. So the user has to ensure the JAX-WS annotations are present and that they specify the databinding (via the className), which is a pain to add manually if he doesn't have a tool to do it, e.g.: @RequestWrapper(localName = greetDOM, targetNamespace = http://intf.privatecopy.itest/;, className = org.w3c.dom.Node) @ResponseWrapper(localName = greetDOMResponse, targetNamespace = http://intf.privatecopy.itest/;, className = org.w3c.dom.Node) Node greetDOM(Node name); We seem to need an ordering so that the WrapperJavaInterfaceProcessor runs after JAXWSJavaInterfaceProcessor. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (TUSCANY-4004) WSDL import handling creates definitions where the URI is set to the location which is different from the top level models
[
https://issues.apache.org/jira/browse/TUSCANY-4004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Laws closed TUSCANY-4004.
---
Resolution: Fixed
At revision: 1229110 I made a small change to maintain the coherence of WSDL
URI and location for imported WSDL documents.
WSDL import handling creates definitions where the URI is set to the location
which is different from the top level models
--
Key: TUSCANY-4004
URL: https://issues.apache.org/jira/browse/TUSCANY-4004
Project: Tuscany
Issue Type: Improvement
Components: SCA Java Runtime
Affects Versions: Java-SCA-2.0-Beta3
Environment: All
Reporter: Simon Laws
Assignee: Simon Laws
Priority: Minor
Fix For: Java-SCA-2.0
There is code in WSDLModelResolver.resolveImports()
if
(unresolved.getNamespace().equals(resolved.getDefinition().getTargetNamespace()))
{
resolved.setNamespace(resolved.getDefinition().getTargetNamespace());
resolved.setUnresolved(false);
resolved.setURI(resolved.getLocation());
return modelClass.cast(resolved);
That puts the absolute location in the (usually relative) URI field. This was
causing me some confusion when debugging another issue as the imported WSDL
definition was constructed differently form the top level WSDL definition. I
don't know whether the imported WSDL absolutely must have this URI file set
to the location or whether it's just that the contribution relative URI is
not readily available in the part of the code.
As an aside, while looking that this, I notices that in
WSDLModelResolver.loadDefinition() there is a loop over the imports in order
to resolve the WSDLDefinition. All the unresolved definitions are represented
by the same WSDLDefinition object and the unresolved object becomes the
resolved object. This is likely to end in tears if there is more than one
import.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (TUSCANY-4000) WS binding: ClassCastException: org.apache.tuscany.sca.interfacedef.wsdl.impl.WSDLInterfaceImpl incompatible with org.apache.tuscany.sca.interfacedef.java.JavaInterface
[
https://issues.apache.org/jira/browse/TUSCANY-4000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Laws closed TUSCANY-4000.
---
Resolution: Fixed
Fix Version/s: Java-SCA-2.0
Fix committed at revision: 1228143
WS binding: ClassCastException:
org.apache.tuscany.sca.interfacedef.wsdl.impl.WSDLInterfaceImpl incompatible
with org.apache.tuscany.sca.interfacedef.java.JavaInterface
Key: TUSCANY-4000
URL: https://issues.apache.org/jira/browse/TUSCANY-4000
Project: Tuscany
Issue Type: Bug
Components: Java SCA Axis Binding Extension
Affects Versions: Java-SCA-2.0-Beta3
Reporter: Rashmi Hunt
Assignee: Simon Laws
Fix For: Java-SCA-2.0
WS Binding reference with WSDL interface with a WSDL callback interface
---invoking--- WS Binding Service with WSDL interface with a WSDL callback
interface
throws ClassCastException when Tuscany tries to cast WSDLInterfaceImpl to
JavaInterface
at JavaImplementationInvoker.invoke() method, at
(JavaInterface)interfaze.getCallbackInterface()
// If there is a callback interface and the implementation is
stateless, we need to
// inject callbacks at invocation time. For Composite scope, this
has already been done.
if (( interfaze.getCallbackInterface() != null )
(scopeContainer.getScope().equals(Scope.STATELESS))){
injectCallbacks(wrapper,
(JavaInterface)interfaze.getCallbackInterface());
}
This exception occurs when Web Service message reaches service implementation
which eventually invokes
JavaImplementationInvoker.invoke()
The above code is assuming that interfaze.getCallbackInterface() will return
instance of JavaInterface.
What if the callback interface on both service and reference are using WSDL
interface?
Shouldn't above logic take care of WSDL interface case?
Exception stack,
Caused by: java.lang.ClassCastException:
org.apache.tuscany.sca.interfacedef.wsdl.impl.WSDLInterfaceImpl incompatible
with org.apache.tuscany.sca.interfacedef.java.JavaInterface
at
org.apache.tuscany.sca.implementation.java.invocation.JavaImplementationInvoker.invoke(JavaImplementationInvoker.java:117)
...
at
org.apache.tuscany.sca.core.invocation.InterceptorAsyncImpl.invoke(InterceptorAsyncImpl.java:58)
at
org.apache.tuscany.sca.core.invocation.RuntimeInvoker.invoke(RuntimeInvoker.java:126)
at
org.apache.tuscany.sca.core.invocation.RuntimeInvoker.invoke(RuntimeInvoker.java:109)
at
org.apache.tuscany.sca.core.assembly.impl.RuntimeEndpointImpl.invoke(RuntimeEndpointImpl.java:328)
components,
component name=MyComponent
implementation.java class=samples.MyServiceImpl/
service name=MyService
interface.wsdl
interface=http://www.mybank.com/account#wsdl.interface(MyService)
callbackInterface=http://www.mybank.com/account#wsdl.interface(MyServiceCallback)
/
binding.ws
wsdlElement=http://www.mybank.com/account#wsdl.port(MyService/MyServicePort)
/
callback
binding.ws name=MyServiceCallback/
/callback
/service
/component
component name=MySummaryService
implementation.java class=samples.MySummaryServiceImpl/
reference name=myService
interface.wsdl
interface=http://www.mybank.com/account#wsdl.interface(MyService)
callbackInterface=http://www.mybank.com/account#wsdl.interface(MyServiceCallback)
/
binding.ws
wsdlElement=http://www.mybank.com/account#wsdl.port(MyService/MyServicePort)
/
callback
binding.ws
wsdlElement=http://www.mybank.com/account#wsdl.binding(MyServiceCallback)/
/callback
/reference
/component
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (TUSCANY-4003) Allow ResourceHost to be specified
[ https://issues.apache.org/jira/browse/TUSCANY-4003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws closed TUSCANY-4003. --- Resolution: Fixed Fix Version/s: Java-SCA-2.0 Thanks for the patch Brian. I made a small change by moving the ResourceHost impl into implementation-java rather than interface-java. Committed at revision: 1228143 Allow ResourceHost to be specified --- Key: TUSCANY-4003 URL: https://issues.apache.org/jira/browse/TUSCANY-4003 Project: Tuscany Issue Type: Improvement Affects Versions: Java-SCA-2.0 Reporter: Brian Sullivan Assignee: Simon Laws Fix For: Java-SCA-2.0 Attachments: patches.zip Allow ResourceHost to be specified for SDO Helper Context resource injection. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (TUSCANY-3890) Port TUSCANY-2931 Allow for separate request and response wireFormats in binding.jms to 2.x
[ https://issues.apache.org/jira/browse/TUSCANY-3890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws closed TUSCANY-3890. --- Resolution: Fixed Committed at revision: 1213702 Port TUSCANY-2931 Allow for separate request and response wireFormats in binding.jms to 2.x - Key: TUSCANY-3890 URL: https://issues.apache.org/jira/browse/TUSCANY-3890 Project: Tuscany Issue Type: Sub-task Components: SCA Java Runtime Reporter: Simon Laws Assignee: Simon Laws Fix For: Java-SCA-2.0 TUSCANY-2931 Allow for separate request and response wireFormats in binding.jms was added to 1.x after the 2.x branch was taken. Needs porting. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (TUSCANY-3890) Port TUSCANY-2931 Allow for separate request and response wireFormats in binding.jms to 2.x
[ https://issues.apache.org/jira/browse/TUSCANY-3890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws closed TUSCANY-3890. --- Resolution: Fixed I'm closing this issue now as TUSCANY-3654 has been resolved and the separate request/response wire formats of that test work. The changes in 2.x were not as extensive as those in 1.x. Primarily OperationImpl in 2.x does not present separate request/response Wrapper fields. This is somewhat mute though because I don't believe we have a scenario where the request wrapper has a different databinding from the response wrapper (we certainly have the case there the request has a wrapper and the response doesn't and vice versa). Port TUSCANY-2931 Allow for separate request and response wireFormats in binding.jms to 2.x - Key: TUSCANY-3890 URL: https://issues.apache.org/jira/browse/TUSCANY-3890 Project: Tuscany Issue Type: Sub-task Components: SCA Java Runtime Reporter: Simon Laws Fix For: Java-SCA-2.0 TUSCANY-2931 Allow for separate request and response wireFormats in binding.jms was added to 1.x after the 2.x branch was taken. Needs porting. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (TUSCANY-3996) Relative binding URIs not handled correctly when non-default root is specified
[
https://issues.apache.org/jira/browse/TUSCANY-3996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Laws closed TUSCANY-3996.
---
Resolution: Fixed
fixed at revision: 1212386
Relative binding URIs not handled correctly when non-default root is specified
--
Key: TUSCANY-3996
URL: https://issues.apache.org/jira/browse/TUSCANY-3996
Project: Tuscany
Issue Type: Bug
Components: SCA Java Runtime
Affects Versions: Java-SCA-2.x
Environment: All
Reporter: Simon Laws
Assignee: Simon Laws
Priority: Minor
Fix For: Java-SCA-2.x
There is code in the BindingURIBuilder as follows
if (baseURI == null) {
if (componentURI == null) {
if (bindingURI != null) {
uriString = name + / + bindingURI.toString();
} else {
uriString = name;
}
} else {
if (bindingURI != null) {
if (bindingURI.toString().startsWith(/)) {
uriString =
componentURI.resolve(bindingURI).toString();
} else {
uriString = componentURI.resolve(name + / +
bindingURI).toString();
}
} else {
uriString = componentURI.resolve(name).toString();
}
}
} else {
if (componentURI == null) {
if (bindingURI != null) {
uriString = basedURI(baseURI, bindingURI).toString();
} else {
uriString = basedURI(baseURI,
URI.create(name)).toString();
}
} else {
if (bindingURI != null) {
uriString = basedURI(baseURI,
componentURI.resolve(bindingURI)).toString();
} else {
uriString = basedURI(baseURI,
componentURI.resolve(name)).toString();
}
}
}
Note that the branch where baseURI is non-null behaves differently w.r.t.
adding name to the final URI compared to when baseURI is null.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (TUSCANY-3993) otest pom.xml needs to point to apache snapshots repo
[ https://issues.apache.org/jira/browse/TUSCANY-3993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws closed TUSCANY-3993. --- Resolution: Fixed Fixed at revision: 1212399. Thanks for the suggested change Tom. otest pom.xml needs to point to apache snapshots repo - Key: TUSCANY-3993 URL: https://issues.apache.org/jira/browse/TUSCANY-3993 Project: Tuscany Issue Type: Bug Components: Java SCA Verification Tests Affects Versions: Java-SCA-2.0-M4 Reporter: Tom Seelbach Assignee: Simon Laws Priority: Minor Need to change the incubating-repo to snapshots repo Index: pom.xml === --- pom.xml (revision 1211541) +++ pom.xml (working copy) @@ -30,8 +30,13 @@ repositories repository -idapache.incubator/id -urlhttp://people.apache.org/repo/m2-incubating-repository/url + idapache.snapshots/id + nameApache Snapshot Repository/name + + urlhttp://repository.apache.org/snapshots/url + releases +enabledfalse/enabled + /releases /repository /repositories -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (TUSCANY-3946) Capability to skip setting TCCL in JavaImplementationInvoker.invoke()
[ https://issues.apache.org/jira/browse/TUSCANY-3946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws closed TUSCANY-3946. --- Resolution: Fixed I've had a bit of a change of heart about this one. I'm concerned that putting extra doPrivileged checks in the main message flow is going to have a negative impact on performance so I've swapped out that code so a check on the presence of a message header does the job now. If you want to set TCCL earlier in the chain add Constants.SUPPRESS_TCCL_SWAP to the message header and the implementation invoker won't try and repeat the process. Capability to skip setting TCCL in JavaImplementationInvoker.invoke() - Key: TUSCANY-3946 URL: https://issues.apache.org/jira/browse/TUSCANY-3946 Project: Tuscany Issue Type: Improvement Components: SCA Java Runtime Affects Versions: Java-SCA-2.x Reporter: Jennifer A Thompson Assignee: Simon Laws Fix For: Java-SCA-2.x Setting the TCCL in the JavaImplementationInvoker can interfere with runtimes extending the Tuscany OASIS runtime. So there should be a mechanism for products extending the runtime to be able to skip setting the TCCL in JavaImplementationInvoker.invoke(). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (TUSCANY-3965) In a Service Implementation annotated with @Service, it's unannonated properties should not be introspected
[
https://issues.apache.org/jira/browse/TUSCANY-3965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Laws closed TUSCANY-3965.
---
Resolution: Fixed
I've uploaded the updates OASIS JCI tests so I'm closing this issue now.
In a Service Implementation annotated with @Service, it's unannonated
properties should not be introspected
---
Key: TUSCANY-3965
URL: https://issues.apache.org/jira/browse/TUSCANY-3965
Project: Tuscany
Issue Type: Bug
Components: Java SCA Assembly Model
Affects Versions: Java-SCA-2.0-Beta1
Environment: All
Reporter: Hasan Muhammad
Priority: Critical
Fix For: Java-SCA-2.x
I was trying to deploy a composite which has component implementing a java
implementation annotated with @Service which has the following field
@Service(TestOasis.class)
public class TestOasisImpl implements TestOasis {
@DefaultHelperContext
protected HelperContext helperContext;
This is not a property as it clearly does not have a @Property annotation and
hence the composite definition does not define this property. However, the
validation is logging this as an error as follows
[Composite: {http://docs.oasis-open.org/ns/opencsa/sca/200912}, Component:
SDOSimpleServiceJavaSerOasis] - No type specified on component property:
Component = SDOSimpleServiceJavaSerOasis Property = helperContext
This is coming from org.apache.tuscany.sca.builder.impl.ComponentBuilderImpl
and the message ID is NoTypeForComponentProperty
This validation is too strict and we should ignore properties defined in
Service class which are not annotated with @Property. The CI spec section 8.1
appears to confirm to this deduction.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (TUSCANY-3988) Cloned component shares same policy provider list as original component causing duplicated policy providers
[
https://issues.apache.org/jira/browse/TUSCANY-3988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Laws closed TUSCANY-3988.
---
Resolution: Fixed
Greg's suggested fix applied at revision: 1210470. Thanks Greg. I added a test
case also.
Cloned component shares same policy provider list as original component
causing duplicated policy providers
---
Key: TUSCANY-3988
URL: https://issues.apache.org/jira/browse/TUSCANY-3988
Project: Tuscany
Issue Type: Bug
Affects Versions: Java-SCA-2.0
Reporter: Greg Dritschler
Assignee: Simon Laws
Priority: Minor
Scenario: A composite X has multiple implementation.composite components
that point to the same composite Y.
Problem: Components in Y have duplicated implementation policy providers.
Detailed explanation: CompositeCloneBuilderImpl clones each occurrence of Y
which clones the components under it. However RuntimeComponentImpl does not
have a clone method, so its policy provider list is simply copied to the
clone. When CompositeActivatorImpl creates implementation policy providers
for each component in Y, it is not updating a unique list, but rather a list
that is shared with the other clones, causing the duplication.
Proposed solution: Add a clone method to RuntimeComponentImpl that
initializes a new policy provider list.
@Override
public Object clone() throws CloneNotSupportedException {
RuntimeComponentImpl clone = (RuntimeComponentImpl)super.clone();
clone.policyProviders = new ArrayListPolicyProvider();
return clone;
}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (TUSCANY-3916) When we pass interface descriptions via the registry is must be complete or the target node must be provided with a mechanism for retrieving the interface
[
https://issues.apache.org/jira/browse/TUSCANY-3916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Laws closed TUSCANY-3916.
---
Resolution: Fixed
A while back at 1167202 the WSDL representation was changed for an internal
representation that serializes the internal Tuscany model to XML which looks
like:
wstxns1:interfaceContract
xmlns:wstxns1=http://tuscany.apache.org/xmlns/sca/1.1;
wstxns1:interface isRemotable=true
wstxns1:operation name=foo1 isDynamic=false
isNonBlocking=false isWrapperStyle=false
wstxns1:input
wstxns1:dataType dataBinding=java:complexType
wstxns1:genericclass
org.apache.tuscany.sca.itest.interfaces.ParameterObject/wstxns1:generic
wstxns1:logicalXMLType
wstxns1:xmlTypeNoType/wstxns1:xmlType
/wstxns1:logicalXMLType
wstxns1:physicalorg.apache.tuscany.sca.itest.interfaces.ParameterObject/wstxns1:physical
/wstxns1:dataType
wstxns1:dataType dataBinding=java:simpleType
wstxns1:genericclass java.lang.String/wstxns1:generic
wstxns1:logicalXMLType
wstxns1:xmlType{http://www.w3.org/2001/XMLSchema}string/wstxns1:xmlType
/wstxns1:logicalXMLType
wstxns1:physicaljava.lang.String/wstxns1:physical
/wstxns1:dataType
/wstxns1:input
wstxns1:output
wstxns1:dataType dataBinding=java:simpleType
wstxns1:genericclass java.lang.String/wstxns1:generic
wstxns1:logicalXMLType
wstxns1:xmlType{http://www.w3.org/2001/XMLSchema}string/wstxns1:xmlType
/wstxns1:logicalXMLType
wstxns1:physicaljava.lang.String/wstxns1:physical
/wstxns1:dataType
/wstxns1:output
wstxns1:fault /
/wstxns1:operation
etc.
I'll close this issue now as this format doesn't depend on imports or any
resolution in remote nodes.
When we pass interface descriptions via the registry is must be complete or
the target node must be provided with a mechanism for retrieving the interface
--
Key: TUSCANY-3916
URL: https://issues.apache.org/jira/browse/TUSCANY-3916
Project: Tuscany
Issue Type: Bug
Components: SCA Java Runtime
Affects Versions: Java-SCA-2.0
Environment: All
Reporter: Simon Laws
Fix For: Java-SCA-2.0
We are currently add function to serializing WSDL documents via the registry
but those WSDL serializations can have includes/imports that the remote node
won't be able to satisfy.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (TUSCANY-3963) SCA client reference binding vaue should have special characters to denote it is not an actual reference URI
[ https://issues.apache.org/jira/browse/TUSCANY-3963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws closed TUSCANY-3963. --- Resolution: Fixed Patch applied at revision: 1209143. Thanks Jennifer. SCA client reference binding vaue should have special characters to denote it is not an actual reference URI Key: TUSCANY-3963 URL: https://issues.apache.org/jira/browse/TUSCANY-3963 Project: Tuscany Issue Type: Improvement Components: SCA Java Runtime Affects Versions: Java-SCA-2.x Reporter: Jennifer A Thompson Assignee: Simon Laws Priority: Minor Fix For: Java-SCA-2.x Attachments: TUSCANY-3963.patch Original Estimate: 1h Remaining Estimate: 1h In the sca-client-impl module the RemoteServiceInvocationHandler.createEndpointReference method creates a dummy reference value to set for the reference name prepended with the string sca.client: componentReference.setName(sca.client. + service.getName()); However, it is possible that sca.client could be in the name of an actual reference/serice, so I'm suggesting we use $sca.client$. rather than the existing string to avoid any conflicts/confusion in debugging. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (TUSCANY-3924) Inherited fields in service impl classes are treated as Properties
[ https://issues.apache.org/jira/browse/TUSCANY-3924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws closed TUSCANY-3924. --- Resolution: Fixed Fixed Inherited fields in service impl classes are treated as Properties -- Key: TUSCANY-3924 URL: https://issues.apache.org/jira/browse/TUSCANY-3924 Project: Tuscany Issue Type: Bug Components: Java SCA Assembly Model Affects Versions: Java-SCA-2.x Reporter: Vijai Kalathur Fix For: Java-SCA-2.x In the scenario where the Service impl class extends a class which has no SCA annotations in it, protected fields in the base class are interpreted like Properties. Ideally, only the fields in the impl class should be introspected for References/Properties. The fields in the base class should not be interpreted as References/Properties if there are no SCA annotations. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (TUSCANY-3966) Duplicate message ID in contribution-validation-messages.properties
[ https://issues.apache.org/jira/browse/TUSCANY-3966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws closed TUSCANY-3966. --- Resolution: Fixed Fixed Duplicate message ID in contribution-validation-messages.properties --- Key: TUSCANY-3966 URL: https://issues.apache.org/jira/browse/TUSCANY-3966 Project: Tuscany Issue Type: Bug Components: Java SCA Problem Determination Affects Versions: Java-SCA-2.0-Beta1 Reporter: Hasan Muhammad Priority: Trivial There is a duplicate message ID in contribution-validation-messages.properties under contribution\src\main\resources The ID is AttributeCannotBeProcessed -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (TUSCANY-3958) Intents are not available for remote endpoints
[ https://issues.apache.org/jira/browse/TUSCANY-3958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws closed TUSCANY-3958. --- Resolution: Fixed Code added at revision: 1185135 to serialize the Endpoint intents and policy sets. They are stashed on the component element at write and retrieved to the Endpoint model on read. Intents are not available for remote endpoints -- Key: TUSCANY-3958 URL: https://issues.apache.org/jira/browse/TUSCANY-3958 Project: Tuscany Issue Type: Bug Affects Versions: Java-SCA-2.0 Reporter: Greg Dritschler Assignee: Simon Laws In a distributed environment, remote endpoints obtained from the domain registry do not have their required intents. This may cause the reference to not provide the correct behavior required by the intents. Presumably the RuntimeEndpointImpl.writeExternal() should write the intents and RuntimeEndpointImpl.readExternal() should read (and resolve?) them. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (TUSCANY-3959) Intent matching is not performed for intents that may be provided by the binding
[
https://issues.apache.org/jira/browse/TUSCANY-3959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Laws closed TUSCANY-3959.
---
Resolution: Fixed
Fix Version/s: Java-SCA-2.0
Change committed at revision: 1185139
Intent matching is not performed for intents that may be provided by the
binding
Key: TUSCANY-3959
URL: https://issues.apache.org/jira/browse/TUSCANY-3959
Project: Tuscany
Issue Type: Bug
Affects Versions: Java-SCA-2.0
Reporter: Greg Dritschler
Assignee: Simon Laws
Fix For: Java-SCA-2.0
EndpointReferenceBinderImpl.haveMatchingPolicy() matches the intents
specified on a reference bindiing to those specified on a potential target
service binding. For some reason, it skips over intents that may be provided
by the binding.
} else if (bindingType != null
bindingType.getMayProvidedIntents().contains(intent)){
eprIntents.remove(intent);
Even though the binding provides the intent when requested to do so, it still
should be matched. It doesn't make sense to allow the client to tell the
reference binding to do something if the service binding isn't doing the same
thing. Note that this applies only to interaction intents. Implementation
intents (such as transactedOneWay) SHOULD NOT be matched. So the above logic
should be changed such that:
a) if the intent is an interaction intent, remove it if the endpoint also has
the endpoint
b) if the intent is an implementation intent, remove it
** NOTE ** TUSCANY-3958 must be addressed before this JIRA. TUSCANY-3958
reports that intents are not present in a remote endpoint. Obviously we have
to fix getting the intents in remote endpoints before we fix matching them.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (TUSCANY-3900) Enhance EquinoxServiceDiscoverer to use bundle trackers
[ https://issues.apache.org/jira/browse/TUSCANY-3900?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws closed TUSCANY-3900. --- Resolution: Fixed Committed at revision: 1185144. Thanks for the patch Greg. Enhance EquinoxServiceDiscoverer to use bundle trackers --- Key: TUSCANY-3900 URL: https://issues.apache.org/jira/browse/TUSCANY-3900 Project: Tuscany Issue Type: Improvement Affects Versions: Java-SCA-2.0 Reporter: Greg Dritschler Priority: Minor Fix For: Java-SCA-2.0 Attachments: TUSCANY-3900.patch Each time that the EquinoxServiceDiscoverer is called to find a service, it obtains the list of bundles in the bundle context and filters them to identify the Tuscany bundle providers. This could be improved by using a bundle tracker to maintain a list of matching bundles. There actually is some bundle tracker code in the class but it is unused. I am attaching a patch to utilize the bundle tracker. The patch creates two bundle trackers, one for all bundles and one for the Tuscany service providing bundles. I changed getBundles() to get the list of bundles from the appropriate tracker rather than the bundle context. There are open questions in the code about what state a bundle should be in to be considered. I tried to maintain compatibility with the existing filtering code (isProviderBundle) which accepts all states except UNINSTALLED. Therefore I changed the bundle tracker constructor to include all bundle states except UNINSTALLED. I removed the check in addingBundle() for a STOPPED event because this was not a criteria used in isProviderBundle(). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (TUSCANY-3960) Port JSR250 annotation processing over from 1.x
[ https://issues.apache.org/jira/browse/TUSCANY-3960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws closed TUSCANY-3960. --- Resolution: Fixed Port JSR250 annotation processing over from 1.x --- Key: TUSCANY-3960 URL: https://issues.apache.org/jira/browse/TUSCANY-3960 Project: Tuscany Issue Type: Improvement Components: SCA Java Runtime Affects Versions: Java-SCA-2.0-Beta3 Environment: All Reporter: Simon Laws Assignee: Simon Laws Fix For: Java-SCA-2.0 AFAICT we haven't ported over the JSR250 annotation support yet. There is a complication here in that we must decide what to do with implementation level operation policy configuration. I'll populate the implementation level operation list and see if that works out. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (TUSCANY-3961) EndpointReferenceBuilder relies on internal exception throwing
[
https://issues.apache.org/jira/browse/TUSCANY-3961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Laws closed TUSCANY-3961.
---
Resolution: Fixed
EndpointReferenceBuilder relies on internal exception throwing
--
Key: TUSCANY-3961
URL: https://issues.apache.org/jira/browse/TUSCANY-3961
Project: Tuscany
Issue Type: Improvement
Components: SCA Java Runtime
Affects Versions: Java-SCA-2.0-Beta3
Environment: All
Reporter: Simon Laws
Assignee: Simon Laws
Fix For: Java-SCA-2.0
The EndpointReferenceBuilderImpl uses this code when it's trying to decide if
a target is a domain target or not.
try {
getSCATargetParts(uri);
// the target uri might be an SCA target so create an
endpoint
// so that the binder can test it against the fully
populated
// registry
endpoint = createEndpoint(component, uri);
if (binding instanceof SCABinding) {
// TUSCANY-3941
// if it's an SCA binding we store it to
influence the matching at runtime
endpointRef.setBinding(binding);
}
endpointRef.setStatus(EndpointReference.Status.WIRED_TARGET_IN_BINDING_URI);
} catch (Exception ex) {
// the target string definitely isn't an SCA target
string
// so we can assume here that the user has configured
a
// resolved binding
endpoint = createEndpoint(false);
endpoint.setURI(uri);
endpoint.setBinding(binding);
endpointRef.setStatus(EndpointReference.Status.RESOLVED_BINDING);
}
Seems a bit missleading and I want change so we don't rely on internal
exception throwing.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (TUSCANY-3922) Java 2 Access Control exception originating from Interface2WSDLGenerator.init, JavaBeansDataBinding.copy, JAXBContextCache.getPackages, JavaImplementationInvoker.invok
[ https://issues.apache.org/jira/browse/TUSCANY-3922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws closed TUSCANY-3922. --- Resolution: Fixed Patch applies back at r1158793 . Thanks for the patch Jennifer. Java 2 Access Control exception originating from Interface2WSDLGenerator.init, JavaBeansDataBinding.copy, JAXBContextCache.getPackages, JavaImplementationInvoker.invoke -- Key: TUSCANY-3922 URL: https://issues.apache.org/jira/browse/TUSCANY-3922 Project: Tuscany Issue Type: Bug Components: SCA Java Runtime Affects Versions: Java-SCA-2.x Reporter: Jennifer A Thompson Assignee: Simon Laws Priority: Minor Fix For: Java-SCA-2.x Attachments: TUSCANY-3922.patch Original Estimate: 1h Remaining Estimate: 1h The following methods are experiencing getClassLoader : Access denied (java.lang.RuntimePermission getClassLoader) exceptions when running with Java2 Security enabled: 1) at org.apache.tuscany.sca.implementation.java.invocation.JavaImplementationInvoker.invoke(JavaImplementationInvoker.java:97) 2) at org.apache.tuscany.sca.databinding.javabeans.JavaBeansDataBinding.copy(JavaBeansDataBinding.java:91) 3) at org.apache.tuscany.sca.databinding.jaxb.JAXBContextCache.getPackages(JAXBContextCache.java:475) And java.security.AccessControlException: Access denied (java.io.FilePermission filename read) originating from: 1) at org.apache.tuscany.sca.binding.ws.wsdlgen.Interface2WSDLGenerator.init(Interface2WSDLGenerator.java:121) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (TUSCANY-3945) Expose RuntimeEndpointImpl.getPromotedComponent() as a public interface.
[ https://issues.apache.org/jira/browse/TUSCANY-3945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws closed TUSCANY-3945. --- Resolution: Fixed Fix Version/s: Java-SCA-2.0 Fixed back at r1170998 Expose RuntimeEndpointImpl.getPromotedComponent() as a public interface. Key: TUSCANY-3945 URL: https://issues.apache.org/jira/browse/TUSCANY-3945 Project: Tuscany Issue Type: New Feature Components: SCA Java Runtime Affects Versions: Java-SCA-2.x Reporter: Jennifer A Thompson Assignee: Simon Laws Priority: Minor Fix For: Java-SCA-2.0 Original Estimate: 1h Remaining Estimate: 1h In order to calculate component URI for nested components RuntimeEndpointImpl.getPromotedComponent() should be exposed as a public interface. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (TUSCANY-3887) AccessControlException in EquinoxServiceDiscoverer with Java2 security enabled
[ https://issues.apache.org/jira/browse/TUSCANY-3887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws closed TUSCANY-3887. --- Resolution: Fixed Looks like Brent committed this at r1140741 AccessControlException in EquinoxServiceDiscoverer with Java2 security enabled -- Key: TUSCANY-3887 URL: https://issues.apache.org/jira/browse/TUSCANY-3887 Project: Tuscany Issue Type: Bug Affects Versions: Java-SCA-2.0 Reporter: Greg Dritschler Priority: Minor Fix For: Java-SCA-2.0 Attachments: TUSCANY-3887.patch An AccessControlException occurs when a client program calls SCAClientFactory, if a security manager is enabled and the EquinoxServiceDiscoverer is in use. java.security.AccessControlException: Access denied (org.osgi.framework.AdminPermission (id=1) metadata) at java.security.AccessController.checkPermission(AccessController.java:108) at java.lang.SecurityManager.checkPermission(SecurityManager.java:544) at com.ibm.ws.security.core.SecurityManager.checkPermission(SecurityManager.java:208) at org.eclipse.osgi.framework.internal.core.Framework.checkAdminPermission(Framework.java:1177) at org.eclipse.osgi.framework.internal.core.AbstractBundle.getHeaders(AbstractBundle.java:943) at org.eclipse.osgi.framework.internal.core.AbstractBundle.getHeaders(AbstractBundle.java:901) at org.apache.tuscany.sca.extensibility.equinox.EquinoxServiceDiscoverer.isProviderBundle(EquinoxServiceDiscoverer.java:218) at org.apache.tuscany.sca.extensibility.equinox.EquinoxServiceDiscoverer.getBundles(EquinoxServiceDiscoverer.java:242) at org.apache.tuscany.sca.extensibility.equinox.EquinoxServiceDiscoverer.getServiceDeclarations(EquinoxServiceDiscoverer.java:274) at org.apache.tuscany.sca.extensibility.ServiceDiscovery.getServiceDeclarations(ServiceDiscovery.java:107) at org.apache.tuscany.sca.extensibility.ServiceDiscovery.getServiceDeclarations(ServiceDiscovery.java:165) at org.apache.tuscany.sca.extensibility.ServiceDiscovery.getServiceDeclaration(ServiceDiscovery.java:224) at org.apache.tuscany.sca.core.DefaultExtensionPointRegistry.getExtensionPoint(DefaultExtensionPointRegistry.java:105) at org.apache.tuscany.sca.core.context.impl.ComponentContextImpl.getInterfaceContract(ComponentContextImpl.java:471) at org.apache.tuscany.sca.core.context.impl.ComponentContextImpl.createEndpointReference(ComponentContextImpl.java:416) at org.apache.tuscany.sca.core.context.impl.ComponentContextImpl.createEndpointReference(ComponentContextImpl.java:392) at org.apache.tuscany.sca.core.context.impl.ComponentContextImpl.createSelfReference(ComponentContextImpl.java:300) at org.apache.tuscany.sca.core.context.impl.ComponentContextImpl.createSelfReference(ComponentContextImpl.java:254) at org.apache.tuscany.sca.core.assembly.impl.RuntimeComponentImpl.getServiceReference(RuntimeComponentImpl.java:154) at org.apache.tuscany.sca.client.impl.SCAClientFactoryImpl.getService(SCAClientFactoryImpl.java:90) EquinoxServiceDiscoverer.getServiceDeclarations() needs to use a doPriviledged block to avoid requiring the client to have osgi permissions. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
