3 EJB30 test failures in Platform TCK 8.0.2 when run in JDK11+ about platform-tck HOT 10 CLOSED

I am unable to reproduce this on WFLY with similar test so take the information below with a pinch of salt as I am unable to debug it.

@alwin-joseph what's your implementation of ProxyServices? It seems WFLY passes this because it has its own implementation of ProxyServices and from your exception I guess that you are using the default one (org.jboss.weld.bean.proxy.util.WeldDefaultProxyServices)?
The default one is there mainly for Weld SE although I have no idea (apart from WFLY) how other EE servers approach class defining for CDI. I would expect that servers use their own impls because they are likely to need to perform some CL handling anyway and in that case delegating to ClassLoader#defineClass is the most straightforward way to solve these issues.

Apart from this, the scenario occurs only because the EJB bean uses @Local to declare an interface it doesn't directly implement. This triggers(here) the createCompoundProxyName method in Weld that you noticed. Ultimately, Weld will attempt to use MethodHandles.Lookup#defineClass to define the class and fail because the lookup will be based on StatelessEqualsBean which will have different package then the bean being defined.

from platform-tck.

WFLY was running in JDK11+? JDK11/17 is where the issue is reproduced for WLS.

Yes, that version of Weld still had to use MR JAR release so you need JDK 11+ to have access to JPMS and modular approach to class defining via MethodHandles.Lookup.
Therefore, there are two versions of the default impl:

• JDK 8 -> https://github.com/weld/core/blob/3.1.9.Final/impl/src/main/java/org/jboss/weld/bean/proxy/util/WeldDefaultProxyServices.java
• JDK 11+ -> https://github.com/weld/core/blob/3.1.9.Final/impl/src/main/java11/org/jboss/weld/bean/proxy/util/WeldDefaultProxyServices.java

The main difference between classical ClassLoader and MethodHandles.Lookup is that ClassLoader#defineClass can define classes in (almost) arbitrary package whereas MethodHandles.Lookup can do so only in the package in which you did the lookup - that is the source of the problem you are seeing. Try debugging WeldDefaultProxyServices to see that.

Yes org.jboss.weld.bean.proxy.util.WeldDefaultProxyServices is being used here. Will you be able to point me to the implementation of `ProxyServices in WFLY (https://github.com/wildfly/wildfly?) .

Here is a link to the current version which is for Weld 5, but it's very similar.

from platform-tck.

FYI I have created a PR draft that attempts to fix this - weld/core#2895
I am still not completely sure it won't interfere elsewhere, but so far it seems like an isolated case for EJB beans with @Local.
The test I added is indirect, as I am unable to verify class defining due to the reasons I mentioned above, but still verifies that the proxy now has package of the bean impl and not the interface.

from platform-tck.

Closing this as the fix is provided in weld. Thanks much @manovotn! Appreciate your help.

from platform-tck.

I am unable to reproduce this on WFLY with similar test so take the information below with a pinch of salt as I am unable to debug it.

WFLY was running in JDK11+? JDK11/17 is where the issue is reproduced for WLS.

@alwin-joseph what's your implementation of ProxyServices? It seems WFLY passes this because it has its own implementation of ProxyServices and from your exception I guess that you are using the default one (org.jboss.weld.bean.proxy.util.WeldDefaultProxyServices)?

Yes org.jboss.weld.bean.proxy.util.WeldDefaultProxyServices is being used here. Will you be able to point me to the implementation of `ProxyServices in WFLY (https://github.com/wildfly/wildfly?) .

from platform-tck.

createCompoundProxyName is invoked with below parameters

• contextId: STATIC_INSTANCE
• typeInfo: org.jboss.weld.util.Proxies$TypeInfo@61a3134c
• bean:
  Session bean [class com.sun.ts.tests.ejb30.lite.view.equals.StatelessEqualsBean with qualifiers [@Any @Default]; local interfaces are [StatelessEqualsBean, BusinessLocalIF1, BusinessLocalIF2, AnnotatedLocalBusinessInterface1]
• name: StatelessEqualsBean$

The proxyPackage of the bean is set(incorrectly for this scenario) here in the first iteration.
with

• typeInfo.getInterfaces =
  [interface com.sun.ts.tests.ejb30.common.busiface.AnnotatedLocalBusinessInterface1,
  interface com.sun.ts.tests.ejb30.common.busiface.BusinessLocalIF1,
  interface com.sun.ts.tests.ejb30.common.busiface.BusinessLocalIF2]
• type = interface com.sun.ts.tests.ejb30.common.busiface.AnnotatedLocalBusinessInterface1
• declaringClass (= type.getDeclaringClass) is null
• proxyPackage = null

Hence this line sets the proxyPackage after obtaining the package name of AnnotatedLocalBusinessInterface1 from this map. From the logs I see that the map does have all the 3 interfaces and the bean class correctly populated, no issue with that.

So effectively the bean gets the proxyPackage of interface.

from platform-tck.

Yes, I am aware of all that. However, for some other cases, this behavior as desired as described in https://issues.redhat.com/browse/WELD-2666 (and the linked PR) which introduced this bit of code.

So effectively the bean gets the proxyPackage of interface.

This isn't necessarily wrong, note that if you define classes with plain ClassLoader, this combination of package and class is perfectly valid.

I am trying to figure out a way to change the package of this proxy only for this particular case - so far my investigation indicates that this happens purely for EJB beans declaring a @Local interface they don't implement.
However, note that even if we decide to fix this, it would be for Weld 5 and 6. Weld 3 is no longer actively developed.

from platform-tck.

I see the PR with fix is merged. Thanks a lot for working on this.

I was looking at the prospects of extending this fix to WELD versions 3 & 4 (weld-core-impl jar).

As you clarified earlier,

However, note that even if we decide to fix this, it would be for Weld 5 and 6. Weld 3 is no longer actively developed.

are there any conditions which if satisfied can trigger updates in non-active versions(3&4).

In other option, should we be mindful of anything If we decide to fork the weld/core repo and apply the fix in the PR. I was thinking to do as below in the order

• fork weld/core
• apply the fix to impl/src/main/java/org/jboss/weld/bean/proxy/ProxyFactory.java as in the PR
• replace all 3.1.10-SNAPSHOT with 3.1.10
• mvn clean install (from root or /impl)
• Use impl/target/weld-core-impl-3.1.10.jar in our server implementation.

from platform-tck.

Note that you can still implement your own ProxyServices to bypass this entirely. That isn't an option for you?

are there any conditions which if satisfied can trigger updates in non-active versions(3&4).

There aren't any formal conditions for this. Jakarta EE 8 is now 4 years ago and JDK 11 is 5y.
TBH I am fairly surprised weblogic hasn't encountered this earlier - those EJB tests don't look like anything that's been tempered with recently.

In other option, should we be mindful of anything If we decide to fork the weld/core repo and apply the fix in the PR. I was thinking to do as below in the order

Yes, you could do that.
Probably compare the ProxyFactory file with what's in main branch now to be sure there aren't any other side effects, but tests should tell you if that's the case.

from platform-tck.

Note that you can still implement your own ProxyServices to bypass this entirely. That isn't an option for you?

It was suggested not to use this approach for this release.

are there any conditions which if satisfied can trigger updates in non-active versions(3&4).

There aren't any formal conditions for this. Jakarta EE 8 is now 4 years ago and JDK 11 is 5y. TBH I am fairly surprised weblogic hasn't encountered this earlier - those EJB tests don't look like anything that's been tempered with recently.

I think this issue might have started after introducing impl/src/main/java11/org/jboss/weld/bean/proxy/util/WeldDefaultProxyServices.java 2 years back in 3.1 ; weblogic would have been using an older version of WELD before that.

In other option, should we be mindful of anything If we decide to fork the weld/core repo and apply the fix in the PR. I was thinking to do as below in the order

Yes, you could do that. Probably compare the ProxyFactory file with what's in main branch now to be sure there aren't any other side effects, but tests should tell you if that's the case.

Thanks! We will do this.

from platform-tck.