There is no notion of "managed EMF." If you see the example, the PU is
confifgured with JTA transaction type and uses data sources as opposed
to JDBC URLs, that's because eclipselink supports these for a Java SE
style EMF. Yes, you can deploy the OSGi bundles to a cluster as well.
While deploying using "deploy command" use --type=osgi. One of the
benefits of the approach of the sample is sharing of second level cache
across users of the PUs.
Thanks,
Sahoo
nb: I am away from work, so my reply is not very detailed.
On Wednesday 06 April 2011 07:43 PM, Steven Siebert wrote:
> 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
> <mailto: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
> <mailto: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
>
>
>
>