Re: F....

Well, I am not that good at getting all this flames ( and to be honest I'm not used to get the "thanks" that I got lately - mostly in private mail - it looks like a very different world, and an wonderful Christmas gift for me ) In any case, I'll try to stay away from further arguments - I know no

Re: back port to 3.2 --> JspInterceptor

Hi Pierre, JspInterceptor is not "enabled" in 3.2 - it was one of the changes I wanted to spend more time into and make sure it's stable enough. It'll be used in 3.3 - or whatever will be called. BTW, did you fixed the command line compiler ? JspInterceptor is based on the command line compil

Re: [tomcat-4.0] Session Creation Slowness

> > > > > Is there a particular page I should go to for triggering session creation? I want > to try this with 4.0-m5 and also with the updates I just checked in (which will > appear in tonight's nightly build). the above url is enough. i will try o

Re: Bug Report #649

Tomoaki From: Tomoaki Okitsu <[EMAIL PROTECTED]> Subject: Bug Report #649 Date: Fri, 22 Dec 2000 10:32:32 +0900 Message-ID: <[EMAIL PROTECTED]> > http://tomcat.3.2.1/examples/jsp/num/numguess.jsp%20 I test this url. But I get "404 Not Found" and don't see a JSP source code. This bug may be syst

Re: Bug #55: Default for included files is 8859_1, with no optionto set otherwise

> Maybe I'm not reading carefully enough (and I haven't had time to trace the > code) but I don't understand what you mean in your "modifications". > > The correct behavior seems to me that when a file is included, a 'fake' > JspReader should be created to scan the file for a @page directive w

Re: [tomcat-4.0] Session Creation Slowness

Jon Stevens wrote: > > >> If you want to duplicate it, you can check Scarab out of CVS and do it > >> yourself. I have re-done the CVS tree and it is very easy to get things up > >> and running (even without a database installed...just ignore that part of > >> the README.txt file). > >> > >>

RE: Bug #55: Default for included files is 8859_1, with no option to set otherwise

Pierre Delisle is wondering: > - > Bug #55 > >- >Synopsis: > Default for included files is 8859_1, with no option to > set otherwise. > [SNIP] > I'm not sure I fully understand what's described there, > so here is what I believe should be done. > > The "encoding" for a

back port to 3.2 --> JspInterceptor

Tried to back port the last fix I made to Jasper in tomcat 4.0 to tomcat 3.2 (the fix related to bug report #269 -- java encoding). Was almost there until I realized there is a new class "JspInterceptor" in tomcat 3.2 that is impacted by that fix. Unfortunately, I'm not too knowledgeable about

Re: Bug #55: Default for included files is 8859_1, with no option to set otherwise

Hans Bergsten wrote: ... > So, > the only possible remaining thing I can think of is to make > sure the encoding specified by jspEncoding is also used as > the "-encoding" argument to the javac command. It is. -- Pierre

Re: Bug #55: Default for included files is 8859_1, with no option to set otherwise

Hans Bergsten wrote: > [...] > I had forgot I filed a bug report on this, with a suggested > solution even ;-) > > But what I really meant with the comment was actually which > encoding to use for javac if the main JSP file specifies > "Shift_JIS" and an included file specified "UTF-8". But maybe

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session ManagerBase.java StandardManager.java

craigmcc00/12/21 17:54:34 Modified:catalina/src/share/org/apache/catalina/session ManagerBase.java StandardManager.java Log: Cause the random number to be initialized when a webapp first starts, rather than waiting for the first call to request.getSession()

Re: Bug #55: Default for included files is 8859_1, with no option to set otherwise

Pierre Delisle wrote: > > Hans, > > > What about the javac encoding? I believe it's currently hardcoded > > as "UTF8" (in Compiler at least). I'm not sure what it should be > > in case different included pages specify different charsets ... > > If you refer to bug report #269, I have a fix comi

Re: F....

I have been following this insane tomcat 4 vs tomcat 3 debate with increasing amazement.  I cannot understand why this has become such a big issue.  Attempting to tell an open source developer what to write is pretty much counter to ESR's cited prime motivation for open source development - scratc

Bug Report #649

hi please see #649 http://tomcat.3.2.1/examples/jsp/num/numguess.jsp%20

cvs commit: jakarta-tomcat-4.0/catalina/src/conf web.xml

pierred 00/12/21 17:31:03 Modified:catalina/src/conf web.xml Log: New JspServlet init parameter for alternate java encoding used when generating Jsp pages servlet source code. The default java encoding used is UTF8. This alternate is set by default to UTF-8. Revision Cha

cvs commit: jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/resources messages.properties

pierred 00/12/21 17:27:39 Modified:jasper/src/share/org/apache/jasper EmbededServletOptions.java JspC.java Options.java jasper/src/share/org/apache/jasper/compiler Compiler.java jasper/src/share/org/apache/jasper/resources

RE: help EJB

try www.jboss.org   good luck jatin -Original Message-From: Boby Micheal [mailto:[EMAIL PROTECTED]]Sent: Thursday, December 21, 2000 1:12 AMTo: [EMAIL PROTECTED]Subject: help EJB   We are soft ware developers(Calrion systems (P)Ltd. , Cochin ,Kerala, India).Now we ar

Re: Bug #55: Default for included files is 8859_1, with no option to set otherwise

Hans, > What about the javac encoding? I believe it's currently hardcoded > as "UTF8" (in Compiler at least). I'm not sure what it should be > in case different included pages specify different charsets ... If you refer to bug report #269, I have a fix coming in the next few minutes. [testing it

Re: Bug #55: Default for included files is 8859_1, with no option to set otherwise

Pierre Delisle wrote: > > Trying to close a few Jasper bugs before the holiday break. > I'd appreciate at least another pair of eyes to review what I believe > should be done on that one... -- Pierre > > - > Bug #55 > >- >Synopsis: > Default for included files is 8859_1, w

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup ContextConfig.java HostConfig.java

craigmcc00/12/21 16:37:52 Modified:catalina/src/share/org/apache/catalina/loader StandardLoader.java catalina/src/share/org/apache/catalina/startup ContextConfig.java HostConfig.java Log: Second (and last) round of chang

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader FileClassLoader.java

craigmcc00/12/21 16:34:37 Removed: catalina/src/share/org/apache/catalina/loader FileClassLoader.java Log: FileClassLoader has been obsolete for a while -- remove it to avoid any potential confusion.

BugRat Report #650 has been filed.

Bug report #650 has just been filed. You can view the report at the following URL: REPORT #650 Details. Project: Tomcat Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: high Severity: serious Co

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup Bootstrap.java

craigmcc00/12/21 15:47:20 Modified:catalina/src/share/org/apache/catalina/startup Bootstrap.java Log: Modify the bootstrap program to call file.getCanonicalPath() rather than file.getAbsolutePath() when constructing "file:" URLs to declare as repositories

Bug #55: Default for included files is 8859_1, with no option to set otherwise

Trying to close a few Jasper bugs before the holiday break. I'd appreciate at least another pair of eyes to review what I believe should be done on that one... -- Pierre - Bug #55 - Synopsis: Default for included files is 8859_1, with no option to set otherwise. Report

cvs commit: jakarta-tomcat/src/share/org/apache/jasper/compiler JspParseEventListener.java

pierred 00/12/21 15:25:28 Modified:src/share/org/apache/jasper/compiler Tag: tomcat_32 JspParseEventListener.java Log: Check for null value before invoking method. From email sent by Brian Bucknam: It's a long story, but I'm working on a project whe

Re: Tomcat session replicator

Craig R. McClanahan wrote: > At ApacheCon Europe (it was also presented in Orlando last March, but I missed > it then), there was a very interesting session by Theo Schlossnagle > <[EMAIL PROTECTED]> about the Backhand Project, which is focused on providing > load balancing support for Apache as

cvs commit: jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler JspParseEventListener.java

pierred 00/12/21 15:16:42 Modified:jasper/src/share/org/apache/jasper/compiler JspParseEventListener.java Log: Check for null value before invoking method. From email sent by Brian Bucknam: It's a long story, but I'm working on a project where Jaspe

Re: Fuck It.

"Pier P. Fumagalli" wrote: > Christopher Cain wrote: > > > > "Pier P. Fumagalli" wrote: > > > > > Where were you KIDS when we were fighting the big > > > corporations to have them looking into open source, to contribute > > > significant parts of their technologies to the Foundation, where were y

Re: [tomcat-4.0] Session Creation Slowness

on 12/21/2000 2:35 PM, "Craig R. McClanahan" <[EMAIL PROTECTED]> wrote: > Yep, although that's probably something that could be changed. +1 >> more with this 4-5 seconds. If so, then I think that 4-5 seconds is to slow >> as well and we should find another RNG solution. > > Patches are welcome

mod_webapp / mod_jk

Pier, I wanted to ask you some questions about mod_webapp, and how you might see it working with mod_jk. I seem to have become the default ajp13 / mod_jk expert, and people have been asking for various extensions. I'm reluctant to invest much work in mod_jk/ajp13, given that TC 4.0 is using

RE: TC 3.2 - Better logging messages when something bad happens?

Thanks for the reply, > From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] > > David Rees wrote: > > > Anyone have any technical comments on the message below? I think that > > printing a stack dump in this case can be very useful, but > someone else may > > have a different view. > > > > For

Re: [tomcat-4.0] Session Creation Slowness

Jon Stevens wrote: > > I can deal with 4-5 seconds although that is a bit long as well. Is this > code re-executed when the classloader is dumped as well? Yep, although that's probably something that could be changed. > If not I can deal > more with this 4-5 seconds. If so, then I think that 4-

Re: Tomcat 3.3

Quoting "Pier P. Fumagalli" <[EMAIL PROTECTED]>: > "Craig R. McClanahan" wrote: > > > > For the record, Sun hired me in March, 2000, so that I could work on > Tomcat full > > time instead of it just being a hobby (as it was when the original > code was > > written). :-) > > And thank you for n

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup Bootstrap.java

craigmcc00/12/21 14:27:12 Modified:catalina/src/share/org/apache/catalina/startup Bootstrap.java Log: Add some debugging instrumentation (still disabled by default) to track down the "non-normalized" URLs issue. If you start Catalina using the standard s

Re: F....

on 12/21/2000 2:18 PM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > Tomcat3.2 is a big step forward versus Tomcat3.1 - but it still have many > issues - take a look at the ContextManager in 3.3, compare it with 3.2 - > there are still many undefined behaviors, even code from 3.0. Tomcat 3.2

Re: [tomcat-4.0] Session Creation Slowness

on 12/21/2000 2:04 PM, "Craig R. McClanahan" <[EMAIL PROTECTED]> wrote: > Jon Stevens wrote: > >> Ok, I put a whole bunch of logging into Turbine to see *exactly* what line >> of code is causing the slowness that I keep reporting here and I have now >> found it... >> >> Log.note ("RunDataFactor

Re: Tomcat 3.3

Yeah i saw that. I'm planning a few updates. Jon Stevens wrote: > on 12/21/2000 1:13 PM, "Craig R. McClanahan" <[EMAIL PROTECTED]> > wrote: > > > updating the web site is yet another useful way to > > contribute). > > It is even documented on how to do that! > >

Re: F....

> > I just had to deal with a major change in Apache2.0 - > > it seems some time ago they reorganized the whole > > tree, > > moved apr in a different repository, etc. Is this a > > different architecture ? > > Apache 2.0 is not yet OUT in final... Try to go down in HTTP land and > build a 1.4 on

Re: Future

on 12/21/2000 1:44 PM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: >>> Speaking of future, the same thing can happen when the next servlet spec >>> is released - and again you could use tomcat3.3 to have a smooth future. >>> I know how painfull it is to upgrade a production server - how many s

RE: [tomcat-4.0] Session Creation Slowness

This is probably due to the new SecureRandom-based session IDs. There is an option to turn that off somewhere. -Original Message- From: Jon Stevens [mailto:[EMAIL PROTECTED]] Sent: Thursday, December 21, 2000 1:47 PM To: tomcat-dev Cc: [EMAIL PROTECTED] Subject: [tomcat-4.0] Session Creat

BugRat Report #649 has been filed.

Bug report #649 has just been filed. You can view the report at the following URL: REPORT #649 Details. Project: Tomcat Category: Bug Report SubCategory: New Bug Report Class: webbug State: received Priority: high Severity: serious C

Re: [tomcat-4.0] Session Creation Slowness

Jon Stevens wrote: > Ok, I put a whole bunch of logging into Turbine to see *exactly* what line > of code is causing the slowness that I keep reporting here and I have now > found it... > > Log.note ("RunDataFactory: 11"); > // Get the HttpSession object. > data.setSession

Re: Fuck It.

Quoting Costin Manolache <[EMAIL PROTECTED]>: > That's even worse - all the flames that start up > whenever code from 4.0 is reused in 3.x. What's the > problem ??? Are you afraid of "featurism" ( i.e. are > good for 4.0 but bad for 3.3 ) ? > > It's open source code, and it's right to reuse it

RE: Fuck It.

Quoting Nacho <[EMAIL PROTECTED]>: > Please be carefull when you write something about anybody, have a look > at commits please... Henri, P. Delisle and I are the only ones here > that > had contribute to ALL present versions of Tomcat, *ALL* dont forget > that, and i feel involved on ALL of them

Re: Fuck It.

Nacho wrote: > > > > Why we are not talking about that ? > > > > Because we already did, we closed that discussions months ago when the > > first 4.0 proposal came out and was voted upon. Where was your -1 when > > the decision was made? Sorry, but you're too late now. > > > > Perhaps!! check th

Re: F... It.

> > > > The future of Tomcat 3.3 seems to be outside Apache now. > > It's really sad. > > Sorry, but that's not what I said Henry. Last month I even came up with > a proposal that got accepted (but never turned to reality) on how to > handle this situation... But it seems to me, that everyone he

Re: Tomcat 3.3

on 12/21/2000 1:13 PM, "Craig R. McClanahan" <[EMAIL PROTECTED]> wrote: > updating the web site is yet another useful way to > contribute). It is even documented on how to do that! :-) -jon -- Honk if you love peace and quiet.

[tomcat-4.0] Session Creation Slowness

Ok, I put a whole bunch of logging into Turbine to see *exactly* what line of code is causing the slowness that I keep reporting here and I have now found it... Log.note ("RunDataFactory: 11"); // Get the HttpSession object. data.setSession ( data.getRequest().getSession(t

RE: Fuck It.

> > Why we are not talking about that ? > > Because we already did, we closed that discussions months ago when the > first 4.0 proposal came out and was voted upon. Where was your -1 when > the decision was made? Sorry, but you're too late now. > Perhaps!! check that http://marc.theaimsgroup.co

Re: cvs commit: jakarta-tomcat/src/doc NT-Service-howto.html

[EMAIL PROTECTED] wrote: > marcsaeg00/12/21 11:24:21 > > Modified:src/doc Tag: tomcat_32 NT-Service-howto.html > Log: > Added notice about the NT service termination feature of JDK1.3 > > Revision ChangesPath > No revision > > > No rev

Re: Future

> > Speaking of future, the same thing can happen when the next servlet spec > > is released - and again you could use tomcat3.3 to have a smooth future. > > I know how painfull it is to upgrade a production server - how many small > > things will stop working and many things will be different. >

Re: Tomcat 3.3

Andy wrote: > > From your comments I have a question: Has 4.0 been voted on ? ( if this is > politically charged please read this in the context it is intended which is NOT > controversy, I'm a programmer not a political type)... Yes, Tomcat 4.0 as been voted on months ago and all -1s have be

Re: Tomcat session replicator

Jason Brittain wrote: > Hi guys.. > > I'm one of the other folks that have voiced some desire to implement > distributed sessions and distributed servlet container functionality in > Tomcat (although I only want to work on 4.0!). I'd love to collaborate > with others on the design and implementa

Re: Fuck It.

Christopher Cain wrote: > > "Pier P. Fumagalli" wrote: > > > Where were you KIDS when we were fighting the big > > corporations to have them looking into open source, to contribute > > significant parts of their technologies to the Foundation, where were you > > while we were changing this world

BugRat Report #648 has been filed.

Bug report #648 has just been filed. You can view the report at the following URL: REPORT #648 Details. Project: Tomcat Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: medium Severity: critical

Re: Tomcat 3.3

"Craig R. McClanahan" wrote: > > For the record, Sun hired me in March, 2000, so that I could work on Tomcat full > time instead of it just being a hobby (as it was when the original code was > written). :-) And thank you for not accepting my offer at that time, otherwise you would be working o

Re: help EJB

Tomcat does not handle EJB and there is no way to make it do that unless you add some extension server, something like the one from this site. www.ejboss.org Try it, it should work with Tomcat.   Ahmed Alawy.   Boby Micheal <[EMAIL PROTECTED]> wrote: We are soft ware developers(Calrion syst

Re: Fuck It.

Jon Stevens wrote: > > Therefore, as long as 3.x does not have support for 2.3, it is a dead end > solution IMHO and adding support for 2.3 within 3.x would be a duplication > of effort since we already have a 2.3 container (hence the reason why I am > -1 and why Costin has already stated he plan

Re: Fuck It.

Nacho wrote: > > I believe that architecture of 3.3 is right one. And you're free to believe what you want. As I am... > Why we are not talking about that ? Because we already did, we closed that discussions months ago when the first 4.0 proposal came out and was voted upon. Where was your -1

Re: TC 3.2 - Better logging messages when something bad happens?

David Rees wrote: > Replying to my own message here, > > Anyone have any technical comments on the message below? I think that > printing a stack dump in this case can be very useful, but someone else may > have a different view. > For developers, you certainly want to be able to see the stack

Re: Fuck It.

Costin Manolache wrote: > > > they were. Jon, you might > > be annoying and obnoxious at times, but those kids > > don't even care about reading what you're writing... > > Too bad all this is on an open mailing list where the > mails can be read again and again - and people may > form their own

Re: Tomcat 3.3

Andy wrote: > > Maybe the best thing would be if one of the commiters gave me a piece of their > bug they don't feel like finding. > The interim bug reporting system we are using has tons of outstanding bugs. I would not bother with the Tomcat 3.1 bugs -- anyon

Re: Tomcat session replicator

Hi guys.. I'm one of the other folks that have voiced some desire to implement distributed sessions and distributed servlet container functionality in Tomcat (although I only want to work on 4.0!). I'd love to collaborate with others on the design and implementation. More below: Craig R. McCl

Re: Fuck It.

GOMEZ Henri wrote: > > It's more a question than a request. I was really sad with Pier > reaction. I really don't want to appear as a someone disturbing the > Tomcat Project. As I don't want to appear as someone who gave up Jakarta and XML to Sun and IBM respectively... And that's what you said.

Re: Fuck It.

Sam Ruby wrote: > > As Pier recently said on another mailing list "You can't stop open source > developers...". And I'm not here to stop them... Proove me wrong :) :) :) > Is this really what everybody wants? I'm sure it could be made to happen. > And quickly upgraded to the latest servletapi.

Re: Fuck It.

Sam Ruby wrote: > > Pier Fumagalli wrote: > > > > So, here I stand, my vote is a big -1 on a 3.3 as a newly > > architected servlet container > > Pier, I beg of you to reconsider. Read my email in detail... Read that phrase. I don't vote -1 on 3.3. I vote -1 if 3.3 is based on a new architectur

java.lang.UnsatisfiedLinkError: init

Hello Mr. McClanahan and thanks advance for your prompt answer, My applet code needs to use javascript functionality for navigating through parent and child windows. When I try to

Re: Fuck It.

GOMEZ Henri wrote: > > The future of Tomcat 3.3 seems to be outside Apache now. > It's really sad. Sorry, but that's not what I said Henry. Last month I even came up with a proposal that got accepted (but never turned to reality) on how to handle this situation... But it seems to me, that everyo

RE: TC 3.2 - Better logging messages when something bad happens?

Replying to my own message here, Anyone have any technical comments on the message below? I think that printing a stack dump in this case can be very useful, but someone else may have a different view. Thanks, Dave > -Original Message- > From: David Rees [mailto:[EMAIL PROTECTED]] > Se

Re: Tomcat 3.3

"Craig R. McClanahan" wrote: > Andy wrote: > > > But, that being the case (and I know I'm touching on a sore spot) what will > > be the lifespan of 3.3. > > Since a proposal to publish a "Tomcat 3.3" has never been formally presented and > voted on, the only logically correct answer is "I don't k

Re: Fuck It.

"Rob S." wrote: > > Of what value would enhancing JServ to the point of technical perfection, be > right now when it is clearly not the direction things are headed? To me, if > someone said, "i want to make all these great changes to JServ" I'd be like, > "ok sure, but no one is going to use it

Re: Fuck It.

on 12/21/2000 11:11 AM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > Tomcat3.3 is designed to allow multiple facades - while it'll be only a > servlet 2.2 container, people can make a Servlet2.3 module available and > you will be able to do a gradual transition ( and when all your > applicat

Re: Tomcat session replicator

> Two weeks ago I posted note here saying I'm going to write patch for Tomcat > 3.2 to support redundancy, in manner of having session information stored > between reloads and shared between tomcat instances. > In order to support tomcat redundancy I thought on implementing that in two > phases:

Re: [humor] Why should I care what color the bikeshed is?

Jon Stevens wrote: > > +1 - Sam Ruby

How do you spell relief?

Title: How do you spell relief? Jon, Thanks (and thank God) for comic relief (which is nevertheless not off-topic). Roy -- Roy Wilson E-mail: [EMAIL PROTECTED] >> Original Message << On 12/21/00, 2:16:48 PM, Jon Stevens <[EMAIL PROTECTED]> wrote regarding [

BugRat Report #646 has been filed.

Bug report #646 has just been filed. You can view the report at the following URL: REPORT #646 Details. Project: Tomcat Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: high Severity: critical C

cvs commit: jakarta-tomcat/src/doc NT-Service-howto.html

marcsaeg00/12/21 11:24:21 Modified:src/doc Tag: tomcat_32 NT-Service-howto.html Log: Added notice about the NT service termination feature of JDK1.3 Revision ChangesPath No revision No revision 1.2.2.4 +13 -4 jak

help EJB

  We are soft ware developers(Calrion systems (P)Ltd. , Cochin ,Kerala, India).Now we are developing application in EJB under weblogic server. We required  to deploy the application (what we developed in EJB under weblogic server)in Tomcat server. Please give me a step by step Instructions

[humor] Why should I care what color the bikeshed is?

-jon

Re: Tomcat session replicator

Shai, I apologize for not responding to you earlier ... substantive discussions are getting a little lost in the noise at the moment. For some reason, my Netscape mail reader won't let me intersperse comments -- so I've put them at the end. I think I read into your earlier comment that you'd be

Re: F**k It. (off topic)

[EMAIL PROTECTED] wrote: > I don't mean to sound as though I am a prude, but we do a lot of our > consulting at customer sites, much of it face-to-face with the customer's > staff and management. I can control what messages I read and when but I > cannot control when people are in my office and

Re: Fuck It.

> Not true at all. 3.x only implements Servlet API 2.2 and 4.0 implements > Servlet API latest and greatest. > > On top of it, I (and others) would be STRONGLY -1 for adding Servlet API 2.3 > support to 3.x within the Jakarta project. That is why Costin has already > agreed and stated that he wil

Tomcat session replicator

Hi,   Two weeks ago I posted note here saying I’m going to write patch for Tomcat 3.2 to support redundancy, in manner of having session information stored between reloads and shared between tomcat instances. In order to support tomcat redundancy I thought on implementing that in two pha

Re: [T4][Classloaders][PATCH Suggestion] Bug in toURL() and new URL(x,x,x,x)

Stuart Roebuck wrote: > In the course of fixing a problem I was having getting Apache Cocoon to run, I came >across a bug in Java in the File.toURL() method. This fault, combined with the use >of the URLClassLoader resulted in a classloading issue. > Stuart, I'm trying to create a simple,

Re: Fuck It.

"Pier P. Fumagalli" wrote: > Where were you KIDS when we were fighting the big > corporations to have them looking into open source, to contribute > significant parts of their technologies to the Foundation, where were you > while we were changing this world? You were home, and one day, you looke

RE: Fuck It.

On Thu, 21 Dec 2000, Rob S. wrote: > Correct me if I'm wrong, but maybe the whole focus of 3.3 / 3.2.x thing, is > that neither of them will be all that they could be because the resources > are so limited and divided. About the same resources that made the evolution from 3.1 to 3.2 are availabl

Re: F**k It. (off topic)

I don't mean to sound as though I am a prude, but we do a lot of our consulting at customer sites, much of it face-to-face with the customer's staff and management. I can control what messages I read and when but I cannot control when people are in my office and when the message alert with the

Re: help for EJB

  Boby Micheal wrote:   We are soft ware developers(Calrion systems (P)Ltd. , Cochin ,Kerala, India).Now we are developing application in EJB under weblogic server. We requiredto deploy the application (what we developed in EJB under weblogic server)in Tomcat server. Please give me a step by s

Re: Tomcat 3.3

Andy wrote: > But, that being the case (and I know I'm touching on a sore spot) what will > be the lifespan of 3.3. Since a proposal to publish a "Tomcat 3.3" has never been formally presented and voted on, the only logically correct answer is "I don't know." Depending on the results of a vote,

Re: Changes to the servletapi build.xml file

This is definitely the place ... thanks Sean! Jon Stevens has committed some changes to the servletapi build scripts.  I will take a look and merge your ideas for anything he missed. Craig   Sean wrote: I had to made changes to the build.xml file to get it to work with the latest version of any

Re: How to do my own JSP processing

Christian Mallwitz wrote: > Hi, > > I want to write a servlet that reads JSP files from somewhere outside the > servlets web application context, compiles them to a location outside the > servlets web application (if necessary) and then invokes the compiled > servlet class. > > I started looking

Re: Tomcat 3.2.1 bug if not root-context defined.

Hi Klaus, I ran into this as well and thought it was particular to the way that Tomcat is integrated with Enhydra. I think I have a fix for it. I'll try to get a patch together and post it soon. Shawn Klaus Friedel wrote: > Tomcat 3.2.1 fails to deliver a resource, if no root-context is defi

Re: Fuck It.

on 12/21/2000 9:44 AM, "Rob S." <[EMAIL PROTECTED]> wrote: > So at the end of all of this, we have slowed development of 4.0 while we end > up with a functionally equivalent container to 3.2.1, but with more bugs, Just to clarify your misconceptions: Not true at all. 3.x only implements Servlet

Getting around Facade

I am interested in calling toString on a Request, but am prevented from this by the Facade wrapping infrastructure. I understand the security reasons for this, but want to see the stringified Request. I tried getting the Context and creating a SimpleFacadeManager, but I got some run time errors

Tomcat 3.2.1 bug if not root-context defined.

Tomcat 3.2.1 fails to deliver a resource, if no root-context is defined in serverl.xml. If you do not define the root-context "" in server.xml and request a non-existing resource, Tomcat will loop forever in PrefixMapper.getLongestPrefixMatch() trying to find a Container for "". Bye, Klaus.

help for EJB

  We are soft ware developers(Calrion systems (P)Ltd. , Cochin ,Kerala, India).Now we are developing application in EJB under weblogic server. We required  to deploy the application (what we developed in EJB under weblogic server)in Tomcat server. Please give me a step by step Instructions f

RE: Fuck It.

On Thu, 21 Dec 2000, Rob S. wrote: > Correct me if I'm wrong, but maybe the whole focus of 3.3 / 3.2.x thing, is > that neither of them will be all that they could be because the resources > are so limited and divided. > > Of what value would enhancing JServ to the point of technical perfectio

RE: Fuck It.

Correct me if I'm wrong, but maybe the whole focus of 3.3 / 3.2.x thing, is that neither of them will be all that they could be because the resources are so limited and divided. Of what value would enhancing JServ to the point of technical perfection, be right now when it is clearly not the direc

RE: Fuck It.

> tree. Who is actually FIXING the 3.2 bugs and trying to get a better > container on the old architecture? Not certainly Costin, Nacho or the Please be carefull when you write something about anybody, have a look at commits please... Henri, P. Delisle and I are the only ones here that had contri

RE: ajp13 evolution or ajp14

> >> Way back to technic ;-) > > > >Great too see that. > > > > May be the last time :-( I hope not - it's great working with you :-) > >- it's not a bad idea - as long as it's an option > > That's could be a secured ajp13 or ajp14 ?-) AFAIK ajp13 can be extended in a backward-compatible way

  1   2   >