DO NOT REPLY [Bug 23971] New: - Declare log variables protected static

[bu...@apache.org]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23971>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23971

Declare log variables protected static

           Summary: Declare log variables protected static
           Product: Struts
           Version: Nightly Build
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: Minor
          Priority: Other
         Component: Standard Actions
        AssignedTo: struts-dev@jakarta.apache.org
        ReportedBy: irc@indrajit.com


In general, Struts core classes (those belonging to src/share and probably some 
others) that are subclassable should have the class level log variables 
declared 'protected' instead of 'private'.

This gives more flexibility to the author of the subclasses in using the log 
instance.  He can choose to have another log instance of his own to 'hide' the 
log instance of the base class or can continue using the log instance of the 
base class.

See http://www.mail-archive.com/struts-user@jakarta.apache.org/msg83339.html 
for a discussion in Struts User List.

While this convention is followed in general, there are some odd cases where 
they are marked 'private'.

Further, LookupDispatchAction.java doesn't have any instance of it's own 
(although it's base class has one).  Although, it doesn't use a log instance 
anywhere, it's subclass might use one.  IMHO, this class can also have a log 
instance until there are stronger reason behind not having one.

In case of ActionConfigMatcher.java, is there a good reason to have the log 
instance marked 'private final' as well?
Is there anything that we gain by being rigid in one off case?

In general, there are some places where these inconsistencies exist.  None of 
them are show stoppers, but having a look at them might be worthwhile.

The attached patch addresses the issue for:
1. share/org/apache/struts/actions/LookupDispatchAction.java
2. share/org/apache/struts/actions/MappingDispatchAction.java
3. share/org/apache/struts/config/ActionConfigMatcher.java
4. share/org/apache/struts/plugins/DigestingPlugIn.java
5. share/org/apache/struts/validator/DynaValidatorActionForm.java
6. share/org/apache/struts/validator/DynaValidatorForm.java
7. share/org/apache/struts/validator/ValidatorForm.java
8. share/org/apache/struts/validator/ValidatorPlugIn.java

---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org