Hi Jarek, Looking through the changes that are needed to support the Java Agent Transformer, we obviously need to get the container's bundlecontext into the ManagedPersistenceUnitInfoFactory.
The current changes that have been made are to the create and destroy methods, which works well, but is a breaking change for both the client and the implementor of the interface. This means that the OSGi package export would need to rise from 1.0.0 to 2.0.0 to communicate the change. As far as I can see this is one of three possible mechanisms. 1. Keep the existing change and update the package version range from [1.0.0,2.0.0) to [2.0.0,3.0.0) in all of the bundles that use the aries jpa container package. 2. Change the create and destroy method back to their previous signatures, and add a setBundleContext() method to the interface. This can be driven to initialize the ManagedPersistenceUnitInfoFactory after it is constructed. This interface change is binary compatible for clients, and so the package version will only need to be changed to 1.1.0. Implementors will need to update their import range, but everyone else can keep the existing [1.0.0,2.0.0) range. 3. Change the interface back to its original state, and add logic in the PersistenceBundleManager to change the way the ManagedPersistenceUnitInfoFactory plugins are created. The plug point can look for a constructor that accepts a bundlecontext, falling back to a no-args constructor if that does not exist. This has the advantage that no changes are needed to the API version, and existing plugins continue to work. What do you think about these approaches? Obviously 1 is the simplest contract, 3 allows existing extensions to continue working, and 2 is somewhere in the middle. My opinion is that 3 is a nice option given that we have already released the plug point and it won't break anyone. 2 is a close second preference because it only breaks implementors and has a clearer implementation contract. Option 1 is probably what I should have done for the first release if I'd thought ahead, but it feels like it might break too many people now. I don't know if anyone else wants to weigh in here? I'm also going to start another email thread to find out what the continuing plan is for interface compatability. At the moment it looks like we use the bundle version for all the packages which would really suck! Regards Tim ---------------------------------------- > Date: Wed, 2 Jun 2010 16:51:36 -0400 > From: [email protected] > To: [email protected] > Subject: [jira] Commented: (ARIES-320) Support ClassTransformers for PUs > > > [ > https://issues.apache.org/jira/browse/ARIES-320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12874793#action_12874793 > ] > > Jarek Gawor commented on ARIES-320: > ----------------------------------- > > Reverted this change in revision 950757 as the same thing could be achieved > via ManagedPersistenceUnitInfoFactory extensions. > > >> Support ClassTransformers for PUs >> --------------------------------- >> >> Key: ARIES-320 >> URL: https://issues.apache.org/jira/browse/ARIES-320 >> Project: Aries >> Issue Type: New Feature >> Components: JPA >> Affects Versions: 0.2 >> Reporter: Jarek Gawor >> Assignee: Jarek Gawor >> Fix For: 0.2 >> >> >> One way of supporting runtime enhancement of JPA entity classes is via java >> agent approach. Aries JPA should allow for java agent based enhancement. > > -- > This message is automatically generated by JIRA. > - > You can reply to this email to add a comment to the issue online. > _________________________________________________________________ http://clk.atdmt.com/UKM/go/197222280/direct/01/ Do you have a story that started on Hotmail? Tell us now
