Re: Native 1.1.12 release

[jean-frederic clere]

Filip Hanik - Dev Lists wrote:

Mladen Turk wrote:

Filip Hanik - Dev Lists wrote:
you're other option is to just vote on tcnative separately, and that 
way utilize all the ASF mirrors and release sites




But that is exactly what we should *not* do.
Tomcat comes with it's native, so if you upgrade the
Tomcat, upgrade its native as well (if changed)


Yes that works because the API is now stable.

Cheers

Jean-Frederic

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

DO NOT REPLY [Bug 44237] New: - Memory consumption is More in Tomcat 5.0 than Tomcat 6.1.4.Memory release is not happening successfully.

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=44237

   Summary: Memory consumption is More in Tomcat 5.0 than Tomcat
6.1.4.Memory release is not happening successfully.
   Product: Tomcat 5
   Version: 5.0.0
  Platform: Other
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P5
 Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]


Hi,
   I am using Tomcat 5.0.0 to deploy my web application.As soon as I run tomcat
, it start memory consumption and after I login to my application the memory
usage increases.I have taken care of the Threads using in my application so that
once logout from the application,they will not be in alive state to hold the
memory unnecessarily.But After logout also I found the memory consumption is not
reduced.
the scenario was like this,
Event   %Mem%CPU
-  --- ---
Before login3.3  1   
After Login 3.4  4 
After Logout3.4  3
Login Again 3.6  4
Navigating to Browse View   4.2  7  
After Logout4.2  2

But when I deployed my application in Tomcat 6.1.4 I found a better performance
than earlier,like,
Event   %Mem%CPU

Before login3.3  1   
After Login 3.4  4 
After Logout3.3  1 (0 after few seconds).
Login Back  3.4  4
Browse View 4.6  12
Configure View  5.2  24
logout  4.2  2 (0 after few seconds)
login in4.4  4
logout  4.2  1
login   4.3  3
logout  4.2  1
login   4.4  3
logout  4.4  1 (Here Memory didn't
decrease,reason is unknown to me) 
login   4.6  5
logout  4.5  1 (decreased again)

I have some doubt to ask along with this.In Tomcat 5.0.0 , server.xml contains a
entry for connector where we can specify the number of connector Threads to be
executed by Tomcat.For my case the number is 25.As soon as I run tomcat 25
Threads start running and I got a trace of those as,
Thread [http-28080-Processor1](Running)  where 28080 is the port number
Thread [http-28080-Processor2](Running)  Tomcat is using. 
.
.
Thread [http-28080-Processor25](Running)
When I am login to my application(Sending my request to Tomcat), one thread(say,
Thread [http-28080-Processor24]) created by connector, start processing the
request and occupied memory increased along with the used CPU cycles. In case
of logout again the thread become active, process the request and application
logged out. Here no decrement of the memory usage and a small decrement of the
used CPU cycle .Now if I suspend(not terminate) the thread which processed the
last request,occupied memory is getting released. In this whole process, I ran
jConsole utility which has a mechanism to make the object applicable for garbage
collection if they are not in use. I used the mechanism but occupied memory
never get released till I suspend the connector thread explicitly(Neither
terminating the thread nor terminating/restarting the Tomcat).Otherwise memory
usage is just keep increasing.
I am surprise to see Tomcat 6.1.4 is managing the memory is effective than the
earlier version.

-Tapas

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 44215] - jkunmount causes apache to throw permission denied error

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=44215


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEEDINFO|RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2008-01-14 18:50 ---
It turns out that apache doesn't have read permission to
/usr/share/tomcat5/webapps.  Sorry about the false alarm.  I have closed the 
bug.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

Re: Native 1.1.12 release

[Guenter Knauf]

Hi,
> Still need to figure out what to do with all the other versions in
> a.o/dist though - we can't just leave them.

well, someone needs to commit them all to a project's SVN subdir like 
'tagged_tarballs' or such;
this way the history would stay available...

Guen.



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

Re: [VOTE] Release Tomcat native 1.1.12

[Filip Hanik - Dev Lists]

Mladen Turk wrote:

Yoav Shapira wrote:

Sorry, I typed this before reading the other thread.

+1 for releasing this specific file.  If this vote doesn't pass, the
file has to be removed.



I'll remove the file (1.1.12)
Like said they are already inside
http://tomcat.apache.org/dev/dist/tomcat-connectors/native/

I doubt we can remove all previous files, cause it would
mean breaking the history builds.
if the file, and its location is required to build a source distro, then 
we should probably move tcnative into "product" status so that we can 
host those files and keep an archive of them
is there a reason or strong preference not to have tcnative in its own 
release cycle?

Filip


I agree that anything inside apache.org/dist needs to be voted,
but we actually use this location only to be able to build the
Tomcat.

It was a mistake we used apache.org/dist as temporary
storage for pre-produced native tarballs, since
this location gets propagated trough the mirrors.

Regards,
Mladen

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






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

Re: Native 1.1.12 release

[Mark Thomas]

Mladen Turk wrote:

Guenter Knauf wrote:

just an idea / suggestion:
isnt it usable for the release process that you create a place in SVN 
where you commit the tarballs, and then download them via http from 
there instead from a directory location?




Finally, an interesting idea.
You are right. This would make things much easier.
It would complicate the url pattern for native
inside build.xml, but who cares.

Anyone?


If we treat it the same way as the windows binaries, it should just be a 
local copy shouldn't it?


Sounds like a plan to me.

Still need to figure out what to do with all the other versions in a.o/dist 
though - we can't just leave them.


Mark


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

Re: Native 1.1.12 release

[Mladen Turk]

William A. Rowe, Jr. wrote:

I understand the desire to make this
"easy" for the RM, and the statement that its "useless" from
outside of tomcat, but the simple fact is that this is a
released unit of code, separately versioned, determined before
the "real release" of Tomcat is designated.



Look, the whole purpose of "versioning" was to make
the things simpler to release.
It seems now, that we cannot rely on that any more,
for what ever reasons.

The only solution is to change the build.xml so it can
create all that at once, or just drop the native from
the distro.


Regards,
Mladen


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

Re: Native 1.1.12 release

[Mladen Turk]

Guenter Knauf wrote:

Hi Mladen,

But that is exactly what we should *not* do.
Tomcat comes with it's native, so if you upgrade the
Tomcat, upgrade its native as well (if changed)



Like said, all that can be easy done by simply
extending requirements for building Tomcat release.
One will need Python and a set of GNU build tools,
and we can easily forget the native helper tarballs.



It would mean that you will need *nix for building
the Tomcat release, but that's fine with me.



If the Tomcat RM's are fine with that, it's a very
simple task.


just an idea / suggestion:
isnt it usable for the release process that you create a place in SVN where you 
commit the tarballs, and then download them via http from there instead from a 
directory location?



Finally, an interesting idea.
You are right. This would make things much easier.
It would complicate the url pattern for native
inside build.xml, but who cares.

Anyone?

Regards,
Mladen

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

Re: [VOTE] Release Tomcat native 1.1.12

[Mark Thomas]

Mladen Turk wrote:

Mark Thomas wrote:


We have been making the src available for download since the first 
version, so why not continue to do so but do so within the ASF rules 
and have a release vote? The overhead of a vote is pretty small and it 
isn't like it is going to be struggling for +1s.




But we *never* had any vote on native release.
See my reply to Yoav. It was a mistake we used apache.org/dist
location for those files.


Thanks, that explains the history.

If we do leave those files in a.o/dist then we'll need to vote on them 
anyway. We can't just leave them there since, mistake or not, they are 
releases.


Just read Guenter's e-mail. I wonder. If we put them in svn, could we use 
some form of cunning re-direct?


Mark


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

Re: Native 1.1.12 release

[Mark Thomas]

Guenter Knauf wrote:

just an idea / suggestion:
isnt it usable for the release process that you create a place in SVN where you 
commit the tarballs, and then download them via http from there instead from a 
directory location?


That would work. We use the same process for the windows service binaries.

Mark


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

Re: [VOTE] Release Tomcat native 1.1.12

[Mladen Turk]

Mark Thomas wrote:
This may end up as moot when the "to release or not to release" thread 
concludes but if not, here is my vote




LOL, I love you Mark, because you cannot be distracted.
I've tried, but I've failed :)

Cheers,
Mladen

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

Re: Native 1.1.12 release

[William A. Rowe, Jr.]

Mladen Turk wrote:


Because it's native and the one that makes a release needs
some extra prerequisites to build it.


Part of this confusion is that projects never vote on binary
artifacts, they vote on source code releases.

Because the sources land in tags/ and a tarball, I'd strongly
consider a release vote is manditory before some binary
artifacts are shipped.  I understand the desire to make this
"easy" for the RM, and the statement that its "useless" from
outside of tomcat, but the simple fact is that this is a
released unit of code, separately versioned, determined before
the "real release" of Tomcat is designated.

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

Re: Native 1.1.12 release

[Guenter Knauf]

Hi Mladen,
> But that is exactly what we should *not* do.
> Tomcat comes with it's native, so if you upgrade the
> Tomcat, upgrade its native as well (if changed)

> Like said, all that can be easy done by simply
> extending requirements for building Tomcat release.
> One will need Python and a set of GNU build tools,
> and we can easily forget the native helper tarballs.

> It would mean that you will need *nix for building
> the Tomcat release, but that's fine with me.

> If the Tomcat RM's are fine with that, it's a very
> simple task.

just an idea / suggestion:
isnt it usable for the release process that you create a place in SVN where you 
commit the tarballs, and then download them via http from there instead from a 
directory location?

Guenter.



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

Re: Native 1.1.12 release

[Mladen Turk]

Filip Hanik - Dev Lists wrote:

Mladen Turk wrote:

Filip Hanik - Dev Lists wrote:
you're other option is to just vote on tcnative separately, and that 
way utilize all the ASF mirrors and release sites




But that is exactly what we should *not* do.
Tomcat comes with it's native, so if you upgrade the
Tomcat, upgrade its native as well (if changed)
except the fact that you could upgrade 5.5.25 (existing tomcat release) 
with the tcnative 1.1.12 (from the new tomcat release)


You can do that with any .jar file as well, right :)

so if it is not a product, how come it's versioned and tagged 
separately, and not just tagged with Tomcat's tag like the jsp engine or 
the nio connector.


Because it's native and the one that makes a release needs
some extra prerequisites to build it.


Regards,
Mladen


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

Re: [VOTE] Release Tomcat native 1.1.12

[Mladen Turk]

Mark Thomas wrote:


We have been making the src available for download since the first 
version, so why not continue to do so but do so within the ASF rules and 
have a release vote? The overhead of a vote is pretty small and it isn't 
like it is going to be struggling for +1s.




But we *never* had any vote on native release.
See my reply to Yoav. It was a mistake we used apache.org/dist
location for those files.

Regards,
Mladen

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

Re: [VOTE] Release Tomcat native 1.1.12

[Mark Thomas]

This may end up as moot when the "to release or not to release" thread 
concludes but if not, here is my vote


Mark Thomas wrote:

The source distributions are here:

http://www.apache.org/dist/tomcat/tomcat-connectors/native/tomcat-native-1.1.12-src.tar.gz 

http://www.apache.org/dist/tomcat/tomcat-connectors/native/tomcat-native-1.1.12-win32-src.zip 



According to the release process, the 1.1.12 tarball is:
[ ] Broken
[ ] Alpha
[ ] Beta
[X] Stable


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

Re: Native 1.1.12 release

[Filip Hanik - Dev Lists]

Mladen Turk wrote:

Filip Hanik - Dev Lists wrote:
you're other option is to just vote on tcnative separately, and that 
way utilize all the ASF mirrors and release sites




But that is exactly what we should *not* do.
Tomcat comes with it's native, so if you upgrade the
Tomcat, upgrade its native as well (if changed)
except the fact that you could upgrade 5.5.25 (existing tomcat release) 
with the tcnative 1.1.12 (from the new tomcat release)
so if it is not a product, how come it's versioned and tagged 
separately, and not just tagged with Tomcat's tag like the jsp engine or 
the nio connector.


Like said, all that can be easy done by simply
extending requirements for building Tomcat release.
One will need Python and a set of GNU build tools,
and we can easily forget the native helper tarballs.

It would mean that you will need *nix for building
the Tomcat release, but that's fine with me.
currently we require Win as the build environment (I think it had to do 
with NSIS installer or something like that)
the tcnative, is a source tarball, right? so could we make it buildable 
with ANT?


If the Tomcat RM's are fine with that, it's a very
simple task.
I'd be ok with putting it as part of the TC build itself if we don't 
want it as a separate product.


Filip



Regards,
Mladen

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






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

Re: [VOTE] Release Tomcat native 1.1.12

[Mladen Turk]

Yoav Shapira wrote:

Sorry, I typed this before reading the other thread.

+1 for releasing this specific file.  If this vote doesn't pass, the
file has to be removed.



I'll remove the file (1.1.12)
Like said they are already inside
http://tomcat.apache.org/dev/dist/tomcat-connectors/native/

I doubt we can remove all previous files, cause it would
mean breaking the history builds.

I agree that anything inside apache.org/dist needs to be voted,
but we actually use this location only to be able to build the
Tomcat.

It was a mistake we used apache.org/dist as temporary
storage for pre-produced native tarballs, since
this location gets propagated trough the mirrors.

Regards,
Mladen

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

Re: [VOTE] Release Tomcat native 1.1.12

[Mark Thomas]

Mladen Turk wrote:

Did you read what I said? There is no such thing
as *tomcat-native release*, period, so
there is no thing we can vote for.


If we make a src tarball available for download, then it is a release. It 
doesn't matter that it is useless on it's own nor that similar 
functionality is included in part of a larger package elsewhere.


We have been making the src available for download since the first version, 
so why not continue to do so but do so within the ASF rules and have a 
release vote? The overhead of a vote is pretty small and it isn't like it 
is going to be struggling for +1s.



There is no Tomcat NIO, HTTP or AJP connector release as well.
The only small difference is that the first one is
written in C, while rest are written in Java.
This is one and only difference.


There are other differences, the key one being that we make it available 
for separate download.



There is no such thing as tomcat-native product that
we can vote for.


What are all these then?
http://tomcat.heanet.ie/native/



Ask the US government and their crypto law :)


I thought it was a licensing issue on one of the required libraries but 
that doesn't really matter here. The point is it looks like a release, it 
gets tagged like a release, it gets distributed like a release, why not 
just do a release?


Mark


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

Re: [VOTE] Release Tomcat native 1.1.12

[Yoav Shapira]

Sorry, I typed this before reading the other thread.

+1 for releasing this specific file.  If this vote doesn't pass, the
file has to be removed.

What we decide to do going forwards I leave to the native release
manager, and I have no preference in the matter.  Except of course we
have to comply with ASF rules ;)

On Jan 14, 2008 6:57 PM, Yoav Shapira <[EMAIL PROTECTED]> wrote:
> I think the difference is based on an understanding of what
> constitutes a release.  A tarball in www.apache.org/dist/... is a
> release by definition.  Files cannot go in that directory or its
> children without a vote.
>
> If they're there, they're a release.  We have to vote on them or pull
> them out.  I don't have a preference, but it seems like just a quick
> vote over 72 hours is a simple enough thing.
>
>
> On Jan 14, 2008 6:29 PM, Mladen Turk <[EMAIL PROTECTED]> wrote:
> > Mark Thomas wrote:
> > > The source distributions are here:
> > >
> > > http://www.apache.org/dist/tomcat/tomcat-connectors/native/tomcat-native-1.1.12-src.tar.gz
> > >
> > > http://www.apache.org/dist/tomcat/tomcat-connectors/native/tomcat-native-1.1.12-win32-src.zip
> > >
> > >
> > > According to the release process, the 1.1.12 tarball is:
> > > [ ] Broken
> > > [ ] Alpha
> > > [ ] Beta
> > > [ ] Stable
> > >
> >
> > -1 (or if you wish veto)
> >
> > There is no such thing as tomcat-native product that
> > we can vote for.
> > Tomcat-native is integral part of Tomcat, so we cannot
> > vote on Tomcat's jsp engine, or its NIO connector.
> >
> >
> >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
>
> --
> Thanks,
>
> Yoav
>



-- 
Thanks,

Yoav

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

Re: [VOTE] Release Tomcat native 1.1.12

[Yoav Shapira]

I think the difference is based on an understanding of what
constitutes a release.  A tarball in www.apache.org/dist/... is a
release by definition.  Files cannot go in that directory or its
children without a vote.

If they're there, they're a release.  We have to vote on them or pull
them out.  I don't have a preference, but it seems like just a quick
vote over 72 hours is a simple enough thing.

On Jan 14, 2008 6:29 PM, Mladen Turk <[EMAIL PROTECTED]> wrote:
> Mark Thomas wrote:
> > The source distributions are here:
> >
> > http://www.apache.org/dist/tomcat/tomcat-connectors/native/tomcat-native-1.1.12-src.tar.gz
> >
> > http://www.apache.org/dist/tomcat/tomcat-connectors/native/tomcat-native-1.1.12-win32-src.zip
> >
> >
> > According to the release process, the 1.1.12 tarball is:
> > [ ] Broken
> > [ ] Alpha
> > [ ] Beta
> > [ ] Stable
> >
>
> -1 (or if you wish veto)
>
> There is no such thing as tomcat-native product that
> we can vote for.
> Tomcat-native is integral part of Tomcat, so we cannot
> vote on Tomcat's jsp engine, or its NIO connector.
>
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>



-- 
Thanks,

Yoav

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

Re: [VOTE] Release Tomcat native 1.1.12

[Mark Thomas]

Mladen Turk wrote:

Mark Thomas wrote:

Mladen Turk wrote:

-1 (or if you wish veto)


Releases can't be voted. The 3 more +1s than -1s rule still applies 
though.




OK, it seems we have problem here.
Did you read what I said? There is no such thing
as *tomcat-native release*, period, so
there is no thing we can vote for.
There is no Tomcat NIO, HTTP or AJP connector release as well.
The only small difference is that the first one is
written in C, while rest are written in Java.
This is one and only difference.


There is no such thing as tomcat-native product that
we can vote for.


What are all these then?
http://tomcat.heanet.ie/native/



Ask the US government and their crypto law :)

Regards,
Mladen



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





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

Re: [VOTE] Release Tomcat native 1.1.12

[Mark Thomas]

Mark Thomas wrote:

Mladen Turk wrote:

-1 (or if you wish veto)


Releases can't be voted. The 3 more +1s than -1s rule still applies though.


Opps. Make that "Releases can't be vetoed". It's getting late here ;)

Mark


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

Re: [VOTE] Release Tomcat native 1.1.12

[Mladen Turk]

Mark Thomas wrote:

Mladen Turk wrote:

-1 (or if you wish veto)


Releases can't be voted. The 3 more +1s than -1s rule still applies though.



BTW, (if that would be considered as a release at the first place)
you were not RM (Jean-Frederic made the tag), so you cannot
ask for an vote.
Well, I'm not actually sure, but the common practice inside ASF
is that the person making a tarball asks for a vote.

Regards,
Mladen

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

Re: [VOTE] Release Tomcat native 1.1.12

[Mladen Turk]

Mark Thomas wrote:

Mladen Turk wrote:

-1 (or if you wish veto)


Releases can't be voted. The 3 more +1s than -1s rule still applies though.



OK, it seems we have problem here.
Did you read what I said? There is no such thing
as *tomcat-native release*, period, so
there is no thing we can vote for.
There is no Tomcat NIO, HTTP or AJP connector release as well.
The only small difference is that the first one is
written in C, while rest are written in Java.
This is one and only difference.


There is no such thing as tomcat-native product that
we can vote for.


What are all these then?
http://tomcat.heanet.ie/native/



Ask the US government and their crypto law :)

Regards,
Mladen



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

Re: Native 1.1.12 release

[Mark Thomas]

Mladen Turk wrote:

It would mean that you will need *nix for building
the Tomcat release, but that's fine with me.

If the Tomcat RM's are fine with that, it's a very
simple task.


That means we require the release to be built on Windows so we can built 
the installer and on *nix for native. Essentially we need would need to 
build every distribution on two platforms. Whilst it is manageable, that 
strikes me significantly increasing the risk of their being subtle 
differences between the Windows and Linux distributions.


I still don't see why we can't just do a native release in the same way we 
do a mod_jk release. That wouldn't stop us bundling a particular native 
release with a Tomcat release and it allows users to easily update the 
native library if there are any serious bugs. It would mean there is a 
greater requirement to keep the interface stable but I don't see that as a 
major issue.


Mark


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

Re: [VOTE] Release Tomcat native 1.1.12

[Mark Thomas]

Mladen Turk wrote:

-1 (or if you wish veto)


Releases can't be voted. The 3 more +1s than -1s rule still applies though.


There is no such thing as tomcat-native product that
we can vote for.


What are all these then?
http://tomcat.heanet.ie/native/


Tomcat-native is integral part of Tomcat, so we cannot
vote on Tomcat's jsp engine, or its NIO connector.


There seems to be little difference between the native connectors and 
mod_jk to me.


I don't understand what the arguments are against separate native releases.

Mark


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

Re: [VOTE] Release Tomcat native 1.1.12

[Mladen Turk]

Mark Thomas wrote:

The source distributions are here:

http://www.apache.org/dist/tomcat/tomcat-connectors/native/tomcat-native-1.1.12-src.tar.gz 

http://www.apache.org/dist/tomcat/tomcat-connectors/native/tomcat-native-1.1.12-win32-src.zip 



According to the release process, the 1.1.12 tarball is:
[ ] Broken
[ ] Alpha
[ ] Beta
[ ] Stable



-1 (or if you wish veto)

There is no such thing as tomcat-native product that
we can vote for.
Tomcat-native is integral part of Tomcat, so we cannot
vote on Tomcat's jsp engine, or its NIO connector.



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

Re: Native 1.1.12 release

[Mladen Turk]

Filip Hanik - Dev Lists wrote:
you're other option is to just vote on tcnative separately, and that way 
utilize all the ASF mirrors and release sites




But that is exactly what we should *not* do.
Tomcat comes with it's native, so if you upgrade the
Tomcat, upgrade its native as well (if changed)

Like said, all that can be easy done by simply
extending requirements for building Tomcat release.
One will need Python and a set of GNU build tools,
and we can easily forget the native helper tarballs.

It would mean that you will need *nix for building
the Tomcat release, but that's fine with me.

If the Tomcat RM's are fine with that, it's a very
simple task.


Regards,
Mladen

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

[VOTE] Release Tomcat native 1.1.12

[Mark Thomas]

The source distributions are here:

http://www.apache.org/dist/tomcat/tomcat-connectors/native/tomcat-native-1.1.12-src.tar.gz
http://www.apache.org/dist/tomcat/tomcat-connectors/native/tomcat-native-1.1.12-win32-src.zip 



According to the release process, the 1.1.12 tarball is:
[ ] Broken
[ ] Alpha
[ ] Beta
[ ] Stable

Cheers,

Mark

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

Re: Native 1.1.12 release

[Mark Thomas]

Filip Hanik - Dev Lists wrote:
you're other option is to just vote on tcnative separately, and that way 
utilize all the ASF mirrors and release sites


A vote seems to be the quickest and best solution along with standard 
releases (like mod_jk) going forward.


It isn't like there is a lack of people ready to vote +1 on this. We just 
need the vote thread.


(IANAL - my terminology may not be spot on)
Until there is a vote all of the legal liability associated with the 
release sits with the person who copied the code into www.a.o/dist rather 
than with the ASF. Once we have a vote, the release is official and if 
there are any problems it is the ASF that gets sued.


Therefore, in the interests of fixing the legal issues ASAP I'll call a 
vote in a separate thread.


Mark


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

Re: Native 1.1.12 release

[Mladen Turk]

William A. Rowe, Jr. wrote:

Mladen Turk wrote:


OK if you insist.


The *Foundation* insists ;-)


OK ;)




I suppose we can then use the src tarball from the heanet.ie
site (used by the installer BTW) instead dist site.


Or you can remove the file to /dev/dist/, and hold a release vote already?

 > Or we can have it inside
 > http://tomcat.apache.org/dev/dist/tomcat-connectors/

/dev/dist/ should be for files that will (ultimately) be released,
or taken down when they fail to garner the necessary votes.  That
area should not become a clearinghouse - trust me, I've seen it
happen to snapshots I'd created.  It's not for 'public consumption'.



The whole problem is miss understanding.
Those files are merely helper files for building Tomcat.
They are not, nor ever be released. They are released together
with Tomcat as tomcat-native.tar.gz inside /bin

I've moved the 1.1.12 and 1.1.10 native connector tag tarballs to
the tomcat/dev/dist.
I'll later change the build.properties.default to point to that
new location. Since it's used only for building Tomcat dist, the
actual url holding them is irrelevant.

Regards,
Mladen

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

Re: Native 1.1.12 release

[Filip Hanik - Dev Lists]

you're other option is to just vote on tcnative separately, and that way 
utilize all the ASF mirrors and release sites


Filip

Mladen Turk wrote:

Mark Thomas wrote:

Mladen Turk wrote:

Henri Gomez wrote:

No, like said, Tomcat Native is voted *together*
with Tomcat version that contains it.


May be but the version numbers are different.

It seems very similar to mod_jk in my opinion, since it's a part of
Tomcat but not mandatory.



But it's not. We don't have announce for Tomcat Native (so no release)


Sorry, no. src tarball on dist == release. No ifs ands or buts.

There needs to be a vote or the invalid release needs to be pulled.



OK if you insist.
I suppose we can then use the src tarball from the heanet.ie
site (used by the installer BTW) instead dist site.
Or we can have it inside 
http://tomcat.apache.org/dev/dist/tomcat-connectors/


It's just a line inside build.properties file.
The latest would probably reflect the purpose of the file
more properly thought.

Regards,
Mladen

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






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

Re: Native 1.1.12 release

[William A. Rowe, Jr.]

Mladen Turk wrote:


OK if you insist.


The *Foundation* insists ;-)


I suppose we can then use the src tarball from the heanet.ie
site (used by the installer BTW) instead dist site.


Or you can remove the file to /dev/dist/, and hold a release vote already?

> Or we can have it inside
> http://tomcat.apache.org/dev/dist/tomcat-connectors/

/dev/dist/ should be for files that will (ultimately) be released,
or taken down when they fail to garner the necessary votes.  That
area should not become a clearinghouse - trust me, I've seen it
happen to snapshots I'd created.  It's not for 'public consumption'.

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

Re: Native 1.1.12 release

[Mladen Turk]

Mark Thomas wrote:

Mladen Turk wrote:

Henri Gomez wrote:

No, like said, Tomcat Native is voted *together*
with Tomcat version that contains it.


May be but the version numbers are different.

It seems very similar to mod_jk in my opinion, since it's a part of
Tomcat but not mandatory.



But it's not. We don't have announce for Tomcat Native (so no release)


Sorry, no. src tarball on dist == release. No ifs ands or buts.

There needs to be a vote or the invalid release needs to be pulled.



OK if you insist.
I suppose we can then use the src tarball from the heanet.ie
site (used by the installer BTW) instead dist site.
Or we can have it inside http://tomcat.apache.org/dev/dist/tomcat-connectors/

It's just a line inside build.properties file.
The latest would probably reflect the purpose of the file
more properly thought.

Regards,
Mladen

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

svn commit: r611941 - /tomcat/tc6.0.x/trunk/STATUS.txt

[markt]

Author: markt
Date: Mon Jan 14 13:23:59 2008
New Revision: 611941

URL: http://svn.apache.org/viewvc?rev=611941&view=rev
Log:
Propose release note update

Modified:
tomcat/tc6.0.x/trunk/STATUS.txt

Modified: tomcat/tc6.0.x/trunk/STATUS.txt
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS.txt?rev=611941&r1=611940&r2=611941&view=diff
==
--- tomcat/tc6.0.x/trunk/STATUS.txt (original)
+++ tomcat/tc6.0.x/trunk/STATUS.txt Mon Jan 14 13:23:59 2008
@@ -71,3 +71,8 @@
   http://svn.apache.org/viewvc?rev=611637&view=rev
   +1: markt
   -1:
+
+  Update release notes with available libraries
+  http://svn.apache.org/viewvc?rev=611940&view=rev
+  +1: markt
+  -1: 



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

svn commit: r611940 - /tomcat/trunk/RELEASE-NOTES

[markt]

Author: markt
Date: Mon Jan 14 13:22:09 2008
New Revision: 611940

URL: http://svn.apache.org/viewvc?rev=611940&view=rev
Log:
Update to available libraries

Modified:
tomcat/trunk/RELEASE-NOTES

Modified: tomcat/trunk/RELEASE-NOTES
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/RELEASE-NOTES?rev=611940&r1=611939&r2=611940&view=diff
==
--- tomcat/trunk/RELEASE-NOTES (original)
+++ tomcat/trunk/RELEASE-NOTES Mon Jan 14 13:22:09 2008
@@ -85,11 +85,10 @@
 * catalina-ant.jar (Tomcat Catalina Ant tasks)
 * catalina-ha.jar (High availability package)
 * catalina-tribes.jar (Group communication)
-* commons-logging-api.jar (Commons Logging API 1.0.x)
 * el-api.jar (EL 2.1 API)
 * jasper.jar (Jasper 2 Compiler and Runtime)
 * jasper-el.jar (Jasper 2 EL implementation)
-* jasper-jdt.jar (Eclipse JDT 3.2 Java compiler)
+* jasper-jdt.jar (Eclipse JDT 3.3 Java compiler)
 * jsp-api.jar (JSP 2.1 API)
 * servlet-api.jar (Servlet 2.5 API)
 * tomcat-coyote.jar (Tomcat connectors and utility classes)



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

DO NOT REPLY [Bug 44223] - Tomcat ignores the "javax.net.ssl.trustStoreType" system property

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=44223


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX




--- Additional Comments From [EMAIL PROTECTED]  2008-01-14 13:13 ---
Tomcat ignores any of the SSL configuration system properties.

I was going to say it has always been this way, I didn't know why and if you
provided a patch that addressed all of them it would be considered.

However, my brain is now in gear and the problem seems obvious. When using
system properties for configuration then everything is fine until two components
require conflicting settings. In a container environment this pretty much a
given. We had a similar issue with logging which is why Remy wrote JULI.

Therefore, I am marking this as a WONTFIX on the grounds I see it causing more
problems than it solves.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

svn commit: r611929 - in /tomcat/connectors/trunk/jk: native/apache-1.3/mod_jk.c native/apache-2.0/mod_jk.c xdocs/miscellaneous/changelog.xml

[rjung]

Author: rjung
Date: Mon Jan 14 12:59:12 2008
New Revision: 611929

URL: http://svn.apache.org/viewvc?rev=611929&view=rev
Log:
JkAutoAlias does not work in combination with JkMountCopy
if there are no Jk(Un)Mount in virtual host.

Modified:
tomcat/connectors/trunk/jk/native/apache-1.3/mod_jk.c
tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c
tomcat/connectors/trunk/jk/xdocs/miscellaneous/changelog.xml

Modified: tomcat/connectors/trunk/jk/native/apache-1.3/mod_jk.c
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/apache-1.3/mod_jk.c?rev=611929&r1=611928&r2=611929&view=diff
==
--- tomcat/connectors/trunk/jk/native/apache-1.3/mod_jk.c (original)
+++ tomcat/connectors/trunk/jk/native/apache-1.3/mod_jk.c Mon Jan 14 12:59:12 
2008
@@ -2408,6 +2408,8 @@
 }
 if (!overrides->mount_file)
 overrides->mount_file = base->mount_file;
+}
+if (overrides->mountcopy == JK_TRUE) {
 if (!overrides->alias_dir)
 overrides->alias_dir = base->alias_dir;
 }

Modified: tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c?rev=611929&r1=611928&r2=611929&view=diff
==
--- tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c (original)
+++ tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c Mon Jan 14 12:59:12 
2008
@@ -2543,6 +2543,8 @@
 }
 if (!overrides->mount_file)
 overrides->mount_file = base->mount_file;
+}
+if (overrides->mountcopy == JK_TRUE) {
 if (!overrides->alias_dir)
 overrides->alias_dir = base->alias_dir;
 }

Modified: tomcat/connectors/trunk/jk/xdocs/miscellaneous/changelog.xml
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/xdocs/miscellaneous/changelog.xml?rev=611929&r1=611928&r2=611929&view=diff
==
--- tomcat/connectors/trunk/jk/xdocs/miscellaneous/changelog.xml (original)
+++ tomcat/connectors/trunk/jk/xdocs/miscellaneous/changelog.xml Mon Jan 14 
12:59:12 2008
@@ -43,6 +43,10 @@
   
   
 
+  
+Apache: JkAutoAlias does not work in combination with JkMountCopy
+if there are no JkMount in virtual host. (rjung)
+  
   
 LB: Optimize state macros to improve performance. (rjung)
   



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

DO NOT REPLY [Bug 44225] - SSL connector tries to load the private keystore file after privileges have already been dropped by JSVC

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=44225


[EMAIL PROTECTED] changed:

   What|Removed |Added

   Severity|normal  |enhancement




--- Additional Comments From [EMAIL PROTECTED]  2008-01-14 12:51 ---
This sounds like an enhancement some users would want. Of course, it only works
if the key is read once and kept in memory - which I assume it is but haven't
checked.

As always, patches are welcome. I don't know this part of the code well enough
to know how big the patch is likely to be.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 44215] - jkunmount causes apache to throw permission denied error

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=44215


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|NEEDINFO




--- Additional Comments From [EMAIL PROTECTED]  2008-01-14 12:45 ---
I tested your setup. I have two different types of answers.

Part I: Questioning your setup

There are two things, which are in conflict in your setup:

- you set a JkAutoAlias. This says: if there is a JkMount in a vhost, but a 
request does not match, then look for the file below the directory given in the 
JkAutoAlias.

- you say, that the file does *not* exist in the appropriate sub directory of 
the directory given in JkAutoAlias, and instead it exists below the 
DocumentRoot.

So it looks like you want to serve the static content from the DocumentRoot. In 
this case simply remove the JkAutoAlias.


Part II: Testing your setup

1) JK version 1.2.21 as indicated in your first post: when requesting

http://www.examples.com/selfservice/images/welcome.gif

the config resolves this to

- do not forward to Tomcat
- use the JkAutoAlias
- return with file /usr/share/tomcat5/webapps/selfservice/images/welcome.gif

As you can see from Part I, this works as desinged. It actually works with or 
without JkMountCopy. No rewrite rule needed. The Jk log shows debug log lines

... [16927:0006] [debug] jk_translate::mod_jk.c (2878): check 
alias_dir: /usr/share/tomcat5/webapps
... [16927:0006] [debug] jk_translate::mod_jk.c (2904): AutoAlias child_dir: 
test.html
... [16927:0006] [debug] jk_translate::mod_jk.c (2939): AutoAlias OK for 
file: /usr/share/tomcat5/webapps/selfservice/test.html

The fact, that it works without JkMountCopy is a bug in 1.2.21.

2) Version 1.2.26: does *not* work either with or without JkMountCopy. Should 
work with JkMountCopy, but does not, because when cleaning up the mount 
handling in vhosts, we treated JkAutoAlias wrong :(

So: which version are you actually testing against? Is it still really 1.2.21, 
like you posted in your first message?

Concerning 1.2.26, the following patch against 1.2.26 should do the trick:

--- mod_jk.c.orig   2007-12-14 19:50:44.0 +0100
+++ mod_jk.c2008-01-14 21:28:01.0 +0100
@@ -2551,6 +2551,8 @@
 }
 if (!overrides->mount_file)
 overrides->mount_file = base->mount_file;
+}
+if (overrides->mountcopy == JK_TRUE) {
 if (!overrides->alias_dir)
 overrides->alias_dir = base->alias_dir;
 }

Questions:

- which jk version?
- do you want to serve the files from the DocumentRoot or from the JkAutoAlias 
directory?
- does the file exist there?
- if you only request one of those static files, what's the jk debog log output?


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 44227] - Space

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=44227


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID




--- Additional Comments From [EMAIL PROTECTED]  2008-01-14 12:21 ---
Please do not use our Bugzilla server in this way. It is open to the public to
enable the public to report bugs, not to provide a sandbox for people to
experiment with.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

Re: Native 1.1.12 release

[Mark Thomas]

Mladen Turk wrote:

Henri Gomez wrote:

No, like said, Tomcat Native is voted *together*
with Tomcat version that contains it.


May be but the version numbers are different.

It seems very similar to mod_jk in my opinion, since it's a part of
Tomcat but not mandatory.



But it's not. We don't have announce for Tomcat Native (so no release)


Sorry, no. src tarball on dist == release. No ifs ands or buts.

There needs to be a vote or the invalid release needs to be pulled.

Mark


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

May Chun Chew/FEA/PEC is out of the office.

[May Chun Chew]

I will be out of the office starting  01/15/2008 and will not return until
01/16/2008.

For urgent matters, pls contact [EMAIL PROTECTED] Tel:
(65)63629408
I am also Contactable at (65)97876648.


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

DO NOT REPLY [Bug 44215] - jkunmount causes apache to throw permission denied error

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=44215


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|WORKSFORME  |




--- Additional Comments From [EMAIL PROTECTED]  2008-01-14 11:10 ---
Thanks for your response.  The image files and jsp files are both under the
/usr/share/tomcat5/webapps/selfservice directory.  For performance improvement,
we want to serve the static files directly from apache, but jsp files from
tomcat.  That's why we need to have JkAutoAlias /usr/share/tomcat5/webapps in
the conf file.

Here is what we see:
We request the URL http://www.examples.com/selfservice/images/welcome.gif, but
we got permission denied error:

***
[Mon Jan 14 10:50:01 2008] [notice] Apache/2.0.52 (Red Hat) configured --
resuming normal operations
[Mon Jan 14 10:50:39 2008] [error] [client 171.64.19.235] (13)Permission denied:
access to /selfservice/images/welcome.gif denied
*** 
 

Note there is no welcome.gif file in
/usr/share/tomcat5/webapps/selfservice/image (we removed it), but there is one
in /var/www/html/selfservice/images.  The file permission on
/var/www/html/selfservice/images is OK because if we use mod_rewrite the files
are served correctly.

We added "JkMountCopy On" in virtual host directive as you suggested, but it
made no difference.

Here is the current conf file:

*
DocumentRoot /var/www/html

# load mod_jk
#LoadModule jk_module modules/mod_jk.so
JkWorkersFile "/etc/httpd/workers.properties"
JkLogFile "/var/log/httpd/mod_jk.log"
JkLogLevel debug
JkAutoAlias /usr/share/tomcat5/webapps
JkMount /selfservice/* worker1
JkUnMount /selfservice/*.html worker1
JkUnMount /selfservice/*.jpg  worker1
JkUnMount /selfservice/*.gif  worker1


ServerName  www.examples.com
ServerAlias examples
JkMountCopy On
DocumentRoot /var/www/html




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

svn commit: r611877 - in /tomcat/connectors/trunk/jk: native/common/jk_lb_worker.c native/common/jk_lb_worker.h xdocs/miscellaneous/changelog.xml

[rjung]

Author: rjung
Date: Mon Jan 14 10:28:34 2008
New Revision: 611877

URL: http://svn.apache.org/viewvc?rev=611877&view=rev
Log:
Optimize state macros n LB to improve performance.
The new macros are equivalent to the old ones, as long
as the constant value sused are sorted correctly.
The new macros should be faster, because they contain
fewer comparisons.

Modified:
tomcat/connectors/trunk/jk/native/common/jk_lb_worker.c
tomcat/connectors/trunk/jk/native/common/jk_lb_worker.h
tomcat/connectors/trunk/jk/xdocs/miscellaneous/changelog.xml

Modified: tomcat/connectors/trunk/jk/native/common/jk_lb_worker.c
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/common/jk_lb_worker.c?rev=611877&r1=611876&r2=611877&view=diff
==
--- tomcat/connectors/trunk/jk/native/common/jk_lb_worker.c (original)
+++ tomcat/connectors/trunk/jk/native/common/jk_lb_worker.c Mon Jan 14 10:28:34 
2008
@@ -40,8 +40,18 @@
  * The load balancing code in this
  */
 
-#define JK_WORKER_USABLE(w)   ((w)->s->state != JK_LB_STATE_ERROR && 
(w)->s->state != JK_LB_STATE_PROBE && (w)->s->state != JK_LB_STATE_BUSY && 
(w)->activation != JK_LB_ACTIVATION_STOPPED && (w)->activation != 
JK_LB_ACTIVATION_DISABLED)
-#define JK_WORKER_USABLE_STICKY(w)   ((w)->s->state != JK_LB_STATE_ERROR && 
(w)->s->state != JK_LB_STATE_PROBE && (w)->activation != 
JK_LB_ACTIVATION_STOPPED)
+/*
+ * The following two macros need to be kept in sync with
+ * the existing values for state and activation.
+ * Note: state <= JK_LB_STATE_FORCE is equivalent to
+ *   state is none of JK_LB_STATE_BUSY, JK_LB_STATE_ERROR, 
JK_LB_STATE_PROBE
+ * Note: state <= JK_LB_STATE_BUSY is equivalent to
+ *   state is none of JK_LB_STATE_ERROR, JK_LB_STATE_PROBE
+ * Note: activation == JK_LB_ACTIVATION_ACTIVE is equivalent to
+ *   activation is none of JK_LB_ACTIVATION_STOPPED, 
JK_LB_ACTIVATION_DISABLED
+ */
+#define JK_WORKER_USABLE(w)   ((w)->s->state <= JK_LB_STATE_FORCE && 
(w)->activation == JK_LB_ACTIVATION_ACTIVE)
+#define JK_WORKER_USABLE_STICKY(w)   ((w)->s->state <= JK_LB_STATE_BUSY && 
(w)->activation != JK_LB_ACTIVATION_STOPPED)
 
 static const char *lb_locking_type[] = {
 JK_LB_LOCK_TEXT_OPTIMISTIC,

Modified: tomcat/connectors/trunk/jk/native/common/jk_lb_worker.h
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/common/jk_lb_worker.h?rev=611877&r1=611876&r2=611877&view=diff
==
--- tomcat/connectors/trunk/jk/native/common/jk_lb_worker.h (original)
+++ tomcat/connectors/trunk/jk/native/common/jk_lb_worker.h Mon Jan 14 10:28:34 
2008
@@ -58,20 +58,27 @@
 #define JK_LB_LOCK_TEXT_OPTIMISTIC ("Optimistic")
 #define JK_LB_LOCK_TEXT_PESSIMISTIC("Pessimistic")
 #define JK_LB_LOCK_TEXT_DEF(JK_LB_LOCK_TEXT_OPTIMISTIC)
+/*
+ * The following definitions for state and activation
+ * need to be kept in sync with the two macros 
+ * JK_WORKER_USABLE() and JK_WORKER_USABLE_STICKY() in jk_lb_worker.c.
+ * Since we use ordered comparisons there instead of multiple
+ * equal/unequal compares, order of the values is critical here.
+ */
 #define JK_LB_STATE_IDLE   (0)
 #define JK_LB_STATE_OK (1)
 #define JK_LB_STATE_RECOVER(2)
-#define JK_LB_STATE_BUSY   (3)
-#define JK_LB_STATE_ERROR  (4)
-#define JK_LB_STATE_FORCE  (5)
+#define JK_LB_STATE_FORCE  (3)
+#define JK_LB_STATE_BUSY   (4)
+#define JK_LB_STATE_ERROR  (5)
 #define JK_LB_STATE_PROBE  (6)
 #define JK_LB_STATE_DEF(JK_LB_STATE_IDLE)
 #define JK_LB_STATE_TEXT_IDLE  ("OK/IDLE")
 #define JK_LB_STATE_TEXT_OK("OK")
 #define JK_LB_STATE_TEXT_RECOVER   ("ERR/REC")
 #define JK_LB_STATE_TEXT_BUSY  ("OK/BUSY")
-#define JK_LB_STATE_TEXT_ERROR ("ERR")
 #define JK_LB_STATE_TEXT_FORCE ("ERR/FRC")
+#define JK_LB_STATE_TEXT_ERROR ("ERR")
 #define JK_LB_STATE_TEXT_PROBE ("ERR/PRB")
 #define JK_LB_STATE_TEXT_MAX   (JK_LB_STATE_PROBE)
 #define JK_LB_STATE_TEXT_DEF   (JK_LB_STATE_TEXT_IDLE)

Modified: tomcat/connectors/trunk/jk/xdocs/miscellaneous/changelog.xml
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/xdocs/miscellaneous/changelog.xml?rev=611877&r1=611876&r2=611877&view=diff
==
--- tomcat/connectors/trunk/jk/xdocs/miscellaneous/changelog.xml (original)
+++ tomcat/connectors/trunk/jk/xdocs/miscellaneous/changelog.xml Mon Jan 14 
10:28:34 2008
@@ -44,6 +44,9 @@
   
 
   
+LB: Optimize state macros to improve performance. (rjung)
+  
+  
 Apache: Allow dynamic setting of reply timeout using the environment
 variable JK_REPLY_TIMEOUT. (rjung)
   



---

DO NOT REPLY [Bug 44227] New: - Space

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=44227

   Summary: Space
   Product: Tomcat 5
   Version: Unknown
  Platform: PC
OS/Version: Windows Vista
Status: NEW
  Severity: normal
  Priority: P2
 Component: Tester
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


 

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

Re: Is Tomcat5.0 FIPS compliant?

[William A. Rowe, Jr.]

robingandhi21 wrote:


Info regarding FIPS is:The Federal Information Processing Standard 140-1
(FIPS 140-1) and its successor FIPS 140-2 are United States Government
standards that provide a benchmark for implementing cryptographic software.
They specify best practices for implementing crypto algorithms, handling key
material and data buffers, and working with the operating system.


It's a boolean, a certificate is issued or it's not.

http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm

demonstrates one provider, IBM JSSE 1.1 operating in FIPS mode, that
has that FIPS-140-2 certification, along with a host of hardware
solutions.  I didn't see any other JSSE provider, but didn't read it
that closely for you.

Tomcat doesn't implement cryptography but consumes a crypto provider,
so you have to look at the underlying components, or configure a
solution leveraging FIPS certified hardware, which is why your post
didn't garner much attention from Tomcat devs.

Bill

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

DO NOT REPLY [Bug 44225] New: - SSL connector tries to load the private keystore file after privileges have already been dropped by JSVC

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=44225

   Summary: SSL connector tries to load the private keystore file
after privileges have already been dropped by JSVC
   Product: Tomcat 6
   Version: 6.0.14
  Platform: Other
OS/Version: other
Status: NEW
  Severity: normal
  Priority: P2
 Component: Connectors
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


The keystore file containing the private server key should be kept in a secure 
location readable only by root. But if you run Tomcat under a less privileged 
user, this prevents you from using this key for the Tomcat SSL Connector.

You are left with two choices: either make the keystore readable to the Tomcat 
user, or run Tomcat permanently as root, neither of which is appealing from 
security point of view.

Now, Tomcat supports Commons Daemon (JSVC), which allows it to be started on 
privileged ports (such as 80 or 443) while not having to run as root all the 
time. It does it by splitting initialization into "load" and "start" phases, 
where the "load" phase runs as root in order to acquire the privileged 
resources, while the "start" phase runs after dropping privileges.

Unfortunately, the privileged "load" phase currently only binds the privileged 
ports. I propose to also move the loading of keystore files to this privileged 
"load" phase, so that private keystore files can be kept in a secure location, 
while Tomcat runs as non-privileged user.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 44223] - Tomcat ignores the "javax.net.ssl.trustStoreType" system property

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=44223





--- Additional Comments From [EMAIL PROTECTED]  2008-01-14 04:26 ---
Created an attachment (id=21383)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=21383&action=view)
simple fix


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 44223] New: - Tomcat ignores the "javax.net.ssl.trustStoreType" system property

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=44223

   Summary: Tomcat ignores the "javax.net.ssl.trustStoreType" system
property
   Product: Tomcat 6
   Version: 6.0.14
  Platform: Other
OS/Version: other
Status: NEW
  Severity: normal
  Priority: P2
 Component: Connectors
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Set up a SSL Connector with a keystore in JKS format:



Let's say you need a custom truststore (e.g. for authenticating self-signed 
client certificates), and that this truststore is also needed by some of your 
webapps, not only Tomcat. The natural thing to do then is to configure this 
truststore globally for the whole JVM, not in server.xml.

Let's also assume this truststore is in a different format (e.g. PKCS#12). So 
before starting Tomcat, you do this:

export JAVA_OPTS="-Djavax.net.ssl.trustStore=trusted.keystore -
Djavax.net.ssl.trustStoreType=PKCS12"

Well, it doesn't work. If you look at tomcat/logs/catalina.out, you will see a 
keystore-related exception. Upon further debugging, you will discover the 
problem is that Tomcat is trying to open the truststore as if it were in JKS 
format, even though it is clearly specified as type PKCS12 in JAVA_OPTS above.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

Re: svn commit: r611696 - in /tomcat/connectors/trunk/jk: native/apache-1.3/ native/apache-2.0/ native/common/ xdocs/generic_howto/ xdocs/miscellaneous/ xdocs/reference/

[Rainer Jung]

Hi Peter,

sometimes the nice things are the easy ones :)

In fact I *don't* want to open a can of worms by letting the web server 
overwrite many worker attributes, but reply_timeout is the one with a 
very strong dependency on the URL. All others, except maybe for 
fail_on_status are not really request dependant.


Have fun!

Rainer

Peter Rossbach schrieb:

Hi Rainer,

many thanks for that cool feature ;-)

Peter


Am 14.01.2008 um 03:28 schrieb [EMAIL PROTECTED]:


Author: rjung
Date: Sun Jan 13 18:28:27 2008
New Revision: 611696

URL: http://svn.apache.org/viewvc?rev=611696&view=rev
Log:
Allow dynamic setting of reply timeout using the httpd environment
variable JK_REPLY_TIMEOUT.

Modified:
tomcat/connectors/trunk/jk/native/apache-1.3/mod_jk.c
tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c
tomcat/connectors/trunk/jk/native/common/jk_ajp_common.c
tomcat/connectors/trunk/jk/native/common/jk_service.h
tomcat/connectors/trunk/jk/native/common/jk_util.c
tomcat/connectors/trunk/jk/xdocs/generic_howto/timeouts.xml
tomcat/connectors/trunk/jk/xdocs/miscellaneous/changelog.xml
tomcat/connectors/trunk/jk/xdocs/reference/workers.xml

Modified: tomcat/connectors/trunk/jk/native/apache-1.3/mod_jk.c
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/apache-1.3/mod_jk.c?rev=611696&r1=611695&r2=611696&view=diff 

== 


--- tomcat/connectors/trunk/jk/native/apache-1.3/mod_jk.c (original)
+++ tomcat/connectors/trunk/jk/native/apache-1.3/mod_jk.c Sun Jan 13 
18:28:27 2008

@@ -70,6 +70,7 @@
 #define JK_ENV_SESSION  ("SSL_SESSION_ID")
 #define JK_ENV_KEY_SIZE ("SSL_CIPHER_USEKEYSIZE")
 #define JK_ENV_CERTCHAIN_PREFIX ("SSL_CLIENT_CERT_CHAIN_")
+#define JK_ENV_REPLY_TIMEOUT("JK_REPLY_TIMEOUT")
 #define JK_ENV_WORKER_NAME  ("JK_WORKER_NAME")
 #define JK_NOTE_WORKER_NAME ("JK_WORKER_NAME")
 #define JK_NOTE_WORKER_TYPE ("JK_WORKER_TYPE")
@@ -610,6 +611,7 @@
 int size;
 request_rec *r = private_data->r;
 char *ssl_temp = NULL;
+const char *reply_timeout = NULL;

 /* Copy in function pointers (which are really methods) */
 s->start_response = ws_start_response;
@@ -639,6 +641,10 @@
 s->flush_packets = 1;
 if (conf->options & JK_OPT_FLUSHEADER)
 s->flush_header = 1;
+
+reply_timeout = apr_table_get(r->subprocess_env, 
"JK_REPLY_TIMEOUT");

+if (reply_timeout)
+s->reply_timeout = atoi(reply_timeout);

 if (conf->options & JK_OPT_DISABLEREUSE)
 s->disable_reuse = 1;

Modified: tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c?rev=611696&r1=611695&r2=611696&view=diff 

== 


--- tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c (original)
+++ tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c Sun Jan 13 
18:28:27 2008

@@ -112,6 +112,7 @@
 #define JK_ENV_SESSION  ("SSL_SESSION_ID")
 #define JK_ENV_KEY_SIZE ("SSL_CIPHER_USEKEYSIZE")
 #define JK_ENV_CERTCHAIN_PREFIX ("SSL_CLIENT_CERT_CHAIN_")
+#define JK_ENV_REPLY_TIMEOUT("JK_REPLY_TIMEOUT")
 #define JK_ENV_WORKER_NAME  ("JK_WORKER_NAME")
 #define JK_NOTE_WORKER_NAME ("JK_WORKER_NAME")
 #define JK_NOTE_WORKER_TYPE ("JK_WORKER_TYPE")
@@ -621,10 +622,10 @@
 static int init_ws_service(apache_private_data_t * private_data,
jk_ws_service_t *s, jk_server_conf_t * conf)
 {
+int size;
 request_rec *r = private_data->r;
-
 char *ssl_temp = NULL;
-int size;
+const char *reply_timeout = NULL;

 /* Copy in function pointers (which are really methods) */
 s->start_response = ws_start_response;
@@ -652,6 +653,10 @@
 s->flush_packets = 1;
 if (conf->options & JK_OPT_FLUSHEADER)
 s->flush_header = 1;
+
+reply_timeout = apr_table_get(r->subprocess_env, 
"JK_REPLY_TIMEOUT");

+if (reply_timeout)
+s->reply_timeout = atoi(reply_timeout);

 if (conf->options & JK_OPT_DISABLEREUSE)
 s->disable_reuse = 1;

Modified: tomcat/connectors/trunk/jk/native/common/jk_ajp_common.c
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/common/jk_ajp_common.c?rev=611696&r1=611695&r2=611696&view=diff 

== 


--- tomcat/connectors/trunk/jk/native/common/jk_ajp_common.c (original)
+++ tomcat/connectors/trunk/jk/native/common/jk_ajp_common.c Sun Jan 
13 18:28:27 2008

@@ -1815,10 +1815,14 @@
 /* Start read all reply message */
 while (1) {
 int rc = 0;
+/* Allow to overwrite reply_timeout on a per URL basis via 
service struct */

+int reply_timeout = s->reply_timeout;

+if (reply_timeout < 0)
+

Re: svn commit: r609294 - in /tomcat/tc6.0.x/trunk: STATUS.txt conf/catalina.policy webapps/docs/changelog.xml

[Remy Maucherat]

On Sun, 2008-01-13 at 22:38 +, Mark Thomas wrote:
> Remy Maucherat wrote:
> > On Fri, 2008-01-11 at 13:27 -0500, Larry Isaacs wrote:
> >>> I used java.security.debug=failure. The NPE isn't visible without it
> >>> (and nothing gets logged). I also did try adding various file
> >>> permissions, without much success.
> >>>
> >>> Rémy
> >>>
> >> If I recall correctly, the "failure" option unfortunately doesn't do
> >> anything by itself.  I believe you have to have "access" enabled before
> >> it will include any failures, i.e "java.security.debug=access,failure".
> >> There's no avoiding the huge log file. :(
> > 
> > Actually, it's quite funny since the NPEs do not occur with
> > "access,failure", and no accesses are reported as denied (but of course,
> > there's still no logging).
> 
> Hmm. Very odd. A bug in the JDK maybe?

Ok, I just found the reason: a packaging issue of my own, causing the
weird error :( Sorry for the trouble.

Rémy



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

Re: Native 1.1.12 release

[Mladen Turk]

Henri Gomez wrote:

No, like said, Tomcat Native is voted *together*
with Tomcat version that contains it.


May be but the version numbers are different.

It seems very similar to mod_jk in my opinion, since it's a part of
Tomcat but not mandatory.



But it's not. We don't have announce for Tomcat Native (so no release),
and tomcat-native.tar.gz (created from tomcat-native-x.x.x.tar.gz)
is integral part of tomcat-x.x.x.tar.gz distribution, referenced
by the build.properties.
So we need tomcat-native.x.x.x.tar.gz to be able to create the
tomcat-native.tar.gz. We could create tomcat-native.tar.gz
directly, but it would require set of native build tools,
so this is just convenient methodology of doing things.
Not to mention that windows installer would need windows
binaries created, etc.

Regards,
Mladen

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

Re: svn commit: r611696 - in /tomcat/connectors/trunk/jk: native/apache-1.3/ native/apache-2.0/ native/common/ xdocs/generic_howto/ xdocs/miscellaneous/ xdocs/reference/

[Peter Rossbach]

Hi Rainer,

many thanks for that cool feature ;-)

Peter


Am 14.01.2008 um 03:28 schrieb [EMAIL PROTECTED]:


Author: rjung
Date: Sun Jan 13 18:28:27 2008
New Revision: 611696

URL: http://svn.apache.org/viewvc?rev=611696&view=rev
Log:
Allow dynamic setting of reply timeout using the httpd environment
variable JK_REPLY_TIMEOUT.

Modified:
tomcat/connectors/trunk/jk/native/apache-1.3/mod_jk.c
tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c
tomcat/connectors/trunk/jk/native/common/jk_ajp_common.c
tomcat/connectors/trunk/jk/native/common/jk_service.h
tomcat/connectors/trunk/jk/native/common/jk_util.c
tomcat/connectors/trunk/jk/xdocs/generic_howto/timeouts.xml
tomcat/connectors/trunk/jk/xdocs/miscellaneous/changelog.xml
tomcat/connectors/trunk/jk/xdocs/reference/workers.xml

Modified: tomcat/connectors/trunk/jk/native/apache-1.3/mod_jk.c
URL: http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/ 
apache-1.3/mod_jk.c?rev=611696&r1=611695&r2=611696&view=diff
== 


--- tomcat/connectors/trunk/jk/native/apache-1.3/mod_jk.c (original)
+++ tomcat/connectors/trunk/jk/native/apache-1.3/mod_jk.c Sun Jan  
13 18:28:27 2008

@@ -70,6 +70,7 @@
 #define JK_ENV_SESSION  ("SSL_SESSION_ID")
 #define JK_ENV_KEY_SIZE ("SSL_CIPHER_USEKEYSIZE")
 #define JK_ENV_CERTCHAIN_PREFIX ("SSL_CLIENT_CERT_CHAIN_")
+#define JK_ENV_REPLY_TIMEOUT("JK_REPLY_TIMEOUT")
 #define JK_ENV_WORKER_NAME  ("JK_WORKER_NAME")
 #define JK_NOTE_WORKER_NAME ("JK_WORKER_NAME")
 #define JK_NOTE_WORKER_TYPE ("JK_WORKER_TYPE")
@@ -610,6 +611,7 @@
 int size;
 request_rec *r = private_data->r;
 char *ssl_temp = NULL;
+const char *reply_timeout = NULL;

 /* Copy in function pointers (which are really methods) */
 s->start_response = ws_start_response;
@@ -639,6 +641,10 @@
 s->flush_packets = 1;
 if (conf->options & JK_OPT_FLUSHEADER)
 s->flush_header = 1;
+
+reply_timeout = apr_table_get(r->subprocess_env,  
"JK_REPLY_TIMEOUT");

+if (reply_timeout)
+s->reply_timeout = atoi(reply_timeout);

 if (conf->options & JK_OPT_DISABLEREUSE)
 s->disable_reuse = 1;

Modified: tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c
URL: http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/ 
apache-2.0/mod_jk.c?rev=611696&r1=611695&r2=611696&view=diff
== 


--- tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c (original)
+++ tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c Sun Jan  
13 18:28:27 2008

@@ -112,6 +112,7 @@
 #define JK_ENV_SESSION  ("SSL_SESSION_ID")
 #define JK_ENV_KEY_SIZE ("SSL_CIPHER_USEKEYSIZE")
 #define JK_ENV_CERTCHAIN_PREFIX ("SSL_CLIENT_CERT_CHAIN_")
+#define JK_ENV_REPLY_TIMEOUT("JK_REPLY_TIMEOUT")
 #define JK_ENV_WORKER_NAME  ("JK_WORKER_NAME")
 #define JK_NOTE_WORKER_NAME ("JK_WORKER_NAME")
 #define JK_NOTE_WORKER_TYPE ("JK_WORKER_TYPE")
@@ -621,10 +622,10 @@
 static int init_ws_service(apache_private_data_t * private_data,
jk_ws_service_t *s, jk_server_conf_t *  
conf)

 {
+int size;
 request_rec *r = private_data->r;
-
 char *ssl_temp = NULL;
-int size;
+const char *reply_timeout = NULL;

 /* Copy in function pointers (which are really methods) */
 s->start_response = ws_start_response;
@@ -652,6 +653,10 @@
 s->flush_packets = 1;
 if (conf->options & JK_OPT_FLUSHEADER)
 s->flush_header = 1;
+
+reply_timeout = apr_table_get(r->subprocess_env,  
"JK_REPLY_TIMEOUT");

+if (reply_timeout)
+s->reply_timeout = atoi(reply_timeout);

 if (conf->options & JK_OPT_DISABLEREUSE)
 s->disable_reuse = 1;

Modified: tomcat/connectors/trunk/jk/native/common/jk_ajp_common.c
URL: http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/ 
common/jk_ajp_common.c?rev=611696&r1=611695&r2=611696&view=diff
== 

--- tomcat/connectors/trunk/jk/native/common/jk_ajp_common.c  
(original)
+++ tomcat/connectors/trunk/jk/native/common/jk_ajp_common.c Sun  
Jan 13 18:28:27 2008

@@ -1815,10 +1815,14 @@
 /* Start read all reply message */
 while (1) {
 int rc = 0;
+/* Allow to overwrite reply_timeout on a per URL basis via  
service struct */

+int reply_timeout = s->reply_timeout;

+if (reply_timeout < 0)
+reply_timeout = p->worker->reply_timeout;
 /* If we set a reply timeout, check if something is  
available */

-if (p->worker->reply_timeout > 0) {
-if (jk_is_input_event(p->sd, p->worker->reply_timeout,  
l) ==

+if (reply_timeout > 0) {
+if (jk_is_input_event(p->sd, reply_timeout, l) ==
  

Re: Native 1.1.12 release

[Henri Gomez]

> No, like said, Tomcat Native is voted *together*
> with Tomcat version that contains it.

May be but the version numbers are different.

It seems very similar to mod_jk in my opinion, since it's a part of
Tomcat but not mandatory.

Just my 0,01 EUR

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

Re: Native 1.1.12 release

[Mladen Turk]

Henri Gomez wrote:

Tomcat native is not separate product, but rather an integral
part of Tomcat distribution. The need for tag is needed because
we'd need to put some serious native part build (as well as tools)
when building Tomcat. Perhaps some day we'll do that, so we can
tag the Tomcat together with native, call the
buildconf.sh and create the native .tar.gz all at the same time.

Hope that explains.


Do we need to vote right now ?



No, like said, Tomcat Native is voted *together*
with Tomcat version that contains it.

The only reason to have a thing we call
"tomcat native version" is so that current and
history builds can be reproduced, because
demanding full set of native build tools for
building tomcat is unrealistic right now thought.

Regards,
Mladen

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

Re: Is Tomcat5.0 FIPS compliant?

[robingandhi21]

Hi 

Info regarding FIPS is:The Federal Information Processing Standard 140-1
(FIPS 140-1) and its successor FIPS 140-2 are United States Government
standards that provide a benchmark for implementing cryptographic software.
They specify best practices for implementing crypto algorithms, handling key
material and data buffers, and working with the operating system.

Please see if noe u can help?

gsexton wrote:
> 
> And which specific FIPS were you curious about?
> 
>>
>> Please let me know if anybody has an idea about tomcat5.0 being FIPS
>> compliant.
>>
>> Thanks in advance
>> Robin Gandhi
>> --
>> View this message in context:
>> http://www.nabble.com/Is-Tomcat5.0-FIPS-compliant--tp14773899p14773899.html
>> Sent from the Tomcat - Dev mailing list archive at Nabble.com.
>>
>>
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
> 
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Is-Tomcat5.0-FIPS-compliant--tp14773899p14797278.html
Sent from the Tomcat - Dev mailing list archive at Nabble.com.


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

Re: Native 1.1.12 release

[Henri Gomez]

> Tomcat native is not separate product, but rather an integral
> part of Tomcat distribution. The need for tag is needed because
> we'd need to put some serious native part build (as well as tools)
> when building Tomcat. Perhaps some day we'll do that, so we can
> tag the Tomcat together with native, call the
> buildconf.sh and create the native .tar.gz all at the same time.
>
> Hope that explains.

Do we need to vote right now ?

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