You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by David Jencks <da...@yahoo.com> on 2006/11/05 09:54:20 UTC
RTC PLEASE COMMENT Priority order for starting gbeans.
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
Re: RTC PLEASE COMMENT Priority order for starting gbeans.
Posted by David Jencks <da...@yahoo.com>.
Since Gianny fixed the reason I thought there might be a question
about this code I intend to commit it (including gianny's backward-
compatibility fix) shortly.
Many thanks Gianny!
david jencks
On Nov 5, 2006, at 5:38 AM, Gianny Damour wrote:
> Hi,
>
> I reviewed the proposed patch and it is ok. Also , I have submitted
> a geronimo-kernel only patch to maintain compatibility with
> previous releases.
>
> Thanks,
> Gianny
>
>
> On 05/11/2006, at 7:54 PM, 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
>>
>
Re: RTC PLEASE COMMENT Priority order for starting gbeans.
Posted by Gianny Damour <gi...@optusnet.com.au>.
Hi,
I reviewed the proposed patch and it is ok. Also , I have submitted a
geronimo-kernel only patch to maintain compatibility with previous
releases.
Thanks,
Gianny
On 05/11/2006, at 7:54 PM, 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
>
Re: RTC PLEASE COMMENT Priority order for starting gbeans.
Posted by Dain Sundstrom <da...@iq80.com>.
+1 commit it
-dain
On Nov 6, 2006, at 12:38 PM, David Jencks 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
>>
Re: RTC PLEASE COMMENT Priority order for starting gbeans.
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
On 11/6/06, David Jencks <da...@yahoo.com> wrote:
> 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.
I don't have a real thorough understanding of the JPA mechanics, so
it's possible I'm totally off-base. For some reason I thought the
list of transformers would be available at deployment time -- but if
they're only registered at runtime, that's definitely a different
scenario.
Anyway, I was thinking that our Configuration ClassLoader could have a
hook like "addTransformer(Transformer t)", which could be called by
something during startup. If we knew what the transformer class names
were during deployment, then the deployer could add them to a list
property on the Configuration, and the Configuration could instantiate
and apply them to the Configuration ClassLoader while loading, so
they'd be there "from the beginning". If they are only coughed up by
the JPA provider at runtime, that wouldn't be an option.
In any case I had been thinking the class transformer feature was more
generic (and might be reused by other features in or out of Java EE),
but upon inspection it looks like it's JPA-specific, so I guess this
is probably not a super idea.
Thanks,
Aaron
Re: RTC PLEASE COMMENT Priority order for starting gbeans.
Posted by David Jencks <da...@yahoo.com>.
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 <da...@yahoo.com> 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 <da...@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
>> >> >
>> >>
>> >>
>>
>>
Re: RTC PLEASE COMMENT Priority order for starting gbeans.
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
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).
Thanks,
Aaron
On 11/6/06, David Jencks <da...@yahoo.com> 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 <da...@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
> >> >
> >>
> >>
>
>
Re: RTC PLEASE COMMENT Priority order for starting gbeans.
Posted by David Jencks <da...@yahoo.com>.
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 <da...@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
>> >
>>
>>
Re: RTC PLEASE COMMENT Priority order for starting gbeans.
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
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 <da...@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
> >
>
>
Re: RTC PLEASE COMMENT Priority order for starting gbeans.
Posted by David Jencks <da...@yahoo.com>.
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
>
Re: RTC PLEASE COMMENT Priority order for starting gbeans.
Posted by Dain Sundstrom <da...@iq80.com>.
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?
-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
Re: RTC PLEASE COMMENT Priority order for starting gbeans.
Posted by Dain Sundstrom <da...@iq80.com>.
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