[jira] [Created] (JCS-102) JCS.getGroupKeys() always triggers a\ ClassCastException

2012-12-23 Thread Robert Clark (JIRA) 
Robert Clark created JCS-102:


 Summary: JCS.getGroupKeys() always triggers a\ ClassCastException
 Key: JCS-102
 URL: https://issues.apache.org/jira/browse/JCS-102
 Project: Commons JCS
  Issue Type: Bug
  Components: Composite Cache
Affects Versions: jcs-2.0.0
Reporter: Robert Clark


Using SVN version build Dec 20, 2012:

This code:

{code:java}
JCS jcs = JCS.getInstance("the region");
jcs.getGroupKeys("the group");
jcs.putInGroup(Long.valueOf(1), "the group", "some value");
jcs.getGroupKeys("the group");
{code}

will trigger an exception on the *second* getGroupKeys() call (when there is 
actually something in the cache)

{noformat}
Exception in thread "main" java.lang.ClassCastException: java.lang.Long cannot 
be cast to org.apache.jcs.engine.control.group.GroupAttrName
 [java] at 
org.apache.jcs.access.GroupCacheAccess.getGroupKeys(GroupCacheAccess.java:205)
 [java] at my.sample.code.Main.main(Main.java:108)
{noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (LANG-863) Method returns number of inheritance hops between parent and subclass

2012-12-23 Thread Daneel S. Yaitskov (JIRA) 
Daneel S. Yaitskov created LANG-863:
---

 Summary: Method returns number of inheritance hops between parent 
and subclass
 Key: LANG-863
 URL: https://issues.apache.org/jira/browse/LANG-863
 Project: Commons Lang
  Issue Type: New Feature
  Components: lang.reflect.*
Reporter: Daneel S. Yaitskov
 Fix For: 4.0


For example.

class A {
}
class B extends A {
}
class C extends B {
}

int d;
d = InheritanceUtils.distance(A.class, A.class);
Assert.assertEquals(0, d);
d = InheritanceUtils.distance(B.class, A.class);
Assert.assertEquals(1, d);
d = InheritanceUtils.distance(C.class, A.class);
Assert.assertEquals(2, d);

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (NET-493) FTPClient: Slow data transfer rate if __bufferSize != 0

2012-12-23 Thread Mico Micic (JIRA) 

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

Mico Micic commented on NET-493:


I'm not sure with which version of Java I have tested it because I switched to 
7 and back to 6... Currently I am out of the office and will be back on Monday, 
7th of January 2013. I'll report back...

> FTPClient: Slow data transfer rate if __bufferSize != 0
> ---
>
> Key: NET-493
> URL: https://issues.apache.org/jira/browse/NET-493
> Project: Commons Net
>  Issue Type: Bug
>  Components: FTP
>Affects Versions: 3.2
> Environment: Windows 7 32bit / Windows XP 32bit
>Reporter: Mico Micic
>  Labels: ftpclient
> Attachments: screenshot-1.jpg, screenshot-2.jpg
>
>
> The patch applied in [NET-465|https://issues.apache.org/jira/browse/NET-465] 
> causes a very slow data transfer rate. The line {code}850: 
> socket.setSendBufferSize(__bufferSize){code} in 
> {code}_openDataConnection_{code} sets the buffer size to 1024  by default. 
> With this size I had a very bad transfer rate on windows 7 and XP. The 
> wireshark log shows that each FTP-DATA packet is exactly 1024 bytes long and 
> has to be acknowledged on the TCP layer before the next one is sent. I don't 
> know why, but when I set the buffer size to 0 (FTPClient.setBufferSize) the 
> transfer rate is fine. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (IMAGING-100) Sanselan stumbles on attached image

2012-12-23 Thread Damjan Jovanovic (JIRA) 

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

Damjan Jovanovic commented on IMAGING-100:
--

According to http://dev.robotbattle.com/bugs/view.php?id=533
there are 2 cases when multiple App13 segments appear: one is (a) where a 
single IPTC block is split into multiple segments, and the other is (b) when 
there are multiple independent IPTC blocks.

This image is case (b). To write a patch for this, I also need a case (a) image 
so I can see exactly how to distinguish these cases.


> Sanselan stumbles on attached image
> ---
>
> Key: IMAGING-100
> URL: https://issues.apache.org/jira/browse/IMAGING-100
> Project: Commons Imaging
>  Issue Type: Bug
>  Components: Format: JPEG
>Affects Versions: 0.97
>Reporter: Luis Arias
>Priority: Minor
> Attachments: employee.jpg
>
>
> The attached image gives rise to the following exception when using sanselan 
> to retrieve exif orientation information as follows:
>   IImageMetadata metadata = Sanselan.getMetadata(bytes);
>   JpegImageMetadata jpegMetadata = (JpegImageMetadata) metadata;
>   TiffField orientation = 
> jpegMetadata.findEXIFValue(TiffConstants.EXIF_TAG_ORIENTATION);
>   orientation.getIntValue();
> |  org.apache.sanselan.ImageReadException: Jpeg contains more than one 
> Photoshop App13 segment.
>   at 
> org.apache.sanselan.formats.jpeg.JpegImageParser.getPhotoshopMetadata(JpegImageParser.java:609)
>   at 
> org.apache.sanselan.formats.jpeg.JpegImageParser.getMetadata(JpegImageParser.java:309)
>   at org.apache.sanselan.Sanselan.getMetadata(Sanselan.java:978)
>   at org.apache.sanselan.Sanselan.getMetadata(Sanselan.java:871)
>   at org.apache.sanselan.Sanselan.getMetadata(Sanselan.java:846)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira