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:[EMAIL PROTECTED] > Sent: Monday, November 12, 2007 3:07 PM > To: [email protected] > 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:[EMAIL PROTECTED] > > > > Sent: Sunday, November 11, 2007 11:54 AM > > > > To: Daniel Kulp > > > > Cc: [email protected] > > > > 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 > [EMAIL PROTECTED] > http://www.dankulp.com/blog
