[jira] Commented: (AXIS-1797) Base attributes not serialized when simpleContent extends another simpleContent

[Jayachandra Sekhara Rao Sunkara (JIRA)]

 [ 
http://issues.apache.org/jira/browse/AXIS-1797?page=comments#action_66594 ]
 
Jayachandra Sekhara Rao Sunkara commented on AXIS-1797:
---

Hi Steve,
running the given Test.java against the artifacts created from the 
SimpleTypes.wsdl you have provided yielded me following results

Using 1.2 source without applying your patch.
-
http://namespace"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xmlns:ns
2="http://test.com/reference";>abc123

After applying your patch:
--
http://namespace"; 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; 
xmlns:ns2="http://test.com/reference";>abc123

Actually even after the patch is applied, I couldn't see in the serialized 
piece of XML the values of BaseAttr1 and BaseAttr2. However I noticed that the 
DerivedSimpleType class created by WSDL2Java came out extending BaseSimpleType 
class without the _value datamember in it. Is the patch complete enough? or did 
I miss something? Can you post the response you got after running Test.java 
with your patch applied. Does it have in total three attributes?

Thanks
Jayachandra

> Base attributes not serialized when simpleContent extends another 
> simpleContent
> ---
>
>  Key: AXIS-1797
>  URL: http://issues.apache.org/jira/browse/AXIS-1797
>  Project: Axis
> Type: Bug
>   Components: WSDL processing
> Versions: current (nightly)
> Reporter: Steve Green
>  Attachments: 1797.patch, 1797.test.tar, 1797.wsdl, Test.java
>
> When a simpleContent extends another simpleContent, and the base type has 
> attributes, those attributes are not serialized.
> I believe that the problem is with the code generation, and not a 
> serialization bug.  The code generator uses a has-a model for this, and I 
> believe that it should be an is-a model.  This is also necessary to allow for 
> polymorphic behavior in the generated classes.

-- 
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: [Axis2][VOTE]Proposal for Axis2 M2

[Jaliya Ekanayake]

Here is my +1 for M2

Jaliya

-Original Message-
From: Chathura Herath [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, May 31, 2005 9:06 AM
To: axis-dev@ws.apache.org
Subject: RE: [Axis2][VOTE]Proposal for Axis2 M2

+1 
Chathura

-Original Message-
From: Sanjiva Weerawarana [mailto:[EMAIL PROTECTED] 
Sent: Monday, May 30, 2005 6:09 PM
To: Srinath Perera
Cc: axis-dev@ws.apache.org
Subject: Re: [Axis2][VOTE]Proposal for Axis2 M2

+1!

Sanjiva.

On Mon, 2005-05-30 at 11:08 +0600, Srinath Perera wrote:
> Hi All;
> Axis2 had lot of progress lately and most of the
> changes decided in the Axis2 F2F has Incorporated,
> I think now it is good time to move on.
> 
> I like to purpose a M2 release on July 7 th, following is the purposed
> improvements to the M2 from M1.
> 
> 1) implementing the Contexts - laying out a hierarchy to handle the
information
> 2) implementing the Module Architecture
> 3) implementing the support for real Async that happens over the two
> channel, this complete the support for MEPs
>In-Only MEP
>In-Out
>* Sync/ One Channel
>* Async/One Channel
>* Sync/ two Channel
>* Async/two Channel
> 4) Client API support for #3
> 5) WSDL code generation without data binding
> 6) implementing the Addressing Module
> 7) TCP/HTTP transport support (we might be able to get the SMTP up as
well)
> 8) REST Support
> 9) MTOM Support
> 10) Admin Web App
> 11) WSDL2WS, eclipe Plugin/Command line version
> 12) Service Archive Wizard
> 13) Module Archive Wizard
> 14) Samples
> 
> Here is My +1
> 
> Thanks
> Srinath
> 

[Axis2] Need for children API for OMDocument

[jayachandra]

Hi devs,

I have two suggestions regarding OMDocument

First - a trivial one:
---
It lacks an interface definition in the package org.apache.axis.om and
a direct implementation class with name OMDocument.java is coded in
the o.a.a.om.impl.llom package. In line with how rest of the code is
arranged, I suggest we have in o.a.a.om package an interface with name
OMDocument.java listing out the setter and getter methods for
rootElement. And in the OMFactory interface we will add an extra
signature something like createOMDocument so as to enable other than
llom factory to be able to provide OMDocument implementation. Let the
implementation class in impl.llom package be named as
OMDocumentImpl.java

Second - this is a critical design issue:

Looking at the current OMDocument support I've realized that it
doesn't have a child navigation API. We might be doing away without it
as far as soap processing is considered. But without the child
navigation API in it, XMLInfoset can never be fully supported because
in an XML document other than the unique root element, at the same
level we can have several other nodes like documentation comments,
processing instructions, DTD element etc.
Enabling child API in OMDocument, implementation wise is not any
difficult. It can be just making it extend OMElement. Something like
public interface OMDocument extends OMElement ;

Semantically if the above looks confusing and weird (OMDocument being
an OMElement !!??!!), alternatively we can copy paste the already
coded child API functionality of OMElementImpl into OMDocumentImpl
letting OMDocument to stand on its own without extending any other
interface. Also, performance wise these changes are not going to add
any significant overhead.

Anticipating thoughts, ideas, suggestions

Regards
Jaya

Re: [Axis2][VOTE]Proposal for Axis2 M2

[Srinath Perera]

Venkat +1000.. actually :) let us add them

On 5/31/05, Venkat Reddy <[EMAIL PROTECTED]> wrote:
> +1 from me, but i suggest we also add the following to the list :-) 
>   
> 1. SAAJ support (will check in updates soon, related to recent changes in
> OM). 
> 2. Improved Infoset support (handling for comments, PI and a test case for
> W3C XML conformance test suite). 
>   
> Currently SAAJ impl uses OM directly, but will switch to using DOM once we
> have the DOM layer. 
>   
> -- venkat
> 
>  
>  
> On 5/31/05, Deepal Jayasinghe <[EMAIL PROTECTED]> wrote: 
> > Hi all;
> > here is my +1 for M2 realse
> > 
> > 
> > Deepal
> > 
> > - Original Message -
> > From: "Chathura Herath" < [EMAIL PROTECTED]>
> > To: 
> > Sent: Tuesday, May 31, 2005 9:06 AM
> > Subject: RE: [Axis2][VOTE]Proposal for Axis2 M2 
> > 
> > 
> > > +1
> > > Chathura
> > >
> > > -Original Message-
> > > From: Sanjiva Weerawarana [mailto:[EMAIL PROTECTED]
> > > Sent: Monday, May 30, 2005 6:09 PM 
> > > To: Srinath Perera
> > > Cc: axis-dev@ws.apache.org
> > > Subject: Re: [Axis2][VOTE]Proposal for Axis2 M2
> > >
> > > +1!
> > >
> > > Sanjiva.
> > >
> > > On Mon, 2005-05-30 at 11:08 +0600, Srinath Perera wrote: 
> > >> Hi All;
> > >> Axis2 had lot of progress lately and most of the
> > >> changes decided in the Axis2 F2F has Incorporated,
> > >> I think now it is good time to move on.
> > >>
> > >> I like to purpose a M2 release on July 7 th, following is the purposed 
> > >> improvements to the M2 from M1.
> > >>
> > >> 1) implementing the Contexts - laying out a hierarchy to handle the
> > > information
> > >> 2) implementing the Module Architecture
> > >> 3) implementing the support for real Async that happens over the two 
> > >> channel, this complete the support for MEPs
> > >>In-Only MEP
> > >>In-Out
> > >>* Sync/ One Channel
> > >>* Async/One Channel
> > >>* Sync/ two Channel 
> > >>* Async/two Channel
> > >> 4) Client API support for #3
> > >> 5) WSDL code generation without data binding
> > >> 6) implementing the Addressing Module
> > >> 7) TCP/HTTP transport support (we might be able to get the SMTP up as 
> > > well)
> > >> 8) REST Support
> > >> 9) MTOM Support
> > >> 10) Admin Web App
> > >> 11) WSDL2WS, eclipe Plugin/Command line version
> > >> 12) Service Archive Wizard
> > >> 13) Module Archive Wizard 
> > >> 14) Samples
> > >>
> > >> Here is My +1
> > >>
> > >> Thanks
> > >> Srinath
> > >>
> > >
> > >
> > >
> > >
> > >
> > >
> > 
> > 
> 
>

Re: [Axis2][VOTE]Proposal for Axis2 M2

[Venkat Reddy]

+1 from me, but i suggest we also add the following to the list :-)
 
1. SAAJ support (will check in updates soon, related to recent changes in OM).
2. Improved Infoset support (handling for comments, PI and a test case for W3C XML conformance test suite).
 
Currently SAAJ impl uses OM directly, but will switch to using DOM once we have the DOM layer.
 
-- venkat 
On 5/31/05, Deepal Jayasinghe <[EMAIL PROTECTED]> wrote:
Hi all;here is my +1 for M2 realseDeepal- Original Message -From: "Chathura Herath" <
[EMAIL PROTECTED]>To: Sent: Tuesday, May 31, 2005 9:06 AMSubject: RE: [Axis2][VOTE]Proposal for Axis2 M2
> +1> Chathura>> -Original Message-> From: Sanjiva Weerawarana [mailto:[EMAIL PROTECTED]]> Sent: Monday, May 30, 2005 6:09 PM
> To: Srinath Perera> Cc: axis-dev@ws.apache.org> Subject: Re: [Axis2][VOTE]Proposal for Axis2 M2>> +1!>> Sanjiva.>> On Mon, 2005-05-30 at 11:08 +0600, Srinath Perera wrote:
>> Hi All;>> Axis2 had lot of progress lately and most of the>> changes decided in the Axis2 F2F has Incorporated,>> I think now it is good time to move on. I like to purpose a M2 release on July 7 th, following is the purposed
>> improvements to the M2 from M1. 1) implementing the Contexts - laying out a hierarchy to handle the> information>> 2) implementing the Module Architecture>> 3) implementing the support for real Async that happens over the two
>> channel, this complete the support for MEPs>>In-Only MEP>>In-Out>>* Sync/ One Channel>>* Async/One Channel>>* Sync/ two Channel
>>* Async/two Channel>> 4) Client API support for #3>> 5) WSDL code generation without data binding>> 6) implementing the Addressing Module>> 7) TCP/HTTP transport support (we might be able to get the SMTP up as
> well)>> 8) REST Support>> 9) MTOM Support>> 10) Admin Web App>> 11) WSDL2WS, eclipe Plugin/Command line version>> 12) Service Archive Wizard>> 13) Module Archive Wizard
>> 14) Samples Here is My +1 Thanks>> Srinath

Re: [Axis2][VOTE]Proposal for Axis2 M2

[Deepal Jayasinghe]

Hi all;
here is my +1 for M2 realse


Deepal

- Original Message - 
From: "Chathura Herath" <[EMAIL PROTECTED]>

To: 
Sent: Tuesday, May 31, 2005 9:06 AM
Subject: RE: [Axis2][VOTE]Proposal for Axis2 M2


+1 
Chathura


-Original Message-
From: Sanjiva Weerawarana [mailto:[EMAIL PROTECTED] 
Sent: Monday, May 30, 2005 6:09 PM

To: Srinath Perera
Cc: axis-dev@ws.apache.org
Subject: Re: [Axis2][VOTE]Proposal for Axis2 M2

+1!

Sanjiva.

On Mon, 2005-05-30 at 11:08 +0600, Srinath Perera wrote:

Hi All;
Axis2 had lot of progress lately and most of the
changes decided in the Axis2 F2F has Incorporated,
I think now it is good time to move on.

I like to purpose a M2 release on July 7 th, following is the purposed
improvements to the M2 from M1.

1) implementing the Contexts - laying out a hierarchy to handle the

information

2) implementing the Module Architecture
3) implementing the support for real Async that happens over the two
channel, this complete the support for MEPs
   In-Only MEP
   In-Out
   * Sync/ One Channel
   * Async/One Channel
   * Sync/ two Channel
   * Async/two Channel
4) Client API support for #3
5) WSDL code generation without data binding
6) implementing the Addressing Module
7) TCP/HTTP transport support (we might be able to get the SMTP up as

well)

8) REST Support
9) MTOM Support
10) Admin Web App
11) WSDL2WS, eclipe Plugin/Command line version
12) Service Archive Wizard
13) Module Archive Wizard
14) Samples

Here is My +1

Thanks
Srinath

Re: [Axis2][VOTE]Proposal for Axis2 M2

[Ajith Ranabahu]

+1-- Ajith Ranabahu

RE: [Axis2][VOTE]Proposal for Axis2 M2

[Eran Chinthaka]

+1. 

> -Original Message-
> From: Davanum Srinivas [mailto:[EMAIL PROTECTED]
> Sent: Monday, May 30, 2005 5:51 PM
> To: axis-dev@ws.apache.org; Srinath Perera
> Subject: Re: [Axis2][VOTE]Proposal for Axis2 M2
> 
> +1 from me.
> 
> -- dims
> 
> On 5/30/05, Srinath Perera <[EMAIL PROTECTED]> wrote:
> > Hi All;
> > Axis2 had lot of progress lately and most of the
> > changes decided in the Axis2 F2F has Incorporated,
> > I think now it is good time to move on.
> >
> > I like to purpose a M2 release on July 7 th, following is the purposed
> > improvements to the M2 from M1.
> >
> > 1) implementing the Contexts - laying out a hierarchy to handle the
> information
> > 2) implementing the Module Architecture
> > 3) implementing the support for real Async that happens over the two
> > channel, this complete the support for MEPs
> >In-Only MEP
> >In-Out
> >* Sync/ One Channel
> >* Async/One Channel
> >* Sync/ two Channel
> >* Async/two Channel
> > 4) Client API support for #3
> > 5) WSDL code generation without data binding
> > 6) implementing the Addressing Module
> > 7) TCP/HTTP transport support (we might be able to get the SMTP up as
> well)
> > 8) REST Support
> > 9) MTOM Support
> > 10) Admin Web App
> > 11) WSDL2WS, eclipe Plugin/Command line version
> > 12) Service Archive Wizard
> > 13) Module Archive Wizard
> > 14) Samples
> >
> > Here is My +1
> >
> > Thanks
> > Srinath
> >
> 
> 
> --
> Davanum Srinivas - http://webservices.apache.org/~dims/

RE: [Axis2][VOTE]Proposal for Axis2 M2

[Chathura Herath]

+1 
Chathura

-Original Message-
From: Sanjiva Weerawarana [mailto:[EMAIL PROTECTED] 
Sent: Monday, May 30, 2005 6:09 PM
To: Srinath Perera
Cc: axis-dev@ws.apache.org
Subject: Re: [Axis2][VOTE]Proposal for Axis2 M2

+1!

Sanjiva.

On Mon, 2005-05-30 at 11:08 +0600, Srinath Perera wrote:
> Hi All;
> Axis2 had lot of progress lately and most of the
> changes decided in the Axis2 F2F has Incorporated,
> I think now it is good time to move on.
> 
> I like to purpose a M2 release on July 7 th, following is the purposed
> improvements to the M2 from M1.
> 
> 1) implementing the Contexts - laying out a hierarchy to handle the
information
> 2) implementing the Module Architecture
> 3) implementing the support for real Async that happens over the two
> channel, this complete the support for MEPs
>In-Only MEP
>In-Out
>* Sync/ One Channel
>* Async/One Channel
>* Sync/ two Channel
>* Async/two Channel
> 4) Client API support for #3
> 5) WSDL code generation without data binding
> 6) implementing the Addressing Module
> 7) TCP/HTTP transport support (we might be able to get the SMTP up as
well)
> 8) REST Support
> 9) MTOM Support
> 10) Admin Web App
> 11) WSDL2WS, eclipe Plugin/Command line version
> 12) Service Archive Wizard
> 13) Module Archive Wizard
> 14) Samples
> 
> Here is My +1
> 
> Thanks
> Srinath
> 

[jira] Commented: (AXIS-1999) Add configuration setting to bypass the SOAP HTTP binding requirement of a SOAPAction header

[Jason Sweeney (JIRA)]

 [ 
http://issues.apache.org/jira/browse/AXIS-1999?page=comments#action_66580 ]
 
Jason Sweeney commented on AXIS-1999:
-

This is my suggestion for the patch explained above.  All changes are in the 
org.apache.axis.transport.http.AxisServlet class.

Header, line 110:

// Location of the services as defined by the servlet-mapping in web.xml
public static final String INIT_PROPERTY_SERVICES_PATH =
"axis.servicesPath";

>>> // This will enforce the use of the SOAPAction HTTP header as mandated by 
>>> the SOAP HTTP binding
>>> // See: http://issues.apache.org/jira/browse/AXIS-1999
>>> public static final String REQUIRE_SOAP_ACTION_HEADER = 
>>> "axis.requireSOAPActionHeader";

// These have default values.
private String transportName;


Header, line 138:

/**
 * Should we turn off the list of services when we receive a GET
 * at the servlet root?
 */
private boolean disableServicesList = false;

>>> /**
>>>  * This will enforce the use of the SOAPAction HTTP header as mandated by 
>>> the SOAP HTTP binding
>>>  * For several legacy systems, providing a custom HTTP header is difficult 
>>> or impossible.
>>>  * Since this is more of a technicality and no actual value is required in 
>>> the header,
>>>  * allowing the header to be optional by configuration enables legacy 
>>> systems to send SOAP
>>>  * documents to an application exposing services through the Axis framework.
>>>  * See: http://issues.apache.org/jira/browse/AXIS-1999
>>>  */
>>> private boolean requireSOAPActionHeader = true;

/**
 * Cached path to JWS output directory
 */
private String jwsClassDir = null;
protected String getJWSClassDir() {return jwsClassDir;
}

init(), line 184:

servicesPath = getOption(context, INIT_PROPERTY_SERVICES_PATH,
 "/services/");

>>> // This will enforce the use of the SOAPAction HTTP header as mandated 
>>> by the SOAP HTTP binding
>>> // See: http://issues.apache.org/jira/browse/AXIS-1999
>>> requireSOAPActionHeader = JavaUtils.isTrue(getOption(context, 
>>> REQUIRE_SOAP_ACTION_HEADER, "true"));


getSoapAction(), line 992

private String getSoapAction(HttpServletRequest req) throws AxisFault {
String soapAction = req.getHeader(HTTPConstants.HEADER_SOAP_ACTION);

if (isDebug) {
log.debug("HEADER_SOAP_ACTION:" + soapAction);

/**
 * Technically, if we don't find this header, we should probably 
fault.
 * It's required in the SOAP HTTP binding.
 */
}

>>> // This will enforce the use of the SOAPAction HTTP header
>>> // as mandated by the SOAP HTTP binding
>>> // See: http://issues.apache.org/jira/browse/AXIS-1999
if (soapAction == null) {
>>> 
>>> if (requireSOAPActionHeader) {
AxisFault af = new AxisFault("Client.NoSOAPAction",
 Messages.getMessage("noHeader00",
 "SOAPAction"),
 null, null);

exceptionLog.error(Messages.getMessage("genFault00"), af);

throw af;
>>> } 
>>> else {
>>> // Simply set the SOAP Action to the empty value
>>> soapAction = "\"\"";
>>> }
}

// the SOAP 1.1 spec & WS-I 1.0 says:
// soapaction= "SOAPAction" ":" [ <"> URI-reference <"> ]
// some implementations leave off the quotes
// we strip them if they are present
if (soapAction.startsWith("\"") && soapAction.endsWith("\"")
&& soapAction.length() >= 2) {
int end = soapAction.length() - 1;
soapAction = soapAction.substring(1, end);
}

if (soapAction.length() == 0) {
soapAction = req.getContextPath(); // Is this right?

}
return soapAction;
}


> Add configuration setting to bypass the SOAP HTTP binding requirement of a 
> SOAPAction header
> 
>
>  Key: AXIS-1999
>  URL: http://issues.apache.org/jira/browse/AXIS-1999
>  Project: Axis
> Type: Improvement
>   Components: Basic Architecture
> Versions: 1.2
>  Environment: Irrelevant to this issue
> Reporter: Jason Sweeney

>
> In the org.apache.axis.transport.http.AxisServlet.getSoapAction() method, 
> when no HTTP header is found for the name 'SOAPAction' (as defined in 
> org.apache.axis.transport.http.HTTPConstants.HEADER_SOAP_ACTION), the process 
> faults and returns an error.  As you mention very clearly in the 
> documentation of this method, this is "technically" correct and respects the 
> letter of the SOAP HTTP binding specification.
> However, in the real world, there are numerous applicatio

[jira] Commented: (AXIS-1752) xs:list attributes do not serialize

[Davanum Srinivas (JIRA)]

 [ 
http://issues.apache.org/jira/browse/AXIS-1752?page=comments#action_66579 ]
 
Davanum Srinivas commented on AXIS-1752:


Steve,

Since everything is working except for "attributes that are lists". i'd 
consider it a bug.

thanks,
dims

> xs:list attributes do not serialize
> ---
>
>  Key: AXIS-1752
>  URL: http://issues.apache.org/jira/browse/AXIS-1752
>  Project: Axis
> Type: Bug
>   Components: Serialization/Deserialization
> Versions: current (nightly)
> Reporter: Steve Green
>  Attachments: 1752-02.02.05.diff, 1752-and-1762-diff.txt, 1752.diff, 
> 1752.diff-u, 1752.wsdl, 1752_try2.patch, Test.java, Test1752.java
>
> When sending messages that contain attributes consisting of a list, the 
> attribute is not serialized.
> The problem appears to be for 2 reasons.
> 1.  wsdl2java does not generate the indexed getter and setter methods.  The 
> bean introspector does not recognize the method as a list method and thus the 
> serializer fails when trying to serialize the "value".
> 2.  BeanSerializer doesn't have any code to serialize attributes that are 
> indexed.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Commented: (AXIS-1997) Regression causing out-of-memory errors for services without attachments returning large response messages

[Davanum Srinivas (JIRA)]

 [ 
http://issues.apache.org/jira/browse/AXIS-1997?page=comments#action_66578 ]
 
Davanum Srinivas commented on AXIS-1997:


done. thanks.

-- dims

> Regression causing out-of-memory errors for services without attachments 
> returning large response messages
> --
>
>  Key: AXIS-1997
>  URL: http://issues.apache.org/jira/browse/AXIS-1997
>  Project: Axis
> Type: Bug
>   Components: Serialization/Deserialization
> Versions: 1.2
>  Environment: Irrelevant to issue at hand
> Reporter: Jason Sweeney

>
> In version 1.1, specifying a value of "none" to the attachment attribute of a 
> service in the deployment description file ensured that the response message 
> would be directly serialized to the HTTP response stream (for the HTTP 
> transport type).
> This has been broken in the 1.2 version by the addition of the following 
> lines in the org.apache.axis.attachments.AttachmentsImpl.getAttachmentCount() 
> method:
> // force a serialization of the message so that
> // any attachments will be added
> soapPart.saveChanges();
> This method is called from the org.apache.axis.Message.getContentType() 
> method in the following section:
> if (mAttachments != null && 0 != mAttachments.getAttachmentCount()) {
> ret = mAttachments.getContentType();
> }
> In order to preserve the support of large response message for services that 
> explictly do not allow attachments, the following code (or its functional 
> equivalent) should be added:
>  
> >>  int sendType = Attachments.SEND_TYPE_NOTSET;
> >>  if ((msgContext != null) && (msgContext.getService() != null)) {
> >>  sendType = msgContext.getService().getSendType();
> >>  }
> >>  if (sendType != Attachments.SEND_TYPE_NONE) {
> if (mAttachments != null && 0 != 
> mAttachments.getAttachmentCount()) {
> ret = mAttachments.getContentType();
> }
> >>  }
> NOTE: Detection of the send type was already present in the 1.1 version of 
> this method.
> There is no functional issue with this modification since the service 
> explicitly declares itself free of attachments, so the attachment count will 
> necessarily be zero.  This low-cost extra validation allows for an entire 
> realm of services to be supported by Axis (massive exports of data) in a 
> seamless way immediately in 1.2.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Commented: (AXIS-2000) $ (dollar sign) Allowed in generated class names

[Davanum Srinivas (JIRA)]

 [ 
http://issues.apache.org/jira/browse/AXIS-2000?page=comments#action_66562 ]
 
Davanum Srinivas commented on AXIS-2000:


Are u using Axis1.2? please upload your wsdl.

thanks,
dims

> $ (dollar sign) Allowed in generated class names
> 
>
>  Key: AXIS-2000
>  URL: http://issues.apache.org/jira/browse/AXIS-2000
>  Project: Axis
> Type: Bug
>   Components: WSDL processing
> Versions: 1.0-rc2
> Reporter: Hawk Newton
> Priority: Minor

>
> wsdl2java will go ahead and use the wsdl:portName for the name of the class, 
> even if that name contains (or even stars with) a $ (dollar sign).  JSR 101 
> (Section 4.3.3) specifies the wsdl:portName should be used for the name of 
> the client class, but a check needs to be made and the $ (dollar sign) needs 
> to be replaced with a _ (underscore)

-- 
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: (AXIS-1752) xs:list attributes do not serialize

[Steve Green (JIRA)]

 [ http://issues.apache.org/jira/browse/AXIS-1752?page=all ]

Steve Green updated AXIS-1752:
--

Attachment: Test1752.java

Attached is a totally self contained version of the test program.  No wsdl or 
further code generation is needed.

> xs:list attributes do not serialize
> ---
>
>  Key: AXIS-1752
>  URL: http://issues.apache.org/jira/browse/AXIS-1752
>  Project: Axis
> Type: Bug
>   Components: Serialization/Deserialization
> Versions: current (nightly)
> Reporter: Steve Green
>  Attachments: 1752-02.02.05.diff, 1752-and-1762-diff.txt, 1752.diff, 
> 1752.diff-u, 1752.wsdl, 1752_try2.patch, Test.java, Test1752.java
>
> When sending messages that contain attributes consisting of a list, the 
> attribute is not serialized.
> The problem appears to be for 2 reasons.
> 1.  wsdl2java does not generate the indexed getter and setter methods.  The 
> bean introspector does not recognize the method as a list method and thus the 
> serializer fails when trying to serialize the "value".
> 2.  BeanSerializer doesn't have any code to serialize attributes that are 
> indexed.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Commented: (AXIS-1997) Regression causing out-of-memory errors for services without attachments returning large response messages

[Jason Sweeney (JIRA)]

 [ 
http://issues.apache.org/jira/browse/AXIS-1997?page=comments#action_66577 ]
 
Jason Sweeney commented on AXIS-1997:
-

I subsequently found that the same patch had to be applied to the writeTo() 
method of the org.apache.axis.Message class.

Could you please complete the patch by adding the following (or its functional 
equivalent) to the Message class.

public void writeTo(java.io.OutputStream os) throws SOAPException, 
IOException {
 //Do it the old fashion way.

>>> // When service that explicitly do not use attachments attempt to 
>>> return large response
>>> // documents, the call to the getAttachmentCount() method forces a 
>>> -useless- serialization
>>> // to a String instance causing out of memory errors.  This temporary 
>>> fix has been submitted
>>> // to the Axis project as issue AXIS-1997 for inclusion in the next 
>>> version of the product.
>>> // The fix itself is similar to the code present in this method in the 
>>> 1.1 version.
>>> // See: http://issues.apache.org/jira/browse/AXIS-1997
>>> 
>>> // Determine the attachment send type of the current service
>>> int sendType = Attachments.SEND_TYPE_NOTSET;
>>> if ((msgContext != null) && (msgContext.getService() != null)) {
>>> sendType = msgContext.getService().getSendType();
>>> }
>>>
>>> // Only request the content type of the attachments if the service 
>>> allows such constructs
>>> if (sendType == Attachments.SEND_TYPE_NONE || mAttachments == null
>>>  || 0 == mAttachments.getAttachmentCount()) {
try {
String charEncoding = XMLUtils.getEncoding(this, msgContext);;
mSOAPPart.setEncoding(charEncoding);
mSOAPPart.writeTo(os);
} catch (java.io.IOException e) {
log.error(Messages.getMessage("javaIOException00"), e);
}
} else {
try {
mAttachments.writeContentToStream(os);
} catch (java.lang.Exception e) {
log.error(Messages.getMessage("exception00"), e);
}
}
}



> Regression causing out-of-memory errors for services without attachments 
> returning large response messages
> --
>
>  Key: AXIS-1997
>  URL: http://issues.apache.org/jira/browse/AXIS-1997
>  Project: Axis
> Type: Bug
>   Components: Serialization/Deserialization
> Versions: 1.2
>  Environment: Irrelevant to issue at hand
> Reporter: Jason Sweeney

>
> In version 1.1, specifying a value of "none" to the attachment attribute of a 
> service in the deployment description file ensured that the response message 
> would be directly serialized to the HTTP response stream (for the HTTP 
> transport type).
> This has been broken in the 1.2 version by the addition of the following 
> lines in the org.apache.axis.attachments.AttachmentsImpl.getAttachmentCount() 
> method:
> // force a serialization of the message so that
> // any attachments will be added
> soapPart.saveChanges();
> This method is called from the org.apache.axis.Message.getContentType() 
> method in the following section:
> if (mAttachments != null && 0 != mAttachments.getAttachmentCount()) {
> ret = mAttachments.getContentType();
> }
> In order to preserve the support of large response message for services that 
> explictly do not allow attachments, the following code (or its functional 
> equivalent) should be added:
>  
> >>  int sendType = Attachments.SEND_TYPE_NOTSET;
> >>  if ((msgContext != null) && (msgContext.getService() != null)) {
> >>  sendType = msgContext.getService().getSendType();
> >>  }
> >>  if (sendType != Attachments.SEND_TYPE_NONE) {
> if (mAttachments != null && 0 != 
> mAttachments.getAttachmentCount()) {
> ret = mAttachments.getContentType();
> }
> >>  }
> NOTE: Detection of the send type was already present in the 1.1 version of 
> this method.
> There is no functional issue with this modification since the service 
> explicitly declares itself free of attachments, so the attachment count will 
> necessarily be zero.  This low-cost extra validation allows for an entire 
> realm of services to be supported by Axis (massive exports of data) in a 
> seamless way immediately in 1.2.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Commented: (AXIS-1753) All xs:choice members are non-nillable

[Steve Green (JIRA)]

 [ 
http://issues.apache.org/jira/browse/AXIS-1753?page=comments#action_66570 ]
 
Steve Green commented on AXIS-1753:
---

Thank you for applying the patch, however upon further investigation I am 
seeing that the patch was not applied as it was written.

My version of the patch looped through all elements just before returning from 
processChoiceNode() whereas the modified patch that got applied only addressed 
"element" children.

My concern is about xs:group choice members.  At the time this patch was 
applied, Axis was broken in the way it handled groups.  Now that my patch for 
groups was taken, groups work much like macros.  That is, a choice with a group 
in it will behave exactly like a choice with the group members directly in the 
choice element.  My concern is that such choice members will not have 
setMinOccursIs0() set.

The processChoiceNode() code also deals with other element types. Shouldn't 
those element types also get setMinOccursIs0()?

> All xs:choice members are non-nillable
> --
>
>  Key: AXIS-1753
>  URL: http://issues.apache.org/jira/browse/AXIS-1753
>  Project: Axis
> Type: Bug
>   Components: WSDL processing
> Versions: current (nightly)
> Reporter: Steve Green
> Assignee: Davanum Srinivas
>  Attachments: 1753.diff
>
> All xs:choice members are non-nillable, thus not really allowing for a choice.

-- 
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: (AXIS-2009) SimpleListDeserializerFactory is not serializable

[Davanum Srinivas (JIRA)]

 [ http://issues.apache.org/jira/browse/AXIS-2009?page=all ]
 
Davanum Srinivas resolved AXIS-2009:


Resolution: Fixed

already fixed.

> SimpleListDeserializerFactory is not serializable
> -
>
>  Key: AXIS-2009
>  URL: http://issues.apache.org/jira/browse/AXIS-2009
>  Project: Axis
> Type: Bug
> Reporter: Gianny Damour
>  Attachments: patch
>
> SimpleListDeserializerFactory defines a non transient field of type 
> Constructor. Hence, it is not serializable.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Commented: (AXIS-1752) xs:list attributes do not serialize

[Steve Green (JIRA)]

 [ 
http://issues.apache.org/jira/browse/AXIS-1752?page=comments#action_66565 ]
 
Steve Green commented on AXIS-1752:
---

Tom, Dims, etc..

AXIS-1752, and AXIS-1762 may not be valid bugs.

I understand that all types must be registered in the type mapping in order to 
{de}serialize properly.  These bug reports address what I thought was a grey 
area.

The problem I've run across is that a bean with xs:list attributes does not 
serialize properly in a stand alone code fragment.  i.e. 

Bean bean = new Bean();
bean.setX(...);
bean.setY(...);
new MessageElement(.., .., bean).toString();

BeanSerializer can do everything (so far) except for attributes that are lists.

Attached is a test program that shows the problem in action.  You'll notice 
that the attribute values are not serialized.  If you say that Axis is working 
as designed (i.e. not working) then please close AXIS-1762 and AXIS-1752.

If these bugs are deemed valid, then a further review of my fixes is probably 
warranted.



> xs:list attributes do not serialize
> ---
>
>  Key: AXIS-1752
>  URL: http://issues.apache.org/jira/browse/AXIS-1752
>  Project: Axis
> Type: Bug
>   Components: Serialization/Deserialization
> Versions: current (nightly)
> Reporter: Steve Green
>  Attachments: 1752-02.02.05.diff, 1752-and-1762-diff.txt, 1752.diff, 
> 1752.diff-u, 1752.wsdl, 1752_try2.patch, Test.java, Test1752.java
>
> When sending messages that contain attributes consisting of a list, the 
> attribute is not serialized.
> The problem appears to be for 2 reasons.
> 1.  wsdl2java does not generate the indexed getter and setter methods.  The 
> bean introspector does not recognize the method as a list method and thus the 
> serializer fails when trying to serialize the "value".
> 2.  BeanSerializer doesn't have any code to serialize attributes that are 
> indexed.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Commented: (AXIS-1999) Add configuration setting to bypass the SOAP HTTP binding requirement of a SOAPAction header

[Davanum Srinivas (JIRA)]

 [ 
http://issues.apache.org/jira/browse/AXIS-1999?page=comments#action_66563 ]
 
Davanum Srinivas commented on AXIS-1999:


A patch would make it easy to make a decision :)

thanks,
dims

> Add configuration setting to bypass the SOAP HTTP binding requirement of a 
> SOAPAction header
> 
>
>  Key: AXIS-1999
>  URL: http://issues.apache.org/jira/browse/AXIS-1999
>  Project: Axis
> Type: Improvement
>   Components: Basic Architecture
> Versions: 1.2
>  Environment: Irrelevant to this issue
> Reporter: Jason Sweeney

>
> In the org.apache.axis.transport.http.AxisServlet.getSoapAction() method, 
> when no HTTP header is found for the name 'SOAPAction' (as defined in 
> org.apache.axis.transport.http.HTTPConstants.HEADER_SOAP_ACTION), the process 
> faults and returns an error.  As you mention very clearly in the 
> documentation of this method, this is "technically" correct and respects the 
> letter of the SOAP HTTP binding specification.
> However, in the real world, there are numerous applications that would and 
> could communication SOAP message to an application exposing "web services" 
> with Axis but that cannot configure custom HTTP headers (usually because the 
> protocol management is encapsulated in an external library that never 
> envisionned this possibility).  Since by everyone's admission this is really 
> a technicality of the specification and in real life almost no web services 
> implementations actually use the value of the SOAPAction header to set the 
> service name information, we would like the next version of Axis to offer a 
> configuration setting to ignore this requirement of the SOAP HTTP binding 
> specification.
> A proposal would be to include a new global parameter named 
> 'axis.requireSOAPActionHeader' that would default to 'true', hence preserving 
> the exact functional behavior of the current version.  However, when set to 
> false, the fault code of the getSoapAction() method mentioned above would be 
> simply skipped and the value associated to the SOAPAction header would be 
> left to 'null'.
> This simple configuration setting would allow many new business uses of the 
> Axis framework and extremely simply the incremental migration of the 
> interaction of legacy systems with new modern web service based systems.
> Thanks!

-- 
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: (AXIS-1997) Regression causing out-of-memory errors for services without attachments returning large response messages

[Davanum Srinivas (JIRA)]

 [ http://issues.apache.org/jira/browse/AXIS-1997?page=all ]
 
Davanum Srinivas resolved AXIS-1997:


Resolution: Fixed

Applied Patch.

thanks,
dims

> Regression causing out-of-memory errors for services without attachments 
> returning large response messages
> --
>
>  Key: AXIS-1997
>  URL: http://issues.apache.org/jira/browse/AXIS-1997
>  Project: Axis
> Type: Bug
>   Components: Serialization/Deserialization
> Versions: 1.2
>  Environment: Irrelevant to issue at hand
> Reporter: Jason Sweeney

>
> In version 1.1, specifying a value of "none" to the attachment attribute of a 
> service in the deployment description file ensured that the response message 
> would be directly serialized to the HTTP response stream (for the HTTP 
> transport type).
> This has been broken in the 1.2 version by the addition of the following 
> lines in the org.apache.axis.attachments.AttachmentsImpl.getAttachmentCount() 
> method:
> // force a serialization of the message so that
> // any attachments will be added
> soapPart.saveChanges();
> This method is called from the org.apache.axis.Message.getContentType() 
> method in the following section:
> if (mAttachments != null && 0 != mAttachments.getAttachmentCount()) {
> ret = mAttachments.getContentType();
> }
> In order to preserve the support of large response message for services that 
> explictly do not allow attachments, the following code (or its functional 
> equivalent) should be added:
>  
> >>  int sendType = Attachments.SEND_TYPE_NOTSET;
> >>  if ((msgContext != null) && (msgContext.getService() != null)) {
> >>  sendType = msgContext.getService().getSendType();
> >>  }
> >>  if (sendType != Attachments.SEND_TYPE_NONE) {
> if (mAttachments != null && 0 != 
> mAttachments.getAttachmentCount()) {
> ret = mAttachments.getContentType();
> }
> >>  }
> NOTE: Detection of the send type was already present in the 1.1 version of 
> this method.
> There is no functional issue with this modification since the service 
> explicitly declares itself free of attachments, so the attachment count will 
> necessarily be zero.  This low-cost extra validation allows for an entire 
> realm of services to be supported by Axis (massive exports of data) in a 
> seamless way immediately in 1.2.

-- 
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: (AXIS-2001) Generated stubs differ between Solaris and Windows

[Davanum Srinivas (JIRA)]

 [ http://issues.apache.org/jira/browse/AXIS-2001?page=all ]
 
Davanum Srinivas resolved AXIS-2001:


Resolution: Fixed

Make sure you use the same version of jdk and xerces on both platforms

thanks,
dims

> Generated stubs differ between Solaris and Windows
> --
>
>  Key: AXIS-2001
>  URL: http://issues.apache.org/jira/browse/AXIS-2001
>  Project: Axis
> Type: Bug
>   Components: WSDL processing
> Versions: 1.2
>  Environment: Solaris 9 running sun JDK 1.4.2_06
> Windows 2kSP4 running sun JDK 1.4.2_07b5
> Reporter: Will Lauer
>  Attachments: wsdl.zip
>
> While using java2wsdl and then wsdl2java to generate first WSDL from an 
> interface definition and then proxy stubs from the wsdl, the resulting stubs 
> diff when generated on Solaris vs Windows. Specifically, the arguments to 
> bean constructors may be placed in different orders depending on platform. 
> The prevents the use of common implementation classes being writen to use 
> these generated stubs on all platforms.
> It looks like the problem is with 
> src\org\apache\axis\wsdl\toJava\JavaBeanWriter.java in the method 
> writeMinimalConstructor(). There seems to have been a change between axis 
> 1.2RC3 and axix 1.2 RTM that removed code to sort the constructor arguments.

-- 
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: (AXIS-2005) AXIS can not handel

[Davanum Srinivas (JIRA)]

 [ http://issues.apache.org/jira/browse/AXIS-2005?page=all ]
 
Davanum Srinivas resolved AXIS-2005:


Resolution: Incomplete

Please upload all the xsd/wsdl files.

thanks,
dims

> AXIS can not handel  -
>
>  Key: AXIS-2005
>  URL: http://issues.apache.org/jira/browse/AXIS-2005
>  Project: Axis
> Type: Bug
>  Environment: axis1.2 (Java version)
> Reporter: Quansheng Jia

>
> We have few XML schemas with same namespace, 
> http://www.ifxforum.org/XSD/IFX17.  The schema may include each other using 
> syn ," display when run WSDL2java using a WSDL which imports above XML schema.
> {http://www.ifxforum.org/XSD/IFX17}POSAgent already exists
> The bug can be removed by modified class package 
> org.apache.axis.wsdl.symbolTable.SymbolTable.addTypes(), see attachment.

-- 
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: (AXIS-2026) wsdl2java does not generate array of wrappers for soapenc array nillable elements

[Hans (JIRA)]

wsdl2java does not generate array of wrappers for soapenc array nillable 
elements
-

 Key: AXIS-2026
 URL: http://issues.apache.org/jira/browse/AXIS-2026
 Project: Axis
Type: Bug
  Components: WSDL processing  
Versions: current (nightly)
 Environment: JDK 1.4.2_06, Linux
Reporter: Hans


For the following structure

















wsdl2java from Axis 1.1 generates a Java Class like:

class StructureType implements Serializable {
private Integer[] fld;
...


But with Axis 1.2 the following is generated:

class StructureType implements Serializable {
private int[] fld;
... 

This is incorrect - type should be Integer[].


I will have a go at creating a fix for 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] Assigned: (AXIS-2002) Problem using OUT-parameters

[Davanum Srinivas (JIRA)]

 [ http://issues.apache.org/jira/browse/AXIS-2002?page=all ]

Davanum Srinivas reassigned AXIS-2002:
--

Assign To: Venkat Reddy

> Problem using OUT-parameters
> 
>
>  Key: AXIS-2002
>  URL: http://issues.apache.org/jira/browse/AXIS-2002
>  Project: Axis
> Type: Bug
> Versions: 1.2
>  Environment: AXIS 1.2 final, running under IBM AIX 5.2, IBM Java 1.4.2, 
> TomCat 4.1.30
> Reporter: Søren Jæger Hansen
> Assignee: Venkat Reddy

>
> I've encountered a problem developing AXIS-based webservices. The webservice 
> is implemented in AXIS 1.2 final, running under IBM AIX, Java 1.4.2.
> The webservice call is defined to AXIS using a WSDD-file containing:
> ...
>   
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>   
> ...
> The problem arises when the webservice is called from VB.NET. It seems that 
> VB.NET may exclude empty parameters in the call (ie. if Dimension1-parameter 
> above is an empty string, it is not sent in the XML-request, even if the 
> parameter is explicitly given in the according WSDL).
> The problem is that OUT-only parameters are kind of "floating" in AXIS. When 
> I set up debug logging in log4j.properties, part of the debug output reads as 
> follows:
> 20196 [http8081-Processor4] DEBUG org.apache.axis.description.OperationDesc  
> - @17c0abbf added parameter >name:   Dimension5
> typeEntry:  null
> mode:   INOUT
> position:   14
> isReturn:   false
> typeQName:  null
> javaType:   null
> inHeader:   false
> outHeader:  false
> @19e32bbf 20196 [http8081-Processor4] DEBUG org.apache.axis.description.OperationDesc  
> - @17c0abbf added parameter >name:   Dimension6
> typeEntry:  null
> mode:   INOUT
> position:   15
> isReturn:   false
> typeQName:  null
> javaType:   null
> inHeader:   false
> outHeader:  false
> @2e5f6bbf 20196 [http8081-Processor4] DEBUG org.apache.axis.description.OperationDesc  
> - @17c0abbf added parameter >name:   Success
> typeEntry:  null
> mode:   OUT
> position:   -1
> isReturn:   false
> typeQName:  null
> javaType:   null
> inHeader:   false
> outHeader:  false
> @213babbf The problem here is "position: -1" in the last ("Success") parameter. It has 
> the implication that AXIS does not correctly set up the call to the java stub 
> when some of the parameters are missing in the serialized XML request. This 
> may cause various errors ranging from parameter mismatch (which are reported 
> to the client) to AXIS/TomCat crashes.
> Looking into the org/apache/axis/description/OperationDesc.java code (rev 
> 1.43), the following lines are revealed in method addParameter, line 255:
> - OperationDesc.java, line 255:
> parameters.add(param);
> if ((param.getMode() == ParameterDesc.IN) ||
> (param.getMode() == ParameterDesc.INOUT)) {
> param.setOrder(numInParams++);
> }
> if ((param.getMode() == ParameterDesc.OUT) ||
> (param.getMode() == ParameterDesc.INOUT)) {
> numOutParams++;
> }
> -
> Ie. param.setOrder is only called for IN and INOUT parameters. For OUT 
> parameters, the order is -1, causing the problems described above.
> I suggest the following code that assigns an ordering to all fields, even if 
> they're output-only-parameters. This fix seems to make things work for me:
> -  OperationDesc.java, line 255:
> param.setOrder(getNumParams());
> parameters.add(param);
> if ((param.getMode() == ParameterDesc.IN) ||
> (param.getMode() == ParameterDesc.INOUT)) {
> numInParams++;
> }
> if ((param.getMode() == ParameterDesc.OUT) ||
> (param.getMode() == ParameterDesc.INOUT)) {
> numOutParams++;
> }
> -

-- 
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] Reopened: (AXIS-1753) All xs:choice members are non-nillable

[Davanum Srinivas (JIRA)]

 [ http://issues.apache.org/jira/browse/AXIS-1753?page=all ]
 
Davanum Srinivas reopened AXIS-1753:


 Assign To: Davanum Srinivas

Steve hinted at possible problems with this one...reopening the bug.

> All xs:choice members are non-nillable
> --
>
>  Key: AXIS-1753
>  URL: http://issues.apache.org/jira/browse/AXIS-1753
>  Project: Axis
> Type: Bug
>   Components: WSDL processing
> Versions: current (nightly)
> Reporter: Steve Green
> Assignee: Davanum Srinivas
>  Attachments: 1753.diff
>
> All xs:choice members are non-nillable, thus not really allowing for a choice.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Commented: (AXIS-2021) String Array Regression causes SAXException: Found character data ...

[Davanum Srinivas (JIRA)]

 [ 
http://issues.apache.org/jira/browse/AXIS-2021?page=comments#action_66551 ]
 
Davanum Srinivas commented on AXIS-2021:


Please upload the complete WSDL

thanks,
dims

> String Array Regression causes SAXException: Found character data ...
> -
>
>  Key: AXIS-2021
>  URL: http://issues.apache.org/jira/browse/AXIS-2021
>  Project: Axis
> Type: Bug
>   Components: Serialization/Deserialization
> Versions: 1.2
>  Environment: Server - Tomcat 5.0.25 on Java 1.4.2_01 on Fedora Core 3
> Client - Axis running on Java 1.4.2_05 On Window XP SP2
> Reporter: Dan Armbrust
> Priority: Blocker

>
> This seems to be a serious regression bug... But maybe I'm doing something 
> wrong...
> I was using 1.2 RC2, and everything was working for me.  Now under 1.2 final, 
> the handling of arrays appears broken.
> Here is the error:
> org.apache.axis.AxisFaultorg.xml.sax.SAXException: Found character data 
> inside an array element while deserializing
> Here is the message that it choked on:
> http://schemas.xmlsoap.org/soap/envelope/"; 
> xmlns:xsd="http://www.w3.org/2001/XMLSchema"; 
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
>  
>
>   xsi:type="ns1:ArrayOf_xsd_string">IdenticalIgnoreCase
>  
> StartsWithIgnoreCase
>  
> EndsWithIgnoreCase
>  
> ContainsPhraseIgnoreCase
>
>  
> 
> What it is supposed to be returning is a simple String[].
> A snippit  from the wsdl file:
>   
>
>   
>   
>
> 
>   type="xsd:string"/>
> 
>
>   
> So I don't know why that ArrayOf_xsd_string gunk is in the response.
> My build process is kind of complicated - my initial definition of the API is 
> in IDL.  The idl is compiled into Java.  Then, my WSDL is generated by the 
> java2wsdl tool, using the "-y WRAPPED"  option.
> Then, I generate java using wsdl2java tool - and I implement my API using the 
> resulting java classes.  One thing that I noted here, was that 1.2 rc2 
> generated  "ArrayOf_X" classes  for each array object, while 1.2 final does 
> not generate any ArrayOf_X classes.
> Finally I install the code into my Axis server, and try it out.  I can call 
> most of the methods in my API - but anything that returns an a String Array 
> throws the SAXException (as noted above) while trying to parse the response, 
> which has stuff in it it shouldn't.
> Dan

-- 
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: (AXIS-2024) enum package causes compilation problems with java 1.5

[Davanum Srinivas (JIRA)]

 [ http://issues.apache.org/jira/browse/AXIS-2024?page=all ]
 
Davanum Srinivas closed AXIS-2024:
--

Resolution: Invalid

don't compile them :)

> enum package causes compilation problems with java 1.5
> --
>
>  Key: AXIS-2024
>  URL: http://issues.apache.org/jira/browse/AXIS-2024
>  Project: Axis
> Type: Bug
>   Components: Basic Architecture
> Versions: 1.2RC2
>  Environment: java sdk 1.5
> Reporter: anonymous
> Priority: Minor

>
> java 1.5 introduced enumeration types. thus, 'enum' has become a keyword in 
> java. this causes compilation problems with the 'enum' package inside the 
> axis.jar.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Commented: (AXIS-1818) MessageElement [] for doesn't include all elements

[Davanum Srinivas (JIRA)]

 [ 
http://issues.apache.org/jira/browse/AXIS-1818?page=comments#action_66554 ]
 
Davanum Srinivas commented on AXIS-1818:


Jaya,

any updates on this?

thanks,
dims

> MessageElement [] for  doesn't include all elements
> 
>
>  Key: AXIS-1818
>  URL: http://issues.apache.org/jira/browse/AXIS-1818
>  Project: Axis
> Type: Bug
>   Components: Serialization/Deserialization
> Versions: 1.2RC2
>  Environment: XP / JDK 1.4.x / Axis 1.2 RC3
> Reporter: Simon Fell
> Assignee: Venkat Reddy
>  Attachments: sforce.xml, sforce.xsd
>
> This is with Axis 1.2 RC3
> Given this type fragment
> 
> 
>  maxOccurs="unbounded"/>
> 
> 
> 
> If a runtime message returns the Id element twice, the 2nd instance, which 
> should end up in the any collection gets dropped.
> There's a sample service at http://soap.4s4c.com/dotnet/any.wsdl that this 
> test code shows this problem.
>   AnyServiceLocator loc = new AnyServiceLocator();
>   Soap svc = loc.getSoap();
>   
>   QueryResult qr = svc.query("blah");
>   
>   for (int i =0; i < qr.getRecords().length; i++ ) {
>   SObject s = qr.getRecords(i);
>   MessageElement [] e= s.get_any();
>   System.out.println("MessageElement array size is " + 
> e.length);
>   for (int j = 0; j < e.length; j++ ){
>   System.out.print(" " + e[j].getValue());
>   }
>   System.out.println("");
>   }
> This prints out "MessageElement array size is 2", even though there's 3 
> elements that appear after the first Id element, here's the fragement of the 
> response.
> 
> Contact
> 0033006jryXAAQ
> 0033006jryXAAQ
> Fred
> A>B
> 

-- 
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: (AXIS-2014) java.lang.ArrayStoreException while deserializing an array of structs

[Davanum Srinivas (JIRA)]

 [ http://issues.apache.org/jira/browse/AXIS-2014?page=all ]

Davanum Srinivas reassigned AXIS-2014:
--

Assign To: Venkat Reddy

venkat?

> java.lang.ArrayStoreException while deserializing an array of structs
> -
>
>  Key: AXIS-2014
>  URL: http://issues.apache.org/jira/browse/AXIS-2014
>  Project: Axis
> Type: Bug
>   Components: Serialization/Deserialization
> Versions: 1.2
>  Environment: Sun JDK 1.5.0_03
> Windows XP
> Reporter: Robson Miranda
> Assignee: Venkat Reddy

>
> Using the classes generated with wsdl4j with the WSDL found in 
> http://soap.genome.ad.jp/KEGG.wsdl, i'm getting the following stacktrace:
> Exception in thread "main" AxisFault
>  faultCode: {http://schemas.xmlsoap.org/soap/envelope/}Server.userException
>  faultSubcode: 
>  faultString: java.lang.ArrayStoreException: 
> org.apache.axis.encoding.ser.ArrayDeserializer$ArrayListExtension
>  faultActor: 
>  faultNode: 
>  faultDetail: 
>   {http://xml.apache.org/axis/}stackTrace:java.lang.ArrayStoreException: 
> org.apache.axis.encoding.ser.ArrayDeserializer$ArrayListExtension
>   at org.apache.axis.utils.JavaUtils.convert(JavaUtils.java:472)
>   at org.apache.axis.client.Call.invoke(Call.java:2518)
>   at org.apache.axis.client.Call.invoke(Call.java:2347)
>   at org.apache.axis.client.Call.invoke(Call.java:1804)
>   at kegg.soap.KEGGBindingStub.list_pathways(KEGGBindingStub.java:765)
>   at 
> org.biofoco.server.service.ExternalDatabaseService.main(ExternalDatabaseService.java:297)
>   {http://xml.apache.org/axis/}hostname:lobato
> java.lang.ArrayStoreException: 
> org.apache.axis.encoding.ser.ArrayDeserializer$ArrayListExtension
>   at org.apache.axis.AxisFault.makeFault(AxisFault.java:101)
>   at org.apache.axis.client.Call.invoke(Call.java:1820)
>   at kegg.soap.KEGGBindingStub.list_pathways(KEGGBindingStub.java:765)
> Caused by: java.lang.ArrayStoreException: 
> org.apache.axis.encoding.ser.ArrayDeserializer$ArrayListExtension
>   at org.apache.axis.utils.JavaUtils.convert(JavaUtils.java:472)
>   at org.apache.axis.client.Call.invoke(Call.java:2518)
>   at org.apache.axis.client.Call.invoke(Call.java:2347)
>   at org.apache.axis.client.Call.invoke(Call.java:1804)
>   ... 2 more
> This exception is caused by the ArrayDeserializer, which tries to deserialize 
> each of the structs (i.e. it is using ArrayDeserializer to deserialize a 
> struct).
> Uncommenting the following lines in 
> DeserializationContext.getDeserializerForClass(Class), I got it working. In 
> this case, the correct deserializer is used for the structs.
> if (cls.isArray()) {
> cls = cls.getComponentType();
> }
> Thanks,
>Robson Paniago

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Commented: (AXIS-2025) Illegal XML characters in String arguments and return values cause XML exceptions in Axis calls

[Davanum Srinivas (JIRA)]

 [ 
http://issues.apache.org/jira/browse/AXIS-2025?page=comments#action_66547 ]
 
Davanum Srinivas commented on AXIS-2025:


check the server logs...post stack traces if any.

thanks,
dims

> Illegal XML characters in String arguments and return values cause XML 
> exceptions in Axis calls
> ---
>
>  Key: AXIS-2025
>  URL: http://issues.apache.org/jira/browse/AXIS-2025
>  Project: Axis
> Type: Bug
>   Components: Serialization/Deserialization
> Versions: 1.2
>  Environment: All (but reproduced on WinXP).
> Axis 1.1 and 1.2
> Reporter: Shankar Unni

>
> Arguments and return values of Java type String are incorrectly handled if 
> they contain non-printing illegal ASCII characters.
> Example 1: bad return values:
> - - - - - - - - - - - - - - -
> E.g. the string 
>   "bad char: " + (char)3 + "."
> Trivial example:
> foo.jws:
>   public class foo {
> public String badmsg()
> {
>   return "bad: " + (char)3 + ".";
> }
>   }
> When calling this method and the server is running on Axis 1.1, it returns 
> XML with the illegal character ASCII "3" in the text:
>bad: .  
> This causes an XML parse exception on the client side 
> ("org.xml.sax.SAXParseException: An invalid XML character (Unicode: 0x3) was 
> found in the element content of the document.")
> With Axis 1.2, the server doesn't even return a valid response: I get an HTTP 
> 200 OK with an empty content, causing a different XML parse error.
> Example 2: bad parameter values:
> - - - - - - - - - - - - - - - -
> A similar problem exists when passing such a string from the the client side.
> If I have a method in foo.jws:
>   public class foo {
> public String echo(String s)
> {
>   return s;
> }
>   }
> Then if I write an ordinary Java client to call this, and pass it a bad 
> string as in the beginning of this post, I get an exception thrown while the 
> call is being composed:
> java.lang.IllegalArgumentException: The char '0x3' in 'bad char: ?.' is not a 
> valid XML character.
> This is somewhat absurd: shouldn't the serialization layer be encoding these 
> illegal XML characters as entity escapes? They're entirely legal in the 
> current locale (US), and normal Java code handles this character quite 
> normally.  Why should it croak when passed by XML/RPC?

-- 
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: (AXIS-2011) Multi Dimensional Array Serialization

[Davanum Srinivas (JIRA)]

 [ http://issues.apache.org/jira/browse/AXIS-2011?page=all ]
 
Davanum Srinivas resolved AXIS-2011:


Resolution: Fixed

Already fixed. Right Guillaume?

-- dims

> Multi Dimensional Array Serialization
> -
>
>  Key: AXIS-2011
>  URL: http://issues.apache.org/jira/browse/AXIS-2011
>  Project: Axis
> Type: Improvement
>   Components: Serialization/Deserialization, Deployment / Registries
> Versions: 1.2
>  Environment: JOnAS 4.4
> Reporter: Guillaume Sauthier
> Assignee: Guillaume Sauthier
>  Fix For: 1.2.1
>  Attachments: axis-arrayMapping.patch, axis-src.jar, axis-test.jar
>
> Actually the test case test.wsdl.marshall is broken because Axis do not 
> serialize 2D arrays as expected.
> See http://www.w3.org/TR/2000/NOTE-SOAP-2508/#_Toc478383522 for reference.
> We are expecting a correct SOAP Message formed like this :
> soap:Body
>  ns1:myOperation
>   return
>return soapenc:arraytype="xsd:string[][2]" xsi:type="soapenc:Array"
> return soapenc:arraytype="xsd:string[2]" xsi:type="soapenc:Array"
>  return xsi:type="xsd:string" [Value1]
>  return xsi:type="xsd:string" []
>  return xsi:type="xsd:string" xsi:nil="true"
> [...]
> Instead, we have the following :
> soap:Body
>  ns1:myOperation
>   return
>return soapenc:arraytype="ns:ArrayOfstring[][2]" xsi:type="soapenc:Array"
> return soapenc:arraytype="xsd:string[2]" xsi:type="soapenc:Array"
>  return xsi:type="xsd:string" [Value1]
>  return xsi:type="xsd:string" []
>  return xsi:type="ns:ArrayOfArrayOfstring" xsi:nil="true"
> [...]
> Points to notice :
> A. the first arrayType has a wrong xml type (expecting most inner non array 
> type xsd:string in place of ns:ArrayOfstring)
> B. the first arrayType has a right dims ([][2]) : 2D array with 2 elements 
> for the first dim
> C. last element of the array has a wrong xsi:type ! I don't know where it 
> comes from but its wrong, indeed :)
> The first thing I tried to change the xsi:type (C) was to lookup the xml type 
> from the (most inner non array )Java type we retrieve. Problem with this 
> approach : I can't exactly control if I will get an xsd:string or 
> soapenc:string. For my case, I was waiting an xsd:string and the TypeMapping 
> gives me a soapenc:string. Grrr !
> Looking deeper in ArraySerializer.serialize(), we can see that this 
> serializer is not "symetrical" (for java type and xml type) : we can go 
> several levels deep when searching for the most inner non array java type, 
> but we're stuck to the itemType (only 1 level deep) retrieved from 
> SerializationContext for xml types!
> My idea is to allow searching in xml types too. If we have for each 
> ArraySerializer the wanted innerType, we can get the mapped serializer. If 
> the retrieved serializer is an ArraySerilalizer, we can go one step further, 
> ...
> So with this, we're symetrical (we go deeper for the xml AND java types in 
> the same time).
> Notice that's more time consumming, because we search TypeMapping very often !
> Now, how to give these metadatas to the Engine ? In the wsdd, indeed !
> So now, we have a new element arrayMapping element that allow us to specify 
> the innerType for an ArraySerializer !
> To be complete, I made some changes too in JavaDeployWriter, to write up the 
> arrayMapping element when an ArraySerializerFactory has to be used.
> Important : This is only for review (Glen/Tom ?) !! The code attached to this 
> report is neither clean nor complete :
> - innerName attribute is not used, could be usefull ?
> - to limitate the number of impacted files, a lot of Constants are inside 
> WSDDArrAyMapping, should go in WSDDContstants.
> - at this time, arrayMapping is only understand if contained in a service 
> element ! We should add for each TypeMappingContainer subclasses...
> - WSDDArrayMapping can be improved with error message (when trying to set 
> ser/deser other than ArraySerFactory...)
> - maybe we can add some NPE checks :)
> Thanks for your comments/suggestions !
> --Guillaume

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Commented: (AXIS-2013) Deserialization of Exception fails

[Davanum Srinivas (JIRA)]

 [ 
http://issues.apache.org/jira/browse/AXIS-2013?page=comments#action_66556 ]
 
Davanum Srinivas commented on AXIS-2013:


Hans,

please enclose the test case for recreating the problem.

thanks,
dims

> Deserialization of Exception fails
> --
>
>  Key: AXIS-2013
>  URL: http://issues.apache.org/jira/browse/AXIS-2013
>  Project: Axis
> Type: Bug
>   Components: Serialization/Deserialization
> Versions: current (nightly)
>  Environment: Linux, JDK 1.4.2_06
> Reporter: Hans

>
> I have a very basic application deployed as a webservice with one operation 
> that throws a user-defined exception (derived from AxisFault). The client 
> application calling this operation has defined a type mapping that maps the 
> operation fault to a client-side Exception class. When the client invokes the 
> operation and the exception is thrown, the client throws an AxisFault instead 
> of the client-exception class. 
> When I edit the server-config.wsdd and set the parameter 'sendMultiRefs' to 
> false, everything works ok: the exception thrown in the server is 
> deserialized and the client throws the mapped client-side exception. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Commented: (AXIS-2010) Wrong xsi:type handling with derived types

[Davanum Srinivas (JIRA)]

 [ 
http://issues.apache.org/jira/browse/AXIS-2010?page=comments#action_66553 ]
 
Davanum Srinivas commented on AXIS-2010:


Yves,

please upload a complete wsdl.

thanks,
dims

> Wrong xsi:type handling with derived types
> --
>
>  Key: AXIS-2010
>  URL: http://issues.apache.org/jira/browse/AXIS-2010
>  Project: Axis
> Type: Bug
>   Components: Serialization/Deserialization
> Versions: 1.2
> Reporter: Yves Langisch
> Priority: Critical

>
> Given a type in a wsdl such as:
> 
>  
>  
>  
>  
> 
> Axis generates following on the wire:
> ...
> 99
> ...
> This is incorrect, as MyDerivedFromShort is derived from xs:short but not 
> xs:short itself. To be sure I let Xerces validating the document. This gives 
> following error:
> Validation error: LineNumber: 48 ColumnNumber: 2883 Message: 
> cvc-elt.4.3: Type 'xsd:short' is not validly derived from the type 
> definition, 'MyDerivedFromShortType', of element 'ns2:MyDerivedFromShort'.:
> Axis 1.2RC3 didn't show this behaviour.

-- 
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: (AXIS-2018) WSDL2Java generates > symbols where it shouldn't

[Davanum Srinivas (JIRA)]

 [ http://issues.apache.org/jira/browse/AXIS-2018?page=all ]
 
Davanum Srinivas resolved AXIS-2018:


Resolution: Invalid

Daniel, If you see an extraneous '>' in the soap messages or in the wsdl 
generated at runtime then i will reopen the problem. It's perfectly ok for us 
to use '>' in wsdd, generated code etc...as long as it does not show up on the 
wire.

thanks,
dims

> WSDL2Java generates > symbols where it shouldn't
> 
>
>  Key: AXIS-2018
>  URL: http://issues.apache.org/jira/browse/AXIS-2018
>  Project: Axis
> Type: Bug
>   Components: WSDL processing
> Versions: 1.2
>  Environment: Windows XP w/ SP1, JBoss 4.0.2, Axis 1.2
> Reporter: Daniel Kador
>  Attachments: StockQuote.wsdl, StockQuote.xsd, deploy.wsdd
>
> First off, I was under the impression that this bug was fixed.  It's possible 
> I'm doing something incorrectly, but if so, I'm not sure what.  Hopefully I'm 
> not wasting any developer's time.
> I'm using a WSDL that has an .xsd file as its schema.  I'll attach them if 
> requested.  When I run the command "java org.apache.axis.wsdl.WSDL2Java -s -S 
> true mywsdl.wsdl", everything proceeds as it should.  However, both the 
> deploy.wsdd and various parts of the emitted Java code contains extraneous > 
> symbols, which obviously is not a good thing.  Like I said above, I thought 
> this was fixed in the 1.2 release, but apparently it is not.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Commented: (AXIS-2022) WSDL2Java baulks at legitimate maxOccurs="unbounded"

[Davanum Srinivas (JIRA)]

 [ 
http://issues.apache.org/jira/browse/AXIS-2022?page=comments#action_66550 ]
 
Davanum Srinivas commented on AXIS-2022:


Please upload the complete wsdl.

thanks,
dims

> WSDL2Java baulks at legitimate maxOccurs="unbounded"
> 
>
>  Key: AXIS-2022
>  URL: http://issues.apache.org/jira/browse/AXIS-2022
>  Project: Axis
> Type: Bug
>   Components: WSDL processing
> Versions: 1.2, 1.2.1
>  Environment: Windows 2000 Professional; Java 1.4.2-b28
> Reporter: Jeff Lawson

>
> This pattern:
> 
> 
>   
> 
>   
> 
> causes WSDL2Java to throw:
> java.io.IOException: Type {http://ay-bee-cee/}MyOtherElement is
> referenced but not defined
> maxOccurs="unbounded" is causing the problem because this pattern:
> 
> 
>   
> 
>   
> 
> does not throw an exception, though it's too far from what I want. I 
> discovered, however, that this pattern:
> 
> 
>   
> 
> 
>   
> 
> didn't throw an exception either and it produced code from which I could 
> easily remove MyUnwantedElement-related content.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Commented: (AXIS-2020) wsdl2java does not generate array of wrappers for array of nillable primitives

[Hans (JIRA)]

 [ 
http://issues.apache.org/jira/browse/AXIS-2020?page=comments#action_66546 ]
 
Hans commented on AXIS-2020:


Patch works well, but only for first scenario. For soapenc arrays having an 
element with maxOccurs="unbounded" and nillable="true" wsdl2java still
does not generate a wrapper. Because I thought that both cases were
caused by the same problem I created one bug. I will submit another bug 
for the second testcase.

> wsdl2java does not generate array of wrappers for array of nillable primitives
> --
>
>  Key: AXIS-2020
>  URL: http://issues.apache.org/jira/browse/AXIS-2020
>  Project: Axis
> Type: Bug
>   Components: WSDL processing
> Versions: 1.2
> Reporter: Hans
>  Attachments: 2020.txt, 2020.txt
>
> For the following xsd construct:
> 
> 
>  nillable="true" minOccurs="0" maxOccurs="unbounded"/>
> 
> 
> 
> 
> 
> 
> 
>  nillable="true" minOccurs="0" maxOccurs="unbounded"/>
> 
> 
> 
> 
> wsdl2java from Axis 1.1 generates a Java Class like:
> class StructureType implements Serializable {
> private Integer[] fld1;
> private Integer[] fld2;
> ...
> But in Axis 1.2 the following is generated:
> class StructureType implements Serializable {
> private int[] fld1;
> private int[] fld2;
> ...
> This is incorrect - wrapper types should have been used for fld1 and fld2.
> Also reproducable on the nightly 1.2.1 build of 27 may 2005.

-- 
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

Blockers for Axis 1.2.1 Release(?)

[Davanum Srinivas]

Hi all,

Let's get the ball rolling again...Anyone see blockers for a minor
release? Please make sure the problem exists in latest CVS,
write/upload a test case and finally change the priority on the JIRA
issue to blocker.

Thanks,
dims
-- 
Davanum Srinivas - http://webservices.apache.org/~dims/

Axis 1.2 class loading issue

[Toni Ala-Piirto]

I have a web application using Axis and Axis is also used by some additions 
to tomcat architecture.


My deployment strategy would be to have a Axis.jar and all related jars in 
tomcats common/lib directory. Because it is used from Server/lib and 
Webapp/lib directories but this is not possible because it will break up 
possibility to hot deploy my webapp.


Other solution is to have Axis.jar and other related jars in server/lib 
directory and in webapp/lib directory. This solution unfortunately fails. 
I'm using axis as an client from class located in server/lib direcotry and 
when in org.apache.axis.Message class, method setup(xx, xx, xx, xx, xx) is 
trying to cast AttachmentsImpl class to interface Attachments a 
classCastException is thrown.


I think this has to be problem that somehow resulting AttachmentsImpl class 
is loaded by another class loader than one that is using axis client.


How this Axis class loader is intended to work and is there any nice 
solution to circumvent this problem?


Thanks
Toni

_
Express yourself instantly with MSN Messenger! Download today it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

Re: Testcase test.RPCDispatch.TestSerializedRPC

[Davanum Srinivas]

Venkat,

Add "engine.setOption(AxisEngine.PROP_SEND_XSI, Boolean.FALSE);" in
testArgAsDOM, that will get rid of the xsi stuff. Also remove the
extraneous xmlns:foo as it does not occur on the wire...once you do
that it will be better. But do make sure that you use xmlunit stuff to
check the old and new xml instead of a string compare.

thanks,
dims

On 5/29/05, Venkat Reddy <[EMAIL PROTECTED]> wrote:
> The test method testArgAsDOM() expects the response to match the
> request argument. However, the server sends the response with
> parameters qualified with xsi types and namespaces, if the
> serialization context is invoked. For example, setting dirty flag to
> true inside NodeImpl.appendChild() causes the
> SerializationContext.serilaze() to be invoked which forces xsi types
> to be added to all RPCParams (actually RPCParam.serialize() forces it)
> in the request message.  And the test case fails. However, if the
> setDirty flag is not set, then event recorder is replayed, instead of
> invoking serialization context, and no attributes are added, and the
> testcase succeeds.
> 
> This makes me feel that the test case might be incorrect. Can someone
> comment on this?
> 
> -- venkat
> 


-- 
Davanum Srinivas - http://webservices.apache.org/~dims/

[jira] Resolved: (AXIS-2020) wsdl2java does not generate array of wrappers for array of nillable primitives

[Davanum Srinivas (JIRA)]

 [ http://issues.apache.org/jira/browse/AXIS-2020?page=all ]
 
Davanum Srinivas resolved AXIS-2020:


Resolution: Fixed

Applied patch.

thanks,
dims

> wsdl2java does not generate array of wrappers for array of nillable primitives
> --
>
>  Key: AXIS-2020
>  URL: http://issues.apache.org/jira/browse/AXIS-2020
>  Project: Axis
> Type: Bug
>   Components: WSDL processing
> Versions: 1.2
> Reporter: Hans
>  Attachments: 2020.txt, 2020.txt
>
> For the following xsd construct:
> 
> 
>  nillable="true" minOccurs="0" maxOccurs="unbounded"/>
> 
> 
> 
> 
> 
> 
> 
>  nillable="true" minOccurs="0" maxOccurs="unbounded"/>
> 
> 
> 
> 
> wsdl2java from Axis 1.1 generates a Java Class like:
> class StructureType implements Serializable {
> private Integer[] fld1;
> private Integer[] fld2;
> ...
> But in Axis 1.2 the following is generated:
> class StructureType implements Serializable {
> private int[] fld1;
> private int[] fld2;
> ...
> This is incorrect - wrapper types should have been used for fld1 and fld2.
> Also reproducable on the nightly 1.2.1 build of 27 may 2005.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Commented: (AXIS-1990) ClassLoader ClassCastException

[Rene wortelboer (JIRA)]

 [ 
http://issues.apache.org/jira/browse/AXIS-1990?page=comments#action_66536 ]
 
Rene wortelboer commented on AXIS-1990:
---

Has nobody an answer to my problem ??

> ClassLoader ClassCastException
> --
>
>  Key: AXIS-1990
>  URL: http://issues.apache.org/jira/browse/AXIS-1990
>  Project: Axis
> Type: Bug
> Versions: 1.2RC3
>  Environment: Axis 1.2RC3 with j2SDK1.4.2_06, working on windows
> Reporter: Rene wortelboer

>
> Hello,
> I have problems with the classLoader. When i wanna load a class with 
> classLoader it`s working on windows without axis. But when my program runs 
> with axis i get a ClassCastException. 
> here are my files which can run on windows with a main method.. but when an 
> axis service has to do it, it goos wrong !
> the following files are working when i run it !
> 
> public class Globus2Wrapper implements Wrapper {
>   public String middlewaretype;
>   public boolean keeprunning;
>   public boolean keepwaiting;
>   public Globus2Wrapper() {
>   middlewaretype = "Globus2";
>   keeprunning = true;
>   keepwaiting = true;
> System.out.println("I GET THIS MESSAGE");
>   }   
>   public String getMiddlewareType() {
>   return middlewaretype;
>   }
> }
> 
> public interface Wrapper {
>   public String getMiddlewareType();
> }
> --
> import java.net.URLClassLoader;
> import java.net.URL;
> public class WrapperLoader {
>   public static void main(String[] args) {
> System.out.println("Loading Wrapper Plug-In"); 
> 
>try {
>   URL[] url = {new URL("file:/d:/wrappers/")};
>   URLClassLoader loader = new URLClassLoader(url);
>   
>   Class wrapper = Class.forName("Globus2Wrapper", true, 
> loader);
>   Wrapper wrapperInstance = 
> (Wrapper)wrapper.newInstance();
>   System.out.println(wrapperInstance.getMiddlewareType() 
> + " plugin loaded succesfully!");
>   }
>   catch (Exception e) {
>   System.out.println(e.getMessage() + " Exception while 
> loading Plug-in");
>   }
>   
>   }
> }
> -
> How can i make a axis service which can run other files? The constructor of 
> Globus2Wrapper is loaded because i get the system.out !
> Can somebody help me with this?? i don`t think i am the only one with this 
> problem.
> Greets Rene

-- 
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: [Axis2][VOTE]Proposal for Axis2 M2

[Sanjiva Weerawarana]

+1!

Sanjiva.

On Mon, 2005-05-30 at 11:08 +0600, Srinath Perera wrote:
> Hi All;
> Axis2 had lot of progress lately and most of the
> changes decided in the Axis2 F2F has Incorporated,
> I think now it is good time to move on.
> 
> I like to purpose a M2 release on July 7 th, following is the purposed
> improvements to the M2 from M1.
> 
> 1) implementing the Contexts - laying out a hierarchy to handle the 
> information
> 2) implementing the Module Architecture
> 3) implementing the support for real Async that happens over the two
> channel, this complete the support for MEPs
>In-Only MEP
>In-Out
>* Sync/ One Channel
>* Async/One Channel
>* Sync/ two Channel
>* Async/two Channel
> 4) Client API support for #3
> 5) WSDL code generation without data binding
> 6) implementing the Addressing Module
> 7) TCP/HTTP transport support (we might be able to get the SMTP up as well)
> 8) REST Support
> 9) MTOM Support
> 10) Admin Web App
> 11) WSDL2WS, eclipe Plugin/Command line version
> 12) Service Archive Wizard
> 13) Module Archive Wizard
> 14) Samples
> 
> Here is My +1
> 
> Thanks
> Srinath
> 

Re: [Axis2][VOTE]Proposal for Axis2 M2

[Davanum Srinivas]

+1 from me.

-- dims

On 5/30/05, Srinath Perera <[EMAIL PROTECTED]> wrote:
> Hi All;
> Axis2 had lot of progress lately and most of the
> changes decided in the Axis2 F2F has Incorporated,
> I think now it is good time to move on.
> 
> I like to purpose a M2 release on July 7 th, following is the purposed
> improvements to the M2 from M1.
> 
> 1) implementing the Contexts - laying out a hierarchy to handle the 
> information
> 2) implementing the Module Architecture
> 3) implementing the support for real Async that happens over the two
> channel, this complete the support for MEPs
>In-Only MEP
>In-Out
>* Sync/ One Channel
>* Async/One Channel
>* Sync/ two Channel
>* Async/two Channel
> 4) Client API support for #3
> 5) WSDL code generation without data binding
> 6) implementing the Addressing Module
> 7) TCP/HTTP transport support (we might be able to get the SMTP up as well)
> 8) REST Support
> 9) MTOM Support
> 10) Admin Web App
> 11) WSDL2WS, eclipe Plugin/Command line version
> 12) Service Archive Wizard
> 13) Module Archive Wizard
> 14) Samples
> 
> Here is My +1
> 
> Thanks
> Srinath
> 


-- 
Davanum Srinivas - http://webservices.apache.org/~dims/

[jira] Updated: (AXIS-2020) wsdl2java does not generate array of wrappers for array of nillable primitives

[Andrei Iltchenko (JIRA)]

 [ http://issues.apache.org/jira/browse/AXIS-2020?page=all ]

Andrei Iltchenko updated AXIS-2020:
---

Attachment: 2020.txt

A new patch that fixes the problem pointed out by Tom.

> wsdl2java does not generate array of wrappers for array of nillable primitives
> --
>
>  Key: AXIS-2020
>  URL: http://issues.apache.org/jira/browse/AXIS-2020
>  Project: Axis
> Type: Bug
>   Components: WSDL processing
> Versions: 1.2
> Reporter: Hans
>  Attachments: 2020.txt, 2020.txt
>
> For the following xsd construct:
> 
> 
>  nillable="true" minOccurs="0" maxOccurs="unbounded"/>
> 
> 
> 
> 
> 
> 
> 
>  nillable="true" minOccurs="0" maxOccurs="unbounded"/>
> 
> 
> 
> 
> wsdl2java from Axis 1.1 generates a Java Class like:
> class StructureType implements Serializable {
> private Integer[] fld1;
> private Integer[] fld2;
> ...
> But in Axis 1.2 the following is generated:
> class StructureType implements Serializable {
> private int[] fld1;
> private int[] fld2;
> ...
> This is incorrect - wrapper types should have been used for fld1 and fld2.
> Also reproducable on the nightly 1.2.1 build of 27 may 2005.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Commented: (AXIS-2020) wsdl2java does not generate array of wrappers for array of nillable primitives

[Andrei Iltchenko (JIRA)]

 [ 
http://issues.apache.org/jira/browse/AXIS-2020?page=comments#action_66531 ]
 
Andrei Iltchenko commented on AXIS-2020:


Tom,

No, this is not by seeing nillable on that element, it is by seeing 
minOccurs="0" on the 

 
   


which causes the fix to promote name's type to a wrapper class.

The old condition under which we carried out a wrapper promotion in 
JavaBeanWrapper is causing this:
if (elem.getMinOccursIs0() || elem.getNillable() ||
elem.getOptional()) {

to fix it, we'll have to add an additional property to the ElementDecl class 
and change the above condition to verify that the multiplicity of maxOccurs is 
set to exactly one. Fixing this is not more than a few minutes of work, I'll do 
it.

Andrei.

> wsdl2java does not generate array of wrappers for array of nillable primitives
> --
>
>  Key: AXIS-2020
>  URL: http://issues.apache.org/jira/browse/AXIS-2020
>  Project: Axis
> Type: Bug
>   Components: WSDL processing
> Versions: 1.2
> Reporter: Hans
>  Attachments: 2020.txt
>
> For the following xsd construct:
> 
> 
>  nillable="true" minOccurs="0" maxOccurs="unbounded"/>
> 
> 
> 
> 
> 
> 
> 
>  nillable="true" minOccurs="0" maxOccurs="unbounded"/>
> 
> 
> 
> 
> wsdl2java from Axis 1.1 generates a Java Class like:
> class StructureType implements Serializable {
> private Integer[] fld1;
> private Integer[] fld2;
> ...
> But in Axis 1.2 the following is generated:
> class StructureType implements Serializable {
> private int[] fld1;
> private int[] fld2;
> ...
> This is incorrect - wrapper types should have been used for fld1 and fld2.
> Also reproducable on the nightly 1.2.1 build of 27 may 2005.

-- 
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