You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Sergey Beryozkin <sb...@gmail.com> on 2016/04/18 18:53:49 UTC
[OT] How to update the existing jar with Maven and then depend on it
Hi
I thought I'd ask at the users list first, sorry for the noise.
I have the following task: make sure that a CXF OAuth2 model
(cxf-rt-rs-security-oauth2 module) can be persisted with JPA. Right now
the tests are running and use Hibernate, but also can be switched to use
OpenJPA. The problem with the latter is that OpenJPA does enhance the
model classes at the build time with OpenJPA specific interfaces thus
leading to a model having a strong OpenJPA dependency.
This is problematic because I'm aware 3rd party users use Ehcache (and
possibly other similar libraries), and some other users will want to use
Hibernate.
Now, as far as my own practical requirement is concerned, this model
needs to be JPA persisted with OpenJPA. So I've spent a lot of time by
experimenting with the load time weaving with Spring ORM, which does not
seem to be stable or reliable, and while I accept it might work it does
not seem the right way to go for me. Using OpenJPA -javaagent is also
very messy.
So I think that leaves me with doing one of the following, when building
a (war) module:
- unpack cxf-rt-rs-security-oauth2 into a Maven build directory/oauth2,
then run Open JPA enhancer on the model classes, then pack it back into
a local_cxf-rt-rs-security-oauth2 and finally have the project build
depending on this locally built artifact.
Or, first, build 'cxf-rt-rs-security-oauth2_openjpa'
- unpack cxf-rt-rs-security-oauth2 into a Maven build directory, then
run Open JPA enhancer on the model classes, then use those locally
enhanced classes to build cxf-rt-rs-security-oauth2_openjpa. And then
have a war project simply depend on cxf-rt-rs-security-oauth2_openjpa.
This is somewhat messy but is clean nonetheless as far as restricting
OpenJPA Enhance dependencies to the project which is fine with them.
Does someone know if either of the above options is doable with Maven,
I'm pretty sure it is but it would seem to require some black magic to
do it right. If someone knows - please contact me privately to continue
the conversation.
Thanks, Sergey
Re: [OT] How to update the existing jar with Maven and then depend on it
Posted by "Vjacheslav V. Borisov" <sl...@gmail.com>.
2016-04-23 0:00 GMT+04:00 Sergey Beryozkin <sb...@gmail.com>:
>
> Thanks, well, I was not planning to spend any more time on LTW, but I
> decided to give it a go again, and after spending a lot of time debugging
> through TomcatInstrumentableClassLoader and OpenJPA it proved
> TomcatInstrumentableClassLoader was actually interfering with LTW.
> Or more specifically, @Entity were loaded by this CL while the entity
> classes - by Tomcat WebAppLoader. Perhaps having an orm.xml would work, but
> as it happens Tomcat 7/64 WebAppLoader is capable of keeping the
> transformers itself now.
> Removing TomcatInstrumentableClassLoader made it work for me, though
> earlier on it was not but during the last try I refactored the application
> context a bit to import the entity related beans. I also updated the module
> to ship a static model based on Romain's tip.
>
I think orm.xml JPA configuration is more "clean" than annotations and
gives more flexibility, becouse different mapping files could be plugged in
persistance unit configuration.
And LTW I am also see as more "clean" than static weaving, since it is
implementation-free.
That's just my opinion, suitable for my use cases.
> This is all truly off-topic :-) but I'm detailing it all to highlight that
> the element of the 'black-magic' is still there, but I do have more
> confidence now in LTW...
>
>
Well, if we talking about JPA in terms of JAX-RS backend, I think this is
not-so-offtopic here
Re: [OT] How to update the existing jar with Maven and then depend on
it
Posted by Sergey Beryozkin <sb...@gmail.com>.
On 19/04/16 06:14, Vjacheslav V. Borisov wrote:
> 2016-04-18 20:53 GMT+04:00 Sergey Beryozkin <sb...@gmail.com>:
>
>>
>> Now, as far as my own practical requirement is concerned, this model needs
>> to be JPA persisted with OpenJPA. So I've spent a lot of time by
>> experimenting with the load time weaving with Spring ORM, which does not
>> seem to be stable or reliable, and while I accept it might work it does not
>> seem the right way to go for me. Using OpenJPA -javaagent is also very
>> messy.
>>
>
> We are using Load-time-weaving with spring and eclipselink in production,
> and LTW looks like stable,
> we are using
> org.springframework.instrument.classloading.tomcat.TomcatInstrumentableClassLoader
>
>
> And LTW is useful in many other cases, eg. @Transactional, @Cacheble can
> use LTW (aspectj), which is more useful that default proxy mode, which has
> limitation, that works only when calling from outer class.
>
Thanks, well, I was not planning to spend any more time on LTW, but I
decided to give it a go again, and after spending a lot of time
debugging through TomcatInstrumentableClassLoader and OpenJPA it proved
TomcatInstrumentableClassLoader was actually interfering with LTW.
Or more specifically, @Entity were loaded by this CL while the entity
classes - by Tomcat WebAppLoader. Perhaps having an orm.xml would work,
but as it happens Tomcat 7/64 WebAppLoader is capable of keeping the
transformers itself now.
Removing TomcatInstrumentableClassLoader made it work for me, though
earlier on it was not but during the last try I refactored the
application context a bit to import the entity related beans. I also
updated the module to ship a static model based on Romain's tip.
This is all truly off-topic :-) but I'm detailing it all to highlight
that the element of the 'black-magic' is still there, but I do have
more confidence now in LTW...
Sergey
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Re: [OT] How to update the existing jar with Maven and then depend on it
Posted by "Vjacheslav V. Borisov" <sl...@gmail.com>.
2016-04-18 20:53 GMT+04:00 Sergey Beryozkin <sb...@gmail.com>:
>
> Now, as far as my own practical requirement is concerned, this model needs
> to be JPA persisted with OpenJPA. So I've spent a lot of time by
> experimenting with the load time weaving with Spring ORM, which does not
> seem to be stable or reliable, and while I accept it might work it does not
> seem the right way to go for me. Using OpenJPA -javaagent is also very
> messy.
>
We are using Load-time-weaving with spring and eclipselink in production,
and LTW looks like stable,
we are using
org.springframework.instrument.classloading.tomcat.TomcatInstrumentableClassLoader
And LTW is useful in many other cases, eg. @Transactional, @Cacheble can
use LTW (aspectj), which is more useful that default proxy mode, which has
limitation, that works only when calling from outer class.
Re: [OT] How to update the existing jar with Maven and then depend on
it
Posted by Francesco Chicchiriccò <il...@apache.org>.
Hi Sergey,
I have some experience with OpenJPA / Spring ORM / etc from Syncope, and
also about Hibernate, since we had to migrate from the latter to the
former when we joined the ASF.
See my replies embedded below.
Regards.
On 18/04/2016 18:53, Sergey Beryozkin wrote:
> Hi
>
> I thought I'd ask at the users list first, sorry for the noise.
>
> I have the following task: make sure that a CXF OAuth2 model
> (cxf-rt-rs-security-oauth2 module) can be persisted with JPA. Right
> now the tests are running and use Hibernate, but also can be switched
> to use OpenJPA. The problem with the latter is that OpenJPA does
> enhance the model classes at the build time with OpenJPA specific
> interfaces thus leading to a model having a strong OpenJPA dependency.
>
> This is problematic because I'm aware 3rd party users use Ehcache (and
> possibly other similar libraries), and some other users will want to
> use Hibernate.
>
> Now, as far as my own practical requirement is concerned, this model
> needs to be JPA persisted with OpenJPA. So I've spent a lot of time by
> experimenting with the load time weaving with Spring ORM, which does
> not seem to be stable or reliable, and while I accept it might work it
> does not seem the right way to go for me. Using OpenJPA -javaagent is
> also very messy.
Can you please elaborate on the reasons why you see OpenJPA runtime
enhancement via -javaagent as messy?
https://ci.apache.org/projects/openjpa/trunk/docbook/manual.html#ref_guide_pc_enhance_runtime
> So I think that leaves me with doing one of the following, when
> building a (war) module:
>
> - unpack cxf-rt-rs-security-oauth2 into a Maven build
> directory/oauth2, then run Open JPA enhancer on the model classes,
> then pack it back into a local_cxf-rt-rs-security-oauth2 and finally
> have the project build depending on this locally built artifact.
>
> Or, first, build 'cxf-rt-rs-security-oauth2_openjpa'
>
> - unpack cxf-rt-rs-security-oauth2 into a Maven build directory, then
> run Open JPA enhancer on the model classes, then use those locally
> enhanced classes to build cxf-rt-rs-security-oauth2_openjpa. And then
> have a war project simply depend on cxf-rt-rs-security-oauth2_openjpa.
>
> This is somewhat messy but is clean nonetheless as far as restricting
> OpenJPA Enhance dependencies to the project which is fine with them.
>
> Does someone know if either of the above options is doable with Maven,
> I'm pretty sure it is but it would seem to require some black magic to
> do it right. If someone knows - please contact me privately to
> continue the conversation.
I think both options above can be accomplished via Maven - with some
help by the ant-plugin - but do you believe it might be possible to
split the JPA artifact into two separate artifacts (jpa-api and
jpa-openjpa)? The former will only depend on JPA 2.0 specs, while the
latter will depend on OpenJPA and perform the build-time enhancement.
Then you might also provide instructions on the wiki about how to
produce jpa-hibernate (or jpa-eclipselink) in order to replace jpa-openjpa.
WDYT?
--
Francesco Chicchiriccò
Tirasa - Open Source Excellence
http://www.tirasa.net/
Involved at The Apache Software Foundation:
member, Syncope PMC chair, Cocoon PMC, Olingo PMC, CXF committer
http://home.apache.org/~ilgrosso/