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




Reply via email to