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
