-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Matthias,
MK wrote: | Christopher Schultz <chris <at> christopherschultz.net> writes: |> |> How did you set the [Java] property? | | I am running my web app inside an Eclipse WTP server container project. So I set | the property as a JVM argument in the Server project's "Run" dialog. I set it | like this: | | -Djava.protocol.handler.pkgs="my.protocol" | | ...given that the Handler class is in package "my.protocol.notes". | | am I missing something here? That should be alright. You can always verify by checking the value itself during runtime (say, during the startup of your webapp). I would recommend doing this just to make sure. | Actually I don't even call URL.openConnection, because I don't need it at all. | It's really just that the java.net.URL constructor requires that there exists an | object which implements this behavior just in case someone should try to open a | connection. Ah, I see. | My situation really is just that there is an API some methods of which take URL | objects instead of plain URL strings in order to link to documents from a web | page (intranet pages). Since notes:// links will open in the Lotus Notes client, | which everyone uses in this company, it should be fine to pass notes:// links if | they are wellformed. There are no calls to openConnection. Well, that's good -- at least you don't have to implement your own protocol or anything like that. | Throwing a MalformedUrl in the constructor if no connection handler is found for | the given protocol is simply a bad design decision IMHO (besides, what does | connection handling have to do with well-formed URLs). These things should really | be postponed to the time where someone actually tries to open a connection from | that URL. I completely agree with you. | But since I can neither change that API I use nor the JVM | implementation, I have to find another way to work around that problem :-) Where are you putting the implementation of the protocol handler? From the bug you mentioned in your original post, it looks like putting it into your webapp just isn't going to work. Instead, you'll have to install it into a ClassLoader that is higher-up in the chain. According to the bug comments, your implementation must be in the system classpath (that is, not loaded through any of the ClassLoaders that Tomcat creates). Which version of TC are you running? In TC 6, you should be able to use <tomcat>/lib. For TC 5.5, try <tomcat>/common/lib and then <tomcat>/common/endorsed. As a last resort, you could put your JAR file into the JRE's "endorsed" directory. Make sure you only have this library living in one place at a time, or other weird things might start happening. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkfC0NAACgkQ9CaO5/Lv0PD6QwCgpdOO7S49z6e/Ab4Bn10zJ2Bh HhEAmwb98Eyku/JXyhb0OTZkVOWWh8UB =Uygl -----END PGP SIGNATURE----- --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
