You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by GOMEZ Henri <hg...@slib.fr> on 2002/05/07 13:04:46 UTC
mod_jk2 (native2) autoconf preliminary works
I started to works on adding autoconf stuff for
mod_jk2 (native2) for Apache 1.3/2.0 and will need
some help and advice since it's not fluent in this
area (JF/Pier are jtc specialists).
Initial works in on Makefile for apxs.
1) What about moving scripts from jk/native to
just jk ? It avoid duplicate between native
and native2.
2) What should be done for APR in Apache 1.3 ?
Should we use external shared apr lib ?
Should we use static build apr (like does webapp) ?
In all case should the apr for 1.3 must be with
or without pthread ?
3) Who could take a look at Makefile I'll commit for
static mod_jk2 built ?
4) What about jni support ?
-
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: mod_jk2 (native2) autoconf preliminary works
Posted by co...@covalent.net.
On Tue, 7 May 2002, Pier Fumagalli wrote:
> > If we would use Glib/Qt/NSPR - we would use the same mechanism,
> > you would install one of those libarary ( each having one common
> > goal with APR - of shielding you against OS-specific code ).
>
> GLIB is the library used by GTK (I didn't know that JK2 needed a widget set
> :), same thing for QT (the widgetery for KDE).
Both Glib and QT have APIs that abstract the OS from the application,
like Java or APR or NSPR.
GLIB does _not_ defines a widget set, but abtractions for threads,
allocation, communication, string operations, hooks, common data
structures.
An important part of Qt is doing exactly the same. As for NSPR,
AFAIK it can be used as a regular library by applications
without any problem.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: mod_jk2 (native2) autoconf preliminary works
Posted by Pier Fumagalli <pi...@betaversion.org>.
"costinm@covalent.net" <co...@covalent.net> wrote:
> On Tue, 7 May 2002, jean-frederic clere wrote:
>>
>> Pier is right... That is more easy to link apr staticly to mod_jk. Having to
>> deliver 2 files instead 1 will only bring more problems.
>
> If you use Apache2 with mod_jk.so, then you _have_ a version of
> libapr.so. Having 2 variations of the apr code will bring more problems.
That's why I'm saying that libapr.so is shipped with Apache 2.0 as a dylib,
so that you can build Apache 2.0 modules against it.... DOH! :)
> If you don't use Apache2, jk2 will require you install a
> libapr.so - the same version that is shiped/taged with Apache2.
And you're going to end up in troubles, because you won't have an APR built
for what you need, but for what Apache 2.0 will need...
As I said, if you get libapr.so from an Apache 2.0/worker and you use to
link against a module which will go in Apache 1.3, you're in troubles...
> And second, that's the only stable/tested/deterministic
> version of APR that exist. If APR1.0 is released in the meantime,
> we'll have to decide what to do, but I hope an Apache2.1 will
> be released at that time too.
Apache 2.1 is _a long_ time from now... You'll be waiting for a while.
> If we would use Glib/Qt/NSPR - we would use the same mechanism,
> you would install one of those libarary ( each having one common
> goal with APR - of shielding you against OS-specific code ).
GLIB is the library used by GTK (I didn't know that JK2 needed a widget set
:), same thing for QT (the widgetery for KDE).
The only portable runtime with more or less the same scope is NSPR, which,
as APR, is built in your application and you will never see it getting down
to /usr/lib...
>>> Also I think the version that comes with Apache2's
>>> binary is to be considered the 'reference' - since Apr
>>> was not released independently, the apache2 package can
>>> be considered as the 'dependency'.
>>
>> We need one mod_jk.so for each version of apache2.
>
> Of course. But mod_jk for Apache1.3 should use the same
> version of APR as mod_jk for Apache2.
>
> And preferably the same binary. Apache1.3 doesn't include
> apr, so we can treat libapr as any other external library
> that a module depends on.
I hope you know what you're talking about....
> Same for IIS - apr.dll from Apache2 is the stable/tested
> version, that's the API we use in jk2 until another stable
> release of apr is available.
You are lucky... Because that's the only case where you could use the same
binary... Since there's no "fork()" in windows, you take away most of the
problems, since basically every server is multi-threaded over there...
> That's my opinion at least - I don't see myself using/supporting
> a system where diferent components use different variation of
> a library. Autoconf is not a deterministic process - especially
> if you use a binary distribution, where the binaries may have been
> built on different machine.
Different components that are going to end up in the same process space,
you'd be damn crazy to use two different things, two different components
having different requirements (apache 1.3 and 2.0) using the same APR
library, you'd be completely crazy to use the same binary...
My 2c after 1+1/2 years of experience with APR in _several_ projects...
Pier
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: mod_jk2 (native2) autoconf preliminary works
Posted by co...@covalent.net.
On Tue, 7 May 2002, jean-frederic clere wrote:
> > APR libs should/could be installed in /usr/lib, /usr/include,
> > and considered 'system' ( like glib, qt, nspr, etc ).
> > If you build a non-threaded version, it shouldn't be
> > called libapr.so in any case.
>
> But we have to deliver the apr.so corresponding to mod_jk.so.
>
> Pier is right... That is more easy to link apr staticly to mod_jk. Having to
> deliver 2 files instead 1 will only bring more problems.
If you use Apache2 with mod_jk.so, then you _have_ a version of
libapr.so. Having 2 variations of the apr code will bring more problems.
If you don't use Apache2, jk2 will require you install a
libapr.so - the same version that is shiped/taged with Apache2.
First, you may install apache2 later :-)
And second, that's the only stable/tested/deterministic
version of APR that exist. If APR1.0 is released in the meantime,
we'll have to decide what to do, but I hope an Apache2.1 will
be released at that time too.
If we would use Glib/Qt/NSPR - we would use the same mechanism,
you would install one of those libarary ( each having one common
goal with APR - of shielding you against OS-specific code ).
> > Also I think the version that comes with Apache2's
> > binary is to be considered the 'reference' - since Apr
> > was not released independently, the apache2 package can
> > be considered as the 'dependency'.
>
> We need one mod_jk.so for each version of apache2.
Of course. But mod_jk for Apache1.3 should use the same
version of APR as mod_jk for Apache2.
And preferably the same binary. Apache1.3 doesn't include
apr, so we can treat libapr as any other external library
that a module depends on.
Same for IIS - apr.dll from Apache2 is the stable/tested
version, that's the API we use in jk2 until another stable
release of apr is available.
It may be tough to require IIS users to install Apache2,
since apr.dll is not distributed separately ( but I can live
with that :-). So we may have to include apr.dll and the
headers in the jk distribution for IIS.
That's my opinion at least - I don't see myself using/supporting
a system where diferent components use different variation of
a library. Autoconf is not a deterministic process - especially
if you use a binary distribution, where the binaries may have been
built on different machine.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: mod_jk2 (native2) autoconf preliminary works
Posted by jean-frederic clere <jf...@fujitsu-siemens.com>.
costinm@covalent.net wrote:
> On Tue, 7 May 2002, jean-frederic clere wrote:
>
>
>>>1) What about moving scripts from jk/native to
>>> just jk ? It avoid duplicate between native
>>> and native2.
>>
>>That may bring problems: the configure.in normaly contains the files you want to
>>generate.
>
>
> IMHO autoconf is justified only for jk2/apache1.3 ( eventually ).
> But if we decide to use it for apache2 and jni - then probably
> that may be a good idea.
>
>
>
>>>2) What should be done for APR in Apache 1.3 ?
>>> Should we use external shared apr lib ?
>>
>>That is probably the best.
>
>
> Building mod_jk without APR is another option here.
> ( i.e. only with socket and what was in jk1 ).
>
> If we use apr, I think ( a bit strongly ) that
> we should use exactly the same library as apache2 does.
>
> APR libs should/could be installed in /usr/lib, /usr/include,
> and considered 'system' ( like glib, qt, nspr, etc ).
> If you build a non-threaded version, it shouldn't be
> called libapr.so in any case.
But we have to deliver the apr.so corresponding to mod_jk.so.
Pier is right... That is more easy to link apr staticly to mod_jk. Having to
deliver 2 files instead 1 will only bring more problems.
>
> Also I think the version that comes with Apache2's
> binary is to be considered the 'reference' - since Apr
> was not released independently, the apache2 package can
> be considered as the 'dependency'.
We need one mod_jk.so for each version of apache2.
>
>
>
>>> Should we use static build apr (like does webapp) ?
>>> In all case should the apr for 1.3 must be with
>>> or without pthread ?
>>
>
> Static apr may be a workaround, but I would avoid that if
> possible. libapr.so should be a 'deterministic' entity,
> if someone has a problem we should know he uses a certain
> version.
>
>
>>>4) What about jni support ?
>>>
>>
>>Costin is the one that knows.
>
>
> It should use libapr.so, the one from Apache2 preferably.
> libjkjni.so should be generated - it won't be used from
> apache, but from java, and the same version of libjkjni
> can be used with any server ( apacheX, iis, etc ).
>
> In other words - you only compile libjkjni with Apache2
> and APR, that's what java will use in all cases.
>
> Costin
>
>
> --
> 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: mod_jk2 (native2) autoconf preliminary works
Posted by co...@covalent.net.
On Tue, 7 May 2002, Pier Fumagalli wrote:
> > We either don't use APR, or use the APR that is included with Apache2.0.
>
> So, you'd better not going to use APR at all, because if you're building a
> module for Apache 1.3, and you link against an APR who has been compiled for
> an Apache 2.0 server with the Worker MPM, you're down in troubles...
Not sure why you think so.
I can link my module against NSPR or Glib or any other library - what's
different for APR ? The only problem is the pthread, but that can be
resolved ( or it seems so ).
Apache13 shouldn't treat APR in any special way - AFAIK there are no
name conflicts, so the code should work just fine.
Again, jk uses various interfaces and implementing jk_pool using apache13
pools would be probably good - but using apr pools should work fine too.
> > For our purpose, that's the only 'stable' APR we can refer to, otherwise
> > we'll be in a maintainance nightmare where everyone will have his
> > own version/variation of APR.
>
> The "stable" version of APR are _there_... The "stable" version of APR are
> all in CVS, and all carry a tag... Simply because noone ever rolled a source
> tarball, that doesn't mean that you can't identify what's stable or not...
"Stable", "tested", "released".
A tag in CVS doesn't mean any of those.
That's beside the point - Apache2.0 includes a particular version of
APR, and that's the target until a new release of apache or APR.
> Do _you_ know how DYLD loading works? You can have 2 same exact libraries
> called libapr.so and (if your ld.so is not broken) have them to coexist
> easily on the same system. That's WHY you don't want to have libapr.so in
> /usr/lib, but rather bundled with your application, because if you put it as
> a shared library inside some standard OS-location directory, and that's not
> the right one you want, you're screwed...
>
> Why do you think all those suckers using APR are embedding it into their
> distros? Just because there's not an "official" tarball that will install
> itself in /usr/lib? NO, because _THAT_ is the _WRONG_ approach....
If this is right ( and I don't think it is ), then something is pretty
broken with APR.
A library that requires you statically link your application with
is at least strange.
Even if you can have 2 .so libraries and have them loaded on the
same system - one some OSes and with special tricks - that doesn't
mean you should do that by default.
DLL hell would look like a nice place compared with that.
If someone would load Apache2, jk2 and webapp - he will have
3 different versions of apr in that process ( or maybe more
if other modules would use APR ) ?
> > The version that was shiped with Apache2.0 is stable and I think
> > that's what we should use with jk2.
>
> You talking about binaries or sources? On sources I agree, on binaries,
> well, it depends on _what_ you're building...
I'm talking about binaries and sources.
I'm not thinking to support a system that uses 2 versions of a library
at the same time, with different settings ( locking is one scary example).
> > We may have to change our code when Apache2.1 is released -
> > but coding against one API in jk2 ( i.e. APR-head ) and using
> > it with Apache2 ( with another APR API ) is looking for trouble.
>
> Err, ehemm... That clearly _shows_ that you don't know what's going on in
> APR land :) APIs are changing, right, but don't worry because some of the
> APIs that were shipped with the current 2.0.35 won't even be there in 2.0.40
> or something like that...
Well, I'm not going to claim that I am an expert - I believe showing some
modesty is quite important. And I try to avoid saying about other people
that they don't have a clue, regardless of how tempting that is.
Costin
> There are stuff which are being "deprecated" and everyone who has a clue
> knows they shouldn't be using them... They're there just because of some
> legacy code that hasn't been backported yet... An APR 1.0 is close, but if
> you want to be so "rigid" about what the runtime provides you well, then
> just go off and don't even think about using it until it's not 1.0 final and
> out-of-the-friggin' door... :)
>
> > The idea that you can release a product without some
> > parts still changing is crazy. I understand Apache2's APR
> > is not called APR1.0 because people don't want to support
> > that particular API in future - but we can't ship
> > jk2 with dependencies on APR-head ( whatever that is ).
>
> Apache 2.0.36 is shipped in GA on a library which is still changing (and
> look, it's approximately 50% of its code)... But goddamit that's the best
> web server I've seen so far...
> > Even if APR1.0 is released, we should use it only when
> > a stable release of Apache2.x with APR1.0 is made.
>
> Ok, I'd give it another 6 months... Why then did you kids just included it
> in JK? You must be loving throwing away man/hours :) :) :)
> >>> Static apr may be a workaround, but I would avoid that if
> >>> possible. libapr.so should be a 'deterministic' entity,
> >>> if someone has a problem we should know he uses a certain
> >>> version.
> >>
> >> I believe that the dynamic build of libapr is better if you have plugins
> >> that your code needs to read: when you compile those, you link them against
> >> a library, rather than to a binary (which you can't easily do anyway)...
> >
> > I believe the main benefit of using shared libraries is not saving
> > memory, but having consistency - the same code will be used in
> > Apache2 and jk2. You can't get into a situation when Apache2 is
> > locking in one way, and jk2 in another way.
>
> _IF_ JK is _BUILT_ for Apache 2.0... If you're building JK for Apache 1.3
> you CAN'T SIMPLY USE THE SAME .so....
>
> Pier
>
>
> --
> 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: mod_jk2 (native2) autoconf preliminary works
Posted by Pier Fumagalli <pi...@betaversion.org>.
"costinm@covalent.net" <co...@covalent.net> wrote:
> On Tue, 7 May 2002, Pier Fumagalli wrote:
>
>> "costinm@covalent.net" <co...@covalent.net> wrote:
>>
>>> If we use apr, I think ( a bit strongly ) that
>>> we should use exactly the same library as apache2 does.
>>
>> If that's provided with Apache 2.0... What if it's not provided with the
>> web-server (AKA, apache 1.3?)
>
> We either don't use APR, or use the APR that is included with Apache2.0.
So, you'd better not going to use APR at all, because if you're building a
module for Apache 1.3, and you link against an APR who has been compiled for
an Apache 2.0 server with the Worker MPM, you're down in troubles...
> For our purpose, that's the only 'stable' APR we can refer to, otherwise
> we'll be in a maintainance nightmare where everyone will have his
> own version/variation of APR.
The "stable" version of APR are _there_... The "stable" version of APR are
all in CVS, and all carry a tag... Simply because noone ever rolled a source
tarball, that doesn't mean that you can't identify what's stable or not...
> But not using APR with Apache1.3 is another choice - using 'native'
> apache1.3 pools for example instead of APR pools, native apache1.3
> maps, etc will be even slightly better ( and using the same code
> as jk1 will be good too )
That's a choice I can't make, but as I don't consider myself as a JK
committer, I'm not going to comment...
I'm just pointing out that if you want to use APR, there is one "easy" way
to do it (probably the "right" way to do it), and several other more
difficult (and probably some even "wrong")... Just consider the fact that
it's more than 1 year that I'm using that code, and I know every single line
of C code that is in that repository....
>>> APR libs should/could be installed in /usr/lib, /usr/include,
>>> and considered 'system' ( like glib, qt, nspr, etc ).
>>> If you build a non-threaded version, it shouldn't be
>>> called libapr.so in any case.
>>
>> I strongly disagree with that, considering the bazillion of options that you
>> have in building APR, and the different features that the library _can_
>> support (but doesn't all times)...
>>
>> Even when building Apache 2.0 the APR library is built differently depending
>> on _how_ you build your Apache 2.0...
>
> Yes - that's the main reason for using a single libapr.so.
>
> If you have 2 programs using different libapr.so, say with different
> locking mechanisms - they'll not work togheter, each will use
> a different lock.
Do _you_ know how DYLD loading works? You can have 2 same exact libraries
called libapr.so and (if your ld.so is not broken) have them to coexist
easily on the same system. That's WHY you don't want to have libapr.so in
/usr/lib, but rather bundled with your application, because if you put it as
a shared library inside some standard OS-location directory, and that's not
the right one you want, you're screwed...
Why do you think all those suckers using APR are embedding it into their
distros? Just because there's not an "official" tarball that will install
itself in /usr/lib? NO, because _THAT_ is the _WRONG_ approach....
>> It has never been released indipendently because of the API changes that
>> (are still) going on to some extent... Look at the APR_ATOMICS, or the
>> locking which got completely rewritten few months ago...
>
> The version that was shiped with Apache2.0 is stable and I think
> that's what we should use with jk2.
You talking about binaries or sources? On sources I agree, on binaries,
well, it depends on _what_ you're building...
> We may have to change our code when Apache2.1 is released -
> but coding against one API in jk2 ( i.e. APR-head ) and using
> it with Apache2 ( with another APR API ) is looking for trouble.
Err, ehemm... That clearly _shows_ that you don't know what's going on in
APR land :) APIs are changing, right, but don't worry because some of the
APIs that were shipped with the current 2.0.35 won't even be there in 2.0.40
or something like that...
There are stuff which are being "deprecated" and everyone who has a clue
knows they shouldn't be using them... They're there just because of some
legacy code that hasn't been backported yet... An APR 1.0 is close, but if
you want to be so "rigid" about what the runtime provides you well, then
just go off and don't even think about using it until it's not 1.0 final and
out-of-the-friggin' door... :)
> The idea that you can release a product without some
> parts still changing is crazy. I understand Apache2's APR
> is not called APR1.0 because people don't want to support
> that particular API in future - but we can't ship
> jk2 with dependencies on APR-head ( whatever that is ).
Apache 2.0.36 is shipped in GA on a library which is still changing (and
look, it's approximately 50% of its code)... But goddamit that's the best
web server I've seen so far...
> Even if APR1.0 is released, we should use it only when
> a stable release of Apache2.x with APR1.0 is made.
Ok, I'd give it another 6 months... Why then did you kids just included it
in JK? You must be loving throwing away man/hours :) :) :)
>>> Static apr may be a workaround, but I would avoid that if
>>> possible. libapr.so should be a 'deterministic' entity,
>>> if someone has a problem we should know he uses a certain
>>> version.
>>
>> I believe that the dynamic build of libapr is better if you have plugins
>> that your code needs to read: when you compile those, you link them against
>> a library, rather than to a binary (which you can't easily do anyway)...
>
> I believe the main benefit of using shared libraries is not saving
> memory, but having consistency - the same code will be used in
> Apache2 and jk2. You can't get into a situation when Apache2 is
> locking in one way, and jk2 in another way.
_IF_ JK is _BUILT_ for Apache 2.0... If you're building JK for Apache 1.3
you CAN'T SIMPLY USE THE SAME .so....
Pier
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: mod_jk2 (native2) autoconf preliminary works
Posted by co...@covalent.net.
On Tue, 7 May 2002, Pier Fumagalli wrote:
> "costinm@covalent.net" <co...@covalent.net> wrote:
>
> > If we use apr, I think ( a bit strongly ) that
> > we should use exactly the same library as apache2 does.
>
> If that's provided with Apache 2.0... What if it's not provided with the
> web-server (AKA, apache 1.3?)
We either don't use APR, or use the APR that is included with Apache2.0.
For our purpose, that's the only 'stable' APR we can refer to, otherwise
we'll be in a maintainance nightmare where everyone will have his
own version/variation of APR.
But not using APR with Apache1.3 is another choice - using 'native'
apache1.3 pools for example instead of APR pools, native apache1.3
maps, etc will be even slightly better ( and using the same code
as jk1 will be good too )
> > APR libs should/could be installed in /usr/lib, /usr/include,
> > and considered 'system' ( like glib, qt, nspr, etc ).
> > If you build a non-threaded version, it shouldn't be
> > called libapr.so in any case.
>
> I strongly disagree with that, considering the bazillion of options that you
> have in building APR, and the different features that the library _can_
> support (but doesn't all times)...
>
> Even when building Apache 2.0 the APR library is built differently depending
> on _how_ you build your Apache 2.0...
Yes - that's the main reason for using a single libapr.so.
If you have 2 programs using different libapr.so, say with different
locking mechanisms - they'll not work togheter, each will use
a different lock.
> It has never been released indipendently because of the API changes that
> (are still) going on to some extent... Look at the APR_ATOMICS, or the
> locking which got completely rewritten few months ago...
The version that was shiped with Apache2.0 is stable and I think
that's what we should use with jk2.
We may have to change our code when Apache2.1 is released -
but coding against one API in jk2 ( i.e. APR-head ) and using
it with Apache2 ( with another APR API ) is looking for trouble.
The idea that you can release a product without some
parts still changing is crazy. I understand Apache2's APR
is not called APR1.0 because people don't want to support
that particular API in future - but we can't ship
jk2 with dependencies on APR-head ( whatever that is ).
Even if APR1.0 is released, we should use it only when
a stable release of Apache2.x with APR1.0 is made.
> > Static apr may be a workaround, but I would avoid that if
> > possible. libapr.so should be a 'deterministic' entity,
> > if someone has a problem we should know he uses a certain
> > version.
>
> I believe that the dynamic build of libapr is better if you have plugins
> that your code needs to read: when you compile those, you link them against
> a library, rather than to a binary (which you can't easily do anyway)...
I believe the main benefit of using shared libraries is not saving
memory, but having consistency - the same code will be used in
Apache2 and jk2. You can't get into a situation when Apache2 is
locking in one way, and jk2 in another way.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: mod_jk2 (native2) autoconf preliminary works
Posted by Pier Fumagalli <pi...@betaversion.org>.
"costinm@covalent.net" <co...@covalent.net> wrote:
> If we use apr, I think ( a bit strongly ) that
> we should use exactly the same library as apache2 does.
If that's provided with Apache 2.0... What if it's not provided with the
web-server (AKA, apache 1.3?)
> APR libs should/could be installed in /usr/lib, /usr/include,
> and considered 'system' ( like glib, qt, nspr, etc ).
> If you build a non-threaded version, it shouldn't be
> called libapr.so in any case.
I strongly disagree with that, considering the bazillion of options that you
have in building APR, and the different features that the library _can_
support (but doesn't all times)...
Even when building Apache 2.0 the APR library is built differently depending
on _how_ you build your Apache 2.0...
Consider that all other projects using them are building APR in their
sources as Apache 2.0 and WebApp does (namely, SubVersion and in the future
PostGreSQL)...
> Also I think the version that comes with Apache2's
> binary is to be considered the 'reference' - since Apr
> was not released independently, the apache2 package can
> be considered as the 'dependency'.
It has never been released indipendently because of the API changes that
(are still) going on to some extent... Look at the APR_ATOMICS, or the
locking which got completely rewritten few months ago...
>>> Should we use static build apr (like does webapp) ?
>>> In all case should the apr for 1.3 must be with
>>> or without pthread ?
>
> Static apr may be a workaround, but I would avoid that if
> possible. libapr.so should be a 'deterministic' entity,
> if someone has a problem we should know he uses a certain
> version.
I believe that the dynamic build of libapr is better if you have plugins
that your code needs to read: when you compile those, you link them against
a library, rather than to a binary (which you can't easily do anyway)...
Pier
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: mod_jk2 (native2) autoconf preliminary works
Posted by co...@covalent.net.
On Tue, 7 May 2002, jean-frederic clere wrote:
> > 1) What about moving scripts from jk/native to
> > just jk ? It avoid duplicate between native
> > and native2.
>
> That may bring problems: the configure.in normaly contains the files you want to
> generate.
IMHO autoconf is justified only for jk2/apache1.3 ( eventually ).
But if we decide to use it for apache2 and jni - then probably
that may be a good idea.
> > 2) What should be done for APR in Apache 1.3 ?
> > Should we use external shared apr lib ?
>
> That is probably the best.
Building mod_jk without APR is another option here.
( i.e. only with socket and what was in jk1 ).
If we use apr, I think ( a bit strongly ) that
we should use exactly the same library as apache2 does.
APR libs should/could be installed in /usr/lib, /usr/include,
and considered 'system' ( like glib, qt, nspr, etc ).
If you build a non-threaded version, it shouldn't be
called libapr.so in any case.
Also I think the version that comes with Apache2's
binary is to be considered the 'reference' - since Apr
was not released independently, the apache2 package can
be considered as the 'dependency'.
> > Should we use static build apr (like does webapp) ?
> > In all case should the apr for 1.3 must be with
> > or without pthread ?
Static apr may be a workaround, but I would avoid that if
possible. libapr.so should be a 'deterministic' entity,
if someone has a problem we should know he uses a certain
version.
> > 4) What about jni support ?
> >
>
> Costin is the one that knows.
It should use libapr.so, the one from Apache2 preferably.
libjkjni.so should be generated - it won't be used from
apache, but from java, and the same version of libjkjni
can be used with any server ( apacheX, iis, etc ).
In other words - you only compile libjkjni with Apache2
and APR, that's what java will use in all cases.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: mod_jk2 (native2) autoconf preliminary works
Posted by Pier Fumagalli <pi...@betaversion.org>.
"jean-frederic clere" <jf...@fujitsu-siemens.com> wrote:
> GOMEZ Henri wrote:
>> I started to works on adding autoconf stuff for
>> mod_jk2 (native2) for Apache 1.3/2.0 and will need
>> some help and advice since it's not fluent in this
>> area (JF/Pier are jtc specialists).
>>
>> Initial works in on Makefile for apxs.
>>
>> 1) What about moving scripts from jk/native to
>> just jk ? It avoid duplicate between native
>> and native2.
>
> That may bring problems: the configure.in normaly contains the files you want
> to generate.
Every "autoconf" M4 definition file (configure.in) is (should) be tied to
the bone of what it's trying to actually configure... If there's enough
stuff in common (like all you want is something like
--enable-native=[native/native2]) that could work, but otherwise, it's just
going to mess stuff around.
If you see (for example) what I did for WebApp, the whole configure.in has a
common part (top and bottom) but all decisional steps are dependant on the
APXS we find (and we're lucky since we only deal with APXS, not with all the
issues you might find when building stuff with a generic compiler and such).
>> 2) What should be done for APR in Apache 1.3 ?
>> Should we use external shared apr lib ?
>
> That is probably the best.
I disagree... APR is not a "shared library" like (for example) the "C"
library, or the "ZLIB" library. It's a runtime, therefore each time you
build it, you can have (or not) support for certain features and so on.
Linking dynamically to such a library is (IMO) wrong unless you do it in a
conservative way (like Apache 2.0 does, placing it in your Apache 2.0
distribution tree). I don't think we'll ever see a /usr/lib/libapr.so-x.x.x
(and _THAT_ would create some problems)
>> Should we use static build apr (like does webapp) ?
>> In all case should the apr for 1.3 must be with
>> or without pthread ?
Therefore, why linking it dynamically? Just to have the extra overhead of
referencing function pointers all the time? Do it static and compile it in,
rely on the dynamic one only if your web server provides it for you (in that
case it's because DSO modules are easier to link against a shared library
than against an executable binary)....
> 1.3 needs threads on win32 at least.
On Win32 and Netware (that's it)... But AFAIK those should be different
makefiles.
>> 4) What about jni support ?
>
> Costin is the one that knows.
Remember that on Darwin it's JNI_CreateJavaVM_Impl()... :)
Pier
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: mod_jk2 (native2) autoconf preliminary works
Posted by jean-frederic clere <jf...@fujitsu-siemens.com>.
GOMEZ Henri wrote:
> I started to works on adding autoconf stuff for
> mod_jk2 (native2) for Apache 1.3/2.0 and will need
> some help and advice since it's not fluent in this
> area (JF/Pier are jtc specialists).
>
> Initial works in on Makefile for apxs.
>
> 1) What about moving scripts from jk/native to
> just jk ? It avoid duplicate between native
> and native2.
That may bring problems: the configure.in normaly contains the files you want to
generate.
>
> 2) What should be done for APR in Apache 1.3 ?
> Should we use external shared apr lib ?
That is probably the best.
> Should we use static build apr (like does webapp) ?
> In all case should the apr for 1.3 must be with
> or without pthread ?
1.3 needs threads on win32 at least.
>
> 3) Who could take a look at Makefile I'll commit for
> static mod_jk2 built ?
I will try.
>
> 4) What about jni support ?
>
Costin is the one that knows.
>
> -
> 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: mod_jk2 (native2) autoconf preliminary works
Posted by co...@covalent.net.
Henri,
I must say I don't like autoconf too much :-)
There are few reasons for that, one beeing that I
prefer to have control over what's compiled ( we want
to distribute the binary to work on any machine, I want
minimal deps on the build machine ).
But I know many people find it easier, so I won't opose
this.
At the moment the compilation of jk2 is controlled by
4-5 'defines', easy to include in a build.properties
( which is used by both Ant-based and Makefile-based
builds ). In addition, for Apache2's mod_jk2 we don't
need autoconf - in fact I'm pretty convinced we shouldn't
use it.
Assume you install an apache2 binary, compiled with a certain
type of locking, shm, etc ( the stuff that is detected/selected
at compile time on the build machine ). It can be very bad
if mod_jk2 detects/selects different options, strange bugs
will happen. And it's a waste of time, the information is
already available in the build/ dir of apache2.
Please try first the Makefile in jk/native2. If it doesn't
fit your needs, I'm ok with an autoconf.
Also, for building jni you can use the Makefile in jni/,
it requires an apache2 binary to be installed ( or built )
before - to get the libapr.so and includes.
IMHO apr should be used for all system-dependent stuff,
we shouldn't have to autoconf.
As a secondary note, if anyone has some time we should
look at sourceforge's ant-contrib and their CC task and
eventually merge jkant into it, we shouldn't duplicate
the effort.
Costin
On Tue, 7 May 2002, GOMEZ Henri wrote:
> I started to works on adding autoconf stuff for
> mod_jk2 (native2) for Apache 1.3/2.0 and will need
> some help and advice since it's not fluent in this
> area (JF/Pier are jtc specialists).
>
> Initial works in on Makefile for apxs.
>
> 1) What about moving scripts from jk/native to
> just jk ? It avoid duplicate between native
> and native2.
>
> 2) What should be done for APR in Apache 1.3 ?
> Should we use external shared apr lib ?
> Should we use static build apr (like does webapp) ?
> In all case should the apr for 1.3 must be with
> or without pthread ?
>
> 3) Who could take a look at Makefile I'll commit for
> static mod_jk2 built ?
>
> 4) What about jni support ?
>
>
> -
> 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>