[jira] Commented: (TUSCANY-2324) InterfaceContract is not pushed down to an inner, promoted component reference only with Axis2 binding
[ https://issues.apache.org/jira/browse/TUSCANY-2324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12604207#action_12604207 ] Simon Laws commented on TUSCANY-2324: - Is there a test case for this issue that shows the problem? I'm eyeballing the code and its interesting as the code that processes promotion on the reference side works differently to the code that processes promotion on the service side. On the reference side it only copies the bindings down. On the service side it does interface contracts also. 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.
Re: [jira] Commented: (TUSCANY-2324) InterfaceContract is not pushed down to an inner, promoted component reference only with Axis2 binding
Simon,
I originally noticed this problem by inspecting trace, and I'm still looking
for an idea how to test this.
The reason it's difficult is interesting.
I thought I'd just take a WS, grab the WSDL, declare it via interface.wsdl
on the outer reference,
and have the inner Java client intf use a package that I knew would map to a
different TNS than that of the portType in the service WSDL.
This is using doc-lit-wrapped WSDL so I thought the wrapper elem with wrong
TNS in the payload would be a problem.
Though the client does send the bad wrapper elem in the SOAP payload, the
service (of course a Tuscany service with binding.ws)
handles the data just fine.Our Tuscany databinding code just realizes
that it can't convert wrapper to wrapper so it simply switches
to convert the wrapper's children.
The reason is the code in Input2InputTransformer:
...
if (sourceWrapperHandler.isInstance(sourceWrapper,
wrapperElement, childElements, context)) {
plus the OMElementWrapperHandler implementation
public boolean isInstance(...)
if (!element.getQName().equals(wrapper.getQName())) {
return false;
So, on the one hand, I thought this was interesting.
On the other, still looking for an idea to test this. Is there an easy way
to create say a raw Axis2 service hosted in the itest environment that would
not be so tolerant?
Scott
On Wed, Jun 11, 2008 at 8:54 AM, Simon Laws (JIRA)
tuscany-dev@ws.apache.org wrote:
[
https://issues.apache.org/jira/browse/TUSCANY-2324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12604207#action_12604207]
Simon Laws commented on TUSCANY-2324:
-
Is there a test case for this issue that shows the problem? I'm eyeballing
the code and its interesting as the code that processes promotion on the
reference side works differently to the code that processes promotion on the
service side. On the reference side it only copies the bindings down. On the
service side it does interface contracts also.
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)http://blah#wsdl.interface%28HelloWorld%29
/
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-2324) InterfaceContract is not pushed down to an inner, promoted component reference only with Axis2 binding
[ https://issues.apache.org/jira/browse/TUSCANY-2324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12597382#action_12597382 ] Simon Nash commented on TUSCANY-2324: - Disclaimer: I haven't yet looked at the code. I think the interface contract on the outer reference should be used for the WS binding. According to the spec rules, it must provide a compatible subset of operations on the interface for the inner reference. If the generated WSDL doesn't match the actual WSDL, this suggests that the interfaces are not compatible, which would violate the spec and should be diagnosed as an error. There's a JIRA (TUSCANY-2109) already open for what looks like a very similar problem caused by namespace conflicts between the two interfaces. It may be possible to close this JIRA as a duplicate of TUSCANY-2109. 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.
Re: [jira] Commented: (TUSCANY-2316) Axis2 Binding Provider does not handle services references with WSDL interfaces correctly
Hi, Mike, I have fixed the DOM transformation issue (TUSCANY-2321) under r656747. Thanks, Raymond -- From: Mike Edwards [EMAIL PROTECTED] Sent: Wednesday, May 14, 2008 2:07 PM To: tuscany-dev@ws.apache.org Subject: Re: [jira] Commented: (TUSCANY-2316) Axis2 Binding Provider does not handle services references with WSDL interfaces correctly Scott Kurz wrote: Oh, I see what I was confused about. The WebServiceBindingImpl object is not going to have an IC in your case in which you simply declare an empty element: binding.ws/ It is in fact, going to set the IC from the component ref/srvc IC.For some reason I had it in my had that things worked differently, but now I see why the clone is needed. Thanks for talking me through that... Scott Sorry, Scott, I should have made it clear that when that code executes, the wsBinding has a null IC - Luciano has explained this clearly now. The code did not deal with the null IC correctly and this caused the initial problem here. As Luciano explained in another thread, there were then 2 other problems in the data path from the Axis binding to the BPEL process. Luciano fixed those to enable BPEL over WS-* to work, but I think there are deeper issues to look at for both those fixes - eg why does the databinding code generate different DOM trees depending on the path through the code? Yours, Mike.
[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=12596708#action_12596708 ] Mike Edwards commented on TUSCANY-2316: --- Scott, The ClassCastExceptions occur in the BPELInvoker.createInvocationMessage(...) method and are caused by that code being delivered message arguments that are not the DOM Elements that it expects. The InterfaceContract overwrite means that Axis2 related OMElements are delivered. Fixing the InterfaceContract overwrite in Axis2ReferenceBindingProvider and Axis2ServiceBindingProvider (by cloning the Interface...) then reveals a second problem, this time associated with the DataBinding code. The DataBinding code converting from OMElements to DOM generates a message which has a Document root element, while the code in createInvocationMessage expects only the internal Element elements. The simplest fix for this is to modify the createInvocationMessage code to strip off the Document element, if there is one. Doing this then reveals yet another problem, this time with the exact form of the elements in the DOM tree passed in from the DataBinding code - this causes an exception within the ODE BPEL server code. Still investigating that one with Luciano 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.
Re: [jira] Commented: (TUSCANY-2316) Axis2 Binding Provider does not handle services references with WSDL interfaces correctly
Mike, Just trying to use this issue to test/expand my own understanding of the Tuscany databinding framework. You're saying there's a problem with setting (resetting) the Axiom DB on the IC obtained from the WebServiceBindingImpl.I'm just trying to understand what the problem could be. What second purpose could this particular IC be serving that you need to clone the original and only set the Axiom DB on a cloned copy? Say we look at the DataBindingRuntimeWireProcessor processing and we are looking at the service-side Axis2 binding, where the wireSource IC is then the Axis2 binding IC and the wireTarget IC is a BPEL impl IC. So what side effect is happening in setting the wireSource IC with the Axiom DB?It seems the wireTarget side of the question should be built off a completely separate IC object... even though this IC is also built off the same WSDL file, I'd think distinct objects should be created and you wouldn't need a clone. Scott
Re: [jira] Commented: (TUSCANY-2316) Axis2 Binding Provider does not handle services references with WSDL interfaces correctly
Scott Kurz wrote: Mike, Just trying to use this issue to test/expand my own understanding of the Tuscany databinding framework. You're saying there's a problem with setting (resetting) the Axiom DB on the IC obtained from the WebServiceBindingImpl.I'm just trying to understand what the problem could be. What second purpose could this particular IC be serving that you need to clone the original and only set the Axiom DB on a cloned copy? Say we look at the DataBindingRuntimeWireProcessor processing and we are looking at the service-side Axis2 binding, where the wireSource IC is then the Axis2 binding IC and the wireTarget IC is a BPEL impl IC. So what side effect is happening in setting the wireSource IC with the Axiom DB?It seems the wireTarget side of the question should be built off a completely separate IC object... even though this IC is also built off the same WSDL file, I'd think distinct objects should be created and you wouldn't need a clone. Scott Scott, Glad you've taken this out of the JIRA comments and on to the list - easier to communicate this way ;-). The point about the original code in Axis2ReferenceBindingProvider and Axis2ServiceBindingProvider is that there is SUPPOSED to be a new InterfaceContract for the Axis binding itself - separate from the InterfaceContract of the BPEL component. The wire, when it is created must be able to see the databinding for the BPEL process (DOM) and the separate databinding for the Axis binding code (OMElements) and then generate the appropriate conversions between the two. The current code in Axis2ReferenceBindingProvider and Axis2ServiceBindingProvider is wrong since for a WSDL InterfaceContract, it does not create a separate InterfaceContract for the Axis binding - it simply hands over the one from the BPEL Process. When the Axis binding does some updates, in particular for the databinding used, it simply overwrites the BPEL Process information. This causes the databinding conversion code to assume that no transformation is necessary and as a result, the wrong stuff gets delivered. Result: BANG! - some nasty type conversion failure at a random point in the code. I'd have submitted a fix by now if I had not found yet another bug lurking behind this one I want to get my Sample code for BPEL process exposed as a Webservice working before I commit a fix. Yours, Mike.
Re: [jira] Commented: (TUSCANY-2316) Axis2 Binding Provider does not handle services references with WSDL interfaces correctly
Mike,
On Wed, May 14, 2008 at 9:41 AM, Mike Edwards
[EMAIL PROTECTED] wrote:
Scott,
Glad you've taken this out of the JIRA comments and on to the list -
easier to communicate this way ;-).
The point about the original code in Axis2ReferenceBindingProvider and
Axis2ServiceBindingProvider is that there is SUPPOSED to be a new
InterfaceContract for the Axis binding itself - separate from the
InterfaceContract of the BPEL component. The wire, when it is created must
be able to see the databinding for the BPEL process (DOM) and the separate
databinding for the Axis binding code (OMElements) and then generate the
appropriate conversions between the two.
The current code in Axis2ReferenceBindingProvider and
Axis2ServiceBindingProvider is wrong since for a WSDL InterfaceContract, it
does not create a separate InterfaceContract for the Axis binding - it
simply hands over the one from the BPEL Process. When the Axis binding does
some updates, in particular for the databinding used, it simply overwrites
the BPEL Process information. This causes the databinding conversion code
to assume that no transformation is necessary and as a result, the wrong
stuff gets delivered. Result: BANG! - some nasty type conversion failure
at a random point in the code.
Yes there is supposed to be a distinct IC between the wireSource IC (Axis2
binding IC) and the wireTarget IC (where the target is the BPEL-implemented
component). But are we sure the problem is with the binding side and not
the impl side?
Look at what the Axis2 binding code does:
public Axis2ServiceBindingProvider(RuntimeComponent component,.)
InterfaceContract contract =
wsBinding.getBindingInterfaceContract();
It just gets the IC from the WS binding.
From what you're saying, it sounds like this IC obtained from the binding is
somehow in the picture as the wireTarget IC as well.This is what
surprises me, because if we look at the WS binding resolve() method, we seem
to be creating a brand new IC at this point:
WebServiceBindingProcessor.resolve():
.
PortType portType = getPortType(model);
if (portType != null) {
WSDLInterfaceContract interfaceContract =
wsdlFactory.createWSDLInterfaceContract();
WSDLInterface wsdlInterface;
try {
wsdlInterface =
wsdlFactory.createWSDLInterface(portType, wsdlDefinition, resolver);
} catch (InvalidInterfaceException e) {
throw new ContributionResolveException(e);
}
interfaceContract.setInterface(wsdlInterface);
model.setBindingInterfaceContract(interfaceContract);
}
I don't believe the createWSDLInterface()/createWSDLInterfaceContract()
methods use a cache but rather instantiate new objects.
I would think that for a component service with intf.wsdl we would be
building a distinct IC which would become the wireTarget IC, and just am
trying to understand how changing the DB of the source IC (binding IC) in
this case can present a problem.
I'd have submitted a fix by now if I had not found yet another bug lurking
behind this one
I want to get my Sample code for BPEL process exposed as a Webservice
working before I commit a fix.
Yours, Mike.
Re: [jira] Commented: (TUSCANY-2316) Axis2 Binding Provider does not handle services references with WSDL interfaces correctly
This is all happening on the Axis2ServiceBindingProvider constructor,
and I assume that at this point the resolve method you mentioned has
not been trigerred yet. Note that when java interface is used, we
properly handle it, but we were not handling it when a WSDl interface
was in use. Below is the code with a local update to clone the
interface contract that seems to workaround/fix the issue. Maybe I
should use the code from resolve to properly fix this.
InterfaceContract contract = wsBinding.getBindingInterfaceContract();
if (contract == null) {
contract = service.getInterfaceContract().makeUnidirectional(false);
if ((contract instanceof JavaInterfaceContract)) {
contract =
Java2WSDLHelper.createWSDLInterfaceContract((JavaInterfaceContract)contract,
requiresSOAP12(wsBinding));
} else {
//WORKAROUND/FIX for TUSCANY-2316
try {
contract = (InterfaceContract) contract.clone();
} catch (Exception e) {
//ignore
}
}
wsBinding.setBindingInterfaceContract(contract);
}
.
// Set to use the Axiom data binding
contract.getInterface().resetDataBinding(OMElement.class.getName());
On Wed, May 14, 2008 at 7:45 AM, Scott Kurz [EMAIL PROTECTED] wrote:
Mike,
On Wed, May 14, 2008 at 9:41 AM, Mike Edwards
[EMAIL PROTECTED] wrote:
Scott,
Glad you've taken this out of the JIRA comments and on to the list -
easier to communicate this way ;-).
The point about the original code in Axis2ReferenceBindingProvider and
Axis2ServiceBindingProvider is that there is SUPPOSED to be a new
InterfaceContract for the Axis binding itself - separate from the
InterfaceContract of the BPEL component. The wire, when it is created must
be able to see the databinding for the BPEL process (DOM) and the separate
databinding for the Axis binding code (OMElements) and then generate the
appropriate conversions between the two.
The current code in Axis2ReferenceBindingProvider and
Axis2ServiceBindingProvider is wrong since for a WSDL InterfaceContract, it
does not create a separate InterfaceContract for the Axis binding - it
simply hands over the one from the BPEL Process. When the Axis binding does
some updates, in particular for the databinding used, it simply overwrites
the BPEL Process information. This causes the databinding conversion code
to assume that no transformation is necessary and as a result, the wrong
stuff gets delivered. Result: BANG! - some nasty type conversion failure
at a random point in the code.
Yes there is supposed to be a distinct IC between the wireSource IC (Axis2
binding IC) and the wireTarget IC (where the target is the BPEL-implemented
component). But are we sure the problem is with the binding side and not
the impl side?
Look at what the Axis2 binding code does:
public Axis2ServiceBindingProvider(RuntimeComponent component,.)
InterfaceContract contract =
wsBinding.getBindingInterfaceContract();
It just gets the IC from the WS binding.
From what you're saying, it sounds like this IC obtained from the binding is
somehow in the picture as the wireTarget IC as well.This is what
surprises me, because if we look at the WS binding resolve() method, we seem
to be creating a brand new IC at this point:
WebServiceBindingProcessor.resolve():
.
PortType portType = getPortType(model);
if (portType != null) {
WSDLInterfaceContract interfaceContract =
wsdlFactory.createWSDLInterfaceContract();
WSDLInterface wsdlInterface;
try {
wsdlInterface =
wsdlFactory.createWSDLInterface(portType, wsdlDefinition, resolver);
} catch (InvalidInterfaceException e) {
throw new ContributionResolveException(e);
}
interfaceContract.setInterface(wsdlInterface);
model.setBindingInterfaceContract(interfaceContract);
}
I don't believe the createWSDLInterface()/createWSDLInterfaceContract()
methods use a cache but rather instantiate new objects.
I would think that for a component service with intf.wsdl we would be
building a distinct IC which would become the wireTarget IC, and just am
trying to understand how changing the DB of the source IC (binding IC) in
this case can present a problem.
I'd have submitted a fix by now if I had not found yet another bug lurking
behind this one
I want to get my Sample code for BPEL process exposed as a Webservice
working before I commit a fix.
Yours, Mike.
--
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/
Re: [jira] Commented: (TUSCANY-2316) Axis2 Binding Provider does not handle services references with WSDL interfaces correctly
Oh, I see what I was confused about.
The WebServiceBindingImpl object is not going to have an IC in your case in
which you simply declare an empty element:
binding.ws/
It is in fact, going to set the IC from the component ref/srvc IC.For
some reason I had it in my had that things worked differently, but
now I see why the clone is needed.
Thanks for talking me through that...
Scott
On Wed, May 14, 2008 at 1:58 PM, Luciano Resende [EMAIL PROTECTED]
wrote:
This is all happening on the Axis2ServiceBindingProvider constructor,
and I assume that at this point the resolve method you mentioned has
not been trigerred yet. Note that when java interface is used, we
properly handle it, but we were not handling it when a WSDl interface
was in use. Below is the code with a local update to clone the
interface contract that seems to workaround/fix the issue. Maybe I
should use the code from resolve to properly fix this.
InterfaceContract contract = wsBinding.getBindingInterfaceContract();
if (contract == null) {
contract =
service.getInterfaceContract().makeUnidirectional(false);
if ((contract instanceof JavaInterfaceContract)) {
contract =
Java2WSDLHelper.createWSDLInterfaceContract((JavaInterfaceContract)contract,
requiresSOAP12(wsBinding));
} else {
//WORKAROUND/FIX for TUSCANY-2316
try {
contract = (InterfaceContract) contract.clone();
} catch (Exception e) {
//ignore
}
}
wsBinding.setBindingInterfaceContract(contract);
}
.
// Set to use the Axiom data binding
contract.getInterface().resetDataBinding(OMElement.class.getName());
On Wed, May 14, 2008 at 7:45 AM, Scott Kurz [EMAIL PROTECTED] wrote:
Mike,
On Wed, May 14, 2008 at 9:41 AM, Mike Edwards
[EMAIL PROTECTED] wrote:
Scott,
Glad you've taken this out of the JIRA comments and on to the list -
easier to communicate this way ;-).
The point about the original code in Axis2ReferenceBindingProvider and
Axis2ServiceBindingProvider is that there is SUPPOSED to be a new
InterfaceContract for the Axis binding itself - separate from the
InterfaceContract of the BPEL component. The wire, when it is created
must
be able to see the databinding for the BPEL process (DOM) and the
separate
databinding for the Axis binding code (OMElements) and then generate the
appropriate conversions between the two.
The current code in Axis2ReferenceBindingProvider and
Axis2ServiceBindingProvider is wrong since for a WSDL InterfaceContract,
it
does not create a separate InterfaceContract for the Axis binding - it
simply hands over the one from the BPEL Process. When the Axis binding
does
some updates, in particular for the databinding used, it simply
overwrites
the BPEL Process information. This causes the databinding conversion
code
to assume that no transformation is necessary and as a result, the wrong
stuff gets delivered. Result: BANG! - some nasty type conversion
failure
at a random point in the code.
Yes there is supposed to be a distinct IC between the wireSource IC
(Axis2
binding IC) and the wireTarget IC (where the target is the
BPEL-implemented
component). But are we sure the problem is with the binding side and
not
the impl side?
Look at what the Axis2 binding code does:
public Axis2ServiceBindingProvider(RuntimeComponent component,.)
InterfaceContract contract =
wsBinding.getBindingInterfaceContract();
It just gets the IC from the WS binding.
From what you're saying, it sounds like this IC obtained from the binding
is
somehow in the picture as the wireTarget IC as well.This is what
surprises me, because if we look at the WS binding resolve() method, we
seem
to be creating a brand new IC at this point:
WebServiceBindingProcessor.resolve():
.
PortType portType = getPortType(model);
if (portType != null) {
WSDLInterfaceContract interfaceContract =
wsdlFactory.createWSDLInterfaceContract();
WSDLInterface wsdlInterface;
try {
wsdlInterface =
wsdlFactory.createWSDLInterface(portType, wsdlDefinition, resolver);
} catch (InvalidInterfaceException e) {
throw new ContributionResolveException(e);
}
interfaceContract.setInterface(wsdlInterface);
model.setBindingInterfaceContract(interfaceContract);
}
I don't believe the createWSDLInterface()/createWSDLInterfaceContract()
methods use a cache but rather instantiate new objects.
I would think that for a component service with intf.wsdl we would be
building a distinct IC which would become the wireTarget IC, and just am
trying to understand how
Re: [jira] Commented: (TUSCANY-2316) Axis2 Binding Provider does not handle services references with WSDL interfaces correctly
Scott Kurz wrote: Oh, I see what I was confused about. The WebServiceBindingImpl object is not going to have an IC in your case in which you simply declare an empty element: binding.ws/ It is in fact, going to set the IC from the component ref/srvc IC.For some reason I had it in my had that things worked differently, but now I see why the clone is needed. Thanks for talking me through that... Scott Sorry, Scott, I should have made it clear that when that code executes, the wsBinding has a null IC - Luciano has explained this clearly now. The code did not deal with the null IC correctly and this caused the initial problem here. As Luciano explained in another thread, there were then 2 other problems in the data path from the Axis binding to the BPEL process. Luciano fixed those to enable BPEL over WS-* to work, but I think there are deeper issues to look at for both those fixes - eg why does the databinding code generate different DOM trees depending on the path through the code? Yours, Mike.
Re: [jira] Commented: (TUSCANY-2316) Axis2 Binding Provider does not handle services references with WSDL interfaces correctly
On Wed, May 14, 2008 at 2:07 PM, Mike Edwards [EMAIL PROTECTED] wrote: Scott Kurz wrote: Oh, I see what I was confused about. The WebServiceBindingImpl object is not going to have an IC in your case in which you simply declare an empty element: binding.ws/ It is in fact, going to set the IC from the component ref/srvc IC.For some reason I had it in my had that things worked differently, but now I see why the clone is needed. Thanks for talking me through that... Scott Sorry, Scott, I should have made it clear that when that code executes, the wsBinding has a null IC - Luciano has explained this clearly now. The code did not deal with the null IC correctly and this caused the initial problem here. As Luciano explained in another thread, there were then 2 other problems in the data path from the Axis binding to the BPEL process. Luciano fixed those to enable BPEL over WS-* to work, but I think there are deeper issues to look at for both those fixes - eg why does the databinding code generate different DOM trees depending on the path through the code? Totally agree here, that's why I left the JIRAs opened. Yours, Mike. -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/
[jira] Created: (TUSCANY-2316) Axis2 Binding Provider does not handle services references with WSDL interfaces correctly
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] Updated: (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:all-tabpanel ] Mike Edwards updated TUSCANY-2316: -- Attachment: sample-helloworld-bpel-ws.zip Sample BPEL application which exposes the BPEL component as a Web service 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-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.
Re: question on Axis2 binding use of J2W helper, building a port from an intf.wsdl portType
Scott Kurz wrote:
I think we have another case to deal with in bindings like the Axis2
binding, which is the case that the user provides a portType on
interface.wsdl
without a full port.
So the SCDL would look like:
component name=JAXBTestComponent1
implementation.java ...
service...
interface.wsdl interface=http://blah#wsdl.interface(Blah) /
binding.ws/
I admit I haven't run this test, but when I look at this code it looks like
if I find an interface.wsdl I'm going to assume
I don't need to generate a port.
public Axis2ServiceBindingProvider(RuntimeComponent component,
RuntimeComponentService service,
WebServiceBinding wsBinding,
ServletHost servletHost,
MessageFactory messageFactory) {
this.wsBinding = wsBinding;
InterfaceContract contract = wsBinding.getBindingInterfaceContract
();
if (contract == null) {
contract = service.getInterfaceContract
().makeUnidirectional(false);
if ((contract instanceof JavaInterfaceContract)) {
contract =
Java2WSDLHelper.createWSDLInterfaceContract((JavaInterfaceContract)contract,
requiresSOAP12(wsBinding));
}
wsBinding.setBindingInterfaceContract(contract);
}
I think that, not only should we still be able to generate a port in this
case, but we should start from the intf.wsdl, not the Java.
Any thoughts on this before I open a JIRA?
I think the code currently handles this case. There is code in
Axis2ServiceClient.setServiceAndPort() to take care of this possibility
by generating a service and port if necessary. This method is called by
Axis2ServiceProvider.createWSDLAxisService().
Simon
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
question on Axis2 binding use of J2W helper, building a port from an intf.wsdl portType
I think we have another case to deal with in bindings like the Axis2
binding, which is the case that the user provides a portType on
interface.wsdl
without a full port.
So the SCDL would look like:
component name=JAXBTestComponent1
implementation.java ...
service...
interface.wsdl interface=http://blah#wsdl.interface(Blah) /
binding.ws/
I admit I haven't run this test, but when I look at this code it looks like
if I find an interface.wsdl I'm going to assume
I don't need to generate a port.
public Axis2ServiceBindingProvider(RuntimeComponent component,
RuntimeComponentService service,
WebServiceBinding wsBinding,
ServletHost servletHost,
MessageFactory messageFactory) {
this.wsBinding = wsBinding;
InterfaceContract contract = wsBinding.getBindingInterfaceContract
();
if (contract == null) {
contract = service.getInterfaceContract
().makeUnidirectional(false);
if ((contract instanceof JavaInterfaceContract)) {
contract =
Java2WSDLHelper.createWSDLInterfaceContract((JavaInterfaceContract)contract,
requiresSOAP12(wsBinding));
}
wsBinding.setBindingInterfaceContract(contract);
}
I think that, not only should we still be able to generate a port in this
case, but we should start from the intf.wsdl, not the Java.
Any thoughts on this before I open a JIRA?
Thanks,
Scott
[jira] Updated: (TUSCANY-1277) Axis2 binding ?wsdl returns wsdl with wrong endpoint url when running in a webapp
[ https://issues.apache.org/jira/browse/TUSCANY-1277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ant elder updated TUSCANY-1277: --- Fix Version/s: (was: Java-SCA-Next) Java-SCA-0.91 Axis2 binding ?wsdl returns wsdl with wrong endpoint url when running in a webapp - Key: TUSCANY-1277 URL: https://issues.apache.org/jira/browse/TUSCANY-1277 Project: Tuscany Issue Type: Bug Components: Java SCA Axis Binding Extension Affects Versions: Java-SCA-0.90 Reporter: ant elder Fix For: Java-SCA-0.99 Axis2 binding ?wsdl returns wsdl with wrong endpoint url when running in a webapp -- 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-1277) Axis2 binding ?wsdl returns wsdl with wrong endpoint url when running in a webapp
[ https://issues.apache.org/jira/browse/TUSCANY-1277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ant elder updated TUSCANY-1277: --- Fix Version/s: (was: Java-SCA-0.91) Java-SCA-0.99 Axis2 binding ?wsdl returns wsdl with wrong endpoint url when running in a webapp - Key: TUSCANY-1277 URL: https://issues.apache.org/jira/browse/TUSCANY-1277 Project: Tuscany Issue Type: Bug Components: Java SCA Axis Binding Extension Affects Versions: Java-SCA-0.90 Reporter: ant elder Fix For: Java-SCA-0.99 Axis2 binding ?wsdl returns wsdl with wrong endpoint url when running in a webapp -- 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] Assigned: (TUSCANY-1277) Axis2 binding ?wsdl returns wsdl with wrong endpoint url when running in a webapp
[ https://issues.apache.org/jira/browse/TUSCANY-1277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ant elder reassigned TUSCANY-1277: -- Assignee: ant elder Axis2 binding ?wsdl returns wsdl with wrong endpoint url when running in a webapp - Key: TUSCANY-1277 URL: https://issues.apache.org/jira/browse/TUSCANY-1277 Project: Tuscany Issue Type: Bug Components: Java SCA Axis Binding Extension Affects Versions: Java-SCA-0.90 Reporter: ant elder Assignee: ant elder Fix For: Java-SCA-0.99 Axis2 binding ?wsdl returns wsdl with wrong endpoint url when running in a webapp -- 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] Closed: (TUSCANY-1277) Axis2 binding ?wsdl returns wsdl with wrong endpoint url when running in a webapp
[ https://issues.apache.org/jira/browse/TUSCANY-1277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ant elder closed TUSCANY-1277. -- Resolution: Fixed Should be fixed now Axis2 binding ?wsdl returns wsdl with wrong endpoint url when running in a webapp - Key: TUSCANY-1277 URL: https://issues.apache.org/jira/browse/TUSCANY-1277 Project: Tuscany Issue Type: Bug Components: Java SCA Axis Binding Extension Affects Versions: Java-SCA-0.90 Reporter: ant elder Assignee: ant elder Fix For: Java-SCA-0.99 Axis2 binding ?wsdl returns wsdl with wrong endpoint url when running in a webapp -- 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] Closed: (TUSCANY-1259) binding.ws / no longer works as the Axis2 binding requires a WSDL4J Definition object
[ https://issues.apache.org/jira/browse/TUSCANY-1259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ant elder closed TUSCANY-1259. -- Resolution: Fixed Fixed binding.ws / no longer works as the Axis2 binding requires a WSDL4J Definition object --- Key: TUSCANY-1259 URL: https://issues.apache.org/jira/browse/TUSCANY-1259 Project: Tuscany Issue Type: Bug Components: Java SCA Axis Binding Extension Affects Versions: Java-SCA-0.90 Reporter: ant elder Fix For: Java-SCA-Next binding.ws / no longer works as the Axis2 binding requires a WSDL4J Definition object but it doesn't look like there's anyway to get to one -- 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-1273) Axis2 binding doesn't work in webapps
Axis2 binding doesn't work in webapps - Key: TUSCANY-1273 URL: https://issues.apache.org/jira/browse/TUSCANY-1273 Project: Tuscany Issue Type: Bug Components: Java SCA Axis Binding Affects Versions: Java-SCA-0.90 Reporter: ant elder Assigned To: ant elder Fix For: Java-SCA-0.90 The axis2 binding doesn't work in webapps - the Axis2 servlet doesn't get its init method called by the tuscany webapp servlel - the Tuscany Axis2ServiceServlet expects it is the registered servlet so gets the path mapping wrong - the Tuscany listing agent calculates the path wrong so doesn't find the servlet - the Tuscany dispatcher calculates the path wrong so doesn't find the servlet -- 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-1273) Axis2 binding doesn't work in webapps
[ https://issues.apache.org/jira/browse/TUSCANY-1273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12495510 ] ant elder commented on TUSCANY-1273: - also ?wsdl has the wrong endpoint url as it leaves out the path of the Tuscany servlet Axis2 binding doesn't work in webapps - Key: TUSCANY-1273 URL: https://issues.apache.org/jira/browse/TUSCANY-1273 Project: Tuscany Issue Type: Bug Components: Java SCA Axis Binding Affects Versions: Java-SCA-0.90 Reporter: ant elder Assigned To: ant elder Fix For: Java-SCA-0.90 The axis2 binding doesn't work in webapps - the Axis2 servlet doesn't get its init method called by the tuscany webapp servlel - the Tuscany Axis2ServiceServlet expects it is the registered servlet so gets the path mapping wrong - the Tuscany listing agent calculates the path wrong so doesn't find the servlet - the Tuscany dispatcher calculates the path wrong so doesn't find the servlet -- 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-1273) Axis2 binding doesn't work in webapps
[ https://issues.apache.org/jira/browse/TUSCANY-1273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12495539 ] ant elder commented on TUSCANY-1273: Partially fixed now although ?wsdl is still not returning wsdl with the correct endpoint URL Axis2 binding doesn't work in webapps - Key: TUSCANY-1273 URL: https://issues.apache.org/jira/browse/TUSCANY-1273 Project: Tuscany Issue Type: Bug Components: Java SCA Axis Binding Affects Versions: Java-SCA-0.90 Reporter: ant elder Assigned To: ant elder Fix For: Java-SCA-0.90 The axis2 binding doesn't work in webapps - the Axis2 servlet doesn't get its init method called by the tuscany webapp servlel - the Tuscany Axis2ServiceServlet expects it is the registered servlet so gets the path mapping wrong - the Tuscany listing agent calculates the path wrong so doesn't find the servlet - the Tuscany dispatcher calculates the path wrong so doesn't find the servlet -- 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] Closed: (TUSCANY-1253) Update Axis2 binding for new SPIs
[ https://issues.apache.org/jira/browse/TUSCANY-1253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ant elder closed TUSCANY-1253. -- Resolution: Fixed Patch applied, thanks Simon! Update Axis2 binding for new SPIs - Key: TUSCANY-1253 URL: https://issues.apache.org/jira/browse/TUSCANY-1253 Project: Tuscany Issue Type: Bug Components: Java SCA Axis Binding Affects Versions: Java-SCA-0.90 Environment: Windows XP Reporter: Simon Nash Assigned To: ant elder Fix For: Java-SCA-0.90 Attachments: axis2binding.zip Update the Axis2 binding to the new SPIs in revision r536114. I have attached a complete zip file of the updated org.apache.tuscany.binding.axis2 package. The changes are so extensive that I don't think diffs would be useful. This code builds cleanly for me, but the tests don't run. They fail with a NullPointerEception on line 244 of Axis2ServiceBindingProvider. The call to wsBinding.getWSDLDefinition() is returning null, apparently because the call to WebServiceBindingProcessor.resolve() is not being made for this reference binding. AFAICT, this problem is independent of the changes I made. -- 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] Closed: (TUSCANY-1243) Update Axis2 binding for new runtime SPIs
[ https://issues.apache.org/jira/browse/TUSCANY-1243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ant elder closed TUSCANY-1243. -- Resolution: Fixed Done Update Axis2 binding for new runtime SPIs - Key: TUSCANY-1243 URL: https://issues.apache.org/jira/browse/TUSCANY-1243 Project: Tuscany Issue Type: Bug Affects Versions: Java-SCA-0.90 Reporter: ant elder Fix For: Java-SCA-0.90 Update Axis2 binding for new runtime SPIs -- 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-1277) Axis2 binding ?wsdl returns wsdl with wrong endpoint url when running in a webapp
Axis2 binding ?wsdl returns wsdl with wrong endpoint url when running in a webapp - Key: TUSCANY-1277 URL: https://issues.apache.org/jira/browse/TUSCANY-1277 Project: Tuscany Issue Type: Bug Affects Versions: Java-SCA-0.90 Reporter: ant elder Fix For: Java-SCA-0.90 Axis2 binding ?wsdl returns wsdl with wrong endpoint url when running in a webapp -- 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] Closed: (TUSCANY-1273) Axis2 binding doesn't work in webapps
[ https://issues.apache.org/jira/browse/TUSCANY-1273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ant elder closed TUSCANY-1273. -- Resolution: Fixed Most of these points are fixed now so I'll close this one and there's a seperate JIRA for the ?wsdl problem: https://issues.apache.org/jira/browse/TUSCANY-1277 Axis2 binding doesn't work in webapps - Key: TUSCANY-1273 URL: https://issues.apache.org/jira/browse/TUSCANY-1273 Project: Tuscany Issue Type: Bug Components: Java SCA Axis Binding Affects Versions: Java-SCA-0.90 Reporter: ant elder Assigned To: ant elder Fix For: Java-SCA-0.90 The axis2 binding doesn't work in webapps - the Axis2 servlet doesn't get its init method called by the tuscany webapp servlel - the Tuscany Axis2ServiceServlet expects it is the registered servlet so gets the path mapping wrong - the Tuscany listing agent calculates the path wrong so doesn't find the servlet - the Tuscany dispatcher calculates the path wrong so doesn't find the servlet -- 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-1259) binding.ws / no longer works as the Axis2 binding requires a WSDL4J Definition object
binding.ws / no longer works as the Axis2 binding requires a WSDL4J Definition object --- Key: TUSCANY-1259 URL: https://issues.apache.org/jira/browse/TUSCANY-1259 Project: Tuscany Issue Type: Bug Affects Versions: Java-SCA-0.90 Reporter: ant elder binding.ws / no longer works as the Axis2 binding requires a WSDL4J Definition object but it doesn't look like there's anyway to get to one -- 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]
Re: Questions from converting the Axis2 binding to new SPIs
A couple of comments inline... On 5/9/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: snip/ 5. The following line was in Axis2BindingBuilder before the SPI changes: TODO: if binding.ws specifies the wsdl service then should create a service for every port Is this remoider still needed? I just checked the WebService spec and couldn't find a statement confirming this behavior. I don't understand why we would create an (Axis2) service for every WSDL port... I could be reading mis-reading it, but line 39, section 2.1 page 2 of the WS binding spec, http://www.osoa.org/download/attachments/35/SCA_AssemblyModel_V100.pdf?version=1 : 39 WSDL-namespace-URI#wsdl.service(service-name) In this case, all the endpoints in the WSDL Service that have equivalent PortTypes with the SCA service or reference must be available to the SCA service or reference. 8. Should Http chunking be on or off? There's code to turn it off, but I've seen it tunred on when reading wire traces. In general I think it's better to have it on. Why would we turn it off? A lot of older (and not so old) SOAP stacks don't support it. There's also a few other things like this where we may want to customise the request it ways not defined by the WS binding spec. The WS binding schema is extensible so we could add these as extensions to binding.ws. Alternatively, for chunking we could do something like say chunking is always on for SOAP 1.2as that is newer so likely a stack that supports chunking, but off for SOAP 1.1, but thats not as flexible as extending the schema. ...ant
Axis2 binding status
I'm debugging the Axis2 binding to get the samples running so that we can put this back into the build. I'm making good progress (just tracked down and fixed one bug) and I'll continue to work on this today. Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Axis2 binding status
On 5/9/07, Simon Nash [EMAIL PROTECTED] wrote: I'm debugging the Axis2 binding to get the samples running so that we can put this back into the build. I'm making good progress (just tracked down and fixed one bug) and I'll continue to work on this today. Simon I've just committed some changes so a lot more of the tests are passing now, could you checkout the latest SVN code? ...ant
Re: Axis2 binding status
Should I be able to build what is in the trunk for this binding right now? I'm currently getting a compilation failure: D:\projects\Tuscany\trunk-java\sca\modules\binding-ws-axis2\src\main\java\org\apache\tuscany\binding\axis2\Axis2ServiceBindingProvider.java:[66,74] type org.apache.tuscany.provider.ServiceBindingProvider does not take parameters D:\projects\Tuscany\trunk-java\sca\modules\binding-ws-axis2\src\main\java\org\apache\tuscany\binding\axis2\Axis2BindingProviderFactory.java:[36,74] type org.apache.tuscany.provider.BindingProviderFactory does not take parameters D:\projects\Tuscany\trunk-java\sca\modules\binding-ws-axis2\src\main\java\org\apache\tuscany\binding\axis2\Axis2BindingProviderFactory.java:[44,35] type org.apache.tuscany.provider.ReferenceBindingProvider does not take parameters D:\projects\Tuscany\trunk-java\sca\modules\binding-ws-axis2\src\main\java\org\apache\tuscany\binding\axis2\Axis2BindingProviderFactory.java:[48,33] type org.apache.tuscany.provider.ServiceBindingProvider does not take parameters D:\projects\Tuscany\trunk-java\sca\modules\binding-ws-axis2\src\main\java\org\apache\tuscany\binding\axis2\Axis2ReferenceBindingProvider.java:[50,78] type org.apache.tuscany.provider.ReferenceBindingProvider does not take parameters D:\projects\Tuscany\trunk-java\sca\modules\binding-ws-axis2\src\main\java\org\apache\tuscany\binding\axis2\Axis2ModuleActivator.java:[39,35] cannot find symbol symbol : class ProviderFactoryExtensionPoint location: package org.apache.tuscany.provider D:\projects\Tuscany\trunk-java\sca\modules\binding-ws-axis2\src\main\java\org\apache\tuscany\binding\axis2\Axis2ModuleActivator.java:[56,8] cannot find symbol symbol : class ProviderFactoryExtensionPoint location: class org.apache.tuscany.binding.axis2.Axis2ModuleActivator D:\projects\Tuscany\trunk-java\sca\modules\binding-ws-axis2\src\main\java\org\ap ache\tuscany\binding\axis2\Axis2ModuleActivator.java:[56,85] cannot find symbol symbol : class ProviderFactoryExtensionPoint location: class org.apache.tuscany.binding.axis2.Axis2ModuleActivator -Bert On 5/9/07, ant elder [EMAIL PROTECTED] wrote: On 5/9/07, Simon Nash [EMAIL PROTECTED] wrote: I'm debugging the Axis2 binding to get the samples running so that we can put this back into the build. I'm making good progress (just tracked down and fixed one bug) and I'll continue to work on this today. Simon I've just committed some changes so a lot more of the tests are passing now, could you checkout the latest SVN code? ...ant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Axis2 binding status
It builds ok for me, all the modules and samples build ok, there are a few itest failures still. Those errors looks like it may be picking up some old version of one of the other modules. ...ant On 5/9/07, Bert Lamb [EMAIL PROTECTED] wrote: Should I be able to build what is in the trunk for this binding right now? I'm currently getting a compilation failure: D:\projects\Tuscany\trunk-java\sca\modules\binding-ws-axis2\src\main\java\org\apache\tuscany\binding\axis2\Axis2ServiceBindingProvider.java:[66,74] type org.apache.tuscany.provider.ServiceBindingProvider does not take parameters D:\projects\Tuscany\trunk-java\sca\modules\binding-ws-axis2\src\main\java\org\apache\tuscany\binding\axis2\Axis2BindingProviderFactory.java:[36,74] type org.apache.tuscany.provider.BindingProviderFactory does not take parameters D:\projects\Tuscany\trunk-java\sca\modules\binding-ws-axis2\src\main\java\org\apache\tuscany\binding\axis2\Axis2BindingProviderFactory.java:[44,35] type org.apache.tuscany.provider.ReferenceBindingProvider does not take parameters D:\projects\Tuscany\trunk-java\sca\modules\binding-ws-axis2\src\main\java\org\apache\tuscany\binding\axis2\Axis2BindingProviderFactory.java:[48,33] type org.apache.tuscany.provider.ServiceBindingProvider does not take parameters D:\projects\Tuscany\trunk-java\sca\modules\binding-ws-axis2\src\main\java\org\apache\tuscany\binding\axis2\Axis2ReferenceBindingProvider.java:[50,78] type org.apache.tuscany.provider.ReferenceBindingProvider does not take parameters D:\projects\Tuscany\trunk-java\sca\modules\binding-ws-axis2\src\main\java\org\apache\tuscany\binding\axis2\Axis2ModuleActivator.java:[39,35] cannot find symbol symbol : class ProviderFactoryExtensionPoint location: package org.apache.tuscany.provider D:\projects\Tuscany\trunk-java\sca\modules\binding-ws-axis2\src\main\java\org\apache\tuscany\binding\axis2\Axis2ModuleActivator.java:[56,8] cannot find symbol symbol : class ProviderFactoryExtensionPoint location: class org.apache.tuscany.binding.axis2.Axis2ModuleActivator D:\projects\Tuscany\trunk-java\sca\modules\binding-ws-axis2\src\main\java\org\ap ache\tuscany\binding\axis2\Axis2ModuleActivator.java:[56,85] cannot find symbol symbol : class ProviderFactoryExtensionPoint location: class org.apache.tuscany.binding.axis2.Axis2ModuleActivator -Bert On 5/9/07, ant elder [EMAIL PROTECTED] wrote: On 5/9/07, Simon Nash [EMAIL PROTECTED] wrote: I'm debugging the Axis2 binding to get the samples running so that we can put this back into the build. I'm making good progress (just tracked down and fixed one bug) and I'll continue to work on this today. Simon I've just committed some changes so a lot more of the tests are passing now, could you checkout the latest SVN code? ...ant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Axis2 binding status
I just tried and modules and samples build clean. As Ant mentions there are failures in itests. Maybe you should do a clean build. - Venkat On 5/9/07, ant elder [EMAIL PROTECTED] wrote: It builds ok for me, all the modules and samples build ok, there are a few itest failures still. Those errors looks like it may be picking up some old version of one of the other modules. ...ant On 5/9/07, Bert Lamb [EMAIL PROTECTED] wrote: Should I be able to build what is in the trunk for this binding right now? I'm currently getting a compilation failure: D:\projects\Tuscany\trunk-java\sca\modules\binding-ws-axis2\src\main\java\org\apache\tuscany\binding\axis2\Axis2ServiceBindingProvider.java:[66,74] type org.apache.tuscany.provider.ServiceBindingProvider does not take parameters D:\projects\Tuscany\trunk-java\sca\modules\binding-ws-axis2\src\main\java\org\apache\tuscany\binding\axis2\Axis2BindingProviderFactory.java:[36,74] type org.apache.tuscany.provider.BindingProviderFactory does not take parameters D:\projects\Tuscany\trunk-java\sca\modules\binding-ws-axis2\src\main\java\org\apache\tuscany\binding\axis2\Axis2BindingProviderFactory.java:[44,35] type org.apache.tuscany.provider.ReferenceBindingProvider does not take parameters D:\projects\Tuscany\trunk-java\sca\modules\binding-ws-axis2\src\main\java\org\apache\tuscany\binding\axis2\Axis2BindingProviderFactory.java:[48,33] type org.apache.tuscany.provider.ServiceBindingProvider does not take parameters D:\projects\Tuscany\trunk-java\sca\modules\binding-ws-axis2\src\main\java\org\apache\tuscany\binding\axis2\Axis2ReferenceBindingProvider.java:[50,78] type org.apache.tuscany.provider.ReferenceBindingProvider does not take parameters D:\projects\Tuscany\trunk-java\sca\modules\binding-ws-axis2\src\main\java\org\apache\tuscany\binding\axis2\Axis2ModuleActivator.java:[39,35] cannot find symbol symbol : class ProviderFactoryExtensionPoint location: package org.apache.tuscany.provider D:\projects\Tuscany\trunk-java\sca\modules\binding-ws-axis2\src\main\java\org\apache\tuscany\binding\axis2\Axis2ModuleActivator.java:[56,8] cannot find symbol symbol : class ProviderFactoryExtensionPoint location: class org.apache.tuscany.binding.axis2.Axis2ModuleActivator D:\projects\Tuscany\trunk-java\sca\modules\binding-ws-axis2\src\main\java\org\ap ache\tuscany\binding\axis2\Axis2ModuleActivator.java:[56,85] cannot find symbol symbol : class ProviderFactoryExtensionPoint location: class org.apache.tuscany.binding.axis2.Axis2ModuleActivator -Bert On 5/9/07, ant elder [EMAIL PROTECTED] wrote: On 5/9/07, Simon Nash [EMAIL PROTECTED] wrote: I'm debugging the Axis2 binding to get the samples running so that we can put this back into the build. I'm making good progress (just tracked down and fixed one bug) and I'll continue to work on this today. Simon I've just committed some changes so a lot more of the tests are passing now, could you checkout the latest SVN code? ...ant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Questions from converting the Axis2 binding to new SPIs
Comments inline. Simon Jean-Sebastien Delfino wrote: Simon, Comments and answers inline. Simon Nash wrote: Here are some questions and observations that I came across while converting the Axis2 binding to the new SPIs. 1. The binding.ws SCDL element is always resolved to Axis2. What should be the mechanism for making this pluggable for other binding.ws implementations liske CXF? Not any more, binding.ws is now resolved in a WebServiceBinding object, independent of Axis2. The BindingProvider that handles it registered by the Axis2ModuleActivator. If you wanted to use a different BindingProvider, you could either come up with a smarter ModuleActivator (which would select the desired one based on some criteria), or maybe simpler have two different ModuleActivators for CXF and Axis2 and pick the ModuleActivator you want. If you go with the option to have ModuleActivators declared in META-INF/services files on the classpath (which is not mandatory, it's just one way of doing this) then just place the one you want on the classpath. This activation-time selection works as long as we are happy to regard this as a big global switch that is always set one way or another in a Tuscany runtime. I'm not sure that we should completely rule out a mix and match scenario where the two stacks could both be active side by side with some services using one and some using the other. 2. Before the SPI changes, a composite reference or service was passed to the builder. The new SPIs pass component references and services. Is this change OK? Yes. CompositeReferences and CompositeServices are just promotion and configuration statements, they don't have an existence at runtime. OK. The new code is working OK and is clearer IMO. 3. Now that TargetInvoker has been replaced by Invoker, we have lost the optimization to avoid creating a Message object when there are no other interceptors in the chain. This seems a lot less efficient. A lot less efficient == how many microseconds and instructions? :) I think that we need to take a candid look at the actual use cases: - Java component to Java component - why would we even need to go through a TargetInvoker if the interceptor chain is empty? - X component to Y component - why would we need to go through a Java Proxy? if not, then why would we need to create an Object[] array?? (which is what TargetInvoker expected) So instead of having a TargetInvoker.invoke(Object[]) a priori in the general SPI, I'd like to look at the actual use cases, prototype a few other options, actually measure them and count these instructions :) and I think we can then do better than this generic TargetInvoker... I'd like to capture this in a JIRA for now. We can revisit it when we're not trying to get a release out. I agree that we need to look at real scenarios and decide what are the paths that need to be highly optimized. 4. The following line was in Axis2BindingBuilder before the SPI changes: URI targetURI = wsBinding.getURI() != null ? URI.create(wsBinding.getURI()) : URI.create(foo); targetURI was passed to the ReferenceBindingExtension constructor and apparently was unused. Is this code still needed? Probably not... OK. I commented it out and things seem to work OK. 5. The following line was in Axis2BindingBuilder before the SPI changes: TODO: if binding.ws specifies the wsdl service then should create a service for every port Is this remoider still needed? I just checked the WebService spec and couldn't find a statement confirming this behavior. I don't understand why we would create an (Axis2) service for every WSDL port... I'll defer to Ant's comments on this one. 6. WorkContextImpl is in an interface package. I think it should be in an impl package. Thanks. Good point. Raymond seems to have started to refactor that part. 7. DefaultCompositeActivator has typo in method name addBindingIntercepor. Thanks. Looks like it's fixed now. 8. Should Http chunking be on or off? There's code to turn it off, but I've seen it tunred on when reading wire traces. In general I think it's better to have it on. Why would we turn it off? I saw Ant's comment and I'd like to look into this a bit more. I don't think the code is currently consistent on this point. 9. Why was getCallbackUris() removed from the Message interface? We do not address the components by URI anymore, and we wouldn't need a list of URIs anyway as it should be possible to talk to any component in an assembly without having to know a list of URIs to get to it, as a component can give its service reference to somebody else, for callbacks or for any other regular call. OK. 10. I carried over a lot of code from Axis2ServiceBinding into Axis2ServiceBinding Provider. I'm not sure how it all gets invoked, specifically the createTargetInvoker() and invokeTarget
Re: Axis2 binding status
I made a bit more progress with this. The SDO data binding test was failing because of an error in the SCDL that showed up a bug in the model runtime (see TUSCANY-1255 and TUSCANY-1256). After correcting the SCDL, the test fails with a different error (see TUSCANY-1257). I'm leaving things there for today. Simon ant elder wrote: On 5/9/07, Simon Nash [EMAIL PROTECTED] wrote: I'm debugging the Axis2 binding to get the samples running so that we can put this back into the build. I'm making good progress (just tracked down and fixed one bug) and I'll continue to work on this today. Simon I've just committed some changes so a lot more of the tests are passing now, could you checkout the latest SVN code? ...ant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1253) Update Axis2 binding for new SPIs
Update Axis2 binding for new SPIs - Key: TUSCANY-1253 URL: https://issues.apache.org/jira/browse/TUSCANY-1253 Project: Tuscany Issue Type: Bug Components: Java SCA Axis Binding Affects Versions: Java-SCA-0.90 Environment: Windows XP Reporter: Simon Nash Assigned To: Simon Nash Fix For: Java-SCA-0.90 Update the Axis2 binding to the new SPIs in revision r536114. I have attached a complete zip file of the updated org.apache.tuscany.binding.axis2 package. The changes are so extensive that I don't think diffs would be useful. This code builds cleanly for me, but the tests don't run. They fail with a NullPointerEception on line 244 of Axis2ServiceBindingProvider. The call to wsBinding.getWSDLDefinition() is returning null, apparently because the call to WebServiceBindingProcessor.resolve() is not being made for this reference binding. AFAICT, this problem is independent of the changes I made. -- 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-1253) Update Axis2 binding for new SPIs
[ https://issues.apache.org/jira/browse/TUSCANY-1253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Nash updated TUSCANY-1253: Attachment: axis2binding.zip Complete replacement for all files in the org.apache.tuscany.binding.axis2 package. Update Axis2 binding for new SPIs - Key: TUSCANY-1253 URL: https://issues.apache.org/jira/browse/TUSCANY-1253 Project: Tuscany Issue Type: Bug Components: Java SCA Axis Binding Affects Versions: Java-SCA-0.90 Environment: Windows XP Reporter: Simon Nash Assigned To: Simon Nash Fix For: Java-SCA-0.90 Attachments: axis2binding.zip Update the Axis2 binding to the new SPIs in revision r536114. I have attached a complete zip file of the updated org.apache.tuscany.binding.axis2 package. The changes are so extensive that I don't think diffs would be useful. This code builds cleanly for me, but the tests don't run. They fail with a NullPointerEception on line 244 of Axis2ServiceBindingProvider. The call to wsBinding.getWSDLDefinition() is returning null, apparently because the call to WebServiceBindingProcessor.resolve() is not being made for this reference binding. AFAICT, this problem is independent of the changes I made. -- 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]
Axis2 binding (was Re: Status of Java SCA 0.90 release)
Simon Nash wrote: Simon Laws wrote: Hi, some comments in line There has been many commits and good progress the last few days, so I (cut) Main todo's that I could think of: - Port the Web Service binding extension to the latest code, as it's really important to have, and is also used by many integration tests. I remember seeing a mail from the other Simon saying that he has been working on this I have this ported over to the r535430 level of the code (but not yet upgraded to r536114). I have a few comments and questions based on this exercise, which I will post here later today. I'm now into debugging and I'll post progress and questions on this as I make progress. I created JIRA 1253 for this and attached a zip file containing the complete code for the updated Axis2 binding. This version of the code is using the SPIs in revision r536114. This code builds cleanly for me, but the tests don't run. They fail with a NullPointerEception on line 244 of Axis2ServiceBindingProvider. The call to wsBinding.getWSDLDefinition() is returning null, apparently because the call to WebServiceBindingProcessor.resolve() is not being made for this reference binding. AFAICT, this problem is independent of my changes. Any suggestions would be greatly appreciated. Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (TUSCANY-1253) Update Axis2 binding for new SPIs
[ https://issues.apache.org/jira/browse/TUSCANY-1253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ant elder reassigned TUSCANY-1253: -- Assignee: ant elder (was: Simon Nash) Update Axis2 binding for new SPIs - Key: TUSCANY-1253 URL: https://issues.apache.org/jira/browse/TUSCANY-1253 Project: Tuscany Issue Type: Bug Components: Java SCA Axis Binding Affects Versions: Java-SCA-0.90 Environment: Windows XP Reporter: Simon Nash Assigned To: ant elder Fix For: Java-SCA-0.90 Attachments: axis2binding.zip Update the Axis2 binding to the new SPIs in revision r536114. I have attached a complete zip file of the updated org.apache.tuscany.binding.axis2 package. The changes are so extensive that I don't think diffs would be useful. This code builds cleanly for me, but the tests don't run. They fail with a NullPointerEception on line 244 of Axis2ServiceBindingProvider. The call to wsBinding.getWSDLDefinition() is returning null, apparently because the call to WebServiceBindingProcessor.resolve() is not being made for this reference binding. AFAICT, this problem is independent of the changes I made. -- 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]
Re: Axis2 binding (was Re: Status of Java SCA 0.90 release)
On 5/8/07, Simon Nash [EMAIL PROTECTED] wrote: Simon Nash wrote: Simon Laws wrote: Hi, some comments in line There has been many commits and good progress the last few days, so I (cut) Main todo's that I could think of: - Port the Web Service binding extension to the latest code, as it's really important to have, and is also used by many integration tests. I remember seeing a mail from the other Simon saying that he has been working on this I have this ported over to the r535430 level of the code (but not yet upgraded to r536114). I have a few comments and questions based on this exercise, which I will post here later today. I'm now into debugging and I'll post progress and questions on this as I make progress. I created JIRA 1253 for this and attached a zip file containing the complete code for the updated Axis2 binding. This version of the code is using the SPIs in revision r536114. This code builds cleanly for me, but the tests don't run. They fail with a NullPointerEception on line 244 of Axis2ServiceBindingProvider. The call to wsBinding.getWSDLDefinition() is returning null, apparently because the call to WebServiceBindingProcessor.resolve() is not being made for this reference binding. AFAICT, this problem is independent of my changes. Any suggestions would be greatly appreciated. Thank you! I'll go have a look and get this in now... ...ant
Questions from converting the Axis2 binding to new SPIs
Here are some questions and observations that I came across while converting the Axis2 binding to the new SPIs. 1. The binding.ws SCDL element is always resolved to Axis2. What should be the mechanism for making this pluggable for other binding.ws implementations liske CXF? 2. Before the SPI changes, a composite reference or service was passed to the builder. The new SPIs pass component references and services. Is this change OK? 3. Now that TargetInvoker has been replaced by Invoker, we have lost the optimization to avoid creating a Message object when there are no other interceptors in the chain. This seems a lot less efficient. 4. The following line was in Axis2BindingBuilder before the SPI changes: URI targetURI = wsBinding.getURI() != null ? URI.create(wsBinding.getURI()) : URI.create(foo); targetURI was passed to the ReferenceBindingExtension constructor and apparently was unused. Is this code still needed? 5. The following line was in Axis2BindingBuilder before the SPI changes: TODO: if binding.ws specifies the wsdl service then should create a service for every port Is this remoider still needed? 6. WorkContextImpl is in an interface package. I think it should be in an impl package. 7. DefaultCompositeActivator has typo in method name addBindingIntercepor. 8. Should Http chunking be on or off? There's code to turn it off, but I've seen it tunred on when reading wire traces. 9. Why was getCallbackUris() removed from the Message interface? 10. I carried over a lot of code from Axis2ServiceBinding into Axis2ServiceBinding Provider. I'm not sure how it all gets invoked, specifically the createTargetInvoker() and invokeTarget() methods. 11. Why was the spi.wire.MessageId class removed? Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Questions from converting the Axis2 binding to new SPIs
Simon, Comments and answers inline. Simon Nash wrote: Here are some questions and observations that I came across while converting the Axis2 binding to the new SPIs. 1. The binding.ws SCDL element is always resolved to Axis2. What should be the mechanism for making this pluggable for other binding.ws implementations liske CXF? Not any more, binding.ws is now resolved in a WebServiceBinding object, independent of Axis2. The BindingProvider that handles it registered by the Axis2ModuleActivator. If you wanted to use a different BindingProvider, you could either come up with a smarter ModuleActivator (which would select the desired one based on some criteria), or maybe simpler have two different ModuleActivators for CXF and Axis2 and pick the ModuleActivator you want. If you go with the option to have ModuleActivators declared in META-INF/services files on the classpath (which is not mandatory, it's just one way of doing this) then just place the one you want on the classpath. 2. Before the SPI changes, a composite reference or service was passed to the builder. The new SPIs pass component references and services. Is this change OK? Yes. CompositeReferences and CompositeServices are just promotion and configuration statements, they don't have an existence at runtime. 3. Now that TargetInvoker has been replaced by Invoker, we have lost the optimization to avoid creating a Message object when there are no other interceptors in the chain. This seems a lot less efficient. A lot less efficient == how many microseconds and instructions? :) I think that we need to take a candid look at the actual use cases: - Java component to Java component - why would we even need to go through a TargetInvoker if the interceptor chain is empty? - X component to Y component - why would we need to go through a Java Proxy? if not, then why would we need to create an Object[] array?? (which is what TargetInvoker expected) So instead of having a TargetInvoker.invoke(Object[]) a priori in the general SPI, I'd like to look at the actual use cases, prototype a few other options, actually measure them and count these instructions :) and I think we can then do better than this generic TargetInvoker... 4. The following line was in Axis2BindingBuilder before the SPI changes: URI targetURI = wsBinding.getURI() != null ? URI.create(wsBinding.getURI()) : URI.create(foo); targetURI was passed to the ReferenceBindingExtension constructor and apparently was unused. Is this code still needed? Probably not... 5. The following line was in Axis2BindingBuilder before the SPI changes: TODO: if binding.ws specifies the wsdl service then should create a service for every port Is this remoider still needed? I just checked the WebService spec and couldn't find a statement confirming this behavior. I don't understand why we would create an (Axis2) service for every WSDL port... 6. WorkContextImpl is in an interface package. I think it should be in an impl package. Thanks. Good point. Raymond seems to have started to refactor that part. 7. DefaultCompositeActivator has typo in method name addBindingIntercepor. Thanks. Looks like it's fixed now. 8. Should Http chunking be on or off? There's code to turn it off, but I've seen it tunred on when reading wire traces. In general I think it's better to have it on. Why would we turn it off? 9. Why was getCallbackUris() removed from the Message interface? We do not address the components by URI anymore, and we wouldn't need a list of URIs anyway as it should be possible to talk to any component in an assembly without having to know a list of URIs to get to it, as a component can give its service reference to somebody else, for callbacks or for any other regular call. 10. I carried over a lot of code from Axis2ServiceBinding into Axis2ServiceBinding Provider. I'm not sure how it all gets invoked, specifically the createTargetInvoker() and invokeTarget() methods. 11. Why was the spi.wire.MessageId class removed? A lot of dead code was removed. Having the Axis2 binding out of the build for a while didn't really help track its dependencies... Do you need it in the Axis2 binding? If you do, and even if we put it back from the SVN history, IMHO it's broken and needs to be rewritten, as - if I remember correctly - it was just getting the current time in milliseconds to form a unique ID... not exactly the best way to form a unique ID I guess :) Simon -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1243) Update Axis2 binding for new runtime SPIs
Update Axis2 binding for new runtime SPIs - Key: TUSCANY-1243 URL: https://issues.apache.org/jira/browse/TUSCANY-1243 Project: Tuscany Issue Type: Bug Affects Versions: Java-SCA-0.90 Reporter: ant elder Fix For: Java-SCA-0.90 Update Axis2 binding for new runtime SPIs -- 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]
ScdlContributionProcessor and Axis2 binding getting the composite name?
I need the composite name to make the default endpoint URIs used with the Axis2 binding but it doesn't look like this name is available to the binding builder. The ComponentDefinition has a name which is available to the binding builders, and currently the ScdlContributionProcessor sets the ComponentDefinition name to the source URI of the contrabution, this is a name like sca://contribution/55b4aa6a-968c-4626-9ce0-40764b02eb11/WSBindingTest.composite. The actual composite name, eg WSBindingTest, is in the ComponentType which is available to the ScdlContributionProcessor but the ComponentType isn't available to things like the Binding builders. So I wondered if the ScdlContributionProcessor could set the ComponentDefinition name from the ComponentType instead of the source uri? ...ant
Re: ScdlContributionProcessor and Axis2 binding getting the composite name?
Yes, on closer reading that is right. Thanks! ...ant On 3/1/07, Jeremy Boynes [EMAIL PROTECTED] wrote: Isn't it based on the parent componentId and not the composite name? -- Jeremy On Mar 1, 2007, at 6:14 AM, ant elder wrote: I need the composite name to make the default endpoint URIs used with the Axis2 binding but it doesn't look like this name is available to the binding builder. The ComponentDefinition has a name which is available to the binding builders, and currently the ScdlContributionProcessor sets the ComponentDefinition name to the source URI of the contrabution, this is a name like sca://contribution/55b4aa6a-968c-4626-9ce0-40764b02eb11/ WSBindingTest.composite. The actual composite name, eg WSBindingTest, is in the ComponentType which is available to the ScdlContributionProcessor but the ComponentType isn't available to things like the Binding builders. So I wondered if the ScdlContributionProcessor could set the ComponentDefinition name from the ComponentType instead of the source uri? ...ant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ScdlContributionProcessor and Axis2 binding getting the composite name?
Could you please take a look and see if the fix I committed solves your issue ? On 3/1/07, ant elder [EMAIL PROTECTED] wrote: Yes, on closer reading that is right. Thanks! ...ant On 3/1/07, Jeremy Boynes [EMAIL PROTECTED] wrote: Isn't it based on the parent componentId and not the composite name? -- Jeremy On Mar 1, 2007, at 6:14 AM, ant elder wrote: I need the composite name to make the default endpoint URIs used with the Axis2 binding but it doesn't look like this name is available to the binding builder. The ComponentDefinition has a name which is available to the binding builders, and currently the ScdlContributionProcessor sets the ComponentDefinition name to the source URI of the contrabution, this is a name like sca://contribution/55b4aa6a-968c-4626-9ce0-40764b02eb11/ WSBindingTest.composite. The actual composite name, eg WSBindingTest, is in the ComponentType which is available to the ScdlContributionProcessor but the ComponentType isn't available to things like the Binding builders. So I wondered if the ScdlContributionProcessor could set the ComponentDefinition name from the ComponentType instead of the source uri? ...ant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende http://people.apache.org/~lresende
[jira] Resolved: (TUSCANY-1003) NPE thrown by AxisEngine.send in service side of axis2 binding for async callbacks
[ https://issues.apache.org/jira/browse/TUSCANY-1003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ignacio Silva-Lepe resolved TUSCANY-1003. - Resolution: Fixed Fix Version/s: (was: Java-SCA-Mx) Java-SCA-M3 Fixed in r499126 NPE thrown by AxisEngine.send in service side of axis2 binding for async callbacks -- Key: TUSCANY-1003 URL: https://issues.apache.org/jira/browse/TUSCANY-1003 Project: Tuscany Issue Type: Bug Components: Java SCA Axis Binding Affects Versions: Java-SCA-Mx Reporter: Ignacio Silva-Lepe Fix For: Java-SCA-M3 I'm seeing an NPE thrown by AxisEngine.send in the service side of the axis2 binding for async callbacks. The trace is below. My current guess is that this may have something to do with the pass-by-value interceptor but I have not delved to deeply into the possible cause. For now I am leaving this in the Java SCA Axis binding component but that may change depending on the actual reason for the exception. org.apache.tuscany.binding.axis2.Axis2BindingRunTimeException: java.lang.NullPoi nterException at org.apache.tuscany.binding.axis2.Axis2ServiceCallbackTargetInvoker.in vokeTarget(Axis2ServiceCallbackTargetInvoker.java:78) at org.apache.tuscany.binding.axis2.Axis2ServiceCallbackTargetInvoker.in voke(Axis2ServiceCallbackTargetInvoker.java:90) at org.apache.tuscany.core.wire.InvokerInterceptor.invoke(InvokerInterce ptor.java:44) at org.apache.tuscany.core.databinding.impl.PassByValueInterceptor.invok e(PassByValueInterceptor.java:65) at org.apache.tuscany.core.wire.SynchronousBridgingInterceptor.invoke(Sy nchronousBridgingInterceptor.java:41) at org.apache.tuscany.core.databinding.impl.DataBindingInteceptor.invoke (DataBindingInteceptor.java:70) at org.apache.tuscany.spi.wire.AbstractOutboundInvocationHandler.invoke( AbstractOutboundInvocationHandler.java:91) at org.apache.tuscany.core.wire.jdk.JDKCallbackInvocationHandler.invoke( JDKCallbackInvocationHandler.java:103) at $Proxy21.getGreetingsCallback(Unknown Source) at helloworld.HelloWorldImpl.getGreetings(HelloWorldImpl.java:43) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.tuscany.core.implementation.java.JavaTargetInvoker.invokeT arget(JavaTargetInvoker.java:90) at org.apache.tuscany.spi.extension.TargetInvokerExtension.invoke(Target InvokerExtension.java:67) at org.apache.tuscany.core.wire.InvokerInterceptor.invoke(InvokerInterce ptor.java:44) at org.apache.tuscany.core.databinding.impl.PassByValueInterceptor.invok e(PassByValueInterceptor.java:65) at org.apache.tuscany.core.wire.NonBlockingBridgingInterceptor$1.run(Non BlockingBridgingInterceptor.java:79) at org.apache.tuscany.core.services.work.jsr237.Jsr237WorkScheduler$Jsr2 37Work.run(Jsr237WorkScheduler.java:212) at org.apache.tuscany.core.services.work.jsr237.workmanager.ThreadPoolWo rkManager$DecoratingWork.run(ThreadPoolWorkManager.java:206) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExec utor.java:650) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor .java:675) at java.lang.Thread.run(Thread.java:595) Caused by: java.lang.NullPointerException at org.apache.coyote.http11.InternalOutputBuffer.realWriteBytes(Internal OutputBuffer.java:746) at org.apache.tomcat.util.buf.ByteChunk.flushBuffer(ByteChunk.java:433) at org.apache.coyote.http11.InternalOutputBuffer.flush(InternalOutputBuf fer.java:304) at org.apache.coyote.http11.Http11Processor.action(Http11Processor.java: 991) at org.apache.coyote.Response.action(Response.java:182) at org.apache.catalina.connector.OutputBuffer.doFlush(OutputBuffer.java: 322) at org.apache.catalina.connector.OutputBuffer.flush(OutputBuffer.java:29 3) at org.apache.catalina.connector.CoyoteOutputStream.flush(CoyoteOutputSt ream.java:97) at sun.nio.cs.StreamEncoder$CharsetSE.implFlush(StreamEncoder.java:410) at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:152) at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:213) at java.io.BufferedWriter.flush(BufferedWriter.java:236) at com.ctc.wstx.sw.BufferingXmlWriter.flush
[jira] Commented: (TUSCANY-1003) NPE thrown by AxisEngine.send in service side of axis2 binding for async callbacks
[ https://issues.apache.org/jira/browse/TUSCANY-1003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12465774 ] Ignacio Silva-Lepe commented on TUSCANY-1003: - Ok, I am past the ServiceRuntimeException, I was missing a @Service declaration. But now I am getting the following TransformationException: org.apache.tuscany.spi.databinding.TransformationException: java.lang.NullPointe rException at org.apache.tuscany.core.databinding.impl.Output2OutputTransformer.tra nsform(Output2OutputTransformer.java:197) at org.apache.tuscany.core.databinding.impl.MediatorImpl.mediate(Mediato rImpl.java:91) at org.apache.tuscany.core.databinding.impl.DataBindingInteceptor.transf orm(DataBindingInteceptor.java:106) at org.apache.tuscany.core.databinding.impl.DataBindingInteceptor.invoke (DataBindingInteceptor.java:92) at org.apache.tuscany.spi.wire.AbstractOutboundInvocationHandler.invoke( AbstractOutboundInvocationHandler.java:91) at org.apache.tuscany.core.wire.jdk.JDKOutboundInvocationHandler.invoke( JDKOutboundInvocationHandler.java:166) at $Proxy25.getGreetings(Unknown Source) at helloworld.HelloWorldServiceComponent.getGreetings(HelloWorldServiceC omponent.java:40) Caused by: java.lang.NullPointerException at org.apache.tuscany.databinding.axiom.OMElementWrapperHandler.getChild (OMElementWrapperHandler.java:50) at org.apache.tuscany.databinding.axiom.OMElementWrapperHandler.getChild (OMElementWrapperHandler.java:34) at org.apache.tuscany.core.databinding.impl.Output2OutputTransformer.tra nsform(Output2OutputTransformer.java:187) Any ideas? NPE thrown by AxisEngine.send in service side of axis2 binding for async callbacks -- Key: TUSCANY-1003 URL: https://issues.apache.org/jira/browse/TUSCANY-1003 Project: Tuscany Issue Type: Bug Components: Java SCA Axis Binding Affects Versions: Java-SCA-Mx Reporter: Ignacio Silva-Lepe Fix For: Java-SCA-Mx I'm seeing an NPE thrown by AxisEngine.send in the service side of the axis2 binding for async callbacks. The trace is below. My current guess is that this may have something to do with the pass-by-value interceptor but I have not delved to deeply into the possible cause. For now I am leaving this in the Java SCA Axis binding component but that may change depending on the actual reason for the exception. org.apache.tuscany.binding.axis2.Axis2BindingRunTimeException: java.lang.NullPoi nterException at org.apache.tuscany.binding.axis2.Axis2ServiceCallbackTargetInvoker.in vokeTarget(Axis2ServiceCallbackTargetInvoker.java:78) at org.apache.tuscany.binding.axis2.Axis2ServiceCallbackTargetInvoker.in voke(Axis2ServiceCallbackTargetInvoker.java:90) at org.apache.tuscany.core.wire.InvokerInterceptor.invoke(InvokerInterce ptor.java:44) at org.apache.tuscany.core.databinding.impl.PassByValueInterceptor.invok e(PassByValueInterceptor.java:65) at org.apache.tuscany.core.wire.SynchronousBridgingInterceptor.invoke(Sy nchronousBridgingInterceptor.java:41) at org.apache.tuscany.core.databinding.impl.DataBindingInteceptor.invoke (DataBindingInteceptor.java:70) at org.apache.tuscany.spi.wire.AbstractOutboundInvocationHandler.invoke( AbstractOutboundInvocationHandler.java:91) at org.apache.tuscany.core.wire.jdk.JDKCallbackInvocationHandler.invoke( JDKCallbackInvocationHandler.java:103) at $Proxy21.getGreetingsCallback(Unknown Source) at helloworld.HelloWorldImpl.getGreetings(HelloWorldImpl.java:43) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.tuscany.core.implementation.java.JavaTargetInvoker.invokeT arget(JavaTargetInvoker.java:90) at org.apache.tuscany.spi.extension.TargetInvokerExtension.invoke(Target InvokerExtension.java:67) at org.apache.tuscany.core.wire.InvokerInterceptor.invoke(InvokerInterce ptor.java:44) at org.apache.tuscany.core.databinding.impl.PassByValueInterceptor.invok e(PassByValueInterceptor.java:65) at org.apache.tuscany.core.wire.NonBlockingBridgingInterceptor$1.run(Non BlockingBridgingInterceptor.java:79) at org.apache.tuscany.core.services.work.jsr237.Jsr237WorkScheduler$Jsr2 37Work.run(Jsr237WorkScheduler.java:212) at org.apache.tuscany.core.services.work.jsr237.workmanager.ThreadPoolWo rkManager$DecoratingWork.run
[jira] Commented: (TUSCANY-1003) NPE thrown by AxisEngine.send in service side of axis2 binding for async callbacks
[ https://issues.apache.org/jira/browse/TUSCANY-1003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12465799 ] Venkatakrishnan commented on TUSCANY-1003: -- Hi Ignacio, I debugged this a bit and what I figure out is that in the Output2OutputTransformer the output wrapper is null and this causes the NPE in the Axiom databinding code. The method seems to be getGreetings and the tranformer is looking at the result which is null and creating a output wrapper for this which inturn also ends up as null. I guess Raymond will be able to throw better light on this while I continue to see if I can get better info about this. - Venkat NPE thrown by AxisEngine.send in service side of axis2 binding for async callbacks -- Key: TUSCANY-1003 URL: https://issues.apache.org/jira/browse/TUSCANY-1003 Project: Tuscany Issue Type: Bug Components: Java SCA Axis Binding Affects Versions: Java-SCA-Mx Reporter: Ignacio Silva-Lepe Fix For: Java-SCA-Mx I'm seeing an NPE thrown by AxisEngine.send in the service side of the axis2 binding for async callbacks. The trace is below. My current guess is that this may have something to do with the pass-by-value interceptor but I have not delved to deeply into the possible cause. For now I am leaving this in the Java SCA Axis binding component but that may change depending on the actual reason for the exception. org.apache.tuscany.binding.axis2.Axis2BindingRunTimeException: java.lang.NullPoi nterException at org.apache.tuscany.binding.axis2.Axis2ServiceCallbackTargetInvoker.in vokeTarget(Axis2ServiceCallbackTargetInvoker.java:78) at org.apache.tuscany.binding.axis2.Axis2ServiceCallbackTargetInvoker.in voke(Axis2ServiceCallbackTargetInvoker.java:90) at org.apache.tuscany.core.wire.InvokerInterceptor.invoke(InvokerInterce ptor.java:44) at org.apache.tuscany.core.databinding.impl.PassByValueInterceptor.invok e(PassByValueInterceptor.java:65) at org.apache.tuscany.core.wire.SynchronousBridgingInterceptor.invoke(Sy nchronousBridgingInterceptor.java:41) at org.apache.tuscany.core.databinding.impl.DataBindingInteceptor.invoke (DataBindingInteceptor.java:70) at org.apache.tuscany.spi.wire.AbstractOutboundInvocationHandler.invoke( AbstractOutboundInvocationHandler.java:91) at org.apache.tuscany.core.wire.jdk.JDKCallbackInvocationHandler.invoke( JDKCallbackInvocationHandler.java:103) at $Proxy21.getGreetingsCallback(Unknown Source) at helloworld.HelloWorldImpl.getGreetings(HelloWorldImpl.java:43) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.tuscany.core.implementation.java.JavaTargetInvoker.invokeT arget(JavaTargetInvoker.java:90) at org.apache.tuscany.spi.extension.TargetInvokerExtension.invoke(Target InvokerExtension.java:67) at org.apache.tuscany.core.wire.InvokerInterceptor.invoke(InvokerInterce ptor.java:44) at org.apache.tuscany.core.databinding.impl.PassByValueInterceptor.invok e(PassByValueInterceptor.java:65) at org.apache.tuscany.core.wire.NonBlockingBridgingInterceptor$1.run(Non BlockingBridgingInterceptor.java:79) at org.apache.tuscany.core.services.work.jsr237.Jsr237WorkScheduler$Jsr2 37Work.run(Jsr237WorkScheduler.java:212) at org.apache.tuscany.core.services.work.jsr237.workmanager.ThreadPoolWo rkManager$DecoratingWork.run(ThreadPoolWorkManager.java:206) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExec utor.java:650) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor .java:675) at java.lang.Thread.run(Thread.java:595) Caused by: java.lang.NullPointerException at org.apache.coyote.http11.InternalOutputBuffer.realWriteBytes(Internal OutputBuffer.java:746) at org.apache.tomcat.util.buf.ByteChunk.flushBuffer(ByteChunk.java:433) at org.apache.coyote.http11.InternalOutputBuffer.flush(InternalOutputBuf fer.java:304) at org.apache.coyote.http11.Http11Processor.action(Http11Processor.java: 991) at org.apache.coyote.Response.action(Response.java:182) at org.apache.catalina.connector.OutputBuffer.doFlush(OutputBuffer.java: 322) at org.apache.catalina.connector.OutputBuffer.flush(OutputBuffer.java:29 3) at org.apache.catalina.connector.CoyoteOutputStream.flush
[jira] Commented: (TUSCANY-1003) NPE thrown by AxisEngine.send in service side of axis2 binding for async callbacks
[ https://issues.apache.org/jira/browse/TUSCANY-1003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12465547 ] Ignacio Silva-Lepe commented on TUSCANY-1003: - I am not sure exactly how run.bat is put together, but I am not even able to get as far as you are, I get the following: C:\Devt\eclipse-311\eclipse\workspace\trunk\samples\sca\helloworldwsclient-async run java.io.FileNotFoundException: C:\Documents and Settings\Administrator\.m2\repos itory\org\apache\tuscany\standalone\1.0-SNAPSHOT\standalone-1.0-SNAPSHOT-bin.zip (The system cannot find the path specified) at java.io.FileInputStream.open(Native Method) at java.io.FileInputStream.init(FileInputStream.java:106) at java.io.FileInputStream.init(FileInputStream.java:66) at sun.tools.jar.Main.run(Main.java:184) at sun.tools.jar.Main.main(Main.java:903) The system cannot find the file specified. ... The system cannot find the file specified. Unable to access jarfile target\standalone\bin\launcher.jar Following Rick's advice, I have used o/a/t/sca/runtime/standalone/assembly to run standalone. Before that, I have just used junit and run the test in the build by adding a TestCase suffixed copy of the client class. But even that at the moment is giving me: Running helloworld.HelloWorldWSAsyncClientTestCase log4j:WARN No appenders could be found for logger (org.apache.axiom.om.util.StAX Utils). log4j:WARN Please initialize the log4j system properly. org.osoa.sca.ServiceRuntimeException: Service not found [null] at org.apache.tuscany.core.implementation.composite.AbstractCompositeCon text.getInboundWire(AbstractCompositeContext.java:85) at org.apache.tuscany.core.implementation.composite.AbstractCompositeCon text.locateService(AbstractCompositeContext.java:67) at helloworld.HelloWorldWSAsyncClientTestCase.setUp(HelloWorldWSAsyncCli entTestCase.java:25) at junit.framework.TestCase.runBare(TestCase.java:125) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.jav a:210) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTes tSet(AbstractDirectoryTestSuite.java:135) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(Ab stractDirectoryTestSuite.java:122) at org.apache.maven.surefire.Surefire.run(Surefire.java:129) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(Su refireBooter.java:288) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.j ava:816) Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 3.955 sec FA ILURE! I believe this is due to some of the refactoring that has been going on, but I have not actually investigated in detail to fix it, yet NPE thrown by AxisEngine.send in service side of axis2 binding for async callbacks -- Key: TUSCANY-1003 URL: https://issues.apache.org/jira/browse/TUSCANY-1003 Project: Tuscany Issue Type: Bug Components: Java SCA Axis Binding Affects Versions: Java-Mx Reporter: Ignacio Silva-Lepe Fix For: Java-Mx I'm seeing an NPE thrown by AxisEngine.send in the service side of the axis2 binding for async callbacks. The trace is below. My current guess is that this may have something to do with the pass-by-value interceptor but I have not delved to deeply into the possible cause. For now I am leaving this in the Java SCA Axis binding component but that may change depending on the actual reason for the exception. org.apache.tuscany.binding.axis2.Axis2BindingRunTimeException: java.lang.NullPoi nterException at org.apache.tuscany.binding.axis2.Axis2ServiceCallbackTargetInvoker.in vokeTarget
[jira] Commented: (TUSCANY-1003) NPE thrown by AxisEngine.send in service side of axis2 binding for async callbacks
[ https://issues.apache.org/jira/browse/TUSCANY-1003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12465375 ] Venkatakrishnan commented on TUSCANY-1003: -- Hi Ignacio, could you please provide some info on how to reproduce this. I deployed the helloworldws-async in tomcat and tried running the 'run.bat' in helloworldwsclient-async. But that seems to end with ... Exception in thread main java.io.FileNotFoundException: Unable to locate profi le directory: F:\TuscanyLatest\samples\sca\helloworldwsclient-async\target\stand alone\profiles\launcher at org.apache.tuscany.runtime.standalone.DirectoryHelper.getProfileDirec tory(DirectoryHelper.java:124) at org.apache.tuscany.launcher.Main.createRuntimeInfo(Main.java:104) at org.apache.tuscany.launcher.Main.main(Main.java:57) Thanks - Venkat NPE thrown by AxisEngine.send in service side of axis2 binding for async callbacks -- Key: TUSCANY-1003 URL: https://issues.apache.org/jira/browse/TUSCANY-1003 Project: Tuscany Issue Type: Bug Components: Java SCA Axis Binding Affects Versions: Java-Mx Reporter: Ignacio Silva-Lepe Fix For: Java-Mx I'm seeing an NPE thrown by AxisEngine.send in the service side of the axis2 binding for async callbacks. The trace is below. My current guess is that this may have something to do with the pass-by-value interceptor but I have not delved to deeply into the possible cause. For now I am leaving this in the Java SCA Axis binding component but that may change depending on the actual reason for the exception. org.apache.tuscany.binding.axis2.Axis2BindingRunTimeException: java.lang.NullPoi nterException at org.apache.tuscany.binding.axis2.Axis2ServiceCallbackTargetInvoker.in vokeTarget(Axis2ServiceCallbackTargetInvoker.java:78) at org.apache.tuscany.binding.axis2.Axis2ServiceCallbackTargetInvoker.in voke(Axis2ServiceCallbackTargetInvoker.java:90) at org.apache.tuscany.core.wire.InvokerInterceptor.invoke(InvokerInterce ptor.java:44) at org.apache.tuscany.core.databinding.impl.PassByValueInterceptor.invok e(PassByValueInterceptor.java:65) at org.apache.tuscany.core.wire.SynchronousBridgingInterceptor.invoke(Sy nchronousBridgingInterceptor.java:41) at org.apache.tuscany.core.databinding.impl.DataBindingInteceptor.invoke (DataBindingInteceptor.java:70) at org.apache.tuscany.spi.wire.AbstractOutboundInvocationHandler.invoke( AbstractOutboundInvocationHandler.java:91) at org.apache.tuscany.core.wire.jdk.JDKCallbackInvocationHandler.invoke( JDKCallbackInvocationHandler.java:103) at $Proxy21.getGreetingsCallback(Unknown Source) at helloworld.HelloWorldImpl.getGreetings(HelloWorldImpl.java:43) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.tuscany.core.implementation.java.JavaTargetInvoker.invokeT arget(JavaTargetInvoker.java:90) at org.apache.tuscany.spi.extension.TargetInvokerExtension.invoke(Target InvokerExtension.java:67) at org.apache.tuscany.core.wire.InvokerInterceptor.invoke(InvokerInterce ptor.java:44) at org.apache.tuscany.core.databinding.impl.PassByValueInterceptor.invok e(PassByValueInterceptor.java:65) at org.apache.tuscany.core.wire.NonBlockingBridgingInterceptor$1.run(Non BlockingBridgingInterceptor.java:79) at org.apache.tuscany.core.services.work.jsr237.Jsr237WorkScheduler$Jsr2 37Work.run(Jsr237WorkScheduler.java:212) at org.apache.tuscany.core.services.work.jsr237.workmanager.ThreadPoolWo rkManager$DecoratingWork.run(ThreadPoolWorkManager.java:206) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExec utor.java:650) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor .java:675) at java.lang.Thread.run(Thread.java:595) Caused by: java.lang.NullPointerException at org.apache.coyote.http11.InternalOutputBuffer.realWriteBytes(Internal OutputBuffer.java:746) at org.apache.tomcat.util.buf.ByteChunk.flushBuffer(ByteChunk.java:433) at org.apache.coyote.http11.InternalOutputBuffer.flush(InternalOutputBuf fer.java:304) at org.apache.coyote.http11.Http11Processor.action(Http11Processor.java: 991) at org.apache.coyote.Response.action(Response.java:182) at org.apache.catalina.connector.OutputBuffer.doFlush
[jira] Created: (TUSCANY-1003) NPE thrown by AxisEngine.send in service side of axis2 binding for async callbacks
NPE thrown by AxisEngine.send in service side of axis2 binding for async callbacks -- Key: TUSCANY-1003 URL: http://issues.apache.org/jira/browse/TUSCANY-1003 Project: Tuscany Issue Type: Bug Components: Java SCA Axis Binding Affects Versions: Java-Mx Reporter: Ignacio Silva-Lepe Fix For: Java-Mx I'm seeing an NPE thrown by AxisEngine.send in the service side of the axis2 binding for async callbacks. The trace is below. My current guess is that this may have something to do with the pass-by-value interceptor but I have not delved to deeply into the possible cause. For now I am leaving this in the Java SCA Axis binding component but that may change depending on the actual reason for the exception. org.apache.tuscany.binding.axis2.Axis2BindingRunTimeException: java.lang.NullPoi nterException at org.apache.tuscany.binding.axis2.Axis2ServiceCallbackTargetInvoker.in vokeTarget(Axis2ServiceCallbackTargetInvoker.java:78) at org.apache.tuscany.binding.axis2.Axis2ServiceCallbackTargetInvoker.in voke(Axis2ServiceCallbackTargetInvoker.java:90) at org.apache.tuscany.core.wire.InvokerInterceptor.invoke(InvokerInterce ptor.java:44) at org.apache.tuscany.core.databinding.impl.PassByValueInterceptor.invok e(PassByValueInterceptor.java:65) at org.apache.tuscany.core.wire.SynchronousBridgingInterceptor.invoke(Sy nchronousBridgingInterceptor.java:41) at org.apache.tuscany.core.databinding.impl.DataBindingInteceptor.invoke (DataBindingInteceptor.java:70) at org.apache.tuscany.spi.wire.AbstractOutboundInvocationHandler.invoke( AbstractOutboundInvocationHandler.java:91) at org.apache.tuscany.core.wire.jdk.JDKCallbackInvocationHandler.invoke( JDKCallbackInvocationHandler.java:103) at $Proxy21.getGreetingsCallback(Unknown Source) at helloworld.HelloWorldImpl.getGreetings(HelloWorldImpl.java:43) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.tuscany.core.implementation.java.JavaTargetInvoker.invokeT arget(JavaTargetInvoker.java:90) at org.apache.tuscany.spi.extension.TargetInvokerExtension.invoke(Target InvokerExtension.java:67) at org.apache.tuscany.core.wire.InvokerInterceptor.invoke(InvokerInterce ptor.java:44) at org.apache.tuscany.core.databinding.impl.PassByValueInterceptor.invok e(PassByValueInterceptor.java:65) at org.apache.tuscany.core.wire.NonBlockingBridgingInterceptor$1.run(Non BlockingBridgingInterceptor.java:79) at org.apache.tuscany.core.services.work.jsr237.Jsr237WorkScheduler$Jsr2 37Work.run(Jsr237WorkScheduler.java:212) at org.apache.tuscany.core.services.work.jsr237.workmanager.ThreadPoolWo rkManager$DecoratingWork.run(ThreadPoolWorkManager.java:206) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExec utor.java:650) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor .java:675) at java.lang.Thread.run(Thread.java:595) Caused by: java.lang.NullPointerException at org.apache.coyote.http11.InternalOutputBuffer.realWriteBytes(Internal OutputBuffer.java:746) at org.apache.tomcat.util.buf.ByteChunk.flushBuffer(ByteChunk.java:433) at org.apache.coyote.http11.InternalOutputBuffer.flush(InternalOutputBuf fer.java:304) at org.apache.coyote.http11.Http11Processor.action(Http11Processor.java: 991) at org.apache.coyote.Response.action(Response.java:182) at org.apache.catalina.connector.OutputBuffer.doFlush(OutputBuffer.java: 322) at org.apache.catalina.connector.OutputBuffer.flush(OutputBuffer.java:29 3) at org.apache.catalina.connector.CoyoteOutputStream.flush(CoyoteOutputSt ream.java:97) at sun.nio.cs.StreamEncoder$CharsetSE.implFlush(StreamEncoder.java:410) at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:152) at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:213) at java.io.BufferedWriter.flush(BufferedWriter.java:236) at com.ctc.wstx.sw.BufferingXmlWriter.flush(BufferingXmlWriter.java:184) at com.ctc.wstx.sw.BaseStreamWriter.flush(BaseStreamWriter.java:269) at org.apache.axiom.om.impl.MTOMXMLStreamWriter.flush(MTOMXMLStreamWrite r.java:119) at org.apache.axiom.om.impl.llom.OMNodeImpl.serializeAndConsume(OMNodeIm pl.java:412) at org.apache.axis2.transport.http.CommonsHTTPTransportSender.sendUsingO utputStream(CommonsHTTPTransportSender.java:275) at org.apache.axis2
Re: axis2 binding compile dependency on core
Comments inline. - Original Message - From: Raymond Feng [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Thursday, October 05, 2006 12:58 AM Subject: axis2 binding compile dependency on core Hi, Ignacio. I just found one of your patches added a compile dependency on core to binding.axis2. It's from Axis2CallbackInvocationHandler extends AbstractOutboundInvocationHandler. I don't think it's appropriate to have binding.axis2 depend on core. Can we fix it? Axis2CallbackInvocationHandler needs to extend AbstractOutboundInvocationHandler to perform most of its handling job. If a dependency on core is not allowed, then other options are: 1- Replicate the logic in binding.axis2 and remove the dependency. I don't think this is a good idea for maintenance reasons. 2- Promote AbstractOutboundInvocationHandler to the spi as an extension point. We had some discussions before to extract the invocation over interceptor chain into SPI. It seems to be the right way to go. I am not sure I understand what you mean, can you elaborate? Thanks, Raymond - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: axis2 binding compile dependency on core
Hi Jim, I had a quick conversation with Raymond about this. We basically agree that we need to promote the function performed by AbstractOutboundInvocationHandler to the spi as an extension point, which is also option 2 in my response to him. This is also what his statement means, ie, AbstractOutboundInvocationHandler is performing an invocation over an interceptor chain, to quote him, and his proposal is to extract that to the spi. Thoughts? - Original Message - From: Jim Marino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Thursday, October 05, 2006 1:01 AM Subject: Re: axis2 binding compile dependency on core On Oct 4, 2006, at 9:58 PM, Raymond Feng wrote: Hi, Ignacio. I just found one of your patches added a compile dependency on core to binding.axis2. It's from Axis2CallbackInvocationHandler extends AbstractOutboundInvocationHandler. I don't think it's appropriate to have binding.axis2 depend on core. Can we fix it? We had some discussions before to extract the invocation over interceptor chain into SPI. It seems to be the right way to go. Hi Raymond, could you explain what you mean by this? Thanks, Jim Thanks, Raymond - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: axis2 binding compile dependency on core
O.K. We'll need to move the testcases down to SPI as well then. Jim On Oct 5, 2006, at 10:31 AM, Ignacio Silva-Lepe wrote: Hi Jim, I had a quick conversation with Raymond about this. We basically agree that we need to promote the function performed by AbstractOutboundInvocationHandler to the spi as an extension point, which is also option 2 in my response to him. This is also what his statement means, ie, AbstractOutboundInvocationHandler is performing an invocation over an interceptor chain, to quote him, and his proposal is to extract that to the spi. Thoughts? - Original Message - From: Jim Marino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Thursday, October 05, 2006 1:01 AM Subject: Re: axis2 binding compile dependency on core On Oct 4, 2006, at 9:58 PM, Raymond Feng wrote: Hi, Ignacio. I just found one of your patches added a compile dependency on core to binding.axis2. It's from Axis2CallbackInvocationHandler extends AbstractOutboundInvocationHandler. I don't think it's appropriate to have binding.axis2 depend on core. Can we fix it? We had some discussions before to extract the invocation over interceptor chain into SPI. It seems to be the right way to go. Hi Raymond, could you explain what you mean by this? Thanks, Jim Thanks, Raymond - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: axis2 binding compile dependency on core
Hmm, not sure I follow. Btw, I'd like to clarify that when I say we basically agree I did not mean that as a forgone conclusion, apologies if I gave the impression that I was trying to go around the process. I was basically reporting our conversation on this topic (which happened to come up on a bug-related discussion). My intent with my reply was to put our, let's call it preliminary, agreement out for consideration. So what is the thought, would promoting the AbstractOutboundInvocationHandler function (not necessarily the class line by line) to the spi work? - Original Message - From: Jim Marino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Thursday, October 05, 2006 1:52 PM Subject: Re: axis2 binding compile dependency on core O.K. We'll need to move the testcases down to SPI as well then. Jim On Oct 5, 2006, at 10:31 AM, Ignacio Silva-Lepe wrote: Hi Jim, I had a quick conversation with Raymond about this. We basically agree that we need to promote the function performed by AbstractOutboundInvocationHandler to the spi as an extension point, which is also option 2 in my response to him. This is also what his statement means, ie, AbstractOutboundInvocationHandler is performing an invocation over an interceptor chain, to quote him, and his proposal is to extract that to the spi. Thoughts? - Original Message - From: Jim Marino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Thursday, October 05, 2006 1:01 AM Subject: Re: axis2 binding compile dependency on core On Oct 4, 2006, at 9:58 PM, Raymond Feng wrote: Hi, Ignacio. I just found one of your patches added a compile dependency on core to binding.axis2. It's fromAxis2CallbackInvocationHandler extends AbstractOutboundInvocationHandler. I don't think it's appropriate to have binding.axis2 depend on core. Can we fix it? We had some discussions before to extract the invocation over interceptor chain into SPI. It seems to be the right way to go. Hi Raymond, could you explain what you mean by this? Thanks, Jim Thanks, Raymond - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: axis2 binding compile dependency on core
Hi, I had a check on these two classes in core: AbstractInboundInvocationHandler.java AbstractOutboundInvocationHandler.java It seems to me that they are fit for the SPI to provide the logic we require. Thanks, Raymond - Original Message - From: Ignacio Silva-Lepe [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Thursday, October 05, 2006 11:10 AM Subject: Re: axis2 binding compile dependency on core Hmm, not sure I follow. Btw, I'd like to clarify that when I say we basically agree I did not mean that as a forgone conclusion, apologies if I gave the impression that I was trying to go around the process. I was basically reporting our conversation on this topic (which happened to come up on a bug-related discussion). My intent with my reply was to put our, let's call it preliminary, agreement out for consideration. So what is the thought, would promoting the AbstractOutboundInvocationHandler function (not necessarily the class line by line) to the spi work? - Original Message - From: Jim Marino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Thursday, October 05, 2006 1:52 PM Subject: Re: axis2 binding compile dependency on core O.K. We'll need to move the testcases down to SPI as well then. Jim On Oct 5, 2006, at 10:31 AM, Ignacio Silva-Lepe wrote: Hi Jim, I had a quick conversation with Raymond about this. We basically agree that we need to promote the function performed by AbstractOutboundInvocationHandler to the spi as an extension point, which is also option 2 in my response to him. This is also what his statement means, ie, AbstractOutboundInvocationHandler is performing an invocation over an interceptor chain, to quote him, and his proposal is to extract that to the spi. Thoughts? - Original Message - From: Jim Marino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Thursday, October 05, 2006 1:01 AM Subject: Re: axis2 binding compile dependency on core On Oct 4, 2006, at 9:58 PM, Raymond Feng wrote: Hi, Ignacio. I just found one of your patches added a compile dependency on core to binding.axis2. It's from Axis2CallbackInvocationHandler extends AbstractOutboundInvocationHandler. I don't think it's appropriate to have binding.axis2 depend on core. Can we fix it? We had some discussions before to extract the invocation over interceptor chain into SPI. It seems to be the right way to go. Hi Raymond, could you explain what you mean by this? Thanks, Jim Thanks, Raymond - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: axis2 binding compile dependency on core
On Oct 5, 2006, at 11:10 AM, Ignacio Silva-Lepe wrote: Hmm, not sure I follow. Btw, I'd like to clarify that when I say we basically agree I did not mean that as a forgone conclusion, apologies if I gave the impression that I was trying to go around the process. I was basically reporting our conversation on this topic (which happened to come up on a bug-related discussion). My intent with my reply was to put our, let's call it preliminary, agreement out for consideration. O.K. now I am really confused...I was agreeing that moving the class down would work (for now, we may want to revisit later as we refactor things at some point) and you should just go ahead and do it unless anyone objects. I was also just adding that if this is done, make sure to move the test cases as well. Jim So what is the thought, would promoting the AbstractOutboundInvocationHandler function (not necessarily the class line by line) to the spi work? - Original Message - From: Jim Marino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Thursday, October 05, 2006 1:52 PM Subject: Re: axis2 binding compile dependency on core O.K. We'll need to move the testcases down to SPI as well then. Jim On Oct 5, 2006, at 10:31 AM, Ignacio Silva-Lepe wrote: Hi Jim, I had a quick conversation with Raymond about this. We basically agree that we need to promote the function performed by AbstractOutboundInvocationHandler to the spi as an extension point, which is also option 2 in my response to him. This is also what his statement means, ie, AbstractOutboundInvocationHandler is performing an invocation over an interceptor chain, to quote him, and his proposal is to extract that to the spi. Thoughts? - Original Message - From: Jim Marino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Thursday, October 05, 2006 1:01 AM Subject: Re: axis2 binding compile dependency on core On Oct 4, 2006, at 9:58 PM, Raymond Feng wrote: Hi, Ignacio. I just found one of your patches added a compile dependency on core to binding.axis2. It's from Axis2CallbackInvocationHandler extends AbstractOutboundInvocationHandler. I don't think it's appropriate to have binding.axis2 depend on core. Can we fix it? We had some discussions before to extract the invocation over interceptor chain into SPI. It seems to be the right way to go. Hi Raymond, could you explain what you mean by this? Thanks, Jim Thanks, Raymond - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: axis2 binding compile dependency on core
Sorry, I think I misunderstood. You meant update the testcases to point to the new location for AbstractOutboundInvocationHandler right? Don't know why but move the testcases down to SPI sounded different to me at the time I read it. Apologies for the confusion. - Original Message - From: Jim Marino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Thursday, October 05, 2006 2:39 PM Subject: Re: axis2 binding compile dependency on core On Oct 5, 2006, at 11:10 AM, Ignacio Silva-Lepe wrote: Hmm, not sure I follow. Btw, I'd like to clarify that when I say we basically agree I did not mean that as a forgone conclusion, apologies if I gave the impression that I was trying to go around the process. I was basically reporting our conversation on this topic (which happened to come up on a bug-related discussion). My intent with my reply was to put our, let's call it preliminary, agreement out for consideration. O.K. now I am really confused...I was agreeing that moving the class down would work (for now, we may want to revisit later as we refactor things at some point) and you should just go ahead and do it unless anyone objects. I was also just adding that if this is done, make sure to move the test cases as well. Jim So what is the thought, would promoting the AbstractOutboundInvocationHandler function (not necessarily the class line by line) to the spi work? - Original Message - From: Jim Marino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Thursday, October 05, 2006 1:52 PM Subject: Re: axis2 binding compile dependency on core O.K. We'll need to move the testcases down to SPI as well then. Jim On Oct 5, 2006, at 10:31 AM, Ignacio Silva-Lepe wrote: Hi Jim, I had a quick conversation with Raymond about this. We basically agree that we need to promote the function performed by AbstractOutboundInvocationHandler to the spi as an extension point, which is also option 2 in my response to him. This is also what his statement means, ie, AbstractOutboundInvocationHandler is performing an invocation over an interceptor chain, to quote him, and his proposal is to extract that to the spi. Thoughts? - Original Message - From: Jim Marino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Thursday, October 05, 2006 1:01 AM Subject: Re: axis2 binding compile dependency on core On Oct 4, 2006, at 9:58 PM, Raymond Feng wrote: Hi, Ignacio. I just found one of your patches added a compile dependency on core to binding.axis2. It's from Axis2CallbackInvocationHandler extends AbstractOutboundInvocationHandler. I don't think it's appropriate to have binding.axis2 depend on core. Can we fix it? We had some discussions before to extract the invocation over interceptor chain into SPI. It seems to be the right way to go. Hi Raymond, could you explain what you mean by this? Thanks, Jim Thanks, Raymond - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: axis2 binding compile dependency on core
On Oct 5, 2006, at 11:58 AM, Ignacio Silva-Lepe wrote: Sorry, I think I misunderstood. You meant update the testcases to point to the new location for AbstractOutboundInvocationHandler right? No, the test cases should reside in the same module as the implementation, in this case SPI. Don't know why but move the testcases down to SPI sounded different to me at the time I read it. Apologies for the confusion. I may have not worded it clearly enough too. Jim - Original Message - From: Jim Marino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Thursday, October 05, 2006 2:39 PM Subject: Re: axis2 binding compile dependency on core On Oct 5, 2006, at 11:10 AM, Ignacio Silva-Lepe wrote: Hmm, not sure I follow. Btw, I'd like to clarify that when I say we basically agree I did not mean that as a forgone conclusion, apologies if I gave the impression that I was trying to go around the process. I was basically reporting our conversation on this topic (which happened to come up on a bug-related discussion). My intent with my reply was to put our, let's call it preliminary, agreement out for consideration. O.K. now I am really confused...I was agreeing that moving the class down would work (for now, we may want to revisit later as we refactor things at some point) and you should just go ahead and do it unless anyone objects. I was also just adding that if this is done, make sure to move the test cases as well. Jim So what is the thought, would promoting the AbstractOutboundInvocationHandler function (not necessarily the class line by line) to the spi work? - Original Message - From: Jim Marino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Thursday, October 05, 2006 1:52 PM Subject: Re: axis2 binding compile dependency on core O.K. We'll need to move the testcases down to SPI as well then. Jim On Oct 5, 2006, at 10:31 AM, Ignacio Silva-Lepe wrote: Hi Jim, I had a quick conversation with Raymond about this. We basically agree that we need to promote the function performed by AbstractOutboundInvocationHandler to the spi as an extension point, which is also option 2 in my response to him. This is also what his statement means, ie, AbstractOutboundInvocationHandler is performing an invocation over an interceptor chain, to quote him, and his proposal is to extract that to the spi. Thoughts? - Original Message - From: Jim Marino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Thursday, October 05, 2006 1:01 AM Subject: Re: axis2 binding compile dependency on core On Oct 4, 2006, at 9:58 PM, Raymond Feng wrote: Hi, Ignacio. I just found one of your patches added a compile dependency on core to binding.axis2. It's from Axis2CallbackInvocationHandler extends AbstractOutboundInvocationHandler. I don't think it's appropriate to have binding.axis2 depend on core. Can we fix it? We had some discussions before to extract the invocation over interceptor chain into SPI. It seems to be the right way to go. Hi Raymond, could you explain what you mean by this? Thanks, Jim Thanks, Raymond - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
axis2 binding compile dependency on core
Hi, Ignacio. I just found one of your patches added a compile dependency on core to binding.axis2. It's from Axis2CallbackInvocationHandler extends AbstractOutboundInvocationHandler. I don't think it's appropriate to have binding.axis2 depend on core. Can we fix it? We had some discussions before to extract the invocation over interceptor chain into SPI. It seems to be the right way to go. Thanks, Raymond - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: axis2 binding compile dependency on core
On Oct 4, 2006, at 9:58 PM, Raymond Feng wrote: Hi, Ignacio. I just found one of your patches added a compile dependency on core to binding.axis2. It's from Axis2CallbackInvocationHandler extends AbstractOutboundInvocationHandler. I don't think it's appropriate to have binding.axis2 depend on core. Can we fix it? We had some discussions before to extract the invocation over interceptor chain into SPI. It seems to be the right way to go. Hi Raymond, could you explain what you mean by this? Thanks, Jim Thanks, Raymond - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (TUSCANY-575) Port Axis2 binding to main trunk
[ http://issues.apache.org/jira/browse/TUSCANY-575?page=all ] ant elder closed TUSCANY-575. - Resolution: Fixed Applied Port Axis2 binding to main trunk Key: TUSCANY-575 URL: http://issues.apache.org/jira/browse/TUSCANY-575 Project: Tuscany Issue Type: New Feature Components: Java SCA Axis Binding Reporter: Jervis Liu Attachments: binding.axis2.rar, jira575.patch -- 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] Closed: (TUSCANY-295) Document the architecture of the WS Axis2 binding
[ http://issues.apache.org/jira/browse/TUSCANY-295?page=all ] ant elder closed TUSCANY-295. - Resolution: Fixed Document the architecture of the WS Axis2 binding - Key: TUSCANY-295 URL: http://issues.apache.org/jira/browse/TUSCANY-295 Project: Tuscany Issue Type: New Feature Components: Website Affects Versions: Java-M2 Reporter: Jean-Sebastien Delfino Assigned To: ant elder Fix For: Java-M2 This was identified as a work item for our release on our Wiki page at http://wiki.apache.org/ws/Tuscany/Tasks. We need this documentationon our web site. Ant has volunteered to do 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Axis2 Binding use of Inbound Wire?
Hi Jeremy, I am trying to get a sample up for the RMI Binding and I am also stuck with the inbound wire not being set (i.e. it is null). Could you please help me identify what I could be missing out here? Thanks. - Venkat On 7/31/06, Scott Kurz [EMAIL PROTECTED] wrote: I'm trying to understand where the Axis2Service of the new Axis2 binding is going to get its InboundWire from. Currently the only example I see is the Axis2ServiceTestCase mocking up this wire and setting it on the Axis2Service created by the testcase. The Jun 5 .ppt presentation says: The runtime provides components with InboundWires and OutboundWires In the simple case in which our binding was part of an AtomicComponent w/ Java implementation, shouldn't the ServiceExtension implemented by the Axis 2 binding be able to access the InboundWire created by JavaComponentBuilder.build() somehow? But if this were the case then I'd sort of expect to see the ServiceExtension base class doing this. Is this not implemented yet or is it there in some way I'm not recognizing? Thanks, Scott Kurz
Re: Axis2 Binding use of Inbound Wire?
Hi Jeremy, I looked up the SystemBindingBuilder.build method and gathered the way inbound and outbound wires are instantiated and initialized. I copied the same code over to the RMIBindingBuilder and created classed for InBoundWireImpl and OutBoundWireImpl as well. Is this the right way to go about this? If so I think there 'might' be some common code that can be factored out so that it applies to all bindings. Comments? Thanks - Venkat On 8/2/06, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi Jeremy, I am trying to get a sample up for the RMI Binding and I am also stuck with the inbound wire not being set (i.e. it is null). Could you please help me identify what I could be missing out here? Thanks. - Venkat On 7/31/06, Scott Kurz [EMAIL PROTECTED] wrote: I'm trying to understand where the Axis2Service of the new Axis2 binding is going to get its InboundWire from. Currently the only example I see is the Axis2ServiceTestCase mocking up this wire and setting it on the Axis2Service created by the testcase. The Jun 5 .ppt presentation says: The runtime provides components with InboundWires and OutboundWires In the simple case in which our binding was part of an AtomicComponent w/ Java implementation, shouldn't the ServiceExtension implemented by the Axis 2 binding be able to access the InboundWire created by JavaComponentBuilder.build() somehow? But if this were the case then I'd sort of expect to see the ServiceExtension base class doing this. Is this not implemented yet or is it there in some way I'm not recognizing? Thanks, Scott Kurz
Re: [jira] Updated: (TUSCANY-575) Port Axis2 binding to main trunk
I've committed Jervis' patch (thanks Jervis!) in 426629. I made some formatting changes to pass checkstyle and pmd and have the following comments: - Axis2Reference and Axis2Service take WebServiceBinding - can we not have it do that? We should decouple the model from the runtime artifacts and I noticed WebServiceBinding gets passed around a bit at the runtime layer when only a few configuration elements are needed. - Rename WebServiceEntryPointServlet and WebServiceEntryPointInOutSyncMessageReceiver to something like WebServiceReferenceServlet and WebServiceReferenceInOutSyncMessageReceiver respectively so they correspond to the new SCA naming scheme. - We should think about introducing monitoring in the axis servlets. Right now they throw ServletException but it would be good to have this picked up by Tuscany runtime monitoring as well - This has been mentioned but I thought I would add it to the list: WebServiceEntryPointInOutSyncMessageReceiver, Axis2TargetInvoker, Axis2Reference should take the data transformation service, not SDODataBinding - Should initServlet() and createAxisService(WebServiceBinding wsBinding) in Axis2Service be done by the builder? Related, maybe Axis2Service should not take ServletHost but instead have the builder perform the registration? We may be able to genericize Axis2Service if we do this. - We should think about handling async and callbacks - and probably should start a separate thread. Thanks again Jervis. Jim On Jul 26, 2006, at 9:07 PM, Jervis Liu (JIRA) wrote: [ http://issues.apache.org/jira/browse/TUSCANY-575?page=all ] Jervis Liu updated TUSCANY-575: --- Attachment: binding.axis2.rar As this is a new directory, you may find it handy if you just untar the attached rar and add it into svn sca/bindings directory. Port Axis2 binding to main trunk Key: TUSCANY-575 URL: http://issues.apache.org/jira/browse/TUSCANY-575 Project: Tuscany Issue Type: New Feature Components: Java SCA Axis Binding Reporter: Jervis Liu Attachments: binding.axis2.rar, jira575.patch -- 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Axis2 binding
Yes he does use BindingBuilderExtension. Thanks, Jeremy for explaining the registration then. On 7/26/06, Jeremy Boynes [EMAIL PROTECTED] wrote: On Jul 26, 2006, at 11:40 AM, Scott Kurz wrote: Jervis, There is also a bit of work to add your Axis2BindingBuilder to the BuilderRegistry, correct? Or maybe that's more of a host-specific question that isn't part of the binding proper. Whoever bootstraps the runtime would add your builder to the registry. I haven't had a chance to look at his patch yet but if the builder uses the extension class then that will handle registration for him. The binding would packaged as a composite and deployed into the runtime (for example, by placing it in an extension directory or by modifying the boot scdl to incorporate it (by include or by having it implement a component)) - when the composite starts, the builder extension has a eager-init method that will perform the registration. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-575) Port Axis2 binding to main trunk
Port Axis2 binding to main trunk Key: TUSCANY-575 URL: http://issues.apache.org/jira/browse/TUSCANY-575 Project: Tuscany Issue Type: New Feature Components: Java SCA Axis Binding Reporter: Jervis Liu -- 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]
Axis2 binding
Hi, An initial version of Axis2 binding can be found from JIRA575. Please review and apply. It is not completely working yet, still need some work on the following areas: 1. TuscanyAxisConfigurator In M1, we use org.apache.tuscany.common.resource.ResourceLoader to load Tuscany's Axis2.xml config file. At the moment, I just use the current classloader to load this file. Need to be revisited. 2. SDODataBinding is not working. I presume this class will be removed from Axis2 binding, as we do not want bindings depending on specific databindings. Related to this, several places that use TypeHelper and ResourceLoader have been commented out. 3.in Axis2BindingBuilder, Axis2Service needs an instance of ServletHost as parameter for its constructor. How to get it? Thanks, Jervis - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-295) Document the architecture of the WS Axis2 binding
[ http://issues.apache.org/jira/browse/TUSCANY-295?page=all ] Jean-Sebastien Delfino updated TUSCANY-295: --- Fix Version: Java-M2 (was: Java-M1-website) Version: Java-M2 (was: Java-M1-website) Document the architecture of the WS Axis2 binding - Key: TUSCANY-295 URL: http://issues.apache.org/jira/browse/TUSCANY-295 Project: Tuscany Type: New Feature Components: Website Versions: Java-M2 Reporter: Jean-Sebastien Delfino Assignee: ant elder Fix For: Java-M2 This was identified as a work item for our release on our Wiki page at http://wiki.apache.org/ws/Tuscany/Tasks. We need this documentationon our web site. Ant has volunteered to do 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Thread hangs in Axis2 binding code
The deadlock problem was due to the usuage of piped streams and it has been fixed for a while. Please try the M1 candidate. Thanks, Raymond - Original Message - From: Rashmi Hunt [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Monday, May 22, 2006 2:01 PM Subject: Thread hangs in Axis2 binding code I am trying to run slightly modified version of Account web service sample. The difference in the sample I am running is, input to the service is DataObject The snapshot of Tuscancy code I have corresponds to the tag java-stable-20060304. AxiomHelper.toDataObject((TypeHelper typeHelper, OMElement omElement) function hangs at omElement.serialize(pos). Problem seems to be the size of the DataObject in the SOAP Body. Thread dump WebContainer : 0 (TID:0x147EAD00, sys_thread_t:0x1442C034, state:CW, native ID:0x01D8) prio=5 at java/lang/Object.wait(Native Method) at java/lang/Object.wait(Object.java:231(Compiled Code)) at java/io/PipedInputStream.awaitSpace(PipedInputStream.java:226) at java/io/PipedInputStream.receive(PipedInputStream.java:183) at java/io/PipedOutputStream.write(PipedOutputStream.java:146) at sun/nio/cs/StreamEncoder$ConverterSE.implFlushBuffer( StreamEncoder.java:283(Compiled Code)) at sun/nio/cs/StreamEncoder$ConverterSE.implFlush(StreamEncoder.java :289) at sun/nio/cs/StreamEncoder.flush(StreamEncoder.java:200) at java/io/OutputStreamWriter.flush(OutputStreamWriter.java:236) at com/ctc/wstx/sw/BaseStreamWriter.flushStream(BaseStreamWriter.java :1351) at com/ctc/wstx/sw/BaseStreamWriter.safeFlushStream( BaseStreamWriter.java:1358) at com/ctc/wstx/sw/BaseStreamWriter.flush(BaseStreamWriter.java:309) at org/apache/axis2/om/impl/OMOutputImpl.flush(OMOutputImpl.java:78) at org/apache/axis2/om/impl/llom/OMNodeImpl.serialize(OMNodeImpl.java :298) at org/apache/axis2/om/impl/llom/OMNodeImpl.serialize(OMNodeImpl.java :338) at org/apache/tuscany/binding/axis2/util/AxiomHelper.toDataObject( AxiomHelper.java:146) Here is the WSDL wsdl:definitions xmlns:soap=http://schemas.xmlsoap.org/wsdl/soap/; xmlns:wsdl=http://schemas.xmlsoap.org/wsdl/; xmlns:tns=http://www.bigbank.com/Account/; xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns:account=http://www.bigbank.com/Account/; targetNamespace=http://www.bigbank.com/Account/; name=AccountService wsdl:types xsd:schema targetNamespace=http://www.bigbank.com/Account/; xmlns:account=http://www.bigbank.com/Account/; xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns:sdojava=commonj.sdo/java sdojava:package=org.apache.tuscany.samples.bigbank.account xsd:element name=invalidRequestFault xsd:complexType xsd:sequence xsd:element name=message type=xsd:string/ /xsd:sequence /xsd:complexType /xsd:element xsd:element name=getAccountReport xsd:complexType xsd:sequence xsd:element name=customerID type=account:AccountReport/ /xsd:sequence /xsd:complexType /xsd:element xsd:element name=getAccountReportResponse xsd:complexType xsd:sequence xsd:element name=accountReport type=account:AccountReport/ /xsd:sequence /xsd:complexType /xsd:element xsd:complexType name=AccountReport xsd:sequence xsd:element name=accountSummaries type=account:AccountSummary maxOccurs=unbounded/ /xsd:sequence /xsd:complexType xsd:complexType name=AccountSummary xsd:sequence xsd:element name=accountType type=xsd:string/ xsd:element name=accountNumber type=xsd:string/ xsd:element name=balance type=xsd:float/ /xsd:sequence /xsd:complexType /xsd:schema /wsdl:types wsdl:message name=getAccountReportRequest wsdl:part name=getAccountReportRequest element=account:getAccountReport/ /wsdl:message wsdl:message name=getAccountReportResponse wsdl:part name=getAccountReportResponse element=account:getAccountReportResponse/ /wsdl:message wsdl:message name=invalidRequestFaultMsg wsdl:part name=parameters element=tns:invalidRequestFault/ /wsdl:message wsdl:portType name=AccountService wsdl:operation name=getAccountReport wsdl:input message=tns:getAccountReportRequest/ wsdl:output message=tns:getAccountReportResponse/ wsdl:fault message=tns:invalidRequestFaultMsg name=InvalidRequestFault/ /wsdl:operation /wsdl:portType wsdl:binding name=AccountServiceSOAP type=tns:AccountService soap:binding style=document transport= http://schemas.xmlsoap.org/soap/http/ wsdl:operation name=getAccountReport soap:operation soapAction= http://www.bigbank.com/Account
[jira] Updated: (TUSCANY-295) Document the architecture of the WS Axis2 binding
[ http://issues.apache.org/jira/browse/TUSCANY-295?page=all ] Jean-Sebastien Delfino updated TUSCANY-295: --- Fix Version: Java-M1-website (was: Java-M1) Version: Java-M1-website (was: Java-M1) Document the architecture of the WS Axis2 binding - Key: TUSCANY-295 URL: http://issues.apache.org/jira/browse/TUSCANY-295 Project: Tuscany Type: New Feature Components: Website Versions: Java-M1-website Reporter: Jean-Sebastien Delfino Assignee: ant elder Fix For: Java-M1-website This was identified as a work item for our release on our Wiki page at http://wiki.apache.org/ws/Tuscany/Tasks. We need this documentationon our web site. Ant has volunteered to do 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] Resolved: (TUSCANY-307) tidy up Axis2 binding packages and move the non-axis2 related extension API classes to core project
[ http://issues.apache.org/jira/browse/TUSCANY-307?page=all ] ant elder resolved TUSCANY-307: --- Resolution: Fixed Done in Revision: 406055 tidy up Axis2 binding packages and move the non-axis2 related extension API classes to core project --- Key: TUSCANY-307 URL: http://issues.apache.org/jira/browse/TUSCANY-307 Project: Tuscany Type: Bug Components: Java SCA Axis Binding Versions: Java-M1 Reporter: ant elder Assignee: ant elder Fix For: Java-M1 -- 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] Assigned: (TUSCANY-295) Document the architecture of the WS Axis2 binding
[ http://issues.apache.org/jira/browse/TUSCANY-295?page=all ] Jean-Sebastien Delfino reassigned TUSCANY-295: -- Assign To: ant elder Document the architecture of the WS Axis2 binding - Key: TUSCANY-295 URL: http://issues.apache.org/jira/browse/TUSCANY-295 Project: Tuscany Type: New Feature Components: Website Versions: M1 Reporter: Jean-Sebastien Delfino Assignee: ant elder Fix For: M1 This was identified as a work item for our release on our Wiki page at http://wiki.apache.org/ws/Tuscany/Tasks. We need this documentationon our web site. Ant has volunteered to do 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] Created: (TUSCANY-307) tidy up Axis2 binding packages and move the non-axis2 related extension API classes to core project
tidy up Axis2 binding packages and move the non-axis2 related extension API classes to core project --- Key: TUSCANY-307 URL: http://issues.apache.org/jira/browse/TUSCANY-307 Project: Tuscany Type: Bug Components: Java SCA Axis Binding Reporter: ant elder Assigned to: ant elder Fix For: M1 -- 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-307) tidy up Axis2 binding packages and move the non-axis2 related extension API classes to core project
[ http://issues.apache.org/jira/browse/TUSCANY-307?page=all ] Jean-Sebastien Delfino updated TUSCANY-307: --- Version: M1 tidy up Axis2 binding packages and move the non-axis2 related extension API classes to core project --- Key: TUSCANY-307 URL: http://issues.apache.org/jira/browse/TUSCANY-307 Project: Tuscany Type: Bug Components: Java SCA Axis Binding Versions: M1 Reporter: ant elder Assignee: ant elder Fix For: M1 -- 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] Resolved: (TUSCANY-266) Upgrade Axis2 binding to Axis2 RC4
[ http://issues.apache.org/jira/browse/TUSCANY-266?page=all ] ant elder resolved TUSCANY-266: --- Resolution: Fixed done Upgrade Axis2 binding to Axis2 RC4 -- Key: TUSCANY-266 URL: http://issues.apache.org/jira/browse/TUSCANY-266 Project: Tuscany Type: Improvement Components: Java SCA Axis Binding Versions: 0.91 Reporter: ant elder Assignee: ant elder Fix For: 0.91 Move up to the RC4 release of Axis2 -- 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] Closed: (TUSCANY-266) Upgrade Axis2 binding to Axis2 RC4
[ http://issues.apache.org/jira/browse/TUSCANY-266?page=all ] ant elder closed TUSCANY-266: - Upgrade Axis2 binding to Axis2 RC4 -- Key: TUSCANY-266 URL: http://issues.apache.org/jira/browse/TUSCANY-266 Project: Tuscany Type: Improvement Components: Java SCA Axis Binding Versions: 0.91 Reporter: ant elder Assignee: ant elder Fix For: 0.91 Move up to the RC4 release of Axis2 -- 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] Created: (TUSCANY-295) Document the architecture of the WS Axis2 binding
Document the architecture of the WS Axis2 binding - Key: TUSCANY-295 URL: http://issues.apache.org/jira/browse/TUSCANY-295 Project: Tuscany Type: New Feature Components: Website Versions: 0.91 Reporter: Jean-Sebastien Delfino This was identified as a work item for our release on our Wiki page at http://wiki.apache.org/ws/Tuscany/Tasks. We need this documentationon our web site. Ant has volunteered to do 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-295) Document the architecture of the WS Axis2 binding
[ http://issues.apache.org/jira/browse/TUSCANY-295?page=all ] Jean-Sebastien Delfino updated TUSCANY-295: --- Fix Version: M1 Document the architecture of the WS Axis2 binding - Key: TUSCANY-295 URL: http://issues.apache.org/jira/browse/TUSCANY-295 Project: Tuscany Type: New Feature Components: Website Versions: M1 Reporter: Jean-Sebastien Delfino Fix For: M1 This was identified as a work item for our release on our Wiki page at http://wiki.apache.org/ws/Tuscany/Tasks. We need this documentationon our web site. Ant has volunteered to do 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] Closed: (TUSCANY-227) Upgrade Axis2 binding to use Axis2 RC2
[ http://issues.apache.org/jira/browse/TUSCANY-227?page=all ] ant elder closed TUSCANY-227: - Upgrade Axis2 binding to use Axis2 RC2 -- Key: TUSCANY-227 URL: http://issues.apache.org/jira/browse/TUSCANY-227 Project: Tuscany Type: Improvement Components: Java SCA Axis Binding Reporter: ant elder Assignee: ant elder Priority: Critical Axis2 has just cut an RC2 release, and the 1.0 final release is imminent. We should move up to RC2 to make sure Tuscany still works so then hopefully should also be good with the 1.0 final release. -- 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] Assigned: (TUSCANY-227) Upgrade Axis2 binding to use Axis2 RC2
[ http://issues.apache.org/jira/browse/TUSCANY-227?page=all ] ant elder reassigned TUSCANY-227: - Assign To: ant elder Upgrade Axis2 binding to use Axis2 RC2 -- Key: TUSCANY-227 URL: http://issues.apache.org/jira/browse/TUSCANY-227 Project: Tuscany Type: Improvement Components: Java SCA Axis Binding Reporter: ant elder Assignee: ant elder Priority: Critical Axis2 has just cut an RC2 release, and the 1.0 final release is imminent. We should move up to RC2 to make sure Tuscany still works so then hopefully should also be good with the 1.0 final release. -- 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] Created: (TUSCANY-227) Upgrade Axis2 binding to use Axis2 RC2
Upgrade Axis2 binding to use Axis2 RC2 -- Key: TUSCANY-227 URL: http://issues.apache.org/jira/browse/TUSCANY-227 Project: Tuscany Type: Improvement Components: Java SCA Axis Binding Reporter: ant elder Priority: Critical Axis2 has just cut an RC2 release, and the 1.0 final release is imminent. We should move up to RC2 to make sure Tuscany still works so then hopefully should also be good with the 1.0 final release. -- 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
Re: Using SDO JavaGenerator for the new Axis2 binding?
Frank Budinsky wrote: Hi ant, It looks to me like the generator may be failing because this imported schema is not available (is failing to resolve): import schemaLocation=sca-core.xsd namespace=http://www.osoa.org/xmlns/sca/0.9/ (I agree that the error checking/messages need improvement.) Is sca-core.xsd available in your environment? Actually, a more general question is has sca-core.xsd been moved to (generated with) SDO 2 yet? If not, this won't work yet anyway. Frank. ant elder [EMAIL PROTECTED] wrote on 02/15/2006 08:14:46 AM: Should I be able to use the Tuscany SDO JavaGenerator to gen all the SDO stuff for the new Axis2 based WS binding? Running it with the following args gets a NPE: -targetDirectory \temp\sdoGen C:\SCA\SCA6\sca\binding.axis\src\main\resources\model\sca- binding-webservice.xsd Exception in thread main java.lang.NullPointerException at org.eclipse.emf.codegen.ecore.genmodel.impl.GenPackageImpl$DependencyHelper .init(GenPackageImpl.java:1859) at org.eclipse.emf.codegen.ecore.genmodel.impl.GenPackageImpl.generate( GenPackageImpl.java:2385) at org.eclipse.emf.codegen.ecore.genmodel.impl.GenModelImpl.generate( GenModelImpl.java:1932) at org.eclipse.emf.codegen.ecore.genmodel.impl.GenBaseImpl.gen( GenBaseImpl.java:355) at org.apache.tuscany.sdo.generate.JavaGenerator.generateFromGenModel( JavaGenerator.java:293) at org.apache.tuscany.sdo.generate.JavaGenerator.generateFromEPackage( JavaGenerator.java:278) at org.apache.tuscany.sdo.generate.JavaGenerator.generateFromXMLSchema( JavaGenerator.java:255) at org.apache.tuscany.sdo.generate.JavaGenerator.main(JavaGenerator.java :222) ...ant Ant, The core assembly model has not moved to SDO2 yet, I'm in the process of changing the assembly models to be a combination of SDO2 models (for XML deserialization) and pure POJO models (logical models used to configure the runtime), building on the approach introduced by Jim in o.a.t.model.assembly.pojo. This is quite a bit of work but I should be ready to commit this new set of models later this week. I'm taking care of the core assembly model, the java container model and the web service assembly model (I want to handle these two at least to flesh out any model extensibility issues raised by component types and binding types). I'll let others port their own models (e.g. the container.js model) later. In the meantime you can continue to use the existing o.a.t.binding.axis.assembly model, which is an SDO1 model. If you want to create another binding model you'll have to generate an SDO1 model like I think you did for the container.js component implementation type model, but I'm not even sure you need to do this here... With the axis2 integration we're not introducing a new web service binding model, we're just porting our implementation of the existing web service binding to Axis 2, so I'm not sure why you would need to regenerate a new binding model, is there anything missing in o.a.t.binding.axis.assembly.model? are you introducing any changes to the definition of the web service binding and the corresponding XSD? -- Jean-Sebastien
