You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Christopher Willingham <cw...@maine.rr.com> on 2003/02/12 21:23:22 UTC

Re: Forcing or replacing a request processor version 1.1 beta3 -

Since we're talking about programmatically altering a configuration, I too
am starting to see some needs for this.  For example, I was thinking about
changing the base layout that all my tiles inherit from so I could change
'skins' on the fly.  I'm not even sure if there's any public api within
tiles to do this because I haven't looked yet.  But I also see the same need
to do this with struts-menus and other aspects and wonder if this isn't an
intended approach.

What's the feeling out there amoung the struts developers about changing
struts configurations on the fly?  Not that it's something I'd want to make
a practice of but I do some cases where it could make life much easier.


----- Original Message -----
From: "Cedric Dumoulin" <ce...@apache.org>
To: "Struts Developers List" <st...@jakarta.apache.org>
Sent: Wednesday, February 12, 2003 8:17 AM
Subject: Re: Forcing or replacing a request processor version 1.1 beta3


>
>   Hi,
>
>   The TilesPlugin set the RequestProcessor to TilesRequestProcessor. It
> does it to simplify the way Tiles should be initialized: a user just
> need to declare the plugin. Then, the plugin check if the current
> RequestProcessor must be changed, or if it is already set by the user.
>
>   Cedric
>
> Peter A. Pilgrim wrote:
>
> > David Graham wrote:
> >
> >> After a quick glance at the code, I think your solution will work
> >> because it looks like TilesPlugin does the same thing.
> >>
> >> David
> >>
> >
> > Ah ha! I will have to look at TilesPlugin as well
> > to see why it is doing the same thing?
> >
> >>
> >>> From: "Peter A. Pilgrim" <pe...@xenonsoft.demon.co.uk>
> >>> Reply-To: "Struts Developers List" <st...@jakarta.apache.org>
> >>> To: Struts Developers List <st...@jakarta.apache.org>
> >>> Subject: Re: Forcing or replacing a request processor version 1.1
beta3
> >>> Date: Wed, 12 Feb 2003 00:52:51 +0000
> >>>
> >>> David Graham wrote:
> >>>
> >>>> Why you don't want to set the RequestProcessor in the
> >>>> struts-config.xml file?
> >>>>
> >>>> David
> >>>>
> >>>
> >>> Because I want to distribute Expresso Framework with the custom
> >>> request processor as standard. Does that answer the question?
> >>> Of course XML config works.
> >>>
> >>>>
> >>>>
> >>>>> From: "Peter A. Pilgrim" <pe...@xenonsoft.demon.co.uk>
> >>>>> Reply-To: "Struts Developers List" <st...@jakarta.apache.org>
> >>>>> To: Struts Dev <st...@jakarta.apache.org>
> >>>>> Subject: Forcing or replacing a request processor version 1.1 beta3
> >>>>> Date: Wed, 12 Feb 2003 00:02:59 +0000
> >>>>>
> >>>>> Hi
> >>>>>
> >>>>> I am looking at the Struts source code. I want to find
> >>>>> out the ActionServlet that is responsible for loading
> >>>>> and setting the RequestProcessor.
> >>>>>
> >>>>> I see a ControllerConfig in the utility with the default
> >>>>> "org.apache.struts.action.RequestProcessor". Is there
> >>>>> a way of overriding this hard setting programmatical?
> >>>>> I want to create an ActionServlet subclass that will
> >>>>> default to a CustomRequestProcessor without having
> >>>>> to set it in XML config.
> >>>>>
> >>>>> Also in the `ActionServlet.initModuleConfig' which
> >>>>> I think is responsible for initialisation all
> >>>>> the module configuration from the XML I was thinking
> >>>>> I could do something like this:
> >>>>>
> >>>>>
> >>>>>         // Parse the configuration for this module
> >>>>>         ModuleConfig config = null;
> >>>>>         InputStream input = null;
> >>>>>         String mapping = null;
> >>>>>         try {
> >>>>>             //@todo & FIXME replace with a FactoryMethod
> >>>>>             ModuleConfigFactory factoryObject =
> >>>>>                 ModuleConfigFactory.createFactory();
> >>>>>             config = factoryObject.createModuleConfig(prefix);
> >>>>>
> >>>>>
> >>>>> ControllerConfig cc =
> >>>>>     moduleConfig.getControllerConfig();
> >>>>> if ( cc.getProcessorClass().equals(
> >>>>>     "org.apache.struts.action.RequestProcessor" ) )
> >>>>>     cc.setProcessorClass("com.xenonsoft.fire.MyCustomProcessor");
> >>>>>
> >>>>> Is this a good idea?
> >>>>>
> >>>>> Tia
> >>>>>
> >>>>> --
> >>>>> Peter Pilgrim
> >>>>>            __ _____ _____ _____
> >>>>>           / //__  // ___// ___/   +  Serverside Java
> >>>>>          / /___/ // /__ / /__     +  Struts
> >>>>>         / // ___// ___// ___/     +  Expresso Committer
> >>>>>      __/ // /__ / /__ / /__       +  Independent Contractor
> >>>>>     /___//____//____//____/       +  Intrinsic Motivation
> >>>>> On Line Resume
> >>>>>    ||
> >>>>>    \\===>  `` http://www.xenonsoft.demon.co.uk/no-it-striker.html ''
> >>>>>
> >>>>>
>
>>>>> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> >>>>> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> _________________________________________________________________
> >>>> The new MSN 8: advanced junk mail protection and 2 months FREE*
> >>>> http://join.msn.com/?page=features/junkmail
> >>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> >>>> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
> >>>>
> >>>>
> >>>
> >>>
> >>> --
> >>> Peter Pilgrim
> >>>            __ _____ _____ _____
> >>>           / //__  // ___// ___/   +  Serverside Java
> >>>          / /___/ // /__ / /__     +  Struts
> >>>         / // ___// ___// ___/     +  Expresso Committer
> >>>      __/ // /__ / /__ / /__       +  Independent Contractor
> >>>     /___//____//____//____/       +  Intrinsic Motivation
> >>> On Line Resume
> >>>    ||
> >>>    \\===>  `` http://www.xenonsoft.demon.co.uk/no-it-striker.html ''
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> >>> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
> >>
> >>
> >>
> >>
> >> _________________________________________________________________
> >> Add photos to your e-mail with MSN 8. Get 2 months FREE*.
> >> http://join.msn.com/?page=features/featuredemail
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> >> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
> >>
> >>
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
>



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


Re: Forcing or replacing a request processor version 1.1 beta3 -

Posted by "Craig R. McClanahan" <cr...@apache.org>.

On Wed, 12 Feb 2003, Christopher Willingham wrote:

> What's the feeling out there amoung the struts developers about changing
> struts configurations on the fly?  Not that it's something I'd want to make
> a practice of but I do some cases where it could make life much easier.

If your change needs to be reflected in the underlying FooConfig objects
and collections, you're going to have a problem -- after the freeze()
method is called, any call to a property setter on these things will throw
IllegalStateException.  The reason for this is so that Struts can access
the HashMaps used for internal storage without needing to synchronize,
since it knows that the undelrying map cannot be changed by another
thread.

Craig

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