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 < > > [email protected]> 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 > > > >
smime.p7s
Description: S/MIME cryptographic signature
