Comments (10)
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 ofProxyServices
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 inmain
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.
Related Issues (20)
- TCK challenge for addressing Jakarta EE 10 Platform TCK signature test failures on Java 21 HOT 3
- [tck-challege] Jakarta EE Core TCK's cdi-lite-tck-suite.xml out of sync with CDI's tck-tests.xml HOT 3
- TCK Challenge : Servlet URLClient getRequestedSessionIdTest1 test involving session management using URL rewriting doesn't provide option to enable URL rewriting HOT 6
- Add new feature for ignoring classes in java.* via https://github.com/jtulach/netbeans-apitest signature test tool HOT 1
- Revisit htmlunit usage in CDI TCK HOT 3
- TCK failures with refactored JSP TCK HOT 4
- Investigate impact of removing support for optional EJB 2.x features (homes, CIs, etc.) HOT 6
- TCK Challenge for JDBC TCK tests that convert String values like `999999999999999` to Float that fail on Java 21 HOT 8
- Check if any additional licenses are missing from the project LICENSE.md file
- WebSocket TCK 2.2.0 zip is incorrect HOT 1
- WebSocket 2.2.0 TCK is STILL incorrect HOT 1
- Jacc code can be removed from the platform TCK HOT 1
- Use Maven Wrapper HOT 1
- Remove optional TCK tests from the EE 11 Platform TCK
- Staged EL TCK contains reference to unavailable SNAPSHOT version of parent HOT 1
- Staged JSP 4.0.0 TCK has missing dependency (and unexpwected HOT 1
- Staged JSP 4.0.0 TCK has missing dependency and unexpected Maven coordinates HOT 4
- Old DTDs/Schema in deployment descriptors of Tags/Pages/Servlet/Assembly Platform TCK tests HOT 22
- merge master branch changes to tckrefactor branch for EE 11 release
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from platform-tck.