Mail fra JSP sider !

Umiddelbart skal der ikke sættes noget op på din Linux box, forudsat du bruger din udbyders SMTP server til at sende via.

Hvis du vil anvende din egen mail server, skal den sættes op og konfigureres.

Prøv at post den kode som sende mailen.

Det er ikke nødvednigt at køre noget specielt for st lave en udgående
TCP/IP connection til port 25 på en SMTP server.

Så de første spørgsmål er:
  - får du nogle exceptions i din log-fil ?
  - er der åbent for connection fra din Debian maskine med
    JSP/servlet container til port 25 på den maskine
    hvor SMTP server kører ?

Disky: Jeg regner bare med at anvende tiscali's SMTP server... men hvis den ikke kan finde den, skulle den så ikke komme med en exception ?

arne_v: Der er ingen exceptions.. hverken i cataline.out eller på skærmen !
Det med porten, skal jeg vel ikke tænke på når jeg bruger smtp.tiscali.dk ?

jo du skal stadigvæk tænke på porten, hvis din adsl router f.eks. af en eller anden grund er sat op til at spærre udgående port 25, hvilket dog ville være MEGET dumt at gøre, da du så heller ikke kan sende emails fra outlook og lignende.

At du bruger Tiscali's server er en rigtigt god ting.

Post lige koden, hvor du kalder din Sendmail klasse.

Prøv og test fra Debian maskinen om du kan telnette til
smtp.tiscali.dk port 25:
  $ telnet smtp.tiscali.dk 25

Jeg kan desværre først komme vidre med det i aften !

Den bør smide en exception eller skrive noget *medmindre* koden
catcher exceptions og ikke gør noget:

try {
  // diverse kode
} catch(Exception e) {
  // ingenting
}

carls:
Fang mig på icq i aften, så skal vi hurtigt knække dette problem.

Jeg tror der er ved at være helt ged i den tomcat !
Nu får jeg en underlig fejl hver gang jeg prøver at tilgå en JSP side.. lige meget hvad der står i den !

type Status report

message Servlet jsp is currently unavailable

description The requested service (Servlet jsp is currently unavailable) is not currently available.

Har du ændret i nogle konfigurations-filer ?

Den tror du vil køre en servlet der hedder jsp !

Det synes jeg ikke at jeg har !
har bare opdateret et par af .JSP filerne... men selvom jeg laver en simpel test.jsp fil skriver den det samme !

Har du prøvet at genstarte Tomcat ?

Ja.. ca 100 gange...
Men mod alle odds, prøvede jeg at geninsallere Tomcat4.. nu ser det ummidelbart ud til at virke... prøver lige at kigge på det ..
(Mail virker stadig ikke )

2003-02-25 15:05:19 StandardContext[/manager]: Error initializing resources: Document base /usr/share/tomcat4/webapps/manager does not exist or is not a readable directory
2003-02-25 15:05:19 StandardContext[/manager]: Context startup failed due to previous errors
2003-02-25 15:05:19 StandardContext[/manager]: Exception during cleanup after start failed
LifecycleException:  Container StandardContext[/manager] has not been started
    at org.apache.catalina.core.ContainerBase.stop(ContainerBase.java:1147)
    at org.apache.catalina.core.StandardContext.stop(StandardContext.java:3451)
    at org.apache.catalina.core.StandardContext.start(StandardContext.java:3408)
    at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1123)
    at org.apache.catalina.core.StandardHost.start(StandardHost.java:614)
    at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1123)
    at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:343)
    at org.apache.catalina.core.StandardService.start(StandardService.java:388)
    at org.apache.catalina.core.StandardServer.start(StandardServer.java:506)
    at org.apache.catalina.startup.Catalina.start(Catalina.java:781)
    at org.apache.catalina.startup.Catalina.execute(Catalina.java:681)
    at org.apache.catalina.startup.Catalina.process(Catalina.java:179)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:324)
    at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:243)

2003-02-25 15:05:19 StandardHost[localhost]: Installing web application at context path  from URL file:/var/lib/tomcat4/webapps/ROOT
2003-02-25 15:05:19 WebappLoader[]: Deploying class repositories to work directory /usr/share/tomcat4/work/localhost/_
2003-02-25 15:05:19 StandardManager[]: Seeding random number generator class java.security.SecureRandom
2003-02-25 15:05:20 StandardManager[]: Seeding of random number generator has been completed
2003-02-25 15:05:22 StandardWrapper[:default]: Loading container servlet default
2003-02-25 15:05:22 default: init
2003-02-25 15:05:22 StandardWrapper[:invoker]: Loading container servlet invoker
2003-02-25 15:05:22 invoker: init
2003-02-25 15:05:22 jsp: init
2003-02-25 15:05:38 StandardHost[localhost]: Removing web application at context path
2003-02-25 15:05:38 StandardHost[localhost]: Removing web application at context path /manager
2003-02-25 15:05:38 StandardHost[localhost]: ContainerBase.removeChild: stop:
LifecycleException:  Container StandardContext[/manager] has not been started
    at org.apache.catalina.core.ContainerBase.stop(ContainerBase.java:1147)
    at org.apache.catalina.core.StandardContext.stop(StandardContext.java:3451)
    at org.apache.catalina.core.ContainerBase.removeChild(ContainerBase.java:984)
    at org.apache.catalina.core.StandardHost.remove(StandardHost.java:791)
    at org.apache.catalina.startup.HostConfig.undeployApps(HostConfig.java:422)
    at org.apache.catalina.startup.HostConfig.stop(HostConfig.java:402)
    at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:234)
    at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:155)
    at org.apache.catalina.core.ContainerBase.stop(ContainerBase.java:1151)
    at org.apache.catalina.core.ContainerBase.stop(ContainerBase.java:1163)
    at org.apache.catalina.core.StandardService.stop(StandardService.java:435)
    at org.apache.catalina.core.StandardServer.stop(StandardServer.java:535)
    at org.apache.catalina.startup.Catalina.start(Catalina.java:799)
    at org.apache.catalina.startup.Catalina.execute(Catalina.java:681)
    at org.apache.catalina.startup.Catalina.process(Catalina.java:179)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:324)
    at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:243)

2003-02-25 15:05:47 StandardContext[/manager]: Error initializing resources: Document base /usr/share/tomcat4/webapps/manager does not exist or is not a readable directory
2003-02-25 15:05:47 StandardContext[/manager]: Context startup failed due to previous errors
2003-02-25 15:05:47 StandardContext[/manager]: Exception during cleanup after start failed
LifecycleException:  Container StandardContext[/manager] has not been started
    at org.apache.catalina.core.ContainerBase.stop(ContainerBase.java:1147)
    at org.apache.catalina.core.StandardContext.stop(StandardContext.java:3451)
    at org.apache.catalina.core.StandardContext.start(StandardContext.java:3408)
    at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1123)
    at org.apache.catalina.core.StandardHost.start(StandardHost.java:614)
    at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1123)
    at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:343)
    at org.apache.catalina.core.StandardService.start(StandardService.java:388)
    at org.apache.catalina.core.StandardServer.start(StandardServer.java:506)
    at org.apache.catalina.startup.Catalina.start(Catalina.java:781)
    at org.apache.catalina.startup.Catalina.execute(Catalina.java:681)
    at org.apache.catalina.startup.Catalina.process(Catalina.java:179)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:324)
    at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:243)

Jeg synes ikke det ser så godt ud.. Det er localhost_log

Det ser ikke godt ud !


Indlysende spørgsmål:

1) Eksisterer /usr/share/tomcat4/webapps/manager  ?

2) Har det brugernavn Tomcat kører under adgang til det directory ?

Jeg har fundet ud af at ../webapps/manager ikke eksistere.. og tomcat kører root så den skulle nok have adgang...

Jeg har også fået det til at virke..  Ved at flytte alt fra WEB_INF/classes virkede det... jeg er nu ved at ligge tingene tilbage i små bidder !

/usr/share/tomcat4/webapps/manager stod jo i exception'sene, så
der må jo være en referanc etil det et eller andet sted.

Har det eventuelt eksisteret tidligere ?

carls:
Smid tomcat langt væk og download Resin fra www.caucho.com

Tomcat er som du nok kan se besværlig at havde med at gøre, hvorimod Resin er legende let at arbejde med og configurere.

jeg synes ikke den har være der før...  men jeg undre mig...
Det er en lang historie men du får den aligevel:
Jeg er ved at lave noget med at der skal sendes en mail ud fra jsp sider.
For at kunne gøre det, skulle jeg bruge j2ee.jar.
Jeg havde lidt problemer med at få tomcat4 til at finde den fil, så det endte med at jeg pakkede den ud, og lagde den under web-inf/classes (kæmpe projekt)
Det har så virket fint (udover at der ingen mail kom frem) og alle fejlmeddelser forsvandt.

Nu, her idag, da jeg startede maskinen op virkede det self. stadig. Men da jeg lige ville ændre i et par .jsp filer (som ikke have noget med mailen at gøre) kom den underlige fejl....
jeg har nu fudnet ud af, at hvis jeg fjerner alt det som lå i j2ee.jar fra WEB-INF/classes forsvinder fejlen (alstå den fejl med Jsp servlet exception)
men nu er jeg tilbage ved det gamle problem med mail at den mangler et par klasser !

er lige nu ved at prøve at pakke j2ee.jar ud igen og lægge den ind i WEB-INF/clases igen !

Disky: Det var faktisk en af de ting jeg ville spørge dig om i aften, altså om resin er bedre ?
... men kan jeg downloade den med apt-get, i debian! jeg er som sagt ret dårlig til linux !

Resin er lettere at installere, lettere at configurere, performer bedre.

Elle dem jeg har hjulpet med JSP problemmer, der har brugt tomcat og har skiftet til Resin har enstemmigt sagt at Resin er bedre.

En jeg hjalp igår via ICQ samtidigt med dig bøvlede vi med Tomcat i 2 timer, til sidst bad jeg ham sparke den ud og installere Resin istedet for, 10 min senere virkede det hele som det skulle.

Tomcat er et til tider brugbart produkt, men det når ikke mere prof. produkter til knæene.

Humm.. så tror jeg også at det er min løsning.... men så er problemet bare hvordan jeg installere den ! :o(

Skal man tage 3.0b eller 2.1 ?

tag nyeste ikke beta udgave, det er vist 2.1.6 eller 2.1.7.

Du skal ikke udpakke j2ee.jar i webapps/dinapp/WEB-INF/classes.

Du skal ligge den som jar-fil i enten server/lib eller
webapps/dinapp/WEB-INF/lib.

Ja i resin smider man den i WEB-INF/lib og så spiller det bare.

arne_v: Jeg har prøvet at ligge den der.. men uden held.
Jeg tror nu jeg vil prøve det resin, der må være noget om det, når alle siger det er bedre !

forudsat problemmer ikke er en underlig opsætning af din linux box, tør jeg næsten garantere vi snilt kan få det op og køre.

Bare fang mig på ICQ i aften.

Ikke alle.

Jeg har f.eks. kun prøvet Resin en gang. Da en bruger her på Eksperten
havde et mystisk problem. Og vi endte med at måtte konkludere at
Resin havde en bug.

Så jeg kunne f.eks. aldrig drømme om at bruge Resin til noget
seriøst.

Hvor skal man insallere resin henne ?
/usr/share ? var/lib ?

Så fik jeg installeret resin !

men en lille fejl... jeg er sikker på at du ved hvad det er !
Skal man ikke sætte JAVA_HOME nogen steder ?

500 Servlet Exception
Resin can't load sun.tools.javac.Main.  Usually this means that the JDK
tools.jar is missing from the classpath, possibly because of using a JRE
instead of the JDK.  You can either add tools.jar to the classpath or change
the compiler to an external one with <java compiler='javac'/> or jikes.

java.lang.ClassNotFoundException: sun.tools.javac.Main


--------------------------------------------------------------------------------
Resin 2.1.7 (built Fri Feb 14 12:48:13 PST 2003)

Arne:
Du har et seriøst problem hvis du ikke vil bruge software hvor der kan forekomme bugs, jeg tvivler på du finder meget software der IKKE er bugs i.

Måske skulle du finde en anden branche, eller er du så super dygtig du aldrig selv laver fejl ?

carls:
Jo java_home skal sættes, det står i dokumentationen hvordan du gør, der er et script der skal kopieres til din /etc/init.d skuffe som starter og stopper Resin, i den defineres java_home

Her er min udgave af filen:

#! /bin/sh
#
# httpd.sh can be called like apachectl
#
# httpd.sh        -- execs the web server in the foreground
# httpd.sh start  -- starts the web server in the background
# httpd.sh stop    -- stops the web server
# httpd.sh restart -- restarts the web server
#
# httpd.sh will return a status code if the wrapper detects an error, but
# some errors, like bind exceptions or Java errors, are not detected.
#
# Customized arguments, e.g. -resin_home or -java_home or -pid.
#
# -pid <pidfile>        -- use a non-default pid file
#                          (useful for multiple servers)
# -java_home <java_home> -- use a non-default Java home
# -stdout <filename>    -- stdout message log
# -stderr <filename>    -- stderr message log
# -native                -- force native threads
# -green                -- force green threads
# -verbose              -- prints Java arguments before starting.
# -no-auto-restart      -- disable automatic server restart
#                        -- (this only appled to start and restart)
#
# This script can be used as a Linux boot script in init.d.  You'll need to
# configure JAVA_HOME and RESIN_HOME directly.
#
# chkconfig: 345 86 14
# description: Resin is a servlet web server.
# processname: wrapper.pl
#
# To install, you'll need to configure JAVA_HOME and RESIN_HOME and
# copy httpd.sh to /etc/rc.d/init.d as resin.  Then
# use "unix# /sbin/chkconfig resin on"
#
#
# You can predefine JAVA_HOME and RESIN_HOME
#
JAVA_HOME=/usr/local/jdk1.3.1
export JAVA_HOME
#
RESIN_HOME=/usr/local/resin-2.0.2
export RESIN_HOME

CLASSPATH=/usr/local/jdk1.3.1/lib:/home/disky/www/WEB-INF/classes/lib:/home/apache/akvarieinfo.dk/WEB-INF/classes/lib
export CLASSPATH

#
# Extra arguments to Java.  If you're passing arguments to the JVM, you'll
# need to use -Jxxx.  For example, args="-J-ms48m".  You can modify
# the pid file with args="-pid server-a.pid"
#
args=
#
# class to start
#
class=com.caucho.server.http.HttpServer
#
# name of the server
#
name=httpd
#
# location of perl executable
#
perl=perl

#
# trace script and simlinks to find thw wrapper
#
script=`/bin/ls -l $0 | awk '{ print $NF; }'`

while test -h "$script"
do
  script=`/bin/ls -l $script | awk '{ print $NF; }'`
done

bin=`dirname $script`

exec $perl /usr/local/resin-2.0.2/bin/wrapper.pl -chdir -name "$name" -class "$class" $args $*

disky>

Det var en hel elementær feature der ikke virkede.

Og jeg konkluderede at de ikke tester deres produkt inden
de releaser.

Jeg føler mig til grin hvis jeg betaler for et kommercielt
produkt, som ikke bliver testet inden release.

Som sagt skift branche, for det er der MANGE firmaer der gør.

En komplet test af et stykke software tager også fakultet tid af antal features, så nogle fejl smutter der igennem.

Men jeg må nok sige dine dømme evner er meget ringe, hvis du skrotter et helt produkt på en fejl der er sneget igennem. Og det passer slet ikke sammen med du er forelsket i Tomcat, for det er fyldt af fejl også.

Hvorfor gør caucho ikke som mange andre gør: kører automatiseret
JUnit test efter hver build ?

Det koster ingen menneske tid - kun en masse CPU cycles.

Jeg er iøvrigt aldrig stødt på en tilsvarende grel fejl i Tomcat.

Men selv om jeg havde, så hvade det jo ikke fået mig til at
fraråde produktet.

Jeg kan acceptere gratis produkter er dårligt testede.

Jeg kan acceptere dyre produkter som er godt testede.

Jeg vil bare ikke betale for dårligt testede produkter.

Så ifølge dig er gratis produkter altså dårlige og fejl helt ok?

Flot at du kan udtale dig om at Caucho ikke bruger junit tests.

Men du kører vel også junit tests af din junits test af din junit test osv.

Læser du ikke lidt dårligt ?

Jeg har ikke sagt, at gratis produkter er dårlige !

Jeg har sagt at jeg kan acceptere at gratis produkter er dårligt
testede i modsætning til produkter man betaler for.

Der er en kendt talemåde "Man får hvad man betaler for". Men det betyder
også at hvis jeg betaler, så vil jeg have noget for pengene.

Jeg har ikke den fjerneste anelse om hvorvidt Caucho bruger JUnit eller
ej - det var dig der der forklarede at det tog lang tid at teste og at
det kunne forklare at man ikke havde testet en så elementær feature. Det lød
meget som om du var sikker på at Caucho ikke brugte automatiseret test.

Hvis et program skal testes 100% igennem, skal alle kombinationer af eller ting testes op imod hinanden, ellers er det ikke testet igennem.

Da dette ikke er muligt selv med junit, kan der ALTID slippe mystiske fejl igennem.

Og der kan også være fejl i en junit test, igen fordi det er software, så man skal faktisk junit teste sin junit test, som igen skal testes osv.

At jeg bruger Resin i forhold til Tomcat, er netop det at det er et prof produkt, som er lettere at konfigurere, installere og arbejde med.
Men selvfølgelig selv i det bedste software kan der slippe fejl igennem, bare se 1. ariane 5 opsendelse.

Jeg er helt enig i at det er svært at teste for alt.

Men 2 x POST request til en servlet som laver en forward
er ikke ligefrem et ekstremt tilfælde.

Hvis nogen selv vil se sagen vi diskuterer så er den på:
  http://www.eksperten.dk/spm/306726

Og du har sagt mange gange at Resin er nemmere at installere end Tomcat.

Hvordan kan noget være nemmere at installere end:
  unzip filnavn<retur>
?

Fra du har downloadet filen, til du er kørende er der mere end bare en unzip.
Der skal måske  ændres i config filer, også i andre programmers til tider, måske skal routeren/firewall'en omkonfigureres osv. osv. osv.

Det gælder selvfølgelig andre programmer.

Og snakker vi linux så er en omgang af:
./configure
make
make install

Oftest også en god ting så programmet er compilet specifikt til din server.

Måske ønsker du ikke at programmet skal ligge der hvor du unzipper det osv.

Disky: Det må man sige... jeg installerede bare programmet... og fik det på mistænkelig vis startet.. og det hele virkede i først hug !
Der er self. lige et par småting, men det virker sgu (også det med mailen)
.. men.... det gamle problem med æøå er blevet endnu værre... Nu er det også mine knapper og almindelig tekst der er problemer med ?
er det en opsætning ?

Glimrende.

Hvad er det for et ÆØÅ problem ?

Og knap problem ?

disky>


Jeg har meget svært ved at hvorfor der skulle ændres mere i firewall
for Tomcat end Resin.

Jeg har også svært ved at se pointen i at rebuilde en pure Java
app.

Men OK hvis det er svært at få unzippet i det rigtige directory, så kan man sikkert rende ind i mange andre problemer også.

:-)

rende ind i mange problemr

Du er sgu ligeså stædig som et æsel.

JEG SNAKKER GENERELT OM INSTALLATION !!!!!

IKKE SPECIFIKT OM TOMCAT ELLER RESIN.

COMPRENDE ??? (mit gæt nej)

Så jeg spørger om hvordan Resin kan være nemmere at installer end Tomcat
og du svarer med nogle generelle betragtninger om installation ?

Helt korrekt: mig ikke comprende !

Carls>

Nå men du bad jo egentlig ikke om en mellem-stor krig mellem
Tomcat og Resin tilhængerne.

:-)

Har du stadigvæk problemet med ÆØÅ ?

Er det tekst-strenge som er i din Java source der giver
problemer eller tekst-strenge som du henter fra eksterne filer
eller tekst-strenge som du henter fra database eller alle sammen ?

Jeg forklarer dig at installation er MERE end bare at unzip'e en fil.

du skriver 'Hvordan kan noget være nemmere at installere end:'

Noget er ikke defineret specifikt, altså en generel betragtning. Havde du skrevet f.eks. 'Hvordan kan resin være nemmere at installere end tomcat med:'
Så havde du specikt nævnt problemstillingen istedet for din generelle betragtning.

Spørger man i øst får man måske svar i vest.


Men nu gider jeg ikke spilde mere tid på dig i denne tråd.

Jeg skrev ikke:
#Hvordan kan noget være nemmere at installere end:

Jeg skrev faktisk:
#Og du har sagt mange gange at Resin er nemmere at installere end Tomcat.
#
#Hvordan kan noget være nemmere at installere end:

Men den tanke strejfede dig ikke, at de 2 linier kunne
relatere sig til hinanden ?

carls>

Der er andre end dig der har haft problemer med den konfiguration.

Se f.eks.:
  http://forum.java.sun.com/thread.jsp?thread=315993&forum=16&message=1411712

Det lyder som om en:
  -Dfile.encoding=ISO-8859-1
til java kommandoen er den generelt accepterede løsning.


  -Dfile.encoding=ISO-8859-1

arne_v: Jeg er ikke helt med på hvordan jeg skal bruge det ?

du angiver det i det script som starter resin serveren.

Prøv og sæt det ind i opstarts-filen.

Jeg kender ikke Resin på Linux, men noget i retning af:

#
# Extra arguments to Java.  If you're passing arguments to the JVM, you'll
# need to use -Jxxx.  For example, args="-J-ms48m".  You can modify
# the pid file with args="-pid server-a.pid"
#
args="-J-Dfile.encoding=ISO-8859-1"

men ændring af 'æøåÆØÅ' til html ekvivalenterne (damm hvordan staver man det ord) løser også problemmet.

Hvad var løsningen på mail-problemet ?

se 25/02-2003 17:56:30 posting.