shale-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ryan Lubke (JIRA)" <j...@apache.org>
Subject [jira] Created: (SHALE-445) 'org.apache.shale.remoting.LOGGER' is not a valid managed-bean-name
Date Tue, 15 May 2007 21:48:42 GMT
'org.apache.shale.remoting.LOGGER' is not a valid managed-bean-name
-------------------------------------------------------------------

                 Key: SHALE-445
                 URL: https://issues.apache.org/struts/browse/SHALE-445
             Project: Shale
          Issue Type: Bug
    Affects Versions: 1.0.4
         Environment: linux 2.6.x kernel
JDK 1.5/1.6

            Reporter: Ryan Lubke


In order to portably support the validation of both DTD and Schema-based faces-config documents
in the RI,
we've had to take the approach or transforming any 1.0/1.1 documents to 1.2 and perform schema
validation
(there is no portable way to validate using both schema and dtd).

Doing so has brought up an interesting issue when deploying to a container when validation
is enabled.

Consider the following shale managed bean entry:


<managed-bean>
  <!-- Default logging adapter implementation -->
    <managed-bean-name>org.apache.shale.remoting.LOGGER</managed-bean-name>
    <managed-bean-class>
        org.apache.shale.remoting.logger.DefaultLogger
    </managed-bean-class>
    <managed-bean-scope>application</managed-bean-scope>
</managed-bean> 

This will fail to validate against the 1.2 schema with the following error:

(cvc-pattern-valid: Value 'org.apache.shale.remoting.LOGGER' is not facet-valid with respect
to pattern '($|_|\p{L})(\p{L}|\p{Nd}|_|$)*' for type 'null'.)

I had talked to Craig off line about this.  Here are his comments:

The spec language doesn't say anything, but the JSF 1.1 DTD comment regarding <managed-bean-name>
includes the comment 'It must be of type "Identifier"', which references back to a "type description"
above claiming that the content must conform to the syntax of a valid Java identifier.  I
suspect that, when this DTD was translated into a schema, this requirement was taken literally.

That creates an interesting backwards compatibility problem for Shale, but also an interesting
spec question regarding backwards compatibility ... the RI for 1.2 is enforcing a requirement
that the RI for 1.1 did not enforce, which could be argued is a breakage.  But, in the mean
time, I'm going to look at what the impact would be of correcting these names in Shale. 

We haven't released these changes yet, so this has no immediate impact, but it would be good
to get a discussion going on this and figure out what should be done.





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


Mime
View raw message