[jira] Commented: (MYFACES-1664) JSR-301 Implementation
[ https://issues.apache.org/jira/browse/MYFACES-1664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12524286 ] Wendy Smoak commented on MYFACES-1664: -- Scott, can you please supply a md5 checksum for the zip file? It's one of the things needed on the IP clearance form. JSR-301 Implementation -- Key: MYFACES-1664 URL: https://issues.apache.org/jira/browse/MYFACES-1664 Project: MyFaces Core Issue Type: New Feature Components: Portlet_Support Affects Versions: 1.2.0-SNAPSHOT Environment: JSR-168, JSF 1.2 Reporter: Scott O'Bryan Attachments: jsf-portlet-bridge.zip MyFaces 1.2 does not currently have a JSR-301 subproject. Work should begin on JSR-301 as bridge support for the MyFaces 1.2 branch. Trinidad is currently dependant on this project for bridge support and other Renderkits may wish to use this standards based bridge as well. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TOMAHAWK-864) Sorting by locale in FacesContext for strings (SortableModel)
[ https://issues.apache.org/jira/browse/TOMAHAWK-864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12466249 ] Wendy Smoak commented on TOMAHAWK-864: -- Catalin, is this commit related? URL: http://svn.apache.org/viewvc?view=revrev=498122 Sorting by locale in FacesContext for strings (SortableModel) - Key: TOMAHAWK-864 URL: https://issues.apache.org/jira/browse/TOMAHAWK-864 Project: MyFaces Tomahawk Issue Type: New Feature Components: Extended Datatable Affects Versions: 1.1.3, 1.1.4-SNAPSHOT, 1.1.5-SNAPSHOT Reporter: Tomislav Jakopec Assigned To: Catalin Kormos Priority: Trivial Fix For: 1.1.5-SNAPSHOT I have small problem and I don't now how to handle. So far I write my own Comparator in witch I sorted according to Collator with locale form FacesContext Collator collator = Collator.getInstance( FacesContext.getCurrentInstance().getViewRoot().getLocale()); My sort order was fine, Croatian letters where sorted alphabet. Now there is possibility to tel whole datatable sortable=true and I don't have to write commandSortHeader tag. Problem: sort is alphabet in english language, not croatian and FacesContext.getCurrentInstance().getViewRoot().getLocale() is croatian The solution: If you look in the org.apache.myfaces.component.html.ext.SortableModel (inner class Comp), the default comparator that is used to sort the values in a given column, will compare the values as Comparable if they implement that interface, if not it will compare them as simple strings, obtained by toString(). This makes me think that the usage of the Collator class to compare those strings would do it, thanks for pointing that out, btw. It would be great if you could open a Jira issue for this, and even greater, if possible, to provide a patch, it would be of great help having this resolved faster. Regards, Catalin -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (TOMAHAWK-864) Sorting by locale in FacesContext for strings (SortableModel)
[ https://issues.apache.org/jira/browse/TOMAHAWK-864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12466252 ] Wendy Smoak commented on TOMAHAWK-864: -- Yes, please. :) Both a description of the commit and the issue key would be great. That cross links things, so research is easier whether you're going from svn logs to JIRA, or the other way around. Thanks! Sorting by locale in FacesContext for strings (SortableModel) - Key: TOMAHAWK-864 URL: https://issues.apache.org/jira/browse/TOMAHAWK-864 Project: MyFaces Tomahawk Issue Type: New Feature Components: Extended Datatable Affects Versions: 1.1.3, 1.1.4-SNAPSHOT, 1.1.5-SNAPSHOT Reporter: Tomislav Jakopec Assigned To: Catalin Kormos Priority: Trivial Fix For: 1.1.5-SNAPSHOT I have small problem and I don't now how to handle. So far I write my own Comparator in witch I sorted according to Collator with locale form FacesContext Collator collator = Collator.getInstance( FacesContext.getCurrentInstance().getViewRoot().getLocale()); My sort order was fine, Croatian letters where sorted alphabet. Now there is possibility to tel whole datatable sortable=true and I don't have to write commandSortHeader tag. Problem: sort is alphabet in english language, not croatian and FacesContext.getCurrentInstance().getViewRoot().getLocale() is croatian The solution: If you look in the org.apache.myfaces.component.html.ext.SortableModel (inner class Comp), the default comparator that is used to sort the values in a given column, will compare the values as Comparable if they implement that interface, if not it will compare them as simple strings, obtained by toString(). This makes me think that the usage of the Collator class to compare those strings would do it, thanks for pointing that out, btw. It would be great if you could open a Jira issue for this, and even greater, if possible, to provide a patch, it would be of great help having this resolved faster. Regards, Catalin -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-660) (Patch provided) request scoping from Portlet Action- to RenderRequest should not occur via Attribute Request Map
[ https://issues.apache.org/jira/browse/MYFACES-660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12463454 ] Wendy Smoak commented on MYFACES-660: - http://svn.apache.org/viewvc?view=revrev=477350 (Patch provided) request scoping from Portlet Action- to RenderRequest should not occur via Attribute Request Map --- Key: MYFACES-660 URL: https://issues.apache.org/jira/browse/MYFACES-660 Project: MyFaces Core Issue Type: Bug Components: Portlet_Support Affects Versions: 1.1.2-SNAPSHOT Environment: myfaces-api + myfaces-impl (rev. 292564) , pluto-1.0.1-rc4 (binary bundle), Liferay 3.6.1 Enterprise, jdk1.5.0_03-b07 Reporter: Tanju Erinmez Assigned To: Stan Silvert Fix For: 1.1.5-SNAPSHOT Attachments: myfaces-impl-src-java.diff, navdemo2.war Hi, After pulling my hair out (and getting a transplant :) I think there is a refined spec vs. current implementation clash [1]. I have looked into this and come up with a possible solution [2]. After having also discussed MYFACES-549 with Brian Chan from Liferay [3] I think you can hit two birds with one stone with the provided patch and get Liferay BEA platform support for free ;-)). Cheers, Tanju 1. Details -- There has been a refinement to the JSR 168 Spec PLT.11.1.3 recently which now clearly indicates that it cannot be assumed that attributes from an ActionRequest will be available in a RenderRequest (see http://jcp.org/aboutJava/communityprocess/maintenance/jsr168/Portlet1.0-ERRATA.html#issue10). On the other hand, it is a legitimate need for JSF to carry over results (e.g. Request scoped managed beans) from the lifecycle execution part (ActionRequest) over to the render part (RenderRequest). AFAIK, there is no special treatment of this case, which means JSF just populates and fetches from the attribute map assuming a standard servlet request behavior. Instead of interfering with this already for servlet mode working behavior I have come up with a special Request Map treatment approach. However, I'm not sure which of the following processing model the design of the portlet integration follows and would be glad if some light could be shed on this: 1. Portlet X receives an ActionRequest and later a RenderRequest this two Requests make up the entire faces lifecycle. Portlet Y from the same PortletContext just receives an ordinary RenderRequest without knowing of any previous ActionRequests 2. Same as above but Portlet Y is aware of the ActionRequest e.g. somehow Interportlet communication shall be achieved in the future 2. Solution - After rolling the dice, I have decided to go with the first approach. The idea is to use a separate map stored in the PortletSession to mimic a request map which spans over two requests (Action RenderRequest). This map is removed from the PortletSession after the render cycle is concluded. I have tested this approach with two simple portlets each containing 3 jsp pages embedding a t:saveState binding to the same managed request scoped bean. I could verify on pluto as well as Liferay that this bean was created only once and its value is preserved despite changing pages in the same portlet. (I merely used saveState as a lazy way to check for request leaking - it will not work for multiple portlet with the intention to have several conversations in parallel). However, what puzzles me right now is that without the patch the standard behavior on pluto is that the bean is created everytime. This indicates that the ActionRequest attribute map is not inherited to the RenderRequest (is ok according to PLT.11.1.3) which would actually mean that request scoped beans haven' worked up to now which I cannot believe. So this is speculative as I have not verified this yet. 3. Liferay et al. MYFACES-549 is somewhat different to the case above because it revolves around the problem that the attribute map from one RenderRequests is visible to another RenderRequests (also governed by PLT.11.1.3) I have had a very brief discussion with Brian Chan from Liferay (see http://support.liferay.com/browse/LEP-287) and apparently it's not only them who interpret PLT.11.1.3 differently but also BEA. They don't see it as a must to confine the attribute maps to the respective request but rather inherit it accross subsequent requests. I have asked Brian to take this issue to the 168 EG and get another errata out whether strict isolation is required or inheritance permitted. I think for myfaces to run on Liferay presumably BEA in the forseable future :) it is important to clean up the attribute
[jira] Commented: (MYFACES-1481) MyFacesGenericPortlet does not work in a cluster
[ https://issues.apache.org/jira/browse/MYFACES-1481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462620 ] Wendy Smoak commented on MYFACES-1481: -- http://svn.apache.org/viewvc?view=revrev=473527 http://svn.apache.org/viewvc?view=revrev=473555 http://svn.apache.org/viewvc?view=revrev=485877 MyFacesGenericPortlet does not work in a cluster Key: MYFACES-1481 URL: https://issues.apache.org/jira/browse/MYFACES-1481 Project: MyFaces Core Issue Type: Bug Reporter: John Gilbert Assigned To: Stan Silvert The problem is that ServletFacesContextImpl is not serializable and processAction places one in the session. Here is a link to a discussion on the JBoss Forum. http://jboss.org/index.html?module=bbop=viewtopicp=3981103#3981103 Here is a link to the workaround I created. http://taylor.cvs.sourceforge.net/taylor/taylor/commons/src/main/java/net/taylor/portlet/MyFacesGenericPortlet.java?view=markup -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-1424) Incorrect source repository commands
[ http://issues.apache.org/jira/browse/MYFACES-1424?page=comments#action_12459992 ] Wendy Smoak commented on MYFACES-1424: -- The website is a separate module, so its scm url points to the source code for the website itself. We can add a src/site/apt/source-repository.apt to override the page generated by Maven, with links to the pages for the various modules and the instructions on how to build it (which I think are on the wiki.) Incorrect source repository commands Key: MYFACES-1424 URL: http://issues.apache.org/jira/browse/MYFACES-1424 Project: MyFaces Core Issue Type: Bug Components: website Reporter: Popcorn Priority: Critical On the website on the page http://myfaces.apache.org/source-repository.html, the source repository commands have the following URL: http://svn.apache.org/repos/asf/myfaces/site/trunk This doesn't point to the MyFaces source code. It needs to be fixed. I cannot figure out which path I should get source from for the current release. For example it says: The source can be checked out anonymously from SVN with this command: $ svn checkout http://svn.apache.org/repos/asf/myfaces/site/trunk myfaces -- 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-1488) ASF Source Header and Copyright Notice Policy
[ http://issues.apache.org/jira/browse/MYFACES-1488?page=comments#action_12450766 ] Wendy Smoak commented on MYFACES-1488: -- If it was developed at or contributed to the ASF, yes, it should have a license header. (Third party works get mentioned in the NOTICE file, but I imagine that's more of an issue in Tomahawk.) I'm not set up to run RAT yet, can you post the output somewhere so I can take a look? ASF Source Header and Copyright Notice Policy - Key: MYFACES-1488 URL: http://issues.apache.org/jira/browse/MYFACES-1488 Project: MyFaces Core Issue Type: Improvement Reporter: Wendy Smoak Assigned To: Grant Smith Priority: Blocker Fix For: 1.1.5-SNAPSHOT Attachments: shared-core.patch All the ASF License headers in the source files need to be updated to remove the copyright notice as per the new policy: http://www.apache.org/legal/src-headers.html We could also run Robert Burrell Donkin's RAT (release audit tool) to see if anything else is missing http://code.google.com/p/arat/ -- 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-1488) ASF Source Header and Copyright Notice Policy
[ http://issues.apache.org/jira/browse/MYFACES-1488?page=comments#action_12448556 ] Wendy Smoak commented on MYFACES-1488: -- There is already a build-tools module with a checkstyle config file: http://svn.apache.org/repos/asf/myfaces/maven/trunk/build-tools/src/main/resources/org/apache/myfaces/checkstyle.xml The RegExp header there can be modified to match the new header. However, it doesn't look like the Checkstyle report is enabled. http://myfaces.apache.org/impl/project-reports.html ASF Source Header and Copyright Notice Policy - Key: MYFACES-1488 URL: http://issues.apache.org/jira/browse/MYFACES-1488 Project: MyFaces Core Issue Type: Improvement Reporter: Wendy Smoak Assigned To: Grant Smith Priority: Blocker Fix For: 1.1.5-SNAPSHOT Attachments: shared-core.patch All the ASF License headers in the source files need to be updated to remove the copyright notice as per the new policy: http://www.apache.org/legal/src-headers.html We could also run Robert Burrell Donkin's RAT (release audit tool) to see if anything else is missing http://code.google.com/p/arat/ -- 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-1406) Core and Shared project has dependency on myfaces:myfaces-api version 1.1.1
[ http://issues.apache.org/jira/browse/MYFACES-1406?page=all ] Wendy Smoak updated MYFACES-1406: - Status: Resolved (was: Patch Available) Resolution: Fixed Updated dependencies to 1.1.4 which has the same groupId as the current snapshot. http://svn.apache.org/viewvc?view=revrev=473177 http://svn.apache.org/viewvc?view=revrev=473179 http://svn.apache.org/viewvc?view=revrev=473180 Core and Shared project has dependency on myfaces:myfaces-api version 1.1.1 --- Key: MYFACES-1406 URL: http://issues.apache.org/jira/browse/MYFACES-1406 Project: MyFaces Core Issue Type: Bug Components: build process Affects Versions: 1.1.5-SNAPSHOT Reporter: Paul Spencer Assigned To: Wendy Smoak Fix For: 1.1.5-SNAPSHOT Attachments: patch-to-core.txt, patch-to-shared.txt Core and Shared project has dependency on myfaces:myfaces-api version 1.1.1. Their are 2 problems here: 1) The dependency group is myfaces instead of org.apache.myfaces.core 2) The version number is wrong. In many places this problem is minimized by the fact that the depenency is marked as provided. I notices the problem why using eclipse. Eclipse was trying to use the 1.1.1 version of the API even though I was working with the 1.1.5-SNAPSHOT . -- 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-1488) ASF Source Header and Copyright Notice Policy
ASF Source Header and Copyright Notice Policy - Key: MYFACES-1488 URL: http://issues.apache.org/jira/browse/MYFACES-1488 Project: MyFaces Core Issue Type: Improvement Reporter: Wendy Smoak Priority: Blocker Fix For: 1.1.5-SNAPSHOT All the ASF License headers in the source files need to be updated to remove the copyright notice as per the new policy: http://www.apache.org/legal/src-headers.html We could also run Robert Burrell Donkin's RAT (release audit tool) to see if anything else is missing http://code.google.com/p/arat/ -- 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: (TOMAHAWK-767) ASF Source Header and Copyright Notice Policy
ASF Source Header and Copyright Notice Policy - Key: TOMAHAWK-767 URL: http://issues.apache.org/jira/browse/TOMAHAWK-767 Project: MyFaces Tomahawk Issue Type: Improvement Reporter: Wendy Smoak Priority: Blocker Fix For: 1.1.4-SNAPSHOT, 1.1.5-SNAPSHOT All the ASF License headers in the source files need to be updated to remove the copyright notice as per the new policy: http://www.apache.org/legal/src-headers.html This needs to be done on both the Tomahawk trunk and the 1.1.4 branch. (And Shared.) We could also run Robert Burrell Donkin's RAT (release audit tool) to see if anything else is missing http://code.google.com/p/arat/ -- 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: (TOMAHAWK-738) SaveState fails with a java.util.List implementation other than ArrayList
[
http://issues.apache.org/jira/browse/TOMAHAWK-738?page=comments#action_12442662
]
Wendy Smoak commented on TOMAHAWK-738:
--
Author: schof
Date: Mon Oct 16 11:16:32 2006
New Revision: 464604
URL: http://svn.apache.org/viewvc?view=revrev=464604
Log:
Reverted most of Catagay's r464151 changes. The original problem that he was
trying to solve is really a problem with the MyFaces core not following the
spec. I also commented out a problematic test that does not currently pass b/c
the core is broke.
SaveState fails with a java.util.List implementation other than ArrayList
-
Key: TOMAHAWK-738
URL: http://issues.apache.org/jira/browse/TOMAHAWK-738
Project: MyFaces Tomahawk
Issue Type: Bug
Components: UISaveState
Affects Versions: 1.1.4-SNAPSHOT
Reporter: Cagatay Civici
Assigned To: Cagatay Civici
Fix For: 1.1.4-SNAPSHOT
restoreAttachedState of UIComponentBase wraps the lists as an ArrayList so
restoring values fails when a list implementation other than an arraylist is
used.
An example;
private LinkedList list;
private String name;
private String surname;
public LinkedList getList() {
list = new LinkedList();
list.add(name);
list.add(surname);
return list;
}
public void setList(LinkedList list) {
name = (String)list.get(0);
surname = (String)list.get(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-1358) PortletExternalContextImpl should massage RenderResponse.getNamespace() into acceptable ID
[
http://issues.apache.org/jira/browse/MYFACES-1358?page=comments#action_12440234
]
Wendy Smoak commented on MYFACES-1358:
--
Related discussion thread:
http://www.nabble.com/JIRA-Issue-MYFACES-1358-t2386768.html
PortletExternalContextImpl should massage RenderResponse.getNamespace() into
acceptable ID
--
Key: MYFACES-1358
URL: http://issues.apache.org/jira/browse/MYFACES-1358
Project: MyFaces Core
Issue Type: Bug
Components: Portlet_Support
Affects Versions: 1.1.3
Environment: MacOS X, JDK 5, GridSphere Portal
Reporter: Jason Novotny
Hi,
I've been testing the most basic portlet in our GridSphere framework and
ran into this error:
java.lang.IllegalArgumentException: Subsequent characters of component
identifier must be a letter, a digit, an underscore ('_'), or a dash ('-')!
But component identifier contains #
at
javax.faces.component.UIComponentBase.isIdValid(UIComponentBase.java:1049)
It appears that PortletExternalContextImpl is using the
RenderResponse.getNamespace() method which in our case will return a string
containing a #.
The JSR168 spec. does not specify any disallowed characters in getNamespace()
so I think this is a bug in the PortletExternalContextImpl class-- probably
in the
public String encodeNamespace(String name)
method, it should conert the response.getNamespace into a form that the
UIComponentBase.isValid method can deal with.
Thanks, Jason
--
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: (TOMAHAWK-713) Auto Scroll silently fails on Core 1.1.4 and Tomahawk nightly
[ http://issues.apache.org/jira/browse/TOMAHAWK-713?page=comments#action_12439952 ] Wendy Smoak commented on TOMAHAWK-713: -- I'm under the (possibly mistaken) impression that the javascript changes made to ensure compatibility with the RI went into Core, not into Tomahawk. If so, they are in Core 1.1.5-SNAPSHOT and should be unrelated to this problem. Auto Scroll silently fails on Core 1.1.4 and Tomahawk nightly - Key: TOMAHAWK-713 URL: http://issues.apache.org/jira/browse/TOMAHAWK-713 Project: MyFaces Tomahawk Issue Type: Bug Affects Versions: 1.1.5-SNAPSHOT Environment: MyFaces Core 1.1.4 and Tomahawk nightlies (dated 2006-09-26 or 2006-09-27) Tested in Firefox and Internet Explorer browsers Reporter: Jeff Bischoff Attachments: simple.war When using MyFaces Core 1.1.4 and the latest Tomahawk nightlies (dated 2006-09-26 or 2006-09-27), the Auto Scroll functionality fails. There is no error message in the application logs nor in javascript console. This is presumably related to the javascript changes made to ensure compatibility with the RI. This is a major bug, since latest Tomahawk should be compatible with the Core 1.1.4 release. This breakage can be observed simply by taking the latest tomahawk-examples nightly download, and substituting in the Core 1.1.4 jars. I will attach such an example. -- 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: (TOMAHAWK-713) Auto Scroll silently fails on Core 1.1.4 and Tomahawk nightly
[ http://issues.apache.org/jira/browse/TOMAHAWK-713?page=comments#action_12439960 ] Wendy Smoak commented on TOMAHAWK-713: -- I'm building from source with: $ cd tomahawk/examples/simple $ mvn clean $ mvn package -Dmyfaces=1.1.4 cargo:start In web.xml, org.apache.myfaces.AUTO_SCROLL is true When I visit http://localhost:8080/myfaces-example-simple/autoscroll.jsf , scroll down, and click number 94 or 95, nothing happens. I believe this is the correct behavior. (The message at the top of the page says, The init parameter org.apache.myfaces.AUTO_SCROLL is set to true. In this case, the page shouldn't move when a link is clicked.) (It could be argued that this is backwards, that AUTO_SCROLL=true should mean that the page *will* scroll. But that's not how it is documented.) If I edit web.xml and change AUTO_SCROLL to false, then clicking number 94 causes the page to jump back to the top. Jeff, what behavior are you seeing? Auto Scroll silently fails on Core 1.1.4 and Tomahawk nightly - Key: TOMAHAWK-713 URL: http://issues.apache.org/jira/browse/TOMAHAWK-713 Project: MyFaces Tomahawk Issue Type: Bug Affects Versions: 1.1.5-SNAPSHOT Environment: MyFaces Core 1.1.4 and Tomahawk nightlies (dated 2006-09-26 or 2006-09-27) Tested in Firefox and Internet Explorer browsers Reporter: Jeff Bischoff Attachments: simple.war When using MyFaces Core 1.1.4 and the latest Tomahawk nightlies (dated 2006-09-26 or 2006-09-27), the Auto Scroll functionality fails. There is no error message in the application logs nor in javascript console. This is presumably related to the javascript changes made to ensure compatibility with the RI. This is a major bug, since latest Tomahawk should be compatible with the Core 1.1.4 release. This breakage can be observed simply by taking the latest tomahawk-examples nightly download, and substituting in the Core 1.1.4 jars. I will attach such an example. -- 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-1421) MyFaces not working with Struts Faces Form
[ http://issues.apache.org/jira/browse/MYFACES-1421?page=comments#action_12437232 ] Wendy Smoak commented on MYFACES-1421: -- Mailing list thread: http://www.nabble.com/MyFaces-1.1.4-with-Struts-Faces-1.3.5-t2322772.html MyFaces not working with Struts Faces Form -- Key: MYFACES-1421 URL: http://issues.apache.org/jira/browse/MYFACES-1421 Project: MyFaces Core Issue Type: Bug Reporter: Matthias Weßendorf Assigned To: Matthias Weßendorf Priority: Minor Fix For: 1.1.5-SNAPSHOT _ComponentUtils.java doesn't know the family of the struts faces form component -- 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-1421) MyFaces not working with Struts Faces Form
[ http://issues.apache.org/jira/browse/MYFACES-1421?page=comments#action_12437240 ] Wendy Smoak commented on MYFACES-1421: -- Added a link to this issue on the Struts Faces page: http://struts.apache.org/1.x/struts-faces/ Please share tips on using MyFaces with Struts Faces on the wiki page: http://wiki.apache.org/struts/StrutsFaces MyFaces not working with Struts Faces Form -- Key: MYFACES-1421 URL: http://issues.apache.org/jira/browse/MYFACES-1421 Project: MyFaces Core Issue Type: Bug Reporter: Matthias Weßendorf Assigned To: Matthias Weßendorf Priority: Minor Fix For: 1.1.5-SNAPSHOT _ComponentUtils.java doesn't know the family of the struts faces form component -- 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-1406) Core and Shared project has dependency on myfaces:myfaces-api version 1.1.1
[ http://issues.apache.org/jira/browse/MYFACES-1406?page=comments#action_12436359 ] Wendy Smoak commented on MYFACES-1406: -- This one is on my list to look at now that 1.1.4 is available in the central Maven repo. My theory is that since both 1.1.4 and 1.1.5-SNAPSHOT have the same groupId, Maven will figure out that they are two versions of the same library, and pick the later version. Core and Shared project has dependency on myfaces:myfaces-api version 1.1.1 --- Key: MYFACES-1406 URL: http://issues.apache.org/jira/browse/MYFACES-1406 Project: MyFaces Core Issue Type: Bug Components: build process Affects Versions: 1.1.5-SNAPSHOT Reporter: Paul Spencer Attachments: patch-to-core.txt, patch-to-shared.txt Core and Shared project has dependency on myfaces:myfaces-api version 1.1.1. Their are 2 problems here: 1) The dependency group is myfaces instead of org.apache.myfaces.core 2) The version number is wrong. In many places this problem is minimized by the fact that the depenency is marked as provided. I notices the problem why using eclipse. Eclipse was trying to use the 1.1.1 version of the API even though I was working with the 1.1.5-SNAPSHOT . -- 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] Reopened: (MYFACES-1411) Lifecycle phase executions repetitions
[ http://issues.apache.org/jira/browse/MYFACES-1411?page=all ]
Wendy Smoak reopened MYFACES-1411:
--
Especially given the comment on the issue that these did not come in
with the licence header, I think we need an iCLA for this. I'm
uncomfortable with having @author tags for someone who hasn't signed
an agreement. (At least, I don't see this name on Jim's page [1].)
[1] http://people.apache.org/~jim/committers.html
Lifecycle phase executions repetitions
--
Key: MYFACES-1411
URL: http://issues.apache.org/jira/browse/MYFACES-1411
Project: MyFaces Core
Issue Type: Improvement
Components: JSR-127
Affects Versions: 1.1.4
Reporter: Nikolay Petrov
Assigned To: Martin Marinschek
Fix For: 1.1.5-SNAPSHOT
Attachments: ApplyRequestValuesExecutor.java,
InvokeApplicationExecutor.java, LifecycleImpl.java, PhaseExecutor.java,
ProcessValidationsExecutor.java, RenderResponseExecutor.java,
RestoreViewExecutor.java, UpdateModelValuesExecutor.java
Every phase in LifecycleImpl looks like:
private boolean applyRequestValues(FacesContext facesContext,
PhaseListenerManager phaseListenerMgr)
throws FacesException
{
boolean skipFurtherProcessing = false;
if (log.isTraceEnabled()) log.trace(entering applyRequestValues in
+ LifecycleImpl.class.getName());
try {
phaseListenerMgr.informPhaseListenersBefore(PhaseId.APPLY_REQUEST_VALUES);
if(isResponseComplete(facesContext, applyRequestValues, true))
{
// have to return right away
return true;
}
if(shouldRenderResponse(facesContext, applyRequestValues, true))
{
skipFurtherProcessing = true;
}
facesContext.getViewRoot().processDecodes(facesContext);
} finally {
phaseListenerMgr.informPhaseListenersAfter(PhaseId.APPLY_REQUEST_VALUES);
}
if (isResponseComplete(facesContext, applyRequestValues, false)
|| shouldRenderResponse(facesContext,
applyRequestValues, false))
{
// since this phase is completed we don't need to
return right away even if the response is completed
skipFurtherProcessing = true;
}
if (!skipFurtherProcessing log.isTraceEnabled())
log.trace(exiting applyRequestValues in
+ LifecycleImpl.class.getName());
return skipFurtherProcessing;
}
And that is repeated as many times as phases are. The fix will be to extract
the common behavior in a method, that receives one additional parameter -
PhaseExecutor and delegate to it the real execution.
--
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] Resolved: (TOMAHAWK-675) Build the example apps with specified versions of MyFaces and Tomahawk
[ http://issues.apache.org/jira/browse/TOMAHAWK-675?page=all ] Wendy Smoak resolved TOMAHAWK-675. -- Fix Version/s: 1.1.4-SNAPSHOT 1.1.5-SNAPSHOT Resolution: Fixed This didn't turn out to be as useful as I had hoped. You can't build the current set of examples against an older version of Tomahawk because the examples for new components won't compile. However, as we go forward it should make it easier to re-build the apps from any tag with newer versions of the jars. Right now you have to either modify the poms and re-build or replace jars by hand in WEB-INF/lib. Build the example apps with specified versions of MyFaces and Tomahawk -- Key: TOMAHAWK-675 URL: http://issues.apache.org/jira/browse/TOMAHAWK-675 Project: MyFaces Tomahawk Issue Type: Improvement Affects Versions: 1.1.4-SNAPSHOT, 1.1.5-SNAPSHOT Reporter: Wendy Smoak Assigned To: Wendy Smoak Priority: Minor Fix For: 1.1.4-SNAPSHOT, 1.1.5-SNAPSHOT Add configuration to the tomahawk-examples-project pom that allows the versions of both MyFaces and Tomahawk to be specified on the command line. For example: mvn package -Dmyfaces=1.1.4 -Dtomahawk=1.1.3 This will allow us to run the Selenium functional tests against different combinations of versions of the MyFaces impl and Tomahawk components. -- 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: (TOMAHAWK-675) Build the example apps with specified versions of MyFaces and Tomahawk
Build the example apps with specified versions of MyFaces and Tomahawk -- Key: TOMAHAWK-675 URL: http://issues.apache.org/jira/browse/TOMAHAWK-675 Project: MyFaces Tomahawk Issue Type: Improvement Affects Versions: 1.1.4-SNAPSHOT, 1.1.5-SNAPSHOT Reporter: Wendy Smoak Assigned To: Wendy Smoak Priority: Minor Add configuration to the tomahawk-examples-project pom that allows the versions of both MyFaces and Tomahawk to be specified on the command line. For example: mvn package -Dmyfaces=1.1.4 -Dtomahawk=1.1.3 This will allow us to run the Selenium functional tests against different combinations of versions of the MyFaces impl and Tomahawk components. -- 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: (TOMAHAWK-669) Missing Jars for RegExprValidator
[ http://issues.apache.org/jira/browse/TOMAHAWK-669?page=comments#action_12434447 ] Wendy Smoak commented on TOMAHAWK-669: -- When you try to use the validator, where? Do you mean that the jars are missing from one of the example apps? Missing Jars for RegExprValidator - Key: TOMAHAWK-669 URL: http://issues.apache.org/jira/browse/TOMAHAWK-669 Project: MyFaces Tomahawk Issue Type: Bug Components: Validators Affects Versions: 1.1.3 Environment: Myfaces Core 1.1.3 Reporter: Brooks Lyrette Priority: Minor When you try to use the RegExprValidator control you find that there are 2 jars missing: commons-validator.jar and jakarta-oro.jar -- 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-1406) Core and Shared project has dependency on myfaces:myfaces-api version 1.1.1
[ http://issues.apache.org/jira/browse/MYFACES-1406?page=comments#action_12433709 ] Wendy Smoak commented on MYFACES-1406: -- Core has a dependency on Shared. myfaces/core/impl/pom.xml: artifactItem groupIdorg.apache.myfaces.shared/groupId artifactIdmyfaces-shared-impl/artifactId version2.0.4-SNAPSHOT/version /artifactItem Therefore, Shared cannot depend on the current snapshot of Core or we will have a circular dependency. (Note that it's in a plugin execution and not a normal dependency, so Maven won't catch it during dependency resolution.) The JSF 1.1 API hasn't changed, so it shouldn't matter whether myfaces-impl builds against 1.1.1 or 1.1.5-SNAPSHOT (or against the API jar from the reference implementation, for that matter.) I'm not as opposed to this one, but I don't think it's necessary... and the fewer snapshot dependencies the better. The situation may improve once 1.1.4 is available, because it will be in the same groupId as the current snapshot. Core and Shared project has dependency on myfaces:myfaces-api version 1.1.1 --- Key: MYFACES-1406 URL: http://issues.apache.org/jira/browse/MYFACES-1406 Project: MyFaces Core Issue Type: Bug Components: build process Affects Versions: 1.1.5-SNAPSHOT Reporter: Paul Spencer Attachments: patch-to-core.txt, patch-to-shared.txt Core and Shared project has dependency on myfaces:myfaces-api version 1.1.1. Their are 2 problems here: 1) The dependency group is myfaces instead of org.apache.myfaces.core 2) The version number is wrong. In many places this problem is minimized by the fact that the depenency is marked as provided. I notices the problem why using eclipse. Eclipse was trying to use the 1.1.1 version of the API even though I was working with the 1.1.5-SNAPSHOT . -- 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-1406) Core and Shared project has dependency on myfaces:myfaces-api version 1.1.1
[ http://issues.apache.org/jira/browse/MYFACES-1406?page=comments#action_12433761 ] Wendy Smoak commented on MYFACES-1406: -- Related thread: http://www.nabble.com/Shared-and-API-circular-dependency%2C-related-to-%28MYFACES-1406%29-p6239070.html Core and Shared project has dependency on myfaces:myfaces-api version 1.1.1 --- Key: MYFACES-1406 URL: http://issues.apache.org/jira/browse/MYFACES-1406 Project: MyFaces Core Issue Type: Bug Components: build process Affects Versions: 1.1.5-SNAPSHOT Reporter: Paul Spencer Attachments: patch-to-core.txt, patch-to-shared.txt Core and Shared project has dependency on myfaces:myfaces-api version 1.1.1. Their are 2 problems here: 1) The dependency group is myfaces instead of org.apache.myfaces.core 2) The version number is wrong. In many places this problem is minimized by the fact that the depenency is marked as provided. I notices the problem why using eclipse. Eclipse was trying to use the 1.1.1 version of the API even though I was working with the 1.1.5-SNAPSHOT . -- 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: (TOMAHAWK-611) Upgrading the dojo codebase to 0.3.1
[ http://issues.apache.org/jira/browse/TOMAHAWK-611?page=comments#action_12429180 ] Wendy Smoak commented on TOMAHAWK-611: -- http://svn.apache.org/viewvc?rev=432754view=rev Upgrading the dojo codebase to 0.3.1 Key: TOMAHAWK-611 URL: http://issues.apache.org/jira/browse/TOMAHAWK-611 Project: MyFaces Tomahawk Issue Type: Improvement Affects Versions: 1.1.4-SNAPSHOT, 1.1.5-SNAPSHOT Reporter: Werner Punz Assigned To: Werner Punz Ok we are upgrading the dojo codebase to the latest stable 0.3.1 this one fixes many issues with the old codebase and introduces a lot of new controls which over time hopefully will become jsfed. -- 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: (TOMAHAWK-70) Add Support for Shale-Clay to Tomahawk
[ http://issues.apache.org/jira/browse/TOMAHAWK-70?page=comments#action_12427763 ] Wendy Smoak commented on TOMAHAWK-70: - I believe we've added support in Shale Clay for older Tomahawk versions, but going forward, this should be done in Tomahawk itself. Like Sean, I'm happy to add it to Tomahawk if Gary approves it. :) (And we should do this for prior to 1.1.4 so that Clay isn't left to support it after the fact.) Add Support for Shale-Clay to Tomahawk -- Key: TOMAHAWK-70 URL: http://issues.apache.org/jira/browse/TOMAHAWK-70 Project: MyFaces Tomahawk Issue Type: Bug Reporter: Ryan Wynn Assigned To: sean schofield Attachments: clay-config.xml, clay-tomahawk.war Shale-Clay is a very useful library that allows significant reuse of JSF components. In order to use Clay with Tomahawk, the Tomahawk jar would need to package a clay configuration in the META-INF folder of the jar. If Clay is used, this file will automatically be picked up by Clay. None Clay users would not be affected by the presence of the file. Attached is a base Shale configuration file for Tomahawk. Please consider adding this file to Tomahawk. It will eliminate the need for those wanting to use Shale-Tomahawk from having to create the file themselves. -- 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: (TOMAHAWK-584) Improve the Tree 2 documentation
Improve the Tree 2 documentation Key: TOMAHAWK-584 URL: http://issues.apache.org/jira/browse/TOMAHAWK-584 Project: MyFaces Tomahawk Issue Type: Improvement Components: Tree2 Reporter: Wendy Smoak Mike Kienenberger made a few comments about missing documentation for Tree 2: Most of the documentation is in the wiki, except for the tld. However, three attributes aren't documented at all: value, var, and varNodeToggler. No documentation on what the allowable facets are. No documentation stating that expand and collapse facets need to be UIGraphic components. Discussion thread: http://www.mail-archive.com/dev%40myfaces.apache.org/msg16266.html -- 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: (TOMAHAWK-583) Use Selenium for functional testing of the example apps
Use Selenium for functional testing of the example apps --- Key: TOMAHAWK-583 URL: http://issues.apache.org/jira/browse/TOMAHAWK-583 Project: MyFaces Tomahawk Issue Type: Test Affects Versions: 1.1.5-SNAPSHOT Reporter: Wendy Smoak Use Selenium for functional testing of the JSF components in the example apps. Discussion thread: http://www.mail-archive.com/dev%40myfaces.apache.org/msg16239.html A simple test of the 'add two numbers' form in myfaces-example-simple shows that the button works, but the link doesn't: http://people.apache.org/~wsmoak/myfaces/selenium/myfaces-simple-failure.jpg -- 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-1376) getScrolling is not defined in simple tree2 example
[ http://issues.apache.org/jira/browse/MYFACES-1376?page=comments#action_12425566 ] Wendy Smoak commented on MYFACES-1376: -- On 02-Aug-2006, Matthias wrote: FIXED IN BRANCH URL: http://svn.apache.org/viewvc?rev=428231view=rev Log: fixed MYFACES-1376 by moving to commits from svn commit: r421297 to branch URL: http://svn.apache.org/viewvc?rev=428230view=rev Log: fixed MYFACES-1376 by moving to commits from svn commit: r421297 to branch ... and r421297 is: Author: mmarinschek Date: Wed Jul 12 08:54:40 2006 New Revision: 421297 URL: http://svn.apache.org/viewvc?rev=421297view=rev Log: made calling of several javascript functions dependent on if they are actually present. Added source section to the poms. Default message now also prints the message of the causes of an exception. getScrolling is not defined in simple tree2 example --- Key: MYFACES-1376 URL: http://issues.apache.org/jira/browse/MYFACES-1376 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 1.1.4-SNAPSHOT Reporter: sean schofield Assigned To: Matthias Weßendorf Priority: Blocker Fix For: 1.1.4-SNAPSHOT tree2NiceWrap.jsf throws a javascript error when you try to expand the node -- 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-1377) h:dataTable with t:dataScroller generates Row is not available. Rowindex =# errors on non-full pages.
[ http://issues.apache.org/jira/browse/MYFACES-1377?page=comments#action_12425569 ] Wendy Smoak commented on MYFACES-1377: -- Discussion thread: http://www.mail-archive.com/dev%40myfaces.apache.org/msg16177.html h:dataTable with t:dataScroller generates Row is not available. Rowindex =# errors on non-full pages. --- Key: MYFACES-1377 URL: http://issues.apache.org/jira/browse/MYFACES-1377 Project: MyFaces Core Issue Type: Bug Affects Versions: 1.1.4-SNAPSHOT Reporter: Mike Kienenberger Priority: Minor h:dataTable with t:dataScroller generates Row is not available. Rowindex =# errors on non-full pages. See http://issues.apache.org/jira/browse/TOMAHAWK-467 -- 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-1376) getScrolling is not defined in simple tree2 example
[ http://issues.apache.org/jira/browse/MYFACES-1376?page=comments#action_12425678 ] Wendy Smoak commented on MYFACES-1376: -- Matthias reverted part of r421297, here: http://svn.apache.org/viewvc?rev=428629view=rev (shared 2.0.4 trunk) http://svn.apache.org/viewvc?rev=428630view=rev (shared 2.0.3 branch) myfaces/shared/trunk/core/src/main/java/org/apache/myfaces/shared/renderkit/html/util/JavascriptUtils.java -private static final String AUTO_SCROLL_PARAM = org_apache_myfaces_autoScroll; -private static final String AUTO_SCROLL_FUNCTION = org_apache_myfaces_getScrolling; +private static final String AUTO_SCROLL_PARAM = autoScroll; +private static final String AUTO_SCROLL_FUNCTION = getScrolling; getScrolling is not defined in simple tree2 example --- Key: MYFACES-1376 URL: http://issues.apache.org/jira/browse/MYFACES-1376 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 1.1.4-SNAPSHOT Reporter: sean schofield Assigned To: Matthias Weßendorf Priority: Blocker Fix For: 1.1.4-SNAPSHOT tree2NiceWrap.jsf throws a javascript error when you try to expand the node -- 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-1361) The listing in Apache's project catalog is out of date and need to be updated.
[ http://issues.apache.org/jira/browse/MYFACES-1361?page=comments#action_12420104 ] Wendy Smoak commented on MYFACES-1361: -- Any updates to the doap file and should be picked up automatically: http://svn.apache.org/repos/asf/myfaces/site/trunk/src/site/resources/doap_MyFaces.rdf To add more projects: http://projects.apache.org/create.html I'll ping site-dev@ about the misspelled PMC name. The listing in Apache's project catalog is out of date and need to be updated. -- Key: MYFACES-1361 URL: http://issues.apache.org/jira/browse/MYFACES-1361 Project: MyFaces Core Type: Task Reporter: Paul Spencer The listing in Apache's project catalog is out of date and need to be updated. See http://projects.apache.org/projects/myfaces.html The information to be updated includes: 1) Release Information 2) Spelling/Capitalization of the project name (per Dennis Byrne) -- 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: (TOMAHAWK-517) Tomahawk Maven2 oddity: 1.1.3 requires Shale and Struts1.2.8.
Tomahawk Maven2 oddity: 1.1.3 requires Shale and Struts1.2.8. - Key: TOMAHAWK-517 URL: http://issues.apache.org/jira/browse/TOMAHAWK-517 Project: MyFaces Tomahawk Type: Improvement Versions: 1.1.3 Reporter: Wendy Smoak Assigned to: Wendy Smoak Priority: Minor Fix For: 1.1.4-SNAPSHOT From: David Friedman [EMAIL PROTECTED] To: MyFaces users@myfaces.apache.org Date: Jun 29, 2006 12:11 PM I just added Tomahawk 1.1.3 to my Maven2 build with: dependency groupIdorg.apache.myfaces.tomahawk/groupId artifactIdtomahawk/artifactId version1.1.3/version /dependency And it suddenly added Struts-1.2.8 to my .war file. The tomahawk-1.1.3.pom file lists Struts like so: dependency groupIdstruts/groupId artifactIdstruts/artifactId version1.2.8/version scopecompile/scope /dependency What kind of dependency is that? I couldn't find anything in the Wiki about it as some kind of Tomahawk 1.1.3 upgrade dependencies. -- 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: (TOMAHAWK-517) Tomahawk Maven2 oddity: 1.1.3 requires Struts1.2.8
[ http://issues.apache.org/jira/browse/TOMAHAWK-517?page=comments#action_12419409 ] Wendy Smoak commented on TOMAHAWK-517: -- Fixed on the 1.1.4 branch, needs to be fixed on the trunk as well. Tomahawk Maven2 oddity: 1.1.3 requires Struts1.2.8 -- Key: TOMAHAWK-517 URL: http://issues.apache.org/jira/browse/TOMAHAWK-517 Project: MyFaces Tomahawk Type: Improvement Versions: 1.1.3 Reporter: Wendy Smoak Assignee: Wendy Smoak Priority: Minor Fix For: 1.1.4-SNAPSHOT From: David Friedman [EMAIL PROTECTED] To: MyFaces users@myfaces.apache.org Date: Jun 29, 2006 12:11 PM I just added Tomahawk 1.1.3 to my Maven2 build with: dependency groupIdorg.apache.myfaces.tomahawk/groupId artifactIdtomahawk/artifactId version1.1.3/version /dependency And it suddenly added Struts-1.2.8 to my .war file. The tomahawk-1.1.3.pom file lists Struts like so: dependency groupIdstruts/groupId artifactIdstruts/artifactId version1.2.8/version scopecompile/scope /dependency What kind of dependency is that? I couldn't find anything in the Wiki about it as some kind of Tomahawk 1.1.3 upgrade dependencies. -- 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] Reopened: (MYFACES-1330) Improve the profile activation in the archetypes
[ http://issues.apache.org/jira/browse/MYFACES-1330?page=all ] Wendy Smoak reopened MYFACES-1330: -- Reopening for a small fix to the JSF component archetype. Improve the profile activation in the archetypes Key: MYFACES-1330 URL: http://issues.apache.org/jira/browse/MYFACES-1330 Project: MyFaces Core Type: Improvement Components: build process Reporter: Wendy Smoak Priority: Minor Attachments: jsfcomp-20060616.diff, maven-profile-activation.diff, tomahawk-profile-activation.diff The default activation of the 'myfaces' profile currently depends on the fact that no other profile is being activated automatically. See MNG-2136. It would be better to activate 'myfaces' based on the absence of a system property, and then the RI with a particular value. (Thanks to Roland Asmann on [EMAIL PROTECTED] for this suggestion.) -- 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-1330) Improve the profile activation in the archetypes
Improve the profile activation in the archetypes Key: MYFACES-1330 URL: http://issues.apache.org/jira/browse/MYFACES-1330 Project: MyFaces Core Type: Improvement Components: build process Reporter: Wendy Smoak Priority: Minor The default activation of the 'myfaces' profile currently depends on the fact that no other profile is being activated automatically. See MNG-2136. It would be better to activate 'myfaces' based on the absence of a system property, and then the RI with a particular value. (Thanks to Roland Asmann on [EMAIL PROTECTED] for this suggestion.) -- 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-1173) Change the groupId for Shale Test Framework
Change the groupId for Shale Test Framework --- Key: MYFACES-1173 URL: http://issues.apache.org/jira/browse/MYFACES-1173 Project: MyFaces Core Type: Improvement Versions: 1.1.2-SNAPSHOT Reporter: Wendy Smoak Since I can't create a patch due to the problem with eol-style, can someone please make the following change in all the affected poms? dependency - groupIdstruts/groupId + groupIdorg.apache.struts.shale/groupId artifactIdshale-test/artifactId version1.0.1-SNAPSHOT/version scopetest/scope (Be careful not to change the one dependency on Struts 1.2.8 -- that one hasn't moved yet.) I've deployed the snapshot to the new location in cvs.apache.org/maven-snapshot-repository, and will leave the old one in place until I see the change go in. -- 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-672) RC2: Unsupported major.minor version 49.0
RC2: Unsupported major.minor version 49.0 -- Key: MYFACES-672 URL: http://issues.apache.org/jira/browse/MYFACES-672 Project: MyFaces Type: Bug Components: General Versions: 1.1.1 Environment: Tomcat 5.0.30, JDK 1.4.2_09 Reporter: Wendy Smoak Priority: Blocker RC2 appears to have been compiled for JDK 1.5. Deploying the sample applications in Tomcat 5.0 with JDK 1.4.2_09 results in 'UnsupportedClassVersionError' in the localhost log. 2005-10-05 19:54:49 StandardContext[/myfaces-tiles]Error configuring application listener of class org.apache.myfaces.webapp.StartupServletContextListener java.lang.UnsupportedClassVersionError: org/apache/myfaces/webapp/StartupServletContextListener (Unsupported major.minor version 49.0) at java.lang.ClassLoader.defineClass0(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:539) -- 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-560) Tiles example does not work
[ http://issues.apache.org/jira/browse/MYFACES-560?page=comments#action_12329490 ] Wendy Smoak commented on MYFACES-560: - This is tiles.war from the 1.1.0 release candidate. Page1, Page2 and non-tiles page work fine, but clicking the 'nested Tiles' button gives: HTTP Status 500 - javax.servlet.ServletException: Error calling action method of component with id menu:button:_id7 javax.faces.webapp.FacesServlet.service(FacesServlet.java:109) org.apache.myfaces.component.html.util.ExtensionsFilter.doFilter(ExtensionsFilter.java:122) root cause javax.faces.FacesException: Error calling action method of component with id menu:button:_id7 org.apache.myfaces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:74) javax.faces.component.UICommand.broadcast(UICommand.java:106) javax.faces.component.UIViewRoot._broadcastForPhase(UIViewRoot.java:90) javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:164) org.apache.myfaces.lifecycle.LifecycleImpl.invokeApplication(LifecycleImpl.java:271) org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:86) javax.faces.webapp.FacesServlet.service(FacesServlet.java:94) org.apache.myfaces.component.html.util.ExtensionsFilter.doFilter(ExtensionsFilter.java:122) Apache Tomcat/5.5.9, WinXP When the error happens, the Tomcat console shows: Phase: INVOKE_APPLICATION(5) Tiles example does not work --- Key: MYFACES-560 URL: http://issues.apache.org/jira/browse/MYFACES-560 Project: MyFaces Type: Bug Components: General Versions: Nightly Build Reporter: sean schofield Assignee: Matthias Weßendorf The Tiles example does not work (as per Wendy's email a while back.) I'm prepared to do the 1.1.0 tag and build but since we know we need this example I'll wait until we resolve this. -- 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-560) Tiles example does not work
[ http://issues.apache.org/jira/browse/MYFACES-560?page=comments#action_12324469 ] Wendy Smoak commented on MYFACES-560: - See: http://issues.apache.org/jira/browse/MYFACES-529 Tiles example does not work --- Key: MYFACES-560 URL: http://issues.apache.org/jira/browse/MYFACES-560 Project: MyFaces Type: Bug Components: General Versions: Nightly Build Reporter: sean schofield The Tiles example does not work (as per Wendy's email a while back.) I'm prepared to do the 1.1.0 tag and build but since we know we need this example I'll wait until we resolve this. -- 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-529) tiles.war example app does not work
tiles.war example app does not work --- Key: MYFACES-529 URL: http://issues.apache.org/jira/browse/MYFACES-529 Project: MyFaces Type: Bug Components: General Versions: Nightly Build Environment: WinXP Pro, Tomcat 5.5.9, JDK 1.5 Reporter: Wendy Smoak Priority: Minor Deploying tiles.war from the 20050906 nightly build and navigating to http://localhost:8080/tiles gives: HTTP Status 500 - type Exception report message description The server encountered an internal error () that prevented it from fulfilling this request. exception javax.servlet.ServletException javax.faces.webapp.FacesServlet.service(FacesServlet.java:113) org.apache.myfaces.component.html.util.ExtensionsFilter.doFilter(ExtensionsFilter.java:122) root cause java.lang.NullPointerException org.apache.myfaces.application.jsp.JspTilesViewHandlerImpl.renderView(JspTilesViewHandlerImpl.java:165) org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:300) javax.faces.webapp.FacesServlet.service(FacesServlet.java:95) org.apache.myfaces.component.html.util.ExtensionsFilter.doFilter(ExtensionsFilter.java:122) In the Tomcat console: Sep 7, 2005 7:49:39 AM org.apache.myfaces.application.jsp.JspTilesViewHandlerImpl getDefinitionsFactory SEVERE: No Tiles definition found. Specify Definition files by adding tiles-definitions param in your web.xml Sep 7, 2005 7:49:56 AM org.apache.myfaces.application.jsp.JspTilesViewHandlerImpl getDefinitionsFactory SEVERE: No Tiles definition found. Specify Definition files by adding tiles-definitions param in your web.xml -- 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-521) Errors in TLDs
[ http://issues.apache.org/jira/browse/MYFACES-521?page=comments#action_12322753 ] Wendy Smoak commented on MYFACES-521: - The error message is pointing out the line number: myfaces_html.tld:2585 It's at the bottom of selectOneMenu: attributenameenabledClass/name requiredfalse/required rtexprvaluefalse/rtexprvalue/attribute attributenamedisabledClass/name requiredfalse/required rtexprvaluefalse/rtexprvalue/attribute ant /tag Actually the extra text is in the entity standard_select_one_menu_attributes; http://svn.apache.org/repos/asf/myfaces/impl/trunk/tld/entities/standard_select_one_menu_attributes.xml Errors in TLDs -- Key: MYFACES-521 URL: http://issues.apache.org/jira/browse/MYFACES-521 Project: MyFaces Type: Bug Components: General Versions: Nightly Build Environment: Windows, JDK 1.4.2, Resin 3.0.14 Reporter: Boris Kovalenko Attachments: tlds.zip Errors in TLDs... Resin compains like: log4j:WARN Please initialize the log4j system properly. [19:06:20.731] com.caucho.xml.XmlParseException: jar:file:/C:/Development/Projec ts/Ubs/WEB-INF/lib/myfaces-all.jar!/META-INF/myfaces_html.tld:2585: The followin g text is not allowed in this context. [19:06:20.731] [19:06:20.731] ant [19:06:20.731] [19:06:20.731] [19:06:20.731] [19:06:20.731] attribute or [19:06:20.731] example are expected, [19:06:20.731] or /tag may close. -- 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
