Re: Release Checklist
Thanks Sean again for your hard work. I will have a look at the release plan, and I will play around with generating the release notes from JIRA. regards, Martin On 8/25/05, Sean Schofield <[EMAIL PROTECTED]> wrote: > I know everybody is getting anxious for a release soon. I've put > together a simple wiki checklist of the steps I feel we need to do for > the release (http://wiki.apache.org/myfaces/MyFaces_1%2e0%2e10.) > Please take a moment to review it. > > Its not really a formal release plan like Struts has but we are ASF > noobs and sadly, are testing procedures are very lacking. Bill got us > off to a nice start with some unit tests. Hopefully we can follow up > on that in the future. We have to be realistic about what we can > achieve and how long it will take us to get to where we ultimately > want to be. So I'm ok with releasing based on my modest checklist > which I believe contains the essential elements. > > I hope to make progress on several of these items over the next few > days. We are gearing up for another release at my day job so time is > scarce right now. One area where someone could help is with the > release notes (they can and should be generated from JIRA). > > sean > -- http://www.irian.at Your JSF powerhouse - JSF Trainings in English and German
[jira] Closed: (MYFACES-427) In myfaces-all.jar, faces-config.xml doesn't include the content of the sandbox's faces-config.xml
[ http://issues.apache.org/jira/browse/MYFACES-427?page=all ] sean schofield closed MYFACES-427: -- Resolution: Fixed I'm going to close this one out for now. I still have a few more tweaks related to a new option to exclude sandbox stuff (for the release build) but everything works now as you have it. > In myfaces-all.jar, faces-config.xml doesn't include the content of the > sandbox's faces-config.xml > -- > > Key: MYFACES-427 > URL: http://issues.apache.org/jira/browse/MYFACES-427 > Project: MyFaces > Type: Bug > Components: General, Sandbox > Versions: Nightly Build > Reporter: Sylvain Vieujot > Assignee: sean schofield > -- 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-438) [tree2] Selected node is lost when navigating to another page
[ http://issues.apache.org/jira/browse/MYFACES-438?page=comments#action_12319961 ] sean schofield commented on MYFACES-438: @Mathias, I like option#1 (that was my long term plan for TreeState.) Why couldn't we just persist the selected node(s) with the component? We're already doing this for the expand info. I don't understand why a cookie would be needed. > [tree2] Selected node is lost when navigating to another page > - > > Key: MYFACES-438 > URL: http://issues.apache.org/jira/browse/MYFACES-438 > Project: MyFaces > Type: Bug > Components: Tomahawk > Versions: Nightly Build > Environment: Window 2000 pro, JSF, Sun RI, Nightly Build 09-Aug-2005 > Reporter: Marc Vandeloise > Assignee: sean schofield > > I have the preserveToggle=true which is supposed to keep the state > of the tree2 navigator when openning another page... but it always > collapse... > The issue still persist with Nightly Build 19-Aug-2005 > From: Sean Schofield <[EMAIL PROTECTED]> > --- > There was a recent change to tree2 that may have broken this feature. > Are you using a recent (with 7-10 days) version of the source code? > If so, then please file a JIRA issue. This is most likely a bug that > was introduced by the new TreeModel and TreeState interfaces. > sean > --- -- 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
Release Checklist
I know everybody is getting anxious for a release soon. I've put together a simple wiki checklist of the steps I feel we need to do for the release (http://wiki.apache.org/myfaces/MyFaces_1%2e0%2e10.) Please take a moment to review it. Its not really a formal release plan like Struts has but we are ASF noobs and sadly, are testing procedures are very lacking. Bill got us off to a nice start with some unit tests. Hopefully we can follow up on that in the future. We have to be realistic about what we can achieve and how long it will take us to get to where we ultimately want to be. So I'm ok with releasing based on my modest checklist which I believe contains the essential elements. I hope to make progress on several of these items over the next few days. We are gearing up for another release at my day job so time is scarce right now. One area where someone could help is with the release notes (they can and should be generated from JIRA). sean
[jira] Updated: (MYFACES-387) Myfaces with Tiles support not working properly under Java System Application Server 8.1
[ http://issues.apache.org/jira/browse/MYFACES-387?page=all ] Jin Chun Chong updated MYFACES-387: --- Attachment: Resolve.pdf Hi, I have managed to resolve the issue. The issue occurs because the sun java system app server itself has JSF Sun RI in the classpath, and also the commons-el.jar will cause the screen blank in sun java system app server (i have no idea why). To resolve it, 1) Remove any Sun RI reference from the app server. The attached is the steps of how i do it. 2) Remove commons-el.jar from the classpath > Myfaces with Tiles support not working properly under Java System > Application Server 8.1 > - > > Key: MYFACES-387 > URL: http://issues.apache.org/jira/browse/MYFACES-387 > Project: MyFaces > Type: Bug > Components: Tomahawk > Versions: 1.0.9 beta > Environment: Java System Application Server 8.1 (8_1_02_2005Q2); Windows XP > Reporter: Jin Chun Chong > Attachments: Resolve.pdf > > Myfaces with Tiles support not working properly under Java System > Application Server 8.1 (8_1_02_2005Q2). > Pages are not rendered properly. Tiles with jsp which uses jsf tags are not > rendered. > To recreate the error, deploy myfaces-tiles-example.war to Java System > Application Server 8.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-444) HtmlMessageRendererBase renders tooltip as message summary rather than detail
[
http://issues.apache.org/jira/browse/MYFACES-444?page=comments#action_12319949
]
Ken Weiner commented on MYFACES-444:
I forgot to mention that showDetail should be set to true in order for the
tooltip to be activated.
The code would then look like this (with the initialization of showDetail moved
up within the method):
String summary = getSummary(facesContext, message, facesMessage,
messageClientId);
String detail = getDetail(facesContext, message, facesMessage,
messageClientId);
boolean showSummary = isShowSummary(message) && (summary != null);
boolean showDetail = isShowDetail(message) && (detail != null);
String title = getTitle(message);
boolean tooltip = isTooltip(message);
if (tooltip && showDetail)
{
title = detail;
}
> HtmlMessageRendererBase renders tooltip as message summary rather than detail
> -
>
> Key: MYFACES-444
> URL: http://issues.apache.org/jira/browse/MYFACES-444
> Project: MyFaces
> Type: Bug
> Components: JSF 1.1
> Versions: 1.0.9 beta
> Reporter: Ken Weiner
>
> The tooltip attribute description on
> http://java.sun.com/j2ee/javaserverfaces/1.1/docs/tlddocs/h/message.html says
> that the tooltip content should be composed of the message detail text.
> However, the tooltip content in MyFaces is getting set to the message summary
> text. This happens in HtmlMessageRendererBase in the
> renderSingleFacesMessage() method. The code sets the title to the summary if
> the tooltip is enabled. Otherwise it uses the title attribute:
> String summary = getSummary(facesContext, message, facesMessage,
> messageClientId);
> String detail = getDetail(facesContext, message, facesMessage,
> messageClientId);
> String title = getTitle(message);
> boolean tooltip = isTooltip(message);
> if (title == null && tooltip)
> {
> title = summary;
> }
> Instead it should use the detail as follows:
> String summary = getSummary(facesContext, message, facesMessage,
> messageClientId);
> String detail = getDetail(facesContext, message, facesMessage,
> messageClientId);
> String title = getTitle(message);
> boolean tooltip = isTooltip(message);
> if (title == null && tooltip)
> {
> title = detail;
> }
> It might be argued that the tooltip should be set to the detail regardless of
> whether the title attribute is set at all since the description of the title
> attribute is "Advisory title information about markup elements generated for
> this component." If that is the case then the code should look like this:
> String summary = getSummary(facesContext, message, facesMessage,
> messageClientId);
> String detail = getDetail(facesContext, message, facesMessage,
> messageClientId);
> String title = getTitle(message);
> boolean tooltip = isTooltip(message);
> if (tooltip)
> {
> title = detail;
> }
--
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-444) HtmlMessageRendererBase renders tooltip as message summary rather than detail
HtmlMessageRendererBase renders tooltip as message summary rather than detail
-
Key: MYFACES-444
URL: http://issues.apache.org/jira/browse/MYFACES-444
Project: MyFaces
Type: Bug
Components: JSF 1.1
Versions: 1.0.9 beta
Reporter: Ken Weiner
The tooltip attribute description on
http://java.sun.com/j2ee/javaserverfaces/1.1/docs/tlddocs/h/message.html says
that the tooltip content should be composed of the message detail text.
However, the tooltip content in MyFaces is getting set to the message summary
text. This happens in HtmlMessageRendererBase in the
renderSingleFacesMessage() method. The code sets the title to the summary if
the tooltip is enabled. Otherwise it uses the title attribute:
String summary = getSummary(facesContext, message, facesMessage,
messageClientId);
String detail = getDetail(facesContext, message, facesMessage,
messageClientId);
String title = getTitle(message);
boolean tooltip = isTooltip(message);
if (title == null && tooltip)
{
title = summary;
}
Instead it should use the detail as follows:
String summary = getSummary(facesContext, message, facesMessage,
messageClientId);
String detail = getDetail(facesContext, message, facesMessage,
messageClientId);
String title = getTitle(message);
boolean tooltip = isTooltip(message);
if (title == null && tooltip)
{
title = detail;
}
It might be argued that the tooltip should be set to the detail regardless of
whether the title attribute is set at all since the description of the title
attribute is "Advisory title information about markup elements generated for
this component." If that is the case then the code should look like this:
String summary = getSummary(facesContext, message, facesMessage,
messageClientId);
String detail = getDetail(facesContext, message, facesMessage,
messageClientId);
String title = getTitle(message);
boolean tooltip = isTooltip(message);
if (tooltip)
{
title = detail;
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
Re: t:span tag
For really new components, I agree with you, but this one as really nothing new or experimental. So I prefer to postpone it because adding it to the sandbox means I'll have to change all the prefixes if I use it. ... for a convenient tag, this isn't very convenient. P.S. As for the doc, it's exactly the same as for t:div, with div->span replacements. On Wed, 2005-08-24 at 18:43 -0400, Sean Schofield wrote: should put this in sandbox. There's no real difference except for to be in tomahawk we need example, docs, etc. I have a couple of these I'd like to add too but I think they go in sandbox as well (ex. t:fieldset) We're trying to get a release ready so I'm -1 for new components no matter how simple they appear to be. Also, we should try and hold off on modifcations (other than bug fixes) to tomahawk for the next few weeks until we can get a release out the door. We don't want to introduce new last minute bugs related to nice-to-have features. sean
Re: t:span tag
-1 for tomahawk.
We should put this in sandbox. There's no real difference except for
to be in tomahawk we need example, docs, etc. I have a couple of
these I'd like to add too but I think they go in sandbox as well (ex.
t:fieldset)
We're trying to get a release ready so I'm -1 for new components no
matter how simple they appear to be.
Also, we should try and hold off on modifcations (other than bug
fixes) to tomahawk for the next few weeks until we can get a release
out the door. We don't want to introduce new last minute bugs related
to nice-to-have features.
sean
On 8/24/05, Sylvain Vieujot <[EMAIL PROTECTED]> wrote:
> I'd like to add a new convenient t:span tag directly to tomahawk.
> It's a rather "risk-free" tag, because as the t:div, it'll extend
> t:htmlTag, with only one method :
>public Object getValue() {
> return "span";
>}
>
> If nobody objects, I'll do this in the next days.
>
> Thanks,
>
> Sylvain.
t:span tag
I'd like to add a new convenient t:span tag directly to tomahawk.
It's a rather "risk-free" tag, because as the t:div, it'll extend t:htmlTag, with only one method :
public Object getValue() {
return "span";
}
If nobody objects, I'll do this in the next days.
Thanks,
Sylvain.
[jira] Created: (MYFACES-443) javax.faces.render.Renderer.encodeChildren() should encode children
javax.faces.render.Renderer.encodeChildren() should encode children --- Key: MYFACES-443 URL: http://issues.apache.org/jira/browse/MYFACES-443 Project: MyFaces Type: Bug Components: JSF 1.1 Versions: 1.0.9 beta Reporter: Ken Weiner I noticed a difference in behavior between MyFaces and the Sun RI in javax.faces.render.Renderer.encodeChildren(). The RI iterates though the children and renders them in succession whereas MyFaces simply asserts that the method arguments are non-null and returns, leaving the optional rendering of the children to the subclasses of Renderer. I am not 100% sure which behavior is correct, but it seems like the spec, in section 8.2 and 3.1.12, indicates that the encodeChildren() method should do the work of creating the response data for each child. As things are now, there is the potential that someone using the RI could develop a renderer that doesn't override encodeChildren(), expecting the children of his/her component to render. When this person switches to MyFaces, his/her component will not render its children anymore. This discussion on the MyFaces Users mailing list led to me submitting this as an issue: http://www.mail-archive.com/users%40myfaces.apache.org/msg07461.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] Commented: (MYFACES-237) x:inputDate and popupCalendar problem
[ http://issues.apache.org/jira/browse/MYFACES-237?page=comments#action_12319864 ] Sylvain Vieujot commented on MYFACES-237: - Did you check with a recent build ? Because I had the problem too, but it seems that it has been corrected recently. > x:inputDate and popupCalendar problem > - > > Key: MYFACES-237 > URL: http://issues.apache.org/jira/browse/MYFACES-237 > Project: MyFaces > Type: Bug > Versions: 1.0.9 beta > Environment: win xp , jsdk 1.4.2_05 > Reporter: Tomasz Bandura > Assignee: Martin Marinschek > Priority: Trivial > > When I use x:inputDate it looks good, popup works, calendar looks fine > but after popup it throws errors ( javax.servlet.error.status_code : 404 ) > 'javax.servlet.error.request_uri', for : > /jscalendar/jscalendar-DB/drop2.gif > /jscalendar/jscalendar-DB/drop1.gif > /jscalendar/jscalendar-DB/left1.gif > /jscalendar/jscalendar-DB/left2.gif > /jscalendar/jscalendar-DB/right1.gif > /jscalendar/jscalendar-DB/right2.gif > I don't mind it but problem occures when i try to catch error 404 > on page header there are : > href="//faces/myFacesExtensionResource/calendar.HtmlCalendarRenderer/1114410789000/WH/theme.css" > type="text/css"/> > href="//faces/myFacesExtensionResource/calendar.HtmlCalendarRenderer/1114410789000/DB/theme.css" > type="text/css"/> > src="//faces/myFacesExtensionResource/calendar.HtmlCalendarRenderer/1114410789000/popcalendar.js" > type="text/javascript"> > regards > tomasz -- 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-442) logs an error when columns parameter not specified
[ http://issues.apache.org/jira/browse/MYFACES-442?page=comments#action_12319860 ] Martin Marinschek commented on MYFACES-442: --- to be precise: builds from August 21, 2005 on should not have this problem in them. regards, Martin > logs an error when columns parameter not specified > > > Key: MYFACES-442 > URL: http://issues.apache.org/jira/browse/MYFACES-442 > Project: MyFaces > Type: Bug > Components: JSF 1.1 > Versions: Nightly Build > Environment: Running MyFaces JSF with Tomahawk components under WebSphere. > Using the nightly build from August 15, 2005. > Reporter: Brendan Conner > Assignee: Martin Marinschek > Priority: Minor > Fix For: Nightly Build > > If I don't specify the number of columns explicitly in my tag, > the following error message gets displayed at runtime on the console: > [8/24/05 10:22:59:335 CDT] 42dd42dd HtmlGridRende E > org.apache.myfaces.renderkit.html.HtmlGridRendererBase Wrong columns > attribute for PanelGrid mainSubview:mainForm:_id11: -2147483648 > The page appears to render correctly (i.e., it defaults to columns="1"), but > the error message is annoying. -- 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-442) logs an error when columns parameter not specified
[ http://issues.apache.org/jira/browse/MYFACES-442?page=comments#action_12319859 ] Martin Marinschek commented on MYFACES-442: --- In the latest nightly build this is fixed ;) regards, Martin > logs an error when columns parameter not specified > > > Key: MYFACES-442 > URL: http://issues.apache.org/jira/browse/MYFACES-442 > Project: MyFaces > Type: Bug > Components: JSF 1.1 > Versions: Nightly Build > Environment: Running MyFaces JSF with Tomahawk components under WebSphere. > Using the nightly build from August 15, 2005. > Reporter: Brendan Conner > Assignee: Martin Marinschek > Priority: Minor > > If I don't specify the number of columns explicitly in my tag, > the following error message gets displayed at runtime on the console: > [8/24/05 10:22:59:335 CDT] 42dd42dd HtmlGridRende E > org.apache.myfaces.renderkit.html.HtmlGridRendererBase Wrong columns > attribute for PanelGrid mainSubview:mainForm:_id11: -2147483648 > The page appears to render correctly (i.e., it defaults to columns="1"), but > the error message is annoying. -- 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-442) logs an error when columns parameter not specified
[ http://issues.apache.org/jira/browse/MYFACES-442?page=all ] Martin Marinschek closed MYFACES-442: - Fix Version: Nightly Build Resolution: Fixed > logs an error when columns parameter not specified > > > Key: MYFACES-442 > URL: http://issues.apache.org/jira/browse/MYFACES-442 > Project: MyFaces > Type: Bug > Components: JSF 1.1 > Versions: Nightly Build > Environment: Running MyFaces JSF with Tomahawk components under WebSphere. > Using the nightly build from August 15, 2005. > Reporter: Brendan Conner > Assignee: Martin Marinschek > Priority: Minor > Fix For: Nightly Build > > If I don't specify the number of columns explicitly in my tag, > the following error message gets displayed at runtime on the console: > [8/24/05 10:22:59:335 CDT] 42dd42dd HtmlGridRende E > org.apache.myfaces.renderkit.html.HtmlGridRendererBase Wrong columns > attribute for PanelGrid mainSubview:mainForm:_id11: -2147483648 > The page appears to render correctly (i.e., it defaults to columns="1"), but > the error message is annoying. -- 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-441) CLONE -HTML Renderkit doesn't choose correct ContentType (JavaScript)
[ http://issues.apache.org/jira/browse/MYFACES-441?page=comments#action_12319858 ] Jacob Hookom commented on MYFACES-441: -- Great! Thanks a ton! > CLONE -HTML Renderkit doesn't choose correct ContentType (JavaScript) > - > > Key: MYFACES-441 > URL: http://issues.apache.org/jira/browse/MYFACES-441 > Project: MyFaces > Type: Bug > Components: JSF 1.1 > Versions: 1.0.9 beta > Environment: Tomcat, FireFox/Mozilla Browser > Reporter: Jacob Hookom > Assignee: Martin Marinschek > Priority: Critical > Fix For: Nightly Build > > The contract between ViewHandler and RenderKit for creating a ResponseWriter > is that the ViewHandler should suggest a list of supported contentTypes. It > is the RenderKit's job to pick the appropriate one based on it's output-- not > just any of them. > In the case of Firefox, the first item it sends is 'text/xml, ', the > HtmlRenderKit in MyFaces just says, use the first item returned, so the > response is set to be contentType of 'text/xml'. > This causes issues since the browser gets a response, renders it, but treats > the content with comments as XML-- so that means the css isn't used, > and commented JavaScript isn't seen. > This is a major blocker. -- 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-376) HTML Renderkit doesn't choose correct ContentType
[ http://issues.apache.org/jira/browse/MYFACES-376?page=comments#action_12319856 ] Martin Marinschek commented on MYFACES-376: --- fixed anew (see clone MYFACES-441) > HTML Renderkit doesn't choose correct ContentType > - > > Key: MYFACES-376 > URL: http://issues.apache.org/jira/browse/MYFACES-376 > Project: MyFaces > Type: Bug > Components: JSF 1.1 > Versions: 1.0.9 beta > Environment: Tomcat, FireFox/Mozilla Browser > Reporter: Jacob Hookom > Assignee: Martin Marinschek > Priority: Critical > Fix For: Nightly Build > > The contract between ViewHandler and RenderKit for creating a ResponseWriter > is that the ViewHandler should suggest a list of supported contentTypes. It > is the RenderKit's job to pick the appropriate one based on it's output-- not > just any of them. > In the case of Firefox, the first item it sends is 'text/xml, ', the > HtmlRenderKit in MyFaces just says, use the first item returned, so the > response is set to be contentType of 'text/xml'. > This causes issues since the browser gets a response, renders it, but treats > the content with comments as XML-- so that means the css isn't used, > and commented JavaScript isn't seen. > This is a major blocker. -- 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-441) CLONE -HTML Renderkit doesn't choose correct ContentType (JavaScript)
[ http://issues.apache.org/jira/browse/MYFACES-441?page=all ] Martin Marinschek closed MYFACES-441: - Resolution: Fixed This should finally be done. We should still work on text/xml/xhtml support in any case. > CLONE -HTML Renderkit doesn't choose correct ContentType (JavaScript) > - > > Key: MYFACES-441 > URL: http://issues.apache.org/jira/browse/MYFACES-441 > Project: MyFaces > Type: Bug > Components: JSF 1.1 > Versions: 1.0.9 beta > Environment: Tomcat, FireFox/Mozilla Browser > Reporter: Jacob Hookom > Assignee: Martin Marinschek > Priority: Critical > Fix For: Nightly Build > > The contract between ViewHandler and RenderKit for creating a ResponseWriter > is that the ViewHandler should suggest a list of supported contentTypes. It > is the RenderKit's job to pick the appropriate one based on it's output-- not > just any of them. > In the case of Firefox, the first item it sends is 'text/xml, ', the > HtmlRenderKit in MyFaces just says, use the first item returned, so the > response is set to be contentType of 'text/xml'. > This causes issues since the browser gets a response, renders it, but treats > the content with comments as XML-- so that means the css isn't used, > and commented JavaScript isn't seen. > This is a major blocker. -- 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-441) CLONE -HTML Renderkit doesn't choose correct ContentType (JavaScript)
[ http://issues.apache.org/jira/browse/MYFACES-441?page=comments#action_12319854 ] Martin Marinschek commented on MYFACES-441: --- Yes. What a mess. Get me my xhtml compliant components ;) regards, Martin > CLONE -HTML Renderkit doesn't choose correct ContentType (JavaScript) > - > > Key: MYFACES-441 > URL: http://issues.apache.org/jira/browse/MYFACES-441 > Project: MyFaces > Type: Bug > Components: JSF 1.1 > Versions: 1.0.9 beta > Environment: Tomcat, FireFox/Mozilla Browser > Reporter: Jacob Hookom > Assignee: Martin Marinschek > Priority: Critical > Fix For: Nightly Build > > The contract between ViewHandler and RenderKit for creating a ResponseWriter > is that the ViewHandler should suggest a list of supported contentTypes. It > is the RenderKit's job to pick the appropriate one based on it's output-- not > just any of them. > In the case of Firefox, the first item it sends is 'text/xml, ', the > HtmlRenderKit in MyFaces just says, use the first item returned, so the > response is set to be contentType of 'text/xml'. > This causes issues since the browser gets a response, renders it, but treats > the content with comments as XML-- so that means the css isn't used, > and commented JavaScript isn't seen. > This is a major blocker. -- 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-441) CLONE -HTML Renderkit doesn't choose correct ContentType (JavaScript)
[ http://issues.apache.org/jira/browse/MYFACES-441?page=comments#action_12319853 ] Jacob Hookom commented on MYFACES-441: -- If the renderkit is going to allow a content type of "xhtml", then it needs to produce "xhtml" compliant JavaScript, which I don't believe it's able to at this point. You are probably safe returning "text/html" everytime until your renderkit is fully xhtml compliant for all built-in components. Cheers! > CLONE -HTML Renderkit doesn't choose correct ContentType (JavaScript) > - > > Key: MYFACES-441 > URL: http://issues.apache.org/jira/browse/MYFACES-441 > Project: MyFaces > Type: Bug > Components: JSF 1.1 > Versions: 1.0.9 beta > Environment: Tomcat, FireFox/Mozilla Browser > Reporter: Jacob Hookom > Assignee: Martin Marinschek > Priority: Critical > Fix For: Nightly Build > > The contract between ViewHandler and RenderKit for creating a ResponseWriter > is that the ViewHandler should suggest a list of supported contentTypes. It > is the RenderKit's job to pick the appropriate one based on it's output-- not > just any of them. > In the case of Firefox, the first item it sends is 'text/xml, ', the > HtmlRenderKit in MyFaces just says, use the first item returned, so the > response is set to be contentType of 'text/xml'. > This causes issues since the browser gets a response, renders it, but treats > the content with comments as XML-- so that means the css isn't used, > and commented JavaScript isn't seen. > This is a major blocker. -- 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-442) logs an error when columns parameter not specified
logs an error when columns parameter not specified Key: MYFACES-442 URL: http://issues.apache.org/jira/browse/MYFACES-442 Project: MyFaces Type: Bug Components: JSF 1.1 Versions: Nightly Build Environment: Running MyFaces JSF with Tomahawk components under WebSphere. Using the nightly build from August 15, 2005. Reporter: Brendan Conner Priority: Minor If I don't specify the number of columns explicitly in my tag, the following error message gets displayed at runtime on the console: [8/24/05 10:22:59:335 CDT] 42dd42dd HtmlGridRende E org.apache.myfaces.renderkit.html.HtmlGridRendererBase Wrong columns attribute for PanelGrid mainSubview:mainForm:_id11: -2147483648 The page appears to render correctly (i.e., it defaults to columns="1"), but the error message is annoying. -- 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-441) CLONE -HTML Renderkit doesn't choose correct ContentType (JavaScript)
CLONE -HTML Renderkit doesn't choose correct ContentType (JavaScript) - Key: MYFACES-441 URL: http://issues.apache.org/jira/browse/MYFACES-441 Project: MyFaces Type: Bug Components: JSF 1.1 Versions: 1.0.9 beta Environment: Tomcat, FireFox/Mozilla Browser Reporter: Jacob Hookom Assigned to: Martin Marinschek Priority: Critical Fix For: Nightly Build The contract between ViewHandler and RenderKit for creating a ResponseWriter is that the ViewHandler should suggest a list of supported contentTypes. It is the RenderKit's job to pick the appropriate one based on it's output-- not just any of them. In the case of Firefox, the first item it sends is 'text/xml, ', the HtmlRenderKit in MyFaces just says, use the first item returned, so the response is set to be contentType of 'text/xml'. This causes issues since the browser gets a response, renders it, but treats the content with comments as XML-- so that means the css isn't used, and commented JavaScript isn't seen. This is a major blocker. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: myfaces debugging with Eclipse
Fab Psycho wrote: Hi Werner, Thanks for explanation, it works that way ... But I think it would be interesting to have an additionnal myfaces build.xml entry such as build wardebug building the four war files with sources included ... That way, we could deploy a war in tomcat, declare project in eclipse and that's it, we can debug live on simple-examples for instance ... that patch could be useful for other IDE as well ... Not a good idea ? Best regards, Fabian Interesting idea but not that easy in combination with eclipse, most webapp plugins I know would probably semi choke on such a construct because they require an entire local webapp structure within your project to work to their full extent. Myeclipse comes to my mind, Exadel the second plugin collection I use is even less forgiving by forcing the webcontent dir to a special name. such a build system probably would have to setup a plugin compatible build structure as well... hence it is probably easier to have a root webapp project and add the needed sources by the means you have.
Re: myfaces debugging with Eclipse
Sean is our build expert, so if you get him to introduce something like that (or let you introduce it via a patch), you are all set! regards, Martin On 8/24/05, Fab Psycho <[EMAIL PROTECTED]> wrote: > Hi Werner, > > Thanks for explanation, it works that way ... But I think it would be > interesting to have an additionnal myfaces build.xml entry such as build > wardebug building the four war files with sources included ... That way, we > could deploy a war in tomcat, declare project in eclipse and that's it, we > can debug live on simple-examples for instance ... that patch could be > useful for other IDE as well ... Not a good idea ? > > Best regards, > Fabian > > > >From: Werner Punz <[EMAIL PROTECTED]> > >Reply-To: [EMAIL PROTECTED] > >To: dev@myfaces.apache.org > >Subject: Re: myfaces debugging with Eclipse > >Date: Wed, 24 Aug 2005 13:11:52 +0200 > > > >Fab Psycho wrote: > >>Hi, > >> > >> I'd like to understand how inputDate works and see it through > >>eclipse debugger. > >>I already tried debugging from a project put in tomcat path having a > >>breakpoint in my bean and it works but this time, I'd like to debug let's > >>say through myfaces-simple-examples.war ... Is it possible to put a > >>breakpoint in my svn myfaces/current project and launch a debug telling > >>eclipse deployement path or something ? > >> > >Hi Fabian, sorry, I did not have time to add that documentation to the wiki > >(by friday, my time hopefully will be better for other works than my job) > > > >You basically can do it, by using myeclipse as a subproject and add the > >affected source paths, be sure however that you have a myeclipse jar in > >your lib path. > > > >The other way is to simply dump the affected classes into your sourcepath, > >either way should work without too much hazzle, did some debugging of 1.0.9 > >code that way. > > > >Werner > > > > > -- http://www.irian.at Your JSF powerhouse - JSF Trainings in English and German
Re: myfaces debugging with Eclipse
Hi Werner, Thanks for explanation, it works that way ... But I think it would be interesting to have an additionnal myfaces build.xml entry such as build wardebug building the four war files with sources included ... That way, we could deploy a war in tomcat, declare project in eclipse and that's it, we can debug live on simple-examples for instance ... that patch could be useful for other IDE as well ... Not a good idea ? Best regards, Fabian From: Werner Punz <[EMAIL PROTECTED]> Reply-To: [EMAIL PROTECTED] To: dev@myfaces.apache.org Subject: Re: myfaces debugging with Eclipse Date: Wed, 24 Aug 2005 13:11:52 +0200 Fab Psycho wrote: Hi, I'd like to understand how inputDate works and see it through eclipse debugger. I already tried debugging from a project put in tomcat path having a breakpoint in my bean and it works but this time, I'd like to debug let's say through myfaces-simple-examples.war ... Is it possible to put a breakpoint in my svn myfaces/current project and launch a debug telling eclipse deployement path or something ? Hi Fabian, sorry, I did not have time to add that documentation to the wiki (by friday, my time hopefully will be better for other works than my job) You basically can do it, by using myeclipse as a subproject and add the affected source paths, be sure however that you have a myeclipse jar in your lib path. The other way is to simply dump the affected classes into your sourcepath, either way should work without too much hazzle, did some debugging of 1.0.9 code that way. Werner
Re: myfaces debugging with Eclipse
Feel free to add it to the official docs ;-) Sean Schofield wrote: That's some nice documentation (I never checked it out before as I have no problems in this area.) Nice job wiki users! sean On 8/23/05, Martin Marinschek <[EMAIL PROTECTED]> wrote: Best thing is you follow these instructions, and do not use the war files at all: http://wiki.apache.org/myfaces/Building_MyFaces_in_your_IDE regards, Martin On 8/23/05, Fab Psycho <[EMAIL PROTECTED]> wrote: Martin, I don't see 'war including source' production from global builder.Maybe a build/build-debug.xml would be interesting ? Best regards, Fabian From: Martin Marinschek <[EMAIL PROTECTED]> Reply-To: [EMAIL PROTECTED] To: MyFaces Development Subject: Re: myfaces debugging with Eclipse Date: Tue, 23 Aug 2005 09:05:46 +0200 I don't know about Eclipse, it sure works in IntelliJ though. You need to attach the sources to your war files in IntelliJ for doing this. regards, Martin On 8/23/05, Fab Psycho <[EMAIL PROTECTED]> wrote: Hi, I'd like to understand how inputDate works and see it through eclipse debugger. I already tried debugging from a project put in tomcat path having a breakpoint in my bean and it works but this time, I'd like to debug let's say through myfaces-simple-examples.war ... Is it possible to put a breakpoint in my svn myfaces/current project and launch a debug telling eclipse deployement path or something ? Best regards, Fabian -- http://www.irian.at Your JSF powerhouse - JSF Trainings in English and German -- http://www.irian.at Your JSF powerhouse - JSF Trainings in English and German
[jira] Commented: (MYFACES-237) x:inputDate and popupCalendar problem
[ http://issues.apache.org/jira/browse/MYFACES-237?page=comments#action_12319837 ] Tomasz Bandura commented on MYFACES-237: Hi, I tried inputCalendar - the same problem occurs. best regards tomasz > x:inputDate and popupCalendar problem > - > > Key: MYFACES-237 > URL: http://issues.apache.org/jira/browse/MYFACES-237 > Project: MyFaces > Type: Bug > Versions: 1.0.9 beta > Environment: win xp , jsdk 1.4.2_05 > Reporter: Tomasz Bandura > Assignee: Sylvain Vieujot > Priority: Trivial > > When I use x:inputDate it looks good, popup works, calendar looks fine > but after popup it throws errors ( javax.servlet.error.status_code : 404 ) > 'javax.servlet.error.request_uri', for : > /jscalendar/jscalendar-DB/drop2.gif > /jscalendar/jscalendar-DB/drop1.gif > /jscalendar/jscalendar-DB/left1.gif > /jscalendar/jscalendar-DB/left2.gif > /jscalendar/jscalendar-DB/right1.gif > /jscalendar/jscalendar-DB/right2.gif > I don't mind it but problem occures when i try to catch error 404 > on page header there are : > href="//faces/myFacesExtensionResource/calendar.HtmlCalendarRenderer/1114410789000/WH/theme.css" > type="text/css"/> > href="//faces/myFacesExtensionResource/calendar.HtmlCalendarRenderer/1114410789000/DB/theme.css" > type="text/css"/> > src="//faces/myFacesExtensionResource/calendar.HtmlCalendarRenderer/1114410789000/popcalendar.js" > type="text/javascript"> > regards > tomasz -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: myfaces debugging with Eclipse
Fab Psycho wrote: Hi, I'd like to understand how inputDate works and see it through eclipse debugger. I already tried debugging from a project put in tomcat path having a breakpoint in my bean and it works but this time, I'd like to debug let's say through myfaces-simple-examples.war ... Is it possible to put a breakpoint in my svn myfaces/current project and launch a debug telling eclipse deployement path or something ? Hi Fabian, sorry, I did not have time to add that documentation to the wiki (by friday, my time hopefully will be better for other works than my job) You basically can do it, by using myeclipse as a subproject and add the affected source paths, be sure however that you have a myeclipse jar in your lib path. The other way is to simply dump the affected classes into your sourcepath, either way should work without too much hazzle, did some debugging of 1.0.9 code that way. Werner
[jira] Created: (MYFACES-440) Circular dependencies in managed properties lead to StackOverflowError in VariableResolverImpl
Circular dependencies in managed properties lead to StackOverflowError in
VariableResolverImpl
--
Key: MYFACES-440
URL: http://issues.apache.org/jira/browse/MYFACES-440
Project: MyFaces
Type: Bug
Components: General
Versions: Nightly Build
Environment: N/A
Reporter: Erik-Berndt Scheper
Circular dependencies in managed properties lead to
java.lang.StackOverflowError in class
org.apache.myfaces.el.VariableResolverImpl.
This can be reproduced with a simple example:
... start snippet from faces-config ...
organisationListController
nl.ibgroep.demo.web.bean.controller.beheer.OrganisationListController
session
organisationDetailsController
nl.ibgroep.demo.web.bean.controller.beheer.OrganisationDetailsController
#{organisationDetailsController}
organisationDetailsController
nl.ibgroep.demo.web.bean.controller.beheer.OrganisationDetailsController
session
organisationListController
nl.ibgroep.demo.web.bean.controller.beheer.OrganisationListController
#{organisationListController}
... end snippet from faces-config ...
If I open a page using either of these managed beans, a StackOverflowError
error occurs in VariableResolverImpl.
The reason is that a new managed bean is put in scope after the complete
managed bean has been created, including all dependent managed properties. So
what happens is that the first managed bean (organisationListController) is
created, Subsequently a new bean for its managed property
(organisationDetailsController) is created. Because the first bean
(organisationListController) was not put in scope, a new managed bean
(organisationListController) is created, which leads to the creation of another
bean (organisationDetailsController), etc.
In this simple example the cause is easy to find out, but this will be less so
if the circular dependency becomes less obvious.
Solution: put the bean in scope in the ManagedBeanBuilder, before the recursive
creation of its managed properties.
--
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
