tomee-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Karan Malhi <karan.ma...@gmail.com>
Subject Re: logging.properties file ignored for unit tests
Date Fri, 13 Feb 2009 04:58:53 GMT
Rename the file to embedded.logging.properties. When testing with embedded
OpenEJB, this is the file which is used. logging.properties is used when you
use openejb with tomcat or use it as a standalone server.
So for example, in my tests, I put this file under src/test/resources and it
gets picked up.

On Wed, Jan 21, 2009 at 8:46 PM, David Blevins <david.blevins@visi.com>wrote:

>
> On Jan 19, 2009, at 2:40 AM, Olivier THIERRY wrote:
>
>  Hi,
>>
>> I use Open EJB 3.1 within a Maven 2.0.9 project to run tests.
>> Everything works well for the moment.
>> But for a few days I encounter a bug with entity manager and I need to
>> activate logs to understand what happens.
>>
>> I start OpenEJB this way :
>>
>>                System.setProperty("openejb.base", "src/test/resources");
>>                java.util.Properties props = new java.util.Properties();
>>
>>  props.put("openejb.jndiname.format","{deploymentId}/{interfaceType.annotationName}");
>>                props.put("openejb.deployments.classpath.ear", "false");
>>                org.apache.openejb.OpenEJB.init(props);
>>
>> If I delete conf/logging.properties file OpenEJB creates a new one, so
>> it looks like OpenEJB knows the base directory. But it looks like
>> logging.properties file is ignored. It never writes any log to default
>> logs/openejb.log file (this file is not even created). Same problem if
>> I set log level to debug or if I add console appender.
>>
>> I have following logs on console, so it looks like logging system is
>> OK. But it's clear to me that logging.properties file is ignored :
>>
>
> I'm not sure what might be happening without some investigation, but there
> is an alternative way to configure logging which you can use to tide you
> over.  Basically you take the properties you want from the
> logging.properties file and set them in your test case as system properties
> before you initialize OpenEJB.
>
>     System.setProperty("log4j.category.OpenEJB", "debug");
>     System.setProperty("log4j.category.openjpa", "debug");
>     java.util.Properties props = new java.util.Properties();
>     props.setProperty("java.naming.factory.initial",
> "org.apache.openejb.client.LocalInitialContextFactory");
>
> props.put("openejb.jndiname.format","{deploymentId}/{interfaceType.annotationName}");
>     props.put("openejb.deployments.classpath.ear", "false");
>     InitialContext ctx = new InitialContext(props);
>
>
> On a side note, I swapped out the call to OpenEJB.init(props) for the
> InitialContext equivalent.  It's ok to call OpenEJB.init() but we don't
> encourage it or consider it to be a part of the public API -- i.e. it's
> considered "internals" and could easily change or disappear without warning.
>
> A safer alternative if the call to setting "java.naming.factory.initial" is
> particularly bothersome -- which it can be -- would be to go directly after
> the LocalInitialContextFactory as in:
>
>     Context context = new
> LocalInitialContextFactory().getInitialContext(props);
>
> That's essentially what the InitialContext class does but skips the JNDI
> internals and gives you the direct result.
>
> -David
>
>


-- 
Karan Singh Malhi

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message