Qu'est-ce que l'EJB 3.0 version de la méthode d'ejbcreate

Je voudrais migrer certains vieux EJB 2.1 code de l'EJB 3.0, mais il y a une manipulation des erreurs de configuration dans la méthode d'ejbcreate. Est-il un EJB 3 version de cette méthode?

Edit: En EJB 2.x d'ejbcreate pourrait jeter une CreateException. Sur la base des documents de @PostConstruct etc. Je ne peux plus lancer aucun checked Exceptions. Comment puis-je faire si je ne peux pas migrer le code à l'aide de l'EJB droit maintenant.

Edit2: Le frontend traite spécifiquement les CreateException qui, malheureusement, est vérifiée.

OriginalL'auteur Stefan | 2011-10-27

  1. 7
    @PostConstruct
public void anyName() {
    //initialization code, dependencies are already injected
}

    Pas seulement le nom est arbitraire, vous pouvez avoir plusieurs @PostConstruct méthodes dans un EJB - cependant, l'ordre d'invocation n'est pas spécifié, alors soyez prudent et essayer de s'en tenir à une méthode. mise à JOUR:

    Une seule méthode peut être annotée avec cette annotation.

    En EJB 2.x d'ejbcreate pourrait jeter une CreateException. Sur la base des documents de @PostConstruct je ne peux plus lancer aucun checked Exceptions. Comment puis-je faire si je ne peux pas migrer le code à l'aide de l'EJB de la droite maintenant.
    "f la méthode lève une décoché l'exception de la classe ne DOIT PAS être mis en service" - à partir de docs. Pourquoi voulez-vous utiliser checked exceptions à la première place? Aussi, vous pas ont plusieurs @PostConstruct méthodes, des travaux au Printemps, mais pas dans les EJB, désolé.
    Je ne veux pas utiliser checked exceptions. Mais le code à l'aide de l'EJB poignées CreateException basé sur le 2.x spec qui est cochée. Et actuellement, je cant modifier le code.
    Quel était le but de d'ejbcreate(-) en EJB 2.x? Le @PostConstruct méthode sera invoquée par le conteneur lors de la nouvelle instance de l'EJB est créé et DI a eu lieu. Peut-être vous avez besoin d'un @PostConstruct méthode pour faire de votre configuration, et certains maquette (méthode régulière) qui simule la d'ejbcreate(-)?
    Le but était d'informer le client si il y avait un problème avec les EJB.

    OriginalL'auteur Tomasz Nurkiewicz

  2. 2

    Vous devez utiliser des EJB 3.0 cycle de vie des méthodes de rappel à l'aide d'annotations 

    @PostConstruct, @PreDestroy, @PostActivate or @PrePassivate

    Ces annotations peuvent aller sur une méthode qui est public, nulle et non-arg.

    N'a pas besoin d'être public. Directement à partir de PostConstruct la javadoc: "La méthode sur laquelle PostConstruct est appliquée PEUT être public, protégé, colis privé ou privé." docs.oracle.com/javaee/5/api/javax/annotation/...

    OriginalL'auteur Kal

  3. 0

    Si le client a été explicitement la manipulation CreateException jeté par d'ejbcreate et vous souhaitez utiliser les EJB 3, alors vous devez être à l'aide d'un stateful session bean. Les Exceptions à partir d'ejbcreate de beans de session sans état ne sont pas répercutées sur les clients, et les beans entité ne prennent pas en charge des annotations dans les EJB 3. Dans ce cas, vous souhaitez que le @Init annotation:

    public interface MyHome extends EJBLocalHome {
  public MyInterface create(int arg) throws CreateException;
}

@Stateful
@LocalHome(MyHome.class)
public class MyBean {
  @Init
  public void init(int arg) throws CreateException {
    if (arg < 0) {
      throw new CreateException();
    }
  }
}
    Malheureusement, puis je reçois un problème avec la mise à l'échelle.
    Que signifie "avec mise à l'échelle"?
    Les haricots Stateful dont l'échelle très bien avec un grand nombre d'utilisateurs.
    Je ne comprends pas; où vous utilisez le beans de session sans état précédemment? Si oui, alors vos clients n'auront jamais CreateException levée à partir de votre méthode d'ejbcreate de toute façon parce que la maison.create() pour un bean session sans état n'appelle pas d'ejbcreate. Ainsi, vous pouvez utiliser n'importe quelle exception de PostConstruct (par exemple, EJBException), et le comportement des clients seraient inchangées.
    Oui il l'a fait. Nous avons eu de code dans d'ejbcreate qui serait de vérifier si le bean avait été chargé correctement. Il y avait un problème de manque de pots et suivantes DuplicateHomeExceptions sur WAS6. Nous avons donc dû vérifier pour toutes les classes présentes dans l'initialiseur statique puis d'ejbcreate serait de vérifier le résultat de l'.

    OriginalL'auteur Brett Kail