Re: Custom URL handlers in Tomcat web app
Christopher Schultz chris at christopherschultz.net writes: Praveen, pmanvi wrote: | I found that org.apache.catalina.loader.WebappLoader was setting the | URL.setURLStreamHandlerFactory() with DirContextURLStreamHandlerFactory, | basically jndi stream handler. | I updated this file rebuild the class placed it in | %TOMCAT_HOME%/server/classes directory so as to force classloader to load my | class. | | Now my custom URLStreamHandler is getting picked up properly. This is a great solution. For the benefit of those still reading this thread, could you post the changes you made to this class? It would be helpful for those searching the archives for solutions in the future. Thanks, -chris +1 Plus, one could place a link to it from the ticket on the Java issue tracker, so that people coming from there have a solution at hand. I simply don't see this getting fixed anytime soon. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tomcat 5.5: How to dump incoming, unprocessed HTTP requests?
Hi tomcat users, I was wondering whether it's possible to advise Tomcat to dump any incoming HTTP requests while preserving their original plain text nature? I tried hard to find something like this, but I only stumbled upon the RequestDumperValve, which unfortunately only has access to a request in its HttpServletRequest incarnation (i.e., already parsed). That's of no use for me though. I know there are Browser plugins which monitor HTTP traffic and all that, but that doesn't help because I am sending these requests from a Groupware client extension using Microsoft's WinHTTPRequest COM object, and this object doesn't let me inspect the actual request it is constructing. A network monitor tool does also not help, because the server runs on localhost while I'm developing of course. Is there an equivalent mechanism to Tomcat's Valves which has access to network data before it is actually parsed? Or do you have any other idea how to do this? Thanks! -Matthias - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.5: How to dump incoming, unprocessed HTTP requests?
Actually, I found a solution, but it is specific to WinHTTP: http://msdn2.microsoft.com/en-us/library/aa384119(VS.85).aspx It worked perfectly for me, and I found the error I was hunting down for 2 hours... So in this regard, I'm fine now. But still, I am curious whether there is a server-side solution to this, because I usually don't develop for Windows machines and this was not the first time I was looking for something like this. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Custom URL handlers in Tomcat web app
Christopher, thanks a lot for your replies. Christopher Schultz chris at christopherschultz.net writes: MK wrote: | 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. As I'm reading more in the API, I can see that the URL class has a constructor that takes a URLStreamHandler. Could you utilize this constructor instead? that's a good idea actually (although it would require me to parse the incoming URL strings on my own; a job which is otherwise done by the URL ctor itself, but oh well). However, unfortunately this still does not help, because it merely moves the problem further down the implementation of that (somewhat obscure) API I am using. The problem is that with this constructor, creating a URL object on my side succeeds, but passing it to that API will still result in a MalformedUrl somewhere down their implementation, maybe because they pack/unpack the wrapped URL string to create other URL objects from it, dunno. Dang! I though I almost had it :-) as for the checking whether the JVM argument for my protocol package is properly set, I already had done that and I can assure you it is properly set. Tomcat really seems not to honor this value properly before registering its URLStreamHandlerFactory. I am using Tomcat 5.5 by the way. I will try rolling a jar from my protocol handler and put it in the places you suggested. Maybe that'll work, I'll report back. Regards, Matt - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Custom URL handlers in Tomcat web app
MK kaeppler.matthias at nts.ricoh.co.jp writes: [...] I am using Tomcat 5.5 by the way. I will try rolling a jar from my protocol handler and put it in the places you suggested. Maybe that'll work, I'll report back. actually I just realized that this is not gonna help if Tomcat does not honor the java.protocol.handler.pkgs setting, because even if Tomcat can load the JAR and knows where to look for it, it would still need to read this setting to load the Handler class upon URL construction (because this happens through Tomcat's URLStreamHandlerFactory), no? Anywho, I just tried common/lib, common/endorsed and a custom location I added manually to the classpath (which would make it available to the system classloader right?). Didn't work. Any ideas left that do not include the words Tomcat sources and modify? :D I still can't quite believe how a trivial operation such as constructing a java.net.URL from a wellformed (!) URL can cause so much trouble in a Servlet based environment. I must be missing something. Regards, Matt - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Custom URL handlers in Tomcat web app
Christopher Schultz chris at christopherschultz.net writes: [...] | problem is, none of these approaches work in Tomcat 5.5. For 1), this simply | didn't have any effect for me. 2) neither, maybe Tomcat simply ignores that | property? How did you set the 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? | Does Tomcat meanwhile have some workaround for this? I mean, I don't even need | an actual URL connection, I just want to pass custom URL strings, which should | be perfectly fine if they are valid URLs, no?! Do you have the opportunity to intercept these URL objects, or are they always handled somewhere that you can't inspect them. I'm wondering if you can convert a notes:// URL into, say, an http:// URL before attempting to call URL.openConnection. I don't know anything about notes://, so maybe it isn't even HTTP-compatible. I'm sure there's a way around this. Give us some more information and we'll see what we can do. 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. 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. 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 wellformed URLs). These things should really be postponed to the time where someone actually tries to open a connection from that URL. 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 :-) Best, Matthias - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
