Help

I've just published Weld 1.1.0, the reference implementation of JSR-299: Contexts and Dependency Injection for Java EE. It's based on the CDI 1.0 API. You can find direct download links at the bottom of this post or you can pull the artifacts from the JBoss Maven Repository.

This release contains all the new developments from the last six months, the highlights of which are:

  • Big improvements in memory usage, boot time and runtime performance. Our measurements showed a two fold improvement in boot time with just a few beans in the deployment, but with many beans, we were showing more than a 10 fold improvement. Memory usage showed a consistent 4 fold improvement, regardless of the number of beans deployed. We showed a 40% improvement in runtime performance, and also measured that Weld performs as well as, or better than other CDI implementations available, as well as other projects in the DI space.
  • Ability to exclude classes from scanning and deployment as beans by Weld. You can configure this in beans.xml for the bean archive you are deploying:
<beans xmlns="http://java.sun.com/xml/ns/javaee" 
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
        xmlns:weld="http://jboss.org/schema/weld/beans" 
        xsi:schemaLocation="
           http://java.sun.com/xml/ns/javaee http://jboss.org/schema/cdi/beans_1_0.xsd
           http://jboss.org/schema/weld/beans http://jboss.org/schema/weld/beans_1_1.xsd">
    
    <weld:scan>
        <!-- Don't include GWT support if GWT is not installed -->
        <weld:exclude name="com.acme.gwt.**">
            <weld:if-class-available name="!com.google.GWT"/>
        </weld:exclude>
    </weld:scan>

</beans>
  • The new Pastecode example, which shows off many of the new EJB 3.1 features in use with Weld
  • around 140 bug fixes
  • A new approach to managing contexts, making it easier to write view-layer integrations

We also just released 1.0.4 of the CDI TCK - you can find the links for it below :-)

Thanks go to Marius Bogoevici, Stuart Douglas, Martin Gencur, Nicklas Karlsson, Stale Pedersen, Ales Justin, David Allen, Sivakumar Thyagarajan and Jason Porter for their hard work on this release!

This also marks the last Weld release that I will be running the project for. I just want to take this opportunity to thank the Weld community for all their help over the last 2 years. Weld has an amazing community, full of very talented people, who want to get things right regardless personality and politics.

JBoss AS

Weld 1.1.0.CR2 is included in JBoss AS 6.0.0.Final, and Weld 1.1.0.Final will be included in JBoss AS 6.0.1 (it's being integrated as we speak). Weld 1.1.0.Final is also included in GlassFish V3.1

About Weld

Weld is used in GlassFish V3 and the JBoss AS 6 series. Weld also has support for Servlet containers such as Tomcat and Jetty. Alternatively, you can use Weld with Java SE.

There is great testing support via Arquillian, which allows you to test in Weld SE, a mocked out Java EE container, Tomcat or Jetty, as well as JBoss AS and GlassFish.

If you are just getting started, there are a few examples in the distribution to guide you (look for instructions in the reference guide, and each example has a readme.txt). If you are looking for help, try our user forums, or perhaps join us on IRC.

[ Distribution (Weld, CDI TCK) ] | [ Release Notes (Weld, CDI TCK) ] | [ Reference Guide (Weld, CDI TCK ] | [ Issue Tracker (Weld, CDI TCK) ] | [ CDI Javadoc ]

14 comments:
 
17. Jan 2011, 19:55 CET | Link

I work on GAE project, so I had to refuse weld because of long scanning time at cold start. Would you be able to describe how to point weld to one package only where beans are contained. Could it be faster than managed beans? How to configure mojarra not to scan beans? What is a best configuration to reduce application start time with weld and mojarra together?

Anyway, I think weld is great, thank you very much for your work.

ReplyQuote
 
17. Jan 2011, 20:48 CET | Link
Ara wrote on Jan 17, 2011 13:55:
I work on GAE project, so I had to refuse weld because of long scanning time at cold start. Would you be able to describe how to point weld to one package only where beans are contained.

That's the simplest example :-)

<beans xmlns="http://java.sun.com/xml/ns/javaee" 
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
        xmlns:weld="http://jboss.org/schema/weld/beans" 
        xsi:schemaLocation="
           http://java.sun.com/xml/ns/javaee http://jboss.org/schema/cdi/beans_1_0.xsd
           http://jboss.org/schema/weld/beans http://jboss.org/schema/weld/beans_1_1.xsd">
    
    <weld:scan>
        <weld:include name="the.one.package.to.scan.*" />
    </weld:scan>

</beans>
Could it be faster than managed beans?

I haven't measured this, but I suspect it should be around the same.

How to configure mojarra not to scan beans? What is a best configuration to reduce application start time with weld and mojarra together?

Maybe a Mojarra expert can help, but I agree with you, disable Mojarra scanning, and use the above snippet.

 
17. Jan 2011, 22:24 CET | Link

I would also like to suggest that you look at the possibility of using Always On instances in GAE. It costs a little money, but you are reserved 3 JVM instances for your application which are always running (i.e, no more waiting for container startup).

 
17. Jan 2011, 23:01 CET | Link

I know, but sometimes I use task queue API very extensive. In this case gae run more instances anyway, so it is better to have shorter start time to run tasks in more predictable order.

 
18. Jan 2011, 08:17 CET | Link

Awesome news, congratulations!

 
20. Jan 2011, 08:18 CET | Link
Maybe a Mojarra expert can help, but I agree with you, disable Mojarra scanning, and use the above snippet.

I investigated GAE start time problem little bit. Anybody can use this to save some start time that can be used for weld start.

1. Register all managed beans statically in faces-config.xml
2. Use metadata-complete=”true” attribute, so faces-config.xml boilerplate is:

<?xml version='1.0' encoding='UTF-8'?>
<faces-config xmlns="http://java.sun.com/xml/ns/javaee"
              xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
              xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
              http://java.sun.com/xml/ns/javaee/web-facesconfig_2_0.xsd"
              version="2.0"
              metadata-complete="true">
    
<!--Your stuff here-->
</faces-config>

Using this technique you force JSF not to scan classes for beans.
3. Force JSF not to check xml syntax. I hope your IDE do it instead. In web.xml check context parameter as here:

<context-param>
     <description>
         Set this flag to true if you want the JavaServer Faces
         Reference Implementation to validate the XML in your
         faces-config.xml resources against the DTD. Default
         value is false.
     </description>
     <param-name>com.sun.faces.validateXml</param-name>
     <param-value>false</param-value>
</context-param> 

Using these tricks I reduce GAE start time by two seconds. Not bad.

 
23. Jan 2011, 19:19 CET | Link

Is @ViewScoped included or I should use this instruction to port it by myself?

 
24. Jan 2011, 12:12 CET | Link

I continue investigation of GAE start time . Instead of usage of metadata-complete="true" you would be consider com.sun.faces.annotationScanPackages context param, that should be included to web.xml. Description could be found here . Start time is rather same.

 
24. Jan 2011, 12:29 CET | Link
Ara wrote on Jan 23, 2011 13:19:
Is @ViewScoped included or I should use this instruction to port it by myself?

You should port it yourself, or consider using Seam Faces.

 
24. Jan 2011, 14:21 CET | Link

Now, it is time to test weld 1.1.0 final on GAE.

1. Aded to pom.xml:

<repository>
    <id>jboss-my-rel</id>
    <url>https://repository.jboss.org/nexus/content/repositories/releases/</url>
</repository>
...
<dependency>
    <groupId>org.jboss.weld.servlet</groupId>
    <artifactId>weld-servlet</artifactId>
    <version>1.1.0.Final</version>
</dependency>

2. Created empty bean.xml
3. Aded to web.xml

<listener>
    <listener-class>org.jboss.weld.environment.servlet.Listener</listener-class>
</listener>

Result is error:

SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in [jar:file:/G:/ideaworkspace/richgost/target/agost/WEB-INF/lib/slf4j-jdk14-1.6.1.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in [jar:file:/G:/ideaworkspace/richgost/target/agost/WEB-INF/lib/weld-servlet-1.1.0.Final.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.
24.01.2011 13:16:47 com.google.apphosting.utils.jetty.JettyLogger warn
WARNING: failed com.google.apphosting.utils.jetty.DevAppEngineWebAppContext@1e232b5{/,G:\ideaworkspace\richgost\target\agost}: java.lang.NoSuchMethodError: org.slf4j.spi.LocationAwareLogger.log(Lorg/slf4j/Marker;Ljava/lang/String;ILjava/lang/String;Ljava/lang/Throwable;)V
24.01.2011 13:16:47 com.google.apphosting.utils.jetty.JettyLogger warn
WARNING: failed JettyContainerService$ApiProxyHandler@16f144c: java.lang.NoSuchMethodError: org.slf4j.spi.LocationAwareLogger.log(Lorg/slf4j/Marker;Ljava/lang/String;ILjava/lang/String;Ljava/lang/Throwable;)V
24.01.2011 13:16:47 com.google.apphosting.utils.jetty.JettyLogger warn
WARNING: Error starting handlers
java.lang.NoSuchMethodError: org.slf4j.spi.LocationAwareLogger.log(Lorg/slf4j/Marker;Ljava/lang/String;ILjava/lang/String;Ljava/lang/Throwable;)V
        at org.slf4j.cal10n.LocLogger.info(LocLogger.java:122)
        at org.jboss.weld.bootstrap.WeldBootstrap.<clinit>(WeldBootstrap.java:207)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
        at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
        at java.lang.reflect.Constructor.newInstance(Unknown Source)
        at com.google.appengine.tools.development.agent.runtime.Runtime.newInstance_(Runtime.java:112)
        at com.google.appengine.tools.development.agent.runtime.Runtime.newInstance(Runtime.java:132)
        at org.jboss.weld.environment.servlet.util.Reflections.newInstance(Reflections.java:41)
        at org.jboss.weld.environment.servlet.Listener.<init>(Listener.java:68)

First question is what to do with slf4j-jdk14. It works perfect on gae with all log levels? Are that all errors?

 
24. Jan 2011, 14:34 CET | Link

I just removed slf4j-jdk from pom.xml. I’ve got new error.

24.01.2011 13:30:57 org.jboss.weld.environment.servlet.Listener contextInitialized
WARNING: @Resource injection not available in simple beans
24.01.2011 13:30:57 org.jboss.weld.bootstrap.WeldBootstrap startContainer
INFO: WELD-000101 Transactional services not available. Injection of @Inject UserTransaction not available. Transactional observers will be invoked synchronously.
24.01.2011 13:30:58 com.google.apphosting.utils.jetty.JettyLogger warn
WARNING: failed com.google.apphosting.utils.jetty.DevAppEngineWebAppContext@3ac93e{/,G:\ideaworkspace\richgost\target\agost}: java.lang.NoClassDefFoundError: org/apache/catalina/core/ApplicationContextFacade
24.01.2011 13:30:58 com.google.apphosting.utils.jetty.JettyLogger warn
WARNING: failed JettyContainerService$ApiProxyHandler@ecb67f: java.lang.NoClassDefFoundError: org/apache/catalina/core/ApplicationContextFacade
24.01.2011 13:30:58 com.google.apphosting.utils.jetty.JettyLogger warn
WARNING: Error starting handlers
java.lang.NoClassDefFoundError: org/apache/catalina/core/ApplicationContextFacade
        at org.jboss.weld.environment.tomcat.WeldForwardingAnnotationProcessor.getStandardContext(WeldForwardingAnnotationProcessor.java:92)
        at org.jboss.weld.environment.tomcat.WeldForwardingAnnotationProcessor.replaceAnnotationProcessor(WeldForwardingAnnotationProcessor.java:69)
        at org.jboss.weld.environment.servlet.Listener.contextInitialized(Listener.java:192)
        at org.mortbay.jetty.handler.ContextHandler.startContext(ContextHandler.java:548)
        at org.mortbay.jetty.servlet.Context.startContext(Context.java:136)
        at org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1250)
        at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:517)
        at org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:467)
        at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
        at org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:130)
        at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
        at org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:130)
        at org.mortbay.jetty.Server.doStart(Server.java:224)
        at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
        at com.google.appengine.tools.development.JettyContainerService.startContainer(JettyContainerService.java:185)
        at com.google.appengine.tools.development.AbstractContainerService.startup(AbstractContainerService.java:149)
        at com.google.appengine.tools.development.DevAppServerImpl.start(DevAppServerImpl.java:219)
        at com.google.appengine.tools.development.DevAppServerMain$StartAction.apply(DevAppServerMain.java:164)
        at com.google.appengine.tools.util.Parser$ParseResult.applyArgs(Parser.java:48)
        at com.google.appengine.tools.development.DevAppServerMain.<init>(DevAppServerMain.java:113)
        at com.google.appengine.tools.development.DevAppServerMain.main(DevAppServerMain.java:89)
Caused by: java.lang.ClassNotFoundException: org.apache.catalina.core.ApplicationContextFacade
        at java.net.URLClassLoader$1.run(Unknown Source)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(Unknown Source)
        at java.lang.ClassLoader.loadClass(Unknown Source)
        at com.google.appengine.tools.development.IsolatedAppClassLoader.loadClass(IsolatedAppClassLoader.java:151)
        at java.lang.ClassLoader.loadClass(Unknown Source)
        ... 21 more
 
24. Jan 2011, 19:06 CET | Link

The strange thing that with weld 1.0.1-Final weld works perfect! So, would you be able to provide some extra configuration? Or this is downgrade for GAE?

 
25. Jan 2011, 21:09 CET | Link

So, continue with weld 1.1.0 final on GAE. Logging problem could be solved by removing any slf4j dependencies. Weld brings slf4j api and correct apply it to GAE logger. You will have all logging levels. After, you should add

<dependency>
    <groupId>org.jboss.weld</groupId>
    <artifactId>weld-logger</artifactId>
    <version>1.0.0-CR2</version>
</dependency>

To you pom.xml. Now, you can just inject logger. Consider this to do it correctly. But the problem with second error still exists. I am very upset that is not able to try new abilities of weld on GAE.

13. Sep 2011, 16:57 CET | Link
Jonathan Benoit
Can you please make Weld 1.1.0.Final artifacts available in maven central repository? For example, I'd like to see http://search.maven.org/#search|gav|1|g%3A%22org.jboss.weld%22%20AND%20a%3A%22weld-osgi-bundle%22 include 1.1.0.Final, 1.1.1.Final, and 1.1.2.Final. This way i don't have to include <repository> element in my pom pointing to http://repository.jboss.org/nexus/content/groups/public/ for dependencies like:
        <dependency>
            <groupId>org.jboss.weld</groupId>
            <artifactId>weld-osgi-bundle</artifactId>
            <version>1.1.0.Final</version>
            <scope>provided</scope>
        </dependency>
Post Comment