DO NOT REPLY [Bug 41260] - [Contribution] WebAppLoader and DirContext implementations for handling with expanded webapp during development

[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=41260





--- Additional Comments From [EMAIL PROTECTED]  2007-01-03 01:28 ---
Created an attachment (id=19343)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=19343&action=view)
VirtualDirContext enhancement

Thanks Tim, great news!
Could you please also apply this patch to the newly committed
VirtualDirContext? I just enhanced it to also handle tag files loaded from
META-INF/tags dirs of referenced libraries, in order to fully emulate an
assembled webapp.


-- 
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 41260] - [Contribution] WebAppLoader and DirContext implementations for handling with expanded webapp during development

[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=41260


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |




-- 
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 41072] - tomcat (3.x/4.x/5.x/6.x) is not supporting http(1.0/1.1) CONNECT method.

[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=41072


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |




--- Additional Comments From [EMAIL PROTECTED]  2007-01-03 01:35 ---
(In reply to comment #7)
> Any target Servlet can implement any processing that it wants for any method 
> that it wants.  There is nothing here that should be within the Servlet 
> Container's scope.

I want to re-open this Bug.!

If you send a Http packet like the following

Http1.0 CONNECT IP:Port
Host 
ContentLenght XXB
ContentType text/xml
ProxyAuthorisation Basic 

does it work with tomcat(as a Proxy)!


-- 
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: r491995 - in /tomcat/tc6.0.x/trunk/java/org/apache: catalina/loader/VirtualWebappLoader.java naming/resources/VirtualDirContext.java

[Remy Maucherat]

[EMAIL PROTECTED] wrote:

Author: funkman
Date: Tue Jan  2 16:51:31 2007
New Revision: 491995

URL: http://svn.apache.org/viewvc?view=rev&rev=491995
Log:
http://issues.apache.org/bugzilla/show_bug.cgi?id=41260
[Contribution] WebAppLoader and DirContext implementations 
for handling with expanded webapp during development


Hmmm. I've always thought this sort of functionality was dangerous bloat 
(= people will use it, esp in prod, and ruin into trouble).


Rémy

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

Re: svn commit: r491995 - in /tomcat/tc6.0.x/trunk/java/org/apache: catalina/loader/VirtualWebappLoader.java naming/resources/VirtualDirContext.java

[Tim Funk]

True - but helping developers develop code faster is typically a good thing.

I'd be OK if we created a bloat [I mean optional] package for things 
like this.


-Tim

Remy Maucherat wrote:

[EMAIL PROTECTED] wrote:

Author: funkman
Date: Tue Jan  2 16:51:31 2007
New Revision: 491995

URL: http://svn.apache.org/viewvc?view=rev&rev=491995
Log:
http://issues.apache.org/bugzilla/show_bug.cgi?id=41260
[Contribution] WebAppLoader and DirContext implementations for 
handling with expanded webapp during development


Hmmm. I've always thought this sort of functionality was dangerous bloat 
(= people will use it, esp in prod, and ruin into trouble).




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

svn commit: r492112 - in /tomcat/tc6.0.x/trunk/java/org/apache: catalina/loader/VirtualWebappLoader.java naming/resources/VirtualDirContext.java

[funkman]

Author: funkman
Date: Wed Jan  3 03:59:32 2007
New Revision: 492112

URL: http://svn.apache.org/viewvc?view=rev&rev=492112
Log:
Update on http://issues.apache.org/bugzilla/show_bug.cgi?id=41260

Added warnings this should be for dev IDEs, not production.


Modified:

tomcat/tc6.0.x/trunk/java/org/apache/catalina/loader/VirtualWebappLoader.java
tomcat/tc6.0.x/trunk/java/org/apache/naming/resources/VirtualDirContext.java

Modified: 
tomcat/tc6.0.x/trunk/java/org/apache/catalina/loader/VirtualWebappLoader.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/catalina/loader/VirtualWebappLoader.java?view=diff&rev=492112&r1=492111&r2=492112
==
--- 
tomcat/tc6.0.x/trunk/java/org/apache/catalina/loader/VirtualWebappLoader.java 
(original)
+++ 
tomcat/tc6.0.x/trunk/java/org/apache/catalina/loader/VirtualWebappLoader.java 
Wed Jan  3 03:59:32 2007
@@ -34,6 +34,14 @@
  *  virtualClasspath="\dir\classes;\somedir\somejar.jar"/>
  * 
  * 
+ *
+ *
+ * This is not meant to be used for production.
+ * Its meant to ease development with IDE's without the
+ * need for fully republishing jars in WEB-INF/lib
+ *
+ *
+ *
  * @author Fabrizio Giustina
  * @version $Id: $
  */

Modified: 
tomcat/tc6.0.x/trunk/java/org/apache/naming/resources/VirtualDirContext.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/naming/resources/VirtualDirContext.java?view=diff&rev=492112&r1=492111&r2=492112
==
--- 
tomcat/tc6.0.x/trunk/java/org/apache/naming/resources/VirtualDirContext.java 
(original)
+++ 
tomcat/tc6.0.x/trunk/java/org/apache/naming/resources/VirtualDirContext.java 
Wed Jan  3 03:59:32 2007
@@ -45,6 +45,13 @@
  *  virtualClasspath="\dir\classes;\somedir\somejar.jar"/>
  * 
  * 
+ *
+ *
+ * This is not meant to be used for production.
+ * Its meant to ease development with IDE's without the
+ * need for fully republishing jars in WEB-INF/lib
+ *
+ *
  * @author Fabrizio Giustina
  * @version $Id: $
  */
@@ -57,6 +64,12 @@
 private Map virtualMappings;
 
 /**
+ * Map containing a mapping for tag files that should be loaded from the
+ * META-INF dir of referenced jar files.
+ */
+private Map tagfileMappings;
+
+/**
  * ; separated list of virtual path elements.
  */
 private String virtualClasspath;
@@ -79,6 +92,7 @@
 super.allocate();
 
 virtualMappings = new Hashtable();
+tagfileMappings = new Hashtable();
 
 // looks into any META-INF dir found in classpath entries for tld 
files.
 StringTokenizer tkn = new StringTokenizer(virtualClasspath, ";");
@@ -110,6 +124,23 @@
 if (virtualMappings.containsKey(tldName)) {
 return new 
FileResourceAttributes(virtualMappings.get(tldName));
 }
+} else if (name.startsWith("/META-INF/tags") && name.endsWith(".tag")
+|| name.endsWith(".tagx")) {
+
+// already loaded tag file
+if (tagfileMappings.containsKey(name)) {
+return new FileResourceAttributes(tagfileMappings.get(name));
+}
+
+// unknown tagfile, search for it in virtualClasspath
+StringTokenizer tkn = new StringTokenizer(virtualClasspath, ";");
+while (tkn.hasMoreTokens()) {
+File file = new File(tkn.nextToken(), name);
+if (file.exists()) {
+tagfileMappings.put(name, file);
+return new FileResourceAttributes(file);
+}
+}
 }
 
 return super.getAttributes(name);
@@ -136,6 +167,15 @@
 String tldName = name.substring(name.lastIndexOf("/") + 1);
 if (virtualMappings.containsKey(tldName)) {
 return new FileResource(virtualMappings.get(tldName));
+}
+} else if (name.startsWith("/META-INF/tags") && name.endsWith(".tag")
+|| name.endsWith(".tagx")) {
+
+// already loaded tag file: we are sure that getAttributes() has
+// already been called if we are here
+File tagFile = tagfileMappings.get(name);
+if (tagFile != null) {
+return new FileResource(tagFile);
 }
 }
 



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

Re: svn commit: r491619 - in /tomcat/tc6.0.x/trunk: java/org/apache/catalina/core/ApplicationDispatcher.java webapps/docs/changelog.xml

[Mark Thomas]

Remy Maucherat wrote:
> [EMAIL PROTECTED] wrote:
>> Author: markt
>> Date: Mon Jan  1 11:31:29 2007
>> New Revision: 491619
>>
>> URL: http://svn.apache.org/viewvc?view=rev&rev=491619
>> Log:
>> Port RD thread safety patch from TC5
> 
> I don't see any justification for this at the moment. Any further info ?

This started with http://marc.theaimsgroup.com/?t=11655879003&r=1&w=2

The short version of the above thread is that a RD was obtained using
ServletContext.getNamedDispatcher() and then re-used. When multiple
requests used the RD at the same time, the request objects got mixed
up (since the RD is not thread safe) which in turn lead to an
occasional ISE when both threads tried to call getParameterMap() at
the same time on the same Request object.

There was some debate whether or not the spec intended RDs to be
re-used in this way. I couldn't see anything that explicitly
dis-allowed it; hence I implemented the patch.

There are a couple of places where the patch could be cleaner but I
opted to make the changes in a consistent way throughout the code so
it was clearer what the patch was doing. Cleaning this up is on my
list of things to do but I wanted to give people a chance to consider
the patch as-is first.

Mark

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

DO NOT REPLY [Bug 41260] - [Contribution] WebAppLoader and DirContext implementations for handling with expanded webapp during development

[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=41260


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2007-01-03 04:56 ---
Done - Committed revision 492112.

Also added warning to javadocs that the files should be used for developmenet / 
IDE's only, not for production.


-- 
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: r491619 - in /tomcat/tc6.0.x/trunk: java/org/apache/catalina/core/ApplicationDispatcher.java webapps/docs/changelog.xml

[Remy Maucherat]

Mark Thomas wrote:

Remy Maucherat wrote:

[EMAIL PROTECTED] wrote:

Author: markt
Date: Mon Jan  1 11:31:29 2007
New Revision: 491619

URL: http://svn.apache.org/viewvc?view=rev&rev=491619
Log:
Port RD thread safety patch from TC5

I don't see any justification for this at the moment. Any further info ?


This started with http://marc.theaimsgroup.com/?t=11655879003&r=1&w=2

The short version of the above thread is that a RD was obtained using
ServletContext.getNamedDispatcher() and then re-used. When multiple
requests used the RD at the same time, the request objects got mixed
up (since the RD is not thread safe) which in turn lead to an
occasional ISE when both threads tried to call getParameterMap() at
the same time on the same Request object.

There was some debate whether or not the spec intended RDs to be
re-used in this way. I couldn't see anything that explicitly
dis-allowed it; hence I implemented the patch.


I remember the issue (not from this thread).

I don't understand how a RD could be be used by multiple threads, as no 
objects provided by the servlet container are thread safe. If you add 
some sort of thread safety somewhere, then users will demand that all 
the other objects to be thread safe, which is not going to happen. If 
they want to reuse the request dispatcher somehow and use it without 
checking, then they should sync on it. I thought the pattern was to 
obtain a RD every time (which is slower, but that's what I saw pretty 
much everywhere).



There are a couple of places where the patch could be cleaner but I
opted to make the changes in a consistent way throughout the code so
it was clearer what the patch was doing. Cleaning this up is on my
list of things to do but I wanted to give people a chance to consider
the patch as-is first.


Rémy


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

Re: Escaping EL doesn't work in Tomcat 6?

[Remy Maucherat]

arjan tijms wrote:
We're using a number of custom tags that accept JSF (deferred) EL 
through dynamic attributes. In JSP 2.1 this is illegal. I therefore 
tried to deactivate expression evaluation by escaping the #{ pattern, 
but it seems that Tomcat 6.0.7 ignores this?


Please provide a test war if you can. Tag with dynamic attribute names 
are supposed to accept EL.


Rémy

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

Re: Escaping EL doesn't work in Tomcat 6?

[Tim Funk]

Is this issue http://issues.apache.org/bugzilla/show_bug.cgi?id=41257
and http://issues.apache.org/bugzilla/show_bug.cgi?id=41258

I think these are the trouble:

Lines 2776-2777 in org.apache.jasper.compiler.Generator

TagAttributeInfo tai = attr.getTagAttributeInfo();
String type = tai.getTypeName();
  ^^^ <-- Is null

But the snippet above is contained in a if/else which wraps too many 
pages for me at the moment to try to determine a fix.



-Tim

Remy Maucherat wrote:

arjan tijms wrote:
We're using a number of custom tags that accept JSF (deferred) EL 
through dynamic attributes. In JSP 2.1 this is illegal. I therefore 
tried to deactivate expression evaluation by escaping the #{ pattern, 
but it seems that Tomcat 6.0.7 ignores this?


Please provide a test war if you can. Tag with dynamic attribute names 
are supposed to accept EL.




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

svn commit: r492182 - /tomcat/tc6.0.x/trunk/java/org/apache/jasper/compiler/Generator.java

[remm]

Author: remm
Date: Wed Jan  3 07:33:48 2007
New Revision: 492182

URL: http://svn.apache.org/viewvc?view=rev&rev=492182
Log:
- Avoid NPE (quick fix).

Modified:
tomcat/tc6.0.x/trunk/java/org/apache/jasper/compiler/Generator.java

Modified: tomcat/tc6.0.x/trunk/java/org/apache/jasper/compiler/Generator.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/jasper/compiler/Generator.java?view=diff&rev=492182&r1=492181&r2=492182
==
--- tomcat/tc6.0.x/trunk/java/org/apache/jasper/compiler/Generator.java 
(original)
+++ tomcat/tc6.0.x/trunk/java/org/apache/jasper/compiler/Generator.java Wed Jan 
 3 07:33:48 2007
@@ -2774,9 +2774,7 @@
 StringBuffer sb = new StringBuffer(64);
 
 TagAttributeInfo tai = attr.getTagAttributeInfo();
-String type = tai.getTypeName();
-String returnType = JspUtil.toJavaSourceTypeFromTld(attr
-.getExpectedTypeName());
+String returnType = 
JspUtil.toJavaSourceTypeFromTld(attr.getExpectedTypeName());
 
 // generate elContext reference
 sb.append(getJspContextVar());
@@ -2807,7 +2805,7 @@
 
 // depending on type
 if (attr.isDeferredInput()
-|| ValueExpression.class.getName().equals(type)) {
+|| ((tai != null) && 
ValueExpression.class.getName().equals(tai.getTypeName( {
 sb.append("new org.apache.jasper.el.JspValueExpression(");
 sb.append(quote(mark));
 sb.append(',');
@@ -2841,7 +2839,7 @@
 }
 attrValue = sb.toString();
 } else if (attr.isDeferredMethodInput()
-|| MethodExpression.class.getName().equals(type)) {
+|| ((tai != null) && 
MethodExpression.class.getName().equals(tai.getTypeName( {
 sb.append("new org.apache.jasper.el.JspMethodExpression(");
 sb.append(quote(mark));
 sb.append(',');



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

Re: Escaping EL doesn't work in Tomcat 6?

[Remy Maucherat]

Tim Funk wrote:

Is this issue http://issues.apache.org/bugzilla/show_bug.cgi?id=41257
and http://issues.apache.org/bugzilla/show_bug.cgi?id=41258

I think these are the trouble:

Lines 2776-2777 in org.apache.jasper.compiler.Generator

TagAttributeInfo tai = attr.getTagAttributeInfo();
String type = tai.getTypeName();
  ^^^ <-- Is null


Yes, I could figure it out, but I'm not totally sure what it should be 
doing then.


Rémy

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

Re: Escaping EL doesn't work in Tomcat 6?

[arjan tijms]

Tim Funk wrote:


Is this issue http://issues.apache.org/bugzilla/show_bug.cgi?id=41257
and http://issues.apache.org/bugzilla/show_bug.cgi?id=41258

I think these are the trouble:

Lines 2776-2777 in org.apache.jasper.compiler.Generator

TagAttributeInfo tai = attr.getTagAttributeInfo();
String type = tai.getTypeName();
  ^^^ <-- Is null



Indeed, I mentioned this in the bug report relating to EL in dynamic 
attributes. This bug report I think was wrongfully marked as a 
duplicate. While the original problem was indeed related to using EL in 
dynamic attributes too, the specific problem here is that escaping EL 
doesn't work either. I merely tried escaping EL as a workaround for the 
NPE bug.


So to sum up, I think we have two seperate bugs here:

1) EL in dynamic attributes causes NPE.
2) Escaping of EL doesn't work.




--
It's a cult. If you've coded for any length of time, you've run across someone 
from this warped brotherhood. Their creed: if you can write complicated code, 
you must be good.


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

DO NOT REPLY [Bug 41281] - provide a property to the wepapp loader classloader to pick classes from more than web-inf/classes location

[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=41281


[EMAIL PROTECTED] changed:

   What|Removed |Added

   Severity|normal  |enhancement




--- Additional Comments From [EMAIL PROTECTED]  2007-01-03 10:42 ---
This feature will be available in tomcat 6:
http://issues.apache.org/bugzilla/show_bug.cgi?id=41260

If that is ok - feel free to close.

-- 
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: r492263 - /tomcat/jasper/tc5.5.x/src/share/org/apache/jasper/compiler/TagLibraryInfoImpl.java

[funkman]

Author: funkman
Date: Wed Jan  3 11:29:52 2007
New Revision: 492263

URL: http://svn.apache.org/viewvc?view=rev&rev=492263
Log:
http://issues.apache.org/bugzilla/show_bug.cgi?id=41267
NPE in TagLibraryInfoImpl for a declared tag files not in jar files

Patch by 
Fabrizio Giustina  - fgiust at-apache:org


Modified:

tomcat/jasper/tc5.5.x/src/share/org/apache/jasper/compiler/TagLibraryInfoImpl.java

Modified: 
tomcat/jasper/tc5.5.x/src/share/org/apache/jasper/compiler/TagLibraryInfoImpl.java
URL: 
http://svn.apache.org/viewvc/tomcat/jasper/tc5.5.x/src/share/org/apache/jasper/compiler/TagLibraryInfoImpl.java?view=diff&rev=492263&r1=492262&r2=492263
==
--- 
tomcat/jasper/tc5.5.x/src/share/org/apache/jasper/compiler/TagLibraryInfoImpl.java
 (original)
+++ 
tomcat/jasper/tc5.5.x/src/share/org/apache/jasper/compiler/TagLibraryInfoImpl.java
 Wed Jan  3 11:29:52 2007
@@ -492,7 +492,11 @@
 
 if (path.startsWith("/META-INF/tags")) {
 // Tag file packaged in JAR
-ctxt.getTagFileJarUrls().put(path, jarFileUrl);
+// check if jarFileUrl is not null before adding it, or this will
+// cause a NPE.
+if (jarFileUrl != null) {
+ctxt.getTagFileJarUrls().put(path, jarFileUrl);
+}
 } else if (!path.startsWith("/WEB-INF/tags")) {
 err.jspError("jsp.error.tagfile.illegalPath", path);
 }



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

DO NOT REPLY [Bug 41267] - NPE in TagLibraryInfoImpl for a declared tag files not in jar files

[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=41267


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2007-01-03 11:30 ---
Fixed : Committed revision 492263.

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]

libtcnative configure check for apr version

[William L. Thomson Jr.]

If possible could the configure script for tomcat-native/libtcnative
check for apr versions. I wasted quite some time with a libtcnative I
compiled against apr 0.x instead of 1.x. Which allowed it to build, but
was really tiny and not usable.

If the configure checked for apr version 1.x or greater. Would have save
much grief. Likely my own fault for not reading or knowing about the apr
1.x dependency. But a check in the configure script would make it idiot
proof. :)

Thanks
 
-- 
William L. Thomson Jr.
Gentoo/Java


signature.asc
Description: This is a digitally signed message part

tcnative 1.1.8 -- offically released as stable?

[Jess Holle]

Has tcnative 1.1.8 been officially released, i.e. as stable?

It seemed like it was going to be from various votes, etc -- but I never 
saw any form of announcement.


Given the serious issues in a number of the previous tcnative releases, 
we've had to disable tcnative.  We'd like to retry with a new tcnative 
-- once one is officially released as stable, that is.  [We don't have 
time to chase all the latest dev builds at this point or such, 
unfortunately.]


--
Jess Holle

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

DO NOT REPLY [Bug 39088] - StandardWrapper getRootCause() infinite loop

[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=39088


[EMAIL PROTECTED] changed:

   What|Removed |Added

  BugsThisDependsOn||14789
OtherBugsDependingO||12369
  nThis||
 Status|REOPENED|NEW




--- Additional Comments From [EMAIL PROTECTED]  2007-01-03 13:20 ---
it is for a called game Bots 

-- 
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 33650] - Jasper performance for multiple files processing

[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=33650


[EMAIL PROTECTED] changed:

   What|Removed |Added

  BugsThisDependsOn||4445
OtherBugsDependingO||4
  nThis||




-- 
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: tcnative 1.1.8 -- offically released as stable?

[Mladen Turk]

Jess Holle wrote:

Has tcnative 1.1.8 been officially released, i.e. as stable?



There is no vote on tcnative releases. The vote is part
of Tomcat release.

It seemed like it was going to be from various votes, etc -- but I never 
saw any form of announcement.


Given the serious issues in a number of the previous tcnative releases, 
we've had to disable tcnative.


Tcnative is bound to the Tomcat release.
The major problem is that we have releases as non mandatory.
You will have INFO message in case the tcnative version
is below recommended one. Of course that allows to run the
tcnative versions that have known bugs.
I've tried to enforce that rule, but was over voted :)
Although the API is the same, I really see no reason to
allow tcnative-1.1.5 (or any pre 1.1.8)
running on any further Tomcat release. It would make sense if
this was performance release, but since its mostly bugfix release
having next Tomcat release allowing buggy tcnative versions would
only bring more concerns like yours.

Regards,
Mladen.


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

RE: tcnative 1.1.8 -- offically released as stable?

[Fenlason, Josh]

Since there is no vote on tcnative, is it always safe to say that the
latest native source available in
http://archive.apache.org/dist/tomcat/tomcat-connectors/native/ is as
close to "official" or "stable" as it's going to get?
Will tcnative 1.1.8 work with Tomcat 5.5.20?
Thanks.
,
Josh. 

> -Original Message-
> From: Mladen Turk [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, January 03, 2007 3:41 PM
> To: Tomcat Developers List
> Subject: Re: tcnative 1.1.8 -- offically released as stable?
> 
> Jess Holle wrote:
> > Has tcnative 1.1.8 been officially released, i.e. as stable?
> > 
> 
> There is no vote on tcnative releases. The vote is part of 
> Tomcat release.
> 
> > It seemed like it was going to be from various votes, etc -- but I 
> > never saw any form of announcement.
> > 
> > Given the serious issues in a number of the previous tcnative 
> > releases, we've had to disable tcnative.
> 
> Tcnative is bound to the Tomcat release.
> The major problem is that we have releases as non mandatory.
> You will have INFO message in case the tcnative version is 
> below recommended one. Of course that allows to run the 
> tcnative versions that have known bugs.
> I've tried to enforce that rule, but was over voted :) 
> Although the API is the same, I really see no reason to allow 
> tcnative-1.1.5 (or any pre 1.1.8) running on any further 
> Tomcat release. It would make sense if this was performance 
> release, but since its mostly bugfix release having next 
> Tomcat release allowing buggy tcnative versions would only 
> bring more concerns like yours.
> 
> 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]

DO NOT REPLY [Bug 33650] - Jasper performance for multiple files processing

[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=33650


[EMAIL PROTECTED] changed:

   What|Removed |Added

  BugsThisDependsOn|4445|




-- 
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: tcnative 1.1.8 -- offically released as stable?

[Mladen Turk]

Fenlason, Josh wrote:

Since there is no vote on tcnative, is it always safe to say that the
latest native source available in
http://archive.apache.org/dist/tomcat/tomcat-connectors/native/ is as
close to "official" or "stable" as it's going to get?
Will tcnative 1.1.8 work with Tomcat 5.5.20?


Sure it will.
Also, any tcnative version (1.1.x) is API
compatible so it'll work with previous Tomcat
versions.

Regards,
Mladen.

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