Hi,
Yuk. The following may help:
http://www.jboss.org/community/wiki/ClassCastExceptions
I think the problem is that jars in the war are conflicting with jars
supplied by JBoss. Are you including a version of JAXB in the ear or
war?
To put things in perspective you just switched to a new major release
of a new app server :-) IMHO the real underlying problem is the lack
of a modularity system in Java SE 6 or less.
Paul.
On Nov 12, 2009, at 9:03 PM, FSauer_at_dsthealthsolutions.com wrote:
>
> next problem - this time JAXB related before even accessing any
> resources. this occurs on deployment:
>
> java.lang.LinkageError: loader constraints violated when linking
> javax/xml/namespace/QName class
> at
> com
> .sun
> .xml
> .bind
> .v2
> .model
> .impl
> .RuntimeBuiltinLeafInfoImpl.<clinit>(RuntimeBuiltinLeafInfoImpl.java:
> 224)
> at
> com
> .sun
> .xml
> .bind
> .v2
> .model
> .impl.RuntimeTypeInfoSetImpl.<init>(RuntimeTypeInfoSetImpl.java:61)
> at
> com
> .sun
> .xml
> .bind
> .v2
> .model
> .impl.RuntimeModelBuilder.createTypeInfoSet(RuntimeModelBuilder.java:
> 129)
> at
> com
> .sun
> .xml
> .bind
> .v2
> .model
> .impl.RuntimeModelBuilder.createTypeInfoSet(RuntimeModelBuilder.java:
> 81)
> at
> com.sun.xml.bind.v2.model.impl.ModelBuilder.<init>(ModelBuilder.java:
> 152)
> at
> com
> .sun
> .xml
> .bind
> .v2.model.impl.RuntimeModelBuilder.<init>(RuntimeModelBuilder.java:89)
> at
> com
> .sun
> .xml
> .bind.v2.runtime.JAXBContextImpl.getTypeInfoSet(JAXBContextImpl.java:
> 456)
> at
> com
> .sun.xml.bind.v2.runtime.JAXBContextImpl.<init>(JAXBContextImpl.java:
> 302)
> at com.sun.xml.bind.v2.runtime.JAXBContextImpl
> $JAXBContextBuilder.build(JAXBContextImpl.java:1136)
> at
> com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:
> 154)
> at
> com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:
> 121)
> at
> com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:
> 202)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun
> .reflect
> .NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun
> .reflect
> .DelegatingMethodAccessorImpl
> .invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at
> javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:133)
> at javax.xml.bind.ContextFinder.find(ContextFinder.java:286)
> at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:
> 372)
> at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:
> 337)
> at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:
> 244)
> at
> com
> .sun
> .jersey
> .server
> .impl
> .wadl
> .WadlApplicationContextImpl.<init>(WadlApplicationContextImpl.java:66)
> at
> com.sun.jersey.server.impl.wadl.WadlFactory.init(WadlFactory.java:93)
> at
> com
> .sun
> .jersey
> .server
> .impl
> .application.WebApplicationImpl.initWadl(WebApplicationImpl.java:988)
> at
> com
> .sun
> .jersey
> .server
> .impl
> .application
> .WebApplicationImpl.processRootResources(WebApplicationImpl.java:887)
> at
> com
> .sun
> .jersey
> .server
> .impl
> .application.WebApplicationImpl.initiate(WebApplicationImpl.java:714)
> at
> com
> .sun
> .jersey
> .server
> .impl
> .application.WebApplicationImpl.initiate(WebApplicationImpl.java:445)
> at
> com
> .sun
> .jersey
> .spi
> .container.servlet.ServletContainer.initiate(ServletContainer.java:
> 404)
> at com.sun.jersey.spi.container.servlet.ServletContainer
> $InternalWebComponent.initiate(ServletContainer.java:253)
> at
> com
> .sun
> .jersey.spi.container.servlet.WebComponent.load(WebComponent.java:517)
> at
> com
> .sun
> .jersey.spi.container.servlet.WebComponent.init(WebComponent.java:199)
> at
> com
> .sun
> .jersey
> .spi.container.servlet.ServletContainer.init(ServletContainer.java:
> 308)
> at
> com
> .sun
> .jersey
> .spi.container.servlet.ServletContainer.init(ServletContainer.java:
> 471)
>
> this whole exercise reminds me why I quit doing JEE and used POJOS
> and Spring instead....... Now I'm back in my worst nightmare :-(
>
>
>
>
> Paul Sandoz <Paul.Sandoz_at_Sun.COM>
> Sent by: Paul.Sandoz_at_Sun.COM
> 11/12/2009 01:38 PM
> Please respond to
> users_at_jersey.dev.java.net
>
> To
> users_at_jersey.dev.java.net
> cc
> Subject
> Re: [Jersey] strange Viewable path resolving problem
>
>
>
>
>
>
> On Nov 12, 2009, at 8:22 PM, FSauer_at_dsthealthsolutions.com wrote:
>
>
> this looks like https://jersey.dev.java.net/issues/show_bug.cgi?id=80
>
> but is still failing with jersey 1.1.4 and jboss 5.1.0 ?
>
> Yes, it looks like something has changed between 5.0.x and 5.1.x.
>
> I need to fix this as part of issue 32. The solution for JBoss,
> AFAIK, requires something plugable specific to JBoss for resolving
> the URIs.
>
> Sorry for the frustration :-( The work around in this respect is not
> to use class scanning by declaring the packages to search for
> classes but to explicitly declare the root resource and provider
> classes in an extension of Application (as described in the
> deployment section of the user guide).
>
> Paul.
>
>
>
>
> FSauer_at_dsthealthsolutions.com
> 11/12/2009 12:47 PM
> Please respond to
> users_at_jersey.dev.java.net
>
>
> To
> users_at_jersey.dev.java.net
> cc
> Subject
> Re: [Jersey] strange Viewable path resolving problem
>
>
>
>
>
>
>
>
> trying to deploy now on JBoss 5.1.0GA and after stumbling through
> many deployment and configuration problems I finally stumble on this
> one:
>
> 12:38:40,106 INFO [TomcatDeployment] deploy, ctxPath=/PMABServiceWeb
> 12:38:40,294 INFO [PackagesResourceConfig] Scanning for root
> resource and provider classes in the packages:
> com.dsths.pmab.resources
> 12:38:40,325 WARNING [AnnotatedClassScanner] URL, vfszip:/C:/dev/
> jboss-5.1.0.GA/server/default/deploy/PMABEar.ear/PMABServiceWeb.war/
> WEB-INF/classes/com/dsths/pmab/resources/, is ignored, it not a file
> or a jar file URL
> 12:38:40,466 INFO [WebApplicationImpl] Initiating Jersey
> application, version 'Jersey: 1.1.2-ea 08/25/2009 04:39 PM'
> 12:38:40,997 SEVERE [WebApplicationImpl] The ResourceConfig instance
> does not contain any root resource classes.
> 12:38:40,997 ERROR [[/PMABServiceWeb]] StandardWrapper.Throwable
> com.sun.jersey.api.container.ContainerException: The ResourceConfig
> instance does not contain any root resource classes.
>
> It exists AND it contains a root resource. I had it somewhat
> "working" earlier on JBoss 4.2.1........... About to throw it he
> towel here! :-(
>
> Any ideas?
>
>
>
>
> Paul Sandoz <Paul.Sandoz_at_Sun.COM>
> Sent by: Paul.Sandoz_at_Sun.COM
> 11/12/2009 08:48 AM
> Please respond to
> users_at_jersey.dev.java.net
>
> To
> users_at_jersey.dev.java.net
> cc
> Subject
> Re: [Jersey] strange Viewable path resolving problem
>
>
>
>
>
>
>
>
>
> On Nov 12, 2009, at 3:40 PM, FSauer_at_dsthealthsolutions.com wrote:
>
>
> Unfortunately it won't be easy for me to extract this into a simple
> maven-based test case. Ears, wars, eclipse and maven don't play nice
> - nothing simple about it...
>
> Agreed. It can take a long time to create such a project set up.
> NetBeans might have something to help, if i have time i will check.
>
> Can you try deploying on another app server? or upgrading the
> version of JBoss?
>
> Or try creating a simple war that explicitly performs forwarding
> using request dispatcher to see if you can reproduce the issue, and
> if so log an issue against JBoss AS?
>
> Paul.
>
> I tried your suggestions, and found this:
>
> > I suspect not as the request URI of d might be:
>
> > /PMABServiceWeb/PMABServiceWeb/com/dsths/pmab/resources/settings/
> GlobalSettings/index.jsp
>
> your suspicion is correct :-( jersey still find the correct full
> path - including one occurrence of PMABServiceWeb, but then another
> one still gets prepended.
>
>
> > What happens if you do not specify the context root in the
> application.xml ? or specify "/' instead?
>
> Then PMABServiceWeb works, however since I have another war in that
> same ear I run into other problems when I do that. The other war now
> fails in a way it doesn't when PMABServiceWeb is specified for this
> war.....
>
>
>
>
> Paul Sandoz <Paul.Sandoz_at_Sun.COM>
> Sent by: Paul.Sandoz_at_Sun.COM
> 11/12/2009 06:11 AM
> Please respond to
> users_at_jersey.dev.java.net
>
>
> To
> users_at_jersey.dev.java.net
> cc
> Subject
> Re: [Jersey] strange Viewable path resolving problem
>
>
>
>
>
>
>
>
>
>
>
> Hi,
>
> Would it be possible to send me a simple maven-based test case?
>
> I am not sure if this is a bug in the JBoss app server or the correct
> behavior. I would like to test on GF.
>
> The inclusion of the context-root path may not be correct because the
> servlet context can get the resource thus there is an inconsistency.
> It basically breaks forwarding to any resource in the war regardless
> of whether Jersey forwards or not. i.e. it should be reproducible with
> a simple servlet that forwards to a JSP resource.
>
>
> I wonder if the following will work:
>
> 1) Move your templates under the directory PMABServiceWeb
>
> 2) Add the following property to the servlet init params:
>
> <init-param>
> <param-
> name>com.sun.jersey.config.property.JSPTemplatesBasePath</param-name>
> <param-value>PMABServiceWeb</param-value>
> </init-param>
>
>
> I suspect not as the request URI of d might be:
>
> /PMABServiceWeb/PMABServiceWeb/com/dsths/pmab/resources/settings/
> GlobalSettings/index.jsp
>
>
> What happens if you do not specify the context root in the
> application.xml ? or specify "/' instead?
>
> Paul.
>
> On Nov 11, 2009, at 11:52 PM, FSauer_at_dsthealthsolutions.com wrote:
>
> >
> > When I run jersey 1.1.2-ea in JBoss 4.2.1 - deployed from an ear -
> > I am running into a weird issue:
> >
> > my resource class has this code:
> >
> > @GET
> > @Produces(MediaType.TEXT_HTML)
> > public Viewable getUI() {
> > return new Viewable("index", this);
> > }
> >
> > and stepping through jersey it he debugger I can see that this
> > correctly resolves to a full path:
> >
> > TemplateFactory.resolveRelativeViewable line 133:
> >
> > for (TemplateProcessor t : getTemplateProcessors()) {
> > String resolvedPath = t.resolve(absolutePath);
> > if (resolvedPath != null) {
> > 133 >>> return new ResolvedViewable(t,
> > resolvedPath, v.getModel(), c);
> > }
> > }
> >
> > returns with the correct absolute path /com/dsths/pmab/resources/
> > settings/GlobalSettings/index.jsp
> >
> > so far so good... Now we get to JSPTemplateProcessor creating a
> > RequestDispatcherWrapper and in there :
> >
> > public void forward(ServletRequest req, ServletResponse rsp)
> > throws ServletException, IOException {
> > ResolvedViewable rv =
> > (ResolvedViewable
> > )hc
> >
> .getProperties().get("com.sun.jersey.spi.template.ResolvedViewable");
> >
> > req.setAttribute("httpContext", hc);
> > req.setAttribute("resolvingClass", rv.getResolvingClass());
> > req.setAttribute("it", it);
> > req.setAttribute("_basePath", basePath);
> > req.setAttribute("_request", req);
> > req.setAttribute("_response", rsp);
> > >>> d.forward(req,rsp);
> > }
> >
> > it is handed over to catalina. However, by now the requestURI in d
> > (an org.apache.catalina.core.ApplicationDispatcher) is:
> >
> > /PMABServiceWeb/com/dsths/pmab/resources/settings/GlobalSettings/
> > index.jsp
> >
> > the first part being the contex root set in the application.xml of
> > the EAR:
> >
> > <module>
> > <web>
> > <web-uri>PMABServiceWeb.war</web-uri>
> > <context-root>PMABServiceWeb</context-root>
> > </web>
> > </module>
> >
> > basePath is an empty string and so is d.servletPath
> >
> > and the result is a 404 without any indication of a problem like a
> > stack trace..........
> >
> > when I insert that directory (PMABServiceWeb) the Viewable does not
> > resolve correctly and I never get this far...
> >
> > How do I make jersey work in an ear? All of this works fine in
> > another app I used to work on that deployed straight to tomcat in a
> > war - no ears....
> >
> >
> > Any suggestions?
> >
> > Thanks,
> >
> > Frank Sauer
> >
> >
> > Please consider the environment before printing this email and any
> > attachments.
> >
> > This e-mail and any attachments are intended only for the individual
> > or company to which it is addressed and may contain information
> > which is privileged, confidential and prohibited from disclosure or
> > unauthorized use under applicable law. If you are not the intended
> > recipient of this e-mail, you are hereby notified that any use,
> > dissemination, or copying of this e-mail or the information
> > contained in this e-mail is strictly prohibited by the sender. If
> > you have received this transmission in error, please return the
> > material received to the sender and delete all copies from your
> > system.
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>
>
>
>