On 05/10/2012 22:26, Kevin Sutter wrote: > Hi Francesco, > There really is no hard rule or reason for these private methods. As we > have continued to extend OpenJPA in various ways, many of the internal > private methods have had to be changed to protected. I would suggest > opening a JIRA and posting a proposed patch for the methods you want to > change. I would guess this type of change would be pretty easy to > accept... (famous last words)
Done: https://issues.apache.org/jira/browse/OPENJPA-2275 Thanks for your support. Regards. > On Fri, Oct 5, 2012 at 9:16 AM, Francesco Chicchiriccò > <[email protected]>wrote: > >> Hi all, >> as already said on this mailing list, I am working on an OpenJPA product >> derivation for dealing with Windows Azure Database sharding [1]. >> >> For our needs, I have to subclass some OpenJPA core classes and that's >> generally fine because most aspects were already thought with >> extensibility in mind. >> >> Unfortunately, it seems that SchemaTool [2] doesn't fall into this >> category: most methods are private or package-private, thus making life >> of a poor extender very hard [3]. >> >> Is there any specific reason for this? Any hope to turn most of >> 'private' from SchemaTool into 'protected'? >> >> Regards. >> >> [1] https://github.com/Tirasa/OpenJPA-Azure >> [2] >> >> http://svn.apache.org/repos/asf/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/schema/SchemaTool.java >> [3] >> >> https://github.com/Tirasa/OpenJPA-Azure/blob/master/src/main/java/org/apache/openjpa/azure/jdbc/schema/AzureSchemaTool.java -- Francesco Chicchiriccò ASF Member, Apache Cocoon PMC and Apache Syncope PPMC Member http://people.apache.org/~ilgrosso/
