[j2ee] JSPs uit jar file laden?

[Verwijderd]

Momenteel ben ik bezig een webcomponent te bouwen. Het is de bedoeling dat dit component uiteindelijk in een jar file zal staan, waarbij dan alleen wat declaraties in web.xml nodig zijn en een .tld + .jar toegevoegd moet worden aan de aplicatie waarin deze gebruik zal worden.

Nu is een algemeen 'probleem' bij webcomponents dat je HTML output doet vanuit java code. Momenteel in mijn webcomponent zo opgebouwd dat 90% van het hele ding uit Java code bestaat, en alleen het (zeer dunne laagje) dat de HTML genereerd staat in jsp files. Eigenlijk is dit niet meer dan wat simpele html tags en wat loopjes die itereren over data die de java code backend heeft geprepareerd.

Als ik dit echter in een .jar ga packagen, dan wordt het moeilijk om de JSP files te behouden. Natuurlijk kan ik deze ook wel laten deployen door de client (en dan de lokatie in web.xml laten opgeven), maar eigenlijk vind ik dit toch minder mooi.

Het punt is echter dat we hier wat vreemde mannetjes hebben zitten ( ) die een beetje aan interface design doen en een beetje trachten te programmeren. Deze personen willen af en toe de opmaak van een webcomponent radicaal weizigen (op een manier die niet kan met CSS), en daarom willen ze dan in de JSP gaan rommelen; deze kunnen ze namelijk nog net aan begrijpen. Zet ik het echter volledig in een java file dan snappen zei het helemaal niet meer.

Wat zouden de mensen hier doen?

* Een methode zoeken om JSP's vanaf een jar te laden (na wat rondzoeken lijkt me dit onmogelijk, maar mischien dat iemand hier toch weet hoe dit moet)
* JSP rendering files mee laten deployen door component client. Lokatie hierna in web.xml laten zetten.
* HTML output vanaf Java classe doen. Bijvoorbeeld met Apache's Element Construction Kit, of gewoon met println en consorten.

[momania]

Gewoon losse jsp's deployen, net als iedereen dat eigenlijk doet

ik zie niet in waarom je ze in een jar zou willen hebben eigenlijk. Als het alleen maar is om het deployen, zodat je alles bij elkaar hebt, zou ik toch eens gaan kijken naar een war

[Janoz]

Als het je enkel is om bepaalde elementen buiten te sluiten kun je misschien beter alles in een war stoppen een een buildscript gebruiken. Aanpassingen in de web.xml komen dan gewoon in een properties bestand terecht, en mbv ant wordt dan alles bij elkaar geveegd. Binnen het buildscript pak je je jsp's uit en jar en construeerd de war.

Maar aigenlijk zie ik het probleemn niet zo. Zolang je al je buisness logic in je java bestanden hebt staan en de jsp's alleen de view dingen doen (Sowieso jsp's niet rechtstreeks toegankelijk maken zodat ze alleen via de acties bereikt kunnen worden) kun je interface design beter aan de interface design professionals overlaten. Sowieso kun je meer bereiken door met elkaar te werken ipv tegen elkaar. Dat eerste is namelijk veel productiever. De interface designers kunnen dan nog eens wat opsteken van fatsoenlijk programmeren (In views hoeft dat eigenlijk nooit verder te gaan dan enkele itteratoren en conditie statements. Maak eventueel gebruik van een taglib en maak scriplets verboden) en de programmeurs kunnen zeker ook wat opsteken over het gebruikers vriendelijk maken van hun interfaces/applicaties.

[Verwijderd]

momania schreef op maandag 15 augustus 2005 @ 14:08:
Gewoon losse jsp's deployen, net als iedereen dat eigenlijk doet

Is dat zo? Als ik nu kijk naar bijvoorbeeld webcomponents van JSF of Struts dan zie ik eigenlijk nooit dat ze JSP pages mee deployen.

Vergeet niet dat het hier niet om een hele pagina gaat Het gaat om losse componenten (zeg maar widgets zoals je ook in SWING hebt, maar dan voor het web. Een web component/widget kan bijvoorbeeld een losse calender zijn, of een universele tabel, of een universeel menu, of een tree, etc etc...

ik zie niet in waarom je ze in een jar zou willen hebben eigenlijk. Als het alleen maar is om het deployen, zodat je alles bij elkaar hebt, zou ik toch eens gaan kijken naar een war

Nou, een .war is alleen bedoeld voor een gehele applicatie! Je kunt een losse widget (waarmee je dus de interface van applicaties opbouwt) natuurlijk niet als een war gaan deployen. Wat zou dat voor resultaat geven?

Stel voor dat ik een advanced button widget heb, en die deploy ik als een war. Dan krijgt de gebruiker bij het navigeren naar de context root hiervan (bv www.example.org/mybutton) alleen een knop te zien?

Je kunt niet war files toevoegen aan andere war files.

Kijk je naar de taglibs als bijvoorbeeld de RI JSTL of Jakarta Taglibs, dan komen deze ook niet als een war, maar als een jar met een .tld file.

[Standeman]

Als je wilt dat er niet idereen er "zomaar" bijkan, kan je ook nog je JSP files precompilen.. (Wat normaal gebeurt door bijv. Tomcat.. ) en ze in de /tomcat/works/bla dir zetten...

Maar goed... een hoop werk.. Ze moeten gewoon met hun tengels er van af blijven.. (kan je de rechten op de specifieke dir niet aanpassen?)

[momania]

Verwijderd schreef op maandag 15 augustus 2005 @ 14:27:
[...]
Vergeet niet dat het hier niet om een hele pagina gaat Het gaat om losse componenten (zeg maar widgets zoals je ook in SWING hebt, maar dan voor het web. Een web component/widget kan bijvoorbeeld een losse calender zijn, of een universele tabel, of een universeel menu, of een tree, etc etc...

Ah, ok... nu snap ik waar je naar toe wilt

Maar is een widget in dit geval niet gewoon een extra lib'je dat je steeds wilt toevoegen aan je bestaande applicatie

Lijkt mij toch dat je je webapp even moet herstarten hiervoor, en als je voor het geheel een knap build script hebt staan waarmee je een war maakt die je kan deployen, is het echt niet veel werk om een nieuwe widget in je build erbij te proppen en die even te draaien en te deployen.

[Verwijderd]

Standeman schreef op maandag 15 augustus 2005 @ 14:33:
Als je wilt dat er niet idereen er "zomaar" bijkan, kan je ook nog je JSP files precompilen.. (Wat normaal gebeurt door bijv. Tomcat.. ) en ze in de /tomcat/works/bla dir zetten...

Nou, het punt is dat pre-compilen van JSP files altijd application server specificieke code oplevert. Wat ik aan het maken ben is 'gewoon' een web component (zoals een speciale knop/tabel/tree, etc) die natuurlijk als een library in elke andere project onder elke andere j2ee application server gebruikt moet kunnen worden.

Maar goed... een hoop werk.. Ze moeten gewoon met hun tengels er van af blijven.. (kan je de rechten op de specifieke dir niet aanpassen?)

*lach* Het gaat me niet zo zeer erom dat ik vind dat ze er niet aan mogen zitten (liever niet, maar ze willen het nu eenmaal), maar dus meer om het feit dat ALS ik het implementeer zoals alle andere componenten het doen, dat ze er DAN niet meer makkelijk bij kunnen.

En nogmaals, jongens het gaat NIET om een gewone web applicatie! Ik ben bezig met het maken van web components die je als library gebruikt in web applicaties.

Voor degene die Swing kennen, het is dus net alsof ik een JPanel, JToolbar, JComboBox, JFileChooser etc etc etc maak. Dit zijn ---geen--- aparte applicatues (een JPanel zelf is GEEN executable), maar het zijn componenten die je gebruikt IN een applicatie. Ik snap dat dit in J2EE niet erg gebruikelijk is, en het dus een beetje vreemd overkomt, dus laat ik een voorbeeldje geven:

Java Server Page:

<%@ taglib          uri="/WEB-INF/tld/jstl/c.tld" prefix="c" %>
<%@ taglib          uri="/WEB-INF/tld/leekecomp/leeko.tld" prefix="leeko" %>

<table>
   <tr>
    <td>
      <leeko:lmenu class="menu1" >
         <leeko:lheading class="heading1" >
             <leeko:item>
               <a href="test.html>test</a>
             </leeko:item>
         </leeko:lheading>
      </leeko:lmenu>
    </td>
   </tr>
</table>

Op deze gebruik ik dus een taglib die een web-component op een willekeurige pagina zet. Dit web-component stelt een menu voor. Een designer gebruikt gewoon de taglib en de css om tot een ontwerp te komen. Alleen de personen die een beetje half designer / half wannabe programmeur zijn, willen ook de binnenkant van het webcompent aanpassen. Simpel voorbeeld, ze willen opeens dat er achter elke menu item een > komt te staan.

Wat je kunt doen in J2EE is JSP pages (eigenlijk fragments) dynamisch in java code inladen en daarna het resultaat outputten. Die JSP pages zet je dan gewoon in een directory en je taglib handler weet het path daarna.

Zolang je je web componenten nog ontwikkeld in het zelfde project als waarin ze gebruik worden leverd dit weinig problemen op. Op een gegeven moment zijn de web componenten (widgets) zo algemeen, dat je ze wilt gebruiken in meerdere projecten. Je packaged ze dus in een JAR die je kunt toevoegen aan een war of exploded web applicatie. Maar goed, dan zit je dus met de JSP renderers.

Nogmaals:

Het gaat hier NIET om web applicaties die JSP pages gebruiken, maar om losse afzonderlijke componentjes die je wilt gebruiken in web applicaties. Je kunt deze dus -niet- in een .war file stoppen.

[momania]

Nu snap ik waar je naar toe wilt

Je wilt dan idd geen losse jsp's hebben, maar de componenten zelf output laten leveren. Maar output zelf laten doen, net als de Struts elementen is idd niet erg handig te onderhouden.

Eigenlijk zou je hier een aparte file voor moeten hebben met een soort van template van je output (je kale html dus), waar je je component de rest van laat invullen en die het geheel laat outputten. (ofzo )

Zo'n template kan je makkelijk in je jar kwijt en is dan toch niet verweven met je code... Verzin idd alleen maar eens een knappe manier om dit met een template op te lossen...

[Verwijderd]

momania schreef op maandag 15 augustus 2005 @ 15:11:
Zo'n template kan je makkelijk in je jar kwijt en is dan toch niet verweven met je code... Verzin idd alleen maar eens een knappe manier om dit met een template op te lossen...

Klopt ja. In feite is een JSP natuurlijk al een template, maar ja die kun je niet van een jar laden. Mischien dat ik toch maar gewoon HTML vanuit java moet genereren dan, hoewel de HTML dan dus wel een beetje moeilijk aan te passen is. Maar goed, dat hebben dus alle web componenten.

[momania]

Verwijderd schreef op maandag 15 augustus 2005 @ 17:00:
[...]
Mischien dat ik toch maar gewoon HTML vanuit java moet genereren dan, hoewel de HTML dan dus wel een beetje moeilijk aan te passen is. Maar goed, dat hebben dus alle web componenten.

Dat wil natuurlijk niet zeggen dat jij dat ook zo hoeft te doen.

Kan je niet een bepaalde xml structuur verzinnen waar je stukken html in kwijt kan die de dan dynamisch in je java code kan ophalen en dat gebruiken Of een ander soort input, hoeft niet direct een moeilijke xml te zijn, maar kan ook een simpele property file zijn natuurlijk.

Voor een simpel list voorbeeld iets van:

code:

list.start=<ul id='{0}'>
list.end=</ul>
element.start=<li id='{0}'>
element value={0}
element.end=</li>

Met knap commentaar erbij welke keys er gebruikt kunnen worden en wat het doel is, kan dan iedereen het makkelijk aanpassen als dat nog nodig is.

Zo heb je iig niet direct alle html in je java code zitten.

[-FoX-]

Ik weet niet ofdat dit een mooie oplossing is, maar wat je eventueel zou kunnen doen om jouw resultaat te bereiken is in je tld in de META-INF folder van je jar, een ServletContextListener registreren die de betreffende JSP's gaat extracten naar een temp-directory binnen de webapp waarin deze gebruikt wordt. Het enige waar de gebruiker op moet letten is dat zijn web-app directory schrijfbaar is door deze ServletContextListener...

Dit lijkt me wel te werken, de gebruiker hoeft de listener niet te registreren omdat jij deze zelf al opneemt in je tld, die automatisch door de appserver gescanned en uitgevoerd wordt.
Alleen weet ik niet of dit nu wel zo'n mooie oplossing is

[misfire]

Als je JSP 2.0 (J2EE 1.4) mag gebruiken dan zijn wellicht Tag Files een oplossing voor jouw probleem. Tag files zijn een soort JSP snippets die je als een tag in een gewone JSP pagina kunt aanroepen. Je moet dan wel JSP pagina's hebben gedefinieerd in je web applicatie die van deze tags gebruik maken, maar als ik jouw voorbeeld zie wil je dat ook. Tag files mag je packagen in een jar, volgens een gedefinieerd formaat (zie bovenstaande link). De oplossing zal ook voldoen aan de J2EE standaard (itt de andere gruwelijke oplossingen die hier genoemd worden ).

[djengizz]

Als je je webcomponenten nu eens allemaal xml laat genereren naar bijv. een DOM Document. XML vervolgens transformeren met een XSLT stylesheet naar HTML en CSS.
Willen je vreemde mannetjes 'designen' dan gooien ze er een nieuwe XSLT stylesheet tussen.

[Verwijderd]

Geweldige topic! Ik loop zelf tegen een vergelijkbaar probleem aan. Ons idee is om een CMS te bouwen, waarbij steeds nieuwe modules als jar ingeplaatst kunnen worden. Mbv Spring weten we alles mooi aan elkaar te koppelen. Echter is de wens om ook de jsp (of tag-files) bij de jar te houden, en niet apart uit te pakken in de WEB-INF. ik kan dus in de JSP geen pagina aanmaken, waarbij ik van tevoren al weet welke tagfiles gebruikt kunnen worden.

Trouwens de reden, waarom ik in eerste instantie op deze pagina kwam, was omdat ik het niet voor elkaar kreeg om 1 of meerdere TLD's uit een jar te benaderen. Op http://www.onjava.com/pub...001/10/10/jsp.html?page=2 vond ik eindelijk de oplossing helder omschreven. Wordt de file dan nog niet ingeladen, kijk dan eens, of je TLD wel correct is. Dit zie je namelijk niet in de foutmeldingen terug, het bestand wordt simpelweg genegeerd.