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

[Costin Manolache]

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/mini - one has 
full jasper, the other only the jsp runtime. There are still few 
requirements  on the dir structure - you need to have the conf/web.xml, 
work/, webapps/, but besides that it's just 'java -jar 
tomcat+jasper.jar', no extra jars required.


tomcat-http11.jar is just coyote, with a javascript adapter as example ( 
 let me know if you want to play with it, I'll send additional info ).


Costin


Henri Gomez wrote:

Happy to see Costin is back :)

15 Sep 2005 06:04:01 -, [EMAIL PROTECTED] <[EMAIL PROTECTED]>:


costin  2005/09/14 23:04:01

 Modified:catalina/src/share/org/apache/catalina/startup
   Bootstrap.java
 Log:
 Support for corner case, when all tomcat is in a single jar and no fancy 
classloaders are used.

 Revision  ChangesPath
 1.23  +9 -5  
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/Bootstrap.java

 Index: Bootstrap.java
 ===
 RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/Bootstrap.java,v
 retrieving revision 1.22
 retrieving revision 1.23
 diff -u -r1.22 -r1.23
 --- Bootstrap.java3 May 2005 14:12:52 -   1.22
 +++ Bootstrap.java15 Sep 2005 06:04:01 -  1.23
 @@ -95,6 +95,10 @@
  private void initClassLoaders() {
  try {
  commonLoader = createClassLoader("common", null);
 +if( commonLoader == null ) {
 +// no config file, default to this loader - we might be in a 
'single' env.
 +commonLoader=this.getClass().getClassLoader();
 +}
  catalinaLoader = createClassLoader("server", commonLoader);
  sharedLoader = createClassLoader("shared", commonLoader);
  } catch (Throwable t) {
 @@ -122,10 +126,10 @@
  // Local repository
  boolean packed = false;
  if (repository.startsWith(CATALINA_HOME_TOKEN)) {
 -repository = getCatalinaHome()
 +repository = getCatalinaHome()
  + repository.substring(CATALINA_HOME_TOKEN.length());
  } else if (repository.startsWith(CATALINA_BASE_TOKEN)) {
 -repository = getCatalinaBase()
 +repository = getCatalinaBase()
  + repository.substring(CATALINA_BASE_TOKEN.length());
  }

 @@ -159,14 +163,14 @@
  // Retrieving MBean server
  MBeanServer mBeanServer = null;
  if (MBeanServerFactory.findMBeanServer(null).size() > 0) {
 -mBeanServer =
 +mBeanServer =
  (MBeanServer) MBeanServerFactory.findMBeanServer(null).get(0);
  } else {
  mBeanServer = MBeanServerFactory.createMBeanServer();
  }

  // Register the server classloader
 -ObjectName objectName =
 +ObjectName objectName =
  new ObjectName("Catalina:type=ServerClassLoader,name=" + name);
  mBeanServer.registerMBean(classLoader, objectName);





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Costin Manolache]

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 IntrospectionUtils in my workspace as 
well, so I don't have to commit that :-)


Costin


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Costin Manolache]

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 a target to build the standalone jar - in case anyone wants to play with 
it.
  
  Revision  ChangesPath

  1.239 +87 -1 jakarta-tomcat-5/build.xml
  
  Index: build.xml

  ===
  RCS file: /home/cvs/jakarta-tomcat-5/build.xml,v
  retrieving revision 1.238
  retrieving revision 1.239
  diff -u -r1.238 -r1.239
  --- build.xml 22 Sep 2005 10:39:37 -  1.238
  +++ build.xml 29 Sep 2005 06:07:24 -  1.239
  @@ -192,6 +192,7 @@
  
  
   
  +
 
   
   @@ -658,7 +659,7 @@

   
   
   
  -  	

  +
 
 
   
  @@ -1167,6 +1168,90 @@
   
 
   
  +  
  + + description="Do once before single jar tomcat">

  +
  +
  +
  +
  +
  +
  +   
  +
  +
  + +   description="Build single jar tomcat">
  +  
  +  

  +
  +
  +
  +
  +
  +
  +
  +
  +  
  +

  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +
  +  
  +
  +
  +
  +
  +
  +
  +  
  +  
  +
  + 

  + 
  + 
  + 
  +   
  +  

  +  
  + 
  + 
  +  
  +
  +
  +
  +  
  +

  +
 
 
@@ -2051,4 +2136,5 @@

 
   
  +

   



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: New repository org

[Costin Manolache]

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 separate repos.

Costin


Remy Maucherat wrote:

Bill Barker wrote:


It occurs to me that I may have misunderstood, and you were just talking
about setting up the svn:externals for tomcat/current.  If that's the 
case,

then +0 (I don't really care, but I'm glad that somebody does :).



svn:externals sounds like a cool feature, I guess I'll have to look it 
up to know what it does.


Mark Thomas wrote:
 > If by this you mean do a checkout of
 > http://svn.apache.org/repos/asf/tomcat/build/tc5.5.x to a directory
 > called build in the build scripts then +1. If it involves any form of
 > svn move -1 since I don't understand what you are planning to move to
 > where and I have concerns about complications that might be created for
 > checkouts, future branches and future tags.

No, I don't want to do any change to the repository. The problem is that 
svn isn't like CVS, so someone (like me, I tried it) which would 
checkout http://svn.apache.org/repos/asf/tomcat would be in trouble. It 
would be better to organize the developer environment. Right now, it 
organizes things using jakarta-tomcat-5, and all the other jakarta folders.


CVS was simpler ...

Rémy



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: New repository org

[Costin Manolache]

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, looks great.

Now, the big question - where can I add a sandbox/experimental directory?

Costin






Mark


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 separate repos.

Costin



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Vacation

[Costin Manolache]

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 else planned
for 3.3 - encoding was my biggest item, everything else I need can be
implemented in (external) modules. 


I've also done the import into jakarta-tomcat-jasper, and it's close to be 
usable for all new performance enhancements ( I hope to get it working
before leaving ). 


Regarding the connector - sorry I didn't had more time to spend on it, but
I'll be able to help more after I'll be back. I plan to do a
re-implementation of the java side of Ajp13/14, and also to do some
optimizations on the JNI side, and I'll try to help with the config stuff 
( if Henri doesn't finish it before I get a chance to help :-) If someone
could import the new buffer stuff - it would be great. 


Costin
( Please don't start too many flame-wars while I'm gone - my
mailbox has a size limit :-)

Re: [VOTE] New Committer: Mike Anderson

[Costin Manolache]

+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 Gomez ___[_]
> EMAIL : [EMAIL PROTECTED](. .) 
> PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
> PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 


__
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35 
a year!  http://personal.mail.yahoo.com/

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

[Costin Manolache]

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
> cvs repository is just a filesytem, after all...  i suppose 2) would
> be
> cleaner though.  i guess i could go either way.
> 
> -kevin.
> 
> jean-frederic clere wrote:
> > 
> > Hi all,
> > 
> > I would like to move jakarta-tomcat-4.0/connectors to
> > jakarta-tomcat-connectors/webapp.
> > It had been voted some weeks ago.
> > 
> > I also would like to add the configure things I have done in
> > jakarta-tomcat-connectors/jk to
> > webapp. Things like shell scripts, default rules, libtool files etc
> could be
> > shared in jakarta-tomcat-connectors/scripts.
> > 
> > How to do these things:
> > 
> > 1 - mv jakarta-tomcat-4.0/connectors
> jakarta-tomcat-connectors/webapp (in
> > daedalus.apache.org).
> > 2 - import a moved exported connectors from
> jakarta-tomcat-connectors/webapp.
> > 
> > 2 is probably the clean way...
> > 
> > Any other ideas?
> > 
> > Cheers
> > 
> > Jean-frederic


__
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35 
a year!  http://personal.mail.yahoo.com/

jasper34 - status

[Costin Manolache]

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 stabilize a bit and get more feedback before I
start the next step. I'll keep doing small changes and fixes, probably
finish the line number mapping and start restoring what was broken during
the first step ( jspc is one, jspservlet needs a bit more testing after
the class loader changes ), plus some improvements in the runtime.

I think the I/O changes, the Liaisons, the overal structure are 'under
control', it's just a matter of finding the time to implement them. The
big one is the internal API to be used for the tree and generators - it
has to be as simple as possible in order to be able to move fast in 
creating inline  versions for common tags and to allow various
optimizations in taglibs. 

I think we can start experimenting in the current version with generating
special code for some tags - and use this to learn more about it. 

( I expect some more major jasper34 changes after 3.3 beta ) 

Costin

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

[Costin Manolache]

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 requests as well, and it will have a lot of nice
features, including the important web-app autoconf. I think it would be
a much better way to spend the time - and if we work togheter we can
finish ajp14 much sooner ( than if we would work on both 13 and 14 ).

Costin

--- kevin seguin <[EMAIL PROTECTED]> wrote:
> i took a quit look, and it doesn't look like merging what's in
> o.a.a.tomcat33 with what's in o.a.a should be too difficult. 
> hopefully,
> soon i'll have some time to help out on this :)
> 
> GOMEZ Henri wrote:
> > 
> > Hi Kevin,
> > 
> > Did you take a look at my AjpXX stuff in TC 3.3 subdir.
> > Could you see how hard it will be to merge with yours ?
> > 
> > I think the only stuff which must stay under
> org.apache.ajp.tomcat33
> > must be interceptor. May be something which could became.
> > 
> > org.apache.ajp.interceptor
> > 
> > -
> > Henri Gomez ___[_]
> > EMAIL : [EMAIL PROTECTED](. .)
> > PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
> > PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
> > 
> > >-Original Message-
> > >From: kevin seguin [mailto:[EMAIL PROTECTED]]
> > >Sent: Friday, June 22, 2001 6:06 PM
> > >To: [EMAIL PROTECTED]
> > >Subject: Re: [J-T-C/TC3.3] Update
> > >
> > >
> > >>
> > >> What about moving isSameAdress to another package ?
> > >>
> > >> org.apache.tomcat.util.net ?
> > >>
> > >
> > >+1
> > >
> > >> And put there some usefull classes ?
> > >>
> > >> in J-T-C I moved it in PoolTCPConnector to make it
> > >> available at both Ajp13Interceptor and Ajp14Interceptor,
> > >> but under TC 3.3, Ajp12 need it directly.
> > >>
> > >> So we need to have it on a common place for both
> > >> JTC/UTIL, JTC/JK/TC33 and JTC/JK/TC4
> > >>
> > >> -
> > >> Henri Gomez ___[_]
> > >> EMAIL : [EMAIL PROTECTED](. .)
> > >> PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
> > >> PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
> > >


__
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/

Re: TC3.3: Encoding

[Costin Manolache]

> 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 implementing any workaround I'll
just 
try to make sure we implement the standard ( ;charset= ) and make it
possible to customize this ( by adding a module ). 

The problem is not in the servlet spec - 2.3 does allow you to specify
the encoding before getting the parameters, but that doesn't help if
you don't know the encoding. 

I spent a lot of time on this issue, and the real problem is that a
browser can send data in any charset - and nobody can know which
charset is used ( neither tomcat nor a servlet using 2.3
setCharacterEncoding),
so the servlet API version is not the very important ( except that in
2.3 you have an extra workaround you can play - assuming you know how
to find the encoding ).  

It seems there are a number of guesses and heuristics someone can use,
and in future UTF8 will work in most cases ( except that right now we 
are required to default to 8859-1, not UTF8 ). But I wouldn't include
any of them in the tomcat3.3 release - instead I'll make sure you can
control this with a module. 

Costin




__
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35 
a year!  http://personal.mail.yahoo.com/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Some benchmarks

[Costin Manolache]

--- 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'll get
the container overhead + the servlet overhead.

What would be interesting is a number of simple servlets doing simple 
tasks - like get a parameter, send a big chunk of data using
OutputStream, then Writer, then set headers, etc: and you substract the
first number and you can reveal more information. 

An arbitrary page can't tell too much, because it'll be hard to
separate the components. Of course, if you want to know how your
application will
perform you need to measure your application :-)


> Actually, it seems there are lots of jsps but no servlets. Perhaps
> the test
> pages would be more complete, but can they be run from within the
> browser?

Yes, I would be very interested in the results with a simple JSP.
In some of my tests they were slightly faster than a similar servlet 
( for 3.3 ).

Also, as a note - 3.3 is just M1 - there are still few things that will
affect the performance.

Costin


__
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35 
a year!  http://personal.mail.yahoo.com/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Tomcat 3.3 contextAdmin issues

[Costin Manolache]

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 to restart
> individual applications, deploy or redeploy new 
> applications and restart the whole container trough this
> web interface.



> The first two things that are really confusing are:
> - the existence of 2 lines of very similar classes 
>   (e.g.: TomcatAdmin and ContextAdmin) in the "tadm"
>   package at "webapps\admin\WEB-INF\classes\tadm";

Well, TomcatAdmin is the first tag I wrote, and it did a lot of things.
Too many, actually, so I started to split it. ContextAdmin will focus on
context tasks, TomcatAdmin for generic tomcat.

Also, TomcatAdmin declares the "ContextManager" scripting variable, and
that's a problem to be fixed - you can have only one  in a
page right now. 


> - and the fact that "restart.jsp" does not work as 
>   expected producing duplicate entries in the list 
>   presented by "contextList.jsp".

That's a bug. I'll take a look, I wrote restart.jsp mostly as a test -
to make sure all modules are cleaning up after themself ( i.e. you do
restart.jsp few times and check the thread count, memory use, etc - it
should stay constant ). If some contexts are not removed - that must be
fixed ( please add a bug so I'll remember ).


> Looking at "org.apache.tomcat.core.ContextManager" did 
> not help a lot since its comments are not very clear
> either, as is the case of its "shutdown()" method where
> comments make me doubt about how cleanup should be done.

Ok, what's not clear :-) ? As you know, I'm not very good at docs, but
if you ask specific questions I may be able to answer ( and fix the
comments allong the way ).  

> This restart thing probably has some relation with the
> work Costin is doing on "EmbededTomcat" - maybe the 
> information missing is the same.

It has some relation, in the sense EmbeddedTomcat must be able to
restart ( and it's using the same calls as restart.jsp ).

Costin
 

RE: Tomcat 3.3 contextAdmin issues

[Costin Manolache]

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 tomcat is not that difficult, but
the goal of the tags was to hide tomcat implementation details ( or
tomcat itself ). A "context" tag can have different implementations,
maybe specific to other servlet containers - the admin interface will be
the same, just a different taglib code will be used.

BTW, nothing requires you to use the tags or jsp - but whatever you use,
please keep the implementation behind an interface similar with the
tags. ( i.e. similar name and behaviors ).


> In this case I am talking about the comments in the method
> org.apache.tomcat.core.ContextManager.shutdown()
> 
> In this method's source code there are 2 blocks of cleanup code that 
> were commented out. The fact that they were not just removed and the 
> nature of a comment:
>   "remove the modules ( XXX do we need that ? )"
> before one of those blocks makes me wonder how sure it is that they
> are correct.

The code that is commented out used to be part of the method, including
the one with XXX comment ( and the answer is - we don't need to remove
the modules ).

The idea is quite simple - shutdown() is symetrical with init(). If you
add any context manually ( for example EmbededTomcat.addContext() ), you
should also remove it when you stop ( if you want to ). If a module is
adding contexts - it should also remove them ( or leave them in and
don't add them back ).

That's probably where the bug is, I need to review ContextXmlReader and
AutoWebApp to make sure they remove the contexts on shutdown.

shutdown() followed by init() should bring you back to the same state as
you were before ( if no configuration change happened ). 

Now, that's the theory - or what seems to be the 'correct' behavior for
the core. 3.3 is mostly about making sure the core behaves in a well
defined way - better modules will follow, and we can fix modules easily
without all the headache of a major release. 

If you have any doubts about the ContextManager behavior - please speak
now, we may still be able to fix it. 

Regarding the module removal - again, whoever adds modules should also
remove them back, shutdown shouldn't mess with that ( since init doesn't
either ).

In future, some modules will be enhanced to deal 'nicely' with restarts,
and I plan to add support module reloading ( via a module, of course
:-). As I mentioned so many times, after 3.3 we shouldn't have to change
anything in the core, so new modules can rely on some known and well
defined behavior ( well defined doesn't mean perfect, but good enough
:-). 


> Specific questions, besides the above "ContextManager.shutdown()" 
> issue:
>  - Why is it possible to add 2 or more contexts with the same name
>and base path? It is a cleanup issue that this happens with the 
>"restart.jsp" code, but shouldn't this kind of duplication also 
>be prevented?

Contexts should be identified by hostname and base path. If we don't
check for that - it's a bug. BTW, the right way to fix the bug is to add
the check - not in the core, but in a module ( that can do other checks
during the addContext/contextInit phases ). Again, this can wait until
after 3.3, I don't think it's a major issue. 

>  - To make a hot restart, it looks like modules should be restarted
>too. Is this correct?

Modules should deal themself with the init/shutdown events, and restart.
Most existing modules do not need to be reloaded - but that can be done
too. I'm still investigating how to implement module restart, and "hot"
module add/remove. I don't think this can be done in 3.3, but in a set
of modules that can be released after 3.3 ( I have some code, but now I
want to focus on 3.3 and few other important pieces ).


>  - When using "restart.jsp", previously removed contexts (using the
>admin pages) were not added back. Why?

Bug probably :-) Again, the right behavior is that whoever adds
something should take it back. 

>  - Where are existing contexts detected and loaded? Is it on a 
>module? And if yes, then which?

Contexts ( and modules ) are added in 2 ways:
- in applications embedding tomcat, by the application via calls to EmbededTomcat 
or ContextManager. 

- in standalone tomcat, by various configuration modules. Right now the list is:
ContextXmlReader
AutoWebApp.

The first will add modules declared in apps-XXX.xml and server.xml ( which 
shouldn't be used for contexts, that's only for backward compat ).

The second deals with webapps-like dirs ( you can define additional
dirs, very usefull for multiple virtual hosts ).

Thats' where you should check what happens on shutdown.

BTW, this review will help a lot - thank you very much. I think it's very
important to make sure the behavior is right in th

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

[Costin Manolache]

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 ajp14. And I think it has a lot in common with 
ajp14 - so it can share lots of code. 

I don't think it's that important how the bytes are packed in the
message, so a real merge between warp and ajp14 might work.

Regarding the general API in jk - we do plan a major refactoring anyway,
after we get something stable tagged ( not only for APR, there are few
other things we can improve in the general layout ). And all good things
from webapp will be wellcomed ( you like it or not :-)

Costin

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

[Costin Manolache]

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 has
nothing ( or little ) to do with APR or ajp14 or warp - and it is the
part I absolutely want preserved ( and improved ).

I'm quite familiar with webapp ( it's allways important to know the
competition :-), wa_request is the only serious obstacle (IMHO ).

If you can merge the request representation ( and callbacks ) to use the
same names, the rest will fit perfectly.

Even in the current status, with part of jk using it's own portability
routines and webapp using apr, there is no other problem in putting them
togheter, except for implemeting the glue code needed to add any new
protocol in jk.

Regarding the module itself- things are reasonably similar.

Costin

Re: [PATCH]Cookies in 3.3dev

[Costin Manolache]

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 Cookie Example would give the following
> error:



__
Do You Yahoo!?
Yahoo! Messenger - Talk while you surf!  It's FREE.
http://im.yahoo.com/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [PATCH]Cookies in 3.3dev

[Costin Manolache]

--- 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
group decision and any member of the group can delay
any release until he's happy with the code.

All I can do is work on 3.3.

> 
> PS: What about mod_war for Apache. Could you give us
> informations about it

I don't know too much - Pier is working on it. I'll
try to make it work with Tomcat 3.3 as soon as it's
ready ( i.e. write the interceptor ). 

I am working on few enhancements to mod_jk, but so far
it's more important to freeze 3.x core before working
on interceptors and connectors.

Costin


__
Do You Yahoo!?
Yahoo! Messenger - Talk while you surf!  It's FREE.
http://im.yahoo.com/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Costin Manolache]

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 PROTECTED]> wrote:
> Okay, this will NOT work with JDK 1.1. Deceptively,
> it will build with
> 1.1, but it just traipses around Java files that
> have Java2
> specific calls. H.
> 
> So I get a Tomcat 3.2b6 that might run, but won't
> embed. (FI, the
> EmbedTomcat.java doesn't get built)
> 
> -Nick
> 
> On Thu, 26 Oct 2000, Nick Bauman wrote:
> 
> > 
> > First:
> > 
> > In the javadoc for the EmbedTomcat class, it says
> you need to set up the
> > RequestInterceptors you want before firing up
> Tomcat. Well, if you read
> > the code a little closer, it looks like a call to
> addContext(String
> > contextPath, URL docroot) will automatically
> initialize the ContextManager
> > and set up the default RequestInterceptors. Is
> this true? 
> > 
> > If so, then you only need to add your Interceptors
> explicitly if you have
> > a custom Interceptor, no?  
> > 
> > Second:
> > 
> > What is the contextPath String mean?
> > 
> > Thanks
> >  -- 
> > Nicolaus Bauman
> > Software Engineer
> > 
> > 
> > 
> >
>
-
> > To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> > For additional commands, e-mail:
> [EMAIL PROTECTED]
> > 
> 
> -- 
> Nicolaus Bauman
> Software Engineer
> Simplexity Systems
> I'll give you $5 if you follow this link:
>
https://secure.paypal.x.com/refer/pal=nixnixnix%40yahoo.com
> 
> 
> 
>
-
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
> 


__
Do You Yahoo!?
Yahoo! Messenger - Talk while you surf!  It's FREE.
http://im.yahoo.com/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: BugRat Bug #42 was assigned to Costin Manolache

[Costin Manolache]

I'm on the airport, using an internet cafe. 

I'll be back to normal conectivity next week.

Costin

--- Nick Bauman <[EMAIL PROTECTED]> wrote:
> Costin, I believe this was fixed, but I don't want
> to assume. Can you
> close this when you get a chance?
> 
> Thanks
> 
> -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:
> >FAX:  
> > 
> > The bug was previously assigned to person #1
> > 
> >Name: Z_Tomcat Alias
> >Email:[EMAIL PROTECTED]
> >HomePage: http://jakarta.apache.org
> >Phone:-NA-
> >FAX:  -NA-
> > 
> >
>
-
> > To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> > For additional commands, e-mail:
> [EMAIL PROTECTED]
> > 
> 
> -- 
> Nicolaus Bauman
> Software Engineer
> Simplexity Systems
> I'll give you $5 if you follow this link:
>
https://secure.paypal.x.com/refer/pal=nixnixnix%40yahoo.com
> 
> 
> 
>
-
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
> 


__
Do You Yahoo!?
Yahoo! Messenger - Talk while you surf!  It's FREE.
http://im.yahoo.com/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Costin Manolache]

--- 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 commits.

( I changed requestURI, method, protocol to use
MessageBytes, and all the code that called the 
String message changed. After that change it should
be possible to add an EncodingIntereptor )

Costin

> 
> Cheers,
> Larry
> 
> -Original Message-
> From: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> Sent: 11/1/00 4:43 PM
> Subject: cvs commit:
> jakarta-tomcat/src/share/org/apache/tomcat/util
> MessageBytes.java MimeHeaders.java MimeMap.java
> SessionIdGenerator.java
> 
> costin  00/11/01 13:43:29
> 
>   Modified:src/share/org/apache/tomcat/util
> MessageBytes.java
> MimeHeaders.java
> MimeMap.java
> SessionIdGenerator.java
>   Log:
>   - added indexOf( c, starting ) to MessageBytes
>   
>   - in SessionIdGenerator, allow the caller to pass
> a Random source.
>   That will allow to configure the
> SessionInterceptor to use a certain
>   random instead of making config decisions at
> tomcat.util level.
>   
> 
> 
>
-
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
> 


__
Do You Yahoo!?
>From homework help to love advice, Yahoo! Experts has your answer.
http://experts.yahoo.com/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Tomcat3.3

[Costin Manolache]

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 ( or re-do everything that you like ).

Starting next week I'll start fixing bugs ( it seems
3.3 passes almost all the watchdog tests - except 1
servlet test and all taglib jsp tests - I think this
is a simple fix ). I want to also propose few name
changes  ( the SessionIntercepotr-s - one to be
SessionIdInterceptor and the other
SessionStorageInterceptor), etc.

Either way I'm going to need help - for merging the
bugs from 3.2, and more importantly a review of how
the "core" will end up like - the ContextManager and
Context state and the order of calls, etc. I would
like to see the core frozen after 3.3.

Costin



__
Do You Yahoo!?
Yahoo! Calendar - Get organized for the holidays!
http://calendar.yahoo.com/

Re: EmbededTomcat.java requires jsse

[Costin Manolache]

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 - it
seems 
we just need to replace 

   sc.setSocketFactory(new
org.apache.tomcat.net.SSLSocketFactory());

with 
sc.setAttribute( "socketFactory",   
"org.apache.tomcat.net.SSLSocketFactory");

and remove the import line.

I know it's not the the easiest solution, but I think
it's worth the added complexity - it is still a
requirement to support JDK1.1 and work with a minimal
set of library ( and JSSE is a very special one
anyway, export, etc).

Costin

--- Mike Anderson <[EMAIL PROTECTED]> wrote:
> I updated my source from CVS yesterday and all of
> the sudden I couldn't build.  I got an error saying
> javax.net.ServeSocketFactory not found in import
> when trying to build
>
src\share\org\apache\tomcat\net\SSLSocketFactory.java.
>  I looked at the build.xml and it looked like it
> shouldn't even be trying to build
> SSLSocketFactory.java since I didn't have the jsse
> classes in my classpath.  However, looking in the
> EmbededTomcat.java that was checked in on 11/17, it
> now does an import of org.apache.tomcat.net.* and
> directly references
> org.apache.tomcat.net.SSLSocketFactory.  Is there a
> way to fix this or are we now going to need to add
> the jsse jars to the build classpath?  If I do need
> to add the jsse jars, we should probably update the
> README to mention this so that others don't pull
> their hair out like I did for a while today.
> 
> Thanks,
> 
> Mike Anderson
> Senior Software Engineer
> Platform Services Group
> [EMAIL PROTECTED]
> Novell, Inc., the leading provider of Net services
> software
> www.novell.com
> 


__
Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products.
http://shopping.yahoo.com/

Re: My patches for Tomcat 3.2 wrt mutlibyte characters

[Costin Manolache]

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
impact on all VMs - try it if you don't believe me.

In tomcat3.3 OutputBuffer tries to resolve exactly
that problem ( char->byte ), and seems to work well,
but we need more work to convert header values, etc.
( i.e. for 3.3 the patch shouldn't be needed, the
problem is supposed to be solved by OutputBuffer ).

This is a very delicate subject from the point of view
of performance, and I spent a lot of time tunning
tomcat -> I would like to review any patch on encoding
before it is commited.

Costin


--- Kazuhiro Kazama <[EMAIL PROTECTED]> wrote:
> From: Pilho Kim <[EMAIL PROTECTED]>
> Subject: Re: My patches for Tomcat 3.2 wrt mutlibyte
> characters
> Date: Thu, 7 Dec 2000 11:30:42 +0900 (KST)
> Message-ID:
>
<[EMAIL PROTECTED]>
> > This is your big fault.
> > You should know the real meaning of default in
> API.
> > What is the default encoding in JVM?
> 
> The default character encoding in JVM is set by the
> "file.encoding"
> property.
> 
> You may aim to serve Korean contents on a Korean
> locale or language
> environment. In shoft, only one language!
> 
> But it is general to serve muliple language (ex.
> english, japanese,
> chinese etc.) contents in one tomcat. A
> well-internationalized servlet
> container will be able to serve them in the same
> situation -
> specifying its charset (and language)!
> 
> In conclusion, the following patches seems good!
> 
>
src/share/org/apache/tomcat/core/BufferedServletOutputStream.java
> 
> 
> But the following patches aren't appropriate or
> needs discussion.
> 
> 1)
> src/share/org/apache/tomcat/adapter/HttpAdapter.java
>
src/share/org/apache/tomcat/service/http/HttpRequestAdapter.java
> 
> (I don't mention cache-control patch for same files)
> 
> These patches convert to native encoding by
> getBytes() (=
> getBytes(CharToByteConverter.getDefault())). But
> quoted-string is used
> for header values in HTTP specification (but I don't
> know this spec is
> reasonable).
> 
> 2)
> src/share/org/apache/tomcat/core/Constants.java 
>
src/share/org/apache/tomcat/context/DefaultCMSetter.java
> 
> DefaultCMSetter must resolve an encoding problem
> internally.
> 
> 3)
> org/apache/jasper/compiler/Compiler.java
> 
> JSP's default charset is ISO-8859-1. Another patch
> will be wellcomed
> (see the following comments).
> 
>   // This seems to be a reasonable point to scan the
> JSP file
>   // for a 'contentType' directive. If it found then
> the set
>   // the value of 'jspEncoding to reflect the value
> specified.
>   // Note: if (true) is convenience programming. It
> can be
>   // taken out once we have a more efficient method.
> 
> And my colleagure (Mr. KAREZAKI) are checking the
> rest of your patches. He
> will post his comment to tomcat-dev.
> 
> Kazuhiro Kazama ([EMAIL PROTECTED])   NTT Network
> Innovation Laboratories


__
Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products.
http://shopping.yahoo.com/

Re: [MY_OPINION] Tomcat 3.x

[Costin Manolache]

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 Tomcat 3.x into the
> future. 

Well, at least it's good that there's at least one
person maintaining and developing it - it's a pretty
good product, it'll be scarry if everyone would
abandon it to do other things.

I have no plans on "developing tomcat3.x into the
future" - all I want is finish what I started and I
couldn't do in 3.2 timeframe - in terms of
performance, refactoring, modularity, security.

I don't see any need to go beyond 3.3 - and I said
many times I'll stop doing any major changes in the
core after 3.3 is done. I'll just fix bugs and develop
modules - most of them in my private, non-apache space
( I'm talking about the servlet 2.3 implementation ).

If you look at the code ( and any developer should do
that before arguing one thing or another ), 3.3 is
much cleaner and faster than 3.2 and it's finishing up
what was started. 

I would like to thank you for making me "the only
person" maintaining tomcat3.x, but I can't take the
credit for that - all I'm doing is improving great
code developed by other smart people, and even more
importantly finishing up what they've started.

As for the future - in many open source projects good
code does have a future - I hope the same will happen
with tomcat.

> It is not good to have the entire rest of the core 
> developers work  on Tomcat 4.x and having you sit 
> here and say that you are going to work
> towards back porting everything that the Tomcat 4.x
> people come up with on your own. 

Well, I don't see anything wrong in reusing good ideas
from tomcat4.x in 3.x - it's in fact the first time I
hear anyone saying it's bad. 

It was one of the goals of tomcat3.x to be modular and
allow people to add extensions without affecting the
core - and almost all of 4.x can be back ported as
tomcat3.x modules. 

If someone is doing that - people who use tomcat 3
will benefit, and that's good. 

> Talk about a complete duplication of
> effort by only a single individual.

That's a great compliment for the design of tomcat3
( unfortunately I can't take too much credit for this
either ) - if only a single individual can do that it
proves ( again ) that tomcat 3 is a great servlet
container and gives me reason to keep working.

> I can't even understand someone wanting to base
> their work on Tomcat 3.x
> when all of the core developer support (ie: more
> than just one person) is going towards Tomcat 4.x.

Better design :-) ? Continuity ? 

> I *personally* think that you should either drop
> your Tomcat 3.x development and work towards making
> Tomcat 4.0 have all the features and benefits that
> you want to see in Tomcat 3.x (and thus show that we

I think tomcat 3.x has most of the features that I
wanted - I would be happy to see 4.0 using the same
patterns and design that allow high performance, but I
don't have the time or wish to do it again. 
 
> are all working together instead of this constant >
> fork within the overall Tomcat project) or

It's funny you're telling this as if I'm doing
something wrong or forking - I strongly agree that
forking is bad, and so far I did all I could to avoid
forks ( i.e. I stoped developing the Servlet2.3 module
as part of tomcat3.3, etc).

> simply fork what you are doing into another project
> that is hosted somewhere else.

It's the second time an Apache member is asking me to
go somewhere else. Believe me, right now it's my
biggest wish - I've had more than enough !


> In fact, I'm pretty strongly -1 on Tomcat 3.3. If
> anything it would need to
> be suggested as Tomcat 5.0 because as far as I can
> tell, we have already
> come to the conclusion that Catalina will be Tomcat
> 4.0.

When 3.3 will be ready you are free to vote whatever
you want - I just hope your vote will be based on the
quality of the code and not political interests.


> What I'm most concerned with here is the overall  
> Tomcat project goals and
> seeing you duplicating work and effort is really not
> making me happy. 

Reuse != duplication



> You should be into
> lobbying people to work with you...not as a "damn
> you all, I'm going to do
> what I want regardless of what you say" type of
> attitude. 

I know some people prefer the "do what we tell you to
do or go away " or "we know what is better " attitude.
  

I don't want to defend myself , and I'll take it as a
compliment - I think it's great to be able to think
for yourself and be able to work when there's an awful
lot of pressure to go away.

As for lobbying - thanks for the advice, I think I did
quite a bit of lobby in the last year and I a tiny bit
of contribution in getting people get involved in
tomcat.



> This is because
> you will never get any other core developer support
> behind yo

Re: Apache 2.0

[Costin Manolache]

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 indpendent of server
architecture.

The only obstacles are the ammount of work I have for
this week ( on my job ) and the fact that I may need
to upgrade my OS to run Apache2.0. Right now it
compiles but crashes on startup, and I traced it to
the mm module and scoreboard ( that's before adding
mod_jk). I tried various options on mm ( including
FILE ) but it still crashes - so I'll have to try with
a different glibc, as that is the problem I presume.
( I have a RedHat 6.2 with a lot of updates, like
glibc
2.1.95 ).

Please let me know what's the schedule you have in
mind for upgrading.

Costin






__
Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products.
http://shopping.yahoo.com/

Re: [MY_OPINION] Tomcat 3.x

[Costin Manolache]

> 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 code was rewriten ( cookies is a good
example ) - but that's just a normal evolution of 3.2
- 
and the same happened after 3.1.  

Regarding the "fancy features" - 3.3 allows people to
add any feature as a module, but the "core" is much
simpler and feature-free than 3.2 ( or 4.0 ). In fact
one of the goals of 3.3 refactoring was to make sure
that all the "features" are modules ( examples: error
handling, class loader hierarchy, jsp integration,
servlet facade, etc )


> AFAIK, there is no plan to get rid of / stop
> maitaining TC 3.2, and actually
> it's Craig who handles the 3.2 releases and
> maintenance releases (like
> 3.2.1), not Costin.

Well, I must agree that this is a nice "political"
spin. It seems suddenly the evolution of 3.2 to 3.3 (
identical with the evolution of 3.1 to 3.2 BTW) turns
to be a "rewrite" or "fork" or "revolution". And 3.2.1
becomes the "evolution path" of 3.2. It also seems
that  improvements on 3.3 are "bad" because they take
away resources from 4.0, and features that are ok to
4.0 are "featurism" if implemented as tomcat3.3
modules.

I'm very happy to see Craig doing maintenance releases
of 3.2 until 3.3 is ready ( and I hope that will
happen in few months ). Please don't tell me that
Craig is going to do major performance improvments in
3.2.2, or rewrite the cookie handling ( to corectly
implement the specs), etc - so far it seems that he's
( rightly ) integrating bug fixes - that's what should
happen on any maintainance release. ( and of course,
he keeps forgeting the rules about release branches -
that a patch in the release branch should be merged
into the development branch ) 

It's a huge difference between maintaining a release
and continuing ( and finishing ) development. Tomcat
3.2 is much better than 3.1 because of active
development, and 3.3 will be better than 3.2.x because
of the same reason - things that can't be done in
3.2.x ( and it doesn't seem to happen anyway )

As I said earlier, the reason we need 3.3 is that 3.2
has unfinished areas - the core refactoring started
after 3.1 is the most important, performance is
another ( and that's easy to check by comparing 3.3
with 3.2 as performance or by reading the core package
). 

Because of the available resources we choosed not to
do maintainance releases of 3.1 unless a major
bug/security issue is found, but try to have a major
release (3.2) in a reasonable time. I think the same
should happen with 3.3, and I'm working as hard as
possible ( given the little free time I have ) to
finish 3.3 development in a short time ( again - few
months ).

BTW, if I remember corectly the rules  for tomcat
developlment, after a feature freeze leading to a
release, "development continues into the main branch,
with only bug fixes going into the release branch".
That's what I'm doing - continuing the development of
tomcat3 into the main branch. The bug fixes that go
into the release branch are great, but please stop
spining that into something else.

Costin

__
Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products.
http://shopping.yahoo.com/

Re: [MY_OPINION] Tomcat 3.x

[Costin Manolache]

> 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 it did before, and
I don't remember 3.2 beeing an "issue" or anyone
saying that 3.2 shouldn't have been developed. ( well,
I remember something about that - but it seems that
those who believed that were very wrong )

In fact, 3.3 doesn't even exist - when the development
on the main branch of tomcat 3 will reach a stable
state we can discuss about 3.3 , and you can argue
that it's better or worse than 3.2 and we should ( or
should not ) release it. Until that happens, TC3.3
refers to the version that is developmed out of tomcat
3 main branch - and you are welcomed to comment on any
development that takes place and send your feedback
about any commit. Those are the only real issues so
far - if you are interested in 3.x future. 

> Please look at all the information available to you
> about what is happening
> before commenting again.

+1 again, jon

Costin

__
Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products.
http://shopping.yahoo.com/

Re: Fuck It.

[Costin Manolache]

> 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 what I see in the commit 
> messages, it seems to me
> that even if on an evolutionary track, the container
> structure is completely
> different between 3.2 and 3.3. The architecture is
> almost as different as
> 3.2 and 4.0. 

It's sad that on this list so many people are experts 
in spinning facts and politics.

This is a _false_ statement, or a gross
misunderstanding of what "architecture" means and what
"refactoring" means.

The _architecture_, _ideas_ and _patterns_ in tomcat3
are the same - the code, code organization changed.

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 ?

And looking back to Apache1.3 - most of the concepts
are still there - you have more flexibility with the
hooks and mpms, but I hope you're not claiming that 
moving from 1.3 to 2.0 will be as hard as moving from
Apache to IIS.

And one more - Tomcat3.2 is also a refactoring of
Tomcat3.1. Refactoring == improving code readability, 
better organization - same design.
If tomcat3.2 is indeed "better" and user are well
served by moving from 3.1 to 3.2 - the same will be
true for 3.3


> others, they are all so busy in rearchitecting the
> container, and
> back-porting features from 4.0 that they don't have
> time to maintain the old

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
instead of reinventing the wheel. If someone writes a
JAAS authenticator for 4.0 - why not making it
available to 3.3 users too ?

After all, if 4.0 is "better", that's because of the
architecture, not because of the features - or else
next spin will be that people should use 4.0 because
of all the features. 

In any case, I made clear that all those "features"
will not be checked into 3.3 - but on an external 
tomcat-contrib-like repository. 

> This is not what's happening. You're not
> fixing them, you're
> re-architecting a new container on the ashes of 3.2,
> but you are not doing
> what you promised ME, you're not supporting your
> baby...

Take a look at "changes" in tomcat 3.3. It's a
description of all the "evolutions" from 3.2 to 3.3.
Too bad I haven't done the same when I worked on 3.2. 

You can also take a look at commit messages - yes,
some are big ( code moved around for better
organization ), 
and some deprecated interfaces are removed ( is this
an "architecutre change" ? They were introduced in
3.2, 3.1 or 3.0 to help refactoring, and "evolved"
into something better ).
 
Costin

__
Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products.
http://shopping.yahoo.com/

RE: ajp13 evolution or ajp14

[Costin Manolache]

> >> 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 ( or at least it should be ) by adding new packet
ids.

I wouldn't mind an ajp14, mod_jk is based on the idea
that there is no "perfect" protocol, but I would try
first to extend 13 ( I'm not even sure if this is
possible - if not then we need a 14). 
 
 
> I used such solutions with ssh tunnels (like CVS at
> apache.org) but I
> really like to have a built-in solution. I know also
> a little SSL since
> I produced sometimes ago the SSL Proxy jonama
> (http://www.multimania.com/jonama/),
> but SSL is just too slow at conect time and SSH is
> also a little too hard. 

I'll take a look.

> I was thinking a more simple algorithm, ie: DES with
> known keys.

AFAIK both SSL and SSH are using DES after the initial
connection is set up ( or IDEA, or other symatrical
alghoritm  - some faster than DES ).

Also ( based on 3-4 old memories ) you could extend
both protocols with other encryption alghoritms.

> >- BTW, SSH or SSL tunnels are very easy to set and
> available to most
> >people. 
> 
> Yes but it is an out of the box solution. I really
> like having a integrated
> solution.

Having it "bundled" with tomcat is very hard -
encryption is allways a problem. 

> 
> Easy under Redhat boxes, with some OpenSSL and
> OpenSSH RPM. 
> May be later I could send some doc about ? 

Check it in - as long as we are still commiters :-)

Costin


__
Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products.
http://shopping.yahoo.com/

test - gmane

[Costin Manolache]

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

[Costin Manolache]

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 to describe
the paths, conditions, etc. I looked at the code in sandbox - and
there are few issues ( many tasks that duplicate existing functionality
in ant, etc ), and some should be contributed back to ant ( like the
enhancements to Execute ). I support the idea - as long as tomcat 
code is kept clean and this is optional.

Right now we have a mess of launchers / entry points. 

Costin



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

[5] Components / optional / compat

[Costin Manolache]

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 compat ( Logger ? etc ).

'modules' for optional things. Launchers, specific realms, etc could
go here.

On a separate issue, there are few things that may be very usefull
independent of tomcat, and even if we don't move them to commons we 
should try to make them independently useable:

- naming
- users
- class loading - catalina has one of the most advanced loaders


Costin



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [5] launcher/deamon

[Costin Manolache]

Patrick, the idea is great - the implementations details are a bit
problematic :-)

On Sat, 03 Aug 2002 09:04:18 -0700, Patrick Luby wrote:

> Costin,
> 
> I plan to post a patch to Ant for the enhanced data types (e.g.
> syspropertyset) and the conditional  task elements (e.g.
> sysproperty with "if" and "unless" attributes) back to Ant as I think
> they would really enhance the Ant  task. I just haven't had time
> yet but I will do so eventually.

I saw a proposal for 'conditional' on all tasks ( for ant1.6). In any case
the current ant ( even 1.5 ) seems to have all the elements it needs to start
tomcat ( cactus and anteater are doing it ). 


> As for making the launcher functionality optional, I am OK with whatever
> the community wants. But before the community takes it out, let me

I don't think the 'community' wants something - and I must admit I had 
very little idea of this going on. 

If _you_ think this is a good idea - you must make a more explicit 
proposal, make sure everyone is aware of this, eventually have a vote
and add some documentation ( a spec / the proposal / whatever ).

I think it is an excelent idea and I would love to see it happen - 
but I don't like the implementation details I'm seeing so far.

Depending on commons-sandbox and reinventing things that are already
in ant, or doing things slightly differently than ant is doing is not very
good. 

You can add the tasks that you need in tomcat, and 'antlib' is
very likely to happen for ant1.6 ( the current feeling is that
ant optional tasks should be split ).


> 1. Make Tomcat 5 startup reliably on Windows (Windows batch scripts are
> notoriously flaky). 
> 2. Emulate the Unix startup on Windows (Windows has no "&" background
> operator like Unix and you cannot redirect stderr to an output file)
> 3. Run background applications (like Tomcat 5 or GUI applications)
> without a DOS shell on Windows.
> 4. Eliminate maintainance of 2 sets of scripts (one set for Windows and
> one set for Unix).

And also:
5. make tomcat startup easy to automate from ant ( all the test
frameworks will benefit )

6. use a well-known format ( , etc ) to describe the env.

7. reuse open-source code instead of reinventing the wheel ( ant ).

8. Add extra features - like multiple profiles ( using different targets
), ability to easily execute 'pre/post' tasks ( like generating the 
apache config files )

And I can go on - there are many other benefits. 

Nobody is arguing ( at least not me ) on the benefits of the idea.


>  From the above list of features, you probably have noticed that the
> launcher does not add any new features for Unix platforms but really
> adds a lot of "fit and finish" to Tomcat on Windows.

I think it adds quite a bit on both unix and windows. 


> So, I think the basic trade-off with using the launcher vs. scripts is
> that with the launcher you get a more native looking application on
> Windows at the price of losing the simplicity of scripts and adding one
> more dependency to the build.

I disagree ( twice )- the bat scripts are not simple, and you _don't_ 
have to add dependencies to the build.


> My recommendation for the community would be to either use the launcher
> or use scripts and not try to accomodate both. I believe that keeping
> the old scripts *and* the launcher would cause a lot more maintenance
> and a more confusion among users.

I partially agree - the scripts are well tuned and work, so there's no
 reason to drop them. 

At least in 3.3 we did a lot of simplifications - like 'guessing'
tomcat.home, etc - so a lot of stuff can be removed.

> If the community chooses not to use the launcher, feel free to 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 Manolache wrote:
>> 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 to describe
>> the paths, conditions, etc. I looked at the code in sandbox - and there
>> are few issues ( many tasks that duplicate existing functionality in
>> ant, etc ), and some should be contributed back to ant ( like the
>> enhancements to Execute ). I support the idea - as long as tomcat code
>> is kept clean and this is optional.
>> 
>> Right now we have a mess of launchers / entry points.
>> 
>> Costin
>> 
>> 
>> 
>> --
>> To unsubscribe, e-mail:
>> <mailto:[EMAIL PROTECTED]> For additional
>> commands, e-mail: <mailto:[EMAIL PROTECTED]>
>



--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: [5] launcher/deamon

[Costin Manolache]

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.jar"  should be enough ( I almost got it working for
>> 5.0, and it works very well for 3.3 ).
>>
>>
> java -jar has one big problem: how do you set java.endorsed.dirs? This
> java.endorsed.dirs problem is one of the primary reasons the Launcher
> forks a child JVM. Since java.endorsed.dirs must be set when you invoke
> the JVM (setting in main() has no effect), you need to use the
> -Djava.endorsed.dirs=... command line argument with JDK 1.4. And since
> setting java.endorsed.dirs in a batch script proved flaky due to the %0
> problem in some Windows versions, I had to fork a child JVM.
> 
> If you find a way around this without forking, let me know because the
> one thing I don't like about my Launcher implementation is the need to
> fork a child JVM.

First of all, there is no need to do that for 1.3, and that's what most
people are using.

Second, endorsed.dirs is a problem only if you want to replace the javax.
or org.xml/w3c packages. And it's a stupid thing - I think we can get
over it, there are far too many problems.

We can still use a different parser/xslt if needed. 

Unfortunately the endorsed.dirs ( and requiring this in command line )
is stupid, and can't be fixed. Hopefully 1.4.2 or other VMs will fix
this - if not we should just live with it. 


>> Have you looked at tomcat(3) Main.java ? It works the same on windows
>> and unix, and all it needs is 'java -jar'. All logic to find
>> TOMCAT_HOME is in java.
> 
> See my JDK 1.4 and java.endorsed.dirs issue above. The java -jar works
> great on JDK 1.2 and JDK 1.3, but not JDK 1.4 when you need a custom XML
> parser and, unfortunately, the default JDK 1.4 parser does not have the
> XML schema support that Tomcat 5 needs so we need to set
> java.endorsed.dirs.

Again, AFAIK you don't need endorsed to use a different parser.

And 'schema support' is needed only for validation - and hopefully 
we stop the stupid practice of validating the same file every time
we start tomcat, even if it is not modified. 

In 3.3 we save a timestamp when we validate and save more 1/2 of 
the startup time for a webapp. With schema validation it'll be much 
worse.

If the user really wants the web.xml validated by a schema ( which
IMHO is plain stupid - tomcat is going to process every piece 
of information from it anyway ) - we can just spawn a java process
with the right endorsed.dirs for validation. After all this will be
nothing compared with the overhead of schema validation.

 
 
>> Of course, passing JAVA_OPTS is a different story - and I'm not sure
>> running a java program to set the options and run another program is a
>> good solution ( the startup time will be pretty big - it is already too
>> big for my taste ).
> 
> A more efficient solution is a native program that uses the Java
> Invocation API to load the JVM and run the target application's main().
> I did not go that route only because I did not want to put native C code
> into Tomcat. But that might be the best course of action in the long
> run.

:-)

Why do people believe you need Invocation or some other fancy
things? A fork()/exec() is enough if you only want a replacement for
a .bat file.

Tomcat does use native code already - the service stuff on windows and
the jk code. The jk code can also be used for chuid() - quite important
in some cases.


>> So I think having multiple options is good - the service wrapper ( C ),
>> the BAT, eventually a small C wrapper, ANT/fork, ANT/in-process.
>> 
>> If we add most logic inside the starter ( creating CLASSATH, detect
>> TOMCAT_HOME, etc ) the external starter can be simple enough.
>> 
>> 
> Makes sense.
> 
> 
>> I was sugesting 'vote' more as a way to get more people aware of this.
>> As I mentioned, I didn't know that the launcher will be required or the
>> BATs will no longer be used. And I suspect other people were in the
>> same situation.
>> 
>> If not a vote - at least a spec describing the 5.0 startup
>> mechansim(s), checked into CVS.
>> 
>> The problem is not on removing the launcher, but on making sure other
>> mechanisms are still possible and we keep it optional at least until
>> commons-launcher has a 1.0 release, enough documentation and stability
>> 
>> 
> How about this: I revert the build back to the old scripts and those
> scripts are copied into the distribution's bin directory. Then, if
> commons-launcher is available, the new scripts (with a different name
> such as catalina-launcher.sh so that old scripts don't get overwritten)
> and commons-launcher also get copied into the distribution's bin
> directory.

> This way, people can try it out and suggest improvements if they want
> to, but the old scripts will still be the default.
> 

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

[Costin Manolache]

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.

It may be a good idea to move the ant tasks/types that you need from
sandbox into oac.launcher. I think they should be in either tomcat
or ant ( preferably). 

Later on, after things stabilise we can propose it for commons proper.

 
> Also, I noticed that you are compiling the ${taglibs.home}/standard/src
> directory. If it helps, you don't need to do this as the expression
> language classes are already compiled and checked into the
> jakarta-tomcat-jasper/jasper2/lib/jsp20el.jar.

My goal was is have all the source that directly affects tomcat compiled.
Not necesarily complete gump-style, but at least 'our' code. 


Costin


> 
> Patrick
> 
> [EMAIL PROTECTED] wrote:
>> costin  2002/08/03 20:48:50
>> 
>>   Modified:.build2.xml
>>   Log:
>>   A more functional build file.
>>   It now creates a fully functional tomcat ( there are few problems
>>   with jasper tough ).
>>   
>>   Also added a task that starts tomcat from ant - with 1.4 you need
>>   fork=true ( I'll try to make few changes to ant classloader to avoid
>>   this ).
>>   
>>   I'm also trying 'everything in a jar' model - there are cases when
>>   you don't need the complex hierarchy.
>>   
>>   Note that the generated tomcat.jar is 2.8M, out of which 1.6 is
>>   tomcat. That's not very bad - if we move backward compat stuff into
>>   tomcat-compat and split some 'optional' functionality we can get well
>>   bellow 1M.
>>   
>>   ( that includes tomcat33 code - i.e. 300k, most of it not used at the
>>   moment, only some non-duplicated modules will be ported )
>>   
>>   Revision  ChangesPath
>>   1.3   +120 -3jakarta-tomcat-5/build2.xml
>>   
>>   Index: build2.xml
>>   ===
>>   RCS file: /home/cvs/jakarta-tomcat-5/build2.xml,v retrieving revision
>>   1.2
>>   retrieving revision 1.3
>>   diff -u -r1.2 -r1.3
>>   --- build2.xml 1 Aug 2002 20:31:15 -   1.2 +++ build2.xml  4 Aug
>>   2002 03:48:50 -1.3 @@ -28,7 +28,7 @@
>>  >   value="${basedir}/../jakarta-tomcat-connectors"/>
>>  -  
>>   +  
>> > value="${base.path}/log4j/log4j.jar"/>
>>  @@ -44,6 +44,14 @@
>>
>>
>>  
>>   +
>>   +  
>>   + +>   />
>>   +
>>   +
>>   +
>>   +  
>> 
>>
>>   @@ -86,8 +94,25 @@
>>  
>>  
>>  >  name="org/apache/commons/logging/impl/LogKitLogger.java" />
>>   -   + +
>>
>>   +  >   name="org/apache/commons/collections/DoubleOrderedMap.java" /> +
>>   
>>
>>   + +  >   dir="${commons.home}/modeler/src/java" > +>   refid="static.res" /> +   +  >   dir="${jtc.home}/util/java" > +>   /> +   +  >   dir="${commons.home}/digester/src/java" > + >   refid="static.res" /> +   +  >   dir="${commons.home}/logging/src/java" > + >   refid="static.res" /> +   +
>>  
>> >   @@ -111,6 +136,40 @@
>>  >  /> >  name="org/apache/catalina/startup/BootstrapService.java" />
>>
>>   +
>>   + +  >   dir="${catalina.home}/catalina/src/share" > +>   refid="static.res" /> +   +  >   dir="${jtc.home}/coyote/src/java" > + >   /> +   +  >   dir="${jtc.home}/http11/src/java" > + >   /> +   +   +   
>>+   +
>>   +
>>   + +>   dir="${api.home}/src/share"> +  >   name="**/*.properties"/> + +
>>   +
>>   +
>>   + +
>>+  >   name="web-app*.dtd"/> + +
>>   +
>>   +   +>   name="web-jsptaglibrary*.dtd"/> + +
>>
>>   +
>>  
>> @@ -129,11 +188,69 @@
>>  >  /> >  name="org/apache/taglibs/standard/lang/jstl/parser/jsp20/ELParser.java"
>>  />
>>
>>   + +  >   dir="${jasper.home}/src/share" > +>   refid="static.res" /> +   +  >   dir="${taglibs.home}/standard/src" > + >   /> +   +
>>   +  
>>   +
>>   +  >   +  description="Create jars" > +>   dir="${build.dir}/lib" /> +>   file="${build.dir}/lib/servlet.jar" > +  >   dir="${build.dir}/classes" > +>   name="javax/servlet/**"/> +   +
>>   +
>>   + + >   dir="${build.dir}/classes" > +>   name="org/apache/commons/**"/> +   +
>>   + +  >   dir="${build.dir}/classes" > +>   name="org/apache/tomcat/**"/> +>   name="org/apache/jk/**"/> +>   name="org/apache/coyote/**"/> +>   name="org/apache/naming/**"/> +>   name="org/apache/catalina/**"/> +   +
>>   +   

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

[Costin Manolache]

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 something, but I had the impression that the bootstrap
> code was linked with the configuration code. I don't see how we can do
> all the changes and add JMX at the core level without doing a new JMX
> based launcher (JBoss style, I guess). Maybe I missed something (too
> much vacation, I suppose) ;-)

Ok. First, I don't think the bootstrap is 'linked' to configuration.
The role of bootstrap is to create 2 classloaders, load a class and
pass all the params. The only possible configuration would be the
location of the server/lib and common/lib - and that could be done
using the trick we discuss ( look in the classpath, find the dir ).
Having one class with start/stop/main/execute/setters and minimal
external deps ( commons-logging and introspection maybe ) should work.

The second step is Catalina/CatalinaService. Again,
having a single story would be really good. This is the real 'entry
point' and should have setters and execute for ant and JMX, as well
as main. 

Regarding JMX - any application can use modeler ( or a similar tool )
and use Catalina.java as a JMX bean. With DynamicMBean it takes
one line of code. After that - no need to use any tomcat-specific
API, it's just a regular MBean.

The configuration is more of an issue after start() is called. If we
want to use JMX 'everywhere' ( JBoss style ) or not - that's a different
issue. I think it is a good idea, but it needs more discussion and 
feedback. So far my 'pre-proposal' on configuration got some 
nodding, but no real feedback or interest. If I'm the only one 
who has this itch - we can leave server.xml, I won't spend the time
implementing something that nobody needs.

Costin 

 



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

[POLL] Configuration API of tomcat5

[Costin Manolache]

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

Possible problems:
- may affect performance ( lots of introspection - jboss does a lot of 
tricks in their jmx impl. )
- we still don't have the test suite for jmx - so licence issues are still
there ( and we don't know if mx4j would pass it )
- we'll be very dependent on JMX - with little control over implementation.
- again, tomcat won't work without jmx.

2. Wrapper->JMX for configuration. 
We can use a small wrapper that will work without JMX. Something
similar with modeler, but with no 'direct' dependency on JMX. We can
register the components with this wrapper and use it to pass/query config
info. If JMX is available, that will translate into JMX calls. 

One possible ( still standard ) API for the wrapper is JNDI. If we 
register all the 'interesting' objects in the jndi we can easily 
'wrap' them for jmx. The APIs are very similar, the code is easy
and most people are supposed to be familiar with the API. There
are other choices as well.

We already depend on JNDI - so no extra deps here, and it'll probably 
be easier to make it work with ldap or other backends.

3. Small config API ( with JMX hooks ). That's what I started in 
util.config - just minimal objectName/attributes/attriubte change 
notifications, no extra overhead. 
That would probably be cleaner and smaller, but it's yet-another-api.

4. Just keep the current API and implementation, with a jmx layer on top. 
The listener provides access to the objects and allows it to transparently
register them with JMX. We rewrite the config read to keep the information
in memory and get all the changes made by user, then save. We could use
DOM or something similar and preserve even the comments ( if XML backend
is used ). 

The key difference is in what we use as a low-level API to 'assemble'
the components. First 3 choices give more decoupling, the third is the
easiest to implement ( almost nothing to change ).

Costin






--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [POLL] Configuration API of tomcat5

[Costin Manolache]

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
>> - reasonably clean
>> - easy to integrate with other apps using JMX
>> 
>> Possible problems:
>> - may affect performance ( lots of introspection - jboss does a lot of
>> tricks in their jmx impl. )
>> - we still don't have the test suite for jmx - so licence issues are
>> still there ( and we don't know if mx4j would pass it ) - we'll be very
>> dependent on JMX - with little control over implementation. - again,
>> tomcat won't work without jmx.
> 
> BTW, I don't see performance being much worse than the current solution,
> which is already very slow, and is also completely based on
> introspection.

It's much more than the introspection we do, plus tons of Strings 
( the ObjectName ), tons of other objects.

But it's not the worse option - JBoss proved that JMX can be made
efficient and that the model works well. 


>> One possible ( still standard ) API for the wrapper is JNDI. If we
>> register all the 'interesting' objects in the jndi we can easily 'wrap'
>> them for jmx. The APIs are very similar, the code is easy and most
>> people are supposed to be familiar with the API. There are other
>> choices as well.
>> 
>> We already depend on JNDI - so no extra deps here, and it'll probably
>> be easier to make it work with ldap or other backends.
> 
> Maybe.

We should discuss this one a bit more - it basically means a DirContext
that doubles as MBean. ( JBoss has a ContextMBean that can be used to 
view the jndi objects from the admin interface, that's slightly different ).
If we do that all config information will be accessible in both ways.

The APIs are very similar, except the goal of JNDI is more 'storage' 
( not for java:env, but LDAP and all other ), JMX is more 'runtime data'.
And JNDI is more focused on the hierarchy of the DN, while JMX leaves it
almost unspecified as semantic but is strict on syntax.



>> 3. Small config API ( with JMX hooks ). That's what I started in
>> util.config - just minimal objectName/attributes/attriubte change
>> notifications, no extra overhead.
>> That would probably be cleaner and smaller, but it's yet-another-api.
> 
> That's up to you. If you think it's useful to use a middle man between
> JMX and the Tomcat code, then I think it's good.
> 
> An advantage of that one may be that the (needed) refactoring of the
> config save may actually be clean, and that it abstracts the
> configuration storage (good).

Well, I can't start much code until I know what people want.
And that involves API in the first place, and data format ( for the
default XML file ). But API is the most important.

It seems either everyone is in vacation or too busy - and this is 
too important an issue to do alone. 


>> 4. Just keep the current API and implementation, with a jmx layer on
>> top. The listener provides access to the objects and allows it to
>> transparently register them with JMX. We rewrite the config read to
>> keep the information in memory and get all the changes made by user,
>> then save. We could use DOM or something similar and preserve even the
>> comments ( if XML backend is used ).
>> 
>> The key difference is in what we use as a low-level API to 'assemble'
>> the components. First 3 choices give more decoupling, the third is the
>> easiest to implement ( almost nothing to change ).
> 
> The 3rd one looks the most interesting. It provides a good level of
> abstraction while being independent from JMX.
> 
> I'd be willing to help implement it.

That would be great - but first I think we need to find more help in
designing it, at least more feedback on which direction to go.

I love java and OO programming, but sometimes I have a feeling it uses
too many ( and too bloated ) APIs and interfaces, and I don't want to
agravate this :-) That's why I slightly perfer one of the first 2 aproaches. 


Costin



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

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

[Costin Manolache]

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 can do it first in an 'optional' way - 
like a separate module that can be excluded and will be
used based on some option. It may need some hooks.

If you want to start on this, I would propose we branch the 
code for a stable 1.0 release.

My current thinking is to use 4.1.9 ( or whatever is the stable
release) as a tag for jk1.2 'stable' and jk2 'beta'.

Costin

 

On Fri, 09 Aug 2002 04:07:27 -0700, Mladen Turk wrote:

> Hi,
> 
> Remember the last month advanced URI space resolution I proposed?
> 
> Well, I've been working on that for a week or so, and found myself doing
> things that are more or less regular expression matching of request uri.
> Even existing uri_map code has a trace of that (matching star for
> example), so IMO (since we are matching things) we could use the regex
> code as a general uri->file space matching solution. That way the users
> will be able to use the same syntax as for the  or
> mod_proxy, allowing one to make complex uri resolutions, like TRUE/FALSE
> cases.
> 
> The major drawback of that is that we'll need the pcre library, either
> one that comes with the Apache 2 (by Philip Hazel) or Apache 1.3 (by
> Henry Spencer). Since the same should be used with the IIS and other
> platforms, I suggest that we use the one from Apache 2.0.
> 
> Using pcre will introduce the need for build process changes (only 2.0
> can use the proposed pcre from its own build) and we'll need the
> pcre.lib.
> 
> Thoughts?
> 
> MT.



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Few additions to CatalinaService

[Costin Manolache]

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 far too 
many.

I would also add some description of those methods in the 
mbean-descriptors.xml file ( or just add a call to DynamicMBean ).


Costin



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [GUMP] cactus-sample-servlet builds

[Costin Manolache]

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 Tomcat 3.3 and I get some strange errors
> in my machine (not the same one as you got in your URL below). See
> attached file.
> 
> Has Tomcat 3.3.2 switched to commons-logging ?

Not yet. Jk depends on commons-logging tought.

There is code in CVS that would switch tomcat to commons-logging
( it's a one-line change in Log to set the default ). 

Costin

> 
> Thanks all for your help!
> -Vincent
> 
>> -Original Message-
>> From: Stefan Bodewig [mailto:[EMAIL PROTECTED]]
>> Sent: 09 August 2002 07:21
>> To: [EMAIL PROTECTED]
>> Subject: Re: [GUMP] cactus-sample-servlet builds
>> 
>> On Thu, 8 Aug 2002, Larry Isaacs <[EMAIL PROTECTED]> wrote:
>> > Done.
>> 
>> Great.
>> 
>> It seems to have helped a little bit
>> > servlet-12.html>
>> > servlet-13.html>
>> 
>> Thanks
>> 
>> Stefan
>> 
>> --
>> To unsubscribe, e-mail:   > [EMAIL PROTECTED]>
>> For additional commands, e-mail: > [EMAIL PROTECTED]>




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [5] Config

[Costin Manolache]

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 already
written, we have a lot of support ( caching, etc ) already and Remy is an
expert.


>> For API - my initial approach was to create a clone of 1.4 prefs.
> 
> Thinking outside the box a little, what would be the implications of
> prereq'ing JDK 1.4 as the minimum for Tomcat 5?  Then, we could consider
> using prefs directly instead of via wrappers.

The reason I prefer JNDI over prefs have nothing to do with the VM. 
JNDI is much more mature, more widely used, more powerfull, we
already have a lot of support and knowledge, there are many drivers.

And it supports the 'distributed / high-end' use case ( directory 
server ) out-of-box.

I don't mind having prefs used by default if 1.4 is detected - 
i.e. registry on windows and .xml files on unix. It is quite
easy to write a JNDI context that uses prefs underneath. 
I don't mind using 1.4 features - but using 1.4 as a minimm is 
a bit too much. Even 1.3 may be questionable. 

For me the baseline is what GCJ supports ( i.e. the classpath project ).
I still believe in 'java everywhere' :-)


> Using DirContext instead of just Context would also let us think about a
> storage format with fewer objects in it -- one per managed object instead
> of one per property -- because we could use JNDI attributes for the
> individual properties themselves.  Such an entry maps pretty directly to
> *being* an MBean as well ... it might be possible to kill two birds with
> one stone here.

Exactly ! And one nice thing in JNDI is that we can do a lot of 'lazy'
evaluation. If nobody is going to configure an object, there is no
point introspecting it. Just bind it to a context and when someone
asks for attributes we do the introspection. And you can also 
construct objects dynamically - which is even better. 

JMX will require you to register each object and most implementations
will do a full introspection when you register. And that involves a lot
of objects and overhead.


> Some utility methods that perform direct conversion between the structured
> name types would be well worth it performance-wise.  We don't want to be
> dealing with the String versions of these names any more than we'd have
> to.

+1
The jndi Name is not bad. And it maps well into JMX ObjectName. 


>> Using notifications it is possible to propagate any change via
>> JMX to the store - but that should be optional ( i.e. you could
>> choose to not change the store, but only the runtime ).
>>
> 
> Note that this would need to include configuration changes the component
> does for itself (i.e. calculate the work directory path if one hasn't been
> explicitly configured), not just those performed by external management
> tools.

I don't agree. The configuration is what the user specifies. What the 
component determines by itself shouldn't slip into the config file. 
Only user-initiated config must be stored ( exactly like if the user would 
edit the file directly and restart ). 

 
>> Any operation ( reload, etc ) will be done via JMX - only
>> setting attributes is important for config.
>>
> 
> While on that topic, it would be useful for some managed objects to
> support two "instances" of a component in memory simultaneously -- for
> example, when upgrading a webapp you often want to leave the old version
> running (and accepting requests) until the new version has been fully
> initialized and is ready to start accepting requests.

Probably a 'ver' component in the name ? 

We really need to reorganize the JMX names.


> Part of the motivation for JMX in the first place was to support the
> ability to have external management apps be able to talk with it.  If we
> didn't need that, we wouldn't really need it -- we could just use JNDI to
> represent the internal component hierarchy (extending the way Catalina
> already represents a webapp's static resources as a JNDI context).

I know. JMX is also necesary to support 'operations' ( reload, start, etc ).
But the nice thing about using JNDI as the 'first line' is that JMX can
be used with less performance impact. For example we can have a 'master'
jmx object that would register other on demand - using the information
in the JNDI hierarchy.

 
 
> One avenue to consider if the number of MBeans becomes an issue (I'm not
> sure that it really is -- we've got an instance of the real component
> class per component anyway) is to make MBeans only for coarse grained
> things, and represent fine-grained things as attributes of the coarse
> grained MBeans.  Conceptually, this is the same sort of design choice you
> make with entity EJBs about how fine grained you get.  It's not
> necessarily an all-or-nothing decision.

Well, on MBean per servlet is important if you wa

Re: [5] [TODO] Config first task

[Costin Manolache]

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 '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.

One way or another, we need each internal object to be aware of its
name - and it can cache the DirContexts it needs ( to avoid duplicating
lookups, etc ).

 
> As I see it, we'll have the JNDI config which will be used by the
> Catalina objects (like StandardContext) to store their config. The
> question is do we make those objects the MBeans. I think we can use the
> modeler to do that easily, instead of having the MBeans be another set
> of separate objects.

I don't think they need to be registered by default, but it is indeed very
easy to turn them into MBeans via modeler. Probably the same listener 
mechanism can be used ( jndi also has some events to notify of new objects
and attribute changes - similar with the Lifecyecle and catalina-specific 
events used to registrate the mbeans in the current code ).

We need to have each configurable object into the mbean.xml descriptor, 
which may eventually turn with some magic into an ldap schema. 

I am thinking to propose use of commons-discovery and a META-INF/mbeans.xml
in modeler - so a jar containing tomcat modules will include it's onw
description, and an easy mechanism to find it.


>> We still need to 'bind' the initial context for each webapp so that
>> webapps can see their separated envs. But internal code
>> should have access to the root of the tree, for example stored in
>> some top-level objects - and be able to access anything with a simple
>> lookup.
> 
> For the J2EE ENC, you have to do the binding:
> - for security reasons, otherwise the webapp could find a way to access
> another context
> - because the lookup call is "static" (it's not, but it would be exactly
> the same if it was), you have no way otherwise to do the lookup in the
> right context

I know ( for webapps ). I was talking about internal and 'priviledged' 
apps, who don't need that. They should be able to access the 'root', 
and shouldn't use the thread binding ( which sometimes is confusing 
and even dangerous ) 

BTW, another idea: what about trying to create a jndi context
for web.xml ? Then same kind of code that manages server.xml will be able
to manage web.xml for apps. 
 
Costin



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [5] [TODO] Config first task

[Costin Manolache]

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 the component a
> reference to the right context.

That's something I don't understand. 

Each app is supposed to get it's own DirContext, using the same name.
And that's done by binding it per thread or class loader.

However this DirContext may also be binded in the 'big tree' - and
internal code could access all those 'enc' contexts. 

>> I am thinking to propose use of commons-discovery and a
>> META-INF/mbeans.xml in modeler - so a jar containing tomcat modules will
>> include it's onw description, and an easy mechanism to find it.
> 
> Ok, since you have ideas, feel free to experiment ;-)

Sure. Just trying to get feedback and maybe get other people interested.
So far only 2 people seem interested in 'common-discovery'.
I want to use it for an antlib 'experiment', but it would also help
for tomcat. Something like ant's ProjectHelper hook to plug in 
different jndi config drivers ? 

Costin



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [5] [TODO] Config first task

[Costin Manolache]

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, you can for example give StandardContext a reference to
> the DirContext which contains the webapp configuration data. So no
> thread binding needed.

I think we're talking about different things.

Say I want to read WEB-INF/web.xml for application /examples. 
Right now it seems what I have to do requires the use of the thread
or cl binding to locate the jndi context representing the war/files.

What I would like to do from inside tomcat is:
 globalContext.lookup("host=localhost:8080, path=/examples, 
file=/WEB-INF/web.xml") 

( or some / based name: FILES:/localhost:8080/examples/WEB-INF/web.xml ).

I couldn't find any way to do that. 

For the java:/comp/env - yes, the Context must be bound so that
the app can locate it using the InitialContext(). But it can 
also be bound in the 'globalContext' - so that an admin app or 
some listeners can see/alter the webapp bindings.  

What I'm trying to say is that thread/classloader binding is 
required in some cases, but it can be avoided in many other cases. And
in general there are a lot of 'tricky' things about it ( like if you 
create a new thread and the binding no longer works ).


>> Sure. Just trying to get feedback and maybe get other people interested.
>> So far only 2 people seem interested in 'common-discovery'.
> 
> I didn't look at it at all, sorry :-(

It's about using META-INF/services, and in general about supporting a 
pattern where each .jar includes some resource with a fixed name 
and you want to manipulate it.

Examples:
- locate Listeners/Valves/Interceptors that are installed, so that the
admin can display all available modules
- locate and automatically load any META-INF/mbeans.xml so that each module
can register his own description transparently
- possibly META-INF/ant.tasks ( or just 
META-INF/services/org.apache.tools.ant.ProjectComponent ) - and have the 
tasks automatically declared
- declare some interface for tomcat configurator ( like ant's ProjectHelper)
and have it loaded automatically. ( or different configurators that are 
available, each getting a chance to configure )
- declare the JNDI providers or JDBC drivers so you don't need to 
explicitely declare them
- support multiple parsers - and have a way to choose which one to use
( instead of 'select first' )

And so on.

Costin





--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

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

[Costin Manolache]

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, "Error connecting to tomcat. Tomcat is
>>   probably not started or is listenning on the wrong port. Failed errno =
>>   %d\n", errno); +

( instead of the "Can't find servlet handler" :-)

I just limited the number of messages that are logged at ERROR level
for each failed connection, you should see a single error message.
If you want more verbosity - you'll get it as info.


Costin



> 
> Regards,
> 
> Glenn
> 
> [EMAIL PROTECTED] wrote:
>> costin  2002/10/30 14:12:20
>> 
>>   Modified:jk/native/common jk_ajp_common.c jk_connect.c
>>   Log:
>>   More trimming for error messages.
>>   
>>   Now only one line ( and hopefully more informative ) is displayed if
>>   we can't send the request to tomcat.
>>   
>>   Revision  ChangesPath
>>   1.32  +11 -5
>>   jakarta-tomcat-connectors/jk/native/common/jk_ajp_common.c
>>   
>>   Index: jk_ajp_common.c
>>   ===
>>   RCS file:
>>   /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_ajp_common.c,v
>>   retrieving revision 1.31 retrieving revision 1.32
>>   diff -u -r1.31 -r1.32
>>   --- jk_ajp_common.c30 Oct 2002 21:17:34 -  1.31
>>   +++ jk_ajp_common.c30 Oct 2002 22:12:20 -  1.32
>>   @@ -623,7 +623,9 @@
>>}
>>}
>>
>>   -jk_log(l, JK_LOG_ERROR, "ERROR connecting to tomcat. Tomcat is
>>   probably not started. Failed errno = %d\n", errno);
>>   +jk_log(l, JK_LOG_INFO,
>>   +   "Error connecting to tomcat. Tomcat is probably not started
>>   or is listenning on the wrong port. Failed errno = %d\n",
>>   +   errno);
>>return JK_FALSE;
>>}
>>
>>   @@ -869,7 +871,7 @@
>>return JK_FALSE;
>>}
>>} else {
>>   -jk_log(l, JK_LOG_ERROR, "Error connecting to the Tomcat
>>   process.\n");
>>   +jk_log(l, JK_LOG_INFO, "Error connecting to the Tomcat
>>   process.\n");
>>return JK_FALSE;
>>}
>>}
>>   @@ -1175,15 +1177,19 @@
>>return JK_FALSE;
>>}
>>
>>   -jk_log(l, JK_LOG_ERROR, "ERRORO: Receiving from tomcat
>>   failed, recoverable operation. err=%d\n", i);
>>   +jk_log(l, JK_LOG_ERROR, "ERROR: Receiving from tomcat
>>   failed, recoverable operation. err=%d\n", i);
>>}
>>else
>>   -jk_log(l, JK_LOG_ERROR, "ERROR: sending request to
>>   tomcat failed in send loop. err=%d\n", i);
>>   +jk_log(l, JK_LOG_INFO, "sending request to tomcat
>>   failed in send loop. err=%d\n", i);
>>
>>jk_close_socket(p->sd);
>>p->sd = -1;
>>ajp_reuse_connection(p, l);
>>}
>>   +
>>   +/* Log the error only once per failed request. */
>>   +jk_log(l, JK_LOG_ERROR, "Error connecting to tomcat. Tomcat is
>>   probably not started or is listenning on the wrong port. Failed errno =
>>   %d\n", errno); +
>>} else {
>>jk_log(l, JK_LOG_ERROR, "In jk_endpoint_t::service, NULL
>>parameters\n");
>>}
>>   
>>   
>>   
>>   1.6   +2 -2 
>>   jakarta-tomcat-connectors/jk/native/common/jk_connect.c
>>   
>>   Index: jk_connect.c
>>   ===
>>   RCS file:
>>   /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_connect.c,v
>>   retrieving revision 1.5 retrieving revision 1.6
>>   diff -u -r1.5 -r1.6
>>   --- jk_connect.c   4 Sep 2002 11:31:33 -   1.5
>>   +++ jk_connect.c   30 Oct 2002 22:12:20 -  1.6
>>   @@ -174,7 +174,7 @@
>>jk_log(l, JK_LOG_DEBUG, "jk_open_socket, return, sd =
>>%d\n", sock); return sock;
>>}
>>   -jk_log(l, JK_LOG_ERROR, "jk_open_socket, connect() failed
>>   errno = %d\n", errno);
>>   +jk_log(l, JK_LOG_INFO, "jk_open_socket, connect() failed errno
>>   = %d\n", errno);
>>jk_close_socket(sock);
>>} else {
>>#ifdef WIN32
>>   
>>   
>>   
>> 
>> --
>> To unsubscribe, e-mail:  
>>  For additional
>> commands, e-mail: 




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

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

[Costin Manolache]

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,
> 
> I would like to propose the following re-factorisation of the current
> Realm interface. Righ now, Realm contains 3 methods related to
> authorization:
> 
> hasRole
> hasUserDataPermission
> hasResourcePermission
> 
> I would like to create a new interface called Authorizator(and a default
> AuthorizatorBase) that will take care of those methods. I just think
> those methods should be grouped together, and I think they are not
> directly related to the Realm "concepts" (better separation of
> concepts). It will allows peoples to change the current resource
> authorization mechanism without having to modify the Realm interface.
> 
> Precisely, the method will have the following signature:
> 
> public boolean hasResourcePermission(HttpRequest request,
> 
> HttpResponse response,
> 
> SecurityConstraint constraint,
> Context
> context)
>
> public boolean hasRolePermission(HttpRequest request,
> HttpResponse
> response,
> String role);
> 
> public boolean hasUserDataPermission(HttpRequest request,
>  HttpResponse response,
>  SecurityConstraint constraint,
>  Context context)
> 
> In the current implementation, those methods  will get invoked by the
> AuthenticatorBase and when the user call isUserInRole().
> 
> This factorisation will provide the ability to replace/extend the
> default AuthorizatorBase (that implement the Servlet
>  stuffs...section SRV 12.7) by another mechanism:
> LDAP, NFS, Database, File base, JSR 115, etc. This way peoples will be
> able to grant/denied permissions not only based on the web.xml content,
> but also using other technologies. Althrough it is possible to do that
> with the current Tomcat 5 codebase, I recommend we create this extra
> interface. For J2EE 1.4, I was able to implement JSR 115 without having
> to much problems, but I'm sure having a specialized interface will make
> implementation easier.
> 
> The Realm.hasRole will be deprecated in order to achieve that
> re-factorisation.
> 
> What do you think?
> 
> Thanks,
> 
> -- Jeanfrancois




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

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

[Costin Manolache]

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, but I don't think you can use it for
> granting/denying web resources (JSR 115 is exactly doing that). With
> 115, you can use the normal policy statement to grant web resources
> permission:

I was thinking at authentication ( this is the main use of Realm AFAIK ).

JAAS is also used for authorization ( I don't know about JSR115),
but in tomcat case the mapper and the web.xml stuff controls this,
and I don't see any good reason to change this.


> ex (for the admin tool)
> 
> grant  codeBase "file://admin" , principal
> org.apache.catalina.realm.GenericRealm "tomcat" {
>
> // Role Mapped for this Grant : admin
> permission javax.security.jacc.WebResourcePermission "*.jsp" ,
> "DELETE,GET,HEAD,OPTIONS,POST,PUT,TRACE";
> // Role Mapped for this Grant : admin
> permission javax.security.jacc.WebRoleRefPermission "action" ,
> "admin";
> // Role Mapped for this Grant : admin
> permission javax.security.jacc.WebResourcePermission "*.html" ,
> "DELETE,GET,HEAD,OPTIONS,POST,PUT,TRACE";
> // Role Mapped for this Grant : admin
> permission javax.security.jacc.WebResourcePermission "*.do" ,
> "DELETE,GET,HEAD,OPTIONS,POST,PUT,TRACE";
> };
> 
> will get translated to javax.security.jacc.WebResourcePermission,
> WebRoleRefPermission and WebUserDataPermission. In order to only use
> JAAS, we will have to:

Why would someone use this instead of web.xml ? 

I don't mind having the security config consistent with the policy 
( I never liked how it's done in web.xml ). However at least from my
point of view the more interesting issue is integrating with the web
server semantics and syntax ( and how to write the authorization 
definition in httpd.conf ).


> (1) Associate the Subject with an access control context (already done
> in Tomcat 5)
> (2) Define are own set of permission object/mapping.


 
> If we decide to go with only JAAS, then I recommend we use JSR 115
> instead of redefining something. But I would prefer opening the API for
> other technologies instead of limitating us with JAAS. Of course we can
> ship with a JAAS/115 default implementation. Between Tomcat and JAAS, we
> will need an "interface". That's what I'm proposing. Righ now both
> authentication and authorization are in Realm.

What's wrong with using JAAS as an "interface" ? After all that's 
the purpose of JAAS - an interface for authorization ( and authentication ).

I'm not sure we're talking about the same things.


>>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.
>>
> Authorizer and AuthorizerBase (proper english this time :-) ) are not
> about user/group, but about granting web resources to user and group.
> JNDI can used for replacing/improving the Realm implementation, but IMO
> not to grant/denied web resources (OK we can always define our JNDI
> permissions). Is that was you mean or do I miss something with JNDI?

I mentioned JNDI as an API to access (abstract) information about users.
JAAS for authentication.

If by authorization you mean deciding in an URL can be accessed by a user -
I think the mapper ( or a similar valve ) is the best solution, using
the informations in web.xml. 

Since the problem of mapping this into httpd.conf semantics is alrady
very complex ( and not completely resolved), I would need a lot of arguments
in opening this up to arbitrary user code - that would be close to 
impossible to integrate with the web server and have consistent behavior.

Having the web server call tomcat for each static page in order to call
this authorization hook is not acceptable.

Costin





--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

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

[Costin Manolache]

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 used in tomcat. But I see 
your point - and I think it would be nice to use similar concepts or 
API.



>>If by authorization you mean deciding in an URL can be accessed by a user
>>- I think the mapper ( or a similar valve ) is the best solution, using
>>the informations in web.xml.
>>
> Exactly. The "similar valve" :-) is the AuthenticatorBase, who delegate
> part of the authorization decision to the RealmBase, as well as part of
> authentication. I'm +1 to delegate the authentication to the RealBase,
> but -1 to delegate the authorization (this is how it is implemented
> right now). What I recommend is to remove the authorization code from
> the RealmBase and move it to the AutorizerBase.  It's just refactoring
> one class into 2. Then we will be able to use JAAS (or 115, LDAP, NFS,
> etc.) in a "cleaner" way.
> 
> Using JAAS as an interface will have to happen somewhere in
> AuthenticatorBase & RealmBase. Since in JAAS there is a clear separation
> between authentication/autorization, why not have the same separation in
> Tomcat by having Realm & Authorizer (instead of only Realm).


I agree that "authenticate" and "authorize" are 2 different hooks and need
to be separated. 

Let me think about it - and maybe get some other opinions. 

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 ). In 4.x Valves
are used as the main extension mechanism, but also Listeners, Realms, 
Connectors and few other interfaces - and I would very much prefer
a solution that is more consistent and simpler.

 
For example - move it at Coyote level and use an ActionCode for 
authorization. Things are not very well defined for chaining the 
coyote actions, but it can be done easily. 

All hooks could be defined as coyote Actions - instead of having a specific 
Authorizer interface you'll have an authorizer action. 

Does it sound acceptable ? I would mention that this is how authorization 
is implemented in apache ( and most web servers ), and it would probably
make it easier to integrate.

Well, there is just a style difference between having a generic hook
and having one specific interface like Authorizer, but for a lot of people
understanding the hook mechanism and the particular hooks is easier than
dealing with dozens of slightly different interfaces.

Costin









--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

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

[Costin Manolache]

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, since we need access to the realm to perform
> it. However, the code in the current authenticators will enventually be
> rewritten Coyote-style (and using tomcat-util objects) so that it
> actually performs well.

That's orthogonal and not the subject of this discussion ( the proposal
is about authorization, not authentication ).

Also the issue of using coyote hooks ( Action ) or a custom interface is 
orthogonal on what information is needed, in both cases the implementation
of the authentication hook ( or interface ) will have access to the same
information ( Request, user info, etc ).



> I think a refactoring of the realms is needed in order to support any
> auth scheme (most realms don't work with digest). To be able to do

+1.

I would add to the wish list better support for web server integration.
It would be nice ( at least for jni mode ) to be able to have the 
native server call the hook to auth static resources - but the real
important thing is allow the native server do it ( and the countless auth 
modules ).


> We should probably standardize on storing the limited digest defined in
> the RFC in the realms instead of the clear password or some kind of
> unusable digest of the password.

I like the move to split the storage of the info about user from Realm,
as well as the split of authorization/authentication. I don't like 
the current abstraction for user info ( and the fact that all users 
need to be in memory ), and I would preffer use of a consistent hook
mechanism ( coyote Action ) instead of special interfaces.

Costin






--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

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

[Costin Manolache]

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 ). In 4.x Valves
>>are used as the main extension mechanism, but also Listeners, Realms,
>>Connectors and few other interfaces - and I would very much prefer
>>a solution that is more consistent and simpler.
>>
> Just downloaded 3.3 code base. I will take a look at the way it work. I
> not familiar with 3.3 code base.

The important codebase to take a look at is Apache2 :-) You can also
check axis, they have a very nice hook mechanism ( very similar with 
apache2 and everything else, but the java implementation is quite good ).

Tomcat3.3 is a bit closer to apache1.3 modules ( one interface, one 
method per hook chain ), and it has the same limitations.

The idea is quite simple: have a consistent API for all supported hooks.
Chain + Handler or whatever name is used is fine. Both iterative
and recursive ( Valve ) are fine ( and can be used in the same chain !).

> I agree. If It possible, I will come up with an ActionCode. If not, then
> we should use the Authorizer idea.

I'm very sure it is possible ( with some extensions to Action maybe, but
it's the same thing ). The pattern is used in a lot of projects and 
most servers I know.

Costin





--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [4.1.16] [VOTE] Stability rating

[Costin Manolache]

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-mail:   
For additional commands, e-mail: 

Re: Jasper Classloader question

[Costin Manolache]

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 direction
> please.

Use jspc, that will generate regular servlets that are loaded in
the same loader.


Costin

> 
> I know that I am going to have to change some classes and this is a temp
> solution for us but something that is needed.
> 
> Again any help is great..
> 
> Thanks,
> 
> john




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [5.0] Cluster features

[Costin Manolache]

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, the amount of work that
> will have to be done to have quality clustering features seems small.
> 
> Most of the current clustering API will be removed in the process, since
> it doesn't seem to be maintained anymore, and didn't evolve past
> experimental stage (if I am wrong on that, let me know).
> 
> I also plan to bundle JavaGroups with Tomcat 5, as it only adds a 1MB
> standalone JAR. Configuring Tomcat for clustering will be quite easy
> once all the code is in place.
> 
> I don't know if that plan is acceptable for everyone. Originally,
> I -1ed the code submission because of licensing and absence of
> integration with the existing Cluster API. The licensing issue is still
> there, but since the Cluster API now seems sort of dead, another
> solution has to be found (IMO, of course there's JK available).
> 
> Comments ?

+1 if all new code goes in a separate module ( instead of catalina ), 
and is built as separate .jar(s).

I think it is time to stop bloating the base tomcat source and binaries.

BTW, it may be a good time to move some of the current features in separate
modules as well. ( SSI, WebDAV, etc ). For webdav - I would rather see slide
bundled with tomcat and the current code deprecated.

I'm not talking ( for now ) about a real module with descriptors or 
anything, just separate dirs in the CVS and a .jar target that can be 
included or not. 

It may be worth reopening the "minimal tomcat" discussion :-)

Costin
 







--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [5.0] Cluster features

[Costin Manolache]

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 it's a lot better to stop the hacks *now*, fix that, and put
> everything in the cluster package.

Well, if you must - you must. 
But we shouldn't have the core depend on the clustering, just add the 
minimal stuff that you need in the session. 

If we can stop the hacks and clean something - I think 5.0 is the best 
chance.

I would preffer to have a consistent hook mechanism for everything - 
I'm not sure what callbacks will be involved in the clustering.
 

>> It may be worth reopening the "minimal tomcat" discussion :-)
> 
> Maybe. If the difference is only a couple MBs, then it's not worth it,
> though.

Bloat is not about MB or storage. It's about code complexity, potential
security, etc. 


> If we do an alternate distribution, it would have to be radically
> different IMO (like for example, being a simple set of JARs without the
> complex dir structure). The laucher + the catalina.properties + future
> mods to the config system should make that easy.

That's what I was thinking about - a set of jars and minimal configuration.
Eventually using only MBeans for configuration and setup.

BTW, we could use MBeans for the optional packages too. I think it works
pretty well. We'll need to get a consensus on requiring JMX for tomcat5,
but so far it doesn't seem it'll have a big impact on the code ( I did
all kind of experiments with modeler and ant lately ).

Costin



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [5.0] Cluster features

[Costin Manolache]

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) :-P
>>>
>>>I suppose it's a lot better to stop the hacks *now*, fix that, and put
>>>everything in the cluster package.
>>>
>>>
>>
>>Well, if you must - you must.
>>But we shouldn't have the core depend on the clustering, just add the
>>minimal stuff that you need in the session.
>>
>>If we can stop the hacks and clean something - I think 5.0 is the best
>>chance.
>>
>>I would preffer to have a consistent hook mechanism for everything -
>>I'm not sure what callbacks will be involved in the clustering.
>>
> Are you thinking about having coyote Action(s)?  If yes, we might one to
> extend the current API having in mind that we will need to supports
> Clustering, Authentification, Authorization, etc.

I don't care too much if it is called Coyote Action, Jk2 Handler, 
3.3 Interceptor(with a single method), or 4.0 Valve ( in multiple chains )
or Axis Handler/Chain. Or even Event/Listener.

Some time ago I started a package to implement yet-another hook, as a 
replacement for Action in coyote. I remove it because there is absolutely
no point for yet another API - any of those APIs can do the job.

All I want is a single and simple and consistent hook mechanism that is used 
for callbacks in all "extension points" ( simple is quite important :-)

Since Coyote is now used in all tomcat versions and also jk - I think
it is a good idea to use with coyote Action. But I'm +1 on anything else -
as long as we converge on a single mechanism ( it is simple
to wrap any hook - Vavle, interceptor, action. into any interface )


Costin



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Strange Tomcat 4.1.x release versions

[Costin Manolache]

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
> Sun is going to deal with releasing Java 2.0 and the confusion that is going
> to create with Java2. What a brain dead idea that one was.

We follow exactly the same numbering scheme as apache2. 
13,14,15 had problems and followed the same path as apache2.0.13,14,15
( i.e. they are not released as beta or stable ).

Hopefully 4.1.17 will be a "release quality" - and we'll not get to 40s.

> 
> I'm also not seeing a vote taking on the list about whether or not to do a
> release...or at least some sort of advance warning.

It was voted on the list, Remy sent the proposal last week.


Costin

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [5.0] Cluster features

[Costin Manolache]

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
> mechanism. Making those classes "public" can be dangerous if the package
> protection is not enabled.

That depends on the class loader - if tomcat is embedded in something else
( like J2EE or some other app ) I'm not sure how it'll protect this.

Also, a number of classes are public because they are intended to be used, 
and a number of security problems may happen ( as we learned ) even if the
class is not accessible ( like the recent web.xml entity issues ).


>>> Bloat is not about MB or storage. It's about code complexity, potential
>>> security, etc.
>>
>>
>> Ok. All distributions need to be thought as secure, though.
> 
> Does that implies re-writting the current set of classloader? It might
> be a good time to revisit classloader and security :-)

Do you have so much free time :-) ? I'm +1 BTW.

If we reach consensus on JMX - it may be a good idea to use its class 
loading mechanism, or something very close - the model in theory is 
very good. You have full control ( using mlet tags or API ) over
the class loaders and hierarchy.

>> +1 for JMX (as there's MX4J); as well as JNDI, BTW.
> 
> +1

I'll send a separate mail with a VOTE subject.

Costin



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

[VOTE] Making JMX required in tomcat5

[Costin Manolache]

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 our components into model mbeans. 

We already have 3 +1 votes ( costin, Remy and Jean Francois ).

The only possible problem is the classical licensing issue
( we must use mx4j - but I don't know if they passed the TCK
or if they will or if the TCK is available yet, etc ).  

Costin



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Jasper 2 Synchronized JSP compiles

[Costin Manolache]

+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 javac memory leak.
> 
> 2. JSP page compiles are synchronized.
> 
> 3. Jikes currently can't be configured for windows because the windows
> build of
> jikes doesn't support -encoding.
> 
> 4. We may be getting some bug reports related to this problem noted in the
> Ant
> documentation for the javac task:
> 
> Windows Note:When the modern compiler is used in unforked mode on Windows,
> it locks up the files present in the classpath of the  task, and
> does not release them. The side effect of this is that you will not be
> able to delete or move those files later on in the build. The workaround
> is to fork when invoking the compiler.
> 
> Recommendation:
> 
> Change Jasper 2 so that it tells ant to fork the javac compile.  This
> should remove the need
> to synchronize the compiles.  It will also move java compilation outside
> of the JVM process Tomcat is running in saving JVM heap memory and
> reducing GC overhead from objects created for
> JSP compiles.  This could be done by just adding another parameter called
> "fork" to the JspServlet paramters. If fork=true ant forks the javac
> compile and no synchronization is done. The default for fork would be
> false.
> 
> Comments?
> 
> Regards,
> 
> Glenn




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

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

[Costin Manolache]

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 methods
> for managing these.  Also a UserDatabase can be instantiated as a JNDI
> resource.
> 
> It would be nice if all realm implementations could support not only
> authentication
> and authorization but also management of users, groups, and roles.  And be
> instantiated as a JNDI resource so it can be provided by the container as
> a resource to a virtual host.

Requiring all realm implementations to support user management is 
not a good idea. Some realms can do that ( database, our own file, ldap)
and some just can't ( passwd, kerberos/radius/tacacs, etc ).

I think we have 3 distinct issues:
- authorization: I think tomcat needs to expose a single hook and provide
a default implementation ( using the mapper - it can also implement jsr115,
but it needs to be efficient )

- authentication: again one hook that could be implemented by delegating
to apache or use JAAS ( that should be the default - and all current
Realms migrated to JAAS plugins ! )

- user management. That should be optional - and probably the best 
abstraction is JNDI. Besides user/pass/certificate it can store all other
user attributes. I think we should be consistent on naming the attributes 
as in the inetUser LDAP schema ( it will work out-of-box with existing
ldap servers and easy to translate to databases, etc ). All UserDatabase
impl should be migrated to JNDI providers, and UserDatabase deprecated (
or implemented on top of jndi ).

Costin



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

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

[Costin Manolache]

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 codebase's where bug fix patches have to
>>> be applied to a
>>> minimum.
>>>
>>> There are alot of ideas for new features that I would like to see end
>>> up in a Tomcat 4.2
>>> release. Especially since we don't know when the Servlet 2.4/JSP 2.0
>>> specs will be finalized
>>> so that Tomcat 5 can be released.
>>>
>>> There isn't that much difference in the core of catalina between the
>>> Servlet 2.3 and
>>> Servlet 2.4 specs. It might be possible to change the
>>> jakarta-tomcat-catalina codebase
>>> to make it neutral to what Servlet spec is implemented.  Then this
>>> codebase could be
>>> used for future Tomcat 4 and Tomcat 5 development.  And we then have a
>>> common codebase
>>> for applying bug fix patches.
>>>
>>> This seems to fit in with the direction we have been going where
>>> different components
>>> are kept in different code bases. naming, connectors, jasper, etc.
>>>
>>> Comments?
>> 
>> 
>> 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.
> 
> 
> Right, I am aware of that. There isn't that much difference between
> Servlet 2.3
> and Servlet 2.4.  Having a common codebase for both would make addition of
> new non spec related features easier and bug fix patching easier.

There are new methods in interfaces, etc. It won't be easy, I tried that 
( for 2.2/2.3 ).

I agree with your idea of having common code between tomcat4 and tomcat5
( and tomcat3 ) - j-t-c is the best place to do that.

If we agree on a hook mechanism at coyote level - i.e. move auth* and other
hooks to implement Action or similar interface - then a lot of stuff 
can be moved to j-t-c ( or j-t-modules ) and be common. All auth*, mapping,
security - and we already have connectors and Request.

That will also simplify the codebase in j-t-catalina - i.e. the code will
be more focused on implementing the servlet spec.

> There needs to be someplace where new features can be added to the Tocmat
> 4 branch. You have been against adding new features to Tomcat 4 head,
> creating a Tocmat 4.2 branch for developement, and now against making
> j-t-catalina common to both Tomcat 4 & 5.

I think adding features in j-t-c was allways open, and so will be for
a potential j-t-module.

The reason for the negative votes on 4.2 was simple - if you find 3 people 
to vote +1 on 4.2 ( i.e. who are interested in working on it ), then
I don't see any reason not to do it. 

I can hardly find time to work on 5.0 ( and thanks to Bill I don't have to
worry about 3.3 :-), and we have a lot of stuff on the todo list. That
shouldn't stop a 4.2 effort - if it gets at least the minimum 3 committers.
I voted -0, I think Remy will change the vote to -0 as well. 
My -0 means: I don't have time or interest in that, and I would preffer
that the features are done in 5.0 - but if 3 committers have this itch
I won't stop it.



> If this is what you want then perhaps you should propose a VOTE to freeze
> all work on
> Tomcat 4 except for bug fixes.  And I mean all work.  If the community
> votes to do that then I will stop asking and perhaps go review the rules
> for revolutionaries.

I don't see the point of a vote to freeze ( and I think it would be a very 
bad idea ). 

Tomcat4 ( and tomcat33 - I think ) can get new features if enough interest
exists. They do get new features all the time ( at connector level ). 
If any of the features in 5.0 gets 3 +1 for porting it back to 4.x - 
then it should be done. 

If we move auth* and other stuff to couyte level and use Action - more 
featurs will be common across versions.

You can start a revolution and make any changes you want in proposal/, but
you'll still need at least 3 +1 votes to release it (well, you need a 
majority - but again I don't see why anyone would vote -1 ).


Costin 








--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

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

[Costin Manolache]

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 all Servlet specs (starting
> 2.3 & 2.4). Without facade, I don't see how we can achieve that. I would
> prefer having a shared workspace for everything except stuffs related to
> Servlet. Something like:
> 
> o.a.catalina (basic web server stuff)
> o.a.catalina.servletEngine (where the Servlet spec is implemented)

Well, if you move auth* and session to modules and use Action ( or something 
like that ) for hooks - catalina will be the facade and have all the 
Servlet spec implementation.

And all modules should work with any version of tomcat that uses coyote
( i.e. 3.3, 4.0, 4.1, 5.0, etc ). 

If we also move ( or replace ) some of the 3.3 modules ( for example
the mapper, or auth* ) - then 3.3 core will also act as a facade. 

There is no need for a servletEngine package, it's much better to go 
the other way around and move ahead with moving modules out.

We'll need to keep the existing modules in - probably as small wrappers
around the new modules - for backward compatibility. So only new 
modules or existing module implementation will need to move ( and not
all at once ). Probably a "backward-compat" module could be used
for all the code that is deprecated but needs to be around for backward
compat.


> or something like that. That probably what Facade meansMaybe I'm
> dreaming ;-). We should really think of having an extension mechanism
> where module can be added easily. The solution resides probably by
> having a consistent hook mechanism...

Part of the solution, yes. The other part is ( IMO ) JNDI/JMX.

JNDI+JMX will take care of configuring ( you can't do it with JMX alone -
you also need JNDI to locate the objects ). A "module" will be an mbean
that also implements the hook interface.

We can theoretically use JMX alone - without a hook interface and using
invoke() - but that would hurt performance. 

To add a module - you can use any JMX mechanism ( including mlet ) 
_and_ register the module in a catalina:/jmx/OBJECT_NAME jndi.
Tomcat will listen for object notifications - and pick up all
modules and configure them based on the name.

The JNDI/JMX name of each module is very important - as it contains
the position where it must be inserted.

It is quite simple. And it can be implemented without affecting too
much the existing code - it'll be just another module. We'll need to
add some JMX awareness into the code, but it seems the proposal
to require jmx will pass.


Costin






--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [VOTE] Tomcat modules

[Costin Manolache]

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; this does not
> directly depend on the servlet API
> 
> Alternately, using another repository (j-t-modules) is possible, but
> just using a folder looks simpler, as there is an API dependency.
> 
> I propose putting independent modules in j-t-connectors (like eventually
> some of the naming features).
> 
> 
> +1 [X]  
> -1 [ ]
> 

Some comments: while it is a good idea for the new code ( clustering ),
it's probably not worth moving the existing code around. At least 
not until we decide about the Action and auth*. 

Code that is independent of catalina core should be in j-t-connectors or 
j-t-modules. Probably a modules cvs repository would make sense - but
there's no problem with using j-t-connectors.


Costin

 


> 
> Remy




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [VOTE] Tomcat modules

[Costin Manolache]

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
>>>- modules folders: Optional functionality and modules (one example is
>>>clustering), but which depends on the Catalina API; this does not
>>>directly depend on the servlet API
>>>
>>>Alternately, using another repository (j-t-modules) is possible, but
>>>just using a folder looks simpler, as there is an API dependency.
>>>
>>>I propose putting independent modules in j-t-connectors (like eventually
>>>some of the naming features).
>>>
>>>
>>>+1 [X]
>>>-1 [ ]
>>>
>> 
>> 
>> Some comments: while it is a good idea for the new code ( clustering ),
>> it's probably not worth moving the existing code around. At least
>> not until we decide about the Action and auth*.
>> 
>> Code that is independent of catalina core should be in j-t-connectors or
>> j-t-modules. Probably a modules cvs repository would make sense - but
>> there's no problem with using j-t-connectors.
> 
> Ok, so to paraphrase:
> - Catalina core: stays in j-t-catalina/catalina
> - Modules which use the Catalina API: j-t-catalina/modules (or by
> component name, like j-t-catalina/cluster ?)

I think j-t-catalina/cluster is better. 

> - Rest: j-t-c

Sounds good. j-t-module may be better name - but I don't think it's 
worth the effort. Maybe we just extend "connector" to more than
web-server-connector, but external-stuff-connector :-)


> I won't bother moving code around for now then (and you like doing that
> way too much, so I'll let you do it if it's needed ;-) ).

Please do move the cluster and new stuff :-)
I like things to be clear and well organized - but we should first 
have a clear decision on what we want. Cluster seems clear - 
it'll be optional, well separated - and minimal interface changes in
catalina to support it. ( later on we can support other kinds of 
cluster - in addition to javagroup - if we want, in a separate module ).

Costin






--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

build files ( again )

[Costin Manolache]

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 output in j-t5 ( as done "build" ) 
instead of all the different dirs and then copy ?

Another one: I added a flag "build.tomcat.minimal" and
split the compile target in catalina/build.xml. One piece
will build the core stuff, the other will build all 
optional code ( unless minimal is set ). You shouldn't
notice any change. 
We do have to decide what is optional and what is not.

Costin



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

minimal

[Costin Manolache]

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 eventually be
rewritten as a JAAS plugin - and same for the LDAP/JDBC ones. But
I don't have the time, so including both jaas and user.xml in the 
minimal would be a reasonable solution.

- I think the vote on JMX passed ( or will pass). Do we agree on 
requiring JAAS and JNDI ( i.e JDK1.3 or JDK1.2 + jndi.jar + jaas.jar ) ?
That would eliminate some of the conditionals and clean up things.

One major criteria for making things "optional" can be the external
dependencies ( on non-required features ). Another thing that can be 
made "optional" for 5.0 is the deprecated stuff we include only for
backward compatibility.

My current preference for the list of "required":
- JMX
- JAAS
- JNDI
- digester ( and beanutils it needs )

And components to be included in minimal:
- catalina
- coyote
- tomcat-util
- http11/jk2
- all valves/etc that are required for tomcat to operate.
- naming

For optional:
- all components with external deps. 
- all components that are not required to get tomcat running
as a fully-functional servlet container.


Costin




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: minimal

[Costin Manolache]

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 required by
modeler, and also by jasper, so I don't think we can remove it.

Minimal:
- subset of catalina ( non-deprecated interfaces and base impl that is 
required for tomcat to work ).
- coyote
- tomcat-util
- http11/jk2
- all valves/etc that are required for tomcat to operate.
- naming
- jasper ( at least jasper runtime - but probably the whole thing ).

Optional:
- all components with external deps. 
- all components that are not required to get tomcat running
as a fully-functional servlet container.
- admin webapp
- example webapps
- manager ( since JMX can already do most of the stuff that's there )
- slide  ( if we agree to replace our internal webdav with the real thing )
- struts ( required by admin, but also as a separate component ).
- extra taglibs
- doc webapp

This can changes as we go - this is just to get things started.
We can add more stuff in the optional - like other jakarta projects,
log4j, etc. 

The "full" distribution will include minimal+optional.

The goal is to keep "minimal" small :-)
 
Costin



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: minimal

[Costin Manolache]

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 all, and while
> it's not a big hindrance to carry around, I always prefer smaller /
> lighter / simpler when possible.

That won't happen. If you don't use/like - it may be a reason to vote or
ask to include whatever you use. 

At least I refuse to accept "I don't like it so nobody should use it". 


Costin



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: minimal

[Costin Manolache]

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 has to do with the fact that Jasper is no longer a requirement of
> JSR 154 and therefore there is a demand that people have a servlet
> container which only offers what is in JSR 154.
> 
> I want a reference implementation distribution of JSR 154 and only JSR
> 154.


I won't vote against such a distribution. But I won't vote +1 either.

If you can get a majority of tomcat committers ( i.e. at least 3 active 
committers +1 ) to support such a distribution of tomcat - nothing will
stop you.

My proposal is about a minimal JSR154 and 152 distribution, and a full
tomcat that includes all the extra stuff. I would be +1 on including other
jakarta technologies in the full distro, if someone is willing to support
it. 

Costin



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [VOTE] minimal JSR 154 only distribution

[Costin Manolache]

-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 is non-binding.

Costin

Shapira, Yoav wrote:

>>Create a separate minimal JSR 154 only distribution of Tomcat 4.x:
>>
>>+1  [X]
>>0   []
>>-1  []
> 
> Yoav Shapira
> Millennium ChemInformatics






--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [VOTE] minimal JSR 154 only distribution

[Costin Manolache]

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 container.
> 
> According to the Costin-vote-watch, we still need at least one more
> (binding) +1 to authorize a servlet-only release of Tomcat.

Now it needs 2 -1 votes :-)

Bill - let me understand this - do you really want and need this ?


Costin




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [VOTE] minimal JSR 154 only distribution

[Costin Manolache]

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. 

> - If we follow Costin's ideas on bundling, full-tomcat will bundle lots
> of projects; we can also bundle Velocity here (probably on the condition
> that it moves to commons-logging, to harmonize dependencies)

It seems Jon is more interested in a release without jsp then in a release
that includes velocity.  Too bad.

> Personally, I think this is a yes or no vote, so I don't think either
> choice needs a justification.

The "majority" decision works only if enough people vote. 

So far we have:
+1: Jon, Pier, Bill
-0: Costin
-1: Remy

Anyone else ? 

Costin


 



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [VOTE] minimal JSR 154 only distribution

[Costin Manolache]

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 more secure server without JSP.

So you're saying Jon is not proposing that because of his hatred for JSPs,
but because users keep asking him for that ?

Disabling JSPs in a server is quite easy - and has been possible for 
a long time. 

Almost 1/2 of the tomcat community is working on jasper, and is the piece of 
tomcat that has probably the biggest distribution ( if we include Jetty and 
all other servers that use jasper ). And most people in the tomcat 
community are using JSPs. I very much doubt a tomcat without
jasper is best for the users or community. Most developers will test
and work on the distribution that includes jasper. 

Anyway - Jon, Bill and Glenn voted +1 - and so far only Remy is -1. 
Even if I change my vote to -1, the vote would still pass. It doesn't
look like a "consensus", but it is a majority at this moment.


Costin



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [VOTE] minimal JSR 154 only distribution

[Costin Manolache]

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 are required for a veto.

I don't think it would be good for tomcat community if it will pass with 3 
+1 votes, 2 -1 votes and one -0.

I hope that more tomcat committers will send at least a +0 or -0, and even 
better +1 or -1. There is no need to get into too much debate - just yes 
and no would help. 



Costin



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [VOTE] minimal JSR 154 only distribution

[Costin Manolache]

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.1 as we did) to
> administer the server, without the need to use the admin webapp.

Now - this is not nice !

I don't know why my proposal for a minimal tomcat that includes jsr152 and
jsr154 shouldn't be allowed. 

Ok, I'll make a VOTE and try to gather the votes - hopefully I'll
get at least 3 +1 votes ( and you'll at least -0 it :-).

Costin



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

[VOTE] Minimal tomcat ( JSR154 + JSR152 )

[Costin Manolache]

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 )
- 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 required by
modeler, and also by jasper, so I don't think we can remove it.

Tomcat:
- subset of catalina ( non-deprecated interfaces and base impl that is 
required for tomcat to work ).
- coyote
- tomcat-util
- http11/jk2
- all valves/etc that are required for tomcat to operate.
- naming
- jasper ( at least jasper runtime - but probably the whole thing ).

Votes:
[ ] +1 I like the idea, I might help
[ ] -1 I don't like the idea, I won't help.


Costin



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [VOTE] minimal JSR 154 only distribution

[Costin Manolache]

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 and very closed minded. Who are
> you to decide what our users may or may not like? In the end, if things
> don't work out, then fine at least we learned something and we can move on
> to the next thing.

No Jon - my vote wasn't based on your biasses about jasper, but on the 
biasses of many members of the tomcat community. 

5.0 was supposed to be the release we make togheter, as a united community 
based on consensus. 

There is one jakarta project where "experimentation" without consensus
was the operating mode - and I certainly don't like the result. You may
remember about the division of the tomcat community on 3.3/4.0 - and
I don't think 69K of code ( jasper runtime ) would justify another 
division. 


> What do we really have to loose here?

Consensus. 

Costin



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

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

[Costin Manolache]

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 removed from the list

I think this is at least unfair.

I started the discussion on "minimal" tomcat before Jon's vote. I was 
trying to get a consensus and opinions to shape the proposal. Jon
jumped in with the vote. I don't think "who proposes the vote first
wins" is the best solution, I don't think we are even talking about the
same thing ( Jon wants a JSR154-only, I'm proposing a minimal tomcat ).


I don't see why a vote on Jon's proposal would affect my proposal 
( or any future vote ). 


> As I said, I'd like to limit to 2 maximum the amount of Tomcat binary
> distributions (I think two is too much, actually, but still is
> acceptable).

Then make a proposal that "maximum 2 tomcat binary distribution should be 
allowed". But even in this case - I think I am allowed to propose that 
one of the distributions ( the small one ) includes jasper runtime and is 
not called "jsr154 only". Even if Jon's vote is passing.

If your -1 vote on "minimal tomcat" ( that includes jasper ) is based 
on concerns that we'll have too many distributions - I agree it's
a valid reason, and I know you don't need a reason to vote -1. 

I have no problem with a vote on "minimal tomcat" to not include
jasper compiler ( or even jasper runtime ) - if this gets a majority
of votes than it can happen. The reverse is a bit more difficult - 
i.e. we can't include jasper in a "JSR154 only" ( as Jon proposed )

Costin



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [VOTE] minimal JSR 154 only distribution

[Costin Manolache]

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.e. they should be included in the
server loader - quite easy ).

The option I preffer for that is to use JMX. Each "pluggin" will be
an mbean that is loaded using either an mlet-like or via a deployment
descriptor ( server/webapps is also fine - using webapps as plugin
units ). JMX notifications can be easily used to have the plugin 
loading/unloading very flexible.


Costin   



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [VOTE] minimal JSR 154 only distribution

[Costin Manolache]

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 these people? I don't think so.

No, I speak for myself. I like and use jasper - and I think the tomcat
official releases should include both tomcat and jasper. 
Just like you don't speak for the users.

>> 5.0 was supposed to be the release we make togheter, as a united
>> community based on consensus.
> 
> My proposal has nothing to do with that.

2 -1 and one -0 vote versus 3 +1 votes doesn't look like a consensus.

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 ).

I heard the argument about "user choice" and "freedom to experiment" on 
avalon ( to justify "everyone releasing his own container" ). I think
their current attempt to have a single product is a move in the right
direction. 


>> Consensus.
> 
> What consensus? This has nothing to do with which container to use. It has
> everything to do with giving people options.

Is Apache http having n different releases with all the possible 
combinations of modules ( to give users choice ) ? They include all the
modules in the httpd repository ( some disabled by default ).

That also goes against my proposal for minimal tomcat as well - and supports
Remy's argument that we should have one release. 

Costin



--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: [VOTE] minimal JSR 154 only distribution

[Costin Manolache]

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 don't like is not "real".
So far you qualified as invalid every reason that everyone mentioned.

> You are so funny! How quickly you seem to change your mind. Go back and

I have a feeling almost everyone "changed his mind" in some issues
in the last 2 years. You seem to be one exception, and I don't know
if this is a good thing :-)

>> Is Apache http having n different releases with all the possible
>> combinations of modules ( to give users choice ) ? They include all the
>> modules in the httpd repository ( some disabled by default ).
> 
> They don't distribute PHP.
> 
> So, why should we distribute JSP?

PHP is not developed by the httpd community. ( but php.apache.org ).
Jasper is developed by the tomcat community - same mailing list,
same avail list. 

Anyway - as long as Bill is supporting the no-jasper release, 
I won't change my vote to -1 ( but keep it -0). I haven't contributed that 
much to jasper - and it's up to jasper people to decide what they
feel ( by voting +1 or -1 ). 


Costin




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

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

[Costin Manolache]

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 features:
>> 
>> Libs:
>> - JMX
>> - JAAS
>> - JNDI
>> - digester ( and beanutils, collections it needs ).
>> - modeler
>> - ant ( used for startup and automation of some tasks )
>> - 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 required by
>> modeler, and also by jasper, so I don't think we can remove it.
>> 
>> Tomcat:
>> - subset of catalina ( non-deprecated interfaces and base impl that is
>> required for tomcat to work ).
>> - coyote
>> - tomcat-util
>> - http11/jk2
>> - all valves/etc that are required for tomcat to operate.
>> - naming
>> - jasper ( at least jasper runtime - but probably the whole thing ).
>> 
>> Votes:
>> [ ] +1 I like the idea, I might help
>> [ ] -1 I don't like the idea, I won't help.
> 
> 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 point to the proposal you made on tomcat-dev and the vote
results to your proposal ? 

Are you saying you made such a proposal and it was voted down ? 

Or it was approved and I didn't allowed you to call it whatever
tomcat-dev decided ?

My comment was in the context of a product named "Tomcat-high-availability"
that wasn't voted by the tomcat-dev. It doesn't matter if it is
a revolution or minimal or whatever it does - it shouldn't be named 
"tomcat-anything" without ASF or tomcat-dev permission. 

If this proposal doesn't pass I won't do it somewhere else and call it 
tomcat-minimal. 



Costin

> 
> I _love_ fairness and justice in this world... What-EVER!
> 
> Pier




--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

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

[Costin Manolache]

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 point to the proposal you made on tomcat-dev and the vote
>> results to your proposal ?
>> 
>> Are you saying you made such a proposal and it was voted down ?
>> 
>> Or it was approved and I didn't allowed you to call it whatever
>> tomcat-dev decided ?
>> 
>> My comment was in the context of a product named
>> "Tomcat-high-availability" that wasn't voted by the tomcat-dev. It
>> doesn't matter if it is a revolution or minimal or whatever it does - it
>> shouldn't be named "tomcat-anything" without ASF or tomcat-dev
>> permission.
>> 
>> If this proposal doesn't pass I won't do it somewhere else and call it
>> tomcat-minimal.
> 
> You're better than me in scavanging through EyeBrowse... :-)

It's hard to find something that doesn't exist. 

I hate the practice of using old postings as arguments in most cases - 
it's normal for people to change their minds. 

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 on tomcat-dev. 


Costin



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [VOTE] minimal JSR 154 only distribution

[Costin Manolache]

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 posted after the fix is done. 

The list is created - and will hopefully be used next time a security 
problem is found.

> Ehemm... With 24 pages of vulnerability notes? Ha.. Hahaha Hahahaha!
> :-)

Again ?

There are 24 results - not 24 pages of results. And if you go down the page 
- many are not in tomcat.

Try the same thing for apache.


Yes - any code may have vulnerabilities, and the more code you have, the
more bugs you'll have. We can only do our best so that our code has 
fewer bugs - but that shouldn't stop us from distributing the code we 
write ( i.e. tomcat and jasper ). 


Costin



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [VOTE] minimal JSR 154 only distribution

[Costin Manolache]

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 3 "config" - minimal, 
default and all. 

One benefit is consistency. They do actually have 3-4 binary
distributions - with the various servlet containers they support,
but that's mostly because the integration of the container is
not that integrated ( at least for tomcat ).

I like very much Henri's proposal of fully-modular tomcat. 

The "minimal" would become JMX ( and modeler ). Then 
various "profiles" can be configured - by either a config file
or placing some jars in a dir. You could have a JK-only
( for example jk + Axis - as a soap server ), or servlet only,
or any other combination - all based on a simple config file.

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.

I think the real argument against my "minimal" proposal is the
current lack of the modular "add-on" mechanism. We almost have it,
but something more is needed.

There is one short-term solution - port the "modules" from 3.3 
( basically take the server/webapps/*/WEB-INF/lib and add this
to the server loader, plus the config file ). Long term we 
can use JMX mlets to load the modules.

We'll still have a single release of tomcat ( that doesn't 
mean we can't have more packages ). A single tomcat is quite
important IMO - at least for our community.


> 
> All we need is a more modular approach of TC 5, which should
> be able to load modules (JMX/JASPER) if available in classpath.
> 
> If you take a look at how decent packaging tools like rpm/debian
> works, they are able to install a PRIMARY PACKAGE and OPTIONAL
> PACKAGES. For your purpose, scarab for example, you could only
> stay with the bare minimum TC 5, without installing the rest
> of TC 5.
> 
> What about ?

+1 


Costin



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [VOTE] New committer: Filip Hanik

[Costin Manolache]

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). Filip is one of the authors of JavaGroups, the Java based
> clustering framework used in the new Tomcat clustering code.

+1



Costin



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

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

[Costin Manolache]

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 on tomcat-dev.
> 
> I swear that _LOVE_ my mates... My friend Tonia, who's apparently better
> than me in getting out old posts, actually _FOUND_ it! :-) Thank you :-)
> And for your own viewing pleasure, that's it...

Did your friend Tonia also found the 3 +1 votes ? 

Can someone explain to Pier that:
1. revolution can't be named tomcat-whatever
2. tomcat releases need a majority vote and at least 3 +1 votes.

I didn't say you can't name your stuff "jerry" - or anything else. 
And my comment on naming it "tomcat-high-availability" was on the code
that you done outside of tomcat. Do you still think it was ok to
do so ? You can check with the board or whoever else in apache about
that - or try to release an "apache httpd - high-availability". 

There are many proposals for "minimal" tomcat - and one of the main 
divergences between 3.3 and 4.0 was the number of features. ( and 
it turned both position had positive and negative aspects - 4.0 features
attracted probably more users than 3.3 minimality ). You may remember 
the <1M tomcat and the discussion about supporting J2ME with 3.3.
So don't tell me you invented the minimal tomcat 4 months ago.

When working in a community the behavior is quite important
and does have an effect on others and yourself.( that's true for Jon - and 
for myself :-) 

One thing we learned is that a proposal needs more than some technical
benefits - it also need buy-in from the community. That's how Apache
works - if you don't know that.

Costin


> 
> (OK, it didn't have the [PROPOSAL] tag, but the  wording was in there,
> c'mon, be flexible! :-)
> 
> Yes, ok, that's so true... I also vented the idea that _MAYBE_ (but maybe)
> someone could have reimplemented the Standard* classes, but WHAT THE HELL?
> 
> All I said I wanted was (quote myself) "more or less what Jon does for
> Scarab"...
> 
> I said that IN JUNE... JUNE for damn sake... And somewhere along this
> thread when it after degenerated in the usual flame war that always
> happens when something needs to be done you said "If possible, please also
> change the name - unless ASF gives you permission to use tomcat name in
> your product."
> 
> And now _I_ am the idiot who makes false statements... Damn... I _knew_ I
> had a reason to be upset...
> 
> Tonia, thanks, I owe you two favours for this one (next time I'm in the
> US!)
> 
> Pier
> 
>  Original Message 
> Subject: Re: 5.0 proposal
> Date: Mon, 24 Jun 2002 21:49:51 +0100
> From: Pier Fumagalli <[EMAIL PROTECTED]>
> Reply-To: "Tomcat Developers List" <[EMAIL PROTECTED]>
> To: Tomcat Developers List <[EMAIL PROTECTED]>
> 
> [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> 
>  > On Mon, 24 Jun 2002, Pier Fumagalli wrote:
>  >
>>> That's why counts where not right on my side of the border... I don't
>>> recall vetoing the proposal... I just complained vehemently that I'd
>>> prefer to see 4.0 out of the door and stable rather than a 4.1 and a
>>> 5.0...
>  >
>> 4.0 is out of door - the release happened long ago. So did 4.0.1...
>> 4.0.4.
>> 
>> 4.1 is getting close - and it should be more stable and better than
>> 4.0.4. And 5.0 should be more stable and better than 4.1 and 3.3.
>> 
>> And 6.0 will probably be better than 5.0.
>> 
>> If you are interested in maintaining and improving 4.0.4 - just volunteer
>> as release manager for the branch, you have my +1 on it.
> 
> I can't be a RM for 4.0.4 because I would simply remove 70% of the code,
> and kiddies would start crying their butts off because they don't have the
> manager application, or JSP support :)
> 
> But if anyone is interested I'd like to explore the opportunity of a
> Tomcat-HA (high-availability or hard-edition), based on 4.0 without the
> "crap" in there, and straightening out the request-response model...
> 
> Simply, take the Catalina classes, and remove piles of useless stuff (more
> or less what Jon does for Scarab, but to a greater degree, maybe even
> reimplementing some of the Standard* classes).
> 
>  >> I can't veto as I don't really care how you want to spend your
> evenings and
>  >> stuff...
>  >
>  > I don't think you can 'veto' a long term plan or release. AFAIK it's
>  > a majority vote.
> 
> Veto in terms of -1ing it.
> 
>  Pier




--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: [VOTE] minimal JSR 154 only distribution

[Costin Manolache]

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 be one "profile" in the normal distribution. Remy's arguments
are also very valid.

I think we can focus on 4 profiles:
- JSR154 only
- minimal ( JSR154 + JSR152 )
- default ( the current set of features )
- all 

The main technical problem is the class loader - we probably need
to place most jars in a "repository" - but not in the loader - and use the 
manifest or config files to pick what we need. Again, the jmx
model may help us. ( jboss solution is to just copy the files
- which does makes sense in a way )

Jon - would that be reasonable middle-ground for you ? It gives you
a JSR154-only profile, included in the "main" distribution. The downside
is that jasper will still be included ( disabled and invisible in your
profile - visible in all others ). 


Costin





--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

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

[Costin Manolache]

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 addition to that is "Tomcat4 lite", "Tomcat4 all"
>> "Tomcat5 lite" disaster, don't go there.
>> 
>> I want one distribution with --enable --disable for source compilation
>> and if I choose binary I can edit the config files (server.xml or
>> whatever) to remove the options I don't need. Exactly like httpd (sort
>> of)...
> 
> I really cannot believe I could agree with you on something ;-)

Don't know what you two disagree on - but I think this is a very 
good point.

Consider my "minimal tomcat distribution" dead - for now. 

I'm not sure about "one distribution with --enable and --disable",
but I think one distribution with different profiles ( and the 
option to create a profile that includes what you need and nothing
else ) is the best choice.

And it seems JMX plus some class loader magic plus some config 
can do that.

Costin 



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [VOTE] minimal JSR 154 only distribution

[Costin Manolache]

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 there, then it isn't a (repeat) 'minimal JSR 154 only
> distribution.'

It'll be a JSR154 profile.


And a Tomcat distribution.

It's up to Sun to release JSR152 or JSR154 or whatever else - we develop
tomcat. 


Costin



--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

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

[Costin Manolache]

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 this one I stoped
at the first phrase ( "a tree of downloads" ).

What Remy and Costin are agreeing on is one tomcat release that includes
multiple profiles - so people can run "jsr154" or "minimal" or "default"
or "all".  

Even if I would have passed this - the Java Server Faces part is clearly the
end of your message for me ( and should have been the end of the 
conversation ). 

I don't know why you have the impression that I have to bother reading
your messages. 


Costin


> 
> -jon
> 
> -- Forwarded Message
> From: Jon Scott Stevens <[EMAIL PROTECTED]>
> Reply-To: "Tomcat Developers List" <[EMAIL PROTECTED]>
> Date: Mon, 09 Dec 2002 01:16:20 -0800
> To: tomcat-dev <[EMAIL PROTECTED]>
> Subject: Re: [VOTE] minimal JSR 154 only distribution
> 
> What I would love to see is a tree of downloads where each one gains more
> and more features (it is additive). Such as:
> 
>  JSR-154 Implementation
> /  \
>  Jasper  Velocity
>   /   \ \
>  Admin Tool (JMX) Java Server Feces   Scarab
> 
> That way, you only need to download what you need. Bundles are easily
> created by simply picking off the branch of the tree that you want. If you
> want the "Tomcat" distribution with web based administration abilities,
> then you grab it at the "Admin Tool" level and so on. We can even build an
> ant based system which is able to help us manage the selection of
> components to include in the distribution. This would be similar to the
> way that we currently have jar repositories and dependencies, but on an
> application level. "Click here to install Jasper, Struts, etc."
> 
> Not only does this provide our users the ability to simply get what they
> need (and add it after the fact if they don't have it), it helps us focus
> on providing a pluggable system which is separate from the other systems
> (ie: clean dependencies).
> 
> I personally think that this is a much cleaner way of providing
> distributions because it does not require people to learn or deal with
> things they do not care about. Options are a good thing. Let's not limit
> ourselves.
> 
> 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 and very closed minded. Who are
> you to decide what our users may or may not like? In the end, if things
> don't work out, then fine at least we learned something and we can move on
> to the next thing.
> 
> What do we really have to loose here?
> 
> -jon
> 




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [VOTE] minimal JSR 154 only distribution

[Costin Manolache]

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 want to. And I don't
think including it in the minimal is a good idea either ( if it 
can run without it, then it shouldn't be in "minimal" ).

The vote was about creating a separate distribution of tomcat 
with certain content. You can vote +1 or -1 if you want to
influence the result, or -0 or +0 if you don't want
to change the result, but still want to say you agree or not.

If you had a bad dream about it last night or you feel it will
confuse users or whatever - it doesn't matter, this is 
not a veto but a majority decision on a proposal.  

And a +1 doesn't mean ( in this case ) that you'll have to help.
It has this meaning ( in tomcat at least ) only on the final
vote to release. A +1 only means that you feel it is a good idea
and will make tomcat better.

Has everyone lost interest in tomcat and doesn't care what happens ?
This open source stuff and majority vote and so on doesn't work
if people don't participate. I can understand that we all have little
time - but at least read the proposals ( marked with [VOTE] or [PROPOSAL]
so you can set your mailer and ignore everything else ) and send your
opinion. A simple +-1, +-0 is enough and shouldn't consume that much time.

One concern I had about Jon's proposal is the tensions it may create
among committers, and especially those that work or use jasper. If their
answer is "we don't give a damn about tomcat releases" - then I'm wrong. My 
other concern is that users will be confused if they have N downloads to 
choose from, and our efforts on documenting and testing will be diluted if
we have N releases each with 3 people working on them. 


Costin


Jeanfrancois Arcand wrote:

> OK, seems I don't have any supports to stay with my -1 (seems nobody
> care about the AdminTool argument :-)). So I will change my mind and
> vote 0.
> 
> -- Jeanfrancois
> 
> Pier Fumagalli wrote:
> 
>>On 10/12/02 0:30 "Jeanfrancois Arcand" <[EMAIL PROTECTED]> wrote:
>>
>>  
>>
Now, don't tell me that ALL that collection of cruft doesn't have a
bug... It's just that we are lucky and noone found them yet (given
enough eyes... Linus says)...

  

>>>I never say that and I will never says that. But I least I have try
>>>during the Security Audit to fix some of the obvious one. Still Tomcat
>>>is probably not enough secure (and will never be).  My point is if you
>>>are aware of such obvious one, then let me know and I will fix them.
>>>
>>>
>>
>>You said (quote) "Jasper/AdminTool/etc. are secure"... That's a pretty
>>bold statement.
>>
>>>From my experience, security audits and stuff are all right, until
>>>someone
>>doesn't call up at 3 AM saying "the server is down because of a DOS"...
>>Nah, I don't like being woken up in the middle of the night...
>>
>>  
>>
>>>But I don't think Tomcat is more secure without JSP I know, I know,
>>>what I think you don't care :-)
>>>
>>>
>>
>>The bible (for us Sun customers, _your_ customers):
>>
>>
>>
>>  
>>
>>>"Solaris Operating Environment Minimization for Security: A Simple,
>>>Reproducible and Secure Application Installation Methodology
>>>- Updated for the Solaris 8 Operating Environment"
>>>- November 2000
>>>- by Alex Noordergraaf
>>>
>>>Discusses the process of minimizing an installation of the Solaris
>>>Operating Environment. Mimimization is the process of removing all
>>>unnecessary components and services from the Solaris software to reduce
>>>system vulnerabilities. Also introduces a simple technique for
>>>replicating these types of installations across a large number of
>>>systems.
>>>
>>>
>>
>>_YOUR_ security folks tought me that... Go and talk to them, they're down
>>in SCA-7 if I'm not wrong... Paranoia is an irreversible process for us on
>>the line-of-fire.
>>
>>  
>>
To sum up: rule of the thumb #3, less code, less bugs (you folks from
Sun preach that all over your Solaris Blueprints stuff, I learnt it when
your employer was paying my salary).

  

>>>Wow, didn't know that... I've missed the chance to work with you :-)
>>>
>>>
>>
>>Don't worry, you would have _hated_ working with me (and proudly keeping
>>up my record of being the most hated freak on the planet).
>>
>>  
>>
>>>I should studies my Tomcat history and learn who is doing what, what
>>>biases he/she have, and then vote appropriatly.
>>>
>>>
>>
>>Oh, no, I got paranoid after I left Sun and started working on the other
>>side of the barricade... Trying to use in production what I was coding
>>earlier... :-)
>>
>>  
>>
So, please, don¹t come up on a mailing list saying "that is secure",
just say that "noone has found a bug yet

Re: [VOTE] minimal JSR 154 only distribution

[Costin Manolache]

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
>>>precompile the admintool ( and we should do it anyway ) and
>>>run it in the JSR154-only container - if you want to.
>>>
>>>
>>
>>I thought that you need Jasper in order to run JSP's (compiled or not).
>>
> Yes, you need them since even if the classes are compiled, they are
> still having reference to org.apache.jasper.*

No, you don't.

You can just copy jasper-runtime.jar in WEB-INF/lib and you're done.

At least that used to work in 3.3 - I don't see any reason it'll
not work ( except maybe some bugs ).


Costin



--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: [VOTE] minimal JSR 154 only distribution

[Costin Manolache]

Jeanfrancois Arcand wrote:

> 
> 
> Costin Manolache wrote:
> 
>>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
>>>>>precompile the admintool ( and we should do it anyway ) and
>>>>>run it in the JSR154-only container - if you want to.
>>>>>   
>>>>>
>>>>>
>>>>>
>>>>I thought that you need Jasper in order to run JSP's (compiled or not).
>>>>
>>>>  
>>>>
>>>Yes, you need them since even if the classes are compiled, they are
>>>still having reference to org.apache.jasper.*
>>>
>>>
>>
>>No, you don't.
>>
>>You can just copy jasper-runtime.jar in WEB-INF/lib and you're done.
>>
>>At least that used to work in 3.3 - I don't see any reason it'll
>>not work ( except maybe some bugs ).
>>
> Is Jasper = Runtime + Compiler (jasper-runtime.jar +
> jasper-compiler.jar)? I was under the impression that when we discuss
> about removing Jasper, it was both part. Not only the compiler
> partIf it's only the compiler part, then yes you can still run the
> Admin Tool.

Yes, jasper=runtime + compiler.

Last time I checked ( and I know no particular reason why this wouldn't
work now ) the runtime can be included in the container - or it
can be included in WEB-INF/lib for each precompiled app.

Jasper doesn't particulary care where the runtime is located. 

A JSP is translated to a servlet. Jasper runtime is just one library
that the generated servlet uses. 

You _can_ ( at least with the older jasper - and probably you can
easily get the current one to work, if it doesn't already ) run
jasper generated ( pre-compiled ) servlets with any servlet container ( 
weblogic, whatever ) - as long as the container doesn't include
an older version of jasper ( that would mess the class loader).

The real issue with Jon's proposal is not the fact that admin ( or 
any jsp ) won't run in the JSR154 distribution. It's more an issue 
of attitude. 

As a note - my proposal for minimal container ( that I consider now
dead - I think the multi-profile solution is much better ) did not
include the jasper compiler either. You don't need jasper compiler
or javac on an embeded or production server to run JSPs. 

By including the runtime I didn't actually meant the current runtime,
which could be easily included in the webapp by the precompiler, but
whatever tomcat-specific optimizations we'll do ( I made a number
of proposals about using the lower-level tomcat constructs for
output, etc - didn't get too much enthusiasm, but I still think
that it is the right way and can make JSPs much faster than the
equivalent servlets ). Assuming such optimizations are done - they'll
have to be included in the minimal container. 

Since right now there's no tomcat-specific optimization in jasper - 
my minimal proposal would be almost the same as the JSR154-only
container, however it keeps the door open ( and includes the runtime
as a matter of convenience ).

Costin 











--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

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

[Costin Manolache]

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, if you don't mind.

I added it in my previous patch, it wasn't there before - and it broke 
something. 

( I added it because the path looked strange on windows - with a \/file.java 
in it, but it works fine without getCanonicalPath and it seems it doesn't 
if getCP is added )

Costin



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [VOTE] minimal JSR 154 only distribution

[Costin Manolache]

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 similar to the
> "download" target.
> 
> Given the separation between 154 and 152, I'm sticking with my vote for
> the "core" release to be 154-only (and, I'm consistent, since minimality
> is one of the features that I like in 3.3).

I don't know about what consensus we reached :-)

Bill - the "minimal" profile ( my original proposal ) is almost the same
thing as the 154-only. The big difference is that it keeps the door open
to add jasper-related runtime. 

Having a small download with the minimal profile that download other
components is acceptable - but the main release should be the full
( minimal + various modules and profiles ). I don't think too many 
people like their production servers to go and download stuff :-)
But this is a separate issue - and I have no problem with posting
more binaries ( Remy already does the lite/full )

The question is - should we do "154-only, no 152 allowed" or just "minimal". 
And should we have 2 ( or N ? ) releases, or one release with multiple
binary packages. 

I do like the idea of a repository of modules and experimenting with
downloading ( or updating ) stuff. Jboss allows runtime-changes to almost
any component ( without restarting ), and this is something I allways
wanted to get ( the 3.3 modules kind-of support this feature or 
are very close ). But as part as a common release.

Costin



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [VOTE] minimal JSR 154 only distribution

[Costin Manolache]

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 counted 3 non-binding +1s.
> 
> The active committers have mostly all voted:  Craig is semi-off tomcat
> (but does great work on tomcat-user :), Amy has always only ever voted on
> the projects she cares about, Kinman & Jan have been blown off by the rest
> of us for months, so what do they care?
> 
> AFAIK, the vote is wrapped up.

I think waiting until Friday is not too much ( one week voting period is 
reasonable ). And since this vote didn't have too much prior discussion
and clarifications - a new vote may also be a good idea, clarifying the
various aspects.

I'm willing to change my vote to +1 if the proposal is changed to "minimal 
tomcat distribution" ( i.e. don't explicitely exclude JSP ). That may
mean only jasper-runtime.jar, or not even that ( if placing it in
WEB-INF still works ). 

Changing the name to "minimal" also keeps the door open to 
have only JMX+classloader+ant+download scripts, and have catalina.jar
( i.e. JSR154 ) downloaded. Or some other servlet implementation can
be selected  - so running the 4.1 .jar will be possible for a while, and 
updates to the servlet impl. will be consistent with updates to all other
components

IMO a lot has been discussed, we have more options and informations - 
so a new vote may be the best idea and may yield real consensus.
I think we are all very close in position and we all agree on 
"minimal". I disagree on binding "minimal" to JSR154 ( in both
directions - it is perfectly reasonable to add jasper-runtime 
or to remove the servlet container ).


To increase the chance of a new vote with more consensus - I'm
changing my vote to -1 on "minimal JSR-154-only".


Costin  



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [VOTE] minimal JSR 154 only distribution

[Costin Manolache]

[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 newb here, but it seems to me the fundamental issue
> is how difficult is it to add or subtract bits and pieces.
> 
> If it was trivial (i.e. a simple unzipping or untarring)
> then the best thing to offer for download would be:
> 1 a minimal
> 2. a 'maximal'
> 
> and all the modules in between for people to roll their own.

I think we all agree on such a model ( I haven't heard any opinion 
against such thing ). This is not an issue we disagree on.

JSR154-only implies a distribution with a very specific set of features.
That's not minimal and not the same thing with the discussion about 
modules ( even if it can support added modules ).

As an example - jboss minimal doesn't include any service
at all, just JMX and the hot deployment support. 


Costin





--
To unsubscribe, e-mail:   
For additional commands, e-mail: