problem with Liferay and Myface portlet integration
Hi all, I am currently developing a JSF project, and my team has decided to integrate it with the Liferay portal using Myfaces portlet. We have had success with getting JSF pages to show on Liferay, but we are having problems with getting the commandButtons to work. I have had a trace through the source and it seems that when the state saving method in web.xml is set to 'server', Myfaces and Liferay keep their own instance of the session variable rather than sharing the same one, and this causes the lifecycle in Myfaces to think that nothing has been done on the page, and so it restores the original page without processing the events. I would be grateful if somebody could tell me whether or not this is a known issue, and if there are any planned fixes or workarounds for this. Best regards, Vincent
[jira] Created: (MYFACES-200) x:dataScroller renders facets twice (sometimes)
x:dataScroller renders facets twice (sometimes) --- Key: MYFACES-200 URL: http://issues.apache.org/jira/browse/MYFACES-200 Project: MyFaces Type: Bug Versions: 1.0.9 beta Environment: Windows XP, Tomcat 5/JBoss 3.2.5 (my environment), in general any environment Reporter: Waldek Piszczewiat Priority: Minor When I use dataScroller tag with facets, i.e like this: sometimes dataScroller renders facets twice (but only links, not a table delimiters). I trace code and I found a method in class HtmlDataScrollerRenderer method renderFacet. The problem is the first line: UIComponent link = getLink(facesContext, scroller, facetComp, facetName); because in method getLink created link with not null child (facetComp). I replaced this line by: // create empty link, without children UIComponent link = getLink(facesContext, scroller, null, facetName); and component works good. I don't know what is a detailed specification of this component (now only first element from facet is rendered), so I don't create diff file. -- 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] Switch to Subversion
The ballot is O Yes, use SVN as it is ASF policy and although it might not be the best revision control system available, I can live with it O No, please wait another few months, because SVN itself is unstable and unusable because of "xy" or I am a committer/contributor and I have no possiblity at all to use SVN on my system XY at the moment. ;-) Anyway, we have a positive result for SVN, so I will prepare a transfer plan for next week. -Manfred On 4/15/05, Oliver Rossmueller <[EMAIL PROTECTED]> wrote: In case to use SVN is ASF policy for new TLPs I don't understand why weare voting on this. The ballot looks likeO Yes, use SVN as it is the best revision control system availableO Yes, use SVN as it is ASF policy to use it So where is the point to have a vote her?OliverSean Schofield wrote:>Oliver,>>One thing you should know is that MyFaces is technically supposed to>be in SVN as a new Apache project. Apparently (according to people on >the @infra list) this is a requirement for all new top level projects.> (I wonder why the incubator is in CVS then?)>>In addition to the fact that we're supposed to be on SVN there are>maintenance advantages for us. Basically it took four weeks to get >Stan Silvert his karma where Manfred could have done it in a single>day. When we finally got @infra to help us we received the lecture>about being on SVN.>>sean>>>On 4/15/05, Thomas Spiegl < [EMAIL PROTECTED]> wrote:+1 switch from CVS to SubversionOn 4/15/05, Bill Dudney < [EMAIL PROTECTED]> wrote:>>> +1 on the switch>>-bd->>On Friday, April 15, 2005, at 07:18AM, Manfred Geiler < [EMAIL PROTECTED]> wrote:>>> IntelliJ users: I'm currently evaluating build #3281 with integrated SVN support. No problem so far.>> Oliver, yes, tool support is better (manifold) for CVS. Not really astonishing keeping the age of CVS in mind. >>> Anyway, the ASF has decided to switch from CVS to SVN and we should not be the blocker, IMHO.>>> Is there a certain tool you have in mind, that has bad or no SVN support by now?>>> >>> -Manfred>On 4/15/05, Oliver Rossmueller <[EMAIL PROTECTED]> wrote:>>While subversion has it's merits -1 from me to switch to subversion at this point in time.We had this discussion a few times in the past and IMHO the mostimportant argument against svn has not changed until today: tool support for subversion is far from what's available for CVS so this switch wouldbe a step back in developer productivity from my POV. And I hate thesestuipid long revision ids subversion uses as I'm not able to memorize them for more than a minute's time ;-)As for source history: as far as I followed the discussions there willbe some moving/renaming of top-level directories in the myfaces module so this can be done on filesystem level in the repository withoutloosing history (same way as we did when migrating the sources fromsourceforge to ASF). This might be not that comfortable as it would be using svn, but it can be done.OliverManfred Geiler wrote: >Final release 1.0.9beta is only a question of hours now. After>publication will be the best time to finally move our repository out>of the incubator.>We have already discussed and voted about the SVN issue, but there are >some new and changed circumstances and I would like to find out if>there are still committers who have serious objection against SVN.>Cons:>- IntelliJ users still do not have integrated SVN support. >Pros:>- SVN is the new repository technology for ASF. At the long term all>Apache projects should have moved to SVN. So it's unwritten common>sense that new top level projects should start with SVN from the >beginning.>- As you know, SVN is able to keep history for renamed and moved files>and dirs. Just now we are discussing some serious structural changes >(subprojects, sandbox, etc.) If we do that now in CVS we would loose>valuable history for many files.>- TortoiseSVN is a powerful alternative for all IntelliJ users in the meantime. >>So here is my definite>+1 for switching from CVS to Subversion>>-Manfred>> >>--Oliver RossmuellerSoftware Engineer and IT-ConsultantHamburg, Germany http://www.rossmueller.com>--Oliver RossmuellerSoftware Engineer and IT-Consultant Hamburg, Germanyhttp://www.rossmueller.com
[jira] Created: (MYFACES-201) Problem with dataScroller and fast forward
Problem with dataScroller and fast forward -- Key: MYFACES-201 URL: http://issues.apache.org/jira/browse/MYFACES-201 Project: MyFaces Type: Bug Versions: 1.0.9 beta Reporter: Emeric Simonneau Hello, This is a part of my JSP : All works fine except in this case : - I have 10 pages of results and the fast-forward value is 5 - The current page is the 6th, - When I click on the fast-forward button, the paginator try to show the 11th page (so an empty page). Regards. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
RE: problem with Liferay and Myface portlet integration
Kito Mann tells me that there is a bug in Liferay that keeps MyFaces portlets from working. I suggest that you contact them about it. If the Liferay folks need help, I’ll be glad to offer any assistance I can with MyFaces portlet integration. Stan Silvert JBoss, Inc. [EMAIL PROTECTED] callto://stansilvert From: Vincent Li [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 19, 2005 11:34 PM To: myfaces-dev@incubator.apache.org Cc: Mishra Tripti; Jackie Liu Subject: problem with Liferay and Myface portlet integration Hi all, I am currently developing a JSF project, and my team has decided to integrate it with the Liferay portal using Myfaces portlet. We have had success with getting JSF pages to show on Liferay, but we are having problems with getting the commandButtons to work. I have had a trace through the source and it seems that when the state saving method in web.xml is set to 'server', Myfaces and Liferay keep their own instance of the session variable rather than sharing the same one, and this causes the lifecycle in Myfaces to think that nothing has been done on the page, and so it restores the original page without processing the events. I would be grateful if somebody could tell me whether or not this is a known issue, and if there are any planned fixes or workarounds for this. Best regards, Vincent
cvs.apache.org problems ?
I'm trying to commit some changes but can't connect to the cvs server. Is anyone having the same problem, or is it just me ? Thanks, Sylvain.
Re: cvs.apache.org problems ?
yes, minotaur is currently down, @infra is workingOn 4/20/05, Sylvain Vieujot <[EMAIL PROTECTED]> wrote: I'm trying to commit some changes but can't connect to the cvs server. Is anyone having the same problem, or is it just me ? Thanks, Sylvain.
Re: cvs.apache.org problems ?
Just checked. I cannot ssh into Minotaur so that is probably it. Also someone on struts-dev reported that they cannot check out the shale repository through subversion. sean On 4/20/05, Sylvain Vieujot <[EMAIL PROTECTED]> wrote: > I'm trying to commit some changes but can't connect to the cvs server. > > Is anyone having the same problem, or is it just me ? > > Thanks, > > Sylvain.
Re: cvs.apache.org problems ?
people.apache.org too -mw- On 4/20/05, Sean Schofield <[EMAIL PROTECTED]> wrote: > Just checked. I cannot ssh into Minotaur so that is probably it. > Also someone on struts-dev reported that they cannot check out the > shale repository through subversion. > > sean > > > On 4/20/05, Sylvain Vieujot <[EMAIL PROTECTED]> wrote: > > I'm trying to commit some changes but can't connect to the cvs server. > > > > Is anyone having the same problem, or is it just me ? > > > > Thanks, > > > > Sylvain. > -- Matthias Wessendorf
Re: cvs.apache.org problems ?
people = cvs = minotaur all the same host 209.237.227.194 ;-)On 4/20/05, Matthias Wessendorf <[EMAIL PROTECTED]> wrote: people.apache.org too-mw-On 4/20/05, Sean Schofield <[EMAIL PROTECTED]> wrote:> Just checked. I cannot ssh into Minotaur so that is probably it. > Also someone on struts-dev reported that they cannot check out the> shale repository through subversion.>> sean>>> On 4/20/05, Sylvain Vieujot < [EMAIL PROTECTED]> wrote:> > I'm trying to commit some changes but can't connect to the cvs server.> >> > Is anyone having the same problem, or is it just me ?> >> > Thanks, > >> > Sylvain.>--Matthias Wessendorf
Re: [vote] Switch to Subversion
+1, Yes, etc. On 4/20/05, Manfred Geiler <[EMAIL PROTECTED]> wrote: The ballot isO Yes, use SVN as it is ASF policy and although it might not be the best revision control system available, I can live with it O No, please wait another few months, because SVN itself is unstable and unusable because of "xy" or I am a committer/contributor and I have no possiblity at all to use SVN on my system XY at the moment. ;-)Anyway, we have a positive result for SVN, so I will prepare a transfer plan for next week. -Manfred On 4/15/05, Oliver Rossmueller <[EMAIL PROTECTED] > wrote: In case to use SVN is ASF policy for new TLPs I don't understand why weare voting on this. The ballot looks like O Yes, use SVN as it is the best revision control system availableO Yes, use SVN as it is ASF policy to use it So where is the point to have a vote her?OliverSean Schofield wrote: >Oliver,>>One thing you should know is that MyFaces is technically supposed to>be in SVN as a new Apache project. Apparently (according to people on >the @infra list) this is a requirement for all new top level projects. > (I wonder why the incubator is in CVS then?)>>In addition to the fact that we're supposed to be on SVN there are>maintenance advantages for us. Basically it took four weeks to get >Stan Silvert his karma where Manfred could have done it in a single >day. When we finally got @infra to help us we received the lecture>about being on SVN.>>sean>>>On 4/15/05, Thomas Spiegl < [EMAIL PROTECTED]> wrote:+1 switch from CVS to SubversionOn 4/15/05, Bill Dudney < [EMAIL PROTECTED]> wrote:>>> +1 on the switch>>-bd->>On Friday, April 15, 2005, at 07:18AM, Manfred Geiler < [EMAIL PROTECTED]> wrote:>>> IntelliJ users: I'm currently evaluating build #3281 with integrated SVN support. No problem so far.>> Oliver, yes, tool support is better (manifold) for CVS. Not really astonishing keeping the age of CVS in mind. >>> Anyway, the ASF has decided to switch from CVS to SVN and we should not be the blocker, IMHO.>>> Is there a certain tool you have in mind, that has bad or no SVN support by now?>>> >>> -Manfred>On 4/15/05, Oliver Rossmueller <[EMAIL PROTECTED] > wrote:>>While subversion has it's merits -1 from me to switch to subversion at this point in time. We had this discussion a few times in the past and IMHO the mostimportant argument against svn has not changed until today: tool support for subversion is far from what's available for CVS so this switch would be a step back in developer productivity from my POV. And I hate thesestuipid long revision ids subversion uses as I'm not able to memorize them for more than a minute's time ;-) As for source history: as far as I followed the discussions there willbe some moving/renaming of top-level directories in the myfaces module so this can be done on filesystem level in the repository without loosing history (same way as we did when migrating the sources fromsourceforge to ASF). This might be not that comfortable as it would be using svn, but it can be done. OliverManfred Geiler wrote:>Final release 1.0.9beta is only a question of hours now. After >publication will be the best time to finally move our repository out>of the incubator.>We have already discussed and voted about the SVN issue, but there are >some new and changed circumstances and I would like to find out if>there are still committers who have serious objection against SVN.>Cons:>- IntelliJ users still do not have integrated SVN support. >Pros:>- SVN is the new repository technology for ASF. At the long term all>Apache projects should have moved to SVN. So it's unwritten common>sense that new top level projects should start with SVN from the >beginning.>- As you know, SVN is able to keep history for renamed and moved files>and dirs. Just now we are discussing some serious structural changes >(subprojects, sandbox, etc.) If we do that now in CVS we would loose>valuable history for many files.>- TortoiseSVN is a powerful alternative for all IntelliJ users in the meantime. >>So here is my definite>+1 for switching from CVS to Subversion>>-Manfred>> >>--Oliver RossmuellerSoftware Engineer and IT-ConsultantHamburg, Germany http://www.rossmueller.com>--Oliver RossmuellerSoftware Engineer and IT-Consultant Hamburg, Germanyhttp://www.rossmueller.com -- -Heath Borders-Wing[EMAIL PROTECTED]
[OT] ADF Dialog Framework
FYI http://www.oracle.com/technology/products/jdev/101/howtos/adfdialog/index.html (was also topic in Duncan Mills's WebLog from GroundSide) also very interestin is Jonas' Blog http://www.orablogs.com/jjacobi/ HTH, Matthias
Re: [OT] ADF Dialog Framework
Matthias Wessendorf wrote: FYI http://www.oracle.com/technology/products/jdev/101/howtos/adfdialog/index.html (was also topic in Duncan Mills's WebLog from GroundSide) also very interestin is Jonas' Blog http://www.orablogs.com/jjacobi/ HTH, Matthias Thanks Matthias. Interesting article and the Blog. I have been working with Shale DialogController and like its clean concept to separate the Jsf standard from extension. But you have to wire your own logic in actionListener. Many more interesting things may come out from its integration with ViewController, Spring and HiveMond works. We all need a solid "process" framework and state engine that compliment BPEL. Hope myfaces Jsf components will play a role in this bigger picture :-). BaTien DBGROUPS
Re: cvs.apache.org problems ?
It seems to be resolved now. Thanks. Sylvain. On Wed, 2005-04-20 at 17:00 +0200, Manfred Geiler wrote: yes, minotaur is currently down, @infra is working On 4/20/05, Sylvain Vieujot <[EMAIL PROTECTED]> wrote: I'm trying to commit some changes but can't connect to the cvs server. Is anyone having the same problem, or is it just me ? Thanks, Sylvain.
[jira] Closed: (MYFACES-194) inputCalendar throws IllegalArguementException when a ConversionException is supposed to be thrown
[ http://issues.apache.org/jira/browse/MYFACES-194?page=all ]
Grant Smith closed MYFACES-194:
---
Resolution: Fixed
Fix Version: Nightly Build
> inputCalendar throws IllegalArguementException when a ConversionException is
> supposed to be thrown
> --
>
> Key: MYFACES-194
> URL: http://issues.apache.org/jira/browse/MYFACES-194
> Project: MyFaces
> Type: Bug
> Versions: 1.0.9 beta
> Environment: All
> Reporter: Rob Decker
> Priority: Critical
> Fix For: Nightly Build
> Attachments: cal_con.patch
>
> If the conversion fails for an inputCalendar the encodeEnd method does not
> check if isValid is true and tries to get a date object to encode:
> Date value = RendererUtils.getDateValue(inputCalendar);
> which throws an IllegalArguementException even though a ConversionException
> was already thrown and a message added.
> This code should check isValid to determine what to encode:
> String svalue;
> if (isValid()) {
> Date value = RendererUtils.getDateValue(inputCalendar);
> svalue = converter.getAsString(value);
> } else {
> svalue = RendererUtils.getStringValue(inputCalendar);
> }
> While this isn't the exact fix a review of the encodeEnd method will make it
> clear that when the calendar is a popup expecting the value to be a valid
> date after a conversion failure already occured is causing this bug.
--
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] Closed: (MYFACES-199) Calendar unnecessarily requests image resources during parsing
[ http://issues.apache.org/jira/browse/MYFACES-199?page=all ] Sylvain Vieujot closed MYFACES-199: --- Resolution: Fixed Fix Version: Nightly Build Fixed. Thanks for the patch. Sylvain. > Calendar unnecessarily requests image resources during parsing > -- > > Key: MYFACES-199 > URL: http://issues.apache.org/jira/browse/MYFACES-199 > Project: MyFaces > Type: Bug > Versions: 1.0.9 beta > Reporter: Kalle Korhonen > Priority: Minor > Fix For: Nightly Build > Attachments: myfaces-popcalendar.patch > > When image objects for the calendar are created in the dom, the src property > was also set, which causes them to be requested when the scripts is parsed. > However, the default path is wrong and four unnecessary requests are made. > The actual path is set later when the actual calendar component is rendered. > I'll add a patch that fixes the problem. -- 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-196) JSCookMenu Children Menus Problem
[ http://issues.apache.org/jira/browse/MYFACES-196?page=all ]
Martin Bosak updated MYFACES-196:
-
Attachment: myfaces-196.diff
Attached is a patch to fix this.
I also re-worked the code to eliminate generating an ArrayIndexOutOfBounds
Exception. (It's more efficient to avoid the creation of unnecessary
Exceptions if possible).
> JSCookMenu Children Menus Problem
> -
>
> Key: MYFACES-196
> URL: http://issues.apache.org/jira/browse/MYFACES-196
> Project: MyFaces
> Type: Bug
> Versions: 1.0.9 beta
> Environment: MyFaces 1.0.9, Windows XP SP1, Tomcat 5.5
> Reporter: Rogerio Saulo
> Priority: Critical
> Attachments: myfaces-196.diff
>
> I have upgraded to MyFaces 1.0.9 (Was in the 1.0.7) and the JSCookMenu dos
> not work anymore.
> My children menus does not appear on the menu, I have installed the
> MyFacesExamples and the last menu "Info" does not work too. Only the top
> level menus appear.
>
> Here is My code :
>
> JSP :
>
>
>
>
> MenuBean :
> public String getMenus() {
> NavigationMenuItem menu[] = new NavigationMenuItem[1];
> menu[0] = new NavigationMenuItem("Rogerio", null, null, true);
> NavigationMenuItem items[] = new NavigationMenuItem[2];
> menu[0].setNavigationMenuItems(items);
> items[0] = new NavigationMenuItem("Rogerio Filho 1", "go_contact",
> null, false);
> items[1] = new NavigationMenuItem("Rogerio Filho 2", "go_copyright",
> null, false);
> return menu;
> }
> Rogerio
--
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
Suggestion for Version history in a Class or Interface documentation
Hi, Would it be possible to end the entries in the version history that is part of a Class or Interface documentation with a HTML tag? This would ensure the history is readable in the generated JavaDocs. As it is now, every entry is 'scrunched' together (because browsers compress whitespace); which makes the history nearly impossible to read. Just a suggestion. Thanks, Marty
[jira] Commented: (MYFACES-197) TLDDocs Index page only has WAP tags
[ http://issues.apache.org/jira/browse/MYFACES-197?page=comments#action_63360 ] Martin Bosak commented on MYFACES-197: -- I have managed to get TLDDOC to include the "x" tags along with the WAP tags in the alltags-frame.html file. I simply removed the xmlns attribute from the root element in the myfaces_ext.tld file before I ran it thru tlddoc. I'm not sure I can explain what was going on; but it worked. (BTW, is it valid to specify an xmlns attribute in a document that has a TLDDocs Index page only has WAP tags > > > Key: MYFACES-197 > URL: http://issues.apache.org/jira/browse/MYFACES-197 > Project: MyFaces > Type: Bug > Versions: 1.0.9 beta > Environment: Any > Reporter: Martin Bosak > Priority: Minor > > The index page of the 1.0.9m9 release only contains links for the WAP tags. > The individual extension tag documentation files are physically in the > tlddocs\x directory; but are missing from the tlddocs\index.html page. -- 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
