RE: Raising feature requests and fix suggestions - What's the acceptedway.

[Richard Tomlinson <Ri...@t-mobile.co.uk>]

> As others have mentioned, Bugzilla is the best way to raise 
> enhancement 
> requests (and post corresponding patches), while the 
> STRUTS-DEV list is 
> the best place to discuss ideas.

I'll follow this route, thanks.

> With regard to reload, you're going to find yourself 
> disappointed when 
> you can change config files but not classes; so it seems like 
> a lot of 
> effort for little gain (but it's not my effort, so not as big a deal 
> :-).

Changing the config is very useful when wiring together an initial site.  In large scale sites there's usually a two phase approach where the design house build the html and throws in the links.  In the second phase the tech guys build in the functionality.   To enable the first phase to happen where they can wire stuff up without a container restart is very helpful.

  I have found that using the right container makes all the 
> difference in the world; my typical turnaround time for an 
> "ant reload" 
> command issued against Tomcat is a couple of seconds -- and 
> that means 
> reloading the entire app, so it *does* pick up new and 
> updated Java classes.

Ah, but sometimes the client mandates a heavyweight container like WLS.  When you've got this with lots of bean deployment and wanting to wire up some new flow its a real benefit not to have to restart.

Fortunately, the ActionServlet is designed well enough to make extending and creating a Reloadable version a breeze.  Apart from refactoring some init() code into a seperate method the implemenetation of reloading is just a series of method calls.

Extending this further, CMS is more of an issue in the corporate environment.  Users want to be able to clone pages, add some links and content areas and quickly create content.  Its therefore of interest to ensure dynamic update of module config is available.

Regards
Richard.

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

Re: Raising feature requests and fix suggestions - What's the acceptedway.

["Craig R. McClanahan" <cr...@apache.org>]

Richard Tomlinson wrote:

>>As others have mentioned, Bugzilla is the best way to raise 
>>enhancement 
>>requests (and post corresponding patches), while the 
>>STRUTS-DEV list is 
>>the best place to discuss ideas.
>>    
>>
>
>I'll follow this route, thanks.
>
>  
>
>>With regard to reload, you're going to find yourself 
>>disappointed when 
>>you can change config files but not classes; so it seems like 
>>a lot of 
>>effort for little gain (but it's not my effort, so not as big a deal 
>>:-).
>>    
>>
>
>Changing the config is very useful when wiring together an initial site.  In large scale sites there's usually a two phase approach where the design house build the html and throws in the links.  In the second phase the tech guys build in the functionality.   To enable the first phase to happen where they can wire stuff up without a container restart is very helpful.
>
>  I have found that using the right container makes all the 
>  
>
>>difference in the world; my typical turnaround time for an 
>>"ant reload" 
>>command issued against Tomcat is a couple of seconds -- and 
>>that means 
>>reloading the entire app, so it *does* pick up new and 
>>updated Java classes.
>>    
>>
>
>Ah, but sometimes the client mandates a heavyweight container like WLS.  When you've got this with lots of bean deployment and wanting to wire up some new flow its a real benefit not to have to restart.
>
>Fortunately, the ActionServlet is designed well enough to make extending and creating a Reloadable version a breeze.  Apart from refactoring some init() code into a seperate method the implemenetation of reloading is just a series of method calls.
>  
>
Actually, that's only part of the battle.

All of the org.apache.struts.config.* objects assume that their internal 
collections can not be modified during runtime, so they skip 
synchronization on all the lookups.  You'll have to replace this entire 
hierarchy of classes with ones that lock the maps on all operations.

>Extending this further, CMS is more of an issue in the corporate environment.  Users want to be able to clone pages, add some links and content areas and quickly create content.  Its therefore of interest to ensure dynamic update of module config is available.
>
>Regards
>Richard.
>  
>
Craig



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