RE: configure for jakarta-tomcat-connectors

2001-05-31 Thread GOMEZ Henri

Hi,

I have added support for static linking of mod_jk (for 
Apache-1.3.x). I have
used automake to reach it, it has side effects I would like to comment:
- apxs cannot be used build mod_jk.so.
- It needs autoconf/automake for prepare the *.in file. (Only 
for develloppers).
- It needs libtools.

I am quite unhappy about not beeing able to use apxs to build 
mod_jk.so, but I
have not find a clean solution. Has someone an idea?


What about a dual strategy ?

DSO using current autoconf stuff and STATIC the new one ?



Re: configure for jakarta-tomcat-connectors

2001-05-31 Thread jean-frederic clere

GOMEZ Henri wrote:
 
 Hi,
 
 I have added support for static linking of mod_jk (for
 Apache-1.3.x). I have
 used automake to reach it, it has side effects I would like to comment:
 - apxs cannot be used build mod_jk.so.
 - It needs autoconf/automake for prepare the *.in file. (Only
 for develloppers).
 - It needs libtools.
 
 I am quite unhappy about not beeing able to use apxs to build
 mod_jk.so, but I
 have not find a clean solution. Has someone an idea?
 
 
 What about a dual strategy ?
 
 DSO using current autoconf stuff and STATIC the new one ?

Yes, but automake builds the Makefile.in out of the Makefile.am... So the
dynamic linking  Makefile.in are lost.
The trick I have thought of is to use automake to generate the Makefile.in,
patch the Makefile.in to put back the dynamic linking part and commit both file
(Of with a note that automake should only be use to regenerate the Makefile.in
and both file have to be committed).



RE: configure for jakarta-tomcat-connectors

2001-05-17 Thread GOMEZ Henri

 
 Error - it shouldn't be in common...

Are you sure ?

in jk_jni_worker there is a jni_worker_factory() which is 
referenced in jk_worker_list.h which is used to determine
workers in jk_worker.c (get_factory_for).

If jk_jni_worker is removed from common, it should be also
removed from the list of know workers (in jk_worker_list.h)
or mod_jk will have to be built with ../common/*.c and ../jni/*.c ?

Thansk to clarify

But it should be in jni.

Are yo
 jk_jni_worker uses JNI to start tomcat in the same process with
 Apache(2.0) or IIS/NES and uses in-process calls instead of TCP/IP.

That means it should be configured for apache with configure 
--enable-jni
--with-apxs=path_to_apxs --with-java-home=path_to_java_home correct?

Does someone knows how to guess OS_TYPE? That is for -I$(JAVA_INCLUDE)
-I$(JAVA_INCLUDE)/$(OS_TYPE)

Not easy with configure but libtool seems to have that :)

 
 It should be the fastest - but it's the hardest to debug, 
and it hasn't
 been tunned too much. ( it is similar with the NES servlet container,
 which runs in-process too, or with mod_perl/mod_php  ).
 
 Costin
 

+++ CUT +++




Re: configure for jakarta-tomcat-connectors

2001-05-16 Thread jean-frederic clere

[EMAIL PROTECTED] wrote:
 
 On Tue, 15 May 2001, jean-frederic clere wrote:
 
  By the way I have a question: Why jk_jni_worker.c is in common not in jni? What
  it is used for? (I have to add JAVA_HOME to the configure for it and I am
  curious).
 
 Error - it shouldn't be in common...

But it should be in jni.

 
 jk_jni_worker uses JNI to start tomcat in the same process with
 Apache(2.0) or IIS/NES and uses in-process calls instead of TCP/IP.

That means it should be configured for apache with configure --enable-jni
--with-apxs=path_to_apxs --with-java-home=path_to_java_home correct?

Does someone knows how to guess OS_TYPE? That is for -I$(JAVA_INCLUDE)
-I$(JAVA_INCLUDE)/$(OS_TYPE)

 
 It should be the fastest - but it's the hardest to debug, and it hasn't
 been tunned too much. ( it is similar with the NES servlet container,
 which runs in-process too, or with mod_perl/mod_php  ).
 
 Costin
 

+++ CUT +++



RE: configure for jakarta-tomcat-connectors

2001-05-15 Thread GOMEZ Henri

I have started a configure.in and makefile(s).in for the
jakarta-tomcat-connectors.
Currently I have just prepared it for Apache2.0 and Apache1.3, 
before going on I
have some questions:

I tested the configure/makefile stuff and it works well but
could you also add the java detection for JNI support ?

ie: --with-java=/usr/jdk1.3.0/ 

Many users asked about statically compiling mod_jk in Apache, 
could you add a --with-apache flag ?

Do you think we could add also the config dir path to have
default mod_jk.conf and workers.properties installed ?

feature which could be added, is the config 

ie: --sysconfdir=/etc/httpd/conf(à la Redhat)


Thanks for that contribution



Re: configure for jakarta-tomcat-connectors

2001-05-15 Thread jean-frederic clere

GOMEZ Henri wrote:
 
 I have started a configure.in and makefile(s).in for the
 jakarta-tomcat-connectors.
 Currently I have just prepared it for Apache2.0 and Apache1.3,
 before going on I
 have some questions:
 
 I tested the configure/makefile stuff and it works well but
 could you also add the java detection for JNI support ?
 
 ie: --with-java=/usr/jdk1.3.0/

My idea is to build one connector per call of configure/make, --with-java should
build the JNI support, correct?
I have noted that common contains jk_jni_worker.c, should not we move it in jni?

 
 Many users asked about statically compiling mod_jk in Apache,
 could you add a --with-apache flag ?

Yes, but we cannot use apxs for that... Following the ideas of mod_webapp we
should libtool for this purpose.
Then it is more easy to use libtool for everything.

 
 Do you think we could add also the config dir path to have
 default mod_jk.conf and workers.properties installed ?
 
 feature which could be added, is the config
 
 ie: --sysconfdir=/etc/httpd/conf(à la Redhat)

If we use --with-apxs the conf is given by apxs, in case we use --with-apache
yes.
This means we need to support make install.

 
 Thanks for that contribution

You are welcome



Re: configure for jakarta-tomcat-connectors

2001-05-15 Thread jean-frederic clere

[EMAIL PROTECTED] wrote:
 
 On Mon, 14 May 2001, jean-frederic clere wrote:
 
  Hi,
 
  I have started a configure.in and makefile(s).in for the
  jakarta-tomcat-connectors.
 
 Excelent !
 
  Currently I have just prepared it for Apache2.0 and Apache1.3, before going on I
  have some questions:
 
  - The idea is to have one configure.in in
  jakarta-tomcat-connectors/jk/src/native and a makefile.in for each supported
  WebServer. Does it sound Ok?
 
 Whatever is simpler.
 
  - Should I already think of using APR? - Just that some of my plateform are not
  (yet) supported and I am reluctant of adding more #idef in the code -
 
 One solution would be to create a common_apr and wrappers for the existing
 functions in common, using apr.
 All platfrom-dependent code should be in common, and we could use the
 current common in parallel with  common_apr until it is stable and tested
 on all cases.
 
 I know apr is supposed to work everywhere and with any server, but I
 wouldn't remove the current code until it is actually tested. I'm quite
 scared of what'll happen on Windows + IIS for example...
 
 The jk_ stuff in common was supposed to be very close to APR as API,
 so maybe a better idea would be to (temporary) use
 
 #ifdev ARP
   apr_function
 #else
   jk_function
 #fi

Ok, I will used HAVE_APR for this purpose.

 
 If needed, you could change the jk_ APIs to match the APR function.

Probably additing an apr_pool_t *ctx to the parameters solves most of needed
changes.
 
 
  - What should I do with the other WebServers (netscape, jni etc)?
 
 Just leave the existing makefiles in, in time someone could include that
 in the configure code.
 
  The configure.in assumes that the Apache connectors sub-directories are
  apache-1.3 and apache-2.0. I think that more consistant with mod_webapp.
 
 +1
 
 Costin



RE: configure for jakarta-tomcat-connectors

2001-05-15 Thread GOMEZ Henri

  The configure.in assumes that the Apache connectors 
sub-directories are
  apache-1.3 and apache-2.0. I think that more consistant 
with mod_webapp.

done



RE: configure for jakarta-tomcat-connectors

2001-05-15 Thread GOMEZ Henri

My idea is to build one connector per call of configure/make, 
--with-java should
build the JNI support, correct?
I have noted that common contains jk_jni_worker.c, should not 
we move it in jni?

no, jk_jni_worker could also be used into apache 1.3/2.0.
And that's HOW IBM use mod_jk on at least AS/400 using JNI
instead of AJP12/AJP13...

 Many users asked about statically compiling mod_jk in Apache,
 could you add a --with-apache flag ?

Yes, but we cannot use apxs for that... Following the ideas of 
mod_webapp we
should libtool for this purpose.
Then it is more easy to use libtool for everything.

apxs is for DSO but the question was how to be sure the
mod_jk stuff could be compiled statically in apache ?

 
 Do you think we could add also the config dir path to have
 default mod_jk.conf and workers.properties installed ?
 
 feature which could be added, is the config
 
 ie: --sysconfdir=/etc/httpd/conf(à la Redhat)

If we use --with-apxs the conf is given by apxs, in case we 
use --with-apache
yes.
This means we need to support make install.

PS: I commited your Makefile and configure stuff !!!



Re: configure for jakarta-tomcat-connectors

2001-05-15 Thread cmanolache

Wow, it is so good to see development discussion on tomcat-dev, and be
able to participate :-)

I have a big question - what happens if configure/libtool is used and
different options are given for mod_jk and apache ?

I can't give a concrete example, but APXS had the big benefit that it
cached all the decisions taken when Apache was built, and that insured
that the same decisions were used when building modules.

I understand that most guesses done by configure will be the same - so
by doing configure again we'll likely get the same flags/options, but
there are some options and some special features that could affect us in
very tricky ways. 

You know all the trubles you get with KDE/Gnome when a certain binary is
linked against an older library - or the EAPI problems. It is possible
to have multiple versions of a library on a system, or to have apache
 configured to use a very specific version ( /usr/secure/libs/).

Costin


On Tue, 15 May 2001, jean-frederic clere wrote:

 GOMEZ Henri wrote:
  
  I have started a configure.in and makefile(s).in for the
  jakarta-tomcat-connectors.
  Currently I have just prepared it for Apache2.0 and Apache1.3,
  before going on I
  have some questions:
  
  I tested the configure/makefile stuff and it works well but
  could you also add the java detection for JNI support ?
  
  ie: --with-java=/usr/jdk1.3.0/
 
 My idea is to build one connector per call of configure/make, --with-java should
 build the JNI support, correct?
 I have noted that common contains jk_jni_worker.c, should not we move it in jni?
 
  
  Many users asked about statically compiling mod_jk in Apache,
  could you add a --with-apache flag ?
 
 Yes, but we cannot use apxs for that... Following the ideas of mod_webapp we
 should libtool for this purpose.
 Then it is more easy to use libtool for everything.
 
  
  Do you think we could add also the config dir path to have
  default mod_jk.conf and workers.properties installed ?
  
  feature which could be added, is the config
  
  ie: --sysconfdir=/etc/httpd/conf(à la Redhat)
 
 If we use --with-apxs the conf is given by apxs, in case we use --with-apache
 yes.
 This means we need to support make install.
 
  
  Thanks for that contribution
 
 You are welcome
 




Re: configure for jakarta-tomcat-connectors

2001-05-15 Thread cmanolache

On Tue, 15 May 2001, jean-frederic clere wrote:

 By the way I have a question: Why jk_jni_worker.c is in common not in jni? What
 it is used for? (I have to add JAVA_HOME to the configure for it and I am
 curious).

Error - it shouldn't be in common...

jk_jni_worker uses JNI to start tomcat in the same process with
Apache(2.0) or IIS/NES and uses in-process calls instead of TCP/IP.

It should be the fastest - but it's the hardest to debug, and it hasn't
been tunned too much. ( it is similar with the NES servlet container,
which runs in-process too, or with mod_perl/mod_php  ).


Costin

  
  
  I understand that most guesses done by configure will be the same - so
  by doing configure again we'll likely get the same flags/options, but
  there are some options and some special features that could affect us in
  very tricky ways.
  
  You know all the trubles you get with KDE/Gnome when a certain binary is
  linked against an older library - or the EAPI problems. It is possible
  to have multiple versions of a library on a system, or to have apache
   configured to use a very specific version ( /usr/secure/libs/).
  
  Costin
  
  On Tue, 15 May 2001, jean-frederic clere wrote:
  
   GOMEZ Henri wrote:
   
I have started a configure.in and makefile(s).in for the
jakarta-tomcat-connectors.
Currently I have just prepared it for Apache2.0 and Apache1.3,
before going on I
have some questions:
   
I tested the configure/makefile stuff and it works well but
could you also add the java detection for JNI support ?
   
ie: --with-java=/usr/jdk1.3.0/
  
   My idea is to build one connector per call of configure/make, --with-java should
   build the JNI support, correct?
   I have noted that common contains jk_jni_worker.c, should not we move it in jni?
  
   
Many users asked about statically compiling mod_jk in Apache,
could you add a --with-apache flag ?
  
   Yes, but we cannot use apxs for that... Following the ideas of mod_webapp we
   should libtool for this purpose.
   Then it is more easy to use libtool for everything.
  
   
Do you think we could add also the config dir path to have
default mod_jk.conf and workers.properties installed ?
   
feature which could be added, is the config
   
ie: --sysconfdir=/etc/httpd/conf(à la Redhat)
  
   If we use --with-apxs the conf is given by apxs, in case we use --with-apache
   yes.
   This means we need to support make install.
  
   
Thanks for that contribution
  
   You are welcome
  
 




RE: configure for jakarta-tomcat-connectors

2001-05-14 Thread GOMEZ Henri

I have started a configure.in and makefile(s).in for the
jakarta-tomcat-connectors.

Thanks great works :!

Currently I have just prepared it for Apache2.0 and Apache1.3, 
before going on I
have some questions:

- The idea is to have one configure.in in
jakarta-tomcat-connectors/jk/src/native and a makefile.in for 
each supported
WebServer. Does it sound Ok?

Seems good, since users could go directly to their preferred
web-server. I saw no advantage to try to resolv in a top
configure all the case (AP1.3/2.0/IIS/NES)...

- Should I already think of using APR? - Just that some of my 
plateform are not
(yet) supported and I am reluctant of adding more #idef in the code -

If your platform are not supported and that #ifdef could help, let's
go. And maybe to avoid #ifdef USE_APR in all the code, we could create 
1/2 C wrapper files ?

- What should I do with the other WebServers (netscape, jni etc)?

netscape and jni will need support. May be Cosin could take a look
at JNI since he play with it, but there is an open position for a 
NETSCAPE USER/DEV. But in each cache what about providing skeleton
configure.in ?

The configure.in assumes that the Apache connectors sub-directories are
apache-1.3 and apache-2.0. I think that more consistant with 
mod_webapp.

I'll fix that ASAP..

Please, have a look to the attached files and make comments :=) 

Thanks again.



Re: configure for jakarta-tomcat-connectors

2001-05-14 Thread cmanolache

On Mon, 14 May 2001, jean-frederic clere wrote:

 Hi,
 
 I have started a configure.in and makefile(s).in for the
 jakarta-tomcat-connectors.

Excelent !

 Currently I have just prepared it for Apache2.0 and Apache1.3, before going on I
 have some questions:
 
 - The idea is to have one configure.in in
 jakarta-tomcat-connectors/jk/src/native and a makefile.in for each supported
 WebServer. Does it sound Ok?

Whatever is simpler. 


 - Should I already think of using APR? - Just that some of my plateform are not
 (yet) supported and I am reluctant of adding more #idef in the code -

One solution would be to create a common_apr and wrappers for the existing
functions in common, using apr.
All platfrom-dependent code should be in common, and we could use the
current common in parallel with  common_apr until it is stable and tested
on all cases.

I know apr is supposed to work everywhere and with any server, but I
wouldn't remove the current code until it is actually tested. I'm quite
scared of what'll happen on Windows + IIS for example...

The jk_ stuff in common was supposed to be very close to APR as API, 
so maybe a better idea would be to (temporary) use 

#ifdev ARP
  apr_function
#else 
  jk_function
#fi

If needed, you could change the jk_ APIs to match the APR function.


 - What should I do with the other WebServers (netscape, jni etc)?

Just leave the existing makefiles in, in time someone could include that
in the configure code.

 The configure.in assumes that the Apache connectors sub-directories are
 apache-1.3 and apache-2.0. I think that more consistant with mod_webapp.

+1

Costin