Archief - Tomcat: iemand ervaring?

Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.
F

Forum

Legacy Member
Hallo,

Ik zou een stukje software willen testen. Blijkbaar moet je dit op een Java Tomcat server draaien. De software bestaat uit een map met 3 mappen "build", "src" en "WebContent". Met in build en src respectievelijk class files en java bron files. In WebContent zitten een aantal jsp files en "WEB-INF" en "jar" map en nog andere files.

Ik heb op ubuntu al een tomcat6 server geïnstalleerd. Ik kan naar http://localhost:8080/ surfen. Enig idee hoe ik de software draaiende krijg? Ik heb op internet al info gezocht, maar raak er niet wijs uit.

Alvast bedankt!
S

Sonaryr

Legacy Member
In uw tomcat installatie staat normaal een "webapps" map.
daar maakt ge een map in aan voor uw applicatie bv : "MijnApplicatie".
In deze map moeten uw files staan, kijk ook eens in de andere die daar al staan.
je kan er dan naar surfen door naar http://localhost:8080/MijnApplicatie te gaan.
Als je het echt simpel wil oplossen download netbeans en installeer in het begin tomcat mee en maak dan een nieuw project met een tomcat server, als je dan runt start deze automatisch de server en opent jouw browser naar de juiste link.
F

Forum

Legacy Member
Hartelijke bedankt! het werkt :)

Ik moest blijkbaar eerst de inhoud wel in een war file steken. Met een omslachtige manier (eerste exporteren naar een jar en dan rename naar war-file) Als ik de war file in webapps plakte werd die automatisch uitgepakt... Als ik dan naar de url surf werkt de toepassing
D

Dieterg

Legacy Member
(edit: juist te laat :))

Open terminal:

typ het volgende:
Code: 
sudo nano /etc/tomcat6/tomcat-users.xml

past in volgende code (beneden ofzo..):
Code: 
<role rolename="admin"/>
<role rolename="manager"/>
<user username="admin" password="pw" roles="admin, manager"/>

ga naar volgende link:
Code: 
http://localhost:8080/manager/html

login met 'admin' en als pw 'pw'.

Het enige wat je hier moet doen is uw WAR file in droppen. In netbeans kan je dit simpel doen door naar RUN -> CLEAN EN BUILD PROJECT te gaan..

Nu krijg je in uw folder normaal een 'dist' map waarin uw warfile staat..!

Succes :-)
m

metalleke

Legacy Member
Forum zei:
Hartelijke bedankt! het werkt :)

Ik moest blijkbaar eerst de inhoud wel in een war file steken. Met een omslachtige manier (eerste exporteren naar een jar en dan rename naar war-file) Als ik de war file in webapps plakte werd die automatisch uitgepakt... Als ik dan naar de url surf werkt de toepassing
Klik om te vergroten...

Normaal kun je ook gewoon packen naar een WAR hoor.
W

Wolf2000me

Legacy Member
Forum zei:
Hartelijke bedankt! het werkt :)

Ik moest blijkbaar eerst de inhoud wel in een war file steken. Met een omslachtige manier (eerste exporteren naar een jar en dan rename naar war-file) Als ik de war file in webapps plakte werd die automatisch uitgepakt... Als ik dan naar de url surf werkt de toepassing
Klik om te vergroten...

De meeste IDE's laten toe om te exporteren naar een WAR zoals hierboven gezegd. In principe is een WAR op dezelfde manier packed als een JAR, vandaar dat het werkt, maar ik zou het toch niet aanraden.

Bovendien vind ik packen via je IDE ook niet optimaal. In professionele omgevingen wordt dit via Apache Ant of Apache Maven gedaan. Ik zou de laatste aanraden, al is dit schijnbaar ingewikkeld. Als voordeel doe je wel kennis van deze tool op en die kan je beslist in andere java projecten gebruiken. Mogelijk is je project nu voor 't school? Als dit zo is en je methodologie is belangrijk dan zal dit zeker punten waard zijn. Indien je meer info wenst ben ik zeker bereid daar 't één en ander over uit te leggen.
m

metalleke

Legacy Member
Wolf2000me zei:
De meeste IDE's laten toe om te exporteren naar een WAR zoals hierboven gezegd. In principe is een WAR op dezelfde manier packed als een JAR, vandaar dat het werkt, maar ik zou het toch niet aanraden.

Bovendien vind ik packen via je IDE ook niet optimaal. In professionele omgevingen wordt dit via Apache Ant of Apache Maven gedaan. Ik zou de laatste aanraden, al is dit schijnbaar ingewikkeld. Als voordeel doe je wel kennis van deze tool op en die kan je beslist in andere java projecten gebruiken. Mogelijk is je project nu voor 't school? Als dit zo is en je methodologie is belangrijk dan zal dit zeker punten waard zijn. Indien je meer info wenst ben ik zeker bereid daar 't één en ander over uit te leggen.
Klik om te vergroten...

Op t werk gebruiken wij constant ant eigenlijk, maar op een of andere manier doet eclipse regelmatig lastig. Kan ant files niet inladen enzo. Ergens wat (interessante) lectuur ant vs maven?
W

Wolf2000me

Legacy Member
metalleke zei:
Op t werk gebruiken wij constant ant eigenlijk, maar op een of andere manier doet eclipse regelmatig lastig. Kan ant files niet inladen enzo. Ergens wat (interessante) lectuur ant vs maven?
Klik om te vergroten...

Dat Eclipse lastig doet op Ant heeft eigenlijk redelijk weinig met Ant te maken. Eclipse doet lastig op zowat alles imho, op Maven dus ook. Een van de hoofdredenen hiervoor komt doordat er zoveel Eclipse versies zijn en dat alle framework support door 3rd party plugins verzorgd wordt. Daardoor zijn de versies, en vodden met bepaalde versies, zo enorm verspreid dat men op den duur het bos door de bomen niet meer ziet. Sinds ik werk met IntelliJ Idea heb ik dit niet meer. Van IntelliJ Idea is een gratis community edition beschikbaar die reeds een enorme waaier aan supported features biedt. Oa. Maven, Ant, Android en Spring native support en awareness.

Maar dat terzijde :)

Over Maven vs. Ant zijn hopen artikels te vinden, google yourself out zou ik zeggen :)

Wat ik zelf vind:

Maven heeft een aantal voordelen die Ant niet heeft zoals:

  • platform onafhankelijk: Maven kan net zoals Ant werken op alle gangbare besturingssystemen. Alleen vind ik dat de centralisatie en decentralisatie van configuratie in de build met online dependency management (jars, plugins,... en diens versies) de platform onafhankelijkheid veel beter in de hand werkt.
  • Maven-antrun-plugin: Maven heeft een Ant Run plugin die gebruikers toelaat van Ant scripts in een Maven build uit te voeren. Soms is het gemakkelijker van een simpel Ant script te schrijven dan een nieuwe specifieke Maven plugin te configureren. Omdat dit kan zou ik nooit meer voor Ant alleen kiezen aangezien het dus als aanvulling op Maven perfect z'n ding doet.
  • Online plugin en dependency management: Zoals gezegd kan je je jars, plugins enz gecentraliseerd in je project beheren. Je kan bv. ook een parent maken waar je een aantal veelgebruikte jars en plugins met hun versies in "klaar zet". Dit zorgt ervoor dat een project dat die parent gebruikt dezelfde jars en plugins gaat gebruiken. Uiteraard is overriding mogelijk.
  • Standaardisatie: Maven biedt zelf een bepaalde standaard aan voor je project. Bv. de plaats waar je je resources op je classpath bewaart, waar je je eindproduct genereert, enz. Zonder configuratie wordt je wel verplicht deze default standaard te volgen, maar daar is voor de meeste projecten eigenlijk een goeie zaak.
  • 3rd party support: Maven projecten worden doorgaans door tal van 3rd party tools gesupporteerd. Zo heb je bv. build servers zoals Hudson, Bamboo of Teamcity. Deze gaan bv. dagelijks je project builden en de testen draaien om vervolgens een hoop statistische info over je project weer te geven. Het zorgt maw. voor een hogere kwaliteit van je code. Dit is maar een voordeel om er één van te noemen.
  • Automatisatie: De beste builds gaan automatisch de elementaire stappen van je software doorlopen om dmv. één command tot je eindproduct te komen. Je verzamelt je jars en resources, je compileert je classes, je draait je testen (optioneel), je bundelt ze in de package (jar, war, ear, apk, ...), je brengt deze beschikbaar in je online repository (optioneel) en deployt naar je server(s) (optioneel). Dat allemaal met versie en release beheer en management.
    Ant heeft ook een zekere vorm van automatisatie, maar met Maven kan je al deze stappen op dezelfde manier op éénder welke machine draaien, zoals zo'n build server bv.

Uiteraard zijn er ook nadelen.

  • Dependency mess: Wanneer je niet voorzichtig bent met het overriden en toekennen van dependencies kan je makkelijk aan verschillende versies van dezelfde jar geraken. Java gaat classes op first find basis gebruiken dus dit kan wel voor een waaier aan fratsen zorgen.
    Wanneer je projecten hebt met veel modules met jars, wars en ears heb je toch wel een uitgekiende strategie van versiebeheer nodig om niet met een hoop redundante (dubbel bestaande) jars te zitten in je eindproducten.
  • overconfiguratie: Er is veel config nodig, waarvan een deel eigenlijk slechts 1x hoeft, maar toch ben je er even mee bezig om het op te zetten. Verder kan je als gebruiker ook gemakkelijk veel te ver gaan in het definiëren van profielen en plugins.
  • ...
    Er zijn er nog, niks is perfect, maar imho is dit tot nu toe by far de beste build tool.
m

metalleke

Legacy Member
Wolf2000me zei:
Dat Eclipse lastig doet op Ant heeft eigenlijk redelijk weinig met Ant te maken. Eclipse doet lastig op zowat alles imho, op Maven dus ook. Een van de hoofdredenen hiervoor komt doordat er zoveel Eclipse versies zijn en dat alle framework support door 3rd party plugins verzorgd wordt. Daardoor zijn de versies, en vodden met bepaalde versies, zo enorm verspreid dat men op den duur het bos door de bomen niet meer ziet. Sinds ik werk met IntelliJ Idea heb ik dit niet meer. Van IntelliJ Idea is een gratis community edition beschikbaar die reeds een enorme waaier aan supported features biedt. Oa. Maven, Ant, Android en Spring native support en awareness.

Maar dat terzijde :)

Over Maven vs. Ant zijn hopen artikels te vinden, google yourself out zou ik zeggen :)
Klik om te vergroten...

Mja onze ontwikkelomgeving is volledig vastgelegd, welke plugins, welke versies, ... T is niet zo dat er maar willekeurige dingen gebruikt worden. Er is ooit voor eclipse gekozen, en dat zal niet (zomaar) veranderen. Voor en nadelen van in een gro(o)t(er) bedrijf te werken zeker.

Heb ik al gedaan ofc, maar was es benieuwd. ;)
Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.
Terug
Bovenaan