News

Weld meets JUnit 5

2017-12-19   junit , testing , weld-se   Matej Novotny

In this article I want to bring weld-junit into light. You might have heard about or, better still, used our extension for JUnit 4 which has been around for some time now. But after getting ourselves acquainted with JUnit 5, we decided we should create another one for JUnit 5. In the sections below I will try to introduce the basic usage and ideas behind it, for more in depth information, you can glance the readme file residing directly in the repository.

GAV Coordinates

Here are group and artifact IDs you need to grab the artifact for Maven projects:

<dependency>
      <groupId>org.jboss.weld</groupId>
      <artifactId>weld-junit-parent</artifactId>
      <version>${weld.junit.version}</version>
    </dependency>

First Steps

You can use the extension as you would any other in JUnit 5, via @ExtendWith from JUnit library along with the name of our extension - org.jboss.weld.junit5.WeldJunit5Extension. Alternatively, there is a shorter annotation @org.jboss.weld.junit5.EnableWeld. Both of these can be used on class and method level.

Hence your test could look like this:

@EnableWeld
    public class InjectionWithWeldTest {
    
      @Inject
      BarBean beanAsField;
    
      @Test
      public void testThatItWorks(FooBean beanAsParam) {
        assertNotNull(beanAsParam);
        beanAsParam.ping();
        assertNotNull(beanAsField);
        beanAsField.ping();
      }
    
    }

Behind the scenes, Weld will bootstrap SE container for each test container invocation and tear it down afterwards (works for both, per-method and per-class lifecycle). As you might have guessed, Weld will also automatically inject into any fields within the test class which you annotated with @Inject. Furthermore, it will attempt to resolve parameters in your test methods in very much the same way. But beware, by default Weld will only scan classes from within the test package! With this in mind, you can play around with beans to your liking.

Dude, Where Is My Container?

Good point, when working with Weld SE you normally have the power to customize container bootstrap and, once running, to query it for beans, fire events and so on. And you shall retain that right!

Only you are going to need a public field with type org.jboss.weld.junit5.WeldInitiator which you annotate with @org.jboss.weld.junit5.WeldSetup. This class has a bunch of static method which will allow you to customize the boostrap and it also works as a handle to grasp the WeldContainer running below.

Too much talk, not enough code, so here we go:

@ExtendWith(WeldJUnit5Extension.class)
    public class WeldJUnit5CustomizedTest {
    
      @WeldSetup
      public WeldInitiator weld = WeldInitiator.of(WeldInitiator.createWeld()
                                               .alternatives(FooAlternative.class)
                                               .beanClasses(Foo.class, FooAlternative.class)
                                               .enableInterceptors(MyInterceptor.class));
    
      @Inject
      Foo bean; // this will be FooAlternative in the end
    
      @Test
      public void testWeldContainerUsage() {
        weld.event().select(MyPayload.class).fire(new MyPayload());
        weld.select(Foo.class).isResolvable();
      }
    }

Help, I Am Stuck With JUnit 4

No problems, we got you covered, check out our JUnit 4 extension.

They are both very similar and easy to master. The only notable difference is that in JUnit 4 you always need the initiator class - org.jboss.weld.junit4.WeldInitiator.

What If I Would Like To…​

If you’re stuck and need a helping hand, we are listening on the usual channels - mailing list, Stack Overflow, Gitter, IRC, GitHub.

It might also be the case that we forgot about something quite important, so don’t hesitate to reach to us through those channels, or open a GitHub issue straight away. We are happy for any kind of feedback we can get.


Weld 2.4.6.Final

2017-12-18   release   Matej Novotny

Time has come for another round of Weld 2.4 bugfix release. But that’s not all - this time there is also new API to go along with this release - Weld API 2.4.SP2.

Among other things you can now obtain interceptor binding from javax.interceptor.InvocationContext, use enriched version of javax.enterprise.event.Event or select javax.enterprise.inject.Instance based on java.lang.reflect.Type.

Notable fixes and improvements:

  • Weld Core:

    • Improved subclass generation mechanism for generic interceptors (WELD-2414)

    • Corrected proxy creation for signed classes (WELD-2425)

    • Correct InjectionPoint bean behaviour when used within AfterBeanDiscovery observer (WELD-2429)

  • Weld SE

    • There are now multiple convenient error-proof methods to quickly configure SE container (WELD-2426)

      • Weld.enableDevMode(), Weld.scanClasspathEntries(), …​

  • Weld API/SPI

    • WeldInstance has several improvements

      • It now allows you to select() beans based on java.lang.reflect.Type (WELD-2427)

      • WeldInstance.Handler had become lazy which means you can now iterate/filter/sort WeldInstance without actually instantiating beans (WELD-2258)

    • There is new interface in the API - WeldEvent - which can be used in place of well known Event but allows you narrow down event type by using select() with java.lang.reflect.Type (WELD-2427)

    • API now contains WeldInvocationContext, an enriched version of javax.interceptor.InvocationContext which allows to obtain interceptor binding (WELD-2433)

      • There is also a String key used to obtain interceptors binding directly from InvocationContext (WELD-2436)

      • In order to learn more, please refer to (our documentation)

  • Other

    • Probe - fixed NPE which might occur when bean had @Priority but no other annotation (WELD-2432)

    • All the API changes should now be documented within Weld docs

WildFly Patch

As usual, a patch for WildFly 11.0.0.Final is available. If you’re not familiar with patching WildFly, check the FAQ.


Weld 3.0.2.Final

2017-11-23   release   Matej Novotny

Weld 3.0.2.Final is out and targetting WildFly 11! Ever wished you could select events and instances in a truly generic way using just java.lang.reflect.Type? Looking for easier way to configure SE container? We have a bunch of bugfixes and improvements for you, so read on…​

Notable fixes and improvements:

  • Weld Core

    • Improved subclass generation mechanism for generic interceptors (WELD-2414)

    • Fixed OSGi bundling, we missed out one package on last release (WELD-2421)

    • Improved behaviour with no-interface EJB view with non-public methods (WELD-2430)

    • Corrected proxy creation for signed classes (WELD-2425)

  • Weld SE

    • There are now multiple convenient error-proof methods to quickly configure SE container (WELD-2426)

      • Weld.enableDevMode(), Weld.scanClasspathEntries(), …​

  • Weld API/SPI

    • WeldInstance has several improvements

      • It now allows you to select() beans based on java.lang.reflect.Type (WELD-2427)

      • WeldInstance.Handler had become lazy which means you can now iterate/filter/sort WeldInstance without actually instantiating beans (WELD-2258)

    • There is new interface in the API - WeldEvent - which can be used in place of well known Event but allows you narrow down event type by using select() with java.lang.reflect.Type (WELD-2427)

    • API now contains a String key used to obtain interceptors binding from InvocationContext (WELD-2436)

  • Other

    • Probe now correctly recognizes beans which have @Priority but aren’t alternatives (WELD-2432)

    • Multiple documentation improvements regarding all things, old and new (WELD-2440, WELD-2431, WELD-2434)

WildFly Patch

As usual, there is a patch for WildFly 11.0.0.Final is available.

If you’re not familiar with patching WildFly, check the FAQ.


Weld 2.4.5.Final

2017-9-11   release   Matej Novotny

It’s about time we delivered another regular bugfix release for Weld 2. And while the list of fixes isn’t exhausting, some of them are quite crucial.

Notable fixes and improvements:

  • Weld Core:

    • Revise Java 8 default methods plus proxies/sublasing behaviour (WELD-2407 and WELD-2405)

    • All POMs in Weld core project should now have correct MIME types; this corrects issues with Nexus 3 (WELD-2417)

    • Proxies for signed packages should now be generated in custom packages (WELD-2402)

    • The behaviour of Weld Core and integrator provided implementation of org.jboss.weld.bootstrap.api.Environment is back to what it was in Weld 2.4.3.Final (WELD-2401)

      • We found out this change could cause serious headaches to integrators so we will leave it as it is - sorry for the mess

      • For Weld 3, we already have a better solution in place

  • Weld SE and Servlet

    • Both, Weld SE and Weld Servlet, will now explicitly bring in dependency on jboss-classfilewriter 1.2+ (WELD-2406)

  • Other

    • Under the jboss-as directory of Weld source code, you can now make use of new profiles to create WildFly patches yourself WELD-2397

WildFly Patch

As usual, a patch for WildFly 10.1.0.Final is available. But since WildFly 11 has already reached CR stage, we have decided to also provide you with patch for WildFly 11.0.0.CR1. If you’re not familiar with patching WildFly, check the FAQ.


Weld 3.0.1.Final

2017-8-25   release   Matej Novotny

Weld 3.0.1.Final is out and it brings some bugfixes as well as new version of Weld API - 3.0.SP1. Among the new things you can find sweet stuff such as an expansion to CDI 2 BeanConfigurator API or the ability to detect that injected object is Weld proxy. Wait, not only detect - you can also use it do get Metadata or even retrieve the actual contextual instance hidden beneath. So let’s see the summary of fixes and improvements, shall we?

Notable fixes and improvements:

  • Weld Core

    • Revised support for Java 8 default methods (WELD-2407 and WELD-2405)

    • Corrected MIME types for all POMs in Weld core - Nexus 3 will love us now! (WELD-2417)

    • Fixed how proxies are created for signed packages (WELD-2402)

    • Portable extension events should now be fired in accordance with specification WELD-2393

  • Weld SE

    • Synthetic bean archive can now have discovery mode annotated (WELD-2386)

    • Added a convenient static method WeldContainer.current() allowing you to quickly grab your running instance (WELD-2399)

    • Fixed a glitch when starting SE container and adding packages via Weld.addPackages() WELD-2395

  • Weld API/SPI

    • Added a way to detect proxies and subclasses (WELD-2407)

      • Every Weld-enhanced object (subclass/proxy) will now implement new marker interface(s) which grant access to additional data about the bean

      • This also allows to retrieve the underlying contextual instance

    • Added WeldBeanConfigurator to API - allows to select an @Alternative which was created using BeanConfigurator (WELD-2412)

    • We have enhanced the Environment in Weld SPI so that integrators define whether their bean archives are "EE module aware" or not (WELD-2398)

  • Other

    • Under the jboss-as directory of Weld source code, you can now make use of new profiles to create WildFly patches yourself WELD-2397

    • Weld SE and Weld Servlet now explicitly depends on jboss-classfilewriter in version 1.2+ WELD-2406

WildFly Patch

As usual, there is a patch for WildFly 10.1.0.Final is available.

But, for those of you who like to stay sharp, we have also created a patch for WildFly 11.0.0.Beta1.

Please note that there is currently a known issue with security context propagation in Weld 3 for WildFly 11. Though this should only concern people who use the combination of Elytron subsystem and asynchronous CDI events.

If you’re not familiar with patching WildFly, check the FAQ.