I used the same sample code Primefaces has in its web page:
<h:commandLink value="Excel">
<p:dataExporter type="xls" target="dataTable" fileName="boo" pageOnly="true"/>
</h:commandLink>
But does not work.
In Internet Explorer browser gives the following message:
Details of the errors of the web page Message: Unexpected call to
method or property access.
Nothing ever happens in Mozilla Firefox.
What might be happening?
javax.servlet.ServletException: org/apache/poi/ss/usermodel/RichTextString
Look further down in the stacktrace. I bet that the root cause is either a NoClassDefFoundError or ClassNotFoundException? In that case, this just means that you forgot to install Apache POI.
Download this Apache POI zip file, extract it, put poi-3.8-20120326.jar in /WEB-INF/lib folder and rebuild/redeploy/restart the webapp.
Try to to put this jar file.I show the link,because i solved this problem.
http://apache.mirrors.pair.com/poi/release/bin/poi-bin-3.9-20121203.zip
Related
We have a JSF application that is currently working and live that uses Primefaces 7.0. The application allows users to upload files using the Primefaces FileUpload component which we then handle and process.
The firewall team is forcing a firewall to sit in front of the upload process which will block upload requests from hitting the application if it deems the file to not be suitable and return a 503 error to the browser. I am struggling to work out how we can handle the 503 error within the JSF application as the request never hits the server and I can't find a suitable attribute we can add to the FileUpload component that would listen for the 503 (tried using onerror as shown in code below but unfortunately it doesn't get called when the 503 error occurs). Without handling this error, nothing is presented to the user to suggest anything happened. Ideally we would present a growl message to the user asking them to try a different file type.
Below is the code currently for the FileUpload component however I'm not sure if it's any use as I'm looking more for advice than a code fix.
Anyone have any idea on how to potentially handle the 503?
Thanks
<p:fileUpload widgetVar="upload" id="upload"
disabled="#{user.filesRemaining eq 0}" label="SELECT FILES"
fileUploadListener="#{controller.handleFileUpload}"
styleclass="smallCommandButton" mode="advanced"
dragDropSupport="true" auto="true"
allowTypes="/(\.|\/)(jpeg|jpe|jpg|png|pdf)$/i" sizeLimit="10485760"
invalidSizeMessage="Image files must be under 10MB in size"
invalidFileMessage="Only JPG, PNG or PDF files can be uploaded"
onerror="#{controller.handleUploadError()}"
onstart="PF('uiBlocker').show()"
oncomplete="PF('uiBlocker').hide()">
</p:fileUpload>
Found a solution, I needed to add the below code to my fileUpload component, 'arguments' carries the information for the error:
onerror="handleUploadError(arguments)"
and then create the corresponding javascript function to handle the error e.g.
function handleUploadError(arguments) {
if(arguments[0].status === 503) {
**create message for user here**
}
}
I upgraded my server in Eclipse from WildFly v10.x to WildFly 18.0.0 Final and now one of my JSF/Primefaces applications doesn't render properly after updating the view. On initial page load the view looks fine but if I select some filters (Primeface dropdowns, checkboxes, etc..) and click a command button to refresh the view (AJAX), it renders as if Primefaces is no longer available. See screenshots
Initial View Renders Fine:
After View Is Updated:
The error while debugging in Chrome:
SCRIPT5007: Unable to get property 'cw' of undefined or null reference
.
$(function(){PrimeFaces.cw('Growl','widget_growl',{id:'growl',sticky:false,life:5000,escape:true,msgs:[]});});
Not sure why the application is now not working after just upgrading WildFly.
I fixed by replacing #all on the p:commandButton with a more specific target
<p:commandButton action="#{...}" update="#all" />
<p:commandButton action="#{...}" update=":tripFormId:dataTableId" />
I realized after seeing this in the Chrome console debugger
jquery.js.xhtml?ln=primefaces&v=7.0:2 [Deprecation] Synchronous
XMLHttpRequest on the main thread is deprecated because of its
detrimental effects to the end user's experience. For more help, check
https://xhr.spec.whatwg.org/.
I am using the WebSphere Liberty Profile server, version 8.5.5.3. I have an ear containing multiple wars. I deploy them all exploded (ear and the war's of the modules inside it as well).
When deploying it I get the following class cast exception:
java.lang.RuntimeException: javax.xml.bind.JAXBException:
ClassCastException: attempting to cast bundleresource://67.fwk-1166858817/javax/xml/bind/JAXBContext.class
to jar:file:/C:/ws/IBM/java_1.7_64/jre/lib/rt.jar!/javax/xml/bind/JAXBContext.class.
Please make sure that you are specifying the proper ClassLoader.
I figured that the problem is that my bundled jax-api and jaxb-impl jars are not loaded, so I added to the server.xml the parentLast class loading option:
<enterpriseApplication id="ear-app" location="C:/ws/ear/exploded/ear-app.ear" name="ear-app" >
<classloader delegation="parentLast" commonLibraryRef="provided-jars" privateLibraryRef="shared-libs"/>
</enterpriseApplication>
I added my jax-api and jax-impl jars to this folder
<library id="shared-libs">
<fileset dir="${server.config.dir}/lib/global" include="*.jar"/>
</library>
However I still have the ClassCastException, it looks like it is still using the parentFirst classloading?
I found other jaxb ClassCastException threads, but not when using the Liberty profile..
Maybe it is a typo, but in your post you have delegation="parentFirst" instead of parentLast.
Did you check to just change delegation for application like this:
<enterpriseApplication id="ear-app" location="C:/ws/ear/exploded/ear-app.ear" name="ear-app" >
<classloader delegation="parentLast"/>
</enterpriseApplication>
For more details see Overriding a provided API with an alternative version
I worked aroud the problem by not using the parentLast. Thanks for the help.
Hello trying to figure out the Jsf (primefaces) and little that goes viz. Compiled war archive in maven try to run through the Glassfish, the server starts but in the beginning writing "Artifact qwe-1.0-SNAPSHOT.war: Server is not connected. Deploy is not available." But in the late writes "Artifact qwe-1.0-SNAPSHOT.war: Artifact is being deployed, please wait... Artifact is deployed successfully." It seems like everything is normal, then opened my page in the browser is empty although in my index.xhtm and my pom.xml and web.xml link pastebin
and should be a button with styles that are connected in primefaces tell me if I'm doing something wrong?
here's a screenshot of the result in the browser. link1
<p:button outcome="productDetail" value="Bookmark" icon="ui-icon-star"> targets you to the productDetail page. If you do not have productDetail.xhtml page at the currect path, the index.xhtml page cannot resolve NavigationCase for outcome. Thus, Create page productDetail.xhtml and put into the same directory of index.xhtml.
In addition, You should use JSF Standard tags(h:head, h:body).
We have an application which uses JSF2 and Spring. The application works fine when deployed. But this happens if I went through the following steps:
Open the login page of the application.
Redeployed the application on the server.
Tried to login using the previously opened login page, and it shows the following exception:
javax.servlet.ServletException: null source
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:321)
at org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:237)
at org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:167)
root cause
java.lang.IllegalArgumentException: null source
at java.util.EventObject.<init>(EventObject.java:38)
at javax.faces.event.SystemEvent.<init>(SystemEvent.java:67)
at javax.faces.event.ComponentSystemEvent.<init>(ComponentSystemEvent.java:69)
at javax.faces.event.PostRestoreStateEvent.<init>(PostRestoreStateEvent.java:69)
at com.sun.faces.lifecycle.RestoreViewPhase.deliverPostRestoreStateEvent(RestoreViewPhase.java:256)
at com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:245)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:97)
at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:107)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:114)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:308)
If I click on the first login page and then enter the login details the application does not break. This only occurs if I try to use the previously loaded login page with the newly deployed application.
Anyone knows the answer?
This one should have been thrown as a ViewExpiredException. It's a bug which started to manifest in Mojarra 2.0.3 and is been fixed in Mojarra 2.1.0. See also issue 1762 (note that Mojarra 2.1.0 doesn't work on Tomcat/Jetty, use at least Mojarra 2.1.1 then).
Basically, when Mojarra fails to build or restore the view, then it usually throws a specific enough exception, but due to this bug, a valid view was incorrectly been expected later in the code which in turn results in IllegalArgumentException: null source. The possible real cause would have been that the view contains a simple XML syntax error, such as a missing tag or broken attribute value, for which Mojarra would usually have thrown a FaceletException with a very detailed message with line number and position and such.
To prevent the ViewExpiredException, you would have to refresh the page by a GET request before doing any actions on it. If you're using a Mojarra version where this bug does not manifest (e.g. 2.0.2 or older, or 2.1.0 or newer), then you could gracefully handle it with an <error-page> in web.xml on the particular exception and provide a custom error page wherein the enduser is informed that the session has been expired, along with a link to the initial request URI.
This looks like http://java.net/jira/browse/JAVASERVERFACES-1758
which is not fixed in Mojarra 2.1.x
As long as javax.faces.PARTIAL_STATE_SAVING is set to false you'll receive that java.lang.IllegalArgumentException. If you set javax.faces.PARTIAL_STATE_SAVING to true (and you know what you are doing) you will get the "good old" javax.faces.application.ViewExpiredException back.
In my case turned out i had missing end tag in xhtml file for one of the jstl calls. i was using choose tag and one of the when tags in between choose did not have an end tag