You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Tom Jordahl <to...@macromedia.com> on 2005/06/03 19:06:44 UTC

Current Axis problems and questions about the future

FYI

I am currently debugging the following problems in an attempt to resolve
all the issues my local product regression tests have uncovered in 1.2.

1. WSDL2Java emits the wrapper types for Doc/lit wrapped services, even
though we explicitly try to prevent this.
Somewhere in the last few years of the 1.2 timeframe this got broken.
For large services that are wrapped, this creates a lot of junk.  It
also means that the JavaDeployWriter emits a slew of useless type
mappings. Taking some responsibility for the incredible complexity of
our SymbolTable implementation, this is code that I wrote.
Unfortunately I can't take much responsibility for the hacking that the
code has undergone since 1.0/1.1. :-(

2. Two dimensional Object arrays (Object[][]) in a JavaBean do not even
come close to getting serialized correctly in doc/lit mode.
The metadata in the Bean only describes a single dimension array, and
that is how it gets serialized.

3. When trying to deploy a service to test the above problems, all those
useless typemapping in the deploy.wsdd cause Axis to fail to generate
WSDL for the service. It appears to be due to anonymous types (those
pesky ">foo" QNames) misleading the WSDL generator in to doing the wrong
thing.


I believe most, if not all of the above problems have been logged as
bugs by users.  I hope to be able to spend a few days and unravel at
least some of this.  Any help is welcome.

A meta note: 
We as a group are going to need to apply serious resources to certain
areas of Axis moving forward.  In particular, our TypeMapping system
needs to be scrapped, and the Array and Bean serializers should probably
also be thrown out and rewritten.  I am frustrated in that I (like most)
have work responsibilities that prevent me from spending more that a few
hours/days on Axis at any time, even though we depend on Axis as our
products web service engine.  Do we just keep adding band aids to Axis
1.x and wait for Axis 2 to take over the burden?  Do we try to drum up
support for a concerted effort at rewriting our WSDL processing, type
mapping and certain serialization implementations?  Even though we have
an active user community that submits many patches, is this the very
thing that is doing more harm than good to the source, as the unified
whole is lost in the little changes?

Your thoughts are welcome.

--
Tom Jordahl
Macromedia Server Development


Re: Current Axis problems and questions about the future

Posted by Davanum Srinivas <da...@gmail.com>.
Tom,

I can take responibility for the problems :) Am actually happy that it
is a handful of problems...lessons learned:
- Put out more releases, more often.
- Make everyone run their test suites more often.
- Add *MORE* test cases.
- When fixing a problem, add a test case first.

I don't care too much about "doing more harm than good to the source",
If Axis does not get the work done, folks will move on and find
alternatives. If folks who wrote it originally are not around, active
users are not going to sit around twiddling thumbs. So, i am all for
folks taking a stab at fixing their own problems. Also, Yes, i'd
rather spend concerted effort on Axis2. Since it is a rewrite anyway.
BUT 1.X is not going to go away anytime soon. There are just too many
people depending on it.

Thanks,
dims

On 6/3/05, Tom Jordahl <to...@macromedia.com> wrote:
>  
> 
> FYI 
> 
> I am currently debugging the following problems in an attempt to resolve all
> the issues my local product regression tests have uncovered in 1.2. 
> 
> 1. WSDL2Java emits the wrapper types for Doc/lit wrapped services, even
> though we explicitly try to prevent this. 
> 
> Somewhere in the last few years of the 1.2 timeframe this got broken.  For
> large services that are wrapped, this creates a lot of junk.  It also means
> that the JavaDeployWriter emits a slew of useless type mappings. Taking some
> responsibility for the incredible complexity of our SymbolTable
> implementation, this is code that I wrote.  Unfortunately I can't take much
> responsibility for the hacking that the code has undergone since 1.0/1.1. L 
> 
> 2. Two dimensional Object arrays (Object[][]) in a JavaBean do not even come
> close to getting serialized correctly in doc/lit mode. 
> 
> The metadata in the Bean only describes a single dimension array, and that
> is how it gets serialized. 
> 
> 3. When trying to deploy a service to test the above problems, all those
> useless typemapping in the deploy.wsdd cause Axis to fail to generate WSDL
> for the service. It appears to be due to anonymous types (those pesky ">foo"
> QNames) misleading the WSDL generator in to doing the wrong thing. 
>  
> 
> I believe most, if not all of the above problems have been logged as bugs by
> users.  I hope to be able to spend a few days and unravel at least some of
> this.  Any help is welcome. 
> 
> A meta note: 
> 
> We as a group are going to need to apply serious resources to certain areas
> of Axis moving forward.  In particular, our TypeMapping system needs to be
> scrapped, and the Array and Bean serializers should probably also be thrown
> out and rewritten.  I am frustrated in that I (like most) have work
> responsibilities that prevent me from spending more that a few hours/days on
> Axis at any time, even though we depend on Axis as our products web service
> engine.  Do we just keep adding band aids to Axis 1.x and wait for Axis 2 to
> take over the burden?  Do we try to drum up support for a concerted effort
> at rewriting our WSDL processing, type mapping and certain serialization
> implementations?  Even though we have an active user community that submits
> many patches, is this the very thing that is doing more harm than good to
> the source, as the unified whole is lost in the little changes? 
> 
> Your thoughts are welcome. 
> 
> -- 
> 
> Tom Jordahl 
> 
> Macromedia Server Development 
> 
>  


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