rich:fileUpload and RF 3.3.3-BETA1

[jpleed3]

Has anyone had any problems with rich:fileUpload in RF 3.3.3 BETA 1? I've been trying to get it working, but my listener method isn't even getting called. The J5EE version of the code (session instead of conversation scope, no weld) works fine with RF 3.3.2-SR1.

Tag usage:

<rich:fileUpload id="pictureUpload" binding="#{simplePogSetCrud.pictureUploadComponent}"

    fileUploadListener="#{simplePogSetCrud.uploadListener}" />

Backing bean constructor prepares component by calling:

void prepareUploadComponents() {
        pictureUploadComponent.setMaxFilesQuantity(1);
        pictureUploadComponent.setStyleClass("pog-upload");
        pictureUploadComponent.setAllowFlash("true");
        pictureUploadComponent.setImmediateUpload(true);
        pictureUploadComponent.setListHeight("auto");
        pictureUploadComponent.setListWidth("325px");
        pictureUploadComponent.setCleanButtonClass("nodisplayall");

        pictureUploadComponent.setAcceptedTypes("jpg,jpeg");
        pictureUploadComponent.setAddControlLabel("Upload New Picture");
}

Upload listener method:

public void uploadListener(UploadEvent event) throws Exception {
        System.out.println("SPSUploadListener: Process upload called");
    ...

}

Nothing gets printed to the output when I upload a file.

[ilya_shaikovsky]

component bindings in jsf should not live longer the request. different problems could occurs with session scoped bindings.

[jpleed3]

Fair enough... JSF 2 Spec, section 3.1.5 states:

It is strongly recommend that application developers place managed beans that are pointed at by component binding expressions in “request” scope. This is because placing it in session or application scope would require thread-safety, since UIComponent instances depends on running inside of a single thread. There are also potentially negative impacts on memory management when placing a component binding in “session” scope.

But what about conversation or view scope? In my case, the component is bound to a conversation scoped bean.

That aside, why would the code work in RF 3.3.2-SR1 (I mistyped this earlier) and not in RF 3.3.3-BETA1? Just to see if anything would change, I pushed my upload listener method into a separate class that implements FileUploadListener; there was no change.

[jpleed3]

I reworked my code to not use a component binding:

Tag Usage:

<rich:fileUpload addControlLabel="Upload New Picture" id="pictureUpload"

    maxFilesQuantity="1" allowFlash="true" immediateUpload="true" listHeight="auto"

    acceptedTypes="jpg,jpeg" fileUploadListener="#{standardPogSetImageUpload.processUpload}">

    <a4j:support id="pictureUpload-support" event="onfileuploadcomplete" ajaxSingle="true"

        oncomplete="alert('Thumbnail picture will update when changes are saved.');" />

</rich:fileUpload>

Upload Listener:

@javax.inject.Named("standardPogSetImageUpload")

@javax.enterprise.context.RequestScoped

public class StandardPogSetImageUploadListener implements FileUploadListener {

    @Override

    public void processUpload(UploadEvent event) {

        ...

    }

}

In the constructor and in the processUpload method, I have a logger setup to tell me when they are entered... they still are never called. However, the alert message I have set up does display. (I've also tried it without the a4j:support tag, no go.)

[ilya_shaikovsky]

1) do you able to see "transfer error" at fileUpload after pressing upload?

2) if there is some errors in log?

B.t.w. should be event="onuploadcomplete"

[jpleed3]

For the most part, there is no indication that anything has failed. Every once in a while I get a transfer error, but there is never anything in the logs. Would I need to turn a logging level up?

Also, even though I'm uploading a small file (75KB) all on my local machine, the upload component will take anywhere between 10-30 seconds to show the alert box after the progress indicator is full.

For kicks, I changed allowFlash to false - now my logging messages are appearing, so I'll assume it's working. However, when I was choosing the file to upload, the acceptedTypes value was ignored and it defaulted to All Files.

So I changed it back to allowFlash=true and tried it on IE8. Works just fine. So I suppose the environment to replicate the problem will be:

• Firefox (in my case, v 3.5.7)
• allowFlash=true

[ilya_shaikovsky]

I can't get this issue.. And I guess that the problem is in Flash Plugin for Firefox.