> > Given that removing these APIs would cause TCK issues in these cases, I > have been reticent to remove the APIs. At this point, I view this to be > in a holding pattern until we have a very strong confidence that it > won't break EE implementations. >
I have been exploring the effects of removing these APIs on JBoss Wildfly 20, the latest version to support Java EE 8. The Wildfly implementations of EJBContext.getCallerIdentity and EJBContext.isCallerInRole(Identity) both throw unconditionally, respectively UnsupportedOperationException and IllegalStateException (?). My first attempt to start Wildfly 20 failed on Java 17, because of encapsulation issues related to reflective access to proxies. That was easily fixed by upgrading the 'jboss-ejb-client' dependency to a version where this issue is fixed, and then building 20.0.2.Final-SNAPSHOT. After this change, Wildfly started just fine with my 21-internal JDK where the APIs have been removed. I then went on to deploy and run the 'ejb-security-context-propagation' sample project [1]. This sample uses EJBContext, so it allows testing of the removed APIs. The existing sample rightfully does not call any of the deprecated methods. The sample client runs just fine against the 21-internal Wildfly server. I then went on to add a call to 'EJBContext.getCallerIdentity()'. Since the method throws unconditionally, the return type is never resolved, so we get the expected UnsupportedOperationException (so, no ClassNotFoundException or similar): Exception in thread "main" javax.ejb.EJBException: > java.lang.UnsupportedOperationException: WFLYEJB0246: getCallerIdentity is > deprecated > at org.jboss.as.ejb3@20.0.2.Final-SNAPSHOT > //org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:266) Based on this testing, it seems removing 'Identity' and related APIs will have no observable effect on Wildfly at runtime. Building will still need to happen using a JDK containing the APIs. I wanted to explore this scenario also on Glassfish, but it seems the last version of Glassfish supporting Java EE 8 cannot even start on Java 11 (which removed javax.annotation.PostConstruct) and I did not investigate fixing that. It seems to me that other Java EE 8 implementations could achieve similar results by also throwing UnsupportedOperation in their 'EJBContext.getCallerIdentity()' implementation, either unconditionally, or perhaps just when then detect that they are running on a JRE where the Identity' class is removed. To summarize, I'm hopeful that removing 'Identity' and friends have limited effect on Java EE 8 implementations and apps and that workarounds exist for problems which may occur. Apps using the deprecated APIs in EJBContext would of course need to be updated, but that's a straightforward replacement job. (Based on my observations of GlassFish and Wildfly, it is not at all clear to me that they have any plans of fixing their Java EE 8 implementations to work on Java 11 or 17, regardless of the API removal discussed here) Thanks, Eirik.
