2 Stateless Beans 1 Local Interface?

A

Achim Lindt

Gast
Hallo zusammen,

ich habe zwei Services die eine identische datenimport Funktionalität über zwei verschiedene Strategien lösen (Stichwort Strategy Pattern).

Lokales EJB Interface
Java:
@Local
public interface IImportStrategy{

public void importData(File file);

}

1. Bean
Java:
@Stateless
public class LocalImport implements IImportStrategy{
    
    @Override
    public void importData(File file){...}

}

2. Bean
Java:
@Stateless
public class DistributedImport implements IImportStrategy{

    @Override
    public void importData(File file){...}

}

Ich möchte nun gerne über den Deployment-Deskriptor oder so dem Application Server mitteilen, welche Bean er jetzt nehmen soll (d.h. das mapping Interface -> Implementierung) - geht das? Zur Laufzeit wird das ja kaum möglich sein...

Oder besteht die Möglichkeit, dass beide ein eigenes @Local Interface implentieren und diese Interfaces dann von dem bestehenden IImportStrategy interface erben?

Hintergrund: Es soll ohne Codierungsaufwand möglich sein die Strategie zu ändern.

Bin für Vorschläge dankbar!

Beste Grüße,
Achim
 

FArt

Top Contributor
Nachdem der AS kein Bean hernimmt sondern der Client muss der halt entscheiden, welches Bean er über den JNDI Lookup denn benutzen möchte.
 
A

Achim Lindt

Gast
D.h. der AppServer (bei mir Glassfish) wird nicht meckern wenn 2 Beans das gleiche Interface benutzen?

Folgendes wäre dann z.B. ok?
Java:
{
   ...
   InitialContext ctx = new InitialContext;
   IImportStrategy import;
   boolean useLocal = false;
   try{
      if (useLocal){
          import = ctx.lookup(java:comp/ejb/LocalImport ) 
      }
      else{
          import = ctx.lookup(java:comp/ejb/DistributedImport)
      }
}
catch(...){...}
 

FArt

Top Contributor
D.h. der AppServer (bei mir Glassfish) wird nicht meckern wenn 2 Beans das gleiche Interface benutzen?

Folgendes wäre dann z.B. ok?
Java:
{
   ...
   InitialContext ctx = new InitialContext;
   IImportStrategy import;
   boolean useLocal = false;
   try{
      if (useLocal){
          import = ctx.lookup(java:comp/ejb/LocalImport ) 
      }
      else{
          import = ctx.lookup(java:comp/ejb/DistributedImport)
      }
}
catch(...){...}

Jein. Der Applicationserver hätte kein Problem mit den Interfaces.

Aber die Spec verbietet dir java.io.File in einem Bean zu verwenden.

Zitat aus der Spec:
An enterprise bean must not use the java.io package to attempt to access files and directo-ries in the file system.
 
A

Achim Lindt

Gast
Okay, danke für den Hinweis - werde das entsprechend umbauen. Wichtig war das mit den Interfaces.
 
Ähnliche Java Themen
  Titel Forum Antworten Datum
M App auf EJB Stateless Beans umstellen - NPE Application Tier 4
M EJB Stateless Bean ist immer null im REST WebService Application Tier 3
M Unterschied Stateless,Stateful Application Tier 3
F Property-Datei in Stateless-Bean laden Application Tier 8
M Entity Bean wird nicht in stateless Session Bean injeziert Application Tier 3
V Stateless-Bean soll Info aus Stateful-Bean holen Application Tier 3
S exception: Could not create stateless EJB StatelessEJB Application Tier 1
L dynamisches Instanziieren von Beans Application Tier 6
N Asynchrone Services mit Message Driven Beans? Application Tier 5
S Context hochfahren, Beans ändern, Server starten?? Application Tier 4
D JSF Frage zu Synchronisation zwischen SessionScoped beans Application Tier 11
M EJB3 Annotations für Session Beans mit einem Parameter ? Application Tier 5
M Deployment Error: Verification of Enterprise Beans failed Application Tier 1
MQue Spring beans Application Tier 10
K Benutzer-Daten über mehrere Session-Beans Application Tier 14
F Lose Kopplung zwischen Session Beans Application Tier 4
reibi Spring Beans - Grundsatzfrage Application Tier 3
V EJB: Eine Remote Bean soll eine Local Bean ansprechen und dem Client übergeben Application Tier 2
J EJB: Local-Annotation wird in Eclipse nicht erkannt Application Tier 7

Ähnliche Java Themen

Neue Themen


Oben