I use omnifaces tree to edit some recursive data structure.But the primefaces component's state is invalid (has red border) when I open the page.
versions:
omnifaces-1.3-SNAPSHOT-20121121.jar
primefaces-3.4.1
tomee 1.5.1 with myfaces 2.1.9
java 7
I also tested with Mojarra 2.1.9, the same result.
Here is the archive of the eclipse project.
This was caused by a bug in OmniFaces EditableValueHolderStateHelper. The valid property indeed incorrectly defaults to false. This is reported as issue 105 and a snapshot containing the fix is provided in the issue ticket.
Related
The p:photocam version for this version of primefaces (6.1.RC2) doesn't work very well, and I need to update it, but due to other reasons I can't update the primefaces.
It is possible?
Thank you all
OK attempt this at your own risk but do the following if you must stay on 6.1.
Download PrimeFaces 8.0 JAR.
Unzip the JAR and find the file \META-INF\resources\primefaces\photocam\photocam.js
Now take the photocam.js from step # 2 and replace it in your PrimeFaces 6.1 JAR in the same location and zip up the 6.1 JAR again.
That should do it but I will not guarantee it will work.
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
I have not lot work experience with PrimeFaces. I have to migrate a java web PrimeFaces project from 3.4 to 5.2. Although I searched it all over the internet there was not proper solution for my situation. If you ever have any experience with this kind of problem or ever heard of that please let me know or send me link for that. Basically I want to the way of doing it. I already have idea about witch component should be changed. Is there anything to do except replacing the jar? I already tried to replace PrimeFaces 3.4 with PrimeFaces 5.2 jar. But it does not allow me to replace the jar. Do I have to to change the code too? Please i want the migration steps.
There is a PrimeFaces migration guide. you need to go step by step to get from 3.5 to 5.2.
Here is the full migration guide for your situation:
Copied from MigrationGuide
3.4 to 3.5
Component Changes
DateSelectEvent, ScheduleDateSelectEvent, ScheduleEntrySelectEvents classes are removed, use SelectEvent instead.
Column class in SortEvent and ColumnResizeEvent is replaced with UIColumn to support dynamic columns.
Scrollable and Resizable DataTable-TreeTable features are reimplemented. DataTable and TreeTable no longer render cell container div element with classes ui-dt-c and ui-tt-c.
Sheet component is removed as it duplicated functionality of DataTable. Galleria is reimplemented.
General Changes
IE7 support is phased out.
3.5 to 4.0 Component Changes
MenuModel is rewritten and not backward compatible with the old version.
(skip this when e.g. directly migrating from 3.x to 5.x, it is 'reverted' again in 5.0) DataTable sortBy and filterBy expressions require the plain property name meaning "name" instead of "#{person.name}".
Backward compatibility is maintained for expressions like
"#{var.property}" but not for complex expressions.
FileUpload is reimplemented and it is backward compatible except "showButtons" option is removed.
disabledSelection option of column, moved to DataTable, change is backward compatible and the option will be removed from column in a future release.
AutoComplete: removed process/global/onstart/oncomplete in favor of "p:ajax event="query" process/global/onstart/oncomplete"
General Changes
Preferred way of accessing widgets is via PF('widgetVarName').show(), old way (e.g. widgetVarName.show())
is still supported and will be removed in a future version.
4.0 to 5.0 Component Changes
Chart components are deprecated in favor of new generic chart component with new Chart API. Old chart components are still supported but will be removed in a future release.
ToolbarGroup deprecated, use left and right facets of toolbar instead. (Reverted back as of 5.0.1, both facets and toolbar groups will be supported instead)
Defining fields in sortBy-filterBy attributes is deprecated use a value expression instead.e.g. sortBy="#{user.name}" instead of sortBy="name"
DataTable frozen rows feature take an integer value instead of a collection from now on. This value defined how many rows from the start should be frozen.
LazyDataModel's filters parameter changed to Map instead of Map as a requirement of the new Advanced
Filtering Feature.
Dialog: appendToBody was removed in favor of appendTo="#(body)" to gain more flexibility
Watermark: forElement was removed in favor of for="#(yourSelector)".
Widgets must be referenced via "PF". e.g. PF('widgetVarName').show() instead of widgetVarName.show();
DataTable layout changed to table-layout:fixed.
PrimeFaces Push is reimplemented, PushContext is deprecated, use EventBus instead along with the new Push API.
ScrollPanel is reimplemented, usage is backward compatible however UI is slightly different.
5.0 to 5.1
Support for literal texts in filterBy-sortBy expressions were deprecated in 5.0 and it is removed in 5.1. These attributes only work with value expression as in the past.
Deprecated chart components are removed.
You can't directly migrate from 3.4 to 5.2.
There are some steps given to migrate in MigrationGuide. Perhaps you could first migrate from 3.4 to 4.0 there are some components changes on DataTable, DateSelectEvent, etc. Then you could proceed with 4.0 to 5.0 migration which involves more changes in LazyDataModel's and some of componets. Please go thought link given for MigrationGuide above.
I am experiencing a problem with a composite component. I'm not quite sure if it's a bug in one of the used libraries or just my own ignorance of the matter. If I put the component bar.xhtml files in
WebContent/resources/foo/bar.xhtml
everything is working as intended. But if I put them in
WebContent/resources/subfolder/foo/bar.xhtml
they are just not displayed, and I get the message:
The page /login.xhtml declares namespace http://java.sun.com/jsf/composite/subfolder/foo and uses the tag foo:bar , but no TagLibrary associated to namespace.
I suspect it has something to do with the unmapped resource handler from Omnifaces, and is maybe just a parameter I'm not able to figure out. Maybe someone can give me a hint here?
I'm using (amongst others):
Apache MyFaces 2.2.4
Omnifaces 1.8.1
Primefaces 5.0
Tomcat 8.0.12
Edit 2
Moved the answer to a reply
Ok - after sleeping one night over it, I found out that this had nothing to with Omnifaces, but with a change in MyFaces since 2.1.6. Since then, you have to put the following in your web.xml:
<context-param>
<param-name>org.apache.myfaces.STRICT_JSF_2_ALLOW_SLASH_LIBRARY_NAME</param-name>
<param-value>true</param-value>
</context-param>
(found here )
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).