[jira] Commented: (TUSCANY-2388) Data binding does not work when Java interface implementation (where method param is not String, primitive) exposed with a web services binding
[
https://issues.apache.org/jira/browse/TUSCANY-2388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12604421#action_12604421
]
Scott Kurz commented on TUSCANY-2388:
-
This looks like it should work, since though your MoreComplexObject doesn't
have JAXB annotations, it does follow the JavaBean pattern with
getters/setters. I tried on r666142 and it seemed to work for me.
Data binding does not work when Java interface implementation (where method
param is not String, primitive) exposed with a web services binding
--
Key: TUSCANY-2388
URL: https://issues.apache.org/jira/browse/TUSCANY-2388
Project: Tuscany
Issue Type: Bug
Components: Java SCA Data Binding Runtime
Affects Versions: Java-SCA-1.1
Environment: Windows XP; IBM J2RE 1.5.0 (Build 2.3)
Reporter: Peter Kemp
Attachments: testcase.zip
1. Create a component with a java implementation, with a service defined by a
Java interface.
The parameter to the method is not a String, primitive or wrapper - rather,
it's a class containing a couple of Strings and an Integer.
2. Expose the service with a webservice binding.
3. Deploy the composite (as a WAR or embedded).
4. Retrieve the WSDL for the service (eg from
http://localhost:8080/SomeServices?wsdl).
5. Generate a web service request from the WSDL.
The runtime fails to map the web service request message to the
implementation class method parameters - it calls the correct method, but the
method parameter is null.
The test works fine when the parameter is a String.
Composite definition (some.composite):
---
?xml version=1.0 encoding=UTF-8?
composite xmlns=http://www.osoa.org/xmlns/sca/1.0;
targetNamespace=http://test; xmlns:test=http://test; name=some
service name=SomeServices promote=SomeServicesComponent
binding.ws uri=http://localhost:8080/SomeServices/
/service
component name=SomeServicesComponent
implementation.java class=service.SomeServiceImpl/
service name=SomeService
interface.java interface=service.SomeService /
/service
/component
/composite
Service interface:
---
/**
*
*/
package service;
import org.osoa.sca.annotations.Remotable;
@Remotable
public interface SomeService {
public AnObject getUsingString(String stringParam);
public AnObject getUsingMoreComplexObject(MoreComplexObject
moreComplexParam);
}
Implementation:
--
package service;
import org.osoa.sca.annotations.Service;
@Service(SomeService.class)
public class SomeServiceImpl implements SomeService {
public AnObject getUsingString(String stringParam) {
System.out.println(Param value: + stringParam);
return getAnObject(stringParam);
}
private AnObject getAnObject(String stringParam) {
// TODO Auto-generated method stub
return new AnObject(stringParam + 123, 123);
}
public AnObject getUsingMoreComplexObject(MoreComplexObject
moreComplexParam) {
System.out.println(Param value: +
moreComplexParam.getStringParam());
return getAnObject(moreComplexParam.getStringParam());
}
}
MoreComplexObject.java
---
/**
*
*/
package service;
import java.io.Serializable;
public class MoreComplexObject implements Serializable{
private static final long serialVersionUID = 43242314234123L;
private String stringParam;
private Integer intParam;
private String stringParam2;
public String getStringParam() {
return stringParam;
}
public void setStringParam(String stringParam) {
this.stringParam = stringParam;
}
public Integer getIntParam() {
return intParam;
}
public void setIntParam(Integer intParam) {
this.intParam = intParam;
}
public String getStringParam2() {
return stringParam2;
}
public void setStringParam2(String stringParam2) {
this.stringParam2 = stringParam2;
}
}
AnObject.java
-
package service;
public class AnObject {
private String someRetValue;
private Integer someOtherRetValue;
public AnObject() {
}
public AnObject(String someRetValue, Integer someOtherRetValue) {
this.someRetValue = someRetValue;
this.someOtherRetValue = someOtherRetValue;
}
/**
* @return the someOtherRetValue
*/
public Integer getSomeOtherRetValue() {
return someOtherRetValue;
}
/**
* @param someOtherRetValue the
[jira] Commented: (TUSCANY-2109) Conflicts between component reference interface and promoted composite reference interface are not detected
[ https://issues.apache.org/jira/browse/TUSCANY-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12603900#action_12603900 ] Scott Kurz commented on TUSCANY-2109: - Based on where our discussion ended up here: http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg30266.html I think we can close this JIRA. Conflicts between component reference interface and promoted composite reference interface are not detected Key: TUSCANY-2109 URL: https://issues.apache.org/jira/browse/TUSCANY-2109 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-1.1 Environment: All Reporter: Simon Nash Assignee: Simon Laws Fix For: Java-SCA-Next Attachments: jira2109.patch, jira2109.zip See TUSCANY-2033 for the background to this problem. When a component reference defined with interface.java (either explicitly or implicitly by introspection) is promoted to a composite reference defined with interface.wsdl, and there is a namespace conflict between the component reference's interface.java and the composite reference's interface.wsdl. this conflict should be diagnosed as an error because it violates the spec rule that an interface specified on a composite reference must be a compatible superset of the interface of the promoted component reference. In this case, the composite interface is incompatible with the component reference because it has a different namespace. There is code in CompositeWireBuilderImpl.connectCompositeReferences() to handle connections between composite references and promoted compoennt references. The only interface processing performed in this method is to copy the component reference's interface contract to the composite reference's interface contract if the composite reference does not have an interface contract. Code should be added here to check for conflicts between the composite reference's interface and the component reference's interface if both interfaces are specified. Similar code should be added to CompositeWireBuilderImpl.connectCompositeServices() to check that the composite service interface is a compatible subset of the component service interface as required by the spec. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TUSCANY-2377) problem reading complex property from @file
problem reading complex property from @file
---
Key: TUSCANY-2377
URL: https://issues.apache.org/jira/browse/TUSCANY-2377
Project: Tuscany
Issue Type: Bug
Components: Java SCA Core Runtime
Reporter: Scott Kurz
I'm having trouble reading a complex property from a file pointed to via the
property @file attr.
I'm using a JAXB to hold the prop value in my Java impl, but in looking at this
briefly in the debugger I think the problem might be in the DOM object before
it is ever transformed into a JAXB (in my case).
I think the problem is in the code:
public class JavaPropertyValueObjectFactory
public ObjectFactory createValueFactory(Property property, Object
propertyValue, Class javaType) {
...
} else {
if (isSimpleType) {
} else {
ListNode nodes = getComplexPropertyValues(doc);
Object value = null;
if (!nodes.isEmpty()) {
value = nodes.get(0);
}
return new ObjectFactoryImpl(property, value, isSimpleType,
javaType);
}
I'm not skilled with DOM... but I think this code is expecting a wrapper around
the real property value, which is why we do a
nodes.get(0) to get the first child.
I think this wrapper must be there in the case that the property value is set
inline in the SCDL or via a Composite property definition, but I think there's
a wrapper missing in the case that we use @file, in which case we get a raw
document.
I'll attach a patch of an existing itest adding a couple tests to to show an
example.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TUSCANY-2377) problem reading complex property from @file
[
https://issues.apache.org/jira/browse/TUSCANY-2377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Scott Kurz updated TUSCANY-2377:
Attachment: 2377.itest.example.diff
I didn't see an example for using XJC, so I just hand-gen'd the Java from
rcprops.xsd into src/main/java. Note I use JAXB customizations so this is a
non-default mapping, but I think the customizations are irrelevant to this JIRA
.
problem reading complex property from @file
---
Key: TUSCANY-2377
URL: https://issues.apache.org/jira/browse/TUSCANY-2377
Project: Tuscany
Issue Type: Bug
Components: Java SCA Core Runtime
Reporter: Scott Kurz
Attachments: 2377.itest.example.diff, 2377.itest.example.diff
I'm having trouble reading a complex property from a file pointed to via the
property @file attr.
I'm using a JAXB to hold the prop value in my Java impl, but in looking at
this briefly in the debugger I think the problem might be in the DOM object
before it is ever transformed into a JAXB (in my case).
I think the problem is in the code:
public class JavaPropertyValueObjectFactory
public ObjectFactory createValueFactory(Property property, Object
propertyValue, Class javaType) {
...
} else {
if (isSimpleType) {
} else {
ListNode nodes = getComplexPropertyValues(doc);
Object value = null;
if (!nodes.isEmpty()) {
value = nodes.get(0);
}
return new ObjectFactoryImpl(property, value, isSimpleType,
javaType);
}
I'm not skilled with DOM... but I think this code is expecting a wrapper
around the real property value, which is why we do a
nodes.get(0) to get the first child.
I think this wrapper must be there in the case that the property value is set
inline in the SCDL or via a Composite property definition, but I think
there's a wrapper missing in the case that we use @file, in which case we get
a raw document.
I'll attach a patch of an existing itest adding a couple tests to to show an
example.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TUSCANY-2377) problem reading complex property from @file
[
https://issues.apache.org/jira/browse/TUSCANY-2377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Scott Kurz updated TUSCANY-2377:
Attachment: 2377.itest.example.diff
Same file.. I meant to say it could be included in ASF
problem reading complex property from @file
---
Key: TUSCANY-2377
URL: https://issues.apache.org/jira/browse/TUSCANY-2377
Project: Tuscany
Issue Type: Bug
Components: Java SCA Core Runtime
Reporter: Scott Kurz
Attachments: 2377.itest.example.diff, 2377.itest.example.diff
I'm having trouble reading a complex property from a file pointed to via the
property @file attr.
I'm using a JAXB to hold the prop value in my Java impl, but in looking at
this briefly in the debugger I think the problem might be in the DOM object
before it is ever transformed into a JAXB (in my case).
I think the problem is in the code:
public class JavaPropertyValueObjectFactory
public ObjectFactory createValueFactory(Property property, Object
propertyValue, Class javaType) {
...
} else {
if (isSimpleType) {
} else {
ListNode nodes = getComplexPropertyValues(doc);
Object value = null;
if (!nodes.isEmpty()) {
value = nodes.get(0);
}
return new ObjectFactoryImpl(property, value, isSimpleType,
javaType);
}
I'm not skilled with DOM... but I think this code is expecting a wrapper
around the real property value, which is why we do a
nodes.get(0) to get the first child.
I think this wrapper must be there in the case that the property value is set
inline in the SCDL or via a Composite property definition, but I think
there's a wrapper missing in the case that we use @file, in which case we get
a raw document.
I'll attach a patch of an existing itest adding a couple tests to to show an
example.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (TUSCANY-2332) reconsider non-support for Holders
reconsider non-support for Holders -- Key: TUSCANY-2332 URL: https://issues.apache.org/jira/browse/TUSCANY-2332 Project: Tuscany Issue Type: Improvement Components: Java SCA Data Binding Runtime Reporter: Scott Kurz Though the Java annotations/API spec specifically says wrt WSDL- Java mapping: The JAX-WS mappings are applied with the following restrictions: • No support for holders I'd like to suggest that we look into enabling such support anyway, as this seems overly restrictive and prevents us from supporting existing WSDLs with inout data. At least I don't see how we'd map these WSDLs to Java and would think we'd be way better off relying on the mapping defined by JAX-WS which does use Holders. (Not sure what this statement in the spec was trying to accomplish.) I attached an example WSDL with two operations which we'd want to use Holders in the corresponding Java methods. One has a common child element of both input/output wrapper elem and the other has a common part of input/output message. (Maybe it would be better to bring this up before opening a JIRA, but I wanted to attach the WSDL.) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TUSCANY-2332) reconsider non-support for Holders
[ https://issues.apache.org/jira/browse/TUSCANY-2332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Kurz updated TUSCANY-2332: Attachment: guessAndGreet.wsdl reconsider non-support for Holders -- Key: TUSCANY-2332 URL: https://issues.apache.org/jira/browse/TUSCANY-2332 Project: Tuscany Issue Type: Improvement Components: Java SCA Data Binding Runtime Reporter: Scott Kurz Attachments: guessAndGreet.wsdl Though the Java annotations/API spec specifically says wrt WSDL- Java mapping: The JAX-WS mappings are applied with the following restrictions: • No support for holders I'd like to suggest that we look into enabling such support anyway, as this seems overly restrictive and prevents us from supporting existing WSDLs with inout data. At least I don't see how we'd map these WSDLs to Java and would think we'd be way better off relying on the mapping defined by JAX-WS which does use Holders. (Not sure what this statement in the spec was trying to accomplish.) I attached an example WSDL with two operations which we'd want to use Holders in the corresponding Java methods. One has a common child element of both input/output wrapper elem and the other has a common part of input/output message. (Maybe it would be better to bring this up before opening a JIRA, but I wanted to attach the WSDL.) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TUSCANY-2324) InterfaceContract is not pushed down to an inner, promoted component reference only with Axis2 binding
InterfaceContract is not pushed down to an inner, promoted component reference only with Axis2 binding --- Key: TUSCANY-2324 URL: https://issues.apache.org/jira/browse/TUSCANY-2324 Project: Tuscany Issue Type: Bug Components: Java SCA Axis Binding Extension Reporter: Scott Kurz Priority: Minor If we take the following example where an inner component reference is overridden in two ways by the outer component using the inner Composite as impl: 1) a binding.ws is added 2) a WSDL intf (compatible with the inner Java intf) is declared composite ... name=OuterComposite component name=OuterComponent implementation.composite name=blah:InnerComposite/ reference name=outerRef target=MyTarget interface.wsdl interface=http://blah#wsdl.interface(HelloWorld) / binding.ws/ /reference /component /composite composite name=InnerComposite component name=InnerComponent implementation.java .../ reference name=helloWorldService interface.java interface=test.sca.w2j.ws.statc.exc.helloworld.HelloWorld/ /reference /component reference name=outerRef promote=InnerComponent/helloWorldService/ /composite we have a problem. The CompositeActivatorImpl is going to start an Axis2ReferenceBindingProvider for the inner Composite ref. The WS binding is propagated down or inwards, you could say.But this WS binding has a null IC, so we're going to look at the component ref IC, but this will be the inner component ref IC, which is a Java IC. This kicks off a Java2WSDL and the new WSDL IC becomes the Axis2 ref binding IC. So the generated WSDL may not match the actual WSDL, which is a problem. Of course, if we had included a wsdlElement (e.g. wsdl.port ) on the outer component's binding.ws/ we would not have had a problem; it would have been propagated inwards along with the binding itself. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TUSCANY-2316) Axis2 Binding Provider does not handle services references with WSDL interfaces correctly
[ https://issues.apache.org/jira/browse/TUSCANY-2316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12596503#action_12596503 ] Scott Kurz commented on TUSCANY-2316: - The binding-ws-axis2 is overwriting the databinding on the IC obtained from the binding.ws model object (WebServiceBindingImpl).So far, that would seem to be correct, then. What do the ClassCastExceptions you're getting look like? Axis2 Binding Provider does not handle services references with WSDL interfaces correctly --- Key: TUSCANY-2316 URL: https://issues.apache.org/jira/browse/TUSCANY-2316 Project: Tuscany Issue Type: Bug Components: Java SCA Axis Binding Extension Affects Versions: Java-SCA-1.2 Environment: - any - Reporter: Mike Edwards Assignee: Mike Edwards Fix For: Java-SCA-Next Attachments: sample-helloworld-bpel-ws.zip Where a component has a service or reference which has an interface which uses a WSDL interface definition, the Axis2 binding providers incorrectly overwrite the DataBinding specified by the component implementation and impose the OMElement binding used by Axis2 - this causes class cast exceptions when the service or reference is invoked. The problem is caused by failure to copy the InterfaceContract definition in the Axis2ReferenceBindingProvider and Axis2ServiceBindingProvider constructors, when the InterfaceContract is not a JavaInterfaceContract. The lack of a copy means that the Axis binding provider then uses the original contract object as its own and overwrites aspects of that contract - including the databinding to use. I've attached a sample application that I created which found this problem -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TUSCANY-2113) Problem with fault comparison in DataTransformationInterceptor; maybe we should compare elem QNames, not type QNames?
[ https://issues.apache.org/jira/browse/TUSCANY-2113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12589777#action_12589777 ] Scott Kurz commented on TUSCANY-2113: - I'm sorry I don't have a test case handy. If I look at itests, I see you could take: sca/itest/exceptions-cross-binding-ws/src/main/resources/wsdl/StockExceptionTest.wsdl and add another int, integer, or anonymous-typed fault and expand the test in that way. Problem with fault comparison in DataTransformationInterceptor; maybe we should compare elem QNames, not type QNames? - Key: TUSCANY-2113 URL: https://issues.apache.org/jira/browse/TUSCANY-2113 Project: Tuscany Issue Type: Bug Affects Versions: Java-SCA-1.1 Reporter: Scott Kurz Assignee: Raymond Feng Fix For: Java-SCA-Next There's a problem with how the fault matching in DTI uses the private DTI.typesMatch() method. I don't think it should be allowing a matching type name to return 'true', i.e. indicate a successful match. return matches(t1.getElementName(), t2.getElementName()) || matches(t1.getTypeName(), t2.getTypeName()); For one, I could have two distinct fault elems of the same type. In addition, also note that, if you have a fault element with anonymous type, the generated JAXB will look like: @XmlType(name = ..) so we will build up an XMLType with typeName equal to a namespace plus a null name.One problem with this is that there is no way to distinguish between two fault elems in the same NS, with anonymous types. I haven't given this a huge amount of thought so I mention this in case anyone thinks of other issues relating to some of the points I am making. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-2217) Some null guards needed in MediatorImpl
Some null guards needed in MediatorImpl --- Key: TUSCANY-2217 URL: https://issues.apache.org/jira/browse/TUSCANY-2217 Project: Tuscany Issue Type: Bug Components: Java SCA Data Binding Runtime Affects Versions: Java-SCA-1.1 Reporter: Scott Kurz Fix For: Java-SCA-Next I think we should add guards to MediatorImpl.mediate() so that: - We don't do the introspectType(source) if 'source' is null - We simply return 'source' if 'targetDataType' is null While, for some methods, we might put the burden on the caller to check, this method is already one that can handle nulls for certain objs, and we want to possibly allow transforming a null 'source', so it seems better to make the mediate() method itself more robust. I'll attach a patch. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-2217) Some null guards needed in MediatorImpl
[ https://issues.apache.org/jira/browse/TUSCANY-2217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Kurz updated TUSCANY-2217: Attachment: 2217.patch Some null guards needed in MediatorImpl --- Key: TUSCANY-2217 URL: https://issues.apache.org/jira/browse/TUSCANY-2217 Project: Tuscany Issue Type: Bug Components: Java SCA Data Binding Runtime Affects Versions: Java-SCA-1.1 Reporter: Scott Kurz Fix For: Java-SCA-Next Attachments: 2217.patch I think we should add guards to MediatorImpl.mediate() so that: - We don't do the introspectType(source) if 'source' is null - We simply return 'source' if 'targetDataType' is null While, for some methods, we might put the burden on the caller to check, this method is already one that can handle nulls for certain objs, and we want to possibly allow transforming a null 'source', so it seems better to make the mediate() method itself more robust. I'll attach a patch. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-2193) NPE when configuring WSDL interface on component ref when the component has a Composite impl
NPE when configuring WSDL interface on component ref when the component has a Composite impl Key: TUSCANY-2193 URL: https://issues.apache.org/jira/browse/TUSCANY-2193 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Reporter: Scott Kurz Priority: Minor I noticed this with a more complicated example. To reproduce more simply maybe, go to the SVN dir: sca/itest/recursive and modify BComposite.composite so it looks like: composite xmlns=http://www.osoa.org/xmlns/sca/1.0; targetNamespace=http://sample; xmlns:sample=http://sample; name=BComposite component name=BComponent implementation.composite name=sample:CComposite/ reference name=PromotedRefX interface.wsdl interface=http://blah#wsdl.interface(Blah) / /reference Note that you can put any old WSDL in there. You shouldn't get far enough for it to even matter. You'll hit errors like: java.lang.NullPointerException at org.apache.tuscany.sca.interfacedef.impl.InterfaceContractMapperImpl.checkCompatibility(InterfaceContractMapperImpl.java:155) at org.apache.tuscany.sca.interfacedef.impl.InterfaceContractMapperImpl.isCompatible(InterfaceContractMapperImpl.java:271) at org.apache.tuscany.sca.assembly.builder.impl.CompositeConfigurationBuilderImpl.reconcileReferences(CompositeConfigurationBuilderImpl.java:527) at org.apache.tuscany.sca.assembly.builder.impl.CompositeConfigurationBuilderImpl.configureComponents(CompositeConfigurationBuilderImpl.java:250) at org.apache.tuscany.sca.assembly.builder.impl.CompositeConfigurationBuilderImpl.configureComponents(CompositeConfigurationBuilderImpl.java:85) at org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl.build(CompositeBuilderImpl.java:97) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-2193) NPE when configuring WSDL interface on component ref when the component has a Composite impl
[
https://issues.apache.org/jira/browse/TUSCANY-2193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12585135#action_12585135
]
Scott Kurz commented on TUSCANY-2193:
-
I found the problem.
In CompositeConfigurationBuilderImpl.reconcileReferences() we do a check to see
if we want an incompatible intf warning:
// Reconcile interface
if (componentReference.getInterfaceContract() != null) {
if
(!componentReference.getInterfaceContract().equals(reference
.getInterfaceContract())) {
if
(!interfaceContractMapper.isCompatible(reference.getInterfaceContract(),
componentReference
.getInterfaceContract())) {
warning(Component reference interface incompatible
with reference interface: +...
In the case I described above, we are going to have a non-null IC from the
component reference (the WSDL IC). However, the reference IC wlil still be
null at this point. (The reason seems to be that the reference IC on the
composite impl does not get set until CompositeWireBuilderImpl.wireComposite).
So I'll leave it up to others whether it's best to put a null guard before
calling the IC mapper or if we should look to put a guard in the IC mapper impl
itself.
NPE when configuring WSDL interface on component ref when the component has a
Composite impl
Key: TUSCANY-2193
URL: https://issues.apache.org/jira/browse/TUSCANY-2193
Project: Tuscany
Issue Type: Bug
Components: Java SCA Core Runtime
Reporter: Scott Kurz
Priority: Minor
I noticed this with a more complicated example.
To reproduce more simply maybe, go to the SVN dir: sca/itest/recursive
and modify BComposite.composite so it looks like:
composite xmlns=http://www.osoa.org/xmlns/sca/1.0;
targetNamespace=http://sample;
xmlns:sample=http://sample;
name=BComposite
component name=BComponent
implementation.composite name=sample:CComposite/
reference name=PromotedRefX
interface.wsdl interface=http://blah#wsdl.interface(Blah) /
/reference
Note that you can put any old WSDL in there. You shouldn't get far enough
for it to even matter.
You'll hit errors like:
java.lang.NullPointerException
at
org.apache.tuscany.sca.interfacedef.impl.InterfaceContractMapperImpl.checkCompatibility(InterfaceContractMapperImpl.java:155)
at
org.apache.tuscany.sca.interfacedef.impl.InterfaceContractMapperImpl.isCompatible(InterfaceContractMapperImpl.java:271)
at
org.apache.tuscany.sca.assembly.builder.impl.CompositeConfigurationBuilderImpl.reconcileReferences(CompositeConfigurationBuilderImpl.java:527)
at
org.apache.tuscany.sca.assembly.builder.impl.CompositeConfigurationBuilderImpl.configureComponents(CompositeConfigurationBuilderImpl.java:250)
at
org.apache.tuscany.sca.assembly.builder.impl.CompositeConfigurationBuilderImpl.configureComponents(CompositeConfigurationBuilderImpl.java:85)
at
org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl.build(CompositeBuilderImpl.java:97)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-2189) Problems building the wire for a service implemented by Composite
[ https://issues.apache.org/jira/browse/TUSCANY-2189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Kurz updated TUSCANY-2189: Attachment: test.2189.jar Sorry this doesn't exactly match the SCDL pasted it the JIRA text but it's the same idea Problems building the wire for a service implemented by Composite - Key: TUSCANY-2189 URL: https://issues.apache.org/jira/browse/TUSCANY-2189 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Reporter: Scott Kurz Fix For: Java-SCA-Next Attachments: test.2189.jar Take something like this: composite name=OuterComposite component name=OuterCalculatorComponent service name=OuterCalculatorService binding.ws wsdlElement=/ /service implementation.composite name=calc:InnerComposite/ /component /composite composite name=InnerComposite service name=OuterCalculatorService promote=CalculatorComponent/CalculatorService/ component name=CalculatorComponent service name=CalculatorService/ implementation.java class=calculator.CalculatorServiceImpl/ /component /composite -- I'm noticing that the wireTarget that ends up getting built for the wire from the OuterCalculatorService service-side WS binding into the impl has a wireTarget with a Composite impl. This causes a problem when RuntimeWireImpl.initInvocationChains() calls addImplementationInterceptor(); we need a non-composite impl (Java impl) at this point to set up the interceptor on the chain. Might it be appropriate to do something like what's done in CompositeWireBuilderImpl.connectComponentReferences(), where we drill down recursively to unwrap the Composite impl services? I looked at the 'recursive' itest and didn't see anything besides binding.sca... so maybe we don't think we've gotten to this yet. In the cases it does work, with binding.sca, we must somehow be connected to the inner-layer wire from the component in the nested Composite. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-2189) Problems building the wire for a service implemented by Composite
Problems building the wire for a service implemented by Composite - Key: TUSCANY-2189 URL: https://issues.apache.org/jira/browse/TUSCANY-2189 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Reporter: Scott Kurz Fix For: Java-SCA-Next Attachments: test.2189.jar Take something like this: composite name=OuterComposite component name=OuterCalculatorComponent service name=OuterCalculatorService binding.ws wsdlElement=/ /service implementation.composite name=calc:InnerComposite/ /component /composite composite name=InnerComposite service name=OuterCalculatorService promote=CalculatorComponent/CalculatorService/ component name=CalculatorComponent service name=CalculatorService/ implementation.java class=calculator.CalculatorServiceImpl/ /component /composite -- I'm noticing that the wireTarget that ends up getting built for the wire from the OuterCalculatorService service-side WS binding into the impl has a wireTarget with a Composite impl. This causes a problem when RuntimeWireImpl.initInvocationChains() calls addImplementationInterceptor(); we need a non-composite impl (Java impl) at this point to set up the interceptor on the chain. Might it be appropriate to do something like what's done in CompositeWireBuilderImpl.connectComponentReferences(), where we drill down recursively to unwrap the Composite impl services? I looked at the 'recursive' itest and didn't see anything besides binding.sca... so maybe we don't think we've gotten to this yet. In the cases it does work, with binding.sca, we must somehow be connected to the inner-layer wire from the component in the nested Composite. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-2084) Problems deserializing XML-SDO after using XMLType element calculated from Java to serialize SDO-XML onto
[ https://issues.apache.org/jira/browse/TUSCANY-2084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12582302#action_12582302 ] Scott Kurz commented on TUSCANY-2084: - There's a similar issue for dynamic SDO. Instead of just: Problems deserializing XML-SDO after using XMLType element calculated from Java to serialize SDO-XML onto Key: TUSCANY-2084 URL: https://issues.apache.org/jira/browse/TUSCANY-2084 Project: Tuscany Issue Type: Bug Components: Java SCA Data Binding Runtime, Java SDO Implementation Affects Versions: Java-SCA-1.1 Reporter: Scott Kurz Fix For: Java-SCA-Next Discussed in this thread: http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg28304.html Personally I worked around this by changing SDODatabinding.introspect() to do: dataType.setLogical(new XMLType(null, xmlType)); //dataType.setLogical(new XMLType(elementName, xmlType)); But Raymond suggested possibly fixing this in the SDO impl. It would also be possible to leave introspection the same but workaround this in the SDO transformers. Note that if you use the WS binding you typically won't see this, because the presence of the WSDL intf on the XML side of things gives you a real element to serialize into, one that SDO can recognize during deserialization. You have to have a binding without a WSDL intf that you're transforming across. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Issue Comment Edited: (TUSCANY-2084) Problems deserializing XML-SDO after using XMLType element calculated from Java to serialize SDO-XML onto
[
https://issues.apache.org/jira/browse/TUSCANY-2084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12582302#action_12582302
]
scottkurz edited comment on TUSCANY-2084 at 3/26/08 7:51 AM:
--
There's a similar issue for dynamic SDO. Instead of doing:
if (dataType.getLogical() == null) {
dataType.setLogical(XMLType.UNKNOWN);
}
which has no impact now that Java introspection is setting up a logical DT with
a default elem in it
(therefore it's non-null), I think we should just do an unconditional:
dataType.setLogical(XMLType.UNKNOWN);
to overwrite and to therefore allow SDO serialization to work.
was (Author: scottkurz):
There's a similar issue for dynamic SDO. Instead of just:
Problems deserializing XML-SDO after using XMLType element calculated from
Java to serialize SDO-XML onto
Key: TUSCANY-2084
URL: https://issues.apache.org/jira/browse/TUSCANY-2084
Project: Tuscany
Issue Type: Bug
Components: Java SCA Data Binding Runtime, Java SDO Implementation
Affects Versions: Java-SCA-1.1
Reporter: Scott Kurz
Fix For: Java-SCA-Next
Discussed in this thread:
http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg28304.html
Personally I worked around this by changing SDODatabinding.introspect() to do:
dataType.setLogical(new XMLType(null, xmlType));
//dataType.setLogical(new XMLType(elementName, xmlType));
But Raymond suggested possibly fixing this in the SDO impl. It would also
be possible to leave introspection the same
but workaround this in the SDO transformers.
Note that if you use the WS binding you typically won't see this, because the
presence of the WSDL intf on the XML side of things
gives you a real element to serialize into, one that SDO can recognize during
deserialization. You have to have a binding without a WSDL intf
that you're transforming across.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-2113) Problem with fault comparison in DataTransformationInterceptor; maybe we should compare elem QNames, not type QNames?
Problem with fault comparison in DataTransformationInterceptor; maybe we should compare elem QNames, not type QNames? - Key: TUSCANY-2113 URL: https://issues.apache.org/jira/browse/TUSCANY-2113 Project: Tuscany Issue Type: Bug Affects Versions: Java-SCA-1.1 Reporter: Scott Kurz Fix For: Java-SCA-Next There's a problem with how the fault matching in DTI uses the private DTI.typesMatch() method. I don't think it should be allowing a matching type name to return 'true', i.e. indicate a successful match. return matches(t1.getElementName(), t2.getElementName()) || matches(t1.getTypeName(), t2.getTypeName()); For one, I could have two distinct fault elems of the same type. In addition, also note that, if you have a fault element with anonymous type, the generated JAXB will look like: -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-2113) Problem with fault comparison in DataTransformationInterceptor; maybe we should compare elem QNames, not type QNames?
[ https://issues.apache.org/jira/browse/TUSCANY-2113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Kurz updated TUSCANY-2113: Description: There's a problem with how the fault matching in DTI uses the private DTI.typesMatch() method. I don't think it should be allowing a matching type name to return 'true', i.e. indicate a successful match. return matches(t1.getElementName(), t2.getElementName()) || matches(t1.getTypeName(), t2.getTypeName()); For one, I could have two distinct fault elems of the same type. In addition, also note that, if you have a fault element with anonymous type, the generated JAXB will look like: @XmlType(name = ..) so we will build up an XMLType with typeName equal to a namespace plus a null name.One problem with this is that there is no way to distinguish between two elems with anonymous types. I haven't given this a huge amount of thought so I mention this in case anyone thinks of other issues relating to some of the points I am making. was: There's a problem with how the fault matching in DTI uses the private DTI.typesMatch() method. I don't think it should be allowing a matching type name to return 'true', i.e. indicate a successful match. return matches(t1.getElementName(), t2.getElementName()) || matches(t1.getTypeName(), t2.getTypeName()); For one, I could have two distinct fault elems of the same type. In addition, also note that, if you have a fault element with anonymous type, the generated JAXB will look like: Problem with fault comparison in DataTransformationInterceptor; maybe we should compare elem QNames, not type QNames? - Key: TUSCANY-2113 URL: https://issues.apache.org/jira/browse/TUSCANY-2113 Project: Tuscany Issue Type: Bug Affects Versions: Java-SCA-1.1 Reporter: Scott Kurz Fix For: Java-SCA-Next There's a problem with how the fault matching in DTI uses the private DTI.typesMatch() method. I don't think it should be allowing a matching type name to return 'true', i.e. indicate a successful match. return matches(t1.getElementName(), t2.getElementName()) || matches(t1.getTypeName(), t2.getTypeName()); For one, I could have two distinct fault elems of the same type. In addition, also note that, if you have a fault element with anonymous type, the generated JAXB will look like: @XmlType(name = ..) so we will build up an XMLType with typeName equal to a namespace plus a null name.One problem with this is that there is no way to distinguish between two elems with anonymous types. I haven't given this a huge amount of thought so I mention this in case anyone thinks of other issues relating to some of the points I am making. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-2113) Problem with fault comparison in DataTransformationInterceptor; maybe we should compare elem QNames, not type QNames?
[ https://issues.apache.org/jira/browse/TUSCANY-2113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Kurz updated TUSCANY-2113: Description: There's a problem with how the fault matching in DTI uses the private DTI.typesMatch() method. I don't think it should be allowing a matching type name to return 'true', i.e. indicate a successful match. return matches(t1.getElementName(), t2.getElementName()) || matches(t1.getTypeName(), t2.getTypeName()); For one, I could have two distinct fault elems of the same type. In addition, also note that, if you have a fault element with anonymous type, the generated JAXB will look like: @XmlType(name = ..) so we will build up an XMLType with typeName equal to a namespace plus a null name.One problem with this is that there is no way to distinguish between two fault elems in the same NS, with anonymous types. I haven't given this a huge amount of thought so I mention this in case anyone thinks of other issues relating to some of the points I am making. was: There's a problem with how the fault matching in DTI uses the private DTI.typesMatch() method. I don't think it should be allowing a matching type name to return 'true', i.e. indicate a successful match. return matches(t1.getElementName(), t2.getElementName()) || matches(t1.getTypeName(), t2.getTypeName()); For one, I could have two distinct fault elems of the same type. In addition, also note that, if you have a fault element with anonymous type, the generated JAXB will look like: @XmlType(name = ..) so we will build up an XMLType with typeName equal to a namespace plus a null name.One problem with this is that there is no way to distinguish between two elems with anonymous types. I haven't given this a huge amount of thought so I mention this in case anyone thinks of other issues relating to some of the points I am making. Problem with fault comparison in DataTransformationInterceptor; maybe we should compare elem QNames, not type QNames? - Key: TUSCANY-2113 URL: https://issues.apache.org/jira/browse/TUSCANY-2113 Project: Tuscany Issue Type: Bug Affects Versions: Java-SCA-1.1 Reporter: Scott Kurz Fix For: Java-SCA-Next There's a problem with how the fault matching in DTI uses the private DTI.typesMatch() method. I don't think it should be allowing a matching type name to return 'true', i.e. indicate a successful match. return matches(t1.getElementName(), t2.getElementName()) || matches(t1.getTypeName(), t2.getTypeName()); For one, I could have two distinct fault elems of the same type. In addition, also note that, if you have a fault element with anonymous type, the generated JAXB will look like: @XmlType(name = ..) so we will build up an XMLType with typeName equal to a namespace plus a null name.One problem with this is that there is no way to distinguish between two fault elems in the same NS, with anonymous types. I haven't given this a huge amount of thought so I mention this in case anyone thinks of other issues relating to some of the points I am making. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-2033) java interface exposed as service, annoted with javax.xml.ws.RequestWrapper(...) is ignoring the namespace
[
https://issues.apache.org/jira/browse/TUSCANY-2033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12579836#action_12579836
]
Scott Kurz commented on TUSCANY-2033:
-
I'm surprised we'd view Clemens' original example as an error, though I agree
the jira2033.zip should be detected as an error.
True, the original component reference was defined via the introspected
interface.java. But shouldn't the JAX-WS annotations be taken into
consideration?
I'm not sure precisely how to do so, whether to build an interface model
object incorporating both Java WSDL info or simply to define the mapping
algorithm to allow for this, or if we've gotten anywhere since this was opened
a month ago, so I'll leave it at that.
java interface exposed as service, annoted with
javax.xml.ws.RequestWrapper(...) is ignoring the namespace
--
Key: TUSCANY-2033
URL: https://issues.apache.org/jira/browse/TUSCANY-2033
Project: Tuscany
Issue Type: Bug
Components: Java SCA Axis Binding Extension
Affects Versions: Java-SCA-1.0.1
Reporter: clemens utschig
Assignee: Raymond Feng
Priority: Critical
Fix For: Java-SCA-Next
Attachments: EmpFlexFieldService.java, EmpFlexFieldService.wsdl,
jira2033.zip, SDOReferenceBinding.zip
I have a composite defined that uses an external referenced webservice which
provides SDOs
?xml version=1.0 encoding=UTF-8?
composite xmlns=http://www.osoa.org/xmlns/sca/1.0;
targetNamespace=/model/common/
xmlns:dbsdo=http://tuscany.apache.org/xmlns/sca/databinding/sdo/1.0;
name=FlexEmployeeComposite xmlns:tns=/model/common/types/
xmlns:types=/model/common/types/
xmlns:errors=http://xmlns.oracle.com/adf/svc/errors/;
xmlns:soap=http://schemas.xmlsoap.org/wsdl/soap/;
component name=FlexEmployeeServiceComponent
implementation.java
class=com.oracle.soa.test.tuscany.impl.EmployeeServiceComponent/
reference name=empFlexFieldService/
/component
reference name=empFlexFieldService
promote=FlexEmployeeServiceComponent/empFlexFieldService
interface.java
interface=model.common.serviceinterface.EmpFlexFieldService/
binding.ws
uri=http://localhost:1234/Application4710-Model-context-root/EmpFlexFieldService/
/reference
/composite
The java interface that is promoted as service interface / and reflects the
webservice endpoint, contains jaxws annotations for namespaces as below ..
@javax.jws.soap.SOAPBinding(parameterStyle=javax.jws.soap.SOAPBinding.ParameterStyle.WRAPPED,
style=javax.jws.soap.SOAPBinding.Style.DOCUMENT)
@javax.jws.WebService(targetNamespace=/model/common/,
name=EmpFlexFieldService,
wsdlLocation=model/common/serviceinterface/EmpFlexFieldService.wsdl)
@oracle.j2ee.ws.common.sdo.SchemaLocation(value=model/common/serviceinterface/EmpFlexFieldService.xsd)
public interface EmpFlexFieldService {
public static final String NAME =
new QName(/model/common/, EmpFlexFieldService).toString();
@javax.jws.WebMethod(action=/model/common/getEmployees1,
operationName=getEmployees1)
@javax.xml.ws.RequestWrapper(targetNamespace=/model/common/types/,
localName=getEmployees1)
@javax.xml.ws.ResponseWrapper(targetNamespace=/model/common/types/,
localName=getEmployees1Response)
@javax.jws.WebResult(name=result)
DataObject
getEmployees1(@javax.jws.WebParam(mode=javax.jws.WebParam.Mode.IN,
name=empno)
Integer empno) throws ServiceException;
At runtime - axis generates the following soap message - which is derived
from the base targetNamespace
?xml version='1.0' encoding='UTF-8'?
soapenv:Envelope
xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/;
soapenv:Body
_ns_:getEmployees1 xmlns:_ns_=/model/common/
empno xmlns=/model/common/1/empno
/_ns_:getEmployees1
/soapenv:Body
/soapenv:Envelope
obviously this is wrong - it should be ..
soap:Envelope xmlns:soap=http://schemas.xmlsoap.org/soap/envelope/;
soap:Body xmlns:ns1=/model/common/types/
ns1:getEmployees1
ns1:empno/ns1:empno
/ns1:getEmployees1
/soap:Body
/soap:Envelope
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-2094) Would like to keep track of element name during fault/exception mapping at introspect time and invocation time so I can use FaultException matching helpfully
[ https://issues.apache.org/jira/browse/TUSCANY-2094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Kurz updated TUSCANY-2094: Attachment: JAXWSFaultExcMapper.patch Would like to keep track of element name during fault/exception mapping at introspect time and invocation time so I can use FaultException matching helpfully - Key: TUSCANY-2094 URL: https://issues.apache.org/jira/browse/TUSCANY-2094 Project: Tuscany Issue Type: Improvement Components: Java SCA Data Binding Runtime Affects Versions: Java-SCA-1.1 Reporter: Scott Kurz Fix For: Java-SCA-1.2 Attachments: JAXWSFaultExcMapper.patch In the JAXWSFaultExceptionMapper, we look at the @WebFault to capture the fault element name. It would be nice to capture during introspect this so it could be set into the FaultException at wrap time for use in matching. I'll attach a patch which has does: 1) During introspect, save the @WebFault element and set it in as the fault DT's XMLType logical's element name 2) During wrapFaultInfo(), if we have a FaultException let's grab the element name from the fault logical and do a setFaultName() The reason I had to do 1) in addition to 2) is that the instrospection of the fault itself was, in my case, creating an XMLType with Type but no Element. (This happened since the JAXBDataBinding only sets up an Element on the XMLType if it finds an @XMLRootElement). I wasn't sure in 1) if I should always set the @WebFault as the fault's logical's element name or if I should only do so in the introspect of the fault did not itself set this field to non-null. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-2094) Would like to keep track of element name during fault/exception mapping at introspect time and invocation time so I can use FaultException matching helpfully
Would like to keep track of element name during fault/exception mapping at introspect time and invocation time so I can use FaultException matching helpfully - Key: TUSCANY-2094 URL: https://issues.apache.org/jira/browse/TUSCANY-2094 Project: Tuscany Issue Type: Improvement Components: Java SCA Data Binding Runtime Affects Versions: Java-SCA-1.1 Reporter: Scott Kurz Fix For: Java-SCA-1.2 Attachments: JAXWSFaultExcMapper.patch In the JAXWSFaultExceptionMapper, we look at the @WebFault to capture the fault element name. It would be nice to capture during introspect this so it could be set into the FaultException at wrap time for use in matching. I'll attach a patch which has does: 1) During introspect, save the @WebFault element and set it in as the fault DT's XMLType logical's element name 2) During wrapFaultInfo(), if we have a FaultException let's grab the element name from the fault logical and do a setFaultName() The reason I had to do 1) in addition to 2) is that the instrospection of the fault itself was, in my case, creating an XMLType with Type but no Element. (This happened since the JAXBDataBinding only sets up an Element on the XMLType if it finds an @XMLRootElement). I wasn't sure in 1) if I should always set the @WebFault as the fault's logical's element name or if I should only do so in the introspect of the fault did not itself set this field to non-null. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-2084) Problems deserializing XML-SDO after using XMLType element calculated from Java to serialize SDO-XML onto
[ https://issues.apache.org/jira/browse/TUSCANY-2084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Kurz updated TUSCANY-2084: Component/s: Java SDO Implementation Java SCA Data Binding Runtime Fix Version/s: Java-SCA-Next Affects Version/s: Java-SCA-1.1 Problems deserializing XML-SDO after using XMLType element calculated from Java to serialize SDO-XML onto Key: TUSCANY-2084 URL: https://issues.apache.org/jira/browse/TUSCANY-2084 Project: Tuscany Issue Type: Bug Components: Java SCA Data Binding Runtime, Java SDO Implementation Affects Versions: Java-SCA-1.1 Reporter: Scott Kurz Fix For: Java-SCA-Next Discussed in this thread: http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg28304.html Personally I worked around this by changing SDODatabinding.introspect() to do: dataType.setLogical(new XMLType(null, xmlType)); //dataType.setLogical(new XMLType(elementName, xmlType)); But Raymond suggested possibly fixing this in the SDO impl. It would also be possible to leave introspection the same but workaround this in the SDO transformers. Note that if you use the WS binding you typically won't see this, because the presence of the WSDL intf on the XML side of things gives you a real element to serialize into, one that SDO can recognize during deserialization. You have to have a binding without a WSDL intf that you're transforming across. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-2085) ConcurentModExc in DefaultDataBindingExtensionPoint
ConcurentModExc in DefaultDataBindingExtensionPoint
Key: TUSCANY-2085
URL: https://issues.apache.org/jira/browse/TUSCANY-2085
Project: Tuscany
Issue Type: Bug
Components: Java SCA Data Binding Runtime
Affects Versions: Java-SCA-1.1
Reporter: Scott Kurz
Priority: Minor
Fix For: Java-SCA-Next
Get an exception like the following,
java.util.ConcurrentModificationException
at java.util.AbstractList$SimpleListIterator.next(Unknown Source)at
org.apache.tuscany.sca.databinding.DefaultDataBindingExtensionPoint.introspectType(DefaultDataBindingExtensionPoint.java:223)
at
org.apache.tuscany.sca.interfacedef.java.jaxws.JAXWSFaultExceptionMapper.introspectFaultDataType(JAXWSFaultExceptionMapper.java:214)
at
org.apache.tuscany.sca.interfacedef.java.jaxws.JAXWSJavaInterfaceProcessor.introspectFaultTypes(JAXWSJavaInterfaceProcessor.java:178)
at
org.apache.tuscany.sca.interfacedef.java.jaxws.JAXWSJavaInterfaceProcessor.visitInterface(JAXWSJavaInterfaceProcessor.java:90)
at
org.apache.tuscany.sca.interfacedef.java.impl.JavaInterfaceIntrospectorImpl.introspectInterface(JavaInterfaceIntrospectorImpl.java:91)
as this thread, A, is in a for-loop looping through 'databindings'
public boolean introspectType(DataType dataType, Annotation[] annotations,
boolean isException) {
loadDataBindings();
for (DataBinding binding : databindings) {
while another thread, B, is still in loadDataBindings() and is still adding to
the databindings ArrayList.
I'm working around this by putting a lock around the whole body of
loadDataBindings()
private final byte[] loadingLock = new byte[0];
...
private void loadDataBindings() {
synchronized (loadingLock) {
if (loadedDataBindings)
return;
...
}
}
Another option might be to change addDataBinding() to look at the 'bindings'
Map before adding to 'databindings'.
I'll attach a patch and leave it for a second opinion.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1679) PBVInvoker doesn't handle checked/business excs
[ https://issues.apache.org/jira/browse/TUSCANY-1679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Kurz updated TUSCANY-1679: Summary: PBVInvoker doesn't handle checked/business excs (was: PBVInvoker always uses service-side classloader to deserialize ... also doesn't handle checked/business excs) PBVInvoker doesn't handle checked/business excs --- Key: TUSCANY-1679 URL: https://issues.apache.org/jira/browse/TUSCANY-1679 Project: Tuscany Issue Type: Bug Components: Java SCA Data Binding Runtime Affects Versions: Java-SCA-1.0 Reporter: Scott Kurz Assignee: Raymond Feng Fix For: Java-SCA-Next First, the easier issue: PBVInvoker doesn't handle faults.For a checked/business exc on a remotable intf, wouldn't we want the exc to get copied too? We wouldn't want some piece of data making its way into the exception to end up unexpectedly modified, right? Second, I have the problem that the service-side classloader is used to do the copy (e.g.. to do the deserialize in JavaBeansDataBinding.copy() ). While this is what I want when copying the inputs, it is not necessarily what I want when copying the outputs (or the faults which I want to copy above). I might, for example, want to use a client-side classloader to deserialize the copied objects into. Maybe it wouldn't matter if I was going to do a data transform anyway, but if my outputs/faults are going to go back to the client untransformed, then I'm going to get a ClassCastExc if they're not in the client classloader. I'm not sure how to fix this... Note this JIRA, as I could imagine the fixes to these two issues intersecting: https://issues.apache.org/jira/browse/TUSCANY-1678 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1679) PBVInvoker always uses service-side classloader to deserialize ... also doesn't handle checked/business excs
[ https://issues.apache.org/jira/browse/TUSCANY-1679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12570742#action_12570742 ] Scott Kurz commented on TUSCANY-1679: - The implications of some other discussions we've had on the list suggest that it would be the binding's job to switch classloaders in a case like the one I had in mind. That is, if the client uses CL 1 and the service impl uses CL 2, the binding should not rely on the PBVInterceptor to switch the data into the correct CL. So I take back stating that as a problem. I'll see if I can rename the JIRA to focus on the need to copy faults. PBVInvoker always uses service-side classloader to deserialize ... also doesn't handle checked/business excs Key: TUSCANY-1679 URL: https://issues.apache.org/jira/browse/TUSCANY-1679 Project: Tuscany Issue Type: Bug Components: Java SCA Data Binding Runtime Affects Versions: Java-SCA-1.0 Reporter: Scott Kurz Assignee: Raymond Feng Fix For: Java-SCA-Next First, the easier issue: PBVInvoker doesn't handle faults.For a checked/business exc on a remotable intf, wouldn't we want the exc to get copied too? We wouldn't want some piece of data making its way into the exception to end up unexpectedly modified, right? Second, I have the problem that the service-side classloader is used to do the copy (e.g.. to do the deserialize in JavaBeansDataBinding.copy() ). While this is what I want when copying the inputs, it is not necessarily what I want when copying the outputs (or the faults which I want to copy above). I might, for example, want to use a client-side classloader to deserialize the copied objects into. Maybe it wouldn't matter if I was going to do a data transform anyway, but if my outputs/faults are going to go back to the client untransformed, then I'm going to get a ClassCastExc if they're not in the client classloader. I'm not sure how to fix this... Note this JIRA, as I could imagine the fixes to these two issues intersecting: https://issues.apache.org/jira/browse/TUSCANY-1678 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-2042) Dynamically generated WSDL not generating output message for void types
[
https://issues.apache.org/jira/browse/TUSCANY-2042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12567848#action_12567848
]
Scott Kurz commented on TUSCANY-2042:
-
It is looking more like an Axis2 versioning issue for me.
In 1.3, Axis2 J2W seems to switch from generating:
* wsdl def TNS=xxx
* schema TNS for wrapper elems = xxx/xsd
like it did in Axis2 1.2,
to simply:
* wsdl def TNS=xxx
* schema TNS for wrapper elems = xxx
which looks to be my issue.
Dynamically generated WSDL not generating output message for void types
-
Key: TUSCANY-2042
URL: https://issues.apache.org/jira/browse/TUSCANY-2042
Project: Tuscany
Issue Type: Bug
Reporter: Lou Amodeo
Fix For: Java-SCA-Next
Attachments: helloworld-ws-asynch.jar
This problem is similar to Tuscany-1658 but it appears the fix is not working
properly in all cases. I am finding that the
namespace and element namespace values assigned durig the dynamic wsdl
definition generation are causing the following code to not function because
theif (element.getAttribute(targetNamespace).equals(namespaceURI)) {
is returning false. This is because the target namespace is being generated
as : targetNamespace=http://helloworld
while the element namespace is : http://helloworld/xsd
The method signature is : public void getGreetings(String name)
class: Java2WSDLHelper.java
private static void processNoArgAndVoidReturnMethods(Definition definition,
Class javaInterface) {
String namespaceURI = definition.getTargetNamespace();
String prefix = definition.getPrefix(namespaceURI);
String xsPrefix =
definition.getPrefix(http://www.w3.org/2001/XMLSchema;);
PortType portType =
(PortType)definition.getAllPortTypes().values().iterator().next();
Element schema = null;
Document document = null;
Types types = definition.getTypes();
if (types != null) {
for (Object ext : types.getExtensibilityElements()) {
if (ext instanceof Schema) {
Element element = ((Schema)ext).getElement();
if
(element.getAttribute(targetNamespace).equals(namespaceURI)) {
schema = element;
document = schema.getOwnerDocument();
break;
}
}
}
}
if (document == null) {
return;
}
Definition generated:
Definition: name=null targetNamespace=http://helloworld
Types:
SchemaExtensibilityElement ({http://www.w3.org/2001/XMLSchema}schema):
required=null
element=[xs:schema: null]
Message: name={http://helloworld}getGreetingsMessage
Part: name=part1
elementName={http://helloworld/xsd}getGreetings
PortType: name={http://helloworld}HelloWorldServicePortType
Operation: name=getGreetings
style=ONE_WAY,0
Input: name=null
Message: name={http://helloworld}getGreetingsMessage
Part: name=part1
elementName={http://helloworld/xsd}getGreetings
Binding: name={http://helloworld}HelloWorldServiceSOAP12Binding
PortType: name={http://helloworld}HelloWorldServicePortType
Operation: name=getGreetings
style=ONE_WAY,0
Input: name=null
Message: name={http://helloworld}getGreetingsMessage
Part: name=part1
elementName={http://helloworld/xsd}getGreetings
BindingOperation: name=getGreetings
BindingInput: name=null
SOAPBody ({http://schemas.xmlsoap.org/wsdl/soap12/}body):
required=null
use=literal
namespaceURI=http://helloworld
SOAPOperation ({http://schemas.xmlsoap.org/wsdl/soap12/}operation):
required=null
soapActionURI=urn:getGreetings
style=document
SOAPBinding ({http://schemas.xmlsoap.org/wsdl/soap12/}binding):
required=null
transportURI=http://schemas.xmlsoap.org/soap/http
style=document
Binding: name={http://helloworld}HelloWorldServiceSOAP11Binding
PortType: name={http://helloworld}HelloWorldServicePortType
Operation: name=getGreetings
style=ONE_WAY,0
Input: name=null
Message: name={http://helloworld}getGreetingsMessage
Part: name=part1
elementName={http://helloworld/xsd}getGreetings
BindingOperation: name=getGreetings
BindingInput: name=null
SOAPBody ({http://schemas.xmlsoap.org/wsdl/soap/}body):
required=null
use=literal
namespaceURI=http://helloworld
SOAPOperation ({http://schemas.xmlsoap.org/wsdl/soap/}operation):
required=null
soapActionURI=urn:getGreetings
style=document
SOAPBinding ({http://schemas.xmlsoap.org/wsdl/soap/}binding):
required=null
transportURI=http://schemas.xmlsoap.org/soap/http
style=document
Service: name={http://helloworld}HelloWorldService
Port: name=HelloWorldServiceSOAP11port
Binding: name={http://helloworld}HelloWorldServiceSOAP11Binding
PortType:
[jira] Commented: (TUSCANY-2042) Dynamically generated WSDL not generating output message for void types
[
https://issues.apache.org/jira/browse/TUSCANY-2042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12567709#action_12567709
]
Scott Kurz commented on TUSCANY-2042:
-
I recreated this at the same time as stepping through the debugger.
I saw a problem here:
(not sure if it's the same as you
Dynamically generated WSDL not generating output message for void types
-
Key: TUSCANY-2042
URL: https://issues.apache.org/jira/browse/TUSCANY-2042
Project: Tuscany
Issue Type: Bug
Reporter: Lou Amodeo
Attachments: helloworld-ws-asynch.jar
This problem is similar to Tuscany-1658 but it appears the fix is not working
properly in all cases. I am finding that the
namespace and element namespace values assigned durig the dynamic wsdl
definition generation are causing the following code to not function because
theif (element.getAttribute(targetNamespace).equals(namespaceURI)) {
is returning false. This is because the target namespace is being generated
as : targetNamespace=http://helloworld
while the element namespace is : http://helloworld/xsd
The method signature is : public void getGreetings(String name)
class: Java2WSDLHelper.java
private static void processNoArgAndVoidReturnMethods(Definition definition,
Class javaInterface) {
String namespaceURI = definition.getTargetNamespace();
String prefix = definition.getPrefix(namespaceURI);
String xsPrefix =
definition.getPrefix(http://www.w3.org/2001/XMLSchema;);
PortType portType =
(PortType)definition.getAllPortTypes().values().iterator().next();
Element schema = null;
Document document = null;
Types types = definition.getTypes();
if (types != null) {
for (Object ext : types.getExtensibilityElements()) {
if (ext instanceof Schema) {
Element element = ((Schema)ext).getElement();
if
(element.getAttribute(targetNamespace).equals(namespaceURI)) {
schema = element;
document = schema.getOwnerDocument();
break;
}
}
}
}
if (document == null) {
return;
}
Definition generated:
Definition: name=null targetNamespace=http://helloworld
Types:
SchemaExtensibilityElement ({http://www.w3.org/2001/XMLSchema}schema):
required=null
element=[xs:schema: null]
Message: name={http://helloworld}getGreetingsMessage
Part: name=part1
elementName={http://helloworld/xsd}getGreetings
PortType: name={http://helloworld}HelloWorldServicePortType
Operation: name=getGreetings
style=ONE_WAY,0
Input: name=null
Message: name={http://helloworld}getGreetingsMessage
Part: name=part1
elementName={http://helloworld/xsd}getGreetings
Binding: name={http://helloworld}HelloWorldServiceSOAP12Binding
PortType: name={http://helloworld}HelloWorldServicePortType
Operation: name=getGreetings
style=ONE_WAY,0
Input: name=null
Message: name={http://helloworld}getGreetingsMessage
Part: name=part1
elementName={http://helloworld/xsd}getGreetings
BindingOperation: name=getGreetings
BindingInput: name=null
SOAPBody ({http://schemas.xmlsoap.org/wsdl/soap12/}body):
required=null
use=literal
namespaceURI=http://helloworld
SOAPOperation ({http://schemas.xmlsoap.org/wsdl/soap12/}operation):
required=null
soapActionURI=urn:getGreetings
style=document
SOAPBinding ({http://schemas.xmlsoap.org/wsdl/soap12/}binding):
required=null
transportURI=http://schemas.xmlsoap.org/soap/http
style=document
Binding: name={http://helloworld}HelloWorldServiceSOAP11Binding
PortType: name={http://helloworld}HelloWorldServicePortType
Operation: name=getGreetings
style=ONE_WAY,0
Input: name=null
Message: name={http://helloworld}getGreetingsMessage
Part: name=part1
elementName={http://helloworld/xsd}getGreetings
BindingOperation: name=getGreetings
BindingInput: name=null
SOAPBody ({http://schemas.xmlsoap.org/wsdl/soap/}body):
required=null
use=literal
namespaceURI=http://helloworld
SOAPOperation ({http://schemas.xmlsoap.org/wsdl/soap/}operation):
required=null
soapActionURI=urn:getGreetings
style=document
SOAPBinding ({http://schemas.xmlsoap.org/wsdl/soap/}binding):
required=null
transportURI=http://schemas.xmlsoap.org/soap/http
style=document
Service: name={http://helloworld}HelloWorldService
Port: name=HelloWorldServiceSOAP11port
Binding: name={http://helloworld}HelloWorldServiceSOAP11Binding
PortType: name={http://helloworld}HelloWorldServicePortType
Operation: name=getGreetings
style=ONE_WAY,0
Input: name=null
Message: name={http://helloworld}getGreetingsMessage
Part: name=part1
[jira] Issue Comment Edited: (TUSCANY-2042) Dynamically generated WSDL not generating output message for void types
[
https://issues.apache.org/jira/browse/TUSCANY-2042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12567709#action_12567709
]
scottkurz edited comment on TUSCANY-2042 at 2/11/08 9:16 AM:
--
I recreated this at the same time as stepping through the debugger.
I saw a problem here:
Types types = definition.getTypes();
if (types != null) {
for (Object ext : types.getExtensibilityElements()) {
if (ext instanceof Schema) {
Element element = ((Schema)ext).getElement();
if
(element.getAttribute(targetNamespace).equals(namespaceURI)) {
I think the J2W is generating the WSDL definition with a TNS of http://blah;
while the schema TNS is being
generated as http://blah/xsd;.
This equals() was returning false, causing the 'document' ref to remain null,
causing a return soon after:
if (document == null) {
return;
I think I'm running on an older Axis2 level.. I wonder if that could have
anything to do with this?
was (Author: scottkurz):
I recreated this at the same time as stepping through the debugger.
I saw a problem here:
(not sure if it's the same as you
Dynamically generated WSDL not generating output message for void types
-
Key: TUSCANY-2042
URL: https://issues.apache.org/jira/browse/TUSCANY-2042
Project: Tuscany
Issue Type: Bug
Reporter: Lou Amodeo
Attachments: helloworld-ws-asynch.jar
This problem is similar to Tuscany-1658 but it appears the fix is not working
properly in all cases. I am finding that the
namespace and element namespace values assigned durig the dynamic wsdl
definition generation are causing the following code to not function because
theif (element.getAttribute(targetNamespace).equals(namespaceURI)) {
is returning false. This is because the target namespace is being generated
as : targetNamespace=http://helloworld
while the element namespace is : http://helloworld/xsd
The method signature is : public void getGreetings(String name)
class: Java2WSDLHelper.java
private static void processNoArgAndVoidReturnMethods(Definition definition,
Class javaInterface) {
String namespaceURI = definition.getTargetNamespace();
String prefix = definition.getPrefix(namespaceURI);
String xsPrefix =
definition.getPrefix(http://www.w3.org/2001/XMLSchema;);
PortType portType =
(PortType)definition.getAllPortTypes().values().iterator().next();
Element schema = null;
Document document = null;
Types types = definition.getTypes();
if (types != null) {
for (Object ext : types.getExtensibilityElements()) {
if (ext instanceof Schema) {
Element element = ((Schema)ext).getElement();
if
(element.getAttribute(targetNamespace).equals(namespaceURI)) {
schema = element;
document = schema.getOwnerDocument();
break;
}
}
}
}
if (document == null) {
return;
}
Definition generated:
Definition: name=null targetNamespace=http://helloworld
Types:
SchemaExtensibilityElement ({http://www.w3.org/2001/XMLSchema}schema):
required=null
element=[xs:schema: null]
Message: name={http://helloworld}getGreetingsMessage
Part: name=part1
elementName={http://helloworld/xsd}getGreetings
PortType: name={http://helloworld}HelloWorldServicePortType
Operation: name=getGreetings
style=ONE_WAY,0
Input: name=null
Message: name={http://helloworld}getGreetingsMessage
Part: name=part1
elementName={http://helloworld/xsd}getGreetings
Binding: name={http://helloworld}HelloWorldServiceSOAP12Binding
PortType: name={http://helloworld}HelloWorldServicePortType
Operation: name=getGreetings
style=ONE_WAY,0
Input: name=null
Message: name={http://helloworld}getGreetingsMessage
Part: name=part1
elementName={http://helloworld/xsd}getGreetings
BindingOperation: name=getGreetings
BindingInput: name=null
SOAPBody ({http://schemas.xmlsoap.org/wsdl/soap12/}body):
required=null
use=literal
namespaceURI=http://helloworld
SOAPOperation ({http://schemas.xmlsoap.org/wsdl/soap12/}operation):
required=null
soapActionURI=urn:getGreetings
style=document
SOAPBinding ({http://schemas.xmlsoap.org/wsdl/soap12/}binding):
required=null
transportURI=http://schemas.xmlsoap.org/soap/http
style=document
Binding: name={http://helloworld}HelloWorldServiceSOAP11Binding
PortType: name={http://helloworld}HelloWorldServicePortType
Operation: name=getGreetings
style=ONE_WAY,0
Input: name=null
Message:
[jira] Created: (TUSCANY-2010) Default binding URI for service from Composite impl component is incorrect
Default binding URI for service from Composite impl component is incorrect
--
Key: TUSCANY-2010
URL: https://issues.apache.org/jira/browse/TUSCANY-2010
Project: Tuscany
Issue Type: Bug
Components: Java SCA Assembly Model
Affects Versions: Java-SCA-1.0.1
Reporter: Scott Kurz
Priority: Minor
Fix For: Java-SCA-1.1
Consider the following two SCDL files, a top-level SCDL with a component
implemented in a 2nd SCDL file:
!-- top-level SCDL excerpt --
component name=MultiplyComponent
implementation.composite name=multiply:MultiplyComposite/
/component
!-- composite impl SCDL excerpt --
composite xmlns=http://www.osoa.org/xmlns/sca/1.0;
name=MultiplyComposite
service name=MultiplyService
promote=InnerMultiplyComponent/MultiplyService
interface.java /
/service
component name=InnerMultiplyComponent
implementation.java... /
/component
/composite
It seems that, based on the current CompositeConfigurationBuilderImpl.java code
in the assembly module, I am going to end up with an effective default binding
URI of MultiplyComponent/MultiplyComponent instead of simply the correct
MultiplyComponent.
It seems like one fix is to change this segment:
// around line 109
Implementation implementation = component.getImplementation();
if (implementation instanceof Composite) {
// Process nested composite
// configureComponents((Composite)implementation,
componentURI); //PROBLEM
configureComponents((Composite)implementation, null);
//SEEMS TO WORK
}
However, I'm not sure if I'm giving this the thought this deserves. For
example I see Sebastien made a change in r592270 and I'm not sure why.
Maybe there's a better solution.Could we possibly want to, in some cases,
do something like:
URI.create(String).relativize(URI.create(String))
in one or more case where we now do:
URI.create(String).resolve(String)
?
Just throwing that out there
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1938) doc-lit-wrapped WSDLs with wrapper elems with non-substitution-group refs are incorrectly treated as non-wrapped
[ https://issues.apache.org/jira/browse/TUSCANY-1938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12559236#action_12559236 ] Scott Kurz commented on TUSCANY-1938: - It works now (operation is treated as 'wrapped') with a WSDL like the one I'd attached. Thanks. doc-lit-wrapped WSDLs with wrapper elems with non-substitution-group refs are incorrectly treated as non-wrapped Key: TUSCANY-1938 URL: https://issues.apache.org/jira/browse/TUSCANY-1938 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-1.0 Reporter: Scott Kurz Assignee: Raymond Feng Attachments: helloworld.wsdl The JAX-WS Spec, Sec. 2.3.1.2, makes the following confusing statement in defining the WSDL style which qualifies for mapping to wrapped Java: ... (v) The wrapper elements only contain child elements, they must not contain other structures such as wildcards (element or attribute), xsd:choice, substitution groups (element references are not permitted) or attributes; furthermore, they must not be nillable. I think the Tuscany interpretation of this statement is wrong in treating certain WSDLs as non-wrapped rather than wrapped. This makes it hard to, say, consistently choose to work in the doc-lit-wrapped WSDL style with a pre-existing WSDL file. I'll attach a WSDL file for reference, but let me show an excerpt. This is not treated as wrapped by Tuscany: element name=person type=tns:Person/ complexType name=Person sequence element name=firstName type=xsd:string/ element name=lastName type=xsd:string/ /sequence /complexType element name=getGreetings complexType sequence element name=greeting type=xsd:string/ element ref=tns:person/ /sequence /complexType /element IMO, the JAX-WS RI toolset, (wsimport) has the best interpretation of the JAX-WS spec.The 'wsimport' tool will treat this as wrapped, (i.e. gen the Java with @RequestWrapper), which I think is correct. (BTW, a service impl that I wrote from this WSDL worked fine on an IBM WAS 6.1 runtime with JAX-WS support.) In the sample WSDL attached, I show what I think the JAX-WS spec is trying to disallow. The key point I think is that they're trying to disallow use of substitution groups. So, if 'person' above had been an abstract element with an associated substitution group, then JAX-WS RI would map this in a non--wrapped style. This also fits with the fact that the statement (element references are not permitted) is not made in a separate sub-bullet, but only in parentheses directly next to substitution groups. Though I still can't explain exactly why the authors phrased it the way they did ! As further proof this is confusing, here's another JIRA on the exact same subject on the CXF project (which apparently hasn't been resolved). https://issues.apache.org/jira/browse/CXF-1079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12531198 Within the Tuscany runtime, I believe this function is implemented in the WSDLOperationIntrospectorImpl$Wrapper.getChildElements() method. There may or may not be a Tuscany tools hit here as well. I haven't checked. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1938) doc-lit-wrapped WSDLs with wrapper elems with non-substitution-group refs are incorrectly treated as non-wrapped
doc-lit-wrapped WSDLs with wrapper elems with non-substitution-group refs are incorrectly treated as non-wrapped Key: TUSCANY-1938 URL: https://issues.apache.org/jira/browse/TUSCANY-1938 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-1.0 Reporter: Scott Kurz The JAX-WS Spec, Sec. 2.3.1.2, makes the following confusing statement in defining the WSDL style which qualifies for mapping to wrapped Java: ... (v) The wrapper elements only contain child elements, they must not contain other structures such as wildcards (element or attribute), xsd:choice, substitution groups (element references are not permitted) or attributes; furthermore, they must not be nillable. I think the Tuscany interpretation of this statement is wrong in treating certain WSDLs as non-wrapped rather than wrapped. This makes it hard to, say, consistently choose to work in the doc-lit-wrapped WSDL style with a pre-existing WSDL file. I'll attach a WSDL file for reference, but let me show an excerpt. This is not treated as wrapped by Tuscany: element name=person type=tns:Person/ complexType name=Person sequence element name=firstName type=xsd:string/ element name=lastName type=xsd:string/ /sequence /complexType element name=getGreetings complexType sequence element name=greeting type=xsd:string/ element ref=tns:person/ /sequence /complexType /element IMO, the JAX-WS RI toolset, (wsimport) has the best interpretation of the JAX-WS spec.The 'wsimport' tool will treat this as wrapped, (i.e. gen the Java with @RequestWrapper), which I think is correct. (BTW, a service impl that I wrote from this WSDL worked fine on an IBM WAS 6.1 runtime with JAX-WS support.) In the sample WSDL attached, I show what I think the JAX-WS spec is trying to disallow. The key point I think is that they're trying to disallow use of substitution groups. So, if 'person' above had been an abstract element with an associated substitution group, then JAX-WS RI would map this in a non--wrapped style. This also fits with the fact that the statement (element references are not permitted) is not made in a separate sub-bullet, but only in parentheses directly next to substitution groups. Though I still can't explain exactly why the authors phrased it the way they did ! As further proof this is confusing, here's another JIRA on the exact same subject on the CXF project (which apparently hasn't been resolved). https://issues.apache.org/jira/browse/CXF-1079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12531198 Within the Tuscany runtime, I believe this function is implemented in the WSDLOperationIntrospectorImpl$Wrapper.getChildElements() method. There may or may not be a Tuscany tools hit here as well. I haven't checked. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1938) doc-lit-wrapped WSDLs with wrapper elems with non-substitution-group refs are incorrectly treated as non-wrapped
[ https://issues.apache.org/jira/browse/TUSCANY-1938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Kurz updated TUSCANY-1938: Attachment: helloworld.wsdl doc-lit-wrapped WSDLs with wrapper elems with non-substitution-group refs are incorrectly treated as non-wrapped Key: TUSCANY-1938 URL: https://issues.apache.org/jira/browse/TUSCANY-1938 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-1.0 Reporter: Scott Kurz Attachments: helloworld.wsdl The JAX-WS Spec, Sec. 2.3.1.2, makes the following confusing statement in defining the WSDL style which qualifies for mapping to wrapped Java: ... (v) The wrapper elements only contain child elements, they must not contain other structures such as wildcards (element or attribute), xsd:choice, substitution groups (element references are not permitted) or attributes; furthermore, they must not be nillable. I think the Tuscany interpretation of this statement is wrong in treating certain WSDLs as non-wrapped rather than wrapped. This makes it hard to, say, consistently choose to work in the doc-lit-wrapped WSDL style with a pre-existing WSDL file. I'll attach a WSDL file for reference, but let me show an excerpt. This is not treated as wrapped by Tuscany: element name=person type=tns:Person/ complexType name=Person sequence element name=firstName type=xsd:string/ element name=lastName type=xsd:string/ /sequence /complexType element name=getGreetings complexType sequence element name=greeting type=xsd:string/ element ref=tns:person/ /sequence /complexType /element IMO, the JAX-WS RI toolset, (wsimport) has the best interpretation of the JAX-WS spec.The 'wsimport' tool will treat this as wrapped, (i.e. gen the Java with @RequestWrapper), which I think is correct. (BTW, a service impl that I wrote from this WSDL worked fine on an IBM WAS 6.1 runtime with JAX-WS support.) In the sample WSDL attached, I show what I think the JAX-WS spec is trying to disallow. The key point I think is that they're trying to disallow use of substitution groups. So, if 'person' above had been an abstract element with an associated substitution group, then JAX-WS RI would map this in a non--wrapped style. This also fits with the fact that the statement (element references are not permitted) is not made in a separate sub-bullet, but only in parentheses directly next to substitution groups. Though I still can't explain exactly why the authors phrased it the way they did ! As further proof this is confusing, here's another JIRA on the exact same subject on the CXF project (which apparently hasn't been resolved). https://issues.apache.org/jira/browse/CXF-1079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12531198 Within the Tuscany runtime, I believe this function is implemented in the WSDLOperationIntrospectorImpl$Wrapper.getChildElements() method. There may or may not be a Tuscany tools hit here as well. I haven't checked. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1926) Problem w/ JDKInvocationHandler with dynamic reference with WSDLinterface
Problem w/ JDKInvocationHandler with dynamic reference with WSDLinterface
-
Key: TUSCANY-1926
URL: https://issues.apache.org/jira/browse/TUSCANY-1926
Project: Tuscany
Issue Type: Bug
Reporter: Scott Kurz
Priority: Minor
I found another case where the JDKInvocationHandler.match() doesn't handle WSDL
interfaces.
Earlier problems in this area were:
https://issues.apache.org/jira/browse/TUSCANY-1342
https://issues.apache.org/jira/browse/TUSCANY-1473
I'm not sure, however, if this a boundary case problem since my operation a
zero-arg operation or if
there's a bigger problem.
Say MyServiceImpl is a component impl looking like:
public class MyServiceImpl implements MyService
{
@Context
public ComponentContext context;
public MyService2 getService2()
{ return context.getService(MyService2.class, myRef);
}
}
And say the SCDL configuration of MyServiceImpl's component looks like:
component name=MyServiceComponent
implementation.java class=MyServiceImpl/
reference name=myRef
interface.wsdl interface=.portType corresponding to MyService2./
binding.ws wsdlElement=..port.../
/reference
/component
Now, I think in most cases we've dealt with, the myRef reference of
MyServiceComponent is going to be declared
statically with a @Reference in MyServiceImpl. I believe, though, that
what I pasted is legal even though the
reference is not a part of the static Java component implementation.
I noticed this doesn't work ... though I ran with a very special case of a
zero-parm operation.I noticed the problem
where the input sizes don't match up (0 in Java vs. 1 in WSDL since we have the
single, empty input wrapper elem), like
the one Raymond had fixed in the past in DataBindingRuntimeWireProcessor.
But I wonder if this was only the first problem, since I noticed in my similar
working case, my wire source operation was Java
intf-based even with the interface.wsdl config in SCDL.
I'm not sure though.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1899) Java2WSDL (trivial) - do we have to assume method names start w/ a lowercase char?
Java2WSDL (trivial) - do we have to assume method names start w/ a lowercase char? -- Key: TUSCANY-1899 URL: https://issues.apache.org/jira/browse/TUSCANY-1899 Project: Tuscany Issue Type: Bug Components: Java SCA Tools, Java SDO Tools Affects Versions: Java-SCA-1.0, Java-SCA-1.0.1 Reporter: Scott Kurz Priority: Trivial The fact that: TuscanyWSDLTypesGenerator .createSchemaTypeForMethodPart on line 267 calls: globalElement.setName(formGlobalElementName(localPartName)); which lowercases the first char in the parm passed to formGlobalElementName ends up implying that method names must start in a lowercase char. Because otherwise..the elem name so constructed won't match the operation name... which will cause us to not end up with doc-lit-wrapped WSDL. Since everyone uses lowercase method names this in Java, I ranked this as 'trivial'. Still, I opened this anyway because I didn't see why we bother to lowercase this string at all, and thought that if someone cancelled this JIRA, at least I'd learn there was a good reason for doing so. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1902) Input2InputTransformer doesn't handle null input going from SDO-AXIOM
[ https://issues.apache.org/jira/browse/TUSCANY-1902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Kurz updated TUSCANY-1902: Fix Version/s: (was: Java-SCA-1.0.1) Input2InputTransformer doesn't handle null input going from SDO-AXIOM -- Key: TUSCANY-1902 URL: https://issues.apache.org/jira/browse/TUSCANY-1902 Project: Tuscany Issue Type: Bug Components: Java SCA Data Binding Runtime Affects Versions: Java-SCA-1.0 Reporter: Scott Kurz Priority: Minor I get the following: java.lang.NullPointerException at org.apache.tuscany.sca.core.databinding.transformers.Input2InputTransformer.transform(Input2InputTransformer.java:127) at org.apache.tuscany.sca.core.databinding.transformers.Input2InputTransformer.transform(Input2InputTransformer.java:46) at org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate(MediatorImpl.java:73) when invoking a method such as: public Person getGreetings() where Person is an SDO causing the SDO databinding to be set at the impl DB level, and where I am using the WS binding, causing AXIOM to be used as the target DB. I'll attach a simple patch to check for null first in the unwrapped-wrapped case in which the problem occurs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1902) Input2InputTransformer doesn't handle null input going from SDO-AXIOM
Input2InputTransformer doesn't handle null input going from SDO-AXIOM -- Key: TUSCANY-1902 URL: https://issues.apache.org/jira/browse/TUSCANY-1902 Project: Tuscany Issue Type: Bug Components: Java SCA Data Binding Runtime Affects Versions: Java-SCA-1.0 Reporter: Scott Kurz Priority: Minor Fix For: Java-SCA-1.0.1 I get the following: java.lang.NullPointerException at org.apache.tuscany.sca.core.databinding.transformers.Input2InputTransformer.transform(Input2InputTransformer.java:127) at org.apache.tuscany.sca.core.databinding.transformers.Input2InputTransformer.transform(Input2InputTransformer.java:46) at org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate(MediatorImpl.java:73) when invoking a method such as: public Person getGreetings() where Person is an SDO causing the SDO databinding to be set at the impl DB level, and where I am using the WS binding, causing AXIOM to be used as the target DB. I'll attach a simple patch to check for null first in the unwrapped-wrapped case in which the problem occurs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1681) DataObject2XMLStreamReader can't handle a null (or could this be an SDO bug??)
[ https://issues.apache.org/jira/browse/TUSCANY-1681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Kurz updated TUSCANY-1681: Attachment: 1681.patch Well, let me push the issue a bit by at least submitting a patch to return null from each of the transformers: XMLStreamReader2DataObject and DataObject2XMLStreamReader upon passing a null 'source' as input. I'm not sure if an alternative solution would be to, say, have DataObject2XMLStreamReader pass back a XMLStreamReader upon receiving a 'null' DataObject as input, in which case we could probably remove this change to XMLStreamReader2DataObject . And it's conceivable the SDO impl should be changed to handle passing a null SDO into XMLHelper.createDocument() and to pass back such a non-null XMLStreamReader in such a case. DataObject2XMLStreamReader can't handle a null (or could this be an SDO bug??) -- Key: TUSCANY-1681 URL: https://issues.apache.org/jira/browse/TUSCANY-1681 Project: Tuscany Issue Type: Bug Components: Java SCA Data Binding Runtime Reporter: Scott Kurz Fix For: Java-SCA-Next Attachments: 1681.patch When passing a null object into DataObject2XMLStreamReader I hit a NPE: java.lang.NullPointerException at org.apache.tuscany.sdo.util.resource.DataObjectXMLStreamReader.populateProperties(DataObjectXMLStreamReader.java:277) at org.apache.tuscany.sdo.util.resource.DataObjectXMLStreamReader.init(DataObjectXMLStreamReader.java:116) at org.apache.tuscany.sdo.util.resource.DataObjectXMLStreamReader.init(DataObjectXMLStreamReader.java:104) at org.apache.tuscany.sdo.helper.XMLStreamHelperImpl.createXMLStreamReader(XMLStreamHelperImpl.java:80) at org.apache.tuscany.sca.databinding.sdo.DataObject2XMLStreamReader.transform(DataObject2XMLStreamReader.java:48) at org.apache.tuscany.sca.databinding.sdo.DataObject2XMLStreamReader.transform(DataObject2XMLStreamReader.java:37) at org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate(MediatorImpl.java:77) This is either: * a bug in this specific transformer (my guess) * a bug in SDO (I'm guessing not) * a bug in the Tuscany databinding framework which should special case nulls (I'd think we might want to let transforms decide on their own how to handle null?) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1206) DataBinding support for transform of Fault DataTypes should account for wrappered FaultBean in JAX-WS style
[
https://issues.apache.org/jira/browse/TUSCANY-1206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Scott Kurz updated TUSCANY-1206:
Attachment: 1206.a.patch
This is a patch created against r558780. It is, for a few reasons, not ready
to be applied as-is.
At the least, we'd want to port to whatever changes have probably been made (I
haven't checked what these might be) and use a real registry for the fault
pattern handlers instead of the dummy one I made.
But I wanted to help move this discussion along:
http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg24973.html
DataBinding support for transform of Fault DataTypes should account for
wrappered FaultBean in JAX-WS style
---
Key: TUSCANY-1206
URL: https://issues.apache.org/jira/browse/TUSCANY-1206
Project: Tuscany
Issue Type: Improvement
Components: Java SCA Core Runtime
Affects Versions: Java-SCA-Next
Reporter: Scott Kurz
Fix For: Java-SCA-Next
Attachments: 1206.a.patch
I wonder if the DataBindingJavaInterfaceProcessor should be introspecting the
FaultBean rather than the exception type itself in order to
calculate the databinding.
In the code we do:
for ( org.apache.tuscany.spi.model.DataType? d :
operation.getFaultTypes()) {
dataBindingRegistry.introspectType(d, annotations);
}
Following JAX-WS, say my fault type is a POJO Java class extending Exception
with a getFaultInfo() returning an SDO type (this SDO is the FaultBean).
If SDODataBinding.introspect() was called to introspect my FaultBean type,
then, you would be able to calculate I wanted SDO databinding (since I load
the fault type with import.sdo).
But since only my POJO wrapper exc is introspected I end up getting a null DB.
Maybe another solution would be to push the responsibility to check for a
FaultBean returned by getFaultInfo() onto an individual DataBindingExtension
class, e.g. SDODataBinding.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1826) DataTransformationInteceptor should be spelled: DataTransformationInterceptor
DataTransformationInteceptor should be spelled: DataTransformationInterceptor --- Key: TUSCANY-1826 URL: https://issues.apache.org/jira/browse/TUSCANY-1826 Project: Tuscany Issue Type: Improvement Components: Java SCA Data Binding Runtime Affects Versions: Java-SCA-Next Reporter: Scott Kurz Priority: Trivial Maybe this is too trivial but after 1.0 maybe someone would be interested in doing this. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1818) XMLStreamSerializer - IllegalStateException caused by unnecessary XMLStreamWriter calls
[ https://issues.apache.org/jira/browse/TUSCANY-1818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Kurz updated TUSCANY-1818: Attachment: 1818.patch XMLStreamSerializer - IllegalStateException caused by unnecessary XMLStreamWriter calls Key: TUSCANY-1818 URL: https://issues.apache.org/jira/browse/TUSCANY-1818 Project: Tuscany Issue Type: Improvement Affects Versions: Java-SCA-Next Reporter: Scott Kurz Priority: Minor Attachments: 1818.patch Hit the following error when using an XLXP impl of StAX. java.lang.IllegalStateException: writeNamespace() can only be called following writeStartElement() or writeEmptyElement(). at com.ibm.xml.xlxp.api.stax.msg.StAXMessageProvider.throwIllegalStateException(StAXMessageProvider.java:45) at com.ibm.xml.xlxp.api.stax.XMLStreamWriterBase.writeNamespace(XMLStreamWriterBase.java:514) at com.ibm.xml.xlxp.api.stax.XMLOutputFactoryImpl$XMLStreamWriterProxy.writeNamespace(XMLOutputFactoryImpl.java:148) at org.apache.tuscany.sca.databinding.xml.XMLStreamSerializer.serializeNamespace(XMLStreamSerializer.java:227) at org.apache.tuscany.sca.databinding.xml.XMLStreamSerializer.serializeElement(XMLStreamSerializer.java:198) at org.apache.tuscany.sca.databinding.xml.XMLStreamSerializer.serializeNode(XMLStreamSerializer.java:243) at org.apache.tuscany.sca.databinding.xml.XMLStreamSerializer.serialize(XMLStreamSerializer.java:70) at org.apache.tuscany.sca.databinding.xml.StAXHelper.save(StAXHelper.java:76) Call sequence of: writer.writeStartElement(...) writer.writeNamespace(...) writer.setPrefix(...) writer.writeNamespace(...) writer.setPrefix(...) is not tolerated by XLXP. I believe the setPrefix() calls are unnecessary since the prefix is passed into writeNamespace(), and that this should be fine with other Stax impls like Woodstox. I'll attach a patch today. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1818) XMLStreamSerializer - IllegalStateException caused by unnecessary XMLStreamWriter calls
XMLStreamSerializer - IllegalStateException caused by unnecessary XMLStreamWriter calls Key: TUSCANY-1818 URL: https://issues.apache.org/jira/browse/TUSCANY-1818 Project: Tuscany Issue Type: Improvement Affects Versions: Java-SCA-Next Reporter: Scott Kurz Priority: Minor Hit the following error when using an XLXP impl of StAX. java.lang.IllegalStateException: writeNamespace() can only be called following writeStartElement() or writeEmptyElement(). at com.ibm.xml.xlxp.api.stax.msg.StAXMessageProvider.throwIllegalStateException(StAXMessageProvider.java:45) at com.ibm.xml.xlxp.api.stax.XMLStreamWriterBase.writeNamespace(XMLStreamWriterBase.java:514) at com.ibm.xml.xlxp.api.stax.XMLOutputFactoryImpl$XMLStreamWriterProxy.writeNamespace(XMLOutputFactoryImpl.java:148) at org.apache.tuscany.sca.databinding.xml.XMLStreamSerializer.serializeNamespace(XMLStreamSerializer.java:227) at org.apache.tuscany.sca.databinding.xml.XMLStreamSerializer.serializeElement(XMLStreamSerializer.java:198) at org.apache.tuscany.sca.databinding.xml.XMLStreamSerializer.serializeNode(XMLStreamSerializer.java:243) at org.apache.tuscany.sca.databinding.xml.XMLStreamSerializer.serialize(XMLStreamSerializer.java:70) at org.apache.tuscany.sca.databinding.xml.StAXHelper.save(StAXHelper.java:76) Call sequence of: writer.writeStartElement(...) writer.writeNamespace(...) writer.setPrefix(...) writer.writeNamespace(...) writer.setPrefix(...) is not tolerated by XLXP. I believe the setPrefix() calls are unnecessary since the prefix is passed into writeNamespace(), and that this should be fine with other Stax impls like Woodstox. I'll attach a patch today. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (TUSCANY-1142) Need to allow generation of wrapped Java intf from doc-lit-wrap WSDL with named complexType
[
https://issues.apache.org/jira/browse/TUSCANY-1142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Scott Kurz reopened TUSCANY-1142:
-
I haven't tested the very latest code but by inspection and trying a recent
build, I'd say this is unresolved.
If you take this WSDL as an example:
sca/modules/wsdl2java/src/test/resources/AccountService.wsdl
Here is an example
The operation:
wsdl:operation name=getAccountReportBare1Complex
with input wrapper elem:
xsd:element name=getAccountReportBare1Complex
type=account:AccountRequest/
should be generated in the wrapped style. Today I believe non-wrapped Java is
still being generated.
--
One point that Yang and I missed in our original comments on this JIRA is that
we need to make sure we do NOT
try to generate wrapped Java when the input element is of a single type. We
might add that as check #5 in Yang's suggest
list then:
5) make sure element is of complexType (or go further and say complexType
defined by sequence)
The current code does not have this problem and correctly detects this as
non-wrapped, for example operation: getAccountReportBare1Simple
in the same WSDL.
Just mentioning this since I had missed this case in my original writeup, which
Tuscany is already handling correclty. Don't want to lose this.
Need to allow generation of wrapped Java intf from doc-lit-wrap WSDL with
named complexType
Key: TUSCANY-1142
URL: https://issues.apache.org/jira/browse/TUSCANY-1142
Project: Tuscany
Issue Type: Bug
Components: Java SCA Tools
Affects Versions: Java-SCA-M2
Reporter: Scott Kurz
Fix For: Java-SCA-1.0
Our WSDL2Java tool maps the following WSDL pattern onto a non-wrapped Java
interface even when using doc-lit-wrapped WSDL:
...types
complexType name=getGreetings
sequence
element name=name type=xsd:string/
/sequence
/complexType
element name=getGreetings type=tns:getGreetings/
...
/types
I noticed that wsimport seems to unwrap this and produce:
getGreetings(String)
whereas our WSDL2Java treats this as non-wrapped and generates:
getGreetings(getGreetings)
The key line of Tuscany code is:
org.apache.tuscany.tools.wsdl2java.generate.JavaInterfaceEmitter.isWrapped()
if (typeMappingEntry.isAnonymous()) {
wrapped = true;
}
As I claim in this JIRA, TUSCANY-1019, it would be nice to ALSO have the
ability to generate a non-wrapped Java interface from the given WSDL pattern,
but we should also allow for generation of a wrapped interface (the wrapped
by my guess should be the default).
Yang Zhong posted this reply in agreement to the Tuscany dev list.
Once binding is involved within WSDL2Java, one WSDL portType/message can end
up with multiple Java classes respective to different bindings.
It mixes business logic and wire format :-(
Assuming involving binding is de facto, and only one binding each WSDL
portType/message,
maybe we can change JavaInterfaceEmitter.isWrapped to an algorithm such as:
1. not wrapped if the style is not document or the use is not literal
2. not wrapped if the message has more than one parts
3. not wrapped if the part isn't element or its local name doesn't match the
operation local name
4. not wrapped if the operation name isn't unique within the portType
Yes, I agree with Scott not to take isAnonymous() into account.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1678) Would like to improve performance by not doing a PBVInvoker.copy in a couple cases where it's unnecessary
Would like to improve performance by not doing a PBVInvoker.copy in a couple cases where it's unnecessary - Key: TUSCANY-1678 URL: https://issues.apache.org/jira/browse/TUSCANY-1678 Project: Tuscany Issue Type: Improvement Reporter: Scott Kurz Copying an SDO, for example, can be expensive... The two cases I have in mind: A) The databinding framework has done a transform which has already resulted in a copy of the data. B) The binding impl does a copy of the data. (For example if the binding impl serializes/deserializes the data in order to cross JVMs) Perhaps a flag on the Message object could be used. One challenge to doing that would be the fact that the PBVInvoker is going to do the copy of the output before the output reaches the DataTransformationInteceptor. I don't know if there's a simple way around that. I can imagine moving the PBVInvoker after the DataTransformationInteceptor on the output path but at the expense of complication the whole Interceptor / invoker chain design. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1678) Would like to improve performance by not doing a PBVInvoker.copy in a couple cases where it's unnecessary
[ https://issues.apache.org/jira/browse/TUSCANY-1678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Kurz updated TUSCANY-1678: Component/s: Java SCA Data Binding Runtime Affects Version/s: Java-SCA-1.0 Would like to improve performance by not doing a PBVInvoker.copy in a couple cases where it's unnecessary - Key: TUSCANY-1678 URL: https://issues.apache.org/jira/browse/TUSCANY-1678 Project: Tuscany Issue Type: Improvement Components: Java SCA Data Binding Runtime Affects Versions: Java-SCA-1.0 Reporter: Scott Kurz Copying an SDO, for example, can be expensive... The two cases I have in mind: A) The databinding framework has done a transform which has already resulted in a copy of the data. B) The binding impl does a copy of the data. (For example if the binding impl serializes/deserializes the data in order to cross JVMs) Perhaps a flag on the Message object could be used. One challenge to doing that would be the fact that the PBVInvoker is going to do the copy of the output before the output reaches the DataTransformationInteceptor. I don't know if there's a simple way around that. I can imagine moving the PBVInvoker after the DataTransformationInteceptor on the output path but at the expense of complication the whole Interceptor / invoker chain design. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1679) PBVInvoker always uses service-side classloader to deserialize ... also doesn't handle checked/business excs
PBVInvoker always uses service-side classloader to deserialize ... also doesn't handle checked/business excs Key: TUSCANY-1679 URL: https://issues.apache.org/jira/browse/TUSCANY-1679 Project: Tuscany Issue Type: Bug Components: Java SCA Data Binding Runtime Affects Versions: Java-SCA-1.0 Reporter: Scott Kurz First, the easier issue: PBVInvoker doesn't handle faults.For a checked/business exc on a remotable intf, wouldn't we want the exc to get copied too? We wouldn't want some piece of data making its way into the exception to end up unexpectedly modified, right? Second, I have the problem that the service-side classloader is used to do the copy (e.g.. to do the deserialize in JavaBeansDataBinding.copy() ). While this is what I want when copying the inputs, it is not necessarily what I want when copying the outputs (or the faults which I want to copy above). I might, for example, want to use a client-side classloader to deserialize the copied objects into. Maybe it wouldn't matter if I was going to do a data transform anyway, but if my outputs/faults are going to go back to the client untransformed, then I'm going to get a ClassCastExc if they're not in the client classloader. I'm not sure how to fix this... Note this JIRA, as I could imagine the fixes to these two issues intersecting: https://issues.apache.org/jira/browse/TUSCANY-1678 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1680) Need a way to detect that PBR can be used when building reference-side binding
Need a way to detect that PBR can be used when building reference-side binding -- Key: TUSCANY-1680 URL: https://issues.apache.org/jira/browse/TUSCANY-1680 Project: Tuscany Issue Type: Improvement Components: Java SCA Data Binding Runtime Affects Versions: Java-SCA-1.0 Reporter: Scott Kurz When building a ref-side binding impl for a remotable intf, I may want to do the following: * if my target is in a remote JVM, then use the Tuscany databinding framework to convert to a databinding I can handle * if my target is local, and the service impl has @AllowsPBR , then choose NOT to set up a databinding interceptor I'm not sure where to start exactly with suggesting how to implement this, so I'll start by just describing the problem. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1681) DataObject2XMLStreamReader can't handle a null (or could this be an SDO bug??)
DataObject2XMLStreamReader can't handle a null (or could this be an SDO bug??) -- Key: TUSCANY-1681 URL: https://issues.apache.org/jira/browse/TUSCANY-1681 Project: Tuscany Issue Type: Bug Components: Java SCA Samples Reporter: Scott Kurz Priority: Minor When passing a null object into DataObject2XMLStreamReader I hit a NPE: java.lang.NullPointerException at org.apache.tuscany.sdo.util.resource.DataObjectXMLStreamReader.populateProperties(DataObjectXMLStreamReader.java:277) at org.apache.tuscany.sdo.util.resource.DataObjectXMLStreamReader.init(DataObjectXMLStreamReader.java:116) at org.apache.tuscany.sdo.util.resource.DataObjectXMLStreamReader.init(DataObjectXMLStreamReader.java:104) at org.apache.tuscany.sdo.helper.XMLStreamHelperImpl.createXMLStreamReader(XMLStreamHelperImpl.java:80) at org.apache.tuscany.sca.databinding.sdo.DataObject2XMLStreamReader.transform(DataObject2XMLStreamReader.java:48) at org.apache.tuscany.sca.databinding.sdo.DataObject2XMLStreamReader.transform(DataObject2XMLStreamReader.java:37) at org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate(MediatorImpl.java:77) This is either: * a bug in this specific transformer (my guess) * a bug in SDO (I'm guessing not) * a bug in the Tuscany databinding framework which should special case nulls (I'd think we might want to let transforms decide on their own how to handle null?) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1682) DataBindingRuntimeWireProcessor bug in processing boundary condition of no-arg, no-returnType method
DataBindingRuntimeWireProcessor bug in processing boundary condition of no-arg,
no-returnType method
-
Key: TUSCANY-1682
URL: https://issues.apache.org/jira/browse/TUSCANY-1682
Project: Tuscany
Issue Type: Bug
Reporter: Scott Kurz
If I have a Java method like:
void myMethod()
it will fail if I expose this method over something like the WS binding which
results in trying to set up the Tuscany databinding framework mapping the
equivalent WSDL to the no-arg, no-return method.
The exception looks like:
java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
at java.util.ArrayList.RangeCheck(ArrayList.java:572)
at java.util.ArrayList.get(ArrayList.java:347)
at
org.apache.tuscany.core.databinding.wire.DataBindingRuntimeWireProcessor.isTransformationRequired(DataBindingRuntimeWireProcessor.java:97)
at
org.apache.tuscany.core.databinding.wire.DataBindingRuntimeWireProcessor.isTransformationRequired(DataBindingRuntimeWireProcessor.java:115)
at
org.apache.tuscany.core.databinding.wire.DataBindingRuntimeWireProcessor.process(DataBindingRuntimeWireProcessor.java:132)
at
org.apache.tuscany.sca.core.invocation.ExtensibleWireProcessor.process(ExtensibleWireProcessor.java:40)
For my failure,
The logical of the source DataType is:
[class java.lang.Object org.apache.axiom.om.OMElement Element:
{http://basicapp}doNonBlockingReq Type: null]
The logical of the target DataType is:
[] (empty array)
Now.. on the one hand this is a low-priority since this isn't a very useful
service operation.
On the other hand, the only reason we don't have the same problem on a method
like:MyReturnType myMethod()
is because for something like the WS binding, the output types will be compared
first, and this comparison will return 'true', causing the input types not to
be compared.
Some sort of special-case (possibly involving recognizing that this is
wrapped?) seems to be needed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-544) WSDL2Java should support WSDLs with schema imports
[ https://issues.apache.org/jira/browse/TUSCANY-544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12524150 ] Scott Kurz commented on TUSCANY-544: In my experience (admittedly not on the absolute latest version of the code), it's not importing XSD per-se which is the problem. In my experience, there are three issues with the WSDL/XSD pair here... 1) failed to put a targetNamespace on the schema element in WSDL types 2) You do an import into the same TNS as the WSDL TNS... the SDO-based WSDL2Java tooling assumes you are going to do an include if you're referencing an external XSD with the same TNS. The XSD2Java code I believe has the same restriction. But the BasicProfile says the style Sean pasted is legal.. and in fact wsgen.bat will generate using this type of pattern in my experience. 3) Your element and types use the same QName. I don't know which standard defines the behavior here... -- So hopefuilly this clears up and narrows down where the problems lies a bit. (not that I'm adding any code with these comments ;) WSDL2Java should support WSDLs with schema imports -- Key: TUSCANY-544 URL: https://issues.apache.org/jira/browse/TUSCANY-544 Project: Tuscany Issue Type: Bug Components: Java SCA Tools Affects Versions: Java-SCA-M2 Reporter: Ron Gavlin Assignee: Luciano Resende Fix For: Java-SCA-Next Many WSDLs choose to import schemas rather than embedding types inline. The tuscany WSDL2JavaGenerator does not currently support this type of usage. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1473) Define component's service with interface.wsdl ,throws 'No matching operation' error.
[ https://issues.apache.org/jira/browse/TUSCANY-1473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12518747 ] Scott Kurz commented on TUSCANY-1473: - This problem looks similar to TUSCANY-1342 which I opened. I commented there that for a remotable interface you can't overload the method names anyway ... and WSDL interfaces are always remotable. Define component's service with interface.wsdl ,throws 'No matching operation' error. - Key: TUSCANY-1473 URL: https://issues.apache.org/jira/browse/TUSCANY-1473 Project: Tuscany Issue Type: Bug Components: Java SCA Assembly Model Affects Versions: Java-SCA-0.91 Environment: Windows XP Reporter: wangfeng Assignee: Raymond Feng Fix For: Java-SCA-Next Attachments: testcase.zip I define the component's service with interface.java,the sample runs fine. but when I modify the component's service with interface.wsdl,the sample throws an exception. The throwable stack is : Exception in thread main java.lang.IllegalArgumentException: No matching operation is found: public abstract java.lang.String helloworld.HelloWorldService.getGreetings(java.lang.String) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:69) at $Proxy10.getGreetings(Unknown Source) at helloworld.HelloWorldClient.main(HelloWorldClient.java:33) I look into the code,found the invoke mothod's input type is 'String',but the method which name is operation.getInputType().getLogical().get(i).getPhysical() on the SourceOperation of the InvocationChain is always return 'Object' type,so can't find an operation to match. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1426) Contribution service's Artifact resolving assumes only one WSDL file per Namespace, which disallows import of portType WSDL from endpoint WSDL
Contribution service's Artifact resolving assumes only one WSDL file per Namespace, which disallows import of portType WSDL from endpoint WSDL -- Key: TUSCANY-1426 URL: https://issues.apache.org/jira/browse/TUSCANY-1426 Project: Tuscany Issue Type: Bug Reporter: Scott Kurz Priority: Minor To notice the problem, go to sca/modules/binding-ws-axis2 and modify one of the itest WSDLs by breaking it up into a portType.wsdl and an endpoint/binding WSDL. The WSDLs within a contribution are processed in alphabetical order and it looks like the single per-NS entry is getting clobbered with the 2nd WSDL files WSDL4J-based Definition. Relevant to the problem is the fact that: org/apache/tuscany/sca/interfacedef/wsdl/impl/WSDLDefinitionImpl has hashCode()/equals() methods simply focused on the String backing the Namespace. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1412) NPE in DataBindingRuntimeWireProcessor in null output boundary case (and null input?)
NPE in DataBindingRuntimeWireProcessor in null output boundary case (and null
input?)
-
Key: TUSCANY-1412
URL: https://issues.apache.org/jira/browse/TUSCANY-1412
Project: Tuscany
Issue Type: Bug
Components: Java SCA Data Binding Runtime
Affects Versions: Java-SCA-M2
Environment: r540027
Reporter: Scott Kurz
Haven't checked the latest code...but...
I have a Java method with signature:void myMethod(whatever...)
and the WSDL output wrapper elem is defined as:
xsd:element name=myMethodResponse
xsd:complexType
xsd:sequence/
/xsd:complexType
/xsd:element
I hit the following NPE when activating the Composite
Caused by: java.lang.NullPointerException
at
org.apache.tuscany.core.databinding.wire.DataBindingRuntimeWireProcessor.isTransformationRequired(DataBindingRuntimeWireProcessor.java:51)
at
org.apache.tuscany.core.databinding.wire.DataBindingRuntimeWireProcessor.isTransformationRequired(DataBindingRuntimeWireProcessor.java:72)
at
org.apache.tuscany.core.databinding.wire.DataBindingRuntimeWireProcessor.isTransformationRequired(DataBindingRuntimeWireProcessor.java:99)
at
org.apache.tuscany.core.databinding.wire.DataBindingRuntimeWireProcessor.process(DataBindingRuntimeWireProcessor.java:116)
The source DataType is:
class java.lang.Object org.apache.axiom.om.OMElement Element:
{http://blah}myMethodResponse Type: null
But the target DataType corresponding to the 'void' is simply null
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-824) DataBinding: Is it a concern of Programming Model vs. Assembly?
[
https://issues.apache.org/jira/browse/TUSCANY-824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12510391
]
Scott Kurz commented on TUSCANY-824:
I found a problem in this area when I run with my promote DataBinding to
operation level patch.. not sure if it's useful to tack onto this JIRA or not
but here goes:
I'm not sure to what degree there is a problem with Tuscany here.
SOAFP introduced the promotion of input/output/fault DBs to operation level.
This code in Output2OutputTransformer.transform() does:
} else if (sourceWrapped (!targetWrapped)) {
.
targetWrapperHandler =
getWrapperHandler(getDataBinding(targetOp), false);
if (targetWrapperHandler != null) {
ElementInfo wrapperElement =
sourceOp.getWrapper().getInputWrapperElement();
// Object targetWrapper =
// targetWrapperHandler.create(wrapperElement, context);
DataTypeXMLType targetWrapperType = new
DataTypeImplXMLType(targetType.getLogical()
.getDataBinding(), Object.class, new
XMLType(wrapperElement));
Object targetWrapper = mediator.mediate(sourceWrapper,
sourceType.getLogical(),
targetWrapperType,
context.getMetadata());
So we use operation DB to get targetWrapperHandler. But then we do the
mediation with the databinding of the output type:
targetType.getLogical().getDataBinding()
This doesn't allow a case where we have SDO DB at the operation level because
of an SDO as an input part, but we have a primitive as the output which would
have default DB.
I'm not sure if this problem exists without my DB promotion patch... I'd
guess it does since I'd expect to be able to put SDO DataBinding annotation on
the operation even with a primitive output type.. but I might not understand
the rules of the DataBinding annotation. Given this.. should this be a
separate JIRA?
DataBinding: Is it a concern of Programming Model vs. Assembly?
---
Key: TUSCANY-824
URL: https://issues.apache.org/jira/browse/TUSCANY-824
Project: Tuscany
Issue Type: Bug
Components: Java SCA Core Runtime
Affects Versions: Java-SCA-M2
Reporter: ant elder
Assignee: Raymond Feng
Priority: Critical
Fix For: Java-SCA-Next
Attachments: skurz.824.v1.patch
There have been some question about the DataBinding framework and if it
should be a concern of the Programming Model vs. Assembly?
See: http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg08679.html
and a follow up mention in:
http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg09363.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1342) Component-level interface.wsdl not supported
[ https://issues.apache.org/jira/browse/TUSCANY-1342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12509830 ] Scott Kurz commented on TUSCANY-1342: - Is this as simple as modifying method:boolean match(Operation, Method) to check if the operation is Remotable via operation.getInterface().isRemotable() If it is remotable, matching the method names is enough and if not we can fall through to, as before, look at the physical types. I don't have the latest code building and running or I'd test this out and attach a patch. Component-level interface.wsdl not supported -- Key: TUSCANY-1342 URL: https://issues.apache.org/jira/browse/TUSCANY-1342 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-0.90 Reporter: Scott Kurz See thread: http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg18780.html Something like this does not work: component name=Component_... implementation.java class=.../ reference name=helloWorldService interface.wsdl interface=.../ binding.ws wsdlElement=.../ /reference /component -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-824) DataBinding: Is it a concern of Programming Model vs. Assembly?
[
https://issues.apache.org/jira/browse/TUSCANY-824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Scott Kurz updated TUSCANY-824:
---
Attachment: skurz.824.v1.patch
This patch attempts to solve two databinding-related problems, though neither
solution has necessarily been agreed upon by the community.
First, it sets up an operation DB (if one isn't set) by looking for non-default
DBs set on the inputs/output/faults.This is what we were specifically
discussing in the thread mentioned in the JIRA.
Second, I also addressed the question of how to calculate the databinding of a
fault type.
As this comment in DataTransformationInteceptor.getFaultType() mentions:
private DataType getFaultType(DataType exceptionType) {
// FIXME: We cannot assume the exception will have a databinding set
there might be no DB on the exception type.The case I was trying to address
was the case that the exception class was a POJO with no
special DB, but the exception class, in the pattern mentioned in the JAX-WS
spec, wrappers a FaultBean accessible via getFaultInfo().
Since the various ExceptionHandler's already know how to unwrapper an
exception to find the DataType of the FaultBean within, I added an option to
the DefaultDataBindingExtensionPoint to check for an ExceptionHandler for each
of the DB's it goes through, and see if exceptionHandler.getFaultType(..) can
return something.
Even if this seems worthy, I know it might be best handled separately... but
this JIRA's a bit broad to begin with anyway.
DataBinding: Is it a concern of Programming Model vs. Assembly?
---
Key: TUSCANY-824
URL: https://issues.apache.org/jira/browse/TUSCANY-824
Project: Tuscany
Issue Type: Bug
Components: Java SCA Core Runtime
Affects Versions: Java-SCA-M2
Reporter: ant elder
Assignee: Raymond Feng
Priority: Critical
Fix For: Java-SCA-Next
Attachments: skurz.824.v1.patch
There have been some question about the DataBinding framework and if it
should be a concern of the Programming Model vs. Assembly?
See: http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg08679.html
and a follow up mention in:
http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg09363.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1342) Component-level interface.wsdl not supported
Component-level interface.wsdl not supported -- Key: TUSCANY-1342 URL: https://issues.apache.org/jira/browse/TUSCANY-1342 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-0.90 Reporter: Scott Kurz See thread: http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg18780.html Something like this does not work: component name=Component_... implementation.java class=.../ reference name=helloWorldService interface.wsdl interface=.../ binding.ws wsdlElement=.../ /reference /component -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1327) Generate static SDO APIs from wsdl files with type definition from wsdl:import and wsdl:include
[ https://issues.apache.org/jira/browse/TUSCANY-1327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12502022 ] Scott Kurz commented on TUSCANY-1327: - What authority (if any) does the Basic Profile 1.1 have here? BP 1.1 disallows this: http://www.ws-i.org/Profiles/BasicProfile-1.1-2004-08-24.html#WSDL_and_Schema_Import Generate static SDO APIs from wsdl files with type definition from wsdl:import and wsdl:include --- Key: TUSCANY-1327 URL: https://issues.apache.org/jira/browse/TUSCANY-1327 Project: Tuscany Issue Type: New Feature Components: Java SDO Tools Affects Versions: Java-SDO-M2 Environment: WinXP Reporter: Fuhwei Lwo Today, SDO codegen tool can recognize and parse wsdl:types content to generate static SDO APIs. However, it ignores wsdl:import and wsdl:include. This means if I have types defined in other wsdl files and they are imported or included by wsdl:import or wsdl:include elements, they won't never get generated. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-824) DataBinding: Is it a concern of Programming Model vs. Assembly?
[ https://issues.apache.org/jira/browse/TUSCANY-824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12501735 ] Scott Kurz commented on TUSCANY-824: This is a link to the ML discussion Raymond mentioned: http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg18236.html DataBinding: Is it a concern of Programming Model vs. Assembly? --- Key: TUSCANY-824 URL: https://issues.apache.org/jira/browse/TUSCANY-824 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-M2 Reporter: ant elder Assignee: Raymond Feng Priority: Critical Fix For: Java-SCA-Next There have been some question about the DataBinding framework and if it should be a concern of the Programming Model vs. Assembly? See: http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg08679.html and a follow up mention in: http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg09363.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-394) NPE when running wsdl2java tool with xsd:anyType in the schema
[ https://issues.apache.org/jira/browse/TUSCANY-394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12487580 ] Scott Kurz commented on TUSCANY-394: To me it looks like this is no longer a problem. I'm not sure in what sense this might be still a problem. I used any anyType as an input parm w/ the doc-lit-wrapped style and it the W2J gen'd a DataObject input parmand there was no problem at runtime over the Axis2 binding. NPE when running wsdl2java tool with xsd:anyType in the schema Key: TUSCANY-394 URL: https://issues.apache.org/jira/browse/TUSCANY-394 Project: Tuscany Issue Type: Bug Components: Java SCA Tools Reporter: Fuhwei Lwo Fix For: Java-SCA-Next Attachments: patch.txt In the wsdl:typesxsd:schema section, if there is an element with xsd:anyType defined, running wsdl2java to generate the service interface would get a null pointer exception as below. Note: The SDO codegen tool is running fine with anyType. java.lang.NullPointerException at org.apache.tuscany.tools.wsdl2java.generate.WSDL2JavaGenerator.genera teFromWSDL(WSDL2JavaGenerator.java:194) at org.apache.tuscany.tools.wsdl2java.plugin.WSDL2JavaGeneratorMojo.exec ute(WSDL2JavaGeneratorMojo.java:82) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi nManager.java:432) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa ultLifecycleExecutor.java:530) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLi fecycle(DefaultLifecycleExecutor.java:472) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau ltLifecycleExecutor.java:451) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan dleFailures(DefaultLifecycleExecutor.java:303) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen ts(DefaultLifecycleExecutor.java:270) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi fecycleExecutor.java:139) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:249) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1206) DataBinding support for transform of Fault DataTypes should account for wrappered FaultBean in JAX-WS style
DataBinding support for transform of Fault DataTypes should account for
wrappered FaultBean in JAX-WS style
---
Key: TUSCANY-1206
URL: https://issues.apache.org/jira/browse/TUSCANY-1206
Project: Tuscany
Issue Type: Improvement
Components: Java SCA Kernel
Affects Versions: Java-SCA-Next
Reporter: Scott Kurz
I wonder if the DataBindingJavaInterfaceProcessor should be introspecting the
FaultBean rather than the exception type itself in order to
calculate the databinding.
In the code we do:
for ( org.apache.tuscany.spi.model.DataType? d :
operation.getFaultTypes()) {
dataBindingRegistry.introspectType(d, annotations);
}
Following JAX-WS, say my fault type is a POJO Java class extending Exception
with a getFaultInfo() returning an SDO type (this SDO is the FaultBean).
If SDODataBinding.introspect() was called to introspect my FaultBean type,
then, you would be able to calculate I wanted SDO databinding (since I load the
fault type with import.sdo).
But since only my POJO wrapper exc is introspected I end up getting a null DB.
Maybe another solution would be to push the responsibility to check for a
FaultBean returned by getFaultInfo() onto an individual DataBindingExtension
class, e.g. SDODataBinding.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1165) Integration branch - Timing issue: incorrect dependency on order of Component loader and ImportSDOLoader within Composite loading
Integration branch - Timing issue: incorrect dependency on order of Component loader and ImportSDOLoader within Composite loading - Key: TUSCANY-1165 URL: https://issues.apache.org/jira/browse/TUSCANY-1165 Project: Tuscany Issue Type: Bug Components: Java SCA Kernel Affects Versions: Java-SCA-integration Reporter: Scott Kurz As referenced in this email: http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg15250.html The Java component loader's introspection of the DataTypes in a Java component impl using SDO data types does not successfully detect the SDO DataTypes. This is because the the SDODataBinding.introspect() method (called by DataBindingRegistryImpl.introspectType()) requires the ImportSDOLoader to have already run by that point. Something needs to be done but I'm not knowledgable enough now to suggest how to fix this. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-695) JavaComponentTypeLoader.load() returns PojoComponentType which isn't a ModelObject
[
https://issues.apache.org/jira/browse/TUSCANY-695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12477872
]
Scott Kurz commented on TUSCANY-695:
Since I opened this.. I just checked and can see that the specific issue
mentioned in the JIRA title has been addressed and a ModelObject is returned
now by JavaComponentTypeLoader.load(). I'm not sure if this was done by
following up on Jim's suggestion.
JavaComponentTypeLoader.load() returns PojoComponentType which isn't a
ModelObject
--
Key: TUSCANY-695
URL: https://issues.apache.org/jira/browse/TUSCANY-695
Project: Tuscany
Issue Type: Bug
Components: Java SCA Kernel
Affects Versions: Java-SCA-2.0-Alpha
Environment: r440401
Reporter: Scott Kurz
Assigned To: Jeremy Boynes
Fix For: Java-SCA-2.0-Alpha
When I tried using a componentType file along w/ my Java impl I got:
org.apache.tuscany.spi.loader.UnrecognizedElementException :
{http://www.osoa.org/xmlns/sca/1.0}componentType
[{http://www.osoa.org/xmlns/sca/1.0}componentType ]
at
org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistryImpl.java:113)
at
org.apache.tuscany.core.implementation.java.JavaComponentTypeLoader.loadFromSidefile(JavaComponentTypeLoader.java
)
at
org.apache.tuscany.core.implementation.java.JavaComponentTypeLoader.load(JavaComponentTypeLoader.java:71)
at
org.apache.tuscany.core.implementation.java.JavaComponentTypeLoader.load(JavaComponentTypeLoader.java
:47)
at
org.apache.tuscany.core.loader.LoaderRegistryImpl.loadComponentType(LoaderRegistryImpl.java:159)
at
org.apache.tuscany.core.implementation.java.JavaImplementationLoader.load(JavaImplementationLoader.java
:57)
at
org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistryImpl.java:92)
at
org.apache.tuscany.core.loader.ComponentLoader.loadImplementation(ComponentLoader.java:133)
at org.apache.tuscany.core.loader.ComponentLoader.load
(ComponentLoader.java:84)
at
org.apache.tuscany.core.loader.ComponentLoader.load(ComponentLoader.java:57)
at
org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistryImpl.java:92)
at org.apache.tuscany.core.implementation.composite.CompositeLoader.load
(CompositeLoader.java:77)
at
org.apache.tuscany.core.implementation.composite.CompositeLoader.load(CompositeLoader.java:52)
at
org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistryImpl.java:92)
at
org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistryImpl.java:109)
at
org.apache.tuscany.core.implementation.composite.CompositeComponentTypeLoader.loadFromSidefile(CompositeComponentTypeLoader.java
:64)
at
org.apache.tuscany.core.implementation.composite.CompositeComponentTypeLoader.load(CompositeComponentTypeLoader.java:56)
at
org.apache.tuscany.core.implementation.composite.CompositeComponentTypeLoader.load
(CompositeComponentTypeLoader.java:38)
at
org.apache.tuscany.core.loader.LoaderRegistryImpl.loadComponentType(LoaderRegistryImpl.java:159)
at org.apache.tuscany.core.deployer.DeployerImpl.load(DeployerImpl.java
:118)
at
org.apache.tuscany.core.deployer.DeployerImpl.deploy(DeployerImpl.java:93)
at
org.apache.tuscany.core.launcher.LauncherImpl.bootApplication(LauncherImpl.java:193)
The problem wasn't the lack of a loader to load componentType
elems.rather, it was this line in JavaComponentTypeLoader:
protected PojoComponentType loadFromSidefile(URL url, DeploymentContext
deploymentContext) throws LoaderException {
return loaderRegistry.load(null, url, PojoComponentType.class,
deploymentContext);
}
Thie use of 'PojoComponentType.class' as argument is a problem. In
LoaderRegistryImpl.load, we do (line 109):
ModelObject mo = load(parent, reader, ctx);
if (type.isInstance(mo)) {
So we're loading into a ModelObject, (more specifically,
org.apache.tuscany.spi.model.ComponentType), but the 'type' here is :
PojoComponentType.class
which is in pkg org.apache.tuscany.core.implementation.java and passed into
the load(..) call.
On the dev list, Raymond Feng answered my email describing the problem with
this:
The ComponentTypeElementLoader creates a generic ComponentType from
the XML file but the code expects an instance of PojoComponentType. Now the
question is how to map the generic ComponentType into the PojoComponentType
if it's required. Jim, do you have ideas?
Jim Marino replied:
We should probably have the implementation loader handle creation of
the particular component type class and populate it by recursing back
into the loader since it is
[jira] Created: (TUSCANY-1146) ServiceContract clone() doesn't clone Operations()
ServiceContract clone() doesn't clone Operations()
--
Key: TUSCANY-1146
URL: https://issues.apache.org/jira/browse/TUSCANY-1146
Project: Tuscany
Issue Type: Bug
Components: Java SCA Core
Affects Versions: Java-M2
Reporter: Scott Kurz
Fix For: Java-SCA-integration
ServiceContract.clone() does:
if (operations != null) {
MapString, OperationT clonedOperations = new HashMapString,
OperationT();
for (OperationT o : operations.values()) {
clonedOperations.put(o.getName(), o);
}
copy.setOperations(clonedOperations);
}
This is going to interfere with the 'operations' of the original
ServiceContract (since setOperations points the Operations to the new SC). We
should have cloned the operations I believe.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1146) ServiceContract clone() doesn't clone operation
[
https://issues.apache.org/jira/browse/TUSCANY-1146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Scott Kurz updated TUSCANY-1146:
Summary: ServiceContract clone() doesn't clone operation (was:
ServiceContract clone() doesn't clone Operations())
ServiceContract clone() doesn't clone operation
---
Key: TUSCANY-1146
URL: https://issues.apache.org/jira/browse/TUSCANY-1146
Project: Tuscany
Issue Type: Bug
Components: Java SCA Core
Affects Versions: Java-M2
Reporter: Scott Kurz
Fix For: Java-SCA-integration
ServiceContract.clone() does:
if (operations != null) {
MapString, OperationT clonedOperations = new HashMapString,
OperationT();
for (OperationT o : operations.values()) {
clonedOperations.put(o.getName(), o);
}
copy.setOperations(clonedOperations);
}
This is going to interfere with the 'operations' of the original
ServiceContract (since setOperations points the Operations to the new SC).
We should have cloned the operations I believe.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1146) ServiceContract clone() doesn't clone operations
[
https://issues.apache.org/jira/browse/TUSCANY-1146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Scott Kurz updated TUSCANY-1146:
Summary: ServiceContract clone() doesn't clone operations (was:
ServiceContract clone() doesn't clone operation)
ServiceContract clone() doesn't clone operations
Key: TUSCANY-1146
URL: https://issues.apache.org/jira/browse/TUSCANY-1146
Project: Tuscany
Issue Type: Bug
Components: Java SCA Core
Affects Versions: Java-M2
Reporter: Scott Kurz
Fix For: Java-SCA-integration
ServiceContract.clone() does:
if (operations != null) {
MapString, OperationT clonedOperations = new HashMapString,
OperationT();
for (OperationT o : operations.values()) {
clonedOperations.put(o.getName(), o);
}
copy.setOperations(clonedOperations);
}
This is going to interfere with the 'operations' of the original
ServiceContract (since setOperations points the Operations to the new SC).
We should have cloned the operations I believe.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1146) ServiceContract clone() doesn't clone operations
[
https://issues.apache.org/jira/browse/TUSCANY-1146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Scott Kurz updated TUSCANY-1146:
Attachment: 1146.patch
This is a patch on the integration-branch. (Should I have attached one to the
trunk as well? )
ServiceContract clone() doesn't clone operations
Key: TUSCANY-1146
URL: https://issues.apache.org/jira/browse/TUSCANY-1146
Project: Tuscany
Issue Type: Bug
Components: Java SCA Core
Affects Versions: Java-M2
Reporter: Scott Kurz
Fix For: Java-SCA-integration
Attachments: 1146.patch
ServiceContract.clone() does:
if (operations != null) {
MapString, OperationT clonedOperations = new HashMapString,
OperationT();
for (OperationT o : operations.values()) {
clonedOperations.put(o.getName(), o);
}
copy.setOperations(clonedOperations);
}
This is going to interfere with the 'operations' of the original
ServiceContract (since setOperations points the Operations to the new SC).
We should have cloned the operations I believe.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1146) ServiceContract clone() doesn't clone operations
[
https://issues.apache.org/jira/browse/TUSCANY-1146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Scott Kurz updated TUSCANY-1146:
Attachment: 1146.patch
Same patch with ASF license..sorry
ServiceContract clone() doesn't clone operations
Key: TUSCANY-1146
URL: https://issues.apache.org/jira/browse/TUSCANY-1146
Project: Tuscany
Issue Type: Bug
Components: Java SCA Core
Affects Versions: Java-M2
Reporter: Scott Kurz
Fix For: Java-SCA-integration
Attachments: 1146.patch, 1146.patch
ServiceContract.clone() does:
if (operations != null) {
MapString, OperationT clonedOperations = new HashMapString,
OperationT();
for (OperationT o : operations.values()) {
clonedOperations.put(o.getName(), o);
}
copy.setOperations(clonedOperations);
}
This is going to interfere with the 'operations' of the original
ServiceContract (since setOperations points the Operations to the new SC).
We should have cloned the operations I believe.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1142) Need to allow generation of wrapped Java intf from doc-lit-wrap WSDL with named complexType
Need to allow generation of wrapped Java intf from doc-lit-wrap WSDL with named
complexType
Key: TUSCANY-1142
URL: https://issues.apache.org/jira/browse/TUSCANY-1142
Project: Tuscany
Issue Type: Bug
Components: Java SCA Tools
Affects Versions: Java-M2
Reporter: Scott Kurz
Fix For: Java-SCA-M3, Java-SCA-integration
Our WSDL2Java tool maps the following WSDL pattern onto a non-wrapped Java
interface even when using doc-lit-wrapped WSDL:
...types
complexType name=getGreetings
sequence
element name=name type=xsd:string/
/sequence
/complexType
element name=getGreetings type=tns:getGreetings/
...
/types
I noticed that wsimport seems to unwrap this and produce:
getGreetings(String)
whereas our WSDL2Java treats this as non-wrapped and generates:
getGreetings(getGreetings)
The key line of Tuscany code is:
org.apache.tuscany.tools.wsdl2java.generate.JavaInterfaceEmitter.isWrapped()
if (typeMappingEntry.isAnonymous()) {
wrapped = true;
}
As I claim in this JIRA, TUSCANY-1019, it would be nice to ALSO have the
ability to generate a non-wrapped Java interface from the given WSDL pattern,
but we should also allow for generation of a wrapped interface (the wrapped by
my guess should be the default).
Yang Zhong posted this reply in agreement to the Tuscany dev list.
Once binding is involved within WSDL2Java, one WSDL portType/message can end
up with multiple Java classes respective to different bindings.
It mixes business logic and wire format :-(
Assuming involving binding is de facto, and only one binding each WSDL
portType/message,
maybe we can change JavaInterfaceEmitter.isWrapped to an algorithm such as:
1. not wrapped if the style is not document or the use is not literal
2. not wrapped if the message has more than one parts
3. not wrapped if the part isn't element or its local name doesn't match the
operation local name
4. not wrapped if the operation name isn't unique within the portType
Yes, I agree with Scott not to take isAnonymous() into account.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-983) Schema Definitions need to be unregistered from Registry
[ https://issues.apache.org/jira/browse/TUSCANY-983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12475330 ] Scott Kurz commented on TUSCANY-983: When Kapish and I noticed the overall lack of undeploy and the problematic caching of WSDL defs in WSDLDefinitionRegistryImpl we assumed the schema registry had similar issues. It would be good to consider the schema registry in the work you're talking about but after looking closely I couldn't point you to a specific, currently-existing problem with org.apache.tuscany.idl.wsdl.XMLSchemaRegistryImpl. Schema Definitions need to be unregistered from Registry Key: TUSCANY-983 URL: https://issues.apache.org/jira/browse/TUSCANY-983 Project: Tuscany Issue Type: Sub-task Affects Versions: Java-SCA-M3, Java-SCA-integration Reporter: Kapish Aggarwal Assigned To: Jean-Sebastien Delfino Fix For: Java-SCA-M3, Java-SCA-integration -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-544) WSDL2Java should support WSDLs with schema imports
[ https://issues.apache.org/jira/browse/TUSCANY-544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12475520 ] Scott Kurz commented on TUSCANY-544: I think it would help to add some specific detail on what you want WSDL2JavaGenerator to support that it doesn't currently .. or to cancel this JIRA. I have been looking at the tools and am planning on opening one or two new JIRAs myself.I wouldn't say that WSDL2JavaGenerator flat-out doesn't support importing schemas; there are issues but certain things work the way I expect them to. I have had success running WSDL2Java against WSDLs with this type of pattern: wsdl:definitions .. wsdl:types... xsd:schema .. xsd:import ... schemaLocation=MySchema.xsd/ WSDL2Java should support WSDLs with schema imports -- Key: TUSCANY-544 URL: https://issues.apache.org/jira/browse/TUSCANY-544 Project: Tuscany Issue Type: Bug Components: Java SCA Tools Affects Versions: Java-M2 Reporter: Ron Gavlin Fix For: Java-SCA-M3 Many WSDLs choose to import schemas rather than embedding types inline. The tuscany WSDL2JavaGenerator does not currently support this type of usage. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1137) WSDL2Java tool should be able to handle imports of other WSDL files into the original WSDL
[ https://issues.apache.org/jira/browse/TUSCANY-1137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Kurz updated TUSCANY-1137: Attachment: PortType.wsdl WSDL2Java tool should be able to handle imports of other WSDL files into the original WSDL -- Key: TUSCANY-1137 URL: https://issues.apache.org/jira/browse/TUSCANY-1137 Project: Tuscany Issue Type: Bug Components: Java SCA Tools Affects Versions: Java-M2 Reporter: Scott Kurz Priority: Minor Fix For: Java-SCA-M3 Attachments: PortType.wsdl If I, for example, define my portType in one WSDL and then import that into another WSDL where I define my Service/Port, I will have problems, like the following when running WSDL2Java against the latter WSDL: Caused by: java.lang.NullPointerException at org.apache.tuscany.tools.wsdl2java.generate.JavaInterfaceEmitter.isWrapped(JavaInterfaceEmitter.java:136) at org.apache.tuscany.tools.wsdl2java.generate.JavaInterfaceEmitter.getInputElement(JavaInterfaceEmitter.java:171) at org.apache.axis2.wsdl.codegen.emitter.AxisServiceBasedMultiLanguageEmitter.generateMethodElement(AxisServiceBasedMultiLanguageEmitter.java:1926) at org.apache.axis2.wsdl.codegen.emitter.AxisServiceBasedMultiLanguageEmitter.loadOperations(AxisServiceBasedMultiLanguageEmitter.java:1841) at org.apache.axis2.wsdl.codegen.emitter.AxisServiceBasedMultiLanguageEmitter.createDOMDocumentForInterface(AxisServiceBasedMultiLanguageEmitter.java:993) at org.apache.tuscany.tools.wsdl2java.generate.JavaInterfaceEmitter.writeInterface(JavaInterfaceEmitter.java:196) at org.apache.tuscany.tools.wsdl2java.generate.JavaInterfaceGenerator.generate(JavaInterfaceGenerator.java:200) I believe a key to the problem is the line in WSDL2JavaGenerator.generateFromWSDL(): xsdHelper.define(inputStream, inputFile.toURI().toString()); Though this method is called the EMF 'packageRegistry' field is essentially empty. I assume this is because XSDHelper.define(...) will not handle a WSDL import.(It does seem to be handling an XSD schema import, however). I don't know enough of the SDO APIs to suggest a better method than the xsdHelper.define(..) we're invoking, however. I'll attach an example -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1137) WSDL2Java tool should be able to handle imports of other WSDL files into the original WSDL
WSDL2Java tool should be able to handle imports of other WSDL files into the original WSDL -- Key: TUSCANY-1137 URL: https://issues.apache.org/jira/browse/TUSCANY-1137 Project: Tuscany Issue Type: Bug Components: Java SCA Tools Affects Versions: Java-M2 Reporter: Scott Kurz Priority: Minor Fix For: Java-SCA-M3 Attachments: PortType.wsdl If I, for example, define my portType in one WSDL and then import that into another WSDL where I define my Service/Port, I will have problems, like the following when running WSDL2Java against the latter WSDL: Caused by: java.lang.NullPointerException at org.apache.tuscany.tools.wsdl2java.generate.JavaInterfaceEmitter.isWrapped(JavaInterfaceEmitter.java:136) at org.apache.tuscany.tools.wsdl2java.generate.JavaInterfaceEmitter.getInputElement(JavaInterfaceEmitter.java:171) at org.apache.axis2.wsdl.codegen.emitter.AxisServiceBasedMultiLanguageEmitter.generateMethodElement(AxisServiceBasedMultiLanguageEmitter.java:1926) at org.apache.axis2.wsdl.codegen.emitter.AxisServiceBasedMultiLanguageEmitter.loadOperations(AxisServiceBasedMultiLanguageEmitter.java:1841) at org.apache.axis2.wsdl.codegen.emitter.AxisServiceBasedMultiLanguageEmitter.createDOMDocumentForInterface(AxisServiceBasedMultiLanguageEmitter.java:993) at org.apache.tuscany.tools.wsdl2java.generate.JavaInterfaceEmitter.writeInterface(JavaInterfaceEmitter.java:196) at org.apache.tuscany.tools.wsdl2java.generate.JavaInterfaceGenerator.generate(JavaInterfaceGenerator.java:200) I believe a key to the problem is the line in WSDL2JavaGenerator.generateFromWSDL(): xsdHelper.define(inputStream, inputFile.toURI().toString()); Though this method is called the EMF 'packageRegistry' field is essentially empty. I assume this is because XSDHelper.define(...) will not handle a WSDL import.(It does seem to be handling an XSD schema import, however).I don't know enough of the SDO APIs to suggest a better method than the xsdHelper.define(..) we're invoking, however. I'll attach an example -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1137) WSDL2Java tool should be able to handle imports of other WSDL files into the original WSDL
[ https://issues.apache.org/jira/browse/TUSCANY-1137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Kurz updated TUSCANY-1137: Attachment: Service.wsdl WSDL2Java tool should be able to handle imports of other WSDL files into the original WSDL -- Key: TUSCANY-1137 URL: https://issues.apache.org/jira/browse/TUSCANY-1137 Project: Tuscany Issue Type: Bug Components: Java SCA Tools Affects Versions: Java-M2 Reporter: Scott Kurz Priority: Minor Fix For: Java-SCA-M3 Attachments: PortType.wsdl, Service.wsdl If I, for example, define my portType in one WSDL and then import that into another WSDL where I define my Service/Port, I will have problems, like the following when running WSDL2Java against the latter WSDL: Caused by: java.lang.NullPointerException at org.apache.tuscany.tools.wsdl2java.generate.JavaInterfaceEmitter.isWrapped(JavaInterfaceEmitter.java:136) at org.apache.tuscany.tools.wsdl2java.generate.JavaInterfaceEmitter.getInputElement(JavaInterfaceEmitter.java:171) at org.apache.axis2.wsdl.codegen.emitter.AxisServiceBasedMultiLanguageEmitter.generateMethodElement(AxisServiceBasedMultiLanguageEmitter.java:1926) at org.apache.axis2.wsdl.codegen.emitter.AxisServiceBasedMultiLanguageEmitter.loadOperations(AxisServiceBasedMultiLanguageEmitter.java:1841) at org.apache.axis2.wsdl.codegen.emitter.AxisServiceBasedMultiLanguageEmitter.createDOMDocumentForInterface(AxisServiceBasedMultiLanguageEmitter.java:993) at org.apache.tuscany.tools.wsdl2java.generate.JavaInterfaceEmitter.writeInterface(JavaInterfaceEmitter.java:196) at org.apache.tuscany.tools.wsdl2java.generate.JavaInterfaceGenerator.generate(JavaInterfaceGenerator.java:200) I believe a key to the problem is the line in WSDL2JavaGenerator.generateFromWSDL(): xsdHelper.define(inputStream, inputFile.toURI().toString()); Though this method is called the EMF 'packageRegistry' field is essentially empty. I assume this is because XSDHelper.define(...) will not handle a WSDL import.(It does seem to be handling an XSD schema import, however). I don't know enough of the SDO APIs to suggest a better method than the xsdHelper.define(..) we're invoking, however. I'll attach an example -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1137) WSDL2Java tool should be able to handle imports of other WSDL files into the original WSDL
[ https://issues.apache.org/jira/browse/TUSCANY-1137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12475537 ] Scott Kurz commented on TUSCANY-1137: - So in the above example if Service.wsdl imports PortType.wsdl, we hit the problem I mentioned when I run Tuscany WSDL2Java against Service.wsdl.BTW, when running a version of wsimport against the same I have no problem. WSDL2Java tool should be able to handle imports of other WSDL files into the original WSDL -- Key: TUSCANY-1137 URL: https://issues.apache.org/jira/browse/TUSCANY-1137 Project: Tuscany Issue Type: Bug Components: Java SCA Tools Affects Versions: Java-M2 Reporter: Scott Kurz Priority: Minor Fix For: Java-SCA-M3 Attachments: PortType.wsdl, Service.wsdl If I, for example, define my portType in one WSDL and then import that into another WSDL where I define my Service/Port, I will have problems, like the following when running WSDL2Java against the latter WSDL: Caused by: java.lang.NullPointerException at org.apache.tuscany.tools.wsdl2java.generate.JavaInterfaceEmitter.isWrapped(JavaInterfaceEmitter.java:136) at org.apache.tuscany.tools.wsdl2java.generate.JavaInterfaceEmitter.getInputElement(JavaInterfaceEmitter.java:171) at org.apache.axis2.wsdl.codegen.emitter.AxisServiceBasedMultiLanguageEmitter.generateMethodElement(AxisServiceBasedMultiLanguageEmitter.java:1926) at org.apache.axis2.wsdl.codegen.emitter.AxisServiceBasedMultiLanguageEmitter.loadOperations(AxisServiceBasedMultiLanguageEmitter.java:1841) at org.apache.axis2.wsdl.codegen.emitter.AxisServiceBasedMultiLanguageEmitter.createDOMDocumentForInterface(AxisServiceBasedMultiLanguageEmitter.java:993) at org.apache.tuscany.tools.wsdl2java.generate.JavaInterfaceEmitter.writeInterface(JavaInterfaceEmitter.java:196) at org.apache.tuscany.tools.wsdl2java.generate.JavaInterfaceGenerator.generate(JavaInterfaceGenerator.java:200) I believe a key to the problem is the line in WSDL2JavaGenerator.generateFromWSDL(): xsdHelper.define(inputStream, inputFile.toURI().toString()); Though this method is called the EMF 'packageRegistry' field is essentially empty. I assume this is because XSDHelper.define(...) will not handle a WSDL import.(It does seem to be handling an XSD schema import, however). I don't know enough of the SDO APIs to suggest a better method than the xsdHelper.define(..) we're invoking, however. I'll attach an example -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1063) Improve diagnostics running XSD2JavaGenerator against bad schema
Improve diagnostics running XSD2JavaGenerator against bad schema Key: TUSCANY-1063 URL: https://issues.apache.org/jira/browse/TUSCANY-1063 Project: Tuscany Issue Type: Improvement Components: Java SDO Tools Affects Versions: Java-SCA-M3 Reporter: Scott Kurz Priority: Minor Fix For: Java-SCA-M3 I gave an invalid XSD file to the XSD2JavaGenerator and had to use the debugger to figure out the problem. It might be nice to do a printStackTrace() on any exception before throwing out of main(). Also it might be good to print out simple error messages in the cases that: a) the usage was correct but the specified file can't be read b) the file can be read but there is no valid schema found As a sample of the latter here is my invalid schema xsd:schema xmlns:tns=http://helloworld; xmlns:xsd=http://www.w3.org/2001/XMLSchema; elementFormDefault=qualified targetNamespace=http://helloworld; complexType name=Person sequence element name=firstName type=string/ element name=lastName type=string/ /sequence /complexType /xsd:schema -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1019) WSDL2Java should offer option to generate Java signature with non-wrapper style mapping from doc-lit-wrapped WSDL
[ https://issues.apache.org/jira/browse/TUSCANY-1019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12463905 ] Scott Kurz commented on TUSCANY-1019: - Thanks for investigating. I'd assume you'd be able to use any compatible Java mapping. For example if your service intf is described by an interface.wsdl, the service impl could be written to a mapped-style Java intf using static SDO. One Java client of this service might be written to a non-mapped Java intf using a single dynamic SDO for input,output. Another client might use JAXB. But the assembly and Java CI specs leave this up for interpretation, I'd agree. I think there are even more issues needing clarification if the service intf. is described as an interface.java w/ static SDO or JAXB types in the interface signatures... but that's starting to expand the discussion past the scope of this JIRA. Also, I believe there would be runtime changes needed in addition to tooling changes to allow the doc-lit-wrapped WSDL combined with non-wrapper-style Java mapping to flow through the databinding code. WSDL2Java should offer option to generate Java signature with non-wrapper style mapping from doc-lit-wrapped WSDL - Key: TUSCANY-1019 URL: https://issues.apache.org/jira/browse/TUSCANY-1019 Project: Tuscany Issue Type: Improvement Components: Java SCA Tools, Specification Affects Versions: Java-Mx Reporter: Scott Kurz Assigned To: Jean-Sebastien Delfino It is currently possible to use the WSDL2Java tooling to do each of: * start w/ doc-lit-wrapped WSDL and generate a wrapper-style Java mapping * start w/ doc-lit-nonwrapped WSDL and generate a non-wrapper-style Java mapping However it is not possible to start w/ doc-lit-wrapped WSDL and generate a non-wrapper-style Java mapping. You might want to do this in order to work with the input as a single SDO rather than having the individual child elements appear on the Java signature. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1034) Need to add support for business exceptions - at least in simple intra-Composite case to begin with
Need to add support for business exceptions - at least in simple
intra-Composite case to begin with
---
Key: TUSCANY-1034
URL: https://issues.apache.org/jira/browse/TUSCANY-1034
Project: Tuscany
Issue Type: Bug
Components: Java SCA Core
Affects Versions: Java-M2
Environment: M2- level code
Reporter: Scott Kurz
Not sure how to track this one. It's possible adding support for business
exceptions is an effort which spans a bunch of different parts.
To start with, as the comment acknowledges the DataBindingInteceptor (sic)
needs to do something other than the current:
// FIXME: How to deal with faults?
if (resultMsg.isFault()) {
// We need to figure out what fault type it is and then transform
it back the source fault type
throw new InvocationRuntimeException((Throwable) result);
}
If no transform was needed this code would have been fine simply doing:
return resultMsg;
If this would not be worked on more completely it might be worth enabling this
simple case for the time being.
Later, probably in another JIRA, code such as the Axis2 binding might need to
be tweaked to handle business exceptions/faults. (For example we might unwrap
an AxisFault). Depends on how this is
handled.
In the meantime I wanted to get this down as a TODO.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1019) WSDL2Java should offer option to generate Java signature with non-wrapper style mapping from doc-lit-wrapped WSDL
WSDL2Java should offer option to generate Java signature with non-wrapper style mapping from doc-lit-wrapped WSDL - Key: TUSCANY-1019 URL: http://issues.apache.org/jira/browse/TUSCANY-1019 Project: Tuscany Issue Type: Improvement Components: Java SCA Tools Affects Versions: Java-Mx Reporter: Scott Kurz It is currently possible to use the WSDL2Java tooling to do each of: * start w/ doc-lit-wrapped WSDL and generate a wrapper-style Java mapping * start w/ doc-lit-nonwrapped WSDL and generate a non-wrapper-style Java mapping However it is not possible to start w/ doc-lit-wrapped WSDL and generate a non-wrapper-style Java mapping. You might want to do this in order to work with the input as a single SDO rather than having the individual child elements appear on the Java signature. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-941) Zero Parm operation w/ SDO @DataType annotation fails over binding.axis2 WS binding
[ http://issues.apache.org/jira/browse/TUSCANY-941?page=all ] Scott Kurz updated TUSCANY-941: --- Attachment: helloworld.wsdl I believe this is the correct way to do this..to keep the input message on the operation and to wrap an empty element: element name=getGreetings complexType sequence/ /complexType /element Though when I get a chance I'll check the JAX-WS spec to be sure ... (and I think JAX-WS is an appropriate authority though I'm not 100% sure I'm right to assume that). Zero Parm operation w/ SDO @DataType annotation fails over binding.axis2 WS binding -- Key: TUSCANY-941 URL: http://issues.apache.org/jira/browse/TUSCANY-941 Project: Tuscany Issue Type: Bug Components: Java SCA Axis Binding Affects Versions: Java-M2 Environment: M2 level code Reporter: Scott Kurz Assigned To: Raymond Feng Priority: Minor Attachments: helloworld.wsdl Seems to need some special-case handling when the service operation is defined with no parms. java.lang.IndexOutOfBoundsException: Index: 0, Size: 0 at java.util.ArrayList.RangeCheck(ArrayList.java:572) at java.util.ArrayList.get(ArrayList.java:347) at org.apache.tuscany.core.databinding.impl.Input2InputTransformer.transform(Input2InputTransformer.java:197) at org.apache.tuscany.core.databinding.impl.Input2InputTransformer.transform(Input2InputTransformer.java:47) at org.apache.tuscany.core.databinding.impl.MediatorImpl.mediate(MediatorImpl.java:95) at org.apache.tuscany.core.databinding.impl.DataBindingInteceptor.transform(DataBindingInteceptor.java:105) at org.apache.tuscany.core.databinding.impl.DataBindingInteceptor.invoke(DataBindingInteceptor.java:69) at org.apache.tuscany.core.wire.SynchronousBridgingInterceptor.invoke(SynchronousBridgingInterceptor.java:41) at org.apache.tuscany.binding.axis2.Axis2Service.invokeTarget(Axis2Service.java:226) at org.apache.tuscany.binding.axis2.Axis2ServiceInOutSyncMessageReceiver.invokeBusinessLogic(Axis2ServiceInOutSyncMessageReceiver.java:53) at org.apache.axis2.receivers.AbstractInOutSyncMessageReceiver.receive(AbstractInOutSyncMessageReceiver.java:39) I don't want to paste my whole app just to show this piece... and it's so simple that one would know what a WSDL snippet would look like so I won't attach anything. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-686) InterfaceWSDLLoader creates WSDLServiceContract objs which return null on getInterfaceClass()
[ http://issues.apache.org/jira/browse/TUSCANY-686?page=comments#action_12452031 ] Scott Kurz commented on TUSCANY-686: I THINK THIS JIRA CAN BE CLOSED I believe the current reworking of the bindings' use of the ServiceContract and the Java interfaces obtained from it have solved all the issues mentioned, (even though I don't understand how in great detail). InterfaceWSDLLoader creates WSDLServiceContract objs which return null on getInterfaceClass() - Key: TUSCANY-686 URL: http://issues.apache.org/jira/browse/TUSCANY-686 Project: Tuscany Issue Type: Bug Components: Java SCA Core Affects Versions: Java-M2 Environment: r438923 Reporter: Scott Kurz Fix For: Java-M2 SYMPTOM (when using interface.wsdl elem along with binding.ws and Axis 2 binding: java.lang.NullPointerException at org.apache.tuscany.core.builder.ConnectorImpl.connect(ConnectorImpl.java:314) at org.apache.tuscany.core.builder.ConnectorImpl.connect(ConnectorImpl.java:110) at org.apache.tuscany.core.builder.ConnectorImpl.connect(ConnectorImpl.java:91) at org.apache.tuscany.core.deployer.DeployerImpl.connect(DeployerImpl.java:141) at org.apache.tuscany.core.deployer.DeployerImpl.deploy(DeployerImpl.java:103) at org.apache.tuscany.core.launcher.LauncherImpl.bootApplication(LauncherImpl.java:193) PROBLEM: Axis2BindingBuilder.build does (line 60): Class? interfaze = serviceDefinition.getServiceContract().getInterfaceClass(); This simply returns null since the WSDLServiceContract built by InterfaceWSDLLoader contains a portType but no interface class.Thus the ConnectorImpl hits the NPE we see above. Some sort of WSDL2Java should probably? be done when InterfaceWSDLLoader sets the portType on the WSDLServiceContract it builds. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-947) JDKCallbackInvocationHandler should handle toString(), hashCode(), equals() specially
JDKCallbackInvocationHandler should handle toString(), hashCode(), equals() specially - Key: TUSCANY-947 URL: http://issues.apache.org/jira/browse/TUSCANY-947 Project: Tuscany Issue Type: Bug Components: Java SCA Core Affects Versions: Java-M2 Environment: M2 Reporter: Scott Kurz Since JDKCallbackInvocationHandler doesn't handle toString() specially, if the dynamic $Proxy toString() gets called before the invoke of a service operation it will mess up the correlationId, etc.. by nulling them out.. The other InvocationHandler classes in Tuscany do special-case these methods. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-947) JDKCallbackInvocationHandler should handle toString(), hashCode(), equals() specially
[ http://issues.apache.org/jira/browse/TUSCANY-947?page=all ] Scott Kurz updated TUSCANY-947: --- Attachment: 947.patch I can copy code from one place to the next ;) But if someone wants to do something better go ahead. JDKCallbackInvocationHandler should handle toString(), hashCode(), equals() specially - Key: TUSCANY-947 URL: http://issues.apache.org/jira/browse/TUSCANY-947 Project: Tuscany Issue Type: Bug Components: Java SCA Core Affects Versions: Java-M2 Environment: M2 Reporter: Scott Kurz Attachments: 947.patch Since JDKCallbackInvocationHandler doesn't handle toString() specially, if the dynamic $Proxy toString() gets called before the invoke of a service operation it will mess up the correlationId, etc.. by nulling them out.. The other InvocationHandler classes in Tuscany do special-case these methods. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-947) JDKCallbackInvocationHandler should handle toString(), hashCode(), equals() specially
[ http://issues.apache.org/jira/browse/TUSCANY-947?page=all ] Scott Kurz updated TUSCANY-947: --- Attachment: 947.patch Jim, I don't know enough about EasyMock or the class I'm changing to copy over the Inbound handler's tests, so I just copied to outbound handler's tests of toString() or hashCode(). Hope that works. Scott JDKCallbackInvocationHandler should handle toString(), hashCode(), equals() specially - Key: TUSCANY-947 URL: http://issues.apache.org/jira/browse/TUSCANY-947 Project: Tuscany Issue Type: Bug Components: Java SCA Core Affects Versions: Java-M2 Environment: M2 Reporter: Scott Kurz Attachments: 947.patch, 947.patch Since JDKCallbackInvocationHandler doesn't handle toString() specially, if the dynamic $Proxy toString() gets called before the invoke of a service operation it will mess up the correlationId, etc.. by nulling them out.. The other InvocationHandler classes in Tuscany do special-case these methods. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-942) Need to build proxy when using locateService on Composite reference w/ interface.wsdl
Need to build proxy when using locateService on Composite reference w/ interface.wsdl --- Key: TUSCANY-942 URL: http://issues.apache.org/jira/browse/TUSCANY-942 Project: Tuscany Issue Type: Bug Components: Java SCA Core Affects Versions: Java-M2 Environment: M2 Reporter: Scott Kurz Running code from the M2 branch, my Composite has a JSP and a Composite-level reference MyRef with binding.ws and interface.wsdl. My JSP does locateService(MyRef) At invocation time I get: java.lang.NullPointerException at org.apache.tuscany.core.wire.jdk.JDKWireService.createProxy(JDKWireService.java:92) at org.apache.tuscany.spi.extension.ReferenceExtension.getServiceInstance(ReferenceExtension.java:81) at org.apache.tuscany.spi.extension.CompositeComponentExtension.locateService (CompositeComponentExtension.java:275) at org.apache.tuscany.core.launcher.CompositeContextImpl.locateService(CompositeContextImpl.java:65) This is an issue of using the locateService API as opposed to @Reference injection. It has nothing to do with the lack of a Component in my Composite. Maybe this isn't strictly spec'd but it seems that since Tuscany can handle: * interface.wsdl combined w/ Reference injection * interface.java combined w/ locateService we also should/could support: * interface.wsdl combined w/ locateService. Don't know how to go about building the proxy myself but I'll open this to track the issue. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-642) Composite references and services - model and runtime representations
[
http://issues.apache.org/jira/browse/TUSCANY-642?page=comments#action_12433608
]
Scott Kurz commented on TUSCANY-642:
I'm having two problems w/ this last patch, RevisedInnerCompositeCallback.patch
First, when I try to apply w/:
patch -p0 -i *.patch
I get:
patching file
sca/kernel/core/src/test/java/org/apache/tuscany/core/implementation/composite/CompositeBuilderTestCase.java
Hunk #2 FAILED at 44.
So I hand-patched that. Second there looks to be a typo in JDKWireService,
line 308:
for (Operation? operation :
contract.getCallbacksOperations().values()) {
That should be: : contract.getCallbackOperation() I think; the other won't
compile.
I would post an update but I don't understand the 1st problem (looks fine to
me) so I'll leave that to you.
Composite references and services - model and runtime representations
-
Key: TUSCANY-642
URL: http://issues.apache.org/jira/browse/TUSCANY-642
Project: Tuscany
Issue Type: New Feature
Components: Java SCA Core
Affects Versions: Java-Mx
Reporter: Ignacio Silva-Lepe
Assigned To: Jim Marino
Fix For: Java-Mx
Attachments: CompositeRefsAndSvcs.txt, CompositeRefsAndSvcs2.txt,
InnerComposite.patch, InnerCompositeCallback.patch,
InnerCompositeCallback2.patch, RevisedInnerCompositeCallback.patch
Support is added to represent composite references and services (those in a
composite and without a binding) in the model and runtime. The
CompositeBuilder is updated to build a composite component that includes
composite references and services without bindings.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-686) InterfaceWSDLLoader creates WSDLServiceContract objs which return null on getInterfaceClass()
[
http://issues.apache.org/jira/browse/TUSCANY-686?page=comments#action_12432666
]
Scott Kurz commented on TUSCANY-686:
A few points I'd like to add to the discussion here:
First,
1) It could be that it's best to consider it to be the binding's (e.g. the
Axis2 WS binding's) responsibility to generate a Java interface class from the
WSDLServiceContract if it needs one.I was hoping this JIRA would provoke
this discussion in case my assumption that InterfaceWSDLLoader should generate
the Java intf class was incorrect.
Next,
I went ahead and ported some code in the old
WSDLServiceContractImpl.generateJavaInterface() method to use ASM to generate
the intf.
(I won't post the patch unless it turns out I'm on the right track here)
I hit two problems:
2) I had to hack CompositeClassLoader to allow me to do a defineClass with the
generated Java class. (Not 100% sure this is needed but I'm guessing it might
be since it was present in M1 and before)
3) The ConnectorImpl check for interface compatibility is too strict.
When, in method, ConnectorImpl .connect(SCAObjectT source, OutboundWireT
sourceWire) we do:
Class sourceInterface =
sourceWire.getServiceContract().getInterfaceClass();
Class targetInterface =
targetWire.getServiceContract().getInterfaceClass();
if (!sourceInterface.isAssignableFrom(targetInterface)) {
throw new BuilderConfigException(Incompatible source and
target interfaces);
}
this says that two classes w/ compatible methods (per SCA spec) are disallowed
since they are not part of the same inheritance hieararchy.
However, if, on the one side, I have a generated Java class from a WSDL-Java
and on the other side a compatible (per SCA spec)
interface corresponding to the Java interface packaged along w/ my component w/
Java implementationthen this should be allowed by the Connector.
InterfaceWSDLLoader creates WSDLServiceContract objs which return null on
getInterfaceClass()
-
Key: TUSCANY-686
URL: http://issues.apache.org/jira/browse/TUSCANY-686
Project: Tuscany
Issue Type: Bug
Components: Java SCA Core
Affects Versions: Java-M2
Environment: r438923
Reporter: Scott Kurz
SYMPTOM (when using interface.wsdl elem along with binding.ws and Axis 2
binding:
java.lang.NullPointerException
at
org.apache.tuscany.core.builder.ConnectorImpl.connect(ConnectorImpl.java:314)
at
org.apache.tuscany.core.builder.ConnectorImpl.connect(ConnectorImpl.java:110)
at
org.apache.tuscany.core.builder.ConnectorImpl.connect(ConnectorImpl.java:91)
at
org.apache.tuscany.core.deployer.DeployerImpl.connect(DeployerImpl.java:141)
at
org.apache.tuscany.core.deployer.DeployerImpl.deploy(DeployerImpl.java:103)
at
org.apache.tuscany.core.launcher.LauncherImpl.bootApplication(LauncherImpl.java:193)
PROBLEM:
Axis2BindingBuilder.build does (line 60):
Class? interfaze =
serviceDefinition.getServiceContract().getInterfaceClass();
This simply returns null since the WSDLServiceContract built by
InterfaceWSDLLoader contains a portType but no interface class.Thus the
ConnectorImpl hits the NPE we see above.
Some sort of WSDL2Java should probably? be done when InterfaceWSDLLoader sets
the portType on the WSDLServiceContract it builds.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-695) JavaComponentTypeLoader.load() returns PojoComponentType which isn't a ModelObject
JavaComponentTypeLoader.load() returns PojoComponentType which isn't a
ModelObject
--
Key: TUSCANY-695
URL: http://issues.apache.org/jira/browse/TUSCANY-695
Project: Tuscany
Issue Type: Bug
Components: Java SCA Core
Affects Versions: Java-M2
Environment: r440401
Reporter: Scott Kurz
When I tried using a componentType file along w/ my Java impl I got:
org.apache.tuscany.spi.loader.UnrecognizedElementException :
{http://www.osoa.org/xmlns/sca/1.0}componentType
[{http://www.osoa.org/xmlns/sca/1.0}componentType ]
at
org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistryImpl.java:113)
at
org.apache.tuscany.core.implementation.java.JavaComponentTypeLoader.loadFromSidefile(JavaComponentTypeLoader.java
)
at
org.apache.tuscany.core.implementation.java.JavaComponentTypeLoader.load(JavaComponentTypeLoader.java:71)
at
org.apache.tuscany.core.implementation.java.JavaComponentTypeLoader.load(JavaComponentTypeLoader.java
:47)
at
org.apache.tuscany.core.loader.LoaderRegistryImpl.loadComponentType(LoaderRegistryImpl.java:159)
at
org.apache.tuscany.core.implementation.java.JavaImplementationLoader.load(JavaImplementationLoader.java
:57)
at
org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistryImpl.java:92)
at
org.apache.tuscany.core.loader.ComponentLoader.loadImplementation(ComponentLoader.java:133)
at org.apache.tuscany.core.loader.ComponentLoader.load
(ComponentLoader.java:84)
at
org.apache.tuscany.core.loader.ComponentLoader.load(ComponentLoader.java:57)
at
org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistryImpl.java:92)
at org.apache.tuscany.core.implementation.composite.CompositeLoader.load
(CompositeLoader.java:77)
at
org.apache.tuscany.core.implementation.composite.CompositeLoader.load(CompositeLoader.java:52)
at
org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistryImpl.java:92)
at
org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistryImpl.java:109)
at
org.apache.tuscany.core.implementation.composite.CompositeComponentTypeLoader.loadFromSidefile(CompositeComponentTypeLoader.java
:64)
at
org.apache.tuscany.core.implementation.composite.CompositeComponentTypeLoader.load(CompositeComponentTypeLoader.java:56)
at
org.apache.tuscany.core.implementation.composite.CompositeComponentTypeLoader.load
(CompositeComponentTypeLoader.java:38)
at
org.apache.tuscany.core.loader.LoaderRegistryImpl.loadComponentType(LoaderRegistryImpl.java:159)
at org.apache.tuscany.core.deployer.DeployerImpl.load(DeployerImpl.java
:118)
at
org.apache.tuscany.core.deployer.DeployerImpl.deploy(DeployerImpl.java:93)
at
org.apache.tuscany.core.launcher.LauncherImpl.bootApplication(LauncherImpl.java:193)
The problem wasn't the lack of a loader to load componentType
elems.rather, it was this line in JavaComponentTypeLoader:
protected PojoComponentType loadFromSidefile(URL url, DeploymentContext
deploymentContext) throws LoaderException {
return loaderRegistry.load(null, url, PojoComponentType.class,
deploymentContext);
}
Thie use of 'PojoComponentType.class' as argument is a problem. In
LoaderRegistryImpl.load, we do (line 109):
ModelObject mo = load(parent, reader, ctx);
if (type.isInstance(mo)) {
So we're loading into a ModelObject, (more specifically,
org.apache.tuscany.spi.model.ComponentType), but the 'type' here is :
PojoComponentType.class
which is in pkg org.apache.tuscany.core.implementation.java and passed into the
load(..) call.
On the dev list, Raymond Feng answered my email describing the problem with
this:
The ComponentTypeElementLoader creates a generic ComponentType from
the XML file but the code expects an instance of PojoComponentType. Now the
question is how to map the generic ComponentType into the PojoComponentType
if it's required. Jim, do you have ideas?
Jim Marino replied:
We should probably have the implementation loader handle creation of
the particular component type class and populate it by recursing back
into the loader since it is minimal code
(ComponentTypeElementLoader). This would be a nice patch for someone
to work on :-)
Jim
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-686) InterfaceWSDLLoader creates WSDLServiceContract objs which return null on getInterfaceClass()
InterfaceWSDLLoader creates WSDLServiceContract objs which return null on getInterfaceClass() - Key: TUSCANY-686 URL: http://issues.apache.org/jira/browse/TUSCANY-686 Project: Tuscany Issue Type: Bug Components: Java SCA Core Affects Versions: Java-M2 Environment: r438923 Reporter: Scott Kurz SYMPTOM (when using interface.wsdl elem along with binding.ws and Axis 2 binding: java.lang.NullPointerException at org.apache.tuscany.core.builder.ConnectorImpl.connect(ConnectorImpl.java:314) at org.apache.tuscany.core.builder.ConnectorImpl.connect(ConnectorImpl.java:110) at org.apache.tuscany.core.builder.ConnectorImpl.connect(ConnectorImpl.java:91) at org.apache.tuscany.core.deployer.DeployerImpl.connect(DeployerImpl.java:141) at org.apache.tuscany.core.deployer.DeployerImpl.deploy(DeployerImpl.java:103) at org.apache.tuscany.core.launcher.LauncherImpl.bootApplication(LauncherImpl.java:193) PROBLEM: Axis2BindingBuilder.build does (line 60): Class? interfaze = serviceDefinition.getServiceContract().getInterfaceClass(); This simply returns null since the WSDLServiceContract built by InterfaceWSDLLoader contains a portType but no interface class.Thus the ConnectorImpl hits the NPE we see above. Some sort of WSDL2Java should probably? be done when InterfaceWSDLLoader sets the portType on the WSDLServiceContract it builds. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-679) InterfaceWSDLLoader mismatch btw. @Constructor annot. and actual Constructor parms
InterfaceWSDLLoader mismatch btw. @Constructor annot. and actual Constructor
parms
---
Key: TUSCANY-679
URL: http://issues.apache.org/jira/browse/TUSCANY-679
Project: Tuscany
Issue Type: Bug
Components: Java SCA Axis Binding
Affects Versions: Java-M2
Reporter: Scott Kurz
PROBLEM:
Mismatch btw. annotation:
@Constructor({registry})
and Constructor:
public InterfaceWSDLLoader(@Autowire LoaderRegistry registry,
@Autowire WSDLDefinitionRegistry wsdlRegistry) {
SYMPTOM:
org.apache.tuscany.core.implementation.processor.InvalidAutowireException:
Names in @Constructor and autowire parameter do not match at 2 [public
org.apache.tuscany.idl.wsdl.InterfaceWSDLLoader(org.apache.tuscany.spi.loader.LoaderRegistry,org.apache.tuscany.idl.wsdl.WSDLDefinitionRegistry)]
Context stack trace: [tuscany.system][intf.wsdl.loader]
at
org.apache.tuscany.core.implementation.processor.ImplementationProcessorServiceImpl.processAutowire(ImplementationProcessorServiceImpl.java:186)
at
org.apache.tuscany.core.implementation.processor.ImplementationProcessorServiceImpl.processParam(ImplementationProcessorServiceImpl.java:113)
at
org.apache.tuscany.core.implementation.processor.ConstructorProcessor.visitConstructor(ConstructorProcessor.java:94)
at
org.apache.tuscany.core.implementation.IntrospectionRegistryImpl.introspect(IntrospectionRegistryImpl.java:83)
at
org.apache.tuscany.core.implementation.system.loader.SystemComponentTypeLoader.loadByIntrospection(SystemComponentTypeLoader.java:85)
at
org.apache.tuscany.core.implementation.system.loader.SystemComponentTypeLoader.load(SystemComponentTypeLoader.java:69)
at
org.apache.tuscany.core.implementation.system.loader.SystemComponentTypeLoader.load(SystemComponentTypeLoader.java:42)
at
org.apache.tuscany.core.loader.LoaderRegistryImpl.loadComponentType(LoaderRegistryImpl.java:159)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-679) InterfaceWSDLLoader mismatch btw. @Constructor annot. and actual Constructor parms
[ http://issues.apache.org/jira/browse/TUSCANY-679?page=all ]
Scott Kurz updated TUSCANY-679:
---
Attachment: InterfaceWSDLLoader.ConstructorFix.patch
Hopefully this is the right patch format (this is my first patch here)
InterfaceWSDLLoader mismatch btw. @Constructor annot. and actual Constructor
parms
---
Key: TUSCANY-679
URL: http://issues.apache.org/jira/browse/TUSCANY-679
Project: Tuscany
Issue Type: Bug
Components: Java SCA Axis Binding
Affects Versions: Java-M2
Reporter: Scott Kurz
Attachments: InterfaceWSDLLoader.ConstructorFix.patch
PROBLEM:
Mismatch btw. annotation:
@Constructor({registry})
and Constructor:
public InterfaceWSDLLoader(@Autowire LoaderRegistry registry,
@Autowire WSDLDefinitionRegistry wsdlRegistry)
{
SYMPTOM:
org.apache.tuscany.core.implementation.processor.InvalidAutowireException:
Names in @Constructor and autowire parameter do not match at 2 [public
org.apache.tuscany.idl.wsdl.InterfaceWSDLLoader(org.apache.tuscany.spi.loader.LoaderRegistry,org.apache.tuscany.idl.wsdl.WSDLDefinitionRegistry)]
Context stack trace: [tuscany.system][intf.wsdl.loader]
at
org.apache.tuscany.core.implementation.processor.ImplementationProcessorServiceImpl.processAutowire(ImplementationProcessorServiceImpl.java:186)
at
org.apache.tuscany.core.implementation.processor.ImplementationProcessorServiceImpl.processParam(ImplementationProcessorServiceImpl.java:113)
at
org.apache.tuscany.core.implementation.processor.ConstructorProcessor.visitConstructor(ConstructorProcessor.java:94)
at
org.apache.tuscany.core.implementation.IntrospectionRegistryImpl.introspect(IntrospectionRegistryImpl.java:83)
at
org.apache.tuscany.core.implementation.system.loader.SystemComponentTypeLoader.loadByIntrospection(SystemComponentTypeLoader.java:85)
at
org.apache.tuscany.core.implementation.system.loader.SystemComponentTypeLoader.load(SystemComponentTypeLoader.java:69)
at
org.apache.tuscany.core.implementation.system.loader.SystemComponentTypeLoader.load(SystemComponentTypeLoader.java:42)
at
org.apache.tuscany.core.loader.LoaderRegistryImpl.loadComponentType(LoaderRegistryImpl.java:159)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-662) Axis2 Binding's OperationClient needs to be reset to support repeated invocation
Axis2 Binding's OperationClient needs to be reset to support repeated invocation Key: TUSCANY-662 URL: http://issues.apache.org/jira/browse/TUSCANY-662 Project: Tuscany Issue Type: Bug Components: Java SCA Axis Binding Affects Versions: Java-M2 Environment: Revision: 433239 Reporter: Scott Kurz When I invoke my service w/ WS binding (Axis2) a second time I get the following exception stack trace: java.lang.reflect.InvocationTargetException at org.apache.tuscany.binding.axis2.Axis2TargetInvoker.invokeTarget(Axis2TargetInvoker.java:138) at org.apache.tuscany.binding.axis2.Axis2TargetInvoker.invoke(Axis2TargetInvoker.java:145) at org.apache.tuscany.core.wire.InvokerInterceptor.invoke(InvokerInterceptor.java:44) at org.apache.tuscany.core.wire.jdk.AbstractJDKOutboundInvocationHandler.invoke(AbstractJDKOutboundInvocationHandler.java:75) at org.apache.tuscany.core.wire.jdk.JDKOutboundInvocationHandler.invoke(JDKOutboundInvocationHandler.java:83) ... 32 more Caused by: org.apache.axis2.AxisFault: Invalid message addition , operation context completed at org.apache.axis2.description.OutInAxisOperation.addMessageContext(OutInAxisOperation.java:64) at org.apache.axis2.context.OperationContext.addMessageContext(OperationContext.java:89) at org.apache.axis2.description.AxisOperation.registerOperationContext(AxisOperation.java:369) at org.apache.axis2.description.OutInAxisOperationClient.addMessageContext(OutInAxisOperation.java:158) at org.apache.tuscany.binding.axis2.Axis2TargetInvoker.invokeTarget(Axis2TargetInvoker.java:99) In looking at the source for method addMessageContext in class org.apache.axis2.description.OutInAxisOperation it appears that the operation context needs to be reset or cleared somehow so that both the in and out values are not set during subsequent invocations after the first. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-232) It would be educational to provide a flavor of the HelloWorld WS / HWWS Client sample which used different names in different contexts where the name HelloWorldService
[ http://issues.apache.org/jira/browse/TUSCANY-232?page=comments#action_12378718 ] Scott Kurz commented on TUSCANY-232: So I can see that the rework of HelloWorld WS Client which has already bee done goes a long way towards making the client more comprehensible. After the rework we use a client module with only an external service and with no component, so the client-side HelloWorldService no longer gets in the way. (I wonder if the original reason for using the client proxy service was due to a bug or then-unimplemented feature in the Tuscany code). I'm not sure if this was done in JIRA-268 or when exactly. All that remains of my comment is: 1) to use a name like HelloWorldExternalService in the locateService call, (and to match this in sca.module) 2) use a URL like: http://localhost:8080/helloworldws-SNAPSHOT/services/HelloWorldServiceEntryPoint; So I will go ahead and post this. However , I'm realizing that HelloWorld WS seems to have gone away. Does anyone know when it will settle down? I see in JIRA-268 we've moved to the sca/samples directory but I'm not sure what happened to HelloWorld WS. Now that the client proxy is gone, I don't think the remaining items are nearly as confusing, (and arguably don't even need to be done). However, once HelloWorld WS is settled down I'll post updates to both HelloWorldWSClient and HelloWorldWS and let the list decide how/if to use them. It would be educational to provide a flavor of the HelloWorld WS / HWWS Client sample which used different names in different contexts where the name HelloWorldService is used today --- Key: TUSCANY-232 URL: http://issues.apache.org/jira/browse/TUSCANY-232 Project: Tuscany Type: Improvement Components: Java SCA Samples Versions: M1 Environment: Any Reporter: Scott Kurz Assignee: Jean-Sebastien Delfino Fix For: M1 A confusing aspect of the HelloWorld WS sample is the fact that certain strings are repeated in different contexts. For example, looking at HelloWorld WS Client, one can see four distinct usages of the string, HelloWorldService. 1. It is the name of the client-side SCA service, which is invoked by the HelloWorldClient main() program. 2. It is the type of the reference variable used in HelloWorldServiceComponentImpl to invoke the ES over the WS binding 3. It is the name of the externalService appearing in sca.module: externalService name=HelloWorldService 4. It appears in the client-side WSDL URL in order to match the deployment location of the EP-side Hello World WS WAR wsdlsoap:address location=http://localhost:8080/helloworldws-SNAPSHOT/services/HelloWorldService/ It is certainly instructive that you can overload the string in this way. However, it is at the same time confusing to a completely new user as he has to sort out which appearances of the HelloWorldService string need to stay in synch with which other uses, and which do not. It might be educational to also provide a flavor of the HelloWorld WS sample in which distinct names are used in each of these four locations, e.g.: HelloWorldClientService HelloWorldWSInterface HelloWorldES HelloWorldService Another alternative would be to include in the documenation and exercise instructing the user to do just this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (TUSCANY-232) It would be educational to provide a flavor of the HelloWorld WS / HWWS Client sample which used different names in different contexts where the name HelloWorldService
[ http://issues.apache.org/jira/browse/TUSCANY-232?page=all ] Scott Kurz updated TUSCANY-232: --- Attachment: JIRA-232.patch.zip OK... so I didn't refresh my page in 3 hours and missed Sebastien's comment. I attached the only thing left, which is just the HelloWorldClient java file and the client-side sca.module file... to use name HelloWorldExternalService. Now it's looking even less necessary but perhaps a slight improvement. Sorry it took me so long .. I had to adjust a bit to the refactoring... THanks It would be educational to provide a flavor of the HelloWorld WS / HWWS Client sample which used different names in different contexts where the name HelloWorldService is used today --- Key: TUSCANY-232 URL: http://issues.apache.org/jira/browse/TUSCANY-232 Project: Tuscany Type: Improvement Components: Java SCA Samples Versions: M1 Environment: Any Reporter: Scott Kurz Assignee: Jean-Sebastien Delfino Fix For: M1 Attachments: JIRA-232.patch.zip A confusing aspect of the HelloWorld WS sample is the fact that certain strings are repeated in different contexts. For example, looking at HelloWorld WS Client, one can see four distinct usages of the string, HelloWorldService. 1. It is the name of the client-side SCA service, which is invoked by the HelloWorldClient main() program. 2. It is the type of the reference variable used in HelloWorldServiceComponentImpl to invoke the ES over the WS binding 3. It is the name of the externalService appearing in sca.module: externalService name=HelloWorldService 4. It appears in the client-side WSDL URL in order to match the deployment location of the EP-side Hello World WS WAR wsdlsoap:address location=http://localhost:8080/helloworldws-SNAPSHOT/services/HelloWorldService/ It is certainly instructive that you can overload the string in this way. However, it is at the same time confusing to a completely new user as he has to sort out which appearances of the HelloWorldService string need to stay in synch with which other uses, and which do not. It might be educational to also provide a flavor of the HelloWorld WS sample in which distinct names are used in each of these four locations, e.g.: HelloWorldClientService HelloWorldWSInterface HelloWorldES HelloWorldService Another alternative would be to include in the documenation and exercise instructing the user to do just this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (TUSCANY-235) EntryPoint name must match wired-to Service name
[ http://issues.apache.org/jira/browse/TUSCANY-235?page=comments#action_12376728 ] Scott Kurz commented on TUSCANY-235: Sorry.. still learning JIRA and I replied to the list but not added a JIRA comment. I'd said that the problem went away when I pulled the repo on 4/26, as I tweaked BigBank to test my issue. So, I don't think I have the power to close the JIRA I opened, but I'm OK with doing so. And, like Jim suggested...I'll test with today's repository before the milestone release when hitting future problems. EntryPoint name must match wired-to Service name Key: TUSCANY-235 URL: http://issues.apache.org/jira/browse/TUSCANY-235 Project: Tuscany Type: Bug Components: Java SCA Core Environment: Ran after pulling SVN contents April 17th in Tomcat on Windows Reporter: Scott Kurz Priority: Minor With a WS binding you currently need to match the EntryPoint name with the name of the Service it is wired to via the references tag. So, for example, in the HelloWorld WS sample's sca.module file, you have: entryPoint name=HelloWorldService interface.wsdl interface=http://helloworldaxis.samples.tuscany.apache.org#HelloWorldServiceImpl/ binding.ws port=http://helloworldaxis.samples.tuscany.apache.org#helloworld/ referenceHelloWorldServiceComponent/HelloWorldService/reference /entryPoint You should be able to rename the entryPoint as: entryPoint name=HelloWorldServiceEP but be able to keep the reference as: referenceHelloWorldServiceComponent/HelloWorldService/reference But when I tried this recently in Tomcat I had this problem. SEVERE: Error deploying web application archive helloworldws.war org.apache.tuscany.core.context.ContextInitException: No proxy factory found for service [HelloWorldServiceEP] Context stack trace: [tuscany.root][/helloworldws][/helloworldws][HelloWorldServiceEP][HelloWorldServiceComponent] at org.apache.tuscany.core.context.impl.AbstractCompositeContext.wireSource(AbstractCompositeContext.java:568) at org.apache.tuscany.core.context.impl.AbstractCompositeContext.start(AbstractCompositeContext.java:149) at org.apache.tuscany.core.context.scope.CompositeScopeContext.registerFactory(CompositeScopeContext.java:95) at org.apache.tuscany.core.context.impl.AbstractCompositeContext.registerConfiguration(AbstractCompositeContext.java:457) at org.apache.tuscany.core.context.impl.AbstractCompositeContext.registerModelObject(AbstractCompositeContext.java:404) at org.apache.tuscany.tomcat.TuscanyContextListener.loadContext(TuscanyContextListener.java:133) at org.apache.tuscany.tomcat.TuscanyContextListener.startContext(TuscanyContextListener.java:85) at org.apache.tuscany.tomcat.TuscanyContextListener.lifecycleEvent(TuscanyContextListener.java:71) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4119) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:759) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:739) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:524) at org.apache.tuscany.tomcat.TuscanyHost.addChild(TuscanyHost.java:117) at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:809) at org.apache.catalina.startup.HostConfig.deployWARs(HostConfig.java:698) at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:472) at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1122) at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:310) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1021) at org.apache.catalina.core.StandardHost.start(StandardHost.java:718) at org.apache.tuscany.tomcat.TuscanyHost.start(TuscanyHost.java:60) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1013) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:442) at org.apache.catalina.core.StandardService.start(StandardService.java:450) at org.apache.catalina.core.StandardServer.start(StandardServer.java:709) at org.apache.catalina.startup.Catalina.start(Catalina.java:551) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615)
[jira] Created: (TUSCANY-232) It would be educational to provide a flavor of the HelloWorld WS / HWWS Client sample which used different names in different contexts where the name HelloWorldService
It would be educational to provide a flavor of the HelloWorld WS / HWWS Client sample which used different names in different contexts where the name HelloWorldService is used today --- Key: TUSCANY-232 URL: http://issues.apache.org/jira/browse/TUSCANY-232 Project: Tuscany Type: Improvement Components: Java Samples HelloWorld Environment: Any Reporter: Scott Kurz Priority: Minor A confusing aspect of the HelloWorld WS sample is the fact that certain strings are repeated in different contexts. For example, looking at HelloWorld WS Client, one can see four distinct usages of the string, HelloWorldService. 1. It is the name of the client-side SCA service, which is invoked by the HelloWorldClient main() program. 2. It is the type of the reference variable used in HelloWorldServiceComponentImpl to invoke the ES over the WS binding 3. It is the name of the externalService appearing in sca.module: externalService name=HelloWorldService 4. It appears in the client-side WSDL URL in order to match the deployment location of the EP-side Hello World WS WAR wsdlsoap:address location=http://localhost:8080/helloworldws-SNAPSHOT/services/HelloWorldService/ It is certainly instructive that you can overload the string in this way. However, it is at the same time confusing to a completely new user as he has to sort out which appearances of the HelloWorldService string need to stay in synch with which other uses, and which do not. It might be educational to also provide a flavor of the HelloWorld WS sample in which distinct names are used in each of these four locations, e.g.: HelloWorldClientService HelloWorldWSInterface HelloWorldES HelloWorldService Another alternative would be to include in the documenation and exercise instructing the user to do just this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (TUSCANY-235) EntryPoint name must match wired-to Service name
[ http://issues.apache.org/jira/browse/TUSCANY-235?page=comments#action_12376523 ] Scott Kurz commented on TUSCANY-235: I might have picked a bad name for the JIRA.The phrase, EntryPoint name must match wired-to Service name is the problem, not the solution needed. The solution would be to eliminate this requirement. Sorry, Scott EntryPoint name must match wired-to Service name Key: TUSCANY-235 URL: http://issues.apache.org/jira/browse/TUSCANY-235 Project: Tuscany Type: Bug Components: Java SCA Core Environment: Ran after pulling SVN contents April 17th in Tomcat on Windows Reporter: Scott Kurz Priority: Minor With a WS binding you currently need to match the EntryPoint name with the name of the Service it is wired to via the references tag. So, for example, in the HelloWorld WS sample's sca.module file, you have: entryPoint name=HelloWorldService interface.wsdl interface=http://helloworldaxis.samples.tuscany.apache.org#HelloWorldServiceImpl/ binding.ws port=http://helloworldaxis.samples.tuscany.apache.org#helloworld/ referenceHelloWorldServiceComponent/HelloWorldService/reference /entryPoint You should be able to rename the entryPoint as: entryPoint name=HelloWorldServiceEP but be able to keep the reference as: referenceHelloWorldServiceComponent/HelloWorldService/reference But when I tried this recently in Tomcat I had this problem. SEVERE: Error deploying web application archive helloworldws.war org.apache.tuscany.core.context.ContextInitException: No proxy factory found for service [HelloWorldServiceEP] Context stack trace: [tuscany.root][/helloworldws][/helloworldws][HelloWorldServiceEP][HelloWorldServiceComponent] at org.apache.tuscany.core.context.impl.AbstractCompositeContext.wireSource(AbstractCompositeContext.java:568) at org.apache.tuscany.core.context.impl.AbstractCompositeContext.start(AbstractCompositeContext.java:149) at org.apache.tuscany.core.context.scope.CompositeScopeContext.registerFactory(CompositeScopeContext.java:95) at org.apache.tuscany.core.context.impl.AbstractCompositeContext.registerConfiguration(AbstractCompositeContext.java:457) at org.apache.tuscany.core.context.impl.AbstractCompositeContext.registerModelObject(AbstractCompositeContext.java:404) at org.apache.tuscany.tomcat.TuscanyContextListener.loadContext(TuscanyContextListener.java:133) at org.apache.tuscany.tomcat.TuscanyContextListener.startContext(TuscanyContextListener.java:85) at org.apache.tuscany.tomcat.TuscanyContextListener.lifecycleEvent(TuscanyContextListener.java:71) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4119) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:759) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:739) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:524) at org.apache.tuscany.tomcat.TuscanyHost.addChild(TuscanyHost.java:117) at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:809) at org.apache.catalina.startup.HostConfig.deployWARs(HostConfig.java:698) at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:472) at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1122) at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:310) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1021) at org.apache.catalina.core.StandardHost.start(StandardHost.java:718) at org.apache.tuscany.tomcat.TuscanyHost.start(TuscanyHost.java:60) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1013) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:442) at org.apache.catalina.core.StandardService.start(StandardService.java:450) at org.apache.catalina.core.StandardServer.start(StandardServer.java:709) at org.apache.catalina.startup.Catalina.start(Catalina.java:551) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:294) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:432) -- This message is automatically generated by JIRA. - If
[jira] Created: (TUSCANY-217) WSDLDefinition caching allows EntryPoint WS URLs to clobber ExternalService URLs
WSDLDefinition caching allows EntryPoint WS URLs to clobber ExternalService URLs - Key: TUSCANY-217 URL: http://issues.apache.org/jira/browse/TUSCANY-217 Project: Tuscany Type: Improvement Components: Java SCA Model Environment: Windows - Tomcat - April 17th download of Tuscany SVN Reporter: Scott Kurz Priority: Minor At a high-level, the problem is just that the URL in the EntryPoint-side WSDL used in a WS binding.sometimes matters and sometimes does not. When invoking over a WS binding, it might be nice to say that, although both client and server have a copy of the WSDL, that only the client URL matters, but not the server's. The URL I'm talking about appears in the WSDL's wsdlsoap:address tag. If an ExternalService using a WS binding with the same namespace as the Entry Point is hosted in the same process as the Entry Point, then the URL used to invoke the ExternalService will come from whichever WSDL Definition is loaded first, the EntryPoint's or the ExternalService's. To be sure that the correct URL is used, you must keep both URLs in synch with the URL corresponding to the URL at which the app is actually hosted (i.e. the IP address and port of your Tomcat service, plus your app's context root, plus the SCA-specific portion of the URL at the end). If the ExternalService lives in another JVM, however, then the EntryPoint WSDL's URL is irrelevant for invoking the SCA WS over the External Service WS binding. Then you only need to synchronize the External Service URL with the URL at which the app is actually hosted. By adding an External Service into the same JVM as the SCA WS with Entry Point , then, you all of a sudden make the Entry Point WSDL's URL relevant. To recreate this problem, take the HelloWorldWSClient sample, and put a JSP front-end on it, and package it into a WAR.Then take the HelloWorld WS sample WAR, and tweak the URL to something that doesn't match your Tomcat server's URL. If you install both WARs and you ensure that the newly-created HelloWorldWSClient WAR starts before the HelloWorld WS WAR (with bad URL), the sample will work fine... HelloWorldWSClient WAR will call out the WS in HelloWorld WS. If, however, the apps are started in reverse order, the garbage URL on the EntryPoint-side will take effect and it don't work. At a low-level, the problem seems to be the definitionsByNamespace map used by the method org.apache.tuscany.model.scdl.loader.impl.SCDLAssemblyModelLoaderImpl.loadDefinitions, which maps namespaces to WSDL Definitions. Assuming there is value caching WSDL Definitions per Namespace, maybe the cache should be implemented such that EntryPoint-side URLs would not take precedence over an ExternalService-side URL in this manner. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
