Wat is de EJB 3.0-versie van de methode ejbCreate

Ik zou graag enkele oude EJB 2.1-code willen migreren naar EJB 3.0, maar er is enige afhandeling van configuratiefouten in de ejbCreate-methode. Bestaat er een EJB 3-versie van die methode?

Bewerken: In EJB 2.x kan ejbCreate een CreateException gooien. Op basis van de documentatie van @PostConstruct etc. kan ik geen gecontroleerde uitzonderingen meer weggooien. Hoe kan ik dit aan als ik de code nu niet via de EJB kan migreren.

Edit2: De frontend behandelt specifiek CreateException die helaas is aangevinkt.

 3
toegevoegd bewerkt
Bekeken: 3
de bron
ro ru fr es pt de hi bn ar kk tr

3 antwoord

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

No only the name is arbitrary, you can have several @PostConstruct methods in one EJB - however the order of invocation is unspecified, so be careful and try to stick with one method. UPDATE:

Er kan slechts één methode worden geannoteerd met deze annotatie.

6
toegevoegd
de bron
" f als de methode een ongecontroleerde uitzondering genereert, mag de klasse NIET in gebruik worden genomen " - van docs . Waarom wilt u gecontroleerde uitzonderingen op de eerste plaats gebruiken? Ook u kan niet hebben verschillende @ PostConstruct methoden, werkt in het voorjaar, maar niet in EJB, sorry.
toegevoegd de auteur Tomasz Nurkiewicz, de bron
Het lijkt erop dat er geen 100% functioneel equivalent is voor ejbCreate in EJB 3. Wat in ons geval betekent dat ik de EJB's niet kan refactoren zonder ook de frontend te moeten refactoren. Ik ga dit antwoord nog steeds accepteren, omdat de oplossing ten minste een deel van mijn probleem oplost.
toegevoegd de auteur Stefan, de bron
Het doel was om de klant te informeren of er een probleem was met de EJB.
toegevoegd de auteur Stefan, de bron
Ik wil gecontroleerde uitzonderingen niet gebruiken. Maar de code die de EJB gebruikt, handelt CreateException af op basis van de 2.x spec die wordt gecontroleerd. En ik kan momenteel die code niet aanpassen.
toegevoegd de auteur Stefan, de bron
In EJB 2.x kon ejbCreate een CreateException gooien. Op basis van de documentatie van @PostConstruct kan ik geen gecontroleerde uitzonderingen meer gooien. Hoe kan ik dit aan als ik de code nu niet via de EJB kan migreren.
toegevoegd de auteur Stefan, de bron
Wat was het doel van ejbCreate (-) in EJB 2.x? De methode @PostConstruct wordt aangeroepen door de container wanneer een nieuw exemplaar van de EJB wordt gemaakt en er zich een DI heeft voorgedaan. Misschien heb je een @PostConstruct -methode nodig om je configuratie uit te voeren, en een paar mockup (normale methode) die de ejbCreate (-) simuleert?
toegevoegd de auteur Piotr Nowicki, de bron

U moet de callback-methoden van EJB 3.0 lifecycle gebruiken met behulp van annotaties

@PostConstruct, @PreDestroy, @PostActivate or @PrePassivate

Deze annotaties kunnen op elke methode worden toegepast die openbaar, nietig en niet-argend is.

2
toegevoegd
de bron
Hoeft niet openbaar te zijn. Rechtstreeks vanuit de javadoc van PostConstruct: "De methode waarop PostConstruct wordt toegepast KAN openbaar, beschermd, privé of privé zijn." docs.oracle.com/javaee/5/api/javax/ annotatie/& hellip;
toegevoegd de auteur ymajoros, de bron

Als de client expliciet omgaat met CreateException die is gegenereerd door ejbCreate en u wilt EJB 3 gebruiken, moet u een stateful session bean gebruiken. Uitzonderingen van ejbCreate van stateless session -bonen worden niet doorgegeven aan clients, en entity-bonen ondersteunen geen annotaties in EJB 3. In dat geval wilt u de @Init-annotatie:

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();
    }
  }
}
0
toegevoegd
de bron
Je hebt gelijk; Ik had moeten zeggen: "de EJB-container van WebSphere Application Server noemt nooit ejbCreate van SLSB home.create op een voor de gebruiker zichtbare manier" :-). (De enige uitzondering is uitgestelde EJB-initialisatie in combinatie met een harde minimum poolSize, waardoor de bean-pool vooraf kan worden ingevuld en ejbCreate wordt aangeroepen tijdens de eerste aanraking van home.create. Maar zelfs in dit geval zal de container worden opgevangen CreateException en geef CNTR0033E uit in plaats van de uitzondering door te geven aan de beller.)
toegevoegd de auteur Brett Kail, de bron
De EJB-container noemt ejbCreate nooit van thuis. Maak, maar noemt het tijdens het vullen van de pool zoals je zei. Dus als uw clientcode EJBException (of RemoteException) oploopt en controleert of getCause() CreateException is, ga ik ermee akkoord dat het gedrag van de klant zou worden gewijzigd en dat er geen manier is om uw doel te bereiken. Is dat wat je clientcode doet? Als dat zo is, mijn excuses, en bedankt voor de discussie.
toegevoegd de auteur Brett Kail, de bron
Inderdaad, de container roept geen ejbCreate vanuit huis.create, dus je bewering dat "de frontend specifiek omgaat met CreateException [gegooid van ejbCreate]" is ongeldig. U kunt @PostConstruct gebruiken en elke gewenste uitzondering uitvoeren; klantgedrag blijft ongewijzigd.
toegevoegd de auteur Brett Kail, de bron
Ik begrijp het niet; waar gebruik je stateless session beans eerder? Als dat het geval is, zien uw klanten Create Excel nooit van uw ejbCreate-methode worden weggehaald omdat home.create() voor een stateloze sessie de bean geen ejbCreate aanroept. U kunt dus elke uitzondering van PostConstruct (bijvoorbeeld EJBException) gebruiken en het gedrag van de client blijft ongewijzigd.
toegevoegd de auteur Brett Kail, de bron
Wat betekent "met schalen"?
toegevoegd de auteur Brett Kail, de bron
Helaas krijg ik dan een probleem met schalen.
toegevoegd de auteur Stefan, de bron
Stateful beans scoren niet erg goed bij een groot aantal gebruikers.
toegevoegd de auteur Stefan, de bron
Ja, ik deed het. We hadden code in ejbCreate die zou controleren of de boon correct was geladen. Er was een probleem met ontbrekende potten en daaropvolgende duplicatieHome excepties op WAS6. Dus moesten we controleren op alle klassen aanwezig in de statische initializer en vervolgens zou ejbCreate de uitkomst daarvan controleren.
toegevoegd de auteur Stefan, de bron
Ik veronderstel dat je bedoelt dat het niet ejb callt, elke keer dat je een boon 'maakt'. Dat is waar. Het noemt het nog steeds het zwembad te vullen en dat is wat ik nodig heb.
toegevoegd de auteur Stefan, de bron
je hebt ongelijk. De container roept ejbCreate aan. Gewoon niet op elke oproep om te creëren. Maar aangezien ik de CreateException gooi vanaf de eerste keer dat de container de pool probeert te vullen, zullen er nooit instanties van de bean zijn en ja, de client krijgt een CreateException. Zie theserverside.com/discussions/thread.tss?thread_id=6632
toegevoegd de auteur Stefan, de bron
Nooit is een beetje sterk, ik weet zeker dat de specificatie het voor de container mogelijk maakt om het te doen. U kunt er niet op vertrouwen, maar de createException moet nog steeds worden gereproduceerd, of de Container eigenlijk ejbCreate aanroept. Helaas hebben sommige ontwerpbeslissingen die we enkele jaren geleden hebben gemaakt, te weinig begrip getoond voor het EJB-concept/de standaard. Op dit moment proberen we te upgraden, maar we moeten dat doen zonder onze applicaties te onderbreken.
toegevoegd de auteur Stefan, de bron