You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Benson Margulies <bi...@basistech.com> on 2007/11/11 17:53:41 UTC
CXF-1197
This JIRA claims that the schemaInfo associated with a MessagePartInfo
is for the wrong part - in fact, for the wrong message altogether.
Emphasis on 'claims,' I'm always prepared to be confused.
RE: CXF-1197
Posted by Benson Margulies <bi...@basistech.com>.
Dan,
Queue depth:
Top: chase down 1198 by adding traps to the new SchemaCollection thing
and running code through it.
Next: get current round of JS code tested using
serialization/deserialization of explicit wrapper classes.
Next: we should decide. I'm inclined to try to actually finish this
Javascript slog.
The code would sure look more uniform if you asm'ed some wrapper classes
instead of the various special cases that dance around it. That is not
meant to dismiss the rest of your considerations, just to give you the
'benefit' of this weekend's reading of the code.
--benson
> -----Original Message-----
> From: Daniel Kulp [mailto:dkulp@apache.org]
> Sent: Monday, November 12, 2007 3:07 PM
> To: cxf-dev@incubator.apache.org
> Cc: Benson Margulies
> Subject: Re: CXF-1197
>
>
>
> One thing I want to add:
>
> When working on this problem for 2.0.1, Dan D and I did toss around
the
> idea of using ASM to create the wrapper classes in memory and use them
> instead of all the work we needed to do. I didn't go that route for
> two reasons:
>
> 1) Maintaining the ASM code thing would not be fun. Adding stuff to
it,
> fixing bugs, etc... really sucks.
>
> 2) We didn't want to add asm as a REQUIRED dependency, so the way we
did
> it had to work anyway. Using ASM could be an optimization later.
> (example: processing the wrapper classes to pull out/insert the fields
> is currently done with reflection if ASM is not available, or via a
> generated ASM helper class if ASM is available.)
>
> That said, we might want to revisit that decision for 2.1. With
JAX-WS
> 2.1, we need to support more annotations on the parameters and return
> values themselves. Things like the mime types and other JAXB
> annotation things. It MAY be easier to just ASM the wrapper classes
> with those annotations than it would be to keep adding more and more
> cases into the complex world of trying read/write all the individul
> parts themselves.
>
> Note: the RI is going the "in memory" direction as well:
>
http://weblogs.java.net/blog/kohsuke/archive/2007/07/bye_bye_wsgen.html
>
> Note 2: I meant wsgen, not wsimport in the last message
>
> Dan
>
>
>
> On Monday 12 November 2007, Daniel Kulp wrote:
> > Benson,
> >
> > The @RequestWrapper and @ResponseWrapper annotations are used to let
> > the jax-ws frontend know the classes to use for the wrappers.
> >
> > Note: this is one of the things that differentiates CXF from the
> > jax-ws reference implementation. With the RI, if you don't have
> > "hand coded" Wrapper classes, for wrapped/doc/lit, you pretty much
> > HAVE to run "wsimport" to have it generate the wrapper types for
you.
> > (it also generates fault beans as JAXB cannot handle subclasses of
> > Exception) The RI uses those at runtime in all cases.
> >
> > With CXF, if the wrapper classes are not there, we try to handle it
> > ourselves. This is NOT easy as we cannot just delegate down to
JAXB
> > and still meet the jax-ws spec(which is why the RI doesn't do it).
> > Many of the "code first" bugs in 2.0 and 2.0.1 were around the use
> > cases of no wrapper classes available. The workaround in most
cases
> > was to call java2wsdl with the -s flag to have it generate the
wrapper
> > types like the RI does. (this ends up very equivilen to wsimport)
> > For 2.0.2, we fixed many of the non-wrapper object cases, and 2.0.3
> > fixes even more.
> >
> > Dan
> >
> > On Sunday 11 November 2007, Benson Margulies wrote:
> > > I'm beginning to see the light of this tunnel coming swiftly
toward
> > > me.
> > >
> > > WrappedOutInterceptor never has a Java object corresponding to the
> > > entire part. It improvises the XML at the part level, and
presumably
> > > calls upon the DataWriter to write the individual elements inside
> > > the part. (Here's more code with a strong fondness for 'ns*'
> > > namespace prefixes, in spite of whatever's in the WSDL or schema.)
> > >
> > > Correspondly, the WrappedInInterceptor does it the hard way unless
> > > there is a wrapper type. For my testing purposes, a wrapper type
> > > sure would be convenient, so I guess that finding out how to
> > > negotiate one with JAX-WS / JAXB would be a smart thing to do.
> > >
> > > > -----Original Message-----
> > > > From: Benson Margulies [mailto:bim2007@basistech.com]
> > > > Sent: Sunday, November 11, 2007 11:54 AM
> > > > To: Daniel Kulp
> > > > Cc: cxf-dev@incubator.apache.org
> > > > Subject: CXF-1197
> > > >
> > > > This JIRA claims that the schemaInfo associated with a
> > > > MessagePartInfo is for the wrong part - in fact, for the wrong
> > > > message altogether. Emphasis on 'claims,' I'm always prepared to
> > > > be confused.
>
>
>
> --
> J. Daniel Kulp
> Principal Engineer
> IONA
> P: 781-902-8727 C: 508-380-7194
> daniel.kulp@iona.com
> http://www.dankulp.com/blog
Re: CXF-1197
Posted by Daniel Kulp <dk...@apache.org>.
One thing I want to add:
When working on this problem for 2.0.1, Dan D and I did toss around the
idea of using ASM to create the wrapper classes in memory and use them
instead of all the work we needed to do. I didn't go that route for
two reasons:
1) Maintaining the ASM code thing would not be fun. Adding stuff to it,
fixing bugs, etc... really sucks.
2) We didn't want to add asm as a REQUIRED dependency, so the way we did
it had to work anyway. Using ASM could be an optimization later.
(example: processing the wrapper classes to pull out/insert the fields
is currently done with reflection if ASM is not available, or via a
generated ASM helper class if ASM is available.)
That said, we might want to revisit that decision for 2.1. With JAX-WS
2.1, we need to support more annotations on the parameters and return
values themselves. Things like the mime types and other JAXB
annotation things. It MAY be easier to just ASM the wrapper classes
with those annotations than it would be to keep adding more and more
cases into the complex world of trying read/write all the individul
parts themselves.
Note: the RI is going the "in memory" direction as well:
http://weblogs.java.net/blog/kohsuke/archive/2007/07/bye_bye_wsgen.html
Note 2: I meant wsgen, not wsimport in the last message
Dan
On Monday 12 November 2007, Daniel Kulp wrote:
> Benson,
>
> The @RequestWrapper and @ResponseWrapper annotations are used to let
> the jax-ws frontend know the classes to use for the wrappers.
>
> Note: this is one of the things that differentiates CXF from the
> jax-ws reference implementation. With the RI, if you don't have
> "hand coded" Wrapper classes, for wrapped/doc/lit, you pretty much
> HAVE to run "wsimport" to have it generate the wrapper types for you.
> (it also generates fault beans as JAXB cannot handle subclasses of
> Exception) The RI uses those at runtime in all cases.
>
> With CXF, if the wrapper classes are not there, we try to handle it
> ourselves. This is NOT easy as we cannot just delegate down to JAXB
> and still meet the jax-ws spec(which is why the RI doesn't do it).
> Many of the "code first" bugs in 2.0 and 2.0.1 were around the use
> cases of no wrapper classes available. The workaround in most cases
> was to call java2wsdl with the -s flag to have it generate the wrapper
> types like the RI does. (this ends up very equivilen to wsimport)
> For 2.0.2, we fixed many of the non-wrapper object cases, and 2.0.3
> fixes even more.
>
> Dan
>
> On Sunday 11 November 2007, Benson Margulies wrote:
> > I'm beginning to see the light of this tunnel coming swiftly toward
> > me.
> >
> > WrappedOutInterceptor never has a Java object corresponding to the
> > entire part. It improvises the XML at the part level, and presumably
> > calls upon the DataWriter to write the individual elements inside
> > the part. (Here's more code with a strong fondness for 'ns*'
> > namespace prefixes, in spite of whatever's in the WSDL or schema.)
> >
> > Correspondly, the WrappedInInterceptor does it the hard way unless
> > there is a wrapper type. For my testing purposes, a wrapper type
> > sure would be convenient, so I guess that finding out how to
> > negotiate one with JAX-WS / JAXB would be a smart thing to do.
> >
> > > -----Original Message-----
> > > From: Benson Margulies [mailto:bim2007@basistech.com]
> > > Sent: Sunday, November 11, 2007 11:54 AM
> > > To: Daniel Kulp
> > > Cc: cxf-dev@incubator.apache.org
> > > Subject: CXF-1197
> > >
> > > This JIRA claims that the schemaInfo associated with a
> > > MessagePartInfo is for the wrong part - in fact, for the wrong
> > > message altogether. Emphasis on 'claims,' I'm always prepared to
> > > be confused.
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194
daniel.kulp@iona.com
http://www.dankulp.com/blog
Please apply this patch before next 2.0.x branch merge
Posted by Jim Ma <em...@iona.com>.
Hi Dan ,
I modified some class in javato/ws module . These changes will not be
merged into javato/core and javato/test module
in 2.0.x branch and some tests will fail. Could you help me apply this
patch to 2.0.x branch before your next merge ?
Thanks
Jim
Re: CXF-1197
Posted by Daniel Kulp <dk...@apache.org>.
Benson,
The @RequestWrapper and @ResponseWrapper annotations are used to let the
jax-ws frontend know the classes to use for the wrappers.
Note: this is one of the things that differentiates CXF from the jax-ws
reference implementation. With the RI, if you don't have "hand coded"
Wrapper classes, for wrapped/doc/lit, you pretty much HAVE to
run "wsimport" to have it generate the wrapper types for you. (it also
generates fault beans as JAXB cannot handle subclasses of Exception)
The RI uses those at runtime in all cases.
With CXF, if the wrapper classes are not there, we try to handle it
ourselves. This is NOT easy as we cannot just delegate down to JAXB
and still meet the jax-ws spec(which is why the RI doesn't do it).
Many of the "code first" bugs in 2.0 and 2.0.1 were around the use cases
of no wrapper classes available. The workaround in most cases was to
call java2wsdl with the -s flag to have it generate the wrapper types
like the RI does. (this ends up very equivilen to wsimport) For 2.0.2,
we fixed many of the non-wrapper object cases, and 2.0.3 fixes even
more.
Dan
On Sunday 11 November 2007, Benson Margulies wrote:
> I'm beginning to see the light of this tunnel coming swiftly toward
> me.
>
> WrappedOutInterceptor never has a Java object corresponding to the
> entire part. It improvises the XML at the part level, and presumably
> calls upon the DataWriter to write the individual elements inside the
> part. (Here's more code with a strong fondness for 'ns*' namespace
> prefixes, in spite of whatever's in the WSDL or schema.)
>
> Correspondly, the WrappedInInterceptor does it the hard way unless
> there is a wrapper type. For my testing purposes, a wrapper type sure
> would be convenient, so I guess that finding out how to negotiate one
> with JAX-WS / JAXB would be a smart thing to do.
>
> > -----Original Message-----
> > From: Benson Margulies [mailto:bim2007@basistech.com]
> > Sent: Sunday, November 11, 2007 11:54 AM
> > To: Daniel Kulp
> > Cc: cxf-dev@incubator.apache.org
> > Subject: CXF-1197
> >
> > This JIRA claims that the schemaInfo associated with a
> > MessagePartInfo is for the wrong part - in fact, for the wrong
> > message altogether. Emphasis on 'claims,' I'm always prepared to be
> > confused.
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194
daniel.kulp@iona.com
http://www.dankulp.com/blog
RE: CXF-1197
Posted by Benson Margulies <bi...@basistech.com>.
I'm beginning to see the light of this tunnel coming swiftly toward me.
WrappedOutInterceptor never has a Java object corresponding to the
entire part. It improvises the XML at the part level, and presumably
calls upon the DataWriter to write the individual elements inside the
part. (Here's more code with a strong fondness for 'ns*' namespace
prefixes, in spite of whatever's in the WSDL or schema.)
Correspondly, the WrappedInInterceptor does it the hard way unless there
is a wrapper type. For my testing purposes, a wrapper type sure would be
convenient, so I guess that finding out how to negotiate one with JAX-WS
/ JAXB would be a smart thing to do.
> -----Original Message-----
> From: Benson Margulies [mailto:bim2007@basistech.com]
> Sent: Sunday, November 11, 2007 11:54 AM
> To: Daniel Kulp
> Cc: cxf-dev@incubator.apache.org
> Subject: CXF-1197
>
> This JIRA claims that the schemaInfo associated with a MessagePartInfo
> is for the wrong part - in fact, for the wrong message altogether.
> Emphasis on 'claims,' I'm always prepared to be confused.