[JSP] Problemen met remote beans

[Super Snackman]

Heya all,

ik heb een JBoss-applicatie server draaien, met daarop een hele simpele bean:
Een veld gebruiker van het type string, en methodes om deze op te vragen/in te stellen.

Nu kan ik met mijn JSP-pagina van deze bean gebruik maken. Maar helaas is het zo dat als ik op machine2 als naam 'SuperSnackman' instel, hij op machine1 ook als naam 'SuperSnackman' krijgt. Ik zou juist via deze beans elke gebruiker zijn eigen sessie willen geven.

Heeft iemand mischien tips die ik client/server-side kan toepassen. (Bijvoorbeeld in de XML-files ofzow). Waardoor dit wel goed gaat werken. Want anders lijkt deze opzet niet te werken. En als ik de JSP/EJB tutorials doorlees moet het toch zeker kunnen...

Ik maak nu gebruik van beans die SessionBean als interface gebruiken. En de JSP-pagina's staan op een Tomcat server. Via RMI roep ik de Beans aan op de JBoss server.

[ Voor 13% gewijzigd door Super Snackman op 25-02-2003 01:24 ]

[yrew]

Je bedoelt dat allebei je beans zo heetten?

Op het moment dat iemand jouw jsp pagina opent dan krijg die persoon zijn eigen verwijzing naar de bean. Het is niet zo dat er maar 1 bean geinstantieerd wordt en dat iedereen dan gebruik maakt van die ene bean.

[Super Snackman]

Hij doet precies wat hij niet zou moeten doen, volgens mij.

Als ik een StateLess bean maak, dan krijg ik dus zoals ik het hierboven beschreef. MAar bij StateFull maakt hij IEDERE KEER een nieuwe bean. Heeft iemand enig idee hoe ik dan bij de volgende JSP pagina weer van de OUDE bean gebruik maak.

Edit

Het is mischien neit eens zo raar wat hij doet. het is natuurlijk neit de bedoeling dat je gelijk de velden van een stateless bean opvraagt. Toch rest mij dan nog ff de vraag, hoe maak ik bij een volgende JSP pagina van de oude bean gebruik?
Ik zal gelijk ff wat handleidingen doorspitten hierover, maar als iemand van jullie dat gelijk zou weten, zou dat natuurlijk heel erg fijn zijn.

[ Voor 41% gewijzigd door Super Snackman op 25-02-2003 09:58 ]

[yrew]

als je in de volgende pagina gebruik wil maken van de bean zul je moeten zorgen dat de referentie naar de bean onthouden wordt. Dit is op te lossen door bijvoorbeeld de gebruikersnaam/id/ipadres door te geven in de querie-string en aan de hand hiervan de juiste referentie weer opzoeken...Ik denk overigens wel dat dit makkelijker kan dan dat ik beschrijf.

[Super Snackman]

Ik zie dat je met SessionContext inderdaad weer van een bestaande bean gebruik kan maken. Maar ik snap alleen nog niet HOE ik hier goed gebruik van maak.
Ik zie bijvoorbeeld dat bij een StateLess bean iedere keer dezelfde SessionContext wordt gebruikt, en bij StateFull iedere keer een andere.
MAar als ik dus op de 1 of andere manier dat inderdaad weer een oude SessionContext kan gebruiken bij een statefull bean...

(Iemand? )

[Super Snackman]

Ik heb een controller-bean, met daaraan vast een persistente bean. In deze bean staat een hashtabel met hashes, en aan de andere kant de locatie van de controller-bean in de pool.
Op het moment dat een gebruiker een sessie begint wordt zijn hash samen met zijn controller-bean in de pool gezet. Door iedere keer deze hash te gebruiken, weet je bij welke bean welke gebruiker hoort.

Mischien omslachtig, maar het wurkt wel. Thx iig

[Verwijderd]

Het is een verkeerde denkwijze om hier een Stateless bean voor te gebruiken.
Een stateless bean kan bij elke aanroep door iemand anders gebruikt worden.
Hij staat in een pool. Bij elke methode aanroep kan je een andere krijgen.
Het heeft dus geen zin en referentie naar een Stateless bean in je SessionContext op te slaan.
Hiervoor moet je een statefull bean gebruiken. Dit kost echter meer resources.
Bij weinig informatie kan je die beter direct in de SessionContext opslaan.

[Super Snackman]

Ik gebruik op dit moment dan ook een StateFul bean. Maar op de 1 of andere manier moet bij een nieuwe JSP-pagina die een client opvraagt hij zijn oude bean weer voorgeschoteld krijgen. Dus dat zal toch ergens bijgehouden moeten worden.
Op de 1 of andere manier gaat dat automatisch als ik de java-classes lokaal heb staan, en ze via een simpele JSP-tag aanroep.
Maar op het moment dat ik RMI gebruik om een remote bean aan te roepen, maakt hij bij elke create een nieuwe bean aan. En dat heb ik dus nu opgelost, door een client-identificatie te koppelen aan zijn bean. Deze combo gooi ik in een hashtable, en zo kan iedere client vrolijk met zijn eigen stateful session bean werken.

[Verwijderd]

Ik kan het niet helemaal overzien, maar ik ben bang dat je niet helemaal de officiele manier gebruikt. Kan je niet gewoon de referentie naar de bean in je Session opslaan?

Misschien is het ook een idee om dan eens te kijken naar entity beans.
Dan kan je de informatie persistent maken. En is het dus niet weg als je bean expired.

[Super Snackman]

Een Session-full bean blijft zo lang in de pool als dat je hem tijd hebt gegeven bij zijn instellingen. En bij Entity beans kan je niet iedere client z'n eigen sessie geven. (Daarom heten die andere dingen ook Session Beans).

En ik zou niet weten wat er onofficieel aan is, om de locatie van de bean in de pool te koppelen aan de client. En dit op de server te doen.

[Verwijderd]

MIschien doelt bierdopje op de regels omtrent de naamgeving van een Bean? Ik weet het anders ook niet zodat je bijvoorbeeld niet, zoals veel mensen hier helas voor gewoonte hebben, private members vooraf laat gaan met een underscore. Dat is natuurlijk compleet not done, maar goed ik dwaal af.

Maar goed even in het kort het verschil tussen een Statefull en een Stateless session bean. Ten eerste even een veel gemaakte misvatting uit de weg ruimen. Van beide type Beans mogen/kunnen instanties worden gecreeerd. Het enige verschil is dat een stateless bean alleen informatie in zijn variabele heeft tijdens de invocatie, en bij een statefull bean kunnen die variabelen ook buiten de invocatie een waarde hebben.

[Super Snackman]

Dat verschil en alles is me na het vele expirimenteren helemaal duidelijk geworden. HEt nadeel van een Session-bean is dat deze gebruikt kan worden gedurende de sessie. En een sessie loopt in principe af als je de JSP-pagina binnen hebt gekregen.
Dit wil NIET zeggen dat jouw bean daarna ook vernietigd wordt! Als je gewoon je session-bean instelt om nooit te verlopen, zal hij na het aanmaken altijd in de pool blijven staan.
Om toch weer een client zijn oude bean terug te geven heb ik deze min-of-meer omweg gemaakt.

[Verwijderd]

> Mischien doelt bierdopje op de regels omtrent de naamgeving van een Bean?
Lijkt me niet.

> En een sessie loopt in principe af als je de JSP-pagina binnen hebt gekregen.
Dat is nieuw voor me!

Wat ik bedoel is de manier waarop je de bean in je pool terug wil vinden.
Je bouwt volgens mij op jou manier je eigen session management, terwijl je daarvoor je webcontainer hebt.
Je kan referenties naar Beans in je session opslaan zodat ze bewaart blijven tussen de verschillende aanroepen.
Waar je op moet letten is dat je session timeout van je webcontainer lager staat dan de timeout van de bean in de pool, anders kan je een dooie referentie hebben.
Je timeout van de bean in de pool op oneindig zetten is niet echt slim.
Dit kost namelijk veel te veel resources. Die timeout moet je gewoon een beetje tunen.
Je moet hem dus in ieder geval langer zetten dan je timeout van je webcontainer.
Een shopping basket bijvoorbeeld hoef je ook niet langer te bewaren dan een paar uur.
Hoogsten een dag. Als session informatie langer wil bewaren moet je het gaan persisteren in de database. En daarvoor kan je dus makkelijk Entity beans gebruiken...
Hoop dat het wat duidelijker is.

[Super Snackman]

Kan jij mij dan uitleggen hoe ik op jouw manier bij het opvragen van een nieuwe JSP-pagina diegene weer met zijn oude Session-bean laat werken. Je zegt 'in de session opslaan'. Hoe werkt dat dan?

En over die oneindige timeout: we laten de sessie aflopen op het moment dat de gebruiker op uitloggen klikt, en dan wordt zijn bean ook verwijderd.

[ edit ]
Uitleggen in Computertaal, en niet in grote-mensen-taal

[ Voor 12% gewijzigd door Super Snackman op 28-02-2003 19:05 ]

[Verwijderd]

In je jsp pagina kan je de HttpSession variabele "session" gebruiken:

session.setAttribute("variableName", beanReference);
Slaat de reference op.

YourBean yb = (YourBean) session.getAttribute("variableName");
Haalt je reference weer op.

Volgens mij is dat alles. Ik kan me herinneren dat er ook ergens attribute methods zijn
waarbij je ook nog een application scope mee kan geven.

> Uitleggen in Computertaal, en niet in grote-mensen-taal
Gelukt?

[Super Snackman]

Je moet dus idd met een HttpSession gaan werken. Ik had daar al iets aan informatie over gevonden, maar nog niet hoe je het goed kan implementeren.

Vind het eerlijk gezegd niet een heel fijn systeem allemaal. Erg langzaam, slecht gedocumenteerd, ontzettend onlogisch inelkaar gestoken. (6 bestanden om te configurer, classes die overal en nergens moeten staan).

Iig thx voor je info

[Verwijderd]

Dat ben ik het niet helemaal met je eens...

> Erg langzaam
Het zou sneller kunnen, maar het is wel erg schaalbaar.

> slecht gedocumenteerd
Zijn goede boeken over te krijgen.
En hopen voorbeeld/opensource applicaties.

> classes die overal en nergens moeten staan
, daar wen je aan en als je eenmaal wat lastigere dingen met verschillende libraries moet doen, dan ga je van dat hierarchische model van classloaders houden.

Ik heb zelf een boek over JBoss en dan wordt er al een hoop duidelijker.
Tevens een boek alleen over de J2EE standaard wil ook al eens verhelderend werken.

Maar je moet idd wel even een stukje doorbijten. Geen grafisch sleur en pleur.

[Super Snackman]

Ik heb alle mogelijke PDFjes die ik heb kunnen vinden over dit onderwerp gedownload. Maar zelfs daarin vind ik dat het nogal beknopt is enzo.

Mastering Enterprise Java Beans
JSP & Ejb - Java on the Edje

Nog wat O'Reilly shit. Maardannog. Geef mij maar good'ol PHP&Mysql

[Verwijderd]

> Ik heb alle mogelijke PDFjes die ik heb kunnen vinden over dit onderwerp gedownload.
Dat klopt wel ja. Ik kan je dan ook aanraden wat boeken te kopen.
Wrox en O'Reilly hebben goede boeken.

> Geef mij maar good'ol PHP&Mysql
Jah, gebruik ik ook wel eens, maar alleen voor website-jes.
Als je iets grotere (web) applicaties wil bouwen die ook met andere applicaties kunnen communiceren, dan heb je meer nodig.
O.a. een middle tier die je ook vanuit andere applicaties kan gebruiken.

Ik ontwikkel zelf veel in de EAI wereld en dan is een hoop lagen onontbeerlijk.
Je wil dan echt niet tegen een database aanpraten...

[Verwijderd]

En dan heb ik trouwens nog niet over het verschil in taal tussen Java en PHP.
PHP is scripting en Java is een strong typed programmeer taal waarin je veel stabielere code kan schrijven.

[Super Snackman]

Dat geloof ik allemaal. MAar het gaat hier om een formulieren systeem. (Wel zeer uitgebreid). Heel veel formulieren met informatie die elke gebruiker in kan vullen, en op kan vragen. Elke gebruiker heeft z'n eigen serie formulieren. En elk formulier bestaat weer uit subformulieren etcetera.
In principe zou PHP niet misstaan

[Verwijderd]

Heb je gelijk in. Je moet geen overkill gebruiken.
Wil ook niet php afkraken, gebruik het zelf ook wel eens.

Maar stel je voor dat je met een andere applicatie die gegevens ook wil uitlezen.
Dan zit je logica in php pagina's en niet in in een algemeen aan te roepen component zoals
een Enterprise Java Bean. Dan moet de aanroepende applicatie die logica weer schrijven en
wordt de logica niet afgedwongen door de applicatie die wordt aangeroepen...
Het zou mooi zijn als php ook ondersteuning had voor componenten (in php) die je remote aan kan roepen en die even makkelijk te gebruiken zijn.

Maar goed, dat is een heel ander onderwerp dan je probleem... wel een leuke discussie die ik te weinig zie. Zou graag meer discussies zien over design patterns en dergelijken.