-
1. Re: myfaces ExtensionsPhaseListener
julien1 May 29, 2006 2:53 PM (in response to dajevtic)it sounds great for 2.4 release but as JBoss AS (4.0.4.G1) ships with myfaces, you need to check that it contains the same version or compatible.
-
2. Re: myfaces ExtensionsPhaseListener
dajevtic May 29, 2006 3:29 PM (in response to dajevtic)"julien@jboss.com" wrote:
it sounds great for 2.4 release but as JBoss AS (4.0.4.G1) ships with myfaces, you need to check that it contains the same version or compatible.
Yes, I forgot to mention that I extended the ant build to replace the existing myfaces version in jboss-4.0.4.GA with the current one. All that needs to be done is modify the properties file to add jboss home variable if it is not set in the environment. -
3. Re: myfaces ExtensionsPhaseListener
julien1 May 29, 2006 4:31 PM (in response to dajevtic)We cannot change the myfaces version in JBoss.
If your patch cannot be applied fully until JBoss version myfaces upgrades then you should make a JIRA issue in JBPORTAL with your patch and make an upgrade request using JIRA too of myfaces in AS and link both jira ISSUE.
if the patch can be partally applies (on tomahawks) then we can apply this part. -
4. Re: myfaces ExtensionsPhaseListener
dajevtic Jun 1, 2006 4:41 AM (in response to dajevtic)Julien, sorry for not having gotten back to you earlier. I was out of town. However, in the meantime I was able to test the new tomahawk with the existing myfaces core of jboss-4.0.4.GA and I must say that compatibility seems quite all right between the two.
However, some of the tomahawk sandbox components do not seem to work properly with tomahawk 1.1.3 and myfaces core 1.1.1. Since they are sandbox, this might be an Apache issue though.
I will run some more tests this weekend and let you know if we can just port the tomahawk into the portal and leave jboss AS the way it is. If so, I will follow your suggestion and open the JIRA issues you mentioned.
Let me know if it is OK to proceed.
Kind regards,
dj -
5. Re: myfaces ExtensionsPhaseListener
dajevtic Jun 4, 2006 8:26 AM (in response to dajevtic)Hey! Disappointing news. The 1.1.2 release of tomahawk is not compatible, however when building the current svn-sources of 1.1.4-SNAPSHOT it DOES work. Even the tomahawk-sandbox examples work without modifications.
I guess we'll have to wait for the myfaces team to bring out a stable release of its new tomahawk version :-(
If someone doesn't care about using myfaces' new svn version of tomahawk, let me know, and I'll post the necessary configuration.
Regards,
dj -
6. Re: myfaces ExtensionsPhaseListener
prenger Jun 4, 2006 5:48 PM (in response to dajevtic)Hi.
I would really appreciate if you can post the configuration. I'm trying to use the schedule component and hope that your solution can help me. -
7. Re: myfaces ExtensionsPhaseListener
dajevtic Jun 5, 2006 7:38 AM (in response to dajevtic)I have opened an issue with tomahawk myfaces team to make the MyFacesExtensionFilter work with portals, however I didn't want to wait.
Ok! here goes for the schedule :-)
First of all do a svn checkout of the newest myfaces sources and build. schedule has left the sandbox and has been moved into tomahawk!
Remove all files inside the deploy/jbossweb-tomcat55.sar/jsf-libs directory and copy the following jars into it (I'm not sure if all are needed, but that's the ones who are inside the generated war-file of myfaces):antlr-2.7.2.jar
commons-beanutils-1.7.0.jar
commons-codec-1.3.jar
commons-collections-3.1.jar
commons-digester-1.6.jar
commons-el-1.0.jar
commons-fileupload-1.0.jar
commons-lang-2.1.jar
commons-logging-1.0.4.jar
commons-validator-1.2.0.jar
jstl-1.1.0.jar
myfaces-api-1.1.4-SNAPSHOT.jar
myfaces-impl-1.1.4-SNAPSHOT.jar
oro-2.0.8.jar
struts-1.2.8.jar
tomahawk-1.1.4-SNAPSHOT.jar
tomahawk-sandbox-1.1.4-SNAPSHOT.jar
xalan-2.5.1.jar
xml-apis-1.0.b2.jar
Remove tomahawk.jar and tomahawk.tld from the portal-core.war file of the jboss portal.
Change the deploy/jbossweb-tomcat55.sar/conf/web.xml inside jboss server to:<init-param> <description>MyFaces tlds</description> <param-name>tagLibJar0</param-name> <param-value>jsf-libs/myfaces-impl-1.1.4-SNAPSHOT.jar</param-value> </init-param> <init-param> <description>Sandbox tlds</description> <param-name>tagLibJar1</param-name> <param-value>jsf-libs/tomahawk-sandbox-1.1.4-SNAPSHOT.jar</param-value> </init-param> <init-param> <description>Tomahawk tlds</description> <param-name>tagLibJar2</param-name> <param-value>jsf-libs/tomahawk-1.1.4-SNAPSHOT.jar</param-value> </init-param>
As of now, jboss is running under the new myfaces version, rendering the management pages of the portal unusable.
To fix this you have to:
change the lineorg.apache.myfaces.tree2.CLIENT_SIDE_TOGGLE="#{false}"
inside the index.xhtml toclientSideToggle="false"
Then, surround any<h:commandLink>
tag with a<h:form>
tag where there is none (there are not too many). Now the management portlets work fine again.
Here is a snippet of how your own web.xml file should look like (be sure to also update the web.xml inside the portal-core.war of jboss portal):<filter> <filter-name>MyFacesExtensionsFilter</filter-name> <filter-class>org.apache.myfaces.webapp.filter.ExtensionsFilter</filter-class> <init-param> <description>Set the size limit for uploaded files. Format: 10 - 10 bytes 10k - 10 KB 10m - 10 MB 1g - 1 GB</description> <param-name>uploadMaxFileSize</param-name> <param-value>100m</param-value> </init-param> <init-param> <description>Set the threshold size - files below this limit are stored in memory, files above this limit are stored on disk. Format: 10 - 10 bytes 10k - 10 KB 10m - 10 MB 1g - 1 GB</description> <param-name>uploadThresholdSize</param-name> <param-value>100k</param-value> </init-param> </filter> <!-- extension mapping for serving page-independent resources (javascript, stylesheets, images, etc.) --> <filter-mapping> <filter-name>MyFacesExtensionsFilter</filter-name> <url-pattern>/faces/myFacesExtensionResource/*</url-pattern> </filter-mapping> <filter-mapping> <filter-name>MyFacesExtensionsFilter</filter-name> <url-pattern>*.jsf</url-pattern> </filter-mapping> <filter-mapping> <filter-name>MyFacesExtensionsFilter</filter-name> <url-pattern>/faces/*</url-pattern> </filter-mapping> <context-param> <param-name>org.apache.myfaces.ALLOW_JAVASCRIPT</param-name> <param-value>true</param-value> </context-param> <context-param> <param-name>org.apache.myfaces.DETECT_JAVASCRIPT</param-name> <param-value>false</param-value> </context-param> <context-param> <param-name>org.apache.myfaces.AUTO_SCROLL</param-name> <param-value>true</param-value> </context-param> <context-param> <param-name>org.apache.myfaces.PRETTY_HTML</param-name> <param-value>true</param-value> </context-param> <context-param> <param-name>javax.faces.DEFAULT_SUFFIX</param-name> <param-value>.xhtml</param-value> </context-param> <context-param> <param-name>org.apache.myfaces.CHECK_EXTENSIONS_FILTER</param-name> <param-value>false</param-value> </context-param> <!-- Must be commented out <servlet> <servlet-name>Faces Servlet</servlet-name> <servlet-class>javax.faces.webapp.FacesServlet</servlet-class> <load-on-startup>1</load-on-startup> </servlet> <servlet-mapping> <servlet-name>Faces Servlet</servlet-name> <url-pattern>*.jsf</url-pattern> </servlet-mapping>-->
Now for the faces-config.xml:<managed-bean> <managed-bean-name>ScheduleBrowserBean</managed-bean-name> <managed-bean-class>de.livemediagroup.ecatalog.web.ScheduleBrowserBean</managed-bean-class> <managed-bean-scope>request</managed-bean-scope> </managed-bean>
Your portlet.jsp should look something like this. I placed the .js files as a quick hack into the portal-core folder. I usually have them in a /static folder inside my apache web server:<%@ taglib uri="http://java.sun.com/jsf/html" prefix="h"%> <%@ taglib uri="http://java.sun.com/jsf/core" prefix="f"%> <%@ taglib uri="http://myfaces.apache.org/tomahawk" prefix="t"%> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> <title>Zeitplan</title> <link rel='stylesheet' type='text/css' href='/portal-core/style/default/schedule.css' /> <script type="text/javascript" src="/portal-core/style/default/schedule.js"><!-- //--></script> <script type="text/javascript" src="/portal-core/style/default/alphaAPI.js"><!-- //--></script> <script type="text/javascript" src="/portal-core/style/default/domLib.js"><!-- //--></script> <script type="text/javascript" src="/portal-core/style/default/domTT.js"><!-- //--></script> <script type="text/javascript" src="/portal-core/style/default/fadomatic.js"><!-- //--></script> </head> <body> <f:view> <h:form> <t:schedule value="#{ScheduleBrowserBean.model}" id="schedule" theme="default" tooltip="true" /> </h:form> </f:view> </body> </html>
One last small thing. If you are using facelets:
Add<tag> <tag-name>schedule</tag-name> <component> <component-type>org.apache.myfaces.Schedule</component-type> <renderer-type>org.apache.myfaces.Schedule</renderer-type> </component> </tag>
to the tomahawl.taglib.xml
I think that's all. Please try and let me know if it worked.
Since I am using jboss-seam I hope I haven't forgotten anything.
If I did, sorry, I'll post the remaining things if needed. -
8. Re: myfaces ExtensionsPhaseListener
prenger Jun 5, 2006 9:54 AM (in response to dajevtic)WHoooHooo! It's working. Thanks a lot. By the way, I am not using the portal, my project is a usual myfaces web application with the jboss 4.0.3 server, but this configuration works there either. You really helped me a lot with this.
-
9. Re: myfaces ExtensionsPhaseListener
dajevtic Jun 5, 2006 10:12 AM (in response to dajevtic)If you're not using the portal, then the extension listener will work perfectly. You don't need to include the .js files manually, because this will be done by DefaultAddResource :-)
Regards -
10. Re: myfaces ExtensionsPhaseListener
prenger Jun 5, 2006 11:20 AM (in response to dajevtic)That's correct. I also do not have to edit the index.xhtml or the Faces Servlet section in the web.xml.
-
11. Re: myfaces ExtensionsPhaseListener
dajevtic Jun 5, 2006 1:38 PM (in response to dajevtic)Exactly.
Needless to say: It works out of the box ;-) -
12. Re: myfaces ExtensionsPhaseListener
prenger Jun 15, 2006 2:48 PM (in response to dajevtic)Sorry, very disappointing news. I thought it's working, because the schedule is rendered correctly. But when I select an entry, I am kicked back to the start page of my application. I think this happens, because I forgot to include the (very important)
<filter-mapping>
<filter-name>MyFacesExtensionsFilter</filter-name>
<url-pattern>/faces/myFacesExtensionResource/*</url-pattern>
</filter-mapping>
in my web.xml
If I add this, I get a deployment exception. I hope you are still watching this topic, because this component is very essential for my application, which has to run on Jboss. I would be really great, if you could help me to get this working. -
13. Re: myfaces ExtensionsPhaseListener
dajevtic Jun 15, 2006 3:02 PM (in response to dajevtic)I might have an idea, why. Post the StackTrace and I'll take a look at it. Which version of myfaces are you using?
-
14. Re: myfaces ExtensionsPhaseListener
prenger Jun 15, 2006 3:46 PM (in response to dajevtic)Here we go:
21:45:52,109 ERROR [MainDeployer] Could not start deployment: file:/C:/jboss-4.0
.3SP1/server/default/deploy/CRM.war
org.jboss.deployment.DeploymentException: URL file:/C:/jboss-4.0.3SP1/server/def
ault/tmp/deploy/tmp16986CRM-exp.war/ deployment failed
at org.jboss.web.tomcat.tc5.TomcatDeployer.performDeployInternal(TomcatD
eployer.java:349)
at org.jboss.web.tomcat.tc5.TomcatDeployer.performDeploy(TomcatDeployer.
java:88)
at org.jboss.web.AbstractWebDeployer.start(AbstractWebDeployer.java:357)
at org.jboss.web.WebModule.startModule(WebModule.java:68)
at org.jboss.web.WebModule.startService(WebModule.java:46)
at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanS
upport.java:274)
at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMB
eanSupport.java:230)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatch
er.java:141)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:72)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.
java:245)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceControl
ler.java:943)
at $Proxy0.start(Unknown Source)
at org.jboss.system.ServiceController.start(ServiceController.java:428)
at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatch
er.java:141)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:72)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.
java:245)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:176)
at $Proxy30.start(Unknown Source)
at org.jboss.web.AbstractWebContainer.start(AbstractWebContainer.java:40
0)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatch
er.java:141)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractIntercept
or.java:118)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelM
BeanOperationInterceptor.java:127)
at org.jboss.mx.interceptor.DynamicInterceptor.invoke(DynamicInterceptor
.java:80)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.
java:245)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:176)
at $Proxy31.start(Unknown Source)
at org.jboss.deployment.MainDeployer.start(MainDeployer.java:989)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:790)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:753)
at sun.reflect.GeneratedMethodAccessor49.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatch
er.java:141)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractIntercept
or.java:118)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelM
BeanOperationInterceptor.java:127)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.
java:245)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:176)
at $Proxy9.deploy(Unknown Source)
at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymen
tScanner.java:319)
at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentS
canner.java:489)
at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.
doScan(AbstractDeploymentScanner.java:192)
at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.
loop(AbstractDeploymentScanner.java:203)
at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.
run(AbstractDeploymentScanner.java:182)