[jira] Updated: (TRINIDAD-1482) Facelets: cannot use facelets.VIEW_MAPPINGS with logical view handled by PageResolver
[ https://issues.apache.org/jira/browse/TRINIDAD-1482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthias Weßendorf updated TRINIDAD-1482: - Resolution: Fixed Fix Version/s: 1.2.12-core Assignee: Matthias Weßendorf Status: Resolved (was: Patch Available) Facelets: cannot use facelets.VIEW_MAPPINGS with logical view handled by PageResolver --- Key: TRINIDAD-1482 URL: https://issues.apache.org/jira/browse/TRINIDAD-1482 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 1.2.11-core Reporter: Max Starets Assignee: Matthias Weßendorf Fix For: 1.2.12-core Attachments: trinidad.patch Unfortunately, Facelets provides no hook for plugging the PageResolver into the logic handling facelets.VIEW_MAPPINGS. The only possible fix for this at the moment for us is to define our own context parameter and check for the extension/prefix mapping match in TrinidadFaceletViewHandler. We will recommend that our users leave facelets.VIEW_MAPPINGS unset and use org.apache.myfaces.trinidad.FACELETS_VIEW_MAPPINGS instead. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-1484) Change Trinidad metadata (build .xml files) to use jsr-276 metadata standard
[ https://issues.apache.org/jira/browse/TRINIDAD-1484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthias Weßendorf updated TRINIDAD-1484: - Resolution: Fixed Fix Version/s: 1.2.10-plugins 1.2.12-core Assignee: Matthias Weßendorf Status: Resolved (was: Patch Available) Change Trinidad metadata (build .xml files) to use jsr-276 metadata standard Key: TRINIDAD-1484 URL: https://issues.apache.org/jira/browse/TRINIDAD-1484 Project: MyFaces Trinidad Issue Type: New Feature Components: Build Affects Versions: 1.2.11-core Reporter: Bill Baggett Assignee: Matthias Weßendorf Fix For: 1.2.12-core, 1.2.10-plugins Attachments: final-metadata-plugin-fix.patch, jsr276_changes.patch This covers the final changes needed to move the Trinidad metadata (ie build .xml files) to use the jsr-276 metadata standard. Note that there were 2 previous jira's for changes in the plugins. This includes 2 patches. The first patch is one last change for the plugins. The second patch contains the new metadata in the jsr-276 format (plus it contains 1 change to the impl test framework that was dependent on a metadata element). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-1879) Problems with myfaces when java2 security is enabled
[
https://issues.apache.org/jira/browse/MYFACES-1879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12711977#action_12711977
]
Matthias Weßendorf commented on MYFACES-1879:
-
can you add this to myfaces 2.0 `?
Problems with myfaces when java2 security is enabled
Key: MYFACES-1879
URL: https://issues.apache.org/jira/browse/MYFACES-1879
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 1.2.3
Reporter: Michael Concini
Assignee: Leonardo Uribe
Fix For: 1.2.7-SNAPSHOT
Attachments: MYFACES-1879-core-v2.patch, MYFACES-1879-core.patch,
MYFACES-1879-shared-v2.patch, MYFACES-1879-shared.patch
When running MyFaces 1.2 on an application server with java2 security turned
on, a user can receive an AccessControlException from several locations
within the code, in some cases preventing the application from working in the
environment.
There are several places in the myfaces code that should be updated to
include a doPriv when java2 security is on. Specifically in locations where
the code is executing a call to
Thread.currentThread().getContextClassLoader(), as well as in the
JspStateManagerImpl's deserializeView() method.
for example (in the classloader case):
if (System.getSecurityManager() != null) {
try {
Object cl = AccessController.doPrivileged(new
PrivilegedExceptionAction() {
public Object run() throws
PrivilegedActionException {
return
Thread.currentThread().getContextClassLoader();
}
});
return (ClassLoader) cl;
} catch (PrivilegedActionException pae) {
throw new FacesException(pae);
}
}else{
return Thread.currentThread().getContextClassLoader();
}
If its agreed that the change should be implemented, I'd be happy to perform
the changes myself and supply a patch. I also thought that it might make
sense to, at least for the ClassLoader lookup, create a method in ClassUtils
called getContextClassloader that could be called elsewhere for efficiency's
sake.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-1975) HtmlResponseStateManager.getSavedState() should handle javax.faces.ViewState=
[ https://issues.apache.org/jira/browse/MYFACES-1975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12711978#action_12711978 ] Matthias Weßendorf commented on MYFACES-1975: - can you add this to myfaces 2.0 ? HtmlResponseStateManager.getSavedState() should handle javax.faces.ViewState= --- Key: MYFACES-1975 URL: https://issues.apache.org/jira/browse/MYFACES-1975 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 1.2.3 Environment: Any Reporter: Curtiss Howard Assignee: Leonardo Uribe Priority: Minor Fix For: 1.1.7-SNAPSHOT, 1.2.7-SNAPSHOT Attachments: MYFACES-1975.patch Original Estimate: 0.08h Remaining Estimate: 0.08h HtmlResponseStateManager.getSavedState() does not seem to handle the request attribute javax.faces.ViewState being an empty string. That is to say, when the request attribute does not exist, a new state is created, but otherwise an attempt is made to reconstruct the view state. In the case that the attribute is an empty string, you'll get an exception similar to the following: javax.faces.FacesException: java.io.EOFException at org.apache.myfaces.shared_impl.util.StateUtils.getAsObject(StateUtils.java:350) at org.apache.myfaces.shared_impl.util.StateUtils.reconstruct(StateUtils.java:246) at org.apache.myfaces.renderkit.html.HtmlResponseStateManager.getSavedState(HtmlResponseStateManager.java:188) at org.apache.myfaces.renderkit.html.HtmlResponseStateManager.getTreeStructureToRestore(HtmlResponseStateManager.java:149) This does not occur on the Sun RI implementation (i.e., it returns a new state in this case), and I think due to this being an issue that should be handled (and a trivial change to boot) that it should be fixed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2007) Converters are not created properly when target class is both, an enum and implements an interface
[
https://issues.apache.org/jira/browse/MYFACES-2007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12711979#action_12711979
]
Matthias Weßendorf commented on MYFACES-2007:
-
can you add this to myfaces 2.0 ?
Converters are not created properly when target class is both, an enum and
implements an interface
--
Key: MYFACES-2007
URL: https://issues.apache.org/jira/browse/MYFACES-2007
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 1.2.4
Reporter: Val Blant
Assignee: Leonardo Uribe
Fix For: 1.2.7-SNAPSHOT
Attachments: myfaces-2007.patch
This patch fixes the following situation:
- A converter is bound in faces-config.xml to an interface type (ex.
EnumCoded).
- There is an enum class that implements EnumCoded, like this:
public enum PickListActionType implements EnumCoded { . etc... }
- There is a converter called a GenericEnumTypeConverter, which knows how to
deal with these and is declared like this:
converter
converter-for-classEnumCoded/converter-for-class
converter-classGenericEnumTypeConverter/converter-class
/converter
- Right now the converter picked by MyFaces is EnumConverter instead of my
GenericEnumTypeConverter, b/c the fact that my target class is an enum takes
precedence over the fact that it implements EnumCoded interface. This is
incorrect.
This patch fixes the problem.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2099) Detection of empty selection in UISelectOne through RenderUtils.NOTHING is faulty
[
https://issues.apache.org/jira/browse/MYFACES-2099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12711980#action_12711980
]
Matthias Weßendorf commented on MYFACES-2099:
-
can you add this to myfaces 2.0 ?
Detection of empty selection in UISelectOne through RenderUtils.NOTHING is
faulty
-
Key: MYFACES-2099
URL: https://issues.apache.org/jira/browse/MYFACES-2099
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 1.1.7-SNAPSHOT, 1.2.6-SNAPSHOT
Environment: All
Reporter: Andreas Watermeyer
Assignee: Leonardo Uribe
Fix For: 1.1.7-SNAPSHOT, 1.2.7-SNAPSHOT
RendererUtils.getConvertedUIOutputValue() throws an IllegalArgumentException
because it does not recognize RendererUtils.NOTHING (see stacktrace below).
Problem is the following code, taken from
RendererUtils.getConvertedUIOutputValue():
public static Object getConvertedUIOutputValue(FacesContext facesContext,
UIOutput output,
Object submittedValue)
throws ConverterException {
if (submittedValue != null !(submittedValue instanceof String)) {
if (RendererUtils.NOTHING.equals(submittedValue)) {
return null;
}
throw new IllegalArgumentException(Submitted value of type
String for component : +
getPathToComponent(output) + expected);
}
Problem: In my case submittedValue *is* an instance of
RendererUtils.NOTHING. However, this is not recognized by the above code
because it was serialized.
As one can see at the declaration of RendererUtils.NOTHING, it is
intentionally Serializable. Unfortunately the detection of the value works
only for not-serialized values.
Possible solution: Implement RendererUtils.NOTHING.equals() to recognize
serialized versions of RendererUtils.NOTHING.
Application Background (Further explanation of the context):
During apply request values the component gets RendererUtils.NOTHING
assigned as submittedValue. Usually the submitted value is resetted in the
process validations phase. But in this case process validations is never
executed because FacesContext.renderResponse() is called earlier. So, the
submitted value (= RendererUtils.NOTHING) remains in the component, gets
serialized. On the next round trip the component doesnt receive a process
decodes because it is disabled, but process validations is called on the
component, which fails with the attached stack trace.
-
Stacktrace:
java.lang.IllegalArgumentException: Submitted value of type String for
component : {.} expected
org.apache.myfaces.shared_impl.renderkit.RendererUtils.getConvertedUIOutputValue(RendererUtils.java:591)
org.apache.myfaces.shared_impl.renderkit.html.HtmlMenuRendererBase.getConvertedValue(HtmlMenuRendererBase.java:126)
javax.faces.component.UIInput.getConvertedValue(UIInput.java:396)
javax.faces.component.UIInput.validate(UIInput.java:350)
javax.faces.component.UIInput.processValidators(UIInput.java:184)
javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:627)
javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:627)
javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:627)
javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:627)
javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:627)
javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:627)
javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:627)
javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:627)
javax.faces.component.UIForm.processValidators(UIForm.java:73)
javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:627)
javax.faces.component.UIViewRoot.processValidators(UIViewRoot.java:149)
org.apache.myfaces.lifecycle.ProcessValidationsExecutor.execute(ProcessValidationsExecutor.java:32)
org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:95)
org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:70)
javax.faces.webapp.FacesServlet.service(FacesServlet.java:139)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1485) jsr 303 support for client-side validation
jsr 303 support for client-side validation -- Key: TRINIDAD-1485 URL: https://issues.apache.org/jira/browse/TRINIDAD-1485 Project: MyFaces Trinidad Issue Type: New Feature Reporter: Gerhard Petracek jsr 303 specifies group validation - client-side validation currently doesn't support that -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1486) jsr 303 support for server-side validation
jsr 303 support for server-side validation -- Key: TRINIDAD-1486 URL: https://issues.apache.org/jira/browse/TRINIDAD-1486 Project: MyFaces Trinidad Issue Type: New Feature Reporter: Gerhard Petracek integration for jsr 303 constraint validation -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-1879) Problems with myfaces when java2 security is enabled
[
https://issues.apache.org/jira/browse/MYFACES-1879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12712086#action_12712086
]
Michael Concini commented on MYFACES-1879:
--
I can add it to the 2.0 stream. I'll take care of it next week once I'm back
from the US Memorial Day holiday.
Problems with myfaces when java2 security is enabled
Key: MYFACES-1879
URL: https://issues.apache.org/jira/browse/MYFACES-1879
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 1.2.3
Reporter: Michael Concini
Assignee: Leonardo Uribe
Fix For: 1.2.7-SNAPSHOT
Attachments: MYFACES-1879-core-v2.patch, MYFACES-1879-core.patch,
MYFACES-1879-shared-v2.patch, MYFACES-1879-shared.patch
When running MyFaces 1.2 on an application server with java2 security turned
on, a user can receive an AccessControlException from several locations
within the code, in some cases preventing the application from working in the
environment.
There are several places in the myfaces code that should be updated to
include a doPriv when java2 security is on. Specifically in locations where
the code is executing a call to
Thread.currentThread().getContextClassLoader(), as well as in the
JspStateManagerImpl's deserializeView() method.
for example (in the classloader case):
if (System.getSecurityManager() != null) {
try {
Object cl = AccessController.doPrivileged(new
PrivilegedExceptionAction() {
public Object run() throws
PrivilegedActionException {
return
Thread.currentThread().getContextClassLoader();
}
});
return (ClassLoader) cl;
} catch (PrivilegedActionException pae) {
throw new FacesException(pae);
}
}else{
return Thread.currentThread().getContextClassLoader();
}
If its agreed that the change should be implemented, I'd be happy to perform
the changes myself and supply a patch. I also thought that it might make
sense to, at least for the ClassLoader lookup, create a method in ClassUtils
called getContextClassloader that could be called elsewhere for efficiency's
sake.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1487) Improve the application view cache
Improve the application view cache -- Key: TRINIDAD-1487 URL: https://issues.apache.org/jira/browse/TRINIDAD-1487 Project: MyFaces Trinidad Issue Type: Improvement Reporter: Matthias Weßendorf We need to improve the Application View Cache feature. However, the issue is that at the very least, we would need to: 1) Switch to using per-page flags to turn it on. The default is off. This allows customers to explicitly turn on the AVC 2) Come up with a replacement for cases where we will break the AVC--for example any renderer that stores rendering information on a component (including the UIViewRoot) Detecting the cases where we are doing 2 is hard and still leaves possible problems with other renderers, or potentially the application itself. We might be able to do some autodetection for UIXComponent cases by integrating with the FacesBean in a similar way to the delta state saving, but we would still need to handle non-Trinidad Components like the UIViewRoot and it is possible that the application could still hose itself. In general, the kinds of failures that the application will see with the application view cache will not be obviously caused by the setting. Currently the application view cache is not supported. Once the Facelets support has improved we can see how much faster the cache is than Facelets before we decide whether it is worthwhile to make the investment necessary to make the application view cache acceptably robust. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[Tobago] site deployment
Hey Bernd, looking at MyFaces CORE, the deployed site is old. Looking at Trinidad, the site pretty old. Looking at Tobago, the site is fresh. Are you using the zone for the deployment ? -Matthias -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
[VOTE] SVN structure change (was: Re: [MyFaces CORE] SVN layout (was: Re: [source control] git and the ASF ...))
actually, I agree with Bernd. For the following layout: /trunk - 2.0 /branches/myfaces_1_1_x /branches/myfaces_1_2_x Two reasons for way making 2.0 trunk: -most current development is on-going in 2.0 (new spec) -most commits are going to the 2.0 branch (so, let's make it trunk) So, I am +1 on the above svn layout -Matthias On Sat, May 16, 2009 at 1:04 PM, Matthias Wessendorf mat...@apache.org wrote: from Bernd, on a different thread: Hello, I would suggest following layout 1.1.x branch/1.1.x 1.2.x branch/1.2.x 2.0.x trunk because the 2.0.x version is in development the other branches are only in bugfix state. On Fri, May 15, 2009 at 1:13 PM, Werner Punz werner.p...@gmail.com wrote: Matthias Wessendorf schrieb: Hi, ... Ok, I filed this: https://issues.apache.org/jira/browse/INFRA-2053 maybe we should also think about making the JSF 1.1.x stuff a branch ... (since we already work on 2.0.x) what do people think if the 1.2 stuff becomes trunk And the following efforts are on a branch: -2.0.x -1.1.x +1 -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
[jira] Commented: (MYFACES-1879) Problems with myfaces when java2 security is enabled
[
https://issues.apache.org/jira/browse/MYFACES-1879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12712201#action_12712201
]
Leonardo Uribe commented on MYFACES-1879:
-
I'll do an svn merge soon from 1.2 to 2.0, but still I need to solve other 1.2
branch issues. Please don't commit on 2.0 (makes more hard the merge)
Problems with myfaces when java2 security is enabled
Key: MYFACES-1879
URL: https://issues.apache.org/jira/browse/MYFACES-1879
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 1.2.3
Reporter: Michael Concini
Assignee: Leonardo Uribe
Fix For: 1.2.7-SNAPSHOT
Attachments: MYFACES-1879-core-v2.patch, MYFACES-1879-core.patch,
MYFACES-1879-shared-v2.patch, MYFACES-1879-shared.patch
When running MyFaces 1.2 on an application server with java2 security turned
on, a user can receive an AccessControlException from several locations
within the code, in some cases preventing the application from working in the
environment.
There are several places in the myfaces code that should be updated to
include a doPriv when java2 security is on. Specifically in locations where
the code is executing a call to
Thread.currentThread().getContextClassLoader(), as well as in the
JspStateManagerImpl's deserializeView() method.
for example (in the classloader case):
if (System.getSecurityManager() != null) {
try {
Object cl = AccessController.doPrivileged(new
PrivilegedExceptionAction() {
public Object run() throws
PrivilegedActionException {
return
Thread.currentThread().getContextClassLoader();
}
});
return (ClassLoader) cl;
} catch (PrivilegedActionException pae) {
throw new FacesException(pae);
}
}else{
return Thread.currentThread().getContextClassLoader();
}
If its agreed that the change should be implemented, I'd be happy to perform
the changes myself and supply a patch. I also thought that it might make
sense to, at least for the ClassLoader lookup, create a method in ClassUtils
called getContextClassloader that could be called elsewhere for efficiency's
sake.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ANNOUNCE] release of myfaces builder plugin 1.0.3
The Apache MyFaces team is pleased to announce the release of Apache MyFaces Builder Plugin and Annotations 1.0.3. Apache MyFaces Builder Plugin is a maven plugin, used internally in other projects like myfaces core and tomahawk for generate component classes, tag classes, faces-config files, .tld files and facelets taglib files. In other words, its several maven goals provide a component kit for generate jsf components with minimal effort. Apache Myfaces Builder Annotations is a set of annotations used by Myfaces Builder Plugin to define the metadata. Apache MyFaces Builder Plugin and Annotations is available in the central Maven repository under Group ID org.apache.myfaces.buildtools. Enjoy! Leonardo Uribe
Re: [VOTE] SVN structure change (was: Re: [MyFaces CORE] SVN layout (was: Re: [source control] git and the ASF ...))
Hello, +1 I would prefer /trunk - 2.0 /branches/myfaces-1.1.x /branches/myfaces-1.2.x because we are not using cvs anymore and the path already contains http://svn.apache.org/repos/asf/myfaces/core/ maybe we can omit the 'myfaces' in the branch name. Regards Bernd On Fri, May 22, 2009 at 5:27 PM, Matthias Wessendorf mat...@apache.org wrote: actually, I agree with Bernd. For the following layout: /trunk - 2.0 /branches/myfaces_1_1_x /branches/myfaces_1_2_x Two reasons for way making 2.0 trunk: -most current development is on-going in 2.0 (new spec) -most commits are going to the 2.0 branch (so, let's make it trunk) So, I am +1 on the above svn layout -Matthias On Sat, May 16, 2009 at 1:04 PM, Matthias Wessendorf mat...@apache.org wrote: from Bernd, on a different thread: Hello, I would suggest following layout 1.1.x branch/1.1.x 1.2.x branch/1.2.x 2.0.x trunk because the 2.0.x version is in development the other branches are only in bugfix state. On Fri, May 15, 2009 at 1:13 PM, Werner Punz werner.p...@gmail.com wrote: Matthias Wessendorf schrieb: Hi, ... Ok, I filed this: https://issues.apache.org/jira/browse/INFRA-2053 maybe we should also think about making the JSF 1.1.x stuff a branch ... (since we already work on 2.0.x) what do people think if the 1.2 stuff becomes trunk And the following efforts are on a branch: -2.0.x -1.1.x +1 -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
[jira] Created: (TRINIDAD-1488) ChangeManager: Ability to apply component changes to a subtree
ChangeManager: Ability to apply component changes to a subtree -- Key: TRINIDAD-1488 URL: https://issues.apache.org/jira/browse/TRINIDAD-1488 Project: MyFaces Trinidad Issue Type: New Feature Components: Archetype Affects Versions: 1.2.11-core Reporter: Andy Schwartz Priority: Minor The ChangeManager currently only supports applying component changes to the entire view. This is accomplished via the following API: public void applyComponentChangesForCurrentView(FacesContext facesContext) I would like to have the ability to apply component changes to a specific subtree as opposed to the entire view. This would require a new API along the lines of: public void applyComponentChangesForSubtree(FacesContext facesContext, NamingContainer root) Note that this method would operate on a subtree rooted at a NamingContainer in order to allow ChangeManager to easily filter the component changes based on id comparisons. (SessionChangeManager already has access to scoped ids for each component change, so checking whether a particular change is applicable by examining the id should be very efficient.) The reason for requesting this new API is that I have cases where portions of the subtree are created dynamically at render time, after applyComponentChangesForCurrentView() has been called. I need to be able to apply component changes directly to the newly created subtrees without re-applying the changes to the entire view. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TOMAHAWK-722) Javascript in Tomahawk components produces invalid markup when output as application/xhtml + xml with 1.2 RI
[ https://issues.apache.org/jira/browse/TOMAHAWK-722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12712282#action_12712282 ] Ramiro Pereira de Magalhães commented on TOMAHAWK-722: -- Wouldn't it be solved if someone changed method prepareScript on class HtmlRendererUtils (http://svn.apache.org/viewvc/myfaces/shared/trunk/core/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlRendererUtils.java?revision=613572pathrev=613572) so that it wrote those CDATA scapes after and before the whole script? Javascript in Tomahawk components produces invalid markup when output as application/xhtml + xml with 1.2 RI - Key: TOMAHAWK-722 URL: https://issues.apache.org/jira/browse/TOMAHAWK-722 Project: MyFaces Tomahawk Issue Type: Bug Affects Versions: 1.1.4-SNAPSHOT Environment: JSF 1.2_02 RI, JBoss 4.0.4 (tomcat 5.5), facelets Reporter: reind The JSF 1.2 RI will output to Content-Type application/xhtml+xml instead of text/html when a page is viewed with Firefox. Tomahawk components do not properly escape the Javascript when they're rendered as application/xhtml+xml and so they produce invalid markup and the pages are not displayed in Firefox. The fix is to enclose any javascript in CDATA elements like the following: script ![CDATA[ ... script content here ... -- ]] /script This was not a problem in the JSF 1.1 RI or MyFaces because they always output to text/html. Ref: 1. http://www.codehouse.com/javascript/tips/xhtml/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1489) get a valueChangeEvent for bigDecimal even though user didn't make a change.
get a valueChangeEvent for bigDecimal even though user didn't make a change. Key: TRINIDAD-1489 URL: https://issues.apache.org/jira/browse/TRINIDAD-1489 Project: MyFaces Trinidad Issue Type: Bug Reporter: Gabrielle Crawford When attribute data type is BigDecimal and af:convertNumber is used Trin treats the attribute as if the attribute value is changed even though the attribute value has not been changed. Under the covers the numberConverter is using the java decimalFormat class, and things can get a little funny when you use bigdecimal, because bigdecimal remembers formatting information like scale. So 2.0 is not equal to 2.00 in bigdecimal. We can add logic to UIXEditableValueHolder that if .equals fails and if the values are the same type and implement comparable we should then check compareTo. There are 2 workarounds for now. 1] apply the pattern to the bigdecimal in the getter, so in the salary example code above return newSal instead of sal. 2] check compareTo in the setter, and don't set if you get 0. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1489) get a valueChangeEvent for bigDecimal even though user didn't make a change.
[ https://issues.apache.org/jira/browse/TRINIDAD-1489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12712307#action_12712307 ] Gabrielle Crawford commented on TRINIDAD-1489: -- added a test case on 1.2.11.3 branch to see 'before' behavior in revision: 41 get a valueChangeEvent for bigDecimal even though user didn't make a change. Key: TRINIDAD-1489 URL: https://issues.apache.org/jira/browse/TRINIDAD-1489 Project: MyFaces Trinidad Issue Type: Bug Reporter: Gabrielle Crawford When attribute data type is BigDecimal and af:convertNumber is used Trin treats the attribute as if the attribute value is changed even though the attribute value has not been changed. Under the covers the numberConverter is using the java decimalFormat class, and things can get a little funny when you use bigdecimal, because bigdecimal remembers formatting information like scale. So 2.0 is not equal to 2.00 in bigdecimal. We can add logic to UIXEditableValueHolder that if .equals fails and if the values are the same type and implement comparable we should then check compareTo. There are 2 workarounds for now. 1] apply the pattern to the bigdecimal in the getter, so in the salary example code above return newSal instead of sal. 2] check compareTo in the setter, and don't set if you get 0. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (TRINIDAD-1489) get a valueChangeEvent for bigDecimal even though user didn't make a change.
[ https://issues.apache.org/jira/browse/TRINIDAD-1489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12712307#action_12712307 ] Gabrielle Crawford edited comment on TRINIDAD-1489 at 5/22/09 4:33 PM: --- added a test case on 1.2.11.3 branch to see 'before' behavior in revision: 41 http://svn.apache.org/viewvc?view=revrevision=41 was (Author: gabrielle): added a test case on 1.2.11.3 branch to see 'before' behavior in revision: 41 get a valueChangeEvent for bigDecimal even though user didn't make a change. Key: TRINIDAD-1489 URL: https://issues.apache.org/jira/browse/TRINIDAD-1489 Project: MyFaces Trinidad Issue Type: Bug Reporter: Gabrielle Crawford When attribute data type is BigDecimal and af:convertNumber is used Trin treats the attribute as if the attribute value is changed even though the attribute value has not been changed. Under the covers the numberConverter is using the java decimalFormat class, and things can get a little funny when you use bigdecimal, because bigdecimal remembers formatting information like scale. So 2.0 is not equal to 2.00 in bigdecimal. We can add logic to UIXEditableValueHolder that if .equals fails and if the values are the same type and implement comparable we should then check compareTo. There are 2 workarounds for now. 1] apply the pattern to the bigdecimal in the getter, so in the salary example code above return newSal instead of sal. 2] check compareTo in the setter, and don't set if you get 0. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1489) get a valueChangeEvent for bigDecimal even though user didn't make a change.
[
https://issues.apache.org/jira/browse/TRINIDAD-1489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12712312#action_12712312
]
Gabrielle Crawford commented on TRINIDAD-1489:
--
Currently there's this code in UIXEditableValue
protected boolean compareValues(Object previous, Object value)
{
if (isEmpty(previous))
return !isEmpty(value);
return !previous.equals(value);
}
The fix being proposed is that if the .equals fails we'll check if the two
values are
1. the same type
2. implement comparable
and if 1 and 2 are true we'll use compareTo
get a valueChangeEvent for bigDecimal even though user didn't make a change.
Key: TRINIDAD-1489
URL: https://issues.apache.org/jira/browse/TRINIDAD-1489
Project: MyFaces Trinidad
Issue Type: Bug
Reporter: Gabrielle Crawford
When attribute data type is BigDecimal and af:convertNumber is used Trin
treats the attribute as if the attribute value is changed even though the
attribute value has not been changed.
Under the covers the numberConverter is using the java decimalFormat class,
and things can get a little funny when you use bigdecimal, because bigdecimal
remembers formatting information like scale. So 2.0 is not equal to 2.00 in
bigdecimal.
We can add logic to UIXEditableValueHolder that if .equals fails and if the
values are the same type and implement comparable we should then check
compareTo.
There are 2 workarounds for now.
1] apply the pattern to the bigdecimal in the getter, so in the salary
example code above return newSal instead of sal.
2] check compareTo in the setter, and don't set if you get 0.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (TRINIDAD-1489) get a valueChangeEvent for bigDecimal even though user didn't make a change.
[ https://issues.apache.org/jira/browse/TRINIDAD-1489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12712307#action_12712307 ] Gabrielle Crawford edited comment on TRINIDAD-1489 at 5/22/09 4:44 PM: --- added a test case on 1.2.11.3 branch to see 'before' behavior in revision: 41 http://svn.apache.org/viewvc?view=revrevision=41 If you run the demo page, and don't change anything, but just hit the submit button on the test page you get a valueChangeEvent fired for the inputText with bigdecimal, even though you didn't change anything. was (Author: gabrielle): added a test case on 1.2.11.3 branch to see 'before' behavior in revision: 41 http://svn.apache.org/viewvc?view=revrevision=41 get a valueChangeEvent for bigDecimal even though user didn't make a change. Key: TRINIDAD-1489 URL: https://issues.apache.org/jira/browse/TRINIDAD-1489 Project: MyFaces Trinidad Issue Type: Bug Reporter: Gabrielle Crawford When attribute data type is BigDecimal and af:convertNumber is used Trin treats the attribute as if the attribute value is changed even though the attribute value has not been changed. Under the covers the numberConverter is using the java decimalFormat class, and things can get a little funny when you use bigdecimal, because bigdecimal remembers formatting information like scale. So 2.0 is not equal to 2.00 in bigdecimal. We can add logic to UIXEditableValueHolder that if .equals fails and if the values are the same type and implement comparable we should then check compareTo. There are 2 workarounds for now. 1] apply the pattern to the bigdecimal in the getter, so in the salary example code above return newSal instead of sal. 2] check compareTo in the setter, and don't set if you get 0. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
UIXEditableValue compareValues change
Hi, I was planning on making a change to UIXEditableValue.compareValues. The details are here: https://issues.apache.org/jira/browse/TRINIDAD-1489 I don't think this is an issue, but since this is some really core code that's run for form controls I thought I'd see if anyone has objections. Thanks, Gabrielle
