TC4: java.lang.LinkageError: duplicate class definition. PLEASE HELP!
Hello, I am getting following error when invoke my jsps for the first time after TC start. It happens only first time - once all classes has been loaded it works fine i.e. I click refresh after the error and it doesn't happen any more. It only happens when two clients trying to access my pages simultaneously. In my case I have three frames on a web page each of the frames use the same custom tags and therefore share the same classes. If I open each frame's jsp one after another I do not get any errors. Duplicate class definition exception happens on any class depending on timing not on any specific one. I am pretty sure there is no duplicate classes in TC class hierarchy. My application uses: - My custom JNDI factories (jars are in TC/lib) - My custom tags they get my factories from JNDI (jars are in TC/lib) - Xalan, Xerces etc (jars TC/lib) - My Ldap authentication (jars TC/common/lib) I am not sure how can I debug this because complex nature of TC class loading I would appreciate your help Alex java.lang.LinkageError: duplicate class definition: org/apache/xalan/lib/Extensions at java.lang.ClassLoader.defineClass0(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:486) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:111) at java.net.URLClassLoader.defineClass(URLClassLoader.java:248) at java.net.URLClassLoader.access$100(URLClassLoader.java:56) at java.net.URLClassLoader$1.run(URLClassLoader.java:195) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at org.apache.catalina.loader.StandardClassLoader.findClass(Unknown Source) at org.apache.catalina.loader.StandardClassLoader.loadClass(Unknown Source) at org.apache.catalina.loader.StandardClassLoader.loadClass(Unknown Source) at org.apache.catalina.loader.WebappClassLoader.loadClass(Unknown Source) at org.apache.catalina.loader.WebappClassLoader.loadClass(Unknown Source) at org.apache.xalan.extensions.ExtensionHandler.getClassForName(ExtensionHa ndler.java:133) at org.apache.xalan.extensions.ExtensionHandlerJavaClass.(ExtensionHa ndlerJavaClass.java:121) at org.apache.xalan.extensions.ExtensionsTable.(ExtensionsTable.java: 106) at org.apache.xpath.XPathContext.(XPathContext.java:423) at org.apache.xalan.transformer.TransformerImpl.(TransformerImpl.java :438) at org.apache.xalan.templates.StylesheetRoot.newTransformer(StylesheetRoot. java:175) at org.apache.xalan.processor.TransformerFactoryImpl.newTransformerHandler( TransformerFactoryImpl.java:668) at com.peacetech.webtools.fw.XServletHelper.getXsltProcessor(XServletHelper .java:279) at com.peacetech.webtools.fw.XServletHelper.getXsltProcessors(XServletHelpe r.java:287) at com.peacetech.webtools.fw.XServletHelper.defaultOutput(XServletHelper.ja va:477) at com.peacetech.webtools.fw.XServletHelper.defaultOutput(XServletHelper.ja va:471) at com.peacetech.webtools.taglib.XsltFileTransformTag.doEndTag(XsltFileTran sformTag.java:46) at org.apache.jsp.main_0002dmenu_0002dtabs$jsp._jspService(main_0002dmenu_0 002dtabs$jsp.java:99) at org.apache.jasper.runtime.HttpJspBase.service(Unknown Source) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(Unknown Source) at org.apache.jasper.servlet.JspServlet.serviceJspFile(Unknown Source) at org.apache.jasper.servlet.JspServlet.service(Unknown Source) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Unknown Source) at org.apache.catalina.core.ApplicationFilterChain.doFilter(Unknown Source) at org.apache.catalina.core.StandardWrapperValve.invoke(Unknown Source) at org.apache.catalina.core.StandardPipeline.invokeNext(Unknown Source) at org.apache.catalina.core.StandardPipeline.invoke(Unknown Source) at org.apache.catalina.core.ContainerBase.invoke(Unknown Source) at org.apache.catalina.core.StandardContextValve.invoke(Unknown Source) at org.apache.catalina.core.StandardPipeline.invokeNext(Unknown Source) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(Unknown Source) at org.apache.catalina.core.StandardPipeline.invokeNext(Unknown Source) at org.apache.catalina.core.StandardPipeline.invoke(Unknown Source) at org.apache.catalina.core.ContainerBase.invoke(Unknown Source) at org.apache.catalina.core.StandardContext.invoke(Unknown Source) at org.apache.catalina.core.StandardHostValve.invoke(Unknown Source) at org.apache.catalina.core.StandardPipeline.invokeNext(Unknown Source) at org.apache.catalina.valves
Encoding "=". Catalina does not understand http parameter with un-encoded equal sign inside param value
Hello Catalina does not understand http parameter with un-encoded equal sign inside i.e. myparam=fname='alex';lname='roytman' It use to work in Tomcat 3.x and I wonder if equal sign in parameter value has to be encoded according to specs or not
Catalina. Class Loader problem. java.lang.LinkageError: duplicate class definition
Hello, I am getting this error when hit my web page first time. What is the most puzzling that after few retries it works no more errors. There is no duplicate class paths in my class path and WEB-INF/class(lib) I would really appreciate if you can point me in right direction Alex java.lang.LinkageError: duplicate class definition: com/peacetech/webtools/tomcat/factory/PropertiesFactory at java.lang.ClassLoader.defineClass0(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:486) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:111) at org.apache.catalina.loader.WebappClassLoader.findClassInternal(WebappCla ssLoader.java:1475) at org.apache.catalina.loader.WebappClassLoader.findClass(WebappClassLoader .java:836) at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader .java:1215) at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader .java:1098) at org.apache.naming.factory.ResourceFactory.getObjectInstance(ResourceFact ory.java:125) at javax.naming.spi.NamingManager.getObjectInstance(NamingManager.java:304) at org.apache.naming.NamingContext.lookup(NamingContext.java:835) at org.apache.naming.NamingContext.lookup(NamingContext.java:181) at org.apache.naming.NamingContext.lookup(NamingContext.java:822) at org.apache.naming.NamingContext.lookup(NamingContext.java:181) at org.apache.naming.NamingContext.lookup(NamingContext.java:822) at org.apache.naming.NamingContext.lookup(NamingContext.java:194) at org.apache.naming.SelectorContext.lookup(SelectorContext.java:183) at javax.naming.InitialContext.lookup(InitialContext.java:350) at com.peacetech.webtools.fw.ServletHelper.(ServletHelper.java:44) at com.peacetech.webtools.fw.XServletHelper.(XServletHelper.java:101) at com.peacetech.webtools.taglib.TagBase.getHelper(TagBase.java:79) at com.peacetech.webtools.taglib.TagBase.doStartTag(TagBase.java:53) at com.peacetech.webtools.taglib.XsltFileTransformTag.doStartTag(XsltFileTr ansformTag.java:28) at com.peacetech.webtools.taglib.TabPanelTag.doStartTag(TabPanelTag.java:19 ) at org.apache.jsp._0002fmain_0002dmenu_0002dtabs_jsp._jspService(_0002fmain _0002dmenu_0002dtabs_jsp.java:91) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:107) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServle t.java:200) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:379) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:456) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica tionFilterChain.java:247) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt erChain.java:193) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValv e.java:243) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.ja va:566) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:4 72) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValv e.java:219) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.ja va:566) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(Authenticator Base.java:472) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.ja va:564) at org.apache.catalina.valves.CertificatesValve.invoke(CertificatesValve.ja va:246) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.ja va:564) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:4 72) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943) at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:225 1) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java :164) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.ja va:566) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:446 ) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.ja va:564) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:4 72) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve. java:163) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.ja va:566) at org.apache.catali
Adding contextPpath and realPath to tomcat environment jndi
Hello I would like to propose to add several things to tomcat's context's environment jndi when a context gets created Specifically I am interested in context path, context real path and any other tomcat context runtime info If it will not violate security I would be happy if Context itself can be looked up via jndi. One of the uses of this kind of information will be to help jndi object factories which need this info to read its metadata from WEB-INF directory (i.e. many Object/Relational mappers need access to their metadata to be initialized). It is possible to use Environment entries for this purpose but it will be deployment nightmare because we will need to hardcode real path to context. If you think that this case is well justified it would be great if we could add it to Servlet specs Alex
Catalina. Jasper generates invalid java code
The problem with this piece of code generated for my JSP by tomcat4.0b6
is that it catches Throwable t and then call
pageContext.handlePageException(t) which takse Exception NOT throwable
!! as parameter as a result I am getting class cast exception:
org.apache.jasper.JasperException: Unable to compile class for
JSPnullD:\java\apache\tomcat4\work\localhost\usorg\_0002forgunits_jsp.ja
va:225: Incompatible type for method. Explicit cast needed to convert
java.lang.Throwable to java.lang.Exception.
if (pageContext != null) pageContext.handlePageException(t);
^
1 error
==
} catch (Throwable t) {
if (out != null && out.getBufferSize() != 0)
out.clearBuffer();
if (pageContext != null) pageContext.handlePageException(t);
} finally {
if (_jspxFactory != null)
_jspxFactory.releasePageContext(pageContext);
}
==
Catalina. Resource factory gets re-created on every resource lookup!
Hello
I am not sure it is desired behavior so I would like to bring it to your
attention
New instance of my factory gets created every time I lookup up a
resource in the environment.
i.e.
Context ctx = new InitialContext();
DataSource ds = (DataSource)ctx.lookup("java:comp/env/jdbc/usorg");
causes new instance of my connection pool be created. I can certainly
work around the problem (have static hash of connection pools by JNDI
name) but I would like to hear your opinion
Thank you very much
Alex Roytman
RE: Catalina: How to specify factory class name for a Resource inserver.xml
Craig, Thank you very much for your help. I have one more question. Why new instance of my factory gets created every time I lookup for a resource created by this factory? -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Tuesday, August 07, 2001 5:05 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: Catalina: How to specify factory class name for a Resource inserver.xml On Tue, 7 Aug 2001, Roytman, Alex wrote: > > > Hello, > > I am writing several jndi factories for catalina's JNDI implementation > and I am trying to figure out how to specify factory class for a > resource. The only sample I found was > type="javax.sql.DataSource"/> > and factory class for type="javax.sql.DataSource" is hard coded. > How do I specify factory class for my resource? > In server.xml, you configure the actual resource with a , which can have nested entries. Use a parameter named FACTORY to define the fully qualified clas name of the resource factory class itself. Alternatively, you can pass system properties that define the factory for a particular resource type. For example, to set the factory class name for a resource type "com.mycompany.Foo", you could say: export \ CATALINA_OPTS="-Dcom.mycompany.Foo.Factory=com.mycompany.MyFooFactory" before starting Tomcat 4. > Thank you very much > > Alex Roytman > Craig
Catalina server.xml DTD?
Hello, I am writing several jndi factories for catalina's JNDI implementation and I am trying to figure out how to specify factory class for a resource. The only sample I found was and factory class for type="javax.sql.DataSource" is hard coded. What is the attribute name for factory class? Thank you very much Alex Roytman
RE: LDAP realms.
Steve, Type of realm should not make any difference for your web.xml Your web.xml setup will be the same with JDBCRealm, or SimpleRealm or JndiRealm. You can use either form based auth (like in your example) or basic auth with JndiRealm. All JndiRealm config is done in tomcat's server.xml file This fragment is from role-map.xml I presume? user Right now the only wildcard supported is "*" but it is easy to add support for regular expressions. Actually you can plug-in your own RoleMapper. I provided SimpleRoleMapper as an example and default. You can use your own (just have your com.acme.tomcat.MyRoleMapper implement RoleMapper interface and in your server.xml specify roleMapperClass = com.acme.tomcat.MyRoleMapper") Alex Hey Alex, Your JndiRealm looks very interesting. I'm currently installing it for testing. I have two questions about setup. 1. Can I use your realms in my web.xml as follows? FORM UmsRealm login.html error.html 2. Can I map names to roles, using wildcards as follows? user -- Steve Steve Cannon [EMAIL PROTECTED] Chief Technology Officer -- OVEN www.oven.com 646 613 2852
RE: LDAPRealm & JNDIReam for Tomcat 3.2 and 4.0 beta 1 is availab le
Title: RE: LDAPRealm & JNDIReam for Tomcat 3.2 and 4.0 beta 1 is availab le Henry, >What about creating a sub project jakarta-tomcat-realms? Sure why not. Although I think TC4.0 has or will have some JNDI authentication I do not know how tomcat project works internally. I rely on tomcat developers (committers) for guidance. I love tomcat product and developed various extensions for it (context aware JNDI Environment for TC3.2 to make it somewhat J2EE compatible, Authentication, etc.) but I have no idea whether they are wanted (I know I can't develop without them) or not. I rely on you guys to provide guidance. If I got no response I assume it is not needed. Alex -Original Message- From: GOMEZ Henri [mailto:[EMAIL PROTECTED]] Sent: Tuesday, June 05, 2001 12:12 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: LDAPRealm & JNDIReam for Tomcat 3.2 and 4.0 beta 1 is availab le That was asked many time before but . What about creating a sub project jakarta-tomcat-realms - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED] (. .) PGP KEY : 697ECEDD ...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -Original Message----- From: Roytman, Alex [mailto:[EMAIL PROTECTED]] Sent: Tuesday, June 05, 2001 5:37 PM To: 'GOMEZ Henri'; [EMAIL PROTECTED] Subject: RE: LDAPRealm & JNDIReam for Tomcat 3.2 and 4.0 beta 1 is availab le Hello Henri, Has Interceptor architecture changed in TC3.3? If not 3.2 version should work just fine. In general I do not mind doing it however I did not see much interest from apache developers and little from users so I am not making any effort to make it truly open source - comments, documentation, etc. If somebody from tomcat developers community could review it would express some interest I will be glad to spend couple of days to its quality. Alex -Original Message- From: GOMEZ Henri [mailto:[EMAIL PROTECTED]] Sent: Tuesday, June 05, 2001 6:52 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: LDAPRealm & JNDIReam for Tomcat 3.2 and 4.0 beta 1 is availab le What about a port of LDAPRealm & JNDIReam to TC 3.3 ? Thanks http://www.peacetech.com/java/files/apache/tomcat/default.htm
RE: LDAPRealm & JNDIReam for Tomcat 3.2 and 4.0 beta 1 is availab le
Title: RE: LDAPRealm & JNDIReam for Tomcat 3.2 and 4.0 beta 1 is availab le Hello Henri, Has Interceptor architecture changed in TC3.3? If not 3.2 version should work just fine. In general I do not mind doing it however I did not see much interest from apache developers and little from users so I am not making any effort to make it truly open source - comments, documentation, etc. If somebody from tomcat developers community could review it would express some interest I will be glad to spend couple of days to its quality. Alex -Original Message- From: GOMEZ Henri [mailto:[EMAIL PROTECTED]] Sent: Tuesday, June 05, 2001 6:52 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: LDAPRealm & JNDIReam for Tomcat 3.2 and 4.0 beta 1 is availab le What about a port of LDAPRealm & JNDIReam to TC 3.3 ? Thanks http://www.peacetech.com/java/files/apache/tomcat/default.htm
LDAPRealm & JNDIReam for Tomcat 3.2 and 4.0 beta 1 is available
Title: LDAPRealm & JNDIReam for Tomcat 3.2 and 4.0 beta 1 is available
http://www.peacetech.com/java/files/apache/tomcat/default.htm
JndiRealm authenticates and authorizes users against JNDI. It was tested against LDAP JNDI
with Sun's and Netscape's jndi providers
LdapRealm authenticates and authorizes users directly against LDAP using Netscape LDAP JDK.
These two realms are interchangeable you can switch between them without many configuration changes.
According to my tests it performs 10 faster under 20 concurrent threads than JNDI with
Sun's LDAP provider. This is not final result because I need to test and tune-up multithreaded
access and synchronization there might be some misunderstanding on my part.
I also noticed some cases of JNDI loosing connection to the server under heavy multithreaded
load while Netscape's LDAP handled it nicely. Because I use LdapRealm for Tomcat 3.2 for my
production system it is tested better than JndiRealm.
There are four classes in the package :
JndiRealm and LdapRealm are for Tomcat 3.2x
JndiRealmCatalina and LdapRealmCatalina for Tomcat 4.0
className="com.peacetech.webtools.tomcat.JndiRealm" JNDI TOMCAT 3.2x
className="com.peacetech.webtools.tomcat.JndiRealmCatalina" JNDI TOMCAT 4.0
className="com.peacetech.webtools.tomcat.LdapRealmCatalina" LDAP TOMCAT 4.0
className="com.peacetech.webtools.tomcat.LdapRealm" LDAP TOMCAT 3.2x
Jndi/LdapRealm uses searchBindDN and searchBindCredentials to connect to a directory.
Then it looks for exactly one user name matching searchFilter in searchBaseContext
scoped by searchScopeAsString (values are "base", "one", "sub" according to LDAP URL rules)
If one and only one matching directory object is found it will use this object and
tomcat supplied credentials to authenticate the user.
If successful Realm will fetch user roles using JNDI attributes listed in securityAttributes
(comma separated directory attribute names). If attributesReadByOwner = "true" Realm will use
authenticated user itself to pool the attributes from directory otherwise it will use searchBindDN
to retrieve the attributes.
If roleMapperClass is specified Realm will use it to map user roles onto application roles
specific for each web context for tomcat 3.2x and specific for each defined Realm for tomcat 4.2.
Provided SimpleRoleMapper implementation will read role map from either roleMapperSourceUrl
(if specified) or for tomcat 3.2x from WEB-INF/role-map.xml file in each web context
if no roleMapperSourceUrl was defined (if WEB-INF/role-map.xml file does not exist in a context
no mapping for this context will occur).
You can use principalAttributes parameter to specify LDAP attributes to be stored in principal
so you can access them from your servlets
PARAMETERS:
jndiInitialContextFactory = "com.sun.jndi.ldap.LdapCtxFactory"
(or "com.netscape.jndi.ldap.LdapContextFactory")
This attribute for JndiRealm ONLY.
It corresponds to javax.naming.Context.INITIAL_CONTEXT_FACTORY
directoryUrl = "ldap://207.176.93.66:389"
This attribute for both JndiRealm and LdapRealm.
If you want to use SSL for LdapRealm you can use "ldaps" protocol: directoryUrl = "ldaps://207.176.93.66:636"
You will need to configure Sun's JSSE to use SSL
It corresponds to javax.naming.Context.PROVIDER_URL
jndiSecurityAuthentication = "simple"
This attribute for JndiRealm ONLY.
It corresponds to javax.naming.Context.SECURITY_AUTHENTICATION
jndiSecurityProtocol = "" ("" vendor default or "ssl", or vendor specific)
This attribute for JndiRealm ONLY.
It corresponds to javax.naming.Context.SECURITY_PROTOCOL
searchBindDN = "cn=ldap-user,o=pti"
This attribute for both JndiRealm and LdapRealm. User name to bind to directory
a to perform user name lookups. It corresponds to javax.naming.Context.SECURITY_PRINCIPAL
searchBindCredentials = "mypassword"
This attribute for both JndiRealm and LdapRealm. Password for searchBindDN
It corresponds to javax.naming.Context.SECURITY_CREDENTIALS
searchBaseContext = "o=pti"
Base context for user lookups
ldapVersion = "3"
This attribute for LdapRealm ONLY. Defines LDAP version.
searchScopeAsString = "base" | "one" | "sub"
defines search scope "base" - object scope, "one" - one level scope, "sub" - subtree scope.
attributesReadByOwner = "true"
defines who will read securityAttribures from the directory. If "true" authenticating user account
will be used to retrieve the roles otherwise the searchBindDN account used for user name lookups will
fetch the attributes. It is useful when either one or the other do not have permission to read the
attributes so you can chose the one which has this permissions
searchFilter = "cn={0}"
Filter to lookup authorizing user. Support java.text.MessageFormat.
The only parameter is to java.text.MessageFormat pattern authorizing us
RE: Upgrading tomcat 3.2.1 to 3.2.2
Title: RE: Upgrading tomcat 3.2.1 to 3.2.2 Did it for RedHat Linux 7.1 and Win2k (Apache server 1.3.19) today took 15 min each. Did stress test for an hour on linux - no problems -Original Message- From: Brandon Cruz [mailto:[EMAIL PROTECTED]] Sent: Friday, June 01, 2001 4:49 PM To: [EMAIL PROTECTED] Subject: Upgrading tomcat 3.2.1 to 3.2.2 Has anyone gone though an upgrade of Tomcat 3.2.1 to 3.2.2? I am using 3.2.1 connected via mod_jk to Apache and using Apj12. If I want to perform this upgrade, is it going to take a very long time? I seem to remember having quite a bit of difficulty setting everything up in the first place, compiling mod_jk, etc. Does anyone have any good or bad news relating to their experiences upgrading? Any helpful hints or warnings? Brandon Cruz
Please help. Accessing protected url from java when using form based authentication
Title: Please help. Accessing protected url from java when using form based authentication I need to access a protected resource on my web site from java. I use form based authentication and I was hoping that following sequence will make it but it dos not 1. Open url to protected resource. get JSESSIONID from headers 2. Post to /mycontext/login/j_security_check with cookie set to JSESSIONID= and name and password as POST parameters 3. Access protected resource again using the same session id Any help is greatly appreciated Alex
Form based Authentication - URLs with username:password are not supported
Title: Form based Authentication - URLs with username:password are not supported When using form based authentication urls username and password do not work i.e. http://alex:[EMAIL PROTECTED]/examples it works just fine with basic authentication but not with form based
JNDI & LDAP Realm for Tomcat 4.0 & Tomcat 3.2x alpha3 available: NEED YOUR FEEDBACK!
Title: JNDI & LDAP Realm for Tomcat 4.0 & Tomcat 3.2x alpha3 available: NEED YOUR FEEDBACK!
Dear tomcat users and developers,
This is an implementation of JNDI and LDAP realm for Tomcat 3 and 4
I would greatly appreciate you feedback regarding its functionality.
Alex Roytman
download from http://www.peacetech.com/java/files/apache/tomcat/
JndiRealm authenticates and authorizes users against JNDI. It was tested against LDAP JNDI
with Sun's and Netscape's jndi providers
LdapRealm authenticates and authorizes users directly against LDAP using Netscape LDAP JDK.
These two realms are interchangeable you can switch between them without many configuration changes.
According to my tests it performs 10 faster under 20 concurrent threads than JNDI with
Sun's LDAP provider. This is not final result because I need to test and tune-up multithreaded
access and synchronization there might be some misunderstanding on my part.
I also noticed some cases of JNDI loosing connection to the server under heavy multithreaded
load while Netscape's LDAP handled it nicely.
There are four classes in the package :
JndiRealm and LdapRealm are for Tomcat 3.2x
JndiRealmCatalina and LdapRealmCatalina for Tomcat 4.0
className="com.peacetech.webtools.tomcat.JndiRealm" JNDI TOMCAT 3.2x
className="com.peacetech.webtools.tomcat.JndiRealmCatalina" JNDI TOMCAT 4.0
className="com.peacetech.webtools.tomcat.LdapRealmCatalina" LDAP TOMCAT 4.0
className="com.peacetech.webtools.tomcat.LdapRealm" LDAP TOMCAT 3.2x
Jndi/LdapRealm uses searchBindDN and searchBindCredentials to connect to a directory.
Then it looks for exactly one user name matching searchFilter in searchBaseContext
scoped by searchScopeAsString (values are "base", "one", "sub" according to LDAP URL rules)
If one and only one matching directory object is found it will use this object and
tomcat supplied credentials to authenticate the user.
If successful Realm will fetch user roles using JNDI attributes listed in securityAttributes
(comma separated directory attribute names). If attributesReadByOwner = "true" Realm will use
authenticated user itself to pool the attributes from directory otherwise it will use searchBindDN
to retrieve the attributes.
If roleMapperClass is specified Realm will use it to map user roles onto application roles
specific for each web context for tomcat 3.2x and specific for each defined Realm for tomcat 4.2.
Provided SimpleRoleMapper implementation will read role map from either roleMapperSourceUrl
(if specified) or for tomcat 3.2x from WEB-INF/role-map.xml file in each web context
if no roleMapperSourceUrl was defined (if WEB-INF/role-map.xml file does not exist in a context
no mapping for this context will occur)
PARAMETERS:
jndiInitialContextFactory = "com.sun.jndi.ldap.LdapCtxFactory"
(or "com.netscape.jndi.ldap.LdapContextFactory")
This attribute for JndiRealm ONLY.
It corresponds to javax.naming.Context.INITIAL_CONTEXT_FACTORY
directoryUrl = "ldap://207.176.93.66:389"
This attribute for both JndiRealm and LdapRealm.
It corresponds to javax.naming.Context.PROVIDER_URL
jndiSecurityAuthentication = "simple"
This attribute for JndiRealm ONLY.
It corresponds to javax.naming.Context.SECURITY_AUTHENTICATION
jndiSecurityProtocol = "" ("" vendor default or "ssl", or vendor specific)
This attribute for JndiRealm ONLY.
It corresponds to javax.naming.Context.SECURITY_PROTOCOL
searchBindDN = "cn=ldap-user,o=pti"
This attribute for both JndiRealm and LdapRealm. User name to bind to directory
a to perform user name lookups. It corresponds to javax.naming.Context.SECURITY_PRINCIPAL
searchBindCredentials = "mypassword"
This attribute for both JndiRealm and LdapRealm. Password for searchBindDN
It corresponds to javax.naming.Context.SECURITY_CREDENTIALS
searchBaseContext = "o=pti"
Base context for user lookups
ldapVersion = "3"
This attribute for LdapRealm ONLY. Defines LDAP version.
searchScopeAsString = "base" | "one" | "sub"
defines search scope "base" - object scope, "one" - one level scope, "sub" - subtree scope.
attributesReadByOwner = "true"
defines who will read securityAttribures from the directory. If "true" authenticating user account
will be used to retrieve the roles otherwise the searchBindDN account used for user name lookups will
fetch the attributes. It is useful when either one or the other do not have permission to read the
attributes so you can chose the one which has this permissions
searchFilter = "cn={0}"
Filter to lookup authorizing user. Support java.text.MessageFormat.
The only parameter is to java.text.MessageFormat pattern authorizing username.
i.e. jndiSearchFilter = "cn={0}" for user alex will result in lookup for "cn=alex"
securityAttributes = "securityEquals"
One or more directory attributes separated with semicolon which contains security roles
attributes can be multivalued. If blank no attempt to retrieve roles from directory will be done
r
NullPointerException in Catalina StandardClassLoader when JAR with no manifest is added to one of the lib directories
NullPointerException in Catalina StandardClassLoader when JAR with no manifest is added to one of the lib directories Adding manifest to the jar fixes the problem D:\java\apache\tomcat4\bin>catalina runUsing CLASSPATH: d:\java\apache\tomcat4\bin\bootstrap.jar;c:\java\jdk\lib\tools.jarjava.lang.NullPointerException at org.apache.catalina.loader.Extension.getAvailable(Extension.java:300) at org.apache.catalina.loader. .addRepositoryInternal(StandardClassLoader.java:1133) at org.apache.catalina.loader.StandardClassLoader.(StandardClassLoader.java:219) at org.apache.catalina.startup.Bootstrap.createCatalinaLoader(Bootstrap.java:328) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:121)Exception in thread "main" java.lang.IllegalArgumentException: addRepositoryInternal: java.lang.NullPointerException at org.apache.catalina.loader.StandardClassLoader.addRepositoryInternal(StandardClassLoader.java:1145) at org.apache.catalina.loader.StandardClassLoader.(StandardClassLoader.java:219) at org.apache.catalina.startup.Bootstrap.createCatalinaLoader(Bootstrap.java:328) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:121)D:\java\apache\tomcat4\bin>
JndiRealm for Tomcat 4.0 and 3.2x alpha2 is available
Title: JndiRealm for Tomcat 4.0 and 3.2x alpha2 is available
JndiRealm for Tomcat 3.2 and Tomcat 4.0 readme:
http://www.peacetech.com/java/files/apache/tomcat/jndi-auth.html
JndiRealm for Tomcat 3.2 and Tomcat 4 Alpha 2 download:
http://www.peacetech.com/java/files/apache/tomcat/jndi_auth_alpha2.jar
(Please use java jar or zip utility to extract files)
I would greatly appreciate your feedback
Alex Roytman
[EMAIL PROTECTED]
className="com.peacetech.webtools.tomcat.JndiRealm"
debug="1"
JNDI_INITIAL_CONTEXT_FACTORY = "com.sun.jndi.ldap.LdapCtxFactory"
JNDI_PROVIDER_URL = "ldap://207.176.93.66:389"
JNDI_SECURITY_AUTHENTICATION = "simple"
JNDI_SECURITY_PRINCIPAL = "cn=ldap-user,o=pti"
JNDI_SECURITY_CREDENTIALS = "mypassword"
JNDI_SECURITY_PROTOCOL = ""
jndiInitialContext = "o=pti"
jndiSearchFilter = "cn={0}"
jndiRolesAttributes = "securityEquals"
contextDirMaxPoolSize = "20"
roleMapperClass = "com.peacetech.webtools.tomcat.SimpleRoleMapper"/>
debug="1"
JNDI_INITIAL_CONTEXT_FACTORY = "com.sun.jndi.ldap.LdapCtxFactory"
JNDI_PROVIDER_URL = "ldap://207.176.93.66:389"
JNDI_SECURITY_AUTHENTICATION = "simple"
JNDI_SECURITY_PRINCIPAL = "cn=ldap-user,o=pti"
JNDI_SECURITY_CREDENTIALS = "mypassword"
JNDI_SECURITY_PROTOCOL = ""
jndiInitialContext = "o=pti"
jndiSearchFilter = "cn={0}"
jndiRolesAttributes = "securityEquals"
contextDirMaxPoolSize = "20"
roleMapperClass = "com.peacetech.webtools.tomcat.SimpleRoleMapper"
roleMapperSourceUrl="file:///z:/Projects/Gao/gwiz/web/gwiz/WEB-INF/role-map.xml" />
[CONTRIBUTION] JndiRealm for Tomcat. LDAP Authentication via JNDI is Available
Title: [CONTRIBUTION] JndiRealm for Tomcat. LDAP Authentication via JNDI is Available JndiRealm for Tomcat Please download ALPHA version of JndiRealm (compiled and source code) from http://peacetech.com/java/files/apache/tomcat/jndi-auth.html JndiRealm authenticates and Authorizes users against JNDI. It was developed and tested against LDAP JNDI (Sun's and Netscape's jndi provider) JndiRealm looks for exactly one user name matching jndiSearchFilter + usename in entire subtree of jndiInitialContext and use tomcat supplied credentials to authenticate. If succesful, it will fetch user roles using JNDI attributes listed in jndiRolesAttributes and if roleMapperClass is specified it will use it to map user roles onto application roles specific for each web context. Provided SimpleRoleMapper implementation will read WEB-INF/role-map.xml file in each web context and will do mappings accordingly JndiRealm works a little bit different from SimpleRealm or JdbcRealm. They extract user/password from user Session for Form based authentication (from headers for Basic authentication) and then for *every request* perform authentication and authorization. This however might be a problem if password on backend changes constantly. Password cached in User Session Cached or Request Header will expire in lets say 15 second and any subsequent attempt to get user roles from directory One solution to the problem would be to cache all authentication/authorization info in user session (as tomcat already already doing with username and password for form based authentication) and use it as a poof of successful authentication for all subsequent request. I am not very familiar with Tomcat's security infrastructure so it would be nice if somebody from tomcat team take a look in my source code If it proves to be useful I will port it to tomcat 4 Alex Roytman For samples, please see tomcat/conf/server.xml and WEB-INF/role-map.xml files in the distribution
RE: Tomcat Security Architecture and RSA ACE authentication
Title: RE: Tomcat Security Architecture and RSA ACE authentication -Original Message- From: Roytman, Alex Sent: Monday, March 26, 2001 1:38 PM To: '[EMAIL PROTECTED]' Subject: RE: Tomcat Security Architecture and RSA ACE authentication Craig, Thank you for such a prompt reply I will be glad to contribute my code as soon as I resolve the issue I outlined. If I can store authentication/authorization info in users session then my staff is a little bit to complicated for the task in hand. I was trying to accommodate tomcat3.x architecture and not to store security info in user session so I developed special cache for LDAP data which expires after specified time (let say every 5 minutes) which causes re-authentication and refetching user roles from LDAP If we cache security info in user session all this LDAP caching staff would be useless Could tomcat 3.x guys comment on this please? Alex -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Monday, March 26, 2001 1:28 PM To: '[EMAIL PROTECTED]' Subject: Re: Tomcat Security Architecture and RSA ACE authentication On Mon, 26 Mar 2001, Roytman, Alex wrote: > Hello, > > I wrote JNDI(LDAP) realm for tomcat 3.x based similar to JDBCRealm provided > with tomcat Would you be interested in contributing this code to the Tomcat 3 (and/or 4) code bases? > My client is going to adopt RSA ACE security infrastructure which to my > understanding will require users to append a hardware generated number to > their passwords when they authenticate. So we will have system where > password changes every 15 seconds and it can not be cached in tomcat and > used for subsequent accesses to LDAP (unless your software is RSA ACE aware > and can deal with it somehow) > (- I am not really familiar with RSA ACE security so I might be missing > something here -) > > If I understand correctly, tomcat 3.x has following security architecture: > 1. Extract user/password from user Session for Form based authentication > (from headers for Basic authentication) > 2. For *every request* perform authentication and authorization > > This might be a problem if password on backend changes constantly. Cached > password will expire in lets say 15 second and that will break tomcat's > security > > One solution to the problem would be to cache all > authentication/authorization info in user session (you already caching > username and password for form based authentication there) and use it as a > poof of successful authentication for all subsequent request. > > Do you see any problems with this approach? > > Does tomcat4 security architecture handles this better? > In Tomcat 4.0, if you are running under a session (which is automatic if you use form-based login), the user principal object retrieved from the Realm is cached in the Session the first time that it is authenticated, so the Realm is consulted only once. This sounds to me like it operates in exactly the way you are proposing. In 3.x, it should be conceptually feasible to do the same thing -- I don't know that code base well enough (at the moment) to know whether this would require modification to the session implementation object or not. Craig
Tomcat Security Architecture and RSA ACE authentication
Title: Tomcat Security Architecture and RSA ACE authentication Hello, I wrote JNDI(LDAP) realm for tomcat 3.x based similar to JDBCRealm provided with tomcat My client is going to adopt RSA ACE security infrastructure which to my understanding will require users to append a hardware generated number to their passwords when they authenticate. So we will have system where password changes every 15 seconds and it can not be cached in tomcat and used for subsequent accesses to LDAP (unless your software is RSA ACE aware and can deal with it somehow) (- I am not really familiar with RSA ACE security so I might be missing something here -) If I understand correctly, tomcat 3.x has following security architecture: 1. Extract user/password from user Session for Form based authentication (from headers for Basic authentication) 2. For *every request* perform authentication and authorization This might be a problem if password on backend changes constantly. Cached password will expire in lets say 15 second and that will break tomcat's security One solution to the problem would be to cache all authentication/authorization info in user session (you already caching username and password for form based authentication there) and use it as a poof of successful authentication for all subsequent request. Do you see any problems with this approach? Does tomcat4 security architecture handles this better?
RE: RequestInterceptor authenticate and authorize. Need advise
>Tomcat 4.0 caches the authenticated principal in the current session (if
there
>is one) -- otherwise, it authenticates on every request. I don't believe
that
>this feature got back-ported to 3.2.
I tested it does not cache it in 3.2
>>
>> Is user principal container wide or context wide?
>>
>For 3.2, it's container-wide. For 4.0, it depends on where you define the
> element -- you can make it webapp-wide, virtual-host-wide, or
>container-wide.
May be I should rephrase my question - when user authenticated first time
the fact of authentication and user's name/password/roles are the same
across all contexts, does authentication for one context mean authentication
for all or each context should authenticate separately?
Reason why I am asking is that I could not find any context specific code in
SimpleRealm/JDBCRealm and there is only one tomcat-users.xml file which is
container wide
-Original Message-
From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, January 24, 2001 6:10 PM
To: [EMAIL PROTECTED]
Subject: Re: RequestInterceptor authenticate and authorize. Need advise
"Roytman, Alex" wrote:
> Hello,
>
> As I understand, RequestInterceptor.authenticate() and authorize() get
> called every time a protected resource is being accessed. Does it mean
> tomcat do not cache user/roles after first authentication?
>
Tomcat 4.0 caches the authenticated principal in the current session (if
there
is one) -- otherwise, it authenticates on every request. I don't believe
that
this feature got back-ported to 3.2.
>
> Should I perform actual authentication every time (which is awfully
resource
> consuming) or could I assume that if (request.getRemoteUser() != null)
user
> has been authenticated.
>
> something like this:
> if (request.getRemoteUser() == null) {
> //perform authentication
> }
>
> the same question with authorize. What is the best way to handle it. Can I
> cache roles using request.getRemoteUser() as a key?
>
You want to do something like this, in case some previous interceptor (or
the
Apache connector) did the authentication -- but if you're running Tomcat
standalone, for example, you'll find that getRemoteUser() is never going to
be
set (unless 3.2 really does cache and I've just got amnesia about it :-),
because your interceptor is the only place it will ever get set.
>
> Is user principal container wide or context wide?
>
For 3.2, it's container-wide. For 4.0, it depends on where you define the
element -- you can make it webapp-wide, virtual-host-wide, or
container-wide.
>
> Thank you very much in advance
>
> Alex Roytman
>
Craig McClanahan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
RequestInterceptor authenticate and authorize. Need advise
Hello,
As I understand, RequestInterceptor.authenticate() and authorize() get
called every time a protected resource is being accessed. Does it mean
tomcat do not cache user/roles after first authentication?
Should I perform actual authentication every time (which is awfully resource
consuming) or could I assume that if (request.getRemoteUser() != null) user
has been authenticated.
something like this:
if (request.getRemoteUser() == null) {
//perform authentication
}
the same question with authorize. What is the best way to handle it. Can I
cache roles using request.getRemoteUser() as a key?
Is user principal container wide or context wide?
Thank you very much in advance
Alex Roytman
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Xalan2 in server environment (was Xalan2 Stree Module spans second thread to do transform?)
Scott, Thank you very much for your reply. One part which is sensitive to thread origin in my opinion is Extensions In extensions people can do all sorts of things. I am not very experienced with EJB implementation but I can imagine that many things (transactional context, bean environment, etc.) depend on threads and some static variables which helps with setting /switching context for beans being managed by the server. Example: in J2EE it is recommended to create JNDI initial context using default constructor InitialContext(). The result of the instantiation depends on the context where it was executed and the context is set by the server for the thread on which your component is running. So if you call new InitialContext() in your extension (in sql extension to get JDBC DataSource for example ) it might fail. Do extension run on the second (created by Xalan) thread? I will forward your message to Tomcat news group lets see what Tomcat developers think. Alex -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Saturday, January 06, 2001 11:39 PM To: [EMAIL PROTECTED] Subject: Re: Xalan2 Stree Module spans second thread to do transform? > In many > cases component should not attempt to create its own threads. > For example thread's ContextClassLoader or ThreadLocal variables might need > to be initialized by the server. > Also it defeats thread pooling done by the server etc. > > Could you please comment on this issue Yeah, I've been a bit worried about this. However, I've not yet heard of any problems that have been caused by it, and XalanJ1 has long had a two threaded system (though not as effective as in XalanJ2). Ultimately, I would rather use a pull model for this, and only have one thread, but a) there is no standard "pull" API for XML parsers, and b) this doesn't work anyway when SAX events are used, for whatever reason. I'm open to any input to how Xalan might request the thread from the servlet environment, though it has to be able to be run outside a servlet environment too. Also, it would be good if someone with deep knowledge of EJB's and the like could comment. I talked this over in a hallway conversation with someone who is fairly familiar with EJB's, and he didn't think there was a problem, though I forget why. It seems insane/crazy to me that a component can't use a thread in it's internal modules. -scott "Roytman, Alex" To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]> Subject: Xalan2 Stree Module spans second thread to do transform? 01/06/2001 10:48 PM Please respond to xalan-dev Dear Xalan developers, I have a question about using upcoming Xalan2 in server env. In Xalan2 design specs it is said: "The Stree module implements the default Source Tree for Xalan, that is to be transformed. It implements read-only DOM2 interfaces, and provides some information needed for fast transforms, such as document order indexes. It also attempts to allow a streaming transform by launching the transform on a secondary thread as soon as the SAX2 StartDocument event has occurred." In server environment server usually controls threads creation. In many cases component should not attempt to create its own threads. For example thread's ContextClassLoader or ThreadLocal variables might need to be initialized by the server. Also it defeats thread pooling done by the server etc. Could you please comment on this issue Thank you very much in advance Alex Roytman - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Xalan2 in server environment (was Xalan2 Stree Module spans second thread to do transform?)
Yeah, I've been a bit worried about this. However, I've not yet heard of any problems that have been caused by it, and XalanJ1 has long had a two threaded system (though not as effective as in XalanJ2). Ultimately, I would rather use a pull model for this, and only have one thread, but a) there is no standard "pull" API for XML parsers, and b) this doesn't work anyway when SAX events are used, for whatever reason. I'm open to any input to how Xalan might request the thread from the servlet environment, though it has to be able to be run outside a servlet environment too. Also, it would be good if someone with deep knowledge of EJB's and the like could comment. I talked this over in a hallway conversation with someone who is fairly familiar with EJB's, and he didn't think there was a problem, though I forget why. It seems insane/crazy to me that a component can't use a thread in it's internal modules. -scott Dear Xalan developers, I have a question about using upcoming Xalan2 in server env. In Xalan2 design specs it is said: "The Stree module implements the default Source Tree for Xalan, that is to be transformed. It implements read-only DOM2 interfaces, and provides some information needed for fast transforms, such as document order indexes. It also attempts to allow a streaming transform by launching the transform on a secondary thread as soon as the SAX2 StartDocument event has occurred." In server environment server usually controls threads creation. In many cases component should not attempt to create its own threads. For example thread's ContextClassLoader or ThreadLocal variables might need to be initialized by the server. Also it defeats thread pooling done by the server etc. Could you please comment on this issue Thank you very much in advance Alex Roytman - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Thread.currentThread().setContextClassLoader() [was: ServletContext.getResourceAsStream() in 3.2?]
Tomcat developers, please correct me if I am wrong but as far as I know
Tomcat 3.2 does not set ContextClassLoader for its threads. So you are using
main class loader which knows nothing about your WEB-INF/lib
I had a different problem - when code loaded by main classloader need to
load classes from WEB-INF/lib. I solved it by writing request and context
interceptors for tomcat to call
Thread.currentThread().setContextClassLoader() for each thread before it
touches a servlet (doing init/destroy or serving request)
-Original Message-
From: Sean Dowd [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, December 12, 2000 10:12 AM
To: [EMAIL PROTECTED]
Subject: Re: ServletContext.getResourceAsStream() in 3.2?
> If you want to load a file that is under WEB-INF, you don't need to
involve the
> class loader at all. Simply use:
>
>InputStream is =
>
getServletContext().getResourceAsStream("/WEB-INF/myprops.properties");
Cool. That works (missed the part about relative to the context
directory
in the javadoc).
But now I'm back to the classloading issue. I'm trying to use JNDI and
the
call to load the factory class is failing. The JNDI code is doing
something
like this to load the factory:
String className = "com.netscape.jndi.ldap.LdapContextFactory";
try
{
// this works
// Class c = Class.forName( className );
// this does not
ClassLoader loader =
(java.lang.ClassLoader)java.security.AccessController.doPrivileged(new
java.security.PrivilegedAction() {
public java.lang.Object run()
{
return java.lang.Thread.currentThread().getContextClassLoader();
}
});
Class c = java.lang.Class.forName(className, true, loader);
log( "Class " + className + " loaded." );
}
catch ( Exception e )
{
log( "Error loading class " + className + ": " + e );
return;
}
I'm seeing a ClassNotFoundException but the jar is definitely in
WEB-INF/lib
and definitely contains com.netscape.jndi.ldap.LdapContextFactory.
RE: HANDLER THREAD PROBLEM: Stream closed prematurely
If you are running Tomcat standalone I would suggest to try it with Apache web server. We had some problems with tomcat built in web server - POST input stream would only give you first 1300 bytes of POST data and some other problems I do not remember. I believe apache inherited it from Sun Web server which had these problems. However all these problems were not present when we access tomcat via Apache web server Alex -Original Message- From: Ritwick Dhar [mailto:[EMAIL PROTECTED]] Sent: Friday, November 24, 2000 11:35 AM To: '[EMAIL PROTECTED]' Subject: HANDLER THREAD PROBLEM: Stream closed prematurely Hi, This problem is driving me nuts. I've tried debugging this, but nothing yet. I was hoping someone on this list will have come accross this before. Case: I have a servlet (server) that accepts POST requests (content-type= application/x-ofx), and sends back a OFX response. I have another servlet (client), that opens a URL to the server, writes the request, and reads the reponse. Simple. The problem is, the moment the client tries to call 'urlConn.getInputStream()' to get an inputstream from the server, I get this (on the server console): HANDLER THREAD PROBLEM: java.io.IOException: Stream closed prematurely java.io.IOException: Stream closed prematurely at java.lang.Throwable.(Compiled Code) at java.lang.Exception.(Compiled Code) at java.io.IOException.(Compiled Code) at org.apache.tomcat.service.connector.AJP12RequestAdapter.readNextRequest(Comp iled Code) at org.apache.tomcat.service.connector.Ajp12ConnectionHandler.processConnection (Compiled Code) at org.apache.tomcat.service.TcpConnectionThread.run(Compiled Code) at java.lang.Thread.run(Compiled Code) What's really driving me up the wall is that this works perfectly fine with Both WebSphere and JRun. Is this something particular to Tomcat?? Thanks for all help Rit
Thread.currentThread().getContextClassLoader() in Tomcat 3.2
I would like to use Thread.currentThread().getContextClassLoader() with
Tomcat 3.2 to resolve one common problem when class from system classpath
needs to call something loaded by tomcat context's loader. As far as I
understand Tomcat 3.2 suppose to run under jdk1.1 so it does not do
Thread.currentThread().setContextClassLoader() before it hands control to a
Servlet.
Below are my interceptors I use for
Thread.currentThread().setContextClassLoader() and setting scope of jndi to
make it tomcat context specific.
I wonder if someone with more knowledge on tomcat internal could possibly
comment on this approach. Is it right approach? is it safe? What if someone
in another interceptor will do something else to
Thread.currentThread().contextClassLoader?
Your feedback is greatly appreciated
Alex
Request Interceptor:
public int preService(Request request, Response response) {
Thread.currentThread().setContextClassLoader(request.getContext().getServlet
Loader().getClassLoader());
HierInitCtxFactory.selectScope(request.getContext().getPath());
return 0;
}
public int postService(Request request, Response response) {
HierInitCtxFactory.selectScope(null);
Thread.currentThread().setContextClassLoader(getClass().getClassLoader());
return 0;
}
ContextInterceptor:
public void preServletInit(Context ctx, ServletWrapper sw) throws
TomcatException {
Thread.currentThread().setContextClassLoader(ctx.getServletLoader().getClass
Loader());
HierInitCtxFactory.selectScope(ctx.getPath());
}
public void postServletInit(Context ctx, ServletWrapper sw) throws
TomcatException {
HierInitCtxFactory.selectScope(null);
Thread.currentThread().setContextClassLoader(getClass().getClassLoader());
}
Form Authentication inconsistency
Hello, Unless I missed something I believe there is a deficiency in Form Authentication mechanism. Which does not let us to protect entire context: When protected resource is entire context: /* tomcat enters endless loop trying to call login form FORM Example Form-Based Authentication Area /login/login.jsp /login/error.jsp I believe tomcat should call login forms without security checks. But it looks like it is not the case. Also, I don't know of any URL pattern which allows to exclude certain patterns so what is a solution. Any help is greatly appreciated Alex
ContextInterceptor.removeContext() does not get fired for all contexts (3.2b6) BUG?
Hello, I was struggling with my interceptors trying to figure out why all resources do not get freed up and then I realized that ContextInterceptor.removeContext() does not get consistently fired for every registered context. When I print list of all contexts from ContextManager in engineShutdown() it shows all contexts for which removeContext() was not fired. I suspect they do not get removed somehow. I also noticed that when tomcat shutdowns it prints "Removing context Ctx( /irg )" but not for ALL registered contexts (even without my interceptor) I also attaching my previous message about multiple invocation of a interceptor when the same class implements both RequestInterceptor and ContextInterceptor The ContextInterceptor.addContext() gets fired twice.
Context Interceptor gets fired multiple times (3.2b6)
I have a class which implements both ContextInterceptor and RequestInterceptor. The ContextInterceptor.addContext() gets fired twice.
Tomcat & JNDI
I am trying to tie Tomcat with JNDI to use J2EE pattern to obtain resources:
Context context = new InitialContext();
dataSource = (DataSource)context.lookup("java:comp/env/jdbc/myDataSource");
(I know Tomcat team is planning to have it for Tomcat 4 eventually)
I have my own little in memory JNDI implementation with support for
java:comp URLs
and it works fine but provides one global JNDI for all contexts defined in
server.xml while it should be context specific. Basically the problem is how
to make InitialContext() tomcat context aware (to be precise to make my
java:comp namespace to start from different roots depending on where
InitialContext was created).
If AdaptiveClassLoader had some context info in it I could get it from there
while creating InitialContext.
Any ideas are greatly appreciated
Alex
Tomcat & JNDI
I am trying to tie Tomcat with JNDI to use J2EE pattern to obtain resources:
Context context = new InitialContext();
dataSource = (DataSource)context.lookup("java:comp/env/jdbc/myDataSource");
(I know Tomcat team is planning to have it for Tomcat 4 eventually)
I have my own little in memory JNDI implementation with support for
java:comp URLs
and it works fine but provides one global JNDI for all contexts defined in
server.xml while it should be context specific. Basically the problem is how
to make InitialContext() tomcat context aware (to be precise to make my
java:comp namespace to start from different roots depending on where
InitialContext was created).
If AdaptiveClassLoader had some context info in it I could get it from there
while creating InitialContext.
Any ideas are greatly appreciated
Alex
