Re: [VOTE] release for myfaces core 2.0.0-beta
Cagatay, also if you continue to use old Facelets for some parts, you have to deploy it with your application. I'd be interested what the debugger tells you, who is trying to load the class etc. -Matthias On Fri, Jan 29, 2010 at 7:16 AM, Matthias Wessendorf mwessend...@gmail.com wrote: What said the Debugger regarding the 'why'? Sent from my iPod. On 29.01.2010, at 01:38, Cagatay Civici cagatay.civ...@gmail.com wrote: I see, I've double checked and all tag handlers in PrimeFaces use javax.faces.view.facelets.MethodRule, so can't figure out where that class load comes from. Also note that project was working with Mojarra jars. Anyway my vote is 0 now and I would like to hear other testers' results. On Jan 28, 2010, at 11:04 PM, Leonardo Uribe wrote: Hi Myfaces itself does not load com.sun.faces.facelets stuff. Note some facelets components before jsf 2.0 uses MethodRule instances to handle listener properties like t:schedule mouseListener or t:panelTabbedPane tabChangeListener. The problem should be on some custom tag handler inside PrimeFaces. What I did for tomahawk was copy MethodRule class from myfaces core to tomahawk and uses that one instead. regards, Leonardo Uribe 2010/1/28 Cagatay Civici cagatay.civ...@gmail.com Why does MyFaces-2.0 beta try to load com.sun.faces.facelets stuff? Because I've replaced mojarra 2.0.2 jars in PrimeFaces demo for testing with MyFaces 2.0 beta jar and got the following when trying to access a page. javax.faces.FacesException: java.lang.NoClassDefFoundError: com/sun/faces/facelets/tag/MethodRule at org.apache.myfaces.context.ExceptionHandlerImpl.wrap(ExceptionHandlerImpl.java:241) at org.apache.myfaces.context.ExceptionHandlerImpl.handle(ExceptionHandlerImpl.java:156) at org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:157) at org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:88) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:189) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.primefaces.examples.filter.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:32) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.primefaces.webapp.filter.FileUploadFilter.doFilter(FileUploadFilter.java:79) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:845) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447) at java.lang.Thread.run(Thread.java:637) Caused by: java.lang.NoClassDefFoundError: com/sun/faces/facelets/tag/MethodRule at java.lang.Class.getDeclaredConstructors0(Native Method) at java.lang.Class.privateGetDeclaredConstructors(Class.java:2389) at java.lang.Class.getConstructor0(Class.java:2699) at java.lang.Class.getConstructor(Class.java:1657) at org.apache.myfaces.view.facelets.tag.AbstractTagLibrary$UserComponentHandlerFactory.init(AbstractTagLibrary.java:506) at org.apache.myfaces.view.facelets.tag.AbstractTagLibrary.addComponent(AbstractTagLibrary.java:164) at org.apache.myfaces.view.facelets.compiler.TagLibraryConfig$TagLibraryImpl.putComponent(TagLibraryConfig.java:182) at org.apache.myfaces.view.facelets.compiler.TagLibraryConfig$LibraryHandler.endElement(TagLibraryConfig.java:422) at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.endElement(AbstractSAXParser.java:601) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanEndElement(XMLDocumentFragmentScannerImpl.java:1774) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2930) at
[jira] Resolved: (MYFACES-2516) Allow any child for f:event in the case of a PreRenderViewEvent
[ https://issues.apache.org/jira/browse/MYFACES-2516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bernd Bohmann resolved MYFACES-2516. Resolution: Fixed Fix Version/s: 2.0.0-beta-2 Allow any child for f:event in the case of a PreRenderViewEvent --- Key: MYFACES-2516 URL: https://issues.apache.org/jira/browse/MYFACES-2516 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Reporter: Bernd Bohmann Assignee: Bernd Bohmann Fix For: 2.0.0-beta-2 Attachments: MYFACES-2516.patch f:event currently only supports the UIViewRoot as a child for the PreRenderViewEvent -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] release for myfaces core 2.0.0-beta
Hi, I've tried testing the beta with DojoFaces, but even the most basic examples fail to work, e.g.: !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd; html xmlns=http://www.w3.org/1999/xhtml; xmlns:h=http://java.sun.com/jsf/html; xmlns:f=http://java.sun.com/jsf/core; xmlns:ui=http://java.sun.com/jsf/facelets; body h:form h:commandButton value=test / /h:form /body /html gives me: java.security.NoSuchAlgorithmException: Cannot find any provider supporting DES/ECB/PKCS5Padding I'm all in favour of another alpha, but I feel people won't give much credit if a beta doesn't do the basic stuff. Best regards, Ganesh Cagatay Civici schrieb: Anyway my vote is 0 now and I would like to hear other testers' results.
Re: [VOTE] release for myfaces core 2.0.0-beta
Hi, Maybe some of the required jars aren't included with this beta? This is where I took the beta from: http://people.apache.org/~lu4242/myfaces200betabinsrc/binaries/ I used the jars contained in the lib folder of: http://people.apache.org/~lu4242/myfaces200betabinsrc/binaries/myfaces-core-2.0.0-beta-bin.zip to replace Mojarra, no other jars are on my classpath, I'm running tomcat 6.0.20. Best regards, Ganesh Ganesh schrieb: Hi, I've tried testing the beta with DojoFaces, but even the most basic examples fail to work, e.g.: !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd; html xmlns=http://www.w3.org/1999/xhtml; xmlns:h=http://java.sun.com/jsf/html; xmlns:f=http://java.sun.com/jsf/core; xmlns:ui=http://java.sun.com/jsf/facelets; body h:form h:commandButton value=test / /h:form /body /html gives me: java.security.NoSuchAlgorithmException: Cannot find any provider supporting DES/ECB/PKCS5Padding I'm all in favour of another alpha, but I feel people won't give much credit if a beta doesn't do the basic stuff. Best regards, Ganesh Cagatay Civici schrieb: Anyway my vote is 0 now and I would like to hear other testers' results.
[jira] Commented: (EXTSCRIPT-45) Dependency scan not triggered in a corner case
[ https://issues.apache.org/jira/browse/EXTSCRIPT-45?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12806288#action_12806288 ] Werner Punz commented on EXTSCRIPT-45: -- works... seems to be a bug which has been fixed by the annotation scan cleanup which was done 3 weeks ago... I will close this one for now... Dependency scan not triggered in a corner case -- Key: EXTSCRIPT-45 URL: https://issues.apache.org/jira/browse/EXTSCRIPT-45 Project: MyFaces Extensions Scripting Issue Type: Bug Reporter: Werner Punz Assignee: Werner Punz Scenario, Renderer exists, cast is added, then the component is added afterwards without a restart in between - classcast error because the dependency is not added before the renderer is refreshed -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (EXTSCRIPT-45) Dependency scan not triggered in a corner case
[ https://issues.apache.org/jira/browse/EXTSCRIPT-45?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Werner Punz resolved EXTSCRIPT-45. -- Resolution: Fixed Dependency scan not triggered in a corner case -- Key: EXTSCRIPT-45 URL: https://issues.apache.org/jira/browse/EXTSCRIPT-45 Project: MyFaces Extensions Scripting Issue Type: Bug Reporter: Werner Punz Assignee: Werner Punz Scenario, Renderer exists, cast is added, then the component is added afterwards without a restart in between - classcast error because the dependency is not added before the renderer is refreshed -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] release for myfaces core 2.0.0-beta
Just by curiosity I looked this file: http://primefaces.googlecode.com/svn/core2/trunk/src/main/java/org/primefaces/component/autocomplete/AutoCompleteHandler.java it has an import to com.sun.faces.facelets.tag. MethodRule Yes, you're right, I've mixed MetaRule with MethodRule. On Fri, Jan 29, 2010 at 9:27 AM, Ganesh gan...@j4fry.org wrote: Hi, Maybe some of the required jars aren't included with this beta? This is where I took the beta from: http://people.apache.org/~lu4242/myfaces200betabinsrc/binaries/http://people.apache.org/%7Elu4242/myfaces200betabinsrc/binaries/ I used the jars contained in the lib folder of: http://people.apache.org/~lu4242/myfaces200betabinsrc/binaries/myfaces-core-2.0.0-beta-bin.ziphttp://people.apache.org/%7Elu4242/myfaces200betabinsrc/binaries/myfaces-core-2.0.0-beta-bin.zip to replace Mojarra, no other jars are on my classpath, I'm running tomcat 6.0.20. Best regards, Ganesh Ganesh schrieb: Hi, I've tried testing the beta with DojoFaces, but even the most basic examples fail to work, e.g.: !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd; html xmlns=http://www.w3.org/1999/xhtml; xmlns:h=http://java.sun.com/jsf/html; xmlns:f=http://java.sun.com/jsf/core; xmlns:ui=http://java.sun.com/jsf/facelets; body h:form h:commandButton value=test / /h:form /body /html gives me: java.security.NoSuchAlgorithmException: Cannot find any provider supporting DES/ECB/PKCS5Padding I'm all in favour of another alpha, but I feel people won't give much credit if a beta doesn't do the basic stuff. Best regards, Ganesh Cagatay Civici schrieb: Anyway my vote is 0 now and I would like to hear other testers' results. -- Cagatay Civici JSF EG | PrimeFaces Lead | Apache MyFaces PMC http://www.primefaces.org
[jira] Commented: (EXTSCRIPT-52) improve the examples
[ https://issues.apache.org/jira/browse/EXTSCRIPT-52?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12806291#action_12806291 ] Werner Punz commented on EXTSCRIPT-52: -- I will raise two new issues here first the one for the 2.0 implementation secondly the one for 1.2 so that we get a better split on things improve the examples Key: EXTSCRIPT-52 URL: https://issues.apache.org/jira/browse/EXTSCRIPT-52 Project: MyFaces Extensions Scripting Issue Type: Improvement Reporter: Werner Punz Assignee: Werner Punz Priority: Minor -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (EXTSCRIPT-52) improve the examples
[ https://issues.apache.org/jira/browse/EXTSCRIPT-52?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Werner Punz resolved EXTSCRIPT-52. -- Resolution: Fixed improve the examples Key: EXTSCRIPT-52 URL: https://issues.apache.org/jira/browse/EXTSCRIPT-52 Project: MyFaces Extensions Scripting Issue Type: Improvement Reporter: Werner Punz Assignee: Werner Punz Priority: Minor -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] release for myfaces core 2.0.0-beta
have you tried building it from the TAG ? the java security is not a 2.0 specific issue -Matthias On Fri, Jan 29, 2010 at 10:27 AM, Ganesh gan...@j4fry.org wrote: Hi, Maybe some of the required jars aren't included with this beta? This is where I took the beta from: http://people.apache.org/~lu4242/myfaces200betabinsrc/binaries/ I used the jars contained in the lib folder of: http://people.apache.org/~lu4242/myfaces200betabinsrc/binaries/myfaces-core-2.0.0-beta-bin.zip to replace Mojarra, no other jars are on my classpath, I'm running tomcat 6.0.20. Best regards, Ganesh Ganesh schrieb: Hi, I've tried testing the beta with DojoFaces, but even the most basic examples fail to work, e.g.: !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd; html xmlns=http://www.w3.org/1999/xhtml; xmlns:h=http://java.sun.com/jsf/html; xmlns:f=http://java.sun.com/jsf/core; xmlns:ui=http://java.sun.com/jsf/facelets; body h:form h:commandButton value=test / /h:form /body /html gives me: java.security.NoSuchAlgorithmException: Cannot find any provider supporting DES/ECB/PKCS5Padding I'm all in favour of another alpha, but I feel people won't give much credit if a beta doesn't do the basic stuff. Best regards, Ganesh Cagatay Civici schrieb: Anyway my vote is 0 now and I would like to hear other testers' results. -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
[jira] Created: (EXTSCRIPT-55) Improve the styling of the JSF 1.2 examples
Improve the styling of the JSF 1.2 examples --- Key: EXTSCRIPT-55 URL: https://issues.apache.org/jira/browse/EXTSCRIPT-55 Project: MyFaces Extensions Scripting Issue Type: Improvement Reporter: Werner Punz Assignee: Werner Punz We have a very good styling now for the 2.0 examples improve it for 1.0 possibly also by introducing weblets there for real on the fly resource updates -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (EXTSCRIPT-57) Improve the styling of the JSF 2.0 examples
Improve the styling of the JSF 2.0 examples --- Key: EXTSCRIPT-57 URL: https://issues.apache.org/jira/browse/EXTSCRIPT-57 Project: MyFaces Extensions Scripting Issue Type: Improvement Reporter: Werner Punz Assignee: Werner Punz Priority: Minor We almost are there but the styling still needs some fixes -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (EXTSCRIPT-56) Improve the styling of the JSF 2.0 examples
Improve the styling of the JSF 2.0 examples --- Key: EXTSCRIPT-56 URL: https://issues.apache.org/jira/browse/EXTSCRIPT-56 Project: MyFaces Extensions Scripting Issue Type: Improvement Reporter: Werner Punz Assignee: Werner Punz Priority: Minor We almost are there but the styling still needs some fixes -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] release for myfaces core 2.0.0-beta
Hello Cagatay, that's one of the issue when removing sorta APIs... In Trinidad, we moved the MethodRule to our implementation: http://svn.apache.org/viewvc?view=revisionrevision=897901 I think the question for the EG is why some (kinda) APIs were moved away... -Matthias On Fri, Jan 29, 2010 at 10:33 AM, Cagatay Civici cagatay.civ...@gmail.com wrote: Just by curiosity I looked this file: http://primefaces.googlecode.com/svn/core2/trunk/src/main/java/org/primefaces/component/autocomplete/AutoCompleteHandler.java it has an import to com.sun.faces.facelets.tag. MethodRule Yes, you're right, I've mixed MetaRule with MethodRule. On Fri, Jan 29, 2010 at 9:27 AM, Ganesh gan...@j4fry.org wrote: Hi, Maybe some of the required jars aren't included with this beta? This is where I took the beta from: http://people.apache.org/~lu4242/myfaces200betabinsrc/binaries/ I used the jars contained in the lib folder of: http://people.apache.org/~lu4242/myfaces200betabinsrc/binaries/myfaces-core-2.0.0-beta-bin.zip to replace Mojarra, no other jars are on my classpath, I'm running tomcat 6.0.20. Best regards, Ganesh Ganesh schrieb: Hi, I've tried testing the beta with DojoFaces, but even the most basic examples fail to work, e.g.: !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd; html xmlns=http://www.w3.org/1999/xhtml; xmlns:h=http://java.sun.com/jsf/html; xmlns:f=http://java.sun.com/jsf/core; xmlns:ui=http://java.sun.com/jsf/facelets; body h:form h:commandButton value=test / /h:form /body /html gives me: java.security.NoSuchAlgorithmException: Cannot find any provider supporting DES/ECB/PKCS5Padding I'm all in favour of another alpha, but I feel people won't give much credit if a beta doesn't do the basic stuff. Best regards, Ganesh Cagatay Civici schrieb: Anyway my vote is 0 now and I would like to hear other testers' results. -- Cagatay Civici JSF EG | PrimeFaces Lead | Apache MyFaces PMC http://www.primefaces.org -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [VOTE] release for myfaces core 2.0.0-beta
Yes, I don't understand why MethodRule stayed as impl specific. On Fri, Jan 29, 2010 at 9:45 AM, Matthias Wessendorf mat...@apache.orgwrote: Hello Cagatay, that's one of the issue when removing sorta APIs... In Trinidad, we moved the MethodRule to our implementation: http://svn.apache.org/viewvc?view=revisionrevision=897901 I think the question for the EG is why some (kinda) APIs were moved away... -Matthias On Fri, Jan 29, 2010 at 10:33 AM, Cagatay Civici cagatay.civ...@gmail.com wrote: Just by curiosity I looked this file: http://primefaces.googlecode.com/svn/core2/trunk/src/main/java/org/primefaces/component/autocomplete/AutoCompleteHandler.java it has an import to com.sun.faces.facelets.tag. MethodRule Yes, you're right, I've mixed MetaRule with MethodRule. On Fri, Jan 29, 2010 at 9:27 AM, Ganesh gan...@j4fry.org wrote: Hi, Maybe some of the required jars aren't included with this beta? This is where I took the beta from: http://people.apache.org/~lu4242/myfaces200betabinsrc/binaries/http://people.apache.org/%7Elu4242/myfaces200betabinsrc/binaries/ I used the jars contained in the lib folder of: http://people.apache.org/~lu4242/myfaces200betabinsrc/binaries/myfaces-core-2.0.0-beta-bin.ziphttp://people.apache.org/%7Elu4242/myfaces200betabinsrc/binaries/myfaces-core-2.0.0-beta-bin.zip to replace Mojarra, no other jars are on my classpath, I'm running tomcat 6.0.20. Best regards, Ganesh Ganesh schrieb: Hi, I've tried testing the beta with DojoFaces, but even the most basic examples fail to work, e.g.: !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd; html xmlns=http://www.w3.org/1999/xhtml; xmlns:h=http://java.sun.com/jsf/html; xmlns:f=http://java.sun.com/jsf/core; xmlns:ui=http://java.sun.com/jsf/facelets; body h:form h:commandButton value=test / /h:form /body /html gives me: java.security.NoSuchAlgorithmException: Cannot find any provider supporting DES/ECB/PKCS5Padding I'm all in favour of another alpha, but I feel people won't give much credit if a beta doesn't do the basic stuff. Best regards, Ganesh Cagatay Civici schrieb: Anyway my vote is 0 now and I would like to hear other testers' results. -- Cagatay Civici JSF EG | PrimeFaces Lead | Apache MyFaces PMC http://www.primefaces.org -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Cagatay Civici JSF EG | PrimeFaces Lead | Apache MyFaces PMC http://www.primefaces.org
Re: [VOTE] release for myfaces core 2.0.0-beta
That is a question for the EG, I guess. Not sure if they are around here ;-) On Fri, Jan 29, 2010 at 11:06 AM, Cagatay Civici cagatay.civ...@gmail.com wrote: Yes, I don't understand why MethodRule stayed as impl specific. On Fri, Jan 29, 2010 at 9:45 AM, Matthias Wessendorf mat...@apache.org wrote: Hello Cagatay, that's one of the issue when removing sorta APIs... In Trinidad, we moved the MethodRule to our implementation: http://svn.apache.org/viewvc?view=revisionrevision=897901 I think the question for the EG is why some (kinda) APIs were moved away... -Matthias On Fri, Jan 29, 2010 at 10:33 AM, Cagatay Civici cagatay.civ...@gmail.com wrote: Just by curiosity I looked this file: http://primefaces.googlecode.com/svn/core2/trunk/src/main/java/org/primefaces/component/autocomplete/AutoCompleteHandler.java it has an import to com.sun.faces.facelets.tag. MethodRule Yes, you're right, I've mixed MetaRule with MethodRule. On Fri, Jan 29, 2010 at 9:27 AM, Ganesh gan...@j4fry.org wrote: Hi, Maybe some of the required jars aren't included with this beta? This is where I took the beta from: http://people.apache.org/~lu4242/myfaces200betabinsrc/binaries/ I used the jars contained in the lib folder of: http://people.apache.org/~lu4242/myfaces200betabinsrc/binaries/myfaces-core-2.0.0-beta-bin.zip to replace Mojarra, no other jars are on my classpath, I'm running tomcat 6.0.20. Best regards, Ganesh Ganesh schrieb: Hi, I've tried testing the beta with DojoFaces, but even the most basic examples fail to work, e.g.: !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd; html xmlns=http://www.w3.org/1999/xhtml; xmlns:h=http://java.sun.com/jsf/html; xmlns:f=http://java.sun.com/jsf/core; xmlns:ui=http://java.sun.com/jsf/facelets; body h:form h:commandButton value=test / /h:form /body /html gives me: java.security.NoSuchAlgorithmException: Cannot find any provider supporting DES/ECB/PKCS5Padding I'm all in favour of another alpha, but I feel people won't give much credit if a beta doesn't do the basic stuff. Best regards, Ganesh Cagatay Civici schrieb: Anyway my vote is 0 now and I would like to hear other testers' results. -- Cagatay Civici JSF EG | PrimeFaces Lead | Apache MyFaces PMC http://www.primefaces.org -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Cagatay Civici JSF EG | PrimeFaces Lead | Apache MyFaces PMC http://www.primefaces.org -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [VOTE] release for myfaces core 2.0.0-beta
I've just asked this to EG. Also I think this discussion messed up the vote post. Sorry :) On Fri, Jan 29, 2010 at 10:31 AM, Matthias Wessendorf mat...@apache.orgwrote: That is a question for the EG, I guess. Not sure if they are around here ;-) On Fri, Jan 29, 2010 at 11:06 AM, Cagatay Civici cagatay.civ...@gmail.com wrote: Yes, I don't understand why MethodRule stayed as impl specific. On Fri, Jan 29, 2010 at 9:45 AM, Matthias Wessendorf mat...@apache.org wrote: Hello Cagatay, that's one of the issue when removing sorta APIs... In Trinidad, we moved the MethodRule to our implementation: http://svn.apache.org/viewvc?view=revisionrevision=897901 I think the question for the EG is why some (kinda) APIs were moved away... -Matthias On Fri, Jan 29, 2010 at 10:33 AM, Cagatay Civici cagatay.civ...@gmail.com wrote: Just by curiosity I looked this file: http://primefaces.googlecode.com/svn/core2/trunk/src/main/java/org/primefaces/component/autocomplete/AutoCompleteHandler.java it has an import to com.sun.faces.facelets.tag. MethodRule Yes, you're right, I've mixed MetaRule with MethodRule. On Fri, Jan 29, 2010 at 9:27 AM, Ganesh gan...@j4fry.org wrote: Hi, Maybe some of the required jars aren't included with this beta? This is where I took the beta from: http://people.apache.org/~lu4242/myfaces200betabinsrc/binaries/http://people.apache.org/%7Elu4242/myfaces200betabinsrc/binaries/ I used the jars contained in the lib folder of: http://people.apache.org/~lu4242/myfaces200betabinsrc/binaries/myfaces-core-2.0.0-beta-bin.ziphttp://people.apache.org/%7Elu4242/myfaces200betabinsrc/binaries/myfaces-core-2.0.0-beta-bin.zip to replace Mojarra, no other jars are on my classpath, I'm running tomcat 6.0.20. Best regards, Ganesh Ganesh schrieb: Hi, I've tried testing the beta with DojoFaces, but even the most basic examples fail to work, e.g.: !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd; html xmlns=http://www.w3.org/1999/xhtml; xmlns:h=http://java.sun.com/jsf/html; xmlns:f=http://java.sun.com/jsf/core; xmlns:ui=http://java.sun.com/jsf/facelets; body h:form h:commandButton value=test / /h:form /body /html gives me: java.security.NoSuchAlgorithmException: Cannot find any provider supporting DES/ECB/PKCS5Padding I'm all in favour of another alpha, but I feel people won't give much credit if a beta doesn't do the basic stuff. Best regards, Ganesh Cagatay Civici schrieb: Anyway my vote is 0 now and I would like to hear other testers' results. -- Cagatay Civici JSF EG | PrimeFaces Lead | Apache MyFaces PMC http://www.primefaces.org -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Cagatay Civici JSF EG | PrimeFaces Lead | Apache MyFaces PMC http://www.primefaces.org -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Cagatay Civici JSF EG | PrimeFaces Lead | Apache MyFaces PMC http://www.primefaces.org
[jira] Created: (MYFACES-2520) UnsupportedOperationException when launching Trinidad 2 w/ MyFaces2 in Jetty
UnsupportedOperationException when launching Trinidad 2 w/ MyFaces2 in Jetty Key: MYFACES-2520 URL: https://issues.apache.org/jira/browse/MYFACES-2520 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-beta-2 Reporter: Matthias Weßendorf SEVERE: java.lang.UnsupportedOperationException: This request class is an empty placeholder at org.apache.myfaces.application._SystemEventServletRequest$1.invoke(_SystemEventServletRequest.java:56) at $Proxy0.getContentType(Unknown Source) at javax.servlet.ServletRequestWrapper.getContentType(ServletRequestWrapper.java:145) at org.apache.myfaces.context.servlet.ServletExternalContextImpl.getRequestContentType(ServletExternalContextImpl.java:322) at org.apache.myfaces.trinidad.util.ExternalContextUtils.getContentType(ExternalContextUtils.java:341) at org.apache.myfaces.trinidadinternal.share.util.MultipartFormHandler.isMultipartRequest(MultipartFormHandler.java:57) at org.apache.myfaces.trinidadinternal.config.upload.FileUploadConfiguratorImpl.beginRequest(FileUploadConfiguratorImpl.java:109) at org.apache.myfaces.trinidadinternal.config.GlobalConfiguratorImpl._startConfiguratorServiceRequest(GlobalConfiguratorImpl.java:532) at org.apache.myfaces.trinidadinternal.config.GlobalConfiguratorImpl.beginRequest(GlobalConfiguratorImpl.java:211) at org.apache.myfaces.trinidadinternal.config.GlobalConfiguratorImpl.getExternalContext(GlobalConfiguratorImpl.java:327) at org.apache.myfaces.trinidadinternal.context.FacesContextFactoryImpl$CacheRenderKit.init(FacesContextFactoryImpl.java:90) at org.apache.myfaces.trinidadinternal.context.FacesContextFactoryImpl.getFacesContext(FacesContextFactoryImpl.java:68) at org.apache.myfaces.webapp.AbstractFacesInitializer.dispatchInitDestroyEvent(AbstractFacesInitializer.java:140) at org.apache.myfaces.webapp.AbstractFacesInitializer.initFaces(AbstractFacesInitializer.java:109) at org.apache.myfaces.webapp.StartupServletContextListener.contextInitialized(StartupServletContextListener.java:155) at org.mortbay.jetty.handler.ContextHandler.startContext(ContextHandler.java:548) at org.mortbay.jetty.servlet.Context.startContext(Context.java:136) at org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1250) at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:517) at org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:467) at org.mortbay.jetty.plugin.Jetty6PluginWebAppContext.doStart(Jetty6PluginWebAppContext.java:115) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152) at org.mortbay.jetty.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:156) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:130) at org.mortbay.jetty.Server.doStart(Server.java:224) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.plugin.Jetty6PluginServer.start(Jetty6PluginServer.java:132) at org.mortbay.jetty.plugin.AbstractJettyMojo.startJetty(AbstractJettyMojo.java:441) at org.mortbay.jetty.plugin.AbstractJettyMojo.execute(AbstractJettyMojo.java:383) at org.mortbay.jetty.plugin.AbstractJettyRunMojo.execute(AbstractJettyRunMojo.java:210) at org.mortbay.jetty.plugin.Jetty6RunMojo.execute(Jetty6RunMojo.java:184) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:569) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:539) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328) at
[jira] Commented: (MYFACES-2521) Parent not composite component or an instance of ClientBehaviorHolder: javax.faces.component.uiviewr...@19f5e3f
[
https://issues.apache.org/jira/browse/MYFACES-2521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12806297#action_12806297
]
Matthias Weßendorf commented on MYFACES-2521:
-
xhtml looks like:
?xml version=1.0 encoding=iso-8859-1 standalone=yes ?
!--
Licensed to the Apache Software Foundation (ASF) under one
or more contributor license agreements. See the NOTICE file
distributed with this work for additional information
regarding copyright ownership. The ASF licenses this file
to you under the Apache License, Version 2.0 (the
License); you may not use this file except in compliance
with the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing,
software distributed under the License is distributed on an
AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express or implied. See the License for the
specific language governing permissions and limitations
under the License.
--
ui:composition
xmlns:ui=http://java.sun.com/jsf/facelets;
xmlns:f=http://java.sun.com/jsf/core;
xmlns:tr=http://myfaces.apache.org/trinidad;
xmlns:trd=http://myfaces.apache.org/trinidad/demo;
xmlns:trh=http://myfaces.apache.org/trinidad/html;
tr:document id=d1 title=Client Behavior Support
trh:script
function checkPrevent()
{
var element = document.getElementById(sbc1);
if (element.checked)
{
alert(Form submission is being prevented by the behavior function);
return false;
}
}
function handleBlur(event)
{
var blurElement = document.getElementById(it1);
var updateElement = document.getElementById(it3);
while (updateElement.firstChild != null)
{
updateElement.removeChild(updateElement.firstChild);
}
updateElement.appendChild(document.createTextNode(blurElement.value));
}
/trh:script
tr:form id=f1
tr:panelHeader text=Client Behavior Support
tr:panelGroupLayout layout=scroll id=pgl1
f:facet name=separator
tr:separator /
/f:facet
tr:messages/
tr:panelHeader text=Command button and blur
tr:panelFormLayout id=pfl1
tr:inputText id=it1 label=Enter text:
value=#{requestScope.inputTextValue}
trd:invokeFunctionBehavior function=handleBlur event=blur
/
/tr:inputText
tr:selectBooleanCheckbox id=sbc1 label=Prevent submission
value=#{requestScope.preventSubmissionValue} /
tr:inputText readOnly=true id=it2
value=#{requestScope.inputTextValue}
label=Value that was entered: partialTriggers=cb1 cb2 /
tr:inputText readOnly=true id=it3
value=#{requestScope.noValue}
label=Value detected on blur: partialTriggers=cb1 cb2 /
tr:commandButton id=cb1 partialSubmit=true text=Submit
trd:invokeFunctionBehavior function=checkPrevent /
/tr:commandButton
tr:commandButton id=cb2 text=Submit via JSF Ajax
trd:invokeFunctionBehavior function=checkPrevent /
f:ajax render=it2 /
/tr:commandButton
/tr:panelFormLayout
/tr:panelHeader
tr:panelHeader text=Ajax during value change
tr:panelFormLayout id=pfl2
tr:inputText id=it4 label=Enter text:
value=#{requestScope.inputText2Value}
f:ajax render=it5 /
/tr:inputText
tr:inputText readOnly=true id=it5
value=#{requestScope.inputText2Value}
label=Value updated by ajax on value change: /
/tr:panelFormLayout
/tr:panelHeader
/tr:panelGroupLayout
/tr:panelHeader
/tr:form
/tr:document
/ui:composition
Parent not composite component or an instance of ClientBehaviorHolder:
javax.faces.component.uiviewr...@19f5e3f
---
Key: MYFACES-2521
URL: https://issues.apache.org/jira/browse/MYFACES-2521
Project: MyFaces Core
Issue Type: Bug
Components: JSR-314
Affects Versions: 2.0.0-alpha
Reporter: Matthias Weßendorf
running the Trinidad demo (clientBehavior demo), I see this exception:
javax.faces.view.facelets.TagException: /demos/clientBehaviorHolder.xhtmlat
line 59 and column 82 trd:invokeFunctionBehavior Parent not composite
component or an instance of ClientBehaviorHolder:
javax.faces.component.uiviewr...@19f5e3f
at
org.apache.myfaces.view.facelets.tag.jsf.BehaviorTagHandlerDelegate.apply(BehaviorTagHandlerDelegate.java:85)
at
javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:54)
at
[jira] Created: (MYFACES-2521) Parent not composite component or an instance of ClientBehaviorHolder: javax.faces.component.uiviewr...@19f5e3f
Parent not composite component or an instance of ClientBehaviorHolder: javax.faces.component.uiviewr...@19f5e3f --- Key: MYFACES-2521 URL: https://issues.apache.org/jira/browse/MYFACES-2521 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-alpha Reporter: Matthias Weßendorf running the Trinidad demo (clientBehavior demo), I see this exception: javax.faces.view.facelets.TagException: /demos/clientBehaviorHolder.xhtmlat line 59 and column 82 trd:invokeFunctionBehavior Parent not composite component or an instance of ClientBehaviorHolder: javax.faces.component.uiviewr...@19f5e3f at org.apache.myfaces.view.facelets.tag.jsf.BehaviorTagHandlerDelegate.apply(BehaviorTagHandlerDelegate.java:85) at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:54) at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:51) at org.apache.myfaces.view.facelets.tag.ui.CompositionHandler.apply(CompositionHandler.java:150) at org.apache.myfaces.view.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:57) at org.apache.myfaces.view.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:45) at org.apache.myfaces.view.facelets.impl.DefaultFacelet.apply(DefaultFacelet.java:103) at org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage.buildView(FaceletViewDeclarationLanguage.java:271) at org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:88) at org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:201) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:191) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1166) at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl._doFilterImpl(TrinidadFilterImpl.java:247) at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl.doFilter(TrinidadFilterImpl.java:157) at org.apache.myfaces.trinidad.webapp.TrinidadFilter.doFilter(TrinidadFilter.java:92) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:388) at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765) at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:418) at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230) at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114) at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152) at org.mortbay.jetty.Server.handle(Server.java:326) at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:536) at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:915) at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:539) at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212) at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:405) at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:409) at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] release for myfaces core 2.0.0-beta
I thought the release files should do. Why would building from the TAG make any difference? What do you mean with java security is not a 2.0 specific issue? Shouldn't the release contain all files needed to replace Mojarras api+impl? Best regards, Ganesh Matthias Wessendorf schrieb: have you tried building it from the TAG ? the java security is not a 2.0 specific issue -Matthias On Fri, Jan 29, 2010 at 10:27 AM, Ganesh gan...@j4fry.org wrote: Hi, Maybe some of the required jars aren't included with this beta? This is where I took the beta from: http://people.apache.org/~lu4242/myfaces200betabinsrc/binaries/ I used the jars contained in the lib folder of: http://people.apache.org/~lu4242/myfaces200betabinsrc/binaries/myfaces-core-2.0.0-beta-bin.zip to replace Mojarra, no other jars are on my classpath, I'm running tomcat 6.0.20. Best regards, Ganesh Ganesh schrieb: Hi, I've tried testing the beta with DojoFaces, but even the most basic examples fail to work, e.g.: !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd; html xmlns=http://www.w3.org/1999/xhtml; xmlns:h=http://java.sun.com/jsf/html; xmlns:f=http://java.sun.com/jsf/core; xmlns:ui=http://java.sun.com/jsf/facelets; body h:form h:commandButton value=test / /h:form /body /html gives me: java.security.NoSuchAlgorithmException: Cannot find any provider supporting DES/ECB/PKCS5Padding I'm all in favour of another alpha, but I feel people won't give much credit if a beta doesn't do the basic stuff. Best regards, Ganesh Cagatay Civici schrieb: Anyway my vote is 0 now and I would like to hear other testers' results.
Re: [VOTE] release for myfaces core 2.0.0-beta
I think it contains everything. What I mean is: Do you have some extra settings for java security ? E.g state encryption etc ? That was my question. What ever I am fine with calling this another alpha Regarding the exception: Please file a bug. If you have some more information about settings/enviorment and a complete stack trace, please post that too, as it may help ;-) -Matthias On Fri, Jan 29, 2010 at 11:55 AM, Ganesh gan...@j4fry.org wrote: I thought the release files should do. Why would building from the TAG make any difference? What do you mean with java security is not a 2.0 specific issue? Shouldn't the release contain all files needed to replace Mojarras api+impl? Best regards, Ganesh Matthias Wessendorf schrieb: have you tried building it from the TAG ? the java security is not a 2.0 specific issue -Matthias On Fri, Jan 29, 2010 at 10:27 AM, Ganesh gan...@j4fry.org wrote: Hi, Maybe some of the required jars aren't included with this beta? This is where I took the beta from: http://people.apache.org/~lu4242/myfaces200betabinsrc/binaries/ I used the jars contained in the lib folder of: http://people.apache.org/~lu4242/myfaces200betabinsrc/binaries/myfaces-core-2.0.0-beta-bin.zip to replace Mojarra, no other jars are on my classpath, I'm running tomcat 6.0.20. Best regards, Ganesh Ganesh schrieb: Hi, I've tried testing the beta with DojoFaces, but even the most basic examples fail to work, e.g.: !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd; html xmlns=http://www.w3.org/1999/xhtml; xmlns:h=http://java.sun.com/jsf/html; xmlns:f=http://java.sun.com/jsf/core; xmlns:ui=http://java.sun.com/jsf/facelets; body h:form h:commandButton value=test / /h:form /body /html gives me: java.security.NoSuchAlgorithmException: Cannot find any provider supporting DES/ECB/PKCS5Padding I'm all in favour of another alpha, but I feel people won't give much credit if a beta doesn't do the basic stuff. Best regards, Ganesh Cagatay Civici schrieb: Anyway my vote is 0 now and I would like to hear other testers' results. -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
[jira] Commented: (MYFACES-2520) UnsupportedOperationException when launching Trinidad 2 w/ MyFaces2 in Jetty
[ https://issues.apache.org/jira/browse/MYFACES-2520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12806310#action_12806310 ] Werner Punz commented on MYFACES-2520: -- Ok the problem here is we basically use an empty proxy here for the request and response object, because we are outside of any request here. The problem here probably is that the invoke of the proxy simply does too much... or too few, it throws an exception because the class itself is a placeholder... perfectly viable but if a user calls something on the request the invoke is automatically invoked throwing the error. Both things perfectly viable but both things in combination cause the error. What we either do is simply to replace the shell causing the error with an interface implementation which does nothing or we cover it from the outside aka HttpServletRequestWrapper. UnsupportedOperationException when launching Trinidad 2 w/ MyFaces2 in Jetty Key: MYFACES-2520 URL: https://issues.apache.org/jira/browse/MYFACES-2520 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-beta-2 Reporter: Matthias Weßendorf SEVERE: java.lang.UnsupportedOperationException: This request class is an empty placeholder at org.apache.myfaces.application._SystemEventServletRequest$1.invoke(_SystemEventServletRequest.java:56) at $Proxy0.getContentType(Unknown Source) at javax.servlet.ServletRequestWrapper.getContentType(ServletRequestWrapper.java:145) at org.apache.myfaces.context.servlet.ServletExternalContextImpl.getRequestContentType(ServletExternalContextImpl.java:322) at org.apache.myfaces.trinidad.util.ExternalContextUtils.getContentType(ExternalContextUtils.java:341) at org.apache.myfaces.trinidadinternal.share.util.MultipartFormHandler.isMultipartRequest(MultipartFormHandler.java:57) at org.apache.myfaces.trinidadinternal.config.upload.FileUploadConfiguratorImpl.beginRequest(FileUploadConfiguratorImpl.java:109) at org.apache.myfaces.trinidadinternal.config.GlobalConfiguratorImpl._startConfiguratorServiceRequest(GlobalConfiguratorImpl.java:532) at org.apache.myfaces.trinidadinternal.config.GlobalConfiguratorImpl.beginRequest(GlobalConfiguratorImpl.java:211) at org.apache.myfaces.trinidadinternal.config.GlobalConfiguratorImpl.getExternalContext(GlobalConfiguratorImpl.java:327) at org.apache.myfaces.trinidadinternal.context.FacesContextFactoryImpl$CacheRenderKit.init(FacesContextFactoryImpl.java:90) at org.apache.myfaces.trinidadinternal.context.FacesContextFactoryImpl.getFacesContext(FacesContextFactoryImpl.java:68) at org.apache.myfaces.webapp.AbstractFacesInitializer.dispatchInitDestroyEvent(AbstractFacesInitializer.java:140) at org.apache.myfaces.webapp.AbstractFacesInitializer.initFaces(AbstractFacesInitializer.java:109) at org.apache.myfaces.webapp.StartupServletContextListener.contextInitialized(StartupServletContextListener.java:155) at org.mortbay.jetty.handler.ContextHandler.startContext(ContextHandler.java:548) at org.mortbay.jetty.servlet.Context.startContext(Context.java:136) at org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1250) at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:517) at org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:467) at org.mortbay.jetty.plugin.Jetty6PluginWebAppContext.doStart(Jetty6PluginWebAppContext.java:115) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152) at org.mortbay.jetty.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:156) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:130) at org.mortbay.jetty.Server.doStart(Server.java:224) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.plugin.Jetty6PluginServer.start(Jetty6PluginServer.java:132) at org.mortbay.jetty.plugin.AbstractJettyMojo.startJetty(AbstractJettyMojo.java:441) at org.mortbay.jetty.plugin.AbstractJettyMojo.execute(AbstractJettyMojo.java:383) at org.mortbay.jetty.plugin.AbstractJettyRunMojo.execute(AbstractJettyRunMojo.java:210) at
[jira] Commented: (MYFACES-2520) UnsupportedOperationException when launching Trinidad 2 w/ MyFaces2 in Jetty
[ https://issues.apache.org/jira/browse/MYFACES-2520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12806311#action_12806311 ] Werner Punz commented on MYFACES-2520: -- As far as I can see this dummy class is only used within the dispatch for initDestroy... UnsupportedOperationException when launching Trinidad 2 w/ MyFaces2 in Jetty Key: MYFACES-2520 URL: https://issues.apache.org/jira/browse/MYFACES-2520 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-beta-2 Reporter: Matthias Weßendorf SEVERE: java.lang.UnsupportedOperationException: This request class is an empty placeholder at org.apache.myfaces.application._SystemEventServletRequest$1.invoke(_SystemEventServletRequest.java:56) at $Proxy0.getContentType(Unknown Source) at javax.servlet.ServletRequestWrapper.getContentType(ServletRequestWrapper.java:145) at org.apache.myfaces.context.servlet.ServletExternalContextImpl.getRequestContentType(ServletExternalContextImpl.java:322) at org.apache.myfaces.trinidad.util.ExternalContextUtils.getContentType(ExternalContextUtils.java:341) at org.apache.myfaces.trinidadinternal.share.util.MultipartFormHandler.isMultipartRequest(MultipartFormHandler.java:57) at org.apache.myfaces.trinidadinternal.config.upload.FileUploadConfiguratorImpl.beginRequest(FileUploadConfiguratorImpl.java:109) at org.apache.myfaces.trinidadinternal.config.GlobalConfiguratorImpl._startConfiguratorServiceRequest(GlobalConfiguratorImpl.java:532) at org.apache.myfaces.trinidadinternal.config.GlobalConfiguratorImpl.beginRequest(GlobalConfiguratorImpl.java:211) at org.apache.myfaces.trinidadinternal.config.GlobalConfiguratorImpl.getExternalContext(GlobalConfiguratorImpl.java:327) at org.apache.myfaces.trinidadinternal.context.FacesContextFactoryImpl$CacheRenderKit.init(FacesContextFactoryImpl.java:90) at org.apache.myfaces.trinidadinternal.context.FacesContextFactoryImpl.getFacesContext(FacesContextFactoryImpl.java:68) at org.apache.myfaces.webapp.AbstractFacesInitializer.dispatchInitDestroyEvent(AbstractFacesInitializer.java:140) at org.apache.myfaces.webapp.AbstractFacesInitializer.initFaces(AbstractFacesInitializer.java:109) at org.apache.myfaces.webapp.StartupServletContextListener.contextInitialized(StartupServletContextListener.java:155) at org.mortbay.jetty.handler.ContextHandler.startContext(ContextHandler.java:548) at org.mortbay.jetty.servlet.Context.startContext(Context.java:136) at org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1250) at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:517) at org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:467) at org.mortbay.jetty.plugin.Jetty6PluginWebAppContext.doStart(Jetty6PluginWebAppContext.java:115) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152) at org.mortbay.jetty.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:156) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:130) at org.mortbay.jetty.Server.doStart(Server.java:224) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.plugin.Jetty6PluginServer.start(Jetty6PluginServer.java:132) at org.mortbay.jetty.plugin.AbstractJettyMojo.startJetty(AbstractJettyMojo.java:441) at org.mortbay.jetty.plugin.AbstractJettyMojo.execute(AbstractJettyMojo.java:383) at org.mortbay.jetty.plugin.AbstractJettyRunMojo.execute(AbstractJettyRunMojo.java:210) at org.mortbay.jetty.plugin.Jetty6RunMojo.execute(Jetty6RunMojo.java:184) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:569) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:539) at
[jira] Issue Comment Edited: (MYFACES-2520) UnsupportedOperationException when launching Trinidad 2 w/ MyFaces2 in Jetty
[ https://issues.apache.org/jira/browse/MYFACES-2520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12806310#action_12806310 ] Werner Punz edited comment on MYFACES-2520 at 1/29/10 11:33 AM: Ok the problem here is we basically use an empty proxy here for the request and response object, because we are outside of any request here. The problem here probably is that the invoke of the proxy simply does too much... or too few, it throws an exception because the class itself is a placeholder... perfectly viable but if the system calls something on the request the invoke is automatically invoked throwing the error. Both things perfectly viable but both things in combination cause the error. What we either do is simply to replace the shell causing the error with an interface implementation which does nothing or we cover it from the outside aka HttpServletRequestWrapper. was (Author: werpu): Ok the problem here is we basically use an empty proxy here for the request and response object, because we are outside of any request here. The problem here probably is that the invoke of the proxy simply does too much... or too few, it throws an exception because the class itself is a placeholder... perfectly viable but if a user calls something on the request the invoke is automatically invoked throwing the error. Both things perfectly viable but both things in combination cause the error. What we either do is simply to replace the shell causing the error with an interface implementation which does nothing or we cover it from the outside aka HttpServletRequestWrapper. UnsupportedOperationException when launching Trinidad 2 w/ MyFaces2 in Jetty Key: MYFACES-2520 URL: https://issues.apache.org/jira/browse/MYFACES-2520 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-beta-2 Reporter: Matthias Weßendorf SEVERE: java.lang.UnsupportedOperationException: This request class is an empty placeholder at org.apache.myfaces.application._SystemEventServletRequest$1.invoke(_SystemEventServletRequest.java:56) at $Proxy0.getContentType(Unknown Source) at javax.servlet.ServletRequestWrapper.getContentType(ServletRequestWrapper.java:145) at org.apache.myfaces.context.servlet.ServletExternalContextImpl.getRequestContentType(ServletExternalContextImpl.java:322) at org.apache.myfaces.trinidad.util.ExternalContextUtils.getContentType(ExternalContextUtils.java:341) at org.apache.myfaces.trinidadinternal.share.util.MultipartFormHandler.isMultipartRequest(MultipartFormHandler.java:57) at org.apache.myfaces.trinidadinternal.config.upload.FileUploadConfiguratorImpl.beginRequest(FileUploadConfiguratorImpl.java:109) at org.apache.myfaces.trinidadinternal.config.GlobalConfiguratorImpl._startConfiguratorServiceRequest(GlobalConfiguratorImpl.java:532) at org.apache.myfaces.trinidadinternal.config.GlobalConfiguratorImpl.beginRequest(GlobalConfiguratorImpl.java:211) at org.apache.myfaces.trinidadinternal.config.GlobalConfiguratorImpl.getExternalContext(GlobalConfiguratorImpl.java:327) at org.apache.myfaces.trinidadinternal.context.FacesContextFactoryImpl$CacheRenderKit.init(FacesContextFactoryImpl.java:90) at org.apache.myfaces.trinidadinternal.context.FacesContextFactoryImpl.getFacesContext(FacesContextFactoryImpl.java:68) at org.apache.myfaces.webapp.AbstractFacesInitializer.dispatchInitDestroyEvent(AbstractFacesInitializer.java:140) at org.apache.myfaces.webapp.AbstractFacesInitializer.initFaces(AbstractFacesInitializer.java:109) at org.apache.myfaces.webapp.StartupServletContextListener.contextInitialized(StartupServletContextListener.java:155) at org.mortbay.jetty.handler.ContextHandler.startContext(ContextHandler.java:548) at org.mortbay.jetty.servlet.Context.startContext(Context.java:136) at org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1250) at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:517) at org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:467) at org.mortbay.jetty.plugin.Jetty6PluginWebAppContext.doStart(Jetty6PluginWebAppContext.java:115) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152) at org.mortbay.jetty.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:156) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at
[jira] Issue Comment Edited: (MYFACES-2520) UnsupportedOperationException when launching Trinidad 2 w/ MyFaces2 in Jetty
[ https://issues.apache.org/jira/browse/MYFACES-2520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12806311#action_12806311 ] Werner Punz edited comment on MYFACES-2520 at 1/29/10 11:35 AM: Ok another analysis, trinidad probably uses the system event, but that one is called outside of any real request (understandable since the destroy etc... is request independend) was (Author: werpu): As far as I can see this dummy class is only used within the dispatch for initDestroy... UnsupportedOperationException when launching Trinidad 2 w/ MyFaces2 in Jetty Key: MYFACES-2520 URL: https://issues.apache.org/jira/browse/MYFACES-2520 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-beta-2 Reporter: Matthias Weßendorf SEVERE: java.lang.UnsupportedOperationException: This request class is an empty placeholder at org.apache.myfaces.application._SystemEventServletRequest$1.invoke(_SystemEventServletRequest.java:56) at $Proxy0.getContentType(Unknown Source) at javax.servlet.ServletRequestWrapper.getContentType(ServletRequestWrapper.java:145) at org.apache.myfaces.context.servlet.ServletExternalContextImpl.getRequestContentType(ServletExternalContextImpl.java:322) at org.apache.myfaces.trinidad.util.ExternalContextUtils.getContentType(ExternalContextUtils.java:341) at org.apache.myfaces.trinidadinternal.share.util.MultipartFormHandler.isMultipartRequest(MultipartFormHandler.java:57) at org.apache.myfaces.trinidadinternal.config.upload.FileUploadConfiguratorImpl.beginRequest(FileUploadConfiguratorImpl.java:109) at org.apache.myfaces.trinidadinternal.config.GlobalConfiguratorImpl._startConfiguratorServiceRequest(GlobalConfiguratorImpl.java:532) at org.apache.myfaces.trinidadinternal.config.GlobalConfiguratorImpl.beginRequest(GlobalConfiguratorImpl.java:211) at org.apache.myfaces.trinidadinternal.config.GlobalConfiguratorImpl.getExternalContext(GlobalConfiguratorImpl.java:327) at org.apache.myfaces.trinidadinternal.context.FacesContextFactoryImpl$CacheRenderKit.init(FacesContextFactoryImpl.java:90) at org.apache.myfaces.trinidadinternal.context.FacesContextFactoryImpl.getFacesContext(FacesContextFactoryImpl.java:68) at org.apache.myfaces.webapp.AbstractFacesInitializer.dispatchInitDestroyEvent(AbstractFacesInitializer.java:140) at org.apache.myfaces.webapp.AbstractFacesInitializer.initFaces(AbstractFacesInitializer.java:109) at org.apache.myfaces.webapp.StartupServletContextListener.contextInitialized(StartupServletContextListener.java:155) at org.mortbay.jetty.handler.ContextHandler.startContext(ContextHandler.java:548) at org.mortbay.jetty.servlet.Context.startContext(Context.java:136) at org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1250) at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:517) at org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:467) at org.mortbay.jetty.plugin.Jetty6PluginWebAppContext.doStart(Jetty6PluginWebAppContext.java:115) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152) at org.mortbay.jetty.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:156) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:130) at org.mortbay.jetty.Server.doStart(Server.java:224) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.plugin.Jetty6PluginServer.start(Jetty6PluginServer.java:132) at org.mortbay.jetty.plugin.AbstractJettyMojo.startJetty(AbstractJettyMojo.java:441) at org.mortbay.jetty.plugin.AbstractJettyMojo.execute(AbstractJettyMojo.java:383) at org.mortbay.jetty.plugin.AbstractJettyRunMojo.execute(AbstractJettyRunMojo.java:210) at org.mortbay.jetty.plugin.Jetty6RunMojo.execute(Jetty6RunMojo.java:184) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694) at
[jira] Issue Comment Edited: (MYFACES-2520) UnsupportedOperationException when launching Trinidad 2 w/ MyFaces2 in Jetty
[ https://issues.apache.org/jira/browse/MYFACES-2520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12806311#action_12806311 ] Werner Punz edited comment on MYFACES-2520 at 1/29/10 11:36 AM: Ok another analysis, trinidad probably uses the system event, but that one is called outside of any real request (understandable since the destroy etc... is request independend) and getContentType then runs into this issue, unfortunately. was (Author: werpu): Ok another analysis, trinidad probably uses the system event, but that one is called outside of any real request (understandable since the destroy etc... is request independend) UnsupportedOperationException when launching Trinidad 2 w/ MyFaces2 in Jetty Key: MYFACES-2520 URL: https://issues.apache.org/jira/browse/MYFACES-2520 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-beta-2 Reporter: Matthias Weßendorf SEVERE: java.lang.UnsupportedOperationException: This request class is an empty placeholder at org.apache.myfaces.application._SystemEventServletRequest$1.invoke(_SystemEventServletRequest.java:56) at $Proxy0.getContentType(Unknown Source) at javax.servlet.ServletRequestWrapper.getContentType(ServletRequestWrapper.java:145) at org.apache.myfaces.context.servlet.ServletExternalContextImpl.getRequestContentType(ServletExternalContextImpl.java:322) at org.apache.myfaces.trinidad.util.ExternalContextUtils.getContentType(ExternalContextUtils.java:341) at org.apache.myfaces.trinidadinternal.share.util.MultipartFormHandler.isMultipartRequest(MultipartFormHandler.java:57) at org.apache.myfaces.trinidadinternal.config.upload.FileUploadConfiguratorImpl.beginRequest(FileUploadConfiguratorImpl.java:109) at org.apache.myfaces.trinidadinternal.config.GlobalConfiguratorImpl._startConfiguratorServiceRequest(GlobalConfiguratorImpl.java:532) at org.apache.myfaces.trinidadinternal.config.GlobalConfiguratorImpl.beginRequest(GlobalConfiguratorImpl.java:211) at org.apache.myfaces.trinidadinternal.config.GlobalConfiguratorImpl.getExternalContext(GlobalConfiguratorImpl.java:327) at org.apache.myfaces.trinidadinternal.context.FacesContextFactoryImpl$CacheRenderKit.init(FacesContextFactoryImpl.java:90) at org.apache.myfaces.trinidadinternal.context.FacesContextFactoryImpl.getFacesContext(FacesContextFactoryImpl.java:68) at org.apache.myfaces.webapp.AbstractFacesInitializer.dispatchInitDestroyEvent(AbstractFacesInitializer.java:140) at org.apache.myfaces.webapp.AbstractFacesInitializer.initFaces(AbstractFacesInitializer.java:109) at org.apache.myfaces.webapp.StartupServletContextListener.contextInitialized(StartupServletContextListener.java:155) at org.mortbay.jetty.handler.ContextHandler.startContext(ContextHandler.java:548) at org.mortbay.jetty.servlet.Context.startContext(Context.java:136) at org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1250) at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:517) at org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:467) at org.mortbay.jetty.plugin.Jetty6PluginWebAppContext.doStart(Jetty6PluginWebAppContext.java:115) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152) at org.mortbay.jetty.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:156) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:130) at org.mortbay.jetty.Server.doStart(Server.java:224) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.plugin.Jetty6PluginServer.start(Jetty6PluginServer.java:132) at org.mortbay.jetty.plugin.AbstractJettyMojo.startJetty(AbstractJettyMojo.java:441) at org.mortbay.jetty.plugin.AbstractJettyMojo.execute(AbstractJettyMojo.java:383) at org.mortbay.jetty.plugin.AbstractJettyRunMojo.execute(AbstractJettyRunMojo.java:210) at org.mortbay.jetty.plugin.Jetty6RunMojo.execute(Jetty6RunMojo.java:184) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490) at
[jira] Issue Comment Edited: (MYFACES-2520) UnsupportedOperationException when launching Trinidad 2 w/ MyFaces2 in Jetty
[ https://issues.apache.org/jira/browse/MYFACES-2520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12806311#action_12806311 ] Werner Punz edited comment on MYFACES-2520 at 1/29/10 11:38 AM: Ok another analysis, trinidad probably uses the system event, but that one is called outside of any real request (understandable since the destroy etc... is request independend) and getContentType then runs into this issue, unfortunately. One solution would be to delegate what is possible to the servlet context object so that we at least can cover parts of the servlet functionality, the getContentType for instance would be implementable by rerouting against getMimeType of the context object. was (Author: werpu): Ok another analysis, trinidad probably uses the system event, but that one is called outside of any real request (understandable since the destroy etc... is request independend) and getContentType then runs into this issue, unfortunately. UnsupportedOperationException when launching Trinidad 2 w/ MyFaces2 in Jetty Key: MYFACES-2520 URL: https://issues.apache.org/jira/browse/MYFACES-2520 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-beta-2 Reporter: Matthias Weßendorf SEVERE: java.lang.UnsupportedOperationException: This request class is an empty placeholder at org.apache.myfaces.application._SystemEventServletRequest$1.invoke(_SystemEventServletRequest.java:56) at $Proxy0.getContentType(Unknown Source) at javax.servlet.ServletRequestWrapper.getContentType(ServletRequestWrapper.java:145) at org.apache.myfaces.context.servlet.ServletExternalContextImpl.getRequestContentType(ServletExternalContextImpl.java:322) at org.apache.myfaces.trinidad.util.ExternalContextUtils.getContentType(ExternalContextUtils.java:341) at org.apache.myfaces.trinidadinternal.share.util.MultipartFormHandler.isMultipartRequest(MultipartFormHandler.java:57) at org.apache.myfaces.trinidadinternal.config.upload.FileUploadConfiguratorImpl.beginRequest(FileUploadConfiguratorImpl.java:109) at org.apache.myfaces.trinidadinternal.config.GlobalConfiguratorImpl._startConfiguratorServiceRequest(GlobalConfiguratorImpl.java:532) at org.apache.myfaces.trinidadinternal.config.GlobalConfiguratorImpl.beginRequest(GlobalConfiguratorImpl.java:211) at org.apache.myfaces.trinidadinternal.config.GlobalConfiguratorImpl.getExternalContext(GlobalConfiguratorImpl.java:327) at org.apache.myfaces.trinidadinternal.context.FacesContextFactoryImpl$CacheRenderKit.init(FacesContextFactoryImpl.java:90) at org.apache.myfaces.trinidadinternal.context.FacesContextFactoryImpl.getFacesContext(FacesContextFactoryImpl.java:68) at org.apache.myfaces.webapp.AbstractFacesInitializer.dispatchInitDestroyEvent(AbstractFacesInitializer.java:140) at org.apache.myfaces.webapp.AbstractFacesInitializer.initFaces(AbstractFacesInitializer.java:109) at org.apache.myfaces.webapp.StartupServletContextListener.contextInitialized(StartupServletContextListener.java:155) at org.mortbay.jetty.handler.ContextHandler.startContext(ContextHandler.java:548) at org.mortbay.jetty.servlet.Context.startContext(Context.java:136) at org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1250) at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:517) at org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:467) at org.mortbay.jetty.plugin.Jetty6PluginWebAppContext.doStart(Jetty6PluginWebAppContext.java:115) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152) at org.mortbay.jetty.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:156) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:130) at org.mortbay.jetty.Server.doStart(Server.java:224) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.plugin.Jetty6PluginServer.start(Jetty6PluginServer.java:132) at org.mortbay.jetty.plugin.AbstractJettyMojo.startJetty(AbstractJettyMojo.java:441) at org.mortbay.jetty.plugin.AbstractJettyMojo.execute(AbstractJettyMojo.java:383) at
[jira] Issue Comment Edited: (MYFACES-2520) UnsupportedOperationException when launching Trinidad 2 w/ MyFaces2 in Jetty
[ https://issues.apache.org/jira/browse/MYFACES-2520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12806311#action_12806311 ] Werner Punz edited comment on MYFACES-2520 at 1/29/10 11:42 AM: Ok another analysis, trinidad probably uses the system event, but that one is called outside of any real request (understandable since the destroy etc... is request independend) and getContentType then runs into this issue, unfortunately. One solution would be to delegate what is possible to the servlet context object so that we at least can cover parts of the servlet functionality, In this case getRequestContentType is questionable since we probably dont even have a request here since we still are in the init part of the system. was (Author: werpu): Ok another analysis, trinidad probably uses the system event, but that one is called outside of any real request (understandable since the destroy etc... is request independend) and getContentType then runs into this issue, unfortunately. One solution would be to delegate what is possible to the servlet context object so that we at least can cover parts of the servlet functionality, the getContentType for instance would be implementable by rerouting against getMimeType of the context object. UnsupportedOperationException when launching Trinidad 2 w/ MyFaces2 in Jetty Key: MYFACES-2520 URL: https://issues.apache.org/jira/browse/MYFACES-2520 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-beta-2 Reporter: Matthias Weßendorf SEVERE: java.lang.UnsupportedOperationException: This request class is an empty placeholder at org.apache.myfaces.application._SystemEventServletRequest$1.invoke(_SystemEventServletRequest.java:56) at $Proxy0.getContentType(Unknown Source) at javax.servlet.ServletRequestWrapper.getContentType(ServletRequestWrapper.java:145) at org.apache.myfaces.context.servlet.ServletExternalContextImpl.getRequestContentType(ServletExternalContextImpl.java:322) at org.apache.myfaces.trinidad.util.ExternalContextUtils.getContentType(ExternalContextUtils.java:341) at org.apache.myfaces.trinidadinternal.share.util.MultipartFormHandler.isMultipartRequest(MultipartFormHandler.java:57) at org.apache.myfaces.trinidadinternal.config.upload.FileUploadConfiguratorImpl.beginRequest(FileUploadConfiguratorImpl.java:109) at org.apache.myfaces.trinidadinternal.config.GlobalConfiguratorImpl._startConfiguratorServiceRequest(GlobalConfiguratorImpl.java:532) at org.apache.myfaces.trinidadinternal.config.GlobalConfiguratorImpl.beginRequest(GlobalConfiguratorImpl.java:211) at org.apache.myfaces.trinidadinternal.config.GlobalConfiguratorImpl.getExternalContext(GlobalConfiguratorImpl.java:327) at org.apache.myfaces.trinidadinternal.context.FacesContextFactoryImpl$CacheRenderKit.init(FacesContextFactoryImpl.java:90) at org.apache.myfaces.trinidadinternal.context.FacesContextFactoryImpl.getFacesContext(FacesContextFactoryImpl.java:68) at org.apache.myfaces.webapp.AbstractFacesInitializer.dispatchInitDestroyEvent(AbstractFacesInitializer.java:140) at org.apache.myfaces.webapp.AbstractFacesInitializer.initFaces(AbstractFacesInitializer.java:109) at org.apache.myfaces.webapp.StartupServletContextListener.contextInitialized(StartupServletContextListener.java:155) at org.mortbay.jetty.handler.ContextHandler.startContext(ContextHandler.java:548) at org.mortbay.jetty.servlet.Context.startContext(Context.java:136) at org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1250) at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:517) at org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:467) at org.mortbay.jetty.plugin.Jetty6PluginWebAppContext.doStart(Jetty6PluginWebAppContext.java:115) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152) at org.mortbay.jetty.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:156) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:130) at org.mortbay.jetty.Server.doStart(Server.java:224) at
[jira] Issue Comment Edited: (MYFACES-2520) UnsupportedOperationException when launching Trinidad 2 w/ MyFaces2 in Jetty
[ https://issues.apache.org/jira/browse/MYFACES-2520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12806311#action_12806311 ] Werner Punz edited comment on MYFACES-2520 at 1/29/10 11:44 AM: Ok another analysis, trinidad probably uses the system event, but that one is called outside of any real request (understandable since the destroy etc... is request independend) and getContentType then runs into this issue, unfortunately. One solution would be to delegate what is possible to the servlet context object so that we at least can cover parts of the servlet functionality, In this case getRequestContentType is questionable since we probably dont even have a request here since we still are in the init part of the system. It would be interesting to see how the RI behaves in this case so that we have the same behavior here.. This is definitely one shady area of the source where we should absolutely behave the same as the RI. was (Author: werpu): Ok another analysis, trinidad probably uses the system event, but that one is called outside of any real request (understandable since the destroy etc... is request independend) and getContentType then runs into this issue, unfortunately. One solution would be to delegate what is possible to the servlet context object so that we at least can cover parts of the servlet functionality, In this case getRequestContentType is questionable since we probably dont even have a request here since we still are in the init part of the system. UnsupportedOperationException when launching Trinidad 2 w/ MyFaces2 in Jetty Key: MYFACES-2520 URL: https://issues.apache.org/jira/browse/MYFACES-2520 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-beta-2 Reporter: Matthias Weßendorf SEVERE: java.lang.UnsupportedOperationException: This request class is an empty placeholder at org.apache.myfaces.application._SystemEventServletRequest$1.invoke(_SystemEventServletRequest.java:56) at $Proxy0.getContentType(Unknown Source) at javax.servlet.ServletRequestWrapper.getContentType(ServletRequestWrapper.java:145) at org.apache.myfaces.context.servlet.ServletExternalContextImpl.getRequestContentType(ServletExternalContextImpl.java:322) at org.apache.myfaces.trinidad.util.ExternalContextUtils.getContentType(ExternalContextUtils.java:341) at org.apache.myfaces.trinidadinternal.share.util.MultipartFormHandler.isMultipartRequest(MultipartFormHandler.java:57) at org.apache.myfaces.trinidadinternal.config.upload.FileUploadConfiguratorImpl.beginRequest(FileUploadConfiguratorImpl.java:109) at org.apache.myfaces.trinidadinternal.config.GlobalConfiguratorImpl._startConfiguratorServiceRequest(GlobalConfiguratorImpl.java:532) at org.apache.myfaces.trinidadinternal.config.GlobalConfiguratorImpl.beginRequest(GlobalConfiguratorImpl.java:211) at org.apache.myfaces.trinidadinternal.config.GlobalConfiguratorImpl.getExternalContext(GlobalConfiguratorImpl.java:327) at org.apache.myfaces.trinidadinternal.context.FacesContextFactoryImpl$CacheRenderKit.init(FacesContextFactoryImpl.java:90) at org.apache.myfaces.trinidadinternal.context.FacesContextFactoryImpl.getFacesContext(FacesContextFactoryImpl.java:68) at org.apache.myfaces.webapp.AbstractFacesInitializer.dispatchInitDestroyEvent(AbstractFacesInitializer.java:140) at org.apache.myfaces.webapp.AbstractFacesInitializer.initFaces(AbstractFacesInitializer.java:109) at org.apache.myfaces.webapp.StartupServletContextListener.contextInitialized(StartupServletContextListener.java:155) at org.mortbay.jetty.handler.ContextHandler.startContext(ContextHandler.java:548) at org.mortbay.jetty.servlet.Context.startContext(Context.java:136) at org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1250) at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:517) at org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:467) at org.mortbay.jetty.plugin.Jetty6PluginWebAppContext.doStart(Jetty6PluginWebAppContext.java:115) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152) at org.mortbay.jetty.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:156) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152) at
[jira] Issue Comment Edited: (MYFACES-2520) UnsupportedOperationException when launching Trinidad 2 w/ MyFaces2 in Jetty
[ https://issues.apache.org/jira/browse/MYFACES-2520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12806311#action_12806311 ] Werner Punz edited comment on MYFACES-2520 at 1/29/10 11:46 AM: Ok another analysis, trinidad probably uses the system event, but that one is called outside of any real request (understandable since the destroy etc... is request independend) and then tries to determine the request content type, then runs into this issue, unfortunately. One solution would be to delegate what is possible to the servlet context object so that we at least can cover parts of the servlet functionality, or simply return a default value (null?) here. In this case calling getRequestContentType is questionable since we dont even have a request here since we still are in the init part of the system. It would be interesting to see how the RI behaves in this case so that we have the same behavior here.. This is definitely one shady area of the source where we should absolutely behave the same as the RI. was (Author: werpu): Ok another analysis, trinidad probably uses the system event, but that one is called outside of any real request (understandable since the destroy etc... is request independend) and getContentType then runs into this issue, unfortunately. One solution would be to delegate what is possible to the servlet context object so that we at least can cover parts of the servlet functionality, In this case getRequestContentType is questionable since we probably dont even have a request here since we still are in the init part of the system. It would be interesting to see how the RI behaves in this case so that we have the same behavior here.. This is definitely one shady area of the source where we should absolutely behave the same as the RI. UnsupportedOperationException when launching Trinidad 2 w/ MyFaces2 in Jetty Key: MYFACES-2520 URL: https://issues.apache.org/jira/browse/MYFACES-2520 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-beta-2 Reporter: Matthias Weßendorf SEVERE: java.lang.UnsupportedOperationException: This request class is an empty placeholder at org.apache.myfaces.application._SystemEventServletRequest$1.invoke(_SystemEventServletRequest.java:56) at $Proxy0.getContentType(Unknown Source) at javax.servlet.ServletRequestWrapper.getContentType(ServletRequestWrapper.java:145) at org.apache.myfaces.context.servlet.ServletExternalContextImpl.getRequestContentType(ServletExternalContextImpl.java:322) at org.apache.myfaces.trinidad.util.ExternalContextUtils.getContentType(ExternalContextUtils.java:341) at org.apache.myfaces.trinidadinternal.share.util.MultipartFormHandler.isMultipartRequest(MultipartFormHandler.java:57) at org.apache.myfaces.trinidadinternal.config.upload.FileUploadConfiguratorImpl.beginRequest(FileUploadConfiguratorImpl.java:109) at org.apache.myfaces.trinidadinternal.config.GlobalConfiguratorImpl._startConfiguratorServiceRequest(GlobalConfiguratorImpl.java:532) at org.apache.myfaces.trinidadinternal.config.GlobalConfiguratorImpl.beginRequest(GlobalConfiguratorImpl.java:211) at org.apache.myfaces.trinidadinternal.config.GlobalConfiguratorImpl.getExternalContext(GlobalConfiguratorImpl.java:327) at org.apache.myfaces.trinidadinternal.context.FacesContextFactoryImpl$CacheRenderKit.init(FacesContextFactoryImpl.java:90) at org.apache.myfaces.trinidadinternal.context.FacesContextFactoryImpl.getFacesContext(FacesContextFactoryImpl.java:68) at org.apache.myfaces.webapp.AbstractFacesInitializer.dispatchInitDestroyEvent(AbstractFacesInitializer.java:140) at org.apache.myfaces.webapp.AbstractFacesInitializer.initFaces(AbstractFacesInitializer.java:109) at org.apache.myfaces.webapp.StartupServletContextListener.contextInitialized(StartupServletContextListener.java:155) at org.mortbay.jetty.handler.ContextHandler.startContext(ContextHandler.java:548) at org.mortbay.jetty.servlet.Context.startContext(Context.java:136) at org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1250) at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:517) at org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:467) at org.mortbay.jetty.plugin.Jetty6PluginWebAppContext.doStart(Jetty6PluginWebAppContext.java:115) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152) at
[jira] Resolved: (EXTSCRIPT-55) Improve the styling of the JSF 1.2 examples
[ https://issues.apache.org/jira/browse/EXTSCRIPT-55?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Werner Punz resolved EXTSCRIPT-55. -- Resolution: Fixed Improve the styling of the JSF 1.2 examples --- Key: EXTSCRIPT-55 URL: https://issues.apache.org/jira/browse/EXTSCRIPT-55 Project: MyFaces Extensions Scripting Issue Type: Improvement Reporter: Werner Punz Assignee: Werner Punz We have a very good styling now for the 2.0 examples improve it for 1.0 possibly also by introducing weblets there for real on the fly resource updates -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (EXTSCRIPT-57) Improve the styling of the JSF 2.0 examples
[ https://issues.apache.org/jira/browse/EXTSCRIPT-57?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Werner Punz resolved EXTSCRIPT-57. -- Resolution: Fixed Improve the styling of the JSF 2.0 examples --- Key: EXTSCRIPT-57 URL: https://issues.apache.org/jira/browse/EXTSCRIPT-57 Project: MyFaces Extensions Scripting Issue Type: Improvement Reporter: Werner Punz Assignee: Werner Punz Priority: Minor We almost are there but the styling still needs some fixes -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-2120) TODO #69: Create and implement the partial response - Implement the partial response writer
[ https://issues.apache.org/jira/browse/MYFACES-2120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Werner Punz updated MYFACES-2120: - Resolution: Fixed Status: Resolved (was: Patch Available) Closing this now TODO #69: Create and implement the partial response - Implement the partial response writer --- Key: MYFACES-2120 URL: https://issues.apache.org/jira/browse/MYFACES-2120 Project: MyFaces Core Issue Type: Sub-task Components: JSR-314 Reporter: Werner Punz Attachments: MYFACES-2120.patch Create and implement the partial response as described in 13.4.3 Sending The Response to The Client of the EDR2 The partial response writer must give back xml and must split the javascripts out of the html the client side then must eval the javascripts separately after rendering the html content! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2522) f:event wrong attribute name
f:event wrong attribute name
Key: MYFACES-2522
URL: https://issues.apache.org/jira/browse/MYFACES-2522
Project: MyFaces Core
Issue Type: Bug
Reporter: Werner Punz
As it seems f:event uses a wrong (probably old) attribute name:
f:event name=postAddToView
listener=#{javatestbean.validate}/ works
but in reality according to the spec section 3.4.3.4 it should be
f:event type=postAddToView
listener=#{javatestbean.validate}/
and that one causes a classNotFound error
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2522) f:event wrong attribute name
[
https://issues.apache.org/jira/browse/MYFACES-2522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12806350#action_12806350
]
Werner Punz commented on MYFACES-2522:
--
Never mind as it seems the spec and the tld seems to differ in this...
we probably are correct there. TLD for me is the final word here.
I will close thise one for now.
As it seems our implementation is correct.
I will ask the EG before going on with this issue.
f:event wrong attribute name
Key: MYFACES-2522
URL: https://issues.apache.org/jira/browse/MYFACES-2522
Project: MyFaces Core
Issue Type: Bug
Components: JSR-314
Reporter: Werner Punz
Priority: Minor
As it seems f:event uses a wrong (probably old) attribute name:
f:event name=postAddToView
listener=#{javatestbean.validate}/ works
but in reality according to the spec section 3.4.3.4 it should be
f:event type=postAddToView
listener=#{javatestbean.validate}/
and that one causes a classNotFound error
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2522) f:event wrong attribute name
[
https://issues.apache.org/jira/browse/MYFACES-2522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12806358#action_12806358
]
Werner Punz commented on MYFACES-2522:
--
Ok I asked in the open mailinglist what the correct behavior of this issue is...
The spec is ambiguous either name or type but not both like we have it.
Mojarra seems to use type (giving the comments I got from someone I gave the
hint to use f:event)
f:event wrong attribute name
Key: MYFACES-2522
URL: https://issues.apache.org/jira/browse/MYFACES-2522
Project: MyFaces Core
Issue Type: Bug
Components: JSR-314
Reporter: Werner Punz
Priority: Minor
As it seems f:event uses a wrong (probably old) attribute name:
f:event name=postAddToView
listener=#{javatestbean.validate}/ works
but in reality according to the spec section 3.4.3.4 it should be
f:event type=postAddToView
listener=#{javatestbean.validate}/
and that one causes a classNotFound error
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2523) files for beta release don't run the most trivial application
files for beta release don't run the most trivial application - Key: MYFACES-2523 URL: https://issues.apache.org/jira/browse/MYFACES-2523 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-beta-2 Environment: tomcat Reporter: Ganesh Jung This most basic page: !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd; html xmlns=http://www.w3.org/1999/xhtml; xmlns:h=http://java.sun.com/jsf/html; xmlns:f=http://java.sun.com/jsf/core; xmlns:ui=http://java.sun.com/jsf/facelets; body h:form h:commandButton value=test /h:commandButton /h:form /body /html yields a security exception: java.security.NoSuchAlgorithmException: Cannot find any provider supporting DES/ECB/PKCS5Padding when creating a minimal project that only contains the files from 2.0.0-beta. I'll attach a war to demonstrate the bug. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2520) UnsupportedOperationException when launching Trinidad 2 w/ MyFaces2 in Jetty
[ https://issues.apache.org/jira/browse/MYFACES-2520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12806362#action_12806362 ] Jakob Korherr commented on MYFACES-2520: There already was a discussion about that on the mailing list: http://old.nabble.com/problem-using-myfaces-core-2.0.0-SNAPSHOT-%2B-myfaces-orchestra20-1.5-SNAPSHOT-td27239462.html#a27239462 UnsupportedOperationException when launching Trinidad 2 w/ MyFaces2 in Jetty Key: MYFACES-2520 URL: https://issues.apache.org/jira/browse/MYFACES-2520 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-beta-2 Reporter: Matthias Weßendorf SEVERE: java.lang.UnsupportedOperationException: This request class is an empty placeholder at org.apache.myfaces.application._SystemEventServletRequest$1.invoke(_SystemEventServletRequest.java:56) at $Proxy0.getContentType(Unknown Source) at javax.servlet.ServletRequestWrapper.getContentType(ServletRequestWrapper.java:145) at org.apache.myfaces.context.servlet.ServletExternalContextImpl.getRequestContentType(ServletExternalContextImpl.java:322) at org.apache.myfaces.trinidad.util.ExternalContextUtils.getContentType(ExternalContextUtils.java:341) at org.apache.myfaces.trinidadinternal.share.util.MultipartFormHandler.isMultipartRequest(MultipartFormHandler.java:57) at org.apache.myfaces.trinidadinternal.config.upload.FileUploadConfiguratorImpl.beginRequest(FileUploadConfiguratorImpl.java:109) at org.apache.myfaces.trinidadinternal.config.GlobalConfiguratorImpl._startConfiguratorServiceRequest(GlobalConfiguratorImpl.java:532) at org.apache.myfaces.trinidadinternal.config.GlobalConfiguratorImpl.beginRequest(GlobalConfiguratorImpl.java:211) at org.apache.myfaces.trinidadinternal.config.GlobalConfiguratorImpl.getExternalContext(GlobalConfiguratorImpl.java:327) at org.apache.myfaces.trinidadinternal.context.FacesContextFactoryImpl$CacheRenderKit.init(FacesContextFactoryImpl.java:90) at org.apache.myfaces.trinidadinternal.context.FacesContextFactoryImpl.getFacesContext(FacesContextFactoryImpl.java:68) at org.apache.myfaces.webapp.AbstractFacesInitializer.dispatchInitDestroyEvent(AbstractFacesInitializer.java:140) at org.apache.myfaces.webapp.AbstractFacesInitializer.initFaces(AbstractFacesInitializer.java:109) at org.apache.myfaces.webapp.StartupServletContextListener.contextInitialized(StartupServletContextListener.java:155) at org.mortbay.jetty.handler.ContextHandler.startContext(ContextHandler.java:548) at org.mortbay.jetty.servlet.Context.startContext(Context.java:136) at org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1250) at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:517) at org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:467) at org.mortbay.jetty.plugin.Jetty6PluginWebAppContext.doStart(Jetty6PluginWebAppContext.java:115) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152) at org.mortbay.jetty.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:156) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:130) at org.mortbay.jetty.Server.doStart(Server.java:224) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.plugin.Jetty6PluginServer.start(Jetty6PluginServer.java:132) at org.mortbay.jetty.plugin.AbstractJettyMojo.startJetty(AbstractJettyMojo.java:441) at org.mortbay.jetty.plugin.AbstractJettyMojo.execute(AbstractJettyMojo.java:383) at org.mortbay.jetty.plugin.AbstractJettyRunMojo.execute(AbstractJettyRunMojo.java:210) at org.mortbay.jetty.plugin.Jetty6RunMojo.execute(Jetty6RunMojo.java:184) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:569) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:539) at
[jira] Commented: (MYFACES-2523) files for beta release don't run the most trivial application
[ https://issues.apache.org/jira/browse/MYFACES-2523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12806365#action_12806365 ] Ganesh Jung commented on MYFACES-2523: -- Looks like this is an issue with Eclipse. After creating the demo war and deploying it directly to tomcat-webapps the application works, but when creating an Eclipse Dynamic Web Project, adding the test.xhtml above, the MyFaces 2.0 beta and the following web.xml then the error occurs. web-app xmlns=http://java.sun.com/xml/ns/javaee; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; version=2.5 xsi:schemaLocation=http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd; context-param param-namejavax.faces.PROJECT_STAGE/param-name param-valueProduction/param-value /context-param servlet servlet-nameFaces Servlet/servlet-name servlet-classjavax.faces.webapp.FacesServlet/servlet-class load-on-startup1/load-on-startup /servlet servlet-mapping servlet-nameFaces Servlet/servlet-name url-pattern*.faces/url-pattern /servlet-mapping welcome-file-list welcome-fileindex.html/welcome-file /welcome-file-list /web-app I still consider this as a MyFaces bug, because the app works with Mojarra 2.0 and MyFaces 1.2 projects do work within Eclipse. files for beta release don't run the most trivial application - Key: MYFACES-2523 URL: https://issues.apache.org/jira/browse/MYFACES-2523 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-beta-2 Environment: tomcat Reporter: Ganesh Jung This most basic page: !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd; html xmlns=http://www.w3.org/1999/xhtml; xmlns:h=http://java.sun.com/jsf/html; xmlns:f=http://java.sun.com/jsf/core; xmlns:ui=http://java.sun.com/jsf/facelets; body h:form h:commandButton value=test /h:commandButton /h:form /body /html yields a security exception: java.security.NoSuchAlgorithmException: Cannot find any provider supporting DES/ECB/PKCS5Padding when creating a minimal project that only contains the files from 2.0.0-beta. I'll attach a war to demonstrate the bug. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2522) f:event wrong attribute name
[
https://issues.apache.org/jira/browse/MYFACES-2522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12806372#action_12806372
]
Matthias Weßendorf commented on MYFACES-2522:
-
the so called open list (which is semi-open in real) also should be aware of
this item:
https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=712
f:event wrong attribute name
Key: MYFACES-2522
URL: https://issues.apache.org/jira/browse/MYFACES-2522
Project: MyFaces Core
Issue Type: Bug
Components: JSR-314
Reporter: Werner Punz
Priority: Minor
As it seems f:event uses a wrong (probably old) attribute name:
f:event name=postAddToView
listener=#{javatestbean.validate}/ works
but in reality according to the spec section 3.4.3.4 it should be
f:event type=postAddToView
listener=#{javatestbean.validate}/
and that one causes a classNotFound error
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2523) files for beta release don't run the most trivial application
[ https://issues.apache.org/jira/browse/MYFACES-2523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12806377#action_12806377 ] Leonardo Uribe commented on MYFACES-2523: - I don't think this is a myfaces bug. My hypothesis is the problem is about project dependences in eclipse. In theory, it is necessary to jce.jar to your project classpath. We can't do anything from myfaces point of view. files for beta release don't run the most trivial application - Key: MYFACES-2523 URL: https://issues.apache.org/jira/browse/MYFACES-2523 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-beta-2 Environment: tomcat Reporter: Ganesh Jung This most basic page: !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd; html xmlns=http://www.w3.org/1999/xhtml; xmlns:h=http://java.sun.com/jsf/html; xmlns:f=http://java.sun.com/jsf/core; xmlns:ui=http://java.sun.com/jsf/facelets; body h:form h:commandButton value=test /h:commandButton /h:form /body /html yields a security exception: java.security.NoSuchAlgorithmException: Cannot find any provider supporting DES/ECB/PKCS5Padding when creating a minimal project that only contains the files from 2.0.0-beta. I'll attach a war to demonstrate the bug. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2516) Allow any child for f:event in the case of a PreRenderViewEvent
[ https://issues.apache.org/jira/browse/MYFACES-2516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12806380#action_12806380 ] Leonardo Uribe commented on MYFACES-2516: - Thanks Bernd for check it and commit that one. I'm glad that solution works. Allow any child for f:event in the case of a PreRenderViewEvent --- Key: MYFACES-2516 URL: https://issues.apache.org/jira/browse/MYFACES-2516 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-alpha, 2.0.0-beta Reporter: Bernd Bohmann Assignee: Bernd Bohmann Fix For: 2.0.0-beta-2 Attachments: MYFACES-2516.patch f:event currently only supports the UIViewRoot as a child for the PreRenderViewEvent -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] release for myfaces core 2.0.0-beta
2010/1/29 Ganesh gan...@j4fry.org Hi, I've tried testing the beta with DojoFaces, but even the most basic examples fail to work, e.g.: !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd; html xmlns=http://www.w3.org/1999/xhtml; xmlns:h=http://java.sun.com/jsf/html; xmlns:f=http://java.sun.com/jsf/core; xmlns:ui=http://java.sun.com/jsf/facelets; body h:form h:commandButton value=test / /h:form /body /html gives me: java.security.NoSuchAlgorithmException: Cannot find any provider supporting DES/ECB/PKCS5Padding I'm all in favour of another alpha, but I feel people won't give much credit if a beta doesn't do the basic stuff. I don't believe this is a myfaces problem. This error is usually found when jce.jar is not found on your classpath. I think we should release this as beta and later do another beta if required (in 2 or 3 weeks?). I'm not have any problem to do it. regards, Leonardo Uribe Best regards, Ganesh Cagatay Civici schrieb: Anyway my vote is 0 now and I would like to hear other testers' results.
[jira] Created: (PORTLETBRIDGE-109) ExternalContext encodeAction/resource URL should only unXML encode URLs that aren't XML encoded
ExternalContext encodeAction/resource URL should only unXML encode URLs that aren't XML encoded --- Key: PORTLETBRIDGE-109 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-109 Project: MyFaces Portlet Bridge Issue Type: Bug Components: Impl Affects Versions: 2.0.0-alpha, 1.0.0-beta Reporter: Michael Freedman Assignee: Michael Freedman When the bridge relies on the underlying portlet container to construct the URL returned from encodeActionURL/encodeResourceURL is always unXML encodes the URl prior to return (i.e. it replaces amp; with ) this is done because it found renderkits sometimes/often did there own XML encoding on the result (as they don't expect these functions to do this. By doing the unencode we worked around incorrectly double encoding. A better strategy is to look at the URL that is past in to these methods. If the URL isn't XML encoded then we should continue to decode at the end of the method (assuming the renderkit wil do any post encoding that is needed. However if it is already encoded then we should skip the decode as its more likely the renderkit has already done its encoding (or else it will double encode. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (PORTLETBRIDGE-110) Bridge relies on a URL/QueryString utility class that doesn't support XML encoding
Bridge relies on a URL/QueryString utility class that doesn't support XML encoding -- Key: PORTLETBRIDGE-110 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-110 Project: MyFaces Portlet Bridge Issue Type: Bug Reporter: Michael Freedman The bridge's QueryString utility class that is used to decode/encode QueryStrings to/from its parameters doesn't parse QueryStrings that use the XML encoded amp; seperator. It should. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] release for myfaces core 2.0.0-beta
Hi Can we close this vote and continue the release procedure? If no objections I'll do it. regards, Leonardo Uribe 2010/1/29 Leonardo Uribe lu4...@gmail.com 2010/1/29 Ganesh gan...@j4fry.org Hi, I've tried testing the beta with DojoFaces, but even the most basic examples fail to work, e.g.: !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd; html xmlns=http://www.w3.org/1999/xhtml; xmlns:h=http://java.sun.com/jsf/html; xmlns:f=http://java.sun.com/jsf/core; xmlns:ui=http://java.sun.com/jsf/facelets; body h:form h:commandButton value=test / /h:form /body /html gives me: java.security.NoSuchAlgorithmException: Cannot find any provider supporting DES/ECB/PKCS5Padding I'm all in favour of another alpha, but I feel people won't give much credit if a beta doesn't do the basic stuff. I don't believe this is a myfaces problem. This error is usually found when jce.jar is not found on your classpath. I think we should release this as beta and later do another beta if required (in 2 or 3 weeks?). I'm not have any problem to do it. regards, Leonardo Uribe Best regards, Ganesh Cagatay Civici schrieb: Anyway my vote is 0 now and I would like to hear other testers' results.
[jira] Created: (PORTLETBRIDGE-111) Bridge RequestParamValues and RequestHeaderValues Map don't support equals() correctly
Bridge RequestParamValues and RequestHeaderValues Map don't support equals() correctly -- Key: PORTLETBRIDGE-111 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-111 Project: MyFaces Portlet Bridge Issue Type: Bug Components: Impl Affects Versions: 2.0.0-alpha, 1.0.0-beta Reporter: Michael Freedman Assignee: Michael Freedman Both externalContext.getRequestParameterValues() and getRequestHeaderValues() return Maps of type String, String[]. If you try and compare 2 equal Maps of these using map1.equals(map2) it fails because the generic AbstractMap equals doesn't support/properly compare Arrays. Instead these Map impls (which are special internal bridge impls) must support equals directly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (PORTLETBRIDGE-111) Bridge RequestParamValues and RequestHeaderValues Map don't support equals() correctly
[ https://issues.apache.org/jira/browse/PORTLETBRIDGE-111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Freedman resolved PORTLETBRIDGE-111. Resolution: Fixed Fix Version/s: 2.0.0 1.0.0 Added equals() implementation that uses Arrays.equals to compare the arrays in the values of the two Maps entries. Also changed superclass PortletAbstractMap to extend AbstractMap rather implement Map -- thus other extenders (other Maps we build) can inherit regular Map equals method. Bridge RequestParamValues and RequestHeaderValues Map don't support equals() correctly -- Key: PORTLETBRIDGE-111 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-111 Project: MyFaces Portlet Bridge Issue Type: Bug Components: Impl Affects Versions: 1.0.0-beta, 2.0.0-alpha Reporter: Michael Freedman Assignee: Michael Freedman Fix For: 1.0.0, 2.0.0 Both externalContext.getRequestParameterValues() and getRequestHeaderValues() return Maps of type String, String[]. If you try and compare 2 equal Maps of these using map1.equals(map2) it fails because the generic AbstractMap equals doesn't support/properly compare Arrays. Instead these Map impls (which are special internal bridge impls) must support equals directly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (PORTLETBRIDGE-110) Bridge relies on a URL/QueryString utility class that doesn't support XML encoding
[ https://issues.apache.org/jira/browse/PORTLETBRIDGE-110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Freedman resolved PORTLETBRIDGE-110. Resolution: Fixed Fix Version/s: 2.0.0 1.0.0 Assignee: Michael Freedman QueryString constructor now decodes the QueryString so internals are always working on a decoded -- non-XML encoded QueryString. Bridge relies on a URL/QueryString utility class that doesn't support XML encoding -- Key: PORTLETBRIDGE-110 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-110 Project: MyFaces Portlet Bridge Issue Type: Bug Reporter: Michael Freedman Assignee: Michael Freedman Fix For: 1.0.0, 2.0.0 The bridge's QueryString utility class that is used to decode/encode QueryStrings to/from its parameters doesn't parse QueryStrings that use the XML encoded amp; seperator. It should. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (PORTLETBRIDGE-109) ExternalContext encodeAction/resource URL should only unXML encode URLs that aren't XML encoded
[ https://issues.apache.org/jira/browse/PORTLETBRIDGE-109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Freedman resolved PORTLETBRIDGE-109. Resolution: Fixed Fix Version/s: 2.0.0 1.0.0 encodeActionURl and encodeResourceURL now check the incoming URL to see if its XML encoded. If it is then it skips the decode usually done after URL generation/encoding prior to return. ExternalContext encodeAction/resource URL should only unXML encode URLs that aren't XML encoded --- Key: PORTLETBRIDGE-109 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-109 Project: MyFaces Portlet Bridge Issue Type: Bug Components: Impl Affects Versions: 1.0.0-beta, 2.0.0-alpha Reporter: Michael Freedman Assignee: Michael Freedman Fix For: 1.0.0, 2.0.0 When the bridge relies on the underlying portlet container to construct the URL returned from encodeActionURL/encodeResourceURL is always unXML encodes the URl prior to return (i.e. it replaces amp; with ) this is done because it found renderkits sometimes/often did there own XML encoding on the result (as they don't expect these functions to do this. By doing the unencode we worked around incorrectly double encoding. A better strategy is to look at the URL that is past in to these methods. If the URL isn't XML encoded then we should continue to decode at the end of the method (assuming the renderkit wil do any post encoding that is needed. However if it is already encoded then we should skip the decode as its more likely the renderkit has already done its encoding (or else it will double encode. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] release for myfaces core 2.0.0-beta
On Fri, Jan 29, 2010 at 5:29 PM, Leonardo Uribe lu4...@gmail.com wrote: 2010/1/29 Ganesh gan...@j4fry.org Hi, I've tried testing the beta with DojoFaces, but even the most basic examples fail to work, e.g.: !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd; html xmlns=http://www.w3.org/1999/xhtml; xmlns:h=http://java.sun.com/jsf/html; xmlns:f=http://java.sun.com/jsf/core; xmlns:ui=http://java.sun.com/jsf/facelets; body h:form h:commandButton value=test / /h:form /body /html gives me: java.security.NoSuchAlgorithmException: Cannot find any provider supporting DES/ECB/PKCS5Padding I'm all in favour of another alpha, but I feel people won't give much credit if a beta doesn't do the basic stuff. I don't believe this is a myfaces problem. This error is usually found when jce.jar is not found on your classpath. I think we should release this as beta and later do another beta if required (in 2 or 3 weeks?). I'm not have any problem to do it. IMO that's fine... We should also have every three weeks a new beta ;-) -Matthias regards, Leonardo Uribe Best regards, Ganesh Cagatay Civici schrieb: Anyway my vote is 0 now and I would like to hear other testers' results. -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: svn commit: r904560 - /myfaces/trinidad/branches/trinidad-2.0.x/trinidad-api/src/main/java/org/apache/myfaces/trinidad/facelets/MetaTagHandler.java
ha! I have seen this before, that it doesn't get catched... The file was in the right folder structure, but the package was wrong. Eclipse gives you a WARNING here. Is that an issue from the Maven compiler plugin, or is Eclipse just smart/nice ? Gruss! Matthias On Fri, Jan 29, 2010 at 6:04 PM, mstar...@apache.org wrote: Author: mstarets Date: Fri Jan 29 17:04:54 2010 New Revision: 904560 URL: http://svn.apache.org/viewvc?rev=904560view=rev Log: Fixed a type in the package name - the class was being compiled into the 'trinidadinternal' package Modified: myfaces/trinidad/branches/trinidad-2.0.x/trinidad-api/src/main/java/org/apache/myfaces/trinidad/facelets/MetaTagHandler.java Modified: myfaces/trinidad/branches/trinidad-2.0.x/trinidad-api/src/main/java/org/apache/myfaces/trinidad/facelets/MetaTagHandler.java URL: http://svn.apache.org/viewvc/myfaces/trinidad/branches/trinidad-2.0.x/trinidad-api/src/main/java/org/apache/myfaces/trinidad/facelets/MetaTagHandler.java?rev=904560r1=904559r2=904560view=diff == --- myfaces/trinidad/branches/trinidad-2.0.x/trinidad-api/src/main/java/org/apache/myfaces/trinidad/facelets/MetaTagHandler.java (original) +++ myfaces/trinidad/branches/trinidad-2.0.x/trinidad-api/src/main/java/org/apache/myfaces/trinidad/facelets/MetaTagHandler.java Fri Jan 29 17:04:54 2010 @@ -16,7 +16,7 @@ * specific language governing permissions and limitations * under the License. */ -package org.apache.myfaces.trinidadinternal.facelets; +package org.apache.myfaces.trinidad.facelets; import java.beans.BeanInfo; import java.beans.IntrospectionException; -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
[jira] Resolved: (EXTVAL-82) Add the EmptyValueAwareValidationStrategy annotation to the Length and Pattern Annotations
[ https://issues.apache.org/jira/browse/EXTVAL-82?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek resolved EXTVAL-82. Resolution: Won't Fix the initial reason for the marker was to avoid such an implicit required validation. use-case: a property is not required but if users provide a value it has to fulfill e.g. a minimal length. the scenario described in this issue is easy to solve via an additional @Required constraint at the property or a custom validation strategy (as replacement for the default one) which hosts the mentioned marker. Add the EmptyValueAwareValidationStrategy annotation to the Length and Pattern Annotations -- Key: EXTVAL-82 URL: https://issues.apache.org/jira/browse/EXTVAL-82 Project: MyFaces Extensions Validator Issue Type: Improvement Components: Property Validation Affects Versions: 1.2.3-SNAPSHOT, 2.0.3-SNAPSHOT, 1.1.3-SNAPSHOT Reporter: Rudy De Busscher Priority: Minor Adding the EmptyValueAwareValidationStrategy allows in JSF 2.0 that Length and Pattern validations are triggered (with the javax.faces.VALIDATE_EMPTY_FIELDS parameter set). They will cause a validation error with an empty string (Length annotation with minimum set or Pattern) so the Required annotation is no longer needed. Tested it out with ExtVal 2.0.3-SNAPSHOT and Myfaces 2.0.0-SNAPHOT (of 21/01) and it works as expected. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (EXTVAL-82) Add the EmptyValueAwareValidationStrategy annotation to the Length and Pattern Annotations
[ https://issues.apache.org/jira/browse/EXTVAL-82?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12806449#action_12806449 ] Gerhard Petracek commented on EXTVAL-82: hi rudy, thx for the additional testing! but i think the behavior of javax.faces.VALIDATE_EMPTY_FIELDS without extval shows a major disadvantage. it's also the behavior of extval r3. due to the mentioned disadvantage (see the previous comment) we moved away from this approach. since it's quite easy to change the default behavior of extval it isn't a big deal to align the behavior of extval with the default behavior of jsf2 in combination with javax.faces.VALIDATE_EMPTY_FIELDS. however, i think you did an important task. maybe we should create a wiki page to document the differences (+ reasons) and how to change the default behavior. regards, gerhard Add the EmptyValueAwareValidationStrategy annotation to the Length and Pattern Annotations -- Key: EXTVAL-82 URL: https://issues.apache.org/jira/browse/EXTVAL-82 Project: MyFaces Extensions Validator Issue Type: Improvement Components: Property Validation Affects Versions: 1.2.3-SNAPSHOT, 2.0.3-SNAPSHOT, 1.1.3-SNAPSHOT Reporter: Rudy De Busscher Priority: Minor Adding the EmptyValueAwareValidationStrategy allows in JSF 2.0 that Length and Pattern validations are triggered (with the javax.faces.VALIDATE_EMPTY_FIELDS parameter set). They will cause a validation error with an empty string (Length annotation with minimum set or Pattern) so the Required annotation is no longer needed. Tested it out with ExtVal 2.0.3-SNAPSHOT and Myfaces 2.0.0-SNAPHOT (of 21/01) and it works as expected. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2524) Change ExternalSpecifications to enable using it in automated tests
Change ExternalSpecifications to enable using it in automated tests --- Key: MYFACES-2524 URL: https://issues.apache.org/jira/browse/MYFACES-2524 Project: MyFaces Core Issue Type: Task Affects Versions: 2.0.0-beta Reporter: Jakob Korherr Assignee: Jakob Korherr Currently ExternalSpecifications is using public static final fields to hold the information if something is available or not (e.g. bean validation). However, this is problematic for automated testing, because the value can not be adapted for the test case (not even with reflection). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2523) files for beta release don't run the most trivial application
[ https://issues.apache.org/jira/browse/MYFACES-2523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12806465#action_12806465 ] Ganesh Jung commented on MYFACES-2523: -- jce.jar is part of the JDK, how would it not be found?? Adding a huge HTML comment: h:form !-- fff ...over 7633 'f' characters... f- h:commandButton value=test / /h:form makes it work ... must be something weird within MyFaces files for beta release don't run the most trivial application - Key: MYFACES-2523 URL: https://issues.apache.org/jira/browse/MYFACES-2523 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-beta-2 Environment: tomcat Reporter: Ganesh Jung This most basic page: !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd; html xmlns=http://www.w3.org/1999/xhtml; xmlns:h=http://java.sun.com/jsf/html; xmlns:f=http://java.sun.com/jsf/core; xmlns:ui=http://java.sun.com/jsf/facelets; body h:form h:commandButton value=test /h:commandButton /h:form /body /html yields a security exception: java.security.NoSuchAlgorithmException: Cannot find any provider supporting DES/ECB/PKCS5Padding when creating a minimal project that only contains the files from 2.0.0-beta. I'll attach a war to demonstrate the bug. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2525) Split javax.faces package in OSGi
Split javax.faces package in OSGi - Key: MYFACES-2525 URL: https://issues.apache.org/jira/browse/MYFACES-2525 Project: MyFaces Core Issue Type: Bug Components: General Reporter: Jarek Gawor Right now both api and impl modules claim to export javax.faces package. That's a problem in OSGi environment and actually causes classloading problems. The impl module exports javax.faces package since it contains resource bundles for javax.faces package. Moving the resource bundles to the api module does resolve the OSGi problem and I saw no failures when building the code. I'm building https://svn.apache.org/repos/asf/myfaces/core/trunk. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2525) Split javax.faces package in OSGi
[ https://issues.apache.org/jira/browse/MYFACES-2525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12806471#action_12806471 ] Jakob Korherr commented on MYFACES-2525: I hope this is not a problem for the TCK test... Split javax.faces package in OSGi - Key: MYFACES-2525 URL: https://issues.apache.org/jira/browse/MYFACES-2525 Project: MyFaces Core Issue Type: Bug Components: General Reporter: Jarek Gawor Right now both api and impl modules claim to export javax.faces package. That's a problem in OSGi environment and actually causes classloading problems. The impl module exports javax.faces package since it contains resource bundles for javax.faces package. Moving the resource bundles to the api module does resolve the OSGi problem and I saw no failures when building the code. I'm building https://svn.apache.org/repos/asf/myfaces/core/trunk. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] release for myfaces core 2.0.0-beta
+1 on the release. Also +1 on the three weekly release if Leonardo can handle the extra burden. :-) Regards, Jan-Kees 2010/1/29 Matthias Wessendorf mat...@apache.org: On Fri, Jan 29, 2010 at 5:29 PM, Leonardo Uribe lu4...@gmail.com wrote: 2010/1/29 Ganesh gan...@j4fry.org Hi, I've tried testing the beta with DojoFaces, but even the most basic examples fail to work, e.g.: !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd; html xmlns=http://www.w3.org/1999/xhtml; xmlns:h=http://java.sun.com/jsf/html; xmlns:f=http://java.sun.com/jsf/core; xmlns:ui=http://java.sun.com/jsf/facelets; body h:form h:commandButton value=test / /h:form /body /html gives me: java.security.NoSuchAlgorithmException: Cannot find any provider supporting DES/ECB/PKCS5Padding I'm all in favour of another alpha, but I feel people won't give much credit if a beta doesn't do the basic stuff. I don't believe this is a myfaces problem. This error is usually found when jce.jar is not found on your classpath. I think we should release this as beta and later do another beta if required (in 2 or 3 weeks?). I'm not have any problem to do it. IMO that's fine... We should also have every three weeks a new beta ;-) -Matthias regards, Leonardo Uribe Best regards, Ganesh Cagatay Civici schrieb: Anyway my vote is 0 now and I would like to hear other testers' results. -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
[jira] Commented: (MYFACES-2524) Change ExternalSpecifications to enable using it in automated tests
[ https://issues.apache.org/jira/browse/MYFACES-2524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12806489#action_12806489 ] Jan-Kees van Andel commented on MYFACES-2524: - The only reason for this approach was performance, since final fields are automatically thread safe. The classloader makes sure it is. Most of the code should be quite performant, only: Validation.buildDefaultValidatorFactory().getValidator(); is an issue. You don't want to invoke this beast on every request, since it bootstraps Bean Validation. I added it because of an issue raised by (I think) Mike Concini. I think a lazy initializing singleton is a good replacement. This way, you can change some settings before initialization happens. Change ExternalSpecifications to enable using it in automated tests --- Key: MYFACES-2524 URL: https://issues.apache.org/jira/browse/MYFACES-2524 Project: MyFaces Core Issue Type: Task Affects Versions: 2.0.0-beta Reporter: Jakob Korherr Assignee: Jakob Korherr Currently ExternalSpecifications is using public static final fields to hold the information if something is available or not (e.g. bean validation). However, this is problematic for automated testing, because the value can not be adapted for the test case (not even with reflection). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-2524) Change ExternalSpecifications to enable using it in automated tests
[ https://issues.apache.org/jira/browse/MYFACES-2524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jakob Korherr resolved MYFACES-2524. Resolution: Fixed Fix Version/s: 2.0.0-beta-2 I changed the public static final fields to private static fields and public getters with lazy initialization. So the value of the fields can be changed using reflection (for automated tests). Change ExternalSpecifications to enable using it in automated tests --- Key: MYFACES-2524 URL: https://issues.apache.org/jira/browse/MYFACES-2524 Project: MyFaces Core Issue Type: Task Affects Versions: 2.0.0-beta Reporter: Jakob Korherr Assignee: Jakob Korherr Fix For: 2.0.0-beta-2 Currently ExternalSpecifications is using public static final fields to hold the information if something is available or not (e.g. bean validation). However, this is problematic for automated testing, because the value can not be adapted for the test case (not even with reflection). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-1696) acc (screen reader mode) layout tables should include role=presentation
[
https://issues.apache.org/jira/browse/TRINIDAD-1696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Cooper updated TRINIDAD-1696:
--
Resolution: Fixed
Fix Version/s: 1.2.14-core
Status: Resolved (was: Patch Available)
acc (screen reader mode) layout tables should include role=presentation
-
Key: TRINIDAD-1696
URL: https://issues.apache.org/jira/browse/TRINIDAD-1696
Project: MyFaces Trinidad
Issue Type: Bug
Affects Versions: 1.2.12-core
Environment: all
Reporter: Dave Robinson
Assignee: Matt Cooper
Priority: Minor
Fix For: 1.2.14-core
Attachments: TRINIDAD-1696 for trinidad 1.2.12.1.patch, TRINIDAD-1696
for trinidad 1.2.12.2.patch, TRINIDAD-1696 for trinidad trunk.patch
Original Estimate: 3h
Remaining Estimate: 3h
When using trh:tableLayout in our page to layout some UI components, it gives
warning during Accessibility testing:
WARNING - This layout Table could be confused for a data table by Screen
Readers
From the html perspective, this warning can be fixed by setting
role=presentation
on the html table element.
We can add
role=presentation to layout tables with the following addition to
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.OutputTextUtils.renderLayoutTableAttributes():
if (CoreRenderer.isScreenReaderMode(arc))
{
ResponseWriter writer = context.getResponseWriter();
writer.writeAttribute(datatable, 0, null);
-- writer.writeAttribute(role, presentation, null); --
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2525) Split javax.faces package in OSGi
[ https://issues.apache.org/jira/browse/MYFACES-2525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12806513#action_12806513 ] Leonardo Uribe commented on MYFACES-2525: - It sound reasonable. I experienced that issue too when I was testing myfaces in OSGi, but spring dm solves it. It does not affect TCK, because it test both jars at the same time. Jakob, if you have time, feel free to move them for all branches (1.1.x, 1.2.x and 2.0.x). Split javax.faces package in OSGi - Key: MYFACES-2525 URL: https://issues.apache.org/jira/browse/MYFACES-2525 Project: MyFaces Core Issue Type: Bug Components: General Reporter: Jarek Gawor Right now both api and impl modules claim to export javax.faces package. That's a problem in OSGi environment and actually causes classloading problems. The impl module exports javax.faces package since it contains resource bundles for javax.faces package. Moving the resource bundles to the api module does resolve the OSGi problem and I saw no failures when building the code. I'm building https://svn.apache.org/repos/asf/myfaces/core/trunk. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[TRINIDAD] trinidad-2.0.x branch and patches
Is the trinidad-2.0.x branch something permanent or do you foresee this being rebranched from the JSF 1.2 Trinidad trunk in the future? (I am asking because I am applying patches for TRINIDAD-1696 and would like to know if I need an extra patch for the trinidad-2.0.x branch.) Thanks, Matt
Re: [TRINIDAD] trinidad-2.0.x branch and patches
Hey Matt, please do NOT apply them to 2.0.x every n weeks, I do merge the 1.2 fixes into the 2.0.x -Matthias On Fri, Jan 29, 2010 at 10:37 PM, Matt Cooper mcoo...@apache.org wrote: Is the trinidad-2.0.x branch something permanent or do you foresee this being rebranched from the JSF 1.2 Trinidad trunk in the future? (I am asking because I am applying patches for TRINIDAD-1696 and would like to know if I need an extra patch for the trinidad-2.0.x branch.) Thanks, Matt -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
[jira] Commented: (MYFACES-2525) Split javax.faces package in OSGi
[ https://issues.apache.org/jira/browse/MYFACES-2525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12806520#action_12806520 ] Jakob Korherr commented on MYFACES-2525: OK, good to know. I'll have some time for that by the end of next week! Split javax.faces package in OSGi - Key: MYFACES-2525 URL: https://issues.apache.org/jira/browse/MYFACES-2525 Project: MyFaces Core Issue Type: Bug Components: General Reporter: Jarek Gawor Right now both api and impl modules claim to export javax.faces package. That's a problem in OSGi environment and actually causes classloading problems. The impl module exports javax.faces package since it contains resource bundles for javax.faces package. Moving the resource bundles to the api module does resolve the OSGi problem and I saw no failures when building the code. I'm building https://svn.apache.org/repos/asf/myfaces/core/trunk. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [TRINIDAD] trinidad-2.0.x branch and patches
Excellent, thank you Matthias :) On Fri, Jan 29, 2010 at 2:39 PM, Matthias Wessendorf mat...@apache.orgwrote: Hey Matt, please do NOT apply them to 2.0.x every n weeks, I do merge the 1.2 fixes into the 2.0.x -Matthias On Fri, Jan 29, 2010 at 10:37 PM, Matt Cooper mcoo...@apache.org wrote: Is the trinidad-2.0.x branch something permanent or do you foresee this being rebranched from the JSF 1.2 Trinidad trunk in the future? (I am asking because I am applying patches for TRINIDAD-1696 and would like to know if I need an extra patch for the trinidad-2.0.x branch.) Thanks, Matt -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
[jira] Created: (TOMAHAWK-1482) HtmlTableRendererBase produces invalid html if row is not available
HtmlTableRendererBase produces invalid html if row is not available
Key: TOMAHAWK-1482
URL: https://issues.apache.org/jira/browse/TOMAHAWK-1482
Project: MyFaces Tomahawk
Issue Type: Bug
Components: Extended Datatable
Affects Versions: 1.1.9
Environment: myfaces 1.2.8, tiles 2.0.7, richfaces 3.3.3.beta1
Reporter: Michael Heinen
The class
org.apache.myfaces.shared_tomahawk.renderkit.html.HtmlTableRendererBase
produces invalid html if a row is not available.
AJAX calls may fail in this case if invalid html is returned.
See method encodeInnerHtml:
for(int nr = 0; nr newspaperRows; nr++){
...
for(int nc = 0; nc newspaperColumns; nc++) {
...
if(!uiData.isRowAvailable()) {
log.error(Row is not available. Rowindex = + currentRow);
295break;
}
if (nc == 0) {
...
renderRowStart(facesContext, writer, uiData, styles, nr);
}
...
}
renderRowEnd(facesContext, writer, uiData);
There is a break in link 295 and the inner loop is left. renderRowStart is not
called but renderRowEnd is called!
FIX:
The call of renderRowEnd(facesContext, writer, uiData) must be in the inner
loop as last statement (1 line before the current position)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2483) Find a way to allow c:if work with partial state saving enabled
[ https://issues.apache.org/jira/browse/MYFACES-2483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12806589#action_12806589 ] Leonardo Uribe commented on MYFACES-2483: - Attached another patch ( fixPSSIf2009JAN-11.patch ) It has solved the two previous goals: 1. how to remove PostBuildComponentTreeOnRestoreViewEvent (Disabling register listener) 2. how to deal with c:if inside UIViewRoot directly (Save the view fully) It was notice before save an added/removed branch it is necessary to call clearInitialState on all children. After multiple attempts, it was clear the only way to ensure this condition is before save view. Thinking about this stuff, it could be good to have this states for org.apache.myfaces.PARAM_REFRESH_TRANSIENT_BUILD_ON_PSS for: - true: Refresh transient view on partial state saving enabled for all views - auto: If in a view the user uses c:if, c:forEach, c:choose, or ui:include with src using ValueExpression (maybe this is a good moment to think other conditions), the view is marked to be refreshed later, to prevent the call to setFilledView in buildView later and force refreshView on render response phase. - false: No view is refreshed. I have to check other conditions that could trigger component addition/removal and makes pss fail before commit, but I hope do it soon. Find a way to allow c:if work with partial state saving enabled --- Key: MYFACES-2483 URL: https://issues.apache.org/jira/browse/MYFACES-2483 Project: MyFaces Core Issue Type: Task Components: JSR-314 Reporter: Leonardo Uribe Assignee: Leonardo Uribe Attachments: fixPSSIf2009JAN-10.patch, fixPSSIf2009JAN-11.patch, fixPSSIf2009JAN-7.patch This one is difficult to solve but I still think it is possible. It was explored trying to solve MYFACES-2428, and it seems ri is trying to do something about it too on: https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1408 and https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1313 One strategy to solve this one is this: 1. Mark the parent component containing c:if to not save it partially. 2. Do not execute c:if on postback and partial state saving enabled. In theory, the parent component should be restored fully from saved state. Note that things like: c:if pSome markup/p c:if is just invalid. It is expected that c:if only contains components with state. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
