You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Henri Gomez <hg...@apache.org> on 2003/10/16 10:59:11 UTC
jk2 evolution plan
Ok, about everybody seems to agree on using apr for jk2
(still waiting Nacho for IIS).
APR side will be to :
- Update doc to indicate that APR is mandatory
- Remove #idef APR
- Use APR for all OS operation and sus will save us from
handling all the #include for all the diverses IO operation
(it's really a pain).
- For now still use_jk pool, but the version using apr_tools.
- Make socket use apr_socket for compatibility.
JK to JK2 fonctionnalities backport :
- Check features added in jk and not present in jk2 (ie cping/cpong).
There was also some specific lb workers settings which should be
studied.
- After this works, make a 2.0.4 release and start extensive
testing.
On the channel side I added a new method, hasinput which should help
use determine if there is something to do on 'stream connections'.
For instance, it's used in jk/jk2 by the cping/cpong stage when
connectTimeout, prepostTimeout and replyTimeout are set.
And no the who's who ;)
I'd like to know who could works on jk2 evolution.
BTW, where could we find today the jk/jk2 documentation which is
regenerated each day ?
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: jk2 evolution plan
Posted by Henri Gomez <hg...@apache.org>.
Costin Manolache wrote:
> Henri Gomez wrote:
>
>
>>And no the who's who ;)
>>
>>I'd like to know who could works on jk2 evolution.
>>
>
>
> Until December is very unlikely I'll have any free time.
>
>
> I would like to help with the unix domain channel and JNI - but
> it'll be very limitted... Sorry.
You're more than welcome of course Costin.
The more I look in jk2, the more I like the 'object' oriented
methods of jk2 :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: jk2 evolution plan
Posted by Costin Manolache <cm...@yahoo.com>.
Henri Gomez wrote:
> And no the who's who ;)
>
> I'd like to know who could works on jk2 evolution.
>
Until December is very unlikely I'll have any free time.
I would like to help with the unix domain channel and JNI - but
it'll be very limitted... Sorry.
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: New builds ?
Posted by Remy Maucherat <re...@apache.org>.
David Rees wrote:
> Remy Maucherat wrote:
>
>> David Rees wrote:
>>
>>> I've been using 4.1.29 for development without any issues for a few
>>> days now. Just one minor annoyance, I get this message twice when
>>> starting
>>> Tomcat up: "CoyoteConnector Coyote can't register jmx for protocol"
>>
>>
>> Very good point. I'll tag new 4.1.30 and 5.0.14 builds tomorrow.
>> Hopefully more people will vote next time :)
>
>
> Anyone have any idea on what's causing that message from Coyote to end
> up in the cataline log file?
Well, we switched to Coyote from TC 5, so this adds a requirement on
JMX. Apparently, it does work even if JMX isn't there (I'm a bit surprised).
Remy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: New builds ?
Posted by David Rees <dr...@greenhydrant.com>.
Remy Maucherat wrote:
> David Rees wrote:
>> I've been using 4.1.29 for development without any issues for a few
>> days now. Just one minor annoyance, I get this message twice when
>> starting
>> Tomcat up: "CoyoteConnector Coyote can't register jmx for protocol"
>
> Very good point. I'll tag new 4.1.30 and 5.0.14 builds tomorrow.
> Hopefully more people will vote next time :)
Anyone have any idea on what's causing that message from Coyote to end
up in the cataline log file?
-Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Logs folder not present in 5.0.12 (Was: Re: New builds ?)
Posted by Sriram N <sr...@yahoo.com>.
Remy:
I downloaded 5.0.12 yesterday and tried it on Linux.
I got the following error
touch: creating `/root/jakarta-tomcat-5.0.12/logs/catalina.out': No such file
or directory
/root/jakarta-tomcat-5.0.12/bin/catalina.sh: line 231:
/root/jakarta-tomcat-5.0.12/logs/catalina.out: No such file or directory
I was able to remedy this by creating the "logs" folder myself. Could you fix
this in the next release ?
-- Sriram
--- Remy Maucherat <re...@apache.org> wrote:
> David Rees wrote:
>
> > Remy Maucherat wrote:
> >
> >> So, what do we do with 4.1.28 ? AFAIK, no significant issue has been
> >> found with this build, with minor tweaks being made since then in the
> >> connectors.
> >> Is a 4.1.29 needed, or is it simply people forgot about that build ?
> >>
> >> Comments ?
> >
> >
> > I've been using 4.1.29 for development without any issues for a few days
> > now. Just one minor annoyance, I get this message twice when starting
> > Tomcat up: "CoyoteConnector Coyote can't register jmx for protocol"
> >
> > Now that new versions of commons dbcp and pool have been released,
> > upgrading to the latest may be a good idea and an excuse to retag
> > 4.1.30. I don't think you'll get many testers until it's called beta,
> > though.
> >
> > Other than that, looks good!
>
> Very good point. I'll tag new 4.1.30 and 5.0.14 builds tomorrow.
> Hopefully more people will vote next time :)
>
> R�my
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: New builds ?
Posted by Remy Maucherat <re...@apache.org>.
David Rees wrote:
> Remy Maucherat wrote:
>
>> So, what do we do with 4.1.28 ? AFAIK, no significant issue has been
>> found with this build, with minor tweaks being made since then in the
>> connectors.
>> Is a 4.1.29 needed, or is it simply people forgot about that build ?
>>
>> Comments ?
>
>
> I've been using 4.1.29 for development without any issues for a few days
> now. Just one minor annoyance, I get this message twice when starting
> Tomcat up: "CoyoteConnector Coyote can't register jmx for protocol"
>
> Now that new versions of commons dbcp and pool have been released,
> upgrading to the latest may be a good idea and an excuse to retag
> 4.1.30. I don't think you'll get many testers until it's called beta,
> though.
>
> Other than that, looks good!
Very good point. I'll tag new 4.1.30 and 5.0.14 builds tomorrow.
Hopefully more people will vote next time :)
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: New builds ?
Posted by David Rees <dr...@greenhydrant.com>.
Remy Maucherat wrote:
> So, what do we do with 4.1.28 ? AFAIK, no significant issue has been
> found with this build, with minor tweaks being made since then in the
> connectors.
> Is a 4.1.29 needed, or is it simply people forgot about that build ?
>
> Comments ?
I've been using 4.1.29 for development without any issues for a few days
now. Just one minor annoyance, I get this message twice when starting
Tomcat up: "CoyoteConnector Coyote can't register jmx for protocol"
Now that new versions of commons dbcp and pool have been released,
upgrading to the latest may be a good idea and an excuse to retag
4.1.30. I don't think you'll get many testers until it's called beta,
though.
Other than that, looks good!
-Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: New builds ?
Posted by David Rees <dr...@greenhydrant.com>.
On Fri, October 24, 2003 1at 1:27 am, Remy Maucherat wrote:
> Remy Maucherat wrote:
>>
>> OTOH, there has been a few useful fixes and tweaks since 5.0.13 in the
>> 5.0 branch, so I'll tag a new 5.0.14 at the end of the week (these .13
>> builds are all cursed :-D).
>
> Ok, tomorrow or Sunday :) (I've been a bit sick this week, so I'm slow)
Any word? ;-)
-Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: New builds ?
Posted by Remy Maucherat <re...@apache.org>.
Remy Maucherat wrote:
> So, what do we do with 4.1.28 ? AFAIK, no significant issue has been
> found with this build, with minor tweaks being made since then in the
> connectors.
> Is a 4.1.29 needed, or is it simply people forgot about that build ?
>
> OTOH, there has been a few useful fixes and tweaks since 5.0.13 in the
> 5.0 branch, so I'll tag a new 5.0.14 at the end of the week (these .13
> builds are all cursed :-D).
Ok, tomorrow or Sunday :) (I've been a bit sick this week, so I'm slow)
- 5.0.14 with pool & DBCP 1.1 (and the latest fixes); I'm going to
bundle the JSR 160 RI (the license is the same as the JMX 1.2 RI), and
I'll try to add support for it using a new server listener.
- 4.1.29 also with pool & DBCP 1.1; ideally, I'll have time to add
additional connector attributes (for compression configuration, among
other things).
Remy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
New builds ?
Posted by Remy Maucherat <re...@apache.org>.
So, what do we do with 4.1.28 ? AFAIK, no significant issue has been
found with this build, with minor tweaks being made since then in the
connectors.
Is a 4.1.29 needed, or is it simply people forgot about that build ?
OTOH, there has been a few useful fixes and tweaks since 5.0.13 in the
5.0 branch, so I'll tag a new 5.0.14 at the end of the week (these .13
builds are all cursed :-D).
Comments ?
Remy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
RE: jk2 evolution plan
Posted by Mladen Turk <mt...@apache.org>.
> From: Henri Gomez
>
>
> Mladen Turk wrote:
>
> >
> >>From: Bill Barker
> >>
> >>I could get on-board with this, after Mladen's suggestion to
> >>change the return-type of most methods to jk_status_t.
> >>Without this, mod_jk2 is hopelessly broken (and I'll contunue
> >>to ignore it :).
> >>
> >
> >
> >
> > It's to apr_status_t ;-).
> > Sill, takes a bit more time then I thought It would.
> > Not just to return APR_SUCCESS, but to return the meaningful error
> > codes that can be logged.
> >
> > So day or two...
>
> So it will be apr_status_t ?
>
Yes, It is IMO the most straighforward.
If the APR API call fails the calee will return the same error code,
without the need to reinvent our own error codes.
The jk2 specific error codes will beging from
APR_OS_START_USERERR + 1.
MT.
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: jk2 evolution plan
Posted by Henri Gomez <hg...@apache.org>.
Mladen Turk wrote:
>
>>From: Bill Barker
>>
>>I could get on-board with this, after Mladen's suggestion to
>>change the return-type of most methods to jk_status_t.
>>Without this, mod_jk2 is hopelessly broken (and I'll contunue
>>to ignore it :).
>>
>
>
>
> It's to apr_status_t ;-).
> Sill, takes a bit more time then I thought It would.
> Not just to return APR_SUCCESS, but to return the meaningful
> error codes that can be logged.
>
> So day or two...
So it will be apr_status_t ?
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
RE: jk2 evolution plan
Posted by Mladen Turk <mt...@apache.org>.
> From: Bill Barker
>
> I could get on-board with this, after Mladen's suggestion to
> change the return-type of most methods to jk_status_t.
> Without this, mod_jk2 is hopelessly broken (and I'll contunue
> to ignore it :).
>
It's to apr_status_t ;-).
Sill, takes a bit more time then I thought It would.
Not just to return APR_SUCCESS, but to return the meaningful
error codes that can be logged.
So day or two...
MT.
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: jk2 evolution plan
Posted by Bill Barker <wb...@wilshire.com>.
----- Original Message -----
From: "Henri Gomez" <hg...@apache.org>
To: "Tomcat Developers List" <to...@jakarta.apache.org>
Sent: Monday, October 20, 2003 12:53 AM
Subject: Re: jk2 evolution plan
> Glenn Nielsen wrote:
>
> > +1
> >
> > I can help out.
> >
> > This is a significant change for a minor revision to 2.0.4,
> > perhaps we should bump it to 2.1 or even 3.0?
>
> Since it's an 'internal rewrite', it should stay 2.x, may be
> 2.1 could be the right name
>
> But first we should cleanup all jk2 from #iddef APR defines and
> custom OS includes.
>
I could get on-board with this, after Mladen's suggestion to change the
return-type of most methods to jk_status_t. Without this, mod_jk2 is
hopelessly broken (and I'll contunue to ignore it :).
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
Re: jk2 evolution plan
Posted by Henri Gomez <hg...@apache.org>.
Glenn Nielsen wrote:
> +1
>
> I can help out.
>
> This is a significant change for a minor revision to 2.0.4,
> perhaps we should bump it to 2.1 or even 3.0?
Since it's an 'internal rewrite', it should stay 2.x, may be
2.1 could be the right name
But first we should cleanup all jk2 from #iddef APR defines and
custom OS includes.
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: jk2 evolution plan
Posted by Glenn Nielsen <gl...@more.net>.
+1
I can help out.
This is a significant change for a minor revision to 2.0.4,
perhaps we should bump it to 2.1 or even 3.0?
Glenn
Henri Gomez wrote:
> Ok, about everybody seems to agree on using apr for jk2
> (still waiting Nacho for IIS).
>
> APR side will be to :
>
> - Update doc to indicate that APR is mandatory
>
> - Remove #idef APR
>
> - Use APR for all OS operation and sus will save us from
> handling all the #include for all the diverses IO operation
> (it's really a pain).
>
> - For now still use_jk pool, but the version using apr_tools.
>
> - Make socket use apr_socket for compatibility.
>
>
> JK to JK2 fonctionnalities backport :
>
> - Check features added in jk and not present in jk2 (ie cping/cpong).
> There was also some specific lb workers settings which should be
> studied.
>
> - After this works, make a 2.0.4 release and start extensive
> testing.
>
>
> On the channel side I added a new method, hasinput which should help
> use determine if there is something to do on 'stream connections'.
>
> For instance, it's used in jk/jk2 by the cping/cpong stage when
> connectTimeout, prepostTimeout and replyTimeout are set.
>
>
> And no the who's who ;)
>
> I'd like to know who could works on jk2 evolution.
>
> BTW, where could we find today the jk/jk2 documentation which is
> regenerated each day ?
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: jk2 evolution plan
Posted by Henri Gomez <hg...@apache.org>.
jean-frederic clere wrote:
> Henri Gomez wrote:
>
>>
>>>
>>> Done. The machine where it runs is stable but inside FSC firmwall.
>>
>>
>>
>> Could we copy it somewhere on apache.org to have it mirrored ?
>
>
> I have copied and adapted it to my account in minotaur.
So we'll have an URL available ?
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: jk2 evolution plan
Posted by jean-frederic clere <jf...@fujitsu-siemens.com>.
Henri Gomez wrote:
>
>>
>> Done. The machine where it runs is stable but inside FSC firmwall.
>
>
> Could we copy it somewhere on apache.org to have it mirrored ?
I have copied and adapted it to my account in minotaur.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: jk2 evolution plan
Posted by Henri Gomez <hg...@apache.org>.
>
> Done. The machine where it runs is stable but inside FSC firmwall.
Could we copy it somewhere on apache.org to have it mirrored ?
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: jk2 evolution plan
Posted by jean-frederic clere <jf...@fujitsu-siemens.com>.
Henri Gomez wrote:
> jean-frederic clere wrote:
>
>> Henri Gomez wrote:
>>
>>> Ok, about everybody seems to agree on using apr for jk2
>>> (still waiting Nacho for IIS).
>>>
>>> APR side will be to :
>>>
>>> - Update doc to indicate that APR is mandatory
>>>
>>> - Remove #idef APR
>>>
>>> - Use APR for all OS operation and sus will save us from
>>> handling all the #include for all the diverses IO operation
>>> (it's really a pain).
>>>
>>> - For now still use_jk pool, but the version using apr_tools.
>>>
>>> - Make socket use apr_socket for compatibility.
>>>
>>>
>>> JK to JK2 fonctionnalities backport :
>>>
>>> - Check features added in jk and not present in jk2 (ie cping/cpong).
>>> There was also some specific lb workers settings which should be
>>> studied.
>>>
>>> - After this works, make a 2.0.4 release and start extensive
>>> testing.
>>>
>>>
>>> On the channel side I added a new method, hasinput which should help
>>> use determine if there is something to do on 'stream connections'.
>>>
>>> For instance, it's used in jk/jk2 by the cping/cpong stage when
>>> connectTimeout, prepostTimeout and replyTimeout are set.
>>>
>>>
>>> And no the who's who ;)
>>>
>>> I'd like to know who could works on jk2 evolution.
>>>
>>> BTW, where could we find today the jk/jk2 documentation which is
>>> regenerated each day ?
>>
>>
>>
>> I used to generate it every night but I have stopped doing the
>> generation.
>> Should I activate my cronjob again?
>
>
> Yes please, but we should find a stable place (where ?)
Done. The machine where it runs is stable but inside FSC firmwall.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: jk2 evolution plan
Posted by Henri Gomez <hg...@apache.org>.
jean-frederic clere wrote:
> Henri Gomez wrote:
>
>> Ok, about everybody seems to agree on using apr for jk2
>> (still waiting Nacho for IIS).
>>
>> APR side will be to :
>>
>> - Update doc to indicate that APR is mandatory
>>
>> - Remove #idef APR
>>
>> - Use APR for all OS operation and sus will save us from
>> handling all the #include for all the diverses IO operation
>> (it's really a pain).
>>
>> - For now still use_jk pool, but the version using apr_tools.
>>
>> - Make socket use apr_socket for compatibility.
>>
>>
>> JK to JK2 fonctionnalities backport :
>>
>> - Check features added in jk and not present in jk2 (ie cping/cpong).
>> There was also some specific lb workers settings which should be
>> studied.
>>
>> - After this works, make a 2.0.4 release and start extensive
>> testing.
>>
>>
>> On the channel side I added a new method, hasinput which should help
>> use determine if there is something to do on 'stream connections'.
>>
>> For instance, it's used in jk/jk2 by the cping/cpong stage when
>> connectTimeout, prepostTimeout and replyTimeout are set.
>>
>>
>> And no the who's who ;)
>>
>> I'd like to know who could works on jk2 evolution.
>>
>> BTW, where could we find today the jk/jk2 documentation which is
>> regenerated each day ?
>
>
> I used to generate it every night but I have stopped doing the generation.
> Should I activate my cronjob again?
Yes please, but we should find a stable place (where ?)
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: jk2 evolution plan
Posted by jean-frederic clere <jf...@fujitsu-siemens.com>.
Henri Gomez wrote:
> Ok, about everybody seems to agree on using apr for jk2
> (still waiting Nacho for IIS).
>
> APR side will be to :
>
> - Update doc to indicate that APR is mandatory
>
> - Remove #idef APR
>
> - Use APR for all OS operation and sus will save us from
> handling all the #include for all the diverses IO operation
> (it's really a pain).
>
> - For now still use_jk pool, but the version using apr_tools.
>
> - Make socket use apr_socket for compatibility.
>
>
> JK to JK2 fonctionnalities backport :
>
> - Check features added in jk and not present in jk2 (ie cping/cpong).
> There was also some specific lb workers settings which should be
> studied.
>
> - After this works, make a 2.0.4 release and start extensive
> testing.
>
>
> On the channel side I added a new method, hasinput which should help
> use determine if there is something to do on 'stream connections'.
>
> For instance, it's used in jk/jk2 by the cping/cpong stage when
> connectTimeout, prepostTimeout and replyTimeout are set.
>
>
> And no the who's who ;)
>
> I'd like to know who could works on jk2 evolution.
>
> BTW, where could we find today the jk/jk2 documentation which is
> regenerated each day ?
I used to generate it every night but I have stopped doing the generation.
Should I activate my cronjob again?
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: jk2 evolution plan
Posted by Henri Gomez <hg...@apache.org>.
Mladen Turk wrote:
>
>>-----Original Message-----
>>From: Henri Gomez
>>
>>You should know what apr call should be used to mimic select
>>isn't it ?
>>
>
>
> PING/PONG right?
>
> Nothing that simple :-).
>
> The magick is apr_poll.
> It will require some modifications to the channel in general.
hasinput method has been created ;)
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
RE: jk2 evolution plan
Posted by Mladen Turk <mt...@apache.org>.
> -----Original Message-----
> From: Henri Gomez
>
> You should know what apr call should be used to mimic select
> isn't it ?
>
PING/PONG right?
Nothing that simple :-).
The magick is apr_poll.
It will require some modifications to the channel in general.
MT.
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: jk2 evolution plan
Posted by Henri Gomez <hg...@apache.org>.
Mladen Turk wrote:
>
>>-----Original Message-----
>>From: Henri Gomez
>>
>>>>I'd like to know who could works on jk2 evolution.
>>>>
>>>
>>>
>>>+1
>>
>>Thanks.
>>
>
>
> I can (not before friday):
> 1. Change all the (quasi boolean) functions to return the apr_status_t
> instead int (0, 1)
> 2. aprize jk2_log to use the apr_file_t
> 3. aprize mutex and pool.
Ok,
You should know what apr call should be used to mimic select isn't it ?
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
jk2/tc4/jkstatus problems ;(
Posted by Henri Gomez <hg...@apache.org>.
Hi
I could get jkstatus via :
http://mysystem/jkstatus/
But it failed to find
http://mysystem/jkstatus/jkstatus?cfgOrig=1
http://mysystem/jkstatus/jkstatus?cfgParsed=1
http://mysystem/jkstatus/jkstatus?scoreboard=1
My original conf was :
[status:]
info=Status worker, displays runtime informations
[uri:/jkstatus/*]
info=Display status information and checks the config file for changes.
group=status:
debug=10
I add to add the following in workers2.properties to make it works :
[uri:/jkstatus/jkstatus]
info=Display status information and checks the config file for changes.
group=status:
debug=10
BTW, I could'nt get access from TC 4.1.x since this one call :
http://mysystem:80/jkstatus?lst=*
http://mysystem:80/jkstatus?dmp=*
What's the problem ?
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
RE: jk2 evolution plan
Posted by Mladen Turk <mt...@apache.org>.
> -----Original Message-----
> From: Henri Gomez
> >>
> >>I'd like to know who could works on jk2 evolution.
> >>
> >
> >
> > +1
>
> Thanks.
>
I can (not before friday):
1. Change all the (quasi boolean) functions to return the apr_status_t
instead int (0, 1)
2. aprize jk2_log to use the apr_file_t
3. aprize mutex and pool.
MT.
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: jk2 evolution plan
Posted by Henri Gomez <hg...@apache.org>.
Mladen Turk wrote:
>
>>-----Original Message-----
>>From: Henri Gomez
>>
>>Ok, about everybody seems to agree on using apr for jk2
>>(still waiting Nacho for IIS).
>>
>
>
> IIS uses APR by default (staticaly linked) for a long time.
>
>
>
>>APR side will be to :
>>
>>- Update doc to indicate that APR is mandatory
>>
>>- Remove #idef APR
>>
>>- Use APR for all OS operation and sus will save us from
>> handling all the #include for all the diverses IO operation
>> (it's really a pain).
>>
>>- For now still use_jk pool, but the version using apr_tools.
>>
>
>
>
>
>>- Make socket use apr_socket for compatibility.
>>
>
>
> Why?
> Just rename
> env->registerFactory( env, "channel.socket",
> jk2_channel_socket_factory );
> to
> env->registerFactory( env,
> "channel.socket",jk2_channel_apr_socket_factory );
>
> and drop the socket channel.
Exactly ...
>
>
>
>>And no the who's who ;)
>>
>>I'd like to know who could works on jk2 evolution.
>>
>
>
> +1
Thanks.
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
RE: jk2 evolution plan
Posted by Mladen Turk <mt...@apache.org>.
> -----Original Message-----
> From: Henri Gomez
>
> Ok, about everybody seems to agree on using apr for jk2
> (still waiting Nacho for IIS).
>
IIS uses APR by default (staticaly linked) for a long time.
> APR side will be to :
>
> - Update doc to indicate that APR is mandatory
>
> - Remove #idef APR
>
> - Use APR for all OS operation and sus will save us from
> handling all the #include for all the diverses IO operation
> (it's really a pain).
>
> - For now still use_jk pool, but the version using apr_tools.
>
> - Make socket use apr_socket for compatibility.
>
Why?
Just rename
env->registerFactory( env, "channel.socket",
jk2_channel_socket_factory );
to
env->registerFactory( env,
"channel.socket",jk2_channel_apr_socket_factory );
and drop the socket channel.
>
> And no the who's who ;)
>
> I'd like to know who could works on jk2 evolution.
>
+1
MT.
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org