CMP/JPA mapping not accounting for <mapping-file> in persistence.xml

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

CMP/JPA mapping not accounting for <mapping-file> in persistence.xml

jgallimore
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
Reply | Threaded
Open this post in threaded view
|

Re: CMP/JPA mapping not accounting for <mapping-file> in persistence.xml

jgallimore
This is my work in progress so far: https://github.com/apache/tomee/pull/222
.

I'd like to incorporate some Arquillian tests today, and ensure that this
works with things like relationships between entities.

The change here is fairly straightforward though; we pick up a persistence
unit called "cmp", if one has been defined, and read all the elements on
it. If an entity has been defined in one of those mappings files, we add
the entity class to a set, and the CMP/JPA processing will simply ignore
it. The persistence provider should then use the mapping that has been
defined in the mapping file and not generate its own.

I'll post further updates here, but feedback is welcome.

Jon

On Wed, Nov 28, 2018 at 11:50 AM Jonathan Gallimore <
[hidden email]> wrote:

> 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
>
Reply | Threaded
Open this post in threaded view
|

Re: CMP/JPA mapping not accounting for <mapping-file> in persistence.xml

jgallimore
I have pushed some further work on this, but I'm now stuck. I have tried to
ensure that this is working ok with CMP beans with a 1-m relationship, but
I am getting a very weird NPE from here:
https://github.com/apache/tomee/pull/222/commits/5d3efd692c4ee3c635d76e5e53b0ff583d692be3#diff-59a18d263fb512ee53c08513f51d2172R58

Weirdly, the business method on MovieBusinessBean works ok:
https://github.com/apache/tomee/pull/222/commits/5d3efd692c4ee3c635d76e5e53b0ff583d692be3#diff-d3d03f1bc557e1eca2bac8afe2a7c86bR56.
All I can see in terms of the stack trace is an NPE thrown inside the
proxy, called from line 58 of MoviesServlet. Only started happening when I
added the addActor method.

I'll kick hacking away on it, but any review of the code, any samples of
CMP code with relationships working, or general debugging tips are much
appreciated.

Jon

On Thu, Nov 29, 2018 at 10:23 AM Jonathan Gallimore <
[hidden email]> wrote:

> This is my work in progress so far:
> https://github.com/apache/tomee/pull/222.
>
> I'd like to incorporate some Arquillian tests today, and ensure that this
> works with things like relationships between entities.
>
> The change here is fairly straightforward though; we pick up a persistence
> unit called "cmp", if one has been defined, and read all the elements on
> it. If an entity has been defined in one of those mappings files, we add
> the entity class to a set, and the CMP/JPA processing will simply ignore
> it. The persistence provider should then use the mapping that has been
> defined in the mapping file and not generate its own.
>
> I'll post further updates here, but feedback is welcome.
>
> Jon
>
> On Wed, Nov 28, 2018 at 11:50 AM Jonathan Gallimore <
> [hidden email]> wrote:
>
>> 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
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: CMP/JPA mapping not accounting for <mapping-file> in persistence.xml

jgallimore
I hacked together a little JVMTI agent to help debug this, and I think I
have tracked down where the NPE is - looks to be field is null in the
metadata that is handed over to OpenJPA. Looks like I now have enough of
stacktrace to debug it. When I track down my mistake, I'll let you know
(and no doubt kick myself as well :-) )

Jon

On Mon, Dec 3, 2018 at 4:55 PM Jonathan Gallimore <
[hidden email]> wrote:

> I have pushed some further work on this, but I'm now stuck. I have tried
> to ensure that this is working ok with CMP beans with a 1-m relationship,
> but I am getting a very weird NPE from here:
> https://github.com/apache/tomee/pull/222/commits/5d3efd692c4ee3c635d76e5e53b0ff583d692be3#diff-59a18d263fb512ee53c08513f51d2172R58
>
> Weirdly, the business method on MovieBusinessBean works ok:
> https://github.com/apache/tomee/pull/222/commits/5d3efd692c4ee3c635d76e5e53b0ff583d692be3#diff-d3d03f1bc557e1eca2bac8afe2a7c86bR56.
> All I can see in terms of the stack trace is an NPE thrown inside the
> proxy, called from line 58 of MoviesServlet. Only started happening when I
> added the addActor method.
>
> I'll kick hacking away on it, but any review of the code, any samples of
> CMP code with relationships working, or general debugging tips are much
> appreciated.
>
> Jon
>
> On Thu, Nov 29, 2018 at 10:23 AM Jonathan Gallimore <
> [hidden email]> wrote:
>
>> This is my work in progress so far:
>> https://github.com/apache/tomee/pull/222.
>>
>> I'd like to incorporate some Arquillian tests today, and ensure that this
>> works with things like relationships between entities.
>>
>> The change here is fairly straightforward though; we pick up a
>> persistence unit called "cmp", if one has been defined, and read all the
>> elements on it. If an entity has been defined in one of those mappings
>> files, we add the entity class to a set, and the CMP/JPA processing will
>> simply ignore it. The persistence provider should then use the mapping that
>> has been defined in the mapping file and not generate its own.
>>
>> I'll post further updates here, but feedback is welcome.
>>
>> Jon
>>
>> On Wed, Nov 28, 2018 at 11:50 AM Jonathan Gallimore <
>> [hidden email]> wrote:
>>
>>> 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
>>>
>>
Reply | Threaded
Open this post in threaded view
|

Re: CMP/JPA mapping not accounting for <mapping-file> in persistence.xml

David Blevins-2
In the bike shed vs nuclear reactor analogy of open source, you're working on a nuclear reactor and therefore not getting much participation.  This particular code is super hard and the guy who wrote it was Dain Sundstrom, who went on to create Presto a 300 pedabyte data warehouse Facebook runs on.  This is also the only CMP implementation that runs on JPA.

Thank you for working on it.

We should document it incredibly, because it *is* a "nuclear reactor" and few people can work on it. I'm aware of the high level design, but this one should point at actual code and say "look here and here for the critical things.  If you have issues, do this and do that."


--
David Blevins
http://twitter.com/dblevins
http://www.tomitribe.com

> On Dec 4, 2018, at 3:48 AM, Jonathan Gallimore <[hidden email]> wrote:
>
> I hacked together a little JVMTI agent to help debug this, and I think I
> have tracked down where the NPE is - looks to be field is null in the
> metadata that is handed over to OpenJPA. Looks like I now have enough of
> stacktrace to debug it. When I track down my mistake, I'll let you know
> (and no doubt kick myself as well :-) )
>
> Jon
>
> On Mon, Dec 3, 2018 at 4:55 PM Jonathan Gallimore <
> [hidden email]> wrote:
>
>> I have pushed some further work on this, but I'm now stuck. I have tried
>> to ensure that this is working ok with CMP beans with a 1-m relationship,
>> but I am getting a very weird NPE from here:
>> https://github.com/apache/tomee/pull/222/commits/5d3efd692c4ee3c635d76e5e53b0ff583d692be3#diff-59a18d263fb512ee53c08513f51d2172R58
>>
>> Weirdly, the business method on MovieBusinessBean works ok:
>> https://github.com/apache/tomee/pull/222/commits/5d3efd692c4ee3c635d76e5e53b0ff583d692be3#diff-d3d03f1bc557e1eca2bac8afe2a7c86bR56.
>> All I can see in terms of the stack trace is an NPE thrown inside the
>> proxy, called from line 58 of MoviesServlet. Only started happening when I
>> added the addActor method.
>>
>> I'll kick hacking away on it, but any review of the code, any samples of
>> CMP code with relationships working, or general debugging tips are much
>> appreciated.
>>
>> Jon
>>
>> On Thu, Nov 29, 2018 at 10:23 AM Jonathan Gallimore <
>> [hidden email]> wrote:
>>
>>> This is my work in progress so far:
>>> https://github.com/apache/tomee/pull/222.
>>>
>>> I'd like to incorporate some Arquillian tests today, and ensure that this
>>> works with things like relationships between entities.
>>>
>>> The change here is fairly straightforward though; we pick up a
>>> persistence unit called "cmp", if one has been defined, and read all the
>>> elements on it. If an entity has been defined in one of those mappings
>>> files, we add the entity class to a set, and the CMP/JPA processing will
>>> simply ignore it. The persistence provider should then use the mapping that
>>> has been defined in the mapping file and not generate its own.
>>>
>>> I'll post further updates here, but feedback is welcome.
>>>
>>> Jon
>>>
>>> On Wed, Nov 28, 2018 at 11:50 AM Jonathan Gallimore <
>>> [hidden email]> wrote:
>>>
>>>> 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
>>>>
>>>

Reply | Threaded
Open this post in threaded view
|

Re: CMP/JPA mapping not accounting for <mapping-file> in persistence.xml

jgallimore
I'm kinda enjoying the challenge. And yes, I'll definitely be kicking out
some docs and better examples for this. :)

Jon

On Tue, Dec 4, 2018 at 4:38 PM David Blevins <[hidden email]>
wrote:

> In the bike shed vs nuclear reactor analogy of open source, you're working
> on a nuclear reactor and therefore not getting much participation.  This
> particular code is super hard and the guy who wrote it was Dain Sundstrom,
> who went on to create Presto a 300 pedabyte data warehouse Facebook runs
> on.  This is also the only CMP implementation that runs on JPA.
>
> Thank you for working on it.
>
> We should document it incredibly, because it *is* a "nuclear reactor" and
> few people can work on it. I'm aware of the high level design, but this one
> should point at actual code and say "look here and here for the critical
> things.  If you have issues, do this and do that."
>
>
> --
> David Blevins
> http://twitter.com/dblevins
> http://www.tomitribe.com
>
> > On Dec 4, 2018, at 3:48 AM, Jonathan Gallimore <
> [hidden email]> wrote:
> >
> > I hacked together a little JVMTI agent to help debug this, and I think I
> > have tracked down where the NPE is - looks to be field is null in the
> > metadata that is handed over to OpenJPA. Looks like I now have enough of
> > stacktrace to debug it. When I track down my mistake, I'll let you know
> > (and no doubt kick myself as well :-) )
> >
> > Jon
> >
> > On Mon, Dec 3, 2018 at 4:55 PM Jonathan Gallimore <
> > [hidden email]> wrote:
> >
> >> I have pushed some further work on this, but I'm now stuck. I have tried
> >> to ensure that this is working ok with CMP beans with a 1-m
> relationship,
> >> but I am getting a very weird NPE from here:
> >>
> https://github.com/apache/tomee/pull/222/commits/5d3efd692c4ee3c635d76e5e53b0ff583d692be3#diff-59a18d263fb512ee53c08513f51d2172R58
> >>
> >> Weirdly, the business method on MovieBusinessBean works ok:
> >>
> https://github.com/apache/tomee/pull/222/commits/5d3efd692c4ee3c635d76e5e53b0ff583d692be3#diff-d3d03f1bc557e1eca2bac8afe2a7c86bR56
> .
> >> All I can see in terms of the stack trace is an NPE thrown inside the
> >> proxy, called from line 58 of MoviesServlet. Only started happening
> when I
> >> added the addActor method.
> >>
> >> I'll kick hacking away on it, but any review of the code, any samples of
> >> CMP code with relationships working, or general debugging tips are much
> >> appreciated.
> >>
> >> Jon
> >>
> >> On Thu, Nov 29, 2018 at 10:23 AM Jonathan Gallimore <
> >> [hidden email]> wrote:
> >>
> >>> This is my work in progress so far:
> >>> https://github.com/apache/tomee/pull/222.
> >>>
> >>> I'd like to incorporate some Arquillian tests today, and ensure that
> this
> >>> works with things like relationships between entities.
> >>>
> >>> The change here is fairly straightforward though; we pick up a
> >>> persistence unit called "cmp", if one has been defined, and read all
> the
> >>> elements on it. If an entity has been defined in one of those mappings
> >>> files, we add the entity class to a set, and the CMP/JPA processing
> will
> >>> simply ignore it. The persistence provider should then use the mapping
> that
> >>> has been defined in the mapping file and not generate its own.
> >>>
> >>> I'll post further updates here, but feedback is welcome.
> >>>
> >>> Jon
> >>>
> >>> On Wed, Nov 28, 2018 at 11:50 AM Jonathan Gallimore <
> >>> [hidden email]> wrote:
> >>>
> >>>> 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
> >>>>
> >>>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: CMP/JPA mapping not accounting for <mapping-file> in persistence.xml

jgallimore
My issue seems more basic than CMP actually - a straight session bean with
a business method that does a no-op is also failing using a Local and
LocalHome interface throws this exception. I stripped the test right down
to the basics, and also tried it in a sample. Not sure what I'm not seeing
at this point. I'll keep you posted if I find anything.

Jon

On Tue, Dec 4, 2018 at 4:41 PM Jonathan Gallimore <
[hidden email]> wrote:

> I'm kinda enjoying the challenge. And yes, I'll definitely be kicking out
> some docs and better examples for this. :)
>
> Jon
>
> On Tue, Dec 4, 2018 at 4:38 PM David Blevins <[hidden email]>
> wrote:
>
>> In the bike shed vs nuclear reactor analogy of open source, you're
>> working on a nuclear reactor and therefore not getting much participation.
>> This particular code is super hard and the guy who wrote it was Dain
>> Sundstrom, who went on to create Presto a 300 pedabyte data warehouse
>> Facebook runs on.  This is also the only CMP implementation that runs on
>> JPA.
>>
>> Thank you for working on it.
>>
>> We should document it incredibly, because it *is* a "nuclear reactor" and
>> few people can work on it. I'm aware of the high level design, but this one
>> should point at actual code and say "look here and here for the critical
>> things.  If you have issues, do this and do that."
>>
>>
>> --
>> David Blevins
>> http://twitter.com/dblevins
>> http://www.tomitribe.com
>>
>> > On Dec 4, 2018, at 3:48 AM, Jonathan Gallimore <
>> [hidden email]> wrote:
>> >
>> > I hacked together a little JVMTI agent to help debug this, and I think I
>> > have tracked down where the NPE is - looks to be field is null in the
>> > metadata that is handed over to OpenJPA. Looks like I now have enough of
>> > stacktrace to debug it. When I track down my mistake, I'll let you know
>> > (and no doubt kick myself as well :-) )
>> >
>> > Jon
>> >
>> > On Mon, Dec 3, 2018 at 4:55 PM Jonathan Gallimore <
>> > [hidden email]> wrote:
>> >
>> >> I have pushed some further work on this, but I'm now stuck. I have
>> tried
>> >> to ensure that this is working ok with CMP beans with a 1-m
>> relationship,
>> >> but I am getting a very weird NPE from here:
>> >>
>> https://github.com/apache/tomee/pull/222/commits/5d3efd692c4ee3c635d76e5e53b0ff583d692be3#diff-59a18d263fb512ee53c08513f51d2172R58
>> >>
>> >> Weirdly, the business method on MovieBusinessBean works ok:
>> >>
>> https://github.com/apache/tomee/pull/222/commits/5d3efd692c4ee3c635d76e5e53b0ff583d692be3#diff-d3d03f1bc557e1eca2bac8afe2a7c86bR56
>> .
>> >> All I can see in terms of the stack trace is an NPE thrown inside the
>> >> proxy, called from line 58 of MoviesServlet. Only started happening
>> when I
>> >> added the addActor method.
>> >>
>> >> I'll kick hacking away on it, but any review of the code, any samples
>> of
>> >> CMP code with relationships working, or general debugging tips are much
>> >> appreciated.
>> >>
>> >> Jon
>> >>
>> >> On Thu, Nov 29, 2018 at 10:23 AM Jonathan Gallimore <
>> >> [hidden email]> wrote:
>> >>
>> >>> This is my work in progress so far:
>> >>> https://github.com/apache/tomee/pull/222.
>> >>>
>> >>> I'd like to incorporate some Arquillian tests today, and ensure that
>> this
>> >>> works with things like relationships between entities.
>> >>>
>> >>> The change here is fairly straightforward though; we pick up a
>> >>> persistence unit called "cmp", if one has been defined, and read all
>> the
>> >>> elements on it. If an entity has been defined in one of those mappings
>> >>> files, we add the entity class to a set, and the CMP/JPA processing
>> will
>> >>> simply ignore it. The persistence provider should then use the
>> mapping that
>> >>> has been defined in the mapping file and not generate its own.
>> >>>
>> >>> I'll post further updates here, but feedback is welcome.
>> >>>
>> >>> Jon
>> >>>
>> >>> On Wed, Nov 28, 2018 at 11:50 AM Jonathan Gallimore <
>> >>> [hidden email]> wrote:
>> >>>
>> >>>> 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
>> >>>>
>> >>>
>>
>>
Reply | Threaded
Open this post in threaded view
|

Re: CMP/JPA mapping not accounting for <mapping-file> in persistence.xml

Gurkan Erdogdu-5
Great job John. In the mean time,
What do you think to trim  old parts of TomEE which includes

   - Removing ORB support
   - Removing CMP/BMP support
   - Some other non-common or deprecated parts?

If we want to have a maintainable TomEE codebase, instead of adding more
features, we need to have more reliable/readable/lightweight code base. I
will start to add comments/explanations to the methods, remove duplicated
parts etc.

Also, is it possible to return back to commit and then review policy? We
can have some strict rules to correlate the commit with the JIRA issue. If
the commit will have a big impact in the current codebase, before working
on the feature, we can discuss it first and starts to work if the community
all agree. Otherwise, it includes lots of commits within one shot that hard
to understand the content.  I think that  community consensus is necessary
before adding big changes/updates to the current codebase.

WDYT? Comments/advises are so welcome!

Regards.
Gurkan


On Tue, Dec 4, 2018 at 8:46 PM Jonathan Gallimore <
[hidden email]> wrote:

> My issue seems more basic than CMP actually - a straight session bean with
> a business method that does a no-op is also failing using a Local and
> LocalHome interface throws this exception. I stripped the test right down
> to the basics, and also tried it in a sample. Not sure what I'm not seeing
> at this point. I'll keep you posted if I find anything.
>
> Jon
>
> On Tue, Dec 4, 2018 at 4:41 PM Jonathan Gallimore <
> [hidden email]> wrote:
>
> > I'm kinda enjoying the challenge. And yes, I'll definitely be kicking out
> > some docs and better examples for this. :)
> >
> > Jon
> >
> > On Tue, Dec 4, 2018 at 4:38 PM David Blevins <[hidden email]>
> > wrote:
> >
> >> In the bike shed vs nuclear reactor analogy of open source, you're
> >> working on a nuclear reactor and therefore not getting much
> participation.
> >> This particular code is super hard and the guy who wrote it was Dain
> >> Sundstrom, who went on to create Presto a 300 pedabyte data warehouse
> >> Facebook runs on.  This is also the only CMP implementation that runs on
> >> JPA.
> >>
> >> Thank you for working on it.
> >>
> >> We should document it incredibly, because it *is* a "nuclear reactor"
> and
> >> few people can work on it. I'm aware of the high level design, but this
> one
> >> should point at actual code and say "look here and here for the critical
> >> things.  If you have issues, do this and do that."
> >>
> >>
> >> --
> >> David Blevins
> >> http://twitter.com/dblevins
> >> http://www.tomitribe.com
> >>
> >> > On Dec 4, 2018, at 3:48 AM, Jonathan Gallimore <
> >> [hidden email]> wrote:
> >> >
> >> > I hacked together a little JVMTI agent to help debug this, and I
> think I
> >> > have tracked down where the NPE is - looks to be field is null in the
> >> > metadata that is handed over to OpenJPA. Looks like I now have enough
> of
> >> > stacktrace to debug it. When I track down my mistake, I'll let you
> know
> >> > (and no doubt kick myself as well :-) )
> >> >
> >> > Jon
> >> >
> >> > On Mon, Dec 3, 2018 at 4:55 PM Jonathan Gallimore <
> >> > [hidden email]> wrote:
> >> >
> >> >> I have pushed some further work on this, but I'm now stuck. I have
> >> tried
> >> >> to ensure that this is working ok with CMP beans with a 1-m
> >> relationship,
> >> >> but I am getting a very weird NPE from here:
> >> >>
> >>
> https://github.com/apache/tomee/pull/222/commits/5d3efd692c4ee3c635d76e5e53b0ff583d692be3#diff-59a18d263fb512ee53c08513f51d2172R58
> >> >>
> >> >> Weirdly, the business method on MovieBusinessBean works ok:
> >> >>
> >>
> https://github.com/apache/tomee/pull/222/commits/5d3efd692c4ee3c635d76e5e53b0ff583d692be3#diff-d3d03f1bc557e1eca2bac8afe2a7c86bR56
> >> .
> >> >> All I can see in terms of the stack trace is an NPE thrown inside the
> >> >> proxy, called from line 58 of MoviesServlet. Only started happening
> >> when I
> >> >> added the addActor method.
> >> >>
> >> >> I'll kick hacking away on it, but any review of the code, any samples
> >> of
> >> >> CMP code with relationships working, or general debugging tips are
> much
> >> >> appreciated.
> >> >>
> >> >> Jon
> >> >>
> >> >> On Thu, Nov 29, 2018 at 10:23 AM Jonathan Gallimore <
> >> >> [hidden email]> wrote:
> >> >>
> >> >>> This is my work in progress so far:
> >> >>> https://github.com/apache/tomee/pull/222.
> >> >>>
> >> >>> I'd like to incorporate some Arquillian tests today, and ensure that
> >> this
> >> >>> works with things like relationships between entities.
> >> >>>
> >> >>> The change here is fairly straightforward though; we pick up a
> >> >>> persistence unit called "cmp", if one has been defined, and read all
> >> the
> >> >>> elements on it. If an entity has been defined in one of those
> mappings
> >> >>> files, we add the entity class to a set, and the CMP/JPA processing
> >> will
> >> >>> simply ignore it. The persistence provider should then use the
> >> mapping that
> >> >>> has been defined in the mapping file and not generate its own.
> >> >>>
> >> >>> I'll post further updates here, but feedback is welcome.
> >> >>>
> >> >>> Jon
> >> >>>
> >> >>> On Wed, Nov 28, 2018 at 11:50 AM Jonathan Gallimore <
> >> >>> [hidden email]> wrote:
> >> >>>
> >> >>>> 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
> >> >>>>
> >> >>>
> >>
> >>
>
Reply | Threaded
Open this post in threaded view
|

Re: CMP/JPA mapping not accounting for <mapping-file> in persistence.xml

jgallimore
Thanks Gurkan.

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.

I'm sure adding comments to the code will be helpful, particularly for new
contributors - thank you.

We're currently on a CTR policy. It is perfectly ok to commit, and then
review. I personally prefer to commit stuff to my fork and discuss a diff
here before its merged. Even though I haven't had many replies on this
thread, just writing about what I'm running into helps. For folks that
aren't committers, the usual contribution methods are fine - GitHub PRs,
diffs attached to JIRAs, whatever works. The nice thing about PRs is that
your name is still attached to the commit when its merged, so you forever
get credit in the git log. Applying diffs from tickets works, and we'll
give credit of course, but the author in log will be whoever applies the
diff.

In other news, I think I have fix for my test. The bad news is that my Mac
chose that moment to blow fuses in 4 different chargers and needs to be
repaired, so I'm mid-swapping-over machines. I should get that pushed
tomorrow morning all being well.

Jon

On Tue, Dec 4, 2018 at 7:14 PM Gurkan Erdogdu <[hidden email]> wrote:

> Great job John. In the mean time,
> What do you think to trim  old parts of TomEE which includes
>
>    - Removing ORB support
>    - Removing CMP/BMP support
>    - Some other non-common or deprecated parts?
>
> If we want to have a maintainable TomEE codebase, instead of adding more
> features, we need to have more reliable/readable/lightweight code base. I
> will start to add comments/explanations to the methods, remove duplicated
> parts etc.
>
> Also, is it possible to return back to commit and then review policy? We
> can have some strict rules to correlate the commit with the JIRA issue. If
> the commit will have a big impact in the current codebase, before working
> on the feature, we can discuss it first and starts to work if the community
> all agree. Otherwise, it includes lots of commits within one shot that hard
> to understand the content.  I think that  community consensus is necessary
> before adding big changes/updates to the current codebase.
>
> WDYT? Comments/advises are so welcome!
>
> Regards.
> Gurkan
>
>
> On Tue, Dec 4, 2018 at 8:46 PM Jonathan Gallimore <
> [hidden email]> wrote:
>
> > My issue seems more basic than CMP actually - a straight session bean
> with
> > a business method that does a no-op is also failing using a Local and
> > LocalHome interface throws this exception. I stripped the test right down
> > to the basics, and also tried it in a sample. Not sure what I'm not
> seeing
> > at this point. I'll keep you posted if I find anything.
> >
> > Jon
> >
> > On Tue, Dec 4, 2018 at 4:41 PM Jonathan Gallimore <
> > [hidden email]> wrote:
> >
> > > I'm kinda enjoying the challenge. And yes, I'll definitely be kicking
> out
> > > some docs and better examples for this. :)
> > >
> > > Jon
> > >
> > > On Tue, Dec 4, 2018 at 4:38 PM David Blevins <[hidden email]>
> > > wrote:
> > >
> > >> In the bike shed vs nuclear reactor analogy of open source, you're
> > >> working on a nuclear reactor and therefore not getting much
> > participation.
> > >> This particular code is super hard and the guy who wrote it was Dain
> > >> Sundstrom, who went on to create Presto a 300 pedabyte data warehouse
> > >> Facebook runs on.  This is also the only CMP implementation that runs
> on
> > >> JPA.
> > >>
> > >> Thank you for working on it.
> > >>
> > >> We should document it incredibly, because it *is* a "nuclear reactor"
> > and
> > >> few people can work on it. I'm aware of the high level design, but
> this
> > one
> > >> should point at actual code and say "look here and here for the
> critical
> > >> things.  If you have issues, do this and do that."
> > >>
> > >>
> > >> --
> > >> David Blevins
> > >> http://twitter.com/dblevins
> > >> http://www.tomitribe.com
> > >>
> > >> > On Dec 4, 2018, at 3:48 AM, Jonathan Gallimore <
> > >> [hidden email]> wrote:
> > >> >
> > >> > I hacked together a little JVMTI agent to help debug this, and I
> > think I
> > >> > have tracked down where the NPE is - looks to be field is null in
> the
> > >> > metadata that is handed over to OpenJPA. Looks like I now have
> enough
> > of
> > >> > stacktrace to debug it. When I track down my mistake, I'll let you
> > know
> > >> > (and no doubt kick myself as well :-) )
> > >> >
> > >> > Jon
> > >> >
> > >> > On Mon, Dec 3, 2018 at 4:55 PM Jonathan Gallimore <
> > >> > [hidden email]> wrote:
> > >> >
> > >> >> I have pushed some further work on this, but I'm now stuck. I have
> > >> tried
> > >> >> to ensure that this is working ok with CMP beans with a 1-m
> > >> relationship,
> > >> >> but I am getting a very weird NPE from here:
> > >> >>
> > >>
> >
> https://github.com/apache/tomee/pull/222/commits/5d3efd692c4ee3c635d76e5e53b0ff583d692be3#diff-59a18d263fb512ee53c08513f51d2172R58
> > >> >>
> > >> >> Weirdly, the business method on MovieBusinessBean works ok:
> > >> >>
> > >>
> >
> https://github.com/apache/tomee/pull/222/commits/5d3efd692c4ee3c635d76e5e53b0ff583d692be3#diff-d3d03f1bc557e1eca2bac8afe2a7c86bR56
> > >> .
> > >> >> All I can see in terms of the stack trace is an NPE thrown inside
> the
> > >> >> proxy, called from line 58 of MoviesServlet. Only started happening
> > >> when I
> > >> >> added the addActor method.
> > >> >>
> > >> >> I'll kick hacking away on it, but any review of the code, any
> samples
> > >> of
> > >> >> CMP code with relationships working, or general debugging tips are
> > much
> > >> >> appreciated.
> > >> >>
> > >> >> Jon
> > >> >>
> > >> >> On Thu, Nov 29, 2018 at 10:23 AM Jonathan Gallimore <
> > >> >> [hidden email]> wrote:
> > >> >>
> > >> >>> This is my work in progress so far:
> > >> >>> https://github.com/apache/tomee/pull/222.
> > >> >>>
> > >> >>> I'd like to incorporate some Arquillian tests today, and ensure
> that
> > >> this
> > >> >>> works with things like relationships between entities.
> > >> >>>
> > >> >>> The change here is fairly straightforward though; we pick up a
> > >> >>> persistence unit called "cmp", if one has been defined, and read
> all
> > >> the
> > >> >>> elements on it. If an entity has been defined in one of those
> > mappings
> > >> >>> files, we add the entity class to a set, and the CMP/JPA
> processing
> > >> will
> > >> >>> simply ignore it. The persistence provider should then use the
> > >> mapping that
> > >> >>> has been defined in the mapping file and not generate its own.
> > >> >>>
> > >> >>> I'll post further updates here, but feedback is welcome.
> > >> >>>
> > >> >>> Jon
> > >> >>>
> > >> >>> On Wed, Nov 28, 2018 at 11:50 AM Jonathan Gallimore <
> > >> >>> [hidden email]> wrote:
> > >> >>>
> > >> >>>> 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
> > >> >>>>
> > >> >>>
> > >>
> > >>
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: CMP/JPA mapping not accounting for <mapping-file> in persistence.xml

David Blevins-2
> On Dec 4, 2018, at 4:08 PM, Jonathan Gallimore <[hidden email]> 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


Reply | Threaded
Open this post in threaded view
|

Re: CMP/JPA mapping not accounting for <mapping-file> in persistence.xml

jgallimore
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 <[hidden email]>
wrote:

> > On Dec 4, 2018, at 4:08 PM, Jonathan Gallimore <
> [hidden email]> 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
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: CMP/JPA mapping not accounting for <mapping-file> in persistence.xml

Gurkan Erdogdu-5
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 <
[hidden email]> 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 <[hidden email]>
> wrote:
>
> > > On Dec 4, 2018, at 4:08 PM, Jonathan Gallimore <
> > [hidden email]> 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
> >
> >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: CMP/JPA mapping not accounting for <mapping-file> in persistence.xml

Otávio Gonçalves de Santana
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 <[hidden email]> 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 <
> [hidden email]> 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 <[hidden email]>
> > wrote:
> >
> > > > On Dec 4, 2018, at 4:08 PM, Jonathan Gallimore <
> > > [hidden email]> 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
> > >
> > >
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: CMP/JPA mapping not accounting for <mapping-file> in persistence.xml

Otávio Gonçalves de Santana
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 <
[hidden email]> 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 <[hidden email]> 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 <
>> [hidden email]> 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 <[hidden email]>
>> > wrote:
>> >
>> > > > On Dec 4, 2018, at 4:08 PM, Jonathan Gallimore <
>> > > [hidden email]> 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
>> > >
>> > >
>> > >
>> >
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: CMP/JPA mapping not accounting for <mapping-file> in persistence.xml

brunobat
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 <
> [hidden email]> 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 <[hidden email]> 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 <
>>> [hidden email]> 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 <[hidden email]>
>>>> wrote:
>>>>
>>>>>> On Dec 4, 2018, at 4:08 PM, Jonathan Gallimore <
>>>>> [hidden email]> 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
>>>>>
>>>>>
>>>>>
Reply | Threaded
Open this post in threaded view
|

Re: CMP/JPA mapping not accounting for <mapping-file> in persistence.xml

Otávio Gonçalves de Santana
The second PR: https://github.com/apache/tomee/pull/285

On Mon, Dec 17, 2018 at 10:21 AM Bruno Baptista <[hidden email]> 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 <
> > [hidden email]> 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 <[hidden email]>
> 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 <
> >>> [hidden email]> 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 <[hidden email]
> >
> >>>> wrote:
> >>>>
> >>>>>> On Dec 4, 2018, at 4:08 PM, Jonathan Gallimore <
> >>>>> [hidden email]> 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
> >>>>>
> >>>>>
> >>>>>
>