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]

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: 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 @@
  property name=tomcat-util.build value=${tomcat.build} /
  property name=tomcat-util.lib value=${tomcat.build}/server/lib /
   /ant
  +
 /target
   
 target name=build-tomcatjk unless=tomcatjk.build.notrequired 
  @@ -658,7 +659,7 @@

   !-- antcall target=build-commons-modeler / --
   !-- antcall target=build-commons-daemon  / --
   
  -  	antcall target=downloadgz

  +antcall target=downloadgz
 param name=sourcefile value=${commons-collections-src.loc}/
 param name=destfile value=${tomcat-dbcp.jar} /
   /antcall
  @@ -1167,6 +1168,90 @@
   /ant
 /target
   
  +  !-- === Single-jar tomcat === --
  +   target name=prepare-runtime-once 
  + description=Do once before single jar tomcat

  +mkdir dir=runtime/deps /
  +mkdir dir=runtime/classes /
  +unjar dest=runtime/deps 
src=${base.path}/servlet-api-2.4/lib/servlet-api.jar /
  +!-- unjar dest=runtime/deps 
src=${base.path}/commons-logging-1.0.4/commons-logging.jar/ --
  +unjar dest=runtime/deps 
src=${base.path}/commons-modeler-1.1/commons-modeler.jar/
  +unjar dest=runtime/deps 
src=${base.path}/jsp-api-2.0/lib/jsp-api.jar/
  +   /target
  +
  +
  +   target name=compile-runtime 
  +   description=Build single jar tomcat
  +  
  +  javac destdir=runtime/classes deprecation=false debug=false  

  +!-- classpath 
path=${base.path}/commons-beanutils-1.6.1/commons-beanutils.jar/ --
  +!-- classpath 
path=${base.path}/commons-logging-1.0.4/commons-logging.jar/ --
  +classpath 
path=${base.path}/commons-modeler-1.1/commons-modeler.jar/
  +classpath path=${base.path}/jsp-api-2.0/lib/jsp-api.jar/
  +classpath 
path=${base.path}/servlet-api-2.4/lib/servlet-api.jar/
  +classpath path=${base.path}/jmxri-1.2.1.jar/
  +
  +src
  +pathelement path=${jtc.home}/util/java/  
  +pathelement path=${jtc.home}/mini/java /

  +!-- pathelement path=${jtc.home}/naming/src/ --
  +pathelement path=${jtc.home}/coyote/src/java/
  +pathelement path=${jtc.home}/http11/src/java/
  +pathelement path=${catalina.home}/catalina/src/share/
  +/src
  +exclude name=org/apache/naming/*.java/
  +exclude name=org/apache/naming/ant/**/
  +exclude name=org/apache/tomcat/util/net/puretls/**/
  +exclude 
name=org/apache/tomcat/util/net/jsse/JSSE15SocketFactory.java/
  +exclude 
name=org/apache/tomcat/util/net/jsse/JSSE15Factory.java/
  +exclude name=org/apache/tomcat/util/net/AprEndpoint.java/
  +exclude name=org/apache/coyote/tomcat3/**/
  +exclude name=org/apache/coyote/tomcat4/**/
  +exclude name=org/apache/coyote/memory/**/
  +exclude name=org/apache/coyote/standalone/**/
  +exclude 
name=org/apache/coyote/http11/Http11AprProcessor.java/
  +exclude name=org/apache/coyote/http11/Http11AprProtocol.java/
  +exclude 
name=org/apache/coyote/http11/InternalAprInputBuffer.java/
  +exclude 
name=org/apache/coyote/http11/InternalAprOutputBuffer.java/
  +exclude name=**/CatalinaLaunchFilter.java/
  +exclude name=**/MailSessionFactory.java/
  +exclude name=**/SendMailFactory.java/
  +exclude name=**/SemaphoreValve.java/
  +exclude name=org/apache/catalina/ant/**/
  +exclude name=org/apache/catalina/ssi/**/
  +exclude 
name=org/apache/catalina/loader/CatalinaModuleListener.java/
  +/javac
  +
  +copy todir=runtime/classes 
  +fileset dir=${jtc.home}/util/java includes=**/*.properties 
**/*.xml/
  +fileset dir=${jtc.home}/naming/src includes=**/*.properties 
**/*.xml/
  +fileset dir=${jtc.home}/coyote/src/java includes=**/*.properties 
**/*.xml 
  +  exclude name=org/apache/coyote/tomcat4/**/
  +/fileset
  +fileset 

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: [Vote] (was Re: Top Level Project? Time for Top Level Lists?)

[Costin Manolache]

William A. Rowe, Jr. wrote:

Costin Manolache wrote:


Remy Maucherat wrote:
I doubt that filling the inbox with the bug reports or commit messages 
will make anyone care more ( or make anyone read them when they don't 
want to ) :-) It seems most people use filters anyway, and those who 
don't ( like using gmane or a web-based interface ) just suffer the 
noise, but still ignore the bugs/commits they don't care about.


I would really appreciate splitting them - I try to read tomcat-dev as 
much as possible, but web-based interfaces ( like gmane's RSS view or 
the html viewer ) are almost useless due to the noise, and filtering 
the news is not easy either.



Well, my first point was that, as a TLP, the lists should become
@tomcat.apache.org; whatever they become.

But AFA different lists are concerned, is it worth a vote?  I'm going
to abstain, as I'm not on the PMC (IIRC).  But here it is, go ahead and
cast an opinion...

Bugs
 [ ]  forward to [EMAIL PROTECTED]
 [X]  forward to [EMAIL PROTECTED]

Commits
  [ ]  forward to [EMAIL PROTECTED]
  [X]  forward to [EMAIL PROTECTED]

Vote away :)



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

Re: Small refactoring in Http11Processor

[Costin Manolache]

Mark Thomas wrote:

Mladen Turk wrote:


Costin Manolache wrote:


Hi,

Also, I would like to add another directory under j-t-c, with a build 
file and few classes for a 'mini' experiment - i.e. using the 
connector standalone, as a minimal http server, and also a target to 
build a minimal servlet container as a single self-contained jar. We 
don't have a sandbox, and j-t-c seems closest to that :-)




Hi Costin,
Nice to have you back :)

Anyhow, seems that the SVN transition is in progress.
If the time is acceptable, perhaps you can postpone that, and simply
create a branch in SVN.
I'm not sure when the code will be moved to SVN,
perhaps Mark will know.



I am about to kick of TC3 and TC4. Once that is complete (few days?) 
I'll do the last batch which will be TC5, Connectors and Jasper.


Mark


Is there any plan to do a bit of cleanup ? Maybe move some of the dead 
code in connectors (mod_webap, jk2, etc ) to a new repo ? And maybe add 
a new 'sandbox' repository ?


Costin


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

Re: How strongly Tomcat 5.5.x will be committed to JDK 1.4.x in future..

[Costin Manolache]

The current servlet spec doesn't requires J2SE 5.0 - only the next one ( 
another stupid forced, unjustified transition IMO ).


I would assume JDK1.4 will be supported for a while, as long as the 
current version of the servlet spec is in use.
Tomcat3.3, which supports JDK1.1, has been maintained for quite a while 
after switching to JDK1.3 and then JDK1.4. I don't see how anyone who 
has been around for past upgrades could expect a mass migration to the 
new servlet spec and JDK1.5.



Costin

Yoav Shapira wrote:

Hi,
Tomcat 5.5 will always allow JDK 1.4.  Tomcat 6.0, as required by the J2EE 5
specifications, will require J2SE 5.0.  I repeat, for emphasis, that this is
required by the J2EE 5 Specification itself, which Tomcat 6.0 will support: it
is not our decision to drop support for JDK 1.4.

Yoav

--- Girish Vasvani [EMAIL PROTECTED] wrote:



Hi,

We'r puzzled between tomcat 5.0.x and 5.5.x.
Due to our product restrictions we can't use JDK 1.5. Looked at jakarta web
site, it seems that using tomcat 5.5.x seriese compated to 5.0.x is a good
idea and recommended.

Before committing our product to tomcat 5.5.9, I want to know how much tomcat
dev team will be committed to supporting JDK 1.4.x going forward ? 


thanks in advance for your help,
Girish



-
Yahoo! for Good
Click here to donate to the Hurricane Katrina relief effort. 



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

Re: Small refactoring in Http11Processor

[Costin Manolache]

Bill Barker wrote:

- Original Message -
From: Costin Manolache [EMAIL PROTECTED]
To: tomcat-dev@jakarta.apache.org
Sent: Thursday, September 08, 2005 10:56 PM
Subject: Small refactoring in Http11Processor




Hi,

I have a small patch, spliting the JMX-dependent code in
Http11Processor, i.e.  the few lines of code dealing with the
registration of the thread pool and per thread data - and moving all
non-jmx code in a separate base class.

I know Tomcat5 is heavily dependent on JMX, but the connector can be
used in other containers, or it can be used standalone. This small
change won't affect any functionality on tomcat - all methods are used
only for intialization anyway, not in the critical path.

Please review and let me know if it's ok to commit the change.




It seems that the only thing this patch does is to allow you to exclude
jmx.jar, so it's usefulness seems very minimal :).  TC 3.3  4.1 already run
very happily with the current code without JMX enabled.


True, it allows a smaller package. TC3.3 and 4.1 don't register the 
connector, so no JMX-related code is called, but it still requires 
jmx.jar to be around.






Something better would be a refactor that would remove the duplicated code
between Http11Processor and Http11AprProcessor (which one doesn't do :).


Yes, I've been thinking about this too :-), and also InternalAprBuffer 
and maybe add conditional compilation for the apr. But I didn't want to 
make the diff too big and risky.





Of course, none of this is enough for me to veto your scratching an itch :).



Also, I would like to add another directory under j-t-c, with a build
file and few classes for a 'mini' experiment - i.e. using the connector
standalone, as a minimal http server, and also a target to build a
minimal servlet container as a single self-contained jar. We don't have
a sandbox, and j-t-c seems closest to that :-)




I agree with Mladen that this would work better if you could wait a couple
of weeks until we are up on SVN.


Ok, sounds good, I need to clean up the code anyway ( well, there are 
2-3 classes only and some build.xml ).



Costin


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

Re: Top Level Project? Time for Top Level Lists?

[Costin Manolache]

Remy Maucherat wrote:
So I, for one, would be most appreciative of splitting the traffic; I 
already do split it in my email client, but I think this would be a

help to many participants.  [Especially if, for example, you want the
dev@ traffic to go to a higher priority email account, and have the
commits/issues type traffic hit your lower priority account.]



Of course, but also fewer people will care about bug reports.


I doubt that filling the inbox with the bug reports or commit messages 
will make anyone care more ( or make anyone read them when they don't 
want to ) :-) It seems most people use filters anyway, and those who 
don't ( like using gmane or a web-based interface ) just suffer the 
noise, but still ignore the bugs/commits they don't care about.


I would really appreciate splitting them - I try to read tomcat-dev as 
much as possible, but web-based interfaces ( like gmane's RSS view or 
the html viewer ) are almost useless due to the noise, and filtering the 
news is not easy either.


Costin



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

Small refactoring in Http11Processor

[Costin Manolache]

Hi,

I have a small patch, spliting the JMX-dependent code in 
Http11Processor, i.e.  the few lines of code dealing with the 
registration of the thread pool and per thread data - and moving all 
non-jmx code in a separate base class.


I know Tomcat5 is heavily dependent on JMX, but the connector can be 
used in other containers, or it can be used standalone. This small 
change won't affect any functionality on tomcat - all methods are used 
only for intialization anyway, not in the critical path.


Please review and let me know if it's ok to commit the change.

Also, I would like to add another directory under j-t-c, with a build 
file and few classes for a 'mini' experiment - i.e. using the connector 
standalone, as a minimal http server, and also a target to build a 
minimal servlet container as a single self-contained jar. We don't have 
a sandbox, and j-t-c seems closest to that :-)


Costin
? src/java/org/apache/coyote/http11/Http11BaseProtocol.java
Index: src/java/org/apache/coyote/http11/Http11Protocol.java
===
RCS file: 
/home/cvs/jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Protocol.java,v
retrieving revision 1.64
diff -b -u -w -r1.64 Http11Protocol.java
--- src/java/org/apache/coyote/http11/Http11Protocol.java   22 May 2005 
17:12:11 -  1.64
+++ src/java/org/apache/coyote/http11/Http11Protocol.java   9 Sep 2005 
05:31:50 -
@@ -56,98 +56,12 @@
  * @author Remy Maucherat
  * @author Costin Manolache
  */
-public class Http11Protocol implements ProtocolHandler, MBeanRegistration
+public class Http11Protocol extends Http11BaseProtocol implements 
MBeanRegistration
 {
 public Http11Protocol() {
-cHandler = new Http11ConnectionHandler( this );
-setSoLinger(Constants.DEFAULT_CONNECTION_LINGER);
-setSoTimeout(Constants.DEFAULT_CONNECTION_TIMEOUT);
-setServerSoTimeout(Constants.DEFAULT_SERVER_SOCKET_TIMEOUT);
-setTcpNoDelay(Constants.DEFAULT_TCP_NO_DELAY);
+super();
 }
 
-/**
- * The string manager for this package.
- */
-protected static StringManager sm =
-StringManager.getManager(Constants.Package);
-
-/** Pass config info
- */
-public void setAttribute( String name, Object value ) {
-if( log.isTraceEnabled())
-log.trace(sm.getString(http11protocol.setattribute, name, 
value));
-
-attributes.put(name, value);
-}
-
-public Object getAttribute( String key ) {
-if( log.isTraceEnabled())
-log.trace(sm.getString(http11protocol.getattribute, key));
-return attributes.get(key);
-}
-
-public Iterator getAttributeNames() {
-return attributes.keySet().iterator();
-}
-
-/**
- * Set a property.
- */
-public void setProperty(String name, String value) {
-setAttribute(name, value);
-}
-
-/**
- * Get a property
- */
-public String getProperty(String name) {
-return (String)getAttribute(name);
-}
-
-/** The adapter, used to call the connector
- */
-public void setAdapter(Adapter adapter) {
-this.adapter=adapter;
-}
-
-public Adapter getAdapter() {
-return adapter;
-}
-
-
-/** Start the protocol
- */
-public void init() throws Exception {
-ep.setConnectionHandler( cHandler );
-try {
-checkSocketFactory();
-} catch( Exception ex ) {
-log.error(sm.getString(http11protocol.socketfactory.initerror),
-  ex);
-throw ex;
-}
-
-if( socketFactory!=null ) {
-Enumeration attE=attributes.keys();
-while( attE.hasMoreElements() ) {
-String key=(String)attE.nextElement();
-Object v=attributes.get( key );
-socketFactory.setAttribute( key, v );
-}
-}
-
-// XXX get domain from registration
-try {
-ep.initEndpoint();
-} catch (Exception ex) {
-log.error(sm.getString(http11protocol.endpoint.initerror), ex);
-throw ex;
-}
-if(log.isInfoEnabled())
-log.info(sm.getString(http11protocol.init, getName()));
-
-}
 
 ObjectName tpOname;
 ObjectName rgOname;
@@ -178,460 +92,18 @@
 ( cHandler.global, rgOname, null );
 }
 
-try {
-ep.startEndpoint();
-} catch (Exception ex) {
-log.error(sm.getString(http11protocol.endpoint.starterror), ex);
-throw ex;
-}
-if(log.isInfoEnabled())
-log.info(sm.getString(http11protocol.start, getName()));
-}
-
-public void pause() throws Exception {
-try {
-ep.pauseEndpoint();
-} catch (Exception ex) {
-log.error(sm.getString(http11protocol.endpoint.pauseerror), ex);
-throw ex

Re: commons-logging infinite loop w/5.5.9

[Costin Manolache]

Nathan Bubna wrote:

On 8/23/05, Remy Maucherat [EMAIL PROTECTED] wrote:


Nathan Bubna wrote:


hey folks,

i'm a developer on the VelocityTools subproject, and we recently came
across an issue with the use of commons-logging in Tomcat 5.5.9.

by default, we configure our example applications to use an adapter
between commons-logging and Velocity's LogSystem.  this way, those of
our tools which require logging are able to send messages to
commons-logging and they get passed of to the LogSystem that the rest
of Velocity is using (without having to pass that LogSystem around).
We also, by default, configure our VelocityViewServlet (the core class
of VelocityTools) to automatically send LogSystem messages to the
servlet log.

so, messages sent to c-l are sent the the Velocity LogSystem which
sends the messages to the servlet log.

this works just dandy for everyone in Tomcat 5.0.x, but when we deploy
our very minimal example applications in Tomcat 5.5.9, we promptly
receive stack overflows and out of memory errors that appear to be a
nasty little commons-logging loop.

can somebody help me figure out what change between 5.0 and 5.5 is
causing this?  and further, what can be done about it?  i'm still not
even sure whether to consider this a bug in our design or in Tomcat.

any help would be much appreciated!


In Tomcat 5.5, everything is logged to commons-logging, so the loop you
get is to be expected.



so, i guess that means web applications/frameworks that wish to work
with Tomcat 5.5 must either not redirect commons-logging messages to
their own logging solution or else they must not use
servletContext.log(...) as a target for their logging solution,
correct?



Seems so - since servletContext.log() call commons-logging, not a good 
idea to use an impl. of commons-logging that eventually calls 
servletContext.log().
Maybe a better solution would be to have the Velocity LogSystem send 
messages to commons-logging, then everything will go to c-l and the 
chosen impl.


Costin


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

Re: inprocess Tomcat/apache via mod_jk

[Costin Manolache]

With worker - it may work. However you may find mod_jk inprocess to be 
slower than ajp and mod_proxy ( or comparable in speed ), this is due to 
 the way parameters are passed as strings ( i.e. lots of unoptimized 
char-byte conversion ).


Porting to 5.5.x shouldn't be hard - the interface between tomcat and 
modjk is very simple: you need to startup, i.e. make sure classpath is 
set and the class that executes launches tomcat correctly, and then it's 
a simple class that does the request/response passing.


If you do this for performance reasons - you may want to look at the 
code in jk2, and try to backport it. A benefit would be that the 
interface is even simpler - the req/response are passed in the same kind 
of buffer as ajp requests. AFAIK that's the only major difference. Since 
Remy, Mladen, etc have greatly optimized the regular tcp connectors - 
probably the difference on performance ( with this optimization 
backported ) will be small. But if you use the old style of interface - 
I'm sure jni will be slower (it was slower 2 years ago).


Costin


Christine Ho wrote:

Hi,
   Thanks a lot. I am really appreciated for your
reply. How about the worker MPM? My team is running
the httpd.worker on RHEL4. The current setting is:

StartServers 1
ServerLimit 1

MaxClients 64
MinSpareThreads 32
MaxSpareThreads 64
ThreadsPerChild 64 


Does the inprocess Tomcat 5.5.9 work for the worker
MPM?

thanks,
Christine

--- Bill Barker [EMAIL PROTECTED] wrote:



Well, inprocess doesn't really work for any MPM on
*nix systems (e.g. with
the prefork MPM, you end up with MaxChild copies of
Tomcat running :).  As a
result, there just hasn't been that much interest in
implementing (or even
back-porting) a feature that only works on Windows
and NetWare.


- Original Message -
From: Christine Ho [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, August 16, 2005 3:30 PM
Subject: inprocess Tomcat/apache via mod_jk


Hi,
  I have posted this email a month ago. I just
wonder
if any developer on mod_jk can answer my question. I
would like to have inprocess Tomcat 5.5.9 running in
Apache 2.x if possible.

thanks again,
Christine


Hi,
  I tried to setup Tomcat 5.5.9 running inside the
apache server 2.x via the mod_jk on RHEL4. I got the
following error:
[debug] open_jvm2::jk_jni_worker.c (1055): JVM
created
[emerg] get_bridge_object::jk_jni_worker.c (1097):
Can't find class
org/apache/tomcat/modules/server/JNIEndpoint

I looked at the mod_jk source codes and found out
that
the mod_jk supports the TC32_BRIDGE_TYPE and
TC33_BRIDGE_TYPE. It doesnt support bridge type of
tomcat 4.x and up. Plus the tomcat 5.5.9 doesnt have
the JNIEndpoint.class.

However, it seems to me that the deprecated mod_jk2
supports bridge type of tomcat 4.x and up because it
tries to instantiate the class
org/apache/jk/apr/TomcatStarter.class which exists
in
tomcat-ajp.jar.

I really dont understand why the mod_jk supports
tomcat 3.x only whereas the deprecated mod_jk2
supports tomcat 4.x and 5.x. Can somebody please
tell
me why?

Also is it easy to have mod_jk to support
TC55_BRIDGE_TYPE? Based on the mod_jk source codes
jk_jni_worker.c, I think I just need to define the
TC55_JAVA_BRIDGE_CLASS_NAME to be
org/apache/jk/apr/TomcatStarter.class and then
assign
it to the btype. Is it just that simple?

Another question is what the disadvantages of
running
tomcat inside the apache are. I googled and it seems
to me that not too many people try to run inprocess
tomcat inside apache. I would be interested in
adding
the 5.5 bridge type to the mod_jk.

thanks,
Christine


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam
protection around
http://mail.yahoo.com




-


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





This message is intended only for the use of the
person(s) listed above as the intended recipient(s),
and may contain information that is PRIVILEGED and
CONFIDENTIAL.  If you are not an intended recipient,
you may not read, copy, or distribute this message
or any attachment. If you received this
communication in error, please notify us immediately
by e-mail and then delete all copies of this message
and any attachments.

In addition you should be aware that ordinary
(unencrypted) e-mail sent through the Internet is
not secure. Do not send confidential or sensitive
information, such as social security numbers,
account numbers, personal identification numbers and
passwords, to us via ordinary (unencrypted) e-mail.





-


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









Start your day with Yahoo! - make it your home page 
http://www.yahoo.com/r/hs 

Re: svn commit: r232601 - /tomcat/watchdog/branches/tc4.1.x/WARNING.txt

[Costin Manolache]

Did tomcat move to svn already ?

Costin


[EMAIL PROTECTED] wrote:

Author: markt
Date: Sun Aug 14 04:48:32 2005
New Revision: 232601

URL: http://svn.apache.org/viewcvs?rev=232601view=rev
Log:
Remove CVS closure warning from SVN

Removed:
tomcat/watchdog/branches/tc4.1.x/WARNING.txt



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

Re: AJP using APR

[Costin Manolache]

Bill Barker wrote:
Costin Manolache [EMAIL PROTECTED] wrote in message 
news:[EMAIL PROTECTED]



Bill Barker wrote:

If I understand you correctly, you want MsgAjp to use ByteBuffer instead 
of byte [].  At the cost of never supporting JDK 1.3 ever again, this 
would probably actually improve the performance of ChannelSocket (after 
changing it to use a blocking SocketChannel).


The biggest difference will be if it's a 'direct' buffer, i.e. zero copy. 
Classpath ( gcj, kaffe, etc ) also has byte buffer support - so it should 
be ok, if anyone needs jdk1.3, they can use the old code.





Yes, the idea was that it would be a direct buffer.



But where is the code ?




It's on my hard-drive.  Unlike Remy's APR stuff, o.a.jk is supposed to be a 
pretty stable package(s) at this point.  I can't just check in stuff like 
this without a lot of testing to make sure that it doesn't break anything 
more than JDK 1.3 compatibility ;-).


That's why C has conditional compilation - and java has some 
options-controlled ugly 'if' code :-) It doesn't break anything if the 
option/def is not selected ( just makes the code a bit uglier ). This 
way even JDK1.3 will be happy.



The biggest problem in JNI ( and probably - in Java playing nice with 
other languages and the rest of the platform ) is the objects and 
buffers moving around almost randomly. Yes, it may improve a bit the 
garbage collection speed - so people can create millions of garbage 
objects without thinking about it, unlike most other languages that 
require you to think when allocating objects - but it is the kind of 
optimization that has disastrous consequences on the rest of the 
systems. Luckily gcj and kaffe and mono don't do this crazy thing.

Direct buffers is one band-aid that should be used whenever possible.

Costin






Costin





Rémy





This message is intended only for the use of the person(s) listed above 
as the intended recipient(s), and may contain information that is 
PRIVILEGED and CONFIDENTIAL.  If you are not an intended recipient, you 
may not read, copy, or distribute this message or any attachment. If you 
received this communication in error, please notify us immediately by 
e-mail and then delete all copies of this message and any attachments.


In addition you should be aware that ordinary (unencrypted) e-mail sent 
through the Internet is not secure. Do not send confidential or sensitive 
information, such as social security numbers, account numbers, personal 
identification numbers and passwords, to us via ordinary (unencrypted) 
e-mail.






-
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: AJP using APR

[Costin Manolache]

Bill Barker wrote:


If I understand you correctly, you want MsgAjp to use ByteBuffer instead 
of byte [].  At the cost of never supporting JDK 1.3 ever again, this 
would probably actually improve the performance of ChannelSocket (after 
changing it to use a blocking SocketChannel).


The biggest difference will be if it's a 'direct' buffer, i.e. zero 
copy.  Classpath ( gcj, kaffe, etc ) also has byte buffer support - so 
it should be ok, if anyone needs jdk1.3, they can use the old code.



But where is the code ?

Costin






Rémy





This message is intended only for the use of the person(s) listed above 
as the intended recipient(s), and may contain information that is 
PRIVILEGED and CONFIDENTIAL.  If you are not an intended recipient, you 
may not read, copy, or distribute this message or any attachment. If you 
received this communication in error, please notify us immediately by 
e-mail and then delete all copies of this message and any attachments.


In addition you should be aware that ordinary (unencrypted) e-mail sent 
through the Internet is not secure. Do not send confidential or 
sensitive information, such as social security numbers, account numbers, 
personal identification numbers and passwords, to us via ordinary 
(unencrypted) e-mail.






-
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: Tomcat performance patch (in development) to reduce concurrency...

[Costin Manolache]

Mladen Turk wrote:
Scott Marlow wrote:
Hi,
I wonder if anyone has any feedback on a performance change that I am
working on making.

Can you compare the performance of you code with the standard
implementation when the concurrency is lower then maxThreads
value?
I see no point to make patches that will deal with cases presuming
that the concurrency is always higher then the actual number of
worker threads available.
IMHO this is a bad design approach for the http applications,
and NIO performance is a proof of that.
It might help in cases where you have a very very slow clients.
In any other case the thread context switching will kill
the performance thought.
Further more I don't see how can you avoid keep-alive connection
problems without using a thread-per-connection model.
The point is that with 100 keep-alive connections you will still
have 100 busy threads.
Why ? 100 keep alive connections doesn't mean 100 active requests,
in real servers there are many 'keep alive' connections that are just
waiting for the next request.
In all servers I know, concurrency was higher than the configured number 
of workers  - at peak time, at least, where performance matters.

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

Re: Tomcat performance patch (in development) to reduce concurrency...

[Costin Manolache]

Remy Maucherat wrote:
I looked at this yesterday, and while it is a cool hack, it is not that 
useful anymore (and we're also not going to use the concurrent utilities 
in Tomcat, so it's not really an option before we require Java 5). The 
main issue is that due to the fact keepalive is done in blocking mode, 
actual concurrency in the servlet container is unpredictable (the amount 
of processing threads - maxThreads - will usually be a lot higher than 
the actual expected concurrency - let's say 100 per CPU). If that issue 
is solved (we're trying to see if APR is a good solution for it), then 
the problem goes away.
I'm still trying to understand the APR connector, but from what I see it 
is still mapping one socket ( 'keep alive' connection ) per thread. 
That's how it allways worked - but it's not necesarily the best 
solution. The only thing that is required is to have a thread per active 
request - the sleepy keep alives don't need thread ( that could be 
implemented using select in the apr, or nio in java )


Your patch is basically a much nicer implementation of maxThreads 
(assuming it doesn't reduce performance) which would be useful for the 
regular HTTP connector, so it's cool, but not worth it. Overall, I think 
the way maxThreads is done in the APR connector is the easiest (if the 
amount of workers is too high, wait a bit without accepting anything).
That's a tricky issue :-) In some cases ( like load balancing ) not 
accepting is the right solution, but in other cases droping connections 
is not what people want ( in particular if most of the threads are just 
waiting on keep alives ).

( sorry if I missed some details in the new implementation :-)
Costin

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

Re: Tomcat performance patch (in development) to reduce concurrency...

[Costin Manolache]

Mladen Turk wrote:
Costin Manolache wrote:
I'm still trying to understand the APR connector, but from what I see 
it is still mapping one socket ( 'keep alive' connection ) per thread. 

No it doesn't. If the connection is keep-alive, and there is no activity
for 100ms, the socket is put in the poller, and that thread is freed.
When the next data on that socket arrives, the socket is signaled and
passed to the thread pool.
Mladen.
Sorry, I missed that. So we can have as many 'keep alive' idle as we 
want - only those active are taking threads ? Which file implements this 
( the 100ms timeout and poller ) ? I assume this is only done in the APR 
connector, or is it implemented in java as well ( nio ) ? .

Costin
-
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/authenticator AuthenticatorBase.java

[Costin Manolache]

Remy Maucherat wrote:
Keith Wannamaker wrote:
If no one else is concerned that Tomcat 5.5 doesn't work by default

Any other nonsensical statement to make ? The only thing that does not 
work is opening third party documents from the website, due to IE's 
broken handling of this.

How about a) going whining at M$ instead ? b) using appropriate 
configuration.

Your veto is completely invalid anyway.
IE is still (unfortunately) the browser used by a lot of people, and if
there is a way to work around IE brokeness - I think it's a good idea to 
do it.

Complaining to M$ doesn't work - people will just end up buying IIS 
instead :-)

Seriously, not sure why is the veto invalid - if the choice is between 
having it working for 90% of the people and doing it 'right' - it is 
worth probably more discussion and a pragmatic decision :-) I would vote 
for fixing it for the 90% of people - at least until IE gets down to 
some 49%.

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

Re: New TLP draft

[Costin Manolache]

Remy Maucherat wrote:
Need to identify just how much of the jakarta-* CVS will go with
Tomcat. Watchdog + ServletAPI modules?

That's undecided. Would the old projects would remain at Jakarta, or 
would they be covered by the new project ?

Why would they remain in jakarta ? They have the same committer list as 
tomcat, and are closely related.

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

Re: New TLP draft

[Costin Manolache]

Tim Funk wrote:
Looks good. Just an idea, it may be nice to have the 3 new lists
tomcat-bug - bug updates from bugzilla. When I subscribe to other groups 
tomcat-cvs  - Same as tomcat-bug but just for cvs commits.
tomcat-gump  - For deaths by gump. If your not a committer - these are 
This has been debated many times :-), maybe this time it'll succeed.
The typical argument for keeping it all in one place is that it may 
force people to read them instead of filtering the out with the mail 
app. It would be nice to split it - it'll be much easier to read 
tomcat-dev ( including in blogs.gmane.org ).

Regarding CVS move - are we going to just change the name of the roots ( 
s/jakarta/apache/ ) or should we do a bit more reorg, to make it easier 
when we move to svn ?  The current layout is based on a lot of 
'historic' reasons that no longer apply. For 3.x and 4.x - of course it 
makes sense to just keep the trees as they are.

Costin

-Tim
Remy Maucherat wrote:
Hi,
Here's a new draft with the necessary updates.
I suppose this needs to be sent to the PMC for approval. If this draft 
is ok, I will send it there.

Then there are infrastructure taks:
- renaming mailing lists
- moving CVS
- new DNS and virtual host

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

Re: [RESULT] PMC Chair

[Costin Manolache]

Kurt Miller wrote:
From: Yoav Shapira [EMAIL PROTECTED]
Below is the draft resolution we agreed on previously, so it should be
pretty close.  We need to make sure the PMC names are correct and 
complete.
Congrats to Remy and thanks everyone for voting, and of course thanks 
Henri
;)

Yoav

While my low level of involvement probably doesn't merit being in the PMC,
I'm concerned that only those names that appear in the PMC list will retain
active committer status. I'm sure there are other committers who fall into
my category. Will the 50+ committers who are not on the PMC be move
to emeritus status? If not how will that be decided?
Congratulations to Remy. Also thank you Yoav for moving the formalities 
along.
Congratulation Remy !
I think a lot of people agree that anyone who is an active committer 
should be in the PMC ( that's what jakarta has been doing for a long 
time ). It's 'should' - not 'must' - that means you are not required to 
do this if you really don't want to.

I think Remy has already sent additional lists of people who are active 
but have not voted. I assume those who really don't want will have to 
send email to Remy to be taken out of the list before it goes to the board.

Regarding 'emeritus status' - I think usually people who have not 
participated in the last 6 months ( or 1 year ) can be moved to 
'emeritus' - unless they ask to remain in the list of active committers.
( for example because they plan to return to active soon, etc :-). We 
could send a mail to everyone in the avail list, and if we don't get an 
answer or we get an 'I don't care' - we should do the switch.

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

Re: [RESULT] PMC Chair

[Costin Manolache]

Remy Maucherat wrote:
Kurt Miller wrote:
From: Yoav Shapira [EMAIL PROTECTED]
Below is the draft resolution we agreed on previously, so it should be
pretty close.  We need to make sure the PMC names are correct and 
complete.
Congrats to Remy and thanks everyone for voting, and of course thanks 
Henri
;)

Yoav

While my low level of involvement probably doesn't merit being in the 
PMC,
I'm concerned that only those names that appear in the PMC list will 
retain
active committer status. I'm sure there are other committers who fall 
into
my category. Will the 50+ committers who are not on the PMC be move
to emeritus status? If not how will that be decided?

The official ASF policy calls for a 6 month inactivity. No Tomcat 
committer has ever been removed in 5+ years. It seems reasonable to me 
that if they don't at least ask for it that they would now be removed.
+1
To get things started, since I'm probably close to the 6 month 
inactivity limit ( in either direction :), I would like to ask to stay 
in the active list :-)


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

Re: [ANN] JK 1.2.10 Released

[Costin Manolache]

Mladen Turk wrote:
Henri Gomez wrote:
I could provide Linux binaries for Suse 8.0 PPC and Suse SLES 9 but
it's up to distributions mainteners to provide such binaries (via
rpm/deb).
Take a look at jpackage for many Linux RPM binaries
Yes, that is my opinion too.
We should focus on providing a solid:
'configure  make  make install', rather then
providing a binaries for ourself.
I think that we are good and mature project that any
serious linux distribution (at least targeted for
enterprise environment) should take into account,
and provide a binaries on their own.
We can provide binaries for platforms that does not
come with integrated build system like WIN32, and
we are doing so. Although, personally I would be
pleased to see the isapi_redirector.dll as part of the
next XP service pack, it's hard too expect something
like that :)
I kind of disagree...
If I want Firefox for linux - I get it from Mozilla.org. It may be a 
.tar.gz or .rpm - but it is a binary provided by the software 
maintainers, not by a 3rd party ( like a linux distributor ). And it is 
the 'real' thing, not a randomly modified version ( different flags and 
features, etc ).

Linux is such a mess in large part because people who write software 
treat it as second-class - 'let someone else deal with compiling 
binaries for linux, I'll only do it for windows and mac'. As a result 
linux distributions have the freedom to mess up and 'personalize' each 
package to their own taste ( we all know how painful it is to switch 
from one distro to another or use/support 2 distros - each file is in a 
different place - this is called lock in ). On windows - you can get 
nice binaries, with installer and everything else you would expect - 
distributed by the package authors.


Costin

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

Re: [VOTE] PMC Chair

[Costin Manolache]

Jim Jagielski wrote:
I would recommend that before anyone responds, we decide who should
rec' and tally the votes. Also, votes should only be counted
from those who will be on the new PMC.
So before the vote:
   1. Finalize list of PMC members
  (all current committers)
   2. Determine who to collect and tally votes
  (I propose Henri Yandell)

Let's not make this too long or complicated.
Some votes are already out of the box, and I think we agree that
any committer who wants to be in the PMC can get there by simply asking 
for it.

So if Henri can send back a count ( or just the winner ) of all private 
votes he receives, as well as the list of people who voted - we can 
check against avail and update the PMC member list as well. ( a vote by 
a committer is an indication that he wants to vote so he wants to be in 
the pmc :-).

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

Re: [VOTE] PMC Chair

[Costin Manolache]

Yoav Shapira wrote:
The initial Tomcat PMC chair should be:
[ +1 ] Remy Maucherat
[  ] Yoav Shapira 

Next year I'll switch, Yoav is great - I just think Remy deserves to be 
the first chair...

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

Re: TLP Draft Proposal

[Costin Manolache]

Remy Maucherat wrote:
Costin Manolache wrote:
Yoav Shapira wrote:
If Remy is interested, I think it would be fair to have a vote. If 
whoever is first later decide he had too much politics/admin pains - 
we'll have a backup ready :-)

At this point, I think I cannot avoid being a candidate. Yoav may be the 
best chair, however, so there's an opportunity for a real election.
Good. Let's get this over then.
I never liked one candidate elections or elections with 99% results ( 
remind me of an evil system :-)

Yoav would be an excelent chair - however Remy has my vote this time.

I'm at the moment in favor of allowing non consecutive one year terms. 
Of course :-)
Costin
Unfortunately, it means two people can share the job, which would defeat 
the purpose, but without this, we could run out of worthy/willing 
candidates pretty fast.

I don't know what are the rules wrt board meetings ( if only the pmc 
is allowed, etc ), but while there is only one pmc chair, we can have 
as many volunteers as we want to help with the admin stuff - reports, 
etc( if I remember, Henri was doing this long before he became chair 
of jakarta pmc, same for Geir ).

Right.
So it's great to have as many people as possible volunteer for the 
unpleasand admin work - it will only make the admin job easier, and 
it'll make the rotation transition easier too.

Rémy

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

Re: TLP Draft Proposal

[Costin Manolache]

Jim Jagielski wrote:
The PMC Chair has ultimate authority, since the position is board
appointed and results in the Chair being a VP of the ASF. There's
no precedent for sharing the role or having a co-Chair. The PMC
Chair is the point man for the PMC.
Yes, we know - that's one of the reasons some people want this to be a 
'rotating' position.

Sharing the role ( i.e. the tasks ) has a lot of precedents.
I have no problem with someone having this kind of authority - in 
projects like Linux or Python, where the guy in charge created the 
project in the first place. I am not confortable at all with having the 
'ultimate' authority appointed - even when (in most cases) it is at the 
recomandation of the community. IMO it is the worse of both worlds.


The PMC Chair is nominated by the PMC, and the recommendation is
sent in with the PMC resolution. The board then debates the issue
and will usually approve the resolution and appoint the nominated
person as chair.
Since the PMC Chair is the main guy for the PMC, it is even more
an issue for that person to be very much an ASF weenie and
understand and embrace the Apache Way... It can be a
political and managerial kind of position and any candidate
should realize that sad fact :/
Well, Remy and Yoav are members of ASF - so they clearly passed the 
'Apache Way' test. If this is a requirement - than the pool of 
candidates is going to be quite small ( Remy, Yoav, you, Bill - and 
Craig or Justina if they choose to get back )

For 'managerial' and 'political' - I think both did both ( maybe without 
enjoying it, but still...)

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

Re: TLP Draft Proposal

[Costin Manolache]

Yoav Shapira wrote:
 NOW, THEREFORE, BE IT FURTHER RESOLVED, that [XXX]
   be appointed to the office of Vice President, Apache Tomcat, to
   serve in accordance with and subject to the direction of the
   Board of Directors and the Bylaws of the Foundation until
   death, resignation, retirement, removal or disqualification, or
   until a successor is appointed; and be it further
+1
I would like to propose Remy == XX ( he can obviously refuse, but I 
hope he will not do that ). Obvious reasons on why he is the best 
choice, so I don't think consensus will be a problem - only his 
acceptance ( it'll not involve too much coding :-).

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

Re: TLP Draft Proposal

[Costin Manolache]

Jim Jagielski wrote:
Yoav Shapira wrote:
Hi,
I could... But there's the question of whether we want all committers on the
PMC or just the active ones.  The avail file has, in addition to the people
I already listed:
duncan,jon,rubys,akv,jhunter,preston,shemnon,shachor,bergsten,gonzo,mode,har
ishp,arun,craigmcc,jluc,nacho,aried\
el,horwat,ed,alex,gaburici,jiricka,pierred,glenn,larryi,arieh,marcsaeg,danmi
l,shai,keith,kief,melaquias,m\
braden,clucas,bip,seguin,mmanders,andya,ccain,bojan,patrickl,jazmin,ekr,manv
een,cks,denisb,dsandbe\
rg,bobh,idarwin,johnturner,ecarmich,fuankg,clar,jim,wrowe
John Turner, Jim J., Bill Rowe are obviously active, I'll add them right
now.  But many of the above are not active, emeritus committers...

Personally, I would agree if people did not think I deserved PMC
member status. I would be honored to accept, but would 100% understand
if there were, well... thoughts that it was unwarranted :)
I hope that Tomcat PMC will be one where each active committer who is
willing will be a member, I don't want it to be an arbitrary and random
process like it was in jakarta ( or asf membership ). If you are working
on tomcat, I can't see why not be in PMC ( unless you really don't want to )
I don't know if I deserve it tough - since I haven't been very active
last year - but since my project is now over, I hope to get back on
tomcat and become active :-)
Costin
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: TLP Draft Proposal

[Costin Manolache]

Yoav Shapira wrote:
Hi,

I would like to propose Remy == XX ( he can obviously refuse, but I
hope he will not do that ). Obvious reasons on why he is the best
choice, so I don't think consensus will be a problem - only his
acceptance ( it'll not involve too much coding :-).

I was thinking Remy might refuse, so he doesn't have to deal with all the
administrative stuff that comes with the role.  That and my own interest in
the role prevent consensus at this point ;)  
It Remy will refuse - you have my vote :-) It's just that he done so 
much coding in this project - that I think it would be good if he is the 
first chair.

I think the idea of rotating ( let's say yearly ? ) would be an excelent 
one - it'll avoid having people serve for too much ( and sometimes avoid 
bad habbits - like forgeting to ask the community before making 
important decisions :-)

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

Re: TLP Draft Proposal

[Costin Manolache]

Yoav Shapira wrote:
Howdy,

I think the idea of rotating ( let's say yearly ? ) would be an excelent
one - it'll avoid having people serve for too much ( and sometimes avoid
bad habbits - like forgeting to ask the community before making
important decisions :-)
That's a decent plan. What do the other projects do about that ?

Logging Services, which formed just recently, has a yearly PMC chair term,
but the incumbent can repeat the role if the PMC so votes.
Sounds ok - I would preffer a real rotation. What about 'can repeat the 
role if he wants and there is no other candidate' ? ( if he doesn't want 
- of course, someone else needs to be 'volunteered' ).

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

Re: TLP Draft Proposal

[Costin Manolache]

Yoav Shapira wrote:
Hola,

What do you guys (parties in the subject) have to say about that?
Lat's put all the cards on the table, do what ever is needed and move
forward. I'm getting tired of all that politic bullshit, but I'm also
aware it must be done. So ... Remy, Yoav?

I'm waiting to hear from Remy on what he wants to do.  He has to want to be
the PMC chair ;)  If he does want it and all the admin stuff that goes with
it, it's fine with me.  The role of a VP is something we can define, but
doesn't really exist within other ASF projects, which just have the PMC
chair and the rest of the PMC, so I don't think we need one.
If Remy is interested, I think it would be fair to have a vote. If 
whoever is first later decide he had too much politics/admin pains - 
we'll have a backup ready :-)

I don't know what are the rules wrt board meetings ( if only the pmc is 
allowed, etc ), but while there is only one pmc chair, we can have as 
many volunteers as we want to help with the admin stuff - reports, etc( 
if I remember, Henri was doing this long before he became chair of 
jakarta pmc, same for Geir ).

So it's great to have as many people as possible volunteer for the 
unpleasand admin work - it will only make the admin job easier, and 
it'll make the rotation transition easier too.


Costin
I'm also fine with the annual rotation as suggested by Costin.
Yoav

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

Re: Changing the Tomcat5 WIN32 service runner

[Costin Manolache]

Mladen Turk wrote:
@if %1 == install   goto cmdInstall
@if %1 == uninstall goto cmdUninstall
@if %1 == start goto cmdStart
@if %1 == stop  goto cmdStop
@if %1 == restart   goto cmdRestart
echo Usage
goto cmdEnd

I assume the '.bat' is the only option - i.e. could you use arbitrary 
'executables' or other 'scripting languages' ? I.e. if you have cygwin 
or equivalent installed - could it execute a .sh ? Or if you have 
different scripting engine - could it run the .js or .py instead of 
.bat? And the most interesting - could you specify an executable .jar as 
the command ?

It's just that .bat is one of the ugliest scripting languages...
Having the unix-style service mechanism, i.e. a script with 
start/stop/etc is IMO a step forward and makes it much easier to
deal with services.

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

Re: [VOTE] Propose Jim Jagielski and William A. Rowe as JakartaTomcatConnectors commiters

[Costin Manolache]

Both +1, of course.
I guess you meant 'commiters for jakarta tomcat project' :-)
Costin
Mladen Turk wrote:
I'd like to nominate Jim Jagielski ([EMAIL PROTECTED]) and
William A. Rowe ([EMAIL PROTECTED]) as commiters for the
JTC connectors.
Both of them are long time ASF members. Jim is even a
director of Apache Software Foundation.
They both are core apache httpd designers and developers
for years now, and IMHO we should be proud tho have them
on board :). I'm sure they will help us with the better
apache httpd integration.
So...
[x] Yes, Jim is really a cool guy.
[ ] No way.
and..
[x] Sure, wellcome Bill.
[ ] I think I know httpd better then him.
The both have my ++1.
Regards,
Mladen

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

Re: Changing the Tomcat5 WIN32 service runner

[Costin Manolache]

William A. Rowe, Jr. wrote:
At 06:31 AM 2/21/2005, Mladen Turk wrote:

Unlike any other java or java/jni implementations
it does not tries to make a java as a service, but
rather makes a batch (.bat) file as a service.

IIUC, that means;
  1. service signals (shutdown etc) aren't recognized by cmd 
 (sh for you linux observers) in any useful manner.

  2. it invokes cmd, which invokes the apps.  You are stuck
 with an instance of cmd for the lifetime of the process.
Seems like a big leap backwards, IMHO.  If anything, a psuedo-sh
script interpreter which picked up the envvar assignments (the
only thing you want to move to .cmd for, anyways) makes more
sense than this.
Would it be possible to have the signals intercepted and cause the
execution of the .bat file with different params ( like 'stop' or 
'reload' or 'start' ), similar with unix init.d files ?

I like the idea of running a .bat ( or arbitrary .exe ) as a service 
based on the analogy with the init.d files - but it needs the 
stop/restart as well.

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

Re: SVN migration?

[Costin Manolache]

Well, numbers are statistics do speak for themself - but may tell 
different things. Apache may have most projects in SVN, but the world 
has most projects in cvs. And most tools (finally) have some good, first 
class built-in support for CVS, most people are (finally) familiar 
enough with using cvs. There are some plugins for svn ( and other 
version control tools ) - but not at the same level.

I like SVN a lot - and for a new project probably I would choose it if 
there is a choice - sf.net or other places are cvs only.  But I don't 
think all the pain for switching tomcat is justified, and switching few 
repositories but not others is even worse.

Unless we're going to do major reorganization of the code ( move 
directories around ) or we start some complex branches, or we have any 
other need where SVN is much better than CVS - I would say it's better 
for everyone to stick with the stable environment.

Costin

Henri Yandell wrote:
I've not heard anything about it being mandatory yet, but the numbers
speak for themselves.
The www.apache.org site has 24 coding projects. There are 22 projects
listed on the svn.apache.org/viewcvs.cgi page. 2 of those are dead, so
20 out of 24 ASF projects have an svn presence of some kind.
The people still left with readable CVS modules are:
mod_perl
ant
2/3rds of jakarta
possibly gump (though they have an svn module too)
apache conference
most of xml
logging
half of web services
So I assume at some point there'll be pressure to turn off the CVS server.
On the command line, svn is pretty much the same as cvs. Some bits are
faster, some slower. There are various improved features
(http://subversion.tigris.org/ lists them) that people have been
asking for for ages with CVS.
Habit-wise, the only differences I've hit are:
1) you checkout from a url, not from a cvs-root and a path.
2) tagging/branching is done by copying a directory revision (really
creating a symlink-style thing in the database) and isn't applied to
every file individually.
Tool-wise, Subclipse is an Eclipse plugin that seems to work fine for
standard development (checkout, update, diff, commit). I'm unsure
whether you can create tags/branches using it as I always do that on
the command line, be it cvs or svn. IntelliJ has a plugin and the next
version will have it built in. TortoiseSvn is spoken well of, and I
can vouch for svn on linux/OS X, I've had no problems in the last year
of use.
Docs are docs :) Yep, they'll need updating. 

Build scripts. Do you have scripts that check modules out of cvs? If
so I imagine the ant support for svn might be a big deal. Unsure what
it's like.
Hen
On Thu, 03 Feb 2005 21:32:41 -0800, Costin Manolache
[EMAIL PROTECTED] wrote:
Is this mandatory ? I suspect there'll be a lot of build
script/doc/habits/tool changes involved. CVS is working reasonably well
at the moment, and a lot of tools have (finally) very good support for it.
Costin
Henri Yandell wrote:
Just wondering if the Tomcat community have any thoughts on a
migration to Subversion?
The process seems pretty easy, though Tomcat may be more complicated
than the usual CVS module. Infra have the process documented at:
http://www.apache.org/dev/cvs2svn.html
The Jakarta status is in the wiki at:
http://wiki.apache.org/jakarta/Migrating_20to_20Subversion
The aim would be for all the tomcat modules to migrate into
asf/repos/jakarta/tomcat/ so that we can have a cleaner top-level
structure to the system, within that though the Tomcat community are
free to choose whatever strategy fits.
I've intentionally left Tomcat until last to nudge about this so as to
build up some experience within Jakarta of dealing with SVN as users
and as a migration. Some of you are probably already getting to grips
with svn following the Commons migration.
Just to provide the context for this, the Infra group are looking to
move from CVS to SVN in the long term and Jakarta were far and away
the main laggards in this. In the last month or so, a third of Jakarta
has moved over, so that's now improving.
Another question is whether the Tomcat community have any svn
expertise in terms of planning svn strategies, or whether we should
try to find some other committers to offer opinions.
Thanks,
Hen
-
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-connectors/jni/native/src ssl.c

[Costin Manolache]

I assume this is going to be a compile/configure time option ?
What about using a different approach - generate multiple .so files, one 
with common/base/non-optional functionality, and one for each optional 
library. Compile time options makes it hard to distribute compiled 
binaries and add more requirements.


Costin
[EMAIL PROTECTED] wrote:
mturk   2005/02/02 23:47:49
  Added:   jni/native/src ssl.c
  Log:
  Add OpenSSL support.
  
  Revision  ChangesPath
  1.1  jakarta-tomcat-connectors/jni/native/src/ssl.c
  
  Index: ssl.c
  ===
  /* Copyright 2000-2004 The Apache Software Foundation

   *
   * Licensed under the Apache License, Version 2.0 (the License);
   * you may not use this file except in compliance with the License.
   * You may obtain a copy of the License at
   *
   * http://www.apache.org/licenses/LICENSE-2.0
   *
   * Unless required by applicable law or agreed to in writing, software
   * distributed under the License is distributed on an AS IS BASIS,
   * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
   * See the License for the specific language governing permissions and
   * limitations under the License.
   */
  

  #include apr.h
  #include apr_pools.h
  #include apr_file_io.h
  

  #include tcn.h
  

  #ifdef HAVE_OPENSSL
  

  /* OpenSSL headers */
  #include openssl/ssl.h
  #include openssl/err.h
  #include openssl/x509.h
  #include openssl/pem.h
  #include openssl/crypto.h
  #include openssl/evp.h
  #include openssl/rand.h
  #include openssl/x509v3.h
  /* Avoid tripping over an engine build installed globally and detected
   * when the user points at an explicit non-engine flavor of OpenSSL
   */
  #if defined(HAVE_OPENSSL_ENGINE_H)  defined(HAVE_ENGINE_INIT)
  #include openssl/engine.h
  #endif
  

  

  

  

  

  

  

  

  #else
  

  

  #endif

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

Re: The FIX - Shutdown not working under SLES8 and FC2

[Costin Manolache]

What about:
- add this information to the bug report
- send a patch to the FAQ or edit a wiki page ( well, the tc wiki is not 
very used, but probably google will find this if anyone has a similar 
problem ). Or post it in your weblog/site/etc for google to find.

It should be obvious changing the default configuration only to deal 
with this case won't happen. If a computer can't locate itself by name - 
you'll have a lot of other problems.

Costin
( BTW - if you plan to participate in any open source project - be 
prepared for a lot of hurt feelings and negative comments, if you can't 
handle it, stay out. It happens to all of us. Track the problem, send a 
patch and friendly reminders if it gets ignored - and be prepared to 
accept a 'no' )

[EMAIL PROTECTED] wrote:
After some playing around I think I've tracked down what the fix is, and
I'd like to throw an idea out as to what could be happening.
First the fix. The fix is to explicitly state in the AJP13 connector
that the connector should ONLY bind to the loopback address (i.e. add
address=127.0.0.1). Maybe this should be made the default because;
a) it's a fix to the issue.
and
b) it also enhances security. 

Those people who are using AJP13 between machines should have the
knowlege to re-configure the connector to allow connections between
different machines.
Now the suggestion as to why this is happening. 

My machine is behind a firewall, and therefore has non-routable IP
addresses (192.168.x.x). If you lookup the full hostname (a.b.c.d) on
the machine the hosts file resolves it to the private IP, if you look
it up using DNS it resolves to the public IP address of the firewall.
If you lookup the machine name only (a) from on the machine or anywhere
else it resolves via DNS to the public IP of the firewall.
From what I can tell the AJP13 connector looks up the hostname only,
(which resolves it to the public IP address), then tries to connect to
the AJP13 port on the public IP address, and because the firewall
blocks this traffic, does not connect, and then gives up.
To back this up I have put the hostname on it's own into the hosts file
(i.e. a resolves to the private IP), and everything worked again.
Before everyone shouts you've got a strange config, it's your problem,
I'd like to re-iterate that this issue can be avoided in many ways, and
my personal beleif is that the order of preference of fixes would be;
1) Add the address=127.0.0.1 to the default server.xml (which also has
the side effect of increasing security).
2) If no address is specified then make the shutdown system start by
trying to connect to localhost as opposed to what seems to be the
current behaviour of attempting to resolve to an external address
first.
3) Require everyone to have the short hostname configured to resolve to
their local IP.
The reasons for this ordering is that 1 is the least effort by the
fewest people, 2 is more effort but by a small group, 3 has a potential
impact on all users and no matter where you document it will still be
missed by those who beleive in unpack and run.
Regards,
Al.
Al Sutton [EMAIL PROTECTED] wrote on 03.02.2005, 07:58:16:
Ben,
Thanks for this. I'm not using any settings in JAVA_OPTS as shown below;
[EMAIL PROTECTED] al]$ env | grep -i JAVA
JRE_HOME=/usr/java/jdk1.4/jre
PATH=/usr/java/jdk1.4/bin:/home/al/utils/apache-ant-1.6.2/bin:/usr/kerberos/
bin:/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin
JAVA_HOME=/usr/java/jdk1.4
[EMAIL PROTECTED] al]$
I've tried this on two machines, one an Athlon XP 2400+ running FC2, and the
other a Dual Xeon 2.8 GHz running SLES 8, both showed the same problem, so
I'm pretty sure it's not hardware. The machines are also geographically
seperated and do not operate on the network (ones on my LAN at home, the
others on a LAN at work), so I'm pretty sure it's not related to the
environment external to the machine.
I'm going to upgrade to _07 and get the latest kernel and try again, as
currently the only difference seems to be that your execting startup and
shutdown from within the bin directory and I'm executing it from the top
level (i.e. doing bin/startup.sh and bin/shutdown.sh).
Thanks again,
Al.
-Original Message-
From: Ben Souther [mailto:[EMAIL PROTECTED]
Sent: 02 February 2005 23:32
To: Tomcat Users List
Subject: RE: Shutdown not working under SLES8 and FC2
On Wed, 2005-02-02 at 17:11, Ben Souther wrote:
On Wed, 2005-02-02 at 16:43, Al Sutton wrote:
Hmmm The latest updates gives me;
Linux host 2.6.10-1.9_FC2 #1 Thu Jan 13 17:54:57 EST 2005 i686 athlon
i386
GNU/Linux
and I'm on JDK 1.4.2_06 as opposed to _05.
Would it be possible for you to upgrade?, I'd like to have the exact
same
environment, but please don't put yourself out or risk a critical
environment.
OK, here you go.
It turns out that I did have _06 on this machine. I also have
2.6.10-1.9_FC2 (which is no longer the latest BTW ;)).
Once again, I started and stopped without a problem.
Here is the screen dump:

Re: The FIX - Shutdown not working under SLES8 and FC2

[Costin Manolache]

Al Sutton wrote:
Is there any reason why it doesn't try localhost first? Using localhost
before anything else would have the following benefits;
a) Would ensure that only really strange network configs would be affected
(i.e. those where localhost is not the local host).
b) Make use of the speed advantage some OS's have in their implementation of
the loopback address.
c) Avoid any wacky differences in the implementation of
InetAddress.getLocalHost() between JVMs/OSs/etc.
Off the top off my head I can't see the advantages of using the result of
InetAddress.getLocalHost() first.
What do you mean by 'try localhost first' ? The name 'localhost', or 
'127.0.0.1' or whatever the number is in IPV6 ? I guess the reason for 
InetAddress.getLocalHost() is the wacky differences between OSes :-),
and if it's broken on a platform - it should be fixed ( by Sun or OS 
vendor )

Costin


Al.
-Original Message-
From: Bill Barker [mailto:[EMAIL PROTECTED]
Sent: 03 February 2005 19:11
To: Tomcat Developers List
Subject: Re: The FIX - Shutdown not working under SLES8 and FC2
If no address is configured, ChannelSocket attempts the shutdown on
InetAddress.getLocalHost().  Personally, I'm not inclined to change this as
it points to a network configuration problem if this is unreachable.
However, you might try complaining to Sun about how they have implemented
getLocalHost on SLES8.
- Original Message -
From: [EMAIL PROTECTED]
To: Tomcat Users List tomcat-user@jakarta.apache.org
Cc: tomcat-dev@jakarta.apache.org
Sent: Thursday, February 03, 2005 2:14 AM
Subject: The FIX - Shutdown not working under SLES8 and FC2

After some playing around I think I've tracked down what the fix is, and
I'd like to throw an idea out as to what could be happening.
First the fix. The fix is to explicitly state in the AJP13 connector
that the connector should ONLY bind to the loopback address (i.e. add
address=127.0.0.1). Maybe this should be made the default because;
a) it's a fix to the issue.
and
b) it also enhances security.
Those people who are using AJP13 between machines should have the
knowlege to re-configure the connector to allow connections between
different machines.
Now the suggestion as to why this is happening.
My machine is behind a firewall, and therefore has non-routable IP
addresses (192.168.x.x). If you lookup the full hostname (a.b.c.d) on
the machine the hosts file resolves it to the private IP, if you look
it up using DNS it resolves to the public IP address of the firewall.
If you lookup the machine name only (a) from on the machine or anywhere
else it resolves via DNS to the public IP of the firewall.
From what I can tell the AJP13 connector looks up the hostname only,
(which resolves it to the public IP address), then tries to connect to
the AJP13 port on the public IP address, and because the firewall
blocks this traffic, does not connect, and then gives up.
To back this up I have put the hostname on it's own into the hosts file
(i.e. a resolves to the private IP), and everything worked again.
Before everyone shouts you've got a strange config, it's your problem,
I'd like to re-iterate that this issue can be avoided in many ways, and
my personal beleif is that the order of preference of fixes would be;
1) Add the address=127.0.0.1 to the default server.xml (which also has
the side effect of increasing security).
2) If no address is specified then make the shutdown system start by
trying to connect to localhost as opposed to what seems to be the
current behaviour of attempting to resolve to an external address
first.
3) Require everyone to have the short hostname configured to resolve to
their local IP.
The reasons for this ordering is that 1 is the least effort by the
fewest people, 2 is more effort but by a small group, 3 has a potential
impact on all users and no matter where you document it will still be
missed by those who beleive in unpack and run.
Regards,
Al.
Al Sutton [EMAIL PROTECTED] wrote on 03.02.2005, 07:58:16:
Ben,
Thanks for this. I'm not using any settings in JAVA_OPTS as shown below;
[EMAIL PROTECTED] al]$ env | grep -i JAVA
JRE_HOME=/usr/java/jdk1.4/jre
PATH=/usr/java/jdk1.4/bin:/home/al/utils/apache-ant-1.6.2/bin:/usr/kerberos/
bin:/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin
JAVA_HOME=/usr/java/jdk1.4
[EMAIL PROTECTED] al]$
I've tried this on two machines, one an Athlon XP 2400+ running FC2, and
the
other a Dual Xeon 2.8 GHz running SLES 8, both showed the same problem, so
I'm pretty sure it's not hardware. The machines are also geographically
seperated and do not operate on the network (ones on my LAN at home, the
others on a LAN at work), so I'm pretty sure it's not related to the
environment external to the machine.
I'm going to upgrade to _07 and get the latest kernel and try again, as
currently the only difference seems to be that your execting startup and
shutdown from within the bin directory and I'm executing it from the top
level (i.e. doing bin/startup.sh and bin/shutdown.sh).

Re: SVN migration?

[Costin Manolache]

Is this mandatory ? I suspect there'll be a lot of build 
script/doc/habits/tool changes involved. CVS is working reasonably well 
at the moment, and a lot of tools have (finally) very good support for it.

Costin
Henri Yandell wrote:
Just wondering if the Tomcat community have any thoughts on a
migration to Subversion?
The process seems pretty easy, though Tomcat may be more complicated
than the usual CVS module. Infra have the process documented at:
http://www.apache.org/dev/cvs2svn.html
The Jakarta status is in the wiki at:
http://wiki.apache.org/jakarta/Migrating_20to_20Subversion
The aim would be for all the tomcat modules to migrate into
asf/repos/jakarta/tomcat/ so that we can have a cleaner top-level
structure to the system, within that though the Tomcat community are
free to choose whatever strategy fits.
I've intentionally left Tomcat until last to nudge about this so as to
build up some experience within Jakarta of dealing with SVN as users
and as a migration. Some of you are probably already getting to grips
with svn following the Commons migration.
Just to provide the context for this, the Infra group are looking to
move from CVS to SVN in the long term and Jakarta were far and away
the main laggards in this. In the last month or so, a third of Jakarta
has moved over, so that's now improving.
Another question is whether the Tomcat community have any svn
expertise in terms of planning svn strategies, or whether we should
try to find some other committers to offer opinions.
Thanks,
Hen

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

Re: DO NOT REPLY [Bug 33339] - Shutdown script down not work

[Costin Manolache]

[EMAIL PROTECTED] wrote:
3) Cygwin is definatley NOT a good platform for testing Linux bugs on.
However testing with all possible linux distributions is not a good 
choice either.

And distributions based on 'latest' version of everything plus all kind 
of experimental/non stable/vendor specific stuff -  like fedora - are 
not the best choice for a supported platform.

Can you reproduce it on RHEL or RH9 ?  If not - report the bug on fedora.
4) Do you want to tell the Fedora guys that the Tomcat developers
official view of Fedora Core 2 is that its' a crappy distro?
It is not 'official view' - but some developers have issues with FC :-)

5) Do you expect me to re-install my system just to get Tomcat working?,
It's easier to replace Tomcat with Jetty than it would be to resintall
my machine with one of the distros that you don't consider crappy
I believe a lot of products ( and not only java ) officially support 
only few distributions. We can't ask you to re-install your system - but 
you can't ask us to reinstall and test your favorite distro either. 
There are just too many incompatible linux distributions.

If jetty works on your linux distro - just use it. It's a fine open 
source product. Or you can use resin or any other server.


Now I'd like to help resolve this, but at the moment all I'm seeing is a
wall of not interesting, can't be bothered, lets' mark it as invalid
because I can't reproduce on my own personal setup. Which kinda
Probably the comments should be more explicit - like 'unsupported 
platform / not reproductible on supported platforms '.

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

Re: DO NOT REPLY [Bug 33339] - Shutdown script down not work

[Costin Manolache]

Well, if you can debug this and find the real cause and a fix - I'm sure
someone will look at it.
But please understand that Remy and the other tomcat developers deal 
with a lot of bugs, and usually it's frustrating to deal with bugs that 
happen only on certain situations. If Java code behaves correctly on 
most platforms - but it doesn't work on few distributions - you may as 
well report this as a bug to either Sun or the distribution. BTW, we are 
engineers, not PR people - so 'crappy' comments may happen :-)

So if you have a patch or workaround - please reopen the bug and add the 
fix. It would be a better way to spend the time instead of arguing about 
closing/not closing it or hurt feelings :-)

Costin
Al Sutton wrote:
In answer to your points;
on 3) I'm not asking for it tested on all distros, just those where issues
have arisen. If no-one has FC2 installed then thats something the group
should know about and should be able to say Sorry, no-one has FC2, rather
than Closed bug, doesn't work on [insert name of totally different platform
here].
The users mail list has a report from Drew Jorgenson if it not working on
RHAS 3, and I can confirm I've also seen the behaviour on SLES8 (i.e. a
non-redhat product), so I don't think it's distribution specific.
on 4) It's never good to write that any other groups efforts off as crappy,
I'm sure this group wouldn't be happy if the Fedora group described Tomcat
as crappy. We're all doing our best (yes, I have released some open source
code in the past), and it worried me that the crappy comment was made and
no-one else stepped in to be a bit more helpful.
on 5) Given your response I'm happy to offer help with FC2 related problems.
I wasn't willing to make this offer before because it seemed the only
responses I had were aimed more at getting the bug marked as closed than
investigating where the problem was. I'll keep an eye on the -dev list (but
unfortunatley I don't have time to look at all the bug report comments) and
if I see a problem with FC2 I will attempt to dupluicate it. In case your
wondering what my experience is I've been a Linux sys admin for 11 years,
and have been programming system in Java for about 8 years with the last 5
spent focused on developing high performance server side applications for
Teleco's and Financial institutions, which hopefully will allow me to assist
in some way.
on the last paragraph - I completely agree. If people know which platforms
are fully supported (i.e. if bugs are reported someone can test them
easilly) it will make life a lot easier. You'll probably find that in return
for listing a platform as full supported the distributor may be receptive to
including Tomcat in their product.
Costin, I'd like to thank you for the sending the first comprehensive
response which makes me feel that users bugs are taken seriously, and not
treated as something that should be closed at any costs.
Regards,
Al.
-Original Message-
From: news [mailto:[EMAIL PROTECTED] Behalf Of Costin Manolache
Sent: 02 February 2005 21:22
To: tomcat-dev@jakarta.apache.org
Subject: Re: DO NOT REPLY [Bug 9] - Shutdown script down not work
[EMAIL PROTECTED] wrote:

3) Cygwin is definatley NOT a good platform for testing Linux bugs on.

However testing with all possible linux distributions is not a good
choice either.
And distributions based on 'latest' version of everything plus all kind
of experimental/non stable/vendor specific stuff -  like fedora - are
not the best choice for a supported platform.
Can you reproduce it on RHEL or RH9 ?  If not - report the bug on fedora.

4) Do you want to tell the Fedora guys that the Tomcat developers
official view of Fedora Core 2 is that its' a crappy distro?

It is not 'official view' - but some developers have issues with FC :-)

5) Do you expect me to re-install my system just to get Tomcat working?,
It's easier to replace Tomcat with Jetty than it would be to resintall
my machine with one of the distros that you don't consider crappy

I believe a lot of products ( and not only java ) officially support
only few distributions. We can't ask you to re-install your system - but
you can't ask us to reinstall and test your favorite distro either.
There are just too many incompatible linux distributions.
If jetty works on your linux distro - just use it. It's a fine open
source product. Or you can use resin or any other server.

Now I'd like to help resolve this, but at the moment all I'm seeing is a
wall of not interesting, can't be bothered, lets' mark it as invalid
because I can't reproduce on my own personal setup. Which kinda

Probably the comments should be more explicit - like 'unsupported
platform / not reproductible on supported platforms '.
Costin
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e

Re: Postcard

[Costin Manolache]

Remy Maucherat wrote:
Allistair Crossley wrote:
*rotfl* that's not Remy at all! ;)

Those viruses are annoying, since I cannot prevent them from reaching 
the list :( As long as they use a valid subscriber's address, I cannot 
do anything. I suppose it would be caught by a spam filter though.

Rmy
Maybe a solution would be to subscribe from an address that uses SPF - 
apache checks for SPF, so it'll reject it.

I don't like SPF for many resons, but it does have its benfits :-)
Gmail.com does spf btw.
Costin
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: mod_jk jni worker - apache + number of processes

[Costin Manolache]

The only way to do in-process with apache on unix is to use a 
multithreaded MPM and a small number of processes ( and lots of 
threads). JNI is not much more efficient than IPC - or at least not
in the simplistic use. Even the applets in mozilla/konqueror/etc run out 
of process on unix ( but in-process on win and macosx ).

Writting apache modules in java has been attempted before - 
unfortunately it never quite worked, and the multiprocess issue is just 
one of the problems.

Costin
Fox,Tim wrote:
Hi Mladen -
Thanks for your reply.
I suspected as much.
My real motivation here is to basically provide a java implementation of an 
apache module or filter. I didn't want to communicate via sockets or whatever 
to a shared java process due to performance considerations.
Especially for doing stuff like setting the apache uri or filename via the 
request_rec, I thought that this would incur too much overhead.
I'm guessing this is something that has been considered before. Any ideas? 
Maybe it's already been discounted for these reasons?
Anyway, I guess this is turning into an Apache httpd question rather than a 
tomcat one! :)

-Original Message-
From: Mladen Turk [mailto:[EMAIL PROTECTED]
Sent: 18 January 2005 12:43
To: Tomcat Developers List
Subject: Re: mod_jk jni worker - apache + number of processes
Fox,Tim wrote:
Hi All-
Apologies for cross-posting from the user group - but in 
retrospect I believe this might be a better forum for this question:
I am interesting in using the in processes jni_worker with 
apache 2.0 on linux.
My question concerns the number of instances of a jvm, and 
hence tomcat that will be created.
My understanding is that, on linux the default mpm 
configuration will have multiple child server processes created.
Does that mean there will be multiple jvms and hence 
multiple tomcat instances instantiated? Or is the jvm somehow 
shared across processes?

You listed all the problems JNI connector faces on Linux, and also the
facts why JNI is unusable.

Is it a requirement of using the jni worker that the number 
of child server processes is limited to 1 in the apache config?
I would suggest that you forgot all about inprocess JNI on any
unix variant with Apache, or better all together.
Even the stupid .NET has a separate process out of IIS.
Mladen.
-
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: [APR-JAVA] cvs upload

[Costin Manolache]

To be honest, I don't like where this is going. I think access to native
functionality for tomcat is great - and starting with functionality 
provided by apr is ok. But there is a lot outside apr, and if this 
becomes 'apr - java interface', it won't be easy to add.

So maybe it would be better to rename it to org.apache.tomcat.jni or 
something, keep the apr stuff as 'tomcat interface with apr' ( with a 
comment that when/if apr does have an official binding - we can switch), 
and keep it open for the other non-apr stuff that may be interesting.

Costin
William A. Rowe, Jr. wrote:
At 01:56 PM 1/13/2005, Mladen Turk wrote:
William A. Rowe, Jr. wrote:
org.apache.apr... ???
If this is private, and you've suggested it should be, don't you mean
org.apache.jakarta.apr... ?
He he :)
I didn't said it should be private to J-T-C nor Jakarta.
But the fact is that we don't have OO languages infrastructure
for APR glue code. Seems to me that we'll need to go through
incubation to create self standing apr-java project, or
something like apr-oo/java.

Self standing?  If apr is borked (and the oo-dev'ers prove it)
do you want another layer in the middle?  This probably should
be closely paired to apr to ensure communications and direction.
Having them both under the same pmc ensures that the apr project
doesn't go off on some weird tangent that interferes with oo 
implementations (not that I expect this would happen.)


If you think we can make something like that in a reasonable
amount of time, count me in.

Happy to encourage it and I'll present it (with myself as a
list moderator) to the apr project, and invite our modperl
friends along with John Sterling and others who have created
C++ wrappers.

In other case I can rename the package to whatever name desired
if it breaks some policy or something like.

This sort of surprises me coming from an ASF java developer.
I seriously doubt this team would find it amusing to discover
org.apache.catalina namespaces populating an xml project's code.
-1 on appropriating another ASF project's namespace (the same -1 
I should have offered to forking proxy.) +/-0 if you want to build
on org.apache.jk.apr namespace.

Bill

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

Re: Deprecation and JK2

[Costin Manolache]

A lot of the code is actually specific to the now-dead Jk2 - if the 
native jk2 is gone, probably you should clean up this side as well.

- org.apache.jk.apr - the not-quite apr jni layer that connects to the 
native objects, as well as 'in-process' launcher ( I doubt it can be 
used by jk1.x ), also common.JniHandler

- ChannelJni, ChannelShm, ChannelUn, Shm - specific to jk2.
Maybe it would be a good idea to rename the remaining files ( but please 
not org.apache.ajp - it would be confusing since this is the name of the 
very old connector package ).

What is the story with in-process ? Is it still supported with jk1.x ?
Costin
Remy Maucherat wrote:
Henri Gomez wrote:
+0
JK / JK2 are also very specific to our current AJP implemtation.
Maybe they should be called AJP instead ?

I thouhgt I had done enough damage with my package renaming and class 
moving ;)
The renaming here is nearly all located in strings which are supposed to 
be displayed to the user when there's an error, and also in comments - 
low impact stuff.

PS: Happy New Year to all TC-DEV members :)

Rémy

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

Re: Deprecation and JK2

[Costin Manolache]

Bill Barker wrote:
- Original Message -
From: Costin Manolache [EMAIL PROTECTED]
To: tomcat-dev@jakarta.apache.org
Sent: Wednesday, January 12, 2005 4:14 AM
Subject: Re: Deprecation and JK2

A lot of the code is actually specific to the now-dead Jk2 - if the
native jk2 is gone, probably you should clean up this side as well.
- org.apache.jk.apr - the not-quite apr jni layer that connects to the
native objects, as well as 'in-process' launcher ( I doubt it can be
used by jk1.x ), also common.JniHandler
- ChannelJni, ChannelShm, ChannelUn, Shm - specific to jk2.

I think that proxy_ajp is hoping to be able to use ChannelUn someday.  It's
no more Jk2 specific than ChannelSocket is.
It is using the jk2 'object' - it can be easily rewritten to use the new 
apr library directly, but in the current form I don't see how it could 
be used without jk2 native  (and if you want to add it - it's easier to 
start from channelSocket ).




Maybe it would be a good idea to rename the remaining files ( but please
not org.apache.ajp - it would be confusing since this is the name of the
very old connector package ).
What is the story with in-process ? Is it still supported with jk1.x ?

Only the (very) old 3.3 JniHandler at the moment.
Maybe the new apr library will help improve this too.
BTW, starting in-process java in jdk1.5 ( on linux at least ) it's 
amazing, no longer requires LD_LIBRARY_PATHs and seem to 'just work'.

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

Re: [INTRODUCE] apr-java

[Costin Manolache]

Mladen Turk wrote:
Hi,
Here is the work in progress for a new project I named apr-java.
It offers a 'thin' layer using JNI over APR library.
The initial code that I wrote over a year now had
two way api, but I've decided to leave only
Java-APR.
I also have a working set of configure and make files
for unixes, but since this is an overview of the technology,
it's only a small subset of entire project, but you can get
the picture :) .
It will support around 90% of APR API (without things like
strings, etc. that are well done inside java itself).
The API itself on the Java side is done as close to the
APR function call (apr_file_write - File.write) with
almost the same function parameters as well.
You can see that the wrapping code is very thin in most
cases with only a couple of lines for each function,
mostly caused by pointer issues.
I'm sending the gz file (tried zip but failed) so you can see
what the general idea is. Of course the library can be extended
with functions that APR doesn't offer (for now or never will).
One of the things would be setting user and group for a process,
sending data from parent to child process, etc.
The question is:
Is it acceptable (think that previous discussions say it is)
Where to put that in the cvs.
Comments?
Looks good.
It seems it still does a lot of String operations in native - unlike SWT 
for example, where it's almost always byte[]. Also the typical memcpy, 
etc should be included somewhere to allow data to move from/to the pool 
and java heap.

Why not checking it in j-t-c ?
Just to make sure - you expect it to also have non-apr native methods ?
Costin
-
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/util CharsetMapper.java

[Costin Manolache]

Remy Maucherat wrote:
Costin Manolache wrote:
Maybe:
* @author Jason Hunter, as part of the book Java Servlet Programming
* (O'Reilly). See a href=http://www.servlets.com/book;
* http://www.servlets.com/book/a for more information.
?
I think it is fair to respect the author wish for attribution.
Given that the board recomends against @author tags and they may be 
someday removed, it doesn't matter that much...

I am all in favor of giving proper attribution (author tags), but -1 on 
anything which restricts the ASF's copyright on the code (like 
advertising clauses in this case).

As a result, I have to agree with all that pointed out that the code 
should be rewritten (in this case, the encoding list must be 
reconstructed from scratch).

Rémy
There is no advertising clause in this. He made it clear that the code 
is donated to ASF, under ASF license. Mentioning that the author 
developed the code while working on a book or while being paid by a 
company can't be that bad.

I don't understand why ASF is so advertising-fobic when it comes to 
authors or companies that donate code or employee time to ASF, but until 
recently strictly required advertisment for the code owner ( ASF ) not 
only in the code, but also on the web site.


Costin

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

Re: IP issues

[Costin Manolache]

Jason Hunter wrote:
nor see why we need an exception for such a such a small amount of code.

You need an exception because (a) the code was included from a third 
party codebase and (b) a lot of research and testing went into compiling 
the map used by the mapper.

I can easily add an @author tag for you in the relevant files, but the 
comment currently creates a legal doubt.

As I wrote in my email and for the archived record, I want the classes 
to have the recognition that is expected when Apache includes code from 
a third party library that's under a license that requires attribution 
(just like Apache's).

The files says copyright ASF - but it seems that's not completely 
accurate ( I assume someone mistakenly removed your Copyright Jason 
Hunder ? ).

As an author, you should be able to keep any notice that you consider 
apropriate. If you didn't explicitely assign the coypright to ASF ( or 
to Sun ), than I don't think it would be right for anyone to remove your 
name or attribution.

If you did assign the rights to ASF - then as you know anything can be 
removed or changed by the new owner, including @author tags or any 
mention of previous author ( just make sure your name does gets into 
whatever obscure file lists all people who contributed something ) :-)


Note: Many companies and individuals donated more than these 10 lines 
of code, 


Yes, and I too donated plenty of code to the Tomcat codebase.  But these 
classes I donated (to Sun at the time) with attribution because they 
were from a separate, pre-existing codebase with a life of its own.

If you write a book and include a paragraph from someone else's book 
with permission, you mention it and you point at the source of the 
original work.  You don't just say, Written by author X you say, 
Written by author X as part of book Y, published by Z.  That's why the 
attribution I put on those classes includes the who, what, and where.  I 
see it as the ethical thing to do.
I fully agree. Doesn't matter how small a contribution is ( or looks at 
some later time ), keeping the reference to the author and whatever else 
the author wants to include is the right thing to do ( if the code is 
accepted and used ).

Too bad what's ethical doesn't matter that much, only copyrights and IP 
ownership  :-)


Costin
-
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/util CharsetMapper.java

[Costin Manolache]

Maybe:
* @author Jason Hunter, as part of the book Java Servlet Programming
* (O'Reilly). See a href=http://www.servlets.com/book;
* http://www.servlets.com/book/a for more information.
?
I think it is fair to respect the author wish for attribution.
Given that the board recomends against @author tags and they may be 
someday removed, it doesn't matter that much...

Costin
[EMAIL PROTECTED] wrote:
remm2005/01/04 14:14:42
  Modified:util/java/org/apache/tomcat/util/http
LocaleToCharsetMap.java
   catalina/src/share/org/apache/catalina/util
CharsetMapper.java
  Log:
  - Remove legally questionable comment. The code was properly donated to the ASF.
  
  Revision  ChangesPath
  1.3   +2 -14 jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/http/LocaleToCharsetMap.java
  
  Index: LocaleToCharsetMap.java
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/http/LocaleToCharsetMap.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- LocaleToCharsetMap.java	24 Feb 2004 08:50:04 -	1.2
  +++ LocaleToCharsetMap.java	4 Jan 2005 22:14:42 -	1.3
  @@ -14,15 +14,6 @@
*  limitations under the License.
*/
   
  -/*
  - *
  - * This class was originally written by Jason Hunter [EMAIL PROTECTED]
  - * as part of the book Java Servlet Programming (O'Reilly).  
  - * See http://www.servlets.com/book for more information.
  - * Used by Sun Microsystems with permission.
  - *
  - */
  -
   package org.apache.tomcat.util.http;
   
   import java.util.*;
  @@ -30,11 +21,8 @@
   /** 
* A mapping to determine the (somewhat arbitrarily) preferred charset for 
* a given locale.  Supports all locales recognized in JDK 1.1.
  - * This class was originally written by Jason Hunter [EMAIL PROTECTED]
  - * as part of the book Java Servlet Programming (O'Reilly).
  - * See a href=http://www.servlets.com/book;
  - * http://www.servlets.com/book/a for more information.
  - * Used by Sun Microsystems with permission.
  + * 
  + * @author Jason Hunter
*/
   public class LocaleToCharsetMap {
   
  
  
  
  1.5   +2 -8  jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/util/CharsetMapper.java
  
  Index: CharsetMapper.java
  ===
  RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/util/CharsetMapper.java,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- CharsetMapper.java	29 Aug 2004 16:46:13 -	1.4
  +++ CharsetMapper.java	4 Jan 2005 22:14:42 -	1.5
  @@ -14,13 +14,6 @@
* limitations under the License.
*/
   
  -/*
  - * This class is based on a class originally written by Jason Hunter
  - * [EMAIL PROTECTED] as part of the book Java Servlet Programming
  - * (O'Reilly).  See http://www.servlets.com/book for more information.
  - * Used by Sun Microsystems with permission.
  - */
  -
   package org.apache.catalina.util;
   
   
  @@ -38,6 +31,7 @@
* it loads, or by subclassing it (to change the algorithm) and then using
* your own version for a particular web application.
*
  + * @author Jason Hunter
* @author Craig R. McClanahan
* @version $Date$ $Version$
*/

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

Re: adding features to Status servlet

[Costin Manolache]

Why don't you check in some of this to j-t-c or some 'proposal' area ?
AFAIK apr has a lot of functionality, but not everything is included.
It would be nice if it is not limited to apr.
Usually with JNI the hardest part is to build, distribute and then set 
it up and debug ld_library_path issues. If you do it for one library, 
it's easy to add more.

Costin
Mladen Turk wrote:
Peter Lin wrote:
that sounds great. does it have support for sysinfo?  if it does, I'll
try using your apr-java package.
No, but it's up to us to decide what will go inside.
APR is included, but I wish to leave that as open as
it could be.
It already have win32.c,unix.c and netware.c files
for platform specific stuff that APR doesn't offer.
Having sysinfo sounds good to me. WIN32 has also good
performance data gathering, and I'm sure that Netware has
them too.
I also wish to include the OS specific things from
httpd like setting group, user, sending data to child
process, etc...
What matters is that we'll have a generic native component,
with well defined build and distribution specification.
Mladen.

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

Re: adding features to Status servlet

[Costin Manolache]

Benson Margulies wrote:
For systems with a /proc file system with these statistics, this doesn't
require any JNI ... 
Yes, there are a lot of ways to workaround java limitations. /proc is 
one. But even on linux, a lot is not exposed via /proc, but ioctl.
I guess the goal is not to implement sysinfo, but have a way to get more
platform-specific information and access platform-specific features.

Costin

-Original Message-
From: Peter Lin [mailto:[EMAIL PROTECTED] 
Sent: Monday, January 03, 2005 10:04 AM
To: Tomcat Developers List
Subject: Re: adding features to Status servlet

sysinfo on unix/linux should be pretty easy. I've used windows
performance stats before when i tried to write the equivalent of the
status servlet for IIS. I will try to write an exe named sysinfo that
spits out similar performance stats.
how can I help mladen?
peter

On Mon, 03 Jan 2005 15:55:44 +0100, Mladen Turk [EMAIL PROTECTED]
wrote:
Peter Lin wrote:
that sounds great. does it have support for sysinfo?  if it does, 
I'll try using your apr-java package.

No, but it's up to us to decide what will go inside.
APR is included, but I wish to leave that as open as it could be.
It already have win32.c,unix.c and netware.c files for platform 
specific stuff that APR doesn't offer.
Having sysinfo sounds good to me. WIN32 has also good performance data

gathering, and I'm sure that Netware has them too.
I also wish to include the OS specific things from httpd like setting 
group, user, sending data to child process, etc...

What matters is that we'll have a generic native component, with well 
defined build and distribution specification.

Mladen.
-
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]

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

Re: adding features to Status servlet

[Costin Manolache]

Or:
1. Wait for Mladen to check in the code
2. figure out how to build it and how to install it easily in tomcat ( 
and other java applications ).
3. probably add one native method. I don't think wrapping it as apr 
component makes sense ( apr is not a component system like xpcom ).
4. write the java mbean - using the native method and making all 
conversions between the native signature and java style ( if SWT-style
of jni is used - i.e. using byte[], int pointers, etc - and doing java 
adaptation in java ).

I'm as curious as you are to see the code and figure out how it can be 
used, I love jni :-)

Costin
Peter Lin wrote:
So which way would be best/better to proceed?  Since mladen has his
apr-java stuff, would it make sense to do this?
1. write native windows dll
2. write apr component
3. use apr-java to wrap apr
4. wrap apr-java with mbeans
or
1. write apr component to call system level API
2. use apr-java to wrap apr
3. wrap apr-java with mbeans
or
something completely different?
peter
On Mon, 03 Jan 2005 11:21:55 -0800, Costin Manolache
[EMAIL PROTECTED] wrote:
Benson Margulies wrote:
For systems with a /proc file system with these statistics, this doesn't
require any JNI ...
Yes, there are a lot of ways to workaround java limitations. /proc is
one. But even on linux, a lot is not exposed via /proc, but ioctl.
I guess the goal is not to implement sysinfo, but have a way to get more
platform-specific information and access platform-specific features.
Costin

-Original Message-
From: Peter Lin [mailto:[EMAIL PROTECTED]
Sent: Monday, January 03, 2005 10:04 AM
To: Tomcat Developers List
Subject: Re: adding features to Status servlet
sysinfo on unix/linux should be pretty easy. I've used windows
performance stats before when i tried to write the equivalent of the
status servlet for IIS. I will try to write an exe named sysinfo that
spits out similar performance stats.
how can I help mladen?
peter

On Mon, 03 Jan 2005 15:55:44 +0100, Mladen Turk [EMAIL PROTECTED]
wrote:

Peter Lin wrote:

that sounds great. does it have support for sysinfo?  if it does,
I'll try using your apr-java package.
No, but it's up to us to decide what will go inside.
APR is included, but I wish to leave that as open as it could be.
It already have win32.c,unix.c and netware.c files for platform
specific stuff that APR doesn't offer.
Having sysinfo sounds good to me. WIN32 has also good performance data

gathering, and I'm sure that Netware has them too.
I also wish to include the OS specific things from httpd like setting
group, user, sending data to child process, etc...
What matters is that we'll have a generic native component, with well
defined build and distribution specification.
Mladen.
-
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]
-
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: adding features to Status servlet

[Costin Manolache]

Mladen Turk wrote:
Peter Lin wrote:
I'm thinking of adding system load stats to the status servlet. What
do other's think about it? It would use JNI to call a native lib and
it would only work on unix, but it would be good to have.

Well, I'm working over a year now on a project that I've called
apr-java. This is a thin (for now) wrapper around apr and apr-utils,
so it will be supported on all platforms the apr is.
Things like true shared memory, process mutexes, advanced networking,
pipes, etc. that are missing from the core Java will be supported.
Usages are many, like writing high-performance networking connector
for Tomcat, making Tomcat a Apache mpm-like server with multiple
JVMs, etc...
I hope I'll have a working start point this month, so we could discuss
is it worth the effort at all, would it fit inside JTC, commons, or
to go trough apache incubation as a separate project.
Mladen.
Anything that allows Java to do things only native apps can do instead 
of beeing as dumb as the dumbest platform is worth the effort :-)

JTC already has some apr and jni code ( it is true, using the dead jk2 
model ), why not start there and if it grows big enough move to commons?

BTW - it would be really great if it would use the SWT model, i.e. JNI 
methods matching exactly the APR signatures and param types, with 
minimal ammount of C wrapper code. It works really well, and it's the 
easiest to maintain and fastest of all JNI flavors I've seen.

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

Re: adding features to Status servlet

[Costin Manolache]

Peter Lin wrote:
I'm thinking of adding system load stats to the status servlet. What
do other's think about it? It would use JNI to call a native lib and
it would only work on unix, but it would be good to have. I would also
update JMeter in the process to display the system load average.
peter lin
Wouldn't be better to have a way to display an arbitrary mbean 
attribute, plus an mbean tracking system load ( and maybe memory/disk 
statistics ) ?

Dealing with jni is allways tricky ( including build issues, etc ) - it
is better to have it in separate modules.
Costin
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: adding features to Status servlet

[Costin Manolache]

As implementation - I assume you weren't going to add a native
method and a .so library to the standalone tomcat distribution :-)
Adding capability to StatusServlet to report arbitrary mbean attributes
would make this feature easy to add ( there is some code in 
JmxProxyServlet - but it it would be much better if integrated and made 
consistent with the status servlet ).

For the JNI + mbean implementation - it may be better to use a separate 
component ( I don't see why it would be specific in any way to tomcat - 
any jmx-based app could use this ). There are several other OS-specific
informations of interest ( including in Windows ), JMX is designed 
exactly for this - to expose management info for different systems.

Costin
Peter Lin wrote:
that's why I decided it was a good idea to ask for other's thoughts.
From a stress testing perspective, I find system load stats very
valuable. breaking tomcat isn't something I find desirable either, but
there has to be a better way to measure system load other than ssh
into the server and use top.
manually doing top or sysinfo is fine for load testing, but for
performance monitoring, something automated is desirable. My thought
was to make it optional and have it detect whether or not a native lib
for that platform exists. If it doesn't it would affect the status
servlet and would look exactly the same as it does now.
on the otherhand, if the user enables it and a native lib exists, it
could display the system load. the only other option is to lobby Sun
to add system load stats to the VM, so that it is portable across
platforms.
peter
On Fri, 31 Dec 2004 17:27:03 -0500, Frank W. Zammetti
[EMAIL PROTECTED] wrote:
I would personally have some reservations about doing this... It's a
little better if it's a module you can activate and deactivate, but still...
First, if it's not something you can do cross-platform, I'm not sure I'd
like it.  AFAIK Tomcat is nicely cross-platform now, anything that
breaks that wouldn't be good I think.  I understand this would be an
optional component (right?), so it wouldn't actually be *breaking*
anything, but the expectation I think is that anything in Tomcat works
on all platforms, so would it be a good thing to introduce something
that doesn't fit that mold?
Second, and more importantly, it doesn't feel right to me to expose this
type of information through an app server.  Your talking about
statistics that aren't truly related to the app server, although is
certainly affected by the app server, so it's debatable whether they
should be there or not.  I agree this is useful information to have
access to, but I'm not sure it'd be the right place for it.
Have you considered maybe making this part of some Commons package?
Make it something that any app could make use of, that might be a very
nice thing.  Heck, it might be somewhere in there already for all I know.
Just my thoughts on it anyway.
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
Peter Lin wrote:
it could be a separate module. It definitely should use MBean. In
terms of getting the CPU load stats, I was thinking of calling the
standard sysinfo loads[].
Is there some other way of getting the system load stats? or CPU
stats? that doesn't require calling native code?
peter
On Fri, 31 Dec 2004 13:13:54 -0800, Costin Manolache
[EMAIL PROTECTED] wrote:

Peter Lin wrote:

I'm thinking of adding system load stats to the status servlet. What
do other's think about it? It would use JNI to call a native lib and
it would only work on unix, but it would be good to have. I would also
update JMeter in the process to display the system load average.
peter lin
Wouldn't be better to have a way to display an arbitrary mbean
attribute, plus an mbean tracking system load ( and maybe memory/disk
statistics ) ?
Dealing with jni is allways tricky ( including build issues, etc ) - it
is better to have it in separate modules.
Costin
-
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]



-
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-connectors/jk/native/common jk_ajp13_worker.c

[Costin Manolache]

Mladen Turk wrote:
jean-frederic clere wrote:
Mladen Turk wrote:
Costin Manolache wrote:
Are you joking :-) ?

If we can not alloc couple of bytes from the system, then the
entire system is unstable.

Or that the process that makes the malloc() has reached a configurable 
limit of the amount of memory it is allowed to use.


Sure, but the system is still unusable.
This checking is done inside worker_factory, called from init_jk,
so IMHO the apache will fail long before.
But if everyone thinks it's a good to check for failed memory
allocation on small objects, I'll revert the patch.
Well, I see your point - probably it doesn't matter much, I'm sure other 
places in code will not check and it would crash anyway. Most OSes use 
swap, so the system will trash and become unuseable before running out 
of memory. But there are other cases where the swap is not used - and 
then malloc failure is a common condition under load.

If the system is very loaded, it is possible you'll run low on memory 
and you don't know which malloc will fail - maybe the small one. The 
correct behavior would be to give up and return a 500 on the request ( 
that may go through since apache probably already have the memory 
allocated in the memory pools ). On single process/multithread systesm, 
an apache server crashing under load is not a good thing :-)

IMO all mallocs should be checked - but probably I spend too much time 
with systems with very little memory where a crash is not such a good 
thing :-)

Costin
Costin



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

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

[Costin Manolache]

Mladen Turk wrote:
David Rees wrote:
Are you sure it's a good idea to wait until it crashes rather than 
fail in a controlled method?  How much overhead is there to check 
aw-name for NULL?  Can't be much...

Yes I am.
Look, if the system can not alloc 1000 bytes of memory what's
the purpose to continue?
Mt.
Are you joking :-) ?
At least do an printf and exit(), coredump is never good  (some systems 
don't collect the core - so the user will have no idea what just 
happened ).

Costin
-
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/connector RequestFacade.java LocalStrings.properties

[Costin Manolache]

Remy Maucherat wrote:
Jan Luehe wrote:
Bill Barker wrote:
 

In the case I was referring to, some project was storing a
servlet request (facade) in a ThreadLocal and, due to a bug in their
code, was hanging on to it beyond the request's lifetime. This was
happening only under rare circumstances.
 

Great use case. And the talented programmer who coded that thing 
couldn't figure out what the problem was quickly enough without a proper 
error message, I assume ;)

So in this case, the Request behind the facade was indeed null.
 

So now he'll get an error message saying null request. Actually, it 
sounds like one of these useless M$ error messages.

Lol and +1 for Bill's suggestion to change text to if you're reading 
this, you're a moron :D
As long as the exception doesn't get into the web browser of some user :-)

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

Re: contrib directory

[Costin Manolache]

Garrison, Meg wrote:
Hi Leslie,
I'm also willing to maintain the HP OpenVMS scripts.  Rather than create
a whole new project (tomcat-contrib) maybe it would be possible for the
Tomcat folks to grant us commit access to a single module/folder in
their CVS library (a contrib folder of some sort).  Then they wouldn't
have to worry about committing our changes, etc..  If we misbehave and
don't follow their rules, then they have the option to boot us out.
That's how the NetBeans project does it.  For example, I have commit
powers in the core module, which is where the OpenVMS launcher lives,
but no other.  Our needs for NetBeans (as yours, I'm sure) require that
the default Tomcat distribution contain our launcher somewhere...it
doesn't have to be in /bin.
It would be a good idea, but I don't think it is possible at the moment.
Commit access requires a unix account on a machine, at least for cvs. 
Even if this could be solved - there are non-technical problems, ASF 
requires a CLA, and a certain review and oversight process.

Ant has an ant-contrib project on sourceforge ( including few ant 
committers ). Maybe we should have a tomcat-contrib as well. This would
be a good idea even for committers - there is experimental stuff and 
code that is not necesarily servlet container but is tomcat related (
like non-http servers, etc ).


Costin

Any other ideas?
Meg 

-Original Message-
From: Leslie Kishalmi [mailto:[EMAIL PROTECTED] 
Sent: Friday, October 29, 2004 5:29 PM
To: Shapira, Yoav
Cc: Tomcat Developers List; Garrison, Meg
Subject: Re: contrib directory

Dear all,
  I'm willing to spend some of my limited free time to collect, organize
and maintain these contributed code.
However, it is very unlikely that I would be ever a committer on this
project with my OS/2 launchers.
So, as Yoav said, we could find an other committer. Or we could create
an other project something like tomcat-contrib where we maintain our
code.
Best regards,
Leslie Kishalmi
Shapira, Yoav wrote:

Hi,
Yeah, it's gone for now.  The reason is that the maintenance aspect is 
too hard for the long term.  While I don't doubt the quality of you (or

anyone else's) work, nothing is perfect.  It is inevitable that the 
scripts will need work.  Even if you stay on top of it and keep 
submitting patches, someone will have to keep checking for them and 
applying them.

I'm not interested in doing that work, and other committers apparently 
aren't interested enough to even comment on what an appropriate place 
in CVS might be for these contributions. So I took them out for now.

That's not to say they're gone forever.  I can see a couple of possible

solutions, and that's why I'm doing this thread on tomcat-dev as 
opposed to just replying to you personally.

One approach is what I'm doing now: contributed stuff is owned by 
authors (like you) who post it wherever they want (hp.com, personal web

sites, whatever), and we link to it from our FAQ and/or wiki pages.
This approach solves the long-term maintenance concerns.
If this was a one-time effort, I would have done it and we'd be all set

by now.  But it's not, and I just don't have the bandwidth to work it 
;( Another approach is for someone else with commit privileges to say 
they're interested and do what they think is appropriate.  That can 
happen at any time, I wouldn't stand in their way obviously, as I'm not

principally objecting to these contributions.  I just don't have the 
bandwidth to deal with them at this point.

So this issue is not dead.  It's just not going to be in 5.0.30/5.5.4.
We might also want to raise it on tomcat-user to see if people have 
other creative approaches to solving this.



Are you really going to take the contrib directory out?  I was just 
about to make a contribution to you via PayPal as a thank you...
  

Thank you ;)
Yoav Shapira http://www.yoavshapira.com

This e-mail, including any attachments, is a confidential business
communication, and may contain information that is confidential,
proprietary and/or privileged.  This e-mail is intended only for the
individual(s) to whom it is addressed, and may not be saved, copied,
printed, disclosed or used by anyone else.  If you are not the(an)
intended recipient, please immediately delete this e-mail from your
computer system and notify the sender.  Thank you.



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

Re: contrib directory

[Costin Manolache]

Shapira, Yoav wrote:
Hi,
Another option for now is to setup a SourceForge project for this.  I'd
be glad to link to it from our docs/FAQs/wiki pages.  You (two) could be
its committers, and we could work together to get additional
contributors setup there.
There has to be a critical mass...
It seems there is some mass - if the same idea is mentioned at the same 
time by more people :-)

I think it would be good to have few tomcat committers as project admins 
- at least 3 (the magic number). I volunteer, it seems Yoav is also 
interested - anyone else ?

Costin

Yoav Shapira http://www.yoavshapira.com
 


-Original Message-
From: Garrison, Meg [mailto:[EMAIL PROTECTED]
Sent: Monday, November 01, 2004 9:18 AM
To: Tomcat Developers List
Subject: RE: contrib directory

why not put it in the NetBeans repository where you're already setup?
I'm only setup to commit to the /core module, which is not where the
Tomcat files are found.
Actually, we started out in the direction of contributing our Tomcat
changes to NetBeans, see
http://www.netbeans.org/issues/show_bug.cgi?id=49420
And we contributed patches to NetBeans to start Tomcat on OpenVMS and a
catalina.com to be placed in the tomcat bin directory that NetBeans
ships.  The NetBeans folks told us they'd prefer we make the launcher
contributions to Tomcat, since that's where they belong...which is why
I
opened
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=31499
against Tomcat.
Meg
-Original Message-
From: Shapira, Yoav [mailto:[EMAIL PROTECTED]
Sent: Monday, November 01, 2004 8:53 AM
To: Tomcat Developers List
Subject: RE: contrib directory
Hi,
That actually gave me an idea: why not put it in the NetBeans
repository
where you're already setup?
In Apache, there needs to be a long-demonstrated background of
contributions before getting commit privileges.  We have different
processes in this area than NetBeans and some of the other open-source
collaborations.
Yoav Shapira http://www.yoavshapira.com

-Original Message-
From: Garrison, Meg [mailto:[EMAIL PROTECTED]
Sent: Monday, November 01, 2004 7:03 AM
To: Tomcat Developers List
Subject: RE: contrib directory
Hi Leslie,
I'm also willing to maintain the HP OpenVMS scripts.  Rather than
create
a whole new project (tomcat-contrib) maybe it would be possible for
the
Tomcat folks to grant us commit access to a single module/folder in
their CVS library (a contrib folder of some sort).  Then they wouldn't
have to worry about committing our changes, etc..  If we misbehave and
don't follow their rules, then they have the option to boot us out..
That's how the NetBeans project does it.  For example, I have commit
powers in the core module, which is where the OpenVMS launcher lives,
but no other.  Our needs for NetBeans (as yours, I'm sure) require
that
the default Tomcat distribution contain our launcher somewhere...it
doesn't have to be in /bin.
Any other ideas?
Meg
-Original Message-
From: Leslie Kishalmi [mailto:[EMAIL PROTECTED]
Sent: Friday, October 29, 2004 5:29 PM
To: Shapira, Yoav
Cc: Tomcat Developers List; Garrison, Meg
Subject: Re: contrib directory
Dear all,
I'm willing to spend some of my limited free time to collect,
organize
and maintain these contributed code.
However, it is very unlikely that I would be ever a committer on this
project with my OS/2 launchers.
So, as Yoav said, we could find an other committer. Or we could create
an other project something like tomcat-contrib where we maintain our
code.
Best regards,
Leslie Kishalmi
Shapira, Yoav wrote:

Hi,
Yeah, it's gone for now.  The reason is that the maintenance aspect
is
too hard for the long term.  While I don't doubt the quality of you
(or
anyone else's) work, nothing is perfect.  It is inevitable that the
scripts will need work.  Even if you stay on top of it and keep
submitting patches, someone will have to keep checking for them and
applying them.
I'm not interested in doing that work, and other committers
apparently
aren't interested enough to even comment on what an appropriate place
in CVS might be for these contributions. So I took them out for now..
That's not to say they're gone forever.  I can see a couple of
possible
solutions, and that's why I'm doing this thread on tomcat-dev as
opposed to just replying to you personally.
One approach is what I'm doing now: contributed stuff is owned by
authors (like you) who post it wherever they want (hp.com, personal
web
sites, whatever), and we link to it from our FAQ and/or wiki pages.
This approach solves the long-term maintenance concerns.
If this was a one-time effort, I would have done it and we'd be all
set
by now.  But it's not, and I just don't have the bandwidth to work it
;( Another approach is for someone else with commit privileges to say
they're interested and do what they think is appropriate.  That can
happen at any time, I wouldn't stand in their way obviously, as I'm
not
principally objecting to these contributions.  I just don't have the

Re: [VOTE] 5.5.3 Stability Rating

[Costin Manolache]

Remy Maucherat wrote:
- Allowing pluggability for commons-modeler
Can you elaborate a bit more on this ? The basic functionality of 
modeler is to take an object and a descriptor and return an mbean.
This can be made pluggable - a simple interface with a single method is
probably enough to hide most of modeler's logic. But all the descriptors 
need to be converted.

But what do you want to use instead and how ? Move the mbean descriptors 
to conf/ so it can be replaced with another format ( since this is 
specific to modeler ) ?

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

Re: JK Todo List

[Costin Manolache]

Henri Gomez wrote:
True, in ASF land as in other community, it's the users and
developpers base which make a solution/product successfull or
forgotten.
BTW, jk 1.2.x is allready very stable and should stay like this for now :
- JK 1.2.x is now on bug-fix only mode.
- AJP_PROXY/MOD_PROXY for Apache 2.1.x (built-in)
Should we start a new AJP/JK/whatever connector is another story which
has been debated this summer when we speak about mod_ajp.
We should first be very prudent since users may be puzzled by :
jk 1.2.x, jk 2.x, mod_webapp, ajp_proxy/mod_proxy, anewstufffwecouldimagine.
Since ajp_proxy/mod_proxy devel goes outside jakarta land, httpd-dev
and will be present only in Apache 2.1.x, may be there is a need for a
new piece of code for IIS/DOMINO/Apache1.3 or even Apache 2.x but we
should list the requested features missing in jk 1.2.x
For IIS/Domino - I think having it maintained and developed by apache is 
  a waste. In both mod_jk and mod_jk2 we pay a significant price for 
trying to be multi-server, and it seems clear this is a feature that 
only few people want.

If an external project wants to create an IIS connector based on mod_ajp 
or jk - that's great. But they should do it taking full advantage of 
whatever IIS provides, including consistent config, etc.


I suggest take a look about what was detailed in mod_ajp thread (July
2004) and see if a new consensus could appears.
On Mon, 11 Oct 2004 16:21:44 -0700, Bill Barker [EMAIL PROTECTED] wrote:
- Original Message -
From: Dave Oxley [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Monday, October 11, 2004 3:35 PM
Subject: Re: JK Todo List

So is JK2 dead because of proxy_ajp? Why doesn't JK2 just replace JK?
JK2 is dead because (like mod_webapp before it :), it failed to attract a
community interested in maintaining it.  You might as well ask 'why doesn't
mod_webapp just replace JK?'
There are also technical reasons I think. Like the attempt to object 
oriented C but without using one of the existing solutions. And not 
droping featurea from mod_jk. But you're right - lack of community 
interest was the main problem.

Costin


Dave.

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

This message is intended only for the use of the person(s) listed above as the 
intended recipient(s), and may contain information that is PRIVILEGED and 
CONFIDENTIAL.  If you are not an intended recipient, you may not read, copy, or 
distribute this message or any attachment. If you received this communication in 
error, please notify us immediately by e-mail and then delete all copies of this 
message and any attachments.
In addition you should be aware that ordinary (unencrypted) e-mail sent through the 
Internet is not secure. Do not send confidential or sensitive information, such as 
social security numbers, account numbers, personal identification numbers and 
passwords, to us via ordinary (unencrypted) e-mail.
-
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: JK Todo List

[Costin Manolache]

Henri Gomez wrote:
Well JK using APR will be a good solution for every webservers but Apache 1.3.x.
Apache 2.x came with APR,  IIS, Domino and others should have no
problems to use an external APR library (.so, .dll).
So the remaining question will be shoud we drop Apache 1.3.x support
in future JK 1.2.x or should we start a 'new' APR JK 1.2.x based
implementation ?

Why use APR in mod_jk ?
Support for Apache1.3 is IMO more important than support for IIS. And so 
far, mod_jk seems to work without any apr - and it is in maintainance 
mode, so no major changes should be made.

Costin

On Fri, 08 Oct 2004 16:53:40 -0400, Kurt Miller [EMAIL PROTECTED] wrote:
From: Mladen Turk [EMAIL PROTECTED]
Remy Maucherat wrote:
Over all, I don't, personally, think that it's worth trying to build
on the existing Jk code base.  However, if you have an itch
Well, we deceased JK2, for Apache2.1 we have proxy_ajp.
Until Apache2.1 becomes the only server around the net,
I'll stick with JK for all those not running my preferred
web server :).
Right. However, I think JK 1.2.x needs some level of stability. So APR,
large architectural changes, etc seem bad ideas. Of your list, I think
documentation (yah !) and the Unix sockets backport would be good (if
not too complex), but that's about it. Modifications to the Java side is
something independent.
I think it would rise the stability, but introduce new problems like
building APR, etc.. so you are probably right. We'll see.
I'm not very happy with the integrated APR build in JK2 for Apache
1.3. I did much of the work there and if I had to do it again, I'd
prefer APR to be a build/runtime depend, built separately by the
user first and loaded with LoadFile directive.
With respect to JK, I'd rather not see it get APR'ized. Mostly
so that Apache 1.3 support is kept simple and straightforward.

For the long term, if you would want better support for the other
servers, you can start a 100% APR replacement for JK 1.2 (I think it was
a bit like your mod_ajp) if you want to.
I'm surely do. The IIS6 support is something to chase :).
MT.


-
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: JK Todo List

[Costin Manolache]

Remy Maucherat wrote:
- Backport JNI from JK2 with lots improvements.

I still don't see benefits in JNI as a transport for JK. Only trouble 
(no matter how I look at it, it seems like it would actually make the 
whole system much less robust) and complexity.
Did I miss something ?
I have to agree - for Apache ( even 2  ) the complexity of multiprocess 
is too big and it's not worth it in almost all cases.

But having a jni library to access OS-specific features is not a bad 
idea. For example registry, change UID ( I know c-daemon could do the 
same), unix sockets, etc.

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

Re: JMX Remote connection

[Costin Manolache]

Jess Holle wrote:
In general the same-user, same-machine stuff works great (including with 
Tomcat 5) if you specify

   -Dcom.sun.management.jmxremote
as part of the command line.
Again - remember not everyone is using Sun JDK1.5 implementation.
My understanding is Macs don't have 1.5 yet, neither most other platforms.

This is without any special web app or such.
What I really want to see is a nice bit of code that allows you to fire 
up a JMX RMI connector that:

   * Finds the first free port in a range (e.g. assuming you have a
 number of slave processes, this does not apply to Tomcat as it
 does not have such logic for it AJP port, etc).
   * Support user/password and SSL
   * Does not rely on implementation internals, i.e. requiring Java 5
 is fine, but having hooks into sun.* or MX4J or whatever classes
 is no good
That's not hard to add. You actually need the first free port in the 
range for rmiregistry - or you can use existing rmiregistry if one is 
found.

You need different rmi names - that's easier.
Adding user/pass/ssl is not hard - if someone has the itch it shouldn't 
be a problem. javax.man.remote has all that's needed AFAIK. IF you look 
at jmxremote webapp that I checked in - there is no mx4j or sun code, 
just plain javax.

Costin


--
Jess Holle
Remy Maucherat wrote:
Dominik Drzewiecki wrote:

I couldn't get the attach to process thing to work, though (= 
without a port). Is it supposed to be doable ?


Neither have I (I am talking of tomcat running as Windows service). 
It seems that both processes : tomcat JVM and jconsole JVM have to be 
owned by the same user. Maybe that is the case with you? Hovewer, 
starting tomcat from my system account solves the problem.
For more info see:
http://java.sun.com/j2se/1.5.0/docs/guide/management/jconsole.html

cut
Both jconsole and the application must by executed by the same user 
name. The management and monitoring system uses the operating 
system's file permissions.
/cut

I'm running both with the same usename on Windows, and it doesn't 
work. Since it's Windows and I like to be able to do stuff, I of 
course run with root privileges. Seems to me it would work on Unix, 
but is currently broken on Windows (I use XP pro SP 2), or something. 
Over a TCP port, it works good.

I couldn't find a comprehensive guide on all these nice system 
properties, while there's tons of docs on the new command line commands.

If I use the service, which runs with the SYSTEM account, it of course 
doesn't work any better ;)

Rémy
-
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: [5.5] Todo list

[Costin Manolache]

Remy Maucherat wrote:
Remy Maucherat wrote:
- Decent default java.util.logging configuration

I don't see any sensible configuration given what the standard handlers 
are (limited rotation options, little possibility of avoiding hardcoding 
logfiles paths, etc). Also, the reload operation is not exposed to JMX 
(other operations are exposed, however).

So I'll add a default configuration file from the JRE, where we'll add 
some example catagory names to help users, but that's unfortunately all 
that can be done by default.

Rémy
And some people are using log4j :-)
I just can't live with the 2-line per log and the formated date, and I 
found no way to change this  ( except writting my own formatter ).


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

Re: loader

[Costin Manolache]

Mladen Turk wrote:
Costin, can you elabborate the purpose of the patch?
Perhaps I've missed few discussions.
There are few goals:
- allow tomcat components ( connector, valves, etc ) to be 
added/removed/upgraded dynamically, at runtime - without requiring a 
full restart.
-  cleanup the startup code - the split startup package, lots of 
introspection and dependencies ( commons-logging, jmx needed in CLASSPATH )
- maybe improve the class loading - for example WebappClassLoader use of 
the jar index, the code is a bit complex, etc
- make it easier to integrate tomcat in apps like jboss or eclipse - 
which both use similar class loaders and module mechanisms ( jbossmx and 
osgi ).

One extra benefit may be on allowing more flexibility in the 
common/shared/webapp hierarchy - if WebappClassLoader extends the 
loader, it will be easier to have webapps using different versions of 
shared libraries ( right now you need to place shared libs in shared or 
common, and you can't have more than a version ).

I've been trying to do this for a very long time - there is some code in 
3.3 ( interceptors can be loaded/unloaded from trusted webapps ), but 
using an m-let-like classloader is a better solution than what was there.

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

Re: loader

[Costin Manolache]

Mladen Turk wrote:
Costin Manolache wrote:
Mladen Turk wrote:
Costin, can you elabborate the purpose of the patch?
Perhaps I've missed few discussions.
There are few goals:
- allow tomcat components ( connector, valves, etc ) to be 
added/removed/upgraded dynamically, at runtime - without requiring a 
full restart.
-  cleanup the startup code - the split startup package, lots of 
introspection and dependencies ( commons-logging, jmx needed in 
CLASSPATH )
- maybe improve the class loading - for example WebappClassLoader use 
of the jar index, the code is a bit complex, etc
- make it easier to integrate tomcat in apps like jboss or eclipse - 
which both use similar class loaders and module mechanisms ( jbossmx 
and osgi ).

One extra benefit may be on allowing more flexibility in the 
common/shared/webapp hierarchy - if WebappClassLoader extends the 
loader, it will be easier to have webapps using different versions of 
shared libraries ( right now you need to place shared libs in shared 
or common, and you can't have more than a version ).

I've been trying to do this for a very long time - there is some code 
in 3.3 ( interceptors can be loaded/unloaded from trusted webapps ), 
but using an m-let-like classloader is a better solution than what was 
there.

What about commons-deamon?
What about it :-) ?
Daemon is a different level - it's about launching a resident process 
(or service in windows ). No connection with how the process is loading
its classes.


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

Re: loader

[Costin Manolache]

Mladen Turk wrote:
Costin Manolache wrote:
Mladen Turk wrote:
What about commons-deamon?
What about it :-) ?
Daemon is a different level - it's about launching a resident process 
(or service in windows ). No connection with how the process is loading
its classes.


Sure, but the wheel was invented long time ago :).
How about making things usable?
Which things to make usable ? Daemon ? It's not my itch to start 
services on windows:-)

Yes, the wheel was invented long ago - and we are still using the 
simplistic hierarchical class loader + delegation.

Do we really need all those different loaders?
That can be said about anything :-)
I'm making the compile optional - so if you don't explicitely ask for it 
it'll not get compiled. When it's completely ready - I hope it will 
replace Bootstrap/StandardClassLoader - so we'll still have 1 loader for 
standalone.

If embeded - as I said, the intent is to not use the loader but the 
embedor's loader - however ability to split tomcat in smaller components 
and manage each separately should remain ( supported by the embedding 
app loader ). That's why the loader is mirroring the fundamental 
behavior of mlet/jboss/eclipse/osgi - i.e. repository of classloaders 
delegating to each other.

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

Re: loader

[Costin Manolache]

Remy Maucherat wrote:
I didn't have time to look at the code yet, though.
Wait a week or 2 - the loader part is fine, but the catalina side is 
still a bit messy and I need to find a good way to integrate with the 
build ( to make it completely optional/isolated - I don't want to affect 
the 5.5  schedule by breaking something :-)

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

Re: JMX Remote connection

[Costin Manolache]

Remy Maucherat wrote:
Dominik Drzewiecki wrote:

Why don't we dump the JkMX and just settle for the facilities provided 
by Java 5 configurable via standard system properties: 
-Dcom.sun.management.jmxremote alone for local JVM monioring

or
-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.port=8004
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false
for remote machine monitoring.
Because they don't work with JDK1.4, and any people (including me) can't 
switch to Java5 since it breaks too much :-)

The option you mention are in fact the same thing with the webapp I'm 
suggesting - they have the effect of loading the standard 
javax.management.remote connector. The difference is that jx.m.r is 
using the standard API and will work with any JMX implementation, while
com.sun is specific to sun's implementation of jmx.


I checked both myself with jconsole shipped with Java 5. It works like 
a charm (apart from increased CPU Load on the machine the jconsole runs).
MC4J 1.2 B5 has no problems with attaching to remote JVM either, 
hovewer it has some issues with mbeans provided by JVM, MC4J folks are 
aware of.

The bottomline is: consider dumping o.a.jk.c.JkMX (I know, I know 
there is number of users wishing to run tomcat on JVM 1.5)
 

Your post motivated me for trying jconsole, and I have to say it's 
really good.
Yes, jconsole is the reason I wrote the app too. Plus the fact that 
mx4j2.0 no longer works with jkmx ( they dumped the connector beans from
distribution since they now support the standard jx.m.r )

As others have said, the problem with JkJMX is that it's annoying to 
keep it up to date. And when we had it up to date, the JMX client was 
then rarely up to date. So I'll let you guys decide what do do, but it's 
sort of obvious the need for that kind of stuff is a lot smaller than 
what it used to be for Tomcat 5.5.

Note: the main reason why I removed jk2.properties is because is has a 
very confusing name (again referring to mod_jk2); if it's really needed, 
then it should be renamed, or an alternate name should be allowed.
No, removing jk2.properties - and removing JkMX - is a good thing.
I'll check in the webapp code, it's easier to talk about code - if 
people don't like it, feel free to -1 :-)

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

JMX Remote connection

[Costin Manolache]

Hi,
Not sure what's the new policy for loading the Jmx RMI connector. 
jk2.properties was a hack - and now that it is removed, I was wandering 
if we have any official mechanism.

I had a small class that hooked in the connector, and I now refactored 
it to a webapp - nothing fancy ( it's not even trusted ), only loads 
rmiregistry and the jmx connector. I can check it in if there's no other
mechanism, it's very helpfull ( especially with JDK1.4/MX4j - in 5.0 
there are the cli options )

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

loader

[Costin Manolache]

I checked in the first part - I'm still working on making build.xml 
changes and the catalina-side code.

It is certainly experimental code for now - I think it works better than 
Bootstrap/etc, but the reloading of connectors/etc is still very tricky 
 ( it kind of works, but I still don't have a clean interface ).

I placed it in util/loader mainly for eclipse/IDE users - I have it 
compiled to a separate classes dir, and use the eclipse autocompilation 
- it's pretty cool and efficient ( i.e. no need to use ant or compile 
most of the time, just type and run :-).

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

Re: JMX Remote connection

[Costin Manolache]

Bill Barker wrote:
- Original Message - From: Costin Manolache 
[EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, October 05, 2004 10:06 PM
Subject: JMX Remote connection


Hi,
Not sure what's the new policy for loading the Jmx RMI connector. 
jk2.properties was a hack - and now that it is removed, I was 
wandering if we have any official mechanism.

At the moment, jk2.properties is still used (we're just not shipping the 
default one).  It should be possible to configure JkMX via Connector 
attributes.
I thought JkMX only supports the old style connector - not the new 
javax.management.remote, and since jk2.properties is being deprecated I
assumed JkMX will go as well, or at least move to a higher level.

The code in JkMX seems very specific to mx4j - and I couldn't get it 
working with mx4j2.0, the package name changed ( mx4j.adapter.rmi - 
mx4j.remote.rmi ) and the mechanism didn't seem to work.

Can we at least add the JMXConnectionServerFactory as another special 
case ? A separate webapp seemed cleaner.

Costin


I had a small class that hooked in the connector, and I now refactored 
it to a webapp - nothing fancy ( it's not even trusted ), only loads 
rmiregistry and the jmx connector. I can check it in if there's no other
mechanism, it's very helpfull ( especially with JDK1.4/MX4j - in 5.0 
there are the cli options )

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



This message is intended only for the use of the person(s) listed above as the 
intended recipient(s), and may contain information that is PRIVILEGED and 
CONFIDENTIAL.  If you are not an intended recipient, you may not read, copy, or 
distribute this message or any attachment. If you received this communication in 
error, please notify us immediately by e-mail and then delete all copies of this 
message and any attachments.
In addition you should be aware that ordinary (unencrypted) e-mail sent through the 
Internet is not secure. Do not send confidential or sensitive information, such as 
social security numbers, account numbers, personal identification numbers and 
passwords, to us via ordinary (unencrypted) e-mail.


-
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: More needed connector refactoring

[Costin Manolache]

Remy Maucherat wrote:
Hi,
- I'll add a thread pool similar to the one in Tomcat 4.0, as an 
optional policy to the current one; the idea is that it's very dumb, and 
could be more stable in some environments (that RH 9 thing ...), but is 
not as efficient as the current one; I'll do some benchmarks to see if 
for a single CPU computer there's any difference between the two, and I 
propose that whichever is the fastest for that use case becomes the 
default one (with a preference for the TC 4.0 one in case of a tie, as 
it's simpler)
I'm a bit confused - what happened with the thread pool and how did we 
end up with 2 ? I missed this change.


- I think conf/jk2.properties should go, since we can have arbitrary 
properties on the Connector element, and additionally, it has an 
extremely confusing name; any comments on that ?
+1 :-)
Costin
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: More needed connector refactoring

[Costin Manolache]

Bill Barker wrote:
- Original Message -
From: Costin Manolache [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, September 29, 2004 9:01 AM
Subject: Re: More needed connector refactoring

Remy Maucherat wrote:
Hi,
- I'll add a thread pool similar to the one in Tomcat 4.0, as an
optional policy to the current one; the idea is that it's very dumb, and
could be more stable in some environments (that RH 9 thing ...), but is
not as efficient as the current one; I'll do some benchmarks to see if
for a single CPU computer there's any difference between the two, and I
propose that whichever is the fastest for that use case becomes the
default one (with a preference for the TC 4.0 one in case of a tie, as
it's simpler)
I'm a bit confused - what happened with the thread pool and how did we
end up with 2 ? I missed this change.

- I think conf/jk2.properties should go, since we can have arbitrary
properties on the Connector element, and additionally, it has an
extremely confusing name; any comments on that ?
+1 :-)

It will make the Connector element in server.xml really hideous, and
restrict component names to be valid XML attribute names (e.g.
channelSocket.localhost:8009 is a no-no :).  Other than that, I don't see a
problem.
Maybe a better solution would be to introduce a new tag ( mbean or 
module or similar ), so we can express the fact that jk is composed 
from multiple components.

The intention of jk2.properties was to have a way to configure generic 
components ( mbean-like ), with a simple way to parse/save the changes 
from both java and C.

Since C is no longer an issue - there is no problem with using an xml 
file, like server.xml. And a good save changes implementation 
shouldn't be specific to jk.

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

classloader

[Costin Manolache]

I had a small vacation, and managed to make some of the changes in the 
classloader/module area. I'm not completely done - but I want to 
eventually start checking in some of the code ( if nobody objects ).

To avoid breaking anything, I started a new package ( 
o.a.tomcat.util.loader ), and started with the existing classes, with 
small refactorings.

- WebappClassLoader
- Bootstrap
- CatalinaProperties
plus some extra classes to support jboss ( or m-let) style loading.
I tried to remove all dependencies outside JDK1.4 - the package is
very small, and I think it's ok to not use commons-logging or jmx in 
this area. Apache.naming and jmx functionality is added via hooks - 
after the server loader ( now repository ) is started.

I think this will improve a bit the code structure - currently we have a 
bit of a mess in how we select some classes in the bin/ jars.

I'm not planning any change in the existing code - except adding few 
classes and code to allow the new loader to be used ( as an option ) 
instead of the old one.

My goal ( which is not yet completely done ) is to support modules for
connectors/interceptors/etc - with reloading and all the cool stuff, and 
make this integrable with existing systems ( jboss, other jmx/mlet based 
 applications, eclipse ). Instead of having the entire tomcat as one 
chunk of code ( plus all the depenencies ) integrated in one plugin, it 
should be possible to add a smaller subset and then have 
connectors/auth/etc as separate plugins.

Please let me know if this is ok with you - I'll have another long trip 
in mid Oct. and I hope to get this done, but if there are problems with 
what I'm trying to do ( or conflicts with other plans ), I would 
appreciate feedback before I waste the time :-)

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

Re: Interesting usage of Tomcat...

[Costin Manolache]

Mladen Turk wrote:
Shapira, Yoav wrote:
http://www.theserverside.com/talks/VendorPerspectives/Mainsoft/interview
.tss
Yes, indeed :)
Almost a year ago I proposed a project that would enable Tomcat to
seemesly integrate the legacy code. Something like moving the
perspective from being an backend to becoming an integrator.
Of course, the reaction was not much in favor :).
But seems that the direction is to integrate as much of those
'million lines written' as possible.
Regards,
MT.
We know more now than we did one year ago :-)
Beeing able to integrate our code in other apps and other apps in our 
code is indeed becoming more and more important.

Costin

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

Re: [VOTE] [5.5] Release plan votes

[Costin Manolache]

Remy Maucherat wrote:
The vote result is:
- the release plan seems to be mostly ok
- it is acceptable to use the J2SE 1.4 API for this release (only Costin 
seems to disagree with that); I expect this will allow using things like 
the NIO API without any difficulties or the need for compatibility code
Well, I disagree with all the incompatibilities and version hell between
jdk releases. I like NIO too, even if I use j2me most of the time :-)
Costin

- Yoav will RM this branch
Rémy

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

Re: [VOTE] [5.5] Release plan votes

[Costin Manolache]

Remy Maucherat wrote:
ballot
I approve the release plan:
[X] Yes
[ ] No
/ballot
ballot
Tomcat 5.5 should use the following API set for the coding:
[X] J2SE 1.3
[ ] J2SE 1.4
[ ] J2SE 5.0
/ballot
Actually - use target=1.3 - but the distribution should be 1.4 based 
(i.e. no Xerces ).

I'm also ok with having a 1.5 distribution ( no xerces, no mx4j ) - but 
again, with target=1.3 and instructions for 1.3 and 1.4 users to 
download the missing jars.

You can have target=1.3 with j2se without harm.
ballot
Yoav Shapira will act as the release manager for this branch:
[X] Yes
[ ] No
/ballot
Thanks :)
Rémy

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

Re: [5.5] Packaging

[Costin Manolache]

Remy Maucherat wrote:
Please make sure target=1.3 is present in all javac tasks :-)

Shouldn't we support only JRE 1.4 and 5.0 instead ? I would be able to 
replace jakarta-regexp use with Java regexp. Obviously people who don't 
want to upgrade (ex: I saw a really funny thread on tomcat-user about a 
guy who wants JMX runtime stats on 4.1.x, like the ones that were in 
5.0.x) aren't going to upgrade to this new branch, because of API breakage.
I'm using 1.3 most of the time, there is a _lot_ of software out there 
that doesn't work in jdk1.4 and won't work in jdk1.5 either. Not to 
mention companies having policies and supporting only one VM ( so they
don't have to deal with all the incompatibilities between versions ).

I'm personally -1 on droping support for 1.3 ( well, I would be +1 on 
supporting J2ME or 1.1 as a baseline :-).

Even compiling software with jdk1.5 or loading it in an IDE is problematic.
I think we should value stability more than featurism - and value 
flexibility and modularity more than bloat. There are people who have
problems with the Sun/Microsoft policy of bundling features in order to
reduce competition  ( logging, mx4j/jbossmx, jakarta-regexp, parser, etc 
). Especially when those features are hard to replace with better 
implementations ( even if they implement an API and have some convoluted 
endorsed setting to replace ).

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

Re: [5.5] Packaging

[Costin Manolache]

Shapira, Yoav wrote:
Hi,

Please make sure target=1.3 is present in all javac tasks :-)
Shouldn't we support only JRE 1.4 and 5.0 instead ? I would be able to

I'm also not big on JDK 1.3 as the default target.  I'm +0 on adding a
javaTarget build.properties attribute that users can set to 1.3 but
whose default value is 1.4, 1.5, or none, but not 1.3.  I haven't seen a
question on tomcat-user with someone running JDK 1.3 for a long time
now.
Maybe that's because they don't have endorsed problems and things just 
work and are stable :-)

Write once, run anywhere - why would you choose a target that will not 
run for a (significant) number of people, and try to force them to 
choose between upgrading tomcat and upgrading other software ?

What do we gain ? Few features that are available anyway - with many 
choices of better implementations.

Sun has the bad habit of breaking compatibility and the run anywhere 
promise on every release. 5.0 is particularly bad. I consider run 
anywhere one of the essential things in java - including the ability to
run with other vendor or open source VMs.

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

Re: [5.5] Packaging

[Costin Manolache]

Shapira, Yoav wrote:
It depends how you define support, right?  Does support mean by
default everything is configured for JDK 1.3, and Tomcat is built with
target=1.3 ?  Or does it means there's an easy way to set this target
parameter (e.g. a build.properties setting) and build your own Tomcat
for 1.3?
What is the cost of having target=1.3 by default ? It means the class
files and the release will work with jdk1.3 - and it will also run on 
1.4 or 1.5.

What is the benefit of having target=1.4 and forcing people who use 1.3
to recompile the entire tomcat ?

Stability versus featurism is much more of a judgment call IMHO.  Does
stability mean we stick with an old platform (JDK 1.3) and jump through
hoops (e.g. runtime detection) to use newer (JDK 1.4, JDK 1.5) features?
If so, then at what point does the cost (e.g. performance) become higher
than the benefit (ease of use for old platform users)?  It's a
subjective call I think.
That's a question for Sun :-), who is forcing people to jump through the 
hoops by bundling all features with the VM.

Tomcat core already works with 1.3 - and you can have optional 
connectors/valves/etc that only work with 1.5 or 1.6 - with just a 
simple conditional compilation.

I understand why MSFT is forcing people to upgrade windows - they make a 
lot of money from that, and don't care how much the users will suffer to 
upgrade. But we don't gain that much by forcing people to upgrade the VM 
to use the latest version of tomcat. I wish Sun would sell and make 
money on the VM - so at least someone would gets some benefit from this 
forced upgrade cycle :-)


While I don't doubt the legitimacy of your pro-1.3 arguments, you just
don't see users on the mailing list with anything other than JDK 1.4.
We already get more JDK 1.5 questions than JDK 1.3 it seems, even though
1.5 is still in beta.  
IMO that's because 1.3 is used in production for quite a while - so most
problems are solved.
If you release the next version with 1.4 target - you may get more 1.3 
questions :-)

Upgrading the VM is almost the same with upgrading the OS - there are 
still plenty of packages for RedHat7.3 or NT, and most of the questions 
are from people trying the latest OS and noticing things are breaking.


So I don't know, I'm not 100% convinced we should require JDK 1.5, and
I'm not 100% convinced we should drop 1.3, I'm just in the middle ;)
I'm comfortable with requiring 1.4 though, as it's been more than 2
years since JDK 1.4 was released.
I'm ok with using 1.5 features, or having a default distribution for 1.5 
- as long as the code is compiled with target=1.3 ( no major harm ) and
it is possible to run the basic tomcat with 1.3 ( with some additional 
packages - parser, mx4j, etc ).


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

Re: [5.5] Packaging

[Costin Manolache]

Remy Maucherat wrote:
I'm planning to do the following changes to packaging:
- removing commons-launcher from the final distribution (I see little 
use of it, since we have good scripts and native wrappers available); it 
will stay as a dependency to launch stuff during the build process
- new release archives based on the contents of the compat folder, for 
JRE 1.4 users (the default distributions will be for JRE 5.0)
Is JRE1.5 final available ? Last I checked it was still beta.
I think it's a good idea to keep 1.4 as default target at least until 
1.5 is out of beta.

Are you going to include xerces or just leave it out and tell 1.3 users 
to download an xml parser and install it in common/lib ?

- new release archives for the admin webapp (= not in the main archive; 
not everyone uses it, and it's quite large)
Not sure what that means :-).
- the Windows installer will remain the same for now (= an offline 
installer), as I don't see how to make it an online installer and still 
respect the mirror scheme we use

Rémy

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

Re: [5.5] Packaging

[Costin Manolache]

What does that leave us with in terms of distros?  Let me try:
[Source distros, same as today]
- jakarta-tomcat-5.5.0-src.zip
- jakarta-tomcat-5.5.0-src.tar.gz
[Binary distros]
- jakarta-tomcat-5.5.0.zip - for JRE 5.0, no Admin
- jakarta-tomcat-5.5.0.tar.gz -  for JRE 5.0, no Admin
- jakarta-tomcat-5.5.0.exe - for Windows, JRE 5.0, no Admin
- jakarta-tomcat-5.5.0-jre14.zip - for JRE 1.4, no Admin
- jakarta-tomcat-5.5.0-jre14.tar.gz - for JRE 1.4, no Admin
- jakarta-tomcat-5.5.0-jre14.exe - for Windows JRE 1.4, no Admin
+ another one for each of the above with Admin?
Why ? We can distribute admin.war as a separate binary, who needs it can
install it separately.
What is the difference between JRE1.4 and JRE5.0 distribution ? I'm 
building with 1.4 and 1.5 and it works fine with 1.5, 1.5 and 1.3, do we 
need separate builds ?

BTW - I don't know how hard it would be to have admin.war also 
distributed as a .exe with installer ( just need to extract the war
in the tomcat dir ).

Maybe we should have admin separately, i.e.
jakarta-tomcat-5.5.0-admin.war (complete with META-INF/context.xml),
that users can just drop into their webapps directory?  I'd rather have
that than 6 more binary distributions.
+1

What about dropping .tar.gz distros?  I realize its files are smaller
than zip, but every platform has zip support and I doubt many of our
users (who are mostly developers for companies or open-source
afficionadoes) are on dialup connections.  Alternatively (this is what
JonAS has done for example) we could just have .tgz files which the
Windows Winzip can handle.  This saves the release manager work and
reduces user confusion slightly, as they are faced with less download
choices.  I see the latter (user confusion) increasing when we have
JRE1.4 and JRE5.0 distros.
Do we do any line ending processing for tgz and zip ? The expectation is 
that .tgz distributions use unix LF, and zip files use CRFL.

If tgz and zip are identical ( and I assume it's CRLF since the build is 
on windows ) - then it's a good idea to have only zip ( tgz with CRLF is 
confusing )

Costin

Yoav

This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged.  This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else.  If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender.  Thank you.

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

Re: [5.5] Packaging

[Costin Manolache]

Remy Maucherat wrote:
No, you misunderstood.
- jakarta-tomcat-5.5.0.zip - for JRE 5.0, no Admin
- jakarta-tomcat-5.5.0.tar.gz -  for JRE 5.0, no Admin
- jakarta-tomcat-5.5.0.exe - for Windows, everything

- jakarta-tomcat-5.5.0-compat.zip - for JRE 1.4 (a few additional JARs, 
not the whole thing)
- jakarta-tomcat-5.5.0-compat.tar.gz -  for JRE 1.4, no Admin
You mean mx4j ? I'm not sure about having the main target be a JRE beta,
but I understand your point, it's cleaner this way. The alternative 
would be to have a 1.4 distro, with mx4j jars included, and detect at
runtime if it's 1.5 and skip them from the loader.

I suspect people will keep using 1.4 and 1.5 for a while, as usual there 
are incompatibilities - so it's better to be able to use the same tomcat 
with both.

Please make sure target=1.3 is present in all javac tasks :-)

- jakarta-tomcat-5.5.0-admin.zip - admin WAR + the XML file
- jakarta-tomcat-5.5.0-admin.tar.gz - admin WAR + the XML file
Good.
Costin


Maybe we should have admin separately, i.e.
jakarta-tomcat-5.5.0-admin.war (complete with META-INF/context.xml),
that users can just drop into their webapps directory?  I'd rather have
that than 6 more binary distributions.
 

IMO, the admin webapp is better located in the special folder we're 
using right now. It helps with catalina_base.

What about dropping .tar.gz distros?  I realize its files are smaller
than zip, but every platform has zip support and I doubt many of our
users (who are mostly developers for companies or open-source
afficionadoes) are on dialup connections.  Alternatively (this is what
JonAS has done for example) we could just have .tgz files which the
Windows Winzip can handle.  This saves the release manager work and
reduces user confusion slightly, as they are faced with less download
choices.  I see the latter (user confusion) increasing when we have
JRE1.4 and JRE5.0 distros.
This is a bad idea.
- Windaube XP only supports .zip
- tgz allows setting Unix execute flag
Rémy

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

Re: [VOTE] 4.1.31 maintenance release

[Costin Manolache]

I think we long ago agreed not to vote -1 just because you want somebody 
to work on a different codebase :-)

If Keith has an itch in 4.1 branch - and if he can find 2 more +1 votes, 
than it's his right to have a release, and the 4.1 branch will become 
maintained.  A branch is maintained if there are committers interested 
to maintain it - not if someone else decides it shouldn't be maintained 
and they should do something else.

4.1 is stable and works good enough - yes, 5.x is faster and has better 
architecture, but some people don't like to change production systems 
very often, and it is very good for them to know that what they are 
using is still maintained ( we're not msft to make money by forcing 
people to upgrade )

Costin
Shapira, Yoav wrote:
Hi,

ballot
The 4.1.31 maintenance release should happen:
[ ] Yes
[ X ] No
/ballot

-1 on this release.  Reasons have been stated in detail in the other
thread, but to summarize this branch is no longer maintained and users
should upgrade to 5.x or custom-patch if they have an emergency.
Yoav Shapira

This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged.  This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else.  If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender.  Thank you.

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

Re: common/endorsed classLoader

[Costin Manolache]

Bill Barker wrote:

Are endorsed jars getting loaded somewhere else other than Bootstrap?
Using the default startup scripts, they are loaded into the System CL
(the
only way a delegating CL can find them :).
You mean -Djava.endorsed.dirs in catalina scripts, correct?

Yup.

BTW, why do they need to be loaded into the System CL in the scripts on
top
of commonLoader in Bootstrap using common.loader property in
org/apache/catalina/startup/catalina.properties?

CLFactory sets delegate=true on the StandardCL instances, so they are
delegating loaders (This is in 5.0.x; in 5.5 StandardCL is pretty much just
a URLCL, which delegates).  As a result, they will always find the xml
classes in the System CL (for JVM = 1.4).  Thus if you want to change your
xml classes from the JVM default, that's where you have to have them.  It
doesn't really matter if they are in the common.loader property or not
(except, of course, for JVM  1.4 :).
To make things a bit more interesting, I believe there are some checks 
in JDK1.4 to prevent you to override rt.jar classes. That's what 
endorsed really does, allow you to bypass those checks.

I don't think we managed to get xerces and jaxp to load from a 
classloader even with delegation disabled.

Costin


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

Re: Tomcat 5.0.28 release

[Costin Manolache]

Jeanfrancois Arcand wrote:
Shapira, Yoav wrote:
Hi,
I have a couple of only-slightly-related comments, but related
nonetheless so I'll put them here.
Re: endorsed directories.  Do we still want to support JDK 1.3 in Tomcat
5.1?  Since we're gearing up for JDK 1.5, we might want to make 1.4 the
minimum.  I'm +0.5 on this.

First, endorsed directories are _not_ for 1.3, but for 1.4 ( to 
override the build-in parser and the check they do on load ).
1.3 works fine with just having the parser in classpath, or in 
/jre/lib/ext, and it's quite simple to add code to the loader to add 
the parser packages only if 1.3 is detected.

Except if you turn validation on, which will not works since XML schema 
is not supported in Crimson or early version of Xerces (remember the 
nightmare)

Yes, schema validation on JDK1.4 is lost because the parser doesn't 
support it well enough.

I think it may be better to just check if the parser supports schema 
validation, and if not just display a warning that schema validation is 
disabled on parser that don't support it. It's easy to detect what 
version of xerces or if crimson is used.

Fact is a lot of parsers don't support schema validation, and it is 
better to allow tomcat to work with any parser than try to force a 
specific version of parser.

Well, the right solution is to just remove the option to turn schema 
validation on at startup - it is a huge waste of time at startup, it 
should be done only at deploy time by deploy tools :-)



I'm using JDK1.3 most of the time, and I think a lot of other people 
and companies are still using it. I don't mind having the default 
distribution built for 1.4+ ( no xerces ), with instructions on how to 
get the additional jars for 1.3. But I think it would be very bad to 
not be able to run in 1.3 - and I don't see any good reason to justify 
forcing the users to upgrade.

One question we should explore is do we really wants to have a 
dependencies on Xerces? Like you already said, a pull parser might be 
better, smaller and more stable than having to rely on Xerces. Not sure 
if pull parser supports schema yet...

+1 of dropping Xerces ;-)
I don't think many pull parsers support schema, they are supposed to be 
faster and simpler :-)

It's not about dropping xerces - we will still use the xerces inside 
jdk1.4 and jdk1.5 - we just shouldn't force a specific version and take 
all the pain for endorsed.dir - but let the user use whatever Jaxp 
parser he wants and disable schema validation if the parser doesn't 
support it.

Costin

-- Jeanfrancois




them. I prefer the latter approach, also because of the multi-user use
case: if a single Tomcat installation (CATALINA_HOME) is used by
multiple users (each having their own CATALINA_BASE), then the former
approach does not work if each user has a different version of the JDK.


How about stopping support for that scenario?  I mean drop the
CATALINA_BASE versus CATALINA_HOME feature, (or set them to always equal
each other, if we want to leave them in the code base), and don't allow
users to share installations except by the user home directory valve.
The disk space benefits aren't worth it.  The central administration
benefits might be, but I wonder how many people use this.  Maybe an
informal survey on the user list is worth doing?

How about the other way around - stop support for the combined tomcat, 
and default to multi-user ( or multi-config ).

I would be very happy to see the server layout change to support 
multiple configurations.

Something like:
/bin
/lib - with manifest/properties file used to select what goes to 
common, server, shared :-)

/servers
/servers/all
/servers/minimal
With conf/ and webapps/ under each server.
Costin
-
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: Tomcat 5.0.28 release

[Costin Manolache]

Petr Jiricka wrote:
Costin Manolache wrote:
Shapira, Yoav wrote:
Hi,
I have a couple of only-slightly-related comments, but related
nonetheless so I'll put them here.
Re: endorsed directories.  Do we still want to support JDK 1.3 in Tomcat
5.1?  Since we're gearing up for JDK 1.5, we might want to make 1.4 the
minimum.  I'm +0.5 on this.

First, endorsed directories are _not_ for 1.3, but for 1.4 ( to 
override the build-in parser and the check they do on load ).
1.3 works fine with just having the parser in classpath, or in 
/jre/lib/ext, and it's quite simple to add code to the loader to add 
the parser packages only if 1.3 is detected.

I'm using JDK1.3 most of the time, and I think a lot of other people 
and companies are still using it. I don't mind having the default 
distribution built for 1.4+ ( no xerces ), with instructions on how to 
get the additional jars for 1.3. But I think it would be very bad to 
not be able to run in 1.3 - and I don't see any good reason to justify 
forcing the users to upgrade.


Hi Tomcat developers,
I must say I don't fully understand the above. So what exactly will 
happen if the common/endorsed directory is removed? What will stop 
working and on which platform(s)? Are there any specific pointers to bug 
ids or discussions, that would explain why the endorsed directory was 
added in the first place? I know configuring the XML parser and JAXP was 
always pain, but I don't know what specifically was the problem. Any 
insights you can bring into this will be appreciated.
If you remove common/endorsed:
- jdk1.3 - it'll work if you add your own parser in common/lib or 
jre/lib/ext or classpath

- jdk1.4 - because the parser in jdk1.4 is an old xerces, xml schema 
validation might fail, everything else should work.

- jdk1.5 - AFAIK everything should work.
The reason endorsed was added is JDK1.4, where we had to add newer 
org.apache.xerces and javax.xml ( replacing what's in rt.jar ).

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

Re: Tomcat 5.0.28 release

[Costin Manolache]

To clarify: I wasn't proposing to remove the separate product 
installation and runtime, but the contrary - to make that the default.

Right now tomcat operates in 2 modes - one where CATALINA_HOME is
identical with CATALINA_BASE, and one where you have them separate ( 
like you use ).

I think it would be cleaner if separate mode will be the default, with 
the runtime files always in a separate hierarchy. But it's more of a 
cosmetic change.

Costin
Rainer Jung wrote:
We are using it also and it is very helpful.
It is one of the standard product features of a container to be able to 
seperate container product installation from runtime instance specific 
files.

It works very nicely with tomcat. We can even allow instance admins to 
extend TC by changing to an alternate catalina.properties file 
(classloader definitions). It's not just a question of users sharing the 
base installation.

I have a small enhancement request: we regularly change catalina.sh to 
include a file setenvInstance.sh from CATALINA_BASE/bin if it exists. We 
do this immediately after CATALINA_TEMPDIR is set. This way all 
instances share the same catalina.sh and instance specific commandline 
flags (memory sizing, catalina.properties, ...) can be done in the 
instance local setenvInstance.sh without changing the product installation.

Please keep the separation of product installation and runtime instance.
Rainer Jung
kippdata informationstechnologie
George Sexton wrote:
How about stopping support for that scenario?  I mean drop the 
CATALINA_BASE versus CATALINA_HOME feature, (or set them to always 
equal each other, if we want to leave them in the code base), and 
don't allow users to share installations except by the user home 
directory valve.


I am really against this. I use CATALINA_HOME and CATALINA_BASE. The 
reason
that I use them is that they provide a clean way of upgrading 
frequently. It
lets me maintain a stock Tomcat Directory, with all of my customization
(conf files, etc) in a separate directory.
Please don't drop this functinality.

George Sexton
MH Software, Inc. - Home of Connect Daily Web Calendar
http://www.mhsoftware.com/
Voice: 303 438 9585
 

-
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: JDT and Jasper

[Costin Manolache]

Are you talking about the compiler in eclipse ?
Does it allow a way to set up to use jikes ?
Costin
Remy Maucherat wrote:
Hi,
I've changed my mind a lot on this particular subject, but I'm still 
investigating.
I'm looking at JDT right now, for use in Jasper, to replace Ant + javac 
task as the default Java compiler. It might be mature enough, and would 
run with a JRE. It is also relatively small (the whole compiler is less 
about 1.5M after trimming stuff from the jdtcore JAR, to compare with 
the Ant JAR which doesn't do much by itself and is slightly less than 1M).

The other advantages:
- loads source dependencies from the classloader
- good error reporting API (no need for hackish text output capture 
anymore)

Note: The license seems ok (Cocoon uses it already).
Rémy

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

Re: both jdk1.5 and jdk1.4 needed to build tomcat????

[Costin Manolache]

What I did is add
   target=1.3 source=1.3
on each javac  target in build.xml files failing under 1.5.
Also in Eclipse java/compiler/compliance - 1.3, and same in idea.
This lets me compile with 1.5 or eclipse ( I have it set to generate 
classes in the same dir ant would compile - so ant is only doing the 
packing ). I use JDK1.3 mostly for OptimizeIt, I have a very old version
that doesn't support 1.4+.

Costin
Shapira, Yoav wrote:
Hi,
Note also that CVS HEAD is not guaranteed to be stable until we make a
release.  If you want a stable reproduction of current code, do your
checkouts with the TOMCAT_5_0 branch.
Yoav Shapira
Millennium Research Informatics

-Original Message-
From: Hiller, Dean D (Dean) [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 12, 2004 5:52 PM
To: Tomcat Developers List
Subject: RE: both jdk1.5 and jdk1.4 needed to build tomcat
Thanks, I will do that.
dean
-Original Message-
From: Filip Hanik - Dev [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 12, 2004 3:49 PM
To: Tomcat Developers List
Subject: Re: both jdk1.5 and jdk1.4 needed to build tomcat
It works for me with those steps using JDK 1.4, no problem
if you need to try again, I suggest to clean your machine, and start
over (this includes all the downloads in /usr/share/java)
Filip
- Original Message -
From: Hiller, Dean D (Dean) [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Thursday, August 12, 2004 4:38 PM
Subject: both jdk1.5 and jdk1.4 needed to build tomcat
I for some reason needed 1.4jdk and 1.5jdk to build tomcat.  My steps
are below.  Any help would be appreciated as to how I can correct
this
Using jdk1.5 and Filip's great list of steps(thanks Filip, the list
made
life easier, and I am almost there)
I go through the list to build tomcat
1. cvs co jakarta-tomcat-5
works great
2. cd jakarta-tomcat-5
obviously works
3. ant update
works great
4. ant download
breaks, and looks like 1.5 problems, so I switch to 1.4 and it
works!!!.  Basically the tomcat-deps module is not compiling in 1.5 as
it conflicts with many different things.
5. ant dist
sticking with 1.4 doesn't work, and going to 1.5 doesn't work.
So now, I am basically stuck again on Jakarta-tomcat-5/build/classes
not
compiling at all.  I am not sure where to go.  I am trying to think
what
are the possibilities of what is wrong.
1. I need to do some configuration which I haven't done.
2. Builds currently don't work if starting from scratch as something
was
modified on accident?
3. they do work if you already had everything downloaded?
I followed the steps above twice.  I don't suppose having to switch
between 1.4 and 1.5 makes my situation easier to debug, as that could
be
part of my problem too.  Don't suppose someone just wants to send me a
zipped up version of their view that builds??  I would like to fix this
and will continue to look at the problem, but I am not really sure
where
to start so it may take me some time as I jump into all this.
Thanks,
dean

-Original Message-
From: Mark Thomas [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 12, 2004 2:16 PM
To: 'Tomcat Developers List'
Subject: RE: tomcat build broken with strange javac error(never seen
this one before)
1. Ignore the stop sending me mail message. Someone has managed to
get
themselves subscribed to the list and is obviously incapable of
following the
simple instructions included in every mail to unsubscribe. One of the
list
owners (of which I am one) will sort this out.
2.  3. The right place to posts depends on the question and will
always
be a
judgement call and different people will make different judgements. I
wouldn't
worry about it too much - personally I thought this one was on the
border line.
Mark

-Original Message-
From: Hiller, Dean D (Dean) [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 12, 2004 8:29 PM
To: Tomcat Developers List
Subject: RE: tomcat build broken with strange javac
error(never seen this one before)
Huh, 3 questions about this mail list then.
1. confused by stop sending me mail when this is my first
mail to this
list
2. Huh, I thought building would be a developer issue
3. Where should I post future questions on the source code I
am looking
at in tomcat???  The users list states it is for configuration
issues,
etc.
ps. Thanks shapira for the jdk1.5 note.  That makes sense, duh.
Thanks,
dean
-Original Message-
From: Joshua Paul [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 12, 2004 1:21 PM
To: Tomcat Developers List
Subject: Re: tomcat build broken with strange javac error(never seen
this one before)
Stop sending me e-mail.
- Original Message -
From: Hiller, Dean D (Dean) [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, August 12, 2004 3:00 PM
Subject: tomcat build broken with strange javac error(never seen this
one
before)
I have never seen an error from javac like this before(and I am by no
means new to java).  I have even read the JLS and am not sure what 

Re: JDT and Jasper

[Costin Manolache]

Remy Maucherat wrote:
Remy Maucherat wrote:
Hi,
I've changed my mind a lot on this particular subject, but I'm still 
investigating.
I'm looking at JDT right now, for use in Jasper, to replace Ant + 
javac task as the default Java compiler. It might be mature enough, 
and would run with a JRE. It is also relatively small (the whole 
compiler is less about 1.5M after trimming stuff from the jdtcore JAR, 
to compare with the Ant JAR which doesn't do much by itself and is 
slightly less than 1M).

The other advantages:
- loads source dependencies from the classloader
- good error reporting API (no need for hackish text output capture 
anymore)

Note: The license seems ok (Cocoon uses it already).

To restate maybe a little more clearly, we would go back to having more 
than one compiler, with the two supported options being:
- Ant with javac task (which AFAIK supports virtually all the compilers)
- (and shipped by default) JDT
That sounds better :-).
Since JDT is from eclipse, we can also use the idea of plugin here - and 
have the javac task and other compilers as separate plugins the user can 
download and install.

I'm making some progress with the class loader - modules placed in 
server/webapps/  can now be loaded  ( with Class.forName or equiv ) from 
the server class loader, and can access classes from each other. 
Reloading of server classes also seems to work now, after serveral 
problems ( at least for the smtp connector I'm playing with ).

My current approach is to use server/webapps as the equivalent of 
eclipse plugins - with a ContainerServlet that does all initialization, 
etc. It just reuses all the webapp infrastrucutre ( manager can control 
modules, etc ).

That means an ant/javac plugin could be packaged as a ( priviledged ) 
war and deployed in tomcat.


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

Re: building tomcat source in eclipse

[Costin Manolache]

The trick is to get all dependencies. Do an ant download, then create 
project for repository, tomcat-connectors, tomcat-catalina, jasper, 
servletapi ( with the obvious dependencis ). Eclipse will find all 
source trees and jars, then compile without problems. Same works
in Idea.

Costin
Hiller, Dean D (Dean) wrote:
I am just trying not to have 800 errors when I run tomcat in eclipse.
It would be easier if someone just provided .project and .classpath
files.  I am working on setting up in eclipse.  Am down to 800 problems
from 1000, and am still playing with it.  I can't find mail.jar that
eclipse is using(might need to just go get it myself), but I can't
figure out how tomcat built successfully without it via command line.
Couldn't find it anywhere including /usr/java/share nor the tomcat view
I have...and that is after building everything fine from command line.
Thanks,
dean
-Original Message-
From: Mark Thomas [mailto:[EMAIL PROTECTED] 
Sent: Thursday, August 12, 2004 2:24 PM
To: 'Tomcat Developers List'; 'Patrick Lacson'
Subject: RE: building tomcat source in eclipse

What are you trying to achieve? I use Eclipse to develop TC5 ( TC4) but
always
build from the command line. I have each of the top level directories
created by
the build script as an Eclipse project. You can still use remote
debugging etc
as well as all the other Eclipse features.
Mark

-Original Message-
From: Patrick Lacson [mailto:[EMAIL PROTECTED] 
Sent: Thursday, August 12, 2004 9:16 PM
To: [EMAIL PROTECTED]
Subject: building tomcat source in eclipse

I searched the archives regarding my question and found nothing.
Has anybody successfully built the tomcat 5 source tree from within
eclipse?  If so could share your .project and .classpath file?
I want to build and run tomcat from within eclipse, launching it as a
Java Application within the IDE.
thanks,
patrick
-
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]

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

Re: [AJP] proxy status

[Costin Manolache]

William A. Rowe, Jr. wrote:
At 02:15 PM 8/7/2004, Costin wrote:
Now let's see how to get this in Apache2.0...

Gonna try to make that happen, if I can somehow merge history (ick)

It would be great if we would have at least one or 2 people who are committers in both projects. Since we can't propose Mladen in apache, maybe we can convince Graham to join tomcat :-)

Can't propose mturk?  Why, because he is already active in httpd space?
My point was that it is hard to do development across 2 projects, while 
none of the developers has CVS access in both.

If it is not possible to find a solution to the cvs permissions in 
either apache or tomcat - then maybe it would be good to have it in a 
separate repository. It may make it easier to also port it to apache2.0, 
as a separate standalone module.

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