Re: [Trinidad 2] Introduce a component context stack in Trinidad to deal with visit tree calls
I agree with not controlling the UIViewRoot -Matthias On Tue, Sep 21, 2010 at 12:44 PM, MAX STARETS max.star...@oracle.com wrote: Hi Andrew, I think I would rather require tr:document or trh:body (vs. tr:html) We already say in our documentation that one of these tags is required for PPR to work. Max On 9/21/2010 3:09 PM, Andrew Robinson wrote: Trinidad IMO should not be controlling the UIViewRoot, that is for the container to create. If we overrode it, it could also cause problems with portals. I think it best that we handle this in tr:document and trh:html as they should be the root elements of a Trinidad page. I am concerned that if we override the view root it will cause other issues or implementation problems. On Tue, Sep 21, 2010 at 12:44 PM, Pavitra Subramaniam pavitra.subraman...@oracle.com wrote: Hello Andrew, One comment regarding your changes in: +public abstract class UIXDocumentTemplate + extends UIXComponentBase Overall your fixes look fine to me, but I was wondering if rather than adding the override methods to the new class UIXDocument class, if instead this should be moved out of the UIXDocument and into a UIViewRoot subclass. For a different issue (of re-entrant calls to visitTree not properly suspending and restoring context) that I encountered, I had a similar fix in mind but after discussing with Blake he proposed that adding it to UIViewRoot subclass may be a better option. Thanks Pavitra On 9/21/2010 9:43 AM, Andrew Robinson wrote: Please see JIRA: https://issues.apache.org/jira/browse/TRINIDAD-1919 I want to propose adding a set of APIs to Trinidad2 that will allow component authors to suspend changes and resume changes before and after an invokeOnComponent or visitTree call. Currently, component context is not reverted during these calls, and bugs may result. The proposed changes would allow components to tear down and set back up their context over one of these calls. I have attached a way to reproduce the issue and my proposed patch to the bug. I'll wait a few days for feedback before going ahead and committing it. Thank you, Andrew -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Release of Tobago 1.5.0-alpha-2?
Hello II think it's time for a first public alpha of Tobago 1.5.0. Any objections? Regards Bernd
Re: submittedValue vs. Converter.getAsObject
Hi, I've just read Leonardo's post at jsr-314-open about this problem. FYI: I have finished prototype of JSF server side solution with non-String communication. It's based on custom renderkit and ResponseWriter implementation. I found only one major problem: this one discussed in this mail thread. Minor thing is string-based naming and meaning of ResponseWriter methods, because ResponseWriter is an abstract class describing an adapter to an underlying output mechanism for *character*-based output (from javadoc), but fortunately all methods accept Object as value. Regards, Kočičák Leonardo Uribe píše v St 08. 09. 2010 v 10:34 -0500: Hi Martin 2010/9/8 Martin Marinschek mmarinsc...@apache.org Hi Leo, Yes, to solve the problem with t:inputCalendar and t:inputDate it was clear an interface like that was necessary but it is tied to java.util.Date in this case: We could open an issue to make this more generic - and have an infrastructure in the impl where we can register such converters. Then we could use them for such use-cases as we have, and also for Martin's use-cases. Ok, I'll check in deep what trinidad does and why and later I'll open an issue for this one on the jsf spec issue tracker. best regards, Leonardo best regards, Martin -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: [jsr-314-open] JSF gathering @ JavaOne (was Re: MyFaces @JavaOne?)
Hello everyone, Let's meet at the Thirsty Bear instead, so people can show up later if necessary. I'm doing a podcast with Dan Allen until 6 or so. What's the best time for everyone? Sent from my iPhone http://www.jsfcentral.com http://www.Virtua.com On Sep 22, 2010, at 2:43 PM, Hazem Saleh haz...@apache.org wrote: +1 for Jankees On Wed, Sep 22, 2010 at 1:21 PM, Jan-Kees van Andel jankeesvanan...@gmail.com wrote: +1 for Thursday. I think my Thursday night is still free. How about meeting at the Hilton, after my talk? According to the current schedule, it's in the Continental Parlor 1/2/3 in the Hilton from 15:30 to 16:30. /JK 2010/9/21 Edward Burns edward.bu...@oracle.com On 9/20/10 23:13 , Kito Mann wrote: We're thinking Thursday might be good for some drinks, if anyone is still around. That would be better for me, actually. I double booked myself for Wednesday night. Kito, thanks for taking point on this one. Ed -- Hazem Ahmed Saleh Ahmed Author of (The Definitive Guide to Apache MyFaces and Facelets): http://www.amazon.com/Definitive-Guide-Apache-MyFaces-Facelets/dp/1590597370 http://www.amazon.com/-/e/B002M052KY Web blog: http://www.jroller.com/HazemBlog [Web 2.0] Mashups Integration with JSF: http://code.google.com/p/mashups4jsf/
Re: [jsr-314-open] JSF gathering @ JavaOne (was Re: MyFaces @JavaOne?)
On Thu, 23 Sep 2010 12:54:09 -0700, Kito Mann kito.m...@virtua.com said: Kito Hello everyone, Kito Let's meet at the Thirsty Bear instead, so people can show up later if Kito necessary. I'm doing a podcast with Dan Allen until 6 or so. What's the best Kito time for everyone? 7pm. Can you please tweet it out liberally? -- | edward.bu...@oracle.com | office: +1 407 458 0017 | homepage: | http://ridingthecrest.com/ | 1 work days until handoff of JSF 2.1 change log to jcp | 0 work days until JavaOne 2010 | 35 work days until DOAG 2010 | 39 work days until JSF 2.1 Milestone 6
Re: submittedValue vs. Converter.getAsObject
Hi Ok, good to know that. Anyway, I think a full solution should something like the proposed solution. Let's see what happen, and if it is not included maybe we could include it on a project in myfaces (myfaces commons or tomahawk maybe). regards, Leonardo Uribe 2010/9/23 Martin Koci martin.kocicak.k...@gmail.com Hi, I've just read Leonardo's post at jsr-314-open about this problem. FYI: I have finished prototype of JSF server side solution with non-String communication. It's based on custom renderkit and ResponseWriter implementation. I found only one major problem: this one discussed in this mail thread. Minor thing is string-based naming and meaning of ResponseWriter methods, because ResponseWriter is an abstract class describing an adapter to an underlying output mechanism for *character*-based output (from javadoc), but fortunately all methods accept Object as value. Regards, Kočičák Leonardo Uribe píše v St 08. 09. 2010 v 10:34 -0500: Hi Martin 2010/9/8 Martin Marinschek mmarinsc...@apache.org Hi Leo, Yes, to solve the problem with t:inputCalendar and t:inputDate it was clear an interface like that was necessary but it is tied to java.util.Date in this case: We could open an issue to make this more generic - and have an infrastructure in the impl where we can register such converters. Then we could use them for such use-cases as we have, and also for Martin's use-cases. Ok, I'll check in deep what trinidad does and why and later I'll open an issue for this one on the jsf spec issue tracker. best regards, Leonardo best regards, Martin -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
[JavaOne] Apache MyFaces talk and Google Summer of Code
FYI, our Apache MyFaces talk contained a good amount of the HTML5 project that has been done during Summer of Code. Ali Ok was with me on stage to demonstrate his project. He did a good presentation! I am also very happy that he, as a GSOC student, could attend to join my session! BTW the session was packed and folks liked what they saw, including Trinidad mobile, HTML-5 and our JSR-299 extensions. Greetings, Matthias -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [JavaOne] Apache MyFaces talk and Google Summer of Code
hey, congratulations! really cool to hear! LieGrue, strub --- On Thu, 9/23/10, Matthias Wessendorf mat...@apache.org wrote: From: Matthias Wessendorf mat...@apache.org Subject: [JavaOne] Apache MyFaces talk and Google Summer of Code To: MyFaces Development dev@myfaces.apache.org, code-awa...@apache.org Date: Thursday, September 23, 2010, 8:48 PM FYI, our Apache MyFaces talk contained a good amount of the HTML5 project that has been done during Summer of Code. Ali Ok was with me on stage to demonstrate his project. He did a good presentation! I am also very happy that he, as a GSOC student, could attend to join my session! BTW the session was packed and folks liked what they saw, including Trinidad mobile, HTML-5 and our JSR-299 extensions. Greetings, Matthias -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
[jira] Created: (TRINIDAD-1922) In Facelets, Partial Refreshing tr:inputText Not Working
In Facelets, Partial Refreshing tr:inputText Not Working
--
Key: TRINIDAD-1922
URL: https://issues.apache.org/jira/browse/TRINIDAD-1922
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Affects Versions: 2.0.0.3-core
Environment: Any browser
Reporter: Mamallan Uthaman
Trinidad currently has an issue partial refreshing an tr:inputText. This
problem is specific to facelets where we use JSF Ajax apis. I tested with the
latest code from our trunk, and below is my test page:
!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN
http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd;
ui:composition xmlns:ui=http://java.sun.com/jsf/facelets;
xmlns:f=http://java.sun.com/jsf/core;
xmlns:tr=http://myfaces.apache.org/trinidad;
xmlns:trd=http://myfaces.apache.org/trinidad/demo;
xmlns:trh=http://myfaces.apache.org/trinidad/html;
tr:document id=d1 title=Client Behavior Support
tr:form id=f1
tr:panelHeader text=Ajax Issue/
tr:panelHorizontalLayout
tr:commandLink text=Press id=cb1 partialSubmit=true
tr:setActionListener from=Success
to=#{sessionScope.status}/
/tr:commandLink
tr:inputText value=#{sessionScope.status}
partialTriggers=cb1 columns=6/
/tr:panelHorizontalLayout
/tr:form
/tr:document
/ui:composition
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jsr-314-open] JSF gathering @ JavaOne (was Re: MyFaces @JavaOne?)
Ok. 7pm at Thirsty Bear it is. See you guys there! Sent from my iPhone http://www.jsfcentral.com http://www.Virtua.com On Sep 23, 2010, at 1:21 PM, Ed Burns edward.bu...@oracle.com wrote: On Thu, 23 Sep 2010 12:54:09 -0700, Kito Mann kito.m...@virtua.com said: Kito Hello everyone, Kito Let's meet at the Thirsty Bear instead, so people can show up later if Kito necessary. I'm doing a podcast with Dan Allen until 6 or so. What's the best Kito time for everyone? 7pm. Can you please tweet it out liberally? -- | edward.bu...@oracle.com | office: +1 407 458 0017 | homepage: | http://ridingthecrest.com/ | 1 work days until handoff of JSF 2.1 change log to jcp | 0 work days until JavaOne 2010 | 35 work days until DOAG 2010 | 39 work days until JSF 2.1 Milestone 6
[jira] Resolved: (PORTLETBRIDGE-170) Portlet 2.0 Bridge: Make routine/debug logging configurable.
[ https://issues.apache.org/jira/browse/PORTLETBRIDGE-170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Freedman resolved PORTLETBRIDGE-170. Fix Version/s: 2.0.0 Resolution: Fixed Done -- now there is a myFaces Bridge specific config parameter to turn on debug messages: initParam nameorg.apache.myfaces.portlet.faces.loggingEnabled/name valuetrue/value /initParam) Portlet 2.0 Bridge: Make routine/debug logging configurable. - Key: PORTLETBRIDGE-170 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-170 Project: MyFaces Portlet Bridge Issue Type: Bug Components: Impl Affects Versions: 2.0.0-beta Reporter: Michael Freedman Assignee: Michael Freedman Fix For: 2.0.0 At some point in the future we need to implement a real logging mechanism (Apache logging?) but until them at least make the simplified logging that we do configurable on a per portlet basis so that its not on by default. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (PORTLETBRIDGE-171) Portlet 2.0 Bridge: update impl to support spec change for turing DIRECT_LINKs into absolute paths in encodeActionURL
Portlet 2.0 Bridge: update impl to support spec change for turing DIRECT_LINKs into absolute paths in encodeActionURL - Key: PORTLETBRIDGE-171 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-171 Project: MyFaces Portlet Bridge Issue Type: Bug Components: Impl Affects Versions: 2.0.0-beta Reporter: Michael Freedman Assignee: Michael Freedman Old version of the spec required developers only mark urls being action encoded with the DIRECT_LINK tag if an absolute url. Based on user feedback the spec changed to require encodeActionURL to turn any app relative DIRECT_LINKs into an absolute link before returning. Need to update the impl to reflect this change. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (PORTLETBRIDGE-171) Portlet 2.0 Bridge: update impl to support spec change for turing DIRECT_LINKs into absolute paths in encodeActionURL
[ https://issues.apache.org/jira/browse/PORTLETBRIDGE-171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Freedman resolved PORTLETBRIDGE-171. Fix Version/s: 2.0.0 Resolution: Fixed Code has been updated to do this. Portlet 2.0 Bridge: update impl to support spec change for turing DIRECT_LINKs into absolute paths in encodeActionURL - Key: PORTLETBRIDGE-171 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-171 Project: MyFaces Portlet Bridge Issue Type: Bug Components: Impl Affects Versions: 2.0.0-beta Reporter: Michael Freedman Assignee: Michael Freedman Fix For: 2.0.0 Old version of the spec required developers only mark urls being action encoded with the DIRECT_LINK tag if an absolute url. Based on user feedback the spec changed to require encodeActionURL to turn any app relative DIRECT_LINKs into an absolute link before returning. Need to update the impl to reflect this change. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2840) Use a copied Iterator instead of the real Enumeration in AbstractAttributeMap.AbstractAttributeIterator
[ https://issues.apache.org/jira/browse/MYFACES-2840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12914277#action_12914277 ] Leonardo Uribe commented on MYFACES-2840: - Finally I added a class called AbstractThreadSafeAttributeMap and this one is implemented only for ApplicationMap and SessionMap. Use a copied Iterator instead of the real Enumeration in AbstractAttributeMap.AbstractAttributeIterator --- Key: MYFACES-2840 URL: https://issues.apache.org/jira/browse/MYFACES-2840 Project: MyFaces Core Issue Type: Task Affects Versions: 1.1.8, 1.2.9, 2.0.1 Reporter: Jakob Korherr Assignee: Jakob Korherr Fix For: 1.1.9-SNAPSHOT, 1.2.10-SNAPSHOT, 2.0.2 We can use a copied version of the Enumeration from getAttributeNames() here, because directly using it might cause a ConcurrentModificationException when performing remove(). Note that we can do this since the Enumeration from getAttributeNames() will contain exactly the attribute names from the time getAttributeNames() was called and it will not be updated if attributes are removed or added. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2928) FacesConfigurator cast for ApplicationImpl directly to load converter configuration, instead use RuntimeConfig object
FacesConfigurator cast for ApplicationImpl directly to load converter
configuration, instead use RuntimeConfig object
-
Key: MYFACES-2928
URL: https://issues.apache.org/jira/browse/MYFACES-2928
Project: MyFaces Core
Issue Type: Bug
Components: JSR-314
Affects Versions: 1.1.9-SNAPSHOT, 1.2.10-SNAPSHOT, 2.0.3-SNAPSHOT
Reporter: Leonardo Uribe
Assignee: Leonardo Uribe
Checking some code on myfaces I notice this lines on FacesConfigurator:
if(application instanceof ApplicationImpl)
{
for (Iterator it =
_dispenser.getConverterConfigurationByClassName(); it.hasNext();)
{
String converterClassName = (String) it.next();
((ApplicationImpl)
application).addConverterConfiguration(converterClassName,
_dispenser.getConverterConfiguration(converterClassName));
}
}
We should avoid that, and instead use RuntimeConfig object, because that is the
right place to do that.
The problem with this hack is what happen when Application object is wrapped.
It is very rare that someone overrides this class, but on JSF 2.0 this problem
become important, because it is valid to wrap Application object.
The solution is just move the related code to RuntimeConfig object and call
from ApplicationImpl doing a lookup to that location.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1923) CLONE -Issue in org.apache.myfaces.trinidad.model.ProccessUtils.getMaxVisitedRowKey
CLONE -Issue in
org.apache.myfaces.trinidad.model.ProccessUtils.getMaxVisitedRowKey
---
Key: TRINIDAD-1923
URL: https://issues.apache.org/jira/browse/TRINIDAD-1923
Project: MyFaces Trinidad
Issue Type: Bug
Affects Versions: 1.2.12-plugins
Environment: Mac OSX 10.5 with JVM 1.6.0_20.
Running using ADF with JDeveloper 11.1.1.3.0
Reporter: Pavitra Subramaniam
Priority: Minor
I have been running the following example:
http://adf-samples.googlecode.com/files/SampleTrainModelWithCustomAction.zip
I just changed the view.train.TrainIdMenuModel class constructor to:
public TrainIdMenuModel() {
super();
super.setMaxPathKey(MyMaxPathKey);
}
This is done to get a max visited node behavior. However when I click on the
button 'Next' to navigate on the tree the nodes are not enabled as expected and
the user has to click on 'Back' and then 'Next' twice to get the nodes enabled
correctly.
The example can be found in this blog entry:
http://jobinesh.blogspot.com/2010/04/custom-model.html which is based on the
ADF rich client demo
(http://www.oracle.com/technology/products/adf/adffaces/11/doc/demo/adf_faces_rc_demo.html).
The rich client demo can also be used to reproduce the issue.
I accept that using a case test that relies in a whole framework like ADF is
not ideal, but looking at the code of
org.apache.myfaces.trinidad.model.ProcessUtils I think that the problem lies
there. In the javadoc it is stated: If set but the focus rowKey is after
maxVisitedRowKey, set maxVisitedRowKey to the focus rowKey.
However if we look at the code, we can see that this is not respected since the
maxPath variable is 'cached' at the request map.
If we assume that a MenuModel is going to be updated during the processing of a
request BUT that the ProccessUtils.getMaxVisitedRowKey is invoked BEFORE the
model is actually updated, the maxPath value will be calculated (and cached)
using the non updated model. In particular the maxPath will be calculated
incorrectly if the focusRowKey of the model is NOT updated before the first
call to ProccessUtils.getMaxVisitedRowKey occurs during the request. After
this, if the focusRowKey is updated in the model and
ProccessUtils.getMaxVisitedRowKey is called (always being in the context of the
same request), the contract will not be respected and the cached maxPath value
will be returned (which can correspond to a node BEFORE the current focus node,
which is wrong).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-2928) FacesConfigurator cast for ApplicationImpl directly to load converter configuration, instead use RuntimeConfig object
[
https://issues.apache.org/jira/browse/MYFACES-2928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leonardo Uribe resolved MYFACES-2928.
-
Fix Version/s: 1.1.9-SNAPSHOT
1.2.10-SNAPSHOT
2.0.3-SNAPSHOT
Resolution: Fixed
FacesConfigurator cast for ApplicationImpl directly to load converter
configuration, instead use RuntimeConfig object
-
Key: MYFACES-2928
URL: https://issues.apache.org/jira/browse/MYFACES-2928
Project: MyFaces Core
Issue Type: Bug
Components: JSR-314
Affects Versions: 1.1.9-SNAPSHOT, 1.2.10-SNAPSHOT, 2.0.3-SNAPSHOT
Reporter: Leonardo Uribe
Assignee: Leonardo Uribe
Fix For: 1.1.9-SNAPSHOT, 1.2.10-SNAPSHOT, 2.0.3-SNAPSHOT
Checking some code on myfaces I notice this lines on FacesConfigurator:
if(application instanceof ApplicationImpl)
{
for (Iterator it =
_dispenser.getConverterConfigurationByClassName(); it.hasNext();)
{
String converterClassName = (String) it.next();
((ApplicationImpl)
application).addConverterConfiguration(converterClassName,
_dispenser.getConverterConfiguration(converterClassName));
}
}
We should avoid that, and instead use RuntimeConfig object, because that is
the right place to do that.
The problem with this hack is what happen when Application object is wrapped.
It is very rare that someone overrides this class, but on JSF 2.0 this
problem become important, because it is valid to wrap Application object.
The solution is just move the related code to RuntimeConfig object and call
from ApplicationImpl doing a lookup to that location.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-1923) CLONE -Issue in org.apache.myfaces.trinidad.model.ProccessUtils.getMaxVisitedRowKey
[
https://issues.apache.org/jira/browse/TRINIDAD-1923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavitra Subramaniam updated TRINIDAD-1923:
--
Status: Patch Available (was: Open)
CLONE -Issue in
org.apache.myfaces.trinidad.model.ProccessUtils.getMaxVisitedRowKey
---
Key: TRINIDAD-1923
URL: https://issues.apache.org/jira/browse/TRINIDAD-1923
Project: MyFaces Trinidad
Issue Type: Bug
Affects Versions: 2.0.0.3-core
Environment: Mac OSX 10.5 with JVM 1.6.0_20.
Running using ADF with JDeveloper 11.1.1.3.0
Reporter: Pavitra Subramaniam
Priority: Minor
(Created this issue for fixing on trinidad trunk)
I have been running the following example:
http://adf-samples.googlecode.com/files/SampleTrainModelWithCustomAction.zip
I just changed the view.train.TrainIdMenuModel class constructor to:
public TrainIdMenuModel() {
super();
super.setMaxPathKey(MyMaxPathKey);
}
This is done to get a max visited node behavior. However when I click on the
button 'Next' to navigate on the tree the nodes are not enabled as expected
and the user has to click on 'Back' and then 'Next' twice to get the nodes
enabled correctly.
The example can be found in this blog entry:
http://jobinesh.blogspot.com/2010/04/custom-model.html which is based on the
ADF rich client demo
(http://www.oracle.com/technology/products/adf/adffaces/11/doc/demo/adf_faces_rc_demo.html).
The rich client demo can also be used to reproduce the issue.
I accept that using a case test that relies in a whole framework like ADF is
not ideal, but looking at the code of
org.apache.myfaces.trinidad.model.ProcessUtils I think that the problem lies
there. In the javadoc it is stated: If set but the focus rowKey is after
maxVisitedRowKey, set maxVisitedRowKey to the focus rowKey.
However if we look at the code, we can see that this is not respected since
the maxPath variable is 'cached' at the request map.
If we assume that a MenuModel is going to be updated during the processing of
a request BUT that the ProccessUtils.getMaxVisitedRowKey is invoked BEFORE
the model is actually updated, the maxPath value will be calculated (and
cached) using the non updated model. In particular the maxPath will be
calculated incorrectly if the focusRowKey of the model is NOT updated before
the first call to ProccessUtils.getMaxVisitedRowKey occurs during the
request. After this, if the focusRowKey is updated in the model and
ProccessUtils.getMaxVisitedRowKey is called (always being in the context of
the same request), the contract will not be respected and the cached maxPath
value will be returned (which can correspond to a node BEFORE the current
focus node, which is wrong).
--
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-1923) CLONE -Issue in org.apache.myfaces.trinidad.model.ProccessUtils.getMaxVisitedRowKey
[
https://issues.apache.org/jira/browse/TRINIDAD-1923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12914297#action_12914297
]
Pavitra Subramaniam edited comment on TRINIDAD-1923 at 9/23/10 8:46 PM:
Uploaded a patch file with the fix for this issue on trunk. The patch was
worked on together by Josu (see base issue 1844) and Pavitra.
was (Author: pasubra):
Uploaded a patch file with the fix for this issue on trunk. The patch was
worked on together by Jose (see base issue 1844) and Pavitra.
CLONE -Issue in
org.apache.myfaces.trinidad.model.ProccessUtils.getMaxVisitedRowKey
---
Key: TRINIDAD-1923
URL: https://issues.apache.org/jira/browse/TRINIDAD-1923
Project: MyFaces Trinidad
Issue Type: Bug
Affects Versions: 2.0.0.3-core
Environment: Mac OSX 10.5 with JVM 1.6.0_20.
Running using ADF with JDeveloper 11.1.1.3.0
Reporter: Pavitra Subramaniam
Priority: Minor
Attachments: ProcessUtils.java
(Created this issue for fixing on trinidad trunk)
I have been running the following example:
http://adf-samples.googlecode.com/files/SampleTrainModelWithCustomAction.zip
I just changed the view.train.TrainIdMenuModel class constructor to:
public TrainIdMenuModel() {
super();
super.setMaxPathKey(MyMaxPathKey);
}
This is done to get a max visited node behavior. However when I click on the
button 'Next' to navigate on the tree the nodes are not enabled as expected
and the user has to click on 'Back' and then 'Next' twice to get the nodes
enabled correctly.
The example can be found in this blog entry:
http://jobinesh.blogspot.com/2010/04/custom-model.html which is based on the
ADF rich client demo
(http://www.oracle.com/technology/products/adf/adffaces/11/doc/demo/adf_faces_rc_demo.html).
The rich client demo can also be used to reproduce the issue.
I accept that using a case test that relies in a whole framework like ADF is
not ideal, but looking at the code of
org.apache.myfaces.trinidad.model.ProcessUtils I think that the problem lies
there. In the javadoc it is stated: If set but the focus rowKey is after
maxVisitedRowKey, set maxVisitedRowKey to the focus rowKey.
However if we look at the code, we can see that this is not respected since
the maxPath variable is 'cached' at the request map.
If we assume that a MenuModel is going to be updated during the processing of
a request BUT that the ProccessUtils.getMaxVisitedRowKey is invoked BEFORE
the model is actually updated, the maxPath value will be calculated (and
cached) using the non updated model. In particular the maxPath will be
calculated incorrectly if the focusRowKey of the model is NOT updated before
the first call to ProccessUtils.getMaxVisitedRowKey occurs during the
request. After this, if the focusRowKey is updated in the model and
ProccessUtils.getMaxVisitedRowKey is called (always being in the context of
the same request), the contract will not be respected and the cached maxPath
value will be returned (which can correspond to a node BEFORE the current
focus node, which is wrong).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1844) Issue in org.apache.myfaces.trinidad.model.ProccessUtils.getMaxVisitedRowKey
[
https://issues.apache.org/jira/browse/TRINIDAD-1844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12914302#action_12914302
]
Pavitra Subramaniam commented on TRINIDAD-1844:
---
Josu, thanks for verifying! Did you want this fix to go into 1.2.12.3? Any
other branches on trinidad?
I have also logged issue https://issues.apache.org/jira/browse/TRINIDAD-1923,
so that the issue can be fixed in trinidad 2.0.0.3-core.
Thanks
Pavitra
Issue in org.apache.myfaces.trinidad.model.ProccessUtils.getMaxVisitedRowKey
Key: TRINIDAD-1844
URL: https://issues.apache.org/jira/browse/TRINIDAD-1844
Project: MyFaces Trinidad
Issue Type: Bug
Affects Versions: 1.2.12-plugins
Environment: Mac OSX 10.5 with JVM 1.6.0_20.
Running using ADF with JDeveloper 11.1.1.3.0
Reporter: Josu Vergara
Priority: Minor
Attachments: ProcessUtils.java, ProcessUtils.java.1
I have been running the following example:
http://adf-samples.googlecode.com/files/SampleTrainModelWithCustomAction.zip
I just changed the view.train.TrainIdMenuModel class constructor to:
public TrainIdMenuModel() {
super();
super.setMaxPathKey(MyMaxPathKey);
}
This is done to get a max visited node behavior. However when I click on the
button 'Next' to navigate on the tree the nodes are not enabled as expected
and the user has to click on 'Back' and then 'Next' twice to get the nodes
enabled correctly.
The example can be found in this blog entry:
http://jobinesh.blogspot.com/2010/04/custom-model.html which is based on the
ADF rich client demo
(http://www.oracle.com/technology/products/adf/adffaces/11/doc/demo/adf_faces_rc_demo.html).
The rich client demo can also be used to reproduce the issue.
I accept that using a case test that relies in a whole framework like ADF is
not ideal, but looking at the code of
org.apache.myfaces.trinidad.model.ProcessUtils I think that the problem lies
there. In the javadoc it is stated: If set but the focus rowKey is after
maxVisitedRowKey, set maxVisitedRowKey to the focus rowKey.
However if we look at the code, we can see that this is not respected since
the maxPath variable is 'cached' at the request map.
If we assume that a MenuModel is going to be updated during the processing of
a request BUT that the ProccessUtils.getMaxVisitedRowKey is invoked BEFORE
the model is actually updated, the maxPath value will be calculated (and
cached) using the non updated model. In particular the maxPath will be
calculated incorrectly if the focusRowKey of the model is NOT updated before
the first call to ProccessUtils.getMaxVisitedRowKey occurs during the
request. After this, if the focusRowKey is updated in the model and
ProccessUtils.getMaxVisitedRowKey is called (always being in the context of
the same request), the contract will not be respected and the cached maxPath
value will be returned (which can correspond to a node BEFORE the current
focus node, which is wrong).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Mansi Gaba is out of the office.
I will be out of the office starting 24/09/2010 and will not return until 27/09/2010. I will respond to your message when I return. Please contact Lakshmi Priya /India/IBM for any RATLC//TVT queries and in urgent cases my manager Saurabh M Agarwal/India/IBM
