http://blog.gmane.org/gmane.comp.apache.shale.issues hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.comp.apache.shale.issues/1545 FacesVariableResolverChainWrapper incorrectly sets properties to resolved ------------------------------------------------------------------------- Key: SHALE-496 URL: https://issues.apache.org/struts/browse/SHALE-496 Project: Shale Issue Type: Bug Reporter: David Green FacesVariableResolverChainWrapper incorrectly sets properties to resolved, causing the chain of ELResolvers to short-circuit. This can cause problems for applications that use a custom ELResolver added to the application. David Green (JIRA 2008-10-16T22:39:36 http://comments.gmane.org/gmane.comp.apache.shale.issues/1528 [ https://issues.apache.org/struts/browse/SHALE-24?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Craig McClanahan updated SHALE-24: ---------------------------------- Comment: was deleted Craig McClanahan (JIRA 2008-09-18T04:34:24 http://comments.gmane.org/gmane.comp.apache.shale.issues/1524 [ https://issues.apache.org/struts/browse/SHALE-24?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=44727#action_44727 ] payne commented on SHALE-24: ---------------------------- http://www.gnn.com.br/forum/showthread.php?t=1000087664 http://www.gnn.com.br/forum/showthread.php?t=1000087663 http://www.gnn.com.br/forum/showthread.php?t=1000087662 http://www.gnn.com.br/forum/showthread.php?t=1000087661 http://www.gnn.com.br/forum/showthread.php?t=1000087660 http://www.gnn.com.br/forum/showthread.php?t=1000087659 http://www.gnn.com.br/forum/showthread.php?t=1000087658 http://www.gnn.com.br/forum/showthread.php?t=1000087657 http://www.gnn.com.br/forum/showthread.php?t=1000087655 http://www.gnn.com.br/forum/showthread.php?t=1000087654 http://www.gnn.com.br/forum/showthread.php?t=1000087653 http://www.gnn.com.br/forum/showthread.php?t=1000087652 http://www.gnn.com.br/forum/showthread.php?t=1000087651 http://www.gnn.com.br/forum/showthread.php?t=1000087650 http://www.gnn.com.br/forum/showthread.php?t=1000087649 http://www.gnn.com.br/forum/showthread.php?t=1000087647 http://www.gnn.com.br/forum/showthread.php?t=1000087646 http://www.gnn.com.br/forum/showthread.php?t=1000087645 http://www.gnn.com.br/forum/showthread.php?t=1000087643 http://www.gnn.com.br/forum/showthread.php?t=1000087642 http://www.gnn.com.br/forum/showthread.php?t=1000087640 http://www.gnn.com.br/forum/showthread.php?t=1000087639 http://www.gnn.com.br/forum/showthread.php?t=1000087638 http://www.gnn.com.br/forum/showthread.php?t=1000087637 http://www.gnn.com.br/forum/showthread.php?t=1000087636 http://www.gnn.com.br/forum/showthread.php?t=1000087635 http://www.gnn.com.br/forum/showthread.php?t=1000087633 http://www.gnn.com.br/forum/showthread.php?t=1000087554 http://www.gnn.com.br/forum/showthread.php?t=1000087553 http://www.gnn.com.br/forum/showthread.php?t=1000087551 http://www.gnn.com.br/forum/showthread.php?t=1000087550 http://www.gnn.com.br/forum/showthread.php?t=1000087548 http://www.gnn.com.br/forum/showthread.php?t=1000087547 http://www.gnn.com.br/forum/showthread.php?t=1000087546 http://www.gnn.com.br/forum/showthread.php?t=1000087545 http://www.gnn.com.br/forum/showthread.php?t=1000087632 http://www.gnn.com.br/forum/showthread.php?t=1000087631 http://www.gnn.com.br/forum/showthread.php?t=1000087630 http://www.gnn.com.br/forum/showthread.php?t=1000087629 http://www.gnn.com.br/forum/showthread.php?t=1000087628 http://www.gnn.com.br/forum/showthread.php?t=1000087627 http://www.gnn.com.br/forum/showthread.php?t=1000087625 http://www.gnn.com.br/forum/showthread.php?t=1000087624 http://www.gnn.com.br/forum/showthread.php?t=1000087623 http://www.gnn.com.br/forum/showthread.php?t=1000087622 http://www.gnn.com.br/forum/showthread.php?t=1000087621 http://www.gnn.com.br/forum/showthread.php?t=1000087620 http://www.gnn.com.br/forum/showthread.php?t=1000087618 http://www.gnn.com.br/forum/showthread.php?t=1000087617 http://www.gnn.com.br/forum/showthread.php?t=1000087616 http://www.gnn.com.br/forum/showthread.php?t=1000087615 http://www.gnn.com.br/forum/showthread.php?t=1000087614 http://www.gnn.com.br/forum/showthread.php?t=1000087613 http://www.gnn.com.br/forum/showthread.php?t=1000087611 http://www.gnn.com.br/forum/showthread.php?t=1000087610 http://www.gnn.com.br/forum/showthread.php?t=1000087609 http://www.gnn.com.br/forum/showthread.php?t=1000087608 http://www.gnn.com.br/forum/showthread.php?t=1000087607 http://www.gnn.com.br/forum/showthread.php?t=1000087605 http://www.gnn.com.br/forum/showthread.php?t=1000087604 http://www.gnn.com.br/forum/showthread.php?t=1000087603 http://www.gnn.com.br/forum/showthread.php?t=1000087602 http://www.gnn.com.br/forum/showthread.php?t=1000087601 http://www.gnn.com.br/forum/showthread.php?t=1000087600 http://www.gnn.com.br/forum/showthread.php?t=1000087599 http://www.gnn.com.br/forum/showthread.php?t=1000087598 http://www.gnn.com.br/forum/showthread.php?t=1000087597 http://www.gnn.com.br/forum/showthread.php?t=1000087596 http://www.gnn.com.br/forum/showthread.php?t=1000087595 http://www.gnn.com.br/forum/showthread.php?t=1000087592 http://www.gnn.com.br/forum/showthread.php?t=1000087591 http://www.gnn.com.br/forum/showthread.php?t=1000087590 http://www.gnn.com.br/forum/showthread.php?t=1000087588 http://www.gnn.com.br/forum/showthread.php?t=1000087587 http://www.gnn.com.br/forum/showthread.php?t=1000087586 http://www.gnn.com.br/forum/showthread.php?t=1000087585 http://www.gnn.com.br/forum/showthread.php?t=1000087584 http://www.gnn.com.br/forum/showthread.php?t=1000087583 http://www.gnn.com.br/forum/showthread.php?t=1000087582 http://www.gnn.com.br/forum/showthread.php?t=1000087581 http://www.gnn.com.br/forum/showthread.php?t=1000087579 http://www.gnn.com.br/forum/showthread.php?t=1000087578 http://www.gnn.com.br/forum/showthread.php?t=1000087577 http://www.gnn.com.br/forum/showthread.php?t=1000087575 http://www.gnn.com.br/forum/showthread.php?t=1000087574 http://www.gnn.com.br/forum/showthread.php?t=1000087573 http://www.gnn.com.br/forum/showthread.php?t=1000087572 http://www.gnn.com.br/forum/showthread.php?t=1000087571 http://www.gnn.com.br/forum/showthread.php?t=1000087570 http://www.gnn.com.br/forum/showthread.php?t=1000087569 http://www.gnn.com.br/forum/showthread.php?t=1000087568 http://www.gnn.com.br/forum/showthread.php?t=1000087567 http://www.gnn.com.br/forum/showthread.php?t=1000087565 http://www.gnn.com.br/forum/showthread.php?t=1000087564 http://www.gnn.com.br/forum/showthread.php?t=1000087561 http://www.gnn.com.br/forum/showthread.php?t=1000087559 http://www.gnn.com.br/forum/showthread.php?t=1000087558 http://www.gnn.com.br/forum/showthread.php?t=1000087557 http://www.gnn.com.br/forum/showthread.php?t=1000087556 http://www.gnn.com.br/forum/showthread.php?t=1000087555 payne (JIRA 2008-09-18T02:08:25 http://comments.gmane.org/gmane.comp.apache.shale.issues/1520 MockHttpServletResponse throws UnsupportedOperationException for setContentLength method ---------------------------------------------------------------------------------------- Key: SHALE-495 URL: https://issues.apache.org/struts/browse/SHALE-495 Project: Shale Issue Type: Bug Components: Test Affects Versions: 1.0.5 Reporter: Nick Belaevski org.apache.shale.test.mock.MockHttpServletResponse#setContentLength(int) throws UnsupportedOperationException. We need this method to be implemented because some application servers (e.g. Weblogic 10.3) seem to ignore "Content-Length" header and consider only the value from ServletResponse object. So we call this method in our framework and unit tests and they fail now. Nick Belaevski (JIRA 2008-09-12T13:51:25 http://comments.gmane.org/gmane.comp.apache.shale.issues/1518 WebResourceProcessor getResourceURL throws and catches NPE ---------------------------------------------------------- Key: SHALE-494 URL: https://issues.apache.org/struts/browse/SHALE-494 Project: Shale Issue Type: Bug Components: Remoting Affects Versions: 1.0.4 Environment: WinXP, glassfish v2ur1 Reporter: David Cooke Priority: Minor In the try catch block where the resource ID is converted to a URL using reflection, the code looks to see if debug logging is enabled in order to log the conversion. However, log is null at this point, causing an NPE which is caught in the surrounding try/catch (there for reflection exceptions). It is then logged as a resource exception, and null is returned. This seconds set of logging uses the log() private method which assigns to the variable log. if (log.isDebugEnabled()) { log.debug("getResource(" + resourceId + ") --> " + url); } should be if (log().isDebugEnabled()) { log().debug("getResource(" + resourceId + ") --> " + url); } David Cooke (JIRA 2008-06-06T14:44:06 http://comments.gmane.org/gmane.comp.apache.shale.issues/1511 Upgrade to Commons Chain 1.2 ---------------------------- Key: SHALE-493 URL: https://issues.apache.org/struts/browse/SHALE-493 Project: Shale Issue Type: Task Reporter: Niall Pemberton Priority: Minor Commons Chain 1.2 is a bug-fix release[1] and IMO is worth upgrading for the CHAIN-33 issue[2] which a Struts user experienced recently - see STR-3143. I also noticed Shale depends on Commons Logging 1.1, rather than latest 1.1.1 release[3] [1] http://commons.apache.org/chain/changes-report.html [2] http://issues.apache.org/jira/browse/CHAIN-33 [3] http://commons.apache.org/logging/commons-logging-1.1.1/RELEASE-NOTES.txt Niall Pemberton (JIRA 2008-06-02T13:36:05 http://comments.gmane.org/gmane.comp.apache.shale.issues/1508 jsfri profile will not build ---------------------------- Key: SHALE-492 URL: https://issues.apache.org/struts/browse/SHALE-492 Project: Shale Issue Type: Bug Components: Examples Affects Versions: 1.0.5, 1.0.6-SNAPSHOT Reporter: Greg Reddin Fix For: 1.0.6-SNAPSHOT When using the jsfri profile to build the example apps the build will fail because of missing dependencies. The missing deps are a direct dependency on javax.servlet.jsp:jsp-api:jar:1.2 and a transitive dependency on javax.servlet.jsp.jstl:jstl:jar:1.1 Greg Reddin (JIRA 2008-05-29T16:28:05 http://comments.gmane.org/gmane.comp.apache.shale.issues/1507 MyFaces profile won't build --------------------------- Key: SHALE-491 URL: https://issues.apache.org/struts/browse/SHALE-491 Project: Shale Issue Type: Bug Components: Examples Affects Versions: 1.0.5 Reporter: Greg Reddin Assignee: Greg Reddin Fix For: 1.0.5 Example apps won't build when using myfaces profile. The reason is due to missing servlet API dependencies. In the process of fixing this we should also upgrade the MyFaces dependencies from 1.1.4 to 1.1.5. Greg Reddin (JIRA 2008-05-29T15:58:06 http://comments.gmane.org/gmane.comp.apache.shale.issues/1497 Want alternative ways of informing user of validation failure ------------------------------------------------------------- Key: SHALE-490 URL: https://issues.apache.org/struts/browse/SHALE-490 Project: Shale Issue Type: Improvement Components: Validator Affects Versions: 1.0.4 Environment: Any Reporter: Jeff Tsay I'd like to see the ability to override the validation error handler. Currently, with the default validatorUtilities.js, whenever a validation error occurs, an alert is displayed. To me that is a bit unpolished; I'd rather see some message below the input field that has an error. Although it's easy enough to replace validatorUtilities.js, jcv_handleError() simply doesn't get enough information in its arguments to do much with the DOM tree, unless the ID's of the elements to replace are hardcoded. It would be good also to let the user supply his own error handling script in the JSF tags, instead of messing with replacing validatorUtilities (which would be apply across the entire web app anyway). Any ideas on how to do this? Is anyone else interested in getting rid of alert()? Jeff Tsay (JIRA 2008-04-20T08:42:05 http://comments.gmane.org/gmane.comp.apache.shale.issues/1496 Default validator configuration should not override user specified configuration --------------------------------------------------------------------------------- Key: SHALE-489 URL: https://issues.apache.org/struts/browse/SHALE-489 Project: Shale Issue Type: Improvement Components: Validator Affects Versions: 1.0.4 Environment: Any Reporter: Jeff Tsay Priority: Minor It seems strange the way that configuration rules are loaded. If the default configuration file is not found, the validator lifecycle listener will add the default configuration file to the end of a url list. However, since the list is processed in forward order, that means if you leave out the default configuration file, any settings you have in your own file will be overwritten by the default. That means you need to explicitly put the default configuration file in your org.apache.shale.validator.VALIDATOR_RULES list before your own files. Since I think it makes more sense to have your specified configuration files override the default settings, I propose the following change in ValidatorLifeCycleListener: private ValidatorResources validatorResources(ServletContext context) throws IOException, SAXException { // Process the explicitly configured resources (if any) // jtsay // Since we want to add to the beginning later, use a linked list // ArrayList urls = new ArrayList() LinkedList urls = new LinkedList(); ... // Process the default configuration resources (if not already loaded) if (!didDefault) { try { url = context.getResource(Globals.DEFAULT_VALIDATOR_RULES); } catch (MalformedURLException e) { throw new IllegalArgumentException("MalformedURLException:" + " The URL '" + Globals.DEFAULT_VALIDATOR_RULES + "' specified as a validator rules resource is malformed."); } if (url == null) { url = ValidatorLifecycleListener.class.getResource(Globals.DEFAULT_VALIDATOR_RULES); } if (url == null) { throw new IllegalArgumentException(Globals.DEFAULT_VALIDATOR_RULES); } // jtsay // Add to beginning of list so that explicit resources override // default, not the other way around. urls.addFirst(url); } Also below, there is some code to iterate over all elements in the list. Since the list is now a LinkedList it is not efficient to iterate using an array index. So the replaced code should like this: int i = 0; for (Iterator it = urls.iterator(); it.hasNext(); i++) { array[i] = ((URL) it.next()).toExternalForm(); } Jeff Tsay (JIRA 2008-04-20T08:40:05 http://comments.gmane.org/gmane.comp.apache.shale.issues/1495 Script contents should be enclosed in CDATA section for XML documents --------------------------------------------------------------------- Key: SHALE-488 URL: https://issues.apache.org/struts/browse/SHALE-488 Project: Shale Issue Type: Improvement Components: Validator Affects Versions: 1.0.4 Environment: XML content types, including XHTML Reporter: Jeff Tsay When the validator script gets rendered, it outputs raw Javascript inside the <script> tags. The Javascript includes characters like & which need to be escaped or in a CDATA section in XML. For XUL or XHTML, this is a problem. I guess that XHTML parsers are more lenient about this so that's why the problem never showed up? Anyway the fix, which was also suggested by Gary VanMatre, was to enclose the script contents in an XML CDATA section. So in src/main/java/org/apache/shale/validator/faces/ValidatorScript.java I have: private void writeScriptStart(ResponseWriter writer) throws IOException { writer.startElement("script", this); writer.writeAttribute("type", "text/javascript", null); writer.writeAttribute("language", "Javascript1.1", null); writer.write("\n"); // jtsay added // Enclose XML in CDATA so special characters can be used without escaping. if (!"text/html".equals(writer.getContentType())) { writer.write("<![CDATA[\n"); } } and private void writeScriptEnd(ResponseWriter writer) throws IOException { // jtsay added if (!"text/html".equals(writer.getContentType())) { writer.write("\n]]>\n"); } writer.write("\n"); writer.endElement("script"); } This assumes if we are not rendering text/html, we must be rendering some sort of XML. Sound reasonable? Jeff Tsay (JIRA 2008-04-20T08:38:05 http://comments.gmane.org/gmane.comp.apache.shale.issues/1494 Update Master POM's Plugin Management ------------------------------------- Key: SHALE-487 URL: https://issues.apache.org/struts/browse/SHALE-487 Project: Shale Issue Type: Improvement Affects Versions: 1.0.5-SNAPSHOT Reporter: Greg Reddin Assignee: Greg Reddin Priority: Critical The Master POM needs to be configured to prevent site-deployment. This requires the following three things. 1) Lock plugins in master pom's <pluginManagement> 2) For release plugin in (1) have this: <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-release-plugin</artifactId> <version>2.0-beta-7</version> <configuration> <goals>deploy</goals> </configuration> </plugin> 3) Override release plugin (to permit default configuration including site deploys) in parent pom's <pluginManagement>. Greg Reddin (JIRA 2008-04-18T15:22:05 http://comments.gmane.org/gmane.comp.apache.shale.issues/1484 Validator Tests are failing due to errors in the properties files. ------------------------------------------------------------------ Key: SHALE-486 URL: https://issues.apache.org/struts/browse/SHALE-486 Project: Shale Issue Type: Bug Components: Validator Affects Versions: 1.0.5-SNAPSHOT Reporter: Greg Reddin Assignee: Greg Reddin Fix For: 1.0.5-SNAPSHOT Th AbstractConverterTestCase and AbstractValidatorTestCase both reference the "errors.long" property but the TestBundle.properties file contains a property called "errors.Long". Also, these tests are invalid because they reference properties that are supposed to be overridden by the application but neither of the properties "errors.long" and "errors.integer" are found in the default bundle. The fix is simply to change the properties being referenced to something that is found in the default bundle. Greg Reddin (JIRA 2008-03-20T21:12:58 http://comments.gmane.org/gmane.comp.apache.shale.issues/1476 ResourceBundle lookup failure in MockApplication12 -------------------------------------------------- Key: SHALE-485 URL: https://issues.apache.org/struts/browse/SHALE-485 Project: Shale Issue Type: Bug Components: Test Affects Versions: 1.0.4 Environment: Java 5, JSF 1.2, i686 GNU/Linux Reporter: Tim Kroeger MockApplication12.getResourceBundle(FacesContext context, String name) is intended to lookup the resource bundle's base name prior to requesting the resource via ResourceBundle.getBundle(name, locale). In the current implementation it tries to lookup the name of the resource registered with the application, which is wrong. Consider a resource bundle added via ResourceBundle bundle = ResourceBundle.getBundle("foo.bar.resource", new Locale("de", "DE")); ((MockApplication12) application).addResourceBundle("fooBarResource", bundle); and e.g. a validator you want to test which composes a new localized FacesMessage by doing context.getApplication().getResourceBundle(context, "fooBarResource").getString("message"); which simulates what would happen in an application where you configured your resource bundles via faces-config.xml. This will throw a MissingResourceException since public ResourceBundle getResourceBundle(FacesContext context, String name) { if ((context == null) || (name == null)) { throw new NullPointerException(); } Locale locale = null; UIViewRoot viewRoot = context.getViewRoot(); if (viewRoot != null) { locale = viewRoot.getLocale(); } if (locale == null) { locale = Locale.getDefault(); } return ResourceBundle.getBundle(name, locale); } tries to lookup "fooBarResource" with it's classLoader. Instead of that, one should either do something like: public ResourceBundle getResourceBundle(FacesContext context, String name) { if ((context == null) || (name == null)) { throw new NullPointerException(); } if (!bundles.containsKey(name)) { return null; } Locale locale = null; UIViewRoot viewRoot = context.getViewRoot(); if (viewRoot != null) { locale = viewRoot.getLocale(); } if (locale == null) { locale = Locale.getDefault(); } return bundles.get(name); } which completely drops any locale context but at least returns a resource bundle, that was added with the corresponding key OR one could go ahead and implement a solution, where only the mapping 'name -> baseName' is stored in a map instead of mappings to ResourceBundles, so MockApplication12.getResourceBundle can lookup the baseName via the provided name parameter as key to the bundles Map property and then utilize ResourceBundle.getBundle() to lookup the bundle with the desired locale. That at least is, what Sun does in it's com.sun.faces.application.ApplicationAssociate which is used by com.sun.faces.application.ApplicationImpl. Tim Kroeger (JIRA 2008-03-12T10:26:09 http://comments.gmane.org/gmane.comp.apache.shale.issues/1475 Jmock update to 2.x ------------------- Key: SHALE-484 URL: https://issues.apache.org/struts/browse/SHALE-484 Project: Shale Issue Type: Improvement Components: Test Reporter: Matthias Wessendorf Assignee: Matthias Wessendorf update the test to JMock 2.x Matthias Wessendorf (JIRA 2008-02-07T17:24:40 http://comments.gmane.org/gmane.comp.apache.shale.issues/1473 Remove Shale-Tiles ------------------ Key: SHALE-483 URL: https://issues.apache.org/struts/browse/SHALE-483 Project: Shale Issue Type: Task Components: Tiles Affects Versions: 1.0.5-SNAPSHOT Reporter: Greg Reddin Fix For: 1.0.5-SNAPSHOT The Shale developers have decided that support for Shale-Tiles is no longer needed since the MyFaces Tomahawk project has a working version of a Tiles 2 view handler and since Shale-Tiles has been holding up a Shale release for some time and has little developer support behind it. The removal of Shale-Tiles really just involves changing the POM files to remove the Tiles component. I assume we will leave the component in svn for the time being. Greg Reddin (JIRA 2008-02-06T19:43:40 http://comments.gmane.org/gmane.comp.apache.shale.issues/1471 Enhance MockLifecycle's execute() and render() ---------------------------------------------- Key: SHALE-482 URL: https://issues.apache.org/struts/browse/SHALE-482 Project: Shale Issue Type: Improvement Components: Test Affects Versions: 1.1.0-SNAPSHOT Reporter: Matthias Wessendorf Assignee: Matthias Wessendorf The execute() and render() method do nothing (just throwing not-supported execption). A "real" lifecycle would be nice. I'll use the MyFaces IMPL of the lifecycle as the base for the MockLifecycle. This lifecycle testing env. would allow testing of other JSF bits, like PhaseListeners. Matthias Wessendorf (JIRA 2008-01-11T18:34:05 http://comments.gmane.org/gmane.comp.apache.shale.issues/1469 Nullpointer exception when validator resources loaded from the custom configuration file in 1.0.4 ------------------------------------------------------------------------------------------------- Key: SHALE-481 URL: https://issues.apache.org/struts/browse/SHALE-481 Project: Shale Issue Type: Bug Components: Validator Affects Versions: 1.0.4 Environment: Windows Xp Sp2, Jdk 1.5, Tomcat 5.5, shale 1.0.4 Reporter: ankit kakkar The server is throwing nullpointer exception whenever it tries to load rules from custom rule xml file. java.lang.NullPointerException at org.apache.shale.validator.CommonsValidator.getValidatorAction(CommonsValidator.java:730) at org.apache.shale.validator.faces.ValidatorScript.writeValidationFunctions(ValidatorScript.java:424) at org.apache.shale.validator.faces.ValidatorScript.encodeBegin(ValidatorScript.java:652) at javax.faces.webapp.UIComponentTag.encodeBegin(UIComponentTag.java:584) at javax.faces.webapp.UIComponentTag.doStartTag(UIComponentTag.java:471) at org.apache.jsp.greeting_jsp._jspx_meth_s_005fvalidatorScript_005f0(greeting_jsp.java:319) at org.apache.jsp.greeting_jsp._jspx_meth_h_005fform_005f0(greeting_jsp.java:173) at org.apache.jsp.greeting_jsp._jspx_meth_f_005fview_005f0(greeting_jsp.java:115) at org.apache.jsp.greeting_jsp._jspService(greeting_jsp.java:80) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:98) at javax.servlet.http.HttpServlet.service(HttpServlet.java:803) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:328) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:315) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:265) at javax.servlet.http.HttpServlet.service(HttpServlet.java:803) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:269) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:691) at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:469) at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:403) at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:301) at com.sun.faces.context.ExternalContextImpl.dispatch(ExternalContextImpl.java:322) at com.sun.faces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:147) at org.apache.shale.validator.faces.ValidatorViewHandler.renderView(ValidatorViewHandler.java:130) at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:87) at com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:200) at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:117) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:198) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:269) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:210) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:174) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:433) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:151) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:870) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:665) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:528) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:81) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:685) at java.lang.Thread.run(Thread.java:595) Jan 4, 2008 4:53:50 PM org.apache.catalina.core.StandardWrapperValve invoke SEVERE: Servlet.service() for servlet Faces Servlet threw exception When I analyzed this issue, I found that there is a bit of code missing which was handling the null case and was loading the customer validation xml file from the web.xml of the application. I am pasting the relevent function from the latest version ie 1.0.4 package org.apache.shale.validator; /** * <p>Return the validator resources that were configured and cached * at application startup time.</p> */ private static ValidatorResources getValidatorResources() { FacesContext context = FacesContext.getCurrentInstance(); ExternalContext external = context.getExternalContext(); Map applicationMap = external.getApplicationMap(); return (ValidatorResources) applicationMap.get(Globals.VALIDATOR_RESOURCES); } Now I am pasting the same function from the previous version. I noticed this on the http://shale.apache.org/shale-core/xref/org/apache/shale/validator/CommonsValidator.html url. /*** 461 * This method lazily configures validator resources by reading either 462 * the default <code>validalidator-rules.xml</code> file in 463 * shale-core.jar or the list of resources configured using the init 464 * param <code>org.apache.shale.validator.VALIDATOR_RULES</code>. 465 * 466 * < at >return validator resources loaded from the configuration file. 467 */ 468 private static ValidatorResources getValidatorResources() { 469 final String VALIDATOR_RESOURCES_KEY = 470 "org.apache.shale.validator.resources"; 471 FacesContext context = FacesContext.getCurrentInstance(); 472 ExternalContext external = context.getExternalContext(); 473 Map applicationMap = external.getApplicationMap(); 474 ValidatorResources validatorResources 475 = (ValidatorResources) applicationMap.get(VALIDATOR_RESOURCES_KEY); 476 if (validatorResources == null) { 477 try { 478 String pathnames = external.getInitParameter(Globals.VALIDATOR_RULES); 479 if (pathnames == null || pathnames.length() <= 0) { 480 pathnames = Globals.DEFAULT_VALIDATOR_RULES; 481 } 482 StringTokenizer st = new StringTokenizer(pathnames, ","); 483 List urlList = new ArrayList(); 484 while (st.hasMoreTokens()) { 485 String validatorRules = st.nextToken().trim(); 486 logger.log(Level.INFO, 487 messages.getMessage("commonsValidator.loadresource", 488 new Object[] {validatorRules})); 489 URL input = external.getResource(validatorRules); 490 if (input == null) { 491 input = CommonsValidator.class.getResource(validatorRules); 492 } 493 if (input != null) { 494 urlList.add(input); 495 } else { 496 logger.log(Level.WARNING, 497 messages.getMessage("commonsValidator.skipresource", 498 new Object[] {validatorRules})); 499 } 500 } 501 int urlSize = urlList.size(); 502 String[] urlArray = new String[urlSize]; 503 for (int urlIndex = 0; urlIndex < urlSize; urlIndex++) { 504 URL url = (URL) urlList.get(urlIndex); 505 urlArray[urlIndex] = url.toExternalForm(); 506 } 507 validatorResources = new ValidatorResources(urlArray); 508 applicationMap.put(VALIDATOR_RESOURCES_KEY, validatorResources); 509 } catch (IOException ex) { 510 logger.log(Level.SEVERE, messages.getMessage("commonsValidator.loaderror"), ex); 511 return null; 512 } catch (SAXException ex) { 513 logger.log(Level.SEVERE, messages.getMessage("commonsValidator.loaderror"), ex); 514 return null; 515 } 516 } 517 518 return validatorResources; 519 } You yourself can see here that validatorResources is checked for null in the second case but it has been returned directly from the latest version implementation. Pls look into the same asap and if now there is some alternate way of doing this thing, then do let me know. thanks and regards, ankit kakkar ankit kakkar (JIRA 2008-01-04T11:32:04 http://comments.gmane.org/gmane.comp.apache.shale.issues/1468 ValidatorScript component : NullPointerException while resolving functionName ----------------------------------------------------------------------------- Key: SHALE-480 URL: https://issues.apache.org/struts/browse/SHALE-480 Project: Shale Issue Type: Bug Components: Validator Reporter: Guillaume Serre Priority: Trivial The writeValidationFunctions method should use getFunctionName() instead of using the "functionName" attribute directly. This is minor, but allows easier overloading. StringBuffer buff = new StringBuffer(); buff.append("var bCancel = false;\n") .append("function ") // the following line is changed .append( getFunctionName() ).append("(form) {\n") .append("\tvar bValid = true;\n") .append("\tvar sFormName = jcv_retrieveFormName(form);\n"); Sorry I can make a diff from here because of a dumb proxy. Guillaume Serre (JIRA 2007-12-06T17:25:33 http://comments.gmane.org/gmane.comp.apache.shale.issues/1466 Shale Validator is Unable to resolve JSF Expression Language for the first time ------------------------------------------------------------------------------- Key: SHALE-479 URL: https://issues.apache.org/struts/browse/SHALE-479 Project: Shale Issue Type: Bug Components: Validator Affects Versions: 1.0.4 Environment: JDK15. with Tomcat5, Windows XP Reporter: Sarwesh Saurabh Shale validator is unable to resolve the JSF Expression language for the first click and after then it works properly. For example for the below code snippet in a jsf file <f:loadBundle basename="crud_bundle" var="myCrudBundle"/> ...... <h:inputText id="text_1" value="" size="15" styleClass="input"> <s:commonsValidator type="integer" arg="#{myCrudBundle.headerColumnId}" server="true" /> </h:inputText> The validator is not able to resolve #{myCrudBundle.headerColumnId} on first submission. crud_bundle.properties is present in classpath and the key is defined as headerColumnId = ID For first submission I get following error null - must be an integer. and once I refresh this, The error shown is proper ID - must be an integer. How ever If I change the arg="#{myCrudBundle.headerColumnId}" to arg="ID" in the above validation tag, It works properly. If required full code can be provided. Please let me know If this issue is fixed in any later version or going to be fixed in any upcoming version. Thanks. Sarwesh Saurabh (JIRA 2007-12-04T12:45:34 http://comments.gmane.org/gmane.comp.apache.shale.issues/1464 Add MarkMail archives to shale-master ------------------------------------- Key: SHALE-478 URL: https://issues.apache.org/struts/browse/SHALE-478 Project: Shale Issue Type: Improvement Affects Versions: 1.0.4 Reporter: Rahul Akolkar Assignee: Rahul Akolkar Fix For: 1.0.5-SNAPSHOT, 1.1.0-SNAPSHOT Requested by Jason Hunter. I often use these archives: http://shale.markmail.org/ Rahul Akolkar (JIRA 2007-11-30T21:31:33 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.apache.shale.issues