portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Le Strat <dlest...@yahoo.com>
Subject Re: [JETSPEED 2] Choosing a component framework/micro-kernel
Date Thu, 16 Oct 2003 14:04:49 GMT
Some more service framework comparison.  Interesting
read:

http://nagoya.apache.org/wiki/apachewiki.cgi?HiveMind/HiveMindAndAvalon

http://nagoya.apache.org/wiki/apachewiki.cgi?AvalonAndOtherShinyContainers

The Hivemind project looks interesting especially the
interceptor stuff.  From what I have read on Hivemind:

"HiveMind is "wide open" compared to Avalon. Any
service can get a reference to any other service; any
module can extend any other module. A lot of HiveMind
is built in HiveMind; people often miss the IoC stuff
because it's accomplished using a HiveMind service,
rather than some kind of native configuration."

One of the posts I read, it does not seems possible to
use Avalon and Hivemind together:

"Avalon takes that problem domain, then adds a strong
"containment" concept (Avalon-Phoenix / Avalon-Merlin)
in places, which comes with additional security,
various kinds of "standalone" features, and
corresponding extra setup. 

What avalon also adds everywhere is a strong emphasis
on several patterns, like Inversion of Control, and a
very rigid lifecycle (rules that boil down to "set up
logging then dependencies then create worker threads"
that are encoded in interfaces and enforced by
containers) on every component. All this makes avalon
rather heavy to apply a system. That's a disadvantage
(lot of work, very much nonoptional dependency, some
flexibility lost) and an advantage (rigid, clean,
structured, common setup). 

HiveMind simply makes a few different choices, with
its own set of advantages and disadvantages. There's
no IoC, and various bits are /way/ more dynamic than
is desireable in an IoC environment. Looking past all
the "features" and "history" of both frameworks, this,
IMO, is the actual big difference. 

Which answers the implicit question "So why not
combine HiveMind and Avalon into a single project?":
there are a few core design choices that are different
between HiveMind and Avalon that make the two
distinctly incompatible. "

It may be worth it trying to ask from guidance from
some of the folks on the Hivemind or Avalon projects.

The Geronimo project is apparently facing the same
kind of issue.  See:

http://wiki.codehaus.org/geronimo/Architecture_2fKernel

This has a nice pros/cons analysis for Avalon.

Regards,

David.

--- dion@multitask.com.au wrote:
> Have you seen hivemind?
> 
> http://jakarta.apache.org/commons/sandbox/hivemind/
> --
> dIon Gillard, Multitask Consulting
> Blog:      http://blogs.codehaus.org/people/dion/
> 
> 
> David Le Strat <dlestrat@yahoo.com> wrote on
> 16/10/2003 01:21:17 AM:
> 
> > FYI, I found an interesting article comparing the
> > Spring/Avalon and PicoContainer framework.
> > 
> >
>
http://www.springframework.org/docs/lightweight_container.html
> > 
> > Interesting quote from the article:
> > 
> > "Avalon's most important container implementation,
> > Phoenix, targets standalone applications like full
> > servers. Avalon has its advantages there, as it
> has
> > been designed for start/stop cycles etc. The only
> > stable implementation for embedded use like within
> a
> > web application is Fortress, which competes with
> > Spring's bean container. Spring focuses on
> embedded
> > usage as application context, it does not aim to
> be a
> > foundation for server processes. And of course,
> > Spring's feature set for application development
> goes
> > far beyond the bean container itself."
> > 
> > I guess the choice boils down to what we are
> trying to
> > achieve:
> > - What is the primary purpose of the service
> > framework? Provide server services? Provide web
> > application services? Should Jetspeed provide/use
> a
> > framework for developing reusable portlets
> components
> > (as opposed to core portal services)?
> > - What core functionality should the service
> framework
> > provide? AOP, JTA, etc...
> > 
> > Just my two cents.  In any case, I like David ST
> > approach to create a commons like layer avoiding
> to
> > get too tightly coupled with the chosen service
> > framework.
> > 
> > Best regards,
> > 
> > David.
> > 
> > --- "Weaver, Scott" <Sweaver@rippe.com> wrote:
> > > I have been evaluating component/service/kernel
> > > frameworks.  So far, I really like what I see in
> > > Avalon Phoenix, it seems right down the alley of
> > > what we are trying to accomplish.  It also has
> > > built-in in JMX to manage components.
> > > 
> > > I briefly looked at picocontainer, very cool,
> > > however it is somewhat young where as Phoenix
> has
> > > quite a few projects built upon it, including
> Apache
> > > James.  Same goes for Hivemind with respect to
> being
> > > a less mature project.
> > > 
> > > I would love if everyone who has used/researched
> any
> > > of these products give me a summary of their
> > > findings/experiences so as we can make the best
> > > choice for Jetspeed.
> > > 
> > > I realize we had a recently discussed this in
> passed
> > > thread, but I want to keep this alive as we need
> to
> > > make this decision very soon.  Plus, I want to
> have
> > > as much community involvement/input on this
> choice
> > > as possible.
> > > 
> > > Regards,
> > >  ________________________________
> > > |                                |
> > > | Scott T Weaver                 |
> > > | <weaver@apache.org>            | 
> > > | Apache Jetspeed Portal Project |
> > > | Apache Pluto Portlet Container |
> > > |________________________________|
> > > 
> > > 
> > 
> > 
> > __________________________________
> > Do you Yahoo!?
> > The New Yahoo! Shopping - with improved product
> search
> > http://shopping.yahoo.com
> > 
> >
>
---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> jetspeed-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> jetspeed-dev-help@jakarta.apache.org
> > 
> 
> 
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> jetspeed-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> jetspeed-dev-help@jakarta.apache.org
> 


__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com

---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org


Mime
View raw message