john.mcclain_at_homeq.com wrote:
> After reading the FAQ about how the newInstance(...) tries to load classes
> using the sameclassloader used to load the JAXBContext itself, it seems
> this may be the problem;
As I pointed out this is not the case. We use the current thread context
classloader.
> My JAXBContext.newInstance calls are in my
> servlets, which are in the war files. I.E., My XJC generated classes are
> in my EJB jar. Thoughmy 2 WAR files (1 works 1 does not) and my EJB jar
> file (containing generated classes) are all in my EAR file, I believe
> (correct me if I am wrong) that JBOSS appserver has a different
> classloader for WAR's and for EJB's.
I'm not familiar with EJB, but I thought WAR class loaders delegate to
EJB classloader. But your experiment says this is not the case.
> I assumed having the EJB jar file in
> the manifest.mf file or the WARS would solve this problem because the
> classpaths would contain the jar file listing. Am I going down a rabbit
> hole, or is it true that the XJC generated fiels MUST be in the same
> classloader and the loader that loaded the JAXBContext class itself
The reason I suggested to pass in java.lang.Class instances is because
that version of the JAXBContext.newInstance() won't be affected by the
classloader at all (you might have noticed that it doesn't take
ClassLoader.)
So if your WAR2 didn't fail by the time you invoke
JAXBContext.newInstance(Class...), then classloading is going on
successfully. If it fails before that by, say, NoClassDefFoundError,
then it's strictly JBoss/yourapp issue. That's the thing you need to check.
>
> I f I am correct, then how do I get my servlets to see the XJC generated
> files housed in the EJB jar, housed in the EAR?
> If I can't then what is a better architecture - should I have the XJC
> generated files reside in the WAR file AND the EJB jar file - wouldn't
> this cause conflict since they are being loaded in both the webapp
> classloader and the EJB classloader?
>
>
>
> Kohsuke Kawaguchi <Kohsuke.Kawaguchi_at_Sun.COM>
> 01/23/2007 12:11 PM
>
> Please respond to
> users_at_jaxb.dev.java.net
>
>
> To
> users_at_jaxb.dev.java.net
> cc
> jmcclain1_at_starstream.net
> Subject
> Re: help with unmarshaling
>
>
>
>
>
>
> john.mcclain_at_homeq.com wrote:
>> Howdy
>> I have an EAR project deployed in jboss. The ear file contains an EJB
> jar
>> file, which houses the XJC generated classes in addition to the EJB. The
>
>> ear file also includes 2 war files
>> Each war file contains 1 servlet.
>>
>> The issue is that the servlet from war 1 fails and the servlet from war2
>
>> succeeds, YET THEY ARE COPIES OF EACH OTHER
>>
>> Here are the datials from a failure/success perspective
>>
>> servlet from War that SUCCEEDS
>> 1)WEB-INF/lib containsa set of jars (call it setx), AND the EJB jar
>> containing the XJC generated classes
>> 2)the mainfest.mf (classpath) has all the above jars including the EJB
>> listed (generated from Maven2) - this means the EJB jar file is in the
> EAR
>> and this wars WEB-INF/lib
>> 3) When the servlet runs, i print out the to_string method of the
>> jaxbContext, and it shows ALL the specific XJC generated classes except
>> for the ObjectFactory
>>
>> Servlet from WAR that FAILS
>> 1)WEB-INF/lib contains ONLY set of jars, setx (see above)
>> 2)the mainfest.mf (classpath) has all the above jars including the EJB
>> listed (generated from Maven2)
>> 3)When the servlet runs, i print out the to_string method of the
>> jaxbContext, and it shows ONLY the ObjectFactory generated by XJC
>
> It sounds like a classloader issue. [1] and [2] are relevant docs on
> this topic. I suspect you've already looked at [1], but [2] might be
> just what you need --- I need to make [1] include [2].
>
> [1]
> https://jaxb.dev.java.net/guide/Unmarshalling_is_not_working__Help_.html
> [2] https://jaxb.dev.java.net/faq/#classloader
>
> Also, Is FIRST_AMERICAN_RESPONSE constant a string? Try passing in
> ObjectFactory.class list, as that's the easier way of identifying
> classloader problems.
>
>>
>> The servlet code FOR BOTH SERVLETS is:
>> JAXBContext jaxbContext_tst =
>> JAXBContext.newInstance(FIRST_AMERICAN_RESPONSE);
>> System.out.println(jaxbContext_tst.toString());
>> Unmarshaller unmarshaller_tst =
>> jaxbContext_tst.createUnmarshaller();
>> unmarshaller_tst.setEventHandler(new
>> javax.xml.bind.helpers.DefaultValidationEventHandler());
>> RESPONSEGROUP tst = (RESPONSEGROUP)
>> unmarshaller_tst.unmarshal(new File(
>> "C:\\homeq-maven\\projects\\homeq-bpo\\notes\\resptest.xml" ));
>>
>> In the success servlet, tst contains all the data, in the failing
> servlet,
>> an unmarshal exception is thrown
>>
>> The unmarshalexception I get when call unmarshal(...) is:
>> 17:08:18,827 INFO [STDOUT] DefaultValidationEventHandler:
> [FATAL_ERROR]:
>> unexpected element (uri:"", local:"RESPONSE_GROUP"). Expected elements
> are
>> (none)
>> Location: line 1 of
>> file:/C:/homeq-maven/projects/homeq-bpo/notes/resptest.xml
>> 17:08:22,093 ERROR [STDERR] javax.xml.bind.UnmarshalException:
> unexpected
>> element (uri:"", local:"RESPONSE_GROUP"). Expected elements are (none)
>> 17:08:22,093 ERROR [STDERR] at
>>
> com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext.handleEvent(
>> UnmarshallingContext.java:556)
>> 17:08:22,093 ERROR [STDERR] at
>> com.sun.xml.bind.v2.runtime.unmarshaller.Loader.reportError(
>> Loader.java:199)
>> 17:08:22,093 ERROR [STDERR] at
>> com.sun.xml.bind.v2.runtime.unmarshaller.Loader.reportError(
>> Loader.java:194)
>> 17:08:22,093 ERROR [STDERR] at
>>
> com.sun.xml.bind.v2.runtime.unmarshaller.Loader.reportUnexpectedChildElement(
>> Loader.java:71)
>> 17:08:22,093 ERROR [STDERR] at
>>
> com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext$DefaultRootLoader.childElement(
>> UnmarshallingContext.java:957)
>> 17:08:22,108 ERROR [STDERR] at
>>
> com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext._startElement(
>> UnmarshallingContext.java:399)
>>
>>
>> Given that the EAR file contains the EJB jar file containing the XJC
>> generated classes, AND the manifest.mf file lists the EJB jar (I believe
>
>> this puts it in the classpath), then why is the failing servlet
> failing???
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_jaxb.dev.java.net
>> For additional commands, e-mail: users-help_at_jaxb.dev.java.net
>>
>>
>
>
--
Kohsuke Kawaguchi
Sun Microsystems kohsuke.kawaguchi_at_sun.com