Paulo Hélio Alves wrote:
>
>
Sorry for response so late...
>
> Well, i'm using Stripes 1.4.3, Stripes Security 1.4.2, Java 6.
> In JSP, i use something like this:
>
> i use an interceptor before fillLookupFields for doing this:
>
@Intercepts(LifecycleStage.ResolutionExecution)
> public class MyInterceptor implements Interceptor {
> public Resolution intercept(ExecutionContext ctx) throws Exception {
> HttpServletRequest httpRequest =
> ctx.getActionBeanContext().getRequest();
> log.info(httpRequest.getUserPrincipal().getName());
> log.info(httpRequest.getRequestURI());
> return ctx.proceed();
> }
> }
> this is my problem... but is we take off the stripes:file tag, the code
> works fine...
> So, can you Help me,please...
>
I believe you may be affected by a bug in the 1.4.3 version of the
StripesFilter code and the way requests are handled (wrapped). Out of
curiosity, what happens when you comment-out the following lines:
public Resolution intercept(ExecutionContext ctx) throws Exception {
// Don't touch context
// HttpServletRequest httpRequest =
ctx.getActionBeanContext().getRequest();
// log.info(httpRequest.getUserPrincipal().getName());
// log.info(httpRequest.getRequestURI());
return ctx.proceed();
}
Also, please post your StripesFilter init() method. If you're using the
StripesSecurityFilter that's floating around with 1.4.3 and you do anything
to the context you have to use a custom wrapper like so:
StripesRequestWrapper wrapper = new StripesRequestWrapper(request) {
@Override
protected void constructMultipartWrapper(HttpServletRequest request)
throws StripesServletException {
Locale locale =
StripesFilter.getConfiguration().getLocalePicker().pickLocale(request);
setLocale(locale);
}
};
final ActionBeanContext context =
StripesFilter.getConfiguration().getActionBeanContextFactory().getContextInstance(wrapper,
response);
// now you can play with the context
return new RedirectResolution("/").execute(wrapper, response);
If you don't, you get the annoying "request wasn't wrapped" Stripes warning.
This has been fixed in 1.5.
I should also point out, just 'cause I only realized this recently myself,
that extending the StripesFilter like the StripesSecurityFilter does is
probably not the best way to go about implementing a security manager. Most
of the stuff is great--don't get me wrong--but creating your own
StripesFilter instance could lead to thread issues if you've got more than
one website using the different configurations. The cleaner way to do it is
to put the security manager (and whatever else) into a custom configuration
which is then stored safely in ThreadLocal. The Stripes folks were even
forward-thinking enough to provide a hook in the web.xml:
Configuration.class.
--
View this message in context:
http://www.nabble.com/File-Upload%2C-throw-null-pointer-because-destroy-context.-tp16420285p16544565.html
Sent from the stripes-users mailing list archive at Nabble.com.
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Register now and save $200. Hurry, offer ends at 11:59 p.m.,
Monday, April 7! Use priority code J8TLD2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
