JBoss 4.0.5 has it's own copy of jaxb in
<jboss>/server/<instance>/deploy/jbossws.sar/ (can't remember if its
there in 4.0.4) - that could be messing you up.
Try using a private / scoped EAR with server class overriding and put
your own jaxb jar in your EAR (you'll probably have to list it as a
java module in application.xml). See:
http://www.jboss.org/wiki/Wiki.jsp?page=ClassLoadingConfiguration
I'm using a setup like this to run Sun RI jaxws/jaxb webservices in
front of JBoss/EJB3 session beans. I was doing this in both 4.0.4 and
4.0.5. So it is definitely possible. I think you're just having
classloader issues, which is a mess to sort out in most J2EE
containers.
On 1/26/07, john.mcclain_at_homeq.com <john.mcclain_at_homeq.com> wrote:
> I have an EAR project. In the project I have a web app and an EJB. My goal
> is to have a REST webservice servlet that gets the XML payload, uses JAXB
> to unmarshal it into XJC generated classes, then pass those classes to an
> EJB for processing. What I have found is the following:
>
> scenario 1)
> here is the EAR fle structure:
> EAR
> bpo-lib.jar - holds the XJC generated classes
> bpo-ejb.jar - references bpo-lib.jar in its manifest.mf file
> bpo-webservice.war - holds the rest servlet that does the
> unmarshaling and passes unmarshaled objects to EJB
> - holds bpo-lib.jar in WEB-INF/lib - I did this
> because I saw in the FAQ that JAXBContext.newInstance tries to load
> classes using the same clasloader that the
> JAXBContext class is in
> - references bpo-lib.jar in its manifest.mf
> file
>
> The result is that I can unmarshal the data into the XJC classes, but
> after I pass them to the EJB, I try to cast the object into the expected
> types and get a class cast exception. this is possibly the behavior
> mentioned in https://jaxb.dev.java.net/faq/#classloader
>
>
> scenario 2)
> here is the EAR file structure:
> EAR
> bpo-lib.jar - holds the XJC generated classes
> bpo-ejb.jar - references bpo-lib.jar in its manifest.mf file
> bpo-webservice.war - holds the rest servlet that does the
> unmarshaling and passes unmarshaled objects to EJB
> - does NOT hold bpo-lib.jar in WEB-INF/lib - I
> did this because in theory, on JBOSS4.0.4GA,
> the EAR classes are accessible to the WAR
> context. I.E., I should NOT have to put the bpo-lib.jar file
> in both the WEB-INF/lib dir and the EAR file
> - references bpo-lib.jar in its manifest.mf file
> The result is that I can NOT unmarshal the data into the XJC classes.
>
>
> To analyze this, I checked what classes the JAXBContext knows about, and
> what I found was that when it unmarshalled data, I had this set of
> classes:
> boolean
> byte
> char
> com.homeq.bpo.domain.FirstAmericanSchema.request.AppraisalStatusResponses
>
> com.homeq.bpo.domain.FirstAmericanSchema.request.AppraisalStatusResponses$AppraisalStatusResponse
>
> com.homeq.bpo.domain.FirstAmericanSchema.request.AppraisalStatusResponses$AppraisalStatusResponse$Notes
> com.homeq.bpo.domain.FirstAmericanSchema.request.NoteType
> com.homeq.bpo.domain.FirstAmericanSchema.request.ResultsDataType
> com.sun.xml.bind.api.CompositeStructure
> double
> .
> .
> .
>
> When it did not unmarshal data it had this set of classes:
> boolean
> byte
> char
> com.homeq.bpo.domain.FirstAmericanSchema.request.ObjectFactory
> com.sun.xml.bind.api.CompositeStructure
> double
> float
> .
> .
> .
>
> The above shows (I think) that I MUST have the bpo-lib.jar in the
> WEB-INF/lib dir as the classloader that loads JAXBContext must also load
> the generated classes. But as shown in scenario 1 above, this prevents you
> from also referencing those classes in an EJB, because, as stated in the
> FAQ, you get a classCast exception
>
> Would I be correct in stating that using JAXB in a rest based web service
> on JBOSS4.0.4GA cannot be done, or am I missing something?
>
>