Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [riena-dev] Test friendly LOGGER pattern

Hi Elias,

No problem! My assumption was that all those logs would be annoying.

Tschüß,
Stefan

Elias Volanakis wrote:
Hi Stefan,

great, I like it :-).

Now is it possible to always return the ConsoleLogger, _unless_ the
property is set to false?

private static Logger getEmergencyLogger(String className) {
                // use ConsoleLogger unless the system property specifies otherwise
                Logger result = new ConsoleLogger(className);
                if (System.getProperty(LoggerMill.RIENA_DEFAULT_LOGGING) != null
                                && !Boolean.getBoolean(LoggerMill.RIENA_DEFAULT_LOGGING)) {
                        result = new NullLogger();
                }
                return result;
        }


Motivation: when running tests, it is always useful to have the
ConsoleLogger enabled. Because of this, I think it is inconvenient to
require the RIENA_DEFAULT_LOGGING to be defined for every test launch
configuration.
:-)

Greetings,
Elias.

On Mon, Mar 9, 2009 at 2:57 AM, Stefan Liebig
<Stefan.Liebig@xxxxxxxxxxxx> wrote:
  
Hi,

I have replaced all occurrences of the old style pattern for getting a
logger with the following:

    private final static Logger LOGGER =
Log4r.getLogger(Activator.getDefault(), YourClass.class);

This will return a ´real´ logger in case that Activator.getDeault() does not
return null, otherwise it will return a ConsoleLogger (if the system
property riena.defaultlogging == true) otherwise it will return a
NullLogger.

Tschüß,
Stefan


Christian Campo wrote:

+1 for the proposal from Stefan.
I think we should keep RienaActivator and RienaPlugin as long as the
equivalent exists in the Eclipse space. (Plugin and Activator)
While we might have a preference for one of them, other users of Riena might
think different.
christian
Am 06.03.2009 um 11:09 schrieb Stefan Liebig:

See comments below.

Elias Volanakis wrote:

One more thing to consider:

- In this case: LoggerUtils.getLogger(Activator.getDefault(),
ImageStore.class);  we would need two LoggerUtils implementaions,
because Activator.getDefault() can be either from core (RienaPlugin,
RienaActivator) or from UI (AbstractRienaUIPlugin)


No. I did not mention that I introduced a new interface with the getLogger()
stuff. This has to be implemented by activators that get passed to the
LoggerUtil.getLogger(..). These methods (getLogger(),..) are already within
the activators they only have to add the ´implements´ statement.

- in the other case we would have three copies of the boilerplate code
in RienaPlugin, RienaActivator, AbstractRienaUIPlugin.


No, I don´t think so. If I get you right you added in your proposal a static
getLogger() to the activator, which in turn uses the static getDefault().
The getDefault() is not (and can not be) part of the abstract activators.
So, this would require to add the static getLogger() to all activators. Or?

I'm wondering is there a difference between RienaPlugin and
RienaActivator? If we only had one of those, both cases would need two
copies ;-)


Yes, I think this has some historical reasons. When we began we were more
´OSGi-addicted´. This is the reason for the RienaActivator.
Maybe we can drop it!

Otherwise the first case is a little better (one copy less).

Thinking aloud,
Elias.



Tschüß,
Stefan

On Thu, Mar 5, 2009 at 11:24 PM, Stefan Liebig
<Stefan.Liebig@xxxxxxxxxxxx> wrote:


This is definitely shorter, but it has the downside of putting boiler plate
code (the elsewhere code) into each bundles activator.
Maintenance of this code gets more difficult.

So, I personally would prefer this pattern:
    private final static Logger LOGGER =
LoggerUtil.getLogger(Activator.getDefault(), ImageStore.class);

Tschüß,
Stefan

Elias Volanakis wrote:

Nice.
Along those lines: how about making getLogger(...) static and moving the
logic into there:
private final static Logger LOGGER = Activator.getLogger(FooClass.class);
// elsewhere:
class Activator {
public static Logger getLogger(Class clazz) {
   if(getDefault() == null) {
       return ... normal logger...
   }
   return new ConsoleLogger(clazz.getName());
}
}
Tschuess,
Elias.
On Thu, Mar 5, 2009 at 1:37 AM, Stefan Liebig <Stefan.Liebig@xxxxxxxxxxxx>
wrote:


How about something like this:

    private final static Logger LOGGER =
LoggerUtil.getLogger(Activator.getDefault(), ImageStore.class);

Looks much nicer to me. ;-)

Tschüß,
Stefan

Elias Volanakis wrote:

Just a quick tip:
If you use static LOGGER fields, I recommend using the pattern (b)
below. It avoids a NPE exception when calling
Activator.getDefault().getLogger(), which usually happens when running test
suites as "plain" junit tests.
(a) Problematic with Junit:

public final class MyClass {
private static final Logger LOGGER =
Activator.getDefault().getLogger(ImageStore.class);
(b) Works well with Junit:
public final class MyClass {
private static final Logger LOGGER;
static {
if (Activator.getDefault() != null) {
LOGGER = Activator.getDefault().getLogger(MyClass.class);
} else {
LOGGER = new ConsoleLogger(MyClass.class.getName());
}
}
I know that some test cases must be run as "plug-in" tests, but I usually
run individual test cases for stuff I'm working on as "regular" unit-tests,
because they start much faster :-)
Viele Gruesse,
Elias.

_______________________________________________
riena-dev mailing list
riena-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/riena-dev


_______________________________________________
riena-dev mailing list
riena-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/riena-dev




--
Elias Volanakis
Technical Lead
Innoopract (EclipseSource)
351 NW 12th Avenue
Portland, Oregon 97209

elias@xxxxxxxxxxxxxxxxx
evolanakis@xxxxxxxxxxxxxx
Tel: +1-503-552-1457
Fax: +1-503-715-4915
Mobile: +1-503-929-5537
---
Innoopract is becoming EclipseSource - www.eclipsesource.com
_______________________________________________
riena-dev mailing list
riena-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/riena-dev


<ATT00001.c>


_______________________________________________
riena-dev mailing list
riena-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/riena-dev


    


--
Elias Volanakis
Technical Lead
Innoopract (EclipseSource)
351 NW 12th Avenue
Portland, Oregon 97209

elias@xxxxxxxxxxxxxxxxx
evolanakis@xxxxxxxxxxxxxx
Tel: +1-503-552-1457
Fax: +1-503-715-4915
Mobile: +1-503-929-5537
---
Innoopract is becoming EclipseSource - www.eclipsesource.com
_______________________________________________
riena-dev mailing list
riena-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/riena-dev
  


Back to the top