commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <craig...@apache.org>
Subject Re: [Chain] examples XML file available?
Date Tue, 23 Sep 2003 01:42:08 GMT
Sgarlata Matt wrote:

>Thanks for the test cases Ted!  More comments below...
>----- Original Message ----- 
>From: "Ted Husted" <husted@apache.org>
>To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
>Sent: Sunday, September 21, 2003 10:32 PM
>Subject: Re: [Chain] examples XML file available?
>
>
>  
>
>> > If I play with the package some more and like it, I could provide a
>> > DTD for the XML file and documentation for it.  That should save Craig
>> > and Ted from some boring work :)
>>
>>What might be helpful is a standalone ChainServlet that would load the
>>configuration file, like the sample PlugIn does. (A HiveMind service
>>might also be very cool.)
>>    
>>
>
>I can write the ChainServlet this week, borrowing relevant code from the
>CatalogConfiguratorPlugIn :)  HiveMind looks cool, but I'm not ready to
>invest time in learning it yet.
>
>  
>
>>Right now, I'm loading it as a Struts PlugIn (and imagine Craig is too),
>>but that wouldn't work for everyone.
>>    
>>
Of course I am :-).  After all, I'm loading the configuration for a 
"request processor" that has to tie in to the rest of the Struts 
infrastructure, so I know that it's all going to be there.

>>
>>Craig R. McClanahan wrote:
>>    
>>
>>>There's another example in the CVS HEAD sources of Struts, where we are
>>>experimenting with building a replacement for the current
>>>      
>>>
>RequestProcessor
>  
>
>>>class to assemble the request processing pipeline:
>>>
>>>  contrib/struts-chain/src/conf/chain-config.xml
>>>      
>>>
>>Also in the Struts Contrib CVS is a PlugIn class. Problem is, other
>>parts of that distribution are coupled to the Struts Nightly Build and
>>won't compile under Struts 1.1 (namely the Constants.MODULE_CONFIG_KEY).
>>    
>>
That particular issue can be addressed with a temporary workaround for 1.1.

>>I'd like to move the Struts CatalogConfiguratorPlugIn to the Commons
>>Chain distro and make it an optional compile, like JSF et al. That way,
>>people could start using Chain with Struts 1.1 "out of the box".
>>
>>Even if we could decouple the Contrib package from the Nightly Build,
>>I'm thinking if we have these other optional packages here, we can also
>>have one for Struts. So, the ComposableRequestProcessor would stay
>>there, but the CatalogConfiguratorPlugIn would move here.
>>
>>Does this sound all right?
>>    
>>
>
>Actually, if we write a ChainServlet then do we need a Struts PlugIn at all?
>If the ChainServlet is set to load before the ActionServlet and the
>ChainServlet stores its catalog in a known location, Struts users should be
>able to use the ChainServlet without using a PlugIn at all.  I do agree with
>your reasoning that the CatalogConfiguratorPlugIn should live in Chain
>instead of Struts, but I don't see a need for a PlugIn at all.
>  
>
Once ChainServlet has assembled the Catalog, how are you planning to 
make it available to the rest of the application?  Storing it as a 
servet context attribute still ties you to the servlet API, and that's 
(IMHO) too restrictive for a configuration mechanism inside 
commons-chain itself, which should be perfectly usable in a non-web 
environment.

This is the kind of reason why I stopped at providing you 
environment-independent APIs (and even using Digester to read XML files 
is an option -- you're perfectly free to configure the Catalog in other 
ways as well) to assemble your own configuration loading; tying it in to 
the rest of the "container" or "environment" you are running in should 
be the business of the client application, not the commons-chain package 
itself.

>  
>
>>-Ted.
>>    
>>
>
>Matt
>  
>
Craig

>
>---------------------------------------------------------------------
>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