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]>
