You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-user@axis.apache.org by Christian Seiler <cs...@interes.com> on 2005/11/01 09:26:22 UTC
AW: I give up (let's change the subject line, but try to be constructive)
I really hate to do that :-) but
*ME TOO*
Christian Seiler
InteRes GmbH
Rheinstrasse 44-46
64283 Darmstadt
Phone +496151 30740 18
Fax +496151 30740 11
-----Ursprüngliche Nachricht-----
Von: Paul Grillo [mailto:Paul.Grillo@trivininc.com]
Gesendet: Montag, 31. Oktober 2005 19:40
An: axis-user@ws.apache.org
Betreff: RE: I give up (let's change the subject line, but try to be
constructive)
If you found a way to use classes generated by XMLBeans in Axis
Client/Server, I would certainly be interested in and very much
appreciate anything you could send me. And anything needed to ensure the
client generated stubs work as well.
-----Original Message-----
From: Nathaniel G. Auvil [mailto:nathaniel_auvil@yahoo.com]
Sent: Monday, October 31, 2005 12:57 PM
To: axis-user@ws.apache.org
Subject: RE: I give up (let's change the subject line, but try to be
constructive)
We are using XMLBeans with Axis. I found a serializer and deserializer
on a website some time
ago. I can email them to you if you would like. I had to add a custom
ant task to modify the
server-config.wsdd to change to the XMLBeans serializer but it was no
big deal.
--- Paul Grillo <Pa...@trivininc.com> wrote:
> Let me be more specific about the 2 areas that have troubled me since
I
> was second in line of kicking off this long thread. I provide this as
> input and food for thought.
>
> As I mentioned previously, I have no axe to grind. I'm fairly well
aware
> of tradeoffs with open source and no open source. We spend tons of
> money on oracle and bea support, such as it is. There are no
guarantees
> of help when you need it whether you pay for it or not. I also would
> never blame or take Axis or any product like that to task for the fact
> that WS_Profile and SOAP is a pain. It is a pain - but it has strong
> advantages. REST, for example, is a good solution for some problems.
> REST assured, however, that it could not possibly solve the problem I
> had to solve which was to communicate with a .NET vendor and swap SOAP
> messages of which certain elements were signed and encrypted and
> depended on ws-addressing etc. AXIS 1.2/WSS4J solved this problem for
> me very nicely, and I thank them.
>
> I guess I would say I'm not giving up, I may (hope to) return. But
I've
> got to solve a few of my own issues.
>
> Okay, the 2 areas I would like to zero in on
>
>
> 1) AXIS 1 or AXIS2? 2 different projects? any Migration? Have I been
> left to solve it for myself?
>
> The move from Axis 1 to Axis 2 and the way it feels is a little
> disconcerting. It seems to me (and has been pointed out) that most
> energy is going into Axis2. Fine, but most deployments have and are
> running in Axis 1. What bothers me is the feeling that I get that
Axis2
> is the replacement, and yet there doesn't seem to be any easy
migration.
> If you look at the migration blurb in Axis 2, it spends time telling
me
> why Axis2 is better, but not how to migrate. It almost leaves me with
> this feeling that I made a mistake going with Axis 1. I ask myself
are
> these the same developes? Axis 1 and 2? Are they competing? So I'm
> left with the feeling that I'm getting little help on Axis 1 because
the
> efforts are toward Axis 2. And when I read Axis 2 doc, all I'm
hearing
> is it is so much better than Axis 1. It's tough to swallow since I'm
> sitting on at least one deployment of Axis 1. Am I now being told
that
> I made a mistake? support is dwindling? move to Axis 2? Make all the
> appropriate changes?
>
> This plays into the overall uneasiness. You look for a commitment
from
> the producers/developers to the users. Migration tools for version to
> version. Make sure users have not been left hanging. Believe me it
> makes you think twice when you choose any technology, open source or
> not. I've been through this sort of thing with products that I've
spent
> a lot of money on. I've worked with open source projects that were
> absolutely committed to the users from version to version with respect
> to backwards compatibility.
>
>
> 2) Please let me decide what technology I use for
> serialization/deserialization, not the Web Services Framework.
> I am in "total" agreement with Guy's # 3 suggestion attached below.
> Then next issue is Serialization independence. I really need
> serialization independence. It cannot be chosen or generated for me
by
> the actual Web Services Framework I chooose, but should use mine.
>
> My job within my company is to provide basic services to a number of
> development teams, each of which provide solutions in a totally
> different domain. I provide them with interfaces that enable our back
> office services in any number of ways. These groups don't even really
> know if or what network is involved.
>
> In the context of Web Services, these groups only interface will be
> related to the generated WSDL/XSD Objects. Given a request object
they
> will gather the info from that object, call upon legacy systems or
> whatever is needed to fulfill the request, then populate the response
> object. I will provide my own internal service factory from which I
can
> call upon these back office services and speak the language of our
> XSD/Schema objects. To them, they are java objects, pure and simple.
>
> What this means is these objects must not change. Translated, we need
> to settle on a stable XSD schema and most importantly a stable set of
> generated java objects.
>
> so ... # 3 is of utmost importance. I do NOT want to tie this
> dependency to my choice of AXIS or AXIS2 or whatever. I need the
ability
> to use XMLBeans, or Castor, or I name it (not the SOAP framework) to
> work with the framework.
>
> Now at this very moment I'm looking at using XMLBeans. I see no easy
> integration of this with either AXIS or AXIS2. AXIS 2 is moving in
that
> direction, but does not have support for externally generated (using
> scomp) XMLBeans. so for me ...
> My "only" salvation here is serialization independence. Because with
> independence, I can even roll my own. Then when/if Axis 2 supports my
> chosen serialization objects I can trash my home grown solution, use
> Axis 2, and there are no bumps in the road.
>
>
>
> so .... I couldn't agree more with Guy's #3 point below..
>
>
> A
>
>
> -----Original Message-----
> From: Guy Rixon [mailto:gtr@ast.cam.ac.uk]
> Sent: Monday, October 31, 2005 3:22 AM
> To: axis-user@ws.apache.org
> Cc: axis-dev@ws.apache.org
> Subject: RE: I give up
>
> Three suggestions for improving the Axis experience:
>
> 1. More effort to documentation. The Axis 1 documents aren't yet
> sufficient to
> deal with use in a real project.
>
> Just expanding some of the Javadoc comments would help. In fact,
> providing or
> expanding the package.html files would be good, and maybe more
palatable
> than
> reworking the xdocs. :)
>
> If someone did want to work on the xdocs, the reference guide to WSDD
> would be
> a good place to start.
>
> 2. Improve the error reports. Currently, when Axis goes worng (more
> commonly,
> when it is misconfigured) the error reporting isn't sufficient to
> diagnose the
> problem. Alternatively, provide tools that can inspect the
configuration
> of a
> deployed service and explain what's wrong.
>
> 3. Provide an alternative to the current WSDL2Java to write stubs that
> use an
> external seralizer/deserializer mechanism (Castor, XMLbeans, JAXB). In
> my
> experience with Axis, the stubs are the valuable part and the Axis
> XML-mapping
> is redundant (duplicates mapping code we already have) unstable (bean
> classes incompatible between Axis versions) and fragile. Hence the
move
> to
> XMLBeans in Axis 2, I guess...but maybe Axis 1 could be cleaned up
too?
>
> What I have in mind is a stub-generation tool that takes a WSDL
> contract, a
> Java interface defining the API of the stub and a file of
class/element
> mappings. It would generate stubs for which the API is entirely
defined
> by the
> author of the client, and which can be rebuild to the same contract in
> the
> next version of Axis 1; WSDL2Java can't provide this stability of
> interface.
>
> You could provide a separate tool for creating data-binding beans if
one
> were
> needed. This could generate the beans that WSDL2Java currently
produces.
> It
> would also need to generate the class/element mapping-file.
>
> Guy Rixon gtr@ast.cam.ac.uk
> Institute of Astronomy Tel: +44-1223-337542
> Madingley Road, Cambridge, UK, CB3 0HA Fax:
+44-1223-337523
>
__________________________________
Start your day with Yahoo! - Make it your home page!
http://www.yahoo.com/r/hs
Re: AW: I give up (let's change the subject line, but try to be constructive)
Posted by "Nathaniel G. Auvil" <na...@yahoo.com>.
here is the link to a war i found. I did not write the code, i am simply using it.
http://superflaco.com/Beehive/java1dot4XBeanSample.war
--- Bolke de Bruin <bd...@aub.nl> wrote:
> Or - if possible - to this list. Or in a JIRA-doc issue (don't know if
> that exists), so someone is able to create some documentation for it?
>
> Kind regards,
>
> B. de Bruin
>
> Christian Seiler wrote:
> > I really hate to do that :-) but
> >
> > *ME TOO*
> >
> > Christian Seiler
> >
> > InteRes GmbH
> > Rheinstrasse 44-46
> > 64283 Darmstadt
> > Phone +496151 30740 18
> > Fax +496151 30740 11
> >
> >
> > -----Ursprüngliche Nachricht-----
> > Von: Paul Grillo [mailto:Paul.Grillo@trivininc.com]
> > Gesendet: Montag, 31. Oktober 2005 19:40
> > An: axis-user@ws.apache.org
> > Betreff: RE: I give up (let's change the subject line, but try to be
> > constructive)
> >
> > If you found a way to use classes generated by XMLBeans in Axis
> > Client/Server, I would certainly be interested in and very much
> > appreciate anything you could send me. And anything needed to ensure the
> > client generated stubs work as well.
> >
> >
> >
> >
> >
> > -----Original Message-----
> > From: Nathaniel G. Auvil [mailto:nathaniel_auvil@yahoo.com]
> > Sent: Monday, October 31, 2005 12:57 PM
> > To: axis-user@ws.apache.org
> > Subject: RE: I give up (let's change the subject line, but try to be
> > constructive)
> >
> >
> > We are using XMLBeans with Axis. I found a serializer and deserializer
> > on a website some time
> > ago. I can email them to you if you would like. I had to add a custom
> > ant task to modify the
> > server-config.wsdd to change to the XMLBeans serializer but it was no
> > big deal.
> >
> >
> >
> > --- Paul Grillo <Pa...@trivininc.com> wrote:
> >
> >> Let me be more specific about the 2 areas that have troubled me since
> > I
> >> was second in line of kicking off this long thread. I provide this as
> >> input and food for thought.
> >>
> >> As I mentioned previously, I have no axe to grind. I'm fairly well
> > aware
> >> of tradeoffs with open source and no open source. We spend tons of
> >> money on oracle and bea support, such as it is. There are no
> > guarantees
> >> of help when you need it whether you pay for it or not. I also would
> >> never blame or take Axis or any product like that to task for the fact
> >> that WS_Profile and SOAP is a pain. It is a pain - but it has strong
> >> advantages. REST, for example, is a good solution for some problems.
> >> REST assured, however, that it could not possibly solve the problem I
> >> had to solve which was to communicate with a .NET vendor and swap SOAP
> >> messages of which certain elements were signed and encrypted and
> >> depended on ws-addressing etc. AXIS 1.2/WSS4J solved this problem for
> >> me very nicely, and I thank them.
> >>
> >> I guess I would say I'm not giving up, I may (hope to) return. But
> > I've
> >> got to solve a few of my own issues.
> >>
> >> Okay, the 2 areas I would like to zero in on
> >>
> >>
> >> 1) AXIS 1 or AXIS2? 2 different projects? any Migration? Have I been
> >> left to solve it for myself?
> >>
> >> The move from Axis 1 to Axis 2 and the way it feels is a little
> >> disconcerting. It seems to me (and has been pointed out) that most
> >> energy is going into Axis2. Fine, but most deployments have and are
> >> running in Axis 1. What bothers me is the feeling that I get that
> > Axis2
> >> is the replacement, and yet there doesn't seem to be any easy
> > migration.
> >> If you look at the migration blurb in Axis 2, it spends time telling
> > me
> >> why Axis2 is better, but not how to migrate. It almost leaves me with
> >> this feeling that I made a mistake going with Axis 1. I ask myself
> > are
> >> these the same developes? Axis 1 and 2? Are they competing? So I'm
> >> left with the feeling that I'm getting little help on Axis 1 because
> > the
> >> efforts are toward Axis 2. And when I read Axis 2 doc, all I'm
> > hearing
> >> is it is so much better than Axis 1. It's tough to swallow since I'm
> >> sitting on at least one deployment of Axis 1. Am I now being told
> > that
> >> I made a mistake? support is dwindling? move to Axis 2? Make all the
> >> appropriate changes?
> >>
> >> This plays into the overall uneasiness. You look for a commitment
> > from
> >> the producers/developers to the users. Migration tools for version to
> >> version. Make sure users have not been left hanging. Believe me it
> >> makes you think twice when you choose any technology, open source or
> >> not. I've been through this sort of thing with products that I've
> > spent
> >> a lot of money on. I've worked with open source projects that were
> >> absolutely committed to the users from version to version with respect
> >> to backwards compatibility.
> >>
> >>
> >> 2) Please let me decide what technology I use for
> >> serialization/deserialization, not the Web Services Framework.
> >> I am in "total" agreement with Guy's # 3 suggestion attached below.
> >> Then next issue is Serialization independence. I really need
> >> serialization independence. It cannot be chosen or generated for me
> > by
> >> the actual Web Services Framework I chooose, but should use mine.
> >>
> >> My job within my company is to provide basic services to a number of
> >> development teams, each of which provide solutions in a totally
> >> different domain. I provide them with interfaces that enable our back
> >> office services in any number of ways. These groups don't even really
> >> know if or what network is involved.
> >>
> >> In the context of Web Services, these groups only interface will be
> >> related to the generated WSDL/XSD Objects. Given a request object
> > they
> >> will gather the info from that object, call upon legacy systems or
> >> whatever is needed to fulfill the request, then populate the response
> >> object. I will provide my own internal service factory from which I
> > can
> >> call upon these back office services and speak the language of our
> >> XSD/Schema objects. To them, they are java objects, pure and simple.
> >>
> >> What this means is these objects must not change. Translated, we need
> >> to settle on a stable XSD schema and most importantly a stable set of
> >> generated java objects.
> >>
> >> so ... # 3 is of utmost importance. I do NOT want to tie this
> >> dependency to my choice of AXIS or AXIS2 or whatever. I need the
> > ability
> >> to use XMLBeans, or Castor, or I name it (not the SOAP framework) to
> >> work with the framework.
> >>
> >> Now at this very moment I'm looking at using XMLBeans. I see no easy
> >> integration of this with either AXIS or AXIS2. AXIS 2 is moving in
> > that
> >> direction, but does not have support for externally generated (using
> >> scomp) XMLBeans. so for me ...
> >> My "only" salvation here is serialization independence. Because with
> >> independence, I can even roll my own. Then when/if Axis 2 supports my
> >> chosen serialization objects I can trash my home grown solution, use
> >> Axis 2, and there are no bumps in the road.
> >>
> >>
> >>
> >> so .... I couldn't agree more with Guy's #3 point below..
> >>
> >>
> >> A
> >>
> >>
> >> -----Original Message-----
> >> From: Guy Rixon [mailto:gtr@ast.cam.ac.uk]
> >> Sent: Monday, October 31, 2005 3:22 AM
> >> To: axis-user@ws.apache.org
> >> Cc: axis-dev@ws.apache.org
> >> Subject: RE: I give up
> >>
> >> Three suggestions for improving the Axis experience:
> >>
> >> 1. More effort to documentation. The Axis 1 documents aren't yet
> >> sufficient to
> >> deal with use in a real project.
> >>
> >> Just expanding some of the Javadoc comments would help. In fact,
> >> providing or
> >> expanding the package.html files would be good, and maybe more
> > palatable
> >> than
> >> reworking the xdocs. :)
> >>
> >> If someone did want to work on the xdocs, the reference guide to WSDD
> >> would be
> >> a good place to start.
> >>
> >> 2. Improve the error reports. Currently, when Axis goes worng (more
> >> commonly,
> >> when it is misconfigured) the error reporting isn't sufficient to
> >> diagnose the
> >> problem. Alternatively, provide tools that can inspect the
> > configuration
> >> of a
> >> deployed service and explain what's wrong.
> >>
> >> 3. Provide an alternative to the current WSDL2Java to write stubs that
> >> use an
> >> external seralizer/deserializer mechanism (Castor, XMLbeans, JAXB). In
> >> my
> >> experience with Axis, the stubs are the valuable part and the Axis
> >> XML-mapping
> >> is redundant (duplicates mapping code we already have) unstable (bean
> >> classes incompatible between Axis versions) and fragile. Hence the
> > move
> >> to
> >> XMLBeans in Axis 2, I guess...but maybe Axis 1 could be cleaned up
> > too?
> >> What I have in mind is a stub-generation tool that takes a WSDL
> >> contract, a
> >> Java interface defining the API of the stub and a file of
> > class/element
> >> mappings. It would generate stubs for which the API is entirely
> > defined
> >> by the
> >> author of the client, and which can be rebuild to the same contract in
> >> the
> >> next version of Axis 1; WSDL2Java can't provide this stability of
> >> interface.
> >>
> >> You could provide a separate tool for creating data-binding beans if
> > one
> >> were
> >> needed. This could generate the beans that WSDL2Java currently
> > produces.
> >> It
> >> would also need to generate the class/element mapping-file.
> >>
> >> Guy Rixon gtr@ast.cam.ac.uk
> >> Institute of Astronomy Tel: +44-1223-337542
> >> Madingley Road, Cambridge, UK, CB3 0HA Fax:
> > +44-1223-337523
> >
> >
> >
> >
> > __________________________________
> > Start your day with Yahoo! - Make it your home page!
> > http://www.yahoo.com/r/hs
> >
>
>
__________________________________
Yahoo! FareChase: Search multiple travel sites in one click.
http://farechase.yahoo.com
Re: AW: I give up (let's change the subject line, but try to be
constructive)
Posted by Bolke de Bruin <bd...@aub.nl>.
Or - if possible - to this list. Or in a JIRA-doc issue (don't know if
that exists), so someone is able to create some documentation for it?
Kind regards,
B. de Bruin
Christian Seiler wrote:
> I really hate to do that :-) but
>
> *ME TOO*
>
> Christian Seiler
>
> InteRes GmbH
> Rheinstrasse 44-46
> 64283 Darmstadt
> Phone +496151 30740 18
> Fax +496151 30740 11
>
>
> -----Ursprüngliche Nachricht-----
> Von: Paul Grillo [mailto:Paul.Grillo@trivininc.com]
> Gesendet: Montag, 31. Oktober 2005 19:40
> An: axis-user@ws.apache.org
> Betreff: RE: I give up (let's change the subject line, but try to be
> constructive)
>
> If you found a way to use classes generated by XMLBeans in Axis
> Client/Server, I would certainly be interested in and very much
> appreciate anything you could send me. And anything needed to ensure the
> client generated stubs work as well.
>
>
>
>
>
> -----Original Message-----
> From: Nathaniel G. Auvil [mailto:nathaniel_auvil@yahoo.com]
> Sent: Monday, October 31, 2005 12:57 PM
> To: axis-user@ws.apache.org
> Subject: RE: I give up (let's change the subject line, but try to be
> constructive)
>
>
> We are using XMLBeans with Axis. I found a serializer and deserializer
> on a website some time
> ago. I can email them to you if you would like. I had to add a custom
> ant task to modify the
> server-config.wsdd to change to the XMLBeans serializer but it was no
> big deal.
>
>
>
> --- Paul Grillo <Pa...@trivininc.com> wrote:
>
>> Let me be more specific about the 2 areas that have troubled me since
> I
>> was second in line of kicking off this long thread. I provide this as
>> input and food for thought.
>>
>> As I mentioned previously, I have no axe to grind. I'm fairly well
> aware
>> of tradeoffs with open source and no open source. We spend tons of
>> money on oracle and bea support, such as it is. There are no
> guarantees
>> of help when you need it whether you pay for it or not. I also would
>> never blame or take Axis or any product like that to task for the fact
>> that WS_Profile and SOAP is a pain. It is a pain - but it has strong
>> advantages. REST, for example, is a good solution for some problems.
>> REST assured, however, that it could not possibly solve the problem I
>> had to solve which was to communicate with a .NET vendor and swap SOAP
>> messages of which certain elements were signed and encrypted and
>> depended on ws-addressing etc. AXIS 1.2/WSS4J solved this problem for
>> me very nicely, and I thank them.
>>
>> I guess I would say I'm not giving up, I may (hope to) return. But
> I've
>> got to solve a few of my own issues.
>>
>> Okay, the 2 areas I would like to zero in on
>>
>>
>> 1) AXIS 1 or AXIS2? 2 different projects? any Migration? Have I been
>> left to solve it for myself?
>>
>> The move from Axis 1 to Axis 2 and the way it feels is a little
>> disconcerting. It seems to me (and has been pointed out) that most
>> energy is going into Axis2. Fine, but most deployments have and are
>> running in Axis 1. What bothers me is the feeling that I get that
> Axis2
>> is the replacement, and yet there doesn't seem to be any easy
> migration.
>> If you look at the migration blurb in Axis 2, it spends time telling
> me
>> why Axis2 is better, but not how to migrate. It almost leaves me with
>> this feeling that I made a mistake going with Axis 1. I ask myself
> are
>> these the same developes? Axis 1 and 2? Are they competing? So I'm
>> left with the feeling that I'm getting little help on Axis 1 because
> the
>> efforts are toward Axis 2. And when I read Axis 2 doc, all I'm
> hearing
>> is it is so much better than Axis 1. It's tough to swallow since I'm
>> sitting on at least one deployment of Axis 1. Am I now being told
> that
>> I made a mistake? support is dwindling? move to Axis 2? Make all the
>> appropriate changes?
>>
>> This plays into the overall uneasiness. You look for a commitment
> from
>> the producers/developers to the users. Migration tools for version to
>> version. Make sure users have not been left hanging. Believe me it
>> makes you think twice when you choose any technology, open source or
>> not. I've been through this sort of thing with products that I've
> spent
>> a lot of money on. I've worked with open source projects that were
>> absolutely committed to the users from version to version with respect
>> to backwards compatibility.
>>
>>
>> 2) Please let me decide what technology I use for
>> serialization/deserialization, not the Web Services Framework.
>> I am in "total" agreement with Guy's # 3 suggestion attached below.
>> Then next issue is Serialization independence. I really need
>> serialization independence. It cannot be chosen or generated for me
> by
>> the actual Web Services Framework I chooose, but should use mine.
>>
>> My job within my company is to provide basic services to a number of
>> development teams, each of which provide solutions in a totally
>> different domain. I provide them with interfaces that enable our back
>> office services in any number of ways. These groups don't even really
>> know if or what network is involved.
>>
>> In the context of Web Services, these groups only interface will be
>> related to the generated WSDL/XSD Objects. Given a request object
> they
>> will gather the info from that object, call upon legacy systems or
>> whatever is needed to fulfill the request, then populate the response
>> object. I will provide my own internal service factory from which I
> can
>> call upon these back office services and speak the language of our
>> XSD/Schema objects. To them, they are java objects, pure and simple.
>>
>> What this means is these objects must not change. Translated, we need
>> to settle on a stable XSD schema and most importantly a stable set of
>> generated java objects.
>>
>> so ... # 3 is of utmost importance. I do NOT want to tie this
>> dependency to my choice of AXIS or AXIS2 or whatever. I need the
> ability
>> to use XMLBeans, or Castor, or I name it (not the SOAP framework) to
>> work with the framework.
>>
>> Now at this very moment I'm looking at using XMLBeans. I see no easy
>> integration of this with either AXIS or AXIS2. AXIS 2 is moving in
> that
>> direction, but does not have support for externally generated (using
>> scomp) XMLBeans. so for me ...
>> My "only" salvation here is serialization independence. Because with
>> independence, I can even roll my own. Then when/if Axis 2 supports my
>> chosen serialization objects I can trash my home grown solution, use
>> Axis 2, and there are no bumps in the road.
>>
>>
>>
>> so .... I couldn't agree more with Guy's #3 point below..
>>
>>
>> A
>>
>>
>> -----Original Message-----
>> From: Guy Rixon [mailto:gtr@ast.cam.ac.uk]
>> Sent: Monday, October 31, 2005 3:22 AM
>> To: axis-user@ws.apache.org
>> Cc: axis-dev@ws.apache.org
>> Subject: RE: I give up
>>
>> Three suggestions for improving the Axis experience:
>>
>> 1. More effort to documentation. The Axis 1 documents aren't yet
>> sufficient to
>> deal with use in a real project.
>>
>> Just expanding some of the Javadoc comments would help. In fact,
>> providing or
>> expanding the package.html files would be good, and maybe more
> palatable
>> than
>> reworking the xdocs. :)
>>
>> If someone did want to work on the xdocs, the reference guide to WSDD
>> would be
>> a good place to start.
>>
>> 2. Improve the error reports. Currently, when Axis goes worng (more
>> commonly,
>> when it is misconfigured) the error reporting isn't sufficient to
>> diagnose the
>> problem. Alternatively, provide tools that can inspect the
> configuration
>> of a
>> deployed service and explain what's wrong.
>>
>> 3. Provide an alternative to the current WSDL2Java to write stubs that
>> use an
>> external seralizer/deserializer mechanism (Castor, XMLbeans, JAXB). In
>> my
>> experience with Axis, the stubs are the valuable part and the Axis
>> XML-mapping
>> is redundant (duplicates mapping code we already have) unstable (bean
>> classes incompatible between Axis versions) and fragile. Hence the
> move
>> to
>> XMLBeans in Axis 2, I guess...but maybe Axis 1 could be cleaned up
> too?
>> What I have in mind is a stub-generation tool that takes a WSDL
>> contract, a
>> Java interface defining the API of the stub and a file of
> class/element
>> mappings. It would generate stubs for which the API is entirely
> defined
>> by the
>> author of the client, and which can be rebuild to the same contract in
>> the
>> next version of Axis 1; WSDL2Java can't provide this stability of
>> interface.
>>
>> You could provide a separate tool for creating data-binding beans if
> one
>> were
>> needed. This could generate the beans that WSDL2Java currently
> produces.
>> It
>> would also need to generate the class/element mapping-file.
>>
>> Guy Rixon gtr@ast.cam.ac.uk
>> Institute of Astronomy Tel: +44-1223-337542
>> Madingley Road, Cambridge, UK, CB3 0HA Fax:
> +44-1223-337523
>
>
>
>
> __________________________________
> Start your day with Yahoo! - Make it your home page!
> http://www.yahoo.com/r/hs
>