RE: isapi_redirector2 build using static APR

[GOMEZ Henri]

I strongly agree with costin, and it has been a point
we discuss many times before with Pier for mod_webapp.

Even if APR is a library used mainly by Apache 2.0,
nothing prevent it to be used elsewhere and for example
under Windows and IIS.

The only problem is that there is still no official APR,
release, and as such APR came out which each Apache 2.0 
release, that's why you could find APR_APACHE_2... tarballs
in jakarta-tomcat-connectors.

So I'd like to have apr.so or apr.dll for windows, distributed
together with future jk2 (jk didn't need it).

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



>-Original Message-
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
>Sent: Sunday, June 30, 2002 11:15 PM
>To: Tomcat Developers List
>Subject: RE: isapi_redirector2 build using static APR
>
>
>I'm close to -1 on this, but if everyone else is +1 I'll 
>change it to -0.
>
>Apr is a library, just like glib or libc, and I hope soon more 
>modules and 
>programs will use it - including in IIS or other environments. 
>
>I see no problem with having apr.dll - it is actually easier to get it 
>from an Apache installation ( or pre-built whenever they have 
>a release )
>Maybe having the dll around will encourage other uses as well :-)
>
>Costin
>
>On Sun, 30 Jun 2002, Mladen Turk wrote:
>
>> > -Original Message-
>> > From: Ignacio J. Ortega [mailto:[EMAIL PROTECTED]] 
>> > Sent: 30. lipanj 2002 18:45
>> > To: '[EMAIL PROTECTED]'
>> > Subject: RE: isapi_redirector2 build using static APR
>> > 
>> > 
>> > > De: Mladen Turk [mailto:[EMAIL PROTECTED]]
>> > > Enviado el: 30 de junio de 2002 7:28
>> > 
>> > hmmm, this will force us to make a binary everytime Apache2 
>> > has a release too?
>> > 
>> > in this case -1, if not +1
>> >
>> 
>> Only if the APR changes itself (in the API way), but then we have to
>> rebuild it in any case.
>> All the Apache utils itself use the static APR if they don't 
>need to go
>> to the httpd directly.
>> Since we are using apr in the IIS connector only as a common 
>library for
>> things like pools, tables, network io, etc.
>> The only rebuild needed would be in the case of some sort of 
>discovered
>> bug. The apr itself is quite stable, and since we are not building
>> apache module, versioning is not an issue here. Actually 
>we'll be less
>> dependent.
>> 
>> Other benefit will be simply the elimination of things like various
>> libapr.dll's flying around.
>> 
>> 
>> MT.
>> 
>> 
>> --
>> To unsubscribe, e-mail:   
<mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
> 
> 


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


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

RE: isapi_redirector2 build using static APR

[Mladen Turk]

Yes, It might be a problem if we think (and should) that someone else
will use apr to build some other filter or isapi extension using apr
that will coexist in the same process (IIS) with our redirector. In that
case we could have serious initialization problems.

The same problem lies with the assumption that we are the only user of
java vm, cause we cannont start two vm's in the same process, so
currently we cannot have two jvm modules in Apache.

I'll withdraw my proposal, and the only thing that's left is to use the
MD instead of MT build, cause the apr is build using dynamic run-time,
and we are using static, and mixing that can cause problems.
 
MT.

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] 
> Sent: 30. lipanj 2002 23:15
> To: Tomcat Developers List
> Subject: RE: isapi_redirector2 build using static APR
> 
> 
> I'm close to -1 on this, but if everyone else is +1 I'll 
> change it to -0.
> 
> Apr is a library, just like glib or libc, and I hope soon 
> more modules and 
> programs will use it - including in IIS or other environments. 
> 
> I see no problem with having apr.dll - it is actually easier 
> to get it 
> from an Apache installation ( or pre-built whenever they have 
> a release ) Maybe having the dll around will encourage other 
> uses as well :-)
> 
> Costin
> 
> On Sun, 30 Jun 2002, Mladen Turk wrote:
> 
> > > -Original Message-
> > > From: Ignacio J. Ortega [mailto:[EMAIL PROTECTED]]
> > > Sent: 30. lipanj 2002 18:45
> > > To: '[EMAIL PROTECTED]'
> > > Subject: RE: isapi_redirector2 build using static APR
> > > 
> > > 
> > > > De: Mladen Turk [mailto:[EMAIL PROTECTED]]
> > > > Enviado el: 30 de junio de 2002 7:28
> > > 
> > > hmmm, this will force us to make a binary everytime Apache2
> > > has a release too?
> > > 
> > > in this case -1, if not +1
> > >
> > 
> > Only if the APR changes itself (in the API way), but then 
> we have to 
> > rebuild it in any case. All the Apache utils itself use the 
> static APR 
> > if they don't need to go to the httpd directly.
> > Since we are using apr in the IIS connector only as a 
> common library for
> > things like pools, tables, network io, etc.
> > The only rebuild needed would be in the case of some sort 
> of discovered
> > bug. The apr itself is quite stable, and since we are not building
> > apache module, versioning is not an issue here. Actually 
> we'll be less
> > dependent.
> > 
> > Other benefit will be simply the elimination of things like various 
> > libapr.dll's flying around.
> > 
> > 
> > MT.
> > 
> > 
> > --
> > To unsubscribe, e-mail:   
> <mailto:tomcat-dev-> [EMAIL PROTECTED]>
> > For 
> additional commands, 
> e-mail: 
> > <mailto:[EMAIL PROTECTED]>
> > 
> > 
> 
> 
> --
> To unsubscribe, e-mail:   
> <mailto:tomcat-dev-> [EMAIL PROTECTED]>
> For 
> additional commands, 
> e-mail: <mailto:[EMAIL PROTECTED]>
> 
> 
> 


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

RE: isapi_redirector2 build using static APR

[costinm]

I'm close to -1 on this, but if everyone else is +1 I'll change it to -0.

Apr is a library, just like glib or libc, and I hope soon more modules and 
programs will use it - including in IIS or other environments. 

I see no problem with having apr.dll - it is actually easier to get it 
from an Apache installation ( or pre-built whenever they have a release )
Maybe having the dll around will encourage other uses as well :-)

Costin

On Sun, 30 Jun 2002, Mladen Turk wrote:

> > -Original Message-
> > From: Ignacio J. Ortega [mailto:[EMAIL PROTECTED]] 
> > Sent: 30. lipanj 2002 18:45
> > To: '[EMAIL PROTECTED]'
> > Subject: RE: isapi_redirector2 build using static APR
> > 
> > 
> > > De: Mladen Turk [mailto:[EMAIL PROTECTED]]
> > > Enviado el: 30 de junio de 2002 7:28
> > 
> > hmmm, this will force us to make a binary everytime Apache2 
> > has a release too?
> > 
> > in this case -1, if not +1
> >
> 
> Only if the APR changes itself (in the API way), but then we have to
> rebuild it in any case.
> All the Apache utils itself use the static APR if they don't need to go
> to the httpd directly.
> Since we are using apr in the IIS connector only as a common library for
> things like pools, tables, network io, etc.
> The only rebuild needed would be in the case of some sort of discovered
> bug. The apr itself is quite stable, and since we are not building
> apache module, versioning is not an issue here. Actually we'll be less
> dependent.
> 
> Other benefit will be simply the elimination of things like various
> libapr.dll's flying around.
> 
> 
> MT.
> 
> 
> --
> To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
> 
> 


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

RE: isapi_redirector2 build using static APR

[Ignacio J. Ortega]

OK, +1.. i'll do the changes to the isapi build 

Saludos ,
Ignacio J. Ortega

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: isapi_redirector2 build using static APR

[Mladen Turk]

> -Original Message-
> From: Ignacio J. Ortega [mailto:[EMAIL PROTECTED]] 
> Sent: 30. lipanj 2002 18:45
> To: '[EMAIL PROTECTED]'
> Subject: RE: isapi_redirector2 build using static APR
> 
> 
> > De: Mladen Turk [mailto:[EMAIL PROTECTED]]
> > Enviado el: 30 de junio de 2002 7:28
> 
> hmmm, this will force us to make a binary everytime Apache2 
> has a release too?
> 
> in this case -1, if not +1
>

Only if the APR changes itself (in the API way), but then we have to
rebuild it in any case.
All the Apache utils itself use the static APR if they don't need to go
to the httpd directly.
Since we are using apr in the IIS connector only as a common library for
things like pools, tables, network io, etc.
The only rebuild needed would be in the case of some sort of discovered
bug. The apr itself is quite stable, and since we are not building
apache module, versioning is not an issue here. Actually we'll be less
dependent.

Other benefit will be simply the elimination of things like various
libapr.dll's flying around.


MT.


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

RE: isapi_redirector2 build using static APR

[Ignacio J. Ortega]

> De: Mladen Turk [mailto:[EMAIL PROTECTED]]
> Enviado el: 30 de junio de 2002 7:28

hmmm, this will force us to make a binary everytime Apache2 has a
release too?

in this case -1, if not +1

Saludos ,
Ignacio J. Ortega

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: isapi_redirector2 build using static APR

[Kevin Seguin]

> 
> 
> IMO it would be better to build the non Apache connectors using static
> APR builds. That way we don't need to ship the extra dll's with the
> connector.
> The dll builds are ok for mod_jk2 since Apache is already there.
> 

+1 (speaking more as a user than a developer these days ...)

> It would be quite easy to do that adding /D "APR_DECLARE_STATIC" /D
> "APU_DECLARE_STATIC", linking with apr.lib and aprutil.lib instead of
> libapr and libaprutil
> 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: