Re: [jira] Commented: (MYFACES-214) TabbedPane : wrong validation behavior
Hi Martin,
I was already using the tabbed panel with nested tags
without problems apparently.
What has been the bug fixed regarding this issue?
On 5/22/05, Martin Marinschek <[EMAIL PROTECTED]> wrote:
> Works like a charm, fixes another bug alongside (x:dataTables can
> finally be used on tabbed-panes as well!)
>
> ..and is therefore committed!
>
> Feedback from anyone?
>
> Thanks Philipp for bearing through this lengthy process with me, and
> thanks even more for helping out with this very necessary patch!
>
> regards,
>
> Martin
>
> On 5/22/05, Philipp Ahlner <[EMAIL PROTECTED]> wrote:
> > Über JS habe ich auch mal kurz nachgedacht, aber da sehe ich zwei Probleme:
> >
> > 1. will man das aktivierte Tab abfragen kann man das nicht mehr, weil
> > es bei einer reinen JS-Lösung kein Model-Update gäbe und wenn doch
> > (also das Umschalten mit einem Request verbunden), dann kann man auf
> > JS gleich verzichten und es so machen, wie bisher.
> >
> > 2. Bei einer reinen JS-Lösung müsste man letztendlich doch einen
> > Request losschicken, weil man die EventListener ja benachrichtigen
> > sollte.
> >
> > Und ausserdem finde JS immer Murks, ich vermeide es gerne, wenn ich
> > kann. Ich hoffe es funzt jetzt und kommt evtl. noch in die M10 rein.
> >
> > Grüße aus Leipzig,
> > Philipp
> >
> > 2005/5/22, Martin Marinschek <[EMAIL PROTECTED]>:
> > > Entschuldigung, falsche Formulierung: zusätzlich mit JavaScript machen
> > > (also die Tabs ein/ausblenden nur über JavaScript).
> > >
> > > lg,
> > >
> > > Martin
> > >
> > > On 5/22/05, Martin Marinschek <[EMAIL PROTECTED]> wrote:
> > > > Können wir!
> > > >
> > > > dein neuer Vorschlag gefällt mir sehr gut, das ist genau das, was
> > > > schon einmal auf der Mailingliste diskutiert wurde und keiner jemals
> > > > implementiert hat ;) (also eigentlich wollten die das ursprünglich mit
> > > > JavaScript machen, aber es geht natürlich auch mit CSS.
> > > >
> > > > lg,
> > > >
> > > > Martin
> > > >
> > > > On 5/22/05, Philipp Ahlner <[EMAIL PROTECTED]> wrote:
> > > > > Hi Martin!
> > > > >
> > > > > Can we speak german outside the ML?
> > > > >
> > > > > 2005/5/22, Philipp Ahlner <[EMAIL PROTECTED]>:
> > > > > > Hmm, oh sorry. I see UISelectMany needs a special handling too. The
> > > > > > setting of the submittedValue's need to be more complex. I will
> > > > > > check
> > > > > > all javax.faces.component.UI* classes for all exemptions. But I
> > > > > > don't
> > > > > > know how I can make this generic for implementation of user
> > > > > > components. Dispatching by UI* classes is not save for user
> > > > > > implementations but if I add the values to the parameterMap the
> > > > > > renderer of each component has to do the job. This will be save for
> > > > > > any component without special handling of individual components. I
> > > > > > have not really a test enviroment at home. I'll submit another
> > > > > > improved patch on next week.
> > > > > > Sorry for that.
> > > > > >
> > > > > > Regards,
> > > > > >
> > > > > > Philipp
> > > > > >
> > > > > > 2005/5/21, Martin Marinschek <[EMAIL PROTECTED]>:
> > > > > > > yes, I used that version - that seems to be the problem,
> > > > > > > HtmlSelectBooleanCheckbox expects a boolean value as submitted
> > > > > > > value?
> > > > > > >
> > > > > > > regards,
> > > > > > >
> > > > > > > Martin
> > > > > > >
> > > > > > > On 5/21/05, Philipp Ahlner <[EMAIL PROTECTED]> wrote:
> > > > > > > > Hi!
> > > > > > > >
> > > > > > > > On yesterday I've submitted a improved patch. Did you using the
> > > > > > > > newest
> > > > > > > > version (which calls the corresponding converter to convert the
> > > > > > > > value
> > > > > > > > to a string)??
> > > > > > > >
> > > > > > > > Here is the version again:
> > > > > > > >
> > > > > > > >
> > > > > > > > /**
> > > > > > > > *
> > > > > > > > */
> > > > > > > > package de.interforum.jsf.myfaces.ext.tabbedpane;
> > > > > > > >
> > > > > > > > import java.util.Iterator;
> > > > > > > >
> > > > > > > > import javax.faces.FacesException;
> > > > > > > > import javax.faces.component.UIComponent;
> > > > > > > > import javax.faces.component.UIInput;
> > > > > > > > import javax.faces.context.FacesContext;
> > > > > > > > import javax.faces.convert.Converter;
> > > > > > > >
> > > > > > > > import
> > > > > > > > org.apache.myfaces.custom.tabbedpane.HtmlTabbedPaneRenderer;
> > > > > > > >
> > > > > > > > /**
> > > > > > > > * @author ahlner
> > > > > > > > */
> > > > > > > > public class TabbedPaneRenderer extends HtmlTabbedPaneRenderer
> > > > > > > > {
> > > > > > > >
> > > > > > > >public void decode(FacesContext facesContext, UIComponent
> > > > > > > > uiComponent)
> > > > > > > >{
> > > > > > > >super.decode(facesContext, uiComponent);
> > > > > > > >fakeSubmittedValue(facesContext, uiComponent);
> > > > > > > >}
> > > > > > > >
> > > > > > > >private void fakeSubmittedValue(FacesContext context,
> > > > > > > > UIComponent compo
Re: Google Open Source
Please, count with another huge YES for AJAX ;-) 2005/6/2, Martin Marinschek <[EMAIL PROTECTED]>: > Hey guys & girls, > > have you read about that Google Summer-of-code initiative > (http://code.google.com/summerofcode.html)? > > I have several (exactly 4 students) who would love to take part in > this initiative, so all we would need to have would be 4 small > projects they could finish in 3 months work. > > The good thing: they are all trained (by me ;) in JSF, have worked > with the framework, have written a small project on their own and that > all using MyFaces! > > What do you say? Is there anything we would definitely want to have done? > > I have already added a project: > - implementing the architecture for AJAX-based components, this one > would be important and certainly worth a shot > > Other suggestions: > - Implementing PRETTY_HTML for all renderers, and getting the html to > be "more" valid than today > - Writing server-side-sort/client-side sort implementations for > dataTable and dataList > - Implementing changes for JSF1.2 > > What about your suggestions? Would you be interested in mentoring? > > Projects can be added at: > > http://wiki.apache.org/general/SummerOfCode2005 > > regards, > > Martin >
Re: Demo for AJAX faces componets
Great example using an AJAX-enabled dataTable. This can be really helpfull! I think that Martin's students are also working on something similar... Alexander, could you please post some reviews about your examples, I mean, some kind of explanation of how is it done? Or better a wiki in MyFaces?2005/8/5, Alexandr J. Smirnov <[EMAIL PROTECTED]>: After any little problems, my demo/test application visible from internet.You can see it by :http://smirnov.org.ru/myfaces-ajax/ . At present, it was tested with Firefox 1.06, Microsoft IE 6.0 and 5.0 (from default install of Windows 2000 ) and Opera 8.02I will be very glad for report of success/failure test on other browsers.My skills in _javascript_ less then 1 month, but long time I worked with java, c, c++ - as result, I was surprised many times by unexpected work of anycode...I don't have any problems for server side part, but need any help for buildclient-side scripts... Most in creating portable code for different clients. ???Do you have a demo of this technology up and running?Can you start a discussion with code snippets on the mailing list how youimplemented that?How many changes would it take to get My Faces to use your approach? regards,MartinOn 8/2/05, Alexandr J. Smirnov <[EMAIL PROTECTED]> wrote:I have worked ( as alpha-alpha-alpha .. ) set of custom components forcreate AJAX-like user interfaces for Java Server Faces Applications. Main idea - in faces lifecycle, ve have view tree on server side and DOM tree inclient browser ( at present, saving tree on client side don't used ). Forajax request, client send all user input of current form ( as normal submit request ). Request phases work as usual, but on render responce phase serversend ONLY CHANGED parts of view ( i don't create full compare, but send onlyfo pre-defined parts, or submitted form ). For this I created special AjaxContainer component, wich render it's children ( or part of children )components. List of clientId's for rendered components included in responsefor client-side part of framework.For other cases ( for example, such will work in-page Jabber client ) component can render updated xml in custom Listener, and setresponseComplete to FacesContext.On client side, _javascript_ get list of rendered parts and update page DOMTree.In result, we have two-way communications between client browser and JSF view, and have sync tree's on client and server side. It's work like commondesctop applications.Such arch don't need create special RenderKit or change most ofcomponents - for example, at present, I have only custom tag's-renderers for UICommand ( link & Button ) components, and have worked all standart andmost of custom ( tree2 and any other Myfaces components ) as AJAX ... Onother hand, custom renderers based on usual Html renderers, and work also in non-_javascript_ environment as simple html...For client side script use XMLHttpRequest object, and, if it don't exist,special "_javascript_"HttpRequest. It's worked same as XMLHttpRequest (designed with same properies and methods ), but use other idea. For perform request, It appended to page
Re: [PROPOSAL] New mailing-list announce@myfaces.apache.org
+12005/8/21, Sean Schofield <[EMAIL PROTECTED]>: +1We could also announce new sandbox components and promotion fromsandbox to tomahawk in this manner.seanOn 8/21/05, Martin Marinschek <[EMAIL PROTECTED] > wrote:> Hi *,>> I'd like to propose a new mailing-list for Apache MyFaces:> [EMAIL PROTECTED]. Due to the heavy traffic on our > development and user list many users of our technology refrain from> subscribing to this list; it is a heavy burden even for the MyFaces> committers to read each post on the dev and the users list and we > cannot expect from every user to do the same.>> Still, users should not be left out of important developments in> Apache MyFaces, be it a new release, or fix of a very notorious bug or> development of a new component without having to go to a website to > pull this information for themselves.>> Therefore I'd like to suggest that the new list> [EMAIL PROTECTED] be used for exactly these special > announcements, with a traffic of about one mail per week.>> By the way (I just looked it up): Struts has one of these, too.>> regards,>> Martin>> --> > http://www.irian.at> Your JSF powerhouse -> JSF Trainings in English and German>
Re: [ANNOUNCE] MyFaces passed the JSF TCK 1.1
Congratulations!2005/9/12, Manfred Geiler <[EMAIL PROTECTED]>: The MyFaces team is very proud to announce the fact, that the currentcodebase has just passed *all* JSF TCK 1.1 tests!This is a great milestone (actually the greatest since MyFaces hasstarted in 2003) and we are all looking forward to releasing the first official certified free open source JSF implementation "Apache MyFaces1.1.0" soon (after clarifying some legal and technical stuff).Thanks to every single contributor, who helped making MyFaces another open source success story.. Thank you very much!Let's head for the next challenges: beat ALL bugs :), JSF 1.2, JSF 2.0 , ...Manfred Geiler
Re: dwr
I'm using it and it works like a charm2005/9/13, Arash Bijanzadeh <[EMAIL PROTECTED]>: Hi, I wanted to know if it is possible to use dwr in myfaces. I mean in a matter of licence and quality-- from debian manifesto:Debian Linux is a brand-new kind of Linux distribution. Rather than being developed by one isolated individual or group, as other distributions of Linux have been developed in the past, Debian is being developed openly in the spirit of Linux and GNU.
Is there anybody out there?
Hi, Could you please vote this JIRA issue, so it can be given some priority? It has not even been assigned to anyone :-( http://issues.apache.org/jira/browse/MYFACES-522 Thanks.
Re: [jira] Commented: (MYFACES-522) PreserveDataModel not working (java.lang.IllegalArgumentException: row is unavailable)
Curious...
The thing is I downloaded the last nightly build and I don't get that
error anymore, although the code for the _SerializableDataModel hasn't
been altered...
Please, close this issue as not reproducible and I will reopen it if needed.
Thanks for your support.2005/9/15, Mathias Broekelmann (JIRA) <myfaces-dev@incubator.apache.org>:
[ http://issues.apache.org/jira/browse/MYFACES-522?page=comments#action_12329409 ]Mathias Broekelmann commented on MYFACES-522:
-I´ve tried to reproduce the problem but found everything working with the current nightly.dataModel.setRowIndex(...) only throws an IllegalArgumentException if the given value is less than -1 which is not the case.
Is it possible to post a stacktrace of the Exception you get?> PreserveDataModel not working (java.lang.IllegalArgumentException: row is unavailable)> --
>> Key: MYFACES-522> URL: http://issues.apache.org/jira/browse/MYFACES-522> Project: MyFaces> Type: Bug
> Components: Tomahawk> Versions: Nightly Build> Environment: N/A> Reporter: Enrique Medina Montenegro> Attachments: _SerializableDataModel_Patch.txt>> When setting the preserveDataModel attribute in a dataTable, a new _SerializableDataModel is internally build by MyFaces.
>
However, if the number of rows to display is less than the total number
of possible rows, an IllegalArgumentException is thrown. This problem
is caused by the following bunch of lines in the _SerializableDataModel
constructor (public _SerializableDataModel(int first, int rows,
DataModel dataModel)):>> _list = new ArrayList(rows);> for (int i = 0; i < _rows; i++)> {> dataModel.setRowIndex(_first + i);> if (!dataModel.isRowAvailable()) break;
> _list.add(dataModel.getRowData());> }> _rowIndex = -1;>
As can be clearly seen, first the dataModel.setRowIndex is set,
independently of whether the row is really available or not, as it is
checked after.> The solution would be as simple as swapping the order:> _list = new ArrayList(rows);> for (int i = 0; i < _rows; i++)> {> if (!dataModel.isRowAvailable()) break;
> dataModel.setRowIndex(_first + i);> _list.add(dataModel.getRowData());> }> _rowIndex = -1;--This message is automatically generated by JIRA.
-If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] Release MyFaces 1.1
+12005/9/16, Mathias Brökelmann <[EMAIL PROTECTED]>: +1there are no bugs only features ;)2005/9/16, Korhonen, Kalle <[EMAIL PROTECTED]>:> My +1>> > -Original Message-> > From: Sean Schofield [mailto: [EMAIL PROTECTED]]> > Sent: Thursday, September 15, 2005 9:29 AM> > To: MyFaces Development> > Subject: [VOTE] Release MyFaces 1.1> > > > The release date is scheduled for Monday pending a> > satisfactory release vote.> >> > +1 for me> >>--Mathias
Re: Is there anybody out there?
Ups, sorry, I'll do it right now...2005/9/16, Mathias Brökelmann <[EMAIL PROTECTED]>: Enrique ask me to close this issue since he was not able to reproducethis bug with a latest nightly.2005/9/15, Bill Dudney <[EMAIL PROTECTED]>:> Hi Enrique,> > Have you looked at the comments? Mathias is unable to reproduce the problem> with the nightly build. Any chance you could try a recent nightly?>> TTFN,>> -bd->> > On Sep 15, 2005, at 1:37 AM, Enrique Medina wrote:> Hi,>> Could you please vote this JIRA issue, so it can be given some priority? It> has not even been assigned to anyone :-(> > http://issues.apache.org/jira/browse/MYFACES-522>> Thanks.>>--Mathias
Re: cactus, cargo and testing on myfaces
Yes, a good tutorial on the wiki would be great!2005/9/22, Martin Marinschek <[EMAIL PROTECTED]>: I believe that there is no problem for us in adding any dependenciesas long as they are ASL licensed...If you would write up some stuff on how to get started with testing,it would be great - I hope we can then get the other developers (including me) to write those tests as well.regards,MartinOn 9/22/05, Jesse Alexander (KBSA 21) <[EMAIL PROTECTED]> wrote: > -Original Message-> With the TCK behind us (thanks again to all who worked so hard on> that) I figured it was a good time to work on getting cactus tests in> place. My thinking behind Cactus is that we need to have the ability > to do in container testing because some of the mock stuff is just too> tedious. As background info I've been working on bug # 233 (empty> date for inputCalendar) and its just too complex to test all the > cases with mocks because of the amount of code that must be written> to setup the mock env.> -/Original Message-> Good to hear that. Developing my own components I also have the problems >> of testing. If we all join forces and know how on that, we can come up> with a sample of testing components...>> -Original Message-> So I set out to get a cactus test env that I could execute container > side tests in and I've gotten a fair way there.> -/Original Message-> good to hear>> -Original Message-> The Good:> 1) Cactus gives us an alternative means to test (in the container) > 2) Cargo integration will be a great way to build tests that> automatically invoke the example code on a wide range of containers> with each release. This will help us avoid problems with the various > containers because of a lack of testing.> -/Original Message-> Cool. Maybe I should revive my ant-task for the Yourkit-profiler?> Right now I have a web-app (done with JSF) and a servlet (for use > with JMeter and similar) to control the Yourkit Profiler from distance.> For an old version I once had also an ant-task... but I seem to have> lost that source...>> -Original Message- > The Bad:> 1) more dependencies> 2) we don't seem to have a ground swell of support for testing so> this all might be for nothing> -/Original Message-> Dependencies are only for build and testing? Is that so bad? >> -Original Message-> What are you thoughts? Since introduction of JUnit I've not seen any> additional tests being added to the mix. Its a huge task to get test> coverage but I think its worth it, we will significantly reduce the > uncertainty in doing a release if we can get a good set of tests in> place.> -/Original Message-> JUnit is on e part of the game. But with presentation layer stuff the> incontainer-testing is a must. The applications that depend on Myfaces > may not need it (maybe they also need it...), but the confidence the> incontainer test can give is important for future changes...>> -Original Message-> I'm working on getting some more JUnit tests in place and would love > to write up what is required if that would help others get started.> -/Original Message-> Way cool.>> regards> Alexander>-- http://www.irian.atYour JSF powerhouse -JSF Trainings in English and German
Re: 100.000 Hits a day
Congratulations ;-)2005/9/27, Werner Punz <[EMAIL PROTECTED]>: Martin Marinschek wrote:> Congratulations to the team!>> We have had a 100.000 hits a day first time on Sept 21.>> regards,>> Martin>was there someone load testing ;-) no seriously, congratulations.
Re: Pro JSF and Ajax: it's good
Thanks for your suggestion, Steve, as then it will be worth giving it a read ;-)2006/2/26, [EMAIL PROTECTED] < [EMAIL PROTECTED]>:My copy of Pro JSF and Ajax showed up on Friday, and I sat down to read it this weekend. I had put it on preorder, based only on thecredibility built up by reading the author's posts on JSF.Below is the review I posted on Amazon. I believe that this book willbe on the bookshelf of anyone writing JSF components. Congrats to Jonas and John on a job well done.Steve--The first round of books on JSF were survey books that attempt tocover all of this complex, sophisticated framework. Pro JSF and Ajaxfocuses on one important facet of JSF -- component development -- and does it well.It starts with a quick overview of the major architectural elements ofJSF, and then quickly moves to building custom components in Chapter2. The first component built is a simple date entry component; a second, more sophisticated example is a 'deck' implementation (a deckis a collapsing navigational/browsing UI element).The authors then provide a succinct overview of client side richinternet technologies -- Ajax, XUL (supported by Firefox) and HTC (the DHTML behavior language that is supported by Internet Explorer). Theythen deploy these technologies to build rich client versions of thedate and deck components.The book does a good job of bridging the gap between JSF 1.1 and 1.2implementations; the code in the book targets 1.1, but discusses howimplementation would differ in 1.2.For someone starting out developing in JSF, I'd recommend this book incombination with the strong survey of JSF in JavaServer Faces by Hans Bergsten.
Re: Playing round with 1.5 features
Hi Martin,We have already discussed it directly, but I would like to stress my skepticism about the convenience to go back again to put configuration stuff in code, abandoning XML files.XML configuration files do quite well their job and were designed to avoid coupling parametrization stuff in code. Now it seems we return to the point were we started. It seems more a response to .NET than real desirable functionality, as we already had it with external configuration files. Regards,Enrique Medina.On 3/27/06, Martin Marinschek <[EMAIL PROTECTED]> wrote: Hi *,Sylvain and me want to play around with 1.5 features a little -annotations and whatever there is. Particularly, we want to build a maven-plugin which creates the faces-config.xml (both managed-beansand navigation rules) file automatically from annotations.We considered a new subdirectory under tomahawk and maven-plugins forthis - a directory, which would not be included in the normal build, but which would have to be built separately.The directory under tomahawk might be called sandbox15.Comments - suggestions - alternatives?regards,Martin-- http://www.irian.atYour JSF powerhouse -JSF Consulting, Development andCourses in English and GermanProfessional Support for Apache MyFaces
Re: Playing round with 1.5 features
Yes, Martin, that's the point. I see here another Sun crusade to the use of annotations for everything, as happened with EJBs ;-)It shouldn't be an all-or-nothing solution...On 3/27/06, Martin Marinschek <[EMAIL PROTECTED]> wrote: Well, yes,it's something we can discuss about - but annotations do have somemerits as well.If the configuration is something that will change with the codeitself, it doesn't make much sense to have it externally. In any case, it's possible to use a mixed approach without a problem.regards,MartinOn 3/27/06, Enrique Medina <[EMAIL PROTECTED]> wrote:> Hi Martin, >> We have already discussed it directly, but I would like to stress my> skepticism about the convenience to go back again to put configuration stuff> in code, abandoning XML files.> > XML configuration files do quite well their job and were designed to avoid> coupling parametrization stuff in code. Now it seems we return to the point> were we started. It seems more a response to .NET than real desirable > functionality, as we already had it with external configuration files.>> Regards,> Enrique Medina.>>> On 3/27/06, Martin Marinschek < [EMAIL PROTECTED]> wrote:> > Hi *,> >> > Sylvain and me want to play around with 1.5 features a little -> > annotations and whatever there is. Particularly, we want to build a > > maven-plugin which creates the faces-config.xml (both managed-beans> > and navigation rules) file automatically from annotations.> >> > We considered a new subdirectory under tomahawk and maven-plugins for > > this - a directory, which would not be included in the normal build,> > but which would have to be built separately.> >> > The directory under tomahawk might be called sandbox15. > >> > Comments - suggestions - alternatives?> >> > regards,> >> > Martin> >> > --> >> > http://www.irian.at > >> > Your JSF powerhouse -> > JSF Consulting, Development and> > Courses 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: Playing round with 1.5 features
I think the key point is Martin's comment:"If the configuration is something that will change with the code itself, it doesn't make much sense to have it externally."It makes sense if you use them to generate your Hibernate mappings, because always it's the consequence of a change in the code (added a new field or whatever); or maybe not, e.g. you only want to tune the mapping with some type of cascade or soOn 3/27/06, Dennis Byrne <[EMAIL PROTECTED] > wrote:>XML configuration files do quite well their job and were designed to avoid >coupling parametrization stuff in code. Now it seems we return to the point>were we started. It seems more a response to .NET than real desirable>functionality, as we already had it with external configuration files. I have to agree w/ this 100%, XML still rocks. After doing my latest project w/ EJB3 annotations, I don't see much added value.But the truth is, annotations are very sexy right now. This project isn't lacking in users, but I think this would generate a lot more interest in MyFaces. Dennis Byrne
Re: Summer of Code
Have you also taken a look at Rumba framework?http://www.rumbaframework.orgOn 5/3/06, Alexander Kazachonak
<[EMAIL PROTECTED]> wrote:
Hello. It is not a comlete proposal, but I rather want to know your opinionon the project i'm working on. It is not straight myfaces codebase related,but you seem as most appropriate mentor. I planned to work on it before I
knew that there is SoC. But may be you will convince me of its uselessness.Recently I have been writing application using jsf. The application ismostly CRUD. I think that there is much glue code that can be eliminated.
All that identical CRUD backing beans, forms, dataTables, navigation rules.It is all powerful, but it should be possible to eliminate it until you needsomething not very trivial. This is the principle which the Ruby on Rails
growing popularity came from.There arises a need to define rules of generating it all based oninformation about a data model. Code generation tools are insufficient.Imagine, you have generated all the beans and views, than provided some
changes to some of them and than you want to add small change to thetemplate or, say, add a field to the domain object. Now you are left on yourown to manually change it everywhere it is used.I propose to extend facelets templating abilities to be able to encapsulate
all that routine tasks into templates. See:1) marks any part of view definition as atemplate.2) marks parts of the template as redefinable.
3) redefines redefinable parts during particulartemplate usage. inserts template and if it is being usedinside another template definition it automatically marks redefinable part.
It can contain only tags. Other tags inside it are treated as tagsinside without name property defined.With used during particular template usage you
can insert part of template marked as redefinable.Than we should generalize data CRUD interfaces and provide implementationsfor technologies/contracts we use to implement business layer. I plan to usevery simple and extendable interfaces.
Let's assume thatobject="#{itemsService}" methodName="getLastItem"/>will get the Item object from getLastItem method and set lastItem variable
to Map containing Item object properties as keys and their values as values.Now the dream is to useto create simple edit form.
See how we can create such a template:#{key}:template=".bool">template=".string" name="validator"/>
name="validator"/>template=".object" name="validator">
where for there is a helper TagHandler, which evalutes its body ifvar is of pointed type. It is decided based on user-provided algorithm. Itallows to do such things as automatically providing textarea for long texts
and so.It is not necessary to divide all this functionality to many templates, itcan reside in only one.Now you can, for example, define special validator for itemUrl field oflastItem object:
And for other fields we can add into template default validator, which will
validate them using hibernate validator annotations.Or we can redefine all components used to represent itemUrl property:
#{lastItem.itemUrl} - url of item descriptionOr we can extend or partially redefine map.field template to differentlyhandle some types.Actually, for short it is display only sample. It is not a comprehensive
description of my ideas. We will be able to writemethodName="getActualItems"/>to represent a complete CRUD interface for caveatemptor.hibernate.org datamodel with an ability to drill down to assotiated objects. And you stillhave an ability to partially redefine default templates behavior. I call it
Smart UI. And important point that it does not impose any requirements toyour other view code. You can use it anywhere in facelets pages definitions.And than you can easily scale introducing backing beans, navigation rules or
anything else only when you need it.Feedback is appreciated.--View this message in context: http://www.nabble.com/Summer-of-Code-t1550695.html#a4212272
Sent from the My Faces - Dev forum at Nabble.com.
Re: [VOTE] Release MyFaces Maven 1.0.0
+12006/2/8, Sean Schofield <[EMAIL PROTECTED]>: It appears that ASF policy requires a vote before an official release. We need to "release" the myfaces-maven project ASAP so we can do moremeaningful releases of the implementation and tomahawk. So to be on the safe side lets do an official vote. No releasecandidate has been built. We are voting on the tagged (1_0_0) versionwhich can be built from maven.Sean
Re: [VOTE] Release MyFaces Maven 1.0.0
+1 (non-binding)2006/2/8, Martin Marinschek <[EMAIL PROTECTED]>: Enrique, you should add non-binding to your vote - like this:+1 (non-binding)regards,MartinOn 2/8/06, Enrique Medina <[EMAIL PROTECTED]> wrote: > +1>> 2006/2/8, Sean Schofield <[EMAIL PROTECTED]>:> > It appears that ASF policy requires a vote before an official release.> > We need to "release" the myfaces-maven project ASAP so we can do more > > meaningful releases of the implementation and tomahawk.> >> > So to be on the safe side lets do an official vote. No release> > candidate has been built. We are voting on the tagged (1_0_0) version > > which can be built from maven.> >> > Sean> >>>--http://www.irian.atYour JSF powerhouse -JSF Consulting, Development and Courses in English and GermanProfessional Support for Apache MyFaces
Re: [VOTE] Accept ADF Faces as Candidate for Incubation
+12006/2/15, Bruno Aranda <[EMAIL PROTECTED]>: My +1 too for Candidate status,On 2/15/06, Manfred Geiler <[EMAIL PROTECTED]> wrote:> And here is my> +1 for Candidate status>> Manfred >>> On 2/15/06, Manfred Geiler <[EMAIL PROTECTED]> wrote:> > MyFaces PMC members,> > Please vote for the acceptance of ADF Faces as a candiate for > > Incubation. On positive vote (no binding -1 within 72 hours) I will> > send a proposal for Podling status to the Incubator PMC.> >> > Attached is a snapshot of the proposal. > >> > Regards,> > Manfred Geiler> >> > > > Proposal for ADF Faces, a MyFaces subproject 6 February 2006, The ADF > > Faces Team (contributions by: Adam Winer, awiner at gmail dot com;> > john dot r dot fallows at gmail dot com)> >> > (0) rationale> >> > Apache MyFaces strives to provide an environment where open source > > developers can create new components and contribute them back to the> > community.> >> > The goal of ADF Faces is to provide web application developers with a> > rich set of user interface components based on the ?JavaServer Faces > > specification.> >> > ADF Faces comes with very high quality components, a dialog framework,> > as well as personalization and skinning capabilities. ADF Faces> > features include: file upload support, client-side validation, partial > > rendering of a page (AJAX-style), data tables, hierarchical tables,> > color/date pickers, progress indicators, menu tabs/buttons, wizards,> > internationalization and accessibility. A complete list of the ADF > > Faces components is available (here.) This project starts with more> > than 100 components which have already been documented and thoroughly> > tested.> >> > ADF Faces is a temporary name for this project, what it will be called > > in the future is yet to be determined by the Apache MyFaces community.> > ADF Faces development started in 2001. Initial development took place> > outside the Apache Software Foundation, therefore the ADF Faces team > > and MyFaces are applying for incubation.> >> > (0.1) criteria> >> > Meritocracy:> >> > The ADF Faces project will be consensus-based using the mailing lists > > and completely transparent. Developers will employ Apache conventions,> > such as "+1", when coming to decisions and if necessary voting will> > establish the final 'will' of the community. > >> > Community:> >> > The MyFaces project and the ?JavaServer Faces standard hold great> > promise. A rich set of UI components will significantly accelerate> > their adoption. We strongly believe that ADF Faces will gather > > significant momentum and enough developers to build a vibrant> > community of users and contributors. We look forward to seeing more> > components "blossom" as part of the Apache MyFaces project. > >> > Core Developers:> >> > ADF Faces was developed by five Oracle employees including Adam Winer> > (active member of the ?JavaServer Faces expert group since day one) > > and John Fallows co-author of "Pro JSF and Ajax". Developers have> > filed the Contribution License Agreement. Oracle has also filed the> > Corporate Contribution License Agreement. > >> > Three PMC members from the MyFaces project are currently planning to> > become active ADF Faces developers, others will hopefully follow:> >> > * Matthias Wessendorf > > * Martin Marinschek> > * Bruno Aranda> >> > Alignment:> >> > ADF Faces aligns perfectly with MyFaces and other ASF projects> > utilizing J2EE infrastructure such as Tomcat. Of particular relevance > > are projects such as Geronimo, Apache libraries like Jakarta Taglibs> > and Apache Maven.> >> > (0.2) warning signs> >> > Orphaned products:> > > > Most of the active developers would like to become ADF Faces> > Committers or PMC Members and plan to remain active in the project.> >> > Inexperience with open source:> > > > Most ADF Faces developers have been consuming open source projects> > extensively and participating in open source mailing lists. In fact> > Adam Winer and John Fallows have been actively involved in the Apache > > MyFaces mailing list. Our mentors and the MyFaces team have great> > experience with open source development and ASF and already sharing> > with the ADF Faces team.> >> > Homogenous developers: > >> > We understand full well that development discussions need to take> > place on the public developers list not behind closed doors. Oracle> > will strongly encourage developers across the globe to join the ADF > > Faces community.> >> > Reliance on salaried developers:> >> > Although ADF Faces was built by Oracle developers, initial interest> > from the MyFaces community seems strong. We anticipate several MyFaces > > community members to join the ADF Faces effort which will dilute this> > project's reliance on Oracle developers overtime. Meanwhile, Oracle> > will continue to support the project by dedicating full time > > resources, to ensure a smooth transition into Apache.
[jira] Updated: (MYFACES-155) Add 'escape' attribute to message tags
[ http://issues.apache.org/jira/browse/MYFACES-155?page=history ] Enrique Medina Montenegro updated MYFACES-155: -- Attachment: escape.zip > Add 'escape' attribute to message tags > -- > > Key: MYFACES-155 > URL: http://issues.apache.org/jira/browse/MYFACES-155 > Project: MyFaces > Type: Improvement > Environment: Any > Reporter: Enrique Medina Montenegro > Priority: Trivial > Attachments: escape.zip > > Added a new attribute to both h:message and h:messages tags named 'escape' > fot the possibility to escape HTML code (similar to h:outputText). -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-155) Add 'escape' attribute to message tags
[ http://issues.apache.org/jira/browse/MYFACES-155?page=comments#action_61869 ] Enrique Medina Montenegro commented on MYFACES-155: --- Sorry, the change has been made for x:message and x:messages :-) > Add 'escape' attribute to message tags > -- > > Key: MYFACES-155 > URL: http://issues.apache.org/jira/browse/MYFACES-155 > Project: MyFaces > Type: Improvement > Environment: Any > Reporter: Enrique Medina Montenegro > Priority: Trivial > Attachments: escape.zip > > Added a new attribute to both h:message and h:messages tags named 'escape' > fot the possibility to escape HTML code (similar to h:outputText). -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
[jira] Updated: (MYFACES-155) Add 'escape' attribute to message tags
[ http://issues.apache.org/jira/browse/MYFACES-155?page=history ] Enrique Medina Montenegro updated MYFACES-155: -- Attachment: patch.txt CVS patch > Add 'escape' attribute to message tags > -- > > Key: MYFACES-155 > URL: http://issues.apache.org/jira/browse/MYFACES-155 > Project: MyFaces > Type: Improvement > Environment: Any > Reporter: Enrique Medina Montenegro > Assignee: Matthias Weßendorf > Priority: Trivial > Attachments: escape.zip, patch.txt > > Added a new attribute to both h:message and h:messages tags named 'escape' > fot the possibility to escape HTML code (similar to h:outputText). -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
[jira] Created: (MYFACES-167) x:inputCalendar and conversion/validation errors
x:inputCalendar and conversion/validation errors
Key: MYFACES-167
URL: http://issues.apache.org/jira/browse/MYFACES-167
Project: MyFaces
Type: Bug
Environment: Any
Reporter: Enrique Medina Montenegro
I'm using the MyFaces tag named x:inputCalendar in order to let the
user select a date from a popup calendar or enter it directly. If the
user enters a valid date, everything goes perfect.
The problem comes when the user enters something wrong, for example
letters. The component tries to convert this value to a valid date
(following the pattern, if there is one), and then throws a
ConvertException exception, so the Apply Request Values phase returns
false, and LifeCycle jumps to the render phase.
When rendering, the component is asked to encode itself, so the
following code is executed:
public void encodeEnd(FacesContext facesContext, UIComponent
component) throws IOException
{
RendererUtils.checkParamValidity(facesContext, component,
HtmlInputCalendar.class);
HtmlInputCalendar inputCalendar = (HtmlInputCalendar) component;
Locale currentLocale = facesContext.getViewRoot().getLocale();
Date value = RendererUtils.getDateValue(inputCalendar);
}
As you can see, the last visible line of this code is:
Date value = RendererUtils.getDateValue(inputCalendar);
so it forces the actual value of the inputCalendar to be a date. And
as obviously we come from a conversion error and that means the value
is not a valid date, the RendererUtils.getDateValue(inputCalendar)
throws:
throw new IllegalArgumentException(
"Expected submitted value of type Date for
component : "+
getPathToComponent(component));
so this exception results in a ServletException that brings up the
undesirable "full of Java trace annoying text" page to the user.
I was wondering why the encondeEnd of this component forces the value
to be obtained to be a date, when anything can be entered in a input
text box.
I've been looking at the common h:inputText tag and its component
always uses the RenderUtils.getStringValue method from its encodeEnd
method, so if a conversion/validation error has been detected, it is
presented to the user using the friendly mechanism of a FacesMessage
and the well-known messages tags.
So I think this could be a bug as no validation can be done at all!
--
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
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-167) x:inputCalendar and conversion/validation errors
[
http://issues.apache.org/jira/browse/MYFACES-167?page=comments#action_62378 ]
Enrique Medina Montenegro commented on MYFACES-167:
---
What release is this fix going to be included in?
> x:inputCalendar and conversion/validation errors
>
>
> Key: MYFACES-167
> URL: http://issues.apache.org/jira/browse/MYFACES-167
> Project: MyFaces
> Type: Bug
> Environment: Any
> Reporter: Enrique Medina Montenegro
>
> I'm using the MyFaces tag named x:inputCalendar in order to let the
> user select a date from a popup calendar or enter it directly. If the
> user enters a valid date, everything goes perfect.
> The problem comes when the user enters something wrong, for example
> letters. The component tries to convert this value to a valid date
> (following the pattern, if there is one), and then throws a
> ConvertException exception, so the Apply Request Values phase returns
> false, and LifeCycle jumps to the render phase.
> When rendering, the component is asked to encode itself, so the
> following code is executed:
> public void encodeEnd(FacesContext facesContext, UIComponent
> component) throws IOException
> {
> RendererUtils.checkParamValidity(facesContext, component,
> HtmlInputCalendar.class);
> HtmlInputCalendar inputCalendar = (HtmlInputCalendar) component;
> Locale currentLocale = facesContext.getViewRoot().getLocale();
> Date value = RendererUtils.getDateValue(inputCalendar);
>
> }
> As you can see, the last visible line of this code is:
> Date value = RendererUtils.getDateValue(inputCalendar);
> so it forces the actual value of the inputCalendar to be a date. And
> as obviously we come from a conversion error and that means the value
> is not a valid date, the RendererUtils.getDateValue(inputCalendar)
> throws:
>throw new IllegalArgumentException(
>"Expected submitted value of type Date for
> component : "+
>getPathToComponent(component));
> so this exception results in a ServletException that brings up the
> undesirable "full of Java trace annoying text" page to the user.
> I was wondering why the encondeEnd of this component forces the value
> to be obtained to be a date, when anything can be entered in a input
> text box.
> I've been looking at the common h:inputText tag and its component
> always uses the RenderUtils.getStringValue method from its encodeEnd
> method, so if a conversion/validation error has been detected, it is
> presented to the user using the friendly mechanism of a FacesMessage
> and the well-known messages tags.
> So I think this could be a bug as no validation can be done at all!
--
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
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Created: (MYFACES-403) Use a PhaseListener to reinject FacesMessages lost during a redirection to the JSF context
Use a PhaseListener to reinject FacesMessages lost during a redirection to the JSF context --- Key: MYFACES-403 URL: http://issues.apache.org/jira/browse/MYFACES-403 Project: MyFaces Type: Improvement Components: General Environment: N/A Reporter: Enrique Medina Montenegro Priority: Trivial Attachments: FacesMessageListener.java When using redirection to navigate from one JSF view to another, e.g., to implement the PRG (Post-Redirect-Get) pattern, all the FacesMessage objects are lost, so the destination view is not able to show any messages created from the originating view. The idea is to temporarily save a copy of the messages in a storage that will survive to the redirection, and then reinject those messages to the JSF context before rendering the destination view. Attached I have provided with a simple but effective way to achieve this behaviour. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MYFACES-403) Use a PhaseListener to reinject FacesMessages lost during a redirection to the JSF context
[ http://issues.apache.org/jira/browse/MYFACES-403?page=all ] Enrique Medina Montenegro updated MYFACES-403: -- Attachment: FacesMessageListener.java This listener must be extended in order to provide the mechanisms to get and set the list of messages from a temporary storage, e.g. the HttpSession Then it has to be registered in the faces-config.xml file: com.deltar.taller.web.bean.FacesMessageListener > Use a PhaseListener to reinject FacesMessages lost during a redirection to > the JSF context > -- > > Key: MYFACES-403 > URL: http://issues.apache.org/jira/browse/MYFACES-403 > Project: MyFaces > Type: Improvement > Components: General > Environment: N/A > Reporter: Enrique Medina Montenegro > Priority: Trivial > Attachments: FacesMessageListener.java > > When using redirection to navigate from one JSF view to another, e.g., to > implement the PRG (Post-Redirect-Get) pattern, all the FacesMessage objects > are lost, so the destination view is not able to show any messages created > from the originating view. > The idea is to temporarily save a copy of the messages in a storage that will > survive to the redirection, and then reinject those messages to the JSF > context before rendering the destination view. > Attached I have provided with a simple but effective way to achieve this > behaviour. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-403) Use a PhaseListener to reinject FacesMessages lost during a redirection to the JSF context
[ http://issues.apache.org/jira/browse/MYFACES-403?page=comments#action_12317986 ] Enrique Medina Montenegro commented on MYFACES-403: --- Sorry, but I copy&paste my own FacesMessageListener. It's obvious that you have to register your own extended implementation ;-) > Use a PhaseListener to reinject FacesMessages lost during a redirection to > the JSF context > -- > > Key: MYFACES-403 > URL: http://issues.apache.org/jira/browse/MYFACES-403 > Project: MyFaces > Type: Improvement > Components: General > Environment: N/A > Reporter: Enrique Medina Montenegro > Priority: Trivial > Attachments: FacesMessageListener.java > > When using redirection to navigate from one JSF view to another, e.g., to > implement the PRG (Post-Redirect-Get) pattern, all the FacesMessage objects > are lost, so the destination view is not able to show any messages created > from the originating view. > The idea is to temporarily save a copy of the messages in a storage that will > survive to the redirection, and then reinject those messages to the JSF > context before rendering the destination view. > Attached I have provided with a simple but effective way to achieve this > behaviour. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MYFACES-522) PreserveDataModel not working (java.lang.IllegalArgumentException: row is unavailable)
PreserveDataModel not working (java.lang.IllegalArgumentException: row is
unavailable)
--
Key: MYFACES-522
URL: http://issues.apache.org/jira/browse/MYFACES-522
Project: MyFaces
Type: Bug
Components: Tomahawk
Versions: Nightly Build
Environment: N/A
Reporter: Enrique Medina Montenegro
When setting the preserveDataModel attribute in a dataTable, a new
_SerializableDataModel is internally build by MyFaces.
However, if the number of rows to display is less than the total number of
possible rows, an IllegalArgumentException is thrown. This problem is caused by
the following bunch of lines in the _SerializableDataModel constructor (public
_SerializableDataModel(int first, int rows, DataModel dataModel)):
_list = new ArrayList(rows);
for (int i = 0; i < _rows; i++)
{
dataModel.setRowIndex(_first + i);
if (!dataModel.isRowAvailable()) break;
_list.add(dataModel.getRowData());
}
_rowIndex = -1;
As can be clearly seen, first the dataModel.setRowIndex is set, independently
of whether the row is really available or not, as it is checked after.
The solution would be as simple as swapping the order:
_list = new ArrayList(rows);
for (int i = 0; i < _rows; i++)
{
if (!dataModel.isRowAvailable()) break;
dataModel.setRowIndex(_first + i);
_list.add(dataModel.getRowData());
}
_rowIndex = -1;
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (MYFACES-522) PreserveDataModel not working (java.lang.IllegalArgumentException: row is unavailable)
[ http://issues.apache.org/jira/browse/MYFACES-522?page=all ]
Enrique Medina Montenegro updated MYFACES-522:
--
Attachment: _SerializableDataModel_Patch.txt
> PreserveDataModel not working (java.lang.IllegalArgumentException: row is
> unavailable)
> --
>
> Key: MYFACES-522
> URL: http://issues.apache.org/jira/browse/MYFACES-522
> Project: MyFaces
> Type: Bug
> Components: Tomahawk
> Versions: Nightly Build
> Environment: N/A
> Reporter: Enrique Medina Montenegro
> Attachments: _SerializableDataModel_Patch.txt
>
> When setting the preserveDataModel attribute in a dataTable, a new
> _SerializableDataModel is internally build by MyFaces.
> However, if the number of rows to display is less than the total number of
> possible rows, an IllegalArgumentException is thrown. This problem is caused
> by the following bunch of lines in the _SerializableDataModel constructor
> (public _SerializableDataModel(int first, int rows, DataModel dataModel)):
>
> _list = new ArrayList(rows);
> for (int i = 0; i < _rows; i++)
> {
> dataModel.setRowIndex(_first + i);
> if (!dataModel.isRowAvailable()) break;
> _list.add(dataModel.getRowData());
> }
> _rowIndex = -1;
> As can be clearly seen, first the dataModel.setRowIndex is set, independently
> of whether the row is really available or not, as it is checked after.
> The solution would be as simple as swapping the order:
> _list = new ArrayList(rows);
> for (int i = 0; i < _rows; i++)
> {
> if (!dataModel.isRowAvailable()) break;
> dataModel.setRowIndex(_first + i);
> _list.add(dataModel.getRowData());
> }
> _rowIndex = -1;
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-522) PreserveDataModel not working (java.lang.IllegalArgumentException: row is unavailable)
[
http://issues.apache.org/jira/browse/MYFACES-522?page=comments#action_12329521
]
Enrique Medina Montenegro commented on MYFACES-522:
---
Mathias, please close this issue as it is not reproducing any more...
Thanks.
> PreserveDataModel not working (java.lang.IllegalArgumentException: row is
> unavailable)
> --
>
> Key: MYFACES-522
> URL: http://issues.apache.org/jira/browse/MYFACES-522
> Project: MyFaces
> Type: Bug
> Components: Tomahawk
> Versions: Nightly Build
> Environment: N/A
> Reporter: Enrique Medina Montenegro
> Attachments: _SerializableDataModel_Patch.txt
>
> When setting the preserveDataModel attribute in a dataTable, a new
> _SerializableDataModel is internally build by MyFaces.
> However, if the number of rows to display is less than the total number of
> possible rows, an IllegalArgumentException is thrown. This problem is caused
> by the following bunch of lines in the _SerializableDataModel constructor
> (public _SerializableDataModel(int first, int rows, DataModel dataModel)):
>
> _list = new ArrayList(rows);
> for (int i = 0; i < _rows; i++)
> {
> dataModel.setRowIndex(_first + i);
> if (!dataModel.isRowAvailable()) break;
> _list.add(dataModel.getRowData());
> }
> _rowIndex = -1;
> As can be clearly seen, first the dataModel.setRowIndex is set, independently
> of whether the row is really available or not, as it is checked after.
> The solution would be as simple as swapping the order:
> _list = new ArrayList(rows);
> for (int i = 0; i < _rows; i++)
> {
> if (!dataModel.isRowAvailable()) break;
> dataModel.setRowIndex(_first + i);
> _list.add(dataModel.getRowData());
> }
> _rowIndex = -1;
--
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
