You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by co...@covalent.net on 2002/07/24 21:10:33 UTC
JSR77 & tomcat5 configuration
It seems JSR77 has been posted - I think everyone should read it.
What's important is the set of naming conventions for the managed
objects we expose - I strongly believe that we should use those
names wherever we provide the equivalent functionality.
For example ( on what is important for me ):
- 'node' attribute - instead of jvmRoute
- each tomcat instance in a distributed config must know
about all other
- we should start exposing mbeans for JVM, WebModule and
servlets using the naming conventions.
Of course, we should keep backward compat - but all old
attribute names should be eventually deprecated.
As I mentioned in the past, I'm not happy with XmlMapper/Digester
style used for configuration and I'm not happy with either
server.xml format or with the way we save the config.
At this moment I have a very strong belief ( and it's getting
stronger every day ) that we should adopt a configuration
close to the JMX model, where every configurable object
is a named mbean.
That means no more Interceptor/Context/Server/Valve/Listener/etc.
I also thing the configuration should be centered around a
class similar with RuntimeConfigurable on ant, where all the
user settings are stored ( including ${props} ). Any
configuration action that involves persistence should operate
on the RuntimeConfigurable, which should deal with saving
the config ( in a form as close as possible to the original
user configuration ).
While I think XmlMapper/Digester are very powerfull tools, I think
tomcat5 should follow a model that is closer to ant - i.e.
a set of patterns and a flatter configuration file. This has proven
to be easy and is well-understood ( even if I wrote a lot of
code in xmlMapper, I do have troubles sometimes with it, and
nobody can claim it's as easy as ant tasks).
The question is: What do you think :-) ?
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: JSR77 & tomcat5 configuration
Posted by Remy Maucherat <re...@apache.org>.
costinm@covalent.net wrote:
> It seems JSR77 has been posted - I think everyone should read it.
>
> What's important is the set of naming conventions for the managed
> objects we expose - I strongly believe that we should use those
> names wherever we provide the equivalent functionality.
>
> For example ( on what is important for me ):
> - 'node' attribute - instead of jvmRoute
> - each tomcat instance in a distributed config must know
> about all other
> - we should start exposing mbeans for JVM, WebModule and
> servlets using the naming conventions.
>
> Of course, we should keep backward compat - but all old
> attribute names should be eventually deprecated.
>
> As I mentioned in the past, I'm not happy with XmlMapper/Digester
> style used for configuration and I'm not happy with either
> server.xml format or with the way we save the config.
>
> At this moment I have a very strong belief ( and it's getting
> stronger every day ) that we should adopt a configuration
> close to the JMX model, where every configurable object
> is a named mbean.
>
> That means no more Interceptor/Context/Server/Valve/Listener/etc.
>
> I also thing the configuration should be centered around a
> class similar with RuntimeConfigurable on ant, where all the
> user settings are stored ( including ${props} ). Any
> configuration action that involves persistence should operate
> on the RuntimeConfigurable, which should deal with saving
> the config ( in a form as close as possible to the original
> user configuration ).
>
> While I think XmlMapper/Digester are very powerfull tools, I think
> tomcat5 should follow a model that is closer to ant - i.e.
> a set of patterns and a flatter configuration file. This has proven
> to be easy and is well-understood ( even if I wrote a lot of
> code in xmlMapper, I do have troubles sometimes with it, and
> nobody can claim it's as easy as ant tasks).
>
> The question is: What do you think :-) ?
Maybe it's time to plan for a change ...
This points out at the need for a new JSR 77 aware servlet container
(which would likely reuse lots of code from the current Catalina). It's
a good thing the core is now separate from the servlet container ;-)
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
can not build libjkjni.so
Posted by Dev Zero G Ltd <ma...@devzerog.com>.
We are trying to get the mod_jk working on FreeBSD 4.4, tomcat 4.0.4,
apache 2.0.39, jdk 1.4.0
We have so far successfully built mod_jk2.so and all the jars, but now
are having problems with libjkjni.so
Can somebody help, PLEASE?!! WE ARE SO CLOSE...
-------- what we've done --------
updated from cvs jakarta-tomcat-connectors (~15:00 GMT+00)
${conn_root}/utils: cp build.properties.sample build.properties
ant
${conn_root}/jk: cp build.properties.sample build.properties
in build.properties:
set catalina.home
set tomcat4.home to catalina.home
set apache.home
${conn_root}/coyote
cp build.properties.sample build.properties
ant
${conn_root}/
ant
${conn_root}/
cp jtc.jar ${catalina.home}/server/lib
cp ${jtc.home}/jk/build/lib/tomcat-jni.jar ${catalina.home}/bin
cd ${catalina.home}/server/lib
rm tomcat-ajp.jar tomcat-util.jar tomcat-coyote.jar tomcat-http11.jar
cd ${catalina.home}
vi conf/server.xml
add coyote connector:
<Connector className="org.apache.coyote.tomcat4.CoyoteConnector"
port="8009" minProcessors="5" maxProcessors="75"
enableLookups="true" redirectPort="8443"
acceptCount="10" debug="0" connectionTimeout="20000"
protocolHandlerClassName="org.apache.jk.server.JkCoyoteHandler"/>
${conn_root}/jk
chmod -r +x *.sh
./buildconf.sh
vi configure
// find key --no-verify and remove it - in other way following
configure run fails with message "--no-verify requires host" or
something else
./configure --with-apxs=/usr/local/apache2/bin/apxs
--with-java-home=${JAVA_HOME} --with-java-platform=2 -enable-jni
// in common, apache2 and jni folders need to edit Makefile because (my
shell is csh)
// a) libtool must be defined as "libtool" but not "/bin/csh libtool"
b) in some places in Makefile's statement $< I've replaced by
certain file name ( .la). I don't know why it doesn't work (we're new to
unix C programming)
make
make install
${conn_root}/jk/apache2
cp mod_jk.so /usr/local/apache2/modules
-------- QUESTION ---------
Where can we find .so library to place into ${catalina.home}/lib folder?
It must be libjkjni.so, or something like that, right?
We are mainly folowing instructions from
http://www.pubbitch.org/jboss/mod_jk2.html
and from http://jakarta.apache.org/tomcat/tomcat-4.0-doc/config/ajp.html
Any more advice, pointers, ideas, suggestions - will be greatful for
_anything_
Thanks in advance!!
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: mod_jk2.so compiled (after patching), but won't install
Posted by Henri Gomez <hg...@apache.org>.
Quoting Dev Zero G Ltd <ma...@devzerog.com>:
> > Which version of Apache 2.0 did you have ?
>
> We are running Apache 2.0.39 on FreeBSD 4.4
good
> >>--- patch history start ---
> >>Filename: jk\native2\include\jk_mutex.h
> >>
> >>Line # :75
> >>Old line :
> >>#ifdef HAS_APR
> >>New line:
> >>#if APR_HAS_THREADS
> >
> > +1
> >
> >>#ifdef HAS_APR
> >
> >
> >>Line # :121
> >>Old line :
> >>#ifdef APR_HAS_THREADS
> >>
> >>New line:
> >>#if APR_HAS_THREADS
> >>
> >>Reason: This conditional define statement adjusts variable
> >>definition (threadMutex). Type of this variable depends on define
> >>directive conditions, but to have needed types there are some #ifdef
> >>statements on lines 75-81. So, those definition statements are not
> >>the same, and this situation causes build-time error, when compiler
> >>includes one header file (with one type defined inside), but variable
> >>tries to have another type (found by me in another .h file - not
> >>included while build time due to #ifdef directives). Such changes
> >>were done experimentally and may be not 100% correct. In original
> >>compiler fails with message like "syntax error on before
> >>apr_thread_mutex_t in line 121"
> >>
> >
> > apr.h have #define APR_AS_THREADS 1 so both should be the same.
> > Didn't have any build error with that on Linux Redhat 7.2 + apache 2.0.39
> ...
> >
>
> our version of apr.h has #define APR_HAS_THREADS 0
So you don't have THREADS and yes #ifdef APR_HAS_THREADS is invalid,
your patch is correct
> Maybe apache/connector has not been ported properly to FreeBSD?
Linux, solaris, windows and many stranges architectures (JF ;)
patches applied to jk_mutex.h
> >>Filename jk\native2\build.xml
> >>
> >>Line # : 374
> >>Action : commented
> >>
> >>Reason : Having this link option uncommented (original) I could
> >>not acquire libjkjni.so, only .a and .la files present. As far as I
> >>am dummy in FreeBSD C/C++, I used something
> >>"try-to-change-something-and-see-what-you-get" method (it has pretty
> >>russian idiom,but I don't know its analog in English)
> >>
> >>Filename: jk\build.properties
> >>
> >>Some pathes set to correspond to reality (path to apache, etc)
> >>
> >>Filename: jk\native\apache-2.0\build-unix.sh
> >>
> >>Line # : 44
> >>Action: commented.
> >>Line # : 46
> >>Action : uncommented and approved
> >>New line:
> >>INCLUDE="-I ../common -I$APACHE_HOME/include/apr-util $JAVA_INCLUDE"
> >
> >
> > Don't use build-unix.sh but instead configure/make. The build.sh is no
> more
> > present in recent jtc cvs, deprecated in favor of autoconf/make
> >
>
> will try this
>
> >
> >>Reason : while compiling mod_jk.so compiler could not see
> >>connectors includes. I added first statement to make it visible
> >>--- patch history end ---
>
> Thanks again
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: mod_jk2.so compiled (after patching), but won't install
Posted by Dev Zero G Ltd <ma...@devzerog.com>.
Thanks very much for the help.
See below
Henri Gomez wrote:
> Quoting Dev Zero G Ltd <ma...@devzerog.com>:
>
>>First of all - many many thanks to everybody who has helped so far - we
>>really appreciate it.. Just one last push required. :)
>>
>>We finally got mod_jk2.so and libjkjni.so to compile (see patch history
>>at the bottom of the mail), but can't install. We put them into
>>$(APACHE2_HOME)/modules and $(CATALINA_HOME)/lib accordingly.
>>
>>But after running $(APACHE2_HOME)/bin/apachectl configtest we get an
>>error message:
>>
>>--- error start ---
>>file://augada/usr/local/apache2/modules ../bin/apachectl configtest
>>Syntax error on line 231 of /usr/local/apache2/conf/httpd.conf:
>>Cannot load /usr/local/apache2/modules/mod_jk2.so into server:
>>/usr/local/apache2/modules/mod_jk2.so: Undefined symbol
>>"apr_thread_mutex_trylock"
>>--- error end ---
>>
>>What could it be?
>
> Which version of Apache 2.0 did you have ?
We are running Apache 2.0.39 on FreeBSD 4.4
>
>>--- patch history start ---
>>Filename: jk\native2\include\jk_mutex.h
>>
>>Line # :75
>>Old line :
>>#ifdef HAS_APR
>>New line:
>>#if APR_HAS_THREADS
>
> +1
>
>>#ifdef HAS_APR
>
>
>>Line # :121
>>Old line :
>>#ifdef APR_HAS_THREADS
>>
>>New line:
>>#if APR_HAS_THREADS
>>
>>Reason: This conditional define statement adjusts variable
>>definition (threadMutex). Type of this variable depends on define
>>directive conditions, but to have needed types there are some #ifdef
>>statements on lines 75-81. So, those definition statements are not
>>the same, and this situation causes build-time error, when compiler
>>includes one header file (with one type defined inside), but variable
>>tries to have another type (found by me in another .h file - not
>>included while build time due to #ifdef directives). Such changes
>>were done experimentally and may be not 100% correct. In original
>>compiler fails with message like "syntax error on before
>>apr_thread_mutex_t in line 121"
>>
>
> apr.h have #define APR_AS_THREADS 1 so both should be the same.
> Didn't have any build error with that on Linux Redhat 7.2 + apache 2.0.39 ...
>
our version of apr.h has #define APR_HAS_THREADS 0
Maybe apache/connector has not been ported properly to FreeBSD?
>
>>Filename jk\native2\build.xml
>>
>>Line # : 374
>>Action : commented
>>
>>Reason : Having this link option uncommented (original) I could
>>not acquire libjkjni.so, only .a and .la files present. As far as I
>>am dummy in FreeBSD C/C++, I used something
>>"try-to-change-something-and-see-what-you-get" method (it has pretty
>>russian idiom,but I don't know its analog in English)
>>
>>Filename: jk\build.properties
>>
>>Some pathes set to correspond to reality (path to apache, etc)
>>
>>Filename: jk\native\apache-2.0\build-unix.sh
>>
>>Line # : 44
>>Action: commented.
>>Line # : 46
>>Action : uncommented and approved
>>New line:
>>INCLUDE="-I ../common -I$APACHE_HOME/include/apr-util $JAVA_INCLUDE"
>
>
> Don't use build-unix.sh but instead configure/make. The build.sh is no more
> present in recent jtc cvs, deprecated in favor of autoconf/make
>
will try this
>
>>Reason : while compiling mod_jk.so compiler could not see
>>connectors includes. I added first statement to make it visible
>>--- patch history end ---
Thanks again
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: mod_jk2.so compiled (after patching), but won't install
Posted by Henri Gomez <hg...@apache.org>.
Quoting Dev Zero G Ltd <ma...@devzerog.com>:
> First of all - many many thanks to everybody who has helped so far - we
> really appreciate it.. Just one last push required. :)
>
> We finally got mod_jk2.so and libjkjni.so to compile (see patch history
> at the bottom of the mail), but can't install. We put them into
> $(APACHE2_HOME)/modules and $(CATALINA_HOME)/lib accordingly.
>
> But after running $(APACHE2_HOME)/bin/apachectl configtest we get an
> error message:
>
> --- error start ---
> file://augada/usr/local/apache2/modules ../bin/apachectl configtest
> Syntax error on line 231 of /usr/local/apache2/conf/httpd.conf:
> Cannot load /usr/local/apache2/modules/mod_jk2.so into server:
> /usr/local/apache2/modules/mod_jk2.so: Undefined symbol
> "apr_thread_mutex_trylock"
> --- error end ---
>
> What could it be?
Which version of Apache 2.0 did you have ?
> --- patch history start ---
> Filename: jk\native2\include\jk_mutex.h
>
> Line # :75
> Old line :
> #ifdef HAS_APR
> New line:
> #if APR_HAS_THREADS
+1
> #ifdef HAS_APR
> Line # :121
> Old line :
> #ifdef APR_HAS_THREADS
>
> New line:
> #if APR_HAS_THREADS
>
> Reason: This conditional define statement adjusts variable
> definition (threadMutex). Type of this variable depends on define
> directive conditions, but to have needed types there are some #ifdef
> statements on lines 75-81. So, those definition statements are not
> the same, and this situation causes build-time error, when compiler
> includes one header file (with one type defined inside), but variable
> tries to have another type (found by me in another .h file - not
> included while build time due to #ifdef directives). Such changes
> were done experimentally and may be not 100% correct. In original
> compiler fails with message like "syntax error on before
> apr_thread_mutex_t in line 121"
>
apr.h have #define APR_AS_THREADS 1 so both should be the same.
Didn't have any build error with that on Linux Redhat 7.2 + apache 2.0.39 ...
> Filename jk\native2\build.xml
>
> Line # : 374
> Action : commented
>
> Reason : Having this link option uncommented (original) I could
> not acquire libjkjni.so, only .a and .la files present. As far as I
> am dummy in FreeBSD C/C++, I used something
> "try-to-change-something-and-see-what-you-get" method (it has pretty
> russian idiom,but I don't know its analog in English)
>
> Filename: jk\build.properties
>
> Some pathes set to correspond to reality (path to apache, etc)
>
> Filename: jk\native\apache-2.0\build-unix.sh
>
> Line # : 44
> Action: commented.
> Line # : 46
> Action : uncommented and approved
> New line:
> INCLUDE="-I ../common -I$APACHE_HOME/include/apr-util $JAVA_INCLUDE"
Don't use build-unix.sh but instead configure/make. The build.sh is no more
present in recent jtc cvs, deprecated in favor of autoconf/make
> Reason : while compiling mod_jk.so compiler could not see
> connectors includes. I added first statement to make it visible
> --- patch history end ---
>
>
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
mod_jk2.so compiled (after patching), but won't install
Posted by Dev Zero G Ltd <ma...@devzerog.com>.
First of all - many many thanks to everybody who has helped so far - we
really appreciate it.. Just one last push required. :)
We finally got mod_jk2.so and libjkjni.so to compile (see patch history
at the bottom of the mail), but can't install. We put them into
$(APACHE2_HOME)/modules and $(CATALINA_HOME)/lib accordingly.
But after running $(APACHE2_HOME)/bin/apachectl configtest we get an
error message:
--- error start ---
file://augada/usr/local/apache2/modules ../bin/apachectl configtest
Syntax error on line 231 of /usr/local/apache2/conf/httpd.conf:
Cannot load /usr/local/apache2/modules/mod_jk2.so into server:
/usr/local/apache2/modules/mod_jk2.so: Undefined symbol
"apr_thread_mutex_trylock"
--- error end ---
What could it be?
--- patch history start ---
Filename: jk\native2\include\jk_mutex.h
Line # :75
Old line :
#ifdef HAS_APR
New line:
#if APR_HAS_THREADS
Line # :121
Old line :
#ifdef APR_HAS_THREADS
New line:
#if APR_HAS_THREADS
Reason: This conditional define statement adjusts variable
definition (threadMutex). Type of this variable depends on define
directive conditions, but to have needed types there are some #ifdef
statements on lines 75-81. So, those definition statements are not
the same, and this situation causes build-time error, when compiler
includes one header file (with one type defined inside), but variable
tries to have another type (found by me in another .h file - not
included while build time due to #ifdef directives). Such changes
were done experimentally and may be not 100% correct. In original
compiler fails with message like "syntax error on before
apr_thread_mutex_t in line 121"
Filename jk\native2\build.xml
Line # : 374
Action : commented
Reason : Having this link option uncommented (original) I could
not acquire libjkjni.so, only .a and .la files present. As far as I
am dummy in FreeBSD C/C++, I used something
"try-to-change-something-and-see-what-you-get" method (it has pretty
russian idiom,but I don't know its analog in English)
Filename: jk\build.properties
Some pathes set to correspond to reality (path to apache, etc)
Filename: jk\native\apache-2.0\build-unix.sh
Line # : 44
Action: commented.
Line # : 46
Action : uncommented and approved
New line:
INCLUDE="-I ../common -I$APACHE_HOME/include/apr-util $JAVA_INCLUDE"
Reason : while compiling mod_jk.so compiler could not see
connectors includes. I added first statement to make it visible
--- patch history end ---
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: JSR77 & tomcat5 configuration
Posted by co...@covalent.net.
On Wed, 24 Jul 2002, Craig R. McClanahan wrote:
> In general, my view is that the JSR-77 standards for managed object
> names, and the corresponding attributes, are not fine grained enough to
> deal with the actual manageable components in a servlet container. We're
> going to need many more MBeans anyway -- it seems like a more viable
> strategy would be to map the standardized names for JSR-77 purposes to the
> corresponding Tomcat MBeans, but focus the Tomcat MBean architecture on
> what we need to manage Tomcat.
That's pretty clear - we'll have much more than what JSR-77 specifies,
but for things that are specified and as general concepts - I think
it would be usefull to stay close.
There are many things that will be slightly different - one example is the
'node' - which in JSR77 is the 'hostname' and we'll need 'hostname:port' (
at least ) since we support more than one instance running on a single
machine.
> As I've mentioned in the past, I'm also fine with looking at alternatives
> to XML-based configuration formats. The *syntax* of the configuration
> parameters is not very important -- the big issue is representing the
> *semantics*. Can you configure every configurable property of every
> component? If you can, then however you want to store it is fine. If you
> can't, then it's time to go back and re-engineer the config data
> persistence design.
+1
> Note that valves already have MBeans today in 4.1 -- extending this to the
> remaining components isn't that difficult :-).
Actually all Interceptors in 3.3 ( the main branch ) and all jk components
have MBeans as well ( dynamic mbeans, but still mbeans ) :-)
What I'm strugling with is the naming conventions and how to map this
in a configuration file ( and make this extensible to non-file based
config ).
> Again, this is focused on syntax. What are your thoughts on my "complete
> coverage of configurable properties for all components" assertion above?
I don't feel this as very hard to achieve. Maybe not random object graphs,
but at least what can be expressed in JMX attributes and the relations
and some object structures similar with what ant provides.
If we think of all configurable components ( vavles, listeners, realms,
interceptors, jkhandlers ) as mbeans - with a well-defined name and
some clear attribute types - then we can express relations using
refIds and we can use some simple patterns like those in ant to configure
complex attributes.
For example today it is difficult to define a Listener ( or Interceptor)
that has some complex attributes, that would require XmlMapper rules.
With ant-like patterns this become possible. It's still not
absolute 'complete coverage', but I think it should reasonably
satisfy your requirement.
What remains hard and where XmlMapper is still the best solution is
web.xml.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: JSR77 & tomcat5 configuration
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Wed, 24 Jul 2002 costinm@covalent.net wrote:
> Date: Wed, 24 Jul 2002 12:10:33 -0700 (PDT)
> From: costinm@covalent.net
> Reply-To: Tomcat Developers List <to...@jakarta.apache.org>
> To: List Tomcat-Dev <to...@jakarta.apache.org>
> Subject: JSR77 & tomcat5 configuration
>
> It seems JSR77 has been posted - I think everyone should read it.
>
In general, my view is that the JSR-77 standards for managed object
names, and the corresponding attributes, are not fine grained enough to
deal with the actual manageable components in a servlet container. We're
going to need many more MBeans anyway -- it seems like a more viable
strategy would be to map the standardized names for JSR-77 purposes to the
corresponding Tomcat MBeans, but focus the Tomcat MBean architecture on
what we need to manage Tomcat.
> What's important is the set of naming conventions for the managed
> objects we expose - I strongly believe that we should use those
> names wherever we provide the equivalent functionality.
>
> For example ( on what is important for me ):
> - 'node' attribute - instead of jvmRoute
> - each tomcat instance in a distributed config must know
> about all other
> - we should start exposing mbeans for JVM, WebModule and
> servlets using the naming conventions.
>
> Of course, we should keep backward compat - but all old
> attribute names should be eventually deprecated.
>
Based on the above assertion, this would be OK with me, but I don't feel
as strongly about it as Costin does.
> As I mentioned in the past, I'm not happy with XmlMapper/Digester
> style used for configuration and I'm not happy with either
> server.xml format or with the way we save the config.
>
As I've mentioned in the past, I'm also fine with looking at alternatives
to XML-based configuration formats. The *syntax* of the configuration
parameters is not very important -- the big issue is representing the
*semantics*. Can you configure every configurable property of every
component? If you can, then however you want to store it is fine. If you
can't, then it's time to go back and re-engineer the config data
persistence design.
> At this moment I have a very strong belief ( and it's getting
> stronger every day ) that we should adopt a configuration
> close to the JMX model, where every configurable object
> is a named mbean.
>
> That means no more Interceptor/Context/Server/Valve/Listener/etc.
>
Note that valves already have MBeans today in 4.1 -- extending this to the
remaining components isn't that difficult :-).
> I also thing the configuration should be centered around a
> class similar with RuntimeConfigurable on ant, where all the
> user settings are stored ( including ${props} ). Any
> configuration action that involves persistence should operate
> on the RuntimeConfigurable, which should deal with saving
> the config ( in a form as close as possible to the original
> user configuration ).
>
Again, this is focused on syntax. What are your thoughts on my "complete
coverage of configurable properties for all components" assertion above?
> While I think XmlMapper/Digester are very powerfull tools, I think
> tomcat5 should follow a model that is closer to ant - i.e.
> a set of patterns and a flatter configuration file. This has proven
> to be easy and is well-understood ( even if I wrote a lot of
> code in xmlMapper, I do have troubles sometimes with it, and
> nobody can claim it's as easy as ant tasks).
>
> The question is: What do you think :-) ?
>
> Costin
>
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>