We Keep Coding

EJB3 Interceptor- Setting attributes and reading them on JSP

In an enterprise application, I'm trying to set some attributes in an EJB3 interceptor and then show them on a jsp. Is it possible? How can I achieve that? The use case is as follows- Some values are read from the database which are required to be shown on the error page. This error page is the default error page, no controller for it. I couldn't find anything in the code regarding this error page, nothing in web.xml. Need a solution for this asap.

I couldn't find a way to use an interceptor. I ended up using a filter, which was already there in the application. I set an application scope variable map in the init method of the Filter. That ways, I had to get and set the values only once, i.e., at the server startup. Then I used this map in the JSP to read the values. Like, ${applicationScope.appParams.someKey}.

getRequestDispatcher() is returning null (Portlet)

I am working on a Java Portlet (extending GenericPortlet), using JBoss 7.02 and LifeRay Portal 6.1.0 GA1. This is one of the bundles that can be downloaded from LifeRay's release archive.
During deployment, when the init() method is called, getRequestDispatcher() returns null. Below is the exact error message:
09:22:15,972 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/my-portlet-name]] (MSC service thread 1-15) Error during mapping: java.lang.NullPointerException
Below is a snippet from my init() method:
PortletConfig config = getPortletConfig();
PortletContext context = getPortletContext();
PortletRequestDispatcher normalView = context.getRequestDispatcher("/portlet.jsp");
As a temporary workaround, I have moved all getRequestDispatcher() calls to doView() where it executes without problem. I do not understand why getRequestDispatcher() can locate portlet.jsp when called during doView, but not when its called during init()
Am I missing a preceding call of some other method that would resolve this? Is this a known issue?
Thanks for any help.

Getting the request dispatcher in the doView is the only place I've seen it done. I would imagine that it returns null during init because there is no actual request to dispatch.
Typically the init method is used for time-expensive operations that you don't want to incur for each request. This might be something like reading data from a file, or creating a reusable SQL connection.
You should also keep in mind that you should keep any portlet state thread safe. Don't create class or object variables that can only be used for one request at a time. The portlet methods are not inhererently thread safe, so you need to make sure that whatever variables a request is interacting with won't be manipulated by another request that is executing concurrently.

I'm not familiar with Portlets, but the answer should be the same as for Servlets.
The init() method is called exactly once, when your application is initially deployed. There is no active request (no one is asking for anything) or response (no one is going to read what the output is). Therefore, it is very reasonable forgetRequestDispatcher() to return null. In doView(), when you're handling a request and response, it makes sense to ask another resource to generate part (or all) of the response.
To address your question directly, getRequestDispatcher() has no problem locating portlet.jsp from init(); it's the request that's missing. (Where do you expect to see the result of portlet.jsp, anyway?)
If you do want to print some output during initialization, you can try logging it to a file, if your application is set up for that. Or, you can display data on System.out, if you know where the container's console is. (I use this second option quite often with servlets.)

ServletRequest.getRequestDispatcher() for non-existent files/resources

Currently I'm preparing for Java EE Web Component Developer exam.
In both exam study guide and Servlet API Java docs I found that method
ServletRequest.getRequestDispatcher()
returns
null if the servlet container cannot return a RequestDispatcher.
When I tried it with non-existent static file I actually got non-null value. And forward resulted in 404 sent to client. Same effect for non-existent servlet. I use Apache Tomcat 7.0.
Does it mean that this behaviour isn't defined and is left to implementer's choice? What do they (Java docs authors) mean by "servlet container cannot return a RequestDispatcher"? I tried to look for it in JSR spec but wasn't able to find answer.

This is what the Servlet 3.0 specification has to say about dispatcher behavior:
The getRequestDispatcher method takes a String argument describing a
path within the scope of the ServletContext. This path must be
relative to the root of the ServletContext and begin with a ‘/’, or
be empty. The method uses the path to look up a servlet, using the
servlet path matching rules in Chapter 12, “Mapping Requests to
Servlets”, wraps it with a RequestDispatcher object, and returns the
resulting object. If no servlet can be resolved based on the given
path, a RequestDispatcher is provided that returns the content for
that path.
Nowhere does it mentioning returning null if a matching servlet cannot be found for the dispatch path. Instead it states that the 'content' found at the dispatch path will be found, which I translate as meaning an implementation can simply allow the container to absolutely resolve the path (which in your scenario yields a 404).
As far as the Javadoc though, it seems documented with the broadest use case possible, aka, if the container cannot create a dispatcher for any reason then it will return a null object (as opposed to throwing an exception). This may be due to a technical problem in the implementation, or may be actually valid (e.g JAX-RS implementations can access some level of the Servlet infrastructure, but cannot use the servlet context or dispatcher).

RESTEasy hides real exception

My code is throwing an exception (due to a bug). In the log, I see:
org.jboss.resteasy.spi.UnhandledException: java.lang.NullPointerException
at org.jboss.resteasy.core.SynchronousDispatcher.handleApplicationException(SynchronousDispatcher.java:323)
at org.jboss.resteasy.core.SynchronousDispatcher.handleException(SynchronousDispatcher.java:199)
at org.jboss.resteasy.core.SynchronousDispatcher.handleInvokerException(SynchronousDispatcher.java:175)
at org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:529)
etc...
The stack of the actual exception is not logged. If I wrap my code in a try..catch and log the caught exception I can verify that my code is at fault. No other library in my system does this, even for deeply-wrapped exceptions, so it must be a problem in RESTEasy, perhaps in UnhandledException?
Is there a way to get around this behavior? I can't think of a good reason why it should be hiding the actual exception.
Jetty
Java
Spring 3.0.3
RESTEasy 2.0.1GA

Do you have an ExceptionMapper? See Chapter 27, Exception Handling, in the RESTEasy documentation.
I used RESTEasy to add REST to an existing system, and the existing system has a weird way of wrapping exceptions within exceptions, so my ExceptionMappers do a lot of unwrapping.
Throwable t = exception;
while (t.getCause() != null) {
t = t.getCause();
}
t.printStackTrace();

I don't use RESTeasy, but it appears to be a dispatch mechanism for RESTful web services.
Assuming this is the case, then it has different design goals from other libraries: they are invoked from your application, but RESTeasy is responsible for invoking your application. It therefore has to protect itself from poorly written code. A "last ditch" exception handler is a common way to do this; you'll see the same thing in Swing.
Whether or not it should log the uncaught exceptions is a different matter. Perhaps there's a configuration option to do this. Or perhaps you need to add a couple lines of code. It is open-source, after all, and I'm sure the maintainers would appreciate a well-written bug report with patch.

Yes, your exception is swallowed by RESTeasy, wrapped in UnhandledException and logged. But your exception lies too deep within to be included in the stacktracs.
To print out your exception to the console, you could append the following to 'WEB-INF/classes/logging.properties'
org.apache.catalina.core.ContainerBase.[Catalina].level = FINEST
org.apache.catalina.core.ContainerBase.[Catalina].handlers = java.util.logging.ConsoleHandler

Java exception problem

I got this exception in time of running a web application in java. What does this mean?
exception.name = javax.servlet.ServletException: BeanUtils.populate

I guess you are using something which utilizes Jakarta BeanUtils (like Struts) and some method is throwing an exception.
Following may be reasons for same :
The action attribute of an tag must
match exactly the path attribute of
the action definition in the
struts-config.xml file. This is how
Struts associates the ActionForm
bean with the action.
This error usually occurs when you
have specified a form name that does
not exist in your tag. For example,
you specifiec and 'myForm' is not
the name of a form associated with
myAction in the struts-config file
You get this message when Struts is
unable to map the data in the HTML
form to the properties in your
ActionForm bean. Make sure each of
the properties on your bean is
either a String or a boolean. Do you
have any properties of type
java.util.Date or other objects?
That might cause this error. Also
check to see that you have public
getters and setter for each of your
properties.
Check:
http://www.coderanch.com/t/53114/Struts/ServletException-BeanUtils-populate
http://forums.sun.com/thread.jspa?threadID=632599
http://javaexceptions1.blogspot.com/2009/08/javaxservletservletexception.html

A short call to google's famous www-indexer (with:"ServletException: BeanUtils.populate") provided this result:
ServletException BeanUtils populate
The answer to that question over there at coderanch could help to solve your problem

Since this is a Struts related exception (and seeing that we don't know the cause of the exception), here are some possible reasons why you're getting the exception.
No Bean Specified. This means that there is no ActionForm defined in your Action.
Your bean properties you're copying from doesn't match the bean properties you're matching to.
Unless we know the cause of the exception, you'll just have to debug your code and see what is the fault.