---

Hej Gruppe

Jeg sidder og udarbejder et produkt i forbindelse med mit afgangsprojekt
på IT-ingeniøruddannelsen.

Produktet er en web-applikation, og vores "kunde" havde forestillet sig
at vi brugte en Tomcatserver som platform. Dette virker imidlertid som
et problem, da Tomcat, så vidt jeg kan gennemskue, kun kan køre opgaver
som reaktion på en request. I vores problem er det imidlertid en central
funktionalitet at kunne schedulere opgaver til at køre, f.eks. kl. 1 om
natten, uovervåget. Er det korrekt forstået at man ikke kan få Tomcat
til at køre en metode med et vist interval, uden at det bliver et hack
bestående af cron og wget?

Vi kigger som alternativ på at skrive vores domænelag i "normal java",
og snakke fra Tomtcat med dette vha. RMI. dette har den fordel at vi i
forvejen kender og er trygge ved J2SE-platformen. Vi skal i denne
løsningsmodel dog sætte os ind i et persistensframework, da vi mener
dette vil betale sig tilbage i brugt tid og give pænere kode. Er
Hibernate et godt valg?
En anden løsningsmodel vi overvejer er at gå fra en servlet-container
til en hel Java EE container som f.eks. JBoss. Her har jeg set at der
findes en afviklingsmodel baseret på timere. Ville denne evt. også være
tilgængelig i Tomcat eller kræver det en fuld Java EE container? Hvor
omfattende er Java EE at sætte sig ind i når man allerede kender Java
SE? Hvor omfattende er det når man medregner at man sparer at lære et
løst persistensframework at kende?
Er der nogle begrænsninger i at kunne lave socketbaseret I/O fra f.eks.
JBoss? Dette er nemlig nødvendigt for at kunne udføre kernefunktionaliteten.

Overordnet set søger jeg kommentarerer på hvor grimt et semiheterogent
Tomcat-kalder-J2SE-persisterer-i-hibernate system er kontra hvor egnet
Java EE er til en applikation hvor hovedfunktionaliteten udføres
asynkront af webinterfacet igennem timere.
Samtidig ønsker jeg kommentarer på læringsbyrden i Hibernate kontra Java
EE eller om man skulle kigge på et andet persistensframework end hibernate.

MVH

Mads Bahrt

---

Mads Bahrt skrev:

> Produktet er en web-applikation, og vores "kunde" havde forestillet sig
> at vi brugte en Tomcatserver som platform. Dette virker imidlertid som
> et problem, da Tomcat, så vidt jeg kan gennemskue, kun kan køre opgaver
> som reaktion på en request. I vores problem er det imidlertid en central
> funktionalitet at kunne schedulere opgaver til at køre, f.eks. kl. 1 om
> natten, uovervåget. Er det korrekt forstået at man ikke kan få Tomcat
> til at køre en metode med et vist interval, uden at det bliver et hack
> bestående af cron og wget?

Nej, du kan sagtens køre hvad du ønsker som selvstændige tråde under
Tomcat, fx. initialiseret som en static singleton i en auto-start
servlet. Jeg har en Tomcat kørende med indtil flere tråde der periodisk
læser xml-filer og laver database oprydning (med Hibernate).

Problemet består måske mere i at afslutte disse ekstra tråde når man fx.
gerne vil deploy'e en nyt version af applikationen. Jeg har ikke haft
tid til at løse dette problem ordentligt (jeg genstarter Tomcat før jeg
deployer ny version), men det kan måske være noget med at have en
reference-tæller i sin servlet så man kan detektere når Tomcat unloader
alle servlets i applikationen før ny deployment. Hvis du evt. finder på
noget godt her vil jeg gerne høre om det.


Mvh,
--
Filip Larsen

---

Filip Larsen <filip@nospam.dk> writes:

>
> Problemet består måske mere i at afslutte disse ekstra tråde når man
> fx. gerne vil deploy'e en nyt version af applikationen. Jeg har ikke

Du kan putte et objekt i applicationscope, og lade det lytte på
hvornår Tomcat hiver det ud af applicationsscope. Bruger det selv på
sessionsniveau til at lukke forbindelser når en bruger logges ud pga
inaktivitet.

Kan ikke huske hvad det hedder, men står garanteret i servlet speccen.
--
Thorbjørn Ravn Andersen

---

Filip Larsen wrote:
> Nej, du kan sagtens køre hvad du ønsker som selvstændige tråde under
> Tomcat, fx. initialiseret som en static singleton i en auto-start
> servlet. Jeg har en Tomcat kørende med indtil flere tråde der periodisk
> læser xml-filer og laver database oprydning (med Hibernate).
>
> Problemet består måske mere i at afslutte disse ekstra tråde når man fx.
> gerne vil deploy'e en nyt version af applikationen. Jeg har ikke haft
> tid til at løse dette problem ordentligt (jeg genstarter Tomcat før jeg
> deployer ny version), men det kan måske være noget med at have en
> reference-tæller i sin servlet så man kan detektere når Tomcat unloader
> alle servlets i applikationen før ny deployment. Hvis du evt. finder på
> noget godt her vil jeg gerne høre om det.

Kan du ikke stoppe tråden i din servlets destroy metode ?

Arne

---

---

Mads Bahrt wrote:
> Produktet er en web-applikation, og vores "kunde" havde forestillet sig
> at vi brugte en Tomcatserver som platform. Dette virker imidlertid som
> et problem, da Tomcat, så vidt jeg kan gennemskue, kun kan køre opgaver
> som reaktion på en request. I vores problem er det imidlertid en central
> funktionalitet at kunne schedulere opgaver til at køre, f.eks. kl. 1 om
> natten, uovervåget. Er det korrekt forstået at man ikke kan få Tomcat
> til at køre en metode med et vist interval, uden at det bliver et hack
> bestående af cron og wget?

Nej.

Det nemmeste er at deploye en scheduler pakke som Quartz i
Tomcat.

http://www.theserverside.com/tt/blogs/showblog.tss?id=QuartzSchedulerInJ2EE

> Vi kigger som alternativ på at skrive vores domænelag i "normal java",
> og snakke fra Tomtcat med dette vha. RMI. dette har den fordel at vi i
> forvejen kender og er trygge ved J2SE-platformen. Vi skal i denne
> løsningsmodel dog sætte os ind i et persistensframework, da vi mener
> dette vil betale sig tilbage i brugt tid og give pænere kode. Er
> Hibernate et godt valg?

Hibernate er ihvertfald et meget brugt persistens framework.

> En anden løsningsmodel vi overvejer er at gå fra en servlet-container
> til en hel Java EE container som f.eks. JBoss. Her har jeg set at der
> findes en afviklingsmodel baseret på timere. Ville denne evt. også være
> tilgængelig i Tomcat eller kræver det en fuld Java EE container?

Rigtig J2EE timers relaterer sig til session beans og
kræver derfor en EJB container.

> Hvor
> omfattende er Java EE at sætte sig ind i når man allerede kender Java
> SE? Hvor omfattende er det når man medregner at man sparer at lære et
> løst persistensframework at kende?

J2EE er faktisk ret omfattende. Men man behøver jo ikke nødvendigvis
at lære alt for at bruge noget af det.

> Er der nogle begrænsninger i at kunne lave socketbaseret I/O fra f.eks.
> JBoss? Dette er nemlig nødvendigt for at kunne udføre
> kernefunktionaliteten.

Outbound sockets er ikke det store problem.

Inbound sockets bør laves med en inbound JCA adapter.

> Overordnet set søger jeg kommentarerer på hvor grimt et semiheterogent
> Tomcat-kalder-J2SE-persisterer-i-hibernate system er kontra hvor egnet
> Java EE er til en applikation hvor hovedfunktionaliteten udføres
> asynkront af webinterfacet igennem timere.

Jeg vil mene at Tomcat---(RMI)---J2SE app er en ret grim konstruktion.

Tomcat med Quartz hvis det er godt nok. Ellers JBoss med das ganze
molevitten.

Hvis JBoss så husk og overvej message queues/JMS/MDB's.


> Samtidig ønsker jeg kommentarer på læringsbyrden i Hibernate kontra Java
> EE eller om man skulle kigge på et andet persistensframework end hibernate.

Hvis du hopper på EJB 3.0 så er forskellen på Hibernate og EJB ikks så
stor som den har været.

Arne

---

Mads Bahrt <mads_bahrt@hotmail.com> wrote in
news:er4g2d$scn$1@news.net.uni-c.dk:

> Vi kigger som alternativ på at skrive vores domænelag i "normal java",
> og snakke fra Tomtcat med dette vha. RMI. dette har den fordel at vi i
> forvejen kender og er trygge ved J2SE-platformen. Vi skal i denne
> løsningsmodel dog sætte os ind i et persistensframework, da vi mener
> dette vil betale sig tilbage i brugt tid og give pænere kode. Er
> Hibernate et godt valg?

Jeg har selv brugt Hibernate i et lille års tid på min tidligere
arbejdsplads. Den løsning vi implementerede var ret simpel. Den skulle bare
tage en POJO struktur og smide det i en database, som vores kunde så kunne
suge data fra. Nu er det godt et år siden jeg sidst var involveret i det,
men det jeg husker som største tidsrøver i forbindelse med Hibernate var at
få lavet mapningerne korrekte - har man ikke erfaring med andre
persisteringsframeworks/tankegangen så kan det altså godt tage en del tid
at få dem helt på plads :)

Vi brugte det ikke til også at hente data fra databasen og gendanne POJO
strukturen, selvom det også er en del af Hibernate. Det forestiller jeg mig
så at kunden evt. gjorde, men jeg blev tilbudt et nyt job inden det kom så
vidt :)

Hvis persisteringen evt. bare kunne være XML og tilbage igen så kunne i
tage et lille kig på Xstream - det er et dejlig lille framework og relativ
hurtigt at komme i gang med sammenlignet med Hibernate (efter min mening i
hvert fald).

http://xstream.codehaus.org/

Lidt god natlæsning er denne artikel der omhandler XML data binding - med
referencer og kommentarer om mange af de mest brugte frameworks:
http://www.rpbourret.com/xml/XMLDataBinding.htm

/flemming

---

Flemming Joensson <flemming@joensson.invalid> writes:

> Hvis persisteringen evt. bare kunne være XML og tilbage igen så kunne i
> tage et lille kig på Xstream - det er et dejlig lille framework og relativ
> hurtigt at komme i gang med sammenlignet med Hibernate (efter min mening i
> hvert fald).

Nu er der jo XML serialiseringen i Java 1.4+ - er det ikke brugbart i
produktion siden du foreslår ovenstående?
--
Thorbjørn Ravn Andersen

---

nospam0000@gmail.com (Thorbjørn Ravn Andersen) wrote in
news:yu2abzbeqh2.fsf@luhmann.netc.dk:

>> Hvis persisteringen evt. bare kunne være XML og tilbage igen så kunne
>> i tage et lille kig på Xstream - det er et dejlig lille framework og
>> relativ hurtigt at komme i gang med sammenlignet med Hibernate (efter
>> min mening i hvert fald).
>
> Nu er der jo XML serialiseringen i Java 1.4+ - er det ikke brugbart i
> produktion siden du foreslår ovenstående?

Jo, men har bare bedre erfaringer med XStream.

Hvad angår XMLEncoder/Decoder så mener jeg at huske at det API kræver at de
klasser der skal serialiseres til xml overholder javabeans spec - mens
XStream ikke har sådan en begrænsning. Vi havde en hulens masse klasser der
ikke overholdt denne spec da vi ledte efter et alternativ, og ved at vælge
Xstream slap vi for at skulle refactorere alle de klasser. En anden ting
var at vi både havde installationer i Java 1.3 og 1.4 dengang og Xstream
virker fra og med 1.3.

Men jeg må indrømme at jeg ikke har tjekket XMLEncoder/Decoder opførslen
eller JAXB siden 1.4, om der er sket noget fantastisk på den front i
5.0/6.0 aner jeg ikke.

Men generelt har jeg det sådan at hvis der er et veldokumenteret,
velfungerende third-party API der tilmed er hurtigt at komme i gang med, så
vælger jeg gerne thirdparty API'et :).

/flemming

---

Hej igen

Jeg glemte helt at sige tak for svarene, det afklarede en del.

MVH

Mads

---

Mads Bahrt <mads_bahrt@hotmail.com> writes:

[snip]
> Produktet er en web-applikation, og vores "kunde" havde forestillet
> sig at vi brugte en Tomcatserver som platform. Dette virker imidlertid
> som et problem, da Tomcat, så vidt jeg kan gennemskue, kun kan køre
> opgaver som reaktion på en request. I vores problem er det imidlertid
> en central funktionalitet at kunne schedulere opgaver til at køre,
> f.eks. kl. 1 om natten, uovervåget. Er det korrekt forstået at man
> ikke kan få Tomcat til at køre en metode med et vist interval, uden at
> det bliver et hack bestående af cron og wget?

Det er nok ikke Tomcat du vil have til at goere det, men din egen
applikation (som maaske tilfaeldigvis kan vaere en web-applikation til
at koere under Tomcat).

Du kan kigge paa ServletContextListener (google) til at taende
og slukke din schedulering under web-applikationer. Der findes mange
schedulerings mekanismer til Java, nok den simpleste er med i j2se;
java.util.Timer

> Vi kigger som alternativ på at skrive vores domænelag i "normal java",

Ja, skriv da endeligt ikke unormal Java Om din Java bliver
afviklet i en JVM under en container som Tomcat eller Jboss eller "plain j2se"
er i princippet ligegyldigt. JEE er "bare" nogen anbefalinger til
hvordan du kan skrive kode paa en standardiseret maade, og hvad du kan
goere for ikke at ende op med noget rod (ikke ment som flame af jee).

> dette vil betale sig tilbage i brugt tid og give pænere kode. Er
> Hibernate et godt valg?

Ja - proev kun at bruge ejb3 annotations. Saa kan du (hurtigere) skifte til
JEE hvis I skulle have lyst til at kaste Jer ud i det.

> En anden løsningsmodel vi overvejer er at gå fra en servlet-container
> til en hel Java EE container som f.eks. JBoss. Her har jeg set at der
> findes en afviklingsmodel baseret på timere. Ville denne evt. også
> være tilgængelig i Tomcat eller kræver det en fuld Java EE container?

Brug hellere noget simpelt som f.eks. java.util.Timer eller Quartz som
ogsaa er naevnt. De binder sig ikke op mod en bestemt container (= du
kan teste uden at starte + installere til containeren)

> Overordnet set søger jeg kommentarerer på hvor grimt et semiheterogent
> Tomcat-kalder-J2SE-persisterer-i-hibernate system er kontra hvor egnet
> Java EE er til en applikation hvor hovedfunktionaliteten udføres
> asynkront af webinterfacet igennem timere.

Grimt . Skriv saa meget kode du kan som normal j2se kode, og lav
derefter nogle simple "adapter" klasser til at interface med det framework
eller den container du vaelger - det er vist hovedideen i letvaegts-
programmering som er meget hypet for tiden

(Et eksempel her kunne vaere den ServletContextListener som jeg naevnte foer,
som er adapteren mellem Tomcat og din j2se kode)

> Samtidig ønsker jeg kommentarer på læringsbyrden i Hibernate kontra
> Java EE eller om man skulle kigge på et andet persistensframework end
> hibernate.

JEE og Hibernate med annotations er naesten ens. Proev at starte med
at undgaa at mappe relationer (klar dem manuelt), samt undgaa sammensatte
primaernoegler, det er det eneste hvor man lige skal holde tungen lidt lige.

Mvh,
Soren