News

Weld 3.0.0.CR2

2017-3-3   release   Martin Kouba

I am very pleased to announce the release of Weld 3.0.0.CR2 (CDI 2.0-PFD). The intention is to provide the latest updates so that early adopters and reviewers can work with up-to-date reference implementation during the JCP review process.

Notable fixes and improvements:

  • InterceptionFactory handles interface correctly (WELD-2335)

  • Enable to obtain InjectionPoint metadata from within BeanConfigurator#produceWith() (WELD-2333)

  • ObserverMethodConfigurator.beanClass() should be preset to the extension class (WELD-2324)

  • Performance improvements in javax.enterprise.inject.Instance implementation (WELD-2322 and WELD-2323)

  • Don’t include built-in session and conversation scoped beans in the bean identifier index (WELD-2343)

  • Support InjectionPoint metadata injected into dependent singleton session bean (WELD-2341)

  • Logging

    • Log DEBUG info about important phases during bootstrap (WELD-2336)

    • Fix the error message when an extension observer method is static (WELD-2331)

    • Improved transactional observer methods logging in case of failure (WELD-2330)

  • Weld SE - ContainerInitialized should be fired after the container is initialized and shutdown hook is registered (WELD-2340)

  • Probe development tool

    • Extended bean archive info

    • Monitor bean instance creation

    • Do not mark a bean as unused if only injected into an observer method or disposer method

    • org.jboss.weld.probe package is vetoed

See also the release details. Thanks to everyone involved in this release!

WildFly Patch

As usual, a patch for WildFly is available. This time the target platform is WildFly 10.1.0.Final. If you’re not familiar with patching WildFly, check the FAQ.

[ Download ] [ Documentation ] [ Release notes ]

Weld 2.4.2.Final

2017-2-2   release   Martin Kouba

As you may know, CDI 2 (JSR 365) is in Public Review phase. That’s great news for early adopters. But for now, I am very pleased to announce another production-ready version of Weld 2.4 (CDI 1.2). See also the release details. Thanks to everyone involved in this release!

Warning
 There is a regression in Weld 2.4.2.Final. The problem only occurs if a Security Manager is used. However, users are encouraged to upgrade to 2.4.2.SP1 which contains a fix for the issue.

Notable fixes and improvements:

  • Added trimmed bean archives support (CDI 2.0, WELD-2314)

  • Fixed Weld SE and Weld Servlet cooperation (WELD-2260 and WELD-2262)

  • Fixed ActivateRequestContextInterceptor - align the priority with CDI 2.0, fire @Initialized and @Destroyed events (CDI 2.0, WELD-2281)

  • Fixed JDK9 build problems (WELD-2303 and WELD-2301)

  • Validation - allow to use CDI 2 rules when validating selected alternatives in bean.xml (WELD-2313)

  • Performance improvements in javax.enterprise.inject.Instance implementation (CDI 2.0, WELD-2323)

  • Illegal bean types ignored for a session bean (WELD-2315)

  • Dependency upgrade - jboss-classfilewriter to 1.2.1.Final (enables interception of default methods, see also WELD-2093)

  • Weld SE - addded useful methods from SeContainerInitializer (CDI 2.0, WELD-2316)

  • Probe development tool - extended bean archive info

WildFly Patch

As usual, a patch for WildFly is available. This time the target platform is WildFly 10.1.0.Final. If you’re not familiar with patching WildFly, check the FAQ.

[ CDI 1.2 API ] [ Download ] [ Documentation ] [ Release notes ]

Weld Tip 4 - Testing CDI/Weld apps

2017-2-1   tips   Tomas Remes, Matej Novotny

In this follow-up article of our Weld Tips series we are going to focus on testing of CDI/Weld applications. Let’s discover options for unit testing in the first part and then continue with integration testing. To set things straight - by integration testing we mean testing in some kind of container and hence in certain environment (SE, servlet, full EE server). However, no matter the environment we always make use of Arquillian integration testing framework.

Using Weld in JUnit tests

Recently we created Weld JUnit extension which uses JUnit4 @Rule to initialize a Weld SE container before each test method execution. For further information please check following blogpost.

Arquillian as the chosen framework for testing

While Arquillian may look complex at first, it is certainly worth it. Here are some of the advantages it gives you:

  • Allows usage of CDI @javax.inject.Inject directly in test classes

  • Works well with ShrinkWrap making archive creation and deployment a breeze

    • ShrinkWrap can create any type of deployment archive (WAR, JAR, even infamous EAR) with exactly the capabilities you wish it to have

    • You can use dedicated beans.xml or @Alternatives for given test case

  • Portability - allows to write one test and run it on any container

    • Arquillian only needs correct adapter; therefore, combined with Maven profiles this gives you some nice fire power for matrix testing

  • Allows for very complex testing scenarios

    • For instance you can create several deployments which you then manually (if you so wish) deploy/undeploy

    • This makes it viable even for cluster testing (session replication, failover scenarios, …​)

  • Can start the application server itself or can just connect to running one

In fact writing tests with Arquillian is quite straightforward. It’s basically about right usage of right annotations. Basic test could like this: [ source, java ]

 package org.arquillian.example;
    
     import javax.inject.Inject;
     import org.jboss.arquillian.container.test.api.Deployment;
     import org.jboss.arquillian.junit.Arquillian;
     import org.jboss.shrinkwrap.api.ShrinkWrap;
     import org.jboss.shrinkwrap.api.asset.EmptyAsset;
     import org.jboss.shrinkwrap.api.spec.JavaArchive;
     import org.junit.Assert;
     import org.junit.Test;
     import org.junit.runner.RunWith;
    
     @RunWith(Arquillian.class)
     public class GreeterTest {
    
         // This static method builds the virtual test deployment archive
         @Deployment
         public static JavaArchive createDeployment() {
             return ShrinkWrap.create(JavaArchive.class)
                 .addClass(Greeter.class)
                 .addAsManifestResource(EmptyAsset.INSTANCE, "beans.xml");
         }
    
         @Inject
         Greeter greeter;
    
         @Test
         public void should_create_greeting() {
            Assert.assertEquals("Hello, Earthling!", greeter.createGreeting("Earthling"));
         }
     }

If you are a complete Arquillian rookie, you might want to look at their Getting started guide. Should you just need an inspiration, you needn’t look any further than our testsuite. To support the though of Arquillian usefulness for CDI/Weld testing, we may also point out that even CDI TCK tests use it.

Now, let’s take a look at different environments and then round it up with Arquillian Weld Embedded container, which can be used in each and every environment.

Java EE application server

When you want to test your application in Java EE application server you basically need to create your test deployment archive, deploy it, execute the test and undeploy the archive. As stated above, ShrinkWrap covers the archive creation (typically WAR or EAR). When it comes to deployment/undeployment, Arquillian controls that, unless you take the reins and control it yourself - just keep an eye for dangling deployments. You also get to chose between using so called managed container, where Arquillian starts and stops the desired container for you, and remote container where Arquillian tries to connect to already running container. Since we are talking Java EE application server, you can use CDI out of the box. Just pay attention to test mode you are using. You can check available Arquillian container adapters here.

For example to use Arquillian WildFly Managed container you need to define following dependency: [ source, xml ]

               <dependency>
                       <groupId>org.wildfly.arquillian</groupId>
                       <artifactId>wildfly-arquillian-container-managed</artifactId>
                       <version>1.1.0.Final</version>
                       <scope>test</scope>
                   </dependency>

Servlet environment

In basic Servlet environment you need to deploy all the dependencies of Weld Servlet integration (as CDI API, Interceptors API, etc.) to your Servlet container and thus embedded container option could be sufficient. As you can see Arquillian offers embedded container adapters for all well known Servlet containers such as Tomcat, Jetty and Undertow.

For example to use Arquillian Embedded Tomcat container you need to define following dependency: [ source, xml ]

               <dependency>
                        <groupId>org.jboss.arquillian.container</groupId>
                        <artifactId>arquillian-tomcat-embedded-8</artifactId>
                        <version>1.0.0.CR8</version>
                        <scope>test</scope>
                    </dependency>

Java SE environment

Java SE is not effectively a container, however it could be very handy to have an option to easily configure classpath elements of your test. This is exactly what Arquillian container SE offers. With this extension you can build your test classpath and the test executes remotely over JMX in new isolated JVM process. You can find basic information in README or you can take look into already mentioned CDI TCK tests where you can find SE testgroup which involves all SE related tests.

The maven dependency for this extension looks like this: [ source, xml ]

               <dependency>
                       <groupId>org.jboss.arquillian.container</groupId>
                       <artifactId>container-se-managed</artifactId>
                       <version>1.0.1.Final</version>
                   </dependency>

Arquillian Weld Embedded container

First of all - this test container is suitable in situations when you know you don’t need to work with full Java EE application server and you are OK with dummy mock EJB, JTA, JPA etc. services. As stated in the beginning of this article, you can use it for any environment but you have to keep it mind, that other technologies/services will be mocked only. By default, this container operates in SE mode, as you don’t need to mock anything there, but you can use a system property (Denvironment=EE) or a programmatic approach in order to make it work in other environments. For full list of supported environments, see Environments.java. We recommend you to take a glance at README file - especially those few lines about flat deployment structure (this means this container is not very suitable for testing EAR deployments) and configuration property for setting testing environment.

The maven dependency for this container could look like this: [ source, xml ]

               <dependency>
                        <groupId>org.jboss.arquillian.container</groupId>
                        <artifactId>arquillian-weld-embedded</artifactId>
                        <version>2.0.0.Beta4</version>
                        <scope>test</scope>
                    </dependency>

Weld 3.0.0.CR1

2017-1-23   release   Martin Kouba

I am very pleased to announce the release of Weld 3.0.0.CR1 (aligned with CDI 2.0-PFD). See also the release details. Thanks to everyone involved in this release! This version of Weld will be part of the JSR 365 Approval Ballot (watch CDI spec website for news). The Beta1 version of Weld 3 turned out to be sufficiently stable and so the first release candidate is mostly dedicated to cleanup and minor optimizations. We would like to release Weld 3.0.0.Final (stable version of CDI 2.0) in early February.

WildFly Patch

As usual, a patch for WildFly is available. This time the target platform is WildFly 10.1.0.Final. If you’re not familiar with patching WildFly, check the FAQ.

[ Download ] [ Documentation ] [ Release notes ]

Weld 3.0.0.Beta1

2016-12-19   release   Martin Kouba

I am very pleased to announce the first Beta version of Weld 3.0.0 (CDI 2.0). See also the release details. Thanks to everyone involved in this release!

This is an important milestone. CDI 2.0 is now considered "feature complete" and so the next Weld 3 versions should be mostly dedicated to cleanup and optimization. The next version will be Weld 3.0.0.CR1 (ETA in mid January). Finally, we would like to release Weld 3.0.0.Final in early February.

New and noteworthy

  • javax.enterprise.inject.spi.InterceptionFactory implementation (WELD-2257)

  • ProcessSyntheticObserverMethod container lifecycle event (WELD-2279)

  • BeforeDestroyed event fired before a context is actually destroyed (WELD-2269)

  • "trimmed" bean archives (WELD-2268)

  • context control - ActivateRequestContext interceptor binding (WELD-2267) and RequestContextController built-in bean (WELD-2266)

  • ProcessSyntheticBean container lifecycle event (WELD-2265)

  • few proposals did not make it into CDI 2.0 and so we enhanced the Weld API:

    • org.jboss.weld.inject.WeldInstance (already part of Weld 2.4 API)

    • org.jboss.weld.interceptor.WeldInvocationContext allows to obtain a set of interceptor bindings for a lifecycle callback, business method, timeout method, or constructor (see also CDI-468)

    • org.jboss.weld.bootstrap.event.WeldAfterBeanDiscovery allows to obtain an InterceptorConfigurator to configure a new Interceptor bean

WildFly Patch

As usual, a patch for WildFly is available. This time the target platform is WildFly 10.1.0.Final. If you’re not familiar with patching WildFly, check Markus’s tutorial.

[ Download ] [ Documentation ] [ Release notes ]

Previous 1 2 ...9 10 11 ...17 18 Next