Hi,
as far as I know, there is only one possible way to use form based
authentication with Tomcat:
- sending a request to a restricted site
- getting the login form instead
- logging in and getting the restricted site
However, the following scenario seems more common in web applications:
-
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14281.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14281.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14281.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
break down the problem, to the combination of my hostage enviroment and the
introspection setting of sSLImplementation in the CoyoteConnector. Some
additional information is that i use tomcat as complete http server (
external ports 80/443) without root rights and priviliges.
Now my
Torsten Fohrer wrote:
break down the problem, to the combination of my hostage enviroment
and the
introspection setting of sSLImplementation in the CoyoteConnector. Some
additional information is that i use tomcat as complete http server (
external ports 80/443) without root rights and
Henri Gomez wrote:
In o.a.c.loader.WebAppClassLoader.java, realFile.toURI() isn't known by
SDK 1.3.1 ..
I didn't pay attention when I wrote the code. This method is extremely
useful for properly URL encoding the result. It will have to be
rewritten with 1.3 compatibility (I suppose the code
I dislike this option immensely. It's entirely contrary to what JSPC is for.
It's a tool for generating servlets from JSP that do not require the entire
JSP machinery. It produces a web.xml file that maps each jsp page to the
generated servlet. The generated servlets are portable between
It's better to look at it as a compiler. It's output happens to be java, but
it acts a whole lot more like a compiler than a precompiler. Precompilers are
usually more like macro preprocessors.
On Friday 08 November 2002 07:05 am, John Trollinger wrote:
I have to disagree with this, jspc is a
On Friday 08 November 2002 03:28 pm, Hans Bergsten wrote:
Glenn Nielsen wrote:
Remy Maucherat wrote:
[...]
I agree that JSPC needs to be simplified and that the webapp mode should
be retained. But the webapp mode should allow for a war file to be
generated
which is self contained
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14436.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Based on problems reported by users of JSPC Remy made a proposal
to deprecate it.
This resulted in a number of people responding that they used JSPC
and strongly felt it should be kept.
There did seem to be some consensus that JSPC could beneifit from
a review and refactoring to make it easier
- Original Message -
From: Glenn Nielsen [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Sunday, November 10, 2002 9:44 PM
Subject: JSPC refactoring/documentation
Based on problems reported by users of JSPC Remy made a proposal
to deprecate it.
This resulted in a number of people
13 matches
Mail list logo
