[jira] Commented: (LANG-456) HashCodeBuilder throws StackOverflowError in bidirectional navigable association
[ https://issues.apache.org/jira/browse/LANG-456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12633948#action_12633948 ] Sebb commented on LANG-456: --- Thanks for the updated test case which causes the expected stack overflow. In fact LANG is currently targeted at Java 1.2 - I believe it may be used by Java ME code, which is not so easily upgraded. == Since the HashCode for the Bidirectional class depends on the hash code for the JavBVO class and vice versa, it's not surprising that there is a stack overflow. If you were not using the HashCodeBuider, how would you define the hashcodes? > HashCodeBuilder throws StackOverflowError in bidirectional navigable > association > > > Key: LANG-456 > URL: https://issues.apache.org/jira/browse/LANG-456 > Project: Commons Lang > Issue Type: Bug >Affects Versions: 2.4 > Environment: Widows XP. Sun JDK 1.5 or 1.6. >Reporter: Bob Fields > Attachments: HashCodeBuilderStackOverflow.zip, StackOverflowError.zip > > > This is not the reflection methods, it is the regular HashCodeBuilder append > methods. It causes EqualsBuilder, ToStringBuilder, CompareToBuilder to also > throw the StackOverflowException, but those methods work when one of the > HashCodeBuilder bidirectional association attributes .hashCode() is commented > out. The problem is that all of the builders call registerObject() which > creates a hashCode, but only the reflectionAppend method checks if an object > is registered. > Bi-directional associations are a very common pattern in Jaxb and Hibernate. > In this case, I generate code from a model in order to avoid the reflection > penalty - I already know what the attributes are at compile time, so I use > .append instead of .reflectionAppend. > See attached example + unit test. One side of the bidirectional association > must be commented out in the hashCode method. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (LANG-456) HashCodeBuilder throws StackOverflowError in bidirectional navigable association
[ https://issues.apache.org/jira/browse/LANG-456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bob Fields updated LANG-456: Attachment: HashCodeBuilderStackOverflow.zip Does anybody even use JDK 1.3 any more? I haven't had it on my machine in years. Here's an updated version with all the Jaxb stuff removed, built with JDK 1.4.2 with compiler compliance level set to JDK 1.3, that should work for you. There's no dependencies other than commons-lang and JUnit. > HashCodeBuilder throws StackOverflowError in bidirectional navigable > association > > > Key: LANG-456 > URL: https://issues.apache.org/jira/browse/LANG-456 > Project: Commons Lang > Issue Type: Bug >Affects Versions: 2.4 > Environment: Widows XP. Sun JDK 1.5 or 1.6. >Reporter: Bob Fields > Attachments: HashCodeBuilderStackOverflow.zip, StackOverflowError.zip > > > This is not the reflection methods, it is the regular HashCodeBuilder append > methods. It causes EqualsBuilder, ToStringBuilder, CompareToBuilder to also > throw the StackOverflowException, but those methods work when one of the > HashCodeBuilder bidirectional association attributes .hashCode() is commented > out. The problem is that all of the builders call registerObject() which > creates a hashCode, but only the reflectionAppend method checks if an object > is registered. > Bi-directional associations are a very common pattern in Jaxb and Hibernate. > In this case, I generate code from a model in order to avoid the reflection > penalty - I already know what the attributes are at compile time, so I use > .append instead of .reflectionAppend. > See attached example + unit test. One side of the bidirectional association > must be commented out in the hashCode method. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-437) Complaints that the IE fix for StringEscapeUtils.escapeJavaScript is causing problems elsewhere. Rollback?
[ https://issues.apache.org/jira/browse/LANG-437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12633917#action_12633917 ] Bob Fields commented on LANG-437: - This change broke our application www.andromda.org. We use StringEscapeUtils to fix documentation contained in Strings for inclusion in Java files and then compile those java files, resulting in the error: Invalid escape sequence (valid ones are \b \t \n \f \r \" \' \\ ) Note that \/ is not a valid String escape sequence. Should use escapeJavaScript if String is meant to be used in html or XML environment rather than in a Java environment. See also https://issues.apache.org/jira/browse/LANG-421. > Complaints that the IE fix for StringEscapeUtils.escapeJavaScript is causing > problems elsewhere. Rollback? > -- > > Key: LANG-437 > URL: https://issues.apache.org/jira/browse/LANG-437 > Project: Commons Lang > Issue Type: Bug >Affects Versions: 2.4 >Reporter: Henri Yandell > Fix For: 3.0 > > > Need to decide if we should roll LANG-363 back or not. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FILEUPLOAD-160) disk leak if multipart parse error
[
https://issues.apache.org/jira/browse/FILEUPLOAD-160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12633823#action_12633823
]
Stepan Koltsov commented on FILEUPLOAD-160:
---
Hello!
> disk leak if multipart parse error
> --
>
> Key: FILEUPLOAD-160
> URL: https://issues.apache.org/jira/browse/FILEUPLOAD-160
> Project: Commons FileUpload
> Issue Type: Bug
>Reporter: Stepan Koltsov
>
> FleUploadBase.parseRequest() keeps files on disk if parser error occured.
> Patch
> {code}
> diff -r cf24bc636e09 -r f706d95f56b7
> src/java/org/apache/commons/fileupload/FileUploadBase.java
> --- a/src/java/org/apache/commons/fileupload/FileUploadBase.java Wed May
> 28 22:25:00 2008 +0400
> +++ b/src/java/org/apache/commons/fileupload/FileUploadBase.java Thu May
> 29 15:40:04 2008 +0400
> @@ -345,9 +345,10 @@
> */
> public List /* FileItem */ parseRequest(RequestContext ctx)
> throws FileUploadException {
> +List items = new ArrayList();
> +boolean successful = false;
> try {
> FileItemIterator iter = getItemIterator(ctx);
> -List items = new ArrayList();
> FileItemFactory fac = getFileItemFactory();
> if (fac == null) {
> throw new NullPointerException(
> @@ -358,6 +359,7 @@
> FileItem fileItem = fac.createItem(item.getFieldName(),
> item.getContentType(), item.isFormField(),
> item.getName());
> +items.add(fileItem);
> try {
> Streams.copy(item.openStream(),
> fileItem.getOutputStream(),
> true);
> @@ -372,13 +374,24 @@
> final FileItemHeaders fih = item.getHeaders();
> ((FileItemHeadersSupport) fileItem).setHeaders(fih);
> }
> -items.add(fileItem);
> }
> +successful = true;
> return items;
> } catch (FileUploadIOException e) {
> throw (FileUploadException) e.getCause();
> } catch (IOException e) {
> throw new FileUploadException(e.getMessage(), e);
> +} finally {
> +if (!successful) {
> +for (Iterator iterator = items.iterator();
> iterator.hasNext();) {
> +FileItem fileItem = (FileItem) iterator.next();
> +try {
> +fileItem.delete();
> +} catch (Throwable e) {
> +// ignore it
> +}
> +}
> +}
> }
> }
>
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
