You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@turbine.apache.org by Age Mooy <am...@home.nl> on 2002/07/26 13:48:07 UTC
Plexus cvs checkout ? (was RE: How Avalon might change Turbine)
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>
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>