Daniel, Yes, it is fixed in the latest 2.0.7-SNAPSHOT! Thanks for your response, and fixing this issue.
Hartmut Lang -----Original Message----- From: Daniel Kulp [mailto:[EMAIL PROTECTED] Sent: Mittwoch, 14. Mai 2008 17:14 To: [email protected] Subject: Re: jaxb-binding problem in 2.0.6 On May 14, 2008, at 2:41 AM, Hartmut Lang wrote: > Daniel, > > I checked the JAXBContext used for unmarshalling in 2.0.4 and 2.0.6. > In 2.0.6 the JAXBContext contained fewer classes (105 instead of 110). > The class of the expected type was there. But in 2.0.6 the related > ObjectFactory class was missing! > It seems that could be related to the "fixes" you were talking about > for > 2.0.5/2.0.6. > Is this now a bug? Possibly, but it might also already be fixed. I fixed a bug related to ObjectFactories not always being added last week. I'm deploying a new 2.0.7-SNAPSHOT right now. It will take an hour or so to get up there. Can you give that a quick try to make sure that fixes this? Dan > > Regards, > Hartmut Lang > > -----Original Message----- > From: Hartmut Lang [mailto:[EMAIL PROTECTED] > Sent: Mittwoch, 14. Mai 2008 06:57 > To: [email protected] > Subject: RE: jaxb-binding problem in 2.0.6 > > Daniel, thanks for your reply. > > The "type" is Object and uses "lax" binding. > @XmlAnyElement(lax = true) > protected List<Object> any; > > I try to find the JAXBContext (the one used for unmarshalling > right?) in > my debugger and let you know. > > Hartmut Lang > > > -----Original Message----- > From: Daniel Kulp [mailto:[EMAIL PROTECTED] > Sent: Dienstag, 13. Mai 2008 17:39 > To: [email protected] > Subject: Re: jaxb-binding problem in 2.0.6 > > > Hmm........... > > What is the "type" of the value in the JAXBElement? > > It LOOKS like 2.0.4 is adding/finding the specific type for the type > in the element (based on the xsi:type on the wire) and is able to > deserialize it into the concrete type. 2.0.6 isn't seeming to find > the concrete type and thus is getting the default of the DOM element. > > I'm not sure how to figure out why either... Hmm....... Is this > something you can run in a debugger and print the JAXBContext? My > gut feeling says the list of classes the JAXBContext is finding is > different, but I'd like to verify that. > > If that IS the case, there are ways to convince the JAXB binding to > add additional classes. 2.0.4 was picking up more things than it > should have which caused issues with too many types going out in the > schema and thus exposing internal structures and stuff. That was > fixed for 2.0.5/2.0.6. Thus, that COULD be the cause of part of > this. > > Dan > > > > > On May 13, 2008, at 5:13 AM, Hartmut Lang wrote: > >> Hi, >> >> >> >> i want to use the following complexType (part of MTOSI 2.0 ): >> >> <complexType name="AnyListType"> >> <complexContent> >> <restriction base="{http://www.w3.org/2001/XMLSchema}anyType";> >> <sequence> >> <any/> >> </sequence> >> </restriction> >> </complexContent> >> </complexType> >> >> >> >> The generated class has the method: >> >> public java.util.List<java.lang.Object> getAny() >> >> >> >> Now if i use cxf 2.0.4-incubator the Object in the getAny() method >> is a >> instance of class "javax.xml.bind.JAXBElement". This is what I >> expect. >> >> If I use the cxf 2.0.6 The Object in the getAny() method is a >> instance >> of class "com.sun.org.apache.xerces.internal.dom.ElementNSImpl". >> >> I do not recompile the code just change the runtime classpath form >> cxf >> 2.0.4 to 2.0.6. >> >> >> >> Why do I get the different class types? Any help welcome! >> >> >> >> Regards, >> >> Hartmut Lang >> > > --- > Daniel Kulp > [EMAIL PROTECTED] > http://www.dankulp.com/blog > > > > --- Daniel Kulp [EMAIL PROTECTED] http://www.dankulp.com/blog
