Rename jK2 to mod_jk2 ?

[GOMEZ Henri <hg...@slib.fr>]

What about renaming native2 (jk2) in JTC to mod_jk2
and jk2_module ?

It will allow us to install both modules at the same 
times and test original mod_jk and new mod_jk.

It will be need to rename all non static references,
variables functions, but I could do that, by suffixing
with jk2_ :

And to be consistent, it could be nice to suffix the native,
original mod_jk, with jk_ 

If you agree, I could do this quickly, but JTC developpers
shouldn't do updates for 1-3 hours...

Regards

-
Henri Gomez                 ___[_]____
EMAIL : hgomez@slib.fr        (. .)                     
PGP KEY : 697ECEDD    ...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Rename jK2 to mod_jk2 ?

[jean-frederic clere <jf...@fujitsu-siemens.com>]

GOMEZ Henri wrote:
> 
> What about renaming native2 (jk2) in JTC to mod_jk2
> and jk2_module ?

If we consider native2 as a remplacement for the native of mod_jk, no. That is
just a new version.
If you thing of easy testing may be... I have libjk.so from native and mod_jk.so
from native2 and I stop/start Apache for testing both.

> 
> It will allow us to install both modules at the same
> times and test original mod_jk and new mod_jk.
> 
> It will be need to rename all non static references,
> variables functions, but I could do that, by suffixing
> with jk2_ :
> 
> And to be consistent, it could be nice to suffix the native,
> original mod_jk, with jk_
> 
> If you agree, I could do this quickly, but JTC developpers
> shouldn't do updates for 1-3 hours...

And that will be a big commit ;-)

> 
> Regards
> 
> -
> Henri Gomez                 ___[_]____
> EMAIL : hgomez@slib.fr        (. .)
> PGP KEY : 697ECEDD    ...oOOo..(_)..oOOo...
> PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
> 
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Rename jK2 to mod_jk2 ?

[co...@covalent.net]

On Fri, 15 Feb 2002, GOMEZ Henri wrote:

> What about renaming native2 (jk2) in JTC to mod_jk2
> and jk2_module ?

+1 if you talk about the binary. -0 if you talk about directory/file
names. 

In mod_jk2 we already removed a lot of 'public' symbols that could
conflict if both modules are loaded. Instead of doing a mechanical
replace, I would do it gradually, and maybe finish the 'virtualization'
of jk2.

I think the effects are very good, it improves code readability and
extensibility. What I'm talking about is using JNI-style ( or
module style ), with structures and funcion pointer. 
( ok, that's kind-of OO programming in C, but OO is not that bad :-)

> It will allow us to install both modules at the same 
> times and test original mod_jk and new mod_jk.

That's a very good idea, it allows us to ship both
and have a 'backup' plan if something doesn't work.


> It will be need to rename all non static references,
> variables functions, but I could do that, by suffixing
> with jk2_ :

If you want, you can go ahead with that ( but in time I would
still like to continue to organize the code with fewer
globals and more objects )


> And to be consistent, it could be nice to suffix the native,
> original mod_jk, with jk_ 
 
> If you agree, I could do this quickly, but JTC developpers
> shouldn't do updates for 1-3 hours...

I agree with changing the names of non-statics in native2,
but need more time to think about changing dir names. There
are build files, cvs history, habbits that will change as well.


Costin


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

jk2 status

[co...@covalent.net]

I haven't done any commit in the last few weeks, that's because
I'm strugling with the config/autoconfig refactoring ( and I had
a lot of non-tomcat work to do ).

I think the java side is in a pretty good shape. I decided to
give up refactoring the config stuff for the first release,
so I'll check in the config interceptors from 3.3 ( and update
the 4.0 valves ), and hopefully in few weeks be ready for a
beta that can be used as a direct replacement for Ajp13Interceptor
and the ajp connector in 4.0. 

It'll just be faster, cleaner and maybe a bit easier to set
up - no new features should be expected ( even if the code
is there, the goal is to be able to replace the old java
code with something as stable ). 
We can mark the new stuff as 'experimental' for brave 
users, or just wait for the jk2.1 release.

We need to reach agreement on the jk config stuff - do
we want to keep the old setting style in server.xml
and interceptors.xml ? Are we comfortable with using 
web.xml ( with the gain of possibly using admin tools,
a well documented and familiar dtd, etc ) ? Would
it be better to use workers.properties style, and be
consistent with the C side ? All 3 ? 

For autoconf, the old code will be used, but in future
I would like to move it to a separate package. 

I strongly believe that the autoconfig should be integrated
in an admin tool - we can't require people to start
tomcat before apache ( especially in Jni mode :-), and 
it's tricky to make it work in an lb env.
Ajp14-style has similar problems ( tomcat must be running ),
and it's pretty hard to do it right for complex deployments.

So I would change this into a set of config utils, independent
of jk, maybe even use ant as a driver ( and combine it with
the deploy tool, etc). 

I would also reorganize the generator in 2 parts - one
would generate Apache/IIS/NES 'generic' config ( LoadModule,
Ports, options ). And one would generate a config 
fragment out of web.xml ( for each app ). When a new app
is deployed or a change happens, the deploy tool would
call the config module and maybe a server-speciic module
to do soft restart or on-the-fly reloading of mappings.

This keeps jk simple and adds much more flexibility. 

But it depends on your aproval and commits - as we know,
config is the biggest problem for users, and we'll need 
a lot of work here.

Costin
P.S. It's a long mail, today the train to SF is slower than
 usual :-)

 


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>