You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomee.apache.org by "Zowalla, Richard" <ri...@hs-heilbronn.de> on 2020/07/07 08:48:08 UTC
Follow-Up: ORB Dependencies and Java 11
Hi,
I was digging around the GitHub Repo and noticed PR 664 [1], which
tries to prepare TomEE to be build with JDK 11 but CORBA was removed in
JDK 11.
There was a disucssion 2 years ago about removing CORBA related access
[2]. There even exist a JIRA (TOMEE-2324) for it [3].
If we want to build TomEE with JDK 11, we either need to (a) remove
CORBA dependencies (and check the implications as suggested in TOMEE-
2324) or (b) add the CORBA API / IMPL back (e.g. via "jacorb" [4] or
via the glassfish api/impl ("glassfish-corba-orb" [5]).
What is the plan for this? Any opinions? :)
Best,
Richard
[1] https://github.com/apache/tomee/pull/664
[2] https://www.mail-archive.com/dev@tomee.apache.org/msg08054.html
[3] https://issues.apache.org/jira/projects/TOMEE/issues/TOMEE-2324
[4] https://www.jacorb.org/
[5] https://javaee.github.io/glassfish-corba/
Re: Follow-Up: ORB Dependencies and Java 11
Posted by "Zowalla, Richard" <ri...@hs-heilbronn.de>.
Hi all,
I found some time creating the classes via ASM, see PR
https://github.com/apache/tomee/pull/713
Happy to retrieve feedback on it.
Best
Richard
Am Mittwoch, den 08.07.2020, 18:56 +0000 schrieb Zowalla, Richard:
> Hi David,
>
> thanks for the in-depth explanation & opinion. It is very much
> appreciated.
>
> To use ASM in order to generate the two classes could be indeed a
> good solution.
>
> Shall we adjust the (old) JIRA for this with reference to this
> discussion?
>
> As this is not mission critical, I could give it a try. Never did
> something with ASM, but happy to dig into it :D
>
> Best,
> Richard
>
>
>
>
>
> Am Mittwoch, den 08.07.2020, 11:23 -0700 schrieb David Blevins:
> > Hi Richard!
> >
> > > On Jul 7, 2020, at 11:54 PM, Zowalla, Richard <
> > > richard.zowalla@hs-heilbronn.de> wrote:
> > >
> > > Thanks for your insights & opinion, @David Jencks & David
> > > Blevins. It is very intersting from my point of view.
> > >
> > > I got this quote from the mailing list archive [1] by @dblevins
> > >
> > > > I know we don't support Corba itself, so we'd probably have to
> > > figure out
> > > > how we're tied to those classes and what to do about it.
> > >
> > > If the "we do not support it" is still correct, we could try to
> > > remove it and then check for the build status (with Java 8).
> >
> > For context the "we don't support Corba" I was referring to is the
> > Java EE Full Profile requirements. There was an entire chapter
> > dedicated to the topic and a few thousand tests in the TCK that
> > involved ensuring your ORB can talk to someone else's ORB while
> > accomplishing distributed transactions and security between the
> > servers. Extremely difficult stuff that in practice few people
> > ever put into production.
> >
> > There are a couple small convenience classes. If we were doing
> > this for a new major version, I'd have no issues with dropping them
> > without warning. It's removing them between 8.0.2 and 8.0.3 is the
> > part that gives me pause.
> >
> > > This will open the possibility to build with Java 11 (target byte
> > > code level 8) in case we want it as "nice 2 have".
> > >
> > > The places in the code-base with CORBA related access are:
> > >
> > > org.apache.openejb.core.OrbFactory
> > > org.apache.openejb.client.corba.Corbas
> > >
> > > XML Files, service-jar XML files:
> > >
> > > <ServiceProvider id=
> > > "Default ORB"
> > >
> > > service=
> > > "Resource"
> > >
> > > types=
> > > "org.omg.CORBA.ORB, ORB"
> > >
> > > factory-name=
> > > "create"
> > >
> > > class-
> > > name=
> > > "org.apache.openejb.core.OrbFactory"
> > > >
> > > </ServiceProvider>
> >
> > One way to handle these two classes could be to simply generate
> > them with ASM. We do that for our Hibernate support as we can't
> > have a direct dependency on it due to licensing restrictions.
> >
> > -
> > https://github.com/apache/tomee/blob/master/container/openejb-jpa-integration/src/main/java/org/apache/openejb/jpa/integration/MakeTxLookup.java
> >
> > In this case we are doing the generation at server startup, but we
> > could just as easily do it at build-time.
> >
> > That would involve no risk removing them would affect someone yet
> > allows the build to work (better) on Java 11.
> >
> > > Nevertheless, one outcome of this dicussion is, that PR 664 [2]
> > > might be closed due to the incompatible license of jacorb
> > > (according to @David Jencks).
> >
> > Right, that could be an issue. I agree with David that the bigger
> > question is if we want to sign up for the incredible complex task
> > of shipping and supporting an ORB. We really struggled with it in
> > Geronimo and it was overall a feature that came at high cost with
> > no real users and the only real benefit was being able to pass the
> > TCK.
> >
> > I'd be happy to maintain what we have for the duration of 8.0.x
> > (via above or any other technique that allows Java 11 progress) and
> > drop it as soon as we have a true new major version.
> >
> >
> > -David
> >
> >
> >
Re: Follow-Up: ORB Dependencies and Java 11
Posted by "Zowalla, Richard" <ri...@hs-heilbronn.de>.
Hi David,
thanks for the in-depth explanation & opinion. It is very much
appreciated.
To use ASM in order to generate the two classes could be indeed a good
solution.
Shall we adjust the (old) JIRA for this with reference to this
discussion?
As this is not mission critical, I could give it a try. Never did
something with ASM, but happy to dig into it :D
Best,Richard
Am Mittwoch, den 08.07.2020, 11:23 -0700 schrieb David Blevins:
> Hi Richard!
> > On Jul 7, 2020, at 11:54 PM, Zowalla, Richard <
> > richard.zowalla@hs-heilbronn.de> wrote:
> >
> > Thanks for your insights & opinion, @David Jencks & David Blevins.
> > It is very intersting from my point of view.
> >
> > I got this quote from the mailing list archive [1] by @dblevins
> >
> > > I know we don't support Corba itself, so we'd probably have to
> > figure out
> > > how we're tied to those classes and what to do about it.
> > If the "we do not support it" is still correct, we could try to
> > remove it and then check for the build status (with Java 8).
>
> For context the "we don't support Corba" I was referring to is the
> Java EE Full Profile requirements. There was an entire chapter
> dedicated to the topic and a few thousand tests in the TCK that
> involved ensuring your ORB can talk to someone else's ORB while
> accomplishing distributed transactions and security between the
> servers. Extremely difficult stuff that in practice few people ever
> put into production.
>
> There are a couple small convenience classes. If we were doing this
> for a new major version, I'd have no issues with dropping them
> without warning. It's removing them between 8.0.2 and 8.0.3 is the
> part that gives me pause.
>
> > This will open the possibility to build with Java 11 (target byte
> > code level 8) in case we want it as "nice 2 have".
> >
> > The places in the code-base with CORBA related access are:
> >
> > org.apache.openejb.core.OrbFactoryorg.apache.openejb.client.corba.C
> > orbas
> >
> > XML Files, service-jar XML files:
> >
> > <ServiceProvider id="Default ORB" service="Resource"
> > types="org.omg.CORBA.ORB, ORB" factory-name="create" class-
> > name="org.apache.openejb.core.OrbFactory"></ServiceProvider>
> One way to handle these two classes could be to simply generate them
> with ASM. We do that for our Hibernate support as we can't have a
> direct dependency on it due to licensing restrictions.
>
> -
> https://github.com/apache/tomee/blob/master/container/openejb-jpa-integration/src/main/java/org/apache/openejb/jpa/integration/MakeTxLookup.java
>
> In this case we are doing the generation at server startup, but we
> could just as easily do it at build-time.
>
> That would involve no risk removing them would affect someone yet
> allows the build to work (better) on Java 11.
>
> > Nevertheless, one outcome of this dicussion is, that PR 664 [2]
> > might be closed due to the incompatible license of jacorb
> > (according to @David Jencks).
>
> Right, that could be an issue. I agree with David that the bigger
> question is if we want to sign up for the incredible complex task of
> shipping and supporting an ORB. We really struggled with it in
> Geronimo and it was overall a feature that came at high cost with no
> real users and the only real benefit was being able to pass the TCK.
>
> I'd be happy to maintain what we have for the duration of 8.0.x (via
> above or any other technique that allows Java 11 progress) and drop
> it as soon as we have a true new major version.
>
>
> -David
>
>
>
>
Re: Follow-Up: ORB Dependencies and Java 11
Posted by David Blevins <da...@gmail.com>.
Hi Richard!
> On Jul 7, 2020, at 11:54 PM, Zowalla, Richard <ri...@hs-heilbronn.de> wrote:
>
> Thanks for your insights & opinion, @David Jencks & David Blevins. It is very intersting from my point of view.
>
> I got this quote from the mailing list archive [1] by @dblevins
>
> > I know we don't support Corba itself, so we'd probably have to figure out
> > how we're tied to those classes and what to do about it.
>
> If the "we do not support it" is still correct, we could try to remove it and then check for the build status (with Java 8).
For context the "we don't support Corba" I was referring to is the Java EE Full Profile requirements. There was an entire chapter dedicated to the topic and a few thousand tests in the TCK that involved ensuring your ORB can talk to someone else's ORB while accomplishing distributed transactions and security between the servers. Extremely difficult stuff that in practice few people ever put into production.
There are a couple small convenience classes. If we were doing this for a new major version, I'd have no issues with dropping them without warning. It's removing them between 8.0.2 and 8.0.3 is the part that gives me pause.
>
> This will open the possibility to build with Java 11 (target byte code level 8) in case we want it as "nice 2 have".
>
> The places in the code-base with CORBA related access are:
>
> org.apache.openejb.core.OrbFactory
> org.apache.openejb.client.corba.Corbas
>
> XML Files, service-jar XML files:
>
> <ServiceProvider id="Default ORB"
> service="Resource"
> types="org.omg.CORBA.ORB, ORB"
> factory-name="create"
> class-name="org.apache.openejb.core.OrbFactory">
> </ServiceProvider>
One way to handle these two classes could be to simply generate them with ASM. We do that for our Hibernate support as we can't have a direct dependency on it due to licensing restrictions.
- https://github.com/apache/tomee/blob/master/container/openejb-jpa-integration/src/main/java/org/apache/openejb/jpa/integration/MakeTxLookup.java <https://github.com/apache/tomee/blob/master/container/openejb-jpa-integration/src/main/java/org/apache/openejb/jpa/integration/MakeTxLookup.java>
In this case we are doing the generation at server startup, but we could just as easily do it at build-time.
That would involve no risk removing them would affect someone yet allows the build to work (better) on Java 11.
> Nevertheless, one outcome of this dicussion is, that PR 664 [2] might be closed due to the incompatible license of jacorb (according to @David Jencks).
Right, that could be an issue. I agree with David that the bigger question is if we want to sign up for the incredible complex task of shipping and supporting an ORB. We really struggled with it in Geronimo and it was overall a feature that came at high cost with no real users and the only real benefit was being able to pass the TCK.
I'd be happy to maintain what we have for the duration of 8.0.x (via above or any other technique that allows Java 11 progress) and drop it as soon as we have a true new major version.
-David
Re: Follow-Up: ORB Dependencies and Java 11
Posted by "Zowalla, Richard" <ri...@hs-heilbronn.de>.
Thanks for your insights & opinion, @David Jencks & David Blevins. It
is very intersting from my point of view.
I got this quote from the mailing list archive [1] by @dblevins
> I know we don't support Corba itself, so we'd probably have to figure
out> how we're tied to those classes and what to do about it.
If the "we do not support it" is still correct, we could try to remove
it and then check for the build status (with Java 8).
This will open the possibility to build with Java 11 (target byte code
level 8) in case we want it as "nice 2 have".
The places in the code-base with CORBA related access are:
org.apache.openejb.core.OrbFactory
org.apache.openejb.client.corba.Corbas
XML Files, service-jar XML files:
<ServiceProvider id="Default ORB"
service="Resource"
types="org.omg.CORBA.ORB, ORB"
factory-name="create"
class-name="org.apache.openejb.core.OrbFactory">
</ServiceProvider>
Nevertheless, one outcome of this dicussion is, that PR 664 [2] might
be closed due to the incompatible license of jacorb (according to
@David Jencks).
[1] https://www.mail-archive.com/dev@tomee.apache.org/msg08054.html[2]
https://github.com/apache/tomee/pull/664
Am Dienstag, den 07.07.2020, 17:03 -0700 schrieb David Blevins:
> Good discussion with great questions. A couple updates/points:
> - Jakarta EE 9 has entirely removed requirements and tests for
> CORBA/ORB support (resolved and executed)
> - Java 11 may or may not stay as the target jvm version for Jakarta
> EE 9 (new discussion
> https://www.eclipse.org/lists/jakartaee-spec-project-leads/msg00600.html
> )
> - TomEE 8x being the master branch, we have some stability
> limitations on removing/adding major features
> Here's where I think that pushes us.
> CORBA/ORB
> We probably don't want to be adding CORBA support. We maybe could
> have gotten some small benefit 10 years ago when it would have
> allowed us to pursue Java EE Full Profile certification, but with it
> being dropped by the JDK and Jakarta platform we'd be setting
> ourselves up to have to carry a ton of weight.
> That brings us remove vs maintain, which really becomes a stability
> question linked to the fact that TomEE 8.0.x is living in master. We
> might want to explore ways to support the very limited ties we have
> without a compile time dependency: reflection; move that to another
> jar released separately and just import it; generate a class or two
> with ASM (we do this to support Hibernate due to LGPL restrictions).
> Open to ideas.
>
> JAVA 11
> We almost certainly would not be able to drop Java 8 support between
> TomEE 8.0.2 and the coming 8.0.3. More than likely we'd have to
> compile on Java 8 and then run the TCK tests on both Java 8 and Java
> 11 to verify all works. What that means is any support for Java 11
> in the build itself is likely nice-to-have.
> This might become even less of a discussion if Java 8 becomes the
> primary java version for Jakarta EE 9, instead of simply being
> optional as it is now. This decision will be made by next Tuesday,
> but honestly given we're stuck with Java 8 due to TomEE 8/Jakarta EE
> 8, we're not really affected either way.
> Where I think that brings us is that we can do work to make the build
> run on Java 11 as long as it does not break the Java 8 build.
> Open to ideas and discussion on that.
>
>
Re: Follow-Up: ORB Dependencies and Java 11
Posted by David Blevins <da...@gmail.com>.
Good discussion with great questions. A couple updates/points:
- Jakarta EE 9 has entirely removed requirements and tests for CORBA/ORB support (resolved and executed)
- Java 11 may or may not stay as the target jvm version for Jakarta EE 9 (new discussion https://www.eclipse.org/lists/jakartaee-spec-project-leads/msg00600.html)
- TomEE 8x being the master branch, we have some stability limitations on removing/adding major features
Here's where I think that pushes us.
CORBA/ORB
We probably don't want to be adding CORBA support. We maybe could have gotten some small benefit 10 years ago when it would have allowed us to pursue Java EE Full Profile certification, but with it being dropped by the JDK and Jakarta platform we'd be setting ourselves up to have to carry a ton of weight.
That brings us remove vs maintain, which really becomes a stability question linked to the fact that TomEE 8.0.x is living in master. We might want to explore ways to support the very limited ties we have without a compile time dependency: reflection; move that to another jar released separately and just import it; generate a class or two with ASM (we do this to support Hibernate due to LGPL restrictions).
Open to ideas.
JAVA 11
We almost certainly would not be able to drop Java 8 support between TomEE 8.0.2 and the coming 8.0.3. More than likely we'd have to compile on Java 8 and then run the TCK tests on both Java 8 and Java 11 to verify all works. What that means is any support for Java 11 in the build itself is likely nice-to-have.
This might become even less of a discussion if Java 8 becomes the primary java version for Jakarta EE 9, instead of simply being optional as it is now. This decision will be made by next Tuesday, but honestly given we're stuck with Java 8 due to TomEE 8/Jakarta EE 8, we're not really affected either way.
Where I think that brings us is that we can do work to make the build run on Java 11 as long as it does not break the Java 8 build.
Open to ideas and discussion on that.
--
David Blevins
http://twitter.com/dblevins
http://www.tomitribe.com
> On Jul 7, 2020, at 1:48 AM, Zowalla, Richard <ri...@hs-heilbronn.de> wrote:
>
> Hi,
>
> I was digging around the GitHub Repo and noticed PR 664 [1], which
> tries to prepare TomEE to be build with JDK 11 but CORBA was removed in
> JDK 11.
>
> There was a disucssion 2 years ago about removing CORBA related access
> [2]. There even exist a JIRA (TOMEE-2324) for it [3].
>
> If we want to build TomEE with JDK 11, we either need to (a) remove
> CORBA dependencies (and check the implications as suggested in TOMEE-
> 2324) or (b) add the CORBA API / IMPL back (e.g. via "jacorb" [4] or
> via the glassfish api/impl ("glassfish-corba-orb" [5]).
>
> What is the plan for this? Any opinions? :)
>
> Best,
> Richard
>
>
> [1] https://github.com/apache/tomee/pull/664
> [2] https://www.mail-archive.com/dev@tomee.apache.org/msg08054.html
> [3] https://issues.apache.org/jira/projects/TOMEE/issues/TOMEE-2324
> [4] https://www.jacorb.org/
> [5] https://javaee.github.io/glassfish-corba/
Re: Follow-Up: ORB Dependencies and Java 11
Posted by David Jencks <da...@gmail.com>.
I’d be quite surprised if any new applications are developed using CORBA and I’d suspect any existing applications are at companies with ${big} support contracts and little interest in migrating. I don’t know much about users of TomEE however.
Generally jax-rs is an easier to deal with solution nowadays.
David Jencks
> On Jul 7, 2020, at 12:40 PM, Daniel Dias Dos Santos <da...@gmail.com> wrote:
>
> Hello ,
>
> Thanks Richard for the information .
>
> But @David Jencks CORBA is important in TomEE ? has any impact?
>
> --
>
> *Daniel Dias dos Santos*
> Java Developer
> SouJava & JCP Member
> GitHub: https://github.com/Daniel-Dos
> Linkedin: www.linkedin.com/in/danieldiasjava
> Twitter: http://twitter.com/danieldiasjava
>
>
> Em ter., 7 de jul. de 2020 às 16:35, David Jencks <da...@gmail.com>
> escreveu:
>
>> BTW, supporting CORBA, no matter which orb you pick, is quite difficult
>> unless you happen to already be a CORBA expert, probably because you’ve
>> already implemented significant parts of an ORB. The CORBA documentation is
>> fairly opaque, and the semantics are quite different from what you are used
>> to in java. Even though Yoko was used to certify IBM Liberty, getting it
>> to work with TomEE is likely to be a significant and painful adventure.
>>
>> David Jencks
>>
>>> On Jul 7, 2020, at 9:53 AM, David Jencks <da...@gmail.com>
>> wrote:
>>>
>>> Apache Yoko (part of geronimo project) is probably also a viable
>> possibility, a few years ago it was the IBM Liberty corba implementation,
>> and is presumably still used in OpenLiberty. I think jacorb has an
>> incompatible license, which is why we didn’t use it in Geronimo. I don’t
>> know about the glassfish orb.
>>>
>>> David Jencks
>>>
>>>> On Jul 7, 2020, at 1:48 AM, Zowalla, Richard <
>> richard.zowalla@hs-heilbronn.de> wrote:
>>>>
>>>> Hi,
>>>>
>>>> I was digging around the GitHub Repo and noticed PR 664 [1], which
>>>> tries to prepare TomEE to be build with JDK 11 but CORBA was removed in
>>>> JDK 11.
>>>>
>>>> There was a disucssion 2 years ago about removing CORBA related access
>>>> [2]. There even exist a JIRA (TOMEE-2324) for it [3].
>>>>
>>>> If we want to build TomEE with JDK 11, we either need to (a) remove
>>>> CORBA dependencies (and check the implications as suggested in TOMEE-
>>>> 2324) or (b) add the CORBA API / IMPL back (e.g. via "jacorb" [4] or
>>>> via the glassfish api/impl ("glassfish-corba-orb" [5]).
>>>>
>>>> What is the plan for this? Any opinions? :)
>>>>
>>>> Best,
>>>> Richard
>>>>
>>>>
>>>> [1] https://github.com/apache/tomee/pull/664
>>>> [2] https://www.mail-archive.com/dev@tomee.apache.org/msg08054.html
>>>> [3] https://issues.apache.org/jira/projects/TOMEE/issues/TOMEE-2324
>>>> [4] https://www.jacorb.org/
>>>> [5] https://javaee.github.io/glassfish-corba/
>>>
>>
>>
Re: Follow-Up: ORB Dependencies and Java 11
Posted by Daniel Dias Dos Santos <da...@gmail.com>.
Hello ,
Thanks Richard for the information .
But @David Jencks CORBA is important in TomEE ? has any impact?
--
*Daniel Dias dos Santos*
Java Developer
SouJava & JCP Member
GitHub: https://github.com/Daniel-Dos
Linkedin: www.linkedin.com/in/danieldiasjava
Twitter: http://twitter.com/danieldiasjava
Em ter., 7 de jul. de 2020 às 16:35, David Jencks <da...@gmail.com>
escreveu:
> BTW, supporting CORBA, no matter which orb you pick, is quite difficult
> unless you happen to already be a CORBA expert, probably because you’ve
> already implemented significant parts of an ORB. The CORBA documentation is
> fairly opaque, and the semantics are quite different from what you are used
> to in java. Even though Yoko was used to certify IBM Liberty, getting it
> to work with TomEE is likely to be a significant and painful adventure.
>
> David Jencks
>
> > On Jul 7, 2020, at 9:53 AM, David Jencks <da...@gmail.com>
> wrote:
> >
> > Apache Yoko (part of geronimo project) is probably also a viable
> possibility, a few years ago it was the IBM Liberty corba implementation,
> and is presumably still used in OpenLiberty. I think jacorb has an
> incompatible license, which is why we didn’t use it in Geronimo. I don’t
> know about the glassfish orb.
> >
> > David Jencks
> >
> >> On Jul 7, 2020, at 1:48 AM, Zowalla, Richard <
> richard.zowalla@hs-heilbronn.de> wrote:
> >>
> >> Hi,
> >>
> >> I was digging around the GitHub Repo and noticed PR 664 [1], which
> >> tries to prepare TomEE to be build with JDK 11 but CORBA was removed in
> >> JDK 11.
> >>
> >> There was a disucssion 2 years ago about removing CORBA related access
> >> [2]. There even exist a JIRA (TOMEE-2324) for it [3].
> >>
> >> If we want to build TomEE with JDK 11, we either need to (a) remove
> >> CORBA dependencies (and check the implications as suggested in TOMEE-
> >> 2324) or (b) add the CORBA API / IMPL back (e.g. via "jacorb" [4] or
> >> via the glassfish api/impl ("glassfish-corba-orb" [5]).
> >>
> >> What is the plan for this? Any opinions? :)
> >>
> >> Best,
> >> Richard
> >>
> >>
> >> [1] https://github.com/apache/tomee/pull/664
> >> [2] https://www.mail-archive.com/dev@tomee.apache.org/msg08054.html
> >> [3] https://issues.apache.org/jira/projects/TOMEE/issues/TOMEE-2324
> >> [4] https://www.jacorb.org/
> >> [5] https://javaee.github.io/glassfish-corba/
> >
>
>
Re: Follow-Up: ORB Dependencies and Java 11
Posted by David Jencks <da...@gmail.com>.
BTW, supporting CORBA, no matter which orb you pick, is quite difficult unless you happen to already be a CORBA expert, probably because you’ve already implemented significant parts of an ORB. The CORBA documentation is fairly opaque, and the semantics are quite different from what you are used to in java. Even though Yoko was used to certify IBM Liberty, getting it to work with TomEE is likely to be a significant and painful adventure.
David Jencks
> On Jul 7, 2020, at 9:53 AM, David Jencks <da...@gmail.com> wrote:
>
> Apache Yoko (part of geronimo project) is probably also a viable possibility, a few years ago it was the IBM Liberty corba implementation, and is presumably still used in OpenLiberty. I think jacorb has an incompatible license, which is why we didn’t use it in Geronimo. I don’t know about the glassfish orb.
>
> David Jencks
>
>> On Jul 7, 2020, at 1:48 AM, Zowalla, Richard <ri...@hs-heilbronn.de> wrote:
>>
>> Hi,
>>
>> I was digging around the GitHub Repo and noticed PR 664 [1], which
>> tries to prepare TomEE to be build with JDK 11 but CORBA was removed in
>> JDK 11.
>>
>> There was a disucssion 2 years ago about removing CORBA related access
>> [2]. There even exist a JIRA (TOMEE-2324) for it [3].
>>
>> If we want to build TomEE with JDK 11, we either need to (a) remove
>> CORBA dependencies (and check the implications as suggested in TOMEE-
>> 2324) or (b) add the CORBA API / IMPL back (e.g. via "jacorb" [4] or
>> via the glassfish api/impl ("glassfish-corba-orb" [5]).
>>
>> What is the plan for this? Any opinions? :)
>>
>> Best,
>> Richard
>>
>>
>> [1] https://github.com/apache/tomee/pull/664
>> [2] https://www.mail-archive.com/dev@tomee.apache.org/msg08054.html
>> [3] https://issues.apache.org/jira/projects/TOMEE/issues/TOMEE-2324
>> [4] https://www.jacorb.org/
>> [5] https://javaee.github.io/glassfish-corba/
>
Re: Follow-Up: ORB Dependencies and Java 11
Posted by David Jencks <da...@gmail.com>.
Apache Yoko (part of geronimo project) is probably also a viable possibility, a few years ago it was the IBM Liberty corba implementation, and is presumably still used in OpenLiberty. I think jacorb has an incompatible license, which is why we didn’t use it in Geronimo. I don’t know about the glassfish orb.
David Jencks
> On Jul 7, 2020, at 1:48 AM, Zowalla, Richard <ri...@hs-heilbronn.de> wrote:
>
> Hi,
>
> I was digging around the GitHub Repo and noticed PR 664 [1], which
> tries to prepare TomEE to be build with JDK 11 but CORBA was removed in
> JDK 11.
>
> There was a disucssion 2 years ago about removing CORBA related access
> [2]. There even exist a JIRA (TOMEE-2324) for it [3].
>
> If we want to build TomEE with JDK 11, we either need to (a) remove
> CORBA dependencies (and check the implications as suggested in TOMEE-
> 2324) or (b) add the CORBA API / IMPL back (e.g. via "jacorb" [4] or
> via the glassfish api/impl ("glassfish-corba-orb" [5]).
>
> What is the plan for this? Any opinions? :)
>
> Best,
> Richard
>
>
> [1] https://github.com/apache/tomee/pull/664
> [2] https://www.mail-archive.com/dev@tomee.apache.org/msg08054.html
> [3] https://issues.apache.org/jira/projects/TOMEE/issues/TOMEE-2324
> [4] https://www.jacorb.org/
> [5] https://javaee.github.io/glassfish-corba/
Re: Follow-Up: ORB Dependencies and Java 11
Posted by "Zowalla, Richard" <ri...@hs-heilbronn.de>.
Hi Daniel,
CORBA is an acronym for "Common Object Request Broker Architecture" - a
standard defined by the Object Management Group (OMG) published in 1991
(rather legacy) and which evolves outside the Java Community Process.
You can find some more details about it (and the motivation why it was
removed in Java 11 in JEP 320 [1]. Oracle provides a more (code-driven)
introduction to the topic [2].
I hope, this provides some insights into this (ancient) technology :).
Best,
Richard
[1] https://openjdk.java.net/jeps/320
[2]
https://www.oracle.com/technical-resources/articles/javase/rmi-corba.html
Am Dienstag, den 07.07.2020, 09:33 -0300 schrieb Daniel Dias Dos
Santos:
> Hello Richard,
>
> Fantastic.
> sorry for ignorance don't ask.
>
> What would CORBA be and what is it for?
> --
>
> *Daniel Dias dos Santos*
> Java Developer
> SouJava & JCP Member
> GitHub: https://github.com/Daniel-Dos
> Linkedin: www.linkedin.com/in/danieldiasjava
> Twitter: http://twitter.com/danieldiasjava
>
>
> Em ter., 7 de jul. de 2020 às 05:48, Zowalla, Richard <
> richard.zowalla@hs-heilbronn.de> escreveu:
>
> > Hi,
> >
> > I was digging around the GitHub Repo and noticed PR 664 [1], which
> > tries to prepare TomEE to be build with JDK 11 but CORBA was
> > removed in
> > JDK 11.
> >
> > There was a disucssion 2 years ago about removing CORBA related
> > access
> > [2]. There even exist a JIRA (TOMEE-2324) for it [3].
> >
> > If we want to build TomEE with JDK 11, we either need to (a) remove
> > CORBA dependencies (and check the implications as suggested in
> > TOMEE-
> > 2324) or (b) add the CORBA API / IMPL back (e.g. via "jacorb" [4]
> > or
> > via the glassfish api/impl ("glassfish-corba-orb" [5]).
> >
> > What is the plan for this? Any opinions? :)
> >
> > Best,
> > Richard
> >
> >
> > [1] https://github.com/apache/tomee/pull/664
> > [2] https://www.mail-archive.com/dev@tomee.apache.org/msg08054.html
> > [3] https://issues.apache.org/jira/projects/TOMEE/issues/TOMEE-2324
> > [4] https://www.jacorb.org/
> > [5] https://javaee.github.io/glassfish-corba/
> >
Re: Follow-Up: ORB Dependencies and Java 11
Posted by Daniel Dias Dos Santos <da...@gmail.com>.
Hello Richard,
Fantastic.
sorry for ignorance don't ask.
What would CORBA be and what is it for?
--
*Daniel Dias dos Santos*
Java Developer
SouJava & JCP Member
GitHub: https://github.com/Daniel-Dos
Linkedin: www.linkedin.com/in/danieldiasjava
Twitter: http://twitter.com/danieldiasjava
Em ter., 7 de jul. de 2020 às 05:48, Zowalla, Richard <
richard.zowalla@hs-heilbronn.de> escreveu:
> Hi,
>
> I was digging around the GitHub Repo and noticed PR 664 [1], which
> tries to prepare TomEE to be build with JDK 11 but CORBA was removed in
> JDK 11.
>
> There was a disucssion 2 years ago about removing CORBA related access
> [2]. There even exist a JIRA (TOMEE-2324) for it [3].
>
> If we want to build TomEE with JDK 11, we either need to (a) remove
> CORBA dependencies (and check the implications as suggested in TOMEE-
> 2324) or (b) add the CORBA API / IMPL back (e.g. via "jacorb" [4] or
> via the glassfish api/impl ("glassfish-corba-orb" [5]).
>
> What is the plan for this? Any opinions? :)
>
> Best,
> Richard
>
>
> [1] https://github.com/apache/tomee/pull/664
> [2] https://www.mail-archive.com/dev@tomee.apache.org/msg08054.html
> [3] https://issues.apache.org/jira/projects/TOMEE/issues/TOMEE-2324
> [4] https://www.jacorb.org/
> [5] https://javaee.github.io/glassfish-corba/
>