Re: the pain of post processing bytecode (another beg for a simple reflection/cglib alternative like hibernate)
Hi Philippe,
It looks like your attachment was dropped by the mailing list so I'm
guessing a little here. I did try setting all of this up from scratch with
one of my Eclipse projects, here's what I did.
Downloaded openjpa-project-0.9.7-incubating-source.zip and
openjpa-project-0.9.7-incubating-binary.zip and extract them (directory
/home/mikedd/downloads in my case).
Add the openjpa-* jar to my Eclipse project's classpath as an external jar.
I'm cheating a bit and picking up the other dependencies from my maven
repository, but that shouldn't matter.
Create a run definition for your application. Add
-javaagent:/home/mikedd/download/openjpa-project-0.9.7-incubating/openjpa-
0.9.7-incubating.jar as a vm arg. On the source tab add the source
directories for each OpenJPA subproject (ie /home/mikedd/downloads/openjpa-
project-0.9.7-incubating-source/openjpa-persistence/src/main/java ).
I think that's about it then you should be able to run your application,
debug OpenJPA or your entities if you want, etc. The mailing list has
rejected my message whenever I attach screenshots so I'll send them directly
to you instead.
Hope this helps,
-Michael Dick
On 5/20/07, Philippe Alexis [EMAIL PROTECTED] wrote:
Hi Everyone,
Not meaning to hi-jack it, I'll piggy-back on this thread because I've
made some progress setting up
OpenJPA as an Eclipse project thanks to some tips below from Michael. It's
been a long arduous road
over the whole weekend...
I went for compile-time enhancement via an Ant script as a user-defined
builder because as per the
attached screenshot, Eclipse-VM-params.PNG, (I hope having that is not
against the list's policy)
dynamic enhancement via -javaagent:${path_to_openjpa-*.jar} hasn't worked
so far and yields the error
message as shown in Eclipse's Console window. Is it working? I doubt it.
There's no [openjpac] output by Ant.
At least, the end of it says Build Successful.
The other screenshot, Eclipse-BrokerFactory-not-found.png, is where I've
reached stepping through the project
this far, running the Main.java of the Deity example.
You did not name the factory class with the required property
openjpa.BrokerFactory.
Normally this property defaults appropriately; have you forgotten to
include all the OpenJPA jars in your classpath?
Where would that be defined by default?
Would anyone be so kind as to post a similar screenshot of what's required
as Source folders to successfully debug
OpenJPA under Eclipse? I'm probably not too far but it's... late.
J-Philippe.
On 5/17/07, Michael Dick [EMAIL PROTECTED] wrote:
Hi James,
I don't know how easy this is to do with IDEA, but what I've done in
Eclipse
is to create the project via mvn eclipse:eclipse then create a run
definition for org.apache.openjpa.enhance.PCEnhancer . With no other
classpath tweaking it enhances the entities in the output directory and
I'm
up and running.
Eclipse also allows user defined builders to be run in addition to the
default java compiler. The builders can be ant scripts or java programs
-
either one should be able to enhance your entities. I have never used
IDEA,
but I suspect it includes a similar concept.
All that being said I'm not trying to dismiss your idea of adding a
cglib
interface - I'm just sharing what has worked for me and some ideas that
might also work for you. It's a bit specific to Eclipse, but from what
I've
heard IDEA is a very good IDE and I suspect it can do them as well.
-Mike
On 5/17/07, James.Strachan [EMAIL PROTECTED] wrote:
Firstly before I start, openjpa is a great piece of software; I'm
particularly fond of the documentation and in particular the query
language
parts. The CSS for the site is also awesome :)
However compared to hibernate, openjpa is still pretty painful to use
from
an end users perspective and I don't think this should be the case;
plus I
don't think it'll take much time to fix. While the pain is still fresh
in
my
mind I thought I'd post on how much more painful openjpa is to use in
a
project. If you're short on time, the basic idea is its that bytecode
post
processing stuff thats to blame :). Yes I know its probably faster
that
way
- its just so painful for Java programmers to work with. (And yes I
know
one
day we'll all have IDE plugins that hide the bytecode stuff etc etc).
So the first thing is having to mess with your build (ant or maven) to
get
the post processing properly integrated. Depending on if you have
persistent
entities in your main or test area this can often trip you up a little
(as
it did me). I don't know about folks on this list but the whole idea
of
having to mess with my maven build gives me the jitters :). When you
get
that far the maven planets are aligned with openjpa, the next hurdle
you
hit is how do you run stuff in your IDE. If like me you use IDEA and
maven
2, the project gets auto-created by default for all projects you work
on.
However
Re: the pain of post processing bytecode (another beg for a simple reflection/cglib alternative like hibernate)
Marc Prud'hommeaux wrote: I think this is a very worthwhile project. James and a few others excoriated me about this issue over beers after JavaOne last week, and, while the bruises from their rhetorical assault are still healing, their observations about the comparative out of the box ease of use OpenJPA compared to other systems definitely bears attention. I hope the bruises heal soon btw :) -- James --- http://macstrac.blogspot.com/ -- View this message in context: http://www.nabble.com/the-pain-of-post-processing-bytecode-%28another-beg-for-a-simple-reflection-cglib-alternative-like-hibernate%29-tf3770760.html#a10722953 Sent from the open-jpa-dev mailing list archive at Nabble.com.
Re: the pain of post processing bytecode (another beg for a simple reflection/cglib alternative like hibernate)
djencks wrote: James, Could extract from this verbiage the scenarios you'd like supported? The simplest scenario is, take any maven 2 project which is using hibernate. Switch the hibernate jars to openjpa jars edit the bits of the persistence.xml that are required and have things work properly in your IDE and maven build without having to resort to explicit bytecode post processing in your build. djencks wrote: Do you need to run tests inside IDEA and have you classes enhanced after IDEA compiles them for you? Do you need to run in a separate jvm, e.g. from maven, and have the classes enhanced as they are loaded? Yes to both djencks wrote: I think the second of these can probably be made to work without any openjpa code changes by doing the same thing geronimo does, running with an enhancer agent that delegates to the openjpa enhancer as appropriate. The enhancer is a good workaround for now, thanks. Though I still think it should be easier for users; things should just work out of the box like they do with hibernate without any secret ninja jvm tweaking, magic class loaders or whatnot. djencks wrote: I'd imagine that if IDEA creates a new classloader for running the tests, and we can get some access to something about it, it ought to be possible to do on the fly enhancement there also. What exactly are the problems with looking at an enhanced class in IDEA? I haven't run into thembut I may not have been trying to debug the enhanced classes but rather openjpa + geronimo. Mostly when you navigate into stack traces, or traverse class relationships in the IDE you end up hitting the 'bytecode' (decompiled view) rather than the source view. -- James --- http://macstrac.blogspot.com/ -- View this message in context: http://www.nabble.com/the-pain-of-post-processing-bytecode-%28another-beg-for-a-simple-reflection-cglib-alternative-like-hibernate%29-tf3770760.html#a10723042 Sent from the open-jpa-dev mailing list archive at Nabble.com.
Re: the pain of post processing bytecode (another beg for a simple reflection/cglib alternative like hibernate)
Patrick Linskey-2 wrote: How hard is it to add a reflection/cglib type alternative to the upfront bytecode generation (like hibernate does) to save us from the development-time pain? Not particularly hard. There are a few APIs that would break for some cases, but it's even pretty straightforward to do a subclassing approach for property-based access type without losing much performance -- the only cost in that configuration is with persistent-new instances. -Patrick Awesome - can't wait for it to be supported :) Should I raise a JIRA? -- James --- http://macstrac.blogspot.com/ -- View this message in context: http://www.nabble.com/the-pain-of-post-processing-bytecode-%28another-beg-for-a-simple-reflection-cglib-alternative-like-hibernate%29-tf3770760.html#a10723139 Sent from the open-jpa-dev mailing list archive at Nabble.com.
Re: the pain of post processing bytecode (another beg for a simple reflection/cglib alternative like hibernate)
I hope the bruises heal soon btw :) Time heals all wounds. At least, that's what I'm told. On May 21, 2007, at 10:09 AM, James.Strachan wrote: Marc Prud'hommeaux wrote: I think this is a very worthwhile project. James and a few others excoriated me about this issue over beers after JavaOne last week, and, while the bruises from their rhetorical assault are still healing, their observations about the comparative out of the box ease of use OpenJPA compared to other systems definitely bears attention. I hope the bruises heal soon btw :) -- James --- http://macstrac.blogspot.com/ -- View this message in context: http://www.nabble.com/the-pain-of- post-processing-bytecode-%28another-beg-for-a-simple-reflection- cglib-alternative-like-hibernate%29-tf3770760.html#a10722953 Sent from the open-jpa-dev mailing list archive at Nabble.com.
Re: the pain of post processing bytecode (another beg for a simple reflection/cglib alternative like hibernate)
Hi Everyone,
Not meaning to hi-jack it, I'll piggy-back on this thread because I've made
some progress setting up
OpenJPA as an Eclipse project thanks to some tips below from Michael. It's
been a long arduous road
over the whole weekend...
I went for compile-time enhancement via an Ant script as a user-defined
builder because as per the
attached screenshot, Eclipse-VM-params.PNG, (I hope having that is not
against the list's policy)
dynamic enhancement via -javaagent:${path_to_openjpa-*.jar} hasn't worked so
far and yields the error
message as shown in Eclipse's Console window. Is it working? I doubt it.
There's no [openjpac] output by Ant.
At least, the end of it says Build Successful.
The other screenshot, Eclipse-BrokerFactory-not-found.png, is where I've
reached stepping through the project
this far, running the Main.java of the Deity example.
You did not name the factory class with the required property
openjpa.BrokerFactory.
Normally this property defaults appropriately; have you forgotten to
include all the OpenJPA jars in your classpath?
Where would that be defined by default?
Would anyone be so kind as to post a similar screenshot of what's required
as Source folders to successfully debug
OpenJPA under Eclipse? I'm probably not too far but it's... late.
J-Philippe.
On 5/17/07, Michael Dick [EMAIL PROTECTED] wrote:
Hi James,
I don't know how easy this is to do with IDEA, but what I've done in
Eclipse
is to create the project via mvn eclipse:eclipse then create a run
definition for org.apache.openjpa.enhance.PCEnhancer . With no other
classpath tweaking it enhances the entities in the output directory and
I'm
up and running.
Eclipse also allows user defined builders to be run in addition to the
default java compiler. The builders can be ant scripts or java programs -
either one should be able to enhance your entities. I have never used
IDEA,
but I suspect it includes a similar concept.
All that being said I'm not trying to dismiss your idea of adding a cglib
interface - I'm just sharing what has worked for me and some ideas that
might also work for you. It's a bit specific to Eclipse, but from what
I've
heard IDEA is a very good IDE and I suspect it can do them as well.
-Mike
On 5/17/07, James.Strachan [EMAIL PROTECTED] wrote:
Firstly before I start, openjpa is a great piece of software; I'm
particularly fond of the documentation and in particular the query
language
parts. The CSS for the site is also awesome :)
However compared to hibernate, openjpa is still pretty painful to use
from
an end users perspective and I don't think this should be the case; plus
I
don't think it'll take much time to fix. While the pain is still fresh
in
my
mind I thought I'd post on how much more painful openjpa is to use in a
project. If you're short on time, the basic idea is its that bytecode
post
processing stuff thats to blame :). Yes I know its probably faster that
way
- its just so painful for Java programmers to work with. (And yes I know
one
day we'll all have IDE plugins that hide the bytecode stuff etc etc).
So the first thing is having to mess with your build (ant or maven) to
get
the post processing properly integrated. Depending on if you have
persistent
entities in your main or test area this can often trip you up a little
(as
it did me). I don't know about folks on this list but the whole idea of
having to mess with my maven build gives me the jitters :). When you get
that far the maven planets are aligned with openjpa, the next hurdle
you
hit is how do you run stuff in your IDE. If like me you use IDEA and
maven
2, the project gets auto-created by default for all projects you work
on.
However these don't work when you use openjpa as you hit the dreaded
'cannot
function at all as you've not run the up front bytecode post processor
you
dummy!' type error when trying to run stuff in your IDE.
So you then add the maven-generated classes to the front of the
classpath
in
your project. Hooray, after a day or two's work, you can now actually
use
openjpa in your IDE and your build. YAY! The downside is that now when
navigating around your Java code, whenever you navigate into an entity
bean,
IDEA shows you the bytecode - not the source code as its confused since
the
bytecode generated stuff is different to the source code it knows about.
So
now you're faced with a dilemma - choose between navigating nicely
around
your source code - or being able to actually run/debug your application.
I
won't even get into the refactoring pain or having to continuously run
maven
builds while developing code to avoid getting code completion/compile
errors
etc. (I prefer to keep in my IDE where possible).
Compare this whole malarkey with hibernate. You add hibernate to your
pom,
generate your project and you're good to go. No messing with your
project
build; no messing with some secret ninja IDE stuff to be able to
actually
run debug your code while
Re: the pain of post processing bytecode (another beg for a simple reflection/cglib alternative like hibernate)
I think that there are at least three worthy goals here:
1. Help users migrate from Hibernate to OpenJPA.
2. Help users who want the performance advantages of enhancement to
more easily integrate enhancement into their build/deploy environment.
3. Help users who want to get started with OpenJPA and not deal with
enhancement at all (i.e. have a mode in which OpenJPA runs without
enhancement, albeit slower).
Each of these is a separable project that can be discussed and
implemented independently.
Craig
On May 18, 2007, at 6:31 AM, Phill Moran wrote:
Let's also keep in mind that hibernate, although open source, is
not public
standards based. This will drive some traffic towards JPA. Also as
David pointed
out there is some cost to starting with any persistence framework
(or really any
framework) so total plug and play for no time I think is an
unattainable goal.
Phill
-Original Message-
From: David Ezzio [mailto:[EMAIL PROTECTED]
Sent: May 18, 2007 8:07 AM
To: open-jpa-dev@incubator.apache.org
Subject: Re: the pain of post processing bytecode (another beg for
a simple
reflection/cglib alternative like hibernate)
Hi Marc,
The goal of drop-in and play functionality is wonderful, but I
doubt that the
modest proposals thus far will achieve it.
Given that the JPA spec specifies only the EJB-3 configuration, I
don't see how
we can achieve drop-in and play compatibility with application
development
environments configured for any arbitrary JPA implementaion.
At one point, I had code examples working with every known
implementation of
JDO. Even after I had a half dozen implementations under my belt,
it still took
a day or two to get the next implementation working with a sample
application of
my own choosing. I'm guessing that the effort required hasn't
changed for JPA
implementations.
Also, I'm incline to doubt that vendors (even open source vendors)
see it as in
their interest to make it easier for users to switch. Reducing
switching costs
to zero is an interesting goal, but I'm not sure how much value is
there.
Perhaps our goal is more modest, just to make it easier for
Hibernate users to
switch to OpenJPA. Since Hibernate is more popular than OpenJPA,
there's some
real value for us in that.
Best wishes,
David
Marc Prud'hommeaux wrote:
On May 17, 2007, at 5:31 PM, David Ezzio wrote:
I think that the issues raised are best solved with tools,
documentation, and examples.
Of course, if one has been coding to Hibernate for years, it's
unlikely that any combination of tools, documentation, and examples
will make OpenJPA easier to use for that person, but that's not
the standard.
Sure it will. If you are using one JPA implementation, be it
Hibernate, Toplink, or anything else, and you want to drop in
OpenJPA to test it out and see what the performance difference is, if
it doesn't work immediately, you are likely to walk away.
I think that easing the process for someone already familiar with JPA
to get started with OpenJPA without having to pour through
documentation about build-time tools or runtime agent flags is a
supremely useful project, especially at this point where we are on
the
brink of graduation and will soon be getting a lot more attention.
Another important point, in my view, is to make sure the tests
run as
well on Windows (without cygwin!) as they do on Linux, Unix, and
OS/X.
For example, using File.separator to construct resource path names
works great on everything but Windows.
This seems orthogonal to the issue of easing OpenJPA's bytecode
enhancement process. If you find cases where we are relying on
hardcoded UNIX paths, these are obviously bugs and should be handled
by creating JIRA issues.
David
Marc Prud'hommeaux wrote:
I think this is a very worthwhile project. James and a few others
excoriated me about this issue over beers after JavaOne last week,
and, while the bruises from their rhetorical assault are still
healing, their observations about the comparative out of the box
ease of use OpenJPA compared to other systems definitely bears
attention.
As Patrick mentioned, we aren't too far away from being able to use
a dynamic subclassing approach.
Another option I've been thinking about recently is that in JDK
1.6,
you can dynamically attach an agent at runtime to your own JVM
(using an implementation-specific mechanism), and using the
provided
Instrumentation, you can redefine existing methods in classes, even
after the classes have already been loaded. While you cannot add or
remove methods or fields, we might be able to re-work our
PCEnhancer
to use a newly-generated inner class and a lookup in some
IdentityHashMap to perform the same function. E.g., instead of our
currently enhanced
class:
public class SomeEntity {
private String someField;
private StateManager stateManager; // generated
public String getSomeField() {
return pcgetSomeField(this);
}
//
Re: the pain of post processing bytecode (another beg for a simple reflection/cglib alternative like hibernate)
Hi James,
I don't know how easy this is to do with IDEA, but what I've done in Eclipse
is to create the project via mvn eclipse:eclipse then create a run
definition for org.apache.openjpa.enhance.PCEnhancer. With no other
classpath tweaking it enhances the entities in the output directory and I'm
up and running.
Another alternative would be to use dynamic enhancement when you run in your
IDE. In eclipse you can just add -javaagent:${path.to.openjpa-xxx.jar} as a
vm argument and you won't have to run the enhancer at all.
Patrick also mentioned writing an IDEA plug-in (not sure if that's the right
name) that would do the enhancement. I believe he ran into a few snags
getting access to IntelliJ jars. This or something similar might be a good
solution for you. Ideally we'll have Eclipse, IDEA and NetBeans plugins
someday.
Eclipse also allows user defined builders to be run in addition to the
default java compiler. The builders can be ant scripts or java programs -
either one should be able to enhance your entities. I have never used IDEA,
but I suspect it includes a similar concept.
All that being said I'm not trying to dismiss your idea of adding a cglib
interface - I'm just sharing what has worked for me and some ideas that
might also work for you. It's a bit specific to Eclipse, but from what I've
heard IDEA is a very good IDE and I suspect it can do them as well.
-Mike
On 5/17/07, James.Strachan [EMAIL PROTECTED] wrote:
Firstly before I start, openjpa is a great piece of software; I'm
particularly fond of the documentation and in particular the query
language
parts. The CSS for the site is also awesome :)
However compared to hibernate, openjpa is still pretty painful to use from
an end users perspective and I don't think this should be the case; plus I
don't think it'll take much time to fix. While the pain is still fresh in
my
mind I thought I'd post on how much more painful openjpa is to use in a
project. If you're short on time, the basic idea is its that bytecode post
processing stuff thats to blame :). Yes I know its probably faster that
way
- its just so painful for Java programmers to work with. (And yes I know
one
day we'll all have IDE plugins that hide the bytecode stuff etc etc).
So the first thing is having to mess with your build (ant or maven) to get
the post processing properly integrated. Depending on if you have
persistent
entities in your main or test area this can often trip you up a little (as
it did me). I don't know about folks on this list but the whole idea of
having to mess with my maven build gives me the jitters :). When you get
that far the maven planets are aligned with openjpa, the next hurdle you
hit is how do you run stuff in your IDE. If like me you use IDEA and maven
2, the project gets auto-created by default for all projects you work on.
However these don't work when you use openjpa as you hit the dreaded
'cannot
function at all as you've not run the up front bytecode post processor you
dummy!' type error when trying to run stuff in your IDE.
So you then add the maven-generated classes to the front of the classpath
in
your project. Hooray, after a day or two's work, you can now actually use
openjpa in your IDE and your build. YAY! The downside is that now when
navigating around your Java code, whenever you navigate into an entity
bean,
IDEA shows you the bytecode - not the source code as its confused since
the
bytecode generated stuff is different to the source code it knows about.
So
now you're faced with a dilemma - choose between navigating nicely around
your source code - or being able to actually run/debug your application. I
won't even get into the refactoring pain or having to continuously run
maven
builds while developing code to avoid getting code completion/compile
errors
etc. (I prefer to keep in my IDE where possible).
Compare this whole malarkey with hibernate. You add hibernate to your pom,
generate your project and you're good to go. No messing with your project
build; no messing with some secret ninja IDE stuff to be able to actually
run debug your code while still being able to actually navigate the
source. It just works. Now it might work in a crappy slow way and
openjpa
might be way way more efficient and powerful and whatnot - but I'd rather
have a cheap car that just works than a ferrari that you can only drive on
a
tuesday if its sunny, but not too hot and refuses to even start if its
wet.
FWIW I've just given up using openjpa for development; its just way too
painful. (I'm even hacking projects I work on so I use openjpa in the
maven
build but explicitly switch to hibernate in development mode; yeah its
more
work but at least I can use my IDE properly again).
I'm cool with putting post processing into the build system (though that
should really only be an optimisation); but please can we have some
inefficient but usable reflection/cglib type approach so folks can easily
switch from hibernate to openjpa (and stay there) without
Re: the pain of post processing bytecode (another beg for a simple reflection/cglib alternative like hibernate)
How hard is it to add a reflection/cglib type alternative to the upfront bytecode generation (like hibernate does) to save us from the development-time pain? Not particularly hard. There are a few APIs that would break for some cases, but it's even pretty straightforward to do a subclassing approach for property-based access type without losing much performance -- the only cost in that configuration is with persistent-new instances. -Patrick On 5/17/07, James.Strachan [EMAIL PROTECTED] wrote: Firstly before I start, openjpa is a great piece of software; I'm particularly fond of the documentation and in particular the query language parts. The CSS for the site is also awesome :) However compared to hibernate, openjpa is still pretty painful to use from an end users perspective and I don't think this should be the case; plus I don't think it'll take much time to fix. While the pain is still fresh in my mind I thought I'd post on how much more painful openjpa is to use in a project. If you're short on time, the basic idea is its that bytecode post processing stuff thats to blame :). Yes I know its probably faster that way - its just so painful for Java programmers to work with. (And yes I know one day we'll all have IDE plugins that hide the bytecode stuff etc etc). So the first thing is having to mess with your build (ant or maven) to get the post processing properly integrated. Depending on if you have persistent entities in your main or test area this can often trip you up a little (as it did me). I don't know about folks on this list but the whole idea of having to mess with my maven build gives me the jitters :). When you get that far the maven planets are aligned with openjpa, the next hurdle you hit is how do you run stuff in your IDE. If like me you use IDEA and maven 2, the project gets auto-created by default for all projects you work on. However these don't work when you use openjpa as you hit the dreaded 'cannot function at all as you've not run the up front bytecode post processor you dummy!' type error when trying to run stuff in your IDE. So you then add the maven-generated classes to the front of the classpath in your project. Hooray, after a day or two's work, you can now actually use openjpa in your IDE and your build. YAY! The downside is that now when navigating around your Java code, whenever you navigate into an entity bean, IDEA shows you the bytecode - not the source code as its confused since the bytecode generated stuff is different to the source code it knows about. So now you're faced with a dilemma - choose between navigating nicely around your source code - or being able to actually run/debug your application. I won't even get into the refactoring pain or having to continuously run maven builds while developing code to avoid getting code completion/compile errors etc. (I prefer to keep in my IDE where possible). Compare this whole malarkey with hibernate. You add hibernate to your pom, generate your project and you're good to go. No messing with your project build; no messing with some secret ninja IDE stuff to be able to actually run debug your code while still being able to actually navigate the source. It just works. Now it might work in a crappy slow way and openjpa might be way way more efficient and powerful and whatnot - but I'd rather have a cheap car that just works than a ferrari that you can only drive on a tuesday if its sunny, but not too hot and refuses to even start if its wet. FWIW I've just given up using openjpa for development; its just way too painful. (I'm even hacking projects I work on so I use openjpa in the maven build but explicitly switch to hibernate in development mode; yeah its more work but at least I can use my IDE properly again). I'm cool with putting post processing into the build system (though that should really only be an optimisation); but please can we have some inefficient but usable reflection/cglib type approach so folks can easily switch from hibernate to openjpa (and stay there) without pulling out our hair swearing too much - or sneaking back at the first opportunity to get an easy life? Please don't take this mail the wrong way - I truly want openjpa to be a success, its a great piece of software. Its just a bit too hard to use out of the box right now. I'd truly like it to be trivial to switch from hibernate to openjpa and never have to go back. How hard is it to add a reflection/cglib type alternative to the upfront bytecode generation (like hibernate does) to save us from the development-time pain? -- James --- http://macstrac.blogspot.com/ -- View this message in context: http://www.nabble.com/the-pain-of-post-processing-bytecode-%28another-beg-for-a-simple-reflection-cglib-alternative-like-hibernate%29-tf3770760.html#a10660986 Sent from the open-jpa-dev mailing list archive at Nabble.com. -- Patrick Linskey 202 669 5907
Re: the pain of post processing bytecode (another beg for a simple reflection/cglib alternative like hibernate)
Patrick also mentioned writing an IDEA plug-in (not sure if that's the right
name) that would do the enhancement. I believe he ran into a few snags
getting access to IntelliJ jars. This or something similar might be a good
solution for you. Ideally we'll have Eclipse, IDEA and NetBeans plugins
someday.
I've worked out the snags, actually. Need to figure out how to publish
it now, since it has some dependencies on IDEA jars.
-Patrick
On 5/17/07, Michael Dick [EMAIL PROTECTED] wrote:
Hi James,
I don't know how easy this is to do with IDEA, but what I've done in Eclipse
is to create the project via mvn eclipse:eclipse then create a run
definition for org.apache.openjpa.enhance.PCEnhancer. With no other
classpath tweaking it enhances the entities in the output directory and I'm
up and running.
Another alternative would be to use dynamic enhancement when you run in your
IDE. In eclipse you can just add -javaagent:${path.to.openjpa-xxx.jar} as a
vm argument and you won't have to run the enhancer at all.
Patrick also mentioned writing an IDEA plug-in (not sure if that's the right
name) that would do the enhancement. I believe he ran into a few snags
getting access to IntelliJ jars. This or something similar might be a good
solution for you. Ideally we'll have Eclipse, IDEA and NetBeans plugins
someday.
Eclipse also allows user defined builders to be run in addition to the
default java compiler. The builders can be ant scripts or java programs -
either one should be able to enhance your entities. I have never used IDEA,
but I suspect it includes a similar concept.
All that being said I'm not trying to dismiss your idea of adding a cglib
interface - I'm just sharing what has worked for me and some ideas that
might also work for you. It's a bit specific to Eclipse, but from what I've
heard IDEA is a very good IDE and I suspect it can do them as well.
-Mike
On 5/17/07, James.Strachan [EMAIL PROTECTED] wrote:
Firstly before I start, openjpa is a great piece of software; I'm
particularly fond of the documentation and in particular the query
language
parts. The CSS for the site is also awesome :)
However compared to hibernate, openjpa is still pretty painful to use from
an end users perspective and I don't think this should be the case; plus I
don't think it'll take much time to fix. While the pain is still fresh in
my
mind I thought I'd post on how much more painful openjpa is to use in a
project. If you're short on time, the basic idea is its that bytecode post
processing stuff thats to blame :). Yes I know its probably faster that
way
- its just so painful for Java programmers to work with. (And yes I know
one
day we'll all have IDE plugins that hide the bytecode stuff etc etc).
So the first thing is having to mess with your build (ant or maven) to get
the post processing properly integrated. Depending on if you have
persistent
entities in your main or test area this can often trip you up a little (as
it did me). I don't know about folks on this list but the whole idea of
having to mess with my maven build gives me the jitters :). When you get
that far the maven planets are aligned with openjpa, the next hurdle you
hit is how do you run stuff in your IDE. If like me you use IDEA and maven
2, the project gets auto-created by default for all projects you work on.
However these don't work when you use openjpa as you hit the dreaded
'cannot
function at all as you've not run the up front bytecode post processor you
dummy!' type error when trying to run stuff in your IDE.
So you then add the maven-generated classes to the front of the classpath
in
your project. Hooray, after a day or two's work, you can now actually use
openjpa in your IDE and your build. YAY! The downside is that now when
navigating around your Java code, whenever you navigate into an entity
bean,
IDEA shows you the bytecode - not the source code as its confused since
the
bytecode generated stuff is different to the source code it knows about.
So
now you're faced with a dilemma - choose between navigating nicely around
your source code - or being able to actually run/debug your application. I
won't even get into the refactoring pain or having to continuously run
maven
builds while developing code to avoid getting code completion/compile
errors
etc. (I prefer to keep in my IDE where possible).
Compare this whole malarkey with hibernate. You add hibernate to your pom,
generate your project and you're good to go. No messing with your project
build; no messing with some secret ninja IDE stuff to be able to actually
run debug your code while still being able to actually navigate the
source. It just works. Now it might work in a crappy slow way and
openjpa
might be way way more efficient and powerful and whatnot - but I'd rather
have a cheap car that just works than a ferrari that you can only drive on
a
tuesday if its sunny, but not too hot and refuses to even start if its
wet.
Re: the pain of post processing bytecode (another beg for a simple reflection/cglib alternative like hibernate)
I think this is a very worthwhile project. James and a few others
excoriated me about this issue over beers after JavaOne last week,
and, while the bruises from their rhetorical assault are still
healing, their observations about the comparative out of the box
ease of use OpenJPA compared to other systems definitely bears
attention.
As Patrick mentioned, we aren't too far away from being able to use a
dynamic subclassing approach.
Another option I've been thinking about recently is that in JDK 1.6,
you can dynamically attach an agent at runtime to your own JVM (using
an implementation-specific mechanism), and using the provided
Instrumentation, you can redefine existing methods in classes, even
after the classes have already been loaded. While you cannot add or
remove methods or fields, we might be able to re-work our PCEnhancer
to use a newly-generated inner class and a lookup in some
IdentityHashMap to perform the same function. E.g., instead of our
currently enhanced class:
public class SomeEntity {
private String someField;
private StateManager stateManager; // generated
public String getSomeField() {
return pcgetSomeField(this);
}
// generated method
private static String getSomeField(SomeEntity entity) {
if (entity.stateManager == null)
return entity.someField;
else
entity.stateManager.getField(1, entity);
}
}
we would instead do something like:
public class SomeEntity {
private String someField;
public String getSomeField() {
return GeneratedInnerClass.pcgetSomeField(this);
}
private static class GeneratedInnerClass {
private static String getSomeField(SomeEntity entity) {
StateManager stateManager = GlobalIdentityMap.get(entity);
if (stateManager == null)
return entity.someField;
else
stateManager.getField(1, entity);
}
}
}
From the brief amount of time I've spent thinking about this, I
think we can get 99% of the way there with our current approach.
The remaining 1% is a situation where if someone creates an instance
of SomeEntity *before* we ever initialize the BrokerFactory (and thus
perform the re-definition of known entity classes), we might get
passed an entity instance that isn't persist-able (since you cannot
redfine the methods for an already-created object, only for objects
that will subsequently be created).
In summary, we have 3 different possibilities for removing the
requirement for build-time enhancement and launch-time agent
specification:
1. Use reflection: considerably slower, would require drastic rework
of all our interaction with PersistenceCapable instances, but
wouldn't require any fancy class-generation/enhancement
2. Dynamic subclassing: easier to implement, but would require people
to use property accessors for everything, and wouldn't support
EntityManager.persist(someInstance)
3. Dynamic agent attachment and class re-definition: more difficult
to implement than #2, and would require JDK 1.6 + JVM implementation-
dependent attachment mechanisms, but might provide the most
functionality
Does anyone have any thoughts about this? Especially any new ideas
for other ways to do this would be very interesting for all of us to
hear.
On May 17, 2007, at 8:19 AM, Patrick Linskey wrote:
How hard is it to add a reflection/cglib type alternative to the
upfront
bytecode generation (like hibernate does) to save us from the
development-time pain?
Not particularly hard. There are a few APIs that would break for some
cases, but it's even pretty straightforward to do a subclassing
approach for property-based access type without losing much
performance -- the only cost in that configuration is with
persistent-new instances.
-Patrick
On 5/17/07, James.Strachan [EMAIL PROTECTED] wrote:
Firstly before I start, openjpa is a great piece of software; I'm
particularly fond of the documentation and in particular the query
language
parts. The CSS for the site is also awesome :)
However compared to hibernate, openjpa is still pretty painful to
use from
an end users perspective and I don't think this should be the
case; plus I
don't think it'll take much time to fix. While the pain is still
fresh in my
mind I thought I'd post on how much more painful openjpa is to use
in a
project. If you're short on time, the basic idea is its that
bytecode post
processing stuff thats to blame :). Yes I know its probably faster
that way
- its just so painful for Java programmers to work with. (And yes
I know one
day we'll all have IDE plugins that hide the bytecode stuff etc etc).
So the first thing is having to mess with your build (ant or
maven) to get
the post processing properly integrated. Depending on if you have
persistent
entities in your main or test area this can often trip you up a
little (as
it did me). I don't know about folks on this list but the whole
idea of
having to mess
Re: the pain of post processing bytecode (another beg for a simple reflection/cglib alternative like hibernate)
James, Could extract from this verbiage the scenarios you'd like supported? Do you need to run tests inside IDEA and have you classes enhanced after IDEA compiles them for you? Do you need to run in a separate jvm, e.g. from maven, and have the classes enhanced as they are loaded? I think the second of these can probably be made to work without any openjpa code changes by doing the same thing geronimo does, running with an enhancer agent that delegates to the openjpa enhancer as appropriate. I'd imagine that if IDEA creates a new classloader for running the tests, and we can get some access to something about it, it ought to be possible to do on the fly enhancement there also. What exactly are the problems with looking at an enhanced class in IDEA? I haven't run into thembut I may not have been trying to debug the enhanced classes but rather openjpa + geronimo. thanks david jencks On May 17, 2007, at 2:39 AM, James.Strachan wrote: Firstly before I start, openjpa is a great piece of software; I'm particularly fond of the documentation and in particular the query language parts. The CSS for the site is also awesome :) However compared to hibernate, openjpa is still pretty painful to use from an end users perspective and I don't think this should be the case; plus I don't think it'll take much time to fix. While the pain is still fresh in my mind I thought I'd post on how much more painful openjpa is to use in a project. If you're short on time, the basic idea is its that bytecode post processing stuff thats to blame :). Yes I know its probably faster that way - its just so painful for Java programmers to work with. (And yes I know one day we'll all have IDE plugins that hide the bytecode stuff etc etc). So the first thing is having to mess with your build (ant or maven) to get the post processing properly integrated. Depending on if you have persistent entities in your main or test area this can often trip you up a little (as it did me). I don't know about folks on this list but the whole idea of having to mess with my maven build gives me the jitters :). When you get that far the maven planets are aligned with openjpa, the next hurdle you hit is how do you run stuff in your IDE. If like me you use IDEA and maven 2, the project gets auto-created by default for all projects you work on. However these don't work when you use openjpa as you hit the dreaded 'cannot function at all as you've not run the up front bytecode post processor you dummy!' type error when trying to run stuff in your IDE. So you then add the maven-generated classes to the front of the classpath in your project. Hooray, after a day or two's work, you can now actually use openjpa in your IDE and your build. YAY! The downside is that now when navigating around your Java code, whenever you navigate into an entity bean, IDEA shows you the bytecode - not the source code as its confused since the bytecode generated stuff is different to the source code it knows about. So now you're faced with a dilemma - choose between navigating nicely around your source code - or being able to actually run/debug your application. I won't even get into the refactoring pain or having to continuously run maven builds while developing code to avoid getting code completion/ compile errors etc. (I prefer to keep in my IDE where possible). Compare this whole malarkey with hibernate. You add hibernate to your pom, generate your project and you're good to go. No messing with your project build; no messing with some secret ninja IDE stuff to be able to actually run debug your code while still being able to actually navigate the source. It just works. Now it might work in a crappy slow way and openjpa might be way way more efficient and powerful and whatnot - but I'd rather have a cheap car that just works than a ferrari that you can only drive on a tuesday if its sunny, but not too hot and refuses to even start if its wet. FWIW I've just given up using openjpa for development; its just way too painful. (I'm even hacking projects I work on so I use openjpa in the maven build but explicitly switch to hibernate in development mode; yeah its more work but at least I can use my IDE properly again). I'm cool with putting post processing into the build system (though that should really only be an optimisation); but please can we have some inefficient but usable reflection/cglib type approach so folks can easily switch from hibernate to openjpa (and stay there) without pulling out our hair swearing too much - or sneaking back at the first opportunity to get an easy life? Please don't take this mail the wrong way - I truly want openjpa to be a success, its a great piece of software. Its just a bit too hard to use out of the box right now. I'd truly like it to be trivial to switch from hibernate to openjpa and never have to go back.
Re: the pain of post processing bytecode (another beg for a simple reflection/cglib alternative like hibernate)
I think that the issues raised are best solved with tools,
documentation, and examples.
Of course, if one has been coding to Hibernate for years, it's unlikely
that any combination of tools, documentation, and examples will make
OpenJPA easier to use for that person, but that's not the standard.
Another important point, in my view, is to make sure the tests run as
well on Windows (without cygwin!) as they do on Linux, Unix, and OS/X.
For example, using File.separator to construct resource path names works
great on everything but Windows.
David
Marc Prud'hommeaux wrote:
I think this is a very worthwhile project. James and a few others
excoriated me about this issue over beers after JavaOne last week, and,
while the bruises from their rhetorical assault are still healing, their
observations about the comparative out of the box ease of use OpenJPA
compared to other systems definitely bears attention.
As Patrick mentioned, we aren't too far away from being able to use a
dynamic subclassing approach.
Another option I've been thinking about recently is that in JDK 1.6, you
can dynamically attach an agent at runtime to your own JVM (using an
implementation-specific mechanism), and using the provided
Instrumentation, you can redefine existing methods in classes, even
after the classes have already been loaded. While you cannot add or
remove methods or fields, we might be able to re-work our PCEnhancer to
use a newly-generated inner class and a lookup in some IdentityHashMap
to perform the same function. E.g., instead of our currently enhanced
class:
public class SomeEntity {
private String someField;
private StateManager stateManager; // generated
public String getSomeField() {
return pcgetSomeField(this);
}
// generated method
private static String getSomeField(SomeEntity entity) {
if (entity.stateManager == null)
return entity.someField;
else
entity.stateManager.getField(1, entity);
}
}
we would instead do something like:
public class SomeEntity {
private String someField;
public String getSomeField() {
return GeneratedInnerClass.pcgetSomeField(this);
}
private static class GeneratedInnerClass {
private static String getSomeField(SomeEntity entity) {
StateManager stateManager = GlobalIdentityMap.get(entity);
if (stateManager == null)
return entity.someField;
else
stateManager.getField(1, entity);
}
}
}
From the brief amount of time I've spent thinking about this, I think
we can get 99% of the way there with our current approach.
The remaining 1% is a situation where if someone creates an instance of
SomeEntity *before* we ever initialize the BrokerFactory (and thus
perform the re-definition of known entity classes), we might get passed
an entity instance that isn't persist-able (since you cannot redfine the
methods for an already-created object, only for objects that will
subsequently be created).
In summary, we have 3 different possibilities for removing the
requirement for build-time enhancement and launch-time agent specification:
1. Use reflection: considerably slower, would require drastic rework of
all our interaction with PersistenceCapable instances, but wouldn't
require any fancy class-generation/enhancement
2. Dynamic subclassing: easier to implement, but would require people to
use property accessors for everything, and wouldn't support
EntityManager.persist(someInstance)
3. Dynamic agent attachment and class re-definition: more difficult to
implement than #2, and would require JDK 1.6 + JVM
implementation-dependent attachment mechanisms, but might provide the
most functionality
Does anyone have any thoughts about this? Especially any new ideas for
other ways to do this would be very interesting for all of us to hear.
On May 17, 2007, at 8:19 AM, Patrick Linskey wrote:
How hard is it to add a reflection/cglib type alternative to the upfront
bytecode generation (like hibernate does) to save us from the
development-time pain?
Not particularly hard. There are a few APIs that would break for some
cases, but it's even pretty straightforward to do a subclassing
approach for property-based access type without losing much
performance -- the only cost in that configuration is with
persistent-new instances.
-Patrick
On 5/17/07, James.Strachan [EMAIL PROTECTED] wrote:
Firstly before I start, openjpa is a great piece of software; I'm
particularly fond of the documentation and in particular the query
language
parts. The CSS for the site is also awesome :)
However compared to hibernate, openjpa is still pretty painful to use
from
an end users perspective and I don't think this should be the case;
plus I
don't think it'll take much time to fix. While the pain is still
fresh in my
mind I thought I'd post on how much more painful
