Details
-
Type:
Improvement
-
Status: Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 2.0.2
-
Component/s: Bridge, ICE-Components
-
Labels:None
-
Environment:ICEfaces 2, ice:inputRichText component
-
Assignee Priority:P1
-
Affects:Documentation (User Guide, Ref. Guide, etc.), Compatibility/Configuration
Description
However, this preloading is not efficient as it causes the CKeditor.js to be loaded and evaluated each time a page is loaded, even if the component is not being used. This JIRA is to add a mechanism (config. param?) that would allow the application to opt. out of the inputRichText JS preload if that component is not being used.
Issue Links
- blocks
-
ICE-8166
ICEfaces Showcase sample app. - Remove legacy use of NavigationController.refreshPage()
-
- Closed
-
Activity
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion
The new technique is also not deploying and running well on Jboss7.
Following error seen in log:
12:44:28,140 SEVERE [javax.enterprise.resource.webcontainer.jsf.context] (http--127.0.0.1-8080-1) JSF1073: javax.faces.event.AbortProcessingException caught during processing of RENDER_RESPONSE 6 : UIComponent-ClientId=, Message=java.io.IOException: Cannot access InputRichText resources icefaces-compat.jar when exploded into the classpath.
12:44:28,140 SEVERE [javax.enterprise.resource.webcontainer.jsf.context] (http--127.0.0.1-8080-1) java.io.IOException: Cannot access InputRichText resources icefaces-compat.jar when exploded into the classpath.: javax.faces.event.AbortProcessingException: java.io.IOException: Cannot access InputRichText resources icefaces-compat.jar when exploded into the classpath.
at com.icesoft.faces.component.inputrichtext.InputRichTextSetup.processEvent(InputRichTextSetup.java:50) [icefaces-compat.jar:]
at javax.faces.event.SystemEvent.processListener(SystemEvent.java:106) [jboss-jsf-api_2.0_spec-1.0.0.Final.jar:1.0.0.Final]
at com.sun.faces.application.ApplicationImpl.processListeners(ApplicationImpl.java:2102) [jsf-impl-2.0.4-b09-jbossorg-4.jar:2.0.4-b09-jbossorg-4]
at com.sun.faces.application.ApplicationImpl.invokeListenersFor(ApplicationImpl.java:2078) [jsf-impl-2.0.4-b09-jbossorg-4.jar:2.0.4-b09-jbossorg-4]
at com.sun.faces.application.ApplicationImpl.publishEvent(ApplicationImpl.java:301) [jsf-impl-2.0.4-b09-jbossorg-4.jar:2.0.4-b09-jbossorg-4]
at com.sun.faces.application.ApplicationImpl.publishEvent(ApplicationImpl.java:245) [jsf-impl-2.0.4-b09-jbossorg-4.jar:2.0.4-b09-jbossorg-4]
at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:108) [jsf-impl-2.0.4-b09-jbossorg-4.jar:2.0.4-b09-jbossorg-4]
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.0.4-b09-jbossorg-4.jar:2.0.4-b09-jbossorg-4]
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139) [jsf-impl-2.0.4-b09-jbossorg-4.jar:2.0.4-b09-jbossorg-4]
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:313) [jboss-jsf-api_2.0_spec-1.0.0.Final.jar:1.0.0.Final]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
at org.jboss.as.web.NamingValve.invoke(NamingValve.java:57) [jboss-as-web-7.0.0.Final.jar:7.0.0.Final]
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:154) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:667) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:951) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
at java.lang.Thread.run(Thread.java:619) [:1.6.0_21]
Caused by: java.io.IOException: Cannot access InputRichText resources icefaces-compat.jar when exploded into the classpath.
at com.icesoft.faces.component.inputrichtext.InputRichTextSetup.loadResources(InputRichTextSetup.java:92) [icefaces-compat.jar:]
at com.icesoft.faces.component.inputrichtext.InputRichTextSetup.processEvent(InputRichTextSetup.java:36) [icefaces-compat.jar:]
... 22 more
Tying to collect the list of CKEditor resources by looking into the JAR or directory that contains them is not possible in JBoss. The URL returned when the JAR/directory is located has the "vfs:" protocol which means that we would need to use the VFS Jboss library to get access to the file. But that will force us onto being dependant on the VFS library which is not really acceptable.
Modified the build to generate a file that contains the list of CKEditor resources. This file is loaded then as a resource at startup time by InputRichTextSetup class. This approach avoids the scanning of the JAR file (containing the CKeditor resources) at startup which proved to be problematic in JBoss.
It looks like JBoss's classloader cannot load new JARs while the application is running. Normally this feature (URLClassLoader.addURL) is used to load the modified CSS resources into the classpath so that JSF can find when they need to be served up.
Implemented new approach where the CSS resources are loaded into memory, image paths are re-written but instead of serving these resources from the file system they are served by a custom ResourceHandler registered with JSF (InputRichTextResourceHandler). Also modified the loading of the mapping between local paths to request paths registered with CKEditor. Now it is loaded as an external resource, not as inline JS which should improve loading performance through caching.
Could we just have the ice:inputRichText component adopt the mandatoryResource feature, so it could be controlled the same way as the ace: components?