Wie kann ich Clientinformationen an SessionBean weitergeben

[kwyjibo_84]

Hallo, Zusammen,

ich habe da ein (so dachte ich) einfaches Problem.
In ersten Linie geht es darum beim Lookup einer Session-Bean eigene bzw. Client-Informationen mitzugeben.

Ich hab also irgendwo eine (Stateful) Session-Bean die auch in meinen JBoss im Global JNDI Namespace auftaucht.

D.h. ich kann mir irgendeine Klasse mit ner main-Methode machen und meine Session-Bean (MySessionBean) holen:

Properties properties = new Properties();
properties.put(Context.INITIAL_CONTEXT_FACTORY, "org.jnp.interfaces.NamingContextFactory");
properties.put(Context.URL_PKG_PREFIXES, "=org.jboss.naming:org.jnp.interfaces");
properties.put(Context.PROVIDER_URL, "localhost:1099");
Context context;
context = new InitialContext(properties);

IMySessionBeanRemote sb = (IMySessionBeanRemote) context.lookup("MySessionBean/remote");

In meiner Session-Bean kann ich mir jetzt den SessionContext holen:

@Resource
SessionContext sessionContext;

So... ich hatte nun die Idee, dass ein Client der "environment" des InitialContext einfach noch eine eigene Property hinzuzufügen kann:

properties.put("meine.property", "hallo");

Und jetzt würde ich gerne die Information die ich dem InitialContext mitgegeben hab in meiner Session-Bean wieder auslesen.
Das hier darf man nicht mehr (Deprecated):

Properties props = sessionContext.getEnvironment();

Javadoc sagt: Use the JNDI naming context java:comp/env to access enterprise bean's environment.

Was bedeutet das?

Bin ich total auf dem Holzweg mit InitialContext?

Gibt es einen einfacheren oder richtigen Weg um textuelle Informationen eines Clients einer Session-Bean zu Verfügung zu stellen?

Vielen dank für eure Antworten,
Sebastian

[Alwin Ibba]

Hallo Sebastian,

environment properties sind schon seit Ewigkeiten deprecated. Die waren glaube ich ganz am Anfang mal drin. Sie wurden ersetzt durch environment entries. Man definiert im ejb-jar.xml irgendwelche Werte (ähnlich properties mit key und value) und kann diese dann über JNDI abfragen. Mit den InitialContext properties des Clients hat und hatte das noch nie was zu tun (komplett andere Baustelle).

Der Client kann keine properties an die EJB übergeben. Bei stateless session beans wäre das sowieso unsinnig. Bei stateful EJBs würde es ev. noch Sinn machen, geht aber trotzdem nicht. Du mußt eine Methode bauen und die Information als Parameter übergeben.

Viele Grüße,

Alwin

[kwyjibo_84]

Hallo Alwin,

danke für deine Antwort.

Wenn ich dich richtig verstehe; Environment entries kann man ja nur für statische Informationen d.h. Konstanten nutzen.

Du hast dann gemeint, ich muss eine Methode bauen und die Information als Paramter übergeben.

Meinst du das so:
Ich mach mir ne Stateful-Session-Bean um die Informationen eines Clients abzulegen:

@Stateful
public class ClientInformation {
   //...
   void putInformation(String key, String value) {
      //...
   }
}

Dann holt sich der Client über ein lookup eine Instanz von der ClientInformation:

//...
public static void main(String[] args) {
   // InitialContext-env setzen
   IClientInformation ci = context.lookup("ClientInformation/remote");
   ci.putInformation("myKey", "client1");
   //...

Dann existiert also jetzt im Container für meinen Client eine Stateful-Session Bean in der myKey=client1 steht.

OK. Wie kann aber jetzt z.B. eine Stateless-Session-Bean die vom Client aufgerufen wird an diese Information kommen?

Der Client macht also in der main-Methode weiter und holt sich ne Stateless-Session-Bean und ruft eine Methode auf:

//...
   IMyStateLESSSessionBean ssb = context.lookup("MyStateLESSSessionBean/remote");
   ssb.doSth();
}

Jetzt würde ich gerne in der Stateless-Session Bean die Client-Information für jeden Client auslesen:

//...
   void doSth() {
      IClientInformation ci = // ??? hol dir die Client-Information irgendwie, vielleicht über den SessionContext ???
      log.info(ci.get("myKey"));
   }
//...

D.h. ruft Client 1 die Bean auf, soll meine Stateless-Bean mit den Werten von Client 1 arbeiten und wenn Client 2 die Bean aufruft soll sie mit den Werten von Client 2 arbeiten.

Sicher, ich könnte der Stateless Bean als Parameter die Client-Informationen mitgeben. Aber das will ich eigentlich nicht. Ich hätte eigentlich gerne so etwas wie eine HttpSession mit seinen setAttribute und getAttribute. Damit ein Client setAttribute aufrufen kann und für jeden Client auf der Server-Seite die Attribute wieder ausgelesen werden können.

Ist sowas möglich, oder habe ich dich falsch verstanden.

Danke,
Sebastian

[Alwin Ibba]

Hallo Sebastian,

Ja, diese environment-Geschichten sind nur für statische Konstanten auf dem Server und nicht wirklich nützlich. Dasselbe erreicht man auch mit herkömmlichen property-Dateien.

Zu Deinem Problem: Das HttpSession-Äquivalent ist die stateful bean. Die stateless bean kann aber nicht wissen in welcher "session" die Daten stehen, da sie von mehreren Clients benutzt wird. Dies mußt Du ihr irgendwie mitteilen. Dazu kannst die Informationen bei jedem Methodenaufruf direkt mitgeben, dann stellt sich aber die Frage wozu die stateful bean gut sein soll. Du kannst auch eine Referenz auf die stateful bean bei jedem Methodenaufruf mitgeben und die stateless bean fragt die Instanz der stateful bean nach den aktuellen Parametern. Um beim Http-Vergleich zu bleiben: Die session auf dem Server hat eine ID und bei jedem Aufruf gibt der Browser (Client) diese ID an den Server (z.b. per cookie). Anders könnte der Server die session nicht zuordnen weil Http stateless ist. Dasselbe gilt analog für die stateless EJBs.

Viele Grüße,

Alwin

[kwyjibo_84]

Hallo Alwin,

danke für deine schnelle Antwort.

Da stellt sich mir dann natürlich die Frage: Wann benutze ich den SessionContext?

Könnte ich nicht mit

@Resource
SessionContext context;

in einer Stateless-Session-Bean irgenwie das zum Client gehörige Objekt finden?
Oder für was verwende ich den SessionContext?

Somit komme ich wiedermal vom hundertsten ins tausendste

Sebastian

[Alwin Ibba]

Den SessionContext benutzt Du z.b. zur Transaktionssteuerung bei BMT oder um Zugriff auf das eigene home oder remote interface innerhalb der Bean-Klasse zu bekommen. Für Dein Problem nützt er Dir nichts.

[kwyjibo_84]

Ok, dann danke für deine Aufklärung.

Falls ich eine Lösung finde dich mich zufrieden stellt, poste ich sie hier.