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.

Upgrade from Weblogic 10.3.6 to 12.1.3

I installed Weblogic 12.1.3 and have had nothing but problems.
I didn't upgrade an existing domain. I created a new one and tried deploying the application to it. It immediately started bombing out on JSP compilation.
Compilation of JSP File '/WEB-INF/pages/common/layout/MainLayout.jsp' failed:
MainLayout.jsp:112:41: This attribute is not recognized.
<custom:UserMessage type="INFO" message="${TopInfoMsg}" messageContainerId="TopInfoContainDiv" messageDivId="TopInfoMsgDiv" hide="${empty TopInfoMsg}" />
I've tried the following to troubleshoot:
Java 7 and Java 8 (problem occurs in both versions)
Tried the JSP Backwards Compatibility setting in the WLS console
Disabled JRebel
Tried eliminating "xerces hell" as a problem by adding xml-apis to the <prefer-application-packages> in weblogic.xml (also eliminated the tertiary dependency on that package in my Maven POM file).
Put the #page tag with pageEnconding="UTF-8" as the first line of the MainLayout.jsp file.
What I occasionally see is weblogic emptying the contents of the .tag files, but not always.
Any help or troubleshooting ideas would be appreciated.

You should write the content of MainLayout.jsp:112:41 with lines 111 and 113, with its we can try to help you.

Hibernate 5 + Glassfish 4.1.1: java.lang.NoSuchMethodError: org.jboss.logging.Logger.debugf(Ljava/lang/String;I)V

When I add Hibernate 5 to my website, I can't get it to work in Glassfish 4.1.1. I always get an error
java.lang.NoSuchMethodError:
org.jboss.logging.Logger.debugf(Ljava/lang/String;I)V
I've tried to replace the jboss-logging library in Glassfish' modules folder, like I read in an answer to a similar problem, but it didn't change anything. I also tried to use Hibernate 4, but that gave an other error.

In my case, I was running the Hibernate 5 with JPA annotations on tomcat and stop working when I changed to glassfish 4.1
The error:
hibernate.properties not found
Make sure: src/main/resources/hibernate.cfg.xml exists
And if you only have the dependency of hibernate-core, I was using hibernate-annotations and hibernate-common-annotations and it was creating conflict. The hibernate 5 doesnt need these two, I had read somewhere.Try to remove ;)
After that a new error appears:
java.lang.NoSuchMethodError: org.jboss.logging.Logger.debugf(Ljava/lang/String;I)V
The reason was the oldest jboss-logging.jar at:
"YOUR_GLASSFISH_FOLDER/glassfish/modules"
Why? The hibernate 5 has dependency with the newest version of
jboss-logging, and the glassfish 4 uses the oldest version even if you
declare inside your POM file the newest version. Actually I'm using:
org.jboss.logging jboss-logging 3.3.0.Final
Then I downloaded it and replace the old .jar inside the modules path
and it back to work, I spent 2 days trying to solve that and I hope it
helps some future issues =D
I used this link to help me: https://medium.com/#mertcal/using-hibernate-5-on-payara-cc242212a5d6#.npq2hdprz
Another solution, in my case, could be back to the last Hibernate 4 version (4.3.11.Final) but it is already too old in my opinion

I had a similar issue, I was able to fix it by creating a glassfish-web.xml file in the WEB-INF directory. The contents of the file are shown below:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE glassfish-web-app PUBLIC "-//GlassFish.org//DTD GlassFish Application Server 3.1 Servlet 3.0//EN" "http://glassfish.org/dtds/glassfish-web-app_3_0-1.dtd">
<glassfish-web-app>
 <class-loader delegate="false"/>
</glassfish-web-app>
This ensures that glassfish does not load it's internal libraries, but libraries from your project..

Try to clean glassfish osgi-cache folder in your domain. You can find details in this Payara github issue: https://github.com/payara/Payara/issues/554 (Payara is a fork of Glassfish with additional features, so basic mechanics remain the same as in Glassfish)

java.lang.NoClassDefFoundError: javax.servlet.ServletInputStream Error deploying on websphere

I have created a jersey web service with neatbeans using glassfish as my server, everything works fine but i have issues trying to install the same app on websphere 7.
i get this error "Error 500 An error occurred while processing request: /ibm/console/upload.do Message: java.lang.NoClassDefFoundError: javax.servlet.ServletInputStream".
I even tried creating a simple web app and tried to deploy on websphere, again, i have the same error.
Anybody with ideas? I need your help so badly ya'll. Thanks in advance

Make sure you don't have servlet-api.jar in your WEB-INF/lib. If its there it may interfere with the one already present in websphere a trick the classloader

I did below steps which worked for me :
Go to the server in console(which was stand - alone in my case i.e no DMGR)
Change the class loader policy to "multiple".

I suppose I am not too late to reply to this question. The HttpServlet class can be found in the j2ee.jar. WAS does not bundle it in servlet-api.jar, the way Tomcat does it.

You need to bundle servlet-api.jar file in your application.

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.