diff --git a/news/page/14.html b/news/page/14.html
index 786a3499..a92a627d 100644
--- a/news/page/14.html
+++ b/news/page/14.html
@@ -141,6 +141,157 @@
+
+
+
+ 2016-4-28
+
+
+
+ release
+ ,
+ cdi2
+
+
+
+ Martin Kouba
+
+
+
+
+
The next experimental Weld version has been released!
+ See also the release details.
+ Thanks to everyone involved in this release!
+
+
+
This release includes a lot of bugfixes and improvements (e.g. all the notable tasks implemented in the latest stable version: Weld 2.3.4.Final).
+ However, the main goal of this release is to align with CDI API 2.0.Alpha4, and in particular to implement the current version of "metadata builders" API (CDI-558).
+ So that everyone can play with the API, discover possibilities and find potential issues.
+ Note that this release also introduces a non-standard experimental feature: Weld SE synthetic container lifecycle event observers.
+ So it should be even easier to get started - no extension class is needed in Weld SE.
+
+
+
+
+
+
Note that we don’t use the term "builder" because there is no build() method in the API.
+ Also note that the API is not intended to cover every possible case.
+ Instead, we would like to help with common tasks.
+ And if necessary, an extension developer can always use the original replacement methods for more complicated stuff.
+
+
+
+
+ -
+
an extension developer receives a configurator instance from a container lifecycle event
+
+ -
+
a configurator instance is always automatically processed at the end of the observer invocation
+
+ -
+
for bean discovery events (all events starting with Process):
+
+
+ -
+
configureX() methods return the same configurator instance (for the given observer method invocation)
+
+ -
+
the configurator is initialized/preconfigured with the component being processed, e.g. ProcessAnnotatedType.configureAnnotatedType() returns a configurator initialized with ProcessAnnotatedType.getAnnotatedType()
+
+ -
+
the result of the configurator will automatically replace the original component (e.g. AnnotatedType in case of ProcessAnnotatedType)
+
+ -
+
replacement methods (e.g. ProcessAnnotatedType.setAnnotatedType()) should not be used together with configurators (CDI-596)
+
+
+
+ -
+
for application lifecycle events (e.g. AfterBeanDiscovery):
+
+
+ -
+
addX() methods always return a new configurator instance
+
+ -
+
the configurator is always uninitialized/empty, but we should probably define some default values wherever it makes sense (e.g. Reception for observer methods)
+
+ -
+
the result of the configurator will be automatically added (e.g. Bean in case of AfterBeanDiscovery.addBean())
+
+
+
+
+
+
+
We have prepared some simple examples - see below.
+ More advanced examples can be found in the TCK test cases.
+ And as usual - feel free to add comments to this blog post. Any feedback is appreciated!
+
+
+
+
+
BeforeBeanDiscovery example
+
+
+
+
@Singleton
class MyService {
// This class is not placed in a bean archive
}
class MyExtension implements Extension {
void beforeBeanDiscovery(@Observes BeforeBeanDiscovery event) {
// Add MyService to the set of discovered classes and replace @Singleton with @ApplicationScoped
event.addAnnotatedType(MyService.class.getName(), MyService.class)
.remove(Singleton.class)
.add(ApplicationScoped.Literal.INSTANCE);
}
}
+
+
+
+
+
+
ProcessAnnotatedType example
+
+
+
+
class MyExtension implements Extension {
void processAnnotatedType(@Observes @WithAnnotations({ Observes.class, ObservesAsync.class }) ProcessAnnotatedType<?> event) {
// Add interceptor binding to all methods annotated with @Observes or @ObservesAsync
event.configureAnnotatedType()
.filterMethods(MyExtension::isObserver)
.forEach(methodConfigurator -> methodConfigurator.add(Monitored.Literal.INSTANCE))
}
static boolean isObserver(AnnotatedMethod<?> annotatedMethod) {
return annotatedMethod.isAnnotationPresent(Observes.class) || annotatedMethod.isAnnotationPresent(ObservesAsync.class);
}
}
+
+
+
+
+
+
ProcessBeanAttributes example
+
+
+
+
class MyExtension implements Extension {
void processBeanAttributes(@Observes ProcessBeanAttributes<?> event) {
// For all beans remove the IllegalBeanType from the set of bean types
if (event.getBeanAttributes().getTypes().contains(IllegalBeanType.class)) {
Set<Type> legalTypes = new HashSet(event.getBeanAttributes().getTypes());
legalTypes.remove(IllegalBeanType.class);
event.configureBeanAttributes().types(legalTypes);
}
}
}
+
+
+
+
+
+
AfterBeanDiscovery example
+
+
+
+
class MyExtension implements Extension {
void afterBeanDiscovery(@Observes AfterBeanDiscovery event) {
// Add a new synthetic observer method - no need to use the fluent API
ObserverMethodConfigurator<Foo> configurator = event.<Foo>addObserverMethod();
configurator.observedType(Foo.class);
configurator.reception(Reception.ALWAYS);
configurator.transactionPhase(TransactionPhase.IN_PROGRESS);
configurator.notifyWith((foo) -> System.out.println("Foo observed: " + foo));
// Add dependent bean - Integer between 0 and 999
event.addBean().addType(Integer.class).addQualifier(Random.Literal.INSTANCE)
.produceWith(() -> new java.util.Random().nextInt(1000))
}
}
+
+
+
+
+
+
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/page/17.html b/news/page/17.html
index f3a00605..5ffe1455 100644
--- a/news/page/17.html
+++ b/news/page/17.html
@@ -141,6 +141,160 @@
+
+
+
+ 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
@@ -894,62 +1048,6 @@ Give it a try!
-
-
- 2014-9-18
-
-
- Jozef Hartinger
-
-
-
-
-
Today, we released Weld 2.2.5.Final. The fifth mostly bug-fixing release in the series addresses 23 issues.
- In addition, the Servlet module got an update and among other things now supports:
-
-
-
-
-
Talking about documentation we are grateful to Antoine Sabot-Durand for migrating our reference documentation to AsciiDoc.
- We also thank our community contributors Antonin Stefanutti and Stefan Grossmann who contributed with pull requests.
-
-
-
Weld 3.0
-
-
-
In the coming months, our focus will be shifting towards Weld 3.0 - the future reference implementation of CDI 2.0.
- Initially, we plan on releasing Alpha releases every two weeks starting in early October.
-
-
-
The Alpha releases are likely to break compatibility from time to time and will often contain bleeding edge or prototype code.
- The goals is however to give the CDI community a chance to test drive the proposed changes in the CDI specification as soon as possible and give quick feedback to the CDI expert group.
-
-
-
Weld 3.0 will also be a good opportunity to get involved in the development of this open-source project. Interested? See our community web page for more details.
-
-
-
-
-
-
diff --git a/news/page/18.html b/news/page/18.html
index 55be1121..1c941872 100644
--- a/news/page/18.html
+++ b/news/page/18.html
@@ -141,6 +141,62 @@
+
+
+
+ 2014-9-18
+
+
+ Jozef Hartinger
+
+
+
+
+
Today, we released Weld 2.2.5.Final. The fifth mostly bug-fixing release in the series addresses 23 issues.
+ In addition, the Servlet module got an update and among other things now supports:
+
+
+
+
+
Talking about documentation we are grateful to Antoine Sabot-Durand for migrating our reference documentation to AsciiDoc.
+ We also thank our community contributors Antonin Stefanutti and Stefan Grossmann who contributed with pull requests.
+
+
+
Weld 3.0
+
+
+
In the coming months, our focus will be shifting towards Weld 3.0 - the future reference implementation of CDI 2.0.
+ Initially, we plan on releasing Alpha releases every two weeks starting in early October.
+
+
+
The Alpha releases are likely to break compatibility from time to time and will often contain bleeding edge or prototype code.
+ The goals is however to give the CDI community a chance to test drive the proposed changes in the CDI specification as soon as possible and give quick feedback to the CDI expert group.
+
+
+
Weld 3.0 will also be a good opportunity to get involved in the development of this open-source project. Interested? See our community web page for more details.
+
+
+
+
+
+
-
-
- 2013-10-22
-
-
- Jozef Hartinger
-
-
-
-
-
-
- -
-
OSGi support with Pax CDI
-
- -
-
Improved runtime performance and memory consumption
-
- -
-
Better integration with various Servlet dispatch types
-
- -
-
SLF4j was replaced with jboss-logging
-
- -
-
30 fixed bugs
-
-
-
-
-
The future of Weld-OSGi
-
-
-
Weld-osgi is a framework that allows the CDI programming model to be used in the OSGi environment.
- The framework was developed entirely by the Weld community and became a part of Weld since version 1.2.0
-
-
-
The framework provides three main features:
-
-
-
- -
-
The CDI programming model can be used within OSGi bundles.
-
- -
-
The OSGi service layer and utility facilities are accessible through CDI injection
-
- -
-
The CDI event bus can be used for both inter-bundle communication and delivering OSGi events.
-
-
-
-
-
The weld-osgi framework served as an inspiration for a standardization effort, known as RFC-193 (formerly RFP-146).
- The proposal is now part of the OSGi early draft
-
-
-
Due to the tight schedule of CDI 1.1, weld-osgi did never make it to Weld 2.0 and was therefore left behind, stuck in the gradually abandoned 1.2 branch.
-
-
-
In the meantime, work on the reference implementation of RFC-193 begun. The reference implementation is known as Pax CDI and it is an open-source project hosted on GitHub.
- Pax CDI aims to be portable across OSGi implementations as well as CDI implementations.
-
-
-
We always wanted to bring OSGi support back in Weld 2.1. However, we decided not to revive the weld-osgi framework nor align it to the new RFC-193 specification. Therefore, weld-osgi will not be merged into Weld 2.x code base.
- Instead, we decided to shift our focus towards Pax CDI and make sure it works well with Weld.
- This was done and Weld 2.1.0 is now one of the CDI runtimes supported by Pax CDI. You can play with the current Pax CDI SNAPSHOT
- or wait for the upcoming 0.5 release.
-
-
-
-
-
-
-
-
-
The CDI specification requires the request, conversation and application contexts to be active during every HTTP request.
- Obviously, the CDI contexts are not necessary for every HTTP request. Fetching a static resource is an example of one such request.
-
-
-
In Weld 2.1.0 we optimized the component that handles context activation/deactivation and cut down the overhead.
- In addition, it is now possible to completely suppress CDI context activation on certain types of HTTP requests should this minimized overhead still be undesired.
- See Martin’s blog post or
- the reference documentation for more details.
-
-
-
-
-
Acknowledgement
-
-
-
We greatly appreciate your contributions to this release. Big thanks go to: Martin Kouba, Matúš Abaffy, Matej Briškár, Marko Lukša, Stuart Douglas, Marek Schmidt, Ron Šmeral, Tomáš Remeš, Max Pimm, Jesse McConnell, Harald Wellmann and Dirk Strauss.
-
-
-
-
-
-
-
diff --git a/news/page/19.html b/news/page/19.html
index 139a2648..895ee141 100644
--- a/news/page/19.html
+++ b/news/page/19.html
@@ -141,6 +141,118 @@
+
+
+
+ 2013-10-22
+
+
+ Jozef Hartinger
+
+
+
+
+
+
+ -
+
OSGi support with Pax CDI
+
+ -
+
Improved runtime performance and memory consumption
+
+ -
+
Better integration with various Servlet dispatch types
+
+ -
+
SLF4j was replaced with jboss-logging
+
+ -
+
30 fixed bugs
+
+
+
+
+
The future of Weld-OSGi
+
+
+
Weld-osgi is a framework that allows the CDI programming model to be used in the OSGi environment.
+ The framework was developed entirely by the Weld community and became a part of Weld since version 1.2.0
+
+
+
The framework provides three main features:
+
+
+
+ -
+
The CDI programming model can be used within OSGi bundles.
+
+ -
+
The OSGi service layer and utility facilities are accessible through CDI injection
+
+ -
+
The CDI event bus can be used for both inter-bundle communication and delivering OSGi events.
+
+
+
+
+
The weld-osgi framework served as an inspiration for a standardization effort, known as RFC-193 (formerly RFP-146).
+ The proposal is now part of the OSGi early draft
+
+
+
Due to the tight schedule of CDI 1.1, weld-osgi did never make it to Weld 2.0 and was therefore left behind, stuck in the gradually abandoned 1.2 branch.
+
+
+
In the meantime, work on the reference implementation of RFC-193 begun. The reference implementation is known as Pax CDI and it is an open-source project hosted on GitHub.
+ Pax CDI aims to be portable across OSGi implementations as well as CDI implementations.
+
+
+
We always wanted to bring OSGi support back in Weld 2.1. However, we decided not to revive the weld-osgi framework nor align it to the new RFC-193 specification. Therefore, weld-osgi will not be merged into Weld 2.x code base.
+ Instead, we decided to shift our focus towards Pax CDI and make sure it works well with Weld.
+ This was done and Weld 2.1.0 is now one of the CDI runtimes supported by Pax CDI. You can play with the current Pax CDI SNAPSHOT
+ or wait for the upcoming 0.5 release.
+
+
+
+
+
+
+
+
+
The CDI specification requires the request, conversation and application contexts to be active during every HTTP request.
+ Obviously, the CDI contexts are not necessary for every HTTP request. Fetching a static resource is an example of one such request.
+
+
+
In Weld 2.1.0 we optimized the component that handles context activation/deactivation and cut down the overhead.
+ In addition, it is now possible to completely suppress CDI context activation on certain types of HTTP requests should this minimized overhead still be undesired.
+ See Martin’s blog post or
+ the reference documentation for more details.
+
+
+
+
+
Acknowledgement
+
+
+
We greatly appreciate your contributions to this release. Big thanks go to: Martin Kouba, Matúš Abaffy, Matej Briškár, Marko Lukša, Stuart Douglas, Marek Schmidt, Ron Šmeral, Tomáš Remeš, Max Pimm, Jesse McConnell, Harald Wellmann and Dirk Strauss.
+
+
+
+
+
+
+
Weld 2.1.0.Beta2 tip
diff --git a/news/page/2.html b/news/page/2.html
index 8ce78356..f8a80e50 100644
--- a/news/page/2.html
+++ b/news/page/2.html
@@ -141,6 +141,106 @@
+
+
+
+ 2024-2-26
+
+
+
+ release
+
+
+
+ Matej Novotny
+
+
+
+
+
Weld Core 6.0.0.Beta1 along with Weld API 6.0.Beta2 are the latest two artifacts you’re going to need if you’re looking for an implementation of the CDI API 4.1.0.Beta1.
+
+
+
Changes based on CDI specification since last 6.x version:
+
+
+
+ -
+
The method invoker API in CDI has been simplified and the transformer functionality removed from the specification (WELD-2765)
+
+
+ -
+
Weld API introduced WeldInvokerBuilder which retains all of the transformers/wrappers that were originally present
+
+ -
+
We also added some more validation and other tweaks but the whole functionality is still being worked on as part of the follow up release
+
+
+
+ -
+
Support declaring @Priority on producers (WELD-2768)
+
+
+ -
+
BeanManager implementations in Weld now correctly extend ELAwareBeanManager from newly introduced CDI API module (WELD-2769)
+
+
+ -
+
Implemented programmatic access to assignability rules on BeanManager (WELD-2774)
+
+
+
+
+
+
Other changes and bugfixes:
+
+
+
+ -
+
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)
+
+ -
+
Weld SE - manually registered portable extensions now reside in synthetic bean archive instead of their own (WELD-2776)
+
+ -
+
Updated CI setup to make sure bulk of our tests is running against JDK 21 (WELD-2777)
+
+
+
+
+
As always, if you find further issues with Weld 6, let us know and we’ll try to help.
+
+
+
+
+
-
-
-
- 2023-6-12
-
-
-
- release
-
-
-
- Matej Novotny
-
-
-
-
-
It’s time for some minor updates and fixes, Weld 5.1.1.Final is now available!
-
-
-
Main highlights are as follows:
-
-
-
- -
-
Fix bean type assignability for beans with recursive generic types (WELD-2738)
-
- -
-
Failing validation for pasivation capability, Weld should throw DeploymentException instead of DefinitionException (WELD-2741)
-
- -
-
Avoid firing ProcessInjectionTarget multiple times if a specialized bean was vetoed (WELD-2742)
-
- -
-
BeanManager#getReference should not create a child CreationalContext instance (WELD-2743)
-
-
- -
-
Fix how Weld defines proxies to avoid problems in JDK 17+ along with the newest JBoss Class File Writer (1.3.0.Final) (WELD-2744)
-
- -
-
Correction to documentation which incorrectly suggested @ManagedBean was a bean defining annotation (WELD-2737)
-
-
-
-
-
As always, if you find further issues 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 5aa0f314..23dca555 100644
--- a/news/page/3.html
+++ b/news/page/3.html
@@ -141,6 +141,69 @@
+
+
+
+ 2023-6-12
+
+
+
+ release
+
+
+
+ Matej Novotny
+
+
+
+
+
It’s time for some minor updates and fixes, Weld 5.1.1.Final is now available!
+
+
+
Main highlights are as follows:
+
+
+
+ -
+
Fix bean type assignability for beans with recursive generic types (WELD-2738)
+
+ -
+
Failing validation for pasivation capability, Weld should throw DeploymentException instead of DefinitionException (WELD-2741)
+
+ -
+
Avoid firing ProcessInjectionTarget multiple times if a specialized bean was vetoed (WELD-2742)
+
+ -
+
BeanManager#getReference should not create a child CreationalContext instance (WELD-2743)
+
+
+ -
+
Fix how Weld defines proxies to avoid problems in JDK 17+ along with the newest JBoss Class File Writer (1.3.0.Final) (WELD-2744)
+
+ -
+
Correction to documentation which incorrectly suggested @ManagedBean was a bean defining annotation (WELD-2737)
+
+
+
+
+
As always, if you find further issues with Weld 5, let us know and we’ll try to help.
+
+
+
+
+
-
-
-
- 2022-4-29
-
-
-
- release
-
-
-
- Matej Novotny
-
-
-
-
-
CDI 4 has passed its Final ballot and is now available in Maven Central.
- Some of you may have played with it already, but where is the fun in it, if you don’t have a Final implementation, right?
- Have no fear, Weld 5 Final is here!
-
-
-
As usual, there is Weld 5.0.Final API as well as Weld 5.0.0.Final core impl.
-
-
-
It is very much the same as CR2, with some additional tweaks and fixes that came to light when working on integrations within EE servers.
- That’s right, EE servers are already making progress towards integrating CDI 4 and Weld 5.
- Folks over at Open Liberty did their Weld 5 homework about a week ago and WildFly now has a pending pull request that adds missing bits for CDI 4 support.
- It might still be a while before there is a Beta WildFly release, but if you have the nerves, you can build the SNAPSHOT at least.
-
-
-
Back on the topic of changes, here is a list of fixes from CR2 to Final:
-
-
-
- -
-
Self-interception can now be used on protected methods, params and return types (WELD-2712)
-
- -
-
Rewieved Weld examples and made sure they run for EE 10 (WELD-2708)
-
- -
-
Review Weld 5 documentation (WELD-2696)
-
-
- -
-
Note that the servlet part is still outdated and being worked on as we need to see if there is workable EE 10 variant, see WELD-2716
-
- -
-
We expect that this will be sorted by the time we ship 5.0.1.Final
-
-
-
- -
-
Firing of the Startup event for web modules can happen too early (WELD-2717)
-
- -
-
Synthetic beans coming from Build Compatible extension should be registered under their respective extensions (WELD-2718)
-
- -
-
Exceptions thrown during execution of Build Compatible extensions now correctly preserve their cause (WELD-2710)
-
- -
-
Some of our SE testing was being skipped ever since Groovy dependency update, this is now corrected (WELD-2714)
-
-
-
-
-
-
-
diff --git a/news/page/4.html b/news/page/4.html
index 5317505d..ce93e699 100644
--- a/news/page/4.html
+++ b/news/page/4.html
@@ -141,6 +141,83 @@
+
+
+
+ 2022-4-29
+
+
+
+ release
+
+
+
+ Matej Novotny
+
+
+
+
+
CDI 4 has passed its Final ballot and is now available in Maven Central.
+ Some of you may have played with it already, but where is the fun in it, if you don’t have a Final implementation, right?
+ Have no fear, Weld 5 Final is here!
+
+
+
As usual, there is Weld 5.0.Final API as well as Weld 5.0.0.Final core impl.
+
+
+
It is very much the same as CR2, with some additional tweaks and fixes that came to light when working on integrations within EE servers.
+ That’s right, EE servers are already making progress towards integrating CDI 4 and Weld 5.
+ Folks over at Open Liberty did their Weld 5 homework about a week ago and WildFly now has a pending pull request that adds missing bits for CDI 4 support.
+ It might still be a while before there is a Beta WildFly release, but if you have the nerves, you can build the SNAPSHOT at least.
+
+
+
Back on the topic of changes, here is a list of fixes from CR2 to Final:
+
+
+
+ -
+
Self-interception can now be used on protected methods, params and return types (WELD-2712)
+
+ -
+
Rewieved Weld examples and made sure they run for EE 10 (WELD-2708)
+
+ -
+
Review Weld 5 documentation (WELD-2696)
+
+
+ -
+
Note that the servlet part is still outdated and being worked on as we need to see if there is workable EE 10 variant, see WELD-2716
+
+ -
+
We expect that this will be sorted by the time we ship 5.0.1.Final
+
+
+
+ -
+
Firing of the Startup event for web modules can happen too early (WELD-2717)
+
+ -
+
Synthetic beans coming from Build Compatible extension should be registered under their respective extensions (WELD-2718)
+
+ -
+
Exceptions thrown during execution of Build Compatible extensions now correctly preserve their cause (WELD-2710)
+
+ -
+
Some of our SE testing was being skipped ever since Groovy dependency update, this is now corrected (WELD-2714)
+
+
+
+
+
+
+
Weld 5.0.0.CR2
@@ -606,71 +683,6 @@ More in-depth over
-
-
-
- 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
-
-
-
-
-
-
-
-
-
diff --git a/news/page/5.html b/news/page/5.html
index 13094668..011fbfa3 100644
--- a/news/page/5.html
+++ b/news/page/5.html
@@ -141,6 +141,71 @@
+
+
+
+ 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
+
+
+
+
+
+
+
+
+
-
-
-
- 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:
-
-
-
-
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.
-
-
-
-
-
-
-
diff --git a/news/page/6.html b/news/page/6.html
index a6e4104b..b7e3ac0e 100644
--- a/news/page/6.html
+++ b/news/page/6.html
@@ -141,6 +141,79 @@
+
+
+
+ 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:
+
+
+
+
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.
+
+
+
+
+
+
+
Weld 4.0.0.Beta1
@@ -577,102 +650,6 @@ WildFly Patch
-
-
-
- 2019-11-28
-
-
-
- release
-
-
-
- Matej Novotny
-
-
-
-
-
Weld 3.1.3.Final arrives along with Weld API 3.1.SP2.
- This is a minor update which had a main goal of swapping whole Weld internals from Java EE 8 to Jakarta EE 8.
-
-
-
Fixes and improvements:
-
-
-
- -
-
Weld API/SPI
-
-
- -
-
Weld Core
-
-
- -
-
Core and whole testing was transferred to Jakarta EE GAvs (WELD-2598)
-
- -
-
Properties inside beans.xml now support spec-descriptor-property-replacement on WildFly (WELD-2600)
-
- -
-
Rolling updates delimiter is now correctly ignored for external bean archives (WELD-2596)
-
- -
-
Allow for private final method in intercepted beans, these methods are then ignored during interception but Weld no longer blows up (WELD-2595)
-
-
-
- -
-
Weld Servlet
-
-
- -
-
Other
-
-
-
-
-
-
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 cf8b5c91..ddbe3e94 100644
--- a/news/page/7.html
+++ b/news/page/7.html
@@ -141,6 +141,102 @@
+
+
+
+ 2019-11-28
+
+
+
+ release
+
+
+
+ Matej Novotny
+
+
+
+
+
Weld 3.1.3.Final arrives along with Weld API 3.1.SP2.
+ This is a minor update which had a main goal of swapping whole Weld internals from Java EE 8 to Jakarta EE 8.
+
+
+
Fixes and improvements:
+
+
+
+ -
+
Weld API/SPI
+
+
+ -
+
Weld Core
+
+
+ -
+
Core and whole testing was transferred to Jakarta EE GAvs (WELD-2598)
+
+ -
+
Properties inside beans.xml now support spec-descriptor-property-replacement on WildFly (WELD-2600)
+
+ -
+
Rolling updates delimiter is now correctly ignored for external bean archives (WELD-2596)
+
+ -
+
Allow for private final method in intercepted beans, these methods are then ignored during interception but Weld no longer blows up (WELD-2595)
+
+
+
+ -
+
Weld Servlet
+
+
+ -
+
Other
+
+
+
+
+
+
WildFly Patch
+
+
+
+
If you’re not familiar with patching WildFly, check the FAQ.
+
+
+
+
+
+
+
Weld 3.1.2.Final
@@ -718,161 +814,6 @@ WildFly Patch
-
-
-
- 2018-7-26
-
-
-
- release
-
-
-
- Matej Novotny
-
-
-
-
-
Weld 3.0.5.Final is here and hand in hand with it comes Weld API 3.0.SP4.
- And in case you missed it, there was CDI 2.0.SP1 release as well.
- It comes with few security manager related fixes and Weld is of course compliant with it.
- If you are running on a servlet or in SE, you may need to update it yourself, in case of EE it usually falls to the server to update this dependency for you.
-
-
-
-
- |
- Note
- |
-
- This time around we are not providing a patch for WildFly 13 as there were major changes blocking us from doing so.
- However, Wildfly 14 will contain all of the above updates - Weld core, Weld API, CDI API - so keep an eye out for its release!
- |
-
-
-
-
-
As for updates and fixes, we keep looking at JDK 11 and have done another round of fixing to keep up with adjustments and removals going on in JDK.
- There is a bunch of interceptor/decorator fixes for those of you who indulge in using complex class hierarchies with abstractions, generics and default methods.
- So let’s take a look at them all, shall we?
-
-
-
Fixes and improvements:
-
-
-
- -
-
Weld Core
-
-
- -
-
Fixed possible race condition appearing during bean index creation (WELD-2492)
-
- -
-
Avoid creating unnecessary bean metatada for anonymous and local classes (WELD-2498)
-
- -
-
Corrected decorator subclass creation when said decorator overrides only default method (WELD-2501)
-
- -
-
Avoid optimizing self invocation of private methods in order to avoid IllegalAccessError (WELD-2506)
-
- -
-
Allow interception of abstract, package-private classes with public methods (WELD-2507)
-
- -
-
Fix interception of overriden generic methods invoked via superclass (WELD-2514)
-
- -
-
Implement reflection fallback for qualifier loading when there are multiple instances of the class in the deployment (WELD-2250)
-
- -
-
Make conversation ID parameter detection more robust (WELD-2512)
-
-
-
- -
-
Weld SE
-
-
- -
-
Make default StartMain more container friendly by exiting with error code should an exception appear (WELD-2502)
-
-
- -
-
Fix possible NPE coming from beans.xml merging in complex Weld SE deployment scenarios (WELD-2515)
-
-
-
- -
-
JDK 9/10 and onwards
-
-
- -
-
WeldProvider moved to servlet core module to align it with how Jigsaw handles services (WELD-2435)
-
- -
-
Fixed SE/Servlet resource loading behavior when ForkJoinPool is used on JDK 9+ (WELD-2494)
-
- -
-
Review executability of Weld examples on JDK 10+ (WELD-2495)
-
- -
-
Update to JBoss Classfilewriter 1.2.3.Final which is JDK 11 compliant (WELD-2509)
-
- -
-
If running in JPMS, remove dependency on java.desktop to shrink the footprint (WELD-2504)
-
-
-
- -
-
Probe development tool
-
-
- -
-
Other
-
-
- -
-
We are now looking at testing Weld with JDK 11 on a regular basis and have taken steps to ensure it works (WELD-2516)
-
- -
-
Updated patching profiles for Weld 3 and WFLY, the process is now more automated and configurable (WELD-2491)
-
- -
-
OSGi bundle now import BCEL only optionally (WELD-2499)
-
-
-
-
-
-
-
-
-
diff --git a/news/page/8.html b/news/page/8.html
index 174fbc39..f60a5876 100644
--- a/news/page/8.html
+++ b/news/page/8.html
@@ -141,6 +141,161 @@
+
+
+
+ 2018-7-26
+
+
+
+ release
+
+
+
+ Matej Novotny
+
+
+
+
+
Weld 3.0.5.Final is here and hand in hand with it comes Weld API 3.0.SP4.
+ And in case you missed it, there was CDI 2.0.SP1 release as well.
+ It comes with few security manager related fixes and Weld is of course compliant with it.
+ If you are running on a servlet or in SE, you may need to update it yourself, in case of EE it usually falls to the server to update this dependency for you.
+
+
+
+
+ |
+ Note
+ |
+
+ This time around we are not providing a patch for WildFly 13 as there were major changes blocking us from doing so.
+ However, Wildfly 14 will contain all of the above updates - Weld core, Weld API, CDI API - so keep an eye out for its release!
+ |
+
+
+
+
+
As for updates and fixes, we keep looking at JDK 11 and have done another round of fixing to keep up with adjustments and removals going on in JDK.
+ There is a bunch of interceptor/decorator fixes for those of you who indulge in using complex class hierarchies with abstractions, generics and default methods.
+ So let’s take a look at them all, shall we?
+
+
+
Fixes and improvements:
+
+
+
+ -
+
Weld Core
+
+
+ -
+
Fixed possible race condition appearing during bean index creation (WELD-2492)
+
+ -
+
Avoid creating unnecessary bean metatada for anonymous and local classes (WELD-2498)
+
+ -
+
Corrected decorator subclass creation when said decorator overrides only default method (WELD-2501)
+
+ -
+
Avoid optimizing self invocation of private methods in order to avoid IllegalAccessError (WELD-2506)
+
+ -
+
Allow interception of abstract, package-private classes with public methods (WELD-2507)
+
+ -
+
Fix interception of overriden generic methods invoked via superclass (WELD-2514)
+
+ -
+
Implement reflection fallback for qualifier loading when there are multiple instances of the class in the deployment (WELD-2250)
+
+ -
+
Make conversation ID parameter detection more robust (WELD-2512)
+
+
+
+ -
+
Weld SE
+
+
+ -
+
Make default StartMain more container friendly by exiting with error code should an exception appear (WELD-2502)
+
+
+ -
+
Fix possible NPE coming from beans.xml merging in complex Weld SE deployment scenarios (WELD-2515)
+
+
+
+ -
+
JDK 9/10 and onwards
+
+
+ -
+
WeldProvider moved to servlet core module to align it with how Jigsaw handles services (WELD-2435)
+
+ -
+
Fixed SE/Servlet resource loading behavior when ForkJoinPool is used on JDK 9+ (WELD-2494)
+
+ -
+
Review executability of Weld examples on JDK 10+ (WELD-2495)
+
+ -
+
Update to JBoss Classfilewriter 1.2.3.Final which is JDK 11 compliant (WELD-2509)
+
+ -
+
If running in JPMS, remove dependency on java.desktop to shrink the footprint (WELD-2504)
+
+
+
+ -
+
Probe development tool
+
+
+ -
+
Other
+
+
+ -
+
We are now looking at testing Weld with JDK 11 on a regular basis and have taken steps to ensure it works (WELD-2516)
+
+ -
+
Updated patching profiles for Weld 3 and WFLY, the process is now more automated and configurable (WELD-2491)
+
+ -
+
OSGi bundle now import BCEL only optionally (WELD-2499)
+
+
+
+
+
+
+
+
+
Weld team changes
@@ -621,135 +776,6 @@ WildFly Patch
-
-
-
-
-
-
-
-
In this article I want to bring weld-junit into light.
- You might have heard about or, better still, used our extension for JUnit 4 which has been around for some time now.
- But after getting ourselves acquainted with JUnit 5, we decided we should create another one for JUnit 5.
- In the sections below I will try to introduce the basic usage and ideas behind it, for more in depth information, you can glance the readme file residing directly in the repository.
-
-
-
GAV Coordinates
-
-
-
Here are group and artifact IDs you need to grab the artifact for Maven projects:
-
-
-
-
<dependency>
<groupId>org.jboss.weld</groupId>
<artifactId>weld-junit-parent</artifactId>
<version>${weld.junit.version}</version>
</dependency>
-
-
-
-
-
-
First Steps
-
-
-
You can use the extension as you would any other in JUnit 5, via @ExtendWith from JUnit library along with the name of our extension - org.jboss.weld.junit5.WeldJunit5Extension.
- Alternatively, there is a shorter annotation @org.jboss.weld.junit5.EnableWeld.
- Both of these can be used on class and method level.
-
-
-
Hence your test could look like this:
-
-
-
-
-
@EnableWeld
public class InjectionWithWeldTest {
@Inject
BarBean beanAsField;
@Test
public void testThatItWorks(FooBean beanAsParam) {
assertNotNull(beanAsParam);
beanAsParam.ping();
assertNotNull(beanAsField);
beanAsField.ping();
}
}
-
-
-
-
Behind the scenes, Weld will bootstrap SE container for each test container invocation and tear it down afterwards (works for both, per-method and per-class lifecycle).
- As you might have guessed, Weld will also automatically inject into any fields within the test class which you annotated with @Inject.
- Furthermore, it will attempt to resolve parameters in your test methods in very much the same way.
- But beware, by default Weld will only scan classes from within the test package!
- With this in mind, you can play around with beans to your liking.
-
-
-
-
-
Dude, Where Is My Container?
-
-
-
Good point, when working with Weld SE you normally have the power to customize container bootstrap and, once running, to query it for beans, fire events and so on.
- And you shall retain that right!
-
-
-
Only you are going to need a public field with type org.jboss.weld.junit5.WeldInitiator which you annotate with @org.jboss.weld.junit5.WeldSetup.
- This class has a bunch of static method which will allow you to customize the boostrap and it also works as a handle to grasp the WeldContainer running below.
-
-
-
Too much talk, not enough code, so here we go:
-
-
-
-
-
@ExtendWith(WeldJUnit5Extension.class)
public class WeldJUnit5CustomizedTest {
@WeldSetup
public WeldInitiator weld = WeldInitiator.of(WeldInitiator.createWeld()
.alternatives(FooAlternative.class)
.beanClasses(Foo.class, FooAlternative.class)
.enableInterceptors(MyInterceptor.class));
@Inject
Foo bean; // this will be FooAlternative in the end
@Test
public void testWeldContainerUsage() {
weld.event().select(MyPayload.class).fire(new MyPayload());
weld.select(Foo.class).isResolvable();
}
}
-
-
-
-
-
-
Help, I Am Stuck With JUnit 4
-
-
-
-
They are both very similar and easy to master.
- The only notable difference is that in JUnit 4 you always need the initiator class - org.jboss.weld.junit4.WeldInitiator.
-
-
-
-
-
What If I Would Like To…
-
-
-
If you’re stuck and need a helping hand, we are listening on the usual channels - mailing list, Stack Overflow, Gitter, IRC, GitHub.
-
-
-
It might also be the case that we forgot about something quite important, so don’t hesitate to reach to us through those channels, or open a GitHub issue straight away.
- We are happy for any kind of feedback we can get.
-
-
-
-
-
-
diff --git a/news/page/9.html b/news/page/9.html
index 4860d252..d55fe64f 100644
--- a/news/page/9.html
+++ b/news/page/9.html
@@ -141,6 +141,135 @@
+
+
+
+
+
+
+
+
In this article I want to bring weld-junit into light.
+ You might have heard about or, better still, used our extension for JUnit 4 which has been around for some time now.
+ But after getting ourselves acquainted with JUnit 5, we decided we should create another one for JUnit 5.
+ In the sections below I will try to introduce the basic usage and ideas behind it, for more in depth information, you can glance the readme file residing directly in the repository.
+
+
+
GAV Coordinates
+
+
+
Here are group and artifact IDs you need to grab the artifact for Maven projects:
+
+
+
+
<dependency>
<groupId>org.jboss.weld</groupId>
<artifactId>weld-junit-parent</artifactId>
<version>${weld.junit.version}</version>
</dependency>
+
+
+
+
+
+
First Steps
+
+
+
You can use the extension as you would any other in JUnit 5, via @ExtendWith from JUnit library along with the name of our extension - org.jboss.weld.junit5.WeldJunit5Extension.
+ Alternatively, there is a shorter annotation @org.jboss.weld.junit5.EnableWeld.
+ Both of these can be used on class and method level.
+
+
+
Hence your test could look like this:
+
+
+
+
+
@EnableWeld
public class InjectionWithWeldTest {
@Inject
BarBean beanAsField;
@Test
public void testThatItWorks(FooBean beanAsParam) {
assertNotNull(beanAsParam);
beanAsParam.ping();
assertNotNull(beanAsField);
beanAsField.ping();
}
}
+
+
+
+
Behind the scenes, Weld will bootstrap SE container for each test container invocation and tear it down afterwards (works for both, per-method and per-class lifecycle).
+ As you might have guessed, Weld will also automatically inject into any fields within the test class which you annotated with @Inject.
+ Furthermore, it will attempt to resolve parameters in your test methods in very much the same way.
+ But beware, by default Weld will only scan classes from within the test package!
+ With this in mind, you can play around with beans to your liking.
+
+
+
+
+
Dude, Where Is My Container?
+
+
+
Good point, when working with Weld SE you normally have the power to customize container bootstrap and, once running, to query it for beans, fire events and so on.
+ And you shall retain that right!
+
+
+
Only you are going to need a public field with type org.jboss.weld.junit5.WeldInitiator which you annotate with @org.jboss.weld.junit5.WeldSetup.
+ This class has a bunch of static method which will allow you to customize the boostrap and it also works as a handle to grasp the WeldContainer running below.
+
+
+
Too much talk, not enough code, so here we go:
+
+
+
+
+
@ExtendWith(WeldJUnit5Extension.class)
public class WeldJUnit5CustomizedTest {
@WeldSetup
public WeldInitiator weld = WeldInitiator.of(WeldInitiator.createWeld()
.alternatives(FooAlternative.class)
.beanClasses(Foo.class, FooAlternative.class)
.enableInterceptors(MyInterceptor.class));
@Inject
Foo bean; // this will be FooAlternative in the end
@Test
public void testWeldContainerUsage() {
weld.event().select(MyPayload.class).fire(new MyPayload());
weld.select(Foo.class).isResolvable();
}
}
+
+
+
+
+
+
Help, I Am Stuck With JUnit 4
+
+
+
+
They are both very similar and easy to master.
+ The only notable difference is that in JUnit 4 you always need the initiator class - org.jboss.weld.junit4.WeldInitiator.
+
+
+
+
+
What If I Would Like To…
+
+
+
If you’re stuck and need a helping hand, we are listening on the usual channels - mailing list, Stack Overflow, Gitter, IRC, GitHub.
+
+
+
It might also be the case that we forgot about something quite important, so don’t hesitate to reach to us through those channels, or open a GitHub issue straight away.
+ We are happy for any kind of feedback we can get.
+
+
+
+
+
+
Weld 2.4.6.Final
@@ -627,203 +756,6 @@ WildFly Patch
-
-
-
-
-
-
-
-
Last year Weld team announced the weld-vertx project (see also Weld meets Vert.x and Update on weld-vertx articles).
- The goal was clear - bring the CDI programming model into the Vert.x ecosystem.
- Since then, several things have changed.
- Two new modules were added, CDI 2 and Weld 3 is now used by default, and two final versions were released.
- I think it’s a good time to summarize the features and plans for future.
-
-
-
What Is It Good For?
-
-
-
First of all, it offers a mature component model for business logic in your Vert.x applications.
- A reasonable component model helps making your applications maintainable and scalable in terms of development and reusability.
- So the primary intention is to implement the business logic as CDI beans and use Vert.x APIs for everything else.
-
-
-
Modules
-
-
So far there are four modules available:
-
-
-
- -
-
The Core module starts/stops the Weld SE container and to notifies CDI observer methods when a message is sent via Vert.x event bus. Also you can inject io.vertx.core.Vertx and io.vertx.core.Context in any CDI bean.
-
- -
-
The Web module allows to configure the router (a component responsible to find the "logic" to handle an HTTP request) in a declarative way, using @org.jboss.weld.vertx.web.WebRoute annotation. Of course, you can register routes programatically. But what if there are hundreds of routes? The more complicated the REST API is the more difficult it is to maintain the code.
-
- -
-
The Service Proxy module makes it possible to inject and invoke service proxies (as defined in https://github.com/vert-x3/vertx-service-proxy).
-
- -
-
The Probe module enables Weld Probe development tool in a Vert.x application.
-
-
-
-
-
-
-
-
How Do I Use It In My Vert.x Webapp?
-
-
-
Let’s enhance an existing webapp in four simple steps.
-
-
-
1. Project Configuration
-
-
Jus add the following dependency to your pom.xml and beans.xml into src/main/resources/META-INF (this will enable CDI).
-
-
-
-
<dependency>
<groupId>org.jboss.weld.vertx</groupId>
<artifactId>weld-vertx-web</artifactId>
<version>${version.weld-vertx}</version>
</dependency>
-
-
-
-
-
- |
- Note
- |
-
- This also brings in org.jboss.weld.vertx:weld-vertx-core, Vert.x and Weld dependencies.
- |
-
-
-
-
-
-
2. Start CDI Container
-
-
Deploy WeldWebVerticle and configure router:
-
-
-
-
class MyVertxApp {
public static void main(String[] args) {
final Vertx vertx = Vertx.vertx();
// ...deploy other existing verticles
final WeldWebVerticle weldVerticle = new WeldWebVerticle();
vertx.deployVerticle(weldVerticle, result -> {
if (result.succeeded()) {
vertx.createHttpServer().requestHandler(weldVerticle.createRouter()::accept).listen(8080);
}
});
}
}
-
-
-
-
-
3. Observe Events
-
-
Create a CDI observer method to consume messages from the Vert.x event bus.
- @VertxConsumer qualifier is used to specify the address the consumer will be registered to.
- VertxEvent is a wrapper of a Vert.x message.
-
-
-
-
@ApplicationScoped
class HelloBean {
void consumerWithDependencies(@Observes @VertxConsumer("hello.address") VertxEvent event, HelloService service) {
// Reply to the message - io.vertx.core.eventbus.Message.reply(Object)
event.setReply(service.hello());
}
}
-
-
-
-
-
- |
- Note
- |
-
- Since we’re working with regular observer methods, additional parameters may be declared (next to the event parameter) - these parameters are injection points.
- |
-
-
-
-
-
-
4. Declare Routes
-
-
Annotate a class implementing Handler<RoutingContext> with @org.jboss.weld.vertx.web.WebRoute:
-
-
-
-
@WebRoute("/hello") // Matches all HTTP methods
class HelloHandler implements Handler<RoutingContext> {
@Inject
HelloService service;
@Override
public void handle(RoutingContext ctx) {
ctx.response().setStatusCode(200).end(service.hello());
}
}
-
-
-
-
This will be translated into something like:
-
-
-
-
void integrationPseudoCode() {
HelloHandler hello = produceInjectedInstanceOfHelloHandler();
Router router = obtainRouterInstance();
router.route("/hello").handler(hello);
}
-
-
-
-
-
- |
- Note
- |
-
- @WebRoute is repeatable, i.e. if multiple annotations are declared on a handler class a single handler instance is used for multiple routes.
- |
-
-
-
-
-
-
5. Enjoy and Celebrate
-
-
And that’s it.
- Fairly straightforward, isn’t it?
-
-
-
-
-
-
Future and Plans
-
-
-
So far there are no new features on the roadmap.
- The plan is to provide bugfix releases as needed.
- But weld-vertx is an open source project and so the future is in hands of the community.
- Feel free to create issues, share ideas, throw feature requests and send pull requests!
-
-
-
-
-
-
diff --git a/news/tags/release/index.html b/news/tags/release/index.html
index b7ccdbf9..f4959503 100644
--- a/news/tags/release/index.html
+++ b/news/tags/release/index.html
@@ -141,6 +141,60 @@
+
+
+
+ 2024-12-16
+
+
+
+ release
+
+
+
+ Matej Novotny
+
+
+
+
+
A small update for Weld 5.1 (5.1.4.Final) has been released.
+
+
+
List of changes from 5.1.3.Final version:
+
+
+
+ -
+
Fix resource injection into beans added via extensions (WELD-2798)
+
+ -
+
Prevent file leak in Weld’s ServiceLoader (WELD-2800)
+
+
+ -
+
Deprecate WeldCrossContextFilter, to be removed in Weld 6 (WELD-2803)
+
+ -
+
Update custom TCK exclusion list used for relaxed mode testing (WELD-2806)
+
+
+
+
+
+
+
-
-
-
- 2023-6-12
-
-
-
- release
-
-
-
- Matej Novotny
-
-
-
-
-
It’s time for some minor updates and fixes, Weld 5.1.1.Final is now available!
-
-
-
Main highlights are as follows:
-
-
-
- -
-
Fix bean type assignability for beans with recursive generic types (WELD-2738)
-
- -
-
Failing validation for pasivation capability, Weld should throw DeploymentException instead of DefinitionException (WELD-2741)
-
- -
-
Avoid firing ProcessInjectionTarget multiple times if a specialized bean was vetoed (WELD-2742)
-
- -
-
BeanManager#getReference should not create a child CreationalContext instance (WELD-2743)
-
-
- -
-
Fix how Weld defines proxies to avoid problems in JDK 17+ along with the newest JBoss Class File Writer (1.3.0.Final) (WELD-2744)
-
- -
-
Correction to documentation which incorrectly suggested @ManagedBean was a bean defining annotation (WELD-2737)
-
-
-
-
-
As always, if you find further issues 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 8d9201ba..8d6d1c4c 100644
--- a/news/tags/release/page/2.html
+++ b/news/tags/release/page/2.html
@@ -141,6 +141,69 @@
+
+
+
+ 2023-6-12
+
+
+
+ release
+
+
+
+ Matej Novotny
+
+
+
+
+
It’s time for some minor updates and fixes, Weld 5.1.1.Final is now available!
+
+
+
Main highlights are as follows:
+
+
+
+ -
+
Fix bean type assignability for beans with recursive generic types (WELD-2738)
+
+ -
+
Failing validation for pasivation capability, Weld should throw DeploymentException instead of DefinitionException (WELD-2741)
+
+ -
+
Avoid firing ProcessInjectionTarget multiple times if a specialized bean was vetoed (WELD-2742)
+
+ -
+
BeanManager#getReference should not create a child CreationalContext instance (WELD-2743)
+
+
+ -
+
Fix how Weld defines proxies to avoid problems in JDK 17+ along with the newest JBoss Class File Writer (1.3.0.Final) (WELD-2744)
+
+ -
+
Correction to documentation which incorrectly suggested @ManagedBean was a bean defining annotation (WELD-2737)
+
+
+
+
+
As always, if you find further issues with Weld 5, let us know and we’ll try to help.
+
+
+
+
+
Weld 5.1.0.Final
@@ -902,71 +965,6 @@ More in-depth over
-
-
-
- 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
-
-
-
-
-
-
-
-
-
diff --git a/news/tags/release/page/3.html b/news/tags/release/page/3.html
index ad7fdad3..ef0f9e89 100644
--- a/news/tags/release/page/3.html
+++ b/news/tags/release/page/3.html
@@ -141,6 +141,71 @@
+
+
+
+ 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
+
+
+
+
+
+
+
+
+
-
-
-
- 2019-11-28
-
-
-
- release
-
-
-
- Matej Novotny
-
-
-
-
-
Weld 3.1.3.Final arrives along with Weld API 3.1.SP2.
- This is a minor update which had a main goal of swapping whole Weld internals from Java EE 8 to Jakarta EE 8.
-
-
-
Fixes and improvements:
-
-
-
- -
-
Weld API/SPI
-
-
- -
-
Weld Core
-
-
- -
-
Core and whole testing was transferred to Jakarta EE GAvs (WELD-2598)
-
- -
-
Properties inside beans.xml now support spec-descriptor-property-replacement on WildFly (WELD-2600)
-
- -
-
Rolling updates delimiter is now correctly ignored for external bean archives (WELD-2596)
-
- -
-
Allow for private final method in intercepted beans, these methods are then ignored during interception but Weld no longer blows up (WELD-2595)
-
-
-
- -
-
Weld Servlet
-
-
- -
-
Other
-
-
-
-
-
-
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 2e58a9b8..af5215d6 100644
--- a/news/tags/release/page/4.html
+++ b/news/tags/release/page/4.html
@@ -141,6 +141,102 @@
+
+
+
+ 2019-11-28
+
+
+
+ release
+
+
+
+ Matej Novotny
+
+
+
+
+
Weld 3.1.3.Final arrives along with Weld API 3.1.SP2.
+ This is a minor update which had a main goal of swapping whole Weld internals from Java EE 8 to Jakarta EE 8.
+
+
+
Fixes and improvements:
+
+
+
+ -
+
Weld API/SPI
+
+
+ -
+
Weld Core
+
+
+ -
+
Core and whole testing was transferred to Jakarta EE GAvs (WELD-2598)
+
+ -
+
Properties inside beans.xml now support spec-descriptor-property-replacement on WildFly (WELD-2600)
+
+ -
+
Rolling updates delimiter is now correctly ignored for external bean archives (WELD-2596)
+
+ -
+
Allow for private final method in intercepted beans, these methods are then ignored during interception but Weld no longer blows up (WELD-2595)
+
+
+
+ -
+
Weld Servlet
+
+
+ -
+
Other
+
+
+
+
+
+
WildFly Patch
+
+
+
+
If you’re not familiar with patching WildFly, check the FAQ.
+
+
+
+
+
+
+
Weld 3.1.2.Final
@@ -1442,130 +1538,6 @@ WildFly Patch
-
-
-
- 2017-11-23
-
-
-
- release
-
-
-
- Matej Novotny
-
-
-
-
-
Weld 3.0.2.Final is out and targetting WildFly 11!
- Ever wished you could select events and instances in a truly generic way using just java.lang.reflect.Type?
- Looking for easier way to configure SE container?
- We have a bunch of bugfixes and improvements for you, so read on…
-
-
-
Notable fixes and improvements:
-
-
-
- -
-
Weld Core
-
-
- -
-
Improved subclass generation mechanism for generic interceptors (WELD-2414)
-
- -
-
Fixed OSGi bundling, we missed out one package on last release (WELD-2421)
-
- -
-
Improved behaviour with no-interface EJB view with non-public methods (WELD-2430)
-
- -
-
Corrected proxy creation for signed classes (WELD-2425)
-
-
-
- -
-
Weld SE
-
-
- -
-
Weld API/SPI
-
-
- -
-
WeldInstance has several improvements
-
-
- -
-
It now allows you to select() beans based on java.lang.reflect.Type (WELD-2427)
-
- -
-
WeldInstance.Handler had become lazy which means you can now iterate/filter/sort WeldInstance without actually instantiating beans (WELD-2258)
-
-
-
- -
-
There is new interface in the API - WeldEvent - which can be used in place of well known Event but allows you narrow down event type by using select() with java.lang.reflect.Type (WELD-2427)
-
- -
-
API now contains a String key used to obtain interceptors binding from InvocationContext (WELD-2436)
-
-
-
- -
-
Other
-
-
- -
-
Probe now correctly recognizes beans which have @Priority but aren’t alternatives (WELD-2432)
-
- -
-
Multiple documentation improvements regarding all things, old and new (WELD-2440, WELD-2431, WELD-2434)
-
-
-
-
-
-
-
WildFly Patch
-
-
-
-
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 add456ab..405dcb82 100644
--- a/news/tags/release/page/5.html
+++ b/news/tags/release/page/5.html
@@ -141,6 +141,130 @@
+
+
+
+ 2017-11-23
+
+
+
+ release
+
+
+
+ Matej Novotny
+
+
+
+
+
Weld 3.0.2.Final is out and targetting WildFly 11!
+ Ever wished you could select events and instances in a truly generic way using just java.lang.reflect.Type?
+ Looking for easier way to configure SE container?
+ We have a bunch of bugfixes and improvements for you, so read on…
+
+
+
Notable fixes and improvements:
+
+
+
+ -
+
Weld Core
+
+
+ -
+
Improved subclass generation mechanism for generic interceptors (WELD-2414)
+
+ -
+
Fixed OSGi bundling, we missed out one package on last release (WELD-2421)
+
+ -
+
Improved behaviour with no-interface EJB view with non-public methods (WELD-2430)
+
+ -
+
Corrected proxy creation for signed classes (WELD-2425)
+
+
+
+ -
+
Weld SE
+
+
+ -
+
Weld API/SPI
+
+
+ -
+
WeldInstance has several improvements
+
+
+ -
+
It now allows you to select() beans based on java.lang.reflect.Type (WELD-2427)
+
+ -
+
WeldInstance.Handler had become lazy which means you can now iterate/filter/sort WeldInstance without actually instantiating beans (WELD-2258)
+
+
+
+ -
+
There is new interface in the API - WeldEvent - which can be used in place of well known Event but allows you narrow down event type by using select() with java.lang.reflect.Type (WELD-2427)
+
+ -
+
API now contains a String key used to obtain interceptors binding from InvocationContext (WELD-2436)
+
+
+
+ -
+
Other
+
+
+ -
+
Probe now correctly recognizes beans which have @Priority but aren’t alternatives (WELD-2432)
+
+ -
+
Multiple documentation improvements regarding all things, old and new (WELD-2440, WELD-2431, WELD-2434)
+
+
+
+
+
+
+
WildFly Patch
+
+
+
+
If you’re not familiar with patching WildFly, check the FAQ.
+
+
+
+
+
+
+
Weld 2.4.5.Final
@@ -1075,85 +1199,6 @@ WildFly Patch
-
-
-
- 2016-11-18
-
-
-
- release
-
-
-
- Martin Kouba
-
-
-
-
-
The development of Weld 3 (CDI 2) is underway.
- However, we don’t forget about the maintenance of the stable branch of Weld!
- So I am very pleased to announce the first bugfix version of Weld 2.4 (CDI 1.2).
- See also the release details.
- Thanks to everyone involved in this release!
-
-
-
Notable fixes and improvements:
-
-
-
- -
-
removed false positive warning about Jandex version used (WELD-2231)
-
- -
-
fixed Groovy support - only filter out relevant methods from Groovy objects when generating bean proxies (WELD-2255)
-
- -
-
optimized proxy class generation for "large classes" (WELD-2244)
-
- -
-
improved the way Weld configuration info is logged (WELD-2238)
-
- -
-
Weld SE
-
-
- -
-
added support for nested directories in uber jars, e.g. Spring Boot jar (WELD-2254)
-
- -
-
allow to use CDI.getBeanManager() after BeforeBeanDiscovery is fired (WELD-2256)
-
- -
-
don’t abort container initialization if JandexClassFileServices is unable to load an annotation (WELD-2232)
-
-
-
- -
-
Weld Servlet - document the usage of org.jboss.weld.environment.container.class init param (WELD-2236)
-
-
-
-
-
WildFly Patch
-
-
-
As usual, a patch for WildFly is available. This time the target platform is WildFly 10.1.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 dd80b5ac..b8da3646 100644
--- a/news/tags/release/page/6.html
+++ b/news/tags/release/page/6.html
@@ -141,6 +141,85 @@
+
+
+
+ 2016-11-18
+
+
+
+ release
+
+
+
+ Martin Kouba
+
+
+
+
+
The development of Weld 3 (CDI 2) is underway.
+ However, we don’t forget about the maintenance of the stable branch of Weld!
+ So I am very pleased to announce the first bugfix version of Weld 2.4 (CDI 1.2).
+ See also the release details.
+ Thanks to everyone involved in this release!
+
+
+
Notable fixes and improvements:
+
+
+
+ -
+
removed false positive warning about Jandex version used (WELD-2231)
+
+ -
+
fixed Groovy support - only filter out relevant methods from Groovy objects when generating bean proxies (WELD-2255)
+
+ -
+
optimized proxy class generation for "large classes" (WELD-2244)
+
+ -
+
improved the way Weld configuration info is logged (WELD-2238)
+
+ -
+
Weld SE
+
+
+ -
+
added support for nested directories in uber jars, e.g. Spring Boot jar (WELD-2254)
+
+ -
+
allow to use CDI.getBeanManager() after BeforeBeanDiscovery is fired (WELD-2256)
+
+ -
+
don’t abort container initialization if JandexClassFileServices is unable to load an annotation (WELD-2232)
+
+
+
+ -
+
Weld Servlet - document the usage of org.jboss.weld.environment.container.class init param (WELD-2236)
+
+
+
+
+
WildFly Patch
+
+
+
As usual, a patch for WildFly is available. This time the target platform is WildFly 10.1.0.Final. If you’re not familiar with patching WildFly, check Markus’s tutorial.
+
+
+
+
+
+
+
Weld 2.4.0.Final
@@ -1027,67 +1106,6 @@ WildFly Patch
-
-
-
- 2015-10-27
-
-
-
- release
-
-
-
- Martin Kouba
-
-
-
-
-
Weld 2.3.1.Final has been released! The delivery: a few killed bugs, couple of Weld SE enhancements and several Weld Probe improvements.
-
-
-
Notable bug-fixes and enhancements:
-
-
-
- -
-
Private producer, disposer and observer methods should be intercepted (WELD-2043)
-
- -
-
Specializing bean - remove @Default qualifier unless explicitly declared (WELD-2046)
-
- -
-
Weld SE
-
-
- -
-
Fix the development mode enablement
-
- -
-
Allow to pass a ResourceLoader to be used for scanning (WELD-2044)
-
- -
-
Allow to skip the registration of a shutdown hook (WELD-2051)
-
-
-
- -
-
Weld Probe now supports monitoring of container lifecycle events during bootstrap (see also supported configuration properties)
-
-
-
-
-
-
-
diff --git a/news/tags/release/page/7.html b/news/tags/release/page/7.html
index cef02cc8..d094e401 100644
--- a/news/tags/release/page/7.html
+++ b/news/tags/release/page/7.html
@@ -141,6 +141,67 @@
+
+
+
+ 2015-10-27
+
+
+
+ release
+
+
+
+ Martin Kouba
+
+
+
+
+
Weld 2.3.1.Final has been released! The delivery: a few killed bugs, couple of Weld SE enhancements and several Weld Probe improvements.
+
+
+
Notable bug-fixes and enhancements:
+
+
+
+ -
+
Private producer, disposer and observer methods should be intercepted (WELD-2043)
+
+ -
+
Specializing bean - remove @Default qualifier unless explicitly declared (WELD-2046)
+
+ -
+
Weld SE
+
+
+ -
+
Fix the development mode enablement
+
+ -
+
Allow to pass a ResourceLoader to be used for scanning (WELD-2044)
+
+ -
+
Allow to skip the registration of a shutdown hook (WELD-2051)
+
+
+
+ -
+
Weld Probe now supports monitoring of container lifecycle events during bootstrap (see also supported configuration properties)
+
+
+
+
+
+
+
Weld 2.3.0.Final released!
diff --git a/sitemap.xml b/sitemap.xml
index 9706360a..6386dbc0 100644
--- a/sitemap.xml
+++ b/sitemap.xml
@@ -2,37 +2,37 @@
https://weld.cdi-spec.org/bug/
- 2024-11-28
+ 2024-12-16
0.5
weekly
https://weld.cdi-spec.org/community/
- 2024-11-28
+ 2024-12-16
0.5
weekly
https://weld.cdi-spec.org/dist/
- 2024-11-28
+ 2024-12-16
1
daily
https://weld.cdi-spec.org/documentation/
- 2024-11-28
+ 2024-12-16
0.5
weekly
https://weld.cdi-spec.org/download/
- 2024-11-28
+ 2024-12-16
0.5
weekly
https://weld.cdi-spec.org/
- 2024-11-28
+ 2024-12-16
0.5
weekly
@@ -600,9 +600,15 @@
1
weekly
+
+ https://weld.cdi-spec.org/news/2024/12/16/weld-514Final/
+ 2024-12-16
+ 1
+ weekly
+
https://weld.cdi-spec.org/news/
- 2024-11-28
+ 2024-12-16
1
daily
+ 
+ 
+