Re: OT: Oracle buys Sun
I may be a little bad for some sun products, but in whole it would be great for java vs .net platformOracle is second largest software vendor. I am afraid this may cause other companies like IBM to move away from Java platform On Mon, Apr 20, 2009 at 7:01 AM, Werner Punz werner.p...@gmail.com wrote: Hello everyone I just read at the german Heise site that Oracle has bought Sun for 7.4 billion dollars. I wonder what the implications in the long run will be. My personal thought is that it might finally become possible that the RI and MyFaces can merge... Java: Probably business as usual but maybe it will become more open! OpenOffice will probably be maintained with the business as usual. Same goes for OpenSolaris/Solaris But I see a rather black future for Netbeans and MySQL... (I would be sad if Netbeans would go away the IDE is simply excellent) Also the proposed IceFaces merger as base for a future JSF-Sun component set might be now dead in the light of Oracle having already something in their portfolio! As for the Sun hardware division that is a big question, but I personally guess Oracle will try to keep it alive and make it a cash cow again! -- Arash Rajaeeyan
Re: OT: Oracle buys Sun
Oracle is a bigger competitor for IBM, has a more aggressive strategy and much less committed to open source,for example they have promised to open source Oracle ADF RC for nearly two years, (Apache RCF) but you can't see any progress. now Oracle will have the most complete software stack even more complete than Microsoft! although MySQL was very popular but it was not a direct competitor of DB2 (But Oracle is) and Solaris and AIX had their own customers, Sparc and Power platform had their own market share two, but now with popularity of Oracle DB, Oracle can boost Sparc and Solaris sale, and get more market share from IBM. in software market because of Strong position of Oracle, they may need less commitment to open source and open standards. cheers Arash On Mon, Apr 20, 2009 at 8:59 AM, Alan Hancock suddenrush9...@gmail.comwrote: What would IBM move to? Why would Java be any different with Oracle from IBM's perspective? -Alan via iPhone On Apr 20, 2009, at 10:25 AM, Arash Rajaeeyan arash.rajaee...@gmail.com wrote: I may be a little bad for some sun products, but in whole it would be great for java vs .net platformOracle is second largest software vendor. I am afraid this may cause other companies like IBM to move away from Java platform On Mon, Apr 20, 2009 at 7:01 AM, Werner Punz werner.p...@gmail.com werner.p...@gmail.com wrote: Hello everyone I just read at the german Heise site that Oracle has bought Sun for 7.4 billion dollars. I wonder what the implications in the long run will be. My personal thought is that it might finally become possible that the RI and MyFaces can merge... Java: Probably business as usual but maybe it will become more open! OpenOffice will probably be maintained with the business as usual. Same goes for OpenSolaris/Solaris But I see a rather black future for Netbeans and MySQL... (I would be sad if Netbeans would go away the IDE is simply excellent) Also the proposed IceFaces merger as base for a future JSF-Sun component set might be now dead in the light of Oracle having already something in their portfolio! As for the Sun hardware division that is a big question, but I personally guess Oracle will try to keep it alive and make it a cash cow again! -- Arash Rajaeeyan -- Arash Rajaeeyan
Swing Renderer
hi what is your idea about Swing Render kit? benefits may include: 1) same programming model for both desktop and web 2) ability to test programs much faster on desktop outside of web container Arash
Re: [New Incubator Project Help - WebBeans Spec Implementation]
Hi I am not a champion, and not an official MyFaces member, but I am willing to help in development, design, documentation, ... On Fri, Oct 3, 2008 at 6:19 PM, Matthias Wessendorf [EMAIL PROTECTED]wrote: FYI -- Forwarded message -- From: Gurkan Erdogdu [EMAIL PROTECTED] Date: Fri, Oct 3, 2008 at 4:11 PM Subject: [New Incubator Project Help - WebBeans Spec Implementation] To: [EMAIL PROTECTED] Hi to all; My name is Gurkan Erdogdu. I have been implementing the Web Beans Specification - JSR-299, EDR-1. 90% of the specification code is completed with its unit tests. I want to denote my working for the Apache Foundation, because I am the believer of the open source. As an open source developer, I developed open source JBoss Cache IDE for a while ago, as a committer of the JBoss IDE. After completing the EDR-1(in a couple of weeks), I will be synchronized with the next revision of the specification when it is available. I have read the pages and doumentation about the how incubator project is proposed and accepted by the foundation. I understand that, I have to find a Champion to further insist my project. Moreover, lots of documentation mixes my mind a little that how I will proceed. Help is very appreciated for taking a part of this great community; Thanks for helping; Sincerely; Gurkan Erdogdu [EMAIL PROTECTED] -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Arash Rajaeeyan
Re: Need a MyFaces Product Environment matrix.
I havea added an small matrix to the following wiki page: http://wiki.apache.org/myfaces/CompatibilityMatrix if any body is sure about any combination he/she may edit it till the jira issue is solved. regards On 4/18/07, Wendy Smoak [EMAIL PROTECTED] wrote: On 4/18/07, Paul Spencer [EMAIL PROTECTED] wrote: Users looking at MyFaces Products do not have one place that lists the products and their supported environments. Below is a example of what I would expect. ... I suspect this need to be on the MyFaces site. Well... then... add it. :) Seriously, we're a 'commit then review' project, and documentation is unlikely to be controversial. If you think it needs to be done but don't have time right now, open a JIRA issue and maybe someone else will pick it up. -- Wendy -- Arash Rajaeeyan
Re: MyFaces Fusion Naming
and may be thats because shale has chosen a different approach? On 3/2/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi ! Just out of curiosity, why is this part of MyFaces as opposed to Shale. It sounds more like something that belongs there... We developed it under the MyFaces umbrella during the last months, we started with a tag base way until we reached the spring based solution we have now. So, thats why it's still here. We will see what the future brings. Ciao, Mario -- Arash Rajaeeyan
Re: MyFaces Fusion
I think the best way is to extend the bean scopes and add some other scope(s) for conversation or dialogs. I think in first proposal they said they want to take best practices of Seam, Shale, ADF, and other JSF based frameworks and find best practices for web development, and put them in web beans (JSR 299) it can be addressed in low level Servlet API but it can also be addressed in higher levels like JSF frameworks. 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? 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. 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? Werner -- Arash Rajaeeyan
Re: [POLL] Sort out of MyFaces Fusion Naming candidates
my poll: - Kleber - Chasb - Simplex - Platypus On 2/28/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! Ok, here we go. This is a poll where I hope that we can sort out the most of the names below (shouldn't be that hard ;-), afterwards I hope we are stripped down to max 4 names where we can start a vote then. Thanks for your time! Just remove the names you don't like, I'll try to sum up those decisions on the wiki page then. == Candidates == * Apache MyFaces Connections * Apache MyFaces Vista * Apache MyFaces Salida * Apache MyFaces Defender * Apache MyFaces Seamless * Apache MyFaces Mergence * Apache MyFaces Accretion * Apache MyFaces Collective * Apache MyFaces Aurora * Apache MyFaces Concerto * Apache MyFaces Orchestra * Apache MyFaces ease * Apache MyFaces Snug * Apache MyFaces Rush * Apache MyFaces Salida * Apache MyFaces Piletra * Apache MyFaces Kleber * Apache MyFaces Sepia * Apache MyFaces Chasb * Apache MyFaces Rapid * Apache MyFaces Custos * Apache MyFaces Coire * Apache MyFaces Simplex * Apache MyFaces Transit * Apache MyFaces Tenere * Apache MyFaces Memini * Apache MyFaces Memento * Apache MyFaces Custos * Apache MyFaces Coire * Apache MyFaces Simplex * Apache MyFaces Transit * Apache MyFaces Tenere * Apache MyFaces Memini * Apache MyFaces Memento * Apache MyFaces Pure * Apache MyFaces Direct * Apache MyFaces Alta * Apache MyFaces Sublime * Apache MyFaces Platypus * Apache MyFaces Brevi Ciao, Mario -- Arash Rajaeeyan
Re: MyFaces Fusion
how can I see the result of this work? On 2/27/07, Werner Punz [EMAIL PROTECTED] wrote: Sorry to jump in here again, I have been playing guinea pig the last week for marios work. All I can say is this thing now is highly usable by now. You can put a view controller under conversation scope (not a shale one yet, you will lose the callbacks) and simply work on the stuff now like you would do in a rich client environment with an EntityManage, Hibernate Session open for the entire conversation. once you hit a point when you want to terminate, you can have the view controller/conversation invalidate itself or restart itself. Also binding component bindings onto such a conversation is taken care of, you can push them into a separate bean which you weave in by a scope of request and aop:scoped-proxy, then you basically get a fresh view onto your backend component bindings at every request. To sum it up, I just almost finished a first full master detail crud ( I have done several details forms before) The master form has about 30 lines of core code, excluding the setters and getters already dealting with dao calling, handling the query part etc... and adding a detail was a matter of one hour of figuring out which patterns work best and a few minutes of implementation handling new update and delete. The objects you work with always are the same the orm layer accesses, so a simple update ends up normally with entitymanager.flush(); And btw. bindings for hibernate and jpa already are in place... All I can say is a lot of thanks to mario for this, this is a killer... I think he has found the right mix of exposing the api and trying to automate. Seam while being excellent and Gavin was entirely correct with his approach of keeping the entitymanager open for a conversation, automates and hides way too much for my taste. One example is that it takes away the control how you connect the master and the detail, and in the end breaks the Tomahawk table that way. Gerald Müllan schrieb: Mario, i am feeling very confident that this will be a great addition to MyFaces in the near future. Through many lessons learned, I can admit that using Spring + JSF together makes up a powerful combination. Tying the new Spring/MyFaces-Conversation scope to JSF brings us beneath a seam-approach, but with less burden. I am quite curious about using the sample-app! As i believe, the sandbox stuff will be removed, after fusion will be quite stable. I also agree that it should have been discussed on the list, but ok it is done now. Next time devs should be informed before such a big commit takes place. cheers, Gerald -- Arash Rajaeeyan
Re: MyFaces Fusion
thank a lot mario, I have started to give it a try. hope I can learn it fast and write about it soon. On 2/27/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi Arash! how can I see the result of this work? I don't know if Werner is able to put his work into public, though, I am working on an example showing the same patterns. It took some time to setup the examples framework, though, yesterday I managed to bring it up and can start now to implement a nice example. You can keep track by checkout fusion from: https://svn.apache.org/repos/asf/myfaces/fusion/trunk You'll have to have a myfaces checkout too which requires a mvn install first. Then change into fusion and execute mvn install there too. Change into fusion/examples and start mvn jetty:run (Thanks to Matthias Wessendorf who provided the configuration for it), though, don't expect too much for now :-) I'll try to finish and polish this simple example and will create the documentation based on it then. Also thanks to Werner Punz who put enormous time into debugging all the stuff. I plan to have an official announcement next week. Today evening I'll kick off a naming discussion on the ml. Ciao, Mario -- Arash Rajaeeyan
Re: MyFaces Fusion
nice demo, dose any documentation exist any where to start? (other than this example) On 2/27/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi Arash! how can I see the result of this work? I don't know if Werner is able to put his work into public, though, I am working on an example showing the same patterns. It took some time to setup the examples framework, though, yesterday I managed to bring it up and can start now to implement a nice example. You can keep track by checkout fusion from: https://svn.apache.org/repos/asf/myfaces/fusion/trunk You'll have to have a myfaces checkout too which requires a mvn install first. Then change into fusion and execute mvn install there too. Change into fusion/examples and start mvn jetty:run (Thanks to Matthias Wessendorf who provided the configuration for it), though, don't expect too much for now :-) I'll try to finish and polish this simple example and will create the documentation based on it then. Also thanks to Werner Punz who put enormous time into debugging all the stuff. I plan to have an official announcement next week. Today evening I'll kick off a naming discussion on the ml. Ciao, Mario -- Arash Rajaeeyan
Re: MyFaces Fusion Naming
I propose Chasb Chasb means Glue in my native language, we can use other translations of glue like colle colla Kleber lijm κόλλα клей colagem pegamento On 2/28/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Mike, It's up to you, but I'd think using a wiki page would be far easier to manage. You can propose names, and then group them as they're added: I thought that too, and I'll do so tomorrow, for now letz use the jira just to collect the names without any bias. I'll close the jira (maybe tomorrow if no new names follow) and then we should stop proposing new names, at that time I'll take them over to a wiki page and we can start to sort out stuff. I'll maintain the wiki page then; based on ml discussions. Ciao, Mario -- Arash Rajaeeyan
Re: MyFaces Fusion
just give me some hints if possible I have two more days to finish this part of the book I am writing and I am interested to replace the seam framework I used in my example with fusion (or what ever it will be called in future) I have used only seam for integration with JPA, and it looks like I can replace it. On 2/28/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi Arash! nice demo, hehe, dont lie ;-) dose any documentation exist any where to start? (other than this example) Unfortunately no, not yet. But I'll start one soon. Ciao, Mario -- Arash Rajaeeyan
Re: [jira] Commented: (MYFACES-1546) Find a new name for Apache MyFaces Fusion
another Idea using name of foods people cook and eat when they are in hurry, I eat fish tuna or omelet when I don't have time too cook! may be the name brings similar idea in mind to developers. Tuna, Grill, Omelette or (omelet), Sandwich, Snack, Chips, Sausage, ... Add Apache MyFaces to the begging if neccessary On 2/28/07, Mario Ivankovits (JIRA) dev@myfaces.apache.org wrote: [ https://issues.apache.org/jira/browse/MYFACES-1546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12476388] Mario Ivankovits commented on MYFACES-1546: --- some more MyFaces ease MyFaces Snug MyFaces Rush Find a new name for Apache MyFaces Fusion - Key: MYFACES-1546 URL: https://issues.apache.org/jira/browse/MYFACES-1546 Project: MyFaces Core Issue Type: Task Components: General Reporter: Mario Ivankovits This jira is to collect new names for Apache MyFaces Fusion so far: Apache MyFaces Connections Apache MyFaces Vista Apache MyFaces Salida Apache MyFaces Defender Apache MyFaces Seamless Apache MyFaces Mergence Apache MyFaces Accretion Apache MyFaces Collective Apache MyFaces Aurora Apache MyFaces Concerto Apache MyFaces Orchestra -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. -- Arash Rajaeeyan
Re: MyFaces Fusion
I am more interested in ORM control part. I prefer to stay neutral between seam and shale in the book :) On 2/28/07, Werner Punz [EMAIL PROTECTED] wrote: Arash Rajaeeyan schrieb: just give me some hints if possible I have two more days to finish this part of the book I am writing and I am interested to replace the seam framework I used in my example with fusion (or what ever it will be called in future) I have used only seam for integration with JPA, and it looks like I can replace it. If you use seam only for conversational control, yes then you can replace it, but seam has a lot of other added value which sometimes is a good supporting layer sometimes you do not need it, fusion has a dedicated scope, which is not quite the same as seam or currently existing dialog systems (but current dialog systems can use fusion as provider for their scope control, with the added value of getting full orm control as well) -- Arash Rajaeeyan
Re: MyFaces Fusion
Thanks mario, (and Werner) thats this is more than enough! On 2/28/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi Arash! just give me some hints if possible I have two more days to finish this part of the book I am writing and I am interested to replace the seam framework I used in my example with fusion (or what ever it will be called in future) I have used only seam for integration with JPA, and it looks like I can replace it. O-K I'll try: For the installation you have to configure the conversation scope in spring, for this you could have a look at fusion/examples/src/main/webapp/WEB-INF/applicationContext.xml As might see, the conversation scope is configured using an advice, the persistentContextConversationInterceptor. This interceptor holds the entity manager for a conversation and is responsible to configure the thread. Every bean configured in conversation scope (using scope=conversation) will get a new entity manager. If you used spring before, your knowledge about daos wont change. Each conversation bean has to have the aop:scoped-proxy/ marker. This creates a proxy so that - even if you end a conversation - you can work with this bean - but on an new instance then. You can use the conversation scoped bean directly as your backing bean for the view, this is the common case if you have to deal with a single page only. If you have a wizzard like pageflow you'll typically create a conversation scope bean which you inject into your request scope backing bean then. The method in your conversation bean which will issue an update has to be annotated with @Transactional - you can change your entites in not annotated methods too, but then they are not flushed - the flush is delayed unit a @Transactional method has been invoked. That way the entity manager will issue a commit() at the end of the method. Tha can also be the point where you end a conversation, from within the conversation bean you can access the current conversation using Conversation.getCurrentInstance() The conversation can also be invalidated(), which means the next access to the bean instance will see an new empty one. There are strategies to restart a conversation too. The point is that you use the (well known) strategies of spring to get access to the entity manager, and in JPA they are the standardized. Fusion just configures spring so that it will see the associated entityManager for the to-be-invoked conversation. I am not sure if I manged to make things clearer now - all in all its the spring configuration which you have to make correct, afterwards there are just a handful of patterns which you should follow to make the most use out of fusion. Ciao, Mario -- Arash Rajaeeyan
Re: MyFaces Fusion
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)? On 2/28/07, Craig McClanahan [EMAIL PROTECTED] wrote: 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 -- Arash Rajaeeyan
Re: MyFaces Fusion
I have also developed a simple application which I want to use teaching MyFaces. I have used Seam components for integration with JPA as data access layer. It looks like this fusion lead a more pure MyFaces application. and I am ready to use it, if you provide some minimum guidelines for rest of us. On 2/23/07, Gerald Müllan [EMAIL PROTECTED] wrote: Regarding the demo-app, i could help out with a nice open-source design which i had improved and used in a sourceforge app and our [EMAIL PROTECTED] website: http://jsfatwork.irian.at Let me know if it seems to be useful for MyFaces Fusion. I am willing to re-design the demo-app so that it is human-readable :) cheers, Gerald On 2/23/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi Cagatay! I'd really really like to help if you need:) There is plenty of room to help :-) Thanks! Short term todos are: * Demo App * Documentation Regarding the DemoApp, maybe Werner is able to donate one, if not we have to build one. Would be great if you could help there if we have to cross that bridge. At least the initial Documentation has to be done by myself (unfortunately ;-) ) Ciao, Mario -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Arash Rajaeeyan
Re: MyFaces Fusion
I can send a working copy to your private email. if you want. zubin is going to use it in his book. I am changing it each day to make it easier for developers learning MyFaces. On 2/23/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: Arash- is your app somewhere accessable ? -M On 2/23/07, Arash Rajaeeyan [EMAIL PROTECTED] wrote: I have also developed a simple application which I want to use teaching MyFaces. I have used Seam components for integration with JPA as data access layer. It looks like this fusion lead a more pure MyFaces application. and I am ready to use it, if you provide some minimum guidelines for rest of us. On 2/23/07, Gerald Müllan [EMAIL PROTECTED] wrote: Regarding the demo-app, i could help out with a nice open-source design which i had improved and used in a sourceforge app and our [EMAIL PROTECTED] website: http://jsfatwork.irian.at Let me know if it seems to be useful for MyFaces Fusion. I am willing to re-design the demo-app so that it is human-readable :) cheers, Gerald On 2/23/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi Cagatay! I'd really really like to help if you need:) There is plenty of room to help :-) Thanks! Short term todos are: * Demo App * Documentation Regarding the DemoApp, maybe Werner is able to donate one, if not we have to build one. Would be great if you could help there if we have to cross that bridge. At least the initial Documentation has to be done by myself (unfortunately ;-) ) Ciao, Mario -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Arash Rajaeeyan -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Arash Rajaeeyan
Re: Suggested Version number roadmap (was Re: Tomahawk 1.1.5 release plans?)
I think a version number which is more similar to JSF standard versions will be much easier for beginners. and less confusing On 2/23/07, Paul Spencer [EMAIL PROTECTED] wrote: This is to summarize the version number discussion. MyFaces for JSF 1.1 1.1.5 - Current Release (Announced 19-Feb-2007) 1.1.6 - Next release not currently scheduled MyFaces for JSF 1.2 2.0.0 - Currently being developed as MyFaces 1.2 MyFaces for JSF 2.0 / JSF 6 3.0.0 - ? Tomahawk for JSF 1.1 1.1.3 - Current Release (Announced 14-Jun-2006) 1.1.5 - Next release, currently in process 1.6.0 - Following release Tomahawk for JSF 1.2 2.x - Not started Paul Spencer -- Arash Rajaeeyan
Re: [Help - Translation] JSF 1.2 Impl found - Apache License ?
by the way why don't you see this one: http://www.apusic.com/en/ On 1/12/07, Arash Rajaeeyan [EMAIL PROTECTED] wrote: hi Matthias, try using this site for translation from Chines to English (or to German) http://babel.altavista.com/ On 1/12/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hello, I am searching for sb. able to translate Asian languages (I think Chinese). The reason: By accident I found a JSF 1.2 impl, which seams to be open source at least that page says that: http://www.operamasks.org/Licence.jsp The main page is http://www.operamasks.org/ The page is owned by a company (selling/providing containers) http://www.apusic.com/ In case of Apache 2.0 License, we can speed up your implementation. In case of not, good to see a new version of a JSF Impl (not only sun, myfaces and ibm) Thanks! Matthias -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Arash Rajaeeyan -- Arash Rajaeeyan
Re: spring conversation start (@manfred)
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). then what will happen to users who use Seam or future WebBean with MyFaces? as you may know seam also has its own phase listener and bean managment facility. can seam users also continue using myfaces? (seam has its own conversation mechanism, http://docs.jboss.com/seam/1.1GA/reference/en/html/conversations.html) will nested conversations also be allowed? 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. Ciao, Mario -- Arash Rajaeeyan
Re: spring conversation start (@manfred)
Hi Since jacob is also here, it is a long time that some components like tree don't work well with facelets, is resolving the issues on the plan? On 12/19/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Oh, thanks! Hi Jacob! how's JSF 1.2 coming along btw? What do you mean? As far as I can see JSF 1.2. do not introduce any new (flash or conversation) scope. So (IMHO) our solution works with JSF 1.2 too. If you mean how far our (MyFaces) JSF 1.2 implementation is ... well ... then I have to say there is another team working on it, I don't know. Ciao, Mario -- Arash Rajaeeyan
Re: spring conversation start (@manfred)
Thanx Matthias, very useful link, but I meant the old tree component not tree2, which people who need a tree table should still use it (according to myfaces web site) On 12/19/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: http://www.jroller.com/page/plainoldweblog?entry=use_tomahawk_tree2_and_ajax4jsf On 12/19/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: at least here is a famous blog, which shows the usage of tree2 and facelets (with ajax4jsf) On 12/19/06, Arash Rajaeeyan [EMAIL PROTECTED] wrote: Hi Since jacob is also here, it is a long time that some components like tree don't work well with facelets, is resolving the issues on the plan? On 12/19/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Oh, thanks! Hi Jacob! how's JSF 1.2 coming along btw? What do you mean? As far as I can see JSF 1.2. do not introduce any new (flash or conversation) scope. So (IMHO) our solution works with JSF 1.2 too. If you mean how far our (MyFaces) JSF 1.2 implementation is ... well ... then I have to say there is another team working on it, I don't know. Ciao, Mario -- Arash Rajaeeyan -- 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 -- Arash Rajaeeyan
swapImage component
swapImage component has no documentation at all, and its realted example is not working.since last revision is 2006-03-01 it looks like component is not deprecated.it looks like the developer is Thomas Spiegl would he or the one who is maintaining it tell me what is its status? and possibly some hints for documenting it?Arash Rajaeeyan
Re: MyFaces with Sun's JSF RI on Websphere5.1
hi roy,I am not sure but I think IBM has its own implementation of JSF not suns, http://www-128.ibm.com/developerworks/forums/dw_thread.jsp?message=13706717cat=28thread=75431treeDisplayType=threadmode1forum=472#13706717as you said, you are using jsf-ibm.jar in your project.On 11/2/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi All, Desperately in need of answers to make it work. 1)I am using WebSphere5.1 and RAD6 for IDE. 2)The jars i am using are :Tomahawk1.1.3.jar,jsf-api.jar,jsf-impl.jar. (Apart from the jars common-beanutils.jar,common-codec1.3.jar,common-collections.jar,common-digester.jar,common-lang.jar2.1,javax-jdom.jar,jdom.jar,jsf-ibm.jar,jsf-portletjar,jstl.jar,jstl_el.jar,standard.jar,saxpath.jar and common-fileupload.jar.) Please note i am not using myfaces-api.jar and myfaces-impl.jar my project wants to use only Sun's JSF RI.Can Tomahawk1.1.3 work withoutmyfaces-api and myfaces-impl.jar.?? 3)My application uses t:inputCalender and t:panelTabbedPane. 4)The exception that i get is :Nested Exception is java.lang.IllegalStateException: ExtensionsFilter not correctly configured. JSF mapping missing. JSF pages not covered. Please see: http://myfaces.apache.org/tomahawk/extensionsFilter.html 5) The web.xml is configured as : filter filter-nameextensionsFilter/filter-name filter-classorg.apache.myfaces.webapp.filter.ExtensionsFilter/filter-class init-param param-nameuploadMaxFileSize/param-name param-value100m/param-value descriptionSet the size limit for uploaded files. Format: 10 - 10 bytes 10k - 10 KB 10m - 10 MB 1g - 1 GB/description /init-param init-param param-nameuploadThresholdSize/param-name param-value100k/param-value descriptionSet the threshold size - files below this limit are stored in memory, files above this limit are stored on disk. Format: 10 - 10 bytes 10k - 10 KB 10m - 10 MB 1g - 1 GB/description /init-param /filter filter-mapping filter-nameextensionsFilter/filter-name url-pattern*.jsf/url-pattern /filter-mapping filter-mapping filter-nameextensionsFilter/filter-name url-pattern*.jsp/url-pattern /filter-mapping filter-mapping filter-nameextensionsFilter/filter-name url-pattern*.faces/url-pattern /filter-mapping filter-mapping filter-nameextensionsFilter/filter-name url-pattern/faces/*/url-pattern /filter-mapping Can you please help me in this regard.How should i configure the extension filters or use any new jars.I am struggling to get this work. Best Regards, Pallavi The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com -- Arash Rajaeeyan
development attribute in dojoInitializer
development attribute in dojoInitializer, is in DojoInitializerTag.java but it is not in TLD class, half documented in xdoc web site.is it removed or what?Arash Rajaeeyan
Re: Option for NavigationHandler to support viewIds as outcome
It is much easier for a developer (especially if they are beginners in JSF) to return name of the page instead of event occurred in page (logical outcome) as output. There are some bad development practices, which when a developer get used to them, it is hard to forget, I think this feature is one of them.since this bad practice(same reasons as described by Craig), makes life easier for them, when they have this feature they will get addicted to it, and they won't learn the real idea behind outcomes. I think this is like giving marijuana to JSF developers! Like the cartoon in the theserverside.com about AOP considered harmful ;-) RegardsArashOn 10/30/06, Martin Marinschek [EMAIL PROTECTED] wrote: Hi Craig,It's all about convention over configuration, and this concept is inturn very good for maintenance. Writing unnecessary configuration codeisn't.Let's look at an automatic navigation handler in practice: 1) I have a managed-bean action-method which returns overview andthis means, I'll go to overview.jsp2) I want to change this to go to overview_2.jsp3) so I won't change anything in the managed-bean-method, but create a new navigation-rule (in your case, I'd need to change thenavigation-rule - where is the maintenance difference, I don't touchmy managed-bean?)4) If I want to go to somewhere else from any other page, I'll need to create additional navigation-rules, according to the concept of JSF.Essence is - you don't have to change anything in your managed bean,youjust add configuration rules where necessary, but keep them out where unnecessary.regards,MartinOn 10/30/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 10/30/06, Martin Marinschek [EMAIL PROTECTED] wrote: Hi Craig, you have been argumenting into this direction before, and I'm sorry to disagree completely. What JSF does in the standard is good for projects 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 them the ability to have a convention-over-configuration approach? You can always override convention-over-configuration by supplying configuration! 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 about annotations you've made the same proposal as Ernst has at the beginning of this discussion - writing a custom navigation-handler which enables one to optionally not configure navigations, and not handle 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, Martin Craig--http://www.irian.at Your JSF powerhouse -JSF Consulting, Development andCourses in English and GermanProfessional Support for Apache MyFaces-- Arash
Re: Option for NavigationHandler to support viewIds as outcome
Hi Martin, may be this feature is very good for highly professional developer like you, but consider those developers new in JSF.what is the different between this and using forward and redirect methods, from developer point of view? (not considering JSF life cycle problems) (if a developer uses forward and direct, then s/he is not even forced to define a view for their page in facesconfig file! and he can use the same methods he may already know from JSP/ Servlet)I have seen lots of .net and JSP developers who were trying to use navigation rules just the way as redirects. and complaining about how hard is it in JSF to redirect into another page, (complex methods), I think this is just as Craig says because they haven't understand the deep rationality behind navigation mechanism yet, and this feature will help them never understand it! On 10/30/06, Martin Marinschek [EMAIL PROTECTED] wrote: Hi David,@breaking tool support: yes, that's true, and is something that mightor might not be of interest to developers.@application size: For an application with 2000 views, we'redefinitely talking about large-size here. I'm absolutely d'accord that for a large size applications with a high number of developersassigned to them the normal navigation system should be used.Having the option of not using the default navigation system forsmall, simple applications is something positive, though. regards,MartinOn 10/30/06, David Chandler [EMAIL PROTECTED] wrote: Don't forget that returning view IDs in outcomes will break tool support such as the visual page flow designer in Exadel Studio. Even without tools, I find it extremely helpful as a developer to be able to look in one place to see how the application flows. The proposed capability would make that impossible, so I agree with Craig and Arash that returning view IDs in outcomes is unsuitable for apps that will be maintained by multiple developers. Having worked as one of 30+ developers on a large application (2000 views) written in a scripting language that effectively returned view IDs in outcomes, I can testify to the horrors of code maintenance with this approach. Introducing finite state machine navigation into that code base and moving nav rules to config files has made it much easier to work on. David Chandler JSF Consultant / Trainer learnjsf.com On 10/30/06, Arash Rajaeeyan [EMAIL PROTECTED] wrote: It is much easier for a developer (especially if they are beginners in JSF) to return name of the page instead of event occurred in page (logical outcome) as output.There are some bad development practices, which when a developer get used to them, it is hard to forget, I think this feature is one of them. since this bad practice(same reasons as described by Craig), makes life easier for them, when they have this feature they will get addicted to it, and they won't learn the real idea behind outcomes. I think this is like giving marijuana to JSF developers! Like the cartoon in the theserverside.com about AOP considered harmful ;-) Regards Arash On 10/30/06, Martin Marinschek [EMAIL PROTECTED] wrote: Hi Craig, It's all about convention over configuration, and this concept is in turn very good for maintenance. Writing unnecessary configuration code isn't. Let's look at an automatic navigation handler in practice: 1) I have a managed-bean action-method which returns overview and this means, I'll go to overview.jsp 2) I want to change this to go to overview_2.jsp 3) so I won't change anything in the managed-bean-method, but create a new navigation-rule (in your case, I'd need to change the navigation-rule - where is the maintenance difference, I don't touch my managed-bean?) 4) If I want to go to somewhere else from any other page, I'll need to create additional navigation-rules, according to the concept of JSF. Essence is - you don't have to change anything in your managed bean, youjust add configuration rules where necessary, but keep them out where unnecessary. regards, Martin On 10/30/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 10/30/06, Martin Marinschek [EMAIL PROTECTED] wrote: Hi Craig, you have been argumenting into this direction before, and I'm sorry to disagree completely. What JSF does in the standard is good for projects 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 arethe same whether there is one developer performing multiple roles, ordifferent 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
Re: Option for NavigationHandler to support viewIds as outcome
Hi Martin,First thanks for taking time and answering me.Believe me or not, the concept is hard to grasp for lots of developers, at least for people in my country who are not as wise and intelligent as people in Germany and Austria, lots of developers are not Computer Science PHD and most of them are not even college educated!I remember 10 years ago, when we were developing codes in C++, most of our time was spend on finding memory problems caused by illegal pointers created by freeing an object in wrong places. Now with garbage collection in java it is years that I haven't seen the problem, although average knowledge of developers is much lower now because of high demand in IT industry.May be this phrase is wrong, but it think a good development framework (especially those who are designed for ease of use) should not let developers make mistakes.I remember when I was in guidance primary school, our Pascal and C programming teacher decided not to teach us about Labels, because he knew that some of us had some experience in GW-Basic programming and we can't get ride of GOTO, and we can't ever learn structured programming, now I think the same case is about this NavigationHandler mechanism, it is like goto in structured languages.RegardsArash On 10/30/06, Martin Marinschek [EMAIL PROTECTED] wrote: Hi Arash,I don't think we're in the JSF space to force developers to dosomething in a certain way. The navigation system of JSF is good, it'sbeen devised with decoupling in mind, and you might want or not want that for your application - I don't think that the rationale behindthis is hard to grasp for anyone. So your sentence about the deeprationality behind the navigation mechanism is a bit overblown... Especially, as with what Ernst suggested, you can still configure -you just don't have to!There is a host of web-frameworks which don't build on this decouplingout of the box - so why not giving the developer the option to do things in the way they're used to? Mind it, I'm not one of the guyswho hate configuration files, and I don't have anything againstfaces-config.xml. There are people out there who want to reduce it toa bare minimum, though, and I don't see why one shouldn't. Enough said, there are pro's and con's, and I do believe that anoption won't hurt anyone, if it's nicely implemented.regards,MartinOn 10/30/06, Arash Rajaeeyan [EMAIL PROTECTED] wrote: Hi Martin, may be this feature is very good for highly professional developer like you, but consider those developers new in JSF. what is the different between this and using forward and redirect methods, from developer point of view? (not considering JSF life cycle problems) (if a developer uses forward and direct, then s/he is not even forced to define a view for their page in facesconfig file! and he can use the same methods he may already know from JSP/ Servlet) I have seen lots of .net and JSP developers who were trying to use navigation rules just the way as redirects. and complaining about how hard is it in JSF to redirect into another page, (complex methods), I think this is just as Craig says because they haven't understand the deep rationality behind navigation mechanism yet, and this feature will help them never understand it! On 10/30/06, Martin Marinschek [EMAIL PROTECTED] wrote: Hi David, @breaking tool support: yes, that's true, and is something that might or might not be of interest to developers. @application size: For an application with 2000 views, we're definitely talking about large-size here. I'm absolutely d'accord that for a large size applications with a high number of developers assigned to them the normal navigation system should be used. Having the option of not using the default navigation system for small, simple applications is something positive, though. regards, Martin On 10/30/06, David Chandler [EMAIL PROTECTED] wrote: Don't forget that returning view IDs in outcomes will break tool support such as the visual page flow designer in Exadel Studio. Even without tools, I find it extremely helpful as a developer to be able to look in one place to see how the application flows. The proposed capability would make that impossible, so I agree with Craig and Arash that returning view IDs in outcomes is unsuitable for apps that will be maintained by multiple developers. Having worked as one of 30+ developers on a large application (2000 views) written in a scripting language that effectively returned view IDs in outcomes, I can testify to the horrors of code maintenance with this approach. Introducing finite state machine navigation into that code base and moving nav rules to config files has made it much easier to work on. David Chandler JSF Consultant / Trainer learnjsf.com On 10/30/06, Arash Rajaeeyan [EMAIL PROTECTED] wrote:It is much easier for a developer (especially if they are beginners in JSF) to return name of the page instead
Re: javadoc
Hi Sebastian,there are 1) Java Docs2) wiki pages3) maven XML documents which generate web site of myfacesthese should be updated and synchronized together, I have started to work on wiki, I hope when I finish we can start synchronizing javadocs and web pages. if you are interested to help you are very welcome we can divide the work between our selves.also soon there will be a book about MyFaces http://www.apress.com/book/bookDisplay.html?bID=10179On 10/30/06, Sebastian Menge [EMAIL PROTECTED] wrote: HiI've subscribed to this list to post just one remark/question.Myfaces is a great implementation. Another example of an opensource effort that will soon be better than the RI.But! ;-)Please take more care on documentation. The javadoc is really really ajoke.Please dont mind. I want to use myfaces in my setting and if I could I also would contribute something.But good documentation is for me about 50% of a good project.I was looking for _anything_ useful regarding the navigationPanels. Noway. There are some tags, there are some classes, no explanations, no cross references between tags and classes etc.There are a few postings on [EMAIL PROTECTED] or some forums, there are somewikipages. But such things should really be documented at some centralplace like javadoc ... Sorry, after nearly a week of wasting time with undocumented things, igot a little bit angry.Please take this as a suggestion to make myfaces a high quality project.Thanks alot for all the good work, Sebastian.PS I know, writing docs is not so exciting as implementing features ornew components. And if you want to do it good, its really difficult. (Ithink even more difficult than programming, because you have to think like your potential reader(s) and not only like the machine ...). Atlast a good documented API can give you a good feeling to... Really :-)To be a little bit constructive: There is a good text on this topic from Sun. Please read it and give it a try.http://java.sun.com/j2se/javadoc/writingdoccomments/ -- Arash Rajaeeyan
Re: [jira] Commented: (MYFACES-1383) FacesContextFactoryImpl issue using trinidad any myfaces core
Hi Craig,so you think it is better that we have another implementation of lifecyles for JSF portlets,(from scratch or using decoratore around current class) which can support both ActionRequest and RenderRequest and map them to different neccessary phases of JSF, one mapping for those who get ActionRequest and another for those which only recieve RenderRequest. am I correct?On 10/29/06, Craig McClanahan (JIRA) dev@myfaces.apache.org wrote: [ 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: BugComponents: Portlet_SupportAffects Versions: 1.1.5-SNAPSHOT Environment: pluto 1.1-dev, tomcat 5.5.17 running on linux 2.6.17Reporter: 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 -- Arash Rajaeeyan
Re: Option for NavigationHandler to support viewIds as outcome
I think this is a bad idea for following reasons:1) it is against the spec behaviour2) since in JSF 1.1 navigation outcomes are string it is completely possible for a programmer to have a syntax error in out comes 3) this make confusion between page names and outcomes (navigation events)4) I think outcomes and names of JSF pages should stay separate.JSF navigation is like an finite state machine (FSM) or finite state automaton, states are pages and outcomes are input to the automaton, this keeps modeling UI very simple. and also it makes it possible for formal verification of JSF application, with available tools.RegardsArash RajaeeyanOn 10/30/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?regardsErnst
Component and tags documentation and wiki
Hello All,I want to synchronize the latest web site documentations and Wiki InformationI want to use the following headers and clean the wiki informationI hope if the quality of works was good, the result transferred to web site documentations to. I want to use following headers and mote information into them and complete the definition:[Component Name]DescriptionScreen ShotAPIUsageSyntaxConfigurationInstructionsAdditional Information ExamplesFAQKnown Bugsfirst: does any one has any objections?second: do you suggest another format?Arash Rajaeeyan
Re: calling authors
me 2I am also volunteerI don't have any experience using Tobago. I haven't used Shale in any real world project.but I have used the rest of component and some times applied some small changes in them. tell me what do you want in that article?what topics should be covered in what detail.On 10/26/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:I am writing one on Trinidad for the German Java Magazine, maybe we can translate it later (deadline is december 20th or so)(I know I need to send you the portlet article too :) )-MOn 10/25/06, Kito D. Mann [EMAIL PROTECTED] wrote: Hello, I'm currently looking for people who are interested in writing great articles for JSF Central about MyFaces, Tomahawk, Tobago, Trinidad, or Shale. If you're interested, please reply! ~~~ Kito D. Mann ([EMAIL PROTECTED]) Author, JavaServer Faces in Action http://www.virtua.com http://www.virtua.com/- JSF/Java EE consulting, training, and mentoring http://www.JSFCentral.com http://www.jsfcentral.com/- JavaServer Faces FAQ, news, and info--Matthias Wessendorf http://tinyurl.com/fmywhfurther stuff:blog: http://jroller.com/page/mwessendorfmail: mwessendorf-at-gmail-dot-com -- Arash Rajaeeyan
Re: calling authors
another idea comes into my mind, when I finished the article I can put it on wiki or post it to list, and let others edit it or send their suggestions.On 10/26/06, Arash Rajaeeyan [EMAIL PROTECTED] wrote: me 2I am also volunteerI don't have any experience using Tobago. I haven't used Shale in any real world project.but I have used the rest of component and some times applied some small changes in them. tell me what do you want in that article?what topics should be covered in what detail.On 10/26/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:I am writing one on Trinidad for the German Java Magazine, maybe we can translate it later (deadline is december 20th or so)(I know I need to send you the portlet article too :) )-MOn 10/25/06, Kito D. Mann [EMAIL PROTECTED] wrote: Hello, I'm currently looking for people who are interested in writing great articles for JSF Central about MyFaces, Tomahawk, Tobago, Trinidad, or Shale. If you're interested, please reply! ~~~ Kito D. Mann ([EMAIL PROTECTED] ) Author, JavaServer Faces in Action http://www.virtua.com http://www.virtua.com/- JSF/Java EE consulting, training, and mentoring http://www.JSFCentral.com http://www.jsfcentral.com/- JavaServer Faces FAQ, news, and info --Matthias Wessendorf http://tinyurl.com/fmywhfurther stuff:blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Arash Rajaeeyan -- Arash Rajaeeyan
Re: Jira Probleme
so this may be even more interesting for you:http://en.wikipedia.org/wiki/German_AmericanOn 10/25/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: I expected that :)happy to read German content, when being in the states ;)-MOn 10/24/06, Zubin Wadia [EMAIL PROTECTED] wrote: Matthias, It was meant for Manfred, he just sent it to dev by mistake! Z. On 10/24/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: I think something went wrong here :) or at least we wanna ensure that every user can read (w/o to translate) your mail. PS: Alle Apache Server waren down, wegen server-umzug. people.apache.org immer noch. Jira wird wohl wieder. Keine Sorge :) -Matt On 10/24/06, Andreas Berger [EMAIL PROTECTED] wrote: Hallo Manfred, da du der Admin von Myfaces Jira bist, wollt ich dir nur bescheid geben, dass ich seit gestern keine Jira Mails mehr bekomme (und ich habe auch einen anderen aus der dev-liste gefragt, der sie auch nicht bekommen hat). Demnach weiß noch keiner dass ich eine Reihe von Patches hochgeladen habe, vor allem für dien CR [1].Bspw. kam für die Einstellung des Patches für [2] keine Mail. [1] http://issues.apache.org/jira/browse/MYFACES-1434 [2] http://issues.apache.org/jira/browse/MYFACES-1454 Vielleicht könntest du mal nachschauen, ob da noch alles richtig läuft. Danke, Andreas -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com --Matthias Wessendorfhttp://tinyurl.com/fmywhfurther stuff:blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com-- Arash Rajaeeyan
examples
Are we going to have myfaces examples in downloads page again?the text on http://myfaces.apache.org/gettingstarted.html is confusing for new comers when they find out there is no example to downloads. and it may be hard for them to get source from svn and make examples them self. Arash
Re: [jira] Created: (TOMAHAWK-741) create a component which creates the JSF tree based on beans and its annotations
hey Mario, these gui builder components are great I think they may gain lots of attentionis there any way I can read more about them?On 10/15/06, Mario Ivankovits (JIRA) dev@myfaces.apache.org wrote: create a component which creates the JSF tree based on beans and its annotations Key: TOMAHAWK-741 URL: http://issues.apache.org/jira/browse/TOMAHAWK-741 Project: MyFaces TomahawkIssue Type: New FeatureComponents: New Component Reporter: Mario Ivankovits Assigned To: Mario IvankovitsPriority: MinorThe component I'll going to add to the sandbox is the GUI Builder stuff I developed for FacesFreeway. The component name is dynaForm and I'll add it to the sandbox15 area as it requires annotations and thus java 5.0--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 -- Arash Rajaeeyan
Re: [jira] Created: (TOMAHAWK-741) create a component which creates the JSF tree based on beans and its annotations
sorry for being impatient, I had an argument with a rubby developer about how java can be as easy as ruby and I saw your component at same day! I find it very useful for that argument. On 10/15/06, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi Arash! hey Mario, these gui builder components are great I think they may gain lots of attention is there any way I can read more about them?Nope, there is only the source and a simple example yet. If you checkout myfaces using the url [1] you'll get the sandbox15module of tomahawk too.Though, to checkout the sandbox15 module only use [2]I try to add more examples and a Wiki documentation as we speak, so hold on for a while :-)Ciao,Mario[1] https://svn.apache.org/repos/asf/myfaces/current[2] http://svn.apache.org/repos/asf/myfaces/tomahawk/trunk/sandbox15-- Arash Rajaeeyan
Re: [jira] Created: (TOMAHAWK-741) create a component which creates the JSF tree based on beans and its annotations
future will bring us ... lets beat ruby - hehe - just kidding ;-)hey why not? when the JSR 276 finished we can bring ease of use of Java Studio Creator to All java IDE's then users can just drag and drop their database tables or java bean or EJB intro JSF pages and have the application ready! as I understood your GUI builder components are an small step for you and myfaces but a giant step for JSF community for this target! ;-)On 10/15/06, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi Arash! sorry for being impatienthehe :-) I had an argument with a rubby developer about how java can be as easy as ruby and I saw your component at same day! I find it very useful for that argument. Let's see how far we can go. For now I removed the persistence stuff,the master plan is to rework the persistence using ourconversationTag, but it should work with Seam too.Yea, and at the end there is still a mvn createApplication (or something like this) missing, it depends on the community what thefuture will bring us ... lets beat ruby - hehe - just kidding ;-)Ciao,Mario-- Arash Rajaeeyan
Question from project owners about 1.1 and 1.2 distribution numbering
Hi I am writing a guide for beginners on how to use MyFacesI have two questionsI want to know what will be package name for implementation of JSF 1.2 api on download siteis it going to be: myfaces-core-1.2.x ?if so will tomahawk branched to to two different versions one for running on JSF 1.1 and another for running on JSF 1.2 ?if answer is positive is tomahawk numbering going to be like this: tomahawk-1.1.x. (run on JSF 1.1) tomahawk-1.2.x. (run on JSF 1.2)Regards Arash Rajaeeyan
Re: who is in charge for JSR 301?
may be I don't get it correctly, but a good solution should cover both multi-part form and lifecycle concepts.On 10/12/06, Scott O'Bryan [EMAIL PROTECTED] wrote:Arash,Is this the multi-part form ExternalContext or the much simplified pre/post lifecycle stuff?ScottArash Rajaeeyan wrote: thank you Carsten, you may have seen the portlet patch of shinsuke for tomahawk, we (me and some other developers) want to do polish this patch and do similar thing for trindad and tobago. it will be great if we can have one soloution working for all components under myfaces umbrella and may be even other components. it looks like this target of JSR 301 as an exprienced member of this group, do you have any guidelines for us? On 10/12/06, Carsten Ziegeler [EMAIL PROTECTED] wrote: Yes, I'm in the spec group - but upto now I don't know who else from Apache is on. Carsten Matthias Wessendorf wrote: added Carsten On 10/11/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: I really really guess that the portlet guys at apache (Carsten for instance), will hook in. I bet they will, b/c -Portlet RI is Apache (Pluto) -JSF/Portlet Bridges are Apache (subproject of portals.apache.org ) On 10/11/06, Arash Rajaeeyan [EMAIL PROTECTED] wrote: I see name of Apache foundation there so there should be some one from Apache! if it is not ADF, is there any one from Myfaces ? I have requested to become a member, but I am not sure if they accept me! On 10/11/06, Scott O'Bryan [EMAIL PROTECTED] wrote: I don't think we really have one yet.I can jump on that if you guys want.Michael Freedman is the Spec Lead and he is someone I work with on a regular basis. -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/ -- Arash Rajaeeyan
Re: who is in charge for JSR 301?
thank you Carsten,you may have seen the portlet patch of shinsuke for tomahawk,we (me and some other developers) want to do polish this patch and do similar thing for trindad and tobago.it will be great if we can have one soloution working for all components under myfaces umbrella and may be even other components. it looks like this target of JSR 301as an exprienced member of this group, do you have any guidelines for us?On 10/12/06, Carsten Ziegeler [EMAIL PROTECTED] wrote:Yes, I'm in the spec group - but upto now I don't know who else from Apache is on.CarstenMatthias Wessendorf wrote: added Carsten On 10/11/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: I really really guess that the portlet guys at apache (Carsten for instance), will hook in. I bet they will, b/c -Portlet RI is Apache (Pluto) -JSF/Portlet Bridges are Apache (subproject of portals.apache.org) On 10/11/06, Arash Rajaeeyan [EMAIL PROTECTED] wrote: I see name of Apache foundation there so there should be some one from Apache! if it is not ADF, is there any one from Myfaces ? I have requested to become a member, but I am not sure if they accept me! On 10/11/06, Scott O'Bryan [EMAIL PROTECTED] wrote: I don't think we really have one yet.I can jump on that if you guys want.Michael Freedman is the Spec Lead and he is someone I work with on a regular basis.--Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.dehttp://www.osoco.org/weblogs/rael/-- Arash Rajaeeyan
Re: Public API's not part of JSF
Hi Matthiasis there any classes in any of those packages now?On 10/11/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:Hi *The shared-impl is not really available in source. It's part of the shared. There is also a shared-tomahawk generation. Shared itself willnot be released. I wrote a small wiki page on [1] about shared.@Martin: 434 ?if so, we (Sean, Wendy and me) just spoke to some portlet guys at the hackaton...that goes against old code etc, maybe they help us on that.btw. discussion about MyFaces's shared stuff should go to [EMAIL PROTECTED],since trinidad is not really depending on it ;) Greetings from sticky Austin.-Matthias[1] http://wiki.apache.org/myfaces/Shared_-_impl_or_tomahawkOn 10/10/06, Martin Marinschek [EMAIL PROTECTED] wrote: Hi Scott, we've had re-occuring discussions about a new commons-module. This would probably be good candidate for this. Additionally, I've still got to review a commit for a module by Shinsuke Sugaya, which is about portlet compatibility - maybe it would be good to put it there. regards, Martin On 10/11/06, Scott O'Bryan [EMAIL PROTECTED] wrote: Is there a place where we could store public API's that are not part of Faces in MyFaces?Would this be the shared-impl package?We'll likely need to support an interface to handle some of our filter functionality from a portlet.This interface would need be referenced by the MyFaces Bridge Portlet (in impl) and Trinidad Impl... Scott -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces--Matthias Wessendorfhttp://tinyurl.com/fmywhfurther stuff: blog: http://jroller.com/page/mwessendorfmail: mwessendorf-at-gmail-dot-com-- Arash Rajaeeyan
Re: who is in charge for JSR 301?
I see name of Apache foundation thereso there should be some one from Apache!if it is not ADF, is there any one from Myfaces ?I have requested to become a member, but I am not sure if they accept me! On 10/11/06, Scott O'Bryan [EMAIL PROTECTED] wrote: I don't think we really have one yet.I can jump on that if you guyswant.Michael Freedman is the Spec Lead and he is someone I work withon a regular basis.ScottArash Rajaeeyan wrote: hello who is in charge for JSR 301 here? -- Arash Rajaeeyan-- Arash Rajaeeyan
Re: dynamic table columns et al
Hi MarioI think this sound pretty much like rubby on railsI don't know about other developersbut I think some people like this kind of components for making rapid web sitesome people hate these kind of components because the code is doings lots of thing implicitly and the code is not showing those behaviour.
lets see what Myfaces gods think about this.On 10/11/06, Mario Ivankovits [EMAIL PROTECTED] wrote:
Hi!As some of you might know I've developed Faces Freeway [1].Well, I don't want to say that this project failed, but - beside - its
hard to maintain a documentation, it is also hard to provide a nicelooking, always working fully fledged simple way to the persistenceframework e.g. hibernate.BUT, there is one thing I'd like to donate to MyFaces.
The GUI Builder.The GUI Builder is responsible to instrument another component to viewselected properties out of an annotated Bean (EJB3).I'd like to let speak code (piece of[2]):ff:form var=blog uri=ejb:
blog.Blogh:panelGrid id=blog-layout columns=2 //ff:formThe above simply does the following:* Lookup a bean by its FQN (=blog.Blog)* Lookup a child component whose id is blog-layout (That is by
convention. The form's var is blog, so the target component has to beblog-layout)* invoke the GUI Builder to dynamically add the bean's properties to thegrid (in this case)At the end, the you'll see a page as if you have written many
outputLabel and input* components.The same goes for a table (piece of [3]):ff:form var=city uri=ejb:blog.Cityh:dataTable id=city-layout var=entity value=#{
city.fc.entities} rowClasses=tr1,tr2h:column id=data rendered=false //h:dataTable/ff:formThe same as above, just creates a table header and its columns. The
id=data column is optional, but allows you to have pre and post columns.Ok, I hope I made it clear what it do and how it works. Again - I'dremove any requirement to a persistence framework. It should just do the
dynamic stuff.The proposed name could be: dynaBean :-) (instead of ff:form)One possibility I still have on my todo list is to allow the user toselect the properties which should be shown.This makes sense if you have beans with many properties, but only a
handful of properties are relevant to your customer. Then you cancustomize them easily. Maybe also adding user defined properties whichare computed at runtime (maybe using BSF) are possible (not yet, but
thats the masterplan)A factory the user has to provide is responsible to store all thiscustomization stuff.Due to its nature this component relies on annotations, well, can workwithout, but its more fun. So it has to go to sandbox15 (is it
functional already?)What do you think?Ciao,Mario[1] http://facesfreeway.l3x.net/[2]
http://l3x.net/svn/facesfreeway/trunk/examples/src/main/webapp/Blog.jsp[3]http://l3x.net/svn/facesfreeway/trunk/examples/src/main/webapp/Cities.jsp
-- Arash Rajaeeyan
Re: Tree2
Hello Mattias, I am so new to this list and may be I am not allowed to say this, but I think most developers I have seen use menu related components for only displaying structured data, and most of times data is displayed to user for one of the following purposes: 1) selecting one item 2) selecting multiple item 3) displaying and editing tree structured data (like organization chart, directory services, etc) the first 2 options are currently supported features of tree2, the 3'rd is under debate. May be if we can use same parent for both menu and tree navigation related components and simple tree data structure as said by matias and zubin, for parent of all these components can have following benefits: 1) simplifying development 2) simplifying learning for users 3) making it easier to add more advanced trees later on demand Best regards Arash On 10/5/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: I think a tree should display structured data and not be an input component.What should the input be? So you are willing register also validatorson the tree?maybe that is more specialized use case instead a generic tree use case you are looking at.On 10/5/06, Martin Marinschek [EMAIL PROTECTED] wrote: Hi Matthias, for the reason that every component that has changing values needs to be an editable value holder. Imagine the case of a tree embedded in a data-table - a data-table, at least the ones of both MyFaces and the RI (I know, Trinidad's data-table does something different) only save whatever is part of the EditableValueHolder interface. So the selection model of a tree won't be saved in a dataTable, except it is part of the EditableValueHolder interface. regards, Martin On 10/5/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: I think a tree is much more about sturctured data instead of input data The UIXCollection is a base clazz for the stamping, that you can say var on those tags. UIComponent | + - UIXComponent | + - UIXComponentBase | + UIXCollection Collection has some subclasses like UIXHierarchy | + UIXTree and UIXIterator | + UIXTable The Trinidad Tree uses a TreeModel which extends CollectionModel (Trin) which extends DataModel (Faces). CollectionModel is also used by the Trin Table. But, I am not really sure, why the table should be EditableValueHolder ? Thanks! -Matthias On 10/5/06, Martin Marinschek [EMAIL PROTECTED] wrote: Hi *, yes, I'd also like to do an Ajaxified version, but that's not the first thing I'm looking at. I believe that extending from UIData is not really what we should do - UIData is totally row-based, and a row-index doesn't make so much sense for a dynamic tree. What are the tree and the table of trinidad sharing with the UIXCollection interface? regards, Martin On 10/4/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:Hi M- On 10/4/06, Martin Marinschek [EMAIL PROTECTED] wrote: Hi *, I'm reviewing the tree2 currently, and I was wondering if we could have a discussion about some of the concepts. First thing I'd like to discuss is what happens with selected nodes. Currently, selecting a node fires an action-listener. This is somewhat ok, but I believe the selection-model of a tree should rather be a list of values, stored at a useful place. Therefore, the tree should implement the EditableValueHolder-interface, then we could do a lot more with the values of the tree as well. I am not really sure about the EditableValueHolder. In Trinidad theTree (UIXTree) is type of UIXCollection, which is also used by UIXTable. I remember some discussions from Sean in the past that they Tree2should extend UIData instead of UIComponent(Base) The change would necessitate to move the current value attribute to some other name - I suppose the name model would be more appropriate nothing wrong w/ using model instead of value, since value makes sense on(editable)valueHolders to me...(like UIOutput, UIInput, UISelect*,...) anyways (I've never understood why a dataTable has a value-attribute, by the way, the semantics for the value-attribute are generally quite different). I guess they just simply introduced that since there was a value of(edit.)value:_holders Additionally, the tree is doing a lot with respect to the markup of the component. I'm not sure if this is useful as very large HTML-bases result from this. I suspect it would be better to only transfer the data-model to the client (and maybe templates for each node-type), and then render the nodes on the client dynamically. you mean sending xml to the client and using a JS_engine to renderon the client side? -Matthias Thoughts? regards, Martin -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and
Re: Tree2
Dear Martin I think for most people its easier to use list of values as selection model of the tree.would you please also consider adding an Ajax capability to Tree2 ?(beside server mode and client mode) regardsOn 10/4/06, Martin Marinschek [EMAIL PROTECTED] wrote: Hi *,I'm reviewing the tree2 currently, and I was wondering if we couldhave a discussion about some of the concepts.First thing I'd like to discuss is what happens with selected nodes.Currently, selecting a node fires an action-listener. This is somewhat ok, but I believe the selection-model of a tree should rather be alist of values, stored at a useful place. Therefore, the tree shouldimplement the EditableValueHolder-interface, then we could do a lotmore with the values of the tree as well. The change would necessitate to move the current value attribute tosome other name - I suppose the name model would be more appropriateanyways (I've never understood why a dataTable has a value-attribute, by the way, the semantics for the value-attributeare generally quite different).Additionally, the tree is doing a lot with respect to the markup ofthe component. I'm not sure if this is useful as very large HTML-bases result from this. I suspect it would be better to only transfer thedata-model to the client (and maybe templates for each node-type), andthen render the nodes on the client dynamically.Thoughts? regards,Martin--http://www.irian.atYour JSF powerhouse -JSF Consulting, Development andCourses in English and GermanProfessional Support for Apache MyFaces -- Arash Rajaeeyan
JSF 1.2 on Java EE 5 Compatible Application Servers
there are 3 Java EE 5 Compatible Implementations:http://java.sun.com/javaee/overview/compatibility.jspSAP NetWeaver Application Server Java EE 5 Edition TmaxSoft JEUS 6Sun Java System Application Server Platform Edition 9 (Glassfish)does any body know what implementation of JSF are they using?is myfaces going to be tested on any of these implementations? RegardsArash Rajaeeyan
Re: [OT] JSF Developers Needed
Hi Zubin, please consider my resume: http://arash.rajaeeyan.googlepages.com/ArashRajaeeyanResume.html I have familar with JSF, facelets, CSS, XHTML and _javascript_. I have also read some books about user interface design.Kind regards Arash Rajaeeyan On 9/16/06, Zubin Wadia [EMAIL PROTECTED] wrote: Opportunities in the NY/NJ area - Interested Developers - please send your resume+rates to [EMAIL PROTECTED] or contact me on GTalk for details.Current positions are for Senior GUI Developers with competencies in JSF, Facelets, CSS, XHTML and _javascript_. Cheers, Zubin.-- Arash Rajaeeyan
Re: [jira] Commented: (MYFACES-1294) Current logic of register extensionFilter not support portlet environment
tell me more I willing to do every thing to support portlets! On 9/12/06, Martin Marinschek (JIRA) dev@myfaces.apache.org wrote: [ http://issues.apache.org/jira/browse/MYFACES-1294?page=comments#action_12433996 ]Martin Marinschek commented on MYFACES-1294:Filter -- PhaseListener and all our Portlet issues are solved. Anyone fancy doing this?regards, Martin Current logic of register extensionFilter not support portlet environment - Key: MYFACES-1294 URL: http://issues.apache.org/jira/browse/MYFACES-1294 Project: MyFaces CoreIssue Type: Bug Components: Portlet_SupportAffects Versions: 1.1.4-SNAPSHOTReporter: Serg Maslyukov (http://webmill.askmore.info)Priority: Blocker Current logic of register extensionFilter not support portlet environment fiter mappings: filter-mapping filter-nameMyFacesExtensionsFilter/filter-name servlet-nameFaces Servlet/servlet-name /filter-mapping filter-mapping filter-nameMyFacesExtensionsFilter/filter-name url-pattern/faces/myFacesExtensionResource/*/url-pattern /filter-mapping filter-mapping filter-nameMyFacesExtensionsFilter/filter-name url-pattern*.jsf/url-pattern /filter-mapping not work in portlet environment--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 -- Arash Rajaeeyan
Re: MyFaces ECCN 5D002
don't worryI am in Iran (main part of axis of evil)we have access to all this crypto codedon't waste your time hiding them! On 9/2/06, Dennis Byrne [EMAIL PROTECTED] wrote:Apache MyFaces has bindings to the javax.crypto API.Configuration parameters, supplied by an application developer, are passed through to the javax.crypto API, employing symmetric encryption algorithms with unlimited key lengths.The following from [1] leads me to believe that Apache Myfaces release artifacts fall under ECCN 5D002 (Export Control Classification Number). the definition of ECCN 5D002, which can be summarized as: ... Software using a symmetric algorithm employing a key length in excess of 56-bitsHowever the crypto page [1] also states the following: If my project ships a binary that provides bindings to OpenSSL, but does not include its source or binaries, what notifications must be made?The only required notification for an Apache project that is specially designed to use, but doesn't include, such crypto, is just the notification for the ASF product code. I think it is reasonable to say the javax.crypto API can replace OpenSSL here?Can anyone please clarify what just the notification for the ASF product code means?To be honest, the code in question was committed more than six months ago and there have been at least three releases.Keep in mind that we don't actually release the software that performs the strong encryption; application developers have to download this *themselves* from a group like Bouncy Castle [2].Such algorithms are not even distributed with a standard JVM release. Thanks to anyone who can help me in this matter,Dennis Byrne[1] http://www.apache.org/dev/crypto.html[2] http://www.bouncycastle.org/latest_releases.html-- Arash Rajaeeyan
Re: [jira] Reopened: (MYFACES-1338) MyFaces is initialized twice in Portlet
/ the name of 'messages' - only keeping the last WARN[org.apache.myfaces.config.FacesConfigurator.configureRuntimeConfig(588)] More than one managed bean w/ the name of 'form' - only keeping the last Both org.apache.myfaces.webapp.StartupServletContextListener.initMyFaces () and org.apache.myfaces.portlet.MyFacesGenericPortlet.initMyFaces() check a context attribute to see if MyFaces is initialized before invoking org.apache.myfaces.config.FacesConfigurator.configure() but both actually check and set a different attribute name. StartupServletContextListener uses: static final String FACES_INIT_DONE = StartupServletContextListener.class.getName() + .FACES_INIT_DONE; MyFacesGenericPortlet uses: protected static final String FACES_INIT_DONE = MyFacesGenericPortlet.class.getName() + .FACES_INIT_DONE; I find that if I override MyFacesGenericPortlet.initMyFaces() to do nothing, everythings works and I avoid the duplicate managed bean warnings. --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-- Arash Rajaeeyan
Re: [jira] Commented: (TOMAHAWK-464) Make Tomahawk work in portals
I am willing to do any help to support porlets in myfaces.also can some body please, put an article on wiki telling us (newly joined developers) where to get latest sources which we should work on? (I am confused which trunk is latest sources) On 8/29/06, Michael Lipp (JIRA) dev@myfaces.apache.org wrote: [ http://issues.apache.org/jira/browse/TOMAHAWK-464?page=comments#action_12431161 ]Michael Lipp commented on TOMAHAWK-464: ---I strongly support eliminating ExtensionsFilter. As Michael Binette has pointed out, there is a solution for adding style sheets. There is also a solution for handling file upload in the portlet bridge (as I have shown in MYFACES-556). Delivering resources from the MyFaces/Tomahawk jars can also simply be implemented by intercepting special URLs in the Servlet (or by a phase listener if you want), so this doesn't require a filter neither. (And honestly: isn't scanning and patching the generated HTML a very clumpsy approach?) I like using MyFaces, especially I like the additional features of Tomahawk. But I think it is an error of the MyFaces team to neglect portlet support as they do. I do believe that portal based applications will become more and more important (well, I should, currently working on them ;-)). I don't know what other issues ExtensionsFilter is trying to address, but I'd be happy to help with solving them, at least conceptually.I'm afraid conceptional help is all I will be able to offer, because another flaw of the MyFaces project is maintaining the source code in the way it does. I spent three days' evenings trying to configure a source code tree that matches the 1.1.3 binary distribution for debugging a problem. The SVN tree is a total mess. E.g. what version of shared is associated with 1.1.3? The build system seems to have changed since 1.1.3. The 1.1.3-taged versions of core and tomahawk reference some file in maven (I hate maven (TM)) that does not exists. I'd really like to contribute patches but I can't reliably establish the reference. I'll now endeavour to move (at least) the adding of _javascript_ to the portlet bridge. If anybody is interested: I'm mainting my own version of such a bridge with a lot of bug fixes at http://wfmopen.cvs.sourceforge.net/wfmopen/wfmopen/src/de/danet/an/util/jsf/MyFacesAdaptedPortlet.java?view=markup. I'm positive that I'll have the _javascript_ merging in there at the end of the week. Make Tomahawk work in portals - Key: TOMAHAWK-464 URL: http://issues.apache.org/jira/browse/TOMAHAWK-464 Project: MyFaces TomahawkIssue Type: ImprovementComponents: ExtensionsFilterAffects Versions: 1.1.1, 1.1.3-SNAPSHOT, 1.1.2, 1.1.4-SNAPSHOTReporter: Danijel Jevtic The ExtensionsFilter isn't working inside Jetspeed. Though this is not a technical blocker it would be great to be able to create portlets with tomahawk components (e.g. tree2). It works fine in 1.1.0 though. Kind regards--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 -- Arash Rajaeeyan
