[Bug 58178] New: Exception not passed to c:catch in custom jsp tag

2015-07-24 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=58178

Bug ID: 58178
   Summary: Exception not passed to c:catch in custom jsp tag
   Product: Tomcat 8
   Version: 8.0.23
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: Jasper
  Assignee: dev@tomcat.apache.org
  Reporter: j...@intalio.com

Created attachment 32935
  --> https://bz.apache.org/bugzilla/attachment.cgi?id=32935&action=edit
Project demonstrating the problem

If a custom tag uses the jstl  tag, then the exception is saved into the
page attributes, but is not actually available to other tags via EL
expressions.

If, however, the  tag is used directly in a jsp page, then the exception
is propagated into the var and visible to subsequent El expressions.


I'm attaching a small project that contains a taglib that demonstrates the
problem. The project contains 2 jsps:

1. no-tagtest.jsp that uses the  and other jstl tags directly in the jsp
2. tagtest.jsp that references a custom tag that uses the  and other
jstl tags.

The problem seems to be that when a custom tag uses any other tags, then the
page context is an instance of JspContextWrapper. When resolving el
expressions, the JspContextWrapper.getElContext() returns an ELContext for the
rootContext, rather than the page context. In this example, the  tag
saves the exception as an attribute named "error" in the page context
attributes (the page context will be an instance of JspContextWrapper).
However, when the "error" variable is referenced later in an EL expression, the
EL mechanism has a page context that is the root context of the
JspContextWrapper and thus can't resolve that variable.

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



[Bug 58179] New: Atomicity violation

2015-07-24 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=58179

Bug ID: 58179
   Summary: Atomicity violation
   Product: Tomcat 7
   Version: 7.0.63
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P2
 Component: Catalina
  Assignee: dev@tomcat.apache.org
  Reporter: baiguangd...@gmail.com

My name is Bai Guangdong, a research fellow from National University of
Singapore. I find an atomicity violation similar to bug 53498. 

The problem occurs in the same file
java/org/apache/catalina/core/ApplicationContext.java. Look at the code snippet
below. 

L791 oldValue = attributes.get(name);
L792 if (oldValue != null)
L793 replaced = true;
L794 attributes.put(name, value);
...  ... 
L801 if (replaced)
L802 event =
L803 new
ServletContextAttributeEvent(context.getServletContext(),
L804  name, oldValue);
L805 else
L806 event =
L807 new
ServletContextAttributeEvent(context.getServletContext(),
L808  name, value);
...  ... 
L816 if (replaced) {
L817 context.fireContainerEvent
L818 ("beforeContextAttributeReplaced", listener);
L819 listener.attributeReplaced(event);
L820
context.fireContainerEvent("afterContextAttributeReplaced",
L821listener);
L822 } else {
L823
context.fireContainerEvent("beforeContextAttributeAdded",
L824listener);
L825 listener.attributeAdded(event);
L826
context.fireContainerEvent("afterContextAttributeAdded",
L827listener);

Suppose two threads T1 and T2 executes this code snippet with the same key
("name"). Initially, "attributes" is empty. T1 executes line 791 and "oldValue"
in T1 becomes null. Before T1 executes line 794, T2 executes 791 and "oldValue"
in T2 becomes null as well. Then T1 executes line 794, and later T2 replaces
T1's "value" at line 794. Afterwards, both T1 and T2 fire the
"beforeContextAttributeAdded" event at line 823. However, in the above
situation, "replaced" in T2 should be true and "beforeContextAttributeReplaced"
should be fired at line 817.

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