JSP-Zugriff auf Session-Bean

Hando84

Grünschnabel
Ich möchte in NetWeaver von einer JSP(in EAR1) auf ein Session-Bean(in EAR2) zugreifen.
Beide EAR's sollen auf dem gleichen Server liegen, einem SAP 7.1 Web-Application-Server.

Jedoch funktioniert das ganze nicht so wie es soll.
Sobald ein narrow auf das interface erzeugt werden soll bricht die Funktion ab.

So sieht mein JSP aus:

<%@ page language="java" contentType="text/html; charset=UTF-8"
pageEncoding="UTF-8"%>

<%@ page import="javax.naming.Context, javax.naming.InitialContext,
javax.rmi.PortableRemoteObject, com.sap.sdn.ejb.HelloWorldLocal" %>


<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>Hello World</title>
</head>
<body>

<%

try {
Context ctx = new InitialContext();
Object o = ctx.lookup(
"com.tsi/MS_HelloWorldEAR/LOCAL/HelloWorldBean/com.sap.sdn.ejb.HelloWorldLocal");
HelloWorldLocal helloRef = (HelloWorldLocal)
PortableRemoteObject.narrow(o, HelloWorldLocal.class);
<-- Abbruch
String msg = helloRef.sayHello("World");
out.println(msg);
out.println("Sie befinden sich noch im try-Block");

} catch (Exception e) {
out.println("Funktion im try-Block fehlgeschlagen: " + e.getMessage());
}

%>

</body>
</html>

Weiss zufällig einer was ich da flasch mache?
Habe dem DynamicWebProject im Java Build Path auch die entsprechende Library(nur mit den interfaces ohne die iegentliche bean) zugewiesen.
Als ich den Client noch auf meinem Rechner hab laufen lassen, ohne ihn wie die bean auf den server zu deployen hat das ganze einwandfrei über das remote-interface funktioniert.

Vielleicht weiß ja einer von euch Rat.

Mfg Michael
 
ich glaub ich muss da irgendwo noch ne classloader referenz einbauen, aber ich hab keine ahnung wie das funktioniert...

hat da vielleicht jemand ne lösung zu?
 
Hi,
es sieht so aus als ob ear1 und ear2 einen eigenen Classloader benutzen. Soll heissen beide Applikationen sind von einander isoliert. Beide Classloader laden die Klasse HelloWorldLocal, diese sind aber in der tat aufgrund des unterschiedlichen Classloader nicht identisch. Beim casten ergibt sich dann die ClassCastException.

Kenne mich jetzt nicht mit dem SAP-AS aus, aber es gibt normaler weise Möglichkeiten das Classloader verhalten zu beeinflussen.

VG,
ck.
 
Hallo,

versuch doch mal ein gemeinsames API Jar zu erzeugen das dann von beiden ears verwendet wird.
Dann hast du auch den selben ClassLoader (für die API Klassen).

Gruß Tom
 
wie gesagt, ich bin java-anfänger^^
wie mach ich denn ne gemeinsame api jar bzw. wie müsste so ne classloader-referenz aussehen?

sitz hier gerade in sb, kannst ja mal vorbeikommen *spaß*
 
Zuletzt bearbeitet:
kann es evtl. daran liegen, dass ich dem client über properties-->JavaBuildPath-->Libraries-->AddExternalJAR eine Jar mit den Interfaces Local und Remote zuweise und der ClassLoader deshalb die Exception wirft?

Aber wie baue ich das sonst ein, dass ich hier:

HelloWorldLocal helloRef = (HelloWorldLocal)
PortableRemoteObject.narrow(o, HelloWorldLocal.class);

ein narrow auf ein object vom Typ HelloWorldLocal machen kann? der kent das doch sonst garnet...
 
Hi,
also normalerweise hat jeder AS ein Classloader Konzept. Ich kenn mich jetzt leider nur mit JBoss aus. Dort hat der Server einen Classloader und wenn gewünscht kann man pro deployable (sar, ear, war, etc.) einen eigenen Classloader konfigurieren. Ebenfalls ist es möglich Classloader über mehrere deployables zu teilen.
Der AS versucht nun zunächst im eigenen Classloader die betreffende Klasse zu finden (auch konfigurierbar) und fall nicht erfolgreich im Server-Classloader.

Also ich sehe folgende Lösungen für dein Problem:
1. Überdenke deine Packaging Strategie, macht es Sinn zwei ears zu haben?
2. Lese dich in die Classloader Konfiguration des SAP-AS ein.
3. Erstelle wie Tom bereits erwähnte ein eigenes API Package und deploye es seperat zu deinen beiden ears, und vergewissere dich das beide ears Zugriff auf den Classpath haben. Somit werden die Klassen nur einmal geladen und du hast keine Probleme mehr mit dem Casten.
Notfalls kannst du dieses API-Package in das Server-Lib Verzeichniss stellst, das wäre aber meiner Meinung nicht die beste Lösung.
Besser wäre Punkt 2 zu befolgen und die Konfigurationsmöglichkeiten vom SAP-AS herauszufinden.
 
es ist eine vorgabe 2 ears zu verwenden...

wie erstelle ich denn eine gemeinsame api jar bzw. wie spreche ich diese dann an?

sind die classloader referenzen je nach as anderst? dachte die würden bei java einheitlich implementiert...
 
es geht eigentlich darum Interfaces für deine Klassen zu definieren und diese dann in einem extra Package auszulagern.
Also du hast ja z.B. die Klasse HelloWorldLocal in ear1 und ear2. Nun erstellst du ein Interface HelloWorldLocalItf welches von HelloWorldLocal implementiert wird. Zum casten benutzt du dann das Itf und nicht direkt die Klassen.
Da Itf nur einmal geladen wurde sollte dann dein Casten ohne Probleme funktionieren.

Pseudo-Code:
ear1HelloWordLocal = (HelloWorldLocalItf) ear2HelloWorldLocal;

Alles klar?
 
Zuletzt bearbeitet:
Zurück