News

Weld 3.0.4.Final

2018-4-26   release   Matej Novotny

Weld 3.0.4.Final is here along with Weld API 3.0.SP3 - make sure you update both.

In this release we took first steps towards eliminating illegal access in JDK 10+. The good news is, Weld should now be able to run with --illegal-access=deny. The project and CI infrastructure around it went through a lot of changes to be able to build and execute on JDK 10 and there is still more to come. There are also numerous optimizations - beans.xml parsing, AT identifier representation, optional memory savings. And of course, bug fixes, so let us take a look at all of it.

Noticeable amount of reports, suggestions and even fixes came from the community - for that you have our thanks (and a new version of Weld of course)!

Fixes and improvements:

  • Weld Core

    • Correct proxy generation for class hierarchy with abstract class and generics (WELD-2470)

    • Opt-in enhancement in HTTP session replication, more eager approach (WELD-1130)

      • Note that WildFly does not need or use this

    • Fix NPE which could occur with SecurityManager if getPermissions() returned null (WELD-2464)

    • Relax bean type check in BeanManager.getInjectableReference() (WELD-2466)

    • AfterTypeDiscovery did not allow to remove declared interceptors/decorators/alternatives correctly (WELD-2479)

    • Two globally selected alternatives with the same priority should result in ambiguous dependency (WELD-2482)

    • Configurator SPI now uses sensible toString() so that user can tell what went wrong (WELD-2484)

    • Improve performance of beans.xml parsing (WELD-2469)

    • Introduce an optional configuration allowing Weld to perform cleanup after boot (WELD-2457 and WELD-2475)

      • In EE servers, if integrators meet certain conditions and allow for this, Weld can them drop metadata from some beans which will not be used in runtime

      • See Docs section for links

    • Optimise String representation of AnnotatedTypeIdentifier (WELD-2477)

  • Weld SE

    • Fix NPE which could occur if trying to intercept a method called by constructor (WELD-2478 and WELD-2473)

  • JDK 9/10 and onwards (WELD-2460)

    • Weld uses JDK’s internal BCEL classes (WELD-2490)

      • This is only used to report errors in generated bytecode on proxies/subclasses

      • We added a dependency on org.apache.bcel:bcel which enables this functionality without reflective access to internal libraries

      • In order to keep Weld’s footprint minimal, this dependency is optional only

    • Upgrade JBoss Classfilewriter to 1.2.2.Final (WELD-2487)

      • Eliminates another bunch of illegal access problems

  • Probe development tool

    • Probe now uses JDK-agnostic Annotation.toString() version (WELD-2463)

    • Correction to licences in Probe (WELD-2480)

  • Docs

    • WeldTerminalListener had wrong FQCN in our documentation which resulted in errors when trying to use it in Tomcat (WELD-2486)

    • Newly added memory-saving option ConfigurationKey.ALLOW_OPTIMIZED_CLEANUP is documented (WELD-2472)

      • If you wish to learn more, please glance here

      • Please note that integrator has to allow for this optimization, otherwise your settings won’t count (psst, WildFly 12 allows this!)

WildFly Patch

As usual, a patch for WildFly 12.0.0.Final is available. Please note that Weld 3.0.4.Final will still allow you to boot up WildFly in either EE 7 or EE 8 mode, whichever you prefer.

If this is the first time you hear about EE 8 mode for WildFly, check this post.

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

[ Download ] [ Documentation ] [ Release notes ]

Weld 2.4.7.Final

2018-3-20   release   Matej Novotny

Weld 2.4.7.Final is now available. It includes multiple important bugfixes, many of them focused around proxy generation and/or invocation.

Note
 Weld 2.4 now enters maintenance mode - there will be no further active development on Weld 2. We will be channeling our efforts into Weld 3 instead.

Notable fixes and improvements:

  • Weld Core:

    • Proxy-related issues:

      • Fixed possible NPE with multiple deployments one of which uses relaxed construction configuration (WELD-2448)

      • BeanManager.getInjectableReference was using unnecessarily strict checks for proxyability (WELD-2466)

      • Proxy serialization is now container agnostic (WELD-2447)

      • Fix invocation of private observer method (WELD-2443)

        • This only applies to private observer method which is not intercepted but is declared on a bean which has some other intercepted methods

      • Correct proxy generation for class hierarchy with abstract class and generics (WELD-2470)

    • Other issues:

      • Minor optimization in internal structures of InterceptionModel (WELD-2455)

      • Improve exception logging for DeploymentException (WELD-2453)

      • Prevent NPE if ProtectionDomain.getPermissions() returns null (WELD-2464)

  • Weld SE

    • Fields in org.jboss.weld.environment.se.Weld are now protected (WELD-2451)

    • Allow to register custom BeanArchiveHandler using ServiceLoader mechanism (WELD-2450)

      • This applies to SE and Servlet environments

  • Other

    • With OSGi, javax.ejb is now imported optionally (WELD-2458)

    • Weld now uses SpotBugs (a successor to FindBugs) (WELD-2462)

    • module-info, if present, is now correctly ignored during bean discovery phase (WELD-2459)

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

Previous 1 2 ...7 8 9 ...18 19 Next