Websphere startup beans --> equivalent in JBOSS?

C

ChrisJava

Grünschnabel
hallo alle zusammen,

ich würde gerne das eine meiner Stateless Session Beans im JBOSS, mit dem JBOSS gestartet wird. Ich habe über Onkel Google nicht allzu viele Informationen herausfinden können.

Ich habe für den Websphere ein proprietäres Feature gefunden, welches wohl exakt das macht was ich mir wünsche. Und zwar die im Topic erwähnten Startup Beans. Nur würde ich es gerne mit Mitteln nach EJB3 machen, und natürlich im JBOSS.
ist das möglich? Falls nicht gibt es für den JBOSS ein ähnliches proprietäres Feature?
Ich habe leider bei meinen Recherchen nur einen hinweis auf ein Szenario mit MBeans gefunden. Dies habe ich leider nicht zum laufen bekommen.

Über hilfe würde ich mich freuen. Ich hänge an diesem Thema schon einige Zeit.

Danke

Christian
 
also gestartet heisst folgendes:

es soll beim application server start, oder halt beim deploy meiner anwendung, eine instanz dieser stateless session bean angelegt werden.

@PostConstruct würde erst ausgeführt werden wenn ein anderes Objekt eine Referenz auf dieses Objekt anfordert, da es dann erst Instanziert wird!?

Normalerweise würde ja die Bohne erst instanziert werden, wenn ein Client oder eine andere Bohne darauf zugrieft.

Ich möchte aber das das vorher schon passiert damit ich mir bestimmte daten zum "start" der application cachen kann...

Ich habe nun für den JBOSS die Annotation @Service gefunden.
Mit @Service kann ich einer klasse die ein bestimmtes interface implementiert die fähigkeit geben von jboss beim deploy gestartet zu werden.

zwar ist dieses feature jboss spezifisch und dadurch natürlich nicht portabel, aber eventuell gibt es ja so etwas in ejb4 ;)

naja wie dem auch sei, für interessiert hier mal ein snippet code...

erst einmal das interface welches mit @Management annotiert ist.
ps: ihr könnt diese @Service beans einfach über jmx anwenden.
Code: 
import org.jboss.ejb3.annotation.Management;


@Management
public interface StartupManagement {

	void create() throws Exception;
	void start() throws Exception;
	void stop() throws Exception;
	void destroy();
	
}

nun die implementierung der @Service klasse

package com.aastra.hermes.ejb3;

Code: 
import javax.ejb.EJB;
import org.jboss.ejb3.annotation.Service;

@Service
public class Manager implements StartupManagement, ManagerLocal, ManagerRemote {


	@Override
	public void startup() {
               // do some things at app startup 
	}

	@Override
	public void create() throws Exception {
		// TODO Auto-generated method stub
		
	}

	@Override
	public void destroy() {
		// TODO Auto-generated method stub
		
	}

	@Override
	public void start() throws Exception {
		// application start here! 
	}

	@Override
	public void stop() throws Exception {
		// application stop here 
		
	}


}

diese @Service beans können auch local und remote interfaces haben, sind also vom verhalten so wie session beans.

mfg
 
Du solltest überdenken, ob es sinnvoll ist zwischen Applikationsstart und Komponenteninstantiierung zu unterscheiden. Wenn die Komponente wirklich gebraucht wird, wird sie eh beim Appstart mit instantiiert und dann greift @PostConstruct.

Im Klartext: ist es wirklich relevant, dass die Daten beim Appstart gecached werden? Warum reicht es nicht, dass beim ersten Zugriff zu tun?

Ich persönlich würde mich nicht an ein API eines Appserver herstellers binden. Wie testest du sowas dann?

Ollie

PS: mit JavaEE 6 kommt wahrscheinlich ein @Startup um sicherzustellen, dass die Komponente beim start instanttiert wird.
 
Oliver Gierke hat gesagt.:
Du solltest überdenken, ob es sinnvoll ist zwischen Applikationsstart und Komponenteninstantiierung zu unterscheiden. Wenn die Komponente wirklich gebraucht wird, wird sie eh beim Appstart mit instantiiert und dann greift @PostConstruct.

Im Klartext: ist es wirklich relevant, dass die Daten beim Appstart gecached werden? Warum reicht es nicht, dass beim ersten Zugriff zu tun?

Ich persönlich würde mich nicht an ein API eines Appserver herstellers binden. Wie testest du sowas dann?

Ollie

PS: mit JavaEE 6 kommt wahrscheinlich ein @Startup um sicherzustellen, dass die Komponente beim start instanttiert wird.
Zum Vergrößern anklicken....

Aber klar ist es sinnvoll etwas beim appserver startup zu instanzieren, aus welchem Grund sollten dann Leute darüber nachdenken eine @Startup annotation zu entwerfen? ;) Anwendungsfälle hierfür gibt es zu hauf. Wenn man mal von der Standard Web Application absieht.
leider brauche ich dieses feature jetzt schon. also wird solange bis @Startup verfügbar ist @Service mit einem TODO im code genutzt ...


mfg
 
Nur weil etwas standardisiert ist, heißt es noch lange nicht, dass es sinnvoll ist. Bestes Beispiel: WS-* Spezifikationen. Gibts zu hauf, nutzt *niemand*. Selbst wenn etwas grundsätzlich sinnvoll ist, heißt das wiederum auch nicht, dass es für deinen entsprechenden Fall sinnvoll ist. IMHO bleibt ein konzeptionelles Problem, kein technisches...

My 0,02€...

REINHAUN!
 
Hallo,

hast du auch ne Web App in deiner Anwendung? Wenn ja würde ichs mit einem javax.servlet.ServletContextListener probieren.

Gruß Tom
 
hallo thomas,

ja ich habe auch eine Web App in meiner Solution.
Nutze Sie aber nur für verschiedenste WebServices.
Es wiederstrebt mir aber meine Bean über irgendwas mit Servlets zu starten, wenn es entsprechende Annotationen gibt, bzw. standardisierte geplant sind.
Hört sich irgendwie nach Workaround an!
 
Hallo,

Es wiederstrebt mir aber meine Bean über irgendwas mit Servlets zu starten, wenn es entsprechende Annotationen gibt, bzw. standardisierte geplant sind.
Hört sich irgendwie nach Workaround an!
Zum Vergrößern anklicken....

Na ja, erstmal hat das außer dem Namen mit normalen Servlets nicht so viel gemeint. ServletContextListener.contextInitialized wird aufgerufen wenn die Web App gestartet wird (beim Deployment).

Dort könntest du dann deine SessionBean aufrufen oder gleich dort den Code ausführen den du beim start der SessionBean ausführen wolltest.

Allgemeine Container callbacks (Init/Shutdown) gibts erst mit EJB 3.1
http://jcp.org/en/jsr/detail?id=318
Requests:
...
Application-level callback notifications, including for container initialization and shutdown
...
Zum Vergrößern anklicken....

Das ist IMHO kein Workaround, sondern ein App-Server neutraler Weg dein Vorhaben mit JEE 5 Mitteln zu realisieren.

In EJB 3.1 könntest du beispielsweise ein Bean mit
@Singleton
@Startup
Annoations deklarieren. Dann sollte der Container die mit @PostConstruct Annotierte Methode des Singletons aufrufen.
Es ist jedoch abhängig vom Container wann das Singleton nun erzeugt wird... aber in der Spec wird das so beschrieben um auf Container-Callbacks reagieren zu können.

Mehr dazu gibts in Kapitel 4.8.1 im EJB 3.1 Proposed Final Draft beschrieben.

Gruß Tom
 
ok, danke für deine erläuterung.
Die ganze Java Welt ist noch neu für mich. Ich habe noch keinen genauen Überblick.
Vielen dank für eure Hinweise ich werde das ganze jetzt wohl noch mit ServletContextListener probieren.

Gute Diskussion hier im Forum ;)

Mfg und schönen Tag noch!

Christian
 
Um antworten zu können musst du eingeloggt sein.

Neue Beiträge

Zurück