DO NOT REPLY [Bug 35258] - [collections] TreeList Collections.binarySearch problem - general remove() after previous() problem
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35258. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35258 --- Additional Comments From [EMAIL PROTECTED] 2005-12-09 11:06 --- Why don't you try passing in a Random instance to the Collections.shuffle() method? You could seed it with a known value that fails every time. You could do: Collections.shuffle( noes, new Random( 1 ) ); That way, it would be more deterministic. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VFS] Contributions to the project
On Thu, 08 Dec 2005 19:54:13 +0100, Mario Ivankovits [EMAIL PROTECTED] said: 3) File Actions There is already a conribution which achieves this. Attached to http://issues.apache.org/bugzilla/show_bug.cgi?id=36047 (includes SVN access) it waits to have VFS release 1.0 out. Such an interface will be used to e.g. commit/update a file, retrieve a thumbnail or exif data (in case of an image format wich allows it) I've had a look at it, but i didn't like the fact that retrieving the services is tied up to the java Class (i.e.: FileService getService(Class serviceClass) ). The reason i don't like that approach, is that one of the things i'm planning to do, is a 'remote VFS' provider. That provider would not only send the information about the files, but also provide the list of actions that can be executed on each file, and allow the client VFS to remotely invoke those actions. In order to do that with that API, it would require the actually classes for all services to be in the client's classpath, which is a very bad approach. My idea is to have the base API to provide enough information to cover most basic use cases, and off course specific implementations of the service can provide richer API that the user of the API can make use. Yours truly - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VFS] Contributions to the project
On Fri, 09 Dec 2005 11:12:44 +, Yannick Menager [EMAIL PROTECTED] said: On Thu, 08 Dec 2005 19:54:13 +0100, Mario Ivankovits [EMAIL PROTECTED] said: 3) File Actions There is already a conribution which achieves this. Attached to http://issues.apache.org/bugzilla/show_bug.cgi?id=36047 (includes SVN access) it waits to have VFS release 1.0 out. Such an interface will be used to e.g. commit/update a file, retrieve a thumbnail or exif data (in case of an image format wich allows it) I've had a look at it, but i didn't like the fact that retrieving the services is tied up to the java Class (i.e.: FileService getService(Class serviceClass) ). The reason i don't like that approach, is that one of the things i'm planning to do, is a 'remote VFS' provider. That provider would not only send the information about the files, but also provide the list of actions that can be executed on each file, and allow the client VFS to remotely invoke those actions. In order to do that with that API, it would require the actually classes for all services to be in the client's classpath, which is a very bad approach. My idea is to have the base API to provide enough information to cover most basic use cases, and off course specific implementations of the service can provide richer API that the user of the API can make use. Ok, i've put in an initial draft on my svn server at http://svn.jguild.com/vfs-contrib/src/org/apache/commons/vfs/action/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 16525] - [beanutils] BeanUtils.setProperty is over-zealous at converting types
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=16525. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=16525 --- Additional Comments From [EMAIL PROTECTED] 2005-12-09 13:08 --- Created an attachment (id=17188) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=17188action=view) Shows that BeanUtils.setProperty converts arrays even though they are assignment compatible with java.lang.Object BeanUtils.setProperty seems to be overzealous when it comes to converting arrays when used with mapped properties. It doesn't seem to realize that type java.lang.Object for the mapped getter and setter is assignment compatible with Arrays (specifically String[]). Instead it converts a String[] to a String (with only the value of the first element), discarding the rest of the array. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VFS] File Type
There is one thing i was wondering if there was any possibility of changing in the VFS API. the FileType.IMAGINARY Now, let's see.. we have: - A FOLDER, that has childrens, but no data - A FILE, that has no childrens, but has data. The other alternatives would be something that has no childrens or data, which i can't think of any valid usecase for it, or the much more likely of a file that has *both* childrens and data (tons of usecases for that one) Why not instead use something like FileType.HYBRID, FileType.BOTH, FileType.VIRTUAL, FileType.OTHER Anything but 'Imaginary' I know it's a bit late in the day, but i really think it would be worth changing that for the 1.0 release. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VFS] File Type
Hi Yannick! the FileType.IMAGINARY - A FOLDER, that has childrens, but no data - A FILE, that has no childrens, but has data. I dont understand whats that bad with imaginary - a file/foler that is non existent. Once we cross the bridge where we have to deal with files that might have children or folders with content we can introduce new FileTypes. Or - do not reflect this using file types at all, but introduce Capabilities on fileObject level too. --- Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VFS] Contributions to the project
Hi Yannick, 3) File Actions and allow the client VFS to remotely invoke those actions. In order to do that with that API, it would require the actually classes for all services to be in the client's classpath, which is a very bad approach. I am definitely against having generic interfaces. If I write programs I would like to compile my stuff and can be sure to have no syntax error in it. Having interfaces like setAttribute(String key, String value) is against my wishes. If the value provided is syntactical correct (e.g. setAttribute(port, abd)) cant be checked during compile time, while SvnCheckout.setPort(123) can be checked. I am sure we find ways to call those services remotely without having all the classes on the client. e.g by providing a RemoteService object which uses reflection on the server side to configure the services then. The same idea I implemented in the *FileSystemConfigBuilder stuff. If you e.g. have to process settings from an xml-file you can use the DelegatingFileSystemObjectBuilder which uses (for sure rather sophisticated) reflection to call the type safe implementations the. --- Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[configuration] Build fails under Maven 1.1-beta2
Hi all, Under maven 1-1.-beta2 there seems to be an issue with the maven- tasks-plugin. I upgraded to 1.2.0 from 1.1.0 to see if that resolved it, but no joy. I actually think the issue is in the project.xml of the tasks plugin. At any rate, if I comment it out, everything is fine. Also, since we are at RC stage, can I bump the versions of the maven- tasks-plugin and maven-findbugs-plugin (should be 1.0!) Eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [configuration] Build fails under Maven 1.1-beta2
Hi Eric, I'll take a look at your problems. Can you send us your errors ? Arnaud On 12/9/05, Eric Pugh [EMAIL PROTECTED] wrote: Hi all, Under maven 1-1.-beta2 there seems to be an issue with the maven- tasks-plugin. I upgraded to 1.2.0 from 1.1.0 to see if that resolved it, but no joy. I actually think the issue is in the project.xml of the tasks plugin. At any rate, if I comment it out, everything is fine. Also, since we are at RC stage, can I bump the versions of the maven- tasks-plugin and maven-findbugs-plugin (should be 1.0!) Eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[configuration] findbugs and JDK1.3
One more thing... I noticed that findbugs is commented out: !-- Commented out, does not run on JDK 1.3 reportmaven-findbugs-plugin/report -- According to the homepage for Findbugs, while yes, it does require JDK1.4 to run, it should analyze 1.3 code. When we compile for 1.3, does that mean you are using a 1.3 JDK as well? RC is looking good, Eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [configuration] findbugs and JDK1.3
Eric Pugh schrieb: One more thing... I noticed that findbugs is commented out: !-- Commented out, does not run on JDK 1.3 reportmaven-findbugs-plugin/report -- According to the homepage for Findbugs, while yes, it does require JDK1.4 to run, it should analyze 1.3 code. When we compile for 1.3, does that mean you are using a 1.3 JDK as well? RC is looking good, Eric Hi Eric, I indeed built the distributions with JDK 1.3 to ensure full compatibility. (It would also be possible to run the build on JDK 1.4 and set the maven.compiler.executable property to point to a JDK 1.3 javac, but then the manifest file will have an incorrect version number; at least if no additional steps are performed.) Also if 1.3 is our minimum required JDK version, I wanted to make sure that building on this JDK is possible without major problems. Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 37844] - [cli] Error in website - Usage Scenarios
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=37844. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=37844 [EMAIL PROTECTED] changed: What|Removed |Added Summary|Error in website - Usage|[cli] Error in website - |Scenarios |Usage Scenarios -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VFS] Contributions to the project
My idea was not that it should be exclusively based on the 'loose' model, but rather that the loose model would be provided by all interfaces, in addition to the constrained one. So SvnCheckout could have it's port set by using setAttribute(port, 123) (which would be provided by the top interface), or by using setPort(123) (which would be provided by the SvnCheckout interface). Rather sofisticated reflection or bytecode engineering is a problem the moment it requires permission that might not be allowed in certain situations (Applets). HHmmm... but now that i think about it, we can have 2 interfaces, one which is the parent one for all actions/services, and another one for services that expose a 'loose' interface... What do you think ? On Fri, 09 Dec 2005 14:41:00 +0100, Mario Ivankovits [EMAIL PROTECTED] said: I am definitely against having generic interfaces. If I write programs I would like to compile my stuff and can be sure to have no syntax error in it. Having interfaces like setAttribute(String key, String value) is against my wishes. If the value provided is syntactical correct (e.g. setAttribute(port, abd)) cant be checked during compile time, while SvnCheckout.setPort(123) can be checked. I am sure we find ways to call those services remotely without having all the classes on the client. e.g by providing a RemoteService object which uses reflection on the server side to configure the services then. The same idea I implemented in the *FileSystemConfigBuilder stuff. If you e.g. have to process settings from an xml-file you can use the DelegatingFileSystemObjectBuilder which uses (for sure rather sophisticated) reflection to call the type safe implementations the. --- Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VFS] File Type
I do think the type makes some sense, however in system API, i always felt it is preferable to use more technical terms, from which the meaning can be more completely understood just from the name. And of all the potential terms i can think of, I just feel that Imaginary is one of the least appropriate ones. Just my personal opinion... On Fri, 09 Dec 2005 14:32:35 +0100, Mario Ivankovits [EMAIL PROTECTED] said: Hi Yannick! the FileType.IMAGINARY - A FOLDER, that has childrens, but no data - A FILE, that has no childrens, but has data. I dont understand whats that bad with imaginary - a file/foler that is non existent. Once we cross the bridge where we have to deal with files that might have children or folders with content we can introduce new FileTypes. Or - do not reflect this using file types at all, but introduce Capabilities on fileObject level too. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VFS] Contributions to the project
Been thinking about this, and you're absolutely right... My preference
also has always been for the constrained approach, but my mind was a bit
stuck on my 'remote vfs' usecase *sheepish grin*
Actually nevermind what i said about having an optional loose API, but i
think i have a much better idea:
Require services to provide the meta-data information that could then be
transfered and exposed to the client. Using either anotations on 1.5, or
for example an xml file on older systems.
i.e.:
class SvnCheckout {
/**
* @@vfs.service-argument description='bla bla' optional='true'
*/
public void setPort( int port ) {
...
}
}
and of course provide API to easily access that information
independently of it using 1.5 or a fallback method.
On Fri, 09 Dec 2005 14:41:00 +0100, Mario Ivankovits [EMAIL PROTECTED]
said:
Hi Yannick,
3) File Actions
and allow the client VFS to
remotely invoke those actions. In order to do that with that API, it
would require the actually classes for all services to be in the
client's classpath, which is a very bad approach.
I am definitely against having generic interfaces. If I write programs I
would like to compile my stuff and can be sure to have no syntax error
in it.
Having interfaces like
setAttribute(String key, String value)
is against my wishes.
If the value provided is syntactical correct (e.g. setAttribute(port,
abd)) cant be checked during compile time, while
SvnCheckout.setPort(123) can be checked.
I am sure we find ways to call those services remotely without having
all the classes on the client. e.g by providing a RemoteService object
which uses reflection on the server side to configure the services then.
The same idea I implemented in the *FileSystemConfigBuilder stuff. If
you e.g. have to process settings from an xml-file you can use the
DelegatingFileSystemObjectBuilder which uses (for sure rather
sophisticated) reflection to call the type safe implementations the.
---
Mario
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VFS] Contributions to the project
Ok, i've updated my draft code at
https://svn.jguild.com/vfs-contrib/src/org/apache/commons/vfs/action
So for example:
FileObject file;
ActionManager actionManager = ...
Action[] actions = actionManager.getActions(file);
SvnCheckout checkoutAction = (SvnCheckout) actionManager.getAction(file,
Class SvnCheckout.class );
-- With SvnCheckout classes available:
checkoutAction.setRevision(55);
checkoutAction.execute();
-- Or without
ActionMetadata actionMetadata = new ActionMetadata( action )
Argument revisionArg = ... gets the right argument out of actionMetadata
...
revisionArg.setValue( new Integer(55) );
action.execute();
On Fri, 09 Dec 2005 15:23:16 +, Yannick Menager
[EMAIL PROTECTED] said:
Been thinking about this, and you're absolutely right... My preference
also has always been for the constrained approach, but my mind was a bit
stuck on my 'remote vfs' usecase *sheepish grin*
Actually nevermind what i said about having an optional loose API, but i
think i have a much better idea:
Require services to provide the meta-data information that could then be
transfered and exposed to the client. Using either anotations on 1.5, or
for example an xml file on older systems.
i.e.:
class SvnCheckout {
/**
* @@vfs.service-argument description='bla bla' optional='true'
*/
public void setPort( int port ) {
...
}
}
and of course provide API to easily access that information
independently of it using 1.5 or a fallback method.
On Fri, 09 Dec 2005 14:41:00 +0100, Mario Ivankovits [EMAIL PROTECTED]
said:
Hi Yannick,
3) File Actions
and allow the client VFS to
remotely invoke those actions. In order to do that with that API, it
would require the actually classes for all services to be in the
client's classpath, which is a very bad approach.
I am definitely against having generic interfaces. If I write programs I
would like to compile my stuff and can be sure to have no syntax error
in it.
Having interfaces like
setAttribute(String key, String value)
is against my wishes.
If the value provided is syntactical correct (e.g. setAttribute(port,
abd)) cant be checked during compile time, while
SvnCheckout.setPort(123) can be checked.
I am sure we find ways to call those services remotely without having
all the classes on the client. e.g by providing a RemoteService object
which uses reflection on the server side to configure the services then.
The same idea I implemented in the *FileSystemConfigBuilder stuff. If
you e.g. have to process settings from an xml-file you can use the
DelegatingFileSystemObjectBuilder which uses (for sure rather
sophisticated) reflection to call the type safe implementations the.
---
Mario
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[VFS] setting read-only, hidden, etc
I'm making a prototype of File to VFS adaptor (http://svn.jguild.com/vfs-contrib/src/org/apache/commons/vfs/util/jio/), which made me realise that there is no support for setting a bunch of stuff like read-only, hidden, etc, that a File does... If there is getters for that information, there should be setters too... So i'd propose to 1) Add setters for those operations 2) Deprecate or remove the getters, add a new Service/Action/Operation that allow to get/set that information. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VFS] File metadata
One thought shouldn't the file metadata information (i.e. FileContent.getAttributes() ), also be constrained ? We could then also use that API to expose and allow to view/modify things like security information (owner, group, permission), svn log history, etc. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VFS] setting read-only, hidden, etc
Hi! I'm making a prototype of File to VFS adaptor (http://svn.jguild.com/vfs-contrib/src/org/apache/commons/vfs/util/jio/), which made me realise that there is no support for setting a bunch of stuff like read-only, hidden, etc, that a File does... These limitation are simply due to the restrictions of the most filesystem libraries, they simply do not provide such a mechanism, even for local files we have to go the native way to change those attributes. 2) Deprecate or remove the getters, add a new Service/Action/Operation that allow to get/set that information. When we deprecate those methods is another story, but to figure out a common way how to modify attributes and security constraints will be the first challange. Implementing such a stuff as Service/Action/Operation at a first step will be great. We need to find a way to express the various security systems linux/windows using one api. I am currently out of time to think about in detail, but maybe something like file owner (with an set of permissions for windows/linux) file users (other users with special rights - with an set of permissions representable only for windows) file usergroups (n groups in windows. only two: group/other in linux) --- Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VFS] File metadata
Hi! One thought shouldn't the file metadata information (i.e. FileContent.getAttributes() ), also be constrained ? These attributes are mainly to get attributes stored e.g. in the jar manifest. We cant constrain them as we dont know which might exists We could then also use that API to expose and allow to view/modify things like security information (owner, group, permission), svn log history, etc. As I said, I think the separate service/... framework would be the best way. --- Mario smime.p7s Description: S/MIME Cryptographic Signature
Re: [VFS] Contributions to the project
Hi! Require services to provide the meta-data information that could then be transfered and exposed to the client. Using either anotations on 1.5, or for example an xml file on older systems. Hmmm, what if we use a simple properties file to describe them. e.g. SvnCheckout.properties port=The port used for communication host=The host then we can localize them too. We can have separate files or one per service group. How to mark a parameter optional (or not) is a good point. Today I would use annotations for it (e.g. @NotNull) but we have to stick with jdk 1.3 for a while. For now we can put then into another properties file too and provide the suggested api to query it, so we can change this to annotations it we are able to upgrade. --- Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 37849] - [resources] Messages should implement Map
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=37849. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=37849 --- Additional Comments From [EMAIL PROTECTED] 2005-12-09 19:08 --- (In reply to comment #2) I'm against this proposal for two reasons: * the main reason is I don't see how it is possible - we don't just retrieve i18n messages based on a key - the Locale is needed as well. A strategy that could make this work would be to have a method signature like this on the factory: Map getMessages(Locale locale) that would return a map already localized for the specified locale. * secondly Map provides too much access - not only retrieving values but also modifying and clearing the whole lot. Resources provides read-only access to whatever it represents (e.g. properties files) and shouldn't either provide or appear to provide a facility to modify them. There's nothing stopping the returned implementation from throwing UnsupportedOperationException on all the methods that modify things (like the standard UnmodifiableMap wrapper does). Maps would be especially handy in the context of EL expressions used to pull individual messages by key out of the Messages object, since EL already knows how to deal with maps. This is the strategy that JSF uses, for example. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 37849] - [resources] Messages should implement Map
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=37849. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=37849 --- Additional Comments From [EMAIL PROTECTED] 2005-12-09 19:10 --- I should mention that Shale has a utility class (org.apache.shale.util.LoadBundle) in the core library that does something similar to this. It only wraps resource bundles, but the Map implementation could be lifted out and generalized inside Resources if this idea were to be accepted. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VFS] setting read-only, hidden, etc
Hi Andy! The reality does remain however that some level of native interface will be required for many of these, but that is an implementation detail that matters for each specific file system and should not prevent adding a support framework to VFS. While I haven't looked at what the underlying library support, it occurs to me that a CIFS system might be the ideal candidate to use for developing the ACL test case as it should be doable with no native code. Yes, I thought to start with CIFS too. But didnt you think it might be possible to map the simple unix like permissions into a ACL like structure? I think the ACL is the way to go, especially as there already exists implementatins for linux too. --- Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VFS] setting read-only, hidden, etc
It could be mapped, but would have a lot of additional constraints. For example with an ACL, you can generally assign any permission to any user or group. With Unix-like - you only get one definable group, one fixed group (other), and one user. So I guess mapping it would be easy, but I would think in that case we would want to have discoverable capabilities for determining if more than one user, group etc can be added so that programmatically such things are predictable. Mario Ivankovits wrote: Hi Andy! The reality does remain however that some level of native interface will be required for many of these, but that is an implementation detail that matters for each specific file system and should not prevent adding a support framework to VFS. While I haven't looked at what the underlying library support, it occurs to me that a CIFS system might be the ideal candidate to use for developing the ACL test case as it should be doable with no native code. Yes, I thought to start with CIFS too. But didnt you think it might be possible to map the simple unix like permissions into a ACL like structure? I think the ACL is the way to go, especially as there already exists implementatins for linux too. --- Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VFS] setting read-only, hidden, etc
Hi Andy! So I guess mapping it would be easy, but I would think in that case we would want to have discoverable capabilities for determining if more than one user, group etc can be added so that programmatically such things are predictable. Yes, thats fair. --- Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VFS] setting read-only, hidden, etc
By the way - I haven't said this in a while - VFS absolutely ROCKS! Congratulations (a bit late though) on getting out of the sandbox and closing on a final release. Mario Ivankovits wrote: Hi Andy! So I guess mapping it would be easy, but I would think in that case we would want to have discoverable capabilities for determining if more than one user, group etc can be added so that programmatically such things are predictable. Yes, thats fair. --- Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VFS] Contributions to the project
Mario Ivankovits wrote: Hi! Require services to provide the meta-data information that could then be transfered and exposed to the client. Using either anotations on 1.5, or for example an xml file on older systems. Hmmm, what if we use a simple properties file to describe them. e.g. SvnCheckout.properties port=The port used for communication host=The host then we can localize them too. We can have separate files or one per service group. How to mark a parameter optional (or not) is a good point. Yup, because of that, and other kind of information that will be needed ( i.e. a description of what the action does ), i think an xml would be a better match i.e. action-metadata descriptionThis action allows to checkout the file on the SVN to the local filesystem/description argument name='revision' optional='true' description='The revision that should be checked out'/ argument name='targetDir' optional='false' description='The directory to which the code should be checked out'/ /action-metadata Today I would use annotations for it (e.g. @NotNull) but we have to stick with jdk 1.3 for a while. For now we can put then into another properties file too and provide the suggested api to query it, so we can change this to annotations it we are able to upgrade. No reason why not have both :-) If the code is running in a 1.5 vm, check for annotations, if it's not, or no annotations were found, check for a metadata xml. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VFS] File metadata
Mario Ivankovits wrote: Hi! One thought shouldn't the file metadata information (i.e. FileContent.getAttributes() ), also be constrained ? These attributes are mainly to get attributes stored e.g. in the jar manifest. We cant constrain them as we dont know which might exists We could then also use that API to expose and allow to view/modify things like security information (owner, group, permission), svn log history, etc. As I said, I think the separate service/... framework would be the best way. So you mean use the Service API both to provide extra information in addition to Operations/Actions ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VFS] File metadata
Mario Ivankovits wrote: Hi! One thought shouldn't the file metadata information (i.e. FileContent.getAttributes() ), also be constrained ? These attributes are mainly to get attributes stored e.g. in the jar manifest. We cant constrain them as we dont know which might exists Oh ! I thought they were for metadata attributes, like for example the SVN attributes... I think it might be better to clarify that in the javadocs :-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [email] Using Templates for Mail Message
There certainly is a place for this type of library, whether or not in belongs in commons-email. Velocity has VelocityStruts, and VelocityViewServlet, what is being described is quite analogous. It has been implemented multiple times in usually over-simplified ways, and it would be great to standardize a more complete implementation. The Jakarta libraries are powerful, and I was able to create a quite useful emailing/templating/email-control package by leveraging the following libraries: commons-mail commons-configuration Velocity It allows developers to specify email templates and for an admin/end user to control addressing emailing options. I'd be willing to donate this to open source. It's not a heck of a lot of code, but enough that you don't want to rewrite. Let me know which project is most suited and Ill look into submitting this, otherwise sourceforge/java.net would work as well. There are two config files (loaded by commons-configuration), along with a sample template. See below for a idea of how they work. Let me know if there is interest. Joel email.properties - for end user email control email_templates.properties - for developer template specifications. Hello.txt - Velocity template. # email.properties file # # Default from, reply to, and bounce-back addresses. # [EMAIL PROTECTED] # [EMAIL PROTECTED] # # Add email recipients (all emails). # [EMAIL PROTECTED] # [EMAIL PROTECTED] # [EMAIL PROTECTED] # # Turns on/off all emails # email.send=true # # Addressing/Control of specific emails # [EMAIL PROTECTED] # [EMAIL PROTECTED] # [EMAIL PROTECTED] # email.message.hello_world.send=false # # Turns on/off JNDI lookup # email.use.jndi=true # # JNDI lookup name # email.use.jndi.path=java:comp/env/mail/MailSetup # # Change hostname # mail.smtp.host=localhost # mail.smtp.port=25000 # mail.smtp.user=user # mail.smtp.password=password # # TESTING OPTIONS # Sends emails to this address ONLY. # [EMAIL PROTECTED] # # Doesn't send any emails, but forwards to this address ONLY. # Useful for testing whether email was addressed correctly. # [EMAIL PROTECTED] # END TESTING # email_templates.properties # # Template Emails (Velocity Macro emails) # # These files should refer to files on the classpath. # email.message.hello_world.file.vm.text/html=on/classpath/hello.html # email.message.hello_world.file.vm.text/plain=hello.txt !-- Example template file -- #set($email.Subject = Your Hello World Email) html body pHello World/p /body /html -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The problem I would see with having this in email, even as a utility, is that it isn't e-mail specific. While your use case deals with the file system and (presumably?) a bean-type substitution (e.g., @@LOGIN@@, user.getLogin()), there is a broader scope of retrieval of information from other sources (database, property files, etc). The use cases (and dependencies to match) could get well out of control for a simple project aimed at making e-mail easier to use. Perhaps a utility class for your use case could simply deal with String's replace/replaceAll? Brian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] [jci][openpgp][exec] Javapolis speech on Commons
Can anyone comment on what [jci] would be useful for? The current website has no examples, and there is no PROPOSAL.txt (why???) so I'm a little in the dark. Also, [openpgp] and [exec] don't have websites yet. Since I'll be mentioning them on Monday, it would be nice if they did! Stephen Henri Yandell wrote: Good luck with your talk :) Interested in hearing how it goes. Hen On 12/6/05, Stephen Colebourne [EMAIL PROTECTED] wrote: I will be giving a 15 minute speech on Commons at Javapolis, I titled it 'new and upcoming at commons' - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] [jci][openpgp][exec] Javapolis speech on Commons
I'll try and get to the latter ones by then. Stephen Colebourne wrote: Can anyone comment on what [jci] would be useful for? The current website has no examples, and there is no PROPOSAL.txt (why???) so I'm a little in the dark. Also, [openpgp] and [exec] don't have websites yet. Since I'll be mentioning them on Monday, it would be nice if they did! Stephen Henri Yandell wrote: Good luck with your talk :) Interested in hearing how it goes. Hen On 12/6/05, Stephen Colebourne [EMAIL PROTECTED] wrote: I will be giving a 15 minute speech on Commons at Javapolis, I titled it 'new and upcoming at commons' - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] [jci][openpgp][exec] Javapolis speech on Commons
On 12/9/05, Brett Porter [EMAIL PROTECTED] wrote: I'll try and get to the latter ones by then. snip/ Exec has been published [1] (as you must be well aware, no doubt), it just needs a blurb (I recently added it to the menu bar on the left, so notice the sandbox entity in the About Us menu has Exec listed). Were you planning on providing a m102 friendly POM for [openpgp]? Would be quite useful, IMO (in addition to the m2 one, not instead of). -Rahul [1] http://jakarta.apache.org/commons/sandbox/exec/ Stephen Colebourne wrote: Can anyone comment on what [jci] would be useful for? The current website has no examples, and there is no PROPOSAL.txt (why???) so I'm a little in the dark. Also, [openpgp] and [exec] don't have websites yet. Since I'll be mentioning them on Monday, it would be nice if they did! Stephen Henri Yandell wrote: Good luck with your talk :) Interested in hearing how it goes. Hen On 12/6/05, Stephen Colebourne [EMAIL PROTECTED] wrote: I will be giving a 15 minute speech on Commons at Javapolis, I titled it 'new and upcoming at commons' - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] [jci][openpgp][exec] Javapolis speech on Commons
Rahul Akolkar wrote: Exec has been published [1] (as you must be well aware, no doubt), it just needs a blurb (I recently added it to the menu bar on the left, so notice the sandbox entity in the About Us menu has Exec listed). It needs adding to http://jakarta.apache.org/commons/sandbox/index.html as thats where I looked :-) Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] [jci][openpgp][exec] Javapolis speech on Commons
On 12/9/05, Stephen Colebourne [EMAIL PROTECTED] wrote: Rahul Akolkar wrote: Exec has been published [1] (as you must be well aware, no doubt), it just needs a blurb (I recently added it to the menu bar on the left, so notice the sandbox entity in the About Us menu has Exec listed). It needs adding to http://jakarta.apache.org/commons/sandbox/index.html as thats where I looked :-) snip/ Yup, the missing blurb ;-) I think Brett's on it. And bravo, glad that you're talking about the new components. -Rahul Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
