EL4J, a set of incremental improvements to Spring, has been open sourced. EL4J provides module support (splitting applications into separate modules), remoting facilities (support for generating EJB session bean facades for POJOs and clean implicit context passing), a daemon manager service, a safety facade, and more.
- Posted by: P O
- Posted on: November 16 2005 09:09 EST
Module support simplifies the usage of the many emerging Spring extensions: the packaging is unified and the default usage of new features is easier. For example, to use the JMX module (publishing all available Spring Beans and their config in an Application Context under JMX), one simply adds a <dependency module="module-jmx"/> to the module description of the application: all default configuration and classpath settings can then be used automatically.
* Short introductory article: http://el4j.sourceforge.net/docs/pdf/EL4J_IntroductionArticle1.pdf
* More documentation: http://el4j.sourceforge.net/documentation.html
What do you think?
- Honestly, I'm not impressed... by Tim O'Brien on November 16 2005 18:41 EST
- it's GPL... by Joe Fawzy on November 16 2005 21:05 EST
- SpringFourge by Vagif Verdi on November 17 2005 00:06 EST
It's dependence on Ant (EL4Ant) has already made it irrelevant to my own projects, and the idea of splitting up a Spring application is already very much a possibility without introducing yet another framework into the mix.
Why is the dependence on EL4Ant a problem for you?
We built EL4Ant as a very light ant-file generator, because we did not find an alternative at the time we created it (we require transitive dependencies). Maven 2.0 now supports transitive dependencies and we are looking into support for it. (Although in the first tries, maven seems a bit heavy.)
I agree that you can split an application through other means. But providing default packaging and config helps to get quickly started with new functionality. I did not yet find comparable support.
while it may contain some usefull extensions, it is completely useless without a commercial license (yes it is commercial) as it is released under GPL
I know this can be limiting for some contexts. As mentioned on our site, we would be happy to contribute parts of it to the existing spring (with the appropriate apache license).
I know this can be limiting for some contexts. As mentioned on our site, we would be happy to contribute parts of it to the existing spring (with the appropriate apache license).Philipp
Hi the EJB remoting stuff seems like a prime candidate for
inclusion into Spring.
Yes, I agree. On the down side POJO remoting via EJBs will soon be made simpler with EJB 3.0. (But on the other hand: EJB 2.1 will probably still be around for some time...)
I think it is time to open SpringFourge :))