[jira] Updated: (LANG-417) ClassUtils: method for turning FQN into resource path
[
https://issues.apache.org/jira/browse/LANG-417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Yandell updated LANG-417:
---
Fix Version/s: (was: 2.4)
3.0
> ClassUtils: method for turning FQN into resource path
> -
>
> Key: LANG-417
> URL: https://issues.apache.org/jira/browse/LANG-417
> Project: Commons Lang
> Issue Type: New Feature
>Reporter: Paul Benedict
> Fix For: 3.0
>
>
> I commonly need a FQ path to a resource within the same location as a class
> file. I recommend the addition of this method:
> public String getPackageResourcePath(Class clazz, String resourceName)
> StringBuffer buf = new StringBuffer();
> buf.append(ClassUtils.getPackageName(getClass()).replace('.', '/'));
> buf.append("/");
> buf.append(resourceName);
> return buf.toString();
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SCXML-65) NullPointer exceptions during triggerEvent
[
https://issues.apache.org/jira/browse/SCXML-65?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577452#action_12577452
]
Rahul Akolkar commented on SCXML-65:
Thanks for trying the SVN trunk. Please let us know how the extended testing
goes.
> NullPointer exceptions during triggerEvent
> --
>
> Key: SCXML-65
> URL: https://issues.apache.org/jira/browse/SCXML-65
> Project: Commons SCXML
> Issue Type: Bug
>Affects Versions: 0.7
> Environment: Linux opensuse 10.2 & Sun Solaris 10
> 1.5.x java
>Reporter: luc willems
> Fix For: 0.8
>
>
> i'm using SCXML state machines in a load generation tool. this tool simulates
> a client connected to a server.
> the SCXML script used custom actions to send a request using a HTTP based
> protocol.
> the HTTP response is transformed into a event and inserted into the SCXML
> script using triggerEvent().
> each SCML executor has 1 dedicated http connection. i'm using around 2 to
> 1 clients depending on the
> test scenario's.
> During execution of the scripts a get sporatic nullpointer exceptions. this
> DOESN'T happen all the time , it is hard to reproduce but when it happens ALL
> clients have the same problem. resetting the SCXML exector doesn't help
> 2008-01-24
> 14:33:35,593|scxml-1-88|ERROR|SCXMLUser.triggerEvents(181)|9|Current events:
> events(TriggerEvent{name=wv.status,type=3},TriggerEvent{name=wv.ok,type=3})
> 2008-01-24 14:33:35,594|scxml-1-88|ERROR|SCXMLUser.triggerEvents(182)|9|error
> scxml event trigger: null
> java.lang.NullPointerException
> at
> org.apache.commons.scxml.semantics.SCXMLSemanticsImpl.seedTargetSet(SCXMLSemanticsImpl.java:493)
> at
> org.apache.commons.scxml.semantics.SCXMLSemanticsImpl.followTransitions(SCXMLSemanticsImpl.java:652)
> at
> org.apache.commons.scxml.SCXMLExecutor.triggerEvents(SCXMLExecutor.java:127)
> at com.nsn.loadtool.scxml.SCXMLUser.triggerEvents(SCXMLUser.java:164)
> at
> com.nsn.loadtool.scxml.SCXMLAsyncExecutor$SCXMLWorker.run(SCXMLAsyncExecutor.java:101)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
> at java.lang.Thread.run(Thread.java:595)
> all event triggering is done in a way that only 1 thread can trigger a event.
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (IO-158) ReaderInputStream implementation
[ https://issues.apache.org/jira/browse/IO-158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577457#action_12577457 ] Jukka Zitting commented on IO-158: -- Design-wise I prefer the iBatis/XMLBeans alternatives as they use an OutputStreamWriter instead of new String(...).getBytes(...) for translating characters to bytes. Functionally they are the same, but the OutputStreamWriter approach is nicely analogous with the reverse stream designs we've been discussing in IO-71. A ReaderInputStream is simply a reversed OutputStreamWriter. > ReaderInputStream implementation > > > Key: IO-158 > URL: https://issues.apache.org/jira/browse/IO-158 > Project: Commons IO > Issue Type: Wish >Reporter: Andreas Veithen >Priority: Minor > > The standard Java class InputStreamReader converts a Reader into an > InputStream. In some cases it is necessary to do the reverse, i.e. to convert > a Reader into an InputStream. Several frameworks and libraries have their own > implementation of this functionality (google for "ReaderInputStream"). Among > these are at least four Apache projects: Ant, iBatis, James and XMLBeans. > Commons IO would be a good place to share a common implementation. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (LANG-376) MultiFormatTest testWTF() does nothing useful
[ https://issues.apache.org/jira/browse/LANG-376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Benson resolved LANG-376. -- Resolution: Invalid Re-resolving as invalid since we removed MultiFormat; this way hopefully any generated release notes won't contain this. > MultiFormatTest testWTF() does nothing useful > - > > Key: LANG-376 > URL: https://issues.apache.org/jira/browse/LANG-376 > Project: Commons Lang > Issue Type: Bug >Reporter: Sebb > Fix For: 2.4 > > > The testWTF() method in MultiFormatTest does not appear to do anything useful > - it merely prints out a DateFormat instance. > This results in spurious output during unit tests. > The test should be removed or made to do something useful. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (LANG-376) MultiFormatTest testWTF() does nothing useful
[ https://issues.apache.org/jira/browse/LANG-376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Benson reopened LANG-376: -- > MultiFormatTest testWTF() does nothing useful > - > > Key: LANG-376 > URL: https://issues.apache.org/jira/browse/LANG-376 > Project: Commons Lang > Issue Type: Bug >Reporter: Sebb > Fix For: 2.4 > > > The testWTF() method in MultiFormatTest does not appear to do anything useful > - it merely prints out a DateFormat instance. > This results in spurious output during unit tests. > The test should be removed or made to do something useful. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IO-159) FileCleaningTracker: ReferenceQueue uses raw type
[ https://issues.apache.org/jira/browse/IO-159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Benedict updated IO-159: - Description: The field is: ReferenceQueue /* Tracker */ q = new ReferenceQueue(); But that inline comment needs to become the parameterized type. Is it of type ? was: The code is: /** * Queue of Tracker instances being watched. */ ReferenceQueue /* Tracker */ q = new ReferenceQueue(); But that inline comment needs to become the parameterized type. Is it of type ? Affects Version/s: 2.0 > FileCleaningTracker: ReferenceQueue uses raw type > - > > Key: IO-159 > URL: https://issues.apache.org/jira/browse/IO-159 > Project: Commons IO > Issue Type: Improvement >Affects Versions: 2.0 >Reporter: Paul Benedict >Priority: Minor > Fix For: 2.0 > > > The field is: > ReferenceQueue /* Tracker */ q = new ReferenceQueue(); > But that inline comment needs to become the parameterized type. Is it of type > ? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (IO-159) FileCleaningTracker: ReferenceQueue uses raw type
FileCleaningTracker: ReferenceQueue uses raw type - Key: IO-159 URL: https://issues.apache.org/jira/browse/IO-159 Project: Commons IO Issue Type: Improvement Reporter: Paul Benedict Priority: Minor Fix For: 2.0 The code is: /** * Queue of Tracker instances being watched. */ ReferenceQueue /* Tracker */ q = new ReferenceQueue(); But that inline comment needs to become the parameterized type. Is it of type ? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IO-158) ReaderInputStream implementation
[ https://issues.apache.org/jira/browse/IO-158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577600#action_12577600 ] Andreas Veithen commented on IO-158: The implementation from James is here, but it's not a good candidate: http://svn.apache.org/repos/asf/james/server/tags/build_2_3_1/src/java/org/apache/james/fetchmail/ReaderInputStream.java > ReaderInputStream implementation > > > Key: IO-158 > URL: https://issues.apache.org/jira/browse/IO-158 > Project: Commons IO > Issue Type: Wish >Reporter: Andreas Veithen >Priority: Minor > > The standard Java class InputStreamReader converts a Reader into an > InputStream. In some cases it is necessary to do the reverse, i.e. to convert > a Reader into an InputStream. Several frameworks and libraries have their own > implementation of this functionality (google for "ReaderInputStream"). Among > these are at least four Apache projects: Ant, iBatis, James and XMLBeans. > Commons IO would be a good place to share a common implementation. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (NET-202) Telnet Command Execution API
Telnet Command Execution API Key: NET-202 URL: https://issues.apache.org/jira/browse/NET-202 Project: Commons Net Issue Type: Wish Affects Versions: 1.4 Environment: Windows,Java Reporter: hardikkumar Darji Priority: Minor I thought there should be an API that just receives UNIX or LINUX command and reply back the command output to Client. I want to use Telnet utility classes in common-net to send commands programmetically and want get back the out put but Could not found any solution yet. Any help will be appreciated. Thanks Hardikkumar -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IO-158) ReaderInputStream implementation
[ https://issues.apache.org/jira/browse/IO-158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577615#action_12577615 ] Andreas Veithen commented on IO-158: In my opinion, design-wise the best alternative would be to use the java.nio.charset classes. Some time ago I used this approach to write an OutputStream implementation that decodes the stream, decomposes it into lines and sends them to a logger. I've refactored this code to isolate the character decoding part. This gives a WriterOutputStream, which would be the natural counterpart to the ReaderInputStream discussed here. The code can be found here (I agree to donate it to Commons IO): https://spring-derby.svn.sourceforge.net/svnroot/spring-derby/trunk/src/main/java/net/sf/springderby/WriterOutputStream.java > ReaderInputStream implementation > > > Key: IO-158 > URL: https://issues.apache.org/jira/browse/IO-158 > Project: Commons IO > Issue Type: Wish >Reporter: Andreas Veithen >Priority: Minor > > The standard Java class InputStreamReader converts a Reader into an > InputStream. In some cases it is necessary to do the reverse, i.e. to convert > a Reader into an InputStream. Several frameworks and libraries have their own > implementation of this functionality (google for "ReaderInputStream"). Among > these are at least four Apache projects: Ant, iBatis, James and XMLBeans. > Commons IO would be a good place to share a common implementation. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IO-132) File Listener/Monitor
[ https://issues.apache.org/jira/browse/IO-132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated IO-132: --- Attachment: (was: AbstractFileObserver.java) > File Listener/Monitor > - > > Key: IO-132 > URL: https://issues.apache.org/jira/browse/IO-132 > Project: Commons IO > Issue Type: New Feature >Reporter: Niall Pemberton >Assignee: Niall Pemberton > Fix For: 2.x > > Attachments: AbstractFileObserverTestCase.java, > CollectionFileListener.java, CollectionFileListenerTestCase.java, > FileListener.java, FileListenerAdaptor.java, FileMonitor.java, > FileObserver.java, FileObserverImpl.java, FileObserverImplTestCase.java, > JDKLoggingFileListener.java > > > Commons JCI has a "fam" (file alteration monitor) module[1] which provides a > listener for file and directory create/change/delete events. I have done some > work refactoring the JCI implementation and propose adding to to Commons IO. > There is already an existing request/propsal to add similar functionality in > IO-79 from Jim Harrington (which includes code). > There are IMO two main differences (IMO improvements) in this implementation > over exsiting JCI fam module: > 1) It uses a matching array technique to compare previous and current > directory contents which minimizes object creation > 2) FileFilters can be specified to monitor only portions of the file system, > ignoring files/directories of no interest. This is more efficient and reduces > the amount of noise from un-wanted file/directory events > From a quick look at IO-79, the above also applies to that proposal. > Additionally IMO the solution in IO-79 would benefit from been broken out > from the two DirectoryPoller and FilePoller artifacts. > There are also some changes to the API specified in JCI's fam: > 1) FileObserver (FilesystemAlterationObserver in fam) has additional init() > and destroy() methods > 2) FileMonitor (FilesystemAlterationMonitor in fam) has > addObserver/removeObserver methods rather than addListener/removeListener > methods. The issue (IMO) with fam is that the monitor is fixed to the > FilesystemAlterationObserverImpl implementation, rather than any > FilesystemAlterationObserver implementation. Also the ability to specify file > filters means that there is a need to be able to add more than one observer > for the same root directory. > [1] http://svn.apache.org/repos/asf/commons/proper/jci/trunk/fam/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IO-132) File Listener/Monitor
[ https://issues.apache.org/jira/browse/IO-132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated IO-132: --- Attachment: (was: FileListenerAdaptor.java) > File Listener/Monitor > - > > Key: IO-132 > URL: https://issues.apache.org/jira/browse/IO-132 > Project: Commons IO > Issue Type: New Feature >Reporter: Niall Pemberton >Assignee: Niall Pemberton > Fix For: 2.x > > > Commons JCI has a "fam" (file alteration monitor) module[1] which provides a > listener for file and directory create/change/delete events. I have done some > work refactoring the JCI implementation and propose adding to to Commons IO. > There is already an existing request/propsal to add similar functionality in > IO-79 from Jim Harrington (which includes code). > There are IMO two main differences (IMO improvements) in this implementation > over exsiting JCI fam module: > 1) It uses a matching array technique to compare previous and current > directory contents which minimizes object creation > 2) FileFilters can be specified to monitor only portions of the file system, > ignoring files/directories of no interest. This is more efficient and reduces > the amount of noise from un-wanted file/directory events > From a quick look at IO-79, the above also applies to that proposal. > Additionally IMO the solution in IO-79 would benefit from been broken out > from the two DirectoryPoller and FilePoller artifacts. > There are also some changes to the API specified in JCI's fam: > 1) FileObserver (FilesystemAlterationObserver in fam) has additional init() > and destroy() methods > 2) FileMonitor (FilesystemAlterationMonitor in fam) has > addObserver/removeObserver methods rather than addListener/removeListener > methods. The issue (IMO) with fam is that the monitor is fixed to the > FilesystemAlterationObserverImpl implementation, rather than any > FilesystemAlterationObserver implementation. Also the ability to specify file > filters means that there is a need to be able to add more than one observer > for the same root directory. > [1] http://svn.apache.org/repos/asf/commons/proper/jci/trunk/fam/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IO-132) File Listener/Monitor
[ https://issues.apache.org/jira/browse/IO-132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated IO-132: --- Attachment: (was: FileListener.java) > File Listener/Monitor > - > > Key: IO-132 > URL: https://issues.apache.org/jira/browse/IO-132 > Project: Commons IO > Issue Type: New Feature >Reporter: Niall Pemberton >Assignee: Niall Pemberton > Fix For: 2.x > > > Commons JCI has a "fam" (file alteration monitor) module[1] which provides a > listener for file and directory create/change/delete events. I have done some > work refactoring the JCI implementation and propose adding to to Commons IO. > There is already an existing request/propsal to add similar functionality in > IO-79 from Jim Harrington (which includes code). > There are IMO two main differences (IMO improvements) in this implementation > over exsiting JCI fam module: > 1) It uses a matching array technique to compare previous and current > directory contents which minimizes object creation > 2) FileFilters can be specified to monitor only portions of the file system, > ignoring files/directories of no interest. This is more efficient and reduces > the amount of noise from un-wanted file/directory events > From a quick look at IO-79, the above also applies to that proposal. > Additionally IMO the solution in IO-79 would benefit from been broken out > from the two DirectoryPoller and FilePoller artifacts. > There are also some changes to the API specified in JCI's fam: > 1) FileObserver (FilesystemAlterationObserver in fam) has additional init() > and destroy() methods > 2) FileMonitor (FilesystemAlterationMonitor in fam) has > addObserver/removeObserver methods rather than addListener/removeListener > methods. The issue (IMO) with fam is that the monitor is fixed to the > FilesystemAlterationObserverImpl implementation, rather than any > FilesystemAlterationObserver implementation. Also the ability to specify file > filters means that there is a need to be able to add more than one observer > for the same root directory. > [1] http://svn.apache.org/repos/asf/commons/proper/jci/trunk/fam/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IO-132) File Listener/Monitor
[ https://issues.apache.org/jira/browse/IO-132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated IO-132: --- Attachment: (was: AbstractFileObserverTestCase.java) > File Listener/Monitor > - > > Key: IO-132 > URL: https://issues.apache.org/jira/browse/IO-132 > Project: Commons IO > Issue Type: New Feature >Reporter: Niall Pemberton >Assignee: Niall Pemberton > Fix For: 2.x > > > Commons JCI has a "fam" (file alteration monitor) module[1] which provides a > listener for file and directory create/change/delete events. I have done some > work refactoring the JCI implementation and propose adding to to Commons IO. > There is already an existing request/propsal to add similar functionality in > IO-79 from Jim Harrington (which includes code). > There are IMO two main differences (IMO improvements) in this implementation > over exsiting JCI fam module: > 1) It uses a matching array technique to compare previous and current > directory contents which minimizes object creation > 2) FileFilters can be specified to monitor only portions of the file system, > ignoring files/directories of no interest. This is more efficient and reduces > the amount of noise from un-wanted file/directory events > From a quick look at IO-79, the above also applies to that proposal. > Additionally IMO the solution in IO-79 would benefit from been broken out > from the two DirectoryPoller and FilePoller artifacts. > There are also some changes to the API specified in JCI's fam: > 1) FileObserver (FilesystemAlterationObserver in fam) has additional init() > and destroy() methods > 2) FileMonitor (FilesystemAlterationMonitor in fam) has > addObserver/removeObserver methods rather than addListener/removeListener > methods. The issue (IMO) with fam is that the monitor is fixed to the > FilesystemAlterationObserverImpl implementation, rather than any > FilesystemAlterationObserver implementation. Also the ability to specify file > filters means that there is a need to be able to add more than one observer > for the same root directory. > [1] http://svn.apache.org/repos/asf/commons/proper/jci/trunk/fam/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IO-132) File Listener/Monitor
[ https://issues.apache.org/jira/browse/IO-132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated IO-132: --- Attachment: (was: CollectionFileListenerTestCase.java) > File Listener/Monitor > - > > Key: IO-132 > URL: https://issues.apache.org/jira/browse/IO-132 > Project: Commons IO > Issue Type: New Feature >Reporter: Niall Pemberton >Assignee: Niall Pemberton > Fix For: 2.x > > > Commons JCI has a "fam" (file alteration monitor) module[1] which provides a > listener for file and directory create/change/delete events. I have done some > work refactoring the JCI implementation and propose adding to to Commons IO. > There is already an existing request/propsal to add similar functionality in > IO-79 from Jim Harrington (which includes code). > There are IMO two main differences (IMO improvements) in this implementation > over exsiting JCI fam module: > 1) It uses a matching array technique to compare previous and current > directory contents which minimizes object creation > 2) FileFilters can be specified to monitor only portions of the file system, > ignoring files/directories of no interest. This is more efficient and reduces > the amount of noise from un-wanted file/directory events > From a quick look at IO-79, the above also applies to that proposal. > Additionally IMO the solution in IO-79 would benefit from been broken out > from the two DirectoryPoller and FilePoller artifacts. > There are also some changes to the API specified in JCI's fam: > 1) FileObserver (FilesystemAlterationObserver in fam) has additional init() > and destroy() methods > 2) FileMonitor (FilesystemAlterationMonitor in fam) has > addObserver/removeObserver methods rather than addListener/removeListener > methods. The issue (IMO) with fam is that the monitor is fixed to the > FilesystemAlterationObserverImpl implementation, rather than any > FilesystemAlterationObserver implementation. Also the ability to specify file > filters means that there is a need to be able to add more than one observer > for the same root directory. > [1] http://svn.apache.org/repos/asf/commons/proper/jci/trunk/fam/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IO-132) File Listener/Monitor
[ https://issues.apache.org/jira/browse/IO-132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated IO-132: --- Attachment: (was: CollectionFileListener.java) > File Listener/Monitor > - > > Key: IO-132 > URL: https://issues.apache.org/jira/browse/IO-132 > Project: Commons IO > Issue Type: New Feature >Reporter: Niall Pemberton >Assignee: Niall Pemberton > Fix For: 2.x > > > Commons JCI has a "fam" (file alteration monitor) module[1] which provides a > listener for file and directory create/change/delete events. I have done some > work refactoring the JCI implementation and propose adding to to Commons IO. > There is already an existing request/propsal to add similar functionality in > IO-79 from Jim Harrington (which includes code). > There are IMO two main differences (IMO improvements) in this implementation > over exsiting JCI fam module: > 1) It uses a matching array technique to compare previous and current > directory contents which minimizes object creation > 2) FileFilters can be specified to monitor only portions of the file system, > ignoring files/directories of no interest. This is more efficient and reduces > the amount of noise from un-wanted file/directory events > From a quick look at IO-79, the above also applies to that proposal. > Additionally IMO the solution in IO-79 would benefit from been broken out > from the two DirectoryPoller and FilePoller artifacts. > There are also some changes to the API specified in JCI's fam: > 1) FileObserver (FilesystemAlterationObserver in fam) has additional init() > and destroy() methods > 2) FileMonitor (FilesystemAlterationMonitor in fam) has > addObserver/removeObserver methods rather than addListener/removeListener > methods. The issue (IMO) with fam is that the monitor is fixed to the > FilesystemAlterationObserverImpl implementation, rather than any > FilesystemAlterationObserver implementation. Also the ability to specify file > filters means that there is a need to be able to add more than one observer > for the same root directory. > [1] http://svn.apache.org/repos/asf/commons/proper/jci/trunk/fam/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IO-132) File Listener/Monitor
[ https://issues.apache.org/jira/browse/IO-132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated IO-132: --- Attachment: (was: FileMonitor.java) > File Listener/Monitor > - > > Key: IO-132 > URL: https://issues.apache.org/jira/browse/IO-132 > Project: Commons IO > Issue Type: New Feature >Reporter: Niall Pemberton >Assignee: Niall Pemberton > Fix For: 2.x > > > Commons JCI has a "fam" (file alteration monitor) module[1] which provides a > listener for file and directory create/change/delete events. I have done some > work refactoring the JCI implementation and propose adding to to Commons IO. > There is already an existing request/propsal to add similar functionality in > IO-79 from Jim Harrington (which includes code). > There are IMO two main differences (IMO improvements) in this implementation > over exsiting JCI fam module: > 1) It uses a matching array technique to compare previous and current > directory contents which minimizes object creation > 2) FileFilters can be specified to monitor only portions of the file system, > ignoring files/directories of no interest. This is more efficient and reduces > the amount of noise from un-wanted file/directory events > From a quick look at IO-79, the above also applies to that proposal. > Additionally IMO the solution in IO-79 would benefit from been broken out > from the two DirectoryPoller and FilePoller artifacts. > There are also some changes to the API specified in JCI's fam: > 1) FileObserver (FilesystemAlterationObserver in fam) has additional init() > and destroy() methods > 2) FileMonitor (FilesystemAlterationMonitor in fam) has > addObserver/removeObserver methods rather than addListener/removeListener > methods. The issue (IMO) with fam is that the monitor is fixed to the > FilesystemAlterationObserverImpl implementation, rather than any > FilesystemAlterationObserver implementation. Also the ability to specify file > filters means that there is a need to be able to add more than one observer > for the same root directory. > [1] http://svn.apache.org/repos/asf/commons/proper/jci/trunk/fam/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IO-132) File Listener/Monitor
[ https://issues.apache.org/jira/browse/IO-132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated IO-132: --- Attachment: (was: FileObserverImpl.java) > File Listener/Monitor > - > > Key: IO-132 > URL: https://issues.apache.org/jira/browse/IO-132 > Project: Commons IO > Issue Type: New Feature >Reporter: Niall Pemberton >Assignee: Niall Pemberton > Fix For: 2.x > > > Commons JCI has a "fam" (file alteration monitor) module[1] which provides a > listener for file and directory create/change/delete events. I have done some > work refactoring the JCI implementation and propose adding to to Commons IO. > There is already an existing request/propsal to add similar functionality in > IO-79 from Jim Harrington (which includes code). > There are IMO two main differences (IMO improvements) in this implementation > over exsiting JCI fam module: > 1) It uses a matching array technique to compare previous and current > directory contents which minimizes object creation > 2) FileFilters can be specified to monitor only portions of the file system, > ignoring files/directories of no interest. This is more efficient and reduces > the amount of noise from un-wanted file/directory events > From a quick look at IO-79, the above also applies to that proposal. > Additionally IMO the solution in IO-79 would benefit from been broken out > from the two DirectoryPoller and FilePoller artifacts. > There are also some changes to the API specified in JCI's fam: > 1) FileObserver (FilesystemAlterationObserver in fam) has additional init() > and destroy() methods > 2) FileMonitor (FilesystemAlterationMonitor in fam) has > addObserver/removeObserver methods rather than addListener/removeListener > methods. The issue (IMO) with fam is that the monitor is fixed to the > FilesystemAlterationObserverImpl implementation, rather than any > FilesystemAlterationObserver implementation. Also the ability to specify file > filters means that there is a need to be able to add more than one observer > for the same root directory. > [1] http://svn.apache.org/repos/asf/commons/proper/jci/trunk/fam/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IO-132) File Listener/Monitor
[ https://issues.apache.org/jira/browse/IO-132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated IO-132: --- Attachment: (was: JDKLoggingFileListener.java) > File Listener/Monitor > - > > Key: IO-132 > URL: https://issues.apache.org/jira/browse/IO-132 > Project: Commons IO > Issue Type: New Feature >Reporter: Niall Pemberton >Assignee: Niall Pemberton > Fix For: 2.x > > > Commons JCI has a "fam" (file alteration monitor) module[1] which provides a > listener for file and directory create/change/delete events. I have done some > work refactoring the JCI implementation and propose adding to to Commons IO. > There is already an existing request/propsal to add similar functionality in > IO-79 from Jim Harrington (which includes code). > There are IMO two main differences (IMO improvements) in this implementation > over exsiting JCI fam module: > 1) It uses a matching array technique to compare previous and current > directory contents which minimizes object creation > 2) FileFilters can be specified to monitor only portions of the file system, > ignoring files/directories of no interest. This is more efficient and reduces > the amount of noise from un-wanted file/directory events > From a quick look at IO-79, the above also applies to that proposal. > Additionally IMO the solution in IO-79 would benefit from been broken out > from the two DirectoryPoller and FilePoller artifacts. > There are also some changes to the API specified in JCI's fam: > 1) FileObserver (FilesystemAlterationObserver in fam) has additional init() > and destroy() methods > 2) FileMonitor (FilesystemAlterationMonitor in fam) has > addObserver/removeObserver methods rather than addListener/removeListener > methods. The issue (IMO) with fam is that the monitor is fixed to the > FilesystemAlterationObserverImpl implementation, rather than any > FilesystemAlterationObserver implementation. Also the ability to specify file > filters means that there is a need to be able to add more than one observer > for the same root directory. > [1] http://svn.apache.org/repos/asf/commons/proper/jci/trunk/fam/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IO-132) File Listener/Monitor
[ https://issues.apache.org/jira/browse/IO-132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated IO-132: --- Attachment: (was: FileObserver.java) > File Listener/Monitor > - > > Key: IO-132 > URL: https://issues.apache.org/jira/browse/IO-132 > Project: Commons IO > Issue Type: New Feature >Reporter: Niall Pemberton >Assignee: Niall Pemberton > Fix For: 2.x > > > Commons JCI has a "fam" (file alteration monitor) module[1] which provides a > listener for file and directory create/change/delete events. I have done some > work refactoring the JCI implementation and propose adding to to Commons IO. > There is already an existing request/propsal to add similar functionality in > IO-79 from Jim Harrington (which includes code). > There are IMO two main differences (IMO improvements) in this implementation > over exsiting JCI fam module: > 1) It uses a matching array technique to compare previous and current > directory contents which minimizes object creation > 2) FileFilters can be specified to monitor only portions of the file system, > ignoring files/directories of no interest. This is more efficient and reduces > the amount of noise from un-wanted file/directory events > From a quick look at IO-79, the above also applies to that proposal. > Additionally IMO the solution in IO-79 would benefit from been broken out > from the two DirectoryPoller and FilePoller artifacts. > There are also some changes to the API specified in JCI's fam: > 1) FileObserver (FilesystemAlterationObserver in fam) has additional init() > and destroy() methods > 2) FileMonitor (FilesystemAlterationMonitor in fam) has > addObserver/removeObserver methods rather than addListener/removeListener > methods. The issue (IMO) with fam is that the monitor is fixed to the > FilesystemAlterationObserverImpl implementation, rather than any > FilesystemAlterationObserver implementation. Also the ability to specify file > filters means that there is a need to be able to add more than one observer > for the same root directory. > [1] http://svn.apache.org/repos/asf/commons/proper/jci/trunk/fam/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IO-132) File Listener/Monitor
[ https://issues.apache.org/jira/browse/IO-132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated IO-132: --- Attachment: (was: FileObserverImplTestCase.java) > File Listener/Monitor > - > > Key: IO-132 > URL: https://issues.apache.org/jira/browse/IO-132 > Project: Commons IO > Issue Type: New Feature >Reporter: Niall Pemberton >Assignee: Niall Pemberton > Fix For: 2.x > > > Commons JCI has a "fam" (file alteration monitor) module[1] which provides a > listener for file and directory create/change/delete events. I have done some > work refactoring the JCI implementation and propose adding to to Commons IO. > There is already an existing request/propsal to add similar functionality in > IO-79 from Jim Harrington (which includes code). > There are IMO two main differences (IMO improvements) in this implementation > over exsiting JCI fam module: > 1) It uses a matching array technique to compare previous and current > directory contents which minimizes object creation > 2) FileFilters can be specified to monitor only portions of the file system, > ignoring files/directories of no interest. This is more efficient and reduces > the amount of noise from un-wanted file/directory events > From a quick look at IO-79, the above also applies to that proposal. > Additionally IMO the solution in IO-79 would benefit from been broken out > from the two DirectoryPoller and FilePoller artifacts. > There are also some changes to the API specified in JCI's fam: > 1) FileObserver (FilesystemAlterationObserver in fam) has additional init() > and destroy() methods > 2) FileMonitor (FilesystemAlterationMonitor in fam) has > addObserver/removeObserver methods rather than addListener/removeListener > methods. The issue (IMO) with fam is that the monitor is fixed to the > FilesystemAlterationObserverImpl implementation, rather than any > FilesystemAlterationObserver implementation. Also the ability to specify file > filters means that there is a need to be able to add more than one observer > for the same root directory. > [1] http://svn.apache.org/repos/asf/commons/proper/jci/trunk/fam/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IO-132) File Listener/Monitor
[ https://issues.apache.org/jira/browse/IO-132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated IO-132: --- Attachment: FilesystemMonitor.java FilesystemObserver.java FilesystemListener.java Stephen's comment was that it seemed too much like a framework. I've re-written the implementations with a single concrete implementation of FilesystemObserver. With that refactoring and being able to use JDK 1.5 features I believe it is much more straight forward - attaching the following: - FilesystemListener - interface which receives create/change/delete events for files/directories - FilesystemObserver - checks the current state of a directory against what it has cached from the previous invocation and notifies listeners - FilesystemMonitor - Runnable that invokes registered observers at a specified interval I also have a do nothing FilesystemListenerAdaptor implementation and FilesystemObserver test case. I'll leave this for review/comment for a while before I commit. > File Listener/Monitor > - > > Key: IO-132 > URL: https://issues.apache.org/jira/browse/IO-132 > Project: Commons IO > Issue Type: New Feature >Reporter: Niall Pemberton >Assignee: Niall Pemberton > Fix For: 2.x > > Attachments: FilesystemListener.java, FilesystemMonitor.java, > FilesystemObserver.java > > > Commons JCI has a "fam" (file alteration monitor) module[1] which provides a > listener for file and directory create/change/delete events. I have done some > work refactoring the JCI implementation and propose adding to to Commons IO. > There is already an existing request/propsal to add similar functionality in > IO-79 from Jim Harrington (which includes code). > There are IMO two main differences (IMO improvements) in this implementation > over exsiting JCI fam module: > 1) It uses a matching array technique to compare previous and current > directory contents which minimizes object creation > 2) FileFilters can be specified to monitor only portions of the file system, > ignoring files/directories of no interest. This is more efficient and reduces > the amount of noise from un-wanted file/directory events > From a quick look at IO-79, the above also applies to that proposal. > Additionally IMO the solution in IO-79 would benefit from been broken out > from the two DirectoryPoller and FilePoller artifacts. > There are also some changes to the API specified in JCI's fam: > 1) FileObserver (FilesystemAlterationObserver in fam) has additional init() > and destroy() methods > 2) FileMonitor (FilesystemAlterationMonitor in fam) has > addObserver/removeObserver methods rather than addListener/removeListener > methods. The issue (IMO) with fam is that the monitor is fixed to the > FilesystemAlterationObserverImpl implementation, rather than any > FilesystemAlterationObserver implementation. Also the ability to specify file > filters means that there is a need to be able to add more than one observer > for the same root directory. > [1] http://svn.apache.org/repos/asf/commons/proper/jci/trunk/fam/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
