På tomcat 3.3 under webaps/root/minMappe har jeg gemt jsp side og applet. Beans er gemt under webaps/classes/Socket.Appleten på siden skal kun oprette socket forbindelse og lytter når serveren notify klienter.serverBean skal oprette en tråd klasse som lytter på port 7777(tomcat server lytter på 8080). Jeg får altid fejl når jeg adskiltkompilerer beans klasser at de ikke kender hinanden selvom de står i samme package Socket, men når beans kompileres som projekt er der ingen fejl kun Note: serverBean.java uses or overrides a deprecated API. Note: Recompile with -deprecation for details. disse kode giver fejl at der kendes ikke directori !--%@ page language="java" import="Socket.*"%--> jsp:useBean id="server" scope="application" class="serverBean" /> her får jeg en null pointerExc. og så får jeg masse exception om tråd og JVM
Denne side indeholder artikler med forskellige perspektiver på Identity & Access Management i private og offentlige organisationer. Artiklerne behandler aktuelle IAM-emner og leveres af producenter, rådgivere og implementeringspartnere.
Hvis jeg har forstået dig rigtigt, er en del af problemet, at din jsp-side ikke kan finde dine bean-klasser.
Dette skyldes, at du har placeret dine beanklasser forkert, de skal ligge i en webapplikation, d.v.s. at beanklasserne skal ligge under webapps/root/web-inf/classes. ENdelig skal der være en fil webapps/root/web-inf/web.xml, der beskriver webapplikationen.
Du er faktisk i gang med at lave tilføjelser til en eksistérende root-webappliaktion, såå de nævnte filer/kataloger bør ligge der i forvejen, så det burde bare være at placere beanklasserne som nævnt.
Prøv det, og se hvad der sker (der dukker sikkert mere bøvl op, menlad os tage en ting af gangen).
Det vil nu ikke gøre hverken fra eller til i retningen af, at løse problemet.
Det er ikke nødvendigt at genstarte Tomcat ved ændringer i klasser, hvis man har sat den rigtige parameter op i sin serverkonfiguration. Jeg formoder, at man også i Resin kan vælge, om serveren skal kigge efter ændrede klasser (godt i udvikling) eller lade være (godt i produktion, det performer lidt bedre).
Det er et kendt problem at tomcat 3.x IKKE kan finde ud af at se at klasser er ændret, jsp sider ja, men ikke beans. Dette er også tilfældet hvis den er sat korrekt op.
Skulle dog være rettet i 4.x.
Men lige meget hvad performer Tomcat tæt på elendigt i forhold til de mere prof. java engine, som f.eks. Resin.
Resin scanner hvert sekund for nye klasse, men som der står i config filen skal man selvfølgelig rette dette ved en produktions server.
I modsætning til tomcat har resin også kun 1 config fil, og er derfor langt lettere at sætte op, og samtidigt er den langt bedre dokumenteret.
ok ok, jeg har heldigvis næsten udelukkende brugt tomcat 4.
Jeg kan forstå på det hele, at der er sket store forbedringer i forhold til tomcat 3.x.
Klassereloading virker fint, ikke kun på jsp/servlets, men også på almindelige klasser (den knalder dog alle sessioner ned, men det er vel også bedre end classcastexceptions, som weblogic er slem til at give).
Normalt arbejder man kun med en konfigurationsfil på serveren (server.xml), og det er ofte slet ikke nødvendigt.
Dokumentationen er blevet meget bedre.
Performance virker fornuftig i testmiljøer, men er sikkert ringe i produktion.
Netop og fordi den performer dårligt i produktion, hvorfor så bruge den i udvikling, og risikere at den ikke opfører sig 100% som ens kommende produktions server ?
Tomcat er og bliver et produkt man kun kan brug til ikke seriøse ting.
Synes godt om
Ny brugerNybegynder
Din løsning...
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
