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

I have few weeks, I'm trying to sync up some of the few changes I made in the last year before the code is moved to svn and try a bit more the 'embedded' scenario ( both single-jar tomcat - that actually works well, and also coyote-only ). I uploaded 2 jars at http://people.apache.org/~costin/m

Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/loader WebappClassLoader.java

Remy Maucherat wrote: Jan Luehe wrote: As a reminder, CVS shound't be used anymore. I commited a bunch of small changes, don't know how easy it'll be to get them in after the switch to svn. Let me know if there's a problem, I can roll them back. BTW - I had some of the changes in Introspec

Re: cvs commit: jakarta-tomcat-5 build.xml

BTW - there are still few files missing, but the end result is a 1.2M jar containing all deps, that can be run with "java -jar" and only requires a webapps/ dir in the current dir. Costin [EMAIL PROTECTED] wrote: costin 2005/09/28 23:07:24 Modified:.build.xml Log: Add

Re: New repository org

Could we just move all in tomcat5.5 ( and HEAD ) into one repository ( say, tomcat ) ? Like: tomcat/ tomcat/catalina tomcat/connectors tomcat/jasper tomcat/build ( or something else - jakarta-tomcat-5 is just the top level build and utils ) There is little benefit those days in having 4 separa

Re: New repository org

Mark Thomas wrote: Using externals wasn't something I had thought of but if offers a nice way to provide all the source for one version in a single chekcout. We now have tomcat/current/5.5.x that uses externals to link in all the various modules. That's actually what I was thinking about,

Vacation

Hi, Next week I'll be in vacation - not sure how much mail I'll be able to read. Most of the big changes needed for encoding are commited, there are many small things still to be done - but I don't expect anything major to be needed. Besides bug fixing and minor tunings I don't have anything e

Re: [VOTE] New Committer: Mike Anderson

+1 Costin --- GOMEZ Henri <[EMAIL PROTECTED]> wrote: > I would like to propose Mike Anderson as a new committer. > > He found many subtils bugs in mod_jk and since he's > working on Netware platforms, it will a great help > to improve connectors on this OS. > > Vote please > > - > Henri Gome

Re: moving jakarta-tomcat-4.0/connectors to jakarta-tomcat-connectors/webapp

1 is very bad, it would alter the history. I would go with 2, but I'm not sure it's an "import" but regular cvs add ( import is used to create new repositories AFAIK ). Costin --- kevin seguin <[EMAIL PROTECTED]> wrote: > i'd be tempted to go with 1), but i like to live on the edge ;-) the >

jasper34 - status

FYI, I'm not planning any major changes in the near future for jasper34. I'm reasonably happy with the first round of cleanup and refactoring, and I think we are moving in a good direction with the "toolkit"-isation of jasper and the various optimizations we discussed. I want to let the code st

Re: [J-T-C/TC3.3] Update

Hi Kevin, Henri, I will spend some time on the connector and can help a bit with that too. Merging should be reasonably easy, but I would like to keep a "backup", i.e. do the merge in a new file. Kevin - what about doing the merge as part of Ajp14 ? It should be able to handle ajp13 request

Re: TC3.3: Encoding

> Perhaps there are two i18n improvements in Servlet 2.3 and JSP 1.2: > > 1, javax.servlet.ServletRequest#setCharacterEncoding() > 2, pageEncoding attribute of Page directive > > Alternative workarounds in these two points makes non-ASCII users > happy. What I'm saying is that instead of imple

Re: Some benchmarks

--- Alex Fernández <[EMAIL PROTECTED]> wrote: > I think the benchmarks are very interesting. Unfortunately, the > results from HelloWorld don't seem too revealing. Depends what you want to measure - HelloWorld shows one number, the container overhead. For any servlet that does something more you

Re: Tomcat 3.3 contextAdmin issues

On 18 Aug 2001 19:56:33 +0200, Paulo Gaspar wrote: > I have been trying to improve a bit on the "admin" > application, especially on the "contextAdmin" bit, > tweaking its web pages/JSPs in order to add functionality > and ease of use. Great :-) > I am especially interested on making it easier

RE: Tomcat 3.3 contextAdmin issues

On 20 Aug 2001 02:01:12 +0200, Paulo Gaspar wrote: > Your explanation sure helps understanding what functionality is intended > for each tag. I can take a look at that too. It is easier for me to > understand the taglibs than the rest of Tomcat. > =;o) Well, I hope understanding the rest of tom

Re: [VOTE] Removal of mod_jk for Apache 2.0 from jakarta-tomcat for Tomcat 3.3

On Mon, 2001-09-10 at 16:40, Pier Fumagalli wrote: > >> A third one could be an API merger between the two... If you want to talk > >> about it... > > > > No, I meant between JK and WebApp... :) Well, webapp has a very nice protocol - it would be a great addition to jni, ajp12, ajp13 and ajp1

Re: [VOTE] Removal of mod_jk for Apache 2.0 from jakarta-tomcat for Tomcat 3.3

On Mon, 2001-09-10 at 16:48, Pier Fumagalli wrote: > > Why don't we keep a NON-APR (JK), and progress works on APR based on WebApp? > Joining AJPv14 and WARP? The important thing in mod_jk is the modularity, the fact that it supports multiple server adapters and multiple protocols. This part ha

Re: [PATCH]Cookies in 3.3dev

Hi, Thanks for the patch, I'll commit it as soon as I'm back. I'm in a (sort of) vacation, back on Nov 2. ( I think most of the big changes in 3.3 are over, next few months I'll only fix bugs and work on few new interceptors ) Costin --- Arion Yu <[EMAIL PROTECTED]> wrote: > Running the C

RE: [PATCH]Cookies in 3.3dev

--- GOMEZ Henri <[EMAIL PROTECTED]> wrote: > >( I think most of the big changes in 3.3 are over, > >next few months I'll only fix bugs and work on few > new > > What about 3.2 release ;-) I hope it will happen - it's not my call and I really hate the very long time it took so far - but it's a g

Re: EmbedTomcat.java question (3.2b6) -- Must use Java 2

EmbededTomcat was introduced initially to allow J2EE integration, it may be possible to make it 1.1 compatible but it's not part of the "core" functionality. We never claimed we'll support all the features on 1.1, only that you'll have a working container. Costin --- Nick Bauman <[EMAIL PROT

Re: BugRat Bug #42 was assigned to Costin Manolache

hanks > > -Nick > > On Thu, 26 Oct 2000, BugRat Mail System wrote: > > > Bug #42 was assigned to Person #2 > > > >Name: Costin Manolache > >Email:[EMAIL PROTECTED] > >HomePage: http://costin.dnt.ro/ > >Phone: &

RE: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/util M essageBytes.java MimeHeaders.java MimeMap.java SessionIdGenerator.java

--- Larry Isaacs <[EMAIL PROTECTED]> wrote: > Hi Costin, > > Good to see you back. > > FYI: My helper\SessionUtil.java is still looking for > SessionIdGenerator.generateId(). Did you mean to > commit SessionUtil.java > too? Yes, but there are few other changes and I need to "serialize" the c

Re: Tomcat3.3

My intention was to make sure we all agree about what goes into 3.3, and we all agree that those changes are not just "feature-ism", but things that will give us a better tomcat. Please review the list of changes - I'm willing to undo any of them if you have good arguments or a better solution (

Re: EmbededTomcat.java requires jsse

I don't like that - tomcat is supposed to depend only on JDK1.1 and a minimal number of extensions ( jaxp is the only required extension ). All non-jdk1.1, non-standard extensions can be used, but shouldn't be required to build standalone tomcat. I don't know if it's too late to change this - i

Re: My patches for Tomcat 3.2 wrt mutlibyte characters

One problem I have with the patches ( and I sent a reply to Pilho Kim the first time he posted the patches) is the impact on performances. The least we can do is to detect if the encoding is compatible with ASCII ( or UNICODE ) and use the getBytes() only if it isn't. The method has a big impac

Re: [MY_OPINION] Tomcat 3.x

Hi Jon, First, I want to thank you for the advices and your mail - even if I don't like what you say I do believe that your mail have some good things for me. > It really scares me that you are the only person (as > far as I can tell) that is seriously interested in ?> maintaining and developing

Re: Apache 2.0

Hi, I am able to compile Apache2.0, and I updated mod_jk for the modified functions in 2.0 - it now compiles. I'm pretty confident we can have it running in few days - it did worked before and it works fine with other multithreaded servers. As you can see, most of the code in mod_jk is indpenden

Re: [MY_OPINION] Tomcat 3.x

> I don't agree. TC3.3 is a rewrite of TC3.2, with all > of the TC4 "fancy features" (and some more). 3.3 is not a "rewrite" of 3.2 - some code was moved for better organization and modularity, and we finished a number of optimizations that were started during 3.2 development. Yes, a lot of cod

Re: [MY_OPINION] Tomcat 3.x

> I wish people would pay more attention to what the > overall issues are > instead of focusing on entirely the wrong things. +1 on this > The issue is the idea of a 3.3 and I'm not saying to > "jump" to 4.0. I don't see how did you created a "3.3" issue - tomcat3.x development continues as i

Re: Fuck It.

> 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 opinions. > _exactly_ happening: from

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

test - gmane

Sorry for the 'test', I'm trying gmane and hopefully here I'll get fewer flames for posting 'test' messages... Costin -- To unsubscribe, e-mail: For additional commands, e-mail:

[5] launcher/deamon

Patrick ( and all ), The 'launcher' is a very good idea - reducing the use of .bat/sh and having 'keepalive' functionality and a clean startup file are all great. My only requirement is to keep the code clean and minimise dependencies. My understanding of the launcher is that it uses ant file

[5] Components / optional / compat

Proposal: Let's split 5.0 code into several directories ( components - like in commons ). 'catalina' will remain the 'core' interfaces and required features ( i.e. the minimal stuff ). 'naming' for jndi stuff 'compat' for all the interfaces from 4.0 that we deprecate but preserve for backward

Re: [5] launcher/deamon

remove it > from the Tomcat 5 build and restore the old scripts. I'm not the 'community' - but I agree with 'choosing' :-) Make a proposal, have a vote - that's the only way to know what the community chooses. Costin > > Patrick > > Costin Manol

Re: [5] launcher/deamon

On Sat, 03 Aug 2002 18:07:08 -0700, Patrick Luby wrote: > Costin, > > [EMAIL PROTECTED] wrote: >> On Sat, 3 Aug 2002, Patrick Luby wrote: >> >> >> I also have reservations - I see no reason to require it, at least not >> until commons-launcher is stable and released. >> >> "java -jar tomcat.j

Re: cvs commit: jakarta-tomcat-5 build2.xml

On Sat, 03 Aug 2002 21:00:17 -0700, Patrick Luby wrote: > Costin, > > If it helps, you can exclude org/apache/catalina/launcher/** from the > build if you are not using commons-launcher. This package is only used > by the Launcher's XML files and has no other packages depend on this > package.

Re: [PROPOSAL] Have Bootstrap and BootsrapService share startup/shutdown code

Remy Maucherat wrote: > BootstrapService never used a port. You're right. I keep confusing the things - I now switched to CatalinaService and it works. BootstrapService depends on daemon - and I don't use daemon to start. ( I hope deamon will switch to introspection ) > Sorry I missed somet

[POLL] Configuration API of tomcat5

Few questions: 1. JMX as low-level configuration API. The question is - should we follow the path of JBoss and make everything that is configurable an MBean, and base the entire architecture on JMX ? The benefits: - standard API - reasonably clean - easy to integrate with other apps using JMX

Re: [POLL] Configuration API of tomcat5

On Fri, 09 Aug 2002 02:24:32 -0700, Remy Maucherat wrote: >> 1. JMX as low-level configuration API. The question is - should we >> follow the path of JBoss and make everything that is configurable an >> MBean, and base the entire architecture on JMX ? The benefits: - >> standard API >> - reasonab

Re: uri_map using regex [WAS: mod_jk, mod_jk2 URI spaces]

I thought about this few times - it's a good idea but a bit scary ( the build process ), and not sure if a general regexp will work as well on the simple patterns we have. On the other side most regexp impl. use finite machines and many optimizations - so they may be much faster. I'm +1 if you

Few additions to CatalinaService

I'm not sure if Remy was -1 or not ( well, technically you can't -1 until you see the code :-). I would like to _add_ few methods to CatalinaService ( with no change to existing ones ). Basically setters and an execute(), to allow: It can be done in a separate class, but we have already

RE: [GUMP] cactus-sample-servlet builds

Vincent Massol wrote: > Thanks Stefan. > > I though it was an httpclient issue but it tried it locally with the > latest HttpClient and it ran fine with Tomcat 3.3.1 and Tomcat 4.0.4. > > Thus, I now have the feeling it is a Tomcat 3.3 problem. I just tried > with yesterday nightly build of Tom

Re: [5] Config

Craig R. McClanahan wrote: > (Breathing a sigh of relief that I don't actually have to *implement* this > stuff, but hoping to contribute a little anyway :-) Well, the fact that I don't have to implement much is a relief for me too... Both the API and a lot of drivers ( including xml file ) are

Re: [5] [TODO] Config first task

Remy Maucherat wrote: >> The way I see it, we'll have 2 JNDI 'trees': >> - one for 'config data' ( the new one ). >> - one for 'runtime data' - including the VFS, various java:env, etc. > > Yes. > > I suppose you can take advantage of federation to make a giant big tree. And internals and 'p

Re: [5] [TODO] Config first task

Remy Maucherat wrote: >> And internals and 'priviledged' application will get access to the >> root of this tree, and look up anything configurable or runtime >> using the 'normal' API - with no tricks with classloader/thread binding. > > That's different from the ENC, since here, you can give t

Re: [5] [TODO] Config first task

Remy Maucherat wrote: > I don't understand why you think it's the same. > > For the ENC, you do something like: > (new InitialContext()).lookup("java:/comp/env/maxExemptions"); > > So you need the thread or CL binding to retrive the JNDI Context where > maxExemptions is. > > For the config, yo

Re: cvs commit: jakarta-tomcat-connectors/jk/native/common jk_ajp_common.c jk_connect.c

Glenn Nielsen wrote: > Costin, > > Why were the log levels changed from LOG_ERROR to LOG_INFO, a connection > failure to tomct is a real fatal error when handling a request. Shouldn't > it be at the JK_LOG_ERROR level? It'll be logged at ERROR level - >> +jk_log(l, JK_LOG_ERROR, "Err

Re: [5] [Proposal] Adding an authorization interface

IMO - I would rather see us using JAAS directly as API instead of defining our own. I already mentioned that I would preffer using JNDI for abstracting the informations about user/group. In general, the fewer interfaces we define, the better it is. Costin Jeanfrancois Arcand wrote: > Hi, > >

Re: [5] [Proposal] Adding an authorization interface

Jeanfrancois Arcand wrote: > > > Costin Manolache wrote: > >>IMO - I would rather see us using JAAS directly as API >>instead of defining our own. >> > Can you elaborate a little more? JAAS will certainly help for user/group > authentication/authorization,

Re: [5] [Proposal] Adding an authorization interface

Jeanfrancois Arcand wrote: >>Why would someone use this instead of web.xml ? >> > Because you can start using the java.security.Provider.checkPermission > for granting/denying resources. Not sure this would be the most efficient solution - the mapper is ( or will be ) optimized on the way it is

Re: [5] [Proposal] Adding an authorization interface

Remy Maucherat wrote: > I'll only be talking about HTTP authentication and the interaction with > the realms for now. > > The main problem is that some authentication schemes need the realm to > function (digest, for example). So I don't see how we can put that layer > of processing in Coyote, si

Re: [5] [Proposal] Adding an authorization interface

Jeanfrancois Arcand wrote: >>I would very much preffer a consistent mechanism for all the hooks in >>tomcat. In 3.3 there is one interface ( BaseInterceptor ) where all >>the possible hooks are defined ( with a number of problems we already >>know regarding ordering, but that's a different issue )

Re: [4.1.16] [VOTE] Stability rating

Remy Maucherat wrote: > Note: I know many people are away this weekend, so this vote will run > until Monday COB (on the west coast), which more or less means Tuesday > morning GMT. > > > [ ] Alpha > [ ] Beta > [ ] Stable (aka GA) > > > Remy Beta or Stable. Costin -- To unsubscribe, e-mai

Re: Jasper Classloader question

John Trollinger wrote: > I am trying to access the jasper class loader directly. I want to do > this so that I can get a jsp class file out of it at runtime vs having > to do a jsp:include to call the jsp. I am having a little trouble > getting through the jasper code and would like a little dir

Re: [5.0] Cluster features

Remy Maucherat wrote: > Hi, > > I think the clustering features in Tomcat 5 should get an overhaul. > Despite some licensing dicrepancies, I plan to use JavaGroups for the > task (LGPL license), as well as some code which was donated a while ago > by Filip Hanik. Based on what is already done, th

Re: [5.0] Cluster features

Remy Maucherat wrote: >> +1 if all new code goes in a separate module ( instead of catalina ), >> and is built as separate .jar(s). > > I wanted to, however I can't do that without changing the API some stuff > in the session package (the damn classes are all package private) :-P > > I suppose

Re: [5.0] Cluster features

Jeanfrancois Arcand wrote: +1 if all new code goes in a separate module ( instead of catalina ), and is built as separate .jar(s). >>>I wanted to, however I can't do that without changing the API some stuff >>>in the session package (the damn classes are all package private

Re: Strange Tomcat 4.1.x release versions

On Tue, 2002-12-03 at 11:29, Jon Scott Stevens wrote: > The last official final release was Tomcat 4.1.12 > > We now have a Tomcat 4.1.16 beta. > > What is up with this weird release numbering? What happened to Tomcat > 4.1.13? Maybe Remy got infected by Sun's marketing. I'm still curious how > S

Re: [5.0] Cluster features

Jeanfrancois Arcand wrote: >> I'll remove stuff in the Cluster API, modify some of the session >> classes to allow extending them in a different package, and everything >> in the core is then independent of the clustering. > > No security problems if we kept the current package protection > mech

[VOTE] Making JMX required in tomcat5

The subject should be clear. The benefit is that we'll be able to build more JMX awareness in the code without doing tricks - each component will know about its ObjectName and will be able to return ObjectName[]. I'm not proposing MBeans all over tomcat - modeler works very well in transforming

Re: Jasper 2 Synchronized JSP compiles

+1, good idea ! Costin Glenn Nielsen wrote: > I have some ideas on how invoking the javac compiler for compiling JSP > pages can be > improved. Currently Jasper 2 uses ant to do compiles from within Tomcat > which are synchronized. > > There are currently several problems. > > 1. The known ja

Re: [5] [Proposal] Adding an authorization interface

Glenn Nielsen wrote: > There are a number of different types of realm implementations in > org.apache.catalina.realm. These are all solely used for web application > realm based authentication except for those which implement the > UserDatabase which understands users, groups, and roles and has me

Re: [RFC] Make jakarta-tomcat-catalina codebase common for both Tomcat 4 and Tomcat 5

Glenn Nielsen wrote: > Remy Maucherat wrote: >> Glenn Nielsen wrote: >> >>> With Tomcat 4.1 released many tomcat developers have been reticent to >>> add new features >>> to its codebase for a number of reasons. All the development going on >>> in Tomcat 5 and >>> wanting to keep the number of c

Re: [RFC] Make jakarta-tomcat-catalina codebase common for both Tomcat 4 and Tomcat 5

Jeanfrancois Arcand wrote: > This is hard to do (Catalina has never been written to allow facades). > Also, for Tomcat 5, j-t-catalina is actually the Servlet 2.4 facade. > Euh...I also like the module idea, but I share Remy's view and I doubt > about having a single o.a.c workspace for a

Re: [VOTE] Tomcat modules

Remy Maucherat wrote: > Hi, > > I plan to reorganize the jakarta-tomcat-catalina repository as follows: > - catalina folder: Catalina core; this depends on the servlet API > - modules folders: Optional functionality and modules (one example is > clustering), but which depends on the Catalina API;

Re: [VOTE] Tomcat modules

Remy Maucherat wrote: > Costin Manolache wrote: >> Remy Maucherat wrote: >> >> >>>Hi, >>> >>>I plan to reorganize the jakarta-tomcat-catalina repository as follows: >>>- catalina folder: Catalina core; this depends on the servlet API >

build files ( again )

Since we are talking about clean and organized: Can I (re)move the antcall to jk, http11, jtc from j-t-catalina/catalina/build.xml ? j-t5 is the main build file and it should call all 'child' build.xml files directly. Is anyone else using the "build" target ? Any objections to creating all the

minimal

Jeanfrancois Arcand wrote: > Yep. There is a couple of Realm/Authenticator that can be optional (the > default one should stay in the core module) Speaking of defaults: - Should we make the JAAS realm the default ? Or at least include it in the core ? In my opinion the user.xml Realm should ev

Re: minimal

Another try: Required libs: - JMX - JAAS - JNDI - digester ( and beanutils, collections it needs ). - modeler - ant ( required by jasper runtime and startup ) - commons-logging When/if the JNDI-based abstraction of config files is ready we'll not need digester - but most likely it'll still be req

RE: minimal

Shapira, Yoav wrote: > Hi, > >>> - jasper ( at least jasper runtime - but probably the whole thing ). >> >>Now that we have JSR 154 and JSR 153, can't we make a distribution of >>Tomcat >>that does not include Jasper? That would rock. =) > > Big time +1 on that. I don't use Jasper/JSP pages at

Re: minimal

Jon Scott Stevens wrote: > What people are saying is that they would like A distribution of Tomcat > without Jasper. We are not saying all distributions of Tomcat should not > include Jasper, only A distribution. > > It has nothing to do with "I don't like it so nobody should use it." It > simply

RE: [VOTE] minimal JSR 154 only distribution

-0 I need JSPs so I'll work on the minimal JSR152 + JSR154 ( and the full distribution ). Jasper is part of tomcat and that's what most people expect. If 3 committers are willing to work on and support such thing ( and it does get more +1 than -1 ) - I see no problem. Yoav - I suppose your vote

Re: [VOTE] minimal JSR 154 only distribution

Bill Barker wrote: > It would cause nightmares if you knew how badly I've got my e-mails > cross-linked :). > > This is to +1 the original VOTE. While I'm personally a heavy JSP user, > having patched TC 3.3.x to allow it to run in servlet-only mode, I see the > need for offering a servlet-only

Re: [VOTE] minimal JSR 154 only distribution

Remy Maucherat wrote: > - As the release manager, I feel lazy, and would like to minimize the > possibilities of screwing up a distribution You don't have to do that - one of the people who voted +1 will have to volunteer as release manager for that release, and they are supposed to maintain it

Re: [VOTE] minimal JSR 154 only distribution

Jason Hunter wrote: >> It seems Jon is more interested in a release without jsp then in a >> release that includes velocity. Too bad. > > I think that's to Jon's credit. It shows the goal isn't to put Velocity > and JSP on even footing, but just to provide what users want, which is > often a mo

Re: [VOTE] minimal JSR 154 only distribution

Jon Scott Stevens wrote: > requirement in JSR 154 to provide the Admin Tool, I don't see how your > argument is valid for what I'm proposing. A majority vote doesn't require arguments or validity of arguments. "I like the idea" or "I don't like the idea" is all that's needed. Valid arguments a

Re: [VOTE] minimal JSR 154 only distribution

Remy Maucherat wrote: > If the vote actually passes, I'd like to have only one minimal Tomcat > distribution, which would mean no admin and no Jasper (with separate > optional Jasper binaries available). JMX can be used directly (using a > MX4J connector + MC4J, assuming MC4J updates to MX4J 1.1.

[VOTE] Minimal tomcat ( JSR154 + JSR152 )

Since things may get confusing around here, I would like to have an official vote on my prior proposal. This is the list of included features: Libs: - JMX - JAAS - JNDI - digester ( and beanutils, collections it needs ). - modeler - ant ( used for startup and automation of some tasks ) - common

Re: [VOTE] minimal JSR 154 only distribution

Jon Scott Stevens wrote: > One last point, we should be able to experiment around here. The negative > votes have been based on biases about what I think about Jasper and my > opinions. > They are not based on the idea that experimentation is a good > thing and I think that is just plain wrong

Re: [VOTE] Minimal tomcat ( JSR154 + JSR152 )

Remy Maucherat wrote: >> >> Votes: >> [ ] +1 I like the idea, I might help >> [ ] -1 I don't like the idea, I won't help. > > I'll have to vote -1 until the other vote completes, and then, I'll > either be: > - +1 if Jon's proposal doesn't pass > - -1 if Jon proposal is accepted, unless Jasper is

Re: [VOTE] minimal JSR 154 only distribution

Henri Gomez wrote: > What about using a minimal tomcat core with plugged modules to give > access to jsp/jmx ? There is already some support for that ( server/webapps is very similar with the 3.3 "modules" - i.e. trusted components ). It'll need few changes to deal with the loader issues ( i.

Re: [VOTE] minimal JSR 154 only distribution

Jon Scott Stevens wrote: > on 2002/12/9 7:51 AM, "Costin Manolache" <[EMAIL PROTECTED]> wrote: > >> No Jon - my vote wasn't based on your biasses about jasper, but on the >> biasses of many members of the tomcat community. > > So, you speak for the

Re: [VOTE] minimal JSR 154 only distribution

Jon Scott Stevens wrote: >> If Sun or anyone else wants to release a JSR154-only product - they >> can do it and we should make it easy to do so. >> I don't think we should do it ( as tomcat community ). > > Why? So far, you haven't even given a real reason. That may be because every reason you

Re: [VOTE] Minimal tomcat ( JSR154 + JSR152 )

Pier Fumagalli wrote: > On 9/12/02 15:16 "Costin Manolache" <[EMAIL PROTECTED]> wrote: > >> Since things may get confusing around here, I would like to >> have an official vote on my prior proposal. >> >> This is the list of included featu

Re: [VOTE] Minimal tomcat ( JSR154 + JSR152 )

Pier Fumagalli wrote: >>> I remember that when I proposed the same thing (roughly) and wanted to >>> call it "Tomcat-HA" or something like it, you said: >>> >>> "If possible, please also change the name - unless ASF gives you >>> permission to use tomcat name in your product." >> >> Can you poin

Re: [VOTE] minimal JSR 154 only distribution

Pier Fumagalli wrote: > They come up every now and then... That's why Costin wanted that > all-private for your eyes only noone who is not cross checked with the FBI > gets in security mailing list, right?... Wrong. The list is for all tomcat committers - and all security information will be post

Re: [VOTE] minimal JSR 154 only distribution

Henri Gomez wrote: > The idea being to provide a minimal tomcat binary and > many external modules which will be linked at runtime if > present, Apache 2.0 does it that way, why could we do the > same. Another solution can be seen in jboss. They do pack all the components ( or almost ), but also

Re: [VOTE] New committer: Filip Hanik

Remy Maucherat wrote: > I'd like to nominate Filip Hanik as a committer on > the Tomcat project. Filip has written the clustering code that was > committed recently in the Tomcat 5 CVS, and is willing to maintain it, > as well as continuing to improve it (including supporting large > clusters). F

Re: [VOTE] Minimal tomcat ( JSR154 + JSR152 )

Pier Fumagalli wrote: > On 9/12/02 23:58 "Costin Manolache" <[EMAIL PROTECTED]> wrote: > >> But in this case you keep making false statements, and not only here. It >> should be quite easy to look for a [VOTE] or [PROPOSAL] that you made >> and was voted

Re: [VOTE] minimal JSR 154 only distribution

Henri Gomez wrote: > Yes but add the ability to activate/include modules, which is > the Costin idea ;) Actually - I think it is your idea :-) ( well, now it makes a lot of sense - I'm in "how didn't I think of it" mode ). That means I will drop my minimal proposal, or at least rewrite it to b

Re: [VOTE] Minimal tomcat ( JSR154 + JSR152 )

Remy Maucherat wrote: > Martin Algesten wrote: >> This is the soundest idea I've heard so far. Multiple distributions >> sounds like disaster area to me. I currently think it is hard enough for >> a new user to decide Tomcat3/Tomcat4.x/Tomcat5 when presented with the >> choices. If there in additi

Re: [VOTE] minimal JSR 154 only distribution

Jon Scott Stevens wrote: > on 2002/12/10 7:30 AM, "Costin Manolache" <[EMAIL PROTECTED]> wrote: > >> Yes - Jon will not be happy ( as far as I know Jon ) if jasper.jar >> is anywhere in the distribution, even if it is not used. > > If Jasper is in ther

Re: FW: [VOTE] minimal JSR 154 only distribution

Jon Scott Stevens wrote: > I'm going to repost this message once again because it seems Remy and > Costin didn't bother reading it the first time and are now essentially > agreeing to what I suggested below. > > What-EVER! What-EVER to you. Reading your posts is not my favorite activity - for t

Re: [VOTE] minimal JSR 154 only distribution

I don't know why people have the impression that they need support or some special motivation when voting on a proposal. Yes - your admin tool argument doesn't make sense. You can easily precompile the admintool ( and we should do it anyway ) and run it in the JSR154-only container - if you wan

Re: [VOTE] minimal JSR 154 only distribution

Jeanfrancois Arcand wrote: > > > Jon Scott Stevens wrote: > >>on 2002/12/10 3:15 PM, "Costin Manolache" <[EMAIL PROTECTED]> wrote: >> >> >> >>>Yes - your admin tool argument doesn't make sense. You can easily >>>p

Re: [VOTE] minimal JSR 154 only distribution

Jeanfrancois Arcand wrote: > > > Costin Manolache wrote: > >>Jeanfrancois Arcand wrote: >> >> >> >>>Jon Scott Stevens wrote: >>> >>> >>> >>>>on 2002/12/10 3:15 PM, "Costin Manolache" <[EMA

Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler Compiler.java

Remy Maucherat wrote: > [EMAIL PROTECTED] wrote: >> costin 2002/12/10 16:38:29 >> >> Modified:jasper2/src/share/org/apache/jasper/compiler Compiler.java >> Log: >> Remove getCanonicalPath. > > This may not be a good idea, and I think would break Jasper on Windows. > I'll revert it

Re: [VOTE] minimal JSR 154 only distribution

Bill Barker wrote: > It seems to me that we've pretty much reached a consensus on this. I > agree with Glen's last post that what we should do is a "core" release > with nsi/rpm/ant scripts to download the additional components that are > required (and modify configs). The "ant" side could be si

Re: [VOTE] minimal JSR 154 only distribution

Bill Barker wrote: > Well, (without checking), I believe that this one started last Friday and > Jakarta Votes last one-week. Unless you propose an additional Vote (which > will last one more week :), to replace this one, my count (of binding > votes) > is: 3 +1, 2 +0, 2 -0, 1 -1. I've also coun

Re: [VOTE] minimal JSR 154 only distribution

[EMAIL PROTECTED] wrote: > On Wed, Dec 11, 2002 at 01:36:02PM -0800, Amy Roh wrote: >> Martin that too many distributions can be confusing for users. I vote >> for one >> distribution with options to disable whatever you don't want. Simple yet >> everyone gets only what they want. > > > I'm a

  1   2   3   4   5   6   7   8   >