Nice approach.
Sahoo, I see in the EntitiesActivator that you're producing an "unmanaged"
EMF and wonder if there would be a means to retrieve a container-managed EMF
to achieve the same. The reasoning would be to be able to mange the
DataSource via the GF admin console and receiving all the benefits (pooling,
XA JTA, etc) without having to add on 3rd party libs like C3PO...I think the
question the is how to ensure the startup sequence of the EntitiesActivator
is after the dependent GF bundles....thoughts?
I also see this approach as another step in deployment...which isn't too bad
in managing a single instance, but does this work with clusters? It may
just be another "soft" thing for administrators to get right during
deployment - another headache in my environment =)
Another (possible easier to scale) approach would be to provide the
persistence functions of these entities as a service to the application via
EJBs. In a similar way to already being done, package your entities in one
or more standard java .jar (not a bundle) without a persistence.xml file.
Include these jars in your CRUD EJBs and set the persistence.xml. Provide
SLSB facades with both local and remote interfaces allowing you to package
the EJB within an EAR for performance and access it remotely via RMI for
remote EJBs. It would be nice if there was a means to access an EJB not
packaged in the same EAR but on the same domain through a local means rather
than RMI/web services (sort of like the NMR from the OpenESB project)...but
I understand that is against the EJB spec =) The advantage of this approach
is:
- I believe accomplished the OPs intended goal
- maintains platform neutrality (no ties to OSGi, which neither the EE or
OSGi Enterprise spec standardizes the OSGI-EJB interfaces)
- flexibility by letting you package the entities logically into their own
library jars and then combine them as necessary in EJB jars. Throw them all
in one EJB jar or make several (understanding that each should have their
own EMF)....
- allows for easy n-tier scalability by providing remote interfaces for the
SLSB facades
Thoughts?
S
On Wed, Apr 6, 2011 at 12:03 AM, Sahoo <sanjeeb.sahoo_at_oracle.com> wrote:
> This is very much possible using OSGi in GlassFish. You can package your
> entities and persistence.xml in a separate OSGi bundle which will export the
> EMF as a service. You can then use the EMF from other EJB/OSGi bundles as a
> service. Full sample at:
>
>
> http://java.net/projects/glassfish/sources/svn/show/trunk/fighterfish/sample/sample.uas/sample.uas.entities
>
> http://java.net/projects/glassfish/sources/svn/show/trunk/fighterfish/sample/sample.uas/sample.uas.ejbservice2
>
> Sahoo
>
>
> On Sunday 03 April 2011 07:05 PM, forums_at_java.net wrote:
>
>> Hi,
>>
>> I have read in the FAQ's that one cannot share a PU across multiple
>> applications deployed in the EJB container. My practical experience has
>> indeed shown that this is error prone as the first application works fine,
>> but subsequent deployed EARs get errors due to the entity classes being in
>> different classloaders and throwing "com.xxx.yy cannot be cast to
>> com.xx.yy"
>> etc.
>>
>> In this light, there must be a way of achieving my use case. Here is what
>> I
>> want to achieve:
>>
>> - I want to create a library jar that can be used by many EJB modules,
>> which
>> in turn are deployed in different EAR's (the library jar would be
>> packagedin
>> the /lib directory of each EAR). I dont want a single ear containing all
>> theEJB's, as it would be huge and wouln't allow me to redeploy a single
>> component at a time. The separate ears are to be deployed to a single
>> Glassfish instance.
>>
>> - The jar needs a persistence unit that allows it to connect to a mysql
>> database
>>
>> - The jar has JPA entity classes for persistence
>>
>>
>>
>> Is there a way I can achieve this? If I try to accomplish this now, the
>> EMF
>> can be created easily enough, but it seems that its shared in a container
>> level classloader for all the EAR's and this causes issues when using the
>> entity classes (the casting issue mentioned).
>>
>>
>>
>> Paul
>>
>>
>> --
>>
>> [Message sent by forum member 'paulcb']
>>
>> View Post: http://forums.java.net/node/788153
>>
>>
>>
>