At this point the specification can add this functionality so that every time addNamedQuery is called any previous queries registered with the same name are replaced. The EntityManagerFactory API is intended to be concurrently accessed and that contract would be extended to this API as well. Any namedQuery management can safely be deferred to the client code. For instance if a client application wants to prevent calling this API multiple times using the same name the client code can easily maintain a list of added query names. In the future if the need arrives we can add additional API to check for the existence of a named query.
We should still add EMF lifecycle events as otherwise it would be very difficult for an client application to ensure it's named query was created on the EMF provided by the container as the container is managing the EMF internally and this behaviour is not specified.
A simple structure would be the following:
public interface EntityManagerFactoryListener(){
/**
* The persistence provider is responsible for invoking this method on any registered implementors of EntityManagerFactoryListener after the EntityManagerFactory has been created just prior to returning the EntityManagerFactory to the requester.
*/
public void postConstruct(EntityManagerFactory emf);
}
This is an easy point to define within the EMF lifecycle. More complicated points (like post metadata processing stage) can be added later as needed.
The EntityManagerFactoryListener could be registered through a EMF property.
--Gordon
On 11/29/2011 4:25 PM, Linda DeMichiel wrote:
>> In particular section 7.6.1 seems generic to me and not specific to container managed persistence contexts
>>
>> 7.4
>> EntityManagerFactory.addNamedQuery
>> As I raised initially, I'm still unclear how a user would properly use this feature. Where in his code would it add a new named query and make sure this has not been added before. To me it'd be preferable to have some initialization hook to set such queries. I'm happy to change my mind but I looked up my emails and I don't think anyone came up with a use case for the current proposed form.
>> Note that this also avoid a bunch of concurrent safe structures as well but that's impl details.
>>
>> See the thread named Re: named queries and my exchange with Gordon from April 28th forward.
>>
>
> OK. Unfortunately, we don't have a well-defined initialization sequence, and the EMF
> may be created by the container before application code gets to execute. However, a
> startup singleton EJB's postConstruct could be used for adding named queries, or a
> servlet init method. In the mean time, do you think addNamedQuery has so little
> value that we should remove it?