openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Patrick Linskey" <plins...@bea.com>
Subject RE: Extending the OpenJPA implementation
Date Mon, 14 Aug 2006 21:57:38 GMT
As yet, we have not found it to be necessary to extend
org.apache.openjpa.persistence.PersistenceProviderImpl in our own
extensions of OpenJPA. However, you rightly point out that the current
org.apache.openjpa.persistence.ConfigurationProviderImpl is pretty
tightly coupled to
org.apache.openjpa.persistence.PersistenceProviderImpl.

ConfigurationProviders don't know anything about PersistenceProviders,
of course, and need to be constructible via a no-args constructor. But
maybe the PersistenceProviderImpl could populate the
ConfigurationProvdierImpl with information about which subclass of
PersistenceProviderImpl it should succeed for. 

PersistenceProviderImpl.java:
    ConfigurationProviderImpl cp = new ConfigurationProviderImpl();
    cp.setPersistenceProviderImplClass(getClass())
    try {
        if (cp.load(pui, map)) {
            ...


ConfigurationProvdierImpl.java:
    public void setPersistenceProviderImplClass(Class cls) {
        persistenceProviderImplClass = cls;
    }

..

    if (!StringUtils.isEmpty(providerName)
        && !persistenceProviderImplClass.getName().equals(providerName))
        return false;


Thoughts?

-Patrick

-- 
Patrick Linskey
BEA Systems, Inc.  

> -----Original Message-----
> From: Kevin Sutter [mailto:kwsutter@gmail.com] 
> Sent: Monday, August 14, 2006 2:26 PM
> To: open-jpa-dev@incubator.apache.org
> Subject: Extending the OpenJPA implementation
> 
> I've been experimenting with extending the OpenJPA 
> implementation.  My first
> experiment was just extending the OpenJPA 
> PersistenceProviderImpl class and
> selectively enhancing a couple of methods.  At first, this 
> looked to be
> rather straight forward.  But, then I ran into a problem with the
> ConfigurationProviderImpl load() method since it did some 
> validation to make
> sure that a requested PersistenceProvider element was equal 
> to the currently
> executing class:
> 
>         if (!StringUtils.isEmpty(providerName)
>             &&
> !PersistenceProviderImpl.class.getName().equals(providerName))
>             return false;
> 
> Since I have extended the PersistenceProviderImpl class, this 
> test failed.
> 
> I considered modifying the above conditional to be more lenient of
> openjpa-derived persistence providers, but Patrick pointed out (via a
> separate e-mail) that we might end up with some false positives when a
> specific persistence provider is requested.  Thus, we decided 
> to move this
> conversation to the dev mailing list to get a discussion started.
> 
> From what I can tell, we have the PersistenceProviderImpl, the
> ConfigurationProvider Service, and the ProductDerivation 
> Service that can
> help develop a proper OpenJPA derivative.  Even my brief 
> experimentation
> with extending the PersistenceProviderImpl showed that this 
> would not be
> useful without extending the ConfigurationProviderImpl (or providing a
> replacement implementation).
> 
> So, is there a defined mechanism and process for extending the OpenJPA
> persistence provider?  If not, any good starting points?  I'm 
> happy to do
> the experimentation.  I just would like to fit within the 
> defined framework.
> 
> Thanks,
> Kevin
> 
_______________________________________________________________________
Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.

Mime
View raw message