Re: RTC PLEASE COMMENT Priority order for starting gbeans.

[David Jencks]

On Nov 6, 2006, at 1:33 PM, Aaron Mulder wrote:
Well, if we go the class loader route, we could make it a feature of
the Configuration and the deployer could just set transformer classess
on the Configuration or Configuration Class Loader, and it could be
independent of the GBeans in the module.  It seems to me to be a
somewhat more straightforward approach than the GBean-ordering option
(though that feature probably has other advantages).

can you go into more detail on what you are thinking of?   I don't  
understand.  It looks to me as if you are proposing building a list  
of what are now PersistenceUnitGBeans directly into the  
configuration.   We can't extract a Transformer from the jpa  
implementation, we have to wait until it does (or doesn't) try to  
install one (or more) in its own sweet time.   Aside from making  
geronimo completely jdk 1.5 only, I don't see why we should put  
support for very specific jpa features into one of our core components.

thanks
david jencks


Thanks,
     Aaron

On 11/6/06, David Jencks <[EMAIL PROTECTED]> wrote:

On Nov 6, 2006, at 12:47 PM, Aaron Mulder wrote:

> 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

We could probably do something like that but I'd rather keep the code
simple and use  the jvm facilities.  If someone else wants to
experiment with this approach, fine.  In any case this doesn't really
have a bearing on the gbean priority implementation:  no matter how
the transformer is installed it still needs to be installed before we
start loading classes.

thanks
david jencks

>
> Thanks,
>     Aaron
>
> On 11/6/06, David Jencks <[EMAIL PROTECTED]> 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
>> >
>>
>>