|
Replies:
8
-
Last Post:
Feb 22, 2006 7:24 AM
by: dibyendumajumdar
|
|
|
|
|
|
|
Packaging Entity Beans
Posted:
Feb 14, 2006 3:22 AM
|
|
|
Hi All,
I'd like to canvas your views about how to package entity beans. My objectives are to achieve reusability so that I can deploy the entities in different environments such as:
1. J2EE containers
2. Servlet containers
3. J2EE clients
4. J2SE environments
Most examples you come across package the entity beans together with the rest of the system in a single EAR. However, this is not the best way of achieving flexibility and reusability, as it is easy to build dependencies between the persistence layer and the rest of the system.
I have been experimenting with two options:
Option 1
--------
1. Entities have their own independent project, and are packaged in a jar file along with the persistence.xml file.
2. A set of Enterprise Beans are defined to act as the Data Access layer. These work with entities and manage persistence. The idea is that the Data Access layer hides details of how the entities are persisted, and it should be possible in theory to implement pure JDBC code here rather than using EJB 3.0 persistence. Anyway, the EJBs are packaged in a separate jar file and have their own independent project.
Option 2
--------
In this option, I combine the entities and the corresponding EJBs in the same package/project.
Now, my question is, which of these two options would you prefer and why?
Secondly, is it a worthwhile goal to allow the entities to be reusable outside the J2EE container? I think it is, but the issue is that to be truly reusable, you must avoid depending upon functionality that is specific to J2EE containers.
Regards
Dibyendu
|
|
|
|
|
|
|
Re: Packaging Entity Beans
Posted:
Feb 14, 2006 6:46 PM
in response to: dibyendumajumdar
|
|
|
Option #1 where you package entities in a separate jar file.
Advantages:
#1 Improves number of ways your jar can be used unmodified.
e.g. You can drop the jar file into a stand alone web application's lib directory (war/WEB-INF/lib) and just deploy the web application into container.
#2 Easier packaging:
If the entities are served by an EJB, then the clients of the EJB any way should have the entities in their CLASSPATH. In such a case, you can just place the entities.jar in the EAR's lib directory and they automatically are made available to all other modules in an ear.
#3 You can test the entities.jar outside of container easily.
No disadvantage that I know of. That's why I followed this approach in my article at http://weblogs.java.net/blog/ss141213/archive/2005/12/using_java_pers.html
Thanks,
Sahoo
|
|
|
|
|
|
|
|
|
Re: Packaging Entity Beans
Posted:
Feb 20, 2006 3:13 AM
in response to: ss141213
|
|
|
> Option #1 where you package entities in a separate
> jar file.
> Advantages:
> #1 Improves number of ways your jar can be used
> unmodified.
> e.g. You can drop the jar file into a stand alone
> e web application's lib directory (war/WEB-INF/lib)
> and just deploy the web application into container.
>
> #2 Easier packaging:
> If the entities are served by an EJB, then the
> e clients of the EJB any way should have the entities
> in their CLASSPATH. In such a case, you can just
> place the entities.jar in the EAR's lib directory and
> they automatically are made available to all other
> modules in an ear.
>
> #3 You can test the entities.jar outside of container
> easily.
>
> No disadvantage that I know of. That's why I followed
> this approach in my article at
> http://weblogs.java.net/blog/ss141213/archive/2005/12/
> using_java_pers.html
>
> Thanks,
> Sahoo
Hi Sahoo.
I am not sure why the Entities should be packaged separately from the EJBs that implement the Data Access Layer. They are intimately connected, and also, my objective is to make the EJBs re-usable outside the J2EE container. The way I am doing this is as follows:
1. I define a setter for injecting the EntityManager in the EJB as shown below:
@PersistenceContext(type=PersistenceContextType.TRANSACTION, unitName="em1")
public void setEntityManager(EntityManager entityManager) {
this.entityManager = entityManager;
}
2. When deployed in J2EE, the appropriate EntityManager in injected automatically.
3. When deploying in J2SE, I use a factory class to instantiate the EJB and manually inject the EntityManager. The code under J2SE looks like this:
em = Persistence.createEntityManagerFactory("em2")
.createEntityManager();
System.err.println("Created entity manager");
ServiceFactory sf = new ServiceFactory(em);
WarehouseService ws = sf.getWarehouseService();
I confess I do not fully understand the packaging rules yet.
Regards
Dibyendu
|
|
|
|
|
|
|
|
|
Re: Packaging Entity Beans
Posted:
Feb 20, 2006 8:32 AM
in response to: dibyendumajumdar
|
|
|
Could you guys have a look at my packaging problems in http://forums.java.net/jive/thread.jspa?threadID=13253?
I am trying to access session beans and the persistence manager via injection from JSF. By trial and error, I found that I was forced into a particular layout. I HAD to place the entities (or at least the JAR with persistence.xml) inside lib, and I HAD to place the session beans outside lib. Does that make sense?
Cay
|
|
|
|
|
|
|
|
|
Re: Packaging Entity Beans
Posted:
Feb 21, 2006 7:19 AM
in response to: dibyendumajumdar
|
|
|
Hi Dibyendu,
You asked why entities should be packaged outside the EJB which is providing the data access layer. Good question. I am assuming you are passing the entity beans arounds in the ejb interface. In such a case, a client of your ejb, say a web application, will also require to have the entity classes in its classpath, right? Having entity classes inside ejb.jar it is not necessary that a container makes them available to a war module in that application. So you have to also package the netity classes inside the war again. To avoid this duplication, the easiest option is to have a separate entity.jar in ear lib directory.
With this, you can as well work in Java SE environment, by just having your ejb.jar, entities.jar in CLASSPATH in addition to your application main class.
Thanks,
Sahoo
|
|
|
|
|
|
|
|
|
Re: Packaging Entity Beans
Posted:
Feb 21, 2006 8:19 AM
in response to: ss141213
|
|
|
> Hi Dibyendu,
>
> You asked why entities should be packaged outside the
> EJB which is providing the data access layer. Good
> question. I am assuming you are passing the entity
> beans arounds in the ejb interface. In such a case, a
> client of your ejb, say a web application, will also
> require to have the entity classes in its classpath,
> right? Having entity classes inside ejb.jar it is not
> necessary that a container makes them available to a
> war module in that application. So you have to also
> package the netity classes inside the war again. To
> avoid this duplication, the easiest option is to have
> a separate entity.jar in ear lib directory.
>
> With this, you can as well work in Java SE
> environment, by just having your ejb.jar,
> entities.jar in CLASSPATH in addition to your
> application main class.
>
Yes, I am passing Entity Beans around in the EJB interface. But from the client perspective, the Entity Beans alone aren't enough - clearly the DAO layer is required as well. Hence my thought that perhaps these ought to be packaged together. However, packaging them separately is also fine.
Regards
Dibyendu
|
|
|
|
|
|
|
|
|
Re: Packaging Entity Beans
Posted:
Feb 22, 2006 3:57 AM
in response to: dibyendumajumdar
|
|
|
I remember now what led me to put the Entity Beans in a separate jar in the first place. Since some of the Entity annotations are non-portable - ie - different database systems may require different annotations - I wanted to ensure that I could swap the Entity definitions in and out without impacting the rest of the application. If I wanted to use an Oracle database instead of Derby, all I'd have to do is swap the entity beans. Of course, another option would be use external XML descriptors - but I like this approach more.
Regards
Dibyendu
Dibyendu
|
|
|
|
|
|
|
|
|
Re: Packaging Entity Beans
Posted:
Feb 22, 2006 6:57 AM
in response to: dibyendumajumdar
|
|
|
> I remember now what led me to put the Entity Beans in
> a separate jar in the first place. Since some of the
> Entity annotations are non-portable - ie - different
> database systems may require different annotations -
Can you give some examples of what you meant by entity annotations are non-portable?
> I wanted to ensure that I could swap the Entity
> definitions in and out without impacting the rest of
> the application. If I wanted to use an Oracle
> database instead of Derby, all I'd have to do is swap
> the entity beans.
And why is this not possible when you are packaging entities in a separate jar file?
-- Sahoo
|
|
|
|
|
|
|
|
|
Re: Packaging Entity Beans
Posted:
Feb 22, 2006 7:24 AM
in response to: ss141213
|
|
|
> Can you give some examples of what you meant by
> entity annotations are non-portable?
The Id Generators are an obvious one. Not all databases support SEQUENCES or IDENTITY columns. Another example is if you use columnDefinition attribute in Column annotation.
>
> > I wanted to ensure that I could swap the Entity
> > definitions in and out without impacting the rest
> of
> > the application. If I wanted to use an Oracle
> > database instead of Derby, all I'd have to do is
> swap
> > the entity beans.
>
> And why is this not possible when you are packaging
> entities in a separate jar file?
I think you have misunderstood what I was saying. I am saying that if you put the Entities in a separate jar - then it is easier to swap the entities in/out - all you have to do is replace the jar.
Regards
Dibyendu
|
|
|
|
|
java.net RSS
