RE: TC (4), IIS isapi_redirector.dll
The installer mentioned uses JK2 which is officially unsupported by the Jakarta project. (See http://jakarta.apache.org/tomcat/connectors-doc/news/20041100.html#20041 115.1) Martin -Original Message- From: Aris Javier [mailto:[EMAIL PROTECTED] Sent: Monday, February 28, 2005 7:52 AM To: Tomcat Users List Subject: RE: TC (4), IIS isapi_redirector.dll sorry... forgot .com =) anyway, here's the site again. http://www.shiftomat.com/opensource/ regards aris philippines -Original Message- From: Paul Wallace [mailto:[EMAIL PROTECTED] Sent: Monday, February 28, 2005 2:39 PM To: Tomcat Users List Subject: RE: TC (4), IIS isapi_redirector.dll Hi thanks, but that link is dead! Hello! visit this site to automate your integration of tomcat and iis. http://www.shiftomat/opensource download the file and follow the instructions... regards aris -Original Message- From: Paul Wallace [mailto:[EMAIL PROTECTED] Sent: Monday, February 28, 2005 2:25 PM To: tomcat-user@jakarta.apache.org Subject: TC (4), IIS isapi_redirector.dll Hi, I am attempting to serve up my pages using IIS, and have Tomcat process my JSPs/Servlets using JK 1.2 Connector. I am following a what I would call a reputable tutorial (http://www.onjava.com/pub/a/onjava/2002/12/18/tomcat.html) which tells me to look here http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk/ release/v1 .2.0/bin/ for the isapi_redirector.dll, there or under my Win32 directory. I am running XP Pro and do not appear to have a Win 32 directory. In the above page are the various project downloads. Can someone tell me where I am being directed please? I see no effervescence to Isapi, IIS, redirector, JK or anything else of a similar topic. thanks and regards Paul. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: URL protocol handler issues
I had a similar problem, which I posted last week. You should find it
searching the Subject field for pluggable protocols in web apps if you
kee pold messages. What I found out so far is this:
- Defining the protocol handler doesn't do any harm. The URL class
searches through the system property java.protocol.handler.pkgs if it
doesn't get a protocol handler from the factory.
- The problem is that URL tries to load the class with
Class.forName(String) method (Check out the method static
URLStreamHandler getURLStreamHandler(String protocol)).
- Class.forName(String) calls the method
ClassLoader.getCallerClassLoader(), which returns null. I think this
means it uses the remodial classloader
- The premodial classloader cannot find the class becaus it is not in
the bootstrap classpath.
- Subsequently the system class loader is asked to load the class. This
classloader cannot find the class either, because the classes in the web
application are not in the classpath when tomcat was started.
- To solve the problem temporarily is put the protocol handler in the
class path.
- The disadvantage with this method is you need to distribute the
protocol handler separately. And if you need classes from the web
application, you need to add the webapp class repository the protocol
handler's list of repositories.
Martin Goldhahn
-Original Message-
From: Peter Crowther [mailto:[EMAIL PROTECTED]
Sent: Friday, February 11, 2005 2:59 PM
To: Tomcat Users List
Subject: URL protocol handler issues
Environment: Tomcat 5.0.28, built from source.
I'm trying to persuade Tomcat to allow me to use a custom URL
scheme ('bod3vfs'), both in webapps and in some of the
behind-the-scenes setup
- for example, I have a custom HostConfig that examines a
virtual file system. I've tried the following approaches to
getting this integrated; none of them appear to work. Ideas welcome!
1) Create the handler in org.bodington.core.protocol.bod3vfs.Handler.
Package that into bodington3.jar; place in server/lib. Call
a static routine just after startup to amend
java.protocol.handler.pkgs to include
org.bodington.core.protocol. Result: MalformedURLException
when asking for bod3vfs:*.
2) As per 1, but add
-Djava.protocol.handler.pkgs=org.bodington.core.protocol.
Result as 1.
3) Amend DirContextURLStreamHandlerFactory to include the following:
public URLStreamHandler createURLStreamHandler(String protocol) {
if (protocol.equals(jndi)) {
return new DirContextURLStreamHandler();
} else if (protocol.equals(bod3vfs)) {
return new org.bodington.core.protocol.bod3vfs.Handler();
} else {
return null;
}
}
... and ensure that the factory replaces the standard factory
before it's required, in my custom HostConfig (which is
successfully loaded from bodington3.jar). Result:
java.lang.reflect.InvocationTargetException caused by
java.lang.NoClassDefFoundError:
org/bodington/core/protocol/bod3vfs/Handler at the point that
the runtime attempts to load
DirContextURLStreamHandlerFactory. Note that the compilation
was successful, and that the invoking class has been loaded
successfully from the same jar that contains the handler. If
I replace the return statement with 'return null',
DirContextURLStreamHandlerFactory loads and runs successfully.
4) Copy the Handler class into catalina.jar and repeat 3.
Same result.
Remy, the original code for DirContextURLStreamHandlerFactory
is yours, I think. Any particular reason you replaced the
factory rather than setting the packages?
- Peter
--
Peter Crowther, Director, Melandra Limited John Dalton House,
121 Deansgate, Manchester M3 2AB
t: +44 (0)161 828 8736 f: +44 (0)161 832 5683
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: URL protocol handler issues
-Original Message- From: Peter Crowther [mailto:[EMAIL PROTECTED] Sent: Monday, February 14, 2005 12:20 PM To: Tomcat Users List Subject: RE: URL protocol handler issues How are you examining the source of this method, by the way? If you downloaded the JDK you already have the source code of the URL class on your hard disk ($JDK_HOME/src.zip). - To solve the problem temporarily is put the protocol handler in the class path. - The disadvantage with this method is you need to distribute the protocol handler separately. And if you need classes from the web application, you need to add the webapp class repository the protocol handler's list of repositories. Hmm. That's going to be fun - there's a good few jars that would be needed. I'll see if I can separate them out. Martin, thanks for the input. I'm still interested in *why* the expected classloader isn't used - anyone got any insights? The document at http://jakarta.apache.org/tomcat/tomcat-5.5-doc/class-loader-howto.html elaborates on class loading. The reason why neither the system class loader nor the premodial classloader load your class is that each webapp has its own classloader that is separated from the rest of tomcat, i.e. class com.mycomp.MyClass in webapp A is a different type than com.mycomp.MyClass in webapp B. The tomcat plugin for Eclipse uses a classlaoder DevClassLoader that could provide a solution to the problem. But again, the class loader mut be put in tomcat's classpath or the VM's bootstrap path and cannot be packaged together with your webapp. --- Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
pluggable protocols in web apps
We use pluggable protocols to access resources. These don't seem to work with the class loading scheme Tomcat is using. Having a class no.mycomp.protocols.myprot.Handler I do the following: 1. prepend no.mycomp.protocols| to the system property java.protocol.handler.pkgs 2. create a URL with URL u = new URL(myprot://whatever); I get a MalformedUrlException: unknown protocol myprot When I debug the code I see that the call Class.forName() in URL.getURLStreamHandler() fails (The one in the try block). After that the System class loader cannot load my protocol handler either. Is ther a way to get this working. perferably without moving archives to Tomcat's common\ or Java's endorsed path? Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
