You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@turbine.apache.org by Leo Simons <le...@apache.org> on 2002/07/26 10:33:39 UTC
How Avalon might change Turbine
Hi all,
there seems to be a lot of misunderstanding / lack of understanding /
uncertainty about the effort Jason is making to move Turbine's Fulcrum
to be based on avalon. This is quite understandable!
I've been around as an avalon committer for quite some time and a
Turbine (2.1 exclusively) user as well.
I will try to explain a few things here the way I see them. I might not
be completely correct. The W3C would see: this section is informative,
not normative ;)
Contents
========
- What is a Service/Component/Block?
- What happens to the Turbine Services?
- What will happen to our servlets / what changes for users?
- Singleton Services Are Considered Evil
- What parts of Avalon will we (not) use?
- Where will our services go?
- So why do all this?
- What about compatibility?
- Conclusions
What is a Service/Component/Block?
==================================
All Avalon documentation atm is a bit formal defining precise contracts,
suggested scopes etc (I'm working to improve it =). Throwing all the
high-level contracts and definitions out the window will help a little.
Mostly, a Service == a Component. We've talked about renaming Component
to Service, then for some reason chose not to. We did agree that they
are basically interchangeable. I'm going to use the name "service" in
this e-mail as that is what turbine uses atm.
Mostly, a Block == a Really-Big-Service/Component. Simple guideline: if
it listens on a port, it is likely a Block. An example block would be a
RDMS, an FTP Server, a Servlet Engine. "Block" is just an arbitrary
concept though, and not really relevant for Turbine (I don't think
Turbine's services should be called "blocks"). So just forget about it
again.
Making "Turbine Services" into "Avalon Components" is conceptually
nearly no difference.
What happens to the Turbine Services?
=====================================
Interface Change
----------------
Their interface will change; they will refer to
org.apache.avalon.framework pieces of code. That's basically our
"lifecycle management" code.
For example, if you a service needs to be configured [1], in the future
you will probably do it somewhat like this:
MyTurbineService.java
---------------------
class MyTurbineService
implements org.apache.framework.configuration.Configurable
{
configure(
org.apache.framework.configuration.Configuration c )
{
// do stuff
}
}
turbine.config
--------------
<configuration>
<services>
<service class="o.a.t.fulcrum.my.MyTurbineService">
<somexmlhere/>
</service>
</services>
</configuration>
What will happen to our servlets / what changes for users?
==========================================================
Jason is writing something called "plexus" [2] (which is in early alpha
I think). This will be what we call an "avalon container" [3]
specifically written for Turbine.
What this will do is handle loading and management of services. Plexus
will load the example turbine.config above, load relevant classes, load
other important stuff, create instances of all the required services,
and then configure and initialize them. After this, it will provide
access to them for the end user in some way.
It might look like the sample below (I have no idea whether it will
though!). Note this code is quite silly; it is just an example.
MyServlet.java
--------------
/** example of using turbine in your own servlet */
MyServlet
{
Plexus m_plexus;
// ...
MyServlet()
{
m_plexus = new Plexus();
m_plexus.configure( "turbine.config" );
m_plexus.initialize();
// ...
}
handleRequest( Request req, Response res )
{
RequestParserService rps = m_plexus.getService(
"requestParserService" );
YourHandlerService yhs = m_plexus.getService(
"YourHandlerService" );
Context c = rps.parse( req, res );
yhs.handle( c );
}
}
I'm not sure, but I think plexus conceptually takes the place of the
Factory service.
Singleton Services Are Considered Evil
======================================
Fulcrum is a singleton services framework. Avalon strongly discourages
the use of *actual* singletons [4]. All services will change to have a
public no-arguments constructor. The guarantee that there will be only
one instance of the service (what singletons are about) is handled by
what we avalon geeks call "creational policy".
Creational policy determines whether there is one service instance per
thread, per classloader, many in a pool, or ... any number of
possibilities. This should be (mostly) transparent to the end user.
Creation policy will be handled by the areforementioned plexus anyway
(you just request a service instance, and get one; no need to worry
about pooling for the end user), so this is neat. The updated example
configuration snippet might look like:
turbine.config
--------------
<configuration>
<services>
<service class="o.a.t.fulcrum.my.MyTurbineService">
<policy>
<creational>classloader</creational>
</policy>
<morexmlhere/>
</service>
</services>
</configuration>
What parts of Avalon will we (not) use?
=======================================
Framework: it'll be everywhere
------------------------------
Allmost all services will reference org.apache.avalon.framework. This
package goes into avalon-framework-XXX.jar and the avalon framework
distribution [5]. I suspect we'll be at version 4.1.3 or maybe 4.2.0 by
the time Turbine 3 is released (the framework doesn't change too much,
nor should it).
Excalibur & Cornerstone: probably bits of 'em
---------------------------------------------
There might also be services in avalon (though they might be called
components or blocks) of use within Turbine. Some of the services cocoon
uses (also servlet technology, so there must be overlap) are in a module
called Avalon Excalibur [6] (there's also Avalon Cornerstone [7]). We
have an excalibur release [8]; we've been busy decoupling the services
and packaging them up separately (and now moving some to commons), so
the next release will feel different but look the same.
Logkit: if you wanna
--------------------
I think y'all know about Avalon Logkit; if anything, it should become
easier to use. It is not required; there's a logging abstraction in
avalon framework that among other things supports log4j; how it will
relate to commons logging in the future I dunno nor will discuss as I
hate burning my fingers in the logging flamefests. I do know it is easy
to use log4j with avalon as I do so quite a lot =)
Phoenix
-------
The biggest and most feature-rich container [3] we have is Avalon
Phoenix. I don't think you'll be using it; phoenix is way too heavy for
use in a servlet environment. Plexus will be used instead.
Apps
----
I think you won't use stuff within Avalon Applications directly; don't
concern yourself with it (it contains stuff like a RDMS, CORBA ORB,
etc).
Where will our services go?
===========================
It's been suggested they should all move to a common repository within
like jakarta-avalon-components. This might happen in the future but I'd
suggest keeping them nice and warm within turbine itself at first, ie I
think a jakarta-turbine-plexus CVS will be proposed. No need to change
everything at once =)
If we have one repository of services, and all of jakarta/xml would be
"avalonized" (not that it will happen any time soon ;), the repository
would be really big. I see turbine as the natural place to put
servlet-related stuff (Intake, JSP, Upload, stuff like that). Things
usuable outside servlet scope (Cache, Velocity) might move to avalon.
So why do all this?
===================
Re-use
------
The best part about making fulcrum follow avalon patterns and concepts
is that the services avalon provides and the ones turbine provides will
be able to be used interchangeably.
For example, I have a GUI avalon-based application for personalized
e-mail marketing campaigns that uses velocity. In the future I'll
refactor it to use the velocity service from turbine, though I'm not
likely to use other parts of turbine.
This is way cool =)
Furthermore, services from other "avalonized" projects will also become
easy to use. I don't know much about cocoon [9], but it does use avalon
extensively and it is pretty smart servlet technology so there might be
something to share between cocoon and turbine.
Really good design
------------------
Avalon's been designed really well =)
Using the patterns avalon promotes [10] really cleans up your head and
your code once you get used to it. Since Fulcrum has *a lot* of
similarities here with avalon, the changes and the benefits here will be
less pronounced.
I happen to think that the avalon lifecycle setup is a little better
than the one in fulcrum (and I think Jason agrees); I understand fulcrum
has been moving in the general avalon lifecycle direction for quite some
time.
If -- for some reason not understandable to an avalon addict -- y'all
disagree and fulcrum's lifecycle is better, well, your losses won't be
that grave because the differences are very small.
Less confusion
--------------
How many frameworks does apache have? 10 or so? ;)
If we can define Avalon as the "generic server framework" and Turbine as
the "web services framework" (sorry to leave Struts fans out of the
picture ;), and then have Turbine as a natural 'extension' (don't like
that word) to Avalon, that'll make life a lot simpler in the end.
Need a neat service/component-oriented framework? Get avalon. Need to
add the "web" in "web services"? Turbine's your choice.
This as opposed to: "hey, Turbine Fulcrum has a Cache service, and
Avalon Excalibur has one too. What is the relationship? :-S".
Less duplication
----------------
More reuse will lead to less duplication, which will lead to more good
things happening with our spare time.
What about compatibility?
=========================
This is the singlemost important issue. A lot of the classes in fulcrum
are definately going to change in a way that will, I think, not be
completely backwards compatible.
It should be possible to provide a 'compatibility layer' which basically
wraps the new 'avalonized' services inside the old singleton model. I
don't know enough about recent turbine to provide an estimate of the
difficulty.
Conclusions
===========
The integration between Avalon and Turbine will benefit both projects,
and in a larger scope will likely benefit many projects at both jakarta
and xml@apache, because there will be a lot more reuse between projects
and a lot more clarity of the relationships between projects.
Fulcrum's architecture is already similar to Avalon so moving over will
be relatively painless. Jason is working on an avalon container for
Turbine, called plexus, that will be the basis of an 'avalonized'
fulcrum. There will be some issues but a backward compatibility layer
should be possible.
While the avalon project as a whole is quite big, the framework (which
will be the most 'intrusive' for Fulcrum) is small, stable, has clear
boundaries, and will not remove features Fulcrum currently has.
Overall, I'm very exited with the effort Jason's making to do the
integration as it will make the three projects I use most at work
(avalon, turbine, velocity) all but perfect. Combined with ant2 possibly
using avalon as well [11], this makes me very happy =)
I hope to have addressed your major questions and concerns, if not, fire
(not flame! 8) away.
best regards,
- Leo Simons
[1] -
http://cvs.apache.org/viewcvs.cgi/jakarta-avalon/src/java/org/apache/avalon/framework/configuration/
[2] - http://tambora.zenplex.org/cgi-bin/cvsweb.cgi/plexus/
[3] -
http://jakarta.apache.org/avalon/framework/reference-containers.html
http://jakarta.apache.org/avalon/framework/guide-cop-in-avalon.html
[4] - "Design Patterns", Eric Gamma et al
[5] -
http://jakarta.apache.org/builds/jakarta-avalon/release/framework/latest/
[6] - http://jakarta.apache.org/avalon/excalibur
[7] - http://jakarta.apache.org/avalon/cornerstone
[8] -
http://jakarta.apache.org/builds/jakarta-avalon/release/excalibur/latest/
[9] - http://xml.apache.org/cocoon
[10] -
http://jakarta.apache.org/avalon/framework/guide-patterns-in-avalon.html
[11] - http://jakarta.apache.org/ant/myrmidon/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: How Avalon might change Turbine
Posted by Jason van Zyl <ja...@zenplex.com>.
On Fri, 2002-07-26 at 04:33, Leo Simons wrote:
> Hi all,
>
> there seems to be a lot of misunderstanding / lack of understanding /
> uncertainty about the effort Jason is making to move Turbine's Fulcrum
> to be based on avalon. This is quite understandable!
Thank you!
Hopefully this will clear things up for people. I have exactly zero time
at the moment for the mailing lists at the moment so I'm immensely
grateful. Thanks again.
--
jvz.
Jason van Zyl
jason@apache.org
http://tambora.zenplex.org
In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
-- Jacques Ellul, The Technological Society
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: How Avalon might change Turbine
Posted by Pat Monardo <pa...@cox.net>.
I think Kabala talks about the kernel/shell pattern (is there an
official kernel/shell pattern?) so I guess it is a religious thing ;-).
Of course, the shell is also a 'user block' so really the pattern would
be
Kernel/User with User being a three fold pattern:
Shell/Service/Component.
Or the SIVA pattern: Service Inspector/Verifier/Adaptor. SIVA as the
ultimate Phoenix BlockListener.
Pat Monardo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: How Avalon might change Turbine
Posted by Pat Monardo <pa...@cox.net>.
> yup. Where things get muddy is on-demand processes you start via
xinetd,
> ie hierarchical processes, etc etc...few java systems have as clear a
> separation as you summarise.
Well Avalon does ;-) xinetd is what Phoenix would call a Block. It's
just heavily service oriented.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: How Avalon might change Turbine
Posted by Leo Simons <le...@apache.org>.
On Fri, 2002-07-26 at 19:24, Pat Monardo wrote:
> Thanks very much for this document.
glad y'all like it =)
> I have to say I am excited about
> this direction.
good! You probably had a few of those "gotchas"...characteristic for
learning the concepts avalon promotes :)
> I was too concerned to be excited earlier but now my
> excitement has defeated my concern! Awesome. During this time I have
> been learning Avalon and the PDF "Developing with Avalon" was a
> particularly inspiring document.
cool. Berin's writing a book, y'know (which is why he's not maintaining
this paper, I guess)...
> Here's a little analogy from the ancient Unix model:
> If a component can be considered the object analog of a process, then a
> service would be the object analog of a daemon process. So a service is
> simply a component that is "init'ed" by the system and whose interface
> is advertised / controlled by the system and not the application. For
> example, ever app has a sendmail() method which ultimately uses a
> standard call to the well known sendmail service.
yup. Where things get muddy is on-demand processes you start via xinetd,
ie hierarchical processes, etc etc...few java systems have as clear a
separation as you summarise.
> Anyway, Programming the Dream to me is having a Services layer that is
> omniscient and omnipotent.
yup. (and all those other things like scalable, KISS, secure, etc etc,
too =)
> Hey! So in practical terms, systems like
> Avalon know this platform will be multilayered and programmed by all
> types of programmers and not just heavy duty service provider types.
yes! We started out mostly on the 'heavy duty' side. I'm guessing
turbine client programmers are a lot more 'soft duty' on average than
current avalon users, so there's a challenge for us to come up with the
stuff a 'newb' can digest.
This is one area where any help from learning people would be most
welcome; if you find easier/simpler ways to explain things, please get
in touch. See [1] for my current efforts in that direction....
> Middleware is definitely interesting. It is a heavy burden so religion
> is a big part of it.
hence the name "avalon" :D
("nirwana" would've been to obvious I guess, and braggin' too ;)
regards,
- Leo, very happy so far with the unexpectedly warm reception
[1] - http://jakarta.apache.org/avalon/excalibur/tweety/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: How Avalon might change Turbine
Posted by Pat Monardo <pa...@cox.net>.
Thanks very much for this document. I have to say I am excited about
this direction. I was too concerned to be excited earlier but now my
excitement has defeated my concern! Awesome. During this time I have
been learning Avalon and the PDF "Developing with Avalon" was a
particularly inspiring document.
Here's a little analogy from the ancient Unix model:
If a component can be considered the object analog of a process, then a
service would be the object analog of a daemon process. So a service is
simply a component that is "init'ed" by the system and whose interface
is advertised / controlled by the system and not the application. For
example, ever app has a sendmail() method which ultimately uses a
standard call to the well known sendmail service.
Anyway, Programming the Dream to me is having a Services layer that is
omniscient and omnipotent. Hey! So in practical terms, systems like
Avalon know this platform will be multilayered and programmed by all
types of programmers and not just heavy duty service provider types.
Middleware is definitely interesting. It is a heavy burden so religion
is a big part of it.
Pat Monardo
-----Original Message-----
From: Leo Simons [mailto:leosimons@apache.org]
Sent: Friday, July 26, 2002 1:34 AM
To: Turbine Developers List
Subject: How Avalon might change Turbine
Hi all,
there seems to be a lot of misunderstanding / lack of understanding /
uncertainty about the effort Jason is making to move Turbine's Fulcrum
to be based on avalon. This is quite understandable!
I've been around as an avalon committer for quite some time and a
Turbine (2.1 exclusively) user as well.
I will try to explain a few things here the way I see them. I might not
be completely correct. The W3C would see: this section is informative,
not normative ;)
Contents
========
- What is a Service/Component/Block?
- What happens to the Turbine Services?
- What will happen to our servlets / what changes for users?
- Singleton Services Are Considered Evil
- What parts of Avalon will we (not) use?
- Where will our services go?
- So why do all this?
- What about compatibility?
- Conclusions
What is a Service/Component/Block?
==================================
All Avalon documentation atm is a bit formal defining precise contracts,
suggested scopes etc (I'm working to improve it =). Throwing all the
high-level contracts and definitions out the window will help a little.
Mostly, a Service == a Component. We've talked about renaming Component
to Service, then for some reason chose not to. We did agree that they
are basically interchangeable. I'm going to use the name "service" in
this e-mail as that is what turbine uses atm.
Mostly, a Block == a Really-Big-Service/Component. Simple guideline: if
it listens on a port, it is likely a Block. An example block would be a
RDMS, an FTP Server, a Servlet Engine. "Block" is just an arbitrary
concept though, and not really relevant for Turbine (I don't think
Turbine's services should be called "blocks"). So just forget about it
again.
Making "Turbine Services" into "Avalon Components" is conceptually
nearly no difference.
What happens to the Turbine Services?
=====================================
Interface Change
----------------
Their interface will change; they will refer to
org.apache.avalon.framework pieces of code. That's basically our
"lifecycle management" code.
For example, if you a service needs to be configured [1], in the future
you will probably do it somewhat like this:
MyTurbineService.java
---------------------
class MyTurbineService
implements org.apache.framework.configuration.Configurable
{
configure(
org.apache.framework.configuration.Configuration c )
{
// do stuff
}
}
turbine.config
--------------
<configuration>
<services>
<service class="o.a.t.fulcrum.my.MyTurbineService">
<somexmlhere/>
</service>
</services>
</configuration>
What will happen to our servlets / what changes for users?
==========================================================
Jason is writing something called "plexus" [2] (which is in early alpha
I think). This will be what we call an "avalon container" [3]
specifically written for Turbine.
What this will do is handle loading and management of services. Plexus
will load the example turbine.config above, load relevant classes, load
other important stuff, create instances of all the required services,
and then configure and initialize them. After this, it will provide
access to them for the end user in some way.
It might look like the sample below (I have no idea whether it will
though!). Note this code is quite silly; it is just an example.
MyServlet.java
--------------
/** example of using turbine in your own servlet */
MyServlet
{
Plexus m_plexus;
// ...
MyServlet()
{
m_plexus = new Plexus();
m_plexus.configure( "turbine.config" );
m_plexus.initialize();
// ...
}
handleRequest( Request req, Response res )
{
RequestParserService rps = m_plexus.getService(
"requestParserService" );
YourHandlerService yhs = m_plexus.getService(
"YourHandlerService" );
Context c = rps.parse( req, res );
yhs.handle( c );
}
}
I'm not sure, but I think plexus conceptually takes the place of the
Factory service.
Singleton Services Are Considered Evil
======================================
Fulcrum is a singleton services framework. Avalon strongly discourages
the use of *actual* singletons [4]. All services will change to have a
public no-arguments constructor. The guarantee that there will be only
one instance of the service (what singletons are about) is handled by
what we avalon geeks call "creational policy".
Creational policy determines whether there is one service instance per
thread, per classloader, many in a pool, or ... any number of
possibilities. This should be (mostly) transparent to the end user.
Creation policy will be handled by the areforementioned plexus anyway
(you just request a service instance, and get one; no need to worry
about pooling for the end user), so this is neat. The updated example
configuration snippet might look like:
turbine.config
--------------
<configuration>
<services>
<service class="o.a.t.fulcrum.my.MyTurbineService">
<policy>
<creational>classloader</creational>
</policy>
<morexmlhere/>
</service>
</services>
</configuration>
What parts of Avalon will we (not) use?
=======================================
Framework: it'll be everywhere
------------------------------
Allmost all services will reference org.apache.avalon.framework. This
package goes into avalon-framework-XXX.jar and the avalon framework
distribution [5]. I suspect we'll be at version 4.1.3 or maybe 4.2.0 by
the time Turbine 3 is released (the framework doesn't change too much,
nor should it).
Excalibur & Cornerstone: probably bits of 'em
---------------------------------------------
There might also be services in avalon (though they might be called
components or blocks) of use within Turbine. Some of the services cocoon
uses (also servlet technology, so there must be overlap) are in a module
called Avalon Excalibur [6] (there's also Avalon Cornerstone [7]). We
have an excalibur release [8]; we've been busy decoupling the services
and packaging them up separately (and now moving some to commons), so
the next release will feel different but look the same.
Logkit: if you wanna
--------------------
I think y'all know about Avalon Logkit; if anything, it should become
easier to use. It is not required; there's a logging abstraction in
avalon framework that among other things supports log4j; how it will
relate to commons logging in the future I dunno nor will discuss as I
hate burning my fingers in the logging flamefests. I do know it is easy
to use log4j with avalon as I do so quite a lot =)
Phoenix
-------
The biggest and most feature-rich container [3] we have is Avalon
Phoenix. I don't think you'll be using it; phoenix is way too heavy for
use in a servlet environment. Plexus will be used instead.
Apps
----
I think you won't use stuff within Avalon Applications directly; don't
concern yourself with it (it contains stuff like a RDMS, CORBA ORB,
etc).
Where will our services go?
===========================
It's been suggested they should all move to a common repository within
like jakarta-avalon-components. This might happen in the future but I'd
suggest keeping them nice and warm within turbine itself at first, ie I
think a jakarta-turbine-plexus CVS will be proposed. No need to change
everything at once =)
If we have one repository of services, and all of jakarta/xml would be
"avalonized" (not that it will happen any time soon ;), the repository
would be really big. I see turbine as the natural place to put
servlet-related stuff (Intake, JSP, Upload, stuff like that). Things
usuable outside servlet scope (Cache, Velocity) might move to avalon.
So why do all this?
===================
Re-use
------
The best part about making fulcrum follow avalon patterns and concepts
is that the services avalon provides and the ones turbine provides will
be able to be used interchangeably.
For example, I have a GUI avalon-based application for personalized
e-mail marketing campaigns that uses velocity. In the future I'll
refactor it to use the velocity service from turbine, though I'm not
likely to use other parts of turbine.
This is way cool =)
Furthermore, services from other "avalonized" projects will also become
easy to use. I don't know much about cocoon [9], but it does use avalon
extensively and it is pretty smart servlet technology so there might be
something to share between cocoon and turbine.
Really good design
------------------
Avalon's been designed really well =)
Using the patterns avalon promotes [10] really cleans up your head and
your code once you get used to it. Since Fulcrum has *a lot* of
similarities here with avalon, the changes and the benefits here will be
less pronounced.
I happen to think that the avalon lifecycle setup is a little better
than the one in fulcrum (and I think Jason agrees); I understand fulcrum
has been moving in the general avalon lifecycle direction for quite some
time.
If -- for some reason not understandable to an avalon addict -- y'all
disagree and fulcrum's lifecycle is better, well, your losses won't be
that grave because the differences are very small.
Less confusion
--------------
How many frameworks does apache have? 10 or so? ;)
If we can define Avalon as the "generic server framework" and Turbine as
the "web services framework" (sorry to leave Struts fans out of the
picture ;), and then have Turbine as a natural 'extension' (don't like
that word) to Avalon, that'll make life a lot simpler in the end.
Need a neat service/component-oriented framework? Get avalon. Need to
add the "web" in "web services"? Turbine's your choice.
This as opposed to: "hey, Turbine Fulcrum has a Cache service, and
Avalon Excalibur has one too. What is the relationship? :-S".
Less duplication
----------------
More reuse will lead to less duplication, which will lead to more good
things happening with our spare time.
What about compatibility?
=========================
This is the singlemost important issue. A lot of the classes in fulcrum
are definately going to change in a way that will, I think, not be
completely backwards compatible.
It should be possible to provide a 'compatibility layer' which basically
wraps the new 'avalonized' services inside the old singleton model. I
don't know enough about recent turbine to provide an estimate of the
difficulty.
Conclusions
===========
The integration between Avalon and Turbine will benefit both projects,
and in a larger scope will likely benefit many projects at both jakarta
and xml@apache, because there will be a lot more reuse between projects
and a lot more clarity of the relationships between projects.
Fulcrum's architecture is already similar to Avalon so moving over will
be relatively painless. Jason is working on an avalon container for
Turbine, called plexus, that will be the basis of an 'avalonized'
fulcrum. There will be some issues but a backward compatibility layer
should be possible.
While the avalon project as a whole is quite big, the framework (which
will be the most 'intrusive' for Fulcrum) is small, stable, has clear
boundaries, and will not remove features Fulcrum currently has.
Overall, I'm very exited with the effort Jason's making to do the
integration as it will make the three projects I use most at work
(avalon, turbine, velocity) all but perfect. Combined with ant2 possibly
using avalon as well [11], this makes me very happy =)
I hope to have addressed your major questions and concerns, if not, fire
(not flame! 8) away.
best regards,
- Leo Simons
[1] -
http://cvs.apache.org/viewcvs.cgi/jakarta-avalon/src/java/org/apache/ava
lon/framework/configuration/
[2] - http://tambora.zenplex.org/cgi-bin/cvsweb.cgi/plexus/
[3] -
http://jakarta.apache.org/avalon/framework/reference-containers.html
http://jakarta.apache.org/avalon/framework/guide-cop-in-avalon.html
[4] - "Design Patterns", Eric Gamma et al
[5] -
http://jakarta.apache.org/builds/jakarta-avalon/release/framework/latest
/
[6] - http://jakarta.apache.org/avalon/excalibur
[7] - http://jakarta.apache.org/avalon/cornerstone
[8] -
http://jakarta.apache.org/builds/jakarta-avalon/release/excalibur/latest
/
[9] - http://xml.apache.org/cocoon
[10] -
http://jakarta.apache.org/avalon/framework/guide-patterns-in-avalon.html
[11] - http://jakarta.apache.org/ant/myrmidon/
--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Plexus cvs checkout ? (was RE: How Avalon might change Turbine)
Posted by Leo Simons <le...@apache.org>.
On Fri, 2002-07-26 at 13:48, Age Mooy wrote:
> It all sounds very interesting... can I checkout the current plexus code
> from the zenplex cvs server somehow ? CvsWeb is not the easiest tool for
> reading source code :)
http://tambora.zenplex.org/docs/dev/cvs.html
you'll wanna change the cvs command to co the module 'plexus' rather
than tambora.
> Any idea when the plexus code can be moved to the jakarta-turbine-plexus
> repo ?
I think when jason is satisfied enough to call it "alpha".
>
> Can I somehow use Plexus from a turbine 2.2 app or do I need turbine-3 for
> that ?
you can't really use it yet at all....it is pre-alpa.
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Plexus cvs checkout ? (was RE: How Avalon might change Turbine)
Posted by Age Mooy <am...@home.nl>.
It all sounds very interesting... can I checkout the current plexus code
from the zenplex cvs server somehow ? CvsWeb is not the easiest tool for
reading source code :)
Any idea when the plexus code can be moved to the jakarta-turbine-plexus
repo ?
Can I somehow use Plexus from a turbine 2.2 app or do I need turbine-3 for
that ?
Age
> -----Original Message-----
> From: Leo Simons [mailto:leosimons@apache.org]
> Sent: Friday, July 26, 2002 10:34
> To: Turbine Developers List
> Subject: How Avalon might change Turbine
>
>
> Hi all,
>
> there seems to be a lot of misunderstanding / lack of understanding /
> uncertainty about the effort Jason is making to move Turbine's Fulcrum
> to be based on avalon. This is quite understandable!
>
> I've been around as an avalon committer for quite some time and a
> Turbine (2.1 exclusively) user as well.
>
> I will try to explain a few things here the way I see them. I might not
> be completely correct. The W3C would see: this section is informative,
> not normative ;)
>
> Contents
> ========
> - What is a Service/Component/Block?
> - What happens to the Turbine Services?
> - What will happen to our servlets / what changes for users?
> - Singleton Services Are Considered Evil
> - What parts of Avalon will we (not) use?
> - Where will our services go?
> - So why do all this?
> - What about compatibility?
> - Conclusions
>
>
> What is a Service/Component/Block?
> ==================================
>
> All Avalon documentation atm is a bit formal defining precise contracts,
> suggested scopes etc (I'm working to improve it =). Throwing all the
> high-level contracts and definitions out the window will help a little.
>
> Mostly, a Service == a Component. We've talked about renaming Component
> to Service, then for some reason chose not to. We did agree that they
> are basically interchangeable. I'm going to use the name "service" in
> this e-mail as that is what turbine uses atm.
>
> Mostly, a Block == a Really-Big-Service/Component. Simple guideline: if
> it listens on a port, it is likely a Block. An example block would be a
> RDMS, an FTP Server, a Servlet Engine. "Block" is just an arbitrary
> concept though, and not really relevant for Turbine (I don't think
> Turbine's services should be called "blocks"). So just forget about it
> again.
>
> Making "Turbine Services" into "Avalon Components" is conceptually
> nearly no difference.
>
>
> What happens to the Turbine Services?
> =====================================
>
> Interface Change
> ----------------
> Their interface will change; they will refer to
> org.apache.avalon.framework pieces of code. That's basically our
> "lifecycle management" code.
>
> For example, if you a service needs to be configured [1], in the future
> you will probably do it somewhat like this:
>
> MyTurbineService.java
> ---------------------
>
> class MyTurbineService
> implements org.apache.framework.configuration.Configurable
> {
> configure(
> org.apache.framework.configuration.Configuration c )
> {
> // do stuff
> }
> }
>
> turbine.config
> --------------
> <configuration>
> <services>
> <service class="o.a.t.fulcrum.my.MyTurbineService">
> <somexmlhere/>
> </service>
> </services>
> </configuration>
>
>
> What will happen to our servlets / what changes for users?
> ==========================================================
>
> Jason is writing something called "plexus" [2] (which is in early alpha
> I think). This will be what we call an "avalon container" [3]
> specifically written for Turbine.
>
> What this will do is handle loading and management of services. Plexus
> will load the example turbine.config above, load relevant classes, load
> other important stuff, create instances of all the required services,
> and then configure and initialize them. After this, it will provide
> access to them for the end user in some way.
>
> It might look like the sample below (I have no idea whether it will
> though!). Note this code is quite silly; it is just an example.
>
> MyServlet.java
> --------------
>
> /** example of using turbine in your own servlet */
> MyServlet
> {
> Plexus m_plexus;
>
> // ...
>
> MyServlet()
> {
> m_plexus = new Plexus();
> m_plexus.configure( "turbine.config" );
> m_plexus.initialize();
>
> // ...
> }
>
> handleRequest( Request req, Response res )
> {
> RequestParserService rps = m_plexus.getService(
> "requestParserService" );
> YourHandlerService yhs = m_plexus.getService(
> "YourHandlerService" );
> Context c = rps.parse( req, res );
> yhs.handle( c );
> }
> }
>
> I'm not sure, but I think plexus conceptually takes the place of the
> Factory service.
>
> Singleton Services Are Considered Evil
> ======================================
>
> Fulcrum is a singleton services framework. Avalon strongly discourages
> the use of *actual* singletons [4]. All services will change to have a
> public no-arguments constructor. The guarantee that there will be only
> one instance of the service (what singletons are about) is handled by
> what we avalon geeks call "creational policy".
>
> Creational policy determines whether there is one service instance per
> thread, per classloader, many in a pool, or ... any number of
> possibilities. This should be (mostly) transparent to the end user.
>
> Creation policy will be handled by the areforementioned plexus anyway
> (you just request a service instance, and get one; no need to worry
> about pooling for the end user), so this is neat. The updated example
> configuration snippet might look like:
>
> turbine.config
> --------------
> <configuration>
> <services>
> <service class="o.a.t.fulcrum.my.MyTurbineService">
> <policy>
> <creational>classloader</creational>
> </policy>
> <morexmlhere/>
> </service>
> </services>
> </configuration>
>
>
> What parts of Avalon will we (not) use?
> =======================================
>
> Framework: it'll be everywhere
> ------------------------------
> Allmost all services will reference org.apache.avalon.framework. This
> package goes into avalon-framework-XXX.jar and the avalon framework
> distribution [5]. I suspect we'll be at version 4.1.3 or maybe 4.2.0 by
> the time Turbine 3 is released (the framework doesn't change too much,
> nor should it).
>
> Excalibur & Cornerstone: probably bits of 'em
> ---------------------------------------------
> There might also be services in avalon (though they might be called
> components or blocks) of use within Turbine. Some of the services cocoon
> uses (also servlet technology, so there must be overlap) are in a module
> called Avalon Excalibur [6] (there's also Avalon Cornerstone [7]). We
> have an excalibur release [8]; we've been busy decoupling the services
> and packaging them up separately (and now moving some to commons), so
> the next release will feel different but look the same.
>
> Logkit: if you wanna
> --------------------
> I think y'all know about Avalon Logkit; if anything, it should become
> easier to use. It is not required; there's a logging abstraction in
> avalon framework that among other things supports log4j; how it will
> relate to commons logging in the future I dunno nor will discuss as I
> hate burning my fingers in the logging flamefests. I do know it is easy
> to use log4j with avalon as I do so quite a lot =)
>
> Phoenix
> -------
> The biggest and most feature-rich container [3] we have is Avalon
> Phoenix. I don't think you'll be using it; phoenix is way too heavy for
> use in a servlet environment. Plexus will be used instead.
>
> Apps
> ----
> I think you won't use stuff within Avalon Applications directly; don't
> concern yourself with it (it contains stuff like a RDMS, CORBA ORB,
> etc).
>
> Where will our services go?
> ===========================
>
> It's been suggested they should all move to a common repository within
> like jakarta-avalon-components. This might happen in the future but I'd
> suggest keeping them nice and warm within turbine itself at first, ie I
> think a jakarta-turbine-plexus CVS will be proposed. No need to change
> everything at once =)
>
> If we have one repository of services, and all of jakarta/xml would be
> "avalonized" (not that it will happen any time soon ;), the repository
> would be really big. I see turbine as the natural place to put
> servlet-related stuff (Intake, JSP, Upload, stuff like that). Things
> usuable outside servlet scope (Cache, Velocity) might move to avalon.
>
> So why do all this?
> ===================
>
> Re-use
> ------
> The best part about making fulcrum follow avalon patterns and concepts
> is that the services avalon provides and the ones turbine provides will
> be able to be used interchangeably.
>
> For example, I have a GUI avalon-based application for personalized
> e-mail marketing campaigns that uses velocity. In the future I'll
> refactor it to use the velocity service from turbine, though I'm not
> likely to use other parts of turbine.
>
> This is way cool =)
>
> Furthermore, services from other "avalonized" projects will also become
> easy to use. I don't know much about cocoon [9], but it does use avalon
> extensively and it is pretty smart servlet technology so there might be
> something to share between cocoon and turbine.
>
> Really good design
> ------------------
> Avalon's been designed really well =)
> Using the patterns avalon promotes [10] really cleans up your head and
> your code once you get used to it. Since Fulcrum has *a lot* of
> similarities here with avalon, the changes and the benefits here will be
> less pronounced.
>
> I happen to think that the avalon lifecycle setup is a little better
> than the one in fulcrum (and I think Jason agrees); I understand fulcrum
> has been moving in the general avalon lifecycle direction for quite some
> time.
>
> If -- for some reason not understandable to an avalon addict -- y'all
> disagree and fulcrum's lifecycle is better, well, your losses won't be
> that grave because the differences are very small.
>
> Less confusion
> --------------
> How many frameworks does apache have? 10 or so? ;)
>
> If we can define Avalon as the "generic server framework" and Turbine as
> the "web services framework" (sorry to leave Struts fans out of the
> picture ;), and then have Turbine as a natural 'extension' (don't like
> that word) to Avalon, that'll make life a lot simpler in the end.
>
> Need a neat service/component-oriented framework? Get avalon. Need to
> add the "web" in "web services"? Turbine's your choice.
>
> This as opposed to: "hey, Turbine Fulcrum has a Cache service, and
> Avalon Excalibur has one too. What is the relationship? :-S".
>
> Less duplication
> ----------------
> More reuse will lead to less duplication, which will lead to more good
> things happening with our spare time.
>
>
> What about compatibility?
> =========================
>
> This is the singlemost important issue. A lot of the classes in fulcrum
> are definately going to change in a way that will, I think, not be
> completely backwards compatible.
>
> It should be possible to provide a 'compatibility layer' which basically
> wraps the new 'avalonized' services inside the old singleton model. I
> don't know enough about recent turbine to provide an estimate of the
> difficulty.
>
> Conclusions
> ===========
>
> The integration between Avalon and Turbine will benefit both projects,
> and in a larger scope will likely benefit many projects at both jakarta
> and xml@apache, because there will be a lot more reuse between projects
> and a lot more clarity of the relationships between projects.
>
> Fulcrum's architecture is already similar to Avalon so moving over will
> be relatively painless. Jason is working on an avalon container for
> Turbine, called plexus, that will be the basis of an 'avalonized'
> fulcrum. There will be some issues but a backward compatibility layer
> should be possible.
>
> While the avalon project as a whole is quite big, the framework (which
> will be the most 'intrusive' for Fulcrum) is small, stable, has clear
> boundaries, and will not remove features Fulcrum currently has.
>
> Overall, I'm very exited with the effort Jason's making to do the
> integration as it will make the three projects I use most at work
> (avalon, turbine, velocity) all but perfect. Combined with ant2 possibly
> using avalon as well [11], this makes me very happy =)
>
> I hope to have addressed your major questions and concerns, if not, fire
> (not flame! 8) away.
>
> best regards,
>
> - Leo Simons
>
> [1] -
> http://cvs.apache.org/viewcvs.cgi/jakarta-avalon/src/java/org/apac
he/avalon/framework/configuration/
[2] - http://tambora.zenplex.org/cgi-bin/cvsweb.cgi/plexus/
[3] -
http://jakarta.apache.org/avalon/framework/reference-containers.html
http://jakarta.apache.org/avalon/framework/guide-cop-in-avalon.html
[4] - "Design Patterns", Eric Gamma et al
[5] -
http://jakarta.apache.org/builds/jakarta-avalon/release/framework/latest/
[6] - http://jakarta.apache.org/avalon/excalibur
[7] - http://jakarta.apache.org/avalon/cornerstone
[8] -
http://jakarta.apache.org/builds/jakarta-avalon/release/excalibur/latest/
[9] - http://xml.apache.org/cocoon
[10] -
http://jakarta.apache.org/avalon/framework/guide-patterns-in-avalon.html
[11] - http://jakarta.apache.org/ant/myrmidon/
--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>