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/11/01 13:22:17 UTC

Re: Follow-Up: ORB Dependencies and Java 11

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
> > 
> > 
> >