And in MyFaces 1.2 these issues do not exist anymore,
Cheers, Bruno On 18/05/07, Manfred Geiler <[EMAIL PROTECTED]> wrote:
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
