at bruge com obejkter i jsp??

Du skal ikke oprette din database forbindelse fra en jsp side det vil være rigtig dumt og grimt og alle mulige andre grimme ord ;o)

En databaseforbindelse skal oprettes fra en servlet og her kan du anvende java kode lige som du gør i en alm. java fil, rettere sagt en servlet er en rigtig java fil :)
Du kan lige så godt lave det overskueligt fra starten af og benytte MVC strukturen.

ja det ved jeg godt alt det. Har kodet en del jsp :)
Men så fra en servlet hvis det skal være helt korrekt. Kan man da gøre brug af en ADO til at forbinde med. Ved godt at JDBC er klart at foretrække, men kan man?

gybel:
Hvorfor skal det absolut være en servlet ?

En servlet bruger man normalt kun som controller i et MVC pattern, resten laves af beans.


bumle:
Nej man kan ikke (gudskelov) bruge com objekter fra Java, det giver ingen mening. Java er platformuafhængigt, og com objekter er properitære.

Umiddelbart så er der ikke nogen forbindelse mellem ADO og java applikationer.
SÅ vidt jeg lige kan huske så kommunikere ADO med OLE DB og den ned til DBMS.
ADO er jo noget microsoft opfund til deres ASP og .net så jeg tror det ikke, men vil lige prøve at undersøge det :)
Men som sagt så tror jeg kun at det er ASP og .net der kan anvende ADO.

disky:

Ja af EJB.
Og det kommer lidt anpå hvilket niveau man er på om man anvender EJB eller simple beans.

Der er findes flere COM wrappers, så man kan pakke COM objekter ind i java klasser, og dermed kunne kalde COM fra JSP/Servlets m.m.

Det er et stykke tid siden jeg arbejdede med emnet, og kan desværre ikke huske hvad de forskellige COM wrappers hedder, beklager.

ok, det var også min umiddelbare tanke, men jeg blev nødt til at undersøge det.
Jeg har faktisk fundet noget, prøv at se det her
http://www.intrinsyc.com/support/j-integra/doc/
Det er et stykke software der kan binde COM objekter og java sammen. Eftersom ADO jo er et com objekt, så må det vel være muligt at bruge ADO fra sin java applikation. Eller er jeg helt ved siden af?

disky> du har som sædvanlig fået galt fat i fakta! man KAN kalde COM klasser m.m. fra java. Men det kører selvfølgelig kun på windoze platformen.

Man skal aldrig sige aldrig man kan med J++

Men men jeg holder på disky at det ikke er smart. ;)

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ado270/htm/mdmscusingadowithmicrosoftsdkforjava.asp

gybel> J++ er noget man skal holde sig fra, hvis man ikke har en rigtig god grund! 

Man kan dog også benytte "rigtig" java, det er bare noget mere besværligt end med J++, da man skal igang med JNI API'et.

Det kan dog af og til være særdeles praktisk at kunne kalde COM objekter m.m. fra Servlets/EJB, da verden også består af non-java applikationer, og det kunne jo være man skulle integere med en standardapplikation.

flse: JA det er helt sikkert.. Jeg er sq heller ikke meget for J++ ;)
Det var bare lige der jeg fandt noget.

Så man kan altså godt istedet for jdbc gøre brug af ADO og dermed OLE DB i sin jsp-applikation?

flse:
Nope det er faktisk dig der ikke har styr på fakta (eller er ordkløver).

Det er dig der begynder at ville bruge properitære ting via JNI, disse ting tager jeg ikke engang med i overvejelserne, da jeg kræver ren java !.

J++ er ikke engang rigtig java, netop pga. alle microsoftes properitære ting, bruger man J++ er man selv uden om alle de problemmer man får.

disky> nej, spørgsmålet var om det kunne lade sig gøre, og svaret er JA, og JNI er skam en del af java.

Kun amatører vælger at benytte skyklapper, og nægte at forholde sig til at der ude i samfundet også benyttes andet end java, og at man af og til faktisk bliver nødt til at snakke med disse produkter på en eller anden måde.

bumle> hvis det bare er databasen du skal have fat i, så kan jeg ikke se hvorfor du ikke vil benytte JDBC, da det er langt hurtigere og mindre ressourcekrævende end at starte COM wrappers op, samt du kan KUN benytte løsningen på Windoze.

Hvis man skal forsvare brug af ADO/COM/OLE fra Java, så skal det være fordi man ad den vej kan få fat i ting der ellers ikke er muligt fra java.

Grunden til at jeg spørger er fordi jeg skal finde alternativer til jdbc og sammenligne disse med brugen af jdbc. Det er et eksamenspørgsmål, hvor jeg bare skal snakke løs om forskellige måde at forbinde til en database, så jeg skal bare finde en masse for/mod argumenter til de forskellige ting.
Nu er ADO og ADO.net jo de eneste der kan bruges fra en scripting side som MS tilbyder. Og så lige selvfølgelig odbc, men det er jo ikke et com-objekt. Så der ville man skulle bruge jdbc:odbc broen.
Men hvad vil for/mod argumenterne være for at bruge ADO i sin jsp-sider ?

JNI er det også det der hedder JNDI  ?(Java Naming and Directory Inteface)

bumle> hvis  man vælger at benytte ADO som alternativ til JDBC i java udelukkende for at få fat i databasen, så vil det svarer til at vælge at slå søm i med en våd søndagsberlinger :-)

ADO giver derimod straks meget mere mening, hvis man arbejder med ASP eller VisualBasic.

flse:
JNI er en del af java, men det er IKKE ren java.

Java er platformsuafhængigt ! Det er det IKKE hvis man bruger JNI.

Ja i sjældne tilfælde kan det være nødvendigt at bruge native ting, men i videst muligt omfang er det at foretrække at lade være med dette. I langt de fleste tilfælde findes der alligevel løsninger på dette i java i forvejen.

Bortset fra det, den eneste amatør her er vist dig, som åbenbart gerne vil bruge properitære løsninger istedet for dem som java levere.

Selvfølgelig er JNI en del af java, men en del man helst skal undgå at bruge, da prisen er at netop det gode ved java forsvinder, nemlig platformsuafhængigheden. Når man begynder med JNI kan man ikke længere bare skifte OS på serveren fra f.eks. Windows til Linux/Solaris osv.

Denne pris er noget man virkeligt skal tænke på i design spørgsmål, men du synes jo åbenbart det er irelevant og tage dette med i overvejelserne.

Så inden du en anden gang begynder at udtale dig om folks evner, synes jeg du skulle tage og sætte dig lidt ind i tingene og ikke mindst se på dine egne evner først.

JNI er Java Native Interface, og den måde man fra Java kan lave kald ud af java.  Såfremt det er muligt er det dog langt bedre at benytte RMI/XML/SOAP til at snakke med andet software, da man dermed ikke binder sig til en bestemt hardware platform

disky> prøv for engangs skyld at læse hvad der bliver skrevet!

Jeg ville sætte pris på hvis du som vi andre kunne holde det på et sagligt niveau, og svare på det folk spørger om, undlade at kritisere andres valg, og iøvrigt hæve dig over børnehaveniveauet. TAK!

flse:
Denne her kommentar er virkeligt sjov:
>Jeg ville sætte pris på hvis du som vi andre kunne holde det på et sagligt
>niveau, og svare på det folk spørger om, undlade at kritisere andres valg, og
>iøvrigt hæve dig over børnehaveniveauet. TAK!

Sjovt at netop du skal komme med sådanne en udtalelse, den passer nemlig perfekt på dig selv.
Du begyndte at rette på andre, du begyndte med at svine folk til, du vil fremhæve din bedre viden osv.


Så den der er på børnehave niveau er vist nok dig selv.

For at vende tilbage til spørgsmålet.
Fra java kan man ikke, jeg pointere IKKE snakke med COM objekter direkte. Man skal igennem properitær kode som et JNI nu engang er. Selvfølgelig er dette et definitions spørgsmål, men bumle's problematik gik på om man kunne fra java, ikke om man kunne fra java via properitær og systemspecifik kode.

bumle:

JNI og JNDI er ikke det samme, det er to helt forskellige teknologier.

disky> JNI er en del af Java som SUN har defineret det, men det er da rart at vide at de har taget fejl :-)

Du er da godt nok for sjov, men kvik er du nu ikke.

Det er GRÆNSEFLADEN der er defineret af SUN, IKKE det man snakker med igennem denne grænseflade.

Og ved at bruge JNI mister man den geniale platformsuafhængighed som netop er det smarte ved JAVA.

disky> hvis du ellers gad læse andres kommentarer, ville du vide at jeg sagde at det kunne lade sig gøre, men at jeg ikke anbefalede det.

Det er da godt nok en imponerende holdning: "jeg kan ikke lide det, ergo eksisterer det ikke".  Du er nok bare dummere end andre folks børn, men det kan man jo ikke bebrejde dig :-)

Iøvrigt stopper den diskusion her!  Gider ikke diskutere på det plan. EOD!

Ja og jeg startede med at sige det kunne MAN IKKE fra java, for det KAN MAN IKKE.

Det kræver nemlig NATIVE kode.

Men det forstår du tydeligtvis ikke.
Men hvad kan man forlange af en person der mener han kan alt (ja jeg har set din kompetence profil på din hjemmeside)

EOD.

Bumle:
Fang mig på ICQ hvis du har spørgsmål, jeg er blevet træt af 'flse von Besserwisser'

Flot nu tiltede experten så min lille opgave til flse forsvandt.

flse du er jo skide god mener du selv, så du vil jo gerne underbygge dine påstande om at jeg er amatør og du bare er super god.
Derfor denne lille mini opgave.
a
Opgaven:
-Lav i REN java noget der kan snakke med et COM objekt.

Definition:
Med ren java menes der at du IKKE må anvende andre teknologier som programmerings sprog, scriptsprog osv.
Altså kun lave kode der kan kompiles med SUN's 'javac' fra JDK1.4.1


Hvis denne opgave kan løses, så har du vist at man i Java godt kan snakke med et COM objekt og selvfølgelig indrømmer jeg så at jeg tog fejl.
Kan du derimod ikke løse opgaven, har du selv bevist at din påstand om at man kan snakke med et COM objekt fra java er forkert.


Detaljen er her at der blev spurgt om man fra JAVA kunne snakke med et COM objekt.
Hvilket jeg sagde nej til, for det ville kræve native kode i form af native windows kode som skulle være interface imellem JNI og COM objekt.

Lidt blandede kommentarer.

1)  Jeg har også tidligere set produkter som kunne
    wrappe en COM component, så den kunne bruges som
    Java bean. Men jeg kan heller ikke huske produktets
    navn.

2)  Ja - det er et totalt overkill med en COM wrapper
    til dette formål.

3)  Hvis du skal lede efter alternativer til JDBC, så
    skal du nok kigge efter EJB entity beans og JDO.
    At de bruger JDBC bagved er nok ligegyldigt for
    din problem-stilling. Måske JSQL/SQLJ.

4)  JNI og JNDI har intet med hinanden at gøre. JNI
    er Java's måde at kalde native kode (.DLL i Windows,
    .so i Unix) på. JNDI er et directory API (ikke en
    implementation).

5)  Der er masser af steder, hvor man i Java verdenen
    bruger native kode. JNI i J2SE. JDBC type 2 drivers.
    Native libraries tilladt i JCA. Etc.etc..

6)  Man kan iøvrigt intet absolut intet i Java uden
    native kode, fordi langt nede i bunden af Java API
    ender man i noget native kode.

7)  Men man skal naturligvis ikke bruge native kode
    medmindre man har en god grund til det.

Det har godt nok været god respons på mit spørgsmål må jeg sige, og jeg har med stor interesse fulgt diskussionen, jeg har ihvertfald lært noget af den hæhæ :)