EJB gond

Nekialltam en is a a J2EE-nek. Szep, jo, egyetlen gondom, hogy a dependency injection nem akar menni.

Van egy interface-em: 


@Local
public interface CarManagerLocal {
    public Car saveOrUpdateCar(Car car);
    public void deleteCar(Long carId);
    public Car getCar(Long carId);
    public List<Car> getAllCars();
}

Es egy azt megvalosito Stateless Session Bean: 


@Stateless
public class CarManagerBean implements CarManagerLocal {
    @PersistenceContext 
    private EntityManager em;

    @EJB
    private TestManagerLocal testManager;
...
}

A jsp-ben igy iratnam (volna) ki: 


    <body>
        <jsp:useBean id="carManager" class="teszt1war.CarsFacade" />
        <c:set var="cars" value="${carManager.allCars}" />
        
        <c:choose>
            <c:when test="${cars==null}">
            Nincs auto
            </c:when>
            <c:otherwise>
        <table>
            <tr> <td>Manufacturer</td> <td>Type</td> </tr>
            <c:forEach var="car" begin="0" items="${cars}">
            <tr> <td>${car.manufacurer}</td> <td>${car.type}</td> </tr>
            </c:forEach>
        </table>
            </c:otherwise>
        </c:choose>
    </body>

A 

getAllCars

loggol, es 

null

-t ad vissza, ha exception tortent.

Amikor felhasznalom a CarManagerBeant, a dependency injection nem rakja be egyik injektalando objektumot sem.
Kb. egy napi guglizas es doksiolvasgatas utan kiderult, hogy ezek csak felugyelt osztalyok eseten mukodnek. Az egyetlen bokkeno, hogy ebbe pont beletartozik a fenti is, mint enterprise bean...

Ami igazan gyanus, hogy a Netbeans 6.1-ben a project ablakban van egy kategoria az Enterprise Bean-eknek. Ez amikor a projekt uj volt, tartalmazta is, amit kellett. Nemi konfig irogatas utan viszont uresen all, hiaba irtam vissza az eredetire oket.
Nyomtam egy validate-et az ejb projektre, es ott nem veszi eszre, hogy ez a beanjeim egy lokalis buisness interface-t implementalnak.

A j2eetutorial mintakat nezegetve nem jottem ra a kulonbsegre sem a 

sun-ejb-jar.xml

-ben, sem mashol.

Egy probat lejtettem, hogy atirtam Remote interface-nek, ezt az appserver eszre is vette, hogy remote, ugyanakkor a hibajelenseg maradt.

Softwarekorites: NetBeans 6.1, Glassfish V2.1 b39

Szerk:

Hege javaslatara megmodositottam a kodot kicsit.
Keletkezett egy 

CarFacade

osztaly, ami elvileg lookuppolna a Beant. Ilyen probalkozasaim voltak: 

  • (CarManagerLocal)ic.lookup("java:comp/env/hu/pezia/idomeres/services/CarManagerLocal");
  • (CarManagerLocal)ic.lookup("java:comp/env/carManagerLocal");
  • (CarManagerLocal)ic.lookup(CarManagerLocal.class.getName());

Ahol 


private InitialContext ic;
...
ic = new InitialContext();
...

Ezek kivetel nelkul 

NamingException

-t dobtak. Az elobbiek 

No object bound to name

, az utolso pedig siman nem talalta a nevet. Ilyesforman egyaltalan nem is kulonbozik mar szinte a tutorial mintaalkalmazasatol.
Persze ragugliztam a temakorre, es ezeket a nevformakat dobtak ki. Igy azt hiszem van meg egy kis szivas hatra, hogy megtalaljam az objektumokat.

Erre a megoldast vegulis az adta, hogy elfelejtettem a hivatkozasokat hozzaadni a 

web.xml

-hez, valahogy igy: 


<ejb-local-ref>
        <ejb-ref-name>carManagerLocal</ejb-ref-name>
        <ejb-ref-type>Session</ejb-ref-type>
        <local>hu.pezia.idomeres.services.CarManagerLocal</local>
</ejb-local-ref>

A nyero nev pedig a 

(CarManagerLocal)ic.lookup("java:comp/env/carManagerLocal");

eseteben volt :)

( hege | 2008. 07. 13., v – 22:36 )

Próbáld meg a Netbeans-ben kikapcsolni a directory deployment-et, az szokott hasonló felderíthetetlen problémákat okozni. (asszem vhol az appserver beállításoknál kell kapcsolni és alapértelmezetten be van kapcsolva).

( Mico v | 2008. 07. 14., h – 01:54 )

Mint fölöttem is leírták, a jó megoldás egy facade bean bevezetése. Esetfüggő, hogy maga a facade session scope-ba kerül, vagy nem.

Viszont miért is írunk kódot JSP -ben? Tudom, hogy a kék könyvekben is ez van, meg egy rakás cégnél is így csinálják, de ma már van olyan, hogy MVC, sőt továbbmegyek, van egy rakás egyéb megjelenítési technológia, a különféle framework-ökről nem is beszélve.

Elsírom magam, amikor úgynevezett architect-ek összeraknak egy multitier alkalmazást aztán nekiállnak .jsp -re ráengedni a requestet meg onnan EJB-t hívogatni. A felmerülő problémákra meg kitalálnak gyorsan 20 féle business patternt, business delegate, session facade, stb. Úgy hallottam, ezen a fázison már a jobb PHP kóderek is túljutottak.

Ps. ez nem neked szól, látom, hogy friss hús vagy.

Nem akarok JSP-zni egyaltalan amugy, csak gondoltam kiprobalom, hogy ez hogy is mukodik. Sosem art legalabb minimalis szinten tisztaban lenni a leheto legtobb dologgal. Igazabol nem is szamitottam arra, hogy ott programkod lesz. Es a tutorial peldaban valoban ott van beagyazva a java kod a jsp-be...
A frameworkoket meg mar kozben nezegetem, persze igy eleg nehez kivalasztani az n+1-bol, hogy melyik a bevetesre erdemes.

Amiket ki fogok probalni igy elso ranezesre:

Persze lehet mindegyik nagy mellefogas, de valahol el kell kezdeni :)

Attol mit varsz el tolik. A Tapestry es a Wicket komponens keretrendeszerek, foleg web resszel foglalkoznak (keresek kiszolgalasa, viewok feltoltese adatokkal), mig a Spring egy komplett alkalmazas platform lehet, ahogy ok mondjak egy jee alternativa. Ha megerted a mogotte huzodo filozofiat, akkor egy nagyon kenyelmes, es hatekonyan platformot kapsz kezbe.