What do you need to access? Can't you find your services, etc during the intercept() call? Interceptors are supposed to be stateless.
Your param values that get set on the Interceptor instance have to be Strings, as they're coming from the XML, but they can use the type conversion used elsewhere in Xwork, if I'm not mistaken. I'm already planning on making Object instantiation pluggable in Xwork for most everything, including Interceptors, Results, etc... This will allow for Spring or Pico enabled Interceptors, etc. It is definitely a mistake to assume any cardinality of instances of Interceptor classes. Just because it's implemented one way now doesn't guarantee that they'll be instantiated that way in Xwork 1.1... The main contract of Interceptors is that: A) init() will be called on them before intercept() B) Interceptors should be stateless and thread safe, since multiple intercept() calls could be going through at the same time C) destroy() will be called if the application is shut down cleanly Tell me what you're trying to accomplish and lets figure out the best way Jason > -----Original Message----- > From: Frederick N. Brier [mailto:[EMAIL PROTECTED] > Sent: Wednesday, January 28, 2004 12:15 AM > To: [EMAIL PROTECTED] > Subject: [OS-webwork] XWork interceptor init() parameter > > > In implementing a new Interceptor, I noticed that the init() > method is > not passed any sort of configuration or context parameter. This has > been fine for the 2 other interceptors I have written, but there is a > limit to how much initialization you can do with no parameters. The > <interceptor> and <interceptor-ref> elements do have <param> > elements, > but their values can only be strings. Is there a way for the > interceptor's init() method to access application level components > (defined in components.xml) or elements like the ServletContext? > Specifically, I want to make some metadata available to the > interceptor. I was thinking that an application level > component would > be a good place to load and cache it. > > 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 > ------------------------------------------------------- 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
