I'm using Glashfish 3 & Primefaces 3.5
Small update
I tried the following but without any luck.
Cleaned my application.
Re-Built the project.
Undeployed the app from Glassfish admin console.
Restarted Glassfish server.
Deployed again from JDeveloper.
While accessing my jsf page I'm getting the below exception in the browser.
java.io.NotSerializableException: org.primefaces.component.outputpanel.OutputPanel
And in my log:
WARNING|glassfish3.1.2|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=24;_ThreadName=Thread-2;|StandardWrapperValve[Faces Servlet]: PWC1406: Servlet.service() for servlet Faces Servlet threw exception
java.io.NotSerializableException: org.primefaces.component.outputpanel.OutputPanel
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1164)
at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1518)
at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1483)
at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1400)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1158)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:330)
at java.util.HashMap.writeObject(HashMap.java:1001)
at sun.reflect.GeneratedMethodAccessor69.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:940)
at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1469)
at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1400)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1158)
at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1518)
at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1483)...
What may be wrong here.? It was working fine just the day before, and I've done no changes (to the application or server) whatsoever.
Update
Issue got resolved. There was an issue with my jsf file which somehow got corrupted. Thankfully I had a backup of it.
Thanks all for you support and suggestion.
Related
I am getting the following exception at runtime using the latest Deeplearning4j release. The exception cause is listed below. I do not get the full trace so not sure which class it is not finding. I am not sure where the log can be found for that exception in hopes of seeing the full trace. It is not in my app server log. I am running using Java 1.8 using the Wildfly app server on Windows 10 prof.
Thanks for any help.
-Tony
Caused by: java.lang.NoClassDefFoundError: Could not initialize class org.nd4j.linalg.factory.Nd4j
at org.deeplearning4j.util.ModelSerializer.restoreMultiLayerNetworkHelper(ModelSerializer.java:283)
at org.deeplearning4j.util.ModelSerializer.restoreMultiLayerNetwork(ModelSerializer.java:238)
at org.deeplearning4j.util.ModelSerializer.restoreMultiLayerNetwork(ModelSerializer.java:222)
at org.deeplearning4j.util.ModelSerializer.restoreMultiLayerNetwork(ModelSerializer.java:380)
at com.myuniportal.service.MyUniPortalMapMobileAIResource.(Unknown Source)
at com.myuniportal.service.MapAIApplication.(Unknown Source)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
at java.lang.reflect.Constructor.newInstance(Unknown Source)
at org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:150)
... 36 more
I fixed this by copying dlls from jars to a folder pointed to in the path.
I hope this answer helps others.
-Tony
Deeplearning4j maintainer here. You should never need to do this and I hope folks don't actually do this in the future. Javacpp (underlying component for native components) manages all of this in a .javcpp folder and already handles this.
If you have to do something more than add the dependency to your pom.xml/gradle file, you likely did something wrong.
The jars already contain the dlls and load them automatically.
I solved the problem (with out unjaring dlls) and was able to get a program running in eclipse. I am working on getting a servlet to run right now
Again, many thanks.
we're trying to migrate our application from Jboss Eap 6.4 to 7.2 but we're facing this issue.
When we're rendering the first view a NPE happens
Caused by: java.lang.NullPointerException
at deployment.EAR-0.0.1-SNAPSHOT.ear.blue_webLayer-0.0.2-SNAPSHOT.war//org.springframework.faces.webflow.FacesContextHelper.releaseIfNecessary(FacesContextHelper.java:64)
at deployment.EAR-0.0.1-SNAPSHOT.ear.blue_webLayer-0.0.2-SNAPSHOT.war//org.springframework.faces.webflow.JsfFlowHandlerAdapter.handle(JsfFlowHandlerAdapter.java:61)
at deployment.EAR-0.0.1-SNAPSHOT.ear.blue_webLayer-0.0.2-SNAPSHOT.war//org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:967)
at deployment.EAR-0.0.1-SNAPSHOT.ear.blue_webLayer-0.0.2-SNAPSHOT.war//org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:901)
at deployment.EAR-0.0.1-SNAPSHOT.ear.blue_webLayer-0.0.2-SNAPSHOT.war//org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:970)
It's like our app isn't able to create a faces context.
In addition I've seen some strange lines during the startup
10:06:34,775 INFO [org.jboss.as.jsf] (ServerService Thread Pool -- 55) WFLYJSF0007: Activated the following JSF Implementations: [main]
....
10:07:09,505 WARN [org.jboss.as.jsf] (MSC service thread 1-1) WFLYJSF0005: Unknown JSF version 'NONE'. Default version 'main' will be used instead.
We've replaced under "main" folder of Jboss' modules the api and spec JSF with the one we're using at the moment with Jboss 6.4.
We've also tried to use multiple JSF installation without luck.
Any idea?
The issue was caused to an updated version of spring-faces.
Using 2.3.2.RELEASE with spring-core 3.2.18.RELEASE fixed the issue.
Now our application is running under EAP 7.2 with custom JSF impl (mojarra 2.1.13)
I'll still need to figure out how to make it work with Spring 4+ and jsf-impl 2.3 but these are another kind of problem.
I have recently upgraded my project to richfaces 4 from richfaces3 and also JSF 1 is been upgraded to JSF 2. I find no issues during the build and build is successful. But when I am trying to deploy application using JBOSS 6 I get below error:
Caused by: java.lang.NoSuchMethodException: org.apache.myfaces.custom.aliasbean.AliasBeanTagHandler.<init>(javax.faces.view.facelets.ComponentConfig)
at java.lang.Class.getConstructor0(Class.java:2892) [:1.7.0_72]
at java.lang.Class.getConstructor(Class.java:1723) [:1.7.0_72]
at com.sun.faces.facelets.tag.AbstractTagLibrary$UserComponentHandlerFactory.<init>(AbstractTagLibrary.java:290) [:2.0.3-]
... 93 more
I have tried a lots of things but nothing worked. Any kinda help would be much appreciated. Thanks a lot in advance
JBoss 7.1, OmniFaces 1.6, Eclipse Kepler, CDI 1.0
I have found the following situation with new Omnifaces 1.6, when I updated from OmniFaces 1.5 to OmniFaces 1.6. I suppose it has something to do with new interesting CDI features of OmniFaces 1.6.
I have two JSF based WAR projects in one EAR archive, both projects have OmniFaces as dependency and they both will be deployed. In deployment, OmniFaces 1.6 ends up in /WEB-INF/lib of both WAR projects. At start of JBoss the IllegalArgumentException was thrown.
java.lang.IllegalArgumentException: Registering converter 'class org.omnifaces.converter.ListConverter' failed, duplicates converter ID 'omnifaces.ListConverter' of other converter 'class org.omnifaces.converter.ListConverter'.
at org.omnifaces.cdi.converter.ConverterExtension.processConverters(ConverterExtension.java:78)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.weld.util.reflection.SecureReflections$13.work(SecureReflections.java:264)
at org.jboss.weld.util.reflection.SecureReflectionAccess.run(SecureReflectionAccess.java:52)
at org.jboss.weld.util.reflection.SecureReflectionAccess.runAsInvocation(SecureReflectionAccess.java:137)
at org.jboss.weld.util.reflection.SecureReflections.invoke(SecureReflections.java:260)
at org.jboss.weld.introspector.jlr.WeldMethodImpl.invokeOnInstance(WeldMethodImpl.java:170)
at org.jboss.weld.introspector.ForwardingWeldMethod.invokeOnInstance(ForwardingWeldMethod.java:51)
at org.jboss.weld.injection.MethodInjectionPoint.invokeOnInstanceWithSpecialValue(MethodInjectionPoint.java:154)
at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:241)
at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:229)
at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:207)
at org.jboss.weld.manager.BeanManagerImpl.notifyObservers(BeanManagerImpl.java:569)
at org.jboss.weld.manager.BeanManagerImpl.fireEvent(BeanManagerImpl.java:559)
at org.jboss.weld.bootstrap.events.AbstractContainerEvent.fire(AbstractContainerEvent.java:60)
at org.jboss.weld.bootstrap.events.AbstractDefinitionContainerEvent.fire(AbstractDefinitionContainerEvent.java:38)
at org.jboss.weld.bootstrap.events.ProcessManagedBeanImpl.fire(ProcessManagedBeanImpl.java:30)
at org.jboss.weld.bootstrap.AbstractBeanDeployer.deploy(AbstractBeanDeployer.java:123)
at org.jboss.weld.bootstrap.BeanDeployment.deployBeans(BeanDeployment.java:204)
at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:344)
at org.jboss.as.weld.WeldContainer.start(WeldContainer.java:82)
at org.jboss.as.weld.services.WeldService.start(WeldService.java:76)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
at java.lang.Thread.run(Thread.java:662)
If I remove one WAR project, then the exception dissapears and I can use the other WAR project in EAR.
Is it possible to use OmniFaces 1.6 in more as one project, and deploy to JBoss 7.1.1 in one EAR?
This bug has been fixed in 1.6.1. There's quite a story behind this bug, so I just wrote a blog on that: CDI behaved unexpectedly in EAR, so OmniFaces 1.6.1 released!
Summarized: CDI context isn't WAR-wide, but EAR-wide. As to the particular exception you faced, it's because there was only one CDI ConverterExtension being loaded from one WAR which is then applied EAR-wide and thus processing all #FacesConverter classes from both WARs instead of the WAR where the CDI extension was being loaded from.
Note that this is not a problem in OmniFaces. This is a problem in the way how CDI works in EARs.
Update: as per issue WELD-2143 this peculiar problem has finally been fixed in Weld 2.3.5. I have tested it in a patched WildFly 10.0.0 and confirmed that all OmniFaces CDI features which depend on an Extension, the #ViewScoped, #Eager and #Param work again in both WARs in a single EAR.
So, if you struggle with using aforementioned OmniFaces CDI features in an EAR with multiple WARs, make sure you upgrade Weld to at least version 2.3.5. The problem remains open in OpenWebBeans.
I used to deploy a JSF+Primefaces app in a Glassfish server without any trouble. Recently I upgraded my NetBeans version. I haven't had any problems with the most of the applications after that. But with one of them when I tried to do the deployment, it failed and this was the error message:
Error occurred during deployment: Exception while loading the app :
java.lang.IllegalStateException: ContainerBase.addChild: start:
org.apache.catalina.LifecycleException: java.lang.RuntimeException:
com.sun.faces.config.ConfigurationException:
java.util.concurrent.ExecutionException:
com.sun.faces.config.ConfigurationException: Unable to parse document
'jar:file:/opt/glassfish3/glassfish/domains/domain1/applications/[name-of-the-application]/WEB-INF/lib/javax.faces.jar!/META-INF/mojarra_ext.taglib.xml':
null. Please see server.log for more details.
It seems like all is ok with the project (cleans and build well), but the error keeps appearing. This is the environment I'm using:
NetBeans 7.3.1
JSF 2.2 (Mojarra)
GlassFish Open Source Edition 3.1.1 (build 12).
PS: When I try to do the deployment with Glassfish 3 bundled in NetBeans, this is the error:
SEVERE: Error during deployment : class com.sun.faces.application.annotation.PersistenceUnit Scanner cannot access its superinterface com.sun.faces.application.annotation.Scanner
Thanks
Unable to parse document 'jar:file:/opt/glassfish3/glassfish/domains/domain1/applications/[name-of-the-application]/WEB-INF/lib/javax.faces.jar!/META-INF/mojarra_ext.taglib.xml
The path to the taglib file suggests that you shipped JSF 2.2 along with the webapp inside its /WEB-INF/lib instead of upgrading GlassFish itself. As GlassFish 3 itself ships with a JSF 2.1 implementation out the box, you need to instruct it to not load it in order to avoid version conflicts. You didn't state anywhere that you were doing that, so I guess that this is the whole cause of your problem.
Glassfish itself already ships with JSF bundled which get by default classloading precedence over the one bundled in the webapp. You basically need to tell Glassfish to use the webapp bundled JSF instead.
In order to achieve that, edit the /WEB-INF/glassfish-web.xml to add the following two lines.
<class-loader delegate="false" />
<property name="useBundledJsf" value="true" />
If the file does not exist create it, you can find a sample xml file here. and add the two lines from above inside the <glassfish-web-app> tag.
GlassFish will then suppress its own bundled JSF from loading and rely on webapp-bundled JSF.
Alternatively, if you have full admin control over Glassfish, you can also copy the javax.faces.jar file from JSF 2.2 into the /glassfish/modules directory, hereby replacing the old one, in order to upgrade it from JSF 2.1 to JSF 2.2 so that it get applied on all webapps.