Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipselink-users] Spikes, FOSS JPA 1.0 test framework

Hello Shaun
Thank you for taking the time to look at the article...


Shaun Smith wrote:
> 
> Hi John,
> 
>    I took a look at your initial article and I see where you're coming 
> from.  I liked this comment ;-) (my bolding):
> 

I'm coming from the 'burnt fingers' point of view. I want to know what's
good, what's bad, and what's ugly, in JPA, and I only have 10 fingers, some
of which have already been burnt on other Java 'standards', sigh. This
should not be taken as a reflection of a specific JPA vendor, nor JPA itself
- I'm all in favour of choice, I just like to know what potential problems I
will face, and better, how to avoid them.


Shaun Smith wrote:
> 
>     So far I have been able to achieve the same effect, *but in a much
>     less brittle and disruptive fashion, for EclipseLink*. Achieving the
>     same feat with OpenJPA is proving to be a much harder task, which
>     I'm still working on.
> 
> We've always said it was relatively easy to customize EclipseLink 
> metadata and I'm glad you had an experience that backs that up.
> 
> One correction though, TopLink Essentials, one of the "ancestors" of 
> EclipseLink is the JPA 1.0 reference implementation, not OpenJPA.
> 

Oops. Can't imagine how I made that mistake, but thanks for pointing it out
- now corrected.
 

Shaun Smith wrote:
> 
> In terms of the problem you're addressing, things have changed since you 
> wrote the article.
> 

It's only a couple of week old!


Shaun Smith wrote:
> 
> Snip...
> 
> The manuals for the mapping file haven't caught up with development yet 
> but you can take a look at the functional spec and the root bug tracking 
> this work here 
> http://wiki.eclipse.org/EclipseLink/Development/200040/FunctionalSpec 
> and here https://bugs.eclipse.org/bugs/show_bug.cgi?id=200040
> 
Thanks for the links. Using a parallel or shadow ORM.xml file seems like a
very good idea. It'll be interesting to see if the others follow the same,
or similar path. It certainly is a great way of bundling the vendor-specific
metadata in one place.

FYI, I have now updated Spikes to use TopLink Essentials, and there have
been a couple of problems:

1. Deliberately setting a non null field to null, and then attempting to
persist the object does not give back a Spring wrapped exception (as it does
in EclipseLink), but rather the infamous NPE trying to call hashCode - which
I assume means that TopLink is trying to put the object in its own cache,
without any 'formal' validation checks first - that's my hypothesis, more
than likely to be wrong. Here's a piece of the stack dump:

java.lang.NullPointerException
	at org.syger.example.domain.Client.hashCode(Client.java:69)
	at java.util.Hashtable.get(Hashtable.java:334)
	at
oracle.toplink.essentials.descriptors.changetracking.DeferredChangeDetectionPolicy.calculateChanges(DeferredChangeDetectionPolicy.java:83)
	at
oracle.toplink.essentials.internal.sessions.UnitOfWorkImpl.calculateChanges(UnitOfWorkImpl.java:476)
	at
oracle.toplink.essentials.internal.ejb.cmp3.base.RepeatableWriteUnitOfWork.writeChanges(RepeatableWriteUnitOfWork.java:253)
	at
oracle.toplink.essentials.internal.ejb.cmp3.base.EntityManagerImpl.flush(EntityManagerImpl.java:335)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at
org.springframework.orm.jpa.SharedEntityManagerCreator$SharedEntityManagerInvocationHandler.invoke(SharedEntityManagerCreator.java:194)
	at $Proxy20.flush(Unknown Source)
	at org.syger.example.manager.AbstractManager.flush(AbstractManager.java:64)
	at
org.syger.example.manager.AbstractManager$$FastClassByCGLIB$$373de1fc.invoke(<generated>)
	at net.sf.cglib.proxy.MethodProxy.invoke(MethodProxy.java:149)
	at
org.springframework.aop.framework.Cglib2AopProxy$CglibMethodInvocation.invokeJoinpoint(Cglib2AopProxy.java:700)
	at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:149)
	at
org.springframework.dao.support.PersistenceExceptionTranslationInterceptor.invoke(PersistenceExceptionTranslationInterceptor.java:138)
	at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
	at
org.springframework.aop.framework.Cglib2AopProxy$DynamicAdvisedInterceptor.intercept(Cglib2AopProxy.java:635)
	at
org.syger.example.manager.DataManager$$EnhancerByCGLIB$$49043ffb.flush(<generated>)
	at org.syger.unittest.ClientTest.testClientNullName(ClientTest.java:37)
...

2. Both TopLink and EclipseLink fail to update a @PreUpdate annotated method
when that method is not  public - when it's public things work just fine.
Yet the specs state that (section 3.5.1)

The callback methods can have public, private, protected, or package level
access, but must not be
static or final.

Here's the method:

	/**
	 * Settaggio della data del'ultimo aggiornamento prima del salvataggio -
	 * Sets the last updated date prior to saving.
	 */
	@PreUpdate 
	protected void preUpdate() {
		lastUpdated = new java.util.Date();
	}

Change protected to public and Robert is you proverbial father's brother.
This is not a showstopper of course, I'm personally not that squeemish about
making the method public.

John


Shaun Smith wrote:
> 
>      Shaun
> 
> John Leach wrote:
>> Dear list,
>> I have prepared a (very) small open source project to provide domain 
>> entity mapping and association examples, together with a programmatic 
>> interface to reach outside the JPA 1.0 specifications. Currently it 
>> works with Hibernate, EclipseLink and (almost, but not quite) OpenJPA.
>>
>> The intention is to provide a 'third' alternative to annotations 
>> and/or persistence.xml, where the entity classes contain only JPA 
>> annotations, with any remaining changes being made programmatically. 
>> The one-to-many example defines CascadeType.ALL, but actually requires 
>> a 'delete-orphans' extension for the tests to succeed.
>>
>> I had better warn you all that I am a freelance consultant working in 
>> Italy and I use and will be using this work to sell both the 
>> advantages and disadvantages (but with solutions) of using JPA 1.0. to 
>> my clients.
>>
>> Although the EclipseLink part works, and the programmatic interface is 
>> quite simple (using the eclipselink.session.customizer property), 
>> working in a vacuum (that's me and myself, and we don't always agree) 
>> does mean that I'm never quite sure that I've found a "good enough" 
>> solution. Any help would be greatly appreciated. I am working 'in 
>> collaboration with' two Java User Groups (Torino and Trento), but it's 
>> really me who wrote most of the code.
>>
>> The open source project, called Spikes (guess why) can be downloaded 
>> via Subversion with the command:
>>
>> svn checkout https://lab.jugtorino.it/svn/sandbox/spikes/trunk spikes
>>
>> There is a Trac site at 
>> http://lab.jugtorino.it/trac/sandbox/wiki/Spikes which I have 
>> converted to English in most places, and also an article (which 
>> started the project rolling) 
>> http://www.syger.it/Tutorials/JPA10Gotchas.html
>>
>> Best regards
>> John Leach, Verona, Italy
>>
>> _______________________________________________
>> eclipselink-users mailing list
>> eclipselink-users@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/eclipselink-users
> 
> -- 
> 
> 
> Oracle <http://www.oracle.com>
> Shaun Smith | Principal Product Manager, TopLink | +1.905.502.3094
> Oracle Fusion Middleware
> 110 Matheson Boulevard West, Suite 100
> Mississauga, Ontario, Canada L5R 3P4
> 
> _______________________________________________
> eclipselink-users mailing list
> eclipselink-users@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/eclipselink-users
> 
> 

-- 
View this message in context: http://www.nabble.com/Spikes%2C-FOSS-JPA-1.0-test-framework-tp17201935p17313809.html
Sent from the EclipseLink - Users mailing list archive at Nabble.com.



Back to the top