[
http://issues.apache.org/jira/browse/OPENJPA-24?page=comments#action_12436089 ]
Abe White commented on OPENJPA-24:
----------------------------------
I've committed some additional work on this as I reviewed Pinaki's work. You
should now be able to extend OpenJPA by creating a ProductDerivation like so:
public class MyProductDerivation
extends AbstractProductDerivation {
public int getType() {
return TYPE_PRODUCT;
}
public boolean beforeConfigurationLoad(Configuration conf) {
Value emf = conf.getValue(EntityManagerFactoryValue.KEY);
if (emf == null)
return false;
emf.setDefault(MyEntityManagerFactoryClass.class.getName());
emf.setClassName(MyEntityManagerFactoryClass.getName());
return true;
}
}
With your custom EntityManagerFactory class (which must extend
EntityManagerFactoryImpl), you can also override newEntityManagerImpl(Broker)
to subclass the EntityManager, and using your EntityManager subclass I believe
you can act as a factory for custom QueryImpl, etc extensions. In addition to
the PersistenceProvider.createEMF methods, the static
toEntitymanagerFactory/toEntityManager methods in OpenJPAPersistence will also
correctly return your custom subclasses.
So you shouldn't need a custom ConfigurationProvider or a custom
PersistenceProvider anymore. I'll be doing some more review of this later to
be sure it actually works, barring someone else testing it and telling me it
does.
> Allow OpenJPA to be extensible
> ------------------------------
>
> Key: OPENJPA-24
> URL: http://issues.apache.org/jira/browse/OPENJPA-24
> Project: OpenJPA
> Issue Type: Bug
> Components: kernel
> Reporter: Kevin Sutter
> Assigned To: Kevin Sutter
>
> The current OpenJPA architecture is not extendable to other implementations.
> For example, if somebody wanted to provide their own PersistenceProvider
> implementation, simply extending the
> org.apache.openjpa.PersistenceProviderImpl would not suffice due to the
> dependencies in the ConfigurationProviderImpl. The discussion for this
> improvement was started on the dev mailing list. Once it was determined that
> there was more to this request than a simple conditional or two, we decided
> to open a JIRA report.
> The complete history of this request can be found in the OpenJPA dev mailing
> list. The first message was posted by me (Kevin Sutter) on August 14, titled
> "Extending the OpenJPA Implementation". I will attempt to paraphrase the
> current state of the problem...
> We have three main players in this issue. The PersistenceProvider, the
> ConfigurationProvider, and the ProductDerivation (along with the various
> implementations of these interfaces). Currently, the ConfigurationProvider
> is in the lib and is unaware of any specific persistence requirements. The
> ProductDerivation is in the kernel and, unfortunately, is aware of
> persistence requirements, specifically the spec and store types. Abe's
> postings have indicated that we need to make these two interfaces more aware
> of each other and work with each other. We need to start with either making
> ConfigurationProvider more persistence-aware and move it into kernel, or make
> ProductDerivations less persistence-aware and move it into lib. The latter
> approach is preferred.
> After we get this re-organization of the base framework complete, we still
> have a couple of other issues ot resolve:
> * Still need the ability to extend EMF's through a ProductDerivation.
> This should be doable by adding a new PluginValue to indicate what class of
> EMF to load.
> * There is still a question as to whether we will need to provide a
> custom PersistenceProviderImpl and ConfigurationProviderImpl pair. I still
> think this will be necessary. And, one of Abe's posts indicated that this
> might help with class loading issues when multiple versions of OpenJPA-based
> implementations are available in the same system.
> I also posted these questions last Friday. (Abe has responded with some
> answers, but I wanted to get this JIRA report created before trying to
> paraphrase his answers.)
> * You mention in several places about separating away the notion of
> specs and stores. In a general sense, I understand what these are. But, can
> you elaborate on how these types are used in the ConfigurationProvider and
> ProductDerivation interfaces?
> * I've moved the ProductDerivation interface to the lib and added the
> "load" methods from the ConfigurationProvider (as described in your previous
> notes). And, I've started to clean up the implementations that depend on
> these interfaces. But, concerning the implementation of the load methods...
> Now that we need to return a ConfigurationProvider, would you expect that we
> just new up a ConfigurationProviderImpl and then just call across to the
> "load" methods on the implementation? Since we want to keep the
> ProductDerivations stateless, I'm not sure how else you were expecting to
> create a ConfigurationProvider to return on these "load" methods.
> * Now that ConfigurationProvider is bare, the
> ConfigurationTestConfigurationProvider doesn't have much function. I'll need
> to take a look to see if this is even required any longer.
> * Can you shed a bit more light on the Configurations class? It doesn't
> implement nor extend any interfaces or classes, but it seems to provide many
> of the same methods as ConfigurationProvider, but as statics. And, it's
> dependent on having a Provider. Can you explain the relationship of this
> class in the bigger picture and how you think it might be affected by thes
> changes?
> That's enough for the initial JIRA report. We will now track this problem
> here instead of the dev mailing list. Thanks.
> Kevin
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
