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 awhite@bea.com designates
 63.96.176.25 as permitted sender)
Mime-Version: 1.0 (Apple Message framework v752.2)
In-Reply-To: <2F460973-E1A8-44FC-8068-0D571601C0A7@bea.com>
References: <7D856CDFE035FF45A0420ACBD71BDD6301B91CBD@repbex02.amer.bea.com>
 <2F460973-E1A8-44FC-8068-0D571601C0A7@bea.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <FF005A1B-79FB-48CA-8B2B-744AD48DF0FF@bea.com>
Content-Transfer-Encoding: 7bit
From: Abe White <awhite@bea.com>
Subject: Re: Extending the OpenJPA implementation
Date: Mon, 14 Aug 2006 17:18:19 -0700
To: open-jpa-dev@incubator.apache.org

>> 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.

I've come up with the beginnings of an idea of how to fix this.  The  
idea ties in nicely with something else I've been wanting to do for a  
while, which is get rid of ConfigurationProviders as a service, and  
do everything through ProductDerivations.

If no one has any objections, I can play around with this later in  
the week.
-
_______________________________________________________________________
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.