[jira] Created: (AXIS2-4475) java2wsdl -tp option does not work!

2009-08-25 Thread Andrew Qu (JIRA)
java2wsdl -tp option does not work!
---

 Key: AXIS2-4475
 URL: https://issues.apache.org/jira/browse/AXIS2-4475
 Project: Axis 2.0 (Axis2)
  Issue Type: Bug
  Components: Tools
 Environment: Using AXIS2_HOME:   C:\Tools\axis2-1.5
Using JAVA_HOME:C:\Tools\Java\jdk1.5.0_19
Reporter: Andrew Qu


Use tn and tp options to set special targetnamespace and targetnamespaceprefix. 
tn option works but tp option does not. The targetnamespaceprefix is still 
"axis2".
The targetnamespaceprefix is stored at variable targetNamespacePrefix of object 
axisService, but generateOM method of class AxisService2WSDL11 want to check 
variable namespaceMap of of object axisService.


Java2WSDLBuilder.generateWSDL() 
  axisService.setTargetNamespacePrefix(getTargetNamespacePrefix());

AxisService2WSDL11.generateOM()
  Map namespaceMap = axisService.getNamespaceMap();
  if (namespaceMap == null)
namespaceMap = new HashMap();
  
  String prefix = 
WSDLSerializationUtil.getPrefix(axisService.getTargetNamespace(),
  namespaceMap);
  if (prefix == null || "".equals(prefix)) {
prefix = DEFAULT_TARGET_NAMESPACE_PREFIX;
  }

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



Re: Please revert API changes done as per AXIS2-4465

2009-08-25 Thread Amila Suriarachchi
On Tue, Aug 25, 2009 at 5:45 PM, Davanum Srinivas  wrote:

> Amila,
>
> you said:
>
> "You have not put any comment in my suggestion to  resolve the issue
> keeping
> your change and with out breaking carbon. We will test it and commit if you
> don't have any suggestions to fix this issue."
>
> Do you have proposed patch on how to fix this break?


yes. Please see my first mail on Monday.
This does not change any functionality but do it in a slightly different
way.

here is the commit[1].

thanks,
Amila.

[1] http://svn.apache.org/viewvc?view=rev&revision=807512

>
>
> thanks,
> dims
>
>
> On 08/25/2009 01:02 AM, Amila Suriarachchi wrote:
>
>> You have not put any comment in my suggestion to  resolve the issue
>> keeping
>> your change and with out breaking carbon. We will test it and commit if
>> you
>> don't have any suggestions to fix this issue.
>>
>


-- 
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/


[jira] Resolved: (AXIS2-4474) JAXWS Provider does not respect FaultTo when a SOAPFault is returned

2009-08-25 Thread Rich Scheuerle (JIRA)

 [ 
https://issues.apache.org/jira/browse/AXIS2-4474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rich Scheuerle resolved AXIS2-4474.
---

Resolution: Fixed

> JAXWS Provider does not respect FaultTo when a SOAPFault is returned
> 
>
> Key: AXIS2-4474
> URL: https://issues.apache.org/jira/browse/AXIS2-4474
> Project: Axis 2.0 (Axis2)
>  Issue Type: Bug
>  Components: jaxws
>Reporter: Rich Scheuerle
>Assignee: Rich Scheuerle
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> If a JAXWS web service implementation or Provider throws and exception, the 
> jaxws engine creates an appropriate SOAP Fault.  The SOAP Fault is returned 
> to the caller or sent to the FaultTo address.
> However a JAXWS mode=Message Provider may return an object representing a 
> SOAP Fault (i.e. no exception is thrown).  In such cases, the JAX-WS is 
> failing to recognize the SOAP Fault and the the subsequent Faul is returned 
> to the caller (instead of being directed to a FaultTo address).
> The error is in the ProviderDispatcher.  A small code change is needed to 
> analyze the returned object and create a "Fault" message context if necessary.
> I am testing this small change and will have it done later today.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (AXIS-2574) Reading an attachment (slowly) can cause resource deleted error

2009-08-25 Thread Rune Slinning (JIRA)

[ 
https://issues.apache.org/jira/browse/AXIS-2574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12747676#action_12747676
 ] 

Rune Slinning commented on AXIS-2574:
-

I am using Axis 1.4 and my project is halted due to this issue.

I'm new to patching. Does anyone have a binary axis.jar (1_4) where this patch 
is incorporated, or could anyone tell me how I can path it myself.

Please help me out.


> Reading an attachment (slowly) can cause resource deleted error
> ---
>
> Key: AXIS-2574
> URL: https://issues.apache.org/jira/browse/AXIS-2574
> Project: Axis
>  Issue Type: Bug
>  Components: Basic Architecture
>Affects Versions: 1.2.1
>Reporter: Steve Sowerby
>Assignee: Jochen Wiedmann
> Attachments: axis-2574.patch, Call.diff, Call.diff, Call.java
>
>
> When reading the data from an attachment we periodically get the following 
> error:
> java.io.IOException: Resource has been deleted.
>  at 
> org.apache.axis.attachments.ManagedMemoryDataSource$Instream.read(ManagedMemoryDataSource.java:688)
> Having run this throught a debugger and had a brief look at the code it seems 
> to me there is a race condition of sorts.
> The MemoryManagedDataSource that provides the InputStream has been marked as 
> deleted by the finalize method of AttachmentPart.
> So basically if the client doesn't read off the attachment fast enough then 
> the writer will have finished and the AttachmentPart gets finalized and blam, 
> you've got a deleted MemoryManagedDataSource.
> I'm not sure what the best fix is.  Perhaps the deletion should actually be 
> some reference count rather than a simple boolean.  That way the 
> MemoryManagedDataSource gets deleted once all the writers and readers are 
> done?  Although perhaps then there would be an issue if the client was very 
> slow to even open the attachment?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Created: (AXIS2-4474) JAXWS Provider does not respect FaultTo when a SOAPFault is returned

2009-08-25 Thread Rich Scheuerle (JIRA)
JAXWS Provider does not respect FaultTo when a SOAPFault is returned


 Key: AXIS2-4474
 URL: https://issues.apache.org/jira/browse/AXIS2-4474
 Project: Axis 2.0 (Axis2)
  Issue Type: Bug
  Components: jaxws
Reporter: Rich Scheuerle
Assignee: Rich Scheuerle


If a JAXWS web service implementation or Provider throws and exception, the 
jaxws engine creates an appropriate SOAP Fault.  The SOAP Fault is returned to 
the caller or sent to the FaultTo address.

However a JAXWS mode=Message Provider may return an object representing a SOAP 
Fault (i.e. no exception is thrown).  In such cases, the JAX-WS is failing to 
recognize the SOAP Fault and the the subsequent Faul is returned to the caller 
(instead of being directed to a FaultTo address).

The error is in the ProviderDispatcher.  A small code change is needed to 
analyze the returned object and create a "Fault" message context if necessary.

I am testing this small change and will have it done later today.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Created: (AXIS2-4473) NameSpaces prefix problem when using inherit complex type

2009-08-25 Thread Guillaume ETTORI (JIRA)
NameSpaces prefix problem when using inherit complex type
-

 Key: AXIS2-4473
 URL: https://issues.apache.org/jira/browse/AXIS2-4473
 Project: Axis 2.0 (Axis2)
  Issue Type: Bug
  Components: adb
Affects Versions: 1.4.1
 Environment: Windows 2003, Server, Weblogic 9.2, Apache ActiveMQ
Reporter: Guillaume ETTORI


Let say you have a service that returns a B class object.

B class object from com.b package EXTENDS 
A class object from com.a package

A has a field_A and B has a field_B.

The problem is i get something like this in my SOAP Message:

http://a.com/xsd"; 
xmlns:ax21="http://b.com/xsd"; type="com.b.B">
IT_IS_OK
test


As you can see, the prefix for field_A is AX21 instead of AX22.

So the problem is i got a ADBException (unexpected element field_A) when i 
called this service with the Stub (generated by wdsl2java).
In the Stub.B.Factory.parse method, i see something like this:

if (reader.isStartElement()&& new 
javax.xml.namespace.QName(

"http://a.com/xsd";,

"field_A").equals(reader.getName())) {

In the enveloppe, ax21 = "http://b.com/xsd"; so the ax21:field_A do not have the 
"http://a.com/xsd"; like expected by the Stub.






-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



Re: Please revert API changes done as per AXIS2-4465

2009-08-25 Thread Davanum Srinivas

Amila,

you said:

"You have not put any comment in my suggestion to  resolve the issue keeping
your change and with out breaking carbon. We will test it and commit if you
don't have any suggestions to fix this issue."

Do you have proposed patch on how to fix this break?

thanks,
dims

On 08/25/2009 01:02 AM, Amila Suriarachchi wrote:

You have not put any comment in my suggestion to  resolve the issue keeping
your change and with out breaking carbon. We will test it and commit if you
don't have any suggestions to fix this issue.


[jira] Issue Comment Edited: (AXIS2-4470) won't receive arguments sent by RPCServiceClient::invokeBlocking anymore with axis 2-1.5 (axis2-4.1 kernel works fine)

2009-08-25 Thread Jeroen (JIRA)

[ 
https://issues.apache.org/jira/browse/AXIS2-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12747335#action_12747335
 ] 

Jeroen edited comment on AXIS2-4470 at 8/25/09 2:59 AM:


Same problem here, communicating using Axis2-1.5 client to an Axis1 server.


RPCServiceClient serviceClient = new RPCServiceClient();
EndpointReference targetEPR = new 
EndpointReference(getGenericDataServiceEndpointUrl());
Options options = serviceClient.getOptions();
options.setTo(targetEPR);
QName opPutData = new QName("ns:putData", "putData");
Object[] putDataArgs = new Object[] {
"parameter1",
"parameter2"
};
Object[] returns = serviceClient.invokeBlocking(opPutData, putDataArgs, new 
Class[] { String[].class });


No arguments are passed to the server.

  was (Author: entiteit):
Same problem here, communicating using Axis2-1.5 client to an Axis1 server.


RPCServiceClient serviceClient = new RPCServiceClient();
EndpointReference targetEPR = new 
EndpointReference(getGenericDataServiceEndpointUrl());
Options options = serviceClient.getOptions();
options.setTo(targetEPR);
QName opPutData = new QName("ns:putData", "putData");
Object[] putDataArgs = new Object[] {
"parameter1",
"parameter2"
};
Class[] types = new Class[] { String[].class }; 
Object[] returns = serviceClient.invokeBlocking(opPutData, putDataArgs, new 
Class[] { String[].class });


No arguments are passed to the server.
  
> won't receive arguments sent by RPCServiceClient::invokeBlocking anymore with 
> axis 2-1.5 (axis2-4.1 kernel works fine)
> --
>
> Key: AXIS2-4470
> URL: https://issues.apache.org/jira/browse/AXIS2-4470
> Project: Axis 2.0 (Axis2)
>  Issue Type: Bug
>  Components: kernel
>Affects Versions: 1.5
> Environment: win xp
>Reporter: Magnus Melin
>
> I have a client like
> import javax.xml.namespace.QName;
> import org.apache.axis2.AxisFault;
> import org.apache.axis2.addressing.EndpointReference;
> import org.apache.axis2.client.Options;
> import org.apache.axis2.rpc.client.RPCServiceClient;
> public class SimpleWSClient {
> public SimpleWSClient(String url) throws AxisFault {
> this.serviceClient = new RPCServiceClient();
> Options options = serviceClient.getOptions();
> EndpointReference targetEPR = new EndpointReference(url);
> options.setTo(targetEPR);
> }
> public Meaning[] findSameAs(String label, String uri) throws AxisFault {
> QName qname = new QName("http://example.org/ws";, "findSameAs");
> Object[] wsArgs = new Object[] { label, uri };
> Class[] rvTypes = new Class[] { Meaning[].class };
> Object[] response = serviceClient.invokeBlocking(
> qname, wsArgs, rvTypes);
> Meaning[] meanings = (Meaning[]) response[0];
> return meanings;
> }
> }
> When i call findSameAs, the server will receive only empty arguments. 
> If i keep all the other 2-1.5 jars, but replace axis2-kernel-1.5.jar with 
> axis2-kernel-1.4.1.jar the label and uri arguments are received again (though 
> it generates other errors later...)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Issue Comment Edited: (AXIS2-4470) won't receive arguments sent by RPCServiceClient::invokeBlocking anymore with axis 2-1.5 (axis2-4.1 kernel works fine)

2009-08-25 Thread Jeroen (JIRA)

[ 
https://issues.apache.org/jira/browse/AXIS2-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12747335#action_12747335
 ] 

Jeroen edited comment on AXIS2-4470 at 8/25/09 2:59 AM:


Same problem here, communicating using Axis2-1.5 client to an Axis1 server.


RPCServiceClient serviceClient = new RPCServiceClient();
EndpointReference targetEPR = new 
EndpointReference(getGenericDataServiceEndpointUrl());
Options options = serviceClient.getOptions();
options.setTo(targetEPR);
QName opPutData = new QName("ns:putData", "putData");
Object[] putDataArgs = new Object[] {
"parameter1",
"parameter2"
};
Class[] types = new Class[] { String[].class }; 
Object[] returns = serviceClient.invokeBlocking(opPutData, putDataArgs, new 
Class[] { String[].class });


No arguments are passed to the server.

  was (Author: entiteit):
Same problem here, communicating using Axis2-1.5 client to an Axis1 server.
{code}RPCServiceClient serviceClient = new RPCServiceClient();
EndpointReference targetEPR = new 
EndpointReference(getGenericDataServiceEndpointUrl());
Options options = serviceClient.getOptions();
options.setTo(targetEPR);
QName opPutData = new QName("ns:putData", "putData");
Object[] putDataArgs = new Object[] {
"parameter1",
"parameter2"
};
Class[] types = new Class[] { String[].class }; 
Object[] returns = serviceClient.invokeBlocking(opPutData, putDataArgs, new 
Class[] { String[].class });{code}

No arguments are passed to the server.
  
> won't receive arguments sent by RPCServiceClient::invokeBlocking anymore with 
> axis 2-1.5 (axis2-4.1 kernel works fine)
> --
>
> Key: AXIS2-4470
> URL: https://issues.apache.org/jira/browse/AXIS2-4470
> Project: Axis 2.0 (Axis2)
>  Issue Type: Bug
>  Components: kernel
>Affects Versions: 1.5
> Environment: win xp
>Reporter: Magnus Melin
>
> I have a client like
> import javax.xml.namespace.QName;
> import org.apache.axis2.AxisFault;
> import org.apache.axis2.addressing.EndpointReference;
> import org.apache.axis2.client.Options;
> import org.apache.axis2.rpc.client.RPCServiceClient;
> public class SimpleWSClient {
> public SimpleWSClient(String url) throws AxisFault {
> this.serviceClient = new RPCServiceClient();
> Options options = serviceClient.getOptions();
> EndpointReference targetEPR = new EndpointReference(url);
> options.setTo(targetEPR);
> }
> public Meaning[] findSameAs(String label, String uri) throws AxisFault {
> QName qname = new QName("http://example.org/ws";, "findSameAs");
> Object[] wsArgs = new Object[] { label, uri };
> Class[] rvTypes = new Class[] { Meaning[].class };
> Object[] response = serviceClient.invokeBlocking(
> qname, wsArgs, rvTypes);
> Meaning[] meanings = (Meaning[]) response[0];
> return meanings;
> }
> }
> When i call findSameAs, the server will receive only empty arguments. 
> If i keep all the other 2-1.5 jars, but replace axis2-kernel-1.5.jar with 
> axis2-kernel-1.4.1.jar the label and uri arguments are received again (though 
> it generates other errors later...)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (AXIS2-4470) won't receive arguments sent by RPCServiceClient::invokeBlocking anymore with axis 2-1.5 (axis2-4.1 kernel works fine)

2009-08-25 Thread Jeroen (JIRA)

[ 
https://issues.apache.org/jira/browse/AXIS2-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12747335#action_12747335
 ] 

Jeroen commented on AXIS2-4470:
---

Same problem here, communicating using Axis2-1.5 client to an Axis1 server.
{code}RPCServiceClient serviceClient = new RPCServiceClient();
EndpointReference targetEPR = new 
EndpointReference(getGenericDataServiceEndpointUrl());
Options options = serviceClient.getOptions();
options.setTo(targetEPR);
QName opPutData = new QName("ns:putData", "putData");
Object[] putDataArgs = new Object[] {
"parameter1",
"parameter2"
};
Class[] types = new Class[] { String[].class }; 
Object[] returns = serviceClient.invokeBlocking(opPutData, putDataArgs, new 
Class[] { String[].class });{code}

No arguments are passed to the server.

> won't receive arguments sent by RPCServiceClient::invokeBlocking anymore with 
> axis 2-1.5 (axis2-4.1 kernel works fine)
> --
>
> Key: AXIS2-4470
> URL: https://issues.apache.org/jira/browse/AXIS2-4470
> Project: Axis 2.0 (Axis2)
>  Issue Type: Bug
>  Components: kernel
>Affects Versions: 1.5
> Environment: win xp
>Reporter: Magnus Melin
>
> I have a client like
> import javax.xml.namespace.QName;
> import org.apache.axis2.AxisFault;
> import org.apache.axis2.addressing.EndpointReference;
> import org.apache.axis2.client.Options;
> import org.apache.axis2.rpc.client.RPCServiceClient;
> public class SimpleWSClient {
> public SimpleWSClient(String url) throws AxisFault {
> this.serviceClient = new RPCServiceClient();
> Options options = serviceClient.getOptions();
> EndpointReference targetEPR = new EndpointReference(url);
> options.setTo(targetEPR);
> }
> public Meaning[] findSameAs(String label, String uri) throws AxisFault {
> QName qname = new QName("http://example.org/ws";, "findSameAs");
> Object[] wsArgs = new Object[] { label, uri };
> Class[] rvTypes = new Class[] { Meaning[].class };
> Object[] response = serviceClient.invokeBlocking(
> qname, wsArgs, rvTypes);
> Meaning[] meanings = (Meaning[]) response[0];
> return meanings;
> }
> }
> When i call findSameAs, the server will receive only empty arguments. 
> If i keep all the other 2-1.5 jars, but replace axis2-kernel-1.5.jar with 
> axis2-kernel-1.4.1.jar the label and uri arguments are received again (though 
> it generates other errors later...)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.