NullPointerException 5.5.17 Request.setAttribute(Request.java:1376)
I sent the following to the tomcat mailing list. Since it also involves struts
I thought I'd also send it on here and see if anyone has any ideas
Cheers
Adam
From: Adam Jenkins [mailto:[EMAIL PROTECTED]
Sent: Tue 19/08/2008 4:05 PM
To: [EMAIL PROTECTED]
Subject: NullPointerException 5.5.17 Request.setAttribute(Request.java:1376)
Hi All,
I'be been tearing my hair out for a couple of weeks over this one and would
appreciate any assistance anyone could give. It's a bit of a unique scenario,
so it'll take me a little while to explain:
We have a legacy struts app, forwarding to a jsf app (details of how below)
running on tomcat 5.5.17. 99.9% of the time everythign works great, but every
now and then (which in users speak translates to 'I keep on getting', hence we
can't ignore it) a NullPointerException gets thrown from
org.apache.catalina.connector.Request.setAttribute.
The flow is:
Third party application ---http redirect--- JSFBridgeFilter (will explain
later) - Struts application JSFBridge---JSF Application---Response
back to third party app.
The struts application contains proprietary logic to interface with the third
party app, so we can't get rid of it. Business wants all development internally
to be done in JSF, so we can't get rid of that.
The JSFBridgeFilter instantiates the JSF Context for later use, and wraps the
request that is used to instantiate it in a request wrapper that translates
.do context paths to .jsf context paths (otherwise all the forms submit
back to .do after coming from the struts framework. It looks like this:
public void doFilter(ServletRequest strutsRequest, ServletResponse response,
FilterChain chain) throws IOException, ServletException {
HttpServletRequest jsfRequest = new
StrutsToJsfRequestWrapper((HttpServletRequest)strutsRequest);
JSFBridge.getFacesContext(viewId, (HttpServletRequest)jsfRequest,
(HttpServletResponse)response);
chain.doFilter(strutsRequest, response);
}
...and the StrutsToJsfRequestWrapper contains only one override method (it
extends HttpServletRequestWrapper):
@Override
public String getServletPath() {
String oldPath = super.getServletPath();
String newPath = null;
int index = oldPath.lastIndexOf(.do);
if (index = 0) {
newPath = oldPath.substring(0, index + 1) + .jsf;
} else {
newPath = oldPath;
}
return newPath;
}
Now, you'll notice in the filter that the request wrapper is used to
instantiate the faces context, and the original request passed onto the struts
application. The 'getFacesContext' method implements some code from the apache
myfaces wiki that shows a way to call into the JSF framework from non jsf
artifacts:
It looks like this:
public class JSFBridge {
private abstract static class InnerFacesContext extends FacesContext {
protected static void setFacesContextAsCurrentInstance(final
FacesContext facesContext) {
FacesContext.setCurrentInstance(facesContext);
}
}
public static FacesContext getFacesContext(final String viewId, final
ServletRequest request, final ServletResponse response) {
FacesContext facesContext = FacesContext.getCurrentInstance();
if (facesContext != null) {
return facesContext;
}
return getNewFacesContext(viewId, request, response);
}
public static FacesContext getNewFacesContext(final String viewId,
final ServletRequest request, final ServletResponse response) {
FacesContext facesContext;
FacesContextFactory contextFactory = (FacesContextFactory)
FactoryFinder.getFactory(FactoryFinder.FACES_CONTEXT_FACTORY);
LifecycleFactory lifecycleFactory = (LifecycleFactory)
FactoryFinder.getFactory(FactoryFinder.LIFECYCLE_FACTORY);
Lifecycle lifecycle =
lifecycleFactory.getLifecycle(LifecycleFactory.DEFAULT_LIFECYCLE);
facesContext =
contextFactory.getFacesContext(((HttpServletRequest)request).getSession().getServletContext(),request,
response, lifecycle);
InnerFacesContext.setFacesContextAsCurrentInstance(facesContext);
UIViewRoot view =
facesContext.getApplication().getViewHandler().createView(facesContext, viewId);
facesContext.setViewRoot(view);
return facesContext;
}
}
And the final piece of the puzzle is a struts action that actually loads the
context and forwards to the appropriate JSF method...which looks like this:
public class ForwardToJSFAction extends Action {
public ActionForward execute(ActionMapping mapping, ActionForm form,
HttpServletRequest request, HttpServletResponse response) throws Exception {
JSFMapping
direction of effort request please?
Hi Guys, I'm having some issues with html:errors/ (I've attached my previous
mail below) that I'm going to write a custom tag to get around. I was
thinking that if it's a bug, my effort is probably more productively used
fixing the bug than rewriting the functionality, but first I need to know if
it is a bug or not. Can anyone help me out (feel free to email me directly
for more information)?
Cheers
Adam
previous email
Hi Guys,
I'm trying to come to terms with html:errors/...it's working ok, I'm using
the following for prefixes etc:
#error formatting information
errors.header=font color=redcenterpSome errors occured validating the
form. Please correct the following errors and try again./p/centerul
errors.footer=/ul/font
errors.prefix=li
errors.suffix=/li
Which is working great when there are form validation errors, however, to get
to the page that has the form, I use a global exception redirect as such:
exception
key=mysite.globalerrors.database_config
path=/private/install/ConfigDB.jsp
scope=request
type=com.mysite.utils.DBMissingConfigDataException/
And a tostring on org.apache.struts.action.ERROR =
{mysite.globalerrors.database_config=[mysite.globalerrors.database_config[The
site is not configured correctly: Required database configuration data was
missing.]]}
Now this is all well and good, except my html:errors/ tag now prints out the
header, and footer with one prefix and suffix in between (and no error
message) when the page first loads (from the error redirect). When there is
form validation errors everything works fine, however it's just that initial
redirect where everything goes haywire.
Does anyone know what's going on and/or how to fix?
Cheers
adam
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: direction of effort request please?
Hi Eddie, Thanks for your response. I understand what you're saying about the redirect, however my primary confusion comes from the fact that html:errors/ is printing out the error.header error.prefix error.suffix error.footer sequence without any error messages (in the case of the exception redirect). My problem is not with the error based redirect, it's with the fact that html:errors/ tag doesn't seem to know how it want's to handle it. I have interrogated the org.apache.struts.action.ERROR object and can see that the redirect error is included (with the appropriate messages). And the fact that the error header, prefix, suffix and footer gets printed would indicate that the html:errors/ tag is identifying an error exists also. But the actual error message (which has been validated as existing on the org.apache.struts.action.Error object) _only_ gets printed out for validation errors (not the global redirect one). So it seems there is a conflict of functional requirements. Either a global error message is printed through the html:errors tag, or it's not (in which case the header information also shouldn't be). Does that make sense or am I completely off base? So my main drive was to pick one or the other of these two paradigms...to either modify html:errors/ so that it doesn't recognise the global errors, or to modify it so that when it does, it actually prints the message...unless I'm missing something and there's a third strategy? On Thu, 3 Mar 2005 09:13 pm, Eddie Bush wrote: Errors get saved in the request. Redirecting gives you a new request - thus you have no errors. Personally, I think it might be nice if these were saved in the session, but there has been (as I recall) quite some effort not to have to sessions as some folks don't like using them. They're the only thing you have server-side to provide continuity across requests though. I tend to catch exceptions in my action and let them clue me in on what errors I need to add. The redirect is your exact problem. Do something to stop the redirect and you'll stop your problem. HTH, Eddie On Thu, 3 Mar 2005 18:39:39 +1100, Adam Jenkins [EMAIL PROTECTED] wrote: previous email snip / form validation errors everything works fine, however it's just that initial redirect where everything goes haywire. Does anyone know what's going on and/or how to fix? Cheers adam - 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]
Re: direction of effort request please?
Thanks Joe, I thought it might be a bug, however I wanted more confirmation
before logging it. I'll log it in bugzilla.
Cheers
Adam
On Thu, 3 Mar 2005 09:18 pm, Joe Germuska wrote:
At 4:13 AM -0600 3/3/05, Eddie Bush wrote:
The redirect is your exact problem. Do something to stop the redirect
and you'll stop your problem.
Still, if there are no errors to display, then the headers shouldn't
display either. I have to run, so I may have scanned this too
superficially, but before Eddie's message came in, I had written the
below:
At 6:39 PM +1100 3/3/05, Adam Jenkins wrote:
Hi Guys, I'm having some issues with html:errors/ (I've attached my
previous mail below) that I'm going to write a custom tag to get around.
I was thinking that if it's a bug, my effort is probably more
productively used fixing the bug than rewriting the functionality, but
first I need to know if it is a bug or not. Can anyone help me out (feel
free to email me directly for more information)?
This sounds like a bug to me. Since html:errors is still
supported, a Bugzilla post would be appropriate and patches would be
quite welcome! For expediency, you might also look at using
logic:messagesPresent and html:messages together as an
alternative route to achieve the same results.
Below is a logical equivalent to html:errors Normally when one
uses html:messages, you wouldn't put the header/footer/etc in the
message resources but would just put them directly into the page, but
this should be a drop in replacement since you already have that
content in the message resources.
logic:messagesPresent
bean:message key=errors.header /
html:messages id=msg
bean:message key=errors.prefix /
bean:write name=msg /
bean:message key=errors.suffix /
/html:messages
bean:message key=errors.footer /
/logic:messagesPresent
It might be instructive just to see if this behaves differently.
Joe
Cheers
Adam
previous email
Hi Guys,
I'm trying to come to terms with html:errors/...it's working ok, I'm
using the following for prefixes etc:
#error formatting information
errors.header=font color=redcenterpSome errors occured validating
the form. Please correct the following errors and try
again./p/centerul errors.footer=/ul/font
errors.prefix=li
errors.suffix=/li
Which is working great when there are form validation errors, however, to
get to the page that has the form, I use a global exception redirect as
such:
exception
key=mysite.globalerrors.database_config
path=/private/install/ConfigDB.jsp
scope=request
type=com.mysite.utils.DBMissingConfigDataException/
And a tostring on org.apache.struts.action.ERROR =
{mysite.globalerrors.database_config=[mysite.globalerrors.database_config[
The site is not configured correctly: Required database configuration data
was missing.]]}
Now this is all well and good, except my html:errors/ tag now prints out
the header, and footer with one prefix and suffix in between (and no
error message) when the page first loads (from the error redirect). When
there is form validation errors everything works fine, however it's just
that initial redirect where everything goes haywire.
Does anyone know what's going on and/or how to fix?
Cheers
adam
-
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]
Re: direction of effort request please?
Yep, and it's loaded ok as you can see it in the toString on the errors
object:
And a tostring on org.apache.struts.action.ERROR =
{mysite.globalerrors.database_config=[mysite.globalerrors.database_config[T
h e
site is not configured correctly: Required database configuration data was
missing.]]}
On Fri, 4 Mar 2005 12:16 am, Niall Pemberton wrote:
Does the mysite.globalerrors.database_config key exist in your
application resources?
Niall
- Original Message -
From: Adam Jenkins [EMAIL PROTECTED]
To: dev@struts.apache.org; user@struts.apache.org
Sent: Thursday, March 03, 2005 7:39 AM
Subject: direction of effort request please?
Hi Guys, I'm having some issues with html:errors/ (I've attached my
previous
mail below) that I'm going to write a custom tag to get around. I was
thinking that if it's a bug, my effort is probably more productively used
fixing the bug than rewriting the functionality, but first I need to know
if it is a bug or not. Can anyone help me out (feel free to email me
directly for more information)?
Cheers
Adam
previous email
Hi Guys,
I'm trying to come to terms with html:errors/...it's working ok, I'm
using the following for prefixes etc:
#error formatting information
errors.header=font color=redcenterpSome errors occured validating
the
form. Please correct the following errors and try again./p/centerul
errors.footer=/ul/font
errors.prefix=li
errors.suffix=/li
Which is working great when there are form validation errors, however, to
get
to the page that has the form, I use a global exception redirect as such:
exception
key=mysite.globalerrors.database_config
path=/private/install/ConfigDB.jsp
scope=request
type=com.mysite.utils.DBMissingConfigDataException/
And a tostring on org.apache.struts.action.ERROR =
{mysite.globalerrors.database_config=[mysite.globalerrors.database_config[T
h e
site is not configured correctly: Required database configuration data was
missing.]]}
Now this is all well and good, except my html:errors/ tag now prints out
the
header, and footer with one prefix and suffix in between (and no error
message) when the page first loads (from the error redirect). When there is
form validation errors everything works fine, however it's just that
initial redirect where everything goes haywire.
Does anyone know what's going on and/or how to fix?
Cheers
adam
-
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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Excluding global errors from html:errors
Hi Guys,
I'm trying to come to terms with html:errors/...it's working ok, I'm using
the following for prefixes etc:
#error formatting information
errors.header=font color=redcenterpSome errors occured validating the
form. Please correct the following errors and try again./p/centerul
errors.footer=/ul/font
errors.prefix=li
errors.suffix=/li
Which is working great when there are form validation errors, however, to get
to the page that has the form, I use a global exception redirect as such:
exception
key=mysite.globalerrors.database_config
path=/private/install/ConfigDB.jsp
scope=request
type=com.mysite.utils.DBMissingConfigDataException/
And a tostring on org.apache.struts.action.ERROR =
{mysite.globalerrors.database_config=[mysite.globalerrors.database_config[The
site is not configured correctly: Required database configuration data was
missing.]]}
Now this is all well and good, except my html:errors/ tag now prints out the
header, and footer with one prefix and suffix in between (and no error
message) when the page first loads (from the error redirect). When there is
form validation errors everything works fine, however it's just that initial
redirect where everything goes haywire.
Does anyone know what's going on and/or how to fix?
Cheers
adam
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Iterate over validation errors?
Hi All, Is there a simple way to iterate over all the validation errors. I don't want to just do html:errors/ I want to actually for a ulli.../li/ul of all the errors that occured when submitting the page. Is this possible? Does anyone have an example I could use? Cheers Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Iterate over validation errors?
Thanks for that, I'll give it a go. Is there anyway you can accomplish
it without having to put html in the resource bundle?
On Sun, 2005-02-27 at 19:04 -0500, Erik Weber wrote:
Last I checked, Struts came configured to do what I think you are asking
by default.
This is an example of the (Struts 1.1) ApplicationResources.properties file:
#header and footer for form validation error messages
errors.header=table width=100% border=0 cellspacing=0
cellpadding=0tr align=lefttdstrongfont color=redinput
error/font/strong/td/trtrtdnbsp;/td/trtr
align=lefttdPlease resubmit the form after correcting your input to
meet the following requirement(s):ul
errors.footer=/ul/td/trtrtdnbsp;/td/tr/table
#form validation error messages
#(rendered between header and footer above)
errors.required=li{0} is required./li
errors.minlength=li{0} cannot contain fewer than {1} characters./li
errors.maxlength=li{0} cannot contain more than {2} characters./li
errors.invalid=li{0} is invalid./li
errors.byte=li{0} must be an byte./li
errors.short=li{0} must be an short./li
errors.integer=li{0} must be an integer./li
errors.long=li{0} must be an long./li
errors.float=li{0} must be an float./li
errors.double=li{0} must be an double./li
errors.date=li{0} is not a date./li
errors.range=li{0} is not in the range {1} through {2}./li
errors.creditcard=li{0} is not a valid credit card number./li
errors.email=li{0} is invalid./li
#user plugins
errors.twofields=li{0} must have the same value as {1}./li
errors.dateRange=li{0} is not an acceptable date./li
Then a simple html:errors/ results in the bulleted list of all current
validation errors, assuming your validation.xml is set up properly so
that errors are matched with the messages in the properties file.
Hope this helps.
Erik
Adam Jenkins wrote:
Hi All,
Is there a simple way to iterate over all the validation errors. I
don't want to just do html:errors/ I want to actually for a
ulli.../li/ul of all the errors that occured when submitting the
page.
Is this possible? Does anyone have an example I could use?
Cheers
Adam
-
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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
