>> 1) On my configuration, the standard tomcat 3.3.1 
>>    run as user tomcat3, group tomcat3, but apache2
>>    run as user apache2, group apache2. 
>
>That won't work very well. At least for in-process mode
>it is completely impossible to do it otherwise.

The problem is that I try to use the tomcat 3.3.1 installed
which was configured to be used by a tomcat3/tomcat3 user, 
so there is bad rigths on directories and files, since in
jni tomcat is run by apache2/apache2

>There are 2 cases:
>- you want to have tomcat and apache in the same directory
>structure. In this case same user id is probably required,
>and we may have problems with log rolling.

Exact, I'll need to copy the tomcat directories to an
apache2 dir with apache2 rigths

>- different directory structures - in which case you can
>have different users. 
>
>A particular case is tomcat.base != tomcat.home, and you 
>may have multiple tomcats with different uids...
>
>Probably the default should be the easiest to understand
>case ( same user, one dir layout ), and let advanced users 
>deal with other cases.

>>    So log/spool files can't be accessed in rw mode
>>    since all these files are 644 to tomcat3/tomcat3.
>>    I saw there is a setUser APR impl but since it's 
>>    not a static method, it couldn't be called by
>>    TomcatStarter. Also shm file is owned by root,
>>    and so couldn't be used by childs (apache2).
>
>setUser should be called very late, after all resources
>are aquired ( port 80, open log files, etc ). That would be
>the start callback. Each jk component can be retrieved
>by name ( "apr" in this case ), and you get an instance and
>call the method.

And what about errors on SHM file ?

>> 2) Tomcat3 at least allow the use of TOMCAT_HOME and
>>    TOMCAT_INSTALL, and in that case config files are
>>    in $TOMCAT_HOME/conf and tomcat.jar in $TOMCAT_INSTALL/lib.
>>    workers2.properties should be updated accordingly.
>>    I think there is a similar system for TC 4.0/4.1
>
>> workers2.properties (nb I put tomcat-jni.jar in tomcat/lib 
>not in tomcat/bin :
>
>That's fine, I was trying to get a consistent location for 4.x 
>and 3.3. 
>I also thing jars should be in lib, but I understand the argument 
>that executable jars should be in bin. 

Hum, it break FHS/LSB layout on Linux boxes (for example), since 
tomcat/bin goes in /usr/bin or /usr/sbin and tomcat-jni.jar couldn't
be run by shell command. My thinking is that jni is not an executable
but an exec wrapper, so it will be better located in tomcat/lib.

What others developpers 3.3/4.x think about that ?

>Please keep in mind that the workers2.properties should work fine
>with any version of tomcat ( i.e. TOMCAT_HOME and TOMCAT_INSTALL
>can point to a catalina installation ).  

Yes

>> 3) Under Linux we have to set many env vars before being
>>    able to load libjvm.so (here is what I've to do to 
>>    use the IBM SDK 1.3.1 :
>> 
>> export JAVAHOME=/opt/IBMJava2-131/jre
>> export 
>LD_LIBRARY_PATH=$JAVAHOME/bin:$JAVAHOME/bin/classic:$LD_LIBRARY_PATH
>> 
>> Linux users running a kernel 2.4 should also add :
>> 
>> export LD_ASSUME_KERNEL=2.2.5
>> 
>> What about adding ENV params in [vm:] to setup all of these directly
>> from httpd2 ?
>
>Also TOMCAT_HOME must be set ( and TOMCAT_INSTALL ). 
>
>Not sure what adding ENV means, but if you talk about setenv() it won't
>work on all cases ( VMs, etc ). Setting the env vars before executing 
>apache and tomcat is the only case that worked in all configurations.

I updated jk2 to handle ENV in [vm] :

[vm:]
info=Parameters used to load a JVM in the server process
#OPT=-Djava.class.path=${TOMCAT_INSTALL}/lib/tomcat-jni.jar:${TOMCAT_INSTALL}/lib/tomcat.jar
OPT=-Djava.class.path=${TOMCAT_HOME}/lib/tomcat-jni.jar
OPT=-Dtomcat.home=${TOMCAT_HOME}
OPT=-Dcatalina.home=${TOMCAT_HOME}
OPT=-Xmx128M
ENV=JAVA_HOME=/opt/IBMJava2-131
ENV=JAVAHOME=/opt/IBMJava2-131/jre
ENV=LD_LIBRARY_PATH=/opt/IBMJava2-131/jre/bin:/opt/IBMJava2-131/jre/bin/classic: 
ENV=TOMCAT_HOME=/var/tomcat3
ENV=LD_ASSUME_KERNEL=2.2.5
disabled=0

But I've got problem with putenv/getenv calls, which didn't 
appears to works (did there is a problem if we want to 
putenv() from inside a process ?).

>From what I see, if I do a putenv() and then getenv(), just
after, it works fine, but a getenv() later (same pid/same threadid)
return null !


>> 4) It seems that jni is loaded in each child (I've build 
>apache 2.0.36
>>    using -with-mpm=worker on my box) and sus there is 3 jvm 
>started and conflict
>>    with listen port later (8080, 8007, 8009), so we should 
>use a lock file to
>>    avoid duplicate initialization
>
>Already have a solution for that - disable the HTTP listeners 
>and the old 
>ajp listeners, and it'll work fine.
>
>The new AJP connector ( coyote-jk2 ) is aware of load balancing ( 
>in-process is a particular case of load balancing ), and will 
>use a port 
>range ( if 8009 is taken, it'll use 8010, 8011... ).

ok. 

>That means we can have a single config file and multiple instances
>( no need for separate server.xml ). There are few details related
>with the log name. The 'instance id' must be used in creating the 
>name for the log and all other resources.
>
>BTW, the instance id ( former jvmRoute ) is automatically generated
>from the ajp13 port number and host ( i.e. localhost:8009, etc ).
>
>
>> 5) What about using tomcat.user and tomcat.group properties 
>and use setUser() in
>>    TomcatStarter run method ?
>
>I would put this in a JkUser, and use a coyote callback ( 
>CONTAINER_START).
>
>It's easy to do it - but I'm doing some research on how things work on 
>windows ( i.e. I heard they have some way to play with the user id ).
>
>
>> Of course will have to change public native int setUser( 
>String user, String group )
>> to public static native int setUser( String user, String group ).
>
>No, it'll be:
>
> AprImpl apr=WorkerEnv.getHandler( "apr" );
> apr.setUser(... );
>
>That works for all jk components ( you can do the same for 
>"shm" if you 
>want to play with the scoreboard ).
>
>But I preffer 
>class JkUser extends JkHandler {
>   void setUser(String);
>
>   void init() {
>     apr.setUser();
>   }
>}
>
>It's more flexible.

Did you plan to add setUser calls ?

>> We have to change JVM user/group in the early stage of init 
>since we want
>> to be sure that logs, pid and others R/W files will be 
>available to the
>> running process. 
>
>I think late - to make sure logs and other resources can be acquired ( 
>port 80, etc ).

Hum, so jni/java could get root protected resources ?
I didn't understand well here, since jni/vm is launched by a child
and apache2 child are no more root, (only main process stay root) 
so they couldn't get access to resource (and that's why I've got
problem with shm access, which was created by the main process which
is root).

I've got a question for Apache 2 gurus, which part of modules are
executed by main process (which is root) (postconfig ?), 
and which part by child process (nobody or apache2) (childinit ?).

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

Reply via email to