cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Kossakowski <>
Subject Re: Abstract classes for Spring-based components
Date Tue, 06 Nov 2007 20:46:19 GMT
Thorsten Scherler pisze:
> Which is a perfect valid question. Actually I still need Avalon ATM for
> a port of the dispatcher.

I see. So the general should be that if you develop Spring-based component and need a ServiceManager
you should obtain it by using DI as for any other component. That's important note that should
included in a page describing how to develop Spring-based components.

> The dispatcher is till now a forrest plugin, but for my current customer
> project I need the plugin as cocoon 2.2 block. 
> Till now I just need a proof of concept port without totally dropping
> all avalon code. To make it work quickly I am using the service manager
> till I find out which replacement classes/methods we can use for e.g.
> source resolving etc.

I see. It's perfectly valid approach.

>> Yes, I agree. This is a really good task for 2.3 that should appear 
>> shortly IMO.
> Ah, ok 2.3 is for the complete move. Makes me thing whether 3.0 would
> not be the better name (since avalon would not be supported anymore).

I would see 2.3 as release introducing all Avalon-free abstract classes for components and
deprecating Avalon-based ones. Then in 3.0 we could remove them from the core as well as move
support for Avalon to separate module or even drop completely.

> I mean 
> public interface Generator extends XMLProducer, SitemapModelComponent {
>     String ROLE = Generator.class.getName();
>     /**
>      * Generate the XML and stream it into the pipeline
>      */
>     void generate()
>     throws IOException, SAXException, ProcessingException;
> }
> Where the void generate() will produce SAX events, right? The interface
> we need to change for sure is SitemapModelComponent since it uses
> org.apache.avalon.framework.parameters.Parameters.

Ah, yes. Nevertheless, it's not a problem to replace Paramters by something else, this class
quite straightforward.

> Bottom line for me is that it would be very helpful to see some abstract
> classes one can extend for new components that are 100% spring. I agree
> that it is easy and I hopefully will find time to submit some examples
> in the near future.

Great, thanks for discussing these things!

Grzegorz Kossakowski
Committer and PMC Member of Apache Cocoon

View raw message