Mladen Turk wrote:
Costin Manolache wrote:
There are few issues and questions, I'm not sure its as simple as it
looks
:-)
For new development - are you going to make changes in both branches ? I
assume there will be
features that can only be done in 1.3.
Right.
1.1.x will be in bug fixing
+1
2008/10/3 Mladen Turk [EMAIL PROTECTED]:
Hi,
I'd like to create a branch of connectors
for native component so it depends on the
new APR 1.3.x API
The new API offers some essential features targeted
explicitly for pool issues usage in
high level languages like Java.
So, my idea is to
Mladen Turk wrote:
Hi,
I'd like to create a branch of connectors
for native component so it depends on the
new APR 1.3.x API
The new API offers some essential features targeted
explicitly for pool issues usage in
high level languages like Java.
So, my idea is to branch the current
On Fri, Oct 3, 2008 at 1:56 AM, Mladen Turk [EMAIL PROTECTED] wrote:
Hi,
I'd like to create a branch of connectors
for native component so it depends on the
new APR 1.3.x API
+1.
Like Mark, I'm also OK with removal.
Yoav
Mladen Turk schrieb:
Hi,
I'd like to create a branch of connectors
for native component so it depends on the
new APR 1.3.x API
The new API offers some essential features targeted
explicitly for pool issues usage in
high level languages like Java.
So, my idea is to branch the current
On Oct 3, 2008, at 9:33 AM, Yoav Shapira wrote:
On Fri, Oct 3, 2008 at 1:56 AM, Mladen Turk [EMAIL PROTECTED] wrote:
Hi,
I'd like to create a branch of connectors
for native component so it depends on the
new APR 1.3.x API
+1.
Like Mark, I'm also OK with removal.
+1
Rainer Jung wrote:
Mladen Turk schrieb:
The native external is used in the dist.xml build file in order to
include the tcnative sources in the TC src release. So either we need to
adjust this part of TC build process, or simply switch the external for
TC 6.0.x to the 1.1 branch (and keep TC
There are few issues and questions, I'm not sure its as simple as it looks
:-)
For new development - are you going to make changes in both branches ? I
assume there will be
features that can only be done in 1.3.
Also, if we have separate releases of APR - are we going to release binaries
? For
Costin Manolache wrote:
There are few issues and questions, I'm not sure its as simple as it looks
:-)
For new development - are you going to make changes in both branches ? I
assume there will be
features that can only be done in 1.3.
Right.
1.1.x will be in bug fixing mode
Also, if we
On Fri, Oct 3, 2008 at 10:43 AM, Mladen Turk [EMAIL PROTECTED] wrote:
Costin Manolache wrote:
There are few issues and questions, I'm not sure its as simple as it looks
:-)
For new development - are you going to make changes in both branches ? I
assume there will be
features that can only
Costin Manolache wrote:
What is the apr version in common linux distros ?
Depends, Httpd 2.2.something+ relies on APR 1.3. SVN as well,
so eventually distros will pick it up.
Well, that's a bit tricky - people don't upgrade prod servers easily.
My concern is mostly about possibility
Ok, +1.
My remaining question - is it possible to generate a .so file for the JNI
library that includes both APR and JK ( or
2 libraries - in a way that the apr library won't conflict with an older
pre-installed version ) ?
Costin
On Fri, Oct 3, 2008 at 12:12 PM, Mladen Turk [EMAIL PROTECTED]
Hi,
I'd like to create a branch of connectors
for native component so it depends on the
new APR 1.3.x API
The new API offers some essential features targeted
explicitly for pool issues usage in
high level languages like Java.
So, my idea is to branch the current trunk
as
13 matches
Mail list logo
