Skip to main content

EJB Module with Entity class in library

14 replies [Last post]
gadnex
Offline
Joined: 2007-12-14

I am using Netbeans 6.8RC1 and Glassfish v3-b73 to develop an EJB module that contains a EJB session bean.

The session bean instantiates and persists an entity class that I developed in a standard Java application project.

Everything compiles fine, but when I try and deploy to Glassfish I get the error:

-------------------------------------------------------------------------------------------------
SEVERE: Class [ org/gadnex/vehicle/entity/VehicleException ] not found. Error while loading [ class org.gadnex.vehicle.ejb.VehicleSessionBean ]
WARNING: Error in annotation processing: java.lang.NoClassDefFoundError: org/gadnex/vehicle/entity/VehicleException
SEVERE: Exception while deploying the app
java.lang.IllegalArgumentException: Invalid ejb jar [VehicleEJB]: 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.
-------------------------------------------------------------------------------------------------

If I move my Vehicle and VehicleException classes to the EJB project it compiles and deployes fine.

I specifically want my entity classes to be in a separate Java project and thus jar file, so that I can reuse my entity classes in my Swing front end application as well.

I used to be able to do this with Netbeans 6.7 and Glassfish v2ur2 without any problems.

Any help will be apreciated.

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

The Manifest mechanism only applies to the modules packaged inside ear and not standalone modules, but it's not really relevant here as the jar as attached could deploy to v2 successfully. :-)

Looking at the v2 code, it seems it added all the root level jars of the modules to the classpath regardless of whether the libraries are referenced or not. This is why the application could deploy to v2 successfully. This is not a spec defined behavior which is not supported in v3 now. We can probably expand the functionality of "compatibility" property to include module level jars as part of the jar visibility backward compatibility support in v3.1.

gadnex
Offline
Joined: 2007-12-14

Thanks very much for all the help and answering my question.

I think it would be really great if this could be added to V3.1 for the purpose of backward compatibility support. In the mean time I will have to use the asadmin --library deploy option.

It is also good to know that this is not part of the Java EE spec and that there would probably be some deployment issues on other app servers as well.

I think it is actually a pity the Java EE spec does not address this as I think it is a really good and interesting design pattern to use.

What I like about this pattern is that I can use the entity class as an input parameter or return type of a JAX-WS web service, where I can code the entity class once and include it as a library to my EJB or EAR file and also the UI project. With the inclution of bean validation in Java EE 6, I think this pattern makes more sense than ever.

I am actually planning to create a Netbeans tutorial (or perhaps a series of tutorials) of this pattern. I am mainly waiting for the release of JavaFX 1.3 and the preview of the new JavaFX GUI builder in Netbeans 6.8.

hzhang_jn
Offline
Joined: 2005-07-22

One additional note, there are spec defined ways to include library jars as part of the ear, either to place libraries in the ear application library directory or through Manifest Class-Path.

gadnex
Offline
Joined: 2007-12-14

Just one last question. In your previous post on this topic you said that this feature could possibly be added to Glassfish V3.1 for backwards compatibility with V2.

I just want to know whether I need to log a defect or something to ensure that this request will be on the radar of the Glassfish dev team. This feature is really important to me and I just want to ensure it gets addressed.

Currently I am in two minds of whether to move to GF V3 or to stick with GF V2. The lack of this feature makes it more difficult to deploy and test on V3, but on the other hand I am really interested in using the Bean Validation (JSR 303) and new EJB3.1 features only found in V3.

hzhang_jn
Offline
Joined: 2005-07-22

Forgot to answer this part earlier, the request was added to this enhancement:
https://glassfish.dev.java.net/issues/show_bug.cgi?id=10496

hzhang_jn
Offline
Joined: 2005-07-22

This part of the enhancement was added into v3.1 now (root level libraries of standalone ejb jar now will be added to the classpath when the property "compatibility" is specified as "v2").

edmondo1984
Offline
Joined: 2009-02-17

Dear all,
you seem to able to help me :)

I was having the same problem and I tried with asadmin like the following:

asadmin deploy --libraries .\blpjavaapi.jar .\Gotware-ejb.jar

However, I obtain a big error... it looks like the class it is not defined

GRAVE: com/bloomberglp/blpapi/EventHandler
java.lang.NoClassDefFoundError: com/bloomberglp/blpapi/EventHandler
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClassCond(ClassLoader.java:632)
at java.lang.ClassLoader.defineClass(ClassLoader.java:616)
at com.sun.enterprise.loader.ASURLClassLoader.findClass(ASURLClassLoader.java:686)
at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
at org.glassfish.weld.BeanDeploymentArchiveImpl.collectJarInfo(BeanDeploymentArchiveImpl.java:240)
at org.glassfish.weld.BeanDeploymentArchiveImpl.populate(BeanDeploymentArchiveImpl.java:225)
at org.glassfish.weld.BeanDeploymentArchiveImpl.(BeanDeploymentArchiveImpl.java:102)
at org.glassfish.weld.DeploymentImpl.(DeploymentImpl.java:118)
at org.glassfish.weld.WeldDeployer.load(WeldDeployer.java:315)
at org.glassfish.weld.WeldDeployer.load(WeldDeployer.java:99)
at org.glassfish.internal.data.ModuleInfo.load(ModuleInfo.java:175)
at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:216)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:338)
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)
Caused by: java.lang.ClassNotFoundException: com.bloomberglp.blpapi.EventHandler
at com.sun.enterprise.loader.ASURLClassLoader.findClassData(ASURLClassLoader.java:736)
at com.sun.enterprise.loader.ASURLClassLoader.findClass(ASURLClassLoader.java:626)
at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
... 42 more

I had check, however, and the class is there..any idea
Thank you very much

gadnex
Offline
Joined: 2007-12-14

As i said I would do, I used Netbeans 6.7.1 and Glassfish v2ur2 this weekend to create an EJB that uses an entity class in a library file.

It worked perfectly on glassfish v2ur2, but when I tried to deploy the same jar (EJB jar) to Glassfish v3-b73 it failed with the same error message as before.

I have attached the compiled EJB jar file to deploy on glassfish. All you need to deploy it is a JDBC resouce where the JNDI name is "jdbc/vehicle".

It needs to be deployed as an jar (EJB jar) not an EAR file. I rely completely on Netbeans to structure the file for me.

After being deployed you can use the Glassfish web servise test client to add vehicles to the database.

Message was edited by: gadnex

Alexis Moussine-Pouchkine

extracting (and eventually removing) VehicleEntity.jar from the EJB
JAR and deploying with :
asadmin deploy --libraries ~/VehicleEntity.jar ~/VehicleEJB.jar
works for me.

The Java EE spec (EE.8.2.1 Bundled Libraries) says that you can bundle
libraries in "Java EE application packages" (which I understand
includes ejb-jar files) and reference them using a "Class-Path" header
in the EJB-JAR manifest.

NetBeans 6.7 is not adding this to the manifest (and 6.8 RC2 acts the
same). Even when adding it by hand, it doesn't seem to be picked up at
deployment.
I don't know if this is because the library is an @Entity. Hong would
know I'm sure.

Of course you can now package your EJB in a WAR or create the EAR and
declare library as explained in an earlier answer.

-Alexis

On Dec 7, 2009, at 9:15, glassfish@javadesktop.org wrote:

> As i said I would do, I I used Netbeans 6.7.1 and Glassfish v2ur2
> this weekend to create an EJB that uses an entity class in a library
> file.
>
> It worked perfectly on glassfish v2ur2, but when i tried to deploy
> the same jar (EJB jar) to Glassfish v3-b73 it failed with the same
> error message as before.
>
> I have attached the compiler EJB jar file to deploy on glassfish.
> All you need to deploy it is a JDBC resouce where the JNDI name is
> "jdbc/vehicle".
>
> It need to be deployed as an jar (EJB jar) not an EAR file. I rely
> completely on Netbeans to structure the file for me.
>
> After being deployed you can use the Glassfish web servise test
> client to add vehicles to the database.
> [Message sent by forum member 'gadnex' ]
>
> http://forums.java.net/jive/thread.jspa?messageID=375093
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

gadnex
Offline
Joined: 2007-12-14

Thanks Alexis

It is great to know that at least it is possible to deploy the application to glassfish v3.

I don't usually deploy with asadmin, because I deploy from Netbeans while developing. In fact, the Netbeans deploy on save is sometimes handy as well.

You haven't perhaps tried to deploy to glassfish v2, because that works 100% for me.

It seems that glassfish v2 does some additional stuff while deploing, that v3 does not. I hope this will be added back in at some point in v3.

hzhang_jn
Offline
Joined: 2005-07-22

So the entity jar is a standalone jar that needs to be referenced by the ejb jar?
You can use the --libraries option to specify a library jar that's needed for the application but not bundled inside the application, you can find more details of the libraries option here:
http://docs.sun.com/app/docs/doc/820-7701/deploy-1?a=view

gadnex
Offline
Joined: 2007-12-14

Thanks, I will try it out your advise over the weekend.

My home PC still had Netbeans 6.7.1 and Glassfish v2ur2 installed. I will also create and test a Java EE 5 application with the entity in a separate jar and make sure it works on that platform. If it does I wil try to deploy on Glassfish v3-b73 and see what happens. That will help me confirm if the issue is on the Netbeans or Glassfish side.

The design pattern I used in the past is actually quite elegant in my opinion, so my first choice would be to use that pattern with Netbeans 6.8 and Glassfish v3.

I will respond again on Monday.

hzhang_jn
Offline
Joined: 2005-07-22

One additional note, if the entity jar is currently packaged as a library jar inside the ear which contains the ejb jar, the library jar needs to be placed in the application library directory of the ear (default is the "lib" from the ear root level) for the library jar to be visible to the component modules.

gadnex
Offline
Joined: 2007-12-14

I think my problem has smething to do with this forum post:

http://forums.java.net/jive/message.jspa?messageID=214039