News - tagged as "release"

Weld 5.0.0.Beta1

2022-1-24   release   Matej Novotny

Some of you might have noticed that Weld already had some version 5 releases, namely two Alphas. Those were a work-in-progress implementations so I didn’t post any actual release notes as the specification was still undergoing changes. CDI 4 is now in very much ready-to-fly state as its first CR release has recently landed in Maven Central. Therefore, here we are with a proper release of Weld API 5.0.Beta5 and Weld Core 5.0.0.Beta1 which implements all the bits and pieces of CDI 4.0 plus brings a few more changes and deprecation removals.

This post will try to cover Weld-side of things meaning anything that changed and is Weld specific or influences integrators in any way. If you want to learn what’s new in CDI 4.0, I suggest taking a look at this detailed article I wrote some time ago. It provides a good overview of all major changes, all of which are implemented in this Weld release. In case you want to check out the list of JIRA issues for Weld releases, the last chapter will provide links for both Alpha releases as well as this Beta release. Last but not least, you can also reach out to us via Gitter channel or weld-dev@lists.jboss.org mailing list.

Without further ado, let’s dive into it!

Target JDK version for Weld 5 (and for CDI 4) is now 11

Therefore, JDK 11 is now the minimal version required to run Weld. This is basically a requirement for all Jakarta EE 10 specifications. On the other hand, Weld 5 is also tested against and supports JDK 17 as well.

Weld 5 is no longer a multi-release (MR) JARs

As you might know, Weld 3 and 4 are running some different class defining strategies for JDK 8 or 11+ resulting in an MR JAR solution. Since JDK 11 is the basis, this is no longer needed and similar workarounds were removed from code.

Deprecations and removals

Here is a list of all changes of this nature within Weld APIs:

  • Multiple methods from org.jboss.weld.serialization.spi.ProxyServices were removed.

    • If you are an integrator, you probably implemented this interface at some point in time; these methods weren’t used by Weld anyway, so they are now gone for good.

    • Here is a link to the issue removing it.

  • Any integrators basing their implementations of Jandex likely implemented ClassFileInfo; its isTopLevelClass() has been removed.

    • Note that this method was redundant and can be replaced by getClassNestingType().

    • This was removed as part of the above mentioned issue.

  • WeldInstance.Handler class is now deprecated and so are multiple methods returning this type from WeldInstance

CDI has had a similar cleanup and some long deprecated API methods were removed; glance at this GitHub issue if you want to learn more about that.

Empty `beans.xml interpretation

There is one breaking change in CDI 4.0 that should be mentioned here - change of default interpretation of empty beans.xml descriptor. Up until CDI 3.0, leaving this file empty meant discovery mode all whereas starting with CDI 4 it now defaults to annotated discovery mode. As per specification, in all discovery mode, all classes in bean archive are scanned and if fitting, turned into beans. However, annotated discovery mode only scans classes with bean defining annotations. Therefore, this change can be breaking for lots of applications using empty beans.xml and relying on CDI to discover classes without annotations. In order to ease the transition to this new default, CDI 4 specification says the following:

For compatibility with CDI versions prior to 4.0, CDI Full products must contain an option that causes an archive with empty beans.xml to be considered an explicit bean archive.

This option is vendor-dependent and integrators needs to define how to achieve it in their frameworks/platforms. That being said, Weld has been updated to allow for this. If you are using Weld tooling to parse beans.xml, chances are, you’re doing one of these:

  • Directly invoking parser via org.jboss.weld.xml.BeansXmlStreamParser.

    • BeansXmlStreamParser now has new constructor methods which allow passing BeanDiscoveryMode parameter telling Weld how to interpret empty beans.xml.

    • All former constructors were retained and default to BeanDiscoveryMode.ANNOTATED.

  • Indirectly invoking it via an implementation of org.jboss.weld.bootstrap.api.Bootstrap and its parse methods.

    • New variantions of the parse methods were added and accept BeanDiscoveryMode parameter telling Weld how to interpret empty beans.xml.

    • All former variantion of parse methods were retained and default to BeanDiscoveryMode.ANNOTATED.

This should give integrators enough leeway to implement the backward compatibility switch.

Weld versus CDI Lite versus CDI Full

By far the biggest change in CDI 4.0 is the introduction of CDI Lite. At this point I should reiterate that I highly recommend looking this article if you don’t know what CDI Lite is. In short, CDI Lite is a feature subset of CDI Full that broadens the amount of environments in which CDI can execute; more presicely, it enables CDI in build time oriented frameworks such as Micronaut or Quarkus. What does that means for Weld users? Nothing much, Weld is and will be a runtime oriented implementation and you can keep using CDI as you did up until now. More precisely, Weld is so called CDI Full implementation meaning it provides each and every CDI feature and while there were some deprecations and removals, the rest stays the same.

Build Compatible Extensions

One of the notable additions to CDI Lite (and therefore into CDI Full as well) were Build Compatible Extensions (BCE). These are akin to Portable Extensions but tuned in a way so that they can be used in build time oriented environments as well. Along with it comes a different language model because AnnotatedType and friends are reflection-heavy and not a good fit for that API. If you want to learns more, here is an excellent article by Ladislav Thon that covers how they work.

From Weld perspective, you can use BCE as much as you like although they are also executed at runtime, just as Portable Extensions are. It is still recommended to use Portable Extensions if possible because BCE are (in Weld) implemented via Portable Extensions. That being said, if you have some portability demands between Lite and Full, you should be able to use BCE as much as you like.

Integrators - how to make Weld understand Build Compatible Extensions?

This part focuses mainly on integrators and describes how Weld implements Build Compatible Extensions and what needs to be done by integrators in order to fully support CDI Lite.

weld-lite-extension-translator module

Weld 5 has a new module that enables Build Compatible Extensions (BCE) and the new language model that goes along with it - weld-lite-extension-translator. GAV of this new artifact is org.jboss.weld:weld-lite-extension-translator:5.0.0.Beta1. As I mentioned in previous point, BCE are executed via a Portable extension. More precisely, the key class is WeldLiteExtensionTranslator.

Just like any Portable extension, it needs an entry in META-INF or an instance of this extensions has to be added programmaticaly during Weld bootstrap. This is where it gets tricky; it doesn’t work out of the box in all environments!

  • Weld SE - works out of the box, the extension is automagically added

  • Weld Servlet - works out of the box, the extensions is automagically added

  • EE - doesn’t work without integrator registering the extension

  • Any other custom integration - doesn’t work without integrator registering the extension

There is of course a reason for it - complex structured deployments (such as EAR or WAR) and the fact that Weld alone cannot know the deployment well enough to make sure this extension wouldn’t be registered multiple times. On top of that, you might also want to avoid registering this extension if there are no BCE found inside the deployment which can also be dependent on how the given platform performs such discovery. Therefore, Weld leaves it up to the integrator (WildFly, GF, Liberty,…​) to identify where and when to register this extension for each deployment.

Registering LiteExtensionTranslator

Registering the LiteExtensionTranslator can be as easy as adding a META-INF entry with it into some archive in the deployment. An example of this would be arquillian-container-weld, a test container for Weld applications. As you can see from this pull request, it basically adds a META-INF entry which is sufficient to support new extension model. Since it a test tool, the extension is always registered without any attempt to optimize it.

The above solution is nice and clean, but won’t cut it for any EE integrators. Instead, you will want to register this extension very similarly to how you currently register ProbeExtension - add it programmatically as part of the CDI deployment. As mentioned above, this extension should to be registered at most once per deployment, so I’d recommend welding (pun intended) this directly into your org.jboss.weld.bootstrap.spi.CDI11Deployment implementation. Because WildFly does not yet have a public branch with this, I can at least point to how it registers ProbeExtension. With a little bit of digging, it boils down to creating CDI11Deployment impl with list of extensions already containing this one.

Which brings us to the second point - I’d recommend integrators to optimize this process and only register/include LiteExtensionTranslator when there is at least one BCE present in any given deployment. The reason being that this extension has to monitor a very wide range of events including ProcessAnnotatedType<?> for all types in order to properly implement BCE. Many integrators can perform BCE detection in their own ways (such as Jandex in WildFly) but for those that want a generic solution, take a look at org.jboss.weld.lite.extension.translator.BuildCompatibleExtensionLoader which is a utility class alowing to perform a standard service discovery process with given ClassLoader and returns the set of discovered BCE classes. You can then instantiate LiteExtensionTranslator via a constructor that takes this set as an input; or skip registering it if you haven’t found any BCE at all.

TCK structural changes and lang model TCKs

Few paragraphs above I mentioned new language model used by Build Compatible Extensions. Obviously, this needed some testing and so CDI TCK has a separate module for it; see lang-model module and its README. Weld tests and passes these TCKs via lang-model-tck module.

Next change was a separation of tests between pure CDI tests and tests requiring other Jakarta EE technologies such as JSF, EL and other. Many of these are candidates for move into their respective specifications but are for now still hosted in CDI TCK. All of these tests now reside under a separate module with GAV jakarta.enterprise:cdi-tck-web-impl.

Lastly, due to the split between CDI Lite and Full and the ability to have CDI implementations only for Lite, all TCKs had to be reviewed and a new test category was added - cdi-full. It is easy to guess that this category was assigned to tests that are supposed to only execute in CDI Full implementations; i.e. tests containing features that aren’t present in CDI Lite. Weld, as noted before, is a CDI Full implementation and as such passes all TCKs. The current setup used for TCK execution can be read from this POM file.

More in-depth overview of resolved issues in Weld 5

Finally, for those who would like to inspect a more detailed list of changes, here are links to release notes of all version 5 releases up to and including Beta1:

[ Download ] [ Documentation ] [ Release notes ]

Weld 4.0.2.Final and 3.1.8.Final

2021-7-14   release   Matej Novotny

New maintenance releases for Weld 3 and 4 have been rolled out.

There is only a handful of changes this time so let’s skid across them:

  • Prevent WeldInvocationContext from ever returning null when queried for interceptor bindings (WELD-2675)

  • Fix an NPE if there is an EJB bean with default package present (WELD-2674)

  • Weld wasn’t working on JDK 17 due to jboss-classfilewriter issue; this should no longer be the case (WELD-2671)

  • Correction to proxy name creation for producers based on interfaces - Weld should now use package and class of the most specific interface (WELD-2675)

  • Weld now provides correct metadata (via @Decorated) in cases where more than one decorator is applied to a single bean (WELD-2673)

  • We have decided to no longer provide WildFly patches for each release (WELD-2660)

    • After discussion with WildFly team, we figured the current way is not going to work for anything beyond Weld 3

    • And we aren’t even certain this feature is requested and/or used anymore; if you feel otherwise, please create a JIRA to let us know

[ Download ] [ Documentation Weld 4.0.2.Final ] [ Documentation Weld 3.1.8.Final ] [ Release notes for Weld 4.0.2.Final ] [ Release notes for Weld 3.1.8.Final ]

Weld 4.0.1.SP1 and 3.1.7.SP1

2021-4-14   release   Matej Novotny

Thanks to your reports, several flaws were discovered in the new class defining for JDK 11+. We have addressed those issues and because we reckon they are potentially blocking, we have released Weld 3.1.7.SP1 and 4.0.1.SP1.

Two main issues were:

  • Producers returning an interface type could sometimes try to define a proxy class with invalid name (WELD-2662)

    • Similar thing could happen for inner classes which should now work as well

  • Proxy class names for hierarchical type structures of interfaces could lead to a jumbled combination of package and name (WELD-2666)

    • Part of this fix is also an improvement wherein Weld actively tries to define new proxies into non-java packages making sure it uses MethodHandles.Lookup whenever applicable

Apart from that, this release also addresses a problem with Undertow servlet integration in which (Weld tried too eagerly to provide it’s own instances of Listener).

[ Download ] [ Documentation Weld 4.0.1.SP1 ] [ Documentation Weld 3.1.7.SP1 ] [ Release notes for Weld 4.0.1.SP1 ] [ Release notes for Weld 3.1.7.SP1 ]

Weld 4.0.1.Final

2021-3-22   release   Matej Novotny

First maintainance release of Weld 4 is now available along with API version 4.0.SP1.

The crux of this release is (much like 3.1.7.Final) a rework of Weld’s default class defining capabilities. With 4.0.1.Final you should no longer see illegal reflective access warning so long as you are on JDK 11 or newer. More details on this are below or in the respective JIRA ticket; in case you encounter any issue with it, please don’t hesitate to reach out to us.

So, let’s take a closer look:

  • Class Defining in Weld

    • Weld Core is now a Multi-Release JAR providing two different implementations for JDK 8 and JDK 11 or newer

    • Integrators are still encouraged to implement ProxyServices class from our API

    • For SE environment or an integrator that doesn’t implement the aforementioned API, Weld now provides a default implementation of ProxyServices which:

      • On JDK 8 behaves the same as it did until now - it cracks open ClassLoader.defineClass(…​) method and uses that

      • On JDK 11+ it uses a combination of MethodHandles.Lookup and a custom ClassLoader; the former is used for vast majority of cases with class loader being a solution for edge cases such as default packages or beans from signed JARs

  • Other Weld Core Fixes

    • BeanAttributesConfigurator could incorrectly initialize default qualifiers when @Named was involved (WELD-2659)

    • Synthetic alternative beans did not trigger ProcessBean event as they should when enabled (WELD-2658)

    • Fixed proxy creation for beans in default package (WELD-2657)

    • Fixed a corner case scenario where a hierarchy of classes with bridge methods would not get correctly intercepted (WELD-2656)

    • ProxyFactory now creates determininistic proxy names (WELD-2618)

    • Decorators for interfaces with non-decorated default method now work properly (WELD-2647)

WildFly Patch

There is no WildFly patch at the moment. We are currently exploring how to properly ship a patch that would align with WildFly usage of Galleon; the tracking JIRA can be seen (here).

[ Download ] [ Documentation ] [ Release notes ]

Weld 3.1.7.Final

2021-3-18   release   Matej Novotny

Weld 3.1.7.Final along with API 3.1.SP4 is now up for grabs!

Along a few bugfixes, the flagship of this release is a rework of Weld’s default class defining utilities which should eliminate those pesky JDK 11+ warnings about illegal reflective access. You can find more details on it below or in the JIRA ticket; in case you encounter any issue with it, please don’t hesitate to reach out to us.

So, let’s take a closer look:

  • Class Defining in Weld

    • Weld Core is now a Multi-Release JAR providing two different implementations for JDK 8 and JDK 11 or newer

    • Integrators are still encouraged to implement ProxyServices class from our API

    • For SE environment or an integrator that doesn’t implement the aforementioned API, Weld now provides a default implementation of ProxyServices which:

      • On JDK 8 behaves the same as it did until now - it cracks open ClassLoader.defineClass(…​) method and uses that

      • On JDK 11+ it uses a combination of MethodHandles.Lookup and a custom ClassLoader; the former is used for vast majority of cases with class loader being a solution for edge cases such as default packages or beans from signed JARs

  • Other Weld Core Fixes

    • BeanAttributesConfigurator could incorrectly initialize default qualifiers when @Named was involved (WELD-2659)

    • Synthetic alternative beans did not trigger ProcessBean event as they should when enabled (WELD-2658)

    • Fixed proxy creation for beans in default package (WELD-2657)

    • Fixed a corner case scenario where a hierarchy of classes with bridge methods would not get correctly intercepted (WELD-2656)

WildFly Patch

There is no WildFly patch at the moment. We are currently exploring how to properly ship a patch that would align with WildFly usage of Galleon; the tracking JIRA can be seen (here).

[ Download ] [ Documentation ] [ Release notes ]

Weld 3.1.6.Final

2021-1-13   release   Matej Novotny

Weld 3.1.6.Final is now available and brings a dosage of bug fixes and updates with it. Without further due, let’s dive straight into it!

Fixes and improvements:

  • Weld Core

    • Fix for decorators operating on interfaces with default methods (WELD-2647)

    • Weld will no longer try to load classes for specific JDK version when using multi-release JARs (WELD-2652)

    • ProxyFactory was changed to produce more deterministic and sensible names when based off interfaces (WELD-2618)

      • NOTE: this slightly changes names of generated proxy classes but has no effect on the functionality itself

  • Weld Servlet

    • Detect Jetty server in GWT 2.8+ test environment (WELD-2635)

    • Injection into Undertow servlet listener now works as intended (WELD-2636)

      • This should work from Undertow 2.2.0.Final onwards

  • Weld SE

    • Bean defining annotation can be specified as generic SeContainerInitializer property (WELD-2639)

  • Other bits

    • Fixed issue preventing upgrade of surefire plugin in our testsuite (WELD-2634)

    • Several corrections to OSGi package configuration (WELD-2642, WELD-2644, WELD-2645, WELD-2646)

    • Re-introduce multi HTML documentation output in best-effort mode; this is mainly to keep old links working (WELD-2640)

    • Fix intermittent test failure in DispatchingTest caused by race condition (WELD-2650)

WildFly Patch

This time around, the patch for WildFly 21.0.2.Final is available.

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

[ Download ] [ Documentation ] [ Release notes ]

Weld 4.0.0.Final

2020-12-16   release   Matej Novotny

An early Xmas present for CDI lovers is here - Final release for Weld 4 is now available! You can pick your Xmas jar-packaged present from Maven Central right away.

Since there were no new reported issues after integrating Weld 4.0.0.CR1 version into GlassFish and WildFly EE 9 preview, we have promoted Weld to Final release. Latest core version is now 4.0.0.Final and Weld API that ships with it is 4.0.Final.

Functionally, Weld 3 and 4 remain identical and both are getting the same treatment and doses of bugfixes. The main difference is that Weld 4 operates with EE 9, meaning it expects you to use it with CDI 3.0 along with the new jakarta package names.

Given that most changes poured into this version were more about dependecy updates, structural changes etc., I won’t list them all here. However, if you are still curious, you could take a peek at JIRA release page and browse various Weld 4 releases that we did over time.

What’s more important is that we are keen on hearing from you should you find any issues with this version. Whether you are an integrator or user, we realize no project is ever bug-free and we want to smack those bugs! So if you hit any problems that you think are bugs, let us know via one of the usual channels:

  • Ask on mailing list weld-dev@lists.jboss.org

  • Create JIRA issues

  • Drop the question on Weld Gitter

Last but not least, the Weld team wishes you Merry Christmas and Happy New Year.

WildFly Patch

Sorry to disappoint, but we cannot provide a patch yet. WildFly source code already contains the needed bits for EE 9 server variant, but there wasn’t a release yet. Good news is, once there is a release, it will already contain Weld 4 Final! From there on, we can then deliver patches as we used to.

[ Download ] [ Documentation ] [ Release notes ]

Weld 4.0.0.Beta1

2020-9-18   release   Matej Novotny

A new Weld 4 release is now available! Latest core version is now 4.0.0.Beta1 and Weld API that ships with it is 4.0.Beta1.

I will not be listing links to issues as usual, because I think more important work was done outside of JIRA tracking this time (although you can check the issues here). Instead, let me sum it up in a short list of noticeable changes:

  • All Weld bits are now present in Maven Central

    • Including servlet core (and shaded) which had to be left out last time

  • We are able to execute CDI TCKs in EE 9 environment once again and it’s all passing

  • We are now able to test servlets with Tomcats and Undertow

  • Reworked documentation generation tooling

    • Weld docs now have similar look to those of CDI and are distributed in either PDF or single page HTML format

  • Did some updates on Javadoc generation in API and Core if generated with JDK 11

  • Big update pass on tooling and dependencies

    • We are now using Dependabot and have bumped almost every dependency and tooling in the project

    • Which also led to nice cleanup and fixing of several issues

On top of that, every bugfix that would go into Weld 3 is of course being added to Weld 4 as well so those aren’t missing either!

WildFly Patch

Sadly we cannot provide a patch for WildFly as there is not yet any official release that would support EE 9. As soon as there is one, we will surely follow up with Weld patch!

[ Download ] [ Documentation ] [ Release notes ]

Weld 3.1.5.Final

2020-8-12   release   Matej Novotny

New maintenance release is now out - Weld 3.1.5.Final. It comes along with Weld API 3.1.SP3 although there are no significant changes in the API. The release was mainly to update to a new parent project version, allowing us to consume newer plugins and prepare ground for MR JAR support. As for core artifacts, there are some bugfixes as usual, so let’s take a look at those.

Fixes and improvements:

  • Weld Core

    • Allow to aggressively invoke setAttribute() when manipulating with conversation map in session (WELD-2626)

      • This behaviour is gated behind a property; it doesn’t affect standard Weld behaviour

    • Automatically cleanup leftover HttpSessionDestructionContext when starting new session context on a thread (WELD-2631)

    • Fix a rare case where an integer overflow could happen during alternative priority ordering (WELD-2628)

  • Weld Servlet Support

    • Change WebAppBeanArchiveScanner to allow serving modules without publishing (WELD-2570)

  • Other bits

    • ObserverMethodConfigurator initialized by reading an AnnotatedType previously didn’t set the method as async when it should (WELD-2609)

    • Fix up generation of javadoc (especially with JDK 11) for shaded artifacts and make it include Weld API/SPI as well as CDI API javadoc

    • Prepare ground for MR JAR releases which are a likely solution to JDK 11 class defining for SE (WELD-2619)

      • This is hopefully coming in the very next release

    • Updates to website tooling (Docker image, Ruby dependencies) and updates to some old http references which should now be https

    • Re-enable testing of CDI TCK 1.2 with Weld 3.x; this was broken sometime during migration to Jakarta artifacts (WELD-2624)

    • A test that assumed an order in between conversation context lifecycle and session timeouts was found to be wrong (ConversationContextDestroyedOnSessionTimeoutTest) and was re-written to remove the erroneous assumption (WELD-2629)

    • Correct JaCoCo TCK execution (WELD-2625)

WildFly Patch

This time around, the patch for WildFly 20.0.1.Final is available.

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

[ Download ] [ Documentation ] [ Release notes ]

Weld 4 and Jakarta EE 9

2020-5-13   release , jakarta   Matej Novotny

Weld Meets Jakarta EE 9

Most of you surely know that Jakarta EE 9 is on the horizon; slowly but steadily it is making its way into Java world. And we are not far behind, in fact we have just released Weld 4.0.0.Alpha2 which is an implementation of CDI 3.0! You heard that right, in Jakarta EE 9, all APIs have bumped their major versions; CDI turned 3.0 and so Weld version implementing that became 4.0. Hand in hand with it goes Weld API 4.0.Alpha1, also adapted to EE 9.

Some basic information about the release:

  • All the bits should be available in Maven Central at this point.

  • There is also .zip distribution as usual, see download page for more information.

  • No WildFly patch is provided this time around because WildFly does not yet have an EE 9 branch.

Working and Broken Parts

The only, yet considerably huge, change in APIs is (or at least should be) the swap from javax to jakarta packages. This comes with bunch of problems, for instance there is no EE server that could run on EE 9 with new packages yet. GlassFish is going to be first and they are working on integrating all the EE 9 reference implementations. There are some chicken-egg problems such as Weld requiring EE 9 server to execute CDI TCKs, but at the same time there is GlassFish needing Weld 4.0 to start operating with EE 9 in the first place. For this reason, our first few 4.0 releases are going to be marked as Alpha or Beta, they will not be fully tested and might be missing some parts that previous releases contained.

Here’s what’s working:

  • All testing that doesn’t require full EE container

  • Weld core implementation and API works as usual and is fully released

  • Weld examples work only partially, all those needing EE container have nowhere to be deployed

  • Weld SE works fully

  • Weld Probe should work so long as you are in SE

And here are the missing parts:

  • We cannot execute CDI TCKs until there are stable GlassFish build

    • We should be able to renew this pretty soon

  • Other in-container tests that we have (running on WildFly) are now disabled

  • Servlet parts of Weld are completely excluded from early releases

    • This is because there is currently no servlet working on EE 9, therefore we have nothing to adapt our internals to, yet

One big and sadly unanswered question is that of backward compatibility. In Jakarta itself, there seems to be a consensus of EE 9 not being backward compatible with EE 8. Weld 4 on its own will not work with applications written for Java EE 8 - basically with anything requiring old javax namespace packages. However, EE servers will be forced to adapt somehow, so I expect a tooling might eventually emerge that will allow to run legacy applications on newer servers. But that is yet to be seen and surely no sooner than after EE 9 release when other big servers start to adopt it.

Development Plans

Just to make things clear - we are planning on actively developing both, Weld 3 and Weld 4. We understand that EE server will need to take their time switching to Jakarta EE 9, all the more due to the aforementioned circumstances around backward compatibility. Therefore, both our versions will get their share of updates and bug fixes in the future!

Previous 1 2 3 4 ...6 7 Next