[Laszlo-dev] The case for Spring
Oliver Steele
steele at laszlosystems.com
Thu Nov 17 08:58:58 PST 2005
Thanks, Mika and Ronen, for an excellent discussion.
I agree with Mika's recommendation of Spring.
Speaking strictly from an API perspective, some of the other
frameworks are appealing. I personally prefer configuration by
convention to Spring's use of separate XML configuration files.
Xdoclet-tags does ameliorate this, although I'm somewhat worried
about the added build environment complexity.
However, from a project perspective, the other platforms look less
appealing (today). In addition to its reliance on JNDI and JBoss
JTA, the JBoss EJB 3.0 container is released under the LGPL; this
rules it out immediately[*]. In the future there may be an
implementation that has fewer restrictions and dependencies, but it's
too early to adopt that library for this project. Seasar looks
great, but there just isn't enough support for it in the English-
speaking community. Lastly, for a personal or internal project I
might choose NanoContainer, but Spring looks more mature and there's
are more books, tutorials, and tools for, and it provides a wider
range of solutions to OpenLaszlo server integrators.
Spring will make it easier to gain acceptance for the project. Let's
go with that.
If, in a couple of years, EJB3 has become a better solution, we can
switch to that container then. If EJB3 catches on, ours will not be
the only project doing so! And in the meantime, it will be valuable
to clean up the codebase using the tools that are appropriate today
--- I'm sure that it would be easier in the future to move from one
DI container to another, than from the current state of things.
Best,
Oliver
[*] LGPL: Yes, the LGPL license is supposed to allow libraries to be
distributed with products that are released under a different open
source license (or a commercial license --- although I believe
Stallman thinks this is a mis-use of the LGPL). However, there are
companies that will deploy other OS-licensed software, such as
OpenLaszlo, but draw the line at LGPL components. Since it is in
part these company's business that supports the OpenLaszlo project,
we don't want to create a license situation that makes the project
unusable to them.
On Nov 15, 2005, at 11:53 AM, Mika Göckel wrote:
> Hi!
>
> Okay... ready to rumble.
>
> What I see from various steamed up discussions now (is this an
> english saw?) is that EJB3 and Spring are competing only in a small
> bandwidth. The DI parts of EJB3 are J2EE focussed and only deal
> with JNDI lookups. EJB3 is for course grained issues whereas Spring
> is better suited for the bread-and-butter business of weaving fine
> grained dependecies. Possibly there could be add-on classes that
> expose OpenLaszlo Services (transcoding, lzx-to-swf..) as services
> via SessionBean, but this doesn't sound to me like a groundbreaking
> feature. Additionally the EJB3 spec isn't released at all, so it's
> too early to go in that direction anyway.
>
> Jdk5-Annotations vs. Xdoclet-Tags (to avoid having to hand-write
> the XML config) is a moving target. Today the choice would still be
> XDoclet, I don't see, that there are jdk5-annotation tools that are
> able to create whateveryouwant artifacts (code, xml config, etc)
> yet. At the end, the syntax looks similar. XDoclet1 vs.
> XDoclet2 ... X2 hasn't got Spring support,
>
> Besides Spring, JBossMC and Seasar there is NanoContainer
> (www.nanocontainer.org), Excalibur (http://excalibur.apache.org/)
> and HiveMind (hivemind.apache.org).
>
> I don't know what your second-hand car dealer would advise, but I
> definitely recommend Spring.
>
> In parallel to this discussion, we need to examine the OpenLaszlo
> source and find pivot objects that are suitable for refactoring.
> What are the services, what are adaptors, where are plug-ins, which
> aspects can be handled by AOP ... to decide the prime targets for
> refactoring.
>
> Regards, Mika
>
>> Hi!
>>
>> I need to do some investigation to get to a clearer view on that..
>> in the meantime have a look on
>> http://www.onjava.com/pub/a/onjava/2005/06/29/spring-ejb3.html?page=1
>> (the comments are interesting)
>> The discussion has got a religious touch :-)
>>
>> Cheers.
>> Mika
>>
>> Ronen Mizrahi schrieb:
>>
>>> Mika, you are right that currently the EJB 3.0 container from
>>> JBoss relies on JNDI and even on the JBoss specific
>>> implementation, however this is about to change since this
>>> container is being integrated with the microcontainer project so
>>> we are dealing with a temporary issue here. In any case, my point
>>> was not JBoss but EJB 3.0 as a more standardized way to achieve
>>> the goals of spring. I was unaware of the fact that JNDI reliance
>>> is mandatory in EJB 3.0, but I may be wrong here so I guess this
>>> is something to check early on (i.e. if EJB 3.0 is at all
>>> considered). It is clear that standalone non J2EE open source
>>> solutions for EJB 3.0 are immature and this may definitely be an
>>> issue, however in 2-3 years from now, it will be ashame to look
>>> back and say we should have done EJB 3.0 because it is becoming a
>>> de-facto standard and is no longer just a standard on paper. So..
>>> if some work is to be invested in looking for a proper framework
>>> I still think EJB 3.0 should be considered.
>>>
>>> Ronen
>>>
>>> PS, we do use ffmpeg in TVersity.
>>>
>>> Mika Göckel wrote:
>>>
>>>> Hi Ronen,
>>>>
>>>> I'm a great fan of JBoss (and a JBoss certified JBoss J2EE
>>>> Developer and a former JBoss Partner) and love much of the stuff
>>>> they have. This said before, because I want to disagree with
>>>> you :-)
>>>>
>>>> OpenLaszlo is an application which is currently not dependent on
>>>> J2EE (if you don't count servlet API) -- you can run it in any
>>>> Servlet Container. Making it dependant on a J2EE container would
>>>> break a fly on the wheel in my opinion.
>>>> Using Spring would not prevent OL to be deployed as a servlet in
>>>> JBoss, but leaves the other option open.
>>>>
>>>> If I understand the EJB3 spec right, dependency injection via
>>>> annotations is in fact getting an object reference from a JNDI
>>>> tree and inject that. At the end, this means, that if you need
>>>> to construct a tree of interdependent objects you need to create
>>>> them in the right sequence and register them in JNDI -- a task
>>>> you want to leave to the app server :-). This means the whole
>>>> openlaszlo would have to be reengineered to be based on EJBs, or
>>>> do I just miss the point?
>>>>
>>>> Jbossmc(Microcontainer) looks more like what we would want. But
>>>> it is a rather young project (with an experienced Project Lead,
>>>> I admit). Spring on the other hand is mature and again, there is
>>>> much more developer experience, knowledge and information
>>>> material out there about Spring than JBossMC.
>>>>
>>>> Alternatively: I've worked a lot with JBossMX in the past and
>>>> thought if that would not be a good solution for OpenLaszlo,
>>>> using JBossMX as a microkernel to wire up the internal services
>>>> of it (like JBoss does for the AS themself), what do you think
>>>> about that?
>>>>
>>>> Besides that there is the license question..... JBoss stuff is
>>>> LGPL, OpenLaszlo is Common Public License Version 1.0, I'm not a
>>>> lawyer, is this a counter-argument?
>>>>
>>>> Let's hear what Oliver and Max think about it :-)
>>>>
>>>> Cheers, Mika
>>>>
>>>> P.S.: TVersity... do you use ffmpeg for transcoding?
>>>>
>>>> Ronen Mizrahi schrieb:
>>>>
>>>>> Hi,
>>>>>
>>>>> I am a new user of Laszlo and this is my first post here. I
>>>>> have been following the discussion in the development mail list
>>>>> and thought that if the use of inversion of control or
>>>>> dependency injection framework is to be seriously considered,
>>>>> it would also require consideration of the standalone EJB 3.0
>>>>> container by JBoss which allows POJOs to achieve the same
>>>>> things spring is aiming to provide but in a more standardized
>>>>> and in my opinion elegany way (due to the use of annotations
>>>>> that appear in the right context instead of XML files). This is
>>>>> not the heavywieght full blown J2EE implementation but rather a
>>>>> lightweight container intended to provided EJB 3.0 services to
>>>>> POJOs. Of-course the use of a standard based solution means
>>>>> that other EJB 3.0 implementations can be used in the future
>>>>> instead of JBoss. The only downside I see is that this is work
>>>>> in progress (currently alpha, which is available only from
>>>>> their CVS head) and it is not yet fully integrated with their
>>>>> microcontainer so some services (like transaction management
>>>>> still require the JBoss JTA implementation).
>>>>>
>>>>> Some links:
>>>>> http://docs.jboss.org/ejb3/embedded/embedded.html
>>>>> http://www.jboss.com/products/ejb3
>>>>> http://www.jboss.com/products/jbossmc
>>>>>
>>>>> Just my two cents,
>>>>>
>>>>> Ronen
>>>>>
>>>>> BTW, in case you are curious I am using Open Laszlo to develop
>>>>> GUI for the TVersity UPNP Media Server (http://
>>>>> www.tversity.com) and I have nothing to do with JBoss but
>>>>> rather simply a Java fan.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Laszlo-dev mailing list
>>> Laszlo-dev at openlaszlo.org
>>> http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
>>>
>>
>> _______________________________________________
>> Laszlo-dev mailing list
>> Laszlo-dev at openlaszlo.org
>> http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
>>
>
> _______________________________________________
> Laszlo-dev mailing list
> Laszlo-dev at openlaszlo.org
> http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
More information about the Laszlo-dev
mailing list