[jira] [Commented] (OGNL-20) Performance - Replace synchronized blocks with ReentrantReadWriteLock
[
https://issues.apache.org/jira/browse/OGNL-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13128104#comment-13128104
]
Maurizio Cucchiara commented on OGNL-20:
Hi Daniel,
Thanks for your preciuos feedback.
This is exactly what I came to my mind.
I'm going in the following direction:
{code}
public class MethodCacheTest
{
CacheMethodCacheEntry, MapString, ListMethod cache =
new ConcurrentHashMapCacheMethodCacheEntry,MapString,
ListMethod( new MethodCacheEntryFactory());
@Test
public void testStaticGet( )
throws Exception
{
MapString, ListMethod methods = cache.get( new MethodCacheEntry(
Root.class,true ) );
assertNotNull( methods );
assertTrue( methods.containsKey( getStaticInt ) );
}
@Test
public void testNonStaticGet( )
throws Exception
{
MapString, ListMethod methods = cache.get( new MethodCacheEntry(
Root.class,false) );
assertNotNull( methods );
assertTrue( methods.containsKey( format ) );
}
}
{code}
{code}
public class MethodCacheEntry implements CacheEntry
{
private Class? targetClass;
private boolean staticMethods;
public MethodCacheEntry( Class? targetClass, boolean staticMethods )
{
this.targetClass = targetClass;
this.staticMethods = staticMethods;
}
@Override
public int hashCode( )
{
int result = targetClass.hashCode( );
result = 31 * result + ( staticMethods ? 1 : 0 );
return result;
}
}
{code}
Performance - Replace synchronized blocks with ReentrantReadWriteLock
-
Key: OGNL-20
URL: https://issues.apache.org/jira/browse/OGNL-20
Project: OGNL
Issue Type: Improvement
Environment: ALL
Reporter: Greg Lively
Attachments: Bench Results.txt, Caching_Mechanism_Benchmarks.patch
I've noticed a lot of synchronized blocks of code in OGNL. For the most part,
these synchronized blocks are controlling access to HashMaps, etc. I believe
this could be done far better using ReentrantReadWriteLocks.
ReentrantReadWriteLock allows unlimited concurrent access, and single threads
only for writes. Perfect in an environment where the ratio of reads is far
higher than writes; which is typically the scenario for caching. Plus the
access control can be tuned for reads and writes; not just a big
synchronized{} wrapping a bunch of code.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (OGNL-20) Performance - Replace synchronized blocks with ReentrantReadWriteLock
[
https://issues.apache.org/jira/browse/OGNL-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13128104#comment-13128104
]
Maurizio Cucchiara edited comment on OGNL-20 at 10/15/11 8:19 AM:
--
Hi Daniel,
Thanks for your preciuos feedback.
This is exactly what came to my mind (which, IIUC, is more or less what you
suggested before).
I'm going in the following direction:
{code}
public class MethodCacheTest
{
CacheMethodCacheEntry, MapString, ListMethod cache =
new ConcurrentHashMapCacheMethodCacheEntry,MapString,
ListMethod( new MethodCacheEntryFactory());
@Test
public void testStaticGet( )
throws Exception
{
MapString, ListMethod methods = cache.get( new MethodCacheEntry(
Root.class,true ) );
assertNotNull( methods );
assertTrue( methods.containsKey( getStaticInt ) );
}
@Test
public void testNonStaticGet( )
throws Exception
{
MapString, ListMethod methods = cache.get( new MethodCacheEntry(
Root.class,false) );
assertNotNull( methods );
assertTrue( methods.containsKey( format ) );
}
}
{code}
{code}
public class MethodCacheEntry implements CacheEntry
{
private Class? targetClass;
private boolean staticMethods;
public MethodCacheEntry( Class? targetClass, boolean staticMethods )
{
this.targetClass = targetClass;
this.staticMethods = staticMethods;
}
@Override
public int hashCode( )
{
int result = targetClass.hashCode( );
result = 31 * result + ( staticMethods ? 1 : 0 );
return result;
}
}
{code}
was (Author: maurizio.cucchiara):
Hi Daniel,
Thanks for your preciuos feedback.
This is exactly what I came to my mind.
I'm going in the following direction:
{code}
public class MethodCacheTest
{
CacheMethodCacheEntry, MapString, ListMethod cache =
new ConcurrentHashMapCacheMethodCacheEntry,MapString,
ListMethod( new MethodCacheEntryFactory());
@Test
public void testStaticGet( )
throws Exception
{
MapString, ListMethod methods = cache.get( new MethodCacheEntry(
Root.class,true ) );
assertNotNull( methods );
assertTrue( methods.containsKey( getStaticInt ) );
}
@Test
public void testNonStaticGet( )
throws Exception
{
MapString, ListMethod methods = cache.get( new MethodCacheEntry(
Root.class,false) );
assertNotNull( methods );
assertTrue( methods.containsKey( format ) );
}
}
{code}
{code}
public class MethodCacheEntry implements CacheEntry
{
private Class? targetClass;
private boolean staticMethods;
public MethodCacheEntry( Class? targetClass, boolean staticMethods )
{
this.targetClass = targetClass;
this.staticMethods = staticMethods;
}
@Override
public int hashCode( )
{
int result = targetClass.hashCode( );
result = 31 * result + ( staticMethods ? 1 : 0 );
return result;
}
}
{code}
Performance - Replace synchronized blocks with ReentrantReadWriteLock
-
Key: OGNL-20
URL: https://issues.apache.org/jira/browse/OGNL-20
Project: OGNL
Issue Type: Improvement
Environment: ALL
Reporter: Greg Lively
Attachments: Bench Results.txt, Caching_Mechanism_Benchmarks.patch
I've noticed a lot of synchronized blocks of code in OGNL. For the most part,
these synchronized blocks are controlling access to HashMaps, etc. I believe
this could be done far better using ReentrantReadWriteLocks.
ReentrantReadWriteLock allows unlimited concurrent access, and single threads
only for writes. Perfect in an environment where the ratio of reads is far
higher than writes; which is typically the scenario for caching. Plus the
access control can be tuned for reads and writes; not just a big
synchronized{} wrapping a bunch of code.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OGNL-11) Checkstyle configuration is broken and fix some checktyle issues
[ https://issues.apache.org/jira/browse/OGNL-11?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13128105#comment-13128105 ] Hudson commented on OGNL-11: Integrated in ognl #136 (See [https://builds.apache.org/job/ognl/136/]) OGNL-11: fixed checkstyle errors grobmeier : http://svn.apache.org/viewvc/?view=revrev=1183602 Files : * /commons/proper/ognl/trunk/src/main/java/org/apache/commons/ognl/ASTAdd.java Checkstyle configuration is broken and fix some checktyle issues Key: OGNL-11 URL: https://issues.apache.org/jira/browse/OGNL-11 Project: OGNL Issue Type: Bug Reporter: Simone Tripodi Assignee: Olivier Lamy TabCharacter module is misconfigured and cause a fail with both Mavven 2/3, refer to discussion on dev ML[1] [1] http://markmail.org/message/mgkzlzdi4xlz7hpp -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OGNL-11) Checkstyle configuration is broken and fix some checktyle issues
[ https://issues.apache.org/jira/browse/OGNL-11?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13128114#comment-13128114 ] Hudson commented on OGNL-11: Integrated in ognl #137 (See [https://builds.apache.org/job/ognl/137/]) OGNL-11: more fixed checkstyle errors grobmeier : http://svn.apache.org/viewvc/?view=revrev=1183611 Files : * /commons/proper/ognl/trunk/src/main/java/org/apache/commons/ognl/ASTAnd.java Checkstyle configuration is broken and fix some checktyle issues Key: OGNL-11 URL: https://issues.apache.org/jira/browse/OGNL-11 Project: OGNL Issue Type: Bug Reporter: Simone Tripodi Assignee: Olivier Lamy TabCharacter module is misconfigured and cause a fail with both Mavven 2/3, refer to discussion on dev ML[1] [1] http://markmail.org/message/mgkzlzdi4xlz7hpp -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DAEMON-178) jsvc process does not take the umask of the running user. It is always 077
[ https://issues.apache.org/jira/browse/DAEMON-178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13128233#comment-13128233 ] Michael Osipov commented on DAEMON-178: --- Cannot this be make easier by providing simply a -umask option in the jsvc binary? It is cumbersome to recompile the binary over and over again. jsvc process does not take the umask of the running user. It is always 077 -- Key: DAEMON-178 URL: https://issues.apache.org/jira/browse/DAEMON-178 Project: Commons Daemon Issue Type: Bug Components: Jsvc Affects Versions: 1.0.3 Environment: Ubuntu Hardy 8.0.4, jdk1.6.2 Reporter: J Miller Fix For: 1.0.4 1) create a simple implementation of the Daemon interface that writes hello world log files 2) compile jsvc as described in the documentation 3) verify that your linux user has umask != 077, by typing umask 4) start jsvc with all the required CP args as described in the documentation 5) look the log file permissions Expected: The permissions are not 700. Actual: They are 700. 6) Modify commons-daemon/src/native/unix/native/jsvc-unix.c, replacing 077 with 022 7) recompile jsvc 8) repeat 4-5 Expected: The permissions are 755. Actual: The permissions are 755. Conclusion: The jsvc process uses a hard-coded value, instead of adopting the running user's umask, as expected. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (DAEMON-178) jsvc process does not take the umask of the running user. It is always 077
[ https://issues.apache.org/jira/browse/DAEMON-178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13128233#comment-13128233 ] Michael Osipov edited comment on DAEMON-178 at 10/15/11 4:21 PM: - Cannot this be made easier by providing simply a -umask option in the jsvc binary? It is cumbersome to recompile the binary over and over again. was (Author: michael-o): Cannot this be make easier by providing simply a -umask option in the jsvc binary? It is cumbersome to recompile the binary over and over again. jsvc process does not take the umask of the running user. It is always 077 -- Key: DAEMON-178 URL: https://issues.apache.org/jira/browse/DAEMON-178 Project: Commons Daemon Issue Type: Bug Components: Jsvc Affects Versions: 1.0.3 Environment: Ubuntu Hardy 8.0.4, jdk1.6.2 Reporter: J Miller Fix For: 1.0.4 1) create a simple implementation of the Daemon interface that writes hello world log files 2) compile jsvc as described in the documentation 3) verify that your linux user has umask != 077, by typing umask 4) start jsvc with all the required CP args as described in the documentation 5) look the log file permissions Expected: The permissions are not 700. Actual: They are 700. 6) Modify commons-daemon/src/native/unix/native/jsvc-unix.c, replacing 077 with 022 7) recompile jsvc 8) repeat 4-5 Expected: The permissions are 755. Actual: The permissions are 755. Conclusion: The jsvc process uses a hard-coded value, instead of adopting the running user's umask, as expected. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (DAEMON-178) jsvc process does not take the umask of the running user. It is always 077
[ https://issues.apache.org/jira/browse/DAEMON-178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13128233#comment-13128233 ] Michael Osipov edited comment on DAEMON-178 at 10/15/11 4:22 PM: - Cannot this be made easier by providing simply a -umask option in the jsvc binary? It is cumbersome to recompile the source over and over again. was (Author: michael-o): Cannot this be made easier by providing simply a -umask option in the jsvc binary? It is cumbersome to recompile the binary over and over again. jsvc process does not take the umask of the running user. It is always 077 -- Key: DAEMON-178 URL: https://issues.apache.org/jira/browse/DAEMON-178 Project: Commons Daemon Issue Type: Bug Components: Jsvc Affects Versions: 1.0.3 Environment: Ubuntu Hardy 8.0.4, jdk1.6.2 Reporter: J Miller Fix For: 1.0.4 1) create a simple implementation of the Daemon interface that writes hello world log files 2) compile jsvc as described in the documentation 3) verify that your linux user has umask != 077, by typing umask 4) start jsvc with all the required CP args as described in the documentation 5) look the log file permissions Expected: The permissions are not 700. Actual: They are 700. 6) Modify commons-daemon/src/native/unix/native/jsvc-unix.c, replacing 077 with 022 7) recompile jsvc 8) repeat 4-5 Expected: The permissions are 755. Actual: The permissions are 755. Conclusion: The jsvc process uses a hard-coded value, instead of adopting the running user's umask, as expected. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (OGNL-27) Move toString implementations into visitor pattern.
Move toString implementations into visitor pattern. - Key: OGNL-27 URL: https://issues.apache.org/jira/browse/OGNL-27 Project: OGNL Issue Type: New Feature Reporter: Daniel Pitts Using the Visitor pattern allows for a cleaner implementation of toString(). I have a patch which will remove toString() from all AST classes, and replace it with a single toString() in SimpleNode which delegates to a ToStringVisitor to build the String efficiently. This patch can also be used as an example of how to move other business logic out of the AST classes into their own visitor classes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OGNL-27) Move toString implementations into visitor pattern.
[ https://issues.apache.org/jira/browse/OGNL-27?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Pitts updated OGNL-27: - Attachment: to_string_visitor1.patch This patch replaces the mishmash of toString methods in the AST classes. Move toString implementations into visitor pattern. - Key: OGNL-27 URL: https://issues.apache.org/jira/browse/OGNL-27 Project: OGNL Issue Type: New Feature Reporter: Daniel Pitts Attachments: to_string_visitor1.patch Using the Visitor pattern allows for a cleaner implementation of toString(). I have a patch which will remove toString() from all AST classes, and replace it with a single toString() in SimpleNode which delegates to a ToStringVisitor to build the String efficiently. This patch can also be used as an example of how to move other business logic out of the AST classes into their own visitor classes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OGNL-27) Move toString implementations into visitor pattern.
[ https://issues.apache.org/jira/browse/OGNL-27?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13128262#comment-13128262 ] Simone Tripodi commented on OGNL-27: sounds a very nice improvement, I'm going to have a look at the patch, thanks once again for your contribution! Move toString implementations into visitor pattern. - Key: OGNL-27 URL: https://issues.apache.org/jira/browse/OGNL-27 Project: OGNL Issue Type: New Feature Reporter: Daniel Pitts Attachments: to_string_visitor1.patch Using the Visitor pattern allows for a cleaner implementation of toString(). I have a patch which will remove toString() from all AST classes, and replace it with a single toString() in SimpleNode which delegates to a ToStringVisitor to build the String efficiently. This patch can also be used as an example of how to move other business logic out of the AST classes into their own visitor classes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OGNL-27) Move toString implementations into visitor pattern.
[
https://issues.apache.org/jira/browse/OGNL-27?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13128267#comment-13128267
]
Simone Tripodi commented on OGNL-27:
patch is good, I'd like to ask you 2 favors before applying it:
* add {{@since 4.0}} tags to new methods;
* respect the original code format - we are using the Maven [code
convention|http://maven.apache.org/developers/conventions/code.html]
Many thanks in advance!
Move toString implementations into visitor pattern.
-
Key: OGNL-27
URL: https://issues.apache.org/jira/browse/OGNL-27
Project: OGNL
Issue Type: New Feature
Reporter: Daniel Pitts
Attachments: to_string_visitor1.patch
Using the Visitor pattern allows for a cleaner implementation of toString().
I have a patch which will remove toString() from all AST classes, and replace
it with a single toString() in SimpleNode which delegates to a
ToStringVisitor to build the String efficiently.
This patch can also be used as an example of how to move other business logic
out of the AST classes into their own visitor classes.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OGNL-27) Move toString implementations into visitor pattern.
[ https://issues.apache.org/jira/browse/OGNL-27?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13128270#comment-13128270 ] Daniel Pitts commented on OGNL-27: -- Okay, I'll make those changes next time I have a free block of time. Thanks, Daniel. Sent from my iPhone On Oct 15, 2011, at 12:39 PM, Simone Tripodi (Commented) (JIRA) Move toString implementations into visitor pattern. - Key: OGNL-27 URL: https://issues.apache.org/jira/browse/OGNL-27 Project: OGNL Issue Type: New Feature Reporter: Daniel Pitts Attachments: to_string_visitor1.patch Using the Visitor pattern allows for a cleaner implementation of toString(). I have a patch which will remove toString() from all AST classes, and replace it with a single toString() in SimpleNode which delegates to a ToStringVisitor to build the String efficiently. This patch can also be used as an example of how to move other business logic out of the AST classes into their own visitor classes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (LANG-761) [PATCH] Fix javadoc warnings
[PATCH] Fix javadoc warnings Key: LANG-761 URL: https://issues.apache.org/jira/browse/LANG-761 Project: Commons Lang Issue Type: Bug Components: General Affects Versions: Nightly Builds Reporter: Ville Skyttä Priority: Trivial There are a few Multiple sources of package comments found warnings and one for commons-collections linkage in commons-lang svn, will attach a patch. By the way, I'm wondering why the javadocs for the org.apache.commons.lang3.compare package are not visible at http://commons.apache.org/lang/api-release/ ; they are there if I build javadocs locally from svn. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LANG-761) [PATCH] Fix javadoc warnings
[ https://issues.apache.org/jira/browse/LANG-761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ville Skyttä updated LANG-761: -- Attachment: lang-javadoc-warnings.patch [PATCH] Fix javadoc warnings Key: LANG-761 URL: https://issues.apache.org/jira/browse/LANG-761 Project: Commons Lang Issue Type: Bug Components: General Affects Versions: Nightly Builds Reporter: Ville Skyttä Priority: Trivial Labels: documentation Attachments: lang-javadoc-warnings.patch There are a few Multiple sources of package comments found warnings and one for commons-collections linkage in commons-lang svn, will attach a patch. By the way, I'm wondering why the javadocs for the org.apache.commons.lang3.compare package are not visible at http://commons.apache.org/lang/api-release/ ; they are there if I build javadocs locally from svn. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (OGNL-27) Move toString implementations into visitor pattern.
[ https://issues.apache.org/jira/browse/OGNL-27?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13128270#comment-13128270 ] Daniel Pitts edited comment on OGNL-27 at 10/15/11 9:50 PM: Okay, I'll make those changes next time I have a free block of time. was (Author: danielpitts): Okay, I'll make those changes next time I have a free block of time. Thanks, Daniel. Sent from my iPhone On Oct 15, 2011, at 12:39 PM, Simone Tripodi (Commented) (JIRA) Move toString implementations into visitor pattern. - Key: OGNL-27 URL: https://issues.apache.org/jira/browse/OGNL-27 Project: OGNL Issue Type: New Feature Reporter: Daniel Pitts Attachments: to_string_visitor1.patch Using the Visitor pattern allows for a cleaner implementation of toString(). I have a patch which will remove toString() from all AST classes, and replace it with a single toString() in SimpleNode which delegates to a ToStringVisitor to build the String efficiently. This patch can also be used as an example of how to move other business logic out of the AST classes into their own visitor classes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OGNL-27) Move toString implementations into visitor pattern.
[ https://issues.apache.org/jira/browse/OGNL-27?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Pitts updated OGNL-27: - Attachment: to_string_visitor_with_style_recommendations.patch Attaching new patch including Simone's requests for style/javadoc. Move toString implementations into visitor pattern. - Key: OGNL-27 URL: https://issues.apache.org/jira/browse/OGNL-27 Project: OGNL Issue Type: New Feature Reporter: Daniel Pitts Attachments: to_string_visitor1.patch, to_string_visitor_with_style_recommendations.patch Using the Visitor pattern allows for a cleaner implementation of toString(). I have a patch which will remove toString() from all AST classes, and replace it with a single toString() in SimpleNode which delegates to a ToStringVisitor to build the String efficiently. This patch can also be used as an example of how to move other business logic out of the AST classes into their own visitor classes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
