Sorry, here is the change I made if additional or cookies already contains the name then just return...

io.undertow.util.Cookies:

    private static int createCookie(final String name, final String value, int maxCookies, int cookieCount,
            final Map<String, String> cookies, final Map<String, String> additional) {
        if (name.charAt(0) == '$') {
//added
            if(additional.containsKey(name)) {
                return cookieCount;
            }
            additional.put(name, value);
            return cookieCount;
        } else {
            if (cookieCount == maxCookies) {
                throw UndertowMessages.MESSAGES.tooManyCookies(maxCookies);
            }
//added
            if(cookies.containsKey(name)) {
                return cookieCount;
            }
            cookies.put(name, value);
            return ++cookieCount;
        }
    }


On Fri, Apr 25, 2014 at 2:43 PM, Derrick Childers <derrick.childers@gmail.com> wrote:
I think I've found a bug in undertow and I have patch.  I thought I'd explain.  We have multiple War's serving a site.  One war covers the root context '/' and a variety of sub paths/contexts.  A couple of other war's server specific sub contexts, such as /selfserve.  If you open a browser and go to / and look at the browser cookies you will see JSESSIONID with path=/.  Then go to /selfserve and look at the cookies.  You now have two JSESSIONID cookies.  One for path=/ and one for path=/selfserve.  As far as I know this is all normal and correct.  From here when my app tries to use the session it fails in various ways.  What I found was that if I deleted the JSESSIONID cookie that was associated with path=/ then everything worked.  After digging around in the code I found where the cookies are being added to a HashMap by the name.  It looks like the last cookie loaded wins, which means the correct cookie is loaded first then overridden by the wrong one.

I have a patch in git and can send a pull request.

--
Derrick Childers



--
Derrick Childers