[jira] Created: (VFS-104) throw exception if setLastModified did not work
throw exception if setLastModified did not work --- Key: VFS-104 URL: http://issues.apache.org/jira/browse/VFS-104 Project: Commons VFS Issue Type: Improvement Affects Versions: Nightly Builds Reporter: Mario Ivankovits Assigned To: Mario Ivankovits Priority: Minor Fix For: 1.1 Final see summary Keep backward compatibility, add a new doSetLastModifiedTime (doSetLastModTime) with a boolean return code, deprecate the old method -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (VFS-104) throw exception if setLastModified did not work
[ http://issues.apache.org/jira/browse/VFS-104?page=all ] Mario Ivankovits resolved VFS-104. -- Resolution: Fixed throw exception if setLastModified did not work --- Key: VFS-104 URL: http://issues.apache.org/jira/browse/VFS-104 Project: Commons VFS Issue Type: Improvement Affects Versions: Nightly Builds Reporter: Mario Ivankovits Assigned To: Mario Ivankovits Priority: Minor Fix For: 1.1 Final see summary Keep backward compatibility, add a new doSetLastModifiedTime (doSetLastModTime) with a boolean return code, deprecate the old method -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (VFS-104) throw exception if setLastModified did not work
[ http://issues.apache.org/jira/browse/VFS-104?page=all ] Mario Ivankovits closed VFS-104. throw exception if setLastModified did not work --- Key: VFS-104 URL: http://issues.apache.org/jira/browse/VFS-104 Project: Commons VFS Issue Type: Improvement Affects Versions: Nightly Builds Reporter: Mario Ivankovits Assigned To: Mario Ivankovits Priority: Minor Fix For: 1.1 Final see summary Keep backward compatibility, add a new doSetLastModifiedTime (doSetLastModTime) with a boolean return code, deprecate the old method -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE][VFS] release commons-vfs 1.0 based on RC9
Hi Oliver! The ant build succeeded, but in the resulting jar the LICENSE.txt was missing (only NOTICE.txt is copied to META-INF). This has been fixed now. Ciao, Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE][VFS] release commons-vfs 1.0 based on RC10
Hi! Please don't laugh ... I don't know if there ever was a to be released Jakarta project with so many RCs. Be patient with me, I hope in the future we can go more straight forward. Changed: * The ant build succeeded, but in the resulting jar the LICENSE.txt was missing (only NOTICE.txt is copied to META-INF). Please find the RC at http://people.apache.org/~imario/vfs The site can be reviewed at http://people.apache.org/~imario/vfs-1.0/site [ ] +1 I support this release [ ] +0 [ ] -0 [ ] -1 I do not support this release because... Thanks for your time! --- Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (VFS-103) Add support for Local File System reserved directories
[ http://issues.apache.org/jira/browse/VFS-103?page=comments#action_12459758 ] Mario Ivankovits commented on VFS-103: -- I see what you have done and I am pretty sure it works for you. But (IMHO) for a library this approach is not sufficient. You can move these folders to virtually any place AND, as far as I know, they differ from system to system in name depending on the OS language. At least you have to lookup those paths through the registry (on windows). I think there is no way around in using a native library. Add support for Local File System reserved directories -- Key: VFS-103 URL: http://issues.apache.org/jira/browse/VFS-103 Project: Commons VFS Issue Type: New Feature Reporter: Mark Fortner Priority: Minor Attachments: RootFileFactory.java Mac OS X, and Windows has special purpose directories used to organizes specific types of files. In Mac OS X, these directories include Documents, Movies, Pictures, Music; Windows uses My Documents, My Pictures, My Videos and My Music. Provide a consistent approach for getting these directories either as a static factory method, or as individual methods. i.e. something along the lines of public static FileObject getRoot(int rootType) where rootType is a constant that defines which one of the directorires (specified above) that you want. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE][VFS] release commons-vfs 1.0 based on RC10
Hi Jörg! first a question to all: Is it consensus that we use groupId commons-vfs? I just wondered that it was taken for the first release, since we'll switch to org.apache.commons ... It's already changed for the m2 build. I don't know if its worth to relocate the m1. But since we have to switch/relocate a lot of projects, one more does not really matter :) ok. The ant build file is autogenerated using maven ... get-dep-commons-net.jar: [get] Getting: http://www.ibiblio.org/maven/commons-net/jars/commons-net-1.4.1.jar [get] To: /home/joehni/.maven/repository/commons-net/jars/commons-net-1.4.1.jar [get] Getting: This get succeeded!! Unhappily the ant build do not stop now but tries the other possible repositories too. http://people.apache.org/repository/commons-net/jars/commons-net-1.4.1.jar [get] To: /home/joehni/.maven/repository/commons-net/jars/commons-net-1.4.1.jar [get] Error opening connection java.io.FileNotFoundException: http://people.apache.org/repository/commons-net/jars/commons-net-1.4.1.jar [get] Error opening connection java.io.FileNotFoundException: http://people.apache.org/repository/commons-net/jars/commons-net-1.4.1.jar [get] Error opening connection java.io.FileNotFoundException: http://people.apache.org/repository/commons-net/jars/commons-net-1.4.1.jar [get] Can't get http://people.apache.org/repository/commons-net/jars/commons-net-1.4.1.jar to /home/joehni/.maven/repository/commons-net/jars/commons-net-1.4.1.jar == % == Shouldn't this goal now try to download from mirrors.ibiblio.org ? The fun part is, that all those deps are in my Maven 1 repo and the compilation went fine afterwards ;-) Hehe, yea, the ant build downloaded them fine. Although some tests are expected to fail, I have also a failure in the VirtualProviderTestCase that makes me wonder: /snip - --- Testcase: testSetLastModified(org.apache.commons.vfs.test.LastModifiedTests):FAILED expected:1.16656636E12 but was:1.16656623E12 junit.framework.AssertionFailedError: expected:1.16656636E12 but was:1.16656623E12 This makes me wonder too, which filesystem do you use for the test partition? I've tried it on two different machines both running linux with ext3 and it worked. Ciao, Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VFS] File System Roots
Hi Mark! Is there any easy way to get file system roots? Not yet, but this is planned to implement somehow, it would be great if you could open a JIRA ticket with it to not forget it. The same API could/should be used to browse the network with SMB/JCIFS. Also, is there a way to get the equivalents of the Application, Documents, Music, Movies, and Pictures directories on other operating systems? No, and I don't know how to do it without native code. I (personally) would not start developing native code stuff for VFS, though, a rough idea could be to try to find a student for the next Google SoC - if there is one and if no one else would start implementing such stuff. Ciao, Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[news] MyFaces and Spring goes conversational
Hi! Yesterday we had a meeting with Jürgen Höller and it turned out that it would make very sense to integrate our ConversationTag [1] with Spring [2]. The plan is to create a custom Spring scope which uses our ConversationManager. Together with Spring's powerful bean management facility this should lead to a solution which uses less tags and a more natural handling of such conversation beans (in contrast to the current ConversationTag) IMHO with this gap fixed MyFaces and Spring will be the first solution for web applications of any size. You see, I am enthusiastic ;-) Ciao, Mario [1] http://wiki.apache.org/myfaces/ConversationTag [2] http://www.springframework.org/
spring conversation start (@manfred)
Hi! Our plan was to implicit start a conversation as soon as a conversation been will be created through spring. Well, to know which conversationContext we are currently working in (this context is required for multiple window awareness) we have to add a request parameter to every rendered url. This already works pretty well, BUT one has to ensure that the s:startConversation tag is the very first on a page using conversations to allow the system to configure itself appropriate so that the url parameter will be appended. At least, the s:startConversation has to be before e.g. the form stuff. Now, with implicit started conversations this is not that easy any more. I see two solutions: 1) still support the startConversation (in addition to the implicit started one for sure). In fact I'll keep backward compatibility anyway, so this will happen anyway. 2) standardize the backing-bean concept (aka ViewController) Technically spoken: We have a PhaseListener which try to lookup a bean using a name derived from the viewId (like shale's ViewController). If this bean is in conversation scope (or one of its injected properties if you have request scoped backing-beans - like me ;-) ) this would have started a conversation then and the system is fine again. What do you think, would someone see such a standardization as a bad thing? IMHO having such a view controller concept would help much (not only for conversations), e.g. we too can have those prerender methods etc we often would like to have. Ciao, Mario
Re: [news] MyFaces and Spring goes conversational
Hi Matthias! The plan is to create a custom Spring scope which uses our ConversationManager. Together with Spring's powerful bean management facility this should now you are using it ? Well, sometimes good things need time ;-). Yes, now I've seen what it can do for us and I can't wait to give it a go. Ciao, Mario
Re: spring conversation start (@manfred)
Hi Jacob! how's JSF 1.2 coming along btw? What do you mean? As far as I can see JSF 1.2. do not introduce any new (flash or conversation) scope. So (IMHO) our solution works with JSF 1.2 too. If you mean how far our (MyFaces) JSF 1.2 implementation is ... well ... then I have to say there is another team working on it, I don't know. Ciao, Mario
Re: spring conversation start (@manfred)
Hi Craig! One of the architectural approaches that MyFaces developers seem to do pretty often, even when they don't have to, is think of everything as needing a component. Hehe, yes indeed. But I'll try to move away from such approaches, the Spring Conversation integration should no longer need them, even if supported. * Dialog instances can be started programmatically Yes, thats easy. or by looking for a special prefix on the logical outcome returned by an action. Thats something we have to take a look at, though, we don't want to build a full featured dialog framework. Lets go small steps, maybe spring-webflow fits in there, but for sure shale-dialog will have its place here too. * Instead of explicitly modifying the URL /snip ... the dialog identifier (and any other related stuff) is stored as a generic attribute on the view root component. Hey, this one is interesting, I'll give it a try. The latter approach has an advantage in that you can pass any sort of state that is serializable (and therefore get t:saveState out of your pages too! :-), and a disadvantage that it doesn't react well to the redirect-after-post pattern. But it is worth taking a look at. The advantage of the url-parameter method is to allow to easily render links WITHOUT the conversationContext attribute and thus a new conversation context will be started. Maybe a mix of both strategies will be fine ... Thanks alot! Ciao, Mario
Re: spring conversation start (@manfred)
Hi Jacob! I might be biased too from the Seam side, but writing this, even in small steps may grow into a monster :-) Yep, and thats why we have no plans to do so ... and there are numerous implementations out there dealing with it, I don't plan to gather new enemies ;-) I can see committing to only an implicit flash scope (90% of the cases-- and very useful), +1 Ciao, Mario
[VOTE][VFS] release commons-vfs 1.0 based on RC9
Hi! Here we go again - please vote if we can push this RC to a release, finally: Please find the RC at http://people.apache.org/~imario/vfs The site can be reviewed at http://people.apache.org/~imario/vfs-1.0/site [ ] +1 I support this release [ ] +0 [ ] -0 [ ] -1 I do not support this release because... Thanks for your time! --- Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANNOUNCE][VFS] commons-vfs 1.0 RC9
Hi Niall! Release looks good to me. Thanks for looking at it! I've started the vote a suggested. Thanks! Ciao, Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE][VFS] release commons-vfs 1.0 based on RC9
Hi! Shouldn't failing test cases be ignored by default because of the complicated test setup? Hmmm maybe ... we can discuss this for the next release, no? The ant build succeeded, but in the resulting jar the LICENSE.txt was missing (only NOTICE.txt is copied to META-INF). This is odd, its a maven ant generated build file. Do we still need this build file? Can't we drop support for ant build files? IT DRIVES ME CRAZY GETTING THE RELEASE OUT ;-) Sorry, its too late today here . I should go to bed now Ciao, Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: t:document tags and xhtml
Hi Brad! I have seen recommendations on the myfaces wiki that performance of JSF can be improved if t:document tags are used. Will these tags produce valid and well formed xhtml? Or can they be configured to do so? They are just replacements for html's html, head, body. So if a page wasn't well formed without using them, they wont be afterwards. In fact, what happen will be is (if you use these tags in conjunction with StreamingAddResource) that the script tags will be rendered within the bode instead of the head, though, this shouldn't be bad. Did you experience any problems? Ciao, Mario
Re: t:document tags and xhtml
Hi Brad! !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd; html xmlns=http://www.w3.org/1999/xhtml; lang=en xml:lang=en Yep, these attributes are missing, as far as a know. Please open a JIRA at [1]. body id='some id' Is this id required? Ciao, Mario [1] http://issues.apache.org/myfaces
[ANNOUNCE][VFS] commons-vfs 1.0 RC9
Hi! The commons vfs community is happy to announce the availability of a new commons-vfs 1.0 RC. Please find the RC at http://people.apache.org/~imario/vfs The site can be reviewed at http://people.apache.org/~imario/vfs-1.0/site This is the first RC which uses the new naming style. Means: *) the site and jars already have the correct name, we just have to copy them to the right place if the vote for a release passed. The advantage is, that we do not have to rebuild the artifact after the vote. What we've voted on WILL BE the release then. *) in SVN it will show up as vfs-1.0-RC as long as it is in expert opinion (pre release vote) stage. After the vote this directory will be copied to vfs-1.0. I've decided to NOT document the various RC tries in svn as there is not much of use of it, IMHO. I hope everything is fine now so that we can start the vote mid next week. I'd like to have it as Christmas or New-Year present :-) Ciao, Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomahawk and JBoss
Hi! Well I just wanted to know if anyone else had come across issues here. Sorry if it is off-topic. no, it's fine. I am now also interested in *deep* details. Yeah, me too. It would be better to help getting things better instead of ranting around. I am not aware that tomahawk do some strange things with the lifecycle, I am looking forward to learn Ciao, Mario
Re: Tomahawk and JBoss
Hi! Thanks for the links. [1] http://www.jboss.com/index.html?module=bbop=viewtopict=85212 http://www.jboss.com/index.html?module=bbop=viewtopict=85212 [2] http://www.jboss.com/index.html?module=bbop=viewtopict=89231 http://www.jboss.com/index.html?module=bbop=viewtopict=89231 I've answered them. Ciao, Mario
Re: Tomahawk and JBoss
Hi! Honestly, Tomahawk has many very good components, and now ICEfaces also plan to integrate them into ICEfaces program. Hear, hear! Now that Trinidad is very mature, why cannot we integrate the Tomahawk into Trinidad? I like this idea, though, unhappily it might not be that simple. I was told that Trinidad uses a very sophisticated, not that easy made-to-be-compatible object hierarchy. @matze: What are the chances of success for such a wish? Ciao, Mario
Re: [OT] RE: JSF is the answer? I don't think so...
Hey. -) I saw in [1] that usage of Tomahawk components is not recommended - does it pose some (serious) problems? Is it possible at all to use them? How about dojo? [1] http://docs.jboss.com/seam/1.1BETA2/reference/en/html/controls.html We recommend the Ajax4JSF and ADF faces (now Trinidad) tag libraries for use with Seam. We do not recommend the use of the Tomahawk tag library. Its a shame to put such a statement in the documentation without an explanations (or a link to a page) whats bad with tomahawk. I have no clue whats wrong with tomahawk, we use it in our productive environment since a long time. Regarding JBoss Seam: If you do not require stuff like BPEL I'll also point you to our Conversation Tag [1] in tomahawks sandbox. This is a lightweight library which just helps you putting JSF+EJB3 together by introducing a conversation context which can be synchronized with the database (which was the basic idea of Seam too, IMO) You can use it with JSP or Facelets. Ciao, Mario [1] http://wiki.apache.org/myfaces/ConversationTag
Re: [VOTE] Release Commons Betwixt 0.8
Hey! release candidate 4 is available @ http://people.apache.org/~rdonkin/commons-betwixt/ and the site @ http://people.apache.org/~rdonkin/commons-betwixt/site/ gpg: BAD signature from Robert Burrell Donkin (CODE SIGNING KEY) [EMAIL PROTECTED] Any idea why its BAD? Haven't had the time to look at the sig again, though, the rest looked good. So: +1 Ciao, Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (VFS-90) RandomAccessFile backed by a RandomAccessContent instance
[ http://issues.apache.org/jira/browse/VFS-90?page=all ] Mario Ivankovits reopened VFS-90: - Assignee: Mario Ivankovits Thanks! Will give it a try. RandomAccessFile backed by a RandomAccessContent instance - Key: VFS-90 URL: http://issues.apache.org/jira/browse/VFS-90 Project: Commons VFS Issue Type: New Feature Reporter: Elifarley Callado Coelho Assigned To: Mario Ivankovits Priority: Minor Fix For: 1.1 Final Attachments: RACRandomAccessFile.java.bz2, RACRandomAccessFile.java.bz2, src.zip Some existing libraries and applications rely on a RandomAccessFile instance to process its IO tasks. They could be benefited by an adapter class providing a RandomAccessFile view of an arbitrary RandomAccessContent. Example: a database server using a RandomAccessFile instance to access its data from a local file would automatically be able to access it from a remote resource accessed through HTTP. I have already created such a class. I'll try to add it to this issue. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (VFS-90) RandomAccessFile backed by a RandomAccessContent instance
[ http://issues.apache.org/jira/browse/VFS-90?page=all ] Mario Ivankovits updated VFS-90: Fix Version/s: 1.1 Final RandomAccessFile backed by a RandomAccessContent instance - Key: VFS-90 URL: http://issues.apache.org/jira/browse/VFS-90 Project: Commons VFS Issue Type: New Feature Reporter: Elifarley Callado Coelho Assigned To: Mario Ivankovits Priority: Minor Fix For: 1.1 Final Attachments: RACRandomAccessFile.java.bz2, RACRandomAccessFile.java.bz2, src.zip Some existing libraries and applications rely on a RandomAccessFile instance to process its IO tasks. They could be benefited by an adapter class providing a RandomAccessFile view of an arbitrary RandomAccessContent. Example: a database server using a RandomAccessFile instance to access its data from a local file would automatically be able to access it from a remote resource accessed through HTTP. I have already created such a class. I'll try to add it to this issue. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Shale Tiger Annotations with large projects
Hi! Try out the current support by setting context init parameter org.apache.shale.tiger.SCAN_PACKAGES. The value is a comma delimited list of individual JAR filenames (shale-tiger.jar) and package prefixes ( org.apache.shale.foo). As far as I remember I just implemented the package prefix scan as this is the most powerful thing. And yes, this *really* needs to be documented :-). Yea - I know. I'll try to find some spare minutes to submit a patch with a short documentation. @Gary: See [1] to get a quick overview about the configuration (though, ignore the jar part). There you'll also find a tool which helps you to figure out which packages to configure in SCAN_PACKAGES by scanning the classpath, but if you are the developer of an application it shouldn't be that that hard to figure out manually ;-) Ciao, Mario [1] http://issues.apache.org/struts/browse/SHALE-301
[jira] Commented: (TOMAHAWK-819) Re-enabled autogeneration of components code, fixed bug in commandButton/commandLink, adding several valueBindings to components
[ http://issues.apache.org/jira/browse/TOMAHAWK-819?page=comments#action_12457625 ] Mario Ivankovits commented on TOMAHAWK-819: --- Hmmm ... I am not sure what other MyFaces developer think about it, but I think the enableOnUserRole stuff should be replaced by the new org.apache.myfaces.custom.security package [1]? This allows you to do even more complex stuff by simply using the standard enable= and disbaled= properties Have a look at its wiki [2] for more documentation. [1] http://myfaces.apache.org/sandbox/xref/org/apache/myfaces/custom/security/package-summary.html [2] http://wiki.apache.org/myfaces/SecurityContext Re-enabled autogeneration of components code, fixed bug in commandButton/commandLink, adding several valueBindings to components Key: TOMAHAWK-819 URL: http://issues.apache.org/jira/browse/TOMAHAWK-819 Project: MyFaces Tomahawk Issue Type: Improvement Affects Versions: 1.1.5-SNAPSHOT Reporter: Zdenek Sochor Priority: Critical Attachments: build-tools.patch, tomahawk.patch I wanted to expand functionality of role management in components, (TOMAHAWK-489), but i ended in re-enabling autogeneration of code. This should simplify adding of properties and gettter/setter with save/restore state of components INCLUDING fixing several components which didn't take EL values for several properties, for which it should have. Autogeneration is based on old maven build tools. Currently (in patch), autogeneration for TOMAHAWK components is w/o error (at least in components with XML definition), BUT autogenerated Myfaces CORE components breaks several examples (MYFACES-1509) - this can be fixed by reverting of myfaces-api changes after generation. After reverting core, autogenerated Tomahawk classes can be used in final snapshot. I added support for role management of enable/disableOnUserRole: It supports 3 logical functions: - logical AND (user has to be in ALL roles specified) - logical OR (user has to be in ONE of roles specified), this is default mode (and only 1 currently supported in Tomahawk) - logical NOT (user MUST NOT be in any roles specified) If none/attribute not specified or other String used, it defaults to OR function. This extension to functionality takes in account 'disabled' and 'rendered' attributes: - disabled=true take precedence in case of 'enabledOnUserRole' - 'rendered' value is taken in account AFTER evaluating roles Examples: t:commandButton value=value enabledOnUserRole=role1,role2 roleSelectionMode=not disabled=false / [to be enabled, user MUST NOT be in both role1 AND role2] t:commandButton value=value enabledOnUserRole=role1,role2 roleSelectionMode=not disabled=true / [always disabled] t:commandButton value=value visibleOnUserRole=role1,role2,role3 roleSelectionMode=and / [to be visible, user MUST BE in all roles - role1, role2 AND role3] t:commandButton value=value visibleOnUserRole=role1,role2 roleSelectionMode=and rendered=false/ [never rendered] t:commandButton value=value enabledOnUserRole=role1,role2,role3 roleSelectionMode=or / EQUALS t:commandButton value=value enabledOnUserRole=role1,role2,role3/ [to be enabled, user MUST BE in one or more roles from list (role1, role2, role3)] - Hidden bug in commandButton/commandLink - fixed - Note on bug: EnabledOnUserRole is currently never used in HtmlCommandButton (tomahawk 1.1.5 in svn) -- i addded support for it (method isDisabled()) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (TOMAHAWK-819) Re-enabled autogeneration of components code, fixed bug in commandButton/commandLink, adding several valueBindings to components
[
http://issues.apache.org/jira/browse/TOMAHAWK-819?page=comments#action_12457638
]
Mario Ivankovits commented on TOMAHAWK-819:
---
We wont remove them from tomahawk without a sufficient dependency period, no
worry :-)
BUT there is NO method how to issue different modes of authority roles for
different components in the same page (let say to display div tag when user
has not required role).
Hmmm .. I dont understand.
As far as I know you can simply use the rendered=#{} way to determine if a
component should be rendered, based on the security el.
Re-enabled autogeneration of components code, fixed bug in
commandButton/commandLink, adding several valueBindings to components
Key: TOMAHAWK-819
URL: http://issues.apache.org/jira/browse/TOMAHAWK-819
Project: MyFaces Tomahawk
Issue Type: Improvement
Affects Versions: 1.1.5-SNAPSHOT
Reporter: Zdenek Sochor
Priority: Critical
Attachments: build-tools.patch, tomahawk.patch
I wanted to expand functionality of role management in components,
(TOMAHAWK-489), but i ended in re-enabling autogeneration of code.
This should simplify adding of properties and gettter/setter with
save/restore state of components INCLUDING fixing several components which
didn't take EL values for several properties, for which it should have.
Autogeneration is based on old maven build tools.
Currently (in patch), autogeneration for TOMAHAWK components is w/o error (at
least in components with XML definition),
BUT autogenerated Myfaces CORE components breaks several examples
(MYFACES-1509)
- this can be fixed by reverting of myfaces-api changes after generation.
After reverting core, autogenerated Tomahawk classes can be used in final
snapshot.
I added support for role management of enable/disableOnUserRole:
It supports 3 logical functions:
- logical AND (user has to be in ALL roles specified)
- logical OR (user has to be in ONE of roles specified),
this is default mode (and only 1 currently supported in Tomahawk)
- logical NOT (user MUST NOT be in any roles specified)
If none/attribute not specified or other String used, it defaults to OR
function.
This extension to functionality takes in account 'disabled' and 'rendered'
attributes:
- disabled=true take precedence in case of 'enabledOnUserRole'
- 'rendered' value is taken in account AFTER evaluating roles
Examples:
t:commandButton value=value enabledOnUserRole=role1,role2
roleSelectionMode=not disabled=false /
[to be enabled, user MUST NOT be in both role1 AND role2]
t:commandButton value=value enabledOnUserRole=role1,role2
roleSelectionMode=not disabled=true /
[always disabled]
t:commandButton value=value visibleOnUserRole=role1,role2,role3
roleSelectionMode=and /
[to be visible, user MUST BE in all roles - role1, role2 AND role3]
t:commandButton value=value visibleOnUserRole=role1,role2
roleSelectionMode=and rendered=false/
[never rendered]
t:commandButton value=value enabledOnUserRole=role1,role2,role3
roleSelectionMode=or /
EQUALS
t:commandButton value=value enabledOnUserRole=role1,role2,role3/
[to be enabled, user MUST BE in one or more roles from list (role1, role2,
role3)]
-
Hidden bug in commandButton/commandLink - fixed
-
Note on bug:
EnabledOnUserRole is currently never used in HtmlCommandButton (tomahawk
1.1.5 in svn)
-- i addded support for it (method isDisabled())
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (TOMAHAWK-819) Re-enabled autogeneration of components code, fixed bug in commandButton/commandLink, adding several valueBindings to components
[
http://issues.apache.org/jira/browse/TOMAHAWK-819?page=comments#action_12457646
]
Mario Ivankovits commented on TOMAHAWK-819:
---
I admit, I've not used it till today, but you'll be able to provide your own
SecurityContext implementation, wouldn't it allow you to implement your own
needs?
This is qute other approach to the matter than enabled/visibleOnUserRole,
which is based on setting security requirements to single component.
Which roles a component belongs to (if you would like to see it that way) is
configured as expression language within the standard component attributes.
say:
t:div rendered=#{securityContext.ifGranted['rolename']}
The way how to determine if a user is allowed (or not) is routed through the
(or your) security context implementation.
Isn't it sufficient?
Re-enabled autogeneration of components code, fixed bug in
commandButton/commandLink, adding several valueBindings to components
Key: TOMAHAWK-819
URL: http://issues.apache.org/jira/browse/TOMAHAWK-819
Project: MyFaces Tomahawk
Issue Type: Improvement
Affects Versions: 1.1.5-SNAPSHOT
Reporter: Zdenek Sochor
Priority: Critical
Attachments: build-tools.patch, tomahawk.patch
I wanted to expand functionality of role management in components,
(TOMAHAWK-489), but i ended in re-enabling autogeneration of code.
This should simplify adding of properties and gettter/setter with
save/restore state of components INCLUDING fixing several components which
didn't take EL values for several properties, for which it should have.
Autogeneration is based on old maven build tools.
Currently (in patch), autogeneration for TOMAHAWK components is w/o error (at
least in components with XML definition),
BUT autogenerated Myfaces CORE components breaks several examples
(MYFACES-1509)
- this can be fixed by reverting of myfaces-api changes after generation.
After reverting core, autogenerated Tomahawk classes can be used in final
snapshot.
I added support for role management of enable/disableOnUserRole:
It supports 3 logical functions:
- logical AND (user has to be in ALL roles specified)
- logical OR (user has to be in ONE of roles specified),
this is default mode (and only 1 currently supported in Tomahawk)
- logical NOT (user MUST NOT be in any roles specified)
If none/attribute not specified or other String used, it defaults to OR
function.
This extension to functionality takes in account 'disabled' and 'rendered'
attributes:
- disabled=true take precedence in case of 'enabledOnUserRole'
- 'rendered' value is taken in account AFTER evaluating roles
Examples:
t:commandButton value=value enabledOnUserRole=role1,role2
roleSelectionMode=not disabled=false /
[to be enabled, user MUST NOT be in both role1 AND role2]
t:commandButton value=value enabledOnUserRole=role1,role2
roleSelectionMode=not disabled=true /
[always disabled]
t:commandButton value=value visibleOnUserRole=role1,role2,role3
roleSelectionMode=and /
[to be visible, user MUST BE in all roles - role1, role2 AND role3]
t:commandButton value=value visibleOnUserRole=role1,role2
roleSelectionMode=and rendered=false/
[never rendered]
t:commandButton value=value enabledOnUserRole=role1,role2,role3
roleSelectionMode=or /
EQUALS
t:commandButton value=value enabledOnUserRole=role1,role2,role3/
[to be enabled, user MUST BE in one or more roles from list (role1, role2,
role3)]
-
Hidden bug in commandButton/commandLink - fixed
-
Note on bug:
EnabledOnUserRole is currently never used in HtmlCommandButton (tomahawk
1.1.5 in svn)
-- i addded support for it (method isDisabled())
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: StreamingAddResource - How to disable log messages
Hi Dominik! I don’t know how to disable the log entries: I enhanced StreamingAddResource in this area now, not sure if its the best of all solutions I've done two things: * catch any IOException * catch the IllegalStateException when doing sendError both log messages are routed to a different log category now * org.apache.myfaces.component.html.util.StreamingAddResource.SEND In your log4j configuration you should be able to create a special configuration (and ignoring its errors) now. Please give it a try! Ciao, Mario
Re: [VOTE] Release Commons Betwixt 0.8
Hi Robert! release candidate 4 is available @ http://people.apache.org/~rdonkin/commons-betwixt/ and the site @ http://people.apache.org/~rdonkin/commons-betwixt/site/ I've updated my gpg key store using gpg ---refresh-keys and got your now key (at least it looks like). Then I tried to check the sig: # gpg --verify commons-betwixt-0.8-RC4.tar.gz.asc commons-betwixt-0.8-RC4.tar.gz gpg: Signature made So 10 Dez 2006 16:52:55 CET using DSA key ID 7D0D4DED gpg: BAD signature from Robert Burrell Donkin (CODE SIGNING KEY) [EMAIL PROTECTED] Any idea why its BAD? The md5 sum is correct. Ciao, Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE][VFS] release commons-vfs 1.0 based on RC8
Hi Rahul! Ofcourse its upto you, but I'd suggest making the (new) RC available for a few days before calling the vote, especially since there has been quite a gap between the last RC and now. Hehe, for sure, I was just too enthusiastic ;-) On the other hand, more often than not things came up during the vote and not after the announcements :-( Also, same comment as in betwixt vote thread about final versions in artifacts. Please note that I do not think its a good idea to announce RCs on the user list, especially once we all switch to the style above. I agree if we change our artifacts. And I too would like another way how we move forward to a release (at least if my understanding matches with what you mean). Is it like this?: *) create a version tag in svn - the final tag - in this case vfs-1.0 *) switch local version to this tag (or checkout at a different place) *) remove SNAPSHOT from various build files *) create distribution - creates artifact with correct final version *) after the vote has passed we simply can copy these version to their final destination Ciao, Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE][VFS] release commons-vfs 1.0 based on RC8
Hi Niall! 1) Theres a failing test - does it matter? http://tinyurl.com/ymh763 No, I've documented it in the release notes ... though ... hmmm ... maybe I found a way to make it run too 2) The dependencies are mis-leading since they include slide and jcifs which are in the vfs sandbox and not part of the release: http://people.apache.org/~imario/vfs-1.0-RC8/site/dependencies.html patch to correct this (and add urls and optional to the dependencies) here: https://issues.apache.org/jira/browse/VFS-100 Ah, yes, thanks for fixing it. (and also the missing headers) 3) Is it intentional to not include the vfs sandbox code in the source distribution? How do other projects handle it, I'd prefer *not* to add it to the source distribution as the sandbox is a different module (or project) e.g. in the context of m2 which will create its own jar and thus its own -source.jar. The same goes for the examples, I'd remove it even from the current source distribution as its another module. In MyFaces land we have a separate source jar for each distributed binary jar which is a one-to-one mapping to the m2 modules. Ciao, Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE][VFS] release commons-vfs 1.0 based on RC8
Hi Rahul! No, tag remains VFS_1_0_RC9. Hmmm ... I don't understand why we still need the RC tags, if something is dangerous, than that we have artifacts with a release version numbering even if its not the real final release. If we need a pre stage in svn, wouldn't it be sufficient to simply tag it with VFS_1_0_RC (without RC number) Anyway, since its much easier to relase that way, I'll do it for the next RC. Thanks! Ciao, Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (VFS-99) Changes in interface RandomAccessContent.
[ http://issues.apache.org/jira/browse/VFS-99?page=comments#action_12457049 ] Mario Ivankovits commented on VFS-99: - Instead of changing the interface I decided to provide a new base class for all stream based random access content implementations (AbstractRandomAccessContent), that way you no longer have to implement those methods. In case of LocalFile and SMB it is wanted to delegate those methods to their native counterparts. We dont know if they use a more performant implementation (e.g. by using native code) However, thanks for pointing it out! Changes in interface RandomAccessContent. - Key: VFS-99 URL: http://issues.apache.org/jira/browse/VFS-99 Project: Commons VFS Issue Type: Wish Reporter: Elifarley Callado Coelho I think the interface RandomAccessContent should not extend DataOutput nor DataInput; Instead, it could declare the following new methods: 1) int read(byte b[], int off, int len) throws IOException; 2) void write(byte b[], int off, int len) throws IOException; 3) int pread(long pos, byte b[], int off, int len) throws IOException; 4) void pwrite(long pos, byte b[], int off, int len) throws IOException; Instead of changing this interface, a new one could be created (RandomAccessStream, maybe). Benefits: Currently, if a class implements this interface, it has to implement method skipBytes, which is redundant since it already implements method seek. It also has to implement 14 methods related to reading, which is also redundant since they can be expressed in terms of specific calls to more primitive methods such as those proposed above. In other words, I don't think different classes implementing RandomAccessContent (or RandomAccessStream) should all implement methods readShort, readInt, readLong, etc, since all implementations of them will be the same, if they are expressed in terms of calls to read(byte b[], int off, int len). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (VFS-99) Changes in interface RandomAccessContent.
[ http://issues.apache.org/jira/browse/VFS-99?page=all ] Mario Ivankovits resolved VFS-99. - Resolution: Fixed Changes in interface RandomAccessContent. - Key: VFS-99 URL: http://issues.apache.org/jira/browse/VFS-99 Project: Commons VFS Issue Type: Wish Reporter: Elifarley Callado Coelho I think the interface RandomAccessContent should not extend DataOutput nor DataInput; Instead, it could declare the following new methods: 1) int read(byte b[], int off, int len) throws IOException; 2) void write(byte b[], int off, int len) throws IOException; 3) int pread(long pos, byte b[], int off, int len) throws IOException; 4) void pwrite(long pos, byte b[], int off, int len) throws IOException; Instead of changing this interface, a new one could be created (RandomAccessStream, maybe). Benefits: Currently, if a class implements this interface, it has to implement method skipBytes, which is redundant since it already implements method seek. It also has to implement 14 methods related to reading, which is also redundant since they can be expressed in terms of specific calls to more primitive methods such as those proposed above. In other words, I don't think different classes implementing RandomAccessContent (or RandomAccessStream) should all implement methods readShort, readInt, readLong, etc, since all implementations of them will be the same, if they are expressed in terms of calls to read(byte b[], int off, int len). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (VFS-99) Changes in interface RandomAccessContent.
[ http://issues.apache.org/jira/browse/VFS-99?page=all ] Mario Ivankovits closed VFS-99. --- Changes in interface RandomAccessContent. - Key: VFS-99 URL: http://issues.apache.org/jira/browse/VFS-99 Project: Commons VFS Issue Type: Wish Reporter: Elifarley Callado Coelho I think the interface RandomAccessContent should not extend DataOutput nor DataInput; Instead, it could declare the following new methods: 1) int read(byte b[], int off, int len) throws IOException; 2) void write(byte b[], int off, int len) throws IOException; 3) int pread(long pos, byte b[], int off, int len) throws IOException; 4) void pwrite(long pos, byte b[], int off, int len) throws IOException; Instead of changing this interface, a new one could be created (RandomAccessStream, maybe). Benefits: Currently, if a class implements this interface, it has to implement method skipBytes, which is redundant since it already implements method seek. It also has to implement 14 methods related to reading, which is also redundant since they can be expressed in terms of specific calls to more primitive methods such as those proposed above. In other words, I don't think different classes implementing RandomAccessContent (or RandomAccessStream) should all implement methods readShort, readInt, readLong, etc, since all implementations of them will be the same, if they are expressed in terms of calls to read(byte b[], int off, int len). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE][VFS] release commons-vfs 1.0 based on RC8
Hi! After an eventful year and some help from others I managed to cut a new RC. Please find the RC at http://people.apache.org/~imario/vfs The site can be reviewed at http://people.apache.org/~imario/vfs-1.0-RC8/site *) imported commons-compress into vfs codebase to get rid of snapshot dependency *) moved webdav implementation to the vfs sandbox due to the fact that webdavclient seems not active and no new release is on the way *) moved smb implemenation to the vfs sandbox due to licensing issues. Now that we sorted out how to deal with LGPL I'll move it back for a 1.1 release *) some bugfixes along the way Thanks to all supporters of commons-VFS! I'll cut a 1.0 release based on RC8, so please take some time and review the distribution [ ] +1 I support this release [ ] +0 [ ] -0 [ ] -1 I do not support this release because... Thanks for your time! --- Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANNOUNCE][VFS] commons-vfs 1.0 RC8
Hi! The commons vfs community is happy to announce the availability of commons-vfs 1.0 RC8. Please find the RC at http://people.apache.org/~imario/vfs The site can be reviewed at http://people.apache.org/~imario/vfs-1.0-RC8/site *) imported commons-compress into vfs codebase to get rid of snapshot dependency *) moved webdav implementation to the vfs sandbox due to the fact that webdavclient seems not active and no new release is on the way *) moved smb implemenation to the vfs sandbox due to licensing issues. Now that we sorted out how to deal with LGPL I'll move it back for a 1.1 release *) some bugfixes along the way Thanks to all supporters of commons-VFS! --- Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (VFS-90) RandomAccessFile backed by a RandomAccessContent instance
[ http://issues.apache.org/jira/browse/VFS-90?page=comments#action_12456852 ] Mario Ivankovits commented on VFS-90: - I had a look at this patch now, but I dont like the way how this needs to be done. I am aware why you need the temporary file, that we need to have it static and thus not thread safe and that we have to take care to delete the temporary file seems all too hacky. Unhappily I cant see another way how to workaround these things. RandomAccessFile backed by a RandomAccessContent instance - Key: VFS-90 URL: http://issues.apache.org/jira/browse/VFS-90 Project: Commons VFS Issue Type: New Feature Reporter: Elifarley Callado Coelho Priority: Minor Attachments: RACRandomAccessFile.java.bz2, src.zip Some existing libraries and applications rely on a RandomAccessFile instance to process its IO tasks. They could be benefited by an adapter class providing a RandomAccessFile view of an arbitrary RandomAccessContent. Example: a database server using a RandomAccessFile instance to access its data from a local file would automatically be able to access it from a remote resource accessed through HTTP. I have already created such a class. I'll try to add it to this issue. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (VFS-41) [VFS] New provider: iso9660
[ http://issues.apache.org/jira/browse/VFS-41?page=all ] Mario Ivankovits resolved VFS-41. - Resolution: Fixed Created plugins pages: http://jakarta.apache.org/commons/vfs/3rdparty.html [VFS] New provider: iso9660 --- Key: VFS-41 URL: http://issues.apache.org/jira/browse/VFS-41 Project: Commons VFS Issue Type: Improvement Environment: Operating System: All Platform: Other Reporter: John Didion Assigned To: Mario Ivankovits Priority: Minor Attachments: iso.patch, providers.xml.diff This is a patch for a read-only provider for ISO 9660 files. It depends on loopy (https://sourceforge.net/project/showfiles.php?group_id=161655). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (VFS-41) [VFS] New provider: iso9660
[ http://issues.apache.org/jira/browse/VFS-41?page=all ] Mario Ivankovits closed VFS-41. --- [VFS] New provider: iso9660 --- Key: VFS-41 URL: http://issues.apache.org/jira/browse/VFS-41 Project: Commons VFS Issue Type: Improvement Environment: Operating System: All Platform: Other Reporter: John Didion Assigned To: Mario Ivankovits Priority: Minor Attachments: iso.patch, providers.xml.diff This is a patch for a read-only provider for ISO 9660 files. It depends on loopy (https://sourceforge.net/project/showfiles.php?group_id=161655). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (VFS-45) [VFS] New provider: crypt
[ http://issues.apache.org/jira/browse/VFS-45?page=all ] Mario Ivankovits closed VFS-45. --- Resolution: Fixed homepage added to our plugins page [VFS] New provider: crypt - Key: VFS-45 URL: http://issues.apache.org/jira/browse/VFS-45 Project: Commons VFS Issue Type: Improvement Environment: Operating System: other Platform: Other Reporter: John Didion Priority: Minor Attachments: crypt.diff, crypt.diff A read/write provider that encrypts/decrypts files using a symmetric algorithm. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (VFS-33) [vfs] ftp-access a directory failed
[ http://issues.apache.org/jira/browse/VFS-33?page=all ] Mario Ivankovits updated VFS-33: Bugzilla Id: (was: 38181) Fix Version/s: later [vfs] ftp-access a directory failed --- Key: VFS-33 URL: http://issues.apache.org/jira/browse/VFS-33 Project: Commons VFS Issue Type: Bug Environment: Operating System: All Platform: Other Reporter: Sven Homburg Fix For: later i try to connect via ftp to a server with this uri : ftp://johndoe:[EMAIL PROTECTED]/depotxxx/depot120/ the user johndoe has only access to this directory but VFS tries to access the depotxxx and the root dir -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (VFS-96) Performance: FtpFileObject.getChildFile() without call to doGetChildren()
[ http://issues.apache.org/jira/browse/VFS-96?page=comments#action_12456861 ] Mario Ivankovits commented on VFS-96: - If it is a performance bottleneck depends on the use case. Loading of the directory should happen only once, so if you are going to scan the directory you'll have a performance bottleneck if you have to issue a dir for every single file. Having it configurable might be an option. Performance: FtpFileObject.getChildFile() without call to doGetChildren() -- Key: VFS-96 URL: http://issues.apache.org/jira/browse/VFS-96 Project: Commons VFS Issue Type: Improvement Affects Versions: later Reporter: Emmanuel Fleury The FtpFileObject.getChildFile() implementation gets the full directory lost of the parent to retrieve information on only one of its childs. This can be a performance bottleneck if the parent directory contains a lot of files (for instance, listing a directory containing 1000 files costs more than 100Kb). A better implementation should be to retrieve only the right child file information. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (VFS-96) Performance: FtpFileObject.getChildFile() without call to doGetChildren()
[ http://issues.apache.org/jira/browse/VFS-96?page=all ] Mario Ivankovits updated VFS-96: Affects Version/s: later Performance: FtpFileObject.getChildFile() without call to doGetChildren() -- Key: VFS-96 URL: http://issues.apache.org/jira/browse/VFS-96 Project: Commons VFS Issue Type: Improvement Affects Versions: later Reporter: Emmanuel Fleury The FtpFileObject.getChildFile() implementation gets the full directory lost of the parent to retrieve information on only one of its childs. This can be a performance bottleneck if the parent directory contains a lot of files (for instance, listing a directory containing 1000 files costs more than 100Kb). A better implementation should be to retrieve only the right child file information. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (VFS-85) unexpected http connect
[ http://issues.apache.org/jira/browse/VFS-85?page=all ]
Mario Ivankovits updated VFS-85:
Fix Version/s: later
unexpected http connect
---
Key: VFS-85
URL: http://issues.apache.org/jira/browse/VFS-85
Project: Commons VFS
Issue Type: Improvement
Reporter: Philippe Poulard
Fix For: later
when I try to create a file object with http://www.somehost.com/;, VFS fails
when the host is unreachable (e.g. when not connected to internet)
this is because org.apache.commons.vfs.provider.http.HttpFileSystem has a
constructor that has an argument HttpClient, whereas it should be an
HttpClientFactory
the HttpClient should be resolved only when required :
protected HttpClient getClient()
{
if ( this.client == null ) {
this.client = clientFactory.createConnection(...);
}
return client;
}
I didn't check it, but this issue is certainly present with FTP and others...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (VFS-96) Performance: FtpFileObject.getChildFile() without call to doGetChildren()
[ http://issues.apache.org/jira/browse/VFS-96?page=all ] Mario Ivankovits updated VFS-96: Fix Version/s: later Affects Version/s: (was: later) Performance: FtpFileObject.getChildFile() without call to doGetChildren() -- Key: VFS-96 URL: http://issues.apache.org/jira/browse/VFS-96 Project: Commons VFS Issue Type: Improvement Reporter: Emmanuel Fleury Fix For: later The FtpFileObject.getChildFile() implementation gets the full directory lost of the parent to retrieve information on only one of its childs. This can be a performance bottleneck if the parent directory contains a lot of files (for instance, listing a directory containing 1000 files costs more than 100Kb). A better implementation should be to retrieve only the right child file information. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (VFS-91) Provide random access to gzip files.
[ http://issues.apache.org/jira/browse/VFS-91?page=all ] Mario Ivankovits updated VFS-91: Fix Version/s: later Provide random access to gzip files. Key: VFS-91 URL: http://issues.apache.org/jira/browse/VFS-91 Project: Commons VFS Issue Type: Improvement Reporter: Elifarley Callado Coelho Priority: Minor Fix For: later Attachments: gzip-rac-src-20061017.zip A local file provides random access to its contents. For an application to have transparent access to the uncompressed contents of a gzip file, VFS should provide random access to it as well. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (VFS-43) [vfs] Services
[ http://issues.apache.org/jira/browse/VFS-43?page=all ] Mario Ivankovits updated VFS-43: Bugzilla Id: (was: 36047) Fix Version/s: 1.1 Final Affects Version/s: (was: 1.1 Final) [vfs] Services -- Key: VFS-43 URL: http://issues.apache.org/jira/browse/VFS-43 Project: Commons VFS Issue Type: Improvement Environment: Operating System: other Platform: Other Reporter: baidun Assigned To: Mario Ivankovits Priority: Minor Fix For: 1.1 Final Attachments: services.diff, vfs-services.zip The framework for vfs services and the implementation of svn services -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (VFS-74) AbstractMethodError when using httpclient v3.0.1
[ http://issues.apache.org/jira/browse/VFS-74?page=comments#action_12456874 ] Mario Ivankovits commented on VFS-74: - It looks there are still incompatibilities between httpclient 3.0.1 and webdav. Something with the url encoding seems to be wrong - or has to be handled differently? Well, hopefully webdav has a maintainer again ... we well see AbstractMethodError when using httpclient v3.0.1 Key: VFS-74 URL: http://issues.apache.org/jira/browse/VFS-74 Project: Commons VFS Issue Type: Bug Affects Versions: Nightly Builds Reporter: Maarten Coene Fix For: later Attachments: WebdavConnectionManager.java.patch Hi, when you use VFS in combination with commons httpclient 3.0.1, you get an AbstractMethodError: java.lang.AbstractMethodError at org.apache.commons.httpclient.HttpClient.setHttpConnectionManager(HttpClient.java:472) at org.apache.commons.vfs.provider.webdav.WebdavClientFactory.createConnection(WebdavClientFactory.java:82) at org.apache.commons.vfs.provider.webdav.WebdavFileProvider.doCreateFileSystem(WebdavFileProvider.java:85) at org.apache.commons.vfs.provider.AbstractOriginatingFileProvider.findFile(AbstractOriginatingFileProvider.java:76) at org.apache.commons.vfs.provider.AbstractOriginatingFileProvider.findFile(AbstractOriginatingFileProvider.java:61) at org.apache.commons.vfs.impl.DefaultFileSystemManager.resolveFile(DefaultFileSystemManager.java:640) at org.apache.commons.vfs.impl.DefaultFileSystemManager.resolveFile(DefaultFileSystemManager.java:601) at org.apache.commons.vfs.impl.DefaultFileSystemManager.resolveFile(DefaultFileSystemManager.java:569) at fr.jayasoft.ivy.repository.vfs.VfsResource.init(VfsResource.java:39) at fr.jayasoft.ivy.repository.vfs.VfsRepository.put(VfsRepository.java:159) at fr.jayasoft.ivy.resolver.RepositoryResolver.put(RepositoryResolver.java:173) at fr.jayasoft.ivy.resolver.RepositoryResolver.publish(RepositoryResolver.java:168) at fr.jayasoft.ivy.Ivy.publish(Ivy.java:2079) at fr.jayasoft.ivy.Ivy.publish(Ivy.java:2063) at fr.jayasoft.ivy.Ivy.publish(Ivy.java:2044) at fr.jayasoft.ivy.ant.IvyPublish.execute(IvyPublish.java:195) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275) at org.apache.tools.ant.Task.perform(Task.java:364) at org.apache.tools.ant.Target.execute(Target.java:341) at org.apache.tools.ant.Target.performTasks(Target.java:369) at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1216) at org.apache.tools.ant.Project.executeTarget(Project.java:1185) at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:40) at org.apache.tools.ant.Project.executeTargets(Project.java:1068) at org.apache.tools.ant.Main.runBuild(Main.java:668) at org.apache.tools.ant.Main.startAnt(Main.java:187) at org.apache.tools.ant.launch.Launcher.run(Launcher.java:246) at org.apache.tools.ant.launch.Launcher.main(Launcher.java:67) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (VFS-74) AbstractMethodError when using httpclient v3.0.1
[ http://issues.apache.org/jira/browse/VFS-74?page=all ] Mario Ivankovits updated VFS-74: Fix Version/s: later AbstractMethodError when using httpclient v3.0.1 Key: VFS-74 URL: http://issues.apache.org/jira/browse/VFS-74 Project: Commons VFS Issue Type: Bug Affects Versions: Nightly Builds Reporter: Maarten Coene Fix For: later Attachments: WebdavConnectionManager.java.patch Hi, when you use VFS in combination with commons httpclient 3.0.1, you get an AbstractMethodError: java.lang.AbstractMethodError at org.apache.commons.httpclient.HttpClient.setHttpConnectionManager(HttpClient.java:472) at org.apache.commons.vfs.provider.webdav.WebdavClientFactory.createConnection(WebdavClientFactory.java:82) at org.apache.commons.vfs.provider.webdav.WebdavFileProvider.doCreateFileSystem(WebdavFileProvider.java:85) at org.apache.commons.vfs.provider.AbstractOriginatingFileProvider.findFile(AbstractOriginatingFileProvider.java:76) at org.apache.commons.vfs.provider.AbstractOriginatingFileProvider.findFile(AbstractOriginatingFileProvider.java:61) at org.apache.commons.vfs.impl.DefaultFileSystemManager.resolveFile(DefaultFileSystemManager.java:640) at org.apache.commons.vfs.impl.DefaultFileSystemManager.resolveFile(DefaultFileSystemManager.java:601) at org.apache.commons.vfs.impl.DefaultFileSystemManager.resolveFile(DefaultFileSystemManager.java:569) at fr.jayasoft.ivy.repository.vfs.VfsResource.init(VfsResource.java:39) at fr.jayasoft.ivy.repository.vfs.VfsRepository.put(VfsRepository.java:159) at fr.jayasoft.ivy.resolver.RepositoryResolver.put(RepositoryResolver.java:173) at fr.jayasoft.ivy.resolver.RepositoryResolver.publish(RepositoryResolver.java:168) at fr.jayasoft.ivy.Ivy.publish(Ivy.java:2079) at fr.jayasoft.ivy.Ivy.publish(Ivy.java:2063) at fr.jayasoft.ivy.Ivy.publish(Ivy.java:2044) at fr.jayasoft.ivy.ant.IvyPublish.execute(IvyPublish.java:195) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275) at org.apache.tools.ant.Task.perform(Task.java:364) at org.apache.tools.ant.Target.execute(Target.java:341) at org.apache.tools.ant.Target.performTasks(Target.java:369) at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1216) at org.apache.tools.ant.Project.executeTarget(Project.java:1185) at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:40) at org.apache.tools.ant.Project.executeTargets(Project.java:1068) at org.apache.tools.ant.Main.runBuild(Main.java:668) at org.apache.tools.ant.Main.startAnt(Main.java:187) at org.apache.tools.ant.launch.Launcher.run(Launcher.java:246) at org.apache.tools.ant.launch.Launcher.main(Launcher.java:67) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (VFS-68) Extraction process is unefficient with large packages
[ http://issues.apache.org/jira/browse/VFS-68?page=comments#action_12456900 ] Mario Ivankovits commented on VFS-68: - I am not 100% sure, but maybe I found the problem. Would be great if you could find some time to test it again. Still, due to some overhead VFS introduces it might never be that fast than the native methods. Extraction process is unefficient with large packages - Key: VFS-68 URL: http://issues.apache.org/jira/browse/VFS-68 Project: Commons VFS Issue Type: Improvement Environment: Windows XP Pro, Java 1.5.0_03 Reporter: Harri Kähkönen Priority: Minor Fix For: Nightly Builds It seems that extracting large zip packages is much slower than with java.util.zip. In certain tests, the extraction time of 2 large packages was almost 1 hour more with VFS. The packages that caused this major efficiency issue we're over 1Gb size, and usually contain lots of entries. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (VFS-68) Extraction process is unefficient with large packages
[ http://issues.apache.org/jira/browse/VFS-68?page=all ] Mario Ivankovits resolved VFS-68. - Fix Version/s: Nightly Builds Resolution: Fixed Extraction process is unefficient with large packages - Key: VFS-68 URL: http://issues.apache.org/jira/browse/VFS-68 Project: Commons VFS Issue Type: Improvement Environment: Windows XP Pro, Java 1.5.0_03 Reporter: Harri Kähkönen Priority: Minor Fix For: Nightly Builds It seems that extracting large zip packages is much slower than with java.util.zip. In certain tests, the extraction time of 2 large packages was almost 1 hour more with VFS. The packages that caused this major efficiency issue we're over 1Gb size, and usually contain lots of entries. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (VFS-68) Extraction process is unefficient with large packages
[ http://issues.apache.org/jira/browse/VFS-68?page=all ] Mario Ivankovits closed VFS-68. --- Extraction process is unefficient with large packages - Key: VFS-68 URL: http://issues.apache.org/jira/browse/VFS-68 Project: Commons VFS Issue Type: Improvement Environment: Windows XP Pro, Java 1.5.0_03 Reporter: Harri Kähkönen Priority: Minor Fix For: Nightly Builds It seems that extracting large zip packages is much slower than with java.util.zip. In certain tests, the extraction time of 2 large packages was almost 1 hour more with VFS. The packages that caused this major efficiency issue we're over 1Gb size, and usually contain lots of entries. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (VFS-49) [VFS] Default VFS cache behavior
[ http://issues.apache.org/jira/browse/VFS-49?page=all ] Mario Ivankovits updated VFS-49: Bugzilla Id: (was: 38686) Fix Version/s: later [VFS] Default VFS cache behavior Key: VFS-49 URL: http://issues.apache.org/jira/browse/VFS-49 Project: Commons VFS Issue Type: Improvement Affects Versions: Nightly Builds Environment: Operating System: All Platform: All Reporter: Jean-Baptiste Onofré Priority: Minor Fix For: later It's really a bug but a explanation. The default VFS cache is SoftRefFilesCache. In my process, I have a FileManipulator which is simply a singleton. This singleton create one (and only one max) instance of FileSystemManager using VFS.getManager(). This process is called every 10mn to perform a copy from a FileObject to another. In earch loop, I perform something which looks like : FIleManipulator fileManipulator = FileManipulator.getInstance(); fileManipulator.copy(tgz:http://remote/archive.tar.gz!/dir/file;, /tmp/file); Either the tgz:http://remote/archive.tar.gz!/dir/file has not change, in the vfs_cache directory, I have : tmp_19071_file tmp_19076_file So a copy if performed every loop and neither release which take a lot of space on the filesystem. How can I avoid this behavior ? Should I create a FileManipulator (and so a FileSystemManager) and use the same in the loop ? Do I need to define my own filesystemmanager with another FileCache system (such as NullFileCache) ? Is it possible to define another VFS cache system for the default filesystem manager got with VFS.getManager() ? Many thanks for your help. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (VFS-90) RandomAccessFile backed by a RandomAccessContent instance
[ http://issues.apache.org/jira/browse/VFS-90?page=all ] Mario Ivankovits resolved VFS-90. - Resolution: Won't Fix As in preparation for a VFS release I close this issue as Won't Fix for now, but feel free to reopen/ping me if you've found another solution. Thanks anyway! RandomAccessFile backed by a RandomAccessContent instance - Key: VFS-90 URL: http://issues.apache.org/jira/browse/VFS-90 Project: Commons VFS Issue Type: New Feature Reporter: Elifarley Callado Coelho Priority: Minor Attachments: RACRandomAccessFile.java.bz2, src.zip Some existing libraries and applications rely on a RandomAccessFile instance to process its IO tasks. They could be benefited by an adapter class providing a RandomAccessFile view of an arbitrary RandomAccessContent. Example: a database server using a RandomAccessFile instance to access its data from a local file would automatically be able to access it from a remote resource accessed through HTTP. I have already created such a class. I'll try to add it to this issue. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (VFS-97) M$ FTP Virtual Folder support
[ http://issues.apache.org/jira/browse/VFS-97?page=all ] Mario Ivankovits updated VFS-97: Fix Version/s: 1.1 Final Affects Version/s: (was: 1.1 Final) M$ FTP Virtual Folder support - Key: VFS-97 URL: http://issues.apache.org/jira/browse/VFS-97 Project: Commons VFS Issue Type: New Feature Environment: current CVS version, 1.0-RC8 Reporter: Sergey Vladimirov Fix For: 1.1 Final Attachments: patch-testcase.txt, patch.txt FTP Object should return child by name, even if it's name of unlisted virtual directory. IIS support creation FTP virtual folders. Such foldres is not listed in LS command, but can be accessed by name (CWD/LS) as well as files in it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (VFS-69) FTPFileObject monitor doesn't retrieve lastModifiedTime
[ http://issues.apache.org/jira/browse/VFS-69?page=all ]
Mario Ivankovits resolved VFS-69.
-
Resolution: Fixed
Should be fixed now, though, it looks not very performant as we have to refetch
the whole parent listing.
Maybe there is room for improvement in the future.
FTPFileObject monitor doesn't retrieve lastModifiedTime
---
Key: VFS-69
URL: http://issues.apache.org/jira/browse/VFS-69
Project: Commons VFS
Issue Type: Bug
Environment: Windows XP, Java version 1.4.2 (this is the version of
Java that WebSphere Portal 5.1 runs on), WebSphere Portal
Reporter: Tony Cooke
Assigned To: Mario Ivankovits
Monitoring of files on a ftp server using DefaultFileMonitor doesn't seem to
register changes in the last modified time.
From the email correspondance with Mario:
1.
This is how I've set up my DefaultFileMonitor:
DefaultFileMonitor fm = new DefaultFileMonitor(new FileListener() {
public void fileCreated(FileChangeEvent arg0) throws Exception {
System.out.println(File created. + arg0.getFile().getName());
}
public void fileDeleted(FileChangeEvent arg0) throws Exception {
System.out.println(File deleted. + arg0.getFile().getName());
}
public void fileChanged(FileChangeEvent arg0) throws Exception {
System.out.println(File changed. + arg0.getFile().getName());
}
});
fm.setDelay(6);
fm.addFile(file);
fm.start();
2.
Thanks for the code snipped. I tried it with the default
VFS.getManager() (without setting the CacheStrategy) and it works here with
my ftp server as expected.
I am pretty sure for your tests you do not use a delay of 6, do you?
I tried it with 5000 (5 seconds) and get the events promptly.
But .. I pointed the monitor to a directory
And this is how I run my checks:
try {
for (int i = 0; 1 100; i++) {
Thread.sleep(6); // 1 minute
System.out.println(file.getContent().getLastModifiedTime() +
+ file.getName());
}
} catch (InterruptedException ie) {
ie.printStackTrace();
}
ok - got it. Its a bug in the FTPFileObject, unhappily I have no
workaround yet.
Thank you for your help and sorry again for the extra work.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (VFS-69) FTPFileObject monitor doesn't retrieve lastModifiedTime
[ http://issues.apache.org/jira/browse/VFS-69?page=all ]
Mario Ivankovits closed VFS-69.
---
FTPFileObject monitor doesn't retrieve lastModifiedTime
---
Key: VFS-69
URL: http://issues.apache.org/jira/browse/VFS-69
Project: Commons VFS
Issue Type: Bug
Environment: Windows XP, Java version 1.4.2 (this is the version of
Java that WebSphere Portal 5.1 runs on), WebSphere Portal
Reporter: Tony Cooke
Assigned To: Mario Ivankovits
Monitoring of files on a ftp server using DefaultFileMonitor doesn't seem to
register changes in the last modified time.
From the email correspondance with Mario:
1.
This is how I've set up my DefaultFileMonitor:
DefaultFileMonitor fm = new DefaultFileMonitor(new FileListener() {
public void fileCreated(FileChangeEvent arg0) throws Exception {
System.out.println(File created. + arg0.getFile().getName());
}
public void fileDeleted(FileChangeEvent arg0) throws Exception {
System.out.println(File deleted. + arg0.getFile().getName());
}
public void fileChanged(FileChangeEvent arg0) throws Exception {
System.out.println(File changed. + arg0.getFile().getName());
}
});
fm.setDelay(6);
fm.addFile(file);
fm.start();
2.
Thanks for the code snipped. I tried it with the default
VFS.getManager() (without setting the CacheStrategy) and it works here with
my ftp server as expected.
I am pretty sure for your tests you do not use a delay of 6, do you?
I tried it with 5000 (5 seconds) and get the events promptly.
But .. I pointed the monitor to a directory
And this is how I run my checks:
try {
for (int i = 0; 1 100; i++) {
Thread.sleep(6); // 1 minute
System.out.println(file.getContent().getLastModifiedTime() +
+ file.getName());
}
} catch (InterruptedException ie) {
ie.printStackTrace();
}
ok - got it. Its a bug in the FTPFileObject, unhappily I have no
workaround yet.
Thank you for your help and sorry again for the extra work.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: conversation-tag
Hi Martin! java.lang.IllegalStateException: Null request object org.apache.catalina.connector.RequestFacade.getAttribute(RequestFacade.java:256) org.apache.myfaces.context.servlet.RequestMap.getAttribute(RequestMap.java:44) org.apache.myfaces.context.servlet.AbstractAttributeMap.get(AbstractAttributeMap.java:91) org.apache.myfaces.custom.conversation.ConversationManager.getConversationContextId(ConversationManager.java:202) org.apache.myfaces.custom.conversation.ConversationManager.getConversationContext(ConversationManager.java:330) org.apache.myfaces.custom.conversation.ConversationManager.attachPersistence(ConversationManager.java:503) Yea - maybe I got it. Is it true that we do NOT release (set to null) the thread-local FacesContext._currentInstance after the request? Tomcat do not create new threads, thus - no one will release a ThreadLocal - any ThreadLocal will hold its value and presents this value to other subsequent requests. Not only for GC we should release it. For the above case it looks like the the conversation tag sees a previous instance of the FacesContext which holds a RequestMap which is no longer valid. I see two ways to fix it: 1) avoid using the FacesContext at this point. I can do it, but I would not really like it to do. 2) release the FacesContext at the end of the request. I'd go for 2. Ciao, Mario
[jira] Updated: (TOMAHAWK-813) submitOnEvent doesn't recognize image commandButtons
[ http://issues.apache.org/jira/browse/TOMAHAWK-813?page=all ] Mario Ivankovits updated TOMAHAWK-813: -- Status: Resolved (was: Patch Available) Fix Version/s: 1.1.5-SNAPSHOT Resolution: Fixed Applied. Thanks for the patch! submitOnEvent doesn't recognize image commandButtons Key: TOMAHAWK-813 URL: http://issues.apache.org/jira/browse/TOMAHAWK-813 Project: MyFaces Tomahawk Issue Type: Bug Components: submitOnEvent Environment: n/a Reporter: Harlan Iverson Priority: Minor Fix For: 1.1.5-SNAPSHOT Attachments: submitOnEvent-image-commandButton.patch submitOnEvent says SubmitOnEvent: don't know how to fire component 'searchForm:searchButton' when for= references an image commandButton. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: ENTER key with a single form but multiple actions
Hi Mick! I have a form with multiple actions and I want a default action to happen when I click the enter key. Have a look at our sandbox component submitOnEvent. It has various modes to determine which action to trigger. The simplest might be to add it as child to the commandButton which should be the default. You'll find its wiki page here [1] Ciao, Mario [1] http://wiki.apache.org/myfaces/SubmitOnEvent
Re: inputCalendar validator
Hi! I have a user who loves to enter the date as MM/dd/YY ignoring the help text But the expected is MM/dd/ So when he enters 12/01/06 …. Might not be much of help, but I implemented a rather complicated converter ... well not that complicated, just uses tons of simple date formats ... to allow the user to enter virtually any date. e.g. mm/dd/, mm/dd/yy, mm/dd or just dd for the first two cases I use the fact that you can have a DateFormat m/d/y and java is smart enough to parse it right. SimpleDateFormat sdf = new SimpleDateFormat(M/d/y, Locale.US); System.err.println(sdf.parse(12/01/06)); System.err.println(sdf.parse(12/01/2006)); With some tricky string operations you can create the patterns in a locale sensitive way. Ciao, Mario
[jira] Created: (MYFACES-1504) oamSetHiddenInput function missing if ...
oamSetHiddenInput function missing if ...
-
Key: MYFACES-1504
URL: http://issues.apache.org/jira/browse/MYFACES-1504
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 1.1.5-SNAPSHOT
Environment: latest myfaces svn head
Reporter: Mario Ivankovits
a) ... there is only a commandButton on the form (not commandLinks)
... which is not necessarily a problem as normally such a form do not require
these functions, BUT when you have enabled the auto_scroll feature things
getting worse. Then something like
oamSetHiddenInput('_idJsp29','autoScroll',getScrolling())
will be rendered and then the oamSetHiddenInput function is missing.
b) ... you are using the adf form
in HtmlLinkRendererBase you'll see that renderFormSubmitScriptIfNecessary will
not be called if the link is used within an adf form, then again the autoScroll
feature is broken and a javascript error will be shown.
Would be great if someone else has some time to fix it.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] s:selectItems to tomahawk
Hi! I'm planning to promote s:selectItems to tomahawk. Component satisfies all of the requirements needed for promotion. +1 Ciao, Mario
Re: Great!! But no release?
Hi! So is this no release policy something that could be changed? Or is it final? I thought this too. Maybe the lab could allow zero-dot (0.1, 0.2, etc) releases with an explanation why the lab cant create a major release? Ciao, Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Progress bar?
Hi Werner!
h:form
t:saveState value=#{progressor.percentage}/t:saveState
h:commandLink/h:commandLink
s:pprPanelGroup id=pprmain periodicalUpdate=500
t:div id=process_done rendered=#{progressor.percentage ==
100} forceId=true/
t:div id=progressbar binding=#{progressor.bar}
style=#{progressor.style}
h:outputFormat binding=#{progressor.outputformat}
value=Login in progress, please wait/
/t:div
/s:pprPanelGroup
/h:form
Shouldn't it be possible to embed a f:verbatim within the process_done
div which renders the window.location stuff then?
Ciao,
Mario
[hibernate-dev] HibernateSearch DocumentBuilder questions
Hi! Is [1] the actual version of the DocumentBuilder? If so, I think we miss something like a converter on fields. As far as I remember to allow range queries (from, to value) you have to create a special string which allows this for numeric values and dates. You have to ensure ordering for numerics even with string comparision, means, you have to convert e.g. 17 to 17 and 1112 to 001112 so that you can execute a range query on them. Similar for dates. You can create those strings for numerics automatically if the user provides a e.g @Min, @Max annotation, still, having a @SearchableConverter where you can define a converter would be great. For sure, you have to take core of the used strategy when building the query too. Ciao, Mario [1] http://fisheye.labs.jboss.com/browse/Hibernate/branches/Lucene_Integration/HibernateExt/metadata/src/java/org/hibernate/lucene/DocumentBuilder.java?r=10076 ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] HibernateSearch DocumentBuilder questions
Hi Emmanuel! No it's http://fisheye.labs.jboss.com/browse/Hibernate/branches/Branch_3_2/HibernateExt/metadata/src/java/org/hibernate/search/engine/DocumentBuilder.java?r=10867 I have merged everything back to the 3.2 version and the version you point to is a very old one :-) Oh ...ok .. I see, thanks for the pointer. You can do what you want through a @FieldBridge (which is probably what you refer to as a @SearchableConverter). Yep, thats it! Ciao, Mario ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Hibernate search(lucene) update question opinion.
Hi Emmanuel! Remember that while you can use the same index for your whole domain model, One index per entity is the recommended approach. Do you expect a finer grained model? Under which partition strategy? First, I hadn't had the time till now to have a look at Hibernate Search, so sorry if this is some sort of newbie question Yes, I thought of a finer grained model, based on the content of the entity. Say you have a property named type in your entity, based on this type one might be able to create multiple smaller indexes. Very similar to what a database can do with partitioned tables. Now, to avoid any complex annotations we can hand the work to determine the partition to the DirectoryProvider (which I assume a user has to provide) Maybe by simply add the entity as argument to the directoryProvider.getDirectory() method so the provider could return a directory based on some sort of complex logic based on the entity. Then, we need an addition like directoryProvider.getDirectories() and create a MultiSearcher based on these directories. Now we can go even further (and I have done this in our Lucene Server). By caching the version of each of the directories, you are able to reopen only those indexes which have changed. So if the index changed, you do not have to open the whole index (which can be really large once you indexed plenty of text data - I've indexes with 1GB in size). I hope its clear what I wanted to say, else I can reword or even better ... can come up with a patch :-) Ciao, Mario ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: Very important JSF issue
Hi Dominik,
a href=#
onclick=clear_mainBrowse_3AbrowseContent_3AbrowseListPage_3AbrowseListMain_3AbrowseListResults_3AbrowseListResultsForm();document.forms['mainBrowse:browseContent:browseListPage:browseListMain:browseListResults:browseListResultsForm'].elements['autoScroll'].value=getScrolling();document.forms['mainBrowse:browseContent:browseListPage:browseListMain:browseListResults:browseListResultsForm'].elements['mainBrowse:browseContent:browseListPage:browseListMain:browseListResults:browseListResultsForm:_link_hidden_'].value='mainBrowse:browseContent:browseListPage:browseListMain:browseListResults:browseListResultsForm:listResults:11:panelPckLink:_idJsp74';if(document.forms['mainBrowse:browseContent:browseListPage:browseListMain:browseListResults:browseListResultsForm'].onsubmit){var
result=document.forms['mainBrowse:browseContent:browseListPage:browseListMain:browseListResults:browseListResultsForm'].onsubmit();
if( (typeof result == 'undefined') || result )
{document.forms['mainBrowse:browseContent:browseListPage:browseListMain:browseListResults:browseListResultsForm'].submit();}}else{document.forms['mainBrowse:browseContent:browseListPage:browseListMain:browseListResults:browseListResultsForm'].submit();}return
false;
id=mainBrowse:browseContent:browseListPage:browseListMain:browseListResults:browseListResultsForm:listResults:11:panelPckLink:_idJsp74[A]/a
Beside using the latest nightly and gzip, consider using shorter id=
names, in your case this will have a great impact in page size ;-)
Ciao,
Mario
Re: [vfs] DefaultFileMonitor doesn't signal when a file is created.
Hi Steven! I put a monitor on a configuration file (not a folder). During testing I noticed that the monitoring doesn't recognize when the file is created. I get changed and deleted events but never a created event. As far as I remember this is the same with all those native file system monitors out there, you always have to monitor the directory to get the create event. I don't know if I would like to change it, even if it is a valid use case, at least, it requires some in-depth thoughts @Thorsten: how will your fam behave in such a situation? Ciao, Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r478073 - in /myfaces/shared/trunk/core/src/main/java/org/apache/myfaces/shared: renderkit/RendererUtils.java util/_ComponentUtils.java
Hi Matze! First step for MYFACES-1496. Making _ComponentUtils deprecated! and modifying RendererUtils. Maybe you can not only deprecate it, but also delegate them to the RendererUtils. That way we do not have to maintain two pieces of code. Ciao, Mario
Re: findNestingForm
Hi! _ComponentUtils to RendererUtils ? Also why is the name starting with _ ? I think that was to express the fact that this is an internal utils class. Not for public use. You know, one of the major oddities in java, you can't have package and sub-package private methods. Ciao, Mario
Re: svn commit: r478073 - in /myfaces/shared/trunk/core/src/main/java/org/apache/myfaces/shared: renderkit/RendererUtils.java util/_ComponentUtils.java
Hi! see my other comment on that; I didn't got feedback on my first email, so I only started on that. Well, I am fine with what you do, nothing bad :-) Deprecation is good and remove all callers is super, still, delegating the deprecated methods to the supported one is just another wish from my side ;-) Ciao, Mario
Re: svn commit: r478073 - in /myfaces/shared/trunk/core/src/main/java/org/apache/myfaces/shared: renderkit/RendererUtils.java util/_ComponentUtils.java
Hi! done for findNestingForm ;) (not getValie... Great! Thanks! I'll drink a beer for your tonight :-D Ciao, Mario
Re: findNestingForm
Hi! in myfaces-api we have the same; but nobody outside of myfaces-api uses them ;) so same should be true for shared as well... I think those _ thingies were introduces before the shared comes to live, so thats why we have them all around. If we think this breaks our naming convention we should deprecate the _ComponentUtils too and create a new ComponentUtils class. Then, you can delegate from _ComponentUtils to ComponentUtils. *hehe* :-D hihi, lol Ciao, Mario
Re: [announcement] new security extensions
Hi Bernd! Bohmann schrieb: http://mail-archives.apache.org/mod_mbox/myfaces-dev/200610.mbox/[EMAIL PROTECTED] Sorry, I've read it in the past, but my brain didn't jump up at this time :-( I like the idea to share more code with each other project. Great! The FileUpload stuff is somewhat tricky. If we would like to have it, it has to go to tomahawk directly, else, it will collide with our ExtensionsFilter. Or, we implement a way to disable the upload thing there. Well, a way can be found just care has to be taken. The security guy ( (c) matze ;-) ) can go to our sandbox15, @cagatay, do you have time to do it? Ciao, Mario
Re: [announcement] new security extensions
Hi Matthias! http://svn.apache.org/viewvc/myfaces/tobago/trunk/contrib/security/ This one is really interesting, though, instead of a simple error message I'd prefer something like invoking a navigation, or even better delegating the action to be taken to the user defined security context implementation. We should discuss with the tobago guys if stuff like this (not directly tobago related) wouldn't fit better in our sandbox15, shouldn't we? Ciao, Mario
[compress] Re: VFS jar files
Hi Will! If folks are interested in code that can write to Zip Files, I've offered code to do this before. Hmmm, looks like I really missed it, sorry! I was thinking it would make sense to put it in compress, and then VFS could use as well. I don't know the status of commons-compress, there was a API change undergoing (for sure, you know), but I am not sure whats the current state is. So, I see two ways ... 1) you finish the compress api change so that we can release it (and add your code for sure) :-) 2) you add your zip enhancements to VFS - we added the old compress code so that we are able to get rid of any snapshot dependency so we can have a VFS release. Yes, yes I know, still no time to cut the release In either way, please ensure you use the org.apache.compress/vfs namespace, add the AFS license header and file a CLA (in case you didn't in the past already) For sure, I prefer the way 1. Ciao, Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: VFS jar files
Nadim Murr schrieb: My problem is the following; when dealing with jar or zip files, I'm not able to write, and more specifically I can't create a new folder inside. VFS is not yet able to write to e.g. jar files, please see the capabilities matrix [1] Another question is: Is there a way to access a password protected jar file in VFS? You mean signed jars, do you? No, there is no way yet to provide a password, but this might be done easily ... do you have some sort of code which shows how to do it? Ciao, Mario [1] http://wiki.apache.org/jakarta-commons/VfsCapabilitiesMatrix - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TOMAHAWK-780) DojoInitializer fails on IE
[
http://issues.apache.org/jira/browse/TOMAHAWK-780?page=comments#action_12450237
]
Mario Ivankovits commented on TOMAHAWK-780:
---
Ok, content-length added. Ariel, could you please try the latest svn head.
Thanks!
DojoInitializer fails on IE
---
Key: TOMAHAWK-780
URL: http://issues.apache.org/jira/browse/TOMAHAWK-780
Project: MyFaces Tomahawk
Issue Type: Bug
Reporter: Ariel Falduto
Assigned To: Mario Ivankovits
DojoInitializer fails on explorer when tries to load the dojo.js if i
look the servlet response of dojo.js file thats not fully writed in the
response ... but in firefox works right.
im debuggin currently this method placed on MyFacesResourceLoader ...
/**
* Copy the content of the specified input stream to the servlet response.
*/
protected void writeResource(HttpServletRequest request,
HttpServletResponse response,
InputStream in) throws IOException
{
ServletOutputStream out = response.getOutputStream();
try
{
byte[] buffer = new byte[1024];
for (int size = in.read(buffer); size != -1; size =
in.read(buffer))
{
out.write(buffer, 0, size);
}
}
finally
{
out.close();
}
}
and its look fine cos' in firefox works ... :P
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Problem with f:convertNumber
Hi Adrian! Hi all! I`m using myfaces 1.1.5 nightly build. I've created my own convertor for BigDecimal to show error message that is oriented to the big decimal object. I have form with input field that is binded to big decimal. Everything works fine. Now i want to put a convertor that will cut some fraction digits - f:convertNumber maxFractionDigits=5 /. When the page is rendered everything is ok but when i submit the form i got the following as h:message for the input component: Exception setting property taxBase of base with class org.cts.web.bean.WareDTO, Bean: org.cts.web.bean.WareDTO, property: taxBase, newValue: 1,newValue class: java.lang.Long method parameter class: java.math.BigDecimal, argument type mismatch Or if i input decimal value - 1.5 i get ... newValue: 1.5,newValue class: java.lang.Double method parameter class: java.math.BigDecimal, argument type mismatch. Any suggestions? Use the tomahawk sandbox (I think) converter s:convertNumber which will automatically try to convert the input to the data type of your backing bean. Ciao, Mario
[jira] Created: (SHALE-332) NPE if javax.faces.CONFIG_FILES points to nonexistent file
NPE if javax.faces.CONFIG_FILES points to nonexistent file -- Key: SHALE-332 URL: http://issues.apache.org/struts/browse/SHALE-332 Project: Shale Issue Type: Improvement Components: Tiger Affects Versions: 1.0.4-SNAPSHOT Reporter: Mario Ivankovits Attachments: npe_prevention.diff LifecycleListener2 will fail with a NPE if javax.faces.CONFIG_FILES points to a nonexistent file. Assumed that the JSF implementation should complain about such misconfigurations the attached patch will let shale-tiger silently ignore such entries. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SHALE-332) NPE if javax.faces.CONFIG_FILES points to nonexistent file
[ http://issues.apache.org/struts/browse/SHALE-332?page=all ] Mario Ivankovits updated SHALE-332: --- Attachment: npe_prevention.diff NPE if javax.faces.CONFIG_FILES points to nonexistent file -- Key: SHALE-332 URL: http://issues.apache.org/struts/browse/SHALE-332 Project: Shale Issue Type: Improvement Components: Tiger Affects Versions: 1.0.4-SNAPSHOT Reporter: Mario Ivankovits Priority: Minor Attachments: npe_prevention.diff LifecycleListener2 will fail with a NPE if javax.faces.CONFIG_FILES points to a nonexistent file. Assumed that the JSF implementation should complain about such misconfigurations the attached patch will let shale-tiger silently ignore such entries. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SHALE-332) NPE if javax.faces.CONFIG_FILES points to nonexistent file
[ http://issues.apache.org/struts/browse/SHALE-332?page=all ] Mario Ivankovits updated SHALE-332: --- Priority: Minor (was: Major) NPE if javax.faces.CONFIG_FILES points to nonexistent file -- Key: SHALE-332 URL: http://issues.apache.org/struts/browse/SHALE-332 Project: Shale Issue Type: Improvement Components: Tiger Affects Versions: 1.0.4-SNAPSHOT Reporter: Mario Ivankovits Priority: Minor Attachments: npe_prevention.diff LifecycleListener2 will fail with a NPE if javax.faces.CONFIG_FILES points to a nonexistent file. Assumed that the JSF implementation should complain about such misconfigurations the attached patch will let shale-tiger silently ignore such entries. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-1492) valueChangeListener is being called before the setters, even with immediate=true
[
http://issues.apache.org/jira/browse/MYFACES-1492?page=comments#action_12449356
]
Mario Ivankovits commented on MYFACES-1492:
---
Now, please, let us try not to heat up this situation any more.
We're all nice guys, stressed by our day jobs and more often then not our
nerves are overwought.
Well, Mircea, next time, please start in our myfaces-user [1] mailinglist.
Developer sometimes ... often ... always (? ;-) ) tend to knee-jerk reactions
when new JIRA tickes come in without having them discussed on the mailinglist
before - Dont treat it personal. JIRA should not be used to start off new
discussions.
Have a nice day!
Ciao,
Mario
[1] http://myfaces.apache.org/mail-lists.html
valueChangeListener is being called before the setters, even with
immediate=true
--
Key: MYFACES-1492
URL: http://issues.apache.org/jira/browse/MYFACES-1492
Project: MyFaces Core
Issue Type: Bug
Components: General
Affects Versions: 1.1.4
Reporter: Mircea Zahan
Assigned To: Cagatay Civici
Priority: Critical
Fix For: 1.1.4
valueChangeListener is being called before the setters, even with
immediate=true.
This is not the right behavior since it overwrites any property modified in
the event handler.
t:panelGrid columns=2 cellpadding=0 cellspacing=5px
columnClasses=left top, left top
t:outputLabel for=infoId value=Options/
t:selectOneMenu id=infoId value=#{productBean.infoId}
onchange=submit() valueChangeListener=#{productBean.valueChangedHandler}
immediate=true
f:selectItem itemValue=-1 itemLabel=new short info/
f:selectItems value=#{productBean.shortInfoSelectItems}/
/t:selectOneMenu
t:outputLabel for=descText value=Description/
t:inputTextarea id=descText rows=8
value=#{productBean.description}/
t:outputLabel for=utilText value=Usage/
t:inputTextarea id=utilText styleClass=wXXXL rows=8
value=#{productBean.usage}/
/t:panelGrid
public class ProductBean {
private Long infoId;
private String description;
private String usage;
// setters and getters for the above properties
public void valueChangedHandler(ValueChangeEvent event) {
Long infoId = (Long) event.getNewValue();
if ((infoId != null) (infoId 0)) {
//DataService and ProductInfo are related to Hibernate
ProductInfo info = DataService.getProductInfo(infoId);
this.description = info.getDescription();
this.usage = info.getUsage();
}
}
}
Description and Usage properties can never be changed since they get
overwritten with the initial values.
:(
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-1492) valueChangeListener is being called before the setters, even with immediate=true
[
http://issues.apache.org/jira/browse/MYFACES-1492?page=comments#action_12449377
]
Mario Ivankovits commented on MYFACES-1492:
---
Martin,
it looks like the not called getter is a known feature
http://forum.java.sun.com/thread.jspa?threadID=720889 ;-)
Though, not sure if this thread tells the truth ...
valueChangeListener is being called before the setters, even with
immediate=true
--
Key: MYFACES-1492
URL: http://issues.apache.org/jira/browse/MYFACES-1492
Project: MyFaces Core
Issue Type: Bug
Components: General
Affects Versions: 1.1.4
Reporter: Mircea Zahan
Assigned To: Cagatay Civici
Priority: Critical
Fix For: 1.1.4
valueChangeListener is being called before the setters, even with
immediate=true.
This is not the right behavior since it overwrites any property modified in
the event handler.
t:panelGrid columns=2 cellpadding=0 cellspacing=5px
columnClasses=left top, left top
t:outputLabel for=infoId value=Options/
t:selectOneMenu id=infoId value=#{productBean.infoId}
onchange=submit() valueChangeListener=#{productBean.valueChangedHandler}
immediate=true
f:selectItem itemValue=-1 itemLabel=new short info/
f:selectItems value=#{productBean.shortInfoSelectItems}/
/t:selectOneMenu
t:outputLabel for=descText value=Description/
t:inputTextarea id=descText rows=8
value=#{productBean.description}/
t:outputLabel for=utilText value=Usage/
t:inputTextarea id=utilText styleClass=wXXXL rows=8
value=#{productBean.usage}/
/t:panelGrid
public class ProductBean {
private Long infoId;
private String description;
private String usage;
// setters and getters for the above properties
public void valueChangedHandler(ValueChangeEvent event) {
Long infoId = (Long) event.getNewValue();
if ((infoId != null) (infoId 0)) {
//DataService and ProductInfo are related to Hibernate
ProductInfo info = DataService.getProductInfo(infoId);
this.description = info.getDescription();
this.usage = info.getUsage();
}
}
}
Description and Usage properties can never be changed since they get
overwritten with the initial values.
:(
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-1492) valueChangeListener is being called before the setters, even with immediate=true
[
http://issues.apache.org/jira/browse/MYFACES-1492?page=comments#action_12449384
]
Mario Ivankovits commented on MYFACES-1492:
---
I too find its strange that they fire the event before the update_model phase
... I'll say thats the technical point of view, hmmm, and maybe you can use
it to veto this particular change ... is this possible?
Anyway, thats why we developed the valueChangeNotifier . so everything is
wonderful again :-D
valueChangeListener is being called before the setters, even with
immediate=true
--
Key: MYFACES-1492
URL: http://issues.apache.org/jira/browse/MYFACES-1492
Project: MyFaces Core
Issue Type: Bug
Components: General
Affects Versions: 1.1.4
Reporter: Mircea Zahan
Assigned To: Cagatay Civici
Priority: Critical
Fix For: 1.1.4
valueChangeListener is being called before the setters, even with
immediate=true.
This is not the right behavior since it overwrites any property modified in
the event handler.
t:panelGrid columns=2 cellpadding=0 cellspacing=5px
columnClasses=left top, left top
t:outputLabel for=infoId value=Options/
t:selectOneMenu id=infoId value=#{productBean.infoId}
onchange=submit() valueChangeListener=#{productBean.valueChangedHandler}
immediate=true
f:selectItem itemValue=-1 itemLabel=new short info/
f:selectItems value=#{productBean.shortInfoSelectItems}/
/t:selectOneMenu
t:outputLabel for=descText value=Description/
t:inputTextarea id=descText rows=8
value=#{productBean.description}/
t:outputLabel for=utilText value=Usage/
t:inputTextarea id=utilText styleClass=wXXXL rows=8
value=#{productBean.usage}/
/t:panelGrid
public class ProductBean {
private Long infoId;
private String description;
private String usage;
// setters and getters for the above properties
public void valueChangedHandler(ValueChangeEvent event) {
Long infoId = (Long) event.getNewValue();
if ((infoId != null) (infoId 0)) {
//DataService and ProductInfo are related to Hibernate
ProductInfo info = DataService.getProductInfo(infoId);
this.description = info.getDescription();
this.usage = info.getUsage();
}
}
}
Description and Usage properties can never be changed since they get
overwritten with the initial values.
:(
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-1492) valueChangeListener is being called before the setters, even with immediate=true
[
http://issues.apache.org/jira/browse/MYFACES-1492?page=comments#action_12449390
]
Mario Ivankovits commented on MYFACES-1492:
---
Well, you know, there is a JSF spec, we cant do anything which makes our
implementation behave different from the spec.
We have to pass TCK tests.
valueChangeListener is being called before the setters, even with
immediate=true
--
Key: MYFACES-1492
URL: http://issues.apache.org/jira/browse/MYFACES-1492
Project: MyFaces Core
Issue Type: Bug
Components: General
Affects Versions: 1.1.4
Reporter: Mircea Zahan
Assigned To: Cagatay Civici
Priority: Critical
Fix For: 1.1.4
valueChangeListener is being called before the setters, even with
immediate=true.
This is not the right behavior since it overwrites any property modified in
the event handler.
t:panelGrid columns=2 cellpadding=0 cellspacing=5px
columnClasses=left top, left top
t:outputLabel for=infoId value=Options/
t:selectOneMenu id=infoId value=#{productBean.infoId}
onchange=submit() valueChangeListener=#{productBean.valueChangedHandler}
immediate=true
f:selectItem itemValue=-1 itemLabel=new short info/
f:selectItems value=#{productBean.shortInfoSelectItems}/
/t:selectOneMenu
t:outputLabel for=descText value=Description/
t:inputTextarea id=descText rows=8
value=#{productBean.description}/
t:outputLabel for=utilText value=Usage/
t:inputTextarea id=utilText styleClass=wXXXL rows=8
value=#{productBean.usage}/
/t:panelGrid
public class ProductBean {
private Long infoId;
private String description;
private String usage;
// setters and getters for the above properties
public void valueChangedHandler(ValueChangeEvent event) {
Long infoId = (Long) event.getNewValue();
if ((infoId != null) (infoId 0)) {
//DataService and ProductInfo are related to Hibernate
ProductInfo info = DataService.getProductInfo(infoId);
this.description = info.getDescription();
this.usage = info.getUsage();
}
}
}
Description and Usage properties can never be changed since they get
overwritten with the initial values.
:(
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-1492) valueChangeListener is being called before the setters, even with immediate=true
[
http://issues.apache.org/jira/browse/MYFACES-1492?page=comments#action_12449262
]
Mario Ivankovits commented on MYFACES-1492:
---
I've never seen valueChangeEvents fired during the invoke application phase,
and yes, I too think the documentation is wrong here. See [1] for a
documentation with what matching my knowledge.
So, one solution can be to use the valueChangeNotifier (tomahawk sandbox), its
events are fired AFTER the update model phase (regardless of the immediate
attribute) and thus should work as expected.
Hope this helps ...
[1]
http://www.oracle.com/webapps/online-help/jdeveloper/10.1.3/state/content/navId.4/navSetId._/vtTopicFile.jsf_apps%7Ceventvalidate%7Csf_aev_valuechange~html/
valueChangeListener is being called before the setters, even with
immediate=true
--
Key: MYFACES-1492
URL: http://issues.apache.org/jira/browse/MYFACES-1492
Project: MyFaces Core
Issue Type: Bug
Components: General
Affects Versions: 1.1.4
Reporter: Mircea Zahan
Priority: Critical
Fix For: 1.1.4
valueChangeListener is being called before the setters, even with
immediate=true.
This is not the right behavior since it overwrites any property modified in
the event handler.
t:panelGrid columns=2 cellpadding=0 cellspacing=5px
columnClasses=left top, left top
t:outputLabel for=infoId value=Options/
t:selectOneMenu id=infoId value=#{productBean.infoId}
onchange=submit() valueChangeListener=#{productBean.valueChangedHandler}
immediate=true
f:selectItem itemValue=-1 itemLabel=new short info/
f:selectItems value=#{productBean.shortInfoSelectItems}/
/t:selectOneMenu
t:outputLabel for=descText value=Description/
t:inputTextarea id=descText rows=8
value=#{productBean.description}/
t:outputLabel for=utilText value=Usage/
t:inputTextarea id=utilText styleClass=wXXXL rows=8
value=#{productBean.usage}/
/t:panelGrid
public class ProductBean {
private Long infoId;
private String description;
private String usage;
// setters and getters for the above properties
public void valueChangedHandler(ValueChangeEvent event) {
Long infoId = (Long) event.getNewValue();
if ((infoId != null) (infoId 0)) {
//DataService and ProductInfo are related to Hibernate
ProductInfo info = DataService.getProductInfo(infoId);
this.description = info.getDescription();
this.usage = info.getUsage();
}
}
}
Description and Usage properties can never be changed since they get
overwritten with the initial values.
:(
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: AW: VFS FTP Problem with Text data
Hi! Do you think that could be a feature for VFS to take care about conversion on heterogenous networks? I am not sure. VFS can't do it easily automatically. As far as I can see it is hard to determine the target OS through the filesystem layer. e.g. a smb connection do not necessarily mean that the source nor the target is a windows machine, it could also be a linux with samba running. So, what will be left is some sort of Input/OutputStream wrappers which can be configured accordingly, but then such streams are better located in commons-io - IMHO. Ciao, Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TOMAHAWK-774) Browser does not cache resources
[ http://issues.apache.org/jira/browse/TOMAHAWK-774?page=comments#action_12448135 ] Mario Ivankovits commented on TOMAHAWK-774: --- I found the same behavior, but its the AuthenticatorBase in Tomcat which tries to workaround a security hole that way. So this has nothing to do with dynamic content, or did you found another place where tomcat will do this? Browser does not cache resources Key: TOMAHAWK-774 URL: http://issues.apache.org/jira/browse/TOMAHAWK-774 Project: MyFaces Tomahawk Issue Type: Bug Components: ExtensionsFilter Affects Versions: 1.1.5-SNAPSHOT Reporter: Sascha Groß Priority: Critical Attachments: TOMAHAWK-774.patch Browser does not cache resources, because the Servlet-Container (Tomcat) add following HTTP-Headers for the dynamic Content (ExtensionsFilter) Pragma: no-cache Cache-Control: no-cache Patch will be added. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Core Release 1.1.5
Hi Wendy! If not, Core 1.1.5 can stay at Shared 2.0.4 and can use the same Shared branch as Tomahawk 1.1.4. Hmmm ... but shared will be copied into the core (or tomahawk) distribution - there is no shared.jar, so I see no advantage of *not* upgrading to the latest shared. This should not introduce a incompatibility with any other release. At least this was the idea. IMHO every release of tomahawk or core should always use the actual shared, in the worst case, shared should be released at the same time as core or tomahawk respectively. Ciao, Mario
[jira] Commented: (VFS-98) VFS causes deadlocks or is not thread-safe
[ http://issues.apache.org/jira/browse/VFS-98?page=comments#action_12447937 ] Mario Ivankovits commented on VFS-98: - Hi! I committed a fix for this hopefully. Could you please try it again. In case it hangs again please attach the stacktrace again, but not the jstack one, it doesn't contain enough informations. Thanks! Ciao, Mario VFS causes deadlocks or is not thread-safe -- Key: VFS-98 URL: http://issues.apache.org/jira/browse/VFS-98 Project: Commons VFS Issue Type: Bug Affects Versions: Nightly Builds Environment: jdk1.5.0_07 / Linux Reporter: Juha-Matti Toppinen Assigned To: Mario Ivankovits Attachments: vfs.dead.jstack.txt, vfs.dead.threaddump.synchronizedfileobject.txt, vfs.dead.threaddump.txt Newer versions of VFS seems to be unusable in multithreading environments, causing a deadlock of some kind. This causes my Java web server application to completely hang when there is many concurrent connections. My application uses a single FileSystemManager instance, and makes quite heavy use of VFS; opening many files from many threads simultaneously. I have tried, without success different workarounds based on some mailing list threads: - Using both NullReferenceFilesCache and the default SoftReferenceFilesCache. (SoftReferenceFilesCache seemed to sometimes cause some additional thread-related exceptions under heavy load, but propably unrelated to this issue) - Using the new SynchorizedFileObjectDecorator also did not help. On the contrary, it seemed to trigger the deadlock more easily. The version I have problems with is a nightly build: commons-vfs-20060831 The older version commons-vfs-20060115 works beautifully, but I would like to use newer version because I want to be able to use FileObject.refresh() to reset the internal state of files (specially, to get a fresh list of children). I hope the threading issues are going to be resolved in near future, and I am willing to help in any way. I do not have very deep experience about multithreading applications, so I wasn't able to get more close to the roots of the issue. Feel free to ask for more information. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: VFS FTP Problem with Text data
Hi Moerk! I tried to use vfs to get some textfiles from a unix host to a windows network drive on a regular basis. The problem is that the transfer program doesn't take care aobout the different CR (0x0A--0x0D 0x0A) commands between Unix and Windows I found that the FTP Conection is alwyas started in FTP.BINARY_FILE_TYPE) that doesn't support the conversion of CR in ftp. Eventually it is possible to extend the FtpFileSystemConfigBuilder with such an option, though, another possibility is to use a BufferedReader and a PrintWriter to do the conversation on client side, no? Simply readline the file and writeln it should do the trick too ... will work not only with ftp and in conjunction with an InputStreamReader you can deal with charset conversion at the same time ... Since the BufferedReader will use a (configureable) buffer to read the file there should be no huge performance penalty. What do you think? Ciao, Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (VFS-98) VFS causes deadlocks or is not thread-safe
[ http://issues.apache.org/jira/browse/VFS-98?page=all ] Mario Ivankovits resolved VFS-98. - Resolution: Fixed You are welcome :-) VFS causes deadlocks or is not thread-safe -- Key: VFS-98 URL: http://issues.apache.org/jira/browse/VFS-98 Project: Commons VFS Issue Type: Bug Affects Versions: Nightly Builds Environment: jdk1.5.0_07 / Linux Reporter: Juha-Matti Toppinen Assigned To: Mario Ivankovits Attachments: vfs.dead.jstack.txt, vfs.dead.threaddump.synchronizedfileobject.txt, vfs.dead.threaddump.txt Newer versions of VFS seems to be unusable in multithreading environments, causing a deadlock of some kind. This causes my Java web server application to completely hang when there is many concurrent connections. My application uses a single FileSystemManager instance, and makes quite heavy use of VFS; opening many files from many threads simultaneously. I have tried, without success different workarounds based on some mailing list threads: - Using both NullReferenceFilesCache and the default SoftReferenceFilesCache. (SoftReferenceFilesCache seemed to sometimes cause some additional thread-related exceptions under heavy load, but propably unrelated to this issue) - Using the new SynchorizedFileObjectDecorator also did not help. On the contrary, it seemed to trigger the deadlock more easily. The version I have problems with is a nightly build: commons-vfs-20060831 The older version commons-vfs-20060115 works beautifully, but I would like to use newer version because I want to be able to use FileObject.refresh() to reset the internal state of files (specially, to get a fresh list of children). I hope the threading issues are going to be resolved in near future, and I am willing to help in any way. I do not have very deep experience about multithreading applications, so I wasn't able to get more close to the roots of the issue. Feel free to ask for more information. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
