<< Back to previous view

[GLASSFISH-16937] Having REST services in separate WARs in a single EAR prints classloading warnings Created: 01/Jul/11  Updated: 17/Mar/14

Status: Open
Project: glassfish
Component/s: web_container
Affects Version/s: 3.1
Fix Version/s: 4.0.1

Type: Bug Priority: Minor
Reporter: mmuller Assignee: Daniel
Resolution: Unresolved Votes: 10
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows Server 2008


File Attachments: File ear-1.0.ear     GZip Archive jaxrs_multimodule_test.tar.gz    
Tags: jax-rs glassfish-3-1 classloader
Participants: andrey.v.markelov, Dan.Daneasa, Daniel, geturnerlmco, hpgisler, mmuller, nabizamani, obfischer, pettymt, phealy, Shing Wai Chan and yonatan

 Description   

Warnings show up when an EAR is deployed, containing more than one WAR archove with REST web services. Looks like GlassFish/Jersey tries to load all the REST service classes for each of the WARs being deployed, and then shows classloader warnings:

WEB9052: Unable to load class <classname>, reason: java.lang.ClassNotFoundException: <classname>

I did a minimal project which produces an EAR with this structure:

ear-1.0.ear

  • META-INF/
`- application.xml
  • war-1-1.0.war
 
  • classes/
  `- test/war1/Service1.class
`- WEB-INF/
`- web.xml
`- war-2-1.0.war
  • classes/
`- test/war2/Service2.class
`- WEB-INF/
`- web.xml

(See the attached maven project).

test.war1.Service1 and test.war2.Service2 are POJOs with class-level @Path annotation and method-level @GET or @POST annotations.
The application.xml DD is generated by maven-ear-plugin and only contains the two webmodules and their contextroots.
Both web.xml only contain a display name and the Jersey ServletContainer loaded on startup.

When deploying to GlassFish 3.1 on Windows Server 2008, the log contains the following entries:

[#|2011-07-01T10:45:59.159+0200|WARNING|glassfish3.1|javax.enterprise.system.container.web.org.glassfish.web.loader|_ThreadID=183;_ThreadName=Thread-1;|WEB9052: Unable to load class test.war2.Service2, reason: java.lang.ClassNotFoundException: test.war2.Service2|#]

[#|2011-07-01T10:45:59.187+0200|INFO|glassfish3.1|com.sun.jersey.api.core.WebAppResourceConfig|_ThreadID=23;_ThreadName=Thread-1;|Scanning for root resource and provider classes in the Web app resource paths:
/WEB-INF/lib
/WEB-INF/classes|#]

[#|2011-07-01T10:45:59.187+0200|INFO|glassfish3.1|com.sun.jersey.api.core.ScanningResourceConfig|_ThreadID=23;_ThreadName=Thread-1;|Root resource classes found:
class test.war1.Service1|#]

[#|2011-07-01T10:45:59.187+0200|INFO|glassfish3.1|com.sun.jersey.api.core.ScanningResourceConfig|_ThreadID=23;_ThreadName=Thread-1;|No provider classes found.|#]

[#|2011-07-01T10:45:59.187+0200|INFO|glassfish3.1|com.sun.jersey.server.impl.application.WebApplicationImpl|_ThreadID=23;_ThreadName=Thread-1;|Initiating Jersey application, version 'Jersey: 1.5 01/14/2011 12:36 PM'|#]

[#|2011-07-01T10:45:59.354+0200|INFO|glassfish3.1|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=183;_ThreadName=Thread-1;|WEB0671: Loading application ear-1.0#war-1-1.0.war at [/war1]|#]

[#|2011-07-01T10:45:59.368+0200|WARNING|glassfish3.1|javax.enterprise.system.container.web.org.glassfish.web.loader|_ThreadID=183;_ThreadName=Thread-1;|WEB9052: Unable to load class test.war1.Service1, reason: java.lang.ClassNotFoundException: test.war1.Service1|#]

[#|2011-07-01T10:45:59.382+0200|INFO|glassfish3.1|com.sun.jersey.api.core.WebAppResourceConfig|_ThreadID=23;_ThreadName=Thread-1;|Scanning for root resource and provider classes in the Web app resource paths:
/WEB-INF/lib
/WEB-INF/classes|#]

[#|2011-07-01T10:45:59.382+0200|INFO|glassfish3.1|com.sun.jersey.api.core.ScanningResourceConfig|_ThreadID=23;_ThreadName=Thread-1;|Root resource classes found:
class test.war2.Service2|#]

[#|2011-07-01T10:45:59.382+0200|INFO|glassfish3.1|com.sun.jersey.api.core.ScanningResourceConfig|_ThreadID=23;_ThreadName=Thread-1;|No provider classes found.|#]

[#|2011-07-01T10:45:59.382+0200|INFO|glassfish3.1|com.sun.jersey.server.impl.application.WebApplicationImpl|_ThreadID=23;_ThreadName=Thread-1;|Initiating Jersey application, version 'Jersey: 1.5 01/14/2011 12:36 PM'|#]

[#|2011-07-01T10:45:59.521+0200|INFO|glassfish3.1|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=183;_ThreadName=Thread-1;|WEB0671: Loading application ear-1.0#war-2-1.0.war at [/war2]|#]

[#|2011-07-01T10:45:59.535+0200|INFO|glassfish3.1|javax.enterprise.system.tools.admin.org.glassfish.deployment.admin|_ThreadID=183;_ThreadName=Thread-1;|ear-1.0 was successfully deployed in 543 milliseconds.|#]

So this looks like Glassfish tries to load both services for each WAR module. When loading war-1, it cannot load test.war2.Service2, and while loading war-2, it cannot load test.war1.Service1...
Although, the application is correctly deployed and all the services do work !!

I guess this is a tiny bug, and could be fixed within a handful of lines. I could try to fix it, if someone could point me to the right module producing this warning.



 Comments   
Comment by mmuller [ 01/Jul/11 09:02 AM ]

Oops, looks like Jira didn't like my folder-tree syntax.

So, the EAR structure is

ear-1.0.ear
  META-INF/
    application.xml
  war-1-1.0.war
    classes/
      test/war1/Service1.class
    WEB-INF/
      web.xml
  war-2-1.0.war
    classes/
      test/war2/Service2.class
    WEB-INF/
      web.xml
Comment by Shing Wai Chan [ 01/Jul/11 10:08 PM ]

The calling stack is as follows:
StandardContext#callServletContainerInitializer
--> ServletContainerInitializerUtil#getInitializerList
--> ServletContainerInitializerUtil#checkAgainstInterestList

and the warning is coming from calling the checkAgainstInterestList method

The issue is from argument of calling the last method as follows:
1. Types classInfo contains the classes information for the ear
which is from WebModule#getTypes
wmInfo.getDeploymentContext().getTransientAppMetaData(
Types.class.getName(), Types.class);
2. WebappClassLoader cl, for war1, say, then it cannot load classes for war2

Even though the returned value of the method is correct, there is unnecessary call for loading other classes.

Comment by geturnerlmco [ 13/Oct/11 10:32 PM ]

This happens if there are multiple WARs, period. I have an application with 5 WARs, two are SOAP service endpoints and 3 are REST. If I remove 2 of the 3 REST WARS, I still get the WARNINGS. If I remove the 2 SOAP WARs, the WARNINGS are gone. I have searched every forum for an answer to this annoying problem, but this is the first one that is the closest to my problem. If anyone has a workaround other than destroying my EAR structure (which doesn't work well for fielding, ha ha) I would really appreciate knowing it.

Comment by geturnerlmco [ 14/Oct/11 02:45 AM ]

One additional comment that I thought would be helpful. I commented out all of the additional WARs from my application.xml but still built the EAR normally. The WARNINGS occured, just because the modules existed in the EAR directory structure, but the module definitions were commented out! Is the class scanner looking for ANY .class file in the EAR directory, whether it was defined to be part of the application or not???

Comment by Dan.Daneasa [ 23/Oct/11 10:32 AM ]

I have more comments on this.
I have 2 wars deployed in the same ear. One is a Jersey simple west app, the other one is an empty war.
I can see the ClassNotFoundExceptions.

There may be more to this problem. If i have an ear with 2 wars, one is a simple Jersey rest app, the other a simple Mojarra faces app. I see that the ClassNotFoundException is still present, also there are Mojarra-impl ClassNotFoundException warnings.
The same happens if i try to integrate MyFaces instead of Mojarra in the faces webapp.
Mojarra/Myfaces tries to load in the Jersey app as well, and vice-versa, Jersey tries to load in the Mojarra/MyFaces app.

If I have only one of the wars in the ear in any of the above combinations then the warnings are not present.

Comment by hpgisler [ 14/Nov/11 12:46 PM ]

Just for the record: Same problem here.

Two WAR's in an EAR
1. WAR JSF frontend
2. WAR REST frontend

If packaging only one of them into EAR, no problem; if packaging both inside EAR, Problem.

Comment by pettymt [ 10/Apr/12 03:55 AM ]

Confirmed on v3.1.1 (build 12)

30 WARs(each containing a REST service) in an EAR is a lot of warnings.

Comment by phealy [ 27/Mar/13 02:47 AM ]

I am getting a warning for every PimesFaces class every time I deploy (because I also have a Jersey app in my EAR). This does not reflect well on Glassfish.

Comment by nabizamani [ 13/Apr/13 12:30 PM ]

I have the same issue with GlassFish 3.1.2.2 (build 5) when deploying an EAR containing 2 wars and 1 ejb module (one of the wars contains restful web services).

Example:
WARNING: WEB9052: Unable to load class com.demo.service.exception.RestExceptionCatcher, reason: java.lang.ClassNotFoundException: com.demo.service.exception.RestExceptionCatcher
WARNING: WEB9052: Unable to load class com.demo.service.Order, reason: java.lang.ClassNotFoundException: com.demo.service.Order

RestExceptionCatcher is a @Provider and implements ExceptionMapper<Throwable>.
Order is a very simple REST service.

These warnings are very frustrating and I really want to get rid of them! But that would means I cannot use my EAR

Comment by yonatan [ 01/May/13 07:51 AM ]

If everything works properly, until the issue is resolved you can raise the logging level of that specific logger by adding javax.enterprise.system.container.web.org.glassfish.web.loader.level=SEVERE to the DOMAIN_HOME/config/logging.properties file.

Comment by andrey.v.markelov [ 07/May/13 06:20 AM ]

I have got the same trouble. Are you going to fix that?

Comment by Shing Wai Chan [ 25/Jun/13 06:29 PM ]

The given test case may need to update for GlassFish 4.

Comment by Daniel [ 25/Jun/13 10:54 PM ]

The web.xml for GF4 should use org.glassfish.jersey.servlet.ServletContainer API instead.

Comment by obfischer [ 17/Mar/14 10:02 PM ]

Is there a chance to get this fixed in the near future? Our monitoring reports all log messages with a log level above INFO. It is very annoying to warnings for a non-existent problem.

Generated at Thu Apr 24 13:21:04 UTC 2014 using JIRA 4.0.2#472.