[jira] Updated: (SHALE-287) Faulty behavior of the "token" component with Apache MyFaces >1.1.1
[ http://issues.apache.org/struts/browse/SHALE-287?page=all ] Craig McClanahan updated SHALE-287: --- Attachment: shale-test-core.war I've completed a test app which (I believe) illustrates that the current trunk code of Shale operates as expected. In particular, you should expect the following behavior when using the token component: * If you submit invalid data (per validator rules) and get back the same page with error messages, you should be able to correct the errors and submit the form (exactly once with correct data). * If you submit the form successfully, and then use the browser back button and then submit the same form again, you should get the "double submit" error message. The attached "shale-test-core.war" application uses the current version of MyFaces (1.1.4), and (as far as I can tell) operates correctly in all use cases. PLEASE try this application yourself and see if you can break it. The comments on the app's pages should be pretty self explanatory. > Faulty behavior of the "token" component with Apache MyFaces >1.1.1 > --- > > Key: SHALE-287 > URL: http://issues.apache.org/struts/browse/SHALE-287 > Project: Shale > Issue Type: Bug > Components: Core > Environment: OS: Microsoft Windows XP SP2 > Servlet Container: jakarta-tomcat-5.5.9 >Reporter: Mike Meessen > Assigned To: Craig McClanahan > Attachments: shale-test-core.war, ShaleIssueDemo.zip > > > This issue appears when using Apache MyFaces as of version 1.1.2. The MyFaces > project states the following about their 1.1.2 release: > [Quote] > This is the first official release of what we are now calling the "core." The > core refers to the JSF 1.1 implementation as specified by JSR-127. It has > passed Sun's TCK and is considered to be 100% compliant with the spec. > [/Quote] > So as a conclusion, I think everyone who's still using MyFaces 1.1.1 should > hurry upgrading his code to be 1.1.2 compliant. > Allthough Shale should be JSF-implementation-independant, it seems this issue > appears or not depending on the used MyFaces version. > Steps to reproduce the issue: > * Use a simple JSF submission form to which you add Shale's Token tag to > check for illegal form resubmissions. > * As long as you submit the form correctly, everyting works fine. > * Press F5 (page refresh) once, the browser warns about HTTP POST data > resubmission. > * Discard the warning and go on resending the same HTTP request. > * Shale recognizes the resubmission and acts correctly (no application logic > gets invoked). > This is the part where the behavior changes according to what MyFaces > version is used: > With MyFaces 1.1.1 > -- > * Resubmit the form correctly (using the submit button). > ==> The workflow goes on and the form is correctly submitted. > With MyFaces 1.1.2 and above > - > * Resubmit the form correctly (using the submit button). > ==> Nothing happens. No new token is generated, so no application logic gets > invoked and the workflow stucks. > I attached a sample project which demoes the issue. > -- EDIT: > I forgot to mention that with both MyFaces versions, I set the context-param > "org.apache.myfaces.ALLOW_JAVASCRIPT" to false. In theory, this shouldn't > make a difference since I'm using HTTP POST just as the javascript would do, > but I think it's worth the hint. > Regards, > Mike -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SHALE-325) Add a custom validation example to the Use Cases example app
[ http://issues.apache.org/struts/browse/SHALE-325?page=comments#action_38607 ] Rahul Akolkar commented on SHALE-325: - Try again, it works for me. And adding should, since the method in question looks up the application's message bundle for the "msg" attribute of (in this case, the custom) . The "message" attribute of gets priority, if present (which is nice, since it allows to change the "default" error message for the custom, or "built-in", validator). On a separate note, we could do better than an NPE here, let me take a stab at that. > Add a custom validation example to the Use Cases example app > > > Key: SHALE-325 > URL: http://issues.apache.org/struts/browse/SHALE-325 > Project: Shale > Issue Type: Improvement > Components: Validator >Reporter: Wendy Smoak >Priority: Minor > Fix For: 1.0.4-SNAPSHOT > > > Add an example of using a custom validator to the Commons Validator > Integration section of the use-cases example app. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SHALE-287) Faulty behavior of the "token" component with Apache MyFaces >1.1.1
[ http://issues.apache.org/struts/browse/SHALE-287?page=comments#action_38606 ] Craig McClanahan commented on SHALE-287: > Hi! I've downloaded the Token source code from the repository and make myself > a test project. > I have the following page.jsp with source code Adrian, Just to verify things, did you build all of Shale from the current trunk source code, and use it in your test, or were you using some modules from the 1.0.3 release? This matters, because 1.0.3 did have the bug you describe, but it was subsequently fixed. So, building from the trunk source (or using a recent nightly build) should *not* have this particular error. To verify this, I just checked in a new test application (shale-test-core) that verifies proper behavior. Among other things, it tries the scenario you describe ... submit a form (with the token) with input data that fails validation, and then resubmits the form with valid data. One other important note -- for the component to work correctly, it must be the *last* input component inside the form. This is because it needs to detect whether any of the other components have fired a validation error, in order to know whether or not to reset the token. Your test case has the token component first instead of last. > Faulty behavior of the "token" component with Apache MyFaces >1.1.1 > --- > > Key: SHALE-287 > URL: http://issues.apache.org/struts/browse/SHALE-287 > Project: Shale > Issue Type: Bug > Components: Core > Environment: OS: Microsoft Windows XP SP2 > Servlet Container: jakarta-tomcat-5.5.9 >Reporter: Mike Meessen > Assigned To: Craig McClanahan > Attachments: ShaleIssueDemo.zip > > > This issue appears when using Apache MyFaces as of version 1.1.2. The MyFaces > project states the following about their 1.1.2 release: > [Quote] > This is the first official release of what we are now calling the "core." The > core refers to the JSF 1.1 implementation as specified by JSR-127. It has > passed Sun's TCK and is considered to be 100% compliant with the spec. > [/Quote] > So as a conclusion, I think everyone who's still using MyFaces 1.1.1 should > hurry upgrading his code to be 1.1.2 compliant. > Allthough Shale should be JSF-implementation-independant, it seems this issue > appears or not depending on the used MyFaces version. > Steps to reproduce the issue: > * Use a simple JSF submission form to which you add Shale's Token tag to > check for illegal form resubmissions. > * As long as you submit the form correctly, everyting works fine. > * Press F5 (page refresh) once, the browser warns about HTTP POST data > resubmission. > * Discard the warning and go on resending the same HTTP request. > * Shale recognizes the resubmission and acts correctly (no application logic > gets invoked). > This is the part where the behavior changes according to what MyFaces > version is used: > With MyFaces 1.1.1 > -- > * Resubmit the form correctly (using the submit button). > ==> The workflow goes on and the form is correctly submitted. > With MyFaces 1.1.2 and above > - > * Resubmit the form correctly (using the submit button). > ==> Nothing happens. No new token is generated, so no application logic gets > invoked and the workflow stucks. > I attached a sample project which demoes the issue. > -- EDIT: > I forgot to mention that with both MyFaces versions, I set the context-param > "org.apache.myfaces.ALLOW_JAVASCRIPT" to false. In theory, this shouldn't > make a difference since I'm using HTTP POST just as the javascript would do, > but I think it's worth the hint. > Regards, > Mike -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SHALE-325) Add a custom validation example to the Use Cases example app
[ http://issues.apache.org/struts/browse/SHALE-325?page=comments#action_38605 ] Wendy Smoak commented on SHALE-325: --- The error message key is specified in the rule itself, in custom-rules.xml. There is no tag in faces-config, and adding it didn't help. The attribute for val:commonsValidator is 'message' (not msg). Adding that fixes the NPE, but see above-- the message is specified in the rule, I shouldn't have to say it again. What do I need to do so that CommonsValidator.getErrorMessage can "see" the resource bundle? > Add a custom validation example to the Use Cases example app > > > Key: SHALE-325 > URL: http://issues.apache.org/struts/browse/SHALE-325 > Project: Shale > Issue Type: Improvement > Components: Validator >Reporter: Wendy Smoak >Priority: Minor > Fix For: 1.0.4-SNAPSHOT > > > Add an example of using a custom validator to the Commons Validator > Integration section of the use-cases example app. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SHALE-67) Clay examples from usecases demo output Sun's state field marker
[ http://issues.apache.org/struts/browse/SHALE-67?page=comments#action_38604 ] Gary VanMatre commented on SHALE-67: 6) Added attribute "binding" support for Converters, Validators and Listeners - new feature added to 1.2 spec. 7) Under the new RI JSF version, the form state marker has changed. Added logic to look for yet another state marker? "com.sun.faces.saveStateFieldMarker" - RI 1.1 "" - myfaces 1.1.x "~com.sun.faces.saveStateFieldMarker~" - RI 1.2 > Clay examples from usecases demo output Sun's state field marker > > > Key: SHALE-67 > URL: http://issues.apache.org/struts/browse/SHALE-67 > Project: Shale > Issue Type: Bug > Components: Clay > Environment: Operating System: All > Platform: All >Reporter: Ryan Lubke > > When testing the following Clay examples from the shale-usecases example > application: > Symbols - pages 1, 2, and 3 > Full HTML View > Extreme HTML View > Full XML View > I see, at the end of the page, 'com.sun.faces.saveState.FieldMarker'. > I don't see this when running the Clay JSP view. > To reproduce: Deploy the shale-usecases application to a nightly build of > GlassFish and run one of the examples mentioned above. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SHALE-325) Add a custom validation example to the Use Cases example app
[ http://issues.apache.org/struts/browse/SHALE-325?page=comments#action_38603 ] Gary VanMatre commented on SHALE-325: - I think your problem is that the CommonsValidator can't find the message. There are a couple of places that you can register a custom message. You can load the resource bundle within the page and use the msg attribute. -- or --- Register the resource bundle in the faces-config.xml en en fr de es org.apache.shale.usecases.view.Bundle > Add a custom validation example to the Use Cases example app > > > Key: SHALE-325 > URL: http://issues.apache.org/struts/browse/SHALE-325 > Project: Shale > Issue Type: Improvement > Components: Validator >Reporter: Wendy Smoak >Priority: Minor > Fix For: 1.0.4-SNAPSHOT > > > Add an example of using a custom validator to the Commons Validator > Integration section of the use-cases example app. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SHALE-287) Faulty behavior of the "token" component with Apache MyFaces >1.1.1
[
http://issues.apache.org/struts/browse/SHALE-287?page=comments#action_38602 ]
Adrian Mitev commented on SHALE-287:
Hi! I've downloaded the Token source code from the repository and make myself a
test project. I have the following:
page.jsp with source code:
When i submit the page without any value inputted i get validation error and
the page is redisplayed. I input value in the input field and submit the form
again, then i got error message from the token - "double submit".
I've debugged a little bit and saw that when validation error occurred and the
page is redisplayed the token value was not changed (no new token is generated):
Check the class: org.apache.shale.component.Token, method: public String
getToken() the code
if (value != null) {
return value;
}
This condition is always true after the page is rendered for the first time.
> Faulty behavior of the "token" component with Apache MyFaces >1.1.1
> ---
>
> Key: SHALE-287
> URL: http://issues.apache.org/struts/browse/SHALE-287
> Project: Shale
> Issue Type: Bug
> Components: Core
> Environment: OS: Microsoft Windows XP SP2
> Servlet Container: jakarta-tomcat-5.5.9
>Reporter: Mike Meessen
> Assigned To: Craig McClanahan
> Attachments: ShaleIssueDemo.zip
>
>
> This issue appears when using Apache MyFaces as of version 1.1.2. The MyFaces
> project states the following about their 1.1.2 release:
> [Quote]
> This is the first official release of what we are now calling the "core." The
> core refers to the JSF 1.1 implementation as specified by JSR-127. It has
> passed Sun's TCK and is considered to be 100% compliant with the spec.
> [/Quote]
> So as a conclusion, I think everyone who's still using MyFaces 1.1.1 should
> hurry upgrading his code to be 1.1.2 compliant.
> Allthough Shale should be JSF-implementation-independant, it seems this issue
> appears or not depending on the used MyFaces version.
> Steps to reproduce the issue:
> * Use a simple JSF submission form to which you add Shale's Token tag to
> check for illegal form resubmissions.
> * As long as you submit the form correctly, everyting works fine.
> * Press F5 (page refresh) once, the browser warns about HTTP POST data
> resubmission.
> * Discard the warning and go on resending the same HTTP request.
> * Shale recognizes the resubmission and acts correctly (no application logic
> gets invoked).
> This is the part where the behavior changes according to what MyFaces
> version is used:
> With MyFaces 1.1.1
> --
> * Resubmit the form correctly (using the submit button).
> ==> The workflow goes on and the form is correctly submitted.
> With MyFaces 1.1.2 and above
> -
> * Resubmit the form correctly (using the submit button).
> ==> Nothing happens. No new token is generated, so no application logic gets
> invoked and the workflow stucks.
> I attached a sample project which demoes the issue.
> -- EDIT:
> I forgot to mention that with both MyFaces versions, I set the context-param
> "org.apache.myfaces.ALLOW_JAVASCRIPT" to false. In theory, this shouldn't
> make a difference since I'm using HTTP POST just as the javascript would do,
> but I think it's worth the hint.
> Regards,
> Mike
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SHALE-325) Add a custom validation example to the Use Cases example app
[ http://issues.apache.org/struts/browse/SHALE-325?page=comments#action_38601 ] Wendy Smoak commented on SHALE-325: --- See: http://svn.apache.org/viewvc?view=rev&rev=471907 This is incomplete. I added a third section on the 'Commons Validator Integration' page. If you enter an odd number for 'Priority', you get: java.lang.NullPointerException java.text.MessageFormat.applyPattern(MessageFormat.java:414) java.text.MessageFormat.(MessageFormat.java:368) org.apache.shale.validator.CommonsValidator.getErrorMessage(CommonsValidator.java:965) org.apache.shale.validator.CommonsValidator.validate(CommonsValidator.java:849) javax.faces.component._ComponentUtils.callValidators(_ComponentUtils.java:157) javax.faces.component.UIInput.validateValue(UIInput.java:312) javax.faces.component.UIInput.validate(UIInput.java:353) javax.faces.component.UIInput.processValidators(UIInput.java:183) javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:624) javax.faces.component.UIForm.processValidators(UIForm.java:70) javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:624) javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:624) javax.faces.component.UIViewRoot.processValidators(UIViewRoot.java:146) org.apache.myfaces.lifecycle.LifecycleImpl.processValidations(LifecycleImpl.java:262) org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:76) javax.faces.webapp.FacesServlet.service(FacesServlet.java:137) org.apache.shale.application.faces.ShaleApplicationFilter.doFilter(ShaleApplicationFilter.java:267) > Add a custom validation example to the Use Cases example app > > > Key: SHALE-325 > URL: http://issues.apache.org/struts/browse/SHALE-325 > Project: Shale > Issue Type: Improvement > Components: Validator >Reporter: Wendy Smoak >Priority: Minor > Fix For: 1.0.4-SNAPSHOT > > > Add an example of using a custom validator to the Commons Validator > Integration section of the use-cases example app. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SHALE-325) Add a custom validation example to the Use Cases example app
Add a custom validation example to the Use Cases example app Key: SHALE-325 URL: http://issues.apache.org/struts/browse/SHALE-325 Project: Shale Issue Type: Improvement Components: Validator Reporter: Wendy Smoak Priority: Minor Fix For: 1.0.4-SNAPSHOT Add an example of using a custom validator to the Commons Validator Integration section of the use-cases example app. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (SHALE-321) Update TilesViewHandler to support new Tiles 2 Snapshot
[ http://issues.apache.org/struts/browse/SHALE-321?page=all ] Wendy Smoak reopened SHALE-321: --- I'm having trouble building Shale Tiles against r471763 of Tiles 2. [INFO] Building Shale Tiles Integration [INFO]task-segment: [install] [INFO] - --- [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:compile] Compiling 1 source file to e:\svn\shale\framework\shale-tiles\target\classes [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure e:\svn\shale\framework\shale-tiles\src\main\java\org\apache\shale\tiles\TilesVie wHandler.java:[35,24] cannot find symbol symbol : class ComponentDefinition location: package org.apache.tiles e:\svn\shale\framework\shale-tiles\src\main\java\org\apache\shale\tiles\TilesVie wHandler.java:[36,24] cannot find symbol symbol : class DefinitionsFactoryException location: package org.apache.tiles e:\svn\shale\framework\shale-tiles\src\main\java\org\apache\shale\tiles\TilesVie wHandler.java:[37,24] cannot find symbol symbol : class NoSuchDefinitionException location: package org.apache.tiles e:\svn\shale\framework\shale-tiles\src\main\java\org\apache\shale\tiles\TilesVie wHandler.java:[38,24] cannot find symbol symbol : class TilesRequestContext location: package org.apache.tiles e:\svn\shale\framework\shale-tiles\src\main\java\org\apache\shale\tiles\TilesVie wHandler.java:[39,24] cannot find symbol symbol : class TilesUtil location: package org.apache.tiles e:\svn\shale\framework\shale-tiles\src\main\java\org\apache\shale\tiles\TilesVie wHandler.java:[253,11] cannot find symbol symbol : class ComponentDefinition location: class org.apache.shale.tiles.TilesViewHandler e:\svn\shale\framework\shale-tiles\src\main\java\org\apache\shale\tiles\TilesVie wHandler.java:[302,31] cannot find symbol symbol : class ComponentDefinition location: class org.apache.shale.tiles.TilesViewHandler e:\svn\shale\framework\shale-tiles\src\main\java\org\apache\shale\tiles\TilesVie wHandler.java:[130,6] cannot find symbol symbol : class ComponentDefinition location: class org.apache.shale.tiles.TilesViewHandler e:\svn\shale\framework\shale-tiles\src\main\java\org\apache\shale\tiles\TilesVie wHandler.java:[262,6] cannot find symbol symbol : class ComponentDefinition location: class org.apache.shale.tiles.TilesViewHandler e:\svn\shale\framework\shale-tiles\src\main\java\org\apache\shale\tiles\TilesVie wHandler.java:[264,8] cannot find symbol symbol : class TilesRequestContext location: class org.apache.shale.tiles.TilesViewHandler e:\svn\shale\framework\shale-tiles\src\main\java\org\apache\shale\tiles\TilesVie wHandler.java:[265,12] cannot find symbol symbol : method createRequestContext(java.lang.Object,java.lang.Object,java.lan g.Object) location: class org.apache.tiles.context.BasicTilesContextFactory e:\svn\shale\framework\shale-tiles\src\main\java\org\apache\shale\tiles\TilesVie wHandler.java:[267,15] cannot find symbol symbol : variable TilesUtil location: class org.apache.shale.tiles.TilesViewHandler e:\svn\shale\framework\shale-tiles\src\main\java\org\apache\shale\tiles\TilesVie wHandler.java:[268,15] cannot find symbol symbol : class NoSuchDefinitionException location: class org.apache.shale.tiles.TilesViewHandler e:\svn\shale\framework\shale-tiles\src\main\java\org\apache\shale\tiles\TilesVie wHandler.java:[270,15] cannot find symbol symbol : class DefinitionsFactoryException location: class org.apache.shale.tiles.TilesViewHandler e:\svn\shale\framework\shale-tiles\src\main\java\org\apache\shale\tiles\TilesVie wHandler.java:[307,6] cannot find symbol symbol : class TilesRequestContext location: class org.apache.shale.tiles.TilesViewHandler e:\svn\shale\framework\shale-tiles\src\main\java\org\apache\shale\tiles\TilesVie wHandler.java:[308,10] cannot find symbol symbol : method createRequestContext(java.lang.Object,java.lang.Object,java.lan g.Object) location: class org.apache.tiles.context.BasicTilesContextFactory e:\svn\shale\framework\shale-tiles\src\main\java\org\apache\shale\tiles\TilesVie wHandler.java:[312,23] org.apache.tiles.ComponentContext is abstract; cannot be instantiated > Update TilesViewHandler to support new Tiles 2 Snapshot > --- > > Key: SHALE-321 > URL: http://issues.apache.org/struts/browse/SHALE-321 > Project: Shale > Issue Type: Bug > Components: Tiles >Affects Versions: 1.0.4-SNAPSHOT, 1.0.5-SNAPSHOT, 1.0.6-SNAPSHOT >Reporter: Greg Reddin > Assigned To: Greg Reddin >Priority: Blocker > Fix For: 1.0.4-SNAPSHOT > > > Changes to the Tiles 2 API have broken T
[jira] Updated: (SHALE-324) Maven Mojo to convert JSF type library descriptors to clay configuration files
[ http://issues.apache.org/struts/browse/SHALE-324?page=all ] Hermod Opstvedt updated SHALE-324: -- Attachment: shale324-tld2claycfg.patch Added capability of handling the Listener tag in a tld. Also added possibility of setting the classloader to use. > Maven Mojo to convert JSF type library descriptors to clay configuration files > -- > > Key: SHALE-324 > URL: http://issues.apache.org/struts/browse/SHALE-324 > Project: Shale > Issue Type: New Feature > Components: Clay >Affects Versions: 1.0.3 > Environment: Any >Reporter: Hermod Opstvedt > Attachments: Clay-tools.zip, shale324-testmojo.patch, > shale324-tld2claycfg.patch, shale324-tld2claycfgmojo.patch, shale324.patch > > > I have created a Utility that will convert a JSF type library descriptor into > a corresponding Clay component configuration file. It can be ran standalone, > or as a Maven mojo thereby enabling the conversion to take place as part of > the Clay Maven build process. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SHALE-324) Maven Mojo to convert JSF type library descriptors to clay configuration files
[ http://issues.apache.org/struts/browse/SHALE-324?page=all ] Hermod Opstvedt updated SHALE-324: -- Attachment: shale324-tld2claycfgmojo.patch Fixed problem of loading the correct dependencies. > Maven Mojo to convert JSF type library descriptors to clay configuration files > -- > > Key: SHALE-324 > URL: http://issues.apache.org/struts/browse/SHALE-324 > Project: Shale > Issue Type: New Feature > Components: Clay >Affects Versions: 1.0.3 > Environment: Any >Reporter: Hermod Opstvedt > Attachments: Clay-tools.zip, shale324-testmojo.patch, > shale324-tld2claycfg.patch, shale324-tld2claycfgmojo.patch, shale324.patch > > > I have created a Utility that will convert a JSF type library descriptor into > a corresponding Clay component configuration file. It can be ran standalone, > or as a Maven mojo thereby enabling the conversion to take place as part of > the Clay Maven build process. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SHALE-324) Maven Mojo to convert JSF type library descriptors to clay configuration files
[ http://issues.apache.org/struts/browse/SHALE-324?page=all ] Hermod Opstvedt updated SHALE-324: -- Attachment: shale324-testmojo.patch Added test for Trinidad and Tobago > Maven Mojo to convert JSF type library descriptors to clay configuration files > -- > > Key: SHALE-324 > URL: http://issues.apache.org/struts/browse/SHALE-324 > Project: Shale > Issue Type: New Feature > Components: Clay >Affects Versions: 1.0.3 > Environment: Any >Reporter: Hermod Opstvedt > Attachments: Clay-tools.zip, shale324-testmojo.patch, shale324.patch > > > I have created a Utility that will convert a JSF type library descriptor into > a corresponding Clay component configuration file. It can be ran standalone, > or as a Maven mojo thereby enabling the conversion to take place as part of > the Clay Maven build process. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SHALE-277) Shale is eating 500s errors
[ http://issues.apache.org/struts/browse/SHALE-277?page=comments#action_38590 ] Torsten Krah commented on SHALE-277: I would like to see this reopened. As i wrote to the list, it does not work for me. I did integrate the use case example in my application, but when i hit the test pages submit button - the arithmetic exception is thrown - but a null pointer exception is thrown too, because my FacesContext dissapeared, i don't know why its gone - but its not there anymore after hitting the button to trigger the exception. clay based exception trace snippet: java.lang.NullPointerException: context at javax.faces.component.UIComponentBase.getRenderer(UIComponentBase.java:738) at javax.faces.component.UIComponentBase.getRendersChildren(UIComponentBase.java:307) at org.apache.shale.clay.faces.ClayViewHandler.recursiveRender(ClayViewHandler.java:462) at org.apache.shale.clay.faces.ClayViewHandler.renderView(ClayViewHandler.java:398) at org.apache.shale.validator.faces.ValidatorViewHandler.renderView(ValidatorViewHandler.java:130) at org.apache.shale.view.faces.ViewViewHandler.renderView(ViewViewHandler.java:147) at de.sf.frc.jsf.navigation.LocaleViewHandler.renderView(LocaleViewHandler.java:86) at org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:384) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:138) ... jsp based: ERROR http-8080-Processor23 javax.faces.webapp.UIComponentTag - Faces context not found. getResponseWriter will fail. Check if the FacesServlet has been initialized at all in your web.xml. ERROR http-8080-Processor23 org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/myapp].[jsp] - Servlet.service() for servlet jsp threw exception java.lang.NullPointerException at javax.faces.webapp.UIComponentTag.setupResponseWriter(UIComponentTag.java:929) at javax.faces.webapp.UIComponentTag.doStartTag(UIComponentTag.java:310) at org.apache.myfaces.taglib.core.ViewTag.doStartTag(ViewTag.java:70) at org.apache.jsp.jsf.test_jsp._jspx_meth_f_view_0(test_jsp.java:100) ... web.xml context param looks like this: org.apache.shale.view.EXCEPTION_DISPATCH_PATH /jsf/error500.html The error page itself is displayed correct but empty if i call the page without an exception, so this should not be an issue. Any help is welcome. Torsten > Shale is eating 500s errors > --- > > Key: SHALE-277 > URL: http://issues.apache.org/struts/browse/SHALE-277 > Project: Shale > Issue Type: Bug > Components: Core >Affects Versions: 1.0.3, 1.0.4-SNAPSHOT > Environment: Tomcat 5.5.17 + Myfaces 1.1.3 >Reporter: Veit Guna > Assigned To: Craig McClanahan > > When using shale-core for the s:token tag in my myfaces webapp, shale is > eating 500 errors. That means if for example > a Nullpointer Exception occurs, it doesn't let tomcat use the custom error > page configured in the web.xml for 500 errors. > If I remove shale-core from my webapp, everything works fine and the custom > error-page is displayed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
