Hi Jarek,
I'd first like to say, thank you for looking at the JPA component and adding new features. It isn't my intention to prevent you from using or enhancing any of the aries code. I simply missed the background for the features and so didn't have an opportunity to share any of the pre-existing design of the JPA bundles. The reason I'm speaking up now is simply to try to make sure that we keep a consistent approach with the code even though different people are working on it. The existing plug point in the PersistenceBundleManager allows for the ManagedPersistenceUnitFactory to be replaced with a different implementation, returning customized ManagedPersistenceUnitInfo instances. We attempt to read the name of the ManagedPersistenceUnitFactory implementation from a properties file called org.apache.aries.jpa.container.properties, and we expect the property key to be org.apache.aries.jpa.container.ManagedPersistenceUnitFactory There are comments as documentation in the ManagedPersistenceUnitFactory interface, as well as a few references in the PersistenceBundleManager, but I agree it would be better to put something up on the website too. Our expectation was that plugins could be written as fragments to the jpa container bundle, including the properties file to set their ManagedPersistenceUnitFactory. As a fragment it is possible to export additional, plug-in specific, interfaces (e.g. the listener ortransformer) so that implementors only resolve if the fragment is active. It is also possible to subclass the existing ManagedPersistenceUnit* classes so that only a few methods have to be reimplemented. I believe that the java agent weaving support is probably best added through a fragment. Most users will not be running with a java agent, so I'd rather it wasn't provided by the core jpa container or API bundles, but I do think it's a good idea to have the support available in the Aries JPA project. Perhaps there should be a common JPA extensions fragment in Aries? As for the Listener interface, I'm not sure what the intended use case is. It may make more sense for that function to remain in the core bundles if the use case is in the 80% usage pattern, otherwise it might make more sense to live in the "extensions" fragment and for us to think about how best to make that fragment configurable. What are your thoughts? Regards, Tim > Date: Wed, 2 Jun 2010 10:43:22 -0400 > Subject: Re: [jira] Commented: (ARIES-320) Support ClassTransformers for PUs > From: [email protected] > To: [email protected] > > Tim, > > What existing plug points do you mean? I didn't see any obvious plug > points but I guess I could have missed them. If there are better > existing plug points I don't mind using them just don't want to > replicate a ton of code. > > My changes addressed two issues there were marked as TODO in the code > and which help to get runtime enhancement working with the javaagent > approach and fragment bundles. > > Jarek > > On Wed, Jun 2, 2010 at 6:46 AM, Timothy Ward <[email protected]> wrote: > > > > > > Hi Jarek, > > > > I think this is another one I missed the discussion for. It was my belief > > that any bytecode weaving would be done by third parties using the existing > > plug point until there is a common solution for weaving in OSGi. > > > > Might a better solution be to provide a "weaving fragment" for the JPA code > > that uses the previously existing extension? This would keep the core code > > clear for the future standardized mechanism and provide less of a > > compatability headache in the future. > > > > From my perspective I'd prefer to keep the number of plug points in the > > core code path to a minimum. So far I haven't seen anything that can't be > > done within the existing code, but please let me know if I'm missing > > something in the bigger picture. > > > > Regards, > > > > Tim > > > > ---------------------------------------- > >> Date: Tue, 25 May 2010 19:45:31 -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=12871438#action_12871438 > >> ] > >> > >> Jarek Gawor commented on ARIES-320: > >> ----------------------------------- > >> > >> Added support for TransformerAgent service. Once detected the PUs will > >> register/unregister its ClassTransformers with it. Committed in revision > >> 948256. > >> > >> > >>> 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 _________________________________________________________________ http://clk.atdmt.com/UKM/go/197222280/direct/01/ Do you have a story that started on Hotmail? Tell us now
