You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by jean-frederic clere <jf...@fujitsu-siemens.com> on 2003/10/15 12:18:08 UTC
JAVA_ENDORSED_DIRS in catalina
Hi,
Should we set JAVA_ENDORSED_DIRS to a default value of
$CATALINA_HOME/common/endorsed in the startup scripts?
Cheers
Jean-Frederic
---------------------------------------------------------------------
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
jk2 evolution plan
Posted by Henri Gomez <hg...@apache.org>.
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: jk/jk2 - time for apr
Posted by Costin Manolache <cm...@yahoo.com>.
Henri Gomez wrote:
> Hi to all,
>
> Now that jk seems stabilized a bit, should we focalize on jk2 ?
>
> For instance I added some features to jk (ping/pong) which should be
> ported to jk2.
>
> Also I wonder if APR is mandatory for jk2.
>
> I'd like to use APR as a facade to all Operating System calls.
>
> The goal is to hide all the complexity of Windows, iSeries,
> differents Unix implementations behind APR which is now stable
> and well diffused.
>
> As such it will be +1 to make APR mandatory and start modifying jk2, to
> make it use only APR call.
+1
APR is released and stable - no reason not to do that.
Costin
>
> But I'd like to have your opinion first.
>
>
> PS: For those of you who was here 2 or 3 years ago, the requirement
> of APR for mod_webapp got my total -1 at this time since it
> wasn't really available, but today that's completly different.
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0] System properties in server.xml (and elsewhere)
Posted by Costin Manolache <cm...@yahoo.com>.
Remy Maucherat wrote:
> Hi,
>
> I think it would be possible, using a new rule, to allow system
> properties inside server.xml (and possibly elsewhere) for attribute
> values. This is the same as what is being done by Ant in its build
> scripts. This would add an additional degree of configurability to Tomcat.
> Actually, I wonder why this feature is not available in the digester
> itself (I really got used to that feature over the years by using Ant).
>
> Comments ?
+1, of course.
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0] System properties in server.xml (and elsewhere)
Posted by "Craig R. McClanahan" <cr...@apache.org>.
Remy Maucherat wrote:
> Hi,
>
> I think it would be possible, using a new rule, to allow system
> properties inside server.xml (and possibly elsewhere) for attribute
> values. This is the same as what is being done by Ant in its build
> scripts. This would add an additional degree of configurability to
> Tomcat.
Makes sense to me.
>
> Actually, I wonder why this feature is not available in the digester
> itself (I really got used to that feature over the years by using Ant).
Because nobody ever asked, or contributed a patch to make it so :-).
>
> Comments ?
>
> Remy
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0] System properties in server.xml (and elsewhere)
Posted by Henri Gomez <hg...@apache.org>.
Remy Maucherat a écrit :
> Henri Gomez wrote:
>
>>>> Do you speak about the ${xxx} properties as present in Tomcat 3.3.x ?
>>>
>>>
>>>
>>>
>>> Possibly. Basically, if you have a "foo.bar" sys property, you can
>>> put "${foo.bar}" in server.xml, and it will be replaced with the
>>> property value (like in Ant). I didn't know this was present in 3.3.
>>
>>
>>
>> Yes it was in TC 3.3.1 and you could also set the properties in the
>> command line if I recall well ;)
>>
>> http://jakarta.apache.org/tomcat/tomcat-3.3-doc/tomcat-ug.html#configuring_tomcat
>>
>>
>> ...
>>
>> In Tomcat 3.3.1, each attribute value may use the ant-style variable
>> substitution by using "${variable}" in the attribute string, i.e.
>> attribute="text${variable}text".
>
>
> Let me guess. James did code all that stuff aeons ago, right ? :-D
James ?
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0] System properties in server.xml (and elsewhere)
Posted by Bill Barker <wb...@wilshire.com>.
----- Original Message -----
From: "Remy Maucherat" <re...@apache.org>
To: "Tomcat Developers List" <to...@jakarta.apache.org>
Sent: Wednesday, October 15, 2003 8:31 AM
Subject: Re: [5.0] System properties in server.xml (and elsewhere)
> Henri Gomez wrote:
>
> >>> Do you speak about the ${xxx} properties as present in Tomcat 3.3.x ?
> >>
> >>
> >>
> >> Possibly. Basically, if you have a "foo.bar" sys property, you can put
> >> "${foo.bar}" in server.xml, and it will be replaced with the property
> >> value (like in Ant). I didn't know this was present in 3.3.
> >
> >
> > Yes it was in TC 3.3.1 and you could also set the properties in the
> > command line if I recall well ;)
> >
> >
http://jakarta.apache.org/tomcat/tomcat-3.3-doc/tomcat-ug.html#configuring_t
omcat
> >
> >
> > ...
> >
> > In Tomcat 3.3.1, each attribute value may use the ant-style variable
> > substitution by using "${variable}" in the attribute string, i.e.
> > attribute="text${variable}text".
>
> Let me guess. James did code all that stuff aeons ago, right ? :-D
>
Well, the aeons ago part is right ;-). But it was the other ant person
(Costin).
The guts of the 3.3 replacement is
o.a.t.u.IntrospectionUtils.replaceProperties, so most of the code is already
in Tomcat 5.
> Remy
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
Re: [5.0] No sessions purged in Context with backgroundProcessorDelay
> 0?
Posted by Jan Luehe <Ja...@Sun.COM>.
Thanks for confirming, Remy!
I'll make these changes.
Jan
Remy Maucherat wrote:
> Jan Luehe wrote:
>
>> I may be totally wrong here, but it seems that if the
>> backgroundProcessorDelay property on a StandardContext is set to
>> something greater than zero (default is -1, inherited from
>> ContainerBase), the context's sessions are never purged.
>>
>> This is because in ContainerBase$ContainerBackgroundProcessor,
>> processChildren() is implemented as follows:
>>
>> for (int i = 0; i < children.length; i++) {
>> if (children[i].getBackgroundProcessorDelay() <= 0) {
>> processChildren(children[i], cl);
>> }
>> }
>>
>> So when invoked from the ContainerBackgroundProcessor of a
>> StandardHost, only the sessions of those StandardContexts with a
>> backgroundProcessorDelay <=0 will get purged.
>>
>> I think the assumption is that if a StandardContext has a
>> backgroundProcessorDelay > 0, it would have its own
>> ContainerBackgroundProcessor spawn at startup. However, unlike
>> StandardEngine/Host/Wrapper, StandardContext.start() does not invoke
>> super.start(), and therefore a ContainerBackgroundProcessor is never
>> created for a StandardContext.
>
>
> Arg, stupid me, I forgot about that. We need to add the code which
> starts the backgroud thread in StandardContext.start.
> So we need to call super.startThread() and super.stopThread. This
> doesn't seem too hard.
>
> Remy
>
>
>
> ---------------------------------------------------------------------
> 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: [5.0] No sessions purged in Context with backgroundProcessorDelay
> 0?
Posted by Remy Maucherat <re...@apache.org>.
Jan Luehe wrote:
> I may be totally wrong here, but it seems that if the
> backgroundProcessorDelay property on a StandardContext is set to
> something greater than zero (default is -1, inherited from
> ContainerBase), the context's sessions are never purged.
>
> This is because in ContainerBase$ContainerBackgroundProcessor,
> processChildren() is implemented as follows:
>
> for (int i = 0; i < children.length; i++) {
> if (children[i].getBackgroundProcessorDelay() <= 0) {
> processChildren(children[i], cl);
> }
> }
>
> So when invoked from the ContainerBackgroundProcessor of a
> StandardHost, only the sessions of those StandardContexts with a
> backgroundProcessorDelay <=0 will get purged.
>
> I think the assumption is that if a StandardContext has a
> backgroundProcessorDelay > 0, it would have its own
> ContainerBackgroundProcessor spawn at startup. However, unlike
> StandardEngine/Host/Wrapper, StandardContext.start() does not invoke
> super.start(), and therefore a ContainerBackgroundProcessor is never
> created for a StandardContext.
Arg, stupid me, I forgot about that. We need to add the code which
starts the backgroud thread in StandardContext.start.
So we need to call super.startThread() and super.stopThread. This
doesn't seem too hard.
Remy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
[5.0] No sessions purged in Context with backgroundProcessorDelay > 0?
Posted by Jan Luehe <Ja...@Sun.COM>.
I may be totally wrong here, but it seems that if the
backgroundProcessorDelay property on a StandardContext is set to
something greater than zero (default is -1, inherited from
ContainerBase), the context's sessions are never purged.
This is because in ContainerBase$ContainerBackgroundProcessor,
processChildren() is implemented as follows:
for (int i = 0; i < children.length; i++) {
if (children[i].getBackgroundProcessorDelay() <= 0) {
processChildren(children[i], cl);
}
}
So when invoked from the ContainerBackgroundProcessor of a
StandardHost, only the sessions of those StandardContexts with a
backgroundProcessorDelay <=0 will get purged.
I think the assumption is that if a StandardContext has a
backgroundProcessorDelay > 0, it would have its own
ContainerBackgroundProcessor spawn at startup. However, unlike
StandardEngine/Host/Wrapper, StandardContext.start() does not invoke
super.start(), and therefore a ContainerBackgroundProcessor is never
created for a StandardContext.
Am I missing something here?
Thanks,
Jan
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0] System properties in server.xml (and elsewhere)
Posted by Remy Maucherat <re...@apache.org>.
Henri Gomez wrote:
>>> Do you speak about the ${xxx} properties as present in Tomcat 3.3.x ?
>>
>>
>>
>> Possibly. Basically, if you have a "foo.bar" sys property, you can put
>> "${foo.bar}" in server.xml, and it will be replaced with the property
>> value (like in Ant). I didn't know this was present in 3.3.
>
>
> Yes it was in TC 3.3.1 and you could also set the properties in the
> command line if I recall well ;)
>
> http://jakarta.apache.org/tomcat/tomcat-3.3-doc/tomcat-ug.html#configuring_tomcat
>
>
> ...
>
> In Tomcat 3.3.1, each attribute value may use the ant-style variable
> substitution by using "${variable}" in the attribute string, i.e.
> attribute="text${variable}text".
Let me guess. James did code all that stuff aeons ago, right ? :-D
Remy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0] System properties in server.xml (and elsewhere)
Posted by Henri Gomez <hg...@apache.org>.
>> Do you speak about the ${xxx} properties as present in Tomcat 3.3.x ?
>
>
> Possibly. Basically, if you have a "foo.bar" sys property, you can put
> "${foo.bar}" in server.xml, and it will be replaced with the property
> value (like in Ant). I didn't know this was present in 3.3.
Yes it was in TC 3.3.1 and you could also set the properties in the
command line if I recall well ;)
http://jakarta.apache.org/tomcat/tomcat-3.3-doc/tomcat-ug.html#configuring_tomcat
...
In Tomcat 3.3.1, each attribute value may use the ant-style variable
substitution by using "${variable}" in the attribute string, i.e.
attribute="text${variable}text".
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0] System properties in server.xml (and elsewhere)
Posted by Remy Maucherat <re...@apache.org>.
Henri Gomez wrote:
> Remy Maucherat a écrit :
>
>> Hi,
>>
>> I think it would be possible, using a new rule, to allow system
>> properties inside server.xml (and possibly elsewhere) for attribute
>> values. This is the same as what is being done by Ant in its build
>> scripts. This would add an additional degree of configurability to
>> Tomcat.
>> Actually, I wonder why this feature is not available in the digester
>> itself (I really got used to that feature over the years by using Ant).
>
> Do you speak about the ${xxx} properties as present in Tomcat 3.3.x ?
Possibly. Basically, if you have a "foo.bar" sys property, you can put
"${foo.bar}" in server.xml, and it will be replaced with the property
value (like in Ant). I didn't know this was present in 3.3.
Remy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0] System properties in server.xml (and elsewhere)
Posted by Henri Gomez <hg...@apache.org>.
Remy Maucherat a écrit :
> Hi,
>
> I think it would be possible, using a new rule, to allow system
> properties inside server.xml (and possibly elsewhere) for attribute
> values. This is the same as what is being done by Ant in its build
> scripts. This would add an additional degree of configurability to Tomcat.
> Actually, I wonder why this feature is not available in the digester
> itself (I really got used to that feature over the years by using Ant).
Do you speak about the ${xxx} properties as present in Tomcat 3.3.x ?
A big +1
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0] System properties in server.xml (and elsewhere)
Posted by Tim Funk <fu...@joedog.org>.
+0 (I'd be +1 if I could actually be of help - but love the idea)
-Tim
Remy Maucherat wrote:
> Hi,
>
> I think it would be possible, using a new rule, to allow system
> properties inside server.xml (and possibly elsewhere) for attribute
> values. This is the same as what is being done by Ant in its build
> scripts. This would add an additional degree of configurability to Tomcat.
> Actually, I wonder why this feature is not available in the digester
> itself (I really got used to that feature over the years by using Ant).
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
[5.0] System properties in server.xml (and elsewhere)
Posted by Remy Maucherat <re...@apache.org>.
Hi,
I think it would be possible, using a new rule, to allow system
properties inside server.xml (and possibly elsewhere) for attribute
values. This is the same as what is being done by Ant in its build
scripts. This would add an additional degree of configurability to Tomcat.
Actually, I wonder why this feature is not available in the digester
itself (I really got used to that feature over the years by using Ant).
Comments ?
Remy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: jk/jk2 - time for apr
Posted by Glenn Nielsen <gl...@mail.more.net>.
+1 to have a version of mod_jk rewritten to use APR for all OS stuff
It would be best to use the version of APR which is distributed with
the current Apache 2 release so that there are no conflicts when using
mod_jk with Apache 2.
Requiring APR would allow using a global connection pool for the socket
connections to Tomcat. And allow more sophisticated load balancing when
you can have access to global information about how each pool of connectors
to Tomcat is performing.
If this involves significant changes to the code we might want to bump
the major version to jk3.
We will still need at least one more release of mod_jk 1.2 for the
minor changes committed since the 1.2.5 release.
Regards,
Glenn
Henri Gomez wrote:
> Hi to all,
>
> Now that jk seems stabilized a bit, should we focalize on jk2 ?
>
> For instance I added some features to jk (ping/pong) which should be
> ported to jk2.
>
> Also I wonder if APR is mandatory for jk2.
>
> I'd like to use APR as a facade to all Operating System calls.
>
> The goal is to hide all the complexity of Windows, iSeries,
> differents Unix implementations behind APR which is now stable
> and well diffused.
>
> As such it will be +1 to make APR mandatory and start modifying jk2, to
> make it use only APR call.
>
> But I'd like to have your opinion first.
>
>
> PS: For those of you who was here 2 or 3 years ago, the requirement
> of APR for mod_webapp got my total -1 at this time since it
> wasn't really available, but today that's completly different.
>
>
> ---------------------------------------------------------------------
> 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: jk/jk2 - time for apr
Posted by Henri Gomez <hg...@apache.org>.
jean-frederic clere a écrit :
> Henri Gomez wrote:
>
>> Mladen Turk a écrit :
>>
>>> +1 to use the APR as mandatory for the mod_jk.
>>> You can rename it to the mod_jk2 after that easily :-)
>>
>>
>>
>> Heu, the idea is to make jk2 (native2) apr mandatory.
>>
>> We'll keep jk as it is today.
>>
>> * the plan
>>
>> - update jk2 (native2) to use APR only
>>
>> - port jk add-ons like ping/pong to jk2
>>
>> - test, test and re-test
>>
>> - mark jk as deprecated
>>
>>
>> The rule will be to use the latest APR release, ie the one which goes
>> with the latest Apache 2.0 release.
>>
>> We could handle more recent APR via :
>>
>> /* deprecated with apr 0.9.3 */
>> #include "apr_version.h"
>> #if (APR_MAJOR_VERSION == 0) && \
>> (APR_MINOR_VERSION <= 9) && \
>> (APR_PATCH_VERSION < 3)
>> #define apr_filepath_name_get apr_filename_of_pathname
>> #endif
>>
>>
>> It will make jk2 ideally suited for Apache 2, and since we could find
>> apr.dll for Windows Box, it should be usable with IIS (Domino ?).
>>
>> I'd like to have comments from Nacho, JF Clere and Mike Anderson
>> who are working of jk on others platforms/webservers.
>
>
> Using APR is a good idea but that is a lot of work. I have APR on all my
> "strange" platforms so no problem for me :-)
iSeries is another quite exotic platform even if Rochester friends does
a great job on Apache 2.0 integration on OS/400 ;)
> I was quite unhappy with the -1 on APR/mod_webapp but all the problems
> of APR years ago have contribued to make mod_webapp deprecated...
At this time there wasn't an official APR release or official Apache 2
release, and webapp was using APR from HEAD CVS (with frequent changes).
Now the situation is stabilized since major Linux distributions have
Apache 2.0 bundled by default, so APR is allready available.
> We have to be carefull with the threads... Specialy if we want to add
> the feature to (re)start Tomcat automaticly from httpd.
We should, allways, be very carefull with threads ;)
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: jk/jk2 - time for apr
Posted by jean-frederic clere <jf...@fujitsu-siemens.com>.
Henri Gomez wrote:
> Mladen Turk a écrit :
>
>> +1 to use the APR as mandatory for the mod_jk.
>> You can rename it to the mod_jk2 after that easily :-)
>
>
> Heu, the idea is to make jk2 (native2) apr mandatory.
>
> We'll keep jk as it is today.
>
> * the plan
>
> - update jk2 (native2) to use APR only
>
> - port jk add-ons like ping/pong to jk2
>
> - test, test and re-test
>
> - mark jk as deprecated
>
>
> The rule will be to use the latest APR release, ie the one which goes
> with the latest Apache 2.0 release.
>
> We could handle more recent APR via :
>
> /* deprecated with apr 0.9.3 */
> #include "apr_version.h"
> #if (APR_MAJOR_VERSION == 0) && \
> (APR_MINOR_VERSION <= 9) && \
> (APR_PATCH_VERSION < 3)
> #define apr_filepath_name_get apr_filename_of_pathname
> #endif
>
>
> It will make jk2 ideally suited for Apache 2, and since we could find
> apr.dll for Windows Box, it should be usable with IIS (Domino ?).
>
> I'd like to have comments from Nacho, JF Clere and Mike Anderson
> who are working of jk on others platforms/webservers.
Using APR is a good idea but that is a lot of work. I have APR on all my
"strange" platforms so no problem for me :-)
I was quite unhappy with the -1 on APR/mod_webapp but all the problems of APR
years ago have contribued to make mod_webapp deprecated...
We have to be carefull with the threads... Specialy if we want to add the
feature to (re)start Tomcat automaticly from httpd.
>
>
>
> ---------------------------------------------------------------------
> 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: jk/jk2 - time for apr
Posted by jean-frederic clere <jf...@fujitsu-siemens.com>.
Mladen Turk wrote:
>
>>-----Original Message-----
>>From: Henri Gomez
>>
>>Mladen Turk a écrit :
>>
>>>+1 to use the APR as mandatory for the mod_jk.
>>>You can rename it to the mod_jk2 after that easily :-)
>>
>>Heu, the idea is to make jk2 (native2) apr mandatory.
>>
>>We'll keep jk as it is today.
>>
>
>
> And I was thinking you have all the time in the world ;-).
>
>
>>* the plan
>>
>>- update jk2 (native2) to use APR only
>>
>
>
> Well, that's mostly "delete all outside HAS_APR".
>
> Other would be to use the full APR/APR-UTILS api where ever possible,
> like for shm, get rid of apr_pool wrapper, etc...
> AND of course drop the all unsupported channels like (fast unix
> sockets).
The AF_UNIX sockets feature needs to have a C part in the Tomcat and that brings
problems similar to the JNI problems.
> (What about JNI? This is very non-portable due to forked servers, but
> that's another story).
>
> IIS and Apache2 uses the APR by default, as well as Apache1.3x (WIN32),
> so no problem there.
>
>
>>- port jk add-ons like ping/pong to jk2
>>
>
>
> OK.
>
>
>>- test, test and re-test
>>
>
>
> OK.
>
>
>>- mark jk as deprecated
>>
>
>
> OK.
>
>
>>The rule will be to use the latest APR release, ie the one
>>which goes with the latest Apache 2.0 release.
>>
>>We could handle more recent APR via :
>>
>>/* deprecated with apr 0.9.3 */
>>#include "apr_version.h"
>>#if (APR_MAJOR_VERSION == 0) && \
>> (APR_MINOR_VERSION <= 9) && \
>> (APR_PATCH_VERSION < 3)
>>#define apr_filepath_name_get apr_filename_of_pathname
>>#endif
>>
>
>
> Why would you do that?
> Just use the post 0.9.3 API.
>
>
>>It will make jk2 ideally suited for Apache 2, and since we
>>could find apr.dll for Windows Box, it should be usable with
>>IIS (Domino ?).
>>
>
>
> MT.
>
>
> ---------------------------------------------------------------------
> 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: jk/jk2 - time for apr
Posted by Mladen Turk <mt...@apache.org>.
> -----Original Message-----
> From: Henri Gomez
>
> Mladen Turk a écrit :
> > +1 to use the APR as mandatory for the mod_jk.
> > You can rename it to the mod_jk2 after that easily :-)
>
> Heu, the idea is to make jk2 (native2) apr mandatory.
>
> We'll keep jk as it is today.
>
And I was thinking you have all the time in the world ;-).
> * the plan
>
> - update jk2 (native2) to use APR only
>
Well, that's mostly "delete all outside HAS_APR".
Other would be to use the full APR/APR-UTILS api where ever possible,
like for shm, get rid of apr_pool wrapper, etc...
AND of course drop the all unsupported channels like (fast unix
sockets).
(What about JNI? This is very non-portable due to forked servers, but
that's another story).
IIS and Apache2 uses the APR by default, as well as Apache1.3x (WIN32),
so no problem there.
> - port jk add-ons like ping/pong to jk2
>
OK.
> - test, test and re-test
>
OK.
> - mark jk as deprecated
>
OK.
>
> The rule will be to use the latest APR release, ie the one
> which goes with the latest Apache 2.0 release.
>
> We could handle more recent APR via :
>
> /* deprecated with apr 0.9.3 */
> #include "apr_version.h"
> #if (APR_MAJOR_VERSION == 0) && \
> (APR_MINOR_VERSION <= 9) && \
> (APR_PATCH_VERSION < 3)
> #define apr_filepath_name_get apr_filename_of_pathname
> #endif
>
Why would you do that?
Just use the post 0.9.3 API.
>
> It will make jk2 ideally suited for Apache 2, and since we
> could find apr.dll for Windows Box, it should be usable with
> IIS (Domino ?).
>
MT.
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: jk/jk2 - time for apr
Posted by Henri Gomez <hg...@apache.org>.
Mladen Turk a écrit :
> +1 to use the APR as mandatory for the mod_jk.
> You can rename it to the mod_jk2 after that easily :-)
Heu, the idea is to make jk2 (native2) apr mandatory.
We'll keep jk as it is today.
* the plan
- update jk2 (native2) to use APR only
- port jk add-ons like ping/pong to jk2
- test, test and re-test
- mark jk as deprecated
The rule will be to use the latest APR release, ie the one which goes
with the latest Apache 2.0 release.
We could handle more recent APR via :
/* deprecated with apr 0.9.3 */
#include "apr_version.h"
#if (APR_MAJOR_VERSION == 0) && \
(APR_MINOR_VERSION <= 9) && \
(APR_PATCH_VERSION < 3)
#define apr_filepath_name_get apr_filename_of_pathname
#endif
It will make jk2 ideally suited for Apache 2, and since we could find
apr.dll for Windows Box, it should be usable with IIS (Domino ?).
I'd like to have comments from Nacho, JF Clere and Mike Anderson
who are working of jk on others platforms/webservers.
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
RE: jk/jk2 - time for apr
Posted by Mladen Turk <mt...@apache.org>.
+1 to use the APR as mandatory for the mod_jk.
You can rename it to the mod_jk2 after that easily :-)
MT.
> -----Original Message-----
> From: Henri Gomez
>
> Hi to all,
>
> Now that jk seems stabilized a bit, should we focalize on jk2 ?
>
> For instance I added some features to jk (ping/pong) which
> should be ported to jk2.
>
> Also I wonder if APR is mandatory for jk2.
>
> I'd like to use APR as a facade to all Operating System calls.
>
> The goal is to hide all the complexity of Windows, iSeries,
> differents Unix implementations behind APR which is now
> stable and well diffused.
>
> As such it will be +1 to make APR mandatory and start
> modifying jk2, to
> make it use only APR call.
>
> But I'd like to have your opinion first.
>
>
> PS: For those of you who was here 2 or 3 years ago, the requirement
> of APR for mod_webapp got my total -1 at this time since it
> wasn't really available, but today that's completly different.
>
>
> ---------------------------------------------------------------------
> 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
jk/jk2 - time for apr
Posted by Henri Gomez <hg...@apache.org>.
Hi to all,
Now that jk seems stabilized a bit, should we focalize on jk2 ?
For instance I added some features to jk (ping/pong) which should be
ported to jk2.
Also I wonder if APR is mandatory for jk2.
I'd like to use APR as a facade to all Operating System calls.
The goal is to hide all the complexity of Windows, iSeries,
differents Unix implementations behind APR which is now stable
and well diffused.
As such it will be +1 to make APR mandatory and start modifying jk2, to
make it use only APR call.
But I'd like to have your opinion first.
PS: For those of you who was here 2 or 3 years ago, the requirement
of APR for mod_webapp got my total -1 at this time since it
wasn't really available, but today that's completly different.
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org