Help

We've been starting to think about what we want to include in Weld 1.1. Of course, you can expect the usual bug fixes, as well as a few new features -- I'll outline those for you here.

Container integration improvements

A number of refinements are planned to the existing requirements -- the biggest change will be exposing our reflection abstraction API to the container. The Weld Reflection API extends the Annotated interface hierarchy from the CDI SPI, adding in additional methods to support discovery of meta-annotated classes, methods, fields, constructors and parameters, as well as some methods to complete the reflection API. You can find the API in SVN (you can glean the intention from the API, but be aware we do intend to clean it up before exposing it to the world!).

This will allow the container to replace our built in implementation (based on JDK Reflection) allowing extensive optimisations. For example, the container must scan classes for annotations for multiple components (such as JPA, EJB 3, JAX-RS, CDI, JSF, Servlet 3) - each implementation performing its own scan is clearly both a waste of time and memory (if the implementation caches this information). Further, a container might choose to use Javassist rather than JDK Reflection to provide faster scanning.

CDI API

A CDI maintenance release is planned, and if finalised in time, we plan to include this update in Weld 1.1.

You can expect this release around September. If the CDI MR is not final, we will provide the latest revision of the changes in our non-portable API, allowing you to experiment with them in advance!

Anything else you think should be included? If so, get in touch!

10 comments:
 
09. May 2010, 21:08 CET | Link
Well my experience with weld 1.01 has been both good and bad. Good because I like the standard javax.Inject annotation features and no need for lots of XML like spring, bad because of integration problems with OSGI and with Jersey, performance issues (makes my boot time >x100 slower), limited support for hybrid JAVA SE/JAVA EE libs/apps and finally it is difficult to debug errors when something does not work.

In particular, I would like to see in Weld 1.0:
1) Real OSGI support for SE and EE. Apart from weld being proper bundles, weld classloader's should work in an osgi environment with an osgi classloader as f.x. google guice 2.0 does. This means f.x no Class.forName as f.x. org.jboss.weld.environment.se.util.Reflections does (see WELD-520)

2) Better support for dual SE and EE applications. I have some weld-using jar's that can be deployed on a Java EE and work standalone. It is possible to get this to work using both weld SE and weld EE but it is a pain. F.x. when deployed under glassfish weld will fail unless I include a few weld SE dummy classes.... Weld should either combine weld SE and weld EE OR there should at least be some support for having weld ignoring some of my classes/packages/services depending on which environment it is running under (see WELD-521)

3) Performance optimizations. Booting my Java SE app without weld takes << 1s but just initializing weld to autowire my about 20-30 singletons takes 4-5 seconds. I have lots of stuff on my classpath so I suspect that could be why weld is going crazy. I guess this could be improved if I can have weld limited to work only inside my own jar and/or only work with specific classes/packages (see WELD-522)

4) Better error reporting in general. F.x. the "not proxyable" error is quite annoying because it does not give the necessary details.

ReplyQuote
 
09. May 2010, 21:50 CET | Link

4) is fixed in trunk.

 
10. May 2010, 04:25 CET | Link
Glad to hear nr. 4 is fixed.

As for issue number one, it seems there are multiple bugs in Weld in addition to the one I mentioned that disallow OSGI (see f.x WELD-523 and WELD-524). Looking at the code of WeldSE it is quite clear that the WeldSE development has been sidelined from the rest of Weld and less tested (f.x org.jboss.weld.resources.spi.ResourceLoader being ignored).

 
10. May 2010, 05:10 CET | Link

Well, Weld SE has pretty much been a one-man-army extension (although a very powerful one-man-army) and as such is limited (by the time/resource available by the contributor) to how quickly practices and stuff migrate over from Weld Core but thanks for creating the JIRAs, that's always the correct place to start when you want something fixed.

 
10. May 2010, 17:52 CET | Link
heiko Braun | heiko(AT)openj.net

Are you referring to http://community.jboss.org/wiki/MCScanninglib ?

 
11. May 2010, 00:09 CET | Link
Morten Christensen wrote on May 09, 2010 15:08:
Well my experience with weld 1.01 has been both good and bad. Good because I like the standard javax.Inject annotation features and no need for lots of XML like spring, bad because of integration problems with OSGI and with Jersey, performance issues (makes my boot time x100 slower), limited support for hybrid JAVA SE/JAVA EE libs/apps and finally it is difficult to debug errors when something does not work.

Thanks for filing out the JIRA issues - just wanted to point out that we have concentrated mainly of Java EE support so far - the SE support (as Nik says) is definitely still in the experimental stage, hence why you may be seeing performance issues with Weld SE etc :-)

I also wanted to say that we definitely need people like you to report how you are struggling with debugging, as only with that feedback can we make it better. For me, it's only when I use the framework do I see where the problems with debugging are! So please continue to report them :-)

 
11. May 2010, 00:11 CET | Link
heiko Braun wrote on May 10, 2010 11:52:
Are you referring to http://community.jboss.org/wiki/MCScanninglib ?

This could be what backs an implementation of Reflection SPI for example.

 
14. May 2010, 01:09 CET | Link
Morten Christensen wrote on May 09, 2010 15:08:
3) Performance optimizations. Booting my Java SE app without weld takes << 1s but just initializing weld to autowire my about 20-30 singletons takes 4-5 seconds. I have lots of stuff on my classpath so I suspect that could be why weld is going crazy. I guess this could be improved if I can have weld limited to work only inside my own jar and/or only work with specific classes/packages (see WELD-522)

Full ack. I already proposed 2 changes to the spec

1.) Don't treat not annotated beans as @Dependent. This really su..x. It makes scanning a lot slower and you usually pickup classes as @Dependent which you didn't intend to. Thus you pretty frequently get an AmbiguousResolutionException and you have to annotated your class with @Typed() or an unused Qualifier anyway. So the original explanation for it simply didn't work out.

2.) add an optional <include> and <exclude> section to beans.xml. This may also vastly improve classpath scanning time.

Please also remember that reducing the effective classes which get's picked up as Bean<T> will also reduce the memory footprint and speed up not only the scanning but also the lookup!

 
25. May 2010, 06:54 CET | Link
Cloves Almeida

Being more flexible about proxyable beans. A lot of third party libs has final methods and because of that you can't extend the object, having to use composition instead. While this is generally a good idea, many frameworks encourage extensions.

 
22. Jun 2010, 07:33 CET | Link
joid

Portlet support would be nice!

Post Comment