'${sys:stardog.home}' directory

[Conrad Leonard]

I'm moving our Java & Groovy codebase across to Empire 1.0 and Stardog 4.0.

The biggest obvious change was moving all client api dependencies from 3.x jars to 4.0.

In re-running all our tests in Eclipse I have noticed the oddly-named directory '${sys:stardog.home}' being created whenever one of the tests runs, in the Eclipse workspace where the test was invoked.

It always contains the two files stardog.log and zookeeper.log, both of which are empty. Example:

[conradL@qimr13054 groovy]$ pwd

/home/conradL/workspace/groovy

[conradL@qimr13054 groovy]$ ls

${sys:stardog.home}  bin  lib  src  test

[conradL@qimr13054 groovy]$ ls '${sys:stardog.home}'

stardog.log  zookeeper.log

[conradL@qimr13054 groovy]$ ls -l '${sys:stardog.home}'/*.log

-rw-rw-r-- 1 conradL conradL 0 Nov 27 15:09 ${sys:stardog.home}/stardog.log

-rw-rw-r-- 1 conradL conradL 0 Nov 27 15:09 ${sys:stardog.home}/zookeeper.log

The creation of the '${sys:stardog.home}' directory doesn't seem dependent on what is in the test, and the tests are all pretty simple client-side stuff that connect to a Stardog database and check whether we can create/update/delete things, whereas those logs look like server-side logs.

Obviously a lot of the context is specific to us so I have been a bit hand-wavy in the description, but perhaps you can give me a pointer as to what might be going on here...

Something to do with moving to log4j logging?

[Conrad Leonard]

And after some digging I can (at least partially) answer my own question here.

The logging config log4j2.xml packaged in client/api/stardog-core-shared-4.0.jar contains the elements:

                <Property name="STARDOG_LOG">stardog</Property>

                <Property name="ZOOKEEPER_LOG">zookeeper</Property>

                <Property name="LOG_DIR">${sys:stardog.home}</Property>

and when stardog.home is not set using e.g. -Dstardog.home=/some/path then the logger returned from LoggerFactory.getLogger( ) in com.clarkparsia.empire.util.DefaultEmpireModule etc. is creating a directory named literally '${sys:stardog.home}'.

Not sure if that is the expected behaviour, but at least I can change it now.

Is there any other way to change client-side logging location?

[Fernando Hernandez]

Hi Conrad,

On Mon, Nov 30, 2015 at 1:33 AM, Conrad Leonard <conrad....@hotmail.com> wrote:

And after some digging I can (at least partially) answer my own question here.

The logging config log4j2.xml packaged in client/api/stardog-core-shared-4.0.jar contains the elements:

                <Property name="STARDOG_LOG">stardog</Property>

                <Property name="ZOOKEEPER_LOG">zookeeper</Property>

                <Property name="LOG_DIR">${sys:stardog.home}</Property>

and when stardog.home is not set using e.g. -Dstardog.home=/some/path then the logger returned from LoggerFactory.getLogger( ) in com.clarkparsia.empire.util.DefaultEmpireModule etc. is creating a directory named literally '${sys:stardog.home}'.

Not sure if that is the expected behaviour, but at least I can change it now.

Is there any other way to change client-side logging location?

You can pass in a configuration file using the  java system property `log4j.configurationFile` and override the behavior defined in core-shared.

Cheers,

Fernando

[Conrad Leonard]

Thanks Fernando. 

I think it would also be useful to make mention of client-side logging in the documentation, in particular the reference to stardog.home in the default log4j2.xml in core-shared jar.

In a client-side environment I would expect many folks would not otherwise see the need to set this system property since in other contexts it refers to the server-side data home.

cheers,

C

On Friday, 27 November 2015 15:32:10 UTC+10, Conrad Leonard wrote:

[Fernando Hernandez]

On Mon, Nov 30, 2015 at 7:25 PM, Conrad Leonard <conrad....@hotmail.com> wrote:

Thanks Fernando. 

I think it would also be useful to make mention of client-side logging in the documentation, in particular the reference to stardog.home in the default log4j2.xml in core-shared jar.

In a client-side environment I would expect many folks would not otherwise see the need to set this system property since in other contexts it refers to the server-side data home.

You are correct. We will address this issue (#2688) in a future release.

Cheers,

Fernando