Craig,
I have given your response some thought. I agree with you about making the interface public and providing a default implementation. No problem there.
I definitely think this would be useful to have. I am now writing a Struts application using chain and I have already run into a situation where I need it. I'm using CatalogConfiguratorPlugIn but my service layer (where I'm storing my business logic) has been designed to be independent of the servlet API. So when I want to execute a chain of commands, I cannot get to the Catalog that the PlugIn initialized because its putting the Catalog in the ServletContext which does not help me.
I definitely think having a CatalogFactory will help with non-web applications which cannot rely on the ServletContext to pass refs to a Catalog around.
Any thoughts?
sean
I confess to ambivalence on this one. While it's always nice to have utility APIs like this, is there really enough value add over the typical naive implementation?
If you do go ahead and propose the code for this, I'd suggest a public interface in o.a.c.chain and a default implementation in o.a.c.chain.impl as you see for the other APIs.
Craig
On Tue, 21 Sep 2004 14:12:19 -0400, Sean Schofield
<[EMAIL PROTECTED]> wrote:
I'm proposing we consider adding a CatalogFactory class with the following methods:
+getInstance():CatalogFactory +getCatalog():Catalog
We'd also have an init() method or two to help initialize the Factory. We could then change ChainListener to use CatalogFactory to intialize and store the catalog (instead of storing in the ServletContext.)
I think CatalogFactory would be a good way to make a Catalog available to the rest of the application (whether its a servlet application, struts application or stand-alone application.)
What do you guys think?
sean
ps. I'm happy to get us started if folks can agree.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
