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 view this discussion on the web visit 
https://groups.google.com/d/msg/google-web-toolkit/-/2m9y2JopvAYJ.
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.

Reply via email to