[vfs] VfsTask
I have pronlems with VfsTask.
First of all I need to instantiate AntLogger in ant tasks
so AntLogger needs to be made public.
But that is not enough since I need to instantiate it also
in DataTypes (FileSet in particular).
Also resolveFile needs to be accessed from FileSet DataType.
Therefore I would propably need VfsDataType that would be very
similar to VfsTask. Which led me to wondering about FileSystemManager.
Now ant tasks instantiate the manager if they invoke resolveFile method.
And when the build completes the manager is closed.
When ant tasks call some components (like toolbox components) that are not related to
ant
they have to open their own manager.
So I was wondering why not just use VFS class to get the manager also in ant tasks?
And make the AntLogger public and independent class like this:
/**
* A commons-logging wrapper for Ant logging.
*/
public class AntLogger
implements Log
{
private ProjectComponent pc;
public AntLogger(ProjectComponent pc) {
this.pc = pc;
}
public void debug(final Object o)
{
pc.log(String.valueOf(o), Project.MSG_DEBUG);
}
public void debug(Object o, Throwable throwable)
{
debug(o);
}
public void error(Object o)
{
pc.log(String.valueOf(o), Project.MSG_ERR);
}
public void error(Object o, Throwable throwable)
{
error(o);
}
public void fatal(Object o)
{
pc.log(String.valueOf(o), Project.MSG_ERR);
}
public void fatal(Object o, Throwable throwable)
{
fatal(o);
}
public void info(Object o)
{
pc.log(String.valueOf(o), Project.MSG_INFO);
}
public void info(Object o, Throwable throwable)
{
info(o);
}
public void trace(Object o)
{
}
public void trace(Object o, Throwable throwable)
{
}
public void warn(Object o)
{
pc.log(String.valueOf(o), Project.MSG_WARN);
}
public void warn(Object o, Throwable throwable)
{
warn(o);
}
public boolean isDebugEnabled()
{
return true;
}
public boolean isErrorEnabled()
{
return true;
}
public boolean isFatalEnabled()
{
return true;
}
public boolean isInfoEnabled()
{
return true;
}
public boolean isTraceEnabled()
{
return false;
}
public boolean isWarnEnabled()
{
return true;
}
}
Then I can instantiate AntLogger also from DataTypes.
And I can resolveFiles from DataTypes by getting a manager.
- rami
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vfs] VfsTask
What happens if FileSystemManager is not closed and JVM exits. In other words what does close method do? And is it a problem if there are many FileSystemManagers? This can happen when instantiating outside of VFS class. Can there be any problems if Ant task uses one manager instance and some other class that ant task uses, uses some other manager instance? - rami - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vfs] VfsTask
Rami Ojares schrieb: I have pronlems with VfsTask. First of all I need to instantiate AntLogger in ant tasks so AntLogger needs to be made public. But that is not enough since I need to instantiate it also in DataTypes (FileSet in particular). Also resolveFile needs to be accessed from FileSet DataType. Therefore I would propably need VfsDataType that would be very similar to VfsTask. Which led me to wondering about FileSystemManager. Now ant tasks instantiate the manager if they invoke resolveFile method. And when the build completes the manager is closed. When ant tasks call some components (like toolbox components) that are not related to ant they have to open their own manager. What of your toolbox component do need the filesystemmanager? I looked into them, but they only use the passed fileobjects. So I was wondering why not just use VFS class to get the manager also in ant tasks? I like the idea of the current ant task implementation, they instantiate their own manager in the context of the current ant project. I am not sure if we should use the static way (VFS.getManager()) as this might have bad sideeffects when using ant embedded. If the user use VFS.getManager() too and we close this instance after ant is done, we close this manager (and all open files) too (it is the same manager instance). Also we can not simply use setLogger() on this instance, there might already be another logger set by the user on this instance (in the embedded case) Might it be possible to implement a special ant task - say vfs-manager id=vfs class=StandardFileSystemManager / this allows us to add some configuration options later (e.g. proxy settings, ssh settings) using this task and refer to this instance within the other tasks and maybe from within DataType (FileSet) Maybe a construct like vfs-manager id=vfs class=global / could be possible which will use the VFS.getManager(). And when using ant embedded, the developer could inject the manager instance. Not sure if all this could work, as i havent written an ant task till now. Do you think this could be an option? -- Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vfs] VfsTask
Rami Ojares wrote: What happens if FileSystemManager is not closed and JVM exits. Nothing special - there is no cleanup handling on jvm exit. In other words what does close method do? close() on the manager release all used resources resolved/used by this manager instance And is it a problem if there are many FileSystemManagers? This can happen when instantiating outside of VFS class. This is no problem. Beside the fact that manager1.resolveFile(abc.txt) returns not the same instance as manager2.resolveFile(abc.txt). Can there be any problems if Ant task uses one manager instance and some other class that ant task uses, uses some other manager instance? No technical problems. However, maybe the vfs-manager could be a clean solution and let the door to the various instantiation mechanism open? -- Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vfs] VfsTask
What of your toolbox component do need the filesystemmanager? I looked into them, but they only use the passed fileobjects. Yeah, that was more like a what if question :) I like the idea of the current ant task implementation, they instantiate their own manager in the context of the current ant project. ok I am not sure if we should use the static way (VFS.getManager()) as this might have bad sideeffects when using ant embedded. ok If the user use VFS.getManager() too and we close this instance after ant is done, we close this manager (and all open files) too (it is the same manager instance). Also we can not simply use setLogger() on this instance, there might already be another logger set by the user on this instance (in the embedded case) Yep. However I need to get AntLogger in FileSet and I need to resolve files there. So there are 2 options. - Duplicating VfsTask to VfsDataType or - separating AntLogger as shown and making resolveFile method to resolveFile(Project p, String uri) Might it be possible to implement a special ant task - say vfs-manager id=vfs class=StandardFileSystemManager / this allows us to add some configuration options later (e.g. proxy settings, ssh settings) using this task and refer to this instance within the other tasks and maybe from within DataType (FileSet) Maybe a construct like vfs-manager id=vfs class=global / could be possible which will use the VFS.getManager(). And when using ant embedded, the developer could inject the manager instance. Not sure if all this could work, as i havent written an ant task till now. Do you think this could be an option? I don't understand fully but I quess you want a way to configure the manager in ant for different tasks. This could be a DataType. eg. vfs-copy toDir=path vfs-manager proxy=foo replicator=bar/ vfs-fileset dir=path include name=*.b?t/ /vfs-fileset /vfs-copy And then a task could support the datatype and use a filemanager with given configuration. - rami - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vfs] VfsTask
Rami Ojares wrote: I don't understand fully but I quess you want a way to configure the manager in ant for different tasks. This could be a DataType. eg. vfs-copy toDir=path vfs-manager proxy=foo replicator=bar/ vfs-fileset dir=path include name=*.b?t/ /vfs-fileset /vfs-copy I thought about vfs-manager id=default class=StandardFileSystemManager vfs-option but this is to specify and implement later ../ /vfs-manager vfs-manager id=special class=MyHyperVFSFileSystemManager / vfs-copy manager=default toDir=path vfs-fileset dir=path include name=*.b?t/ /vfs-fileset /vfs-copy vfs-copy manager=special toDir=path vfs-fileset dir=pathXX include name=*.b?t/ /vfs-fileset /vfs-copy the manager=default could be the default and thus need not to be specified. If needet, the manager= reference could be added to the vfs-fileset too, but isnt it possible to access the object of the parent element in ant? vfs-fileset runs in the context of vfs-copy - there should be a way to access it. Also the vfs-manager could listen to the project finish an close the manager. -- Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vfs] VfsTask
vfs-manager id=default class=StandardFileSystemManager vfs-option but this is to specify and implement later ../ /vfs-manager vfs-manager id=special class=MyHyperVFSFileSystemManager / vfs-copy manager=default toDir=path vfs-fileset dir=path include name=*.b?t/ /vfs-fileset /vfs-copy vfs-copy manager=special toDir=path vfs-fileset dir=pathXX include name=*.b?t/ /vfs-fileset /vfs-copy Yes, looks very good. vfs-manager is here a data-type that sets a reference to itself to project project.addReference(String name, Object value); Then when vfs-copy sees manager attribute it asks an object from project that is registered with the given refid. And expects it to be vfs-manager datatype. The same task can also accept that type nested inside, in which case the type definition is local to the task. - rami - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
