We Keep Coding

Weblogic classloader issue

I have a problem with Weblogic classloader.
When I try to deploy my app on WL 12.2.1.2.0 it fails.
In the logs on my server I see
java.lang.ClassNotFoundException: org.w3c.dom.ElementTraversal
The class belongs to xml-apis library. The library comes into my app with another dependency(so as transitive dependency). The version of xml-apis is 1.4.01.
After that I added exception in my deployment descriptor:
<container-descriptor>
<prefer-application-packages>
<package-name>org.w3c.dom.*</package-name>
</prefer-application-packages>
</container-descriptor>
And later a new deployment. The described issue with org.w3c.dom.ElementTraversal was solved. There is no any information about missing org.w3c.dom.ElementTraversal class anymore.
But there is a new issue:
java.lang.ClassNotFoundException: org.w3c.dom.Document
After analysis I figured out that org.w3c.dom.Document class comes from JRE(jre/lib/rt.jar).
So in deployment descriptor I've said:
"if I need something from org.w3c.dom.* package - please load it from my app distribution". And now there is such inconsistency.
I've had idea to use WL Classloader Analysis Tool(CAT) but it is impossible because the deploy was failed.
Excluding xml-apis and xerces libraries from my ear we mentioned here didn't help me.
Does anybody have idea how to solve my problem?
Thanks in advance for your answers.

Excluding xercexImpl library from my EAR without changing the deployment descriptor was solved my problem. Mentioned classes during new deployment were loaded from WL distribution.

Java EE Exception: Name java:comp is not bound in this Context

I have the Java EE app in Netbeans 7.2.1. Trying to deploy it (building ends OK), I get the error in Tomcat log:
Caused by: javax.naming.NameNotFoundException: Name java:comp is not bound in this Context
at org.apache.naming.NamingContext.lookup(NamingContext.java:770)
at org.apache.naming.NamingContext.lookup(NamingContext.java:153)
at javax.naming.InitialContext.lookup(InitialContext.java:392)
at org.springframework.jndi.JndiTemplate$1.doInContext(JndiTemplate.java:154)
at org.springframework.jndi.JndiTemplate.execute(JndiTemplate.java:87)
at org.springframework.jndi.JndiTemplate.lookup(JndiTemplate.java:152)
at org.springframework.jndi.JndiTemplate.lookup(JndiTemplate.java:178)
at org.springframework.jndi.JndiLocatorSupport.lookup(JndiLocatorSupport.java:95)
at org.springframework.jndi.JndiObjectLocator.lookup(JndiObjectLocator.java:105)
at org.springframework.jndi.JndiObjectFactoryBean.lookupWithFallback(JndiObjectFactoryBean.java:201)
at org.springframework.jndi.JndiObjectFactoryBean.afterPropertiesSet(JndiObjectFactoryBean.java:187)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1514)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1454)
Looking for code, that causes this error I found the follow:
public Object lookup(String name) throws NamingException {
return getURLOrDefaultInitCtx(name).lookup(name);
}
How is this caused and how can I solve it?

That will in case of Tomcat happen when you have for some reason dropped arbitrary servletcontainer-specific JARs such as jsp-api.jar, servlet-api.jar, catalina.jar, etc in webapp's /WEB-INF/lib. You should remove all servletcontainer-specific JARs from there, they do not belong there. Also, make sure those JARs are not nested within other JARs you have inside WEB-INF/lib.
This is a common starter's mistake in order to "fix" compilation errors on JSP/Servlet libraries which should have been solved differently; namely by configuring the IDE project to be associated with a "Target server" in Netbeans or "Target runtime" in Eclipse. The IDE will then automagically include the server's libraries during compiletime.

Jar dependency exceptions on weblogic servers for an application

I am getting an exception while deploying on Weblogic Server:
[2012-01-13 01:17:11,496] ERROR [org.springframework.web.servlet.DispatcherServlet] Context
initialization failed
org.springframework.beans.factory.BeanCreationException: Error creating bean with name
'org.springframework.validation.beanvalidation.LocalValidatorFactoryBean#0': Invocation of init method
failed; nested exception is java.lang.NoClassDefFoundError: javax/xml/bind/JAXBException
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.at
org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:291)
at
org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:222)
at
org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:288)
at
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:190)
at
org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.at
org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.
I have some jars as below:
log4j-1.2.14.jar
spring-asm-3.0.3.RELEASE.jar
spring-beans-3.0.3.RELEASE.jar
spring-context-3.0.3.RELEASE.jar
spring-core-3.0.3.RELEASE.jar
spring-expression-3.0.3.RELEASE.jar
spring-web-3.0.3.RELEASE.jar
spring-webmvc-3.0.3.RELEASE.jar
servlet-2.3.jar
validation-api-1.0.0.GA.jar
commons-logging-1.1.1.jar
hibernate-validator-4.0.2.GA.jar
slf4j-api-1.5.6.jar
slf4j-log4j12-1.5.6.jar
standard.jar
commons-fileupload-1.1.1.jar
ESAPI-1.4.4.jar
I am guessing the issues can be but need guidance to solve it:
After researching the issue, 2 likely scenarios came to the forefront:
Hibernate Validator Library has a bug resulting in a dependency on JDK 6
Hibernate Validator has a dependency on the JAXBException Class, and the class is not present in the existing Weblogic Environment
Upon further research, the hibernate-validator-4.0.2.jar build states a clear dependency on JDK 5.
Digging deeper into the Hibernate Validator code, it appears that version 4.0.2 relies on JAXB API 2.1.
Weblogic servers are on java 1.5 and code is also compiled on java 1.5 then why the exceptions seems to pop up??

You're being bitten by JAr incompatibilities. Your project has one version of the JAR, but WebLogic has another. The two don't match. (This is what OSGi was born to solve.)
You'll need to tell WebLogic which JAR you prefer. There's a setting in the weblogic.xml for "prefer WAR file JARs." I'm sorry, I can't recall the exact tag name; please Google for it.

java.lang.IllegalArgumentException: Sniffers with type [ejb] and type [appclient] should not claim the archive at the same time

Environment: GlassFish 3.0.1, NetBeans 6.9, JDK 6u21
Also tested with GlassFish 3.0.1, NetBeans 6.9.1, JDK 6u22, but results are the same.
Problem: Unable to run app-client in an enterprise application (app-client, ejb, war).
The EJB jar has only Local interfaces and contains no main methods.
GlassFish Message
SEVERE: Exception while deploying the app
java.lang.IllegalArgumentException: Sniffers with type [ejb] and type [appclient] should not claim the archive at the same time. Please check the packaging of your archive [C:\Users\myUser\.netbeans\6.9\config\GF3\domain1\applications\fabench-app-client]
at com.sun.enterprise.v3.server.SnifferManagerImpl.validateSniffers(SnifferManagerImpl.java:221)
at com.sun.enterprise.v3.server.ApplicationLifecycle.setupContainerInfos(ApplicationLifecycle.java:426)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:262)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:183)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:272)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:305)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:320)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1176)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$900(CommandRunnerImpl.java:83)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1235)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1224)
at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:365)
at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:204)
at com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:166)
at com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:100)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:245)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:791)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:693)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:954)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:170)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:135)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:102)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:88)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:76)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:53)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:57)
at com.sun.grizzly.ContextTask.run(ContextTask.java:69)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:330)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:309)
at java.lang.Thread.run(Thread.java:619)
NetBeans run message
Building jar: F:\NetBeansProjects\fabench\fabench-app-client\dist\fabench-app-client.jar
dist:
pre-run-deploy:
Distributing F:\NetBeansProjects\fabench\fabench-app-client\dist\fabench-app-client.jar to [GlassFish Server 3]
deploy?path=F:\NetBeansProjects\fabench\fabench-app-client\dist\fabench-app-client.jar&name=fabench-app-client&force=true failed on GlassFish Server 3
F:\NetBeansProjects\fabench\fabench-app-client\nbproject\build-impl.xml:716: The module has not been deployed.
BUILD FAILED (total time: 0 seconds)
application-client.xml
This contains only the <display-name> tag filled, but <ejb-ref> can also be specified with a <remote> interface. There is no <local> tag, so I guess app-client is only able to work with Remote interfaces. Is this true?
What could be the problem here?
Any help or ideas would be appreciated!
Thanks in advance,
wheelie

Not a Glassfish expert, but it sounds like the jar is being seen as both an ejb jar and an app client jar. If that's the case, it is not a valid app. First thing I'd check is to ensure your app client jar does not have either:
A META-INF/ejb-jar.xml
Any classes annotated with #Stateless, #Singleton, #Stateful or #MessageDriven
On the other question, right, application clients are remote clients and by definition cannot talk to beans using their #Local interface.

App-client accesses EJBs via Remote interfaces
Since GlassFish v3, Remote interfaces has to be packed inside a Java Class Library, so interfaces are distributable.
App-client has to be inside an enterprise application EAR (but not strictly the same EAR with EJB and WAR).
The tutorial under http://netbeans.org/kb/docs/javaee/entappclient.html explains how to create an app-client, however it doesn't work for me; there is also a question for that matter: Unable to run app-client that is accessing an EJB on GlassFish v3.

Deploy war through netbeans onto glassfish v3 beta

The same .war file deploys fine onto Glassfish v2.1. I don't know the last time I tried v3, but I was wanting to check out hot-deploy functionality as it's rumored to be working in netbeans 6.8 with glassfish v3. So, I deploy just like usual and I get the following error:
SEVERE: Exception while invoking class org.glassfish.ejb.startup.EjbDeployer load method
....
SEVERE: Exception while loading the app
java.lang.RuntimeException: Unable to load EJB module. DeploymentContext does not contain any EJB Check archive to ensure correct packaging for c:\src\svn\trunk\gui\target\WEBAPP
at org.glassfish.ejb.startup.EjbDeployer.load(EjbDeployer.java:134)
at org.glassfish.ejb.startup.EjbDeployer.load(EjbDeployer.java:64)
at org.glassfish.internal.data.ModuleInfo.load(ModuleInfo.java:153)
at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:220)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:314)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:169)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:272)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:305)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:320)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1159)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$900(CommandRunnerImpl.java:83)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1218)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1207)
at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:362)
at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:201)
at com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:166)
at com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:100)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:241)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:789)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:697)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:951)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:166)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:135)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:102)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:88)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:76)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:53)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:57)
at com.sun.grizzly.ContextTask.run(ContextTask.java:69)
at com.sun.grizzly.util.FixedThreadPool$BasicWorker.doWork(FixedThreadPool.java:431)
at com.sun.grizzly.util.FixedThreadPool$BasicWorker.run(FixedThreadPool.java:410)
at java.lang.Thread.run(Thread.java:619)
I don't understand why it's complaining about anything EJB related since this is a .war file. Any ideas?
UPDATE: I filed a bug with glassfish: https://glassfish.dev.java.net/issues/show_bug.cgi?id=10592. Either this is a bug in glassfish or at the very least the error message is not helpful in tracking the problem down.

https://glassfish.dev.java.net/issues/show_bug.cgi?id=10592
From the bug:
Ok, found the cause (thanks much for providing the test case!):
EjbSniffer was retrieved after scanning the archive: one (or more) of the
library jars packaged in the archive contains EJBs with component annotations.
So the ejb container was asked to load the module later.
The ejb container was not able to find the corresponding metadata because the
web.xml is 2.4 version so the meta-data processing skipped the annotation
processing (we only process annotations for Java EE 5+ schema versions).
After I changed the web.xml to reference 2.5 schema (you can do 3.0 schema as well):
http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd">
The app deployed successfully.
Please give it a try and let me know if it works for you.

I have 3_0 schema and I still get the error. What's more interesting is I have two wars, one is the example project from weld archetype, and the other is a customization of that. The custom war doesn't work.
I've checked side by side, it's the same except for more model classes and more properties in persistence.xml

Someone using the #Stateless annotations in ManagedBeans is reporting a similar problem on the java.net Forums.
I don't know if this applies to you but the given workaround was:
Go to the admin console, go to the update center, and install EJB.
I didn't test it myself so I can't confirm this will help.

Just my $0.02...
I had the same error after I added the JaxMe library (version 0.5.2) to my application. This caused a deployment failure on one of my war modules - which confused the hell out of me, because I didn't make any changes to that module. Removing JaxMe fixed the problem.