« Return to Thread: patch for bug 243365 - Forked Java VM exited abnormally when running SDOXMLHelperLoadAndSaveTestSuite

Need to externalize concrete classes resolution to get clean extension

by Sebastien Tardif-2 :: Rate this Message:

Reply to Author | View in Thread

Some parts of this message have been removed. Learn more about Nabble's security policy.

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

 

Let me know what you think.


_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@...
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev

 « Return to Thread: patch for bug 243365 - Forked Java VM exited abnormally when running SDOXMLHelperLoadAndSaveTestSuite

LightInTheBox - Buy quality products at wholesale price!