You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-dev@portals.apache.org by "Weaver, Scott" <Sw...@rippe.com> on 2003/10/15 16:50:21 UTC
[JETSPEED 2] Choosing a component framework/micro-kernel
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 |
| <we...@apache.org> |
| Apache Jetspeed Portal Project |
| Apache Pluto Portlet Container |
|________________________________|
Re: [JETSPEED 2] Choosing a component framework/micro-kernel
Posted by BaTien Duong <ba...@dbgroups.com>.
Weaver, Scott 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 had a casual look at HiveMind, SpringFramework, and Pico. My first
impression is that different frameworks will meet different
requirements. A flexible, non-intrusive framework is better than a
rigid, my way or the high way, framework. Different frameworks must live
together since no single one can be the answer for all architecture issues.
In this sense, HiveMind seems to be better than the one based on Avalon.
There was some comparison of HiveMind and Avalon by someone who is
familiar with both, posted on this list sometimes ago. HiveMind fits as
a centralized registry of services and extension points, which is what
the portal and portlet containers are.
Both SpringFramework and Pico seems to design for any arbitrary
container and can fit as extension point(s) in HiveMind. There is some
comparion (probably with some bias) between SpringFramework and Pico on
the SpringFramework site.
I will spend some more time with HiveMind, especially HiveMind with
Commons Chain.
BaTien
DBGROUPS
>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 |
>| <we...@apache.org> |
>| Apache Jetspeed Portal Project |
>| Apache Pluto Portlet Container |
>|________________________________|
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [JETSPEED 2] Choosing a component framework/micro-kernel
Posted by David Le Strat <dl...@yahoo.com>.
Check http://www.acm.org/chapters/webtech/ if you are
interested by the event mentioned previously.
David.
--- BaTien Duong <ba...@dbgroups.com> wrote:
> David Le Strat wrote:
>
> >I don't know if any of you guys are in the Boston
> area
> >but there will be a presentation of Hivemind by
> Howard
> >Lewis Ship on Oct 21st, organized by the ACM at the
> >IBM SPC in Waltham. Thought that may be
> interesting
> >to attend.
> >
> >Regards,
> >
> >David.
> >
> >__________________________________
> >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
> >
> >.
> >
> >
> >
> Please report significant topics and available
> links. I view component
> framework a very strategic point in the overall
> architect.
> BaTien
> DBGROUPS
>
>
>
---------------------------------------------------------------------
> 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
Re: [JETSPEED 2] Choosing a component framework/micro-kernel
Posted by BaTien Duong <ba...@dbgroups.com>.
David Le Strat wrote:
>I don't know if any of you guys are in the Boston area
>but there will be a presentation of Hivemind by Howard
>Lewis Ship on Oct 21st, organized by the ACM at the
>IBM SPC in Waltham. Thought that may be interesting
>to attend.
>
>Regards,
>
>David.
>
>__________________________________
>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
>
>.
>
>
>
Please report significant topics and available links. I view component
framework a very strategic point in the overall architect.
BaTien
DBGROUPS
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [JETSPEED 2] Choosing a component framework/micro-kernel
Posted by David Le Strat <dl...@yahoo.com>.
To follow up with that thread, here is some more info
on Hivemind. It indeed looks interesting. Lewis
presentation can be found at:
http://jakarta.apache.org/~hlship/HiveMind.ppt
Outside of the typical IoC support, I believe
interesting features are:
1. The concept of interceptor which allows in a
similar way than aspects to provide cross cutting
points to services (though with quite more lightweight
functionally).
2. Localization support: the ability to localize
services (limited to 1 local per instantiation so not
really for user localization but more for logs).
3. Substitution: The ability to provide configuration
variable substitution at start up (for instance
instantiate a service jdbc parameters through
substitution from a main configuration point).
4. Hivedoc: Interesting to keep track of the service
and their evolution.
Lewis presentation does a good job at providing a good
overview of the framework.
Hivemind seems to have good arguments in its favor but
may be difficult to wrap with CPS (mostly because of
the work performed by the XML configurator). The XML
configuration probably would have to be closely look
at.
If we decide to wrap Avalon with CPS, I believe it may
still be worth it to explore the use of aspects. Any
thougths on this?
Regards,
David.
__________________________________
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
Re: [JETSPEED 2] Choosing a component framework/micro-kernel
Posted by David Le Strat <dl...@yahoo.com>.
I don't know if any of you guys are in the Boston area
but there will be a presentation of Hivemind by Howard
Lewis Ship on Oct 21st, organized by the ACM at the
IBM SPC in Waltham. Thought that may be interesting
to attend.
Regards,
David.
__________________________________
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
Re: [JETSPEED 2] Choosing a component framework/micro-kernel
Posted by David Le Strat <dl...@yahoo.com>.
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 <dl...@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" <Sw...@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 |
> > > | <we...@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
Re: [JETSPEED 2] Choosing a component framework/micro-kernel
Posted by di...@multitask.com.au.
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 <dl...@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" <Sw...@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 |
> > | <we...@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
Re: [JETSPEED 2] Choosing a component framework/micro-kernel
Posted by David Le Strat <dl...@yahoo.com>.
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" <Sw...@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 |
> | <we...@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
RE: [JETSPEED 2] Choosing a component framework/micro-kernel
Posted by Tim Reilly <ti...@consultant.com>.
May be a dumb question, but is it possible to combine Avalon and Hivemind?
The configuration, service-point, interceptor, etc - paradigm
is very appealing to me.
Let's say you have a usage reporting requirement.
Your marketing department wants real-time stats so they can track campaigns
in real-time
so you implement a "web-bug"/"hidden-pixel" strategy.
Just an example, but your portlet calls a usage logging service. The service
sets up data in the request
for your jsp tags to use during the rendering of the portlet, which adds the
pixel/bug and parameters.
This works fine except a few months later you find out your legal department
has a compliance requirement and
needs the same/similar data, but they need it in common log format and must
be generated on the server,
not derived from data from the original solution.
You create a different service implementation and then configure the service
container to use serviceimpl1, serviceimpl2
or both serviceimpl1 and serviceimpl2
Perhaps the example isn't great, but hopefully the idea comes across.
What I see with hivemind this could easily be "configured-in".
I don't know much about Avalon, but my concern/question is whether or not
Avalon precludes this level of
flexibility or not?
On the general topic; asking for some input from Avalon and Hivemind
contributors may not be
a bad idea.
I recall some commons discussions where H.L. Ship (Hivemind et al) was very
level about why one would
use one over the other (e.g. not over selling - Hivemind over Avalon, just
describing the diff's and reason
for the project when Avalon exists)
I'll see if I can find the post again, if anyone wishes?
Regards
-TR
> -----Original Message-----
> From: Glenn R. Golden [mailto:ggolden@umich.edu]
> Sent: Wednesday, October 15, 2003 11:46 PM
> To: Jetspeed Developers List
> Subject: Re: [JETSPEED 2] Choosing a component framework/micro-kernel
>
>
> Scott, I probably said this before recently, but I still recommend we
> use the Avalon Framework, not an Avalon Product like Phoenix. The
> Avalon Framework is very close to a "wrapper" API only services
> methodology, with very little implementation. It tells us how to write
> our services, and how to write the service container that will give
> life to the services.
>
> If we decide on this, we can go on and re-factor the services to fit
> the rich (and optional) life cycles that Avalon Framework provides.
>
> Then we can find one of the Avalon containers to use, or write our own.
> I think that the Avalon folks would aim us at Merlin or Fortress, not
> Phoenix.
>
> In my current project, we are currently taking this approach, and are
> probably going to write our own container for Avalon Framework
> services. The services don't care what the container is as long as it
> plays the full and correct Avalon Framework game. My project's needs
> are probably strange enough to justify our own container. It's not so
> hard to create a good, simple Avalon container.
>
> Now, this is just for services, not for a micro-kernel, which is more
> like what Phoenix gives, I think. I'm not sure Jetspeed needs a
> micro-kernel, since it's basically a servlet with many services and
> Pluto. What I think we need is a service model to replace Turbine, and
> I like Avalon Framework.
>
> And we might be able to either retro-fit Pluto to use Avalon services,
> and then either use Pluto's service container or our own as an Avalon
> container. Just thinking here...
>
> - Glenn
>
> On Wednesday, October 15, 2003, at 10:50 AM, Weaver, Scott 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 |
> > | <we...@apache.org> |
> > | Apache Jetspeed Portal Project |
> > | Apache Pluto Portlet Container |
> > |________________________________|
> >
>
>
> ---------------------------------------------------------------------
> 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
Re: [JETSPEED 2] Choosing a component framework/micro-kernel
Posted by "Glenn R. Golden" <gg...@umich.edu>.
Scott, I probably said this before recently, but I still recommend we
use the Avalon Framework, not an Avalon Product like Phoenix. The
Avalon Framework is very close to a "wrapper" API only services
methodology, with very little implementation. It tells us how to write
our services, and how to write the service container that will give
life to the services.
If we decide on this, we can go on and re-factor the services to fit
the rich (and optional) life cycles that Avalon Framework provides.
Then we can find one of the Avalon containers to use, or write our own.
I think that the Avalon folks would aim us at Merlin or Fortress, not
Phoenix.
In my current project, we are currently taking this approach, and are
probably going to write our own container for Avalon Framework
services. The services don't care what the container is as long as it
plays the full and correct Avalon Framework game. My project's needs
are probably strange enough to justify our own container. It's not so
hard to create a good, simple Avalon container.
Now, this is just for services, not for a micro-kernel, which is more
like what Phoenix gives, I think. I'm not sure Jetspeed needs a
micro-kernel, since it's basically a servlet with many services and
Pluto. What I think we need is a service model to replace Turbine, and
I like Avalon Framework.
And we might be able to either retro-fit Pluto to use Avalon services,
and then either use Pluto's service container or our own as an Avalon
container. Just thinking here...
- Glenn
On Wednesday, October 15, 2003, at 10:50 AM, Weaver, Scott 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 |
> | <we...@apache.org> |
> | Apache Jetspeed Portal Project |
> | Apache Pluto Portlet Container |
> |________________________________|
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org