On 2/13/15 3:36 AM, Alessandro Manzoni wrote:
Il 12.02.2015 22.20, Rick Hillegas ha scritto:
Thank you Rick,
Hi Alessandro,
The simplest way to achieve your goal is to provide a public static
method which returns a custom java.io.OutputStream or java.io.Writer.
Then point to that method using the system property
derby.stream.error.field as described in the Reference Manual:
http://db.apache.org/derby/docs/10.11/ref/rrefproper33027.html Your
custom OutputStream/Writer can filter and reformat the Derby
diagnostics as you wish.
Well, I created my own PrinterWriter, I got one goal: derby.log is no
more used, output goes into System.err. I suspect that's because Derby
dislikes my writer!
I put into derby.properties:
derby.stream.error.field=it.qteam.udf.DbLogger.derbyLogger
when Derby starts it logs correctly my properties, then it logs that
classloader is using my jar, that's the same jar used for UDFs, that's
correctly loaded as UDFs run correctly.
I tried setting derby.database.classpath property with my jar, also
with a path relative to derby install directory, but log shows
"java.lang.ClassNotFoundException: it.qteam.udf.DbLogger"
I tried to add my jar to the same classpath that starts Derby, now the
class is found and is used to logout messages.
But Derby fails to start due to the exception:
org.apache.derby.impl.drda.DRDAProtocolException: Execution failed
because of Permanent Agent Error: SVRCOD = 40; RDBNAM =
mydb;autocommit=false;currentschema=mydb; diagnostic msg = Driver not
loaded
Reversing boot classpath Derby starts normally again, but my logger
class is not found again, as logs are written to stderr.
I suspect that I should load my jar in a different way. Which way?
Hi Alessandro,
I have never tried running a custom diagnostic logger from a jar file
stored in the database. I doubt that approach would work. The reason is
that the diagnostic logger needs to be shared by all databases booted on
the JVM. A diagnostic logger which lives in a jar file in a database
would only be accessible to that database and, crucially, would not be
available when the Derby engine comes up and performs system-wide
housekeeping before actually booting any databases.
I recommend that you leave your UDFs in the jar file stored in the
database. I also recommend that you put your diagnostic logger in a
separate jar file which is wired into the JVM classpath.
Let me know how that works out. I will be on the road for the next week,
so I apologize that my responses may come slowly.
Hope this helps,
-Rick
On 2/12/15 2:43 AM, Alessandro Manzoni wrote:
I need to log statements to derby.log. I already put
derby.language.logStatementText=true propertiy into derby.properties
file, and restarted te network server.
Now derby.log is growing as expected.
I didn't find a way to change the log format, Iwould like to change
the date format and log also the name of the user that executed a
statement.
Then I would like to log only statement that change the db, delete
update and insert, and avoid to log sysprocs calls.
Is there some way to achieve my goals?
Further more, even if the server is stopped, I cannot open derby.log
file because of an access denied error (it's windows).
The only way I found to browse derby.log is from a dos prompt opened
as Administrator, so it appear as an authorization problem.
That's not comfortable at all.
Is there a way to have Derby create derby.log with different
authorizations?
Maybe someone with more Windows experience can offer some advice
here. It sounds as though the server is being run from the
Administrator account. You could try running the server from some
less restricted account. You might be able to get around this problem
by directing derby.log to a less secure part of the file system. See
http://db.apache.org/derby/docs/10.11/ref/rrefproper18151.html.
Otherwise, you should be able to adjust the permissions on the
diagnostic log file if you pursue the derby.stream.error.field
approach described above.
I lack enough experience on windows too. It seems that only malwares do!
The problem is that Derby is running as a service with System account.
If I try to run the service as a local account the service do not
start, due to lack of autorizations on databases folder. If I try to
change folder authorization, windows (8.1) refuse to change
permissions on some files inside, and the service keeps fail to start.
Changing permissions on log file is not an option, when the file is
created again it will be restricted again.
Hope this helps,
-Rick
.
