You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Gustavo Lima <li...@opendf.com.br> on 2003/04/11 22:18:38 UTC
mod_jk compiled in RH 8.0 with apache 2.0.40-11.3
Hi All,
Does anybody have a mod_jk compiled in RH 8.0 with apache 2.0.40*? I´m trying to compile mod_jk for a week and always get errors. I´m sending you all the process:
[root@erosnovo native]# ./buildconf.sh
libtoolize --force --automake --copy
aclocal
automake -a --foreign -i --copy
autoconf
[root@erosnovo native]# ./configure --with-apxs=/usr/sbin/apxs
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
/home/gustavo/jakarta-tomcat-connectors-jk-1.2.2-src/jk/native/scripts/build/unix/missing: Unknown `--run' option
Try `/home/gustavo/jakarta-tomcat-connectors-jk-1.2.2-src/jk/native/scripts/build/unix/missing --help' for more information
configure: WARNING: `missing' script is too old or missing
checking for gawk... gawk
checking whether make sets ${MAKE}... yes
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking for style of include used by make... GNU
checking for gcc... gcc
checking for C compiler default output... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking dependency style of gcc... none
checking for ld used by GCC... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for /usr/bin/ld option to reload object files... -r
checking for BSD-compatible nm... /usr/bin/nm -B
checking whether ln -s works... yes
checking how to recognise dependant libraries... pass_all
checking command to parse /usr/bin/nm -B output... ok
checking how to run the C preprocessor... gcc -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking dlfcn.h usability... yes
checking dlfcn.h presence... yes
checking for dlfcn.h... yes
checking for ranlib... ranlib
checking for strip... strip
checking for objdir... .libs
checking for gcc option to produce PIC... -fPIC
checking if gcc PIC flag -fPIC works... yes
checking if gcc static flag -static works... yes
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.lo... yes
checking if gcc supports -fno-rtti -fno-exceptions... yes
checking whether the linker (/usr/bin/ld) supports shared libraries... yes
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking dynamic linker characteristics... GNU/Linux ld.so
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
checking whether -lc should be explicitly linked in... no
creating libtool
checking for gcc... (cached) gcc
checking whether we are using the GNU C compiler... (cached) yes
checking whether gcc accepts -g... (cached) yes
checking dependency style of gcc... (cached) none
checking for ld used by GCC... (cached) /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... (cached) yes
checking for test... /usr/bin/test
checking for rm... /bin/rm
checking for grep... /bin/grep
checking for echo... /bin/echo
checking for sed... /bin/sed
checking for cp... /bin/cp
checking for mkdir... /bin/mkdir
checking for libtool... /usr/bin/libtool
need to check for Perl first, apxs depends on it...
checking for perl... /usr/bin/perl
building connector for "apache-2.0"
checking for target platform... unix
no apache given
configure: creating ./config.status
config.status: creating Makefile
config.status: creating apache-1.3/Makefile
config.status: creating apache-1.3/Makefile.apxs
config.status: creating apache-2.0/Makefile
config.status: creating apache-2.0/Makefile.apxs
config.status: creating common/Makefile
config.status: creating common/list.mk
config.status: creating jni/Makefile
config.status: executing depfiles commands
[root@erosnovo native]# make
Making all in common
make[1]: Entering directory `/home/gustavo/jakarta-tomcat-connectors-jk-1.2.2-src/jk/native/common'
/usr/bin/libtool --mode=compile gcc -I/usr/include/httpd -g -O2 -O2 -march=i386 -mcpu=i686 -pthread -g -O2 -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -I /include -I /include/ -c jk_ajp12_worker.c
rm -f .libs/jk_ajp12_worker.lo
gcc -I/usr/include/httpd -g -O2 -O2 -march=i386 -mcpu=i686 -pthread -g -O2 -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -I /include -I /include/ -c jk_ajp12_worker.c -fPIC -DPIC -o .libs/jk_ajp12_worker.lo
gcc -I/usr/include/httpd -g -O2 -O2 -march=i386 -mcpu=i686 -pthread -g -O2 -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -I /include -I /include/ -c jk_ajp12_worker.c -o jk_ajp12_worker.o >/dev/null 2>&1
mv -f .libs/jk_ajp12_worker.lo jk_ajp12_worker.lo
/usr/bin/libtool --mode=compile gcc -I/usr/include/httpd -g -O2 -O2 -march=i386 -mcpu=i686 -pthread -g -O2 -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -I /include -I /include/ -c jk_connect.c
rm -f .libs/jk_connect.lo
gcc -I/usr/include/httpd -g -O2 -O2 -march=i386 -mcpu=i686 -pthread -g -O2 -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -I /include -I /include/ -c jk_connect.c -fPIC -DPIC -o .libs/jk_connect.lo
gcc -I/usr/include/httpd -g -O2 -O2 -march=i386 -mcpu=i686 -pthread -g -O2 -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -I /include -I /include/ -c jk_connect.c -o jk_connect.o >/dev/null 2>&1
mv -f .libs/jk_connect.lo jk_connect.lo
/usr/bin/libtool --mode=compile gcc -I/usr/include/httpd -g -O2 -O2 -march=i386 -mcpu=i686 -pthread -g -O2 -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -I /include -I /include/ -c jk_msg_buff.c
rm -f .libs/jk_msg_buff.lo
gcc -I/usr/include/httpd -g -O2 -O2 -march=i386 -mcpu=i686 -pthread -g -O2 -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -I /include -I /include/ -c jk_msg_buff.c -fPIC -DPIC -o .libs/jk_msg_buff.lo
gcc -I/usr/include/httpd -g -O2 -O2 -march=i386 -mcpu=i686 -pthread -g -O2 -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -I /include -I /include/ -c jk_msg_buff.c -o jk_msg_buff.o >/dev/null 2>&1
mv -f .libs/jk_msg_buff.lo jk_msg_buff.lo
/usr/bin/libtool --mode=compile gcc -I/usr/include/httpd -g -O2 -O2 -march=i386 -mcpu=i686 -pthread -g -O2 -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -I /include -I /include/ -c jk_util.c
rm -f .libs/jk_util.lo
gcc -I/usr/include/httpd -g -O2 -O2 -march=i386 -mcpu=i686 -pthread -g -O2 -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -I /include -I /include/ -c jk_util.c -fPIC -DPIC -o .libs/jk_util.lo
gcc -I/usr/include/httpd -g -O2 -O2 -march=i386 -mcpu=i686 -pthread -g -O2 -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -I /include -I /include/ -c jk_util.c -o jk_util.o >/dev/null 2>&1
mv -f .libs/jk_util.lo jk_util.lo
/usr/bin/libtool --mode=compile gcc -I/usr/include/httpd -g -O2 -O2 -march=i386 -mcpu=i686 -pthread -g -O2 -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -I /include -I /include/ -c jk_ajp13.c
rm -f .libs/jk_ajp13.lo
gcc -I/usr/include/httpd -g -O2 -O2 -march=i386 -mcpu=i686 -pthread -g -O2 -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -I /include -I /include/ -c jk_ajp13.c -fPIC -DPIC -o .libs/jk_ajp13.lo
gcc -I/usr/include/httpd -g -O2 -O2 -march=i386 -mcpu=i686 -pthread -g -O2 -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -I /include -I /include/ -c jk_ajp13.c -o jk_ajp13.o >/dev/null 2>&1
mv -f .libs/jk_ajp13.lo jk_ajp13.lo
/usr/bin/libtool --mode=compile gcc -I/usr/include/httpd -g -O2 -O2 -march=i386 -mcpu=i686 -pthread -g -O2 -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -I /include -I /include/ -c jk_pool.c
rm -f .libs/jk_pool.lo
gcc -I/usr/include/httpd -g -O2 -O2 -march=i386 -mcpu=i686 -pthread -g -O2 -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -I /include -I /include/ -c jk_pool.c -fPIC -DPIC -o .libs/jk_pool.lo
gcc -I/usr/include/httpd -g -O2 -O2 -march=i386 -mcpu=i686 -pthread -g -O2 -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -I /include -I /include/ -c jk_pool.c -o jk_pool.o >/dev/null 2>&1
mv -f .libs/jk_pool.lo jk_pool.lo
/usr/bin/libtool --mode=compile gcc -I/usr/include/httpd -g -O2 -O2 -march=i386 -mcpu=i686 -pthread -g -O2 -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -I /include -I /include/ -c jk_worker.c
rm -f .libs/jk_worker.lo
gcc -I/usr/include/httpd -g -O2 -O2 -march=i386 -mcpu=i686 -pthread -g -O2 -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -I /include -I /include/ -c jk_worker.c -fPIC -DPIC -o .libs/jk_worker.lo
gcc -I/usr/include/httpd -g -O2 -O2 -march=i386 -mcpu=i686 -pthread -g -O2 -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -I /include -I /include/ -c jk_worker.c -o jk_worker.o >/dev/null 2>&1
mv -f .libs/jk_worker.lo jk_worker.lo
/usr/bin/libtool --mode=compile gcc -I/usr/include/httpd -g -O2 -O2 -march=i386 -mcpu=i686 -pthread -g -O2 -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -I /include -I /include/ -c jk_ajp13_worker.c
rm -f .libs/jk_ajp13_worker.lo
gcc -I/usr/include/httpd -g -O2 -O2 -march=i386 -mcpu=i686 -pthread -g -O2 -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -I /include -I /include/ -c jk_ajp13_worker.c -fPIC -DPIC -o .libs/jk_ajp13_worker.lo
gcc -I/usr/include/httpd -g -O2 -O2 -march=i386 -mcpu=i686 -pthread -g -O2 -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -I /include -I /include/ -c jk_ajp13_worker.c -o jk_ajp13_worker.o >/dev/null 2>&1
mv -f .libs/jk_ajp13_worker.lo jk_ajp13_worker.lo
/usr/bin/libtool --mode=compile gcc -I/usr/include/httpd -g -O2 -O2 -march=i386 -mcpu=i686 -pthread -g -O2 -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -I /include -I /include/ -c jk_lb_worker.c
rm -f .libs/jk_lb_worker.lo
gcc -I/usr/include/httpd -g -O2 -O2 -march=i386 -mcpu=i686 -pthread -g -O2 -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -I /include -I /include/ -c jk_lb_worker.c -fPIC -DPIC -o .libs/jk_lb_worker.lo
gcc -I/usr/include/httpd -g -O2 -O2 -march=i386 -mcpu=i686 -pthread -g -O2 -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -I /include -I /include/ -c jk_lb_worker.c -o jk_lb_worker.o >/dev/null 2>&1
mv -f .libs/jk_lb_worker.lo jk_lb_worker.lo
/usr/bin/libtool --mode=compile gcc -I/usr/include/httpd -g -O2 -O2 -march=i386 -mcpu=i686 -pthread -g -O2 -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -I /include -I /include/ -c jk_sockbuf.c
rm -f .libs/jk_sockbuf.lo
gcc -I/usr/include/httpd -g -O2 -O2 -march=i386 -mcpu=i686 -pthread -g -O2 -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -I /include -I /include/ -c jk_sockbuf.c -fPIC -DPIC -o .libs/jk_sockbuf.lo
gcc -I/usr/include/httpd -g -O2 -O2 -march=i386 -mcpu=i686 -pthread -g -O2 -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -I /include -I /include/ -c jk_sockbuf.c -o jk_sockbuf.o >/dev/null 2>&1
mv -f .libs/jk_sockbuf.lo jk_sockbuf.lo
/usr/bin/libtool --mode=compile gcc -I/usr/include/httpd -g -O2 -O2 -march=i386 -mcpu=i686 -pthread -g -O2 -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -I /include -I /include/ -c jk_map.c
rm -f .libs/jk_map.lo
gcc -I/usr/include/httpd -g -O2 -O2 -march=i386 -mcpu=i686 -pthread -g -O2 -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -I /include -I /include/ -c jk_map.c -fPIC -DPIC -o .libs/jk_map.lo
gcc -I/usr/include/httpd -g -O2 -O2 -march=i386 -mcpu=i686 -pthread -g -O2 -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -I /include -I /include/ -c jk_map.c -o jk_map.o >/dev/null 2>&1
mv -f .libs/jk_map.lo jk_map.lo
/usr/bin/libtool --mode=compile gcc -I/usr/include/httpd -g -O2 -O2 -march=i386 -mcpu=i686 -pthread -g -O2 -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -I /include -I /include/ -c jk_uri_worker_map.c
rm -f .libs/jk_uri_worker_map.lo
gcc -I/usr/include/httpd -g -O2 -O2 -march=i386 -mcpu=i686 -pthread -g -O2 -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -I /include -I /include/ -c jk_uri_worker_map.c -fPIC -DPIC -o .libs/jk_uri_worker_map.lo
gcc -I/usr/include/httpd -g -O2 -O2 -march=i386 -mcpu=i686 -pthread -g -O2 -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -I /include -I /include/ -c jk_uri_worker_map.c -o jk_uri_worker_map.o >/dev/null 2>&1
mv -f .libs/jk_uri_worker_map.lo jk_uri_worker_map.lo
/usr/bin/libtool --mode=compile gcc -I/usr/include/httpd -g -O2 -O2 -march=i386 -mcpu=i686 -pthread -g -O2 -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -I /include -I /include/ -c jk_ajp14.c
rm -f .libs/jk_ajp14.lo
gcc -I/usr/include/httpd -g -O2 -O2 -march=i386 -mcpu=i686 -pthread -g -O2 -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -I /include -I /include/ -c jk_ajp14.c -fPIC -DPIC -o .libs/jk_ajp14.lo
gcc -I/usr/include/httpd -g -O2 -O2 -march=i386 -mcpu=i686 -pthread -g -O2 -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -I /include -I /include/ -c jk_ajp14.c -o jk_ajp14.o >/dev/null 2>&1
mv -f .libs/jk_ajp14.lo jk_ajp14.lo
/usr/bin/libtool --mode=compile gcc -I/usr/include/httpd -g -O2 -O2 -march=i386 -mcpu=i686 -pthread -g -O2 -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -I /include -I /include/ -c jk_ajp14_worker.c
rm -f .libs/jk_ajp14_worker.lo
gcc -I/usr/include/httpd -g -O2 -O2 -march=i386 -mcpu=i686 -pthread -g -O2 -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -I /include -I /include/ -c jk_ajp14_worker.c -fPIC -DPIC -o .libs/jk_ajp14_worker.lo
gcc -I/usr/include/httpd -g -O2 -O2 -march=i386 -mcpu=i686 -pthread -g -O2 -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -I /include -I /include/ -c jk_ajp14_worker.c -o jk_ajp14_worker.o >/dev/null 2>&1
mv -f .libs/jk_ajp14_worker.lo jk_ajp14_worker.lo
/usr/bin/libtool --mode=compile gcc -I/usr/include/httpd -g -O2 -O2 -march=i386 -mcpu=i686 -pthread -g -O2 -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -I /include -I /include/ -c jk_md5.c
rm -f .libs/jk_md5.lo
gcc -I/usr/include/httpd -g -O2 -O2 -march=i386 -mcpu=i686 -pthread -g -O2 -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -I /include -I /include/ -c jk_md5.c -fPIC -DPIC -o .libs/jk_md5.lo
gcc -I/usr/include/httpd -g -O2 -O2 -march=i386 -mcpu=i686 -pthread -g -O2 -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -I /include -I /include/ -c jk_md5.c -o jk_md5.o >/dev/null 2>&1
mv -f .libs/jk_md5.lo jk_md5.lo
/usr/bin/libtool --mode=compile gcc -I/usr/include/httpd -g -O2 -O2 -march=i386 -mcpu=i686 -pthread -g -O2 -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -I /include -I /include/ -c jk_ajp_common.c
rm -f .libs/jk_ajp_common.lo
gcc -I/usr/include/httpd -g -O2 -O2 -march=i386 -mcpu=i686 -pthread -g -O2 -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -I /include -I /include/ -c jk_ajp_common.c -fPIC -DPIC -o .libs/jk_ajp_common.lo
gcc -I/usr/include/httpd -g -O2 -O2 -march=i386 -mcpu=i686 -pthread -g -O2 -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -I /include -I /include/ -c jk_ajp_common.c -o jk_ajp_common.o >/dev/null 2>&1
mv -f .libs/jk_ajp_common.lo jk_ajp_common.lo
/usr/bin/libtool --mode=compile gcc -I/usr/include/httpd -g -O2 -O2 -march=i386 -mcpu=i686 -pthread -g -O2 -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -I /include -I /include/ -c jk_context.c
rm -f .libs/jk_context.lo
gcc -I/usr/include/httpd -g -O2 -O2 -march=i386 -mcpu=i686 -pthread -g -O2 -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -I /include -I /include/ -c jk_context.c -fPIC -DPIC -o .libs/jk_context.lo
gcc -I/usr/include/httpd -g -O2 -O2 -march=i386 -mcpu=i686 -pthread -g -O2 -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -I /include -I /include/ -c jk_context.c -o jk_context.o >/dev/null 2>&1
mv -f .libs/jk_context.lo jk_context.lo
make[1]: Leaving directory `/home/gustavo/jakarta-tomcat-connectors-jk-1.2.2-src/jk/native/common'
Making all in apache-2.0
make[1]: Entering directory `/home/gustavo/jakarta-tomcat-connectors-jk-1.2.2-src/jk/native/apache-2.0'
/bin/sh /usr/src/redhat/BUILD/httpd-2.0.43/srclib/apr/libtool --silent --mode=compile gcc -I/usr/include/httpd -g -O2 -DUSE_APACHE_MD5 -I ../common -I /include -I /include/unix -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -O2 -march=i386 -mcpu=i686 -pthread -g -O2 -pthread -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -c mod_jk.c
/usr/src/redhat/BUILD/httpd-2.0.43/srclib/apr/libtool: /usr/src/redhat/BUILD/httpd-2.0.43/srclib/apr/libtool: No such file or directory
make[1]: *** [mod_jk.lo] Error 127
make[1]: Leaving directory `/home/gustavo/jakarta-tomcat-connectors-jk-1.2.2-src/jk/native/apache-2.0'
make: *** [all-recursive] Error 1
Does anybody know whats going wrong?
Thanks any help
Gustavo
Re: mod_jk compiled in RH 8.0 with apache 2.0.40-11.3
Posted by John Turner <to...@johnturner.com>.
You don't have a compatible version of libtool, would be my guess.
John
On Fri, 11 Apr 2003 17:18:38 -0300, Gustavo Lima <li...@opendf.com.br>
wrote:
> Hi All,
>
> Does anybody have a mod_jk compiled in RH 8.0 with apache 2.0.40*? I´m
> trying to compile mod_jk for a week and always get errors. I´m sending
> you all the process:
>
> [root@erosnovo native]# ./buildconf.sh libtoolize --force --automake --
> copy
> aclocal
> automake -a --foreign -i --copy
> autoconf
> [root@erosnovo native]# ./configure --with-apxs=/usr/sbin/apxs checking
> for a BSD-compatible install... /usr/bin/install -c
> checking whether build environment is sane... yes
> /home/gustavo/jakarta-tomcat-connectors-jk-1.2.2-
> src/jk/native/scripts/build/unix/missing: Unknown `--run' option
> Try `/home/gustavo/jakarta-tomcat-connectors-jk-1.2.2-
> src/jk/native/scripts/build/unix/missing --help' for more information
> configure: WARNING: `missing' script is too old or missing
> checking for gawk... gawk
> checking whether make sets ${MAKE}... yes
> checking build system type... i686-pc-linux-gnu
> checking host system type... i686-pc-linux-gnu
> checking for style of include used by make... GNU
> checking for gcc... gcc
> checking for C compiler default output... a.out
> checking whether the C compiler works... yes
> checking whether we are cross compiling... no
> checking for suffix of executables... checking for suffix of object
> files... o
> checking whether we are using the GNU C compiler... yes
> checking whether gcc accepts -g... yes
> checking dependency style of gcc... none
> checking for ld used by GCC... /usr/bin/ld
> checking if the linker (/usr/bin/ld) is GNU ld... yes
> checking for /usr/bin/ld option to reload object files... -r
> checking for BSD-compatible nm... /usr/bin/nm -B
> checking whether ln -s works... yes
> checking how to recognise dependant libraries... pass_all
> checking command to parse /usr/bin/nm -B output... ok
> checking how to run the C preprocessor... gcc -E
> checking for ANSI C header files... yes
> checking for sys/types.h... yes
> checking for sys/stat.h... yes
> checking for stdlib.h... yes
> checking for string.h... yes
> checking for memory.h... yes
> checking for strings.h... yes
> checking for inttypes.h... yes
> checking for stdint.h... yes
> checking for unistd.h... yes
> checking dlfcn.h usability... yes
> checking dlfcn.h presence... yes
> checking for dlfcn.h... yes
> checking for ranlib... ranlib
> checking for strip... strip
> checking for objdir... .libs
> checking for gcc option to produce PIC... -fPIC
> checking if gcc PIC flag -fPIC works... yes
> checking if gcc static flag -static works... yes
> checking if gcc supports -c -o file.o... yes
> checking if gcc supports -c -o file.lo... yes
> checking if gcc supports -fno-rtti -fno-exceptions... yes
> checking whether the linker (/usr/bin/ld) supports shared libraries...
> yes
> checking how to hardcode library paths into programs... immediate
> checking whether stripping libraries is possible... yes
> checking dynamic linker characteristics... GNU/Linux ld.so
> checking if libtool supports shared libraries... yes
> checking whether to build shared libraries... yes
> checking whether to build static libraries... yes
> checking whether -lc should be explicitly linked in... no
> creating libtool
> checking for gcc... (cached) gcc
> checking whether we are using the GNU C compiler... (cached) yes
> checking whether gcc accepts -g... (cached) yes
> checking dependency style of gcc... (cached) none
> checking for ld used by GCC... (cached) /usr/bin/ld
> checking if the linker (/usr/bin/ld) is GNU ld... (cached) yes
> checking for test... /usr/bin/test
> checking for rm... /bin/rm
> checking for grep... /bin/grep
> checking for echo... /bin/echo
> checking for sed... /bin/sed
> checking for cp... /bin/cp
> checking for mkdir... /bin/mkdir
> checking for libtool... /usr/bin/libtool
> need to check for Perl first, apxs depends on it...
> checking for perl... /usr/bin/perl
> building connector for "apache-2.0"
> checking for target platform... unix
> no apache given
> configure: creating ./config.status
> config.status: creating Makefile
> config.status: creating apache-1.3/Makefile
> config.status: creating apache-1.3/Makefile.apxs
> config.status: creating apache-2.0/Makefile
> config.status: creating apache-2.0/Makefile.apxs
> config.status: creating common/Makefile
> config.status: creating common/list.mk
> config.status: creating jni/Makefile
> config.status: executing depfiles commands
> [root@erosnovo native]# make
> Making all in common
> make[1]: Entering directory `/home/gustavo/jakarta-tomcat-connectors-jk-
> 1.2.2-src/jk/native/common'
> /usr/bin/libtool --mode=compile gcc -I/usr/include/httpd -g -O2 -O2 -
> march=i386 -mcpu=i686 -pthread -g -O2 -DLINUX=2 -D_REENTRANT -
> D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -I /include
> -I /include/ -c jk_ajp12_worker.c rm -f .libs/jk_ajp12_worker.lo
> gcc -I/usr/include/httpd -g -O2 -O2 -march=i386 -mcpu=i686 -pthread -g -
> O2 -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -
> D_SVID_SOURCE -D_GNU_SOURCE -I /include -I /include/ -c jk_ajp12_worker.c
> -fPIC -DPIC -o .libs/jk_ajp12_worker.lo
> gcc -I/usr/include/httpd -g -O2 -O2 -march=i386 -mcpu=i686 -pthread -g -
> O2 -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -
> D_SVID_SOURCE -D_GNU_SOURCE -I /include -I /include/ -c jk_ajp12_worker.c
> -o jk_ajp12_worker.o >/dev/null 2>&1
> mv -f .libs/jk_ajp12_worker.lo jk_ajp12_worker.lo
> /usr/bin/libtool --mode=compile gcc -I/usr/include/httpd -g -O2 -O2 -
> march=i386 -mcpu=i686 -pthread -g -O2 -DLINUX=2 -D_REENTRANT -
> D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -I /include
> -I /include/ -c jk_connect.c rm -f .libs/jk_connect.lo
> gcc -I/usr/include/httpd -g -O2 -O2 -march=i386 -mcpu=i686 -pthread -g -
> O2 -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -
> D_SVID_SOURCE -D_GNU_SOURCE -I /include -I /include/ -c jk_connect.c -
> fPIC -DPIC -o .libs/jk_connect.lo
> gcc -I/usr/include/httpd -g -O2 -O2 -march=i386 -mcpu=i686 -pthread -g -
> O2 -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -
> D_SVID_SOURCE -D_GNU_SOURCE -I /include -I /include/ -c jk_connect.c -o
> jk_connect.o >/dev/null 2>&1
> mv -f .libs/jk_connect.lo jk_connect.lo
> /usr/bin/libtool --mode=compile gcc -I/usr/include/httpd -g -O2 -O2 -
> march=i386 -mcpu=i686 -pthread -g -O2 -DLINUX=2 -D_REENTRANT -
> D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -I /include
> -I /include/ -c jk_msg_buff.c rm -f .libs/jk_msg_buff.lo
> gcc -I/usr/include/httpd -g -O2 -O2 -march=i386 -mcpu=i686 -pthread -g -
> O2 -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -
> D_SVID_SOURCE -D_GNU_SOURCE -I /include -I /include/ -c jk_msg_buff.c -
> fPIC -DPIC -o .libs/jk_msg_buff.lo
> gcc -I/usr/include/httpd -g -O2 -O2 -march=i386 -mcpu=i686 -pthread -g -
> O2 -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -
> D_SVID_SOURCE -D_GNU_SOURCE -I /include -I /include/ -c jk_msg_buff.c -o
> jk_msg_buff.o >/dev/null 2>&1
> mv -f .libs/jk_msg_buff.lo jk_msg_buff.lo
> /usr/bin/libtool --mode=compile gcc -I/usr/include/httpd -g -O2 -O2 -
> march=i386 -mcpu=i686 -pthread -g -O2 -DLINUX=2 -D_REENTRANT -
> D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -I /include
> -I /include/ -c jk_util.c rm -f .libs/jk_util.lo
> gcc -I/usr/include/httpd -g -O2 -O2 -march=i386 -mcpu=i686 -pthread -g -
> O2 -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -
> D_SVID_SOURCE -D_GNU_SOURCE -I /include -I /include/ -c jk_util.c -fPIC -
>
>
> DPIC -o .libs/jk_util.lo
> gcc -I/usr/include/httpd -g -O2 -O2 -march=i386 -mcpu=i686 -pthread -g -
> O2 -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -
> D_SVID_SOURCE -D_GNU_SOURCE -I /include -I /include/ -c jk_util.c -o
> jk_util.o >/dev/null 2>&1
> mv -f .libs/jk_util.lo jk_util.lo
> /usr/bin/libtool --mode=compile gcc -I/usr/include/httpd -g -O2 -O2 -
> march=i386 -mcpu=i686 -pthread -g -O2 -DLINUX=2 -D_REENTRANT -
> D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -I /include
> -I /include/ -c jk_ajp13.c rm -f .libs/jk_ajp13.lo
> gcc -I/usr/include/httpd -g -O2 -O2 -march=i386 -mcpu=i686 -pthread -g -
> O2 -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -
> D_SVID_SOURCE -D_GNU_SOURCE -I /include -I /include/ -c jk_ajp13.c -fPIC
> -DPIC -o .libs/jk_ajp13.lo
> gcc -I/usr/include/httpd -g -O2 -O2 -march=i386 -mcpu=i686 -pthread -g -
> O2 -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -
> D_SVID_SOURCE -D_GNU_SOURCE -I /include -I /include/ -c jk_ajp13.c -o
> jk_ajp13.o >/dev/null 2>&1
> mv -f .libs/jk_ajp13.lo jk_ajp13.lo
> /usr/bin/libtool --mode=compile gcc -I/usr/include/httpd -g -O2 -O2 -
> march=i386 -mcpu=i686 -pthread -g -O2 -DLINUX=2 -D_REENTRANT -
> D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -I /include
> -I /include/ -c jk_pool.c rm -f .libs/jk_pool.lo
> gcc -I/usr/include/httpd -g -O2 -O2 -march=i386 -mcpu=i686 -pthread -g -
> O2 -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -
> D_SVID_SOURCE -D_GNU_SOURCE -I /include -I /include/ -c jk_pool.c -fPIC -
>
>
> DPIC -o .libs/jk_pool.lo
> gcc -I/usr/include/httpd -g -O2 -O2 -march=i386 -mcpu=i686 -pthread -g -
> O2 -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -
> D_SVID_SOURCE -D_GNU_SOURCE -I /include -I /include/ -c jk_pool.c -o
> jk_pool.o >/dev/null 2>&1
> mv -f .libs/jk_pool.lo jk_pool.lo
> /usr/bin/libtool --mode=compile gcc -I/usr/include/httpd -g -O2 -O2 -
> march=i386 -mcpu=i686 -pthread -g -O2 -DLINUX=2 -D_REENTRANT -
> D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -I /include
> -I /include/ -c jk_worker.c rm -f .libs/jk_worker.lo
> gcc -I/usr/include/httpd -g -O2 -O2 -march=i386 -mcpu=i686 -pthread -g -
> O2 -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -
> D_SVID_SOURCE -D_GNU_SOURCE -I /include -I /include/ -c jk_worker.c -
> fPIC -DPIC -o .libs/jk_worker.lo
> gcc -I/usr/include/httpd -g -O2 -O2 -march=i386 -mcpu=i686 -pthread -g -
> O2 -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -
> D_SVID_SOURCE -D_GNU_SOURCE -I /include -I /include/ -c jk_worker.c -o
> jk_worker.o >/dev/null 2>&1
> mv -f .libs/jk_worker.lo jk_worker.lo
> /usr/bin/libtool --mode=compile gcc -I/usr/include/httpd -g -O2 -O2 -
> march=i386 -mcpu=i686 -pthread -g -O2 -DLINUX=2 -D_REENTRANT -
> D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -I /include
> -I /include/ -c jk_ajp13_worker.c rm -f .libs/jk_ajp13_worker.lo
> gcc -I/usr/include/httpd -g -O2 -O2 -march=i386 -mcpu=i686 -pthread -g -
> O2 -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -
> D_SVID_SOURCE -D_GNU_SOURCE -I /include -I /include/ -c jk_ajp13_worker.c
> -fPIC -DPIC -o .libs/jk_ajp13_worker.lo
> gcc -I/usr/include/httpd -g -O2 -O2 -march=i386 -mcpu=i686 -pthread -g -
> O2 -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -
> D_SVID_SOURCE -D_GNU_SOURCE -I /include -I /include/ -c jk_ajp13_worker.c
> -o jk_ajp13_worker.o >/dev/null 2>&1
> mv -f .libs/jk_ajp13_worker.lo jk_ajp13_worker.lo
> /usr/bin/libtool --mode=compile gcc -I/usr/include/httpd -g -O2 -O2 -
> march=i386 -mcpu=i686 -pthread -g -O2 -DLINUX=2 -D_REENTRANT -
> D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -I /include
> -I /include/ -c jk_lb_worker.c rm -f .libs/jk_lb_worker.lo
> gcc -I/usr/include/httpd -g -O2 -O2 -march=i386 -mcpu=i686 -pthread -g -
> O2 -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -
> D_SVID_SOURCE -D_GNU_SOURCE -I /include -I /include/ -c jk_lb_worker.c -
> fPIC -DPIC -o .libs/jk_lb_worker.lo
> gcc -I/usr/include/httpd -g -O2 -O2 -march=i386 -mcpu=i686 -pthread -g -
> O2 -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -
> D_SVID_SOURCE -D_GNU_SOURCE -I /include -I /include/ -c jk_lb_worker.c -o
> jk_lb_worker.o >/dev/null 2>&1
> mv -f .libs/jk_lb_worker.lo jk_lb_worker.lo
> /usr/bin/libtool --mode=compile gcc -I/usr/include/httpd -g -O2 -O2 -
> march=i386 -mcpu=i686 -pthread -g -O2 -DLINUX=2 -D_REENTRANT -
> D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -I /include
> -I /include/ -c jk_sockbuf.c rm -f .libs/jk_sockbuf.lo
> gcc -I/usr/include/httpd -g -O2 -O2 -march=i386 -mcpu=i686 -pthread -g -
> O2 -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -
> D_SVID_SOURCE -D_GNU_SOURCE -I /include -I /include/ -c jk_sockbuf.c -
> fPIC -DPIC -o .libs/jk_sockbuf.lo
> gcc -I/usr/include/httpd -g -O2 -O2 -march=i386 -mcpu=i686 -pthread -g -
> O2 -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -
> D_SVID_SOURCE -D_GNU_SOURCE -I /include -I /include/ -c jk_sockbuf.c -o
> jk_sockbuf.o >/dev/null 2>&1
> mv -f .libs/jk_sockbuf.lo jk_sockbuf.lo
> /usr/bin/libtool --mode=compile gcc -I/usr/include/httpd -g -O2 -O2 -
> march=i386 -mcpu=i686 -pthread -g -O2 -DLINUX=2 -D_REENTRANT -
> D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -I /include
> -I /include/ -c jk_map.c rm -f .libs/jk_map.lo
> gcc -I/usr/include/httpd -g -O2 -O2 -march=i386 -mcpu=i686 -pthread -g -
> O2 -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -
> D_SVID_SOURCE -D_GNU_SOURCE -I /include -I /include/ -c jk_map.c -fPIC -
> DPIC -o .libs/jk_map.lo
> gcc -I/usr/include/httpd -g -O2 -O2 -march=i386 -mcpu=i686 -pthread -g -
> O2 -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -
> D_SVID_SOURCE -D_GNU_SOURCE -I /include -I /include/ -c jk_map.c -o
> jk_map.o >/dev/null 2>&1
> mv -f .libs/jk_map.lo jk_map.lo
> /usr/bin/libtool --mode=compile gcc -I/usr/include/httpd -g -O2 -O2 -
> march=i386 -mcpu=i686 -pthread -g -O2 -DLINUX=2 -D_REENTRANT -
> D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -I /include
> -I /include/ -c jk_uri_worker_map.c rm -f .libs/jk_uri_worker_map.lo
> gcc -I/usr/include/httpd -g -O2 -O2 -march=i386 -mcpu=i686 -pthread -g -
> O2 -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -
> D_SVID_SOURCE -D_GNU_SOURCE -I /include -I /include/ -c
> jk_uri_worker_map.c -fPIC -DPIC -o .libs/jk_uri_worker_map.lo
> gcc -I/usr/include/httpd -g -O2 -O2 -march=i386 -mcpu=i686 -pthread -g -
> O2 -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -
> D_SVID_SOURCE -D_GNU_SOURCE -I /include -I /include/ -c
> jk_uri_worker_map.c -o jk_uri_worker_map.o >/dev/null 2>&1
> mv -f .libs/jk_uri_worker_map.lo jk_uri_worker_map.lo
> /usr/bin/libtool --mode=compile gcc -I/usr/include/httpd -g -O2 -O2 -
> march=i386 -mcpu=i686 -pthread -g -O2 -DLINUX=2 -D_REENTRANT -
> D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -I /include
> -I /include/ -c jk_ajp14.c rm -f .libs/jk_ajp14.lo
> gcc -I/usr/include/httpd -g -O2 -O2 -march=i386 -mcpu=i686 -pthread -g -
> O2 -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -
> D_SVID_SOURCE -D_GNU_SOURCE -I /include -I /include/ -c jk_ajp14.c -fPIC
> -DPIC -o .libs/jk_ajp14.lo
> gcc -I/usr/include/httpd -g -O2 -O2 -march=i386 -mcpu=i686 -pthread -g -
> O2 -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -
> D_SVID_SOURCE -D_GNU_SOURCE -I /include -I /include/ -c jk_ajp14.c -o
> jk_ajp14.o >/dev/null 2>&1
> mv -f .libs/jk_ajp14.lo jk_ajp14.lo
> /usr/bin/libtool --mode=compile gcc -I/usr/include/httpd -g -O2 -O2 -
> march=i386 -mcpu=i686 -pthread -g -O2 -DLINUX=2 -D_REENTRANT -
> D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -I /include
> -I /include/ -c jk_ajp14_worker.c rm -f .libs/jk_ajp14_worker.lo
> gcc -I/usr/include/httpd -g -O2 -O2 -march=i386 -mcpu=i686 -pthread -g -
> O2 -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -
> D_SVID_SOURCE -D_GNU_SOURCE -I /include -I /include/ -c jk_ajp14_worker.c
> -fPIC -DPIC -o .libs/jk_ajp14_worker.lo
> gcc -I/usr/include/httpd -g -O2 -O2 -march=i386 -mcpu=i686 -pthread -g -
> O2 -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -
> D_SVID_SOURCE -D_GNU_SOURCE -I /include -I /include/ -c jk_ajp14_worker.c
> -o jk_ajp14_worker.o >/dev/null 2>&1
> mv -f .libs/jk_ajp14_worker.lo jk_ajp14_worker.lo
> /usr/bin/libtool --mode=compile gcc -I/usr/include/httpd -g -O2 -O2 -
> march=i386 -mcpu=i686 -pthread -g -O2 -DLINUX=2 -D_REENTRANT -
> D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -I /include
> -I /include/ -c jk_md5.c rm -f .libs/jk_md5.lo
> gcc -I/usr/include/httpd -g -O2 -O2 -march=i386 -mcpu=i686 -pthread -g -
> O2 -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -
> D_SVID_SOURCE -D_GNU_SOURCE -I /include -I /include/ -c jk_md5.c -fPIC -
> DPIC -o .libs/jk_md5.lo
> gcc -I/usr/include/httpd -g -O2 -O2 -march=i386 -mcpu=i686 -pthread -g -
> O2 -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -
> D_SVID_SOURCE -D_GNU_SOURCE -I /include -I /include/ -c jk_md5.c -o
> jk_md5.o >/dev/null 2>&1
> mv -f .libs/jk_md5.lo jk_md5.lo
> /usr/bin/libtool --mode=compile gcc -I/usr/include/httpd -g -O2 -O2 -
> march=i386 -mcpu=i686 -pthread -g -O2 -DLINUX=2 -D_REENTRANT -
> D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -I /include
> -I /include/ -c jk_ajp_common.c rm -f .libs/jk_ajp_common.lo
> gcc -I/usr/include/httpd -g -O2 -O2 -march=i386 -mcpu=i686 -pthread -g -
> O2 -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -
> D_SVID_SOURCE -D_GNU_SOURCE -I /include -I /include/ -c jk_ajp_common.c -
>
>
> fPIC -DPIC -o .libs/jk_ajp_common.lo
> gcc -I/usr/include/httpd -g -O2 -O2 -march=i386 -mcpu=i686 -pthread -g -
> O2 -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -
> D_SVID_SOURCE -D_GNU_SOURCE -I /include -I /include/ -c jk_ajp_common.c -
> o jk_ajp_common.o >/dev/null 2>&1
> mv -f .libs/jk_ajp_common.lo jk_ajp_common.lo
> /usr/bin/libtool --mode=compile gcc -I/usr/include/httpd -g -O2 -O2 -
> march=i386 -mcpu=i686 -pthread -g -O2 -DLINUX=2 -D_REENTRANT -
> D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -I /include
> -I /include/ -c jk_context.c rm -f .libs/jk_context.lo
> gcc -I/usr/include/httpd -g -O2 -O2 -march=i386 -mcpu=i686 -pthread -g -
> O2 -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -
> D_SVID_SOURCE -D_GNU_SOURCE -I /include -I /include/ -c jk_context.c -
> fPIC -DPIC -o .libs/jk_context.lo
> gcc -I/usr/include/httpd -g -O2 -O2 -march=i386 -mcpu=i686 -pthread -g -
> O2 -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -
> D_SVID_SOURCE -D_GNU_SOURCE -I /include -I /include/ -c jk_context.c -o
> jk_context.o >/dev/null 2>&1
> mv -f .libs/jk_context.lo jk_context.lo
> make[1]: Leaving directory `/home/gustavo/jakarta-tomcat-connectors-jk-
> 1.2.2-src/jk/native/common'
> Making all in apache-2.0
> make[1]: Entering directory `/home/gustavo/jakarta-tomcat-connectors-jk-
> 1.2.2-src/jk/native/apache-2.0'
> /bin/sh /usr/src/redhat/BUILD/httpd-2.0.43/srclib/apr/libtool --silent --
> mode=compile gcc -I/usr/include/httpd -g -O2 -DUSE_APACHE_MD5 -I
> ../common -I /include -I /include/unix -DLINUX=2 -D_REENTRANT -
> D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -O2 -
> march=i386 -mcpu=i686 -pthread -g -O2 -pthread -DLINUX=2 -D_REENTRANT -
> D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -c mod_jk.c
> /usr/src/redhat/BUILD/httpd-2.0.43/srclib/apr/libtool:
> /usr/src/redhat/BUILD/httpd-2.0.43/srclib/apr/libtool: No such file or
> directory
> make[1]: *** [mod_jk.lo] Error 127
> make[1]: Leaving directory `/home/gustavo/jakarta-tomcat-connectors-jk-
> 1.2.2-src/jk/native/apache-2.0'
> make: *** [all-recursive] Error 1
>
> Does anybody know whats going wrong?
>
> Thanks any help
>
> Gustavo
>
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: [5.0.2] New tag at the end of the week ?
Posted by Remy Maucherat <re...@apache.org>.
Amy Roh wrote:
> So will you tagging commons-el, fileupload, and daemon as well?
As usual.
REmy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0.2] New tag at the end of the week ?
Posted by Amy Roh <am...@apache.org>.
So will you tagging commons-el, fileupload, and daemon as well?
Thanks,
Amy
Remy Maucherat wrote:
> Hi,
>
> I'd like to avoid big gaps like 5.0.0 -> 5.0.1, so I think it would be
> good to try to tag and release 5.0.2 at the end of the week.
>
> It would be packaged for JDK 1.4, with an optional package containing
> the extra JARs needed for JDK 1.3 (maybe only Xerces - or Crimson - is
> needed ?). If the deployer package could be done by then, it would be
> great (I got a volunteer sending me a private email about that).
>
> Note: I plan to add a new static resource cache by then.
>
> Comments ?
>
> Remy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0.2] New tag at the end of the week ?
Posted by Amy Roh <am...@apache.org>.
+1
Amy
Remy Maucherat wrote:
> Hi,
>
> I'd like to avoid big gaps like 5.0.0 -> 5.0.1, so I think it would be
> good to try to tag and release 5.0.2 at the end of the week.
>
> It would be packaged for JDK 1.4, with an optional package containing
> the extra JARs needed for JDK 1.3 (maybe only Xerces - or Crimson - is
> needed ?). If the deployer package could be done by then, it would be
> great (I got a volunteer sending me a private email about that).
>
> Note: I plan to add a new static resource cache by then.
>
> Comments ?
>
> Remy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: mod_jk 1.2.3
Posted by Glenn Nielsen <gl...@mail.more.net>.
At this point only a vote to release mod_jk 1.2.3 has been conducted.
The release hasn't been done yet.
Looks like there have been enough positive votes.
I will plan on doing the release this weekend.
Regards,
Glenn
Renato wrote:
> Hi,
>
> Could somebody please post the mod_jk 1.2.3 source code link again ? I missed Glenn's e-mail and the archived mailing list is not updated yet...
>
> Thanks !
>
>
>
> ---------------------------------
> Do you Yahoo!?
> The New Yahoo! Search - Faster. Easier. Bingo.
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
mod_jk 1.2.3
Posted by Renato <re...@yahoo.com>.
Hi,
Could somebody please post the mod_jk 1.2.3 source code link again ? I missed Glenn's e-mail and the archived mailing list is not updated yet...
Thanks !
---------------------------------
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
Re: TC5 JMX domain engine issue
Posted by Costin Manolache <cm...@yahoo.com>.
Amy Roh wrote:
>> Maybe we could just register the Engine as a j2eeServer ? This would give
>> us a standard name for the engine. Since tomcat will use it's own private
>> domain - I think it makes sense.
>
> I don't think registering Engine as j2eeServer is a good idea. First of
> all, j2eeServer != Engine for most of App Servers and this won't allow
> having multiple engines in the same server. The semantic of j2eeServer as
> defined in JSR77 suggests that it is an access point to all deployed
> objects (including EJB modules), of course, the concept of Engine does not
> make
> sense for EJBs. If we use JSR77 reserved names for Engine MBean in
> tomcat, there will be no way of removing it from App Server.
I was thinking to the standalone case.
>From a management app perspective, it may be easier to use a standard name
for j2eeServer and navigate to the WebApps, etc. In standalone case - we
only have a servlet container and webapps, so all other fields will be
null.
If tomcat is embeded in a j2ee server - then navigations starts from the
j2eeserver object.
Costin
>
> Thanks,
> Amy
>
>>
>> In any case - WebModule and Servlet can be placed under the same domain
>> with the j2ee server, and tomcat internal components are not required
>> to use jsr77 ( there is no jsr77 requirement for "connector" or "valve")
>>
>> >> >>- An option to configure in which domain the JSR 77 beans go (the
> other
>> >> >>parts of the appserver must have their stuff in the same domain I
>> >> >>assume)
>> >> >
>> >> >
>> >> > I'm leaning toward this option as well. I agree with Amy,
>> >> > registering them in both tomcat and j2ee domain is hacky.
>> >>
>> >> Yeah, I don't think this is a good elegant long term solution. We
> don't
>> >> want to have two mbeans registered in two different domains. When a
>> >> user browses through WebModule & Servlet jsr77 mbeans, you'll see two
>> >> registered in j2eedomain and tomcat each. Hacky.
>> >
>> > I agree that having two mbeans registered in two different domains for
> the
>> > same managed resource is a bad solution. I think the name aliases
> proposal
>> > is also a bad solution. There should only be one ObjectName per MBean
>> > in the system.
>>
>> Yes, we now have one ObjectName per mbean.
>>
>>
>> Costin
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: TC5 JMX domain engine issue
Posted by Amy Roh <am...@apache.org>.
> Hans Hrasna wrote:
>
> > jsr77 allows multiple servers to be grouped under a single domain of
> > control. It also allows a system to have multiple domains. It is
possible
> > to preserve the 1 engine 1 domain 1 service cardinality and still be
jsr77
> > compliant. You current implementation would need to register a
J2EEDomain
> > compliant mbean for each unique domain it creates and a j2eeserver mbean
> > in each domain, which should manage the runtime state of the engine
> > itself. Since you have a 1 domain -> 1 server relationship, they domain
> > and server managed objects may seem redundant, but the domain object has
> > additional requirements, such as aggregating notifications for the
domain
> > (only if it is a eventProvider).
>
> Sounds reasonable.
>
> For now - I already made the changes to place all JSR77 objects in the
> j2ee domain, and leaves tomcat internal components in its own domain.
> But it may be a good idea to add a j2eeDomain/j2eeServer component in
> each tomcat domain.
>
> Maybe we could just register the Engine as a j2eeServer ? This would give
> us a standard name for the engine. Since tomcat will use it's own private
> domain - I think it makes sense.
I don't think registering Engine as j2eeServer is a good idea. First of
all, j2eeServer != Engine for most of App Servers and this won't allow
having multiple engines in the same server. The semantic of j2eeServer as
defined in JSR77 suggests that it is an access point to all deployed objects
(including EJB modules), of course, the concept of Engine does not make
sense for EJBs. If we use JSR77 reserved names for Engine MBean in tomcat,
there will be no way of removing it from App Server.
Thanks,
Amy
>
> In any case - WebModule and Servlet can be placed under the same domain
> with the j2ee server, and tomcat internal components are not required
> to use jsr77 ( there is no jsr77 requirement for "connector" or "valve")
>
> >> >>- An option to configure in which domain the JSR 77 beans go (the
other
> >> >>parts of the appserver must have their stuff in the same domain I
> >> >>assume)
> >> >
> >> >
> >> > I'm leaning toward this option as well. I agree with Amy, registering
> >> > them in both tomcat and j2ee domain is hacky.
> >>
> >> Yeah, I don't think this is a good elegant long term solution. We
don't
> >> want to have two mbeans registered in two different domains. When a
> >> user browses through WebModule & Servlet jsr77 mbeans, you'll see two
> >> registered in j2eedomain and tomcat each. Hacky.
> >
> > I agree that having two mbeans registered in two different domains for
the
> > same managed resource is a bad solution. I think the name aliases
proposal
> > is also a bad solution. There should only be one ObjectName per MBean in
> > the system.
>
> Yes, we now have one ObjectName per mbean.
>
>
> Costin
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: TC5 JMX domain engine issue
Posted by Costin Manolache <cm...@yahoo.com>.
Hans Hrasna wrote:
> jsr77 allows multiple servers to be grouped under a single domain of
> control. It also allows a system to have multiple domains. It is possible
> to preserve the 1 engine 1 domain 1 service cardinality and still be jsr77
> compliant. You current implementation would need to register a J2EEDomain
> compliant mbean for each unique domain it creates and a j2eeserver mbean
> in each domain, which should manage the runtime state of the engine
> itself. Since you have a 1 domain -> 1 server relationship, they domain
> and server managed objects may seem redundant, but the domain object has
> additional requirements, such as aggregating notifications for the domain
> (only if it is a eventProvider).
Sounds reasonable.
For now - I already made the changes to place all JSR77 objects in the
j2ee domain, and leaves tomcat internal components in its own domain.
But it may be a good idea to add a j2eeDomain/j2eeServer component in
each tomcat domain.
Maybe we could just register the Engine as a j2eeServer ? This would give
us a standard name for the engine. Since tomcat will use it's own private
domain - I think it makes sense.
In any case - WebModule and Servlet can be placed under the same domain
with the j2ee server, and tomcat internal components are not required
to use jsr77 ( there is no jsr77 requirement for "connector" or "valve")
>> >>- An option to configure in which domain the JSR 77 beans go (the other
>> >>parts of the appserver must have their stuff in the same domain I
>> >>assume)
>> >
>> >
>> > I'm leaning toward this option as well. I agree with Amy, registering
>> > them in both tomcat and j2ee domain is hacky.
>>
>> Yeah, I don't think this is a good elegant long term solution. We don't
>> want to have two mbeans registered in two different domains. When a
>> user browses through WebModule & Servlet jsr77 mbeans, you'll see two
>> registered in j2eedomain and tomcat each. Hacky.
>
> I agree that having two mbeans registered in two different domains for the
> same managed resource is a bad solution. I think the name aliases proposal
> is also a bad solution. There should only be one ObjectName per MBean in
> the system.
Yes, we now have one ObjectName per mbean.
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: TC5 JMX domain engine issue
Posted by Hans Hrasna <Ha...@east.sun.com>.
Amy Roh wrote:
>
> Changing the subject and ccing the spec lead for more insights.
>
> Costin Manolache wrote:
> > Remy Maucherat wrote:
> >
> >
> >>Personally, here's what I would like:
> >>- 1 engine <-> 1 domain <-> 1 service
> >
> >
> > That provides the cleanest solution for tomcat, and I don't think it hurts
> > anything. We can still have as many engines as we want in the VM.
>
> The problem is that this doesn't follow jsr77. You should be able to
> have more than one server(engine) under one domain (see jsr77.3.2). If
> we treat engine's name as domain and not allow multiple engines under
> one domain we're skipping one level (j2eeserver) and problems occur.
>
> Hans, maybe you can comment on this better?
jsr77 allows multiple servers to be grouped under a single domain of control. It
also allows a system to have multiple domains. It is possible to preserve the 1
engine 1 domain 1 service cardinality and still be jsr77 compliant. You current
implementation would need to register a J2EEDomain compliant mbean for each
unique domain it creates and a j2eeserver mbean in each domain, which should
manage the runtime state of the engine itself. Since you have a 1 domain -> 1
server relationship, they domain and server managed objects may seem redundant,
but the domain object has additional requirements, such as aggregating
notifications for the domain (only if it is a eventProvider).
>
> >>- An option to configure in which domain the JSR 77 beans go (the other
> >>parts of the appserver must have their stuff in the same domain I assume)
> >
> >
> > I'm leaning toward this option as well. I agree with Amy, registering them
> > in both tomcat and j2ee domain is hacky.
>
> Yeah, I don't think this is a good elegant long term solution. We don't
> want to have two mbeans registered in two different domains. When a
> user browses through WebModule & Servlet jsr77 mbeans, you'll see two
> registered in j2eedomain and tomcat each. Hacky.
I agree that having two mbeans registered in two different domains for the same
managed resource is a bad solution. I think the name aliases proposal is also a
bad solution. There should only be one ObjectName per MBean in the system.
>
> > And it makes a lot of sense to do that - tomcat servlet engine(s) provide
> > a certain service ( i.e. implement the servlet spec ), but the webapps
> > should be in the domain that manages them.
> >
> > It is possible to have tomcat manage the webapps ( standalone case ), but if
> > we are in a j2ee server, the server handles deployment and lifecycle. Tomcat
> > only listens what the j2ee server wants ( i.e. add/remove events, etc ) and
> > forwards the requests.
> >
> > I would even go one step further and have all webapps/servlets in a separate
> > domain from tomcat internal components - even in standalone case. This way
> > we could restart the container without having to restart the webapps ( does
> > it makes sense ? Don't know :-)
> >
> >
> >>- A way to set J2EEApplication
> >>- A way to set J2EEServer
> >
> >
> > I think we already have that ( setter methods if you construct the Context
> > directly, or you just include them in the name when you create it via JMX).
>
> I confirm we do have this.
>
> >>I do not like the virtual-virtual-virtual hosting Catalina provides (or
> >>rather provided). It adds complexity and adds problems for little
> >>benefit. With the ability to have services, we already have
> >>virtual-vurtual hosting. I'd like to remove the extra layer, and the
> >>timing is right.
> >
> >
> > Multiple Engines are not a bad thing, quite the contrary. But
> > they should be used in a clean way. JMX domains are a good way to
> > organize the info.
>
> I agree we should decide to use a clean way that follows the spec to
> achieve this goal.
>
> Thanks,
> Amy
>
> >
> > Costin
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
> >
--
Hans Hrasna Java Software
781-442-0231 Hans.Hrasna@Sun.Com
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: TC5 JMX domain engine issue
Posted by Amy Roh <am...@sun.com>.
Costin Manolache wrote:
> Amy Roh wrote:
>
>
>>OK. So we'll add get/setDomain for StandardContext to set j2eeDomain if
>>it's in j2ee container and add "engineName" so it knows which engine,
>>correct? Since servlets use context's domain, I don't think we need
>>domain change code there.
>
>
> getDomain already exists ( in ContainerBase ).
I think we also need to add setDomain to set j2eeDomain in case
deployment isn't done using jmx.
> I'll add "engineName" attribute, if set it'll be used instead of the domain.
Cool.
> How do you deploy the contexts ? My prefference is:
> - create the mbean with whatever name you want ( in your favorite j2ee
> domain ), and the code o.a.c.core.StandardContext
> - set the attributes, including engineName
> - call init - which will look for the engine and register itself.
> - call start ( I think start calls init() if not already done, so in case
> you're using the jsr77 lifecycle - which doesn't have init - you're can
> call directly start )
Sounds good.
> You can still do it directly ( as server.xml does ), but it would help if we
> would settle on the jmx method for cases where tomcat is embeded in another
> app.
We can still keep this for backward compatibility.
>>I can revert the admin changes so it's working once again ;-).
>
>
> A lot of things depend on name stability.
>
> That is one of the reasons I would like tomcat to use JSR77 names whenever
> possible ( i.e. contexts/servlets ).
>
> I think it is probably the time ( i.e. after all this discussion ends ) to
> freeze all JMX names.
+1000000... I think we're getting there.
Once we settle JMX names, admin, and other issues(?) we can finally tag
5.0.2 hopefully.
Thanks,
Amy
>
> Costin
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: TC5 JMX domain engine issue
Posted by Costin Manolache <cm...@yahoo.com>.
Amy Roh wrote:
> OK. So we'll add get/setDomain for StandardContext to set j2eeDomain if
> it's in j2ee container and add "engineName" so it knows which engine,
> correct? Since servlets use context's domain, I don't think we need
> domain change code there.
getDomain already exists ( in ContainerBase ).
I'll add "engineName" attribute, if set it'll be used instead of the domain.
How do you deploy the contexts ? My prefference is:
- create the mbean with whatever name you want ( in your favorite j2ee
domain ), and the code o.a.c.core.StandardContext
- set the attributes, including engineName
- call init - which will look for the engine and register itself.
- call start ( I think start calls init() if not already done, so in case
you're using the jsr77 lifecycle - which doesn't have init - you're can
call directly start )
You can still do it directly ( as server.xml does ), but it would help if we
would settle on the jmx method for cases where tomcat is embeded in another
app.
> I can revert the admin changes so it's working once again ;-).
A lot of things depend on name stability.
That is one of the reasons I would like tomcat to use JSR77 names whenever
possible ( i.e. contexts/servlets ).
I think it is probably the time ( i.e. after all this discussion ends ) to
freeze all JMX names.
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: TC5 JMX domain engine issue
Posted by Amy Roh <am...@apache.org>.
Costin Manolache wrote:
> Amy Roh wrote:
>
>
>>I don't know about having _all_ names in the same domain. However,
>>webmodules and servlets should be under the same domain as the
>>J2EEServer who's responsible for its deployment.
>
>
> Ok. As long as they are not _required_ to be in the same domain with
> the servlet engine internal components.
>
> It makes sense - if we consider that in this case the j2ee server is
> actually responsible for the webapps ( deployment, lifecycle ).
>
>
>
>>>If this is the case - the only option is to treat tomcat as a separate
>>>entity, in a separate domain from the webapps.
>>>
>>>We have 3 options:
>>>- Webapps registered once, in the jsr77Domain. Tomcat will listen for
>>>events and register them, but nothing else ( i.e. no contexts in the
>>>tomcat domain)
>>
>>+1. We can keep context mbeans under tomcat domain in tomcat standalone
>>case - keep it the way it is?
>
>
> Ok.
>
> Are you already working on this ? I can try a quick fix, it shouldn't be
> very difficult. ( probably this evening or tommorow night ).
OK. So we'll add get/setDomain for StandardContext to set j2eeDomain if
it's in j2ee container and add "engineName" so it knows which engine,
correct? Since servlets use context's domain, I don't think we need
domain change code there.
I can revert the admin changes so it's working once again ;-).
Thanks,
Amy
>
> Costin
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: TC5 JMX domain engine issue
Posted by Costin Manolache <cm...@yahoo.com>.
Amy Roh wrote:
> I don't know about having _all_ names in the same domain. However,
> webmodules and servlets should be under the same domain as the
> J2EEServer who's responsible for its deployment.
Ok. As long as they are not _required_ to be in the same domain with
the servlet engine internal components.
It makes sense - if we consider that in this case the j2ee server is
actually responsible for the webapps ( deployment, lifecycle ).
>> If this is the case - the only option is to treat tomcat as a separate
>> entity, in a separate domain from the webapps.
>>
>> We have 3 options:
>> - Webapps registered once, in the jsr77Domain. Tomcat will listen for
>> events and register them, but nothing else ( i.e. no contexts in the
>> tomcat domain)
>
> +1. We can keep context mbeans under tomcat domain in tomcat standalone
> case - keep it the way it is?
Ok.
Are you already working on this ? I can try a quick fix, it shouldn't be
very difficult. ( probably this evening or tommorow night ).
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: TC5 JMX domain engine issue
Posted by Amy Roh <am...@apache.org>.
Costin Manolache wrote:
> Amy Roh wrote:
>
>
>>>>>>Personally, here's what I would like:
>>>>>>- 1 engine <-> 1 domain <-> 1 service
>>>>>
>>>>>
>>>>>That provides the cleanest solution for tomcat, and I don't think it
>>>>>hurts anything. We can still have as many engines as we want in the VM.
>>>>
>>>>The problem is that this doesn't follow jsr77. You should be able to
>>>>have more than one server(engine) under one domain (see jsr77.3.2). If
>>>>we treat engine's name as domain and not allow multiple engines under
>>>>one domain we're skipping one level (j2eeserver) and problems occur.
>>>
>>>
>>>Can you have more than one J2EE server under one domain ?
>>
>>Yes - JSR77.3.2.1.
>
>
> It seems my undersanding of JSR77 was completely off...
>
> I assumed that 77.3.2 and the servers[] reffer more to a cluster-like
> setup, not to have multiple J2EE server in the same VM.
>
> And the fact that all navigation is in terms of ObjectName[] missled me
> to think that you can have any object name - this is the first I hear the
> restriction that _all_ names need to be in the same domain.
I don't know about having _all_ names in the same domain. However,
webmodules and servlets should be under the same domain as the
J2EEServer who's responsible for its deployment.
> If this is the case - the only option is to treat tomcat as a separate
> entity, in a separate domain from the webapps.
>
> We have 3 options:
> - Webapps registered once, in the jsr77Domain. Tomcat will listen for events
> and register them, but nothing else ( i.e. no contexts in the tomcat
> domain)
+1. We can keep context mbeans under tomcat domain in tomcat standalone
case - keep it the way it is?
> - webapps registered twice, once in tomcat domain and once in the JSR77
> domain. That can use either the same (local) name, or we can use the name
> in tomcat4.1 ( but what would admin use ? IMO it should be the standard
> names ).
>
> - webapps registered once, in tomcat domain - and wrappers registered in
> the jsr77Domain.
>
>
>
>>>You can register WebModules in any domain - all we need is an attribute (
>>>not even part of the name ) that tells wich engine it needs to be
>>>registered in.
>>
>>I was under impression that WebModules have to be in the same domain as
>>engine in order for everything to work. If all we need is engineName,
>>then we won't have to register them twice. :-)
>
>
> I don't see any need.
>
> The do need to know the domain of the engine - but you can configure this
> as an attribute. The only need is to construct the engine name - so it can
> invoke the addContext() callback.
>
>
>
>
>>>>I agree we should decide to use a clean way that follows the spec to
>>>>achieve this goal.
>>>
>>>
>>>+1 - if tomcat is to support JSR77 ( for contexts/servlets ), it needs to
>>>be able to place them in the j2eeServer domain, and if multiple engines
>>>are used each must use the same domain for webmodules ( as long as they
>>>are part of the same j2eeServer ).
>>
>>I don't see how this can be achieved if we don't allow multiple engines
>>per domain. You're saying "if multiple engines are used, each must use
>>the same domain for webmodules." But we don't allow multiple engines to
>>share the same domain as for webmodules that are placed in the
>>j2eeServer domain. Doesn't it make sense to put the engines under the
>>same j2eeDomain in order for it to work?
>
>
> There is no reason to have the webapps and the engine in the same domain. It
> may be even cleaner if they are in separate domains.
> There is no reason to even have the connector in the same domain with the
> engine.
>
> All we need is that each component is able to find the other components it
> needs. That can be done by constructing it's name using the same domain,
> but it is easy to override it.
>
> Sorry - I allways was under the impression that JSR77 doesn't require that
> all components are in the same domain, and you can just navigate from root
> to any component using the ObjectNames.
>
>
> Costin
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: TC5 JMX domain engine issue
Posted by Costin Manolache <cm...@yahoo.com>.
Amy Roh wrote:
>>>>>Personally, here's what I would like:
>>>>>- 1 engine <-> 1 domain <-> 1 service
>>>>
>>>>
>>>>That provides the cleanest solution for tomcat, and I don't think it
>>>>hurts anything. We can still have as many engines as we want in the VM.
>>>
>>>The problem is that this doesn't follow jsr77. You should be able to
>>>have more than one server(engine) under one domain (see jsr77.3.2). If
>>>we treat engine's name as domain and not allow multiple engines under
>>>one domain we're skipping one level (j2eeserver) and problems occur.
>>
>>
>> Can you have more than one J2EE server under one domain ?
>
> Yes - JSR77.3.2.1.
It seems my undersanding of JSR77 was completely off...
I assumed that 77.3.2 and the servers[] reffer more to a cluster-like
setup, not to have multiple J2EE server in the same VM.
And the fact that all navigation is in terms of ObjectName[] missled me
to think that you can have any object name - this is the first I hear the
restriction that _all_ names need to be in the same domain.
If this is the case - the only option is to treat tomcat as a separate
entity, in a separate domain from the webapps.
We have 3 options:
- Webapps registered once, in the jsr77Domain. Tomcat will listen for events
and register them, but nothing else ( i.e. no contexts in the tomcat
domain)
- webapps registered twice, once in tomcat domain and once in the JSR77
domain. That can use either the same (local) name, or we can use the name
in tomcat4.1 ( but what would admin use ? IMO it should be the standard
names ).
- webapps registered once, in tomcat domain - and wrappers registered in
the jsr77Domain.
>> You can register WebModules in any domain - all we need is an attribute (
>> not even part of the name ) that tells wich engine it needs to be
>> registered in.
>
> I was under impression that WebModules have to be in the same domain as
> engine in order for everything to work. If all we need is engineName,
> then we won't have to register them twice. :-)
I don't see any need.
The do need to know the domain of the engine - but you can configure this
as an attribute. The only need is to construct the engine name - so it can
invoke the addContext() callback.
>>>I agree we should decide to use a clean way that follows the spec to
>>>achieve this goal.
>>
>>
>> +1 - if tomcat is to support JSR77 ( for contexts/servlets ), it needs to
>> be able to place them in the j2eeServer domain, and if multiple engines
>> are used each must use the same domain for webmodules ( as long as they
>> are part of the same j2eeServer ).
>
> I don't see how this can be achieved if we don't allow multiple engines
> per domain. You're saying "if multiple engines are used, each must use
> the same domain for webmodules." But we don't allow multiple engines to
> share the same domain as for webmodules that are placed in the
> j2eeServer domain. Doesn't it make sense to put the engines under the
> same j2eeDomain in order for it to work?
There is no reason to have the webapps and the engine in the same domain. It
may be even cleaner if they are in separate domains.
There is no reason to even have the connector in the same domain with the
engine.
All we need is that each component is able to find the other components it
needs. That can be done by constructing it's name using the same domain,
but it is easy to override it.
Sorry - I allways was under the impression that JSR77 doesn't require that
all components are in the same domain, and you can just navigate from root
to any component using the ObjectNames.
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: TC5 JMX domain engine issue
Posted by Amy Roh <am...@sun.com>.
Costin Manolache wrote:
> Amy Roh wrote:
>
>
>>>>Personally, here's what I would like:
>>>>- 1 engine <-> 1 domain <-> 1 service
>>>
>>>
>>>That provides the cleanest solution for tomcat, and I don't think it
>>>hurts anything. We can still have as many engines as we want in the VM.
>>
>>The problem is that this doesn't follow jsr77. You should be able to
>>have more than one server(engine) under one domain (see jsr77.3.2). If
>>we treat engine's name as domain and not allow multiple engines under
>>one domain we're skipping one level (j2eeserver) and problems occur.
>
>
> Can you have more than one J2EE server under one domain ?
Yes - JSR77.3.2.1.
> Is there anything in the J2EE spec that requires a J2EE server to support
> more than one Servlet Engine ?
Not sure.
>
> Please keep in mind that tomcat itself ( the Engine, connectors, etc ) are
> _not_ constrainted by JSR77. Only the WebModule and Servlet are defined in
> 77.
Right.
>>>>- An option to configure in which domain the JSR 77 beans go (the other
>>>>parts of the appserver must have their stuff in the same domain I assume)
>>>
>>>
>>>I'm leaning toward this option as well. I agree with Amy, registering
>>>them in both tomcat and j2ee domain is hacky.
>>
>>Yeah, I don't think this is a good elegant long term solution. We don't
>>want to have two mbeans registered in two different domains. When a
>>user browses through WebModule & Servlet jsr77 mbeans, you'll see two
>>registered in j2eedomain and tomcat each. Hacky.
>
>
> There is no need to register them twice. The mapper receives notifications
> for all domains.
Cool!
> You can register WebModules in any domain - all we need is an attribute (
> not even part of the name ) that tells wich engine it needs to be
> registered in.
I was under impression that WebModules have to be in the same domain as
engine in order for everything to work. If all we need is engineName,
then we won't have to register them twice. :-)
>
>>>Multiple Engines are not a bad thing, quite the contrary. But
>>>they should be used in a clean way. JMX domains are a good way to
>>>organize the info.
>>
>>I agree we should decide to use a clean way that follows the spec to
>>achieve this goal.
>
>
> +1 - if tomcat is to support JSR77 ( for contexts/servlets ), it needs to
> be able to place them in the j2eeServer domain, and if multiple engines are
> used each must use the same domain for webmodules ( as long as they are
> part of the same j2eeServer ).
I don't see how this can be achieved if we don't allow multiple engines
per domain. You're saying "if multiple engines are used, each must use
the same domain for webmodules." But we don't allow multiple engines to
share the same domain as for webmodules that are placed in the
j2eeServer domain. Doesn't it make sense to put the engines under the
same j2eeDomain in order for it to work?
> That doesn't impose any restrictions on the domain for tomcat.
>
> We could as well use one domain for the Engine, Mapper and all
> servlet-implementation components, and a separate domain for the connector.
> ( for a use case of having one connector used for multiple engines for
> example.
>
> Placing too many components in the same domain results in a mess. It may be
> much better to not place non-JSR77 components ( like Engine or Connector )
> in the jsr77 domain.
>
> The only issue is that the components registered in jsr77 for WebModule
> should be either StandardContext or a proxy/wrapper that exposes the info
> and operations in StandardContext. Maybe with some changes ( for Statistics
> for example ).
>
>
> Costin
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: TC5 JMX domain engine issue
Posted by Costin Manolache <cm...@yahoo.com>.
Amy Roh wrote:
>>>Personally, here's what I would like:
>>>- 1 engine <-> 1 domain <-> 1 service
>>
>>
>> That provides the cleanest solution for tomcat, and I don't think it
>> hurts anything. We can still have as many engines as we want in the VM.
>
> The problem is that this doesn't follow jsr77. You should be able to
> have more than one server(engine) under one domain (see jsr77.3.2). If
> we treat engine's name as domain and not allow multiple engines under
> one domain we're skipping one level (j2eeserver) and problems occur.
Can you have more than one J2EE server under one domain ?
Is there anything in the J2EE spec that requires a J2EE server to support
more than one Servlet Engine ?
Please keep in mind that tomcat itself ( the Engine, connectors, etc ) are
_not_ constrainted by JSR77. Only the WebModule and Servlet are defined in
77.
>>>- An option to configure in which domain the JSR 77 beans go (the other
>>>parts of the appserver must have their stuff in the same domain I assume)
>>
>>
>> I'm leaning toward this option as well. I agree with Amy, registering
>> them in both tomcat and j2ee domain is hacky.
>
> Yeah, I don't think this is a good elegant long term solution. We don't
> want to have two mbeans registered in two different domains. When a
> user browses through WebModule & Servlet jsr77 mbeans, you'll see two
> registered in j2eedomain and tomcat each. Hacky.
There is no need to register them twice. The mapper receives notifications
for all domains.
You can register WebModules in any domain - all we need is an attribute (
not even part of the name ) that tells wich engine it needs to be
registered in.
>> Multiple Engines are not a bad thing, quite the contrary. But
>> they should be used in a clean way. JMX domains are a good way to
>> organize the info.
>
> I agree we should decide to use a clean way that follows the spec to
> achieve this goal.
+1 - if tomcat is to support JSR77 ( for contexts/servlets ), it needs to
be able to place them in the j2eeServer domain, and if multiple engines are
used each must use the same domain for webmodules ( as long as they are
part of the same j2eeServer ).
That doesn't impose any restrictions on the domain for tomcat.
We could as well use one domain for the Engine, Mapper and all
servlet-implementation components, and a separate domain for the connector.
( for a use case of having one connector used for multiple engines for
example.
Placing too many components in the same domain results in a mess. It may be
much better to not place non-JSR77 components ( like Engine or Connector )
in the jsr77 domain.
The only issue is that the components registered in jsr77 for WebModule
should be either StandardContext or a proxy/wrapper that exposes the info
and operations in StandardContext. Maybe with some changes ( for Statistics
for example ).
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
TC5 JMX domain engine issue
Posted by Amy Roh <am...@apache.org>.
Changing the subject and ccing the spec lead for more insights.
Costin Manolache wrote:
> Remy Maucherat wrote:
>
>
>>Personally, here's what I would like:
>>- 1 engine <-> 1 domain <-> 1 service
>
>
> That provides the cleanest solution for tomcat, and I don't think it hurts
> anything. We can still have as many engines as we want in the VM.
The problem is that this doesn't follow jsr77. You should be able to
have more than one server(engine) under one domain (see jsr77.3.2). If
we treat engine's name as domain and not allow multiple engines under
one domain we're skipping one level (j2eeserver) and problems occur.
Hans, maybe you can comment on this better?
>>- An option to configure in which domain the JSR 77 beans go (the other
>>parts of the appserver must have their stuff in the same domain I assume)
>
>
> I'm leaning toward this option as well. I agree with Amy, registering them
> in both tomcat and j2ee domain is hacky.
Yeah, I don't think this is a good elegant long term solution. We don't
want to have two mbeans registered in two different domains. When a
user browses through WebModule & Servlet jsr77 mbeans, you'll see two
registered in j2eedomain and tomcat each. Hacky.
> And it makes a lot of sense to do that - tomcat servlet engine(s) provide
> a certain service ( i.e. implement the servlet spec ), but the webapps
> should be in the domain that manages them.
>
> It is possible to have tomcat manage the webapps ( standalone case ), but if
> we are in a j2ee server, the server handles deployment and lifecycle. Tomcat
> only listens what the j2ee server wants ( i.e. add/remove events, etc ) and
> forwards the requests.
>
> I would even go one step further and have all webapps/servlets in a separate
> domain from tomcat internal components - even in standalone case. This way
> we could restart the container without having to restart the webapps ( does
> it makes sense ? Don't know :-)
>
>
>>- A way to set J2EEApplication
>>- A way to set J2EEServer
>
>
> I think we already have that ( setter methods if you construct the Context
> directly, or you just include them in the name when you create it via JMX).
I confirm we do have this.
>>I do not like the virtual-virtual-virtual hosting Catalina provides (or
>>rather provided). It adds complexity and adds problems for little
>>benefit. With the ability to have services, we already have
>>virtual-vurtual hosting. I'd like to remove the extra layer, and the
>>timing is right.
>
>
> Multiple Engines are not a bad thing, quite the contrary. But
> they should be used in a clean way. JMX domains are a good way to
> organize the info.
I agree we should decide to use a clean way that follows the spec to
achieve this goal.
Thanks,
Amy
>
> Costin
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0.2] New tag at the end of the week ?
Posted by Costin Manolache <cm...@yahoo.com>.
Remy Maucherat wrote:
> Personally, here's what I would like:
> - 1 engine <-> 1 domain <-> 1 service
That provides the cleanest solution for tomcat, and I don't think it hurts
anything. We can still have as many engines as we want in the VM.
> - An option to configure in which domain the JSR 77 beans go (the other
> parts of the appserver must have their stuff in the same domain I assume)
I'm leaning toward this option as well. I agree with Amy, registering them
in both tomcat and j2ee domain is hacky.
And it makes a lot of sense to do that - tomcat servlet engine(s) provide
a certain service ( i.e. implement the servlet spec ), but the webapps
should be in the domain that manages them.
It is possible to have tomcat manage the webapps ( standalone case ), but if
we are in a j2ee server, the server handles deployment and lifecycle. Tomcat
only listens what the j2ee server wants ( i.e. add/remove events, etc ) and
forwards the requests.
I would even go one step further and have all webapps/servlets in a separate
domain from tomcat internal components - even in standalone case. This way
we could restart the container without having to restart the webapps ( does
it makes sense ? Don't know :-)
> - A way to set J2EEApplication
> - A way to set J2EEServer
I think we already have that ( setter methods if you construct the Context
directly, or you just include them in the name when you create it via JMX).
> I do not like the virtual-virtual-virtual hosting Catalina provides (or
> rather provided). It adds complexity and adds problems for little
> benefit. With the ability to have services, we already have
> virtual-vurtual hosting. I'd like to remove the extra layer, and the
> timing is right.
Multiple Engines are not a bad thing, quite the contrary. But
they should be used in a clean way. JMX domains are a good way to
organize the info.
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0.2] New tag at the end of the week ?
Posted by Remy Maucherat <re...@apache.org>.
Amy Roh wrote:
>>Amy Roh wrote:
>>
>>
>>>>No, you can't change the object name of Servlet and WebModule. It is
>>>>defined in JSR77, and we're stuck with the attributes there. Can't
>>>>"extend" the standard by adding more to the names.
>>>
>>>Where does it say that? J2EEManagedObject objectName has syntax of
>>>
>
> [domainName]:j2eeType=value,name=value,<parent-j2eeType>[,property=value]
>
>>>77.3.1.1.2 says the key property list must contain at least the
>>>mandatory key properties but doesn't limit to only mandatory. It says
>>>"it may contain any number of optional key properties whose order is not
>>>significant". I think you can add "engineName" attribute.
>>
>>I missed that part. Well, it seems there are few other things
>>that are missing in the jsr77 impl.
>>
>>So the question remain if we want to add the "engine=XXX" to all mbeans,
>>and the code to use the engine name when refering to other components.
>
>
> Do we have to add "engineName" to *all* mbeans?
>
> How about we add an option to set "J2EEDomain" for WebModule and Servlet?
> So when J2EEDomain for those components aren't null, we can register the
> mbeans under J2EEDomain as well as tomcat domain. At the time of
> registration we can save tomcatDomain name as "engineName" for those J2EE
> mbeans. In Tomcat, we can just look at "engineName" for WebModule and
> Servlet mbeans to do JMX operations if they're set to something. If not, we
> can assume its domain is the same as tomcat domain. This way we won't have
> to change other components (keep one engine per domain) and should work both
> in Tomcat and J2EE world? I'll check with jsr77 to see if registering in
> both domains are ok and if there're better ways to handle this.
Personally, here's what I would like:
- 1 engine <-> 1 domain <-> 1 service
- An option to configure in which domain the JSR 77 beans go (the other
parts of the appserver must have their stuff in the same domain I assume)
- A way to set J2EEApplication
- A way to set J2EEServer
I do not like the virtual-virtual-virtual hosting Catalina provides (or
rather provided). It adds complexity and adds problems for little
benefit. With the ability to have services, we already have
virtual-vurtual hosting. I'd like to remove the extra layer, and the
timing is right.
<rant>
BTW, if I sound nervous, it's because of your coworkers. I do not really
care about integration issues with whatever appserver you have (if Sun
paid me something, maybe I would care more :-D ), be it the RI or SunOne
(however, I do care about the JBoss integration ;-) ). I can send my
sympathy because you guys have an integration deadline or whatever, but
that's it.
I'm so glad I don't have to attend those bugtraq meetings anymore :-P
</rant>
Remy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: TC5 JMX domain engine issue
Posted by Costin Manolache <cm...@yahoo.com>.
Amy Roh wrote:
> Costin Manolache wrote:
>> Amy - one more question.
>>
>> What if we just move back to not support JSR77 directly in tomcat ?
>
> Yeah, this is an option. Remember I asked a while ago about turning off
> jmx in TC5. That was due to the same reason. Tomcat supports JSR77
> partially. It might be better for j2ee container to use tomcat mbeans
> to do jsr77 stuff.
My only concern ( now and then ) was to make sure that all
attributes/operations that tomcat supports be exposed in the container.
One way or another - the state management, statistics, etc should be
delegated to tomcat.
BTW, jboss also has its own layer for JSR77, and nothing ever restricted you
on using a similar approach and just ignore the tomcat names.
Tomcat is in a different domain - and it doesn't affect in any way the
jsr77 domain.
>> Decoupling them - I think you already suggested that - would probably
>> loose some info and control, at least in a simple implementation. But it
>> can be done via a dynamic or model mbean that proxies all the methods and
>> attributes in StandardContext, and adds the extra JSR77 specific stuff
>> (i.e statistics, etc ).
>
> I'd like to hear Han's comment on this. This means the admin webapp
> needs to be rewritten *again!* to accommodate the new objectnames. :-(
> I'm open to what's the best.
Well... Sorry for the admin.
BTW, if the admin is going to use the JSR77 names - then we have to keep
supporting JSR77 in tomcat standalone. Keep in mind tomcat can work without
a J2EE server :-)
The whole poing of JSR77 is to allow apps a consistent access to webapps
names. In tomcat standalone - admin or any other app should be able to use
the same kind of names it would use in a j2ee container.
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: TC5 JMX domain engine issue
Posted by Amy Roh <am...@apache.org>.
Costin Manolache wrote:
> Amy - one more question.
>
> What if we just move back to not support JSR77 directly in tomcat ?
Yeah, this is an option. Remember I asked a while ago about turning off
jmx in TC5. That was due to the same reason. Tomcat supports JSR77
partially. It might be better for j2ee container to use tomcat mbeans
to do jsr77 stuff.
>
> I was reading jsr77 again - and it may be a better idea to just use
> type=Context, etc - internal tomcat names, etc.
>
> Then a j2ee container could just wrap those objects. The problem is that
> if we want to support the statistics ( and we do have a lot of metrics
> already ), JSR77 requires us to depend on javax.management.j2ee.statistics
> and present them in a certain way. Nothing wrong with that - but we can
> have an easier life if we leave this for the people who integrate tomcat
> in a j2ee server.
>
> The reason I tought we should implement jsr77 in tomcat was the fact that we
> do have all the information already, and it would be easier for us to just
> use the standard names ( even if 1/2 of it is not used - j2eeApp and
> server). And it seemed logical that the StandardContext object, which is
> the tomcat implementation of a WebApplication, is registered as a jsr77,
> without another intermediary.
>
> Decoupling them - I think you already suggested that - would probably loose
> some info and control, at least in a simple implementation. But it can be
> done via a dynamic or model mbean that proxies all the methods and
> attributes in StandardContext, and adds the extra JSR77 specific stuff (i.e
> statistics, etc ).
I'd like to hear Han's comment on this. This means the admin webapp
needs to be rewritten *again!* to accommodate the new objectnames. :-(
I'm open to what's the best.
Thanks Costin!
Amy
>
> Would that be a better solution for you ?
>
>
> Costin
>
>
>
> Amy Roh wrote:
>
>
>>>Amy Roh wrote:
>>>
>>>
>>>>>No, you can't change the object name of Servlet and WebModule. It is
>>>>>defined in JSR77, and we're stuck with the attributes there. Can't
>>>>>"extend" the standard by adding more to the names.
>>>>
>>>>Where does it say that? J2EEManagedObject objectName has syntax of
>>>>
>>>
>>[domainName]:j2eeType=value,name=value,<parent-j2eeType>[,property=value]
>>
>>>>77.3.1.1.2 says the key property list must contain at least the
>>>>mandatory key properties but doesn't limit to only mandatory. It says
>>>>"it may contain any number of optional key properties whose order is
>>>>not
>>>>significant". I think you can add "engineName" attribute.
>>>
>>>I missed that part. Well, it seems there are few other things
>>>that are missing in the jsr77 impl.
>>>
>>>So the question remain if we want to add the "engine=XXX" to all mbeans,
>>>and the code to use the engine name when refering to other components.
>>
>>Do we have to add "engineName" to *all* mbeans?
>>
>>How about we add an option to set "J2EEDomain" for WebModule and Servlet?
>>So when J2EEDomain for those components aren't null, we can register the
>>mbeans under J2EEDomain as well as tomcat domain. At the time of
>>registration we can save tomcatDomain name as "engineName" for those J2EE
>>mbeans. In Tomcat, we can just look at "engineName" for WebModule and
>>Servlet mbeans to do JMX operations if they're set to something. If not,
>>we
>>can assume its domain is the same as tomcat domain. This way we won't
>>have to change other components (keep one engine per domain) and should
>>work both
>>in Tomcat and J2EE world? I'll check with jsr77 to see if registering in
>>both domains are ok and if there're better ways to handle this.
>>
>>Thanks,
>>Amy
>>
>>
>>>>>I'm very much against multiple engines per domain because of the same
>>>>>reason - it adds complexity :-) The problem is that it adds complexity
>>>>
>>in
>>
>>>>>the common case ( one Engine per domain - most people don't have
>>>>
>>multiple
>>
>>>>>servlet engines running in the same VM ), in order to support a very
>>>>>hacky use case.
>>>>
>>>>I agree it adds complexity in the common case (single engine) to
>>>>support
>>>>uncommon cases(multiple engines). If we decide not to support multiple
>>>>engines, that's fine. I just wish you voiced your opinion when I first
>>>>raised the issue before I made the changes. :-(
>>>
>>>
>>>Really sorry - I missunderstood the proposal, my assumption was that you
>>>would add support for multiple engines in /admin - and use the engine
>>>name ( which was equal with the domain ). I didn't know you need to add a
>>>name and move all engines in the same domain.
>>>
>>>The issue is not if we support multiple engines - we should support them
>>
>>in
>>
>>>both cases. I see no reasons not to.
>>>
>>>The only question is how - by changing the naming of the components to
>>>include the name of the engine, and having multiple tomcat engines in the
>>>same domain or by just having each engine in its own domain.
>>>
>>>For "multi engine" use case - I'm very interested in /admin managing
>>>multiple Engines, but some of them beeing proxys for remote VMs ( i.e.
>>>managing a cluster ). And in this case having one domain per Engine is
>>>again simpler.
>>>
>>>
>>>
>>>
>>>>But I still think it's not *too* complicated to add "name" and query
>>>>"engineName" from webmodules though. ;-)
>>>
>>>It's not too complicated. However it requires a bit more work - the
>>
>>embeded
>>
>>>case had a lot of NPEs, and all components will have to have this extra
>>>overhead.
>>>
>>>Plus it breaks a very elegant model, where each servlet engine had it's
>>
>>own
>>
>>>space.
>>>
>>>I'm +1 on multiple servlet engines - but I preffer the 1 engine- 1
>>>domain, and we can fix the jsr77 domain problem separately.
>>>
>>>BTW, in my experience so far having one JMX domain with too many
>>
>>components
>>
>>>can be quite confusing and is harder to use ( with the jmx console ) - so
>>
>>it
>>
>>>may be even better if we register the WebModules/Servlets in the jsr77
>>>domain ( where they are required ), and keep the other tomcat components
>>
>>in
>>
>>>their own domain.
>>>
>>>
>>>Costin
>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
>>>For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>>>
>>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0.2] New tag at the end of the week ?
Posted by Costin Manolache <cm...@yahoo.com>.
Amy - one more question.
What if we just move back to not support JSR77 directly in tomcat ?
I was reading jsr77 again - and it may be a better idea to just use
type=Context, etc - internal tomcat names, etc.
Then a j2ee container could just wrap those objects. The problem is that
if we want to support the statistics ( and we do have a lot of metrics
already ), JSR77 requires us to depend on javax.management.j2ee.statistics
and present them in a certain way. Nothing wrong with that - but we can
have an easier life if we leave this for the people who integrate tomcat
in a j2ee server.
The reason I tought we should implement jsr77 in tomcat was the fact that we
do have all the information already, and it would be easier for us to just
use the standard names ( even if 1/2 of it is not used - j2eeApp and
server). And it seemed logical that the StandardContext object, which is
the tomcat implementation of a WebApplication, is registered as a jsr77,
without another intermediary.
Decoupling them - I think you already suggested that - would probably loose
some info and control, at least in a simple implementation. But it can be
done via a dynamic or model mbean that proxies all the methods and
attributes in StandardContext, and adds the extra JSR77 specific stuff (i.e
statistics, etc ).
Would that be a better solution for you ?
Costin
Amy Roh wrote:
>> Amy Roh wrote:
>>
>> >> No, you can't change the object name of Servlet and WebModule. It is
>> >> defined in JSR77, and we're stuck with the attributes there. Can't
>> >> "extend" the standard by adding more to the names.
>> >
>> > Where does it say that? J2EEManagedObject objectName has syntax of
>> >
> [domainName]:j2eeType=value,name=value,<parent-j2eeType>[,property=value]
>> > 77.3.1.1.2 says the key property list must contain at least the
>> > mandatory key properties but doesn't limit to only mandatory. It says
>> > "it may contain any number of optional key properties whose order is
>> > not
>> > significant". I think you can add "engineName" attribute.
>>
>> I missed that part. Well, it seems there are few other things
>> that are missing in the jsr77 impl.
>>
>> So the question remain if we want to add the "engine=XXX" to all mbeans,
>> and the code to use the engine name when refering to other components.
>
> Do we have to add "engineName" to *all* mbeans?
>
> How about we add an option to set "J2EEDomain" for WebModule and Servlet?
> So when J2EEDomain for those components aren't null, we can register the
> mbeans under J2EEDomain as well as tomcat domain. At the time of
> registration we can save tomcatDomain name as "engineName" for those J2EE
> mbeans. In Tomcat, we can just look at "engineName" for WebModule and
> Servlet mbeans to do JMX operations if they're set to something. If not,
> we
> can assume its domain is the same as tomcat domain. This way we won't
> have to change other components (keep one engine per domain) and should
> work both
> in Tomcat and J2EE world? I'll check with jsr77 to see if registering in
> both domains are ok and if there're better ways to handle this.
>
> Thanks,
> Amy
>
>>
>> >> I'm very much against multiple engines per domain because of the same
>> >> reason - it adds complexity :-) The problem is that it adds complexity
> in
>> >> the common case ( one Engine per domain - most people don't have
> multiple
>> >> servlet engines running in the same VM ), in order to support a very
>> >> hacky use case.
>> >
>> > I agree it adds complexity in the common case (single engine) to
>> > support
>> > uncommon cases(multiple engines). If we decide not to support multiple
>> > engines, that's fine. I just wish you voiced your opinion when I first
>> > raised the issue before I made the changes. :-(
>>
>>
>> Really sorry - I missunderstood the proposal, my assumption was that you
>> would add support for multiple engines in /admin - and use the engine
>> name ( which was equal with the domain ). I didn't know you need to add a
>> name and move all engines in the same domain.
>>
>> The issue is not if we support multiple engines - we should support them
> in
>> both cases. I see no reasons not to.
>>
>> The only question is how - by changing the naming of the components to
>> include the name of the engine, and having multiple tomcat engines in the
>> same domain or by just having each engine in its own domain.
>>
>> For "multi engine" use case - I'm very interested in /admin managing
>> multiple Engines, but some of them beeing proxys for remote VMs ( i.e.
>> managing a cluster ). And in this case having one domain per Engine is
>> again simpler.
>>
>>
>>
>> > But I still think it's not *too* complicated to add "name" and query
>> > "engineName" from webmodules though. ;-)
>>
>> It's not too complicated. However it requires a bit more work - the
> embeded
>> case had a lot of NPEs, and all components will have to have this extra
>> overhead.
>>
>> Plus it breaks a very elegant model, where each servlet engine had it's
> own
>> space.
>>
>> I'm +1 on multiple servlet engines - but I preffer the 1 engine- 1
>> domain, and we can fix the jsr77 domain problem separately.
>>
>> BTW, in my experience so far having one JMX domain with too many
> components
>> can be quite confusing and is harder to use ( with the jmx console ) - so
> it
>> may be even better if we register the WebModules/Servlets in the jsr77
>> domain ( where they are required ), and keep the other tomcat components
> in
>> their own domain.
>>
>>
>> Costin
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0.2] New tag at the end of the week ?
Posted by Costin Manolache <cm...@yahoo.com>.
Amy Roh wrote:
>> So the question remain if we want to add the "engine=XXX" to all mbeans,
>> and the code to use the engine name when refering to other components.
>
> Do we have to add "engineName" to *all* mbeans?
AFAIK, yes.
Each component that needs to find the engine. Connectors for example.
And then each components that need to find those components. Jk components,
mapper, etc.
Each component must be able to find the other components it works with.
If you add a connector dynamically - it needs to find the engine, etc.
> How about we add an option to set "J2EEDomain" for WebModule and Servlet?
> So when J2EEDomain for those components aren't null, we can register the
> mbeans under J2EEDomain as well as tomcat domain. At the time of
That was also my first solution
>> 1. ( easy ) add an attribute to WebModule ( say "j2eeDomain" ), when the
>> context is started it'll register itself in the j2eeDomain ( and it'll
>> remain registered in the tomcat domain as well ). There are some fixes to
>> deal with preRegister/preUnregister.
And it seems Remy is thinking about the same thing.
If you are ok with that - then we have 3 votes :-)
I can help with the implementation tonight.
> registration we can save tomcatDomain name as "engineName" for those J2EE
> mbeans. In Tomcat, we can just look at "engineName" for WebModule and
> Servlet mbeans to do JMX operations if they're set to something. If not,
> we
> can assume its domain is the same as tomcat domain. This way we won't
> have to change other components (keep one engine per domain) and should
> work both
> in Tomcat and J2EE world? I'll check with jsr77 to see if registering in
> both domains are ok and if there're better ways to handle this.
I don't think we'll need to register in both domains.
And I don't think we even need to add anything to the name - it can be a
simple attribute ( "name property" is the part of the name, attribute is
what you get with getAttribute()).
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0.2] New tag at the end of the week ?
Posted by Amy Roh <am...@apache.org>.
> Amy Roh wrote:
>
> >> No, you can't change the object name of Servlet and WebModule. It is
> >> defined in JSR77, and we're stuck with the attributes there. Can't
> >> "extend" the standard by adding more to the names.
> >
> > Where does it say that? J2EEManagedObject objectName has syntax of
> >
[domainName]:j2eeType=value,name=value,<parent-j2eeType>[,property=value]
> > 77.3.1.1.2 says the key property list must contain at least the
> > mandatory key properties but doesn't limit to only mandatory. It says
> > "it may contain any number of optional key properties whose order is not
> > significant". I think you can add "engineName" attribute.
>
> I missed that part. Well, it seems there are few other things
> that are missing in the jsr77 impl.
>
> So the question remain if we want to add the "engine=XXX" to all mbeans,
> and the code to use the engine name when refering to other components.
Do we have to add "engineName" to *all* mbeans?
How about we add an option to set "J2EEDomain" for WebModule and Servlet?
So when J2EEDomain for those components aren't null, we can register the
mbeans under J2EEDomain as well as tomcat domain. At the time of
registration we can save tomcatDomain name as "engineName" for those J2EE
mbeans. In Tomcat, we can just look at "engineName" for WebModule and
Servlet mbeans to do JMX operations if they're set to something. If not, we
can assume its domain is the same as tomcat domain. This way we won't have
to change other components (keep one engine per domain) and should work both
in Tomcat and J2EE world? I'll check with jsr77 to see if registering in
both domains are ok and if there're better ways to handle this.
Thanks,
Amy
>
> >> I'm very much against multiple engines per domain because of the same
> >> reason - it adds complexity :-) The problem is that it adds complexity
in
> >> the common case ( one Engine per domain - most people don't have
multiple
> >> servlet engines running in the same VM ), in order to support a very
> >> hacky use case.
> >
> > I agree it adds complexity in the common case (single engine) to support
> > uncommon cases(multiple engines). If we decide not to support multiple
> > engines, that's fine. I just wish you voiced your opinion when I first
> > raised the issue before I made the changes. :-(
>
>
> Really sorry - I missunderstood the proposal, my assumption was that you
> would add support for multiple engines in /admin - and use the engine name
> ( which was equal with the domain ). I didn't know you need to add a name
> and move all engines in the same domain.
>
> The issue is not if we support multiple engines - we should support them
in
> both cases. I see no reasons not to.
>
> The only question is how - by changing the naming of the components to
> include the name of the engine, and having multiple tomcat engines in the
> same domain or by just having each engine in its own domain.
>
> For "multi engine" use case - I'm very interested in /admin managing
> multiple Engines, but some of them beeing proxys for remote VMs ( i.e.
> managing a cluster ). And in this case having one domain per Engine is
> again simpler.
>
>
>
> > But I still think it's not *too* complicated to add "name" and query
> > "engineName" from webmodules though. ;-)
>
> It's not too complicated. However it requires a bit more work - the
embeded
> case had a lot of NPEs, and all components will have to have this extra
> overhead.
>
> Plus it breaks a very elegant model, where each servlet engine had it's
own
> space.
>
> I'm +1 on multiple servlet engines - but I preffer the 1 engine- 1 domain,
> and we can fix the jsr77 domain problem separately.
>
> BTW, in my experience so far having one JMX domain with too many
components
> can be quite confusing and is harder to use ( with the jmx console ) - so
it
> may be even better if we register the WebModules/Servlets in the jsr77
> domain ( where they are required ), and keep the other tomcat components
in
> their own domain.
>
>
> Costin
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0.2] New tag at the end of the week ?
Posted by Costin Manolache <cm...@yahoo.com>.
Amy Roh wrote:
>> No, you can't change the object name of Servlet and WebModule. It is
>> defined in JSR77, and we're stuck with the attributes there. Can't
>> "extend" the standard by adding more to the names.
>
> Where does it say that? J2EEManagedObject objectName has syntax of
> [domainName]:j2eeType=value,name=value,<parent-j2eeType>[,property=value]
> 77.3.1.1.2 says the key property list must contain at least the
> mandatory key properties but doesn't limit to only mandatory. It says
> "it may contain any number of optional key properties whose order is not
> significant". I think you can add "engineName" attribute.
I missed that part. Well, it seems there are few other things
that are missing in the jsr77 impl.
So the question remain if we want to add the "engine=XXX" to all mbeans,
and the code to use the engine name when refering to other components.
>> I'm very much against multiple engines per domain because of the same
>> reason - it adds complexity :-) The problem is that it adds complexity in
>> the common case ( one Engine per domain - most people don't have multiple
>> servlet engines running in the same VM ), in order to support a very
>> hacky use case.
>
> I agree it adds complexity in the common case (single engine) to support
> uncommon cases(multiple engines). If we decide not to support multiple
> engines, that's fine. I just wish you voiced your opinion when I first
> raised the issue before I made the changes. :-(
Really sorry - I missunderstood the proposal, my assumption was that you
would add support for multiple engines in /admin - and use the engine name
( which was equal with the domain ). I didn't know you need to add a name
and move all engines in the same domain.
The issue is not if we support multiple engines - we should support them in
both cases. I see no reasons not to.
The only question is how - by changing the naming of the components to
include the name of the engine, and having multiple tomcat engines in the
same domain or by just having each engine in its own domain.
For "multi engine" use case - I'm very interested in /admin managing
multiple Engines, but some of them beeing proxys for remote VMs ( i.e.
managing a cluster ). And in this case having one domain per Engine is
again simpler.
> But I still think it's not *too* complicated to add "name" and query
> "engineName" from webmodules though. ;-)
It's not too complicated. However it requires a bit more work - the embeded
case had a lot of NPEs, and all components will have to have this extra
overhead.
Plus it breaks a very elegant model, where each servlet engine had it's own
space.
I'm +1 on multiple servlet engines - but I preffer the 1 engine- 1 domain,
and we can fix the jsr77 domain problem separately.
BTW, in my experience so far having one JMX domain with too many components
can be quite confusing and is harder to use ( with the jmx console ) - so it
may be even better if we register the WebModules/Servlets in the jsr77
domain ( where they are required ), and keep the other tomcat components in
their own domain.
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0.2] New tag at the end of the week ?
Posted by Amy Roh <am...@apache.org>.
Costin Manolache wrote:
>
> Amy Roh wrote:
>
> >> No, I think we should keep one engine per domain ( i.e. no name ), but
> >> fix the WebModule and Servlet - so you can keep them all in one domain (
> >> different than tomcat ).
> >>
> >>
> >> Actually - there is another option, to just register the WebModule and
> >> Servlet in both domains. Still few changes are required - but that would
> >> be the easiest solution.
> >
> > When you say both domains, you mean its engine's domain and also
> > J2EEDomain? Sounds ugly.
>
> It's a matter of taste :-)
>
> Using multiple Engines is what creates the problem in the first place.
> We need one engine per domain to keep things simple ( and not ugly ).
> IMO the "normal" case is to have the engine and the j2eeServer in the same
> domain - and have one servlet engine per j2eeServer.
>
> I don't know what the j2ee specs are saying - but having multiple servlet
> engines in a single j2ee server is going to create a lot of pain (
> configuration - where do you deploy the apps, etc ).
>
> >> There are 2 ways:
> >> 1. ( easy ) add an attribute to WebModule ( say "j2eeDomain" ), when the
> >> context is started it'll register itself in the j2eeDomain ( and it'll
> >> remain registered in the tomcat domain as well ). There are some fixes to
> >> deal with preRegister/preUnregister.
> >>
> >> 2. Add an attribute to WebModule ( "engineName" ). Then change the code
> >> in WebModule to use engineName as a domain when constructing the Host or
> >> Engine names. I think that would require more changes.
> >
> > Too complex. Admin will have to be completely rewriten in that part if
> > we have to construct Host & Engine using "engineName" domain.
>
>
> > I still don't understand why we can't add "name" attribute to
> > type=Engine mbeans so that we can have multiple engines under one domain
> > following jsr 77. If figuring out which engine each webmodule belongs
> > to is the problem, it can be fixed by just adding "engineName" attribute
> > to webmodule & servlet mbeans. But you won't have to register in two
> > different domains to do so. What am I missing here?
>
> No, you can't change the object name of Servlet and WebModule. It is defined
> in JSR77, and we're stuck with the attributes there. Can't "extend" the
> standard by adding more to the names.
Where does it say that? J2EEManagedObject objectName has syntax of
[domainName]:j2eeType=value,name=value,<parent-j2eeType>[,property=value]
77.3.1.1.2 says the key property list must contain at least the
mandatory key properties but doesn't limit to only mandatory. It says
"it may contain any number of optional key properties whose order is not
significant". I think you can add "engineName" attribute.
> The whole point of using JMX in tomcat is to be able to manage it using
> JMX ( instead of internal APIs ). You want to add/remove a connector to
> tomcat - just create the Connector mbean, set the attributes, and call
> init/start. You add a new webapp ? Create mbean, set attributes, call
> init/start. All this can happen at almost any time and in almost any order,
> you don't need to restart the server.
>
> In order for this to work - we need to play with the object names.
> JMX is a component registry - you can find and configure and operate on any
> component using its name.
>
> In all cases, components that are created need to find the engine. With 1
> Engine per domain - it's very simple- use the domain the component was
> registered with, add ":type=Engine".
>
> If you add name to engine, _all_ components that need the engine will have
> to have an extra attribute as well, and use it to locate the engine. For
> WebModule and Servlet - we can't add attributes, so other hacks are needed.
I don't think other hacks are needed. See above.
>
> But the fundamental issue is that Engine corresponds to a servlet engine,
> with all the settings and components. Mixing 2 serlvet engines in the same
> domain is ugly - you don't do it for the J2EEServer I assume ( jsr77
> actually requires you to have a single j2ee server per domain )
>
> Is there any J2EE spec that sugests that a j2ee server should support
> multiple servlet engines ?
>
> > If we're not allowing to register multiple engines per domain by adding
> > "name" attribute, I think all this just adds complexity. I can just add
> > the code in the J2EE product to create its mbeans for webmodule and
> > ignore mbeans in tomcat domain. We won't have to worry about
> > registering both in J2EEDomain and tomcat in tomcat itself.
>
> Then you loose the timing and other info.
> That's one option ( you could just wrap the tomcat mbeans - a dynamic mbean
> or modeler could probably allow you to keep the tomcat attributes exposed ).
>
> I'm very much against multiple engines per domain because of the same reason
> - it adds complexity :-) The problem is that it adds complexity in the
> common case ( one Engine per domain - most people don't have multiple
> servlet engines running in the same VM ), in order to support a very
> hacky use case.
I agree it adds complexity in the common case (single engine) to support
uncommon cases(multiple engines). If we decide not to support multiple
engines, that's fine. I just wish you voiced your opinion when I first
raised the issue before I made the changes. :-(
But I still think it's not *too* complicated to add "name" and query
"engineName" from webmodules though. ;-)
>
> Let's wait until Remy ( and other French people ) wakes up and maybe get
> some other opinions. I have no problems with making changes to the names -
> but if we add engine name, all components must add it and we need an answer
> on what to do about WebModule ( where we can't add keys to the name )
>
> Costin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0.2] New tag at the end of the week ?
Posted by Costin Manolache <cm...@yahoo.com>.
Amy Roh wrote:
>> No, I think we should keep one engine per domain ( i.e. no name ), but
>> fix the WebModule and Servlet - so you can keep them all in one domain (
>> different than tomcat ).
>>
>>
>> Actually - there is another option, to just register the WebModule and
>> Servlet in both domains. Still few changes are required - but that would
>> be the easiest solution.
>
> When you say both domains, you mean its engine's domain and also
> J2EEDomain? Sounds ugly.
It's a matter of taste :-)
Using multiple Engines is what creates the problem in the first place.
We need one engine per domain to keep things simple ( and not ugly ).
IMO the "normal" case is to have the engine and the j2eeServer in the same
domain - and have one servlet engine per j2eeServer.
I don't know what the j2ee specs are saying - but having multiple servlet
engines in a single j2ee server is going to create a lot of pain (
configuration - where do you deploy the apps, etc ).
>> There are 2 ways:
>> 1. ( easy ) add an attribute to WebModule ( say "j2eeDomain" ), when the
>> context is started it'll register itself in the j2eeDomain ( and it'll
>> remain registered in the tomcat domain as well ). There are some fixes to
>> deal with preRegister/preUnregister.
>>
>> 2. Add an attribute to WebModule ( "engineName" ). Then change the code
>> in WebModule to use engineName as a domain when constructing the Host or
>> Engine names. I think that would require more changes.
>
> Too complex. Admin will have to be completely rewriten in that part if
> we have to construct Host & Engine using "engineName" domain.
> I still don't understand why we can't add "name" attribute to
> type=Engine mbeans so that we can have multiple engines under one domain
> following jsr 77. If figuring out which engine each webmodule belongs
> to is the problem, it can be fixed by just adding "engineName" attribute
> to webmodule & servlet mbeans. But you won't have to register in two
> different domains to do so. What am I missing here?
No, you can't change the object name of Servlet and WebModule. It is defined
in JSR77, and we're stuck with the attributes there. Can't "extend" the
standard by adding more to the names.
The whole point of using JMX in tomcat is to be able to manage it using
JMX ( instead of internal APIs ). You want to add/remove a connector to
tomcat - just create the Connector mbean, set the attributes, and call
init/start. You add a new webapp ? Create mbean, set attributes, call
init/start. All this can happen at almost any time and in almost any order,
you don't need to restart the server.
In order for this to work - we need to play with the object names.
JMX is a component registry - you can find and configure and operate on any
component using its name.
In all cases, components that are created need to find the engine. With 1
Engine per domain - it's very simple- use the domain the component was
registered with, add ":type=Engine".
If you add name to engine, _all_ components that need the engine will have
to have an extra attribute as well, and use it to locate the engine. For
WebModule and Servlet - we can't add attributes, so other hacks are needed.
But the fundamental issue is that Engine corresponds to a servlet engine,
with all the settings and components. Mixing 2 serlvet engines in the same
domain is ugly - you don't do it for the J2EEServer I assume ( jsr77
actually requires you to have a single j2ee server per domain )
Is there any J2EE spec that sugests that a j2ee server should support
multiple servlet engines ?
> If we're not allowing to register multiple engines per domain by adding
> "name" attribute, I think all this just adds complexity. I can just add
> the code in the J2EE product to create its mbeans for webmodule and
> ignore mbeans in tomcat domain. We won't have to worry about
> registering both in J2EEDomain and tomcat in tomcat itself.
Then you loose the timing and other info.
That's one option ( you could just wrap the tomcat mbeans - a dynamic mbean
or modeler could probably allow you to keep the tomcat attributes exposed ).
I'm very much against multiple engines per domain because of the same reason
- it adds complexity :-) The problem is that it adds complexity in the
common case ( one Engine per domain - most people don't have multiple
servlet engines running in the same VM ), in order to support a very
hacky use case.
Let's wait until Remy ( and other French people ) wakes up and maybe get
some other opinions. I have no problems with making changes to the names -
but if we add engine name, all components must add it and we need an answer
on what to do about WebModule ( where we can't add keys to the name )
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0.2] New tag at the end of the week ?
Posted by Amy Roh <am...@apache.org>.
> No, I think we should keep one engine per domain ( i.e. no name ), but
> fix the WebModule and Servlet - so you can keep them all in one domain (
> different than tomcat ).
>
>
> Actually - there is another option, to just register the WebModule and
> Servlet in both domains. Still few changes are required - but that would be
> the easiest solution.
When you say both domains, you mean its engine's domain and also
J2EEDomain? Sounds ugly.
>>>It's not very difficult to fix the creation of WebModule - to move it
>>>under the same domain.
>>
>>When context is created, it inherits its domain name from its parent
>>engine. If we don't allow multiple engines in one domain, how can we
>>move it under the same domain?
>
>
> There are 2 ways:
> 1. ( easy ) add an attribute to WebModule ( say "j2eeDomain" ), when the
> context is started it'll register itself in the j2eeDomain ( and it'll
> remain registered in the tomcat domain as well ). There are some fixes to
> deal with preRegister/preUnregister.
>
> 2. Add an attribute to WebModule ( "engineName" ). Then change the code
> in WebModule to use engineName as a domain when constructing the Host or
> Engine names. I think that would require more changes.
Too complex. Admin will have to be completely rewriten in that part if
we have to construct Host & Engine using "engineName" domain.
I still don't understand why we can't add "name" attribute to
type=Engine mbeans so that we can have multiple engines under one domain
following jsr 77. If figuring out which engine each webmodule belongs
to is the problem, it can be fixed by just adding "engineName" attribute
to webmodule & servlet mbeans. But you won't have to register in two
different domains to do so. What am I missing here?
If we're not allowing to register multiple engines per domain by adding
"name" attribute, I think all this just adds complexity. I can just add
the code in the J2EE product to create its mbeans for webmodule and
ignore mbeans in tomcat domain. We won't have to worry about
registering both in J2EEDomain and tomcat in tomcat itself.
> In the end - all WebModules will be in the same domain. In the first case
> they'll also be registered in the tomcat domain. In the second case - some
> code will be slightly more complex.
>
>
>
>
>>>The problem is how to figure out what Engine a WebModule belongs to, if
>>>you use JMX ( and embed ) to create it.
>>>
>>>Attribute is the only solution I can find - and that restricts engines
>>>from registering 2 webmodules with the same name.
>>
>>We *should* restrict registering 2 webmodules with the same name, no?
>
>
> You mean don't allow /examples to be available on 2 Engines ?
>
> I assume the connectors are virtual hosts - and I don't think we can
> restrict vhosts this way. But I assume the j2eeApplication will be
> different..
>
>
>
>>>You have a point with the J2EEDomain. IMO the solution is to fix the
>>>WebModule and Servlet registration. If we find how to associate them back
>>>to the Engine - it shouldn't be hard to implement.
>>
>>with "parentName" (engineName) attribute? So all we have to change is
>>in WebModule and Servlet to include its parent objectName, right?
>
>
> The second solution. Yes, that works for me.
>
> Other opinions ? Remy ?
>
>
> Costin
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0.2] New tag at the end of the week ?
Posted by Costin Manolache <cm...@yahoo.com>.
Amy Roh wrote:
> Costin Manolache wrote:
>> Amy Roh wrote:
>>
>>
>>>>For the first part - it works both ways. If you use 1 Engine/domain -
>>>>then you'll also have each connector in the same domain with the
>>>>corresponding engine. I see no problem here.
>>>
>>>This is not an issue. The issue is that we need WebModules and Servlets
>>>to be in the same domain as the J2EEServer.
>>
>>
>> Ok. Let's fix that then, and let the Engine in its own domain.
>
> I'm not sure what you mean. Are you agreeing to have engine name *and*
> domain name and allow for them to be different? ;-)
No, I think we should keep one engine per domain ( i.e. no name ), but
fix the WebModule and Servlet - so you can keep them all in one domain (
different than tomcat ).
Actually - there is another option, to just register the WebModule and
Servlet in both domains. Still few changes are required - but that would be
the easiest solution.
>> So if I create a Context, give it an ObjectName - how do I figure out
>> what Engine ( and Connector ) should it be mapped to ?
>>
>> The only solution I can think of is to have a "engineName" attribute on
>> the context.
>
> I think WebModule mbeans should have "parentName" attribute to store its
> parent engine objectname so that it knows which engine it belongs to and
> so forth.
WebModule's parent is the virtual host. So it needs "engineName" attribute.
>> It's not very difficult to fix the creation of WebModule - to move it
>> under the same domain.
>
> When context is created, it inherits its domain name from its parent
> engine. If we don't allow multiple engines in one domain, how can we
> move it under the same domain?
There are 2 ways:
1. ( easy ) add an attribute to WebModule ( say "j2eeDomain" ), when the
context is started it'll register itself in the j2eeDomain ( and it'll
remain registered in the tomcat domain as well ). There are some fixes to
deal with preRegister/preUnregister.
2. Add an attribute to WebModule ( "engineName" ). Then change the code
in WebModule to use engineName as a domain when constructing the Host or
Engine names. I think that would require more changes.
In the end - all WebModules will be in the same domain. In the first case
they'll also be registered in the tomcat domain. In the second case - some
code will be slightly more complex.
>> The problem is how to figure out what Engine a WebModule belongs to, if
>> you use JMX ( and embed ) to create it.
>>
>> Attribute is the only solution I can find - and that restricts engines
>> from registering 2 webmodules with the same name.
>
> We *should* restrict registering 2 webmodules with the same name, no?
You mean don't allow /examples to be available on 2 Engines ?
I assume the connectors are virtual hosts - and I don't think we can
restrict vhosts this way. But I assume the j2eeApplication will be
different..
>> You have a point with the J2EEDomain. IMO the solution is to fix the
>> WebModule and Servlet registration. If we find how to associate them back
>> to the Engine - it shouldn't be hard to implement.
>
> with "parentName" (engineName) attribute? So all we have to change is
> in WebModule and Servlet to include its parent objectName, right?
The second solution. Yes, that works for me.
Other opinions ? Remy ?
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0.2] New tag at the end of the week ?
Posted by Costin Manolache <cm...@yahoo.com>.
Amy Roh wrote:
>> When context is created, it inherits its domain name from its parent
>> engine. If we don't allow multiple engines in one domain, how can we
>> move it under the same domain?
>
> To clarify more...it's not right to distribute managed objects belonging
> to one domain and one server across multiple domain names. And we're
> doing that if we create more than one engine since we use engine's name
> as its domain for all components under it.
For tomcat, the Engine is the servlet engine implementation. It is not right
to have multiple engines in the same domain - just like you wouldn't want
to have 2 distinct j2eeServers in the same domain.
If you create multiple servlet engines - that's fine, as long as you don't
mix them togheter.
I think it is ok to have the WebModules registered in both domains, or
registered in a separate domain - i.e. the j2eeServer will manage the
modules lifecycle ( which is probably the case ). Engine still needs to
find them - or the Context still needs to find the Engine, either by double
registration or by using an attribute. However logically the WebModule
can belong to the j2eeServer domain - I see no problem with that, it's
the server that actually deploys/create/manage them.
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0.2] New tag at the end of the week ?
Posted by Amy Roh <am...@apache.org>.
>>>> Could you point to the JSR77 section where the mbeans are required
>>>> to be
>>>> in the same domain ? My understanding so far has been that the
>>>> domain is
>>>> not specified, and implementations can use it, for example to deal with
>>>> this case, of multiple servlet engine instances running in the same
>>>> j2eeServer, with the same context name and j2eeApplication.
>>>
>>>
>>> If you look at JSR77.3.2, J2EEServer extends J2EEDomain.
>>> J2EEModule(WebModule) and J2EEApplication extend J2EEDeployedObject
>>> which extends J2EEServer. Therefore, all WebModules that are deployed
>>> under J2EEServer should be in the same J2EEDomain. When TC is
>>> integrated in AppServer, if multiple engines are created, there isn't a
>>> way for the WebModules to be under same domain. They'll get deployed
>>> under engine name domain not the J2EEServer, J2EEDomain from the
>>> integration which is not JSR77 compliant.
>>
>>
>>
>> It's not very difficult to fix the creation of WebModule - to move it
>> under
>> the same domain.
>
>
> When context is created, it inherits its domain name from its parent
> engine. If we don't allow multiple engines in one domain, how can we
> move it under the same domain?
To clarify more...it's not right to distribute managed objects belonging
to one domain and one server across multiple domain names. And we're
doing that if we create more than one engine since we use engine's name
as its domain for all components under it.
>
>
>> The problem is how to figure out what Engine a WebModule belongs to,
>> if you
>> use JMX ( and embed ) to create it.
>> Attribute is the only solution I can find - and that restricts engines
>> from registering 2 webmodules with the same name.
>
>
> We *should* restrict registering 2 webmodules with the same name, no?
>
>> The thing I miss is the relation between multiple engines ( and
>> connectors )
>> and ears. The context name is based on .ear name, server name, and
>> context
>> name. How do you associate this with an engine ?
>>
>>
>>
>>> What do you think?
>>
>>
>>
>> You have a point with the J2EEDomain. IMO the solution is to fix the
>> WebModule and Servlet registration. If we find how to associate them back
>> to the Engine - it shouldn't be hard to implement.
>
>
> with "parentName" (engineName) attribute? So all we have to change is
> in WebModule and Servlet to include its parent objectName, right?
>
> Amy
>
>>
>> Costin
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0.2] New tag at the end of the week ?
Posted by Amy Roh <am...@apache.org>.
Costin Manolache wrote:
> Amy Roh wrote:
>
>
>>>For the first part - it works both ways. If you use 1 Engine/domain -
>>>then you'll also have each connector in the same domain with the
>>>corresponding engine. I see no problem here.
>>
>>This is not an issue. The issue is that we need WebModules and Servlets
>>to be in the same domain as the J2EEServer.
>
>
> Ok. Let's fix that then, and let the Engine in its own domain.
I'm not sure what you mean. Are you agreeing to have engine name *and*
domain name and allow for them to be different? ;-)
>>>The second part is a bit trickier ( and it seems a valid use case ... ).
>>>You want the WebModules and Servlets to be in the same domain. I think
>>>this can be done with some changes in WebModules and Servlets.
>>>
>>>Let me ask you one question first: would it be ok if we use the
>>>j2eeServer to match the engine name ( and it's domain ) ?
>>
>>No. J2EEServer and J2EEApplication names should be set as part of
>>integration as you mentioned and should be out of Tomcat scope. This
>>will only restrict more on top of domain name having to be the same as
>>engine name.
>
>
> So if I create a Context, give it an ObjectName - how do I figure out what
> Engine ( and Connector ) should it be mapped to ?
>
> The only solution I can think of is to have a "engineName" attribute on the
> context.
I think WebModule mbeans should have "parentName" attribute to store its
parent engine objectname so that it knows which engine it belongs to and
so forth.
>>>You see - the real problem is that the JSR77 name is fixed - you have
>>>webapp name, j2eeApplication ( that's the .ear - and it's part of the
>>>integration code with j2ee server to set it right ), and j2eeServer.
>>>Nothing else. My understanding was that all webapps will be in the same
>>>j2eeServer, and this would be set by the integration code.
>>
>>Right.
>>
>>
>>>The webapp mbean needs to find the engine - at least in embeded case.
>>>Right now all it needs is in its own name. And I assume other pieces of
>>>code could benefit from beeing able to tell what engine a webapp is
>>>associated with - looking at the name.
>>>
>>>We could just use an attribute in StandardContext and StandardWrapper to
>>>override the domain - in case using the j2eeServer attribute is not
>>>acceptable.
>>>But that would break if you have 2 webapps with the same name, inside
>>>identical EARs running on 2 different connectors - the generated name
>>>will be completely identical. I assume different connectors correspond to
>>>different vhosts - and if this is the case, I think it's reasonable to
>>>expect to be able to deply the same .ear on 2 vhosts.
>>>
>>>
>>>Could you point to the JSR77 section where the mbeans are required to be
>>>in the same domain ? My understanding so far has been that the domain is
>>>not specified, and implementations can use it, for example to deal with
>>>this case, of multiple servlet engine instances running in the same
>>>j2eeServer, with the same context name and j2eeApplication.
>>
>>If you look at JSR77.3.2, J2EEServer extends J2EEDomain.
>>J2EEModule(WebModule) and J2EEApplication extend J2EEDeployedObject
>>which extends J2EEServer. Therefore, all WebModules that are deployed
>>under J2EEServer should be in the same J2EEDomain. When TC is
>>integrated in AppServer, if multiple engines are created, there isn't a
>>way for the WebModules to be under same domain. They'll get deployed
>>under engine name domain not the J2EEServer, J2EEDomain from the
>>integration which is not JSR77 compliant.
>
>
> It's not very difficult to fix the creation of WebModule - to move it under
> the same domain.
When context is created, it inherits its domain name from its parent
engine. If we don't allow multiple engines in one domain, how can we
move it under the same domain?
> The problem is how to figure out what Engine a WebModule belongs to, if you
> use JMX ( and embed ) to create it.
>
> Attribute is the only solution I can find - and that restricts engines from
> registering 2 webmodules with the same name.
We *should* restrict registering 2 webmodules with the same name, no?
> The thing I miss is the relation between multiple engines ( and connectors )
> and ears. The context name is based on .ear name, server name, and context
> name. How do you associate this with an engine ?
>
>
>
>>What do you think?
>
>
> You have a point with the J2EEDomain. IMO the solution is to fix the
> WebModule and Servlet registration. If we find how to associate them back
> to the Engine - it shouldn't be hard to implement.
with "parentName" (engineName) attribute? So all we have to change is
in WebModule and Servlet to include its parent objectName, right?
Amy
>
> Costin
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0.2] New tag at the end of the week ?
Posted by Costin Manolache <cm...@yahoo.com>.
Amy Roh wrote:
>> For the first part - it works both ways. If you use 1 Engine/domain -
>> then you'll also have each connector in the same domain with the
>> corresponding engine. I see no problem here.
>
> This is not an issue. The issue is that we need WebModules and Servlets
> to be in the same domain as the J2EEServer.
Ok. Let's fix that then, and let the Engine in its own domain.
>> The second part is a bit trickier ( and it seems a valid use case ... ).
>> You want the WebModules and Servlets to be in the same domain. I think
>> this can be done with some changes in WebModules and Servlets.
>>
>> Let me ask you one question first: would it be ok if we use the
>> j2eeServer to match the engine name ( and it's domain ) ?
>
> No. J2EEServer and J2EEApplication names should be set as part of
> integration as you mentioned and should be out of Tomcat scope. This
> will only restrict more on top of domain name having to be the same as
> engine name.
So if I create a Context, give it an ObjectName - how do I figure out what
Engine ( and Connector ) should it be mapped to ?
The only solution I can think of is to have a "engineName" attribute on the
context.
>> You see - the real problem is that the JSR77 name is fixed - you have
>> webapp name, j2eeApplication ( that's the .ear - and it's part of the
>> integration code with j2ee server to set it right ), and j2eeServer.
>> Nothing else. My understanding was that all webapps will be in the same
>> j2eeServer, and this would be set by the integration code.
>
> Right.
>
>> The webapp mbean needs to find the engine - at least in embeded case.
>> Right now all it needs is in its own name. And I assume other pieces of
>> code could benefit from beeing able to tell what engine a webapp is
>> associated with - looking at the name.
>>
>> We could just use an attribute in StandardContext and StandardWrapper to
>> override the domain - in case using the j2eeServer attribute is not
>> acceptable.
>> But that would break if you have 2 webapps with the same name, inside
>> identical EARs running on 2 different connectors - the generated name
>> will be completely identical. I assume different connectors correspond to
>> different vhosts - and if this is the case, I think it's reasonable to
>> expect to be able to deply the same .ear on 2 vhosts.
>>
>>
>> Could you point to the JSR77 section where the mbeans are required to be
>> in the same domain ? My understanding so far has been that the domain is
>> not specified, and implementations can use it, for example to deal with
>> this case, of multiple servlet engine instances running in the same
>> j2eeServer, with the same context name and j2eeApplication.
>
> If you look at JSR77.3.2, J2EEServer extends J2EEDomain.
> J2EEModule(WebModule) and J2EEApplication extend J2EEDeployedObject
> which extends J2EEServer. Therefore, all WebModules that are deployed
> under J2EEServer should be in the same J2EEDomain. When TC is
> integrated in AppServer, if multiple engines are created, there isn't a
> way for the WebModules to be under same domain. They'll get deployed
> under engine name domain not the J2EEServer, J2EEDomain from the
> integration which is not JSR77 compliant.
It's not very difficult to fix the creation of WebModule - to move it under
the same domain.
The problem is how to figure out what Engine a WebModule belongs to, if you
use JMX ( and embed ) to create it.
Attribute is the only solution I can find - and that restricts engines from
registering 2 webmodules with the same name.
The thing I miss is the relation between multiple engines ( and connectors )
and ears. The context name is based on .ear name, server name, and context
name. How do you associate this with an engine ?
> What do you think?
You have a point with the J2EEDomain. IMO the solution is to fix the
WebModule and Servlet registration. If we find how to associate them back
to the Engine - it shouldn't be hard to implement.
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0.2] New tag at the end of the week ?
Posted by Amy Roh <am...@apache.org>.
Costin Manolache wrote:
> Amy Roh wrote:
>
>
>>>If you have a use case where this would actually help - we should discuss
>>>it and do the change ASAP ( but on all components- I really don't see any
>>>way embed can work otherwise ).
>>
>>Here is my use case and background info. I need to create multiple
>>engines (one engine per connector) because in TC we support defaultHost
>>in engine level. However, AppServer that I'm working on supports one
>>defaultHost per listener(connector). This forces me to create one
>>engine per listener which results in having as many engines as listeners
>>to map AppServer domain.xml and TC server.xml. AppServer has its JSR77
>>mbeans for domain, server, applications, ejbmodules, etc. We want to
>>use Tomcat MBeans for WebModules & Servlets sharing one default domain.
>> Not allowing multiple engines per domain means that the deployed
>>WebModules will have different domains which doesn't follow JSR77.
>>Maybe you have a better idea/suggestion to resolve this issue if we
>>don't allow multiple engines per domain.
>
>
> For the first part - it works both ways. If you use 1 Engine/domain - then
> you'll also have each connector in the same domain with the corresponding
> engine. I see no problem here.
This is not an issue. The issue is that we need WebModules and Servlets
to be in the same domain as the J2EEServer.
>
> The second part is a bit trickier ( and it seems a valid use case ... ).
> You want the WebModules and Servlets to be in the same domain. I think this
> can be done with some changes in WebModules and Servlets.
>
> Let me ask you one question first: would it be ok if we use the j2eeServer
> to match the engine name ( and it's domain ) ?
No. J2EEServer and J2EEApplication names should be set as part of
integration as you mentioned and should be out of Tomcat scope. This
will only restrict more on top of domain name having to be the same as
engine name.
>
> You see - the real problem is that the JSR77 name is fixed - you have webapp
> name, j2eeApplication ( that's the .ear - and it's part of the integration
> code with j2ee server to set it right ), and j2eeServer. Nothing else. My
> understanding was that all webapps will be in the same j2eeServer, and this
> would be set by the integration code.
Right.
> The webapp mbean needs to find the engine - at least in embeded case. Right
> now all it needs is in its own name. And I assume other pieces of code
> could benefit from beeing able to tell what engine a webapp is associated
> with - looking at the name.
>
> We could just use an attribute in StandardContext and StandardWrapper to
> override the domain - in case using the j2eeServer attribute is not
> acceptable.
> But that would break if you have 2 webapps with the same name, inside
> identical EARs running on 2 different connectors - the generated name will
> be completely identical. I assume different connectors correspond to
> different vhosts - and if this is the case, I think it's reasonable to
> expect to be able to deply the same .ear on 2 vhosts.
>
>
> Could you point to the JSR77 section where the mbeans are required to be in
> the same domain ? My understanding so far has been that the domain is not
> specified, and implementations can use it, for example to deal with this
> case, of multiple servlet engine instances running in the same j2eeServer,
> with the same context name and j2eeApplication.
If you look at JSR77.3.2, J2EEServer extends J2EEDomain.
J2EEModule(WebModule) and J2EEApplication extend J2EEDeployedObject
which extends J2EEServer. Therefore, all WebModules that are deployed
under J2EEServer should be in the same J2EEDomain. When TC is
integrated in AppServer, if multiple engines are created, there isn't a
way for the WebModules to be under same domain. They'll get deployed
under engine name domain not the J2EEServer, J2EEDomain from the
integration which is not JSR77 compliant.
What do you think?
Amy
>
>
> Costin
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0.2] New tag at the end of the week ?
Posted by Costin Manolache <cm...@yahoo.com>.
Amy Roh wrote:
>> If you have a use case where this would actually help - we should discuss
>> it and do the change ASAP ( but on all components- I really don't see any
>> way embed can work otherwise ).
>
> Here is my use case and background info. I need to create multiple
> engines (one engine per connector) because in TC we support defaultHost
> in engine level. However, AppServer that I'm working on supports one
> defaultHost per listener(connector). This forces me to create one
> engine per listener which results in having as many engines as listeners
> to map AppServer domain.xml and TC server.xml. AppServer has its JSR77
> mbeans for domain, server, applications, ejbmodules, etc. We want to
> use Tomcat MBeans for WebModules & Servlets sharing one default domain.
> Not allowing multiple engines per domain means that the deployed
> WebModules will have different domains which doesn't follow JSR77.
> Maybe you have a better idea/suggestion to resolve this issue if we
> don't allow multiple engines per domain.
For the first part - it works both ways. If you use 1 Engine/domain - then
you'll also have each connector in the same domain with the corresponding
engine. I see no problem here.
The second part is a bit trickier ( and it seems a valid use case ... ).
You want the WebModules and Servlets to be in the same domain. I think this
can be done with some changes in WebModules and Servlets.
Let me ask you one question first: would it be ok if we use the j2eeServer
to match the engine name ( and it's domain ) ?
You see - the real problem is that the JSR77 name is fixed - you have webapp
name, j2eeApplication ( that's the .ear - and it's part of the integration
code with j2ee server to set it right ), and j2eeServer. Nothing else. My
understanding was that all webapps will be in the same j2eeServer, and this
would be set by the integration code.
The webapp mbean needs to find the engine - at least in embeded case. Right
now all it needs is in its own name. And I assume other pieces of code
could benefit from beeing able to tell what engine a webapp is associated
with - looking at the name.
We could just use an attribute in StandardContext and StandardWrapper to
override the domain - in case using the j2eeServer attribute is not
acceptable.
But that would break if you have 2 webapps with the same name, inside
identical EARs running on 2 different connectors - the generated name will
be completely identical. I assume different connectors correspond to
different vhosts - and if this is the case, I think it's reasonable to
expect to be able to deply the same .ear on 2 vhosts.
Could you point to the JSR77 section where the mbeans are required to be in
the same domain ? My understanding so far has been that the domain is not
specified, and implementations can use it, for example to deal with this
case, of multiple servlet engine instances running in the same j2eeServer,
with the same context name and j2eeApplication.
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0.2] New tag at the end of the week ?
Posted by Amy Roh <am...@sun.com>.
Costin Manolache wrote:
> Amy Roh wrote:
>
>
>>>>Amy Roh wrote:
>>>>
>>>>
>>>>>Hi Remy, Is the NPE in Mapper fixed with your commit? I can't reproduce
>>>>>it. Thanks,Amy
>>>>
>>>>Yes, it is fixed.
>>>
>>>
>>>I get some NPEs in embeded.
>>
>>Can you tell me where?
>>
>>
>>>I noticed the Engine now has a name.
>>>
>>>I was thinking that each Engine will have its own domain - i.e. the
>>>name of the engine will be the same with the domain. We can add a name
>>>attribute, but we still need to keep each engine in its own domain.
>>
>>Why is there a need to keep each engine in its own domain *only*?
>>Currently, you can keep each engine in its own domain by setting its
>>domain with engine's name and also have multiple engines under one
>>domain if you set it to share one domain. It's upto how you use
>>setDomain(). The default way (if you don't set domain explicitly) is to
>>use engine's name for its domain.
>
>
> Because having one engine per domain simplifies a lot in the naming.
I agree this simplifies things.
>
> Why would you want to have multiple engines per domain ? I don't see any
> use case.
>
> You can run multiple engines in a single VM - just use a different domain.
>
>
>
>>>Amy - do you mind if I change that ? Are you using it ?
>>
>>Yes. I need to have a way to have multiple engines per one domain. The
>>reason for adding "name" attribute was to do so. You can still achieve
>>the previous behavior by not setting domain so I don't see why you need
>>to change? Please let me know what you think.
>
>
> What I don't understand is why multiple engines per _domain_.
>
> I understand the use case of multiple Engines in a single VM. But why do
> they need to have the same JMX domain name ?
>
> If you have a use case for that - what we have to do is add the extra
> attribute to _all_ components in tomcat. This is the only way they can find
> each other.
>
> In embed case, when a component is registered it needs to find the Engine
> and the other components. For that it needs to construct the name.
>
> To recap - the problems I have with adding another component to all names:
> - it makes all code more complicated
> - it needs to be done in _all_ components so they can find each other
> - it doesn't provide any benefit - you can still use different domains
> without problem.
>
> If you have a use case where this would actually help - we should discuss it
> and do the change ASAP ( but on all components- I really don't see any way
> embed can work otherwise ).
Here is my use case and background info. I need to create multiple
engines (one engine per connector) because in TC we support defaultHost
in engine level. However, AppServer that I'm working on supports one
defaultHost per listener(connector). This forces me to create one
engine per listener which results in having as many engines as listeners
to map AppServer domain.xml and TC server.xml. AppServer has its JSR77
mbeans for domain, server, applications, ejbmodules, etc. We want to
use Tomcat MBeans for WebModules & Servlets sharing one default domain.
Not allowing multiple engines per domain means that the deployed
WebModules will have different domains which doesn't follow JSR77.
Maybe you have a better idea/suggestion to resolve this issue if we
don't allow multiple engines per domain.
Thanks,
Amy
>
>
> Costin
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0.2] New tag at the end of the week ?
Posted by Costin Manolache <cm...@yahoo.com>.
Amy Roh wrote:
>>>Amy Roh wrote:
>>>
>>>>Hi Remy, Is the NPE in Mapper fixed with your commit? I can't reproduce
>>>>it. Thanks,Amy
>>>
>>>Yes, it is fixed.
>>
>>
>> I get some NPEs in embeded.
>
> Can you tell me where?
>
>>
>> I noticed the Engine now has a name.
>>
>> I was thinking that each Engine will have its own domain - i.e. the
>> name of the engine will be the same with the domain. We can add a name
>> attribute, but we still need to keep each engine in its own domain.
>
> Why is there a need to keep each engine in its own domain *only*?
> Currently, you can keep each engine in its own domain by setting its
> domain with engine's name and also have multiple engines under one
> domain if you set it to share one domain. It's upto how you use
> setDomain(). The default way (if you don't set domain explicitly) is to
> use engine's name for its domain.
Because having one engine per domain simplifies a lot in the naming.
Why would you want to have multiple engines per domain ? I don't see any
use case.
You can run multiple engines in a single VM - just use a different domain.
>
>> Amy - do you mind if I change that ? Are you using it ?
>
> Yes. I need to have a way to have multiple engines per one domain. The
> reason for adding "name" attribute was to do so. You can still achieve
> the previous behavior by not setting domain so I don't see why you need
> to change? Please let me know what you think.
What I don't understand is why multiple engines per _domain_.
I understand the use case of multiple Engines in a single VM. But why do
they need to have the same JMX domain name ?
If you have a use case for that - what we have to do is add the extra
attribute to _all_ components in tomcat. This is the only way they can find
each other.
In embed case, when a component is registered it needs to find the Engine
and the other components. For that it needs to construct the name.
To recap - the problems I have with adding another component to all names:
- it makes all code more complicated
- it needs to be done in _all_ components so they can find each other
- it doesn't provide any benefit - you can still use different domains
without problem.
If you have a use case where this would actually help - we should discuss it
and do the change ASAP ( but on all components- I really don't see any way
embed can work otherwise ).
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0.2] New tag at the end of the week ?
Posted by Amy Roh <am...@apache.org>.
Costin Manolache wrote:
> Remy Maucherat wrote:
>
>
>>Amy Roh wrote:
>>
>>>Hi Remy, Is the NPE in Mapper fixed with your commit? I can't reproduce
>>>it. Thanks,Amy
>>
>>Yes, it is fixed.
>
>
> I get some NPEs in embeded.
Can you tell me where?
>
> I noticed the Engine now has a name.
>
> I was thinking that each Engine will have its own domain - i.e. the
> name of the engine will be the same with the domain. We can add a name
> attribute, but we still need to keep each engine in its own domain.
Why is there a need to keep each engine in its own domain *only*?
Currently, you can keep each engine in its own domain by setting its
domain with engine's name and also have multiple engines under one
domain if you set it to share one domain. It's upto how you use
setDomain(). The default way (if you don't set domain explicitly) is to
use engine's name for its domain.
> Amy - do you mind if I change that ? Are you using it ?
Yes. I need to have a way to have multiple engines per one domain. The
reason for adding "name" attribute was to do so. You can still achieve
the previous behavior by not setting domain so I don't see why you need
to change? Please let me know what you think.
Thanks,
Amy
>
> Costin
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0.2] New tag at the end of the week ?
Posted by Costin Manolache <cm...@yahoo.com>.
Remy Maucherat wrote:
> Amy Roh wrote:
>> Hi Remy, Is the NPE in Mapper fixed with your commit? I can't reproduce
>> it. Thanks,Amy
>
> Yes, it is fixed.
I get some NPEs in embeded.
I noticed the Engine now has a name.
I was thinking that each Engine will have its own domain - i.e. the
name of the engine will be the same with the domain. We can add a name
attribute, but we still need to keep each engine in its own domain.
Amy - do you mind if I change that ? Are you using it ?
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0.2] New tag at the end of the week ?
Posted by Remy Maucherat <re...@apache.org>.
Amy Roh wrote:
> Hi Remy, Is the NPE in Mapper fixed with your commit? I can't reproduce it. Thanks,Amy
Yes, it is fixed.
Remy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0.2] New tag at the end of the week ?
Posted by Amy Roh <am...@yahoo.com>.
Hi Remy, Is the NPE in Mapper fixed with your commit? I can't reproduce it. Thanks,Amy
Remy Maucherat <re...@apache.org> wrote:Costin Manolache wrote:
> Remy Maucherat wrote:
>>>BTw, part of the preparation for releasing j-t-c I tested it against
>>>tomcat3.3, tomcat-4.0.6 and 4.1.24. All 3 seem to be working fine.
>>
>>Cool ! I definitely haven't been spending time checking 4.0.6, but since
>>it's the same code as 4.1.x with a few additional security checks, I
>>think it's supposed to be ok.
>
>
> We could use the "standalone" j-t-c as a dependency in 50.
>
> I know we don't agree on the "update jars" mechanism, but if j-t-c can
> work without (major:-) problems with 3.3, 4.0, 4.1 and 5.0 I think we
> could assume it'll work for 5.0.3, etc.
> I don't want to reopen this again - but modular and incremental releases can
> simplify a lot of things.
The problem is that "small" "incremental" changes are never properly tested.
Ex: When I wake up this morning, look at the commits (where the messages
imply they're all safe changes), update everything, ant clean; ant, I get:
GRAVE: Une exception ou une erreur s''est produite dans le conteneur
durant le traitement de la requ?te
java.lang.NullPointerException
at org.apache.tomcat.util.http.mapper.Mapper.find(Mapper.java:865)
at
org.apache.tomcat.util.http.mapper.Mapper.internalMap(Mapper.java:502)
at org.apache.tomcat.util.http.mapper.Mapper.map(Mapper.java:474)
at
org.apache.coyote.tomcat5.CoyoteAdapter.postParseRequest(CoyoteAdapter.java:301)
at
org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:197)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:630)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:463)
at
org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:568)
at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:631)
at java.lang.Thread.run(Thread.java:534)
Apparently some change caused the default host name to not properly get
set in the mapper, but the point is that small changes are the biggest
problems for regressions.
Remy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
---------------------------------
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
Re: [5.0.2] New tag at the end of the week ?
Posted by Remy Maucherat <re...@apache.org>.
Costin Manolache wrote:
> Remy Maucherat wrote:
>>>BTw, part of the preparation for releasing j-t-c I tested it against
>>>tomcat3.3, tomcat-4.0.6 and 4.1.24. All 3 seem to be working fine.
>>
>>Cool ! I definitely haven't been spending time checking 4.0.6, but since
>>it's the same code as 4.1.x with a few additional security checks, I
>>think it's supposed to be ok.
>
>
> We could use the "standalone" j-t-c as a dependency in 50.
>
> I know we don't agree on the "update jars" mechanism, but if j-t-c can
> work without (major:-) problems with 3.3, 4.0, 4.1 and 5.0 I think we
> could assume it'll work for 5.0.3, etc.
> I don't want to reopen this again - but modular and incremental releases can
> simplify a lot of things.
The problem is that "small" "incremental" changes are never properly tested.
Ex: When I wake up this morning, look at the commits (where the messages
imply they're all safe changes), update everything, ant clean; ant, I get:
GRAVE: Une exception ou une erreur s''est produite dans le conteneur
durant le traitement de la requ?te
java.lang.NullPointerException
at org.apache.tomcat.util.http.mapper.Mapper.find(Mapper.java:865)
at
org.apache.tomcat.util.http.mapper.Mapper.internalMap(Mapper.java:502)
at org.apache.tomcat.util.http.mapper.Mapper.map(Mapper.java:474)
at
org.apache.coyote.tomcat5.CoyoteAdapter.postParseRequest(CoyoteAdapter.java:301)
at
org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:197)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:630)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:463)
at
org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:568)
at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:631)
at java.lang.Thread.run(Thread.java:534)
Apparently some change caused the default host name to not properly get
set in the mapper, but the point is that small changes are the biggest
problems for regressions.
Remy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0.2] New tag at the end of the week ?
Posted by Remy Maucherat <re...@apache.org>.
Costin Manolache wrote:
> Remy Maucherat wrote:
>
>
>>>I posted 2 weeks ago that I plan to move coyote/tomcat5 from j-t-c to
>>>catalina, to break the circular dep. For tomcat41 and 3.3 we need to keep
>>>them in j-t-c ( so they work with the current released version ). Nobody
>>>objected so far - so in about 15 minutes it'll happen, hurry up if you
>>>don't like the idea :-)
>>
>>I know the build will be broken in 15 minutes then :-D
>
>
> Seems to work for me - if anyone can do a full build and confirm.
Sorry, it fails for me :-P
Coyote is built after the main Catalina source (which now uses the main
Coyote API).
I don't think I forgot to update anything (I did j-t-5, j-t-cat, j-t-c).
build-catalina-core:
[javac] Compiling 323 source files to
L:\home\tomcat-5\jakarta-tomcat-5\build\classes
[javac]
L:\home\tomcat-5\jakarta-tomcat-catalina\catalina\src\share\org\apache\coyote\tomcat5\CoyoteAdapter.java:77:
cannot resolve symbol
[javac] symbol : class ActionCode
[javac] location: package coyote
[javac] import org.apache.coyote.ActionCode;
[javac] ^
...
Remy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0.2] New tag at the end of the week ?
Posted by Costin Manolache <cm...@yahoo.com>.
Remy Maucherat wrote:
>> I posted 2 weeks ago that I plan to move coyote/tomcat5 from j-t-c to
>> catalina, to break the circular dep. For tomcat41 and 3.3 we need to keep
>> them in j-t-c ( so they work with the current released version ). Nobody
>> objected so far - so in about 15 minutes it'll happen, hurry up if you
>> don't like the idea :-)
>
> I know the build will be broken in 15 minutes then :-D
Seems to work for me - if anyone can do a full build and confirm.
>> BTw, part of the preparation for releasing j-t-c I tested it against
>> tomcat3.3, tomcat-4.0.6 and 4.1.24. All 3 seem to be working fine.
>
> Cool ! I definitely haven't been spending time checking 4.0.6, but since
> it's the same code as 4.1.x with a few additional security checks, I
> think it's supposed to be ok.
We could use the "standalone" j-t-c as a dependency in 50.
I know we don't agree on the "update jars" mechanism, but if j-t-c can
work without (major:-) problems with 3.3, 4.0, 4.1 and 5.0 I think we
could assume it'll work for 5.0.3, etc.
I don't want to reopen this again - but modular and incremental releases can
simplify a lot of things.
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0.2] New tag at the end of the week ?
Posted by Remy Maucherat <re...@apache.org>.
Costin Manolache wrote:
> Remy Maucherat wrote:
>
>
>>>I'm making another try with modeler - last week we hit several bugs,
>>>so I did a lot more testing.
>>
>>Ok. I hope to get my changes in and tested by monday, but I don't think
>>anybody would get hurt if the release is delayed until the end of next
>>week ;-)
>
>
> Changes to modeler ?
>
> I was just working on a new build.
>
> IMO most of the functionality (that was part of 1.0) is stable, except
> for the "experimental" features ( persistence, remote ).
>
> I was thinking that after M1 we can make a release ( 1.1 ) and when
> the persistence and remote are tested and saved we can move to 2.0 and
> remove the static methods ( or release 1.2 with the backward compat and
> move to a 2.0 after that ).
>
> We need 1.1 and statics to support tomcat4.1.
Ok.
>>>I haven't heard back from JFC about the vhost fix on jk2- but I did more
>>>tests with the unix channel, reconfiguration - things look pretty good
>>>IMO. I would like to have jakarta-tomcat-connectors released as a
>>>standalone package ( including tomcat-util, coyote + 33 and 4.x
>>>connector, jk2, http11)- for use with pre-5.0 containters.
>>
>>Yes, it's supposed to work.
>
>
> I posted 2 weeks ago that I plan to move coyote/tomcat5 from j-t-c to
> catalina, to break the circular dep. For tomcat41 and 3.3 we need to keep
> them in j-t-c ( so they work with the current released version ). Nobody
> objected so far - so in about 15 minutes it'll happen, hurry up if you
> don't like the idea :-)
I know the build will be broken in 15 minutes then :-D
> BTw, part of the preparation for releasing j-t-c I tested it against
> tomcat3.3, tomcat-4.0.6 and 4.1.24. All 3 seem to be working fine.
Cool ! I definitely haven't been spending time checking 4.0.6, but since
it's the same code as 4.1.x with a few additional security checks, I
think it's supposed to be ok.
Remy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0.2] New tag at the end of the week ?
Posted by Costin Manolache <cm...@yahoo.com>.
Remy Maucherat wrote:
>> I'm making another try with modeler - last week we hit several bugs,
>> so I did a lot more testing.
>
> Ok. I hope to get my changes in and tested by monday, but I don't think
> anybody would get hurt if the release is delayed until the end of next
> week ;-)
Changes to modeler ?
I was just working on a new build.
IMO most of the functionality (that was part of 1.0) is stable, except
for the "experimental" features ( persistence, remote ).
I was thinking that after M1 we can make a release ( 1.1 ) and when
the persistence and remote are tested and saved we can move to 2.0 and
remove the static methods ( or release 1.2 with the backward compat and
move to a 2.0 after that ).
We need 1.1 and statics to support tomcat4.1.
>> I haven't heard back from JFC about the vhost fix on jk2- but I did more
>> tests with the unix channel, reconfiguration - things look pretty good
>> IMO. I would like to have jakarta-tomcat-connectors released as a
>> standalone package ( including tomcat-util, coyote + 33 and 4.x
>> connector, jk2, http11)- for use with pre-5.0 containters.
>
> Yes, it's supposed to work.
I posted 2 weeks ago that I plan to move coyote/tomcat5 from j-t-c to
catalina, to break the circular dep. For tomcat41 and 3.3 we need to keep
them in j-t-c ( so they work with the current released version ). Nobody
objected so far - so in about 15 minutes it'll happen, hurry up if you
don't like the idea :-)
BTw, part of the preparation for releasing j-t-c I tested it against
tomcat3.3, tomcat-4.0.6 and 4.1.24. All 3 seem to be working fine.
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0.2] New tag at the end of the week ?
Posted by Remy Maucherat <re...@apache.org>.
Costin Manolache wrote:
> Remy Maucherat wrote:
>
>
>>Remy Maucherat wrote:
>>
>>>Hi,
>>>
>>>I'd like to avoid big gaps like 5.0.0 -> 5.0.1, so I think it would be
>>>good to try to tag and release 5.0.2 at the end of the week.
>>>
>>>It would be packaged for JDK 1.4, with an optional package containing
>>>the extra JARs needed for JDK 1.3 (maybe only Xerces - or Crimson - is
>>>needed ?). If the deployer package could be done by then, it would be
>>>great (I got a volunteer sending me a private email about that).
>>>
>>>Note: I plan to add a new static resource cache by then.
>>>
>>>Comments ?
>>
>>I turns out I am a bit late on the cache update. On the positive side, I
>>think I'll be able to include the deployer in the release.
>>
>>I'll also add a TODO list in the CVS, so that other people, including
>>non committers, can join the dev effort for 5.0, and the rest of us can
>>get an overview. Please add items to the list as needed.
>>When all the items are done, I think we'll be ready to go to beta :)
>
>
> I'm making another try with modeler - last week we hit several bugs,
> so I did a lot more testing.
Ok. I hope to get my changes in and tested by monday, but I don't think
anybody would get hurt if the release is delayed until the end of next
week ;-)
> I haven't heard back from JFC about the vhost fix on jk2- but I did more
> tests with the unix channel, reconfiguration - things look pretty good IMO.
> I would like to have jakarta-tomcat-connectors released as a standalone
> package ( including tomcat-util, coyote + 33 and 4.x connector, jk2,
> http11)- for use with pre-5.0 containters.
Yes, it's supposed to work.
Remy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0.2] New tag at the end of the week ?
Posted by Costin Manolache <cm...@yahoo.com>.
Remy Maucherat wrote:
> Remy Maucherat wrote:
>> Hi,
>>
>> I'd like to avoid big gaps like 5.0.0 -> 5.0.1, so I think it would be
>> good to try to tag and release 5.0.2 at the end of the week.
>>
>> It would be packaged for JDK 1.4, with an optional package containing
>> the extra JARs needed for JDK 1.3 (maybe only Xerces - or Crimson - is
>> needed ?). If the deployer package could be done by then, it would be
>> great (I got a volunteer sending me a private email about that).
>>
>> Note: I plan to add a new static resource cache by then.
>>
>> Comments ?
>
> I turns out I am a bit late on the cache update. On the positive side, I
> think I'll be able to include the deployer in the release.
>
> I'll also add a TODO list in the CVS, so that other people, including
> non committers, can join the dev effort for 5.0, and the rest of us can
> get an overview. Please add items to the list as needed.
> When all the items are done, I think we'll be ready to go to beta :)
I'm making another try with modeler - last week we hit several bugs,
so I did a lot more testing.
I haven't heard back from JFC about the vhost fix on jk2- but I did more
tests with the unix channel, reconfiguration - things look pretty good IMO.
I would like to have jakarta-tomcat-connectors released as a standalone
package ( including tomcat-util, coyote + 33 and 4.x connector, jk2,
http11)- for use with pre-5.0 containters.
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
RE: [5.0.2] New tag at the end of the week ?
Posted by Filip Hanik <ma...@filip.net>.
very cool,
I also added in asynchronous replication to the system, so that the users
can choose whether to have the replication done sync or async
Filip
-----Original Message-----
From: Remy Maucherat [mailto:remm@apache.org]
Sent: Saturday, April 19, 2003 7:48 AM
To: Tomcat Developers List
Subject: Re: [5.0.2] New tag at the end of the week ?
Remy Maucherat wrote:
> Hi,
>
> I'd like to avoid big gaps like 5.0.0 -> 5.0.1, so I think it would be
> good to try to tag and release 5.0.2 at the end of the week.
>
> It would be packaged for JDK 1.4, with an optional package containing
> the extra JARs needed for JDK 1.3 (maybe only Xerces - or Crimson - is
> needed ?). If the deployer package could be done by then, it would be
> great (I got a volunteer sending me a private email about that).
>
> Note: I plan to add a new static resource cache by then.
>
> Comments ?
I turns out I am a bit late on the cache update. On the positive side, I
think I'll be able to include the deployer in the release.
I'll also add a TODO list in the CVS, so that other people, including
non committers, can join the dev effort for 5.0, and the rest of us can
get an overview. Please add items to the list as needed.
When all the items are done, I think we'll be ready to go to beta :)
Remy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0.2] New tag at the end of the week ?
Posted by Remy Maucherat <re...@apache.org>.
Remy Maucherat wrote:
> Hi,
>
> I'd like to avoid big gaps like 5.0.0 -> 5.0.1, so I think it would be
> good to try to tag and release 5.0.2 at the end of the week.
>
> It would be packaged for JDK 1.4, with an optional package containing
> the extra JARs needed for JDK 1.3 (maybe only Xerces - or Crimson - is
> needed ?). If the deployer package could be done by then, it would be
> great (I got a volunteer sending me a private email about that).
>
> Note: I plan to add a new static resource cache by then.
>
> Comments ?
I turns out I am a bit late on the cache update. On the positive side, I
think I'll be able to include the deployer in the release.
I'll also add a TODO list in the CVS, so that other people, including
non committers, can join the dev effort for 5.0, and the rest of us can
get an overview. Please add items to the list as needed.
When all the items are done, I think we'll be ready to go to beta :)
Remy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0.2] New tag at the end of the week ?
Posted by Costin Manolache <cm...@yahoo.com>.
Jean-Francois Arcand wrote:
> Also, since Jasper now requires ant, should we add ant as a
> dependencies? If I do a clean build right now Tomcat 5 will fail at
> startup. If I add ant.jar to common/lib, then of course the exception
> goes away.
I'll try this - ant should be needed only for jasper compilation, we
ship precompiled apps.
> Costin has made a tentative of tagging common-modeler. Can we coordinate
> with him and try to add a "tagged" version of modeler?
I'll tag again tonight,
I'm also trying to get j-t-c ( including jk ) tagged, I tested the java side
with tomcat3.3, 4.0.6, 4.1.24 and 5.0, the only remaining issue is the bug
in mod_jk2 vhosts, I'm waiting for J-F-C to confirm the fix is solving the
problem.
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0.2] New tag at the end of the week ?
Posted by Jean-Francois Arcand <jf...@apache.org>.
Remy Maucherat wrote:
> Hi,
>
> I'd like to avoid big gaps like 5.0.0 -> 5.0.1, so I think it would be
> good to try to tag and release 5.0.2 at the end of the week.
+1
>
>
> It would be packaged for JDK 1.4, with an optional package containing
> the extra JARs needed for JDK 1.3 (maybe only Xerces - or Crimson - is
> needed ?). If the deployer package could be done by then, it would be
> great (I got a volunteer sending me a private email about that).
Good :-)
The endorsed dir will be empty by default, right? I will update the
server.xml to include more documentation when people turns on xml
validation.
Also, since Jasper now requires ant, should we add ant as a
dependencies? If I do a clean build right now Tomcat 5 will fail at
startup. If I add ant.jar to common/lib, then of course the exception
goes away.
>
>
> Note: I plan to add a new static resource cache by then.
>
> Comments ?
Costin has made a tentative of tagging common-modeler. Can we coordinate
with him and try to add a "tagged" version of modeler?
-- Jeanfrancois
>
>
> Remy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
RE: [5.0.2] New tag at the end of the week ?
Posted by Filip Hanik <ma...@filip.net>.
I would still like some help on the order that setDistributable is set on
the standard context, this will allow the clustering to work as specified in
the spec.
It would be great to get that into the tag
--------------------------------------
I modified the StandardContext to respect the <distributable/> flag in
web.xml but I am running into problems with the WebRuleSet.
The StandardContext is "started" ie the start() method is called, before the
setDistributable(true) is called. Hence a context will not be replicated,
because the flag wasn't set.
How would I go about setting this parameter earlier, before the context is
started so that the context can get the correct manager put in place.
With the new spec the web.xml can contain a <distributable/> element meaning
that we can replicate the sessions in the request. If this element is
missing, means that we are not gonna replicate it, hence I need to know. I
can work around this, but I would prefer to not and rather fix the order of
when the "setDistributable" is called
thanks in advance
Filip
---------------------------------------
> -----Original Message-----
> From: Remy Maucherat [mailto:remm@apache.org]
> Sent: Monday, April 14, 2003 12:23 PM
> To: Tomcat Developers List
> Subject: [5.0.2] New tag at the end of the week ?
>
>
> Hi,
>
> I'd like to avoid big gaps like 5.0.0 -> 5.0.1, so I think it would be
> good to try to tag and release 5.0.2 at the end of the week.
>
> It would be packaged for JDK 1.4, with an optional package containing
> the extra JARs needed for JDK 1.3 (maybe only Xerces - or Crimson - is
> needed ?). If the deployer package could be done by then, it would be
> great (I got a volunteer sending me a private email about that).
>
> Note: I plan to add a new static resource cache by then.
>
> Comments ?
>
> Remy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
[5.0.2] New tag at the end of the week ?
Posted by Remy Maucherat <re...@apache.org>.
Hi,
I'd like to avoid big gaps like 5.0.0 -> 5.0.1, so I think it would be
good to try to tag and release 5.0.2 at the end of the week.
It would be packaged for JDK 1.4, with an optional package containing
the extra JARs needed for JDK 1.3 (maybe only Xerces - or Crimson - is
needed ?). If the deployer package could be done by then, it would be
great (I got a volunteer sending me a private email about that).
Note: I plan to add a new static resource cache by then.
Comments ?
Remy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: mod_jk compiled in RH 8.0 with apache 2.0.40-11.3
Posted by Gustavo Lima <li...@opendf.com.br>.
Prasanth,
Thank´s a thousand times. I was not updating the box waiting for all
configurations to finish. After updating to httpd-2.0.40-11.3 everything
went ok to compile.
Thank´s again
Gustavo
----- Original Message -----
From: "Prasanth S" <pa...@yahoo.com>
To: "Tomcat Users List" <to...@jakarta.apache.org>
Cc: "DEVELOPER Tomcat`" <to...@jakarta.apache.org>
Sent: Monday, April 14, 2003 3:43 PM
Subject: Re: mod_jk compiled in RH 8.0 with apache 2.0.40-11.3
> Lima,
> make sure you have libtool version 1.4.2 (this
> should come with defauld rh8.0 installation). I had
> the same problem. make sure that u have upgraded ur
> httpd ..rpm and httpd-devel ..rpm to the latest using
> the commands #>up2date httpd and up2date httpd-devel
> you should have the version 2.0.40-11.3 (RedHat had a
> correction in their defauld httpd rpm. They have
> corrected the /etc/httpd/build/config_vars.mk file).
> Now just use the commands:
> #>./build.sh
> #>./configure --with-apxs=/path/to/apxs ....
> #>make
> #>make install
> These were the steps i've taken and i got it
> working. Now i have my apache and tomcat working
> perfectly for me.
>
> Prasanth S.
> --- Gustavo Lima <li...@opendf.com.br> wrote:
> > Hi All,
> >
> > Does anybody have a mod_jk compiled in RH 8.0 with
> > apache 2.0.40*? I´m trying to compile mod_jk for a
> > week and always get errors. I´m sending you all the
> > process:
> >
> > [root@erosnovo native]# ./buildconf.sh
> > libtoolize --force --automake --copy
> > aclocal
> > automake -a --foreign -i --copy
> > autoconf
> > [root@erosnovo native]# ./configure
> > --with-apxs=/usr/sbin/apxs
> >
>
>
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Tax Center - File online, calculators, forms, and more
> http://tax.yahoo.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: mod_jk compiled in RH 8.0 with apache 2.0.40-11.3
Posted by Prasanth S <pa...@yahoo.com>.
Lima,
make sure you have libtool version 1.4.2 (this
should come with defauld rh8.0 installation). I had
the same problem. make sure that u have upgraded ur
httpd ..rpm and httpd-devel ..rpm to the latest using
the commands #>up2date httpd and up2date httpd-devel
you should have the version 2.0.40-11.3 (RedHat had a
correction in their defauld httpd rpm. They have
corrected the /etc/httpd/build/config_vars.mk file).
Now just use the commands:
#>./build.sh
#>./configure --with-apxs=/path/to/apxs ....
#>make
#>make install
These were the steps i've taken and i got it
working. Now i have my apache and tomcat working
perfectly for me.
Prasanth S.
--- Gustavo Lima <li...@opendf.com.br> wrote:
> Hi All,
>
> Does anybody have a mod_jk compiled in RH 8.0 with
> apache 2.0.40*? I�m trying to compile mod_jk for a
> week and always get errors. I�m sending you all the
> process:
>
> [root@erosnovo native]# ./buildconf.sh
> libtoolize --force --automake --copy
> aclocal
> automake -a --foreign -i --copy
> autoconf
> [root@erosnovo native]# ./configure
> --with-apxs=/usr/sbin/apxs
>
__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more
http://tax.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: mod_jk compiled in RH 8.0 with apache 2.0.40-11.3
Posted by Prasanth S <pa...@yahoo.com>.
Lima,
make sure you have libtool version 1.4.2 (this
should come with defauld rh8.0 installation). I had
the same problem. make sure that u have upgraded ur
httpd ..rpm and httpd-devel ..rpm to the latest using
the commands #>up2date httpd and up2date httpd-devel
you should have the version 2.0.40-11.3 (RedHat had a
correction in their defauld httpd rpm. They have
corrected the /etc/httpd/build/config_vars.mk file).
Now just use the commands:
#>./build.sh
#>./configure --with-apxs=/path/to/apxs ....
#>make
#>make install
These were the steps i've taken and i got it
working. Now i have my apache and tomcat working
perfectly for me.
Prasanth S.
--- Gustavo Lima <li...@opendf.com.br> wrote:
> Hi All,
>
> Does anybody have a mod_jk compiled in RH 8.0 with
> apache 2.0.40*? I�m trying to compile mod_jk for a
> week and always get errors. I�m sending you all the
> process:
>
> [root@erosnovo native]# ./buildconf.sh
> libtoolize --force --automake --copy
> aclocal
> automake -a --foreign -i --copy
> autoconf
> [root@erosnovo native]# ./configure
> --with-apxs=/usr/sbin/apxs
>
__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more
http://tax.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org