> However, we need to define a set of deprecation rules in the openjpa > documentation.
I'm not sure that the class in question is something that really should make it into our docs -- we're talking about a pretty deeply internal class. Recall that our docs are geared (should be geared?) towards users of the products, not people who are looking to extend it. -Patrick On Nov 19, 2007 7:11 AM, Teresa Kan <[EMAIL PROTECTED]> wrote: > Yes, I agreed with you that we need a deprecation rule to get rid of the old > interfaces for API or SPI. I can add the @deprecated tag to the interface. > However, we need to define a set of deprecation rules in the openjpa > documentation. > > Teresa > > > > On 11/15/07, Patrick Linskey (JIRA) <[EMAIL PROTECTED]> wrote: > > > > > > [ > > > https://issues.apache.org/jira/browse/OPENJPA-442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12542921] > > > > Patrick Linskey commented on OPENJPA-442: > > ----------------------------------------- > > > > So I guess it depends what we consider to be a "public interface". To > > date, we've defined that as just being things that are marked as @published. > > Significantly increasing this footprint will make OpenJPA much more brittle > > to refactorings. > > > > We might want to think about a relatively high-speed deprecation route for > > things like this. This could help facilitate integration testing etc. while > > still allowing things to change as we perform useful refactorings by > > providing overlap in internal SPI compatibility. > > > > > JIRA-407 introduced backward compatibility problem in QueryImpl > > > --------------------------------------------------------------- > > > > > > Key: OPENJPA-442 > > > URL: https://issues.apache.org/jira/browse/OPENJPA-442 > > > Project: OpenJPA > > > Issue Type: Bug > > > Components: query > > > Affects Versions: 1.1.0 > > > Reporter: Teresa Kan > > > Fix For: 1.1.0 > > > > > > Attachments: OPENJPA-442.patch > > > > > > > > > In the openjpa-407 patch, it changed the constructor to pass an extra > > parameter RuntimeExceptionTransaltor, > > > public QueryImpl(EntityManagerImpl em, RuntimeExceptionTranslator > > ret, > > > org.apache.openjpa.kernel.Query query) { > > > _em = em; > > > _query = new DelegatingQuery(query, ret); > > > } > > > However, it did not keep the orginial constructor so the extension of > > this QueryImpl from other vendor resulted in compiler error. We need to keep > > the backward compatibilty issue in mind when we change the public interface. > > > The solution will be to add the original constructor back and route it > > to the new constructor: > > > public QueryImpl(EntityManagerImpl em, RuntimeExceptionTranslator > > ret, > > > org.apache.openjpa.kernel.Query query) { > > > _em = em; > > > if (ret == null) > > > ret = PersistenceExceptions.getRollbackTranslator(em); > > > _query = new DelegatingQuery(query, ret); > > > } > > > /** > > > * Constructor; supply factory and delegate. > > > */ > > > public QueryImpl(EntityManagerImpl em, > > org.apache.openjpa.kernel.Query query) { > > > this(em, null, query); > > > } > > > > -- > > This message is automatically generated by JIRA. > > - > > You can reply to this email to add a comment to the issue online. > > > > > -- Patrick Linskey 202 669 5907
