Entries tagged [java]

Monday November 12, 2018

Apache OpenWebBeans-2.0.8 has been released

The Apache OpenWebBeans Team is proud to announce the release of Apache OpenWebBeans-2.0.8.

Apache OpenWebBeans-2.0.x is an Apache License v2 licensed implementation of the JSR-365 CDI-2.0 specification.

OpenWebBeans has a modular structure and provides Dependency Injection scaling from Java SE environments up to Java EE8 server clusters with complicated ClassLoader hierarchies or OSGi environments.

This is a maintenance release targetting the Contexts and Dependency Injection CDI 2.0 specification!

CDI is a JavaEE standard (JSR-365) but fully available under Apache License v2.0.



Apache OpenWebBeans-2.0.8 implements the CDI-2.0 API, and passes the JSR-330 and JSR-365 TCKs.

Distribution packages can be downloaded from http://www.apache.org/dyn/closer.lua/openwebbeans/2.0.8/

Hashes can be found here http://www.apache.org/dist/openwebbeans/2.0.8/

The release is also available in maven.central https://repo1.maven.apache.org/maven2/org/apache/openwebbeans/

More info can be found at


The following tickets got fixed in this release:


  • [OWB-1257] - Conditional exclusion of beans in beans.xml does not honor system property
  • [OWB-1263] - Generic observers not called correctly
  • [OWB-1264] - Observers method throws NoClassDefFoundError for optional classes
  • [OWB-1269] - TomcatSecurityService principal is not the contextual one out of request scope beans


  • [OWB-1261] - Upgrade ASM to version 7
  • [OWB-1265] - [perf] cache AnnotationManager#getRepeatableMethod
  • [OWB-1266] - [perf] InjectionResolver cache can be activated earlier


  • [OWB-1268] - Upgrade to xbean 4.12

Monday October 01, 2018

Apache Meecrowave-1.2.4 has been released

The Apache OpenWebBeans team is proud to announce the release of Apache Meecrowave 1.2.4

Apache Meecrowave is a small java enterprise application server framework fully based on Apache Tomcat9 and other JavaEE 8 technologies.

    Apache Tomcat-9.0.12 (Servlets-4.0)
    Apache OpenWebBeans-2.0.7 (CDI-2.0)
    Apache Johnzon-1.1.10 (JSON-P-1.1 and JSON-B-1.0), and
    Apache CXF-3.2.6 (JAX-RS-2.1).

And all that in less than 10MB. That means it is ideally suited for Microservices and standalone applications.

Meecrowave can be either started via a maven plugin (for ease of development), programmatically as embedded server, bundled as application with your business code or as runner to start up portable WAR or JAR applications.

The source distribution package can be downloaded from our mirrors:

Hashes can be found here

The binary artifacts are available on maven.central:

Our main change for this bugfix release is adding preliminary Java11 support.
The full list of resolved tickets is:

    • [MEECROWAVE-130] - IOException if MEECROWAVE_OUT is different than MEECROWAVE_HOME
    • [MEECROWAVE-142] - error while starting jpda debug in a bundle
    • [MEECROWAVE-143] - [junit5] RequestScoped not activated with @MeecrowaveConfig
    • [MEECROWAVE-144] - update geronimo specs to new versions

    • [MEECROWAVE-136] - update to apache-parent-21 for sha512
    • [MEECROWAVE-140] - Embrace JUnit 5 PER_CLASS support
    • [MEECROWAVE-141] - Add @AfterFirstInjection and @AfterLastTest for JUnit 5 integration

    • [MEECROWAVE-133] - Upgrade to CXF 3.2.6
    • [MEECROWAVE-134] - Tomcat 9.0.12 upgrade
    • [MEECROWAVE-135] - Log4j2 2.11.1 upgrade
    • [MEECROWAVE-138] - update to Johnzon-1.1.9
    • [MEECROWAVE-139] - update OWB to 2.0.7
    • [MEECROWAVE-145] - update to Johnzon-1.1.10
    • [MEECROWAVE-146] - Upgrade commons-compress to 1.18
    • [MEECROWAVE-147] - Upgrade commons-dbcp2 to 2.5.0
    • [MEECROWAVE-148] - Upgrade commons-jcs to 2.2.1
    • [MEECROWAVE-149] - Upgrade acme4j to 2.3
    • [MEECROWAVE-150] - Remove commons-lang and commons-text from core dependencies

More info can be found at

Tuesday August 14, 2018

Apache Meecrowave-1.2.3 has been released

The Apache OpenWebBeans team is proud to announce the release of Apache Meecrowave 1.2.3

Apache Meecrowave is a small server (only 9MB) fully based on Apache Tomcat9 and other JavaEE 8 technologies.[Read More]

Friday February 15, 2013

News from OpenWebBeans-1.2.0

The Apache OpenWebBeans team has been quite busy with big refactorings. Big improvements have been made to the proxying mechanism, the Bean scanning and the AnnotatedType handling. We managed to improve the overall performance again and now deliver almost native Java like performance for our NormalScoping proxies.

Parts which are already implemented

Let's take a close look at a few details of the parts we already finished and explain them briefly.

Split between NormalScoping Proxies and Interceptor Proxies

In OpenWebBeans 1.0.x and 1.1.x a single Bean only had one single Proxy handling for all tasks - The NormalScopedBeanInterceptorHandler. This did handle all the stuff like Interceptors, Decorators provide subclassing for abstract Decorators but also did the NormalScope handling.

As result of this unified handling we only stored the native Contextual Instances in the Contexts (Session, Request map, Conversation map, etc). The negative side effect of this approach was that we had to introduce a quite hacky mechanism to regain access to the CreationalContext. Needless to say that this was not only complex but also error prone.

In OpenWebBeans-1.2.0 we now maintain 2 proxies. The first one solely handles NormalScoping, then 2nd one does all the Interceptor and Decorator stuff. The most important change is that we apply the DecoratorProxy directly 1:1 on the Contextual Instance and thus don't need to do any of those weird CreationalContext hacks anymore. Instead the already intercepted/decorated instance gets stored in the Context.

All NormalScope proxies now implement the Interface OwbNormalScopeProxy and have a name *$OwbNormalScopeProxy*.

All Interceptor and/or Decorator proxies implement the Interface OwbInterceptorProxy and have a name *$OwbInterceptProxy*.

Additionally to those 2 proxies we also introduced a new separate proxy kind for creating subclasses for abstract Decorators which now implement the marker interface OwbDecoratorProxy.

Creating our own proxy bytecode

For performance reasons we moved from using Javassist (where we fixed quite a few mem leaks in the past) to generating our own native Java ByteCode with ASM. We now only use reflection if really necessary. For standard NormalScoping of public methods we e.g. generate the following code. Consider a simple User class:

public class User {
   public String getGivenName() { return "Hans"; }

For this class the generated bytecode of an OwbNormalScopeProxy will look like the following:

public class User$OwbNormalScopeProxy0 extends User {
  private Provider owbContextualInstanceProvider;
  public String getGivenName() {
    return owbContextualInstanceProvider.get().getGivenName();

There is no bells and whistle and especially no reflection - just pure plain Java bytecode which is blazingly fast!

Btw, we do very similar stuff for non-intercepted methods of intercepted/decorated classes. And we also improved the handling of intercepted methods and are now more than twice as fast as OWB-1.1.7 (which was already very fast). 

Cleaning up the Bean creation

In the past we had 2 ways to create beans. If an Extension used ProcessAnnotatedType to tweak the AnnotatedType of a class then we built the Bean<T> from the modified AnnotatedType<T>. For cases where the AnnotatedType did not get modified we took a completely different part and created the Bean from the Class reflection information. This part came from a time where there was no AnnotatedType in the spec yet.

In OWB-1.2.0 we now do all the Bean<T> construction based on the AnnotatedType - regardless if it got provided by a CDI-Extension or remained unchanged. This made our codebase much easier to maintain! Arne also did a great job by introducing and cleaning up all the BeanBuilders and making the final Bean<T> immutable.

Parts waiting to be done

More new things to come before the release:

  • Replace Scannotation by xbean-finder.
  • Create the initial AnnotatedTypes from the information already collected by xbean-finder instead of doing expensive Class reflection.

CDI-1.0 or CDI-1.1?

We initially targeted CDI-1.1 with this release. But during the development we figured that we do not yet need to. All the parts introduced so far are perfectly working with CDI-1.0 as well. Thus it looks like we gonna release OWB-1.2.0 as still being CDI-1.0. But we are well prepared to support the new features of CDI-1.1 very quickly as we already did all the preparations. Sometimes we internally already use CDI-1.1 mechanisms (like the BeanAttributs) and only have to add 'implements RandomCdi11FeatureInterface'. This will likely be shipped as OWB-2.0.0 though when the spec hits an almost final status and the TCK is available.

How to Test

That's a pretty easy thing. If you have the apache.snapshots maven repo in your build, then you can just reference owb 1.2.0-SNAPSHOT in your build and you're done!



Hot Blogs (today's hits)

Tag Cloud