[Bug 54017] New: new String instance is generated for constant string in Generator.convertString

2012-10-17 Thread bugzilla 
https://issues.apache.org/bugzilla/show_bug.cgi?id=54017

  Priority: P2
Bug ID: 54017
  Assignee: dev@tomcat.apache.org
   Summary: new String instance is generated for constant string
in Generator.convertString
  Severity: normal
Classification: Unclassified
  Reporter: xs...@ebay.com
  Hardware: PC
Status: NEW
   Version: trunk
 Component: Jasper
   Product: Tomcat 7

If the target class is "Object.class", the generator generates
"new String(" + quoted + ")";
as attribute value for Tag Handler.

How about using quoted directly same as when the target class is
"Object.class"?

Creating a String instance will cause some overhead from memory allocation and
hash code recaluation when it is used as a key on HashMap.


Here is the detail code,

/*
 * @param c The target class to which to coerce the given string @param
 * s The string value @param attrName The name of the attribute whose
 * value is being supplied @param propEditorClass The property editor
 * for the given attribute @param isNamedAttribute true if the given
 * attribute is a named attribute (that is, specified using the
 * jsp:attribute standard action), and false otherwise
 */
private String convertString(Class c, String s, String attrName,
Class propEditorClass, boolean isNamedAttribute) {

String quoted = s;
if (!isNamedAttribute) {
quoted = quote(s);
}

if (propEditorClass != null) {
String className = c.getCanonicalName();
return "("
+ className
+
")org.apache.jasper.runtime.JspRuntimeLibrary.getValueFromBeanInfoPropertyEditor("
+ className + ".class, \"" + attrName + "\", " + quoted
+ ", " + propEditorClass.getCanonicalName() +
".class)";
} else if (c == String.class) {
return quoted;
} else if (c == boolean.class) {
return JspUtil.coerceToPrimitiveBoolean(s, isNamedAttribute);
} else if (c == Boolean.class) {
return JspUtil.coerceToBoolean(s, isNamedAttribute);
} else if (c == byte.class) {
return JspUtil.coerceToPrimitiveByte(s, isNamedAttribute);
} else if (c == Byte.class) {
return JspUtil.coerceToByte(s, isNamedAttribute);
} else if (c == char.class) {
return JspUtil.coerceToChar(s, isNamedAttribute);
} else if (c == Character.class) {
return JspUtil.coerceToCharacter(s, isNamedAttribute);
} else if (c == double.class) {
return JspUtil.coerceToPrimitiveDouble(s, isNamedAttribute);
} else if (c == Double.class) {
return JspUtil.coerceToDouble(s, isNamedAttribute);
} else if (c == float.class) {
return JspUtil.coerceToPrimitiveFloat(s, isNamedAttribute);
} else if (c == Float.class) {
return JspUtil.coerceToFloat(s, isNamedAttribute);
} else if (c == int.class) {
return JspUtil.coerceToInt(s, isNamedAttribute);
} else if (c == Integer.class) {
return JspUtil.coerceToInteger(s, isNamedAttribute);
} else if (c == short.class) {
return JspUtil.coerceToPrimitiveShort(s, isNamedAttribute);
} else if (c == Short.class) {
return JspUtil.coerceToShort(s, isNamedAttribute);
} else if (c == long.class) {
return JspUtil.coerceToPrimitiveLong(s, isNamedAttribute);
} else if (c == Long.class) {
return JspUtil.coerceToLong(s, isNamedAttribute);
} else if (c == Object.class) {
return "new String(" + quoted + ")";
} else {
String className = c.getCanonicalName();
return "("
+ className
+
")org.apache.jasper.runtime.JspRuntimeLibrary.getValueFromPropertyEditorManager("
+ className + ".class, \"" + attrName + "\", " + quoted
+ ")";
}
}

-- 
You are receiving this mail because:
You are the assignee for the bug.

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Reloading WebappClassLoader

2012-10-17 Thread Elgs Chen 
Dear Tomcat Developers,

I'm using embedded tomcat 7 on my current project. I'm wondering if there's any 
API available that I can reload the WebappClassLoader by ditching the webapp 
class loader that loads the jars and classes in /WEB-INF/lib and 
/WEB-INF/classes, and create a new one that loads the jars and classes from 
exactly the same location. I'm hoping the webapp class loader can be manually 
reloaded as opposed to the auto-redeploy. If this is possible, it will allow my 
users to upload their plugins and decide when to apply their plugins to make 
them effective.

Thanks,
Elgs
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

svn commit: r1399161 - /tomcat/trunk/java/org/apache/coyote/AbstractProtocol.java

2012-10-17 Thread markt 
Author: markt
Date: Wed Oct 17 09:27:01 2012
New Revision: 1399161

URL: http://svn.apache.org/viewvc?rev=1399161&view=rev
Log:
Reduce a circular package dependency (Structure 101)

Modified:
tomcat/trunk/java/org/apache/coyote/AbstractProtocol.java

Modified: tomcat/trunk/java/org/apache/coyote/AbstractProtocol.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/coyote/AbstractProtocol.java?rev=1399161&r1=1399160&r2=1399161&view=diff
==
--- tomcat/trunk/java/org/apache/coyote/AbstractProtocol.java (original)
+++ tomcat/trunk/java/org/apache/coyote/AbstractProtocol.java Wed Oct 17 
09:27:01 2012
@@ -31,7 +31,6 @@ import javax.management.MalformedObjectN
 import javax.management.ObjectName;
 
 import org.apache.coyote.http11.upgrade.UpgradeInbound;
-import org.apache.coyote.http11.upgrade.UpgradeProcessor;
 import org.apache.juli.logging.Log;
 import org.apache.tomcat.util.ExceptionUtils;
 import org.apache.tomcat.util.collections.SynchronizedStack;
@@ -651,8 +650,9 @@ public abstract class AbstractProtocol i
 // Need to keep the connection associated with the 
processor
 longPoll(socket, processor);
 } else {
-// Connection closed. OK to recycle the processor.
-if (!(processor instanceof UpgradeProcessor)) {
+// Connection closed. OK to recycle the processor. Upgrade
+// processors are not recycled.
+if (!processor.isUpgrade()) {
 release(socket, processor, true, false);
 }
 }
@@ -678,7 +678,7 @@ public abstract class AbstractProtocol i
 sm.getString("abstractConnectionHandler.error"), e);
 }
 // Don't try to add upgrade processors back into the pool
-if (!(processor instanceof UpgradeProcessor)) {
+if (!processor.isUpgrade()) {
 release(socket, processor, true, false);
 }
 return SocketState.CLOSED;



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

svn commit: r1399162 - /tomcat/trunk/java/org/apache/coyote/AbstractProtocol.java

2012-10-17 Thread markt 
Author: markt
Date: Wed Oct 17 09:30:12 2012
New Revision: 1399162

URL: http://svn.apache.org/viewvc?rev=1399162&view=rev
Log:
Suppress some warnings

Modified:
tomcat/trunk/java/org/apache/coyote/AbstractProtocol.java

Modified: tomcat/trunk/java/org/apache/coyote/AbstractProtocol.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/coyote/AbstractProtocol.java?rev=1399162&r1=1399161&r2=1399162&view=diff
==
--- tomcat/trunk/java/org/apache/coyote/AbstractProtocol.java (original)
+++ tomcat/trunk/java/org/apache/coyote/AbstractProtocol.java Wed Oct 17 
09:30:12 2012
@@ -759,6 +759,7 @@ public abstract class AbstractProtocol i
 this.handler = handler;
 }
 
+@SuppressWarnings("sync-override") // Size may exceed cache size a bit
 @Override
 public boolean push(Processor processor) {
 int cacheSize = handler.getProtocol().getProcessorCache();
@@ -775,6 +776,7 @@ public abstract class AbstractProtocol i
 return result;
 }
 
+@SuppressWarnings("sync-override") // OK if size is too big briefly
 @Override
 public Processor pop() {
 Processor result = super.pop();



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[Bug 54019] New: org.apache.coyote.Response & org.apache.coyote.Request don't call recycle() on notes[] elements.

2012-10-17 Thread bugzilla 
https://issues.apache.org/bugzilla/show_bug.cgi?id=54019

  Priority: P2
Bug ID: 54019
  Assignee: dev@tomcat.apache.org
   Summary: org.apache.coyote.Response & org.apache.coyote.Request
don't call recycle() on notes[] elements.
  Severity: critical
Classification: Unclassified
  Reporter: frederic.arn...@gmail.com
  Hardware: PC
Status: NEW
   Version: unspecified
 Component: Connectors
   Product: Tomcat 7

Note: I'll use coyoteRequest (resp. coyoteResponse) where in code it's req
(resp. res), it just to help because there's also the connectorRequest (resp.
connectorResponse).

CoyoteAdapter checks coyoteRequest (resp. coyoteResponse) notes content in
CoyoteAdapter method service(coyoreRequest, coyoteResponse):
Request request = (Request) req.getNote(ADAPTER_NOTES);
Response response = (Response) res.getNote(ADAPTER_NOTES);

If they exist, it will not create a new one and set it as note in coyoteRequest
(resp. coyoteResponse):
if (request == null) {
...
// Set as notes
req.setNote(ADAPTER_NOTES, request);
res.setNote(ADAPTER_NOTES, response);
...
}

There's no change later on theses notes, so recycle must work for them!

But (here the but): coyoteRequest (resp. coyoteResponse) will not recycle
theses notes.

Side effect of bug: in some cases (in my case it's for IOException while using
Comet API):
1) I can get the request attributes of previous request
2) My output buffer in response is corrupted, on first access like
setBufferSize I got an IllegalStateException buffer already commited (today I'm
not sure if it's the root cause, but now I can't reproduce it with my fix).
3) Side effect also on traditional servlet (and JSP for sure!).



Fix (for me, below a general fix):
==
I added this in org.apache.coyote.Request at end of recycle() method:
for(Object note : notes) {
if (note instanceof org.apache.catalina.connector.Request) {
((org.apache.catalina.connector.Request) note).recycle();
}
}

And this in org.apache.coyote.Response at end of recycle() method:
for(Object note : notes) {
if (note instanceof org.apache.catalina.connector.Response) {
((org.apache.catalina.connector.Response) note).recycle();
}
}



Final fix need a solution like (since notes will not use only connector Request
and Response):
1) Create a new Recyclable interface like:
public interface Recyclable {
void recycle();
}

2) Change some object that could be used in notes (but maybe all recyclable
objects) to implements this interface:
package org.apache.coyote;
...
public final class Response implements Recyclable {
...
}
and:
package org.apache.coyote;
...
public final class Request implements Recyclable {
...
}

3) Do this in recycle method for org.apache.coyote.Request and Response:
for(Object note : notes) {
if (note instanceof Recyclable) {
((Recyclable) note).recycle();
}
}



IMPORTANT: THIS HAPPENS ALSO ON TOMCAT 6!



best regards
f.arnoud

-- 
You are receiving this mail because:
You are the assignee for the bug.

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: svn commit: r1389005 - in /tomcat/trunk/java/org/apache/catalina/valves: AccessLogValve.java Constants.java

2012-10-17 Thread Konstantin Kolinko 
2012/9/23  :
> Author: markt
> Date: Sun Sep 23 10:36:58 2012
> New Revision: 1389005
>
> URL: http://svn.apache.org/viewvc?rev=1389005&view=rev
> Log:
> More GC reduction in the AccessLog. Integer.toString(response.getStatus()) 
> was responsible for ~4% of allocated objects under load
>
> Modified:
> tomcat/trunk/java/org/apache/catalina/valves/AccessLogValve.java
> tomcat/trunk/java/org/apache/catalina/valves/Constants.java
>
> Modified: tomcat/trunk/java/org/apache/catalina/valves/AccessLogValve.java
> URL: 
> http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/valves/AccessLogValve.java?rev=1389005&r1=1389004&r2=1389005&view=diff
> ==
> --- tomcat/trunk/java/org/apache/catalina/valves/AccessLogValve.java 
> (original)
> +++ tomcat/trunk/java/org/apache/catalina/valves/AccessLogValve.java Sun Sep 
> 23 10:36:58 2012
> @@ -41,6 +41,7 @@ import java.util.concurrent.ConcurrentLi
>
>  import javax.servlet.ServletException;
>  import javax.servlet.http.Cookie;
> +import javax.servlet.http.HttpServletResponse;
>  import javax.servlet.http.HttpSession;
>
>  import org.apache.catalina.AccessLog;
> @@ -1617,7 +1618,134 @@ public class AccessLogValve extends Valv
>  public void addElement(CharBuffer buf, Date date, Request request,
>  Response response, long time) {
>  if (response != null) {
> -buf.append(Integer.toString(response.getStatus()));
> +// This approach is used to reduce GC
> +switch (response.getStatus()) {
> +case HttpServletResponse.SC_CONTINUE:
> +buf.put(Constants.SC_CONTINUE_CHAR);
> +break;
> +case HttpServletResponse.SC_SWITCHING_PROTOCOLS:
> +buf.put(Constants.SC_SWITCHING_PROTOCOLS_CHAR);
> +break;
>(...)
> +}
>  } else {
>  buf.append('-');
>  }
>
> Modified: tomcat/trunk/java/org/apache/catalina/valves/Constants.java
> URL: 
> http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/valves/Constants.java?rev=1389005&r1=1389004&r2=1389005&view=diff
> ==
> --- tomcat/trunk/java/org/apache/catalina/valves/Constants.java (original)
> +++ tomcat/trunk/java/org/apache/catalina/valves/Constants.java Sun Sep 23 
> 10:36:58 2012
> @@ -36,4 +36,44 @@ public final class Constants {
>  public static final String COMBINED_PATTERN = "%h %l %u %t \"%r\" %s 
> %b \"%{Referer}i\" \"%{User-Agent}i\"";
>  }
>
> +public static final char[] SC_CONTINUE_CHAR = new char[] {'1', '0', '0'};
> +public static final char[] SC_SWITCHING_PROTOCOLS_CHAR = new char[] 
> {'1', '0', '1'};
>(...)
>  }
>


It is ugly and unmanageable.

BTW, if someone changes the content of those char arrays, the access
log may become a mess.

I propose to just write the digits. I think the following will work,
appending a digit value to the code of '0' character:

int status = response.getStatus();
if (100 <= status && status < 1000) {
   buf.write((char) ('0' + (status/100)));
   buf.write((char) ('0' + ((status / 10) % 10)));
   buf.write((char) ('0' + (status % 10)));
} else {
   buf.write(Integer.toString(status));
}

Best regards,
Konstantin Kolinko

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: svn commit: r1389005 - in /tomcat/trunk/java/org/apache/catalina/valves: AccessLogValve.java Constants.java

2012-10-17 Thread Mark Thomas 
On 17/10/2012 13:57, Konstantin Kolinko wrote:
> 2012/9/23  :
>> Author: markt
>> Date: Sun Sep 23 10:36:58 2012
>> New Revision: 1389005
>>
>> URL: http://svn.apache.org/viewvc?rev=1389005&view=rev
>> Log:
>> More GC reduction in the AccessLog. Integer.toString(response.getStatus()) 
>> was responsible for ~4% of allocated objects under load
>>
>> Modified:
>> tomcat/trunk/java/org/apache/catalina/valves/AccessLogValve.java
>> tomcat/trunk/java/org/apache/catalina/valves/Constants.java
>>
>> Modified: tomcat/trunk/java/org/apache/catalina/valves/AccessLogValve.java
>> URL: 
>> http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/valves/AccessLogValve.java?rev=1389005&r1=1389004&r2=1389005&view=diff
>> ==
>> --- tomcat/trunk/java/org/apache/catalina/valves/AccessLogValve.java 
>> (original)
>> +++ tomcat/trunk/java/org/apache/catalina/valves/AccessLogValve.java Sun Sep 
>> 23 10:36:58 2012
>> @@ -41,6 +41,7 @@ import java.util.concurrent.ConcurrentLi
>>
>>  import javax.servlet.ServletException;
>>  import javax.servlet.http.Cookie;
>> +import javax.servlet.http.HttpServletResponse;
>>  import javax.servlet.http.HttpSession;
>>
>>  import org.apache.catalina.AccessLog;
>> @@ -1617,7 +1618,134 @@ public class AccessLogValve extends Valv
>>  public void addElement(CharBuffer buf, Date date, Request request,
>>  Response response, long time) {
>>  if (response != null) {
>> -buf.append(Integer.toString(response.getStatus()));
>> +// This approach is used to reduce GC
>> +switch (response.getStatus()) {
>> +case HttpServletResponse.SC_CONTINUE:
>> +buf.put(Constants.SC_CONTINUE_CHAR);
>> +break;
>> +case HttpServletResponse.SC_SWITCHING_PROTOCOLS:
>> +buf.put(Constants.SC_SWITCHING_PROTOCOLS_CHAR);
>> +break;
>> (...)
>> +}
>>  } else {
>>  buf.append('-');
>>  }
>>
>> Modified: tomcat/trunk/java/org/apache/catalina/valves/Constants.java
>> URL: 
>> http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/valves/Constants.java?rev=1389005&r1=1389004&r2=1389005&view=diff
>> ==
>> --- tomcat/trunk/java/org/apache/catalina/valves/Constants.java (original)
>> +++ tomcat/trunk/java/org/apache/catalina/valves/Constants.java Sun Sep 23 
>> 10:36:58 2012
>> @@ -36,4 +36,44 @@ public final class Constants {
>>  public static final String COMBINED_PATTERN = "%h %l %u %t \"%r\" 
>> %s %b \"%{Referer}i\" \"%{User-Agent}i\"";
>>  }
>>
>> +public static final char[] SC_CONTINUE_CHAR = new char[] {'1', '0', 
>> '0'};
>> +public static final char[] SC_SWITCHING_PROTOCOLS_CHAR = new char[] 
>> {'1', '0', '1'};
>> (...)
>>  }
>>
> 
> 
> It is ugly and unmanageable.
> 
> BTW, if someone changes the content of those char arrays, the access
> log may become a mess.
> 
> I propose to just write the digits. I think the following will work,
> appending a digit value to the code of '0' character:

Go for it.

Mark


> 
> int status = response.getStatus();
> if (100 <= status && status < 1000) {
>buf.write((char) ('0' + (status/100)));
>buf.write((char) ('0' + ((status / 10) % 10)));
>buf.write((char) ('0' + (status % 10)));
> } else {
>buf.write(Integer.toString(status));
> }
> 
> Best regards,
> Konstantin Kolinko
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Resources - merging back the changes

2012-10-17 Thread Konstantin Kolinko 
2012/10/16 Mark Thomas :
> On 09/10/2012 22:27, Mark Thomas wrote:
>> I believe from the various threads on the Resources implementation for
>> Tomcat 8 there is agreement that:
>>
>> - DirContext is not the right basis for the Resources API
>> - Refactoring is required to simplify the multiple 'add-ons' and to
>>   provide a sound basis for overlays (which may slip to Servlet 3.2)
>> - Any Resources implementation must provide in-memory caching
>>
>> The sandbox Resources implementation addresses all of the above and
>> passes the Servlet and JSP TCKs as well as all the unit tests.
>>
>> Given the above, is there any objection to merging the changes made in
>> the sandbox back to trunk?
>
> It has been a week and no objections so I will go ahead and do this.
> However, I am currently working on the new HTTP Upgrade API, the new
> WebSocket API and converting trunk to use both. I plan to focus on that
> for the next few days and and merge the resources changes afterwards.
>
> Mark
>
>> Note that the following TODOs remain:
>> - Provide an option to exclude selected resources from the cache
>> - Remove the DirContext code
>> - Review the use of trailing '/'
>> - Determine if a custom URL scheme is required (and implement if it is)
>> - Review the interaction of WebappClassLoader and Resources to see if
>>   there current work-arounds are a) still required b) implemented
>>   efficiently
>>

1. Are  and  able to inject individual files?

2. I am -1 on removal of VirtualWebappLoader.

The feature of injecting additional classpath entries into
WebappClassLoader.super.addURL() is an important one and I use it a
lot to inject external dependent libraries into web applications.

I do not like your approach as a replacement, because classpath
entries handling (jars handling) in URLClassLoader and in
WebappClassLoader is based on different requirements. I think that
URLClassLoader serves better for external libraries

See also #1. above.


3. Regarding the API.
In the tests I see
[[[
 tomcat.addContext("", System.getProperty("java.io.tmpdir"));

 File lib = new File("webapps/examples/WEB-INF/lib");
-ctx.setAliases("/WEB-INF/lib=" + lib.getCanonicalPath());
+ctx.setResources(new StandardRoot(ctx));
+ctx.getResources().createWebResourceSet(
+WebResourceRoot.ResourceSetType.POST, lib.getAbsolutePath(),
+"/WEB-INF/lib", "");
]]]

That "setResources" call seems to be excessive.

Maybe getResources() should create a StandardRoot instance implicitly,
or Tomcat.addContext() could create one, or StandardContext could
create one.

4. org.apache.catalina.webresources.Cache
+private ConcurrentMap resourceCache =
+new ConcurrentHashMap<>();

It think it'd be better with "final" there.


If you resolve #2., then I do not mind the merge.
I do not see much problems with the new APIs. I think we can go with them.


For reference:
The last merge from trunk to the branch was in r1397302, so I did a
svn diff between trunk and trunk-resources branch state after that
commit.
The command is
svn diff --old=https://svn.apache.org/repos/asf/tomcat/trunk@1397302
--new=https://svn.apache.org/repos/asf/tomcat/sandbox/trunk-resources@1397302

I uploaded the diff file here (its size is ~400KB):
http://people.apache.org/~kkolinko/patches/2012-10-17_tc8_resources-vs-trunk_r1397302.diff


Best regards,
Konstantin Kolinko

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[jira] [Created] (MTOMCAT-181) Allow to run the webapp under the root context

2012-10-17 Thread JIRA 
Sergio Fernández created MTOMCAT-181:


 Summary: Allow to run the webapp under the root context
 Key: MTOMCAT-181
 URL: https://issues.apache.org/jira/browse/MTOMCAT-181
 Project: Apache Tomcat Maven Plugin
  Issue Type: New Feature
  Components: tomcat7
Reporter: Sergio Fernández
Assignee: Olivier Lamy (*$^¨%`£)
Priority: Minor


Right now the plugin simply ignores this:


org.apache.tomcat.maven
tomcat7-maven-plugin
2.0

/



and take the artifactId as default context path. 

Would be possible to run it under the root context?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Resources - merging back the changes

2012-10-17 Thread Mark Thomas 
On 17/10/2012 15:07, Konstantin Kolinko wrote:

> 1. Are  and  able to inject individual files?

Not yet, but that should be relatively simple to implement.

> 2. I am -1 on removal of VirtualWebappLoader.
> 
> The feature of injecting additional classpath entries into
> WebappClassLoader.super.addURL() is an important one and I use it a
> lot to inject external dependent libraries into web applications.
> 
> I do not like your approach as a replacement, because classpath
> entries handling (jars handling) in URLClassLoader and in
> WebappClassLoader is based on different requirements. I think that
> URLClassLoader serves better for external libraries

Could you expand on this please. I'm struggling to see the difference
between using the VirtualWebappLoader and mapping JARs into WEB-INF/lib
and directories containing classes onto WEB-INF/classes


> 3. Regarding the API.
> In the tests I see
> [[[
>  tomcat.addContext("", System.getProperty("java.io.tmpdir"));
> 
>  File lib = new File("webapps/examples/WEB-INF/lib");
> -ctx.setAliases("/WEB-INF/lib=" + lib.getCanonicalPath());
> +ctx.setResources(new StandardRoot(ctx));
> +ctx.getResources().createWebResourceSet(
> +WebResourceRoot.ResourceSetType.POST, lib.getAbsolutePath(),
> +"/WEB-INF/lib", "");
> ]]]
> 
> That "setResources" call seems to be excessive.
> 
> Maybe getResources() should create a StandardRoot instance implicitly,
> or Tomcat.addContext() could create one, or StandardContext could
> create one.

Easy enough. I'll take a look.

> 4. org.apache.catalina.webresources.Cache
> +private ConcurrentMap resourceCache =
> +new ConcurrentHashMap<>();
> 
> It think it'd be better with "final" there.

Yep.

> If you resolve #2., then I do not mind the merge.
> I do not see much problems with the new APIs. I think we can go with them.

Great. I'll like to get better clarity on yoru thinking behind #2 before
I merge anything.

> For reference:
> The last merge from trunk to the branch was in r1397302, so I did a
> svn diff between trunk and trunk-resources branch state after that
> commit.
> The command is
> svn diff --old=https://svn.apache.org/repos/asf/tomcat/trunk@1397302
> --new=https://svn.apache.org/repos/asf/tomcat/sandbox/trunk-resources@1397302
> 
> I uploaded the diff file here (its size is ~400KB):
> http://people.apache.org/~kkolinko/patches/2012-10-17_tc8_resources-vs-trunk_r1397302.diff

Nice. Thanks.

Mark


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [VOTE] Release build 6.0.36

2012-10-17 Thread Olivier Lamy 
do you plan to release maven artifacts too ?

2012/10/16 jean-frederic clere :
> The candidates binaries are available here:
> http://people.apache.org/~jfclere/tomcat-6/v6.0.36/
>
> According to the release process, the 6.0.36 build corresponding to the
> tag TOMCAT_6_0_36 is:
> [ ] Broken
> [ ] Alpha
> [ ] Beta
> [ ] Stable
>
> Cheers
>
> Jean-Frederic
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>



-- 
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[jira] [Updated] (MTOMCAT-181) Allow to run the webapp under the root context

2012-10-17 Thread *$^¨%`£ 

 [ 
https://issues.apache.org/jira/browse/MTOMCAT-181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Olivier Lamy (*$^¨%`£) updated MTOMCAT-181:
---

Fix Version/s: 2.1

> Allow to run the webapp under the root context
> --
>
> Key: MTOMCAT-181
> URL: https://issues.apache.org/jira/browse/MTOMCAT-181
> Project: Apache Tomcat Maven Plugin
>  Issue Type: New Feature
>  Components: tomcat7
>Reporter: Sergio Fernández
>Assignee: Olivier Lamy (*$^¨%`£)
>Priority: Minor
> Fix For: 2.1
>
>
> Right now the plugin simply ignores this:
> 
> org.apache.tomcat.maven
> tomcat7-maven-plugin
> 2.0
> 
> /
> 
> 
> and take the artifactId as default context path. 
> Would be possible to run it under the root context?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[jira] [Commented] (MTOMCAT-181) Allow to run the webapp under the root context

2012-10-17 Thread *$^¨%`£ 

[ 
https://issues.apache.org/jira/browse/MTOMCAT-181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13478044#comment-13478044
 ] 

Olivier Lamy (*$^¨%`£) commented on MTOMCAT-181:


Do you have any sample to reproduce ?
Because I cannot reproduce.
Thanks!

> Allow to run the webapp under the root context
> --
>
> Key: MTOMCAT-181
> URL: https://issues.apache.org/jira/browse/MTOMCAT-181
> Project: Apache Tomcat Maven Plugin
>  Issue Type: New Feature
>  Components: tomcat7
>Reporter: Sergio Fernández
>Assignee: Olivier Lamy (*$^¨%`£)
>Priority: Minor
> Fix For: 2.1
>
>
> Right now the plugin simply ignores this:
> 
> org.apache.tomcat.maven
> tomcat7-maven-plugin
> 2.0
> 
> /
> 
> 
> and take the artifactId as default context path. 
> Would be possible to run it under the root context?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[jira] [Commented] (MTOMCAT-181) Allow to run the webapp under the root context

2012-10-17 Thread Enrico Olivelli (JIRA) 

[ 
https://issues.apache.org/jira/browse/MTOMCAT-181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13478045#comment-13478045
 ] 

Enrico Olivelli commented on MTOMCAT-181:
-

please implement this, in this way I will be able to use tomcat plugin for 
integration testing

> Allow to run the webapp under the root context
> --
>
> Key: MTOMCAT-181
> URL: https://issues.apache.org/jira/browse/MTOMCAT-181
> Project: Apache Tomcat Maven Plugin
>  Issue Type: New Feature
>  Components: tomcat7
>Reporter: Sergio Fernández
>Assignee: Olivier Lamy (*$^¨%`£)
>Priority: Minor
> Fix For: 2.1
>
>
> Right now the plugin simply ignores this:
> 
> org.apache.tomcat.maven
> tomcat7-maven-plugin
> 2.0
> 
> /
> 
> 
> and take the artifactId as default context path. 
> Would be possible to run it under the root context?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: SPDY/3

2012-10-17 Thread Mark Thomas 
Costin Manolache  wrote:

>Hi,
>
>Most browsers are switching from SPDY/2 to 3, I'm working on updating
>the
>tomcat implementation as well.
>I'm not sure if anyone has tried out or uses the SPDY support - or if
>there
>is still interest in supporting it (
>or doubts about keeping it ) - please let me know.

Happy to see it in trunk. Until folks start asking about it / for it, I'm 
tempted to remove it from the 8.0.x branch when it is created from trunk.

On a related note, Servlet 3.1 NIO looks like it may trigger some largish 
refactoring in the connectors.

Mark


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: SPDY/3

2012-10-17 Thread verlag.preis...@t-online.de 
Hi,

-Original-Nachricht-
> Von: Costin Manolache 

> Most browsers are switching from SPDY/2 to 3, I'm working on updating
> the tomcat implementation as well.
> I'm not sure if anyone has tried out or uses the SPDY support - or if
> there is still interest in supporting it (
> or doubts about keeping it ) - please let me know.
> 
> Costin

Great, I'm looking forward to the SPDY/3 implementation in Tomcat.
I've been waiting for it to be able to test the draft of a possible IIS SPDY 
redirector module [1] with Tomcat. :)

Regards,
Konstantin Preißer

[1] http://tomcat.markmail.org/message/ixeijji2rfymskif



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[Bug 54022] New: CometEvent.END event is not sent on a suspended socket disconnect when running with Tomcat Native (tcnative-1.dll) on Windows Vista / Windows Server 2008 or newer.

2012-10-17 Thread bugzilla 
https://issues.apache.org/bugzilla/show_bug.cgi?id=54022

  Priority: P2
Bug ID: 54022
  Assignee: dev@tomcat.apache.org
   Summary: CometEvent.END event is not sent on a suspended socket
disconnect when running with Tomcat Native
(tcnative-1.dll) on Windows Vista / Windows Server
2008 or newer.
  Severity: blocker
Classification: Unclassified
  Reporter: doug.bea...@verizon.net
  Hardware: PC
Status: NEW
   Version: 7.0.32
 Component: Connectors
   Product: Tomcat 7

Created attachment 29492
  --> https://issues.apache.org/bugzilla/attachment.cgi?id=29492&action=edit
Tomcat 7.0.32 source file with the bugfix

Our Web application uses an asynchronous 3.0 servlet (via Atmosphere 1.0,
actually) to send notification messages to clients connected via long-running
sockets (e.g., HTTP streaming, long polling, etc.) I found a bug where Tomcat
was not sending the CometEvent.END event on x64 platforms that used Tomcat
Native when a socket would disconnect (e.g., by pressing CTRL-C from an HTTP
GET curl command).  

After narrowing it down and debugging the Tomcat 7.0.32 source, I tracked the
problem down to org.apache.coyote.AbstractProtocol.java.  Due to the way that
APR handles socket polling in Tomcat Native, the bug only occurs on Windows
platforms that 1) use tcnative-1.dll, and 2) are Vista/Server 2008 or newer. 
Here is what is happening:

1) On startup, APR in tcnative-1.dll looks for a method named "WSAPoll" method
in Ws2_32.dll.  If it finds it, it assigns that function as the function to use
to poll sockets.  Otherwise, it falls back to the legacy method of polling
sockets.  WSAPoll is only present on Windows Vista/Server 2008 or newer.

2) In org.apache.tomcat.util.net.AprEndpoint, the doPoll(long pollset) method
invokes Poll.poll(pollset, pollTime, desc, true), which delegates the call to
tcnative-1.dll if present.

3) If doPoll returns > 0, it means that at least one socket requires
processing, so it falls through to this block in the doPoll method
AprEndpoint.java (comments added below marked with "{DB}"):

  for (int n = 0; n < rv; n++) {
  // Check for failed sockets and hand this socket off to a worker
  if (((desc[n*2] & Poll.APR_POLLHUP) == Poll.APR_POLLHUP)   //
{DB} only the WSAPoll method sets the APR_POLLHUP flag when a socket
disconnects; neither the legacy tcnative polling method nor the pure Java
Coyote polling method sets this flag (which is fine)
  || ((desc[n*2] & Poll.APR_POLLERR) == Poll.APR_POLLERR)
  || (comet && (!processSocket(desc[n*2+1],
SocketStatus.OPEN)))  // {DB} this line is executed for comet sockets if
WSAPoll is not available on this platform (e.g., pre-Vista/Server 2008) or if
tcnative-1.dll is not present.  (This is also fine.)
  || (!comet && (!processSocket(desc[n*2+1] {
  // Close socket and clear pool
  if (comet) {
  processSocket(desc[n*2+1], SocketStatus.DISCONNECT);  //
{DB} this is only reached if tcnative-1.dll is present and we are running on
Vista/Server 2008 or newer.  This is OK, but there is a bug with
SocketStatus.DISCONNECT handling for comet sockets in processSocket (described
in the next step)
  } else {
  destroySocket(desc[n*2+1]);
  }
  }
  }

 4) The processSocket(long socket, SocketStatus status) method fires up a
SocketEventProcessor and runs it, which excutes this:

Handler.SocketState state = handler.process(socket, status);  // {DB}
this does not send CometEvent.END for comet if status ==
SocketStatus.DISCONNECT (details in next steps)
if (state == Handler.SocketState.CLOSED) {
// Close socket and pool
destroySocket(socket.getSocket().longValue());  // {DB} this closes
the socket and frees it for reuse, but since the Comet application was not
notified that the socket went away, the next time it tries to send data down
the socket it either crashes the JVM or writes the data to the response which
is now owned by somebody else.  Chaos ensues.
socket = null;
}

  5) When running Tomcat Native, the handler.process(socket, status) method is
implemented by
org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler, which
extends AbstractConnectionHandler defined as an inner class in
org.apache.coyote.AbstractProtocol.  The method and the fix that I made on my
test instance are shown below [the fix was to add '&& (!processor.isComet())'
to the beginning condition of the 'if' block]:
==  
  public SocketState process(SocketWrapper socket, SocketStatus status)
{
  ..
  do {
  // {DB} NOTE: status only == SocketStatus.DISCONNECT here if we
are running tcnative on Windows V

[jira] [Updated] (MTOMCAT-181) Allow to run the webapp under the root context

2012-10-17 Thread *$^¨%`£ 

 [ 
https://issues.apache.org/jira/browse/MTOMCAT-181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Olivier Lamy (*$^¨%`£) updated MTOMCAT-181:
---

Fix Version/s: (was: 2.1)
   moreinfo

> Allow to run the webapp under the root context
> --
>
> Key: MTOMCAT-181
> URL: https://issues.apache.org/jira/browse/MTOMCAT-181
> Project: Apache Tomcat Maven Plugin
>  Issue Type: New Feature
>  Components: tomcat7
>Reporter: Sergio Fernández
>Assignee: Olivier Lamy (*$^¨%`£)
>Priority: Minor
> Fix For: moreinfo
>
>
> Right now the plugin simply ignores this:
> 
> org.apache.tomcat.maven
> tomcat7-maven-plugin
> 2.0
> 
> /
> 
> 
> and take the artifactId as default context path. 
> Would be possible to run it under the root context?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org