Menu
▾
▴
smartfrog-users
|
From: <dep...@al...> - 2010-11-01 10:44:03
|
Hi, I would like to delete multiple files, using a pattern. This seems like a common enough action, but I can't figure out how to do it with standard components. Thanks Dmitry Epstein | Developer Allied Testing T +7 495 544 4869 Ext 417 M +7 926 215 7336 www.alliedtesting.com We Deliver Quality. |
|
From: Steve L. <ste...@hp...> - 2010-11-01 13:21:19
|
On 01/11/10 10:43, dep...@al... wrote: > > > Hi, > > I would like to delete multiple files, using a pattern. This seems like > a common enough action, but I can’t figure out how to do it with > standard components. > That's an interesting thought, I've just run over the source code to see what we do there. Summary: we have components that delete entire directories, both the Tempdir and Mkdir components can do this when being terminated, and that's all we've needed. That said, DeleteFile and DeleteDir components would be useful in some situations, so I've added two bugreps http://jira.smartfrog.org/jira/browse/SFOS-1541 http://jira.smartfrog.org/jira/browse/SFOS-1542 Deleting a single file is easy, the directory one not so hard, once you get into patterns it gets tricky, so don't hold your breath waiting for that feature. What you can do right now is use the Ant components and just use Ant's Delete task, give it the pattern. Be aware that Ant's code ignores SCM paths (like .svn, .cvs, .git) etc, and its copy logic checks source and destination times by default -features you want at build time but which interfere during deployments -steve |
|
From: Steve L. <ste...@hp...> - 2010-11-01 13:33:23
|
On 01/11/10 13:20, Steve Loughran wrote: > On 01/11/10 10:43, dep...@al... wrote: >> >> >> Hi, >> >> I would like to delete multiple files, using a pattern. This seems like >> a common enough action, but I can’t figure out how to do it with >> standard components. >> > > That's an interesting thought, I've just run over the source code to see > what we do there. > > Summary: we have components that delete entire directories, both the > Tempdir and Mkdir components can do this when being terminated, and > that's all we've needed. > > That said, DeleteFile and DeleteDir components would be useful in some > situations, so I've added two bugreps > > http://jira.smartfrog.org/jira/browse/SFOS-1541 > http://jira.smartfrog.org/jira/browse/SFOS-1542 > A quick look at the code shows me that you can use SelfDeletingFile to delete a file on startup by configuring itself to shut itself down just after starting up. DeleteFileOnStartup extends SelfDeletingFile { sfShouldTerminate true; } This is only for a single file and doesn't handle error reporting well, as all code to clean things up on shutdown tends to log-and-continue on any problem. |
|
From: <dep...@al...> - 2010-11-01 14:00:34
|
> From: Steve Loughran [mailto:ste...@hp...] > Sent: Monday, November 01, 2010 4:33 PM > Cc: Dmitry Epstein; sma...@li... > Subject: Re: [Smartfrog-users] Deleting multiple files? > > On 01/11/10 13:20, Steve Loughran wrote: > > On 01/11/10 10:43, dep...@al... wrote: > >> > >> > >> Hi, > >> > >> I would like to delete multiple files, using a pattern. This seems > like > >> a common enough action, but I can't figure out how to do it with > >> standard components. > >> > > > > That's an interesting thought, I've just run over the source code to > see > > what we do there. > > > > Summary: we have components that delete entire directories, both the > > Tempdir and Mkdir components can do this when being terminated, and > > that's all we've needed. > > > > That said, DeleteFile and DeleteDir components would be useful in > some > > situations, so I've added two bugreps > > > > http://jira.smartfrog.org/jira/browse/SFOS-1541 > > http://jira.smartfrog.org/jira/browse/SFOS-1542 > > > > A quick look at the code shows me that you can use SelfDeletingFile to > delete a file on startup by configuring itself to shut itself down just > after starting up. > > DeleteFileOnStartup extends SelfDeletingFile { > sfShouldTerminate true; > } > > This is only for a single file and doesn't handle error reporting well, > as all code to clean things up on shutdown tends to log-and-continue on > any problem. Yes, I was aware of SelfDeletingFile. I was thinking of perhaps adding deleteOnExit attribute to the Files component, or patching together a new component, based on Files. Dmitry Epstein | Developer Allied Testing |
|
From: Steve L. <ste...@hp...> - 2010-11-01 14:31:08
|
> > Yes, I was aware of SelfDeletingFile. I was thinking of perhaps adding deleteOnExit attribute to the Files component, or patching together a new component, based on Files. > OK. I'm just checking in a DeleteFile component that does the delete operation but is more helpful on a failure, even security exceptions are caught and turned into errors. I also had a quick scan and cleanup of the test of that code, again checking it in as we speak. Looking at that code, the target for modification would be to subclass FilesCompoundImpl and have a child DeleteFiles which would call FilesCompoundImpl.sfStart(), take that list of files and do a best effort attempt at deleting them, tracking which ones couldn't be deleted and adding that up to some results which could be reported or turned into an error. |
|
From: <dep...@al...> - 2010-11-08 10:30:27
|
> -----Original Message----- > From: Steve Loughran [mailto:ste...@hp...] > Sent: Monday, November 01, 2010 5:31 PM > To: Dmitry Epstein > Cc: sma...@li... > Subject: Re: [Smartfrog-users] Deleting multiple files? > > > > > > Yes, I was aware of SelfDeletingFile. I was thinking of perhaps > adding deleteOnExit attribute to the Files component, or patching > together a new component, based on Files. > > > > OK. I'm just checking in a DeleteFile component that does the delete > operation but is more helpful on a failure, even security exceptions > are > caught and turned into errors. > > I also had a quick scan and cleanup of the test of that code, again > checking it in as we speak. Looking at that code, the target for > modification would be to subclass FilesCompoundImpl and have a child > DeleteFiles which would call FilesCompoundImpl.sfStart(), take that > list > of files and do a best effort attempt at deleting them, tracking which > ones couldn't be deleted and adding that up to some results which could > be reported or turned into an error. Speaking of files, a useful workflow component would be one that iterates over a list of files, i.e. performs a parameterized execution of its action sub-component, where the parameter is a path-name from a Files component. Or perhaps a more general component that iterates over any given vector, with a child component specifically for files. I know this would be useful for my test designs. Dmitry |
|
From: Steve L. <ste...@hp...> - 2010-11-09 15:06:02
|
On 08/11/10 10:30, dep...@al... wrote: >> -----Original Message----- >> From: Steve Loughran [mailto:ste...@hp...] >> Sent: Monday, November 01, 2010 5:31 PM >> To: Dmitry Epstein >> Cc: sma...@li... >> Subject: Re: [Smartfrog-users] Deleting multiple files? >> >> >>> >>> Yes, I was aware of SelfDeletingFile. I was thinking of perhaps >> adding deleteOnExit attribute to the Files component, or patching >> together a new component, based on Files. >>> >> >> OK. I'm just checking in a DeleteFile component that does the delete >> operation but is more helpful on a failure, even security exceptions >> are >> caught and turned into errors. >> >> I also had a quick scan and cleanup of the test of that code, again >> checking it in as we speak. Looking at that code, the target for >> modification would be to subclass FilesCompoundImpl and have a child >> DeleteFiles which would call FilesCompoundImpl.sfStart(), take that >> list >> of files and do a best effort attempt at deleting them, tracking which >> ones couldn't be deleted and adding that up to some results which could >> be reported or turned into an error. > > Speaking of files, a useful workflow component would be one that iterates over a list of files, i.e. performs a parameterized execution of its action sub-component, where the parameter is a path-name from a Files component. I had an opportunity to sit with the IDE and the SF code in front of me yesterday, and now have an uncommitted change that makes the FilesCompoundImpl component a subclass of EventCompoundImpl, which makes it one very short distance away from having an action compound deploy. But that gets very confusing as to what contains files and what contains the action. What that parent change does do is make the FilesCompound a workflow component that can read the attributes saying what to do after building the list, and it would be trivial to add a target attribute to specify which component to attach the list. > Or perhaps a more general component that iterates over any given vector, with a child component specifically for files. Probably simplest to deploy the action once the files have been gathered. > > I know this would be useful for my test designs. I think I understand. So, what is most usable/easy to test, document and understand? 1. -tweak FilesCompoundImpl, add a FilesActionCompoundImpl that deploys the action after building up the filelist, skipping that action until then, the actions would have to take a reference to something that can serve up the file list, either a simple attribute/list or a component that can return the list of files over RMI. 2. have FilesCompoundImpl support workflow attributes and a target attribute, add the ability to write its filelist to a destination (as both a list of strings and a single path.separator separated string.) both of these would be backed by some FilesOperations which would be workflow components. I'd start with DeleteFiles - delete any, do a best effort skip all missing files, log failures and continue. ExistsFiles - check the files all exist (or don't exist, we'll use that for testing DeletesFiles) Other actions: copy, scp, etc, are feature creep. What do you think, (1) or (2)? I think (2) is more generic and would work in more places. Also trying to test and debug the workflow components is no fun, believe me, especially once you start encountering odd race conditions with termination events coming in while you are starting up: http://jira.smartfrog.org/jira/browse/SFOS-1510 http://jira.smartfrog.org/jira/browse/SFOS-1526 -Steve |
|
From: <dep...@al...> - 2010-11-18 10:18:49
|
Hi Steve,
Sorry to be taking so long to reply - other work intervened. You are in a better position to decide what is more feasible to implement and support, as far as file actions go. On further reflection I think that perhaps a generic action component that iterates the action over a list of parameters would be useful for more than just working with a list of files. With files, you would just need to combine it with Files or FilesCompound, ensuring that the latter deploys first (isn't that the default behavior when two components follow each other in a compound?)
A use case would look something like this:
DoStuffWithFiles extends Compound {
files extends Files {
...
}
doStuff extends Iterate {
params PARENT:files:fileList;
action extends {
...
}
}
}
Regards,
Dmitry
-----Original Message-----
From: Steve Loughran [mailto:ste...@hp...]
Sent: Tuesday, November 09, 2010 6:06 PM
To: Dmitry Epstein
Cc: sma...@li...
Subject: Re: [Smartfrog-users] Deleting multiple files?
On 08/11/10 10:30, dep...@al... wrote:
>> -----Original Message-----
>> From: Steve Loughran [mailto:ste...@hp...]
>> Sent: Monday, November 01, 2010 5:31 PM
>> To: Dmitry Epstein
>> Cc: sma...@li...
>> Subject: Re: [Smartfrog-users] Deleting multiple files?
>>
>>
>>>
>>> Yes, I was aware of SelfDeletingFile. I was thinking of perhaps
>> adding deleteOnExit attribute to the Files component, or patching
>> together a new component, based on Files.
>>>
>>
>> OK. I'm just checking in a DeleteFile component that does the delete
>> operation but is more helpful on a failure, even security exceptions
>> are caught and turned into errors.
>>
>> I also had a quick scan and cleanup of the test of that code, again
>> checking it in as we speak. Looking at that code, the target for
>> modification would be to subclass FilesCompoundImpl and have a child
>> DeleteFiles which would call FilesCompoundImpl.sfStart(), take that
>> list of files and do a best effort attempt at deleting them, tracking
>> which ones couldn't be deleted and adding that up to some results
>> which could be reported or turned into an error.
>
> Speaking of files, a useful workflow component would be one that iterates over a list of files, i.e. performs a parameterized execution of its action sub-component, where the parameter is a path-name from a Files component.
I had an opportunity to sit with the IDE and the SF code in front of me yesterday, and now have an uncommitted change that makes the FilesCompoundImpl component a subclass of EventCompoundImpl, which makes it one very short distance away from having an action compound deploy.
But that gets very confusing as to what contains files and what contains the action.
What that parent change does do is make the FilesCompound a workflow component that can read the attributes saying what to do after building the list, and it would be trivial to add a target attribute to specify which component to attach the list.
> Or perhaps a more general component that iterates over any given vector, with a child component specifically for files.
Probably simplest to deploy the action once the files have been gathered.
>
> I know this would be useful for my test designs.
I think I understand. So, what is most usable/easy to test, document and understand?
1. -tweak FilesCompoundImpl, add a FilesActionCompoundImpl that deploys
the action after building up the filelist, skipping that action until
then, the actions would have to take a reference to something that can
serve up the file list, either a simple attribute/list or a component
that can return the list of files over RMI.
2. have FilesCompoundImpl support workflow attributes and a target
attribute, add the ability to write its filelist to a destination (as
both a list of strings and a single path.separator separated string.)
both of these would be backed by some FilesOperations which would be
workflow components. I'd start with
DeleteFiles - delete any, do a best effort skip all missing files, log
failures and continue.
ExistsFiles - check the files all exist (or don't exist, we'll use that
for testing DeletesFiles)
Other actions: copy, scp, etc, are feature creep.
What do you think, (1) or (2)? I think (2) is more generic and would
work in more places. Also trying to test and debug the workflow
components is no fun, believe me, especially once you start encountering
odd race conditions with termination events coming in while you are
starting up:
http://jira.smartfrog.org/jira/browse/SFOS-1510
http://jira.smartfrog.org/jira/browse/SFOS-1526
-Steve
|
Thanks for helping keep SourceForge clean.
X