Russell Butek
[EMAIL PROTECTED]
Please respond to [EMAIL PROTECTED]
To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
cc:
Subject: RE: Axis beta 3 feedbacks: bugs, improvement, ....
I believe the problem there (in the Beans spec) was what to do about "holes" caused by the set-by-index operation:
bean.setArray(new Object[3] { ..., ..., ... });
bean.setArray(12, new Object()); // Do we grow to 12 and leave 8 holes of null Object refs?
That said, do you have to be 100% Beans compliant? Is there something in the JAXRPC or JAXM specs that require it?
Ted Neward
Architect, UCDavis Account & Financial Services
http://www.javageeks.com
http://www.clrgeeks.com
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Friday, July 12, 2002 11:25
To: [EMAIL PROTECTED]
Subject: Re: Axis beta 3 feedbacks: bugs, improvement, ....
For the setXXX(index, element) we USED to grow the array, if necessary. But we discovered that was wrong. According to the JavaBeans spec, section 7.2, the indexed setter should not establish or grow the array. So we complied. What a bummer.
Russell Butek
[EMAIL PROTECTED]
Please respond to [EMAIL PROTECTED]
To: axis <[EMAIL PROTECTED]>
cc:
Subject: Axis beta 3 feedbacks: bugs, improvement, ....
We have succesfully migrated from beta 2 to beta 3. But this was not as
smooth as it should have been, see my comments bellow:
- Our WSDLs contains complex types with some elements defined with
maxOccurs="unbounded". This is naturally turned into an array by the
WSDL2Java. There are 2 setXXX methods, one taking an initialized array
and another one taking 2 parameters: index, element.
In beta 2 the second method (index + element) was checking that the
array was not null, now the generated code skips this checking which
leads to a NullPointerException (if this method is being used).
Immediate workaround: use the first setXXX method passing an initialized
array
real workaround: fix the generated code. A good apparoach would be to
use an ArrayList instead of an array (number of elements not known all
the time).
- I am glad that the ServiceLifeCycle interface is know being picked up
when the service is created. The problem is that the context is null ???
Another problem is that the type of the context (MessageContext) is the
wrong type !! The jax-rpc specification talks about a
ServletEndpointContext in the case of a servlet based web service (page
80 of the spec). Then a method getMessageContext within this
ServletEndpointContext returns the targeted context for invocation.
Immediate workaround: Should I still use the "ugly" code to get to the
context, ServletContext which is described in the mailing list ? (using
a static object, ...) ?
real workaround: There are 2 problems to fix: one immediate: the context
is null, the other one would be implementing the ServletEndpointContext,
but I understand that there are many things to work on Axis and that
might not have been the priority.
- I have switched from calling the WSDL2java within my ant build file
using the java task to now using the axis ant tasks defined in the test
directory. I have not seen any problems using these, and it is much
faster (you do not have to fork an extra jvm, ....)
Otherwise, I have not seen any other major bugs, all our unit tests are
working fine. Axis is great and performances are amazing.
Olivier
