0

I'm using,

  • GlassFish 4.0
  • JSF 2.2
  • Mojarra 2.2.0
  • Primefaces 3.5

I have this fileUpload component on an XHTML page.

<h:form enctype="multipart/form-data">

    <p:fileUpload id="txtCatImage" 
                  value="#{testManagedBean.uploadedFile}"
                  mode="advanced"
                  sizeLimit="100000"
                  multiple="false"
                  showButtons="true" 
                  allowTypes="/(\.|\/)(gif|jpe?g|png)$/"
                  fileUploadListener="#{testManagedBean.fileUploadListener}"/>

    <p:message for="txtCatImage" showSummary="false"/>

    <p:commandButton id="btnSubmit" 
                     actionListener="#{testManagedBean.insert}" 
                     icon="ui-icon-check" value="Save"/>
</h:form>

This is the corresponding managed bean.

@ManagedBean
@ViewScoped
public final class TestManagedBean implements Serializable {

    private UploadedFile uploadedFile;
    private static final long serialVersionUID = 1L;

    public TestManagedBean() {}

    public UploadedFile getUploadedFile() {
        return uploadedFile;
    }

    public void setUploadedFile(UploadedFile uploadedFile) {
        this.uploadedFile = uploadedFile;
    }

    public void fileUploadListener(FileUploadEvent event) {
        uploadedFile = event.getFile();
        System.out.println("fileUploadListener invoked.");
    }

    public void insert() {
        if (uploadedFile != null) {
            System.out.println(uploadedFile.getFileName());
        } else {
            System.out.println("The file object is null.");
        }
    }
}

The file upload listener as mentioned - fileUploadListener() is never invoked.

The file upload filter is mapped in web.xml as follows.

<filter>
    <filter-name>PrimeFaces FileUpload Filter</filter-name>
    <filter-class>org.primefaces.webapp.filter.FileUploadFilter</filter-class>
</filter>

<filter-mapping>
    <filter-name>PrimeFaces FileUpload Filter</filter-name>
    <servlet-name>Faces Servlet</servlet-name>
</filter-mapping>

<servlet>
    <servlet-name>Faces Servlet</servlet-name>
    <servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
    <load-on-startup>1</load-on-startup>
</servlet>

<servlet-mapping>
    <servlet-name>Faces Servlet</servlet-name>
    <url-pattern>*.jsf</url-pattern>
</servlet-mapping>

I have added Apache-commons-fileupload and Apache-commons-io to the classpath. The same thing works in my earlier project with Spring / JSF.

I can't see what I'm missing here. Does it have to do something with the version of the server?

Tiny
  • 27,221
  • 105
  • 339
  • 599
  • *I have added Apache-commons-fileupload and Apache-commons-io to the classpath.* How exactly did you do that step? There are many ways to do that, of which in turn many are plain wrong for a WAR. Have you confirmed that those JARs did end up in `/WEB-INF/lib` folder of the built/deployed WAR file? – BalusC Sep 16 '13 at 11:07
  • I have just checked them out. After deploying the application, both the jar files are present in `$Project/Project-war/build/web/WEB-INF/lib` – Tiny Sep 16 '13 at 11:42
  • Okay. What if you remove/disable all security related filters and stuff? (just to exclude them from being the cause) What if you try JSF 2.1 instead? (JSF 2.2 comes namely with its own native file upload parser, not sure how PrimeFaces 3.5 acts on that, never tried it myself). – BalusC Sep 16 '13 at 11:59
  • I have tried the same scenario as it is in the question on GlassFish 3.1.2 running on Mojarra 2.1.6, JSF 2.1 and PrimeFaces 3.5. It worked correctly as it should. – Tiny Sep 16 '13 at 12:52
  • Tried on GlassFish 4.0 by disabling the security filter and the security constraints but it didn't work. – Tiny Sep 16 '13 at 13:07
  • Well, it'll be the combination `` and JSF 2.2. Theoretically, this may indeed cause trouble like this. – BalusC Sep 16 '13 at 14:03
  • [primefaces-4.0.RC1](http://www.primefaces.org/downloads.html) has been released in which the file upload listener is invoked but on pressing `` after uploading a file, it gives this exception - `javax.faces.FacesException: javax.servlet.ServletException: The request content-type is not a multipart/form-data`, (**In case of ajax="true"**). It only worked when the ajax attribute is set to false. Maybe this feature has changed. – Tiny Sep 16 '13 at 19:49
  • The problem I have mentioned in my last comment can temporarily be solved by [this](http://stackoverflow.com/a/19381134/1391249) answer. It worked for me - files can be uploaded with AJAX submit. – Tiny Oct 25 '13 at 22:24

2 Answers2

3

It's most probably because Primefaces 4 is the only one compatible with the latest JSF standard present in Glassfish 4 (Java EE 7). Primefaces 3.5 works with Glassfish 3.1.2.2 (Java EE 6)
There were more people having this issue.
Monday 16th of September will be launched Primefaces 4.0 RC1, so you should try with that if you really want GF 4.

Edit:
Reference: Glassfish 4, JSF 2.2 and PrimeFaces FileUploadEvent not working together
The user can decide by itself if RC is good enough for him or not. I have just suggested it to him, because that's the only way at the moment.

Community
  • 1
  • 1
zmirc
  • 825
  • 2
  • 11
  • 27
  • 'Primefaces 4 is the only one compatible with the latest JSF standard present in Glassfish 4 (Java EE 7)' can you post any quotation about this fact? 'Monday 16th of September will be launched Primefaces 4.0 RC1' that's a release candidate, maybe migrating to a beta is not actually a choice for the OP. 'There were more people having this issue' the same, you need a reference here. – Aritz Sep 16 '13 at 09:03
  • The link you posted is talking about JSF 2.2 while the user says he uses 2.0. Appart from that I don't see anything related with Java EE 7 in that link. Why can't it be just a glassfish problem? – Aritz Sep 16 '13 at 09:15
  • Well...don't comment if you don't know how Java EE works. Glassfish 4 = Java EE 7 -> JSF 2.2 Glassfish 3.1.2 = Java EE 6. You can't use an older JSF version with GF4. You have to use GF 3.1.2 for the previous one, exactly as I suggested. Primefaces 3.5 is not Java EE 7 compatible. – zmirc Sep 16 '13 at 09:31
  • 'Primefaces 3.5 is not Java EE 7 compatible' I'm still waiting for a serious confirmation for this assumption, since I have used that PF version with JSF 2.2, which is the one included in Java EE 7. PF has nothing to do with Java EE, but with JSF itself. In fact, I use PF without JavaEE. And, about glassfish, as far as I know the user can change its JSF implementation isn't it? @Tiny mentions he's using JSF 2.0, don't know if he's managing it properly or not. – Aritz Sep 16 '13 at 09:46
  • You can either wait or search. https://www.facebook.com/groups/primefaces/permalink/10151467884751333/ JSF 2.2 is part of Java EE 7, so saying Primefaces 4 is Java EE 7 compatible is right. You can't use Primefaces without Java EE, because JSF is part of EE. By saying you don't use EE, you also say that you don't use JSF, which is impossible if you want Primefaces. Are you ok now? – zmirc Sep 16 '13 at 09:53
  • Whatever you use (Servlet, JSF, JSP, JPA, CDI, EJB), all of them are part of Java EE. By using at least one, it means that you use Java EE. If you use all of them or not, it doesn't matter. It's still Java EE. More details: https://java.net/projects/javaee-spec/pages/Home – zmirc Sep 16 '13 at 10:00
  • I'm not interested in arguing about this, but keep clear that JSF is part of JavaEE, as JPA, but you can keep using them SEPARATELY. JavaEE is just a standard which defines them, appart from that you have glassfish which is a full JavaEE implementation and includes everything out of the box. But yes, you can use JSF without JavaEE full implementation as Glassfish is. You can include an individual JSF implementation in single servlet container like tomcat to run it without the need of the whole JavaEE environment. That's why Primefaces ITSELF is not related with JavaEE, but with JSF. – Aritz Sep 16 '13 at 10:00
  • Yes, my friend. Did I say that you can't use them separately? I'm just saying that all of them are part of Java EE. By just touching one technology, automatically you're using Java EE. If your container supports just 1-2 or the full implementation, that's something else. I am talking just about the fact that all of them belong to Java EE. Because JSF is part of Java EE ecosystem, you can say that Primefaces is related to Java EE. Saying that PF is not related to Java EE is false, because JSF is part of EE. Do you get it? JSF belongs to EE, therefore PF is related to both JSF and EE. – zmirc Sep 16 '13 at 10:07
  • We agree in basis, just terminology concepts. However, I keep thinking your answer for this question is actually wrong and untested. Try to provide oficial references and not an unanswered,not-related question link. – Aritz Sep 16 '13 at 10:15
  • 1
    My answer is right. Take a look again here: https://www.facebook.com/groups/primefaces/permalink/10151467884751333/ . Çağatay Çivici is the creator and owner of PF. Check his reply. Because GF 4 is Java EE 7 implementation, therefore JSF 2.2, Primefaces 3.5 is not compatible with GF 4. If you still don't understand that, check this page: https://glassfish.java.net/ . It says JAVA EE 7. Are you satisfied now? – zmirc Sep 16 '13 at 10:21
  • 1
    Sorry, I accidently posted JPA version 2.0. It is JSF 2.2, Mojarra 2.2.0. – Tiny Sep 16 '13 at 11:13
  • 1
    "*Daily vote limit reached*". I can't vote today. I will however do it tomorrow. Thanks. – Tiny Oct 25 '13 at 22:28
-1

If you use Primefaces upload, you have to take care the following situation.

  1. Don't use ajax request, that mean, you have to put ajax="false" attribute in your <p:commandButton...>.Otherwise, use <h:commandButton>.
  2. If you would like to display dynamic image, the scope of the backing bean must be Session Scope. Otherwise, you have to write the file in the temporary storage and use this file path to display dynamic image.

Reference is here

Community
  • 1
  • 1
Zaw Than oo
  • 9,651
  • 13
  • 83
  • 131
  • 3
    1. is wrong. OP is using `mode="advanced"`. The ajax should only be disabled on `mode="simple"`. – BalusC Sep 20 '13 at 11:12