[jira] Commented: (MYFACES-1761) Handling PostConstruct annotations - wrong order
[
https://issues.apache.org/jira/browse/MYFACES-1761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12543607
]
Paul McMahan commented on MYFACES-1761:
---
Feedback from the MyFaces dev list indicates that changing the
LifecycleProvider interface in a maintenance release will be OK.
During that conversation Bernhard offered to provide an alternative patch that
will bring together the best aspects of both patches already proposed for this
issue. Specifically, his proposal is:
{quote}
what about introducing InjectionTasks? The ManagedBeanBuilder, for example,
could register an InjectionTask that handles the injection of managed
properties. In fact, I'm thinking of a more general approach of your patch so
that others can perform additional injection too.
public interface InjectionTask {
public void inject(Object bean) throws ...;
}
{quote}
See
http://www.nabble.com/Re%3A-external-api-change-OK-for-myfaces-impl-1.2.1--p13733556.html
Handling PostConstruct annotations - wrong order
Key: MYFACES-1761
URL: https://issues.apache.org/jira/browse/MYFACES-1761
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 1.2.0, 1.2.1-SNAPSHOT
Reporter: Bernhard Huemer
Assignee: Paul McMahan
Fix For: 1.2.1-SNAPSHOT
Attachments: MYFACES-1761-01.diff, MyFaces-1761.patch,
postconstruct-demo.zip
The specification states that managed bean methods annotated with
@PostConstruct have to be called after the object is initialized and after
dependency injection is performed. However, MyFaces calls those methods after
the bean instance is created but before dependency injection is performed
(for example, see
http://www.nabble.com/myfaces-1.2.0-postConstruct-tf4760326.html ). In order
to resolve this bug the LifecycleProvider interface has to be changed.
Currently there's only one method responsible for creating/initializing a new
bean: newInstance(). This design choice implicates that there's no
possibility to seperate the steps creating the bean and postconstructing
the bean.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-1761) Handling PostConstruct annotations - wrong order
[ https://issues.apache.org/jira/browse/MYFACES-1761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12541341 ] Paul McMahan commented on MYFACES-1761: --- Thanks Martin. As you can probably tell (and maybe agree?) I am still not convinced by the original claim that the current @PostConstruct support in MyFaces is not compliant with the wording in the JSF spec. In fact I could go so far as to say that changing the current behavior actually introduces a bug because the spec is clear about injection (and therefore the timing of @PostConstruct) being limited to container managed resources. So like you pointed out our next recourse is to look at the TCK and the RI for enlightenment. MyFaces 1.2 passed the TCK so we are OK there. But I don't think that the JSF RI (by itself) can be used to determine the meaning of this language in the spec because IIUC the JSF RI only provides the hooks for dependency injection. Therefore my position is that it is the responsibility of the embedder of MyFaces to ensure compatibility with the *glassfish* RI, and compatibility with glassfish is not the responsibility of MyFaces itself. Testing the JSF RI's resource injection behavior outside of a compliant JavaEE container (such as in tomcat or jetty) is not valid IMHO. MyFaces can help JavaEE containers meet this compatibility requirement by refactoring ManagedBeanBuilder. And furthermore MyFaces can provide (as a feature) default implementations of LifecycleProvider for various non-JavaEE environments that include this functionality. My hope is that we can implement this @PostConstruct behavior while keeping the LifecycleProvider interface intact. LifecycleProvider.newInstance() is the integration point for dependency injection in several JavaEE components in Geronimo, and I do not think that it is necessary to change that interface to provide the desired behavior. Handling PostConstruct annotations - wrong order Key: MYFACES-1761 URL: https://issues.apache.org/jira/browse/MYFACES-1761 Project: MyFaces Core Issue Type: Bug Affects Versions: 1.2.0, 1.2.1-SNAPSHOT Reporter: Bernhard Huemer Fix For: 1.2.1-SNAPSHOT Attachments: MyFaces-1761.patch, postconstruct-demo.zip The specification states that managed bean methods annotated with @PostConstruct have to be called after the object is initialized and after dependency injection is performed. However, MyFaces calls those methods after the bean instance is created but before dependency injection is performed (for example, see http://www.nabble.com/myfaces-1.2.0-postConstruct-tf4760326.html ). In order to resolve this bug the LifecycleProvider interface has to be changed. Currently there's only one method responsible for creating/initializing a new bean: newInstance(). This design choice implicates that there's no possibility to seperate the steps creating the bean and postconstructing the bean. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-1761) Handling PostConstruct annotations - wrong order
[ https://issues.apache.org/jira/browse/MYFACES-1761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12541068 ] Paul McMahan commented on MYFACES-1761: --- Bernhard, thanks for bringing this up and for the helpful sample which clearly demonstrates the issue. Can you please point me to the language in the spec that you are referring to? Specifically you said: The specification states that managed bean methods annotated with @PostConstruct have to be called after the object is initialized and after dependency injection is performed. But the language I found in the spec says: JSF implementations running in a Java EE 5 compliant container must support attaching the @PostConstruct and @PreDestroy annotations to aid in awareness of the managed-bean lifecycle. and Methods on managed beans declared to be in request, session, or application scope, annotated with @PostConstruct, must be called by the JSF implementation after resource injection is performed (if any) but before the bean is placed into scope. Reading the spec literally, the @PostConstruct annotation is exclusively provided for the benefit of resource injection in a Java EE 5 container, which as you have pointed out doesn't necessarily know about managed bean properties. I don't see any discussion about the @PostConstuct annotation being related to managed bean properties, so initializing them before calling @PostConstrcut could arguably be non-compliant with the spec. (I'm not taking that position, just considering both sides) I agree that initializing managed properties before calling PostConstruct methods might be a useful feature worth further consideration. But I want to determine first whether we think it is actually required by the spec or its up to us to determine if/how this feature should be implemented. If it's not required by the spec then let's consider how the RI behaves. Something I read in a blog suggests that the RI does in fact provide this feature, which would make me lean towards also providing it in MyFaces. However, the LifeCycleProvider interface you modified is an existing integration point for servlet and Java EE containers, and there are very similar LifeCycleProvider interfaces for several other Java EE components. So let's investigate whether it's possible to provide this feature without changing the interface, perhaps by refactoring the ManagedBeanBuilder so that initialization can occur as an additional step within the LifeCycleProvider.newInstance(). Looking forward to your thoughts on all this! Handling PostConstruct annotations - wrong order Key: MYFACES-1761 URL: https://issues.apache.org/jira/browse/MYFACES-1761 Project: MyFaces Core Issue Type: Bug Affects Versions: 1.2.0, 1.2.1-SNAPSHOT Reporter: Bernhard Huemer Fix For: 1.2.1-SNAPSHOT Attachments: MyFaces-1761.patch, postconstruct-demo.zip The specification states that managed bean methods annotated with @PostConstruct have to be called after the object is initialized and after dependency injection is performed. However, MyFaces calls those methods after the bean instance is created but before dependency injection is performed (for example, see http://www.nabble.com/myfaces-1.2.0-postConstruct-tf4760326.html ). In order to resolve this bug the LifecycleProvider interface has to be changed. Currently there's only one method responsible for creating/initializing a new bean: newInstance(). This design choice implicates that there's no possibility to seperate the steps creating the bean and postconstructing the bean. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-1761) Handling PostConstruct annotations - wrong order
[ https://issues.apache.org/jira/browse/MYFACES-1761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12541154 ] Paul McMahan commented on MYFACES-1761: --- The original description for this issue says: The specification states that... after the object is initialized and after dependency injection is performed But your quote from the spec says: after the object is *instantiated*, and after injection is performed I take this change in your terminology as agreement that creating (instantiating) the bean does not involve setting its managed properties, correct? Now it seems that you are instead interpreting the term injection to include setting of managed properties from the application config file. But I would have to disagree with that position as well because section 5.4 says (with *emphasis* added by me) : JSF Implementations that are running as a part of Java EE 5 must allow managed bean implementations to use the annotations specified in section 14.5 of the Servlet 2.5 Specification to allow the container to inject references to *container managed resources* into a managed bean instance before it is made accessible to the JSF application. The spec goes on to provide the concise list of annotations where injection is valid - @Resource, @EJB, @WebService, etc. I see no other discussion of injection in the JSF spec. While I can understand your practical usage of this term to include setting of managed properties, IMO that usage is not consistent with the spec which is very clear about injection being limited to a specific list of annotations for referencing container managed resources. I still agree with you that making this change could be appropriate and I think that consistency with the RI is important as well. Earlier when I mentioned the RI I meant Glassfish and not the JSF RI in a standalone servlet container. The JSF spec only discusses dependency injection in JavaEE. Which environment did you test the attached sample in? Your reaction towards my suggestion for keeping the LifecycleProvider interface unchanged is on track with the reason I hope we can agree that we are discussing a feature request and not a myfaces bug. If setting managed properties before calling @PostConstruct is *not* required by the spec, then 3rd party implementations of LifecycleProvider are not required to do it. They can (optionally) use a refactored ManagedBeanBuilder api to initialize the managed bean or even process the application config file themselves. Apache Geronimo would probably do the latter. Handling PostConstruct annotations - wrong order Key: MYFACES-1761 URL: https://issues.apache.org/jira/browse/MYFACES-1761 Project: MyFaces Core Issue Type: Bug Affects Versions: 1.2.0, 1.2.1-SNAPSHOT Reporter: Bernhard Huemer Fix For: 1.2.1-SNAPSHOT Attachments: MyFaces-1761.patch, postconstruct-demo.zip The specification states that managed bean methods annotated with @PostConstruct have to be called after the object is initialized and after dependency injection is performed. However, MyFaces calls those methods after the bean instance is created but before dependency injection is performed (for example, see http://www.nabble.com/myfaces-1.2.0-postConstruct-tf4760326.html ). In order to resolve this bug the LifecycleProvider interface has to be changed. Currently there's only one method responsible for creating/initializing a new bean: newInstance(). This design choice implicates that there's no possibility to seperate the steps creating the bean and postconstructing the bean. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-1722) c:forEach does not work with deferred expression
[
https://issues.apache.org/jira/browse/MYFACES-1722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12526549
]
Paul McMahan commented on MYFACES-1722:
---
I transferred this problem from the Geronimo project hoping the MyFaces team
could take a look. I wasn't able to determine the root problem in my debugger
but I think it may be related to the MyFaces resolvers. It could also be
related to the tomcat's implementation of EL that is used by Geronimo.
c:forEach does not work with deferred expression
Key: MYFACES-1722
URL: https://issues.apache.org/jira/browse/MYFACES-1722
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 1.2.0
Environment: Fedora7, Sun JDK 1.6.0_02, geronimo-tomcat6-jee5-2.0.1
Reporter: Piotr Piotrowski
The following page works on SunApplication Server 9, but does not work on
Geronimo:
[EMAIL PROTECTED] contentType=text/html%
[EMAIL PROTECTED] pageEncoding=UTF-8%
[EMAIL PROTECTED] prefix=f uri=http://java.sun.com/jsf/core%
[EMAIL PROTECTED] prefix=h uri=http://java.sun.com/jsf/html%
[EMAIL PROTECTED] prefix=c uri=http://java.sun.com/jsp/jstl/core%
!DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN
http://www.w3.org/TR/html4/loose.dtd;
html
head
meta http-equiv=Content-Type content=text/html; charset=UTF-8
titleJSP Page/title
/head
body
f:view
p
c:forEach var=i items=#{CombinedEL.table}
h:outputText value=#{i}/,
/c:forEach
/p
/f:view
/body
/html
The managed bean looks as follows:
package pp.web;
public class CombinedEL {
public Object[] getTable() {
return new Object[] {a, b, c};
}
}
The error looks like this:
HTTP Status 500 -
type Exception report
message
description The server encountered an internal error () that prevented it
from fulfilling this request.
exception
javax.servlet.ServletException: javax.servlet.jsp.JspTagException: Don't know
how to iterate over supplied items in lt;forEachgt;
javax.faces.webapp.FacesServlet.service(FacesServlet.java:152)
root cause
javax.faces.FacesException: javax.servlet.jsp.JspTagException: Don't know how
to iterate over supplied items in lt;forEachgt;
org.apache.myfaces.context.servlet.ServletExternalContextImpl.dispatch(ServletExternalContextImpl.java:340)
org.apache.myfaces.application.jsp.JspViewHandlerImpl.renderView(JspViewHandlerImpl.java:254)
org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:41)
org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:132)
javax.faces.webapp.FacesServlet.service(FacesServlet.java:138)
root cause
javax.servlet.ServletException: javax.servlet.jsp.JspTagException: Don't know
how to iterate over supplied items in lt;forEachgt;
org.apache.jasper.runtime.PageContextImpl.doHandlePageException(PageContextImpl.java:850)
org.apache.jasper.runtime.PageContextImpl.handlePageException(PageContextImpl.java:779)
org.apache.jsp.combinedEL_jsp._jspService(combinedEL_jsp.java:90)
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:388)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:320)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:266)
javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
org.apache.myfaces.context.servlet.ServletExternalContextImpl.dispatch(ServletExternalContextImpl.java:334)
org.apache.myfaces.application.jsp.JspViewHandlerImpl.renderView(JspViewHandlerImpl.java:254)
org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:41)
org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:132)
javax.faces.webapp.FacesServlet.service(FacesServlet.java:138)
root cause
javax.servlet.jsp.JspTagException: Don't know how to iterate over supplied
items in lt;forEachgt;
org.apache.taglibs.standard.tag.common.core.ForEachSupport.toForEachIterator(ForEachSupport.java:274)
org.apache.taglibs.standard.tag.common.core.ForEachSupport.supportedTypeForEachIterator(ForEachSupport.java:238)
org.apache.taglibs.standard.tag.common.core.ForEachSupport.prepare(ForEachSupport.java:155)
javax.servlet.jsp.jstl.core.LoopTagSupport.doStartTag(LoopTagSupport.java:256)
org.apache.jsp.combinedEL_jsp._jspx_meth_c_005fforEach_005f0(combinedEL_jsp.java:157)
[jira] Commented: (MYFACES-1709) faces-config.xml validation using an XML Schema
[ https://issues.apache.org/jira/browse/MYFACES-1709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12520869 ] Paul McMahan commented on MYFACES-1709: --- I agree that this is a good improvement for myfaces. As an aside, I also want to point out that the spec says that validating the resource file against the schema is only required for JSF in a Java EE environment. It is recommended but optional for JSF outside the Java EE environment. Geronimo 2.0, for example, which embeds MyFaces 1.2 already performs schema validation at deployment time. So if myfaces implements its own validation then it would be good to do this in a way that is complimentary to the validation that occurs in the Java EE container. From a visual inspection of this patch it looks like this goal is accomplished quite nicely by toggling schema validation via an init parameter, and that it is disabled by default: String validateConfig = context.getInitParameter(VALIDATE_CONFIG); return true.equals(validateConfig); // by default, configuration files won't be validated My only suggestion would be to add a little more doc in the code making it clear that changing the default to true instead of false would have an effect on how MyFaces behaves in a Java EE container which is probably not desirable. If I get a chance to commit this patch then I will add that comment, or you may want to add something along those lines into the patch for anyone else who might be taking a look. faces-config.xml validation using an XML Schema --- Key: MYFACES-1709 URL: https://issues.apache.org/jira/browse/MYFACES-1709 Project: MyFaces Core Issue Type: Improvement Components: JSR-252 Affects Versions: 1.2.0, 1.2.1-SNAPSHOT Reporter: Bernhard Huemer Attachments: configuration-webapp.zip, MYFACES-1709.patch According to an inline comment (validation set to false during implementation of 1.2, DigesterFacesConfigUnmarshallerImpl) and my personal experience, configuration file validation hasn't been implemented so far. However, as far as I know the JSF specification says that JSF implementations that are part of a Java EE technology-compliant implementation are required to validate the application resource file against the XML schema (section 10.4.2). I'll attach a sample application reproducing the error (the fact that there is no error is incorrect this time) and the corresponding patch. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-1656) Wrong coercing in #{} for h:inputText
[
https://issues.apache.org/jira/browse/MYFACES-1656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12502344
]
Paul McMahan commented on MYFACES-1656:
---
From a visual inspection of jetty it looks like it uses the jsp-2.1 RI from
glassfish, which includes the el api.Geronimo uses tomcat's el api, see:
http://svn.apache.org/repos/asf/tomcat/tc6.0.x/tags/TOMCAT_6_0_13/java/javax/el/
(Actually geronimo uses a copy of tomcat's el api, but will soon switch back
over to tomcat's original version now that they are published to maven central
repo)
If we can narrow this problem down to a bug in EL and provide a patch to tomcat
then geronimo will be able to pick up that change.
Wrong coercing in #{} for h:inputText
---
Key: MYFACES-1656
URL: https://issues.apache.org/jira/browse/MYFACES-1656
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 1.2.0-SNAPSHOT
Environment: geronimo 2.0 - M6, winxp
Reporter: Alexander Zynevich
Attachments: Bad coercing.jpg
I tried to run GuessNumber application on the latest SNAPSHOT of 1.2.0
Looks like is cannot coerce #{integer-value} for string. A week ago this code
worked. Now it prints:
/greeting.jsp(44,3) '#{UserNumberBean.userNumber}'
java.lang.IllegalArgumentException: argument type mismatch
snip from bean:
public void setUserNumber(Integer user_number) {
userNumber = user_number;
System.out.println(Set userNumber + userNumber);
}
public Integer getUserNumber() {
System.out.println(get userNumber + userNumber);
return userNumber;
}
snip from jsp:
h:inputText id=userNo value=#{UserNumberBean.userNumber}
validator=#{UserNumberBean.validate}/
you may download war from GERONIMO-3167
see also screen shot
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-1644) API signature error problem with UIComponentTagBase
API signature error problem with UIComponentTagBase --- Key: MYFACES-1644 URL: https://issues.apache.org/jira/browse/MYFACES-1644 Project: MyFaces Core Issue Type: Bug Components: JSR-252 Affects Versions: 1.2.0-SNAPSHOT Reporter: Paul McMahan Assigned To: Paul McMahan Fix For: 1.2.0-SNAPSHOT JSF 1.2 javadoc for UIComponentTagBase requires protected static Logger log = Logger.getLogger(javax.faces.webapp); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-1644) API signature error with UIComponentTagBase
[ https://issues.apache.org/jira/browse/MYFACES-1644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul McMahan resolved MYFACES-1644. --- Resolution: Fixed API signature error with UIComponentTagBase --- Key: MYFACES-1644 URL: https://issues.apache.org/jira/browse/MYFACES-1644 Project: MyFaces Core Issue Type: Bug Components: JSR-252 Affects Versions: 1.2.0-SNAPSHOT Reporter: Paul McMahan Assigned To: Paul McMahan Fix For: 1.2.0-SNAPSHOT JSF 1.2 javadoc for UIComponentTagBase requires protected static Logger log = Logger.getLogger(javax.faces.webapp); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-1639) Some DTDs hold Sun Microsystems copyrights.
[ https://issues.apache.org/jira/browse/MYFACES-1639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12497687 ] Paul McMahan commented on MYFACES-1639: --- the current12 branch also contains the DTDs. do you think we should copy your hand typed versions into that branch? Some DTDs hold Sun Microsystems copyrights. Key: MYFACES-1639 URL: https://issues.apache.org/jira/browse/MYFACES-1639 Project: MyFaces Core Issue Type: Task Components: General Affects Versions: 1.1.4 Reporter: Grant Smith Assigned To: Grant Smith For now, I will follow GERONIMO's lead and retype the DTDs by hand, with ASF headers. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-1633) Incorret view rendering after postback
[ https://issues.apache.org/jira/browse/MYFACES-1633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12496686 ] Paul McMahan commented on MYFACES-1633: --- Bruno, is GERONIMO-3167 a manifestation of this problem? Incorret view rendering after postback -- Key: MYFACES-1633 URL: https://issues.apache.org/jira/browse/MYFACES-1633 Project: MyFaces Core Issue Type: Bug Components: JSR-252 Affects Versions: 1.2.0-SNAPSHOT Reporter: Bruno Aranda Priority: Critical The rendered code and the html code from the page are not ordered correctly. Visual mess. Easily observable when running the simple examples with our 1.2 implementation. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-1622) support headerClass and footerClass at h:column level
support headerClass and footerClass at h:column level
-
Key: MYFACES-1622
URL: https://issues.apache.org/jira/browse/MYFACES-1622
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 1.2.0-SNAPSHOT
Reporter: Paul McMahan
Assigned To: Paul McMahan
headerClass and footerClass attributes specified at the h:column level should
override style attributes specified at the UIData level.
page 7 of JSF 1.2 spec, section titled General changes says:
{quote}
Added headerClass and footerClass attributes at the h:column level. Please
see Section8.5 Standard HTML RenderKit Implementation for more details.
{quote}
Further details are available in the header section of :
http://java.sun.com/javaee/javaserverfaces/1.2_MR1/docs/renderkitdocs/HTML_BASIC/javax.faces.Datajavax.faces.Table.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-1622) support headerClass and footerClass at h:column level
[
https://issues.apache.org/jira/browse/MYFACES-1622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul McMahan resolved MYFACES-1622.
---
Resolution: Fixed
Fix Version/s: 1.2.0-SNAPSHOT
support headerClass and footerClass at h:column level
-
Key: MYFACES-1622
URL: https://issues.apache.org/jira/browse/MYFACES-1622
Project: MyFaces Core
Issue Type: Bug
Components: JSR-252
Affects Versions: 1.2.0-SNAPSHOT
Reporter: Paul McMahan
Assigned To: Paul McMahan
Fix For: 1.2.0-SNAPSHOT
headerClass and footerClass attributes specified at the h:column level should
override style attributes specified at the UIData level.
page 7 of JSF 1.2 spec, section titled General changes says:
{quote}
Added headerClass and footerClass attributes at the h:column level. Please
see Section8.5 Standard HTML RenderKit Implementation for more details.
{quote}
Further details are available in the header section of :
http://java.sun.com/javaee/javaserverfaces/1.2_MR1/docs/renderkitdocs/HTML_BASIC/javax.faces.Datajavax.faces.Table.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-1607) implement ResourceBundleResolver.getFeatureDescriptors()
implement ResourceBundleResolver.getFeatureDescriptors() Key: MYFACES-1607 URL: https://issues.apache.org/jira/browse/MYFACES-1607 Project: MyFaces Core Issue Type: Bug Components: JSR-252 Affects Versions: 1.2.0-SNAPSHOT Reporter: Paul McMahan Assigned To: Paul McMahan Fix For: 1.2.0-SNAPSHOT Flesh out the implementation of ResourceBundleResolver.getFeatureDescriptors() -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-1607) implement ResourceBundleResolver.getFeatureDescriptors()
[ https://issues.apache.org/jira/browse/MYFACES-1607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul McMahan resolved MYFACES-1607. --- Resolution: Fixed implement ResourceBundleResolver.getFeatureDescriptors() Key: MYFACES-1607 URL: https://issues.apache.org/jira/browse/MYFACES-1607 Project: MyFaces Core Issue Type: Bug Components: JSR-252 Affects Versions: 1.2.0-SNAPSHOT Reporter: Paul McMahan Assigned To: Paul McMahan Fix For: 1.2.0-SNAPSHOT Flesh out the implementation of ResourceBundleResolver.getFeatureDescriptors() -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-1582) web-facesconfig_1_2.xsd contains restrictive copyright
[ https://issues.apache.org/jira/browse/MYFACES-1582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul McMahan resolved MYFACES-1582. --- Resolution: Fixed Fix Version/s: 1.2.0-SNAPSHOT Assignee: Paul McMahan replaced the copyrighted version with a version typed in by hand from the jsf 1.2 specification web-facesconfig_1_2.xsd contains restrictive copyright -- Key: MYFACES-1582 URL: https://issues.apache.org/jira/browse/MYFACES-1582 Project: MyFaces Core Issue Type: Bug Components: JSR-252 Affects Versions: 1.2.0-SNAPSHOT Reporter: Paul McMahan Assigned To: Paul McMahan Fix For: 1.2.0-SNAPSHOT Attachments: web-facesconfig_1_2.xsd web-facesconfig_1_2.xsd contains a restrictive copyright. This document and the technology which it describes are distributed under licenses restricting their use, copying, distribution, and decompilation. No part of this document may be reproduced in any form by any means without prior written authorization of Sun and its licensors, if any. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-1604) commandLink with disabled=true should render children and id
commandLink with disabled=true should render children and id Key: MYFACES-1604 URL: https://issues.apache.org/jira/browse/MYFACES-1604 Project: MyFaces Core Issue Type: Bug Components: JSR-252 Affects Versions: 1.2.0-SNAPSHOT Reporter: Paul McMahan Assigned To: Paul McMahan A disabled commandLink correctly renders as a span but needs to include id attribute and also render its children. See http://java.sun.com/javaee/javaserverfaces/1.2_MR1/docs/renderkitdocs/HTML_BASIC/javax.faces.Outputjavax.faces.Link.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-1604) commandLink with disabled=true should render children and id
[ https://issues.apache.org/jira/browse/MYFACES-1604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul McMahan resolved MYFACES-1604. --- Resolution: Fixed Fix Version/s: 1.2.0-SNAPSHOT commandLink with disabled=true should render children and id Key: MYFACES-1604 URL: https://issues.apache.org/jira/browse/MYFACES-1604 Project: MyFaces Core Issue Type: Bug Components: JSR-252 Affects Versions: 1.2.0-SNAPSHOT Reporter: Paul McMahan Assigned To: Paul McMahan Fix For: 1.2.0-SNAPSHOT A disabled commandLink correctly renders as a span but needs to include id attribute and also render its children. See http://java.sun.com/javaee/javaserverfaces/1.2_MR1/docs/renderkitdocs/HTML_BASIC/javax.faces.Outputjavax.faces.Link.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-1592) cannot render selectBooleanCheckbox tag when a boolean value is supplied
[
https://issues.apache.org/jira/browse/MYFACES-1592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul McMahan resolved MYFACES-1592.
---
Resolution: Fixed
Fix Version/s: 1.2.0-SNAPSHOT
patch applied with a minor modification, thanks Martin!
cannot render selectBooleanCheckbox tag when a boolean value is supplied
Key: MYFACES-1592
URL: https://issues.apache.org/jira/browse/MYFACES-1592
Project: MyFaces Core
Issue Type: Bug
Components: JSR-252
Affects Versions: 1.2.0-SNAPSHOT
Reporter: Paul McMahan
Assigned To: Martin Haimberger
Fix For: 1.2.0-SNAPSHOT
Attachments: MYFACES-1592.patch
The tag descriptor generated by the maven plugin for
HtmlSelectBooleanCheckboxTag has the following attribute:
attribute
description![CDATA[The initial value of this
component.]]/description
namevalue/name
deferred-value/deferred-value
/attribute
So when a JSP contains a tag like this:
h:selectBooleanCheckbox id=foo1 value=true/
The following unhandled exception is thrown:
javax.servlet.ServletException: Expected submitted value of type Boolean for
Component : {Component-Path : [Class:
javax.faces.component.UIViewRoot,ViewId: /mytest.jsp][Class:
javax.faces.component.html.HtmlForm,Id: form][Class:
javax.faces.component.html.HtmlSelectBooleanCheckbox,Id: foo1]}
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:152)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:231)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at
org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:56)
at
org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:333)
at
org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:47)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:543)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:238)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:634)
at
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:445)
at java.lang.Thread.run(Thread.java:613)
This exception is thrown because RendererUtils.getBooleanValue() expects
HtmlSelectBooleanCheckbox.getValue() to return a Boolean but instead it
returns an Object. Changing the type for the value attribute in h.tld as
shown below avoids the exception and passes the currently failing TCK test
for that component:
attribute
description![CDATA[The initial value of this
component.]]/description
namevalue/name
deferred-value
typeboolean/type
/deferred-value
/attribute
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-1595) spec compliance for HtmlCommandButton
spec compliance for HtmlCommandButton - Key: MYFACES-1595 URL: https://issues.apache.org/jira/browse/MYFACES-1595 Project: MyFaces Core Issue Type: Bug Components: JSR-252 Affects Versions: 1.2.0-SNAPSHOT Reporter: Paul McMahan Assigned To: Paul McMahan Per the HtmlCommandButton spec at: http://java.sun.com/javaee/javaserverfaces/1.2_MR1/docs/api/javax/faces/component/html/HtmlCommandButton.html need to correct two issues with HtmlCommandButton renderer to match the spec: - render readonly=readonly when button.isReadOnly() returns true, otherwise don't render the attribute - render type=reset when button.getType() returns reset (case sensitive), otherwise render type=submit -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-1595) spec compliance for HtmlCommandButton
[ https://issues.apache.org/jira/browse/MYFACES-1595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul McMahan resolved MYFACES-1595. --- Resolution: Fixed Fix Version/s: 1.2.0-SNAPSHOT spec compliance for HtmlCommandButton - Key: MYFACES-1595 URL: https://issues.apache.org/jira/browse/MYFACES-1595 Project: MyFaces Core Issue Type: Bug Components: JSR-252 Affects Versions: 1.2.0-SNAPSHOT Reporter: Paul McMahan Assigned To: Paul McMahan Fix For: 1.2.0-SNAPSHOT Per the HtmlCommandButton spec at: http://java.sun.com/javaee/javaserverfaces/1.2_MR1/docs/api/javax/faces/component/html/HtmlCommandButton.html need to correct two issues with HtmlCommandButton renderer to match the spec: - render readonly=readonly when button.isReadOnly() returns true, otherwise don't render the attribute - render type=reset when button.getType() returns reset (case sensitive), otherwise render type=submit -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-1594) Passthrough attribute acceptcharset for form not being rendered
[ https://issues.apache.org/jira/browse/MYFACES-1594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul McMahan resolved MYFACES-1594. --- Resolution: Fixed Fix Version/s: 1.2.0-SNAPSHOT applied fix similar to MYFACES-1510 Passthrough attribute acceptcharset for form not being rendered - Key: MYFACES-1594 URL: https://issues.apache.org/jira/browse/MYFACES-1594 Project: MyFaces Core Issue Type: Bug Components: JSR-252 Reporter: Bruno Aranda Assigned To: Paul McMahan Fix For: 1.2.0-SNAPSHOT The attribute acceptcharset for the form is not being rendered. Probably the fix lies in the rendering of the passthrough attributes for the form component. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-1592) cannot render selectBooleanCheckbox tag when a boolean value is supplied
cannot render selectBooleanCheckbox tag when a boolean value is supplied
Key: MYFACES-1592
URL: https://issues.apache.org/jira/browse/MYFACES-1592
Project: MyFaces Core
Issue Type: Bug
Components: JSR-252
Affects Versions: 1.2.0-SNAPSHOT
Reporter: Paul McMahan
The tag descriptor generated by the maven plugin for
HtmlSelectBooleanCheckboxTag has the following attribute:
attribute
description![CDATA[The initial value of this
component.]]/description
namevalue/name
deferred-value/deferred-value
/attribute
So when a JSP contains a tag like this:
h:selectBooleanCheckbox id=foo1 value=true/
The following unhandled exception is thrown:
javax.servlet.ServletException: Expected submitted value of type Boolean for
Component : {Component-Path : [Class: javax.faces.component.UIViewRoot,ViewId:
/mytest.jsp][Class: javax.faces.component.html.HtmlForm,Id: form][Class:
javax.faces.component.html.HtmlSelectBooleanCheckbox,Id: foo1]}
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:152)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:231)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at
org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:56)
at
org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:333)
at
org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:47)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:543)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:238)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:634)
at
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:445)
at java.lang.Thread.run(Thread.java:613)
This exception is thrown because RendererUtils.getBooleanValue() expects
HtmlSelectBooleanCheckbox.getValue() to return a Boolean but instead it returns
an Object. Changing the type for the value attribute in h.tld as shown below
avoids the exception and passes the currently failing TCK test for that
component:
attribute
description![CDATA[The initial value of this
component.]]/description
namevalue/name
deferred-value
typeboolean/type
/deferred-value
/attribute
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-1592) cannot render selectBooleanCheckbox tag when a boolean value is supplied
[
https://issues.apache.org/jira/browse/MYFACES-1592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12490987
]
Paul McMahan commented on MYFACES-1592:
---
Thanks Martin, I haven't looked at the RI and didn't realize that it also
declares SelectBooleanCheckbox as an object. So based on that observation I
think your approach is right and will apply your patch unless there is some
objection.
cannot render selectBooleanCheckbox tag when a boolean value is supplied
Key: MYFACES-1592
URL: https://issues.apache.org/jira/browse/MYFACES-1592
Project: MyFaces Core
Issue Type: Bug
Components: JSR-252
Affects Versions: 1.2.0-SNAPSHOT
Reporter: Paul McMahan
Assigned To: Martin Haimberger
Attachments: MYFACES-1592.patch
The tag descriptor generated by the maven plugin for
HtmlSelectBooleanCheckboxTag has the following attribute:
attribute
description![CDATA[The initial value of this
component.]]/description
namevalue/name
deferred-value/deferred-value
/attribute
So when a JSP contains a tag like this:
h:selectBooleanCheckbox id=foo1 value=true/
The following unhandled exception is thrown:
javax.servlet.ServletException: Expected submitted value of type Boolean for
Component : {Component-Path : [Class:
javax.faces.component.UIViewRoot,ViewId: /mytest.jsp][Class:
javax.faces.component.html.HtmlForm,Id: form][Class:
javax.faces.component.html.HtmlSelectBooleanCheckbox,Id: foo1]}
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:152)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:231)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at
org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:56)
at
org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:333)
at
org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:47)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:543)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:238)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:634)
at
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:445)
at java.lang.Thread.run(Thread.java:613)
This exception is thrown because RendererUtils.getBooleanValue() expects
HtmlSelectBooleanCheckbox.getValue() to return a Boolean but instead it
returns an Object. Changing the type for the value attribute in h.tld as
shown below avoids the exception and passes the currently failing TCK test
for that component:
attribute
description![CDATA[The initial value of this
component.]]/description
namevalue/name
deferred-value
typeboolean/type
/deferred-value
/attribute
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-1593) javax.el.CompositeELResolver cannot resolve managed beans
javax.el.CompositeELResolver cannot resolve managed beans - Key: MYFACES-1593 URL: https://issues.apache.org/jira/browse/MYFACES-1593 Project: MyFaces Core Issue Type: Bug Components: JSR-252 Affects Versions: 1.2.0-SNAPSHOT Reporter: Paul McMahan With a managed bean defined in faces-config.xml like this: managed-bean managed-bean-name mybean /managed-bean-name managed-bean-class MyBean /managed-bean-class managed-bean-scope request /managed-bean-scope /managed-bean FacesCompositeResolver can resolve the bean but javax.el.CompositeELResolver cannot. It does not insulate the ManagedBeanResolver with the code in VariableResolverToELResolver that sets the propertyResolved flag back to false after ManagedBeanResolver returns null and relies on ScopedAttributeResolver to return it from the proper scope later. For example, this code will fail to resolve the managed bean: PageContext context = JspFactory.getDefaultFactory().getPageContext( ... ); ELResolver resolver = context.getELResolver(); // jasper returns a javax.el.CompositeELResolver MyBean mybean = resolver.getValue(context, null, mybean); // returns null -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-1593) javax.el.CompositeELResolver cannot resolve managed beans
[ https://issues.apache.org/jira/browse/MYFACES-1593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul McMahan resolved MYFACES-1593. --- Resolution: Fixed Fix Version/s: 1.2.0-SNAPSHOT Assignee: Paul McMahan javax.el.CompositeELResolver cannot resolve managed beans - Key: MYFACES-1593 URL: https://issues.apache.org/jira/browse/MYFACES-1593 Project: MyFaces Core Issue Type: Bug Components: JSR-252 Affects Versions: 1.2.0-SNAPSHOT Reporter: Paul McMahan Assigned To: Paul McMahan Fix For: 1.2.0-SNAPSHOT With a managed bean defined in faces-config.xml like this: managed-bean managed-bean-name mybean /managed-bean-name managed-bean-class MyBean /managed-bean-class managed-bean-scope request /managed-bean-scope /managed-bean FacesCompositeResolver can resolve the bean but javax.el.CompositeELResolver cannot. It does not insulate the ManagedBeanResolver with the code in VariableResolverToELResolver that sets the propertyResolved flag back to false after ManagedBeanResolver returns null and relies on ScopedAttributeResolver to return it from the proper scope later. For example, this code will fail to resolve the managed bean: PageContext context = JspFactory.getDefaultFactory().getPageContext( ... ); ELResolver resolver = context.getELResolver(); // jasper returns a javax.el.CompositeELResolver MyBean mybean = resolver.getValue(context, null, mybean); // returns null -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-1588) managed beans are not resolved when scope is none
[
https://issues.apache.org/jira/browse/MYFACES-1588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul McMahan resolved MYFACES-1588.
---
Resolution: Fixed
Fix Version/s: 1.2.0-SNAPSHOT
managed beans are not resolved when scope is none
---
Key: MYFACES-1588
URL: https://issues.apache.org/jira/browse/MYFACES-1588
Project: MyFaces Core
Issue Type: Bug
Components: JSR-252
Affects Versions: 1.2.0-SNAPSHOT
Reporter: Paul McMahan
Assigned To: Paul McMahan
Fix For: 1.2.0-SNAPSHOT
When a manged bean is defined in an application's config like this:
managed-bean
managed-bean-nameMyBean/managed-bean-name
managed-bean-classfoo.MyBean/managed-bean-class
managed-bean-scopenone/managed-bean-scope
/managed-bean
the bean should be resolvable from a ValueBinding but instead it returns null
as shown below:
ValueBinding binding = application.createValueBinding(#{MyBean});
binding.getValue(facesContext); // returns null;
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-1587) generated h.tld doesn't conform to schema
generated h.tld doesn't conform to schema - Key: MYFACES-1587 URL: https://issues.apache.org/jira/browse/MYFACES-1587 Project: MyFaces Core Issue Type: Bug Components: JSR-252 Affects Versions: 1.2.0-SNAPSHOT Reporter: Paul McMahan The TLD at target/classes/META-INF/h.tld that is generated ( IIUC ) by the maven plugin does not conform to the schema it references http://java.sun.com/xml/ns/javaee/web-jsptaglibrary_2_1.xsd. See GERONIMO-3038 for an exhaustive list of parse errors. The file at core/impl/src/main/tld/myfaces_html.tld appears to be a more accurate version of this TLD but does not end up in the myfaces-impl jar. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-1574) HtmlOutputLink returns the wrong renderer type
[
https://issues.apache.org/jira/browse/MYFACES-1574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul McMahan resolved MYFACES-1574.
---
Resolution: Fixed
Fix Version/s: 1.2.0-SNAPSHOT
Not sure when/how this was fixed but HtmlOutputLink returns the correct
renderer type now.
HtmlOutputLink returns the wrong renderer type
--
Key: MYFACES-1574
URL: https://issues.apache.org/jira/browse/MYFACES-1574
Project: MyFaces Core
Issue Type: Bug
Components: JSR-252
Affects Versions: 1.2.0-SNAPSHOT
Reporter: Paul McMahan
Assigned To: Matthias Weßendorf
Fix For: 1.2.0-SNAPSHOT
The generated java src for javax.faces.component.html.HtmlOutputLink sets the
renderer type to javax.faces.Label :
public HtmlOutputLink()
{
setRendererType(javax.faces.Label);
}
It should instead set the renderer type to javax.faces.Link
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-1588) managed beans are not resolved when scope is none
managed beans are not resolved when scope is none
---
Key: MYFACES-1588
URL: https://issues.apache.org/jira/browse/MYFACES-1588
Project: MyFaces Core
Issue Type: Bug
Components: JSR-252
Affects Versions: 1.2.0-SNAPSHOT
Reporter: Paul McMahan
Assigned To: Paul McMahan
When a manged bean is defined in an application's config like this:
managed-bean
managed-bean-nameMyBean/managed-bean-name
managed-bean-classfoo.MyBean/managed-bean-class
managed-bean-scopenone/managed-bean-scope
/managed-bean
the bean should be resolvable from a ValueBinding but instead it returns null
as shown below:
ValueBinding binding = application.createValueBinding(#{MyBean});
binding.getValue(facesContext); // returns null;
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-1584) DateTimeConverter contains an extra non-spec field
[ https://issues.apache.org/jira/browse/MYFACES-1584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul McMahan updated MYFACES-1584: -- Resolution: Fixed Fix Version/s: 1.2.0-SNAPSHOT Assignee: Paul McMahan Status: Resolved (was: Patch Available) DateTimeConverter contains an extra non-spec field -- Key: MYFACES-1584 URL: https://issues.apache.org/jira/browse/MYFACES-1584 Project: MyFaces Core Issue Type: Bug Components: JSR-252 Affects Versions: 1.2.0-SNAPSHOT Reporter: Paul McMahan Assigned To: Paul McMahan Fix For: 1.2.0-SNAPSHOT Attachments: MYFACES-1584.patch javax.faces.convert.DateTimeConverter contains an extra non-spec field: public static final String PATTERN_TYPE_ID = javax.faces.converter.DateTimeConverter.PATTERN_TYPE; See: http://java.sun.com/javaee/javaserverfaces/1.2/docs/api/javax/faces/convert/DateTimeConverter.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-1577) PropertyResolver should throw PropertyNotFoundException
[ https://issues.apache.org/jira/browse/MYFACES-1577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul McMahan updated MYFACES-1577: -- Resolution: Fixed Status: Resolved (was: Patch Available) PropertyResolver should throw PropertyNotFoundException --- Key: MYFACES-1577 URL: https://issues.apache.org/jira/browse/MYFACES-1577 Project: MyFaces Core Issue Type: Bug Components: JSR-252 Affects Versions: 1.2.0-SNAPSHOT Reporter: Paul McMahan Assigned To: Paul McMahan Fix For: 1.2.0-SNAPSHOT Attachments: MYFACES-1577-2.patch, MYFACES-1577.patch According to the spec several methods in PropertyResolver should throw PropertyNotFoundException in the following circumstances: getValue(Object base, int index) PropertyNotFoundException - if the index is out of bounds or if base is null setValue(Object base, int index, Object value) PropertyNotFoundException - if the index is out of bounds or if base is null setValue(Object base, Object property, Object value) PropertyNotFoundException - if the specified bean base object property does not exist or if base or property is null BTW, MYFACES-1576 already addressed these two cases: getType(Object base, int index) PropertyNotFoundException - if the index is out of bounds or if base is null getType(Object base, Object property) PropertyNotFoundException - if the specified bean base object property does not exist or if base or property is null -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-1577) PropertyResolver should throw PropertyNotFoundException
[ https://issues.apache.org/jira/browse/MYFACES-1577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12486952 ] Paul McMahan commented on MYFACES-1577: --- It was actually the setValue() errors that prompted me to provide the patch. But while working on the patch I also noticed the discrepancy between getValue() and the spec/javadoc so I adjusted its behavior as well. As they say, no good deed goes unpunished :-) I believe that the current behavior of getValue() is consistent with the spec/javadoc and that the test cases are in error. Last week I created GERONIMOTCK-22 and GERONIMOTCK-23 to track challenges for those test cases. But while that gets sorted out I agree that getValue() should be reverted back to its original form which as I recall threw the exceptions like you described. PropertyResolver should throw PropertyNotFoundException --- Key: MYFACES-1577 URL: https://issues.apache.org/jira/browse/MYFACES-1577 Project: MyFaces Core Issue Type: Bug Components: JSR-252 Affects Versions: 1.2.0-SNAPSHOT Reporter: Paul McMahan Assigned To: Dennis Byrne Fix For: 1.2.0-SNAPSHOT Attachments: MYFACES-1577.patch According to the spec several methods in PropertyResolver should throw PropertyNotFoundException in the following circumstances: getValue(Object base, int index) PropertyNotFoundException - if the index is out of bounds or if base is null setValue(Object base, int index, Object value) PropertyNotFoundException - if the index is out of bounds or if base is null setValue(Object base, Object property, Object value) PropertyNotFoundException - if the specified bean base object property does not exist or if base or property is null BTW, MYFACES-1576 already addressed these two cases: getType(Object base, int index) PropertyNotFoundException - if the index is out of bounds or if base is null getType(Object base, Object property) PropertyNotFoundException - if the specified bean base object property does not exist or if base or property is null -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-1577) PropertyResolver should throw PropertyNotFoundException
[ https://issues.apache.org/jira/browse/MYFACES-1577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul McMahan updated MYFACES-1577: -- Status: Patch Available (was: Reopened) PropertyResolver should throw PropertyNotFoundException --- Key: MYFACES-1577 URL: https://issues.apache.org/jira/browse/MYFACES-1577 Project: MyFaces Core Issue Type: Bug Components: JSR-252 Affects Versions: 1.2.0-SNAPSHOT Reporter: Paul McMahan Assigned To: Dennis Byrne Fix For: 1.2.0-SNAPSHOT Attachments: MYFACES-1577.patch According to the spec several methods in PropertyResolver should throw PropertyNotFoundException in the following circumstances: getValue(Object base, int index) PropertyNotFoundException - if the index is out of bounds or if base is null setValue(Object base, int index, Object value) PropertyNotFoundException - if the index is out of bounds or if base is null setValue(Object base, Object property, Object value) PropertyNotFoundException - if the specified bean base object property does not exist or if base or property is null BTW, MYFACES-1576 already addressed these two cases: getType(Object base, int index) PropertyNotFoundException - if the index is out of bounds or if base is null getType(Object base, Object property) PropertyNotFoundException - if the specified bean base object property does not exist or if base or property is null -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-1584) DateTimeConverter contains an extra non-spec field
DateTimeConverter contains an extra non-spec field -- Key: MYFACES-1584 URL: https://issues.apache.org/jira/browse/MYFACES-1584 Project: MyFaces Core Issue Type: Bug Components: JSR-252 Affects Versions: 1.2.0-SNAPSHOT Reporter: Paul McMahan Attachments: MYFACES-1584.patch javax.faces.convert.DateTimeConverter contains an extra non-spec field: public static final String PATTERN_TYPE_ID = javax.faces.converter.DateTimeConverter.PATTERN_TYPE; See: http://java.sun.com/javaee/javaserverfaces/1.2/docs/api/javax/faces/convert/DateTimeConverter.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-1584) DateTimeConverter contains an extra non-spec field
[ https://issues.apache.org/jira/browse/MYFACES-1584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul McMahan updated MYFACES-1584: -- Status: Patch Available (was: Open) DateTimeConverter contains an extra non-spec field -- Key: MYFACES-1584 URL: https://issues.apache.org/jira/browse/MYFACES-1584 Project: MyFaces Core Issue Type: Bug Components: JSR-252 Affects Versions: 1.2.0-SNAPSHOT Reporter: Paul McMahan Attachments: MYFACES-1584.patch javax.faces.convert.DateTimeConverter contains an extra non-spec field: public static final String PATTERN_TYPE_ID = javax.faces.converter.DateTimeConverter.PATTERN_TYPE; See: http://java.sun.com/javaee/javaserverfaces/1.2/docs/api/javax/faces/convert/DateTimeConverter.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-1582) web-facesconfig_1_2.xsd contains restrictive copyright
web-facesconfig_1_2.xsd contains restrictive copyright -- Key: MYFACES-1582 URL: https://issues.apache.org/jira/browse/MYFACES-1582 Project: MyFaces Core Issue Type: Bug Components: JSR-252 Affects Versions: 1.2.0-SNAPSHOT Reporter: Paul McMahan web-facesconfig_1_2.xsd contains a restrictive copyright. This document and the technology which it describes are distributed under licenses restricting their use, copying, distribution, and decompilation. No part of this document may be reproduced in any form by any means without prior written authorization of Sun and its licensors, if any. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-1582) web-facesconfig_1_2.xsd contains restrictive copyright
[ https://issues.apache.org/jira/browse/MYFACES-1582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12486574 ] Paul McMahan commented on MYFACES-1582: --- correct reference is GERONIMO-2630 web-facesconfig_1_2.xsd contains restrictive copyright -- Key: MYFACES-1582 URL: https://issues.apache.org/jira/browse/MYFACES-1582 Project: MyFaces Core Issue Type: Bug Components: JSR-252 Affects Versions: 1.2.0-SNAPSHOT Reporter: Paul McMahan Attachments: web-facesconfig_1_2.xsd web-facesconfig_1_2.xsd contains a restrictive copyright. This document and the technology which it describes are distributed under licenses restricting their use, copying, distribution, and decompilation. No part of this document may be reproduced in any form by any means without prior written authorization of Sun and its licensors, if any. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-1579) VariableResolver throws IllegalStateException because scope is unknown
VariableResolver throws IllegalStateException because scope is unknown -- Key: MYFACES-1579 URL: https://issues.apache.org/jira/browse/MYFACES-1579 Project: MyFaces Core Issue Type: Bug Components: JSR-252 Affects Versions: 1.2.0-SNAPSHOT Reporter: Paul McMahan VariableResolverImpl tries to determine if it was invoked through the faces chain or jsp chain by looking for an attribute (Scope.getClassName()) in the RequestMap. However, that attribute is only set during the span of a call to FacesCompositeELResolver.getValue(). See FacesCompositeELResolver#invoke(), which calls setScope() and then unsetScope(). Therefore the following code always throws IllegalStateException VariableResolver resolver = application.getVariableResolver(); Object result = resolver.resolveVariable(facesContext, param); because when VariableResolverImpl.resolveVariable() looks for the scope in the request map (which happens outside the getValue() call) its always null. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-1579) VariableResolver throws IllegalStateException because scope is unknown
[ https://issues.apache.org/jira/browse/MYFACES-1579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul McMahan updated MYFACES-1579: -- Status: Patch Available (was: Open) VariableResolver throws IllegalStateException because scope is unknown -- Key: MYFACES-1579 URL: https://issues.apache.org/jira/browse/MYFACES-1579 Project: MyFaces Core Issue Type: Bug Components: JSR-252 Affects Versions: 1.2.0-SNAPSHOT Reporter: Paul McMahan Attachments: MYFACES-1579.patch VariableResolverImpl tries to determine if it was invoked through the faces chain or jsp chain by looking for an attribute (Scope.getClassName()) in the RequestMap. However, that attribute is only set during the span of a call to FacesCompositeELResolver.getValue(). See FacesCompositeELResolver#invoke(), which calls setScope() and then unsetScope(). Therefore the following code always throws IllegalStateException VariableResolver resolver = application.getVariableResolver(); Object result = resolver.resolveVariable(facesContext, param); because when VariableResolverImpl.resolveVariable() looks for the scope in the request map (which happens outside the getValue() call) its always null. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (MYFACES-1572) getFirst() and getRows() methods in UIData don't return correct values
[ https://issues.apache.org/jira/browse/MYFACES-1572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul McMahan reopened MYFACES-1572: --- still seeing the problem with getRows in generated UIData class. seems that _rowsSet assignment needs to be in setRows() method in the template. getFirst() and getRows() methods in UIData don't return correct values -- Key: MYFACES-1572 URL: https://issues.apache.org/jira/browse/MYFACES-1572 Project: MyFaces Core Issue Type: Bug Components: JSR-252 Affects Versions: 1.2.0-SNAPSHOT Reporter: Paul McMahan Assigned To: Matthias Weßendorf Priority: Critical Fix For: 1.2.0-SNAPSHOT UIData data = new UIData(); data.setFirst(1); data.getFirst(); // returns 0 data.setRows(1); data.getRows(); // returns 0 Looks like there may be a bug in the code generator. The setFirst() and setRows() methods should be assigning _firstSet=true and _rowsSet=true. Maybe there is some way to influence this behavior in UIData's template? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-1572) getFirst() and getRows() methods in UIData don't return correct values
[ https://issues.apache.org/jira/browse/MYFACES-1572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul McMahan updated MYFACES-1572: -- Status: Patch Available (was: Reopened) getFirst() and getRows() methods in UIData don't return correct values -- Key: MYFACES-1572 URL: https://issues.apache.org/jira/browse/MYFACES-1572 Project: MyFaces Core Issue Type: Bug Components: JSR-252 Affects Versions: 1.2.0-SNAPSHOT Reporter: Paul McMahan Assigned To: Matthias Weßendorf Priority: Critical Fix For: 1.2.0-SNAPSHOT Attachments: MYFACES-1572.2.patch UIData data = new UIData(); data.setFirst(1); data.getFirst(); // returns 0 data.setRows(1); data.getRows(); // returns 0 Looks like there may be a bug in the code generator. The setFirst() and setRows() methods should be assigning _firstSet=true and _rowsSet=true. Maybe there is some way to influence this behavior in UIData's template? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-1577) PropertyResolver should throw PropertyNotFoundException
PropertyResolver should throw PropertyNotFoundException --- Key: MYFACES-1577 URL: https://issues.apache.org/jira/browse/MYFACES-1577 Project: MyFaces Core Issue Type: Bug Components: JSR-252 Affects Versions: 1.2.0-SNAPSHOT Reporter: Paul McMahan According to the spec several methods in PropertyResolver should throw PropertyNotFoundException in the following circumstances: getValue(Object base, int index) PropertyNotFoundException - if the index is out of bounds or if base is null setValue(Object base, int index, Object value) PropertyNotFoundException - if the index is out of bounds or if base is null setValue(Object base, Object property, Object value) PropertyNotFoundException - if the specified bean base object property does not exist or if base or property is null BTW, MYFACES-1576 already addressed these two cases: getType(Object base, int index) PropertyNotFoundException - if the index is out of bounds or if base is null getType(Object base, Object property) PropertyNotFoundException - if the specified bean base object property does not exist or if base or property is null -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-1577) PropertyResolver should throw PropertyNotFoundException
[ https://issues.apache.org/jira/browse/MYFACES-1577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul McMahan updated MYFACES-1577: -- Status: Patch Available (was: Open) PropertyResolver should throw PropertyNotFoundException --- Key: MYFACES-1577 URL: https://issues.apache.org/jira/browse/MYFACES-1577 Project: MyFaces Core Issue Type: Bug Components: JSR-252 Affects Versions: 1.2.0-SNAPSHOT Reporter: Paul McMahan Attachments: MYFACES-1577.patch According to the spec several methods in PropertyResolver should throw PropertyNotFoundException in the following circumstances: getValue(Object base, int index) PropertyNotFoundException - if the index is out of bounds or if base is null setValue(Object base, int index, Object value) PropertyNotFoundException - if the index is out of bounds or if base is null setValue(Object base, Object property, Object value) PropertyNotFoundException - if the specified bean base object property does not exist or if base or property is null BTW, MYFACES-1576 already addressed these two cases: getType(Object base, int index) PropertyNotFoundException - if the index is out of bounds or if base is null getType(Object base, Object property) PropertyNotFoundException - if the specified bean base object property does not exist or if base or property is null -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-1572) getFirst() and getRows() methods in UIData don't return correct values
[ https://issues.apache.org/jira/browse/MYFACES-1572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12484691 ] Paul McMahan commented on MYFACES-1572: --- correction -- I meant to say the patch moves assignment of _rowsSet to the *setRows()* method getFirst() and getRows() methods in UIData don't return correct values -- Key: MYFACES-1572 URL: https://issues.apache.org/jira/browse/MYFACES-1572 Project: MyFaces Core Issue Type: Bug Components: JSR-252 Affects Versions: 1.2.0-SNAPSHOT Reporter: Paul McMahan Assigned To: Matthias Weßendorf Priority: Critical Fix For: 1.2.0-SNAPSHOT Attachments: MYFACES-1572.2.patch UIData data = new UIData(); data.setFirst(1); data.getFirst(); // returns 0 data.setRows(1); data.getRows(); // returns 0 Looks like there may be a bug in the code generator. The setFirst() and setRows() methods should be assigning _firstSet=true and _rowsSet=true. Maybe there is some way to influence this behavior in UIData's template? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-1574) HtmlOutputLink returns the wrong renderer type
HtmlOutputLink returns the wrong renderer type
--
Key: MYFACES-1574
URL: https://issues.apache.org/jira/browse/MYFACES-1574
Project: MyFaces Core
Issue Type: Bug
Components: JSR-252
Affects Versions: 1.2.0-SNAPSHOT
Reporter: Paul McMahan
The generated java src for javax.faces.component.html.HtmlOutputLink sets the
renderer type to javax.faces.Label :
public HtmlOutputLink()
{
setRendererType(javax.faces.Label);
}
It should instead set the renderer type to javax.faces.Link
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-1575) MethodBinding.invoke() should provide cause exception
[ https://issues.apache.org/jira/browse/MYFACES-1575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul McMahan updated MYFACES-1575: -- Status: Patch Available (was: Open) MethodBinding.invoke() should provide cause exception - Key: MYFACES-1575 URL: https://issues.apache.org/jira/browse/MYFACES-1575 Project: MyFaces Core Issue Type: Bug Components: JSR-252 Affects Versions: 1.2.0-SNAPSHOT Reporter: Paul McMahan Attachments: MYFACES-1575.patch When javax.faces.el.MethodBinding.invoke() catches an Exception the EvaluationException it subsequently throws should include the cause property of the original exception. See: http://java.sun.com/javaee/5/docs/api/javax/faces/el/MethodBinding.html#invoke(javax.faces.context.FacesContext,%20java.lang.Object[])exception) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-1576) PropertyResolver.getType() should check arguments
PropertyResolver.getType() should check arguments - Key: MYFACES-1576 URL: https://issues.apache.org/jira/browse/MYFACES-1576 Project: MyFaces Core Issue Type: Bug Components: JSR-252 Affects Versions: 1.2.0-SNAPSHOT Reporter: Paul McMahan According to the spec PropertyResolver.getType(Object, int) should throw PropertyNotFoundException when the int is out of bounds or Object is null. Also PropertyResolver.getType(Object, property) should throw PropertyNotFoundException when property is null. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-1576) PropertyResolver.getType() should check arguments
[ https://issues.apache.org/jira/browse/MYFACES-1576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul McMahan updated MYFACES-1576: -- Status: Patch Available (was: Open) PropertyResolver.getType() should check arguments - Key: MYFACES-1576 URL: https://issues.apache.org/jira/browse/MYFACES-1576 Project: MyFaces Core Issue Type: Bug Components: JSR-252 Affects Versions: 1.2.0-SNAPSHOT Reporter: Paul McMahan Attachments: MYFACES-1576.patch According to the spec PropertyResolver.getType(Object, int) should throw PropertyNotFoundException when the int is out of bounds or Object is null. Also PropertyResolver.getType(Object, property) should throw PropertyNotFoundException when property is null. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-1572) getFirst() and getRows() methods in UIData don't return correct values
getFirst() and getRows() methods in UIData don't return correct values -- Key: MYFACES-1572 URL: https://issues.apache.org/jira/browse/MYFACES-1572 Project: MyFaces Core Issue Type: Bug Components: JSR-252 Affects Versions: 1.2.0-SNAPSHOT Reporter: Paul McMahan Priority: Critical UIData data = new UIData(); data.setFirst(1); data.getFirst(); // returns 0 data.setRows(1); data.getRows(); // returns 0 Looks like there may be a bug in the code generator. The setFirst() and setRows() methods should be assigning _firstSet=true and _rowsSet=true. Maybe there is some way to influence this behavior in UIData's template? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-1560) WebXmlParser should log debug instead of warn
WebXmlParser should log debug instead of warn - Key: MYFACES-1560 URL: https://issues.apache.org/jira/browse/MYFACES-1560 Project: MyFaces Core Issue Type: Bug Components: JSR-252 Affects Versions: 1.2.0-SNAPSHOT Reporter: Paul McMahan Priority: Minor When WebXmlParser ignores a child of servlet or filter it logs a debug message, as expected. However, when it ignores a child of servlet-mapping or filter-mapping it logs a warning message. It should log a debug message instead. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-1560) WebXmlParser should log debug instead of warn
[ https://issues.apache.org/jira/browse/MYFACES-1560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul McMahan updated MYFACES-1560: -- Status: Patch Available (was: Open) WebXmlParser should log debug instead of warn - Key: MYFACES-1560 URL: https://issues.apache.org/jira/browse/MYFACES-1560 Project: MyFaces Core Issue Type: Bug Components: JSR-252 Affects Versions: 1.2.0-SNAPSHOT Reporter: Paul McMahan Priority: Minor Attachments: MYFACES-1560.patch When WebXmlParser ignores a child of servlet or filter it logs a debug message, as expected. However, when it ignores a child of servlet-mapping or filter-mapping it logs a warning message. It should log a debug message instead. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-1553) CONVERTER_ID for DoubleConverter doesn't match 1.2 spec
CONVERTER_ID for DoubleConverter doesn't match 1.2 spec --- Key: MYFACES-1553 URL: https://issues.apache.org/jira/browse/MYFACES-1553 Project: MyFaces Core Issue Type: Bug Components: JSR-252 Affects Versions: 1.2.0-SNAPSHOT Reporter: Paul McMahan The JSF 1.2 API says that the value of DoubleConverter.CONVERTER_ID should be javax.faces.DoubleTime -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-1246) JSR-252 Issue #119: implementations running in a JSR-250 container have their managed bean methods annotated with @PostConstruct be called after the object is instanti
[ https://issues.apache.org/jira/browse/MYFACES-1246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12475588 ] Paul McMahan commented on MYFACES-1246: --- Dennis, sorry I can see how my comment could be easily misunderstood. Yes I agree that MyFaces shoiuld support the @PostConstruct and @PreDestroy annotations with or without a full JEE container. My comments were mainly in reaction to Mathias' observation that MyFaces should also provide support for resource injection when running in a JEE container. If you agree with Mathias and want to tackle JEE resource injection as part of this JIRA then I wanted to let you know about Geronimo's current level of support for annotations, which discovers annotations and handles resource injection in servlets, filters, and listeners but not in managed beans. To add support for resource injection in managed beans we could take the approach that Mathias recommends where the JEE container implements an InjectionProvider interface. Geronimo is currently using MyFaces for JSF 1.2 support so as a Geronimo committer I can work with you on defining and testing this interface. Hope this makes better sense now. JSR-252 Issue #119: implementations running in a JSR-250 container have their managed bean methods annotated with @PostConstruct be called after the object is instantiated, and after injection is performed, but before the bean is placed into scope. Key: MYFACES-1246 URL: https://issues.apache.org/jira/browse/MYFACES-1246 Project: MyFaces Core Issue Type: New Feature Components: JSR-252 Reporter: Stan Silvert Assigned To: Dennis Byrne Specified that implementations running in a JSR-250 compliant container have their managed bean methods annotated with @PostConstruct be called after the object is instantiated, and after injection is performed, but before the bean is placed into scope. Specified that methods annotated with @PreDestroy be called when the scope for the bean is ending. See https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=252 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-1536) Resolvers assume that all JSPs produce a FacesContext
Resolvers assume that all JSPs produce a FacesContext
--
Key: MYFACES-1536
URL: https://issues.apache.org/jira/browse/MYFACES-1536
Project: MyFaces Core
Issue Type: Bug
Components: JSR-252
Affects Versions: 1.2.0-SNAPSHOT
Reporter: Paul McMahan
Priority: Critical
It seems that when MyFaces has been enabled it assumes that all the JSPs in a
web app will produce a FacesContext. But that's not the case for JSPs like the
following:
%@ taglib prefix=c uri=http://java.sun.com/jsp/jstl/core; %
%
java.util.ArrayList mylist = new java.util.ArrayList();
mylist.add(one);
mylist.add(two);
mylist.add(three);
pageContext.setAttribute(mylist, mylist);
%
c:forEach var=x items=${mylist}
p${x}/p
/c:forEach
And the error is:
java.lang.NullPointerException
org.apache.myfaces.el.unified.resolver.ManagedBeanResolver.externalContext(ManagedBeanResolver.java:217)
org.apache.myfaces.el.unified.resolver.ManagedBeanResolver.getValue(ManagedBeanResolver.java:146)
javax.el.CompositeELResolver.getValue(CompositeELResolver.java:53)
javax.el.CompositeELResolver.getValue(CompositeELResolver.java:53)
org.apache.el.parser.AstIdentifier.getValue(AstIdentifier.java:45)
org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:186)
org.apache.jasper.el.JspValueExpression.getValue(JspValueExpression.java:101)
org.apache.jsp.index_jsp._jspx_meth_c_005fforEach_005f0(index_jsp.java:95)
org.apache.jsp.index_jsp._jspService(index_jsp.java:68)
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:98)
javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:384)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:320)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:266)
javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
This looks like there's a problem in the resolvers where the ELContext is
expected to always have a FacesContext.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
