Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [eclipselink-dev] Need to externalize concrete classes resolution to get clean extension

 
Hmmm. Interesting idea, Sebastien.
 
As you know, in TopLink and EclipseLink there are already many defined strategies/hooks that allow specific classes to be used at key extension points, the classes typically being specified in the sessions.xml file. If I understand your idea correctly you are still talking about putting in the instantiation code (e.g. using reflection) that used the class specified in a given property file -- basically allowing the hooks and extension points to be specified as properties. I guess the main difference is that new properties would be more extensibly added to the XML file (no schema changes would be necessay) rather than having to define new XML elements for each hook. On the negative side, there would be a small loss of type safety in terms of the property name vs. the XML elements that we use now. Persistence properties in persistence.xml already made that sacrifice, though...
-----Original Message-----
From: Sebastien Tardif [mailto:stardif@xxxxxxxxxxxx]
Sent: Thursday, August 07, 2008 10:25 PM
To: Dev mailing list for Eclipse Persistence Services
Subject: [eclipselink-dev] Need to externalize concrete classes resolution to get clean extension

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.


Back to the top