News

Weld 3.0.3.Final

2018-2-9   release   Matej Novotny

How do you cook Weld 3.0.3.Final? You start with a speck of bug fixes add some proxy generation improvements top it off with adjustments for integrators.

Notable fixes and improvements:

  • Weld Core

    • Fixed invocation of private observer method in some very specific cases (WELD-2443)

    • Container agnostic proxy serialization (WELD-2447)

    • Improve shared proxy class instantiation for multiple deployments with relaxed construction enabled (WELD-2448)

    • beans_1_1.xsd is now known to Weld once again (WELD-2445)

    • module-info is now ignored during discovery and won’t give you warnings in log (WELD-2459)

    • Enhanced logging of DeploymentException, it should now be possible to glance more from suppressed exceptions (WELD-2453)

  • Weld SE && Servlet

    • You can now register additional BeanArchiveHandler via ServiceLoader (WELD-2450)

    • Multitude of fields/method in Weld SE builder are now protected and hence extendable (WELD-2451)

  • Other

    • Improvements in documentation (WELD-2449)

    • Weld project now uses SpotBugs instead of FindBugs (WELD-2462)

    • OSGi now requires javax.ejb only optionally (WELD-2458)

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.

[ Download ] [ Documentation ] [ Release notes ]

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:

[ source, java ]

@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:

[ source, java ]

@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.

[ Download ] [ Documentation ] [ Release notes ]

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.

[ Download ] [ Documentation ] [ Release notes ]

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.

[ Download ] [ Documentation ] [ Release notes ]

Previous 1 2 ...8 9 10 ...19 20 Next