ICEfaces' inputfile results in concurrent call on SFSB

[newlukai]

Hi there,

I use ICEfaceas' inputFile component to let the user upload files. After the user has chosen a file and submits the upload form (it's an iFrame containing a multipart form), a Could not find stateful bean exception is thrown. Right before this exception the log tells me that there is a problem with a concurrent call on a SFSB.

Solving this problem isn't trivial, because I don't know which threads call this SFSB and why. If I knew that I would have a chance to fix it. So I read in several forums and documentations and found this from the Seam documentation:

Concurrent requests to session-scoped stateful session beans are always serialized by Seam.

The bad thing is: the multipart form handles the upload without Seam. Would Seam's upload component work with Seam? Or is there a way to find out which threads/components call the SFSB?

Thanks in advance
Jens

[jguglielmin]

Not sure which version of ICEfaces you are using but this was tracked with the following jiraICE-2999.

I have developed several variations of using this component with Seam (including not using the progress bar which is similar to using s:fileupload, as well as a conversation-scoped backing bean).  Recommended libraries for ICEfaces are 1.7.2.SP1 for Seam 2.x, and 1.7.1 for Seam 1.2.1.GA.

[newlukai]

Thanks for your advice. I downloaded the new version and tried it, but it doesn't help.

Because the SFSB that is called concurrently is a special one, I will explain it a little further.

I've two components, where component B is the one that is called concurrently. Both of them inject the other one, i. e. A injects B and vice-versa. Additionally A calls B in its @Create method. That means if neither A nor B exist and B has to be created (it's annotated with @AutoCreate and injected somewhere), then Seam has to create A first. Seam creates A which calls B, which doesn't yet exist.

I think I created something like a deadlock, but in any place I use one of those components or even both, it works. There are no problems, only the upload doesn't work. And because there's no other place where this deadlock doesn't work, I don't think it's a problem; or Seam is intelligent enough to handle this.

[jguglielmin]

I can think of a few things to try like removing the progress bar from the fileupload and see if it works then.  Also, are you using the latest markup for inputFile?  Similar to the following:-

        <ice:inputFile id="inputFileName"
                       progressRender="true"
                       submitOnUpload="postUpload"
                    progressListener="#{inputFileController.fileUploadProgress}"
                       actionListener="#{inputFileController.uploadFile}"/>

You can use it without the progressListener and outputProgress component to make it simpler.  Instead of injecting the components into each other, you could also try Components.getInstance(compA), etc.  The fileupload with progressMonitor actually bypasses injection with each push.  If you want to post your actual code of the xhtml and source, please do so on the ICEfaces forum.

[newlukai]

Thanks for your advice. I didn't use any progress bar and I immediately switched to the latest markup as I saw it. I also tried ICEfaces 1.7.2 and it didn't work. So I changed the dependencies in my components and it works now.

[gus888]

Jens Weintraut wrote on Dec 18, 2008 13:19:

So I changed the dependencies in my components and it works now.

Hi Jens, can you share how you changed the dependencies and make it works? It seems a nightmare for file uploading when integrating Seam with ICEfaces, since both s:fileUpload and ice:inputFile failed to work.

[jguglielmin]

@Sheng

If Jens doesn't post back here in sufficient time (or his posting doesn't help you), please post your exact problems to ICEfaces forum as we can provide several examples of Seam and ICEfaces working with fileupload.  Also, if you have a simple sample project that exhibits your problem, please attach it there so we can have a look at it.

[newlukai]

Hi Sheng,

I'm sorry that this post took so long. It's the first day I'm working in the new year. BTW: Happy new year :D

In my application the call of B in the @Create method of A was unnecessary so I removed it. I'm sure this is not the solution you hoped to hear, so I'm sorry.