How do I configure server.xml for Tomcat to recognize my application directory?
How do I configure server.xml for Tomcat to recognize the following setup? Tomcat is in C:\Program Files\Apache Software Foundation\Tomcat 6.0 The application is in C:\public_html The directory structure of the application is C:\public_html\index.html C:\public_html\WEB-INF\ C:\public_html\WEB-INF\web.xml C:\public_html\META-INF C:\public_html\META-INF\context.xml What should server.xml look like? I tried the following, but it did not work. Upon navigating to "http://localhost"; or "http://localhost/index.html"; the error message is: The requested resource () is not available. It seems the the problem might be the directory structure, and appBase, and docBase. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: How do I configure server.xml for Tomcat to recognize my application directory?
Thanks to everyone. I will try out these suggestions tonight and write back if they do not work. In response to > What is in your webapp's META-INF/context.xml file? It > should not have either the path or the docBase attributes > set. the file contents are as follows (note: no attributes in the Context element) --- On Tue, 11/18/08, Caldarale, Charles R <[EMAIL PROTECTED]> wrote: > From: Caldarale, Charles R <[EMAIL PROTECTED]> > Subject: RE: How do I configure server.xml for Tomcat to recognize my > application directory? > To: "Tomcat Users List" > Date: Tuesday, November 18, 2008, 9:52 AM > > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > > Subject: How do I configure server.xml for Tomcat to > > recognize my application directory? > > > > The application is in > > C:\public_html > > You should put the application in a directory underneath > public_html, not in public_html. If you want it to be the > default webapp, make that directory name ROOT (case > sensitive, even on Windows). > > > The directory structure of the application is > > Move the files to: > C:\public_html\ROOT\index.html > C:\public_html\ROOT\WEB-INF\ > C:\public_html\ROOT\WEB-INF\web.xml > C:\public_html\ROOT\META-INF > C:\public_html\ROOT\META-INF\context.xml > > > It seems the the problem might be the directory > structure, > > and appBase, and docBase. > > Correct; keep reading. > > > appBase="/public_html" > > unpackWARs="true" > autoDeploy="true" > > xmlValidation="false" > xmlNamespaceAware="false"> > > The above is mostly o.k.; appBase specifies the directory > under which each webapp is deployed. However, I would make > it "C:/public_html", just in case you're in a > different drive letter when Tomcat is started. > > > docBase="/public_html"> > > > > This is bad. The docBase attribute must *never* be the > same as appBase, and you should not be placing > elements in server.xml these days. Just > remove the entire element, since it's > not needed. > > What is in your webapp's META-INF/context.xml file? It > should not have either the path or the docBase attributes > set. > > - Chuck > > > THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR > OTHERWISE PROPRIETARY MATERIAL and is thus for use only by > the intended recipient. If you received this in error, > please contact the sender and delete the e-mail and its > attachments from all computers. > > - > To start a new topic, e-mail: users@tomcat.apache.org > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat vs Daemons
In my code, I have a ServletContextListener (configured in web.xml or similar file, don't remember exactly), so when the servlet context is created it calls contextInitialized(ServletContextEvent). In this function I start the daemon threads. There is a function contextDestroyed which you can use to stop the threads (but note Thread.stop is deprecated). It sounds like a good idea to start these background threads in a new process. However, I don't know if you can do this in a hosted web server environment like the kind you find at mochahost.com and dailyrazor.com. Will need to test it out. --- On Tue, 11/18/08, Christopher Schultz <[EMAIL PROTECTED]> wrote: > From: Christopher Schultz <[EMAIL PROTECTED]> > Subject: Re: Tomcat vs Daemons > To: "Tomcat Users List" > Date: Tuesday, November 18, 2008, 1:35 PM > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Nathan, > > Nathan Thatcher wrote: > > I am porting an application from Windows to Linux > which makes heavy use of > > servlets. I have a fairly intensive background process > (currently a windows > > service) that requires no user interaction. I plan to > rewrite the code in > > Java and I am wondering if there is any notable > performance difference > > between running the Java code under Tomcat as opposed > to running the code > > directly as a daemon. > > Not really, but I don't see a compelling reason to run > something under a > servlet container if it doesn't actually need to be > running inside a > servlet container. Is also simplifies testing, deployment, > etc if you > leave it separate. > > > Since the application requires Tomcat, I know I can > > code it up as a servlet and kick off the processing in > the init() function > > and not worry about executing the code directly as a > daemon. > > While this certainly will work (I'm assuming you're > kicking-off a thread > to do this work), it's a pretty big hack ;) > > > Since this is a > > performance sensitive process I want to make sure that > I choose the optimal > > route. > > So, you want to make sure that the process itself gets > enough CPU time? > I think you want to be able to control this process > separately from your > webapps. *NIX has finer-grained levels of process priority > than > Microsoft Windows does (at least, those that are exposed to > the user), > and you can use the program "nice" to run a job > with higher or lower > priority (note there is no "mean" command... you > just use a negative > "niceness" value). > > > Does anybody know how java code running as a servlet > compares > > performance-wise to the same code running as a daemon? > Is one way generally > > better than the other? > > Once your code starts up, there should be no performance > difference > since you're not adding any overhead from the container > (that is, you > don't have to use any of their classes or objects or > anything). The only > problem is that it's running in the same JVM as the > actual servlets in > your application. > > I'd keep it as a separate application if I were you. > > - -chris > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.9 (MingW32) > Comment: Using GnuPG with Mozilla - > http://enigmail.mozdev.org > > iEYEARECAAYFAkkjNTsACgkQ9CaO5/Lv0PBEogCfVE3yTS6SV/BSpK810P2XYtW/ > HX8AoMKeCUSOK2tlDLHdVWLzGRtCUZaI > =Q41d > -END PGP SIGNATURE- > > - > To start a new topic, e-mail: users@tomcat.apache.org > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: How do I configure server.xml for Tomcat to recognize my application directory?
The suggestion works. However, many of the log files are gone. There used to
be in the ${catalina.home}/logs folder files such as
catalina...log
admin...log
host-manager...log
etc
Now there is only
jakarta_service...log
stderr...log
stdout...log
I tried creating a folder log at the same level as public_html -- ie. c:\log --
but it did not work.
Incidentally, my log4j.properties specifies the log file as logs/MyFile.log,
and that file is created in the ${catalina.home} folder.
--- On Tue, 11/18/08, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> From: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
> Subject: RE: How do I configure server.xml for Tomcat to recognize my
> application directory?
> To: "Tomcat Users List"
> Date: Tuesday, November 18, 2008, 11:11 AM
> Thanks to everyone. I will try out these suggestions
> tonight and write back if they do not work.
>
> In response to
>
> > What is in your webapp's META-INF/context.xml
> file? It
> > should not have either the path or the docBase
> attributes
> > set.
>
> the file contents are as follows (note: no attributes in
> the Context element)
>
>
>
>
>
>
>
>
> --- On Tue, 11/18/08, Caldarale, Charles R
> <[EMAIL PROTECTED]> wrote:
>
> > From: Caldarale, Charles R
> <[EMAIL PROTECTED]>
> > Subject: RE: How do I configure server.xml for Tomcat
> to recognize my application directory?
> > To: "Tomcat Users List"
>
> > Date: Tuesday, November 18, 2008, 9:52 AM
> > > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED]
> > > Subject: How do I configure server.xml for Tomcat
> to
> > > recognize my application directory?
> > >
> > > The application is in
> > > C:\public_html
> >
> > You should put the application in a directory
> underneath
> > public_html, not in public_html. If you want it to be
> the
> > default webapp, make that directory name ROOT (case
> > sensitive, even on Windows).
> >
> > > The directory structure of the application is
> >
> > Move the files to:
> > C:\public_html\ROOT\index.html
> > C:\public_html\ROOT\WEB-INF\
> > C:\public_html\ROOT\WEB-INF\web.xml
> > C:\public_html\ROOT\META-INF
> >
> C:\public_html\ROOT\META-INF\context.xml
> >
> > > It seems the the problem might be the directory
> > structure,
> > > and appBase, and docBase.
> >
> > Correct; keep reading.
> >
> > > > appBase="/public_html"
> > > unpackWARs="true"
> > autoDeploy="true"
> > > xmlValidation="false"
> > xmlNamespaceAware="false">
> >
> > The above is mostly o.k.; appBase specifies the
> directory
> > under which each webapp is deployed. However, I would
> make
> > it "C:/public_html", just in case you're
> in a
> > different drive letter when Tomcat is started.
> >
> > > > docBase="/public_html">
> > >
> >
> > This is bad. The docBase attribute must *never* be
> the
> > same as appBase, and you should not be placing
> > elements in server.xml these days.
> Just
> > remove the entire element, since
> it's
> > not needed.
> >
> > What is in your webapp's META-INF/context.xml
> file? It
> > should not have either the path or the docBase
> attributes
> > set.
> >
> > - Chuck
> >
> >
> > THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR
> > OTHERWISE PROPRIETARY MATERIAL and is thus for use
> only by
> > the intended recipient. If you received this in error,
> > please contact the sender and delete the e-mail and
> its
> > attachments from all computers.
> >
> >
> -
> > To start a new topic, e-mail: users@tomcat.apache.org
> > To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> > For additional commands, e-mail:
> > [EMAIL PROTECTED]
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Default location
You have to specify the servlet classname in the WEB-INF/web.xml file. The jar
or class file containing the servlet must be on your classpath. The classpath
in Tomcat is the following to the best of my knowledge, though I don't know the
order
- the system classpath
- the ${catalina.home}/lib
- application/WEB-INF/classes
- application/WEB-INF/lib
There is also a common lib folder that I heard about, and there might be others.
--- On Fri, 11/21/08, kcg_ <[EMAIL PROTECTED]> wrote:
> From: kcg_ <[EMAIL PROTECTED]>
> Subject: Default location
> To: users@tomcat.apache.org
> Date: Friday, November 21, 2008, 10:27 AM
> Hello,
>
>
> Can anyone tel me what is the default location where tomcat
> looks for
> servlets?
>
>
> Thanks!
>
>
> kcg_
> --
> View this message in context:
> http://www.nabble.com/Default-location-tp20627077p20627077.html
> Sent from the Tomcat - User mailing list archive at
> Nabble.com.
>
>
> -
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Setup Logging for Tomcat 6
To setup log4j, here's what I did.
Copy the log4j jar file to WEB-INF/lib. Put it in ${catalina.home}/lib if you
want all webapps to be able to see this file.
Create a log4j.properties. Initially this file was in
WEB-INF/classes/log4j.properties. Now I have the file in
WEB-INF/lib/myjarfile.jar!log4j.properties (that is, at the root level of the
jar file).
That's it, if I remember correctly.
When the properties file specifies a relative filename, it appears to be
relative to ${catalina.home}, so specify for example "logs/myfile.log".
--- On Mon, 11/24/08, dOE <[EMAIL PROTECTED]> wrote:
> From: dOE <[EMAIL PROTECTED]>
> Subject: Setup Logging for Tomcat 6
> To: "Tomcat User-List"
> Date: Monday, November 24, 2008, 8:25 AM
> I have downloaded "Apache-log4j-1.2.15.zip" from
> http://tomcat.apache.org/tomcat-6.0-doc/logging.html, and
> began to following
> some of the steps, and then I am left clueless on what to
> do following the
> creation of the log4j.properties file, and copying
> "log4j-1.2.15.jar" in
> /tomca/lib. Then it asks to "Place
> output/extras/tomcat-juli-adapters.jarin
> $CATALINA_HOME/lib." I don't
> know where "output/extras" is?
>
> Any further guidance in this would be much MUCH
> appreciated.
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
configure JNDI to avoid error "Last packet sent to the server was xxxxx ms ago"
How to configure JNDI in order to avoid the error "Last packet sent to the
server was x ms ago."? I've seen two other errors which seem to be from
the same cause: "Communications link failure" and "Connection.close90 has
already been called".
This is what I've come up with, but wonder if it is is good and efficient:
The my.custom.mysql.Driver class decodes and decrypts the password, and passes
these to the base class, which is com.mysql.jdbc.NonRegisteringDriver.
I read that the validationQuery="select 1" validates the connection before
returning it to the user. If the select statement fails, then the connection
is removed from the pool and a new one is created.
What I'm not sure is if I need the testOnBorrow="true" and testWhileIdle="true".
The MySQL connection timeout is 12 hours, so I set
minEvictableIdleTimeMillis="4320". From the doc at
http://svn.apache.org/repos/asf/tomcat/trunk/modules/jdbc-pool/doc/jdbc-pool.xml,
it looks like this is the minimum time that the connection may sit idle in the
pool until it is considered for eviction/removal. So I set the value to 12
hours. So I imagine that after 12 hours, the validation query will run and it
will fail because the connection has been closed on the server, and so the idle
connection will be removed.
In my case, the last packet was sent about 57xxx milliseconds ago, which is
less than a minute, which is much less than the 12 hour MySQL connection
timeout. Yet the error happens only after around 12 hours. I expect the error
to be "... 4320 ms ago" or something like that.
Also, I read that the validationQuery adds performance overhead, and maybe the
Java code should handle exceptions. But how would this work? I'm guessing you
catch the SQLException, and if it is "Last packet sent to the server was x
ms ago" then call connection.reconnect and attempt the operation again. But
java.sql.Connection does not have a function reconnect.
The other thing I could try in code, is that after getting the connection by
calling ctx.lookup("java:comp/env/jdbc/myname"), is to call
connection.isValid() or connection.isClosed(), and if the connection is closed
then call something to remove it from the pool. But java.sql.Connection does
not have a function removeMeFromThePoolIBelongTo().
Finally, I'm concerned about maxIdle="15" and removeAbandoned="true". If a
connection is used for a SQL statement then closed, it becomes idle. But then,
will it be removed? Or does removeAbandoned="true" only apply to connections
that are still active (i.e. connection.close() has not been called on it) for
removeAbandonedTimeout="30" seconds?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: configure JNDI to avoid error "Last packet sent to the server was xxxxx ms ago"
The second message -- connection has already been closed -- most likely arises
from my code structure, which is:
Connection connection = null;
PreparedStatement prepStmt = null;
try
{
Connection connection = getConnection();
PreparedStatement prepStmt = connection.prepareStatement(...);
...
}
finally
{
if (prepStmt != null) prepStmt.close();
if (connection != null) connection.close();
}
The call to getConnection() in the try block gets a connection from the pool.
But the server has closed this connection. Therefore the call to
prepareStatement throws a SQLException which is the last packet exception.
And we then enter the finally block, which tries to close the connection, and
we get a new SQLException that the connection has already been closed.
In some places in my code I solve the issue of throwing a new exception by a
new local variable as follows:
SQLException caught = null;
Connection connection = null;
PreparedStatement prepStmt = null;
try
{
Connection connection = getConnection();
PreparedStatement prepStmt = connection.prepareStatement(...);
...
}
catch (SQLException e)
{
caught = e;
throw e;
}
finally
{
if (prepStmt != null)
{
try
{
prepStmt.close();
}
catch (SQLException e)
{
if (caught == null) caught = e;
}
}
if (connection != null)
{
try
{
connection.close();
}
catch (SQLException e)
{
if (caught == null) caught = e;
}
}
if (caught != null) throw caught;
}
But it's just too much code to write!
Probably with the validationQuey I won't have to worry about the last packet
exception. Let me try it out.
I removed minEvictableIdleTimeMillis and testWhileIdle.
Is there any doc about the ping in "/*ping*/ select 1"?
And yes, I got these errors even without my driver.
FYI, my driver class is
import com.mysql.jdbc.NonRegisteringDriver;
public class DecryptPasswordMysqlDriver extends NonRegisteringDriver
{
public static final String urlPrefix = "mydriver@";
private static final String usernamePropertyName = "user";
private static final String passwordPropertyName = "password";
static
{
try
{
DriverManager.registerDriver(new DecryptPasswordMysqlDriver());
}
catch (SQLException e)
{
throw new RuntimeException("Can't register " +
DecryptPasswordMysqlDriver.class.getName());
}
}
public DecryptPasswordMysqlDriver() throws SQLException
{
// Required for Class.forName().newInstance()
}
public boolean acceptsURL(String string) throws SQLException
{
if (string.startsWith(urlPrefix))
{
return super.acceptsURL(string.substring(urlPrefix.length()));
}
return false;
}
public Connection connect(String string, Properties properties) throws
SQLException
{
if (!acceptsURL(string)) return null;
// when the connection is created,
// the username and password come from context.xml and are therefore
encoded
// when the connection is borrowed from the pool,
// the username and password come from values saved by the pool, which
are the decoded values
String encodedPassword = (String) properties.get(passwordPropertyName);
if (MapUtils.canDecrypt(encodedPassword))
{
String username = (String) properties.get(usernamePropertyName);
String password = MapUtils.decrypt(username, encodedPassword);
username = baseUsername + '_' + username;
properties.put(usernamePropertyName, username);
properties.put(passwordPropertyName, password);
}
Connection connection =
super.connect(string.substring(urlPrefix.length()), properties);
return connection;
}
}
--- On Fri, 12/5/08, Christopher Schultz <[EMAIL PROTECTED]> wrote:
> From: Christopher Schultz <[EMAIL PROTECTED]>
> Subject: Re: configure JNDI to avoid error "Last packet sent to the server
> was x ms ago"
> To: "Tomcat Users List"
> Date: Friday, December 5, 2008, 9:20 AM
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> To whom it may concern,
>
> [EMAIL PROTECTED] wrote:
> > How to configure JNDI in order to avoid the error
> "Last packet sent
> > to the server was x ms ago."? I've seen
> two other errors which
> > seem to be from the same cause: "Communications
> link failure" and
> > "Connection.close() has already been
> called".
>
> I think the first one is a MySQL error message, so properly
> configuring
> your DataSource is key. The second one looks like you are
> being sloppy
> with your connections and closing them multiple times.
>
> > The my.custom.mysql.Driver class decodes and decrypts
> the password,
> > and passes these to the base class, which is
> > com.mysql.jdbc.NonRegisteringDriver.
>
> Aah, the old "why can't I encrypt my password in
> my "
> question. Do you have any of these problems if you just
Re: configure JNDI to avoid error "Last packet sent to the server was xxxxx ms ago"
But I need to re-trigger the operation (such as an INSERT statement), and also
to remove the dead connection from the pool or reconnect it.
--- On Sat, 12/6/08, Ken Bowen <[EMAIL PROTECTED]> wrote:
> From: Ken Bowen <[EMAIL PROTECTED]>
> Subject: Re: configure JNDI to avoid error "Last packet sent to the server
> was x ms ago"
> To: "Tomcat Users List"
> Date: Saturday, December 6, 2008, 4:39 PM
> Can't you deal with the connection being closed in your
> finally block
> by using this code:
>
> if (connection != null && !connection.isClosed())
> connection.close();
>
>
> On Dec 6, 2008, at 6:50 PM, [EMAIL PROTECTED]
> wrote:
>
> > The second message -- connection has already been
> closed -- most
> > likely arises from my code structure, which is:
> >
> > Connection connection = null;
> > PreparedStatement prepStmt = null;
> > try
> > {
> > Connection connection = getConnection();
> > PreparedStatement prepStmt =
> connection.prepareStatement(...);
> > ...
> > }
> > finally
> > {
> > if (prepStmt != null) prepStmt.close();
> > if (connection != null) connection.close();
> > }
> >
> > The call to getConnection() in the try block gets a
> connection from
> > the pool. But the server has closed this connection.
> Therefore the
> > call to prepareStatement throws a SQLException which
> is the last
> > packet exception.
>
>
> -
> 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: configure JNDI to avoid error "Last packet sent to the server was xxxxx ms ago"
Thanks for the links. But in answer to the issues below: chmod 600 is not sufficient because the admin of my website should not be able to see the passwords either. And if you're using a web hosting service, all the more reason. The decryption algorithm may need a license key which is installed only on that machine, so copying the contents of the lib folder may not be sufficient. Though I have to admit, mines is not that complex! --- On Sun, 12/7/08, Kees Jan Koster <[EMAIL PROTECTED]> wrote: > From: Kees Jan Koster <[EMAIL PROTECTED]> > Subject: Re: configure JNDI to avoid error "Last packet sent to the server > was x ms ago" > To: "Tomcat Users List" > Date: Sunday, December 7, 2008, 12:39 AM > Hmm. Lots of trouble for a file that you can just chmod 600 > to avoid > this whole issue. But that's just how I do this. > > You realize of course that this precisely as safe as > storing a plain- > text password. I mean, if I can read this file with the > encrypted > password, I can see that you use a non-standard MySQL > driver. So I > would just download the contents of your Tomcat's lib > directories. I > presume they have the same directory and file permissions > as the data > source config file. > > I don't care what the password is. I just copy your > config, plop the > contents of your Tomcat's lib dir into mine and I can > connect to your > database just fine. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
default application versus secondary application
Sorry, I could not find info on this topic on the internet, though I'm sure it's there. My directory structure is like this: c:\webapps\ c:\webapps\ROOT\ c:\webapps\ROOT\index.html c:\webapps\secondApp\ c:\webapps\secondApp\index.html To use the second application I type http://localhost/secondApp/index.html Now suppose I have the following files c:\webapps\ROOT\secondApp\ c:\webapps\ROOT\secondApp\index.html When I enter the above URL, Tomcat still shows the contents of c:\webapps\secondApp\index.html So the questions are: (1) What are the reasons to create many applications? (2) Will an application with name X hide a folder with name X in the root/default application? Thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat not displaying jsp files.
What address are you typing into the address/location bar? --- On Mon, 12/8/08, Gaurav Pruthi <[EMAIL PROTECTED]> wrote: > From: Gaurav Pruthi <[EMAIL PROTECTED]> > Subject: Tomcat not displaying jsp files. > To: "Tomcat Users List" > Date: Monday, December 8, 2008, 5:27 AM > Hi, > > I am facing a strange issue infact from past one year. I am > using tomcat > virtual hosting but i am not able to run jsp pages in the > root directory. > Every time i have to create a directory in the AppBase and > have to put all > the jsp pages into it so that they could get executed. > > Here are my VirtualHost configured in server.xml file. > > debug="0" > appBase="/usr/local/tomcat/webapps/www.mydomain.com" > unpackWARs="true"> > className="org.apache.catalina.valves.AccessLogValve" > directory="/usr/local/tomcat/logs" > prefix="www.mydomain.com.access." > suffix=".log" pattern="common" > resolveHosts="false"/> > docBase="servlet" debug="0" > reloadable="true" > crossContext="true"> > className="org.apache.catalina.logger.FileLogger" > directory="/usr/local/tomcat/logs" > prefix="www.mydomain.com.access" > suffix=".log" timestamp="true"/> > > mydomain.com > > > > When i am keeping jsp files in > /usr/local/tomcat/webapps/www.mydomain.com/Folder, blank > page is > displayed. > > But If i am keeping jsp file in /usr/local/tomcat/webapps/ > www.mydomain.com/newfolder/ directory, then page is > displayed. > > Using apache-tomcat 6.0.16 > > Kindly let me know if any other information is required > > I am totally confused on this issue. I checked on the net > but in vain. > > > > Kindly Help. > > > > > > Thanks & Regards, > Gaurav Pruthi - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: configure JNDI to avoid error "Last packet sent to the server was xxxxx ms ago"
Yeah, the validationQuery seems to have fixed the problem. I guess a full week of non-use of the website should tell for sure. --- On Tue, 12/9/08, Kees Jan Koster <[EMAIL PROTECTED]> wrote: > From: Kees Jan Koster <[EMAIL PROTECTED]> > Subject: Re: configure JNDI to avoid error "Last packet sent to the server > was x ms ago" > To: "Tomcat Users List" > Date: Tuesday, December 9, 2008, 6:55 AM > Dear removeps-groups, > > > Thanks for the links. But in answer to the issues > below: > > > > chmod 600 is not sufficient because the admin of my > website should > > not be able to see the passwords either. And if > you're using a web > > hosting service, all the more reason. > > > > The decryption algorithm may need a license key which > is installed > > only on that machine, so copying the contents of the > lib folder may > > not be sufficient. Though I have to admit, mines is > not that complex! > > Euh. You admin probably has root. Even chmod 000 won't > stop him. If > your implementation does not work with a license server, > you've wasted > your time. Sorry. :-) > > Have you managed to fix your connection pool issues? > > Kees Jan > > > --- On Sun, 12/7/08, Kees Jan Koster > <[EMAIL PROTECTED]> wrote: > > > >> From: Kees Jan Koster <[EMAIL PROTECTED]> > >> Subject: Re: configure JNDI to avoid error > "Last packet sent to the > >> server was x ms ago" > >> To: "Tomcat Users List" > > >> Date: Sunday, December 7, 2008, 12:39 AM > > > >> Hmm. Lots of trouble for a file that you can just > chmod 600 > >> to avoid > >> this whole issue. But that's just how I do > this. > >> > >> You realize of course that this precisely as safe > as > >> storing a plain- > >> text password. I mean, if I can read this file > with the > >> encrypted > >> password, I can see that you use a non-standard > MySQL > >> driver. So I > >> would just download the contents of your > Tomcat's lib > >> directories. I > >> presume they have the same directory and file > permissions > >> as the data > >> source config file. > >> > >> I don't care what the password is. I just copy > your > >> config, plop the > >> contents of your Tomcat's lib dir into mine > and I can > >> connect to your > >> database just fine. > > > > > > > > > - > > To unsubscribe, e-mail: > [EMAIL PROTECTED] > > For additional commands, e-mail: > [EMAIL PROTECTED] > > > > > -- > Kees Jan > > http://java-monitor.com/forum/ > [EMAIL PROTECTED] > 06-51838192 > > The secret of success lies in the stability of the goal. -- > Benjamin > Disraeli > > > - > 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]
unable to login to second application because of password digest issues
Hi. I added a second application, but am unable to login to it because of password digest issues. Stepping into RealmBase.java this is what I find: When I log in to the primary application (under ROOT) the password is "test" and the password saved in the database is the sha1 which is "a743f6004188c384dbf566c0811ca0c978e07a9b". In JDBCRealm.digest, which is called by authenticate, there is a line return (HexUtils.convert(md.digest())); Incidentally, the second call to md.digest() returns a new result, although there is a call to md.reset() at the start of the try block. When I put HexUtils.convert(md.digest()) into the debug watch, I get HexUtils.convert(md.digest()) "a743f6004188c384dbf566c0811ca0c978e07a9b" String This matches what's in the database. Of course when I let the debugger continue the login fails because the code itself calls md.digest which returns a new result. So if I did not add that expression to the watch window, the login would work. And this is the case. Now onto my second application. The login is also "test", although the username, table name, and column names are different. However, When I put HexUtils.convert(md.digest()) into the debug watch, I get HexUtils.convert(md.digest()) "5fd0b97a45856c5581c1022c2e59ea00670e1040" String This does not match the value in the database, so the login fails. In fact, if I don't add any breakpoints and let the code run, the login fails, and my guess is that's because digest returns the wrong value. By contrast, for the ROOT application, digest returns the right value and the login succeeds -- as long as there are no breakpoints and watch variables. Incidentally, in both cases, the next call to HexUtils.convert(md.digest()) yields HexUtils.convert(md.digest()) "da39a3ee5e6b4b0d3255bfef95601890afd80709" String HexUtils.convert(md.digest()) "da39a3ee5e6b4b0d3255bfef95601890afd80709" String And the value remains the same even for the next call to HexUtils.convert(md.digest()). Strange problem. Thanks. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: unable to login to second application because of password digest issues
Nevermind, I figured it out. In the second request to login, there was an extra line, so the password was actually "test\r\n". --- On Sun, 12/14/08, removeps-gro...@yahoo.com wrote: > From: removeps-gro...@yahoo.com > Subject: unable to login to second application because of password digest > issues > To: users@tomcat.apache.org > Date: Sunday, December 14, 2008, 2:55 PM > Hi. I added a second application, but am unable to login to > it because of password digest issues. Stepping into > RealmBase.java this is what I find: > > When I log in to the primary application (under ROOT) the > password is "test" and the password saved in > the database is the sha1 which is > "a743f6004188c384dbf566c0811ca0c978e07a9b". > > In JDBCRealm.digest, which is called by authenticate, there > is a line > > return (HexUtils.convert(md.digest())); > > Incidentally, the second call to md.digest() returns a new > result, although there is a call to md.reset() at the start > of the try block. > > When I put HexUtils.convert(md.digest()) into the debug > watch, I get > > HexUtils.convert(md.digest()) "a743f6004188c384dbf566c0811ca0c978e07a9b" > String > > This matches what's in the database. Of course when I > let the debugger continue the login fails because the code > itself calls md.digest which returns a new result. > > So if I did not add that expression to the watch window, > the login would work. And this is the case. > > Now onto my second application. The login is also > "test", although the username, table name, and > column names are different. > > However, When I put HexUtils.convert(md.digest()) into the > debug watch, I get > > HexUtils.convert(md.digest()) "5fd0b97a45856c5581c1022c2e59ea00670e1040" > String > > This does not match the value in the database, so the login > fails. > > In fact, if I don't add any breakpoints and let the > code run, the login fails, and my guess is that's > because digest returns the wrong value. By contrast, for > the ROOT application, digest returns the right value and the > login succeeds -- as long as there are no breakpoints and > watch variables. > > Incidentally, in both cases, the next call to > HexUtils.convert(md.digest()) yields > > HexUtils.convert(md.digest()) "da39a3ee5e6b4b0d3255bfef95601890afd80709" > String > HexUtils.convert(md.digest()) "da39a3ee5e6b4b0d3255bfef95601890afd80709" > String > > And the value remains the same even for the next call to > HexUtils.convert(md.digest()). > > Strange problem. > > Thanks. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Server returned HTTP response code: 408 for URL: https...j_security_check
Server returned HTTP response code: 408 for URL: https...j_security_check
In my testing I get the following error:
Server returned HTTP response code: 408 for URL:
https://localhost:6143/mywebservice/action/j_security_check
408 = request time out.
So the question is how can a client authenticate themselves? Do you have to
figure out a JSESSION id somehow?
The code is
public static void main(String[] args)
{
BufferedReader responseReader = null;
try
{
URL url = new
URL("https://localhost:6143/mywebservice/action/j_security_check";);
HttpURLConnection connection = (HttpURLConnection)
url.openConnection();
connection.setRequestMethod("POST");
connection.setUseCaches(false);
connection.setAllowUserInteraction(false);
connection.setDoOutput(true);
PrintWriter requestParamsWriter = new
PrintWriter(connection.getOutputStream());
requestParamsWriter.print("j_username=junkuser&j_password=test");
requestParamsWriter.flush();
requestParamsWriter.close();
requestParamsWriter = null;
responseReader = new BufferedReader(new
InputStreamReader(connection.getInputStream()));
while (true)
{
String line = responseReader.readLine();
if (line == null) break;
System.out.println(line);
}
}
catch (IOException e)
{
e.printStackTrace();
}
finally
{
try
{
if (responseReader != null) responseReader.close();
}
catch (Exception e)
{
e.printStackTrace();
}
}
}
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Server returned HTTP response code: 408 for URL: https...j_security_check
But how does this work through code? My initial request is to "http://localhost/mywebservice/file.do"; (and all this is through Java code similar to below). Tomcat redirects the request to the login page specified in web.xml "http://localhost/mywebservice/login.html";. Then either Tomcat returns this page to the user, or invokes a servlet that constructs the page and returns is to the user. Then it seems Tomcat remembers the original request. Now the user sees a login page with the j_username and j_password form fields. In code, they get the output stream and it instructs them to login, though my page does not have the form fields in it. So in code the client constructs a login request. The request input stream is set to "j_username=username&j_password=password". But to what URL should the above response be posted? I would imagine that it should be to "http://localhost/mywebservice/j_security_check"; because the login page is typically like this A browser does not know about Tomcat protocols, so it would I imagine send the request to j_security_check. Then I imagine that Tomcat intercepts the request and validates the login, and then forwards to the original page (which must have remembered). So it makes sense to me that through code one may make requests to j_security_check. Just this would not not a recommended practice to users typing something into the address bar. So any ideas on how to make https requests through code? --- On Sun, 12/14/08, Caldarale, Charles R wrote: > From: Caldarale, Charles R > Subject: RE: Server returned HTTP response code: 408 for URL: > https...j_security_check > To: "Tomcat Users List" > Date: Sunday, December 14, 2008, 7:20 PM > > From: removeps-gro...@yahoo.com > [mailto:removeps-gro...@yahoo.com] > > Subject: Server returned HTTP response code: 408 for > URL: > > https...j_security_check > > > > Server returned HTTP response code: 408 for URL: > > > https://localhost:6143/mywebservice/action/j_security_check > > You're not allowed to reference j_security_check > directly. The URL must refer to a protected resource (as > declared in your web.xml), at which point Tomcat will > internally call up the j_security_check. if the > authentication succeeds, the original request will then be > reattempted automatically. > > - Chuck > > > THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR > OTHERWISE PROPRIETARY MATERIAL and is thus for use only by > the intended recipient. If you received this in error, > please contact the sender and delete the e-mail and its > attachments from all computers. > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: > users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Server returned HTTP response code: 408 for URL: https...j_security_check
> It should be a POST request to /[webapp]/j_security_check, > and include the JSESSIONID cookie set by the server when the > login page was returned. Thanks, this seems to be the issue. There is a call to org.apache.catalina.connector.Request.setRequestedSessionId(String id) from parseSessionCookiesId? How does the client get the JSESSIONID? When the server generates the login page does it have to call response.addCookie? From where should the servlet get the session id? How does the client read the cookie? Thanks. --- On Sun, 12/14/08, Caldarale, Charles R wrote: > From: Caldarale, Charles R > Subject: RE: Server returned HTTP response code: 408 for URL: > https...j_security_check > To: "Tomcat Users List" > Date: Sunday, December 14, 2008, 9:02 PM > > From: removeps-gro...@yahoo.com > [mailto:removeps-gro...@yahoo.com] > > Subject: RE: Server returned HTTP response code: 408 > for URL: > > https...j_security_check > > > > The request input stream is set to > > > "j_username=username&j_password=password". > > Good so far. > > > But to what URL should the above response be posted? > > It should be a POST request to /[webapp]/j_security_check, > and include the JSESSIONID cookie set by the server when the > login page was returned. > > > ...> > > Again, note that the method should be POST (which your code > does seem to be doing). > > > A browser does not know about Tomcat protocols, so it > > would I imagine send the request to j_security_check. > > Correct, but that's accepted by Tomcat only when a > login form has just been returned to the client. > There's no indication in your code that the > j_security_check is being sent as a response to a login > form, nor is the required JSESSIONID cookie being returned. > > > So any ideas on how to make https requests through > code? > > This isn't tied to HTTPS, just form login. The SSL > negotiation is completely separate. > > - Chuck > > > THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR > OTHERWISE PROPRIETARY MATERIAL and is thus for use only by > the intended recipient. If you received this in error, > please contact the sender and delete the e-mail and its > attachments from all computers. > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: > users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Server returned HTTP response code: 408 for URL: https...j_security_check
Nevermind, I see that JSESSIONID is added to the response automatically from
Tomcat.
The code
System.out.println(connection.getHeaderField("Set-Cookie"));
prints
JSESSIONID=56136B3CE4CC657DD36C226E264A97AD; Path=/mywebservice; Secure
So now I think I just have to include that cookie in every request. Will write
back if it does not work.
--- On Sun, 12/14/08, removeps-gro...@yahoo.com
wrote:
> From: removeps-gro...@yahoo.com
> Subject: RE: Server returned HTTP response code: 408 for URL:
> https...j_security_check
> To: "Tomcat Users List"
> Date: Sunday, December 14, 2008, 9:18 PM
> > It should be a POST request to
> /[webapp]/j_security_check,
> > and include the JSESSIONID cookie set by the server
> when the
> > login page was returned.
>
> Thanks, this seems to be the issue. There is a call to
> org.apache.catalina.connector.Request.setRequestedSessionId(String
> id) from parseSessionCookiesId?
>
> How does the client get the JSESSIONID? When the server
> generates the login page does it have to call
> response.addCookie? From where should the servlet get the
> session id? How does the client read the cookie?
>
> Thanks.
>
>
>
> --- On Sun, 12/14/08, Caldarale, Charles R
> wrote:
>
> > From: Caldarale, Charles R
>
> > Subject: RE: Server returned HTTP response code: 408
> for URL: https...j_security_check
> > To: "Tomcat Users List"
>
> > Date: Sunday, December 14, 2008, 9:02 PM
> > > From: removeps-gro...@yahoo.com
> > [mailto:removeps-gro...@yahoo.com]
> > > Subject: RE: Server returned HTTP response code:
> 408
> > for URL:
> > > https...j_security_check
> > >
> > > The request input stream is set to
> > >
> >
> "j_username=username&j_password=password".
> >
> > Good so far.
> >
> > > But to what URL should the above response be
> posted?
> >
> > It should be a POST request to
> /[webapp]/j_security_check,
> > and include the JSESSIONID cookie set by the server
> when the
> > login page was returned.
> >
> > > > ...>
> >
> > Again, note that the method should be POST (which your
> code
> > does seem to be doing).
> >
> > > A browser does not know about Tomcat protocols,
> so it
> > > would I imagine send the request to
> j_security_check.
> >
> > Correct, but that's accepted by Tomcat only when a
> > login form has just been returned to the client.
> > There's no indication in your code that the
> > j_security_check is being sent as a response to a
> login
> > form, nor is the required JSESSIONID cookie being
> returned.
> >
> > > So any ideas on how to make https requests
> through
> > code?
> >
> > This isn't tied to HTTPS, just form login. The
> SSL
> > negotiation is completely separate.
> >
> > - Chuck
> >
> >
> > THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR
> > OTHERWISE PROPRIETARY MATERIAL and is thus for use
> only by
> > the intended recipient. If you received this in error,
> > please contact the sender and delete the e-mail and
> its
> > attachments from all computers.
> >
> >
> -
> > To unsubscribe, e-mail:
> users-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail:
> > users-h...@tomcat.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
How to install the session cookie into the original request of the secure area?
How to install the session cookie into the original request of the secure area? Here is my problem. When making a connection to the secure area of my website through code, the original request is saved, but the JSESSIONID cookie is not added to it. So after j_security_check succeeds, the saved request fails. Details: (1) Open a URL connection to "https://localhost/mywebservice/secure/action.do";. There are no cookies. (2) Tomcat redirects to "https://localhost/mywebservice/secure/login.html"; as specified in web.xml. Tomcat also saves the request in (1). (3) A servlet creates the page and sends it back. The response has a JSESSOINID cookie in it. (4) The client reads the response and saves the cookie. (5) The clien opens a connection to "https://localhost/mywebservice/secure/j_security_check";, and passes j_username, j_password, and JSESSIONID. (6) The authentication succeeds on the server. (7) The server goes on to process the saved request (1) above. (8) But there are no cookies, so the request fails and we get the login page again. There's a function in Tomcat that calls req.getCookies(), and the result is an array of length 0. By contrast, when I open Mozilla and go to a secure section of my website, Tomcat saves the original request. It then sends back the login page. Upon a succesful login, Tomcat processes the saved request, and in the debugger I can see that the above function req.getCookies() returns an array of size 1, and it is the correct JSESSION cookie. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Case-insensitive JDBC Realm j_security_check
Yes, this is possible. Override JDBCRealm.authenticate.
Details:
1. Class is org.apache.catalina.realm.JDBCRealm.
2. Override authenticate of 2 arguments. I guess you would convert username
and/or password to lowercase and call super.authenticate.
3. The jar file containing your class, or the class file itself should go into
${catalina.home}/lib.
4. You will probably reference the new class in the Realm and Resource elements
of context.xml or server.xml.
--- On Thu, 12/18/08, Tokajac wrote:
> From: Tokajac
> Subject: Case-insensitive JDBC Realm j_security_check
> To: users@tomcat.apache.org
> Date: Thursday, December 18, 2008, 6:37 AM
> Hello!
>
>
> Is it possible to adapt REALM authentication of Tomcat, so
> that Username and
> password become case insensitive?
>
>
> Regards
> --
> View this message in context:
> http://www.nabble.com/Case-insensitive-JDBC-Realm-j_security_check-tp21073984p21073984.html
> Sent from the Tomcat - User mailing list archive at
> Nabble.com.
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail:
> users-h...@tomcat.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
RE: How to install the session cookie into the original request of the secure area?
Was not able to figure out how to use Wireshark. But I found an extension called Tamper Data for Firefox. On browser I type https://localhost/myaccount/index.faces Tamper Data shows - a GET request for the above page with no JSESSIONID, which returns 200 - OK There are other requests such as wpad.dat. No idea what that is. There are also requests to get the images and style sheets. The above response is actually the login page. Now I login. Tamper Data shows - a POST request for the http://localhost/myaccount/j_security_check page with JSESSION passed in The server evidently returns status code 302 - moved temporarily to the above request, and the location returned is "http://localhost/myacccount/index.faces";. The above makes sense, because the code in FormAuthenticator.java is response.sendRedirect(response.encodeRedirectURL(requestURI)); which redirects the user to the saved page. So the browser sends a request to the above page, passing in the JSESSIONID, but probably no body data as that has already been saved. But in my application, the above call to sendRedirect does not send anything back to the client. Instead, the server directly goes on to handle the saved request, as if the sendRedirect was a jsp:forward. So why? It seems my code needs to call HttpURLConnection.setFollowRedirects(false); This way, when j_security_check finishes, my code sees the response code 302. My code then resubmits the request, passing in JSESSIoNID. It looks like the default behavior of HttpURLConnection is to automatically go to the redirect page (without adding the JSESSIONID). --- On Tue, 12/16/08, Caldarale, Charles R wrote: > From: Caldarale, Charles R > Subject: RE: How to install the session cookie into the original request of > the secure area? > To: "Tomcat Users List" > Date: Tuesday, December 16, 2008, 12:38 PM > > From: removeps-gro...@yahoo.com > [mailto:removeps-gro...@yahoo.com] > > Subject: How to install the session cookie into the > original > > request of the secure area? > > > > When making a connection to the secure area of my > > website through code, the original request is saved, > > but the JSESSIONID cookie is not added to it. > > You need to invest* in a copy of Wireshark so you can see > the differences in the requests that a browser sends vs the > ones your client code makes. > > - Chuck > > *It's open source, so the investment is primarily one > of education. > > > THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR > OTHERWISE PROPRIETARY MATERIAL and is thus for use only by > the intended recipient. If you received this in error, > please contact the sender and delete the e-mail and its > attachments from all computers. > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: > users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
How can the login page see parameters in the original request?
How can the login page see parameters in the original request?
In my app, I make a request to https://localhost/mywebservice/action.do.
Because the user is not authenticated, Tomcat redirects them to the login page.
I want the login page to be able to see the parameters passed in the original
request. Only if certain secret fields and values are present, do I want to
generate the login page. Otherwise, I want to send the response code 404.
In FormAuthenticator.java, function saveRequest, they have
if ("POST".equalsIgnoreCase(request.getMethod())) {
ByteChunk body = new ByteChunk();
body.setLimit(request.getConnector().getMaxSavePostSize());
byte[] buffer = new byte[4096];
int bytesRead;
InputStream is = request.getInputStream();
while ( (bytesRead = is.read(buffer) ) >= 0) {
body.append(buffer, 0, bytesRead);
}
saved.setContentType(request.getContentType());
saved.setBody(body);
}
Maybe the act of reading the input stream through is.read uses it up, not sure.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: How can the login page see parameters in the original request?
To hide the existence of the page from robots. --- On Tue, 12/30/08, Pid wrote: > From: Pid > Subject: Re: How can the login page see parameters in the original request? > To: "Tomcat Users List" > Date: Tuesday, December 30, 2008, 6:26 AM > removeps-gro...@yahoo.com wrote: > > > Only if certain secret fields and values are present, > do I want to generate the login page. > > They're not really secret if you're passing them as > parameters. > It sounds like you're trying to over-engineer > something, which often > results in no security improvements and sometimes > introduces flaws. > > What is your real goal? > > p > > > > > - > > To unsubscribe, e-mail: > users-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: > users-h...@tomcat.apache.org > > > > > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: > users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: How can the login page see parameters in the original request?
Do you mean set session attributes? How do you do that from the client side? --- On Wed, 12/31/08, Konstantin Kolinko wrote: > From: Konstantin Kolinko > Subject: Re: How can the login page see parameters in the original request? > To: "Tomcat Users List" , removeps-gro...@yahoo.com > Date: Wednesday, December 31, 2008, 5:43 AM > 2008/12/30 : > > To hide the existence of the page from robots. > > > > --- On Tue, 12/30/08, Pid wrote: > > > >> From: Pid > >> Subject: Re: How can the login page see parameters > in the original request? > >> To: "Tomcat Users List" > > >> Date: Tuesday, December 30, 2008, 6:26 AM > >> removeps-gro...@yahoo.com wrote: > >> > >> > Only if certain secret fields and values are > present, > >> do I want to generate the login page. > >> > >> They're not really secret if you're > passing them as > >> parameters. > >> It sounds like you're trying to over-engineer > >> something, which often > >> results in no security improvements and sometimes > >> introduces flaws. > >> > >> What is your real goal? > >> > > > > How about passing them with the Session? > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: > users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: How can the login page see parameters in the original request?
Most thorough, thanks! --- On Thu, 1/1/09, Konstantin Kolinko wrote: > From: Konstantin Kolinko > Subject: Re: How can the login page see parameters in the original request? > To: "Tomcat Users List" > Date: Thursday, January 1, 2009, 3:53 PM > 2009/1/1 : > > Do you mean set session attributes? How do you do > that from the client side? > > > > > > a) You can set them in another page (an unprotected one) > that is > accessed before, > or that redirects to this one. > > b) You can pass your secrets as a cookie, or as a request > header. Cookies > can be created on the client side. > > c) You can use RemoteAddrValve and block those clients that > should not > know about your service. > > d) You can throw away all the security constraints from > web.xml and use > alternative approaches, e.g. those that implement a Filter, > e.g. > > securityfilter ([1]), that is ofter mentioned on this list > and should be easy > to adopt, or some others > > [1] http://securityfilter.sourceforge.net/ > > Best regards, > Konstantin Kolinko > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: > users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
How to have multiple loggers with shared code also using the logger?
How to have multiple loggers with shared code also using the logger?
In ${catalina.home}/lib there is a jar file that contains class MyLog. There
is a function in it
public class MyLog
{
public static Logger getLogger()
{
ClassLoader classLoader = Thread.currentThread().getContextClassLoader();
URL log4j_properties = classLoader.getResource("log4j.properties");
String loggerName = log4j_properties != null ?
log4j_properties.toString() : "default";
synchronized (MyLog.class)
{
Logger logger =
Logger.getRootLogger().getLoggerRepository().exists(loggerName);
if (logger == null)
{
logger = Logger.getLogger(loggerName);
System.out.println("Created logger: loggerName=" + loggerName);
}
return logger;
}
}
}
The jar file in ${catalina.home}/lib contains common code used by all web
applications, and it calls MyLog.getLogger() to write some logs.
My ROOT application in ${catalina.home}/webapps/ROOT and web service
application in ${catalina.home}/webapps/mywebservice also call MyLog.
The intent of getLogger() above is to return the logger for the application
currently being run. I have verified that
Thread.currentThread().getContextClassLoader().hashCode() has value1 for the
ROOT application and value2 for the mywebservice application.
We have the following two log4j.properties:
${catalina.home}/webapps/ROOT/WEB-INF/lib/root.jar!/log4j.properties
${catalina.home}/webapps/mywebservice/WEB-INF/lib/root.jar!/log4j.properties
The value of loggerName is the first one when we're running the ROOT
application, and the second one when running the mywebservice application. So
far, so good.
After starting Tomcat, if we run the ROOT application first, then it will call
MyLog.getLogger(), and the log4j.properties found by the call to
Logger.getLogger() will be the first one above. If we run mywebservice first,
then Logger.getLogger() will find the second log4j.properties file. Any
subsequent call to Logger.getLogger() will use the same log4j.properties. So
suppose we run the ROOT application first, then the new logger will be
initialized with the first log4j.properties above. And then if mywebservice
calls MyLog.getLogger(), a new logger will get created, but it will be based on
the same log4j.properties file. You can see this because all applications log
to the same file (each of my log4j.properties specifies a different file).
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
RE: How to have multiple loggers with shared code also using the logger?
Why is it what I'm trying to do not working though? It seems that my
MyLog.getLogger function does find the correct logger name, and that
Logger.getLogger() is always using the the first log4j.properties that was
found.
Yeah, I had tried something like this, namely to have a class AbstractMyLog in
the common folder, and a class MyLog in each of the webapps that derives from
AbstractMyLog so as to minimize code changes. But then the common code also
needs to write to the log file, and it should use the log file of the web
application that called it.
The other ideas I had are:
(1) Pass a logger from the webapp to the common code -- ie. to add a Logger
argument to all the functions in the common code, but this sounds tedious.
(2) In each webapp have a filter that sets a thread local variable like
ThreadLocal threadLogger.
--- On Tue, 1/13/09, Caldarale, Charles R wrote:
> From: Caldarale, Charles R
> Subject: RE: How to have multiple loggers with shared code also using the
> logger?
> To: "Tomcat Users List"
> Date: Tuesday, January 13, 2009, 6:21 AM
> > From: removeps-gro...@yahoo.com
> [mailto:removeps-gro...@yahoo.com]
> > Subject: How to have multiple loggers with shared code
> also
> > using the logger?
> >
> > How to have multiple loggers with shared code also
> using the logger?
> > In ${catalina.home}/lib there is a jar file that
> contains class MyLog.
>
> "Doctor, doctor, it hurts when I do this."
>
> The simple fix is: don't do it. Package your webapps
> so that each contains a copy of MyLog rather than putting
> that class in the common location. You can still maintain
> the same source, just make sure the .class file is located
> locally in each webapp that uses it.
>
> - Chuck
>
>
> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR
> OTHERWISE PROPRIETARY MATERIAL and is thus for use only by
> the intended recipient. If you received this in error,
> please contact the sender and delete the e-mail and its
> attachments from all computers.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail:
> users-h...@tomcat.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
RE: How to have multiple loggers with shared code also using the logger?
> Because of the classloading hierarchy. Once the logger is
> initialized with the common classloader, everybody uses that
> one.
Thanks. I studied the Apache logger code.
When we call org.apache.log4j.Logger.getLogger(), it calls functions of
LogManager. The static initializer block of LogManager gets log4j.properties
using the thread's class loader, so if the first webapp I run is mywebservice,
then it will get log4j.properties from mywebservice, such as
mywebservice/WEB-INF/classes/log4j.properties. The root logger will be
initialized using this log4j.properties file, and all new loggers will inherit
this configuration, which does not seem very useful.
And since the log4j.jar resides in the ${catalina.home}/lib folder, this root
logger is used by all web apps.
So what I did is
(1) Create a log4j.properties in ${catalina.home}/lib/log4j.properties or in a
jar file here.
(2) This properties file should contain the configuration shared by all app
loggers. For me, the file is one line:
log4j.rootLogger=warn
(3) Rename log4j.properties in each webapp and swingapp and JUnit test app to
log4j_app.properties.
(4) Modify MyLog.getLogger(), which is a function in a jar file that is shared
by all apps (ie. a function in ${catalina.home}/lib) so that when a logger is
created, initialize the logger from the appropriate log4j_app.properties.
import org.apache.log4j.PropertyConfigurator;
/**
* This function attempts to locate log4j_app.properties using the
* thread's classloader, and returns a logger using the location of
* log4j_app.properties as the logger name.
* The logger will be initialized with the configuration in
log4j_app.properties.
* This allows each application within the web server will use its own
logger.
* This function is thread-safe, and callers don't need to synchronized on
MyLog.
* @return
* @throws NullPointerException if log4j_app.properties does not exist
*/
public static Logger getLogger()
{
ClassLoader classLoader = Thread.currentThread().getContextClassLoader();
URL log4j_properties = classLoader.getResource("log4j_app.properties");
String loggerName = log4j_properties.toString();
synchronized (MyLog.class)
{
Logger logger =
Logger.getRootLogger().getLoggerRepository().exists(loggerName);
if (logger == null)
{
logger = Logger.getLogger(loggerName);
PropertyConfigurator.configure(log4j_properties);
System.out.println("Created logger: loggerName=" + loggerName);
}
return logger;
}
}
> Don't do that. Keep just one copy of the source
> somewhere, just have your packaging script put the .class
> file in the webapp package. No need to have an abstract
> class or subclasses.
Not sure if that would work as the log4j.jar is in ${catalina.home}/lib, so the
root logger is shared by all apps.
> > (1) Pass a logger from the webapp to the common code
> -- ie.
> > to add a Logger argument to all the functions in the
> common
> > code, but this sounds tedious.
>
> That's the cost of keeping things isolated, which is a
> worthwhile goal.
>
> > (2) In each webapp have a filter that sets a thread
> local
> > variable like ThreadLocal threadLogger.
>
> Just make sure you clear the ThreadLocal on *every*
> possible exit path out of your request processing. If you
> don't, you will have memory leaks in PermGen causing it
> to fill up as webapps are redeployed.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
RE: How to have multiple loggers with shared code also using the logger?
Thanks, this makes sense. However, I'd like to find out what is being held
onto by the log4j.jar. So I'd like to test it out. How does one redploy a
single application? Strange, I could not find any information on this
seemingly basic task on google. Thanks again.
--- On Wed, 1/14/09, Caldarale, Charles R wrote:
> From: Caldarale, Charles R
> Subject: RE: How to have multiple loggers with shared code also using the
> logger?
> To: "Tomcat Users List"
> Date: Wednesday, January 14, 2009, 9:27 PM
> > From: removeps-gro...@yahoo.com
> [mailto:removeps-gro...@yahoo.com]
> > Subject: RE: How to have multiple loggers with shared
> code
> > also using the logger?
> >
> > And since the log4j.jar resides in the
> ${catalina.home}/lib
> > folder, this root logger is used by all web apps.
>
> The log4j.jar is only there because you put it there. It
> does not come with the Tomcat distribution, and it's
> normally placed in the WEB-INF/lib directory of each webapp
> that needs it.
>
> By having such a jar in a common location, you've
> pretty much guaranteed that you'll have to take Tomcat
> down to redeploy a single webapp - the old webapp won't
> go away because log4j will be hanging onto references to it.
> (A common cause of PermGen filling up after redeployments.)
>
> The servlet spec (and experience) strongly suggest that
> webapps be kept as isolated as possible for this kind of
> reason.
>
> - Chuck
>
>
> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR
> OTHERWISE PROPRIETARY MATERIAL and is thus for use only by
> the intended recipient. If you received this in error,
> please contact the sender and delete the e-mail and its
> attachments from all computers.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail:
> users-h...@tomcat.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: which JSP web hosting(windows or linux)
There's also mochahost.com. It is not necessary to know Linux to use a Linux plan. Though be aware that file names are case sensitive. On MochaHost, it looks like if you must use MSSqlServer, then you have to go with the Windows plan, and use ASP instead of JSP. In theory it should be possible to use MSSqlServer with Java and Linux. I only know about Linux. They have shared plans where many users share the same Tomcat and Java virtual machine, then dedicated plans where each user has their own Tomcat instance and Java virtual machine (but I think many users are on the same machine), and finally you have truly dedicated plans with your own machine and SSH access. --- On Sun, 1/18/09, Sneha Manohar wrote: > From: Sneha Manohar > Subject: which JSP web hosting(windows or linux) > To: "Tomcat Users List" > Date: Sunday, January 18, 2009, 2:49 AM > Hello , > I have some more questions on web hosting . Which web > hosting I should go for windows or linux . Do I need to > learn linux if I choose linux hosting . What is the impact > of linux or windows hosting on my web application. > > sneha > > --- On Sun, 18/1/09, Rusty Wright > wrote: > > From: Rusty Wright > Subject: Re: which JSP web hosting > To: "Tomcat Users List" > > Date: Sunday, 18 January, 2009, 10:57 AM > > I haven't tried any of these but they're in my > bookmarks: > > http://www.godaddy.com/ > http://www.dailyrazor.com/java/private_tomcat.php > http://www.javaservlethosting.com/index.jsh > http://rimuhosting.com/ > http://www.slicehost.com/ > > > Sneha Manohar wrote: > > Hello, > > I am developing web application using JSP,HTML,Java > script with MS SQL as > back end (using JDBC mechanism for connecing to data base) > > Can you please suggest me some web hosting ? > > Regards > > Sneha Manohar > > Anoigma software services > > London > > > > > > Add more friends to your messenger and enjoy! Go > to > http://messenger.yahoo.com/invite/ > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: > users-h...@tomcat.apache.org > > > > > Add more friends to your messenger and enjoy! Go to > http://messenger.yahoo.com/invite/ - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: How to have multiple loggers with shared code also using the logger?
Here's an update on the logger issue. It too me long to figure out because I
ran into an issue about privileged servlets and had to write my own
log4j.properties parser.
The original code posted earlier in this thread works in that it creates a
different logger for web application, and allows the user to stop and restart
the application.
public static Logger getLogger()
{
ClassLoader classLoader = Thread.currentThread().getContextClassLoader();
URL log4j_properties = classLoader.getResource("log4j_app.properties");
String loggerName = log4j_properties.toString(); // throws
NullPointerException if log4j_app.properties does not exist
synchronized (MyLog.class)
{
Logger logger =
Logger.getRootLogger().getLoggerRepository().exists(loggerName);
if (logger == null)
{
logger = Logger.getLogger(loggerName);
PropertyConfigurator.configure(log4j_properties);
System.out.println("Created logger: loggerName=" + loggerName);
}
return logger;
}
}
One bug with the above is the line
PropertyConfigurator.configure(log4j_properties);
The above re-configures the root logger with the new log4j.properties, so
basically the new configuration applies to all loggers. What would be nice is
PropertyConfigurator.configure(logger, log4j_properties);
that configures only the specified logger with the log4j_properties.
Unfortunately, log4j does not have such a function, so I wrote my own (but it
only supports the properties used in my log4j_app.properties files).
Now, if web application 1 calls MyLog.getLogger() or calls common code that
calls MyLog.getLogger() then the first logger will be used, and similarly for
web application 2.
Finally, I create a servlet
import org.apache.catalina.manager.ManagerServlet;
public class TomcatManagerServlet extends ManagerServlet
The servlet is called for "/reload", and it calls super.doGet() after doing
some checks.
It turns out that only privileged web applications can instantiate
ManagerServlet, so one has to have the following in context.xml:
I'm not sure what is the practical impact of setting privileged="true", though
the docs said something about the catalina and shared class loaders.
So upon calling
http://localhost/mywebservice/reload?path=/
the ROOT application is stopped and started. After the application restart,
all users are logged out and they have to log in again, but the logger
continues to work. A call to MyLog.getLogger() does not re-create the logger.
The logger is really owned by the common code in ${catalina.home}/lib. The
code
URL log4j_properties = classLoader.getResource("log4j_app.properties");
just gets the URL of the log4j.properties file. However, there is no pointer
to anything in the webapp, so it's possible to stop the webapp. And the line
PropertyConfigurator.configure(log4j_properties);
opens the URL (by calling log4j_properties.getInputStream()), reads it, and
closes it. So no stream in the webapp is open, and it's possible to stop the
webapp.
--- On Thu, 1/15/09, Caldarale, Charles R wrote:
> From: Caldarale, Charles R
> Subject: RE: How to have multiple loggers with shared code also using the
> logger?
> To: "Tomcat Users List"
> Date: Thursday, January 15, 2009, 11:28 AM
> > From: removeps-gro...@yahoo.com
> [mailto:removeps-gro...@yahoo.com]
> > Subject: RE: How to have multiple loggers with shared
> code
> > also using the logger?
> >
> > How does one redploy a single application? Strange, I
> > could not find any information on this seemingly basic
> > task on google.
>
> Read the real docs first, then Google only if needed.
> http://tomcat.apache.org/tomcat-6.0-doc/deployer-howto.html#Deploying%20on%20a%20running%20Tomcat%20server
> http://tomcat.apache.org/tomcat-6.0-doc/manager-howto.html
>
> - Chuck
>
>
> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR
> OTHERWISE PROPRIETARY MATERIAL and is thus for use only by
> the intended recipient. If you received this in error,
> please contact the sender and delete the e-mail and its
> attachments from all computers.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail:
> users-h...@tomcat.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Is it possible for error page from one webapp to direct to another?
Is it possible for error page from one webapp to direct to another? What I'm thinking is: In mywebservice/WEB-INF/web.xml 404 /errors/404.html But I want the error page to be ROOT/errors/404.html Thanks. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Unexpected redirect from https to http
If the internal redirects and forwards did change the scheme to http, then they wouldn't work because there is no http listener. Is this what you want? I have no idea, except that perhaps Tomcat changes the scheme to https automatically whenever it can. --- On Mon, 1/26/09, Timothy Tagge wrote: > From: Timothy Tagge > Subject: Unexpected redirect from https to http > To: users@tomcat.apache.org > Date: Monday, January 26, 2009, 3:01 PM > I'm working on an application that does redirects to > itself. The > application is intended to run under https for all pages. > However, > when the redirect is requested, the resulting URL shown in > the browser > is http://secureServer/correctDomain/correctPage.jsp This > request > times out because there is no http listener at > secureServer. However, > requests directly to a jsp file in that application via > https do not > get changed to http and work just fine. So the issue only > happens > during internal redirects. Could this be cert related? > Apache or > Tomcat config issue? > > Our setup is as follows... > JDK 1.6.06 > Tomcat 5.5.15 > AJP1.3 > Big IP is providing https with a certificate supplied by > Verisign > Host file on the tomcat server that points all calls to > secureServer > to the IP Address for Big IP. Big IP is configured to > point back to > tomcat on port 80 > > > ### AJP Configuration # > > enableLookups="false" > redirectPort="8443" protocol="AJP/1.3" > /> > > ### workers.properties configuration > # > worker.worker_aat.type=ajp13 > worker.worker_aat.host=localhost > worker.worker_aat.port=8009 > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: > users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
