With pleasure :-)
It's actually quite simple:
- make sure Velocity JAR file is visible to your application classloader in
Tomcat; either put it in your own WEB-INF/lib (for singleton model) of each app
or in lib/apps of Tomcat distribution (for non-singleton model)
- have a good
thnx man...
think i got a good start
cheers
sunil
- Original Message -
From: Bojan Smojver [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Monday, July 22, 2002 11:55 AM
Subject: Re: new velocity user
With pleasure :-)
It's actually quite simple:
- make
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=11026.
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=11026.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
This email is autogenerated from the output from:
http://jakarta.apache.org/builds/gump/2002-07-22/jakarta-tomcat-4.0.html
Buildfile: build.xml
deploy-prepare:
deploy-static:
deploy:
Does anyone know how to get the webapp name from ServletContext? Here
is a quick description of what i am trying to do.
I have a webapp that i want to load when tomcat starts. I want to make
sure the webapp only starts for one webapp and not the others.
I wrote a test class that implements
Does anyone know how to get the webapp name from ServletContext? Here
is a quick description of what i am trying to do.
I have a webapp that i want to load when tomcat starts. I want to make
sure the webapp only starts for one webapp and not the others.
I wrote a test class that implements
I figured out why I was getting null back from
SERVLETCONTEXT.getServletContextName(), my web.xml file didn't have the
display-namename/display-name defined. Now that I have it in there,
I see the event fired twice for my webapp.
Is that a bug? From what I can tell, it is creating the webapp
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=10629.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
On Sun, 21 Jul 2002, Bill Barker wrote:
At the moment, the servlet-mapping issue is somewhat of a red-herring, since
only 3.3.2-dev supports it (and even there, it is disabled by default). For
now, mod_jk(2) might as well assume that the physical jsp/vm file is there,
since Tomcat requires
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=10629.
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=10711.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Hi. I am trying to get Tomcat to log to JDK1.4's logging.
I tried implementing a o.a.c.logging.Logger subclass that forwarded
calls to commons-logging Log. This was unsatisfying because the
commons-logger unrolls the stack and logs the class.method of my
logger, not my logger's caller.
I
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=11042.
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=10629.
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=11043.
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=11045.
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=11045.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Why does Tomcat not use Log4j for its logging?
Dave.
-Original Message-
From: Bob Herrmann [mailto:[EMAIL PROTECTED]]
Sent: 22 July 2002 15:51
To: Tomcat Developers List
Subject: JDK 1.4 Logging
Hi. I am trying to get Tomcat to log to JDK1.4's logging.
I tried implementing
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=11045.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
On Mon, 2002-07-22 at 12:12, David Oxley wrote:
Why does Tomcat not use Log4j for its logging?
Some parts of Tomcat do use Log4j, other parts do not. I think
this is because different people have just chosen whatever
they felt was handy. Tomcat doesn't yet have a unified logging
strategy. I
Bob,
This is a useful piece of code. However, your patch can't go into Tomcat
as it will only compile with JDK 1.4. The standard builds of Tomcat that
are downloadable from the jakarta.apache.org are built using JDK 1.3 and
should be run without crashing Tomcat on JDK 1.2.
So, if you would
Humm... How about this instead (not that I am lazy)?
$ cvs diff -u catalina/build.xml
Index: catalina/build.xml
===
RCS file: /home/cvspublic/jakarta-tomcat-4.0/catalina/build.xml,v
retrieving revision 1.124
diff -u -r1.124
Bob Herrmann wrote:
Humm... How about this instead (not that I am lazy)?
$ cvs diff -u catalina/build.xml
Index: catalina/build.xml
===
RCS file: /home/cvspublic/jakarta-tomcat-4.0/catalina/build.xml,v
retrieving revision
Bob,
That would work. I forgot that Remy now puts out a JDK 1.4 build of
Tomcat and using the build flags would allow it to be picked up by users
of the JDK 1.4 builds.
Patrick
Bob Herrmann wrote:
Humm... How about this instead (not that I am lazy)?
$ cvs diff -u catalina/build.xml
I'm close to -1 on this patch.
I think the right long-term solution is to use commons-logging in
all tomcat and jasper, and stop defining our interfaces.
I am +1 on fixing commons-logger, this will probably be
usefull for other packages that switch to commons-logger.
Costin
On 22 Jul 2002,
On Mon, 2002-07-22 at 12:37, Remy Maucherat wrote:
Assuming people actually like the JDK 1.4 logger and think it's useful,
I like that solution better (there are flags, use them).
The JDK Logger is pretty cool. Although the default output is pretty
plain. I use it with my own formatter. My
[EMAIL PROTECTED] wrote:
I'm close to -1 on this patch.
I think the right long-term solution is to use commons-logging in
all tomcat and jasper, and stop defining our interfaces.
I am +1 on fixing commons-logger, this will probably be
usefull for other packages that switch to
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=11047.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
On Mon, 2002-07-22 at 13:00, [EMAIL PROTECTED] wrote:
I'm close to -1 on this patch.
I think the right long-term solution is to use commons-logging in
all tomcat and jasper, and stop defining our interfaces.
I am +1 on fixing commons-logger, this will probably be
usefull for other
On 22 Jul 2002, Bob Herrmann wrote:
This could be fixed by adding these methods to Log of commons-logger
void trace(Object msg, Throwable thr, String className, String method);
void debug(Object msg, Throwable thr, String className, String method);
void info(Object msg, Throwable thr,
On Mon, 2002-07-22 at 14:18, [EMAIL PROTECTED] wrote:
...
I think there is a simpler solution for this class of problems, and
that would also work with log4j and doesn't require _any_ API change.
( only changes to the adapter implementations )
Any 'wrapper' will use:
[EMAIL PROTECTED] wrote:
On 22 Jul 2002, Bob Herrmann wrote:
This could be fixed by adding these methods to Log of commons-logger
void trace(Object msg, Throwable thr, String className, String method);
void debug(Object msg, Throwable thr, String className, String method);
void
On 22 Jul 2002, Bob Herrmann wrote:
That is an interesting idea, although in my particular case, I walk
the stack a variable amount. Namely if the stack has method log() or
method internalLog() I keep unrolling the stack - this may not be
a great idea - but it gives good stack traces without
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=10967.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
remm2002/07/22 12:52:40
Modified:catalina/src/share/org/apache/catalina/loader
WebappClassLoader.java
Added: catalina/src/share/org/apache/catalina/loader
ResourceEntry.java
Log:
- Attempt to fix bug 10967.
- Move
remm2002/07/22 12:53:45
Modified:catalina/src/share/org/apache/catalina/loader
WebappClassLoader.java
Added: catalina/src/share/org/apache/catalina/loader
ResourceEntry.java
Log:
- Port fix for bug 10967.
- Move
amyroh 2002/07/22 13:16:33
Modified:webapps/tomcat-docs/funcspecs project.xml
Added: webapps/tomcat-docs/funcspecs mbean-names.xml
Log:
Add Tomcat MBean Names documentation that describes a naming convention
for Tomcat MBeans.
Revision ChangesPath
1.2
kinman 2002/07/22 13:35:27
Modified:jasper2/src/share/org/apache/jasper/compiler Node.java
PageInfo.java Parser.java ParserController.java
Validator.java
jasper2/src/share/org/apache/jasper/resources
bojan 2002/07/22 14:03:19
Modified:jk/native/apache-2.0 mod_jk.c
Log:
Put back DIR_MAGIC_TYPE in case there is no DirectoryIndex and/or no
pysical files to stat.
Lose one stat, not really needed. Fix a typo.
Revision ChangesPath
1.52 +10 -5
I have tested this with and without DirectoryIndex.
In case there is DirectoryIndex, the physical file(s) are stat and if
that's successful mod_dir does its thing. It works nicely for at least 2
different file extensions (in my case *.jsp and *.vm). If the files
cannot be stat, it's up the
If I remember correctly, I believe someone sent a patch for Japanese
support in admin webapp a while ago. I accidentally deleted the email
with the patch and cannot remember the title or the author. Does anyone
have that email or remember the title so I can search for it?
Thanks,
Amy
--
To
On 23 Jul 2002, Bojan Smojver wrote:
Important note:
---
THE CODE IN mod_jk2 IS STILL BROKEN, WITH DocumentRoot LOGIC.
-
Do you want me to:
[ ] Revert it back to what it was before I put my fingers in it
[ ] Leave
Before I do that, some questions about uriEnv in jk2_handler(), since
that part is very different to mod_jk. The initial test involves asking:
if (uriEnv==NULL || strcmp(r-handler,JK_HANDLER)!= 0)
and if so, the whole thing is skipped.
After the first test, there is the second test that goes:
For those of you tracking the JSP 2.0 specification, we are pleased to
announce the availability of an Early Access Preview implementation,
available now from:
http://developer.java.sun.com/developer/earlyAccess/jsp/
The primary goal of the JSP 2.0 specification is to make JSP technology
Not acked...
Pier
--
I love introducing bug: Floating Point Exception this is Access Violation,
Access Violation, this is Floating Point Exception. Eric Prud'Hommeaux
-- Forwarded Message
From: R Andrew Johnston [EMAIL PROTECTED]
Date: Mon, 22 Jul 2002 17:24:29 -0400 (EDT)
To:
luehe 2002/07/22 16:02:55
Modified:jasper2/src/share/org/apache/jasper/compiler
JspDocumentParser.java JspUtil.java
PageDataImpl.java TagConstants.java
TagLibraryInfoImpl.java
Log:
Added support for Tag File
bojan 2002/07/22 16:18:38
Modified:jk/native2/server/apache2 mod_jk2.c
Log:
Initial, most likely *BROKEN* code to handle default directory files. The
code in jk2_map_to_storage() should be OK.
Most critical stuff is in jk2_handler() function, the part of code that
I made an initial, most likely broken commit of this code for mod_jk2.
Can you go through it as I'm making assumptions in there that I am not
sure about. They are just a parallel from mod_jk, but that could be
totally bogus.
At least there is some 'meat' for you guys to play with.
Bojan
On
Hi,
I'm sorry if i'm posting it to the wrong list,
I found small problem in JNDIRealm and I suggest small change.
in method protected List getRoles(DirContext context,
String username, String dn)
is line
String role = (String) attr.get();
Hi all,
I am currently trying to get the JK/JK2 connectors working on MacOS X
(with little success so far, but that's another thing). Trouble already
starts compiling the native sources using the provided ant buildfiles.
To make life easier for other mac users, would you mind making the
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=11066.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
On Mon, 22 Jul 2002, Amy Roh wrote:
Date: Mon, 22 Jul 2002 14:54:05 -0700
From: Amy Roh [EMAIL PROTECTED]
Reply-To: Tomcat Developers List [EMAIL PROTECTED]
To: Tomcat Dev [EMAIL PROTECTED]
Subject: Missing patch for Japanese support in admin
If I remember correctly, I believe someone
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=11066.
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=10789.
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=11069.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
On 23 Jul 2002, Bojan Smojver wrote:
Before I do that, some questions about uriEnv in jk2_handler(), since
that part is very different to mod_jk. The initial test involves asking:
if (uriEnv==NULL || strcmp(r-handler,JK_HANDLER)!= 0)
uriEnv == null means no match was found.
It is set by
Dear Sir,
Kindly tell me wether Bug#: 7013 has been fixed or not.If yes then in which release
it has been
fixed.I am seeing the Release documents of 3.3 it says somthing but not clearly wether
the above
mentioned bug has been fixed or not.I`m using 3.2.2 version of Tomcat and facing
similar
Hello,
I have been looking at extending the SSLAuthenticator class to accept
Certificates AND Form type logins using a JDBC connector.
This would have seemed relatively simple - but I have not been able to
instantiate the j_security_check servlet for the SSLAuthenticator class
(as it seems to
Right now, the choice between FORM and CLIENT-CERT is an either-or choice
in the servlet spec -- you cannot choose both on the same web application.
The j_security_check URL is not actually mapped to a servlet -- it is a
magic URL that is only enabled (by FormAuthenticator) when the form
login
It should be possible to include this magic url in the SSLAuthenticator
class too, no?
thanks
From: Craig R. McClanahan [EMAIL PROTECTED]
Reply-To: Tomcat Developers List [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]
Subject: Re: How to start the
Quoting [EMAIL PROTECTED]:
It's jk_translate who decides if a request is to be handled by
jk ( by mapping it to a uriEnv ).
You can add a test for r-handler==DIR_MAGIC_TYPE, but don't assume
any uriEnv is set.
OK, I did that in jk2_handler(), which now seems like the wrong place to do it,
On Tue, 23 Jul 2002, Andrew Grosser wrote:
Date: Tue, 23 Jul 2002 04:39:09 +
From: Andrew Grosser [EMAIL PROTECTED]
Reply-To: Tomcat Developers List [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: How to start the j_security_check servlet if using
SSLAuthenticator
It
Hi,
I know that Tomcat is moving towards using the commons
db pool but there may be some people still using the
Poolman package to do connection pooling.
I created a PoolmanDataSourceFactory that can be
plugged into Tomcat 4.0.x and Tomcat 4.1.x to provide
Poolman managed pools through the
On Sun, 21 Jul 2002 [EMAIL PROTECTED] wrote:
On Mon, 22 Jul 2002, Bojan Smojver wrote:
it can already map any URI. All it has to do is:
- for each index:
Just reading the algorithm and thinking about the implementation of it. Some of
Well, don't take it as an algorithm - there
65 matches
Mail list logo
