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 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


Back to the top