Re: defacto standard for EL Flash scope?
On Thu, 09 Mar 2006 12:15:52 -0800, Ed Burns [EMAIL PROTECTED] said:
EB As you know, JSF 1.2 is fast drawing to a close and the scope is such
EB that we can't get any new big features in.
EB However, Sun's and Apache's JSF 1.1 impls are open source, so there is
EB room for us to make defacto standards if both of us provide the same
EB interface to the user.
EB One thing I wanted to include in JSF 1.2 is a flash scope as shown in
EB my blog entry [1].
EB Is anyone here interested in doing this sort of thing?
EB Ed
EB [1]
http://weblogs.java.net/blog/edburns/archive/2005/12/bringing_ruby_o.html
Sorry, I had to repost this. The proper URL is
http://weblogs.java.net/blog/edburns/archive/2006/03/repost_bringing.html
Ed
--
| [EMAIL PROTECTED] | {home: 407 869 9587, office: 408 884 9519 OR x31640}
| homepage: | http://purl.oclc.org/NET/edburns/
| aim: edburns0sunw | iim: [EMAIL PROTECTED]
| 45 Business Days until JavaOne SF 2006
Re: defacto standard for EL Flash scope?
On Thu, 09 Mar 2006 16:49:49 -0800, Adam Winer [EMAIL PROTECTED] said:
AW I have very mixed emotions about rushing into any standards here,
AW de-facto or otherwise. There's a lot of different ideas here,
AW and I don't want to latch into any one just yet. Let's
AW take our time to get this right.
Sure, I understand your caution, but the concept of the flash has been a
popular feature in RoR. Therefore, it just *has* to be great, doesn't
it? ;^b.
Seriously, I know what you're getting at. We need a first class
Dialog/Conversation/ProcessScope concept. We'll do *that* in JCP in the
next rev of the spec. For now, I'm suggesting we agree on something
simple that the two major JSF impls can implement in a compatible way.
Ed
--
| [EMAIL PROTECTED] | {home: 407 869 9587, office: 408 884 9519 OR x31640}
| homepage: | http://purl.oclc.org/NET/edburns/
| aim: edburns0sunw | iim: [EMAIL PROTECTED]
| 45 Business Days until JavaOne SF 2006
Re: Dojo + myfaces upfront refactoring warning
Werner Punz schrieb: Laurie Harper schrieb: Hmm, I thought there were XHTML compliance issues with having script tags in the body? That's why I queried this in the first place :) Although it appears to work, valid or not. To my understanding you can embed scripts in the body in xhtml but you have to add them as CDATA . As for the onload etc... there are some issues, I cannot say that I wont shift the require and includes into the head again or not, but as is it has to be in the body in certain situations, there is no big deal in it having it in the body anyway, since the require is rendered only once anyway, the dojo utils take care of that. But keeping it in the body would render some dojo components useless, so I do not have a choice here until it is fixed. I will try to isolate the problem further, but for now the fix has to do it, since it does not break anything and follows the guidelines the dojo people give in their examples (they must be aware of those issues otherwise they would not have pushed the entire init part into the body) Ok no checkin yet, I ran into another problem: There is a huge issue with the jsessionid in dojo we have a situation which is javascript include src=...dojo.js;jsessionid=. now we have the problem that dojo uses that url and its parameters to load additional parts via ajax if not loaded. If we have the jsessionid in the url loading the url becomes too long for the ajaxed part of dojo and the loading of some component fails. I have to resolve that problem upfront now. Since the jsessionid is not really needed for dojo I probably will alter the uri loading the way that the jsessionid is not passed through for the dojo part.
[jira] Created: (TOMAHAWK-195) Wrong entry in AddRessource.properties causes Error-message
Wrong entry in AddRessource.properties causes Error-message --- Key: TOMAHAWK-195 URL: http://issues.apache.org/jira/browse/TOMAHAWK-195 Project: MyFaces Tomahawk Type: Bug Versions: 1.1.2-SNAPSHOT Reporter: Roland Schaal Priority: Minor I don't really know, what this file is exactly for, but I get a log-output 'Unparsable lastModified : @lastModified@' when using the nightly builds of tomahawk. Looking at the AddRessource.properties-file I see the entry [EMAIL PROTECTED]@ which probably causes the logging It ought to be in a format that can be parsed from the method MyFacesRessourceLoader.getLastModified() (format = -MM-dd HH:mm:ss Z). So there has to be something like lastModified=2006-03-01 15:23:34 -0400 in this file. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (TOMAHAWK-194) Wrong entry in AddRessource.properties causes Error-message
Wrong entry in AddRessource.properties causes Error-message --- Key: TOMAHAWK-194 URL: http://issues.apache.org/jira/browse/TOMAHAWK-194 Project: MyFaces Tomahawk Type: Bug Versions: 1.1.2-SNAPSHOT Reporter: Roland Schaal Priority: Minor I don't really know, what this file is exactly for, but I get a log-output 'Unparsable lastModified : @lastModified@' when using the nightly builds of tomahawk. Looking at the AddRessource.properties-file I see the entry [EMAIL PROTECTED]@ which probably causes the logging It ought to be in a format that can be parsed from the method MyFacesRessourceLoader.getLastModified() (format = -MM-dd HH:mm:ss Z). So there has to be something like lastModified=2006-03-01 15:23:34 -0400 in this file. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (TOMAHAWK-195) Wrong entry in AddRessource.properties causes Error-message
[ http://issues.apache.org/jira/browse/TOMAHAWK-195?page=all ] Roland Schaal closed TOMAHAWK-195: -- Resolution: Duplicate weird double-entry Wrong entry in AddRessource.properties causes Error-message --- Key: TOMAHAWK-195 URL: http://issues.apache.org/jira/browse/TOMAHAWK-195 Project: MyFaces Tomahawk Type: Bug Versions: 1.1.2-SNAPSHOT Reporter: Roland Schaal Priority: Minor I don't really know, what this file is exactly for, but I get a log-output 'Unparsable lastModified : @lastModified@' when using the nightly builds of tomahawk. Looking at the AddRessource.properties-file I see the entry [EMAIL PROTECTED]@ which probably causes the logging It ought to be in a format that can be parsed from the method MyFacesRessourceLoader.getLastModified() (format = -MM-dd HH:mm:ss Z). So there has to be something like lastModified=2006-03-01 15:23:34 -0400 in this file. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Created: (TOMAHAWK-195) Wrong entry in AddRessource.properties causes Error-message
Hi! URL: http://issues.apache.org/jira/browse/TOMAHAWK-195 Could someone with more maven knowledge have a look at it please. I guess there is some parsing missing. Thanks! Ciao, Mario
[jira] Created: (TOMAHAWK-196) PopupCalendar base href= tag
PopupCalendar base href= tag -- Key: TOMAHAWK-196 URL: http://issues.apache.org/jira/browse/TOMAHAWK-196 Project: MyFaces Tomahawk Type: Bug Components: Calendar Versions: 1.1.2-SNAPSHOT Reporter: Paul Klaer Fix For: 1.1.2-SNAPSHOT Popup Calender doesn't work if the base href tag is used in the html page. If you click on a date in the popup window the browser redirects the user to the base href tag. - http://www.example.com/faces/#; To avoid this myfaces has to stop the event like for the close button closeCalendarLink with the Event.stop(event); script. I apply a patch tested on IE, Firefox and Opera. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (TOMAHAWK-196) PopupCalendar base href= tag
[ http://issues.apache.org/jira/browse/TOMAHAWK-196?page=all ] Paul Klaer updated TOMAHAWK-196: PopupCalendar base href= tag -- Key: TOMAHAWK-196 URL: http://issues.apache.org/jira/browse/TOMAHAWK-196 Project: MyFaces Tomahawk Type: Bug Components: Calendar Versions: 1.1.2-SNAPSHOT Reporter: Paul Klaer Fix For: 1.1.2-SNAPSHOT Popup Calender doesn't work if the base href tag is used in the html page. If you click on a date in the popup window the browser redirects the user to the base href tag. - http://www.example.com/faces/#; To avoid this myfaces has to stop the event like for the close button closeCalendarLink with the Event.stop(event); script. I apply a patch tested on IE, Firefox and Opera. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Committers/contributors meeting at J1?
+1 Manfred On 3/10/06, Stan Silvert [EMAIL PROTECTED] wrote: In addition to dinner, what do you guys think of having a more serious meeting for committers and other contributors? Since we have grown so much, I think it would be a great opportunity to do some organizational/informational sessions and discussions. Stan Silvert JBoss, Inc. [EMAIL PROTECTED] callto://stansilvert
[jira] Created: (MYFACES-1171) Dont render clear_formName if not in MyFacesForm
Dont render clear_formName if not in MyFacesForm -- Key: MYFACES-1171 URL: http://issues.apache.org/jira/browse/MYFACES-1171 Project: MyFaces Core Type: Bug Versions: 1.1.3-SNAPSHOT Reporter: Martin Koci Priority: Minor HtmlCommandButtonRenderer alway renders onclick=clear_formName. But this will work only if myfaces form renderer was used. With custom form renderer (and with ADF faces renderer kit too) function 'clear_formName does not exist in output html. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Committers/contributors meeting at J1?
+1 regards, Martin On 3/13/06, Manfred Geiler [EMAIL PROTECTED] wrote: +1 Manfred On 3/10/06, Stan Silvert [EMAIL PROTECTED] wrote: In addition to dinner, what do you guys think of having a more serious meeting for committers and other contributors? Since we have grown so much, I think it would be a great opportunity to do some organizational/informational sessions and discussions. Stan Silvert JBoss, Inc. [EMAIL PROTECTED] callto://stansilvert -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: ADF Faces MyFaces merge dates
That depends on community building and the process of the project running through the incubator - we can't commit on a certain date. regards, Martin On 3/12/06, Nick Gudushauri [EMAIL PROTECTED] wrote: Hi All, Can you specify approximately date when ADF Faces refactoring (package and tag name changes) and merging with MyFaces will be complete? Thanks, Nick Gudushauri -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Fwd: IMPORTANT: Change of schedule for Incubator Board Reports
Looks like we have to write up an incubator report very early... ;) regards, Martin -- Forwarded message -- From: Brett Porter [EMAIL PROTECTED] Date: Mar 13, 2006 3:48 AM Subject: Re: IMPORTANT: Change of schedule for Incubator Board Reports To: general@incubator.apache.org I'd say start with the newest ones to see how they are going with their set up, licensing, etc: ActiveMQ ADF Faces Cayenne Kabuki log4net Lokahi Ode OFBiz ServiceMix Solr WebWork 2 wadi Yoko That's 13 right there, only a few of which have had to report before. - Brett On 3/13/06, Noel J. Bergman [EMAIL PROTECTED] wrote: The ASF Board would like for the Incubator to deliver a board report every month, rather than every quarter. For most of you, this will not result in additional work, since each podling will still only report quarterly. The current list of projects, http://incubator.apache.org/projects, consists of: ActiveMQ ADF Faces Apollo Agila AltRMI Cayenne Felix FtpServer Graffito Harmony Hermes Jackrabbit JuiCE Kabuki log4net log4php Lokahi Lucene4c mod_ftp Muse Ode OFBiz Roller ServiceMix Solr stdcxx Synapse TSIK Tobago Tuscany WebWork 2 wadi Woden WSRP4J Yoko That is 35 projects, or 12 per month. And, yes, some of the projects on the list are already graduated, but until the WS PMC responds to repeated requests to clean up the files for Apollo, Hermes, and Muse, I'm going to keep pinging them. In any event, which 12 projects would like to volunteer to provide a brief report? Or do we have to draw straws? ;-) --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
[jira] Commented: (MYFACES-1170) Application can not start if xercesImpl-2.7.1.jar is present
[ http://issues.apache.org/jira/browse/MYFACES-1170?page=comments#action_12370168 ] Boris Kovalenko commented on MYFACES-1170: -- Specification-Version: 1.5 from MANIFEST.MF Application can not start if xercesImpl-2.7.1.jar is present Key: MYFACES-1170 URL: http://issues.apache.org/jira/browse/MYFACES-1170 Project: MyFaces Core Type: Bug Versions: 1.1.2-SNAPSHOT Environment: Any OS, Resin 3.0.18, JDK 1.4.2 Reporter: Boris Kovalenko If xercesImpl-2.7.1.jar is present in application lib directory the application can not start with exception: java.lang.NullPointerException at org.apache.commons.digester.Digester.getXMLReader(Digester.java:899) at org.apache.commons.digester.Digester.parse(Digester.java:1647) at org.apache.myfaces.config.impl.digester.DigesterFacesConfigUnmarshallerImpl.getFacesConfig(DigesterFacesConfigUnmarshallerImpl.java:183) at org.apache.myfaces.config.FacesConfigurator.feedStandardConfig(FacesConfigurator.java:141) at org.apache.myfaces.config.FacesConfigurator.configure(FacesConfigurator.java:115) at org.apache.myfaces.webapp.StartupServletContextListener.initFaces(StartupServletContextListener.java:63) at org.apache.myfaces.webapp.StartupServletContextListener.contextInitialized(StartupServletContextListener.java:46) at com.caucho.server.webapp.Application.start(Application.java:1592) at com.caucho.server.deploy.DeployController.startImpl(DeployController.java:587) at com.caucho.server.deploy.StartAutoRedeployAutoStrategy.startOnInit(StartAutoRedeployAutoStrategy.java:72) at com.caucho.server.deploy.DeployController.startOnInit(DeployController.java:475) at com.caucho.server.deploy.DeployContainer.start(DeployContainer.java:158) at com.caucho.server.webapp.ApplicationContainer.start(ApplicationContainer.java:651) at com.caucho.server.host.Host.start(Host.java:385) at com.caucho.server.deploy.DeployController.startImpl(DeployController.java:587) at com.caucho.server.deploy.StartAutoRedeployAutoStrategy.startOnInit(StartAutoRedeployAutoStrategy.java:72) at com.caucho.server.deploy.DeployController.startOnInit(DeployController.java:475) at com.caucho.server.deploy.DeployContainer.start(DeployContainer.java:158) at com.caucho.server.host.HostContainer.start(HostContainer.java:467) at com.caucho.server.resin.ServletServer.start(ServletServer.java:945) at com.caucho.server.deploy.DeployController.startImpl(DeployController.java:587) at com.caucho.server.deploy.AbstractDeployControllerStrategy.start(AbstractDeployControllerStrategy.java:56) at com.caucho.server.deploy.DeployController.start(DeployController.java:483) at com.caucho.server.resin.ResinServer.start(ResinServer.java:478) at com.caucho.server.resin.Resin.init(Resin.java) at com.caucho.server.resin.Resin.main(Resin.java:623) I'm not sure this is MyFaces trouble, but with downgrade to 1.1.1 release the problem has gone. I use commons-digester-1.7.jar -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-1170) Application can not start if xercesImpl-2.7.1.jar is present
[ http://issues.apache.org/jira/browse/MYFACES-1170?page=comments#action_12370162 ] Martin Marinschek commented on MYFACES-1170: Hi Boris, can you find out which version Facelets has? Look into the META-INF directory of the jar-file, and you should find the version-number. regards, Martin Application can not start if xercesImpl-2.7.1.jar is present Key: MYFACES-1170 URL: http://issues.apache.org/jira/browse/MYFACES-1170 Project: MyFaces Core Type: Bug Versions: 1.1.2-SNAPSHOT Environment: Any OS, Resin 3.0.18, JDK 1.4.2 Reporter: Boris Kovalenko If xercesImpl-2.7.1.jar is present in application lib directory the application can not start with exception: java.lang.NullPointerException at org.apache.commons.digester.Digester.getXMLReader(Digester.java:899) at org.apache.commons.digester.Digester.parse(Digester.java:1647) at org.apache.myfaces.config.impl.digester.DigesterFacesConfigUnmarshallerImpl.getFacesConfig(DigesterFacesConfigUnmarshallerImpl.java:183) at org.apache.myfaces.config.FacesConfigurator.feedStandardConfig(FacesConfigurator.java:141) at org.apache.myfaces.config.FacesConfigurator.configure(FacesConfigurator.java:115) at org.apache.myfaces.webapp.StartupServletContextListener.initFaces(StartupServletContextListener.java:63) at org.apache.myfaces.webapp.StartupServletContextListener.contextInitialized(StartupServletContextListener.java:46) at com.caucho.server.webapp.Application.start(Application.java:1592) at com.caucho.server.deploy.DeployController.startImpl(DeployController.java:587) at com.caucho.server.deploy.StartAutoRedeployAutoStrategy.startOnInit(StartAutoRedeployAutoStrategy.java:72) at com.caucho.server.deploy.DeployController.startOnInit(DeployController.java:475) at com.caucho.server.deploy.DeployContainer.start(DeployContainer.java:158) at com.caucho.server.webapp.ApplicationContainer.start(ApplicationContainer.java:651) at com.caucho.server.host.Host.start(Host.java:385) at com.caucho.server.deploy.DeployController.startImpl(DeployController.java:587) at com.caucho.server.deploy.StartAutoRedeployAutoStrategy.startOnInit(StartAutoRedeployAutoStrategy.java:72) at com.caucho.server.deploy.DeployController.startOnInit(DeployController.java:475) at com.caucho.server.deploy.DeployContainer.start(DeployContainer.java:158) at com.caucho.server.host.HostContainer.start(HostContainer.java:467) at com.caucho.server.resin.ServletServer.start(ServletServer.java:945) at com.caucho.server.deploy.DeployController.startImpl(DeployController.java:587) at com.caucho.server.deploy.AbstractDeployControllerStrategy.start(AbstractDeployControllerStrategy.java:56) at com.caucho.server.deploy.DeployController.start(DeployController.java:483) at com.caucho.server.resin.ResinServer.start(ResinServer.java:478) at com.caucho.server.resin.Resin.init(Resin.java) at com.caucho.server.resin.Resin.main(Resin.java:623) I'm not sure this is MyFaces trouble, but with downgrade to 1.1.1 release the problem has gone. I use commons-digester-1.7.jar -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Commented: (MYFACES-1170) Application can not start if xercesImpl-2.7.1.jar is present
Martin Marinschek (JIRA) wrote: Hello! Specification-Version: 1.5 Implementation-Version: 1.5 from MANIFEST.MF [ http://issues.apache.org/jira/browse/MYFACES-1170?page=comments#action_12370162 ] Martin Marinschek commented on MYFACES-1170: Hi Boris, can you find out which version Facelets has? Look into the META-INF directory of the jar-file, and you should find the version-number. regards, Martin Application can not start if xercesImpl-2.7.1.jar is present Key: MYFACES-1170 URL: http://issues.apache.org/jira/browse/MYFACES-1170 Project: MyFaces Core Type: Bug Versions: 1.1.2-SNAPSHOT Environment: Any OS, Resin 3.0.18, JDK 1.4.2 Reporter: Boris Kovalenko If xercesImpl-2.7.1.jar is present in application lib directory the application can not start with exception: java.lang.NullPointerException at org.apache.commons.digester.Digester.getXMLReader(Digester.java:899) at org.apache.commons.digester.Digester.parse(Digester.java:1647) at org.apache.myfaces.config.impl.digester.DigesterFacesConfigUnmarshallerImpl.getFacesConfig(DigesterFacesConfigUnmarshallerImpl.java:183) at org.apache.myfaces.config.FacesConfigurator.feedStandardConfig(FacesConfigurator.java:141) at org.apache.myfaces.config.FacesConfigurator.configure(FacesConfigurator.java:115) at org.apache.myfaces.webapp.StartupServletContextListener.initFaces(StartupServletContextListener.java:63) at org.apache.myfaces.webapp.StartupServletContextListener.contextInitialized(StartupServletContextListener.java:46) at com.caucho.server.webapp.Application.start(Application.java:1592) at com.caucho.server.deploy.DeployController.startImpl(DeployController.java:587) at com.caucho.server.deploy.StartAutoRedeployAutoStrategy.startOnInit(StartAutoRedeployAutoStrategy.java:72) at com.caucho.server.deploy.DeployController.startOnInit(DeployController.java:475) at com.caucho.server.deploy.DeployContainer.start(DeployContainer.java:158) at com.caucho.server.webapp.ApplicationContainer.start(ApplicationContainer.java:651) at com.caucho.server.host.Host.start(Host.java:385) at com.caucho.server.deploy.DeployController.startImpl(DeployController.java:587) at com.caucho.server.deploy.StartAutoRedeployAutoStrategy.startOnInit(StartAutoRedeployAutoStrategy.java:72) at com.caucho.server.deploy.DeployController.startOnInit(DeployController.java:475) at com.caucho.server.deploy.DeployContainer.start(DeployContainer.java:158) at com.caucho.server.host.HostContainer.start(HostContainer.java:467) at com.caucho.server.resin.ServletServer.start(ServletServer.java:945) at com.caucho.server.deploy.DeployController.startImpl(DeployController.java:587) at com.caucho.server.deploy.AbstractDeployControllerStrategy.start(AbstractDeployControllerStrategy.java:56) at com.caucho.server.deploy.DeployController.start(DeployController.java:483) at com.caucho.server.resin.ResinServer.start(ResinServer.java:478) at com.caucho.server.resin.Resin.init(Resin.java) at com.caucho.server.resin.Resin.main(Resin.java:623) I'm not sure this is MyFaces trouble, but with downgrade to 1.1.1 release the problem has gone. I use commons-digester-1.7.jar With respect, Boris
[jira] Commented: (MYFACES-1170) Application can not start if xercesImpl-2.7.1.jar is present
[ http://issues.apache.org/jira/browse/MYFACES-1170?page=comments#action_12370169 ] Boris Kovalenko commented on MYFACES-1170: -- Specification-Version: 1.5 from MANIFEST.MF Application can not start if xercesImpl-2.7.1.jar is present Key: MYFACES-1170 URL: http://issues.apache.org/jira/browse/MYFACES-1170 Project: MyFaces Core Type: Bug Versions: 1.1.2-SNAPSHOT Environment: Any OS, Resin 3.0.18, JDK 1.4.2 Reporter: Boris Kovalenko If xercesImpl-2.7.1.jar is present in application lib directory the application can not start with exception: java.lang.NullPointerException at org.apache.commons.digester.Digester.getXMLReader(Digester.java:899) at org.apache.commons.digester.Digester.parse(Digester.java:1647) at org.apache.myfaces.config.impl.digester.DigesterFacesConfigUnmarshallerImpl.getFacesConfig(DigesterFacesConfigUnmarshallerImpl.java:183) at org.apache.myfaces.config.FacesConfigurator.feedStandardConfig(FacesConfigurator.java:141) at org.apache.myfaces.config.FacesConfigurator.configure(FacesConfigurator.java:115) at org.apache.myfaces.webapp.StartupServletContextListener.initFaces(StartupServletContextListener.java:63) at org.apache.myfaces.webapp.StartupServletContextListener.contextInitialized(StartupServletContextListener.java:46) at com.caucho.server.webapp.Application.start(Application.java:1592) at com.caucho.server.deploy.DeployController.startImpl(DeployController.java:587) at com.caucho.server.deploy.StartAutoRedeployAutoStrategy.startOnInit(StartAutoRedeployAutoStrategy.java:72) at com.caucho.server.deploy.DeployController.startOnInit(DeployController.java:475) at com.caucho.server.deploy.DeployContainer.start(DeployContainer.java:158) at com.caucho.server.webapp.ApplicationContainer.start(ApplicationContainer.java:651) at com.caucho.server.host.Host.start(Host.java:385) at com.caucho.server.deploy.DeployController.startImpl(DeployController.java:587) at com.caucho.server.deploy.StartAutoRedeployAutoStrategy.startOnInit(StartAutoRedeployAutoStrategy.java:72) at com.caucho.server.deploy.DeployController.startOnInit(DeployController.java:475) at com.caucho.server.deploy.DeployContainer.start(DeployContainer.java:158) at com.caucho.server.host.HostContainer.start(HostContainer.java:467) at com.caucho.server.resin.ServletServer.start(ServletServer.java:945) at com.caucho.server.deploy.DeployController.startImpl(DeployController.java:587) at com.caucho.server.deploy.AbstractDeployControllerStrategy.start(AbstractDeployControllerStrategy.java:56) at com.caucho.server.deploy.DeployController.start(DeployController.java:483) at com.caucho.server.resin.ResinServer.start(ResinServer.java:478) at com.caucho.server.resin.Resin.init(Resin.java) at com.caucho.server.resin.Resin.main(Resin.java:623) I'm not sure this is MyFaces trouble, but with downgrade to 1.1.1 release the problem has gone. I use commons-digester-1.7.jar -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-1170) Application can not start if xercesImpl-2.7.1.jar is present
[ http://issues.apache.org/jira/browse/MYFACES-1170?page=comments#action_12370172 ] Martin Marinschek commented on MYFACES-1170: Interesting - a bug in commons-digester versions after 1.5. Can you tell that to our colleagues over at commons-digester? Thanks, regards, Martin Application can not start if xercesImpl-2.7.1.jar is present Key: MYFACES-1170 URL: http://issues.apache.org/jira/browse/MYFACES-1170 Project: MyFaces Core Type: Bug Versions: 1.1.2-SNAPSHOT Environment: Any OS, Resin 3.0.18, JDK 1.4.2 Reporter: Boris Kovalenko If xercesImpl-2.7.1.jar is present in application lib directory the application can not start with exception: java.lang.NullPointerException at org.apache.commons.digester.Digester.getXMLReader(Digester.java:899) at org.apache.commons.digester.Digester.parse(Digester.java:1647) at org.apache.myfaces.config.impl.digester.DigesterFacesConfigUnmarshallerImpl.getFacesConfig(DigesterFacesConfigUnmarshallerImpl.java:183) at org.apache.myfaces.config.FacesConfigurator.feedStandardConfig(FacesConfigurator.java:141) at org.apache.myfaces.config.FacesConfigurator.configure(FacesConfigurator.java:115) at org.apache.myfaces.webapp.StartupServletContextListener.initFaces(StartupServletContextListener.java:63) at org.apache.myfaces.webapp.StartupServletContextListener.contextInitialized(StartupServletContextListener.java:46) at com.caucho.server.webapp.Application.start(Application.java:1592) at com.caucho.server.deploy.DeployController.startImpl(DeployController.java:587) at com.caucho.server.deploy.StartAutoRedeployAutoStrategy.startOnInit(StartAutoRedeployAutoStrategy.java:72) at com.caucho.server.deploy.DeployController.startOnInit(DeployController.java:475) at com.caucho.server.deploy.DeployContainer.start(DeployContainer.java:158) at com.caucho.server.webapp.ApplicationContainer.start(ApplicationContainer.java:651) at com.caucho.server.host.Host.start(Host.java:385) at com.caucho.server.deploy.DeployController.startImpl(DeployController.java:587) at com.caucho.server.deploy.StartAutoRedeployAutoStrategy.startOnInit(StartAutoRedeployAutoStrategy.java:72) at com.caucho.server.deploy.DeployController.startOnInit(DeployController.java:475) at com.caucho.server.deploy.DeployContainer.start(DeployContainer.java:158) at com.caucho.server.host.HostContainer.start(HostContainer.java:467) at com.caucho.server.resin.ServletServer.start(ServletServer.java:945) at com.caucho.server.deploy.DeployController.startImpl(DeployController.java:587) at com.caucho.server.deploy.AbstractDeployControllerStrategy.start(AbstractDeployControllerStrategy.java:56) at com.caucho.server.deploy.DeployController.start(DeployController.java:483) at com.caucho.server.resin.ResinServer.start(ResinServer.java:478) at com.caucho.server.resin.Resin.init(Resin.java) at com.caucho.server.resin.Resin.main(Resin.java:623) I'm not sure this is MyFaces trouble, but with downgrade to 1.1.1 release the problem has gone. I use commons-digester-1.7.jar -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Dojo + myfaces upfront refactoring warning
Werner Punz schrieb: Werner Punz schrieb: Laurie Harper schrieb: Hmm, I thought there were XHTML compliance issues with having script tags in the body? That's why I queried this in the first place :) Although it appears to work, valid or not. To my understanding you can embed scripts in the body in xhtml but you have to add them as CDATA . As for the onload etc... there are some issues, I cannot say that I wont shift the require and includes into the head again or not, but as is it has to be in the body in certain situations, there is no big deal in it having it in the body anyway, since the require is rendered only once anyway, the dojo utils take care of that. But keeping it in the body would render some dojo components useless, so I do not have a choice here until it is fixed. I will try to isolate the problem further, but for now the fix has to do it, since it does not break anything and follows the guidelines the dojo people give in their examples (they must be aware of those issues otherwise they would not have pushed the entire init part into the body) Ok no checkin yet, I ran into another problem: There is a huge issue with the jsessionid in dojo we have a situation which is javascript include src=...dojo.js;jsessionid=. now we have the problem that dojo uses that url and its parameters to load additional parts via ajax if not loaded. If we have the jsessionid in the url loading the url becomes too long for the ajaxed part of dojo and the loading of some component fails. I have to resolve that problem upfront now. Since the jsessionid is not really needed for dojo I probably will alter the uri loading the way that the jsessionid is not passed through for the dojo part. Correction, the jsessionid in the dojo imports are not needed if client side cookies are enabled, can we live with an enforcement for that policy now until I can clean up this mess on the dojo side (or the dojo people can clean it up)
[jira] Updated: (TOMAHAWK-197) More CSS for TabbedPane (incl. patch with solution)
[ http://issues.apache.org/jira/browse/TOMAHAWK-197?page=all ]
Wolfgang Engelhard updated TOMAHAWK-197:
More CSS for TabbedPane (incl. patch with solution)
---
Key: TOMAHAWK-197
URL: http://issues.apache.org/jira/browse/TOMAHAWK-197
Project: MyFaces Tomahawk
Type: New Feature
Components: Tabbed Pane
Environment: N/A
Reporter: Wolfgang Engelhard
Priority: Minor
For better control of style on your tabbed pane you need attribute id or
style for the tag tr.
The following patch (created with eclipse and NOT TESTED ) should address
this (you need to adjust the paths to your workspace requirements, sorry for
the inconvenience).
Please test first, even if changes are minor, as I wasn't able to compile
this (dependencies and build environment) !
This may also solve some of Jim Wrights issues, tomahawk-22 and tomahawk-54.
Expected problems are:
- writeAttribute not working as expected and
- no documentation of additionally available styles.
### patch begin, copy and paste from next line till end ##
Index:
D:/projects/tomahawk/src/main/java/org/apache/myfaces/custom/tabbedpane/HtmlTabbedPaneRenderer.java
===
---
D:/projects/tomahawk/src/main/java/org/apache/myfaces/custom/tabbedpane/HtmlTabbedPaneRenderer.java
(revision 385479)
+++
D:/projects/tomahawk/src/main/java/org/apache/myfaces/custom/tabbedpane/HtmlTabbedPaneRenderer.java
(working copy)
@@ -44,15 +44,18 @@
public class HtmlTabbedPaneRenderer
extends HtmlRenderer
{
+private static final String HEADER_ROW_CLASS =
myFaces_pannelTabbedPane_HeaderRow;
private static final String ACTIVE_HEADER_CELL_CLASS =
myFaces_panelTabbedPane_activeHeaderCell;
private static final String INACTIVE_HEADER_CELL_CLASS =
myFaces_panelTabbedPane_inactiveHeaderCell;
private static final String DISABLED_HEADER_CELL_CLASS =
myFaces_panelTabbedPane_disabledHeaderCell;
private static final String EMPTY_HEADER_CELL_CLASS =
myFaces_panelTabbedPane_emptyHeaderCell;
+private static final String SUB_HEADER_ROW_CLASS =
myFaces_pannelTabbedPane_subHeaderRow;
private static final String SUB_HEADER_CELL_CLASS =
myFaces_panelTabbedPane_subHeaderCell;
private static final String SUB_HEADER_CELL_CLASS_ACTIVE =
myFaces_panelTabbedPane_subHeaderCell_active;
private static final String SUB_HEADER_CELL_CLASS_INACTIVE =
myFaces_panelTabbedPane_subHeaderCell_inactive;
private static final String SUB_HEADER_CELL_CLASS_FIRST =
myFaces_panelTabbedPane_subHeaderCell_first;
private static final String SUB_HEADER_CELL_CLASS_LAST =
myFaces_panelTabbedPane_subHeaderCell_last;
+private static final String CONTENT_ROW_CLASS =
myFaces_panelTabbedPane_contentRow;
private static final String TAB_PANE_CLASS =
myFaces_panelTabbedPane_pane;
private static final String DEFAULT_BG_COLOR = white;
@@ -164,6 +167,7 @@
writeTableStart(writer, facesContext, tabbedPane);
HtmlRendererUtils.writePrettyLineSeparator(facesContext);
writer.startElement(HTML.TR_ELEM, tabbedPane);
+writer.writeAttribute(HTML.CLASS_ATTR, HEADER_ROW_CLASS, null);
//Tab headers
int tabIdx = 0;
@@ -207,6 +211,7 @@
//Sub header cells
HtmlRendererUtils.writePrettyLineSeparator(facesContext);
writer.startElement(HTML.TR_ELEM, tabbedPane);
+writer.writeAttribute(HTML.CLASS_ATTR, SUB_HEADER_ROW_CLASS, null);
writeSubHeaderCells(writer, facesContext, tabbedPane,
visibleTabCount, visibleTabSelectedIdx);
HtmlRendererUtils.writePrettyLineSeparator(facesContext);
writer.endElement(HTML.TR_ELEM);
@@ -214,6 +219,7 @@
//Tabs
HtmlRendererUtils.writePrettyLineSeparator(facesContext);
writer.startElement(HTML.TR_ELEM, tabbedPane);
+writer.writeAttribute(HTML.CLASS_ATTR, CONTENT_ROW_CLASS, null);
writer.startElement(HTML.TD_ELEM, tabbedPane);
writer.writeAttribute(HTML.COLSPAN_ATTR,
Integer.toString(visibleTabCount + 1), null);
String tabContentStyleClass = tabbedPane.getTabContentStyleClass();
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Created: (TOMAHAWK-197) More CSS for TabbedPane (incl. patch with solution)
More CSS for TabbedPane (incl. patch with solution)
---
Key: TOMAHAWK-197
URL: http://issues.apache.org/jira/browse/TOMAHAWK-197
Project: MyFaces Tomahawk
Type: New Feature
Components: Tabbed Pane
Environment: N/A
Reporter: Wolfgang Engelhard
Priority: Minor
For better control of style on your tabbed pane you need attribute id or style
for the tag tr.
The following patch (created with eclipse and NOT TESTED ) should address this
(you need to adjust the paths to your workspace requirements, sorry for the
inconvenience).
Please test first, even if changes are minor, as I wasn't able to compile this
(dependencies and build environment) !
This may also solve some of Jim Wrights issues, tomahawk-22 and tomahawk-54.
Expected problems are:
- writeAttribute not working as expected and
- no documentation of additionally available styles.
### patch begin, copy and paste from next line till end ##
Index:
D:/projects/tomahawk/src/main/java/org/apache/myfaces/custom/tabbedpane/HtmlTabbedPaneRenderer.java
===
---
D:/projects/tomahawk/src/main/java/org/apache/myfaces/custom/tabbedpane/HtmlTabbedPaneRenderer.java
(revision 385479)
+++
D:/projects/tomahawk/src/main/java/org/apache/myfaces/custom/tabbedpane/HtmlTabbedPaneRenderer.java
(working copy)
@@ -44,15 +44,18 @@
public class HtmlTabbedPaneRenderer
extends HtmlRenderer
{
+private static final String HEADER_ROW_CLASS =
myFaces_pannelTabbedPane_HeaderRow;
private static final String ACTIVE_HEADER_CELL_CLASS =
myFaces_panelTabbedPane_activeHeaderCell;
private static final String INACTIVE_HEADER_CELL_CLASS =
myFaces_panelTabbedPane_inactiveHeaderCell;
private static final String DISABLED_HEADER_CELL_CLASS =
myFaces_panelTabbedPane_disabledHeaderCell;
private static final String EMPTY_HEADER_CELL_CLASS =
myFaces_panelTabbedPane_emptyHeaderCell;
+private static final String SUB_HEADER_ROW_CLASS =
myFaces_pannelTabbedPane_subHeaderRow;
private static final String SUB_HEADER_CELL_CLASS =
myFaces_panelTabbedPane_subHeaderCell;
private static final String SUB_HEADER_CELL_CLASS_ACTIVE =
myFaces_panelTabbedPane_subHeaderCell_active;
private static final String SUB_HEADER_CELL_CLASS_INACTIVE =
myFaces_panelTabbedPane_subHeaderCell_inactive;
private static final String SUB_HEADER_CELL_CLASS_FIRST =
myFaces_panelTabbedPane_subHeaderCell_first;
private static final String SUB_HEADER_CELL_CLASS_LAST =
myFaces_panelTabbedPane_subHeaderCell_last;
+private static final String CONTENT_ROW_CLASS =
myFaces_panelTabbedPane_contentRow;
private static final String TAB_PANE_CLASS =
myFaces_panelTabbedPane_pane;
private static final String DEFAULT_BG_COLOR = white;
@@ -164,6 +167,7 @@
writeTableStart(writer, facesContext, tabbedPane);
HtmlRendererUtils.writePrettyLineSeparator(facesContext);
writer.startElement(HTML.TR_ELEM, tabbedPane);
+writer.writeAttribute(HTML.CLASS_ATTR, HEADER_ROW_CLASS, null);
//Tab headers
int tabIdx = 0;
@@ -207,6 +211,7 @@
//Sub header cells
HtmlRendererUtils.writePrettyLineSeparator(facesContext);
writer.startElement(HTML.TR_ELEM, tabbedPane);
+writer.writeAttribute(HTML.CLASS_ATTR, SUB_HEADER_ROW_CLASS, null);
writeSubHeaderCells(writer, facesContext, tabbedPane, visibleTabCount,
visibleTabSelectedIdx);
HtmlRendererUtils.writePrettyLineSeparator(facesContext);
writer.endElement(HTML.TR_ELEM);
@@ -214,6 +219,7 @@
//Tabs
HtmlRendererUtils.writePrettyLineSeparator(facesContext);
writer.startElement(HTML.TR_ELEM, tabbedPane);
+writer.writeAttribute(HTML.CLASS_ATTR, CONTENT_ROW_CLASS, null);
writer.startElement(HTML.TD_ELEM, tabbedPane);
writer.writeAttribute(HTML.COLSPAN_ATTR,
Integer.toString(visibleTabCount + 1), null);
String tabContentStyleClass = tabbedPane.getTabContentStyleClass();
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
Re: hibernate validator
I agree, it would be very nice and avoid double validation code for the hibernate users. It would also prevent meaning less errors for the users and show the exact problem. Great idea ! Sylvain. On Sat, 2006-03-11 at 17:45 +0100, Jurgen Lust wrote: How about this approach? You annotate your model classes with Hibernate Validator annotations, for example @Range(min=10, max=20) You don't put any validators in the JSPs You implement a custom PropertyResolverImpl that does the following: set the property perform the validation with HibernateValidator on the property if the value is invalid, set the property to its original value and throw an EvaluationException The JSP is rendered with a FacesMessage next to the input, containing the Hibernate Validator error message. Advantages: All validation is in 1 place, the model class, where it belongs Much cleaner JSP Disadvantages: You completely bypass the JSF process validations phase, however, since the custom PropertyResolver would reset the property to its old value when a validation error occurs, this would not really be a problem. This approach would not work at the moment, or at least until MYFACES-1157 is fixed. Any ideas? Jurgen Jurgen Lust schreef: Hi, I've been playing around with Hibernate Annotations a bit, and noticed that there is also something like the Hibernate Validator: http://www.hibernate.org/hib_docs/annotations/reference/en/html/validator.html This allows you to specify constraints on your model classes, using jdk 5.0 annotations. Hibernate then automatically enforces these contraints in the persistence tier of your application. Now I was thinking that this could also be used with JSF. Instead of putting all the JSF validation stuff in the JSPs, you should be able to use those annotations in the validate phase. Has anyone tried this yet? Would it be possible, and are there any pitfalls? regards, Jurgen
Re: hibernate validator
There might be some overlap here with Seam-- we've already implemented some of this. Sylvain Vieujot wrote: I agree, it would be very nice and avoid double validation code for the hibernate users. It would also prevent meaning less errors for the users and show the exact problem. Great idea ! Sylvain. On Sat, 2006-03-11 at 17:45 +0100, Jurgen Lust wrote: How about this approach? 1. You annotate your model classes with Hibernate Validator annotations, for example @Range(min=10, max=20) 2. You don't put any validators in the JSPs 3. You implement a custom PropertyResolverImpl that does the following: 1. set the property 2. perform the validation with HibernateValidator on the property 3. if the value is invalid, set the property to its original value and throw an EvaluationException 4. The JSP is rendered with a FacesMessage next to the input, containing the Hibernate Validator error message. Advantages: * All validation is in 1 place, the model class, where it belongs * Much cleaner JSP Disadvantages: * You completely bypass the JSF process validations phase, however, since the custom PropertyResolver would reset the property to its old value when a validation error occurs, this would not really be a problem. This approach would not work at the moment, or at least until MYFACES-1157 is fixed. Any ideas? Jurgen Jurgen Lust schreef: Hi, I've been playing around with Hibernate Annotations a bit, and noticed that there is also something like the Hibernate Validator: http://www.hibernate.org/hib_docs/annotations/reference/en/html/validator.html This allows you to specify constraints on your model classes, using jdk 5.0 annotations. Hibernate then automatically enforces these contraints in the persistence tier of your application. Now I was thinking that this could also be used with JSF. Instead of putting all the JSF validation stuff in the JSPs, you should be able to use those annotations in the validate phase. Has anyone tried this yet? Would it be possible, and are there any pitfalls? regards, Jurgen -- Jacob Hookom - Minneapolis JSF-EG, JSF-RI, EL, Facelets
Re: hibernate validator
Hi! I do this in FacesFreeway too. But here I also generate the required components and thus I can attach any validator I want. To have it cleanly integrated in the phases of jsf we have to instrument the tree after it has been created (yes martin, I know this is a no-no for the standard ;-) ) But you can create your own view-handler and process all UIInputs after createView parse the binding get its annotations and attach an appropiated validator. This wont work with components e.g. within an table or any other components where the reference of the binding is only reachable during the encoding phase. Its more often the case than you might think ;-) Doing this after the validation phase - during update model is a hack, isnt it? e.g. it will fire valueChanges where the value to be changed to might be and invalid value, no? Ciao, Mario There might be some overlap here with Seam-- we've already implemented some of this. Sylvain Vieujot wrote: I agree, it would be very nice and avoid double validation code for the hibernate users. It would also prevent meaning less errors for the users and show the exact problem. Great idea ! Sylvain. On Sat, 2006-03-11 at 17:45 +0100, Jurgen Lust wrote: How about this approach? 1. You annotate your model classes with Hibernate Validator annotations, for example @Range(min=10, max=20) 2. You don't put any validators in the JSPs 3. You implement a custom PropertyResolverImpl that does the following: 1. set the property 2. perform the validation with HibernateValidator on the property 3. if the value is invalid, set the property to its original value and throw an EvaluationException 4. The JSP is rendered with a FacesMessage next to the input, containing the Hibernate Validator error message. Advantages: * All validation is in 1 place, the model class, where it belongs * Much cleaner JSP Disadvantages: * You completely bypass the JSF process validations phase, however, since the custom PropertyResolver would reset the property to its old value when a validation error occurs, this would not really be a problem. This approach would not work at the moment, or at least until MYFACES-1157 is fixed. Any ideas? Jurgen Jurgen Lust schreef: Hi, I've been playing around with Hibernate Annotations a bit, and noticed that there is also something like the Hibernate Validator: http://www.hibernate.org/hib_docs/annotations/reference/en/html/validator.html This allows you to specify constraints on your model classes, using jdk 5.0 annotations. Hibernate then automatically enforces these contraints in the persistence tier of your application. Now I was thinking that this could also be used with JSF. Instead of putting all the JSF validation stuff in the JSPs, you should be able to use those annotations in the validate phase. Has anyone tried this yet? Would it be possible, and are there any pitfalls? regards, Jurgen -- mfg Mario Ivankovits - OPS EDV Vertriebsges.m.b.H. Software Engineering Michael-Bernhard-Gasse 10, A-1120 Wien Tel.: +43-1-8938810 Fax: +43-1-8938810/3700 E-Mail: [EMAIL PROTECTED] Skype: mario_ivankovits
Re: hibernate validator
Hmm, I hadn't thought about the value change events yet. That would be a problem. I first had the idea to plugin a custom LifeCycleImpl, that does not invoke the validator of each component, but instead calls the hibernate validator on each property, but the problem there is that Hibernate Validator is best used to validate an entire bean in one go (or at least, that's how I understand it). Jurgen Mario Ivankovits schreef: Hi! I do this in FacesFreeway too. But here I also generate the required components and thus I can attach any validator I want. To have it cleanly integrated in the phases of jsf we have to instrument the tree after it has been created (yes martin, I know this is a no-no for the standard ;-) ) But you can create your own view-handler and process all UIInputs after createView parse the binding get its annotations and attach an appropiated validator. This wont work with components e.g. within an table or any other components where the reference of the binding is only reachable during the encoding phase. Its more often the case than you might think ;-) Doing this after the validation phase - during update model is a hack, isnt it? e.g. it will fire valueChanges where the value to be changed to might be and invalid value, no? Ciao, Mario There might be some overlap here with Seam-- we've already implemented some of this. Sylvain Vieujot wrote: I agree, it would be very nice and avoid double validation code for the hibernate users. It would also prevent meaning less errors for the users and show the exact problem. Great idea ! Sylvain. On Sat, 2006-03-11 at 17:45 +0100, Jurgen Lust wrote: How about this approach? 1. You annotate your model classes with Hibernate Validator annotations, for example @Range(min=10, max=20) 2. You don't put any validators in the JSPs 3. You implement a custom PropertyResolverImpl that does the following: 1. set the property 2. perform the validation with HibernateValidator on the property 3. if the value is invalid, set the property to its original value and throw an EvaluationException 4. The JSP is rendered with a FacesMessage next to the input, containing the Hibernate Validator error message. Advantages: * All validation is in 1 place, the model class, where it belongs * Much cleaner JSP Disadvantages: * You completely bypass the JSF process validations phase, however, since the custom PropertyResolver would reset the property to its old value when a validation error occurs, this would not really be a problem. This approach would not work at the moment, or at least until MYFACES-1157 is fixed. Any ideas? Jurgen Jurgen Lust schreef: Hi, I've been playing around with Hibernate Annotations a bit, and noticed that there is also something like the Hibernate Validator: http://www.hibernate.org/hib_docs/annotations/reference/en/html/validator.html This allows you to specify constraints on your model classes, using jdk 5.0 annotations. Hibernate then automatically enforces these contraints in the persistence tier of your application. Now I was thinking that this could also be used with JSF. Instead of putting all the JSF validation stuff in the JSPs, you should be able to use those annotations in the validate phase. Has anyone tried this yet? Would it be possible, and are there any pitfalls? regards, Jurgen
[jira] Updated: (TOMAHAWK-187) ClassCastException using panelTabbedPane in nightly build
[ http://issues.apache.org/jira/browse/TOMAHAWK-187?page=all ]
Roland Schaal updated TOMAHAWK-187:
---
ClassCastException using panelTabbedPane in nightly build
-
Key: TOMAHAWK-187
URL: http://issues.apache.org/jira/browse/TOMAHAWK-187
Project: MyFaces Tomahawk
Type: Bug
Components: Tabbed Pane
Versions: 1.1.2-SNAPSHOT
Reporter: Roland Schaal
Attachments: HtmlPanelTabbedPane.java
Hello,
When using
serverSideTabSwitch=true
I get the following ClassCastException:
java.lang.ClassCastException
at
org.apache.myfaces.custom.tabbedpane.HtmlPanelTabbedPane.isClientSide(HtmlPanelTabbedPane.java:142)
at
org.apache.myfaces.custom.tabbedpane.HtmlTabbedPaneRenderer.encodeEnd(HtmlTabbedPaneRenderer.java:92)
at
javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:536)
at
org.apache.myfaces.shared_impl.renderkit.RendererUtils.renderChild(RendererUtils.java:442)
at
org.apache.myfaces.shared_impl.renderkit.RendererUtils.renderChildren(RendererUtils.java:419)
at
org.apache.myfaces.shared_impl.renderkit.html.HtmlGroupRendererBase.encodeEnd(HtmlGroupRendererBase.java:75)
at
javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:536)
at
org.apache.myfaces.shared_impl.renderkit.RendererUtils.renderChild(RendererUtils.java:442)
at
org.apache.myfaces.shared_impl.renderkit.html.HtmlGridRendererBase.renderChildren(HtmlGridRendererBase.java:216)
...
Looking at the code of HtmlPanelTabbedPane it seems to me that they try to
cast a String- into a Boolean-object, which causes the exception:
public boolean isClientSide(){
Boolean serverSideTabSwitch =
(Boolean)getAttributes().get(serverSideTabSwitch);
return serverSideTabSwitch != null ? !serverSideTabSwitch.booleanValue() :
true;
}
Regards,
Roland Schaal
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (TOMAHAWK-187) ClassCastException using panelTabbedPane in nightly build
[ http://issues.apache.org/jira/browse/TOMAHAWK-187?page=all ]
Roland Schaal updated TOMAHAWK-187:
---
ClassCastException using panelTabbedPane in nightly build
-
Key: TOMAHAWK-187
URL: http://issues.apache.org/jira/browse/TOMAHAWK-187
Project: MyFaces Tomahawk
Type: Bug
Components: Tabbed Pane
Versions: 1.1.2-SNAPSHOT
Reporter: Roland Schaal
Attachments: HtmlPanelTabbedPane.java
Hello,
When using
serverSideTabSwitch=true
I get the following ClassCastException:
java.lang.ClassCastException
at
org.apache.myfaces.custom.tabbedpane.HtmlPanelTabbedPane.isClientSide(HtmlPanelTabbedPane.java:142)
at
org.apache.myfaces.custom.tabbedpane.HtmlTabbedPaneRenderer.encodeEnd(HtmlTabbedPaneRenderer.java:92)
at
javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:536)
at
org.apache.myfaces.shared_impl.renderkit.RendererUtils.renderChild(RendererUtils.java:442)
at
org.apache.myfaces.shared_impl.renderkit.RendererUtils.renderChildren(RendererUtils.java:419)
at
org.apache.myfaces.shared_impl.renderkit.html.HtmlGroupRendererBase.encodeEnd(HtmlGroupRendererBase.java:75)
at
javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:536)
at
org.apache.myfaces.shared_impl.renderkit.RendererUtils.renderChild(RendererUtils.java:442)
at
org.apache.myfaces.shared_impl.renderkit.html.HtmlGridRendererBase.renderChildren(HtmlGridRendererBase.java:216)
...
Looking at the code of HtmlPanelTabbedPane it seems to me that they try to
cast a String- into a Boolean-object, which causes the exception:
public boolean isClientSide(){
Boolean serverSideTabSwitch =
(Boolean)getAttributes().get(serverSideTabSwitch);
return serverSideTabSwitch != null ? !serverSideTabSwitch.booleanValue() :
true;
}
Regards,
Roland Schaal
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
hibernate validator PhaseListener
A few days there was a thread on using Hibernate Validator. Here is a
quick prototype. I've only played with a tiny bit, so I'm sure there are
issues:
-barry
package org.opentrader.infra.jsf.validation;
import java.util.Collection;
import java.util.Map;
import javax.faces.application.FacesMessage;
import javax.faces.context.ExternalContext;
import javax.faces.context.FacesContext;
import javax.faces.event.PhaseEvent;
import javax.faces.event.PhaseId;
import javax.faces.event.PhaseListener;
import org.hibernate.validator.InvalidValue;
import org.opentrader.infra.validation.BeanValidator;
import org.opentrader.infra.validation.ValidatedBean;
import org.springframework.context.ApplicationContext;
import org.springframework.web.jsf.WebApplicationContextVariableResolver;
// TODO Test and harden this spike.
public class HibernateValidatorPhaseListener implements PhaseListener {
private BeanValidator beanValidator;
public PhaseId getPhaseId() {
return PhaseId.PROCESS_VALIDATIONS;
}
public void beforePhase(PhaseEvent arg0) {
//empty
}
public void afterPhase(PhaseEvent event) {
FacesContext facesContext = event.getFacesContext();
ExternalContext externalContext = facesContext.getExternalContext();
BeanValidator validator = getValidator(externalContext);
processValidators(externalContext.getRequestMap(), facesContext,
validator);
processValidators(externalContext.getSessionMap(), facesContext,
validator);
}
@SuppressWarnings(unchecked)
private BeanValidator getValidator(ExternalContext externalContext) {
if (beanValidator == null) {
ApplicationContext context = (ApplicationContext)
externalContext.getApplicationMap().get(
WebApplicationContextVariableResolver.WEB_APPLICATION_CONTEXT_VARIABLE_NAME);
MapString, BeanValidator beans =
context.getBeansOfType(BeanValidator.class);
if (beans.size() == 0) {
throw new IllegalStateException(Bean of class
BeanValidator not found in application-context);
}
if (beans.size() == 0) {
throw new IllegalStateException(More than one bean of
class BeanValidator found in application-context: beans= + beans.keySet());
}
beanValidator = beans.values().iterator().next();
}
return beanValidator;
}
private void processValidators(Map scope, FacesContext facesContext,
BeanValidator validator) {
Collection collection = scope.values();
for (Object object : collection) {
if
(object.getClass().isAnnotationPresent(ValidatedBean.class)) {
InvalidValue[] invalidValues =
validator.validateBean(object);
if (invalidValues.length 0) {
addFacesMessages(invalidValues, facesContext);
}
}
}
}
private void addFacesMessages(InvalidValue[] invalidValues,
FacesContext facesContext) {
for (InvalidValue invalidValue : invalidValues) {
FacesMessage message = new FacesMessage();
message.setSeverity(FacesMessage.SEVERITY_ERROR);
message.setSummary(invalidValue.toString());
message.setDetail(invalidValue.toString());
facesContext.addMessage(null, message);
}
}
}
[jira] Commented: (MYFACES-1163) JBoss classloading fails if myfaces jars installed in tomcat
[ http://issues.apache.org/jira/browse/MYFACES-1163?page=comments#action_12370204 ] Stan Silvert commented on MYFACES-1163: --- Fix committed to trunk. Dennis will test this evening. The fix consists of: Move MyFacesObjectInputStream from impl to share. Change StateUtils to use MyFacesObjectInputStream Change JspStateManagerImpl to use MyFacesObjectInputStream JBoss classloading fails if myfaces jars installed in tomcat Key: MYFACES-1163 URL: http://issues.apache.org/jira/browse/MYFACES-1163 Project: MyFaces Core Type: Bug Versions: 1.1.2-SNAPSHOT, 1.1.2, 1.1.3-SNAPSHOT Environment: JBoss 4.0.4RC1 myfaces-1.1.3-SNAPSHOT Reporter: Ingo Massen Assignee: Stan Silvert Cannot use Myfaces jars installed in JBOSS_HOME/server/default/deploy/jbossweb-tomcat55.sar/jsf-libs as they do not use the correct WebappClassloader but instead an UCL3 classloader. This is because myfaces use the following line in StateUtils.getAsObject ObjectInputStream s = new ObjectInputStream(input); instead of import org.apache.myfaces.shared.util.MyFacesObjectInputStream; ObjectInputStream s = new MyFacesObjectInputStream(input); The same applies to JspStateManagerImpl.deserializeView(). ObjectInputStream uses Class.forName instead of Thread.currentThread().getContextClassLoader() as the ClassUtils implementation that MyFacesObjectInputStream uses does. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-1163) JBoss classloading fails if myfaces jars installed in tomcat
[ http://issues.apache.org/jira/browse/MYFACES-1163?page=comments#action_12370206 ] Stan Silvert commented on MYFACES-1163: --- Ingo, Can you try this out as well. Actually I should have asked you before bothering Dennis (though I assume he is interested in it too). Stan JBoss classloading fails if myfaces jars installed in tomcat Key: MYFACES-1163 URL: http://issues.apache.org/jira/browse/MYFACES-1163 Project: MyFaces Core Type: Bug Versions: 1.1.2-SNAPSHOT, 1.1.2, 1.1.3-SNAPSHOT Environment: JBoss 4.0.4RC1 myfaces-1.1.3-SNAPSHOT Reporter: Ingo Massen Assignee: Stan Silvert Cannot use Myfaces jars installed in JBOSS_HOME/server/default/deploy/jbossweb-tomcat55.sar/jsf-libs as they do not use the correct WebappClassloader but instead an UCL3 classloader. This is because myfaces use the following line in StateUtils.getAsObject ObjectInputStream s = new ObjectInputStream(input); instead of import org.apache.myfaces.shared.util.MyFacesObjectInputStream; ObjectInputStream s = new MyFacesObjectInputStream(input); The same applies to JspStateManagerImpl.deserializeView(). ObjectInputStream uses Class.forName instead of Thread.currentThread().getContextClassLoader() as the ClassUtils implementation that MyFacesObjectInputStream uses does. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (TOMAHAWK-187) ClassCastException using panelTabbedPane in nightly build
[
http://issues.apache.org/jira/browse/TOMAHAWK-187?page=comments#action_12370207
]
Mike Kienenberger commented on TOMAHAWK-187:
Roland,
Excellent! This is the right direction to go with this patch.
Nice catch on the saveState/restoreState issue. I'm surprised that the missing
state saving hasn't caused bug reports!
I would recommend this format which returns a boolean instead of a Boolean and
also allows setting a constant in the java file when serverSideTabSwitch isn't
defined.
public boolean getServerSideTabSwitch()
{
if (_displayValueOnly != null) return _displayValueOnly.booleanValue();
ValueBinding vb = getValueBinding(displayValueOnly);
Boolean v = vb != null ? (Boolean)vb.getValue(getFacesContext()) : null;
return v != null ? v.booleanValue() : DEFAULT_SERVER_SIDE_TAB_SWITCH;
}
You also need to change isClientSide which currently isn't calling your code.
public boolean isClientSide(){
Boolean serverSideTabSwitch =
(Boolean)getAttributes().get(serverSideTabSwitch);
return serverSideTabSwitch != null ?
!serverSideTabSwitch.booleanValue() : true;
}
to
public boolean isClientSide(){
return getServerSideTabSwitch();
}
It'd also be helpful if you'd submit your patches in patch format (unified
diff).
-Mike
ClassCastException using panelTabbedPane in nightly build
-
Key: TOMAHAWK-187
URL: http://issues.apache.org/jira/browse/TOMAHAWK-187
Project: MyFaces Tomahawk
Type: Bug
Components: Tabbed Pane
Versions: 1.1.2-SNAPSHOT
Reporter: Roland Schaal
Attachments: HtmlPanelTabbedPane.java
Hello,
When using
serverSideTabSwitch=true
I get the following ClassCastException:
java.lang.ClassCastException
at
org.apache.myfaces.custom.tabbedpane.HtmlPanelTabbedPane.isClientSide(HtmlPanelTabbedPane.java:142)
at
org.apache.myfaces.custom.tabbedpane.HtmlTabbedPaneRenderer.encodeEnd(HtmlTabbedPaneRenderer.java:92)
at
javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:536)
at
org.apache.myfaces.shared_impl.renderkit.RendererUtils.renderChild(RendererUtils.java:442)
at
org.apache.myfaces.shared_impl.renderkit.RendererUtils.renderChildren(RendererUtils.java:419)
at
org.apache.myfaces.shared_impl.renderkit.html.HtmlGroupRendererBase.encodeEnd(HtmlGroupRendererBase.java:75)
at
javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:536)
at
org.apache.myfaces.shared_impl.renderkit.RendererUtils.renderChild(RendererUtils.java:442)
at
org.apache.myfaces.shared_impl.renderkit.html.HtmlGridRendererBase.renderChildren(HtmlGridRendererBase.java:216)
...
Looking at the code of HtmlPanelTabbedPane it seems to me that they try to
cast a String- into a Boolean-object, which causes the exception:
public boolean isClientSide(){
Boolean serverSideTabSwitch =
(Boolean)getAttributes().get(serverSideTabSwitch);
return serverSideTabSwitch != null ? !serverSideTabSwitch.booleanValue() :
true;
}
Regards,
Roland Schaal
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (TOMAHAWK-187) ClassCastException using panelTabbedPane in nightly build
[
http://issues.apache.org/jira/browse/TOMAHAWK-187?page=comments#action_12370208
]
Mike Kienenberger commented on TOMAHAWK-187:
Oops. Of course, you'll want to change references to displayValueOnly to
serverSideTabSwitch :-)
public boolean getServerSideTabSwitch()
{
if (_displayValueOnly != null) return
_serverSideTabSwitch.booleanValue();
ValueBinding vb = getValueBinding(serverSideTabSwitch);
Boolean v = vb != null ? (Boolean)vb.getValue(getFacesContext()) : null;
return v != null ? v.booleanValue() : DEFAULT_SERVER_SIDE_TAB_SWITCH;
}
ClassCastException using panelTabbedPane in nightly build
-
Key: TOMAHAWK-187
URL: http://issues.apache.org/jira/browse/TOMAHAWK-187
Project: MyFaces Tomahawk
Type: Bug
Components: Tabbed Pane
Versions: 1.1.2-SNAPSHOT
Reporter: Roland Schaal
Attachments: HtmlPanelTabbedPane.java
Hello,
When using
serverSideTabSwitch=true
I get the following ClassCastException:
java.lang.ClassCastException
at
org.apache.myfaces.custom.tabbedpane.HtmlPanelTabbedPane.isClientSide(HtmlPanelTabbedPane.java:142)
at
org.apache.myfaces.custom.tabbedpane.HtmlTabbedPaneRenderer.encodeEnd(HtmlTabbedPaneRenderer.java:92)
at
javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:536)
at
org.apache.myfaces.shared_impl.renderkit.RendererUtils.renderChild(RendererUtils.java:442)
at
org.apache.myfaces.shared_impl.renderkit.RendererUtils.renderChildren(RendererUtils.java:419)
at
org.apache.myfaces.shared_impl.renderkit.html.HtmlGroupRendererBase.encodeEnd(HtmlGroupRendererBase.java:75)
at
javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:536)
at
org.apache.myfaces.shared_impl.renderkit.RendererUtils.renderChild(RendererUtils.java:442)
at
org.apache.myfaces.shared_impl.renderkit.html.HtmlGridRendererBase.renderChildren(HtmlGridRendererBase.java:216)
...
Looking at the code of HtmlPanelTabbedPane it seems to me that they try to
cast a String- into a Boolean-object, which causes the exception:
public boolean isClientSide(){
Boolean serverSideTabSwitch =
(Boolean)getAttributes().get(serverSideTabSwitch);
return serverSideTabSwitch != null ? !serverSideTabSwitch.booleanValue() :
true;
}
Regards,
Roland Schaal
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
Re: commit to 1.1.2?
There is a Continuum build failure. It has been acting weird lately so don't be suprised if this is not your fault. Dennis Byrne -Original Message- From: Stan Silvert [mailto:[EMAIL PROTECTED] Sent: Monday, March 13, 2006 11:32 AM To: 'Dennis Byrne' Subject: RE: commit to 1.1.2? Right. Now that MyFacesObjectInputStream is in the same package with StatUtils, the change was just a one-liner. For JspStateManagerImpl, it was just a new import and one-line change. I just did a fresh checkout, so your changes to StateUtils should be included. I will commit now. Please let me know when you are done testing. Thanks for your help, Stan Silvert JBoss, Inc. [EMAIL PROTECTED] callto://stansilvert
Re: hibernate validator PhaseListener
Definitely a very interesting approach; one problem is that it'll
validate too much. For example, it'll validate beans that aren't
even used on the current page. It'll also validate beans that
aren't yet valid because they're being created and populated
over multiple pages, and beans that weren't set on this request
because they're in a different form (or subform) than the one
that was submitted.
The interesting question is how to tie an annotation
driven approach like this - which I really like - to all of
the information resident in the UIComponent tree.
-- Adam
On 3/13/06, Barry Kaplan [EMAIL PROTECTED] wrote:
A few days there was a thread on using Hibernate Validator. Here is a
quick prototype. I've only played with a tiny bit, so I'm sure there are
issues:
-barry
package org.opentrader.infra.jsf.validation;
import java.util.Collection;
import java.util.Map;
import javax.faces.application.FacesMessage;
import javax.faces.context.ExternalContext;
import javax.faces.context.FacesContext;
import javax.faces.event.PhaseEvent;
import javax.faces.event.PhaseId;
import javax.faces.event.PhaseListener;
import org.hibernate.validator.InvalidValue;
import org.opentrader.infra.validation.BeanValidator;
import org.opentrader.infra.validation.ValidatedBean;
import org.springframework.context.ApplicationContext;
import org.springframework.web.jsf.WebApplicationContextVariableResolver;
// TODO Test and harden this spike.
public class HibernateValidatorPhaseListener implements PhaseListener {
private BeanValidator beanValidator;
public PhaseId getPhaseId() {
return PhaseId.PROCESS_VALIDATIONS;
}
public void beforePhase(PhaseEvent arg0) {
//empty
}
public void afterPhase(PhaseEvent event) {
FacesContext facesContext = event.getFacesContext();
ExternalContext externalContext = facesContext.getExternalContext();
BeanValidator validator = getValidator(externalContext);
processValidators(externalContext.getRequestMap(), facesContext,
validator);
processValidators(externalContext.getSessionMap(), facesContext,
validator);
}
@SuppressWarnings(unchecked)
private BeanValidator getValidator(ExternalContext externalContext) {
if (beanValidator == null) {
ApplicationContext context = (ApplicationContext)
externalContext.getApplicationMap().get(
WebApplicationContextVariableResolver.WEB_APPLICATION_CONTEXT_VARIABLE_NAME);
MapString, BeanValidator beans =
context.getBeansOfType(BeanValidator.class);
if (beans.size() == 0) {
throw new IllegalStateException(Bean of class
BeanValidator not found in application-context);
}
if (beans.size() == 0) {
throw new IllegalStateException(More than one bean of
class BeanValidator found in application-context: beans= + beans.keySet());
}
beanValidator = beans.values().iterator().next();
}
return beanValidator;
}
private void processValidators(Map scope, FacesContext facesContext,
BeanValidator validator) {
Collection collection = scope.values();
for (Object object : collection) {
if
(object.getClass().isAnnotationPresent(ValidatedBean.class)) {
InvalidValue[] invalidValues =
validator.validateBean(object);
if (invalidValues.length 0) {
addFacesMessages(invalidValues, facesContext);
}
}
}
}
private void addFacesMessages(InvalidValue[] invalidValues,
FacesContext facesContext) {
for (InvalidValue invalidValue : invalidValues) {
FacesMessage message = new FacesMessage();
message.setSeverity(FacesMessage.SEVERITY_ERROR);
message.setSummary(invalidValue.toString());
message.setDetail(invalidValue.toString());
facesContext.addMessage(null, message);
}
}
}
Re: hibernate validator
Would be cool if the annotations stayed w/in JSR 220. For example, a lot us already have this in our models @Column(name = crew_id, unique = false, nullable = false, insertable = true, updatable = true, length = 255, precision = 19, scale = 2) It would be weird, but it could be used by people NOT using ejb3 . Dennis Byrne -Original Message- From: Sylvain Vieujot [mailto:[EMAIL PROTECTED] Sent: Monday, March 13, 2006 09:35 AM To: 'MyFaces Development' Subject: Re: hibernate validator I agree, it would be very nice and avoid double validation code for the hibernate users. It would also prevent meaning less errors for the users and show the exact problem. Great idea ! Sylvain. On Sat, 2006-03-11 at 17:45 +0100, Jurgen Lust wrote: How about this approach? 1. You annotate your model classes with Hibernate Validator annotations, for example @Range(min=10, max=20) 2. You don't put any validators in the JSPs 3. You implement a custom PropertyResolverImpl that does the following: 1. set the property 2. perform the validation with HibernateValidator on the property 3. if the value is invalid, set the property to its original value and throw an EvaluationException 4. The JSP is rendered with a FacesMessage next to the input, containing the Hibernate Validator error message. Advantages: * All validation is in 1 place, the model class, where it belongs * Much cleaner JSP Disadvantages: * You completely bypass the JSF process validations phase, however, since the custom PropertyResolver would reset the property to its old value when a validation error occurs, this would not really be a problem. This approach would not work at the moment, or at least until MYFACES-1157 is fixed. Any ideas? Jurgen Jurgen Lust schreef: Hi, I've been playing around with Hibernate Annotations a bit, and noticed that there is also something like the Hibernate Validator: http://www.hibernate.org/hib_docs/annotations/reference/en/html/validator.html This allows you to specify constraints on your model classes, using jdk 5.0 annotations. Hibernate then automatically enforces these contraints in the persistence tier of your application. Now I was thinking that this could also be used with JSF. Instead of putting all the JSF validation stuff in the JSPs, you should be able to use those annotations in the validate phase. Has anyone tried this yet? Would it be possible, and are there any pitfalls? regards, Jurgen
Re: hibernate validator
Depending on how you do this, it might also allow you to work in db validation from non-Hibernate users who are also using JSR 220-compatible products, like OpenEJB and Cayenne, which are currently in the Incubator. On 3/13/06, Dennis Byrne [EMAIL PROTECTED] wrote: Would be cool if the annotations stayed w/in JSR 220. For example, a lot us already have this in our models @Column(name = crew_id, unique = false, nullable = false, insertable = true, updatable = true, length = 255, precision = 19, scale = 2) It would be weird, but it could be used by people NOT using ejb3 . Dennis Byrne -Original Message- From: Sylvain Vieujot [mailto:[EMAIL PROTECTED] Sent: Monday, March 13, 2006 09:35 AM To: 'MyFaces Development' Subject: Re: hibernate validator I agree, it would be very nice and avoid double validation code for the hibernate users. It would also prevent meaning less errors for the users and show the exact problem. Great idea ! Sylvain. On Sat, 2006-03-11 at 17:45 +0100, Jurgen Lust wrote: How about this approach? 1. You annotate your model classes with Hibernate Validator annotations, for example @Range(min=10, max=20) 2. You don't put any validators in the JSPs 3. You implement a custom PropertyResolverImpl that does the following: 1. set the property 2. perform the validation with HibernateValidator on the property 3. if the value is invalid, set the property to its original value and throw an EvaluationException 4. The JSP is rendered with a FacesMessage next to the input, containing the Hibernate Validator error message. Advantages: * All validation is in 1 place, the model class, where it belongs * Much cleaner JSP Disadvantages: * You completely bypass the JSF process validations phase, however, since the custom PropertyResolver would reset the property to its old value when a validation error occurs, this would not really be a problem. This approach would not work at the moment, or at least until MYFACES-1157 is fixed. Any ideas? Jurgen Jurgen Lust schreef: Hi, I've been playing around with Hibernate Annotations a bit, and noticed that there is also something like the Hibernate Validator: http://www.hibernate.org/hib_docs/annotations/reference/en/html/validator.html This allows you to specify constraints on your model classes, using jdk 5.0 annotations. Hibernate then automatically enforces these contraints in the persistence tier of your application. Now I was thinking that this could also be used with JSF. Instead of putting all the JSF validation stuff in the JSPs, you should be able to use those annotations in the validate phase. Has anyone tried this yet? Would it be possible, and are there any pitfalls? regards, Jurgen
[jira] Commented: (TOMAHAWK-70) Add Support for Shale-Clay to Tomahawk
[ http://issues.apache.org/jira/browse/TOMAHAWK-70?page=comments#action_12370227 ] Richard Wallace commented on TOMAHAWK-70: - Alright, I figured out the problem with the class attribute on the td tag on a per cell basis. It wa my fault. Somehow the version I was using didn't have the renderType attribute overridden in the t:dataTable configuration. Thanks to Gary for pointing this out. What needs to be done to get this included in the distributed tomahawk.jar? Add Support for Shale-Clay to Tomahawk -- Key: TOMAHAWK-70 URL: http://issues.apache.org/jira/browse/TOMAHAWK-70 Project: MyFaces Tomahawk Type: Bug Reporter: Ryan Wynn Assignee: sean schofield Attachments: clay-config.xml, clay-tomahawk.war Shale-Clay is a very useful library that allows significant reuse of JSF components. In order to use Clay with Tomahawk, the Tomahawk jar would need to package a clay configuration in the META-INF folder of the jar. If Clay is used, this file will automatically be picked up by Clay. None Clay users would not be affected by the presence of the file. Attached is a base Shale configuration file for Tomahawk. Please consider adding this file to Tomahawk. It will eliminate the need for those wanting to use Shale-Tomahawk from having to create the file themselves. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-1170) Application can not start if xercesImpl-2.7.1.jar is present
[ http://issues.apache.org/jira/browse/MYFACES-1170?page=comments#action_12370234 ] Simon Kitching commented on MYFACES-1170: - Yes, it is a digester bug introduced by r132533. I'll have it patched by the end of today. However it only occurs in an unusual circumstance, as here. The problem is that Xerces is in the classpath, but it is not the xml parser being used; the stacktrace shows that the SAXParserFactory class is from com.caucho.xml. Digester sees Xerces in the classpath, assumes Xerces is the xml parser being used, and tries to set a xerces-specific property on the parser factory which of course fails. Either removing xerces from the classpath (it isn't being used) or actually forcing xerces to be used will resolve this issue. I presume that Resin is being used as the container here... Application can not start if xercesImpl-2.7.1.jar is present Key: MYFACES-1170 URL: http://issues.apache.org/jira/browse/MYFACES-1170 Project: MyFaces Core Type: Bug Versions: 1.1.2-SNAPSHOT Environment: Any OS, Resin 3.0.18, JDK 1.4.2 Reporter: Boris Kovalenko If xercesImpl-2.7.1.jar is present in application lib directory the application can not start with exception: java.lang.NullPointerException at org.apache.commons.digester.Digester.getXMLReader(Digester.java:899) at org.apache.commons.digester.Digester.parse(Digester.java:1647) at org.apache.myfaces.config.impl.digester.DigesterFacesConfigUnmarshallerImpl.getFacesConfig(DigesterFacesConfigUnmarshallerImpl.java:183) at org.apache.myfaces.config.FacesConfigurator.feedStandardConfig(FacesConfigurator.java:141) at org.apache.myfaces.config.FacesConfigurator.configure(FacesConfigurator.java:115) at org.apache.myfaces.webapp.StartupServletContextListener.initFaces(StartupServletContextListener.java:63) at org.apache.myfaces.webapp.StartupServletContextListener.contextInitialized(StartupServletContextListener.java:46) at com.caucho.server.webapp.Application.start(Application.java:1592) at com.caucho.server.deploy.DeployController.startImpl(DeployController.java:587) at com.caucho.server.deploy.StartAutoRedeployAutoStrategy.startOnInit(StartAutoRedeployAutoStrategy.java:72) at com.caucho.server.deploy.DeployController.startOnInit(DeployController.java:475) at com.caucho.server.deploy.DeployContainer.start(DeployContainer.java:158) at com.caucho.server.webapp.ApplicationContainer.start(ApplicationContainer.java:651) at com.caucho.server.host.Host.start(Host.java:385) at com.caucho.server.deploy.DeployController.startImpl(DeployController.java:587) at com.caucho.server.deploy.StartAutoRedeployAutoStrategy.startOnInit(StartAutoRedeployAutoStrategy.java:72) at com.caucho.server.deploy.DeployController.startOnInit(DeployController.java:475) at com.caucho.server.deploy.DeployContainer.start(DeployContainer.java:158) at com.caucho.server.host.HostContainer.start(HostContainer.java:467) at com.caucho.server.resin.ServletServer.start(ServletServer.java:945) at com.caucho.server.deploy.DeployController.startImpl(DeployController.java:587) at com.caucho.server.deploy.AbstractDeployControllerStrategy.start(AbstractDeployControllerStrategy.java:56) at com.caucho.server.deploy.DeployController.start(DeployController.java:483) at com.caucho.server.resin.ResinServer.start(ResinServer.java:478) at com.caucho.server.resin.Resin.init(Resin.java) at com.caucho.server.resin.Resin.main(Resin.java:623) I'm not sure this is MyFaces trouble, but with downgrade to 1.1.1 release the problem has gone. I use commons-digester-1.7.jar -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-434) MyFaces's Portlet enhancement
[ http://issues.apache.org/jira/browse/MYFACES-434?page=comments#action_12370263 ] Shinsuke SUGAYA commented on MYFACES-434: - Yes. If you want to use it on J2, headerresource_for_j2.tar.gz is needed. I'm providing myfaces-bridges as an other solution from SourceForge.jp, and also you can check the implementaion on some portlets, such as blog, notepad.. https://sourceforge.jp/projects/pal/ MyFaces's Portlet enhancement - Key: MYFACES-434 URL: http://issues.apache.org/jira/browse/MYFACES-434 Project: MyFaces Core Type: Improvement Versions: 1.1.0 Environment: LInux, J2SE 1.4.2 Reporter: Shinsuke SUGAYA Assignee: Stan Silvert Attachments: filter051230.patch, filter051230.tar.gz, filterportlet.patch, filterportlet.tar.gz, headerresource_for_j2.tar.gz, newfile_for_portlet.tar.gz, patch_for_portlet.patch MyFacesGenericPortlet does not fully support the feature of tomahawk component, such as inputHtml and fileUpload. So, I request the following feature to run it on portlet: - support tags in head (ex. inputHtml component) - support upload (fileUpload component) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Please fix svn:eol-style on poms
I'm trying to create a patch, but some of the poms have the wrong line endings. The three I need fixed are: core/impl/pom.xml commons/pom.xml shared/pom.xml Can someone please set $ svn propset svn:eol-style native pom.xml for them? Also core/assembly/pom.xml core/pom.xml maven/build-tools/pom.xml tomahawk/assembly/pom.xml tomahawk/examples/assembly/pom.xml tomahawk/sandbox/pom.xml Thanks, Wendy
[jira] Created: (TOMAHAWK-198) Extra jar in simple examples
Extra jar in simple examples Key: TOMAHAWK-198 URL: http://issues.apache.org/jira/browse/TOMAHAWK-198 Project: MyFaces Tomahawk Type: Bug Versions: 1.1.2-SNAPSHOT Environment: clean co from Mar. 12, 2006 Reporter: Dennis Byrne Priority: Minor After 'mvn install', under \tomahawk\examples\simple\target\myfaces-example-simple\WEB-INF\lib , there are ... tomahawk-1.1.2-SNAPSHOT.jar myfaces-shared-tomahawk-2.0.1-SNAPSHOT.jar The first one appears to be a superset of the second. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MYFACES-1173) Change the groupId for Shale Test Framework
Change the groupId for Shale Test Framework --- Key: MYFACES-1173 URL: http://issues.apache.org/jira/browse/MYFACES-1173 Project: MyFaces Core Type: Improvement Versions: 1.1.2-SNAPSHOT Reporter: Wendy Smoak Since I can't create a patch due to the problem with eol-style, can someone please make the following change in all the affected poms? dependency - groupIdstruts/groupId + groupIdorg.apache.struts.shale/groupId artifactIdshale-test/artifactId version1.0.1-SNAPSHOT/version scopetest/scope (Be careful not to change the one dependency on Struts 1.2.8 -- that one hasn't moved yet.) I've deployed the snapshot to the new location in cvs.apache.org/maven-snapshot-repository, and will leave the old one in place until I see the change go in. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-1163) JBoss classloading fails if myfaces jars installed in tomcat
[ http://issues.apache.org/jira/browse/MYFACES-1163?page=comments#action_12370319 ] Dennis Byrne commented on MYFACES-1163: --- Can either/both of you please give me a detailed set of instructions on how to reproduce this ( w/out facelets )? Please post a stacktrace or something. I believe you guys but I am having a hard time reproducing what may or may not be the problem. Some of the errors I'm getting both w/ and w/out Stan's patch have no explanation. JBoss classloading fails if myfaces jars installed in tomcat Key: MYFACES-1163 URL: http://issues.apache.org/jira/browse/MYFACES-1163 Project: MyFaces Core Type: Bug Versions: 1.1.2-SNAPSHOT, 1.1.2, 1.1.3-SNAPSHOT Environment: JBoss 4.0.4RC1 myfaces-1.1.3-SNAPSHOT Reporter: Ingo Massen Assignee: Stan Silvert Cannot use Myfaces jars installed in JBOSS_HOME/server/default/deploy/jbossweb-tomcat55.sar/jsf-libs as they do not use the correct WebappClassloader but instead an UCL3 classloader. This is because myfaces use the following line in StateUtils.getAsObject ObjectInputStream s = new ObjectInputStream(input); instead of import org.apache.myfaces.shared.util.MyFacesObjectInputStream; ObjectInputStream s = new MyFacesObjectInputStream(input); The same applies to JspStateManagerImpl.deserializeView(). ObjectInputStream uses Class.forName instead of Thread.currentThread().getContextClassLoader() as the ClassUtils implementation that MyFacesObjectInputStream uses does. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
