Re: On an unrelated sidenote
Awesome! Congratulations! On Fri, Feb 11, 2011 at 5:50 PM, Bruno Aranda brunoara...@gmail.com wrote: Congrats!!! And forget sleeping... Bruno On 11 February 2011 22:36, Hazem Saleh haz...@apache.org wrote: Congratulations Werner! I bet you are a very good father. On Sat, Feb 12, 2011 at 12:26 AM, Werner Punz werner.p...@gmail.comwrote: I have become father of a nice little boy yesterday. My second child. Werner -- Hazem Ahmed Saleh Ahmed Author of (The Definitive Guide to Apache MyFaces and Facelets): http://www.amazon.com/Definitive-Guide-Apache-MyFaces-Facelets/dp/1590597370 http://www.amazon.com/-/e/B002M052KY Visualize and share your social networks 2D and 3D: http://www.mapmysocial.com
Re: OT: Oracle buys Sun
My two cents: http://zwadia.com/?p=91 Cheers, Zubin. On Mon, Apr 20, 2009 at 12:09 PM, Arash Rajaeeyan arash.rajaee...@gmail.com wrote: 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
[OT] ADF/JSF Developers Wanted
MyFacers, Looking for some capable JSF developers in the New York City area. Experience with JDeveloper / ADF / Weblogic is preferred but not compulsory. Candidates WILL be evaluated thoroughly for technical competence. I usually don't post here, but this is a good gig with real-world benefits for the user-base you are developing solutions for. Compensation is competitive; two positions are open for immediate placement. Cheers, Zubin.
Re: Thoughts on Trinidad
Agree with Werner's assessment on JSF2.0 adoption. The 1.2 adoption curve shouldn't be a benchmark for 2.0 adoption. I think 2.0, when it goes final, is going to have significant uptake. Apple might already be using the Mojarra snapshot for one of its rebate processes: http://weblogs.java.net/blog/edburns/archive/2008/09/apple_using_jsf.html Cheers, Zubin. http://zwadia.com On Sat, Oct 4, 2008 at 1:55 PM, Werner Punz [EMAIL PROTECTED] wrote: Andrew Robinson schrieb: However, as Matthias pointed out, JSF 2.0 standardize Trinidad's principal core features namely PPR and Resource handling and hopefully skinning too. Under such circumstances, I feel that we should wait for 2.0 to be cemented before going through a massive refactoring of some of the old and twisted code parts so that the refactored design is fully compatible with 1.2, but using 2.0 concept to make the upgrade to 2.0 easier imho. Although those are really good concerns, I wonder how long it will take JSF2 to be adopted. It seems like many are even reluctant to adopt 1.2. So I wonder if it is still worth it for us to make an effort to at least clean up the 1.2 trunk? (I did not mention the 1.0 trunk as I seem to have lost my desire to maintain the JSF 1.1 code myself) Well the JSF 1.2 adaption is slow, due to several reasons, some people cannot due to the Java 5 adoption inherent to JEE5 (Political concerns). For others it simply is not worth it, they do not gain too much, most areas JSF 1.2 addresses are covered already by extensions. JSF2 however is an entirely different issue, if it works out it removes pretty much every weak point of jsf and adds a lot of stuff people really need in their day to day applications. I assume the adoption will probably very high with new applications probably trying to target 2.0 asap! I guess it comes down to time and desire. I worry about the UIXNode conversion as I don't yet fully understand that code enough to feel comfortable porting it without missing things. I guess I could create sandbox renderers for the components, then if they look complete, we could promote them replace the UIXNode ones at that time. Is there a WIKI page that I missed that talks about how to convert these guys or about any of the UIXNode architecture? +1
Re: JSF2.0 implementation
Simon, You can do a search for Subject = '[OT] JSF 2.0' on the Dev list. I believe that discussion, begun by MW turned into a discussion about branch creation... then a couple of +1s followed and I assume that's where the branch was born. Cheers, Zubin. On 8/28/08, Simon Kitching [EMAIL PROTECTED] wrote: I see from the commit list that a new JSF2.0 branch has been created. I don't remember seeing *any* kind of discussion or even announcement about this. While I am happy to see JSF2.0 work going on, this kind of approach does not seem to be at all in the community spirit. IMO, major events like this should be discussed beforehand. One issue, for example, is that the core-1.2 stuff is currently half-way-converted from the trinidad plugins to the myfaces-builder-plugin. So now it is branched, any changes need to be applied in two places. In addition, a large amount of code has just been committed by someone (slessard) who is not a particularly regular contributor to myfaces. Where did this code come from? Do we need a code grant for it? Note that when code is developed iteratively on the dev list then there is no need for a grant. But a sudden code dump is different, even when contributed by someone who has signed a CLA. And with 3 branches to now maintain, we need to discuss whether and when we phase out maintenance of the jsf-1.1 branch. Currently when users provide patches in jira, they almost always provide a patch against only one version and the committer ports it, which does increase the load on existing committers. When do we stop asking committers to do this when patching bugs? To repeat, I'm *happy* that jsf2.0 implementation is in progress, and appreciate people contributing time to write an ASF-2.0-licensed implementation. But it is a standard saying at Apache that community is more important than code, and the community aspect here seems to have been rather neglected... Regards, Simon
Re: [VOTE] promoting the exporterActionListener component to Tomahawk
+1 On Sun, Jun 8, 2008 at 4:48 PM, Hazem Saleh [EMAIL PROTECTED] wrote: [1] useful = very useful. On Sun, Jun 8, 2008 at 11:46 PM, Hazem Saleh [EMAIL PROTECTED] wrote: Hi Volker, I promise to do a separated one for commons after finishing my Tomahawk release tasks (Although I don't think that the component will be useful[1] if it depends on JSF APIs only). *A note about the commons project :* I think we should have a clear vision or a draft plan that determines the project objectives, scope and road map. Thanks! On Sun, Jun 8, 2008 at 5:16 PM, Volker Weber [EMAIL PROTECTED] wrote: Hi, Can you create another exporterActionListener to include into comons for non tomahawk users? Or should i copy the pre 664385 svn version to commons? Adding the complete tomahawk.jar just for this one tool is a no go, so its worthless for me. BTW should i add knowledge about the tobago sheet paging and start a vote moving it to tobago? AFAIK the core of exporterActionListener is just based on jsf-api. It is fine to have a version which 'knows' the library specific extensions (t:dataScroller, tc:sheet, tr:table) in the subprojects, but why should we replicate the core exporter sources instead of using/extending the plain jsf-api version from commons? We should start putting useful stuff into commons or this subproject will never grow. Regards, Volker 2008/6/8 Hazem Saleh [EMAIL PROTECTED]: Hi Team, I just finished one of the improvements I intended to develop for the exporterActionListener component : * Integration with the Tomahawk dataScroller, so that it can be allowed for generating the only displayed dataTable page in the exported pdf or excel file. - Example of usage : h:commandButton action= value=Export the current page as a pdf file s:exporterActionListener for=your dataScroller ID fileType=PDF showDisplayedPageOnly=true/ /h:commandButton As we see in the example, the component should know the Tomahawk scroller ID. So I think it is not suitable to include this component in myfaces commons as it uses Tomahawk APIs. Let's resume voting again : Now we have. 3 votes for promoting the component to Tomahawk. 2 votes for not promoting the component to Tomahawk and moving to commons. Thanks all very much! On Fri, Jun 6, 2008 at 6:30 PM, Andrew Robinson [EMAIL PROTECTED] wrote: Isn't Tomahawk already a commons set of components? It works with other render kits, besides some incompatibilities do to the filter design. I am wondering if we are attempting to put too much into commons. My take would be if this is a component that does any rendering it fits well in Tomahawk, but if it is more of a framework feature, then commons would be better. +0 for me though, I don't mind either approach, I'll let others decide. On Fri, Jun 6, 2008 at 6:38 AM, Hazem Saleh [EMAIL PROTECTED] wrote: I have no problem to give non Tomahawk users the ability to use the exporter, but I would like to use the nice Tomahawk features so that the component can be more useful and prettier (Please wait till I show you a near demo about the exporter and you will get my point). On Fri, Jun 6, 2008 at 3:30 PM, Matthias Wessendorf [EMAIL PROTECTED] wrote: On Fri, Jun 6, 2008 at 2:28 PM, Volker Weber [EMAIL PROTECTED] wrote: Hi Hazem, there is no reason why tomahawk should not depends on common-*. If you have a well working UIData content to exel/pdf exporter why don't give non tomahawk users the ability to use it. that were exactly my reasons. even more, the application would require the extra commons-* stuff, when one want the exporter. Regards, Volker 2008/6/6 Hazem Saleh [EMAIL PROTECTED]: Hi Team, I will suspend this vote for now. I will start now implementing some of my future work of this component so that no confusion can be occur. I will be back to this thread after showing you a concrete example. Thanks all very much. On Fri, Jun 6, 2008 at 2:41 PM, Hazem Saleh [EMAIL PROTECTED] wrote: As I said before, This listener will be aware of other Tomahawk components (The current functionality will be extended). BTW, I don't think that I said some thing so funny! On Fri, Jun 6, 2008 at 2:10 PM, Matthias Wessendorf [EMAIL PROTECTED] wrote: On Fri, Jun 6, 2008 at 12:58 PM, Hazem Saleh [EMAIL PROTECTED] wrote: I still totally agree with Leonardo, Iam not seeing that Tomahawk should depend on myfaces-commons to use the exporterListener component. lol there would be no dependency... in an ideal world such a listener is totally independent from the used table (icefaces, tomahawk, standard, ...) So, just add it to the page (inside an actionsource(2)) and refer
Re: [VOTE] promoting the captcha component to Tomahawk
+1 On Thu, Jun 5, 2008 at 8:44 PM, Leonardo Uribe [EMAIL PROTECTED] wrote: +1 On Thu, Jun 5, 2008 at 6:39 PM, Hazem Saleh [EMAIL PROTECTED] wrote: +1 On Thu, Jun 5, 2008 at 11:12 PM, Werner Punz [EMAIL PROTECTED] wrote: +1 Hazem Saleh schrieb: Hi Team, After completing the CAPTCHA documentation. I wish to promote this component to the next Tomahawk release. [+1] for agreeing with promoting the component to the next Tomahawk release. [-1] for disagreeing with promoting the component to the next Tomahawk release. Thanks all very much! -- Hazem Ahmed Saleh Ahmed http://www.jroller.com/page/HazemBlog -- Hazem Ahmed Saleh Ahmed http://www.jroller.com/page/HazemBlog
Re: [VOTE] promoting the captcha component to Tomahawk
+1 On Fri, Jun 6, 2008 at 5:59 AM, Bruno Aranda [EMAIL PROTECTED] wrote: +1 2008/6/6 Zubin Wadia [EMAIL PROTECTED]: +1 On Thu, Jun 5, 2008 at 8:44 PM, Leonardo Uribe [EMAIL PROTECTED] wrote: +1 On Thu, Jun 5, 2008 at 6:39 PM, Hazem Saleh [EMAIL PROTECTED] wrote: +1 On Thu, Jun 5, 2008 at 11:12 PM, Werner Punz [EMAIL PROTECTED] wrote: +1 Hazem Saleh schrieb: Hi Team, After completing the CAPTCHA documentation. I wish to promote this component to the next Tomahawk release. [+1] for agreeing with promoting the component to the next Tomahawk release. [-1] for disagreeing with promoting the component to the next Tomahawk release. Thanks all very much! -- Hazem Ahmed Saleh Ahmed http://www.jroller.com/page/HazemBlog -- Hazem Ahmed Saleh Ahmed http://www.jroller.com/page/HazemBlog
Re: [VOTE] To create a subproject alchemy under MyFaces for the contribution that integrates Adobe Flex components as MyFaces JSF components
That name might be difficult to apply: http://www.captaris.com/alchemy/ Otherwise, welcome! +1. On 5/14/08, Jihoon Kim [EMAIL PROTECTED] wrote: Hi, Since I wanted to have a clear understanding of community's viewpoint of whether the contribution should be part of MyFaces subproject, I am starting this vote. The contribution details are noted within the following JIRA link = https://issues.apache.org/jira/browse/TOMAHAWK-1250 In a nutshell, it is to give users capability in creating Adobe Flex components as MyFaces JSF components. So users would create the components as normal JSF components and the contribution will create the necessary SWF files and etcetera and link the values of the components back to the managed beans using JSON+Javascript and etcetera. In the above discussion Adobe Flex components as MyFaces JSF components, one note that was raised is that Adobe Flash Player is proprietary while Adobe Flex has been open sourced. Personally, since I did see an another project within Apache that did create Adobe PDF and since Adobe Flash Player is ubiquitous; I guess I underplayed the fact that Adobe Flash Player is proprietary. Anyway, thanks to everyone and I will wait to hear the consensus regarding this contribution!!! -- Sincerely, Ji Hoon Kim
Re: Exporter new syntax discussion
-1 On Thu, May 8, 2008 at 2:02 PM, Hazem Saleh [EMAIL PROTECTED] wrote: On Thu, May 8, 2008 at 9:01 PM, Hazem Saleh [EMAIL PROTECTED] wrote: Hi Team, After I started modifying of the Exporter component syntax, * To be like this :** h:commandButton ... s:exporter for=tbl_cars fileType=XLS/ /h:commandButton * Some guys didnot like this new syntax, and they preferred the current one : *s:exporter for=tbl_cars fileType=XLS h:commandButton .../ /s:exporter * I need your input regarding this. (+1) for supporting the new syntax. (-1) for supporting the old syntax. Thanks! -- Hazem Ahmed Saleh Ahmed http://www.jroller.com/page/HazemBlog (-1) for :). -- Hazem Ahmed Saleh Ahmed http://www.jroller.com/page/HazemBlog
Re: The pdfExport component released ;)
https://xhtmlrenderer.dev.java.net/ On Tue, Apr 8, 2008 at 9:44 PM, Martin Marinschek [EMAIL PROTECTED] wrote: Hi Hazem, I have just helped implementing a PDF export in Credit-Suisse (I have to say it is proprietory code, though) - and what we did was using Flying-Saucer. You might want to check it out. regards, Martin On Mon, Apr 7, 2008 at 12:39 PM, Hazem Saleh [EMAIL PROTECTED] wrote: Hi Alexander, I will do these changes as soon as I complete the excel and pdf export integration. Your suggestions are really nice! Thank you! On Mon, Apr 7, 2008 at 9:24 AM, Jesse Alexander (KSFH 323) [EMAIL PROTECTED] wrote: Hi From the sample code it seems that your component will just put the content of one table into the PDF. For the PDF-export it would make sense to also allow - multiple tables - forms - even complete views to be exportable. Would this require a big refactoring to be possible? regards Alexander From: Hazem Saleh [mailto:[EMAIL PROTECTED] Sent: Saturday, April 05, 2008 3:23 AM To: MyFaces Development Subject: The pdfExport component released ;) Hi guys, Iam pleased to tell you that the (PDFExport) component is finished. It works like the (excelExport) component. for example) s:pdfExport for=your table id h:commandButton action= value=Export as PDF/ /s:pdfExport Here is the patch url : https://issues.apache.org/jira/browse/TOMAHAWK-1229 Thanks all :). -- Hazem Ahmed Saleh Ahmed http://www.jroller.com/page/HazemBlog -- Hazem Ahmed Saleh Ahmed http://www.jroller.com/page/HazemBlog -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: New logos for Tobago and Orchestra
I can see what you see but I also see a biology experiment... On 3/27/08, Simon Lessard [EMAIL PROTECTED] wrote: Hmmm, I see it as an orchestra, the solo brown dot being the chief and the others the musicians... ~ Simon On Thu, Mar 27, 2008 at 12:31 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Adonis Raduca schrieb: Hi, We have new logos for Tobago and Orchestra :) Thanks very much Adonis. It certainly is an improvement over what we have now (nothing). But what does the Orchestra one mean? I'm happy to use this one, but if I had a preference, I'd rather see something that has a link to the orchestra name in some way. For example, perhaps two violins, interlocked like the faces in the new myfaces logo? Or a clef symbol in the new myfaces colours, or something like that.. Cheers, Simon
Re: We have a new look for MyFaces website :)
http://ode.apache.org/ - another nice one from the Apache family. On 12/11/07, Cagatay Civici [EMAIL PROTECTED] wrote: Awesome design! yes, but we should really include this all in our maven-based site-build Yes, we shoud indeed On Dec 11, 2007 10:33 PM, Matthias Wessendorf [EMAIL PROTECTED] wrote: yes, but we should really include this all in our maven-based site-build -M On Dec 11, 2007 9:33 PM, Scott O'Bryan [EMAIL PROTECTED] wrote: Cocoons and directory are kind of nice, but I really like the Adonis' look and feel. I think it fits the project well and with consistant branding across all the subprojects, I think it might quickly set a new standard for sites here at Apache... Plus, I like little cartooney logoie things... Scott Andrew Robinson wrote: You must really like cayenne to mention it 2x On Dec 11, 2007 12:10 PM, Catalin Kormos [EMAIL PROTECTED] wrote: How about building an actual Maven theme out of it as a separate module of MyFaces, to keep things nicely separated, reusable and versionable? in the end it needs to build with Maven, and i'm sure it will. Not sure if it's that much unfair :), here are a few open source project from Apache that have a carefully designed website: http://jackrabbit.apache.org/ http://cayenne.apache.org/ http://cocoon.apache.org/ http://cayenne.apache.org/ http://directory.apache.org/ And i'd say, we should include the Apache Software Foundation logo somewhere in the header on the right maybe? regards, Catalin On Dec 11, 2007 8:31 PM, Jesse Alexander (KSFH 323) [EMAIL PROTECTED] wrote: yeah it's almost unfair against other project's sites which are not so good looking... almost sexy grats Adonis -Original Message- From: Andrew Robinson [mailto: [EMAIL PROTECTED] Sent: Tuesday, December 11, 2007 5:38 PM To: MyFaces Development Subject: Re: We have a new look for MyFaces website :) Ah man, why do you want the web site to look nice? Come on it is open source! :) Next thing you will want to have the WIKI looking halfway decent Was this a demo or really working with maven site css changes? -A On Dec 11, 2007 9:14 AM, Adonis Raduca [EMAIL PROTECTED] wrote: Hello, We have a new look for MyFaces website :) This is the first draft, so I look for your opinions :) Have a nice evening ! Adonis -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
Re: [Announce] Release of Apache MyFaces Orchestra 1.0
Well done Mario, Simon Werner... congratulations on the release! Cheers, Zubin. On 10/12/07, Mario Ivankovits [EMAIL PROTECTED] wrote: The Apache MyFaces Orchestra team is pleased to announce the release of Apache MyFaces Orchestra Core 1.0. Apache MyFaces Orchestra is a library which introduce a new scope called conversation scope to your web based application which will help you alot building applications using ORM by avoiding exceptions like LazyInitializationException. Get a full overview at Orchestras homepage [1]. The distribution is available at * http://myfaces.apache.org/orchestra/download.html Apache MyFaces Orchestra is available in the central Maven repository under Group ID org.apache.myfaces.orchestra. Have fun! Ciao, Mario [1] http://myfaces.apache.org/orchestra
Re: Yippeee!
We should have countered on TSS, that's where the FUD damage was done mostly. Good counter regardless. Cheers, Zubin. On 9/15/07, Manfred Geiler [EMAIL PROTECTED] wrote: Well done, Martin. Thanks for taking the time to counter at full length. --Manfred On 9/15/07, Martin Marinschek [EMAIL PROTECTED] wrote: Isn't it nice to read something like this? This blog made my day, see my comments. http://icoloma.blogspot.com/2006/10/myfaces-emperor-has-no-clothes.html regards, Martin
Re: [orchestra] changed scope configuration
Martin, I think that's what is already happening. If nothing is set - the conversation dies with the session. It used to be that it was hard-wired to last 30 mins. If a specific setting is made in the config, then it supercedes the default which = session timeout. Cheers, Zubin On 9/7/07, Martin Marinschek [EMAIL PROTECTED] wrote: Hi Simon, I would suspect the default should be same as session, and that the added value of Orchestra is that a conversation will time out if the session keeps being used, but only these conversation scoped beans are not used anymore. Configuration should be available, and it is good that it is, but my POV is a nice default value would be the session timeout. regards, Martin On 9/8/07, simon [EMAIL PROTECTED] wrote: Hi, Conversations are stored in the session (indirectly). So when the http session times out, the conversations automatically go too. The timeout mentioned here is just in case you want conversations to time out more quickly than the http session. Until recently this shorter timeout was hard-wired to 30 minutes. It is now configurable via the scope declaration in the spring file. And as Mario mentions, if you don't specify a timeout there the default is now *no* timeout (ie timeout only when session goes). I hope that's what you were asking about.. Kito, you might like to look at the new documentation added to the website recently (esp. in core). It's still a work in progress but any feedback on what's there so far would be very welcome.. Regards, Simon On Fri, 2007-09-07 at 23:35 +0200, Martin Marinschek wrote: Hi Mario, why do I have to configure a timeout? Can't the default be taken from the session timeout? regards, Martin On 9/7/07, Kito D. Mann [EMAIL PROTECTED] wrote: Very cool, Mario. FYI, I'll be talking about Orchestra (among other things) at JavaZone next week (http://www4.java.no/web/show.do?page=92articleid=5276). This means I may be asking a lot of questions over the next few days :-). ~~~ Kito D. Mann - Author, JavaServer Faces in Action http://www.virtua.com - JSF/Java EE consulting, training, and mentoring http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info * Sign up for the JSF Central newsletter! http://oi.vresp.com/?fid=ac048d0e17 * -Original Message- From: Mario Ivankovits [mailto:[EMAIL PROTECTED] Sent: Friday, September 07, 2007 11:36 AM To: MyFaces Development Subject: [orchestra] changed scope configuration Hi! Today we cleaned up the way how to configure the different scopes. Basically this means: * you HAVE to configure a timeout now. The default is to never timeout a conversation on its own. * the flash scope is now configured through the lifetime property. Please see here an example or refer to the updated installation documentation (once it has been published which might take some hours) entry key=conversation.normal bean class= org.apache.myfaces.orchestra.conversation.spring.SpringConversat ionScope property name=timeout value=35 / property name=advices list ref bean=persistentContextConversationInterceptor/ /list /property /bean /entry entry key=conversation.flash bean class= org.apache.myfaces.orchestra.conversation.spring.SpringConversat ionScope property name=advices list ref bean=persistentContextConversationInterceptor/ /list /property property name=lifetime value=flash/ /bean /entry Ciao, Mario -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: [jira] Resolved: (TRINIDAD-653) PanelLabelAndMessageRenderer shouldn't need the for given to detect what it is for
On 8/31/07, Andrew Robinson (JIRA) dev@myfaces.apache.org wrote:
[
https://issues.apache.org/jira/browse/TRINIDAD-653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Robinson resolved TRINIDAD-653.
--
Resolution: Fixed
Fix Version/s: 1.0.3-core
Committed revision 571586.
PanelLabelAndMessageRenderer shouldn't need the for given to detect what
it is for
Key: TRINIDAD-653
URL: https://issues.apache.org/jira/browse/TRINIDAD-653
Project: MyFaces Trinidad
Issue Type: Improvement
Affects Versions: 1.0.2-core
Reporter: Andrew Robinson
Assignee: Andrew Robinson
Fix For: 1.0.3-core
Since CorePanelLabelAndMessage will usually be used having the first child
component as the input, the renderer should be able to determine the for
attribute value without it being specified. Here is code that can be used in
the PanelLabelAndMessageRenderer:
@Override
protected String getLabelFor(FacesContext context, RenderingContext arc,
UIComponent component, FacesBean bean)
{
String forValue = getFor(bean);
String val = MessageUtils.getClientIdFor(context, component,
forValue);
if (val == null)
{
if (component.getChildCount() 0)
{
UIComponent firstChild =
(UIComponent)component.getChildren().get(0);
if (firstChild instanceof EditableValueHolder)
{
val = firstChild.getClientId(context);
}
}
}
return val;
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Resolved: (TRINIDAD-653) PanelLabelAndMessageRenderer shouldn't need the for given to detect what it is for
On 8/31/07, Zubin Wadia [EMAIL PROTECTED] wrote:
On 8/31/07, Andrew Robinson (JIRA) dev@myfaces.apache.org wrote:
[
https://issues.apache.org/jira/browse/TRINIDAD-653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Robinson resolved TRINIDAD-653.
--
Resolution: Fixed
Fix Version/s: 1.0.3-core
Committed revision 571586.
PanelLabelAndMessageRenderer shouldn't need the for given to detect
what
it is for
Key: TRINIDAD-653
URL: https://issues.apache.org/jira/browse/TRINIDAD-653
Project: MyFaces Trinidad
Issue Type: Improvement
Affects Versions: 1.0.2-core
Reporter: Andrew Robinson
Assignee: Andrew Robinson
Fix For: 1.0.3-core
Since CorePanelLabelAndMessage will usually be used having the first
child
component as the input, the renderer should be able to determine the for
attribute value without it being specified. Here is code that can be used
in
the PanelLabelAndMessageRenderer:
@Override
protected String getLabelFor(FacesContext context, RenderingContext
arc,
UIComponent component, FacesBean bean)
{
String forValue = getFor(bean);
String val = MessageUtils.getClientIdFor(context, component,
forValue);
if (val == null)
{
if (component.getChildCount() 0)
{
UIComponent firstChild =
(UIComponent)component.getChildren().get(0);
if (firstChild instanceof EditableValueHolder)
{
val = firstChild.getClientId(context);
}
}
}
return val;
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [ANNOUNCE] MyFaces Core 1.2.0 Release
Terrific! Congratulations to everyone involved. Cheers, Zubin. On 7/18/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: The Apache MyFaces team is pleased to announce the release of MyFaces Core 1.2.0. MyFaces Core 1.2.x is a JavaServer(tm) Faces 1.2 implementation as specified by JSR-252. MyFaces Core has passed Sun's JSR-252 TCK and is 100% compliant with the JSR-252 specification. MyFaces Core 1.2.0 is available in both binary and source distributions. * http://myfaces.apache.org/download.html MyFaces Core is also available in the central Maven repository under Group ID org.apache.myfaces.core. Release Notes - MyFaces Core - Version 1.2.0 Sub-task * [MYFACES-1436] - Add element deferred-value/method for elements in the taglibs * [MYFACES-1437] - Implement UIComponentTagUtils to use ValueExpression and MethodExpression * [MYFACES-1440] - Implement method: ApplicationImpl.createComponent(ValueExpression,FacesContext, String) * [MYFACES-1441] - Implement method: ApplicationImpl.getResourceBundle(FacesContext ,String) * [MYFACES-1444] - Change all the html basic tag attributes to ValueExpression * [MYFACES-1453] - Implement JSR-252 core tag: ActionListenerTag * [MYFACES-1454] - Implement JSR-252 core tag: ConvertNumberTag * [MYFACES-1455] - Implement JSR-252 core tag: LoadBundleTag * [MYFACES-1456] - Implement JSR-252 core tag: ParamTag * [MYFACES-1457] - Implement JSR-252 core tag: SelectItemsTag * [MYFACES-1458] - Implement JSR-252 core tag: SubviewTag * [MYFACES-1459] - Implement JSR-252 core tag: ValidateDoubleRangeTag * [MYFACES-1460] - Implement JSR-252 core tag: ValidateLengthTag * [MYFACES-1461] - Implement JSR-252 core tag: ValidateLongRangeTag * [MYFACES-1462] - Implement JSR-252 core tag: ValueChangeListenerTag * [MYFACES-1463] - Implement JSR-252 core tag: VerbatimTag * [MYFACES-1464] - Implement JSR-252 core tag: ViewTag * [MYFACES-1473] - Implement JSR-252 core tag: SelectItemTag * [MYFACES-1475] - ValidatorTag * [MYFACES-1478] - Implement JSR-252 core tag: convertDateTimeTag * [MYFACES-1484] - Implement JSR-252 core tag: phaseListenerTag * [MYFACES-1485] - Implement JSR-252 core tag: FacetTag Bug * [MYFACES-1212] - JSR-252 Issue #21: Provide additional binding attribute for the core Converter, Listener, and Validator tags that would be used as a ValueExpression to alternatively create the instance * [MYFACES-1218] - JSR-252 Issue #45: Avoided concurrent read issues by using a java.util.HashMap instead of java.util.WeakHashMap for a component's Property Descriptor Map * [MYFACES-1331] - Value attribute in f:selectItem is documented as not required, but javax.faces.FacesException: SelectItem with no value is thrown * [MYFACES-1344] - get svn meta data out of impl jar file * [MYFACES-1381] - JSR-252 Issue #303: Clarified the use of encodeChildren with no renderer: render not no-op * [MYFACES-1474] - Fix for ActionListenerTag * [MYFACES-1521] - tag class generator (datatable . setVar()) * [MYFACES-1536] - Resolvers assume that all JSPs produce a FacesContext * [MYFACES-1544] - Verbatim Components are not created during JSP dispatch * [MYFACES-1548] - UIComponent State change if getValueBinding() is called. * [MYFACES-1551] - UIViewRoot.getPhaseListeners() must not be generated * [MYFACES-1557] - MyfacesConfig.getCurrentInstance not thread safe * [MYFACES-1562] - ValueBinding's getType always returns object when trying to converter for class * [MYFACES-1572] - getFirst() and getRows() methods in UIData don't return correct values * [MYFACES-1574] - HtmlOutputLink returns the wrong renderer type * [MYFACES-1575] - MethodBinding.invoke() should provide cause exception * [MYFACES-1576] - PropertyResolver.getType() should check arguments * [MYFACES-1577] - PropertyResolver should throw PropertyNotFoundException * [MYFACES-1579] - VariableResolver throws IllegalStateException because scope is unknown * [MYFACES-1582] - web-facesconfig_1_2.xsd contains restrictive copyright * [MYFACES-1584] - DateTimeConverter contains an extra non-spec field * [MYFACES-1588] - managed beans are not resolved when scope is none * [MYFACES-1592] - cannot render selectBooleanCheckbox tag when a boolean value is supplied * [MYFACES-1593] - javax.el.CompositeELResolver cannot resolve managed beans * [MYFACES-1594] - Passthrough attribute acceptcharset for form not being rendered * [MYFACES-1595] - spec compliance for HtmlCommandButton * [MYFACES-1596] - In an inputText, If the autocomplete attribute is not set or the value is on, render nothing. * [MYFACES-1597] - In inputTextarea, pass thru attributes cols and rows should not be rendered if they are not set * [MYFACES-1598] - JSF 1.2 TLD compliance: attributes binding and converter with wrong deferred-type * [MYFACES-1599] - JSF 1.2 TLD compliance:
Re: [PROPOSAL] MyFaces JSR-252 Version Number (was MyFaces 2.0.0)
+1, great mediation Manfred. Cheers, Zubin. On 5/25/07, Manfred Geiler [EMAIL PROTECTED] wrote: Hi all, I want to get rid of that 1.2 vs. 2.0 discussion blocker. Therefore I will try to summarize all of the arguments and collect the pros and cons once more. The goal is to find a compromise that is acceptable for all of us. I will try to be as impartial as possible. You will see I'm no pigheaded person. Not always at least... ;-) Requisites: R1. Users (esp. non-community members) must be able to find out the implemented spec version (JSR) easily. R2. We must be able to distinguish bugfix releases from feature releases (with changes or extended API). Arguments pro 1.2.x: A12.1. MyFaces 1.2.x is more intuitive and easier to explain to non-community members. A12.2. MyFaces 2.0 for JSF 1.2 and MyFaces 3.0 for JSF 2.0 sounds strange and will confuse people. A12.3. When the JSF 2.0 spec is out in 2008 there will by a MyFaces 2.0.x implementation which will confuse people even more. A12.4. The JSR-252 MyFaces API lib would get the name myfaces-api-2.0.0.jar (!). Mind: This is a new argument pro 1.2.x! ;-) A12.5. MyFaces 1.2 is an incremental improvement over 1.1 that doesn't have giant technology changes in its core. A12.6. Tomahawk/Trinidad/Tobago are no longer tightly-coupled to a specific MyFaces core release, and should use whatever versions make the most sense. A12.7. Free evolution of myfaces-impl is possible, but would come at a cost of incompatibility with the RI. Arguments pro 2.x.y: A20.1. Tomcat does the same. They do not align there container versions to the spec and nobody complains. A20.2. Degree of freedom with minor (x) and fix (y) number. Feature releases with changed or extended API will have a higher minor number. Releases that only fix bugs will only count up the y number. A20.3. Aligning the version numbers of core and component libs within the MyFaces umbrella would be easier. A20.4. MyFaces API can stay with a version number of 1.2, though. A20.5. What do we do when there is a fix to the spec, i.e. JSF-1.2.1 ? A20.6. What do we do when there is a major refactoring of MyFaces, similar to Tomcat 5.0 and 5.5 Ok, here is my compromise proposal, which I hope everyone can live with: C1. We switch MyFaces Core to a 4 digit version numbering: 1.2.0.0 which means major-spec-version.minor-spec-version.minor-impl-version.fix-version C2. We leave the 1.1.5 branch version numbering. Should there ever be the need for doing a fix in that branch (security, copyright issues) we will release a 1.1.6. C3. Non-core libs will no longer be aligned to Core. Which means that Tomahawk/Trinidad/Tobago will always have the freedom to jump to 1.5.0 or 2.0.0 or any appropriate number whenever there are major feature additions or global refactorings. All Requistes accomplished? R1: yes R2: yes Arguments? A12.1. solved A12.2. solved A12.3. solved A12.4. solved A12.5. solved A12.6. solved A12.7. not constricted A20.1. not solved. Well, MyFaces is not Tomcat... A20.2. solved A20.3. not solved, but identified as no longer necessary/desired A20.4. solved A20.5. not solved, but if there is a JSF fix we must join all our influence and convice Ed to call it JSF-1.3 ;-) A20.6. solved, we could switch to 1.2.5.x Somebody mentioned that this issue is the most controversial since a while. Well, I hope this proposal is a good compromise and we/I can start the release procedure next week. Regards, Manfred
Re: MyFaces 2.0.0 (was Re: Tomahawk 1.1.5 release plans?)
There will always be an impedence mismatch here because MyFaces no longer represents the Spec but also various component projects. So I see Manfred/Matze's point. This is why I have always advocated letting the Component initiatives reign alone in terms of their version order, release frequency and alignment with MyFaces and/or the Sun RI. And to think that we have the same exposure as the Tomcat community is pushing it. We are nowhere near as big as them - yet. So while they can start naming their releases after varieties of Hibiscus flowers in the future - we can't. I'm still +1 on 1.2. Cheers, Zubin. On 5/21/07, Bruno Aranda [EMAIL PROTECTED] wrote: +1 for 1.2 -1 for 2.0 I do agree that using 2.0 may cause confusion, as unlike what happens with tomcat, there will be a future version 2.0 of the spec when myfaces 2.0 is there already. People, unaware of the versioning procedure of the myfaces project, will go and fetch this version thinking that it is the implementation of jsf 2.0. Cheers, Bruno On 21/05/07, Mike Kienenberger [EMAIL PROTECTED] wrote: +1 for 1.2. -1 for 2.0. I see no advantage to using major version numbers which differ from the spec. I see the disadvantage of confusion. Also, Manfred, you can have a -1 vote on this issue, but not a veto. Vetos only apply to code changes; they do not apply to procedural issues such as software releases. http://www.apache.org/foundation/glossary.html See also http://mail-archives.apache.org/mod_mbox/incubator-general/200606.mbox/[EMAIL PROTECTED] On 5/18/07, Manfred Geiler [EMAIL PROTECTED] wrote: Hi folks, Like Paul Spencer I'm also still +1 for MyFaces 1.x.y -- JSF 1.1 MyFaces 2.x.y -- JSF 1.2 MyFaces 3.x.y -- JSF 2.0 MyFaces 4.x.y -- JSF whatever comes next Here is my explanation for the why: This one is similar to Tomcat version numbering and I do not remember anyone complaining about having a Tomcat 5.x that is an implementaion of Servlet 2.4 and Tomcat 6.x being a Servlet 2.5 container. If there will be a release vs. spec table on the MyFaces Homepage (like the one on http://tomcat.apache.org/) nobody will ever be confused. The big advantage of having (only) the major number aligned to the spec is the degree of freedom with minor (x) and fix (y) number. It is a well known and successful pattern to have this major.minor.fix version numbering scheme. With the 1.2.x versioning on the other hand, how could we ever differentiate between a minor release (with new features and maybe slightly changed API for non-spec stuff) and a bug fix only release, if we may only count the last number up?! Remember the Tomcat jump from 5.0.x to 5.5.x when they did a complete rewriting of the core stuff? How could they ever have expressed that in version numbering if they had stolidly aligned their tomcat version to the servlet spec 2.4? And do not forget: There is not only the implementation. There are 3 component libs under the MyFaces umbrella. And IMHO it is much more important to align all the myfaces stuff (compatible to each other) within one major number (2.x) than aligning all the stuff to the spec version. For the component libs it is even more important to have that degree of freedom for counting up a minor number whenever there is an API change and let the minor number unchanged for a bug fix release. MyFaces is getting more and more important. Also for tool vendors. So there will be more and more people and stuff out there who/that relies on our APIs. We should be oblivious to this responsibility. Sorry, but this is my binding -1 veto on having 1.2.x for our next spec 1.2 implementation as long as the only reason for having 1.2.x is a cosmetic reason only to help people not being confused. Perhaps I missed something. If so, please explain to me what is a proper technical or organizational or consequential reason for having 1.2.x as version for our next major (sic!) release. Thanks, Manfred On 5/18/07, Kito D. Mann [EMAIL PROTECTED] wrote: +1 for 1.2 -1 for 2.0 Using a 2.0 version is going to confuse people. ~~~ Kito D. Mann - Author, JavaServer Faces in Action http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info * Sign up for the JSF Central newsletter! http://oi.vresp.com/?fid=ac048d0e17 * From: Grant Smith [mailto:[EMAIL PROTECTED] Sent: Friday, May 18, 2007 1:16 PM To: MyFaces Development Subject: Re: MyFaces 2.0.0 (was Re: Tomahawk 1.1.5 release plans?) +1 for 1.2 -1 for 2.0 On 5/18/07, Mathias Brökelmann [EMAIL PROTECTED] wrote: +1 for 1.2 2007/5/18, Matthias Wessendorf [EMAIL PROTECTED] : So, any interest in making this to 2.0.0 ? -Matthias On 2/23/07, Manfred Geiler [EMAIL
Re: MyFaces 2.0.0 (was Re: Tomahawk 1.1.5 release plans?)
It is a discussion about the core - I am only trying to establish WHY there are two schools of thought on this - refer to Manfred's post to this thread on May 18th. Cheers, Z. On 5/21/07, Mike Kienenberger [EMAIL PROTECTED] wrote: I thought we were simply discussing MyFaces Core. Let me clarify my vote: +1 1.2 MyFaces Core for JSF 1.2. -1 2.0 MyFaces Core for JSF 1.2. Don't care for Tomahawk/Trinidad/Tobago. These are no longer tightly-coupled to a specific MyFaces core release, and should use whatever versions make the most sense. This is already true for shared, Trinidad, and Tobago. It's going to happen anyway for Tomahawk once Myfaces 1.2 becomes trunk since Myfaces 1.1 releases are going to be few and far between once the majority of committers have switched to 1.2. While there have been matching releases for Tomahawk and Core up to this point, this has been due to the elimination of the previous coupling between Core and Tomahawk (a process that was more involved and took longer than anyone expected). For tomahawk, my don't care suggestion for versioning would be to use the same version as shared as long as that makes sense. On 5/21/07, Zubin Wadia [EMAIL PROTECTED] wrote: There will always be an impedence mismatch here because MyFaces no longer represents the Spec but also various component projects. So I see Manfred/Matze's point. This is why I have always advocated letting the Component initiatives reign alone in terms of their version order, release frequency and alignment with MyFaces and/or the Sun RI. And to think that we have the same exposure as the Tomcat community is pushing it. We are nowhere near as big as them - yet. So while they can start naming their releases after varieties of Hibiscus flowers in the future - we can't. I'm still +1 on 1.2. Cheers, Zubin. On 5/21/07, Bruno Aranda [EMAIL PROTECTED] wrote: +1 for 1.2 -1 for 2.0 I do agree that using 2.0 may cause confusion, as unlike what happens with tomcat, there will be a future version 2.0 of the spec when myfaces 2.0 is there already. People, unaware of the versioning procedure of the myfaces project, will go and fetch this version thinking that it is the implementation of jsf 2.0. Cheers, Bruno On 21/05/07, Mike Kienenberger [EMAIL PROTECTED] wrote: +1 for 1.2. -1 for 2.0. I see no advantage to using major version numbers which differ from the spec. I see the disadvantage of confusion. Also, Manfred, you can have a -1 vote on this issue, but not a veto. Vetos only apply to code changes; they do not apply to procedural issues such as software releases. http://www.apache.org/foundation/glossary.html See also http://mail-archives.apache.org/mod_mbox/incubator-general/200606.mbox/[EMAIL PROTECTED] On 5/18/07, Manfred Geiler [EMAIL PROTECTED] wrote: Hi folks, Like Paul Spencer I'm also still +1 for MyFaces 1.x.y -- JSF 1.1 MyFaces 2.x.y -- JSF 1.2 MyFaces 3.x.y -- JSF 2.0 MyFaces 4.x.y -- JSF whatever comes next Here is my explanation for the why: This one is similar to Tomcat version numbering and I do not remember anyone complaining about having a Tomcat 5.x that is an implementaion of Servlet 2.4 and Tomcat 6.x being a Servlet 2.5 container. If there will be a release vs. spec table on the MyFaces Homepage (like the one on http://tomcat.apache.org/) nobody will ever be confused. The big advantage of having (only) the major number aligned to the spec is the degree of freedom with minor (x) and fix (y) number. It is a well known and successful pattern to have this major.minor.fix version numbering scheme. With the 1.2.x versioning on the other hand, how could we ever differentiate between a minor release (with new features and maybe slightly changed API for non-spec stuff) and a bug fix only release, if we may only count the last number up?! Remember the Tomcat jump from 5.0.x to 5.5.x when they did a complete rewriting of the core stuff? How could they ever have expressed that in version numbering if they had stolidly aligned their tomcat version to the servlet spec 2.4? And do not forget: There is not only the implementation. There are 3 component libs under the MyFaces umbrella. And IMHO it is much more important to align all the myfaces stuff (compatible to each other) within one major number (2.x) than aligning all the stuff to the spec version. For the component libs it is even more important to have that degree of freedom for counting up a minor number whenever there is an API change and let the minor number unchanged for a bug fix release. MyFaces is getting more and more important. Also for tool vendors. So there will be more and more people and stuff out there who/that relies on our APIs. We should be oblivious to this responsibility
Re: MyFaces 2.0.0 (was Re: Tomahawk 1.1.5 release plans?)
+1 for 1.2. IMO, Save 2.0 for JSF2.0. It's just easier to explain to non-community members that way and keeps it aligned with the spec releases. Cheers, Zubin. On 5/18/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: So, any interest in making this to 2.0.0 ? -Matthias On 2/23/07, Manfred Geiler [EMAIL PROTECTED] wrote: ... I am +1 for Paul's suggestion: JSF 1.1 - MyFaces 1.x JSF 1.2 - MyFaces 2.x and I am +1 for JSF 2.0 (or JSF6 or whatever) - MyFaces 3.x --Manfred
Re: Use 1.2 as current now
Kito, Here are the current unassigned issues as per Martin Haimberger's report to the list previously: MYFACES-1563 - Christoph will do that. MYFACES-1255 - Crosschecked with RI - Only javadoc MYFACES-1264 - Christoph will do that. MYFACES-1253 - Crosschecked with RI - Only javadoc and specification MYFACES-1204 - Martin (me) will check this. MYFACES-1236 - This issues is open. MYFACES-1251 - This issues is open. Needs to be done if the JSF 1.2 implementation is nearly done. MYFACES-1217 - Implemented christoph will recheck this. MYFACES-1200 - This issues is open. Needs to be done if the JSF 1.2 implementation is nearly done. MYFACES-1434 - Martin (me) will do Add element deferred-value/method for elements in the taglibs MYFACES-1444 - patch available MYFACES-1109 - Regarding the comment from Mathias Broekelmann, this is not compatible with the JSF 1.2 specification. Could be done for t:dataTable MYFACES-1548 - patch available MYFACES-1564 - Christoph Ebner will do that. MYFACES-1220 - This issue is open. MYFACES-1221 - Martin (me) will test this with an own renderkit. MYFACES-1230 - Specification Request, someone should recheck this. MYFACES-1582 - patch available MYFACES-1584 - patch available MYFACES-1223 - low priority Cheers, Zubin. On 4/18/07, Kito D. Mann [EMAIL PROTECTED] wrote: Martin, How complete is the work on 1.2? ~~~ Kito D. Mann ([EMAIL PROTECTED]) Author, JavaServer Faces in Action http://www.virtua.com - JSF/Java EE consulting, training, and mentoring http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info -Original Message- From: Martin Marinschek [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 18, 2007 4:07 AM To: MyFaces Development Subject: Use 1.2 as current now Hi *, I wonder if we should switch the trunk to be the 1.2 branch now, cause our next release will surely be fully 1.2 compatible (Tomcat 6 is out now, so the sooner we're done, the better)... We'll have a lot better testing of 1.2 if we do it like this - wdyt? regards, Martin -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: Re: Trinidad, Tomahawk, Tobago, and RCF [Was: [Proposal] RCF, a rich component library for JSF]
I would like two different TLPs: 1. MyFaces Implementation (keeps progressing with the specification's maturity). 2. JSF Component Libraries (whatever their names will be in the future) which work with Sun MyFaces Implementations. Not one. But both. If they only work with MyFaces then there is no need for another TLP. Just like Tomahawk components need to adhere to certain requirements prior to coming out of the sandbox - a promotion criteria should be developed for components under this TLP. I think it will allow the developer community to channel their open source energies better and lead to more commits. Cheers, Zubin. On 3/16/07, Barbalace, Richard [EMAIL PROTECTED] wrote: As someone who mostly just lurks on the dev list, I did want to comment on Werner's post. I would be very interested in component programming, and I have a fair number of ideas for what I think would make useful and interesting components. (Wouldn't it be nice to have a Google Maps component, for instance?) But trying to figure out even how to get started is frustrating. There are all these different projects, with seemingly different purposes, with scattered or poor documentation, and with no single place for getting a top-down overview. Having a nice, clear taxonomy of all the projects and their relationships would be a helpful start, but it would be so much better if there were better integration. I personally would be unlikely to start developing components until that is achieved. Richard J. Barbalace -Original Message- From: Werner Punz [mailto:[EMAIL PROTECTED] Sent: Thursday, March 15, 2007 11:48 AM To: dev@myfaces.apache.org Subject: Re: Trinidad, Tomahawk, Tobago, and RCF [Was: [Proposal] RCF, a rich component library for JSF] . Getting people into component programming is hard, the api is unnecessarily complicated and overloaded with glue code, a common base, could ease tool development as well (we need well documented codegens and uis for helping people to kickstart it). one third is inherent incompatibility problems and one third is questions And the first question you geht, why so many components in the sets double... And then we have Tobago, an excellent framework which feels like being one big block designed for coherency and it has also problems working together with the rest. I think it is long overdue to get a good corebase here and more coherency, since there has to be done some overhaul for jsf 1.2, why not in a proper and decent manner. The information transmitted in this electronic communication is intended only for the person or entity to whom it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this information in error, please contact the Compliance HelpLine at 800-856-1983 and properly dispose of this information.
Re: [VOTE] New Apache MyFaces Fusion Name
[+] Apache MyFaces Orchestra [ ] Apache MyFaces Aurora [ ] Apache MyFaces Connections Although, it really should be called 'Choreo'... coming from the word 'Choreograph'... oh well, too late! Cheers, Zubin. On 3/8/07, Jesse Alexander (KSFD 121) [EMAIL PROTECTED] wrote: [+] Apache MyFaces Orchestra [ ] Apache MyFaces Aurora [ ] Apache MyFaces Connections regards Alexander
Re: MyFaces Fusion Naming
Apache Faces Concerto anyone? Zubin. On 2/27/07, Mario Ivankovits [EMAIL PROTECTED] wrote: What about something completely different: Apache MyFaces Aurora Positive thing, no? Seriously. Ciao, Mario
Re: autogeneration of Comonents, Tags and TDLs
Well done Andreas :), thanks for moving 1.2 along in the right direction!! Cheers, Zubin. On 11/30/06, Andreas Berger [EMAIL PROTECTED] wrote: Hello, I'm proud to announce, that I finished writing the XML files for autogenerating all UI* components + tags and all html components and tags in the 1.2 myfaces branch. Now only the core XMLs need to be done. (I will do it asap) @Bruno: please apply the patches [1] and [2], thx cheers, Andreas [1] http://issues.apache.org/jira/browse/ADFFACES-311 [2] http://issues.apache.org/jira/browse/MYFACES-1444 (XML_NR4.patch)
Re: JSF Client Side JS Framework Written on Top of Dojo Donation
Ole, Good stuff. Let me know if you need a hosting location, we can get that sorted for you and get it out to the community en masse! Zubin. On 11/24/06, Manfred Geiler [EMAIL PROTECTED] wrote: zip it and send it to my address, I'd like to take a look over the weeknd! Do we have a place where we could store this, so that everybody interested can download it? I do not remember how we did it with the ADF donation. Manfred
Re: [EMAIL PROTECTED] Delivery Status Notification (Failure)
Nope, I got it too...On 11/3/06, Dennis Byrne [EMAIL PROTECTED] wrote: Am I the only one getting these after I send a message to either the dev or users list?Dennis Byrne-Original Message-From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]]Sent: Friday, November 3, 2006 11:43 AMTo: [EMAIL PROTECTED]Subject: Delivery Status Notification (Failure) This is an automatically generated Delivery Status Notification.Delivery to the following recipients failed. [EMAIL PROTECTED] Final-Recipient: rfc822;admin@pspindia.comAction: failedStatus: 5.1.1-- Forwarded message --From: Dennis Byrne [EMAIL PROTECTED]To: MyFaces Discussion users@myfaces.apache.orgDate: Fri, 3 Nov 2006 16:33:00 +Subject: [SPAM (Non-existent user)] - Re: Subject: expected a myfaces custom component class in package org.apache.myfaces.custom - Local recipient does not existMatt,HTML_BASIC may be the root of your problem.JsCookMenu is a part of either core JSF tag lib renderers.It is a member of MyFaces extended library.Try removing the render-kit-id element.Also, make sure this configuration file is correctly referenced in the deployment descriptor. Dennis Byrne-Original Message-From: Matt Tyson [mailto:[EMAIL PROTECTED]]Sent: Friday, November 3, 2006 11:20 AMTo: users@myfaces.apache.orgSubject: Subject: expected a myfaces custom component class in package org.apache.myfaces.customTrying to extend the JSCookMenu renderer.I subclassed HtmlJSCookMenuRenderer and added a faces-config entry like this:render-kitrender-kit-idHTML_BASIC/render-kit-id renderercomponent-family javax.faces.Command/component-familyrenderer-typeorg.apache.myfaces.JSCookMenu/renderer-typerenderer-classcom.company.toolbox.jsf.renderer.MyHtmlJSCookMenuRenderer /renderer-class/renderer/render-kitBut I get: expected a myfaces custom component class in packageorg.apache.myfaces.customWhat am I not doing right? Thanks very much.Matt Tyson--View this message in context: http://www.nabble.com/Subject%3A-expected-a-myfaces-custom-component-class-in-package-org.apache.myfaces.custom-tf2568868.html#a7160628Sent from the MyFaces - Users mailing list archive at Nabble.com.
Re: MyFaces with Sun's JSF RI on Websphere5.1
Pallavi,IBM is aware of classloader conflicts with MyFaces on Websphere 5.x - please open a support ticket with them and they will likely have a history of resolutions for it. Cheers,Zubin. On 11/2/06, Arash Rajaeeyan [EMAIL PROTECTED] wrote: 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
Re: Tomcat SNAPSHOT is missing, 1.2 impl cannot be built
It's not official...http://tomcat.apache.org/download-60.cgiOn 10/31/06, Wendy Smoak [EMAIL PROTECTED] wrote:On 10/31/06, Craig McClanahan [EMAIL PROTECTED] wrote: Didn't Tomcat 6.0 just go final?If so, it'd probably be worth updating to the final version number.Not yet... 6.0.0 exists, but the only vote I've seen was on the release plan.I'm working with them to get Tomcat 6 into the centralMaven repo when it's time.--Wendy
Re: Tomcat SNAPSHOT is missing, 1.2 impl cannot be built
Remy,I was just answering Craig's question. Alpha != Final.Cheers,Z.On 10/31/06, Remy Maucherat [EMAIL PROTECTED] wrote:Zubin Wadia wrote: It's not official... http://tomcat.apache.org/download-60.cgiIt's official, but it's an alpha release, which to me is a lot betterthan a random build (it has a svn tag, for starters). At the moment, I am doing some Jasper changes, so it's not a good idea to use a snapshotanyway.Rémy
Re: Jira Probleme
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 :)-MattOn 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/fmywhfurther stuff:blog: http://jroller.com/page/mwessendorfmail: mwessendorf-at-gmail-dot-com
Re: Fwd: JSR-252 TCK
Team(s),Any updates on the 1.2 TCK?Thanks,Zubin.On 10/6/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote:This is utterly inappropriate.Please don't do that.Martin Marinschek wrote: That's good news! So we really need to get Sun up and moving... Ed, can you help us out? regards, Martin On 10/6/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: The license is done - I'm just waiting for the bits to be delivered... Martin Marinschek wrote: Hi Geir, I know that there is not too much of your precious time we can ask for - but is there any chance you could work your magic just like you did for the TCK for JSF, version 1.1, to get us a TCK for JSF version 1.2? When we finally asked you, it went mch faster than before... regards, Martin -- Forwarded message -- From: Bruno Aranda [EMAIL PROTECTED] Date: Oct 6, 2006 12:49 AM Subject: JSR-252 TCK To: MyFaces Development dev@myfaces.apache.org Hi, As the implementation of JSR-252 is progressing, do we have any news of the TCK? Cheers, Bruno-- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: Fwd: JSR-252 TCK
Martin,Just did a blind reply-all - not intentional.Cheers,Z.On 10/16/06, Martin Marinschek [EMAIL PROTECTED] wrote:No, not so far.We'll need for Geir to come up with news. And Zubin, please don't include Ed in the cc for such questions.regards,MartinOn 10/16/06, Zubin Wadia [EMAIL PROTECTED] wrote: Team(s), Any updates on the 1.2 TCK? Thanks, Zubin. On 10/6/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: This is utterly inappropriate.Please don't do that. Martin Marinschek wrote: That's good news! So we really need to get Sun up and moving... Ed, can you help us out? regards, Martin On 10/6/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: The license is done - I'm just waiting for the bits to be delivered... Martin Marinschek wrote:Hi Geir, I know that there is not too much of your precious time we can ask for- but is there any chance you could work your magic just like you didfor the TCK for JSF, version 1.1, to get us a TCK for JSF version 1.2? When we finally asked you, it went mch faster than before... regards, Martin -- Forwarded message --From: Bruno Aranda [EMAIL PROTECTED]Date: Oct 6, 2006 12:49 AM Subject: JSR-252 TCKTo: MyFaces Development dev@myfaces.apache.org Hi, As the implementation of JSR-252 is progressing, do we have any news ofthe TCK? Cheers, Bruno -- http://www.irian.at Your JSF powerhouse -JSF Consulting, Development andCourses in English and German Professional Support for Apache MyFaces --http://www.irian.atYour JSF powerhouse -JSF Consulting, Development andCourses in English and GermanProfessional Support for Apache MyFaces
Re: Fwd: JSR-252 TCK
DoubleM,Have you left Gtalk on somewhere or r u ignoring me?Z.On 10/16/06, Martin Marinschek [EMAIL PROTECTED] wrote:By the way - in private communication with Geir, He's told me that contacting Sun randomly is not appropriate. So if I'll contact Edagain, it won't be in his function as Sun representative.regards,MartinOn 10/6/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: This is utterly inappropriate.Please don't do that. Martin Marinschek wrote: That's good news! So we really need to get Sun up and moving... Ed, can you help us out? regards, Martin On 10/6/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: The license is done - I'm just waiting for the bits to be delivered... Martin Marinschek wrote: Hi Geir, I know that there is not too much of your precious time we can ask for - but is there any chance you could work your magic just like you did for the TCK for JSF, version 1.1, to get us a TCK for JSF version 1.2? When we finally asked you, it went mch faster than before... regards, Martin -- Forwarded message -- From: Bruno Aranda [EMAIL PROTECTED] Date: Oct 6, 2006 12:49 AM Subject: JSR-252 TCK To: MyFaces Development dev@myfaces.apache.org Hi, As the implementation of JSR-252 is progressing, do we have any news of the TCK? Cheers, Bruno -- 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: Tree2
Precisely! Perhaps Werner can chime in some more on this too..Z.On 10/5/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:regarding the ajaxized version, would be cool if the renderer takes care of dojo.rendering out the dojo:widget / things and adding the dojo.jsfile to the *header* of the page. So the widget builds the clienttreee.-MOn 10/5/06, Zubin Wadia [EMAIL PROTECTED] wrote: Right on. I think drag and drop node switching and editing should be part of an AJAXized implementation of the Tree component as that model suits it better. For better scope control perhaps we should have a baseTree and an advancedTree component set? Cheers, Zubin. On 10/5/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: I haven't said that there is no value for that. But I am abit against a super tree component :) Maybe there is value for a specialized editable tree or what ever. I know scenarios where that would be nice. but on the other hand you don't want this overhead when just displaying structured data. I think same is true for an editable table (not a table w/ inputText in it... ;) ) -M On 10/5/06, Zubin Wadia [EMAIL PROTECTED] wrote: Matthias, I think the Tree component can be used in contexts beyond navigation - for example, it can be implemented for Content/Document management where a Category-DocumentType heirarchy needs to be user managed and editable based on their changing business process and the type of content they wish to classify. In the .NET world - this excellent Tree component also supports Node editing for such scenarios: http://www.componentart.com/treeview/features.aspx I believe there is value in the use-case Martin is describing. Cheers, Zubin. On 10/5/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:also why should a tree, used for navigation structure be an editablevalue holder? It just structures data :) 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 validators on 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 thefirst 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 muchsense 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
Re: JSF 1.2 on Java EE 5 Compatible Application Servers
Hi Arash,We'll be testing MyFaces 1.2 on Glassfish - that should be a suitable test-bed. You could join in on the March to 1.2 and submit some patches to JIRA if you'd like! https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truemode=hidepid=10600sorter/order=DESCsorter/field=priorityresolution=-1component=12310871Cheers,Zubin. On 10/4/06, Arash Rajaeeyan [EMAIL PROTECTED] wrote: there are 3 Java EE 5 Compatible Implementations:http://java.sun.com/javaee/overview/compatibility.jsp SAP 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: Tobago and MyFaces
Team,Might as well throw my 2 cents in here - while more developers would help the cause, the root cause of the conflict lies in the fact that one sub-project moved in a relatively non-aligned manner to the rest. This is what needs to change. I don't think making Tobago a top-level ASF project will be the solution. We just need to assess what it would take to shape Tobago into a seamless composition within MyFaces. So let's have that dialogue.There are no developer classes - let's try to be constructive here! Zubin.On 9/13/06, Bernd Bohmann [EMAIL PROTECTED] wrote: Wendy Smoak wrote: On 9/12/06, Craig McClanahan [EMAIL PROTECTED] wrote: 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. There aren't so many active developers that I think we need to be concerned about who has access to what.Rather, there are so few developers working on certain parts of the project that we should be doing everything we can to find *more* of them. :)I would like to see no difference about a Tobago and a MyFacesdeveloper. I don't like the agreement. It looks like a Tobago developer is a second class developer. But we are working on the same thing JSFand JSF Renderkits.RegardsBernd
Re: Tobago and MyFaces
Mike/Volker,I was responding to Bernd feeling like a second-class citizen - that's not true and its not a good feeling to foster. I just want to get this issue out in the open - and sometimes you have to write ambivalently to bring people's feelings into the open. So yay :). If PMC members are not in a position to vote lucidly on a release - then you are correct - it doesn't get the exposure or insight it deserves under MyFaces. Nobody doubts Tomahawk's place or purpose within MyFaces - and we should afford the same respect to Tobago. Z.On 9/13/06, Mike Kienenberger [EMAIL PROTECTED] wrote: On 9/13/06, Zubin Wadia [EMAIL PROTECTED] wrote: Might as well throw my 2 cents in here - while more developers would help the cause, the root cause of the conflict lies in the fact that one sub-project moved in a relatively non-aligned manner to the rest. This is what needs to change. I don't think making Tobago a top-level ASF project will be the solution. We just need to assess what it would take to shape Tobago into a seamless composition within MyFaces. So let's have that dialogue. There are no developer classes - let's try to be constructive here!I think we're all being constructive.Some of us didn't realize that the Tobago folks were being treated differently.I don't agree with your statement that the root cause of the conflictlies in the fact that [Tobago] moved in a relatively non-alignedmanner to the rest -- that was the whole point of Tobago -- to provide layout and theming/skinning. Currently layout management hasnot (and maybe cannot) be done with any other rendering kit involved.If, after discussion, we find that Tobago cannot be made compatible with Tomahawk, making Tobago self-governing is probably the bestsolution since we have two disparate groups working here.If Tobagois incompatible, it's not fair to the Tobago team to be at the mercyof the rest of us. After all, Shale and Tomahawk are similar (probably more so thanTobago and Tomahawk as things stand) and share many of the samecommitters, but no one is suggesting that Shale *must* be a subprojectof MyFaces.
Re: MyFaces ECCN 5D002
Would you like a medal Arash?On 9/2/06, Arash Rajaeeyan [EMAIL PROTECTED] wrote: 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-bits However 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
