Kyle F. Downey wrote:
> Remy,
>
> Do you happen to know if the patch I submitted for the context
> ClassLoader was ever inspected or merged in? I never saw a reply.
>
Sorry, this was a personal reply not meant for the list.
--kd
Remy,
Do you happen to know if the patch I submitted for the context
ClassLoader was ever inspected or merged in? I never saw a reply.
--kd
Anne Dirkse wrote:
> Douglas --
>
> I am experiencing the exact same set of problems, except that I'm just
> beginning to experience them, so I haven't done any real testing to get
> to the specifics of what is going on and the exact performance
> difference that I am experiencing between Solari
I think there's another place the context ClassLoader should be
set: right before init(ServletConfig) is called. Attached is a
patch that sets the current Thread's ContextClassLoader and then to the
servlet context's ClassLoader and restores it after init() completes.
This ensures that the webapp
I'm working with the latest b4-dev from CVS.
Is there a reason the StandardLoader establishes a URLStreamHandlerFactory
(a precious resource, since you can set it only once) just for the "jndi:"
protocol? If all it's used for is to find the protocol handler, that could
be done less intrusively b
Right on. HTML-in-Java vs. Java-in-HTML is a silly argument AFAIK.
Neither's a very good solution long-term. The Java-in-HTML makes it
near-impossible for designers to collaborate with coders, while the
HTML-in-Java has that problem, plus the code bloat problem (the bytecode
format will choke on
Whoops, thanks for the correction!
--kd
> I just found this under
>
> http://www.lucene.com/
>
> - Paul
>
> > -Original Message-
> > From: Kyle F. Downey [mailto:[EMAIL PROTECTED]]
> > Sent: Wednesday, January 03, 2001 9:55 AM
> > To:
Try http://www.lucene.org. Open source full-text search engine.
--kd
> Hi,
>
> Does tomcat-apache provide site search functionality?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED
>
> Since I'm in your "tinkerer" group because I'm following the Catalina path
> (like we agreed on), I will state that everything in your "conservative"
> group is just as important to me in the "tinkerer" group.
>
> Therefore, your distinct separation of the groups is illogical and moot.
>
Not
>
> If you are in a session, the authenticated principal is actually cached (in a
> private variable inside the Session object). If you are not in a session, Catalina
> has no choice but to authenticate you every time, because it has no way to know
> that the second request came from the same per
I've been following of the TC4.0/TC3.2/TC3.3 threads for a while in
silence, and wanted to make an observation.
The Tomcat project really has two major types of customers: those who
want an open source servlet container for their production needs
("conservatives"), and those interested in the st
Quick question: why does Catalina check with the Realm implementation on
every HTTP request, even after a successful authentication? Is it the
responsibility of the Realm to handle caching and expiring of credentials?
Seems to me that would lead to a good bit of replication of code among
Realm im
As promised, here's the code, plus docs, build.xml, etc..
http://www.amberarcher.com/apache/tomcat_contrib/tomcat_contrib-0.1.zip
Feedback welcome. I probably won't be able to get up HTML docs to
supplement the text docs in the package until after Xmas. I'll set up the
"tomcat_contrib" project
Okay, after a full day's work, I have a working JAASRealm that lets you
use a JAAS LoginModule (or many LoginModules) for authenticating Web
clients. My company's KerberosLoginModule now happily authenticates a user
against our Kerberos 5 KDC from inside Catalina. Jazzy.
This is JDK 1.3-only cod
14 matches
Mail list logo
