Yes, logging at warn level (with some explanation) sounds appropriate
for me for all stuff that does not violate the spec but might bring
difficulties with other implementations (or better: the other
implementation ;-)
--Manfred
On 5/18/07, Paul Spencer <[EMAIL PROTECTED]> wrote:
Grant,
I have though about a utility that can be used to ease the pain of
deprecating an TLD tag or attribute. This would help the user/developer
identify where the deprecated tag/attribute is used before it actually
breaks. The utility would:
o Log the deprecation at the warning level.
o The user/developer/... should be able to disable the logging via
configuration.
o The log message should contain the viewId, tag, and attribute
deprecated. The method could be extended to include instruction
at the debug level.
DeprecationUtility.logTag( viewid, tag)
DeprecationUtility.logTag( viewid, tag, attribute)
DeprecationUtility.logTag( viewid, tag, attribute, instructions)
This may be better suited for Shale, but either way it is needed.
We also need a deprecation policy, i.e. use the above utility at least
one release before the tag/attribute is removed.
Paul Spencer
Grant Smith wrote:
> Hi,
>
> as part of http://issues.apache.org/jira/browse/MYFACES-654 , I'm about to
> remove the attributes in MyFaces that are not present in the RI. My concern
> is breaking user's applications that may already depend on these
> attributes... for example commandLink's onclick.
>
> In choosing the lesser of two evils, should we rather just leave in the
> attributes that users may already (mistakenly) depend on ?
>
>
--
http://www.irian.at
Your JSF powerhouse - JSF Consulting,
Development and Courses in English and
German
Professional Support for Apache MyFaces
