Logging mit Java ohne Notes Logging API

[Boost]

Hallo,

Ich möchte in meine Notes Applikation Logging einbauen, ohne die Notes Logging API zu benutzten.

Ich habe folgenden Code in einer Java Script Library stehen :

      Logger logger = Logger.getLogger("Console");
      MemoryHandler handler = new MemoryHandler(new ConsoleHandler(),1000,Level.CONFIG);
      logger.addHandler(handler);

Leider bekomme ich folgende Exception:

java.security.AccessControlException: access denied (java.util.logging.LoggingPermission control)
   at java.security.AccessControlContext.checkPermission(AccessControlContext.java:292)
   at java.security.AccessController.checkPermission(AccessController.java:476)
   at java.lang.SecurityManager.checkPermission(SecurityManager.java:538)
   at COM.ibm.JEmpower.applet.AppletSecurity.superDotCheckPermission(AppletSecurity.java:1397)
   at COM.ibm.JEmpower.applet.AppletSecurity.checkPermission(AppletSecurity.java:1479)
   at COM.ibm.JEmpower.applet.AppletSecurity.checkPermission(AppletSecurity.java:1412)
   at java.util.logging.LogManager.checkAccess(LogManager.java:848)
   at java.util.logging.Logger.addHandler(Logger.java:1142)
   at com.ibm.vse.lotus.console.ConsoleMessageThread.runNotes(ConsoleMessageThread.java:81)
   at lotus.domino.NotesThread.run(Unknown Source)

Kann mir jemand sagen wie ich den/die Handler (oder vielleicht Notes) konfigurieren muss damit das Logging klappt?
Hat jemand schon mal so etwas gemacht?

[animate]

Ich denke du musst den Logging-Klassen Zugriff auf deine Anwendung geben. Ich kenne mich damit nicht aus in Notes, aber in diesem Artikel könnte eine Hilfe stehen: http://lekkimworld.com/lekkimworld/2006/04/25/1145963331004.html

[animate]

Ein Beispiel aus der Tomcat - Policy fürs Commons-Logging Framework. Vielleicht hilft dir das:

// These permissions apply to the commons-logging API
grant codeBase "file:${catalina.home}/bin/commons-logging-api.jar" {
        permission java.security.AllPermission;
};

Dieser Eintrag gewährt dem Commons Logging API alle Zugriffsrechte.

[Boost]

In meiner java.policy Datei für die Notes JVM steht u.a. folgendes:

// Standard extensions get all permissions by default

grant codeBase "file:${java.home}/lib/ext/*" {
   permission java.security.AllPermission;
};

// Notes java code gets all permissions

grant codeBase "file:${notes.binary}/*" {
   permission java.security.AllPermission;
};

Bedeutet das nicht, dass die JVM und mein Code alle Permissions haben?

[umi]

Kennst Du das OpenLog? http://www.openntf.org/projects/pmt.nsf/ProjectLookup/OpenLog
Logging Tool welches sowohl LS als auch Java kann.

[flaite]

... ist nur die Frage, ob du tatsächlich die richtige policy Datei editierst.
Falls der code in einem Nortes Java Agenten ist (was ich vermute):
Im 2. Tab des Notes Java Agenten im sogenannten "Notes-Designer" gibt es eine Selectbox für Agentensicherheit (zumindest ab Version 6).
Oft ist es das.

[Boost]

@ umi
Unter welcher Lizenz steht dieses Tool?
Ich hab auf der Seite keinen Hinweis gesehen.

@ Axel
Ich habe den Code in einen Agenten gepackt zum testen, eigentlich steht er in einer Java Script Library.
Eine Änderung am Runtime security level (egal ob 1,2 oder 3) bringt keine Änderung, sonder immer die gleiche Exception.

Aber:
Mit Looger.getAnonymousLogger() gehts!
Könnte mir jemand sagen warum?

[umi]

Author ist Robichaux. www.nsftools.com.
Keine Ahnung wie die Lizenz aussieht. Höchstwahrscheinlich frei.

[flaite]

@Boost: Ist das schlimm?
Ich benutz eigentlich immer Log4j (nicht mit Notes), aber wenn ich die Api-Doc richtig lese, hat das was mit Applet Security zu tun, die ja aus mir übrigens völlig unklaren Gründen in Notes Agenten verwendet wird. Kann sein, das Lotus diesen Anwendungsfall einfach übersehen hat.
Gibt es ein Problem mit dem anonymous logger?

This factory method is primarily intended for use from applets. Because the resulting Logger is anonymous it can be kept private by the creating class. This removes the need for normal security checks, which in turn allows untrusted applet code to update the control state of the Logger. For example an applet can do a setLevel or an addHandler on an anonymous Logger.

@Umi: die Sun Logging Klassen wurden von Sun Engineers erstellt und auf diesem Planeten millionenfach getestet. Das von dir genannte Projekt von Julian Robinchaux (und es wurde vielleicht 1000 mal installiert). Ich würde in Projekten auch deutlich die solidere Lösung präferieren (d.h. die von Sun).

Gruß Axel

[Boost]

Ich habe den anonymous Logger noch nicht wieter getestet, da ich erst heute die Spezifikationen des Loggings festgeklopft habe. Um ausgiebieger zu testen müssen erst noch einen Handler für Notes und einen Formatter für ein vorgegebenes Format her.
Bei ersten Tests, die nur Ausgabe auf die Konsole geschrieben haben, hat soweit alles funktioniert.
Ich werde in den nächsten Tagen posten wie es läuft.

Wenn keine weiteren Probleme ausser dem nicht anonymen Logging auftreten, werde ich die Sun API verwenden. Wenn das Programm zum Kunden geht, kann ich nicht einfach fremden Code einbauen, ohne die Lizenz zu kennen, und die ist auf der Seite nicht eindeutig, zumindest für mich nicht.

Gibt es eine Möglichkeit, die Sicherheitseinstellungen zur Laufzeit anzupassen, so dass ein Logger mit Namespace als vertraueswürdig eingestuft wird und läuft?

[flaite]

Gibt es eine Möglichkeit, die Sicherheitseinstellungen zur Laufzeit anzupassen, so dass ein Logger mit Namespace als vertraueswürdig eingestuft wird und läuft?

Theoretisch Policy Dateien.
http://www.galileocomputing.de/openbook/javainsel3/javainsel_240001.htm#Rxxjavainsel_240001460RechtevergebendurchPolicyDateien
Vielleicht hast du ja einen Fehler bei der Konfiguration der policy Datei gemacht (was sehr leicht passieren kann).

[flaite]

Was du natürlich auch machen kannst:
Eine münchener Consulting (beck et al) hat eine ziemlich gründliche Api rund um Notes herausgebracht. Die Sachen, die ich mir mal angeschaut habe, sehen sehr gut aus.
Die haben auch spezielles Zeugs für Logging.
Wenn du Zeit und/oder Lust hast, schaus dir an.
http://domingo.sourceforge.net/ (Jdk14LoggerMonitor).


 

[Boost]

Danke für die vielen Hinweise. Ich werde sie mir die API anschauen.

[Boost]

Kurzes Update:
Das Problem scheint die Zeile mit logger.addHandler(handler) zu sein.
Weis jemand, wie man die Handler benutzen kann, bzw. muss ?

[domino java]

Hallo,

Ursache ist definitiv die Java Security.
Hierfür musst du in einer Domino Standard-Installation (Windows) die Datei

c:\lotus\domino\jvm\lib\security\java.policy (für einen Domino Server)
bzw.
c:\lotus\notes\jvm\lib\security\java.policy (für einen Notes Client)

bearbeiten.
Offenbar benötigen die Klassen
java.util.logging.LogManager
und java.util.logging.Logger.addHandler

besondere Rechte (in der Java Security), die du dort über einen Grant Befehl zuweisen kannst.
Testhalber versuchen:

grant {
   permission java.security.AllPermission;
};

Das erlaubt allen alles. SEHR UNSICHER. Nur für einen Test verwenden.
Alternativ die JAR-Datei des Logging-Frameworks in den Pfad c:\lotus\domino\jvm\lib\ext legen. Code aus JAR-Dateien in diesem Verzeichnis erhalten per Default alle Rechte.

Ansonsten darf ich (in aller Bescheidenheit) die Adresse http://www.domino-java.com empfehlen. Dort gibt es einen Domino-tauglichen Wrapper für log4j, der dazu noch selbst-konfigurierend ist (bei log4j eine grosse Hilfe).

Gruß

Thomas

[kriede]

Hallo Thomas,

normalerweise wird LogJ benutzt, um in eine Datei zu loggen, und genau hier liegt die Ursache für die AccessControlException: Schreiben in Dateien ist in der Standardeinstellung für Java-Agenten nicht erlaubt. Es gibt drei Wege, dies zu ändern:

1. java.policy file
2. Server-Dokument
3. Agent-Settings

Weg 1 ist nicht empfehlenswert, da diese Einstellungen dann für den gesamten Server und alle Benutzer gelten und so bei unvorsichtigem Vorgehen die Sicherheitsmechanismen von Java unterwandert werden und somit der Server potentiell verwundbar wird.

Weg 2 erlaubt, bestimmten Usern, z.B. dem Agent-Signer, mehr Rechte zu gewähren. Dies ist ein typisches Vorgehen, um Agenten die nötigen Rechte zuzuteilen. Siehe Server-Dokument -> Security -> Programmability Restrictions -> Run unrestricted methods and operations: Benutzer oder Gruppe angeben, die unbeschränkten Zugriff auf das OS erhalten soll.

Weg 3 ist noch spezieller und ermöglicht eben nur bestimmten Agenten, Sonderrechte zu erteilen. Siehe Agent-Settings -> zweites Tab (Security) -> Set runtim security level -> Allow restricted operations.
Soweit ich mich erinnere zieht diese Einstellung nur in Kombination mit Möglichkeit 2, am besten mal ausprobieren.

Im Rahmen einer SAP-Integration über WebServices habe Ich Log4J mit diesen Einstellungen bereits erfolgreich und produktiv in Lotus Domino eingesetzt, ohne Manipulation der java.policy. Falls Du noch Fragen dazu hast, stelle sie einfach hier in diesem Thread.

Falls Du über einen eigenen Appender in eine Notes-Datenbank loggen möchtest, dann ist das alles nicht nötig, denn Zugriff auf Notes-Datenbanken hat jeder Agent in jedem Fall (solange er über die ACL der Datenbank berechtigt ist).

Ich hoffe, das hilft Dir weiter.

Gruß
Kurt

[Boost]

Danke für die Hinweise.
.policy fällt flach, denn wenn die DB an den Kunden geht, müsste ihm das jemand  erklären und der Kunde müsste es verstehen.

2. Server-Dokument

Weg 2 erlaubt, bestimmten Usern, z.B. dem Agent-Signer, mehr Rechte zu gewähren. Dies ist ein typisches Vorgehen, um Agenten die nötigen Rechte zuzuteilen. Siehe Server-Dokument -> Security -> Programmability Restrictions -> Run unrestricted methods and operations: Benutzer oder Gruppe angeben, die unbeschränkten Zugriff auf das OS erhalten soll.

Das funktioniert serverseitig, richtig?
Wenn ja, die gleiche Einschränkung wie oben, zusätzlicher Administrationsaufwand ist nicht zumutbar.

3. Agent-Settings

Weg 3 ist noch spezieller und ermöglicht eben nur bestimmten Agenten, Sonderrechte zu erteilen. Siehe Agent-Settings -> zweites Tab (Security) -> Set runtim security level -> Allow restricted operations.
Soweit ich mich erinnere zieht diese Einstellung nur in Kombination mit Möglichkeit 2, am besten mal ausprobieren.

Funktioniert das auch mit Java Script Libraries?
Ich habe keine Einstllungen gesehen.
Ich brauche Threads die mit einer GUI aufgerufen werden, und nicht von Agenten.

Falls Du über einen eigenen Appender in eine Notes-Datenbank loggen möchtest, dann ist das alles nicht nötig, denn Zugriff auf Notes-Datenbanken hat jeder Agent in jedem Fall (solange er über die ACL der Datenbank berechtigt ist).

Könntest du genauer erklären, was du mit Appender meinst?

[flaite]

Könntest du genauer erklären, was du mit Appender meinst?

In log4j speak, an output destination is called an appender.

Du kannst einen eigenen Appender schreiben. Oder vielleicht gibts schon einen fertigprogrammierten Appender, der in Notes-Datenbanken schreibt.
Domino Java hat doch einen Tipp genannt. Hilft das nicht weiter?

Ansonsten darf ich (in aller Bescheidenheit) die Adresse http://www.domino-java.com empfehlen. Dort gibt es einen Domino-tauglichen Wrapper für log4j, der dazu noch selbst-konfigurierend ist (bei log4j eine grosse Hilfe).

[Boost]

Erst mal danke für dien Hinweis auf den Wrapper.
Aber Log4j ist teil des Apache Projekts, d.h. ein eigenes Paket, der Wrapper ebenso.
Das kann ich aber leider nicht bundeln und mitschicken, sodern ich dürfte nur einen Link geben mit dem Hinweis "Bitte dort runterladen".
Dann müsste das Paket noch in die Notes JVM kommen.
Deshalb werde ich Log4j und den Wrapper nicht verwenden.

[flaite]

Aber Log4j ist teil des Apache Projekts, d.h. ein eigenes Paket, der Wrapper ebenso.
Das kann ich aber leider nicht bundeln und mitschicken, sodern ich dürfte nur einen Link geben mit dem Hinweis "Bitte dort runterladen".
Dann müsste das Paket noch in die Notes JVM kommen.

Wie jetzt runterladen? Man muß einfach den Admins die entsprechenden jars aushändigen und dann können sie diese ins <Notes-Programm>\jvm\lib\ext Verzeichnis der Domino JVM tun. Man kann dafür sogar eine eigene Routine für schreiben, falls dies vowe.net lesende Systemadministratoren überfordern sollte 
So etwas vorzuschlagen, war nie ein Problem.
Vielleicht liegt das daran, dass ichseit Jahren aus-weiss-nicht-warum Gründen nur noch Kunden aus dem sehr ITisierten Banken- und Versicherungsumfeld habe. Bei den anderen kommt das dann später auch.