svn commit: r1560274 - /tomcat/tc7.0.x/trunk/test/org/apache/tomcat/websocket/TestWebSocketFrameClient.java

[markt]

Author: markt
Date: Wed Jan 22 08:12:47 2014
New Revision: 1560274

URL: http://svn.apache.org/r1560274
Log:
Need different value for BIO on 7.0.x as it is the default.

Modified:

tomcat/tc7.0.x/trunk/test/org/apache/tomcat/websocket/TestWebSocketFrameClient.java

Modified: 
tomcat/tc7.0.x/trunk/test/org/apache/tomcat/websocket/TestWebSocketFrameClient.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/test/org/apache/tomcat/websocket/TestWebSocketFrameClient.java?rev=1560274&r1=1560273&r2=1560274&view=diff
==
--- 
tomcat/tc7.0.x/trunk/test/org/apache/tomcat/websocket/TestWebSocketFrameClient.java
 (original)
+++ 
tomcat/tc7.0.x/trunk/test/org/apache/tomcat/websocket/TestWebSocketFrameClient.java
 Wed Jan 22 08:12:47 2014
@@ -100,8 +100,7 @@ public class TestWebSocketFrameClient ex
 public void testBug56032() throws Exception {
 // TODO Investigate options to get this test to pass with the HTTP BIO
 //  connector.
-if (getTomcatInstance().getConnector().getProtocol().equals(
-"org.apache.coyote.http11.Http11Protocol")) {
+if 
(getTomcatInstance().getConnector().getProtocol().equals("HTTP/1.1")) {
 return;
 }
 



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

Re: svn commit: r1560214 - in /tomcat/tc7.0.x/trunk: ./ test/org/apache/tomcat/websocket/TestWebSocketFrameClient.java

[Mark Thomas]

On 22/01/2014 05:31, Konstantin Kolinko wrote:
> 2014/1/22  :
>> Author: markt
>> Date: Tue Jan 21 22:45:35 2014
>> New Revision: 1560214
>>
>> URL: http://svn.apache.org/r1560214
>> Log:
>> Back port unit test fixes / improvements
>>
>> Modified:
>> tomcat/tc7.0.x/trunk/   (props changed)
>> 
>> tomcat/tc7.0.x/trunk/test/org/apache/tomcat/websocket/TestWebSocketFrameClient.java
>>
>> Propchange: tomcat/tc7.0.x/trunk/
>> --
>>   Merged /tomcat/trunk:r1560212-1560213
>>
>> Modified: 
>> tomcat/tc7.0.x/trunk/test/org/apache/tomcat/websocket/TestWebSocketFrameClient.java
>> URL: 
>> http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/test/org/apache/tomcat/websocket/TestWebSocketFrameClient.java?rev=1560214&r1=1560213&r2=1560214&view=diff
>> ==
>> --- 
>> tomcat/tc7.0.x/trunk/test/org/apache/tomcat/websocket/TestWebSocketFrameClient.java
>>  (original)
>> +++ 
>> tomcat/tc7.0.x/trunk/test/org/apache/tomcat/websocket/TestWebSocketFrameClient.java
>>  Tue Jan 21 22:45:35 2014
>> @@ -98,6 +98,12 @@ public class TestWebSocketFrameClient ex
>>
>>  @Test
>>  public void testBug56032() throws Exception {
>> +// TODO Investigate options to get this test to pass with the HTTP 
>> BIO
>> +//  connector.
>> +if (getTomcatInstance().getConnector().getProtocol().equals(
>> +"org.apache.coyote.http11.Http11Protocol")) {
>> +return;
>> +}
> 
> Connector.getProtocol() returns "HTTP/1.1" for BIO connector in Tomcat 7.
> Thus the above condition fails and the test is not skipped.
> 
> This code works in trunk, as the "HTTP/1.1" value is returned for NIO
> connector there.

Thanks. Fixed.

Mark


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

Re: Context switch integration

[Mark Thomas]

On 16/01/2014 15:08, Mark Thomas wrote:
> On 15/01/2014 15:59, Rémy Maucherat wrote:
>> 2014/1/15 Mark Thomas 
>>
>>>
>>> If folks integrating with Tomcat need to extend / replace what is
>>> currently in StandardContext.bindThread() and
>>> StandardContext.unbindThread() having a listener for this rather than
>>> having to extend StandardContext makes sense to me.
>>>
>>
>> Ok.
>>
>>>
>>> I'm not sure I follow what you are proposing for PAs.
>>>
>>> Nothing, if a utility class was doing the PA itself to make it easier and
>> do PA + setContextCL + call the listener, there would be more PAs (maybe a
>> performance impact).
> 
> Thanks for the clarification. No objections here.

I've been looking at this some more with an eye to reducing code
duplication. I think the thread binding listener could be merged with
the ContainerListener. I can't see a good reason to keep them apart at
this point. With this in mind, the changes I'm planning are:

- Add bindThread() and unbindThread() to the Context interface
- Add optional PA (as in callers can opt to use it if they wish)
  support to bindThread() and unbindThread()
- Switch all the components currently implementing their own
  bind/unbind methods to use these new context methods
- Switch container event type to use an enum
- Add bind and unbind events to this new enum
- Remove ThreadBindingListener

The main benefit of this is that all the actions required on bind and
unbind will be in a single place rather than duplicated (sometimes
inconsistently) across the code base.

Mark

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

Re: Context switch integration

[Rémy Maucherat]

2014/1/22 Mark Thomas 

> I've been looking at this some more with an eye to reducing code
> duplication. I think the thread binding listener could be merged with
> the ContainerListener. I can't see a good reason to keep them apart at
> this point. With this in mind, the changes I'm planning are:
>
> - Add bindThread() and unbindThread() to the Context interface
> - Add optional PA (as in callers can opt to use it if they wish)
>   support to bindThread() and unbindThread()
> - Switch all the components currently implementing their own
>   bind/unbind methods to use these new context methods
> - Switch container event type to use an enum
> - Add bind and unbind events to this new enum
> - Remove ThreadBindingListener
>
> The main benefit of this is that all the actions required on bind and
> unbind will be in a single place rather than duplicated (sometimes
> inconsistently) across the code base.
>
> +1

Rémy

[Bug 56050] NPE in WebappClassLoader.clearReferencesJdbc on shutdown

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=56050

Konstantin Kolinko  changed:

   What|Removed |Added

 Status|REOPENED|NEEDINFO

--- Comment #3 from Konstantin Kolinko  ---
How can it happen?

http://svn.apache.org/viewvc/tomcat/tc7.0.x/tags/TOMCAT_7_0_50/java/org/apache/catalina/loader/WebappClassLoader.java?view=markup#l2054

The only dereferences on that line are in
"this.getClass().getProtectionDomain()" so "this" is null, or "this.getClass()"
is null?
Both of those should not happen.

Is "ClassLoader.defineClass(..)" a native method on that JVM, so it is not
included in stacktrace?

Is that JVM broken?

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

buildbot success in ASF Buildbot on tomcat-7-trunk

[buildbot]

The Buildbot has detected a restored build on builder tomcat-7-trunk while 
building ASF Buildbot.
Full details are available at:
 http://ci.apache.org/builders/tomcat-7-trunk/builds/1705

Buildbot URL: http://ci.apache.org/

Buildslave for this Build: bb-vm_ubuntu

Build Reason: scheduler
Build Source Stamp: [branch tomcat/tc7.0.x/trunk] 1560274
Blamelist: markt

Build succeeded!

sincerely,
 -The Buildbot

svn commit: r1560290 - /tomcat/trunk/java/org/apache/catalina/ContainerEventType.java

[markt]

Author: markt
Date: Wed Jan 22 09:17:21 2014
New Revision: 1560290

URL: http://svn.apache.org/r1560290
Log:
Initial enum for ContainerEventType. Lots more event types to add.

Added:
tomcat/trunk/java/org/apache/catalina/ContainerEventType.java   (with props)

Added: tomcat/trunk/java/org/apache/catalina/ContainerEventType.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/ContainerEventType.java?rev=1560290&view=auto
==
--- tomcat/trunk/java/org/apache/catalina/ContainerEventType.java (added)
+++ tomcat/trunk/java/org/apache/catalina/ContainerEventType.java Wed Jan 22 
09:17:21 2014
@@ -0,0 +1,44 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ *  http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.catalina;
+
+public enum ContainerEventType {
+
+/**
+ * The ContainerEvent event type sent when a child container is added
+ * by addChild().
+ */
+ADD_CHILD,
+
+/**
+ * The ContainerEvent event type sent when a child container is removed
+ * by removeChild().
+ */
+REMOVE_CHILD,
+
+/**
+ * The ContainerEvent event type sent when a valve is added
+ * by addValve(), if this Container supports pipelines.
+ */
+ADD_VALVE,
+
+/**
+ * The ContainerEvent event type sent when a valve is removed
+ * by removeValve(), if this Container supports pipelines.
+ */
+REMOVE_VALVE;
+}

Propchange: tomcat/trunk/java/org/apache/catalina/ContainerEventType.java
--
svn:eol-style = native



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

Re: Context switch integration

[Konstantin Kolinko]

2014/1/22 Mark Thomas :
> On 16/01/2014 15:08, Mark Thomas wrote:
>> On 15/01/2014 15:59, Rémy Maucherat wrote:
>>> 2014/1/15 Mark Thomas 
>>>

 If folks integrating with Tomcat need to extend / replace what is
 currently in StandardContext.bindThread() and
 StandardContext.unbindThread() having a listener for this rather than
 having to extend StandardContext makes sense to me.

>>>
>>> Ok.
>>>

 I'm not sure I follow what you are proposing for PAs.

 Nothing, if a utility class was doing the PA itself to make it easier and
>>> do PA + setContextCL + call the listener, there would be more PAs (maybe a
>>> performance impact).
>>
>> Thanks for the clarification. No objections here.
>
> I've been looking at this some more with an eye to reducing code
> duplication. I think the thread binding listener could be merged with
> the ContainerListener. I can't see a good reason to keep them apart at
> this point.

1. If there are many ContainerListeners installed you will be calling
them with an event that they are not interested to handle. It wastes
time.

> With this in mind, the changes I'm planning are:
>
> - Add bindThread() and unbindThread() to the Context interface

Do you mean as a generic replacement to Thread.setContextClassLoader() calls?
I think the current methods of StandardContext are not suitable for
such exposure.

AFAIK, JNDI works in the following way:
1) org.apache.naming.java.javaURLContextFactory  class is configured
as the value of System.getProperty(Context.INITIAL_CONTEXT_FACTORY
).
It is normally done by Catalina.initNaming() or by Tomcat.enableNaming()

2) javax.naming.spi.NamingManager.getInitialContext() calls
javaURLContextFactory.getInitialContext()
and it returns an instance of org.apache.naming.SelectorContext

3) SelectorContext  uses either current thread or TCCL to find a JNDI
context in a lookup table.

Thus I think that the calls to ContextBindings.bindThread(...) /
unbindThread(...)  as performed by those StandardContext methods  are
needed only during some initial set up.  Using them as general methods
would be a waste. Those methods are overly synchronized and may be a
nuisance.

> - Add optional PA (as in callers can opt to use it if they wish)
>   support to bindThread() and unbindThread()

What do you mean by "PA"?

> - Switch all the components currently implementing their own
>   bind/unbind methods to use these new context methods
> - Switch container event type to use an enum

Enums are better than Strings for performance,
but I am not sure whether those can be extended if needed.

I'd prefer to keep Strings here.

> - Add bind and unbind events to this new enum
> - Remove ThreadBindingListener
>
> The main benefit of this is that all the actions required on bind and
> unbind will be in a single place rather than duplicated (sometimes
> inconsistently) across the code base.

Best regards,
Konstantin Kolinko

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

svn commit: r1560303 - /tomcat/trunk/java/org/apache/catalina/ContainerEventType.java

[markt]

Author: markt
Date: Wed Jan 22 10:17:10 2014
New Revision: 1560303

URL: http://svn.apache.org/r1560303
Log:
Drop this idea for now

Removed:
tomcat/trunk/java/org/apache/catalina/ContainerEventType.java


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

Re: Context switch integration

[Rémy Maucherat]

2014/1/22 Konstantin Kolinko 

> Thus I think that the calls to ContextBindings.bindThread(...) /
> unbindThread(...)  as performed by those StandardContext methods  are
> needed only during some initial set up.  Using them as general methods
> would be a waste. Those methods are overly synchronized and may be a
> nuisance.
>
> It is true these two are only needed during start/stop, and they do more
than what is otherwise needed.

On the overuse of container events, they are called for configuration
changes and (for whatever reason) all session updates. The session updates
indeed mean setting one listener is a rather big impact for meany
applications (if they use lots of session attributes). Ultimately, I added
a dedicated thing because it is a thing EE needs so it got graduated to
something more visible and straightforward to use.

Last [not directly related], looking at the code, I notice that session
expiration already takes care of changing the context CL. I was not aware
of that, and it means I need to drop/rework my SSO patch. Oops. And I'll
also rework the session code since it switches context even if not needed
(in most cases, it is not needed). I'll do that when Mark is done.

Rémy

Re: Context switch integration

[Mark Thomas]

On 22/01/2014 09:42, Konstantin Kolinko wrote:
> 2014/1/22 Mark Thomas :



>> I've been looking at this some more with an eye to reducing code
>> duplication. I think the thread binding listener could be merged with
>> the ContainerListener. I can't see a good reason to keep them apart at
>> this point.
> 
> 1. If there are many ContainerListeners installed you will be calling
> them with an event that they are not interested to handle. It wastes
> time.

Fair point. This is something that gets called several times on every
request. That probably makes the case for a separate listener.

> 
>> With this in mind, the changes I'm planning are:
>>
>> - Add bindThread() and unbindThread() to the Context interface
> 
> Do you mean as a generic replacement to Thread.setContextClassLoader() calls?
> I think the current methods of StandardContext are not suitable for
> such exposure.

Sort of, with some refactoring because of the JNDI aspects you
mentioned. My main aim is to reduce code duplication.

>> - Add optional PA (as in callers can opt to use it if they wish)
>>   support to bindThread() and unbindThread()
> 
> What do you mean by "PA"?

PrivilegedAction

>> - Switch all the components currently implementing their own
>>   bind/unbind methods to use these new context methods
>> - Switch container event type to use an enum
> 
> Enums are better than Strings for performance,
> but I am not sure whether those can be extended if needed.
> 
> I'd prefer to keep Strings here.

Do we need to extend these? This is all internal to Tomcat. We can add
values to the enum as easily as we can use new String values.

>> - Add bind and unbind events to this new enum
>> - Remove ThreadBindingListener
>>
>> The main benefit of this is that all the actions required on bind and
>> unbind will be in a single place rather than duplicated (sometimes
>> inconsistently) across the code base.

This is really what I am aiming at. There are several places across the
code that do call near enough exactly the code to bind and unbind the
context class loader. It is this duplication I want to remove.

I'll start again and address my primary concern - the duplicate code.
The other aspects I'm happy to think about / discuss further with a view
to possibly coming back to them later.

Mark


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

JDK 8 Build 124 & JDK 7 Update 60 build 03 are available on java.net

[Rory O'Donnell Oracle, Dublin Ireland]

Hi Mladen,

JDK 8 Build b124 Early Access Build is now available for download 
 & test.
JDK 7u60 b03 Early Access Build is also available for download 
& test.


Please log all show stopper issues as soon as possible.

If you are going to FOSDEM next week,please let me know we should meet up.

Thanks for your support, Rory

--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland

[Bug 56051] New: FarmWarDeployer sporadically fails with "application being serviced"

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=56051

Bug ID: 56051
   Summary: FarmWarDeployer sporadically fails with "application
being serviced"
   Product: Tomcat 7
   Version: 7.0.28
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P2
 Component: Cluster
  Assignee: dev@tomcat.apache.org
  Reporter: m.glo...@gmail.com

We are trying to use FarmWarDeployer at the moment, however it fails
ocassionally on the "slave" nodes with the following log message:

Jan 22, 2014 11:00:23 AM org.apache.catalina.ha.deploy.FarmWarDeployer
messageReceived
SEVERE: Application [/xxx] is being serviced. Touch war file [xxx.war] again!

It occurs sporadically and after touching the war the deployment usually works
in a second try. However it is pretty annoying because we always have to check
if deployment might have failed or not on individual nodes.

-

Email Feedback from Mark:

It usually means that the manager application or the auto deployment code is
doing something (starting, stopping, deploying, undeploying etc) the web
application.

The Javadoc looks like it could do with some fixes.

Looking at the docs and the code, the problem is that the FarmWarDeployer
writes the WAR to the appBase and then marks it is serviced. This means that
the auto deployment code may get there first which confuses the
FarmWarDeployer.

I'd say this is a bug in the FarmWarDeployer. Please open a Bugzilla entry.

As a work-around, you should be able to disable automatic deployment
(untested).

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

svn commit: r1560363 - in /tomcat/trunk/java/org/apache/catalina: authenticator/SingleSignOn.java security/SecurityClassLoad.java session/StandardSession.java

[remm]

Author: remm
Date: Wed Jan 22 14:39:51 2014
New Revision: 1560363

URL: http://svn.apache.org/r1560363
Log:
- Drop the code from SSO (I didn't know StandardSession.expire was already 
setting the context CL.
- Add bind/unbind to StandardSession.expire instead (and only do it if the 
classloader actually changes).
- See later if the bind/unbind code can be moved to StandardContext, but all 
uses seem slightly different.

Modified:
tomcat/trunk/java/org/apache/catalina/authenticator/SingleSignOn.java
tomcat/trunk/java/org/apache/catalina/security/SecurityClassLoad.java
tomcat/trunk/java/org/apache/catalina/session/StandardSession.java

Modified: tomcat/trunk/java/org/apache/catalina/authenticator/SingleSignOn.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/authenticator/SingleSignOn.java?rev=1560363&r1=1560362&r2=1560363&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/authenticator/SingleSignOn.java 
(original)
+++ tomcat/trunk/java/org/apache/catalina/authenticator/SingleSignOn.java Wed 
Jan 22 14:39:51 2014
@@ -20,23 +20,17 @@ package org.apache.catalina.authenticato
 
 
 import java.io.IOException;
-import java.security.AccessController;
 import java.security.Principal;
-import java.security.PrivilegedAction;
 import java.util.HashMap;
 import java.util.Map;
 
 import javax.servlet.ServletException;
 import javax.servlet.http.Cookie;
 
-import org.apache.catalina.Context;
-import org.apache.catalina.Globals;
-import org.apache.catalina.Manager;
 import org.apache.catalina.Realm;
 import org.apache.catalina.Session;
 import org.apache.catalina.SessionEvent;
 import org.apache.catalina.SessionListener;
-import org.apache.catalina.ThreadBindingListener;
 import org.apache.catalina.connector.Request;
 import org.apache.catalina.connector.Response;
 import org.apache.catalina.valves.ValveBase;
@@ -421,15 +415,7 @@ public class SingleSignOn extends ValveB
 reverse.remove(sessions[i]);
 }
 // Invalidate this session
-ClassLoader oldContextClassLoader = null;
-try {
-oldContextClassLoader = bindThread(sessions[i]);
-sessions[i].expire();
-} finally {
-if (oldContextClassLoader != null) {
-unbindThread(sessions[i], oldContextClassLoader);
-}
-}
+sessions[i].expire();
 }
 
 // NOTE:  Clients may still possess the old single sign on cookie,
@@ -438,97 +424,6 @@ public class SingleSignOn extends ValveB
 
 }
 
-protected ClassLoader bindThread(Session session) {
-
-Manager manager = session.getManager();
-Context context = null;
-ClassLoader contextClassLoader = null;
-ThreadBindingListener threadBindingListener = null;
-if (manager != null) {
-context = manager.getContext();
-}
-if (context != null) {
-if (context.getLoader() != null && 
context.getLoader().getClassLoader() != null) {
-contextClassLoader = context.getLoader().getClassLoader();
-}
-threadBindingListener = context.getThreadBindingListener();
-}
-if (threadBindingListener == null || contextClassLoader == null) {
-return null;
-}
-
-if (Globals.IS_SECURITY_ENABLED) {
-return AccessController.doPrivileged(new 
PrivilegedBind(contextClassLoader, threadBindingListener));
-} else {
-ClassLoader oldContextClassLoader =
-Thread.currentThread().getContextClassLoader();
-Thread.currentThread().setContextClassLoader(contextClassLoader);
-threadBindingListener.bind();
-return oldContextClassLoader;
-}
-
-}
-
-protected class PrivilegedBind implements PrivilegedAction {
-private ClassLoader contextClassLoader;
-private ThreadBindingListener threadBindingListener;
-
-PrivilegedBind(ClassLoader contextClassLoader, ThreadBindingListener 
threadBindingListener) {
-this.contextClassLoader = contextClassLoader;
-this.threadBindingListener = threadBindingListener;
-}
-
-@Override
-public ClassLoader run() {
-ClassLoader oldContextClassLoader =
-Thread.currentThread().getContextClassLoader();
-Thread.currentThread().setContextClassLoader(contextClassLoader);
-threadBindingListener.bind();
-return oldContextClassLoader;
-}
-}
-
-protected void unbindThread(Session session, ClassLoader 
oldContextClassLoader) {
-
-Manager manager = session.getManager();
-Context context = null;
-ThreadBindingListener threadBindingListener = null;
-if (manager != null) {
-context = manager.getContext();
-  

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

[schultz]

Author: schultz
Date: Wed Jan 22 15:34:50 2014
New Revision: 1560387

URL: http://svn.apache.org/r1560387
Log:
Vote

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=1560387&r1=1560386&r2=1560387&view=diff
==
--- tomcat/tc6.0.x/trunk/STATUS.txt (original)
+++ tomcat/tc6.0.x/trunk/STATUS.txt Wed Jan 22 15:34:50 2014
@@ -33,7 +33,7 @@ PATCHES PROPOSED TO BACKPORT:
 * BIO tolerates whitespace in the ciphers attribute whereas NIO does not. Make
   NIO tolerate it as well
   
http://people.apache.org/~markt/patches/2014-01-18-ciphers-whitespace-nio-tc6-v1.patch
-  +1: markt, rjung
+  +1: markt, rjung, schultz
   +1: kkolinko: OK, though I have two comments:
1. If we align NIO and BIO here, the code in 
JSSESocketFactory.getEnabledCiphers(..)
also skips empty tokens.



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

[jira] [Commented] (MTOMCAT-257) Classpathes separation between plugin and application is broken (can't use slf4j-jcl in app)

[Andreas Christoforides (JIRA)]

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

Andreas Christoforides commented on MTOMCAT-257:


I am having a similar issue but with the Google Guava dependency (version 
15.0). 

Setup:
* useSeparateTomcatClassLoader is enabled
* Google Guava version in dependency management is 15.0
* Using tomcat6:run

I was getting a NoSuchMethodException when using a Google Guava method that was 
added in version 15.0. I enabled the -verbose:class flag and I noticed that all 
the Google Guava classes for my webapp were being loaded from version 10.0.1 
instead of version 15.0.

The problem does NOT occur when running the WAR in a standalone Tomcat instance.

Google Guava version 10.0.1 is actually one of the dependencies of the Maven 
Tomcat plugin itself. It seems that dependencies from the plugin are mixed with 
the webapp even if the setting useSeparateTomcatClassLoader is enabled.

> Classpathes separation between plugin and application is broken (can't use 
> slf4j-jcl in app)
> 
>
> Key: MTOMCAT-257
> URL: https://issues.apache.org/jira/browse/MTOMCAT-257
> Project: Apache Tomcat Maven Plugin
>  Issue Type: Bug
>  Components: tomcat7
>Affects Versions: 2.1
>Reporter: Brendan Le Ny
>Assignee: Olivier Lamy (*$^¨%`£)
> Attachments: MTOMCAT-227-2.zip, MTOMCAT-227.tgz
>
>
> I use in my war the slf4j-jcl, which is not compatible with the 
> jcl-over-slf4j used in the plugin dependencies.
> I give you a little project that show the problem.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

Re: Context switch integration

[Christopher Schultz]

Mark,

On 1/22/14, 5:21 AM, Mark Thomas wrote:
> On 22/01/2014 09:42, Konstantin Kolinko wrote:
>> 2014/1/22 Mark Thomas :
> 
> 
> 
>>> I've been looking at this some more with an eye to reducing code
>>> duplication. I think the thread binding listener could be merged with
>>> the ContainerListener. I can't see a good reason to keep them apart at
>>> this point.
>>
>> 1. If there are many ContainerListeners installed you will be calling
>> them with an event that they are not interested to handle. It wastes
>> time.
> 
> Fair point. This is something that gets called several times on every
> request. That probably makes the case for a separate listener.
> 
>>
>>> With this in mind, the changes I'm planning are:
>>>
>>> - Add bindThread() and unbindThread() to the Context interface
>>
>> Do you mean as a generic replacement to Thread.setContextClassLoader() calls?
>> I think the current methods of StandardContext are not suitable for
>> such exposure.
> 
> Sort of, with some refactoring because of the JNDI aspects you
> mentioned. My main aim is to reduce code duplication.
> 
>>> - Add optional PA (as in callers can opt to use it if they wish)
>>>   support to bindThread() and unbindThread()
>>
>> What do you mean by "PA"?
> 
> PrivilegedAction
> 
>>> - Switch all the components currently implementing their own
>>>   bind/unbind methods to use these new context methods
>>> - Switch container event type to use an enum
>>
>> Enums are better than Strings for performance,
>> but I am not sure whether those can be extended if needed.
>>
>> I'd prefer to keep Strings here.
> 
> Do we need to extend these? This is all internal to Tomcat. We can add
> values to the enum as easily as we can use new String values.
> 
>>> - Add bind and unbind events to this new enum
>>> - Remove ThreadBindingListener
>>>
>>> The main benefit of this is that all the actions required on bind and
>>> unbind will be in a single place rather than duplicated (sometimes
>>> inconsistently) across the code base.
> 
> This is really what I am aiming at. There are several places across the
> code that do call near enough exactly the code to bind and unbind the
> context class loader. It is this duplication I want to remove.
> 
> I'll start again and address my primary concern - the duplicate code.
> The other aspects I'm happy to think about / discuss further with a view
> to possibly coming back to them later.

Could this be done more simply by providing a pair of utility methods to
do the enter/exit work rather than treating them as events to be
"handled"? That way, they can be invoked directly by components that
need them and ignored by those that don't.

-chris



signature.asc
Description: OpenPGP digital signature

Re: Context switch integration

[Mark Thomas]

On 22/01/2014 10:21, Mark Thomas wrote:

> I'll start again and address my primary concern - the duplicate code.
> The other aspects I'm happy to think about / discuss further with a view
> to possibly coming back to them later.

This is the sort of thing I was thinking about:
http://people.apache.org/~markt/dev/2014-01-22-tccl-tc8-v1.patch

It doesn't reduce the code as much as I had hoped.

It isn't complete but you get the idea of how all the class loader
binding/unbinding could move into the Context.

The main benefit is consistency. There is quite a variation in how class
loader binding/unbinding is done at the moment. I think, ultimately, it
will result in slightly less code.

What do folks think?

Mark

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

Re: Context switch integration

[Mark Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 22/01/2014 20:48, Christopher Schultz wrote:

>> I'll start again and address my primary concern - the duplicate
>> code. The other aspects I'm happy to think about / discuss
>> further with a view to possibly coming back to them later.
> 
> Could this be done more simply by providing a pair of utility
> methods to do the enter/exit work rather than treating them as
> events to be "handled"? That way, they can be invoked directly by
> components that need them and ignored by those that don't.

I thought about that. There is some coupling between the entry and
exit methods (the class loader) that the caller would need to retain
and some standard try/finally plumbing.

There is also an optimisation not to try to change the class loader if
there is no need to do so.

In an effort to reduce this common code for every caller, I started
down a different route. I do wonder if the entry/exit approach might
end up being cleaner as even with my approach, you end up with some
not so nice exception handling.

I'll see what folks think of the patch so far and maybe explore the
entry/exit option as well.

Mark

-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJS4DAnAAoJEBDAHFovYFnneMoP/2oA7IeOH+e7kENRJauAIQT9
2RqHHbfbE54m27PQUk8JtstskokT/p0AoTmrELo9VfJocgWKAjzD39+Zhsm8YgVk
9Z+eW25rheG/YDYTBHxNAMAl79EQhBDzyVL+04Ltgn11PLD9uqZR4HdOdietFXQc
wOXPW/hnnTbPXAXpK+EsXXPU5JDskjUIoXxWw7jjYX+MUHRsbnlbc8r9ky17sX3B
kyjcjLYGCXuB5zFzwVKzFGhA4Kx9vcLYq3Fw/bA1qf64JA9F7BljFnhxaotFVshQ
WIFjNl/g7ZwZV717iPUvUaP+/M1/Mq4EiE5iPRL+k8tGOBMR8A88z4dQ1nPmrsC/
HrJ7mJIaXKoyAj0GGmCcdSG1IlqINQa/zxe2LVZ6p2JsFA7ryNf0vvfzo4OSVqBP
M0A8PcC6kyrHlQ24SyGRfqcMzTiZdHQ0sFS1uYBbESkuyJ9ooxTR2/eCarzemvj6
KIUOqgDJcnHaHI/zjelrC5vBWlWIyZX2+AI27moO34YC5I3KIJ9DhJ99KjumGZup
PdMhszy2nFXHE2s9Q4H7mz5MJWQYmCYF/ecJV3evWgicA1EFVoM0jQfGRwRYTuhe
QdPD8ljAa7VvGZAcXcqfUDjmQ+l9SX/9nNLGIIEKLT+pHNsiL0WRPCGzxFGvOMQA
kppqlPlBvNJdecCKPVPb
=TamI
-END PGP SIGNATURE-

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

Re: Context switch integration

[Rémy Maucherat]

2014/1/22 Mark Thomas 

> I thought about that. There is some coupling between the entry and
> exit methods (the class loader) that the caller would need to retain
> and some standard try/finally plumbing.
>
> There is also an optimisation not to try to change the class loader if
> there is no need to do so.
>

That looks like a good summary !

>
> In an effort to reduce this common code for every caller, I started
> down a different route. I do wonder if the entry/exit approach might
> end up being cleaner as even with my approach, you end up with some
> not so nice exception handling.
>
> I'll see what folks think of the patch so far and maybe explore the
> entry/exit option as well.
>
> The first patch however looks more complicated than the "dumb" way IMO.

Rémy