---

Hejsa,

Jeg har lavet min egen Handler impl.

package sun.net.www.protocol.dongfang;
public class Handler extends URLStreamHandler ......

Dette skulle så være (med det packagenavn) en URLStreamHandler til
protokollen dongfang. Det er det også -- virker fint i testkørsler. Jeg
kan i hvert fald instantiere URLs med min protokol og åbne streams på dem.

-- men det dur ikke under Tomcat! Unknown protocol: dongfang. Som om
katten ikke loader min handler.

Har prøvet at smide koden (altså sun directoryet m indhold) i
applikationen/WEB-INF/classes

og / eller i
common/classes

-- lige meget hjælper det.

Ved nogen hvad der er galt?

MVH
Søren

---

Soren Kuula skrev

> Jeg har lavet min egen Handler impl.
>
> package sun.net.www.protocol.dongfang;
> public class Handler extends URLStreamHandler ......
>
> Dette skulle så være (med det packagenavn) en URLStreamHandler til
> protokollen dongfang. Det er det også -- virker fint i testkørsler.
Jeg
> kan i hvert fald instantiere URLs med min protokol og åbne streams på
dem.
>
> -- men det dur ikke under Tomcat! Unknown protocol: dongfang. Som om
> katten ikke loader min handler.

Mit gæt vil være, at klassen skal placeres på Tomcats classpath da
webapps og lign. bliver loaded via deres egen class loader. For at komme
på Tomcats classpath gætter jeg videre på, at klassen enten skal
placeres i et bibliotek (en jar fil) et sted under Tomcat serveren eller
placeres som et Java bibliotek i ext kataloget under den JRE Tomcat
benytter sig af.


Mvh,
--
Filip Larsen

---

Hej Filip,
> Mit gæt vil være, at klassen skal placeres på Tomcats classpath da
> webapps og lign. bliver loaded via deres egen class loader. For at komme
> på Tomcats classpath gætter jeg videre på, at klassen enten skal
> placeres i et bibliotek (en jar fil) et sted under Tomcat serveren eller
> placeres som et Java bibliotek i ext kataloget under den JRE Tomcat
> benytter sig af.

Tak for svar,

Jeg har i mellemtiden prøvet at lave en instans af min Handler klasse
inde fra min .jsp --- både på compile og på run af siden virker det!
Så den kan i hvert fald godt sniffes op fra den classloader som .jsp
siden bruger.

Spm. er hvilken classloader java's io package futter rundt med inde i
katten. Jeg lagde jo en kopi af min klasse (korrekt) ind under common i
tomcat, som eftersigede skulle være synlig for 'alt'.

Jeg kan ikke lige se noget security relateret snadder i loggene -- men
mon nogen ved om der er nogen generelle restriktioner på
URLStreamHandlers i tomcat?

MVH
Søren

---

Soren Kuula wrote:
> Hej Filip,
>
>> Mit gæt vil være, at klassen skal placeres på Tomcats classpath da
>> webapps og lign. bliver loaded via deres egen class loader. For at komme
>> på Tomcats classpath gætter jeg videre på, at klassen enten skal
>> placeres i et bibliotek (en jar fil) et sted under Tomcat serveren eller
>> placeres som et Java bibliotek i ext kataloget under den JRE Tomcat
>>

> Spm. er hvilken classloader java's io package futter rundt med inde i
> katten. Jeg lagde jo en kopi af min klasse (korrekt) ind under common i
> tomcat, som eftersigede skulle være synlig for 'alt'.

Hmm, jeg klarede den med vold, men kønt blev det ikke...!

Jeg tog min Handler og det transitive lokum af min anden kode som den
refererede til, og pakkede det sammen i en .jar -- og smed denne i
jre/lib/ext under min java. SÅ kunne URLStreamFactory (er det vel) finde
den.

Men nu skal jeg lave den dumme jar om hver gang jeg builder (der er
nemlig et interface med i jar'en som mange andre klasser refererer til,
så hver gang dette interface rebuildes (med eller unden ændringer), skal
den nyesteudgave i jar'en) ... og genstarte Tomcat helt. Det er ikke
optimalt...

Så hvis nogen kender en bedre måde at gøre ting synlige for whatever
classloader som har at gøre med URLStreams mv under Tomcat, vil jeg
gerne høre om det.

MVH
Søren

---

Soren Kuula wrote:
> Så hvis nogen kender en bedre måde at gøre ting synlige for whatever
> classloader som har at gøre med URLStreams mv under Tomcat, vil jeg
> gerne høre om det.
>
> MVH
> Søren
>

Vi plejer på arbejde at pakke libs/ejb/webapps sammen i en EAR, og
deploye hele skidtet i en fil.

Det har den fordel, at hver EAR deploy har sin egen class loader.

Dermed gør det det muligt at have forskellig versioner af 3 parts
software til det individuelle system.

---

Nikolaj Hansen wrote:

> Vi plejer på arbejde at pakke libs/ejb/webapps sammen i en EAR, og
> deploye hele skidtet i en fil.
>
> Det har den fordel, at hver EAR deploy har sin egen class loader.

> Dermed gør det det muligt at have forskellig versioner af 3 parts
> software til det individuelle system.

Yep .. men der duer netop ikke her, at det har sin egen classloader
(bare man kunne slå det fra...).

Når java.net.URL implementationen ser min hjemmelavede protokol, prøver
den at hente en handler til den -- over sin egen classloader (formentlig
-- i hvert fald ikke over min webapplikations, hvor skulle den vide
noget om den fra ? :)

Men selv ikke i commoin directory under Tomcat virker det, fordi de har
separeret common's classloading væk fra JRE'ens (ser det ud til).

De har reengineered den classloading lige rigeligt nok synes jeg :(

MVH
Søren

---

> Har prøvet at smide koden (altså sun directoryet m indhold) i
> applikationen/WEB-INF/classes

Prøvet WEB-INF\lib ?
Kan ske det kun dur med .jar filer i mappen.

Du husker vel at reloade din applikation i manageren når du ændrer på koden?
Medmindre du har sat det op i web.xml filen i din WEB-INF mappe så loader
tomcat kun dine .class filer én gang, modsat .jsp filerne som den jo
compiler hver gang der er pillet i dem.

Håber det hjælper lidt

--

- RpR
~=[ www.MopedGallery.dk ]=~
~=[ www.PhotoBlog.dk ]=~
--

---

On Tue, 10 May 2005 16:53:49 +0200, RpR wrote:

>
> Prøvet WEB-INF\lib ?
> Kan ske det kun dur med .jar filer i mappen.
>
WEB-INF/classes = *.class
WEN-INF/lib = *.jar
--
Hilsen/Regards
Michael Rasmussen
http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE3E80917