arquillian / arquillian-container-weld Goto Github PK
View Code? Open in Web Editor NEWArquillian Weld Containers
License: Apache License 2.0
Arquillian Weld Containers
License: Apache License 2.0
There is regexp for ".*/beans.xml". This is not 100% correct because the dot should be escaped.
At least CDI and Weld should be updated to their latest respective releases.
Other Jakarta deps might also be affected; this isn't anyhow breaking but it's good practice to have that updated to non-beta versions at least :)
Create an ftests module to help demonstrate features of the container.
I think it would be a good idea if we had a Travis PR builder for this repo. This way incoming PRs can be tested and confirmed working/not working.
@tremes @bartoszmajsak what do you think?
I'm hitting the following issue when trying to run an arquillian CDI test with arquillian-weld-ee-embedded-1.1:1.0.0.CR3
java.lang.IllegalAccessError: tried to access method com.google.common.collect.MapMaker.makeComputingMap(Lcom/google/common/base/Function;)Ljava/util/concurrent/ConcurrentMap; from class org.jboss.weld.logging.WeldMessageConveyor
at org.jboss.weld.logging.WeldMessageConveyor.<init>(WeldMessageConveyor.java:61)
at org.jboss.weld.logging.WeldMessageConveyerFactory.getDefaultMessageConveyer(WeldMessageConveyerFactory.java:27)
at org.jboss.weld.logging.LoggerFactory.<init>(LoggerFactory.java:37)
at org.jboss.weld.logging.LoggerFactory.loggerFactory(LoggerFactory.java:51)
at org.jboss.weld.bootstrap.WeldBootstrap.<clinit>(WeldBootstrap.java:124)
at org.jboss.arquillian.container.weld.ee.embedded_1_1.mock.TestContainer.<init>(TestContainer.java:211)
at org.jboss.arquillian.container.weld.ee.embedded_1_1.WeldEEMockContainer.deploy(WeldEEMockContainer.java:93)
at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:161)
at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:128)
at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.executeOperation(ContainerDeployController.java:271)
at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deploy(ContainerDeployController.java:127)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
at org.jboss.arquillian.container.impl.client.container.DeploymentExceptionHandler.verifyExpectedExceptionDuringDeploy(DeploymentExceptionHandler.java:50)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createDeploymentContext(ContainerDeploymentContextHandler.java:78)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$1.perform(ContainerDeployController.java:95)
at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$1.perform(ContainerDeployController.java:80)
at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.forEachDeployment(ContainerDeployController.java:263)
at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.forEachManagedDeployment(ContainerDeployController.java:239)
at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deployManaged(ContainerDeployController.java:79)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
at org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:101)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeClass(EventTestRunnerAdaptor.java:87)
at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:201)
at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:422)
at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54)
at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:218)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:166)
at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124)
at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
@bartoszmajsak I'm not sure if we're still using github issues or JIRA, feel free to redirect!
The classloader around service loaders doesn't pick up all classes when using TCCL.
Given I have a ShrinkWrap archive that creates a WAR, and two JAR files (jarA and jarB), when inside jarB I use ServiceLoader.load(SomeClass, TCCL)
I get back all services defined in the WAR, jarA and jarB.
The contents of jarA are ignored.
If you check out https://svn.apache.org/repos/asf/geronimo/components/config/trunk/ and run mvn clean install -PWeld3
you'll see that several tests fail due to missing config properties.
The config properties are not loaded as the service loader isn't finding the relevant services. Debug DefaultConfigBuilder.build
to see the service loader's behavior.
The recent change I made to account for empty beans.xml
has a flaw in it.
When checking for presence of bean defining annotation, I am using Class#isAnnotationPresent
which also checks for indirectly present (inherited) annotations. This is contradictory to CDI specification as only declared annotations should count.
Sadly, this means some of the fixes we did for CDI TCKs based on testing were incorrect. Good news is, they should be fixed due to jakartaee/cdi-tck#314 as I am now running the same test against WFLY and seeing these mistakes.
CC @Ladicek ^^
I'll put this on my TODO list and fix it in coming days.
Take a look at https://github.com/hammock-project/microprofile-samples/blob/7d9a367f12922e4eaff49d5dbd967578d045f016/microprofile-sample-canonical/src/test/java/io/microprofile/sample/canonical/rest/TopCDsEndpointTest.java#L70 and https://github.com/hammock-project/hammock/blob/d3a134e372cd0c35001f73ff8132c7ee705837f0/web-spi/src/main/java/ws/ament/hammock/web/spi/StartWebServer.java
It seems that the start of an app scope event isn't working quite right, or maybe there's some hidden thing I'm missing.
To clarify, to get my webserver to start, I had to manually call the method. It works fine when using an uber-jar though (against Weld 2.3.5)
If I am looking correctly, then this container always follows all
discovery mode.
This will be a problem for next Weld (5) and CDI (4) versions because of https://issues.redhat.com/browse/WELD-2677 and jakartaee/cdi#500.
From first glance, we will need to tweak this method to pick up the discovery mode from beans.xml
and handle it accordingly.
I am not entirely sure why this container performs so much of discovery on its own but I suppose it has something to do with the flat deployment and merging of beans.xml.
I will try and look into what needs doing.
It looks like a release of Beta5 was done, but it was never synchronized to maven central?
When executing a test with arquillian-weld-se-embedded-1.1
with Weld version 2.1.1.Final
, the following statement is logged:
WARN org.jboss.weld.Bootstrap - WELD-000135: Legacy deployment metadata provided by the integrator. Certain functionality will not be available
This log statement is written by the following code in weld-core-impl
:
public class WeldStartup {
...
public WeldRuntime startContainer(String contextId, Environment environment, Deployment deployment) {
...
if (deployment instanceof CDI11Deployment) {
registry.add(BeanManagerLookupService.class, new BeanManagerLookupService((CDI11Deployment) deployment, bdaMapping.getBdaToBeanManagerMap()));
} else {
BootstrapLogger.LOG.legacyDeploymentMetadataProvided();
}
To avoid having that warning logged, the Deployment
instance created in:
public class WeldSEContainer implements DeployableContainer<WeldSEConfiguration>
{
...
public ProtocolMetaData deploy(Archive<?> archive) throws DeploymentException
{
final ShrinkwrapBeanDeploymentArchive beanArchive = archive.as(ShrinkwrapBeanDeploymentArchive.class);
final org.jboss.weld.bootstrap.spi.Deployment deployment = new org.jboss.weld.bootstrap.spi.Deployment()
{
...
}
should implement the org.jboss.weld.bootstrap.spi.CDI11Deployment
interface.
I've noticed that the structure has been changed with 2.0.0
version. What happened with the other modules? If it's desired we should probably also remote -root
in such a case.
Also the name of -root
pom is a bit misleading and it results with a weird blog post title and module name on arquillian.org
- Arquillian Container Weld Root POM 2.0.0.Beta3 Released
.
When using org.jboss.arquillian.container:arquillian-weld-embedded:3.0.2.Final we have an error
The reason is additional dependency org.jboss.weld:weld-lite-extension-translator:5.0.0.Alpha1.
Version org.jboss.arquillian.container:arquillian-weld-embedded:3.0.1.Final is complaint with CDI 3.0, but this new dependency in 3.0.2 make it incompatible with it. This new dependency is part of implementation CDI 4.0
Even if my app does not use JTA, arquillian-weld-embedded requires JTA on the classpath. No impl required, but the jar must be there.
If it's a required dependency, it should be properly marked in the pom.
Weld contains the implementation of extension translator from Lite extensions to portable extensions.
However, this is automatically included only in SE and servlet and this container does its own bootstrap and as such needs to explicitly include it.
Since there is a circular dep between Weld and this, I will have to first release Weld 5 Alpha and then update it here.
I suppose I'll have that done today or the next workday but we'll need another release then.
While inside a Weld archive WAR file, the classloader used is unable to locate /META-INF/somefile.properties
.
Searching for /META-INF/somefile.properties
and META-INF/somefile.properties
should work fine.
Looking up META-INF/somefile.properties
works, but having the leading /
causes it to fail
The greeter test from the examples, testing simple injection using weld embedded
works fine with 3.0.0.Alpha2 but fails on 3.0.0.Final with java.lang.NoClassDefFoundError: jakarta/ejb/Singleton
Tests to run without failing
Tests fail with
java.lang.NoClassDefFoundError: jakarta/ejb/Singleton
at org.jboss.arquillian.container.weld.embedded.Utils.<clinit>(Utils.java:81)
at org.jboss.arquillian.container.weld.embedded.WeldMockContainer.deploy(WeldMockContainer.java:106)
...
Caused by: java.lang.ClassNotFoundException: jakarta.ejb.Singleton
at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:636)
Using test:
@ExtendWith(ArquillianExtension.class)
public class GreeterTest {
@Deployment
public static JavaArchive createDeployment() {
return ShrinkWrap.create(JavaArchive.class)
.addClasses(
Greeter.class,
PhraseBuilder.class)
.addAsManifestResource(EmptyAsset.INSTANCE, "beans.xml");
}
@Inject
private Greeter greeter;
@Test
public void should_create_greeting() {
assertThat(greeter.createGreeting("Earthling")).isEqualTo("Hello, Earthling!");
greeter.greet(System.out, "Earthling");
}
}
With dependencies:
<dependency>
<groupId>org.jboss.arquillian</groupId>
<artifactId>arquillian-bom</artifactId>
<version>1.7.0.Alpha10</version>
<type>pom</type>
<scope>import</scope>
</dependency>
<dependency>
<groupId>org.jboss.arquillian.container</groupId>
<artifactId>arquillian-weld-embedded</artifactId>
<version>3.0.0.Final</version>
</dependency>
I can resolve the issue by including the dependency:
<dependency>
<groupId>jakarta.ejb</groupId>
<artifactId>jakarta.ejb-api</artifactId>
</dependency>
But since it works without this in Alpha2, this feels like a bug.
Tested using JDK 16 and jakartaee-api 9.0.0
The license appears to be wrong on the artifact. Shouldn't it be apache license?
https://www.versioneye.com/java/org.jboss.arquillian.container:arquillian-weld-embedded/2.0.0.Beta2
When trying to test with alternatives if the beans.xml uses xmlns="http://xmlns.jcp.org/xml/ns/javaee" they will be ignored. It will work if we use xmlns="http://java.sun.com/xml/ns/javaee" instead. However I have read that it should be used its from jcp since from its from sun is and old version.
The used POM is https://gist.github.com/alacambra/4d302ee4cd5e55daedd3, profile arquillian-weld-ee-embedded.
The working beans.xml is: https://gist.github.com/alacambra/fe862f3cb11f0fd3e249
And the not working beans.xml is: https://gist.github.com/alacambra/13f9a811e368ed9f5471
When my test app calls getResource("META-INF/someResource.txt")
on the web app's classloader, it fails to find anything - even though the file exists in a JAR file in the WEB-INF/lib directory. When I search for the same resource using getResources
, the returned set of URLs includes the URL to the resource in the WEB-INF/lib JAR file.
The getResource
method should search JAR files in the WEB-INF/lib directory after searching the WEB-INF/classes directory.
The getResource
method only searches the WEB-INF/classes directory.
loader.getResources("META-INF/someResource.txt")
- this will return an Enumeration with a URL to the resource - all good so far.loader.getResource("META-INF/someResource.txt")
- this will fail.I think the problem is here:
Unlike the getResources
method, this method just adjusts the name for searching the WEB-INF/classes directory and then delegates to the super class. I think it should follow the same pattern as getResources
and search the JAR files in the WEB-INF/lib directory.
TestContainer
uses BeanManager.fireEvent
which has been removed in latest CDI API (4.0.0.Alpha1).
We will need to adapt that.
However, note that in order to pass tests, we will also need a Arq. core update for similar reasons - see arquillian/arquillian-core#339
Weld and CDI API don't need to be updated immediately (can't actually because of circular dep).
I will send a draft PR that captures what we can fix and which should be updated once Arq. core is out.
Multi-release jar breaks arquillian.
I got this exception using Arquillian with an MR-jar:
java.lang.NoClassDefFoundError: io/smallrye/context/Jdk9CompletableFutureWrapper (wrong name: META-INF/versions/9/io/smallrye/context/Jdk9CompletableFutureWrapper)
...
at org.jboss.arquillian.container.weld.embedded.Utils.filterClasses(Utils.java:182)
at org.jboss.arquillian.container.weld.embedded.Utils.findBeanClasses(Utils.java:149)
at org.jboss.arquillian.container.weld.embedded.WeldMockContainer.deploy(WeldMockContainer.java:109)
at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:151)
at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:118)
at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.executeOperation(ContainerDeployController.java:239)
at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deploy(ContainerDeployController.java:118)
Looks at the source code in question, I was able to add a beans.xml
to avoid scanning those classes as a workaround:
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:weld="http://jboss.org/schema/weld/beans"
xsi:schemaLocation="
http://java.sun.com/xml/ns/javaee http://docs.jboss.org/cdi/beans_1_0.xsd
http://jboss.org/schema/weld/beans http://jboss.org/schema/weld/beans_1_1.xsd">
<weld:scan>
<!-- Don't let Arquillian choke on MR-Jars -->
<weld:exclude weld:pattern="META-INF\.versions\..*"></weld:exclude>
</weld:scan>
</beans>
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.