---

Jeg er ved at modellerer nogen kernekomponenter i vores applikation,
og jeg vil gerne undgå at lave BMP da det er nogen ret komplekse ting.
Er der nogen CMP-løsninger som kan hitte ud af at have en-til-mange
relationer imellem tabeller i en enkelt bean, og hvor man kan afprøve
teknologien først?

Valget af applikationsserver er ikke gjort endnu (selvom JBoss virker
ret fin), så der er ingen begrænsninger der.

Nogen der har erfaringer?
--
Thorbjørn Ravn Andersen
http://homepage.mac.com/ravn

---

"Thorbjoern Ravn Andersen" <thunderbear@bigfoot.com> wrote in message
news:kkadq3yxys.fsf@mimer.null.dk...
>
> Jeg er ved at modellerer nogen kernekomponenter i vores applikation,
> og jeg vil gerne undgå at lave BMP da det er nogen ret komplekse ting.
> Er der nogen CMP-løsninger som kan hitte ud af at have en-til-mange
> relationer imellem tabeller i en enkelt bean,
____________________

Det tror jeg ikke, hvis ellers jeg forstår dig ret (prøv evt. at uddybe).

Pointen er en-bean til en-tabel og en-bean-relation-til-anden-bean til
en-tabel-relation-til-anden-tabel.
Det gælder osse en-til-mange relationer, og du vil kunne gøre det
deklarativt med
CMP i de fleste servere ved deployment (jeg har dog ingen erfaring
med JBoss - men den skulle vistnok være udmærket.)

Mvh. Steen
____________________



og hvor man kan afprøve
> teknologien først?
>
> Valget af applikationsserver er ikke gjort endnu (selvom JBoss virker
> ret fin), så der er ingen begrænsninger der.
>
> Nogen der har erfaringer?
> --
> Thorbjørn Ravn Andersen
> http://homepage.mac.com/ravn

---

"Steen Jorgensen" <seldrup@get2net.dk> writes:

> > Jeg er ved at modellerer nogen kernekomponenter i vores applikation,
> > og jeg vil gerne undgå at lave BMP da det er nogen ret komplekse ting.
> > Er der nogen CMP-løsninger som kan hitte ud af at have en-til-mange
> > relationer imellem tabeller i en enkelt bean,
> ____________________
>
> Det tror jeg ikke, hvis ellers jeg forstår dig ret (prøv evt. at uddybe).
>
> Pointen er en-bean til en-tabel og en-bean-relation-til-anden-bean til
> en-tabel-relation-til-anden-tabel.
> Det gælder osse en-til-mange relationer, og du vil kunne gøre det
> deklarativt med
> CMP i de fleste servere ved deployment (jeg har dog ingen erfaring
> med JBoss - men den skulle vistnok være udmærket.)

Jeg er blevet belært om at i EJB 1.0 skal man ikke lave en bønne pr
tabel, hvis de objekter der behandles egentlig består af flere
tabelopslag, dels på grund af at objektet gerne skulle abstraheres fra
databaselaget, og dels at overheadet ved at kalde mange entitetsbønner
hurtigt bliver meget stort, og det vil jeg gerne undgå.


--
Thorbjørn Ravn Andersen
http://homepage.mac.com/ravn

---

"Thorbjoern Ravn Andersen" <thunderbear@bigfoot.com> wrote in message
news:kkr8jf9lbg.fsf@mimer.null.dk...
> "Steen Jorgensen" <seldrup@get2net.dk> writes:
>
> > > Jeg er ved at modellerer nogen kernekomponenter i vores applikation,
> > > og jeg vil gerne undgå at lave BMP da det er nogen ret komplekse ting.
> > > Er der nogen CMP-løsninger som kan hitte ud af at have en-til-mange
> > > relationer imellem tabeller i en enkelt bean,
> > ____________________
> >
> > Det tror jeg ikke, hvis ellers jeg forstår dig ret (prøv evt. at
uddybe).
> >
> > Pointen er en-bean til en-tabel og en-bean-relation-til-anden-bean til
> > en-tabel-relation-til-anden-tabel.
> > Det gælder osse en-til-mange relationer, og du vil kunne gøre det
> > deklarativt med
> > CMP i de fleste servere ved deployment (jeg har dog ingen erfaring
> > med JBoss - men den skulle vistnok være udmærket.)
>
> Jeg er blevet belært om at i EJB 1.0 skal man ikke lave en bønne pr
> tabel, hvis de objekter der behandles egentlig består af flere
> tabelopslag, dels på grund af at objektet gerne skulle abstraheres fra
> databaselaget, og dels at overheadet ved at kalde mange entitetsbønner
> hurtigt bliver meget stort, og det vil jeg gerne undgå.
>


Stadig hvis jeg forstår dig ret ...
Et eksempel: et person kan have flere adresser. Tabelmæssigt laver du en
person-tabel og en adresse tabel, med en foreignkey mellem de to.
Er det du vil så, at du kun vil have én CMP-entity-person-bean, med Fields
som
svarer til columns i både person- og adresse-tabellerne? Og som så
automatisk skal kunne
håndtere fx. en ejbCreate(fornavn, efternavn, gade, by, postnr ... )?

Jeg skal da ikke afvise det, men det siger mig ikke noget, og jeg må
indrømme
jeg ikke rigtig tror på det?

Mvh. Steen


>
> --
> Thorbjørn Ravn Andersen
> http://homepage.mac.com/ravn

---

"Steen Jorgensen" <seldrup@get2net.dk> writes:

> Stadig hvis jeg forstår dig ret ...
> Et eksempel: et person kan have flere adresser. Tabelmæssigt laver du en
> person-tabel og en adresse tabel, med en foreignkey mellem de to.
> Er det du vil så, at du kun vil have én CMP-entity-person-bean, med Fields
> som
> svarer til columns i både person- og adresse-tabellerne? Og som så
> automatisk skal kunne
> håndtere fx. en ejbCreate(fornavn, efternavn, gade, by, postnr ... )?

Ja, næsten. Jeg tror at adresserne skal laves som en collection for
at give mening.

> Jeg skal da ikke afvise det, men det siger mig ikke noget, og jeg må
> indrømme
> jeg ikke rigtig tror på det?

Der findes tilsyneladende produkter der kan løse det, men det er
hverken trivielt eller billigt.

Eftersom jeg har meget nemt ved at se fordelen ved CMP, vil jeg godt
se mig _meget_ grundigt om, inden jeg opgiver at få det automatiseret
og får lavet hele molevitten som BMP.

--
Thorbjørn Ravn Andersen
http://homepage.mac.com/ravn

---

---

"Kristian Rasmussen" <elrond@krconsulting.dk> wrote in message
news:Pine.LNX.4.44.0206111608280.4989-100000@krconsulting.dk...
> On Mon, 10 Jun 2002, Steen Jorgensen wrote:
>
> >
> > "Thorbjoern Ravn Andersen" <thunderbear@bigfoot.com> wrote in message
> > news:kkr8jf9lbg.fsf@mimer.null.dk...
> > > "Steen Jorgensen" <seldrup@get2net.dk> writes:
> > > Jeg er blevet belært om at i EJB 1.0 skal man ikke lave en bønne pr
> > > tabel, hvis de objekter der behandles egentlig består af flere
> > > tabelopslag, dels på grund af at objektet gerne skulle abstraheres fra
> > > databaselaget, og dels at overheadet ved at kalde mange entitetsbønner
> > > hurtigt bliver meget stort, og det vil jeg gerne undgå.
> Godt princip!
>
> > Et eksempel: et person kan have flere adresser. Tabelmæssigt laver du en
> > person-tabel og en adresse tabel, med en foreignkey mellem de to.
> > Er det du vil så, at du kun vil have én CMP-entity-person-bean, med
Fields
> > svarer til columns i både person- og adresse-tabellerne? Og som så
> > automatisk skal kunne
> > håndtere fx. en ejbCreate(fornavn, efternavn, gade, by, postnr ... )?
>
> Det kan man også sagtens envejs - ved creation. Det er straks en anden
> sag, når data skal hives op igen. Det kan man ikke umiddelbart gøre uden
> at lave opslag på flere bønner. Og dog - jeg mener at have set en kammerat
> mappe en cmp over flere tabeller. Han brugte vidst nok suns deployment
> tool.
>
> Alternativt så brug EJB 2.0 i stedet for at prøve at opfinde den dybe
> tallerken selv. Tag fx. Orion, den er efterhånden ved at kunne klare
> relationer mellem bønner uden at leake connections og andet godt.
> Så ville man kunne boltre sig lige så tosset man har lyst til.
>

Jeg arbejder med Websphere, og er derfor lidt handicappet (osse) i
den her forbindelse.
Kan du kort skitsere forskellen mellem vers. 1.1 og 2.0 her?

Mvh. Steen

> Ellers er der jo også et bredt udvalg at vælge i mellem:
> Bea Weblogic 7.0 (Understøtter EJB2.0) ret peberet dog
> Oracle9ias(oc4j) eller Orion (de understøtter det også,
> mindste i samme udstrækning som Orion, dog har jeg læst på deres mailing
> liste at oc4j skulle kunne klarer det uden at blinke, man kan suge den
> fra technet)
>




> --
> mvh Kristian
> http://www.krconsulting.dk
>

---

Kristian Rasmussen <elrond@krconsulting.dk> writes:

> Alternativt så brug EJB 2.0 i stedet for at prøve at opfinde den dybe
> tallerken selv. Tag fx. Orion, den er efterhånden ved at kunne klare
> relationer mellem bønner uden at leake connections og andet godt.
> Så ville man kunne boltre sig lige så tosset man har lyst til.
>
> Ellers er der jo også et bredt udvalg at vælge i mellem:
> Bea Weblogic 7.0 (Understøtter EJB2.0) ret peberet dog
> Oracle9ias(oc4j) eller Orion (de understøtter det også,
> mindste i samme udstrækning som Orion, dog har jeg læst på deres mailing
> liste at oc4j skulle kunne klarer det uden at blinke, man kan suge den
> fra technet)

Takker. Jeg har siddet og kigget på hvilke muligheder der er for
persistens (kan man ikke få CMP, kan man vel få et minimalt BMP med
JDO), og der er vist bred enighed om at det er svært og at dem der har
løst det gerne vil have penge for ulejligheden. Netop fordi vi leder
efter noget som kan løse problemet en gang for alle, vil vi godt have
så godt et produkt som muligt, kombineret med open source (det gør
ikke noget det koster noget, men vi vil gerne have det også findes om
5-10 år). Denne applikation kan forventes at skulle køre i mange år.

Da vi bruger Oracle, vil det være nærliggende at kigge på deres
applikations server, men jeg har fået en fornemmelse af at det er ny
teknologi, og derfor skal bruge noget tid til at blive helt modent.

Med hensyn til EJB 2.0, kunne jeg godt bruge en rigtig god tutorial
baseret på at man godt ved hvordan EJB 1 er skruet sammen. Nogen
anbefalinger?

--
Thorbjørn Ravn Andersen
http://homepage.mac.com/ravn

---

---

Kristian Rasmussen <elrond@krconsulting.dk> writes:

> Jeg ville nok gå efter CMP 2.0 alligevel. Bevares CMP 2.0 er ikke for
> kids, men det er bestemt besværet værd.

Det er også den fornemmelse jeg har. Det er bare lige lovligt
uhåndgribeligt at få på plads.

> Hvis I allerede bruger Oracle så er det jo oplagt at benytte deres
> bønnegård. Oc4j 9.0.3 er vidst nok det mest stabile de har præsteret
> endnu. 9.0.2 kom i en final release for ca. en måned siden, mener de
> rettede et CMP problem med connections leaks i det. Jeg kører selv på
> 9.0.3. (pzzt. bruger dog Orion 1.5.4 privat)

Vi er ikke migreret til 9i endnu, da jeg har problemer med at få den
nyeste rullet ind på vores Solarismaskine, så vi kører pt kun på en
non-i-version.

> > Med hensyn til EJB 2.0, kunne jeg godt bruge en rigtig god tutorial
> > baseret på at man godt ved hvordan EJB 1 er skruet sammen. Nogen
> > anbefalinger?
> O'Reilly Enterprise Java Beans 2.0 - det er en meget god håndbog. Den
> dækker bla. CMP 2.0, herunder også QL.

Ok. Den får jeg fat i. Tak for tippet.

--
Thorbjørn Ravn Andersen
http://homepage.mac.com/ravn

---

Kristian Rasmussen <elrond@krconsulting.dk> writes:

> Jeg ville nok gå efter CMP 2.0 alligevel. Bevares CMP 2.0 er ikke for
> kids, men det er bestemt besværet værd.

Jeg har nu kigget grundigt på det og jeg vil give dig ret i at det er
lidt tricky, men det er lige præcis hvad vi skal bruge (selvom jeg er
bange for at vi har nogen besynderligheder der ikke kan proppes ind i
det her) på grund af de avancerede muligheder med EQL, som læner sig
godt op af de søgebehov vi har.

> Hvis I allerede bruger Oracle så er det jo oplagt at benytte deres
> bønnegård. Oc4j 9.0.3 er vidst nok det mest stabile de har præsteret
> endnu. 9.0.2 kom i en final release for ca. en måned siden, mener de
> rettede et CMP problem med connections leaks i det. Jeg kører selv på
> 9.0.3. (pzzt. bruger dog Orion 1.5.4 privat)

Oracle 9ias er iøjeblikket ikke aktuel da vi stadig tøffer afsted på
Oracle 7, og selv om vi i øjeblikket afvikler på JBoss 2.4.x med
forsimplede EJB 1.1 konstruktioner, så ville jeg gerne skifte til en
passende EJB 2.0 container. Problemer er bare med JBoss at
dokumentationen er så elendig til at komme i luften med, så derfor vil
jeg godt høre om dine erfaringer med Orion, især med Oracle som
backend.

> O'Reilly Enterprise Java Beans 2.0 - det er en meget god håndbog. Den
> dækker bla. CMP 2.0, herunder også QL.

God bog. Tak for anbefalingen.

--
Thorbjørn Ravn Andersen
http://homepage.mac.com/ravn

---

"Thorbjoern Ravn Andersen" <thunderbear@bigfoot.com> wrote in message
news:kku1njlqzw.fsf@mimer.null.dk...
> Kristian Rasmussen <elrond@krconsulting.dk> writes:
>
<snip>

> Oracle 9ias er iøjeblikket ikke aktuel da vi stadig tøffer afsted på
> Oracle 7, og selv om vi i øjeblikket afvikler på JBoss 2.4.x med
> forsimplede EJB 1.1 konstruktioner, så ville jeg gerne skifte til en
> passende EJB 2.0 container. Problemer er bare med JBoss at
> dokumentationen er så elendig til at komme i luften med, så derfor vil
> jeg godt høre om dine erfaringer med Orion, især med Oracle som
> backend.

</snip>


Har du overvejet at købe dokumentationen (9.99$). Jeg havde ikke
noget problem med at sætte JBoss op fra bunden af, ud fra den købte
dokumentation. Den frivillige dokumentation stinker til gengæld og
findes nu kun i en JBoss 3 (med store dele af 2.4.x, der endnu ikke
er opdateret).

MvH
/Frank

---

"Frank Hahn" <efgeho@hotmail.com> writes:

> Har du overvejet at købe dokumentationen (9.99$). Jeg havde ikke
> noget problem med at sætte JBoss op fra bunden af, ud fra den købte
> dokumentation. Den frivillige dokumentation stinker til gengæld og
> findes nu kun i en JBoss 3 (med store dele af 2.4.x, der endnu ikke
> er opdateret).

Ja. Det er i praksis umuligt for os at købe noget via nettet.

Til gengæld er det ikke et problem at købe på almindelig vis hvor der
kommer en faktura til betaling, men det gør de vist ikke i.

Er dokumentationen værd at "investere i"? Her tænker jeg også på den
tid jeg skal bruge på at afgøre om JBoss 3.0 er værd at arbejde med -
som jeg skrev tidligere, er det et kardinalpunkt at CMP er i orden med
version 2.0. Kan det firma du arbejder i eventuelt sælge os en kopi
I køber online?
--
Thorbjørn Ravn Andersen
http://homepage.mac.com/ravn

---

"Thorbjoern Ravn Andersen" <thunderbear@bigfoot.com> wrote in message
news:kk4rfj1zrd.fsf@mimer.null.dk...
> "Frank Hahn" <efgeho@hotmail.com> writes:
>
> > Har du overvejet at købe dokumentationen (9.99$). Jeg havde ikke
> > noget problem med at sætte JBoss op fra bunden af, ud fra den købte
> > dokumentation. Den frivillige dokumentation stinker til gengæld og
> > findes nu kun i en JBoss 3 (med store dele af 2.4.x, der endnu ikke
> > er opdateret).
>
> Ja. Det er i praksis umuligt for os at købe noget via nettet.
>
> Til gengæld er det ikke et problem at købe på almindelig vis hvor der
> kommer en faktura til betaling, men det gør de vist ikke i.
>
> Er dokumentationen værd at "investere i"? Her tænker jeg også på den
> tid jeg skal bruge på at afgøre om JBoss 3.0 er værd at arbejde med -
> som jeg skrev tidligere, er det et kardinalpunkt at CMP er i orden med
> version 2.0. Kan det firma du arbejder i eventuelt sælge os en kopi
> I køber online?

Dokumentationen for JBoss 3.0 eksisterer ikke endnu (ikke til salg).
Kun den frivillig-baserede udgave af dokumentationen (gratis).

Grundet problemer med Tomcat 4+ og nogle legacy-opsætninger
Xalan1+Xerces1 er JBoss 3.0 foreløbigt ikke direkte under
overvejelse her. Så det er kun docs til 2.4 jeg har.

Alt der kræves for at købe online hos dem er et Visa-kort (eller lignende).
Jeg tror ikke man må videresælge den 1-bruger licens til docs, der blev
købt til mig.

Documentationen til JBoss 3.0 er under udarbejdelse, hvilket nok
fører til at vi opgraderer når den er færdig (og vores mindre tekniske
problemer er løste), da er de første "børnesygdomme" nok også
blevet fundet og løst (hurtig og effektiv fejludbedring i OSS software).

Hygge
/Frank

---

---

Nej det er der ikke.

CMP afspejler i relationsdatabaser en række i en tabel.

hvis du anvender CMP2.0 (Understøttes af JBoss 3.0) kan du lave relationer
mellem 2 cmp-bønner
, og så håndteres det som man forventer


hygge
flemming




"Thorbjoern Ravn Andersen" <thunderbear@bigfoot.com> wrote in message
news:kkadq3yxys.fsf@mimer.null.dk...
>
> Jeg er ved at modellerer nogen kernekomponenter i vores applikation,
> og jeg vil gerne undgå at lave BMP da det er nogen ret komplekse ting.
> Er der nogen CMP-løsninger som kan hitte ud af at have en-til-mange
> relationer imellem tabeller i en enkelt bean, og hvor man kan afprøve
> teknologien først?
>
> Valget af applikationsserver er ikke gjort endnu (selvom JBoss virker
> ret fin), så der er ingen begrænsninger der.
>
> Nogen der har erfaringer?
> --
> Thorbjørn Ravn Andersen
> http://homepage.mac.com/ravn