[prev in list] [next in list] [prev in thread] [next in thread] 

List:       tapestry-user
Subject:    RE: Auto-wiring in AssetService shouldn't be auto-wired?
From:       Robert Cole <robert.cole () db ! com>
Date:       2006-08-31 14:04:29
Message-ID: OFB7D0195D.E37646CA-ON802571DB.004D10D7-802571DB.004D50CE () db ! com
[Download RAW message or body]


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" <james@carmanconsulting.com>                                         \
  
             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:robert.cole@db.com]
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: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org




---

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: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


[prev in list] [next in list] [prev in thread] [next in thread]