[j2ee] Sun Application Server 8: welcome file list werkt nie

[Verwijderd]

Ik zit met een vreemd probleem.

Ik heb een J2EE web applicatie, die onder de context root / van een site draait (bv localhost of www.mijnsite.nl). Als welcome-file-list heb ik een pagina genaamt index.jsp neergezet. Via een filter vang ik alle jsp requesten af en regel authentication. Onder Orion draait dit goed, maar zodra ik het onder Sun Application server 8 probeer, pakt ie mijn welcome file niet.

Als ik in mijn browser localhost intik dan krijgt het filter als request alleen een '/' en geen index.jsp. Als ik dan de volledige url opgeef, dus bv localhost/index.jsp werkt de hele web applicatie gewoon.

Het gaat dus alleen fout met die stomme welcome file en ik kan er maar niet achter komen wat het nou is, vooral omdat het onder Orion dus wel gewoon werkt.

[-FoX-]

Post je web.xml dan eens...

[djengizz]

En kijk ook eens in $install_dir\Sun\AppServer\domains\domain1\config\default-web.xml (of welk domein dan ook)

[Verwijderd]

Verwijderd schreef op 13 oktober 2004 @ 15:02:
Ik zit met een vreemd probleem.

...Via een filter vang ik alle jsp requesten af en regel authentication...

werkt het zonder die filter wel?
Is het resolven van de request naar de welcome file list iets wat gebeurt voor of na de filters. Hoe is die filter mapping(*.*, *.do, ..)?

[Verwijderd]

Even met mijn eigen web-app geprobeerd, en het klopt inderdaad. Ik draai zelf ook al tijden voornamelijk met Orion (volgens mij is er geen betere AS, maar dat terzijde), maar die Sun server pakt inderdaad de welcome file niet.

Voor de goede orde, ook ik heb een filter staan die jsp's afvangt voor authorisatie. Volgens mij doet echt elke denkbare web-app dat (er zijn niet zoveel andere zinvolle schema's voor authorisatie), dus dat zou geen issue moeten zijn.

Ik heb nu even geen tijd om het uit te zoeken, maar zal er mischien vanavond nog eens even dieper in duiken.

[Verwijderd]

Ik heb de oplossing nog niet gevonden (eerlijk gezegd nog niet heel veel gekeken, sorry), maar nu het toch over Orion en Sun Server gaat valt me nog het volgende op:

Als ik Orion 2.02 opstart staat ie echt in 2 seconden klaar voor het afhandelen van requesten, zelfs in debug mode. Vooral voor developpen is dat erg handig omdat je dan vaak de server moet stoppen en weer starten.

Sun Application Server 8 doet er echt bijna een minuut over voor dat ie klaar staat. In de tijd scrollen er ook 10-tallen configuratie berichten langs. Voor developpen is dat bijna een onwerkbare situatie.

[flowerp]

Sun Application server gebruikt toch veel dingen van tomcat? Iniedergeval is het snelheids verschil tussen sun en orion merkwaardig.

Een factor 30 is opstartsnelheid is toch raar. Je zou zeggen dat je dan een optie aan hebt staan dat ie alvast alle JSP's van te voren gaat compileren, maar volgens mij doet ie dat helemaal niet. Vreemde zaak, verpest de lol die je in het developpen hebt wel een beetje...

[Alarmnummer]

Verwijderd schreef op 14 oktober 2004 @ 20:21:
Ik heb de oplossing nog niet gevonden (eerlijk gezegd nog niet heel veel gekeken, sorry), maar nu het toch over Orion en Sun Server gaat valt me nog het volgende op:

Kun je niet een hot deploy doen? Dus gewoon de applicatieserver aanzetten, en daarna de webarchive erin plaatsen? Met JBoss werkt dat in ieder geval wel.

Waarom heb je trouwens een applicatieserver met ejb ondersteuning nodig?

[flowerp]

Alarmnummer schreef op 16 oktober 2004 @ 12:54:
[...]

Kun je niet een hot deploy doen? Dus gewoon de applicatieserver aanzetten, en daarna de webarchive erin plaatsen? Met JBoss werkt dat in ieder geval wel.

Wat de anderen gebruiken weet ik niet, maar zelf gebruiken wij Eclipse met de MyEclipse extension. Deze doet een zogenaamde exploded deploy. Dat is een mooi woord voor gewoon een hele directory die gecopieerd wordt eigenlijk ipv een .war. Deze kan nooit auto deployed worden maar moet altijd via de admin console met de hand gedaan worden.

Daarbij komt nog het feit dat als je aan het developpen bent je code toevoegd en veranderd. De sun AS ondersteund niet (volledig) hot code replace, en dat vertrouw ik toch al zo niet. Orion herstart gewoon in 1 seconde bij mij, dus dat is veel makkelijker en betrouwbaarder. (overigens ondersteund Orion ook geen hot code swap/replace).

Waarom heb je trouwens een applicatieserver met ejb ondersteuning nodig?

Volgens mij zegt niemand dat ie dat nodig heeft, maar ging het enkel om web applications. Ik neem dan aan dat iedereen dan alleen servlets bedoelt (met op servlet bouwende technology als jsp, jsf, jstl enz).

Voor de web application waar wij bij ons bedrijf aan werken gebruiken we ook geen ejb (enterprise application), maar slechts een web application. Ook wij gebruiken Orion. Uit testen van een tijdje terug bleek dat alleen deze een extreem hoge load kan handlen. Daarbij komt nog dat Orion de snelste JSP compiler heeft. Dat is natuurlijk alleen van belang bij de eerste aanvragen voor een jsp resource, maar toch.

Mischien dat ik me vergis, ik ben ook slechts een simpele HBO afgestudeerde met slechts 1 jaar werkervaring , maar waarom zou het dan mischien kwaad kunnen om een AS met ejb ondersteuning te gebruiken als je geen ejb nodig hebt? Wat zou jij aanraden alarmnummer?

[ Voor 23% gewijzigd door flowerp op 16-10-2004 16:19 ]

[Alarmnummer]

[quote]flowerp schreef op 16 oktober 2004 @ 16:11:
[...]Volgens mij zegt niemand dat ie dat nodig heeft, maar ging het enkel om web applications. Ik neem dan aan dat iedereen dan alleen servlets bedoelt (met op servlet bouwende technology als jsp, jsf, jstl enz).
[/qoute]
Omdat er alleen ejb applicatie servers werden genoemt. Daarom ging ik er vanuit dat ejb de eis was.

Mischien dat ik me vergis, ik ben ook slechts een simpele HBO afgestudeerde met slechts 1 jaar werkervaring , maar waarom zou het dan mischien kwaad kunnen om een AS met ejb ondersteuning te gebruiken als je geen ejb nodig hebt? Wat zou jij aanraden alarmnummer?

Ik heb zelf ook weinig praktische ervaring met webapplicatie servers dus kan ook niet zeggen welke beter is, alleen dat er misschien ook eens gekeken kan worden naar lichtere varianten als je niet alles nodig bent, een lichtere variant zoals jetty bv (alleen servlets/jsp) en anders tomcat.

[flowerp]

Alarmnummer schreef op 16 oktober 2004 @ 17:33:

Ik heb zelf ook weinig praktische ervaring met webapplicatie servers dus kan ook niet zeggen welke beter is, alleen dat er misschien ook eens gekeken kan worden naar lichtere varianten als je niet alles nodig bent, een lichtere variant zoals jetty bv (alleen servlets/jsp) en anders tomcat.

De keuze voor Orion was bij ons voornamelijk wegens de betrouwbaarheid onder hoge load. Hoewel ik nog niet lang in mijn huidige baan zit begreep ik dat we 200 requests per seconde moesten kunnen doen. Er was lang geleden met verschillende AS's getest en alles klapte er altijd meteen uit onder die load. Alleen Orion bleef draaien. Als ik het goed begreep was dat 2 jaar geleden, maar ik kan er naast zitten. Mischien dat tomcat of jetty het nu wel volhouden, maar toen dus zeker niet.

Een goede reden om de SUN AS te gebruiken is dat het de enigste is (zover ik weet) die JSR045 ondersteund. Dat betekent dus JSP's kunnen debuggen. Nu begreep ik dat een debugger door de profs hier als 'evil' wordt gezien, maar vaak is het toch wel handig. Zeker bij ons waar de JSP's vergeven zijn van Java code (dat is opzich natuurlijk niet goed, maar het is nu eenmaal de huidige situatie, in mijn eigen code minimaliseer ik het gebruik van java code in jsp's).

[djengizz]

flowerp schreef op 16 oktober 2004 @ 16:11:
Ook wij gebruiken Orion. Uit testen van een tijdje terug bleek dat alleen deze een extreem hoge load kan handlen.

flowerp schreef op 16 oktober 2004 @ 18:00:
Hoewel ik nog niet lang in mijn huidige baan zit begreep ik dat we 200 requests per seconde moesten kunnen doen. Er was lang geleden met verschillende AS's getest en alles klapte er altijd meteen uit onder die load.

Orion is zeker niet de enige AS die deze hoge load aankan. Het feit dat 'alles eruit klapt' ligt ook vaker aan de settings op de server dan aan de applicatie server. Bijna elke grote J2EE app server kan per applicatie (sterker nog: per container) zaken als geheugen per JVM, aantal threads, connection pooling e.d. instellen. Zaak is wel om een OS en hardware te hebben die dit kan leveren. Ik werk zelf met WebSphere op Unix en wij halen een hogere injectierate dan 200/s op dit systeem.

[flowerp]

djengizz schreef op 16 oktober 2004 @ 18:49:

Zaak is wel om een OS en hardware te hebben die dit kan leveren. Ik werk zelf met WebSphere op Unix en wij halen een hogere injectierate dan 200/s op dit systeem.

Wij werken met linux. Eerst een red hat distributie, nu een debian. De hardware varieert, maar zal destijds iets rond een P3 Xeon zijn geweest. Het punt was dat de hardware het aankon, maar alleen als Orion gebruikt werd.

Ik neem aan dat men de instellingen toch wel nagegaan is, bijv door de -Xmx instellingen waarmee Orion wordt opgestart, maar ook het aantal threads. Dat laatste staat momenteel naar mijn mening redelijk hoog ( tussen de 600 en 700 ). Het lijkt me dat zoiets meer in de buurt moet staan van het aantal requesten wat je kan afhandelen per seconde.

WebSphere is natuurlijk een zeer profesionele oplossing, en daardoor ook wat duurder dan de combinate Eclipse, MyEclipse, Orion.

[Verwijderd]

Even een follow-up op deze oude post, aangezien ik het probleem eindelijk opgelost heb.

De welcome-file werkte niet omdat ik in een servlet of filter, request.getRequestURI() niet de URI terug geeft waar je heen gaat, maar diegene waarmee de user de request deed. Als je welcome file dus index.jsp is, en de user gaat naar www.jouwsite.nl dan geeft getRequestURI dus '/' terug en geen 'index.jsp'. De enige uitzondering hierop (voor de servers die ik testte) is dus Orion.

Omdat wij een authentication filter hadden die op onze welcome file checkte, maar niet op '/' leek het dus fout te gaan, maar als je chain.doFilter laat doorgaan op '/' dan weet de JSP servlet opeens op automagische wijze wel welke file ie moet hebben. Ik vermoed dat er in request nog ergens een hidden field zit waar de echte target URI instaat.

(het zelfde fenomeen heb je overigens met dynamische includes: als die weer aankomen in een filter dan geeft getRequestURI() ook alleen de naam van de originele requested page en niet die van de include)

[Verwijderd]

Krijg nou wat! Het werkt inderdaad.

Dit had wel even duidelijker in de API documentatie mogen staan zeg! Ik vraag me af hoe andere mensen hun authentication dan doen. getRequestURI werkt dus niet, aangezien deze dus nooit de echte URI doorgeeft (of eigenlijk weer wel heel echt, net hoe je het wilt bekijken).

Wat betreft die includes, die worden door de meeste app servers helemaal niet gefilterd. In de J2EE 1.4 style web.xml kun je dat expliciet aangeven of je dat wilt of niet. Tomcat filtert overigens nooit includes als je dat niet aangeeft, ook niet met een oude style web.xml. Ik weet het niet zeker, maar ik dacht dat het vroeger AS afhankelijk was of includes wel of niet gefiltert werden (zowieso zitten filters nog niet zo heel lang in de J2EE spec).