Hi,

I want to write a generator for a composite key but, AFAIK, I have no way of specifying my own generator using annotations and/or the ORM file. I dug around a little and noticed that I can define enitity lifecycle callbacks for my entities so I was wondering if the right thing to do is to:

1. Define a PrePersist() callback for my entities.
2. Call my key generator in the callback.
3. Assign the primary key to the entity.
4. Return from callback.

It looks like this would ensure the correct behavior in all cases, including cascading but is it OK to modify the entity in a lifecycle callback like this? Is there a better way to plug a key generator into an EntityManager?

you're wrong, you cna define a custom generator
Use @GenericGenerator

But I don't want to use a vendor-specific mechanism, I want to keep this independent of any specific EntityManager implementation.

I noticed that there has been a bug report filed against these callbacks (EJB-46) which implies that my plan above wouldn't work - basically some validation of the entities is performed before any callbacks are called. In this case if I call em.persist(obj) and the id of 'obj' has not been set, none of the callbacks are called so I wouldn't have an opportunity to set the primary key value.

I would be interested to hear your opinion on whether or not this is the correct behavior, also on how developers are supposed to be able to plug generators into an EntityManager in a vendor neutral way. Is this a hole in the EJB3 spec?

Thanks.

Cost of a portable solution
1. analysis of the issue
2. implementation and test on all implementations
3. go back to 1. until 2 pass
At least 5 days if even possible, probably way more

Cost of a extension use:
1. Hibernate: 2hrs
2. migration to an other JPA provider implementation of this feature: 2hrs
3. if your provider does not have this extension, don't migrate, it's crap
2hr + 2hr per migration: assuming 8hr a day, you can migrate 40 times, assuming you can count the decent (future or already certified) JPA implementation with one hand, you're safe.

You have to foresee which extension is "natural" and which one is clearly specific. Then the cost of *not* using it. Don't be religious.

So I guess your answer is: No, you can't use entity listeners to implement this.

Whilst I take your point about development costs I would still like to see a couple of things from the EJB3 community which addresses these issues in the long run:

1. Support for the definition of user-defined id generators.
2. Clarification of the expected behavior of the entity manager and the calling of entity listeners - for example there is nothing in the spec that says an entity manager should perform validation of the entities before calling prePersist().

The other thing is I'm not using annotations, I'm using mapping files. If I were using annotations then it is perhaps no big deal to mix the odd vendor-specific annotation in with the standard ones. If I'm using mapping files though, I'm assuming that I would have to define the entire mapping of each affected entity in a vendor-specific mapping file?[/list]

this can't work on a general basis because the persistence provider have to guess whether it's an insert or an update before calling prepersist or preupdate listeners, which can't be done unless the id is set.