You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@tomee.apache.org by Jonathan Gallimore <jo...@gmail.com> on 2018/11/28 11:50:49 UTC

CMP/JPA mapping not accounting for in persistence.xml

Hi

This continues on from the work that Otavio did on this thread: "Creates an
unmarshal that does not filter to JavaEE namespace".

For those of you who aren't aware, TomEE supports CMP entity beans (which
is quite an old way of doing persistence - it dates back to the EJB 2.1 era
- and possibly earlier, I started using EJB around 2.1), and it does this
by converting them to JPA entities on the fly and creating an ORM mapping
file in XML for the persistence provider to use. It uses a special
persistence unit called "cmp".

One of the nice things you can do is use
the openejb.descriptors.output=true system property, and you'll get the
persistence.xml and orm.xml file that was generated at deploy time.
Unfortunately, if you try and customize the ORM xml, and provide both the
persistence xml and ORM xml files in your app, using the <mapping-file> tag
in persistence.xml (something like the example below), it doesn't work, and
the auto generated mappings are still used instead.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<persistence xmlns="http://java.sun.com/xml/ns/persistence" version="2.0">
    <persistence-unit name="cmp" transaction-type="JTA">
        <jta-data-source>jta-ds</jta-data-source>
        <non-jta-data-source>non-jta-ds</non-jta-data-source>
        <mapping-file>META-INF/openejb-cmp-generated-orm.xml</mapping-file>
        <class>...</class>
        ...
        <exclude-unlisted-classes>true</exclude-unlisted-classes>
    </persistence-unit>
</persistence>

I've reproduced this in a test, and am working on a fix. Doesn't look like
it'll be too hard. https://issues.apache.org/jira/browse/TOMEE-2295 is the
JIRA, and I'll post a PR here for review and discussion when I'm done.

Cheers

Jon

Re: CMP/JPA mapping not accounting for in persistence.xml

Posted by Otávio Gonçalves de Santana <os...@tomitribe.com>.

The second PR: https://github.com/apache/tomee/pull/285

On Mon, Dec 17, 2018 at 10:21 AM Bruno Baptista <br...@gmail.com> wrote:

> Great! Thanks!
>
> Bruno Baptista
> https://twitter.com/brunobat_
>
>
> On 17/12/18 12:19, Otávio Gonçalves de Santana wrote:
> > Thank you Bruno, I created a PR to fix missing header
> >
> > On Mon, Dec 17, 2018 at 9:46 AM Otávio Gonçalves de Santana <
> > osantana@tomitribe.com> wrote:
> >
> >> Hello, I created the backport to version 7.0.x:
> >> https://github.com/apache/tomee/pull/283
> >>
> >> On Wed, Dec 5, 2018 at 4:21 PM Gurkan Erdogdu <cg...@gmail.com>
> wrote:
> >>
> >>> For the ORB case, there are places where ORB class is imported
> >>> (openejb-core and openejb-client). For java 11, this will probably not
> >>> compile and needs to have some 3th party Jar. For CMP case, as you have
> >>> already experienced, the codebase is very complicated and it is really
> old
> >>> technology and has not been updated since years. Therefore, it is a
> good
> >>> idea to declare it  as --deprecated-- and remove it from the future
> 8.1.x
> >>> or 9.0.x versions.
> >>> Regards.
> >>> Gurkan
> >>>
> >>>
> >>> On Wed, Dec 5, 2018 at 8:33 PM Jonathan Gallimore <
> >>> jonathan.gallimore@gmail.com> wrote:
> >>>
> >>>> Thanks for the background David, that's much appreciated.
> >>>>
> >>>> I agree about the webapp. Our last CVE was due to an XSS issue in that
> >>>> webapp - I'd be inclined to remove it as well. Our Arquillian test
> suite
> >>>> tests all the distros *and* has a couple of phases doing an install
> with
> >>>> the webapp, so losing the webapp could shorten the build a bit too.
> >>>>
> >>>> Back on the CMP changes, my Arquillian test is now working, and I'm
> >>> quite
> >>>> happy with the change itself. If there's no objections, I'll merge
> this
> >>> in
> >>>> tomorrow. I'll do some documentation and check some more stuff out
> with
> >>>> this functionality after that merge.
> >>>>
> >>>> Thanks
> >>>>
> >>>> Jon
> >>>>
> >>>> On Wed, Dec 5, 2018 at 1:09 AM David Blevins <david.blevins@gmail.com
> >
> >>>> wrote:
> >>>>
> >>>>>> On Dec 4, 2018, at 4:08 PM, Jonathan Gallimore <
> >>>>> jonathan.gallimore@gmail.com> wrote:
> >>>>>> I don't know that we have stuff that is deprecated pending removal
> >>> at
> >>>> the
> >>>>>> moment. In terms of removing the CMP/BMP stuff... well, people are
> >>>> using
> >>>>>> it, which is why I'm working on it :-). I would be ok with marking
> >>> it
> >>>> as
> >>>>>> deprecated, as long as we print out an explicit warning if your
> >>>>> application
> >>>>>> is using it, so you know to migrate. In terms of the gain... I don't
> >>>>> know.
> >>>>>> There'd be less code, but I suspect still the same dependencies, so
> >>>> we'd
> >>>>> be
> >>>>>> removing a small part of openejb-core effectively. I think its a
> >>> good
> >>>>>> discussion, but I'd prefer to see graceful deprecation with clear
> >>>>> warnings
> >>>>>> before removal.
> >>>>> Contextual information on the CMP implementation.  We actually had a
> >>>>> separate CMP implementation in OpenEJB 2.0 that was working and
> passed
> >>>> the
> >>>>> TCK and used to certify Geronimo for J2EE 1.5.
> >>>>>
> >>>>> When JPA was added in EJB 3.0 / Java EE 5, we made a deliberate
> >>> decision
> >>>>> to throw out all of that code and write a new CMP implementation in
> >>>> OpenEJB
> >>>>> 3.0 on top of JPA to protect ourselves in the future from the
> >>> inevitable
> >>>>> cost of CMP legacy.  What we have is actually a very thin layer on
> >>> top of
> >>>>> JPA, which I think provides people more value than cost.
> >>>>>
> >>>>> If someone is still stuck on CMP, our implementation is the best in
> >>> the
> >>>>> industry in terms of helping you migrate to JPA, because it *is* JPA
> >>> and
> >>>>> you can freely mix the two and even have them backed by the same
> >>>>> persistence unit.
> >>>>>
> >>>>> There is no code in TomEE/OpenEJB that implements Corba or JAX-RPC.
> >>> All
> >>>>> the Corba and ORB related code stayed in Geronimo as we didn't want
> it
> >>>>> OpenEJB 3.0 because even for 2006 it would have been instant legacy.
> >>>> Same
> >>>>> with JAX-RPC which would have brought in at least 10BM in
> >>> dependencies.
> >>>>> If we hadn't completely rewritten OpenEJB between 2 and 3 I suspect
> we
> >>>>> would have good candidates for the chopping block.
> >>>>>
> >>>>> One thing I think is a great candidate for the chopping block is the
> >>>>> "tomee-webapp" used to bootstrap our Tomcat integration for people
> >>> who do
> >>>>> not have the ability to just use an already built TomEE dis.  I don't
> >>>> think
> >>>>> it ever took off.  I'm not aware of anyone using it.  Removing it
> >>> would
> >>>>> allow us to drop binaries from our release process.  We could
> optimize
> >>>> our
> >>>>> Tomcat integration because there are quirky things we do only for the
> >>>>> benefit of that unused webapp.
> >>>>>
> >>>>> Rather than use that quirky webapp, we could simply build our TomEE
> >>>>> distros using the TomEE Maven Plugin.  It's there to help others
> build
> >>>>> their own TomEE distros, but we don't use it only because of the
> >>>>> tomee-webapp legacy.  We chose to use the tomee-webapp to "eat our
> own
> >>>>> dogfood", but we should probably switch the dog food to the TomEE
> >>> Maven
> >>>>> Plugin.
> >>>>>
> >>>>>
> >>>>> -David
> >>>>>
> >>>>>
> >>>>>
>

Re: CMP/JPA mapping not accounting for in persistence.xml

Posted by Bruno Baptista <br...@gmail.com>.

Great! Thanks!

Bruno Baptista
https://twitter.com/brunobat_


On 17/12/18 12:19, Otávio Gonçalves de Santana wrote:
> Thank you Bruno, I created a PR to fix missing header
>
> On Mon, Dec 17, 2018 at 9:46 AM Otávio Gonçalves de Santana <
> osantana@tomitribe.com> wrote:
>
>> Hello, I created the backport to version 7.0.x:
>> https://github.com/apache/tomee/pull/283
>>
>> On Wed, Dec 5, 2018 at 4:21 PM Gurkan Erdogdu <cg...@gmail.com> wrote:
>>
>>> For the ORB case, there are places where ORB class is imported
>>> (openejb-core and openejb-client). For java 11, this will probably not
>>> compile and needs to have some 3th party Jar. For CMP case, as you have
>>> already experienced, the codebase is very complicated and it is really old
>>> technology and has not been updated since years. Therefore, it is a good
>>> idea to declare it  as --deprecated-- and remove it from the future 8.1.x
>>> or 9.0.x versions.
>>> Regards.
>>> Gurkan
>>>
>>>
>>> On Wed, Dec 5, 2018 at 8:33 PM Jonathan Gallimore <
>>> jonathan.gallimore@gmail.com> wrote:
>>>
>>>> Thanks for the background David, that's much appreciated.
>>>>
>>>> I agree about the webapp. Our last CVE was due to an XSS issue in that
>>>> webapp - I'd be inclined to remove it as well. Our Arquillian test suite
>>>> tests all the distros *and* has a couple of phases doing an install with
>>>> the webapp, so losing the webapp could shorten the build a bit too.
>>>>
>>>> Back on the CMP changes, my Arquillian test is now working, and I'm
>>> quite
>>>> happy with the change itself. If there's no objections, I'll merge this
>>> in
>>>> tomorrow. I'll do some documentation and check some more stuff out with
>>>> this functionality after that merge.
>>>>
>>>> Thanks
>>>>
>>>> Jon
>>>>
>>>> On Wed, Dec 5, 2018 at 1:09 AM David Blevins <da...@gmail.com>
>>>> wrote:
>>>>
>>>>>> On Dec 4, 2018, at 4:08 PM, Jonathan Gallimore <
>>>>> jonathan.gallimore@gmail.com> wrote:
>>>>>> I don't know that we have stuff that is deprecated pending removal
>>> at
>>>> the
>>>>>> moment. In terms of removing the CMP/BMP stuff... well, people are
>>>> using
>>>>>> it, which is why I'm working on it :-). I would be ok with marking
>>> it
>>>> as
>>>>>> deprecated, as long as we print out an explicit warning if your
>>>>> application
>>>>>> is using it, so you know to migrate. In terms of the gain... I don't
>>>>> know.
>>>>>> There'd be less code, but I suspect still the same dependencies, so
>>>> we'd
>>>>> be
>>>>>> removing a small part of openejb-core effectively. I think its a
>>> good
>>>>>> discussion, but I'd prefer to see graceful deprecation with clear
>>>>> warnings
>>>>>> before removal.
>>>>> Contextual information on the CMP implementation.  We actually had a
>>>>> separate CMP implementation in OpenEJB 2.0 that was working and passed
>>>> the
>>>>> TCK and used to certify Geronimo for J2EE 1.5.
>>>>>
>>>>> When JPA was added in EJB 3.0 / Java EE 5, we made a deliberate
>>> decision
>>>>> to throw out all of that code and write a new CMP implementation in
>>>> OpenEJB
>>>>> 3.0 on top of JPA to protect ourselves in the future from the
>>> inevitable
>>>>> cost of CMP legacy.  What we have is actually a very thin layer on
>>> top of
>>>>> JPA, which I think provides people more value than cost.
>>>>>
>>>>> If someone is still stuck on CMP, our implementation is the best in
>>> the
>>>>> industry in terms of helping you migrate to JPA, because it *is* JPA
>>> and
>>>>> you can freely mix the two and even have them backed by the same
>>>>> persistence unit.
>>>>>
>>>>> There is no code in TomEE/OpenEJB that implements Corba or JAX-RPC.
>>> All
>>>>> the Corba and ORB related code stayed in Geronimo as we didn't want it
>>>>> OpenEJB 3.0 because even for 2006 it would have been instant legacy.
>>>> Same
>>>>> with JAX-RPC which would have brought in at least 10BM in
>>> dependencies.
>>>>> If we hadn't completely rewritten OpenEJB between 2 and 3 I suspect we
>>>>> would have good candidates for the chopping block.
>>>>>
>>>>> One thing I think is a great candidate for the chopping block is the
>>>>> "tomee-webapp" used to bootstrap our Tomcat integration for people
>>> who do
>>>>> not have the ability to just use an already built TomEE dis.  I don't
>>>> think
>>>>> it ever took off.  I'm not aware of anyone using it.  Removing it
>>> would
>>>>> allow us to drop binaries from our release process.  We could optimize
>>>> our
>>>>> Tomcat integration because there are quirky things we do only for the
>>>>> benefit of that unused webapp.
>>>>>
>>>>> Rather than use that quirky webapp, we could simply build our TomEE
>>>>> distros using the TomEE Maven Plugin.  It's there to help others build
>>>>> their own TomEE distros, but we don't use it only because of the
>>>>> tomee-webapp legacy.  We chose to use the tomee-webapp to "eat our own
>>>>> dogfood", but we should probably switch the dog food to the TomEE
>>> Maven
>>>>> Plugin.
>>>>>
>>>>>
>>>>> -David
>>>>>
>>>>>
>>>>>

Re: CMP/JPA mapping not accounting for in persistence.xml

Posted by Otávio Gonçalves de Santana <os...@tomitribe.com>.

Thank you Bruno, I created a PR to fix missing header

On Mon, Dec 17, 2018 at 9:46 AM Otávio Gonçalves de Santana <
osantana@tomitribe.com> wrote:

> Hello, I created the backport to version 7.0.x:
> https://github.com/apache/tomee/pull/283
>
> On Wed, Dec 5, 2018 at 4:21 PM Gurkan Erdogdu <cg...@gmail.com> wrote:
>
>> For the ORB case, there are places where ORB class is imported
>> (openejb-core and openejb-client). For java 11, this will probably not
>> compile and needs to have some 3th party Jar. For CMP case, as you have
>> already experienced, the codebase is very complicated and it is really old
>> technology and has not been updated since years. Therefore, it is a good
>> idea to declare it  as --deprecated-- and remove it from the future 8.1.x
>> or 9.0.x versions.
>> Regards.
>> Gurkan
>>
>>
>> On Wed, Dec 5, 2018 at 8:33 PM Jonathan Gallimore <
>> jonathan.gallimore@gmail.com> wrote:
>>
>> > Thanks for the background David, that's much appreciated.
>> >
>> > I agree about the webapp. Our last CVE was due to an XSS issue in that
>> > webapp - I'd be inclined to remove it as well. Our Arquillian test suite
>> > tests all the distros *and* has a couple of phases doing an install with
>> > the webapp, so losing the webapp could shorten the build a bit too.
>> >
>> > Back on the CMP changes, my Arquillian test is now working, and I'm
>> quite
>> > happy with the change itself. If there's no objections, I'll merge this
>> in
>> > tomorrow. I'll do some documentation and check some more stuff out with
>> > this functionality after that merge.
>> >
>> > Thanks
>> >
>> > Jon
>> >
>> > On Wed, Dec 5, 2018 at 1:09 AM David Blevins <da...@gmail.com>
>> > wrote:
>> >
>> > > > On Dec 4, 2018, at 4:08 PM, Jonathan Gallimore <
>> > > jonathan.gallimore@gmail.com> wrote:
>> > > >
>> > > > I don't know that we have stuff that is deprecated pending removal
>> at
>> > the
>> > > > moment. In terms of removing the CMP/BMP stuff... well, people are
>> > using
>> > > > it, which is why I'm working on it :-). I would be ok with marking
>> it
>> > as
>> > > > deprecated, as long as we print out an explicit warning if your
>> > > application
>> > > > is using it, so you know to migrate. In terms of the gain... I don't
>> > > know.
>> > > > There'd be less code, but I suspect still the same dependencies, so
>> > we'd
>> > > be
>> > > > removing a small part of openejb-core effectively. I think its a
>> good
>> > > > discussion, but I'd prefer to see graceful deprecation with clear
>> > > warnings
>> > > > before removal.
>> > >
>> > > Contextual information on the CMP implementation.  We actually had a
>> > > separate CMP implementation in OpenEJB 2.0 that was working and passed
>> > the
>> > > TCK and used to certify Geronimo for J2EE 1.5.
>> > >
>> > > When JPA was added in EJB 3.0 / Java EE 5, we made a deliberate
>> decision
>> > > to throw out all of that code and write a new CMP implementation in
>> > OpenEJB
>> > > 3.0 on top of JPA to protect ourselves in the future from the
>> inevitable
>> > > cost of CMP legacy.  What we have is actually a very thin layer on
>> top of
>> > > JPA, which I think provides people more value than cost.
>> > >
>> > > If someone is still stuck on CMP, our implementation is the best in
>> the
>> > > industry in terms of helping you migrate to JPA, because it *is* JPA
>> and
>> > > you can freely mix the two and even have them backed by the same
>> > > persistence unit.
>> > >
>> > > There is no code in TomEE/OpenEJB that implements Corba or JAX-RPC.
>> All
>> > > the Corba and ORB related code stayed in Geronimo as we didn't want it
>> > > OpenEJB 3.0 because even for 2006 it would have been instant legacy.
>> > Same
>> > > with JAX-RPC which would have brought in at least 10BM in
>> dependencies.
>> > >
>> > > If we hadn't completely rewritten OpenEJB between 2 and 3 I suspect we
>> > > would have good candidates for the chopping block.
>> > >
>> > > One thing I think is a great candidate for the chopping block is the
>> > > "tomee-webapp" used to bootstrap our Tomcat integration for people
>> who do
>> > > not have the ability to just use an already built TomEE dis.  I don't
>> > think
>> > > it ever took off.  I'm not aware of anyone using it.  Removing it
>> would
>> > > allow us to drop binaries from our release process.  We could optimize
>> > our
>> > > Tomcat integration because there are quirky things we do only for the
>> > > benefit of that unused webapp.
>> > >
>> > > Rather than use that quirky webapp, we could simply build our TomEE
>> > > distros using the TomEE Maven Plugin.  It's there to help others build
>> > > their own TomEE distros, but we don't use it only because of the
>> > > tomee-webapp legacy.  We chose to use the tomee-webapp to "eat our own
>> > > dogfood", but we should probably switch the dog food to the TomEE
>> Maven
>> > > Plugin.
>> > >
>> > >
>> > > -David
>> > >
>> > >
>> > >
>> >
>>
>

Re: CMP/JPA mapping not accounting for in persistence.xml

Posted by Otávio Gonçalves de Santana <os...@tomitribe.com>.

Hello, I created the backport to version 7.0.x:
https://github.com/apache/tomee/pull/283

On Wed, Dec 5, 2018 at 4:21 PM Gurkan Erdogdu <cg...@gmail.com> wrote:

> For the ORB case, there are places where ORB class is imported
> (openejb-core and openejb-client). For java 11, this will probably not
> compile and needs to have some 3th party Jar. For CMP case, as you have
> already experienced, the codebase is very complicated and it is really old
> technology and has not been updated since years. Therefore, it is a good
> idea to declare it  as --deprecated-- and remove it from the future 8.1.x
> or 9.0.x versions.
> Regards.
> Gurkan
>
>
> On Wed, Dec 5, 2018 at 8:33 PM Jonathan Gallimore <
> jonathan.gallimore@gmail.com> wrote:
>
> > Thanks for the background David, that's much appreciated.
> >
> > I agree about the webapp. Our last CVE was due to an XSS issue in that
> > webapp - I'd be inclined to remove it as well. Our Arquillian test suite
> > tests all the distros *and* has a couple of phases doing an install with
> > the webapp, so losing the webapp could shorten the build a bit too.
> >
> > Back on the CMP changes, my Arquillian test is now working, and I'm quite
> > happy with the change itself. If there's no objections, I'll merge this
> in
> > tomorrow. I'll do some documentation and check some more stuff out with
> > this functionality after that merge.
> >
> > Thanks
> >
> > Jon
> >
> > On Wed, Dec 5, 2018 at 1:09 AM David Blevins <da...@gmail.com>
> > wrote:
> >
> > > > On Dec 4, 2018, at 4:08 PM, Jonathan Gallimore <
> > > jonathan.gallimore@gmail.com> wrote:
> > > >
> > > > I don't know that we have stuff that is deprecated pending removal at
> > the
> > > > moment. In terms of removing the CMP/BMP stuff... well, people are
> > using
> > > > it, which is why I'm working on it :-). I would be ok with marking it
> > as
> > > > deprecated, as long as we print out an explicit warning if your
> > > application
> > > > is using it, so you know to migrate. In terms of the gain... I don't
> > > know.
> > > > There'd be less code, but I suspect still the same dependencies, so
> > we'd
> > > be
> > > > removing a small part of openejb-core effectively. I think its a good
> > > > discussion, but I'd prefer to see graceful deprecation with clear
> > > warnings
> > > > before removal.
> > >
> > > Contextual information on the CMP implementation.  We actually had a
> > > separate CMP implementation in OpenEJB 2.0 that was working and passed
> > the
> > > TCK and used to certify Geronimo for J2EE 1.5.
> > >
> > > When JPA was added in EJB 3.0 / Java EE 5, we made a deliberate
> decision
> > > to throw out all of that code and write a new CMP implementation in
> > OpenEJB
> > > 3.0 on top of JPA to protect ourselves in the future from the
> inevitable
> > > cost of CMP legacy.  What we have is actually a very thin layer on top
> of
> > > JPA, which I think provides people more value than cost.
> > >
> > > If someone is still stuck on CMP, our implementation is the best in the
> > > industry in terms of helping you migrate to JPA, because it *is* JPA
> and
> > > you can freely mix the two and even have them backed by the same
> > > persistence unit.
> > >
> > > There is no code in TomEE/OpenEJB that implements Corba or JAX-RPC. All
> > > the Corba and ORB related code stayed in Geronimo as we didn't want it
> > > OpenEJB 3.0 because even for 2006 it would have been instant legacy.
> > Same
> > > with JAX-RPC which would have brought in at least 10BM in dependencies.
> > >
> > > If we hadn't completely rewritten OpenEJB between 2 and 3 I suspect we
> > > would have good candidates for the chopping block.
> > >
> > > One thing I think is a great candidate for the chopping block is the
> > > "tomee-webapp" used to bootstrap our Tomcat integration for people who
> do
> > > not have the ability to just use an already built TomEE dis.  I don't
> > think
> > > it ever took off.  I'm not aware of anyone using it.  Removing it would
> > > allow us to drop binaries from our release process.  We could optimize
> > our
> > > Tomcat integration because there are quirky things we do only for the
> > > benefit of that unused webapp.
> > >
> > > Rather than use that quirky webapp, we could simply build our TomEE
> > > distros using the TomEE Maven Plugin.  It's there to help others build
> > > their own TomEE distros, but we don't use it only because of the
> > > tomee-webapp legacy.  We chose to use the tomee-webapp to "eat our own
> > > dogfood", but we should probably switch the dog food to the TomEE Maven
> > > Plugin.
> > >
> > >
> > > -David
> > >
> > >
> > >
> >
>