Skip to main content

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

  • From: Adam Bien <abien@...>
  • To: jsr338-experts@...
  • Subject: [jsr338-experts] Fwd: [jpa-spec users] Re: proposal : @Entity on interfaces
  • 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@...>
> Subject: Re: [jpa-spec users] [jsr338-experts] Re: proposal : @Entity on 
> interfaces
> Date: 17. April 2012 07:10:46 MESZ
> Cc: Adam Bien <abien@...>, jsr338-users@..., michael.keith@..., Oliver 
> Gierke <ogierke@...>
> 
> [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/



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

Adam Bien 04/17/2012
 
 
Close
loading
Please Confirm
Close