users@jpa-spec.java.net

[jpa-spec users] [jsr338-experts] Fwd: Re: proposal : _at_Entity on interfaces

From: Adam Bien <abien_at_adam-bien.com>
Date: Tue, 17 Apr 2012 19:52:26 +0200

[forwarding a message from users]

Proxying is probably too much, but I really would appreciate the ability of getting a reference to the EntityManager :-). I'm back from the JAX. There were ~10 requests in my workshop about how to get a reference to the EntityManager...

An @OnAttachment annotation on a method with the EntityManager as parameter would solve the problem.

Begin forwarded message:

> From: Craig Ringer <craig_at_postnewspapers.com.au>
> Subject: Re: [jpa-spec users] [jsr338-experts] Re: proposal : @Entity on interfaces
> Date: 17. April 2012 07:10:46 MESZ
> Cc: Adam Bien <abien_at_adam-bien.com>, jsr338-users_at_jpa-spec.java.net, michael.keith_at_oracle.com, Oliver Gierke <ogierke_at_vmware.com>
>
> [Replying on -users list because of lack of post permission on the main list]
>
> On 04/17/2012 12:46 AM, Adam Bien wrote:
>> On 12.03.2012, at 17:57, Oliver Gierke wrote:
>>
>>> I fear we get into a philosophical discussion here. Objects have state *and* behavior, which is what especially proponents of Domain Driven Design emphasize. Why should JPA get in the way of using objects this way?
>> +1 for this. I also consider JPA entities as rich domain objects and not just structs mapped to tables.
>
> They can't be full participants in the EE environment, though, as they're not subject to injection, interceptors, the alternatives mechanism, etc. Perhaps most importantly, if a transaction fails you have to toss them all out and replace them, and if a merge succeeds you have to start using new versions of the objects that were created by the JPA implementation. Those limitations make it frustrating and often impractical - IMO - to use them for much more than data storage and access.
>
> What I'd like to see in this case, instead of support for @Entity on interfaces, is a proxying system that works on entities and isn't insanely verbose. Rather than enhancing entities themselves, allow the creation of proxies/wrappers that can delegate all calls to an entity but can wrap all operations, can exchange wrapped entities (ie: after a merge, replace old with new), can implement additional interfaces, are subject to injection & interception, etc.
>
> As far as I can tell, right now there isn't any suitable proxying support. JavaAssist or CGLib can't be used by the end-developer for this because they require you to control the object's instantiation in order to proxy it and they can't exchange proxied objects. java.util.Proxy *can* change proxied objects, bu5t can only proxy interfaces, so it won't work with JPA's concrete-class driven approach.
>
> If only we could effectively proxy entities, and do so without having to hand-write or code-generate wrappers for *every* *single* *method* of *every* entity class, then I think that'd solve a fair few issues. Folks: How would you feel about being able to have *proxies* for your entities that could implement the interfaces you wanted and otherwise be extended?
>
> --
> Craig Ringer
>
> POST Newspapers
> 276 Onslow Rd, Shenton Park
> Ph: 08 9381 3088 Fax: 08 9388 2258
> ABN: 50 008 917 717
> http://www.postnewspapers.com.au/