2009. szeptember 2., szerda

Scanning java annotations - reflections

reflections

"Reflections scans your classpath, indexes the metadata, allows you to query it on runtime and may save and collect that information for many modules within your project."

Related project: scannotation

2009. augusztus 27., csütörtök

Troubleshooting Deployment in Glassfish + XSD Namespaces

Troubleshooting Deployment in Glassfish

Plussz amit sosem talalok amikor kell, nem birom megjegyezni es nem rakok fel 20 kilos eclipse plugint erte:

application.xml
<application xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="5" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/application_5.xsd>

ejb-jar.xml
<ejb-jar xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="3.0" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd">

web.xml
<web-app version="2.5" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd">

2009. augusztus 16., vasárnap

HG ignore RTFM

Eclipse-esek .hgignore file-jaban a .project biztosan megtalalhato. Sideeffectje a dolognak, hogy barmi amiben benne van a project ignoralva lesz. Hg baratunk ket pattern syntax-ot is tud, celszeru explicit megadni melyiket hasznaljuk:


syntax: glob
.project
...


Tovabbi RTFM itt.

2009. július 20., hétfő

Building Artifactory RTFM

"How do I build Artifactory from source? Maven tells me there are some missing dependencies.

Simply download the source and run mvn clean install from within the Artifactory root module (parent").
To gain access to open source dependencies not currently deployed on Maven's public repositories, you have to run mvn with the artifactory profile activate. e.g.:
mvn clean install -Partifactory."


http://wiki.jfrog.org/confluence/display/RTF/Usage


2009. július 18., szombat

Lodon Wicket (Yeah, London BABY)

Wicket-es eloadas slidok, forrasok, webcast-ok, stb:

London-Wicket

2008. augusztus 8., péntek

Maven vs Apache snapshot repository

Addot a kovetkezo motto:

Apache Maven Simplifies the Java Build Process — Even More Than Ant

A fenti idezet alapjan felteteleztem, hogy egy snapshot-os dependency-t behuzhatok a sajat projectembe. Csak hat a Apache Snapshot Repository-n a kivant artifact alatt a kovetkezo kep fogadott: m2-snapshot-repository.

2008. augusztus 7., csütörtök

Lazy fetching a'tka

Aki hasznalt/hasznal ORM framework-ot, biztos vagyok benne, hogy talalkozott mar a LAZY/EAGER fetching modokkal. Mind a ket loading modnak megvan az elonye/hatranya. Jelen esetben LAZY mod egyik igen bosszanto es gyakran elofordulo hatranyaval fogok foglalkozni, delikvens ORM pedig a Hibernate3.

Tegyuk fel, hogy three tier-es kornyezetben vagyunk es presentation tier-hez szeretnenk eljuttatni egy entity-t a business tier-bol. Az entity-nk neve legyen A.

class A {
private int id;
private List<B> b;
}

class B {
int id;
private List<C> c;
}

class C {
int id;
}

Fenti kodreszlet lenyegeben az A entitynk strukturajat mutatja. Fontos, hogy B es C is entity, tehat adatbazis szinten harom tablank van. A-ban talalhato B illetve a B-ben levo C lista LAZY modos fetching-t hasznal, JOIN kapcsolat van koztuk. Tehat A.getB() illetve B.getC() egy proxy-zott listat fog visszadni, csak akkor lesz populalva, ha valaki hasznalni akarja (pl. amikor vegig akarunk iteralni rajta).

Perfomance szempontjabol teljesen korrekt megoldas, minek betolteni azt, amit nem is biztos, hogy hasznalunk. Azonban van egy exception amivel szerintem minden Hibernate "barat" talalkozott mar: org.hibernate.LazyInitializationException. Ezt az exception akkor kapjuk, amikor egy proxyzott listan akarunk vegigiteralni, viszont a Hibernate session-unk mar nem letezik, igy a lista populalasa meghiusult.

Tegyuk fel, hogy presentation tier es a business tier kozott WebService-en keresztul mozognak az egyes entity-k. Marshalling soran (Object -> XML) valoszinuleg kapni fogunk egy exception a lazy loading miatt. A LazyInitializationException-t ugy tudjuk elkerulni, hogy az entitynket detach-eljuk, tehat a lazy loados listakat betoltjuk meg mielott a Hibernate session megszunne.

Kinai farmeres modszerrel megtehetjuk azt, hogy vegigiteralunk az oszes lista elemen, viszont nem a legegeszsegesebb. Szerencsere Hibernate biztosit szamunkra egy built-in utility methodot, org.hibernate.Hibernate#initialize(Object proxy). A proxy-zott listakat atjuk a initialize() methodusnak igy initializalva lesz a listank.

A fentiek alapjan, azt gondolnank, hogy a kovetkezo dologgal meg is oldottuk a marshalling problemat:

A a = ...;
Hibernate.initialize(a.getB());

Ha megfigyeljuk akkor B entity szinten tartalmaz egy proxyzott listat (C). Ezen lista nem kerul initializalasra, igy B entity C listajan is meg kellene hivnunk a initialize() methodust. Egy nagyon complex model eseten tobb szaz soros kodreszlet lesz, ami a detach-et vegzi, ami nem a legszebb latvany, illetve konnyu hibat veteni.

Tegyuk fel, hogy a detach-et vegzo kodot megirtuk, viszont RMI-re valtunk WebService helyett. Az RMI legjobb tulajdonsaga az, hogy egy az egyben kiszerializalja az objecteket, nem kell DDL, WebService esetben viszont igen. Ezen jo tulajdonsaga lesz esetunkben a hatranya, ugyanis List objectek konkret tipusa Hibernate fuggo, sajat tipusok. Ha a presentation tier dependency listaja nem tartalmazza a Hibernate libeket, akkor NoClassFoundException fogunk kapni.

Most erkeztunk el a lenyeghez amiert ezt a post-ot megirtam. Letezik egy megoldas, ami a teljes detach-es kodiras terhet leveszi a vallunkrol, illetve a RMI-s problemat is eliminalja. A utility class neve, ami nem resze a Hibernate CORE-nak (egyenlore), HibernateCleaner. Ahoz, hogy detach-eljuk illetve a megszabaduljunk a hibernate dependent class tipusoktol, meg kell hivnunk a clean() metodust.