[jira] Created: (MYFACES-2235) ProjectStage extension
ProjectStage extension -- Key: MYFACES-2235 URL: https://issues.apache.org/jira/browse/MYFACES-2235 Project: MyFaces Core Issue Type: Improvement Components: JSR-314 Affects Versions: 2.0.0-alpha Reporter: Matthias Weßendorf Assignee: Matthias Weßendorf currently jsf's standard ProjectStage is a bit poor, it does not provide support for system props... In order to make that happen we (myfaces) could provide an extension for that... Wo that we could support something like: projectStage = System.getProperty(org.apache.myfaces.PROJECT_STAGE) Ordering would be: -jndi -web.xml -sys-props the current order is JNDI, followed by web.xml -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [myfaces 2.0] ProjectStage extension ?
On Fri, May 15, 2009 at 1:19 AM, Simon Lessard simon.lessar...@gmail.com wrote: Well I guess you're right, there's no way that the property will be set during the tests. created ticket https://issues.apache.org/jira/browse/MYFACES-2235 will commit change soon -M On Thu, May 14, 2009 at 5:52 PM, Matthias Wessendorf mwessend...@gmail.com wrote: I guess the tck has no org.apache.** cfg param as sys prop Sent from my iPod. Am 14.05.2009 um 22:45 schrieb Simon Lessard simon.lessar...@gmail.com: Sounds pretty decent to me, we'll just have to make sure we still pass the TCK after though since the spec also define the default. ~ Simon On Thu, May 14, 2009 at 2:27 PM, Matthias Wessendorf mwessend...@gmail.com wrote: Of course ordering after the standard... Sent from my iPod. Am 14.05.2009 um 20:18 schrieb Gerhard Petracek gerhard.petra...@gmail.com: +1 regards, gerhard 2009/5/14 Matthias Wessendorf mat...@apache.org Hey, currently ProjectStage is a bit poor, it does not provide support for system props... In order to make that happen we (myfaces) could provide an extension for that... so that we would support something like: projectStage = System.getProperty(org.apache.myfaces.PROJECT_STAGE) what do you think ? (as far as I know this is present in JSF 2.1 as well) -Matthias -- 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-2218) We have the error : context must not be null in VariableResolverImpl, in MyFaces during the execution of the system.
[
https://issues.apache.org/jira/browse/MYFACES-2218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12709754#action_12709754
]
Leonardo Uribe commented on MYFACES-2218:
-
org.apache.myfaces.el.unified.FacesELContext has this code it its constructor:
public FacesELContext(ELResolver elResolver,
FacesContext facesContext) {
this._elResolver = elResolver;
putContext(FacesContext.class, facesContext);
Theorically the java compiler adds automatically a call to super(), so
putContext method should work without problem. Maybe some wrapper of
FacesContext uses its custom ELContext, so the error could be related to that
instance. At first view, I think the problem is not related to myfaces.
We have the error : context must not be null in VariableResolverImpl, in
MyFaces during the execution of the system.
Key: MYFACES-2218
URL: https://issues.apache.org/jira/browse/MYFACES-2218
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 1.2.3
Environment: We are using Weblogic Server 10.0MP1, RedHat Enterprise
Server 4, and JVM is JRockit 5.0.11
Reporter: Eduardo Felter Simone
Priority: Critical
Original Estimate: 24h
Remaining Estimate: 24h
We receive the following error:
24 Abr 2009 11:11:43,895 ERROR StackTrace:
java.lang.NullPointerException: context must not be null
at
org.apache.myfaces.el.VariableResolverImpl.resolveVariable(VariableResolverImpl.java:47)
at
org.apache.myfaces.el.convert.VariableResolverToELResolver.getValue(VariableResolverToELResolver.java:93)
at javax.el.CompositeELResolver.getValue(CompositeELResolver.java:143)
at
org.apache.myfaces.el.unified.resolver.FacesCompositeELResolver.access$301(FacesCompositeELResolver.java:46)
at
org.apache.myfaces.el.unified.resolver.FacesCompositeELResolver$4.invoke(FacesCompositeELResolver.java:108)
at
org.apache.myfaces.el.unified.resolver.FacesCompositeELResolver.invoke(FacesCompositeELResolver.java:148)
at
org.apache.myfaces.el.unified.resolver.FacesCompositeELResolver.getValue(FacesCompositeELResolver.java:104)
at com.sun.el.parser.AstIdentifier.getValue(AstIdentifier.java:68)
at com.sun.el.parser.AstNot.getValue(AstNot.java:46)
at com.sun.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:192)
at
javax.faces.component._ComponentUtils.getExpressionValue(_ComponentUtils.java:233)
at
javax.faces.component.UIComponentBase.getExpressionValue(UIComponentBase.java:1155)
at javax.faces.component.UIComponentBase.isRendered(UIComponentBase.java:1225)
at
javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:685)
at
javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:688)
at org.ajax4jsf.component.AjaxViewRoot.processPhase(AjaxViewRoot.java:238)
at org.ajax4jsf.component.AjaxViewRoot.processDecodes(AjaxViewRoot.java:409)
at
org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:103)
at org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:76)
at
pt.ptinovacao.components.aeolus.web.servlet.AeolusFacesServlet.service(AeolusFacesServlet.java:148)
at
br.com.vivo.vivo360.ui.servlet.Vivo360FacesServlet.service(Vivo360FacesServlet.java:82)
at
weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:226)
at
weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:124)
at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:283)
at weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:26)
at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:42)
at
br.com.vivo.vivo360.ui.servlet.SessionExpiredFilter.doFilter(SessionExpiredFilter.java:51)
at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:42)
at br.com.vivo.vivo360.ui.servlet.ErrorFilter.doFilter(ErrorFilter.java:63)
at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:42)
at
org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(ExtensionsFilter.java:147)
at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:42)
at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:178)
at org.ajax4jsf.webapp.BaseFilter.handleRequest(BaseFilter.java:290)
at
org.ajax4jsf.webapp.BaseFilter.processUploadsAndHandleRequest(BaseFilter.java:390)
at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:517)
at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:42)
at
weblogic.servlet.internal.RequestEventsFilter.doFilter(RequestEventsFilter.java:26)
at
[jira] Updated: (MYFACES-2165) concurrent issue in initializing myfaces 1.1.6
[ https://issues.apache.org/jira/browse/MYFACES-2165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe updated MYFACES-2165: Status: Patch Available (was: Open) concurrent issue in initializing myfaces 1.1.6 -- Key: MYFACES-2165 URL: https://issues.apache.org/jira/browse/MYFACES-2165 Project: MyFaces Core Issue Type: Bug Affects Versions: 1.1.6 Environment: tomcat 6.0.18 java 1.6.0_06 Reporter: xuxiankun Priority: Critical Attachments: MYFACES-2165.patch after starting tomcat, we will get a error when i visit a faces page. we can fix this issue by restarting tomcat. so i think it's concurrent issue. java.lang.NullPointerException at org.apache.myfaces.application.jsp.JspViewHandlerImpl.getServletMapping(JspViewHandlerImpl.java:388) at org.apache.myfaces.application.jsp.JspViewHandlerImpl.renderView(JspViewHandlerImpl.java:222) at org.ajax4jsf.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:108) at org.ajax4jsf.application.AjaxViewHandler.renderView(AjaxViewHandler.java:216) at org.apache.shale.validator.faces.ValidatorViewHandler.renderView(ValidatorViewHandler.java:130) at org.ajax4jsf.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:108) at org.ajax4jsf.application.AjaxViewHandler.renderView(AjaxViewHandler.java:216) at org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:41) at org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:146) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:147) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at cn.com.brilliance.begen.webapp.servlet.BeGenFilter.doFilter(BeGenFilter.java:56) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:141) at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:281) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:630) at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:436) at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:374) at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:302) at cn.com.brilliance.begen.webapp.servlet.LoginServlet.doPost(LoginServlet.java:91) at javax.servlet.http.HttpServlet.service(HttpServlet.java:637) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.springframework.orm.hibernate3.support.OpenSessionInViewFilter.doFilterInternal(OpenSessionInViewFilter.java:198) at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:76) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.springframework.web.filter.CharacterEncodingFilter.doFilterInternal(CharacterEncodingFilter.java:96) at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:76) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at
Re: [myfaces 2.0] ProjectStage extension ?
+1 On Fri, May 15, 2009 at 8:21 AM, Matthias Wessendorf mat...@apache.orgwrote: On Fri, May 15, 2009 at 1:19 AM, Simon Lessard simon.lessar...@gmail.com wrote: Well I guess you're right, there's no way that the property will be set during the tests. created ticket https://issues.apache.org/jira/browse/MYFACES-2235 will commit change soon -M On Thu, May 14, 2009 at 5:52 PM, Matthias Wessendorf mwessend...@gmail.com wrote: I guess the tck has no org.apache.** cfg param as sys prop Sent from my iPod. Am 14.05.2009 um 22:45 schrieb Simon Lessard simon.lessar...@gmail.com : Sounds pretty decent to me, we'll just have to make sure we still pass the TCK after though since the spec also define the default. ~ Simon On Thu, May 14, 2009 at 2:27 PM, Matthias Wessendorf mwessend...@gmail.com wrote: Of course ordering after the standard... Sent from my iPod. Am 14.05.2009 um 20:18 schrieb Gerhard Petracek gerhard.petra...@gmail.com: +1 regards, gerhard 2009/5/14 Matthias Wessendorf mat...@apache.org Hey, currently ProjectStage is a bit poor, it does not provide support for system props... In order to make that happen we (myfaces) could provide an extension for that... so that we would support something like: projectStage = System.getProperty(org.apache.myfaces.PROJECT_STAGE) what do you think ? (as far as I know this is present in JSF 2.1 as well) -Matthias -- 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
Re: [source control] git and the ASF ...
Matthias Wessendorf schrieb: Werner, according to here: http://www.apache.org/dev/git.html we need to provide the following information, for the INFRA jira ticket: * Name of the codebase, for example Apache Tika * Name of the requested Git mirror, for example tika.git * Subversion path of the codebase, for example /lucene/tika/ * Subversion layout, in case it is different from the standard trunk, branches, tags structure. I think we may start with MyFaces core? Or do you think we should add *all* the subprojects? +1 to core I think core is find for now and later we can add tomahawk and orchestra etc... have in mind that git basically mirrors all revisions and you cannot checkout subprojects like in svn, so having a split is preferrable. Werner
Re: [source control] git and the ASF ...
Matthias Wessendorf schrieb: core 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) +1 1.1.x branch 1.2 trunk 2.0 branch instead of 1.1 trunk 1.2 trunk_1.2 2.0 branch this also helps the infrastructure people!
[MyFaces CORE] SVN layout (was: Re: [source control] git and the ASF ...)
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 -Matthias -Matthias I think core is find for now and later we can add tomahawk and orchestra etc... have in mind that git basically mirrors all revisions and you cannot checkout subprojects like in svn, so having a split is preferrable. Werner -- 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
Re: [source control] git and the ASF ...
On Fri, May 15, 2009 at 11:37 AM, Werner Punz werner.p...@gmail.com wrote: Matthias Wessendorf schrieb: core 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) +1 1.1.x branch 1.2 trunk 2.0 branch hehe :-) just wrote a similar email :-) -Matthias instead of 1.1 trunk 1.2 trunk_1.2 2.0 branch this also helps the infrastructure people! -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [MyFaces CORE] SVN layout (was: Re: [source control] git and the ASF ...)
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
Re: MyFaces 2.0 PartialResponseWriter + EVALs
Ok I added a dynamically loading loadScript function to our javascript _Utils class/function. The code basically resolves the script src handling aspect by loading the script via synchronous xhr and doing a global eval on the script! This way we dont have dom manipulations just to do the script src part on the client side, and to my knowledge the speed drop is neglectable! (Most javascript libraries do dynamic loading that way) The next step is to find out if the RI has added the start and endTag functionality the way Trinidad and others do! An if yes we have to implement it (I have started on this already) if no, I am going to file a bugreport! Werner Werner Punz schrieb: Hia Ganesh, I have to check the latest codebase, the version i have which is a few weeks old, did not have anything integrated... The main problem I see not doing it is, that usually the response writer already is in update stage when the components encode method is called which means every out goes into update so component authors cannot even trigger the eval part properly! If you want to utilize the eval part properly you have to integrate this automatically one way or the other. I will check the latest codebase this week and if they do not have it integrated I will file a bug report for Mojarra, they might probably have overlooked this aspect on the implementors side (definitely not on the spec side hence the eval cycle). I probably would not know it either on the first look, if I hadn´t worked on those aspects of Trinidad within the boundaries of a project where we tried to integrate PPR! Werner Ganesh schrieb: Hi Werner, Actually, I'm not quite sure which of the cases [1] to [4] (see below) you are referring to. Did you check the behaviour of Mojarra on this? In which case does it return eval? I'd say our PartialResponseWriter should work along the same basic line. My personal guess is they return eval either in case [1] or [3]. I'll try and find some time to set up a test on this during the next week. Best Regards, Ganesh Werner Punz schrieb: I have to evaluate that because generally the insertBefore did not trigger on all non IE browsers in the embedded case (Safari for instance failed as well, while Opera was working) so I had to embed our browser check code... Anyway the safe bet probably is to load the script synchronously via xhr and eval it manually in that case! The unsafe bet is to have the browser doing this automatically. Either way is fine with me since both methods are just a few lines of code. My personal question was more along the lines if there are any obstacles to add the eval behavior as described to the PartialResponseWriter, and how does facelets trigger the response writer in this regard. (Facelets theorectically allows to use scripts just as plain html thus we cannot use the startElement(script approach in this case unless facelets can map single tags into startElement calls) Werner Hi, There are four kinds of script constructs I can image may becoming pulled in through an ajax request: [1] component does startElement(script, component) ... endElement(script) [2] XHTML markup contains script type=text/javascript .../script (or component writes this directly to the stream) [3] markup contains h:outputSrcipt [4] markup contains script src=... IMHO only [1] qualifies to be included in the eval section of the AJAX response by the PartialResponseWriter. Execution on the Javascript side can happen with window.execScript(theActualScriptContent) like Matthias proposed. Matthias, can you explain the advantages of this? [2] should be recognized by our embedded Javascript runScripts function which in fact also does window.execScript. Werner, I think we agree on this. Everything else would cause parsing of the XHTML markup. For [3] Werners document.createElement(script) approach can be suitable though I'm not sure how you want to send this down to the browser. Are you planning to run on the extension tag in the ajax XMLSchema? Werner, your example for document.createElement(script) was based on case [4]. But how do you want to do this? Are you planning to parse all the markup for script tags with src attributes? Maybe here an extension to our embedded Javascript runScripts function could make sense? This could also solve [3]! Best regards, Ganesh
Mojarra and us...
Hello everyone I wanted to start a legal discussion here regarding the status of Mojarra and our codebase. As far as I understood it is following. The mojarra license prevents us from using their code, while they can use ours, this is fine with me the Apache license is more liberal. The Mojarra and Apache license however do not prevent that we can have an occasional look into the mojarra codebase to check things out which are not 100% clearly defined, so that we are in sync there, or to prevent external patches being applied which might have mojarra code inside (we had that once in the past with comments copy pasted from the spec or mojarra) Am I right or wrong? I am just asking to clear this up once and for all. Werner
Re: Mojarra and us...
On Fri, May 15, 2009 at 2:18 PM, Werner Punz werner.p...@gmail.com wrote: Hello everyone I wanted to start a legal discussion here regarding the status of Mojarra and our codebase. As far as I understood it is following. The mojarra license prevents us from using their code, while they can use ours, this is fine with me the Apache license is more liberal. +1 (OT *and* a side-info: OpenJDK is using Apache Harmony code :-) ) The Mojarra and Apache license however do not prevent that we can have an occasional look into the mojarra codebase to check things out which are not 100% clearly defined, so that we are in sync there, or to prevent external patches being applied which might have mojarra code inside (we had that once in the past with comments copy pasted from the spec or mojarra) Am I right or wrong? not sure on the legal side, but I find it *is* critical to take a look at such a code base. -Matthias I am just asking to clear this up once and for all. Werner -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: Mojarra and us...
I have to explain, I noticed that we probably need a special response writer impl which tries to determine script blocks the way Trinidad does it to send the scripts as separate entities in the ppr response. I wanted to check if Mojarra already had something along those lines implemented and if not, wanted to send them a bug notification, because this is the standard way to handle inline scripts over the component api. (startTag(script usually should trigger a deferred writing of the next responseWriter commands, in a special eval section) So before doing this I want to clear this up once and for all! As I said I am not eager to touch mojarra code in this regard, but I personally would prefer to be in sync in both implementations in such corner areas partially not covered by the spec! Werner Werner Punz schrieb: Hello everyone I wanted to start a legal discussion here regarding the status of Mojarra and our codebase. As far as I understood it is following. The mojarra license prevents us from using their code, while they can use ours, this is fine with me the Apache license is more liberal. The Mojarra and Apache license however do not prevent that we can have an occasional look into the mojarra codebase to check things out which are not 100% clearly defined, so that we are in sync there, or to prevent external patches being applied which might have mojarra code inside (we had that once in the past with comments copy pasted from the spec or mojarra) Am I right or wrong? I am just asking to clear this up once and for all. Werner
Re: Mojarra and us...
Matthias Wessendorf schrieb: On Fri, May 15, 2009 at 2:18 PM, Werner Punz werner.p...@gmail.com wrote: Hello everyone I wanted to start a legal discussion here regarding the status of Mojarra and our codebase. As far as I understood it is following. The mojarra license prevents us from using their code, while they can use ours, this is fine with me the Apache license is more liberal. +1 (OT *and* a side-info: OpenJDK is using Apache Harmony code :-) ) The Mojarra and Apache license however do not prevent that we can have an occasional look into the mojarra codebase to check things out which are not 100% clearly defined, so that we are in sync there, or to prevent external patches being applied which might have mojarra code inside (we had that once in the past with comments copy pasted from the spec or mojarra) Am I right or wrong? not sure on the legal side, but I find it *is* critical to take a look at such a code base. This is the question, not looking against the other codebase might introduce incompatibilities or errors might be overlooked, just like I pointed out in the example before, or even worse, external patches could go into the codebase which come straight from the mojarra codebase! As far as I can see the way the bsd and linux guys handle it is that linux freely takes BSD code why the BSD guys dont have a problem looking at the linux codebase, but they never ever would copy any code from the linux side. Werner
Re: Mojarra and us...
On Fri, May 15, 2009 at 2:22 PM, Werner Punz werner.p...@gmail.com wrote: I have to explain, I noticed that we probably need a special response writer impl which tries to determine script blocks the way Trinidad does it to send the scripts as separate entities in the ppr response. I wanted to check if Mojarra already had something along those there is a user/dev list for mojarra, right ? lines implemented and if not, wanted to send them a bug notification, because this is the standard way to handle inline scripts over the component api. (startTag(script usually should trigger a deferred writing of the next responseWriter commands, in a special eval section) So before doing this I want to clear this up once and for all! As I said I am not eager to touch mojarra code in this regard, but I personally would prefer to be in sync in both implementations in such corner areas partially not covered by the spec! IMO this is critical; -M Werner Werner Punz schrieb: Hello everyone I wanted to start a legal discussion here regarding the status of Mojarra and our codebase. As far as I understood it is following. The mojarra license prevents us from using their code, while they can use ours, this is fine with me the Apache license is more liberal. The Mojarra and Apache license however do not prevent that we can have an occasional look into the mojarra codebase to check things out which are not 100% clearly defined, so that we are in sync there, or to prevent external patches being applied which might have mojarra code inside (we had that once in the past with comments copy pasted from the spec or mojarra) Am I right or wrong? I am just asking to clear this up once and for all. Werner -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: Mojarra and us...
On Fri, May 15, 2009 at 2:27 PM, Werner Punz werner.p...@gmail.com wrote: Matthias Wessendorf schrieb: On Fri, May 15, 2009 at 2:18 PM, Werner Punz werner.p...@gmail.com wrote: Hello everyone I wanted to start a legal discussion here regarding the status of Mojarra and our codebase. As far as I understood it is following. The mojarra license prevents us from using their code, while they can use ours, this is fine with me the Apache license is more liberal. +1 (OT *and* a side-info: OpenJDK is using Apache Harmony code :-) ) The Mojarra and Apache license however do not prevent that we can have an occasional look into the mojarra codebase to check things out which are not 100% clearly defined, so that we are in sync there, or to prevent external patches being applied which might have mojarra code inside (we had that once in the past with comments copy pasted from the spec or mojarra) Am I right or wrong? not sure on the legal side, but I find it *is* critical to take a look at such a code base. This is the question, not looking against the other codebase might introduce incompatibilities or errors might be overlooked, just like I pointed out in the example before, or even worse, external patches could go into the codebase which come straight from the mojarra codebase! isn't the behavior *clear* defined in the spec ? If so, go the route; If not, ask the EG on the why ;-) -Matthias As far as I can see the way the bsd and linux guys handle it is that linux freely takes BSD code why the BSD guys dont have a problem looking at the linux codebase, but they never ever would copy any code from the linux side. Werner -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: MyFaces 2.0 PartialResponseWriter + EVALs
Ok before anyone is starting to write one. I have a script splitting response writer in state which triggers also on src attributes and the connected javascripts load the scripts via xhr and do a global eval. I have not comitted it yet, because I want to compare my code with Trinidad just to check if I have overlooked something in this area. I will commit it around next week to be reused in the partial processing area, so that we have a proper script splitting! Werner Werner Punz schrieb: Ok I added a dynamically loading loadScript function to our javascript _Utils class/function. The code basically resolves the script src handling aspect by loading the script via synchronous xhr and doing a global eval on the script! This way we dont have dom manipulations just to do the script src part on the client side, and to my knowledge the speed drop is neglectable! (Most javascript libraries do dynamic loading that way) The next step is to find out if the RI has added the start and endTag functionality the way Trinidad and others do! An if yes we have to implement it (I have started on this already) if no, I am going to file a bugreport! Werner Werner Punz schrieb: Hia Ganesh, I have to check the latest codebase, the version i have which is a few weeks old, did not have anything integrated... The main problem I see not doing it is, that usually the response writer already is in update stage when the components encode method is called which means every out goes into update so component authors cannot even trigger the eval part properly! If you want to utilize the eval part properly you have to integrate this automatically one way or the other. I will check the latest codebase this week and if they do not have it integrated I will file a bug report for Mojarra, they might probably have overlooked this aspect on the implementors side (definitely not on the spec side hence the eval cycle). I probably would not know it either on the first look, if I hadn´t worked on those aspects of Trinidad within the boundaries of a project where we tried to integrate PPR! Werner Ganesh schrieb: Hi Werner, Actually, I'm not quite sure which of the cases [1] to [4] (see below) you are referring to. Did you check the behaviour of Mojarra on this? In which case does it return eval? I'd say our PartialResponseWriter should work along the same basic line. My personal guess is they return eval either in case [1] or [3]. I'll try and find some time to set up a test on this during the next week. Best Regards, Ganesh Werner Punz schrieb: I have to evaluate that because generally the insertBefore did not trigger on all non IE browsers in the embedded case (Safari for instance failed as well, while Opera was working) so I had to embed our browser check code... Anyway the safe bet probably is to load the script synchronously via xhr and eval it manually in that case! The unsafe bet is to have the browser doing this automatically. Either way is fine with me since both methods are just a few lines of code. My personal question was more along the lines if there are any obstacles to add the eval behavior as described to the PartialResponseWriter, and how does facelets trigger the response writer in this regard. (Facelets theorectically allows to use scripts just as plain html thus we cannot use the startElement(script approach in this case unless facelets can map single tags into startElement calls) Werner Hi, There are four kinds of script constructs I can image may becoming pulled in through an ajax request: [1] component does startElement(script, component) ... endElement(script) [2] XHTML markup contains script type=text/javascript .../script (or component writes this directly to the stream) [3] markup contains h:outputSrcipt [4] markup contains script src=... IMHO only [1] qualifies to be included in the eval section of the AJAX response by the PartialResponseWriter. Execution on the Javascript side can happen with window.execScript(theActualScriptContent) like Matthias proposed. Matthias, can you explain the advantages of this? [2] should be recognized by our embedded Javascript runScripts function which in fact also does window.execScript. Werner, I think we agree on this. Everything else would cause parsing of the XHTML markup. For [3] Werners document.createElement(script) approach can be suitable though I'm not sure how you want to send this down to the browser. Are you planning to run on the extension tag in the ajax XMLSchema? Werner, your example for document.createElement(script) was based on case [4]. But how do you want to do this? Are you planning to parse all the markup for script tags with src
Re: svn commit: r774395 - /myfaces/core/branches/2_0_0/impl/src/main/java/org/apache/myfaces/application/ViewHandlerImpl.java
Hey Mike,
please make sure you are running the build;
I am seeing checkstyle problems for this new file; No license added to
the beginning
of the file...
#fixed in revision 775217
-Matthias
On Wed, May 13, 2009 at 5:10 PM, mconc...@apache.org wrote:
Author: mconcini
Date: Wed May 13 15:10:38 2009
New Revision: 774395
URL: http://svn.apache.org/viewvc?rev=774395view=rev
Log:
MYFACES-2219 - new ViewHandlerImpl class
Added:
myfaces/core/branches/2_0_0/impl/src/main/java/org/apache/myfaces/application/ViewHandlerImpl.java
Added:
myfaces/core/branches/2_0_0/impl/src/main/java/org/apache/myfaces/application/ViewHandlerImpl.java
URL:
http://svn.apache.org/viewvc/myfaces/core/branches/2_0_0/impl/src/main/java/org/apache/myfaces/application/ViewHandlerImpl.java?rev=774395view=auto
==
---
myfaces/core/branches/2_0_0/impl/src/main/java/org/apache/myfaces/application/ViewHandlerImpl.java
(added)
+++
myfaces/core/branches/2_0_0/impl/src/main/java/org/apache/myfaces/application/ViewHandlerImpl.java
Wed May 13 15:10:38 2009
@@ -0,0 +1,358 @@
+package org.apache.myfaces.application;
+
+import java.beans.BeanDescriptor;
+import java.beans.BeanInfo;
+import java.beans.PropertyDescriptor;
+import java.io.IOException;
+import java.util.ArrayList;
+import java.util.Collection;
+import java.util.HashMap;
+import java.util.Iterator;
+import java.util.List;
+import java.util.Locale;
+import java.util.Map;
+
+import javax.el.ExpressionFactory;
+import javax.el.MethodExpression;
+import javax.el.ValueExpression;
+import javax.faces.FacesException;
+import javax.faces.FactoryFinder;
+import javax.faces.application.Application;
+import javax.faces.application.StateManager;
+import javax.faces.application.ViewHandler;
+import javax.faces.component.ActionSource2;
+import javax.faces.component.EditableValueHolder;
+import javax.faces.component.UIComponent;
+import javax.faces.component.UIViewParameter;
+import javax.faces.component.UIViewRoot;
+import javax.faces.context.ExternalContext;
+import javax.faces.context.FacesContext;
+import javax.faces.event.ActionEvent;
+import javax.faces.event.MethodExpressionActionListener;
+import javax.faces.event.MethodExpressionValueChangeListener;
+import javax.faces.event.ValueChangeEvent;
+import javax.faces.render.RenderKitFactory;
+import javax.faces.render.ResponseStateManager;
+import javax.faces.validator.MethodExpressionValidator;
+import javax.faces.view.ActionSource2AttachedObjectHandler;
+import javax.faces.view.ActionSource2AttachedObjectTarget;
+import javax.faces.view.AttachedObjectHandler;
+import javax.faces.view.AttachedObjectTarget;
+import javax.faces.view.EditableValueHolderAttachedObjectHandler;
+import javax.faces.view.EditableValueHolderAttachedObjectTarget;
+import javax.faces.view.ValueHolderAttachedObjectHandler;
+import javax.faces.view.ValueHolderAttachedObjectTarget;
+import javax.faces.view.ViewDeclarationLanguage;
+import javax.faces.view.ViewDeclarationLanguageFactory;
+import javax.faces.view.ViewMetadata;
+import javax.servlet.http.HttpServletResponse;
+
+import org.apache.commons.logging.Log;
+import org.apache.commons.logging.LogFactory;
+import org.apache.myfaces.shared_impl.config.MyfacesConfig;
+import org.apache.myfaces.shared_impl.renderkit.html.util.JavascriptUtils;
+
+public class ViewHandlerImpl extends ViewHandler
+{
+ private static final Log log = LogFactory.getLog(ViewHandlerImpl.class);
+ public static final String FORM_STATE_MARKER =
!--@@JSF_FORM_STATE_MARKER@@--;
+ private ViewHandlerSupport _viewHandlerSupport;
+ private ViewDeclarationLanguageFactory _vdlFactory;
+
+ public ViewHandlerImpl()
+ {
+ _vdlFactory =
(ViewDeclarationLanguageFactory)FactoryFinder.getFactory(FactoryFinder.VIEW_DECLARATION_LANGUAGE_FACTORY);
+ if (log.isTraceEnabled())
+ log.trace(New ViewHandler instance created);
+ }
+
+ �...@override
+ public String deriveViewId(FacesContext context, String input)
+ {
+ String calculatedViewId = input;
+ try
+ {
+ //TODO: JSF 2.0 - need to make sure calculateViewId follows the
new algorithm from 7.5.2
+ calculatedViewId =
getViewHandlerSupport().calculateViewId(context, input);
+ }
+ catch (InvalidViewIdException e)
+ {
+ sendSourceNotFound(context, e.getMessage());
+ }
+ return calculatedViewId;
+ }
+
+ �...@override
+ public String getBookmarkableURL(FacesContext context, String viewId,
+ MapString, ListString parameters, boolean includeViewParams)
+ {
+ MapString, ListString viewParameters;
+ ExternalContext externalContext = context.getExternalContext();
+ if (includeViewParams)
+ {
+ viewParameters =
[jira] Resolved: (MYFACES-2235) ProjectStage extension
[ https://issues.apache.org/jira/browse/MYFACES-2235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthias Weßendorf resolved MYFACES-2235. - Resolution: Fixed Fix Version/s: 2.0.0-alpha ProjectStage extension -- Key: MYFACES-2235 URL: https://issues.apache.org/jira/browse/MYFACES-2235 Project: MyFaces Core Issue Type: Improvement Components: JSR-314 Affects Versions: 2.0.0-alpha Reporter: Matthias Weßendorf Assignee: Matthias Weßendorf Fix For: 2.0.0-alpha Attachments: myfaces2235.diff currently jsf's standard ProjectStage is a bit poor, it does not provide support for system props... In order to make that happen we (myfaces) could provide an extension for that... Wo that we could support something like: projectStage = System.getProperty(org.apache.myfaces.PROJECT_STAGE) Ordering would be: -jndi -web.xml -sys-props the current order is JNDI, followed by web.xml -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [source control] git and the ASF ...
some more infos: http://wiki.apache.org/general/GitAtApache On Fri, May 15, 2009 at 11:39 AM, Matthias Wessendorf mat...@apache.org wrote: On Fri, May 15, 2009 at 11:37 AM, Werner Punz werner.p...@gmail.com wrote: Matthias Wessendorf schrieb: core 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) +1 1.1.x branch 1.2 trunk 2.0 branch hehe :-) just wrote a similar email :-) -Matthias instead of 1.1 trunk 1.2 trunk_1.2 2.0 branch this also helps the infrastructure people! -- 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-1474) Add Window abstraction to Trinidad
Add Window abstraction to Trinidad -- Key: TRINIDAD-1474 URL: https://issues.apache.org/jira/browse/TRINIDAD-1474 Project: MyFaces Trinidad Issue Type: New Feature Components: Archetype Affects Versions: 1.2.12-core Environment: All Reporter: Blake Sullivan Add Window abstraction to Trinidad. Currently, Trinidad knows nothing of the separate browser Windows that make up a browser session. This causes weird problems. For example, the state management token cache is shared across all of the active windows with a simple LRU. If the user opens up two windows and operates on one window long enough, he will cause the token state for the original window to be purged. When the user switches back to the original window and POSTs back, the token won't be found, Trinidad will assume that this is because the session expired, and the user will be given an error. Adding the concept of a Window and a Window lifecyle opens up the following capabilities: 1) Correct handling of per-window UI state by segregating tokens by window 2) Early clean-up of UI state by aggressively purging state for closed windows 3) Applications can manager per-window state by listening for window lifecycle events 4) Sessions can be cleaned up earlier by terminating the session when the last window in the session is closed 5) A window scope can be implemented to ease using per-window state with EL 6) A window manager implementation can hide the details of handling control-N in the browser -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[TRINIDAD][API] JIRA-1474 Add Window abstraction to Trinidad
Here is the proposed api:
package org.apache.myfaces.trinidad.context;
/**
* Represents a Window in the current user's Session. Windows are
created and vended
* by the Session's WindowManager and the Window for the current request is
* available from codeWindowManager.getCurrentWindow/code
* @see WindowManager#getCurrentWindow
*/
public abstract class Window implements Serializable
{
/**
* p
* Represents the current state of the Window. Windows start out
codeOPEN/code,
* when the current window's document is being unloaded, they move to
the codeUNLOADING/code
* state and then either move back to the codeOPEN/code state if
the Window's content
* is populated with a new document from the same application, or to
the codeCLOSED/code
* state if it is not.
* /pp
* This represents the framework's best guess at the current status of
the Window.
* /p
*/
public enum LifecycleState
{
/** The Window is currently open */
OPEN,
/** The Window is being unloaded */
UNLOADING,
/** The Window is believed to be closed, either because the window
was explicitly closed
* or because the window is suspected to have been closed
*/
CLOSED
}
/**
* Represents how the window is used in the application
*/
public enum Usage
{
/** Used as a top-level application window */
FRAME,
/** Used as a dialog */
DIALOG
}
/**
* @return The unique identifier for this Window within the Session
*/
public abstract String getId();
/**
* @return The current state of the Window
*/
public abstract LifecycleState getLifecycleState();
/**
* Returns the Usage of the Window--either a top-level frame or a dialog
* @return how the window is used
*/
public abstract Usage getUsage();
}
/**
* p
* Manages the set of Windows currently in the Session and allows
listeners on the Windows'
* lifecycles to be registered.
* /p
* @see org.apache.myfaces.trinidad.context.RequestContext#getWindowManager
*/
abstract public class WindowManager
{
/**
* @param extContext ExternalContext so that the WindowManager may be
called before the
* FacesContext is available
* @return The Window that contains the document making the current
request
*/
public abstract Window getCurrentWindow(ExternalContext extContext);
/**
* @param extContext ExternalContext so that the WindowManager may be
called before the
* FacesContext is available
* @return codetrue/code if the Window making the current request
is newly created.
*/
public abstract boolean isCurrentWindowNew(ExternalContext extContext);
/**
* @param extContext ExternalContext so that the WindowManager may be
called before the
* FacesContext is available
* @return The Unmodifiable Map of WindowIds to Windows
*/
public abstract MapString, ? extends Window
getWindows(ExternalContext extContext);
/**
* p
* Registers a listener that will be informed of changes to the
Lifecylce state of any of
* the known Windows.
* /p
* p
* Window listeners may be registered automatically by adding a file
* containing the names of the classes implementing the WindowListener
in a file named
* codeorg.apache.myfaces.trinidad.event.WindowListener/code inside of
* the codeMETA_INF/services/code directory.
* /p
* @param extContext ExternalContext so that the WindowManager may be
called before the
* FacesContext is available
* @param windowListener
*/
public abstract void addWindowListener(ExternalContext extContext,
WindowListener windowListener);
/**
* Removes a listener that will be informed of changes to the
Lifecylce state of any of
* the known Windows
* @param extContext ExternalContext so that the WindowManager may be
called before the
* FacesContext is available
* @param windowListener
*/
public abstract void removeWindowListener(ExternalContext extContext,
WindowListener windowListener);
/**
* Performs any necessary action to embed the current window
identifier into the output
* @param context FacesContext to use to write the output
* @throws IOException if an output exception occurs
*/
public abstract void writeState(FacesContext context) throws IOException;
}
/**
* p
* Application-scoped factory for creating per-Session WindowManager
instances. It is the
* WindowManagerFactory implementation's responsibility to ensure that
only one
* WindowManager instance is created per-session. The
WindowManagerFactory is also responsible
* for ensuring that any mutable state in the WindowManager instances
will be successfully failed
* over.
* /p
* p
* The factory is usually specified by placing the name of the
WindowManagerFactory
* implementation class in a file named
* codeorg.apache.myfaces.trinidad.context.WindowManagerFactory/code
* in the codeMETA-INF/services/code directory
* /p
* @see org.apache.myfaces.trinidad.context.WindowManager
* @see org.apache.myfaces.trinidad.context.RequestContext#getWindowManager
*/
Re: [TRINIDAD][API] JIRA-1474 Add Window abstraction to Trinidad
Hi Blake,
I'm + 1 with the idea and the general API, but I have some concerns:
1. I don't really like the API to expose a read only map through
WindowManager.getWindows, I would prefer
WindowManager.getWindowIds(ExternalContext) and
WindowManager.getWindow(ExternalContext, String);
2. WindowListener should be an interface extending EventListener one of
its subclasses;
3. Either WindowListener or WindowLifecycleEvent is wrongly named from a
JSF point of view (althoguh it could be potentially correctly named in
Swing). All JSF Listener handle events with the exact same name as the
listener, but with Listener changed to Event, so it should either be
WindowLifecycleListener or WindowEvent for the API to be coherent with the
usual JSF nomenclature.
4. WindowListener method is not properly named. Pretty much as above, in
JSF all listener methods are called processevenType so it should either be
public void processWindowEvent or processWindowLifecycleEventdepending on
the resolution of the previous point;
5. The process method parameters do not match the usual listener
convention to receive a single event object. Would it be possible to place
the ExternalContext instance in the event?
6. I would prefer to see WindowManager.isCurrentWindowNew as
Window.isNew, it's more OOP correct;
7. Actually I would prefer the same for the add/get/removeWindowListener
Regards,
~ Simon
On Fri, May 15, 2009 at 3:09 PM, Blake Sullivan
blake.sulli...@oracle.comwrote:
Here is the proposed api:
package org.apache.myfaces.trinidad.context;
/**
* Represents a Window in the current user's Session. Windows are created
and vended
* by the Session's WindowManager and the Window for the current request is
* available from codeWindowManager.getCurrentWindow/code
* @see WindowManager#getCurrentWindow
*/
public abstract class Window implements Serializable
{
/**
* p
* Represents the current state of the Window. Windows start out
codeOPEN/code,
* when the current window's document is being unloaded, they move to the
codeUNLOADING/code
* state and then either move back to the codeOPEN/code state if the
Window's content
* is populated with a new document from the same application, or to the
codeCLOSED/code
* state if it is not.
* /pp
* This represents the framework's best guess at the current status of the
Window.
* /p
*/
public enum LifecycleState
{
/** The Window is currently open */
OPEN,
/** The Window is being unloaded */
UNLOADING,
/** The Window is believed to be closed, either because the window was
explicitly closed
* or because the window is suspected to have been closed
*/
CLOSED
}
/**
* Represents how the window is used in the application
*/
public enum Usage
{
/** Used as a top-level application window */
FRAME,
/** Used as a dialog */
DIALOG
}
/**
* @return The unique identifier for this Window within the Session
*/
public abstract String getId();
/**
* @return The current state of the Window
*/
public abstract LifecycleState getLifecycleState();
/**
* Returns the Usage of the Window--either a top-level frame or a dialog
* @return how the window is used
*/
public abstract Usage getUsage();
}
/**
* p
* Manages the set of Windows currently in the Session and allows listeners
on the Windows'
* lifecycles to be registered.
* /p
* @see org.apache.myfaces.trinidad.context.RequestContext#getWindowManager
*/
abstract public class WindowManager
{
/**
* @param extContext ExternalContext so that the WindowManager may be
called before the
* FacesContext is available
* @return The Window that contains the document making the current request
*/
public abstract Window getCurrentWindow(ExternalContext extContext);
/**
* @param extContext ExternalContext so that the WindowManager may be
called before the
* FacesContext is available
* @return codetrue/code if the Window making the current request is
newly created.
*/
public abstract boolean isCurrentWindowNew(ExternalContext extContext);
/**
* @param extContext ExternalContext so that the WindowManager may be
called before the
* FacesContext is available
* @return The Unmodifiable Map of WindowIds to Windows
*/
public abstract MapString, ? extends Window getWindows(ExternalContext
extContext);
/**
* p
* Registers a listener that will be informed of changes to the Lifecylce
state of any of
* the known Windows.
* /p
* p
* Window listeners may be registered automatically by adding a file
* containing the names of the classes implementing the WindowListener in a
file named
* codeorg.apache.myfaces.trinidad.event.WindowListener/code inside of
* the codeMETA_INF/services/code directory.
* /p
* @param extContext ExternalContext so that the WindowManager may be
called before the
* FacesContext is available
* @param
Re: Mojarra and us...
Hi, At least for the AJAX part I can tell that many details are treated as implementation details, so the spec purposely leaves them open. On some details in the jsdocs Roger has even relaxed the wording of the spec to leave the details to the impl. If we muddle through the specs and do it our way the MyFaces AJAX and the Mojarra AJAX won't have compatible XML interfaces (syntactically, yes, but not sematically). This would be bad in two ways: 1. The way things have been going until now the spec will further evolve to match the behaviour of Mojarra. They have all right to try out new features in their impl before writing them into the spec, but it seems wise to stay close. 2. If the MyFaces Javascript doesn't work with the Mojarra server, the t:ajax tag (I'm working on it ...) wouldn't run with Mojarra. Here is how I've been treating this: By testing with Mojarra I've checked their implementation's behaviour if I wasn't sure how to interpret the specs. Just running it and checking a test apps behaviour as well as the transferred XML stream for serveral corner cases definitely doesn't break any license. I don't think reading their code is a helpful idea - we'd just repeat the same errors they have made and aren't we convinced to know it better? ;-) Best regards, Ganesh Matthias Wessendorf schrieb: isn't the behavior *clear* defined in the spec ? If so, go the route; If not, ask the EG on the why ;-) -Matthias
Re: [Fwd: Re: f:ajax not working inside composite components?]
From a logical standpoint you cannot avoid to send the entire abslute
(html) id
because otherwise on the server side you cannot
identify the component properly.
If you take the relative id, a proper identification within the
component tree is impossible.
So the id sent down has to be the absolute id otherwise we do not have a
chance of identifying the affected components properly!
Werner
Ganesh schrieb:
Hi everybody who is involved with MyFaces 2.0,
have you seen this?
From this:
h:selectOneMenu id=menu
value=#{place.zoomIndex}
valueChangeListener=#{place.zoomChanged}
style=font-size:13px;font-family:Palatino
f:selectItems value=#{places.zoomLevelItems}/
*f:ajax execute=@this render=image/
*
/h:selectOneMenu
,nested inside a ui:repeat and a composition, Mojarra creates this AJAX
request:
form form
j_id-939329235_16ef8569:0:j_id-939329235_16ef8513:j_id1608935764_5fe6690f:menu
3
javax.faces.ViewState -1363564553004911965:-1863826268811277742
javax.faces.behavior.event valueChange
javax.faces.partial.ajax true
javax.faces.partial.event change
javax.faces.partial.execute
j_id-939329235_16ef8569:0:j_id-939329235_16ef8513:j_id1608935764_5fe6690f:menu
javax.faces.partial.render
j_id-939329235_16ef8569:0:j_id-939329235_16ef8513:j_id1608935764_5fe6690f:image
javax.faces.source
j_id-939329235_16ef8569:0:j_id-939329235_16ef8513:j_id1608935764_5fe6690f:menu
In the JSR-314 spec it says in table 14-1:
render - A space delimited list of client identifiers or one of the
keywords (Section 14.2.2 “Keywords”). These reference the components
that will be processed during the “render” phase of the request
processing lifecycle.
now, 'image' is definitely not a client identifier, but a component
identifier. And there is more! Andy Schwarz comments on this:
When specifying execute/render ids for f:ajax, the id resolution
behavior is similar to findComponent(). So, if you specify a relative
id, eg. image, this should be resolved relative to the nearest naming
container. In your case, that would be the composite component. In order
to specify an absolute id, you would prefix the id with :, eg.
:foo:mycompositecomp:image.
Both kinds of behaviour - resolving ids either relative to the nearest
naming container or prepending them with a : to mark them absolute -
cannot be found in the spec.
So, what do we do? Shall we follow Mojarras paths even if not covered by
the specs words? Or do purposely break application portability to adhere
to the specs?
Please comment on this.
Best regards,
Ganesh
P.S.: For the curious ones: The reason why Davids code doesn't work
because there is some bug in the decode processing of ui:repeat that
Ryan is currently fixing ...
Original-Nachricht
Betreff: Re: f:ajax not working inside composite components?
Datum: Tue, 12 May 2009 14:39:58 -0700
Von: Ryan Lubke ryan.lu...@sun.com
Antwort an: JSR 314 Open Mailing list jsr-314-o...@jcp.org
An: jsr-314-o...@jcp.org
Referenzen:
75fa9e650905120936p114faae7g987969d2e0b7c...@mail.gmail.com
4a09adcc.8040...@oracle.com
75fa9e650905121417h7e0b4758obbd3de65a428c...@mail.gmail.com
On 5/12/09 2:17 PM, David Geary wrote:
2009/5/12 Andy Schwartz andy.schwa...@oracle.com
mailto:andy.schwa...@oracle.com
Hi David -
Hi Andy,
Thanks for responding.
David Geary wrote On 5/12/2009 12:36 PM ET:
h:selectOneMenu id=menu
value=#{place.zoomIndex}
valueChangeListener=#{place.zoomChanged}
style=font-size:13px;font-family:Palatino
f:selectItems value=#{places.zoomLevelItems}/
*f:ajax execute=@this render=image/
*
/h:selectOneMenu
This looks good to me.
Yup. I thought that perhaps I was failing validation for some reason,
so I added immediate=true to the f:ajax tag, but it didn't fix the
problem. :(
With FireBug, I've verified that a POST request is indeed executed
when I change the zoom level, and it appears that everything is in
order:
form form
j_id-939329235_16ef8569:0:j_id-939329235_16ef8513:j_id1608935764_5fe6690f:menu
3
javax.faces.ViewState -1363564553004911965:-1863826268811277742
javax.faces.behavior.event valueChange
javax.faces.partial.ajax true
javax.faces.partial.event change
javax.faces.partial.execute
j_id-939329235_16ef8569:0:j_id-939329235_16ef8513:j_id1608935764_5fe6690f:menu
javax.faces.partial.render
j_id-939329235_16ef8569:0:j_id-939329235_16ef8513:j_id1608935764_5fe6690f:image
javax.faces.source
j_id-939329235_16ef8569:0:j_id-939329235_16ef8513:j_id1608935764_5fe6690f:menu
And the request payload looks right - seems like all of the
necessary information is present. (Though, man, those
auto-generated client ids sure are huge!)
Yes, it looks right to me too.
I get a response back that looks like this:
?xml version=1.0 encoding=utf-8?
partial-responsechangesupdate
id=javax.faces.ViewState![CDATA[1747337848471748955:2683565346534242854
Re: [Fwd: Re: f:ajax not working inside composite components?]
Hi Werner,
of course you have to send the absolute id.
But in the json attributes execute and render we should use the JSF id's
(so not the html id of the element).
Alex
2009/5/15 Werner Punz werner.p...@gmail.com
From a logical standpoint you cannot avoid to send the entire abslute
(html) id
because otherwise on the server side you cannot
identify the component properly.
If you take the relative id, a proper identification within the component
tree is impossible.
So the id sent down has to be the absolute id otherwise we do not have a
chance of identifying the affected components properly!
Werner
Ganesh schrieb:
Hi everybody who is involved with MyFaces 2.0,
have you seen this?
From this:
h:selectOneMenu id=menu
value=#{place.zoomIndex}
valueChangeListener=#{place.zoomChanged}
style=font-size:13px;font-family:Palatino
f:selectItems value=#{places.zoomLevelItems}/
*f:ajax execute=@this render=image/
*
/h:selectOneMenu
,nested inside a ui:repeat and a composition, Mojarra creates this AJAX
request:
form form
j_id-939329235_16ef8569:0:j_id-939329235_16ef8513:j_id1608935764_5fe6690f:menu
3
javax.faces.ViewState -1363564553004911965:-1863826268811277742
javax.faces.behavior.event valueChange
javax.faces.partial.ajax true
javax.faces.partial.event change
javax.faces.partial.execute
j_id-939329235_16ef8569:0:j_id-939329235_16ef8513:j_id1608935764_5fe6690f:menu
javax.faces.partial.render
j_id-939329235_16ef8569:0:j_id-939329235_16ef8513:j_id1608935764_5fe6690f:image
javax.faces.source
j_id-939329235_16ef8569:0:j_id-939329235_16ef8513:j_id1608935764_5fe6690f:menu
In the JSR-314 spec it says in table 14-1:
render - A space delimited list of client identifiers or one of the
keywords (Section 14.2.2 “Keywords”). These reference the components that
will be processed during the “render” phase of the request processing
lifecycle.
now, 'image' is definitely not a client identifier, but a component
identifier. And there is more! Andy Schwarz comments on this:
When specifying execute/render ids for f:ajax, the id resolution
behavior is similar to findComponent(). So, if you specify a relative id,
eg. image, this should be resolved relative to the nearest naming
container. In your case, that would be the composite component. In order to
specify an absolute id, you would prefix the id with :, eg.
:foo:mycompositecomp:image.
Both kinds of behaviour - resolving ids either relative to the nearest
naming container or prepending them with a : to mark them absolute -
cannot be found in the spec.
So, what do we do? Shall we follow Mojarras paths even if not covered by
the specs words? Or do purposely break application portability to adhere to
the specs?
Please comment on this.
Best regards,
Ganesh
P.S.: For the curious ones: The reason why Davids code doesn't work
because there is some bug in the decode processing of ui:repeat that Ryan is
currently fixing ...
Original-Nachricht
Betreff: Re: f:ajax not working inside composite components?
Datum: Tue, 12 May 2009 14:39:58 -0700
Von: Ryan Lubke ryan.lu...@sun.com
Antwort an: JSR 314 Open Mailing list jsr-314-o...@jcp.org
An: jsr-314-o...@jcp.org
Referenzen: 75fa9e650905120936p114faae7g987969d2e0b7c...@mail.gmail.com
4a09adcc.8040...@oracle.com
75fa9e650905121417h7e0b4758obbd3de65a428c...@mail.gmail.com
On 5/12/09 2:17 PM, David Geary wrote:
2009/5/12 Andy Schwartz andy.schwa...@oracle.com mailto:
andy.schwa...@oracle.com
Hi David -
Hi Andy,
Thanks for responding.
David Geary wrote On 5/12/2009 12:36 PM ET:
h:selectOneMenu id=menu
value=#{place.zoomIndex}
valueChangeListener=#{place.zoomChanged}
style=font-size:13px;font-family:Palatino
f:selectItems value=#{places.zoomLevelItems}/
*f:ajax execute=@this render=image/
*
/h:selectOneMenu
This looks good to me.
Yup. I thought that perhaps I was failing validation for some reason, so
I added immediate=true to the f:ajax tag, but it didn't fix the problem.
:(
With FireBug, I've verified that a POST request is indeed executed when
I change the zoom level, and it appears that everything is in order:
form form
j_id-939329235_16ef8569:0:j_id-939329235_16ef8513:j_id1608935764_5fe6690f:menu
3
javax.faces.ViewState -1363564553004911965:-1863826268811277742
javax.faces.behavior.event valueChange
javax.faces.partial.ajax true
javax.faces.partial.event change
javax.faces.partial.execute
j_id-939329235_16ef8569:0:j_id-939329235_16ef8513:j_id1608935764_5fe6690f:menu
javax.faces.partial.render
j_id-939329235_16ef8569:0:j_id-939329235_16ef8513:j_id1608935764_5fe6690f:image
javax.faces.source
j_id-939329235_16ef8569:0:j_id-939329235_16ef8513:j_id1608935764_5fe6690f:menu
And the request payload looks right - seems like all of the
necessary information is present. (Though, man, those
auto-generated client ids sure
Re: [source control] git and the ASF ...
I would say -1. Seems pointless to use another version control client that is not 100% compatible with SVN when the SVN command-line and UI clients works fine. What next, a mercurial read-only repository too? We have chosen to use subversion with MyFaces at Apache, I don't see any reason to support other clients just to appease some peoples technology fix. But this is just my opinion. Note that there are tools out there to do this type of support from the client, not the server. For example, http://www.selenic.com/mercurial/wiki/WorkingWithSubversion details how to use Mercurial as an SVN client and even be able to commit to SVN! In my opinion, if someone wants to use git, then they should find a similar tool for git and not burden the folks at Apache. -Andrew FYI: http://www.russellbeattie.com/blog/distributed-revision-control-systems-git-vs-mercurial-vs-svn http://texagon.blogspot.com/2008/02/use-mercurial-you-git.html http://weblog.masukomi.org/2008/02/07/a-rebuttal-to-use-mercurial-you-git On Fri, May 15, 2009 at 10:45 AM, Matthias Wessendorf mat...@apache.org wrote: some more infos: http://wiki.apache.org/general/GitAtApache On Fri, May 15, 2009 at 11:39 AM, Matthias Wessendorf mat...@apache.org wrote: On Fri, May 15, 2009 at 11:37 AM, Werner Punz werner.p...@gmail.com wrote: Matthias Wessendorf schrieb: core 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) +1 1.1.x branch 1.2 trunk 2.0 branch hehe :-) just wrote a similar email :-) -Matthias instead of 1.1 trunk 1.2 trunk_1.2 2.0 branch this also helps the infrastructure people! -- 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
Re: [source control] git and the ASF ...
I don't know much about git, but I know that other committers on Apache Cayenne use git to commit to the Cayenne svn, so it's certainly possible to do what Andrew suggests. From my limited git understanding, that's the typical practice of using git -- as a front-end to svn or cvs. On Fri, May 15, 2009 at 4:08 PM, Andrew Robinson andrew.rw.robin...@gmail.com wrote: I would say -1. Seems pointless to use another version control client that is not 100% compatible with SVN when the SVN command-line and UI clients works fine. What next, a mercurial read-only repository too? We have chosen to use subversion with MyFaces at Apache, I don't see any reason to support other clients just to appease some peoples technology fix. But this is just my opinion. Note that there are tools out there to do this type of support from the client, not the server. For example, http://www.selenic.com/mercurial/wiki/WorkingWithSubversion details how to use Mercurial as an SVN client and even be able to commit to SVN! In my opinion, if someone wants to use git, then they should find a similar tool for git and not burden the folks at Apache. -Andrew FYI: http://www.russellbeattie.com/blog/distributed-revision-control-systems-git-vs-mercurial-vs-svn http://texagon.blogspot.com/2008/02/use-mercurial-you-git.html http://weblog.masukomi.org/2008/02/07/a-rebuttal-to-use-mercurial-you-git On Fri, May 15, 2009 at 10:45 AM, Matthias Wessendorf mat...@apache.org wrote: some more infos: http://wiki.apache.org/general/GitAtApache On Fri, May 15, 2009 at 11:39 AM, Matthias Wessendorf mat...@apache.org wrote: On Fri, May 15, 2009 at 11:37 AM, Werner Punz werner.p...@gmail.com wrote: Matthias Wessendorf schrieb: core 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) +1 1.1.x branch 1.2 trunk 2.0 branch hehe :-) just wrote a similar email :-) -Matthias instead of 1.1 trunk 1.2 trunk_1.2 2.0 branch this also helps the infrastructure people! -- 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
Re: [source control] git and the ASF ...
Hey andrew, Thanks for your mail. There is a discussion on the members list. Let me point them to our thread. Thanks again! Sent from my iPod. On 15.05.2009, at 22:08, Andrew Robinson andrew.rw.robin...@gmail.com wrote: I would say -1. Seems pointless to use another version control client that is not 100% compatible with SVN when the SVN command-line and UI clients works fine. What next, a mercurial read-only repository too? We have chosen to use subversion with MyFaces at Apache, I don't see any reason to support other clients just to appease some peoples technology fix. But this is just my opinion. Note that there are tools out there to do this type of support from the client, not the server. For example, http://www.selenic.com/mercurial/wiki/WorkingWithSubversion details how to use Mercurial as an SVN client and even be able to commit to SVN! In my opinion, if someone wants to use git, then they should find a similar tool for git and not burden the folks at Apache. -Andrew FYI: http://www.russellbeattie.com/blog/distributed-revision-control-systems-git-vs-mercurial-vs-svn http://texagon.blogspot.com/2008/02/use-mercurial-you-git.html http://weblog.masukomi.org/2008/02/07/a-rebuttal-to-use-mercurial-you-git On Fri, May 15, 2009 at 10:45 AM, Matthias Wessendorf mat...@apache.org wrote: some more infos: http://wiki.apache.org/general/GitAtApache On Fri, May 15, 2009 at 11:39 AM, Matthias Wessendorf mat...@apache.org wrote: On Fri, May 15, 2009 at 11:37 AM, Werner Punz werner.p...@gmail.com wrote: Matthias Wessendorf schrieb: core 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) +1 1.1.x branch 1.2 trunk 2.0 branch hehe :-) just wrote a similar email :-) -Matthias instead of 1.1 trunk 1.2 trunk_1.2 2.0 branch this also helps the infrastructure people! -- 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] Updated: (MYFACES-1982) Too many open files on Weblogic 9.2
[ https://issues.apache.org/jira/browse/MYFACES-1982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe updated MYFACES-1982: Status: Patch Available (was: Open) Too many open files on Weblogic 9.2 --- Key: MYFACES-1982 URL: https://issues.apache.org/jira/browse/MYFACES-1982 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 1.2.3 Environment: Linux Red Hat AS4 (2.6.9-34.ELsmp), JRockit 1.5.0_14, Weblogic 9.2 MP2 Reporter: Roland Schaer Priority: Critical Due to the default value of the parameter CONFIG_REFRESH_PERIOD, each request causes to reload the web.xml and potential faces config files defined in the web.xml. These loaded files were not freed up and led to open file handles (which are limited to 1024 by default) on the system. After a while the open file handles prevents the system from creating new SocketConnections. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [TRINIDAD][API] JIRA-1474 Add Window abstraction to Trinidad
Sent from my iPod.
On 15.05.2009, at 21:35, Simon Lessard simon.lessar...@gmail.com
wrote:
Hi Blake,
I'm + 1 with the idea and the general
+1 good idea!
API, but I have some concerns:
I don't really like the API to expose a read only map through
WindowManager.getWindows, I would prefer
WindowManager.getWindowIds(ExternalContext) and
WindowManager.getWindow(E
I like these two methods
xternalContext, String);
WindowListener should be an interface extending EventListener one of
its subclasses;
Either WindowListener or WindowLifecycleEvent is wrongly named from
a JSF point of view (althoguh it could be potentially correctly
named in Swing). All JSF Listener handle events with the exact same
name as the listener, but with Listener changed to Event, so it
should either be WindowLifecycleListener or WindowEvent for the API
to be coherent with the usual JSF nomenclature.
WindowListener method is not properly named. Pretty much as above,
in JSF all listener methods are called processevenType so it
should either be public void processWindowEvent or
processWindowLifecycleEventdepending on the resolution of the
previous point;
The process method parameters do not match the usual listener
convention to receive a single event object. Would it be possible to
place the ExternalContext instance in the event?
I would prefer to see WindowManager.isCurrentWindowNew as
Window.isNew, it's more OOP correct;
I agree
-M
Actually I would prefer the same for the add/get/removeWindowListener
Regards,
~ Simon
On Fri, May 15, 2009 at 3:09 PM, Blake Sullivan blake.sulli...@oracle.com
wrote:
Here is the proposed api:
package org.apache.myfaces.trinidad.context;
/**
* Represents a Window in the current user's Session. Windows are
created and vended
* by the Session's WindowManager and the Window for the current
request is
* available from codeWindowManager.getCurrentWindow/code
* @see WindowManager#getCurrentWindow
*/
public abstract class Window implements Serializable
{
/**
* p
* Represents the current state of the Window. Windows start out
codeOPEN/code,
* when the current window's document is being unloaded, they move
to the codeUNLOADING/code
* state and then either move back to the codeOPEN/code state if
the Window's content
* is populated with a new document from the same application, or to
the codeCLOSED/code
* state if it is not.
* /pp
* This represents the framework's best guess at the current status
of the Window.
* /p
*/
public enum LifecycleState
{
/** The Window is currently open */
OPEN,
/** The Window is being unloaded */
UNLOADING,
/** The Window is believed to be closed, either because the window
was explicitly closed
* or because the window is suspected to have been closed
*/
CLOSED
}
/**
* Represents how the window is used in the application
*/
public enum Usage
{
/** Used as a top-level application window */
FRAME,
/** Used as a dialog */
DIALOG
}
/**
* @return The unique identifier for this Window within the Session
*/
public abstract String getId();
/**
* @return The current state of the Window
*/
public abstract LifecycleState getLifecycleState();
/**
* Returns the Usage of the Window--either a top-level frame or a
dialog
* @return how the window is used
*/
public abstract Usage getUsage();
}
/**
* p
* Manages the set of Windows currently in the Session and allows
listeners on the Windows'
* lifecycles to be registered.
* /p
* @see
org.apache.myfaces.trinidad.context.RequestContext#getWindowManager
*/
abstract public class WindowManager
{
/**
* @param extContext ExternalContext so that the WindowManager may
be called before the
* FacesContext is available
* @return The Window that contains the document making the current
request
*/
public abstract Window getCurrentWindow(ExternalContext extContext);
/**
* @param extContext ExternalContext so that the WindowManager may
be called before the
* FacesContext is available
* @return codetrue/code if the Window making the current
request is newly created.
*/
public abstract boolean isCurrentWindowNew(ExternalContext
extContext);
/**
* @param extContext ExternalContext so that the WindowManager may
be called before the
* FacesContext is available
* @return The Unmodifiable Map of WindowIds to Windows
*/
public abstract MapString, ? extends Window
getWindows(ExternalContext extContext);
/**
* p
* Registers a listener that will be informed of changes to the
Lifecylce state of any of
* the known Windows.
* /p
* p
* Window listeners may be registered automatically by adding a file
* containing the names of the classes implementing the
WindowListener in a file named
* codeorg.apache.myfaces.trinidad.event.WindowListener/code
inside of
* the codeMETA_INF/services/code directory.
* /p
* @param extContext ExternalContext so that the WindowManager may
be
[jira] Commented: (MYFACES-1982) Too many open files on Weblogic 9.2
[ https://issues.apache.org/jira/browse/MYFACES-1982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12709957#action_12709957 ] Leonardo Uribe commented on MYFACES-1982: - Committed solution (1.2.7-SNAPSHOT). Since there is no confirmation if the changes this solves the problem, this issue will be let open. Too many open files on Weblogic 9.2 --- Key: MYFACES-1982 URL: https://issues.apache.org/jira/browse/MYFACES-1982 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 1.2.3 Environment: Linux Red Hat AS4 (2.6.9-34.ELsmp), JRockit 1.5.0_14, Weblogic 9.2 MP2 Reporter: Roland Schaer Priority: Critical Due to the default value of the parameter CONFIG_REFRESH_PERIOD, each request causes to reload the web.xml and potential faces config files defined in the web.xml. These loaded files were not freed up and led to open file handles (which are limited to 1024 by default) on the system. After a while the open file handles prevents the system from creating new SocketConnections. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [source control] git and the ASF ...
Anderw, I asked to move the thread to committ...@. Thx Matthias Sent from my iPod. On 15.05.2009, at 22:21, Matthias Wessendorf mwessend...@gmail.com wrote: Hey andrew, Thanks for your mail. There is a discussion on the members list. Let me point them to our thread. Thanks again! Sent from my iPod. On 15.05.2009, at 22:08, Andrew Robinson andrew.rw.robin...@gmail.com wrote: I would say -1. Seems pointless to use another version control client that is not 100% compatible with SVN when the SVN command-line and UI clients works fine. What next, a mercurial read-only repository too? We have chosen to use subversion with MyFaces at Apache, I don't see any reason to support other clients just to appease some peoples technology fix. But this is just my opinion. Note that there are tools out there to do this type of support from the client, not the server. For example, http://www.selenic.com/mercurial/wiki/WorkingWithSubversion details how to use Mercurial as an SVN client and even be able to commit to SVN! In my opinion, if someone wants to use git, then they should find a similar tool for git and not burden the folks at Apache. -Andrew FYI: http://www.russellbeattie.com/blog/distributed-revision-control-systems-git-vs-mercurial-vs-svn http://texagon.blogspot.com/2008/02/use-mercurial-you-git.html http://weblog.masukomi.org/2008/02/07/a-rebuttal-to-use-mercurial-you-git On Fri, May 15, 2009 at 10:45 AM, Matthias Wessendorf mat...@apache.org wrote: some more infos: http://wiki.apache.org/general/GitAtApache On Fri, May 15, 2009 at 11:39 AM, Matthias Wessendorf mat...@apache.org wrote: On Fri, May 15, 2009 at 11:37 AM, Werner Punz werner.p...@gmail.com wrote: Matthias Wessendorf schrieb: core 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) +1 1.1.x branch 1.2 trunk 2.0 branch hehe :-) just wrote a similar email :-) -Matthias instead of 1.1 trunk 1.2 trunk_1.2 2.0 branch this also helps the infrastructure people! -- 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
jsf.ajax.request parameters vs. f:ajax parameters
Hi, The confusion was based on the mixup between javascript parameters and tag attributes. It's easy: The tag takes component ids and the javascript function takes clientids. Here's what the spec says on this: table 10-3, f:ajax's render attribute: If a literal is specified, it must be a space delimited String of component identifiers and/or one of the keywords outlined in Section 14.2.2 “Keywords”. If not specified, then @none is the default . If a ValueExpression is specified, it must refer to a property that returns a Collection of Strings. Each String in the Collection must not contain spaces. table 14-1, jsf.ajax.request's render parameter: A space delimited list of client identifiers or one of the keywords (Section 14.2.2 “Keywords”). These reference the components that will be processed during the “render” phase of the request processing lifecycle. Best regards, Ganesh
[jira] Commented: (MYFACES-2165) concurrent issue in initializing myfaces 1.1.6
[ https://issues.apache.org/jira/browse/MYFACES-2165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12709973#action_12709973 ] Leonardo Uribe commented on MYFACES-2165: - committed solution on both branches but since there is no confirmation of the patch provided solves the problem, this will be let open concurrent issue in initializing myfaces 1.1.6 -- Key: MYFACES-2165 URL: https://issues.apache.org/jira/browse/MYFACES-2165 Project: MyFaces Core Issue Type: Bug Affects Versions: 1.1.6 Environment: tomcat 6.0.18 java 1.6.0_06 Reporter: xuxiankun Priority: Critical Attachments: MYFACES-2165.patch after starting tomcat, we will get a error when i visit a faces page. we can fix this issue by restarting tomcat. so i think it's concurrent issue. java.lang.NullPointerException at org.apache.myfaces.application.jsp.JspViewHandlerImpl.getServletMapping(JspViewHandlerImpl.java:388) at org.apache.myfaces.application.jsp.JspViewHandlerImpl.renderView(JspViewHandlerImpl.java:222) at org.ajax4jsf.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:108) at org.ajax4jsf.application.AjaxViewHandler.renderView(AjaxViewHandler.java:216) at org.apache.shale.validator.faces.ValidatorViewHandler.renderView(ValidatorViewHandler.java:130) at org.ajax4jsf.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:108) at org.ajax4jsf.application.AjaxViewHandler.renderView(AjaxViewHandler.java:216) at org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:41) at org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:146) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:147) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at cn.com.brilliance.begen.webapp.servlet.BeGenFilter.doFilter(BeGenFilter.java:56) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:141) at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:281) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:630) at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:436) at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:374) at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:302) at cn.com.brilliance.begen.webapp.servlet.LoginServlet.doPost(LoginServlet.java:91) at javax.servlet.http.HttpServlet.service(HttpServlet.java:637) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.springframework.orm.hibernate3.support.OpenSessionInViewFilter.doFilterInternal(OpenSessionInViewFilter.java:198) at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:76) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.springframework.web.filter.CharacterEncodingFilter.doFilterInternal(CharacterEncodingFilter.java:96) at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:76) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at
[jira] Updated: (MYFACES-2155) HtmlLinkRenderer did not recognize ankers (#)
[ https://issues.apache.org/jira/browse/MYFACES-2155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe updated MYFACES-2155: Resolution: Fixed Fix Version/s: 1.2.7-SNAPSHOT 1.1.7-SNAPSHOT Status: Resolved (was: Patch Available) Solution committed on both shared branches Thanks Martin for provide this patch HtmlLinkRenderer did not recognize ankers (#) - Key: MYFACES-2155 URL: https://issues.apache.org/jira/browse/MYFACES-2155 Project: MyFaces Core Issue Type: Bug Reporter: Martin Haimberger Assignee: Martin Haimberger Fix For: 1.1.7-SNAPSHOT, 1.2.7-SNAPSHOT Attachments: HtmlLinkRenderer.patch HtmlLinkRenderer did not recognize ankers (#) and encoded them wrong if there were f:params used (- url#anker?paramname=paramvalue instead of url?paramname=paramvalue#anker) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-1891) ClassCastException in converter when Hiding / Showing unselected selectOneRadio
[
https://issues.apache.org/jira/browse/MYFACES-1891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12709990#action_12709990
]
Leonardo Uribe commented on MYFACES-1891:
-
The problem described before is a variant of the original exception.
The solution is a little bit different from the proposed on the modified
RendererUtils file (but the file helps to find what's wrong, thanks Patrick for
the patch). It is add this code to getConvertedStringValue (look the last
return):
public static String getConvertedStringValue(FacesContext context,
UIComponent component,
Converter converter, Object value) {
if (converter == null) {
if (value == null) {
return ;
}
else if (value instanceof String) {
return (String) value;
} else if (RendererUtils.NOTHING.equals(value)) {
return ;
} else {
throw new IllegalArgumentException(
Value is no String (class= + value.getClass().getName() +
, value= + value + ) and component
+ component.getClientId(context) + with path:
+ getPathToComponent(component)
+ does not have a Converter);
}
}
if (RendererUtils.NOTHING.equals(value))
{
return converter.getAsString(context, component, );
}
else
{
return converter.getAsString(context, component, value);
}
}
If a converter is used and RendererUtils.NOTHING is set, we should call
converter.getAsString with empty string as value (right now
RendererUtils.NOTHING is passed, but it must not, because this var is used when
no selection is set by the user and then pass it as null value).
The fix should be done for both 1.1 and 1.2 branches
ClassCastException in converter when Hiding / Showing unselected
selectOneRadio
---
Key: MYFACES-1891
URL: https://issues.apache.org/jira/browse/MYFACES-1891
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 1.2.3
Environment: MyFaces 1.2.3, Spring WebFlow 2.0.2, RichFaces 3.2.1,
Tomahawk 1.1.6, Facelets 1.1.15.B1, Tomcat 6.0.16
Reporter: Patrick Schmidt
Assignee: Leonardo Uribe
Fix For: 1.1.6
Attachments: example.zip, MYFACES-1891-custom-converter.patch,
RendererUtils.patch, RendererUtils_1.2.6_patched.java
See the attached example.
When the block with the selectOneRadio ist shown, then hidden and then shown
again a ClassCastException occurs in the Converter. The selectOneRadio has as
submittedValue org.apache.myfaces.shared_impl.renderkit.RendererUtils$1, for
which the conversion is done.
javax.faces.FacesException: Exception while calling encodeEnd on component :
{Component-Path : [Class: org.ajax4jsf.component.AjaxViewRoot,ViewId:
/WEB-INF/pages/schnellerfassung/dea/dea.xhtml][Class:
javax.faces.component.html.HtmlForm,Id: form][Class:
org.apache.myfaces.custom.div.Div,Id: hideableBlock][Class:
javax.faces.component.html.HtmlSelectOneRadio,Id: selectOneRadio]}
at
javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:610)
at
org.ajax4jsf.renderkit.RendererBase.renderChild(RendererBase.java:286)
at
org.ajax4jsf.renderkit.RendererBase.renderChildren(RendererBase.java:262)
at
org.ajax4jsf.renderkit.RendererBase.renderChild(RendererBase.java:284)
at
org.ajax4jsf.renderkit.RendererBase.renderChildren(RendererBase.java:262)
at
org.ajax4jsf.renderkit.RendererBase.renderChild(RendererBase.java:284)
at
org.ajax4jsf.renderkit.AjaxChildrenRenderer.encodeAjaxComponent(AjaxChildrenRenderer.java:125)
at
org.ajax4jsf.renderkit.AjaxChildrenRenderer.encodeAjaxChildren(AjaxChildrenRenderer.java:68)
at
org.ajax4jsf.renderkit.AjaxChildrenRenderer.encodeAjaxComponent(AjaxChildrenRenderer.java:116)
at
org.ajax4jsf.renderkit.AjaxContainerRenderer.encodeAjax(AjaxContainerRenderer.java:123)
at org.ajax4jsf.component.AjaxViewRoot.encodeAjax(AjaxViewRoot.java:673)
at
org.ajax4jsf.component.AjaxViewRoot.encodeChildren(AjaxViewRoot.java:544)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:239)
at
com.sun.facelets.FaceletViewHandler.renderView(FaceletViewHandler.java:592)
at
org.ajax4jsf.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:108)
at
org.ajax4jsf.application.AjaxViewHandler.renderView(AjaxViewHandler.java:189)
at org.springframework.faces.webflow.JsfView.render(JsfView.java:92)
at
[jira] Resolved: (MYFACES-1891) ClassCastException in converter when Hiding / Showing unselected selectOneRadio
[
https://issues.apache.org/jira/browse/MYFACES-1891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leonardo Uribe resolved MYFACES-1891.
-
Resolution: Fixed
Fix Version/s: (was: 1.1.6)
1.2.7-SNAPSHOT
1.1.7-SNAPSHOT
ClassCastException in converter when Hiding / Showing unselected
selectOneRadio
---
Key: MYFACES-1891
URL: https://issues.apache.org/jira/browse/MYFACES-1891
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 1.2.3
Environment: MyFaces 1.2.3, Spring WebFlow 2.0.2, RichFaces 3.2.1,
Tomahawk 1.1.6, Facelets 1.1.15.B1, Tomcat 6.0.16
Reporter: Patrick Schmidt
Assignee: Leonardo Uribe
Fix For: 1.1.7-SNAPSHOT, 1.2.7-SNAPSHOT
Attachments: example.zip, MYFACES-1891-custom-converter.patch,
RendererUtils.patch, RendererUtils_1.2.6_patched.java
See the attached example.
When the block with the selectOneRadio ist shown, then hidden and then shown
again a ClassCastException occurs in the Converter. The selectOneRadio has as
submittedValue org.apache.myfaces.shared_impl.renderkit.RendererUtils$1, for
which the conversion is done.
javax.faces.FacesException: Exception while calling encodeEnd on component :
{Component-Path : [Class: org.ajax4jsf.component.AjaxViewRoot,ViewId:
/WEB-INF/pages/schnellerfassung/dea/dea.xhtml][Class:
javax.faces.component.html.HtmlForm,Id: form][Class:
org.apache.myfaces.custom.div.Div,Id: hideableBlock][Class:
javax.faces.component.html.HtmlSelectOneRadio,Id: selectOneRadio]}
at
javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:610)
at
org.ajax4jsf.renderkit.RendererBase.renderChild(RendererBase.java:286)
at
org.ajax4jsf.renderkit.RendererBase.renderChildren(RendererBase.java:262)
at
org.ajax4jsf.renderkit.RendererBase.renderChild(RendererBase.java:284)
at
org.ajax4jsf.renderkit.RendererBase.renderChildren(RendererBase.java:262)
at
org.ajax4jsf.renderkit.RendererBase.renderChild(RendererBase.java:284)
at
org.ajax4jsf.renderkit.AjaxChildrenRenderer.encodeAjaxComponent(AjaxChildrenRenderer.java:125)
at
org.ajax4jsf.renderkit.AjaxChildrenRenderer.encodeAjaxChildren(AjaxChildrenRenderer.java:68)
at
org.ajax4jsf.renderkit.AjaxChildrenRenderer.encodeAjaxComponent(AjaxChildrenRenderer.java:116)
at
org.ajax4jsf.renderkit.AjaxContainerRenderer.encodeAjax(AjaxContainerRenderer.java:123)
at org.ajax4jsf.component.AjaxViewRoot.encodeAjax(AjaxViewRoot.java:673)
at
org.ajax4jsf.component.AjaxViewRoot.encodeChildren(AjaxViewRoot.java:544)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:239)
at
com.sun.facelets.FaceletViewHandler.renderView(FaceletViewHandler.java:592)
at
org.ajax4jsf.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:108)
at
org.ajax4jsf.application.AjaxViewHandler.renderView(AjaxViewHandler.java:189)
at org.springframework.faces.webflow.JsfView.render(JsfView.java:92)
at
org.springframework.webflow.engine.ViewState.render(ViewState.java:240)
at
org.springframework.webflow.engine.ViewState.resume(ViewState.java:199)
at org.springframework.webflow.engine.Flow.resume(Flow.java:535)
at
org.springframework.webflow.engine.impl.FlowExecutionImpl.resume(FlowExecutionImpl.java:261)
at
org.springframework.webflow.executor.FlowExecutorImpl.resumeExecution(FlowExecutorImpl.java:153)
at
org.springframework.webflow.mvc.servlet.FlowHandlerAdapter.handle(FlowHandlerAdapter.java:173)
at
org.springframework.webflow.mvc.servlet.FlowController.handleRequest(FlowController.java:172)
at
org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter.handle(SimpleControllerHandlerAdapter.java:48)
at
org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:875)
at
org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:809)
at
org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:571)
at
org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet.java:511)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
com.metzler.ec.web.filter.RendererFilter.doFilter(RendererFilter.java:183)
at
[jira] Resolved: (MYFACES-2177) ConvertDateTimeTag timeZone does not work with ValueExpression of return type String
[ https://issues.apache.org/jira/browse/MYFACES-2177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe resolved MYFACES-2177. - Resolution: Fixed Fix Version/s: 1.2.7-SNAPSHOT Assignee: Leonardo Uribe The code on ConvertDateTimeTag is right, the problem comes from tld generation. Really is an exception to the rule, so the best is change on the velocity template. Thanks for point this issue. ConvertDateTimeTag timeZone does not work with ValueExpression of return type String Key: MYFACES-2177 URL: https://issues.apache.org/jira/browse/MYFACES-2177 Project: MyFaces Core Issue Type: Bug Affects Versions: 1.2.6 Reporter: Philipp Schoepf Assignee: Leonardo Uribe Fix For: 1.2.7-SNAPSHOT A always get an exception like this when I bind a VE avaluating to a TimeZone pattern (GMT+1) to the timeZone property of the convertDateTime converter: java.lang.IllegalArgumentException: Cannot convert GMT+1 of type class java.lang.String to class java.util.TimeZone This worked for MyFaces 1.1 and since we are currently migrating this breaks our code. I believe the root cause for this problem is the definition of the convertDateTimeTag in the myfaces tld, which will never allow VE with return types other than java.util.TimeZone to be bound: attribute description![CDATA[The time zone to use instead of GMT (the default timezone). When this value is a value-binding to a TimeZone instance, that timezone is used. Otherwise this value is treated as a String containing a timezone id, ie as the ID parameter of method java.util.TimeZone.getTimeZone(String).]]/description nametimeZone/name deferred-value typejava.util.TimeZone/type /deferred-value /attribute -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-1808) h:commandLink doesn't execute action when Javascript is disabled
[ https://issues.apache.org/jira/browse/MYFACES-1808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe resolved MYFACES-1808. - Resolution: Duplicate Assignee: Leonardo Uribe This is a duplicate of MYFACES-1692. For more information, see the comments there. h:commandLink doesn't execute action when Javascript is disabled Key: MYFACES-1808 URL: https://issues.apache.org/jira/browse/MYFACES-1808 Project: MyFaces Core Issue Type: Bug Components: JSR-127 Affects Versions: 1.1.5 Environment: Liferay Portal 4.3.5, Tomcat 6.0, Java 6 Reporter: Martin Goldhahn Assignee: Leonardo Uribe Priority: Minor Fix For: 1.1.7-SNAPSHOT I run the following view in a portlet (Liferay 4.3.5). I also have a navigation rule for the back action. simple page: %@ taglib uri=http://java.sun.com/jsf/core; prefix=f % %@ taglib uri=http://java.sun.com/jsf/html; prefix=h % f:view f:loadBundle basename=Language var=msgs / h:form id=articleForm h:outputText value=ARTICLE / h:commandLink action=back value=back/ /h:form /f:view In the rendered page, when I click on the link. Nothing happens. Debugging the code shows me that the form is not set to submitted in the restore phase. (org.apache.myfaces.shared_impl.renderkit.html.HtmlFormRenderBase, line 227 in version 1.1.5) When clicking the link, the form is not submitted and the parameter articleForm_SUBMIT is not added to the request. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-2008) Character encoding in Content-Type is ignored
[
https://issues.apache.org/jira/browse/MYFACES-2008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leonardo Uribe resolved MYFACES-2008.
-
Resolution: Fixed
Fix Version/s: 1.1.7-SNAPSHOT
Assignee: Leonardo Uribe
Thanks to Taro App for provide us this patch
Character encoding in Content-Type is ignored
-
Key: MYFACES-2008
URL: https://issues.apache.org/jira/browse/MYFACES-2008
Project: MyFaces Core
Issue Type: Bug
Components: General
Affects Versions: 1.1.6
Reporter: Taro App
Assignee: Leonardo Uribe
Fix For: 1.1.7-SNAPSHOT
Original Estimate: 1h
Remaining Estimate: 1h
In a constructor of ServletExternalContextImpl.java, if character encoding is
looked up from Content-Type header, it is not set on request character
encoding.
This bug exists in MyFaces Core 1.1.6 and also in SVN trunk for 1.1.
This bug does not exists in 1.2.x. (The logic is moved to
calculateCharacterEncoding method, and fixed there.)
Current Code:
if (characterEncoding == null) {
HttpSession session = httpServletRequest.getSession(false);
if (session != null) {
characterEncoding = (String)
session.getAttribute(ViewHandler.CHARACTER_ENCODING_KEY);
}
if (characterEncoding != null) {
setCharacterEncodingMethod.invoke(servletRequest, new
Object[]{characterEncoding});
}
}
Should be fixed to:
if (characterEncoding == null) {
HttpSession session = httpServletRequest.getSession(false);
if (session != null) {
characterEncoding = (String)
session.getAttribute(ViewHandler.CHARACTER_ENCODING_KEY);
}
}
if (characterEncoding != null) {
setCharacterEncodingMethod.invoke(servletRequest, new
Object[]{characterEncoding});
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-2167) If graphicImage does not have value/url is not rendered in MyFaces Core JSF 1.1
[ https://issues.apache.org/jira/browse/MYFACES-2167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe resolved MYFACES-2167. - Resolution: Fixed Fix Version/s: 1.1.7-SNAPSHOT Assignee: Leonardo Uribe (was: Bruno Aranda) If graphicImage does not have value/url is not rendered in MyFaces Core JSF 1.1 --- Key: MYFACES-2167 URL: https://issues.apache.org/jira/browse/MYFACES-2167 Project: MyFaces Core Issue Type: Bug Components: JSR-127 Affects Versions: 1.1.6 Reporter: Jifeng Liu Assignee: Leonardo Uribe Fix For: 1.1.7-SNAPSHOT This issue also happens in MyFaces Core JSF 1.1. Could you fix it in Core JSF 1.1 as well. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-2160) The action in tr:commandButton is not fired if you use the trinidad jsf library (in 1.1.5 it works).
[ https://issues.apache.org/jira/browse/MYFACES-2160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe resolved MYFACES-2160. - Resolution: Fixed Fix Version/s: 1.1.7-SNAPSHOT Assignee: Leonardo Uribe On trinidad 1.1.x, the state is saved on a param called org.apache.myfaces.trinidad.faces.STATE instead javax.faces.ViewState (note that on jsf 1.2 the state param was normalized so trinidad 1.2.x uses javax.faces.ViewState). The fix is allow RestoreViewExecutor to recognize a postback if trinidad state param is on the request. The action in tr:commandButton is not fired if you use the trinidad jsf library (in 1.1.5 it works). Key: MYFACES-2160 URL: https://issues.apache.org/jira/browse/MYFACES-2160 Project: MyFaces Core Issue Type: Bug Affects Versions: 1.1.6 Environment: Trinidad JSF Library Reporter: Roger Wegmann Assignee: Leonardo Uribe Fix For: 1.1.7-SNAPSHOT Attachments: test.zip I can provide an example. If I change in my pom file dependency groupIdorg.apache.myfaces.core/groupId artifactIdmyfaces-impl/artifactId version1.1.5/version scoperuntime/scope /dependency to dependency groupIdorg.apache.myfaces.core/groupId artifactIdmyfaces-impl/artifactId version1.1.6/version scoperuntime/scope /dependency it doesn't work anymore. I only change the version from 1.1.5 to 1.1.6 and the commandButton doesn't work anymore. It should navigate to an other page but it doesn't work anymore. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [TRINIDAD][API] JIRA-1474 Add Window abstraction to Trinidad
Simon Lessard said the following On 5/15/2009 12:35 PM PT:
Hi Blake,
I'm + 1 with the idea and the general API, but I have some concerns:
1. I don't really like the API to expose a read only map through
WindowManager.getWindows, I would prefer
WindowManager.getWindowIds(ExternalContext) and
WindowManager.getWindow(ExternalContext, String);
Is your worry over that the Map is read only? The two separate methods
prevent the developer from leveraging the Map interface.
1. WindowListener should be an interface extending EventListener
one of its subclasses;
Fair enough, the rationale for making this an abstract class was so we
could add more event types later. However, since the WindowManager
class is itself an abstract class we could add more event listener
interfaces later to the WindowManager later, so I agree that the
interface is fine
1. Either WindowListener or WindowLifecycleEvent is wrongly named
from a JSF point of view (althoguh it could be potentially
correctly named in Swing). All JSF Listener handle events with
the exact same name as the listener, but with Listener changed
to Event, so it should either be WindowLifecycleListener or
WindowEvent for the API to be coherent with the usual JSF
nomenclature.
See above. I agree that if we use an interface then the listener class
must be WindowLifecycleListener
1. WindowListener method is not properly named. Pretty much as
above, in JSF all listener methods are called processevenType
so it should either be public void processWindowEvent or
processWindowLifecycleEventdepending on the resolution of the
previous point;
2. The process method parameters do not match the usual listener
convention to receive a single event object. Would it be
possible to place the ExternalContext instance in the event?
I guess we could put the ExternalContext in the event, though the field
will need to be transient and getExternalContext() method on the event
would need to document that it might return null if the event has been
serialized. All of which is pretty gross. In this case the extra
parameter is much cleaner. I believe that the convention is really to
aid Java Beans design tools using introspection and would prefer
cleanliness in this case.
1. I would prefer to see WindowManager.isCurrentWindowNew as
Window.isNew, it's more OOP correct;
OK. The original implementation only tracked the new status of the
current window, which was tracked by the WindowManager (which is why the
WindowManager). However, due to the need to answer this question in the
face of redirects and other weirdness, the Windows in the implementation
I have been testing do maintain their new state, so I agree that it
makes more sense for the Window to answer this question.
1. Actually I would prefer the same for the
add/get/removeWindowListener
Prefer the same what? Are you talking about the ExternalContext?
Thanks for the helpful feedback.
--Blake Sullivan
Regards,
~ Simon
On Fri, May 15, 2009 at 3:09 PM, Blake Sullivan
blake.sulli...@oracle.com mailto:blake.sulli...@oracle.com wrote:
Here is the proposed api:
package org.apache.myfaces.trinidad.context;
/**
* Represents a Window in the current user's Session. Windows are
created and vended
* by the Session's WindowManager and the Window for the current
request is
* available from codeWindowManager.getCurrentWindow/code
* @see WindowManager#getCurrentWindow
*/
public abstract class Window implements Serializable
{
/**
* p
* Represents the current state of the Window. Windows start out
codeOPEN/code,
* when the current window's document is being unloaded, they move
to the codeUNLOADING/code
* state and then either move back to the codeOPEN/code state
if the Window's content
* is populated with a new document from the same application, or
to the codeCLOSED/code
* state if it is not.
* /pp
* This represents the framework's best guess at the current
status of the Window.
* /p
*/
public enum LifecycleState
{
/** The Window is currently open */
OPEN,
/** The Window is being unloaded */
UNLOADING,
/** The Window is believed to be closed, either because the
window was explicitly closed
* or because the window is suspected to have been closed
*/
CLOSED
}
/**
* Represents how the window is used in the application
*/
public enum Usage
{
/** Used as a top-level application window */
FRAME,
/** Used as a dialog */
DIALOG
}
/**
* @return The unique identifier for this Window within the Session
*/
public abstract String getId();
/**
* @return The current state of the Window
*/
public abstract
[jira] Commented: (MYFACES-2160) The action in tr:commandButton is not fired if you use the trinidad jsf library (in 1.1.5 it works).
[ https://issues.apache.org/jira/browse/MYFACES-2160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12710072#action_12710072 ] Leonardo Uribe commented on MYFACES-2160: - Thanks a lot to Roger Wegmann for the test provided. It helps a lot. The action in tr:commandButton is not fired if you use the trinidad jsf library (in 1.1.5 it works). Key: MYFACES-2160 URL: https://issues.apache.org/jira/browse/MYFACES-2160 Project: MyFaces Core Issue Type: Bug Affects Versions: 1.1.6 Environment: Trinidad JSF Library Reporter: Roger Wegmann Assignee: Leonardo Uribe Fix For: 1.1.7-SNAPSHOT Attachments: test.zip I can provide an example. If I change in my pom file dependency groupIdorg.apache.myfaces.core/groupId artifactIdmyfaces-impl/artifactId version1.1.5/version scoperuntime/scope /dependency to dependency groupIdorg.apache.myfaces.core/groupId artifactIdmyfaces-impl/artifactId version1.1.6/version scoperuntime/scope /dependency it doesn't work anymore. I only change the version from 1.1.5 to 1.1.6 and the commandButton doesn't work anymore. It should navigate to an other page but it doesn't work anymore. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [source control] git and the ASF ...
Ah lovely saturday morning and a general technology discussion. Ok here is the deal, it is a very common practice to use git for local versioning and svn or cvs for hosting the code (I do that very often). There are downsides to this practice. First of all git-svn does not have external parsing. Git has a similar mechanism subprojects but there is no bridget between git and svn in this regard, you have to symlink for instance manually to match the externals. Secondly it is a speed issue as well. Git is a distributed filesystem which does most operations locally and delegates the server to a storage system only. Which means you have local branches and local commit histories (one of the reasons why I use it) but the downside is it mirrors literally all revisions into you local filesystem (which is not as bad as it sounds since it stores the revisions very efficiently, way more than svn does) which means the initial mirror of a bigger project takes a very long time. And there the apache infrastructure which by far is not our idea comes into the game, having a read only git mirror speeds up this process much more swiftly. As for Andrews argument, this is no bothering from our side, as it seems the infrastructure people have been working on this for almost a year now and now have a stable infrastructure and many projects have moved towards this read only mirror. The also seem to think about providing the same fo Mercurial in the future. Werner Mike Kienenberger schrieb: I don't know much about git, but I know that other committers on Apache Cayenne use git to commit to the Cayenne svn, so it's certainly possible to do what Andrew suggests. From my limited git understanding, that's the typical practice of using git -- as a front-end to svn or cvs. On Fri, May 15, 2009 at 4:08 PM, Andrew Robinson andrew.rw.robin...@gmail.com wrote: I would say -1. Seems pointless to use another version control client that is not 100% compatible with SVN when the SVN command-line and UI clients works fine. What next, a mercurial read-only repository too? We have chosen to use subversion with MyFaces at Apache, I don't see any reason to support other clients just to appease some peoples technology fix. But this is just my opinion. Note that there are tools out there to do this type of support from the client, not the server. For example, http://www.selenic.com/mercurial/wiki/WorkingWithSubversion details how to use Mercurial as an SVN client and even be able to commit to SVN! In my opinion, if someone wants to use git, then they should find a similar tool for git and not burden the folks at Apache. -Andrew FYI: http://www.russellbeattie.com/blog/distributed-revision-control-systems-git-vs-mercurial-vs-svn http://texagon.blogspot.com/2008/02/use-mercurial-you-git.html http://weblog.masukomi.org/2008/02/07/a-rebuttal-to-use-mercurial-you-git On Fri, May 15, 2009 at 10:45 AM, Matthias Wessendorf mat...@apache.org wrote: some more infos: http://wiki.apache.org/general/GitAtApache On Fri, May 15, 2009 at 11:39 AM, Matthias Wessendorf mat...@apache.org wrote: On Fri, May 15, 2009 at 11:37 AM, Werner Punz werner.p...@gmail.com wrote: Matthias Wessendorf schrieb: core 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) +1 1.1.x branch 1.2 trunk 2.0 branch hehe :-) just wrote a similar email :-) -Matthias instead of 1.1 trunk 1.2 trunk_1.2 2.0 branch this also helps the infrastructure people! -- 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
