I use JSF 2.3 (Mojarra 2.3.3), Trinidad (2.2.1) and its file upload component (tr:inputFile) in a web.xml-version 3.1 on a Tomcat 8.5 server.
I get following exception and no valid uploaded file (i.e. the "value"-binded bean attribute remains null):
java.io.EOFException: null
at org.apache.myfaces.trinidadinternal.share.util.MultipartFormHandler._readLine(MultipartFormHandler.java:253) ~[trinidad-impl-2.2.1.jar:2.2.1]
at org.apache.myfaces.trinidadinternal.share.util.MultipartFormHandler._readLine(MultipartFormHandler.java:237) ~[trinidad-impl-2.2.1.jar:2.2.1]
at org.apache.myfaces.trinidadinternal.share.util.MultipartFormHandler._skipBoundary(MultipartFormHandler.java:223) ~[trinidad-impl-2.2.1.jar:2.2.1]
at org.apache.myfaces.trinidadinternal.share.util.MultipartFormHandler.<init>(MultipartFormHandler.java:102) ~[trinidad-impl-2.2.1.jar:2.2.1]
at org.apache.myfaces.trinidadinternal.share.util.MultipartFormHandler.<init>(MultipartFormHandler.java:75) ~[trinidad-impl-2.2.1.jar:2.2.1]
at org.apache.myfaces.trinidadinternal.config.upload.FileUploadConfiguratorImpl.beginRequest(FileUploadConfiguratorImpl.java:139) [trinidad-impl-2.2.1.jar:2.2.1]
at org.apache.myfaces.trinidadinternal.config.GlobalConfiguratorImpl._startConfiguratorServiceRequest(GlobalConfiguratorImpl.java:763) [trinidad-impl-2.2.1.jar:2.2.1]
at org.apache.myfaces.trinidadinternal.config.GlobalConfiguratorImpl.beginRequest(GlobalConfiguratorImpl.java:244) [trinidad-impl-2.2.1.jar:2.2.1]
at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl.doFilter(TrinidadFilterImpl.java:178) [trinidad-impl-2.2.1.jar:2.2.1]
at org.apache.myfaces.trinidad.webapp.TrinidadFilter.doFilter(TrinidadFilter.java:92) [trinidad-api-2.2.1.jar:2.2.1]
(Info: The JSF 1.2 version with Trinidad 1.2.14 with web.xml-version 2.5 on Tomcat 6 or a Weblogic 10 does not have this problem.)
While searching for a solution I found that this seems to affect not only my concrete situation, but also:
ADF Faces (at least 12.x)
Trinidad 2.1
JSF 2.x in general
Wildfly (10.1)
Searching for an answer I developed a solution I want to share.
Use JSF's <h:inputFile> (since JSF 2.2) instead of <tr:inputFile>.
You may continue to use <tr:form usesUpload="true">, but see notes below.
In the backing bean you have to simply replace org.apache.myfaces.trinidad.model.UploadedFile with javax.servlet.http.Part and use getSubmittedFileName() instead of getFileName().
With this, file upload already works, but the EOFException still occurs and is logged (but ignored internally).
To prevent the needed TrinidadFilter (configured in web.xml) from processing the file upload, add your own javax.servlet.Filter (most apps will already have one, I guess) and put in its doFilter():
request.setAttribute("org.apache.myfaces.trinidadinternal.config.upload.FileUploadUtils.PROCESSED", Boolean.TRUE);
Of course, your filter must be executed before the TrinidadFilter, so either use a broader filter-mapping or place it before TrinidadFilter in your web.xml.
Additional notes:
When using <tr:form> the <h:inputFile> will output the wrong error/warning "File upload component requires a form with an enctype of multipart/form-data" via FacesMessage - but not for javax.faces.PROJECT_STAGE Production.
You may simply ignore it in development or use <h:form enctype="multipart/form-data"> instead. But note: <h:form> is a naming container and <tr:form> is not, so addressing input elements differs (hformId:inputId instead of simple inputId)
If your <tr:inputFile> is used inside a <tr:panelFormLayout>, put the <h:inputFile> inside a <tr:panelLabelAndMessage> and put the label there.
CSS styling for af|inputFile::content must also be done for input[type="file"].
See also:
https://stackoverflow.com/a/27681292/5074004
https://developer.jboss.org/thread/274824?_sscc=t
http://myfaces.10567.n7.nabble.com/Trinidad-File-upload-issue-td30231.html
Related
This question already has an answer here:
What is the use of faces-config.xml in JSF 2?
(1 answer)
Closed 4 years ago.
I have been studying JavaEE8 and practicing with some projects, understanding the new technologies like Servlet 4.0 and JSF 2.3. I have read in many forums and pages, in some I see that they say that web.xml and faces-config.xml are not necessary, because annotations are now used, but in some others they continue to use them.
In which cases should you continue to use the Web Deployment Descriptor-> web.xml and the application configuration resource file-> faces-config.xml?
They aren't required, but I'd highly recommend to use them since you'll need them sooner or later for additional configuration anyways.
The annotations are used to achieve better readability and to simplify the faces-config.xml and web.xml, however they do not even nearly allow for the configuration options that can be made in the configuration files.
For example you can use the #FacesValidator Annotation instead of declaring and referencing the corresponding class in the faces-config.xml.
A task that can't be achieved by using annotations would be the declaratation of a welcome page. If you want to specify it, you need the web.xml.
I found a specific problem in the Mojarra implementation of JSF 2.3 when using the web.xml or faces-config.xml file. In the code of this implementation, the ELUtils class has the following condition:
if (getFacesConfigXmlVersion(facesContext).equals("2.3") || getWebXmlVersion(facesContext).equals("4.0")) {
throw new FacesException("Unable to find CDI BeanManager");
}
which throws an exception: "Unable to find CID BeanManager". I only had the faces-config.xml file with the latest version of JSF specified in the namespace and I was throwing that exception.
To avoid this problem, you can specify a different version of JSF (before 2.3) in the faces-config.xml file and specify a different version of the web.xml file (before 4.0), or simply do not add any of these configuration files. In my case, I removed the faces-config.xml and ran the application without problems.
I hope that the implementation of Mojarra will solve that little detail.
I tried to upgrade my Java EE 7 / JSF 2.2 application to Omnifaces 2.6. Currently I am running version 2.4.
After that, I have noticed a strange behavior when using #ConversationScoped and Ajax-Requests. When calling, the area, which should get rendered after the request, gets cleared (no exception on the server, response status code 200).
Next, I have a kind of wizard implementation, based on #ConversationScoped. It holds a class called ViewManager which has itself a List of Views. Initializing works fine and this list gets filled. But somehow it gets cleared (set to null) when the first form/view gets submitted. The setter for this is never called after the initialization, so it is not changed by my code. Somehow the view manager instance is still available, only this list of view within the view manager is null, which is kind of strange.
With omnifaces 2.4, everything did work fine (this is why I did not add some code of my wizard). I checked the changelog and noticed the MultiViews configuration when using ExtensionlessURLs. Don't know why this could effect my problem, but i tried it...with no success.
I have no idea what could be the problem, so maybe you can help me.
Thanks in advance :)
In OmniFaces, the FacesViews extensionless URLs feature got in version 2.5 an overhaul in order to support the so-called MultiViews as you can read on this blog.
During this overhaul I made a backwards compatibility mistake in the FacesViewsViewHandler where the <h:form> action URL is being manipulated in order to include the virtual folders of the MultiViews feature. The query string parameters were dropped from the original action URL and not added back.
The #ConversationScoped relies on the cid request parameter being present in the <h:form> action URL as in /context/page?cid=1. This thus became /context/page and therefore the conversation isn't retained across postbacks.
I will fix this in next OmniFaces release, for now you can get back the desired behavior by adding the below context parameter to web.xml.
<context-param>
<!-- Workaround for disappearing #ConversationScoped ?cid= parameter -->
<!-- This can be removed in next OmniFaces version after 2.6 -->
<param-name>org.omnifaces.FACES_VIEWS_VIEW_HANDLER_MODE</param-name>
<param-value>BUILD_WITH_PARENT_QUERY_PARAMETERS</param-value>
</context-param>
This parameter triggers a different way of building the URL whereby the entire query string from the original action URL is explicitly retained.
In this beginner's JSF tuorial
section 1.1 says:
JSF UI components and their state are represented on the server with a defined life-cycle of the UI components.
But in the example that follows, I am unable to see how the state of an UI component is managed by the server? The example looks like a standard servlet jsp example minus the servlet mappings.
My other question is that in the example, we are accessing the jsp directly. Is this the standard thing to do in JSF as opposed to using servlet mappings?
First of all, if you're a beginner, I encourage you not to look at that old tutorials and find a good JSF 2.x one. JSF 2 was released in 2009 and you should consider it as the branch to learn, as it brings several advantages comparing with 1.x old versions.
JSF has its own lifecycle for any request you make from the browser which can be a GET or POST request, even an ajax based one. What you basically have to understand about JSF comparing with other frameworks is that it's stateful. In other words, you can keep a component's state from one request to another (you actually have a view state, which can be kept no matter how many requests you do, until you change the view).
Appart from that, about your last statement, in old JSF ages the servlet mapping used to be done over .*jsf suffix. It means, when you make a request for that in the browser, jsf will convert the matching jsp page and display it.
JSF 2 however introduced facelets, which are based in .xhtml view pages. It's now also possible to do the mapping as .xhtml having the source code in an .xhtml too and JSF will make the conversion. The main advantage for this is that end user will not be allowed to see the sources, as browser's request matches source page's url, so JSF servlet will always be invoked.
I am trying to get the reusable group of jsf 1.2 components inside a panelgrid using Facelet tag file. #Balusc's previous answer at How to make a grid of JSF composite component? was a fabulous resource. I have a couple of followup questions:
In my c:when how do I test for the tagName itself instead of checking for the attributes. Instead of
<c:when test="#{type != 'submit'}">
I want to check tagName itself to decide how to format it. If 'input' do xxx.
2 Is this approach is still valid with jsf 1.2 other than f:ajax? If yes, can I replace with a4j:support...?
In my c:when how do I test for the tagName itself instead of checking for the attributes.
I'm not sure how this question makes sense. It sounds like that you're approaching something not entirely right. Do you maybe have copypasted exactly the same piece of code over multiple tag files? You should not do that. Make it a reuseable <ui:composition> or maybe <ui:decoration> instead which you compose/decorate in every tag file along with a fixed and unique <ui:param> value depending on the taglib file.
Is this approach is still valid with jsf 1.2 other than f:ajax? If yes, can I replace with a4j:support...?
Being able to create tag files is not necessarily specific to JSF, but to the view technology used, which is in this case Facelets. You can even do similar stuff in its predecesor JSP, see also this answer for an example: JSF 1.2 custom component from jsp:include It should work just fine in every JSF version supporting the view technology in question.
As to ajax support, it doesn't matter to the tag file what you're all doing inside the tag file. If you want and can use <a4j:support> then just do it.
I got this error when I upgraded from primefaces 3.0.M3 to 3.0.M4-SNAPSHOT
#60,114 Parent is not of type ActionSource, type is: javax.faces.component.html.HtmlForm#1d9c3e7
I understand that it is happening in other libraries like icefaces too, but I couldn't figure out how to fix it. Any help is appreciated.
The PrimeFaces tags/components are not been parsed at all and thus treated as plain HTML which caused that the real closest parent JSF component is a <h:form>.
This can have at least 2 causes:
You didn't update the taglib namespace URI from http://primefaces.prime.com.tr/ui to the new namespace http://primefaces.org/ui which was introduced in M4.
The PrimeFaces 3.0 M4 JAR file isn't in the webapp's runtime classpath. Verify if this is done right. This is to be achieved by dropping the JAR in /WEB-INF/lib, or if it's been dropped elsewhere, by including it in Deployment Assembly list in project's properties (assuming that you're using Eclipse).