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