jsf and servlets

[Johan Rignas]

Hi! Which is the most correct way to use servlets?
I am having no problem using servlets with <a href> and .js. But I cant figure out how to call it from my beans:

public String happening(){
  return "servlet";
}

Am I not supposed to use JSF and servlets? Can someone point me in the correct direction?
I would like to use Servlets to get a specific link in the url-field which I´m having hard to get with my JSF "return" method.

[Torsten Oppermann]

as far as i can tell, you are not supposed to use servlets with JSF. You only have one universal controller servlet, the facelet. Everything else you can handle with managed Beans or CDI

[Johan Rignas]

Ok. Thanks for clearing that out. But I guess there is a way to navigate with the beans that affect the url-bar/field?

For the moment all my navigation looks like this:

<commandLink value="Home" action="#{myBean.navigate}"/>

public String navigate(){  
  return "index";  
}

[Torsten Oppermann]

if you return "index", the url will be "index.xhtml". You could manipulate that behaviour in the facelets-config.xml, but there really is no need for that

[Johan Rignas]

If I return index I will end up on the "index.jsf" page. But the web-browsers address link are not changed. If you are a member of a community page you might want to be able to share the address link of your profile to friends. But it sounds like I need to use js and servlets then?

[Torsten Oppermann]

i think you can configure this behaviour in the facelets-config.xml. But i dont know how right now. Maybe someone else can help ?

Try to google if you can config in that file

[Oli Wurster]

I don't know if you can configure this behaviour system wide. But you can append "?faces-redirect=true" to a link, then the location (url) is updated.

Please see some more info here

Have fun,
Oli

[Tim Holloway]

Torsten Oppermann wrote:as far as i can tell, you are not supposed to use servlets with JSF. You only have one universal controller servlet, the facelet. Everything else you can handle with managed Beans or CDI

Nope. Not so. JSF is not a greedy all-or-nothing framework. A webapp can have JSF, raw JSPs, servlets, and even Struts code in it. If a request is a JSF request, it's routed to the JSF main Controller (FacesServlet), and if not, it's routed to whatever JSP or servlet is configured to receive it. JSF is built on the same object types as regular J2EE, so JSF code and non-JSF code can cheerfully chatter back and forth all day long.

People need to understand that JSF is primarily about forms and HTML. Too many people try and force JSF to output PDFs and Excel spreadsheets, and that's just wrong. It's the "small-child-with-hammer" syndrome where every problem looks like a nail. Servlets are a much better fit for stuff like that.

I can see from the questions in this thread, however, that there's some confusion about how to get to/from servlets from JSF code. Allow me to explain.

A JSF action method returns a navigation token (alternatively in JSF2 a relative URL) that's designed to allow it to cause a new JSF View to be presented. So what if you want a Servlet, instead?

Well, first of all, the navigation is for the outgoing display! And the servlet would be an ingoing request. So that kind of rules out using JSF navigation anyway. The exception to that is in cases where you are actually doing a JSF internal forward to a servlet, but that's not necessarily what you want to do anyway in most cases.

The key is in understanding that there are 2 different types of actions that can be coded on a JSF View. The commandLink and commandButton elements fire a JSF action, which initiates a JSF form postback. Meaning that JSF backing beans will be updated and action logic will be invoked. But there's also a non-JSF submit, which is the h:outputLink tag.

The outputLink tag emits a non-JSF URL, adjusted to reflect the application context (which is convenient, since you can do app-relative URLs). That URL can reference anything. Servlets, JSPs, even JSF. However, since it's a link and not a command, it won't submit any form data. If you absolutely have to submit a form, use the raw HTML form and a raw HTML submit.

[Johan Rignas]

Thanks a lot for the information Tim!
I got a feeling I am making it a bit in the wrong way(all servlet guides I can find generate view inside servlet...). Am I supposed to do like this:

<h:outputLink value="servlet?id=#{myBean.object.id}">
Go to servlet
</h:outputLink>

@WebServlet(name = "TestServlet", urlPatterns = {"/servlet"})
public class TestServlet extends HttpServlet {

   protected void processRequest(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
        String id= request.getParameter("id");
        MyEntity e = myModelBean.getEntity(id);
        fillIndexViewBean(e);
        response.sendRedirect("index.jsf");
   }
}

In words: I would like to click on the link, then fill the proper bean with the values in question and then go to the page for the newly updated bean. Is this correct way to do it?

[Tim Holloway]

Technically, I think that everything's OK, there, but there are a couple of things I'd do differently.

1. "servlet" isn't the best name for a servlet. Someday you might have more than one servlet. Or switch it to a JSF View, or a JSP or something. Plus, it gives hackers a clue about the internal organization of your webapp, and there's never a good thing.

2. In the outputLink, you've coded "servlet" as a relative URL. It would be better to use a context-absolute URL. In other words,

<h:outputLink value="/servlet?id=#{myBean.object.id}">  

Note the slash. The generated HTTP will add the application's servlet context, and this way, if your JSF view is in a subdirectory, you'll still match the servlet URL properly

3. I never pass stuff in parameters if I can avoid it. It's extra network traffic and a great opportunity for hacking. Instead of having the servlet pull an ID, I'd simply have it get "myBean" directly as a session-scope object. Note that for this case, neither Request nor View scope will work. It has to be Session or Application scope.

4. Finally, I don't like redirects if I can avoid them. If the purpose is to find a database entity and do various things with it, I'd just make that a JSF function. If the processing is complex, I'd offload it into a POJO logic JavaBean, not a servlet. In particular, if all I'm doing is CRUD operations, I'd end up with a ton of redundant servlets, so all my CRUD operations are JSF-only. Servlets are what I use when I need non-HTML output like PDFs, MS-Word documents, and so forth.

[Johan Rignas]

Thanks!!!

I don't like redirects if I can avoid them. If the purpose is to find a database entity and do various things with it, I'd just make that a JSF function

The reason is that I would like it to be an valid url for the user for different places on the page(for bookmarking).

But it seems like I am having problem using my beans in the servlet. Getting NullPointerException. Any idea why?

@WebServlet(name = "TestServlet", urlPatterns = {"/testar"})
public class TestServlet extends HttpServlet implements Serializable {

    @ManagedProperty(value = "#{modelBean}")
    ModelBean modelBean;
    
    protected void processRequest(HttpServletRequest request, HttpServletResponse response)
            throws ServletException, IOException {
          
        String value = request.getParameter("action");
        modelBean.setValue(value);
    }

    public ModelBean getModelBean() {
        return modelBean;
    }

    public void setModelBean(ModelBean modelBean) {
        this.modelBean = modelBean;
    }
}

Get param works but modelBean.setValue gives me NullpointerException

[Tim Holloway]

Unfortunately, the ManagedProperty annotation only works in ManagedBeans. You're going to have to get the session object the hard way, by obtaining the session from your HTTPServletRequest object, then using the session getAttribute method to obtain the bean itself.

Even if the annotation had worked, the context was wrong. Generally, there's only one instance of a servlet class in a webapp, but multiple sessions. Servlet instance variables aren't an appropriate place to store session objects.

[Johan Rignas]

Ok, thanks. But any idea why I still get NullpointerException?
Servlet:

MyBean bean = (MyBean) request.getSession().getAttribute("myBean");
bean.setValue("new");

And my bean:

@ManagedBean(name="myBean")
@RequestScoped
public class CompletedBackBean implements Serializable {
  ...

[Tim Holloway]

You will get a NullPointerException if you attempt to retrieve it before JSF had created it for a session-scope bean, since JSF creates beans on-demand.

But in your case, the reason is that Request scope beans are destroyed at the end of the outgoing request AND you're attempting to fetch the bean from the session, not the request. Double whammy.

[Johan Rignas]

Thanks. It sounds troublesome that the beans are create on-demand. When I try to check which attributes(beans) I have in the request it seems to be none:
Servlet:

Enumeration<String> enum = request.getAttributeNames();
while(a.hasMoreElements()){
            System.out.println("atrib:"+a.nextElement());
}

Becouse all my pages contains separate request-beans I guess the request are supposed to contain something?