You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@shale.apache.org by "Ryan Lubke (JIRA)" <ji...@apache.org> on 2007/05/15 23:48:42 UTC
[jira] Created: (SHALE-445) 'org.apache.shale.remoting.LOGGER' is
not a valid managed-bean-name
'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.
[jira] Commented: (SHALE-445) 'org.apache.shale.remoting.LOGGER' is
not a valid managed-bean-name
Posted by "Ryan Lubke (JIRA)" <ji...@apache.org>.
[ 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.