[jira] [Commented] (SANDBOX-418) Support for Java 7 using ASM 4.0
[ https://issues.apache.org/jira/browse/SANDBOX-418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13403737#comment-13403737 ] Torsten Curdt commented on SANDBOX-418: --- Sorry it took so long but - a big thank you for all your work. It's great someone pushes forward here. Since it's such a big step I think it deserves we create a 1.x branch and move trunk to 2.0 for these changes. I am sure commons could also host the maven plugin - but if you want to maintain it on e.g. github that would be fine, too. Just having one is great. > Support for Java 7 using ASM 4.0 > > > Key: SANDBOX-418 > URL: https://issues.apache.org/jira/browse/SANDBOX-418 > Project: Commons Sandbox > Issue Type: Improvement > Components: Javaflow >Reporter: Marc Bridner > Attachments: javaflow-2.0.patch > > > Javaflow doesn't work with Java 7 since ASM 3.x doesn't support Java 7, > mainly due to frame size computing issues. > So... this patch lifts everything to Java 7 and ASM 4.0. > Changes: > * Removed BCEL support, including testcases and dependencies. > * Now depends on ASM 4.0 instead of 3.x. > * Debug output for tests (bytecode trace) is now output to > target/test-instrumentation instead of the root directory. > * COMPUTE_FRAMES is used when writing instrumenting so that Java 7 stays > happy :) > * Re-added some testcases I found on this JIRA to make sure I didn't > reintroduce an old bug. > * All instrumented classes will now implement the empty Continuable > interface. If instrumentation is attempted on a class that implements > Continuable, an exception will be thrown. This is because multiple > instrumentation by mistake = very bad. > * Suppressed a lot of warnings in the testcases. > * Changed target java version to Java 7 in the pom file (might be better to > leave it at 1.5?) > * Javaflow version is now 2.0-SNAPSHOT due to breaking changes (removal of > BCEL) > > I've also made a maven plugin for instrumenting code (instead of the ANT > task), but it is not included in this patch since I'm unsure of the commons > project structure. It basically has to be in its own project and depend on > this one. > On my TODO list: > * Add a check that ensures that the class version of the file being > instrumented isn't changed by instrumentation. Happened a few times when code > was compiled using Java 6 and JavaFlow was compiled with Java 7 and Java 7 > was used for instrumentation. > * Add more testcases, check existing ones. > * Remove all warnings (by fixing them, not suppressing them). > * Add comments where possible. > * Detect and throw an exception if something not instrumented and is on the > call stack when suspending/resuming. Not sure if possible, but definitely > needed. Easy to miss something when not using class loader instrumentation > (say, using OSGi you don't want to do that...) > * Make Javaflow an OSGi bundle. > It'd be nice if someone took a close (!) look at the patch, since I'm fairly > new when it comes to ASM. > Also, what version of Java should be targeted in the pom file? -- 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] (CHAIN-69) Fixed Checkstyle / PMD Warnings
[ https://issues.apache.org/jira/browse/CHAIN-69?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elijah Zupancic updated CHAIN-69: - Attachment: chain-69.diff Checkstyle / PMD violations fixes. > Fixed Checkstyle / PMD Warnings > --- > > Key: CHAIN-69 > URL: https://issues.apache.org/jira/browse/CHAIN-69 > Project: Commons Chain > Issue Type: Improvement >Affects Versions: 2.0 >Reporter: Elijah Zupancic > Fix For: 2.0 > > Attachments: chain-69.diff > > > In this issue, we fix many PMD and checkstyle violations. -- 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] (CHAIN-69) Fixed Checkstyle / PMD Warnings
Elijah Zupancic created CHAIN-69: Summary: Fixed Checkstyle / PMD Warnings Key: CHAIN-69 URL: https://issues.apache.org/jira/browse/CHAIN-69 Project: Commons Chain Issue Type: Improvement Affects Versions: 2.0 Reporter: Elijah Zupancic Fix For: 2.0 In this issue, we fix many PMD and checkstyle violations. -- 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] (MATH-797) Single step integrators
[
https://issues.apache.org/jira/browse/MATH-797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13403231#comment-13403231
]
Gilles commented on MATH-797:
-
I'd rather include the algorithm for computing the points and weights. So, if
you don't mind (and the paperwork is all done), could you please post the code
which you wanted to donate?
> Single step integrators
> ---
>
> Key: MATH-797
> URL: https://issues.apache.org/jira/browse/MATH-797
> Project: Commons Math
> Issue Type: Wish
>Affects Versions: 3.0
>Reporter: Gilles
>Assignee: Gilles
>Priority: Trivial
> Fix For: 3.1
>
>
> CM assumes that the user wants to integrate a complex function on a large
> interval, so the large interval has to be subdivided into many subintervals.
> CM does the partition, and performs convergence checks, using an iterative
> approach.
> However, if the function is smooth enough, no subdivision of the integration
> interval is required. Those use-cases could benefit from the efficiency gain
> of not performing a convergence check.
> The proposal is to provide a new interface "UnivariateSingleStepIntegrator":
> {code}
> interface SingleIntervalIntegrator {
> /**
> * Method for implementing a single interval integration.
> * There is no convergence checks because it is not iterative.
> *
> * @param f Function to integrate.
> * @param lower Lower bound of the interval over which to integrate.
> * @param upper Upper bound of the interval over which to integrate.
> * @return the integrated value.
> */
> double integrate(UnivariateFunction f,
> double lower,
> double upper);
> }
> {code}
> In effect, the implementation of the above "integrate" method of a new
> "LegendreGaussIntegratorSingleStepIntegrator" would the equivalent of
> "stage(1)" in the current "LegendreGaussIntegrator".
--
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] (JEXL-133) String matching Operator short-hand inspired by CSS3
[
https://issues.apache.org/jira/browse/JEXL-133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13403133#comment-13403133
]
Henri Biestro commented on JEXL-133:
Good idea.
For coherence, it might be better to name them '=^' and '=$' (since the
matching operator is '=~').
And generalize the 'start with' and 'ends with' for any ordered sequence
(Object[], List...).
The following test (in Jexl3) exhibits the intended behavior on String.
{code}
public void test133() throws Exception {
JexlEngine jexl = new Engine();
JexlScript script;
Object result;
script = jexl.createScript("x =^ 'foo'", "x");
result = script.execute(null, "foobar");
assertEquals(Boolean.TRUE, result);
result = script.execute(null, "barfoo");
assertEquals(Boolean.FALSE, result);
script = jexl.createScript("x =$ 'foo'", "x");
result = script.execute(null, "foobar");
assertEquals(Boolean.FALSE, result);
result = script.execute(null, "barfoo");
assertEquals(Boolean.TRUE, result);
}
{code}
> String matching Operator short-hand inspired by CSS3
>
>
> Key: JEXL-133
> URL: https://issues.apache.org/jira/browse/JEXL-133
> Project: Commons JEXL
> Issue Type: Improvement
>Affects Versions: 2.1.1
>Reporter: Alfred Reibenschuh
>Assignee: Henri Biestro
>Priority: Trivial
> Fix For: 3.0
>
>
> like the perl inspired shorthand "=~", css3 also has some nice shorthands
> http://www.w3.org/TR/2011/REC-css3-selectors-20110929/#attribute-selectors
> for "startsWith" the shorthand could be "expr1 ^= expr2"
> for "endsWith" the shorthand could be "expr1 $= expr2"
> it could be that the "^=" operator already collides with "xor and assign"
> which i haven't looked at as of now.
--
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] (JEXL-133) String matching Operator short-hand inspired by CSS3
[ https://issues.apache.org/jira/browse/JEXL-133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Biestro updated JEXL-133: --- Fix Version/s: 3.0 > String matching Operator short-hand inspired by CSS3 > > > Key: JEXL-133 > URL: https://issues.apache.org/jira/browse/JEXL-133 > Project: Commons JEXL > Issue Type: Improvement >Affects Versions: 2.1.1 >Reporter: Alfred Reibenschuh >Assignee: Henri Biestro >Priority: Trivial > Fix For: 3.0 > > > like the perl inspired shorthand "=~", css3 also has some nice shorthands > http://www.w3.org/TR/2011/REC-css3-selectors-20110929/#attribute-selectors > for "startsWith" the shorthand could be "expr1 ^= expr2" > for "endsWith" the shorthand could be "expr1 $= expr2" > it could be that the "^=" operator already collides with "xor and assign" > which i haven't looked at as of now. -- 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] [Comment Edited] (IMAGING-84) Generate tests.jar so client projects can leverage test image data easily
[
https://issues.apache.org/jira/browse/IMAGING-84?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13403077#comment-13403077
]
Farrukh Najmi edited comment on IMAGING-84 at 6/28/12 1:27 PM:
---
Using test data is not always the only reason to have a tests.jar artifact from
a project. Another reason is when a project extends another project then it may
want to also the base project's test classes as part of its own test suite. Do
you see a downside to the project producing a tests.jar artifact?
Also, please see my comment on IMAGING-85 on why I think it is not unusual to
load test data from the classpath in junit tests.
Feel free to close the issue if you and other dev team members are still -1 on
this.
was (Author: farrukhnajmi):
Using test data is not always the only reason to have a tests.jar artifact
from a project. Another reason is when a project extends another project then
it may want to also the base project's test classes as part of its own test
suite. Do you see a downside to the project producing a tests.jar artifact?
Also, please see my comment on IMAGING-83 on why I think it is not unusual to
load test data from the classpath in junit tests.
> Generate tests.jar so client projects can leverage test image data easily
> -
>
> Key: IMAGING-84
> URL: https://issues.apache.org/jira/browse/IMAGING-84
> Project: Commons Imaging
> Issue Type: Improvement
> Components: Build
>Affects Versions: 0.97
>Reporter: Farrukh Najmi
>Priority: Minor
> Attachments: SANSELAN-82-patch.txt
>
>
> Client projects of commons-imaging need test image data and commons-imaging
> already has a pretty good set.
> The simple patch below can be applied to pom.xml to generate
> commons-imaging-xxx-tests.jar in addition to commons-imaging-xxx.jar to allow
> client projects to leverage the test data.
> {code}
> Index: pom.xml
> ===
> --- pom.xml (revision 1354112)
> +++ pom.xml (working copy)
> @@ -89,6 +89,14 @@
>
>
> maven-jar-plugin
> +
> +
> +
> + test-jar
> +
> +
> +
> +
>
>
>
> {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] [Comment Edited] (IMAGING-85) Rename src/test/data directory to src/test/resources to comply with maven conventions
[
https://issues.apache.org/jira/browse/IMAGING-85?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13403075#comment-13403075
]
Farrukh Najmi edited comment on IMAGING-85 at 6/28/12 1:27 PM:
---
Loading test resources from classpath is not uncommon. Consider the simplicity
of the following code junit test that uses spring framework.
Feel free to close the issue if you and other dev team members are still -1 on
this.
{code}
@Test
public void testGetImageMetadataCommonsImaging() {
InputStream is = null;
try {
PathMatchingResourcePatternResolver resolver = new
PathMatchingResourcePatternResolver();
Resource[] resources =
resolver.getResources("classpath:images/iptc/1/Oregon Scientific DS6639 -
DSC_0307 - iptc added with irfanview.jpg");
Resource res = resources[0];
URL url = res.getURL();
is = url.openStream();
Map params = new HashMap();
JpegImageMetadata metadata = (JpegImageMetadata)
Imaging.getMetadata(is, "Oregon Scientific DS6639 - DSC_0307 - iptc added with
irfanview.jpg");
JpegPhotoshopMetadata psMetadata = metadata.getPhotoshop();
List oldRecords = psMetadata.photoshopApp13Data.getRecords();
for (int j = 0; j < oldRecords.size(); j++) {
IptcRecord record = (IptcRecord) oldRecords.get(j);
System.err.println("Key: " + record.iptcType.getName() + " (0x"
+ Integer.toHexString(record.iptcType.getType())
+ "), value: " + record.value);
}
} catch (ImageReadException ex) {
Logger.getLogger(ImageCatalogerTest.class.getName()).log(Level.SEVERE, null,
ex);
} catch (IOException ex) {
Logger.getLogger(ImageCatalogerTest.class.getName()).log(Level.SEVERE, null,
ex);
} finally {
if (null != is) {
try {
is.close();
} catch (IOException ex) {
Logger.getLogger(ImageCatalogerTest.class.getName()).log(Level.SEVERE, null,
ex);
}
}
}
}
{code}
was (Author: farrukhnajmi):
Loading test resources from classpath is not uncommon. Consider the
simplicity of the following code junit test that uses spring framework.
{code}
@Test
public void testGetImageMetadataCommonsImaging() {
InputStream is = null;
try {
PathMatchingResourcePatternResolver resolver = new
PathMatchingResourcePatternResolver();
Resource[] resources =
resolver.getResources("classpath:images/iptc/1/Oregon Scientific DS6639 -
DSC_0307 - iptc added with irfanview.jpg");
Resource res = resources[0];
URL url = res.getURL();
is = url.openStream();
Map params = new HashMap();
JpegImageMetadata metadata = (JpegImageMetadata)
Imaging.getMetadata(is, "Oregon Scientific DS6639 - DSC_0307 - iptc added with
irfanview.jpg");
JpegPhotoshopMetadata psMetadata = metadata.getPhotoshop();
List oldRecords = psMetadata.photoshopApp13Data.getRecords();
for (int j = 0; j < oldRecords.size(); j++) {
IptcRecord record = (IptcRecord) oldRecords.get(j);
System.err.println("Key: " + record.iptcType.getName() + " (0x"
+ Integer.toHexString(record.iptcType.getType())
+ "), value: " + record.value);
}
} catch (ImageReadException ex) {
Logger.getLogger(ImageCatalogerTest.class.getName()).log(Level.SEVERE, null,
ex);
} catch (IOException ex) {
Logger.getLogger(ImageCatalogerTest.class.getName()).log(Level.SEVERE, null,
ex);
} finally {
if (null != is) {
try {
is.close();
} catch (IOException ex) {
Logger.getLogger(ImageCatalogerTest.class.getName()).log(Level.SEVERE, null,
ex);
}
}
}
}
{code}
> Rename src/test/data directory to src/test/resources to comply with maven
> conventions
> -
>
> Key: IMAGING-85
> URL: https://issues.apache.org/jira/browse/IMAGING-85
> Project: Commons Imaging
> Issue Type: Improvement
>Reporter: Farrukh Najmi
> Attachments: SANSELAN-83-patch.txt
>
>
> Currently established maven convention is not being following because test
> resources being placed under src/test/data instead of src/test/resources
> directory. This cause
[jira] [Commented] (IMAGING-84) Generate tests.jar so client projects can leverage test image data easily
[
https://issues.apache.org/jira/browse/IMAGING-84?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13403077#comment-13403077
]
Farrukh Najmi commented on IMAGING-84:
--
Using test data is not always the only reason to have a tests.jar artifact from
a project. Another reason is when a project extends another project then it may
want to also the base project's test classes as part of its own test suite. Do
you see a downside to the project producing a tests.jar artifact?
Also, please see my comment on IMAGING-83 on why I think it is not unusual to
load test data from the classpath in junit tests.
> Generate tests.jar so client projects can leverage test image data easily
> -
>
> Key: IMAGING-84
> URL: https://issues.apache.org/jira/browse/IMAGING-84
> Project: Commons Imaging
> Issue Type: Improvement
> Components: Build
>Affects Versions: 0.97
>Reporter: Farrukh Najmi
>Priority: Minor
> Attachments: SANSELAN-82-patch.txt
>
>
> Client projects of commons-imaging need test image data and commons-imaging
> already has a pretty good set.
> The simple patch below can be applied to pom.xml to generate
> commons-imaging-xxx-tests.jar in addition to commons-imaging-xxx.jar to allow
> client projects to leverage the test data.
> {code}
> Index: pom.xml
> ===
> --- pom.xml (revision 1354112)
> +++ pom.xml (working copy)
> @@ -89,6 +89,14 @@
>
>
> maven-jar-plugin
> +
> +
> +
> + test-jar
> +
> +
> +
> +
>
>
>
> {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] (IMAGING-85) Rename src/test/data directory to src/test/resources to comply with maven conventions
[
https://issues.apache.org/jira/browse/IMAGING-85?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13403075#comment-13403075
]
Farrukh Najmi commented on IMAGING-85:
--
Loading test resources from classpath is not uncommon. Consider the simplicity
of the following code junit test that uses spring framework.
{code}
@Test
public void testGetImageMetadataCommonsImaging() {
InputStream is = null;
try {
PathMatchingResourcePatternResolver resolver = new
PathMatchingResourcePatternResolver();
Resource[] resources =
resolver.getResources("classpath:images/iptc/1/Oregon Scientific DS6639 -
DSC_0307 - iptc added with irfanview.jpg");
Resource res = resources[0];
URL url = res.getURL();
is = url.openStream();
Map params = new HashMap();
JpegImageMetadata metadata = (JpegImageMetadata)
Imaging.getMetadata(is, "Oregon Scientific DS6639 - DSC_0307 - iptc added with
irfanview.jpg");
JpegPhotoshopMetadata psMetadata = metadata.getPhotoshop();
List oldRecords = psMetadata.photoshopApp13Data.getRecords();
for (int j = 0; j < oldRecords.size(); j++) {
IptcRecord record = (IptcRecord) oldRecords.get(j);
System.err.println("Key: " + record.iptcType.getName() + " (0x"
+ Integer.toHexString(record.iptcType.getType())
+ "), value: " + record.value);
}
} catch (ImageReadException ex) {
Logger.getLogger(ImageCatalogerTest.class.getName()).log(Level.SEVERE, null,
ex);
} catch (IOException ex) {
Logger.getLogger(ImageCatalogerTest.class.getName()).log(Level.SEVERE, null,
ex);
} finally {
if (null != is) {
try {
is.close();
} catch (IOException ex) {
Logger.getLogger(ImageCatalogerTest.class.getName()).log(Level.SEVERE, null,
ex);
}
}
}
}
{code}
> Rename src/test/data directory to src/test/resources to comply with maven
> conventions
> -
>
> Key: IMAGING-85
> URL: https://issues.apache.org/jira/browse/IMAGING-85
> Project: Commons Imaging
> Issue Type: Improvement
>Reporter: Farrukh Najmi
> Attachments: SANSELAN-83-patch.txt
>
>
> Currently established maven convention is not being following because test
> resources being placed under src/test/data instead of src/test/resources
> directory. This causes problems is maven-jar-plugin and possibly other
> situations. Proposed patch for SANSELAN-82 will not work until the proposed
> fix for this issues is addressed.
> The proposed fix is to rename src/test/data to src/test/resources and apply
> the following patch to fix test code that setsup path for test data files:
> {code}
> Index: src/test/java/org/apache/commons/imaging/ImagingTestConstants.java
> ===
> --- src/test/java/org/apache/commons/imaging/ImagingTestConstants.java
> (revision 1354112)
> +++ src/test/java/org/apache/commons/imaging/ImagingTestConstants.java
> (working copy)
> @@ -24,12 +24,12 @@
>
> static final File PHIL_HARVEY_TEST_IMAGE_FOLDER = new File(
> FilenameUtils
> -
> .separatorsToSystem("src\\test\\data\\images\\exif\\philHarvey\\"));
> +
> .separatorsToSystem("src\\test\\resources\\images\\exif\\philHarvey\\"));
>
> static final File SOURCE_FOLDER = new File("src");
> static final File TEST_SOURCE_FOLDER = new File(SOURCE_FOLDER, "test");
> static final File TEST_DATA_SOURCE_FOLDER = new File(TEST_SOURCE_FOLDER,
> -"data");
> +"resources");
> static final File TEST_IMAGE_FOLDER = new File(TEST_DATA_SOURCE_FOLDER,
> "images");
> }
> {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] [Comment Edited] (IMAGING-85) Rename src/test/data directory to src/test/resources to comply with maven conventions
[
https://issues.apache.org/jira/browse/IMAGING-85?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13403075#comment-13403075
]
Farrukh Najmi edited comment on IMAGING-85 at 6/28/12 1:02 PM:
---
Loading test resources from classpath is not uncommon. Consider the simplicity
of the following code junit test that uses spring framework.
{code}
@Test
public void testGetImageMetadataCommonsImaging() {
InputStream is = null;
try {
PathMatchingResourcePatternResolver resolver = new
PathMatchingResourcePatternResolver();
Resource[] resources =
resolver.getResources("classpath:images/iptc/1/Oregon Scientific DS6639 -
DSC_0307 - iptc added with irfanview.jpg");
Resource res = resources[0];
URL url = res.getURL();
is = url.openStream();
Map params = new HashMap();
JpegImageMetadata metadata = (JpegImageMetadata)
Imaging.getMetadata(is, "Oregon Scientific DS6639 - DSC_0307 - iptc added with
irfanview.jpg");
JpegPhotoshopMetadata psMetadata = metadata.getPhotoshop();
List oldRecords = psMetadata.photoshopApp13Data.getRecords();
for (int j = 0; j < oldRecords.size(); j++) {
IptcRecord record = (IptcRecord) oldRecords.get(j);
System.err.println("Key: " + record.iptcType.getName() + " (0x"
+ Integer.toHexString(record.iptcType.getType())
+ "), value: " + record.value);
}
} catch (ImageReadException ex) {
Logger.getLogger(ImageCatalogerTest.class.getName()).log(Level.SEVERE, null,
ex);
} catch (IOException ex) {
Logger.getLogger(ImageCatalogerTest.class.getName()).log(Level.SEVERE, null,
ex);
} finally {
if (null != is) {
try {
is.close();
} catch (IOException ex) {
Logger.getLogger(ImageCatalogerTest.class.getName()).log(Level.SEVERE, null,
ex);
}
}
}
}
{code}
was (Author: farrukhnajmi):
Loading test resources from classpath is not uncommon. Consider the
simplicity of the following code junit test that uses spring framework.
{code}
@Test
public void testGetImageMetadataCommonsImaging() {
InputStream is = null;
try {
PathMatchingResourcePatternResolver resolver = new
PathMatchingResourcePatternResolver();
Resource[] resources =
resolver.getResources("classpath:images/iptc/1/Oregon Scientific DS6639 -
DSC_0307 - iptc added with irfanview.jpg");
Resource res = resources[0];
URL url = res.getURL();
is = url.openStream();
Map params = new HashMap();
JpegImageMetadata metadata = (JpegImageMetadata)
Imaging.getMetadata(is, "Oregon Scientific DS6639 - DSC_0307 - iptc added with
irfanview.jpg");
JpegPhotoshopMetadata psMetadata = metadata.getPhotoshop();
List oldRecords = psMetadata.photoshopApp13Data.getRecords();
for (int j = 0; j < oldRecords.size(); j++) {
IptcRecord record = (IptcRecord) oldRecords.get(j);
System.err.println("Key: " + record.iptcType.getName() + " (0x"
+ Integer.toHexString(record.iptcType.getType())
+ "), value: " + record.value);
}
} catch (ImageReadException ex) {
Logger.getLogger(ImageCatalogerTest.class.getName()).log(Level.SEVERE, null,
ex);
} catch (IOException ex) {
Logger.getLogger(ImageCatalogerTest.class.getName()).log(Level.SEVERE, null,
ex);
} finally {
if (null != is) {
try {
is.close();
} catch (IOException ex) {
Logger.getLogger(ImageCatalogerTest.class.getName()).log(Level.SEVERE, null,
ex);
}
}
}
}
{code}
> Rename src/test/data directory to src/test/resources to comply with maven
> conventions
> -
>
> Key: IMAGING-85
> URL: https://issues.apache.org/jira/browse/IMAGING-85
> Project: Commons Imaging
> Issue Type: Improvement
>Reporter: Farrukh Najmi
> Attachments: SANSELAN-83-patch.txt
>
>
> Currently established maven convention is not being following because test
> resources being placed under src/test/data instead of src/test/resources
> directory. This causes problems is maven-jar-plugin and possibly other
> situations. Proposed patch for SAN
[jira] [Commented] (NET-471) Provide NIO SocketFactory Support
[ https://issues.apache.org/jira/browse/NET-471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13403049#comment-13403049 ] Sebb commented on NET-471: -- I'm not sure using NIO will help here. > Provide NIO SocketFactory Support > - > > Key: NET-471 > URL: https://issues.apache.org/jira/browse/NET-471 > Project: Commons Net > Issue Type: New Feature > Components: FTP >Affects Versions: 3.2 > Environment: WLan , poor network >Reporter: yankay > Labels: NIO, SocketManager > Fix For: 3.2 > > > When I use ftpclient to push a huge file(>1GB) from one city to another. The > Thread will block forever.Then I know the default setting use default > socketfactory. And the socket.setSoTimeout only works on read but write. > The commons-net not provide a NIO SocketFactory. So it's a hard work for me > to write one. > Can we provide a NIO SocketFactory? -- 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] (JEXL-133) String matching Operator short-hand inspired by CSS3
Alfred Reibenschuh created JEXL-133: --- Summary: String matching Operator short-hand inspired by CSS3 Key: JEXL-133 URL: https://issues.apache.org/jira/browse/JEXL-133 Project: Commons JEXL Issue Type: Improvement Affects Versions: 2.1.1 Reporter: Alfred Reibenschuh Priority: Trivial like the perl inspired shorthand "=~", css3 also has some nice shorthands http://www.w3.org/TR/2011/REC-css3-selectors-20110929/#attribute-selectors for "startsWith" the shorthand could be "expr1 ^= expr2" for "endsWith" the shorthand could be "expr1 $= expr2" it could be that the "^=" operator already collides with "xor and assign" which i haven't looked at as of now. -- 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
