Modify the startup script for tomcat so that the java.awt.headless system
property is set
to true.
Example:
java -Djava.awt.headless=true -cp $CLASSPATH $MAINCLASS
This will tell the Java virtual machine to use a non-X11 toolkit for images
etc.
- Original Message -
From: "Micael Padra
Hi,
It sounds like the Java keystore file that was created was somehow damaged.
Try using the JDK keytool utility to have a look inside it, or try using the
GUI version of keytool available at:
http://southgatesoftware.com/products/sskeytool/download/download.html
to have a look at your Java keys
Hi Roland,
As far as I understand tomcat/ssl/openssl and java's keystore, you need to
do the following:
1. Generate a private key/self-signed certificate pair in a keystore file
(mykeys.jks for example)
and give it an alias ("tomcat" for example)
2. Export a certificate signing request (CSR) for
I think you can do what you want by simply creating your own
subclass/implementation
of HttpServletRequest and HttpServletResponse to pass to the
service() method of your servlet (or whatever the equivalent is for JSPs)
Just make sure that the HttpServletResponse.getOutputStream() returns
the Fil
I could be being naive on this one, but I've always loaded property files
and
other resources by putting them in the
WEB-INF/classes directory of my class path, then doing something like:
InputStream istr=getClass().getResourceAsStream("/myprops.properties");
Properties props=new Properties();
pr
Hi Costin,
What about modifying mod_jk so that it can dynamically load .so files (or
.dll on windows)
that export well-known method names, so that one doesn't need to recompile
mod_jk
to add different functionality/protocols etc.
?
-Mike
- Original Message -
From: <[EMAIL PROTECTED]>
To
Hi everyone,
I'm working on a project for a client that involves a servlet engine component. I
suggested tomcat
since I am most familiar with it and it seems the most compliant servlet engine around.
My client has mentioned concerns about tomcat's performance and now is insisting on
using IBM we
glaring problems with the modifications, please
let me know and I'll try and fix it.
-Mike Jennings
- Original Message -
From: "Michael Jennings" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Friday, November 0
ative.
>
> Of course, all rules have exceptions - but it is extremely painfull to
> merge and track 2 codebases.
>
> Costin
>
>
> On Fri, 2 Nov 2001, Michael Jennings wrote:
>
> > If anyone sees any glaring problems with the following modification to
> >
ect: RE: Does anyone see anything wrong with this fix?
> It isn't a matter of how the '*' is interpreted, but that
> mod_jk will put a null terminator following the '*' if the
> next character isn't a '.'. Thus:
>
>JkMount /*something ...
, so it was removed from Tomcat 3.3. It may still
> get implemented in the jakarta-tomcat-connectors version
> of mod_jk, assuming a better approach doesn't present itself.
>
> Larry
>
> > -Original Message-
> > From: Michael Jennings [mailto:[EMAIL PROTECTED]
rite a mod_jk.conf similar to that of Tomcat 3.2.x,
> but with additional mappings. These additional mappings for
> the context will include one like the following:
>
> JkMount /examples/jsp/security/login/j_security_check ajp13
>
> If you want "j_security_check" to
2.4 before the final release.
>
>
> Marc Saegesser
>
> > -Original Message-
> > From: Michael Jennings [mailto:[EMAIL PROTECTED]]
> > Sent: Thursday, November 01, 2001 10:51 AM
> > To: [EMAIL PROTECTED]
> > Subject: Can someone commit this minor
As far as I know, that is a problem with Internet Explorer closing the
socket
prematurely on an http request.
Try hitting your servlet or JSP with a java.net.URL object
and see if you get the same error. Also try with Netscape.
My guess is that this "bug" is just how tomcat deals with
clients that
As far as I can tell, the following modification to the ApacheConfig.java class will
enable form-based authentication to work for people using mod_jk.conf-auto
with Apache.
mod_jk needs to be told to handle requests of the form
"/webapproot/somedir/j_security_check"
since a login.jsp page (for
The following fix enables form-based authentication to work with
Apache + Tomcat.
Can someone add this to tomcat 3.2?
Thanks!
-Mike Jennings
Index: jakarta-tomcat/src/share/org/apache/tomcat/task/ApacheConfig.java
===
RCS file:
/h
The following fix enables form-based authentication to work with
Apache + Tomcat.
Can someone add this to tomcat 3.2?
Thanks!
-Mike Jennings
Index: jakarta-tomcat/src/share/org/apache/tomcat/task/ApacheConfig.java
===
RCS file:
/ho
Bonjour!
When I was trying to get mod_jk to work I had to pass a parameter to GCC:
gcc -shared -lposix4 -o mod_jk.so *.o
To tell it to link in the correct library.
What compiler are you using? Is it GCC? If so, what version?
I would try commenting out code until you get a .so file
that does not
So the redirection thing is just how it is implemented right now.
Stupid me.
-Mike
- Original Message -
From: "Michael Jennings" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, June 21, 2001 2:21 PM
Subject: Re: FORM-based authentication idea
> >
> It's kinda hard for them to bookmark the login page when they don't know
> the URL.
>
> Keep in mind that, as far as the browser is concerned, the URL in the
> location is still the page that was originally requested. Therefore, a
> bookmark for the login form will actually be to the real page
> Why is the button there at all? There should be zero linkages to the
> login page from *anywhere* in your user interface.
That's true. The point I was trying to make is that there is nothing to
stop an end-user from bookmarking a login page or typing it in
directly, even if you have no linkag
> The best way to think about form-based login is like this:
>
> * The login page is (in essence) part of the container,
> not the application. Therefore, ...
>
> * The login page should *never* be referenced directly by any
> other application page, and ...
>
> * The login page should *never
> I would simply be a little bit leary of extending the web.xml file
> format beyond what the spec states, given that Tomcat is the official
> reference implementation. My feeling would be to change the internal
> behavior of the problem you point out to be handled a bit more
> elegantly, rather t
> FWIW, I guess I could see some small convenience in a target-fail and
> target-succeed context parameter. I guess I if I had multiple entry
> points into my application, such as a more complex manual authentication
> routine within a different application or something, I could also grab
> these
> > The alternative is to look for the presence of a session variable called
> > "tomcat.auth.originalLocation"
> > and set up a default from within the login page if that session variable
> > isn't there.
> >
> > Any thoughts?
>
>
> Why not supply the default in a hidden field on the login page?
Hi everyone,
I just wanted to bounce an idea off of everyone. In tomcat, when one
specifies form-based
authentication you have to tell tomcat which page is the login page. This is
done
via the context's web.xml file by setting the property
under the
section. When a user hits a protected URL in
.0...
Saludos ,
Ignacio J. Ortega
> -----Mensaje original-
> De: Michael Jennings [mailto:[EMAIL PROTECTED]]
> Enviado el: miércoles 6 de junio de 2001 17:56
> Para: [EMAIL PROTECTED]
> Asunto: per-context realms
>
>
> Hi everyone,
>
> Does anyone have an idea of h
Thanks!
That is EXACTLY what I was looking for!
-Mike
- Original Message -
From: "Antony Bowesman" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, June 06, 2001 10:39 PM
Subject: Re: per-context realms
> Michael Jennings wrote:
> >
> &
Hi everyone,
Does anyone have an idea of how I could go about implementing
realms/authentication on a per-context basis?
Ideally, what I would like to do is have each context control
their users and roles. Where should I look to get a clue?
-Mike
__
Mike Jennings
Southgate
Sounds like a VERY cool idea!
What kind of database structure do you use? I know that ColdFusion
and PHP both have the capability to store their session info in a database,
do you know what schema they use? If your code can use the same
schema as PHP or ColdFusion, then one could conceivably use
Antony Bowesman wrote:
> >
> > Andy Armstrong wrote:
> > >
> > > Michael Jennings wrote:
> > > >
> > > > Thanks for the feedback!
> > > >
> > > > Does tomcat 3.2.2 currently support JAAS?
> > >
> > > Not in
ess what JAAS does? There are a number of JAAS
> modules at http://free.tagish.net/ that implement among other things a
> JDBC Authentication provider.
>
> Michael Jennings wrote:
> >
> > Hi everyone,
> >
> > Just for my own education, I decided to write my own
au
Hi everyone,
Just for my own education, I decided to write my own authentication-stuff
for tomcat 3.2.2
To that end I wrote a Request Interceptor that takes 2 parameters
called "realmProviderClass" and "setupString".
The "realmProviderClass" is the fully-qualified class name of a class which
im
auto file.
-Mike
- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, May 27, 2001 4:11 PM
Subject: cvs commit:
jakarta-tomcat/src/share/org/apache/tomcat/modules/config ApacheConfig.java
> costin 01/05/27 16:11:08
>
> Modified:sr
Hi!
I've made a modification to the ApacheConfig module to enable the
mod_jk.conf-auto to include directives to enable form-based authentication.
Can someone with "commit" privilege commit this change?
Here's the cvs diff:
Index:
jakarta-tomcat/src/share/org/apache/tomcat/modules/config/Apache
35 matches
Mail list logo
