commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Juozas Baliuka" <bali...@mwm.lt>
Subject Re: Query: Hosting Avalon Components
Date Fri, 25 Apr 2003 12:37:14 GMT

As I understant it is not very practical to host Avalon components in
commons.
If they become commons components they will loose Avalon features later or
will start
to conflict with Avalon versions or become "invissible" in sandbox.

----- Original Message -----
From: "Leo Simons" <leosimons@apache.org>
To: <commons-dev@jakarta.apache.org>
Sent: Friday, April 25, 2003 12:43 PM
Subject: Re: Query: Hosting Avalon Components


> up-front summary: first answers to technical questions, next post will
> be about "management". "avalon components" are interface/class pairs
> distinguished (practically speaking) from normal beans by a dependency
> on avalon-framework.jar. They are perfectly usuable outside of an avalon
> container as long as you do a little work and include
> avalon-framework.jar or do some extra work while building the component.
>
> Henri Yandell wrote:
> > What's an Avalon component? Something that implements the Initable,
> > Startable stuff? [I'm sketchy on Avalon]
>
> sort-of. In practical terms, what we call "avalon component" /usually/
> has an interface, implementation of that interface, and additionally
> implementation of some of those "lifecycle interfaces" inside
> avalon-framework.jar. avalon-framework.jar sorta is to
> Component-Oriented Programming what java.lang (+ commons-lang ;) is to
OOP.
>
> example:
>
> public interface MyService
> {
>    String ROLE = MyService.class.getName();
>
>    Object doStuff();
> }
>
> public class MyClass implements MyService,
>      Servicable // Serviceable lives in avalon-framework.jar
> {
>    private MyPrereqService prereqService = null;
>
>    public void service( ServiceManager sm ) {
>      this.prereqService =
>        (MyPrereqService)sm.lookup( MyPrereqService.ROLE );
>    }
>
>    protected MyPrereqService getPrereqService() {
>      return this.prereqService;
>    }
>
>    public void doStuff()
>    {
>      getPrereqService().doSomething( /* ... */ );
>      /* ... */
>    }
> }
>
> > I can see that it doesn't make any sense to host an Avalon component in
> > Jakarta Commons if it's only useful in an Avalon container,
>
> this is almost never the case for a properly built component, though you
> often need to do some extra work.
>
> COP-By-Wrapping
> ---------------
> This is the most common usecase today. You have a utility bean (say,
> commons-digester) which you want to be able to transparently use in an
> avalon-based environment. Last time we talked about this here, I think I
> wrote a full sample wrapper around commons-digester. Many avalon devs
> code all of their commercial/home-grown projects this way.
>
> Roll-Your-Own-Container
> -----------------------
> A minimal use-once "avalon container" is equivalent to a few lines of
> code in your calling class.
>
> Code example which allows you to use MyClass just by importing
> avalon-framework.jar:
>
> // ... somewhere
>
> DefaultServiceManager sm =
>      new DefaultServiceManager(); // lives in avalon-framework
> MyPrereqService prereq = new MyPrereqServiceImpl();
> sm.put( MyprereqService.ROLE, prereq );
> MyService my = new MyClass();
> ContainerUtil.service( my, sm ); // lives in avalon-framework
>
> // .... somewhere, cont'd
>
> COP-Is-Optional
> ---------------
> What we are seeing more and more is components which are /optionally/
> avalonized. For example, you can put the above code snippet into the
> getPrereqService to have a component "be its own container", in fact it
> is a completely reusable bean again:
>
> public class MyClass implements MyService,
>      Servicable // Serviceable lives in avalon-framework.jar
> {
>    private MyPrereqService prereqService = null;
>
>    public void doStuff()
>    {
>      getPrereqService().doSomething( /* ... */ );
>      /* ... */
>    }
>
>    public void service( ServiceManager sm ) {
>      this.prereqService =
>        (MyPrereqService)sm.lookup( MyPrereqService.ROLE );
>    }
>
>    protected MyPrereqService getPrereqService() {
>      if( this.prereqService != null )
>        return this.prereqService;
>      else
>        this.startup();
>    }
>
>    private void startup()
>    {
>      DefaultServiceManager sm =
>        new DefaultServiceManager(); // lives in avalon-framework
>      MyPrereqService prereq = new MyPrereqServiceImpl();
>      sm.put( MyprereqService.ROLE, prereq );
>      MyService my = new MyClass();
>      ContainerUtil.service( this, sm ); // lives in avalon-framework
>    }
> }
>
> the only difference a client will see between a component coded like
> this and a regular bean is the need to put avalon-framework.jar on the
> classpath:
>
> // ... somewhere
>
> MyService myService = new MyClass();
> myService.doStuff(); // Just Works(tm)
>
> // ... somewhere, contd
>
> the cost for this flexibility is a compile-time dependency on the
> MyPrereqServiceImpl inside MyClass, as opposed to merely on the work
> interface, but the coupling can be isolated, or seperated out into a
> utility jar.
>
> Concrete Example
> ----------------
> Berin's question popped up in relation to components which are used
> inside cocoon and other projects which live in avalon-excalibur cvs atm.
>
>
http://cvs.apache.org/viewcvs.cgi/avalon-excalibur/store/src/java/org/apache
/excalibur/store/impl/MemoryStore.java?rev=1.6&content-type=text/vnd.viewcvs
-markup
>
> says
>
> // ....
> public class MemoryStore
>      extends AbstractLogEnabled
>      implements Store, ThreadSafe {
> // ...
>
> in order to use this component in your application, you can do
>
> Store myStore = new MemoryStore();
> ContainerUtil.enableLogging( myStore, new ConsoleLogger() );
>      // ConsoleLogger lives in avalon-framework; other options
>      // provided there include NullLogger, Log4jLogger,
>      // LogkitLogger, and jdk1.4 logging. A wrapper around
>      // commons-logging is planned for framework 4.1.5 and has
>      // been previously discussed here
> myStore.hold( key, value );
> myStore.get( key );
>
> IOW, the difference is an additional library to include and a single
> line of code.
>
> Where Code Should Live
> ----------------------
> > unless there
> > are lots of Jakarta Projects out there which are customers of the Avalon
> > project. Then it makes some sense, though it could also be Avalon
Commons
> > [or better name] as a subproject of Avalon?
> >
> > If there are Jakarta projects out there who want to share Avalon
> > components, I don't see why they can't be in Jakarta Commons.
>
> I'll tackle this part of the issue (which is more complex) in a seperate
> post.
>
> cheers,
>
> - Leo
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>


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


Mime
View raw message