SCBCD jegyzetek

Néhány lejárófélben lévő voucher miatt beneveztem egy Sun Certified Business Component Developer (SCBCD) for the Java Platform, Enterprise Edition 5 (CX-310-091) vizsgára is nemrég. A Java EE 6 vizsgákat tavaszra ígérték a megvásárolt Sun weblapján a tranzakció előtt, azóta viszont nem sok újdonságot hallani a témáról, úgyhogy kénytelen voltam az 5-össel beérni.

Szokásos emlékeztetők lentebb. Tesztelésre, példakódok írására egy régebbi, egész pontosan 6.7.1-es Netbeanst és a hozzá csomagolt GlassFish 2.1.1-et használtam.

Tanulni leginkább a specifikációból érdemes, a vizsgán is azt kérdezik. A GlassFish alatt kipróbáltakra sem érdemes túlságosan hagyatkozni, mert néhol megengedőbb, mint a specifikáció. Nem mindig veszi szigorúan a leírtakat az implementáció.

A felkészüléshez legnagyobb segítséget az Enthuware-es tesztprogram jelentette. Korrekt darab, jó kérdésekkel, megéri az árát, sok időt lehet vele spórolni. A SkillGuru-n lévő kérdéssorral viszont csak óvatosan, szerintem elég sok hiba van benne.

Könyvek közül az EJB 3 in Action-re esett a választásom. Leginkább ezt olvastam végig, de volt nálam egy Enterprise JavaBeans 3 is. Utóbbi inkább referenciaként van felépítve. XML-es részekben az O'Reilly-féle a nyerő, bár szerencsére vizsgán nem túl sok XML-t kérdeztek, nem igazán volt szükség a DTD-k bemagolására. Ami kellett, az kb. a manningos könyvben is benne volt.

Leírom ide is: A lista átnézése a könyvekben és a JavaRanch-en linkelt vizsgasorok, feladatok megoldása előtt túlzott önbizalomhoz vezethet, aminek sikertelen vizsga lehet a vége.

Hivatkozások:

  • ejb3core: JSR 220: Enterprise JavaBeans, Version 3.0, EJB Core Contracts and Requirements
  • pers: JSR 220: Enterprise JavaBeans, Version 3.0, Java Persistence API
Enterprise Bean-ek
  • EJBContext elérése:
    • MDB-ben: @Resource private MessageDrivenContext context;
    • Session Bean-ben: @Resource private SessionContext context;
    • Mindkettőben: @Resource private EJBContext context;
  • @PostConstruct metódus EJB esetén non-final kell legyen, egyébként lehet final is.
  • Interceptor metódus példa: import javax.interceptor.AroundInvoke; @AroundInvoke public Object log(final javax.interceptor.InvocationContext ctx) throws Exception
  • Egy session bean method-ready állapotba kerül a példányosítás, dependency injecton és a @PostConstruct metódus futtatása után.
  • @PrePassivate után nem feltétlenül kell minden mezőnek nullnak vagy szerializálhatónak lennie. Egy rakat kivétel olvasható az [ejb3core 4.2.1 Instance Passivation and Conversational State] alatt.
  • EJBContext lookup() metódusa a komponens private naming contextjéhez fér hozzá, nem kell a name-et a „java:comp/env”-vel kezdeni. InitialContext esetén kell a „java:comp/env”.
  • A konténernek kötelezően elérhetővé kell tennie a következő API-kat: minden, ami J2SE 5.0, JDBC, RMI-IIOP, JNDI, JAXP, Java IDL, JAAS [ejb3core 21.1.1 APIs Provided by Container].
  • EJB konténerben elérhetőnek kell lennie: EJB 3.0, including the Java Persistence API, JTA 1.1, JMS 1.1, JavaMail 1.4 (csak levélküldésre), JAF 1.1, JAXR 1.0, SAAJ 1.3, JAX-RPC 1.1, JAX-WS 2.0, Connector 1.5, Web Services 1.2, JAXB 2.0, Java EE Management 1.1, JACC 1.1, Web Services Metadata 2.0, Common Annotations 1.0, StAX 1.0 [ejb3core 21.1.1 APIs Provided by Container].
  • [ejb3core 21.2.3 JNDI Requirements] leírja, hogy miket kell elérhetővé tenni a konténernek JNDI-n keresztül (beleértve az InitialContext-et is).
  • EJB csak olvashatja a környzete állapotát, írni nem írhatja. Emiatt az InitialContext rebind() metódusa nem használható.
  • @javax.ejb.Local elemei: Class[] value - több interfészt is meg lehet adni neki. @Remote szintén ugyanilyen.
  • @PostConstruct metódus lehet private vagy package private is.
  • SFSB afterCompletion metódusa nem hívhat másik EJB-t, meg van rá egy rakat egyéb korlátozás is. Csak a JNDI java:comp/env és a SessionContext metódusai érhetőek el. [ejb3core 4.4.1 Operations Allowed in the Methods of a Stateful Session Bean Class]
  • [ejb3core 21.1.2] szerint EJB (többek közt) nem teheti a következőket:
    • Írható/olvasható static mezőket nem használhat (mert nem lesz portolható, több JVM esetén problémát okozhat, ha nem ésszel használjuk).
    • Szálszinkronizációs primitívek nem használhatóak. Szálkezelés szintén tiltott.
    • Billentyűzet és képernyő I/O nincs.
    • java.io csomagok nem használhatóak a helyi fájlrendszer elérésére.
    • Socket listen szintén tiltott. Hálózati kliens viszont lehet.
    • this-szel nem térhet vissza, és nem adhatja át metódusparaméterként.
    • Van még jópár korlátozás az említett fejezetben, érdemes egyszer átfutni.
  • @javax.interceptor.Interceptors elemei: Class[] value
  • Ha két stateful SB-t injektálunk be például egy szervletbe a @EJB-vel, akkor két különböző példányt kapunk. Statless SB esetén ugyanazok lesznek. Az equals() metódussal hasonlíthatóak össze. [ejb3core 3.4.5.1 és 3.4.5.2]
  • SessionContext néhány metódusa:
    • Class getInvokedBusinessInterface()
    • <T> T getBusinessObject(Class<T> businessInterface) - Obtain an object that can be used to invoke the current bean through the given business interface.
  • 2.1-es EJB elérése 3-as EJB-ből:
    • @EJB ChargeCredit Home ccHome; ChargeCredit cc = ccHome.create();
Timerek
  • @Timeout metódusa csak SLSB-nek és MDB-nek lehet, SFSB-nek nem.
  • A múltidőre állított Timer-ek azonnal lejárnak (GF2).
    • TimeService.createTimer() után a visszaadott Timer getTimeRemaining() metódusa nullát ad vissza.
  • Ha több Timer jár le egy időben, akkor a @Timeout method egyszerre több szálon is futhat (persze mind külön SLSB-t használva). (GF2)
  • Csak egyetlen @Timeout metódus lehet egy SB-ben.
  • Ha nem fog többet lejárni egy időzítő, akkor a Timer.getNextTimeout() az aktuális időponttal feltöltött Date-et ad vissza, a getTimeRemaining() pedig nullát.
  • Timer létrehozás is beletartozik a tranzakcióba. Ha rollback-elünk (például system exception dobásával vagy setRollbackOnly() hívással), akkor a Timer sem lesz elindítva.
  • Egy állandóan rollback-elő timer ledöntheti a lábáról a konténert. GF2 védekezik ez ellen:
    • EJB5119:Expunging timer ['41@@1268933358072@@server@@domain' 'TimedObject = TestSessionBean' 'Application = TestEnterpriseApplication1' 'BEING_DELIVERED' 'SINGLE-ACTION' 'Container ID = 83160947064307714' 'Thu Mar 18 15:02:36 CET 2010' '0' ] after [2] failed deliveries
  • A Timer cancel() metódusa is beletartozik a tranzakcióba. Ha visszagörgetjük a tranzakciót, akkor a cancel() hívás is hatástalanítva lesz.
  • @Timeout metódusnak kötelező, hogy legyen egy Timer paramétere.
  • TimerService.getTimers() csak az adott EJB-hez tartozó időzítőket adja vissza, nem a szerveren lévő összes Timert.
  • TimerService: public Timer createTimer(long duration, Serializable info)
    • Az info Serializable kell, hogy legyen.
Tranzakciókezelés
  • SB-n beállított @TransactionManagement(TransactionManagementType.BEAN) és metódusra beállított @TransactionAttribute értelemszerűen nem használható együtt.
  • A @TransactionAttribute annotáció csak a business interface metódusaira van hatással, ha egy ilyen metódusból hívott private metódusnak más TransactionAttribute-ot adunk, az figyelmen kívül lesz hagyva. @EJB-vel injektált SB business metódusán persze lehet eltérő @TransactionAttribute beállítás.
  • javax.ejb.SessionSynchronization SFSB-hez való, specifikáció szerint SLSB nem implementálhatja ezt az interfészt. [ejb3core 4.3.7]
  • SessionSynchronization metódusai:
    • void afterBegin()
    • void afterCompletion(boolean committed)
    • void beforeCompletion()
  • SessionSynchronization.beforeCompletion() nem hívódik meg, ha rollback-elődni fog a tranzakció.
  • ic.lookup("java:comp/UserTransaction"): csak BMT esetén működik.
  • EntityTransaction EntityManager.getTransaction() IllegalStateException-t dob, ha JTA EntityManager-en hívjuk meg.
  • UserTransaction-nek csak setRollbackOnly() metódusa van, getRollbackOnly() metódusa nincs. A tranzakció állapota a getStatus() metódussal kérdezhető le.
  • UserTransaction.commit() RollbackException-t dob, ha előtte volt setRollbackOnly() hívás. [ejb3core 13.6.1 Bean-Managed Transaction Demarcation]
  • SFSB esetén BMT-nél ha csak begin() van, de commit() és rollback() nincs, akkor a konténer fenntartja a tranzakciót a következő hívásig, és a business method a korábbi BMT transaction contextben fog futni.
    • MDB vagy SLSB esetén ilyenkor naplózás, rollback és az MDB vagy SLSB példány eldobása történik. SLSB esetén a felhasználó kap egy EJBException-t is.
    • @Timeout metódusban szintén naplózás, rollback, és a példány eldobása történik.
    • Egyébként kötelező az SLSB-nek illetve MDB-nek befejeznie a tranzakciót a spec szerint, a fenti arra vonatkozik, ha valamiért mégsem tenné.
  • Ha egy metódus tranzakció-beállítása MANDATORY, és tranzakció nélkül hívjuk meg, akkor nem lesz eldobva az SB, csak simán kapunk egy javax.ejb.EJBTransactionRequiredException kivételt.
  • javax.persistence.PersistenceContextType enum értékei:
    • EXTENDED: Extended persistence context.
    • TRANSACTION: Transaction-scoped persistence context.
  • CMT esetén a konténernek nem szabad EJBException-t vagy RemoteException-t dobnia rollback esetén, ha a rollback a setRollbackOnly() metódussal lett kezdeményezve. Ilyenkor a business method visszatérési értékét kell átadnia a kliensnek. [ejb3core 14.3.10 Exceptions from the Management of Container-Managed Transactions]
  • Ha az SB metódusa a kliens transaction contextjében fut, akkor system exception esetén javax.ejb.EJBTransactionRolledbackException-t kap a kliens és a tranzakció setRollbackOnly lesz. [ejb3core 14.3.1 Exceptions from a Session Bean’s Business Interface Methods]
    • Required és RequiresNew esetén, amikor a konténer indítja a tranzakciót a business method hívása előtt, system exception esetén EJBException-t kap a kliens, és az ő tranzakcióját nem érinti a rollback.
    • unspecified transaction context és system exception esetén szintén EJBException-t kap a kliens.
Kivételkezelés
  • Csak az aktuálisan dobott Exception-re aggatott @ApplicationException számít, ha valamelyik őse volt annotálva, az figyelmen kívül lesz hagyva.
  • A javax.ejb.EJBException RuntimeException leszármazott.
  • EJB-s RuntimeException-ök EJBException formájában érkeznek a kliensekhez.
  • @ApplicationException(rollback=true) public class MyException extends Exception ...
  • @ApplicationException rollback mezőjének alapértelmezett értéke false.
  • @ApplicationException jelentése: kliensnek közvetlenül kell átadni, más exceptionbe csomagolás nélkül.
  • A java.rmi.RemoteException Exception leszármazott (IOException, ellenőrzött kivétel).
  • Ha egy SB system exceptiont dob (RuntimeException, vagy java.rmi.RemoteException leszármazott), akkor konténer eldobja az adott SB példányt.
    • Stateless SB esetén: a következő kérést egy másik SB példány fogja kiszolgálni.
    • Stateful SB esetén következő híváskor: Kivételt kapunk (például: javax.ejb.NoSuchObjectLocalException: The EJB does not exist. session-key: 1907f0100001f-ffffffff80e1).
    • Application Exception esetén nincs példánymegszüntetés.
  • Ha valamelyik SB metódus system exceptiont dob, akkor @PreDestroy hívás nélkül megszűnik az SB. O'Reilly könyv szerint hiba a specben.
  • A business interfész metódusai csak akkor dobhatnak java.rmi.RemoteException kivételt, ha az interfész kiterjeszti a java.rmi.Remote interfészt. [ejb3core 4.6.6] Remote interfész esetén kötelező a RemoteException-nek metódusok definíciójában szerepelni. [ejb3core 4.6.7.] Érdemes rákeresni a specifikációban erre a Remote interfészre, mert többek közt kiderül, hogy az alábbi EJBException-ök helyett mely RemoteException leszármazottak fognak dobódni Remote interfész használata esetén. (A „konverzió” a konténer feladata, kódból nem szabad RemoteException-t dobni EJB3 esetén.)
    • javax.ejb.EJBTransactionRequiredException -> javax.transaction.TransactionRequiredException
    • javax.ejb.NoSuchEJBException -> java.rmi.NoSuchObjectException
    • javax.ejb.EJBException -> java.rmi.RemoteException
    • javax.ejb.EJBAccessException -> java.rmi.AccessException
Security
  • A @DeclareRoles("role1") csak deklarál, nem ellenőriz semmit, csak jelzi, hogy később használni fogjuk a paraméterben megnevezett role-t. Enélkül az EJBContext isCallerInRole() metódusa „java.lang.IllegalArgumentException: No mapping available for role reference role1” kivételt dob. A deklaráció az ejb-jar.xml-ben is megtehető.
  • A getCallerPrincipal() @PostConstruct-ból sem hívható (RuntimeException-t dob).
Entitások, JPA
  • Ha egy entitás (nem feltétlenül absztrakt) ősosztálya nincs @Entity-vel megjelölve, akkor a mezői nem lesznek perzisztálva, EntityManager.find() után null értékűek lesznek.
  • Minden entitásnak kell legyen elsődleges kulcsa. Ha absztrakt ősosztály, akkor is.
    • The primary key must be defined on the entity that is the root of the entity hierarchy or on a mapped superclass of the entity hierarchy. The primary key must be defined exactly once in an entity hierarchy. [pers 2.1.4 Primary Keys and Entity Identity]
  • Property és field based access nem keverhető. Erre az esetre nem definiálja a viselkedést a spec.
  • GF2 figyelmen kívül hagyja a leszármazott osztályban az annotációkat (a @Column-ot biztosan), ha nem ugyanaz a hozzáférés típusa (field vagy property based), mint az ősentitásban.
  • Ha property based hozzáférést használunk, akkor setter-getter metódus csak protected vagy public lehet, és a final is tiltott.
  • Setter metódust tilos annotálni.
  • Az @Etity-nek nincs accessType mezője. (Egy fórum szerint a végleges specből kikerült, vagymi.) Ezzel lehetett volna beállítani, hogy field vagy property based elérésűek a mezőink.
  • @IdClass-os összetett kulcs esetén ugyanazokat a mezőneveket kell használni, mint az entitásban.
  • EntityManager: Query createNativeQuery(String sqlString, Class resultClass); A visszatérési Query nincs paraméterezve a resultClass-szal.
  • EntityManager.detach() nincs, szerializáláskor, klónozáskor lesz detached az entitás, vagy ha meghívjuk az EntityManager clear() metódusát.
  • Ha detached entitást akarunk törölni az adatbázisból, akkor előtte mindenképp merge-elni kell, csak utána lehet remove()-ot hívni. Egyébként IllegalArgumentException-t kapunk.
  • EntityManager-t nem a @Resource annotációval kell injektálni, hanem a @PersistenceContext-tel: @PersistenceContext private EntityManager em;
  • EntityManagerFactory injektálására a @PersistenceUnit használható.
  • Extended EntityManager esetén (@PersistenceContext(type=PersistenceContextType.EXTENDED)) a tranzakció végén managed állapotban maradnak az entitások. Csak SFSB-vel használható. Ha eltárolunk az SFSB egyik mezőjében egy entitás referenciáját, akkor EXTENDED esetben a következő hívásnál az EntityManager.contains() true-t mond, TRANSACTION esetén false-t.
  • Entitások esetén a private getter metódusok is annotálhatóak, nem kell public-nak lenniük.
  • EntityManager.close() IllegalStateException-t dob, ha az EntityManager container-managed vagy már egyszer le lett zárva.
  • Entitás csak top-level class lehet. Enum és interfész nem annotálható @Entity-vel. [pers 2.1]
  • Entity lifecycle callback metódusai ugyanabban a security és tranzakciós contextben hajtódnak végre, mint azok, amik indikálták a hívásukat.
  • A Serializable mezők is perzisztálódnak, ami akár saját osztály is lehet.
    • Pontos lista a [pers: 2.1.1 Persistent Fields and Properties] alatt olvasható.
  • Az @Embeddable működik @Embedded nélkül, de specben nem találtam erről semmit.
  • Instance variables must be private, protected, or package visibility. [pers 2.1] Tehát public nem lehet.
  • New állapotú entitásra az EntityManager.remove() nem dob kivételt. A kaszkádoláson végigmegy, ha ALL vagy REMOVE van beállítva.
  • Absztrakt entitásnak is kell lennie publikus, argumentumok nélküli konstruktorának, bár explicit nincs benne a specifikációban.
  • EntityManager: <T> T find(Class<T> entityClass, Object primaryKey) - A primaryKey típusa Object.
Entitások közötti kapcsolatok
  • @OneToOne-ként megjelölt kapcsolat esetén ha csak az egyik objektumot perzisztáljuk és cascade=CascadeType.PERSIST sincs beállítva, akkor a tranzakció rollback-elve lesz. (java.lang.IllegalStateException: During synchronization a new object was found through a relationship that was not marked cascade PERSIST: entityapp.entity.BillingInfo[id=null] username: addr1.) (Az optional elem értékétől függetlenül.)
  • A CascadeType enumerációnak van REFRESH értéke is.
  • Ha kétirányú 1:1 kapcsolatnál a mappedBy-t nem vesszük fel egyik oldalra sem, akkor a JPA két külön kapcsolatként kezeli az annotációkat. Ennek következtében mindkét táblában lesz távoli kulcs a másikra.
  • @OneToOne: mappedBy: a „kisebb” oldalon van. A mappedBy-t tartalmazó oldalra nem kerül a távoli kulcs oszlopa.
  • @PrimaryKeyJoinColumn: akkor használjuk, ha a két entitásnak ugyanaz az elsődleges kulcsa, így egyik táblában sincs szükség külön mező felvételére, ami a másik entitás elsődleges kulcsát tartalmazza.
  • @javax.persistence.PrimaryKeyJoinColumn mezői: String columnDefinition; String name; String referencedColumnName
  • @javax.persistence.Enumerated: value: EnumType: (Optional) The type used in mapping an enum type. Default: ORDINAL
    • ORDINAL: Persist enumerated type property or field as an integer.
    • STRING: Persist enumerated type property or field as a string .
  • @javax.persistence.Column mezői: String columnDefinition; boolean insertable; int length; String name; boolean nullable; int precision; int scale; String table; boolean unique; boolean updatable @javax.persistence.Basic mezői: FetchType fetch; boolean optional
    • optional: This is a hint and is disregarded for primitive types; it may be used in schema generation.
  • @javax.persistence.Temporal value típusa és értékei:
    • TemporalType: DATE, TIME, TIMESTAMP.
  • @javax.persistence.UniqueConstraint: String[] columnNames
  • @Column alapértelmezett hossza 255. Ennél hosszabb String-et nem engedett a Derby menteni, rollback-elte a tranzakciót.
  • @javax.persistence.AttributeOverride: The AttributeOverride annotation may be applied to an entity that extends a mapped superclass or to an embedded field or property to override a basic mapping defined by the mapped superclass or embeddable class. If the AttributeOverride annotation is not specified, the column is mapped the same as in the original mapping.
    • @AttributeOverride mezői: Column column; String name
  • @javax.persistence.MappedSuperclass: Designates a class whose mapping information is applied to the entities that inherit from it. A mapped superclass has no separate table defined for it.
  • @javax.persistence.Inheritance(strategy=JOINED)
    • InheritanceType: JOINED, SINGLE_TABLE, TABLE_PER_CLASS.
EntityManager
  • „unspecified transaction context”: NOT_SUPPORTED, NEVER, or SUPPORTS, @PostConstruct, @PreDestroy, @PostActivate, @PrePassivate metódusok. Ahol nem definiálják, hogy mi történjen, az appszerverre van bízva.
  • PersistenceException extends RuntimeException: elvileg ilyet kapunk akkor is, ha valamilyen adatbázisbeli kényszernek nem felel meg a mentendő entitásunk. Leszármazottai: EntityExistsException, EntityNotFoundException, NonUniqueResultException, NoResultException, OptimisticLockException, RollbackException, TransactionRequiredException.
Lekérdezések, JPQL
  • A JPQL az EJBQL kiterjesztése. [pers 4.]
  • JPQL-ben nincs INSERT.
  • JPQL-lel csak a persistence unitban lévő entitások érhetőek el, más táblák nem.
  • JPQL aggregáló függvényeinek visszatérési típusai [pers 4.8.4]:
    • COUNT visszatérési típusa Long.
    • MIN, MAX visszatérési típusa megegyezik a paraméter típusával.
    • AVG visszatérési típusa Double.
    • SUM: Long, ha egész típust kap (kivéve BigInteger), Double lebegőpontos típusoknál. BigInteger-nél és BigDecimal-nál a kapott típus.
    • SUM, AVG, MIN, MAX NULL-t ad vissza, ha egyetlen értéket sem kapott.
  • JPQL összehasonlító operátorai (többek közt): , <> (és nem =, illetve =)
  • A Query-nek is van setFlushMode() metódusa, nem csak az EntityManager-nek. Ezzel felül lehet írni az EntityManager beállítását.
  • FlushModeType értékei:
    • AUTO: (Default) Flushing to occur at query execution.
    • COMMIT: Flushing must occur only at transaction commit.
  • Sorrendezni (ORDER BY) csak SELECT részben is szereplő elemek alapján lehet.
  • Érvényes lekérdezés: SELECT p FROM Owner o, IN(o.properties) p
    • Visszaad minden Property példányt, ami Owner példányhoz van rendelve.
  • Érvényes lekérdezés ez is: SELECT o, p FROM Owner o, IN(o.properties) p
  • A SIZE függvény kollekcióban lévő elemek darabszámának meghatározására használható, míg a LENGTH egy String hosszát adja meg.
  • A bulk update és delete a megadott osztály leszármazottaira is vonatkozik. [pers 4.10 Bulk Update and Delete Operations]
  • A bulk delete nem kaszkádolódik. [pers 4.10 Bulk Update and Delete Operations]
  • Duplán létező NamedQuery-t a GF2 egyszerűen figyelmen kívül hagyja: Ignoring the @NamedQuery [findAllWebUser] specified on class [entityapp.entity.WebUser] since a query with that name already exists.
  • @NamedQuery UPDATE és DELETE is lehet, nem csak SELECT.
  • EntityManager.createQuery IllegalArgumentException-t dob, ha nem érvényes a lekérdezés.
  • @NamedQuery esetén a deploy sem sikerül, ha hibás a lekérdezés.
  • Több elemmel is visszatérő SELECT lekérdezés visszatérési típusa Object[].
  • Constructor expression példa: SELECT new hu.test.Name(c.firstName, c.lastName) FROM Customer c
  • Paraméteres lekérdezés esetén a Query.setParameter() metódusainak megadott paraméterek számozása nem 0-val vagy 1-gyel kezdődik, hanem a lekérdezésben kell megadni a konkrét számot, például: SELECT w FROM WebUser w WHERE w.username LIKE ?5
    • A „?0” nem érvényes helyettesítő.
  • LIKE-nál a % és az _ speciális karakterek a \ karakterrel hatástalaníthatóak.
  • Ha setParamter() metódust, LIKE-ot és % vagy _ speciális jelet szeretnénk együtt használni, akkor a %-et és az _-et a setParameter() metódus második paraméterében kell elhelyezni. Például: query.setParameter("name", "%" + searchText + "%");
  • A lekérdezésekben használható entitások nevét nem az osztály neve adja meg, hanem az @Entity annotáció name mezője.
  • EJBQL lekérdezésekben hexadecimális és oktális számformátumok nem használhatóak.
  • The BETWEEN expression x BETWEEN y AND z is semantically equivalent to: y <= x AND x <= z.
  • Join fetch példa: SELECT d FROM Department d LEFT JOIN FETCH d.employees WHERE d.deptno = 1
  • A SOME az ANY szinonimája.
  • SELECT kulcsszó után nem adható meg olyan kifejezés, ami több elemet tartalmaz (például kollekció). A következő példa nem érvényes: SELECT o.lineItems FROM Order AS o [pers 4.8 SELECT Clause]
  • A @NamedNativeQuery is az EntityManager.createNamedQuery() metódusával használható.
  • Subquery-k a WHERE és HAVING részben használhatóak, a FORM-ban nem.
  • A bulk update-ek egyáltalán nem foglalkoznak az optimista lockolással, kézzel kell módosítani a @Version oszlopot, ha akarjuk.
EJB 3 alkalmazások csomagolása
  • Ha meg van adva a @Stateless annotáció name eleme, akkor az ejb-jar.xml-ben is ezzel a névvel kell rá hivatkozni a enterprise-beans / session / ejb-name tag-ben.
  • assembly-descriptor? / interceptor-binding*
    • interceptor-binding*
      • ejb-name1
      • interceptor-class*
      • method? / method-params? / method-param*
      • method? / method-name1
  • Ha a method tag alatt csak a method-name van megadva, és nincs method-params, akkor minden olyan nevű metódusra vontkozik a tag (paraméterektől függetlenül).
  • env-entry-type tag lehetséges értéke Boolean, Byte, Character, String, Short, Integer, Long, Float, Double (java.lang előtaggal). Date nincs a listában.
  • Az ejb-jar.xml opcionális.
persistence.xml
  • persistence / persistence-unit*
    • persistence-unit / provider?, jta-data-source?, exclude-unlisted-classes?, mapping-file*, jar-file?, properties?
    • properties / <property name="" value="" />
Message-Driven Bean-ek
  • MDB nem definiálhat finalize() metódust.
  • Dups-ok-acknowledge és Auto-acknowledge közti különbség: What is the acknowledge mode?
  • Ha konténer kezeli a tranzakciókat, akkor abba az üzenet kivétele a sorból és az ACK elküldése is beletartozik.
  • Ha az MDB bean-managed tranzakciót használ, és nem dob exceptiont, akkor mindenképp nyugtázva (ACK) lesz a Message, és nem lesz újraküldve, mivel az üzenetfogadás nem része a tranzakciónak.
  • MDB class: The class must implement, directly or indirectly, the message listener interface required by the messaging type that it supports or the methods of the message listener interface. In the case of JMS, this is the javax.jms.MessageListener interface.
  • javax.ejb.MessageDrivenBean interfész metódusai:
    • void ejbRemove() throws EJBException
    • void setMessageDrivenContext(MessageDrivenContext ctx) throws EJBException
  • MDB által használható container-managed tranzakciótípusok: REQUIRED, NOT_SUPPORTED. [ejb3core 5.4.12]
  • MDB @Timeout metódusa által használható tranzakciótípusok: REQUIRED, REQUIRES_NEW, NOT_SUPPORTED. [ejb3core 5.4.12]
  • MDB nem dobhat java.rmi.RemoteException-t. [ejb3core 5.4.17 Dealing with Exceptions]
Webszolgáltatások
  • @WebMethod mezői: String action; boolean exclude; String operationName
  • @WebParam mezői: boolean header; WebParam.Mode mode; String name; String partName; String targetNamespace;
    • WebParam.Mode értékei: IN, OUT, INOUT.
Tartalom átvétel