[jira] Commented: (MYFACES-1126) ExtensionsFilter results in empty response on Jetty 6
[ http://issues.apache.org/jira/browse/MYFACES-1126?page=comments#action_12366490 ] Bill Dudney commented on MYFACES-1126: -- Jurgen, The jetty m2 plugin is trying to deploy from the src directory instead of from the target dir. Any idea how to make the m2 plugin deploy from the target dir? IOW, the src dir does not have the jars for myfaces but the target does. I've pasted the stack trace that I get from m2 below. Also since few of us are that familiar with Jetty (as far as I know anyway) perhaps you could do some digging to help us find the problem? Thanks again for using myfaces! [INFO] Configuring Jetty for project: Tomahawk Examples: Simple [INFO] Webapp source directory is: .../myfaces-current/tomahawk/examples/simple/src/main/webapp [INFO] web.xml file located at: .../myfaces-current/tomahawk/examples/simple/src/main/webapp/WEB-INF/web.xml [INFO] Classes located at: .../myfaces-current/tomahawk/examples/simple/target/classes [INFO] tmp dir for webapp will be .../myfaces-current/tomahawk/examples/simple/target/jetty-tmp [INFO] Starting Jetty Server ... [INFO] No connectors configured, using defaults: org.mortbay.jetty.nio.SelectChannelConnector listening on 8080 with maxIdleTime 3 1 [main] INFO org.mortbay.log - Logging to [EMAIL PROTECTED] via org.mortbay.log.Slf4jLog [INFO] Context path = /myfaces-example-simple [INFO] Webapp directory = .../myfaces-current/tomahawk/examples/simple/src/main/webapp [INFO] Setting up classpath ... [INFO] Finished setting up classpath [INFO] Started configuring web.xml, resource base=.../myfaces-current/tomahawk/examples/simple/src/main/webapp [INFO] Finished configuring web.xml 1560 [main] WARN org.mortbay.log - failed Faces Servlet 1562 [main] WARN org.mortbay.log - failed [EMAIL PROTECTED]/myfaces-example-simple,file:.../myfaces-current/tomahawk/examples/simple/src/main/webapp/} 1621 [main] INFO org.mortbay.log - Started SelectChannelConnector @ 0.0.0.0:8080 1622 [main] WARN org.mortbay.log - failed [EMAIL PROTECTED] [INFO] Jetty server exiting. [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failure Embedded error: No Factories configured for this Application. This happens if the faces-initialization does not work at all - make sure that you properly include all configuration settings necessary for a basic faces application and that all the necessary libs are included. Also check the logging output of your web application and your container for any exceptions! If you did that and find nothing, the mistake might be due to the fact that you use some special web-containers which do not support registering context-listeners via TLD files and a context listener is not setup in your web.xml. A typical config looks like this; org.apache.myfaces.webapp.StartupServletContextListener > ExtensionsFilter results in empty response on Jetty 6 > - > > Key: MYFACES-1126 > URL: http://issues.apache.org/jira/browse/MYFACES-1126 > Project: MyFaces > Type: Bug > Components: Tomahawk > Versions: 1.1.1, Nightly > Environment: Windows XP SP2, Jetty 6 as part of the Jetty6 plugin for maven2 > Reporter: Jurgen Lust > > When deploying a MyFaces webapp that uses the ExtensionsFilter in Jetty6, the > response is always empty. > You can verify this by adding this to the tomahawk/examples/simple/pom.xml: > > >org.mortbay.jetty >maven-jetty6-plugin >6.0.0beta9 > >10 > > > > And then typing mvn jetty6:run in the same folder. > Now you can access the simple example at > http://localhost:8080/myfaces-example-simple/ > Normally you will now see a completely empty 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
[jira] Commented: (MYFACES-688) displayValueOnly property on HtmlSelectBooleanCheckbox throws ClassCastException during rendering, second approach
[
http://issues.apache.org/jira/browse/MYFACES-688?page=comments#action_12331799
]
Bill Dudney commented on MYFACES-688:
-
Hi Stefan,
If you could post an example or cactus test that demonstrates the bug it would
help up alot in making sure we fix all the problem the first time.
Thanks!
> displayValueOnly property on HtmlSelectBooleanCheckbox throws
> ClassCastException during rendering, second approach
> --
>
> Key: MYFACES-688
> URL: http://issues.apache.org/jira/browse/MYFACES-688
> Project: MyFaces
> Type: Bug
> Components: Tomahawk
> Versions: Nightly, 1.1.0
> Environment: tomcat 5.5.7, java 1.5, linux 2.6.13
> Reporter: Stefan Betermieux
> Assignee: Martin Marinschek
> Fix For: Nightly
>
> When I create a HtmlSelectBooleanCheckbox and set displayValueOnly to true,
> an exception is raised during the rendering phase. During encodeEnd()
> HtmlRendererUtils.renderDisplayValueOnlyForSelects() is called.
> The following snippet causes the problems:
>
> if (uiComponent instanceof UISelectMany) {
> isSelectOne = false;
> selectItemList = RendererUtils.getSelectItemList((UISelectMany)
> uiComponent);
> converter = findUISelectManyConverterFailsafe(facesContext, uiComponent);
> } else {
> isSelectOne = true;
> selectItemList = RendererUtils.getSelectItemList((UISelectOne) uiComponent);
> converter = findUIOutputConverterFailSafe(facesContext, uiComponent);
> }
> Since the HtmlSelectBooleanCheckbox is derived neither from UISelectMany nor
> from UISelectOne but from UISelectBoolean, the cast to UISelectOne fails.
--
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-664) Cactus Test for HtmlSelectManyCheckbox rendering
[ http://issues.apache.org/jira/browse/MYFACES-664?page=all ] Bill Dudney closed MYFACES-664: --- Fix Version: Nightly Resolution: Fixed Thanks for the test! > Cactus Test for HtmlSelectManyCheckbox rendering > > > Key: MYFACES-664 > URL: http://issues.apache.org/jira/browse/MYFACES-664 > Project: MyFaces > Type: Test > Components: Tomahawk > Versions: Nightly > Reporter: Ken Weiner > Fix For: Nightly > Attachments: HtmlSelectManyCheckboxRendererCactus-patch.txt > > As requested in http://issues.apache.org/jira/browse/MYFACES-622, here are > some cactus tests for the rendering of HtmlSelectManyCheckbox. > I am new to Cactus test writing, so feel free to correct anything or suggest > a different way of acheiving the assertions. -- 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-674) 'common' accessor prefixes
[ http://issues.apache.org/jira/browse/MYFACES-674?page=all ] Bill Dudney closed MYFACES-674: --- Resolution: Won't Fix I agree that this is not a myfaces issues. Perhapse taking it up with the next JSR for Java 6 SE? We should close this (and I have) > 'common' accessor prefixes > -- > > Key: MYFACES-674 > URL: http://issues.apache.org/jira/browse/MYFACES-674 > Project: MyFaces > Type: Wish > Components: General > Reporter: Thomas Timbul > Priority: Minor > > Currently (correct me if wrong) the list of 'common' getter and setter > prefixes is > get (getProperty) > is (isBig) > set (setProperty) > One particular prefix I find more common every day is 'has' for boolean > getters (hasArms rather than isArmed or isWithArms or isHasArms). > So maybe there should be a referendum on what is commonly perceived as > 'common' prefixes and those added as possibilities. Of course, if the method > gets too long we need to be careful with how EL can handle it, since there > could be a great difference between 'isMobile' and 'hasMobile' and EL cannot > distinguish the 2... (can it?) -- 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-672) RC2: Unsupported major.minor version 49.0
[ http://issues.apache.org/jira/browse/MYFACES-672?page=all ] Bill Dudney closed MYFACES-672: --- Fix Version: 1.1.1 Resolution: Fixed > 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 > Fix For: 1.1.1 > > 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] Closed: (MYFACES-628) Current Lifecycle implementation violates JSF Spec 1.1
[ http://issues.apache.org/jira/browse/MYFACES-628?page=all ] Bill Dudney closed MYFACES-628: --- Resolution: Fixed Fixed, with 25 cactus tests hopefully it really really works now. I did not add the 'next phase' stuff to the logs. > Current Lifecycle implementation violates JSF Spec 1.1 > -- > > Key: MYFACES-628 > URL: http://issues.apache.org/jira/browse/MYFACES-628 > Project: MyFaces > Type: Bug > Components: JSR-127 > Versions: 1.1.0 > Reporter: Holger Schimanski > Assignee: Bill Dudney > Priority: Blocker > Fix For: 1.1.1 > > If a PhaseListener.beforePhase() calles FacesContext.renderResponse() or > FacesContext.responseComplete(), then the LifeCycleImpl should not execute > the functionality required for the current phase. (see JSF Spec 1.1 section > 11-1 page 296f.) LifeCycleImpl is not taking care about this. > This is important for us, because we'd like to make a redirect in the before > render response phase. And at the moment an Illegal State exception is > thrown, because the renderResponse is executed although responseComplete has > been called. -- 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-628) Current Lifecycle implementation violates JSF Spec 1.1
[
http://issues.apache.org/jira/browse/MYFACES-628?page=comments#action_12331221
]
Bill Dudney commented on MYFACES-628:
-
Hi Ronald,
Here is the logging code;
private boolean shouldSkipPhaseProcessing(FacesContext facesContext, String
phase, boolean before) {
boolean flag = false;
if (facesContext.getResponseComplete())
{
if (log.isDebugEnabled())
log.debug("exiting from lifecycle.execute in "
+ phase
+ " because getResponseComplete
is true from one of the " +
(before ? "before" : "after") +
" listeners");
flag = true;
}
if (facesContext.getRenderResponse())
{
if (log.isDebugEnabled())
log.debug("exiting from lifecycle.execute in "
+ phase
+ " because getRenderResponse
is true from one of the " +
(before ? "before" : "after") +
" listeners");
flag = true;
}
return flag;
}
I figure you know the phase lifecycle well enough that I don't have to put the
'next phase' into the message.
> Current Lifecycle implementation violates JSF Spec 1.1
> --
>
> Key: MYFACES-628
> URL: http://issues.apache.org/jira/browse/MYFACES-628
> Project: MyFaces
> Type: Bug
> Components: JSR-127
> Versions: 1.1.0
> Reporter: Holger Schimanski
> Assignee: Bill Dudney
> Priority: Blocker
> Fix For: 1.1.1
>
> If a PhaseListener.beforePhase() calles FacesContext.renderResponse() or
> FacesContext.responseComplete(), then the LifeCycleImpl should not execute
> the functionality required for the current phase. (see JSF Spec 1.1 section
> 11-1 page 296f.) LifeCycleImpl is not taking care about this.
> This is important for us, because we'd like to make a redirect in the before
> render response phase. And at the moment an Illegal State exception is
> thrown, because the renderResponse is executed although responseComplete has
> been called.
--
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-628) Current Lifecycle implementation violates JSF Spec 1.1
[ http://issues.apache.org/jira/browse/MYFACES-628?page=all ] Bill Dudney reopened MYFACES-628: - Hi Ronald, On the logging: I'll update that with the requested detail On the before listeners in render: I think I have a fix for that but I wanted to run it by the rest of the dev team. In the FacesServlet.service method I can wrap the call to lifecycle.render in a check for 'responseComplete'. This will avoid calling render all together (as Ronald needs) and seems to be what is needed. The other approach is to have a check at the top of render that looks for 'responsecomplete' and just returns. Which fix is better? > Current Lifecycle implementation violates JSF Spec 1.1 > -- > > Key: MYFACES-628 > URL: http://issues.apache.org/jira/browse/MYFACES-628 > Project: MyFaces > Type: Bug > Components: JSR-127 > Versions: 1.1.0 > Reporter: Holger Schimanski > Assignee: Bill Dudney > Priority: Blocker > Fix For: 1.1.1 > > If a PhaseListener.beforePhase() calles FacesContext.renderResponse() or > FacesContext.responseComplete(), then the LifeCycleImpl should not execute > the functionality required for the current phase. (see JSF Spec 1.1 section > 11-1 page 296f.) LifeCycleImpl is not taking care about this. > This is important for us, because we'd like to make a redirect in the before > render response phase. And at the moment an Illegal State exception is > thrown, because the renderResponse is executed although responseComplete has > been called. -- 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-622) HtmlSelectManyCheckbox rendering is flawed
[ http://issues.apache.org/jira/browse/MYFACES-622?page=comments#action_12331210 ] Bill Dudney commented on MYFACES-622: - Hi Ken, Any chance we could get some automated tests that we could use to make sure things continue to work as expected? A simple cactus test would probably be sufficient. I'd be glad to offer some pointers on Cactus in a dev list thread if you need them. I am generally opposed to introducing changes to the branch that are not strictly necessary but the changes here seem to be localized so with a test I'd be OK with them. > HtmlSelectManyCheckbox rendering is flawed > -- > > Key: MYFACES-622 > URL: http://issues.apache.org/jira/browse/MYFACES-622 > Project: MyFaces > Type: Bug > Components: Tomahawk > Versions: 1.1.1 > Reporter: Ken Weiner > Attachments: HtmlCheckboxRenderer.java-patch.txt > > I apologize, but the patch I submitted to add an attirbute "layoutWidth" was > not adequately tested, and I have discovered that the layoutWidth attribute > does not have the desired effect when the checkboxes are rendered with a > pageDirection layout. The checkboxes end up rendering in a single vertical > row not matter what the layoutWidth is. Also for both pageDirection and > lineDirection, the markup is not properly formed. The label tag appears > twice for each checkbox. > I am now submitting another patch to HtmlCheckboxRenderer that fixes these > issues. I have tested it with different amounts of checkboxes, different > layoutWidths, and different combinations of SelectItemGroups. Sorry about > the original being messed up. -- 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: (MYFACES-657) Blank page after switching to 1.1.1RC1
[ http://issues.apache.org/jira/browse/MYFACES-657?page=all ] Bill Dudney resolved MYFACES-657: - Fix Version: 1.1.1 Resolution: Fixed This bug is fixed in 1.1.1RC2 > Blank page after switching to 1.1.1RC1 > -- > > Key: MYFACES-657 > URL: http://issues.apache.org/jira/browse/MYFACES-657 > Project: MyFaces > Type: Bug > Versions: 1.1.1 > Environment: JDK 1.4 and Tomcat 5.0.x probably other versions affected as > well > Reporter: Werner Punz > Priority: Blocker > Fix For: 1.1.1 > > There have been several reports of getting a blank page after people swithing > to the 1.1.1RC > The most detailed report comes from Wendy Smoak from the Struts and Struts > Shale project: > There are two reports on the user list that 1.1.1 is causing a previously > working app to just display a blank page. (Though they're talking about > myfaces-all.jar, and I'm having trouble with the api & impl pair.) > All of the example webapps display blank pages on Tomcat 5.0.30 and JDK > 1.4.2_09. > If it helps at all, I've posted the debug logs from the Shale Use Cases app > with 1.1.1 as well as the 20051002 nightly build (which uses the RI): > http://wiki.wsmoak.net/cgi-bin/wiki.pl?ShaleUseCases -- 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-610) Getting IllegalStateException exception when setting javax.faces.STATE_SAVING_METHOD to "server"
[ http://issues.apache.org/jira/browse/MYFACES-610?page=comments#action_12331131 ] Bill Dudney commented on MYFACES-610: - Sorry but I was running on the 1.1.1 branch. We will hopefully have a release out shortly (in a week or so) that should fix this issue. Although an example would still be helpful so we could add a cactus test that makes sure we don't reintroduce the problem. > Getting IllegalStateException exception when setting > javax.faces.STATE_SAVING_METHOD to "server" > > > Key: MYFACES-610 > URL: http://issues.apache.org/jira/browse/MYFACES-610 > Project: MyFaces > Type: Bug > Components: General > Versions: 1.1.0 > Environment: Tomcat 5.5.9 on Windows XP. > Reporter: Saul Q Yuan > > I have an application that works on 1.0.9 but stopped working when upgraded > to 1.1.0. I got a blank screen. And console shows the following error: > java.lang.IllegalStateException: Cannot create a session after the > response > has been committed > at > org.apache.catalina.connector.Request.doGetSession(Request.java:2195) > at > org.apache.catalina.connector.Request.getSession(Request.java:2017) > at > org.apache.catalina.connector.RequestFacade.getSession(RequestFacade.java:822) > at > org.apache.myfaces.context.servlet.SessionMap.setAttribute(SessionMap.java:50) > at > org.apache.myfaces.context.servlet.AbstractAttributeMap.put(AbstractAttributeMap.java:104) > at > org.apache.myfaces.application.jsp.JspStateManagerImpl.saveSerializedViewInServletSession(JspStateManagerImpl.java:321) > at > org.apache.myfaces.application.jsp.JspStateManagerImpl.saveSerializedView(JspStateManagerImpl.java:228) > at > org.apache.myfaces.taglib.core.ViewTag.doEndTag(ViewTag.java:122) > at > org.apache.jsp.common.headerBodyFooterLayout_jsp._jspx_meth_f_view_0 > > After a few days tweaking & debugging, I changed the value of the following > setting in my web.xml: > javax.faces.STATE_SAVING_METHOD > from "server" to "client", > Now, my app works again. > I think this is a 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] Commented: (MYFACES-610) Getting IllegalStateException exception when setting javax.faces.STATE_SAVING_METHOD to "server"
[ http://issues.apache.org/jira/browse/MYFACES-610?page=comments#action_12331130 ] Bill Dudney commented on MYFACES-610: - Could you post an example of what is causing this problem? The example apps seem to work with the saving method set to 'server', and with the value excluded (which defaults to server). > Getting IllegalStateException exception when setting > javax.faces.STATE_SAVING_METHOD to "server" > > > Key: MYFACES-610 > URL: http://issues.apache.org/jira/browse/MYFACES-610 > Project: MyFaces > Type: Bug > Components: General > Versions: 1.1.0 > Environment: Tomcat 5.5.9 on Windows XP. > Reporter: Saul Q Yuan > > I have an application that works on 1.0.9 but stopped working when upgraded > to 1.1.0. I got a blank screen. And console shows the following error: > java.lang.IllegalStateException: Cannot create a session after the > response > has been committed > at > org.apache.catalina.connector.Request.doGetSession(Request.java:2195) > at > org.apache.catalina.connector.Request.getSession(Request.java:2017) > at > org.apache.catalina.connector.RequestFacade.getSession(RequestFacade.java:822) > at > org.apache.myfaces.context.servlet.SessionMap.setAttribute(SessionMap.java:50) > at > org.apache.myfaces.context.servlet.AbstractAttributeMap.put(AbstractAttributeMap.java:104) > at > org.apache.myfaces.application.jsp.JspStateManagerImpl.saveSerializedViewInServletSession(JspStateManagerImpl.java:321) > at > org.apache.myfaces.application.jsp.JspStateManagerImpl.saveSerializedView(JspStateManagerImpl.java:228) > at > org.apache.myfaces.taglib.core.ViewTag.doEndTag(ViewTag.java:122) > at > org.apache.jsp.common.headerBodyFooterLayout_jsp._jspx_meth_f_view_0 > > After a few days tweaking & debugging, I changed the value of the following > setting in my web.xml: > javax.faces.STATE_SAVING_METHOD > from "server" to "client", > Now, my app works again. > I think this is a 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] Commented: (MYFACES-628) Current Lifecycle implementation violates JSF Spec 1.1
[ http://issues.apache.org/jira/browse/MYFACES-628?page=comments#action_12331129 ] Bill Dudney commented on MYFACES-628: - HI Ronald, The fix I put in on the 30th caused pages to stop drawing in the RC1. I have reverted part of the fix for this bug to get 657 resolved. Could you please take a look at the comments for 657 and test out the head of the 1.1.1 branch to make sure that this version works for your case. > Current Lifecycle implementation violates JSF Spec 1.1 > -- > > Key: MYFACES-628 > URL: http://issues.apache.org/jira/browse/MYFACES-628 > Project: MyFaces > Type: Bug > Components: JSR-127 > Versions: 1.1.0 > Reporter: Holger Schimanski > Assignee: Bill Dudney > Priority: Blocker > Fix For: 1.1.1 > > If a PhaseListener.beforePhase() calles FacesContext.renderResponse() or > FacesContext.responseComplete(), then the LifeCycleImpl should not execute > the functionality required for the current phase. (see JSF Spec 1.1 section > 11-1 page 296f.) LifeCycleImpl is not taking care about this. > This is important for us, because we'd like to make a redirect in the before > render response phase. And at the moment an Illegal State exception is > thrown, because the renderResponse is executed although responseComplete has > been called. -- 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-657) Blank page after switching to 1.1.1RC1
[ http://issues.apache.org/jira/browse/MYFACES-657?page=comments#action_12331128 ] Bill Dudney commented on MYFACES-657: - Ok I think I have it fixed. I'm seeing the proper stuff in the simple.war application. > Blank page after switching to 1.1.1RC1 > -- > > Key: MYFACES-657 > URL: http://issues.apache.org/jira/browse/MYFACES-657 > Project: MyFaces > Type: Bug > Versions: 1.1.1 > Environment: JDK 1.4 and Tomcat 5.0.x probably other versions affected as > well > Reporter: Werner Punz > Priority: Blocker > > There have been several reports of getting a blank page after people swithing > to the 1.1.1RC > The most detailed report comes from Wendy Smoak from the Struts and Struts > Shale project: > There are two reports on the user list that 1.1.1 is causing a previously > working app to just display a blank page. (Though they're talking about > myfaces-all.jar, and I'm having trouble with the api & impl pair.) > All of the example webapps display blank pages on Tomcat 5.0.30 and JDK > 1.4.2_09. > If it helps at all, I've posted the debug logs from the Shale Use Cases app > with 1.1.1 as well as the 20051002 nightly build (which uses the RI): > http://wiki.wsmoak.net/cgi-bin/wiki.pl?ShaleUseCases -- 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-657) Blank page after switching to 1.1.1RC1
[ http://issues.apache.org/jira/browse/MYFACES-657?page=comments#action_12331127 ] Bill Dudney commented on MYFACES-657: - This is the result of a fix I did for 628. I'm working on a solution right now. I think the problem is that I'm checking for both renderResponse and responseComplete (and returning if either have been called) but the method should only be returning if responseComplete was called. > Blank page after switching to 1.1.1RC1 > -- > > Key: MYFACES-657 > URL: http://issues.apache.org/jira/browse/MYFACES-657 > Project: MyFaces > Type: Bug > Versions: 1.1.1 > Environment: JDK 1.4 and Tomcat 5.0.x probably other versions affected as > well > Reporter: Werner Punz > Priority: Blocker > > There have been several reports of getting a blank page after people swithing > to the 1.1.1RC > The most detailed report comes from Wendy Smoak from the Struts and Struts > Shale project: > There are two reports on the user list that 1.1.1 is causing a previously > working app to just display a blank page. (Though they're talking about > myfaces-all.jar, and I'm having trouble with the api & impl pair.) > All of the example webapps display blank pages on Tomcat 5.0.30 and JDK > 1.4.2_09. > If it helps at all, I've posted the debug logs from the Shale Use Cases app > with 1.1.1 as well as the 20051002 nightly build (which uses the RI): > http://wiki.wsmoak.net/cgi-bin/wiki.pl?ShaleUseCases -- 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-623) setValue() method of ValueBindingImpl does not behave properly
[
http://issues.apache.org/jira/browse/MYFACES-623?page=comments#action_12331125
]
Bill Dudney commented on MYFACES-623:
-
Hi Oliver, I like the idea of moving the fix to ValueBindingImpl.setValue() but
I'm not sure that removing the coercion is the right thing.
Will there ever be a case where the converter is not invoked but coercion
should happen? If so I think removing this will cause reflection exceptions on
invocation of the set method. I guess we could then go fix where/when the
converter is not being called.
Thoughts?
> setValue() method of ValueBindingImpl does not behave properly
> --
>
> Key: MYFACES-623
> URL: http://issues.apache.org/jira/browse/MYFACES-623
> Project: MyFaces
> Type: Bug
> Components: JSR-127
> Versions: 1.1.0
> Reporter: sean schofield
> Assignee: Oliver Rossmueller
> Fix For: 1.1.1
> Attachments: MYFACES-623.patch
>
> According to section 5.1.4 of the specification (p. 5-4) ...
> If you have #{expr-a[value-b]} where value-a is a Map then ...
> call value-a.put(value-b, newValue).
> The MyFaces implementation is coercing newValue into String which is
> incorrect behavior.
> NOTE: I discovered the problem while using a bean that was programatically
> added to the session map. So there is is no class defined in
> faces-config.xml. I don't think this should matter but I thought I would
> mention it.
--
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-628) Current Lifecycle implementation violates JSF Spec 1.1
[ http://issues.apache.org/jira/browse/MYFACES-628?page=all ] Bill Dudney closed MYFACES-628: --- Resolution: Fixed Ok, now I think its really fixed. Please take look at it and let me know. > Current Lifecycle implementation violates JSF Spec 1.1 > -- > > Key: MYFACES-628 > URL: http://issues.apache.org/jira/browse/MYFACES-628 > Project: MyFaces > Type: Bug > Components: JSR-127 > Versions: 1.1.0 > Reporter: Holger Schimanski > Assignee: Bill Dudney > Priority: Blocker > Fix For: 1.1.1 > > If a PhaseListener.beforePhase() calles FacesContext.renderResponse() or > FacesContext.responseComplete(), then the LifeCycleImpl should not execute > the functionality required for the current phase. (see JSF Spec 1.1 section > 11-1 page 296f.) LifeCycleImpl is not taking care about this. > This is important for us, because we'd like to make a redirect in the before > render response phase. And at the moment an Illegal State exception is > thrown, because the renderResponse is executed although responseComplete has > been called. -- 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-628) Current Lifecycle implementation violates JSF Spec 1.1
[ http://issues.apache.org/jira/browse/MYFACES-628?page=all ] Bill Dudney reopened MYFACES-628: - Sorry I did not get everythign the first time... When you say you want to know its about looking at a log not programatically correct? > Current Lifecycle implementation violates JSF Spec 1.1 > -- > > Key: MYFACES-628 > URL: http://issues.apache.org/jira/browse/MYFACES-628 > Project: MyFaces > Type: Bug > Components: JSR-127 > Versions: 1.1.0 > Reporter: Holger Schimanski > Assignee: Bill Dudney > Priority: Blocker > Fix For: 1.1.1 > > If a PhaseListener.beforePhase() calles FacesContext.renderResponse() or > FacesContext.responseComplete(), then the LifeCycleImpl should not execute > the functionality required for the current phase. (see JSF Spec 1.1 section > 11-1 page 296f.) LifeCycleImpl is not taking care about this. > This is important for us, because we'd like to make a redirect in the before > render response phase. And at the moment an Illegal State exception is > thrown, because the renderResponse is executed although responseComplete has > been called. -- 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-633) forceId in t:panelGrid does not work propertly
[ http://issues.apache.org/jira/browse/MYFACES-633?page=all ] Bill Dudney closed MYFACES-633: --- Resolution: Fixed closed based on Travis' last comment > forceId in t:panelGrid does not work propertly > -- > > Key: MYFACES-633 > URL: http://issues.apache.org/jira/browse/MYFACES-633 > Project: MyFaces > Type: Bug > Components: Tomahawk > Versions: 1.1.0 > Reporter: Travis Reeder > > It outputs a parent child relationship, for example: > > > will generate an id like: > > Where _id9 is the containing . There are other containing panelGrids > that are not prepended to the id so maybe it's just the form tag. -- 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: (MYFACES-628) Current Lifecycle implementation violates JSF Spec 1.1
[ http://issues.apache.org/jira/browse/MYFACES-628?page=all ] Bill Dudney resolved MYFACES-628: - Fix Version: 1.1.1 Resolution: Fixed fix for this bug is on the branch along with a cactus test > Current Lifecycle implementation violates JSF Spec 1.1 > -- > > Key: MYFACES-628 > URL: http://issues.apache.org/jira/browse/MYFACES-628 > Project: MyFaces > Type: Bug > Components: JSR-127 > Versions: 1.1.0 > Reporter: Holger Schimanski > Assignee: Bill Dudney > Priority: Blocker > Fix For: 1.1.1 > > If a PhaseListener.beforePhase() calles FacesContext.renderResponse() or > FacesContext.responseComplete(), then the LifeCycleImpl should not execute > the functionality required for the current phase. (see JSF Spec 1.1 section > 11-1 page 296f.) LifeCycleImpl is not taking care about this. > This is important for us, because we'd like to make a redirect in the before > render response phase. And at the moment an Illegal State exception is > thrown, because the renderResponse is executed although responseComplete has > been called. -- 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: (MYFACES-623) setValue() method of ValueBindingImpl does not behave properly
[ http://issues.apache.org/jira/browse/MYFACES-623?page=all ]
Bill Dudney resolved MYFACES-623:
-
Fix Version: 1.1.1
Resolution: Fixed
Added the fix for this to the branch since I had the tests there. We still need
comments on the 'null' type being returned for properties in a map.
> setValue() method of ValueBindingImpl does not behave properly
> --
>
> Key: MYFACES-623
> URL: http://issues.apache.org/jira/browse/MYFACES-623
> Project: MyFaces
> Type: Bug
> Components: JSR-127
> Versions: 1.1.0
> Reporter: sean schofield
> Assignee: Bill Dudney
> Fix For: 1.1.1
> Attachments: MYFACES-623.patch
>
> According to section 5.1.4 of the specification (p. 5-4) ...
> If you have #{expr-a[value-b]} where value-a is a Map then ...
> call value-a.put(value-b, newValue).
> The MyFaces implementation is coercing newValue into String which is
> incorrect behavior.
> NOTE: I discovered the problem while using a bean that was programatically
> added to the session map. So there is is no class defined in
> faces-config.xml. I don't think this should matter but I thought I would
> mention it.
--
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-628) Current Lifecycle implementation violates JSF Spec 1.1
[ http://issues.apache.org/jira/browse/MYFACES-628?page=comments#action_12330690 ] Bill Dudney commented on MYFACES-628: - I think I have this fixed, testing now. Holger - will you be able to test it out in your app with the RC that Sean will put out later in the week? Thanks! > Current Lifecycle implementation violates JSF Spec 1.1 > -- > > Key: MYFACES-628 > URL: http://issues.apache.org/jira/browse/MYFACES-628 > Project: MyFaces > Type: Bug > Components: JSR-127 > Versions: 1.1.0 > Reporter: Holger Schimanski > Priority: Blocker > > If a PhaseListener.beforePhase() calles FacesContext.renderResponse() or > FacesContext.responseComplete(), then the LifeCycleImpl should not execute > the functionality required for the current phase. (see JSF Spec 1.1 section > 11-1 page 296f.) LifeCycleImpl is not taking care about this. > This is important for us, because we'd like to make a redirect in the before > render response phase. And at the moment an Illegal State exception is > thrown, because the renderResponse is executed although responseComplete has > been called. -- 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-623) setValue() method of ValueBindingImpl does not behave properly
[
http://issues.apache.org/jira/browse/MYFACES-623?page=comments#action_12330661
]
Bill Dudney commented on MYFACES-623:
-
So do we want this fix in the branch? Also does anyone see an issue with this
proposed fix?
> setValue() method of ValueBindingImpl does not behave properly
> --
>
> Key: MYFACES-623
> URL: http://issues.apache.org/jira/browse/MYFACES-623
> Project: MyFaces
> Type: Bug
> Components: JSR-127
> Versions: 1.1.0
> Reporter: sean schofield
> Attachments: MYFACES-623.patch
>
> According to section 5.1.4 of the specification (p. 5-4) ...
> If you have #{expr-a[value-b]} where value-a is a Map then ...
> call value-a.put(value-b, newValue).
> The MyFaces implementation is coercing newValue into String which is
> incorrect behavior.
> NOTE: I discovered the problem while using a bean that was programatically
> added to the session map. So there is is no class defined in
> faces-config.xml. I don't think this should matter but I thought I would
> mention it.
--
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-623) setValue() method of ValueBindingImpl does not behave properly
[
http://issues.apache.org/jira/browse/MYFACES-623?page=comments#action_12330652
]
Bill Dudney commented on MYFACES-623:
-
OK, I've found the problem but I'm not sure there is an easy fix.
getType on PropertyResolverImpl returns String (since that is what is in the
Map currently) which is returned to the ValueBindingImpl on line 269. Which is
passed to the coerce method. That is in turn invoking a coersion to String on
the Foo object (via org.apache.commons.el.Coercions.coerce). I think that is
calling toString on the object passed in.
I think we could return null from the PropertyResolverImpl.getType method if
the 'base' is a Map since a Map will accept any type and does not need to have
things converted. If a null type is passed into coerce on the ValueBindingImpl
it will simply return the value passed in (Foo in Sean's case and the Integer
in the test above).
Thoughts?
> setValue() method of ValueBindingImpl does not behave properly
> --
>
> Key: MYFACES-623
> URL: http://issues.apache.org/jira/browse/MYFACES-623
> Project: MyFaces
> Type: Bug
> Components: JSR-127
> Versions: 1.1.0
> Reporter: sean schofield
> Attachments: MYFACES-623.patch
>
> According to section 5.1.4 of the specification (p. 5-4) ...
> If you have #{expr-a[value-b]} where value-a is a Map then ...
> call value-a.put(value-b, newValue).
> The MyFaces implementation is coercing newValue into String which is
> incorrect behavior.
> NOTE: I discovered the problem while using a bean that was programatically
> added to the session map. So there is is no class defined in
> faces-config.xml. I don't think this should matter but I thought I would
> mention it.
--
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-623) setValue() method of ValueBindingImpl does not behave properly
[
http://issues.apache.org/jira/browse/MYFACES-623?page=comments#action_12330646
]
Bill Dudney commented on MYFACES-623:
-
Hi Sean,
I think I've found a reproducable test case;
public void testSetValueSimpleBeanInRequestMapWithInitialValue() {
Map map = new HashMap();
String initialValue = "hello world";
map.put("baz", initialValue);
TestBean bean = new TestBean(map);
facesContext.getExternalContext().getRequestMap().put("bean",
bean);
ValueBinding binding =
application.createValueBinding("#{bean.map['baz']}");
assertEquals(initialValue, binding.getValue(facesContext));
Integer value = new Integer(14);
binding.setValue(facesContext, value);
assertEquals(14,
((Integer)binding.getValue(facesContext)).intValue());
}
thows a class cast exception on the final assert.
> setValue() method of ValueBindingImpl does not behave properly
> --
>
> Key: MYFACES-623
> URL: http://issues.apache.org/jira/browse/MYFACES-623
> Project: MyFaces
> Type: Bug
> Components: JSR-127
> Versions: 1.1.0
> Reporter: sean schofield
> Attachments: MYFACES-623.patch
>
> According to section 5.1.4 of the specification (p. 5-4) ...
> If you have #{expr-a[value-b]} where value-a is a Map then ...
> call value-a.put(value-b, newValue).
> The MyFaces implementation is coercing newValue into String which is
> incorrect behavior.
> NOTE: I discovered the problem while using a bean that was programatically
> added to the session map. So there is is no class defined in
> faces-config.xml. I don't think this should matter but I thought I would
> mention it.
--
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-623) setValue() method of ValueBindingImpl does not behave properly
[
http://issues.apache.org/jira/browse/MYFACES-623?page=comments#action_12330644
]
Bill Dudney commented on MYFACES-623:
-
Sean,
looking at the patch it seems to have something to do with the converter.
this test;
public void testSetValueSimpleBeanInRequestMapWithInitialValue() {
Map map = new HashMap();
String initialValue = "hello world";
map.put("baz", initialValue);
TestBean bean = new TestBean(map);
facesContext.getExternalContext().getRequestMap().put("bean",
bean);
ValueBinding binding =
application.createValueBinding("#{bean.map['baz']}");
assertEquals(initialValue, binding.getValue(facesContext));
Integer value = new Integer(14);
binding.setValue(facesContext, value);
assertEquals(14, value.intValue());
}
passes.
This test is getting the value through the ValueBinding before setting it to an
integer.
What else am I missing in the test besides a converter?
I'll do that next.
> setValue() method of ValueBindingImpl does not behave properly
> --
>
> Key: MYFACES-623
> URL: http://issues.apache.org/jira/browse/MYFACES-623
> Project: MyFaces
> Type: Bug
> Components: JSR-127
> Versions: 1.1.0
> Reporter: sean schofield
> Attachments: MYFACES-623.patch
>
> According to section 5.1.4 of the specification (p. 5-4) ...
> If you have #{expr-a[value-b]} where value-a is a Map then ...
> call value-a.put(value-b, newValue).
> The MyFaces implementation is coercing newValue into String which is
> incorrect behavior.
> NOTE: I discovered the problem while using a bean that was programatically
> added to the session map. So there is is no class defined in
> faces-config.xml. I don't think this should matter but I thought I would
> mention it.
--
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-623) setValue() method of ValueBindingImpl does not behave properly
[
http://issues.apache.org/jira/browse/MYFACES-623?page=comments#action_12330633
]
Bill Dudney commented on MYFACES-623:
-
Hi Sean,
I can't repeat this error in a cactus test.
All three of these tests pass;
public void testSetValueSimpleMap() {
facesContext.getExternalContext().getRequestMap().put("foo",
new HashMap());
ValueBinding binding =
application.createValueBinding("#{foo['baz']}");
Integer value = new Integer(14);
binding.setValue(facesContext, value);
assertEquals(14, value.intValue());
}
public void testSetValueSimpleBeanInRequestMap() {
TestBean bean = new TestBean(new HashMap());
facesContext.getExternalContext().getRequestMap().put("bean",
bean);
ValueBinding binding =
application.createValueBinding("#{bean.map['baz']}");
Integer value = new Integer(14);
binding.setValue(facesContext, value);
assertEquals(14, value.intValue());
}
public void testSetValueSimpleBeanInSessionMap() {
TestBean bean = new TestBean(new HashMap());
facesContext.getExternalContext().getSessionMap().put("bean",
bean);
ValueBinding binding =
application.createValueBinding("#{bean.map['baz']}");
Integer value = new Integer(14);
binding.setValue(facesContext, value);
assertEquals(14, value.intValue());
}
Am I not doing something that you are?
> setValue() method of ValueBindingImpl does not behave properly
> --
>
> Key: MYFACES-623
> URL: http://issues.apache.org/jira/browse/MYFACES-623
> Project: MyFaces
> Type: Bug
> Components: JSR-127
> Versions: 1.1.0
> Reporter: sean schofield
>
> According to section 5.1.4 of the specification (p. 5-4) ...
> If you have #{expr-a[value-b]} where value-a is a Map then ...
> call value-a.put(value-b, newValue).
> The MyFaces implementation is coercing newValue into String which is
> incorrect behavior.
> NOTE: I discovered the problem while using a bean that was programatically
> added to the session map. So there is is no class defined in
> faces-config.xml. I don't think this should matter but I thought I would
> mention it.
--
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-629) Missing faces-config.xml from binary distribution's myfaces-all.jar
[ http://issues.apache.org/jira/browse/MYFACES-629?page=all ] Bill Dudney closed MYFACES-629: --- Resolution: Fixed This is a duplicate of #598. > Missing faces-config.xml from binary distribution's myfaces-all.jar > --- > > Key: MYFACES-629 > URL: http://issues.apache.org/jira/browse/MYFACES-629 > Project: MyFaces > Type: Bug > Components: General > Versions: 1.1.0 > Environment: all 1.1.0 binary packages > Reporter: Piotr Czerwinski > > the myfaces-all.jar does not contain faces-config.xml for tomahawk extensions. -- 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: (MYFACES-598) When building with -Dskip.sandbox=true the faces-config.xml is not included in the META-INF folder of the myfaces-all.jar
[ http://issues.apache.org/jira/browse/MYFACES-598?page=all ] Bill Dudney resolved MYFACES-598: - Fix Version: Nightly Build Resolution: Fixed updated the build.xml file to use the tomahawk/config/faces-config.xml file if the sandbox is excluded > When building with -Dskip.sandbox=true the faces-config.xml is not included > in the META-INF folder of the myfaces-all.jar > - > > Key: MYFACES-598 > URL: http://issues.apache.org/jira/browse/MYFACES-598 > Project: MyFaces > Type: Bug > Components: General > Versions: 1.1.0 > Reporter: Bruno Aranda > Assignee: Bill Dudney > Priority: Minor > Fix For: Nightly Build > > ant -Dskip.sandbox=true is supposed to build myfaces without the sandbox > components, but if you use pass that variable to ant, the file > faces-config.xml which contains the tomahawk components is not included in > the myfaces-all.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] Reopened: (MYFACES-118) inputCalendar RenderAsPopup fails: Duplicate ID
[ http://issues.apache.org/jira/browse/MYFACES-118?page=all ] Bill Dudney reopened MYFACES-118: - Assign To: Bill Dudney (was: Martin Marinschek) I agree, section 3.1.1 states that the components should be unique and if we are not forcing that then we probably should be. I'd be glad to take this on as a test case (pun intended) for the cactus tests. I'll introduce a cactus test that reproduces the bug then fix it. > inputCalendar RenderAsPopup fails: Duplicate ID > --- > > Key: MYFACES-118 > URL: http://issues.apache.org/jira/browse/MYFACES-118 > Project: MyFaces > Type: Bug > Versions: 1.0.8 beta > Environment: Windows 2003, OC4J (10.1.3.0.0) - Developer Preview 3 or Tomcat > 5.5.7, JSF 1.1, JSP 2.0, MyFaces 1.0.8 beta > Reporter: Norbert Csík > Assignee: Bill Dudney > Fix For: Nightly Build > Attachments: go.jspx > > I have JSP Document with an f:view and an x:inputCalendar element. When the > inputCalendar's RenderAsPopup attribute is set to true the page display fails > with the message (myca is the id of the inputCalendar component): > 500 Internal Server Error > javax.servlet.jsp.JspException: Duplicate component ID '_id0:myca' found in > view. at > com.sun.faces.taglib.jsf_core.ViewTag.doAfterBody(ViewTag.java:171) at > _go_2e_jspx._jspService(go.jspx:24) [/go.jspx] > Rendering with RenderAsPopup set to false is okay. -- 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-146) latest build of extensions jar doesn't include Tag classes
[ http://issues.apache.org/jira/browse/MYFACES-146?page=comments#action_61530 ] Bill Dudney commented on MYFACES-146: - Hi Hal, Just want to make sure I understand. From the thread thus far it sounds like some classes referenced in the TLD are not being included in the jar file. For example; foo org.apache.myfaces.foo ... ... bar org.apache.myfaces.bar ... bar is in the jar but foo is not? So WL81 is complaining that bar can not be found? > latest build of extensions jar doesn't include Tag classes > -- > > Key: MYFACES-146 > URL: http://issues.apache.org/jira/browse/MYFACES-146 > Project: MyFaces > Type: Bug > Versions: Nightly Build > Reporter: Hal Deadman > > I was trying to use the regexp validator in from the extensions jar. This > meant I needed to use the tag and Weblogic complained > that it couldn't find other tag classes referenced in the x tld. I added the > following to build script and was able to use the validators I wanted. > includes="org/apache/myfaces/taglib/**/*.class"/> > Index: build.xml > === > RCS file: /home/cvspublic/incubator-myfaces/build/build.xml,v > retrieving revision 1.87 > diff -u -r1.87 build.xml > --- build.xml 22 Mar 2005 06:59:42 - 1.87 > +++ build.xml 23 Mar 2005 00:42:50 - > @@ -235,6 +235,8 @@ > includes="**/*.class"/> > includes="**/*.class"/> > + + includes="org/apache/myfaces/taglib/**/*.class"/> > > >includes="myfaces_ext.tld,myfaces_ext_sf.tld" -- 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
