Community
Participate
Working Groups
I have been fixing/extending TopLink source code, which look exactly the same than EclipseLink, for over 2 years. In my previous life I had also been extending MFC a framework from Microsoft. In both cases, the main problem for clean modifications without changing directly existing class is to get a handle on the instantiation of the concrete classes to swap mine, which often extend from the original. EclipseLink should be extensible. To achieve this, all concrete classes’ instantiations should be customizable. Different degrees of customization are conceivable. The simpler approach is that if a property/xml file is found in the classpath it is used to choose the concrete classes. The more complex implementation will probably end-up looking like Spring. The following classes all need some modifications to get them working gracefully in my enterprise-grade application: UnitOfWorkImpl SessionBroker ObjectBuilder SequencingManager DeferredChangeDetectionPolicy XMLSessionConfigLoader WebSphere_6_1_Platform SessionsFactory SessionManager Oracle10Platform MergeManager MergeChangeSetCommand VersionLockingPolicy And others
I agree that being able to control the instantiation of some internal classes would be valuable in advanced usage cases. Some of the items in this list however are already externally configurable. Limiting the discussion to the list provided I believe these are already supported for extension in Sessions.xml or persistence.xml properties. WebSphere_6_1_Platform Oracle10Platform The following are candidates for a configurable factory UnitOfWorkImpl SessionBroker ObjectBuilder SequencingManager DeferredChangeDetectionPolicy XMLSessionConfigLoader SessionManager MergeManager MergeChangeSetCommand VersionLockingPolicy The biggest challenge when this is added is evaluating these classes for their extensibility due to method scoping and general functionality. I am concerned that if extending a very internal impl class is too easy users may do so without fully understanding the impact. Documenting he 'supported' extensibility and building appropriate testing to very the extension points can be very time consuming.
After giving this some more thought and discussions with some of the committers I now have concerns about simply providing a factory for usage of custom subclasses of these classes. While I have encountered the need for these myself I am concerned about what the user's expectations would be. If a user creates their own subclass of UnitOfWorkImpl does that mean that any changes to the implementation of this class must remain backwards compatible? If this is the implied contract then future development of new features and required refactoring work would be greatly limited.If only some of the API is allowed for extensibility then this bug requires significant work to identify and clearly document these. The alternative approach is allow custom subclasses but document this feature as extremely advanced and require any user doing this to certify their custom subclass on any all future releases. This would be a big liability for users who have a system in production and then later wish to upgrade their EclipseLink version. If the same developers are not on staff the upgrade cost could be much greater then expected. I would really like some community feedback on this issue to help us decide how to best proceed.
My expectations are that public methods are more likely stable than the one protected. When EclipseLink is refactored to small methods, small method will have smaller and clearer set of responsabilities so less likely to change of semantic. We already override classes but it's not straight forward, we end-up to have to override also the class(es) hardcoding the instantiation, often this involve cascade creation. So changes needed after an upgrade of EclipseLink is lot more without customizable factory. With factories and from our experiences, change to our customization are rarely needed after upgrade.
The Eclipselink project has moved to Github: https://github.com/eclipse-ee4j/eclipselink
