Problems with persistence context (Lift/JPA)

[Kris Nuttycombe]

Hi, all,

I'm trying to get a simple Lift webapp working with my existing EJB3
persistence artifact, and am getting some strange errors on startup.
I've been following the directions from
http://liftweb.net/index.php/Lift_and_JPA_(javax.persistence) closely,
but using my existing entities jar instead of the samples. Here's the
error I'm getting:

Internal Exception: Exception [EclipseLink-30004] (Eclipse Persistence
Services - 1.0 (Build SNAPSHOT - 20080428)):
org.eclipse.persistence.exceptions.PersistenceUnitLoadingException
Exception Description: An exception was thrown while processing
persistence.xml from URL:
file:/home/knuttycombe/.m2/repository/com/gaiam/gcsi/gcsi-core/1.0-SNAPSHOT/gcsi-core-1.0-SNAPSHOT.jar
Internal Exception:
(1. cvc-elt.1: Cannot find the declaration of element 'persistence'.)
at org.eclipse.persistence.exceptions.PersistenceUnitLoadingException.exceptionSearchingForPersistenceResources(PersistenceUnitLoadingException.java:121)
at org.eclipse.persistence.jpa.PersistenceProvider.createEntityManagerFactory(PersistenceProvider.java:87)
at javax.persistence.Persistence.createEntityManagerFactory(Persistence.java:110)
at javax.persistence.Persistence.createEntityManagerFactory(Persistence.java:83)
at com.gaiam.gcsi.model.Model$.(Model.scala:7)
at com.gaiam.gcsi.model.Model$.(Model.scala)
at bootstrap.liftweb.Boot$$anon$1.apply(Boot.scala:19)
at net.liftweb.http.S$.net$liftweb$http$S$$doAround(S.scala:340)
...
Caused by: Exception [EclipseLink-30004] (Eclipse Persistence Services
- 1.0 (Build SNAPSHOT - 20080428)):
org.eclipse.persistence.exceptions.PersistenceUnitLoadingException
Exception Description: An exception was thrown while processing
persistence.xml from URL:
file:/home/knuttycombe/.m2/repository/com/gaiam/gcsi/gcsi-core/1.0-SNAPSHOT/gcsi-core-1.0-SNAPSHOT.jar
Internal Exception:
(1. cvc-elt.1: Cannot find the declaration of element 'persistence'.)
at org.eclipse.persistence.exceptions.PersistenceUnitLoadingException.exceptionProcessingPersistenceXML(PersistenceUnitLoadingException.java:112)
at org.eclipse.persistence.internal.jpa.deployment.PersistenceUnitProcessor.processPersistenceXML(PersistenceUnitProcessor.java:351)
at org.eclipse.persistence.internal.jpa.deployment.PersistenceUnitProcessor.processPersistenceArchive(PersistenceUnitProcessor.java:289)
at org.eclipse.persistence.internal.jpa.deployment.PersistenceUnitProcessor.getPersistenceUnits(PersistenceUnitProcessor.java:217)
at org.eclipse.persistence.internal.jpa.JavaSECMPInitializer.initPersistenceUnits(JavaSECMPInitializer.java:197)
at org.eclipse.persistence.internal.jpa.JavaSECMPInitializer.initialize(JavaSECMPInitializer.java:215)
at org.eclipse.persistence.jpa.PersistenceProvider.createEntityManagerFactory(PersistenceProvider.java:73)
... 50 more
Caused by:
(1. cvc-elt.1: Cannot find the declaration of element 'persistence'.)
at org.eclipse.persistence.internal.jpa.deployment.xml.parser.XMLExceptionHandler.error(XMLExceptionHandler.java:28)
at org.apache.xerces.util.ErrorHandlerWrapper.error(Unknown Source)

This puzzles me, because it appears to be finding the persistence.xml
file correctly (gcsi-core is the jar containing my entities and
includes META-INF/persistence.xml) and my persistence.xml is rather
straightforward:

<?xml version="1.0" encoding="UTF-8"?>
<persistence>
<!--<persistence-unit name="gcsi-entities" transaction-type="JTA">-->
<persistence-unit name="gcsi-entities" transaction-type="RESOURCE_LOCAL">
<provider>org.hibernate.ejb.HibernatePersistence</provider>
<!--<jta-data-source>jdbc/GcsiDS</jta-data-source>-->
<properties>
<property name="hibernate.cache.provider_class"
value="org.hibernate.cache.NoCacheProvider"/>
<property name="hibernate.hbm2ddl.auto" value="update"/>
<property name="hibernate.ejb.naming_strategy"
value="com.gaiam.gcsi.util.SensibleNamingStrategy"/>
</properties>
</persistence-unit>
</persistence>

Hibernate database connection properties are configured in my
hibernate.cfg.xml; this has worked fine in other environments. The
only changes I've made are to use RESOURCE_LOCAL transactions instead
of JTA just so that I could follow the example more closely.

I'm running all of this under Glassfish V2 (UR2)

As a secondary question, does anyone have an example of using JNDI
lookup to get the EntityManager in Model.scala instead of calling
Persistence.createEntityManagerFactory?

Thanks,

Kris

[nuttycom]

Okay, I've figured out the first error - I needed to declare the
<persistence> tag as

<persistence xmlns="http://java.sun.com/xml/ns/persistence"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/
persistence http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd"
version="1.0">


On Sep 3, 10:20 am, "Kris Nuttycombe" <kris.nuttyco...@gmail.com>
wrote:

> Hi, all,
>
> I'm trying to get a simple Lift webapp working with my existing EJB3
> persistence artifact, and am getting some strange errors on startup.

> I've been following the directions fromhttp://liftweb.net/index.php/Lift_and_JPA_(javax.persistence) closely,

[Derek Chen-Becker]

Yeah, you have to provide the DTD for the XML for the persistence API to pick it up correctly. As for a JNDI lookup, you could write a utility lookup method:

import javax.naming.InitialContext
def lookupEM() = (new InitialContext()).lookup("my JNDI name here").asInstanceOf[EntityManager]

and then change the Model.emVar object to

object emVar extends RequestVar(lookupEM())

Let me know if you run into any problems with that.

Derek

[Kris Nuttycombe]

Thanks, Derek. Today's my first day with Lift so I'm just coming up to
speed, and I'm not familiar with RequestVar. As I understand this
solution though, I would no longer need the Model threadlocal or the
LoanWrapper at all (since I'm depending upon the container to manage
the EntityManager's lifecycle) and would just declare such an emVar
object in whatever snippet I wished to use it?

Thanks again,

Kris

[Derek Chen-Becker]

Technically, no. I use the Model object to also hold some implicit defs for converting java.util collections into their Scala counterparts to make some of the JPA API easier to work with:

// Implicit defs to help with entity member access
  implicit def setToWrapper[A](set : java.util.Set[A]) = new SetWrapper[A]{override def underlying = set}
  implicit def listToWrapper[A](list : java.util.List[A]) = new BufferWrapper[A]{override def underlying = list}

But there's no reason that these have to sit there. I keep the emVar there because I call it from multiple snippets. If you did one per snippet you'd be duplicating effort, although it shouldn't cause problems. As for the LoanWrapper, that isn't required at all in a container-managed environment, just for JSE JPA. Even then, Lift 0.10 introduces lifecycle management right on the RequestVar, so that will go away completely then.

Derek

[Oliver]

What lifecycle managment on RequestVar does 0.10 add and can I read about it anywhere?
Why is RequestVar a better solution that using a threadLocal?

Oliver

[Oliver]

I found thread http://groups.google.com/group/liftweb/browse_thread/thread/fb4aea7c0d13d17e
which pretty much explains the lifecyle hook additions.

The RequestVar solution as you point out, gets rid of the LoanWrapper requirement which is nice. However, at the moment, the persistence project, within my application, has no requirement on lift at all  - guess I'll have to decide sooner or later whether to swim with lift, and include it as a dependency to get RequestVar's and Can's.

[Derek Chen-Becker]

The way I've structured the "demo" JPA project is as separate persistence and webapp modules under a master Maven project. In that respect, the persistence module is an independent Maven project and has no reliance on Lift at all, just scala. The RequestVar usage is strictly for use within a Lift webapp. It's essentially a threadLocal, but it does come with some built-in lifecycle methods now that make it a little more useful than a stright threadLocal in that context. Am I misunderstanding what you mean?

Derek

[Oliver]

Using your Model object as a starting point I created a JPA wrapper (partly finished) and dragged it to my persistence module. I feel that is where it belongs for unit/integration testing. Currenly it uses ThreadLocal, I guess I could hide a RequestVar using a function callback to the Web tier (and inject a ThreadLocal for testing), but if I use Can's, I have a dependency on Lift.

Oliver

[David Pollak]

On Wed, Sep 3, 2008 at 10:29 PM, Oliver <ola...@gmail.com> wrote:

Using your Model object as a starting point I created a JPA wrapper (partly finished) and dragged it to my persistence module. I feel that is where it belongs for unit/integration testing. Currenly it uses ThreadLocal, I guess I could hide a RequestVar using a function callback to the Web tier (and inject a ThreadLocal for testing), but if I use Can's, I have a dependency on Lift.

If you're writing web apps, what's the problem with Lift dependencies?
 

--
Lift, the simply functional web framework http://liftweb.net
Collaborative Task Management http://much4.us
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

[Oliver]

I guess it doesn't really matter but it drags in a lot of functionality that would normally not be in a persistence
tier module. I may have another module that uses the persistence tier but just talks web service.

Could you split Lift into separate jars for useful utilities like Can and persistence utilities - just kidding :-)

[Oliver]

Actually to extend on that, Can would be a useful addition to a non lift library.

Lift appears to very non anemic Model objects which I believe know how to persist themselves, how to validate and how to write themselves to html (hence my just kidding on breaking them into separate jars).  I can see this will be useful for some apps, however many times Im only interested in bits of several entities to create a page.

[David Pollak]

On Wed, Sep 3, 2008 at 11:37 PM, Oliver <ola...@gmail.com> wrote:

Actually to extend on that, Can would be a useful addition to a non lift library.

One of the projects that DavidB was working on was splitting up Lift Webkit into modules.  Then he got a job that requires a long commute, and he's been unable to work on his surgery.  Before Lift goes 1.0, I expect that we'll split out the util package into its own JAR.
 

Lift appears to very non anemic Model objects which I believe know how to persist themselves, how to validate and how to write themselves to html (hence my just kidding on breaking them into separate jars).  I can see this will be useful for some apps, however many times Im only interested in bits of several entities to create a page.

You don't need to use Lift's model stuff in order to build Lift apps.  You can use JPA.  My question was "even if you're using JPA and not Lift's mapper stuff, if you're building a web app, why not use the rest of Lift?"
 

[Oliver Lambert]

On 04/09/2008, at 11:28 PM, David Pollak wrote:

On Wed, Sep 3, 2008 at 11:37 PM, Oliver <ola...@gmail.com> wrote:

Actually to extend on that, Can would be a useful addition to a non lift library.

One of the projects that DavidB was working on was splitting up Lift Webkit into modules.  Then he got a job that requires a long commute, and he's been unable to work on his surgery.  Before Lift goes 1.0, I expect that we'll split out the util package into its own JAR.
 

Lift appears to very non anemic Model objects which I believe know how to persist themselves, how to validate and how to write themselves to html (hence my just kidding on breaking them into separate jars).  I can see this will be useful for some apps, however many times Im only interested in bits of several entities to create a page.

You don't need to use Lift's model stuff in order to build Lift apps.  You can use JPA.  My question was "even if you're using JPA and not Lift's mapper stuff, if you're building a web app, why not use the rest of Lift?"

Then, the answer should simply have been, I am using the rest of Lift (or bits of it, as I learn and replace confusion with less confusion).

[Kris Nuttycombe]

On Wed, Sep 3, 2008 at 4:12 PM, Derek Chen-Becker <dchen...@gmail.com> wrote:
> Technically, no. I use the Model object to also hold some implicit defs for
> converting java.util collections into their Scala counterparts to make some
> of the JPA API easier to work with:
>
> // Implicit defs to help with entity member access
> implicit def setToWrapper[A](set : java.util.Set[A]) = new
> SetWrapper[A]{override def underlying = set}
> implicit def listToWrapper[A](list : java.util.List[A]) = new
> BufferWrapper[A]{override def underlying = list}

I kept Model around for the same reason when making the changes you
suggested. This did bring to mind, though, a question that's been
growing in my mind about the frequent use of singletons in Lift. In
the Java world, we've been moving fairly quickly away from singletons
because of the dependency issues that they introduce for unit testing;
mocking becomes a real hassle. It's a little distressing to see
singletons making such a resurgence in Lift and Scala, and while it's
convenient in a number of places the fact that they're baked in to the
language doesn't help. An EntityManager is exactly the sort of thing
that I'd prefer to see as an injected dependency so that I can just
use a mock in my tests.

The Lift FAQ makes a bit of a reference to these concerns, but I
haven't been able to find any references on how to actually *do*
dependency injection for this sort of case where your snippet needs a
reference to some external resource that's not managed by Lift. (also,
the link from that FAQ entry that's given for more information appears
to be dead.)

Kris

[Derek Chen-Becker]

For dependency injection in this case you can just use a mock JNDI provider to handle dependency injection. Of course, you can always use Spring or some other IoC framework to inject the dependencies; Scala objects and classes, after all, are really just Java classes.

Derek

[Oliver]

Hi Kris

I come from the Java world and can understand your concerns. However,
I think its a little unfortunate that the Java community rejects a useful
methodology just because it makes testing difficult. I think the
modular programming section in the programming in Scala book, gives
an example of how to mix in test classes. Im also working on Entity
Manager stuff so will also have to cross this hurdle too.

Oliver