On Nov 6, 2006, at 12:25 PM, Dain Sundstrom wrote:
So to be clear, I'm generally against adding destabilizing features
that aren't required to meet the features we have chosen for the
1.2 release. Does OpenJPA use a runtime class transformer?
OpeneJPA can pre-enhance classes (using an ant task) or do runtime
enhancement. The jpa contracts require that we implement
PersistenceUnitInfo.addTransformer which lets the persistence
provider install a transformer. The code I've written to make this
work uses the java 5 java.lang.instrument facilities which
unfortunately requires and elaborated command line like:
java -javaagent:bin/jpa.jar -jar bin/server.jar
to get the agent picked up. If you just start the server you don't
get errors, but you don't get runtime enhancement either.
Currently runtime enhancement doesn't work if classes that need to be
enhanced get loaded while gbean datas are deserialized. So far I
know this can happen with ejb web services that include methods that
have enhanced classes as parameters. It doesn't happen with ejbs
that don't have enhanced classes as parameters. I think that most
users will want to work in eclipse or similar ide and not want to
have to rebuild + pre-enhance their classes during development.
Runtime enhancement is a required feature for full jpa support. I
think it's going to be pretty convenient when it works. Therefore I
think that if there aren't backwards compatibility problems with
this stuff after gianny's fix we should keep it.
thanks
david jencks
-dain
On Nov 6, 2006, at 10:26 AM, Dain Sundstrom wrote:
As I mentioned on IRC, I would prefer if we keep changes like this
out of 1.2. From what I understand it is unnecessary since
OpenJPA doesn't even use a transformer, so we are just
destabilizing and breaking backwards compatibility.
Can you explain how this works? I don't see the code that is
actually using this feature.
-dain
On Nov 5, 2006, at 12:54 AM, David Jencks wrote:
See GERONIMO-2541
In order for runtime class enhancement for jpa to have any chance
of working, the persistence provider has to get started before
much of anything else happens so it can install the bytecode
transformer before any classes that need enhancement get loaded.
To support this I wrote a priority order loading feature for
gbeans, see GERONIMO-2541. This is pretty simple and appears to
work fine except it will prevent any pre-1.2 configurations from
running on 1.2 servers: I have to write the priority for each
gbeandata in the serialized gbeanstate. I don't know how to fix
this: if anyone else does please speak up.
Runtime enhancement seems to work ok with this feature for simple
apps that use ejbs and web apps but there are some situations in
which I cannot get runtime enhancement to work because the
classes are loaded when some gbeans are loaded before any gbeans
are started. So far this has occurred with web services that use
an enhanced class as a paramenter: I think that the axis 1
mapping info includes seriailzed class instances rather than the
names of the classes involved.
So, is runtime enhancement for some jpa apps worth breaking
backwards compatibility for configs? Can we do something to
recognize both old and new config formats? If I don't hear
anything against this in a few days (about 3) I'm going to go
ahead and break backwards compatibility and commit this
patch..... you are warned.
thanks
david jencks
