Yes, the essential idea is to expose Struts as some type of framework API object through the request. Where the objects the gateway object returns live would be an implementation issue. A framework API object was the original idea behind this little adventure:
http://cvs.apache.org/viewcvs/jakarta-struts/src/share/org/apache/struts/config/ConfigHelperInterface.java
http://cvs.apache.org/viewcvs/jakarta-struts/src/share/org/apache/struts/config/ConfigHelper.java
We first did it to help prototype the Velocity tools for Struts. The Velocity gang then came up with an implementation that didn't need a helper, and further development was then sidelined by the modules.
A very nifty way to implement a framework API object might be to use the Chain ContextBase object,
http://jakarta.apache.org/commons/sandbox/chain/apidocs/org/apache/commons/chain/impl/ContextBase.html
since it be used as a JavaBean or a Map, as need be.
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.
-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]
