Re: Orchestra on code.google.com
On 6/28/07, Werner Punz [EMAIL PROTECTED] wrote: Craig McClanahan schrieb: I'm on the expert group for WebBeans[1], along with a bunch of other people. There will definitely be some functional overlap on what Shale calls the dialog manager -- you will really really really want to pick one framework for that kind of stuff, be it Shale's, Trinidad's, Orchestra's, Seam's, WebBeans's, Spring's ... but other than that there's no reason you shouldn't be able to use Shale features and WebBeans features together, since they are both built on top of JSF APIs. Btw. Craig, you might be happy to hear, that I started with some preliminary Orchestra/Shale integration two days ago. I have nothing to show off yet, because I still tinker around with things and trying to find myself around in both codebases, but so far things look pretty good. Cool ... I just answered your first question on the Shale list, also. After three hours of reading the codebase and tinkering with it, I was able to fetch orchestra conversational beans within a defined Shale Dialog environment and have shale issuing the end conversation commands which trigger all the jpa and bean related cleanup in orchestra. Yesterday I managed to bind all conversational beans under one dialog to one persistencecontext. I am still a little bit unclear about some things, but things look very good for an integration bridge which is not too hard to configure. (so far it looks like a special shaledialog scope in spring should do the trick) That makes sense. If all goes well then Shale dialog will be the first high level conversation framework with an orchestra binding. Or the other way round the first framework orchestra prodides bindings for. Looking forward to seeing this in action :-). Craig
Re: Orchestra on code.google.com
On 6/26/07, Dr. Duong BaTien [EMAIL PROTECTED] wrote: On Tue, 2007-06-26 at 13:47 -0700, Craig McClanahan wrote: On 6/26/07, Dr. Duong BaTien [EMAIL PROTECTED] wrote: Is there anything in shale-goodies yet? The beginnings of a Clay based port of the Petstore app, and a few related experiments. Craig Thanks. Looking forward to it. Has any one ported Petstore 2.0 to Spring JPA and tomcat or Jetty? Craig, is there any thought on Shale and WebBeans? (Hope not to offend any one on this list) I'm on the expert group for WebBeans[1], along with a bunch of other people. There will definitely be some functional overlap on what Shale calls the dialog manager -- you will really really really want to pick one framework for that kind of stuff, be it Shale's, Trinidad's, Orchestra's, Seam's, WebBeans's, Spring's ... but other than that there's no reason you shouldn't be able to use Shale features and WebBeans features together, since they are both built on top of JSF APIs. Craig [1] http://jcp.org/en/jsr/detail?id=299 BaTien Thanks On Tue, 2007-06-26 at 00:47 -0700, Craig McClanahan wrote: On 6/26/07, Werner Punz [EMAIL PROTECTED] wrote: Mario Ivankovits schrieb: Hi! code.google.com is fine for that. I'd like to start a project at code.google.com to host any code not allowed (or not easily allowed) by the policy of ASF. e.g. when depending on (L)GPL code. I reserved a name already [1]. Any objections about it? Ciao, Mario [1] http://code.google.com/p/myfaces-orchestra-nonasf ++1 That name works, of course, but I also like the naming convention that was used for Shale extras that didn't fit into the usual Shale project: http://code.google.com/p/shale-goodies Doesn't myfaces-goodies have a nice ring? Craig
Re: Orchestra on code.google.com
On 6/26/07, Dr. Duong BaTien [EMAIL PROTECTED] wrote: On Tue, 2007-06-26 at 22:18 +, Gary VanMatre wrote: From: Craig McClanahan [EMAIL PROTECTED] On 6/26/07, Dr. Duong BaTien wrote: Is there anything in shale-goodies yet? The beginnings of a Clay based port of the Petstore app, and a few related experiments. I think that's a Facelets example. Where is the Clay love? :--) Wow ;-) It's even better. Please announce when it is up for testing. Thanks to the whole community effort. we need more than 24 hrs a day to catch up. Gary's right ... it is indeed Facelets based. IIRC, Sean started this as an effort to show Shale and Facelets and Hibernate working together, but got to busy to finish it. As such, it's never going to be up for testing unless someone comes along who *does* want to work on it. I've got admin rights on shale-goodies, and won't make you wait multiple months to get commit access :-). Craig BaTien Craig Thanks On Tue, 2007-06-26 at 00:47 -0700, Craig McClanahan wrote: On 6/26/07, Werner Punz wrote: Mario Ivankovits schrieb: Hi! code.google.com is fine for that. I'd like to start a project at code.google.com to host any code not allowed (or not easily allowed) by the policy of ASF. e.g. when depending on (L)GPL code. I reserved a name already [1]. Any objections about it? Ciao, Mario [1] http://code.google.com/p/myfaces-orchestra-nonasf g t; ; ++1 That name works, of course, but I also like the naming convention that was used for Shale extras that didn't fit into the usual Shale project: http://code.google.com/p/shale-goodies Doesn't myfaces-goodies have a nice ring? Craig
Re: Orchestra on code.google.com
On 6/26/07, Werner Punz [EMAIL PROTECTED] wrote: Mario Ivankovits schrieb: Hi! code.google.com is fine for that. I'd like to start a project at code.google.com to host any code not allowed (or not easily allowed) by the policy of ASF. e.g. when depending on (L)GPL code. I reserved a name already [1]. Any objections about it? Ciao, Mario [1] http://code.google.com/p/myfaces-orchestra-nonasf ++1 That name works, of course, but I also like the naming convention that was used for Shale extras that didn't fit into the usual Shale project: http://code.google.com/p/shale-goodies Doesn't myfaces-goodies have a nice ring? Craig
Re: Orchestra on code.google.com
On 6/26/07, Dr. Duong BaTien [EMAIL PROTECTED] wrote: Is there anything in shale-goodies yet? The beginnings of a Clay based port of the Petstore app, and a few related experiments. Craig Thanks On Tue, 2007-06-26 at 00:47 -0700, Craig McClanahan wrote: On 6/26/07, Werner Punz [EMAIL PROTECTED] wrote: Mario Ivankovits schrieb: Hi! code.google.com is fine for that. I'd like to start a project at code.google.com to host any code not allowed (or not easily allowed) by the policy of ASF. e.g. when depending on (L)GPL code. I reserved a name already [1]. Any objections about it? Ciao, Mario [1] http://code.google.com/p/myfaces-orchestra-nonasf ++1 That name works, of course, but I also like the naming convention that was used for Shale extras that didn't fit into the usual Shale project: http://code.google.com/p/shale-goodies Doesn't myfaces-goodies have a nice ring? Craig
Re: MyFaces Fusion Naming
On 3/2/07, Werner Punz [EMAIL PROTECTED] wrote: Arash Rajaeeyan schrieb: and may be thats because shale has chosen a different approach? No... Actually I think the fusion conversation system is one level lower than shale dialog. While shale dialog basically follows the approach - configuration of dialog scopes, have something which can keep objects in ram during the dialog. the fusion conversation system is along the lines of: providing a programmatic accessible scope mechanism based on spring 2.0s basic scope control which also is able to handle orm entity manager control, no dialog configuration whatsoever (except for a spring bean entry). Nothing speaks against accessing this programmatic control from a configuration based dialog system, and only a few things currently prevent it from being accessible from other webframeworks outside of the jsf scope. But as Mario said, who knows what the future will bring. One thing I've wondered as I've watched the fusion stuff go by ... in an architecture that is so heavily based on Spring 2 already, why wasn't Spring Web Flow used? It looks like the core value add you wanted (managing the persistence tier resources at a per-conversation level instead of per-request) could have been done with SWF just as easily as writing your own conversation scope stuff. Craig
Re: MyFaces Fusion
On 2/28/07, Werner Punz [EMAIL PROTECTED] wrote: Arash Rajaeeyan schrieb: oh yes, also conversation scope of Trinidad does you (or any one one else) have access to JSR 299 info? do you which approach are they going to standardize for conversation/dialog/(or what ever they name it)? Btw. speaking of JSR 299, and conversations, isnt jsr299 just a glue specification of marrying ejb3 and jsf so that you can use ejb3 beans as managed beans? JSR299 means whatever the expert group decides to propose to the JCP executive committee for approval. The kinds of things you describe above are definitely within the initial proposal document[1], but I would not place any bets that JSR-299 will limit itself to just what you mentioned. Regarding conversations and dialogs: This stuff really belongs into the servlet space just like session and request, which technologies then are built on top of such scoping is an entire issue. Agreed in general ... the devil is in the details. Consider the RESTafarian attitude that scopes of any kind (other than request scope) are evil. And, consider the fact that, although javax.servlet was one of the earliest extension proposals for the Java language, there have not been any mainstream-adopted solutions on different APIs to adapt HTTP requests to Java business logic (unless, I suppose, you count SOAP mappings via things like JAX-RPC and JAX-WS ... but those still count IMHO as built on *top* of the servlet APi instead of replacing it). Maybe there is some virtue in a simple baseline standard that everyone can adopt? Lets face it 90% of all problems most people have in webapps stem from the fact that you cannot keep objects for a longer time without going through the problems a session scope causes for garbage collection and due to the fact that if you do not work on a pure jdbc base but on an orm base you either have to keep an erm open for your entire session with all related problems or you have to open it on request or even works on business case and then run into the usual merge problems most orm layers have (which is not solvable in a satisfying way anyway) The current already big number of various dialog systems which also keep something conversational open for object storage stem from the fact that this is a huge problem or has become a bigger one now that webapps seem to have moved towards orm layers where this problem becomes more problematic. Tackeling it on JEE level has been long overdue in my opinion especially because most of the usage and core patterns basically are tested by now. Craig since you are reading this, any idea if the servlet specs will be opened to scopes/conversations in the next specifications? It turns out that I've been an internal proponent of dealing with these kinds of issues at the servlet spec level, as my colleagues in the platform group are aware of :-). One of the critical challenges, unfortunately, is econimics -- funding any spec all the way through the JCP process is likely to be a six-figure ($) investment, and the challenge is to optimize our (Sun's) investments. My personal interest in this problem space is actually at a level *below* the servlet API ... hopefully, the recently filed RESTful API JSR can deal with those sorts of things. Things like conversation scope (and even session scope) should be extensions on top of such a basic API, not fundamental features of it. Serv;ets have served us honorably for almost 10 years (only a little less than the lifetime of Java itself) ... but it's time to move forwards. Werner Craig
Re: MyFaces Fusion
On 2/27/07, Werner Punz [EMAIL PROTECTED] wrote: Mario Ivankovits schrieb: I thought you were simply playing around with the fusion framework, not trying to use it for real work :-) He is really enthusiastic and an adventurer ;-) It has less to do with adventure more along the lines of having been on a dreadful schedule for the app and having a conversation framework as being the only solution to get things done without killing my nerves and banging my head constantly against the orm layer (I have had enough of that in my life= In the end we get a good testcase for the patterns (and lots of stuff has been readjusted) so in the end it is a win win situation for everyone. Except that you might have been able to save some work by leveraging one of the existing dialog manager solutions (including possibly negotiating feature additions if you needed something that wasn't already supported). Instead, you guys just created another one. Craig
Re: MyFaces Fusion
On 2/27/07, Arash Rajaeeyan [EMAIL PROTECTED] wrote: I am more interested in ORM control part. I prefer to stay neutral between seam and shale in the book :) Don't forget about the conversation scope implementation in Trinidad, too :-). Craig
Re: MyFaces Fusion
On 2/27/07, Arash Rajaeeyan [EMAIL PROTECTED] wrote: oh yes, also conversation scope of Trinidad does you (or any one one else) have access to JSR 299 info? do you which approach are they going to standardize for conversation/dialog/(or what ever they name it)? EG discussions on JSR-299 have started (although it's been quiet for a while), but there's no definitive conclusion on this or pretty much any other technical issue yet. Craig
Re: [VOTE] Remove Static loggers from 1.2
On 2/26/07, Cagatay Civici [EMAIL PROTECTED] wrote: +1 non-binding Just as a procedural note, the only votes that PMC members have binding votes on is releases. For technical issues (like this one), all committer votes are not only binding, but a -1 (supported by adequate reasoning) is a blocker (whereas a release vote is majority rules). Craig
Where's Tomahawk?
I was attempting to build a quick demo application for Shale and Tomahawk interoperability, and was surprised to not be able to find it at the Maven central repository (at least under groupId org.apache.myfaces.tomahawk and artifactId tomahawk). The only thing I can find is snapshots at the Apache snapshot repository. Am I missing something, or did the production versions of Tomahawk never get published anywhere? Craig
[jira] Created: (TOMAHAWK-893) Incorrect filter mapping documentation for the Tomahawk Extensions Filter
Incorrect filter mapping documentation for the Tomahawk Extensions Filter - Key: TOMAHAWK-893 URL: https://issues.apache.org/jira/browse/TOMAHAWK-893 Project: MyFaces Tomahawk Issue Type: Bug Components: Tabbed Pane Affects Versions: 1.1.5-SNAPSHOT Reporter: Craig McClanahan Among other places, the documentation at http://myfaces.apache.org/tomahawk/extensionsFilter.html tells you to map the extension filter to the URL pattern: /faces/myFaces/extensionResources/* in addition to mapping it to the same path as the JSF servlet. However, at least for the Tabbed Pane component, this does not work ... it causes the exception message stating that resources could not be delivered, and references the documentation URL above. The Tomahawk examples in the trunk use: /faces/* instead, and that does indeed seem to work. The docs and wiki pages should be updated to reflect this. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TOMAHAWK-894) User specified style classes do not behave as expected
User specified style classes do not behave as expected -- Key: TOMAHAWK-894 URL: https://issues.apache.org/jira/browse/TOMAHAWK-894 Project: MyFaces Tomahawk Issue Type: Bug Components: Tabbed Pane Affects Versions: 1.1.5-SNAPSHOT Reporter: Craig McClanahan The TLD docs for the t:panelTabbedPane have these definitions for two of the style class overrides: activeTabStyleClassStyle class of the active tab cell inactiveTabStyleClass Style class of the inactive tab cells This implies to the reader that I can say something like: t:panelTabbedPane ... activeTabStyleClass=menu-sel inactiveTabStyleClass=menu .../ and expect my custom style classes to take effect. However, that is not what actually happens, because the component still emits the default Tomahawk style class first (myFaces_panelTabbedPane_activeHeaderCell or myFaces_panelTabbedPane_inactiveHeaderCell). That means my styles get ignored *unless* I create a cascade in my stylesheet definitions, or I use the !important modifier on EVERY SINGLE ENTRY. That is very poor usability -- it would be much better to *replace* the default style class when the user specifies one, so they don't have to go through all the pain of figuring out why their styles seem to be ignored. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TOMAHAWK-894) User specified style classes do not behave as expected
[ https://issues.apache.org/jira/browse/TOMAHAWK-894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12472070 ] Craig McClanahan commented on TOMAHAWK-894: --- It should go without saying that, if this kind of change is made to Tabbed Pane, the same philosophy would be consistently applied across the entire component library. User specified style classes do not behave as expected -- Key: TOMAHAWK-894 URL: https://issues.apache.org/jira/browse/TOMAHAWK-894 Project: MyFaces Tomahawk Issue Type: Bug Components: Tabbed Pane Affects Versions: 1.1.5-SNAPSHOT Reporter: Craig McClanahan The TLD docs for the t:panelTabbedPane have these definitions for two of the style class overrides: activeTabStyleClassStyle class of the active tab cell inactiveTabStyleClass Style class of the inactive tab cells This implies to the reader that I can say something like: t:panelTabbedPane ... activeTabStyleClass=menu-sel inactiveTabStyleClass=menu .../ and expect my custom style classes to take effect. However, that is not what actually happens, because the component still emits the default Tomahawk style class first (myFaces_panelTabbedPane_activeHeaderCell or myFaces_panelTabbedPane_inactiveHeaderCell). That means my styles get ignored *unless* I create a cascade in my stylesheet definitions, or I use the !important modifier on EVERY SINGLE ENTRY. That is very poor usability -- it would be much better to *replace* the default style class when the user specifies one, so they don't have to go through all the pain of figuring out why their styles seem to be ignored. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Patch Branch?
On 1/5/07, Sean Schofield [EMAIL PROTECTED] wrote: A patch release certainly would be a good idea but it takes time and resources to pull off each release. Its probably worth the effort since we tend to shoot ourselves in the foot when we release a whole set of features that sometimes contain radical changes and have not been tested extensively. Although it takes more effort, it might be nice to always have a patch branch available and then have an informal discussion on the dev list about which fixes belong in the patch vs. the next major release. Its the major refactoring that tends to cause problems due to our lack of unit tests. FWIW, this is the path we're going to follow for Shale. The 1.0.4 release is about to happen (vote in progress), and we created a SHALE_1_0_X branch to allow us to do any patch releases needed (1.0.5, ...). Feature development (towards a 1.1 release) will *only* happen on the trunk, so the fact that the trunk might be unstable at a particular point in time will have no effect on our ability to, say, fix a security vulnerability quickly. Craig Sean On 1/5/07, Stan Silvert [EMAIL PROTECTED] wrote: Stan, do you have the JIRA issue and svn revision(s) for the portlet bug fix? I need to know if it affects Shared or just Core. -- Wendy It's just core. http://issues.apache.org/jira/browse/MYFACES-1481
Re: Reason behind jsf_sequence?
On 12/21/06, lightbulb432 [EMAIL PROTECTED] wrote: Thanks for the detailed response. How would the server generally tell which came from which window using jsf_sequence? Because each window would postback the id rendered in that page, telling the server which ViewState to associate to process update/action logic. Does the server actually store the ViewState associated with EVERY single jsf_sequence number? I'd imagine that it'd only store it for what it deems to be each separate sequence of tasks (e.g. in a given window), then overwrite/update that ViewState associated with one window, but keep the other ViewState around for when that one comes in. That's why I'm wondering how the server knows which jsf_sequence number is associated with which other jsf_sequence number as part of the same window... (I wonder if any of what I said was coherent...?) I'll try to explain my question: You open one window and go to the page and get a jsf_sequence of 332 - the server creates a component tree on the server in reponse and associates it with jsf_sequence 332. You open another window and get a jsf_sequence of 154 and similar things occur. In the first window you submit a form and get a jsf_sequence of 778. Now does the server have 3 component trees in its memory? (One per sequence number?) Or just 2? (One per window?) I'd imagine it'd be the latter. But if so, how does it know that the component tree of 332 should be overridden by component tree associated with 778? Wow, I'm so confused...I'm pretty sure I'm not even thinking about this in anywhere near the right way! The best way to address your confusion would be to look at the actual source code, and see what actually happens for yourself. The source code for both MyFaces and the JSF RI is open source ... you'd answer your questions a lot faster by just taking a look at what actually *does* happen. Craig Jacob Hookom wrote: When a postback occurs, the ViewState is restored from the previous request-- in the case of: Client: The ViewState is serialized and posted back to the server-- so you could render a page, come back 5 hours later and click a button, sending the state you have stored in the page back to the server for use. Server: The ViewState is stored on the server, so the page only has a sequence number to identify, on postback, which rendered state we should use. lightbulb432 wrote: That's a good point. Few follow ups below: 1) Could you please explain what, on a high level, the general algorithm used by the server would be to see whether the state is part of the same sequence of activities? e.g. if I open up two windows and am doing two different things at the same time, couldn't potentially the jsf_sequences in the first window be 1,3,5,7,9... and for the second window be 2,4,6,8,10...? There is no continuity with ViewState-- nor is there an expectation on the 'sequence' of identifiers, it could be any unique number. Theoretically, you could store ViewState globally in the application scope, handing out identifiers from one, shared sequence number. So I think there's some confusion with the term 'sequence' here, since it should just be 'unique id' or 'primary key' How would the server generally tell which came from which window using jsf_sequence? Because each window would postback the id rendered in that page, telling the server which ViewState to associate to process update/action logic. 2) A somewhat related question I have is what is the difference between the back button problem for client-side and server-side state saving? From what I've read in articles/posts/books, I get the impression that it's a bigger problem with server-side than client-side state saving (e.g. even your post singled out server-side). I know that the state is stored in the actual page as a hidden field with client-side, but I can't conceptualize how that solves the problem...after all, if you hit the back button, aren't you looking at an outdated component tree even with client-side, because that's what the hidden field has stored? When you use client-side state saving, you, the client, are always passing in the page state you are currently viewing, there's no opportunity to become disjoint from the server state because it's all on the client. Original implementations of server-side state did not have any uid/sequence associated, so as you hit the back and forward button, there was opportunity for disconnect on what version of 'main.faces' you were actually working with. Since server-side state now pases a uid/sequence on postback, there's no question as to which version of 'main.faces' you were currently viewing. 3) You mentioned that jsf_sequence is used with server-side state saving, but I've noticed it in client-side state-saving's generated HTML as well. Could you perhaps describe how it would be used with client-side? (Same reason as for server-side? I'm basically wondering why you
Re: spring conversation start (@manfred)
On 12/19/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: Just out of curiousity, where did they add it? I don't see any reference to updateActionListener in 1.2. it is named setPropertyActionListener in the spec and in trinidad setActinListener Thanks ... I had not recalled that from when I last did a detailed review of all the 1.2 changes. Hmm, between that and f:valueChangeListener, JSF has a pretty good analog to the Beans Binding JSR for Swing (JSR-296) :-), but only if you're using JSP :-(. I presume that the alternative view handlers like Clay and Facelets will deal with that issue on their own. -M Craig By the way, is this similar to (or identical to) your idea for a preupdate() method in Shale's ViewController (SHALE-338)? If so, I still like the idea ... just need to see the follow through :-). Craig Just my $0.02 -M On 12/20/06, Werner Punz [EMAIL PROTECTED] wrote: Craig McClanahan schrieb: One of the architectural approaches that MyFaces developers seem to do pretty often, even when they don't have to, is think of everything as needing a component. To me, this involves the person building the view in decisions that really belong to the person working on the business logic. Yes, it's often the same person, but where is the separation of concerns? That was indeed the concerns of the original scope tag (I am using it currently btw. it is excellent work) the original intent was to have a viable replacement for savestate which would allow quick and dirty scoping with a a visual/tag approach. Mario did this approach and he solved it in an excellent way and yes, there is a break in separation of concerns and it was intended by design to ease the development of small applications, you basically push the scope control and parts of the transaction handling into the visual part. But the idea was to have a tag like way for those things, and if you need it differently (which many apps do but many small ones dont) have other frameworks deal with it. Now Mario, now he is moving into the Spring domain with his stuff, seems to be covering, let other frameworks do the scope control approach, as well. Btw. The scope tag of Mario is really excellent you should give it a try, but I agree, separation of concerns is not really there and cannot be by design principle, but there are other frameworks and solutions to deal with this. -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: spring conversation start (@manfred)
On 12/19/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: By the way, is this similar to (or identical to) your idea for a preupdate() method in Shale's ViewController (SHALE-338)? If so, I still like the idea ... just need to see the follow through :-). :) I am on it, but got blocked by other *tasks* Boy do I know *that* story :-). Looking forward to the results, whenever they happen, although we're really close to rolling 1.0.4 now, so it might have to wait for the next feature release. Stay tuned -M Craig Craig Just my $0.02 -M On 12/20/06, Werner Punz [EMAIL PROTECTED] wrote: Craig McClanahan schrieb: One of the architectural approaches that MyFaces developers seem to do pretty often, even when they don't have to, is think of everything as needing a component. To me, this involves the person building the view in decisions that really belong to the person working on the business logic. Yes, it's often the same person, but where is the separation of concerns? That was indeed the concerns of the original scope tag (I am using it currently btw. it is excellent work) the original intent was to have a viable replacement for savestate which would allow quick and dirty scoping with a a visual/tag approach. Mario did this approach and he solved it in an excellent way and yes, there is a break in separation of concerns and it was intended by design to ease the development of small applications, you basically push the scope control and parts of the transaction handling into the visual part. But the idea was to have a tag like way for those things, and if you need it differently (which many apps do but many small ones dont) have other frameworks deal with it. Now Mario, now he is moving into the Spring domain with his stuff, seems to be covering, let other frameworks do the scope control approach, as well. Btw. The scope tag of Mario is really excellent you should give it a try, but I agree, separation of concerns is not really there and cannot be by design principle, but there are other frameworks and solutions to deal with this. -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: spring conversation start (@manfred)
On 12/19/06, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! Our plan was to implicit start a conversation as soon as a conversation been will be created through spring. Well, to know which conversationContext we are currently working in (this context is required for multiple window awareness) we have to add a request parameter to every rendered url. This already works pretty well, BUT one has to ensure that the s:startConversation tag is the very first on a page using conversations to allow the system to configure itself appropriate so that the url parameter will be appended. At least, the s:startConversation has to be before e.g. the form stuff. Now, with implicit started conversations this is not that easy any more. I see two solutions: 1) still support the startConversation (in addition to the implicit started one for sure). In fact I'll keep backward compatibility anyway, so this will happen anyway. 2) standardize the backing-bean concept (aka ViewController) Technically spoken: We have a PhaseListener which try to lookup a bean using a name derived from the viewId (like shale's ViewController). If this bean is in conversation scope (or one of its injected properties if you have request scoped backing-beans - like me ;-) ) this would have started a conversation then and the system is fine again. What do you think, would someone see such a standardization as a bad thing? IMHO having such a view controller concept would help much (not only for conversations), e.g. we too can have those prerender methods etc we often would like to have. One of the architectural approaches that MyFaces developers seem to do pretty often, even when they don't have to, is think of everything as needing a component. To me, this involves the person building the view in decisions that really belong to the person working on the business logic. Yes, it's often the same person, but where is the separation of concerns? Given that statement to show my biases :-), there are two aspects of the way that Shale's dialog manager deals with these issues that you might want to take a look at: * Dialog instances can be started programmatically, or by looking for a special prefix on the logical outcome returned by an action. Nothing at all needs to be placed in the page itself for this to work ... and a particular page can be reused inside or outside a dialog. * Instead of explicitly modifying the URL (as described above), or adding a custom HTTP header (as Seam used to do ... don't know what 1.1 does at the moment), the dialog identifier (and any other related stuff) is stored as a generic attribute on the view root component. Typically this will be stored (for a Shale app) in the prerender() method ... the corresponding generic way would be a before render response event handler in a phase listener. The latter approach has an advantage in that you can pass any sort of state that is serializable (and therefore get t:saveState out of your pages too! :-), and a disadvantage that it doesn't react well to the redirect-after-post pattern. But it is worth taking a look at. Ciao, Mario Craig
Re: spring conversation start (@manfred)
On 12/19/06, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi Craig! One of the architectural approaches that MyFaces developers seem to do pretty often, even when they don't have to, is think of everything as needing a component. Hehe, yes indeed. But I'll try to move away from such approaches, the Spring Conversation integration should no longer need them, even if supported. * Dialog instances can be started programmatically Yes, thats easy. or by looking for a special prefix on the logical outcome returned by an action. Thats something we have to take a look at, though, we don't want to build a full featured dialog framework. Lets go small steps, maybe spring-webflow fits in there, but for sure shale-dialog will have its place here too. If you haven't looked at Shale Dialog lately (last couple of months), it has been substantially enhanced -- it might suit your needs directly. A couple of interesting tidbits: * Totally independent of view controller (although it works fine in conjunction with view controller if you want) * Separated API and implementation -- currently two implementations available (a basic one much like the original but with lots of bugfixes, and one based on Jakarta Commons SCXML). An implementation that integrates directly with Spring's conversation stuff (but still used the same APIs) would be interesting to take a look at. * Instead of explicitly modifying the URL /snip ... the dialog identifier (and any other related stuff) is stored as a generic attribute on the view root component. Hey, this one is interesting, I'll give it a try. The latter approach has an advantage in that you can pass any sort of state that is serializable (and therefore get t:saveState out of your pages too! :-), and a disadvantage that it doesn't react well to the redirect-after-post pattern. But it is worth taking a look at. The advantage of the url-parameter method is to allow to easily render links WITHOUT the conversationContext attribute and thus a new conversation context will be started. Maybe a mix of both strategies will be fine ... Indeed, I should have mentioned that Shale Dialog does support a mixed case, where you *can* start a conversation using a request parameter. That turned out to be useful when you wanted a popup dialog to have its own context, independent of the one for the parent window or frame. The docs[1] are reasonably up to date, plus there are some sample and test apps for both dialog implementations. Thanks alot! Ciao, Mario Craig [1] http://shale.apache.org/shale-dialog/
Re: spring conversation start (@manfred)
On 12/19/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: Well, sometimes somethings work well, even the design is not that best. Regard the separation, I think that is true for the updateActionListener as well. I love that guy, Trinidad has a similar and now the spec folks saw what's useful und added it Just out of curiousity, where did they add it? I don't see any reference to updateActionListener in 1.2. By the way, is this similar to (or identical to) your idea for a preupdate() method in Shale's ViewController (SHALE-338)? If so, I still like the idea ... just need to see the follow through :-). Craig Just my $0.02 -M On 12/20/06, Werner Punz [EMAIL PROTECTED] wrote: Craig McClanahan schrieb: One of the architectural approaches that MyFaces developers seem to do pretty often, even when they don't have to, is think of everything as needing a component. To me, this involves the person building the view in decisions that really belong to the person working on the business logic. Yes, it's often the same person, but where is the separation of concerns? That was indeed the concerns of the original scope tag (I am using it currently btw. it is excellent work) the original intent was to have a viable replacement for savestate which would allow quick and dirty scoping with a a visual/tag approach. Mario did this approach and he solved it in an excellent way and yes, there is a break in separation of concerns and it was intended by design to ease the development of small applications, you basically push the scope control and parts of the transaction handling into the visual part. But the idea was to have a tag like way for those things, and if you need it differently (which many apps do but many small ones dont) have other frameworks deal with it. Now Mario, now he is moving into the Spring domain with his stuff, seems to be covering, let other frameworks do the scope control approach, as well. Btw. The scope tag of Mario is really excellent you should give it a try, but I agree, separation of concerns is not really there and cannot be by design principle, but there are other frameworks and solutions to deal with this. -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: Option for NavigationHandler to support viewIds as outcome
On 10/31/06, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! 1.) Seperate NavigationHandlerImplIMHO, this is a must! I think we should *not* implement stuff whichsilently changes/enhances the behaviour - especially in myfaces-impl!!The TCK might forbid this change anyway ... 2.) Configurable Optionnot required, as everyone can configure this NH in faces-config.xml.In particular, if you decide to implement this feature, consider packaging it inside a separate JAR file with its own embedded META-INF/faces- config.xml file that defines the custom navigation handler. That way, it is self configuring -- to use the feature, just drop the JAR into your app.Craig 3.) Custom NH code in the wiki with a discouraged noteThis might be a good compromise. 4.) Not at allI do not mind ;-)5) Add the new NH to the sandbox (but not configured by default) I like it to put stuff to the sandbox first and see if the community iswilling to use them something like the time will tell if its worth.Ciao,Mario
Re: Tomcat SNAPSHOT is missing, 1.2 impl cannot be built
On 10/31/06, Dennis Byrne [EMAIL PROTECTED] wrote: Looks like the 1.2 branch [2] does not work on a fresh co because the tomcat jars have been removed from the apache repo [1].Does anyone know where they have gone to?I seem to remember the Mortbay jars working quite well for us.Is there any reason this was changed? Dennis Byrne[1] http://people.apache.org/repo/m2-snapshot-repository/org/apache/[2][INFO] [ERROR] BUILD ERROR[INFO] [INFO] Failed to resolve artifact.Missing:--1) org.apache.tomcat:jasper-el:jar:6.0.0-SNAPSHOT Didn't Tomcat 6.0 just go final? If so, it'd probably be worth updating to the final version number.Craig Try downloading the file manually from the project website.Then, install it using the command:mvn install:install-file -DgroupId=org.apache.tomcat -DartifactId=jasper-el \-Dversion= 6.0.0-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/filePath to dependency:1) org.apache.myfaces.core:myfaces-api:jar:1.2.0-SNAPSHOT2) org.apache.tomcat:jasper-el:jar:6.0.0-SNAPSHOT2) org.apache.tomcat:el-api:jar:6.0.0-SNAPSHOTTry downloading the file manually from the project website.Then, install it using the command:mvn install:install-file -DgroupId=org.apache.tomcat -DartifactId=el-api \ -Dversion=6.0.0-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/filePath to dependency:1) org.apache.myfaces.core:myfaces-api:jar:1.2.0-SNAPSHOT2) org.apache.tomcat:el-api:jar:6.0.0-SNAPSHOT --2 required artifacts are missing.for artifact:org.apache.myfaces.core:myfaces-api:jar:1.2.0-SNAPSHOTfrom the specified remote repositories:central ( http://repo1.maven.org/maven2),java.net (https://maven-repository.dev.java.net/nonav/repository),apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository),myfaces-repo (http://myfaces.zones.apache.org/dist/maven-repository )
Re: Option for NavigationHandler to support viewIds as outcome
On 10/29/06, Ernst Fastl [EMAIL PROTECTED] wrote: Hi!At the moment when no navigation case for an outcome is foundthe navigationHandler decides to stay at the same view. I thinkan option for web.xml would be useful to tell the navigationHandlerif no navigation case for an outcome is found, but the outcome matches a viewId to navigate to this view id.This idea was mainly driven by a lot of jsf-projects where I saw for eachview id:navigation-rulefrom-view-id*/from-view-id navigation-casefrom-outcomeviewId/from-outcometo-view-id/viewId.xhtml/to-view-idredirect//navigation-case ...which seems kind of unnecessary to mewhat do you think about that?I think that the developers of projects like that did not actually understand the reasoning behind the standard JSF approach to navigation. The basic theory is that an action method should return a *logical outcome* -- a string that says this is what happened, not a string that says go to this page next. That decision should be left to the architect who is gluing things all together. In particular, you should *want* to have the ability to remodel your view identifiers namespace, *without* having to go modify every single action method that returns a view id instead of a logical outcome. Consider the following use case to understand what's going on here. Lots of web sites have search text fields (like Google's search text field) that can be used to select the relevant database information. Let's assume, for the purposes of discussion, that such a text field exists to select a customer from your database of current customers. Next, let's look at this issue from the viewpoint of the developer who is writing the action method that responds to a user entering a value into the search field. If you are following good application design principles, this person will *not* know (or care) about what page should be displayed next. Instead, he or she will be focused on the fact that there are three logical outcomes that can result from a database search based on criteria specified in the search field: * No matching results were found.* Exactly one matching result was found.* More than one matching result was found.In a very simple minded application (or a RAD-developed prototype), you might be satisfied with only doing one thing in all three cases. In a user-friendly app, on the other hand, you might want to react like this: * No results -- show the search criteria page again with a message saying I'm sorry, no matches were found -- please refine your search criteria.* Exactly one result -- go directly to the next step in the user conversation, having selected a particular master record.* More than one result -- go to a page that lists the available matches and lets the user select the desired one.The key issue here ... THE DEVELOPER WRITING THE ACTION METHOD FOR THE SEARCH SHOULD NOT NEED TO KNOW WHAT HAPPENS NEXT. The important responsibility is to report this is what happened (one of the three logical outcomes). It's up to the rest of the application to react to this event. And, over the lifetime of the application, this reaction might change -- but you should *not* have to go back and do the original code over again. Given this background, I believe that the proposed feature here is *not* a good idea. It is counter to the basic philosophy behind the navigation handler architecture that the JSF spec defines. regardsErnstCraig McClanahan
Re: Option for NavigationHandler to support viewIds as outcome
On 10/30/06, Martin Marinschek [EMAIL PROTECTED] wrote: Hi Craig,you have been argumenting into this direction before, and I'm sorry todisagree completely. What JSF does in the standard is good forprojects where you have this necessity of different roles for page development and back-end development.It's not a matter of different roles. The design principles I advocate are the same whether there is one developer performing multiple roles, or different developers (or developer groups) performing the different roles. The architectural issues here are exactly the same in either case.Generally - for small projects, and the majority of web-projects are still small projects, the person writing the navigation-handling code,the page, and the backing-bean will be the same, so why not give themthe ability to have a convention-over-configuration approach? You can always override convention-over-configuration by supplyingconfiguration!Because that user will be crying alligator tears a year from now, or a month from now, when the person responsible for the overall organization of the webapp changes the set of view identifiers that represents the UI of an app. WHY SHOULD THIS REQUIRE CHANGES IN THE BUSINESS LOGIC???. That is a cross-linkage between view tier and model tier that I find unacceptable in large scale apps. You have a seductive argument with respect to small scale apps. But I can tell you from 30 years of professional software development experience that managers tend to buy in to this kind of attitude at the prototype stage, when ongoing application maintenance is not a consideration. And those types of people tend to be really unhappy when the effects of this type of decision cause their maintenance budgets to skyrocket. The scale of the app does not actually matter -- the percentage of the overall budget that must be allocated to reworking previously running code is *always* a major consideration. Furthermore, I seem to resemble that in the discussion aboutannotations you've made the same proposal as Ernst has at the beginning of this discussion - writing a custom navigation-handlerwhich enables one to optionally not configure navigations, and nothandle navigation via annotations.I am *adamantly* in the no annotations for navigaiton camp ... navigation is absolutely *not* something that should be done with annotations. Doing so would have the same effect as implementing the suggested approach -- it would be requiring the person developing the server side business logic to be intimately aware of view tier considerations like what view should I show next?. Doing so makes it basically impossible to reuse business logic in scenarios like:* Migrating a non-AJAX app to be AJAX-enabled* Using the same business logic for REST-based or SOAP-based web services In short, I believe that requiring the developer of an action method to know anything about what the view tier will do next is a ***very*** bad idea.You might note that the Shale Tiger Extensions have no provision for annotation based navigation. That is a deliberate design choice, not one based on limited development time :-) regards,MartinCraig
Re: Option for NavigationHandler to support viewIds as outcome
On 10/30/06, Mario Ivankovits [EMAIL PROTECTED] wrote: In reality there is a dependency between two pages, there is a silentcontract how to prepare the managed beans so that the destination pageknows what to display (and I think the f:param stuff is useless here). So more often than not you'll use a updateActionListener to set stuff onthe destination backing bean. And voilla, you'll have hard dependencybetween these two pages.This is an important point, no matter how you architect your navigation. shameless-plugThat is why Shale's view controller has a prerender() method ... you are encouraged to use that method in the destination page to pull data that this page needs out of the model, rather than having the origin page push data into the destination page (or some request scoped objects whose names are known to both). That way, coupling is minimized to something like passing primary keys -- and I like the convention of always passing, say, a customerId, in the same place throughout the application (independent of particular pages), to minimize direct coupling between any two particular pages. This approach also makes it *much* easier for your application to support bookmarkable GET URLs that pass primary keys with request parameters./shameless-plugCraig
[jira] Commented: (MYFACES-1383) FacesContextFactoryImpl issue using trinidad any myfaces core
[ http://issues.apache.org/jira/browse/MYFACES-1383?page=comments#action_12445431 ] Craig McClanahan commented on MYFACES-1383: --- Looking at this issue again, it seems to me that it would be better to recreate the FacesContext between the execute and render phases of the lifecycle. We would need to preserve messages and some other things, but nothing to difficult to preserve. This would allow wrappers to update their wrapping when the external context changes. I would recommend that this suggestion be implemented ... not just for consistency with the other bridges, but because the portlet lifecycle is different from a standard webapp lifecycle in one crucial respect. Consider the scenario where you have six portlets on a particular page, all created with MyFaces (yeah :-). On any given request, *one* of the six portlets will go through the Restore View through Invoke Application phases, while *all* six portlets will have the Render Response phase executed. Thus, it is important for portlet developers to understand that they need to be prepared to rerender their current contents at any time, whether or not they were the portlet that received this particular postback. The easiest way to do that is to treat a single portlet request as two JSF requests ... one for the execute part of the lifecycle, and one for the render part. And that, by the way, is why the Lifecycle API has these two subsets of the overall lifecycle split into two methods. FacesContextFactoryImpl issue using trinidad any myfaces core - Key: MYFACES-1383 URL: http://issues.apache.org/jira/browse/MYFACES-1383 Project: MyFaces Core Issue Type: Bug Components: Portlet_Support Affects Versions: 1.1.5-SNAPSHOT Environment: pluto 1.1-dev, tomcat 5.5.17 running on linux 2.6.17 Reporter: nicolas kalkhof trinidad won´t run in a portlet environment. problem is, that FacesContextFactoryImpl does not extend ServletFacesContextImpl. therefore this is an internal myfaces core problem that could hopefully be fixed. stacktrace of the crashing portlet using myfaces and trinidad: javax.portlet.PortletException: org.apache.myfaces.trinidadinternal.context.FacesContextFactoryImpl$CacheRenderKit at org.apache.myfaces.portlet.MyFacesGenericPortlet.handleExceptionFromLifecycle(MyFacesGenericPortlet.java:253) at org.apache.myfaces.portlet.MyFacesGenericPortlet.facesRender(MyFacesGenericPortlet.java:407) Nested Exception is java.lang.ClassCastException: org.apache.myfaces.trinidadinternal.context.FacesContextFactoryImpl$CacheRenderKit at org.apache.myfaces.portlet.MyFacesGenericPortlet.facesRender(MyFacesGenericPortlet.java:387) at net.portlets.logon.LogonPortlet.doView(LogonPortlet.java:88) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [Faces 1.2] RespStMgr.isPostback()
On 10/19/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: no, I mean,why not just abstract isPost() method and letting the impls deal with that?It looks like the JSF 1.2 EG used this pattern a lot, when they added new methods to existing classes ... see for example FacesContext.getELContext(). Leaving the new method abstract would have caused old applications loading this class to break, so they had to make the new methods concrete. Why they didn't just go ahead and implement the newly desired behavior is a question for them, though. Craig
[jira] Commented: (MYFACES-1467) Validation doesn't run for required fields if submitted value is null
[ http://issues.apache.org/jira/browse/MYFACES-1467?page=comments#action_12442362 ] Craig McClanahan commented on MYFACES-1467: --- On a sidenote - I believe that it is bad to skip validation at all if the value of a field is null. I haven't looked to see if this changed in 1.2, but I can tell you with certainty that this behavior is *exactly* what was intended for version 1.0. The reasoning was that, if there is no value, then there is nothing to be validated. Indeed, this is the entire reason that required exists as a property, instead of as a validator, in the first place. Craig Validation doesn't run for required fields if submitted value is null - Key: MYFACES-1467 URL: http://issues.apache.org/jira/browse/MYFACES-1467 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 1.2.0-SNAPSHOT, 1.1.5-SNAPSHOT Reporter: David Chandler Assigned To: Matthias Weßendorf Attachments: patch.txt A component with a required value will not fail validation as expected if the submitted value is null. This issue is not seen normally because browsers send the value for an empty text field as an empty string. That is, the POST data for an empty field1 will contain the field name but no value, like field1=field2=something. However, if you use a man-in-the-middle proxy such as Paros to remove fieldname= from the POST data, the submitted value will be null. UIInput.validate() skips validation for null submitted values, but since requiredness is also part of validation, the requiredness check gets skipped, too. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-1467) Validation doesn't run for required fields if submitted value is null
[ http://issues.apache.org/jira/browse/MYFACES-1467?page=comments#action_12442364 ] Craig McClanahan commented on MYFACES-1467: --- what do you say to my reasoning for cases where required is either true or false, depending on the value of another component? I say two things: * JSF validation is all about single values -- cross field validation is left to the application, or to frameworks built on top of JSF (i.e. it's reasonable to build a validation framework extending JSF that does this kind of thing, but it's out of scope for the JSF validation APIs themselves, at least for 1.0). * Firing validators on null values doesn't solve your use case anyway. You are going to need to do something application specific anyway. The current APIs are nowhere near rich enough to express all of the possible cross field scenarios that you would need to cover to be complete. In the short term (i.e. before you can convince some future JSF expert group to change this), the best advice might be to build a standalone validation framework that deals with all the possible cross-field type issues, rather than trying to coerce individual components to behave differently than the JSF standard ones do. Also, keep an eye on JSRs like #303 (annotations based validation rules), which will be playing in this same space. Validation doesn't run for required fields if submitted value is null - Key: MYFACES-1467 URL: http://issues.apache.org/jira/browse/MYFACES-1467 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 1.2.0-SNAPSHOT, 1.1.5-SNAPSHOT Reporter: David Chandler Assigned To: Matthias Weßendorf Attachments: patch.txt A component with a required value will not fail validation as expected if the submitted value is null. This issue is not seen normally because browsers send the value for an empty text field as an empty string. That is, the POST data for an empty field1 will contain the field name but no value, like field1=field2=something. However, if you use a man-in-the-middle proxy such as Paros to remove fieldname= from the POST data, the submitted value will be null. UIInput.validate() skips validation for null submitted values, but since requiredness is also part of validation, the requiredness check gets skipped, too. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Nice job on recent reorg
On 10/7/06, Rahul Akolkar [EMAIL PROTECTED] wrote: On 10/7/06, Bruno Aranda [EMAIL PROTECTED] wrote: hehe wrong list... but now that you say that, as we are using shale-test for testing, in the implementation of MyFaces 1.2 there is one test (UIComponentTagUtils) that fails, because it tries to use a method specific of JSR-252 in the Application.getExpressionFactory: java.lang.UnsupportedOperationException at javax.faces.application.Application.getExpressionFactory(Application.java:74) ... Of course, this UnsupportedOperationException is thrown by the Application class (as mandated by the spec), but not in the Application myfaces implementation (ApplicationImpl). What do I have to do to use ApplicationImpl then? Is that possible?snip/You should be able to use JSR-252 specific methods in the next shale-test release (thanks to Craig). See SHALE-304 [1] for all thedetails, particularly r453841 in the commits tag. In short, this mockapplication class [2] will be available for such tests. As it happens, I've been working on the 1.2 support in shale-test over the last few days. ExpressionFactory, plus a simulation of the standard set of ELResolvers outlined in Section 5.6.2, is next on my list. With ApacheCon coming up, I should get a good chunk of time to wrap this up. -Rahul[1] http://issues.apache.org/struts/browse/SHALE-304 [2] http://svn.apache.org/repos/asf/shale/framework/trunk/shale-test/src/main/java/org/apache/shale/test/mock/MockApplication12.java Thanks, BrunoCraig
Re: [offtopic][rollcall] Who's Going To Be At Apache Con?
On 10/5/06, Sean Schofield [EMAIL PROTECTED] wrote: Can we start a roll call of who is going to be at Apache Con and onwhat days?I'm posting this to both Shale and MyFaces list since Ifeel there is a lot of overlap between our two groups.I will be there Tuesday (late afternoon) - Friday (leaving early in the morning) I'm arriving Monday late afternoon, leaving Friday night. SeanCraig
Re: Getting rid of the wish issue type
On 9/22/06, Mike Kienenberger [EMAIL PROTECTED] wrote: On 8/17/06, Mike Kienenberger [EMAIL PROTECTED] wrote: I think we should get rid of the wish issue type. I don't see that we're likely to have someone surfing the jira issue tracker looking for things to do. If someone wants to wish for something, the user list (or maybe a wiki page) seems like a better place to do it. All this issue type is doing is collecting work that other people are not willing to do themselves. We already have a new feature type that people use when they plan to provide patches to implement their new feature.No one objected to removing Wish as an issue type. Unfortunately, that appears to be beyond my ability to change in theJIRA system.Looks like it is defined here:Issue Type Scheme:Apache Default Issue Type SchemeSo maybe it's not something we can change solely for our project. One approach to this would be to clone the Apache Default Issue Type Scheme into a MyFaces Issue Type Scheme and make any adjustments, then assign this scheme to the MyFaces project(s). I did something like this for Shale (which shares a JIRA instance with Struts, but has slightly different requirements) and it has worked out pretty well. Craig
Re: Tobago and MyFaces
On 9/12/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: There was a gentleman agreement that there is no commit from Tobagosto MyFaces, after the toboago incubation was done.That is exactly ***not*** the expected scenario in an Apache TLP. All committers to MyFaces should be able to commit to any of the MyFaces code. Bernd and Volkerare committers of MyFaces.Interestingly, the SVN permissions already allow all of the Tobago committers to commit anything anywhere in MyFaces, as it should be. +1 on cleaning out the remaining cruft from the incubation process, and considering all MyFaces committers as being equal. I am fine to add the rest of them too!-MatthiasCraig On 9/13/06, Wendy Smoak [EMAIL PROTECTED] wrote: In the Tobago vote thread, Bernd Bohmann [EMAIL PROTECTED] wrote: The tobago team list is: http://myfaces.apache.org/tobago/team-list.html Is there some reason we're keeping a separate list for Tobago? The Tomahawk team list inherits from the myfaces-master pom, and shows everyone:http://myfaces.apache.org/tomahawk/team-list.html I can see on Jim's page [1] that there is a 'myfaces-tobago' svn auth group, but everyone in it is also in the 'myfaces' group and so has access to the entire myfaces codebase.Is this just something left over from incubation? Since the myfaces-tobago svn auth group isn't actually doing anything, let's ask Manfred to remove it.And let's also hook the Tobago build up to the myfaces-master pom as its parent, so that we can share the committer list (and reduce some other duplication, since the mailing lists are in both places now.) We're all MyFaces committers... anyone who is willing and able should feel free -- and welcome -- to work on any part of the project. Thoughts? [1] http://people.apache.org/~jim/committers.html -- Wendy--Matthias Wessendorf further stuff:blog: http://jroller.com/page/mwessendorfmail: mwessendorf-at-gmail-dot-com
Re: [VOTE] Release Apache Tobago 1.0.8
On 9/12/06, Bernd Bohmann [EMAIL PROTECTED] wrote: Not really.But I need a vote from 2 other pmc member.Can you encourage 2 pmc member to vote for the release.FWIW, this is the kind of thing that motivates a MyFaces committer is a MyFaces committer, as opposed to trying to segregate folks only interested in Tobago. On the other hand, the fact that only a small number of folks in the MyFaces committer community seem interested in Tobago is a danger signal. RegardsBerndCraig Matthias Wessendorf wrote: too late ? +1 ... sorry for the delay, Bernd On 9/13/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 9/12/06, Bernd Bohmann [EMAIL PROTECTED] wrote: Thanks Wendy, but I think the vote closed after 72 hours and I get 4 +1(non-binding). Is this not lasy consens [1][2]? [1] http://www.apache.de/foundation/glossary.html#LazyConsensus [2] http://www.apache.de/foundation/voting.html The relevant sections are: http://www.apache.de/foundation/voting.html#ReleaseVotes... and 'Binding Votes' at the top of the page, which doesn't have an anchor. I see you found the 'majority approval' section. :)Release votes are similar to that, except that releases can't be vetoed.(I've never seen a release that had a -1, though... usually the release manager will stop the vote and fix the problem.) Thanks, -- Wendy
Re: About the Partial Page Rendering Commit ...
On 8/24/06, Catalin Kormos [EMAIL PROTECTED] wrote: Hi guys,Sorry for the late reaction. Just want to say that i'm sorry about thesituation, I should have been more carefull, and this sort of things won'thappen next time. All your reactions were quite usefull and made me learn a lot about ASF.I don't think anyone feels that either Ernst or Catalin had any evil motives in all of this (I certainly don't). But it's pretty clear we (Apache) need to improve the education process for new committers (as they come on board in a particular project), and perhaps we can rearrange the steps for Google Summer of Code contributions (if the program happens again next summer), but having the ICLA gotten out of the way early. CraigBest regards,CatalinMatthias Wessendorf-4 wrote: Ernst, glad you replyed to some comments. The MyFaces community trys the best to help users with how OS development works. You are very welcome here. The ASF is not all about code, those the guide is important. One document to read is [1] if you have *enhancements* to that. they are welcome. Provide a patch for the infra team ;) I now think we should move back to work. Thanks for the contribution [1] http://www.apache.org/foundation/how-it-works.html On 8/23/06, Ernst Fastl [EMAIL PROTECTED] wrote: Hi There! Since the recent commit brought quite some comments and advices in different threads I'll try to comment on what I understand as the outcome of that discussions in this mail. For a substantial contribution like this, we'll need a CLA on file in any case (even if the code came in through a jira-issue). Is the original author of these classes willing to sign and fax in a CLA[2]? If so, that gets us over the first hurdle.If not, the files should definitely be removed. I signed and faxed it today in the morning, so you all can be sure that this is apaches code now. Sorry that I haven't done that before, I did not know that this is also necessary if another commiter commits the code for you. I should have gathered more information of the process of apache contributions - to be honest I just didn't think of any legal issues. I am not concerned about the icla or not I am more concerned about the fact that patches sent offline and not through Jira. I'm also sorry for that one. I just thought it would be good to provide some code which implements what I think came out of the initial discussions, before starting to talk on the mailing list of things that do not already exist. That was probably the wrong direction and I will try hard to communicate more efficiently with the community in the future. The second problem is one that Wendy pointed out ... lack of license headers on the source files. Again I can only apologize, I just didn't think of that - sorry. The sort of offline development. Sending offline a patch to a committer for letting him commit the stuff is to me a -1. Looks like a bypass. I really didn't mean to bypass confirmation or evaluation of the community. I just thougth if the code is commited to the sandbox that this doesn't cause any harm and all people that want to verify the code can take a look there and give feedback. Matthias, you're absolutely right - I'm just as concerned as you about offline development, and asked Ernst several times to engage in an discussion on the mailing list. All together I can only apologize for all those beginners misstakes. I am still new to Open Source Development and although it may have produced a different image I just had the best intentions. Thanks to all the comments that came up after this commit I belive I learned a lot of things about how the ASF works and will hopefully be able to avoid such beginners misstakes in the future. kind regards Ernst -- Matthias Wessendorf further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com --View this message in context: http://www.nabble.com/About-the-Partial-Page-Rendering-Commit-...-tf2153656.html#a5962006 Sent from the My Faces - Dev forum at Nabble.com.
Re: [dialog] Basic button functionality
On 8/24/06, Sean Schofield [EMAIL PROTECTED] wrote: No I'm not proposing we deal with generating HTML rendering businessas far as dialogs are concerned.[I'll post a more detailedexplanation on the shale dev list where that belongs.]@Adam: If you're not already subscribed to shale dev we'd love to have you over there.Specifically, we could benefit from your insightregarding dialogs.I suspect what Adam is asking about is Shale getting in the business of creating visual components like buttons in order to implement the Next/Previous type of thing. That's an area I have wanted to shy away from, and this kind of thing is a case in point for why. No matter what we do, our navigation buttons are going to stick out like a sore thumb visually, unless the user takes great pains to style them similar to whatever theming or skinning strategy the developer is using on all the other components. That being said, the logical concept that a general purpose dialog architecture might want to support explicit mechanisms for wizard-style navigation is well taken. But we should strive to make it possible to incorporate existing button or hyperlink components from your favorite component library, instead of imposing our own. Craig@Everyone Else: This goes for you too.If you're using JSF you'll want to check out Shale which just builds on JSF and provides a lot ofcool stuff missing from the spec.SeanOn 8/24/06, Gary VanMatre [EMAIL PROTECTED] wrote: From: Adam Winer [EMAIL PROTECTED] Wrong list, sure, but since you opened up the can of worms... Is Shale really planning on getting into the HTML-rendering business? What do you mean by HTML-rendering business? We have custom components that do rendering.Clay has been around better than a year now and provides rich view composition using various templating options.Clay is a component in of itself that simple builds a subtree of components using a mechanism other than JSP tags.The clay component renders it children.When using full html (tapestry like) views or full xml (tiles like) views, the clay component is the only child under the view root so it pretty much renderers the full page. -- Adam Gary
Re: Partial Page Rendering for tomahawk
On 8/22/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: I am not concerned about the icla or notAs a PMC member for Apache MyFaces, you *should* be concerned about this.Part of the responsibility that the ASF Board delegates to each PMC is to ensure that all code ultimately included in the project is covered by appropriate licensing, so that downstream users of Apache software can be assured that this is the case. For patches included as attachments on a JIRA issue, we provide a convenient way for the poster to grant a license specifically for this patch. Therefore, sending all patches from non-committers through JIRA helps create an audit trail, and is therefore a Good Thing. However, this will not be considered sufficient for large contributions, where the contributor is also asked to sign an Individual CLA[1]. How large is large? Clearly, we shouldn't need this for for a three-line patch submitted through JIRA with the appropriate radio button granting a license attrached. But would it have been OK to accept all of Trinidad as a humongous patch, simply by having someone have checked the button? Nope ... that is definitely large enough to require more. A contribution of this size (multiple source files and associated resources) is definitely at the point where the should in the page referenced below means REALLY REALLY should.Is the original author of these classes willing to sign and fax in a CLA[2]? If so, that gets us over the first hurdle. If not, the files should definitely be removed. The second problem is one that Wendy pointed out ... lack of license headers on the source files. While the details of this policy are currently being reviewed, standing practice is to use the complete header that you'll see on all the other MyFaces source files, in its entirety, at the top of every source file. As committers, this is something we should look for on incoming new source files before adding them to the source code repository. Because these files do not have such headers, they should be removed, and not re-added until both issues (CLA and license headers) have been addressed. The line-endings issue is something that should also be fixed, but it's not make-or-break to have source code in the repository. But having these broken means you'll have to answer to people like Wendy :-). I am more concerned about the fact that patches sent offlineand not through Jira.Even if they had been, that would not have been sufficient in this case, for the reasons outlined above. I mean, why ?Craig McClanahan [1] http://www.apache.org/licenses/[2] http://www.apache.org/licenses/icla.txt On 8/22/06, Martin Marinschek [EMAIL PROTECTED] wrote: For a substantial contribution like this, we'll need a CLA on file in any case (even if the code came in through a jira-issue). regards, Martin On 8/22/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 8/22/06, Ernst Fastl [EMAIL PROTECTED] wrote:Hello everyone, After verifying the patches I send him Catalin was so kind and commited the new sandbox component called PPRPanelGroup to the sandbox. Hi there!I think that's the commit I just commented on. :) Matthias already asked if there was a JIRA issue open, which might address my concern about whether we have (or need) a contributor license agreement [1] for the new code. [1] http://www.apache.org/licenses/index.html#clas -- Wendy -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces --Matthias Wessendorffurther stuff:blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: Proposal Jira (was Re: Partial Page Rendering for tomahawk)
On 8/22/06, Martin Marinschek [EMAIL PROTECTED] wrote: One clarification: For external contributions, a jira-issue definitelymakes sense.A behavior that both the Struts and Shale communities have adopted (albeit recently in the case of Shale :-) is to have a JIRA issue for pretty much any non-trivial change to the codebase. It's not necessarily that committers need to flow their proposed commits through attachments to those issues; it's more about being able to associate a commit with a particular issue (simply done by putting the appropriate MYFACES-x issue number somewhere in the text, and JIRA will notice that and add the commit log to the history of the issue). Whoever is release manager, and therefore is responsible for assembling the release notes, might actually get persuaded to do it for more than one release if this habit is followed, because JIRA will very nicely accumulate all the issues that have been tagged to be fixed in that release. Separately, I think there's a couple of lessons here for how Apache projects interact with Google Summer of Code participants:* Get the participants to sign an iCLA early on, so that their ultimate contributions won't have to go through a bunch of bureaucratic red tape at the last minute.* Develop a mini-guide to what is expected of GSoC code contributions (such as the license headers, setting up SVN properties correctly, and the like). * Make sure that new committers clearly understand the rules too.Regarding sandbox code, I can sympathize with Mario's point that this is somehow different than regular commits. BUT ... even sandbox project commits are done with an ultimate goal in mind. Even if it's an omnibus issue like add partial page refresh support to Tomahawk, it will help improve the overall discipline if we deal with sandbox commits according to the same process requirements as everything else. After all, the rest of the world might not understand the subtle differences that we (knowledgeable participants in the process) might take for granted. regards,MartinCraig On 8/23/06, Martin Marinschek [EMAIL PROTECTED] wrote: I really don't see the necessity for MyFaces committers to do all extensions of MyFaces through jira, if sufficient communication has happened on the developer list first. Why do you think that opening a jira-issue and adding patches will make us more efficient in the development process? regards, Martin On 8/22/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: what about using Jira first. for almost all commits ? I mean this makes us more efficent to follow the development process ;) So each change to API, non trivial enhancement, etc must! go through jira. WDYT ? -Matthias On 8/22/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: I am not concerned about the icla or not I am more concerned about the fact that patches sent offline and not through Jira. I mean, why ? On 8/22/06, Martin Marinschek [EMAIL PROTECTED] wrote:For a substantial contribution like this, we'll need a CLA on file in any case (even if the code came in through a jira-issue). regards, Martin On 8/22/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 8/22/06, Ernst Fastl [EMAIL PROTECTED] wrote: Hello everyone, After verifying the patches I send him Catalin was so kind and commited the new sandbox component called PPRPanelGroup to the sandbox. Hi there!I think that's the commit I just commented on. :) Matthias already asked if there was a JIRA issue open, which might address my concern about whether we have (or need) a contributor license agreement [1] for the new code. [1] http://www.apache.org/licenses/index.html#clas -- Wendy -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development andCourses in English and German Professional Support for Apache MyFaces -- Matthias Wessendorf further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Matthias Wessendorf further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces--http://www.irian.at Your JSF powerhouse -JSF Consulting, Development andCourses in English and GermanProfessional Support for Apache MyFaces
Re: Myfaces Wiki ComponentMaintainers
On 8/21/06, Werner Punz [EMAIL PROTECTED] wrote: Jurgen Lust schrieb: Op ma, 21-08-2006 te 11:14 -0400, schreef Mike Kienenberger: Do we want to list out who's responsible for components on the wiki? It seems like ththis would encourage having people send email directly an individual committer rather than the MyFaces community. Hmm, good point. Once things are checked into the repository, we should all be collectively responsible for the code. There are going to be people who have a lot more invested into a component, but does that require a tracking page?SVN logs will show who has been committing changes to a particular component. Personally I favour the way they do things at Gentoo Linux: instead of everyone being collectively responsible for the code, they have divided their committer community into groups, each with a project lead. For example, they have a Java group, an Apache group, etc. JurgenActually I just started the page to document which componentsare dojoized and which are not,the maintainers are not really mandatory on this,it just makes things easier... I like the idea with the groups btw...In every large open source project, it's natural that certain developers tend to focus on certain parts of the code. However, assigning formal ownership or responsibility -- or even implying that there is such a thing -- is not the way Apache projects work. We are all corporately responsible for all of the code, and have freedom to get involved with any of it. Need to coordinate, or ask who might be affected by a change you want to make? That's what the dev list is for.Craig
Re: Myfaces Wiki ComponentMaintainers
On 8/21/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: I get lot's of direct emails, I think Mike is right, that this can (orwill) increase the number of offline emails.You'd be amazed at how many personal Tomcat questions I still get, after not having worked on that project for several years, simply because my name is listed as an author on one of the developer guides :-). Craig
Re: How to configure the default renderers and component within a Shale-Test based unit test
On 8/20/06, Dennis Byrne [EMAIL PROTECTED] wrote: I would be suprised if you found a quick and easy way to do this. MyFaces core uses digester to unmarshal the config files.It then calls the API you mention. I would start digging around in org.apache.myfaces.config . One aggressive approach you might consider is to set up a directory structure that looks like a webapp, and then fire off the real MyFaces context listener that initializes things. It would tie you using the MyFaces implementation for your tests, but it would pre-initialize all that stuff. (I haven't tried this myself, so it might also run into cases where the mock objects need some extended behavior ... but i'd certainly be open to improving the test library so that it enables this use case.) A more conservative approach would be to build an abstract base test case that did the manual configuration operations (as you are doing them), for the combination of components that you want to test, in its setUp() method. At least that way, you'd only have to write them once. Dennis ByrneCraig -Original Message-From: Paul Spencer [mailto:[EMAIL PROTECTED]]Sent: Sunday, August 20, 2006 11:42 PMTo: 'MyFaces Development'Subject: How to configure the default renderers and component within a Shale-Test based unit test I am writing a unit test based on the Shale Test Framework for a Tomahawkcomponent.My current problem is the I need to add the default MyFaces andTomahawk components and renderers to the FacesContext. To date I have been using facesContext.getApplication().addComponent(...) andfacesContext.getRenderKit().addRenderer(...).This is becoming verycumbersome.I know the defaults are out their in various configuration files, but I do not know how to tell Shale's test framework how to use them.Suggestions?Paul Spencer
Heads Up on Shale Test Framework API Change
We're looking at implementing a suggestion[1] to change the API on the setUp() and tearDown() methods of org.apache.shale.test.base.AbstractJsfTestCase, to add throws Exception to the method signatures. The primary goal is to be consistent with the underlying TestCase class from JUnit 3.8.1, and to allow test developers to go ahead and let JUnit handle exceptions here like you often do when you add throws Exception to individual test methods.Implementing this change, of course, will cause all existing test cases that extend this base class to not compile. Looking at the MyFaces and Trinidad codebases, there are indeed a few such tests (although not a gigantic number). What I propose to do is to make the change in the Shale code, and then fix the test cases in MyFaces and Trinidad and check those in too (since I'm a committer on both repositories). Does anyone see any problem with me doing this (probably over the weekend at some point)?Craig McClanahan[1] https://issues.apache.org/struts/browse/SHALE-249
Re: [OT] ApacheCon planings...
On 8/4/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: If sb. is interested in staying the weekend () in Austin, lemme know. For me it's pretty fine to fly back to San Francisco on Sunday, instead of Friday. That one I'm going to pass on :-).I do enough travelling that leaving Friday night (if feasible) would be a good thing.no flight from Austin - Portland ?Nothing direct; probably need to connect through Dallas.Craig Thanks! Matthias Craig [1] http://wiki.apache.org/apachecon/WhoArrivesWhen -- Matthias Wessendorf further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com --Matthias Wessendorffurther stuff:blog: http://jroller.com/page/mwessendorfmail: mwessendorf-at-gmail-dot-com
Re: [OT] ApacheCon planings...
On 8/4/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi folks,anyone already planing her/his trip to Austin?I *think* I'll arrive on Oct 10 in the evenings. If you already know,when you arrive etc, please update this wiki page [1]. Bill and Ispoke about it during the flight to Dublin; so it's much more easier to organize cab sharing.I won't make my final plans until I know when my sessions are scheduled (two sessions on Shale), but I suspect it'll be arriving Tuesday afternoon/evening depending on flight connections. If sb. is interested in staying the weekend () in Austin, lemme know.For me it's pretty fine to fly back to San Francisco on Sunday, instead of Friday.That one I'm going to pass on :-). I do enough travelling that leaving Friday night (if feasible) would be a good thing. Thanks!MatthiasCraig [1] http://wiki.apache.org/apachecon/WhoArrivesWhen--Matthias Wessendorffurther stuff:blog: http://jroller.com/page/mwessendorfmail: mwessendorf-at-gmail-dot-com
Re: [VOTE] Move s:form to tomahawk
On 7/14/06, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! I noticed that there are only some tests for components in Tomahawk. Wouldn't it be great to have a test-case as a requirement for promoting a component ? Sure, if we can decide what reasonable test cases are. I would like to see more test-cases too, but not by using mock tests. Ithink for component testing its way too much work and error prone afterrefactoring.I was told (thanks to matze ;-) ) that trinidad uses so called gold-files - it compares the resulting html with an known-to-be-good(=gold) html file,I can tell you from years of painful experience, supporting some JSP tag libraries that rendered complex output, that the golden file approach can be really fragile and I'd never do it again :-). The problem we had is two fold: * Some changes that are innocuous in their effect on the runtime (such as changing the order of attributes generated in an element) will still break the golden file. False positive error reports are never a productivity enhancer :-).* If you deliberately change the output of a component, the tendency of the developer is to just re-record the entire golden file, and forget to examine whether some other bug was introduced (such as omitting a child element or something). We found ourselves introducing new errors when this occurred, which kind of defeats the purpose. though, what I really would like to see for componenttesting is something like htmlunit (http://htmlunit.sourceforge.net/)which allows some basic _javascript_ testing too. Shale's test framework includes support for exactly this scenario (using HtmlUnit). Many of the system integration tests in Shale's use cases example use this to evaluate the actual output ... very convenient, because HtmlUnit gives you back a DOM of the output, and you can test your assertions as needed. That being said, the behavior of a JSF component and renderer combination is complex enough that you probably want both unit tests on the individual methods and integration tests on the overall output. And of course, Mike is right in *testing* with RI and example. Note that I don't think that the component necessarily has to work with the RI to be promoted. But the documentation for the component should state whether it's expected to work with the RI or not, which would be determined by the testing.This is my point too, we should document if a tag breaks RI compatibility. As far as I know, only the form and command* stuff willbreak RI compatibility and - as long as there is no spec for this, itshard to make it any JSF compatible - we can act as RI and so we can be RI compatible, but as long as there is no spec for the parameter passingstuff we cant make it any JSF compatible.However, whats the case why we didnt change our classes to be at leastRI compatible? Thomas and Martin wanted to look at it, but didnt came up with asolution - is there something fundamental which prevents it, or is itsimply a matter of time?Deliberately releasing components that don't work with the RI does not seem like something that will increase the market acceptance of MyFaces components. Instead, this would create (or increase) a perception that MyFaces developers are not interested in compatibility. Also, given the fact that the RI has a 1.2 version available and MyFaces doesn't yet, it seems likely to give people a reason to consider switching away.The best approach is to make the build system so powerful that running your entire test suite against either the MyFaces or RI implementations is a single command line parameter. Wendy's already done that for Shale (so we have no excuses for the framework not supporting both :-), and I'm sure it can be done for the component libraries too. Ciao,MarioCraig
Re: [VOTE] Move s:form to tomahawk
On 7/14/06, Mike Kienenberger [EMAIL PROTECTED] wrote: On 7/14/06, Craig McClanahan [EMAIL PROTECTED] wrote: Deliberately releasing components that don't work with the RI does not seem like something that will increase the market acceptance of MyFaces components.Well, let's not make this more sinister than it is. There have beencases in the past where a tomahawk component could not functionwithout help from the JSF implementation. These are the cases where something might be marked as incompatible with otherimplementations.A component that doesn't work with both implementations is simply broken. Instead of relying on help from a JSF implementation, it should be redesigned to include its own help. Craig
Re: [VOTE] Move s:form to tomahawk
On 7/14/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: On 7/14/06, Craig McClanahan [EMAIL PROTECTED] wrote: I can tell you from years of painful experience, supporting some JSP tag libraries that rendered complex output, that the golden file approach can be really fragile and I'd never do it again :-).The problem we had is two fold: * Some changes that are innocuous in their effect on the runtime (such as changing the order of attributes generated in an element) will still break the golden file.False positive error reports are never a productivity enhancer :-). * If you deliberately change the output of a component, the tendency of the developer is to just re-record the entire golden file, and forget to examine whether some other bug was introduced (such as omitting a child element or something).We found ourselves introducing new errors when this occurred, which kind of defeats the purpose. *snip*This means that we are not testing the order in which attributes arewritten, which we shouldn't be testing, since order doesn't meananything.( http://wiki.apache.org/myfaces/Trinidad_RenderKit_test_framework) Deliberately releasing components that don't work with the RI does not seem like something that will increase the market acceptance of MyFaces components.Instead, this would create (or increase) a perception that MyFaces developers are not interested in compatibility.Also, given theright. fact that the RI has a 1.2 version available and MyFaces doesn't yet, it seems likely to give people a reason to consider switching away.Nope.Not every company is going to *swtich* to Java EE 5 only because it isnow released. From what I learned at my last job is, that big companies are going to have *solid* base for their technology stack. Ialso know from a friend that they recently switched away from Java EE1.2 to Java EE 1.4 (or from 2 - 4, what ever the real name is...). Who said anything about adopting Java EE 5? I'm talking about people considering adopting JSF 1.2. Yes, MyFaces will have such an implementation eventually, but if people get the impression that this group only cares about compatibility with their own JSF implementation, then what's the point of implementing a standard in the first place? Craig
Re: Testing for CoreRelease114
On 7/13/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: Dennis, when and what are you testing?Shouldn't we tag and build it as 1.1.4 first?why tagging, when the *snapshot* might be crap ?:-)I agree with Wendy. Release votes should be about here is a bunch of bits that I propose we release as version x.y.z -- not hey, I think the trunk is ready to go. The latter leaves open the possibility for several sorts of problems:* Packaging problems that aren't apparent until the release manager actually performs an assembly build or whatever. * Mistakes on the part of the release manager, that lead to building something different than what the committers thought they were voting on.* Differing assumptions about exactly what assembly steps the release manager will do, versus what you (as a developer) might expect.I've seen enough issues like this across multiple Apache projects that I will now generally -1 any release where I'm a committer unless the proposal is for a specific set of bits someone has posted in a test repository or personal home directory for examination. Three other points:* Subversion tags are effectively free -- Subversion operates on a copy when modified principle so there is essentially no overhead.* Tertiary version numbers (the z in x.y.z) are also effectively free, but it is extremely important to never release a non-snapshot x.y.z and then change it later. Therefore, if testing of a release candidate finds problems, throw it away and go build the next one.* Doing the TCK testing on core should certainly occur on the proposed release bits, but it is also useful for someone to run them earlier against the trunk build also, in an attempt to catch compatibility issues earlier rather than later.-MatthiasCraig I'm making this up as I go along, referring to http://wiki.apache.org/myfaces/Release_Procedure as necessary. :) IMO steps 5-6-7 are out of order.We should be voting on an actual set of files, not a revision number in svn, and we should be testing exacly those files before releasing them. There's a recent thread on [EMAIL PROTECTED] about voting on tarballs vs. the state of the svn tree. http://www.mail-archive.com/dev@tomcat.apache.org/msg06219.html Thanks, -- Wendy--Matthias Wessendorffurther stuff:blog: http://jroller.com/page/mwessendorfmail: mwessendorf-at-gmail-dot-com
Testing for CoreRelease114
I temporarily modified the Shale build environment to use 1.1.4 instead of 1.1.1, and was able to successfully build and run all the unit tests and integration tests (meaning I could deploy apps and run through some basic exercises on some of the standard components). One thing I would note in the release notes is that the Maven group identifier is changing (myfaces-org.apache.myfaces.core) as well as the version number.Craig
[ANNOUNCE][SHALE] Apache Shale Top Level Project Is Now Up And Running
You might have seen the recent announcement that Apache Shale, originally developed as part of the Apache Struts project, has been approved as an Apache top level project of its own. This message is an announcement that the project resources are now completely set up (thanks to the prompt attention of the Apache infrastructure team), and ready for use: Project Web Site: http://shale.apache.org/Project Wiki Site: http://wiki.apache.org/shale/Mailing List Information / Subscription / Archive Links: http://shale.apache.org/mail-lists.htmlNightly Builds: http://people.apache.org/builds/shale/On the web site, you will notice that there is, as of yet, no logo for the project. In fact, we would really like two images -- one for the web site logo, and a Powered By Shale logo that can optionally be included by web applications built with Shale. As someone who can barely draw a rectangle with straight lines, this seems like the perfect opportunity to get the community involved in a design ... so we're going to have a logo contest. Read about it on our wiki page, and submit your creative ideas there: http://wiki.apache.org/shale/LogoContestthen, join the Shale User mailing list and root for your favorites. Craig McClanahan
Re: Bad repository entry in pom.xml for org.apache.myfaces.core:myfaces-core-project:1.1.2
On 6/17/06, Sean Schofield [EMAIL PROTECTED] wrote: Craig,What's wrong with http://cvs.apache.org?It resolves fine for me?Wewere using that because a while back when we set up the nightlybuilds, that's what everyone was using. It resolves for me too, but hangs trying to download resources -- as a result, I can't build anything that depends on 1.1.2 unless I happened to have it in my local repository already. SeanCraig On 6/16/06, Craig McClanahan [EMAIL PROTECTED] wrote: This POM (possibly among others) has a repository element pointing at http://cvs.apache.org that needs to be changed to point at http://people.apache.org .Without doing so, you can't use Maven to build with 1.1.2 as a dependency unless you happened to have it in your local Maven repository prior to the host name change. Craig
Bad repository entry in pom.xml for org.apache.myfaces.core:myfaces-core-project:1.1.2
This POM (possibly among others) has a repository element pointing at http://cvs.apache.org that needs to be changed to point at http://people.apache.org . Without doing so, you can't use Maven to build with 1.1.2 as a dependency unless you happened to have it in your local Maven repository prior to the host name change.Craig
MyFaces Core 1.1.3 Release
Is there a reason that the 1.1.3 core release advertised on the MyFaces website[1] has not been synched over to the ibiblio Maven2 repository?Also, when I download the .tar.gz version of this, I get an error tar: a lone zero block at 8130 from a tar zxvf myfaces-core-1.1.3-bin.tar.gz on SUSE Linux.Craig[1] http://myfaces.apache.org/download.html
Re: [OT] Jira anonymous access
On 6/8/06, Chris Dadej [EMAIL PROTECTED] wrote: Within JIRA, go to Administration - Permission Schemes and edit theparticular scheme to which the ADFFACES project belongs.Just a matter of setting the appropriate permissions for Add Commentsto not include everyone. Thanks Chris. I've got admin rights on the project in question, but not general JIRA admin rights (which seems to be necessary to edit permission schemes). Therefore, this will need to be requested from the Infra group. CraigChris DadejMacquarie Bank LimitedISD - Investment Banking Group Phone:+612 8232 9987Mobile: +614 1625 4791Email:[EMAIL PROTECTED]-Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf OfMatthias WessendorfSent: Friday, 9 June 2006 3:46 PMTo: MyFaces DevelopmentSubject: [OT] Jira anonymous access hey,anybody knows what todo to avoid anonymous sending comments to theADFFACES jira?Or is this a task for the infra@ guys?thx,Matthias--Matthias WessendorfAechterhoek 18 48282 Emsdettenblog: http://jroller.com/page/mwessendorfmail: mwessendorf-at-gmail-dot-comNOTICEThis e-mail and any attachments are confidential and may contain copyright material of Macquarie Bank or third parties. If you are not the intended recipient of this email you should not read, print, re-transmit, store or act in reliance on this e-mail or any attachments, and should destroy all copies of them. Macquarie Bank does not guarantee the integrity of any emails or any attached files. The views or opinions expressed are the author's own and may not reflect the views or opinions of Macquarie Bank.
Re: [OT] Jira anonymous access
On 6/9/06, Henri Yandell [EMAIL PROTECTED] wrote: Easy enough to add Craig as a jira admin.I assume it's the craigmcc user Craig?Yes, that's me ([EMAIL PROTECTED]). I'd be happy to help out on all the JIRA admin issues if I could. There's another one with asun.com address, but I suspect that was pulled in by a migration. That ([EMAIL PROTECTED]) is also me ... but I'd prefer to have my Apache related admin rights attached to my Apache identity. HenCraigOn 6/8/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi infra@ guys. We - the ADF team - would like to ask you to help us out with the jira permissions. currently it is possible to add comments as anonymous. This is a fact, we don't like for some reasons. thanks for your help, Matthias On 6/8/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 6/8/06, Chris Dadej [EMAIL PROTECTED] wrote: Within JIRA, go to Administration - Permission Schemes and edit the particular scheme to which the ADFFACES project belongs. Just a matter of setting the appropriate permissions for Add Comments to not include everyone. Thanks Chris.I've got admin rights on the project in question, but not general JIRA admin rights (which seems to be necessary to edit permission schemes).Therefore, this will need to be requested from the Infra group. Craig Chris Dadej Macquarie Bank Limited ISD - Investment Banking Group Phone:+612 8232 9987 Mobile: +614 1625 4791 Email:[EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Matthias Wessendorf Sent: Friday, 9 June 2006 3:46 PM To: MyFaces Development Subject: [OT] Jira anonymous access hey, anybody knows what todo to avoid anonymous sending comments to the ADFFACES jira? Or is this a task for the infra@ guys? thx, Matthias -- Matthias Wessendorf Aechterhoek 18 48282 Emsdetten blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com NOTICE This e-mail and any attachments are confidential and may contain copyright material of Macquarie Bank or third parties. If you are not the intended recipient of this email you should not read, print, re-transmit, store or act in reliance on this e-mail or any attachments, and should destroy all copies of them. Macquarie Bank does not guarantee the integrity of any emails or any attached files. The views or opinions expressed are the author's own and may not reflect the views or opinions of Macquarie Bank. -- Matthias Wessendorf Aechterhoek 18 48282 Emsdetten blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: [Vote] Release Tomahawk 1.1.3
On 6/9/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: This is a vote to release Tomahawk 1.1.3 (and its dependencies:MyFaces Shared 2.0.2 and MyFaces Maven 1.0.3.)I should have spoken up earlier on, but I have a problem with this approach to release votes. In the Struts world, the release manager tends to put up a particular set of bits in his or her personal directory on people.apache.org, and then posts the vote request as I propose to release *this set of bits* ... That way, the other committers can download and check out exactly what is being proposed. Yes, with Maven based builds it is easy to assume that you and I will build identical artifacts, but it is still easier than you think for that not to be the case. Besides that, we caught packaging errors in several of the recent Struts Action Framework and Shale builds that would not have been caught if we hadn't been examining the actual bits being proposed. I would strongly suggest following this approach in MyFaces as well.On this basis, I'm -1 (non-binding as I'm not on the PMC).Craig +1 for my vote--Matthias WessendorfAechterhoek 1848282 Emsdettenblog: http://jroller.com/page/mwessendorfmail: mwessendorf-at-gmail-dot-com
Re: [Vote] Release Tomahawk 1.1.3
On 6/9/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: Craig-thanks for heads up. That particular RC for the Tomahawk 1.1.3 islisted available for download under [1]. That Shared 2.0.2 thing is*no* extra jar to be added to your WEB-INF/lib. The Shared clazzes are included in Tomahawk (org.apache.myfaces.shared_tomahawk.**)The folder [1] also contains a pom file for that Tomahawk 1.1.3 RCOK, good ... I see that the proposed bits have indeed been published to a special repository for testing, and thereby withdraw my -1. But I still recommend a [VOTE] message for a release should specifically include such a URL (and perhaps instructions on how to temporarily modify your Maven settings to download and test this version) instead of just assuming that everyone knows where the bits are, and what to do. -MatthiasCraig [1] http://tinyurl.com/mu4t9On 6/9/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 6/9/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: This is a vote to release Tomahawk 1.1.3 (and its dependencies: MyFaces Shared 2.0.2 and MyFaces Maven 1.0.3.) I should have spoken up earlier on, but I have a problem with this approach to release votes. In the Struts world, the release manager tends to put up a particular set of bits in his or her personal directoryon people.apache.org, and then posts the vote request as I propose to release *this set of bits* ...That way, the other committers can download and check out exactly what is being proposed. Yes, with Maven based builds it is easy to assume that you and I will build identical artifacts, but it is still easier than you think for that not to be the case.Besides that, we caught packaging errors in several of the recent Struts Action Framework and Shale builds that would not have been caught if we hadn't been examining the actual bits being proposed. I would strongly suggest following this approach in MyFaces as well. On this basis, I'm -1 (non-binding as I'm not on the PMC). Craig +1 for my vote -- Matthias Wessendorf Aechterhoek 18 48282 Emsdetten blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com --Matthias WessendorfAechterhoek 1848282 Emsdettenblog: http://jroller.com/page/mwessendorfmail: mwessendorf-at-gmail-dot-com
Re: Upcoming Tomahawk Release
On 6/8/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: I tried tomahawk_1_1_3 and JSF 1.1._01(I just removed myfaces-xxx and added jsf-xxx)I didn't changed any of the dependencies. No idea, what RI needs :-)You'd know if you pointed at the RI's POM :-). It's in a Maven1 ( i.e. legacy format) repository at java.net: https://maven-repository.dev.java.net/nonav/repositorygroupId= javax.faces(api) artifactId=jsf-api(impl) artifactId=jsf-implversionId=1.1_02You might also want to take a look at the snazzy pom.xml setup Wendy created for the Shale mvn_reorg branch. It lets you compile against either MyFaces or the RI based on enabling a profile ... something like this might be really handy on the component libraries, so you can easily build and test against both implementations. Craig
Re: [JSF 1.2] question
On 6/6/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: tracking system), but there hasn't been a formal roadmap for JSF.nextso is JSF.next the project name for it?No, JSF.next is shorthand for whatever version follows JSF 1.2 . Without a formal roadmap, there's no guarantee that the next version will actually be 2.0 (although that seems most likely to me). But the real roadmap could, for example, contemplate an intermediate 1.3 version with more incremental changes before a next major version. As a historical note, the JSP version in J2EE 1.3 was numbered 1.2. The original JSR for JCP to be included in J2EE 1.4 was proposed as 1.3, but the scope of the changes that the EG took on was so large that it became obvious that JSP 2.0 was a much better identifier. So, to avoid confusion, within Sun we've started talking about xxx.next as being the next version of xxx, leaving the precise identiier to be determined later. that happens, it would be very much appropriate that Apache have a representative on the EG, and it would seem to make the most sense that this rep be someone from the MyFaces community.Manfred is already there. I think Martin is interested too.Cool. However, we'll want to figure out which particular person to nominate as the official Apache representative ... in general, JCP expert groups have only one representative from a particular organization (but that person can generally communicate to others within the organization to build consensus, and then represent the organization's view back to the EG). It's also possible for additional folks to become EG members as individuals, at the discretion of the spec lead(s). -MatthiasCraig In the interim before the formal announcement, talk to Ed Burns and Roger Kitain, who were the co-spec leads for 1.2 (and AFAIK that's not changing for future versions, but I'm not as intimately connected with the specs world in my Creator architect role -- instead, I'm a customer :-) about the kinds of areas you would like to see a 2.0 spec cover. -Matthias Craig [1] https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=176 On 6/6/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 6/6/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:CONVERTER_ID =javax.faces.DoubleTimeLooks like a spec bug due to a cut-n-paste error in the RI's API classes. If so, the correct thing to do would be to report feedback via the website on the spec cover ( https://javaserverfaces-spec-public.dev.java.net ) so that it can get addressed as an errata, or included in a maintenance version of the 1.2 spec. Until then, though, I'd recommend you keep it ... this is the kind of mechanical detail that the API signature tests in the TCK will likely flag if it's missing. Craig On 6/6/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: Any reason for keeping [1] ? -Matthias [1] http://tinyurl.com/gjdxe On 6/5/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: Ah, thanks. Some are some issues also the reasons, why UIComponent is not an interface? -Matthias On 6/5/06, Adam Winer [EMAIL PROTECTED] wrote: Backwards compatibility - at least of a sort;you won't get AbstractMethodErrors when using 1.1-compiled subclasses. -- Adam On 6/5/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:Hi, does anybody know why the methods added to ViewHandler or ExternalContext in 1.2 are not abstract, like their *old* JSF 1.1counterparts ? -Matthias --Matthias WessendorfAechterhoek 18 48282 Emsdettenblog: http://jroller.com/page/mwessendorfmail: mwessendorf-at-gmail-dot-com -- Matthias Wessendorf Aechterhoek 18 48282 Emsdetten blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Matthias Wessendorf Aechterhoek 18 48282 Emsdetten blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com --Matthias WessendorfAechterhoek 1848282 Emsdetten blog: http://jroller.com/page/mwessendorfmail: mwessendorf-at-gmail-dot-com -- Matthias Wessendorf Aechterhoek 18 48282 Emsdetten blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com --Matthias WessendorfAechterhoek 1848282 Emsdettenblog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: [JSF 1.2] question
On 6/6/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: CONVERTER_ID =javax.faces.DoubleTimeLooks like a spec bug due to a cut-n-paste error in the RI's API classes. If so, the correct thing to do would be to report feedback via the website on the spec cover ( https://javaserverfaces-spec-public.dev.java.net) so that it can get addressed as an errata, or included in a maintenance version of the 1.2 spec.Until then, though, I'd recommend you keep it ... this is the kind of mechanical detail that the API signature tests in the TCK will likely flag if it's missing. CraigOn 6/6/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: Any reason for keeping [1] ? -Matthias [1] http://tinyurl.com/gjdxe On 6/5/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: Ah, thanks. Some are some issues also the reasons, why UIComponent is not an interface? -Matthias On 6/5/06, Adam Winer [EMAIL PROTECTED] wrote: Backwards compatibility - at least of a sort;you won't get AbstractMethodErrors when using 1.1-compiled subclasses. -- Adam On 6/5/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi, does anybody know why the methods added to ViewHandler orExternalContext in 1.2 are not abstract, like their *old* JSF 1.1 counterparts ? -Matthias --Matthias WessendorfAechterhoek 18 48282 Emsdettenblog: http://jroller.com/page/mwessendorfmail: mwessendorf-at-gmail-dot-com -- Matthias Wessendorf Aechterhoek 18 48282 Emsdetten blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Matthias Wessendorf Aechterhoek 18 48282 Emsdetten blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com--Matthias WessendorfAechterhoek 1848282 Emsdettenblog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: [JSF 1.2] question
On 6/6/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: Created a ticket [1]btw. there was version 2.0 already mentioned. Any kickoff for JSF 2.0 ideas yet?Ideas are being gathered (you can submit your favorites via the same issue tracking system), but there hasn't been a formal roadmap for JSF.next schheduled yet. Once it is, there will be a formal announcement of a JSR from the JCP, plus a call for experts to be on the expert group. When that happens, it would be very much appropriate that Apache have a representative on the EG, and it would seem to make the most sense that this rep be someone from the MyFaces community. In the interim before the formal announcement, talk to Ed Burns and Roger Kitain, who were the co-spec leads for 1.2 (and AFAIK that's not changing for future versions, but I'm not as intimately connected with the specs world in my Creator architect role -- instead, I'm a customer :-) about the kinds of areas you would like to see a 2.0 spec cover.-MatthiasCraig [1] https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=176On 6/6/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 6/6/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: CONVERTER_ID =javax.faces.DoubleTime Looks like a spec bug due to a cut-n-paste error in the RI's API classes. If so, the correct thing to do would be to report feedback via the website on the spec cover ( https://javaserverfaces-spec-public.dev.java.net) so that it can get addressed as an errata, or included in a maintenance version of the 1.2 spec. Until then, though, I'd recommend you keep it ... this is the kind of mechanical detail that the API signature tests in the TCK will likely flag if it's missing. Craig On 6/6/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: Any reason for keeping [1] ? -Matthias [1] http://tinyurl.com/gjdxe On 6/5/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:Ah, thanks. Some are some issues also the reasons, why UIComponent is notan interface? -Matthias On 6/5/06, Adam Winer [EMAIL PROTECTED] wrote: Backwards compatibility - at least of a sort;you won't get AbstractMethodErrors when using 1.1-compiled subclasses. -- Adam On 6/5/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi, does anybody know why the methods added to ViewHandler or ExternalContext in 1.2 are not abstract, like their *old* JSF 1.1 counterparts ? -Matthias -- Matthias Wessendorf Aechterhoek 18 48282 Emsdetten blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com --Matthias WessendorfAechterhoek 1848282 Emsdetten blog: http://jroller.com/page/mwessendorfmail: mwessendorf-at-gmail-dot-com -- Matthias Wessendorf Aechterhoek 18 48282 Emsdetten blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Matthias Wessendorf Aechterhoek 18 48282 Emsdetten blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com --Matthias WessendorfAechterhoek 18 48282 Emsdettenblog: http://jroller.com/page/mwessendorfmail: mwessendorf-at-gmail-dot-com
Re: Multiple SVN Branches (Was -- Re: JSF 1.2)
On 5/25/06, Martin Marinschek [EMAIL PROTECTED] wrote: @Craig: We can certainly release a not TCK tested version - we canjust not call it TCK compliant.You'd better read the spec license again A package that implements some of the javax.* APIs from a spec needs to implement *all* of them. regards,MartinCraig
Re: Multiple SVN Branches (Was -- Re: JSF 1.2)
On 5/25/06, Sean Schofield [EMAIL PROTECTED] wrote: You'd better read the spec license again A package that implements some of the javax.* APIs from a spec needs to implement *all* of them.@ Craig: Is this different the the 1.1 spec license?I seem to recall a compromise solution where we released as milestone.Is that nolonger an option?No, it's not different. Milestone/EA/Alpha/Beta/etc. are fine (as would be nightly builds that are not formally a release). Final/GA releases are not fine. Craig
Re: Multiple SVN Branches (Was -- Re: JSF 1.2)
On 5/24/06, Sean Schofield [EMAIL PROTECTED] wrote: As far as I can see, we never ever try to release a version out of the 1.2tc6 branch. So no need to do any special maintainance with this branch - just an archive.This part confuses me.I was under the impression that Stan was 90% of the way there.So why would we plan on abandoning this work infavor of a watered down version?I still haven't heard a compellingreason for two different branches for JSF 1.2 supported by twodifferent groups of MyFaces committers.We've got 5 - 6 active committers that work on the core on a regular basis.If what Stan has done independently doesn't suit us, then we canchoose to ignore it.(I can't say since I haven't looked at it.)ButI don't think we should just throw it in to SVN and then start working on a less complete version that works on Tomcat 5.What features ofJSF 1.2 that don't require Tomcat do people think we need right *now*?There's a separate issue as well ... a partial implementation of 1.2 couldn't pass the TCK, and therefore couldn't be released, either. Ciao, MarioSeanCraig
Re: JSF 1.2 [was: Cancelled: JavaOne MyFaces Committers/Contributors meeting]
On 5/21/06, Martin Marinschek [EMAIL PROTECTED] wrote: Ok,one more addition to the discussion - I'll want to branches. One forJSF1.2 things which cannot be used together with Tomcat 5.5 and, onefor JSF1.2 things which can be used with Tomcat 5.5. I'd love trunk to be the JSF1.2/Tomcat 5.5 branch, and have bug fixes for 1.1 on a realbranch.summary:1.1 -- branch1.2 Tomcat 6 -- branch1.2 Tomcat 5.5. -- trunkis that ok? Wouldn't this mean that every change that worked under 5.5 would need to be committed to both branches? That seems like a good way to slow down the effort to achieve 1.2 compliance. regards,MartinCraigOn 5/19/06, Stan Silvert [EMAIL PROTECTED] wrote: That would be fine.After I am done we may need some help from Sean. He was talking about putting Tomcat 6 jars in an Apache Maven repository. I've been building with NetBeans and not Maven.So someone who is more Maven savvy will need to update things so it builds correctly.I don't think it will be more complicated than adding and removing some dependencies. Stan Silvert JBoss, Inc. [EMAIL PROTECTED] callto://stansilvert -Original Message- From: Manfred Geiler [mailto: [EMAIL PROTECTED]] Sent: Thursday, May 18, 2006 8:48 PM To: MyFaces Development Subject: Re: JSF 1.2 [was: Cancelled: JavaOne MyFaces Committers/Contributors meeting] Sean, Can you please make a copy of the current trunk to /myfaces/core/branches/jsf_1_2 ? After that, Stan can simply (?) merge his stuff inside that. Is that ok, Stan? ManfredOn 5/18/06, Sean Schofield [EMAIL PROTECTED] wrote: You want a 1.2 branch for core only using the latest trunk right?I can create it for you if you want ... Sean On 5/18/06, Martin Marinschek [EMAIL PROTECTED] wrote:Manfred, can you go ahead with that 1.2 branch? regards, Martin On 5/18/06, Thomas Spiegl [EMAIL PROTECTED] wrote: I'm having a look at tomahawk 416 +1 for creating a 1.2 branch On 5/18/06, Stan Silvert [EMAIL PROTECTED] wrote: I have implemented most of the new core API's and fixed most of the deprecated ones to be backwards compatible with 1.1 (if you look at the 1.2 javadocs you'll see what I mean).If you look at the section in the spec preface entitled What's Changed Since the Last Release you can get a feel for what I did.I've pretty much done everything in that list. Most of it is covered under this issue, which just says to implement several sections of the spec: http://issues.apache.org/jira/browse/MYFACES-1274 I believe all of 1274 is complete except ApplicationImpl.getResourceBundle ().I needed code that reads the new faces-context.xml for that one.However, all the ELResolver stuff is done including the ResourceBundleELResolver. I've also done some of the issues listed under General Changes. For each item in that list, I created a Jira task.You can look at Jira and see which ones I did. I was just getting started on the javax.faces.webapp package when I was taken off of the project.I probably won't commit any changes from that.I didn't touch the components or renderer at all.With all the backward-compatible code I wrote, it appears that all the components still work even though they are written the 1.1 way. So, hopefully, what you guys will have to start with is a JSF 1.2 impl that is about half-way done and still works. Stan Silvert JBoss, Inc. [EMAIL PROTECTED] callto://stansilvert -Original Message- From: Thomas Spiegl [mailto:[EMAIL PROTECTED] ] Sent: Wednesday, May 17, 2006 4:58 PM To: MyFaces Development; [EMAIL PROTECTED] Subject: Re: JSF 1.2 [was: Cancelled: JavaOne MyFaces Committers/Contributors meeting] +1 for solving tomahawk 416, being incompatible to RI is a serious issue Stan which 1.2 issues did you fix. Did you change any link renderers? If not, i am +1 for open a 1.2 branch On 5/17/06, Werner Punz [EMAIL PROTECTED] wrote:Sean Schofield schrieb: I'm -1 on the 1.2 branch.There are major issues to be fixed in the core right now.(See TOMAHAWK-416 and related dev discussions.) I know that Stan is anxious but given the lack of interest in the core trunk, its hard to imagine we have enough support to sustain this branch.Do we have firm committments from anyone else besides Stan?+1 for a fork... the reason we need to get going asap and a fork helps.If we wait for another bunch of issues to be fixed, this will never end. Sorry to say that so harsh, but the time on 1.2 is really pressing,given that there wont be an option in jee to override the default JSFimplementation via other libs in
Re: Unit testing components
On 5/15/06, Sean Schofield [EMAIL PROTECTED] wrote: ps. Look at the shale test stuff.We're using more of it each day in MyFaces.Here's a link to the website docs about the Shale Test Framework: http://struts.apache.org/struts-shale/features-test-framework.htmlCraig
Re: Cancelled: JavaOne MyFaces Committers/Contributors meeting
On 5/10/06, Werner Punz [EMAIL PROTECTED] wrote: Dennis Byrne schrieb: Also, JBoss has decided to use the RI instead of MyFaces for JBoss 5. The decision was purely one of time and resources.By shipping the RI we will be able to pass the JEE 5 TCK sooner. We need to branch for 1.2 and get moving.Btw. if anyone has not noticed yet, Craig pointed out at JAX a hugepolitical issue with JSF 1.2As of JEE 5 the webcontainers are not allowed in their classloader hierarchy to make the jsf implementation overridable via a WEB-INF/libjsf (as far as I understood, Craig correct me there if I am wrong).More precisely, you should not be allowed to replace the container's 1.2 implementation with a 1.1 implementation ... that would be like trying to replace the Servlet 2.5 implementation built in to the container with a Servlet 2.4 or 2.3 implementation by trying to include the relevant jars of Tomcat inside your war. It is certainly technically feasible for an app server to provide a mechanism to replace the JSF implementation inside the server itself. Just keep in mind that the result of doing this is no longer guaranteed to be a Java EE 5 server that has passed the entire platform suite of TCK tests. The TCKs would have been run against the unmodified server as a unit. CraigSo it will become way harder to push a new jsf implementation into a webapp as soon as an application moves from a plain servlet runnertowards Tomcat.Werner
Re: svn commit: r399437 [3/4] - in /myfaces/tomahawk/trunk/sandbox/core/src/main: java/org/apache/myfaces/custom/pagelet/ resources/org/apache/myfaces/custom/pagelet/resource/ resources/org/apache/myf
On 5/3/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Added: myfaces/tomahawk/trunk/sandbox/core/src/main/resources/org/apache/myfaces/custom/pagelet/resource/cpaint2.inc.jsURL: http://svn.apache.org/viewcvs/myfaces/tomahawk/trunk/sandbox/core/src/main/resources/org/apache/myfaces/custom/pagelet/resource/cpaint2.inc.js?rev=399437view=auto== --- myfaces/tomahawk/trunk/sandbox/core/src/main/resources/org/apache/myfaces/custom/pagelet/resource/cpaint2.inc.js (added)+++ myfaces/tomahawk/trunk/sandbox/core/src/main/resources/org/apache/myfaces/custom/pagelet/resource/cpaint2.inc.js Wed May3 14:24:53 2006 @@ -0,0 +1,1127 @@+/**+* CPAINT - Cross-Platform Asynchronous INterface Toolkit+*+* http://cpaint.sourceforge.net+*+* released under the terms of the LGPL +* see http://www.fsf.org/licensing/licenses/lgpl.txt for details+*Werner,LGPL? That's a no-no for Apache source repositories. Craig
Re: 'Progress Bar' component
On 4/27/06, Werner Punz [EMAIL PROTECTED] wrote: Craig McClanahan schrieb: On 4/26/06, *Sean Schofield* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Is there something like this in ADF faces?I haven't looked at the donation yet with all of the other stuff going on but they have a pretty complete set of widgets in there.I agree it would be something nice to have. It would definitely be nice to have in MyFaces.But, there's no reason to be shy about using the BluePrints ones either ... they are open source and BSD licensed :-). Yes the BluePrints stuff is neat, and the license is even better.Btw. I have not checked the latest code, have you guys moved theprogress bar towards dojo, the old one afair, was straighton top of ajax. Yes, we've refactored the entire library of components to use dojo.io.bind for asynchronous communication. In addition, we're experimenting with wrapping DOJO widgets (such as the Rich Textarea Edtior). Besides having some interesting components to play with, the other desired outcome of this effort is a set of BluePrints Catalog solution entries that document best practices for building AJAX enabled components. Since the MyFaces developers are rapidly gaining experience in this area as well, it would be interesting to have you review the catalog entries that have been developed so far, and see how they stack up with your own work. (Who knows ... might even learn a thing or two as well :-). Craig
Re: FW: Facelet File Handles
On 4/27/06, Gethin Evans [EMAIL PROTECTED] wrote: Hi, I am urgently trying to find out how and where Facelet file handles are assigned. I am hitting a problem with java IOExceptions for having too many files open on my system. Upon inspection it appears as I navigate around my web application handles to my facelet .xhtml files are being assigned but not being removed leaving hundreds of file handles to each facelet. I am using liferay 3.6.1 so this could be a potential cause. Any advice/thoughts would be much appreciated.You might get more help on an internal implementation question like this by asking on the Facelets User mailing list. See [1] for subscription info. Craig[1] https://facelets.dev.java.net/servlets/ProjectMailingListList
Re: 'Progress Bar' component
On 4/27/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
I think the approaches of the blueprint components are highly faulty-- especially with the use of dojo.bind. You are dealing with pure URI negotiation which is orthogonal to the communication capabilities of JSF. Example, the autocomplete example uses Shale Remoting via an EL _expression_-- but doesn't carry context, so yeah, you can put #{
foo.suggest} but only if 'foo' is globally available which is a huge gotcha for developers and pushing the JSF solution back to where we were with JSP 2.0 and JSF 1.1 issues again with the disconnect.
Jacob,It might surprise you to hear *me* say something like this, but the entire AJAX world does *not* revolve around JSF :-0.Don't get me wrong. The use cases for wanting to partially update the state of the JSF component tree are perfectly valid -- and the stuff you guys are looking at with Avatar is perfectly reasonable (can you *please* settle it down so I can use it in Shale Remoting, for JSF
1.1 as well as JSF 1.2, in addition to what's already there :-). But this is by no means an approach that is universally applicable.Take the use case you are complaining about here (the auto complete component having to forward the method binding _expression_ to call the end user's method). Yes, that is necessary because this particular implementation does not assume that it has access to the JSF component tree (from which it could acquire the appropriate _expression_). And, it would be perfectly reasonable to want an auto complete component that *allowed* me to do such a thing.
But to *require* me to do that? Nah ... there are valid tradeoffs between sending extra state information (and avoiding the computational effort required to restore the component tree) and not doing so. That's not for the component author to predict -- an ideal auto complete text field component would support *both* strategies.
To say nothing of a Java back-end for non-JSF based applications, which care not a whit about JSF component state :-). Don't forget that this world exists too, and Shale Remoting as it currently exists supports out of the box.
Craig
Re: 'Progress Bar' component
On 4/26/06, Sean Schofield [EMAIL PROTECTED] wrote: Is there something like this in ADF faces?I haven't looked at thedonation yet with all of the other stuff going on but they have apretty complete set of widgets in there.I agree it would besomething nice to have. It would definitely be nice to have in MyFaces. But, there's no reason to be shy about using the BluePrints ones either ... they are open source and BSD licensed :-). SeanCraig
Re: RSVP for JavaOne
On 4/26/06, Stan Silvert [EMAIL PROTECTED] wrote: In addition to the dinner, we are also having a MyFacescommitters/contributors meeting.Anyone interested in the developmentof the MyFaces project is welcome.It will be held on Tuesday, June 17 at 1pm.We have the room until 5pm. I hope that June 17 (at least) isn't right ... if it is, you're likely to be pretty lonely :-).Criag Location: Palomar Hotel (very nice hotel - across the street from theMarriott)Snacks: YesPresentations: YesLots of discussion time: YesStan SilvertJBoss, Inc. [EMAIL PROTECTED]callto://stansilvert -Original Message- From: James Mitchell [mailto:[EMAIL PROTECTED]] Sent: Wednesday, April 26, 2006 12:48 PM To: MyFaces Development Subject: RSVP for JavaOne Any chance I can get in on the MyFaces happenings? -- James Mitchell
Re: How popular is this project?
On 4/15/06, Dennis Byrne [EMAIL PROTECTED] wrote: Does anyone know where to get crude numbers such as X # of downloads a day, Y # of subsrcibers to users@ ?Download counts are hard to come by, because the majority of them come from Apache mirror sites. Buf for the user list subscriber count, the MyFaces user list has 835 subscribers (dev list has 333). For comparison, the two Java projects with the largest user mailing list counts are Tomcat (user=3096, dev=1154) and Struts (user=2821, dev=718). Of course, you also have to remember that these numbers don't include anyone who reads these lists via email-to-NNTP gateways like gmane.org, or just peruse the archives.Dennis Byrne
Re: [VOTE] Release MyFaces-Core 1.1.2
On 4/14/06, Sean Schofield [EMAIL PROTECTED] wrote: Finally the release has passed the TCK.Lets start the vote so we canrelease ASAP.This is a vote to release myfaces-core-1.1.2.Its alsoimplicitly a vote to release myfaces-shared-2.0.0 since that is adependency.The shared dependency will only be pushed to ibiblio.It will not be available on the ASF mirrors.Here's my +1Can you (re)send a pointer to the bits being proposed? I can't in good conscience vote without this (plus I want to run my Shale examples with it to see if anything got broken). Craig
Re: [VOTE] Release MyFaces-Core 1.1.2
On 4/14/06, Sean Schofield [EMAIL PROTECTED] wrote: Finally the release has passed the TCK.Lets start the vote so we canrelease ASAP.This is a vote to release myfaces-core-1.1.2.Its alsoimplicitly a vote to release myfaces-shared-2.0.0 since that is adependency.The shared dependency will only be pushed to ibiblio.It will not be available on the ASF mirrors.Here's my +1+1.It even fixes the UIData bug I filed dealing with data models where getRowCount() returns -1 :-).Craig
Re: Any status update on the Subversion repos?
Jonas Jacobi wrote: Hi Craig, It is now three weeks since the announcement of the new adffaces-xxx mailing lists. I know you are busy, but do you have a status update on the creation of the Subversion repository for these components? Thanks - Jonas -- *Author*: Pro JSF and Ajax: Building Rich Internet Components http://apress.com/book/bookDisplay.html?bID=10044 *Blog*: http://www.orablogs.com/jjacobi When I looked yesterday, the request to create this subversion repository was 23rd on the list of outstanding infrastructure issues (yes, it takes a long time :-( sometimes). However, in response to some pings from me on Monday, it at least got assigned to someone who promised to look at it this week. Same thing (but different volunteer) for the new account setups. I'll try again. Craig
Re: Any status update on the Subversion repos?
On 4/13/06, Martin Cooper [EMAIL PROTECTED] wrote: On 4/13/06, Craig McClanahan [EMAIL PROTECTED] wrote: Jonas Jacobi wrote: Hi Craig, It is now three weeks since the announcement of the new adffaces-xxx mailing lists. I know you are busy, but do you have a status update on the creation of the Subversion repository for these components? Thanks - Jonas -- *Author*: Pro JSF and Ajax: Building Rich Internet Components http://apress.com/book/bookDisplay.html?bID=10044 *Blog*: http://www.orablogs.com/jjacobiWhen I looked yesterday, the request to create this subversion repository was 23rd on the list of outstanding infrastructure issues (yes, it takes a long time :-( sometimes).However, in response to somepings from me on Monday, it at least got assigned to someone whopromised to look at it this week.Same thing (but different volunteer) for the new account setups.I'll try again.Unless there's more to it than I think there is, I should be able to take care of the SVN repo this evening, if Garrett doesn't beat me to it. I believe all that's involved is adding the directories in SVN and updating the auth and mailer config files. That would be awesome. Thanks Martin!! --Martin Cooper Craig Craig
Re: Any status update on the Subversion repos?
On 4/13/06, Martin Cooper [EMAIL PROTECTED] wrote: I believe this is done. Your repo is at:https://svn.apache.org/repos/asf/incubator/adffaces/ Note that I have not created the standard trunk / tags / branches directories in there, since incubator podlings appear to be doing things differently - some have them, some don't - so I figured I'd let you decide what you want to do. I've given karma to craigmcc, matzew, mmarinschek and baranda, per INCUBATOR-17.Commits should go to the right place.If someone could verify for me that it's all working, I'll go ahead and close out the JIRA issues. Works for me (complete with email to the commits list) ... thanks Martin!I assume that granting karma to other authorized committers is just a matter of editing the infrastructure subversion/asf-authorization file, right? I'm on the Incubator PMC, so karma for that shouldn't be a problem. Craig-- Martin CooperOn 4/13/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 4/13/06, Martin Cooper [EMAIL PROTECTED] wrote: On 4/13/06, Craig McClanahan [EMAIL PROTECTED] wrote: Jonas Jacobi wrote: Hi Craig, It is now three weeks since the announcement of the new adffaces-xxx mailing lists. I know you are busy, but do you have a status update on the creation of the Subversion repository for these components? Thanks - Jonas -- *Author*: Pro JSF and Ajax: Building Rich Internet Components http://apress.com/book/bookDisplay.html?bID=10044*Blog*: http://www.orablogs.com/jjacobi When I looked yesterday, the request to create this subversion repository was 23rd on the list of outstanding infrastructure issues (yes, it takes a long time :-( sometimes).However, in response to some pings from me on Monday, it at least got assigned to someone who promised to look at it this week.Same thing (but different volunteer) for the new account setups.I'll try again. Unless there's more to it than I think there is, I should be able to take care of the SVN repo this evening, if Garrett doesn't beat me to it. I believe all that's involved is adding the directories in SVN and updating the auth and mailer config files.That would be awesome.Thanks Martin!!-- Martin Cooper Craig Craig
Re: Any status update on the Subversion repos?
On 4/13/06, Martin Cooper [EMAIL PROTECTED] wrote: On 4/13/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 4/13/06, Martin Cooper [EMAIL PROTECTED] wrote: I believe this is done. Your repo is at:https://svn.apache.org/repos/asf/incubator/adffaces/ Note that I have not created the standard trunk / tags / branches directories in there, since incubator podlings appear to be doing things differently - some have them, some don't - so I figured I'd let you decide what you want to do. I've given karma to craigmcc, matzew, mmarinschek and baranda, per INCUBATOR-17.Commits should go to the right place.If someone could verify for me that it's all working, I'll go ahead and close out the JIRA issues. Works for me (complete with email to the commits list) ... thanks Martin!No problem. Happy to help. I assume that granting karma to other authorized committers is just a matter of editing the infrastructure subversion/asf-authorization file, right? Right. I'm on the Incubator PMC, so karma for that shouldn't be a problem. Actually, only PMC chairs have explicit rights for that, but I think you'll be OK because you're an ASF member. It's not letting me right now ... i'll go ahead and request karma on the infra list. --Martin CooperCraig Craig -- Martin CooperOn 4/13/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 4/13/06, Martin Cooper [EMAIL PROTECTED] wrote: On 4/13/06, Craig McClanahan [EMAIL PROTECTED] wrote: Jonas Jacobi wrote: Hi Craig, It is now three weeks since the announcement of the new adffaces-xxx mailing lists. I know you are busy, but do you have a status update on the creation of the Subversion repository for these components? Thanks - Jonas -- *Author*: Pro JSF and Ajax: Building Rich Internet Components http://apress.com/book/bookDisplay.html?bID=10044*Blog*: http://www.orablogs.com/jjacobi When I looked yesterday, the request to create this subversion repository was 23rd on the list of outstanding infrastructure issues (yes, it takes a long time :-( sometimes).However, in response to some pings from me on Monday, it at least got assigned to someone who promised to look at it this week.Same thing (but different volunteer) for the new account setups.I'll try again. Unless there's more to it than I think there is, I should be able to take care of the SVN repo this evening, if Garrett doesn't beat me to it. I believe all that's involved is adding the directories in SVN and updating the auth and mailer config files.That would be awesome.Thanks Martin!!-- Martin Cooper Craig Craig
Re: Any status update on the Subversion repos?
On 4/13/06, Martin Cooper [EMAIL PROTECTED] wrote: On 4/13/06, Adam Winer [EMAIL PROTECTED] wrote: Scratch item #1 - just got the e-mail, [EMAIL PROTECTED]now exists. ;)Who can grant me karma for http://svn.apache.org/repos/asf/incubator/adffaces/ ?Scratch #2 - you now have karma. Now all you need is free time. ;-)Plus one more detail :-). We need to decide about the organization of the incubator repository. I'll post a separate thread on that in just a minute. John Fallows also now has karma. FYI, we still don't have ICLAs from Jonas Jacobi or Omar Tazi. --Martin Cooper Craig -- AdamOn 4/13/06, Adam Winer [EMAIL PROTECTED] wrote: Excellent, thanks!Once I get an apache account, karma for the SVN, and a bit of free time, I can check this puppy in and we can started for real! -- Adam On 4/13/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 4/13/06, Martin Cooper [EMAIL PROTECTED] wrote: I believe this is done. Your repo is at: https://svn.apache.org/repos/asf/incubator/adffaces/ Note that I have not created the standard trunk / tags / branches directories in there, since incubator podlings appear to be doing things differently - some have them, some don't - so I figured I'd let you decide what you want to do. I've given karma to craigmcc, matzew, mmarinschek and baranda, per INCUBATOR-17. Commits should go to the right place. If someone could verify for me that it's all working, I'll go ahead and close out the JIRA issues. Works for me (complete with email to the commits list) ... thanks Martin! I assume that granting karma to other authorized committers is just a matter of editing the infrastructure subversion/asf-authorization file, right?I'm on the Incubator PMC, so karma for that shouldn't be a problem. Craig-- Martin Cooper On 4/13/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 4/13/06, Martin Cooper [EMAIL PROTECTED] wrote: On 4/13/06, Craig McClanahan [EMAIL PROTECTED] wrote: Jonas Jacobi wrote: Hi Craig, It is now three weeks since the announcement of the newadffaces-xxx mailing lists. I know you are busy, but do you have a status update on the creation of the Subversion repository for these components? Thanks - Jonas -- *Author*: Pro JSF and Ajax: Building Rich Internet Components http://apress.com/book/bookDisplay.html?bID=10044*Blog*: http://www.orablogs.com/jjacobi When I looked yesterday, the request to create this subversion repository was 23rd on the list of outstanding infrastructure issues (yes, it takes a long time :-( sometimes).However, in response tosome pings from me on Monday, it at least got assigned to someone who promised to look at it this week.Same thing (but different volunteer) for the new account setups.I'll try again. Unless there's more to it than I think there is, I should be able totake care of the SVN repo this evening, if Garrett doesn't beat me to it. I believe all that's involved is adding the directories in SVN andupdating the auth and mailer config files. That would be awesome.Thanks Martin!! -- Martin Cooper Craig Craig
Re: Fwd: Action/Shale/JSF Overlap? (Was -- RESTful JSF)
On 4/10/06, Don Brown [EMAIL PROTECTED] wrote: Jacob Hookom wrote: The NavigationHandler has that default behavior. But much like WebWork allows the pluggable ActionMapper, all parts of JSF are pluggable in that manner.Seam and SWF are two examples of plugging in alternate logic for navigation handling.So the emphasis is put on the API, not the implementation.I guess what I'm saying is the navigation is already the way we want it.What would reimplementing it as a NavigationHandler bring to the table? I've been trying to get everyone behind the EL-API.The 'traditional' EL implementation provided in the spec is, again, only one implementation.The JEXL implementation of the EL-API would be a piece of cake, OGNL wouldn't be that hard either if they would use JavaCC with the visitor=true when compiling the grammar.Ok, I was under the impression that the Unified EL was tightly coupled to the implementation.If the API is abstract enough to handle different implementations such as OGNL, then this is good news.This might be the abstraction we werelooking for to ensure Action 2 isn't tied to one EL.Of course, deciding to implement the EL API by OGNL is one thing, finding someone with the time and expertise to do it is another :)Do you know of an alternate implementation of the EL API and/or more documentation about it?In my research, everywhereI saw it mentioned it didn't make the distinction, and comments, particularly on TSS, seemed to indicate the features I previously mentioned were explicitly rejected (method invocation, for example).In JSF 1.1, the APIs for the EL were indeed tightly bound. But that's no longer the case with JSF 1.2. The javadocs for the EL are formally still part of the JSP 2.1 spec, but are implementable separately. You can grab the spec documents (JSP and EL, bundled in one download) and the javadocs (again, bundled), at: http://jcp.org/aboutJava/communityprocess/pfd/jsr245/index2.htmlThese are in the Proposed Final Draft 2 state, in JCP terms, so I wouldn't expect to see much, if any, change before they go final. Ok, so we can walk away with saying we might be able to collaborate on the EL API, provided someone steps up and ports OGNL or an EL with a similar set of capabilities to it.I'm still not convinced implementing WebWork as a Lifecycleimplementation would bring any value for 95% of the applications, however, at some point, I am planing on porting Struts Faces to Action 2 for the edge case of a WebWork app that wants to take advantage of JSF components, the real draw ofJSF IMO, for certain pages.At which time, I'll look more into different integration approaches like this one. That (porting Struts-Faces) is a reasonable thing to do. Not only does it help the developer who just needs a few pages with JSF components (but wants to keep their existing overall architecture), it also helps those who are trying to migrate. I guess the bottom line I think our best bet is to focus on discrete problems like EL, validation, annotations, etc. for integration.From a framework developer perspective, sharing APIs is interesting, but not so for the end user, whocould probably care less.I guess I'm trying to see what advantages this would bring to the end user.The one capability of JSF that I'd like to use in an Action 2 application, as an end user, is its stateful components,particularly complex, out-of-the-box components.I'd be interested to hear of more capabilities an Action 2 developer would get out of such a hybrid.A strategy on my TODO list for Shale is to actually go in the other direction, by using JSF extension points to add in the processing of XWork interceptor chains. The two places this makes sense are: * Overriding the default ActionListener, which actually calls the action method. This corresponds to when an action framework invokes the execute or whatever method on the selected action. This takes care of per-action pipeline customizations.* Supporting the use of an XWork interceptor stack in the application controler filter part of Shale (as an alternative to the current mechanism, which lets you customize a Commons Chain command chain). This takes care of global pipeline customization.The first scenario seems pretty straightforward. I don't know XWork well enough to know whether the second strategy can actually be implemented the way I think it should (it would be necessary to split the before and after parts of the interceptor chain), but that'll become obvious when it gets attempted :-). The gain for the end user is to be able to reuse (or migrate) existing interceptors without having to rewrite everything. This is a good discussion, and I hope it can continue and be a benefit to both communities.DonCraig
Re: What's a POJSO ?
On 4/3/06, Dennis Byrne [EMAIL PROTECTED] wrote: Since you never answered the question in your subject line :-), I ampresuming that POJSO means Plain Old _javascript_ Object, right?Oops, yes.BTW, POJSO _javascript_ has no results in google, so this is hot stuff ;) /me just burned my fingers on the keyboard :-) Given that, JSON has primitives for the Java-JS conversions (things like JSONStringer and JSONWriter) in addition to the primitives for JS-Java.Iswhat you are after some sort of wrapper around this (that avoids all the lowlevel mechanics to assemble the JSON stream)?That would seem like a pretty nice gadget to have in your toolbox when you have a nice set of POJOsmodelling the data on the server side already.Hmmm ... it looks like their license is compatible as well. http://www.json.org/license.htmlEncapsulating something like this in JSF components would be duck soup ...maybe t:saveJSON instead of t:saveState :-)Interesting you mention this, as UISaveState is about 20 lines of java. True, but it cheats a bit ... it relies on the fact that POJOs know how to serialize themselves already. We might be able to mine things like Commons Betwixt (POJO--XML) for useful ideas. And, of course, the underlying functionality should be available via a Java API as well, to facilitate its use in AJAX event handlers. Dennis Byrne CraigDennis Byrne Craig
Re: Context configuration parameter name
On 4/2/06, Dennis Byrne [EMAIL PROTECTED] wrote: +1 ( and both examples are from me )It's good that you brought this up now because both of those parameters ( and three of four more) were introduced *after* the last release.Had these ended up in the 1.1.2 release, I would bring up the backwards compatibility argument.Any other thoughts?Any other context parameters added to the code base?What do Struts and Tapestry do? Struts tends to use org.apache.struts.XXX (upper case final portion) for both context init parameters and attribute keys), but it's not universal. Same with JSF (javax.faces.). Personally, I can't see this issue being a useful place to become pedantic :-). There are much more important usability issues that deserve attention. Dennis ByrneCraig-Original Message- From: Mario Ivankovits [mailto:[EMAIL PROTECTED]]Sent: Monday, April 3, 2006 01:19 AMTo: 'MyFaces Development'Subject: Context configuration parameter name Hi!I dont want to be an asshole - so sorry in advance :-) -, but maybe weshould find a standard how to name our context configuration parameternames.In the past we had the scheme org.apache.myfaces.X where isupper case only.Now I've seen we got some new configuration parameters named:org.apache.myfaces.validateandorg.apache.myfaces.secret.cache et alwhich is against this naming pattern.If others dont think its mandatory to follow this scheme I'll be finetoo (I wont start a war to archive it ;-) )I just wanted to bring this up now, once the user use them it might be hard to change it.If we wouldlike to go the lower-case pattern way, I'll propose to addlower-case aliases to our current names.Ciao,Mario
Re: Playing round with 1.5 features
On 4/2/06, Martin Marinschek [EMAIL PROTECTED] wrote: Hi Craig,If I take your philosophy and apply it to the managed-bean annotation,it makes only sense for the scope-annotation. The name annotationshould (and will be changed) without changing the code itself. Indeed. And nothing stops you from declaring a managed bean (using the same class) in the usual way if you need this. Same for navigation rules. The from-viewid as well as theto-viewid will be independent of the code, whereas the outcome verymuch interacts with the code. I suppose it is not quite the clear distinction you try to point out in your mail above.If we agree that the from and to view ids are not appropriate in the annotations, I don't see much of a need to annotate anything related to the outcome. It is just a string that (in my opinion) should describe this is what happened, not this is where you should go next. If you try another line of argument, you could say that navigationrules could be used in multiple action-methods, in different classes. Absolutely true. But managed beans can be used (as managed properties)in multiple other managed beans as well. And it makes no sense toconfigure a managed-property in the faces-config.xml, if the managedbean has been created by annotation. Regarding managed properties, that was my original thought as well -- you can always just pre-initialize the instance variable value to whatever default you are trying to set. Then, I remembered two things: * You can also use a value binding _expression_ instead of a literal value, just like you can in a faces-config.xml file.* Using the annotation (or a managed property declaration) causes the property setter to get called, in which you might have coded side effects that you want to trigger (such as a property change event getting fired). What I want to point out is that depending on how you see a navigationrule (as very related to the special action-method you program rightnow or as a general navigation rule, valid for many action methods)the usability of annotations change, but I wouldn't outright decline them. In fact, I would personally like to use annotations for somevery special navigation rules, and for general navigation rules, I'dtake Werner's approach of writing a semi-automaticnavigation-handler. I could see a case for a completely different sort of navigation scheme, driven by its own navigation handler, that ran off its own annotations. And this wouldn't even have to conflict with the standard handler, if it delegated for cases that were not annotated. I just don't see it for the standard algorithm. With this, I'd be pretty happy to get rid of the faces-config.xml if Idon't like it. regards,MartinCraig
Re: Release Candidate
On 4/3/06, Sean Schofield [EMAIL PROTECTED] wrote: There is a release candidate for myfaces-core-1.1.2 available fortesting.Its in the nightly directory[1] so it will be auto-deletedafter 5 days.Lets get this tested and out the door so we can finallyget a new stable release out there. Has this build passed the TCK yet, or is that part of the testing that needs to be done? Sean[1] http://cvs.apache.org/builds/myfaces/nightly/Craig
Re: What's a POJSO ?
On 4/3/06, Dennis Byrne [EMAIL PROTECTED] wrote:
Hello community,There are plenty of great frameworks that allow us to marshall entities back and forth between our POJOs and the DB.Does any know of a way to marshall entities back and forth from our POJOs and the client side?What I want is to just point a tag at a java business object and have it render as a POJSO ...
s:pojso value=#{back.pojo.class} / render class ( function )s:pojso var=myPojo value=#{backer.pojo} / render instances:pojso var=myPojos value=#{
backer.pojoList} / render arrays:pojso var=myPojos value=#{backer.pojoMap} / render associative arrayIn order to render an input field w/ the onchange event syncing the value w/ the *client* side entity w/ *no* postback ...
h:inputText id=zipcode value=#{backer.pojo.zipCode} s:valueChangeListener for="" //h:inputTexts:pojso var=myPojo value=#{
backer.pojo} /There could be lots of facets for the extra stuff ( disable getters/setters, how deep to walk the POJO graph, which properties to exclude, etc.).I would envision using bindings for the facets so that application developers do not have to repeat this across every JSP, or facelet if your initials are
M.K. :)Perhaps there are non-JSF ( or non-Java ) implementations of the concept already ?How deep does the ADF rabbit hole go?I am not interested in AJAX method invocation because DWR already does this good - nor so much getting POJSOS to POJOS ( which JSON kind of does ).I am more or less trying to move the conversation to the browser w/out doing a lot of grunt work.
Since you never answered the question in your subject line :-), I am presuming that POJSO means Plain Old _javascript_ Object, right?Given that, JSON has primitives for the Java-JS conversions (things like JSONStringer and JSONWriter) in addition to the primitives for JS-Java. Is what you are after some sort of wrapper around this (that avoids all the low level mechanics to assemble the JSON stream)? That would seem like a pretty nice gadget to have in your toolbox when you have a nice set of POJOs modelling the data on the server side already.
Encapsulating something like this in JSF components would be duck soup ... maybe t:saveJSON instead of t:saveState :-)
Dennis ByrneCraig
Re: Playing round with 1.5 features
On 3/28/06, Werner Punz [EMAIL PROTECTED] wrote: Craig, the Shale Tiger extensions are a good startin point, I read thedocs, and liked what I saw. (I also highly recommend Seam which drivesannotations to the extreme)Yep ... good stuff there too. Anyway, having had to hack components again for an extende period oftime I still hate the huge mess the whole component API is in (no offence to the Sun guys they did their best given that they had toenforce 1.3+ JDKs)What I would like to see would be a single controller and view objectwith all the taglib binding exposed via annotations instead of having to drag around an extra tag class, an extra tld and an extra faces-configentry.Components for instance are the perfect place to get rid of the xmldefintions totally (which then can be overridden with application level xml definitions if someone wants to use his own renderer)I was constrained in the stuff so far by what could be accomplished at runtime -- and there's no way to define a tag library on the fly at that point. But what you're describing could certainly be done by processing annotations at compile time instead (using apt or equivalent). That'd be an interesting area to explore, over and above the runtime stuff. I'm game to work on that for Shale. There's a couple of other useful things to do at compile time ... like a tool to audit the configuration files that do exist to catch silly mistakes like wrong class names for managed beans. With a good use of annotations we could cut down from two xmldefinitions and 3 classes, to two classes and 1-2 annotations in the controller and view.Which means a total cut down of the code of at least 30% average and atotal cutdown of artefacts from 5 to 2.Craig
Re: Playing round with 1.5 features
On 3/28/06, Werner Punz [EMAIL PROTECTED] wrote: Dennis Byrne schrieb: XML configuration files do quite well their job and were designed to avoid coupling parametrization stuff in code. Now it seems we return to the point were we started. It seems more a response to .NET than real desirable functionality, as we already had it with external configuration files. I have to agree w/ this 100%, XML still rocks.After doing my latest project w/ EJB3 annotations, I don't see much added value. But the truth is, annotations are very sexy right now.This project isn't lacking in users, but I think this would generate a lot more interest in MyFaces.Actually this is getting off topic. But I see annotations as a huge improvement over central configuration in certain situations.As someone mentioned it is first of all a good place to haveconfigurations if it has to change with your code on the fly.Secondly it cuts down severely on artefacts because annotations work on introspection, which most xml based configurations dont.So you end up with two annotations per class, within the code instead ofa 20-30 line extra xml artefact.Perfect example is for instance the @WebMethode or the @Transactional annotationThere are scenarios where a central configuration in xml makes perfectsense. For application singletons for instance, or db connectionconfiguration.But this is totally off topic for now. Off topic or not :-), you can get a sense of what it would feel like to use JSF-specific annotations today, using Shale's Tiger Extensions[1]. They let you use annotations to define managed beans, register components/converters/renderers/validators, as well as get Shale's view controller functionality without having to implement the ViewController interface. Requires JSF 1.1 and JavaSE 5.The SQL Browser example app uses these, so you can see what it looks like in action. (NOTE - the app is currently bundled with MyFaces 1.1.1 that has a bug, recently fixed, that prevents the actual data in the table from being displayed -- will switch to 1.1.2 once that's released.)For application developers, not having to declare managed beans in XML can quickly spoil you.On a more general note, I believe annotations make sense when your code is designed on the assumption that the configuration variable is set a certain way. In JSF, for example, which scope the managed bean goes in can make a difference in what you do (thread safety issues, session scope beans should be Serializable, etc.). Having the setting in the class lessens the likelihood that someone will unknowingly change the configuration setting, without understanding that it might need code changes too. I don't believe annotations should be used for everything. Again, in the JSF case, I think navigation rules don't belong there -- actions should return an outcome that says this is what happened rather than this is where you should go next, and the overall flow should be managed separately (because it can change, without needing to change the code). Craig[1] http://struts.apache.org/struts-shale/features-tiger-extensions.html
Re: Continuation For Stateless Yet Stateful Apps
On 3/28/06, Travis Reeder [EMAIL PROTECTED] wrote: A mixture of the two might be good, keep them in RAM for a short period of time and/or a maximum number of sessions, then write them to disk after the thresholds. Or even write them to some kind of scalable persistence mechanism like ehcache or JavaSpaces, then the cache could take care of the persistence and scaling. You could have a virtually unlimited number of sessions making JSF very scalable. FWIW, some servlet containers (including Tomcat) have features that will do this sort of swap to disk for all session attributes, not just the ones that might be needed for continuations support. In such a world, the concern about memory occupancy could get reduced substantially, without the applicaton (or JSF) having to do anything special. Travis Craig On 3/28/06, Werner Punz [EMAIL PROTECTED] wrote: Travis Reeder schrieb: http://www-128.ibm.com/developerworks/java/library/j-cb03216/?ca=dgr-jw22StatelessWeb It would be interesting to take a look at working this type of thing into MyFaces.We are already doing some of this stuff with the session state saving to help with the back button, but I wonder if it could be taken a step further and persisted for long periods.It could go a long way in making JSF more scalable.Ok to think this over:It is sort of there already as you mentioned...the persistence for long periods of time is problematic. If you keep it in ram, it will suck up ram in no time.If you drop it into a storage (file database etc...) it willsuck away your performance, unless you have the continuation faultlenient (which means it does not matter if you can lose one point in time), so that you can push it into an asynchronous backend process withheavy caching in between.I think getting a stateful approach is better done the way shaleand seam do it, by using the session for keeping conversations open in time. That does not resolve the back button issue however.
Re: [ANNOUNCE] Mailing Lists for ADF Faces Incubator Podling
On 3/27/06, Mike Kienenberger [EMAIL PROTECTED] wrote: Craig,The issues and commits mailing lists are bouncing my subscriptionrequests.The user and dev subscriptions worked fine, however.That was me, acting as moderator. Wierd ... I responded in the text with the fact that you sent to the list, instead of to the subscribe addresses, but that doesn't show in the quoted text below. At any rate, you need to send to the following addresses to subscribe to these lists: [EMAIL PROTECTED] [EMAIL PROTECTED]And of course you did that because you clicked the botched links in the original announcement. Oops :-(. Craig-- Forwarded message --From: [EMAIL PROTECTED][EMAIL PROTECTED]Date: 27 Mar 2006 20:25:37 -Subject: Returned post for adffaces-commits@incubator.apache.orgTo: [EMAIL PROTECTED]Hi! This is the ezmlm program. I'm managing the adffaces-commits@incubator.apache.org mailing list.I'm working for my owner, who can be reachedat [EMAIL PROTECTED].I'm sorry, your message (enclosed) was not accepted by the moderator.If the moderator has made any comments, they are shown below.-- Forwarded message -- From: Mike Kienenberger [EMAIL PROTECTED]To: adffaces-commits@incubator.apache.orgDate: Mon, 27 Mar 2006 15:22:06 -0500 Subject:On 3/27/06, Craig McClanahan [EMAIL PROTECTED] wrote: Good news!There are now four email lists that will be specifically focused on the ADF Faces component contribution to Apache!You can use the subscription links below to subscribe yourselves to the corresponding lists. ADF Faces User List -- this is the place to ask questions about using the ADF Faces components that are currently in incubation: [EMAIL PROTECTED] ADF Faces Developer List -- subscribe here to discuss the technical evolution of the ADF Faces components into the MyFaces community, and to talk about how we should deal with particular bugs and enhancement requests. [EMAIL PROTECTED] ADF Faces Commit Reports -- subscribe here to receive an email for each commit to the ADF Faces source code repository.All developers actively working on the ADF Faces components SHOULD (if it were up to me alone I would say MUST :-) subscribe to this list. adffaces-commits@incubator.apache.org ADF Faces JIRA Issues -- subscribe here to receive an email each time a JIRA issue is created, or modified, for the ADF Faces components project. All developers actively working on the ADF Faces components SHOULD (if it were up to me alone I would say MUST :-) subscribe to this list. adffaces-issues@incubator.apache.org In the near future, we'll see the creation of the Subversion repository for these components, to which the initial contribution will be checked in. From the initial checkin until the graduation of this Incubator project, all updates to the ADF Faces component source code will be done here. It should be noted that these mailing lists are likely to have a fairly short lifetime.Upon graduation (technically an if but I am an optimist :-), the intended destination of these components is to become part of the MyFaces project ( http://myfaces.apache.org), and we will migrate to the standard MyFaces project mailing lists and source repository.But this is where the initial steps will be taken.Be sure to subscribe so you can tell your grandchildren that you were in at the very start of this :-). Craig McClanahan Mentor, ADF Faces Incubator Podling
[ANNOUNCE] Mailing Lists for ADF Faces Incubator Podling
Good news! There are now four email lists that will be specifically focused on the ADF Faces component contribution to Apache! You can use the subscription links below to subscribe yourselves to the corresponding lists. ADF Faces User List -- this is the place to ask questions about using the ADF Faces components that are currently in incubation: [EMAIL PROTECTED] ADF Faces Developer List -- subscribe here to discuss the technical evolution of the ADF Faces components into the MyFaces community, and to talk about how we should deal with particular bugs and enhancement requests. [EMAIL PROTECTED]ADF Faces Commit Reports -- subscribe here to receive an email for each commit to the ADF Faces source code repository. All developers actively working on the ADF Faces components SHOULD (if it were up to me alone I would say MUST :-) subscribe to this list. adffaces-commits@incubator.apache.orgADF Faces JIRA Issues -- subscribe here to receive an email each time a JIRA issue is created, or modified, for the ADF Faces components project. All developers actively working on the ADF Faces components SHOULD (if it were up to me alone I would say MUST :-) subscribe to this list. adffaces-issues@incubator.apache.org In the near future, we'll see the creation of the Subversion repository for these components, to which the initial contribution will be checked in. From the initial checkin until the graduation of this Incubator project, all updates to the ADF Faces component source code will be done here. It should be noted that these mailing lists are likely to have a fairly short lifetime. Upon graduation (technically an if but I am an optimist :-), the intended destination of these components is to become part of the MyFaces project ( http://myfaces.apache.org), and we will migrate to the standard MyFaces project mailing lists and source repository. But this is where the initial steps will be taken. Be sure to subscribe so you can tell your grandchildren that you were in at the very start of this :-). Craig McClanahanMentor, ADF Faces Incubator Podling
Re: tomahawk/src/test has dependencies on MyFaces Impl
On 3/20/06, Martin Marinschek [EMAIL PROTECTED] wrote: For properly testing against both APIs and IMPLs, we'd need to have the RI be1) maven2-nized2) with a compatible license.Now, license issues have been resolved for most of the licenses wedeal with. Was the CDDL amongst the libraries we may deliver binaries with? I do believe so...Yes, per the current proposal for compatible licenses that is currently being discussed in Apache's licensing mailing lists.On the other hand, is *distribution* really a requirement? Or just the ability to automatically download from a Maven-compatible repository without any click-through licenses? That's possible today for the 1.2 JSF RI (which should ideally be added to the testing matrix I listed earlier, since the 1.2 spec is nearing final release) ... working on it for 1.1. regards,MartinCraig
Re: tomahawk/src/test has dependencies on MyFaces Impl
(Coming back from London after a couple of days out of touch, so this might be old news, but ...)On 3/17/06, Dennis Byrne [EMAIL PROTECTED] wrote:One -- you're actually limiting or biasing the test coverage for this particular test because you're testing against a particularimplementation rather than a more abstract mock object.Yes, this is an argument that is as old as QA itself ;)And it would be exactly the same if the tests were using a MyFaces-specific mock object :-). The point is that you *cannot* test the behavior of many JSF related objects without more than a pure abstract implementation of the mock objects. I'm sure that is true in most scenarios that use mock objects for a testing strategy, but it is clearly true here. Want proof? You wouldn't believe how many times the Shale test framework had to flesh out implementations of abstract methods (that used to just throw UnsupportedOperationException) before the framework was actually usable in testing MyFaces components :-). Two -- by requiring impl to be a dependency for the test code, youallow the possibility of unintentionally using impl classes in the non-test code.As long as impl is scoped as test in the pom.xml for tomahawk, I don't see how maven would allow one of us to compile the non-test code.+1. In order to test components correctly, it is vital that the compile-time and runtime classpaths for the tests include the API jar file and the test framework, but *not* the impl classes. HOWEVER ... this condition is merely necessary but not sufficient. That is because JSF has quite a lot of implementation functionality built in to the API classes as well, so you could still end up with unintended dependencies on the MyFaces API classes. A robust testing strategy for components would execute against both (a) MyFaces API + Test Framework, and (b) JSF RI + Test Framework. Along with, of course, runtime tests against both API+IMPL combinations. Another observation is that end-users cannot download, build, testTomahawk without MyFaces impl. Since Tomahawk is supposed to be JSF-implementation independent, it's contrary to our stated goal torequire a specific implementation for testing or development.Obviously we want people to use tomahawk w/out myFaces impl.If you would like to make it possible for them to test tomahawk w/out impl than more power to you.I think this is taking it too far and we will never get a pat on the back for this. Isn't this the basic motivation behind migrating to a shared or commons artifact that both the MyFaces impl and the components can depend on, without creating a mutual dependency? (But that only deals with part of the problem, as the previous response paragraph describes.) Dennis ByrneCraig
Re: [shale] Another Shale Release?
On 3/10/06, Wendy Smoak [EMAIL PROTECTED] wrote: On 3/10/06, Sean Schofield [EMAIL PROTECTED] wrote: @Craig Any idea whether we can do another alpha release so we can use the fixed mock stuff in MyFaces?I think both Shale and MyFaces should try to start releasing more often. @ Wendy Would you be able to help with said release?I'm out of the country and Craig will also be traveling himself.Plus you are the Maven master ;-)Wrong list, I think. :)But I already said yes...http://www.nabble.com/Urgent-Core-Release-Problem-t1242345.html#a3311258 Yep ... I'm accumulating changes to be listed in the release notes, and Wendy is going to do the heavy lifting. Craig --Wendy
Re: ADF Faces Proposal -- Status Report
On 3/9/06, Adam Winer [EMAIL PROTECTED] wrote: One thing I'd like to get in gear right now :is there a utilityout there that can do batch replacing of license files for .javaand .xml files?I'd like to get the per-file license done beforechecking in the new drop and I'm dreading doing this manually. All of the Apache projects had to do that kind of thing when we switched from v1 to v2 a couple of years ago, and IIRC there are some scripts lying around for this kind of thing. Let me check ... -- Adam Craig
Re: The annual MyFaces JavaOne party/dinner
On 3/9/06, John Fallows [EMAIL PROTECTED] wrote: Count me in - it was great fun last year! I want to be there, but need to know which night to protect as quickly as possible, so my schedule doesn't get trumped like it did last year :-). tc,-john. Craig On 3/9/06, Jonas Jacobi [EMAIL PROTECTED] wrote: Hi All, Its getting close to JavaOne and it is time to add the MyFaces JavaOne Party to your calendar. As we did last year, there is no set date this early on, but we need to know now how many are interested in coming to a MyFaces night out during JavaOne (May 16th - 19th, 2006). With this information we can plan and book the right venue for the party/dinner. Last year ~20 MyFaces fans met at the Thirst Bear for a dinner and a few beers (http://myfaces.apache.org/community/javaone2005_cometogether.html), and, of course, lot of interesting discussions about JSF and web frameworks in general. This year we hope that more fans will come and join us for a night out. Please let us know if you are interested in joining up at the MyFaces party as soon as possible. Note: JavaOne is a month early compared to last year and that is why you see this invite now :) Last year Oracle sponsored the evening, and they sure will this year :), but we would love to see more sponsors contribute to ensure that this will be a very memorable happening. Thanks, Jonas -- Author: Pro JSF and Ajax: Building Rich Internet Components Blog: http://www.orablogs.com/jjacobi -- http://apress.com/book/bookDisplay.html?bID=10044Author: Pro JSF and Ajax: Building Rich Internet Components, Apress
Re: Servers to Test
On 3/8/06, CONNER, BRENDAN (SBCSI) [EMAIL PROTECTED] wrote: Do the other application servers ship with their own JSF implementation? Glassfish ships with the JSF 1.2 reference implementation. Supporting JSF 1.2 is required for all JavaEE 5 platforms, so this is going to be a universal issue for that generation of servers. If so, do they offer any other way of substituting another JSFimplementation into one's application? We (Sun) are looking at that issue for Glassfish at the moment. - Brendan Craig
