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