RE: Is this a bug??

[Parikh,Pratik]

Title: Is this a bug??



I checked my object but it is filled out. Another 
suggestions
 
Thanks,
Parikh, Pratik | Software 
Engineer | Cerner Corporation | (1)-816-201-1298 
| [EMAIL PROTECTED] | www.cerner.com 
 


From: Dovholuk, Clint 
[mailto:[EMAIL PROTECTED] Sent: Tuesday, November 
08, 2005 5:11 PMTo: axis-user@ws.apache.orgCc: 
axis-dev@ws.apache.orgSubject: RE: Is this a 
bug??

sounds like on your client you are instantiating a java 
object but not populating the "required" attribute named "id", sending the 
object to axis, and axis is rejecting the message because the id attribute of 
the class can't be null.
 
use TCPMon (or whatever) and check the message you're 
sending and verify that the id is indeed in the message.


From: Parikh,Pratik 
[mailto:[EMAIL PROTECTED] Sent: Tuesday, November 08, 2005 
6:08 PMTo: axis-user@ws.apache.orgCc: 
axis-dev@ws.apache.orgSubject: Is this a bug??

Hi Everyone, 
    I am 
getting a following exception when I try to send a message thought my client to 
my web service. I looked around for solution and it seems like it is a bug, but 
am not sure can some one help me??? I am also using a MQ Logger where it does 
the same…. Please help me???
java.io.IOException: java.io.IOException: 
java.io.IOException: java.io.IOException: java.io.IOException: Non nillable 
element 'id' is null.
java.io.IOException: java.io.IOException: 
java.io.IOException: java.io.IOException: java.io.IOException: 
java.io.IOException: Non nillable element 'id' is null.
    at 
org.apache.axis.encoding.ser.BeanSerializer.serialize(BeanSerializer.java:275) 
    at 
org.apache.axis.encoding.SerializationContext.serializeActual(SerializationContext.java:1502) 
    at 
org.apache.axis.encoding.SerializationContext.serialize(SerializationContext.java:978) 
    at 
org.apache.axis.encoding.SerializationContext.serialize(SerializationContext.java:799) 
    at 
org.apache.axis.message.RPCParam.serialize(RPCParam.java:208) 
    at 
org.apache.axis.message.RPCElement.outputImpl(RPCElement.java:433) 
    at 
org.apache.axis.message.MessageElement.output(MessageElement.java:1208) 
    at 
org.apache.axis.message.SOAPBody.outputImpl(SOAPBody.java:139) 
    at 
org.apache.axis.message.MessageElement.output(MessageElement.java:1208) 
    at 
org.apache.axis.message.MessageElement.getAsString(MessageElement.java:) 
    at 
com.cerner.endpoint.fsi.axis.handlers.auditing.MQLoggerHandler.invoke(MQLoggerHandler.java:90) 
    at 
org.apache.axis.client.AxisClient.invoke(AxisClient.java:121) 
    at 
org.apache.axis.client.Call.invokeEngine(Call.java:2784) 
    at 
org.apache.axis.client.Call.invoke(Call.java:2767) 
    at 
org.apache.axis.client.Call.invoke(Call.java:2443) 
    at 
org.apache.axis.client.Call.invoke(Call.java:2366) 
    at 
org.apache.axis.client.Call.invoke(Call.java:1812) 
Reference Links  
Thanks, Parikh, 
Pratik 

  
  
CONFIDENTIALITY NOTICEThis 
  message and any included attachmentsare from Cerner Corporation and 
  are intendedonly for the addressee. The informationcontained in 
  this message is confidential andmay constitute inside or non-public 
  informationunder international, federal, or statesecurities laws. 
  Unauthorized forwarding,printing, copying, distribution, or use of 
  suchinformation is strictly prohibited and may beunlawful. If you 
  are not the addressee, pleasepromptly delete this message and notify 
  thesender of the delivery error by e-mail or youmay call Cerner's 
  corporate offices in KansasCity, Missouri, U.S.A at (+1) 
  (816)221-1024. 
  --

Is this a bug??

[Parikh,Pratik]

Title: Is this a bug??






Hi Everyone,


    I am getting a following exception when I try to send a message thought my client to my web service. I looked around for solution and it seems like it is a bug, but am not sure can some one help me??? I am also using a MQ Logger where it does the same…. Please help me???

java.io.IOException: java.io.IOException: java.io.IOException: java.io.IOException: java.io.IOException: Non nillable element 'id' is null.

java.io.IOException: java.io.IOException: java.io.IOException: java.io.IOException: java.io.IOException: java.io.IOException: Non nillable element 'id' is null.

    at org.apache.axis.encoding.ser.BeanSerializer.serialize(BeanSerializer.java:275)

    at org.apache.axis.encoding.SerializationContext.serializeActual(SerializationContext.java:1502)

    at org.apache.axis.encoding.SerializationContext.serialize(SerializationContext.java:978)

    at org.apache.axis.encoding.SerializationContext.serialize(SerializationContext.java:799)

    at org.apache.axis.message.RPCParam.serialize(RPCParam.java:208)

    at org.apache.axis.message.RPCElement.outputImpl(RPCElement.java:433)

    at org.apache.axis.message.MessageElement.output(MessageElement.java:1208)

    at org.apache.axis.message.SOAPBody.outputImpl(SOAPBody.java:139)

    at org.apache.axis.message.MessageElement.output(MessageElement.java:1208)

    at org.apache.axis.message.MessageElement.getAsString(MessageElement.java:)

    at com.cerner.endpoint.fsi.axis.handlers.auditing.MQLoggerHandler.invoke(MQLoggerHandler.java:90)

    at org.apache.axis.client.AxisClient.invoke(AxisClient.java:121)

    at org.apache.axis.client.Call.invokeEngine(Call.java:2784)

    at org.apache.axis.client.Call.invoke(Call.java:2767)

    at org.apache.axis.client.Call.invoke(Call.java:2443)

    at org.apache.axis.client.Call.invoke(Call.java:2366)

    at org.apache.axis.client.Call.invoke(Call.java:1812)


Reference Links





Thanks,

Parikh, Pratik






CONFIDENTIALITY NOTICE

This message and any included attachments
are from Cerner Corporation and are intended
only for the addressee. The information
contained in this message is confidential and
may constitute inside or non-public information
under international, federal, or state
securities laws. Unauthorized forwarding,
printing, copying, distribution, or use of such
information is strictly prohibited and may be
unlawful. If you are not the addressee, please
promptly delete this message and notify the
sender of the delivery error by e-mail or you
may call Cerner's corporate offices in Kansas
City, Missouri, U.S.A at (+1) (816)221-1024.
 --

Re: [Axis2] Schema parsing

[Paul Fremantle]

TomI always like the idea of taking a DOM-like object (how about AXIOM) and making it typed. So instead on doing OMAbstractFactory.createOMElement(), you could do TOMAbstractFactory.createElement(Schema s);
Then as you navigated the tree, you could query the type of a given element and set its value using type-specific setters:if (el.getType()==DOUBLE) el.setDouble(doub);IBM has published a model a bit like this (SDO - 
http://www-128.ibm.com/developerworks/library/specification/j-commonj-sdowmt/index.html) but I've always found this a little heavy. I may have been overly influenced by the implementation rather than the interface. 
I like the idea of Axis2 building a TOM model (Typed Object Model) which then uses OM under the covers. Honestly I'm not sucking up... it was the name that popped into my head.What do you think?Paul
On 11/8/05, Tom Oinn <[EMAIL PROTECTED]> wrote:
Sanjiva Weerawarana wrote:> On Tue, 2005-11-08 at 10:42 -0500, Dan Diephouse wrote:>> There is some schema parsing stuff here in the webservices commons: 
http://svn.apache.org/viewcvs.cgi/webservices/commons/trunk/XmlSchema/ It sounds like you might be going a step beyond just parsing things into>> a schema oject model though?>
> Since we're already using the commons schema (above) in Axis2 (for the> Axis2 data binding stuff), Tom would you guys be able to contribute to> that and help drive that to ultimate success? It doesn't seem to make
> sense to create a parallel universe.Agreed on that, I'll have to take a proper look at the commons schemastuff to see whether I agree that that's the right way to go (a verybrief look suggests it's sane). Basically I can get the QName of the
type that the operation expects and want some way of getting theexpected structure of a document conforming to that type to then drivemy data binding layer. This also involved handling the rather grotty way
the Definition object handles the various imports. Something like thefollowing for usage would be ideal for us :Definition def =  (get Definition here from WSDL4J)SchemaDescriber sd = new SchemaDescriber(def)
...QName operationInputType = SchemaDescription description = sd.getDescriptionFor(operationInputType)and then use 'description' to generate our input ports on the workflowprocessor and the logic required to massage those inputs into the
request document - obviously similar things apply for outputs.Makes sense to drive this off the Definition object as this has alreadydone the work of resolving imported schema (albeit badly) and if you're
running in a WSDL centric world you almost certainly have one lyingaround anyway.Cheers,Tom

Re: [Axis2] Schema parsing

[Eric Johnson]

Tom Oinn wrote:


Hi all,

We're planning to use Axis2 in Taverna to construct SOAP requests, 
probably not using any form of data binding as we have our own and 
just using the send / receive SOAP body functionality.


This means we have to be able to inspect arbitrary WSDL documents and 
determine the input schema in such a way that we can present 
appropriate 'input' and 'output' ports on our workflow components - 
this is slightly non trivial as we can attempt to split up sequence 
elements on input documents into different inputs and suchlike.


Until recently we were using the WSIF library to present a slightly 
friendlier interface on the schema support in WSDL4J but changes in 
the latter have broken this for the time being.


It occurs to me that our requirement is probably not unique, and that 
it might be useful for the more message driven approach in Axis2 to 
have richer schema support for type declarations in WSDL definitions. 
Unless anyone knows of a really good existing lightweight Java model 
for schema (I've looked but no luck) that can be glued into WSDL4J's 
Definition model we're going to write one - the purpose being to 
inspect a WSDL file and, for a given operation, provide enough 
information in a friendly and easy to digest form for a dynamic 
invoker to build a compliant request document / parse a response. Note 
that this is _not_ a databinding layer, just type metadata. Actual 
databinding could obviously be driven off it though.


1) Does this exist?


Xerces 2.7.1 has a schema API:
http://xerces.apache.org/xerces2-j/javadocs/xs/index.html

Also note that DOM 3 supports TypeInfo 
(http://www.w3.org/TR/DOM-Level-3-Core/core.html#TypeInfo), although it 
sounds insufficient to your needs.


I cannot speak to the remaining two questions.

-Eric.

Re: [Axis2] Schema parsing

[Tom Oinn]

Sanjiva Weerawarana wrote:

On Tue, 2005-11-08 at 10:42 -0500, Dan Diephouse wrote:

There is some schema parsing stuff here in the webservices commons:

http://svn.apache.org/viewcvs.cgi/webservices/commons/trunk/XmlSchema/

It sounds like you might be going a step beyond just parsing things into 
a schema oject model though?


Since we're already using the commons schema (above) in Axis2 (for the
Axis2 data binding stuff), Tom would you guys be able to contribute to
that and help drive that to ultimate success? It doesn't seem to make
sense to create a parallel universe.


Agreed on that, I'll have to take a proper look at the commons schema 
stuff to see whether I agree that that's the right way to go (a very 
brief look suggests it's sane). Basically I can get the QName of the 
type that the operation expects and want some way of getting the 
expected structure of a document conforming to that type to then drive 
my data binding layer. This also involved handling the rather grotty way 
the Definition object handles the various imports. Something like the 
following for usage would be ideal for us :


Definition def =  (get Definition here from WSDL4J)
SchemaDescriber sd = new SchemaDescriber(def)

...

QName operationInputType = 
SchemaDescription description = sd.getDescriptionFor(operationInputType)

and then use 'description' to generate our input ports on the workflow 
processor and the logic required to massage those inputs into the 
request document - obviously similar things apply for outputs.


Makes sense to drive this off the Definition object as this has already 
done the work of resolving imported schema (albeit badly) and if you're 
running in a WSDL centric world you almost certainly have one lying 
around anyway.


Cheers,

Tom

[Axis2] REMINDER : Axis IRC chat TOMORROW

[The Axis2 ChatBot]

Hi folks!

This is an automatic reminder that the weekly Axis2 developer chat
will be occurring tomorrow, November 09, at:

7PM PST, 10PM EST, 3AM GMT, 9AM (next day) SLT, 2PM (next day) AEST

The chat takes place on the freenode IRC network, (use server
irc.freenode.net), on channel #apache-axis, and is scheduled to last
one hour, though it may run longer.  Please join us!

Current topics can be found at http://wiki.apache.org/ws/ChatAgenda.

If you need an IRC client for windows, check out http://www.mirc.com,
and http://www.mirc.com/links.html has some links to clients for other
OS's.

Thanks,
--Glen

P.S.  To account for the time difference between the US, Europe, and
Sri Lanka, we toggle the times each week.  NEXT week, the chat
will be at:

5AM PST, 8AM EST, 1PM GMT, 7PM SLT, midnight (next day) AEST

Re: [Axis2] Schema parsing

[Sanjiva Weerawarana]

On Tue, 2005-11-08 at 10:42 -0500, Dan Diephouse wrote:
> There is some schema parsing stuff here in the webservices commons:
> 
> http://svn.apache.org/viewcvs.cgi/webservices/commons/trunk/XmlSchema/
> 
> It sounds like you might be going a step beyond just parsing things into 
> a schema oject model though?

Since we're already using the commons schema (above) in Axis2 (for the
Axis2 data binding stuff), Tom would you guys be able to contribute to
that and help drive that to ultimate success? It doesn't seem to make
sense to create a parallel universe.

> > It occurs to me that our requirement is probably not unique, and that 
> > it might be useful for the more message driven approach in Axis2 to 
> > have richer schema support for type declarations in WSDL definitions. 
> > Unless anyone knows of a really good existing lightweight Java model 
> > for schema (I've looked but no luck) that can be glued into WSDL4J's 
> > Definition model we're going to write one - the purpose being to 
> > inspect a WSDL file and, for a given operation, provide enough 
> > information in a friendly and easy to digest form for a dynamic 
> > invoker to build a compliant request document / parse a response. Note 
> > that this is _not_ a databinding layer, just type metadata. Actual 
> > databinding could obviously be driven off it though.

Big +1 for using a schema model for introspective execution. Again,
please look at commons schema and see whether you can help improve
that ..

Sanjiva.

Re: [Axis2] Schema parsing

[Jim Murphy]

It is targeted as the object model for an XSD editor so its a little
heavy for your needs but the Eclipse XSD library[1] is the most
complete I've seen.

[1] - http://www.eclipse.org/xsd/

Jim Murphy
Mindreef, Inc.

[jira] Commented: (AXIS-1399) axis.types.Time does not deserialise properly in UK/GMT0BST

[Simon Tuckwell (JIRA)]

[ 
http://issues.apache.org/jira/browse/AXIS-1399?page=comments#action_12357042 ] 

Simon Tuckwell commented on AXIS-1399:
--

Hopefully this issue is related!

There are de/serialisation problems with the AXISCPP v1.5 project in the file 
src/soap/xdl/DateTime.cpp.  It determines the current timezone offset by 
running tests using the fixed unix time 0, i.e. 01/01/1970 00:00:00.  In the 
U.K., we were on BST from 1968-1971 (see 
http://en.wikipedia.org/wiki/British_Summer_Time) which changes the result of 
the calculation for us.  The rest of the world doesn't see this problem.

On our systems, the error results in the offset being added once at 
serialisation and again at deserialisation, hence we see a two-hour offset.

I believe a better solution is to use the current time or the external variable 
timezone.


> axis.types.Time does not deserialise properly in UK/GMT0BST
> ---
>
>  Key: AXIS-1399
>  URL: http://issues.apache.org/jira/browse/AXIS-1399
>  Project: Apache Axis
> Type: Bug
>   Components: Deployment / Registries
> Versions: current (nightly)
>  Environment: Java1.4.2 on RH9.0 and Windows XP2 SP2
> Reporter: Steve Loughran

>
> The axis time class does not properly deserialise a time when running in the 
> UK (at least on both systems tested)
> TestDeser2001.testTimeZoneLogicWorks() demonstrates the problem
> The underlying cause appears to be in Time.ParseHoursMinutesSeconds(), where 
> zulu.parse() takes in a string like "12:30:00Z" and, in the UK, returns a 
> timestamp bound to 13:30:00. 
> This is quite a serious difference in expectations, and appears to be 
> happening somewhere we cannot get at. Either it is a TZ issue, a locale 
> issue, a bug in Java1.4.2, or an installation defect common to two systems 
> (and platforms) under my control. 
> I dont have an obvious fix, but I would hesitate to ship with such a deser 
> bug, were time not such a troublespot already. 
> I think the ideal solution may be to abandon the built in simple time parser 
> completely and do it ourselves, the way we do partially anyway, then write 
> some good tests for the new code. Too bad we cannot use java1.4 regexp (or C 
> sscanf()) to do the low-level work.

-- 
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] Schema parsing

[Dan Diephouse]

There is some schema parsing stuff here in the webservices commons:

http://svn.apache.org/viewcvs.cgi/webservices/commons/trunk/XmlSchema/

It sounds like you might be going a step beyond just parsing things into 
a schema oject model though?


Tom Oinn wrote:


Hi all,

We're planning to use Axis2 in Taverna to construct SOAP requests, 
probably not using any form of data binding as we have our own and 
just using the send / receive SOAP body functionality.


This means we have to be able to inspect arbitrary WSDL documents and 
determine the input schema in such a way that we can present 
appropriate 'input' and 'output' ports on our workflow components - 
this is slightly non trivial as we can attempt to split up sequence 
elements on input documents into different inputs and suchlike.


Until recently we were using the WSIF library to present a slightly 
friendlier interface on the schema support in WSDL4J but changes in 
the latter have broken this for the time being.


It occurs to me that our requirement is probably not unique, and that 
it might be useful for the more message driven approach in Axis2 to 
have richer schema support for type declarations in WSDL definitions. 
Unless anyone knows of a really good existing lightweight Java model 
for schema (I've looked but no luck) that can be glued into WSDL4J's 
Definition model we're going to write one - the purpose being to 
inspect a WSDL file and, for a given operation, provide enough 
information in a friendly and easy to digest form for a dynamic 
invoker to build a compliant request document / parse a response. Note 
that this is _not_ a databinding layer, just type metadata. Actual 
databinding could obviously be driven off it though.


1) Does this exist?
2) Would anyone else use it?
3) We're happy to contribute it to Axis2, to any other project or to 
manage it ourselves, any preferences?


Cheers,

Tom




--
Dan Diephouse
Envoi Solutions LLC
http://netzooid.com

Re: [Axis2] Schema parsing

[Tom Oinn]

Davanum Srinivas wrote:

1) Not that i know of
2) Absolutely
3) Axis2 please :)


Those were the answers I was hoping for, I'll start playing around and 
see what I can get going. Current plan is to hack a prototype up as part 
of Taverna's cvs / project module and get comments once I've something 
working, sound reasonable?


Tom

Re: [Axis2] Schema parsing

[Davanum Srinivas]

1) Not that i know of
2) Absolutely
3) Axis2 please :)

-- dims

On 11/8/05, Tom Oinn <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> We're planning to use Axis2 in Taverna to construct SOAP requests,
> probably not using any form of data binding as we have our own and just
> using the send / receive SOAP body functionality.
>
> This means we have to be able to inspect arbitrary WSDL documents and
> determine the input schema in such a way that we can present appropriate
> 'input' and 'output' ports on our workflow components - this is slightly
> non trivial as we can attempt to split up sequence elements on input
> documents into different inputs and suchlike.
>
> Until recently we were using the WSIF library to present a slightly
> friendlier interface on the schema support in WSDL4J but changes in the
> latter have broken this for the time being.
>
> It occurs to me that our requirement is probably not unique, and that it
> might be useful for the more message driven approach in Axis2 to have
> richer schema support for type declarations in WSDL definitions. Unless
> anyone knows of a really good existing lightweight Java model for schema
> (I've looked but no luck) that can be glued into WSDL4J's Definition
> model we're going to write one - the purpose being to inspect a WSDL
> file and, for a given operation, provide enough information in a
> friendly and easy to digest form for a dynamic invoker to build a
> compliant request document / parse a response. Note that this is _not_ a
> databinding layer, just type metadata. Actual databinding could
> obviously be driven off it though.
>
> 1) Does this exist?
> 2) Would anyone else use it?
> 3) We're happy to contribute it to Axis2, to any other project or to
> manage it ourselves, any preferences?
>
> Cheers,
>
> Tom
>


--
Davanum Srinivas : http://wso2.com/blogs/

[Axis2] Schema parsing

[Tom Oinn]

Hi all,

We're planning to use Axis2 in Taverna to construct SOAP requests, 
probably not using any form of data binding as we have our own and just 
using the send / receive SOAP body functionality.


This means we have to be able to inspect arbitrary WSDL documents and 
determine the input schema in such a way that we can present appropriate 
'input' and 'output' ports on our workflow components - this is slightly 
non trivial as we can attempt to split up sequence elements on input 
documents into different inputs and suchlike.


Until recently we were using the WSIF library to present a slightly 
friendlier interface on the schema support in WSDL4J but changes in the 
latter have broken this for the time being.


It occurs to me that our requirement is probably not unique, and that it 
might be useful for the more message driven approach in Axis2 to have 
richer schema support for type declarations in WSDL definitions. Unless 
anyone knows of a really good existing lightweight Java model for schema 
(I've looked but no luck) that can be glued into WSDL4J's Definition 
model we're going to write one - the purpose being to inspect a WSDL 
file and, for a given operation, provide enough information in a 
friendly and easy to digest form for a dynamic invoker to build a 
compliant request document / parse a response. Note that this is _not_ a 
databinding layer, just type metadata. Actual databinding could 
obviously be driven off it though.


1) Does this exist?
2) Would anyone else use it?
3) We're happy to contribute it to Axis2, to any other project or to 
manage it ourselves, any preferences?


Cheers,

Tom

Re: [Axis2] Road Map for next release

[robert burrell donkin]

On 11/6/05, Paul Fremantle <[EMAIL PROTECTED]> wrote:
Ajith / Folks1) Please can we do a release ASAP? The core
changes (like renaming to AxisService) mean that it would be good to
have a stable build with these in, plus the latest ADB.
+1 

IMHO cutting another 0.x release soon seems to be make the most sense.
this gives a chance for ADB to be tested by users in the wild as well
as continuing the momentum.
2) The obvious list of services to support are:
All of Google, Amazon, Yahoo, XMethods core services
(stockquote, currency, etc). I would like to see some from strikeiron.
Any WSDL interop tests. Axis1 samples???That would be a good starter set. 
good plan but IMHO not a reason to hold up another 0.x release

from reading this thread IMHO the main concern seems to be about
managing the expectation of users about the functionality of ADB in
this release. perhaps we could a few words to the release notes
explaining this.

 - robert

[jira] Created: (AXIS-2294) WSDL2JAVA ignores attributes in certain schema structures

[Marko Sormunen (JIRA)]

WSDL2JAVA ignores attributes in certain schema structures
-

 Key: AXIS-2294
 URL: http://issues.apache.org/jira/browse/AXIS-2294
 Project: Apache Axis
Type: Bug
  Components: WSDL processing  
Versions: 1.2, 1.2.1, 1.3
 Environment: JDK 1.4.1
JDK 1.5
Reporter: Marko Sormunen


WSDL2JAVA seems to ignore attributes in certain schema structures. For example:


http://schemas.xmlsoap.org/wsdl/";
 xmlns:impl="urn:plugit:CommonServices/IdentifyProfile"
 xmlns:type="urn:plugit:CommonServices/type"
 xmlns:excep="urn:plugit:CommonServices/exception"
 xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/";
 name="IdentifyProfile">
 
  http://www.w3.org/2001/XMLSchema";>
   

 
  
  
  
  
 

   
   

 
  
  
 

   
  

  http://www.w3.org/2001/XMLSchema";>
   

 
 
 
 
 


   

   

 

   
   

 
 


   

   

 


   
  
 

 
  
 
 
  
 

(The rest of WSDL snipped)

The problem is that Candidate is not generated as a class, even though it 
should contain the id attribute. Instead a CandidateHolder class like this is 
generated:

public final class CandidateArrayHolder implements javax.xml.rpc.holders.Holder 
{
public org.plugit.soap.type.Trait[][] value;

public CandidateArrayHolder() {
}

public CandidateArrayHolder(org.plugit.soap.type.Trait[][] value) {
this.value = value;
}

}

When it should generate this:

public final class CandidateArrayHolder implements javax.xml.rpc.holders.Holder 
{
public org.plugit.soap.type.Candidate[] value;

public CandidateArrayHolder() {
}

public CandidateArrayHolder(org.plugit.soap.type.Candidate[] value) {
this.value = value;
}

}

and of course a Candidate class with a Trait-array and id property. This worked 
correctly with Axis 1.2RC3 , but not in newer versions..


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