headers
Rahul Akolkar (JIRA | 1 Feb 2007 16:52
Picon
Favicon

Resolved: (SHALE-403) Back the root Context used for SCXML dialogs with the application VariableResolver


     [
https://issues.apache.org/struts/browse/SHALE-403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Rahul Akolkar resolved SHALE-403.
---------------------------------

    Resolution: Fixed

> Back the root Context used for SCXML dialogs with the application VariableResolver
> ----------------------------------------------------------------------------------
>
>                 Key: SHALE-403
>                 URL: https://issues.apache.org/struts/browse/SHALE-403
>             Project: Shale
>          Issue Type: Improvement
>          Components: Dialog
>    Affects Versions: 1.0.4
>            Reporter: Rahul Akolkar
>         Assigned To: Rahul Akolkar
>             Fix For: 1.0.5-SNAPSHOT, 1.1.0-SNAPSHOT
>
>
> This allows for using arbitrary EL expressions (beyond calling action state MBEs) within the SCXML
document used to describe the dialog.
> Reported by Paul Spencer <paulsp AT apache DOT org> on the Shale user mailing list in this thread:
> http://www.nabble.com/Need-help-with-SCXML-transition-cond-syntax.-tf3144134.html

--

-- 
This message is automatically generated by JIRA.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Doug Chasman (JIRA | 4 Feb 2007 17:15
Picon
Favicon

Created: (SHALE-405) Incorrect logic in MockApplication12.addELResolver(ELResolver resolver)

Incorrect logic in MockApplication12.addELResolver(ELResolver resolver)
-----------------------------------------------------------------------

                 Key: SHALE-405
                 URL: https://issues.apache.org/struts/browse/SHALE-405
             Project: Shale
          Issue Type: Bug
          Components: Test
    Affects Versions: 1.1.0-SNAPSHOT
         Environment: Not environment specific
            Reporter: Doug Chasman
            Priority: Blocker

Current implementation will never allow addition of el resolvers regardless of the point in the app lifecycle:

    /** { <at> inheritDoc} */
    public void addELResolver(ELResolver resolver) {

        // Simulate the restriction that you cannot add resolvers after
        // the first request has been processed.
        if (resolver != null) {
            throw new IllegalStateException("Cannot add resolvers now");
        }

        resolvers.add(resolver);

    }

should read:
(Continue reading)

Permalink | Reply | 2 comments |
headers
Rahul Akolkar (JIRA | 5 Feb 2007 22:07
Picon
Favicon

Updated: (SHALE-405) Incorrect logic in MockApplication12.addELResolver(ELResolver resolver)


     [
https://issues.apache.org/struts/browse/SHALE-405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Rahul Akolkar updated SHALE-405:
--------------------------------

    Fix Version/s: 1.1.0-SNAPSHOT
                   1.0.5-SNAPSHOT
         Assignee: Rahul Akolkar

> Incorrect logic in MockApplication12.addELResolver(ELResolver resolver)
> -----------------------------------------------------------------------
>
>                 Key: SHALE-405
>                 URL: https://issues.apache.org/struts/browse/SHALE-405
>             Project: Shale
>          Issue Type: Bug
>          Components: Test
>    Affects Versions: 1.1.0-SNAPSHOT
>         Environment: Not environment specific
>            Reporter: Doug Chasman
>         Assigned To: Rahul Akolkar
>            Priority: Blocker
>             Fix For: 1.0.5-SNAPSHOT, 1.1.0-SNAPSHOT
>
>
> Current implementation will never allow addition of el resolvers regardless of the point in the app lifecycle:
>     /** { <at> inheritDoc} */
>     public void addELResolver(ELResolver resolver) {
(Continue reading)

Permalink | Reply | 0 comments |
headers
Rahul Akolkar (JIRA | 5 Feb 2007 22:13
Picon
Favicon

Resolved: (SHALE-405) Incorrect logic in MockApplication12.addELResolver(ELResolver resolver)


     [
https://issues.apache.org/struts/browse/SHALE-405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Rahul Akolkar resolved SHALE-405.
---------------------------------

    Resolution: Fixed

This has been fixed in the source repository, thanks for reporting this.

> Incorrect logic in MockApplication12.addELResolver(ELResolver resolver)
> -----------------------------------------------------------------------
>
>                 Key: SHALE-405
>                 URL: https://issues.apache.org/struts/browse/SHALE-405
>             Project: Shale
>          Issue Type: Bug
>          Components: Test
>    Affects Versions: 1.1.0-SNAPSHOT
>         Environment: Not environment specific
>            Reporter: Doug Chasman
>         Assigned To: Rahul Akolkar
>            Priority: Blocker
>             Fix For: 1.0.5-SNAPSHOT, 1.1.0-SNAPSHOT
>
>
> Current implementation will never allow addition of el resolvers regardless of the point in the app lifecycle:
>     /** { <at> inheritDoc} */
>     public void addELResolver(ELResolver resolver) {
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ingo Dueppe (JIRA | 11 Feb 2007 14:35
Picon
Favicon

Created: (SHALE-406) ConverterHelper produce NullPointerException by calling Converter with uiComponent = null parameter during restore view phase.

ConverterHelper produce NullPointerException by calling Converter with uiComponent = null parameter
during restore view phase.
------------------------------------------------------------------------------------------------------------------------------

                 Key: SHALE-406
                 URL: https://issues.apache.org/struts/browse/SHALE-406
             Project: Shale
          Issue Type: Bug
          Components: View
    Affects Versions: 1.0.4
         Environment: Facelets 1.1.12, MyFaces 1.1.5-SNAPSHOT , Tomahawk 1.1.5-SNAPSHOT
            Reporter: Ingo Dueppe

I had an backing bean class with the following property:

 <at> Property{value="#{param.enrollmentId}")
private Long enrollmentId;

And this ends up that shale calls the
getAsObject method javax.faces.convert.LongConverter of MyFaces-1.1.5-SNAPSHOT during the restore
view phase .

This method expects an uiComponent not null otherwise it throws a
NullPointerException. But this method is called by the
org.apache.shale.util.ConverterHelper during create view and therefore
the facesContext setViewRoot is still null. So the below code of the ConverterHelper
end ups in a NullPointerException in this situation.

    public Object asObject(FacesContext context, Class type, String value) {
        if (String.class == type) {
(Continue reading)

Permalink | Reply | 3 comments |
headers
Ingo Dueppe (JIRA | 11 Feb 2007 14:43
Picon
Favicon

Updated: (SHALE-406) ConverterHelper produce NullPointerException by calling Converter with uiComponent = null parameter during restore view phase.


     [
https://issues.apache.org/struts/browse/SHALE-406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ingo Dueppe updated SHALE-406:
------------------------------

    Component/s: Core

> ConverterHelper produce NullPointerException by calling Converter with uiComponent = null parameter
during restore view phase.
> ------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: SHALE-406
>                 URL: https://issues.apache.org/struts/browse/SHALE-406
>             Project: Shale
>          Issue Type: Bug
>          Components: Core, View
>    Affects Versions: 1.0.4
>         Environment: Facelets 1.1.12, MyFaces 1.1.5-SNAPSHOT , Tomahawk 1.1.5-SNAPSHOT
>            Reporter: Ingo Dueppe
>
> I had an backing bean class with the following property:
>  <at> Property{value="#{param.enrollmentId}")
> private Long enrollmentId;
> And this ends up that shale calls the
> getAsObject method javax.faces.convert.LongConverter of MyFaces-1.1.5-SNAPSHOT during the
restore view phase .
> This method expects an uiComponent not null otherwise it throws a
> NullPointerException. But this method is called by the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bernhard Slominski (JIRA | 11 Feb 2007 20:59
Picon
Favicon

Created: (SHALE-407) E-Mail Validator is not working in sample applications

E-Mail Validator is not working in sample applications
------------------------------------------------------

                 Key: SHALE-407
                 URL: https://issues.apache.org/struts/browse/SHALE-407
             Project: Shale
          Issue Type: Bug
          Components: Validator
    Affects Versions: 1.0.4
            Reporter: Bernhard Slominski

The E-Mail validator of the Jakarta Commons Validator project has a dependency on the Jakarta Oro project.
Even the E-Mail validaton is optional it should be at least included in "shale-clay-usecases-current"
because the E-Mail validation is used there.
If the jakarta-oro-2.0.X.jar is missing and E-Mail validation is used an Exception occurs and a blank page
is displayed.
This behavior occurs in the Clay Usescases e.g. for the page rolodex/hrolodex.html if you edit a contact
with an E-Mail address and hit the save button, then a blank page occurs.
It would even be better to include the jakarta-oro-2.0.X.jar in other war files like
"shale-clay-usecases-current" and "shale-blank-current" because the E-Mail validation is the most
frequent usecase for the build-in validators. It is a bit difficult to track the problem down to the
missing jar file, especially for people who use Shale the first time.

The Exception is:
10.02.2007 10:44:28 org.apache.catalina.core.ApplicationContext log
SCHWERWIEGEND: Error initializing commons validator for rule type "email" on component id "email".
java.lang.RuntimeException: Error initializing commons validator for rule type "email" on component
id "email".
	at org.apache.shale.validator.CommonsValidator.validate(CommonsValidator.java:821)
	at javax.faces.component._ComponentUtils.callValidators(_ComponentUtils.java:157)
(Continue reading)

Permalink | Reply | 3 comments |
headers
Bernhard Slominski (JIRA | 12 Feb 2007 12:25
Picon
Favicon

Updated: (SHALE-407) E-Mail Validator is not working in sample applications


     [
https://issues.apache.org/struts/browse/SHALE-407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bernhard Slominski updated SHALE-407:
-------------------------------------

    Description: 
The E-Mail validator of the Jakarta Commons Validator project has a dependency on the Jakarta Oro project.
Even the E-Mail validaton is optional it should be at least included in "shale-clay-usecases-current"
because the E-Mail validation is used there.
If the jakarta-oro-2.0.X.jar is missing and E-Mail validation is used an Exception occurs and a blank page
is displayed.
This behavior occurs in the Clay Usescases e.g. for the page rolodex/hrolodex.html if you edit a contact
with an E-Mail address and hit the save button, then a blank page occurs.
It would even be better to include the jakarta-oro-2.0.X.jar in other war files like
"shale-usecases-current" and "shale-blank-current" because the E-Mail validation is the most
frequent usecase for the build-in validators. It is a bit difficult to track the problem down to the
missing jar file, especially for people who use Shale the first time.

The Exception is:
10.02.2007 10:44:28 org.apache.catalina.core.ApplicationContext log
SCHWERWIEGEND: Error initializing commons validator for rule type "email" on component id "email".
java.lang.RuntimeException: Error initializing commons validator for rule type "email" on component
id "email".
	at org.apache.shale.validator.CommonsValidator.validate(CommonsValidator.java:821)
	at javax.faces.component._ComponentUtils.callValidators(_ComponentUtils.java:157)
	at javax.faces.component.UIInput.validateValue(UIInput.java:312)
	at javax.faces.component.UIInput.validate(UIInput.java:353)
	at javax.faces.component.UIInput.processValidators(UIInput.java:183)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Hermod Opstvedt (JIRA | 12 Feb 2007 22:04
Picon
Favicon

Updated: (SHALE-408) Update to the Tld2ClayCfg tool


     [
https://issues.apache.org/struts/browse/SHALE-408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Hermod Opstvedt updated SHALE-408:
----------------------------------

    Attachment: MavenTld2Cfgpatch.patch

> Update to the Tld2ClayCfg tool
> ------------------------------
>
>                 Key: SHALE-408
>                 URL: https://issues.apache.org/struts/browse/SHALE-408
>             Project: Shale
>          Issue Type: Improvement
>          Components: Clay
>    Affects Versions: 1.0.4
>            Reporter: Hermod Opstvedt
>         Attachments: MavenTld2Cfgpatch-2.patch, MavenTld2Cfgpatch.patch
>
>
> This update adds support for Validators, Converters and RendererType. There is still an unresolved
issue with Converters and Validators: There does not seem to be any way to programtically getting hold of
the componenttype for these short of assuming that it is the same as the Tag-Class minus the Tag ending.

--

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Hermod Opstvedt (JIRA | 12 Feb 2007 22:04
Picon
Favicon

Updated: (SHALE-408) Update to the Tld2ClayCfg tool


     [
https://issues.apache.org/struts/browse/SHALE-408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Hermod Opstvedt updated SHALE-408:
----------------------------------

    Attachment: MavenTld2Cfgpatch-2.patch

> Update to the Tld2ClayCfg tool
> ------------------------------
>
>                 Key: SHALE-408
>                 URL: https://issues.apache.org/struts/browse/SHALE-408
>             Project: Shale
>          Issue Type: Improvement
>          Components: Clay
>    Affects Versions: 1.0.4
>            Reporter: Hermod Opstvedt
>         Attachments: MavenTld2Cfgpatch-2.patch, MavenTld2Cfgpatch.patch
>
>
> This update adds support for Validators, Converters and RendererType. There is still an unresolved
issue with Converters and Validators: There does not seem to be any way to programtically getting hold of
the componenttype for these short of assuming that it is the same as the Tag-Class minus the Tag ending.

--

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane