Hi, I was wondering if the following method overloads in Category might be
useful to help ease the burden associated with logXXX() parameter
construction. Currently, there are two convenience overloads per priority,
e.g.

        void info(Object message);
        void info(Object message, Throwable);

What I find myself doing a lot in my code is something similar to the
following:

        category.info("message: " + variable + " is not found");

What if a few extra overloads were added to account for multiple message
parameters, e.g

        void info(Object message1, Object message2);
        void info(Object message1, Object message2, Object message3);

Then the user code would be simplified to:

        category.info("message: ", variable, " is not found");

The nice thing is that for the common cases of 1-3 parameters, the "hidden"
StringBuffer goes away. The overloaded methods inside Category could reuse a
common StringBuffer for string concatenation. Plus, you may feel less need
to wrap your log statements with "category.isInfoEnabled()" if statements.

Also, for support for more than three message concatenations, or as an
alternative to the above idea, an Object[] could be passed to the one
argument method, and a special renderer could be called upon to deal with
arrays. For example:

        category.info(new Object[]{"message", variable, "is not found.", "..."});

Would be handled by a default ObjectRenderer similar to:

        String doRender(Object o) {
                String message;
                Object[] messages = (Object[])o;
                myStringBuffer.setLength(0);
                for (int i=0; i<messages.length; ++i) {
                        o = messages[i];
                        message =  (o instanceof String)?
                           (String)message : myRendererMap.findAndRender(o);
                        myStringBuffer.append(message);
                }
                return myStringBuffer.toString();
        }

Is all this more trouble than it's worth? I suppose Category could be also
extended to add this behavior as well, but then configuration gets a little
tricky. Thoughts?

--mike



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to