I haven't studied the source from this perspective, but it certainly seems feasible.
I don't know if we want to expose the ActionServlet in the request as much as the resources associated with it. So I'd think about an interface for a JavaBean that encapsulated the Mappings and the Messages and whatever else might come up. Something like the StrutsConfig that's been mentioned. Perhaps there could be a factory method for this, so other resources could be added to a subclass. It might also be possible to write this "resource bean" so the interface is not bound to the Web tier. The primary could save the original resources under the original keys, for backward compatibility. It would be the developer's responsible to see that exactly one servlet is marked the primary. As mentioned, other components could "fall back" to this if the resource bean was not in the request. I would add + A ActionServlet.getMappings() method, that would return the link to it's own mappings. + A collection in Application Scope to store all the "resource beans". As each ActionServlet initialized, it would create or add to this collection. At runtime, it could then pluck it's own bean, and put it into the request. -- Ted Husted, Husted dot Com, Fairport NY USA. -- Custom Software ~ Technical Services. -- Tel +1 716 737-3463 -- http://www.husted.com/struts/ Tim W Wilson wrote: > > Is there anything wrong with having a given ActionServlet save itself in > the request at process() time and then have all attributes that are > currently accessed through application scope can instead be accessed > through the servlet that has been saved in the request? That way all > components are using the public interface of ActionServlet to get at its > attributes (findForward(), findMapping(), etc). Then: > 1) A given servlet is marked as "primary" or not. Default is to be > primary. For compatibility the primary servlet is exposed using the same > application scope attributes. Primary servlet also saves itself into the > context at some static key (Action.CONTROLLER_KEY) > 2) RequestUtil has one public method - getController(PageContext) added. > This returns the current controller in the request and if not found returns > the one in the application scope. > 3) Components that need access to the action servlet (like taglibs) and > have not had it passed use the above method to get the appropriate > instance. > 4) Could choose to deprecate application scope access. > > This seems very simple, and is compatible with current deployments. > > Tim W Wilson > Eclipse WSED Architecture & Development > internet: [EMAIL PROTECTED] > (919) 254-0029 (TL 444-0029) > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
