Re: svn commit: r565464 - in /tomcat/tc6.0.x/trunk/java/org/apache: catalina/connector/ catalina/startup/ coyote/ajp/ coyote/http11/ tomcat/util/ tomcat/util/digester/

2007-08-16 Thread Remy Maucherat

Bill Barker wrote:
Tomcat has never made any promise that the core API won't 
change between versions.  If you depend on the Tomcat API at any version 
level, then you are required to review at the next level.


There should be no backwards incompatible changes in my change. The only 
method signature which does change is in IntroUtils, to return a 
boolean. It is possible to add a setProperty2 method and revert 
setProperty to what it was.


-public static void setProperty(Object o, String name, String value) {
+public static boolean setProperty(Object o, String name, String 
value) {


The digester (if there was use of it despite the package renaming) 
should default to the old behavior.


Rémy

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



DO NOT REPLY [Bug 42983] - Creating a custom tag with an attribute named "class" causes exception

2007-08-16 Thread 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=42983


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID




--- Additional Comments From [EMAIL PROTECTED]  2007-08-16 04:36 ---
Every Java object has a getClass method, which returns a Class object that
indicates the object's type. Your getClass and/or setClass methods are
conflicting with the 'standard' getClass method.

Basically the introspector is seeing the standard getClass first, and sees
there's no matching setClass that takes a Class object. It therefore treats
class as a read-only property, hence the "Unable to find setter method" error.
You do have a setClass method, it's just that it doesn't take a Class parameter.

I imagine that on WebLogic, the introspection sees your setClass method first
and therefore treats "class" as a writable property.

To avoid this kind of problem, you should change your property name to 
"className".

-- 
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 43142] New: - webapp expanded in a FOLDER named webapps/xxx.war is loaded TWICE

2007-08-16 Thread 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=43142

   Summary: webapp expanded in a FOLDER named webapps/xxx.war is
loaded TWICE
   Product: Tomcat 6
   Version: 6.0.14
  Platform: PC
OS/Version: Windows XP
Status: NEW
  Severity: minor
  Priority: P2
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


reproduce: copy the expanded of file xxx.war file in a FOLDER 
tomcat/webapps/xxx.war

bug: tomcat will load the app TWICE

-- 
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: r565464 - in /tomcat/tc6.0.x/trunk/java/org/apache: catalina/connector/ catalina/startup/ coyote/ajp/ coyote/http11/ tomcat/util/ tomcat/util/digester/

2007-08-16 Thread Filip Hanik - Dev Lists

Remy Maucherat wrote:

Bill Barker wrote:
Tomcat has never made any promise that the core API 
won't change between versions.  If you depend on the Tomcat API at 
any version level, then you are required to review at the next level.


There should be no backwards incompatible changes in my change. The 
only method signature which does change is in IntroUtils, to return a 
boolean. It is possible to add a setProperty2 method and revert 
setProperty to what it was.


-public static void setProperty(Object o, String name, String 
value) {
+public static boolean setProperty(Object o, String name, String 
value) {


The digester (if there was use of it despite the package renaming) 
should default to the old behavior.
as you might have noticed, but I didn't veto the change either. but the 
fact that 6.0.14 has a pretty serious bug in the Comet related code, 
that after a comet request has ended also breaks regular HTTP requests, 
would call for another release fairly shortly, large changes like this, 
do have a tendency to delay such releases, as we now need a lot more 
testing and feedback to vote it stable


Filip

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



Re: svn commit: r565464 - in /tomcat/tc6.0.x/trunk/java/org/apache: catalina/connector/ catalina/startup/ coyote/ajp/ coyote/http11/ tomcat/util/ tomcat/util/digester/

2007-08-16 Thread Filip Hanik - Dev Lists

Remy Maucherat wrote:

Filip Hanik - Dev Lists wrote:

Remy Maucherat wrote:

Tim Funk wrote:
I thought changes were going into trunk and then when applicable, 
backported to 6.0.x.


While I initiated the creation of the trunk branch, I can no longer 
work with Filip since I disagree with him on API design, and I don't 
like his ideas on collaboration. As a result, I do not wish to 
participate in trunk development, and I have to do my development 
activities elsewhere :( 
it's community development, you can participate or not. That's your 
call.
You've threatened to start other branches elsewhere, you've 
threatened to leave, you can keep threatening, if the community is 
strong enough it will survive. If it is not, then it will fall, just 
like Rome did.


No, trunk is Filip's development, and that's it. 
I don't see how that is, you created it, you even agreed to most of the 
initial Comet interface changes, even before trunk was created.
After that, you through in a bunch of vetoes based on your personal 
preference of an API, even though you already agreed. I would say, those 
vetoes were noted, but invalid, they didn't have a technical 
explanations. Vetoes are a pretty serious thing, but you throw 'em out 
often without an explanation.
After that you withdrew your proposal, and withdrew your vetoes as well. 
So at that point, trunk would be official.
I've been working elsewhere since I had no other choice, and I regret 
there is no way to collaborate. ASF projects cannot go anywhere if two 
parties are in constant opposition, so basically one of us needs to go 
away for the project to move forward.
you've been used to getting your way, all the time, you have a very hard 
to functioning when you don't get your way, you throw tantrums, threats 
and all kinds of accusations around you instead of working towards a 
resolution.
This isn't a one-man show, never has been. It's give an take. I think a 
lot of people, including me, have disagreed with things you've done, 
specially the way you abuse users providing feedback on bugzilla, but we 
all go along for the sake of the project and the community.


 I now think removing the trunk branch or moving it to the sandbox 
would be best.
I'm gonna propose for trunk to stay, we specifically made that cause 
you decided changes the Geronimo team needed were not appropriate.

And there are other changes that have gone in there since then.


Maybe switching to a tigher patch inclusion process like what is done 
in httpd, and reboot trunk, could be a solution. As you may have 
noticed, I disagreed with all your Comet related commits, and you 
never cared in any way. This would have avoided the initial divide.
I was more than willing to continue the discussion around the API, but 
you ignored that and you jumped the gun and started another sandbox 
project instead. That was your call again.



Filip

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



DO NOT REPLY [Bug 43146] New: - address attribute is ignored by Admin application

2007-08-16 Thread 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=43146

   Summary: address attribute is ignored by Admin application
   Product: Tomcat 5
   Version: 5.5.23
  Platform: Other
OS/Version: Windows Server 2003
Status: NEW
  Severity: major
  Priority: P2
 Component: Webapps:Administration
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


The address attribute on a connector is completely ignored by the Admin 
interface. 

I have setup four connectors with two ip-addresses on ports 80 and 443 each,
protocols are http/https. This happened manually by editing the file.

The server.xml was tested and the server works as expected, responding only to
the specific addresses.

If you move into tomcat admin, adding/changing anything and pressing "commit
changes", all connector elements lack the address attribute, effectively
destroying the configuration.

The admin application can therefore not be used on servers that will only listen
to certain IP-addresses.

-- 
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: r565464 - in /tomcat/tc6.0.x/trunk/java/org/apache: catalina/connector/ catalina/startup/ coyote/ajp/ coyote/http11/ tomcat/util/ tomcat/util/digester/

2007-08-16 Thread Remy Maucherat

Filip Hanik - Dev Lists wrote:
as you might have noticed, but I didn't veto the change either. but the 
fact that 6.0.14 has a pretty serious bug in the Comet related code, 
that after a comet request has ended also breaks regular HTTP requests, 
would call for another release fairly shortly, large changes like this, 
do have a tendency to delay such releases, as we now need a lot more 
testing and feedback to vote it stable


It's not a regression, affecting only a slightly edgy feature, so I 
would at least wait a few weeks to see if there are more things to fix 
in this build before releasing a new 6.0.x.


Rémy

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



Re: svn commit: r565464 - in /tomcat/tc6.0.x/trunk/java/org/apache: catalina/connector/ catalina/startup/ coyote/ajp/ coyote/http11/ tomcat/util/ tomcat/util/digester/

2007-08-16 Thread Remy Maucherat

Filip Hanik - Dev Lists wrote:
you've been used to getting your way, all the time, you have a very hard 
to functioning when you don't get your way, you throw tantrums, threats 
and all kinds of accusations around you instead of working towards a 
resolution.
This isn't a one-man show, never has been. It's give an take. I think a 
lot of people, including me, have disagreed with things you've done, 
specially the way you abuse users providing feedback on bugzilla, but we 
all go along for the sake of the project and the community.


Right, I'm evil, I know it by now. Since you, thankfully, are not evil, 
I would need to qualify how development works on the following components:

- clustering functionality
- HTTP NIO connector
- and now, Comet functionality in trunk
If these aren't a one man show ... You're never participating in other 
components, where there's actual collaboration. In clustering, there 
used one other contributor, but you managed to scare off the only other 
contributor with constant refactorings.


About BZ, which is a legitimate claim, I find reports of many people to 
simply be irritating. The feeling grows with time, and it's been a long 
time. As a result, I am not patient at all. To avoid the problem, I am 
now not often commenting in BZ anymore, which works reasonably well.


About the Comet functionality evolution, I evidently agreed on a number 
of features, which I thought you had understood (it turned out to not be 
so accurate). I never agreed to specific APIs, and I never said I 
wouldn't refine my ideas. Starting with a fully explicit and detailed 
API is cool, but then I did start looking at usage, improving it, and 
removing cruft. It's an iterative improvement process.


The rest of the email does not make much sense to me. I think if you 
believe I am bad for the community, you should not waste more time, and 
call for a PMC vote to remove my commit privileges. It's been done 
before in other projects in similar situations.


Rémy

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



DO NOT REPLY [Bug 43147] New: - Tomcat source does not compile with javac 1.6.0_01

2007-08-16 Thread 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=43147

   Summary: Tomcat source does not compile with javac  1.6.0_01
   Product: Tomcat 6
   Version: 6.0.14
  Platform: PC
OS/Version: Solaris
Status: NEW
  Severity: normal
  Priority: P2
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


The Tomcat 6.0.14 does not compile when using javac 1.6.0_01.
When JDK 1.5.0_12 is installed and used for compiling, binaries can be produced.

This is on Solaris_11 (Opensolaris) x86.

-- 
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 43147] - Tomcat source does not compile with javac 1.6.0_01

2007-08-16 Thread 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=43147





--- Additional Comments From [EMAIL PROTECTED]  2007-08-16 12:11 ---
Created an attachment (id=20670)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=20670&action=view)
Compile log

This is the output of 'ant > /tmp/compile.log'

-- 
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: r565464 - in /tomcat/tc6.0.x/trunk/java/org/apache: catalina/connector/ catalina/startup/ coyote/ajp/ coyote/http11/ tomcat/util/ tomcat/util/digester/

2007-08-16 Thread Filip Hanik - Dev Lists

Remy Maucherat wrote:

Filip Hanik - Dev Lists wrote:
you've been used to getting your way, all the time, you have a very 
hard to functioning when you don't get your way, you throw tantrums, 
threats and all kinds of accusations around you instead of working 
towards a resolution.
This isn't a one-man show, never has been. It's give an take. I think 
a lot of people, including me, have disagreed with things you've 
done, specially the way you abuse users providing feedback on 
bugzilla, but we all go along for the sake of the project and the 
community.


Right, I'm evil, I know it by now. Since you, thankfully, are not 
evil, I would need to qualify how development works on the following 
components:

sure, I'll be happy to

- clustering functionality
anyone welcome to join, I get most of the feedback from the user 
community and that drives the development here.



- HTTP NIO connector
no one in the tomcat developer community believed in this project, 
turned out to work quite well.
again, tons of feedback from the user community, and as always folks are 
welcome to join

- and now, Comet functionality in trunk

had you actually bothered to reply to:
[0] http://marc.info/?l=tomcat-dev&m=118660698611008&w=2
[1] http://marc.info/?l=tomcat-dev&m=118036723731841&w=2
[2] http://marc.info/?l=tomcat-dev&m=118042428922165&w=2
in all three instances, I'd openly said that we can revise it.
If these aren't a one man show ... You're never participating in other 
components, where there's actual collaboration. In clustering, there 
used one other contributor, but you managed to scare off the only 
other contributor with constant refactorings.
I'll leave Peter to answer if he got scared off or not. I'm not going to 
speak for him, I don't believe anyone has the right to.

But the refactorings were necessary, and extremely useful.
turns out that even jboss/jgroups adopted a few ideas from here 
(example: multiplex channel and concurrency in the channel stack)


About BZ, which is a legitimate claim, I find reports of many people 
to simply be irritating. The feeling grows with time, and it's been a 
long time. As a result, I am not patient at all. To avoid the problem, 
I am now not often commenting in BZ anymore, which works reasonably well.


About the Comet functionality evolution, I evidently agreed on a 
number of features, which I thought you had understood (it turned out 
to not be so accurate). I never agreed to specific APIs, and I never 
said I wouldn't refine my ideas. Starting with a fully explicit and 
detailed API is cool, but then I did start looking at usage, improving 
it, and removing cruft. It's an iterative improvement process.

see the links above


The rest of the email does not make much sense to me. I think if you 
believe I am bad for the community, you should not waste more time, 
and call for a PMC vote to remove my commit privileges. It's been done 
before in other projects in similar situations.

another ultimatum?
I'll leave that to the PMC chair, as that would fall into the category 
of such decisions. As for me personally, I think you are a very good 
coder, somewhat short sighted on other folks ideas and communication 
skills, but you've done lots of good for the project, (maybe not as much 
for the community).


Filip


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



DO NOT REPLY [Bug 43150] New: - Tomcat and path with pound sign (#) -> ClassNotFoundException

2007-08-16 Thread 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=43150

   Summary: Tomcat and path with pound sign (#) ->
ClassNotFoundException
   Product: Tomcat 6
   Version: 6.0.14
  Platform: All
   URL: http://marc.info/?l=tomcat-user&m=118660647227413&w=2
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Tomcat will not start if it's located and launched from a path with a # (pound)
character somewhere. You'll find all informations in the given mail-thread on
tomcat-user, including some developer specific informations.

One part of the problem is the usage of File.toURL in URLClassloader...

I'd really appreciate it if this problem could be fixed/worked around (see
mail-thread for hints).

btw. the same applies to version 5.5 and probably earlier versions too.

thanks!

-- 
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 43127] - Tomcat's windows service doesn't start up when run in guest OS in MS Virtual Server

2007-08-16 Thread 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=43127


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE




--- Additional Comments From [EMAIL PROTECTED]  2007-08-16 17:05 ---
This is a JVM bug

*** This bug has been marked as a duplicate of 41538 ***

-- 
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 41538] - Unable to run Tomcat as a Windows service under JDK 1.6

2007-08-16 Thread 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=41538


[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]




--- Additional Comments From [EMAIL PROTECTED]  2007-08-16 17:05 ---
*** Bug 43127 has been marked as a duplicate of this 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]



DO NOT REPLY [Bug 43153] New: - Socket.optGet(socket, Socket.APR_SO_SNDBUF) throws org.apache.tomcat.jni.Error

2007-08-16 Thread 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=43153

   Summary: Socket.optGet(socket, Socket.APR_SO_SNDBUF) throws
org.apache.tomcat.jni.Error
   Product: Tomcat 6
   Version: unspecified
  Platform: Other
OS/Version: other
Status: NEW
  Severity: normal
  Priority: P4
 Component: Native:Integration
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Socket.optGet(socket, Socket.APR_SO_SNDBUF) throws org.apache.tomcat.jni.Error:
Socket operation on non-socket due to a typo in network.c.

-- 
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 43153] - Socket.optGet(socket, Socket.APR_SO_SNDBUF) throws org.apache.tomcat.jni.Error

2007-08-16 Thread 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=43153





--- Additional Comments From [EMAIL PROTECTED]  2007-08-16 19:31 ---
Created an attachment (id=20672)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=20672&action=view)
Fix optGet(..., APR_SO_SNDBUF) by correcting a typo in network.c


-- 
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 43153] - Socket.optGet(socket, Socket.APR_SO_SNDBUF) throws org.apache.tomcat.jni.Error

2007-08-16 Thread 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=43153


[EMAIL PROTECTED] changed:

   What|Removed |Added

  BugsThisDependsOn||43152




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