Re: [vfs] parsing uri

As you might have seen I implemented the plugin-resolve-stuff. Now we could extend VFS by simply drop a jar into the classpath and if we find a /META-INF/vfs-plugins.xml it would be added. That way we could keep the VFS core slim and could provide extension jars to allow whatever we can

Re: [vfs] parsing uri

And sometimes we just find some spare minutes and would like to experiment a little bit I have absolutely nothing against experimenting and coding all kinds of weird and useful things for your own purposes. I was just talking about what should be included into vfs. even if the result is

Re: [vfs] parsing uri

Your asumption about the used servers is correct. Now why uml or vmware: It is a pain to setup all this stuff and keep it in sync with any junit changes. With uml or vmware I can provide a image one simply can drop into its box and startup the tests. So no security problem, just to simplify

Re: [vfs] JDBC FileSystem: planning an implementation

Please do not take my continued questioning as a sign of not liking the vfs - jdbc provider. I just like to question because I still don't completely understand. E.g. if it is not possible to setup a ftp/ssh server but already have a working database connection (e.g. in webshop environments)

Re: [vfs] parsing uri

I glanced the tests you have in place for uris and naming and they seem extensive. I am not going to test this extensively. But the case that brought this issue up was like the following I called FileObject resolveFile(File baseFile, String name) on FileSystemManager and the baseFile has path

Re: [vfs] JDBC FileSystem: planning an implementation

Hi Mario Wouter, Could you still clarify what is the purpose of making a relational database work as filesystem. This is just for curiosity (and maybe good for docs). I had the idea that someone might want to attach more metadata to files through attributes. Another reason that came to my mind

[vfs] JDBC FileSystem: planning an implementation

-storing files into databases, including some metadata (the easy part) I would see the mapping from relational model to filesystem: relation (table) = filesystem (defines a set of files that share the same set of attributes). tuple (row) = file that has the content value and attribute values

Re: [vfs] parsing uri

URI spec dudes talk about canonical form of the URI. This is left for the schema to define. Now if vfs is in control of the uri's that come in and go out then it would be possible to canonicalize the URI when it enters the core areas of vfs that is not provider (schema) specific. Cache I believe

Re: [vfs] parsing uri

Again quoting the RFC: For original character sequences that contain non-ASCII characters, however, the situation is more difficult. Internet protocols that transmit octet sequences intended to represent character sequences are expected to provide some way of identifying the charset used, if

Re: [vfs] parsing uri

I wrote the previous email too quickly so there are many errors in details. So please read it without too much attention to the details. I quess those uris with non us characters get always sent in some encoding. It would work nicely if it could be us-ascii But the interpretation problem is just

Re: [vfs] parsing uri

The File-URI codec on unix encodes \foo\bar -- %5Cfoo%5Cbar This is to be interpreted as file or dir named \foo\bar If you send this uri to jvm on windows you get new File(new URI(uriStr)) which is interpreted as file or dir bar under dir foo which is under root. So it seems that %5C is not

Re: [vfs] parsing uri

[EMAIL PROTECTED] wrote: I'm unsure that the URI specs intend to distinguish a string from it's encoded form for the purposes of naming. I believe they are to be interpreted equivalently, and that the encoding exists only to permit uncorrupted transmission of forbidden characters. Quote

Re: [vfs] parsing uri

btw. you catched a vespiary - usign the '%' as valid filename character turns out to be a problem through all archive like filesystem providers (tar, zip, ..). Also the FileObject.getName().getURI() didnt correctly encode the path i.e. one cant use its result to resolve a file again. I have to

Re: [vfs] parsing uri

Rami 12 points. I'm honored. - Rami - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

Re: [vfs] parsing uri

What does it does not work mean? That is, what is an example failure case? Good question. Because it does work :) All I can say to my defense is that my library management is a mess! Therefore I decided to make the simplest possible class for testing how file.toURI().toString() It encodes

Re: [vfs] parsing uri

Slight correction new File(new URI( (new File($%[EMAIL PROTECTED]|\\^[]`$)).toURI().toString() )).getPath() Returns $%[EMAIL PROTECTED]|\\^[]`$ Return value is $%[EMAIL PROTECTED]|\^[]`$ (Only one backslash) - rami - To

[vfs] parsing uri

to public FileObject findLocalFile(final String name) throws FileSystemException { // TODO - tidy this up, no need to turn the name into an absolute URI, // and then straight back again return findFile(null, file: + name, null); } - Rami Ojares Ps. I hope this remark is valid since I

Re: [vfs] parsing uri

Here is my proposal using idea from binkley /** * Finds a local file, from its local name. */ public FileObject findLocalFile(final String name) throws FileSystemException { // TODO - tidy this up, no need to turn the name into an absolute URI, // and then

Re: [vfs] parsing uri

file.toURI().toString() is not the way to go. The reason is simple. It does not work. I don't know why. So I think we should use ParseUtil.encode(..) which does work and decide which characters to include as special ones. I did this and it works (last time I said this I was wrong because a jar did

Re: [VFS] FileSystem close

Hi, I asked about this a little while ago - when you resolve a file for a SFTP url, the SFTP file system maintains the session until the file manager is closed - the solution you propsed (see below) works well, but this will not work if I try to use this in a multi-threaded

Re: [vfs] FileSystemManager construction rethought

the configuration (file) can be passed as path, File, FileObject, DOM or whatever. But it would be nice if FileSystemManager interface would dictate at least some kind of configuration framework so the ant tasks would not have to mention any implementations. - Rami Ojares

Re: [vfs] FileSystemManager construction rethought

Now the configuration (file) can be passed as path, File, FileObject, DOM or whatever. Here the word Now does not mean that now the implementation is ... It means In general it is possible ... - rami - To unsubscribe,

Re: [vfs][all][poll]regular expression library or jdk1.4 as minimum requirement

Daniel wrote: The Java regex syntax is almost a superset of Perl, which is why I don't see the impact of using a Perl engine for JDK 1.3 and java.util.regex for J2SE 1.4 as being major. The expression Rami gave was straight Perl 5.005. jakarta-oro's Perl5Compiler/Perl5Matcher implements

Re: [vfs] FileSystemManager construction rethought

But i have to say i dont like to add all those configuration stuff to the uri - maybe this might be a handy place, but adding e.g. path elements like those in your example might be a real pain. It might be really hard to construct a correct uri. I agree. It was just an example. Now

Re: [vfs] FileSystemManager construction rethought

I tried to replace the parsing of the xml file by commons-digester beanutils but failed as it comes to the point to add those dependencies to vfs. Other people vetoed against it (Too large jars) That is a shame. But isn't it so that we should first come up with a configuration structure

Re: [vfs] FileSystemManager construction rethought

Here are some small changes that I came across when making the changes compilable. I changed configure method to init because there was already private configure(String) method in DefaultFileSystemManager but the existing init method was without arguments. I saw also that there is quite a lot of

[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

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

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

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/

RE: [vfs][all][poll]regular expression library or jdk1.4 as minimum requirement

Again, you use a common syntax, which is translated to the appropriate syntax for the implementation. If some specific feature of the common syntax is not supported in the implementation, then your RE will fail to translate, and should throw some sort of exception. Doesn't seem too

Re: [vfs][all][poll]regular expression library or jdk1.4 as minimum requirement

Since the whole point of the VFS discussion appears to be to support users who aren't using J2SE 1.4, all you have to do is use the syntax subset shared by Perl5 and java.util.regex, which is rather rich and useful. Anyway, that's my take given my understanding of what's being discussed.

Re: [vfs][all][poll]regular expression library or jdk1.4 as minimum requirement

bother and use jdk1.4 as minimum requirement OR write separate package that works exactly like jdk 1.4 on earlier jdk's - Rami Ojares - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

Do attachments go through the mailing lists?

Hi, Trying to send some contributions with zip/jar attachments but they don't seem to go through. Thus I'm testing. - rami - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

Re: Do attachments go through the mailing lists?

Hi, Trying to send some contributions with zip/jar attachments but they don't seem to go through. Thus I'm testing. Answering to my self here. They don't so how can I send posting with jar/zip. I have heard that these kinds of things should be done with bugzilla. But I did not see any

[vfs] FileObject.delete

USING EXTERNAL EDITOR - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

[vfs] FileObject.delete

FileObject.delete() calls FileObject.delete(Selectors.SELECT_SELF) So all the juice is in delete(FileSelector) There we find section SNIP // If the file is a folder, make sure all its children have been deleted if (file.type == FileType.FOLDER file.getChildren().length != 0) { // TODO -

Re: [vfs] FileObject.delete

This will be done AFTER the children are removed, just to check if the folder is really empty before deleting it. I think the indention was to check if any other process created a file within the folder structure - and thus to avoid a error message during recursive delete. Not really.

[vfs] Patch: small documentation add

it works on local filesystem. - Rami Ojares - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

Re: [vfs] FileObject.delete

but one idea could be that delete would return boolean that would tell whether something was deleted or not. - Rami Ojares - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]