Rick, completely understand and agree that there should be no magic. Classes have to be identified as being persistent, and some kind of interception has to take place. I recognise that the industry standard way to approach this is through containers in which system-level capabilities like persistence are engineered from-the-outside-in through augmentation of the bytecode, or JVM, configured by XML. Actually this IS a lot like magic from the programmer's perspective, which is why I'm suspicious of it.
I think you're saying there's no established way to achieve this with procedural java and OpenJPA (and I don't see it anywhere else either). I'm fairly comfortable in principle with the need for enhancement but simply aiming to achieve it in a particular way. To summarise in response to your points... * The classes carry javax.persistence Annotations. They could additionally be listed and passed to a java method. I'm not saying they should be identified or configured by magic. * The objects are already being created through a dependency injection engine, and conform strictly to interfaces, so augmentation to satisfy a Persistence engine is feasible procedurally in a typical JVM. I'm not saying they should be enhanced by magic either. For good or ill, the XML route is part of the standard. I just wonder whether also supporting a more Java-oriented mode of enhancement could be valuable, especially given issues around type-safety. I imagine naively that the code itself must already exist - this is just another way to introduce it. I'm partly inspired here by the difference between Spring (XML city) and Guice (no XML at all), and looking for a similarly unambiguous Java way to bring in persistence. The point about Skyhooks is a bit facetious, sorry, but is derived from this... http://en.wikipedia.org/wiki/Skyhook_(concept)#Skyhooks_and_cranes ...where they are contrasted with Cranes. Procedural java is a thing you can specify explicitly, debug and pin down. In my view it's the Crane. I see no technical reason why procedural java (as opposed to bytecode or JVM augmentation) shouldn't be used to intercept object construction procedurally, and do the appropriate wrapping in a way which is easy to nail down. Unless I find a way to do it myself I could be waiting a long time as I think I'm in the minority. It doesn't look like any JPA engine provider is interested in exposing its persistence hooks sufficiently to support this mode, or at least I haven't found how. The shotgun blast of information is always useful, and in particular the PersistenceCapable interface is where my investigations should go next. Looks like I need to know what the enhancement actually does, if I want to trigger it through Java. Thanks again. Cefn http://cefn.com PS I expected that listing a class in persistence.xml would cause an unlisted @MappedSuperclass in its inheritance heirarchy to also be enhanced, especially since a runtime failure is triggered otherwise. I was wrong. It seems unnecessary since the information is already there in Java but I'll have to make this more explicit in future. ________________________________________ From: Rick Curtis [[email protected]] Sent: 17 November 2010 15:18 To: [email protected] Subject: Re: OpenJPA Enhancement fail - suggestions? Cefn - > I thought I'd already brought in runtime enhancement using the OpenJPA agent. You did and you also said you weren't able to get enhancement working... I thought maybe a shotgun blast of information would get you going. :-) > Can I manually configure the MethodInterceptor capabilities of a Dependency Injector to explicitly trigger whatever augmentation is needed, as described here? Are there examples of this being done elsewhere? Not that I'm aware of. > skyhook programming model I'm not familiar to that programming model... > All the mechanisms seem to rely on the use of a persistence.xml file in META-INF - pretty unsatisfactory to drop out of Java and into a type-unsafe serialisation language, but I can't find an alternative mechanism. This mechanism of using persistence.xml to configure your persistence unit is something that is defined by the JPA spec. > To get it working I've resorted to a manual list of strings inside <class></class> elements. All classes (including abstract mapped superclasses) had to be listed here, so the inheritance structures in Java weren't being employed either! Listing your classes has nothing to do with Java inheritance, it is a way to inform OpenJPA of the Entities to operate over. This is how we know whether or not we should enhance a given type... or when you execute a query "Select p FROM Person p" we know that Person is mapped to foo.Person.class. > Is there a way to simply pass a list of classes into a Java method in an unmodified VM, recursively trigger introspection of a whole package or even have my java persistence invocations configure things? Are you asking if there is a way that OpenJPA will auto configure a persistence unit for you? If so, I don't know of any such magic. Thanks, Rick On Wed, Nov 17, 2010 at 4:11 AM, <[email protected]> wrote: > Thanks for getting back to me. The enhancement link is relevant, but as I > mentioned in the original mail, I thought I'd already brought in runtime > enhancement using the OpenJPA agent. > > Using Java invocation would be hugely preferable. Can I manually configure > the MethodInterceptor capabilities of a Dependency Injector to explicitly > trigger whatever augmentation is needed, as described here? Are there > examples of this being done elsewhere? > http://code.google.com/p/google-guice/wiki/AOP > > To achieve enhancement I used a post-compile enhance.xml Ant task, combined > with > -javaagent:lib/openjpa/openjpa-all-2.0.1.jar=jdoEnhance=true,scanDevPath=true > passed to the VM on launch. At this stage I've no idea which of these is > actually doing the enhancement and how, which is why I'm working to avoid a > skyhook programming model. > > All the mechanisms seem to rely on the use of a persistence.xml file in > META-INF - pretty unsatisfactory to drop out of Java and into a type-unsafe > serialisation language, but I can't find an alternative mechanism. To get it > working I've resorted to a manual list of strings inside <class></class> > elements. All classes (including abstract mapped superclasses) had to be > listed here, so the inheritance structures in Java weren't being employed > either! > > Is there a way to simply pass a list of classes into a Java method in an > unmodified VM, recursively trigger introspection of a whole package or even > have my java persistence invocations configure things? The MethodInterceptor > model would be the ideal way to go for me, but I don't want to go so far > under the hood that it clicks shut behind me. > > Cefn > http://cefn.com > ________________________________________ > From: Rick Curtis [[email protected]] > Sent: 16 November 2010 15:54 > To: [email protected] > Subject: Re: OpenJPA Enhancement fail - suggestions? > > How are you enhancing your classes? Please take a read through this > page[1]. > > [1] http://openjpa.apache.org/entity-enhancement.html > > Thanks, > Rick >
