On Fri, 30 Aug 2002, jean-frederic clere wrote: > I still see no good reasons to make a 'copy'...
Well, for the JNI invocation ( starting the VM inprocess ) - I just want to make sure that jk is not missing any 'trick' - as you know this is a very OS-specific and delicate problem. Right now it seems to work well, but we require LD_LIBRARY_PATH to be set before with java .so in it - if deamon can get around that on linux, than that's something to copy. The other thing to copy is the service monitor and service starter - which seems cool and cleaner than jk_nt_service. I still want to keep the wrapper.properties, it gives a lot of control and is easier to use ( IMO ) then using CLI. Another reason - we'll have a single native build to worry about and the user will have a more consistent behavior ( same logs, same config, etc ) > Surely the code in daemon needs a cleaning and some changes to fit mod_jk needs. > A "ant download" task could bring the needed source in the mod_jk directory to > ease the release mechanism. Well, it's a bit more than 'copy' - I would like to use the same logger and same communication mechanism with the VM as jk is using ( i.e. messages, invoke/get/setAttribute, etc). > I will try to find time to get the JVM started under Apache as it was in > mod_jserv using the code in daemon. +1. You may also 'copy' some code from jserv. I think it should also work under IIS and the other servers - the Apache parent process will act as the 'controller'. One important thing is that the code in daemon just starts the JVM and supports 'restart' ( using that 123 return code ). What we would need and what jserv did is to keep it alive - i.e. unless a special 'stop me' return code is given, we should restart the process if it dies. Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
