diff --git a/dist/index.html b/dist/index.html
index 43987736..dd2eb5a2 100644
--- a/dist/index.html
+++ b/dist/index.html
@@ -157,6 +157,29 @@
-
-
- 2014-1-14
-
-
- Jozef Hartinger
-
-
-
-
-
This week we are releasing three new builds of Weld. Firstly, Weld 2.1.2.Final was released. This is a bug-fixing release with 11 issues resolved. Most notably:
-
-
-
- -
-
The conversation context is now initialized lazily. This resolves the problem with custom character encoding that many of you run into. See the reference documentation for details.
-
- -
-
Weld now runs fine on JDK8
-
- -
-
Jetty 9.1 is now supported by weld-servlet
-
-
-
-
-
In addition, Weld 1.1.17.Final (CDI 1.0) was released with several bug fixes.
-
-
-
Last but not least, there was a memory leak identified in GlassFish caused partly by GlassFish and partly by Weld. GlassFish still uses Weld 2.0. Although we do not maintain the 2.0 branch any longer and advice everyone to upgrade to Weld 2.1, the memory leak may be a problem for GlassFish users that are not able to upgrade to Weld 2.1 themselves. Therefore, we decided to do one more 2.0 release where this problem is fixed so that GlassFish users stuck on Weld 2.0 have an easy fix. Enjoy Weld 2.0.5.Final!
-
-
-
Now, our focus shifts completely towards Weld 2.2 where performance optimization and lowering memory consumption are the main goals. Expect first Alpha of Weld 2.2 by the end of January.
-
-
-
-
-
diff --git a/news/page/18.html b/news/page/18.html
index c27297d0..f4cccff1 100644
--- a/news/page/18.html
+++ b/news/page/18.html
@@ -141,6 +141,49 @@
+
+
+
+ 2014-1-14
+
+
+ Jozef Hartinger
+
+
+
+
+
This week we are releasing three new builds of Weld. Firstly, Weld 2.1.2.Final was released. This is a bug-fixing release with 11 issues resolved. Most notably:
+
+
+
+ -
+
The conversation context is now initialized lazily. This resolves the problem with custom character encoding that many of you run into. See the reference documentation for details.
+
+ -
+
Weld now runs fine on JDK8
+
+ -
+
Jetty 9.1 is now supported by weld-servlet
+
+
+
+
+
In addition, Weld 1.1.17.Final (CDI 1.0) was released with several bug fixes.
+
+
+
Last but not least, there was a memory leak identified in GlassFish caused partly by GlassFish and partly by Weld. GlassFish still uses Weld 2.0. Although we do not maintain the 2.0 branch any longer and advice everyone to upgrade to Weld 2.1, the memory leak may be a problem for GlassFish users that are not able to upgrade to Weld 2.1 themselves. Therefore, we decided to do one more 2.0 release where this problem is fixed so that GlassFish users stuck on Weld 2.0 have an easy fix. Enjoy Weld 2.0.5.Final!
+
+
+
Now, our focus shifts completely towards Weld 2.2 where performance optimization and lowering memory consumption are the main goals. Expect first Alpha of Weld 2.2 by the end of January.
+
+
+
+
+
-
-
- Weld 2.0.1.Final
-
-
- 2013-6-6
-
-
- Jozef Hartinger
-
-
-
-
-
Weld 2.0.1.Final has been released. This is mainly a bug-fixing release with 20 issues fixed since the previous one. For details, see the release notes.
-
-
-
Our focus is now shifting towards WildFly and its Weld integration in order to provide a CDI 1.1 compliant container. For details about CDI 1.1, see Pete’s blog post. Furthermore, we plan frequent releases of Weld to continue, so expect another release in early July at the latest!
-
-
-
-
-
diff --git a/news/page/19.html b/news/page/19.html
index 89f2e2ca..0ca6cfb0 100644
--- a/news/page/19.html
+++ b/news/page/19.html
@@ -141,6 +141,33 @@
+
+
+ Weld 2.0.1.Final
+
+
+ 2013-6-6
+
+
+ Jozef Hartinger
+
+
+
+
+
Weld 2.0.1.Final has been released. This is mainly a bug-fixing release with 20 issues fixed since the previous one. For details, see the release notes.
+
+
+
Our focus is now shifting towards WildFly and its Weld integration in order to provide a CDI 1.1 compliant container. For details about CDI 1.1, see Pete’s blog post. Furthermore, we plan frequent releases of Weld to continue, so expect another release in early July at the latest!
+
+
+
+
+
Weld 2.0.0.Final released
diff --git a/news/page/2.html b/news/page/2.html
index bdba9b9b..8fd49199 100644
--- a/news/page/2.html
+++ b/news/page/2.html
@@ -141,6 +141,41 @@
+
+
+ Weld 5.1.1.SP2
+
+
+ 2023-8-9
+
+
+
+ release
+
+
+
+ Matej Novotny
+
+
+
+
+
Another bug-smashing release has landed in Maven Central and this time it’s Weld 5.1.1.SP2.
+
+
+
This is a very small but important change which addresses possible memory leak scenario (WELD-2750).
+ There are multiple conditions for this leak to occur and while most applications are unlikely to be affected, it is still recommended to upgrade to this latest version.
+
+
+
As always, if you find further issues with Weld 5, do let us know.
+
+
+
+
+
Weld 5.1.1.SP1
@@ -403,42 +438,6 @@
-
-
- Weld 5.0.0.SP2
-
-
- 2022-6-8
-
-
-
- release
-
-
-
- Matej Novotny
-
-
-
-
-
Another quick turnaround as more integrators adopt Weld 5 and help us squash bugs.
- Weld 5.0.0.SP2 is headed into Central as we speak.
-
-
-
The main reason for this service release is WELD-2721 which was a spec violation in how AfterBeanDiscovery
methods were treated outside of lifecycle observer method invocations.
- Apart from that, there was also a corner case NPE during Weld Servlet and SE cooperation bootstrap (WELD-2720).
-
-
-
As always, if there are more problems with Weld 5, let us know and we’ll try to help.
-
-
-
-
-
diff --git a/news/page/3.html b/news/page/3.html
index 0f959efb..f880eafc 100644
--- a/news/page/3.html
+++ b/news/page/3.html
@@ -141,6 +141,42 @@
+
+
+ Weld 5.0.0.SP2
+
+
+ 2022-6-8
+
+
+
+ release
+
+
+
+ Matej Novotny
+
+
+
+
+
Another quick turnaround as more integrators adopt Weld 5 and help us squash bugs.
+ Weld 5.0.0.SP2 is headed into Central as we speak.
+
+
+
The main reason for this service release is WELD-2721 which was a spec violation in how AfterBeanDiscovery
methods were treated outside of lifecycle observer method invocations.
+ Apart from that, there was also a corner case NPE during Weld Servlet and SE cooperation bootstrap (WELD-2720).
+
+
+
As always, if there are more problems with Weld 5, let us know and we’ll try to help.
+
+
+
+
+
Weld 5.0.0.SP1
@@ -338,78 +374,6 @@
-
-
- Weld 4.0.3.Final and 3.1.9.Final
-
-
- 2022-2-16
-
-
-
- release
-
-
-
- Matej Novotny
-
-
-
-
-
Weld 3.1.9.Final for Jakarta EE 8 and Weld 4.0.3.Final for Jakarta EE 9 are now available.
-
-
-
-
-
- Note
- |
-
- Weld 3.1 and Weld 4.0 now enter a maintenance mode - there will be no further active development on these branches. Instead, the focus will be on Weld 5/EE 10 and beyond.
- |
-
-
-
-
-
Here is a brief list of notable changes; all of these are present in both Weld versions:
-
-
-
- -
-
Gracefully handle non-existing classpath entries in SE (WELD-2605)
-
- -
-
Proxies for classes starting with jakarta.*
now have Weld proxy prefix instead (WELD-2684)
-
- -
-
WeldInstance.Handle#get()
could incorrectly return the same instance even after destroying underlying contextual reference (WELD-2687)
-
- -
-
Fixed BeanConfigurator#produceWith()
leaking dependent bean under certain conditions (WELD-2693)
-
- -
-
Correct default package detection inside ProxyFactory
(WELD-2704)
-
- -
-
Several minor changes with regard to testing setup and update configurations (WELD-2706 and WELD-2707)
-
-
-
-
-
Last but not least, for those using WildFly, I would recommend taking a look into their release plan for 2022.
- It details which WildFly is the last for EE 8 and EE 9 and what happens going onwards.
- Weld is of course going to keep up the pace and we are working on integrating Weld 5 into Wildfly.
-
-
-
-
-
diff --git a/news/page/4.html b/news/page/4.html
index 08759c76..002111a9 100644
--- a/news/page/4.html
+++ b/news/page/4.html
@@ -141,6 +141,78 @@
+
+
+ Weld 4.0.3.Final and 3.1.9.Final
+
+
+ 2022-2-16
+
+
+
+ release
+
+
+
+ Matej Novotny
+
+
+
+
+
Weld 3.1.9.Final for Jakarta EE 8 and Weld 4.0.3.Final for Jakarta EE 9 are now available.
+
+
+
+
+
+ Note
+ |
+
+ Weld 3.1 and Weld 4.0 now enter a maintenance mode - there will be no further active development on these branches. Instead, the focus will be on Weld 5/EE 10 and beyond.
+ |
+
+
+
+
+
Here is a brief list of notable changes; all of these are present in both Weld versions:
+
+
+
+ -
+
Gracefully handle non-existing classpath entries in SE (WELD-2605)
+
+ -
+
Proxies for classes starting with jakarta.*
now have Weld proxy prefix instead (WELD-2684)
+
+ -
+
WeldInstance.Handle#get()
could incorrectly return the same instance even after destroying underlying contextual reference (WELD-2687)
+
+ -
+
Fixed BeanConfigurator#produceWith()
leaking dependent bean under certain conditions (WELD-2693)
+
+ -
+
Correct default package detection inside ProxyFactory
(WELD-2704)
+
+ -
+
Several minor changes with regard to testing setup and update configurations (WELD-2706 and WELD-2707)
+
+
+
+
+
Last but not least, for those using WildFly, I would recommend taking a look into their release plan for 2022.
+ It details which WildFly is the last for EE 8 and EE 9 and what happens going onwards.
+ Weld is of course going to keep up the pace and we are working on integrating Weld 5 into Wildfly.
+
+
+
+
+
Weld 5.0.0.Beta1
@@ -682,105 +754,6 @@ WildFly Patch
-
-
- 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).
-
-
-
-
-
-
-
diff --git a/news/page/5.html b/news/page/5.html
index bc45bf48..bb8f2019 100644
--- a/news/page/5.html
+++ b/news/page/5.html
@@ -141,6 +141,105 @@
+
+
+ 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).
+
+
+
+
+
+
+
Weld 3.1.6.Final
@@ -548,136 +647,6 @@ WildFly Patch
-
-
- Weld 4 and Jakarta EE 9
-
-
-
-
-
-
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
-
-
- -
-
Other in-container tests that we have (running on WildFly) are now disabled
-
- -
-
Servlet parts of Weld are completely excluded from early releases
-
-
-
-
-
-
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!
-
-
-
-
-
-
diff --git a/news/page/6.html b/news/page/6.html
index 64f95bb3..69b9423b 100644
--- a/news/page/6.html
+++ b/news/page/6.html
@@ -141,6 +141,136 @@
+
+
+ Weld 4 and Jakarta EE 9
+
+
+
+
+
+
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
+
+
+ -
+
Other in-container tests that we have (running on WildFly) are now disabled
+
+ -
+
Servlet parts of Weld are completely excluded from early releases
+
+
+
+
+
+
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!
+
+
+
+
+
+
Weld 3.1.4.Final
@@ -560,248 +690,6 @@ WildFly Patch
-
-
- Weld 3.1.0.Final
-
-
- 2019-2-6
-
-
-
- release
-
-
-
- Matej Novotny
-
-
-
-
-
Weld 3.1.0.Final and Weld API 3.1.Final are now up for grabs. What’s in it for you?
-
-
-
There are quite a few new things in the mix - InterceptionFactory
improvements, new API clases and methods, improvements to class defining for integrators in preparation for JDK 12.
- We now also support CDI context propagation between threads; there is a whole new SPI that allows users and/or frameworks to propagate request, session or conversation contexts.
- Last but no least, there are bug fixes, so let’s get right into it!
-
-
-
-
-
- Note
- |
-
- Integrators (WildFly, Liberty, GlassFish, …) will have to adjust to the changes made in SPI. Those are, most notably, the removal of long deprecated methods (WELD-2558) and reworked ProxyServices which now delegate class defining responsibility to the integrator (WELD-2556). This is crucial for Weld to operate on newer JDKs (12) and while Weld will work with the old approach for now, we will eventually fully swap to this new SPI.
- |
-
-
-
-
-
Fixes and improvements:
-
-
-
- -
-
Weld API/SPI
-
-
- -
-
Added API to allow for CDI context propagation between threads (WELD-2497)
-
-
- -
-
New API class was introduced (WeldAlterableContext
), this class offers methods to manipulate context state
-
- -
-
You can now propagate Request
, Session
and Conversation
contexts between threads as they all implement WeldAlterableContext
-
- -
-
This comes with certain limitations and is mostly designed for frameworks which would do this for you (such as MicroProfile Concurrency) but anyone can use it
-
- -
-
For more information, please glance at this part of Weld documentation
-
-
-
-
- -
-
WeldManager
, providing extra methods over what BeanManager
offers, is now an injectable bean (WELD-2538)
-
- -
-
WeldManager
now offers new util methods allowing you to easily grab active contexts
-
-
- -
-
WeldManager
can now be used to check if any given context is active without having to care about exceptions (WELD-2537)
-
- -
-
Added new SPI for class defining, deprecated old approach in ProxyServices
(WELD-2556)
-
-
- -
-
Integrators will have to implement this new API to be able to operate on JDK 12+
-
- -
-
Weld now delegates class defining to integrators in order to avoid having to crack open ClassLoader
methods
-
- -
-
Previously, integrators provided ClassLoader
instance which Weld then used to invoke defineClass()
methods
-
- -
-
We now ask integrators to invoke those methods themselves while providing them with all the necessary bits for doing so
-
-
-
-
- -
-
Remove deprecated parts of API/SPI (WELD-2558)
-
-
-
-
-
- -
-
Weld Core
-
-
- -
-
Weld will now log a WARNING
if you try to register an invalid qualifier (WELD-2522)
-
- -
-
You can now use InterceptionFactory
with an interface as a parameter (WELD-2550, WELD-2533)
-
-
- -
-
This means the proxy class will be based off an interface which is by definition always proxyable
-
- -
-
You can therefore even supply an unproxyable implementation and it will still work
-
- -
-
Note that this is experimental feature with some limitations to it, see Weld docs for more details
-
-
-
-
- -
-
Correct atomic behaviour in RequestContextController
(WELD-2536)
-
- -
-
Fix rare race condition in ConcurrentValidator
(WELD-2545)
-
- -
-
Small correction to interceptor resolution when they have no bindings (WELD-2521)
-
- -
-
Enforce consistent behaviour between AnnotatedType
and WithAnnotations
in regards to default methods (WELD-2551)
-
- -
-
All proxy-specific methods added by Weld now have more complex names to avoid (very rare) method clashes (WELD-2508)
-
- -
-
Lower logging level of InterceptorLogger.unableToDetermineInterceptedBean()
from WARN
to INFO
(WELD-2546)
-
-
-
-
- -
-
Weld SE
-
-
- -
-
You can now extend the set of bean defining annotations in Weld SE (WELD-2523)
-
-
- -
-
Fix bug in handling JAR dependencies added onto classpath where you could accidentally add more packages than desired (WELD-2535)
-
- -
-
Correct ALLOW_OPTIMIZED_CLEANUP
configuration key value (WELD-2547)
-
- -
-
When running with SecurityManager
enabled, Weld will now refuse to use ForkJoinPool
for startup and will pick different pool instead (WELD-2517)
-
-
-
-
- -
-
Probe development tool
-
-
- -
-
Other
-
-
- -
-
Stabilize testsuite and make sure dependencies are EE 8 based (WELD-2519, WELD-2553)
-
- -
-
Documentation has been updated to reflects EE 8 versions of servers (WELD-2529)
-
- -
-
Documented all changes coming to Weld API in 3.1 update (WELD-2540)
-
- -
-
Re-enable SpotBugs code quality checking on JDK 11+ (WELD-2544)
-
- -
-
Upgraded WildFly Arquillian adapter to 2.1.1.Final (WELD-2543)
-
- -
-
Revisit testing on Jetty (WELD-2528)
-
- -
-
We are now regularly testing with JDK 11 and looking into JDK 12 testing
-
-
-
-
-
-
-
-
WildFly Patch
-
-
-
-
If you’re not familiar with patching WildFly, check the FAQ.
-
-
-
-
-
-
-
diff --git a/news/page/7.html b/news/page/7.html
index d725078b..39f4aab3 100644
--- a/news/page/7.html
+++ b/news/page/7.html
@@ -141,6 +141,248 @@
+
+
+ Weld 3.1.0.Final
+
+
+ 2019-2-6
+
+
+
+ release
+
+
+
+ Matej Novotny
+
+
+
+
+
Weld 3.1.0.Final and Weld API 3.1.Final are now up for grabs. What’s in it for you?
+
+
+
There are quite a few new things in the mix - InterceptionFactory
improvements, new API clases and methods, improvements to class defining for integrators in preparation for JDK 12.
+ We now also support CDI context propagation between threads; there is a whole new SPI that allows users and/or frameworks to propagate request, session or conversation contexts.
+ Last but no least, there are bug fixes, so let’s get right into it!
+
+
+
+
+
+ Note
+ |
+
+ Integrators (WildFly, Liberty, GlassFish, …) will have to adjust to the changes made in SPI. Those are, most notably, the removal of long deprecated methods (WELD-2558) and reworked ProxyServices which now delegate class defining responsibility to the integrator (WELD-2556). This is crucial for Weld to operate on newer JDKs (12) and while Weld will work with the old approach for now, we will eventually fully swap to this new SPI.
+ |
+
+
+
+
+
Fixes and improvements:
+
+
+
+ -
+
Weld API/SPI
+
+
+ -
+
Added API to allow for CDI context propagation between threads (WELD-2497)
+
+
+ -
+
New API class was introduced (WeldAlterableContext
), this class offers methods to manipulate context state
+
+ -
+
You can now propagate Request
, Session
and Conversation
contexts between threads as they all implement WeldAlterableContext
+
+ -
+
This comes with certain limitations and is mostly designed for frameworks which would do this for you (such as MicroProfile Concurrency) but anyone can use it
+
+ -
+
For more information, please glance at this part of Weld documentation
+
+
+
+
+ -
+
WeldManager
, providing extra methods over what BeanManager
offers, is now an injectable bean (WELD-2538)
+
+ -
+
WeldManager
now offers new util methods allowing you to easily grab active contexts
+
+
+ -
+
WeldManager
can now be used to check if any given context is active without having to care about exceptions (WELD-2537)
+
+ -
+
Added new SPI for class defining, deprecated old approach in ProxyServices
(WELD-2556)
+
+
+ -
+
Integrators will have to implement this new API to be able to operate on JDK 12+
+
+ -
+
Weld now delegates class defining to integrators in order to avoid having to crack open ClassLoader
methods
+
+ -
+
Previously, integrators provided ClassLoader
instance which Weld then used to invoke defineClass()
methods
+
+ -
+
We now ask integrators to invoke those methods themselves while providing them with all the necessary bits for doing so
+
+
+
+
+ -
+
Remove deprecated parts of API/SPI (WELD-2558)
+
+
+
+
+
+ -
+
Weld Core
+
+
+ -
+
Weld will now log a WARNING
if you try to register an invalid qualifier (WELD-2522)
+
+ -
+
You can now use InterceptionFactory
with an interface as a parameter (WELD-2550, WELD-2533)
+
+
+ -
+
This means the proxy class will be based off an interface which is by definition always proxyable
+
+ -
+
You can therefore even supply an unproxyable implementation and it will still work
+
+ -
+
Note that this is experimental feature with some limitations to it, see Weld docs for more details
+
+
+
+
+ -
+
Correct atomic behaviour in RequestContextController
(WELD-2536)
+
+ -
+
Fix rare race condition in ConcurrentValidator
(WELD-2545)
+
+ -
+
Small correction to interceptor resolution when they have no bindings (WELD-2521)
+
+ -
+
Enforce consistent behaviour between AnnotatedType
and WithAnnotations
in regards to default methods (WELD-2551)
+
+ -
+
All proxy-specific methods added by Weld now have more complex names to avoid (very rare) method clashes (WELD-2508)
+
+ -
+
Lower logging level of InterceptorLogger.unableToDetermineInterceptedBean()
from WARN
to INFO
(WELD-2546)
+
+
+
+
+ -
+
Weld SE
+
+
+ -
+
You can now extend the set of bean defining annotations in Weld SE (WELD-2523)
+
+
+ -
+
Fix bug in handling JAR dependencies added onto classpath where you could accidentally add more packages than desired (WELD-2535)
+
+ -
+
Correct ALLOW_OPTIMIZED_CLEANUP
configuration key value (WELD-2547)
+
+ -
+
When running with SecurityManager
enabled, Weld will now refuse to use ForkJoinPool
for startup and will pick different pool instead (WELD-2517)
+
+
+
+
+ -
+
Probe development tool
+
+
+ -
+
Other
+
+
+ -
+
Stabilize testsuite and make sure dependencies are EE 8 based (WELD-2519, WELD-2553)
+
+ -
+
Documentation has been updated to reflects EE 8 versions of servers (WELD-2529)
+
+ -
+
Documented all changes coming to Weld API in 3.1 update (WELD-2540)
+
+ -
+
Re-enable SpotBugs code quality checking on JDK 11+ (WELD-2544)
+
+ -
+
Upgraded WildFly Arquillian adapter to 2.1.1.Final (WELD-2543)
+
+ -
+
Revisit testing on Jetty (WELD-2528)
+
+ -
+
We are now regularly testing with JDK 11 and looking into JDK 12 testing
+
+
+
+
+
+
+
+
WildFly Patch
+
+
+
+
If you’re not familiar with patching WildFly, check the FAQ.
+
+
+
+
+
+
+
Weld 2.4.8.Final
@@ -633,151 +875,6 @@ WildFly Patch
-
-
- 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)
-
-
- -
-
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
-
-
- -
-
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)
-
-
-
-
-
-
-
-
-
-
diff --git a/news/page/8.html b/news/page/8.html
index fc695289..ccecaf42 100644
--- a/news/page/8.html
+++ b/news/page/8.html
@@ -141,6 +141,151 @@
+
+
+ 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)
+
+
+ -
+
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
+
+
+ -
+
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)
+
+
+
+
+
+
+
+
+
+
Weld 3.0.3.Final
@@ -625,101 +770,6 @@ WildFly Patch
-
-
- 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
-
-
- -
-
Other
-
-
-
-
-
-
-
-
diff --git a/news/page/9.html b/news/page/9.html
index 6162e24f..3abfe584 100644
--- a/news/page/9.html
+++ b/news/page/9.html
@@ -141,6 +141,101 @@
+
+
+ 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
+
+
+ -
+
Other
+
+
+
+
+
+
+
+
Weld 3.0.1.Final
@@ -843,155 +938,6 @@ Trimmed Bean Archives
-
-
- Weld 3.0.0.Final - the first implementation of CDI 2.0!
-
-
- 2017-5-15
-
-
-
- release
-
-
-
- Martin Kouba
-
-
-
-
-
I am very pleased to announce the release of Weld 3.0.0.Final - the first implementation of CDI 2.0!
- I would like to thank not only to everyone involved in this particular release but also to the Weld community as a whole and also to all active CDI EG members who invested a lot of energy into the specification process!
-
-
-
-
-
/**
* TODO: Continue to deliver bugfixes and improvements
*/
public class WeldTeam extends OpenSourceCommunity {
@Inject
@AwesomeNews
Event<String> event;
public void release() {
// Fire asynchronously so that we don't need to wait for observer notification before we start celebrating!
event.fireAsync("CDI 1.2 is dead, long live CDI 2.0!");
celebrate();
}
}
-
-
-
-
-
-
- Note
- |
-
- Weld 3 is an IMPORTANT MILESTONE.
- Therefore, we’re preparing a special blogpost summarizing all the important stuff that was added.
- Expect the Tour around Weld 3 blogpost within a few days.
- |
-
-
-
-
-
Let’s sum up the notable changes since 3.0.0.CR2:
-
-
-
- -
-
Weld defines two non-portable notification options to configure the notification of asynchronous observer methods (see also Notification options for more info):
-
-
- -
-
weld.async.notification.mode
- the notification mode, possible values are: SERIAL
(default) and PARALLEL
-
- -
-
weld.async.notification.timeout
- the notification timeout (in milliseconds) after which the returned completion stage must be completed.
-
-
- -
-
If the time expires the stage is completed exceptionally with a CompletionException
holding the java.util.concurrent.TimeoutException
as its cause
-
- -
-
The expiration does not abort the notification of the observers
-
-
-
-
-
-
-
- -
-
Session replication - handle situation when HTTPSessionBean
might not be serializable (WELD-2346)
-
- -
-
Fire @Initialied(RequestScoped.class)
/@Destroyed(RequestScoped.class)
events for a @PostConstruct
callback if the request context was activated for the specific callback
-
- -
-
Weld SE
-
-
- -
-
It’s possible to easily register a org.jboss.weld.bootstrap.api.Service
during container bootstrap (WELD-2360)
-
- -
-
Any javax.enterprise.inject.spi.CDI
method can now be called during AfterDeploymentValidation
(WELD-2371)
-
- -
-
ContainerInitialized
and ContainerShutdown
now implement toString()
(WELD-2354)
-
-
-
-
- -
-
Weld Servlet
-
-
- -
-
Added option to disable Jandex in Weld SE and Weld Servlet (WELD-2374)
-
- -
-
Development tools
-
-
- -
-
Updated documentation and migration notes for integrators
-
- -
-
Examples cleanup (dropped GAE support, etc.)
-
-
-
-
-
-
-
diff --git a/news/tags/release/index.html b/news/tags/release/index.html
index 4d7bd1b6..657e27ce 100644
--- a/news/tags/release/index.html
+++ b/news/tags/release/index.html
@@ -141,6 +141,84 @@
+
+
+ Weld 5.1.3.Final
+
+
+ 2024-8-27
+
+
+
+ release
+
+
+
+ Matej Novotny
+
+
+
+
+
A new version of Weld 5.1 has landed in Maven Central.
+
+
+
This is a bug squashing round which backports several notable fixes and changes from Weld 6 into Weld 5:
+
+
+
+ -
+
Change BeanManager
resolution process for BuildCompatibleExtension
not belonging to any bean archive (WELD-2794)
+
+ -
+
LazySessionBeanStore
no longer swallows exceptions happening when attempting to initiate HTTP session (WELD-2762)
+
+ -
+
Correct how we determine proxy package for beans with unassignable types in their bean type set (WELD-2763)
+
+
+ -
+
Correct CommonLogger
to mention correct GAV for Jandex (WELD-2770)
+
+ -
+
Added the ability to register Build Compatible Extension in Weld SE without discovery (WELD-2772)
+
+ -
+
Correct inheritance of producer fields if there is an extension present (WELD-2773)
+
+ -
+
Make sure @Default
qualifier is added to events fired via BeanManager#getEvent()
where appropriate (WELD-2775)
+
+ -
+
Observer method confiurator now correctly allows to override Reception
settings without changing its notify()
method (WELD-2786)
+
+ -
+
Clean up legacy Jetty integration parts (WELD-2787)
+
+ -
+
Use Lock
instead of synchronized
within ContextualInstanceStrategy
to be more virtual thread-friendly (WELD-2788)
+
+ -
+
Skip superclass declarations of final methods when creating proxies (WELD-2785)
+
+ -
+
Ensure OSGi bundle has access to all dependencies needed for built-in beans (WELD-2796)
+
+
+
+
+
+
+
Weld 6.0.0.Beta4
@@ -821,42 +899,6 @@
-
-
- Weld 5.0.0.SP2
-
-
- 2022-6-8
-
-
-
- release
-
-
-
- Matej Novotny
-
-
-
-
-
Another quick turnaround as more integrators adopt Weld 5 and help us squash bugs.
- Weld 5.0.0.SP2 is headed into Central as we speak.
-
-
-
The main reason for this service release is WELD-2721 which was a spec violation in how AfterBeanDiscovery
methods were treated outside of lifecycle observer method invocations.
- Apart from that, there was also a corner case NPE during Weld Servlet and SE cooperation bootstrap (WELD-2720).
-
-
-
As always, if there are more problems with Weld 5, let us know and we’ll try to help.
-
-
-
-
-
diff --git a/news/tags/release/page/2.html b/news/tags/release/page/2.html
index 0c444093..f82e11b0 100644
--- a/news/tags/release/page/2.html
+++ b/news/tags/release/page/2.html
@@ -141,6 +141,42 @@
+
+
+ Weld 5.0.0.SP2
+
+
+ 2022-6-8
+
+
+
+ release
+
+
+
+ Matej Novotny
+
+
+
+
+
Another quick turnaround as more integrators adopt Weld 5 and help us squash bugs.
+ Weld 5.0.0.SP2 is headed into Central as we speak.
+
+
+
The main reason for this service release is WELD-2721 which was a spec violation in how AfterBeanDiscovery
methods were treated outside of lifecycle observer method invocations.
+ Apart from that, there was also a corner case NPE during Weld Servlet and SE cooperation bootstrap (WELD-2720).
+
+
+
As always, if there are more problems with Weld 5, let us know and we’ll try to help.
+
+
+
+
+
Weld 5.0.0.SP1
@@ -951,105 +987,6 @@ WildFly Patch
-
-
- 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).
-
-
-
-
-
-
-
diff --git a/news/tags/release/page/3.html b/news/tags/release/page/3.html
index 88a9b14d..b4276a9e 100644
--- a/news/tags/release/page/3.html
+++ b/news/tags/release/page/3.html
@@ -141,6 +141,105 @@
+
+
+ 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).
+
+
+
+
+
+
+
Weld 3.1.6.Final
@@ -1097,248 +1196,6 @@ WildFly Patch
-
-
- Weld 3.1.0.Final
-
-
- 2019-2-6
-
-
-
- release
-
-
-
- Matej Novotny
-
-
-
-
-
Weld 3.1.0.Final and Weld API 3.1.Final are now up for grabs. What’s in it for you?
-
-
-
There are quite a few new things in the mix - InterceptionFactory
improvements, new API clases and methods, improvements to class defining for integrators in preparation for JDK 12.
- We now also support CDI context propagation between threads; there is a whole new SPI that allows users and/or frameworks to propagate request, session or conversation contexts.
- Last but no least, there are bug fixes, so let’s get right into it!
-
-
-
-
-
- Note
- |
-
- Integrators (WildFly, Liberty, GlassFish, …) will have to adjust to the changes made in SPI. Those are, most notably, the removal of long deprecated methods (WELD-2558) and reworked ProxyServices which now delegate class defining responsibility to the integrator (WELD-2556). This is crucial for Weld to operate on newer JDKs (12) and while Weld will work with the old approach for now, we will eventually fully swap to this new SPI.
- |
-
-
-
-
-
Fixes and improvements:
-
-
-
- -
-
Weld API/SPI
-
-
- -
-
Added API to allow for CDI context propagation between threads (WELD-2497)
-
-
- -
-
New API class was introduced (WeldAlterableContext
), this class offers methods to manipulate context state
-
- -
-
You can now propagate Request
, Session
and Conversation
contexts between threads as they all implement WeldAlterableContext
-
- -
-
This comes with certain limitations and is mostly designed for frameworks which would do this for you (such as MicroProfile Concurrency) but anyone can use it
-
- -
-
For more information, please glance at this part of Weld documentation
-
-
-
-
- -
-
WeldManager
, providing extra methods over what BeanManager
offers, is now an injectable bean (WELD-2538)
-
- -
-
WeldManager
now offers new util methods allowing you to easily grab active contexts
-
-
- -
-
WeldManager
can now be used to check if any given context is active without having to care about exceptions (WELD-2537)
-
- -
-
Added new SPI for class defining, deprecated old approach in ProxyServices
(WELD-2556)
-
-
- -
-
Integrators will have to implement this new API to be able to operate on JDK 12+
-
- -
-
Weld now delegates class defining to integrators in order to avoid having to crack open ClassLoader
methods
-
- -
-
Previously, integrators provided ClassLoader
instance which Weld then used to invoke defineClass()
methods
-
- -
-
We now ask integrators to invoke those methods themselves while providing them with all the necessary bits for doing so
-
-
-
-
- -
-
Remove deprecated parts of API/SPI (WELD-2558)
-
-
-
-
-
- -
-
Weld Core
-
-
- -
-
Weld will now log a WARNING
if you try to register an invalid qualifier (WELD-2522)
-
- -
-
You can now use InterceptionFactory
with an interface as a parameter (WELD-2550, WELD-2533)
-
-
- -
-
This means the proxy class will be based off an interface which is by definition always proxyable
-
- -
-
You can therefore even supply an unproxyable implementation and it will still work
-
- -
-
Note that this is experimental feature with some limitations to it, see Weld docs for more details
-
-
-
-
- -
-
Correct atomic behaviour in RequestContextController
(WELD-2536)
-
- -
-
Fix rare race condition in ConcurrentValidator
(WELD-2545)
-
- -
-
Small correction to interceptor resolution when they have no bindings (WELD-2521)
-
- -
-
Enforce consistent behaviour between AnnotatedType
and WithAnnotations
in regards to default methods (WELD-2551)
-
- -
-
All proxy-specific methods added by Weld now have more complex names to avoid (very rare) method clashes (WELD-2508)
-
- -
-
Lower logging level of InterceptorLogger.unableToDetermineInterceptedBean()
from WARN
to INFO
(WELD-2546)
-
-
-
-
- -
-
Weld SE
-
-
- -
-
You can now extend the set of bean defining annotations in Weld SE (WELD-2523)
-
-
- -
-
Fix bug in handling JAR dependencies added onto classpath where you could accidentally add more packages than desired (WELD-2535)
-
- -
-
Correct ALLOW_OPTIMIZED_CLEANUP
configuration key value (WELD-2547)
-
- -
-
When running with SecurityManager
enabled, Weld will now refuse to use ForkJoinPool
for startup and will pick different pool instead (WELD-2517)
-
-
-
-
- -
-
Probe development tool
-
-
- -
-
Other
-
-
- -
-
Stabilize testsuite and make sure dependencies are EE 8 based (WELD-2519, WELD-2553)
-
- -
-
Documentation has been updated to reflects EE 8 versions of servers (WELD-2529)
-
- -
-
Documented all changes coming to Weld API in 3.1 update (WELD-2540)
-
- -
-
Re-enable SpotBugs code quality checking on JDK 11+ (WELD-2544)
-
- -
-
Upgraded WildFly Arquillian adapter to 2.1.1.Final (WELD-2543)
-
- -
-
Revisit testing on Jetty (WELD-2528)
-
- -
-
We are now regularly testing with JDK 11 and looking into JDK 12 testing
-
-
-
-
-
-
-
-
WildFly Patch
-
-
-
-
If you’re not familiar with patching WildFly, check the FAQ.
-
-
-
-
-
-
-
diff --git a/news/tags/release/page/4.html b/news/tags/release/page/4.html
index 03c851d3..140b0834 100644
--- a/news/tags/release/page/4.html
+++ b/news/tags/release/page/4.html
@@ -141,6 +141,248 @@
+
+
+ Weld 3.1.0.Final
+
+
+ 2019-2-6
+
+
+
+ release
+
+
+
+ Matej Novotny
+
+
+
+
+
Weld 3.1.0.Final and Weld API 3.1.Final are now up for grabs. What’s in it for you?
+
+
+
There are quite a few new things in the mix - InterceptionFactory
improvements, new API clases and methods, improvements to class defining for integrators in preparation for JDK 12.
+ We now also support CDI context propagation between threads; there is a whole new SPI that allows users and/or frameworks to propagate request, session or conversation contexts.
+ Last but no least, there are bug fixes, so let’s get right into it!
+
+
+
+
+
+ Note
+ |
+
+ Integrators (WildFly, Liberty, GlassFish, …) will have to adjust to the changes made in SPI. Those are, most notably, the removal of long deprecated methods (WELD-2558) and reworked ProxyServices which now delegate class defining responsibility to the integrator (WELD-2556). This is crucial for Weld to operate on newer JDKs (12) and while Weld will work with the old approach for now, we will eventually fully swap to this new SPI.
+ |
+
+
+
+
+
Fixes and improvements:
+
+
+
+ -
+
Weld API/SPI
+
+
+ -
+
Added API to allow for CDI context propagation between threads (WELD-2497)
+
+
+ -
+
New API class was introduced (WeldAlterableContext
), this class offers methods to manipulate context state
+
+ -
+
You can now propagate Request
, Session
and Conversation
contexts between threads as they all implement WeldAlterableContext
+
+ -
+
This comes with certain limitations and is mostly designed for frameworks which would do this for you (such as MicroProfile Concurrency) but anyone can use it
+
+ -
+
For more information, please glance at this part of Weld documentation
+
+
+
+
+ -
+
WeldManager
, providing extra methods over what BeanManager
offers, is now an injectable bean (WELD-2538)
+
+ -
+
WeldManager
now offers new util methods allowing you to easily grab active contexts
+
+
+ -
+
WeldManager
can now be used to check if any given context is active without having to care about exceptions (WELD-2537)
+
+ -
+
Added new SPI for class defining, deprecated old approach in ProxyServices
(WELD-2556)
+
+
+ -
+
Integrators will have to implement this new API to be able to operate on JDK 12+
+
+ -
+
Weld now delegates class defining to integrators in order to avoid having to crack open ClassLoader
methods
+
+ -
+
Previously, integrators provided ClassLoader
instance which Weld then used to invoke defineClass()
methods
+
+ -
+
We now ask integrators to invoke those methods themselves while providing them with all the necessary bits for doing so
+
+
+
+
+ -
+
Remove deprecated parts of API/SPI (WELD-2558)
+
+
+
+
+
+ -
+
Weld Core
+
+
+ -
+
Weld will now log a WARNING
if you try to register an invalid qualifier (WELD-2522)
+
+ -
+
You can now use InterceptionFactory
with an interface as a parameter (WELD-2550, WELD-2533)
+
+
+ -
+
This means the proxy class will be based off an interface which is by definition always proxyable
+
+ -
+
You can therefore even supply an unproxyable implementation and it will still work
+
+ -
+
Note that this is experimental feature with some limitations to it, see Weld docs for more details
+
+
+
+
+ -
+
Correct atomic behaviour in RequestContextController
(WELD-2536)
+
+ -
+
Fix rare race condition in ConcurrentValidator
(WELD-2545)
+
+ -
+
Small correction to interceptor resolution when they have no bindings (WELD-2521)
+
+ -
+
Enforce consistent behaviour between AnnotatedType
and WithAnnotations
in regards to default methods (WELD-2551)
+
+ -
+
All proxy-specific methods added by Weld now have more complex names to avoid (very rare) method clashes (WELD-2508)
+
+ -
+
Lower logging level of InterceptorLogger.unableToDetermineInterceptedBean()
from WARN
to INFO
(WELD-2546)
+
+
+
+
+ -
+
Weld SE
+
+
+ -
+
You can now extend the set of bean defining annotations in Weld SE (WELD-2523)
+
+
+ -
+
Fix bug in handling JAR dependencies added onto classpath where you could accidentally add more packages than desired (WELD-2535)
+
+ -
+
Correct ALLOW_OPTIMIZED_CLEANUP
configuration key value (WELD-2547)
+
+ -
+
When running with SecurityManager
enabled, Weld will now refuse to use ForkJoinPool
for startup and will pick different pool instead (WELD-2517)
+
+
+
+
+ -
+
Probe development tool
+
+
+ -
+
Other
+
+
+ -
+
Stabilize testsuite and make sure dependencies are EE 8 based (WELD-2519, WELD-2553)
+
+ -
+
Documentation has been updated to reflects EE 8 versions of servers (WELD-2529)
+
+ -
+
Documented all changes coming to Weld API in 3.1 update (WELD-2540)
+
+ -
+
Re-enable SpotBugs code quality checking on JDK 11+ (WELD-2544)
+
+ -
+
Upgraded WildFly Arquillian adapter to 2.1.1.Final (WELD-2543)
+
+ -
+
Revisit testing on Jetty (WELD-2528)
+
+ -
+
We are now regularly testing with JDK 11 and looking into JDK 12 testing
+
+
+
+
+
+
+
+
WildFly Patch
+
+
+
+
If you’re not familiar with patching WildFly, check the FAQ.
+
+
+
+
+
+
+
Weld 2.4.8.Final
@@ -1324,124 +1566,6 @@ WildFly Patch
-
-
- Weld 2.4.4.Final
-
-
- 2017-6-14
-
-
-
- release
-
-
-
- Matej Novotny
-
-
-
-
-
We have been busy chasing down some annoying little bugs and it’s high time you got the fruits of those efforts into your hands.
- Say hello to Weld 2.4.4.Final.
-
-
-
Notable fixes and improvements:
-
-
-
- -
-
Weld Core
-
-
- -
-
Fixed bean discovery event ordering when processing producers (WELD-2393)
-
- -
-
Eliminated an NPE for a corner case with abstract decorator (WELD-2273)
-
- -
-
Corrected @Initialized(RequestScoped.class)
event firing in @PostConstruct
callbacks (WELD-2372)
-
- -
-
Fixed BeanManager.isStereotype()
behavior when checking a qualifier annotated with yet another qualifier (WELD-2390)
-
-
-
-
- -
-
Weld SE
-
-
- -
-
Added a convenience static method WeldContainer.current()
, a shortcut for CDI.current()
with no need to cast the result (WELD-2399)
-
- -
-
Allowed to specify bean discovery mode for synthetic archives (WELD-2386)
-
- -
-
Fixed bean class discovery problem when adding whole packages (WELD-2395)
-
-
-
-
- -
-
Weld Servlet
-
-
- -
-
Configuration options
-
-
- -
-
Development tools
-
-
-
-
-
-
WildFly Patch
-
-
-
As usual, a patch for WildFly is available.
- Target platform is WildFly 10.1.0.Final.
- If you’re not familiar with patching WildFly, check the FAQ.
-
-
-
-
-
-
-
diff --git a/news/tags/release/page/5.html b/news/tags/release/page/5.html
index 57fc0f6a..2b912283 100644
--- a/news/tags/release/page/5.html
+++ b/news/tags/release/page/5.html
@@ -141,6 +141,124 @@
+
+
+ Weld 2.4.4.Final
+
+
+ 2017-6-14
+
+
+
+ release
+
+
+
+ Matej Novotny
+
+
+
+
+
We have been busy chasing down some annoying little bugs and it’s high time you got the fruits of those efforts into your hands.
+ Say hello to Weld 2.4.4.Final.
+
+
+
Notable fixes and improvements:
+
+
+
+ -
+
Weld Core
+
+
+ -
+
Fixed bean discovery event ordering when processing producers (WELD-2393)
+
+ -
+
Eliminated an NPE for a corner case with abstract decorator (WELD-2273)
+
+ -
+
Corrected @Initialized(RequestScoped.class)
event firing in @PostConstruct
callbacks (WELD-2372)
+
+ -
+
Fixed BeanManager.isStereotype()
behavior when checking a qualifier annotated with yet another qualifier (WELD-2390)
+
+
+
+
+ -
+
Weld SE
+
+
+ -
+
Added a convenience static method WeldContainer.current()
, a shortcut for CDI.current()
with no need to cast the result (WELD-2399)
+
+ -
+
Allowed to specify bean discovery mode for synthetic archives (WELD-2386)
+
+ -
+
Fixed bean class discovery problem when adding whole packages (WELD-2395)
+
+
+
+
+ -
+
Weld Servlet
+
+
+ -
+
Configuration options
+
+
+ -
+
Development tools
+
+
+
+
+
+
WildFly Patch
+
+
+
As usual, a patch for WildFly is available.
+ Target platform is WildFly 10.1.0.Final.
+ If you’re not familiar with patching WildFly, check the FAQ.
+
+
+
+
+
+
+
-
-
- Weld 2.3.5.Final
-
-
- 2016-7-1
-
-
-
- release
- ,
- plans
-
-
-
- Martin Kouba
-
-
-
-
-
The next version of the stable 2.3 branch has been released!
- See also the release details.
- Thanks to everyone involved in this release!
-
-
-
We plan to create the 2.4 branch of Weld within a few weeks.
- Weld 2.4 will remain a CDI 1.2 implementation.
- We would like to do some cleanup (e.g. remove deprecated classes from Weld SE), enhance the API and also add some new features.
- See also the list of issues for 2.4.0.CR1.
-
-
-
Notable bugfixes and improvements:
-
-
-
- -
-
fixed static disposer method invocation (WELD-2176)
-
- -
-
fixed private observer/producer/disposer invocation on a bean with decorator (WELD-2179)
-
- -
-
fixed Instance.destroy()
for dependent session beans (WELD-2148)
-
- -
-
fixed ArraySet.hashCode()
to comply with java.util.Set.hashCode()
contract (WELD-2185)
-
- -
-
log veto actions and modifications of lists returned by AfterTypeDiscovery
(WELD-2170, WELD-2171)
-
- -
-
log a warning when a class is annotated with a scope but does not declare an appropriate constructor (WELD-2178)
-
- -
-
support extension deployed in multiple WARs in an EAR (WELD-2143)
-
- -
-
detect non-unique BeanDeploymentArchive
identifier (WELD-2165)
-
- -
-
Weld Servlet
-
-
- -
-
fixed extraction of bean archive id - problem occures with embedded Jetty (WELD-2161)
-
- -
-
improve the way JandexDiscoveryStrategy
identifies an annotation annotated with @NormalScope
(WELD-2160)
-
- -
-
weld-servlet-core
declares dependency on weld-core-jsf
-
-
-
-
- -
-
Weld SE
-
-
- -
-
Probe - allow to test bean availability in a given bean archive
-
-
- -
-
many documentation and reference guide updates
-
-
-
-
-
WildFly Patch
-
-
-
As usual, a patch for WildFly is available. This time the target platform is WildFly 10.0.0.Final. If you’re not familiar with patching WildFly, check Markus’s tutorial.
-
-
-
-
-
-
-
diff --git a/news/tags/release/page/6.html b/news/tags/release/page/6.html
index 9f6c1696..1be39dbb 100644
--- a/news/tags/release/page/6.html
+++ b/news/tags/release/page/6.html
@@ -141,6 +141,123 @@
+
+
+ Weld 2.3.5.Final
+
+
+ 2016-7-1
+
+
+
+ release
+ ,
+ plans
+
+
+
+ Martin Kouba
+
+
+
+
+
The next version of the stable 2.3 branch has been released!
+ See also the release details.
+ Thanks to everyone involved in this release!
+
+
+
We plan to create the 2.4 branch of Weld within a few weeks.
+ Weld 2.4 will remain a CDI 1.2 implementation.
+ We would like to do some cleanup (e.g. remove deprecated classes from Weld SE), enhance the API and also add some new features.
+ See also the list of issues for 2.4.0.CR1.
+
+
+
Notable bugfixes and improvements:
+
+
+
+ -
+
fixed static disposer method invocation (WELD-2176)
+
+ -
+
fixed private observer/producer/disposer invocation on a bean with decorator (WELD-2179)
+
+ -
+
fixed Instance.destroy()
for dependent session beans (WELD-2148)
+
+ -
+
fixed ArraySet.hashCode()
to comply with java.util.Set.hashCode()
contract (WELD-2185)
+
+ -
+
log veto actions and modifications of lists returned by AfterTypeDiscovery
(WELD-2170, WELD-2171)
+
+ -
+
log a warning when a class is annotated with a scope but does not declare an appropriate constructor (WELD-2178)
+
+ -
+
support extension deployed in multiple WARs in an EAR (WELD-2143)
+
+ -
+
detect non-unique BeanDeploymentArchive
identifier (WELD-2165)
+
+ -
+
Weld Servlet
+
+
+ -
+
fixed extraction of bean archive id - problem occures with embedded Jetty (WELD-2161)
+
+ -
+
improve the way JandexDiscoveryStrategy
identifies an annotation annotated with @NormalScope
(WELD-2160)
+
+ -
+
weld-servlet-core
declares dependency on weld-core-jsf
+
+
+
+
+ -
+
Weld SE
+
+
+ -
+
Probe - allow to test bean availability in a given bean archive
+
+
+ -
+
many documentation and reference guide updates
+
+
+
+
+
WildFly Patch
+
+
+
As usual, a patch for WildFly is available. This time the target platform is WildFly 10.0.0.Final. If you’re not familiar with patching WildFly, check Markus’s tutorial.
+
+
+
+
+
+
+
Weld 3.0.0.Alpha16
@@ -956,160 +1073,6 @@ WildFly Patch
-
-
- Weld 3.0.0.Alpha8
-
-
- 2015-4-21
-
-
-
- release
- ,
- cdi2
-
-
-
- Jozef Hartinger
-
-
-
-
-
Weld 3.0.0.Alpha8 has been released.
- The main change is the enhanced API for using Weld in Java SE environment. In addition, this release comes with several weld-probe improvements.
-
-
-
Enhanced API for Weld SE
-
-
-
Weld has provided support for the Java SE environment for a long time with the weld-se module.
- The API provides an easy way for an application to initialize Weld and use it in a standalone mode.
- On initialization Weld SE scans the classpath for bean archives with the beans.xml
file, similarly to how it’s done in the Java EE environment.
-
-
-
In this release we are extending the API further.
- This is partially inspired by the current discussion in the CDI expert group where a standardized CDI API for Java SE is being proposed as part of CDI-26.
-
-
-
The following code snippet shows the new API in action:
-
-
-
-
Weld builder = new Weld()
.disableDiscovery()
.packages(Main.class, Utils.class)
.interceptors(TransactionalInterceptor.class)
.property("org.jboss.weld.construction.relaxed", true);
try (WeldContainer weld = builder.initialize()) {
MyBean bean = weld.select(MyBean.class).get();
System.out.println(bean.computeResult());
}
-
-
-
-
There are several new things to notice:
-
-
-
- -
-
the Weld
class is used as a builder to configure Weld before it is initialized
-
- -
-
automatic scanning can be disabled
-
- -
-
instead of scanning, classes or packages can be selected explicitly. All classes in those packages will be managed by Weld
-
- -
-
interceptors, decorators, extensions and Weld-specific configuration options can be specified using the builder
-
- -
-
WeldContainer
now implements AutoCloseable
and can therefore be used in a try-with-resources
block. At any time that execution gets outside of the code block, the Weld instance is shut down and all managed instances are safely destroyed.
-
-
-
-
-
It is also possible to start multiple independent Weld instances:
-
-
-
-
new Weld().disableDiscovery().containerId("one").beanClasses(MyBean.class).initialize();
new Weld().disableDiscovery().containerId("two").beanClasses(OtherBean.class).initialize();
MyBean bean = WeldContainer.instance("one").select(MyBean.class).get();
System.out.println(bean.computeResult());
WeldContainer.instance("one").shutdown();
WeldContainer.instance("two").shutdown();
-
-
-
-
Here, two independent WeldContainer
instances are initialized.
- Each of them is given a unique ID.
- The ID can subsequently be used to obtain a WeldContainer
reference in a different place of the code.
- One possible use-case this enables is for a library or framework (e.g. a testing framework) to use an embedded instance of Weld internally for its own needs (dependency injection, events, extensibility).
- This instance would not interfere with the Weld instance used by the application.
-
-
-
Obviously, automatic classpath scanning can still be used as before:
-
-
-
-
try (WeldContainer weld = new Weld().enableDiscovery().initialize()) {
MyBean bean = weld.select(MyBean.class).get();
System.out.println(bean.computeResult());
}
-
-
-
-
-
To play with the new API use the following dependency in you Maven project:
-
-
-
-
<dependency>
<groupId>org.jboss.weld.se</groupId>
<artifactId>weld-se-core</artifactId>
<version>3.0.0.Alpha8</version>
</dependency>
-
-
-
-
Aforementioned classes are from the org.jboss.weld.environment.se
package.
-
-
-
-
-
Weld Probe Enhancements
-
-
-
Since the last Alpha releases there were several enhancements to Weld Probe.
- If you are not familiar with Weld Probe, check this introductory blog post first.
-
-
-
A new feature of Probe is that, when the development mode is enabled, it now embeds a tiny information bar directly into the application’s HTML output.
- That makes it easy to navigate to Probe directly from the application anytime.
- Furthermore, if invocation tracking is enabled, the information bar helps navigate directly to the invocation tree related to the request that rendered the output.
-
-
-
-
-
-
-
-
-
Additionally, the following Probe improvements were implemented:
-
-
-
- -
-
tracked invocations are now grouped into a invocation tree instead of being tracked in isolation
-
- -
-
a special type of edges is now used in the overview graph to represent a "declared by" relation (when a bean declares a producer method or field)
-
- -
-
Instance<?> injection points are now treated specially - a resolved bean is show as injection point’s dependency
-
-
-
-
-
-
-
-
-
diff --git a/news/tags/release/page/7.html b/news/tags/release/page/7.html
index da3c95d2..4a79f6f0 100644
--- a/news/tags/release/page/7.html
+++ b/news/tags/release/page/7.html
@@ -141,6 +141,160 @@
+
+
+ Weld 3.0.0.Alpha8
+
+
+ 2015-4-21
+
+
+
+ release
+ ,
+ cdi2
+
+
+
+ Jozef Hartinger
+
+
+
+
+
Weld 3.0.0.Alpha8 has been released.
+ The main change is the enhanced API for using Weld in Java SE environment. In addition, this release comes with several weld-probe improvements.
+
+
+
Enhanced API for Weld SE
+
+
+
Weld has provided support for the Java SE environment for a long time with the weld-se module.
+ The API provides an easy way for an application to initialize Weld and use it in a standalone mode.
+ On initialization Weld SE scans the classpath for bean archives with the beans.xml
file, similarly to how it’s done in the Java EE environment.
+
+
+
In this release we are extending the API further.
+ This is partially inspired by the current discussion in the CDI expert group where a standardized CDI API for Java SE is being proposed as part of CDI-26.
+
+
+
The following code snippet shows the new API in action:
+
+
+
+
Weld builder = new Weld()
.disableDiscovery()
.packages(Main.class, Utils.class)
.interceptors(TransactionalInterceptor.class)
.property("org.jboss.weld.construction.relaxed", true);
try (WeldContainer weld = builder.initialize()) {
MyBean bean = weld.select(MyBean.class).get();
System.out.println(bean.computeResult());
}
+
+
+
+
There are several new things to notice:
+
+
+
+ -
+
the Weld
class is used as a builder to configure Weld before it is initialized
+
+ -
+
automatic scanning can be disabled
+
+ -
+
instead of scanning, classes or packages can be selected explicitly. All classes in those packages will be managed by Weld
+
+ -
+
interceptors, decorators, extensions and Weld-specific configuration options can be specified using the builder
+
+ -
+
WeldContainer
now implements AutoCloseable
and can therefore be used in a try-with-resources
block. At any time that execution gets outside of the code block, the Weld instance is shut down and all managed instances are safely destroyed.
+
+
+
+
+
It is also possible to start multiple independent Weld instances:
+
+
+
+
new Weld().disableDiscovery().containerId("one").beanClasses(MyBean.class).initialize();
new Weld().disableDiscovery().containerId("two").beanClasses(OtherBean.class).initialize();
MyBean bean = WeldContainer.instance("one").select(MyBean.class).get();
System.out.println(bean.computeResult());
WeldContainer.instance("one").shutdown();
WeldContainer.instance("two").shutdown();
+
+
+
+
Here, two independent WeldContainer
instances are initialized.
+ Each of them is given a unique ID.
+ The ID can subsequently be used to obtain a WeldContainer
reference in a different place of the code.
+ One possible use-case this enables is for a library or framework (e.g. a testing framework) to use an embedded instance of Weld internally for its own needs (dependency injection, events, extensibility).
+ This instance would not interfere with the Weld instance used by the application.
+
+
+
Obviously, automatic classpath scanning can still be used as before:
+
+
+
+
try (WeldContainer weld = new Weld().enableDiscovery().initialize()) {
MyBean bean = weld.select(MyBean.class).get();
System.out.println(bean.computeResult());
}
+
+
+
+
+
To play with the new API use the following dependency in you Maven project:
+
+
+
+
<dependency>
<groupId>org.jboss.weld.se</groupId>
<artifactId>weld-se-core</artifactId>
<version>3.0.0.Alpha8</version>
</dependency>
+
+
+
+
Aforementioned classes are from the org.jboss.weld.environment.se
package.
+
+
+
+
+
Weld Probe Enhancements
+
+
+
Since the last Alpha releases there were several enhancements to Weld Probe.
+ If you are not familiar with Weld Probe, check this introductory blog post first.
+
+
+
A new feature of Probe is that, when the development mode is enabled, it now embeds a tiny information bar directly into the application’s HTML output.
+ That makes it easy to navigate to Probe directly from the application anytime.
+ Furthermore, if invocation tracking is enabled, the information bar helps navigate directly to the invocation tree related to the request that rendered the output.
+
+
+
+
+
+
+
+
+
Additionally, the following Probe improvements were implemented:
+
+
+
+ -
+
tracked invocations are now grouped into a invocation tree instead of being tracked in isolation
+
+ -
+
a special type of edges is now used in the overview graph to represent a "declared by" relation (when a bean declares a producer method or field)
+
+ -
+
Instance<?> injection points are now treated specially - a resolved bean is show as injection point’s dependency
+
+
+
+
+
+
+
+
+
Weld 3.0.0.Alpha5
diff --git a/sitemap.xml b/sitemap.xml
index 2cfd2417..1354663a 100644
--- a/sitemap.xml
+++ b/sitemap.xml
@@ -2,37 +2,37 @@
https://weld.cdi-spec.org/bug/
- 2024-07-03
+ 2024-08-27
0.5
weekly
https://weld.cdi-spec.org/community/
- 2024-07-03
+ 2024-08-27
0.5
weekly
https://weld.cdi-spec.org/dist/
- 2024-07-03
+ 2024-08-27
1
daily
https://weld.cdi-spec.org/documentation/
- 2024-07-03
+ 2024-08-27
0.5
weekly
https://weld.cdi-spec.org/download/
- 2024-07-03
+ 2024-08-27
0.5
weekly
https://weld.cdi-spec.org/
- 2024-07-03
+ 2024-08-27
0.5
weekly
@@ -582,9 +582,15 @@
1
weekly
+
+ https://weld.cdi-spec.org/news/2024/08/27/weld-513Final/
+ 2024-08-27
+ 1
+ weekly
+
https://weld.cdi-spec.org/news/
- 2024-07-03
+ 2024-08-27
1
daily