If there is no existing method of access, xwork might benefit from having an XworkConfig/Context or ActionConfig (more advantages and it could have a reference to XworkConfig) passed to the init() method similar to the Java servlet API. A context prevents me from having to use singletons, JNDI, or other container based mechanism to find services. The approach is also familiar to web developers.
Not being able to initialize during init() means using lazy initialization in the intercept() method, where we access to actionInvocation and a populated ActionContext, but it must occur in a synchronized section of code because the List of interceptors are shallow array copies for each invocation. The interceptor is the same instance.
An XworkConfig could hold property values, which webwork could add to. It would have a reference to an XWorkContext which again like the ServletContext contains a map of attributes. One of the attributes webwork could install is a reference to the ServletContext.
However, the main goal of this is to have a place where the interceptor's init() method could access application level components at a point in time where synchronization is not necessary. I would like to see those components get initialized first, and then have the interceptors initialized. components.xml provides the extensibility to add new objects to the XworkContext. What do you think?
Other thought on Interceptors:
------------------------------
xwork.xml: Correct me if I am wrong, but if an Interceptor is declared as part of a stack, wherever the stack is referenced, the same instance is used/shared. Whereas if the Interceptor is explicitly referenced inside an Action element, a new instance is created. So some of the instances in an ActionConfig's List of interceptors are shared, and some are not. The savings in memory are probably not worth getting bit in the butt if someone incorrectly assumes the interceptor, while shared amongst invocations of a specific Action, was not shared among all Actions.
Thank you for the help. Fred.
------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
