[jira] Commented: (IO-46) [io] Find file in classpath
[
https://issues.apache.org/jira/browse/IO-46?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12673515#action_12673515
]
Jukka Zitting commented on IO-46:
-
{quote}
For example to place some input files on the test class path to fetch from when
invoking File-based APIs.
{quote}
That seems a bit fragile, as the resources could also be contained in a jar
file included in the classpath. The only case I can see when this is not a
potential issue is when the application is in control of the classpath, in
which case it could just as well access the files directly instead of going
through the class loader.
I'm also not so eager to introduce methods that make it easier to modify
resources on the classpath...
Perhaps a better alternative would be a method that takes a classpath resource
and returns a temporary file that contains the same data. This would (at some
performance cost) satisfy the requirements of File-based APIs without worrying
about the complexities of class loading.
> [io] Find file in classpath
> ---
>
> Key: IO-46
> URL: https://issues.apache.org/jira/browse/IO-46
> Project: Commons IO
> Issue Type: Improvement
> Components: Utilities
>Affects Versions: 1.1
> Environment: Operating System: other
> Platform: Other
>Reporter: David Leal
>Priority: Minor
> Fix For: 2.x
>
>
> Just to suggest adding a method like this:
> public File findFileInClasspath(String fileName) throws
> FileNotFoundException
> {
> URL url = getClass().getClassLoader().getResource(fileName);
> if (url == null){
> throw new FileNotFoundException(fileName);
> }
> return new File(url.getFile());
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Reopened: (IO-157) [FileUtils] Return target File from copyFileToDirectory()
[ https://issues.apache.org/jira/browse/IO-157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting reopened IO-157: -- Reopening, as this change breaks binary compatibility with IO 1.4. > [FileUtils] Return target File from copyFileToDirectory() > - > > Key: IO-157 > URL: https://issues.apache.org/jira/browse/IO-157 > Project: Commons IO > Issue Type: Improvement > Components: Utilities >Affects Versions: 1.4 >Reporter: Kenny MacLeod >Assignee: Niall Pemberton >Priority: Minor > Fix For: 2.0 > > > It would be useful if the FileUtils.copyFileToDirectory() method returned the > target file to which it does the copy. Currently, it creates the target File > object, passes it to copyFile(), and discards the reference. This could just > be returned from the method instead. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IO-125) wrong groupId value in pom.xml
[
https://issues.apache.org/jira/browse/IO-125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12673495#action_12673495
]
Jukka Zitting commented on IO-125:
--
{quote}
Properly moving to org.apache.commons means a bunch of redirects being put in
the maven repository.
{quote}
Do we need those redirects? I think the 1.x releases could well remain at their
current location at commons-io, and we'd just put new 2.x releases in
org/apache/commons. An upgrade from 1.4 to 2.0 would require changing the
dependency setting from
{code:xml}
commons-io
commons-io
1.4
{code}
to
{code:xml}
org.apache.commons
commons-io
2.0
{code}
> wrong groupId value in pom.xml
> --
>
> Key: IO-125
> URL: https://issues.apache.org/jira/browse/IO-125
> Project: Commons IO
> Issue Type: Bug
>Reporter: Piotr Czerwinski
> Fix For: 2.x
>
>
> groupId for the project is set to commons-io. I believe it should be
> org.apache.commons.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (IO-196) Occasional FileSystemObserver test failures
Occasional FileSystemObserver test failures --- Key: IO-196 URL: https://issues.apache.org/jira/browse/IO-196 Project: Commons IO Issue Type: Bug Reporter: Jukka Zitting Priority: Minor The FilesystemObserverTestCase method testFileCreate() fails occasionally in the Continuum build at http://vmbuild.apache.org/continuum/projectView.action?projectId=155. The failure, when it happens, is: FilesystemObserverTestCase testFileCreate : junit.framework.AssertionFailedError junit.framework.AssertionFailedError: E[0 0 0 1 0 0]: No. of directories changed expected:<1> but was:<0> at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.failNotEquals(Assert.java:282) at junit.framework.Assert.assertEquals(Assert.java:64) at junit.framework.Assert.assertEquals(Assert.java:201) at org.apache.commons.io.monitor.FilesystemObserverTestCase.checkCollectionSizes(FilesystemObserverTestCase.java:424) at org.apache.commons.io.monitor.FilesystemObserverTestCase.testFileCreate(FilesystemObserverTestCase.java:203) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IO-192) Tagged input and output streams
[
https://issues.apache.org/jira/browse/IO-192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12673492#action_12673492
]
Jukka Zitting commented on IO-192:
--
My point about the static IOUtils methods is that IMHO using the tagged stream
features across method calls is bad form. Consider the following alternative to
the bar() method:
{code}
public void bar(InputStream input, OutputStream output) {
TaggedInputStream taggedInput = new TaggedInputStream(input);
TaggedInputStream taggedOutput = new TaggedInputStream(output);
try {
processStreams(taggedInput, taggedOutput);
} catch (IOException e) {
if (taggedInput.isCauseOf(e)) {
}
if (taggedOutput.isCauseOf(e)) {
}
}
}
{code}
There is no need for a caller to know that bar() needs the tagged stream
functionality. That can (and should) be encapsulated within bar(). Thus I think
it's better if we *don't* provide the static IOUtils methods, as that'll make
it harder for people to write bad APIs that silently assume extra functionality
on stream instances.
> Tagged input and output streams
> ---
>
> Key: IO-192
> URL: https://issues.apache.org/jira/browse/IO-192
> Project: Commons IO
> Issue Type: New Feature
> Components: Streams/Writers
>Reporter: Jukka Zitting
>Assignee: Jukka Zitting
>Priority: Minor
> Fix For: 1.5
>
> Attachments: IO-192-tagged-stream-changes.patch, IO-192.patch
>
>
> I'd like to introduce two new proxy streams, TaggedInputStream and
> TaggedOutputStream, that tag all exceptions thrown by the proxied streams.
> The goal is to make it easier to detect the source of an IOException when
> you're dealing with multiple different streams. For example:
> {code}
> InputStream input = ...;
> OutputStream output = ...;
> TaggedOutputStream proxy = new TaggedOutputStream(output);
> try {
> IOUtils.copy(input, proxy);
> } catch (IOException e) {
> if (proxy.isTagged(e)) {
> // Could not write to the output stream
> // Perhaps we can handle that error somehow (retry, cancel?)
> e.initCause(); // gives the original exception from the proxied stream
> } else {
> // Could not read from the input stream, nothing we can do
> throw e;
> }
> }
> {code}
> I'm working on a patch to implement such a feature.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (IO-192) Tagged input and output streams
[
https://issues.apache.org/jira/browse/IO-192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12673492#action_12673492
]
jukkaz edited comment on IO-192 at 2/14/09 2:06 AM:
---
My point about the static IOUtils methods is that IMHO using the tagged stream
features across method calls is bad form. Consider the following alternative to
the bar() method:
{code}
public void bar(InputStream input, OutputStream output) {
TaggedInputStream taggedInput = new TaggedInputStream(input);
TaggedOutputStream taggedOutput = new TaggedOutputStream(output);
try {
processStreams(taggedInput, taggedOutput);
} catch (IOException e) {
if (taggedInput.isCauseOf(e)) {
}
if (taggedOutput.isCauseOf(e)) {
}
}
}
{code}
There is no need for a caller to know that bar() needs the tagged stream
functionality. That can (and should) be encapsulated within bar(). Thus I think
it's better if we *don't* provide the static IOUtils methods, as that'll make
it harder for people to write bad APIs that silently assume extra functionality
on stream instances.
was (Author: jukkaz):
My point about the static IOUtils methods is that IMHO using the tagged
stream features across method calls is bad form. Consider the following
alternative to the bar() method:
{code}
public void bar(InputStream input, OutputStream output) {
TaggedInputStream taggedInput = new TaggedInputStream(input);
TaggedInputStream taggedOutput = new TaggedInputStream(output);
try {
processStreams(taggedInput, taggedOutput);
} catch (IOException e) {
if (taggedInput.isCauseOf(e)) {
}
if (taggedOutput.isCauseOf(e)) {
}
}
}
{code}
There is no need for a caller to know that bar() needs the tagged stream
functionality. That can (and should) be encapsulated within bar(). Thus I think
it's better if we *don't* provide the static IOUtils methods, as that'll make
it harder for people to write bad APIs that silently assume extra functionality
on stream instances.
> Tagged input and output streams
> ---
>
> Key: IO-192
> URL: https://issues.apache.org/jira/browse/IO-192
> Project: Commons IO
> Issue Type: New Feature
> Components: Streams/Writers
>Reporter: Jukka Zitting
>Assignee: Jukka Zitting
>Priority: Minor
> Fix For: 1.5
>
> Attachments: IO-192-tagged-stream-changes.patch, IO-192.patch
>
>
> I'd like to introduce two new proxy streams, TaggedInputStream and
> TaggedOutputStream, that tag all exceptions thrown by the proxied streams.
> The goal is to make it easier to detect the source of an IOException when
> you're dealing with multiple different streams. For example:
> {code}
> InputStream input = ...;
> OutputStream output = ...;
> TaggedOutputStream proxy = new TaggedOutputStream(output);
> try {
> IOUtils.copy(input, proxy);
> } catch (IOException e) {
> if (proxy.isTagged(e)) {
> // Could not write to the output stream
> // Perhaps we can handle that error somehow (retry, cancel?)
> e.initCause(); // gives the original exception from the proxied stream
> } else {
> // Could not read from the input stream, nothing we can do
> throw e;
> }
> }
> {code}
> I'm working on a patch to implement such a feature.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
