using <ace:fileEntry>

with a series of <h:commandButton> markup as follows:
<ice:form>
<ace:fileEntry id="fileEntryComp"
relativePath="/files/"
maxFileSize="6291456"
maxFileSizeMessage="Submitted file is too large."
maxTotalSize="18874368"
maxTotalSizeMessage="Total size of submitted files is too large."
required="true"
requiredMessage="The file is required to submit this form."
useOriginalFilename="true"
fileEntryListener="#

">
</ace:fileEntry>

<h:commandButton id="submitBtn" value="PlainSubmit" type="submit"/>
<h:commandButton id="cmdAttr" value="submitWithAttr" type="submit">
<f:attribute name="convIdAttribute" value="#

" />
</h:commandButton>
</ice:form>

using 3.0.0.RC2...
none of the first 3 h:commandButton's will fire until after I have used the last one (???? is there something that limits only one submit per form now?).

Last one, retains the cid, but the File is empty for the upload (even when it is not)....has this component been tested with <f:param>?? Anyways, get the File is required for this component message, so no file is created when using f:param in this use-case.

All the other options (only working once I have used the last button on the form)....have problems with the conversation being null. Tested and it is null at the very beginning of the fileListener method. (checked it first thing). I would imagine that the context may be cleaned out .
it is stored in javax.enterprise.context.conversation which becomes null as soon as you trigger the method for the fileListener.

Files are all uploaded successfully with first 3 options, but conversation is null (problem for weld/CDI).

using ICEfaces-2.0.2 release:-
(package name changed for the file entry classes between this version and 3.0.0.RC2).
I don't have to fire the last button, I can fire any of them and they will work as above.
Again, the conversation is lost for the first three but not the last, but the file is empty for the last one.

question....
how do we want this to work??? Should whatever is in the request context (like conversation) be kept as this component moves through it's processing, or do we want to allow the use of <f:param> to ensure they can maintain their parameters . Either way, neither is working at this time, but probably should decide what is going to be supported for items like conversation id propagation.

above testing one on jboss-as-7.1.0.CR1b (aka FluxCompacitor).

info on how conversation is propagated for weld.
5.3.2. Conversation propagation

The conversation context automatically propagates with any JSF faces request (JSF form submission) or redirect. It does not automatically propagate with non-faces requests, for example, navigation via a link.

We can force the conversation to propagate with a non-faces request by including the unique identifier of the conversation as a request parameter. The CDI specification reserves the request parameter named cid for this use. The unique identifier of the conversation may be obtained from the Conversation object, which has the EL bean name conversation.

Therefore, the following link propagates the conversation:

<a href="/addProduct.jsp?cid=#

">Add Product</a>

(from http://docs.jboss.org/weld/reference/latest/en-US/html/scopescontexts.html)

It's probably better to use one of the link components in JSF 2:

<h:link outcome="/addProduct.xhtml" value="Add Product">

<f:param name="cid" value="#

"/>

</h:link>

Tip
The conversation context propagates across redirects, making it very easy to implement the common POST-then-redirect pattern, without resort to fragile constructs such as a "flash" object. The container automatically adds the conversation id to the redirect URL as a request parameter.

Let's switch from using h:commandButton with an f:param to using h:commandButton with a hidden field containing the cid.

the following meets the criteria of the conversation not being lost and the upload completing successfully.
<h:commandButton
value="UPLOAD THAT RETAINS CID, BUT NEVER RUNS THE ACE:FILEENTRY LISTENER METHOD"
action="#

">
<input type="hidden" name="cid"
value="#

" />
</h:commandButton>

Note that having the hidden field anywhere on the form, allows any of the upload buttons to work. <f:param> is not supported with h:commandButton when used to submit a file upload with the ace:fileEntry component.