Tomcat web page (http://jakarta.apache.org/tomcat/) currently lists the
releases in the order from the oldest to the newest in the description
section.
I propose those are listed in the more natural order, from the newest to
the oldest (i.e. TC 4.0.x, TC 3.3, TC 3.2.x, TC 3.1.x)
Vote to change t
Bill Barker wrote:
>
> It works for me, and if it just involves swapping 3.2 and 3.3 I don't see a
> problem (or, at least you'll win the vote). Personally I wouldn't try to
> move the 4.0 without first posting a [VOTE] (although since you're moving it
> up, it will likely win).
OOPS! Will have
Thanks. Didn't actually pay attention to that part. Fixing now...
BTW, do you think it would be better if the order of described releases
is changed? In other words, Tomcat 3.3/4.0 first and then others.
Bojan
Bill Barker wrote:
>
> You forgot to remove the "is in beta testing" from the 3.3 de
Silly to ask, but I'll do it anyway... in which CVS repository are the
files that appear on Tomcat section of Jakarta site? I've checked out
jakarta-site2, but it's not there.
Bojan
Bill Barker wrote:
>
> No objection here.
> - Original Message -
> Fr
I've noticed that on the main TC page of Jakarta site, TC 3.2.x is
still listed as production quality release, although we all know that
3.3 is far superior in almost any respect. That's for Servlet API 2.2
and JSP 1.1, of course.
Any objections if I change this?
Bojan
--
To unsubscribe, e
Weiqi Gao wrote:
> Pier Fumagalli wrote:
> >
>
>> Bojan Smojver at [EMAIL PROTECTED] wrote:
>>
>> > I have been trying to convince Sun people that 1.3.1 and 1.3.1_01
>> > HotSpot has problems on Linux, but they wouldn't buy it.
>> >
>
Pier Fumagalli wrote:
> Bojan Smojver at [EMAIL PROTECTED] wrote:
>
>
>>I have been trying to convince Sun people that 1.3.1 and 1.3.1_01
>>HotSpot has problems on Linux, but they wouldn't buy it.
>>
>>My suggestion is: use IBM's JDK 1.3.0. It is fast
I have been trying to convince Sun people that 1.3.1 and 1.3.1_01
HotSpot has problems on Linux, but they wouldn't buy it.
My suggestion is: use IBM's JDK 1.3.0. It is faster and more stable then
Sun's.
Bojan
Eddie Ruvinsky wrote:
> Hi all,
>
> Would anyone happen to know the fix to this?
I've seen some issues similar to those. Sometimes (I could not establish
the pattern for now), this is what appears in TC 3.3 logs:
---
2001-10-29 16:35:51 - ContextManager: Removing context www.dev.dev:/ROOT
2001-10-29 16:35:51 - Ctx() : Remove mapping
20
Quoting Pier Fumagalli <[EMAIL PROTECTED]>:
> And in case I don't see you, good afternoon, good evening and good
> bye...
Pier, my apologies for the Sun related e-mail on the list today. If I only knew,
I would never have sent it.
:-((
I wish you all the best in your future undertakings and I
Quoting Pier Fumagalli <[EMAIL PROTECTED]>:
> Bill Barker at [EMAIL PROTECTED] wrote:
>
> > I know that Jon has already pointed out that Sun is going to sue the
> 3.x
> > branch out of Jakarta in five months,
>
> I don't think Jon said that, and as a Sun employee I can guarantee
> that
> Tomcat
Do you think that it would be smart and/or desirable to 'enforce' the
check for all people that use sessions with SSL? In other words, if you
have a TC session, and you're running things over SSL, we enforce the TC
session ID and SSL session ID match.
If there are security experts out there (C
If you can, try out the 3.3. I find it much more stable and scalable
then 3.2.x.
Bojan
Endre Stølsvik wrote:
> I'm experiencing hangs when testing out a application with tomcat 3.2.3 on
> Sun's JRE 1.3.1_01 running on a Intel 733MHz Redhat 7.1 stock kernel,
> using only 2 PoolTcpConnector HTTP
Lee Bruce wrote:
>
> hi ,
> I installed Tomcat 4.0 at windows 2000 workstation version . The problem is
> : I don't know if the workstation version is enough , should I use "server
> edition" ? Do I need "IIS" ?
I think you should be able to run it even on Win 9x (from posts on this
list - don't
Marc Saegesser wrote:
> --
> Vote: Tomcat 3.2.4 Release Plan
> [ ] +1 I am in favor of the release, and will help support it
> [X] +0 I am in favor of the release, but am unable to help support it
> [ ] -0 I am not in fav
jean-frederic clere wrote:
> Yes, Bugzilla asks the right questions... So a form like the Bugzilla one that
> mails to the user list (of course telling that you have to subscribe to the list
> otherwise you question will be ignored).
Since they'd have to login to use the form (just like on Bugzi
jean-frederic clere wrote:
>
> Bojan Smojver wrote:
> >
> > I have subscribed myself to Tomcat User list a few days back with the
> > intention to help a few people on it (given my +1 on TC 3.3 final). I
> > have to say that the amount of e-mails and sometimes the
Jan Labanowski wrote:
>
> On Fri, 19 Oct 2001, Bojan Smojver wrote:
>
> >
> > I can't argue with that one since I'm very green here. But my thinking
> > is coming from the basic mailing list notion: ask your question in the
> > right forum.
>
>
"Craig R. McClanahan" wrote:
>
> On Fri, 19 Oct 2001, Bojan Smojver wrote:
>
> > Most of this has come from my totally different experience with Velocity
> > User mailing list. There are fewer messages and fewer developers
> > answering questions, but most
"Craig R. McClanahan" wrote:
>
> On Fri, 19 Oct 2001, Bojan Smojver wrote:
>
> > Date: Fri, 19 Oct 2001 08:59:27 +1000
> > From: Bojan Smojver <[EMAIL PROTECTED]>
> > Reply-To: [EMAIL PROTECTED]
> > To: Tomcat Dev List <[EMAIL PROTECTED
I have subscribed myself to Tomcat User list a few days back with the
intention to help a few people on it (given my +1 on TC 3.3 final). I
have to say that the amount of e-mails and sometimes the superficial
nature of them prevented me from actually doing any useful work. Don't
know about the res
+1
Bojan
PS. What's the world coming to these days - a guy from Sun has to ask
approval to become a Tomcat committer ;-)
Christopher Cain wrote:
>
> I would like to nominate Patrick Luby <[EMAIL PROTECTED]> for committer
> status. His recent contributions include several security-manager-relat
jean-frederic clere wrote:
> And in mod_jk.log file is there something?
Mostly something like this:
-
[Fri Oct 05 17:07:55 2001] [jk_ajp_common.c (914)]: Error
ajp_process_callback - write failed
[Fri Oct 05 17:07:55 2001] [jk_ajp_co
Bojan Smojver wrote:
> Since I can control the headers from my servlet, let my try with
> Content-length. Fingers crossed...
If think this can actually qualify as a bug in ab - even when I set
Content-Length header, it still says that that there are length
failures. Since jsession
[EMAIL PROTECTED] wrote:
> I think ( or guess ) that ab is checking the length of the first request,
> and if following requests have different lengths it assumes it's a
> failure.
>
> Could you check if your page returns the same thing ? Very strange..
I ran the thing with -v 99 and it shows o
Bojan Smojver wrote:
>
> Bojan Smojver wrote:
>
> > This goes OK on both 1.1.0 and 1.2.0, although some requests aren't
> > served (probably because no more threads are available in ajp13
> > connector - I run a max of 50).
>
> Has probably very little to
Bojan Smojver wrote:
> This goes OK on both 1.1.0 and 1.2.0, although some requests aren't
> served (probably because no more threads are available in ajp13
> connector - I run a max of 50).
Has probably very little to do with it. I tried more threads, but some
requests still fai
Try: http://jakarta.apache.org/site/mail2.html
Bojan
Sai Sekhar wrote:
>
> "Unsubscribe"
Just for fun I did this to exercise mod_jk/TC 3.3 combination:
---
ab -c 1 -n 1000 http://some/velocity/page.vm
---
This goes OK on both 1.1.0 and 1.2.0, although some requests aren't
served (probably because no more threads
"Schreibman, David" wrote:
>
> I'm submitting this with mixed feelings since the recent discussion has
> shown strong opinions about the utility of the SingleThreadModel.
STM as a concept has so many flaws that I tend to side with Jon (ie. it
should be dropped from the spec). Personally, I was d
Tested briefly against mod_jk 1.1.0 and mod_jk 1.2.0... Everything seems
to be chugging along quite fine.
Bojan
Jan Grant wrote:
> actually, I was more concerned with exposing implementation mechanisms
> in URIs; and future-proofing so that when index.jsp becomes
> index.csharpsp in the future (only kidding...) I'm not left with an
> unmanageable mess.
He, he, good one!
:-))
Bojan
Bojan Smojver wrote:
>
> [EMAIL PROTECTED] wrote:
>
> > I don't think I can do this alone ( if it sounded like I volunteer to fix
> > it - well, I need help ).
>
> > - Test.
>
> I'm one of those overly brave and too stupid that put CVS ve
Bojan Smojver wrote:
>
> I have done this with TC 3.3, Apache 1.3.20 + mod_jk and my own form
> based authentication:
Just to clarify here, 'my own' means in my own app, not something I've
coded separately from TC.
Bojan
I have done this with TC 3.3, Apache 1.3.20 + mod_jk and my own form
based authentication:
Pages:
/login/login.vm <-- login page
/login/error.vm <-- error page
/login/index.vm <-- default index page
If someone goes to /login/login.vm directly and gets authenticated, the
page /login/index.vm get
Christopher Cain wrote:
>
> Quoting [EMAIL PROTECTED]:
>
> > On Mon, 1 Oct 2001, Aaron Bannert wrote:
> >
> > > What are the main advantages to using an in-process VM as opposed
> > > to an out-of-process VM bridged over some form of IPC (like
> > > mod_webapp/mod_jk/mod_jserv)?
> >
> > Well, us
Bill Barker wrote:
>
> While pooling was a very nice feature of JServe (which I have personally
> taken advantage of in the past), the operative word in the spec is "may".
> The 3.x and 4.0 implementations are entirely within their rights within the
> spec to simply synchronize.
>
> In other wor
[EMAIL PROTECTED] wrote:
> Having a stable core is essential for module development and for enhancing
> the current set of modules. Even if there are many improvements we can add
> to 3.3, I believe the benefit of keeping 3.3 stable is far bigger.
Just to confirm this point, I've been running 3.
[EMAIL PROTECTED] wrote:
>
> On Wed, 26 Sep 2001, Keith Wannamaker wrote:
>
> > 0x3b = ';'. Ignacio is right, SessionID doesn't remove the id
> > because it is not expecting ; to be encoded. So now it shows
> > up in the URI and has the side effect of breaking sessions
> > that depend on url r
Keith Wannamaker wrote:
>
> 0x3b = ';'. Ignacio is right, SessionID doesn't remove the id
> because it is not expecting ; to be encoded. So now it shows
> up in the URI and has the side effect of breaking sessions
> that depend on url rewriting. But, the spec does say the URL
> should be encod
context mappings
> generated as well.
>
> Larry has added other options to allow you to specify the directories where
> various files go (e.g. mod_jk.so), but I don't remember them off the top of
> my head.
> - Original Message -
> From: "Bojan Smojver" <[E
The latest TC 3.3 CVS with its mod_jk, gives an encoded URI, together
with the session ID on HttpServletRequest.getRequestURI().
Example:
/login/login.vm%3bjsessionid=q95pbsuof1
Previously, jsessionid wasn't there. The change was intentional, right?
Bojan
alse"), then it outputs all of the
> defined mappings (including j_security_check for form auth contexts).
> - Original Message -
> From: "Bojan Smojver" <[EMAIL PROTECTED]>
> To: "Tomcat Dev List" <[EMAIL PROTECTED]>
> Sent: Tuesda
Unless this is now implemented automatically in mod_jk, I think it would
be worth mentioning in mod_jk HOWTO about the need to JKMount
j_security_check when form authentication is used in applications.
I think I should be able to fake a paragraph about it (with examples).
Bojan
"Morrison, John" wrote:
>
> The cvs list is moderated. It takes a little time the first time ;) Don't
> worry, it'll get there.
He, he, good one ;-)
Bojan
I've committed a patch to the repository today, expecting an automatic
e-mail to the tomcat-dev list when the commit happens. But it never did,
although the commit went through OK.
After searching the CVS manual for clues, I bumped into -i option for
modules, but that seems like an admin/setup ki
[EMAIL PROTECTED] wrote:
>
> On Tue, 25 Sep 2001, Bojan Smojver wrote:
>
> > I've read the thread about tabs/spaces/indentiation in Tomcat code and
> > it seems that at least TC 4 people are going with 4 spaces instead of
> > tabs (judging by comments from Craig
[EMAIL PROTECTED] wrote:
>
> Hi Bojan,
>
> +1 - looks very good, it'll be a great 'first commit'.
>
> ( 'normal' case with only global modules is not affected in any way, and
> for local modules it'll do the right thing, and update the context ).
Thanks. Wouldn't be able to do any of it withou
I've read the thread about tabs/spaces/indentiation in Tomcat code and
it seems that at least TC 4 people are going with 4 spaces instead of
tabs (judging by comments from Craig).
Does that apply to TC 3.3 as well?
Bojan
PS. I've noticed that a lot of TC 3.3 code still uses tabs, so when
patchi
This seems to do the trick. I've tested it with the JDBCRealm
interceptor and it behaves normally (ie. JDBCRealm gets hooked back in
and it actually works after the application reload).
Any feedback before this gets committed is welcome (as in: I'd rather
not screw up TC 3.3 RC with my first comm
[EMAIL PROTECTED] wrote:
> > My understanding is that ContextXmlReader actually produces 'fresh'
> > instances every time.
>
> True. Do you think it would be better ( or simpler ) to just change
> ContextXmlReader to create a new set of per/context interceptors ?
>
> My thinking was that the i
[EMAIL PROTECTED] wrote:
>
> Hi Bojan,
>
> A simpler solution is to fix ReloadInterceptor - and save the current list
> of interceptors before removing the context, then add all per/context
> interceptors after the context is added back ( those having getContext()
> != null ).
OK. I'll look int
Bojan Smojver wrote:
> Is this something that happens by design or am I looking at a possible
> bug?
By following what happens when TC starts and when it reloads the
context, it seems that there should be contextInit() method in
ContextXmlReader.
This interceptor is responsible for calli
Kenny Ma wrote:
>
> I need to restart tomcat everytime after i change my servlet program
> even I added "reloadable=true" in serevr.xml
>
> Anyone solve this problem ? please tell me
>
> thanks
Works in 3.3 but be careful with servlets packed in jars. It appears
that JDK has a few bugs in that
Bojan Smojver wrote:
>
> Just playing with Form authentication in TC 3.3. Have two Velocity pages
> that are doing the authentication with a JDBC Realm (for that context
> only). When Tomcat starts, all is fine. I get authenticated (or not)
> depending on username/password combi
Just playing with Form authentication in TC 3.3. Have two Velocity pages
that are doing the authentication with a JDBC Realm (for that context
only). When Tomcat starts, all is fine. I get authenticated (or not)
depending on username/password combination I supply. Subsequent visits
to the same pag
Here is commented and slightly reworked readFully(). It should do
(hopefully) the same thing as the old one but (hopefully again) with a
bit more fluff for the uninitiated like me.
Do you guys think that this method can be put into some sort of
'utility' package? It seems like something generally
This version should be more efficient and cleaner too.
Will do the old code with comments too.
Bojan
---
/home/groups/devel/jakarta/jakarta-tomcat/src/share/org/apache/tomcat/util/depend/DependClassLoader.java
Mon Sep 17 11:51:16 2001
+++
+jakarta-tomcat-changed/src/share/org/apache/tomca
Mike Anderson wrote:
>
> +1
>
> Keep up the good work Bojan!
>
> >>> [EMAIL PROTECTED] 09/17/01 05:43AM >>>
> I would like to propose Bojan Smojver as a committer.
> He has supplied a number of patches as well as done
> useful testing. I think he w
[EMAIL PROTECTED] wrote:
>
> Hi Bojan,
>
> First, you're a commiter now, feel free to fix anything you see
> broken :-)
Didn't know it was official. Thanks!
> Regarding this particular fix - it will not have a big performance
> impact ( except for loading .class files, which happen once ).
> H
After digging some more into the code of it, I've realized that the
readFully() method is really hard to understand. So, unless there are
some substantial performance gains in the existing approach, maybe we
should go with something a bit simpler.
And just as a side note, you've probably noticed
Pier Fumagalli wrote:
>
> "Bojan Smojver" <[EMAIL PROTECTED]> wrote:
>
> > Pier Fumagalli wrote:
> >>
> >> "Bojan Smojver" <[EMAIL PROTECTED]> wrote:
> >>
> >>> Hi Pier,
> >>>
> >>>
Pier Fumagalli wrote:
>
> "Bojan Smojver" <[EMAIL PROTECTED]> wrote:
>
> > Hi Pier,
> >
> > I can see by the number of recent commits that you are very busy with
> > mod_webapp. Can you tell me if the new stuff will include support for
> &
Hi Pier,
I can see by the number of recent commits that you are very busy with
mod_webapp. Can you tell me if the new stuff will include support for
mod_webapp with a statically linked Apache of is it still DSO only?
Bojan
[EMAIL PROTECTED] wrote:
>
> On Sat, 15 Sep 2001, Bojan Smojver wrote:
>
> > - if the jar file is changed, the application will reload (due to some
> > recent fixes there in DependClassLoader), but some resources might not
> > get loaded properly (for instance a prope
[EMAIL PROTECTED] wrote:
>
> On Sat, 15 Sep 2001, Bojan Smojver wrote:
>
> > Remy Maucherat wrote:
> >
> > > TC 4 uses a 100% custom URLClassLoader clone, and it accesses the JARs
> > > directly (using JarFile objects). I'm really careful about prop
Remy Maucherat wrote:
> TC 4 uses a 100% custom URLClassLoader clone, and it accesses the JARs
> directly (using JarFile objects). I'm really careful about properly closing
> these objects when the CL is dumped when reloading. However, there are still
> problems, at least under Windows (the sympt
Remy Maucherat wrote:
> > My environment is JDK 1.3.1_01, Linux. In some other discussions, people
> > from TC 4 team mentioned that there are similar problems on Windows too.
>
> TC 4 uses a 100% custom URLClassLoader clone, and it accesses the JARs
> directly (using JarFile objects). I'm reall
I'm playing with Classloader issues in Tomcat 3.3 (but from what I hear
it's not much different in TC 4) and the whole thing behaves really,
really strange. This is what I can observe, with automatic reloading
enabled:
- a jar file in WEB-INF/lib will be picked up with no issues the very
first ti
If debugging is enabled and sw is null, it blows up (NPE). Patch
follows.
Bojan
---
/home/groups/devel/jakarta/jakarta-tomcat/src/facade22/org/apache/tomcat/facade/ServletHandler.java
Mon Jul 23 09:00:00 2001
+++ jakarta-tomcat/src/facade22/org/apache/tomcat/facade/ServletHandler.javaFri
ing( 0, idx) ;
> - f=new File( fileN );
> - if( debug > 0 ) log( "Jar dep " +f );
> + // Bojan Smojver <[EMAIL PROTECTED]>: remove jar:
> + if( fileN.startsWith( "jar:" ))
> + fileN=fileN.substring( 4 );
Just reformatting the e-mail to look like an actual patch. Sorry for not
following the conventions earlier.
Bojan
---
/home/groups/devel/jakarta/jakarta-tomcat/src/share/org/apache/tomcat/util/depend/DependClassLoader.java
Tue Sep 11 17:42:11 2001
+++ src/share/org/apache/tomcat/util/depend
Just for the fun of it, I've tried to enable AccessLogInterceptor (all
defaults) in server.xml, but it actually causes NullPointerException in
line 199.
Line 199 is:
--
fw.write(request.remoteHost().toString());
Thanks.
Bojan
Larry Isaacs wrote:
>
> Its hard wired near the end of the Ajp13Request class.
> Its now fixed. Thanks for finding this.
>
> Larry
"Craig R. McClanahan" wrote:
>
> Christopher Cain has raised some concerns (both in private email and
> publicly on this list) regarding the initialization of pseudo random
> number generators (PRNGs) used to calculate session id values. We need to
> have a quick discussion about this, to determ
I've notice that the most recent Ajp13Interceptor prints something like
this into log files:
--
Ajp13Request: Read:
formid=order&email=a%40aa&customer=a&address=a&city=a&state=a&postcode=a&country=Bermuda&shipping=air&product=Pooh+Cosmology+and+the+Quantum+
Bojan Smojver wrote:
>
> [EMAIL PROTECTED] wrote:
> >
> > Sorry, I had a lot on my had in the last days.
> >
> > Bojan - if you want to send a patch, it would be great. If not - I can fix
> > the bug ( but I would prefer you to send a patch - who knows, may
[EMAIL PROTECTED] wrote:
>
> Sorry, I had a lot on my had in the last days.
>
> Bojan - if you want to send a patch, it would be great. If not - I can fix
> the bug ( but I would prefer you to send a patch - who knows, maybe later
> you'll send another one, the first is allways harder :-)
>
> C
Since I was playing with distributing all my apps in jars...
In method dependency() of that class, there is a section for jars. It
goes something like this:
if( "jar".equals( res.getProtocol() )) {
String fileN=res.getFile();
int idx=f
Larry Isaacs wrote:
> Hope this helps,
>
> Larry
OOPS. Trigger happy! Take 2 :-)
Bojan
--- /home/groups/devel/jakarta/jakarta-tomcat/src/doc/tomcat-ug.htmlSat Aug 18
11:25:01 2001
+++ tomcat-ug.html Fri Aug 24 23:19:05 2001
@@ -1313,24 +1313,14 @@