Skip to main content

"Contains no EJBs"...but it does, and no server.log errors

4 replies [Last post]
ljnelson
Offline
Joined: 2003-08-04

Hello; this morning we attempted to deploy our ear file on build 26.

The .ear file has worked fine for weeks.  It consists of a bunch of EJB jars with their shared dependency jars in the lib directory.

This morning it said that one of those EJB jars was invalid (?) because it contained no EJBs.  But, of course, it does, and they haven't changed.

The message said to check the server.log for other errors.  There were none.

Here is the stack.  I apologize in advance for any formatting mistakes, as the forum editor has become (unbelievably) even more brain dead and unusable than before:

[#|2010-11-08T07:11:11.004-0500|SEVERE|glassfish3.1|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=17;_ThreadName=Thread-1;|Exception while deploying the app [ngp-financial-sa-ear-1.0-SNAPSHOT]|#]

[#|2010-11-08T07:11:11.004-0500|SEVERE|glassfish3.1|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=17;_ThreadName=Thread-1;|Invalid ejb jar [ngp-constituent-ejb-1.0-SNAPSHOT.jar]: it contains zero ejb.
Note:
1. A valid ejb jar requires at least one session, entity (1.x/2.x style), or message-driven bean.
2. EJB3+ entity beans (@Entity) are POJOs and please package them as library jar.
3. If the jar file contains valid EJBs which are annotated with EJB component level annotations (@Stateless, @Stateful, @MessageDriven, @Singleton), please check server.log to see whether the annotations were processed properly.
java.lang.IllegalArgumentException: Invalid ejb jar [ngp-constituent-ejb-1.0-SNAPSHOT.jar]: it contains zero ejb.
Note:
1. A valid ejb jar requires at least one session, entity (1.x/2.x style), or message-driven bean.
2. EJB3+ entity beans (@Entity) are POJOs and please package them as library jar.
3. If the jar file contains valid EJBs which are annotated with EJB component level annotations (@Stateless, @Stateful, @MessageDriven, @Singleton), please check server.log to see whether the annotations were processed properly.
    at com.sun.enterprise.deployment.util.EjbBundleValidator.accept(EjbBundleValidator.java:76)
    at com.sun.enterprise.deployment.util.ApplicationValidator.accept(ApplicationValidator.java:128)
    at com.sun.enterprise.deployment.EjbBundleDescriptor.visit(EjbBundleDescriptor.java:727)
    at com.sun.enterprise.deployment.Application.visit(Application.java:1768)
    at com.sun.enterprise.deployment.archivist.ApplicationArchivist.validate(ApplicationArchivist.java:794)
    at com.sun.enterprise.deployment.archivist.ApplicationArchivist.openWith(ApplicationArchivist.java:273)
    at com.sun.enterprise.deployment.archivist.ApplicationFactory.openWith(ApplicationFactory.java:239)
    at org.glassfish.javaee.core.deployment.DolProvider.load(DolProvider.java:170)
    at org.glassfish.javaee.core.deployment.DolProvider.load(DolProvider.java:93)
    at com.sun.enterprise.v3.server.ApplicationLifecycle.loadDeployer(ApplicationLifecycle.java:766)
    at com.sun.enterprise.v3.server.ApplicationLifecycle.setupContainerInfos(ApplicationLifecycle.java:708)
    at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:347)
    at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:243)
    at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:351)
    at com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:354)
    at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:369)
    at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1079)
    at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1200(CommandRunnerImpl.java:95)
    at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1256)
    at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1245)
    at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:396)
    at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:216)
    at com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:168)
    at com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:117)
    at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:234)
    at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:817)
    at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:718)
    at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1007)
    at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
    at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
    at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
    at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
    at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
    at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
    at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
    at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
    at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
    at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
    at java.lang.Thread.run(Thread.java:680)
|#]

I can't reproduce this in a test case, because I'm not sure how to create a valid EJB jar that is then treated as invalid.

Is this error "code" for anything else?  Could this indicate a name collision, or something else entirely?

Thanks,
Laird

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
hzhang_jn
Offline
Joined: 2005-07-22

Can you share a little bit more about the packaging of the ngp-constituent-ejb-1.0-SNAPSHOT.jar aa you cannot share the test case? Is the EJB bean class with the component annotation packaged directly inside this jar? Does the bean class reference some other classes somewhere else (if for some reason the referenced class could not be loaded, that' will affect the annotation processing which might lead server to think there is no valid EJB in the jar).
In the server.log, before this part of the error message, is there anything about annotation processing failed (hint #3 of the error message)?
If you deploy this ear to the latest nightly build, does it make a difference?

ljnelson
Offline
Joined: 2003-08-04

EJB is at the root level of the EJB jar.

EJB refers to other classes that have lived in the .ear's lib directory for almost a year :-)

No additional errors in the server.log.

We're digging to see what else might be going on.  Does the OSGI cache contain results from a previous run?  We've seen the application server run out of memory before while on some kind of hk2 class modeling timer, with nuggets like this:

[#|2010-11-07T18:29:51.848-0500|SEVERE|glassfish3.1|javax.enterprise.system.tools.admin.org.glassfish.deployment.admin|_ThreadID=17;_ThreadName=Thread-1;|Exception while visiting org/apache/xalan/res/XSLTErrorResources_ko.class of size 39332
java.lang.OutOfMemoryError: Java heap space
    at org.objectweb.asm.ClassReader.accept(Unknown Source)
    at org.objectweb.asm.ClassReader.accept(Unknown Source)
    at org.glassfish.hk2.classmodel.reflect.Parser$5.on(Parser.java:313)
    at com.sun.enterprise.v3.server.ReadableArchiveScannerAdapter.onSelectedEntries(ReadableArchiveScannerAdapter.java:102)
    at org.glassfish.hk2.classmodel.reflect.Parser.doJob(Parser.java:297)
    at org.glassfish.hk2.classmodel.reflect.Parser.access$200(Parser.java:62)
    at org.glassfish.hk2.classmodel.reflect.Parser$3.call(Parser.java:260)
    at org.glassfish.hk2.classmodel.reflect.Parser$3.call(Parser.java:249)
    at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
    at java.util.concurrent.FutureTask.run(FutureTask.java:138)
    at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
    at java.lang.Thread.run(Thread.java:680)

I don't know what this code is doing, or what thread it's coming from.  We're starting this particular Glassfish up with the default options, so -Xmx512m and a permgen of 192M.

I emphasize that these OOME occur before this particular startup.

L

hzhang_jn
Offline
Joined: 2005-07-22

Not familiar with felix, but there was a felix regression in glassfish build 26:
https://issues.apache.org/jira/browse/FELIX-2646
Not sure if this is related. The regression was fixed in the felix code already, but not sure when it was (or will be) intergrated to the glassfish.

ljnelson
Offline
Joined: 2003-08-04

The other interesting thing is that the server.log contains out of memory errors before the JVM invocation that started this server.

So at some time in the past, the server ran out of memory and was killed.  Then my colleague did an asadmin start-domain, and ran an asadmin deploy our/ear/file, the results of which you see here.

I've noticed on many occasions that the Felix cache, whatever that is (I know it has to do with OSGI, about which I remain blissfully ignorant, and about which I wish to remain blissfully ignorant :-)), when removed, cleans lots of things up.

Is it possible that the cache--whatever it caches--has some stale corrupt information left over from an OOME that is impacting *this* startup?

Best,
Laird