Re: which IDE are you using for JSF ?
We are using NetBeans with the mevenide plugin for maven support. We are also using Facelets and the new Facelets Netbeans plugin. That gives us autocomplete but not drag drop (I don't think). Seems to be working great. On a team of 5 two were PHP types before this project and one other had some experience in Java. The other two of us are pretty experienced Java programmers and helped bring the others along. Greg
Re : which IDE are you using for JSF ?
Thank you very much for the info. I've also found these liks after googling : Eclipse WTP (free) or - using Eclipse WTP as suggested by Rick Hightower [1], basically : . you need to rename .xhtml extension to jspx. . you need to add some jsp directives such as jsp:root). . I'm not sure, but expect some difficulties websphere appserver, all calls to jspx files are directed to jsp container. - More for Eclipse WTP : Mail exchange to add facelet suport to Eclipse WTP - don't know if there's something implemented now or if it's forgotten [3]. RAD (very commercial ;)): - same approach on RAD as WTP. But gives drag and drop capacities. . some more problems on RAD 6 : the designer adds ibm jsf libraries automatically on the first drag and drop, and some JSF components (such as f:view, hx:scriptCollector, h:form). Exadel Studio Pro (commercial) http://www.exadel.com/web/portal/products/ExadelStudioPro An old link on Myfaces wiki [2] [1] http://www-03.ibm.com/developerworks/blogs/page/JEE?entry=tutorial_for_stack_of_choice) [2] http://wiki.apache.org/myfaces/What_Tools_Do_You_Use_to_Develop_Web_Applications_Using_JSF [3] http://dev.eclipse.org/mhonarc/lists/wtp-jsf-dev/msg00223.html - Message d'origine De : Craig McClanahan [EMAIL PROTECTED] À : user@shale.apache.org Envoyé le : Vendredi, 2 Février 2007, 18h35mn 52s Objet : Re: which IDE are you using for JSF ? On 2/2/07, Adrian Gonzalez [EMAIL PROTECTED] wrote: Hello, Is there a good IDE (drag and drop and autocompletion for EL expressions and tags) for facelets or Clay technology ? What IDE are you using to create JSF apps ? NetBeans has out-of-the-box support for autocompletion of EL expressions in a JSP page. For facelets, there is a fairly new plugin[1] that I haven't tried yet, but is worth checking out. (By the way, and it's definitely not ready for prime time yet, I also just started a NetBeans plugin project for general Shale support[2]. Anyone who wants to contribute Clay related editing, or any other Shale features, for NB is welcome to join!) Craig [1] https://nbfaceletssupport.dev.java.net [2] https://nbshalesupport.dev.java.net My current purpose is to see if one can use JSF for mainstream development (developers with little experience in Java / web technologies), so drag drop, autocompletion would be a must - the company has currently developed ~100 web apps. Seeking advice on the trinidad user list, I've been given pointers to use facelets or shale Clay, to really AVOID JSP for rendering, and to ask to this mailing list (thanks Gary for the tip !), since there's a lot of knowledgeable people (such as Ryan Wynn ;)). I'm just using IBM RAD 6, and it's quite difficult (ibm proprietary components, JSF 1.0, JSP...) - I've integrated myfaces on it, simulating dummy ibm components - since IBM's are tied to SUN RI, but it's doesn't appear to be a good solution even if it's working. Thanks P.S. sorry this question is not really a Shale question ___ Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses http://fr.answers.yahoo.com ___ Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses http://fr.answers.yahoo.com
Re: stack traces from shale-clay-usecases
I was able to run the shale-clay-usecases in 10g (10.1.3.1.1) from JDeveloper Studio 10.1.3.2 but I had to make a few minor changes. For some reason, JDeveloper doesn't like that the shale-core and shale-validator jars have TLD files with the name taglib.tld? I renamed the TLD's and it was happy? I pulled down the trinidad maven plugin to build the JDeveloper project file and ran from the IDE. I had to include the JSP Runtime libraries too. I'm not sure if that's what you are seeing? It's weird that taglib.tld trips it up? Gary -- Original message -- From: John Carlson [EMAIL PROTECTED] I got a couple of stacktraces from the shale-clay-usecases using OC4J 10.1.3.1 (supposedly supports J2EE 1.4). I deployed the shale-clay-usecases.war and tried to use the rolodex use cases. None of the rolodex cases work, although the first use case page does work. Here are the 2 different kinds of stack traces I got. This is on Windows XP service pack 2. 500 Internal Server Error java.lang.NullPointerException at org.apache.shale.validator.CommonsValidator.getValidatorAction(CommonsValidator.java:739) at org.apache.shale.validator.faces.ValidatorScript.findCommonsValidators(ValidatorScript.java:260) at org.apache.shale.validator.faces.ValidatorScript.findCommonsValidators(ValidatorScript.java:301) at org.apache.shale.validator.faces.ValidatorScript.findCommonsValidators(ValidatorScript.java:301) at org.apache.shale.validator.faces.ValidatorScript.findCommonsValidators(ValidatorScript.java:301) at org.apache.shale.validator.faces.ValidatorScript.findCommonsValidators(ValidatorScript.java:301) at org.apache.shale.validator.faces.ValidatorScript.encodeBegin(ValidatorScript.java:649) at org.apache.shale.clay.component.Clay.recursiveRenderChildren(Clay.java:413) at org.apache.shale.clay.component.Clay.recursiveRenderChildren(Clay.java:416) at org.apache.shale.clay.component.Clay.encodeChildren(Clay.java:445) at org.apache.shale.clay.faces.ClayViewHandler.recursiveRender(ClayViewHandler.java:476) at org.apache.shale.clay.faces.ClayViewHandler.renderView(ClayViewHandler.java:402) at org.apache.shale.validator.faces.ValidatorViewHandler.renderView(ValidatorViewHandler.java:130) at org.apache.shale.view.faces.ViewViewHandler.renderView(ViewViewHandler.java:147) at org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:384) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:138) at com.evermind[Oracle Containers for J2EE 10g (10.1.3.1.0) ].server.http.ResourceFilterChain.doFilter(ResourceFilterChain.java:64) at org.apache.shale.application.faces.ShaleApplicationFilter.doFilter(ShaleApplicationFilter.java:267) at com.evermind[Oracle Containers for J2EE 10g (10.1.3.1.0) ].server.http.ServletRequestDispatcher.invoke(ServletRequestDispatcher.java:621) at com.evermind[Oracle Containers for J2EE 10g (10.1.3.1.0) ].server.http.ServletRequestDispatcher.forwardInternal(ServletRequestDispatcher.java:368) at com.evermind[Oracle Containers for J2EE 10g (10.1.3.1.0) ].server.http.HttpRequestHandler.doProcessRequest(HttpRequestHandler.java:866) at com.evermind[Oracle Containers for J2EE 10g (10.1.3.1.0) ].server.http.HttpRequestHandler.processRequest(HttpRequestHandler.java:448) at com.evermind[Oracle Containers for J2EE 10g (10.1.3.1.0) ].server.http.HttpRequestHandler.serveOneRequest(HttpRequestHandler.java:216) at com.evermind[Oracle Containers for J2EE 10g (10.1.3.1.0) ].server.http.HttpRequestHandler.run(HttpRequestHandler.java:117) at com.evermind[Oracle Containers for J2EE 10g (10.1.3.1.0) ].server.http.HttpRequestHandler.run(HttpRequestHandler.java:110) at oracle.oc4j.network.ServerSocketReadHandler$SafeRunnable.run(ServerSocketReadHandler.java:260) at com.evermind[Oracle Containers for J2EE 10g (10.1.3.1.0) ].util.ReleasableResourcePooledExecutor$MyWorker.run(ReleasableResourcePooledExecutor.java:303) at java.lang.Thread.run(Thread.java:595) 500 Internal Server Error javax.faces.FacesException: javax.servlet.ServletException at org.apache.myfaces.context.servlet.ServletExternalContextImpl.dispatch(ServletExternalContextImpl.java:426) at org.apache.myfaces.application.jsp.JspViewHandlerImpl.renderView(JspViewHandlerImpl.java:234) at org.apache.shale.clay.faces.ClayViewHandler.renderView(ClayViewHandler.java:450) at org.apache.shale.validator.faces.ValidatorViewHandler.renderView(ValidatorViewHandler.java:130) at org.apache.shale.view.faces.ViewViewHandler.renderView(ViewViewHandler.java:147) at org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:384) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:138) at com.evermind[Oracle Containers for J2EE
Re: stack traces from shale-clay-usecases
On 2/2/07, Gary VanMatre [EMAIL PROTECTED] wrote: I was able to run the shale-clay-usecases in 10g (10.1.3.1.1) from JDeveloper Studio 10.1.3.2 but I had to make a few minor changes. For some reason, JDeveloper doesn't like that the shale-core and shale-validator jars have TLD files with the name taglib.tld? I renamed the TLD's and it was happy? I pulled down the trinidad maven plugin to build the JDeveloper project file and ran from the IDE. I had to include the JSP Runtime libraries too. I'm not sure if that's what you are seeing? It's weird that taglib.tld trips it up? Gary -- Original message -- From: John Carlson [EMAIL PROTECTED] I got a couple of stacktraces from the shale-clay-usecases using OC4J 10.1.3.1 (supposedly supports J2EE 1.4). I deployed the shale-clay-usecases.war and tried to use the rolodex use cases. None of the rolodex cases work, although the first use case page does work. Here are the 2 different kinds of stack traces I got. This is on Windows XP service pack 2. 500 Internal Server Error java.lang.NullPointerException at org.apache.shale.validator.CommonsValidator.getValidatorAction( CommonsValidator.java:739) at org.apache.shale.validator.faces.ValidatorScript.findCommonsValidators( ValidatorScript.java:260) at org.apache.shale.validator.faces.ValidatorScript.findCommonsValidators( ValidatorScript.java:301) at org.apache.shale.validator.faces.ValidatorScript.findCommonsValidators( ValidatorScript.java:301) at org.apache.shale.validator.faces.ValidatorScript.findCommonsValidators( ValidatorScript.java:301) at org.apache.shale.validator.faces.ValidatorScript.findCommonsValidators( ValidatorScript.java:301) at org.apache.shale.validator.faces.ValidatorScript.encodeBegin( ValidatorScript.java:649) at org.apache.shale.clay.component.Clay.recursiveRenderChildren(Clay.java :413) at org.apache.shale.clay.component.Clay.recursiveRenderChildren(Clay.java :416) at org.apache.shale.clay.component.Clay.encodeChildren(Clay.java:445) at org.apache.shale.clay.faces.ClayViewHandler.recursiveRender( ClayViewHandler.java:476) at org.apache.shale.clay.faces.ClayViewHandler.renderView( ClayViewHandler.java:402) at org.apache.shale.validator.faces.ValidatorViewHandler.renderView( ValidatorViewHandler.java:130) at org.apache.shale.view.faces.ViewViewHandler.renderView( ViewViewHandler.java:147) at org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:384) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:138) at com.evermind[Oracle Containers for J2EE 10g (10.1.3.1.0) ].server.http.ResourceFilterChain.doFilter(ResourceFilterChain.java:64) at org.apache.shale.application.faces.ShaleApplicationFilter.doFilter( ShaleApplicationFilter.java:267) at com.evermind[Oracle Containers for J2EE 10g (10.1.3.1.0) ].server.http.ServletRequestDispatcher.invoke( ServletRequestDispatcher.java:621) at com.evermind[Oracle Containers for J2EE 10g (10.1.3.1.0) ].server.http.ServletRequestDispatcher.forwardInternal( ServletRequestDispatcher.java:368) at com.evermind[Oracle Containers for J2EE 10g (10.1.3.1.0) ].server.http.HttpRequestHandler.doProcessRequest(HttpRequestHandler.java :866) at com.evermind[Oracle Containers for J2EE 10g (10.1.3.1.0) ].server.http.HttpRequestHandler.processRequest(HttpRequestHandler.java :448) at com.evermind[Oracle Containers for J2EE 10g (10.1.3.1.0) ].server.http.HttpRequestHandler.serveOneRequest(HttpRequestHandler.java :216) at com.evermind[Oracle Containers for J2EE 10g (10.1.3.1.0) ].server.http.HttpRequestHandler.run(HttpRequestHandler.java:117) at com.evermind[Oracle Containers for J2EE 10g (10.1.3.1.0) ].server.http.HttpRequestHandler.run(HttpRequestHandler.java:110) at oracle.oc4j.network.ServerSocketReadHandler$SafeRunnable.run( ServerSocketReadHandler.java:260) at com.evermind[Oracle Containers for J2EE 10g (10.1.3.1.0) ].util.ReleasableResourcePooledExecutor$MyWorker.run( ReleasableResourcePooledExecutor.java:303) at java.lang.Thread.run(Thread.java:595) 500 Internal Server Error javax.faces.FacesException: javax.servlet.ServletException at org.apache.myfaces.context.servlet.ServletExternalContextImpl.dispatch( ServletExternalContextImpl.java:426) at org.apache.myfaces.application.jsp.JspViewHandlerImpl.renderView( JspViewHandlerImpl.java:234) at org.apache.shale.clay.faces.ClayViewHandler.renderView( ClayViewHandler.java:450) at org.apache.shale.validator.faces.ValidatorViewHandler.renderView( ValidatorViewHandler.java:130) at org.apache.shale.view.faces.ViewViewHandler.renderView( ViewViewHandler.java:147) at org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:384) at
Re: stack traces from shale-clay-usecases
On 2/2/07, Gary VanMatre [EMAIL PROTECTED] wrote: I was able to run the shale-clay-usecases in 10g (10.1.3.1.1) from JDeveloper Studio 10.1.3.2 but I had to make a few minor changes. For some reason, JDeveloper doesn't like that the shale-core and shale-validator jars have TLD files with the name taglib.tld? I renamed the TLD's and it was happy? I pulled down the trinidad maven plugin to build the JDeveloper project file and ran from the IDE. I had to include the JSP Runtime libraries too. I'm not sure if that's what you are seeing? It's weird that taglib.tld trips it up? Ignore the previous empty response -- that's what you get when you pet a cat who is pawing your mouse at that moment :-). It would definitely be wierd, but I can kind of sympathize with how someone writing the server side could make a naive assumption that these resource names are unique. At any rate, I'd be fine with making all of our META-INF/xxx.tld resource names unique. After all, it won't affect any users because they should not (can not?) make any direct references to these things. Gary Craig -- Original message -- From: John Carlson [EMAIL PROTECTED] I got a couple of stacktraces from the shale-clay-usecases using OC4J 10.1.3.1 (supposedly supports J2EE 1.4). I deployed the shale-clay-usecases.war and tried to use the rolodex use cases. None of the rolodex cases work, although the first use case page does work. Here are the 2 different kinds of stack traces I got. This is on Windows XP service pack 2. 500 Internal Server Error java.lang.NullPointerException at org.apache.shale.validator.CommonsValidator.getValidatorAction( CommonsValidator.java:739) at org.apache.shale.validator.faces.ValidatorScript.findCommonsValidators( ValidatorScript.java:260) at org.apache.shale.validator.faces.ValidatorScript.findCommonsValidators( ValidatorScript.java:301) at org.apache.shale.validator.faces.ValidatorScript.findCommonsValidators( ValidatorScript.java:301) at org.apache.shale.validator.faces.ValidatorScript.findCommonsValidators( ValidatorScript.java:301) at org.apache.shale.validator.faces.ValidatorScript.findCommonsValidators( ValidatorScript.java:301) at org.apache.shale.validator.faces.ValidatorScript.encodeBegin( ValidatorScript.java:649) at org.apache.shale.clay.component.Clay.recursiveRenderChildren(Clay.java :413) at org.apache.shale.clay.component.Clay.recursiveRenderChildren(Clay.java :416) at org.apache.shale.clay.component.Clay.encodeChildren(Clay.java:445) at org.apache.shale.clay.faces.ClayViewHandler.recursiveRender( ClayViewHandler.java:476) at org.apache.shale.clay.faces.ClayViewHandler.renderView( ClayViewHandler.java:402) at org.apache.shale.validator.faces.ValidatorViewHandler.renderView( ValidatorViewHandler.java:130) at org.apache.shale.view.faces.ViewViewHandler.renderView( ViewViewHandler.java:147) at org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:384) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:138) at com.evermind[Oracle Containers for J2EE 10g (10.1.3.1.0) ].server.http.ResourceFilterChain.doFilter(ResourceFilterChain.java:64) at org.apache.shale.application.faces.ShaleApplicationFilter.doFilter( ShaleApplicationFilter.java:267) at com.evermind[Oracle Containers for J2EE 10g (10.1.3.1.0) ].server.http.ServletRequestDispatcher.invoke( ServletRequestDispatcher.java:621) at com.evermind[Oracle Containers for J2EE 10g (10.1.3.1.0) ].server.http.ServletRequestDispatcher.forwardInternal( ServletRequestDispatcher.java:368) at com.evermind[Oracle Containers for J2EE 10g (10.1.3.1.0) ].server.http.HttpRequestHandler.doProcessRequest(HttpRequestHandler.java :866) at com.evermind[Oracle Containers for J2EE 10g (10.1.3.1.0) ].server.http.HttpRequestHandler.processRequest(HttpRequestHandler.java :448) at com.evermind[Oracle Containers for J2EE 10g (10.1.3.1.0) ].server.http.HttpRequestHandler.serveOneRequest(HttpRequestHandler.java :216) at com.evermind[Oracle Containers for J2EE 10g (10.1.3.1.0) ].server.http.HttpRequestHandler.run(HttpRequestHandler.java:117) at com.evermind[Oracle Containers for J2EE 10g (10.1.3.1.0) ].server.http.HttpRequestHandler.run(HttpRequestHandler.java:110) at oracle.oc4j.network.ServerSocketReadHandler$SafeRunnable.run( ServerSocketReadHandler.java:260) at com.evermind[Oracle Containers for J2EE 10g (10.1.3.1.0) ].util.ReleasableResourcePooledExecutor$MyWorker.run( ReleasableResourcePooledExecutor.java:303) at java.lang.Thread.run(Thread.java:595) 500 Internal Server Error javax.faces.FacesException: javax.servlet.ServletException at org.apache.myfaces.context.servlet.ServletExternalContextImpl.dispatch( ServletExternalContextImpl.java:426) at
RE : Re: Re : RE : Re: Oracle ADF and Shale tiles/validator
I agree, please add it to the wiki when you have time. Done ! I've put a link on the main wiki's page for Shale And Other JSF libraries ((Shale ADF). I really don't know if it's good or if the shale team wants to move it elsewhere, so if it's a you think it's crapy, just delete it ! Thank you very much for your appreciated help Gary ! However, Tiles/JSF 1.2 and JSP might workout since the verbatim issue is fixed but I have not heard from anyone who's tried it either. I know, but my IDE don't support facelets and one of the main points (for me) of JSF is IDE RAD support. Just one final point (which doesn't help anybody), I believe one of the main problems of JSF (other than the well known ones) is library incompatibility (i.e. Icefaces components can't be used on the same page with other third party components, ADF problem with Shale or Tiles, and surely others I don't know since I'm a newbie). It's really a pity (since some JSF libraries are really incredible), and I don't know if this problem will be resolved in the future. --- Gary VanMatre [EMAIL PROTECTED] a écrit : From: Adrian Gonzalez [EMAIL PROTECTED] Thank you very much Gary for this information, I'll try ADF validators instead of Shale's. Do you have similar info about Shale tiles and ADF ? Do you know if ADF (or Trinidad) has a feature similar as Tiles composition ? I've not tried Shale Tiles with ADF but I suspect the two won't play nicely together. Many will also tell you not to use JSP with JSF 1.1 due to the verbatim issue. However, Tiles/JSF 1.2 and JSP might workout since the verbatim issue is fixed but I have not heard from anyone who's tried it either. Perhaps the information about incompatibility between shale tiles/validator and ADF (and perhaps Trinidad) should be usefull for other newbies (in a wiki ?). I agree, please add it to the wiki when you have time. Gary - Message d'origine De : Gary VanMatre À : user@shale.apache.org Envoyé le : Mercredi, 31 Janvier 2007, 17h47mn 08s Objet : Re: RE : Re: Oracle ADF and Shale tiles/validator From: Adrian Gonzalez I've found the problem (using both Oracle ADF and some shale extensions doesn't work). It's in shale-validator and in shale-tiles (1.0.4 version). For info, I'm using adf-faces 10_1_3_0_4. To reproduce the problem with shale-validator, one just needs to put the shale-validator.jar in WEB-INF/lib. We don't need to use a validator explicitly in jsf page. To reproduce the problem with shale-tiles, one needs to put the shale-tiles.jar in WEB-INF/lib AND to call jsf page through a tile definition. I've done some debugging with shale-validator. The problem with this validator is that it changes the current renderKit (see org.apache.shale.validator.faces.setupRenderKit). I've just commented the setupRenderKit method implementation and the JSF page displays fine. Can we change something in order to use ADF with those Shale extensions ? I don't know if the two will work together. The ADF component library takes advantage of about every JSF extension point. I'm making this statement based on reviewing Trinidad's code. Both ADF and Shale Validator use a custom RenderKit. In Shale Validator's case, it decorates the original so that it can decorate renderers. This is needed because Shale is not a widget library and we are not interested in build a suite of components from the ground up as you will see with ADF. This trick allows us to modify a renderers behavior without rewritting every renderer that is a Input or Command component. If the registration of shale validator's faces-config is prior to ADF, there might be a chance to make it work however I'm doubtful. Assuming that ADF has the same validator support as Trinidad, you might rather look at their's which is couple with their components and provides client side validation. tr:validateRegExp - Validate expression using java regular expression syntax. tr:validateLongRange - Validate that the date entered is within a given range. tr:validateLength - Validate that the date entered is within a given range. tr:validateDoubleRange - Validate that the date entered is within a given range. tr:validateDateTimeRange - Validate that the date entered is within a given range. tr:validateDateRestriction - Validate that the date entered is within a given restriction. tr:validateByteLength - Validate the byte length of strings when encoded. Thanks Gary ___ Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! Profitez des connaissances, des opinions et des
Re: Need help with SCXML transition cond syntax.
On 1/31/07, Paul Spencer [EMAIL PROTECTED] wrote: Rahul, Works as expected. You may mark the issue as resolved. snip/ Done, and thanks for the quick feedback. -Rahul Thanks again. Paul Spencer
Re: RE : Re: Re : RE : Re: Oracle ADF and Shale tiles/validator
Hey Adrian, can you send me offline a simple sample WAR file, that uses ADF Faces and Shale Validator? Not the Shale-Tiles thing. Only those two ? I'd like to look at it. Thanks, Matthias On 2/1/07, Adrian Gonzalez [EMAIL PROTECTED] wrote: I agree, please add it to the wiki when you have time. Done ! I've put a link on the main wiki's page for Shale And Other JSF libraries ((Shale ADF). I really don't know if it's good or if the shale team wants to move it elsewhere, so if it's a you think it's crapy, just delete it ! Thank you very much for your appreciated help Gary ! However, Tiles/JSF 1.2 and JSP might workout since the verbatim issue is fixed but I have not heard from anyone who's tried it either. I know, but my IDE don't support facelets and one of the main points (for me) of JSF is IDE RAD support. Just one final point (which doesn't help anybody), I believe one of the main problems of JSF (other than the well known ones) is library incompatibility (i.e. Icefaces components can't be used on the same page with other third party components, ADF problem with Shale or Tiles, and surely others I don't know since I'm a newbie). It's really a pity (since some JSF libraries are really incredible), and I don't know if this problem will be resolved in the future. --- Gary VanMatre [EMAIL PROTECTED] a écrit : From: Adrian Gonzalez [EMAIL PROTECTED] Thank you very much Gary for this information, I'll try ADF validators instead of Shale's. Do you have similar info about Shale tiles and ADF ? Do you know if ADF (or Trinidad) has a feature similar as Tiles composition ? I've not tried Shale Tiles with ADF but I suspect the two won't play nicely together. Many will also tell you not to use JSP with JSF 1.1 due to the verbatim issue. However, Tiles/JSF 1.2 and JSP might workout since the verbatim issue is fixed but I have not heard from anyone who's tried it either. Perhaps the information about incompatibility between shale tiles/validator and ADF (and perhaps Trinidad) should be usefull for other newbies (in a wiki ?). I agree, please add it to the wiki when you have time. Gary - Message d'origine De : Gary VanMatre À : user@shale.apache.org Envoyé le : Mercredi, 31 Janvier 2007, 17h47mn 08s Objet : Re: RE : Re: Oracle ADF and Shale tiles/validator From: Adrian Gonzalez I've found the problem (using both Oracle ADF and some shale extensions doesn't work). It's in shale-validator and in shale-tiles (1.0.4 version). For info, I'm using adf-faces 10_1_3_0_4. To reproduce the problem with shale-validator, one just needs to put the shale-validator.jar in WEB-INF/lib. We don't need to use a validator explicitly in jsf page. To reproduce the problem with shale-tiles, one needs to put the shale-tiles.jar in WEB-INF/lib AND to call jsf page through a tile definition. I've done some debugging with shale-validator. The problem with this validator is that it changes the current renderKit (see org.apache.shale.validator.faces.setupRenderKit). I've just commented the setupRenderKit method implementation and the JSF page displays fine. Can we change something in order to use ADF with those Shale extensions ? I don't know if the two will work together. The ADF component library takes advantage of about every JSF extension point. I'm making this statement based on reviewing Trinidad's code. Both ADF and Shale Validator use a custom RenderKit. In Shale Validator's case, it decorates the original so that it can decorate renderers. This is needed because Shale is not a widget library and we are not interested in build a suite of components from the ground up as you will see with ADF. This trick allows us to modify a renderers behavior without rewritting every renderer that is a Input or Command component. If the registration of shale validator's faces-config is prior to ADF, there might be a chance to make it work however I'm doubtful. Assuming that ADF has the same validator support as Trinidad, you might rather look at their's which is couple with their components and provides client side validation. tr:validateRegExp - Validate expression using java regular expression syntax. tr:validateLongRange - Validate that the date entered is within a given range. tr:validateLength - Validate that the date entered is within a given range. tr:validateDoubleRange - Validate that the date entered is within a given range. tr:validateDateTimeRange - Validate that the date entered is within a given range. tr:validateDateRestriction - Validate that the date entered is within a given restriction. tr:validateByteLength - Validate the byte length of strings when encoded. Thanks Gary
Re: Shale + Ajax4jsf
Hi, I'm currently using JSF 1.2, Facelets, Tomahawk Sandbox and Shale. Now I want to integrate Ajax4Jsf and I have some trouble too. Tomorrow I will trying to extract Shale and fit in Ajax4jsf to solve the errors. I got some conflicts with duplicated component - ID's after an post-request. The inital request render successfully. A complete report is here: http://forum.exadel.com/viewtopic.php?t=5982 kind regards DaWorm
RE : Re: Oracle ADF and Shale tiles/validator
Thank you Matthias. I removed this filter, but no way. The problem is resolved when I remove all shale and ajax4jsf librairies from /WEB-INF/lib. I've put a custom Listener for logging purpose and the difference I see is : - it works fine if viewroot is javax.faces.component.UIViewRoot. - it doesn't work if viewroot is different (i.e. : org.apache.shale.view.faces.ShaleViewRoot). I'll continue to debug my app, but if anyone has resolved this kind of problem I'll be most gratefull for the tips, I'm really having a hard time with this JSF stuff. --- Matthias Wessendorf [EMAIL PROTECTED] a écrit : I saw you are using the Spring CharacterEncodingFilter. In Trinidad we saw issues when that one is in front of the Trinidad (Adf Faces) Filter I think your issue is related to the ordering of the filters. -Matthias ___ Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses http://fr.answers.yahoo.com
RE : Re: Oracle ADF and Shale tiles/validator
I've just changed the JSP test page to include some ADF components, and it changed the stackTrace to : java.lang.IllegalStateException: No AdfRenderingContext --- Here's the jsp page : !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd; %@ taglib uri=http://java.sun.com/jsf/core; prefix=f% [EMAIL PROTECTED] uri=http://java.sun.com/jsf/html; prefix=h% [EMAIL PROTECTED] uri=http://xmlns.oracle.com/adf/faces/html; prefix=afh% [EMAIL PROTECTED] uri=http://xmlns.oracle.com/adf/faces; prefix=af% f:view af:document title=Oracle ADF Faces Demo Index html xmlns=http://www.w3.org/1999/xhtml; body pPlacez le contenu ici./p h:form styleClass=form id=form1 h:inputText styleClass=inputText id=text1 value=message sample/h:inputText /h:form /body /html /af:document /f:view --- Here's the stackTrace : Begin backtrace for Nested Throwables java.lang.IllegalStateException: No AdfRenderingContext at oracle.adfinternal.view.faces.renderkit.core.CoreRenderer.encodeEnd(CoreRenderer.java:154) at oracle.adf.view.faces.component.UIXComponentBase.encodeEnd(UIXComponentBase.java:624) at javax.faces.webapp.UIComponentTag.encodeEnd(UIComponentTag.java:495) at javax.faces.webapp.UIComponentTag.doEndTag(UIComponentTag.java:363) at oracle.adf.view.faces.webapp.UIXComponentTag.doEndTag(UIXComponentTag.java:100) at com.ibm._jsp._simple._jspx_meth_af_document_0(_simple.java:151) at com.ibm._jsp._simple._jspx_meth_f_view_0(_simple.java:176) at com.ibm._jsp._simple._jspService(_simple.java:76) at com.ibm.ws.jsp.runtime.HttpJspBase.service(HttpJspBase.java:88) at javax.servlet.http.HttpServlet.service(HttpServlet.java:856) at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1282) at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1239) at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:113) at com.ibm.ws.webcontainer.filter.WebAppFilterChain._doFilter(WebAppFilterChain.java:82) at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:670) at com.ibm.wsspi.webcontainer.servlet.GenericServletWrapper.handleRequest(GenericServletWrapper.java:117) at com.ibm.ws.jsp.webcontainerext.JSPExtensionServletWrapper.handleRequest(JSPExtensionServletWrapper.java:178) at com.ibm.ws.jsp.webcontainerext.JSPExtensionProcessor.handleRequest(JSPExtensionProcessor.java:241) at com.ibm.ws.webcontainer.webapp.WebAppRequestDispatcher.forward(WebAppRequestDispatcher.java:265) at org.apache.myfaces.context.servlet.ServletExternalContextImpl.dispatch(ServletExternalContextImpl.java:416) at org.apache.myfaces.application.jsp.JspViewHandlerImpl.renderView(JspViewHandlerImpl.java:234) at oracle.adfinternal.view.faces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:157) at org.ajax4jsf.framework.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:101) at org.apache.shale.tiles.TilesViewHandler.renderView(TilesViewHandler.java:176) at org.apache.shale.validator.faces.ValidatorViewHandler.renderView(ValidatorViewHandler.java:130) at org.apache.shale.view.faces.ViewViewHandler.renderView(ViewViewHandler.java:147) at org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:384) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:138) at org.apache.myfaces.webapp.MyFacesServlet.service(MyFacesServlet.java:74) at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1282) at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1239) at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:136) at org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(ExtensionsFilter.java:144) at com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.doFilter(FilterInstanceWrapper.java:142) at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:121) at oracle.adfinternal.view.faces.webapp.AdfFacesFilterImpl._invokeDoFilter(AdfFacesFilterImpl.java:367) at oracle.adfinternal.view.faces.webapp.AdfFacesFilterImpl._doFilterImpl(AdfFacesFilterImpl.java:336) at oracle.adfinternal.view.faces.webapp.AdfFacesFilterImpl.doFilter(AdfFacesFilterImpl.java:196) at oracle.adf.view.faces.webapp.AdfFacesFilter.doFilter(AdfFacesFilter.java:87) at com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.doFilter(FilterInstanceWrapper.java:142) at
RE : Re: Oracle ADF and Shale tiles/validator
I've found the problem (using both Oracle ADF and some shale extensions doesn't work). It's in shale-validator and in shale-tiles (1.0.4 version). For info, I'm using adf-faces 10_1_3_0_4. To reproduce the problem with shale-validator, one just needs to put the shale-validator.jar in WEB-INF/lib. We don't need to use a validator explicitly in jsf page. To reproduce the problem with shale-tiles, one needs to put the shale-tiles.jar in WEB-INF/lib AND to call jsf page through a tile definition. I've done some debugging with shale-validator. The problem with this validator is that it changes the current renderKit (see org.apache.shale.validator.faces.setupRenderKit). I've just commented the setupRenderKit method implementation and the JSF page displays fine. Can we change something in order to use ADF with those Shale extensions ? Thanks ___ Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses http://fr.answers.yahoo.com
Re: Need help with SCXML transition cond syntax.
Rahul,
What am I doing wrong?
When the next button is clicked my goal is to go from page1 to page2 if the
property Leased is checked on the page1, otherwise go to page2. Neither is
happening!
When the cancel button is clicked, the transition to menu works as expected.
***
* Value of dialog.data fields
***
licenseTag = 'test'
leased = Boolean.TRUE
***
* Dialog configuration for the stat Page 1
***
state id=page1
onentry
shale:view viewId=vehicle/addPage1 /
/onentry
transition cond=${dialogData.licenseTag eq 'test'}
target=page2 /
transition cond=${dialog.data.licenseTag eq 'test'}
target=page2 /
transition cond=${dialog.data.lease}
target=page2 /
transition event=faces.outcome cond=${outcome eq 'next'}
if cond=${dialog.data.leased eq 'true'}
target next=page2 /
else
target next=review /
/else
/if
/transition
transition target=menu event=faces.outcome
cond=${outcome eq 'cancel'} /
/state
***
* Logging
***
outcome = next
_eventdata = null
_eventdatamap = {faces.outcome=null}
_ALL_NAMESPACES = {shale=http://shale.apache.org/dialog-scxml,
=http://www.w3.org/2005/07/scxml}
${outcome eq 'next'} = true
_ALL_NAMESPACES = null
_ALL_NAMESPACES = {shale=http://shale.apache.org/dialog-scxml,
=http://www.w3.org/2005/07/scxml}
${outcome eq 'cancel'} = false
_ALL_NAMESPACES = null
_ALL_NAMESPACES = {shale=http://shale.apache.org/dialog-scxml,
=http://www.w3.org/2005/07/scxml}
${dialogData.licenseTag eq 'test'} = false
_ALL_NAMESPACES = null
_ALL_NAMESPACES = {shale=http://shale.apache.org/dialog-scxml,
=http://www.w3.org/2005/07/scxml}
${dialog.data.licenseTag eq 'test'} = false
_ALL_NAMESPACES = null
_ALL_NAMESPACES = {shale=http://shale.apache.org/dialog-scxml,
=http://www.w3.org/2005/07/scxml}
${dialog.data.lease} = false
_ALL_NAMESPACES = null
_ALL_NAMESPACES = {shale=http://shale.apache.org/dialog-scxml,
=http://www.w3.org/2005/07/scxml}
${dialog.data.leased eq 'true'} = false
_ALL_NAMESPACES = null
_eventdata = null
_eventdatamap = null
Current States: [page1]
Paul Spencer
Rahul Akolkar wrote:
On 1/30/07, Paul Spencer [EMAIL PROTECTED] wrote:
Version 1.1.0-SNAPSHOT
I would like a transition to be selected when a bean's field is not
empty. If the field is
an empty string, , or null I do not want the transition executed.
Below is
the syntax in JSF EL.
#{not empty dialogData.companyId}
What is the equivalent in SCXML?
transition ... cond= ? /
snip/
${not empty dialogData.companyId}
The SCXML implementation often doesn't have the liberty of knowing
anything about the expression based on the location of the expression
within the document (though cond attribute values are expected to
evaluate to booleans, in this particular case).
The evaluator Javadoc is here [1], and lists some relevant details.
-Rahul
[1]
http://shale.apache.org/shale-dialog-scxml/apidocs/org/apache/shale/dialog/scxml/ShaleDialogELEvaluator.html
Paul Spencer
Re: Need help with SCXML transition cond syntax.
On 1/31/07, Paul Spencer [EMAIL PROTECTED] wrote:
Rahul,
What am I doing wrong?
When the next button is clicked my goal is to go from page1 to page2 if the
property Leased is checked on the page1, otherwise go to page2. Neither is
happening!
When the cancel button is clicked, the transition to menu works as expected.
***
* Value of dialog.data fields
***
licenseTag = 'test'
leased = Boolean.TRUE
***
* Dialog configuration for the stat Page 1
***
state id=page1
onentry
shale:view viewId=vehicle/addPage1 /
/onentry
transition cond=${dialogData.licenseTag eq 'test'}
target=page2 /
transition cond=${dialog.data.licenseTag eq 'test'}
target=page2 /
transition cond=${dialog.data.lease}
target=page2 /
transition event=faces.outcome cond=${outcome eq 'next'}
if cond=${dialog.data.leased eq 'true'}
target next=page2 /
else
target next=review /
/else
/if
/transition
snip/
The target of a transition element cannot be determined at runtime
(if we think of this in terms of a state chart diagrams, when we start
to draw a transition we need to also know the end point/state, can't
have it TBD amongst some candidates) -- a slight exception is
history (but thats OT, see SCXML WD or Commons SCXML test suite /
site for semantics).
But another way to look at this is that we simply have compound
conditional expressions, i.e. the one transition above whose target
we're trying to determine using conditionals (if) is conceptually
equivalent to the two transitions below (untested):
transition event=faces.outcome
cond=${outcome eq 'next' and dialog.data.leased}
target=page2/
transition event=faces.outcome
cond=${outcome eq 'next' and not dialog.data.leased}
target=review/
Ofcourse, if the condition expressions start becoming too involved
they can be moved to MBEs or custom EL functions.
Other observations probably relevant here:
* Generally, all outbound transitions from a view state should be
guarded by the faces.outcome event (or they may be followed
immediately if the cond is satisfied)
* The latest SCXML WD [1] (Jan '06) has removed the target element
(though the 0.x line of Commons SCXML supports it for backwards
compatibility). It is recommended to use the target attribute of
transition instead (and once thats done, it becomes hard to provide
more than one based on some conditional logic anyway). The SCXML
examples in the Shale test app use the newer variants of any such spec
changes.
* Upto v0.6 of Commons SCXML, the conds are expected to be mutually
exclusive (no two -- or more -- should evaluate to true at the same
time in a given scenario). That will lead to non-determinism, and the
related error being reported. I think the spec may talk about document
order priorities in the next rev.
-Rahul
[1] http://www.w3.org/TR/scxml/
transition target=menu event=faces.outcome
cond=${outcome eq 'cancel'} /
/state
***
* Logging
***
outcome = next
_eventdata = null
_eventdatamap = {faces.outcome=null}
_ALL_NAMESPACES = {shale=http://shale.apache.org/dialog-scxml,
=http://www.w3.org/2005/07/scxml}
${outcome eq 'next'} = true
_ALL_NAMESPACES = null
_ALL_NAMESPACES = {shale=http://shale.apache.org/dialog-scxml,
=http://www.w3.org/2005/07/scxml}
${outcome eq 'cancel'} = false
_ALL_NAMESPACES = null
_ALL_NAMESPACES = {shale=http://shale.apache.org/dialog-scxml,
=http://www.w3.org/2005/07/scxml}
${dialogData.licenseTag eq 'test'} = false
_ALL_NAMESPACES = null
_ALL_NAMESPACES = {shale=http://shale.apache.org/dialog-scxml,
=http://www.w3.org/2005/07/scxml}
${dialog.data.licenseTag eq 'test'} = false
_ALL_NAMESPACES = null
_ALL_NAMESPACES = {shale=http://shale.apache.org/dialog-scxml,
=http://www.w3.org/2005/07/scxml}
${dialog.data.lease} = false
_ALL_NAMESPACES = null
_ALL_NAMESPACES = {shale=http://shale.apache.org/dialog-scxml,
=http://www.w3.org/2005/07/scxml}
${dialog.data.leased eq 'true'} = false
_ALL_NAMESPACES = null
_eventdata = null
_eventdatamap = null
Current States: [page1]
Paul Spencer
snap/
Re: Need help with SCXML transition cond syntax.
Rahul,
See below.
Rahul Akolkar wrote:
On 1/31/07, Paul Spencer [EMAIL PROTECTED] wrote:
Rahul,
What am I doing wrong?
When the next button is clicked my goal is to go from page1 to page2
if the
property Leased is checked on the page1, otherwise go to page2.
Neither is happening!
When the cancel button is clicked, the transition to menu works as
expected.
***
* Value of dialog.data fields
***
licenseTag = 'test'
leased = Boolean.TRUE
***
* Dialog configuration for the stat Page 1
***
state id=page1
onentry
shale:view viewId=vehicle/addPage1 /
/onentry
transition cond=${dialogData.licenseTag eq 'test'}
target=page2 /
transition cond=${dialog.data.licenseTag eq 'test'}
target=page2 /
transition cond=${dialog.data.lease}
target=page2 /
transition event=faces.outcome cond=${outcome eq 'next'}
if cond=${dialog.data.leased eq 'true'}
target next=page2 /
else
target next=review /
/else
/if
/transition
snip/
The target of a transition element cannot be determined at runtime
(if we think of this in terms of a state chart diagrams, when we start
to draw a transition we need to also know the end point/state, can't
have it TBD amongst some candidates) -- a slight exception is
history (but thats OT, see SCXML WD or Commons SCXML test suite /
site for semantics).
But another way to look at this is that we simply have compound
conditional expressions, i.e. the one transition above whose target
we're trying to determine using conditionals (if) is conceptually
equivalent to the two transitions below (untested):
transition event=faces.outcome
cond=${outcome eq 'next' and dialog.data.leased}
target=page2/
transition event=faces.outcome
cond=${outcome eq 'next' and not dialog.data.leased}
target=review/
My previous configuration was simply a summary of my attempts. Although I my
first attempt matches your suggestion, I did not included it in the example.
Below is the configuration you suggested. I suspect that SCXML is not getting
the properties from dialog.data because the value of dialog.data.leased is
always
false.
***
* Value of dialog.data fields
***
leased = Boolean.TRUE
***
* Dialog configuration for the stat Page 1
***
state id=page1
onentry
shale:view viewId=vehicle/addPage1 /
/onentry
transition event=faces.outcome
cond=${outcome eq 'next' and dialog.data.leased} target=page2 /
transition event=faces.outcome
cond=${outcome eq 'next' and not dialog.data.leased} target=review /
transition target=menu event=faces.outcome
cond=${outcome eq 'cancel'} /
/state
***
* Logging
***
outcome = next
_eventdata = null
_eventdatamap = {faces.outcome=null}
_ALL_NAMESPACES = {shale=http://shale.apache.org/dialog-scxml,
=http://www.w3.org/2005/07/scxml}
${outcome eq 'next' and dialog.data.leased} = false
_ALL_NAMESPACES = null
_ALL_NAMESPACES = {shale=http://shale.apache.org/dialog-scxml,
=http://www.w3.org/2005/07/scxml}
${outcome eq 'next' and not dialog.data.leased} = true
_ALL_NAMESPACES = null
_ALL_NAMESPACES = {shale=http://shale.apache.org/dialog-scxml,
=http://www.w3.org/2005/07/scxml}
${outcome eq 'cancel'} = false
_ALL_NAMESPACES = null
_eventdata = null
_eventdatamap = null
Current States: [review]
Ofcourse, if the condition expressions start becoming too involved
they can be moved to MBEs or custom EL functions.
Can you point me to an example of this?
Other observations probably relevant here:
* Generally, all outbound transitions from a view state should be
guarded by the faces.outcome event (or they may be followed
immediately if the cond is satisfied)
This is good to know.
* The latest SCXML WD [1] (Jan '06) has removed the target element
(though the 0.x line of Commons SCXML supports it for backwards
compatibility). It is recommended to use the target attribute of
transition instead (and once thats done, it becomes hard to provide
more than one based on some conditional logic anyway). The SCXML
examples in the Shale test app use the newer variants of any such spec
changes.
I only used target in an attempt to get the transition working. I was
using an example from Commons SCXML's wiki.
* Upto v0.6 of Commons SCXML, the conds are expected to be mutually
exclusive (no two -- or more -- should evaluate to true at the same
time in a given scenario). That will lead to non-determinism, and the
related error being reported. I think the spec may talk about document
order priorities in the next rev.
This matches my expectations. I only had two potentially evaluating to
true for debugging and testing. Once in production only 1 transition will
evaluate to true.
-Rahul
snip
Paul Spencer
Re: RE : Re: Oracle ADF and Shale tiles/validator
From: Adrian Gonzalez [EMAIL PROTECTED] I've found the problem (using both Oracle ADF and some shale extensions doesn't work). It's in shale-validator and in shale-tiles (1.0.4 version). For info, I'm using adf-faces 10_1_3_0_4. To reproduce the problem with shale-validator, one just needs to put the shale-validator.jar in WEB-INF/lib. We don't need to use a validator explicitly in jsf page. To reproduce the problem with shale-tiles, one needs to put the shale-tiles.jar in WEB-INF/lib AND to call jsf page through a tile definition. I've done some debugging with shale-validator. The problem with this validator is that it changes the current renderKit (see org.apache.shale.validator.faces.setupRenderKit). I've just commented the setupRenderKit method implementation and the JSF page displays fine. Can we change something in order to use ADF with those Shale extensions ? I don't know if the two will work together. The ADF component library takes advantage of about every JSF extension point. I'm making this statement based on reviewing Trinidad's code. Both ADF and Shale Validator use a custom RenderKit. In Shale Validator's case, it decorates the original so that it can decorate renderers. This is needed because Shale is not a widget library and we are not interested in build a suite of components from the ground up as you will see with ADF. This trick allows us to modify a renderers behavior without rewritting every renderer that is a Input or Command component. If the registration of shale validator's faces-config is prior to ADF, there might be a chance to make it work however I'm doubtful. Assuming that ADF has the same validator support as Trinidad, you might rather look at their's which is couple with their components and provides client side validation. tr:validateRegExp - Validate expression using java regular expression syntax. tr:validateLongRange - Validate that the date entered is within a given range. tr:validateLength - Validate that the date entered is within a given range. tr:validateDoubleRange - Validate that the date entered is within a given range. tr:validateDateTimeRange - Validate that the date entered is within a given range. tr:validateDateRestriction - Validate that the date entered is within a given restriction. tr:validateByteLength - Validate the byte length of strings when encoded. Thanks Gary ___ Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses http://fr.answers.yahoo.com
Re: Need help with SCXML transition cond syntax.
On 1/31/07, Paul Spencer [EMAIL PROTECTED] wrote:
Rahul,
See below.
Rahul Akolkar wrote:
On 1/31/07, Paul Spencer [EMAIL PROTECTED] wrote:
snip/
My previous configuration was simply a summary of my attempts. Although I my
first attempt matches your suggestion, I did not included it in the example.
Below is the configuration you suggested. I suspect that SCXML is not getting
the properties from dialog.data because the value of dialog.data.leased is
always
false.
snap/
Bah, OK, it seems I missed one todo in code, about three lines needed
to tie the application variable resolver to the Commons SCXML context
for greater EL capabilities (such as this, arbitrary expressions
beyond simply calling action state MBEs etc). Could you file a JIRA
issue for this? Thanks! In any case, I intend to get to this later
this afternoon, so there will be one soon enough.
Ofcourse, if the condition expressions start becoming too involved
they can be moved to MBEs or custom EL functions.
Can you point me to an example of this?
snip/
What I meant was if we ever get into ${A and B and C or D ...} style
expressions, perhaps the procedural bits can be captured in a managed
bean method for brevity of the dialog descriptor.
I only used target in an attempt to get the transition working. I was
using an example from Commons SCXML's wiki.
snap/
You're welcome to whack any bits on the wiki that are outdated /
incorrect, if you feel like it.
This matches my expectations. I only had two potentially evaluating to
true for debugging and testing. Once in production only 1 transition will
evaluate to true.
snip/
Sounds good.
-Rahul
Re : RE : Re: Oracle ADF and Shale tiles/validator
Thank you very much Gary for this information, I'll try ADF validators instead of Shale's. Do you have similar info about Shale tiles and ADF ? Do you know if ADF (or Trinidad) has a feature similar as Tiles composition ? Perhaps the information about incompatibility between shale tiles/validator and ADF (and perhaps Trinidad) should be usefull for other newbies (in a wiki ?). - Message d'origine De : Gary VanMatre [EMAIL PROTECTED] À : user@shale.apache.org Envoyé le : Mercredi, 31 Janvier 2007, 17h47mn 08s Objet : Re: RE : Re: Oracle ADF and Shale tiles/validator From: Adrian Gonzalez [EMAIL PROTECTED] I've found the problem (using both Oracle ADF and some shale extensions doesn't work). It's in shale-validator and in shale-tiles (1.0.4 version). For info, I'm using adf-faces 10_1_3_0_4. To reproduce the problem with shale-validator, one just needs to put the shale-validator.jar in WEB-INF/lib. We don't need to use a validator explicitly in jsf page. To reproduce the problem with shale-tiles, one needs to put the shale-tiles.jar in WEB-INF/lib AND to call jsf page through a tile definition. I've done some debugging with shale-validator. The problem with this validator is that it changes the current renderKit (see org.apache.shale.validator.faces.setupRenderKit). I've just commented the setupRenderKit method implementation and the JSF page displays fine. Can we change something in order to use ADF with those Shale extensions ? I don't know if the two will work together. The ADF component library takes advantage of about every JSF extension point. I'm making this statement based on reviewing Trinidad's code. Both ADF and Shale Validator use a custom RenderKit. In Shale Validator's case, it decorates the original so that it can decorate renderers. This is needed because Shale is not a widget library and we are not interested in build a suite of components from the ground up as you will see with ADF. This trick allows us to modify a renderers behavior without rewritting every renderer that is a Input or Command component. If the registration of shale validator's faces-config is prior to ADF, there might be a chance to make it work however I'm doubtful. Assuming that ADF has the same validator support as Trinidad, you might rather look at their's which is couple with their components and provides client side validation. tr:validateRegExp - Validate expression using java regular expression syntax. tr:validateLongRange - Validate that the date entered is within a given range. tr:validateLength - Validate that the date entered is within a given range. tr:validateDoubleRange - Validate that the date entered is within a given range. tr:validateDateTimeRange - Validate that the date entered is within a given range. tr:validateDateRestriction - Validate that the date entered is within a given restriction. tr:validateByteLength - Validate the byte length of strings when encoded. Thanks Gary ___ Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses http://fr.answers.yahoo.com ___ Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses http://fr.answers.yahoo.com
Re: Re : RE : Re: Oracle ADF and Shale tiles/validator
From: Adrian Gonzalez [EMAIL PROTECTED] Thank you very much Gary for this information, I'll try ADF validators instead of Shale's. Do you have similar info about Shale tiles and ADF ? Do you know if ADF (or Trinidad) has a feature similar as Tiles composition ? I've not tried Shale Tiles with ADF but I suspect the two won't play nicely together. Many will also tell you not to use JSP with JSF 1.1 due to the verbatim issue. However, Tiles/JSF 1.2 and JSP might workout since the verbatim issue is fixed but I have not heard from anyone who's tried it either. Perhaps the information about incompatibility between shale tiles/validator and ADF (and perhaps Trinidad) should be usefull for other newbies (in a wiki ?). I agree, please add it to the wiki when you have time. Gary - Message d'origine De : Gary VanMatre À : user@shale.apache.org Envoyé le : Mercredi, 31 Janvier 2007, 17h47mn 08s Objet : Re: RE : Re: Oracle ADF and Shale tiles/validator From: Adrian Gonzalez I've found the problem (using both Oracle ADF and some shale extensions doesn't work). It's in shale-validator and in shale-tiles (1.0.4 version). For info, I'm using adf-faces 10_1_3_0_4. To reproduce the problem with shale-validator, one just needs to put the shale-validator.jar in WEB-INF/lib. We don't need to use a validator explicitly in jsf page. To reproduce the problem with shale-tiles, one needs to put the shale-tiles.jar in WEB-INF/lib AND to call jsf page through a tile definition. I've done some debugging with shale-validator. The problem with this validator is that it changes the current renderKit (see org.apache.shale.validator.faces.setupRenderKit). I've just commented the setupRenderKit method implementation and the JSF page displays fine. Can we change something in order to use ADF with those Shale extensions ? I don't know if the two will work together. The ADF component library takes advantage of about every JSF extension point. I'm making this statement based on reviewing Trinidad's code. Both ADF and Shale Validator use a custom RenderKit. In Shale Validator's case, it decorates the original so that it can decorate renderers. This is needed because Shale is not a widget library and we are not interested in build a suite of components from the ground up as you will see with ADF. This trick allows us to modify a renderers behavior without rewritting every renderer that is a Input or Command component. If the registration of shale validator's faces-config is prior to ADF, there might be a chance to make it work however I'm doubtful. Assuming that ADF has the same validator support as Trinidad, you might rather look at their's which is couple with their components and provides client side validation. tr:validateRegExp - Validate expression using java regular expression syntax. tr:validateLongRange - Validate that the date entered is within a given range. tr:validateLength - Validate that the date entered is within a given range. tr:validateDoubleRange - Validate that the date entered is within a given range. tr:validateDateTimeRange - Validate that the date entered is within a given range. tr:validateDateRestriction - Validate that the date entered is within a given restriction. tr:validateByteLength - Validate the byte length of strings when encoded. Thanks Gary ___ Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses http://fr.answers.yahoo.com ___ Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses http://fr.answers.yahoo.com
Re: Need help with SCXML transition cond syntax.
Rahul, Rahul Akolkar wrote: snip Bah, OK, it seems I missed one todo in code, about three lines needed to tie the application variable resolver to the Commons SCXML context for greater EL capabilities (such as this, arbitrary expressions beyond simply calling action state MBEs etc). Could you file a JIRA issue for this? Thanks! In any case, I intend to get to this later this afternoon, so there will be one soon enough. https://issues.apache.org/struts/browse/SHALE-404 snip -Rahul Thank you for you help on this. Paul Spencer
Re: Need help with SCXML transition cond syntax.
Rahul,
Works as expected. You may mark the issue as resolved.
Thanks again.
Paul Spencer
Rahul Akolkar wrote:
On 1/30/07, Paul Spencer [EMAIL PROTECTED] wrote:
Version 1.1.0-SNAPSHOT
snip/
Could you try an updated snap, one thats post this issue:
http://issues.apache.org/struts/browse/SHALE-403
-Rahul
I would like a transition to be selected when a bean's field is not
empty. If the field is
an empty string, , or null I do not want the transition executed.
Below is
the syntax in JSF EL.
#{not empty dialogData.companyId}
What is the equivalent in SCXML?
transition ... cond= ? /
Paul Spencer
Re: t:saveState works great ... except when I use h:outputLink
On 1/30/07, Dick Starr [EMAIL PROTECTED] wrote:
I need to save separate state information for each open Firefox tab. Since
Firefox shares the same session between all tabs I need to dream up another
way besides using session. I am using Firefox 2.0.
I have been experimenting with t:saveState and find it works great when
I submit a form and go to another form via a rule, but I lose my state when
I execute an h:outputLink. I am using Shale 1.1.0 (yesterday's
snapshot) with the included Tiles. I have created a simple example,
described below.
The neat part of this method is that I have a single StateBean for all my
tab state data and a single reference to saveState in my Tiles header. I
can merrily go through my three test jsp forms for each tab with different
tab state forever without losing my tab state (as test3 branches back to
test1). But in my test2 I also have a h:outputLink that goes to test3,
and if I click this link I lose my state.
It would be great if this could work. Any help would be greatly
appreciated.
The h:outputLink component does an HTTP GET to the new URL, instead of the
usual POST, so *all* JSF state is lost when you do that. Have you tried it
with h:commandLink instead?
Craig
Here are my test details.
For my test I am using the logonName in my StateBean. I added this logic
to my logon Class:
stateBean = new StateBean();
stateBean.setLogonName(this.getLogonName());
setStateBean(stateBean);
String ab = #{requestScope.stateBean};
getApplication().createValueBinding(ab).setValue(facesContext, stateBean);
My Tiles header.jsp has the saveState:
...
t:saveState id=stateBeanSS value=#{stateBean}/
...
Here are the rules:
navigation-rule
from-view-id/systemLogon.jsp/from-view-id
navigation-case
from-outcomesuccess/from-outcome
to-view-id/testTest1.jsp/to-view-id
/navigation-case
/navigation-rule
navigation-rule
from-view-id/testTest1.jsp/from-view-id
navigation-case
from-outcomesuccess/from-outcome
to-view-id/testTest2.jsp/to-view-id
/navigation-case
/navigation-rule
navigation-rule
from-view-id/testTest2.jsp/from-view-id
navigation-case
from-outcomesuccess/from-outcome
to-view-id/testTest3.jsp/to-view-id
/navigation-case
/navigation-rule
navigation-rule
from-view-id/testTest3.jsp/from-view-id
navigation-case
from-outcomesuccess/from-outcome
to-view-id/testTest1.jsp/to-view-id
/navigation-case
/navigation-rule
And here are my jsps:
testTest1.jsp
...
h:form
h:outputText value=Test1 stateBean = #{stateBean}, #{
stateBean.logonName}/
h:commandButton action=#{testTestBean.submit} value=Submit/
/h:form
testTest2.jsp
...
h:form
h:outputText value=Test2 stateBean = #{stateBean}, #{
stateBean.logonName}/
h:commandButton action=#{testTestBean.submit} value=Submit/
/h:form
h:outputLink value=#{facesContext.externalContext.requestContextPath
}/testTest3.faces
h:outputText value=Test3/
/h:outputLink
testTest3.jsp
...
h:form
h:outputText value=Test3 stateBean = #{stateBean}, #{
stateBean.logonName}/
h:commandButton action=#{testTestBean.submit} value=Submit/
/h:form
Dick
Re: Need help with SCXML transition cond syntax.
On 1/30/07, Paul Spencer [EMAIL PROTECTED] wrote:
Version 1.1.0-SNAPSHOT
I would like a transition to be selected when a bean's field is not empty. If
the field is
an empty string, , or null I do not want the transition executed. Below is
the syntax in JSF EL.
#{not empty dialogData.companyId}
What is the equivalent in SCXML?
transition ... cond= ? /
snip/
${not empty dialogData.companyId}
The SCXML implementation often doesn't have the liberty of knowing
anything about the expression based on the location of the expression
within the document (though cond attribute values are expected to
evaluate to booleans, in this particular case).
The evaluator Javadoc is here [1], and lists some relevant details.
-Rahul
[1]
http://shale.apache.org/shale-dialog-scxml/apidocs/org/apache/shale/dialog/scxml/ShaleDialogELEvaluator.html
Paul Spencer
RE: saveState works great ... except when I use h:outputLink - solved
Thank you!
This h:commandLink works:
...
h:form
h:outputText value=Test2 stateBean = #{stateBean}, #{stateBean.logonName}/
h:commandButton action=#{testTestBean.submit} value=Submit/
h:commandLink action=#{testTestBean.submit} value=Test3/
/h:form
Dick
-Original Message-
From: Craig McClanahan [mailto:[EMAIL PROTECTED]
Sent: Tue 1/30/2007 12:58 PM
To: user@shale.apache.org
Cc:
Subject:Re: saveState works great ... except when I use h:outputLink
On 1/30/07, Dick Starr [EMAIL PROTECTED] wrote:
I need to save separate state information for each open Firefox tab. Since
Firefox shares the same session between all tabs I need to dream up another
way besides using session. I am using Firefox 2.0.
I have been experimenting with t:saveState and find it works great when
I submit a form and go to another form via a rule, but I lose my state when
I execute an h:outputLink. I am using Shale 1.1.0 (yesterday's
snapshot) with the included Tiles. I have created a simple example,
described below.
The neat part of this method is that I have a single StateBean for all my
tab state data and a single reference to saveState in my Tiles header. I
can merrily go through my three test jsp forms for each tab with different
tab state forever without losing my tab state (as test3 branches back to
test1). But in my test2 I also have a h:outputLink that goes to test3,
and if I click this link I lose my state.
It would be great if this could work. Any help would be greatly
appreciated.
The h:outputLink component does an HTTP GET to the new URL, instead of the
usual POST, so *all* JSF state is lost when you do that. Have you tried it
with h:commandLink instead?
Craig
Here are my test details.
For my test I am using the logonName in my StateBean. I added this logic
to my logon Class:
stateBean = new StateBean();
stateBean.setLogonName(this.getLogonName());
setStateBean(stateBean);
String ab = #{requestScope.stateBean};
getApplication().createValueBinding(ab).setValue(facesContext, stateBean);
My Tiles header.jsp has the saveState:
...
t:saveState id=stateBeanSS value=#{stateBean}/
...
Here are the rules:
navigation-rule
from-view-id/systemLogon.jsp/from-view-id
navigation-case
from-outcomesuccess/from-outcome
to-view-id/testTest1.jsp/to-view-id
/navigation-case
/navigation-rule
navigation-rule
from-view-id/testTest1.jsp/from-view-id
navigation-case
from-outcomesuccess/from-outcome
to-view-id/testTest2.jsp/to-view-id
/navigation-case
/navigation-rule
navigation-rule
from-view-id/testTest2.jsp/from-view-id
navigation-case
from-outcomesuccess/from-outcome
to-view-id/testTest3.jsp/to-view-id
/navigation-case
/navigation-rule
navigation-rule
from-view-id/testTest3.jsp/from-view-id
navigation-case
from-outcomesuccess/from-outcome
to-view-id/testTest1.jsp/to-view-id
/navigation-case
/navigation-rule
And here are my jsps:
testTest1.jsp
...
h:form
h:outputText value=Test1 stateBean = #{stateBean}, #{
stateBean.logonName}/
h:commandButton action=#{testTestBean.submit} value=Submit/
/h:form
testTest2.jsp
...
h:form
h:outputText value=Test2 stateBean = #{stateBean}, #{
stateBean.logonName}/
h:commandButton action=#{testTestBean.submit} value=Submit/
/h:form
h:outputLink value=#{facesContext.externalContext.requestContextPath
}/testTest3.faces
h:outputText value=Test3/
/h:outputLink
testTest3.jsp
...
h:form
h:outputText value=Test3 stateBean = #{stateBean}, #{
stateBean.logonName}/
h:commandButton action=#{testTestBean.submit} value=Submit/
/h:form
Dick
Re: My exception handling is broken
Hi. I encountered the same problem. I started development with shale-1.0.4-SNAPHSOT a while ago and wrote my own ExceptionHandler, too. That worked so far. 3 weeks ago I upgraded to 1.0.4 and for example acegi exceptions didn't get propagated anymore to its ExceptionFilter. At this time I thought, it worked before because of a bug in the SNAPSHOT release and that got fixed in the final 1.0.4. Something changed in the way of handling exceptions I guess. I can't remember exactly what I changed to get it running in 1.0.4 again, but it had something todo with trowing exceptions. In the past, I think the Shale Controller threw exceptions that were queued up in the session under FacesConstants.EXCEPTIONS_LIST. Now this isn't done anymore. I had to throw the exception explicitly in my shale exception handler to get it propagated. I would be also interested in what changed exactly and what's the right way to handle exceptions in shale... regards, Veit Ingo Düppe schrieb: Hi, I guess I missed some changes in shale 1.0.4. I override the DefaultExceptionHandling so that my backing bean can throw to types of exceptions one of my ApplicationExceptions and the unchecked SystemExceptions. These two types were handled by the DefaultExceptionHandler. For instance, the application exception just ends up in an error message on the same view. But now there is a responseComplete within the ShaleViewRoot (Is this class new?) that prevents the rendering after exception handling. So, do I need to introduce my own ViewRoot component or what is the recommended way to handle my exceptions? Regards Ingo
Re: Oracle ADF and Shale tiles/validator
I saw you are using the Spring CharacterEncodingFilter. In Trinidad we saw issues when that one is in front of the Trinidad (Adf Faces) Filter I think your issue is related to the ordering of the filters. -Matthias
Re: How to end a SCXML dialog in an action?
Rahul,
I was using 1.0.4. When I switch to 1.1.0-SNAPSHOT, it worked.
Paul Spencer
Rahul Akolkar wrote:
On 1/26/07, Paul Spencer [EMAIL PROTECTED] wrote:
Rahul,
I an getting the following when I click on the home link. It appears
that the dialog
is still running even though it was stopped.
snip/
Couldn't spot anything so dropped your code snippets into the
shale-test-dialog-scxml app. Works for me, recipe below:
1) Used SessionManagerBean and the h:form snippet, both verbatim
from below (snippet placed at the bottom of wizardpage1.jsp in the
test app above)
2) faces-config additions:
managed-bean
managed-bean-namesessionManager/managed-bean-name
managed-bean-classorg.apache.shale.examples.test.dialog.scxml.SessionManagerBean/managed-bean-class
managed-bean-scopesession/managed-bean-scope
/managed-bean
navigation-rule
from-view-id/*/from-view-id
navigation-case
from-action#{sessionManager.gotoHome}/from-action
from-outcomehome/from-outcome
to-view-id/menu.jsp/to-view-id
/navigation-case
/navigation-rule
Then clicking on Home takes me to the test app home page (menu.jsp)
after stopping the active dialog.
-Rahul
***
* Stack Trace
***
ServletRequestAttributeAdded(org.apache.myfaces.config.beansUnderConstruction,[])
stop(id=1, name=addVendor)
remove(Removed DialogContext instance with ID '1'
handleNavigation(context='[EMAIL PROTECTED]',
fromAction='#{sessionManager.gotoHome}', outcome='home')
Dialog instance '1' for dialog name 'addVendor' has not yet been started
java.lang.IllegalStateException: Dialog instance '1' for dialog name
'addVendor' has not yet been started
at
org.apache.shale.dialog.scxml.SCXMLDialogContext.advance(SCXMLDialogContext.java:316)
at
org.apache.shale.dialog.faces.DialogNavigationHandler.handleNavigation(DialogNavigationHandler.java:139)
at
org.apache.myfaces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:84)
at
org.apache.shale.view.faces.ViewActionListener.processAction(ViewActionListener.java:74)
at javax.faces.component.UICommand.broadcast(UICommand.java:106)
at
javax.faces.component.UIViewRoot._broadcastForPhase(UIViewRoot.java:94)
at
javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:168)
at
org.apache.shale.view.faces.ShaleViewRoot.processApplication(ShaleViewRoot.java:40)
at
org.apache.myfaces.lifecycle.LifecycleImpl.invokeApplication(LifecycleImpl.java:343)
at
org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:86)
***
* From the managed bean
***
public class SessionManagerBean
{
public String gotoHome()
{
stopActiveDialogIfAny(FacesContext.getCurrentInstance());
return home;
}
private void stopActiveDialogIfAny(FacesContext facesContext)
{
DialogContext dcontext = (DialogContext)
facesContext.getExternalContext().getRequestMap().get(Constants.CONTEXT_BEAN);
if (dcontext != null)
{
dcontext.stop(facesContext);
}
}
}
**
* Form the view
***
h:form id=logoutForm
h:commandLink action=#{sessionManager.gotoHome}
h:outputText value=Home /
/h:commandLink
/h:form
Paul Spencer
Re: How to end a SCXML dialog in an action?
On 1/29/07, Paul Spencer [EMAIL PROTECTED] wrote: Rahul, I was using 1.0.4. When I switch to 1.1.0-SNAPSHOT, it worked. snip/ OK, I'll try to reproduce this (in a couple of days) using the 1.0.4 artifacts (nothing jumps out at me that would have caused such a change in behavior, but I'll check). -Rahul Paul Spencer
Re: Applicaion Manger and FacesContext
Hi again,
I've register only one preprocess-class to execute the code once per
request. So the execute method in the preprocess chain do something and
return the logic right value PROCESSING_COMPLETE(true). The code were
execute correctly but the return value (true) avoid the execution of the
doFilter(request, response).
result = command.execute(context);
if (result) {
// Clean up the stored request attribute
request.removeAttribute(CONTEXT_ATTR);
// Bypass calling the remainder of the application
return;
}
doFilter(...);
Why this is happen? Calling the remainder of what, when the processing
are complete?
please help
kind regards
DaWorm
Craig McClanahan wrote:
On 1/27/07, Danny Worm [EMAIL PROTECTED] wrote:
Hi,
I've added the application manager to my application. This feature is
very nice to me. But there is an question about a command-class in the
preprocess-chain. Is it possible to get the FacesContext from the
web-application or an similar way to get the managed-beans from the
factory?
As long as you are executing inside a JSF request (i.e. a request
mapped to
FacesServlet), you can use a convenient static method to get the
FacesContext for the current instance:
FacesContext context = FacesContext.getCurrentInstance();
However, the preprocess chain is executed in a Servlet Filter, before the
JSF machinery has had a chance to create the FacesContext. Therefore,
you'll want to access the underlying servlet API objects directly. The
simplest way to do that is to cast the Context object passed in to your
command to a ShaleWebContext, which gives you accessors for all the
servlet
API objects.
I want to rebind hibernate to the session.
To bind the hibernate session to a session attribute named foo,
you'd do
something like:
Session hibernate = ... create a hibernate session ...;
ShaleWebContext swc = (ShaleWebContext) context;
HttpSession session = (HttpSession) swc.getSession();
session.setAttribute(foo, hibernate);
thanks
kind regards
DaWorm
Craig
Re: Applicaion Manger and FacesContext
On 1/28/07, Danny Worm [EMAIL PROTECTED] wrote:
Hi again,
I've register only one preprocess-class to execute the code once per
request. So the execute method in the preprocess chain do something and
return the logic right value PROCESSING_COMPLETE(true). The code were
execute correctly but the return value (true) avoid the execution of the
doFilter(request, response).
result = command.execute(context);
if (result) {
// Clean up the stored request attribute
request.removeAttribute(CONTEXT_ATTR);
// Bypass calling the remainder of the application
return;
}
doFilter(...);
Why this is happen? Calling the remainder of what, when the processing
are complete?
please help
Returning true in a preprocess command means do not let the user run this
request. You would use it, for example, in a command that enforced some
dynamic security checks. For your scenario, you will want to return false,
which means go ahead and run the rest of the request normally.
kind regards
DaWorm
Craig
Craig McClanahan wrote:
On 1/27/07, Danny Worm [EMAIL PROTECTED] wrote:
Hi,
I've added the application manager to my application. This feature is
very nice to me. But there is an question about a command-class in the
preprocess-chain. Is it possible to get the FacesContext from the
web-application or an similar way to get the managed-beans from the
factory?
As long as you are executing inside a JSF request (i.e. a request
mapped to
FacesServlet), you can use a convenient static method to get the
FacesContext for the current instance:
FacesContext context = FacesContext.getCurrentInstance();
However, the preprocess chain is executed in a Servlet Filter, before
the
JSF machinery has had a chance to create the FacesContext. Therefore,
you'll want to access the underlying servlet API objects directly. The
simplest way to do that is to cast the Context object passed in to your
command to a ShaleWebContext, which gives you accessors for all the
servlet
API objects.
I want to rebind hibernate to the session.
To bind the hibernate session to a session attribute named foo,
you'd do
something like:
Session hibernate = ... create a hibernate session ...;
ShaleWebContext swc = (ShaleWebContext) context;
HttpSession session = (HttpSession) swc.getSession();
session.setAttribute(foo, hibernate);
thanks
kind regards
DaWorm
Craig
Re: Exceptions at startup
On 1/26/07, amjad Shahrour [EMAIL PROTECTED] wrote: Hi, I am using shale-tiger along with ADF faces on tomcat 5.5.8. and i am having several exceptions thrown at the startup of the server (but this seems not affecting the working of shale, i.e. callbacks are being called) Class = org.apache.commons.digester.Digester Parse Error at line 83 column 19: The content of element type attribute must match (description*,display-name*,icon*,attribute-name,at tribute-class,default-value?,suggested-value?,attribute-extension*). One of the frustrating things about Digester error messages is you get the line and column number, but not the resource name :-). But this one looks like an issue with an attribute element in one of your faces-config.xmlresources. Most likely, you have a nested element inside that is not valid (the list after must match is the only valid subelements). Craig org.xml.sax.SAXParseException: The content of element type attribute must match (description*,display-name*,icon*,attribut e-name,attribute-class,default-value?,suggested-value?,attribute-extension*). at org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown Source) at org.apache.xerces.util.ErrorHandlerWrapper.error(Unknown Source) at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source) at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source) at org.apache.xerces.impl.dtd.XMLDTDValidator.handleEndElement (Unknown Source) at org.apache.xerces.impl.dtd.XMLDTDValidator.endElement(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanEndElement (Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch (Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) at org.apache.commons.digester.Digester.parse(Digester.java:1647) at org.apache.shale.tiger.config.FacesConfigParser.parse( FacesConfigParser.java:157) at org.apache.shale.tiger.view.faces.LifecycleListener2.parseResource( LifecycleListener2.java:1282) at org.apache.shale.tiger.view.faces.LifecycleListener2.contextInitialized( LifecycleListener2.java:290) at org.apache.shale.view.faces.LifecycleListener.contextInitialized( LifecycleListener.java:138) at org.apache.catalina.core.StandardContext.listenerStart( StandardContext.java:3659) at org.apache.catalina.core.StandardContext.start( StandardContext.java:4097) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java :1012) at org.apache.catalina.core.StandardHost.start(StandardHost.java :718) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java :1012) at org.apache.catalina.core.StandardEngine.start( StandardEngine.java :442) at org.apache.catalina.core.StandardService.start( StandardService.java:450) at org.apache.catalina.core.StandardServer.start( StandardServer.java :683) at org.apache.catalina.startup.Catalina.start(Catalina.java:537) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke( NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke( DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:271) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:409) regards, Amjad Shahrour
Re: Exception handling on init, prerender and preprocess
On 1/26/07, JS Portal Support [EMAIL PROTECTED] wrote:
Hi,
As the AbstractViewController does not throw Exceptions on its init(),
prerender() and preprocess(), I'm catching the exceptions in these methods
in my own classes extending the AbstractViewController and build my own
dispatching or logging. Why can these methods not utilize shale's
exception
handling?
You can let Shale's exception handling deal with exceptions, but you will
have to wrap a checked exception (i.e. an exception that does not extend
RuntimeException) in order to be able to throw it. Because
javax.faces.FacesException *is* a RuntimeException, I generally do something
like this if I want, say, an IOException to be handled by the Shale
machinery.
try {
... some operation that can throw an exception ...
} catch (IOException e) {
throw new FacesException(e);
}
In the code that ultimately handles exceptions, you'll likely want to unwrap
FacesException instances that have a root cause, to log what really
happened.
Craig
Regards,
Joost
RE: Shale + Facelets + Tomahawk [OT?]
I do have that setting and I should mention that Facelets + Shale are working great together. The problem I'm having is only with the addition of myfaces tomahawk. In the absence of any obvious conflict, I'll run off to bother the myfaces mailing list for a change :) Thanks for the suggestion and have a great day! On 1/26/07, Reynolds, James [EMAIL PROTECTED] wrote: I'm having trouble configuring myfaces tomahawk components to work with Facelets and I'm wondering if there is a conflict with Shale. Is anyone else using this combination successfully? I've seen people say they did, but can't point directly at a mail thread for you. One critical link for Facelets to work is setting the default suffix context init parameter. Did you do that as well? context-param param-namejavax.faces.DEFAULT_SUFFIX/param-name param-value.xhtml/param-value !-- Or whatever your pages use -- /context-param Without this setting, JSF is going to assume the extension is .jsp Craig Based on instructions at the facelets wiki, this is what I've done so far: I've created a file named tomahawk.taglib.xml under /WEB-INF: ?xml version=1.0? !DOCTYPE facelet-taglib PUBLIC -//Sun Microsystems, Inc.//DTD Facelet Taglib 1.0//EN http://java.sun.com/dtd/facelet-taglib_1_0.dtd; facelet-taglib !-- Just in case my email client removes them for me, note that the namespace tags are included below -- namespacehttp://myfaces.apache.org/tomahawk/namespace tag tag-namecommandLink/tag-name component component-typeorg.apache.myfaces.component.html.ext.HtmlCommandLink/c omponent-type renderer-typeorg.apache.myfaces.renderkit.html.HtmlLinkRenderer/rende rer-type /component /tag /facelet-taglib I've registered the file in my web.xml: ... context-param param-namefacelets.LIBRARIES/param-name param-value/WEB-INF/tomahawk.taglib.xml/param-value /context-param ... I've referenced the namespace declared in the taglib file in the root html element of my page as such: xmlns:t=http://myfaces.apache.org/tomahawk; Is there something else I need to do on the Shale side to make this work? Thanks E-Mail messages may contain viruses, worms, or other malicious code. By reading the message and opening any attachments, the recipient accepts full responsibility for taking protective action against such code. Sender is not liable for any loss or damage arising from this message. The information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee(s). Access to this e-mail by anyone else is unauthorized. E-Mail messages may contain viruses, worms, or other malicious code. By reading the message and opening any attachments, the recipient accepts full responsibility for taking protective action against such code. Sender is not liable for any loss or damage arising from this message. The information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee(s). Access to this e-mail by anyone else is unauthorized.
RE: setting rowStyleClass
From: Ian.Priest [EMAIL PROTECTED] See https://issues.apache.org/jira/browse/TOMAHAWK-523 for problem and work-around. Hey, what do you know, facelets has the same problem :--). Thanks for reporting the work around. Cheers, Ian. Gary -Original Message- From: Ian.Priest [mailto:[EMAIL PROTECTED] Sent: 26 January 2007 15:30 To: user@shale.apache.org Subject: setting rowStyleClass Hi, I seem to have an error when setting the rowStyleClass attribute of a table. I'm trying to set the row class dynamically so I can have certain rows highlighted based on a bean variable. Here's my widget, which extends MyFaces Tomahawk DataTable: allowBody=false value=[EMAIL PROTECTED] / ... But no class at all is set in the rendered table. Viewing page source of the final page gives: ... ... ... If I try to set a rowStyleClass in my html as follows (I also remove the ref to rowStyleClass in the widget): All I get is an empty class declaration in my tag: ... Has anyone managed to get this working? Cheers, Ian.
Re: How to display exception thrown by beans during a dialog?
On 1/26/07, Paul Spencer [EMAIL PROTECTED] wrote:
Rahul,
So, if I want to display information from the exception to the user:
1) I need to maintain the exception in the bean, #{venderDialog}.
2) The view displaying the exception would reference a property in the
bean, #{venderDialog.caughtException}?
snip/
I meant com.foo.Vendor in your earlier example below:
dialogs
dialog name=addVendor scxmlconfig=dialogs/addVendor.xml
dataclassname=com.foo.Vendor /
/dialogs
This is because:
* The dialog data is maintained for us, so we don't need to worry
about scoping, the information will exist for as long as the dialog is
active, and no more than that
* IMO, if the exception message (or some other bits) are meaningful
to the user interaction, then the message (or other bits) belong to
the location where we store all data associated with the user
interaction (such as form field values etc.)
Probably the easiest way to populate the dialog data in v1.0.4 is by
setting the value on the appropriate ValueBinding expression, i.e.
updated snippet:
} catch (NotConfiguredException nce) {
FacesContext ctx = FacesContext.getCurrentInstance();
ValueBinding vb = ctx.getApplication().
createValueBinding(#{dialog.data.cfgErrMsg}); // or a
better prop name
vb.setValue(ctx, nce.getMessage());
return notconfigured;
}
Again, the DialogHelper will help eliminate the grunt work [1] of the
catch block in future releases.
Whereby in the subsequent view (for vendor/noconfig state ID), we can have:
h:outputText value=No configuration: #{dialog.data.cfgErrMsg}/
-Rahul
[1] https://issues.apache.org/struts/browse/SHALE-401
public class VendorDialog
{
private Exception caughtException;
// ..
public String setup() { // no throws clause
// ...
try {
// line(s) that can throw NotConfiguredException
} catch (NotConfiguredException nce) {
caughtException = nce;
return notconfigured;
}
// ...
return success;
}
Exception getCaughtException()
{
return caughtException;
}
}
Thank you,
Paul Spencer
snap/
Re: How to end a SCXML dialog in an action?
On 1/26/07, Paul Spencer [EMAIL PROTECTED] wrote:
Rahul Akolkar wrote:
snip/
As mentioned above, that would be inside the method called by the MB,
if at all we wanted to stop an active dialog and delegate to the
faces-config navigation.
What is the name of the method, or where do I configure it, that is
called when the outcome, does is not configured?
In the above example page's header/footer define the outcomes home,
logout, and menu. These outcomes are currently handled by
faces-config.xml, and I agree with your statement about avoiding the
modeling of global site navigation in each dialog.
snap/
Lets say outcome home is actually a commandLink, so simplistically:
h:commandLink action=home value=Home /
This, by itself, would mess with an active dialog. Instead:
h:commandLink action=#{globals.home} value=Home /
would ensure that we clean up correctly if there is an active dialog, where:
// In the managed bean globals --
public String home() {
stopActiveDialogIfAny(); // the two lines of code from before
return home; // faces-config nav rules takes over here
}
Similarly for logout and menu. Also may want to check with user
via onclick or suitable event handlers before wiping out the dialog.
-Rahul
Re: ADF faces with shale tiger
On 1/26/07, amjad Shahrour [EMAIL PROTECTED] wrote: Hi there, I am trying to utilize only shale-tiger with ADF faces. I am interested only in using only the view controller services (callbacks). i created a simple (adf) jsf page and used the @View @Preprocess @Init @Prerender @Destroy on the page's backing bean. but nothing seems to take effect (no callbacks are being called). A couple of quick questions: * Is the backing bean also registered as a managed bean in faces-config.xml? If not, you will also want to use the @Bean annotation. * Does the name you assign the matching bean match the view id so that the matching algorithm will find it? * Have you tried this with just standard components to temporarily reduce the complexity of all the stuff being combined? Craig following is the web.xml file content ?xml version = '1.0' encoding = 'windows-1252'? web-app xmlns=http://java.sun.com/xml/ns/j2ee; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd; version=2.4 descriptionEmpty web.xml file for Web Application/description context-param param-namejavax.faces.STATE_SAVING_METHOD/param-name param-valueserver/param-value /context-param context-param param-nameoracle.adf.view.faces.USE_APPLICATION_VIEW_CACHE /param-name param-valuefalse/param-value /context-param context-param param-nameCpxFileName/param-name param-valuesystemsettings.DataBindings/param-value /context-param !-- Commons Chain Configuration Resources -- filter filter-nameadfFaces/filter-name filter-classoracle.adf.view.faces.webapp.AdfFacesFilter /filter-class /filter filter filter-nameadfBindings/filter-name filter-classoracle.adf.model.servlet.ADFBindingFilter /filter-class /filter filter filter-nameCustomSecurityFilter/filter-name filter-classcom.openaspects.comms.commons.CustomSecurityFilter /filter-class /filter filter filter-nameshale/filter-name filter-class org.apache.shale.application.faces.ShaleApplicationFilter /filter-class /filter !-- Shale Application Controller Filter Mapping -- filter-mapping filter-nameadfFaces/filter-name servlet-namefaces/servlet-name /filter-mapping filter-mapping filter-nameadfBindings/filter-name url-pattern*.jsp/url-pattern /filter-mapping filter-mapping filter-nameadfBindings/filter-name url-pattern*.jspx/url-pattern /filter-mapping filter-mapping filter-nameCustomSecurityFilter/filter-name servlet-namefaces/servlet-name /filter-mapping filter-mapping filter-nameshale/filter-name url-pattern/*/url-pattern /filter-mapping servlet servlet-namefaces/servlet-name servlet-classjavax.faces.webapp.FacesServlet/servlet-class load-on-startup1/load-on-startup /servlet servlet servlet-nameresources/servlet-name servlet-classoracle.adf.view.faces.webapp.ResourceServlet /servlet-class /servlet servlet-mapping servlet-namefaces/servlet-name url-pattern/faces/*/url-pattern /servlet-mapping servlet-mapping servlet-nameresources/servlet-name url-pattern/adf/*/url-pattern /servlet-mapping session-config session-timeout35/session-timeout /session-config mime-mapping extensionhtml/extension mime-typetext/html/mime-type /mime-mapping mime-mapping extensiontxt/extension mime-typetext/plain/mime-type /mime-mapping listener listener-class org.apache.commons.chain.web.ChainListener /listener-class /listener welcome-file-list welcome-file/index.jsp/welcome-file /welcome-file-list error-page exception-typejava.lang.Exception/exception-type location/Error.jsp/location /error-page resource-ref descriptionOracle Datasource example/description res-ref-namejdbc/myoracle/res-ref-name res-typejavax.sql.DataSource/res-type res-authContainer/res-auth /resource-ref /web-app Am I missing something ? thanks in advance
Re: ADF faces with shale tiger
From: amjad Shahrour [EMAIL PROTECTED] Hi there, I am trying to utilize only shale-tiger with ADF faces. I am interested only in using only the view controller services (callbacks). i created a simple (adf) jsf page and used the @View @Preprocess @Init @Prerender @Destroy on the page's backing bean. but nothing seems to take effect (no callbacks are being called). It sounds like you are missing the binding between a JSF view and a managed bean. This is handled by a naming convention. The JSF viewId is normalized into a value that must have a corresponding managed. So if your target page was /something.jsf, the ViewController should be registered as a managed bean by the name of something. The default mapper, removes the suffix of the viewId and replaces the / with $. You can override the default mapper if you want to create your own rules. Since your are using the tiger annotations (you also need shale-tiger besides shale-view and shale-core), you could register your ViewControllers as managed beans with the following annotation: @Bean(name = something, scope = Scope.REQUEST) following is the web.xml file content thanks in advance Gary
Re: ADF faces with shale tiger
You are right Gary, that was the cause. Thanks. I am interested to learn more about the mapper configuration. can you point me to a document about it. regards, amjad On 1/26/07, Gary VanMatre [EMAIL PROTECTED] wrote: From: amjad Shahrour [EMAIL PROTECTED] Hi there, I am trying to utilize only shale-tiger with ADF faces. I am interested only in using only the view controller services (callbacks). i created a simple (adf) jsf page and used the @View @Preprocess @Init @Prerender @Destroy on the page's backing bean. but nothing seems to take effect (no callbacks are being called). It sounds like you are missing the binding between a JSF view and a managed bean. This is handled by a naming convention. The JSF viewId is normalized into a value that must have a corresponding managed. So if your target page was /something.jsf, the ViewController should be registered as a managed bean by the name of something. The default mapper, removes the suffix of the viewId and replaces the / with $. You can override the default mapper if you want to create your own rules. Since your are using the tiger annotations (you also need shale-tiger besides shale-view and shale-core), you could register your ViewControllers as managed beans with the following annotation: @Bean(name = something, scope = Scope.REQUEST) following is the web.xml file content thanks in advance Gary
Re: Shale + Facelets + Tomahawk [OT?]
On 1/26/07, Reynolds, James [EMAIL PROTECTED] wrote: In the taglib file, don't be tempted to list the actual path to the component in the tomahawk jar. Follow the component-type listed in the Facelets wiki I had a feeling it had to do with the tomahawk taglib file. Just so you know we are using that same configuration with our app: MyFaces 1.1.5-SNAPSHOT, Tomahawk 1.1.5-SNAPSHOT, Facelets 1.1.10 and Shale 1.0.4. Greg
Re: ADF faces with shale tiger
From: amjad Shahrour [EMAIL PROTECTED] You are right Gary, that was the cause. Thanks. I am interested to learn more about the mapper configuration. can you point me to a document about it. We have some site documentation [1]. This is Craig's craft-work so the javadoc is also very helpful [2]. [1]http://shale.apache.org/shale-view/index.html [2]http://shale.apache.org/shale-view/apidocs/org/apache/shale/view/impl/DefaultViewControllerMapper.html regards, amjad Gary On 1/26/07, Gary VanMatre wrote: From: amjad Shahrour Hi there, I am trying to utilize only shale-tiger with ADF faces. I am interested only in using only the view controller services (callbacks). i created a simple (adf) jsf page and used the @View @Preprocess @Init @Prerender @Destroy on the page's backing bean. but nothing seems to take effect (no callbacks are being called). It sounds like you are missing the binding between a JSF view and a managed bean. This is handled by a naming convention. The JSF viewId is normalized into a value that must have a corresponding managed. So if your target page was /something.jsf, the ViewController should be registered as a managed bean by the name of something. The default mapper, removes the suffix of the viewId and replaces the / with $. You can override the default mapper if you want to create your own rules. Since your are using the tiger annotations (you also need shale-tiger besides shale-view and shale-core), you could register your ViewControllers as managed beans with the following annotation: @Bean(name = something, scope = Scope.REQUEST) following is the web.xml file content thanks in advance Gary
RE: Starting A DialogContext Programmatically
Hi, great help and making slow progress. I've been breaking my head all day
on this programmatic dialog though.
When I start my dialog though a commandLink, all goes fine, and this is what
my log shows (jsportal=debug and org.apache.shale=debug altered for email a
bit):
(Logon.java:144)Logon will return authenticated
(BasicDialogContext.java:363) - advance(id=1, name=AuthenticateUser,
outcome=authenticated)
(jsportal.PortalBaseViewController.java:146) - findStoredView() called. View
stored:
(jsportal.PortalBaseViewController.java:153)no_view_stored will be returned
as no STORED_VIEW is found
(BasicDialogContext.java:523) - stop(id=1, name=null)
(ViewViewHandler.java:282) - setupViewController(/jsp/dashboard.jsp,false)
all doing what it should do as defined in my below dialog[1]
When I start the AuthenticateUser programmatically the user gets nicely
redirected to the logon.jsf when not logged. Then after logon, no further
execution of the dialog seems to happen. My log shows of this situation:
(Logon.java:144) - Logon will return authenticated
(LifecycleListener.java:604) -
ServletRequestAttributeRemoved(org.apache.shale.view.PHASE_ID,INVOKE_APPLICA
TION(5))
(LifecycleListener.java:538) -
ServletRequestAttributeAdded(org.apache.shale.view.PHASE_ID,RENDER_RESPONSE(
6))
(PortalBaseViewController.java:92) - prerender() called on:
com.jsportal.projectportal.web.JSFaces.Logon
and just the logon will be shown again with that difference manual
navigation to the dashboard.jsf will now be permitted because I'm logged.
I'm lost and don't know what else to try after about 8 hours of banging my
head on the keyboard ;-)
Thanks
Joost
[1] dialog:
dialog name=AuthenticateUser start=CheckLogged
action name=CheckLogged method=#{logon.isLogged}
transition outcome=not_logged target=LogonPage/
transition outcome=logged target=FindStoredView/
/action
view name=LogonPage viewId=/logon.jsp
transition outcome=authenticated
target=FindStoredView/
transition outcome=unauthenticated target=LogonPage/
transition outcome=discontinued_account
target=LogonPage/
/view
action name=FindStoredView method=#{logon.findStoredView}
!--if it holds the stored view, it will navigate there from
the holdsStoredView method--
transition outcome=holds_stored_view target=Exit/
transition outcome=no_view_stored target=Enter/
/action
end name=Enter viewId=/jsp/dashboard.jsp/
end name=Exit/
/dialog
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Craig
McClanahan
Sent: Thursday, January 25, 2007 5:22 AM
To: user@shale.apache.org
Subject: Re: Starting A DialogContext Programmatically
On 1/24/07, JS Portal Support [EMAIL PROTECTED] wrote:
Okay,
For some reason my shale jar's didn't have the DialogContextManager and
DialogContext interfaces in them. I downloaded the latest 1.0.4 ;-) and
that
solved it. Now I can't get to my data anymore without logging in. Jeee!
Is there a problem with the .getVariableResolver() being depreciated by
the
way? What would be the new preferred way?
The issues with using the getVariableResolver() approach are:
* The application is getting involved with the internal plumbing of the
implementation, including depending on the managed beans facility
to create the manager if it does not exist.
* The application is required to be aware of the key under which the
DialogContextManager is stored, and what scope it is in.
* Because the knowledge is scattered all over an application, it would
be essentially impossible to modify the technique inside the framework.
In 1.0.4, the approach I described is the only one that works, and it will
continue to work in later versions. In the nightly builds, last night I
checked in a helper class that makes life a lot easier:
public class DialogHelper {
// Return the active DialogContext (if any)
public static DialogContext getDialogContext();
public static DialogContext getDialogContext(FacesContext context);
// Return the DialogContextManager, creating if needed
public static DIalogContextManager getDialogContextManager();
public static DialogContextManager
getDialogContextManager(FacesContext context);
}
so you end up with very simple calls like:
DialogContextManager manager = DialogHelper.getDialogContextManager();
with all the implementation details hidden away.
I haven't personally tested whether you can successfully navigate (say, to
a login page) from the prerender() method.
It works. When a user tries to access without being logged, the
Authenticate
dialog is started from the prerender. But now, how can I make my user
return
to the initial view which started up the Authenticate dialog. The user
gets
logged on but gets to see the logon.jsp once the Authenticate dialog is
done. Is there a way to create
Re: How to end a SCXML dialog in an action?
On 1/25/07, Paul Spencer [EMAIL PROTECTED] wrote:
I have a dialog that adds a vendor. If the dialog successfully add the
vendor, or the dialog is canceled, then I want to end the dialog with a
call to the action #{vendorManager.listAllVendors}. The view to display
upon the completion of the action is configured in faces-config.xml.
How to do I configure this ?
snip/
For v1.0.4, this requires a bit of knowledge of the internals (the
recent DialogHelper addition to trunk really simplifies this ;-).
Knowing that the active DialogContext is stored as a request-scoped
attribute with key Constants.CONTEXT_BEAN, its possible to end the
dialog like so:
code
DialogContext dcontext = (DialogContext)
FacesContext.getCurrentInstance().getExternalContext().getRequestMap().get(Constants.CONTEXT_BEAN);
dcontext.stop();
/code
You can guard the stop() with a not null and isActive() predicate, if
deemed necessary. The good thing is this will also do the necessary
book-keeping cleanup associated with the DialogContextManager for you.
Assumes the view displayed (via the faces-config nav rule) is not part
of any dialog at that point.
-Rahul
Paul Spencer
Re: How to end a SCXML dialog in an action?
Rahul,
I do not completely follow you answer.
Assume the following:
1) stateId = start
Display the view /editVendor_1
OutcomeNext state
---
successpage2
cancel end
2) stateId = page2
Display the view /editVendor_2
OutcomeNext state
---
successsave
cancel end
3) stateId = save
Execute the action #{vendorDialog.save}
OutcomeNext state
---
successend
failurestart
4) End state stateId = end
Execute the action #{vendorManager.listAllVendors}. faces-config.xml
will take over form here.
5) dialog-config.xml
dialogs
dialog name=addVendor scxmlconfig=dialogs/addVendor.xml
dataclassname=com.foo.Vendor /
/dialogs
6) Using Shale 1.0.4
What does the dialog's scxml file look like?
Where does the code you mentioned below go and how is it called?
Paul Spencer
Rahul Akolkar wrote:
On 1/25/07, Paul Spencer [EMAIL PROTECTED] wrote:
I have a dialog that adds a vendor. If the dialog successfully add the
vendor, or the dialog is canceled, then I want to end the dialog with a
call to the action #{vendorManager.listAllVendors}. The view to display
upon the completion of the action is configured in faces-config.xml.
How to do I configure this ?
snip/
For v1.0.4, this requires a bit of knowledge of the internals (the
recent DialogHelper addition to trunk really simplifies this ;-).
Knowing that the active DialogContext is stored as a request-scoped
attribute with key Constants.CONTEXT_BEAN, its possible to end the
dialog like so:
code
DialogContext dcontext = (DialogContext)
FacesContext.getCurrentInstance().getExternalContext().getRequestMap().get(Constants.CONTEXT_BEAN);
dcontext.stop();
/code
You can guard the stop() with a not null and isActive() predicate, if
deemed necessary. The good thing is this will also do the necessary
book-keeping cleanup associated with the DialogContextManager for you.
Assumes the view displayed (via the faces-config nav rule) is not part
of any dialog at that point.
-Rahul
Paul Spencer
RE: where did org/apache/shale/taglib/CommonsValidatorTag go in 1.0.4?
Aha! Guess I'll have to do a directory wide find and replace from s:commonsValidator to val:commonsValidator ;-) Thanks! Joost Dasstraat 21 2623CB Delft the Netherlands W: www.jsportal.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matthias Wessendorf Sent: Wednesday, January 24, 2007 10:06 PM To: user@shale.apache.org Subject: Re: where did org/apache/shale/taglib/CommonsValidatorTag go in 1.0.4? shale-validator\src\main\java\org\apache\shale\validator\faces\ValidatorTag. java -M On 1/24/07, JS Portal Support [EMAIL PROTECTED] wrote: Hi, I just downloaded 1.0.4 to give it a go, and can't find org/apache/shale/taglib/CommonsValidatorTag In the shale-core-1.0.4.jar. Is that correct? If so, where can I find it now. The shale-validator-1.0.4.jar does not contain it either. Thank you, Joost -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
RE: Starting A DialogContext Programmatically
Okay, For some reason my shale jar's didn't have the DialogContextManager and DialogContext interfaces in them. I downloaded the latest 1.0.4 ;-) and that solved it. Now I can't get to my data anymore without logging in. Jeee! Is there a problem with the .getVariableResolver() being depreciated by the way? What would be the new preferred way? I haven't personally tested whether you can successfully navigate (say, to a login page) from the prerender() method. It works. When a user tries to access without being logged, the Authenticate dialog is started from the prerender. But now, how can I make my user return to the initial view which started up the Authenticate dialog. The user gets logged on but gets to see the logon.jsp once the Authenticate dialog is done. Is there a way to create a dialog programmatically, like you described, moving the user to the view on which prerender is called and then set the Authenticate as a child so that after authenticate, the user will be redirected back to the initial view? I hope I'm not too much of a burden using you as a climbing rope on my shale learning curve ;-) Cheers, Joost JS Portal Dasstraat 21 2623CB Delft the Netherlands W: www.jsportal.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Craig McClanahan Sent: Wednesday, January 24, 2007 4:53 PM To: user@shale.apache.org Subject: Re: Starting A DialogContext Programmatically On 1/23/07, JS Portal Support [EMAIL PROTECTED] wrote: Hi, I have a ViewController which in it's prerender checks if the user in the session is logged or not. If not, I want to start a subdialog logging the user in. On page http://shale.apache.org/shale-dialog/index.html at: Starting A DialogContext Programmatically it is described how I can do this. I don't understand it though. Do I need to build my own DialogContextManager and DialogContext as they seem to be interfaces? Or are there implementations I can use, and if so, where can I find them? An example would be great! The shale-test-dialog-basic and shale-test-dialog-scxml test webapps (they are built nightly along with the framework) have an example of this use case. One nice feature is that the application coding is the same no matter which implementation you use. The DialogContextManager instance is created for you by the framework, so all you will need to do is acquire a reference to it, and then ask it to create you a DialogContext instance like this: FacesContext context = FacesContext.getCurrentInstance(); DialogContextManager manager = (DialogContextManager) context.getApplication().getVariableResolver(). resolveVariable(context, Constants.MANAGER_BEAN); DialogContext dcontext = manager.create(context, myDialogName); dcontext.start(context); You do not have to do anything else about storing the DialogContext instance, because the manager will have taken care of that for you. By the way, the reason for using the variable resolver, in the code example above, is because the dialog framework defines the manager as a managed bean. Doing things this way (instead of just checking the write scoped attributes) causes the manager to be created if it does not already exist. By the way, is this a good architecture approach, checking the logged status on prerender and preprocess? Or are there other better ways to do this? The only thing I would be concerned about is navigation -- I haven't personally tested whether you can successfully navigate (say, to a login page) from the prerender() method. If that works for you, then this seems like a reasonable approach. Thanks, Joost Schouten Craig
Re: Integrating JSF and Shale Tiles
A couple of intermixed comments ... I'm hoping Greg and others more familiar with Tiles than I am might be able to help too. On 1/24/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I've tried to use the shale-framework-1.0.4.zip file and have hit a problem that I was wondering if anyone could help me with? I've developed a very simple 2 page JSF application using Workshop v3.2.1 which just allows you to move from the first to the second pages using a commandLinks action to trigger a JSF navigation. This has all the common JARs as per the shale-framework-1.0.4.zip and works fine. However when I added in the shale-*-1.0.4.jar's, spring-*1.2.8.jar's and tiles-core-2.0-468346-SNAPSHOT.jar and make some config file changes to introduce Tiles behaviour I start to get problems. It might be a little easier to debug things like this if you only add one layer of stuff at a time :-). To my faces-config.xml I added view-handlerorg.apache.shale.tiles.TilesViewHandler/view-handler You do not need to do this ... it is already done inside the shale-tiles-xxx.jar file. To my web.xml file I added a context parameter pointing to my new tiles.xml file context-param param-nametiles-definitions/param-name param-value/WEB-INF/tiles.xml/param-value /context-param and added an additional servlet servlet servlet-nameTiles Servlet/servlet-name servlet-classorg.apache.tiles.servlet.TilesServlet /servlet-class load-on-startup1/load-on-startup /servlet the existing (faces) servlet had the load-on-startup value changed to 2 (from 1) at this point. I created a tiles.xml file (within the WEB-INF folder) that just defines a header, menu, content format for these same 2 pages (with the header being made up of 3 sub-parts a banner, breadcrumb trail and heading). ?xml version=1.0 encoding=UTF-8? !DOCTYPE tiles-definitions PUBLIC -//Apache Software Foundation//DTD Tiles Configuration//EN http://jakarta.apache.org/struts/dtds/tiles-config.dtd; tiles-definitions !-- These are the general tile layouts that will be used by every page -- definition name=header path=/tiles/header.jsp put name=banner value=/pages/exampleBanner.jsp / put name=breadcrumb value=/pages/exampleBreadcrumb.jsp / put name=headerTitle value=/pages/exampleHeader.jsp / /definition definition name=menu path=/tiles/menu.jsp put name=menuDetail value=/pages/exampleMenu.jsp / /definition !-- These are the definitions for each page -- definition name=page1 path=/tiles/headerMenuContent.jsp put name=header value=header/ put name=menu value=menu/ put name=content value=page1Content/ /definition definition name=page1Content path=/tiles/content.jsp put name=contentContent value=/pages/standardPage.jsp / /definition definition name=page2 path=/tiles/headerMenuContent.jsp put name=header value=header/ put name=menu value=menu/ put name=content value=page2Content/ /definition definition name=page2Content path=/tiles/content.jsp put name=contentContent value=/pages/standardPage2.jsp / /definition /tiles-definitions I also added in the necessary menu, header, content and headerMenuContent JSPs into the tiles folder (at the same level as the pages folder) and the example*** JSPs into the pages folder. The application builds within Workshop OK but when I try and run it (Tomcat v5.5) I get the following output in the console... INFO: Initializing TilesServlet 24-Jan-2007 16:05:29 org.apache.tiles.servlet.TilesServletreadFactoryConfig INFO: CONFIG FILES WERE NOT DEFINED IN WEB.XML, LOOKING FOR /WEB-INF/tiles.xml This message implies that your context init parameter is not being recognized. If I am reading the Tiles code correctly, the parameter name should now be org.apache.tiles.DEFINITIONS_CONFIG although definitions-config is still recognized for backwards compatibility. 24-Jan-2007 16:05:29 org.apache.tiles.servlet.TilesServlet initDefinitionsFactory INFO: initializing definitions factory... org.apache.tiles.DefinitionsFactoryException: I/O Error reading definitions. at The fact that this says I/O error instead of parsing error implies that the problem is not finding the file at all (rather than some problem with the XML syntax). Craig org.apache.tiles.digester.DigesterDefinitionsReader.read( DigesterDefinitionsReader.java:161) at org.apache.tiles.definition.UrlDefinitionsFactory.readDefinitions( UrlDefinitionsFactory.java:253) at org.apache.tiles.TilesUtilImpl.createDefinitionsFactory(TilesUtilImpl.java :190) at org.apache.tiles.TilesUtil.createDefinitionsFactory(
Re: Shale Application Controller page not updated to 1.0.4
On 1/24/07, Paul Spencer [EMAIL PROTECTED] wrote: The first sentence paragraph in (A) Standard Per-Request Processing has not been updated to 1.0.4. It should be: As described in Configuring Your Application For Shale, you are requested to configure a Servlet Filter (org.apache.shale.applicationfaces.ShaleApplicationFilter) The class name changed! Thanks for catching this! I fixed the reference you mentioned above, plus some obsolete dependency information on the using.html page. I've created an omnibus JIRA ticket[2] to catch any more of these problems in the future, because we will want to apply them to both the 1.0 branch as well as the trunk. So, if you see any more cases, please comment on this ticket. Paul Spencer [1] http://shale.apache.org/shale-application/index.html [2] https://issues.apache.org/struts/browse/SHALE-397
Re: How to use request scoped manage beans in a 1.0.4 dialog?
I think we're far enough along in our thinking to start exploring implementation, so I've opened an issue to track it[1]. Craig [1] https://issues.apache.org/struts/browse/SHALE-399
Re: Choosing a JSF/AJAX Framework
On 1/24/07, James Watkin [EMAIL PROTECTED] wrote:
Craig,
Thank you for your time, information, and openness.
I'd also like to pass along a link to a video interview of Ed Burns that
I watched today:
http://w.on24.com/r.htm?e=25412s=1k=1C3610AF899E09A2EFD26F0FD6B7875Epartnerref=atssc_sitepost_01_16_07
In this interview, Ed Burns talked about JSF frameworks like Apache
Shale and how the next version of the JSF spec will leverage ideas from
them.
Some specific features mentioned for the next (2.0?) JSF spec were
conversation scope, additional core components, state management, and
some sort of AJAX support.
In a reference to Apache Shale, Ed Burns said, ...they (Apache Shale)
have a remoting package that provides the ability to facilitate AJAX by
invoking method bindings in the server but it turns out there are some
security issues with that, but I think they'll be addressed. I don't
know how old this interview is. Can you explain what he's referring to
and whether or not it was addressed?
Yes, it was an old issue (the interview was recorded a while ago), and yes
it has been addressed in the 1.0.4 release. The issue related to the way
that the dynamic processor mapped a request URL to a method binding that
could call any public method on a managed bean that has zero parameters. In
other words, a URL like:
http://localhost:8080/myapp/dynamic/foo/bar.faces
(assumes you are using *.faces mapping for FacesServlet) would cause a
method binding expression #{foo.bar} to be constructed, and therefore the
bar method would be called. The challenge is that you might have public
zero-args methods in your managed beans that are not designed to be executed
directly from a client call like that, and gives clients an opportunity to
disrupt your application.
Today, the fix for this is a set of context init parameters that can be used
to limit what URL patterns are allowed or disallowed for this processor (as
well as the ones that serve static resources) to serve. It will return not
allowed HTTP errors if you attempt to use a prohibited URL pattern. The
gory details of configuring this are in the package summary Javadocs[1].
In the future, when we can move to an assumption of Java SE 5 as the
baseline (or successfully demonstrate that retro-weaved JARs can run
on 1.4systems), we'll be able to use annotations to explicitly
identify the public
methods that you want to make accessible to the dynamic processor. That's a
lot more fine grained and easily understood than having to remember to
update URL patterns in context init parameters.
- Jim
Craig
Craig McClanahan wrote:
On 1/23/07, James Watkin [EMAIL PROTECTED] wrote:
I'm looking for a new web application framework. From attending various
conferences and selected readings, it appears that a framework which
supports JSF and AJAX is probably what we're looking for.
Again, based solely on conferences and selected readings, the following
frameworks appear to have merit:
* Apache Shale or JBoss Seam for a high-end code-centric framework.
http://shale.apache.org/
http://www.jboss.com/products/seam
* ICEfaces for superior JSF/AJAX integration.
http://www.devx.com/security/Article/33533
http://www.icesoft.com/products/icefaces.html
http://theserversidecom.bitpipe.com/detail/RES/1163445089_619.html?src=wc_atssc_sitepost_11_14_06
* NetBeans Visual Web Pack (or Sun Java Studio Creator) for rapid
development.
http://www.netbeans.org/products/visualweb/
http://developers.sun.com/prodtech/javatools/jscreator/index.jsp
* Spring Web Flow combined with JSF?
http://opensource.atlassian.com/confluence/spring/display/WEBFLOW/Home
You might want to add one more category of things to look at ...
JSF-based
libraries that enable the use of non-Ajax-aware JSF components in an
Ajax
environment (partial page submit, partial page refresh). Two libraries
at
java.net that do this kind of thing:
* https://ajax4jsf.dev.java.net/
* https://jsf-extensions.dev.java.net/
I notice that JBoss Seam appears to have support for ICEfaces. Does
Apache Shale plan to do the same? If not, why not, and does Apache
Shale
have some other plan to support AJAX, and what will be the benefit of
that other approach?
You will see two attitudes in Shale towards this issue:
* Shale does not contain any components itself ... it is designed to add
value
on the server side while working with *any* component
library. Therefore,
in principle, it should work with any of the JSF-Ajax component
libraries
that
you like. That being said, if there are compelling advantages to be
gained by
an explicit integration layer for particular libraries, we will
certainly
look at that.
But, in the particular case of ICEFaces, there shouldn't be anything
required
other than just putting all the right libraries together.
* For the particular use case of a client side application that wants to
do
asynchronous callbacks *without* updating the JSF component
Re: How to use request scoped manage beans in a 1.0.4 dialog?
Craig,
I embedded my comments.
Craig McClanahan wrote:
On 1/24/07, Paul Spencer [EMAIL PROTECTED] wrote:
Craig,
I embedded my comments. They are near the end.
Paul Spencer
Craig McClanahan wrote:
On 1/24/07, Paul Spencer [EMAIL PROTECTED] wrote:
snip
o For simple dialogs only configuration changes should be required, the
implementation of a interface like DialogContextListener, should
not be
required. The default DialogContextListener implemention should do
the
please save and restore this stuff for me in
onActivate()/onDeactivate().
Isn't the list of what request scope beans you want to save and restore
going to be specific to each dialog definition? I agree that we should
provide a listener implementation that does the work, but it will still
need
to be configured.
Yes, the list of beans is specific to a dialog.
Up to this point the beans have been request scope. What if the user
configures a session or application scope bean? On the face it seems the
save/restore process will be wasted work, but can/should a request a
request
scope bean be created? Thus the bean will have a request and
session/appliction set of
properties.
It is technically legal to have beans with the same name in different
scopes. The EL evaluation rules guarantee that the same order will be
followed (request, then session, then application), at least for expression
evaluation, so the results will be predictable.
I think your point about wasted work is key ... if you are already keeping
your state information in session or application scope, you do not *need*
this new mechanism, so you should keep on doing what you are doing. The
accesses to sesion and application scope data will still work inside the
dialog execution.
If the user wants to configure a session or application scopes bean, they
can and it will work.
Cool
Separately but related, I'm thinking that the configuration information
would be a set of zero or more value binding expressions. Saving the
state
information would end up calling getValue() on these, and storing in
session
scope, while restoring will mean calling setValue() on the value
binding.
This should work for request scope variables ... for an expression
#{foo}:
* Caling getValue() will look up this variable in any scope ... thus
will find it in session scope if it is there.
* Calling setValue() will cause a new request scope variable to be
created.
Doing this lets us cover the simple case of entire attributes, but also
gives the developer the freedom to save and restore properties of an
existing scoped bean, instead of just scoped beans themselves.
Also separately but related, it seems to me that someone using this
approach
would not need the data property of DialogContext explicitly. Thus,
we
could offer a concrete implementation bean that does the save/restore
stuff
for you, and is configured by setting a list of expressions. The
DialogContext implementations already notice when the data class is a
DialogContextListener, so adding the onActivate()/onDeactivate()
methods
to
the event signature should be all the wiring we need. (This will make
more
sense when I work out a concrete example ... but I think we can
dispense
with modifying the configuration DTDs at all.)
1) Yes, the data property of DialogContext would not be needed.
2) I am not sure what you mean by configured by setting a list
of expressions. The exact details around how the list of beans
to be saved/restored is configued can be detemined later.
Yah, I was kind of hand waving there :-). I've checked in the first steps
of the mechanism, and am working on a concrete class that illustrates
what I
was talking about here in code instead of words ... hopefully that will be
easier to understand.
I look forward to using it.
o The user should be able to convert from a series of views that use a
session scoped bean to pass the data between views to a dialog using
request scoped bean with the following configuration changes:
1) Change the scope of the session bean to request.
2) Define the dialog
3) Update the actions to reference the dialog
That makes a lot of sense, but I don't think step 3 is actually
required.
As part of step 2, you will just need to make sure that you define
transitions for all of the possible outcomes that the actions can
return,
and you should not have to modify the actions themselves (or the pages
that
used value binding expressions to the state data). That's a pretty
elegant
migration path.
The actions will need to change. They may be addPage1, addPage2..
and
will
change to dialog:add, next,
I agree that the link that starts the dialog would need to change, but is
there any reason you *have* to change the rest of them? It's certainly
possible to do so, but I don't think it would be a requirement for
migration.
I agree, you only have to change the action that starts the dialog
Re: Re : [Shale view 1.0.4]
On 1/22/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: I think we should add 105-snap and 104-release to the jira versions Version 1.0.5-SNAPSHOT is already there. The 1.0.4-SNAPSHOT version will get converted into 1.0.4 as a byproduct of the release process that Rahul is executing. But, in this particular case, it didn't get fixed in 1.0.4, so we would want to tag this as being fixed only in 1.0.5-SNAPSHOT and 1.1.0-SNAPSHOT. (howto do that?) This just takes JIRA admin privileges, which I have but can happily share. Give me a shout if you'd like the ability to do that kind of thing. Craig On 1/22/07, Craig McClanahan [EMAIL PROTECTED] wrote: On 1/22/07, Rahul Akolkar [EMAIL PROTECTED] wrote: On 1/22/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: I guess since other will run into this, I created a ticket and marked it as fixed for 1.1.0 so the release notes contain that ;) https://issues.apache.org/struts/browse/SHALE-394 snip/ Thanks, seems like a good example of something that should be applied to the 1_0_X branch too. Would you like to do that as well? Agreed, although in general I also think you're setting a good precedent by asking for agreement (lazy consensus) first. -Rahul Craig On 1/21/07, Adrian Gonzalez [EMAIL PROTECTED] wrote: Thank you very much. So, I suppose I don't need to open an issue anymore ? - Message d'origine De : Matthias Wessendorf [EMAIL PROTECTED] À : user@shale.apache.org Envoyé le : Dimanche, 21 Janvier 2007, 23h40mn 24s Objet : Re: [Shale view 1.0.4] fixed already in current trunk (see svn commit: r497775) or http://svn.apache.org/viewvc/shale/framework/trunk/shale-view/src/main/java/org/apache/shale/view/faces/ViewPhaseListener.java?view=diffr1=497774r2=497775pathrev=497775 thx, Matt On 1/21/07, Craig McClanahan [EMAIL PROTECTED] wrote: On 1/21/07, Adrian Gonzalez [EMAIL PROTECTED] wrote: Hello, I think there's a little bug on shale view 1.0.4. Shale View : Bug on render response phase when removing view from request map. Error in org.apache.shale.view.faces.ViewPhaseListener, method afterRenderResponse, lien 233 : iterator obtained from map, code calling map.remove, and afterward using iterator which generated ConcurrentModificationException. snip/ -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: Re : [Shale view 1.0.4]
On 1/23/07, Craig McClanahan [EMAIL PROTECTED] wrote: snip/ Version 1.0.5-SNAPSHOT is already there. The 1.0.4-SNAPSHOT version will get converted into 1.0.4 as a byproduct of the release process that Rahul is executing. snap/ Done. -Rahul
Re: Core Shale Tiles functionality?
On 1/22/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I'm just starting to look at Shale and would like to use the Tiles functionality. I understand that there is an optional Tiles 2 JAR that is still in the Struts sandbox. Yes, there is still a snapshot built from the code in the Struts sandbox. You can see the snapshot builds here: http://people.apache.org/maven-snapshot-repository/org/apache/struts/tiles/tiles-core/ The version that currently works with Shale is 2.0-r468346-SNAPSHOT. If you are using Maven you can use the Tiles doc located here: http://tiles.apache.org/ If you are not using Maven you'll need to download the version noted above from the snapshot repository listed above. Does all Tiles functionality in Shale require this sandbox version of Tiles or is there some Tile functionality available out-of-the-box with Shale? No, if you want to use Shale-Tiles you'll have to use the sandbox version of Tiles. This should all be clearing up soon as Tiles has been promoted to a TLP. My hope is that you will see an actual release coming out soon. HTH, Greg
Re: Re : [Shale view 1.0.4]
On 1/22/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
I guess since other will run into this,
I created a ticket and marked it as fixed for 1.1.0
so the release notes contain that ;)
https://issues.apache.org/struts/browse/SHALE-394
Thanks Matthias!
Craig
On 1/21/07, Adrian Gonzalez [EMAIL PROTECTED] wrote:
Thank you very much.
So, I suppose I don't need to open an issue anymore ?
- Message d'origine
De : Matthias Wessendorf [EMAIL PROTECTED]
À : user@shale.apache.org
Envoyé le : Dimanche, 21 Janvier 2007, 23h40mn 24s
Objet : Re: [Shale view 1.0.4]
fixed already in current trunk
(see svn commit: r497775)
or
http://svn.apache.org/viewvc/shale/framework/trunk/shale-view/src/main/java/org/apache/shale/view/faces/ViewPhaseListener.java?view=diffr1=497774r2=497775pathrev=497775
thx,
Matt
On 1/21/07, Craig McClanahan [EMAIL PROTECTED] wrote:
On 1/21/07, Adrian Gonzalez [EMAIL PROTECTED] wrote:
Hello,
I think there's a little bug on shale view 1.0.4.
Shale View : Bug on render response phase when removing view from
request
map.
Error in org.apache.shale.view.faces.ViewPhaseListener, method
afterRenderResponse, lien 233 :
iterator obtained from map, code calling map.remove, and afterward
using
iterator which generated ConcurrentModificationException.
Just change this order :
- remove FacesConstants.VIEWS_INITIALIZED from map.
- obtain iterator.
- use iterator.
I've just changed this piece of code in order to have :
private void afterRenderResponse(PhaseEvent event) {
/*AFTER CHANGE*/
// Initialize local values we will need
Map map = event.getFacesContext
().getExternalContext().getRequestMap();
List list = new ArrayList();
// Remove our list of initialized views explicitly
map.remove(FacesConstants.VIEWS_INITIALIZED);
Iterator entries = map.entrySet().iterator();
instead of :
/*BEFORE CHANGE
// Initialize local values we will need
Map map = event.getFacesContext
().getExternalContext().getRequestMap();
List list = new ArrayList();
Iterator entries = map.entrySet().iterator();
// Remove our list of initialized views explicitly
map.remove(FacesConstants.VIEWS_INITIALIZED);
And it's ok (or it seems).
Adrian,
Thanks very much for the thorough analysis ... it looks like you are
on
target (although it likely depends on your VM's implementation of the
iterator methods so the problem may or may not manifest itself
everywhere).
Could you do me a favor and file a bug in our issue tracking system[1]
for
this? That way, the eventual fix will automatically be included in
the
release notes for the next version.
Craig
[1] https://issues.apache.org/struts/browse/SHALE
Here's the stack trace I had :
[21/01/07 20:38:36:453 CET] 0043 helperI BEFORE
RENDER_RESPONSE(6)
[21/01/07 20:38:38:765 CET] 0043 HtmlTableRend E
org.apache.myfaces.shared_tomahawk.renderkit.html.HtmlTableRendererBaseencodeInnerHtmlRow
is not available. Rowindex = 3
[21/01/07 20:38:38:921 CET] 0043 HtmlResponseW W
org.apache.myfaces.shared_impl.renderkit.html.HtmlResponseWriterImplendElementHTML
nesting warning on closing tbody: element tr rendered by
component : {Component-Path : [Class:
org.ajax4jsf.framework.ajax.AjaxViewRootRIOneOne,ViewId:
/userList.jsp][Class: javax.faces.component.html.HtmlForm,Id:
editUser][Class: org.apache.myfaces.component.html.ext.HtmlDataTable
,Id:
userList]} not explicitly closed
[21/01/07 20:38:40:250 CET] 0043 PhaseListener E
org.apache.myfaces.lifecycle.PhaseListenerManagerinformPhaseListenersAfterException
in PhaseListener RENDER_RESPONSE(6)
afterPhase
java.util.ConcurrentModificationException
at java.util.HashMap$HashIterator.nextEntry(HashMap.java:942)
at java.util.HashMap$KeyIterator.next(HashMap.java:978)
at com.ibm.ws.webcontainer.srt.SRTServletRequest$1.nextElement(
SRTServletRequest.java:177)
at
org.apache.myfaces.context.servlet.AbstractAttributeMap$KeyIterator.next(
AbstractAttributeMap.java:210)
at
org.apache.myfaces.context.servlet.AbstractAttributeMap$EntryIterator.next
(AbstractAttributeMap.java:306)
at
org.apache.shale.view.faces.ViewPhaseListener.afterRenderResponse(
ViewPhaseListener.java:233)
at org.apache.shale.view.faces.ViewPhaseListener.afterPhase(
ViewPhaseListener.java:106)
at
org.apache.myfaces.lifecycle.PhaseListenerManager.informPhaseListenersAfter
(PhaseListenerManager.java:89)
at org.apache.myfaces.lifecycle.LifecycleImpl.render(
LifecycleImpl.java:391)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java
:138)
at org.apache.myfaces.webapp.MyFacesServlet.service(
MyFacesServlet.java:74
Re: Core Shale Tiles functionality?
On 1/22/07, Greg Reddin [EMAIL PROTECTED] wrote: On 1/22/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I'm just starting to look at Shale and would like to use the Tiles functionality. I understand that there is an optional Tiles 2 JAR that is still in the Struts sandbox. Yes, there is still a snapshot built from the code in the Struts sandbox. You can see the snapshot builds here: http://people.apache.org/maven-snapshot-repository/org/apache/struts/tiles/tiles-core/ The version that currently works with Shale is 2.0-r468346-SNAPSHOT. If you are using Maven you can use the Tiles doc located here: http://tiles.apache.org/ If you are not using Maven you'll need to download the version noted above from the snapshot repository listed above. Does all Tiles functionality in Shale require this sandbox version of Tiles or is there some Tile functionality available out-of-the-box with Shale? No, if you want to use Shale-Tiles you'll have to use the sandbox version of Tiles. This should all be clearing up soon as Tiles has been promoted to a TLP. My hope is that you will see an actual release coming out soon. In addition to what Greg said, you should also be aware that releases and nightly builds of Shale ship with the correct version of the Tiles snapshot jar for that particular version of Shale (in the lib subdirectory of the framework archive file), so that is probably the simplest way to make sure you've got the correct snapshot. Craig HTH, Greg
Re: Re : [Shale view 1.0.4]
On 1/22/07, Rahul Akolkar [EMAIL PROTECTED] wrote: On 1/22/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: I guess since other will run into this, I created a ticket and marked it as fixed for 1.1.0 so the release notes contain that ;) https://issues.apache.org/struts/browse/SHALE-394 snip/ Thanks, seems like a good example of something that should be applied to the 1_0_X branch too. Would you like to do that as well? Agreed, although in general I also think you're setting a good precedent by asking for agreement (lazy consensus) first. -Rahul Craig On 1/21/07, Adrian Gonzalez [EMAIL PROTECTED] wrote: Thank you very much. So, I suppose I don't need to open an issue anymore ? - Message d'origine De : Matthias Wessendorf [EMAIL PROTECTED] À : user@shale.apache.org Envoyé le : Dimanche, 21 Janvier 2007, 23h40mn 24s Objet : Re: [Shale view 1.0.4] fixed already in current trunk (see svn commit: r497775) or http://svn.apache.org/viewvc/shale/framework/trunk/shale-view/src/main/java/org/apache/shale/view/faces/ViewPhaseListener.java?view=diffr1=497774r2=497775pathrev=497775 thx, Matt On 1/21/07, Craig McClanahan [EMAIL PROTECTED] wrote: On 1/21/07, Adrian Gonzalez [EMAIL PROTECTED] wrote: Hello, I think there's a little bug on shale view 1.0.4. Shale View : Bug on render response phase when removing view from request map. Error in org.apache.shale.view.faces.ViewPhaseListener, method afterRenderResponse, lien 233 : iterator obtained from map, code calling map.remove, and afterward using iterator which generated ConcurrentModificationException. snip/
Re: Re : [Shale view 1.0.4]
lemme check out _1_0_x tomorrow (only working on *trunk* ;)) -M On 1/22/07, Craig McClanahan [EMAIL PROTECTED] wrote: On 1/22/07, Rahul Akolkar [EMAIL PROTECTED] wrote: On 1/22/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: I guess since other will run into this, I created a ticket and marked it as fixed for 1.1.0 so the release notes contain that ;) https://issues.apache.org/struts/browse/SHALE-394 snip/ Thanks, seems like a good example of something that should be applied to the 1_0_X branch too. Would you like to do that as well? Agreed, although in general I also think you're setting a good precedent by asking for agreement (lazy consensus) first. -Rahul Craig On 1/21/07, Adrian Gonzalez [EMAIL PROTECTED] wrote: Thank you very much. So, I suppose I don't need to open an issue anymore ? - Message d'origine De : Matthias Wessendorf [EMAIL PROTECTED] À : user@shale.apache.org Envoyé le : Dimanche, 21 Janvier 2007, 23h40mn 24s Objet : Re: [Shale view 1.0.4] fixed already in current trunk (see svn commit: r497775) or http://svn.apache.org/viewvc/shale/framework/trunk/shale-view/src/main/java/org/apache/shale/view/faces/ViewPhaseListener.java?view=diffr1=497774r2=497775pathrev=497775 thx, Matt On 1/21/07, Craig McClanahan [EMAIL PROTECTED] wrote: On 1/21/07, Adrian Gonzalez [EMAIL PROTECTED] wrote: Hello, I think there's a little bug on shale view 1.0.4. Shale View : Bug on render response phase when removing view from request map. Error in org.apache.shale.view.faces.ViewPhaseListener, method afterRenderResponse, lien 233 : iterator obtained from map, code calling map.remove, and afterward using iterator which generated ConcurrentModificationException. snip/ -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: Re : [Shale view 1.0.4]
I think we should add 105-snap and 104-release to the jira versions (howto do that?) On 1/22/07, Craig McClanahan [EMAIL PROTECTED] wrote: On 1/22/07, Rahul Akolkar [EMAIL PROTECTED] wrote: On 1/22/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: I guess since other will run into this, I created a ticket and marked it as fixed for 1.1.0 so the release notes contain that ;) https://issues.apache.org/struts/browse/SHALE-394 snip/ Thanks, seems like a good example of something that should be applied to the 1_0_X branch too. Would you like to do that as well? Agreed, although in general I also think you're setting a good precedent by asking for agreement (lazy consensus) first. -Rahul Craig On 1/21/07, Adrian Gonzalez [EMAIL PROTECTED] wrote: Thank you very much. So, I suppose I don't need to open an issue anymore ? - Message d'origine De : Matthias Wessendorf [EMAIL PROTECTED] À : user@shale.apache.org Envoyé le : Dimanche, 21 Janvier 2007, 23h40mn 24s Objet : Re: [Shale view 1.0.4] fixed already in current trunk (see svn commit: r497775) or http://svn.apache.org/viewvc/shale/framework/trunk/shale-view/src/main/java/org/apache/shale/view/faces/ViewPhaseListener.java?view=diffr1=497774r2=497775pathrev=497775 thx, Matt On 1/21/07, Craig McClanahan [EMAIL PROTECTED] wrote: On 1/21/07, Adrian Gonzalez [EMAIL PROTECTED] wrote: Hello, I think there's a little bug on shale view 1.0.4. Shale View : Bug on render response phase when removing view from request map. Error in org.apache.shale.view.faces.ViewPhaseListener, method afterRenderResponse, lien 233 : iterator obtained from map, code calling map.remove, and afterward using iterator which generated ConcurrentModificationException. snip/ -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: Shale ExceptionHandling
Hello Craig:
Thank for a quick response. I downloaded the 1.1.0-SNAPSHOT but cannot
find a binary for trunk/shale-apps/*. Do you think it will be available
soon? What is the difference between shale-apps and shale-application
directories?
On Sat, 2007-01-20 at 17:43 -0800, Craig McClanahan wrote:
On 1/20/07, Duong BaTien [EMAIL PROTECTED] wrote:
Hello Craig:
I am trying to look at shale-apps/shale-test-view to see an example of
ViewController exception handling. I download from svn and try to build
it from mvn but get the following exception:
The plugin 'org.codehaus.mojo:cobertura-maven-plugin' does not exist or
no valid version could be found
I then try to get the latest nightly build, but they all disappeared.
Where are they located now?
There has been a glitch on the server that creates the nightly builds, which
I just fixed. We should see tonight's (and following) builds appear in the
usual place[1].
Craig
[1] http://people.apache.org/builds/shale/nightly/
Thanks
BaTien
On Fri, 2007-01-19 at 14:47 -0800, Craig McClanahan wrote:
On 1/19/07, Reynolds, James [EMAIL PROTECTED] wrote:
I have a question about the org.apache.shale.view.ExceptionHandler
interface. Comments in the Shale Wiki indicate that Shale ...can
optionally do a RequestDispatcher.forward() call to the context
relative
path of an error display page... How do I invoke the option to
forward
to my error page?
I've created my ExceptionHandler class (code below) and configured it
successfully. I also configured this parameter in my web.xml:
context-param
param-nameorg.apache.shale.view.EXCEPTION_DISPATCH_PATH/param-name
param-value/exceptionViewer.jsf/param-value
/context-param
ExceptionHandler code:
public class WebEnabledExceptionHandler implements ExceptionHandler {
public WebEnabledExceptionHandler(){
}
public void handleException(Exception exception) {
System.out.println(Shale ExceptionHandler: +
exception.getMessage());
// How do I forward to the error page?
}
}
Thanks!
It's magic :-).
Actually, the act of declaring the forward path (as you are doing here)
enables the forwarding automatically. The code that actually does this
is
the afterPhaseExceptionCheck() method in ViewPhaseListener, which is
called
at the end of each phase. IF any exceptions have been queued up, AND
the
web.xml declares a forwarding path, THEN it will do the forwarding. You
do
not need to provide a custom ExceptionHandler to accomplish this.
Craig
E-Mail messages may contain viruses, worms, or other malicious code. By
reading the message and opening any attachments, the recipient accepts
full
responsibility for taking protective action against such code. Sender
is not
liable for any loss or damage arising from this message.
The information in this e-mail is confidential and may be legally
privileged. It is intended solely for the addressee(s). Access to this
e-mail by anyone else is unauthorized.
Re: [Shale view 1.0.4]
On 1/21/07, Adrian Gonzalez [EMAIL PROTECTED] wrote:
Hello,
I think there's a little bug on shale view 1.0.4.
Shale View : Bug on render response phase when removing view from request
map.
Error in org.apache.shale.view.faces.ViewPhaseListener, method
afterRenderResponse, lien 233 :
iterator obtained from map, code calling map.remove, and afterward using
iterator which generated ConcurrentModificationException.
Just change this order :
- remove FacesConstants.VIEWS_INITIALIZED from map.
- obtain iterator.
- use iterator.
I've just changed this piece of code in order to have :
private void afterRenderResponse(PhaseEvent event) {
/*AFTER CHANGE*/
// Initialize local values we will need
Map map = event.getFacesContext
().getExternalContext().getRequestMap();
List list = new ArrayList();
// Remove our list of initialized views explicitly
map.remove(FacesConstants.VIEWS_INITIALIZED);
Iterator entries = map.entrySet().iterator();
instead of :
/*BEFORE CHANGE
// Initialize local values we will need
Map map = event.getFacesContext
().getExternalContext().getRequestMap();
List list = new ArrayList();
Iterator entries = map.entrySet().iterator();
// Remove our list of initialized views explicitly
map.remove(FacesConstants.VIEWS_INITIALIZED);
And it's ok (or it seems).
Adrian,
Thanks very much for the thorough analysis ... it looks like you are on
target (although it likely depends on your VM's implementation of the
iterator methods so the problem may or may not manifest itself everywhere).
Could you do me a favor and file a bug in our issue tracking system[1] for
this? That way, the eventual fix will automatically be included in the
release notes for the next version.
Craig
[1] https://issues.apache.org/struts/browse/SHALE
Here's the stack trace I had :
[21/01/07 20:38:36:453 CET] 0043 helperI BEFORE
RENDER_RESPONSE(6)
[21/01/07 20:38:38:765 CET] 0043 HtmlTableRend E
org.apache.myfaces.shared_tomahawk.renderkit.html.HtmlTableRendererBaseencodeInnerHtml
Row is not available. Rowindex = 3
[21/01/07 20:38:38:921 CET] 0043 HtmlResponseW W
org.apache.myfaces.shared_impl.renderkit.html.HtmlResponseWriterImplendElement
HTML nesting warning on closing tbody: element tr rendered by
component : {Component-Path : [Class:
org.ajax4jsf.framework.ajax.AjaxViewRootRIOneOne,ViewId:
/userList.jsp][Class: javax.faces.component.html.HtmlForm,Id:
editUser][Class: org.apache.myfaces.component.html.ext.HtmlDataTable,Id:
userList]} not explicitly closed
[21/01/07 20:38:40:250 CET] 0043 PhaseListener E
org.apache.myfaces.lifecycle.PhaseListenerManagerinformPhaseListenersAfter
Exception in PhaseListener RENDER_RESPONSE(6)
afterPhase
java.util.ConcurrentModificationException
at java.util.HashMap$HashIterator.nextEntry(HashMap.java:942)
at java.util.HashMap$KeyIterator.next(HashMap.java:978)
at com.ibm.ws.webcontainer.srt.SRTServletRequest$1.nextElement(
SRTServletRequest.java:177)
at
org.apache.myfaces.context.servlet.AbstractAttributeMap$KeyIterator.next(
AbstractAttributeMap.java:210)
at
org.apache.myfaces.context.servlet.AbstractAttributeMap$EntryIterator.next
(AbstractAttributeMap.java:306)
at org.apache.shale.view.faces.ViewPhaseListener.afterRenderResponse(
ViewPhaseListener.java:233)
at org.apache.shale.view.faces.ViewPhaseListener.afterPhase(
ViewPhaseListener.java:106)
at
org.apache.myfaces.lifecycle.PhaseListenerManager.informPhaseListenersAfter
(PhaseListenerManager.java:89)
at org.apache.myfaces.lifecycle.LifecycleImpl.render(
LifecycleImpl.java:391)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:138)
at org.apache.myfaces.webapp.MyFacesServlet.service(
MyFacesServlet.java:74)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(
ServletWrapper.java:1282)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(
ServletWrapper.java:1239)
at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(
WebAppFilterChain.java:136)
at org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(
ExtensionsFilter.java:144)
at com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.doFilter(
FilterInstanceWrapper.java:142)
at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(
WebAppFilterChain.java:121)
at org.ajax4jsf.framework.ajax.xmlfilter.BaseXMLFilter.doXmlFilter(
BaseXMLFilter.java:67)
at org.ajax4jsf.framework.ajax.xmlfilter.BaseFilter.doFilter(
BaseFilter.java:223)
at com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.doFilter(
FilterInstanceWrapper.java:142)
at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(
WebAppFilterChain.java:121)
at org.firsttest.webapp.filter.MessageFilter.doFilter(
MessageFilter.java:45)
at com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.doFilter(
Re: h:messages and i18n
On 1/21/07, JS Portal Support [EMAIL PROTECTED] wrote:
Hi,
My backing beans set some info messages though calling the
.info(message).
The messages I set however are ResourceBundle id's. In my JSP's I then
want
to collect the id and present the message. I have:
h:messages layout=table globalOnly=true showDetail=false
showSummary=true rendered=#{! empty facesContext.maximumSeverity}/
Which now nicely displays my i18n id's.
Aren't they pretty? :-)
How can I alter it so that my proper
localized messages are shown?
All my i18n is setup and things like:
h:outputText value=#{labels['my.label.id']} /
Work as they should.
The simplest approach is to use the tried and true techniques of Java
internationalization, along these lines:
public class MyBackingBean extends AbstractViewController {
private static ResourceBundle bundle =
ResourceBundle.getBundle(com.mycompany.mypackage.MyBundle);
...
public String myAction() {
...
info(bundle.getString(my.message.key));
...
}
}
If the resource bundle name listed here is the same as the one you used in
your f:loadBundle tag, then you are easily able to leverage exactly the
same localized messages as you are using for the JSP page itself.
If you also need to do parameter replacement in the localized messages, you
should take a look at the org.apache.shale.util.Messages utility class in
the shale-core module.
Craig
Regards,
Joost Schouten
Re: JSF 1.1 vs. JSF 1.2
Hi,
1. EL unification. Since I'm not using JSPs, this isn't a big deal
Well, it's not entirely gone :-) You still do EL with Facelets. It's
true
that Facelets allows you to use the unified EL out of the box. But I've
noticed that in some instances using Tomahawk tags I still have to use
the
#{...} syntax. The net result is that our code is sprinkled with
mostly
${...} and a few #{...} and I have to try to explain to new devs when
and why they have to use one or the other.
Sorry, you confuse me. Is there any difference between #{...} and ${...}?
Could you explain when and why to use one or the other.
Does it depend on fact that in some classes of tomahawk use a hard
coded '#{' el prefix?
Regards
Ingo
Re: Shale ExceptionHandling
Hello Craig:
I am trying to look at shale-apps/shale-test-view to see an example of
ViewController exception handling. I download from svn and try to build
it from mvn but get the following exception:
The plugin 'org.codehaus.mojo:cobertura-maven-plugin' does not exist or
no valid version could be found
I then try to get the latest nightly build, but they all disappeared.
Where are they located now?
Thanks
BaTien
On Fri, 2007-01-19 at 14:47 -0800, Craig McClanahan wrote:
On 1/19/07, Reynolds, James [EMAIL PROTECTED] wrote:
I have a question about the org.apache.shale.view.ExceptionHandler
interface. Comments in the Shale Wiki indicate that Shale ...can
optionally do a RequestDispatcher.forward() call to the context relative
path of an error display page... How do I invoke the option to forward
to my error page?
I've created my ExceptionHandler class (code below) and configured it
successfully. I also configured this parameter in my web.xml:
context-param
param-nameorg.apache.shale.view.EXCEPTION_DISPATCH_PATH/param-name
param-value/exceptionViewer.jsf/param-value
/context-param
ExceptionHandler code:
public class WebEnabledExceptionHandler implements ExceptionHandler {
public WebEnabledExceptionHandler(){
}
public void handleException(Exception exception) {
System.out.println(Shale ExceptionHandler: +
exception.getMessage());
// How do I forward to the error page?
}
}
Thanks!
It's magic :-).
Actually, the act of declaring the forward path (as you are doing here)
enables the forwarding automatically. The code that actually does this is
the afterPhaseExceptionCheck() method in ViewPhaseListener, which is called
at the end of each phase. IF any exceptions have been queued up, AND the
web.xml declares a forwarding path, THEN it will do the forwarding. You do
not need to provide a custom ExceptionHandler to accomplish this.
Craig
E-Mail messages may contain viruses, worms, or other malicious code. By
reading the message and opening any attachments, the recipient accepts full
responsibility for taking protective action against such code. Sender is not
liable for any loss or damage arising from this message.
The information in this e-mail is confidential and may be legally
privileged. It is intended solely for the addressee(s). Access to this
e-mail by anyone else is unauthorized.
Re: Shale ExceptionHandling
On 1/20/07, Duong BaTien [EMAIL PROTECTED] wrote:
Hello Craig:
I am trying to look at shale-apps/shale-test-view to see an example of
ViewController exception handling. I download from svn and try to build
it from mvn but get the following exception:
The plugin 'org.codehaus.mojo:cobertura-maven-plugin' does not exist or
no valid version could be found
I then try to get the latest nightly build, but they all disappeared.
Where are they located now?
There has been a glitch on the server that creates the nightly builds, which
I just fixed. We should see tonight's (and following) builds appear in the
usual place[1].
Craig
[1] http://people.apache.org/builds/shale/nightly/
Thanks
BaTien
On Fri, 2007-01-19 at 14:47 -0800, Craig McClanahan wrote:
On 1/19/07, Reynolds, James [EMAIL PROTECTED] wrote:
I have a question about the org.apache.shale.view.ExceptionHandler
interface. Comments in the Shale Wiki indicate that Shale ...can
optionally do a RequestDispatcher.forward() call to the context
relative
path of an error display page... How do I invoke the option to
forward
to my error page?
I've created my ExceptionHandler class (code below) and configured it
successfully. I also configured this parameter in my web.xml:
context-param
param-nameorg.apache.shale.view.EXCEPTION_DISPATCH_PATH/param-name
param-value/exceptionViewer.jsf/param-value
/context-param
ExceptionHandler code:
public class WebEnabledExceptionHandler implements ExceptionHandler {
public WebEnabledExceptionHandler(){
}
public void handleException(Exception exception) {
System.out.println(Shale ExceptionHandler: +
exception.getMessage());
// How do I forward to the error page?
}
}
Thanks!
It's magic :-).
Actually, the act of declaring the forward path (as you are doing here)
enables the forwarding automatically. The code that actually does this
is
the afterPhaseExceptionCheck() method in ViewPhaseListener, which is
called
at the end of each phase. IF any exceptions have been queued up, AND
the
web.xml declares a forwarding path, THEN it will do the forwarding. You
do
not need to provide a custom ExceptionHandler to accomplish this.
Craig
E-Mail messages may contain viruses, worms, or other malicious code. By
reading the message and opening any attachments, the recipient accepts
full
responsibility for taking protective action against such code. Sender
is not
liable for any loss or damage arising from this message.
The information in this e-mail is confidential and may be legally
privileged. It is intended solely for the addressee(s). Access to this
e-mail by anyone else is unauthorized.
Re: [JSF] How to control scheme with commandLink/Button tags?
From: Cyril Bouteille [EMAIL PROTECTED] Hi, I've a problem using JSF/Shale on Sun AS 9.0.1 when deployed behind an SSL accelerator in production. Because secure requests get to the app server unencrypted, I am unable to use regular declarative security user-data-constraint/transport-guarantee/CONFIDENTIAL in web.xml, or it gets in an infinite loop redirecting to https... Anyway, so in the meantime, I'd just like to control the schemes on my links and action post, but JSF doesn't seem to support it! s don't seem to allow you to change scheme. If you put a full URL in the action, it fails to find the full URL w/ scheme in the faces-config.xml... Is this a Glassfish bug or a JSF oversight? Or am I missing some other way to programmatically control the scheme of a JSF command? I'd appreciate any workaround idea the community would be willing to share. :) What part of shale are you using (view controller, dialog manager, remoting). Are you using one of the shale example applications? What does your naviation rule look like in the faces-config.xml acting for the commandLink/Button. Thank you, Gary
Re: [JSF] How to control scheme with commandLink/Button tags?
On 1/19/07, Cyril Bouteille [EMAIL PROTECTED] wrote: Hi, I've a problem using JSF/Shale on Sun AS 9.0.1 when deployed behind an SSL accelerator in production. Because secure requests get to the app server unencrypted, I am unable to use regular declarative security user-data-constraint/transport-guarantee/CONFIDENTIAL in web.xml, or it gets in an infinite loop redirecting to https... If your accellerator sends the request in on the http port, that is definitely not going to work ... but why do you need a security constraint to enforce this? It seems like something you could do with firewall rules. Anyway, so in the meantime, I'd just like to control the schemes on my links and action post, but JSF doesn't seem to support it! commandLink/Buttons don't seem to allow you to change scheme. If you put a full URL in the action, it fails to find the full URL w/ scheme in the faces-config.xml... Is this a Glassfish bug or a JSF oversight? When you submit a form, JSF is using HTTP POST requests back to the URL of the original page URL, which means you cannot change modes. You'll need to do a redirect to an appropriate URL to do that. Or am I missing some other way to programmatically control the scheme of a JSF command? I'd appreciate any workaround idea the community would be willing to share. :) Thank you, Craig
Re: Shale ExceptionHandling
On 1/19/07, Reynolds, James [EMAIL PROTECTED] wrote:
I have a question about the org.apache.shale.view.ExceptionHandler
interface. Comments in the Shale Wiki indicate that Shale ...can
optionally do a RequestDispatcher.forward() call to the context relative
path of an error display page... How do I invoke the option to forward
to my error page?
I've created my ExceptionHandler class (code below) and configured it
successfully. I also configured this parameter in my web.xml:
context-param
param-nameorg.apache.shale.view.EXCEPTION_DISPATCH_PATH/param-name
param-value/exceptionViewer.jsf/param-value
/context-param
ExceptionHandler code:
public class WebEnabledExceptionHandler implements ExceptionHandler {
public WebEnabledExceptionHandler(){
}
public void handleException(Exception exception) {
System.out.println(Shale ExceptionHandler: +
exception.getMessage());
// How do I forward to the error page?
}
}
Thanks!
It's magic :-).
Actually, the act of declaring the forward path (as you are doing here)
enables the forwarding automatically. The code that actually does this is
the afterPhaseExceptionCheck() method in ViewPhaseListener, which is called
at the end of each phase. IF any exceptions have been queued up, AND the
web.xml declares a forwarding path, THEN it will do the forwarding. You do
not need to provide a custom ExceptionHandler to accomplish this.
Craig
E-Mail messages may contain viruses, worms, or other malicious code. By
reading the message and opening any attachments, the recipient accepts full
responsibility for taking protective action against such code. Sender is not
liable for any loss or damage arising from this message.
The information in this e-mail is confidential and may be legally
privileged. It is intended solely for the addressee(s). Access to this
e-mail by anyone else is unauthorized.
Re: [JSF] How to control scheme with commandLink/Button tags?
From: Cyril Bouteille [EMAIL PROTECTED] Hi Craig, My understanding is that declarative web.xml security rules is the official way to control the protocol scheme with JSF (since I'm unable to specify it w/ JSF tags). Sprinkling redirects all over our code and pages to correct the protocol scheme is rather ugly... I wish there was just a way to specify the POST scheme with JSF commandLink/Button tags. As a wrapper around Servlet API, I'd expect to have at least access to the same functionality. Is this a JSF architecture decision resulting from technical difficulties allowing the scheme to switch on the command submission? The h:form component renderer calls the view handler to create the action URL. There are a couple extension points here. You could plug in your own ViewHandler and override the get ActionURL [1] method or you could create your own form renderer [2]. [1] http://svn.apache.org/viewvc/myfaces/core/trunk/impl/src/main/java/org/apache/myfaces/application/jsp/JspViewHandlerImpl.java?view=markup [2]http://svn.apache.org/viewvc/myfaces/shared/trunk/core/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlFormRendererBase.java?view=markup Craig McClanahan wrote: On 1/19/07, Cyril Bouteille wrote: Hi, I've a problem using JSF/Shale on Sun AS 9.0.1 when deployed behind an SSL accelerator in production. Because secure requests get to the app server unencrypted, I am unable to use regular declarative security user-data-constraint/transport-guarantee/CONFIDENTIAL in web.xml, or it gets in an infinite loop redirecting to https... If your accellerator sends the request in on the http port, that is definitely not going to work ... but why do you need a security constraint to enforce this? It seems like something you could do with firewall rules. Anyway, so in the meantime, I'd just like to control the schemes on my links and action post, but JSF doesn't seem to support it! s don't seem to allow you to change scheme. If you put a full URL in the action, it fails to find the full URL w/ scheme in the faces-config.xml... Is this a Glassfish bug or a JSF oversight? When you submit a form, JSF is using HTTP POST requests back to the URL of the original page URL, which means you cannot change modes. You'll need to do a redirect to an appropriate URL to do that. Or am I missing some other way to programmatically control the scheme of a JSF command? I'd appreciate any workaround idea the community would be willing to share. :) Thank you, Craig
Re: [JSF] How to control scheme with commandLink/Button tags?
On 1/19/07, Cyril Bouteille [EMAIL PROTECTED] wrote: Hi Craig, My understanding is that declarative web.xml security rules is the official way to control the protocol scheme with JSF (since I'm unable to specify it w/ JSF tags). That's true ... but you are violating the assumptions of the way that these constraints were originally designed when you send a secure request to the insecure port :-). Sprinkling redirects all over our code and pages to correct the protocol scheme is rather ugly... I wish there was just a way to specify the POST scheme with JSF commandLink/Button tags. As a wrapper around Servlet API, I'd expect to have at least access to the same functionality. Is this a JSF architecture decision resulting from technical difficulties allowing the scheme to switch on the command submission? It's actually just a use case we didn't consider at all. It would be good to provide feedback to the JSF spec folks that this is an important issue to address in a future JSF spec version. There are feedback links at the public java.net project for the spec https://javaserverfaces-spec-public.dev.java.net. Craig Craig McClanahan wrote: On 1/19/07, Cyril Bouteille [EMAIL PROTECTED] wrote: Hi, I've a problem using JSF/Shale on Sun AS 9.0.1 when deployed behind an SSL accelerator in production. Because secure requests get to the app server unencrypted, I am unable to use regular declarative security user-data-constraint/transport-guarantee/CONFIDENTIAL in web.xml, or it gets in an infinite loop redirecting to https... If your accellerator sends the request in on the http port, that is definitely not going to work ... but why do you need a security constraint to enforce this? It seems like something you could do with firewall rules. Anyway, so in the meantime, I'd just like to control the schemes on my links and action post, but JSF doesn't seem to support it! commandLink/Buttons don't seem to allow you to change scheme. If you put a full URL in the action, it fails to find the full URL w/ scheme in the faces-config.xml... Is this a Glassfish bug or a JSF oversight? When you submit a form, JSF is using HTTP POST requests back to the URL of the original page URL, which means you cannot change modes. You'll need to do a redirect to an appropriate URL to do that. Or am I missing some other way to programmatically control the scheme of a JSF command? I'd appreciate any workaround idea the community would be willing to share. :) Thank you, Craig
Re: Shale ExceptionHandling
From: Reynolds, James [EMAIL PROTECTED]
I have a question about the org.apache.shale.view.ExceptionHandler
interface. Comments in the Shale Wiki indicate that Shale ...can
optionally do a RequestDispatcher.forward() call to the context relative
path of an error display page... How do I invoke the option to forward
to my error page?
I've created my ExceptionHandler class (code below) and configured it
successfully. I also configured this parameter in my web.xml:
org.apache.shale.view.EXCEPTION_DISPATCH_PATH
/exceptionViewer.jsf
ExceptionHandler code:
public class WebEnabledExceptionHandler implements ExceptionHandler {
public WebEnabledExceptionHandler(){
}
public void handleException(Exception exception) {
System.out.println(Shale ExceptionHandler: +
exception.getMessage());
// How do I forward to the error page?
}
}
The shale-test-view application has an example of the ViewController exception
handling. You need to add the error page to the web.xml [1] and then define an
error page [2].
[1]
https://svn.apache.org/repos/asf/shale/framework/trunk/shale-apps/shale-test-view/src/main/webapp/WEB-INF/web.xml
[2]
https://svn.apache.org/repos/asf/shale/framework/trunk/shale-apps/shale-test-view/src/main/webapp/WEB-INF/web.xml
Gary
Thanks!
E-Mail messages may contain viruses, worms, or other malicious code. By
reading
the message and opening any attachments, the recipient accepts full
responsibility for taking protective action against such code. Sender is not
liable for any loss or damage arising from this message.
The information in this e-mail is confidential and may be legally privileged.
It
is intended solely for the addressee(s). Access to this e-mail by anyone else
is
unauthorized.
Re: Startup Error
From: Craig McClanahan [EMAIL PROTECTED] On 1/18/07, Greg Reddin wrote: On 1/18/07, Gary VanMatre wrote: I had not realized that facelets was a subproject of JSF 1.2 . Humm interesting... That is interesting. I guess it's just a subproject of the java.netproject. It's not actually part of the spec is it? No, it's not. Subproject in the context of this page is talking about the project hierarchy at java.net. Ahh, good marketing strategy, none the less. Greg Craig Gary
Re: JSF 1.1 vs. JSF 1.2
On 1/18/07, Reynolds, James [EMAIL PROTECTED] wrote:
2. JSF 1.1, Facelets Shale
This is the platform we are currently developing on. It's very close to
working with JSF 1.2 from what I can tell (though I have not actually used
1.2 yet).
1. EL unification. Since I'm not using JSPs, this isn't a big deal
Well, it's not entirely gone :-) You still do EL with Facelets. It's true
that Facelets allows you to use the unified EL out of the box. But I've
noticed that in some instances using Tomahawk tags I still have to use the
#{...} syntax. The net result is that our code is sprinkled with mostly
${...} and a few #{...} and I have to try to explain to new devs when
and why they have to use one or the other.
Overall, I'm pretty happy with where we are.
Greg
Re: JSF 1.1 vs. JSF 1.2
On 1/18/07, Reynolds, James [EMAIL PROTECTED] wrote: I think I get it now (thanks to help from this list). If I want to use JSF 1.2 with Shale, I must use a J2EE 5 servlet container. However, I may not be able to convince my company to switch from Tomcat 5.5.* If you want to run JSF 1.2 on Tomcat, you really want 6.0 not 5.5. It might be technically feasible to hack together a JSF 1.2 implementation that would execute on Tomcat 5.5, but it's hard to see how you could have a completely spec compliant implementation in the absence of JSP 2.1 (which is part of Tomcat 6; Tomcat 5 and 5.5 provide JSP 2.0). If that is the case, I need to decide between the following two setups: 1. JSF 1.2 Facelets or 2. JSF 1.1, Facelets Shale Practically speaking, the main improvements in JSF 1.2 may not offer too much to me since I'm using Facelets. Specifically: Just curious ... is this based on a belief that JSF 1.2 + Facelets + Shale does not work (if it doesn't that is a bug that needs to be fixed), or that Shale does not provide you anything extra if you have JSF 1.2? I confess that I don't recall any details of which Shale features you are looking at from your previous comments ... but there is quite a lot of different things available. 1. EL unification. Since I'm not using JSPs, this isn't a big deal 2. Improved Messages. From what I've read, Shale's info/warn/error methods provide much of the same improvements to 1.1 as there is out of the box in 1.2. Finally, I'll need to consider bug fixes, like the multiple button press issue. In your experience, is developing JSF 1.2 far superior to JSF 1.1? Are there any major tradeoffs that I'm overlooking? Thanks for your time and any advice. Craig
RE: JSF 1.1 vs. JSF 1.2
If you want to run JSF 1.2 on Tomcat, you really want 6.0 not 5.5. It might be technically feasible to hack together a JSF 1.2 implementation that would execute on Tomcat 5.5, but it's hard to see how you could have a completely spec compliant implementation in the absence of JSP 2.1 (which is part of Tomcat 6; Tomcat 5 and 5.5 provide JSP 2.0). You're right, *I* really want Tomcat 6, but my employers are leery of its beta status. They are also concerned about supporting an additional container. Just curious ... is this based on a belief that JSF 1.2 + Facelets + Shale does not work (if it doesn't that is a bug that needs to be fixed), or that Shale does not provide you anything extra if you have JSF 1.2? I confess that I don't recall any details of which Shale features you are looking at from your previous comments ... but there is quite a lot of different things available. I didn't explain myself clearly, I'd prefer to use Shale in either case. My problem is that I may be stuck in Tomcat 5.5.17, which (for me) would necessitate using JSF 1.1. I need to decide if yesterday's setup is good enough, or if it's worth pushing my employers really hard to add a Tomcat 6 setup (and risk being thrown out on my rear). E-Mail messages may contain viruses, worms, or other malicious code. By reading the message and opening any attachments, the recipient accepts full responsibility for taking protective action against such code. Sender is not liable for any loss or damage arising from this message. The information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee(s). Access to this e-mail by anyone else is unauthorized.
RE: JSF 1.1 vs. JSF 1.2
From: Kito D. Mann [EMAIL PROTECTED] I didn't explain myself clearly, I'd prefer to use Shale in either case. My problem is that I may be stuck in Tomcat 5.5.17, which (for me) would necessitate using JSF 1.1. I need to decide if yesterday's setup is good enough, or if it's worth pushing my employers really hard to add a Tomcat 6 setup (and risk being thrown out on my rear). Don't forget that you can use JSF 1.2 with Facelets and Tomcat 5.x. And you can use Facelets with Shale, too. That's awesome that Facelets works with Shale too. Looks like there's about a dozen articles and at least a couple Virtua courses. All there at JSFCentral. ~~~ Kito D. Mann ([EMAIL PROTECTED]) Author, JavaServer Faces in Action http://www.virtua.com - JSF/Java EE consulting, training, and mentoring http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info
Re: EL question
On 1/16/07, JS Portal Support [EMAIL PROTECTED] wrote:
Hi,
Maybe an ignorant (and more a simple JSP) question, but I can't seem to
figure out how to make an EL call that does:
org.apache.lucene.document.Document.get(String nameOfField)
I have my Hits (wrapped in a custom HitsToListWrapper) nicely accessible
for
each row of my dataTable (#{hit.document.butWhatHere}), but am struggling
with just this last seemingly simple step.
The EL used by JSP and JSF does not include support for arbitrary method
calls with parameters. It can only call JavaBeans property getters (and
setters, in the case of JSF expressions). You'll need to point your
expression at something that looks like getFoo().
The other thing to note is that a data table already knows how to iterate
over a List or array, so just pointing at one of those directly is the
easiest approach.
Thanks,
Joost
Craig
RE: Getting started...again.
That sounds great! Thanks for doing this and letting me know.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Matthias Wessendorf
Sent: Tuesday, January 16, 2007 9:23 AM
To: user@shale.apache.org
Subject: Re: Getting started...again.
James-
I am creating a sorta kickstart project, using technologies like
Apache MyFaces
Facelets
Apache Trinidad (formal Oracle ADF Faces)
Shale (View and application.manager (test will follow soon))
JPA
Toplink Essentials
as the container I am using jetty.
check here:
http://code.google.com/p/facesgoodies/
-M
On 1/15/07, Craig McClanahan [EMAIL PROTECTED] wrote:
On 1/15/07, Reynolds, James [EMAIL PROTECTED] wrote:
Steps 0 1 are complete :)
I'm much closer as I can see Tomcat behaving as I'd expect, though I
did
end up with a couple errors in the log:
1. java.lang.NoClassDefFoundError: javax/el/ExpressionFactory
This is supposed to be pulled in by the dependencies for MyFaces
(commons-el?) if you're using JSF 1.1. It'll be part of the server
if
you're using JSF 1.2 (the RI, since MyFaces doesn't support this yet).
2. org.apache.commons.chain.web.ChainListener
Make sure commons chain is not *also* in your Tomcat shared or common
dirs.
Commons-chain is definitely in my project, but I can't locate
javax/el/ExpressionFactory in my jsf libs. Should this be in my
server
or J2EE libs? I'm attempting to use Tomcat 5.5.20
Does the prebuilt war in the 1.0.4 test builds work out of the box?
If so,
it'd be interesting to do a detailed comparison of JARs in yours
versus that
one. If not, we've got something else weird, because the
out-of-the-box one
runs for me.
Craig
On 1/15/07, Reynolds, James [EMAIL PROTECTED] wrote:
I've been on a hiatus from Shale since changing jobs last year;
however,
my new company is considering it based on my gushing
recommendation.
Embarrassingly enough, I can't fire up the shale-blank
application.
When I run the app, I see the output below in the console then -
nothing. No errors in tomcat or anything (that I can see). This
output
has changed since I last ran Shale. Do you see anything that
might
explain the silent failure?
I've never tried it with the Shale libraries or facelets installed
in
Tomcat's common/lib directory ... FIrst thing I would try is a
completely
vanilla Tomcat install, with the Shale jars deployed inside the
webapp
(as
they should default when shale-blank builds).
Actually, the zeroth thing I would try is the 1.0.4 release instead
of
1.0.3:-). Rahul is in the process of getting it out there; his test
build is
available at http://people.apache.org/~rahul/shale/v104/.
Craig
Thanks!
cmd /c C:\apache-tomcat-5.5.20\bin\catalina.bat run
Using CATALINA_BASE: C:\Documents and
Settings\jReynolds\.IntelliJIdea60\system\tomcat_Unnamed_5094815
Using CATALINA_HOME: C:\apache-tomcat-5.5.20
Using CATALINA_TMPDIR: C:\apache-tomcat-5.5.20\temp
Using JRE_HOME:C:\Java\jdk1.5.0_09
log4j:WARN No appenders could be found for logger
(org.apache.catalina.startup.Embedded).
log4j:WARN Please initialize the log4j system properly.
ContextListener:
attributeAdded('org$apache$shale$view$VIEW_CALLBACKS',
'[EMAIL PROTECTED]')
ContextListener:
attributeAdded('org.apache.shale.tiger.FACES_CONFIG_CONFIG',
'[EMAIL PROTECTED]')
ContextListener:
attributeAdded('org.apache.myfaces.config.RuntimeConfig',
'[EMAIL PROTECTED]')
ContextListener:
attributeAdded('org.apache.myfaces.webapp.webxml.WebXml',
'[EMAIL PROTECTED]')
ContextListener:
attributeAdded('org.apache.myfaces.webapp.StartupServletContextListener.
FACES_INIT_DONE', 'true')
ContextListener:
attributeAdded('org$apache$shale$view$VIEW_CALLBACKS',
'[EMAIL PROTECTED]')
ContextListener:
attributeAdded('org.apache.shale.tiger.FACES_CONFIG_CONFIG',
'[EMAIL PROTECTED]')
ContextListener:
attributeAdded('org.apache.myfaces.config.RuntimeConfig',
'[EMAIL PROTECTED]')
ContextListener:
attributeAdded('org.apache.myfaces.webapp.webxml.WebXml',
'[EMAIL PROTECTED]')
ContextListener:
attributeAdded('org.apache.myfaces.webapp.StartupServletContextListener.
FACES_INIT_DONE', 'true')
ContextListener:
attributeRemoved('org.apache.shale.tiger.FACES_CONFIG_CONFIG',
'[EMAIL PROTECTED]')
ContextListener:
attributeRemoved('org.apache.catalina.jsp_classpath',
'/C:/apache-tomcat-5.5.20/webapps/servlets-examples/WEB-INF/classes/;/C:
/apache-tomcat-5.5.20/common/classes/;/C:/apache-tomcat-5.5.20/common/i1
8n/tomcat-i18n-en.jar;/C:/apache-tomcat-5.5.20/common/i18n/tomcat-i18n-e
s.jar;/C:/apache-tomcat-5.5.20/common/i18n/tomcat-i18n-fr.jar;/C:/apache
-tomcat-5.5.20/common/i18n/tomcat-i18n-ja.jar;/C:/apache-tomcat-5.5.20/c
ommon/lib/commons-beanutils-1.7.0.jar;/C:/apache-tomcat-5.5.20/common/li
b/commons
Re: Getting started...again.
you need to build trinidad components yourself, since
we currently working on getting a release out...
On 1/16/07, Reynolds, James [EMAIL PROTECTED] wrote:
That sounds great! Thanks for doing this and letting me know.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Matthias Wessendorf
Sent: Tuesday, January 16, 2007 9:23 AM
To: user@shale.apache.org
Subject: Re: Getting started...again.
James-
I am creating a sorta kickstart project, using technologies like
Apache MyFaces
Facelets
Apache Trinidad (formal Oracle ADF Faces)
Shale (View and application.manager (test will follow soon))
JPA
Toplink Essentials
as the container I am using jetty.
check here:
http://code.google.com/p/facesgoodies/
-M
On 1/15/07, Craig McClanahan [EMAIL PROTECTED] wrote:
On 1/15/07, Reynolds, James [EMAIL PROTECTED] wrote:
Steps 0 1 are complete :)
I'm much closer as I can see Tomcat behaving as I'd expect, though I
did
end up with a couple errors in the log:
1. java.lang.NoClassDefFoundError: javax/el/ExpressionFactory
This is supposed to be pulled in by the dependencies for MyFaces
(commons-el?) if you're using JSF 1.1. It'll be part of the server
if
you're using JSF 1.2 (the RI, since MyFaces doesn't support this yet).
2. org.apache.commons.chain.web.ChainListener
Make sure commons chain is not *also* in your Tomcat shared or common
dirs.
Commons-chain is definitely in my project, but I can't locate
javax/el/ExpressionFactory in my jsf libs. Should this be in my
server
or J2EE libs? I'm attempting to use Tomcat 5.5.20
Does the prebuilt war in the 1.0.4 test builds work out of the box?
If so,
it'd be interesting to do a detailed comparison of JARs in yours
versus that
one. If not, we've got something else weird, because the
out-of-the-box one
runs for me.
Craig
On 1/15/07, Reynolds, James [EMAIL PROTECTED] wrote:
I've been on a hiatus from Shale since changing jobs last year;
however,
my new company is considering it based on my gushing
recommendation.
Embarrassingly enough, I can't fire up the shale-blank
application.
When I run the app, I see the output below in the console then -
nothing. No errors in tomcat or anything (that I can see). This
output
has changed since I last ran Shale. Do you see anything that
might
explain the silent failure?
I've never tried it with the Shale libraries or facelets installed
in
Tomcat's common/lib directory ... FIrst thing I would try is a
completely
vanilla Tomcat install, with the Shale jars deployed inside the
webapp
(as
they should default when shale-blank builds).
Actually, the zeroth thing I would try is the 1.0.4 release instead
of
1.0.3:-). Rahul is in the process of getting it out there; his test
build is
available at http://people.apache.org/~rahul/shale/v104/.
Craig
Thanks!
cmd /c C:\apache-tomcat-5.5.20\bin\catalina.bat run
Using CATALINA_BASE: C:\Documents and
Settings\jReynolds\.IntelliJIdea60\system\tomcat_Unnamed_5094815
Using CATALINA_HOME: C:\apache-tomcat-5.5.20
Using CATALINA_TMPDIR: C:\apache-tomcat-5.5.20\temp
Using JRE_HOME:C:\Java\jdk1.5.0_09
log4j:WARN No appenders could be found for logger
(org.apache.catalina.startup.Embedded).
log4j:WARN Please initialize the log4j system properly.
ContextListener:
attributeAdded('org$apache$shale$view$VIEW_CALLBACKS',
'[EMAIL PROTECTED]')
ContextListener:
attributeAdded('org.apache.shale.tiger.FACES_CONFIG_CONFIG',
'[EMAIL PROTECTED]')
ContextListener:
attributeAdded('org.apache.myfaces.config.RuntimeConfig',
'[EMAIL PROTECTED]')
ContextListener:
attributeAdded('org.apache.myfaces.webapp.webxml.WebXml',
'[EMAIL PROTECTED]')
ContextListener:
attributeAdded('org.apache.myfaces.webapp.StartupServletContextListener.
FACES_INIT_DONE', 'true')
ContextListener:
attributeAdded('org$apache$shale$view$VIEW_CALLBACKS',
'[EMAIL PROTECTED]')
ContextListener:
attributeAdded('org.apache.shale.tiger.FACES_CONFIG_CONFIG',
'[EMAIL PROTECTED]')
ContextListener:
attributeAdded('org.apache.myfaces.config.RuntimeConfig',
'[EMAIL PROTECTED]')
ContextListener:
attributeAdded('org.apache.myfaces.webapp.webxml.WebXml',
'[EMAIL PROTECTED]')
ContextListener:
attributeAdded('org.apache.myfaces.webapp.StartupServletContextListener.
FACES_INIT_DONE', 'true')
ContextListener:
attributeRemoved('org.apache.shale.tiger.FACES_CONFIG_CONFIG',
'[EMAIL PROTECTED]')
ContextListener:
attributeRemoved('org.apache.catalina.jsp_classpath',
'/C:/apache-tomcat-5.5.20/webapps/servlets-examples/WEB-INF/classes/;/C:
/apache-tomcat-5.5.20/common/classes/;/C:/apache-tomcat-5.5.20/common/i1
8n/tomcat-i18n-en.jar;/C:/apache-tomcat-5.5.20/common/i18n/tomcat-i18n-e
s.jar;/C:/apache-tomcat-5.5.20/common/i18n/tomcat-i18n-fr.jar;/C:/apache
-tomcat
RE: Getting started...again.
Oh, thank you! I'll drop my Tomcat version and go again.
:)
-Original Message-
From: Hermod Opstvedt [mailto:[EMAIL PROTECTED]
Sent: Tuesday, January 16, 2007 11:01 AM
To: user@shale.apache.org
Subject: SV: Getting started...again.
Hi
Just don't attempt to use Shale with 5.5.20 and jdk5. It works with any
version below 5.5.20 and jdk5. If your stuck to 5.5.20 you need to be
running jdk1.4
Hermod
-Opprinnelig melding-
Fra: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] På vegne av
Matthias Wessendorf
Sendt: 16. januar 2007 17:23
Til: user@shale.apache.org
Emne: Re: Getting started...again.
James-
I am creating a sorta kickstart project, using technologies like
Apache MyFaces
Facelets
Apache Trinidad (formal Oracle ADF Faces)
Shale (View and application.manager (test will follow soon))
JPA
Toplink Essentials
as the container I am using jetty.
check here:
http://code.google.com/p/facesgoodies/
-M
On 1/15/07, Craig McClanahan [EMAIL PROTECTED] wrote:
On 1/15/07, Reynolds, James [EMAIL PROTECTED] wrote:
Steps 0 1 are complete :)
I'm much closer as I can see Tomcat behaving as I'd expect, though I did
end up with a couple errors in the log:
1. java.lang.NoClassDefFoundError: javax/el/ExpressionFactory
This is supposed to be pulled in by the dependencies for MyFaces
(commons-el?) if you're using JSF 1.1. It'll be part of the server if
you're using JSF 1.2 (the RI, since MyFaces doesn't support this yet).
2. org.apache.commons.chain.web.ChainListener
Make sure commons chain is not *also* in your Tomcat shared or common
dirs.
Commons-chain is definitely in my project, but I can't locate
javax/el/ExpressionFactory in my jsf libs. Should this be in my server
or J2EE libs? I'm attempting to use Tomcat 5.5.20
Does the prebuilt war in the 1.0.4 test builds work out of the box? If
so,
it'd be interesting to do a detailed comparison of JARs in yours versus
that
one. If not, we've got something else weird, because the out-of-the-box
one
runs for me.
Craig
On 1/15/07, Reynolds, James [EMAIL PROTECTED] wrote:
I've been on a hiatus from Shale since changing jobs last year;
however,
my new company is considering it based on my gushing recommendation.
Embarrassingly enough, I can't fire up the shale-blank application.
When I run the app, I see the output below in the console then -
nothing. No errors in tomcat or anything (that I can see). This
output
has changed since I last ran Shale. Do you see anything that might
explain the silent failure?
I've never tried it with the Shale libraries or facelets installed in
Tomcat's common/lib directory ... FIrst thing I would try is a
completely
vanilla Tomcat install, with the Shale jars deployed inside the webapp
(as
they should default when shale-blank builds).
Actually, the zeroth thing I would try is the 1.0.4 release instead of
1.0.3:-). Rahul is in the process of getting it out there; his test
build is
available at http://people.apache.org/~rahul/shale/v104/.
Craig
Thanks!
cmd /c C:\apache-tomcat-5.5.20\bin\catalina.bat run
Using CATALINA_BASE: C:\Documents and
Settings\jReynolds\.IntelliJIdea60\system\tomcat_Unnamed_5094815
Using CATALINA_HOME: C:\apache-tomcat-5.5.20
Using CATALINA_TMPDIR: C:\apache-tomcat-5.5.20\temp
Using JRE_HOME:C:\Java\jdk1.5.0_09
log4j:WARN No appenders could be found for logger
(org.apache.catalina.startup.Embedded).
log4j:WARN Please initialize the log4j system properly.
ContextListener:
attributeAdded('org$apache$shale$view$VIEW_CALLBACKS',
'[EMAIL PROTECTED]')
ContextListener:
attributeAdded('org.apache.shale.tiger.FACES_CONFIG_CONFIG',
'[EMAIL PROTECTED]')
ContextListener:
attributeAdded('org.apache.myfaces.config.RuntimeConfig',
'[EMAIL PROTECTED]')
ContextListener:
attributeAdded('org.apache.myfaces.webapp.webxml.WebXml',
'[EMAIL PROTECTED]')
ContextListener:
attributeAdded('org.apache.myfaces.webapp.StartupServletContextListener.
FACES_INIT_DONE', 'true')
ContextListener:
attributeAdded('org$apache$shale$view$VIEW_CALLBACKS',
'[EMAIL PROTECTED]')
ContextListener:
attributeAdded('org.apache.shale.tiger.FACES_CONFIG_CONFIG',
'[EMAIL PROTECTED]')
ContextListener:
attributeAdded('org.apache.myfaces.config.RuntimeConfig',
'[EMAIL PROTECTED]')
ContextListener:
attributeAdded('org.apache.myfaces.webapp.webxml.WebXml',
'[EMAIL PROTECTED]')
ContextListener:
attributeAdded('org.apache.myfaces.webapp.StartupServletContextListener.
FACES_INIT_DONE', 'true')
ContextListener:
attributeRemoved('org.apache.shale.tiger.FACES_CONFIG_CONFIG',
'[EMAIL PROTECTED]')
ContextListener: attributeRemoved('org.apache.catalina.jsp_classpath',
'/C:/apache-tomcat-5.5.20/webapps/servlets-examples/WEB-INF/classes/;/C:
/apache-tomcat-5.5.20/common/classes/;/C:/apache-tomcat-5.5.20
RE: Getting started...again.
I've been setting it up from scratch, since (oh the shame) I haven't used Maven
yet. This is yet another reason why I'd better hop on the bandwagon and set it
up. I'll check out that project too.
Thanks so much!
-Original Message-
From: Hermod Opstvedt [mailto:[EMAIL PROTECTED]
Sent: Tuesday, January 16, 2007 12:46 PM
To: user@shale.apache.org
Subject: SV: Getting started...again.
Hi
How are you creating it? As a complete Maven2 project, or as Maven2
archetype?
Reason for asking, is that I recently submitted Shale/Clay kickstart project
(The first of more to come with other faces libs included). Take a look in
the shale sandbox under maven
Hermod
-Opprinnelig melding-
Fra: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] På vegne av
Matthias Wessendorf
Sendt: 16. januar 2007 17:23
Til: user@shale.apache.org
Emne: Re: Getting started...again.
James-
I am creating a sorta kickstart project, using technologies like
Apache MyFaces
Facelets
Apache Trinidad (formal Oracle ADF Faces)
Shale (View and application.manager (test will follow soon))
JPA
Toplink Essentials
as the container I am using jetty.
check here:
http://code.google.com/p/facesgoodies/
-M
On 1/15/07, Craig McClanahan [EMAIL PROTECTED] wrote:
On 1/15/07, Reynolds, James [EMAIL PROTECTED] wrote:
Steps 0 1 are complete :)
I'm much closer as I can see Tomcat behaving as I'd expect, though I did
end up with a couple errors in the log:
1. java.lang.NoClassDefFoundError: javax/el/ExpressionFactory
This is supposed to be pulled in by the dependencies for MyFaces
(commons-el?) if you're using JSF 1.1. It'll be part of the server if
you're using JSF 1.2 (the RI, since MyFaces doesn't support this yet).
2. org.apache.commons.chain.web.ChainListener
Make sure commons chain is not *also* in your Tomcat shared or common
dirs.
Commons-chain is definitely in my project, but I can't locate
javax/el/ExpressionFactory in my jsf libs. Should this be in my server
or J2EE libs? I'm attempting to use Tomcat 5.5.20
Does the prebuilt war in the 1.0.4 test builds work out of the box? If
so,
it'd be interesting to do a detailed comparison of JARs in yours versus
that
one. If not, we've got something else weird, because the out-of-the-box
one
runs for me.
Craig
On 1/15/07, Reynolds, James [EMAIL PROTECTED] wrote:
I've been on a hiatus from Shale since changing jobs last year;
however,
my new company is considering it based on my gushing recommendation.
Embarrassingly enough, I can't fire up the shale-blank application.
When I run the app, I see the output below in the console then -
nothing. No errors in tomcat or anything (that I can see). This
output
has changed since I last ran Shale. Do you see anything that might
explain the silent failure?
I've never tried it with the Shale libraries or facelets installed in
Tomcat's common/lib directory ... FIrst thing I would try is a
completely
vanilla Tomcat install, with the Shale jars deployed inside the webapp
(as
they should default when shale-blank builds).
Actually, the zeroth thing I would try is the 1.0.4 release instead of
1.0.3:-). Rahul is in the process of getting it out there; his test
build is
available at http://people.apache.org/~rahul/shale/v104/.
Craig
Thanks!
cmd /c C:\apache-tomcat-5.5.20\bin\catalina.bat run
Using CATALINA_BASE: C:\Documents and
Settings\jReynolds\.IntelliJIdea60\system\tomcat_Unnamed_5094815
Using CATALINA_HOME: C:\apache-tomcat-5.5.20
Using CATALINA_TMPDIR: C:\apache-tomcat-5.5.20\temp
Using JRE_HOME:C:\Java\jdk1.5.0_09
log4j:WARN No appenders could be found for logger
(org.apache.catalina.startup.Embedded).
log4j:WARN Please initialize the log4j system properly.
ContextListener:
attributeAdded('org$apache$shale$view$VIEW_CALLBACKS',
'[EMAIL PROTECTED]')
ContextListener:
attributeAdded('org.apache.shale.tiger.FACES_CONFIG_CONFIG',
'[EMAIL PROTECTED]')
ContextListener:
attributeAdded('org.apache.myfaces.config.RuntimeConfig',
'[EMAIL PROTECTED]')
ContextListener:
attributeAdded('org.apache.myfaces.webapp.webxml.WebXml',
'[EMAIL PROTECTED]')
ContextListener:
attributeAdded('org.apache.myfaces.webapp.StartupServletContextListener.
FACES_INIT_DONE', 'true')
ContextListener:
attributeAdded('org$apache$shale$view$VIEW_CALLBACKS',
'[EMAIL PROTECTED]')
ContextListener:
attributeAdded('org.apache.shale.tiger.FACES_CONFIG_CONFIG',
'[EMAIL PROTECTED]')
ContextListener:
attributeAdded('org.apache.myfaces.config.RuntimeConfig',
'[EMAIL PROTECTED]')
ContextListener:
attributeAdded('org.apache.myfaces.webapp.webxml.WebXml',
'[EMAIL PROTECTED]')
ContextListener:
attributeAdded('org.apache.myfaces.webapp.StartupServletContextListener.
FACES_INIT_DONE', 'true')
ContextListener:
attributeRemoved
RE: EL question
Ok, that explains why I couldn't do it ;-) Just thought it'd be nice to be
able to call methods like that and pass it String arguments.
I did already wrap my lucene search results in a List so I could pass that
list to the dataTable. But the Hit's in the list had a
Hit.getDocument.fiels() method returning the Fields (no get you see). I now
also wrapped the Hit's and added the getters I needed.
Thank you,
joost
JS Portal - Support
Dasstraat 21
2623CB Delft
the Netherlands
E: [EMAIL PROTECTED]
W: www.jsportal.com
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Craig
McClanahan
Sent: Wednesday, January 17, 2007 2:45 AM
To: user@shale.apache.org
Subject: Re: EL question
On 1/16/07, JS Portal Support [EMAIL PROTECTED] wrote:
Hi,
Maybe an ignorant (and more a simple JSP) question, but I can't seem to
figure out how to make an EL call that does:
org.apache.lucene.document.Document.get(String nameOfField)
I have my Hits (wrapped in a custom HitsToListWrapper) nicely accessible
for
each row of my dataTable (#{hit.document.butWhatHere}), but am struggling
with just this last seemingly simple step.
The EL used by JSP and JSF does not include support for arbitrary method
calls with parameters. It can only call JavaBeans property getters (and
setters, in the case of JSF expressions). You'll need to point your
expression at something that looks like getFoo().
The other thing to note is that a data table already knows how to iterate
over a List or array, so just pointing at one of those directly is the
easiest approach.
Thanks,
Joost
Craig
Re: Getting started...again.
m2 project
archetype will be the result
(need to add some more *demo* parts)
On 1/16/07, Hermod Opstvedt [EMAIL PROTECTED] wrote:
Hi
How are you creating it? As a complete Maven2 project, or as Maven2
archetype?
Reason for asking, is that I recently submitted Shale/Clay kickstart project
(The first of more to come with other faces libs included). Take a look in
the shale sandbox under maven
Hermod
-Opprinnelig melding-
Fra: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] På vegne av
Matthias Wessendorf
Sendt: 16. januar 2007 17:23
Til: user@shale.apache.org
Emne: Re: Getting started...again.
James-
I am creating a sorta kickstart project, using technologies like
Apache MyFaces
Facelets
Apache Trinidad (formal Oracle ADF Faces)
Shale (View and application.manager (test will follow soon))
JPA
Toplink Essentials
as the container I am using jetty.
check here:
http://code.google.com/p/facesgoodies/
-M
On 1/15/07, Craig McClanahan [EMAIL PROTECTED] wrote:
On 1/15/07, Reynolds, James [EMAIL PROTECTED] wrote:
Steps 0 1 are complete :)
I'm much closer as I can see Tomcat behaving as I'd expect, though I did
end up with a couple errors in the log:
1. java.lang.NoClassDefFoundError: javax/el/ExpressionFactory
This is supposed to be pulled in by the dependencies for MyFaces
(commons-el?) if you're using JSF 1.1. It'll be part of the server if
you're using JSF 1.2 (the RI, since MyFaces doesn't support this yet).
2. org.apache.commons.chain.web.ChainListener
Make sure commons chain is not *also* in your Tomcat shared or common
dirs.
Commons-chain is definitely in my project, but I can't locate
javax/el/ExpressionFactory in my jsf libs. Should this be in my server
or J2EE libs? I'm attempting to use Tomcat 5.5.20
Does the prebuilt war in the 1.0.4 test builds work out of the box? If
so,
it'd be interesting to do a detailed comparison of JARs in yours versus
that
one. If not, we've got something else weird, because the out-of-the-box
one
runs for me.
Craig
On 1/15/07, Reynolds, James [EMAIL PROTECTED] wrote:
I've been on a hiatus from Shale since changing jobs last year;
however,
my new company is considering it based on my gushing recommendation.
Embarrassingly enough, I can't fire up the shale-blank application.
When I run the app, I see the output below in the console then -
nothing. No errors in tomcat or anything (that I can see). This
output
has changed since I last ran Shale. Do you see anything that might
explain the silent failure?
I've never tried it with the Shale libraries or facelets installed in
Tomcat's common/lib directory ... FIrst thing I would try is a
completely
vanilla Tomcat install, with the Shale jars deployed inside the webapp
(as
they should default when shale-blank builds).
Actually, the zeroth thing I would try is the 1.0.4 release instead of
1.0.3:-). Rahul is in the process of getting it out there; his test
build is
available at http://people.apache.org/~rahul/shale/v104/.
Craig
Thanks!
cmd /c C:\apache-tomcat-5.5.20\bin\catalina.bat run
Using CATALINA_BASE: C:\Documents and
Settings\jReynolds\.IntelliJIdea60\system\tomcat_Unnamed_5094815
Using CATALINA_HOME: C:\apache-tomcat-5.5.20
Using CATALINA_TMPDIR: C:\apache-tomcat-5.5.20\temp
Using JRE_HOME:C:\Java\jdk1.5.0_09
log4j:WARN No appenders could be found for logger
(org.apache.catalina.startup.Embedded).
log4j:WARN Please initialize the log4j system properly.
ContextListener:
attributeAdded('org$apache$shale$view$VIEW_CALLBACKS',
'[EMAIL PROTECTED]')
ContextListener:
attributeAdded('org.apache.shale.tiger.FACES_CONFIG_CONFIG',
'[EMAIL PROTECTED]')
ContextListener:
attributeAdded('org.apache.myfaces.config.RuntimeConfig',
'[EMAIL PROTECTED]')
ContextListener:
attributeAdded('org.apache.myfaces.webapp.webxml.WebXml',
'[EMAIL PROTECTED]')
ContextListener:
attributeAdded('org.apache.myfaces.webapp.StartupServletContextListener.
FACES_INIT_DONE', 'true')
ContextListener:
attributeAdded('org$apache$shale$view$VIEW_CALLBACKS',
'[EMAIL PROTECTED]')
ContextListener:
attributeAdded('org.apache.shale.tiger.FACES_CONFIG_CONFIG',
'[EMAIL PROTECTED]')
ContextListener:
attributeAdded('org.apache.myfaces.config.RuntimeConfig',
'[EMAIL PROTECTED]')
ContextListener:
attributeAdded('org.apache.myfaces.webapp.webxml.WebXml',
'[EMAIL PROTECTED]')
ContextListener:
attributeAdded('org.apache.myfaces.webapp.StartupServletContextListener.
FACES_INIT_DONE', 'true')
ContextListener:
attributeRemoved('org.apache.shale.tiger.FACES_CONFIG_CONFIG',
'[EMAIL PROTECTED]')
ContextListener: attributeRemoved('org.apache.catalina.jsp_classpath',
'/C:/apache-tomcat-5.5.20/webapps/servlets-examples/WEB-INF/classes/;/C:
/apache-tomcat-5.5.20/common/classes/;/C:/apache-tomcat-5.5.20/common
Re: Remoting and other app security concerns - shale 1.0.3
On 1/16/07, Costa Basil [EMAIL PROTECTED] wrote: Today, I added some code for calling bean methods from ajax via shale remoting and to my wonder I discovered the mechanisms for executing bean calls are enabled by default. I don't think this is right. I think they should be disabled by default, and they should be enabled once the configuration settings are added to the web.xml. When I added shale core and shale remoting to my project I didn't have time to read the remoting documentation (I didn't have to use it at that time) and I didn't think shale would provide ways to poke server code by default. Is there anything else that I should be aware of? Anyway, I want to enable access only to one bean. I used the DYNAMIC_RESOURCES_INCLUDES directive, but this doesn't make any difference. I didn't understand from the documentation how shale processes the DYNAMIC_RESOURCES_INCLUDES and DYNAMIC_RESOURCES_EXCLUDES parameters and I didn't have time to read the code. Can someone explain this? The other way would be to use the default web app security settings. The 1.0.3 release did not support the restriction init parameters like DYNAMIC_RESOURCES_INCLUDES, but the upcoming 1.0.4 release (currently being voted on) does support them. Thanks Craig
Re: How to pass object between backing beans
On 1/14/07, JS Portal Support [EMAIL PROTECTED] wrote: By the sounds of it jMaki is the way to go then. I understand you might be a bit bias here, but if it does whatever DOJO does and more, capturing all frameworks, what would be the reason for choosing any other framework? Whatever DOJO does and more is not quite right ... jMaki doesn't currently cover all of DOJO (or any of the other frameworks), and like any abstraction layer its simplifications sometimes hide some of the capabilities of the underlying widgets. On the other hand, the ability to mix and match widgets from different libraries is pretty handy if you need it. Which is right for you? Don't know ... that's really your call, depending on your requirements :-). The best thing to do would ge articulate the kinds of capabilities you need, and see if there is a widget library that addresses all of those needs directly. If there is, you might want to look at just using that library directly. On the other hand, if you really need multiple libraries, or you like the simplifications that jMaki provides, it can be useful. I agree with Kito's comments about how the existing jMaki JSF integration is not particularly in the style of other JSF components. I'm doing some work in the jMaki project (contributions welcome ... it's open source) to provide a more traditional style JSF component library that uses jMaki to do all the rendering grunt work, but provides a component-per-widget environment that JSF based developers will be familiar with. It might be worth taking a look at that, although it's in its early stages (six widgets wrapped so far). Cheers, Joost Craig -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Craig McClanahan Sent: Monday, January 15, 2007 3:29 PM To: user@shale.apache.org Subject: Re: How to pass object between backing beans On 1/14/07, JS Portal Support [EMAIL PROTECTED] wrote: Craig, Great, it now works nicely and is portable to any other view I might create in the future without altering my GenericTable view. Cool ... that's the way it's supposed to work :-). On a different note: Is it correct btw that MyFaces will use DOJO AJAX toolkit as its script engine of choice? As we are currently looking at our options it seems to me this will be the wisest choice right? More specifically, the component libraries at MyFaces (Tomahawk and Tobago in the MyFaces project now, Trinidad in the incutabor) have tended to choose Dojo for their Ajax support. That's more up to each individual library than it is up to MyFaces as a whole. And, as a general policy, I can't disagree that it is a reasonable choice. I used Dojo also in our work on the Blueprints Ajax components[1] that ship with Java Studio Creator and NetBeans Visual Web Pack. We made that choice originally because of the nice lower level APIs for asynchronous messaging and eventing on the client side. I've been pretty happy with those layers, but not quite as happy with the UI widget layer -- which has been going through a lot of evolution lately but is looking more settled as we go on. Personally, I'm spending a bunch of time today on the jMaki project[2], where a primary goal is to let you avoid locking yourself into one particular widget framework. jMaki strives to provide a common adapter API around various widget libraries (including Dojo, Spry, Scriptaculous, Yahoo, and a bunch of others) to both reduce complexity and support mix-and-match. Today, there's a low level JSF component that provides direct connection to a large portion of these libraries, but with a fairly low level API. I'm also working on adding a layer of JSF components per widget that will appeal more to someone familiar with traditional JSF composition of your views ... and, will fit very nicely into visual development tools. Needless to say, this all works very nicely with Shale :-). I have to say the more I learn about shale/MyFaces the more excited I get. We come from a custom build mvc which we respectfully will lay to rest now :-) :-) Thanks, Joost Craig
Re: Getting started...again.
On 1/15/07, Reynolds, James [EMAIL PROTECTED] wrote:
I've been on a hiatus from Shale since changing jobs last year; however,
my new company is considering it based on my gushing recommendation.
Embarrassingly enough, I can't fire up the shale-blank application.
When I run the app, I see the output below in the console then -
nothing. No errors in tomcat or anything (that I can see). This output
has changed since I last ran Shale. Do you see anything that might
explain the silent failure?
I've never tried it with the Shale libraries or facelets installed in
Tomcat's common/lib directory ... FIrst thing I would try is a completely
vanilla Tomcat install, with the Shale jars deployed inside the webapp (as
they should default when shale-blank builds).
Actually, the zeroth thing I would try is the 1.0.4 release instead of
1.0.3:-). Rahul is in the process of getting it out there; his test
build is
available at http://people.apache.org/~rahul/shale/v104/.
Craig
Thanks!
cmd /c C:\apache-tomcat-5.5.20\bin\catalina.bat run
Using CATALINA_BASE: C:\Documents and
Settings\jReynolds\.IntelliJIdea60\system\tomcat_Unnamed_5094815
Using CATALINA_HOME: C:\apache-tomcat-5.5.20
Using CATALINA_TMPDIR: C:\apache-tomcat-5.5.20\temp
Using JRE_HOME:C:\Java\jdk1.5.0_09
log4j:WARN No appenders could be found for logger
(org.apache.catalina.startup.Embedded).
log4j:WARN Please initialize the log4j system properly.
ContextListener: attributeAdded('org$apache$shale$view$VIEW_CALLBACKS',
'[EMAIL PROTECTED]')
ContextListener:
attributeAdded('org.apache.shale.tiger.FACES_CONFIG_CONFIG',
'[EMAIL PROTECTED]')
ContextListener:
attributeAdded('org.apache.myfaces.config.RuntimeConfig',
'[EMAIL PROTECTED]')
ContextListener:
attributeAdded('org.apache.myfaces.webapp.webxml.WebXml',
'[EMAIL PROTECTED]')
ContextListener:
attributeAdded('org.apache.myfaces.webapp.StartupServletContextListener.
FACES_INIT_DONE', 'true')
ContextListener: attributeAdded('org$apache$shale$view$VIEW_CALLBACKS',
'[EMAIL PROTECTED]')
ContextListener:
attributeAdded('org.apache.shale.tiger.FACES_CONFIG_CONFIG',
'[EMAIL PROTECTED]')
ContextListener:
attributeAdded('org.apache.myfaces.config.RuntimeConfig',
'[EMAIL PROTECTED]')
ContextListener:
attributeAdded('org.apache.myfaces.webapp.webxml.WebXml',
'[EMAIL PROTECTED]')
ContextListener:
attributeAdded('org.apache.myfaces.webapp.StartupServletContextListener.
FACES_INIT_DONE', 'true')
ContextListener:
attributeRemoved('org.apache.shale.tiger.FACES_CONFIG_CONFIG',
'[EMAIL PROTECTED]')
ContextListener: attributeRemoved('org.apache.catalina.jsp_classpath',
'/C:/apache-tomcat-5.5.20/webapps/servlets-examples/WEB-INF/classes/;/C:
/apache-tomcat-5.5.20/common/classes/;/C:/apache-tomcat-5.5.20/common/i1
8n/tomcat-i18n-en.jar;/C:/apache-tomcat-5.5.20/common/i18n/tomcat-i18n-e
s.jar;/C:/apache-tomcat-5.5.20/common/i18n/tomcat-i18n-fr.jar;/C:/apache
-tomcat-5.5.20/common/i18n/tomcat-i18n-ja.jar;/C:/apache-tomcat-5.5.20/c
ommon/lib/commons-beanutils-1.7.0.jar;/C:/apache-tomcat-5.5.20/common/li
b/commons-chain-1.1.jar;/C:/apache-tomcat-5.5.20/common/lib/commons-code
c-1.3.jar;/C:/apache-tomcat-5.5.20/common/lib/commons-collections-3.1.ja
r;/C:/apache-tomcat-5.5.20/common/lib/commons-digester-1.7.jar;/C:/apach
e-tomcat-5.5.20/common/lib/commons-el-1.0.jar;/C:/apache-tomcat-5.5.20/c
ommon/lib/commons-el.jar;/C:/apache-tomcat-5.5.20/common/lib/commons-fil
eupload-1.0.jar;/C:/apache-tomcat-5.5.20/common/lib/commons-lang-2.1.jar
;/C:/apache-tomcat-5.5.20/common/lib/commons-logging-1.1.jar;/C:/apache-
tomcat-5.5.20/common/lib/commons-validator-1.1.4.jar;/C:/apache-tomcat-5
.5.20/common/lib/jasper-compiler-jdt.jar;/C:/apache-tomcat-5.5.20/common
/lib/jasper-compiler.jar;/C:/apache-tomcat-5.5.20/common/lib/jasper-runt
ime.jar;/C:/apache-tomcat-5.5.20/common/lib/jsf-facelets.jar;/C:/apache-
tomcat-5.5.20/common/lib/jsp-api.jar;/C:/apache-tomcat-5.5.20/common/lib
/jstl-1.1.2.jar;/C:/apache-tomcat-5.5.20/common/lib/log4j-1.2.12.jar;/C:
/apache-tomcat-5.5.20/common/lib/myfaces-api-1.1.1.jar;/C:/apache-tomcat
-5.5.20/common/lib/myfaces-impl-1.1.1.jar;/C:/apache-tomcat-5.5.20/commo
n/lib/naming-factory-dbcp.jar;/C:/apache-tomcat-5.5.20/common/lib/naming
-factory.jar;/C:/apache-tomcat-5.5.20/common/lib/naming-resources.jar;/C
:/apache-tomcat-5.5.20/common/lib/oro-2.0.8.jar;/C:/apache-tomcat-5.5.20
/common/lib/servlet-api.jar;/C:/apache-tomcat-5.5.20/common/lib/shale-cl
ay-1.0.3.jar;/C:/apache-tomcat-5.5.20/common/lib/shale-core-1.0.3.jar;/C
:/apache-tomcat-5.5.20/common/lib/shale-remoting-1.0.3.jar;/C:/apache-to
mcat-5.5.20/common/lib/shale-spring-1.0.3.jar;/C:/apache-tomcat-5.5.20/c
ommon/lib/shale-test-1.0.3.jar;/C:/apache-tomcat-5.5.20/common/lib/shale
-tiger-1.0.3.jar;/C:/apache-tomcat-5.5.20/common/lib/shale-tiles-1.0.3.j
ar;/C:/apache-tomcat-5.5.20/common/lib/spring-beans-1.2.8.jar;/C:/apache
-tomcat-5.5.20/common/lib/spring-context-1.2.8.jar;/C:/apache-tomcat-5.5
RE: How to pass object between backing beans
Craig,
Great, it now works nicely and is portable to any other view I might create
in the future without altering my GenericTable view.
On a different note:
Is it correct btw that MyFaces will use DOJO AJAX toolkit as its script
engine of choice? As we are currently looking at our options it seems to me
this will be the wisest choice right?
I have to say the more I learn about shale/MyFaces the more excited I get.
We come from a custom build mvc which we respectfully will lay to rest now
:-)
Thanks,
Joost
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Craig
McClanahan
Sent: Monday, January 15, 2007 12:24 PM
To: user@shale.apache.org
Subject: Re: How to pass object between backing beans
On 1/13/07, JS Portal Support [EMAIL PROTECTED] wrote:
Thanks Craig,
That makes sense. But the problem here is that generictable will be called
from many views, and not just the myfiles view. So I would love the
injection to be handled from the myfiles view, backing bean or
managed-bean
declaration. Is this possible?
In this case, doing an injection from the view wouldn't work anyway, right?
Fortunately, since it's your controller that knows what view it is going to
navigate to, it can do the injection programmatically. There's two
different possible techniques:
Using standard JSF APIs, programmatically evaluate an EL expression like
this:
FacesContext context = FacesContext.getCurrentInstance();
ValueBinding vb = context.getApplication().createValueBinding(#{
generictable.fileList});
vb.setValue(context, ... the list to be injected ...);
or, if you are extending AbstractViewController, you can take advantage of a
helper method:
GenericTable gt = getBean(generictable);
gt.setFileList(... the list to be injected ...);
So basically I want my s:view to pass instantiated objects to its
s:subview's
For this particular scenario, putting the injection code into the prerender
method of the outer view should do the trick. That's the same place you
would go grab data that you might need for the outer view itself, so it's
nicely consistent when using subviews.
Thanks,
Joost
Craig
Re: How to pass object between backing beans
On 1/14/07, JS Portal Support [EMAIL PROTECTED] wrote: Craig, Great, it now works nicely and is portable to any other view I might create in the future without altering my GenericTable view. Cool ... that's the way it's supposed to work :-). On a different note: Is it correct btw that MyFaces will use DOJO AJAX toolkit as its script engine of choice? As we are currently looking at our options it seems to me this will be the wisest choice right? More specifically, the component libraries at MyFaces (Tomahawk and Tobago in the MyFaces project now, Trinidad in the incutabor) have tended to choose Dojo for their Ajax support. That's more up to each individual library than it is up to MyFaces as a whole. And, as a general policy, I can't disagree that it is a reasonable choice. I used Dojo also in our work on the Blueprints Ajax components[1] that ship with Java Studio Creator and NetBeans Visual Web Pack. We made that choice originally because of the nice lower level APIs for asynchronous messaging and eventing on the client side. I've been pretty happy with those layers, but not quite as happy with the UI widget layer -- which has been going through a lot of evolution lately but is looking more settled as we go on. Personally, I'm spending a bunch of time today on the jMaki project[2], where a primary goal is to let you avoid locking yourself into one particular widget framework. jMaki strives to provide a common adapter API around various widget libraries (including Dojo, Spry, Scriptaculous, Yahoo, and a bunch of others) to both reduce complexity and support mix-and-match. Today, there's a low level JSF component that provides direct connection to a large portion of these libraries, but with a fairly low level API. I'm also working on adding a layer of JSF components per widget that will appeal more to someone familiar with traditional JSF composition of your views ... and, will fit very nicely into visual development tools. Needless to say, this all works very nicely with Shale :-). I have to say the more I learn about shale/MyFaces the more excited I get. We come from a custom build mvc which we respectfully will lay to rest now :-) :-) Thanks, Joost Craig
Re: How to pass object between backing beans
It pays to add the footnotes: [1] https://bpcatalog.dev.java.net/ [2] https://ajax.dev.java.net/ Craig On 1/14/07, Craig McClanahan [EMAIL PROTECTED] wrote: On 1/14/07, JS Portal Support [EMAIL PROTECTED] wrote: Craig, Great, it now works nicely and is portable to any other view I might create in the future without altering my GenericTable view. Cool ... that's the way it's supposed to work :-). On a different note: Is it correct btw that MyFaces will use DOJO AJAX toolkit as its script engine of choice? As we are currently looking at our options it seems to me this will be the wisest choice right? More specifically, the component libraries at MyFaces (Tomahawk and Tobago in the MyFaces project now, Trinidad in the incutabor) have tended to choose Dojo for their Ajax support. That's more up to each individual library than it is up to MyFaces as a whole. And, as a general policy, I can't disagree that it is a reasonable choice. I used Dojo also in our work on the Blueprints Ajax components[1] that ship with Java Studio Creator and NetBeans Visual Web Pack. We made that choice originally because of the nice lower level APIs for asynchronous messaging and eventing on the client side. I've been pretty happy with those layers, but not quite as happy with the UI widget layer -- which has been going through a lot of evolution lately but is looking more settled as we go on. Personally, I'm spending a bunch of time today on the jMaki project[2], where a primary goal is to let you avoid locking yourself into one particular widget framework. jMaki strives to provide a common adapter API around various widget libraries (including Dojo, Spry, Scriptaculous, Yahoo, and a bunch of others) to both reduce complexity and support mix-and-match. Today, there's a low level JSF component that provides direct connection to a large portion of these libraries, but with a fairly low level API. I'm also working on adding a layer of JSF components per widget that will appeal more to someone familiar with traditional JSF composition of your views ... and, will fit very nicely into visual development tools. Needless to say, this all works very nicely with Shale :-). I have to say the more I learn about shale/MyFaces the more excited I get. We come from a custom build mvc which we respectfully will lay to rest now :-) :-) Thanks, Joost Craig
[OT] jMaki, Dojo, and AJAX integration (was RE: How to pass object between backing beans)
Craig, I was talking to Greg Murray about jMaki at Javapolis, and I mentioned the possibility of generating JSF components based on some metadata much like the RI and MyFaces do for the HTML components and the tag libraries. (I don't think Greg fully appreciates the value of the JSF model.) Are you taking a code-generation approach or more of a hand-crafted approach? ~~~ Kito D. Mann - Author, JavaServer Faces in Action http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info * Sign up for the JSF Central newsletter! http://oi.vresp.com/?fid=ac048d0e17 * -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Craig McClanahan Sent: Sunday, January 14, 2007 9:29 PM To: user@shale.apache.org Subject: Re: How to pass object between backing beans On 1/14/07, JS Portal Support [EMAIL PROTECTED] wrote: Craig, Great, it now works nicely and is portable to any other view I might create in the future without altering my GenericTable view. Cool ... that's the way it's supposed to work :-). On a different note: Is it correct btw that MyFaces will use DOJO AJAX toolkit as its script engine of choice? As we are currently looking at our options it seems to me this will be the wisest choice right? More specifically, the component libraries at MyFaces (Tomahawk and Tobago in the MyFaces project now, Trinidad in the incutabor) have tended to choose Dojo for their Ajax support. That's more up to each individual library than it is up to MyFaces as a whole. And, as a general policy, I can't disagree that it is a reasonable choice. I used Dojo also in our work on the Blueprints Ajax components[1] that ship with Java Studio Creator and NetBeans Visual Web Pack. We made that choice originally because of the nice lower level APIs for asynchronous messaging and eventing on the client side. I've been pretty happy with those layers, but not quite as happy with the UI widget layer -- which has been going through a lot of evolution lately but is looking more settled as we go on. Personally, I'm spending a bunch of time today on the jMaki project[2], where a primary goal is to let you avoid locking yourself into one particular widget framework. jMaki strives to provide a common adapter API around various widget libraries (including Dojo, Spry, Scriptaculous, Yahoo, and a bunch of others) to both reduce complexity and support mix-and-match. Today, there's a low level JSF component that provides direct connection to a large portion of these libraries, but with a fairly low level API. I'm also working on adding a layer of JSF components per widget that will appeal more to someone familiar with traditional JSF composition of your views ... and, will fit very nicely into visual development tools. Needless to say, this all works very nicely with Shale :-). I have to say the more I learn about shale/MyFaces the more excited I get. We come from a custom build mvc which we respectfully will lay to rest now :-) :-) Thanks, Joost Craig
RE: How to pass object between backing beans
By the sounds of it jMaki is the way to go then. I understand you might be a bit bias here, but if it does whatever DOJO does and more, capturing all frameworks, what would be the reason for choosing any other framework? Cheers, Joost -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Craig McClanahan Sent: Monday, January 15, 2007 3:29 PM To: user@shale.apache.org Subject: Re: How to pass object between backing beans On 1/14/07, JS Portal Support [EMAIL PROTECTED] wrote: Craig, Great, it now works nicely and is portable to any other view I might create in the future without altering my GenericTable view. Cool ... that's the way it's supposed to work :-). On a different note: Is it correct btw that MyFaces will use DOJO AJAX toolkit as its script engine of choice? As we are currently looking at our options it seems to me this will be the wisest choice right? More specifically, the component libraries at MyFaces (Tomahawk and Tobago in the MyFaces project now, Trinidad in the incutabor) have tended to choose Dojo for their Ajax support. That's more up to each individual library than it is up to MyFaces as a whole. And, as a general policy, I can't disagree that it is a reasonable choice. I used Dojo also in our work on the Blueprints Ajax components[1] that ship with Java Studio Creator and NetBeans Visual Web Pack. We made that choice originally because of the nice lower level APIs for asynchronous messaging and eventing on the client side. I've been pretty happy with those layers, but not quite as happy with the UI widget layer -- which has been going through a lot of evolution lately but is looking more settled as we go on. Personally, I'm spending a bunch of time today on the jMaki project[2], where a primary goal is to let you avoid locking yourself into one particular widget framework. jMaki strives to provide a common adapter API around various widget libraries (including Dojo, Spry, Scriptaculous, Yahoo, and a bunch of others) to both reduce complexity and support mix-and-match. Today, there's a low level JSF component that provides direct connection to a large portion of these libraries, but with a fairly low level API. I'm also working on adding a layer of JSF components per widget that will appeal more to someone familiar with traditional JSF composition of your views ... and, will fit very nicely into visual development tools. Needless to say, this all works very nicely with Shale :-). I have to say the more I learn about shale/MyFaces the more excited I get. We come from a custom build mvc which we respectfully will lay to rest now :-) :-) Thanks, Joost Craig
RE: ViewController.preprocess never called
Craig, Due to reasons I don't quite understand it started working. I tried to find out what I did that changed it, but unfortunately I can't backtrack the cause. But, fortunately, it works! Thanks, Joost JS Portal - Support Dasstraat 21 2623CB Delft the Netherlands E: [EMAIL PROTECTED] W: www.jsportal.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Craig McClanahan Sent: Friday, January 12, 2007 7:00 PM To: user@shale.apache.org Subject: Re: ViewController.preprocess never called On 1/11/07, JS Portal support team [EMAIL PROTECTED] wrote: Hi, I have a backing bean which extends an abstract backing bean extending the AbstractViewController. I use preprocess to enlist resources that need to be committed once the entire request is done. However, preprocess never gets called, while init does get called. Could anyone point me to clues why this might be and what common scenarios are when this happens. One very common mistake is to attempt to place your ViewController bean in session scope. If you are doing that, it's not going to work (but you should look at the Dialog capabilities for techniques of maintaining state across requests). If that is not your situation, could you please post snippets of your faces-config.xml describing the managed bean that you have defined? Thank you, joost Craig
RE: state tracking for jsp:include's
Joost, Looking at the issues you're having, it looks like you need one or more other objects in a different scope (such as session). For example, if you had a session-scoped visit object that was injected into your backing beans, it could store state inbetween requests, and your backing beans could just updated it whenever there was some information that needed stick around longer. Another aproach would be to use scopes in the dialog manager; someone else on this list can tell you more about that. ~~~ Kito D. Mann - Author, JavaServer Faces in Action http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info * Sign up for the JSF Central newsletter! http://oi.vresp.com/?fid=ac048d0e17 * -Original Message- From: JS Portal support team [mailto:[EMAIL PROTECTED] Sent: Saturday, January 13, 2007 3:33 AM To: user@shale.apache.org Subject: state tracking for jsp:include's Sorry if I'm asking a lot of newbie questions here, but some things are not quite clear to me. When I have a /entities/file.jsp backed by my file class. and access it directly all works fine. But when I include the /entities/file.jsp (jsp:include page=/entities/file.jsp) in another jsp, shale/myfaces seems to loose the discussion of the included pages. Upon each request the backing bean for the included pages gets reinitiated. How can I have my includes remember their state as well as the containing page? Thanks, Joost
RE: How to pass object between backing beans
Thanks Craig,
That makes sense. But the problem here is that generictable will be called
from many views, and not just the myfiles view. So I would love the
injection to be handled from the myfiles view, backing bean or managed-bean
declaration. Is this possible?
So basically I want my s:view to pass instantiated objects to its
s:subview's
Thanks,
Joost
JS Portal - Support
Dasstraat 21
2623CB Delft
the Netherlands
E: [EMAIL PROTECTED]
W: www.jsportal.com
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Craig
McClanahan
Sent: Sunday, January 14, 2007 1:08 PM
To: user@shale.apache.org
Subject: Re: How to pass object between backing beans
On 1/13/07, JS Portal support team [EMAIL PROTECTED] wrote:
Hi,
I have a view (myfiles.jsp) plus backing bean (myfiles). myfiles.jsp has
an jsp:include (filestable.jsp) in an s:subview which is backed by my
generictable bean. How can I best pass the List of file Objects from
myfiles to generictable. Something like jsp:param name=fileList
value=#{myfiles.files} would be great.
Or is this not the right way to setup my architecture?
As a matter of fact, something very similar to this is available ... but
it's done in the managed bean definition instead of in the view:
managed-bean
managed-bean-namegenerictable/managed-bean-name
managed-bean-class.../managed-bean-class
managed-bean-scoperequest/managed-bean-scope
managed-property
property-namefileList/property-name
value#{myfiles.files}/value
/managed-property
/managed-bean
The expression will be evaluated when this managed bean is created, and
setFileList() will be called with the result.
This general technique is known as dependency injection, and JSF supports
the variant called setter injection which (as the name implies) uses
property setters to actually insert the values. The only restriction on
what kind of expressions you can evaluate are that you cannot inject a value
from a shorter scope (such as request) into a bean in a longer scope
(session or application). The other way around (longer-scoped bean into
shorter-scoped bean property), or the same scope, is fine.
Thank you
Craig
Re: [clay] closing urlconnections
From: Ryan Wynn [EMAIL PROTECTED]
I noticed that in Clay's ComponentConfigBean$WatchDog the following is
used to close the open URLConnections:
private void close() {
if (connections == null) {
return;
}
for (int i = 0; i connections.length; i++) {
connections[i] = null;
}
connections = null;
}
Is dereferencing these enough or would it be better to explicitly call
close() on the inputstreams associated with the connections?
Opening and closing the input streams is the job of the Parser. They use the
URL object versus the URLConnection.
There are a couple of flavors:
1)
http://svn.apache.org/viewvc/shale/framework/trunk/shale-clay/src/main/java/org/apache/shale/clay/config/ClayXmlParser.java?view=markup
2)
http://svn.apache.org/viewvc/shale/framework/trunk/shale-clay/src/main/java/org/apache/shale/clay/config/ClayTemplateParser.java?view=markup
The Watch Dog uses the URLConnection to find the last modified time-stamp.
Gary
Re: ViewController.preprocess never called
On 1/11/07, JS Portal support team [EMAIL PROTECTED] wrote: Hi, I have a backing bean which extends an abstract backing bean extending the AbstractViewController. I use preprocess to enlist resources that need to be committed once the entire request is done. However, preprocess never gets called, while init does get called. Could anyone point me to clues why this might be and what common scenarios are when this happens. One very common mistake is to attempt to place your ViewController bean in session scope. If you are doing that, it's not going to work (but you should look at the Dialog capabilities for techniques of maintaining state across requests). If that is not your situation, could you please post snippets of your faces-config.xml describing the managed bean that you have defined? Thank you, joost Craig
Re: Clicking Cancel twice to get out of sub-dialog?
I've created a sample WAR application[1] which displays this behaviour. If anyone is willing to download and run it I'd be very grateful! Adam [1] http://www.outofthemold.com/bwa.war
Re: Clicking Cancel twice to get out of sub-dialog?
-- Original message -- From: Adam Koch [EMAIL PROTECTED] I added immediate=true to my cancel button and added a messages tag to my page, but neither helped. I wonder if you need a viewId attribute on the end state to tell it where to go next? I didn't see one in the previous thread. end name=quit viewId=/index.jsf/ Here is some of the log after I clicked the Cancel button the first time: [2007-01-02 12:47:35,160] [TRACE] [ org.apache.shale.dialog.basic.BasicDialogContext] [--EndState()] [2007-01-02 12:47:35,160] [DEBUG] [ org.apache.shale.dialog.faces.DialogNavigationHandler] [Advancing dialog 'View User Authorization' for FacesContext ' [EMAIL PROTECTED]' with navigation to viewId '/secure/dialog/addRole/add-step1.jsp'] The EndState is good to see, but what's confusing to me is that it's navigating to a view id that isn't defined in the dialog View User Authorization. The add-step1.jsp is part of the sub-dialog. When I click on the Cancel button again, then I see the correct behaviour: [2007-01-02 12:48:00,380] [TRACE] [ org.apache.shale.dialog.basic.BasicDialogContext] [--ViewState(viewId=/secure/authorization/index.jsp,redirect=false)] [2007-01-02 12:48:00,380] [TRACE] [ org.apache.shale.dialog.basic.BasicDialogContext] [--Navigate(viewId=/secure/authorization/index.jsp)] [2007-01-02 12:48:00,380] [DEBUG] [ org.apache.shale.dialog.faces.DialogNavigationHandler] [Advancing dialog 'View User Authorization' for FacesContext ' [EMAIL PROTECTED]' with navigation to viewId '/secure/authorization/index.jsp'] Any thoughts? Adam Gary
Re: How to load faces-config.xml in the test framework?
On 1/1/07, Paul Spencer [EMAIL PROTECTED] wrote: How do I load faces-config.xml when running a test based on AbstractJsfTestCase? My current testing manually adds the renderers during setUp(). This work, but it has the following drawbacks: 1) The association between a component and it renderer must be maintained in more then one place. 2) Testing with more then one JSF Implementation is a lot of extra work. Ideally I would like to instruct shale-test to load the implementation's jsf configuration file, i.e. faces-config.xml. How do I do this? There is an outstanding Shale RFE for this feature already[1], and seeing what you were doing kind of motivated me to start working on it a bit in between plays in the football games today :-). My thinking is to provide an optional utility helper (based on Commons Digester) with a parse(URL) method that you could call to register things like components, converters, validators, renderkits, and renderers. The parser would typically be called during a setUp() method of a test case. We'll still have an implementation-specific issue for dealing with the registration of the standard components (since MyFaces and the RI use different resource names), but that's probably something that can be abstracted into a get me the URL(s) of the standard component definitions method that could isolate the differences into one place. Is this what you had in mind? Paul Spencer Craig [1] https://issues.apache.org/struts/browse/SHALE-262
Re: How to load faces-config.xml in the test framework?
Craig, Yes, we are thing along the same lines. As an example, I have a version hardcoded to MyFaces renderers in place [1][2]. I suspect configuring a digester type utility that reads faces-config.xml located in the class path like JSF implementation do, but also allows a file to be passed into the utility, would work very well. After I hard coded the MyFaces stuff, I tried to run it using Sun's RI. As you alluded to, it failed since the package and class names are different. Paul Spencer [1] http://svn.apache.org/viewvc/myfaces/tomahawk/trunk/core/src/test/java/org/apache/myfaces/test/AbstractTomahawkJsfTestCase.java?view=markup [2] http://svn.apache.org/viewvc/myfaces/tomahawk/trunk/core/src/test/java/org/apache/myfaces/test/utils/TestUtils.java?view=markup Craig McClanahan wrote: On 1/1/07, Paul Spencer [EMAIL PROTECTED] wrote: How do I load faces-config.xml when running a test based on AbstractJsfTestCase? My current testing manually adds the renderers during setUp(). This work, but it has the following drawbacks: 1) The association between a component and it renderer must be maintained in more then one place. 2) Testing with more then one JSF Implementation is a lot of extra work. Ideally I would like to instruct shale-test to load the implementation's jsf configuration file, i.e. faces-config.xml. How do I do this? There is an outstanding Shale RFE for this feature already[1], and seeing what you were doing kind of motivated me to start working on it a bit in between plays in the football games today :-). My thinking is to provide an optional utility helper (based on Commons Digester) with a parse(URL) method that you could call to register things like components, converters, validators, renderkits, and renderers. The parser would typically be called during a setUp() method of a test case. We'll still have an implementation-specific issue for dealing with the registration of the standard components (since MyFaces and the RI use different resource names), but that's probably something that can be abstracted into a get me the URL(s) of the standard component definitions method that could isolate the differences into one place. Is this what you had in mind? Paul Spencer Craig [1] https://issues.apache.org/struts/browse/SHALE-262
