You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Mladen Turk <mt...@mappingsoft.com> on 2002/06/08 19:10:32 UTC
[PROPOSAL] RegisterNatives
Hi,
Are there any reason why are we loading jkjni, or mod_jk2 for inprocess
mode.
I think that the same can be accomplished using JNI RegisterNatives.
Further more you can build the mod_jk as static module then.
It would IMO require and some minor java refactoring just to know when
to load the jkjni calling AprImpl.jniMode().
I've tested the concept and it works perfectly withouth the need to
specify the nativeSo in config.
MT.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [PROPOSAL] RegisterNatives
Posted by Mladen Turk <mt...@mappingsoft.com>.
> -----Original Message-----
> From: costinm@covalent.net [mailto:costinm@covalent.net]
> Sent: 9. lipanj 2002 18:04
> To: Mladen Turk
> Cc: 'Tomcat Developers List'
> Subject: RE: [PROPOSAL] RegisterNatives
>
>
> Few questions:
>
> - Do we still need System.load() in jniMode ? I noticed you made it
> configurable, but if registerNatives works there's no reason to keep
> the old ( ugly ) mechanism.
>
Think not.
> I'll uncomment it and add a method that will be called in
> in-process mode to set a flag to disable the initialize() (
> it'll also set the workerEnv and all the stuff we compute for
> standalone mode )
>
Perhaps Something like initialize( bool standAlone) should do.
MT.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [PROPOSAL] RegisterNatives
Posted by co...@covalent.net.
Few questions:
- Do we still need System.load() in jniMode ? I noticed you made it
configurable, but if registerNatives works there's no reason to keep
the old ( ugly ) mechanism.
- I'm not sure it'll work in standalone mode if you comment out
apr_initialize(). "Standalone" means java using jkjni to access
unix channel, scoreboard, locks and all the apr stuff that'll
be exposed.
I'll uncomment it and add a method that will be called in in-process
mode to set a flag to disable the initialize() ( it'll also set
the workerEnv and all the stuff we compute for standalone mode )
Costin
On Sun, 9 Jun 2002, Mladen Turk wrote:
>
> > -----Original Message-----
> > From: costinm@covalent.net [mailto:costinm@covalent.net]
> > Sent: 8. lipanj 2002 22:38
> > To: Tomcat Developers List
> > Subject: Re: [PROPOSAL] RegisterNatives
> >
> >
> > On Sat, 8 Jun 2002, Mladen Turk wrote:
> >
> > > Are there any reason why are we loading jkjni, or mod_jk2 for
> >
> > +1 !
>
> Ok, here is the patch.
>
> RegisterNatives are called inside jk_worker_jni.c for AprImpl class.
> There is a small change in AprImpl.java that checks the name of
> jniModeSo and if
> the name equals "inprocess" (didn't think of anything smarter) the
> native lib loading
> is simply skipped. We trust that the native functions are inserted in
> the JVM from the caller.
>
> There is one potential problem about portability (apr_initialize call in
> native initialize),
> cause there is no need to call that from apache so I ifdef that out. The
> apr_initialize for IIS should be called
> IMO from DllMain in jk_isapi_plugin, but I'm not familiar with that.
>
> Nevertheless I've tested it with TC 4.1.3 and Apache-2.0.37-dev on
> WINXP, build with VS7,
> and it works as good as the 'standard' version :-).
>
> Simply put the apr.jniModeSo=inprocess in jk2.properties, and that's it.
>
>
> MT.
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [PROPOSAL] RegisterNatives
Posted by Mladen Turk <mt...@mappingsoft.com>.
> -----Original Message-----
> From: costinm@covalent.net [mailto:costinm@covalent.net]
> Sent: 8. lipanj 2002 22:38
> To: Tomcat Developers List
> Subject: Re: [PROPOSAL] RegisterNatives
>
>
> On Sat, 8 Jun 2002, Mladen Turk wrote:
>
> > Are there any reason why are we loading jkjni, or mod_jk2 for
>
> +1 !
Ok, here is the patch.
RegisterNatives are called inside jk_worker_jni.c for AprImpl class.
There is a small change in AprImpl.java that checks the name of
jniModeSo and if
the name equals "inprocess" (didn't think of anything smarter) the
native lib loading
is simply skipped. We trust that the native functions are inserted in
the JVM from the caller.
There is one potential problem about portability (apr_initialize call in
native initialize),
cause there is no need to call that from apache so I ifdef that out. The
apr_initialize for IIS should be called
IMO from DllMain in jk_isapi_plugin, but I'm not familiar with that.
Nevertheless I've tested it with TC 4.1.3 and Apache-2.0.37-dev on
WINXP, build with VS7,
and it works as good as the 'standard' version :-).
Simply put the apr.jniModeSo=inprocess in jk2.properties, and that's it.
MT.
Re: [PROPOSAL] RegisterNatives
Posted by co...@covalent.net.
On Sat, 8 Jun 2002, Mladen Turk wrote:
> Are there any reason why are we loading jkjni, or mod_jk2 for inprocess
> mode.
> I think that the same can be accomplished using JNI RegisterNatives.
> Further more you can build the mod_jk as static module then.
> It would IMO require and some minor java refactoring just to know when
> to load the jkjni calling AprImpl.jniMode().
jkjni is for java standalone. The only reason we load mod_jk2.so for
inprocess is that nobody wrote the RegisterNative code yet :-) ( it was
easier to just load mod_jk2 ).
> I've tested the concept and it works perfectly withouth the need to
> specify the nativeSo in config.
+1 !
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>