Sorry, I should have included my code. Here's the interceptor setup: <service-point id="ApplicationStateFlushingInterceptor" interface="org.apache.hivemind.ServiceInterceptorFactory"> <invoke-factory model="threaded"> <construct class="com.db.csa.tapestry.core.ApplicationStateFlushingInterceptorFactory"> <set-object property="stateManager" value="infrastructure:applicationStateManager"/> </construct> </invoke-factory> </service-point>
<implementation service-id="tapestry.globals.WebRequest"> <interceptor service-id="ApplicationStateFlushingInterceptor"/> </implementation> I've also overriden the response renderer using InfrastructureOverrides but that shouldn't make any different. My Factory is below: public class ApplicationStateFlushingInterceptorFactory implements ServiceInterceptorFactory { private ApplicationStateManager stateManager; public void setStateManager(ApplicationStateManager stateManager) { this.stateManager = stateManager; } public void createInterceptor(InterceptorStack stack, Module invokingModule, List parameters) { InvocationHandler handler = new ApplicationStateFlushingInvocationHandler(stateManager, stack.peek()); Object interceptor = Proxy.newProxyInstance( invokingModule.getClassResolver().getClassLoader(), new Class[] { stack.getServiceInterface()}, handler); stack.push(interceptor); } } And my InvocationHandler: public class ApplicationStateFlushingInvocationHandler implements InvocationHandler { private final Object delegate; private final ApplicationStateManager stateManager; public ApplicationStateFlushingInvocationHandler(ApplicationStateManager stateManager, Object delegate){ this.delegate = delegate; this.stateManager = stateManager; } public Object invoke(Object proxy, Method method, Object[] args) throws Throwable { if (method.getName().equals("forward")){ stateManager.flush(); } return method.invoke(delegate, args); } } Rob Cole "James Carman" <[EMAIL PROTECTED]> 31/08/2006 13:23 To "'Tapestry users'" <users@tapestry.apache.org> cc Please respond to "Tapestry users" <users@tapestry.apache.org> Subject RE: Auto-wiring in AssetService shouldn't be auto-wired? You can't use an interceptor to inject dependencies reliably. Just adding an interceptor to a service shouldn't prohibit it from being autowired properly or make it stop working. Are you sure you've added your interceptor properly? Did you write your own interceptor factory to do it? -----Original Message----- From: Robert Cole [mailto:[EMAIL PROTECTED] Sent: Thursday, August 31, 2006 6:47 AM To: users@tapestry.apache.org Subject: Auto-wiring in AssetService shouldn't be auto-wired? Hi all I'm hitting an issue that is really, really starting to get my goat. The AssetService service appears to have the WebRequest object auto-wired into it via Hivemind. This is a little odd as all of the other dependencies are wired in normally via the Hivemind mapping. I'm sure its just an oversite by whoever wired up the AssetService in Tapestry but its now causing me problems. Normally this wouldn't be a problem but I'm trying to get around my cookie writing problem (previously posted), the last bit of it is that WebRequest.forward doesn't flush the applications state when it sends a redirect to the client (possibly a bug?). To get around this I've written an Interceptor that intercepts calls to the WebRequest.forward method and uses the ApplicationStateManger.flush to write out the application state. All fine so far. Unfortnately this somehow stops the auto-wiring from wiring the WebRequest into the AssetService so I now get lots of NullPointerExceptions in AssetService. I'm thinking that the auto-wiring of WebRequest into AssetService shouldn't be happening (so another bug?) but is there a way around it for the moment? I could write another interceptor for the AsserService to inject the WebRequest into it but then I could hit the problem in another location for another service and end up having interceptors all over the place. Is there a better solution? Thanks, Rob Cole --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. --------------------------------------------------------------------- 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] --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]