[jira] Commented: (TOMAHAWK-1222) forceIdIndexFormula must encode value
[
https://issues.apache.org/jira/browse/TOMAHAWK-1222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12637468#action_12637468
]
Paul Rivera commented on TOMAHAWK-1222:
---
Hi!
I agree with you that value must confirm to the restrictions on component ids
imposed by the specification. I've checked the JSF specification for both 1.1
and 1.2 and under the section 'Client Identifiers' there is no mention of a
specific format for clientId.
But for myfaces, the clientId can contain numbers, letters, -, and _ only.
Mojarra has the same constraint.
I suggest we do the same check that UIComponentBase.isIdValid() does. If the
value from forceIdIndexFormula contains characters other than those mentioned
above, we should throw an exception and not encode it.
Here's a sample of what was rendered from my test case (attached above as
testcase1.rar):
trtdTEXT2 'lt;gt;gt;/gt;quot;/tdtda href=# onclick=return
oamSubmitForm('mainForm','mainForm:itemsTable:TEXT2
'lt;gt;gt;/gt;quot;:deleteLinkX'); id=mainForm:itemsTable:TEXT2
'lt;gt;gt;/gt;quot;:deleteLinkXdelete/a/td/tr
The malformed id causes oamSubmitForm() not to function properly. The link is
then unable to call the method from my backing bean.
I've attached a patch above named AbstractHtmlDataTable.patch and has already
been tested for both tomahawk11 and tomahawk12.
forceIdIndexFormula must encode value
-
Key: TOMAHAWK-1222
URL: https://issues.apache.org/jira/browse/TOMAHAWK-1222
Project: MyFaces Tomahawk
Issue Type: Bug
Components: Extended Datatable
Affects Versions: 1.1.6
Environment: Any
Reporter: Michael Lipp
Attachments: AbstractHtmlDataTable.patch, testcase1.rar
The documentation does not impose any restriction on the value passed to
forceIdIndexFormula. But as Tomahawk makes the value returned part of the
component id, the value must confirm to the restrictions on component ids
imposed by the specification. This should either be specified in the
documentation (bad) or the value should be encoded when used in the component
id (better).
The problem showed up in my case because the rows displayed show data from an
LDAP server and the distinguished name used as unique key contains commas.
This breaks Sun's JSF RI because it creates a JavaScript function invocation
with f(id,value). When the id contains a comma (as in my case) the function
arguments cannot be seperated properly any more.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Thoughts on Trinidad
Hi all, About JSF 2.0 adoption, I know there's a big hype in the JSF community about it. However, unlike1.1 and akin to 1.2, 2.0 is part of JEE and has some dependencies on some other specifications from it. Therefore, it's unlikely that simply dropping the jsf 2.0 jars will be enough to use 2.0, it might requires some additional jars as well. As a result, I think massive adoption of JSF 2.0 won't come before the massive adoption of JEE 6 that cannot happen until JEE 6 AS get released. I believe the latter is why it took so long for JSF 1.2 to be adopted. Then again, JEE 5 included MASSIVE changes so it's very possible that JEE 6 does suffer a delay as long before seeing AS in production version. As for skinning, I agree with Scott. Trinidad's skinning enchine is very decent. However, I also agree that I see many developers bang their head when trying to skin something, sometimes myself even. Some of the main issues I suffer from are things like: element class=tr_component span class=DefaultFontColorText/span /element So when trying to set the color on the component, the more global selector takes preceedence which is annoying and force usage of tr|component .DefaultFontColor complex selector. Another problem I have that was even more important before -tr-inhibit time is the unknown alias inclusion. I raised that issue during incubation but my suggestion was discarded at a time. I could raise again that suggestion with a modification. I think we should provide three skins with Trinidad, not only basic and simple like now. Those skins would be: 1. empty: An empty skin with no selector at all (this skin wouldn't be necessary if no extends in the skin definition was meaning inherit nothing rather than simple) 2. coherence extends empty: A skin defining empty aliases and aliases inclusion, basically servign as a base of a skin using coherent styling across its components 3. simple extends coherence: Define the quite ugly green values in the alias and add some other styling information about layout and icons. So, when creating a new skin, developers could start out from scratch if they prefer and thus not suffer from unexpected side effects. Regards, ~ Simon On Mon, Oct 6, 2008 at 8:24 PM, Scott O'Bryan [EMAIL PROTECTED] wrote: I would tend to agree with this, but the real issue is striking a balance between flexibility and simplicity. I know the Richclient uses the same skinning mechanism as Trinidad (it USES Trinidad Skinning) and the look and feels out of that renderkit are entirely different. With a less flexible system, that kind of capability would not be possible. shrug Maybe better things can be done to strike a balance, but in our projects, the flexibility on the skinning has helped us more then it has hurt us. Scott Werner Punz wrote: Simon Lessard schrieb: Hi, The UIX issue is a very valid one indeed and so few link to it remains, it's a shame that we didn't get rid of it already and I'm to blame a lot for that because I started it a long time ago but was never able to finish it. However, as Matthias pointed out, JSF 2.0 standardize Trinidad's principal core features namely PPR and Resource handling and hopefully skinning too. Under such circumstances, I feel that we should wait for 2.0 to be cemented before going through a massive refactoring of some of the old and twisted code parts so that the refactored design is fully compatible with 1.2, but using 2.0 concept to make the upgrade to 2.0 easier imho. Actually regarding skinning, I have used Trinidad at a customer and I personally consider the way Trinidad handles skinning one of the weak points which should be considered to be thought over. The reason for this simply was the experience seeing one developer hammering his head against the table trying to learn how to skin it. And it becomes worse with more complicated components. I personally think the entire skinning aspect, while technologically being really impressive with a CSS3 down to browser CSS support is a huge problem for many to adapt the component library. At least it should be simplified for certain components! The UIX dependencies are another problem, but I personally consider the complexity of component skinning an even bigger issue, which might even be way harder to address!
[jira] Created: (TOBAGO-710) use of maxNumber in tc:messages throws IllegalArgumentException: argument type mismatch
use of maxNumber in tc:messages throws IllegalArgumentException: argument type mismatch --- Key: TOBAGO-710 URL: https://issues.apache.org/jira/browse/TOBAGO-710 Project: MyFaces Tobago Issue Type: Bug Components: Core Affects Versions: 1.0.19 Reporter: Volker Weber Assignee: Volker Weber -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Another approach to the templating problem
Ok to summarize this thread Generelly the compiler is appreciated, but a) We need a jsp like mechanism for dynamic compilation of the source templates, that should be doable, although it would mean modifications within the source how the templates are called (probably loading them via a utils class from the renderer) b) We need a more precise handling of the JSF APIs, that is much harder than a) but I think it is solvable one way or the other (probably by a second interpretion step which scans for tags and also merges the incoming variable expressions into the mix. Anything else? Besides that one question is open. Do we host it within myfaces or should I put it somewhere else (my preferrence would be java.net outside of myfaces due to its maven support) If we host it within myfaces, I will take care of the codegrant today or tomorrow and will start to work on the additional features after the code drop. If not, I will drop it somewhere else and will keep the mailinglist notified. Either option is fine by me! Werner
[jira] Created: (TOBAGO-711) Onsubmit Attribute is missing in facelets ScriptHandler
Onsubmit Attribute is missing in facelets ScriptHandler Key: TOBAGO-711 URL: https://issues.apache.org/jira/browse/TOBAGO-711 Project: MyFaces Tobago Issue Type: Bug Components: Facelets Affects Versions: 1.0.19 Reporter: Bernd Bohmann Assignee: Bernd Bohmann Priority: Minor Fix For: 1.0.20 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1252) Tag Attributes duplicated in trace level logging.
Tag Attributes duplicated in trace level logging. - Key: TRINIDAD-1252 URL: https://issues.apache.org/jira/browse/TRINIDAD-1252 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 1.2.9-core Reporter: Paul Spencer Priority: Minor Some attributes, like renderType and title, are duplicated in trace level logging. The log output below is based on the following jspx. You will notice duplicate attributes in both tr:document and tr:outputText. ?xml version=1.0 encoding=iso-8859-1 standalone=yes ? jsp:root xmlns:jsp=http://java.sun.com/JSP/Page; version=2.0 xmlns:f=http://java.sun.com/jsf/core; xmlns:tr=http://myfaces.apache.org/trinidad; jsp:directive.page contentType=text/html;charset=utf-8 / f:view tr:document title=My Title! tr:outputText value=Hello World! / /tr:document /f:view /jsp:root TRACE - View after rendering UIViewRoot id=j_id_jsp_880081898_0 org.apache.myfaces.FORMER_CHILD_IDS=[j_id_jsp_880081898_1] org.apache.myfaces.BOUND_VIEW_ROOT=true afterPhaseListener=NULL beforePhaseListener=NULL facetCount=0 family=javax.faces.ViewRoot locale=en renderKitId=org.apache.myfaces.trinidad.core rendered=true rendererType=NULL rendersChildren=false transient=false viewId=/documentTest.jspx org.apache.myfaces.trinidad.component.core.CoreDocument id=j_id_jsp_880081898_1 title=My Title! org.apache.myfaces.FORMER_CHILD_IDS=[j_id_jsp_880081898_2] rendererType=org.apache.myfaces.trinidad.Document attributeChangeListener=NULL attributeChangeListeners=NULL facesBean=NULL facetCount=NULL facetNames=NULL family=NULL initialFocusId=NULL inlineStyle=NULL metaContainer=NULL mode=default onclick=NULL ondblclick=NULL onkeydown=NULL onkeypress=NULL onkeyup=NULL onload=NULL onmousedown=NULL onmousemove=NULL onmouseout=NULL onmouseover=NULL onmouseup=NULL onunload=NULL partialTriggers=NULL rendered=true rendererType=org.apache.myfaces.trinidad.Document rendersChildren=NULL shortDesc=NULL styleClass=NULL title=My Title! transient=NULL org.apache.myfaces.trinidad.component.core.output.CoreOutputText id=j_id_jsp_880081898_2 value=Hello World! rendererType=org.apache.myfaces.trinidad.Text attributeChangeListener=NULL attributeChangeListeners=NULL converter=NULL description=NULL escape=true facesBean=NULL facetCount=NULL facetNames=NULL family=NULL inlineStyle=NULL localValue=NULL onclick=NULL ondblclick=NULL onkeydown=NULL onkeypress=NULL onkeyup=NULL onmousedown=NULL onmousemove=NULL onmouseout=NULL onmouseover=NULL onmouseup=NULL partialTriggers=NULL rendered=true rendererType=org.apache.myfaces.trinidad.Text rendersChildren=NULL shortDesc=NULL styleClass=NULL transient=NULL truncateAt=0 / /org.apache.myfaces.trinidad.component.core.CoreDocument /UIViewRoot -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TOBAGO-709) JavaScript error when opening a popup
JavaScript error when opening a popup
-
Key: TOBAGO-709
URL: https://issues.apache.org/jira/browse/TOBAGO-709
Project: MyFaces Tobago
Issue Type: Bug
Components: Themes
Affects Versions: 1.0.19
Reporter: Rainer Rohloff
When opening a popup there is a JavaScript error message.
Zeile 966
Fehler: Ungültiges Argument .
possible fix in tobago.js line 966
old: setTimeout(Tobago.lockPopupPage( id ), 100);
new: setTimeout(Tobago.lockPopupPage(' + id + '), 100);
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Bug in ApplicationImpl
On Mon, 2008-06-10 at 16:27 -0500, Leonardo Uribe wrote: On my local repo there are versions from 1.0.4 to 1.5.6. Maybe it is related to your maven version. Try upgrade your maven version. I'm using 2.0.8. I was using maven 2.0.7. I upgraded to 2.0.9. The versions of plexus-utils are still the same as they were, but something else must have changed b/c now everything works. Thanks a lot, Leonardo. Val
Trinidad - custom PPR tag problem - not evaluating an #{...} expression
Hi,
Hope you can help the headache this is giving me.
Basically I am trying to write a custom PPR tag with Trinidad (1.2.9). My tag
though displays #{topteaser.currentText} while an outputTag tag using PPR in an
identical way is working just fine. I guess I am missing some configuration
option as I have tracked through the code and got to a line which goes
getValue(bean) which for my tag returns #{topteaser.currentText} and for the
outputText returns start, hello, goodbye as I want. As I see it (and I
may be wrong) it is not the actual PPR (configuration) that is wrong but the
fact that my tag has not correctly intepreted #{topteaser.currentText} as being
an expression rather than just a chunk of text.
I have reduced by Tag to something quite simple - which simply extends
CoreOutputText (and CoreOutputTextTag). I have specified virtually nothing in
the code as you can see below.
package org.cage.myfaces.tags.teaser;
import org.apache.myfaces.trinidad.component.core.output.CoreOutputText;
public class UITeaser extends CoreOutputText {
public UITeaser() {
super();
}
/**
* Construct an instance of the CoreOutputText.
*/
protected UITeaser(String rendererType) {
super(rendererType);
}
}
and
package org.cage.myfaces.tags.teaser;
import org.apache.myfaces.trinidadinternal.taglib.core.output.CoreOutputTextTag;
public class TeaserTag extends CoreOutputTextTag {
public TeaserTag()
{
}
}
In the WEB_INF/teaser.tld, I have
?xml version=1.0 encoding=UTF-8?
taglib xmlns=http://java.sun.com/xml/ns/javaee;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://java.sun.com/xml/ns/javaee/web-jsptaglibrary_2_1.xsd;
version=2.1
tlib-version1.0/tlib-version
jsp-version1.2/jsp-version
short-nameteaser/short-name
urihttp://www.promt.me.uk/development/JSF
/uri
description.../description
tag
descriptionThe outputText component supports styled text.
/description
nameteaser/name
tag-class..
The rest of the tag...tag is copied straight from the outputText
tag.../tag definition from Trinidad
In the JSP I have
...
%@ taglib uri=http://www.promt.me.uk/development/JSF; prefix=cage %
...
tr:poll id=myPoller interval=1000
pollListener=#{topteaser.doSomething}/tr:poll
cage:teaser value=#{topteaser.currentText} partialTriggers=myPoller/
tr:outputText value=#{topteaser.currentText} partialTriggers=myPoller/
topteaser is defined as.
managed-bean
managed-bean-nametopteaser/managed-bean-name
managed-bean-classorg.cage.myfaces.teasers.beans.TopTeaser
/managed-bean-class
managed-bean-scoperequest/managed-bean-scope
/managed-bean
and contains the code
package org.cage.myfaces.teasers.beans;
import org.apache.myfaces.trinidad.event.PollEvent;
public class TopTeaser {
private String[] text = new String[] {hello, goodbye};
public String currentText = start;
/**
* default empty constructor
*/
public TopTeaser(){
}
public String getCurrentText() {
return currentText;
}
public void setCurrentText(String currentText) {
this.currentText = currentText;
}
public void doSomething(PollEvent event)
{
currentText =
text[Integer.parseInt(Long.toString(System.currentTimeMillis()%2))];
}
}
How simple can you get?
Any pointers would be gratefully received.
Thanks Regards
Christopher Biggs
Re: [jira] Commented: (TRINIDAD-1226) CoreShowDetails doesn't function when created programatically
Shane Petroff wrote: Andrew Robinson (JIRA) wrote: You are clearing the children component on every single get call. Every _set_, but regardless, I have to take a look to make sure I haven't gotten my example out of synch with the real code. Did the explanation below make sense to anyone? Given the choice of generating a single page via java code which is then re-built for each submission, vs 1K+ very similar pages vs 100+ large pages making judicious use of the rendered property, I chose the first option. The 2 use cases also driving this decision were the need to navigate essentially randomly through the various details and the need to alter page contents without developer or designer intervention. That said, I do need to rebuild the entire page after submission (hence the getChildren().clear()). This is a 'detail' page whose content is not know at design time. There are thousands of possible combinations of components which make up this page, and those combinations change from time to time, so it is not reasonable to develop a normal page per combination. As a user iterates through objects (examining their details) the same page is reconstructed based on metadata describing the particular instance they happen to be looking at. User instances which are adjacent in the list which is being traversed, can have radically different profiles, so I just reconstruct the page. I would suggest that you try to alter your code to make sure the component is only created once (use an attribute on the parent component). I want to recreate components once per submission in this case. I realize that this isn't a 'normal' approach, but I'm not sure how else I could have structured things. The only thing that seems to be 'required' (found through experimentation, not spec) is that component id's need to be allocated in a deterministic way. The show detail seems not to like id's 'duplicated' in distinct naming containers, but it too behaves when names are deterministic and consistent. Am I going to be in trouble in the future with this approach? -- Shane
[jira] Created: (MYFACES-2007) Converters are not created properly when target class is both, an enum and implements an interface
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
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 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] Updated: (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:all-tabpanel
]
Val Blant updated MYFACES-2007:
---
Status: Patch Available (was: Open)
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
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 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.
Re: Bug in ApplicationImpl
On Mon, 2008-29-09 at 09:37 +0200, Simon Kitching wrote: I suggest you create a JIRA issue for this. If you can provide a patch (and even better a simple unit test) that would be even better.. Jira issue MYFACES-2007 includes a patch with the fix and a unit test. Val
Re: Make dev@ private?
Andrew Robinson schrieb: Is it possible to make dev@ a private mailing list, so only commiters and people that PMCs decide should have access to post are allowed to send emails to this list? That way we can reduce the accidental posting to dev@ instead of [EMAIL PROTECTED] -Andrew No... I am not even sure that any devs list on apache ever went private I am absolutely against it -1!
Re: Make dev@ private?
mea culpa.. Scott O'Bryan schrieb: Old thread. I think he's been sufficiently pummeled. :) Werner Punz wrote: Andrew Robinson schrieb: Is it possible to make dev@ a private mailing list, so only commiters and people that PMCs decide should have access to post are allowed to send emails to this list? That way we can reduce the accidental posting to dev@ instead of [EMAIL PROTECTED] -Andrew No... I am not even sure that any devs list on apache ever went private I am absolutely against it -1!
[jira] Resolved: (TOBAGO-710) use of maxNumber in tc:messages throws IllegalArgumentException: argument type mismatch
[ https://issues.apache.org/jira/browse/TOBAGO-710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Volker Weber resolved TOBAGO-710. - Resolution: Fixed Fix Version/s: 1.0.20 use of maxNumber in tc:messages throws IllegalArgumentException: argument type mismatch --- Key: TOBAGO-710 URL: https://issues.apache.org/jira/browse/TOBAGO-710 Project: MyFaces Tobago Issue Type: Bug Components: Core Affects Versions: 1.0.19 Reporter: Volker Weber Assignee: Volker Weber Fix For: 1.0.20 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Deleted: (MYFACES-1909) Implement JSF 2.0 Early Draf 2008-04-21
[ https://issues.apache.org/jira/browse/MYFACES-1909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Lessard deleted MYFACES-1909: --- Implement JSF 2.0 Early Draf 2008-04-21 --- Key: MYFACES-1909 URL: https://issues.apache.org/jira/browse/MYFACES-1909 Project: MyFaces Core Issue Type: Task Reporter: Simon Lessard Assignee: Simon Lessard Priority: Minor Original Estimate: 4800h Remaining Estimate: 4800h A JSF 2.0 branch was created at https://svn.apache.org/repos/asf/myfaces/core/branches/2_0_0. While there's no official release of the spec, I won't create a brand new category for this issue. My team and anyone else willing to help can attach the patches here. If it gets too tricky we might change the work flow and I'll have a JIRA component created specifically for JSR-314 where we can create as much ticket as needed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TOBAGO-529) TabChangeListener tag should allow methodBinding
[ https://issues.apache.org/jira/browse/TOBAGO-529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Volker Weber resolved TOBAGO-529. - Resolution: Fixed Fix Version/s: 1.0.20 TabChangeListener tag should allow methodBinding Key: TOBAGO-529 URL: https://issues.apache.org/jira/browse/TOBAGO-529 Project: MyFaces Tobago Issue Type: Improvement Components: Core Reporter: Volker Weber Assignee: Volker Weber Priority: Minor Fix For: 1.0.20 tc:tabChangeListener currently requires the type attribute which is a class implementing TabChangeListener. As an alternate a attribute 'listener' should be possible with a methodBinding pointing to a processTabChange(TabChangeEvent stateChangeEvent) method. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Async Lifecycle for JSF without patching JSF
Hello, I just started an Async Lifecycle module based on the suggestion from Greg Wilkins http://wiki.glassfish.java.net/Wiki.jsp?page=AlternateAsyncProposalRebuttal The module has been tested with MyFaces 1.2.4 and Sun RI 1.2_08 and the async-jsf-example-webapp from the jetty 7.0.0pre3 version. http://svn.codehaus.org/jetty/jetty/tags/jetty-7.0.0pre3/modules/examples/async-jsf-example-webapp/ Please look at the code http://svn.apache.org/repos/asf/myfaces/commons/trunk/myfaces-async-lifecycle/src/main/java/org/apache/myfaces/commons/async/ The common Lifecycle and FacesContext code has been added to the myfaces-commons-utils artifact. Note the async Servlet API is not final. Regards Bernd Greg Wilkins schrieb: Bernd Bohmann wrote: Hello Greg, I just reviewed your patch for the Mojarra JSF implementation. I think it should be possible to provide an extra artifact for JSF which implements the async support for JSF without patching the implementation. The extra artifact contains a FacesContextFactory and a different Lifecyle for the async case. If you are interested I would try to provide the code as a new module in MyFaces Commons. Bernd, that would be excellent! and well timed as well as the servlet-EG is in final deliberations about the async API proposals. cheers
Re: Async Lifecycle for JSF without patching JSF
side bash... I am not 100% how well the Servlet and JSF EGs are connected, but... wouldn't it be worth to put things like .isSuspended() on the ExternalContext = etx.isReqSuspended() ? (also, is there some async stuff on portlet?, I am only aware of of servlet, but I am generally a portlet ignorant) But, Bernd this looks cool -M On Tue, Oct 7, 2008 at 11:19 PM, Bernd Bohmann [EMAIL PROTECTED] wrote: Hello, I just started an Async Lifecycle module based on the suggestion from Greg Wilkins http://wiki.glassfish.java.net/Wiki.jsp?page=AlternateAsyncProposalRebuttal The module has been tested with MyFaces 1.2.4 and Sun RI 1.2_08 and the async-jsf-example-webapp from the jetty 7.0.0pre3 version. http://svn.codehaus.org/jetty/jetty/tags/jetty-7.0.0pre3/modules/examples/async-jsf-example-webapp/ Please look at the code http://svn.apache.org/repos/asf/myfaces/commons/trunk/myfaces-async-lifecycle/src/main/java/org/apache/myfaces/commons/async/ The common Lifecycle and FacesContext code has been added to the myfaces-commons-utils artifact. Note the async Servlet API is not final. Regards Bernd Greg Wilkins schrieb: Bernd Bohmann wrote: Hello Greg, I just reviewed your patch for the Mojarra JSF implementation. I think it should be possible to provide an extra artifact for JSF which implements the async support for JSF without patching the implementation. The extra artifact contains a FacesContextFactory and a different Lifecyle for the async case. If you are interested I would try to provide the code as a new module in MyFaces Commons. Bernd, that would be excellent! and well timed as well as the servlet-EG is in final deliberations about the async API proposals. cheers -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
[jira] Created: (TRINIDAD-1253) Problems with ValueBindingValueExpression and ValueExpressionValueBinding
Problems with ValueBindingValueExpression and ValueExpressionValueBinding - Key: TRINIDAD-1253 URL: https://issues.apache.org/jira/browse/TRINIDAD-1253 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 1.2.9-core, 1.2.10-core Environment: All Reporter: Blake Sullivan The implementations of ValueBindingValueExpression and ValueExpressionValueBinding have several problems: ValueBindingValueExpression doesn't correctly implement StateHolder and Serializable. The returned class should implement the interfaces only if the class that it delegates to implements them (it currently always implements Serializable and never implements StateHolder). Determining which implementation class to create should be hidden behind a factory method. ValueBindingValueExpression should implement toString() to aid in debugging ValueExpressionValueBinding's problems are more extensive. It does not implement equals() it does not implement hashCode() It does not implement toString() Similarly to ValueBindingValueExpression it doesn't return implementations that implement StateHolder and/or Serializable if the ValueExpression that it is delegating to does. Determining which implementation class to create should be hidden behind a factory method. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Async Lifecycle for JSF without patching JSF
On Wed, Oct 8, 2008 at 3:06 AM, Greg Wilkins [EMAIL PROTECTED] wrote: Bernd, excellent work! this is valuable feedback as there is a push by some to throw out the asynchronous proposal on the basis that it is too complex and will break frameworks. I have a question. Since in async req. processing (arp) not every req is *mapped* to one thread, how do ThreadLocals work ? For instance, there is one FacesContext per request and it is stored via ThreadLocal. I hope that the ARP actually stays in Servlet 3.0; this is valuable evidence that framework developers are able to deal with the complexities of suspend and resume. I'll keep you informed as to how the servlet async-API develops. Jetty 7 is pretty up-to-date, when there new changes, right ? If anybody on this list is on the JSF EG or Portlet EG, then I'd be happy to liase with them about the progress of the servlet proposals. thanks Matthias Wessendorf wrote: side bash... I am not 100% how well the Servlet and JSF EGs are connected, but... wouldn't it be worth to put things like .isSuspended() on the ExternalContext = etx.isReqSuspended() ? (also, is there some async stuff on portlet?, I am only aware of of servlet, but I am generally a portlet ignorant) But, Bernd this looks cool -M On Tue, Oct 7, 2008 at 11:19 PM, Bernd Bohmann [EMAIL PROTECTED] wrote: Hello, I just started an Async Lifecycle module based on the suggestion from Greg Wilkins http://wiki.glassfish.java.net/Wiki.jsp?page=AlternateAsyncProposalRebuttal The module has been tested with MyFaces 1.2.4 and Sun RI 1.2_08 and the async-jsf-example-webapp from the jetty 7.0.0pre3 version. http://svn.codehaus.org/jetty/jetty/tags/jetty-7.0.0pre3/modules/examples/async-jsf-example-webapp/ Please look at the code http://svn.apache.org/repos/asf/myfaces/commons/trunk/myfaces-async-lifecycle/src/main/java/org/apache/myfaces/commons/async/ The common Lifecycle and FacesContext code has been added to the myfaces-commons-utils artifact. Note the async Servlet API is not final. Regards Bernd Greg Wilkins schrieb: Bernd Bohmann wrote: Hello Greg, I just reviewed your patch for the Mojarra JSF implementation. I think it should be possible to provide an extra artifact for JSF which implements the async support for JSF without patching the implementation. The extra artifact contains a FacesContextFactory and a different Lifecyle for the async case. If you are interested I would try to provide the code as a new module in MyFaces Commons. Bernd, that would be excellent! and well timed as well as the servlet-EG is in final deliberations about the async API proposals. cheers -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
