[
https://issues.apache.org/struts/browse/SHALE-445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_41174
]
Ryan Lubke commented on SHALE-445:
----------------------------------
For now, I've created a private Schema for 1.1 documents and relaxed the
restriction of managed-bean-name. This seems to work ok.
However, this should be kept in mind if the shale faces-config documents are
moved to 1.2 or beyond, the managed-bean-name will not be valid.
> '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.
