Thanks, Thomas, I searched through the methods in ServiceLayerDecorator for something like this, but somehow missed these.
Using report() from with the ServiceLayerDecorator doesn't allow me to re-fire the RequestFactory request, giving me the "A request is already in progress" error. If I call die() then the exception is still printed out, but the onFailure method of the Receiver is in fact called, and I can re-fire the request. Ryan On Jun 7, 3:06 pm, Thomas Broyer <t.bro...@gmail.com> wrote: > If you go the ServiceLayerDecorator route, you can no longer use an HTTP > status detected by a custom RequestTransport, you're pluggin *into* the RF > protocol, not *around* it. > Try using the die() or report() methods from ServiceLayerDecorator and see > how they behave. > > > > On Thursday, June 7, 2012 8:30:35 PM UTC+2, Ryan McFall wrote: > > > I'm well on my way to getting this to work. I can determine whether > > the method to be invoked requires authentication, and whether or not > > the user is currently authenticated. > > > Currently, what I've done is defined a new runtime exception and > > thrown that exception in my ServiceLayerDecorator if an > > unauthenticated user tries to invoke a method requiring > > authentication. I've then overridden doPost in my sub-class of > > RequestFactoryServlet to catch this exception and set the status code > > of the response to be 401. > > > Unfortunately, this doesn't quite work. I get the following in my > > server console when this exception is thrown by my code: > > > SEVERE: Unexpected error > > edu.hope.cs.surveys.editor.server.SessionExpiredException: Session > > expired > > at > > edu.hope.cs.surveys.editor.server.ActiveSessionDecorator.invoke(ActiveSessionDecorator.java: > > > 17) > > at > > com.google.web.bindery.requestfactory.server.ServiceLayerDecorator.invoke(ServiceLayerDecorator.java: > > > 111) > > at > > com.google.web.bindery.requestfactory.server.SimpleRequestProcessor.processInvocationMessages(SimpleRequestProcessor.java: > > > 455) > > at > > com.google.web.bindery.requestfactory.server.SimpleRequestProcessor.process(SimpleRequestProcessor.java: > > > 225) > > at > > com.google.web.bindery.requestfactory.server.SimpleRequestProcessor.process(SimpleRequestProcessor.java: > > > 127) > > at > > com.google.web.bindery.requestfactory.server.RequestFactoryServlet.doPost(RequestFactoryServlet.java: > > > 133) > > at > > edu.hope.cs.surveys.editor.server.JandyRequestFactoryServlet.doPost(JandyRequestFactoryServlet.java: > > > 28) > > > I see that SimpleRequestProcessor has a setExceptionHandler method > > which is responsible for creating a ServerFailure object. Do I need > > to provide a custom exception handler to the RequestProcessor? Or is > > there some other way of catching the failure caused by the invoke > > method of my ServiceLayerDecorator? > > > Thanks, > > Ryan > > > On Jun 5, 11:13 am, Ashwin Desikan <ashwin.desi...@gmail.com> wrote: > > > Thomas is correct. I had tried the route of creating two separate RF's. > > But that involves more work in comparison to annotations. In fact I changed > > my approach post Thomas suggestion in this forum quite sometime bac > > > > ~Ashwin > > > > Sent from my iPhone > > > > On Jun 5, 2012, at 7:38 PM, Thomas Broyer <t.bro...@gmail.com> wrote: > > > > > On Tuesday, June 5, 2012 3:58:22 PM UTC+2, Ryan McFall wrote: > > > > After I wrote my original follow-up to Thomas' message, I thought of > > > > having different services - one for methods that require > > > > authentication, and one for those that don't. Then I can map my > > > > ServletFilter to the URL for the service that requires authentication, > > > > and not map it to those that don't. > > > > > That seems easier to me than the annotation route. Anyone have any > > > > reasons to think otherwise? > > > > > It won't work. RequestFactoryServlet loads from the classpath, so > > unless you somehow constrain the classpath of each servlet to only contain > > the classes you want to expose, the unauthenticated servlet would be able > > to load the "services requiring authentication", therefore allowing > > unauthenticated access to them. > > > > In other words, that's not how RF has been designed. > > > > -- > > > > You received this message because you are subscribed to the Google > > Groups "Google Web Toolkit" group. > > > > To view this discussion on the web visithttps:// > > groups.google.com/d/msg/google-web-toolkit/-/fl0PLdvGKHUJ. > > > > To post to this group, send email to > > google-web-toolkit@googlegroups.com. > > > > To unsubscribe from this group, send email to > > google-web-toolkit+unsubscr...@googlegroups.com. > > > > For more options, visit this group athttp:// > > groups.google.com/group/google-web-toolkit?hl=en. -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
