[jira] [Assigned] (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 reassigned TUSCANY-4036: --- Assignee: Simon Laws > 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 > 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] [Assigned] (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 reassigned TUSCANY-4035: --- Assignee: Simon Laws > 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 > 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] [Assigned] (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 reassigned TUSCANY-4032: --- Assignee: Simon Laws > 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 > > If I deploy a composite with the following component > > > > interface="test.bindings.sca.intf.FrontendService"/> > > > target="SerializationBackendComponent"> > interface="test.bindings.sca.intf.SerializeBackendService" > callbackInterface="test.bindings.sca.intf.SerializeCallback"/> > > > > > > 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] [Assigned] (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 reassigned TUSCANY-4031: --- Assignee: Simon Laws > 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] [Assigned] (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 reassigned TUSCANY-4033:
---
Assignee: Simon Laws
> 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] [Assigned] (TUSCANY-4030) AccessControlException when trying to read schemas with Java 2 security enabled
[
https://issues.apache.org/jira/browse/TUSCANY-4030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Laws reassigned TUSCANY-4030:
---
Assignee: Simon Laws
> AccessControlException when trying to read schemas with Java 2 security
> enabled
> ---
>
> Key: TUSCANY-4030
> URL: https://issues.apache.org/jira/browse/TUSCANY-4030
> Project: Tuscany
> Issue Type: Bug
>Reporter: Kaushik Mukherjee
>Assignee: Simon Laws
> Attachments: TUSCANY-4030v3.patch
>
>
> I believe we need to wrap line 183 in the XSDModelResolver with an
> AccessController.doPrivileged so we can read a schema when java 2 security is
> enabled. Working on a patch now.
> InputSource xsd = null;
> final XSDefinition finaldef = definition;
> try {
> try {
> xsd = (InputSource) AccessController.doPrivileged(new
> PrivilegedExceptionAction() {
> public InputSource run() throws IOException {
> return
> XMLDocumentHelper.getInputSource(finaldef.getLocation().toURL());
> }
> });
> } catch (PrivilegedActionException e) {
> throw (IOException) e.getException();
> }
> } catch (IOException e) {
> throw new ContributionRuntimeException(e);
> }
> java.security.AccessControlException: Access denied (java.io.FilePermission
> C:\WAS\was85a\profiles\AppSrv01\installedAssets\sdoscope-shared-oasis.jar\BASE\sdoscope-shared-oasis.jar
> read)
> at
> java.security.AccessController.checkPermission(AccessController.java:132)
> at java.lang.SecurityManager.checkPermission(SecurityManager.java:544)
> at
> com.ibm.ws.security.core.SecurityManager.checkPermission(SecurityManager.java:208)
> at java.lang.SecurityManager.checkRead(SecurityManager.java:883)
> at java.util.zip.ZipFile.(ZipFile.java:145)
> at java.util.jar.JarFile.(JarFile.java:149)
> at java.util.jar.JarFile.(JarFile.java:86)
> at sun.net.www.protocol.jar.URLJarFile.(URLJarFile.java:84)
> at sun.net.www.protocol.jar.URLJarFile.getJarFile(URLJarFile.java:60)
> at sun.net.www.protocol.jar.JarFileFactory.get(JarFileFactory.java:92)
> at
> sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:119)
> at
> sun.net.www.protocol.jar.JarURLConnection.getInputStream(JarURLConnection.java:147)
> at
> org.apache.tuscany.sca.common.xml.XMLDocumentHelper.openStream(XMLDocumentHelper.java:139)
> at
> org.apache.tuscany.sca.common.xml.XMLDocumentHelper.getInputSource(XMLDocumentHelper.java:129)
> at
> org.apache.tuscany.sca.xsd.xml.XSDModelResolver.loadOnDemand(XSDModelResolver.java:183)
> at
> org.apache.tuscany.sca.xsd.xml.XSDModelResolver.aggregate(XSDModelResolver.java:224)
> at
> org.apache.tuscany.sca.xsd.xml.XSDModelResolver.resolveModel(XSDModelResolver.java:123)
> at
> org.apache.tuscany.sca.contribution.resolver.ExtensibleModelResolver.resolveModel(ExtensibleModelResolver.java:154)
--
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] [Assigned] (TUSCANY-4034) More memory leak fixes
[ https://issues.apache.org/jira/browse/TUSCANY-4034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws reassigned TUSCANY-4034: --- Assignee: Simon Laws > More memory leak fixes > -- > > Key: TUSCANY-4034 > URL: https://issues.apache.org/jira/browse/TUSCANY-4034 > Project: Tuscany > Issue Type: Bug >Affects Versions: Java-SCA-2.0-Beta3 > Environment: All >Reporter: Simon Laws >Assignee: Simon Laws > Fix For: Java-SCA-2.0 > > > Plugging variuous potential memory leaks. -- 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] [Assigned] (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 reassigned TUSCANY-4028: --- Assignee: Simon Laws > 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] [Assigned] (TUSCANY-4027) EndpointFinder is ineffective
[ https://issues.apache.org/jira/browse/TUSCANY-4027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws reassigned TUSCANY-4027: --- Assignee: Simon Laws > 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 > 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] [Assigned] (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 reassigned TUSCANY-4025:
---
Assignee: Simon Laws
> 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] [Assigned] (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 reassigned TUSCANY-4020: --- Assignee: Simon Laws > 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] [Assigned] (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 reassigned TUSCANY-4018: --- Assignee: Simon Laws > 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] [Assigned] (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 reassigned TUSCANY-4016:
---
Assignee: Simon Laws
> 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
>
> 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] [Assigned] (TUSCANY-4017) Tuscany needs to process profile intents as in OSOA
[ https://issues.apache.org/jira/browse/TUSCANY-4017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws reassigned TUSCANY-4017: --- Assignee: Simon Laws > Tuscany needs to process profile intents as in OSOA > --- > > Key: TUSCANY-4017 > URL: https://issues.apache.org/jira/browse/TUSCANY-4017 > Project: Tuscany > Issue Type: Bug > Components: Java SCA Policy >Affects Versions: Java-SCA-2.0-Beta3 >Reporter: Rashmi Hunt >Assignee: Simon Laws > Fix For: Java-SCA-2.x > > > In OASIS Tuscany implementation, 'exactlyOnce' intent is returned as is when > I tried to get intent name > from PolicySubject. > In OSOA Tuscany, if 'exactlyOnce' intent is defined in the composite, Tuscany > used to return it as > 'atleastOnce'/'atMostOnce' as intent name ( > PolicyComputationUtils.expandProfileIntents()) , which > seems to be missing in OASIS implementation -- 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] [Assigned] (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 reassigned TUSCANY-4015:
---
Assignee: Simon Laws
> 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] [Assigned] (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 reassigned TUSCANY-4005: --- Assignee: Simon Laws > 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 > > I have a component reference with a target that includes only a component > name. > > 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 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] [Assigned] (TUSCANY-4006) Intent transactedOneWay with an interface that has both one-way and two-way methods should be allowed
[ https://issues.apache.org/jira/browse/TUSCANY-4006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws reassigned TUSCANY-4006: --- Assignee: Simon Laws > Intent transactedOneWay with an interface that has both one-way and two-way > methods should be allowed > - > > Key: TUSCANY-4006 > URL: https://issues.apache.org/jira/browse/TUSCANY-4006 > Project: Tuscany > Issue Type: Bug > Components: Java SCA Assembly Model >Affects Versions: Java-SCA-2.0-M1 > Environment: All >Reporter: Hasan Muhammad >Assignee: Simon Laws > Fix For: Java-SCA-2.x > > > This is a bug in CompositePolicyBuilderImpl.validateTransactionIntents(). It > is failing the use of transactedOneWay with an interface that has both > one-way and two-way methods. This is allowed; transactedOneWay applies only > to the one-way methods. (It's conceptually the same as > propagatesTransaction, which by definition applies to the two-way methods and > is ignored for one-way methods.) The check should be deleted. -- 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] [Assigned] (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 reassigned TUSCANY-3924: --- Assignee: Simon Laws > 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 >Assignee: Simon Laws > 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] [Assigned] (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 reassigned TUSCANY-4004:
---
Assignee: Simon Laws
> 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] [Assigned] (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 reassigned TUSCANY-3910: --- Assignee: Simon Laws (was: Scott Kurz) > 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 > > 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] [Assigned] (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 reassigned TUSCANY-4003: --- Assignee: Simon Laws > 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 > 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] [Assigned] (TUSCANY-4000) WS binding: ClassCastException: org.apache.tuscany.sca.interfacedef.wsdl.impl.WSDLInterfaceImpl incompatible with org.apache.tuscany.sca.interfacedef.java.JavaInterfac
[
https://issues.apache.org/jira/browse/TUSCANY-4000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Laws reassigned TUSCANY-4000:
---
Assignee: Simon Laws
> 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
>
> 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,
>
>
>
> interface="http://www.mybank.com/account#wsdl.interface(MyService)"
>
> callbackInterface="http://www.mybank.com/account#wsdl.interface(MyServiceCallback)"
> />
>
>
> wsdlElement="http://www.mybank.com/account#wsdl.port(MyService/MyServicePort)"
>/>
>
>
>
>
>
>
>
>
>interface="http://www.mybank.com/account#wsdl.interface(MyService)"
>
> callbackInterface="http://www.mybank.com/account#wsdl.interface(MyServiceCallback)"
> />
>
> wsdlElement="http://www.mybank.com/account#wsdl.port(MyService/MyServicePort)"
> />
>
> wsdlElement="http://www.mybank.com/account#wsdl.binding(MyServiceCallback)"/>
>
>
>
--
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] [Assigned] (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 reassigned TUSCANY-3993: --- Assignee: Simon Laws > 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 @@ > > > > -apache.incubator > -http://people.apache.org/repo/m2-incubating-repository > + apache.snapshots > + Apache Snapshot Repository > + > + http://repository.apache.org/snapshots > + > +false > + > > > -- 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] [Assigned] (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 reassigned TUSCANY-3996:
---
Assignee: Simon Laws
> 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] [Assigned] (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 reassigned TUSCANY-3988:
---
Assignee: Simon Laws
> 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 ArrayList();
> 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] [Assigned] (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 reassigned TUSCANY-3963:
---
Assignee: Simon Laws
> 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] [Assigned] (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 reassigned TUSCANY-3965:
---
Assignee: Simon Laws
> 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
>Assignee: Simon Laws
>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] [Assigned] (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 reassigned TUSCANY-3959:
---
Assignee: Simon Laws
> 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
>
> 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] [Assigned] (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 reassigned TUSCANY-3958: --- Assignee: Simon Laws > 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] [Assigned] (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 reassigned TUSCANY-3961:
---
Assignee: Simon Laws
> 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] [Assigned] (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 reassigned TUSCANY-3960: --- Assignee: Simon Laws > 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
