On Fri, 14 Nov 2003, Ted Husted wrote: <snip /> > Of course, we have the tyranny of the installed base to contend with. > Right now, a lot of Struts-specific presentation code expects things to > be stored in the shared contexts under the original keys. The module > code was designed to swap things in and out for that reason. > > So, if backward compatibility is desirable, then the framework API > object would have to do the same thing: push it's members into the > original shared contexts before an Action or some tag tool were invoked. > > If that were accomplished, we could then deprecate accessing these > resources from the shared locations, and eventually make everything > available only through the framework API object. A framework API object > should simplify the module implementation as well as the eventual > portlet implementation, and would certainly be more testable.
While I certainly am a huge fan of backwards compatibility, would that even be feasable? Take these chain of events: 1. Servlet 1 puts objects in context for action 1 2. Servlet 2 puts objects in context for action 2 3. Action 1 pulls out objects for Servlet 2 To rewrite all the code in the Struts CVS to use the framework API wouldn't be too difficult, however, its the third-party extensions, user actions, etc. which worry me. Perhaps a framework/services/IoC API should wait for a 2.0 release :/ If that's the case, I really want to start kicking 1.x releases out the door. What can I do to help? Don > > -Ted. > > > Don Brown wrote: > > What about using Inversion of Control (IoC) to replace the current > > global context map? The action servlet loads up the IoC factory, > > initializing all objects, then puts the factory in the request > > attributes for each request, allowing other components, like taglibs, > > to be able to access that servlet's objects? Not only would this > > make managing dependencies much cleaner, but make it easier to extend > > Struts once class references were changed into interfaces. Of course > > since any objects that aren't pre-initialized can pull objects from > > the bean factory in the request, we can ensure that the servlets > > won't overlap. > > > > The impact to existing Struts can be minimal - we could even put IoC > > configuration in the jar to prevent any user confusion. For an IoC > > implementation, I've found Spring (http://www.springframework.org) to > > be very easy to use and straightforward, not to mention light weight, > > however it would be pretty easy to provide a few Struts classes to > > wrap the IoC framework to prevent being tied to one implementation. > > > > I'm no Spring expert, but I volunteer to do any work necessary, > > assuming the idea is approved. > > > > Don > > > > On Fri, 14 Nov 2003, Ted Husted wrote: > > > > > >> The underlying problem is that Struts stores things directly in the > >> application and session contexts under static names. So, the > >> resources (in the generic sense) for one application can overwrite > >> the other. One reason for modules is to put multiple sets of > >> resources in the shared contexts under different names. > >> > >> An alternate design for the Struts 2.x timeframe might be to gather > >> everything the framework uses into single context objects, perhaps > >> named after the servlet. So the "action" servlet would have an > >> "action" context in the application and session scope, and the > >> "differentAction" servlet would have it's own "differentAction" > >> context object. Inside of each context (a Map) would be things like > >> the message resources and Locale the servlet and client are using. > >> > >> Then, when a request is being serviced, a default gateway context > >> can be placed in the request that would link to the appropriate > >> session and application contexts for a given controller instance. > >> This is essentially what the module code does now, but with all the > >> complications that backward compatibility brings. > >> > >> Of course, complications still arise. Such as if the "action" > >> servlet changes the Locale for a client, is the "differentAction" > >> servlet suppose to see that change? So, there might still be a > >> global framework context at the top of the chain, which a > >> controller instance could update and the other controllers could > >> see. > >> > >> Another advantage here is that it would be easier for Struts > >> applications to pass along its context to a business layer without > >> binding that layer to HTTP. An Action could pass up the Context > >> chain without passing the HTTP request itself, or pulling things > >> out piecemeal. > >> > >> -Ted. > >> > >> [EMAIL PROTECTED] wrote: > >> > >>> I'm with Edgar on this one - should it not be possible? Of > >>> course, I tried the following: > >>> > >>> <servlet-mapping> <servlet-name>action</servlet-name> > >>> <url-pattern>*.do</url-pattern> </servlet-mapping> > >>> > >>> <servlet-mapping> <servlet-name>differentAction</servlet-name> > >>> <url-pattern>*.dont</url-pattern> </servlet-mapping> > >>> > >>> with each mapping to different action servlets with different > >>> config files and everything got bunged up. It seems like it > >>> should have worked but alas. > >>> > >>> Perhaps it is a bit of a green question, but why would it not > >>> work? > >>> > >>> Best, > >>> > >>> Alvin > >>> > >>> Quoting Edgar P Dollin <[EMAIL PROTECTED]>: > >>> > >>> > >>> > >>>> Why wouldn't changing the servlet mapping from *.do --> action > >>>> servlet to *.[actiontype] --> [associated action servlet] work? > >>>> As long as you are consistent would struts care? > >>>> > >>>> Edgar > >>>> > >>>> > >>>> > >>>>> -----Original Message----- From: Ted Husted > >>>>> [mailto:[EMAIL PROTECTED] Sent: Friday, November 14, 2003 > >>>>> 7:10 AM To: Struts Developers List Subject: Re: Multi Action > >>>>> servlet ! > >>>>> > >>>>> > >>>>> People have done it, but it's a delicate thing to try. The > >>>>> recommended approach is to use Struts 1.1 modules. To > >>>>> customize the front controller logic for each module, you can > >>>>> plug in alternate Request Processors if needed. This gives > >>>>> you all the benefits of having multiple servlets, without the > >>>>> extra overhead. (There is *no* performance benefit in having > >>>>> multiple servlets that do the same thing.) > >>>>> > >>>>> A better place to ask questions like this would be the Struts > >>>>> USER list. This is where you'd ask if we were going to > >>>>> support multiple servlets in the future. (Answer to that one: > >>>>> not any time soon.) > >>>>> > >>>>> -Ted. > >>>>> > >>>>> Karikalan Kumaresan wrote: > >>>>> > >>>>> > >>>>>> Hi, > >>>>>> > >>>>>> Does anyone know, is it possible to have 2 action servlet > >>>>> > >>>>> configured > >>>>> > >>>>> > >>>>>> in struts for different project in a same JVM/in same > >>>>>> webserver. > >>>>>> > >>>>>> Cheers, Kari... > > > > > > --------------------------------------------------------------------- > 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]
