james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@osm.net>
Subject Re: Avalon feedback request
Date Sat, 27 Jul 2002 22:11:10 GMT

Peter M. Goldstein wrote:

>>Personally I would like to see
>>  (a) improvements in the framework usage
>Any specific, immediate recommendations?

1.  James uses the org.apache.avalon.framework.component.* interfaces
    and classes.  This really ties you to components developed strictly
    in the Avalon model - which simply makes you life more difficult.  
    The alternative is to use the org.apache.avalon.framework.service.*
    instead - the difference is that component can be any java.lang.Object.
    It kind of makes life easier when your working in the real world.

2.  Declare you depedency on the framework as an extension jar dependency.
    The current avalon-framework.jar (Avalon current CVS build) includes
    this.  If the jar files created by James include extension depedencies
    your can get more rigerouse about version control.

>>  (b) cleaning up of Avalon Excalibur dependencies (the Excalibur 
>>      packages has been cleaned up a lot and you can now limit your 
>>      dependencies to only those packages you need) - whereas the 
>>      James lib includes all Excalibur contents
>By my count we have the following top-level James dependencies:

    Jar File: excalibur-collections-1.0.jar
    Extension Name: excalibur-collections


   Jar File: excalibur-datasource-1.0.jar
   Extension Name: excalibur-datasource

But you should check this because there are two sub-packages included in 
the datasource project that you may have depedencies on.


    Jar File: excalibur-io-1.1.jar
    Extension Name: excalibur-io


   Jar File: excalibur-thread-1.0.jar
   Extension Name: excalibur-thread

On this package it appears that there are several depedencies to other 
excalibur package ut they are not documeted in the manifest.  I'll post 
this ias an issue over on Avalon-Dev.

>So I'm sure we can do that reduction.
>>  (c) elimination of structural dependencies on Phoenix (Block and 
>>Block context
>>      usage).  This would eliminate the Phoenix jar dependency and is 
>>      easy to do.  It would enable the deployment of James in more 
>>      scenarios (embedded, part of web-service), etc. - while 
>>maintaining your
>>      ability to deploy under Phoenix where appropriate.
>As of right now we use the BlockContext for one thing and one thing only
>- to determine the root directory where James is running.  This allows
>us to use relative URLs in the configuration parameters.  Quite
>honestly, I'm not sure this is the best way to do this, although I can't
>come up with anything else other than adding a root directory
>configuration parameter.  This probably requires a little discussion on
>the james-dev list.

All you need to do is to replace BlockContext with 
framework.context.Context, then get the File reference as follows:

    File file = (File) context.get("app.home");

You simply changing the depedency from Phoenix to "a context object 
capable of providing a File instance keyed by the name "app.home". 
 There is work going on over in Avalon to enable you to declare this 
context depedency indendently of the container.  I can provide more 
about this is a seperate thread (sometime later).  In the meantime, the 
above change will work when deployed in Phoeinix - and it will also work 
in avalon containers.

Cheers, Steve.


Stephen J. McConnell

digital products for a global economy

To unsubscribe, e-mail:   <mailto:james-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:james-dev-help@jakarta.apache.org>

View raw message