EJB3 Annotations für Session Beans mit einem Parameter ?

[Matvei]

Ich hab folgendes Problem:

- ich möchte ein Session Bean Objekt für mehrere Log4j Logging Zwecken erzeugen
- ich habe mehrere MDBs und möchte mehrere Daten vom MDBs an mehrere Log4j Loggers mit der Hilfe von Session Bean melden
- die Idee ist etwas ähnliches zu benutzen (oder eigene Annotation mit einem Parameter zu erzeugen)

@EJB ("LoggerForIncomeInfo")
private Monitoring monitor;

wo "Monitoring" Session Bean ist.

also, in meinem Monitor möchte ich gerne die Möglichkeit haben den Parameter "LoggerForIncomeInfo" zu ermitteln und entsprechendes Log4j Logger Objekt zu benutzen.
Wenn ich mindestens wusste welche Klasse ruft Session Bean Objekt - es könnte mir helfen (Klasse analisieren, Annotations holen - fertig).

Danke

 

[FArt]

Das mit den Sessionbeans zu Loggingzwecken hört sich sehr verquer an.

Beschreibe doch mal, was du eigentlich erreichen möchtest. Ich könnte mir vorstellen, dass man das u.U. mit reinen Log4J-Mitteln erreichen kann.

Welcher Applicationserver?

 

[Matvei]

Log4j hat an diese Stelle am wenigstens zu tun, ich muss nun wissen wer die Daten Loggen will.

Also die Idee ist:

- wir haben mehrere MDBs
- wir haben Session Bean (Monitor) mit, sagen wir, 3 Methoden: log(),info(),trace()

in jedem MDB steht nur eine Konfugirationszeile:

@EJB("FromInfoChecker")
Monitor monitor;

oder

@MyOwnMarkerAnnotation("FromInfoChecker")
@EJB
Monitor monitor;

jetzt kann ich alle mögliche Varianten in meinem Monitor benutzen, z.b. ein Logger pro MDB, die Idee ist vom Log4j Logger komplett zu abstrahieren, monitor ist monitor und logger ist logger. MDBs loggen irgendwelche Information und haben keine Vorstellung an welche Stelle diese Information weiterleitet wird.

Ich benutze JBOSS 5.1, Loggers kann ich entweder in einem log4j.properties Datei in meiner EJB Datei speichern oder direkt in $JBOSS_HOME/server/[config name]/conf/jboss-log4j.xml
Meinen Sie ich muss für jede Klasse einen Logger erzeugen? Das Hilft mir eigentlich nicht viel, weil ich sicher bin, dass ich in der Zunkuft zusätzliche Aufgaben erfüllen muss, genau beim Logging (z.b. JMS Nachricht verschicken), deswegen möchte ich gerne eine neutrale Klasse benutzen.

 

[FArt]

Hm, das war noch nicht ganz die Erklärung was eigentlich erreicht werden soll.

Es geht um Logging... ein SessionBean mit den Methoden log(), info(), und trace() macht keinen Sinn, denn das realisiere ich mit einem Logger. Im Prinzip hat jedes MDB z.B. seinen eigenen Logger. Logger bedeutet ja nur, dass hier Logmeldung reingesteckt werden. Erst ein Appender sammelt Informationen zusammen und gibt sie aus. Dazwischen steht ein Mapping und evtl. Filter (ein Teil der Log4j Konfiguration), mit der ich festlege, welche Logger (einer, mehrere) auf welche Appender (einer, mehrere) loggt. Das ist die Abstraktion zwischen Logmeldung erzeugen und ausgeben und das ist eine Aufgabe von Log4J.

Beim Logging sollen keine zusätzlichen Aktionen passieren. Das wäre äußerst schlechtes Design. Anders wäre es, wenn man anstatt in eine Datei zu loggen plötzlich eine JMS Message als Logmeldung verschicken möchte oder ein SNMP-Trap oder was anderes, für andere "Empfänger". Das realsiert man wiederum nur über Log4J, indem man einen passenden Appender verwendet, z.B. einen JMS-Appender.

Wenn ich alles einigermaßen richtig verstanden habe, liegt hier ein suboptimales Design für Logging / Monitoring vor. Noch mal die Frage: was soll eigentlich wirklich erreicht werden? Damit meine ich die Anforderungen, die zu obigem Design bzw. zu der Frage geführt haben?

 

[Matvei]

Das Problem ist nun, dass ich nie wissen kann, was ich demnächst mit der technische Information machen soll, z.b. habe ich Vorgaben zusätzlich zum Logging Message eine Datei pro MDB JMS auf die Festplatte anlegen. Was sonst noch dazu kommt - bisher unklar. Deswegen meine Idee war komplett vom Log4j zu abstrahieren (und ja, es ist auch nicht klar, ob ich log4j in der Zukunft benutzen darf oder sonst noch, z.b. UC4 für einige Objekte) und Session Bean für solche Zwecken benutzen. Ich definiere nur Interface und die Realisierung wird frei wählbar, log4j war nur ein Beispiel was dahinten steckt. Hauptsache: in meinem Session Bean Objekt muss ich genau wissen welche Klasse ruft eine Methode aus diesem Session Bean. Natürlich kann ich eine abstrakte Klasse erzeugen und dann mehrere "Nachfolger" für jeden MDB, dieses Design gefällt mir aber auch nicht besonders.

 

[FArt]

Meine Erfahrung mit schwammigen und nicht zu Ende gedachten Anforderungen: größtenteils ignorieren bzw. so weit spezifizieren lassen, dass man für eine erste Version handfeste Aussagen hat.
Die einzige Lösung ist ein sauberes, offenes Design für die Anforderungen, die man bereits hat. Wenn das gelungen ist, kann man jederzeit weitere Anforderungen sauber einarbeiten, wenn sie denn kommen und spezifiziert sind.


Das prinzipielle Vorhaben lässt sich theoretisch lediglich mit Log4J realisieren, das wäre aber evtl. ein Missbrauch der API.

Prinzipiell scheint es um eine Art Observermechanismus zu gehen. Mehrere Teilnehmer interessieren sich für bestimmte Ereignisse. Also würde ich genau so eine Schnittstelle definieren. Dazu kann es dann verschiedene Implementierungen geben, z.B. Observer/Observable, die über ein JMS Topic kommunizieren, eine SNMP Schnittstelle usw.
Damit man diese auch frei kombinieren kann (also der Observable verbreitet seine Informationen per JMS während ein Observer mit einem anderen Protokoll darauf reagiert, können als Observer auch Bridges implementiert werden, die also nur eine Protokollumsetzung realisieren.

Log4J ist für Logging da, das sollte auf jeden Fall zum Einsatz kommen... und einfache Observer können Implementierungen sein, die lediglich eine Bridge zu Log4J bilden.

Das wäre mein Vorschlag ... eine einfache, schlanke Schnittstelle fern von Implementierungdetails...

Noch ein Vorschlag: wenn man die vorhanden Anforderung einsammelt, kann man oft sogar eine fertige Lösung verwenden ohne selber das Rad neu erfinden zu müssen...

Überdenke noch mal deinen Ansatz, ich glaube es lohnt sich...