[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] [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] [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] [Reopened] (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 reopened TUSCANY-3924: - Reopening as I didn't answer the JSR250 question 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] [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] [Closed] (TUSCANY-4002) Updates to JMSBindingContext JMSBindingProcessor to allow for additional extensions.
[ https://issues.apache.org/jira/browse/TUSCANY-4002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ant elder closed TUSCANY-4002. -- Resolution: Fixed Patches applied, thanks for the updates Jenniifer Updates to JMSBindingContext JMSBindingProcessor to allow for additional extensions. --- Key: TUSCANY-4002 URL: https://issues.apache.org/jira/browse/TUSCANY-4002 Project: Tuscany Issue Type: Improvement Components: Java SCA JMS Binding Extension Affects Versions: Java-SCA-2.x Reporter: Jennifer A Thompson Fix For: Java-SCA-2.x Attachments: JMSBindingContext.patch, JMSBindingProcessor-resolve.patch The following updates should be made to allow the JMS Binding to allow for additional extensions: 1) Add a HashTable to JMSBindingContext which allow extensions to set/get java.lang.Object based upon a string key. 2) Update JMSBindingProcessor.read() to allow for the extension processor to resolve models for wireformats and operation selectors. -- 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-3992) AccessControlException occurs when calling SCAClientFactory.getService
[ https://issues.apache.org/jira/browse/TUSCANY-3992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ant elder closed TUSCANY-3992. -- Resolution: Fixed Patch applied, thanks for the fix Greg. AccessControlException occurs when calling SCAClientFactory.getService -- Key: TUSCANY-3992 URL: https://issues.apache.org/jira/browse/TUSCANY-3992 Project: Tuscany Issue Type: Bug Affects Versions: Java-SCA-2.0 Reporter: Greg Dritschler Priority: Minor Attachments: TUSCANY-3992.patch If a Java2 security manager is active, an application's call to SCAClientFactory.getService() may fail with an AccessControlException. java.security.AccessControlException: Access denied (java.lang.RuntimePermission accessDeclaredMembers) at java.security.AccessController.checkPermission(AccessController.java:108) at java.lang.SecurityManager.checkPermission(SecurityManager.java:544) at java.lang.SecurityManager.checkMemberAccess(SecurityManager.java:1689) at java.lang.Class.checkMemberAccess(Class.java:107) at java.lang.Class.getDeclaredMethods(Class.java:675) at org.apache.tuscany.sca.interfacedef.java.impl.JavaIntrospectionHelper.getMethods(JavaIntrospectionHelper.java:621) at org.apache.tuscany.sca.interfacedef.java.impl.JavaInterfaceIntrospectorImpl.introspectInterface(JavaInterfaceIntrospectorImpl.java:150) at org.apache.tuscany.sca.interfacedef.java.impl.JavaInterfaceFactoryImpl.createJavaInterface(JavaInterfaceFactoryImpl.java:80) at org.apache.tuscany.sca.interfacedef.java.impl.JavaInterfaceFactoryImpl.createJavaInterface(JavaInterfaceFactoryImpl.java:56) at org.apache.tuscany.sca.core.context.impl.ComponentContextImpl.getInterfaceContract(ComponentContextImpl.java:472) at org.apache.tuscany.sca.core.context.impl.ComponentContextImpl.createEndpointReference(ComponentContextImpl.java:423) at org.apache.tuscany.sca.core.context.impl.ComponentContextImpl.createEndpointReference(ComponentContextImpl.java:399) 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:134) at org.apache.tuscany.sca.client.impl.SCAClientFactoryImpl.getService(SCAClientFactoryImpl.java:98) I have attached a patch that resolves the problem. -- 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-3998) Provide a way to override Tuscany system definition.xml documents
[ https://issues.apache.org/jira/browse/TUSCANY-3998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ant elder closed TUSCANY-3998. -- Resolution: Fixed Patches applied, thanks for the fix Greg. Provide a way to override Tuscany system definition.xml documents --- Key: TUSCANY-3998 URL: https://issues.apache.org/jira/browse/TUSCANY-3998 Project: Tuscany Issue Type: Improvement Affects Versions: Java-SCA-2.0 Reporter: Greg Dritschler Assignee: ant elder Priority: Minor Attachments: TUSCANY-3998-revised.patch A Tuscany embedder may need to change certain system definitions, e.g. a bindingType or an implementationType. System definitions are found using the ServiceDiscovery mechanism. DefaultDefinitionsExtensionPoint looks for jars/bundles that have a META-INF/services/org.apache.tuscany.sca.definitions.xml.Definitions file. definitionsDeclarations = registry.getServiceDiscovery().getServiceDeclarations(DEFINITIONS_FILE); This collects all definitions documents in the runtime. There is no way to override one definitions document with another. I am attaching a patch to address this. It changes the getServiceDeclarations() call to get declarations in ranked order. When processing the returned declarations, it now processes only the first resource with a given path. The embedder's service declaration must use the same resource name as the Tuscany definition it replaces and it must have a higher ranking attribute. -- 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
