geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aaron Mulder" <ammul...@alumni.princeton.edu>
Subject Re: RTC PLEASE COMMENT Priority order for starting gbeans.
Date Mon, 06 Nov 2006 20:47:04 GMT
So for the JPA plugin, we just applied the transformer in the class
loader.  I'm not super-confident of the specific implementation -- but
is there a reason why this approach wouldn't work for us in Geronimo
(since we have a custom class loader already)?

http://gplugins.svn.sourceforge.net/viewvc/gplugins/jpa/trunk/base/common/src/java/org/gplugins/jpa/app/TransformingClassLoader.java?revision=28&view=markup

Thanks,
     Aaron

On 11/6/06, David Jencks <david_jencks@yahoo.com> wrote:
>
> 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
> >
>
>

Mime
View raw message