[Java/JSP/Struts] Wat (welke libs) moet waar komen te staan?

[Verwijderd]

Beste lieden,

Sinds kort ben ik weer aan de slag gegaan met het Struts framework. Het framework is inmiddels erg gegroeid in vergelijking met toen ik het een jaar of 4 geleden eens een aantal keer heb gebruikt. Toen was het nog erg beperkt en overzichtelijk, maar nu zie ik door de bomen het bos niet meer.

Ik gebruik NetBeans als de IDE (met geintegreerde TomCat) om de applicatie in te ontwikkelen en heb het inmiddels zover, dat ik de blanke Struts template (struts-blank) heb weten te integreren binnen een blanke NetBeans webapplicatie project. Echter, wat ik nu niet begrijp is het volgende. Ik heb de Struts libs in de common libs directory van TomCat geplaatst, maar in de documentatie van Struts staat dat je ook een aantal classes specifiek bij je webapplicatie zelf onder moet brengen. Echter, wanneer ik dat niet doe, werkt het ook prima. Op zich logisch, want de webapplicatie specifieke classes komen ook allemaal voor in de algemene verzameling Struts classes.

Mijn vraag is nu: wie weet waarom dit zo is en waarom ik dus toch ook die specifieke classes moet plaatsen binnen mijn webapplicatie omgeving, terwijl ze ook zijn geplaatst in de common lib?

[den 150]

Moesten we nu weten welke classes dat zijn (link naar relevante docs zijn welkom) dan zouden we wat meer kunnen zeggen.
Educated guess: als Struts property files wil lezen (bvb je i18n messages) zal dat gebeuren met classloader.getResource() . Dan wordt er gezocht in common/lib naar die files, terwijl die in WEB-INF/classes zitten.

Als je dan toch persé libs wil sharen doe dat dan in shared/lib ipv common/lib, dan heb je wat minder kans om iets aan tomcat zelf kapot te doen.

[Cuball]

je struts lib horen in je lib folder van je applicatie en niet in de common lib van je applicatie server...

[flowerp]

Verwijderd schreef op vrijdag 02 februari 2007 @ 20:38:
Sinds kort ben ik weer aan de slag gegaan met het Struts framework. Het framework is inmiddels erg gegroeid in vergelijking met toen ik het een jaar of 4 geleden eens een aantal keer heb gebruikt.

Dat vind ik eigenlijk wel mee vallen. Struts is eigenlijk een soort abandonware, het heeft juist heel lang stil gestaan omdat met alle tijd heeft gestopt in de opvolger ervan (JSF). Deze opvolger is dan ook sinds afgelopen jaar standaard opgenomen in Java. Aan Struts zelf werd geen tijd meer besteed, volgens dezelfde logica als dat je nu geen features meer toevoegd aan Java 1 of Java 1.1, etc.

Er is overigens wel een soort resurectie gedaan. Een groep enthousiastelingen is toch met de oude code base verder gegaan, en heeft daadwerkelijk een Struts-2 uitgebracht. Of het verstandig is om hier voor nieuwe projecten mee te beginnen is nog maar zeer de vraag. Het is eigenlijk voornamelijk bedoeld voor mensen die al een hele boel Struts code hebben en daar direct op door willen bouwen. De 'echte' Struts 2 (JSF dus), biedt ook al diverse integratie mogelijkheden om je oude Struts code te kunnen blijven gebruiken.

[Verwijderd]

flowerp schreef op zaterdag 03 februari 2007 @ 15:52:
[...]


Dat vind ik eigenlijk wel mee vallen. Struts is eigenlijk een soort abandonware, het heeft juist heel lang stil gestaan omdat met alle tijd heeft gestopt in de opvolger ervan (JSF). Deze opvolger is dan ook sinds afgelopen jaar standaard opgenomen in Java. Aan Struts zelf werd geen tijd meer besteed, volgens dezelfde logica als dat je nu geen features meer toevoegd aan Java 1 of Java 1.1, etc.

Er is overigens wel een soort resurectie gedaan. Een groep enthousiastelingen is toch met de oude code base verder gegaan, en heeft daadwerkelijk een Struts-2 uitgebracht. Of het verstandig is om hier voor nieuwe projecten mee te beginnen is nog maar zeer de vraag. Het is eigenlijk voornamelijk bedoeld voor mensen die al een hele boel Struts code hebben en daar direct op door willen bouwen. De 'echte' Struts 2 (JSF dus), biedt ook al diverse integratie mogelijkheden om je oude Struts code te kunnen blijven gebruiken.

Hmmm, dus eigenlijk is het, volgens jou, aan te raden om de draad (met Java webapplication development) met JSF en niet meer met Struts?

[flowerp]

Verwijderd schreef op zaterdag 03 februari 2007 @ 16:02:
[...]

Hmmm, dus eigenlijk is het, volgens jou, aan te raden om de draad (met Java webapplication development) met JSF en niet meer met Struts?

Als je niet tenminste 10.000 regels bestaande Struts code hebt liggen, of niet van plan bent om bij een werkgever te gaan werken die dit heeft, dan zou ik inderdaad gewoon met JSF beginnen.

JSF zit tegenwoordig standaard in Java EE (versie 5). Op het moment zijn er nog wel weinig implementaties van Java EE 5. Sun heeft zijn versie natuurlijk al een jaar lang op de markt, maar Jboss komt bijvoorbeeld pas dit jaar met een versie.

In beginsel maakt elk bedrijf gewoon gebruik van de dingen die standaard in Java zitten (tenzij het echt slecht is zoals EJB2). De kans is dus heel groot dat zodra men gaat upgraden naar Java EE 5, JSF kennis nog meer gewild zal worden dan het nu al is.

[Verwijderd]

den 150 schreef op vrijdag 02 februari 2007 @ 21:42:
Moesten we nu weten welke classes dat zijn (link naar relevante docs zijn welkom) dan zouden we wat meer kunnen zeggen.
Educated guess: als Struts property files wil lezen (bvb je i18n messages) zal dat gebeuren met classloader.getResource() . Dan wordt er gezocht in common/lib naar die files, terwijl die in WEB-INF/classes zitten.

Als je dan toch persé libs wil sharen doe dat dan in shared/lib ipv common/lib, dan heb je wat minder kans om iets aan tomcat zelf kapot te doen.

Laat ik het anders zo proberen uit te leggen:
Ik gebruik NetBeans 5.5 met daarbij de geintegreerde TomCat applicatieserver. Ik wil daarbij nu dus een webapplicatie schrijven met Struts 1.3.5, maar wel binnen de NetBeans 5.5 omgeving. NetBeans 5.5 ondersteunt standaard alleen een oudere versie van Struts. Nu heb ik het voor elkaar dat ik probleemloos in NetBeans 5.5 mijn Struts webapp kan ontwikkelen (door handmatig een in NetBeans aangemaakte kale webapp uit te breiden met relevante Struts bestanden), maar ik ben er nu wat onzeker over, of ik de zaak goed heb opgezet. Heb ik bijvoorbeeld de juiste bestanden op de juiste locaties geplaatst enzovoort. Kortom: het werkt, maar zit het ook zo in elkaar, zoals bedoeld?

[ Voor 4% gewijzigd door Verwijderd op 03-02-2007 16:22 ]

[Verwijderd]

flowerp schreef op zaterdag 03 februari 2007 @ 16:18:
[...]


Als je niet tenminste 10.000 regels bestaande Struts code hebt liggen, of niet van plan bent om bij een werkgever te gaan werken die dit heeft, dan zou ik inderdaad gewoon met JSF beginnen.

JSF zit tegenwoordig standaard in Java EE (versie 5). Op het moment zijn er nog wel weinig implementaties van Java EE 5. Sun heeft zijn versie natuurlijk al een jaar lang op de markt, maar Jboss komt bijvoorbeeld pas dit jaar met een versie.

In beginsel maakt elk bedrijf gewoon gebruik van de dingen die standaard in Java zitten (tenzij het echt slecht is zoals EJB2). De kans is dus heel groot dat zodra men gaat upgraden naar Java EE 5, JSF kennis nog meer gewild zal worden dan het nu al is.

Maar in de JSF FAQ (http://wiki.java.net/bin/...ts/JavaServerFacesSpecFaq) wordt JSF expliciet onderscheiden van Struts. Daarin wordt aangegeven dat waar Struts een framework voor een MVC implementatie is, JSF zich voornamelijk richt op de presentatielaag.

[flowerp]

Verwijderd schreef op zaterdag 03 februari 2007 @ 16:21:
[...]
Maar in de JSF FAQ (http://wiki.java.net/bin/...ts/JavaServerFacesSpecFaq) wordt JSF expliciet onderscheiden van Struts. Daarin wordt aangegeven dat waar Struts een framework voor een MVC implementatie is, JSF zich voornamelijk richt op de presentatielaag.

Java EE 5 in z'n geheel past het MVC model toe. Hoewel je JSF ook los kunt downloaden (en dan bijvoorbeeld met Tomcat kunt gebruiken) is JSF gewoon een onderdeel van Java zelf dat zich inderdaad voornamelijk op de presentatie laag richt, maar dan wel heel nadrukkelijk de presentatie laag in een MVC omgeving. Daarnaast bevat JSF wel zeker ook controller aspecten dmv de navigation rules.

Hier heb je een link van de maker van Struts zelf (Craig McClanahan) uit 2002(!) waarin wordt uitgelegd dat JSF het oude Struts zal opvolgen:

http://struts.apache.org/proposals/struts-faces.html

Relevante quote:

For applications with a longer lead time, seriously consider waiting for the ability to use JSF components instead of the Struts HTML tag library. Doing this will let you leverage not only the standard HTML components that come with JSF out of the box, but also the rich libraries of JSF components likely to be created by third parties in the future (including Struts developers).

Zeker als je Netbeans gebruikt lijkt me weinig twijfel mogelijk wat je het beste kunt gebruiken. Netbeans of all IDEs heeft juist de beste support voor JSF, beter dan wat Eclipse momenteel bied. Dit komt omdat SUN natuurlijk in eerste instantie de standaard Java APIs wil supporten, en pas in 2de instantie alternatieve of legacy technieken.

[Verwijderd]

Ik heb inmiddels wat meer gelezen over JSF en het lijkt mij zeer interessant. Ik ben van plan hier een project mee te doen. Maar wat ik nog niet echt heb kunnen vinden (maar wat wel voor de hand ligt, denk ik), is waar de business logic moet worden geplaatst. JSF maakt gebruik van zogenaamde managed beans zoals ik heb begrepen en een managed bean is eigenlijk een combinatie van een form bean en een action object in Struts. In een JSF managed bean bevinden zich zowel de properties als de 'actie logic'. Mijn vraag is nu: is het net zoals bij Struts 'good practice' om de eigenlijke business logic weer onder te brengen in eigen objecten welke door de managed beans worden aangesproken?

Een mogelijke opstelling van lagen zou dan kunnen zijn:
(JSF)
1. JSP
2. Managed beans
(/JSF)
3. Business logic objecten
4. Data Access Objects (DAO)
5. Datasource (RDBMS)

[Verwijderd]

Laat maar, ik heb het al gevonden . Het geniet inderdaad de voorkeur om de eigenlijke business logic als een aparte laag te ontwikkelen tussen de JSF managed beans en de data access layer. Wat is het toch heerlijk, dat Java!

[flowerp]

Verwijderd schreef op zondag 04 februari 2007 @ 11:14:
Laat maar, ik heb het al gevonden . Het geniet inderdaad de voorkeur om de eigenlijke business logic als een aparte laag te ontwikkelen tussen de JSF managed beans en de data access layer. Wat is het toch heerlijk, dat Java!

Dat kan heel goed ja. Managed beans zijn gewoon POJO's (Plain Old Java Objects, d.w.z. gewone simpele classes), die je opgeeft in faces-config.xml.

D.m.v. EL uitdrukkingen koppel (bind) je deze managed beans aan je userinterface componenten. Zo'n koppeling kan bi-directioneel zijn. Bij een input component haalt JSF initieel een waarde op via die verbinding, en als de user dan een waarde opgeeft gaat het via dezelfde verbinding weer naar de bean.

Eenmaal in de bean heb je de keuze. Als je wilt -kun- je de business logic direct in de bean afhandelen. Voor hele kleine simpele apps wordt dat wel eens gedaan. Je kunt echter ook meteen delegeren naar andere objecten die de eigenlijke business logic implementeren.

Een groot voordeel van JSF is dat je werkelijk alles van het standaard gedrag wel kunt afvangen en veranderen. Er zitten heel veel plekken in waar je via plug-ins eigen code aan de zogenaamde JSF lifecycle kunt toevoegen. Als je pas begint zul je die mogelijkheid voorlopig niet nodig hebben, maar het is mischien altijd goed om te weten dat er later meer kan

[Verwijderd]

flowerp schreef op zondag 04 februari 2007 @ 12:09:
[...]


Dat kan heel goed ja. Managed beans zijn gewoon POJO's (Plain Old Java Objects, d.w.z. gewone simpele classes), die je opgeeft in faces-config.xml.

D.m.v. EL uitdrukkingen koppel (bind) je deze managed beans aan je userinterface componenten. Zo'n koppeling kan bi-directioneel zijn. Bij een input component haalt JSF initieel een waarde op via die verbinding, en als de user dan een waarde opgeeft gaat het via dezelfde verbinding weer naar de bean.

Eenmaal in de bean heb je de keuze. Als je wilt -kun- je de business logic direct in de bean afhandelen. Voor hele kleine simpele apps wordt dat wel eens gedaan. Je kunt echter ook meteen delegeren naar andere objecten die de eigenlijke business logic implementeren.

Een groot voordeel van JSF is dat je werkelijk alles van het standaard gedrag wel kunt afvangen en veranderen. Er zitten heel veel plekken in waar je via plug-ins eigen code aan de zogenaamde JSF lifecycle kunt toevoegen. Als je pas begint zul je die mogelijkheid voorlopig niet nodig hebben, maar het is mischien altijd goed om te weten dat er later meer kan

Ik ben tot dusver heel enthousiast. Sowieso is de Servlet technologie erg gaaf. Zeker in vergelijking met PHP (wat ik voorheen gebruikte). Ik heb zojuist een filter geschreven voor de authenticatie van een ingelogde user. Hoe super is dat ? In PHP moet je daarvoor op iedere relevante pagina verwijzen naar een check, maar nu kan ik volstaan met zo'n filter!

De JSF controller servlet 'mapt' nu op basis van het virtuele URL pad 'faces' en het authenticatiefilter 'mapt' op basis van het virtuele URL pad 'faces/secure'.

Erg mooi!