[jira] Created: (MYFACES-932) CLONE -Action crashes application
CLONE -Action crashes application - Key: MYFACES-932 URL: http://issues.apache.org/jira/browse/MYFACES-932 Project: MyFaces Type: Bug Environment: Geronimo 1.0M5 with Tomcat as servlet container Reporter: Olexandr Zakordonskyy Priority: Blocker When action that returns forward null executes, I got duplicate id exception. -- 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-932) CLONE -Action crashes application
[ http://issues.apache.org/jira/browse/MYFACES-932?page=comments#action_12360204 ] Olexandr Zakordonskyy commented on MYFACES-932: --- Please close this issue. It's not a problem of Myfaces it's problem of Tobago. CLONE -Action crashes application - Key: MYFACES-932 URL: http://issues.apache.org/jira/browse/MYFACES-932 Project: MyFaces Type: Bug Environment: Geronimo 1.0M5 with Tomcat as servlet container Reporter: Olexandr Zakordonskyy Priority: Blocker When action that returns forward null executes, I got duplicate id exception. -- 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-933) Tobago Crash under Geronimo 1.0M5 after action execution.
Tobago Crash under Geronimo 1.0M5 after action execution. - Key: MYFACES-933 URL: http://issues.apache.org/jira/browse/MYFACES-933 Project: MyFaces Type: Bug Components: Tobago Environment: Geronimo 1.0M5 with Tomcat as servlet container Reporter: Olexandr Zakordonskyy When action that returns forward null executes, I got duplicate id exception. Try attached application, based on tobago-blank-example. Under Tomcat this application works fine, but under Geronimo 1.0 M5 it is crashed. I tried to create analogical application based on myfaces without Tobago and it works fine. -- 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-934) Parsing UserData in org.apache.myfaces.custom.date.HtmlInputDate.UserData throws java.lang.NumberFormatException, not java.text.ParseException
Parsing UserData in org.apache.myfaces.custom.date.HtmlInputDate.UserData
throws java.lang.NumberFormatException, not java.text.ParseException
--
Key: MYFACES-934
URL: http://issues.apache.org/jira/browse/MYFACES-934
Project: MyFaces
Type: Bug
Components: Tomahawk
Versions: 1.1.1, Nightly
Environment: windows, java 1.5.0_05, tomcat 5.5
Reporter: Ulf Helmke
Priority: Minor
Hello,
The UserData.parse method declares to throw aParseException. But it never
throws a ParseException, the Integer.parseInt throws a NumberFormatException
instead:
public Date parse() throws ParseException{
Calendar tempCalendar=Calendar.getInstance();
if (timeZone != null)
tempCalendar.setTimeZone(timeZone);
tempCalendar.set(Calendar.DAY_OF_MONTH,Integer.parseInt(day));
tempCalendar.set(Calendar.MONTH,Integer.parseInt(month)-1);
tempCalendar.set(Calendar.YEAR,Integer.parseInt(year));
if (uses_ampm) {
int int_hours = Integer.parseInt(hours);
// ampm hours must be in range 0-11 to be handled right; we
have to handle 12 specially
if (int_hours == 12) {
int_hours = 0;
}
tempCalendar.set(Calendar.HOUR,int_hours);
tempCalendar.set(Calendar.AM_PM,Integer.parseInt(ampm));
} else {
tempCalendar.set(Calendar.HOUR_OF_DAY,Integer.parseInt(hours));
}
tempCalendar.set(Calendar.MINUTE,Integer.parseInt(minutes));
tempCalendar.set(Calendar.SECOND,Integer.parseInt(seconds));
tempCalendar.set(Calendar.MILLISECOND, 0);
return tempCalendar.getTime();
}
The most simple approach to solve it: Catch the NumberFormatException inside
the parse method and throw a new ParseException:
public Date parse() throws ParseException{
Calendar tempCalendar=Calendar.getInstance();
if (timeZone != null)
tempCalendar.setTimeZone(timeZone);
try {
tempCalendar.set(Calendar.DAY_OF_MONTH,Integer.parseInt(day));
tempCalendar.set(Calendar.MONTH,Integer.parseInt(month)-1);
tempCalendar.set(Calendar.YEAR,Integer.parseInt(year));
if (uses_ampm) {
int int_hours = Integer.parseInt(hours);
// ampm hours must be in range 0-11 to
be handled right; we have to handle 12 specially
if (int_hours == 12) {
int_hours = 0;
}
tempCalendar.set(Calendar.HOUR,int_hours);
tempCalendar.set(Calendar.AM_PM,Integer.parseInt(ampm));
} else {
tempCalendar.set(Calendar.HOUR_OF_DAY,Integer.parseInt(hours));
}
tempCalendar.set(Calendar.MINUTE,Integer.parseInt(minutes));
tempCalendar.set(Calendar.SECOND,Integer.parseInt(seconds));
tempCalendar.set(Calendar.MILLISECOND, 0);
} catch (NumberFormatException e) {
throw new ParseException(e.getMessage(),0);
}
return tempCalendar.getTime();
}
It would be a good idea to write some new tests. The existing Tests do not deal
with invalid form data.
Greetings Ulf
--
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-591) f:param causes rendering of seperator in t:panelNavigation
[ http://issues.apache.org/jira/browse/MYFACES-591?page=comments#action_12360209 ] Jesper Pedersen commented on MYFACES-591: - I'm having the same problem and I would like to see this issue fixed. But I can't find a developer guide on our site - is there some information on how to get started with code ? I'm thinking on class organization, how the components are put together and so on. The build and SVN instructions are ok. Basically how do I start to look for the f:param (standard tag) in t:panelNavigation (custom tag) ? f:param causes rendering of seperator in t:panelNavigation -- Key: MYFACES-591 URL: http://issues.apache.org/jira/browse/MYFACES-591 Project: MyFaces Type: Bug Components: Tomahawk Versions: 1.1.0 Reporter: Mads Peter Henderson A seperator is rendered for hidden elements such as an f:param inside a t:commandNavigation element of the panelNavigation component. This has previously been reported and fixed (can't find that bug report) but has been reintroduced sometime after august 1st. this year. Thanks madsph -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MYFACES-933) Tobago Crash under Geronimo 1.0M5 after action execution.
[ http://issues.apache.org/jira/browse/MYFACES-933?page=all ] Olexandr Zakordonskyy updated MYFACES-933: -- Attachment: test.war Tobago Crash under Geronimo 1.0M5 after action execution. - Key: MYFACES-933 URL: http://issues.apache.org/jira/browse/MYFACES-933 Project: MyFaces Type: Bug Components: Tobago Environment: Geronimo 1.0M5 with Tomcat as servlet container Reporter: Olexandr Zakordonskyy Attachments: test.war When action that returns forward null executes, I got duplicate id exception. Try attached application, based on tobago-blank-example. Under Tomcat this application works fine, but under Geronimo 1.0 M5 it is crashed. I tried to create analogical application based on myfaces without Tobago and it works fine. -- 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-921) NullPointerException using inputSuggestAjax with Facelets
[ http://issues.apache.org/jira/browse/MYFACES-921?page=comments#action_12360216 ] Mike Kienenberger commented on MYFACES-921: --- I haven't looked at InputSuggestAjax, but my guess is that suggestedItemsMethod takes a method binding. You'll need to create a Facelets tag handler to assign a method binding to the component since it's not possible for facelets to determine that information automatically (the method signature can vary even if the attribute name is known). It's pretty simple to do this. You can find an example of creating such a tag handler for the GraphicImageDynamic component at this url: http://wiki.java.net/bin/view/Projects/FaceletsTaglibsMyfacesSandbox Please update that wiki with an example for InputSuggestAjax after you get it working. NullPointerException using inputSuggestAjax with Facelets - Key: MYFACES-921 URL: http://issues.apache.org/jira/browse/MYFACES-921 Project: MyFaces Type: Bug Components: Sandbox Versions: Nightly Reporter: Peter Mahoney The following exception is generated using inputSuggestAjax with Facelets: 005-12-09 11:08:58,776 ERROR [localhost].[/webmail].[FacesServlet]:253 http-8080-Processor25 - Servlet.service() for servlet FacesServlet threw exception java.lang.NullPointerException at org.apache.myfaces.custom.inputsuggestajax.InputSuggestAjaxRenderer.encodeAjax(InputSuggestAjaxRenderer.java:209) It appears that InputSuggestAjaxTag uses its setSuggestedItemsMethodProperty method to set the suggestedItemsMethod property in the component, rather than this being carried out by the component itself. -- 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-921) NullPointerException using inputSuggestAjax with Facelets
[ http://issues.apache.org/jira/browse/MYFACES-921?page=all ]
Mike Kienenberger closed MYFACES-921:
-
Resolution: Invalid
InputSuggestAjaxTag is pretty trivial. There's some code in there to create a
MethodBinding, but that's it. You'll need to do the same thing in the
facelets tag handler. The only tricky part is that the method signature
changes based on the value of maxSuggestedItems, which is unfortunate. If you
can't make this conditional statement work with facelets, submit a patch and
I'll review it.
if (((InputSuggestAjax)component).getMaxSuggestedItems()!=null)
{
MethodBinding mb =
context.getApplication().createMethodBinding(suggestedItemsMethod,new
Class[]{String.class, Integer.class});
((InputSuggestAjax)component).setSuggestedItemsMethod(mb);
} else {
MethodBinding mb =
context.getApplication().createMethodBinding(suggestedItemsMethod,new
Class[]{String.class});
((InputSuggestAjax)component).setSuggestedItemsMethod(mb);
}
However, there's no bug here, so I'm marking this as invalid and closing it.
NullPointerException using inputSuggestAjax with Facelets
-
Key: MYFACES-921
URL: http://issues.apache.org/jira/browse/MYFACES-921
Project: MyFaces
Type: Bug
Components: Sandbox
Versions: Nightly
Reporter: Peter Mahoney
The following exception is generated using inputSuggestAjax with Facelets:
005-12-09 11:08:58,776 ERROR [localhost].[/webmail].[FacesServlet]:253
http-8080-Processor25 - Servlet.service() for servlet FacesServlet threw
exception
java.lang.NullPointerException
at
org.apache.myfaces.custom.inputsuggestajax.InputSuggestAjaxRenderer.encodeAjax(InputSuggestAjaxRenderer.java:209)
It appears that InputSuggestAjaxTag uses its setSuggestedItemsMethodProperty
method to set the suggestedItemsMethod property in the component, rather than
this being carried out by the component itself.
--
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-936) Resource bundle key name
[ http://issues.apache.org/jira/browse/MYFACES-936?page=all ] Volker Weber closed MYFACES-936: Resolution: Invalid It is not possible to have a dot (.) in a var name of a resourceBundle. This can't work in any jsf implementation because the lookup is done by standart valueBinding resolving. I have added http://issues.apache.org/jira/browse/MYFACES-937 to add a check for this. Resource bundle key name Key: MYFACES-936 URL: http://issues.apache.org/jira/browse/MYFACES-936 Project: MyFaces Type: Bug Components: Tobago Reporter: Olexandr Zakordonskyy Can't use naming like com.company.resourceKey = , because exception is thrown: javax.faces.el.PropertyNotFoundException: Bean: java.lang.String, property: company at org.apache.myfaces.el.PropertyResolverImpl.getPropertyDescriptor(PropertyResolverImpl.java:445) at org.apache.myfaces.el.PropertyResolverImpl.getPropertyDescriptor(PropertyResolverImpl.java:416) at org.apache.myfaces.el.PropertyResolverImpl.getProperty(PropertyResolverImpl.java:379) at org.apache.myfaces.el.PropertyResolverImpl.getValue(PropertyResolverImpl.java:71) at org.apache.myfaces.el.ELParserHelper$MyPropertySuffix.evaluate(ELParserHelper.java:532) at org.apache.commons.el.ComplexValue.evaluate(ComplexValue.java:145) at org.apache.commons.el.ExpressionString.evaluate(ExpressionString.java:114) at org.apache.myfaces.el.ValueBindingImpl.getValue(ValueBindingImpl.java:380) at javax.faces.component._ComponentAttributesMap.get(_ComponentAttributesMap.java:138) at org.apache.myfaces.tobago.renderkit.html.scarborough.standard.tag.ButtonRenderer.createOnClick(ButtonRenderer.java:147) at org.apache.myfaces.tobago.renderkit.html.scarborough.standard.tag.ToolBarRenderer.createOnClick(ToolBarRenderer.java:400) at org.apache.myfaces.tobago.renderkit.html.scarborough.standard.tag.ToolBarRenderer.renderToolbarCommand(ToolBarRenderer.java:134) at org.apache.myfaces.tobago.renderkit.html.scarborough.standard.tag.ToolBarRenderer.encodeEndTobago(ToolBarRenderer.java:93) at org.apache.myfaces.tobago.renderkit.RendererBase.encodeEnd(RendererBase.java:146) at javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:331) at org.apache.myfaces.tobago.renderkit.RenderUtil.encode(RenderUtil.java:93) at org.apache.myfaces.tobago.renderkit.html.scarborough.standard.tag.GridLayoutRenderer.encodeChildrenOfComponent(GridLayoutRenderer.java:266) at org.apache.myfaces.tobago.component.UILayout.encodeChildrenOfComponent(UILayout.java:73) at org.apache.myfaces.tobago.component.UIGridLayout.encodeChildrenOfComponent(UIGridLayout.java:71) at org.apache.myfaces.tobago.component.UIPanel.encodeChildren(UIPanel.java:41) at org.apache.myfaces.tobago.renderkit.RenderUtil.encode(RenderUtil.java:85) at org.apache.myfaces.tobago.renderkit.html.scarborough.standard.tag.GridLayoutRenderer.encodeChildrenOfComponent(GridLayoutRenderer.java:266) at org.apache.myfaces.tobago.component.UILayout.encodeChildrenOfComponent(UILayout.java:73) at org.apache.myfaces.tobago.component.UIGridLayout.encodeChildrenOfComponent(UIGridLayout.java:71) at org.apache.myfaces.tobago.component.UIPanel.encodeChildren(UIPanel.java:41) at org.apache.myfaces.tobago.renderkit.RenderUtil.encode(RenderUtil.java:85) at org.apache.myfaces.tobago.renderkit.html.scarborough.standard.tag.GridLayoutRenderer.encodeChildrenOfComponent(GridLayoutRenderer.java:266) at org.apache.myfaces.tobago.component.UILayout.encodeChildrenOfComponent(UILayout.java:73) at org.apache.myfaces.tobago.component.UIGridLayout.encodeChildrenOfComponent(UIGridLayout.java:71) at org.apache.myfaces.tobago.component.UIPanel.encodeChildren(UIPanel.java:41) at org.apache.myfaces.tobago.renderkit.RenderUtil.encode(RenderUtil.java:85) at org.apache.myfaces.tobago.renderkit.html.scarborough.standard.tag.DefaultLayoutRenderer.encodeChildrenOfComponent(DefaultLayoutRenderer.java:54) at org.apache.myfaces.tobago.component.UILayout.encodeChildrenOfComponent(UILayout.java:73) at org.apache.myfaces.tobago.component.UIPanel.encodeChildren(UIPanel.java:41) at org.apache.myfaces.tobago.renderkit.RenderUtil.encode(RenderUtil.java:85) at org.apache.myfaces.tobago.renderkit.html.scarborough.standard.tag.GridLayoutRenderer.encodeChildrenOfComponent(GridLayoutRenderer.java:266) at org.apache.myfaces.tobago.component.UILayout.encodeChildrenOfComponent(UILayout.java:73) at org.apache.myfaces.tobago.component.UIGridLayout.encodeChildrenOfComponent(UIGridLayout.java:71)
[jira] Created: (MYFACES-938) implement 'fixed' in width calculation of panel renderers
implement 'fixed' in width calculation of panel renderers - Key: MYFACES-938 URL: http://issues.apache.org/jira/browse/MYFACES-938 Project: MyFaces Type: Bug Components: Tobago Reporter: Volker Weber Assigned to: Volker Weber -- 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-939) Add default values for calendar popup size
Add default values for calendar popup size -- Key: MYFACES-939 URL: http://issues.apache.org/jira/browse/MYFACES-939 Project: MyFaces Type: Bug Components: Tobago Reporter: Volker Weber set default values for width and height of calendar popups in theme-config-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
[jira] Resolved: (MYFACES-929) LoadBundleTag$BundleMapWrapper.equals
[ http://issues.apache.org/jira/browse/MYFACES-929?page=all ] Bernd Bohmann resolved MYFACES-929: --- Resolution: Fixed LoadBundleTag$BundleMapWrapper.equals - Key: MYFACES-929 URL: http://issues.apache.org/jira/browse/MYFACES-929 Project: MyFaces Type: Bug Components: Tobago Environment: Geronimo 1.0M5, Jetty container(default) Reporter: Olexandr Zakordonskyy Assignee: Bernd Bohmann My application crashes, because: Unsupported operationException. Thread [SocketListener0-9] (Suspended (exception UnsupportedOperationException)) LoadBundleTag$BundleMapWrapper.equals(Object) line: 115 HashSessionManager$Session(AbstractSessionManager$Session).setAttribute(String, Object) line: 805 SessionMap.setAttribute(String, Object) line: 50 SessionMap(AbstractAttributeMap).put(Object, Object) line: 104 LoadBundleTag.doStartTag() line: 50 page.tag line: 4 page.tag line: not available page.tag line: 3 login.jsp line: 5 login.jsp line: 5 login_jsp(HttpJspBase).service(HttpServletRequest, HttpServletResponse) line: 97 login_jsp(HttpServlet).service(ServletRequest, ServletResponse) line: 688 JspServletWrapper.service(HttpServletRequest, HttpServletResponse, boolean) line: 322 JspServlet.serviceJspFile(HttpServletRequest, HttpServletResponse, String, Throwable, boolean) line: 291 JspServlet.service(HttpServletRequest, HttpServletResponse) line: 241 JspServlet(HttpServlet).service(ServletRequest, ServletResponse) line: 688 JettyServletHolder(ServletHolder).handle(ServletRequest, ServletResponse) line: 427 JettyServletHolder.handle(ServletRequest, ServletResponse) line: 99 WebApplicationHandler$CachedChain.doFilter(ServletRequest, ServletResponse) line: 832 JSR154Filter.doFilter(ServletRequest, ServletResponse, FilterChain) line: 171 WebApplicationHandler$CachedChain.doFilter(ServletRequest, ServletResponse) line: 823 WebApplicationHandler.dispatch(String, HttpServletRequest, HttpServletResponse, ServletHolder, int) line: 473 Dispatcher.dispatch(ServletRequest, ServletResponse, int) line: 272 Dispatcher.forward(ServletRequest, ServletResponse) line: 169 ServletExternalContextImpl.dispatch(String) line: 415 JspViewHandlerImpl.renderView(FacesContext, UIViewRoot) line: 234 ViewHandlerImpl.renderView(FacesContext, UIViewRoot) line: 116 ViewHandler(ViewHandlerImpl).renderView(FacesContext, UIViewRoot) line: 116 LifecycleImpl.render(FacesContext) line: 300 FacesServlet.service(ServletRequest, ServletResponse) line: 95 JettyServletHolder(ServletHolder).handle(ServletRequest, ServletResponse) line: 427 JettyServletHolder.handle(ServletRequest, ServletResponse) line: 99 WebApplicationHandler$CachedChain.doFilter(ServletRequest, ServletResponse) line: 832 JSR154Filter.doFilter(ServletRequest, ServletResponse, FilterChain) line: 171 WebApplicationHandler$CachedChain.doFilter(ServletRequest, ServletResponse) line: 823 WebApplicationHandler.dispatch(String, HttpServletRequest, HttpServletResponse, ServletHolder, int) line: 473 Dispatcher.dispatch(ServletRequest, ServletResponse, int) line: 272 Dispatcher.forward(ServletRequest, ServletResponse) line: 169 RulesEngine.doForward(Forward, HttpServletRequest, HttpServletResponse) line: 67 RulesEngine.doForward(HttpServletRequest, HttpServletResponse) line: 52 RESTFilter.doFilter(ServletRequest, ServletResponse, FilterChain) line: 183 WebApplicationHandler$CachedChain.doFilter(ServletRequest, ServletResponse) line: 823 JSR154Filter.doFilter(ServletRequest, ServletResponse, FilterChain) line: 171 WebApplicationHandler$CachedChain.doFilter(ServletRequest, ServletResponse) line: 823 WebApplicationHandler.dispatch(String, HttpServletRequest, HttpServletResponse, ServletHolder, int) line: 473 WebApplicationHandler(ServletHandler).handle(String, String, HttpRequest, HttpResponse) line: 567 JettyWebAppContext(HttpContext).handle(String, String, HttpRequest, HttpResponse) line: 1565 JettyWebAppContext(WebApplicationContext).handle(String, String, HttpRequest, HttpResponse) line: 635 JettyWebAppContext(HttpContext).handle(HttpRequest, HttpResponse) line: 1517 JettyServer(HttpServer).service(HttpRequest, HttpResponse) line: 954 HttpConnection.service(HttpRequest, HttpResponse) line: 816 HttpConnection.handleNext() line: 983 HttpConnection.handle() line: 833 SocketListener.handleConnection(Socket) line: 244 SocketListener(ThreadedServer).handle(Object) line: 357 ThreadPool$PoolThread.run() line: 534 I think, you shold
[jira] Commented: (MYFACES-933) Tobago Crash under Geronimo 1.0M5 after action execution.
[ http://issues.apache.org/jira/browse/MYFACES-933?page=comments#action_12360231 ] Bernd Bohmann commented on MYFACES-933: --- Please add the exception to the issue. Tobago Crash under Geronimo 1.0M5 after action execution. - Key: MYFACES-933 URL: http://issues.apache.org/jira/browse/MYFACES-933 Project: MyFaces Type: Bug Components: Tobago Environment: Geronimo 1.0M5 with Tomcat as servlet container Reporter: Olexandr Zakordonskyy Attachments: test.war When action that returns forward null executes, I got duplicate id exception. Try attached application, based on tobago-blank-example. Under Tomcat this application works fine, but under Geronimo 1.0 M5 it is crashed. I tried to create analogical application based on myfaces without Tobago and it works fine. -- 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: [jira] Updated: (MYFACES-920) Avoid invoking value-bindings during component initialisation
One slightly better way to get more eyes on an issue is to file it in the JSF spec project on www.java.net. Then it'll go off to the full dev list, and will be officially tracked. That said, it's rather unlikely that anything will happen for JSF 1.2. At this point, it'd have to be a rather critical issue (and, like I said, without numbers, it's hard to prove that it is critical.) Cheers, Adam On 12/11/05, Simon Kitching [EMAIL PROTECTED] wrote: Adam Winer wrote: Fair enough, but as with most performance questions. actual numbers are of the essence. I've had thoroughly brilliant (so I thought) insights into how to make code faster that, after measuring, didn't do a darn thing. And since you're adding memory allocations (which, at higher server loads, will decrease performance), you'd want to see a convincing improvement. I'd be happy to *not* have to do this hack. If the JSF spec would provide some method to set an attribute without getting the old value returned that would be far better (hint, hint). I've sent a request through to the [EMAIL PROTECTED] address on 7-dec to change the API so this hack isn't necessary but not got any response so far. Cheers, Simon
[jira] Commented: (MYFACES-936) Resource bundle key name
[
http://issues.apache.org/jira/browse/MYFACES-936?page=comments#action_12360239
]
Adam Winer commented on MYFACES-936:
Strictly speaking, this is not illegal (at least not for f:loadBundle). You
could reference such vars with #{requestScope['org.apache.resource']}. That
said, such resource names are certainly a poor approach.
Resource bundle key name
Key: MYFACES-936
URL: http://issues.apache.org/jira/browse/MYFACES-936
Project: MyFaces
Type: Bug
Components: Tobago
Reporter: Olexandr Zakordonskyy
Can't use naming like com.company.resourceKey = , because exception is
thrown:
javax.faces.el.PropertyNotFoundException: Bean: java.lang.String, property:
company
at
org.apache.myfaces.el.PropertyResolverImpl.getPropertyDescriptor(PropertyResolverImpl.java:445)
at
org.apache.myfaces.el.PropertyResolverImpl.getPropertyDescriptor(PropertyResolverImpl.java:416)
at
org.apache.myfaces.el.PropertyResolverImpl.getProperty(PropertyResolverImpl.java:379)
at
org.apache.myfaces.el.PropertyResolverImpl.getValue(PropertyResolverImpl.java:71)
at
org.apache.myfaces.el.ELParserHelper$MyPropertySuffix.evaluate(ELParserHelper.java:532)
at org.apache.commons.el.ComplexValue.evaluate(ComplexValue.java:145)
at
org.apache.commons.el.ExpressionString.evaluate(ExpressionString.java:114)
at
org.apache.myfaces.el.ValueBindingImpl.getValue(ValueBindingImpl.java:380)
at
javax.faces.component._ComponentAttributesMap.get(_ComponentAttributesMap.java:138)
at
org.apache.myfaces.tobago.renderkit.html.scarborough.standard.tag.ButtonRenderer.createOnClick(ButtonRenderer.java:147)
at
org.apache.myfaces.tobago.renderkit.html.scarborough.standard.tag.ToolBarRenderer.createOnClick(ToolBarRenderer.java:400)
at
org.apache.myfaces.tobago.renderkit.html.scarborough.standard.tag.ToolBarRenderer.renderToolbarCommand(ToolBarRenderer.java:134)
at
org.apache.myfaces.tobago.renderkit.html.scarborough.standard.tag.ToolBarRenderer.encodeEndTobago(ToolBarRenderer.java:93)
at
org.apache.myfaces.tobago.renderkit.RendererBase.encodeEnd(RendererBase.java:146)
at
javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:331)
at
org.apache.myfaces.tobago.renderkit.RenderUtil.encode(RenderUtil.java:93)
at
org.apache.myfaces.tobago.renderkit.html.scarborough.standard.tag.GridLayoutRenderer.encodeChildrenOfComponent(GridLayoutRenderer.java:266)
at
org.apache.myfaces.tobago.component.UILayout.encodeChildrenOfComponent(UILayout.java:73)
at
org.apache.myfaces.tobago.component.UIGridLayout.encodeChildrenOfComponent(UIGridLayout.java:71)
at
org.apache.myfaces.tobago.component.UIPanel.encodeChildren(UIPanel.java:41)
at
org.apache.myfaces.tobago.renderkit.RenderUtil.encode(RenderUtil.java:85)
at
org.apache.myfaces.tobago.renderkit.html.scarborough.standard.tag.GridLayoutRenderer.encodeChildrenOfComponent(GridLayoutRenderer.java:266)
at
org.apache.myfaces.tobago.component.UILayout.encodeChildrenOfComponent(UILayout.java:73)
at
org.apache.myfaces.tobago.component.UIGridLayout.encodeChildrenOfComponent(UIGridLayout.java:71)
at
org.apache.myfaces.tobago.component.UIPanel.encodeChildren(UIPanel.java:41)
at
org.apache.myfaces.tobago.renderkit.RenderUtil.encode(RenderUtil.java:85)
at
org.apache.myfaces.tobago.renderkit.html.scarborough.standard.tag.GridLayoutRenderer.encodeChildrenOfComponent(GridLayoutRenderer.java:266)
at
org.apache.myfaces.tobago.component.UILayout.encodeChildrenOfComponent(UILayout.java:73)
at
org.apache.myfaces.tobago.component.UIGridLayout.encodeChildrenOfComponent(UIGridLayout.java:71)
at
org.apache.myfaces.tobago.component.UIPanel.encodeChildren(UIPanel.java:41)
at
org.apache.myfaces.tobago.renderkit.RenderUtil.encode(RenderUtil.java:85)
at
org.apache.myfaces.tobago.renderkit.html.scarborough.standard.tag.DefaultLayoutRenderer.encodeChildrenOfComponent(DefaultLayoutRenderer.java:54)
at
org.apache.myfaces.tobago.component.UILayout.encodeChildrenOfComponent(UILayout.java:73)
at
org.apache.myfaces.tobago.component.UIPanel.encodeChildren(UIPanel.java:41)
at
org.apache.myfaces.tobago.renderkit.RenderUtil.encode(RenderUtil.java:85)
at
org.apache.myfaces.tobago.renderkit.html.scarborough.standard.tag.GridLayoutRenderer.encodeChildrenOfComponent(GridLayoutRenderer.java:266)
at
org.apache.myfaces.tobago.component.UILayout.encodeChildrenOfComponent(UILayout.java:73)
at
org.apache.myfaces.tobago.component.UIGridLayout.encodeChildrenOfComponent(UIGridLayout.java:71)
at
[jira] Commented: (MYFACES-787) defining attributes in tomahawk.tld makes it difficult to subclass tomahawk components
[ http://issues.apache.org/jira/browse/MYFACES-787?page=comments#action_12360248 ] Steve Peterson commented on MYFACES-787: I'm +1 on this as well. Considered doing this as part of my big docs patch a while back but decided to focus mostly on the standard tags. This will speed improvements in the tomahawk TLD docs. defining attributes in tomahawk.tld makes it difficult to subclass tomahawk components -- Key: MYFACES-787 URL: http://issues.apache.org/jira/browse/MYFACES-787 Project: MyFaces Type: Improvement Reporter: Simon Kitching Attachments: html_column_attributes.xml, tomahawk.tld.patch The tomahawk.tld file uses xml entities to reference some attributes shared between components. However the attributes for tomahawk components are defined in-line in the tomahawk.tld file. When subclassing a tomahawk component to extend it, all of the text needs to be copied into the tld where the derived component is defined - ugly, esp. for things like HtmlColumn that have dozens of attributes. Attached is a patch to simply move the attributes defined in tomahawk.tld for the HtmlColumn tag into an external entity file, thus allowing derived classes to just reference this entity file. I'm happy to provide patches to move all defined attributes for other tomahawk components into entity files too, though it probably takes more time to apply/commit such patches than it would for a MyFaces committer to make this change directly. One possible variant on this patch is to move the other entity refs which are used by HtmlColumn into the html_column_attributes.xml file, so that the HtmlColumn definition in tomahawk.tld just contains one reference. That makes subclassing even easier, and seems sensible. It's a slightly more adventurous change, though, so I've submitted the simpler approach as the patch. -- 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-940) ImportCalendar doesn't work in FireFox browser
ImportCalendar doesn't work in FireFox browser
--
Key: MYFACES-940
URL: http://issues.apache.org/jira/browse/MYFACES-940
Project: MyFaces
Type: Bug
Components: Tomahawk
Environment: Windows XP with FireFox browser
Reporter: Jane Skolnick
InputCalendar component (tomahawk extensions) is working fine in Internet
Explorer but it doesn't work in FireFox browser. The following is javascript
error message detected by FireFox browser. I can see the calendar image on
FireFox browser but the calendar doesn't pop up when I click the calendar image.
Code in JSP:
t:inputCalendar id=personDOBInput title=#{uimsg['label.person.DOB']}
alt=date
forceId=true size=13
value=#{person.dateOfBirth}
popupDateFormat=#{uimsg['format.date']}
required=true
validator=#{memberController.validate}
renderAsPopup=true
renderPopupButtonAsImage=true/
Error: jscalendarSetImageDirectory is not defined
Source File:
http://localhost/CAS/jsp/provider/presumptiveEligibility/providerSearch.jsf
--
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: Milestone builds?
I think we all have somewhat similar positions then. The milestone builds are not official releases and therefore aren't subject to the TCK. My position would be that we do not announce them other then updating a wiki or a webpage that lists the version and its status as an alpha or beta build. Also, I would suggest that we follow the Struts procedure and eventually vote one of these milestone builds to be an official GA release (we would subject it to TCK before then.) Thoughts? sean On 12/10/05, Bruno Aranda [EMAIL PROTECTED] wrote: I do agree with Simon that there is no need to run the TCK (I can confirm that it is a major hassle) for those milestones or integration builds, but we should warn users accordingly. When we see that a milestone has no major bugs and many new bugs has been fixed or issues implemented, we could decide to prepare a release, run the TCK etc... Regards, Bruno 2005/12/10, Simon Kitching [EMAIL PROTECTED]: I think the problem with more frequent real releases is the difficulty of running Sun's TCK. I don't have any first-hand knowledge of this, but it sounds like a major hassle, and I expect that each official release would need to be re-certified unless the changes were limited just to very simple bugfixes. Making milestone releases should be much easier; there's no need to run the TCK on these (though they should be JSF-compliant barring any accidents). Abrams, Howard A wrote: How about just releasing smaller bug-fix releases, more often? I tried to start the conversation about then 1.1.2 would be released and the 'roadmap', but the conversation has stalled. Should we call a vote to begin the release process for 1.1.2? -Original Message- From: Simon Kitching [mailto:[EMAIL PROTECTED] Sent: Thursday, December 08, 2005 8:07 PM To: MyFaces Development Subject: Milestone builds? Hi, What do people think about releasing a binary milestone build? Currently the SVN head is pretty stable. There are *many* great fixes and enhancements since the 1.1.1 release, but people may be (rightly) wary of trying to use SVN head as there's no guarantee it's workable at any particular time. Releasing a milestone build every couple of months, where we run the tests, the examples, wait a few days for any problem reports, then publish it could be very useful without being a large burden to create. Opinions? Cheers, Simon
[jira] Commented: (MYFACES-769) configurable IDs used for rendering
[ http://issues.apache.org/jira/browse/MYFACES-769?page=comments#action_12360256 ] Simon Kitching commented on MYFACES-769: With non-portal JSP/JSF applications, including an external file multiple times is not an issue. Suppose the included file has: h:inputText id=zzz/ The including page then does this: f:subview id=first jsp:include page=include.jsp/ /f:subview f:subview id=second jsp:include page=include.jsp/ /f:subview This results in ids first:zzz and second:zzz. Note that wrapping includes in f:subview is *required by the spec*, for exactly this reason. However if all components in the included page have dynamic ids you can get away without using f:subview. If the included page is: h:inputText .. / then the including page can do: jsp:include page=include.jsp/ jsp:include page=include.jsp/ jsp:include page=include.jsp/ resulting in components with ids _id0, _id1, _id2 respectively. I don't know how this works with portlets, but I would assume that each portlet should be a subview, thus ensuring the ids of its components don't conflict. The f:subview works just like any old namespacing (filesystem, java package names, etc): you place names within parent namespaces to avoid name conflicts. configurable IDs used for rendering --- Key: MYFACES-769 URL: http://issues.apache.org/jira/browse/MYFACES-769 Project: MyFaces Type: Improvement Reporter: Dave Brondsema If the same code is used ot generated a component tree for more than one part of a webpage, the rendered IDs are the same and functionality is broken (javascript needs unique IDs). An example of when this happens is when as portlet uses JSF for rendering. If the portlet is used more than once on a single page (e.g. an RSS reader) all the IDs are the same. Thus we need a way to have more configurable (perhaps random) IDs when rendered. -- 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: Milestone builds?
Sean Schofield wrote: I think we all have somewhat similar positions then. The milestone builds are not official releases and therefore aren't subject to the TCK. My position would be that we do not announce them other then updating a wiki or a webpage that lists the version and its status as an alpha or beta build. I would prefer to just label interim releases as M1, M2, M3 etc. The wiki could be used by people to note any issues they find with that particular milestone release, so others can see whether that milestone is going to be usable for them or not. The notes would generally be links to relevant significant JIRA issues. I'm not suggesting that myfaces developers should comb through outstanding issues and put links to them from each milestone release; the notes would just be casual, befitting non-official milestones, and hopefully mostly maintained by JSF users. A milestone release could even be just a nightly build renamed (or maybe not even renamed). They would be created whenever people feel that (a) there has been significant progress from the last milestone in new features or bugfixes and (b) the code seems to be fairly stable. Rather than using alpha/beta as some kind of rough quality measurement, I think the proposed list of known issues is better. A quick scan of the wiki entries next to that milestone will show whether the milestone is usable *for a particular purpose* (eg broken t:dataTable may be a showstopper for some people and irrelevant to others). That's info a rating can't convey. Also, to me, alpha is a release whose API is not frozen while beta implies that the API is frozen. I don't think this is relevant for myfaces: the javax.faces api is *always* frozen, while the tomahawk api is likely to be in flux until quite near the release date. Also, I would suggest that we follow the Struts procedure and eventually vote one of these milestone builds to be an official GA release (we would subject it to TCK before then.) +1 Having milestone releases available means a larger user community will be using them, and therefore there's more confidence that all showstoppers are known. It would be great to be able to promote M99 to RC1 to 1.x in the knowledge that it is actually in real use out in the world. Cheers, Simon
RE: Milestone builds?
+1 for: nightly + votes = M1 nightly + votes = M2 . . M[n] + votes + branch = RC1 RC1 + bug fixes = RC2 RC2 + bug fixes = RC3 . . RC[n] + votes - 1.[n] [SNIP] A milestone release could even be just a nightly build renamed (or maybe not even renamed). They would be created whenever people feel that (a) there has been significant progress from the last milestone in new features or bugfixes and (b) the code seems to be fairly stable. [SNIP] Also, I would suggest that we follow the Struts procedure and eventually vote one of these milestone builds to be an official GA release (we would subject it to TCK before then.) +1 Having milestone releases available means a larger user community will be using them, and therefore there's more confidence that all showstoppers are known. It would be great to be able to promote M99 to RC1 to 1.x in the knowledge that it is actually in real use out in the world.
[jira] Commented: (MYFACES-769) configurable IDs used for rendering
[
http://issues.apache.org/jira/browse/MYFACES-769?page=comments#action_12360269
]
Dave Brondsema commented on MYFACES-769:
Okay. If my portlet does this:
f:subview id=foo
!-- all my components --
/f:subview
And I use that portlet twice on one page, both instances of the portlet are
using foo prefixes which doesn't help. (All lifecycle phases run fine since
each instance is executed independently of the other, but the portal aggregates
the HTML of instance 1, the HTML of instance 2, and some of its own HTML which
makes forms and javascript not work)
I'd like to do something like this
f:subview id=foo#{bean.random}
!-- all my components --
/f:subview
or (where render-id is a new attribute used only when rendering components):
f:subview id=foo render-id=foo#{bean.random}
!-- all my components --
/f:subview
configurable IDs used for rendering
---
Key: MYFACES-769
URL: http://issues.apache.org/jira/browse/MYFACES-769
Project: MyFaces
Type: Improvement
Reporter: Dave Brondsema
If the same code is used ot generated a component tree for more than one part
of a webpage, the rendered IDs are the same and functionality is broken
(javascript needs unique IDs).
An example of when this happens is when as portlet uses JSF for rendering.
If the portlet is used more than once on a single page (e.g. an RSS reader)
all the IDs are the same.
Thus we need a way to have more configurable (perhaps random) IDs when
rendered.
--
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-769) configurable IDs used for rendering
[ http://issues.apache.org/jira/browse/MYFACES-769?page=comments#action_12360272 ] Simon Kitching commented on MYFACES-769: Your first example is why the f:subview should be *outside* the included file, as in my example. And unfortunately JSF requires that id attributes be static text, not dynamic. That's because a component's id must never change over its lifetime. As I know almost nothing at all about portlets, the following is just guesswork (and ignorant guesswork too :-) From your description I gather that each portlet is represented by a separate ViewRoot, and that the whole page is somehow composed by rendering each viewroot separately and stitching the results together. In this case, I presume that you can generate some kind of unique id string for each portlet that you are including in a page (including unique ids when the same portlet is included twice). So what I would do is ensure that id is included in the ids of the components by creating a custom UIViewRoot component. The standard UIViewRoot class doesn't implement the NamingContainer interface, but I expect that if a custom one did, and its getClientId() method returns a unique portlet id then that portletId would become the prefix for every component in that portlet. The UIViewRoot is created via method ViewHandler.createView, and a simple config entry in your application's faces-config.xml file allows a custom ViewHandler to be specified. I probably can't offer much more help on this as it's getting very portlet-specific now. Good luck! configurable IDs used for rendering --- Key: MYFACES-769 URL: http://issues.apache.org/jira/browse/MYFACES-769 Project: MyFaces Type: Improvement Reporter: Dave Brondsema If the same code is used ot generated a component tree for more than one part of a webpage, the rendered IDs are the same and functionality is broken (javascript needs unique IDs). An example of when this happens is when as portlet uses JSF for rendering. If the portlet is used more than once on a single page (e.g. an RSS reader) all the IDs are the same. Thus we need a way to have more configurable (perhaps random) IDs when rendered. -- 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: [jira] Commented: (MYFACES-888) Classes for Schedule Entry, Title, and Subtitle should be optional parameters to the tag.
Jurgen,, The more I looking into this, the more I need to understand. So, do not wait for me to provide a patch any time soon. I would like to know where this fits into your schedule. Paul Spencer Paul Spencer wrote: Jurgen, Where does this fit on your schedule? I would like to create a patch based the changes posted in JIRA if you are not able to get to it. Paul Spencer Jurgen Lust (JIRA) wrote: [ http://issues.apache.org/jira/browse/MYFACES-888?page=comments#action_12358857 ] Jurgen Lust commented on MYFACES-888: - I agree the css class should be an optional parameter of the component tag. In fact i will get to it as soon as I can. Classes for Schedule Entry, Title, and Subtitle should be optional parameters to the tag. - Key: MYFACES-888 URL: http://issues.apache.org/jira/browse/MYFACES-888 Project: MyFaces Type: Improvement Components: Sandbox Versions: 1.1.1 Reporter: Paul Spencer CSS Class for the Schedule Component are hardcoded. I sugget they should be optional parameters to the tag. Currently CSS Class -- Entire Entryentry title fieldtitle subtitle field subtitle I am sure their are may other CSS Classes that are hardcoded that should be added to this list.
[jira] Updated: (MYFACES-840) 404 in simple examples using jscookmenu
[ http://issues.apache.org/jira/browse/MYFACES-840?page=all ] Dennis Byrne updated MYFACES-840: - Attachment: PropertyNotFoundException.txt ... for panelNavigation example 404 in simple examples using jscookmenu --- Key: MYFACES-840 URL: http://issues.apache.org/jira/browse/MYFACES-840 Project: MyFaces Type: Bug Components: General Environment: http://www.irian.at/myfaces/jscookmenu.jsf Reporter: Dennis Byrne Priority: Minor Attachments: PropertyNotFoundException.txt, current.examples.simple.dec.1.2005.txt Example - Components - RSS Ticker - 404 -- 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
Tomahawk and JSF RI
Im trying to add Tomahawk to my existing java project (JSF RI myeclipse IDE) using the following instructions from the FAQ page: http://myfaces.apache.org/faq.html Can I use MyFaces extensions (aka Tomahawk) with the JSF RI? Yes, most of the Apache MyFaces extensions work with JSF RI. You must only copy tomahawk.jar to your WEB-INF/lib folder. To be able to use the MyFaces extensions add the following line to your JSPs: %@ taglib uri=http://myfaces.apache.org/tomahawk prefix=t% I receive the following error: org.apache.jasper.JasperException: The absolute uri: http://myfaces.apache.org/tomahawk cannot be resolved in either web.xml or the jar files deployed with this application Do I need to deploy the tomahawk.tld file separately? Any other instructions? Thanks.
Re: Tomahawk and JSF RI
is tomohawk.jar under WEB-INF/lib ? Original message Date: Tue, 13 Dec 2005 00:23:10 -0500 From: Tom Butler [EMAIL PROTECTED] Subject: Tomahawk and JSF RI To: dev@myfaces.apache.org I'm trying to add Tomahawk to my existing java project (JSF RI myeclipse IDE) using the following instructions from the FAQ page: http://myfaces.apache.org/faq.html Can I use MyFaces extensions (aka Tomahawk) with the JSF RI? Yes, most of the Apache MyFaces extensions work with JSF RI. You must only copy tomahawk.jar to your WEB-INF/lib folder. To be able to use the MyFaces extensions add the following line to your JSPs: %@ taglib uri=http://myfaces.apache.org/tomahawk; prefix=t% I receive the following error: org.apache.jasper.JasperException: The absolute uri: http://myfaces.apache.org/tomahawk cannot be resolved in either web.xml or the jar files deployed with this application Do I need to deploy the tomahawk.tld file separately? Any other instructions? Thanks. Dennis Byrne
