RE: Scanning for annotated classes in MyFaces 2
Hi! not sure on the PERF, but if it is really (proven) the case, I am with you. Well... startup time isn't really a big problem, right? :-) Is that ironic? In projects with 3000 classes and 60 jar files you are up to 30 seconds, or even more, scanning time. Under load, with shale, I saw scanning times of 60 seconds. This _will_ drive you crazy! Ciao, Mario
[jira] Commented: (VFS-106) VFS Truezip provider
[ https://issues.apache.org/jira/browse/VFS-106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12661856#action_12661856 ] Mario Ivankovits commented on VFS-106: -- commons-compress is on the way of providing writable zip support (and probably others), no need to get truezip into play here. Would be great if someone could have a at integrating commons-compress trunk into a new filesystem in vfs-sandbox. VFS Truezip provider - Key: VFS-106 URL: https://issues.apache.org/jira/browse/VFS-106 Project: Commons VFS Issue Type: New Feature Reporter: Filip Defoort Attachments: TzFileObject.java, TzFileProvider.java, TzFileSystem.java, vfs-tz.patch Attached is a quicky truezip provider to allow for read/write access to zip/tar/... archives. See https://truezip.dev.java.net/ for details on truezip. Let me know how you want to proceed with something like this. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
RE: Scanning for annotated classes in MyFaces 2
Hi! But there are some issues with this: First, what paths to scan? AFAIK the spec doesn't state the classpaths to scan. I suppose only /WEB-INF/lib and /WEB-INF/classes need to be checked, but I can't find it in the spec. What ever the spec says, we definitely should provide a configuration parameter in web.xml where one can configure the packages to scan, else startup times of your webapp will be VERY bad. I had this in the past with shale-annotation. There I added such configuration already. We can strip the scanning/parsing out there - I'll contribute if required. Ciao, Mario
RE: Scanning for annotated classes in MyFaces 2
-Original Message- From: Jan-Kees van Andel [mailto:jankeesvanan...@gmail.com] Sent: Wednesday, January 07, 2009 8:15 AM To: dev@myfaces.apache.org Subject: Re: Scanning for annotated classes in MyFaces 2 It might be smart to put this Shale code in a separate project. For example in Commons, since there are several Apache projects that need to scan for annotations, like EJB3 and JPA projects. Yeah, I thought the same too. What would be great would be some sort of annotation scanner where you can register a scanning job for system startup so that the classpath scanning has to take place only once and the scanning jobs get called back about the results. Sure, if a scanning job registers something like ** all packages get scanned and startup time is slow again, but this is on the responsibility of the developer then. I can help to startup a commons sandbox project and to work out a specification for the library, but my spare time for coding is very low :-( Ciao, Mario
RE: [VFS] tests and project status
Great to see that there is some development with VFS again! It's more motivating to work in a team :-) Thanks. I just set myself back a little bit though. It must be getting late. I have been trying to get the checkstyle reports to work and I somehow managed to remove trunk instead of target. Luckily I have time machine running but unfortunately my backup was from yesterday. Hopefully IntelliJ will help me restore the rest. Ouch, that sound really bad! Good look with IntelliJ. Ciao, Mario
RE: [VFS] tests and project status
Hi! From: tcu...@vafer.org [mailto:tcu...@vafer.org] On Behalf Of Torsten Curdt Sent: Monday, January 05, 2009 1:41 AM To: Commons Developers List Subject: Re: [VFS] tests and project status On Mon, Jan 5, 2009 at 00:43, Ralph Goers ralph.go...@dslextreme.com wrote: Is anyone actively working on commons-vfs? I have spent the last week making trunk actually run the unit tests that use a local file system with Maven 2 as well as getting it to run those pointed at a remote repository if the url property is defined in settings.xml. I have also added webdav using Jackrabbit and removed the webdav using Slide that was in the sandbox. I've still got some more things to do, but I would like to check this into trunk. I'm not sure who to ask for approval from since the last message regarding VFS in October indicated there weren't many (any?) active developers. Awesome news! Mostly Mario was working on it ...Mario? Yes, great news if the tests work with Maven 2 now. And sure, go on and commit those things! I'll run them against my vmware VFS test server then. Great to see that there is some development with VFS again! It's more motivating to work in a team :-) Ciao, Mario
[OT] Mesir
Hi! Just wanted to post a link to mesir [1]. Mainly a pom.xml and a few examples, but I like the idea of bundling all this together and state this a full stack. From the pom.xml I can say that we use many of these libraries already in our application and they turned out to be very stable. I think mesir is worth a look if you start a new project. Not sure if it is really a full JEE stack already, but the most important libraries are there. MyFaces Orchestra for example ;-) Ciao, Mario [1] http://code.google.com/p/mesir/ PS: I didn't send this mail to the MyFaces user group as I don't wanted to make it look like an official proposal of the MyFaces group. Not yet ...
RE: VFS - Could not load VFS configuration
Hi! org.apache.commons.vfs.provider.local.DefaultLocalFileProvider is a class in vfs core. For me it seems there is something wrong with your vfs core jar. Please check if the class is in there. Did you build the jar by yourself? Probably something went wrong during the build process. Ciao, Mario -Original Message- From: Per Hermansson [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 10, 2008 7:39 PM To: Commons Users List Subject: Re: VFS - Could not load VFS configuration Hi Thanks for your help but I've now tried to add all the jars mentioned on the homepage and I still get the same exception. /Per Mark Fortner wrote: It looks like your classpath doesn't include all of the vfs libraries. You might want to check to see that you have all dependent libraries. The VFS project page should give you a list of dependencies. Hope this helps, Mark On Wed, Dec 10, 2008 at 4:07 AM, Per Hermansson [EMAIL PROTECTED] wrote: Hi I'm having trouble using recent versions of Commons VFS. Current trunk gives the following error: org.apache.commons.vfs.FileSystemException: Could not load VFS configuration from jar:file:/media/Fort/per/program/backup/lib/commons-vfs-2.0- SNAPSHOT.jar!/org/apache/commons/vfs/impl/providers.xml. at org.apache.commons.vfs.impl.StandardFileSystemManager.configure(Standar dFileSystemManager.java:199) at org.apache.commons.vfs.impl.StandardFileSystemManager.init(StandardFile SystemManager.java:126) at org.apache.commons.vfs.tasks.VfsTask.resolveFile(VfsTask.java:53) ... Caused by: org.apache.commons.vfs.FileSystemException: Could not create file provider of class org.apache.commons.vfs.provider.local.DefaultLocalFileProvider. at org.apache.commons.vfs.impl.StandardFileSystemManager.createInstance(St andardFileSystemManager.java:477) at org.apache.commons.vfs.impl.StandardFileSystemManager.addProvider(Stand ardFileSystemManager.java:358) ... Caused by: java.lang.ClassNotFoundException: org.apache.commons.vfs.provider.local.DefaultLocalFileProvider at java.net.URLClassLoader$1.run(URLClassLoader.java:217) at java.security.AccessController.doPrivileged(Native Method) while the latest release (commons-vfs-1.0) works without error. Here is the ant script I've tested with project xmlns:vfs=antlib:org.apache.commons.vfs.tasks taskdef uri=antlib:org.apache.commons.vfs.tasks resource=org/apache/commons/vfs/tasks/antlib.xml classpath pathelement location=lib/commons-vfs-2.0-SNAPSHOT.jar/ pathelement location=lib/commons-logging-1.1.1.jar/ /classpath /taskdef target name=test vfs:copy src=lib destdir=lib2 / /target /project Does anyone know a solution to this? My environment: java version 1.6.0_0 IcedTea6 1.3.1 (6b12-0ubuntu6) Runtime Environment (build 1.6.0_0- b12) OpenJDK Client VM (build 1.6.0_0-b12, mixed mode, sharing) Apache Ant version 1.7.1 compiled on October 3 2008 Thanks /Per - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: VFS - Could not load VFS configuration
Me too. Probaby try it with Sun's JDK, or enable some sort of class loading debug (there might be a command-line switch to do so) with OpenJDK, probably you can find some more hints. According to [1] this java -verbose:class might do the trick. Ciao Mario [1] http://java.sun.com/developer/TechTips/2000/tt1128.html -Original Message- From: Per Hermansson [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 10, 2008 8:08 PM To: Commons Users List Subject: Re: VFS - Could not load VFS configuration Hi I've build it using mvn install from the core directory and I've verified that the class file is actually in the jar file. This problem might not be related to VFS but I can't understand what is causing it. Per Mario Ivankovits wrote: Hi! org.apache.commons.vfs.provider.local.DefaultLocalFileProvider is a class in vfs core. For me it seems there is something wrong with your vfs core jar. Please check if the class is in there. Did you build the jar by yourself? Probably something went wrong during the build process. Ciao, Mario -Original Message- From: Per Hermansson [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 10, 2008 7:39 PM To: Commons Users List Subject: Re: VFS - Could not load VFS configuration Hi Thanks for your help but I've now tried to add all the jars mentioned on the homepage and I still get the same exception. /Per Mark Fortner wrote: It looks like your classpath doesn't include all of the vfs libraries. You might want to check to see that you have all dependent libraries. The VFS project page should give you a list of dependencies. Hope this helps, Mark On Wed, Dec 10, 2008 at 4:07 AM, Per Hermansson [EMAIL PROTECTED] wrote: Hi I'm having trouble using recent versions of Commons VFS. Current trunk gives the following error: org.apache.commons.vfs.FileSystemException: Could not load VFS configuration from jar:file:/media/Fort/per/program/backup/lib/commons-vfs-2.0- SNAPSHOT.jar!/org/apache/commons/vfs/impl/providers.xml. at org.apache.commons.vfs.impl.StandardFileSystemManager.configure(Standar dFileSystemManager.java:199) at org.apache.commons.vfs.impl.StandardFileSystemManager.init(StandardFile SystemManager.java:126) at org.apache.commons.vfs.tasks.VfsTask.resolveFile(VfsTask.java:53) ... Caused by: org.apache.commons.vfs.FileSystemException: Could not create file provider of class org.apache.commons.vfs.provider.local.DefaultLocalFileProvider. at org.apache.commons.vfs.impl.StandardFileSystemManager.createInstance(St andardFileSystemManager.java:477) at org.apache.commons.vfs.impl.StandardFileSystemManager.addProvider(Stand ardFileSystemManager.java:358) ... Caused by: java.lang.ClassNotFoundException: org.apache.commons.vfs.provider.local.DefaultLocalFileProvider at java.net.URLClassLoader$1.run(URLClassLoader.java:217) at java.security.AccessController.doPrivileged(Native Method) while the latest release (commons-vfs-1.0) works without error. Here is the ant script I've tested with project xmlns:vfs=antlib:org.apache.commons.vfs.tasks taskdef uri=antlib:org.apache.commons.vfs.tasks resource=org/apache/commons/vfs/tasks/antlib.xml classpath pathelement location=lib/commons-vfs-2.0- SNAPSHOT.jar/ pathelement location=lib/commons-logging-1.1.1.jar/ /classpath /taskdef target name=test vfs:copy src=lib destdir=lib2 / /target /project Does anyone know a solution to this? My environment: java version 1.6.0_0 IcedTea6 1.3.1 (6b12-0ubuntu6) Runtime Environment (build 1.6.0_0- b12) OpenJDK Client VM (build 1.6.0_0-b12, mixed mode, sharing) Apache Ant version 1.7.1 compiled on October 3 2008 Thanks /Per -- -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: VFS - Could not load VFS configuration
Yes, but don't forget to attach a patch :-) Ciao, Mario -Original Message- From: Per Hermansson [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 10, 2008 11:31 PM To: Commons Users List Subject: Re: VFS - Could not load VFS configuration I think I found the problem (context classloader). Reverting rev 537717 seems to solve my issue. Should I open an issue about this? Per Mario Ivankovits wrote: Me too. Probaby try it with Sun's JDK, or enable some sort of class loading debug (there might be a command-line switch to do so) with OpenJDK, probably you can find some more hints. According to [1] this java -verbose:class might do the trick. Ciao Mario [1] http://java.sun.com/developer/TechTips/2000/tt1128.html -Original Message- From: Per Hermansson [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 10, 2008 8:08 PM To: Commons Users List Subject: Re: VFS - Could not load VFS configuration Hi I've build it using mvn install from the core directory and I've verified that the class file is actually in the jar file. This problem might not be related to VFS but I can't understand what is causing it. Per Mario Ivankovits wrote: Hi! org.apache.commons.vfs.provider.local.DefaultLocalFileProvider is a class in vfs core. For me it seems there is something wrong with your vfs core jar. Please check if the class is in there. Did you build the jar by yourself? Probably something went wrong during the build process. Ciao, Mario -Original Message- From: Per Hermansson [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 10, 2008 7:39 PM To: Commons Users List Subject: Re: VFS - Could not load VFS configuration Hi Thanks for your help but I've now tried to add all the jars mentioned on the homepage and I still get the same exception. /Per Mark Fortner wrote: It looks like your classpath doesn't include all of the vfs libraries. You might want to check to see that you have all dependent libraries. The VFS project page should give you a list of dependencies. Hope this helps, Mark On Wed, Dec 10, 2008 at 4:07 AM, Per Hermansson [EMAIL PROTECTED] wrote: Hi I'm having trouble using recent versions of Commons VFS. Current trunk gives the following error: org.apache.commons.vfs.FileSystemException: Could not load VFS configuration from jar:file:/media/Fort/per/program/backup/lib/commons-vfs-2.0- SNAPSHOT.jar!/org/apache/commons/vfs/impl/providers.xml. at org.apache.commons.vfs.impl.StandardFileSystemManager.configure(Standar dFileSystemManager.java:199) at org.apache.commons.vfs.impl.StandardFileSystemManager.init(StandardFile SystemManager.java:126) at org.apache.commons.vfs.tasks.VfsTask.resolveFile(VfsTask.java:53) ... Caused by: org.apache.commons.vfs.FileSystemException: Could not create file provider of class org.apache.commons.vfs.provider.local.DefaultLocalFileProvider. at org.apache.commons.vfs.impl.StandardFileSystemManager.createInstance(St andardFileSystemManager.java:477) at org.apache.commons.vfs.impl.StandardFileSystemManager.addProvider(Stand ardFileSystemManager.java:358) ... Caused by: java.lang.ClassNotFoundException: org.apache.commons.vfs.provider.local.DefaultLocalFileProvider at java.net.URLClassLoader$1.run(URLClassLoader.java:217) at java.security.AccessController.doPrivileged(Native Method) while the latest release (commons-vfs-1.0) works without error. Here is the ant script I've tested with project xmlns:vfs=antlib:org.apache.commons.vfs.tasks taskdef uri=antlib:org.apache.commons.vfs.tasks resource=org/apache/commons/vfs/tasks/antlib.xml classpath pathelement location=lib/commons-vfs-2.0- SNAPSHOT.jar/ pathelement location=lib/commons-logging- 1.1.1.jar/ /classpath /taskdef target name=test vfs:copy src=lib destdir=lib2 / /target /project Does anyone know a solution to this? My environment: java version 1.6.0_0 IcedTea6 1.3.1 (6b12-0ubuntu6) Runtime Environment (build 1.6.0_0- b12) OpenJDK Client VM (build 1.6.0_0-b12, mixed mode, sharing) Apache Ant version 1.7.1 compiled on October 3 2008 Thanks /Per -- -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED
RE: [VOTE] Release of Extensions Validator 1.1.1
+0 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gerhard Petracek Sent: Thursday, December 04, 2008 12:01 PM To: MyFaces Development Subject: [VOTE] Release of Extensions Validator 1.1.1 Hi, I was running the needed tasks to get the 1.1.1 release of Apache MyFaces Extensions Validator out. The artifacts are deployed to my private Apache account ([1]). Please take a look at the 1.1.1 artifacts and vote! Please note: This vote is majority approval with a minimum of three +1 votes (see [2]). [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Gerhard [1] http://people.apache.org/~gpetracek/myfaces/extval/release_candidate/1_1_1/ [2] http://www.apache.org/foundation/voting.html#ReleaseVotes
RE: [OT] Babs Books
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Are there also MyFaces diapers available, that would be the perfect present for my newborn child this year ;-) cool. congrats! is is a wernER or wernSIE ? ROFL Werner, whats up? Why haven't you notified us? Congrats! :-) Hope, you still get some sleep. Ciao, Mario
RE: New MyFaces PMC chair
Welcome Mr. President! -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Manfred Geiler Sent: Thursday, November 20, 2008 10:08 AM To: MyFaces Development Subject: New MyFaces PMC chair Please welcome our new MyFaces PMC chair Matthias Wessendorf! As some of you already might know, I had decided to step down as the chair. The MyFaces PMC members then voted for Matthias Wessendorf as the successor and yesterday the board approved the change. Matthias, thanks for beeing up to that job. I personally have great confidence in you and wish you all the best for guiding us into the JSF 2.0 era. Regards, Manfred Geiler
RE: New MyFaces PMC chair
The old JFK one … ;-) From: Bruno Aranda [mailto:[EMAIL PROTECTED] Sent: Thursday, November 20, 2008 1:21 PM To: MyFaces Development Subject: Re: New MyFaces PMC chair Congratulations!! Is it a wood chair or a metal chair? Bruno 2008/11/20 Hazem Saleh [EMAIL PROTECTED]mailto:[EMAIL PROTECTED] Congratulations! On Thu, Nov 20, 2008 at 11:42 AM, Mario Ivankovits [EMAIL PROTECTED]mailto:[EMAIL PROTECTED] wrote: Welcome Mr. President! -Original Message- From: [EMAIL PROTECTED]mailto:[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]mailto:[EMAIL PROTECTED]] On Behalf Of Manfred Geiler Sent: Thursday, November 20, 2008 10:08 AM To: MyFaces Development Subject: New MyFaces PMC chair Please welcome our new MyFaces PMC chair Matthias Wessendorf! As some of you already might know, I had decided to step down as the chair. The MyFaces PMC members then voted for Matthias Wessendorf as the successor and yesterday the board approved the change. Matthias, thanks for beeing up to that job. I personally have great confidence in you and wish you all the best for guiding us into the JSF 2.0 era. Regards, Manfred Geiler -- Hazem Ahmed Saleh Ahmed Author of (The Definitive Guide to Apache MyFaces and Facelets): http://www.amazon.com/Definitive-Guide-Apache-MyFaces-Facelets/dp/1590597370 Web blog: http://www.jroller.com/page/HazemBlog [Web 2.0] Google Maps Integration with JSF: http://code.google.com/p/gmaps4jsf/ http://www.theserverside.com/news/thread.tss?thread_id=51250
RE: [Continuum] up? or down?
At least, I can't access it either. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matthias Wessendorf Sent: Thursday, November 20, 2008 1:33 PM To: MyFaces Development Subject: Re: [Continuum] up? or down? http://myfaces.zones.apache.org:8080/ is that only down behind my firewall ? -M On Tue, Nov 18, 2008 at 10:26 AM, Matthias Wessendorf [EMAIL PROTECTED] wrote: hrm looks like the project builds is fine... just some (maven|minor|random) issue on the (trinidad) site... -M On Tue, Nov 18, 2008 at 10:07 AM, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi, I don't see mails from the continuum server recently. In the past we saw them once in a while. The server is up, but looks like the old password (for me) doesn't work. Was there an update on the machine ? Looks like the site build isn't working as well. Does one know more? Thanks! Matthias -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
RE: SVN question
Probably something went wrong during the copy process and you have old .svn directories in the structure. Check the content of the files in the .svn directory in trinidad-1.0.10/trinidad-api and check if the url points to the correct svn path and not to the trunk or any other tag path. Ciao, Mario -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matthias Wessendorf Sent: Tuesday, November 11, 2008 11:28 AM To: MyFaces Development Subject: SVN question Hi, a little quiz. I got this output, from my lovely svn tool... svn: Commit failed (details follow): svn: File '/repos/asf/myfaces/trinidad/tags/trinidad-1.0.10/trinidad- api/pom.xml' already exists However, as a matter of fact, there is nothing like this: http://svn.apache.org/viewvc/myfaces/trinidad/tags/ So, I am really really wondering, what is wrong here... Any hint is totally appreciated! -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
RE: Defining and Adding a new provider to the apache VFS api
Hi! I need to know how to define and add a new provider to the api? I mean which classes do I need to extend and implement to create a new provider? Have a look at the VFS sandbox and e.g. the mime or webdav provider. Base directory: vfs\sandbox\src\main\java\org\apache\commons\vfs\provider Simply checkout vfs from http://svn.apache.org/repos/asf/commons/proper/vfs/trunk to get access to it. There you will also find a vfs-providers.xml which you have to provide to give VFS a clue where to find your provider and which namespace to use to access it. Basically you have to provide implementations of * AbstractFileObject (including the FileObject interface) * AbstractFileSystem (including the FileSystem interface) * AbstractOriginatingFileProvider (including the FileProvider interface) When looking at the sandbox it sould become clear what to do. Unhappily there is no wiki which describes these steps in every detail. Ciao, Mario
RE: [orchestra flow] support JSF1.2 only?
+1 -Original Message- From: Simon Kitching [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 04, 2008 12:15 PM To: MyFaces Development Subject: [orchestra flow] support JSF1.2 only? Hi, Currently orchestra-flow 0.0.1 supports JSF1.1. However in order to allow pages that declare orchestra flows to be *included* in other pages, eg ui:include src=somePageThatCallsAFlow ui:param name=vname value=value/ /ui:include the EL expressions in the included page need to be build using the correct ELContext object (otherwise they cannot see the params). Rather than build some kind of reflection-based solution, it would be simpler to just ditch JSF1.1 support for orchestra-flow. Note that there are no plans to ditch JSF1.1 support for orchestra-core .. Any objections? Regards, Simon. -- -- Emails in mixed posting style will be ignored -- (http://en.wikipedia.org/wiki/Posting_style)
RE: [configuration] Interface vs class
Hi! Look through the archives, the discussion with pros and cons went on promoting commons-proxy. Yes they did! I remember it well and I hated using a class rather than an interface. However, I can see the merit in the decision when it comes to maintenance and backward compatibility. As a purist, it just hurt! ;) Yep, sooner or later it hurts. Everytime I cross the bridge having the requirement to create a facade or proxy for a class based on just an abstract class it is a pain in the a*. Sooner or later you'll find methods with an implementation in there and then you'll face any sort of problem. JSF is a very good (or bad) example where over the time it gets harder and harder to extend from a grown abstract base class. Java itself has some interesting classes, e.g. Authenticator or SSLSocketFactory. Stuff I had to deal with today. Having an interface (which is extensible too, just extend an interface from another one) makes this much more cleaner. Any problem after an upgrade (major release upgrade for sure) the compiler will complain. Having abstract basis classes you can avoid this, but your application might fail on runtime later ... or not ... depending what you use from the inherited class. If you inherit from an interface you can be sure that you fulfill the contract of the library, an abstract class can change without any notice. For me, the trend to abstract basis classes are a bad thing. Ciao, Mario
RE: [Orchestra] Drawbacks of Orchestra I'd like to discuss
Hi! The problem is, that it is hard to ensure having a stopConversation for each startConversation, and what about reloading the page where possibly the startConversation gets called twice. Well, if I'm not completely mistaken, you also have to invalidate all Orchestra conversations manually by now. Well, for conversation.access this is no problem, they die with any request not accessing any bean in the conversation. For manual-scoped conversations, this is true. However due to the map based approach, the impact of not having a converation closed is much less, and if the user navigates back it can resume the work automagically. Manual conversations also have a timeout; when not used for a while they are garbage-collected. Will this work as well in your approach? The not used thing won't work so well, yes? I don't see the point, why forcing the user to stop the conversation manually is a problem. Normally the user wont play nicely - and a web application should not force the user to do so. But, to say the truth, we often use the conversation.access for the persistence stuff and conversation.manual for storing non-persistence state of the conversation which allows to restart easily. This gives the user a great application experience I think. Reloading the page, however, doesn't matter. Well, of course, it creates another conversation but sooner a later a timeout will invalidate the one that has been created first. But then you can not talk about nested conversations, then you too have the same flat structure as Orchestra has by today. When you talk about nested conversation you normally also mean to invalidate all child conversations once the parent timeout. This clearly can not work for your scenario. So you too have to distinguish between nested conversations and start a new conversation. Currently nested conversations are supported through Orchestra Flow ... which also requires some sort of configuration/convention for the flow demarcation. Another problem ist that not each and every page-flow is triggered by a navigation-handler event, what about get requests - e.g. from the main menu. The NavigationHandler was just supposed to be an example. However, somewhere, of course, you have to implement that logic, i.e. some callback method is needed in order to handle the conversation selection, for example, you could use a ViewController for GET Requests. But then again you do not know if you'd like to start or end a conversation without specific external configuration. You can not state this as implementation detail. Starting and ending a conversation in a reasonable and controlled way is what it is all about. Orchestra just allowes to handle it in a less hot way. Of course, it's best practice not to pass any entities between Orchestra conversations, but that's just true because each Orchestra conversation has got its own persistence context. Seperating conversations and persistence contexts allows you to use the conversation scope in a more fine-grained way (for example, I'd like to reset filter criteria of a search conversation without closing the persistence context). How many levels do you want the developer to keep in mind? If you separate the conversation from the persistence scope you also have to be aware that, once the persistence context dies all the conversation cached in a conversation bean is detached. Creating a new persistence scope and pulling in conversation beans with entites loaded using another persistence scope will not work. The only workaround is to NOT cache any entity in the conversation bean and look it up from the persistence context each and every time. Which is doable, for clustering probably needed, but hard to code. And yes, the reset filter criteria is just what is easily possible (and used) with orchestra. Simply invalidate the conversation which holds the criteria. BTW: This conversation lives in a scope which does not use any persistence context at all here. This is just a matter of scope configuration. You could count it as example 3 of things I don't like in Orchestra. I have to use a single persistence context for a certain dialog (I'm calling it dialog now so that you don't mix it up with Orchestra conversations). Now I'd like to split this dialog into seperate conversations, but I can't because I have to reuse the persistence context so I'm actually reseting some values manually. :-f This is just not true, you can use as many persistence contexts as you would like to. You just have to be aware how to pass information from one conversation to another one. That you should not pass entities between persistence contexts is a limitation of the persistence framework - and nothing which is a real problem in any application, is it? I don't know what you mean by split this dialog as no persistence framework allows you to split its session, but if you'd like to push the data to other
RE: [orchestra] [VOTE] Orchestra Core 1.3 Release
+1 -Original Message- From: Simon Kitching [mailto:[EMAIL PROTECTED] Sent: Friday, October 24, 2008 11:27 AM To: MyFaces Development Cc: MyFaces Discussion Subject: [orchestra] [VOTE] Orchestra Core 1.3 Release Hi All, A release-candidate has been prepared for Orchestra Core 1.3. The release-candidate source is currently at: http://svn.apache.org/repos/asf/myfaces/orchestra/branches/core-1_3- prepare and will be moved to tags dir when/if the release vote passes. The artifacts have been deployed to the staging repository here: http://people.apache.org/builds/myfaces/m2-staging- repository/org/apache/myfaces/orchestra/myfaces-orchestra-core/1.3/ Sorry about the .asc.asc.* files; please ignore those and I will remove them before deploying the final artifacts to the central repo. The latest maven-clirr-report plugin unfortunately crashes on orchestra, but I have created a report using clirr trunk; please see here: http://people.apache.org/~skitching/orchestra-core-1.3/clirr- orchestra-1.2-to-1.3.txt Javadocs etc for this release can be found here: http://people.apache.org/~skitching/orchestra-core-1.3/myfaces- orchestra-core-1.3/site/ The release notes from this version can be found at: http://svn.apache.org/repos/asf/myfaces/orchestra/branches/core-1_3- prepare/RELEASE-NOTES.txt Please have a look at these artifacts and vote: [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Regards, Simon -- -- Emails in mixed posting style will be ignored -- (http://en.wikipedia.org/wiki/Posting_style)
AW: [Orchestra] Drawbacks of Orchestra I'd like to discuss
Hi! Example 1) I've developed some views for a search dialog that I wanted to use in at least two different conversations. Everything worked fine for the first conversation. The following code listing should give you an idea of the problem. Simon developed Orchestra Flow which might solve this problem as it creates an all new conversation context for this flow and thus can reuse the conversation setup. Simon is still working on it to make it work with our latest requirements, but it should work for many use-cases already. I am not sure if there is a detailed documentation already. Example 2) In a different part of the same application I've created a view that should serve for three different usecases. Basically the view doesn't change for these usecases at all, but the logic of the backing bean does. My first approach was to determine the specific page bean at runtime in the action method that navigates to this view. This action method was supposed to register the specific page bean under a common name. So somehow it can be said that I wanted to use polymorphic beans. You might treat it as workaround (which you don't want to hear), but the latest Orchestra provides the method convObject = ConversationUtils.bindToCurrent(object) which allows you to attach all the aspects to any bean you'd like to. Allowing to use that from within the spring configuration is on our todo list. I don't want to hear anything about certain workarounds that I could have used in these cases as I think that these usecases aren't exceptional enough to justify workarounds. It is hard to know what you treat as workaround and what we treat as by design ;-) However, the missing flow part is nearly there and already usable. Summarizing it can be stated that I'd propose you to rewrite conversation handling for the next major release and I'd be willing to contribute. Note that I don't want to drop support for these named conversations, but I think that this usecase is not the default one for conversations. I know from the past that you would like to rewrite this stuff, but I've never seen a proposal what exactly and how. Don't get me wrong, but if you'd like to make the naming-conversation-way optional you need another way how to deal with the persistence context. Orchestra IS different to Seam here and probably different to Webflow. If the naming-conversations are exceptional ... I don't know, we use it heavily, and now with Orchestra Flow the last missing bit has been developed and Orchestra fits VERY nicely within our application. Probably how we built our application is exceptional (for the good and the bad ;-) ) Well, now with Orchestra Flow it might be possible to reach what you want. If I understood that right. You'd like to have a single conversation active for the request instead for a bean. So, creating a SingleConversationScope, this scope then should hold the persistence context in the conversationContext and bind/unbind it on request start/end. Different conversations then are only possible by utilizing Orchestra Flow. How parallel running conversations should work in such a setup, I don't know yet ... Ciao, Mario
Re: [Orchestra] Drawbacks of Orchestra I'd like to discuss
Hi!
Example 1)
I've developed some views for a search dialog that I wanted to use in at
least two different conversations. Everything worked fine for the first
conversation. The following code listing should give you an idea of the
problem.
However (as noted in my other email) flow won't solve this issue. In
fact it sets up even more strict isolation between caller and called
views - deliberately. The called view cannot access any
conversation-scoped data except its own - and whatever parameters it
gets explicitly passed.
I thought Bernhard is searching a way how to do solve this problem, and
Orchestra Flow clearly shows how to solve the search-flow-use-case without
having to build your own parameter passing framework.
For me it was clear that passing entities between conversations is a no-go; as
with any framework which allows multiple persistence context.
Example 2)
In a different part of the same application I've created a view that
should serve for three different usecases. Basically the view
doesn't
You might treat it as workaround (which you don't want to hear),
but the latest Orchestra provides the method
convObject = ConversationUtils.bindToCurrent(object)
which allows you to attach all the aspects to any bean you'd like to.
Allowing to use that from within the spring configuration is on our
todo list.
I'm not sure how the new Conversationutils.bindToCurrent would help
here..
In your main bean you can have this switch/case to create the bean and put it
into a specific conversation, your main bean then provides a method like
getImplementation.
In your view then you write #{mainBean.implementation.xyz}.
The SingleConversationScope class was recently deleted from Orchestra -
as discussed on the list. Partly because there did not seem to be any
use-case that it was useful for.
We can resurrect it if such a use-case is found. But I don't understand
the above description...how exactly does it solve the two issues that
Bernhard had?
From discussions in the past with Bernhard I got the feeling that he don't
like the multiple-conversations per request approach. Which forced us to
create something like the view-controller scope, however, I still see no way
around that. Having the request conversation defined by the view controller
is the best we can do I think.
Ciao,
Mario
RE: [Orchestra] Drawbacks of Orchestra I'd like to discuss
Hi! Well, basically I'd refactor the ConversationContext so that it's actually the main conversation of Orchestra. The conversation itself is almost independent of Spring (of course, there's still an according implementation of the Scope interface, but it will be implemented way easier). It's possible to nest conversations, i.e. a there's a certain hierarchy of conversations. The main problem I see with this approach is that you HAVE to use a flow definition, else Orchestra has no chance to determine when to end a conversation and when to reuse the current one. In a web-application, where you have global menues where the user is able to suspend the current conversation and jump right to the start of another one (or resume it) it is hard to find the conversation demarcation without a flow description. In fact I tried such thing in Orchestra BEFORE I started to go the named-conversation way. Orchestra just fits way better with this free-floating-named-conversations in our application. As far as I know Spring WebFlow is such a system and is able to deal with persistence contexts already. Each conversation has got it's own lifecycle and therefore it's possible to register so-called conversation listeners in order to hook logic into such lifecycle phases. Some of the events you outlined are already there in Orchestra. Also using Orchestra without persistence at all works great, on a per-scope-configuration basis! Still, the beauty of Orchestra is that it supports use-cases like: 1) Doing Order-Processing 2) Suspend task 1 and do some different things like, update customers master-data 3) Go back to Order-Processing and continue All this works without a single line of flow-description and by nicely separate the persistence contexts, so the memory of task 2 has been freed while task 1 is stil there. Also no user-interaction is required (pause, restart, etc) and no other sort of convention. On top of THAT we built the flow, so each flow separates even more by still keeping the easy-to-use multiple conversation feature. Where a flow is required (e.g. search-pages) you can use them now. So, it is not only using two conversations during the same render-request, no, it is about using different parallel conversations for different tasks without additional configuration on view level. In fact, if one finds a method how Orchestra can determin what is the CURRENT conversation we could get rid of the viewController-scope, but since Orchestra talks about beans and not about views in its innerst, that is hard to find. For me the single-conversation approach looks like a limitation, which to break out requires a flow-description. Sorry, at all it is hard for me to see what is better to do it like Spring WebFlow. Ciao, Mario
Re: [orchestra] release orchestra-core version 1.3?
Hi! Great! I think it is a good time to make another Orchestra Core release. There is nothing radical in this new version, Yep, the radical stuff is kept for the next version ;-) Ciao, Mario
Re: tomahawk examples design proposal
Hi! +1 to number one. Ciao, Mario
RE: [Orchestra] SpringSingleConversationScope
Hi! A while ago you added class SpringSingleConversationScope to orchestra with the comment Mostly useful for dialog/flow frameworks. The idea was that a dialog can have only one conversation. I can't remember why we/I thought that we require that. Now that it works without this limitation I am fine if you remove that class. Ciao, Mario
Re: Bug in ApplicationImpl
Hi! This used to work in MyFaces 1.1, but in 1.2 it looks like the fact that my type is an enum takes precedence over the fact that it implements EnumCoded interface, so I end up with the built-in EnumConverter instead of my GenericEnumTypeConverter. Of course this issue was not relevant in JSF1.1, as java1.5 native enums were not supported (JSF1.1 is java1.4-compatible). But for JSF1.2, it makes a lot of sense to check for an optional interface first. Shouldn't that be specified by the spec? Is this a spec bug? I mean, things like that are very important for a JSF application to rely on to work correctly between various JSF implementations. Ciao, Mario
Re: Tomahawk sandbox release (was Re: [ANNOUNCE] Release of Tomahawk 1.1.7)
Hi! If people are happy with adding a note to the tomahawk sandbox page as described above then I'll do it. I'd prefer this mark buoy. Ciao, Mario
[jira] Resolved: (VFS-218) .skip() always returns the same number as given as parameter while the stream itself may or may not skip to given position
[
https://issues.apache.org/jira/browse/VFS-218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Ivankovits resolved VFS-218.
--
Resolution: Invalid
Hi!
... and so does this code snippet
{code}
FileInputStream fis = new FileInputStream(C:/temp/bla.txt);
long skipped = fis.skip(9L);
System.out.println(skipped+ = prints 9, this should be 6 as
per javadoc's specification; +
http://java.sun.com/j2se/1.5.0/docs/api/java/io/InputStream.html#skip(long));
{code}
And this is due to a bug/feature in java [1] which has already been added to
the documentation of FileInputStream [2].
Clearly, FileInputStream breaks the contract of its interface.
Seems like you are out of luck.
Ciao,
Mario
[1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6294974
[2] http://java.sun.com/javase/6/docs/api/java/io/FileInputStream.html
.skip() always returns the same number as given as parameter while the stream
itself may or may not skip to given position
--
Key: VFS-218
URL: https://issues.apache.org/jira/browse/VFS-218
Project: Commons VFS
Issue Type: Bug
Affects Versions: 1.0
Environment: Java 5, using jdk1.6.0_06 on Windows XP SP3
Reporter: Not Telling
The code below should reproduce the bug, so far I've tested this with file:
and res: file systems and at least those two expose this bug. As you may
notice from the source, you should have file called bla.txt containing
blabla (6 characters) in your C:\temp\ folder for this.
{code:title=VFSStreamSkipping.java}
import java.io.IOException;
import java.io.InputStream;
import org.apache.commons.vfs.FileObject;
import org.apache.commons.vfs.FileSystemException;
import org.apache.commons.vfs.FileSystemManager;
import org.apache.commons.vfs.VFS;
/**
* This class demonstrates buggy behaviour of .skip() when using VFS.
* The bug is that no matter how many bytes were actually skipped, .skip()
* always returns the same number as the user tried to skip. The stream itself
* may get skipped though, if one tries to read the stream in this example
* after .skip(), it will return -1 indicating that .skip() was executed
* properly.
*/
public class VFSStreamSkipping {
public static void main(String[] args) {
FileObject file;
FileSystemManager fsm;
try {
fsm = VFS.getManager();
} catch (FileSystemException e) {
fsm = null;
}
InputStream is = null;
try {
file = fsm.resolveFile(file:C:/temp/bla.txt);
// file content is simply blabla with no \n or \r
is = file.getContent().getInputStream();
} catch (FileSystemException e) {}
try {
long skipped = is.skip(9L);
System.out.println(skipped+ = prints 9, this should
be 6 as per javadoc's specification; +
http://java.sun.com/j2se/1.5.0/docs/api/java/io/InputStream.html#skip(long));
System.out.println(is.read());
} catch (IOException e) {}
}
}
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[orchestra] Re: a4j:commandButton break orchetra conversation?
Hi! I use richfaces 3.1.4, myfaces orchestra 1.2,myfaces 1.1.5, We use RichFaces 3.2.1 with Orchestra without any problems, even with ajax. I can't say much about 3.1.4, though. To mask sure a a4j request will break orchestra conversation, I build a demo project, here are the code segment. As long as JSF 2.0 isn't out of the door the different ajax implementations will make us headache. However, Simon committed a patch yesterday which probably sovles your problem. Simon changed the way how Orchestra detects that access scoped beans have to be discarded. Would it be possible for you to try the latest Orchestra svn head version? You can find a nightly build here [1]. But I don't know if it is actual enough ... looks like one day behind to me. Best will be to build from source as described here [2]. Ciao, Mario [1] http://people.apache.org/repo/m2-snapshot-repository/org/apache/myfaces/orchestra/ [2] http://myfaces.apache.org/orchestra/download.html
Re: [VOTE] Orchestra core 1.2 release candidate 1 available
+0 No chance to look at it for me now, but I trust that you did a good job again :-) Ciao, Mario On Tue, 2008-07-15 at 23:03 +0200, simon wrote: Hi All, The release candidate for MyFaces Orchestra Core 1.2 can be found in the following places: Download bundles: http://people.apache.org/~skitching/orchestra-core-1.2/ Maven staging repository: http://people.apache.org/builds/myfaces/m2-staging-repository/org/apache/myfaces/orchestra/myfaces-orchestra-core/1.2/ Please have a look at these artifacts and vote: [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released (and reason why) Note that I will be on holiday until Monday 15 July, so there is no hurry :-) I hope it was just the fact that I forgot to put [VOTE] in the subject line which lead to the lack of response...(now fixed). The release candidate is still out there waiting for a few kind souls to review BTW, the release notes can be found here: http://svn.apache.org/repos/asf/myfaces/orchestra/branches/prepare_core12/RELEASE-NOTES.txt Regards, Simon
Re: [VFS] How to use operations
Hi! 1. Do you have any mechanism in mind to give feedback on the result of the operation? Not yet, this is all work in progress. But probably changing the FileOperation interface to ProcessReturn process() and add a new ProcessReturn interface with. boolean isCorrect(); int getReturnCode(); 2. Should the FileOperations.getOperations() method return a list of interfaces or a list of implementing classes? Also not that easy to answer. At the moment I think we should return a list of interfaces as a concrete implementation might implement different interfaces. Ok, no I am on vacation for two weeks. I hope this is sufficient for now, I'll catch up after my vacation with your current status. I am looking forward to it :-) Ciao, Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Orchestra] javax.faces.application.ViewExpiredException after session timeout
Hi!
I am using MyFaces+RichFaces+Orchestra
When I update from Orchestra 1.0 to 1.1, I am getting
javax.faces.application.ViewExpiredException: /pages/dms/dms_overview.jsfThe
expected view was not returned for the view identifier:
/pages/dms/dms_overview.jsf
I guess you are using MyFaces 1.2.x or JSF 1.2.x.
This is the normal problem you'll experience when the session times
out. I don't see how Orchestra 1.0 did help to solve that problem.
Probably you changed the JSF version lately? If I remember correctly
previous JSF versions just re-rendered the page.
Anyway, if possible use the a4j poller which helps keeping the session
alive as long as the user is on the page. This allows you to use a very
short session timeout, but keeping it alive as long as the user did not
close the browser or left your web application at all.
Something like this will do the trick:
a4j:region renderRegionOnly=true
h:form id=_pingForm
a4j:poll id=ajaxPoller
interval=1
reRender=ajaxPollerResult,ajaxPollerCounter
action=#{ping.pollAction}
timeout=1/
/h:form
/a4j:region
And gives another piece of real rich-client feeling :-)
Ciao,
Mario
Re: [Orchestra] javax.faces.application.ViewExpiredException after session timeout
Hi! I am absolutely sure, that it works with myfaces-orchestra-core-1.0.jar - I need only to replace the .jar to see the difference! Nothing else changes! Strange, I have no clue why Orchestra 1.0 will avoid this problem. Unfortuantly, we can not allow the user to stay online all the time. Each opened session consumes memory (we have many statefull beans with session life time). I understand, but notice: Using the poller keeps the session open only as long as a browser is pointing to your application. On the other hand, once the browser has been closed the session can die much faster. If the session scoped beans are a problem think about putting them into a separate (probably non-persistence-linked) conversation.manual scope. If accessed every now and then it lives as long as the session. Together with the poller then, the conversation.manual scope is able to timeout and release memory, but the session is still alive with just a handful of data in it. I do it that way with our application. Can you explain pls, why It works, if I use navigation with navigation-case without redirect / and does not work wit redirect /? No, I can't. Are you using client-side state saving? Probably without redirect / JSF is able to restore itself to the point where it is possible then to render again, though, it should not work either I think. Do you have any chance to try the JSF RI Mojarra? Just wondering if it makes any difference there too. Is there any workaround to generally avoid this exception or to handle it correctly? Probably you can configure an error handler for this exception in your web.xml (I think it is called error-type where you can configure an error page per exception) and explain the user that the session has expired. Ciao, Mario
Re: Orchestra core 1.2 release candidate 1 available
Hi! Note that I will be on holiday until Monday 15 July, so there is no hurry :-) Monday OR 15 July, both together will not be possible ;-) Well, and even 15 July might be a VERY short vacation. *hehe* Thanks or the work, I'll look at the artifacts in the next few days, before my vacation :-D *yes* Ciao, Mario
Re: [VFS] How to use operations
Hi! I am just curious if anyone else has ever used them and how they did it. I am not sure, this is some of the last things I added (with the help of a contributor) but didn't finished it, nor documented it :-( *help* Is the only use of them when you create your own client that knows about your own operations? Or should any VFS client (e.g. JCommander) know how to discover which operations exist, select one, configure it and execute it? The idea is to being able to lookup abstract operations. For example the update operation and VFS returns a CsvUpdate or SvnUpdate depending on the used implementation. As far as I remeber there is a way to list all file operations. A tool like JCommander than can use reflection to get an idea of which configuration options are available and can present a user a list then. Ciao, Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VFS] How to use operations
Hi! As long as you use a standard set of annotations, that would be great. I only mentioned the Javabeans method because there are already components out there that can edit a Javabean given its BeanInfo object. Its fine! Probably using BeanInfo would be a good first step, afterwards we can see if there exists a standard set of annotations. Ciao, Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] release orchestra parent pom version 1.2
+1 simon schrieb: Hi All, I'd like to release a new parent pom for the Orchestra project. You can find the artifact here: http://people.apache.org/builds/myfaces/m2-staging-repository/org/apache/myfaces/orchestra/myfaces-orchestra-maven/1.2/ and the svn tag here: http://svn.apache.org/repos/asf/myfaces/orchestra/branches/prepare-maven-1_2/ The major differences are: * some website updates * use version 6 of parent pom rather than version 5 * enable checkstyle rules As with all parent-pom releases, this of course does not affect any existing software; things need to explicitly point at the new version before they pick up any of these changes. +1 from me of course Regards, Simon -- mit freundlichen Grüßen Mario Ivankovits Software Engineering OPS EDV VertriebsgesmbH A-1120 Wien, Michael-Bernhard-Gasse 10 Firmenbuch Nr.: FN51233v, Handelsgericht Wien Tel.: +43-1-8938810; Fax: +43-1-8938810/3700 http://www.ops.co.at E-Mail: [EMAIL PROTECTED] Skype: mario_ivankovits
Re: Dojo discussion - opensourcing the jsf dojo components project
Hi! Werner Punz schrieb: Martin Marinschek schrieb: In any case, I remain -1 to add a new component library - I am sorry. Ok I am going to postpone this discussion until I can showcase something then we can start it over... Hmm ... was Martin's -1 a veto or did he just express his opinion. Martin, how do we have to count your -1? Ciao, Mario
Re: [tomahawk] Is there any task left to make a release of tomahawk?
Hi! Mario, Could you please open jira issues on the defects you found during your work with s:pprPanelGroup. The problems I had previously were: 1) Sometimes ppr simply stopps working, a full page refresh will happen. Don't know how to reproduce it. Probably you could simply ignore that issue. 2) You need a way how to send the component h:messages together with the ppr response. In a4j you could wrap any component. These component are then fetched with ANY ajax request. This makes it VERY easy to have ajax submit by still being able to show the messages, even if a custom messagesRenderer is used (like we have here). 3) Support setting a new ViewRoot from within an ajax request. a4j also supports that. The ajax response will then be (I think aborted) and a full page refresh will happen. But hey, it was really cool once I discovered that this works at all. More generally I have to say I find it way more harder to define all the client-side id's where the ppr should trigger than to simply setup a reRender attribute on any commandLink/commandButton. We found it much more natural to work that way then to configure triggerPatterns. a4j also provides an easy way to have a status icon somewhere on the page which will appear on ajax-req-start and disappear (or whatever, just configure the facets) on ajax-req-stop. The main question is, what is the target of our pprPanelGroup. If it is to be as comfortable as the other ppr implementations I think it needs much more work. Ciao, Mario Thank you. On Wed, Jul 9, 2008 at 1:39 AM, Mario Ivankovits [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi! s:xmlTemplate Dont know much, not to say nothing, about that. s:pprPanelGroup (is this component ready? it could be good but I don't know if there is any objection). I do not think that pprPanelGroup is ready for a release, there are some things still missing and sometimes it stopps working. Unfortunately, I have to say I am switching away from pprPanelGroup to a4j with richfaces. I just have no time to look into pprPanelGroup ... Ciao, Mario -- Hazem Ahmed Saleh Ahmed http://www.jroller.com/page/HazemBlog
Re: proposal: new Orchestra Flow subproject
Hi! (a) create a sub-project myfaces/orchestra/trunk/flow, publish to snapshot-repo and main myfaces website as normel, but make sure that the welcome page for the website says SANDBOX in big letters and the version number is something like 0.0.1 +1 Often even the sandbox will be used also in production. Which is peoples own fault, but it is as it is. Given automatic installation of NavigationHandler and ViewHandler I'll second that it is a good idea to have it as sub-project even when it will be released. Also it clearly shows Orchestra's openess for anything else, even another flow implementation. Ciao, Mario
Re: [tomahawk] Is there any task left to make a release of tomahawk?
Hi! s:xmlTemplate Dont know much, not to say nothing, about that. s:pprPanelGroup (is this component ready? it could be good but I don't know if there is any objection). I do not think that pprPanelGroup is ready for a release, there are some things still missing and sometimes it stopps working. Unfortunately, I have to say I am switching away from pprPanelGroup to a4j with richfaces. I just have no time to look into pprPanelGroup ... Ciao, Mario
Re: current state of MYFACES-434
Hi Leonardo, I tried to upgrade to the latest Tomahawk+Sandbox and now the application fails to run properly as the TomahawkFacesContextWrapper does the AddResource processing AND the ExtensionsFilter does the AddResource processing. The code in extension filter that do AddResource processing should be commented (this was added to disable this feature before). But before do that, we need to test several configurations of this feature (DefaultAddResource, NonBufferingAddResource, if servlet or portlet environment and other variations), because it could break old code. Ok, but it seems that Tomahawk head breaks every installation using DefaultAddResource which makes it impossible to test new things. My workaround is to use DojoAddResource, but that is far from being nice. If you would like us to test this thing it would be great if you could finish the work in ExtensionsFilter so that it really works as drop in replacement. Thanks! Ciao, Mario
Re: [myfaces core] Redirect to a JSF page when Throwable exception or error occur
Hi! the use-case is that people want the same type of functionality they have in their web.xml (specifying an error-page per exception) in the JSF-world as well. Just doing it in the web.xml is not sufficient, as then the faces-context is already closed and not available anymore, so important context-information for the error would be missing. I wonder why people always want a full running JSF environment for each and every page. If there is an exception it might be due to a problem in JSF itself which might make it impossible to show any error page at all. Not that you can not handle such situations (revert to default error handling), but it makes things complicated. As long as it does not break other things and is fully optional with non-intrusive by default I am -0 adding such a feature. Ciao, Mario
Re: Dojo discussion - opensourcing the jsf dojo components project
Hi! Ok then those things are cleared up, now back to the original question sandbox or own subproject? +1 for own subproject. Any further influence with tomahawk/sandbox needs to be avoided. These two projects are still waiting for a overhaul themself. Ciao, Mario
current state of MYFACES-434
Hi! What is the current state of MYFACES-434? I tried to upgrade to the latest Tomahawk+Sandbox and now the application fails to run properly as the TomahawkFacesContextWrapper does the AddResource processing AND the ExtensionsFilter does the AddResource processing. This results in having the scripts added twice to the header which will result in non working dojo components. Configuring the ExtensionsFilter to not cover the jsf requests will result in the well known ExtensionsFilter not correctly configured. JSF mapping missing. JSF pages not covered. Please see: http://myfaces.apache.org/tomahawk/extensionsFilter.html (java.lang.IllegalStateException) message. So it seems we are half way, aren't we? Did I do something wrong? If not, can we fix this? Notice: I built Tomahawk MyFaces from a fresh checkout (which was a story itself as the 6-SNAPSHOT master pom couldn't be found). Ciao, Mario
Re: [myfaces core] Redirect to a JSF page when Throwable exception or error occur
Hi! One possible enhancement to the error handling feature of myfaces could be the capability of redirect to a jsf page. Any concrete use-case for this, or just yet another cool-we-can-make-it thingy? ;-) Seriously, what's wrong with the error page capabilities of the webapp container? Instead of error-code you can have error-type. Never used, tough. Probably it would be enough to learn the Faces-Servlet to unwrap the real exception instead of introduce another error handling stuff. Even this I'd do with a Faces-Servlet wrapper, more like a general purpose exception-unwrapper-servlet so that this can work with Mojarra and whatever. Ciao, Mario
Re: t:graphicImage doesnot generate XHTML complaint code
Hi! Ok, just to say something here too. If you are going to create an accessibility application you have to put more work into it than just adding an ALT text to your images. Since a meaningful default text is not easy to find, if not impossible, my vote is: that means: - log a nag warning +1 probably configurable. something like org.apache.myfaces.ACCESSIBILITY_WARNINGS=true|false with default to true. - render a non-empty alt attribute with a meaningful default text if the developer omits the attribute (or provides an empty one) -1 (a) don't output ALT. This screws all blind users, but in an obvious way so that QA departments can easily detect it and tell their developers to add the needed alt attributes. And it is not our code that is at fault. +1 (b) output empty ALT. This screws all blind users, but it cannot be detected by validation. And it is our code that is at fault as well as the user code. -1 (c) output ALT with ha ha no description. See (b). -1 Probably we can use the title text as default for the alt if there is one. For sure, the Tomahawk components (e.g. tree2) need to be fixed to properly render an ALT attrbute. Ciao, Mario
Re: svn commit: r671015 - in /myfaces/tomahawk/trunk: core/src/main/java/org/apache/myfaces/custom/aliasbean/AliasBeanTag.java examples/simple/src/main/webapp/aliasBean.jsp
Hi!
Doesn't this change break backward compatibility completley?
The value of the alias= attribute now has to be defined differently,
instead of the el-expressesion just the name needs to be set.
Even if this change is logical to me, a new tomahawk release will break
any existing application using the aliasBean, no?
If so, I think this patch needs to be reverted unless we are going to
release a new major version of tomahawk.
Ciao,
Mario
[EMAIL PROTECTED] schrieb:
Author: lu4242
Date: Mon Jun 23 21:22:49 2008
New Revision: 671015
URL: http://svn.apache.org/viewvc?rev=671015view=rev
Log:
TOMAHAWK-790 Aliasbean warning/error when no EL expression in the alias property
Modified:
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/aliasbean/AliasBeanTag.java
myfaces/tomahawk/trunk/examples/simple/src/main/webapp/aliasBean.jsp
Modified:
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/aliasbean/AliasBeanTag.java
URL:
http://svn.apache.org/viewvc/myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/aliasbean/AliasBeanTag.java?rev=671015r1=671014r2=671015view=diff
==
---
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/aliasbean/AliasBeanTag.java
(original)
+++
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/aliasbean/AliasBeanTag.java
Mon Jun 23 21:22:49 2008
@@ -47,7 +47,7 @@
protected void setProperties(UIComponent component) {
super.setProperties(component);
-setStringProperty(component, alias, _alias);
+setValueBinding(component, alias, _alias);
setStringProperty(component, value, _valueExpression);
}
Modified: myfaces/tomahawk/trunk/examples/simple/src/main/webapp/aliasBean.jsp
URL:
http://svn.apache.org/viewvc/myfaces/tomahawk/trunk/examples/simple/src/main/webapp/aliasBean.jsp?rev=671015r1=671014r2=671015view=diff
==
--- myfaces/tomahawk/trunk/examples/simple/src/main/webapp/aliasBean.jsp
(original)
+++ myfaces/tomahawk/trunk/examples/simple/src/main/webapp/aliasBean.jsp Mon
Jun 23 21:22:49 2008
@@ -45,7 +45,7 @@
h:form
h2aliasTest1/h2
-t:aliasBean alias=#{holder} value=#{aliasTest1}
+t:aliasBean alias=holder value=#{aliasTest1}
f:subview id=simulatedIncludedSubform1
%-- The next tags could be inserted by an %@ include or
jsp:include --%
h:outputLabel for=name value=Name :/
[jira] Commented: (TOMAHAWK-1014) HTMLInputDate ignores custom converters
[ https://issues.apache.org/jira/browse/TOMAHAWK-1014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12607465#action_12607465 ] Mario Ivankovits commented on TOMAHAWK-1014: at least t:inputCalendar allows to use the converter= property (we use it here), and so should inputDate too no? The custom converter just inherits from the special inputCalendar converter. This is required to e.g. allow to plug in any other date library like Joda-DateTime. I'll reopen this bug, please close it again if I got things wrong. Ciao, Mario HTMLInputDate ignores custom converters --- Key: TOMAHAWK-1014 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1014 Project: MyFaces Tomahawk Issue Type: Bug Components: Date Affects Versions: 1.1.5 Reporter: Steven Gollery Assignee: Leonardo Uribe Fix For: 1.1.7-SNAPSHOT Setting a custom converter on HTMLInputDate fails. HTMLDateRenderer.getConvertedValue does not use the converter from the component, but instead uses UserData.parse. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (TOMAHAWK-1014) HTMLInputDate ignores custom converters
[ https://issues.apache.org/jira/browse/TOMAHAWK-1014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Ivankovits reopened TOMAHAWK-1014: HTMLInputDate ignores custom converters --- Key: TOMAHAWK-1014 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1014 Project: MyFaces Tomahawk Issue Type: Bug Components: Date Affects Versions: 1.1.5 Reporter: Steven Gollery Assignee: Leonardo Uribe Fix For: 1.1.7-SNAPSHOT Setting a custom converter on HTMLInputDate fails. HTMLDateRenderer.getConvertedValue does not use the converter from the component, but instead uses UserData.parse. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] layout for myfaces-commons project
simon schrieb: In other words, keeping one line of code makes sense (less maintenance) even if we lose some JSF1.2/JSF2.0-specific features or performance boosts. While I second the rest of your mail, I wont do so with the sentence above. We are developers, and, at least in your younger years ;-), you'd like to keep up with technology and use the newest things. And JSF 1.2 is anything else then new today, not to speak about JSF 1.1. In contrast, we spent alot of time to make our JSF 1.1 development upward compatible. I don't think that we are responsible to provide a vital community around a library which itself depends on a stone old architecture. So, yes to one line of code, but I'd like to see the bundle Tomahawk+JSF1.1 frozen. Anything new should go to a JSF 1.2 native Tomahawk. And JSF 2.0 release date + (lets say) half year the same should count for Tomhawk JSF 1.2 then. Ciao, Mario
Re: [vfs] SFTP Provider and Daemon Threads?
Hi! Since this change requires a newer version of jsch then the one used to build the project, will it be updated as well (0.1.39 is the latest)? I'm trying to build a snapshot and it fails with: For the current VFS trunk we can do this. James, could you update the pom and build.xml please. Thanks! Ciao, Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [trinidad] Why input type=hidden name=javax.faces.ViewState ... does not render its id?
Hi! why not getElementsByName[0] ? Well, in general document.getElementById is both faster and more elegant. So in this case, rendering this component with id=clientId seems reasonable. Hmm..but it is possible that there are multiple view state fields in the page, one per form. So perhaps using getElementsByName is a good idea in this specific case. And also ensure that every ViewState will be replaced and not only the first [0] one. When you do have multiple JSF forms (which is valid) each ViewState needs to be replaced. Ciao, Mario
Re: [trinidad] Why input type=hidden name=javax.faces.ViewState ... does not render its id?
Hi!
And also ensure that every ViewState will be replaced and not only the
first [0] one.
When you do have multiple JSF forms (which is valid) each ViewState
needs to be replaced.
Yes, but only when they came from the same view!
I don't know much about JSF portal bridge stuff. Can this result in a
page contains a form that was rendered via JSF from host A, and a
different form that was rendered via JSF from host B?
I'd say yes. You might be right.
Don't know much about protlets either, but, I guess one solution can be
to replace only those ViewState fields with the same value as the one
associated with the form the component is embedded in.
Lets speak code:
var enclosingForm = findEnclosingForm(theComponent);
var oldViewState = enclosingForm[ViewState].value;
for (form : forms)
{
if (form[ViewState].value == oldViewState)
{
form[ViewState].value = newViewState;
}
}
Or do any portlet have its own namespace reflected into the element id?
Then this could be checked too, though, this will be a portlet specific
solution then.
Ciao,
Mario
Re: [trinidad] Why input type=hidden name=javax.faces.ViewState ... does not render its id?
Hi! I ignore what happens when use multiple jsf portlets in the same page, or when the page is using multiple forms on the same page (normal submits should work on both environmets, but ajaxified components?). With I ignore you mean you will not replace the ViewState for each form having a ViewState hidden field? If so, this is bad I think, as having multiple forms is a perfect possible scenario, subForm is not always the best answer. Ciao, Mario
Re: [lang] Java 5
Hi! +1 on generics +99 on package-name change. +100 The ASM project (org.objectweb.asm) changes their API significantly with major releases, but do not change the package name. And it causes major pain. For example, the following libs all require specific versions of ASM: * hibernate * drools * spring AOP (via cglib) * groovy I've got an app that uses all of the above Sounds familiar ;-) Ciao, Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vfs] Why doesn't AbstractFileObject override equals?
Hi!
I'd go that way:
1. in AbstractFileObject.getParent():
replace
if (this == fs.getRoot()) { ... };
with
FileObject root = fs.getRoot();
if (root instanceof DecoratedFileObject) {
root = ((DecoratedFileObject) root).getDecoratedFileObject();
}
if (this == root) { ... }
But instead of the instanceof thing simply use
FileObject root = FileObjectUtils.getAbstractFileObject(root);
Which does all the unpacking stuff.
Ciao,
Mario
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: VFS problem with StaticUserAuthenticator
Hi Stephan! i just wanted to do the same, but it seems that i'm too stupid. how do you add yourself as a developer. i found no related links, neither on the page you mentioned nor on the vfs homepage. sorry! You aren't an Apache Commiter yet, no? You have to become an Apache Commons Committer first which requires to send patches and being active on the ML for a while. And there are a lot of bugs to fix for VFS waiting in JIRA, so if you would like to join, feel free to pick them up and attach patches where missing :-) Ciao, Mario cheers, stephan James Carman wrote: Done. I added myself as a developer. If you want me to change it to contributor, then I can do that also. On Wed, Jun 11, 2008 at 9:07 AM, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi James! I might be able to spend a few cycles getting it set up. And probably you should add yourself to VFS's project-team :-) Ciao, Mario [1] http://commons.apache.org/vfs/team-list.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: VFS problem with StaticUserAuthenticator
Hi! Are there thoughts on doing a new release. We really need webdav working in VFS and the core VFS code in the sandbox just doesn't work. One simple test it would be great if you as a commons-vfs-comitter could replace slide with webdavclient4j and make it part of the core instead of being in i separate sandbox. What we can do is to take the webdavclient4j vfs provider over to apache. But I don't want to take the webdavclient4j core over as VFS is enough work to do already and I don't see enough developers around here maintaining that codebase then. There are already too few for vfs alone :-( Ciao, Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: VFS problem with StaticUserAuthenticator
Hi! so what i meant (and i hope this is in line with jason harrop, the project leader) is, that webdavclient4j should be the default library (as it is slide at the moment) used for vfs' webdav providers. therefore it would be necessary to take over webdavclient4j's vfs providers (webdav and webdavs) to commons-vfs, exactly as you mentioned it. Yep, if Jason is providing a release of the webdavlib4j core through an public maven repository we can go that route. Ciao, Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: VFS problem with StaticUserAuthenticator
Hi James! I might be able to spend a few cycles getting it set up. And probably you should add yourself to VFS's project-team :-) Ciao, Mario [1] http://commons.apache.org/vfs/team-list.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: VFS problem with StaticUserAuthenticator
James Carman schrieb: Done. I added myself as a developer. If you want me to change it to contributor, then I can do that also. No, developer was exactly what I had in mind :-) Thanks! - and - Welcome! Ciao, Mario On Wed, Jun 11, 2008 at 9:07 AM, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi James! I might be able to spend a few cycles getting it set up. And probably you should add yourself to VFS's project-team :-) Ciao, Mario [1] http://commons.apache.org/vfs/team-list.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vfs] Why doesn't AbstractFileObject override equals?
Hi! on the first glimpse i don't understand why AbstractFileObject doesn't override equals() and hashCode(). The current VFS implementation (if you do not use anything else then the only-working SoftRefFilesCache) ensures that two resolveFile will return the same object if you ask for the same filename, thus, in terms of VFS there is nothing bad with the object comparison. Did you catch any problem? Ciao, Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vfs] SFTP Provider and Daemon Threads?
Hi! I went ahead and committed it. It was a one-line change. So, it'll be easy to back out if you so desire. But, in my application, it solved the hanging problem. So, I resolved/closed the JIRA issue. Yep, seems good. Thank you! Ciao, Mario On Tue, Jun 10, 2008 at 8:50 AM, James Carman [EMAIL PROTECTED] wrote: I've created: https://issues.apache.org/jira/browse/VFS-211 and assigned it to myself. If you don't mind, I'll add in this feature and commit it (assuming it doesn't break anything of course). :) On Tue, Jun 10, 2008 at 8:45 AM, James Carman [EMAIL PROTECTED] wrote: It's on the Session API (since 0.1.31 I believe). There's a new setDaemonThread() method. On Tue, Jun 10, 2008 at 8:40 AM, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! Shouldn't the SFTP provider be calling setDaemon(true) on the JSch session? I am running a simple application which just lists the contents of a directory and it hangs after it's done because there's a non-daemon thread running (looks like a keep-alive thread from JSch). Is the JSch session inherited from Thread, or the flag exposed? If there is a possibility to set this flag from VFS we should do it. Ciao, Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [TOMAHAWK] modalWindow
Hi Kito! Two questions: (1) How well does the Tomahawk sandbox modalWindow work, and (2) has anyone tried using it with RichFaces? (Their modal window is pretty buggy.) Well, I use modalWindow and ... let's say, it works. I use in the special mode where another view will be rendered within the modalWindow. Anyway, I can't say that it is easy to use. You have to use some javascript and also there is no standard way to transfer data back to a backing bean. You have to solve that yourself. I think there is an example in the sandbox examples, if not, I can post how I use it. Ciao, Mario
Re: [Orchestra] How to annotate conversation scope bean
Hi! sorry, I found a reference to this issue and it is not supported yet. http://www.nabble.com/-orchestra--Spring-2.5-to15292381.html As far as I remember Simon already added this feature to the core15 release. So @ConversationName should be your friend :-) Ciao, Mario -D Dan Tran wrote: Hello, I would like to use spring 2.5.x to annotate my backing bean with conversation. So here is what have so far @Component @Scope( conversation.access ) what about conversation' name? big thanks ahead. -D -- mit freundlichen Grüßen Mario Ivankovits Software Engineering OPS EDV VertriebsgesmbH A-1120 Wien, Michael-Bernhard-Gasse 10 Firmenbuch Nr.: FN51233v, Handelsgericht Wien Tel.: +43-1-8938810; Fax: +43-1-8938810/3700 http://www.ops.co.at E-Mail: [EMAIL PROTECTED] Skype: mario_ivankovits
Re: VFS FTP AbstractFileObject.isWriteable() Causes NullPointerException
Hi Richard! Could you please try the latest VFS (aka 2.0) nightly build, there a lot of stuff in this area has been changed. Hi! No luck. Ok, no worries, at least we have a stacktrace matching the current source-base. I'll see what I can do to fix this. Thanks! Ciao, Mario
Re: VFS FTP AbstractFileObject.isWriteable() Causes NullPointerException
Hi! 1. I receive a NullPointerException from AbstractFileObject.isWriteable() when I attempt to copy VFSFTPTest.class from a local directory to one on a FTP server: Could you please try the latest VFS (aka 2.0) nightly build, there a lot of stuff in this area has been changed. It seems the VFS nightly build system if broken again, you have to build a version yourself by gathering the source from svn as described here [1] and using maven 2 to build with mvn -DskipTests install from within the checked out VFS directory. But probably you know that :-) 2. file.findFiles() will return a 0 length array, or a null array depending on the FTP server I connect to. This should be consistent, one or the other, don't you think? Even this is changed in the version mentioned above. Please give it a try. Ciao, Mario [1] http://commons.apache.org/vfs/download.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Orchestra core15 version 1.0 release
Hi! [X] +1 for community members who have reviewed the bits Thanks for being the release-manager again! Ciao, Mario
[jira] Commented: (VFS-210) Wrapper-Mode VFS
[
https://issues.apache.org/jira/browse/VFS-210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12599578#action_12599578
]
Mario Ivankovits commented on VFS-210:
--
Yes!
I haven't changed the API so far and I do not plan to do so. There are just a
few changes in the contract VFS had with some of it's abstract methods in
AbstractFileObject. Nothing too serious so far.
If your code does something like this ...
FileObject fo = VFS.getManager().resolveFile(ftp://xyz/;);
if (fo.getType().hasChildren())
{
// traverse fo
fo.getChildren();
}
... you should not see any changes. But you could also not expect any
performance increase as you called getType().
With the commits today you will be able to:
FileObject fo = VFS.getManager().resolveFile(ftp://xyz/;);
// traverse fo
fo.getChildren();
This will no longer call getType(), not in your code nor within VFS. Thus, it
is no longer required to list the parent directory which was a real pain.
You will get a FileNotFolderException from getChildren() if the file wasn't a
directory instead.
Both modes work in parallel. It just depends on the way how you use the VFS API.
Wrapper-Mode VFS
Key: VFS-210
URL: https://issues.apache.org/jira/browse/VFS-210
Project: Commons VFS
Issue Type: Improvement
Affects Versions: 1.0
Reporter: Mario Ivankovits
Assignee: Mario Ivankovits
Fix For: 2.0
VFS should behave more like a wrapper to the underlaying library than a full
blown filesystem.
This should solve the following problems:
* access of hidden files/directories
* access to special folders
* speed up FTP access
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (VFS-196) FTP Provider Does Not Support Symbolic Links Correctly
[ https://issues.apache.org/jira/browse/VFS-196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12599580#action_12599580 ] Mario Ivankovits commented on VFS-196: -- Go on an commit it please! Thanks! FTP Provider Does Not Support Symbolic Links Correctly -- Key: VFS-196 URL: https://issues.apache.org/jira/browse/VFS-196 Project: Commons VFS Issue Type: Bug Affects Versions: 1.1 Reporter: James Carman Assignee: James Carman Fix For: 1.1 Attachments: symbolic_links.patch If a directory is a symbolic link, it shows up as file type imaginary -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (VFS-196) FTP Provider Does Not Support Symbolic Links Correctly
[ https://issues.apache.org/jira/browse/VFS-196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12599589#action_12599589 ] Mario Ivankovits commented on VFS-196: -- In VFS 2 we need the first version where nul will be returned in case of listFiles didn't return something which indicates that this was a file and not a directory and thus this file had null children. FTP Provider Does Not Support Symbolic Links Correctly -- Key: VFS-196 URL: https://issues.apache.org/jira/browse/VFS-196 Project: Commons VFS Issue Type: Bug Affects Versions: 1.1 Reporter: James Carman Assignee: James Carman Fix For: 1.1, 2.0 Attachments: symbolic_links.patch If a directory is a symbolic link, it shows up as file type imaginary -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (VFS-196) FTP Provider Does Not Support Symbolic Links Correctly
[ https://issues.apache.org/jira/browse/VFS-196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12599590#action_12599590 ] Mario Ivankovits commented on VFS-196: -- Just in case it is not clear, with first version I mean the null check. The symbolic check stuff should be fine. BTW. In case of isSymbolicLink, you can also use this.getLinkDestination().getName() instead of doing the name-resolve yourself. FTP Provider Does Not Support Symbolic Links Correctly -- Key: VFS-196 URL: https://issues.apache.org/jira/browse/VFS-196 Project: Commons VFS Issue Type: Bug Affects Versions: 1.1 Reporter: James Carman Assignee: James Carman Fix For: 1.1, 2.0 Attachments: symbolic_links.patch If a directory is a symbolic link, it shows up as file type imaginary -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[vote][vfs] set minimum java version to 1.5
Hi! Since it is not that easy to get in touch with a jdk 1.3 (or I tried not hard enough ;-) ) I'd like to ask if everyone is fine to start VFS 2 with jdk1.5? As long as no other development need requires it to enhance the VFS 2 api I do not plan to introduce generics yet (I don't see that many places for this in VFS), though sticking with jdk 1.3 seems uncool, no? ;-) Seriously, it should really be the right time to leave jdk 1.3 behind. Since the API might not drastically change it should not be required to rename the package to vfs5 or vfs2 or whatever. If required, JDK 1.4 will do the trick too, though, this is EOL with October 2008 too. [ ] Go on with JDK 1.5 [ ] Go on with JDK 1.4 [ ] Stick with JDK 1.3 for the following reason: Ciao, Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote][vfs] set minimum java version to 1.5
Hi! It's easy enough to get 1.3 from java.sun.com ... I also got 1.2 and 1.1 from there recently. Ah, yes, now I found it too, it's in archive. Since the API might not drastically change it should not be required to rename the package to vfs5 or vfs2 or whatever. Not sure I understand why the API needs to change at all. Yepp, it is also the plan. I just don't wanted to put anything in stone yet. Ciao, Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (VFS-210) Wrapper-Mode VFS
Wrapper-Mode VFS Key: VFS-210 URL: https://issues.apache.org/jira/browse/VFS-210 Project: Commons VFS Issue Type: Improvement Affects Versions: 1.0 Reporter: Mario Ivankovits Assignee: Mario Ivankovits Fix For: 2.0 VFS should behave more like a wrapper to the underlaying library than a full blown filesystem. This should solve the following problems: * access of hidden files/directories * access to special folders * speed up FTP access -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[vfs] vfs2 or plain wrapper mode
Hi! Probably I find some time during the next weekend to fix a long standig bug in VFS regarding dealing with hidden or special files. The main problem I see is that VFS tries to act more like a real filesystem than a simple wrapper. VFS tries to determine the filetype (FILE, DIR, VIRTUAL) and then throws an exception if one tries to open a VIRTUAL file. VFS thinks such a file can not exist. I'd like to change that behavior from a fail fast to a fail lazy one, means, even on VIRTUAL files VFS tries to issue a getInputStream() on read. If the underlaying library then throws an exception about non-existent files this exception will be converted to a VFS exception. The internal file-type is then more like a guess and might change on e.g. getInputStream(). For example, a VIRTUAL file will become a FILE if getInputStream() succeeded. In the end I'd like to make VFS behave more like a wrapper than a real filesystem and VFS will pass down each file operation to the underlaying library as soon as possible and then normalize the thrown exceptions to VFS ones if possible. As a side-effect it could be possible to disable this filetype determination at all (or make it optional) and thus make VFS a lot faster e.g. with FTP connections where this operation is really really costly. As far as I can see this will lead to a somehow different behavior of VFS than it is today. It should not influence any existing applications, but it might. So, my questions are: * [ ] Do you agree that such an evolution might make sense * and if so, should I ** [ ] add a VFS-global (static) flag to enable this wrapper-like-mode or ** [ ] can I fork VFS to put the current head into maintainance (or more correct dormant) mode and start with e.g. VFS 2.0? I'd prefer VFS 2.0. Ciao, Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vfs] vfs2 or plain wrapper mode
Hi Martin! Just wondering, how would a client of VFS enumerate Just the folders in a directory e.g. in order to Render a tree of files? As today. Disabling the file-type determination should be optional only and isn't something I'd change during the first development iteration. The difference to today is that VFS will allow you to try to enumerate even on files where it thinks it is a file or virtual. And only if the underlaying library throws an exception the operation will fail. What I'd like to open up is just to ignore what VFS thinks about a file and try to read it anyway. This should make it possible to also deal with special files and also hidden files which will look like a virtual file for VFS - and make VFS unable to handle them today. On filesystem level than (through our FileSystemOptions) it might be interesting to allow to disable the file-type determination at all which will make ftp access a lot faster, even if some file informations are missing then. But polling a ftp directory for new files will be as fast as when using plain ftp then. Ciao, Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vfs] vfs2 or plain wrapper mode
Hi! Sounds like your solution would work for directories as well, if VFS didn't attempt to enumerate all the files in all the directories along the path? Yes, that is the plan :-) What I wrote about files count for directories too, for me this attribute is just a different value ;-) Ciao, Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Orchestra] Session is closed
Hi Cagatay! I'm trying to convert an existing application to use Orchestra. Followed the installation documentation but I'm getting org.hibernate.SessionException: Session is closed! exception after I add Orchestra. Just cant make it work so far. Unfortunately I can't see anything obviously wrong in your configuration file. Is the Session closed issued after the first request or after an exception? Normally I'd think that there is some filter active which will close the session and that your application do not really use the Orchestra provided persistence context. No clue why this can happen. Probably debugging into Orchestra's JpaPersistenceContextFactory and see if the created PersistenceContext is the same you'll use in your method then will help. If you can't solve your problem and nobody else has a better idea we need to get in touch with your application, I think :-( Ciao, Mario
Re: svn commit: r656086 [2/2] - in /myfaces/tomahawk/trunk/core: ./ src/main/java/org/apache/myfaces/component/html/util/ src/main/java/org/apache/myfaces/custom/jslistener/ src/main/java/org/apache/m
Hi!
Simon and me had to spend 5 hours today to track down a problem which in
the end uncovered a nasty bug in TomahawkFacesContextWrapper. In
.release() the delegation was broken (due to a return in the try block).
Bad stuff :-(
Also I found some questionable stuff:
* Some important todos like the arguments for the MultipartRequestWrapper
* A lot of e.printStackTrace()
Is this work in progress? Or is the module already in
if-one-finds-a-problem-fix-it-yourself-mode ;-)
Ciao,
Mario
http://svn.apache.org/viewvc/myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/webapp/filter/TomahawkFacesContextWrapper.java?rev=656086view=auto
==
---
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/webapp/filter/TomahawkFacesContextWrapper.java
(added)
+++
myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/webapp/filter/TomahawkFacesContextWrapper.java
Tue May 13 19:00:38 2008
@@ -0,0 +1,292 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * License); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.myfaces.webapp.filter;
+
+import java.lang.reflect.InvocationTargetException;
+import java.lang.reflect.Method;
+import java.util.Iterator;
+
+import javax.faces.FacesException;
+import javax.faces.application.Application;
+import javax.faces.application.FacesMessage;
+import javax.faces.component.UIViewRoot;
+import javax.faces.context.ExternalContext;
+import javax.faces.context.FacesContext;
+import javax.faces.context.ResponseStream;
+import javax.faces.context.ResponseWriter;
+import javax.faces.render.RenderKit;
+import javax.portlet.PortletResponse;
+import javax.servlet.http.HttpServletRequest;
+import javax.servlet.http.HttpServletResponse;
+
+import org.apache.commons.fileupload.FileUpload;
+import org.apache.myfaces.renderkit.html.util.AddResource;
+import org.apache.myfaces.renderkit.html.util.AddResourceFactory;
+import org.apache.myfaces.tomahawk.util.ExternalContextUtils;
+
+/**
+ * @author Martin Marinschek
+ */
+public class TomahawkFacesContextWrapper extends FacesContext {
+
+private FacesContext delegate=null;
+private ExternalContext externalContextDelegate=null;
+private ExtensionsResponseWrapper extensionsResponseWrapper = null;
+
+public TomahawkFacesContextWrapper(FacesContext delegate) {
+
+this.delegate = delegate;
+
+//if(delegate.getExternalContext().getResponse() instanceof
PortletResponse) {
+
if(ExternalContextUtils.getRequestType(delegate.getExternalContext()).isPortlet())
{
+//todo do something here - with the multipart-wrapper. rest
should be fine
+AddResource addResource= AddResourceFactory.getInstance(this);
+addResource.responseStarted();
+
+ if (addResource.requiresBuffer())
+ {
+throw new IllegalStateException(buffering not supported in
the portal environment.);
+}
+}
+else {
+HttpServletResponse httpResponse = (HttpServletResponse)
delegate.getExternalContext().getResponse();
+HttpServletRequest httpRequest = (HttpServletRequest)
delegate.getExternalContext().getRequest();
+
+HttpServletRequest extendedRequest = httpRequest;
+HttpServletResponse extendedResponse = httpResponse;
+
+// For multipart/form-data requests
+if (FileUpload.isMultipartContent(httpRequest)) {
+extendedRequest = new MultipartRequestWrapper(httpRequest,
/*todo _uploadMaxFileSize*/-1,
+/*todo _uploadThresholdSize*/-1, /*todo
_uploadRepositoryPath*/null);
+}
+
+AddResource addResource= AddResourceFactory.getInstance(this);
+addResource.responseStarted();
+
+ if (addResource.requiresBuffer())
+ {
+extensionsResponseWrapper = new
ExtensionsResponseWrapper(httpResponse);
+ extendedResponse = extensionsResponseWrapper;
+}
+
+externalContextDelegate = new ExternalContextWrapper(
+
Re: [VOTE] To create a subproject alchemy under MyFaces for the contribution that integrates Adobe Flex components as MyFaces JSF components
Hi! Reason #3: The development community is not (so far) very large. Jihoon Kim's initial code looks nicely written, but it was written as a hobby project rather than being driven by any long-term goal. Shouldn't the project go through the incubator for this reason? MyFaces can be the sponsor (or however this is called in incubator land ;-) ) It also gives Apache the chance to sort out the legal issues. Ciao, Mario
log and throw exception [was: Re: svn commit: r656124 - /tomcat/trunk/java/org/apache/tomcat/util/net/jsse/JSSESocketFactory.java]
Hi!
} catch (FileNotFoundException fnfe) {
log.error(sm.getString(jsse.keystore_load_failed, type, path,
-fnfe.getMessage()));
+fnfe.getMessage()), fnfe);
throw fnfe;
} catch (IOException ioe) {
log.error(sm.getString(jsse.keystore_load_failed, type, path,
-ioe.getMessage()));
+ioe.getMessage()), ioe);
throw ioe;
I'd like to ask if it is really required to log the exception and throw
it too. Code like this will lead to logfile flooding as normally there
is some exception handling outside of the method which then handle the
exception, rethrow it, or purge it - then with logging of the exception.
I think there is no need to log the exception if you rethrow it. If
everyone along the stack rethrowing an exception also logs it, it will
be hard to read the logs, no?
Probably you can change the message so that it comes to something like:
catch (FileNotFoundException fnfe)
{
throw new FileNotFoundException(sm.getString(.), fnfe);
}
Ciao,
Mario
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Orchestra] Disabling Persistence Conversation Feature
Hi! I tried deleting the part regardless to persistence from spring configuration (application-context.xml) but no success. I encountered exceptions thrown by the Orchestra Conversation Interceptor. Not configuring the persistence related advice (e.g the persistentContextConversationInterceptor) with the scope should be sufficient. What exceptions do you encounter? Ciao, Mario
Re: [Orchestra] Explicit conversation starting and nested conversations
Hi! The user is inserting data for a Claim reading from a paper, receive a call and start to insert a new Claim in a new browser window (or tab). At the moment I have two browser using the same HttpSession, the same function and same shared data and my application does not work! For this, with Orchestra, you have to have an outputLink e.g. enter new claim which is surrounded by o:separateConversationContext. This link must have a target= (or any other trick) to open a new browser window. In this separate window then Orchestra will start a new conversationContext where you can have the exact same conversations running but with a different set of data. With Orchestra the scopes look like something like this: application-session-conversationContext-conversations Even if the conversation name is enterClain, this conversation is separated between the conversationContexts. separateConversationContext does nothing else then stripping the conversationContext URL parameter from the URL, forcing Orchestra to start a new context. Ciao, Mario
Re: [Orchestra] Explicit conversation starting and nested conversations
Hi! I don't know if I understood very well, but I'm going to fix Shale to store data in the current conversationContext. So I can have same dialog in differents windows. Do you think I have a chance of success? ( :) ) Yep, sounds very good! Don't know if Shale allows this easily, though. Probably this makes a good contribution if you made it work :-) Ciao, Mario (too) :-D
Re: [VOTE] Add MyfacesBuilderPlugin to buildtools branch and use it on myfaces 1.1
Leonardo Uribe schrieb: +0 ... just due to the fact that I don't have time to review these bits, but I trust you guys that *everything* ;-) works as expected. +1 for the architecture and the general approach! Great work! Hi MyfacesBuilderPlugin is now available for use on myfaces 1.1, so we can officially vote about what plugin use on myfaces 1.1, 1.2 and tomahawk for code generation Please note that this work is based on the discussion about code generation long time ago. A vote is necessary since this is a new module and the changes proposed impact several projects. The wiki describing how works this is here: http://wiki.apache.org/myfaces/MyfacesBuilderPlugin The examples are available here: https://svn.apache.org/repos/asf/myfaces/myfaces-build-tools/branches/builder_plugin/ You can find a copy of myfaces 1.1 working with this plugin here: https://svn.apache.org/repos/asf/myfaces/myfaces-build-tools/branches/builder_plugin/bigtest/core_trunk_11/ So please vote if you want to see this feature included on myfaces 1.x and tomahawk regards Leonardo Uribe -- mit freundlichen Grüßen Mario Ivankovits Software Engineering OPS EDV VertriebsgesmbH A-1120 Wien, Michael-Bernhard-Gasse 10 Firmenbuch Nr.: FN51233v, Handelsgericht Wien Tel.: +43-1-8938810; Fax: +43-1-8938810/3700 http://www.ops.co.at E-Mail: [EMAIL PROTECTED] Skype: mario_ivankovits
Re: possible replacement for our kupu based html editor
No way - http://www.cdolivet.net/editarea/editarea/docs/license.html - its LGPL Probably contacting the author and asking him to change the license or dual license it might be worth a try. Ciao, Mario Hi Werner, It works for me after removing some plug-ins from FF2. I can start working on it when I have sometime. But what is the new name u suggest for the new TextEditor? On 4/22/08, Werner Punz [EMAIL PROTECTED] wrote: Hazem Saleh schrieb: Hi Werner, It doesn't work for me on FF2. On 4/22/08, Werner Punz [EMAIL PROTECTED] wrote: Guys have a look at this amazing editor http://www.cdolivet.net/editarea/editarea/exemples/exemple_full.html the best, the code is under apache license!!! Werner Check your browser settings FF2 is exactly what I am using to view it :-) -- mit freundlichen Grüßen Mario Ivankovits Software Engineering OPS EDV VertriebsgesmbH A-1120 Wien, Michael-Bernhard-Gasse 10 Firmenbuch Nr.: FN51233v, Handelsgericht Wien Tel.: +43-1-8938810; Fax: +43-1-8938810/3700 http://www.ops.co.at E-Mail: [EMAIL PROTECTED] Skype: mario_ivankovits smime.p7s Description: S/MIME Cryptographic Signature
Re: MyfacesBuilderPlugin work now against myfaces core 1.1
Hi! MyfacesBuilderPlugin is almost complete. Actually works for 1.1 and all interested people could see the example here: Cool work guys. Great job! Thanks for all the hard work! Ciao, Mario
[jira] Commented: (ORCHESTRA-23) Incorrect initialization of OrchestraFacesContextFactory
[ https://issues.apache.org/jira/browse/ORCHESTRA-23?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12590607#action_12590607 ] Mario Ivankovits commented on ORCHESTRA-23: --- *shocked* Really?! All due to this bug or do you refer to some other (hopefully fixed) bugs too ... We use the 1.1 release without the problems you mentioned. Incorrect initialization of OrchestraFacesContextFactory Key: ORCHESTRA-23 URL: https://issues.apache.org/jira/browse/ORCHESTRA-23 Project: MyFaces Orchestra Issue Type: Bug Components: FrameworkAdapter Affects Versions: 1.1 Environment: windows, linux, solaris Reporter: Dan Tran Priority: Blocker Fix For: 2.0 Attachments: diff.txt In org.apache.myfaces.orchestra.lib.jsf. OrchestraFacesContextFactory. getFacesContext(...) The ContextLockRequestHandler is registered BEFORE FrameworkAdapterRequestHandler, For serialization of requests to work properly, the FrameworkAdapter must be initialized BEFORE the ContextLockRequestHandler attempts to use it in ContextLockRequestHandler.init(...) (in fact ,there is even a NOTE in there to that effect). The current order means the FrameworkAdapter is initialized JUST AFTER the ContextLockRequestHandler needs it. The fix is to swap the order of registering these adapters in OrchestraFacesContextFactory. getFacesContext(...). final LinkedList handlers = new LinkedList(); handlers.add(new ContextLockRequestHandler()); handlers.add(new FrameworkAdapterRequestHandler()); handlers.add(new ConversationManagerRequestHandler()); handlers.add(new DataSourceLeakRequestHandler()); should read final LinkedList handlers = new LinkedList(); handlers.add(new FrameworkAdapterRequestHandler()); handlers.add(new ContextLockRequestHandler()); handlers.add(new ConversationManagerRequestHandler()); handlers.add(new DataSourceLeakRequestHandler()); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-1855) hidden fields created when using h:commandLink and f:param should be created and removed using javascript
[ https://issues.apache.org/jira/browse/MYFACES-1855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12587862#action_12587862 ] Mario Ivankovits commented on MYFACES-1855: --- It would be really great if you could externalize the javascript too. Currently it is simply inlined into the source, which looks not very professional I think. hidden fields created when using h:commandLink and f:param should be created and removed using javascript - Key: MYFACES-1855 URL: https://issues.apache.org/jira/browse/MYFACES-1855 Project: MyFaces Core Issue Type: Bug Affects Versions: 1.2.2 Reporter: Leonardo Uribe Assignee: Leonardo Uribe Myfaces render the hidden fields before the end of the form, which cause compatibility problems when someone does not use h:form to encapsulate a form. Mojarra or jsf ri does not, instead create the hidden fields before submit (including the hidden fields for params), submit the form an then remove the hidden fields to avoid unwanted effects. Myfaces set the hidden fields (if it is not rendered on the form creates it), submit the form and then set the values of the hidden fields to null. I have noted that autoscroll feature available when using tomahawk + myfaces uses oamSetHiddenInput instead render the hidden autoscroll part. After thinking a lot (A LOT!!) about this problem, the best for solve this problem is do not render hidden fields for this case, but let the code for hidden fields (compatibility with tomahawk, since jscookmenu use this feature, this should change in a future release). Instead, for h:commandLink, set and remove the hidden fields using javascript. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TOMAHAWK-1214) allow to process form submits in a queue for high-speed input handling
[ https://issues.apache.org/jira/browse/TOMAHAWK-1214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Ivankovits resolved TOMAHAWK-1214. Resolution: Later Immediate need for this feature is no longer existent. It would be an interesting feature anyway, so resolved with later to get it out of line, but to keep the idea too. allow to process form submits in a queue for high-speed input handling -- Key: TOMAHAWK-1214 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1214 Project: MyFaces Tomahawk Issue Type: New Feature Components: PPRPanelGroup Reporter: Mario Ivankovits Assignee: Ernst Fastl Enhance the PPR stuff in a way which allows to process form input asynchron in a queue for high-speed input handling. Probably by adding a new attribute to the PPRPanelGroup called queued=true|false. With true the form data should be collected and held in a queue on client side. The client then checks that queue at given intervalls (queueCheckInterval=) if there is data in the queue and transmit that data to the server like a normal ppr request. Between each transmit a queueWaitInterval= should be waited. A status component (queueShowStatus=true|false) should show the success of each transmit. A client side javascript should be used to extract the status text information from the form data (queueShowStatusInfoBuilder=javascript-method-name(formData)) The PprPanelGroup should also be enhanced to being able to point to the messages component (messages=component-id) the queueStatus information should then be able to visualize that text and show e.g. a red-cross if there were errors (=messages) For this first version the status info can be a simple table created client-side using some css to allow to format it according to the application skin. A simple table with two columns status-info|return-visualization status-info is the text returned by the queueShowStatusInfoBuilder javascript method and return-visualization might be an icon. Only waiting requests and those with errors should be shown, correctly finished requests can be removed from the list. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [proposal] jsf validation with annotations
Hi! my position on this is we could make sev-en part of orchestra, if the orchestra crew really, really wants it. If not, this should just be a separate sub-module in MyFaces. It is interesting enough to stand on its own. First, Orchestra is part of the MyFaces community, so it really, really should be a decision the MyFaces community felt, and not a Orchestra Team only one. Anyway, I think this is a question on how we position Orchestra. If it is a strong position against JBoss Seam, then it probably might make sense to include everything which makes life easier for the developer into Orchestra - just as Seam tries to do. However, then we loose one of the strongest arguments pro Orchestra: Being a lightweight Conversation-Centric Library. If, we could add it as sub-module to Orchestra, but I think the best place for sev-en (would like to see a new name anyway) is to be a submodule of MyFaces. But first I'd like to see the technical details of how the sev-en core works. e.g. in the examples I've seen a lot of converter wrapper stuff ... Building an official MyFaces Maven Artifact which bootup a development environment (MyFaces Fullstack) with what we think on need for development of any-range-sized applications would be more approriate then. Such a project could include sev-en too. Ciao, Mario
[jira] Commented: (ORCHESTRA-21) URLs are always encoded
[ https://issues.apache.org/jira/browse/ORCHESTRA-21?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12587058#action_12587058 ] Mario Ivankovits commented on ORCHESTRA-21: --- Ouch ... good catch. Will do so. URLs are always encoded --- Key: ORCHESTRA-21 URL: https://issues.apache.org/jira/browse/ORCHESTRA-21 Project: MyFaces Orchestra Issue Type: Bug Reporter: Matthias Weßendorf Assignee: Mario Ivankovits Fix For: 2.0 In Trinidad some components creates the javascript calls like String url = javascript:TrShuttleProxy._moveItems(...; and than, we internally encode the url. Like facesContext.getExternalContext().encodeActionURL(url); so... with Orchestra, you now get something like: javascript:TrShuttleProxy._movetems();?conversationContext=3 which causes a JS syntax error. Fix would be to ignore anything that has a javascript: prefix. Orchestra should only append the conversationContext if the protocol is http or https. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ORCHESTRA-21) URLs are always encoded
[ https://issues.apache.org/jira/browse/ORCHESTRA-21?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12587059#action_12587059 ] Mario Ivankovits commented on ORCHESTRA-21: --- done URLs are always encoded --- Key: ORCHESTRA-21 URL: https://issues.apache.org/jira/browse/ORCHESTRA-21 Project: MyFaces Orchestra Issue Type: Bug Reporter: Matthias Weßendorf Assignee: Mario Ivankovits Fix For: 2.0 In Trinidad some components creates the javascript calls like String url = javascript:TrShuttleProxy._moveItems(...; and than, we internally encode the url. Like facesContext.getExternalContext().encodeActionURL(url); so... with Orchestra, you now get something like: javascript:TrShuttleProxy._movetems();?conversationContext=3 which causes a JS syntax error. Fix would be to ignore anything that has a javascript: prefix. Orchestra should only append the conversationContext if the protocol is http or https. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [configuration] JSON format
Hi! JSON is a subset of Javascript, so we can use a simple call eval() to parse the configuration file. Wouldn't that be dangerous for something like script injection? One might be able to pass in a faked JSON string with some code in there which will be executed on eval() then, no? Ciao, Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (ORCHESTRA-21) URLs are always encoded
[ https://issues.apache.org/jira/browse/ORCHESTRA-21?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Ivankovits resolved ORCHESTRA-21. --- Resolution: Fixed Fix Version/s: 2.0 Assignee: Mario Ivankovits We will encode now only if the url starts with http* URLs are always encoded --- Key: ORCHESTRA-21 URL: https://issues.apache.org/jira/browse/ORCHESTRA-21 Project: MyFaces Orchestra Issue Type: Bug Reporter: Matthias Weßendorf Assignee: Mario Ivankovits Fix For: 2.0 In Trinidad some components creates the javascript calls like String url = javascript:TrShuttleProxy._moveItems(...; and than, we internally encode the url. Like facesContext.getExternalContext().encodeActionURL(url); so... with Orchestra, you now get something like: javascript:TrShuttleProxy._movetems();?conversationContext=3 which causes a JS syntax error. Fix would be to ignore anything that has a javascript: prefix. Orchestra should only append the conversationContext if the protocol is http or https. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ORCHESTRA-20) single conversation
[ https://issues.apache.org/jira/browse/ORCHESTRA-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12585939#action_12585939 ] Mario Ivankovits commented on ORCHESTRA-20: --- Currently, the viewController scope does not work with this single conversation scope as the way how the conversation name will be derived from the bean name does not honor the fact into which scope the bean has been put into. This needs to be fixed. single conversation --- Key: ORCHESTRA-20 URL: https://issues.apache.org/jira/browse/ORCHESTRA-20 Project: MyFaces Orchestra Issue Type: Improvement Components: Conversation Reporter: Mario Ivankovits Create an implementation of a single conversation. A dialog/flow framework will create new conversationContexts instead of direct conversations. While you still will be able to use conversation.manual or conversation.access it makes sense to also provide a conversation.single implementation which shares the lifetime of the conversationContext (managed by the dialog framework) and has only one (single) persistence context. Still, mixing the various conversation implementations is possible. Probably Conversation.getCurrentInstance() outside of a conversation will return this single conversation if it exists within the current conversationContext. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
