Mailing-List: contact open-jpa-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: open-jpa-dev@incubator.apache.org
Received-SPF: pass (asf.osuosl.org: domain of kwsutter@gmail.com designates
 64.233.182.187 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:mime-version:content-type;
        b=rCrh/kbvnUl2kfhcLQZmpHygi9rnBXw2ueN7SqoJM1lYRE81YPAJeKvPq5QjcihEg4BdQdhlg2lNUMkFA3Voqk7a/Pe3idajL0htGoZN7dRfu9vaTTP2kBVeUlL6xhuzzmwfQVMSUmAc1TJO1oCnT3hjGgEWgyC7V0je4gD5fgI=
Message-ID: <89c0c52c0608141426j7e22ece9iff0da5ab38d72e89@mail.gmail.com>
Date: Mon, 14 Aug 2006 16:26:21 -0500
From: "Kevin Sutter" <kwsutter@gmail.com>
To: open-jpa-dev@incubator.apache.org
Subject: Extending the OpenJPA implementation
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_201869_16990144.1155590781668"

------=_Part_201869_16990144.1155590781668
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

------=_Part_201869_16990144.1155590781668--