Concurrency problems in Myfaces 1.1.5
Hello, We found a NullPointerException occuring in JspViewHandlerImpl.getServletMappings(). It could be traced back to an implementation problem in method org.apache.myfaces.shared_impl.webapp.webxml.WebXML.getServletMappings() . This method is used as singleton. When called simultaneously from different requests, the result collection saved as member variable remains in inconsistent state and contains some unexpected null entries causing the NPE in JspViewHandlerImpl. We produced that error with a frameset having 2 frames using JSF pages, but the frameset definition itself not. It might probably come under different circumstances too. Our simplest solution was to synchronize the whole block of the method altough more efficient ways shall be possible. Please note that other methods (e.g. getFacesExtensionsFilterMappings()) of this and similar classes will lack the same problem. Sorry if you already have fixed this in later versions of MyFaces (we ourself can not upgrade yet). Thank you for your notice. Cheers, Matthias.
Re: jira organisation question regarding myfaces-extensions
+1 On Fri, Aug 14, 2009 at 20:58, Gerhard Petracekgerhard.petra...@gmail.com wrote: hi, i was told that independent releases of the different subprojects wouldn't be possible. it seems that this information isn't correct. however, the much more interesting part is that the constellation at trinidad is ok because these parts belong together. that's not the case with myfaces extensions. since we don't expect that much subprojects i think we should continue to have a jira project for each extension project. furthermore, it would get a bit confusing to have one jira project and a lot of components which don't belong together. if we keep the current structure, we have: jira project: EXTVAL component: Core component: Property Validation component: Bean Validation component: Generic Support component: Trinidad Support and e.g.: jira project: EXTSCRIPT component: Core component: Groovy component: [other scripting language] so it's a clear separation... if there are no major concerns about it, i think we should keep it as it is. regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2009/8/14 Matthias Wessendorf mat...@apache.org On Fri, Aug 14, 2009 at 11:04 AM, Werner Punzwerner.p...@gmail.com wrote: Werner Punz schrieb: Hello everyone while I am preparing my initial commit I noticed following. We have a subproject for extension-extval but nothing more in this regard. Which means since I cannot open my own subproject in jira I am somehow blocked. Wouldnt it be better to have the project itself reside under extensions and then have different modules for extval, groovy etc.? Ok Gerhard just gave me the explanation, it has something to do with the release management. I think that in Trinidad it pretty much works well. We have plugin releases and core releases. With different release notes. Not sure what he means. Perhaps he could jump in ?! Anyway Manfred, Matthias, can anyone of you open an extensions-groovy jira subprojekt for me? Werner -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: Concurrency problems in Myfaces 1.1.5
2009/8/17 matthias.cla...@t-systems.com Hello, We found a NullPointerException occuring in JspViewHandlerImpl.getServletMappings(). It could be traced back to an implementation problem in method org.apache.myfaces.shared_impl.webapp.webxml.WebXML.getServletMappings() . This method is used as singleton. When called simultaneously from different requests, the result collection saved as member variable remains in inconsistent state and contains some unexpected null entries causing the NPE in JspViewHandlerImpl. We produced that error with a frameset having 2 frames using JSF pages, but the frameset definition itself not. It might probably come under different circumstances too. Our simplest solution was to synchronize the whole block of the method altough more efficient ways shall be possible. Please note that other methods (e.g. getFacesExtensionsFilterMappings()) of this and similar classes will lack the same problem. Sorry if you already have fixed this in later versions of MyFaces (we ourself can not upgrade yet). Hi I remember that one. Take a look at this one: http://issues.apache.org/jira/browse/MYFACES-2165 A patch was applied, so the solution is included in 1.1.7 and 1.2.7. It could be good to have confirmation that solution solves the problem (I haven't close that one yet by that reason). regards Leonardo Uribe Thank you for your notice. Cheers, Matthias.
RE: Concurrency problems in Myfaces 1.1.5
Hi, A patch was applied, so the solution is included in 1.1.7 and 1.2.7. It could be good to have confirmation that solution solves the problem (I haven't close that one yet by that reason). I reviewed the issue and the patch. I am sorry I can neither say definitly yes nor no. Why? It is a race condition - we validated from code review and in running system that our solution solves the problem at hand The but is: I solved it using a synchronized block around the whole method body and can't make sure that there are no new problems introduced with volatile. And there's no guarantee for other code parts bearing the same pattern. The advantage is the blocking of synchronized (what volatile does not), thus computing the collection's content will be done only once and not multiple times in case of concurrent usage. Please feel free to take this as a yes, it solves the problem in my opinion. I think you might close your issue. Best regards, Matthias From: Leonardo Uribe [mailto:lu4...@gmail.com] Sent: Monday, August 17, 2009 10:18 AM To: MyFaces Development Subject: Re: Concurrency problems in Myfaces 1.1.5 2009/8/17 matthias.cla...@t-systems.com Hello, We found a NullPointerException occuring in JspViewHandlerImpl.getServletMappings(). It could be traced back to an implementation problem in method org.apache.myfaces.shared_impl.webapp.webxml.WebXML.getServletMappings() . This method is used as singleton. When called simultaneously from different requests, the result collection saved as member variable remains in inconsistent state and contains some unexpected null entries causing the NPE in JspViewHandlerImpl. We produced that error with a frameset having 2 frames using JSF pages, but the frameset definition itself not. It might probably come under different circumstances too. Our simplest solution was to synchronize the whole block of the method altough more efficient ways shall be possible. Please note that other methods (e.g. getFacesExtensionsFilterMappings()) of this and similar classes will lack the same problem. Sorry if you already have fixed this in later versions of MyFaces (we ourself can not upgrade yet). Hi I remember that one. Take a look at this one: http://issues.apache.org/jira/browse/MYFACES-2165 A patch was applied, so the solution is included in 1.1.7 and 1.2.7. It could be good to have confirmation that solution solves the problem (I haven't close that one yet by that reason). regards Leonardo Uribe Thank you for your notice. Cheers, Matthias.
RESULT was:[VOTE] Extensions - Scripting subproject
Ok the necessary steps are done, we have the necessary number of binding votes: +1 Matthias Wessendorf, Bruno Aranda, Jan Kees van Andel Leonardo Uribe Simon Lessard Grand Smith Gerhard Petracek No 0 or -1 and the number of necessary PMC member votes has been reached. Mathias can you open a new subprojekt on the Jira for me? I will commit my code later today, but have in mind it wont work out of the box for now since it needs a myfaces patch for the classloading. Werner Werner Punz schrieb: Hello everyone just to make sure things are formal enough I am going to open a vote on this I want to open a myfaces-scripting extensions subproject/module within the domain of our extensions project. (For now we have projects not modules) The current status is that this project will add a scripting extension to myfaces which allows to code JSF artefacts in groovy and enables dynamic reloading without server shutdown of those artefacts. The plan for now is, to commit the initial code which works for myfaces 1.2 and then work on resolving pending issues regarding the myfaces connectivity and generally the server connectivty and then move the code over to MyFaces 2.0. [ ] +1 for opening the project for the initial commit and the ongoing work [ ] +0 [ ] -1 for not opening it Werner
[jira] Created: (MYFACES-2332) build fails du to broken repo dependency
build fails du to broken repo dependency Key: MYFACES-2332 URL: https://issues.apache.org/jira/browse/MYFACES-2332 Project: MyFaces Core Issue Type: Bug Components: build process Affects Versions: 1.2.8-SNAPSHOT Reporter: Werner Punz The myfaces core 1.2 trunk build process fails, the reason is an obsolete java.net address in the repository sections of the pom.xml changing this address to the address which currently is in use in other submodules fixes it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2332) build fails du to broken repo dependency
[ https://issues.apache.org/jira/browse/MYFACES-2332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12744056#action_12744056 ] Werner Punz commented on MYFACES-2332: -- correction on my side, changing all java.net dependencies to http://download.java.net/maven/2 resolves the issue I will commit the fixup for the 1.2 trunk build fails du to broken repo dependency Key: MYFACES-2332 URL: https://issues.apache.org/jira/browse/MYFACES-2332 Project: MyFaces Core Issue Type: Bug Components: build process Affects Versions: 1.2.8-SNAPSHOT Reporter: Werner Punz Assignee: Werner Punz The myfaces core 1.2 trunk build process fails, the reason is an obsolete java.net address in the repository sections of the pom.xml changing this address to the address which currently is in use in other submodules fixes it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-2332) build fails du to broken repo dependency
[ https://issues.apache.org/jira/browse/MYFACES-2332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Werner Punz resolved MYFACES-2332. -- Resolution: Fixed fixed build works now for me build fails du to broken repo dependency Key: MYFACES-2332 URL: https://issues.apache.org/jira/browse/MYFACES-2332 Project: MyFaces Core Issue Type: Bug Components: build process Affects Versions: 1.2.8-SNAPSHOT Reporter: Werner Punz Assignee: Werner Punz The myfaces core 1.2 trunk build process fails, the reason is an obsolete java.net address in the repository sections of the pom.xml changing this address to the address which currently is in use in other submodules fixes it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[trinidad] Unresolved compilation problems
Hi there, I'm sorry to bring a complete noob question, but I'm trying to build trinidad from svn (HEAD), with little success. Here is what I did : - checked out sources ( svn co http://svn.apache.org/repos/asf/myfaces/trinidad/trunk/ trinidad ) (I get revision 804902) - built/installed with maven : mvn -Dmaven.test.skip=true install (no error at this step) - included it in my test app (as maven dependency) After this, when I try to get my test homepage, I get this error message (see below). Note that the homepage does work fine with the latest snapshot available from http://people.apache.org/repo/m2-snapshot-repository/org/apache/myfaces/trinidad/trinidad-api/1.2.12-SNAPSHOT/ . Could somebody tell me what I am missing ? Or is it because there really are errore in the current HEAD ? Cedric 17 aout 2009 09:59:38 javax.faces.webapp._ErrorPageWriter handleThrowable GRAVE: An exception occurred javax.faces.FacesException: javax.servlet.ServletException: java.lang.Error: Unresolved compilation problems: The import org.apache.myfaces.trinidad.component.UIXDocument cannot be resolved Incompatible conditional operand types UIComponent and UIXDocument UIXDocument cannot be resolved to a type at org.apache.myfaces.context.servlet.ServletExternalContextImpl.dispatch(ServletExternalContextImpl.java:347) at org.apache.myfaces.trinidad.context.ExternalContextDecorator.dispatch(ExternalContextDecorator.java:44) at org.apache.myfaces.trinidad.context.ExternalContextDecorator.dispatch(ExternalContextDecorator.java:44) at org.apache.myfaces.trinidadinternal.context.FacesContextFactoryImpl$OverrideDispatch.dispatch(FacesContextFactoryImpl.jav a:267) at org.apache.myfaces.application.jsp.JspViewHandlerImpl.buildView(JspViewHandlerImpl.java:486) at org.apache.myfaces.application.jsp.JspViewHandlerImpl.renderView(JspViewHandlerImpl.java:337) at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:48) at org.apache.myfaces.trinidadinternal.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:193) at org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:41) at org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:140) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:155) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java: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.valves.AccessLogValve.invoke(AccessLogValve.java:567) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:849) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:454) at java.lang.Thread.run(Thread.java:619) Caused by: org.apache.jasper.JasperException: javax.servlet.ServletException: java.lang.Error: Unresolved compilation problems: The import org.apache.myfaces.trinidad.component.UIXDocument cannot be resolved Incompatible conditional operand types UIComponent and UIXDocument UIXDocument cannot be resolved to a type at org.apache.jasper.servlet.JspServletWrapper.handleJspException(JspServletWrapper.java:522) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:398) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:342) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:267) 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.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:646) 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
Re: [trinidad] Unresolved compilation problems
Are you building from the root trinidad directory or are you trying to build one of the subfolders? I have never seen it not find UIXDocument.It looks like you are getting the error at run time, not compile time. What runtime environment are you using? On Mon, Aug 17, 2009 at 3:19 AM, Cédric Durmontcdurm...@gmail.com wrote: Hi there, I'm sorry to bring a complete noob question, but I'm trying to build trinidad from svn (HEAD), with little success. Here is what I did : - checked out sources ( svn co http://svn.apache.org/repos/asf/myfaces/trinidad/trunk/ trinidad ) (I get revision 804902) - built/installed with maven : mvn -Dmaven.test.skip=true install (no error at this step) - included it in my test app (as maven dependency) After this, when I try to get my test homepage, I get this error message (see below). Note that the homepage does work fine with the latest snapshot available from http://people.apache.org/repo/m2-snapshot-repository/org/apache/myfaces/trinidad/trinidad-api/1.2.12-SNAPSHOT/ . Could somebody tell me what I am missing ? Or is it because there really are errore in the current HEAD ? Cedric 17 aout 2009 09:59:38 javax.faces.webapp._ErrorPageWriter handleThrowable GRAVE: An exception occurred javax.faces.FacesException: javax.servlet.ServletException: java.lang.Error: Unresolved compilation problems: The import org.apache.myfaces.trinidad.component.UIXDocument cannot be resolved Incompatible conditional operand types UIComponent and UIXDocument UIXDocument cannot be resolved to a type at org.apache.myfaces.context.servlet.ServletExternalContextImpl.dispatch(ServletExternalContextImpl.java:347) at org.apache.myfaces.trinidad.context.ExternalContextDecorator.dispatch(ExternalContextDecorator.java:44) at org.apache.myfaces.trinidad.context.ExternalContextDecorator.dispatch(ExternalContextDecorator.java:44) at org.apache.myfaces.trinidadinternal.context.FacesContextFactoryImpl$OverrideDispatch.dispatch(FacesContextFactoryImpl.jav a:267) at org.apache.myfaces.application.jsp.JspViewHandlerImpl.buildView(JspViewHandlerImpl.java:486) at org.apache.myfaces.application.jsp.JspViewHandlerImpl.renderView(JspViewHandlerImpl.java:337) at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:48) at org.apache.myfaces.trinidadinternal.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:193) at org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:41) at org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:140) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:155) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java: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.valves.AccessLogValve.invoke(AccessLogValve.java:567) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:849) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:454) at java.lang.Thread.run(Thread.java:619) Caused by: org.apache.jasper.JasperException: javax.servlet.ServletException: java.lang.Error: Unresolved compilation problems: The import org.apache.myfaces.trinidad.component.UIXDocument cannot be resolved Incompatible conditional operand types UIComponent and UIXDocument UIXDocument cannot be resolved to a type at org.apache.jasper.servlet.JspServletWrapper.handleJspException(JspServletWrapper.java:522) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:398) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:342) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:267) 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
[jira] Commented: (TOMAHAWK-1441) JSCookMenu over HTTPS in IE6
[ https://issues.apache.org/jira/browse/TOMAHAWK-1441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12744110#action_12744110 ] Brendan Buckley commented on TOMAHAWK-1441: --- Could you provide more details on the nature of the problems you have with JSCookMenu? I have recently upgraded to 1.1.9 and am testing the application over HTTPS also with IE6, but do not see any issue with JSCookMenu. We use the Javascript implmentation that is in the 1.1.9 release (i.e. do not specify an alternative javascriptLocation). JSCookMenu over HTTPS in IE6 Key: TOMAHAWK-1441 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1441 Project: MyFaces Tomahawk Issue Type: Bug Components: JS Cook Menu Affects Versions: 1.1.9 Environment: IE 6 Reporter: Pedro Busko Priority: Blocker JSCookMenu in Tomahawk 1.1.9 does not work over HTTPS in IE6, even with the 2.0.4 JavaScript implementation of the JSCookMenu . The menu simply does not show. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [trinidad] Unresolved compilation problems
yes mvn install is called from trinidad root my runtime environment is : tomcat 6.0.20 myfaces 1.2.7 jdk 1.6.0_14 running under windows XP (french) 2009/8/17 Andrew Robinson andrew.rw.robin...@gmail.com: Are you building from the root trinidad directory or are you trying to build one of the subfolders? I have never seen it not find UIXDocument.It looks like you are getting the error at run time, not compile time. What runtime environment are you using? On Mon, Aug 17, 2009 at 3:19 AM, Cédric Durmontcdurm...@gmail.com wrote: Hi there, I'm sorry to bring a complete noob question, but I'm trying to build trinidad from svn (HEAD), with little success. Here is what I did : - checked out sources ( svn co http://svn.apache.org/repos/asf/myfaces/trinidad/trunk/ trinidad ) (I get revision 804902) - built/installed with maven : mvn -Dmaven.test.skip=true install (no error at this step) - included it in my test app (as maven dependency) After this, when I try to get my test homepage, I get this error message (see below). Note that the homepage does work fine with the latest snapshot available from http://people.apache.org/repo/m2-snapshot-repository/org/apache/myfaces/trinidad/trinidad-api/1.2.12-SNAPSHOT/ . Could somebody tell me what I am missing ? Or is it because there really are errore in the current HEAD ? Cedric 17 aout 2009 09:59:38 javax.faces.webapp._ErrorPageWriter handleThrowable GRAVE: An exception occurred javax.faces.FacesException: javax.servlet.ServletException: java.lang.Error: Unresolved compilation problems: The import org.apache.myfaces.trinidad.component.UIXDocument cannot be resolved Incompatible conditional operand types UIComponent and UIXDocument UIXDocument cannot be resolved to a type at org.apache.myfaces.context.servlet.ServletExternalContextImpl.dispatch(ServletExternalContextImpl.java:347) at org.apache.myfaces.trinidad.context.ExternalContextDecorator.dispatch(ExternalContextDecorator.java:44) at org.apache.myfaces.trinidad.context.ExternalContextDecorator.dispatch(ExternalContextDecorator.java:44) at org.apache.myfaces.trinidadinternal.context.FacesContextFactoryImpl$OverrideDispatch.dispatch(FacesContextFactoryImpl.jav a:267) at org.apache.myfaces.application.jsp.JspViewHandlerImpl.buildView(JspViewHandlerImpl.java:486) at org.apache.myfaces.application.jsp.JspViewHandlerImpl.renderView(JspViewHandlerImpl.java:337) at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:48) at org.apache.myfaces.trinidadinternal.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:193) at org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:41) at org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:140) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:155) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java: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.valves.AccessLogValve.invoke(AccessLogValve.java:567) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:849) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:454) at java.lang.Thread.run(Thread.java:619) Caused by: org.apache.jasper.JasperException: javax.servlet.ServletException: java.lang.Error: Unresolved compilation problems: The import org.apache.myfaces.trinidad.component.UIXDocument cannot be resolved Incompatible conditional operand types UIComponent and UIXDocument UIXDocument cannot be resolved to a type at org.apache.jasper.servlet.JspServletWrapper.handleJspException(JspServletWrapper.java:522) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:398) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:342) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:267) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at
[jira] Created: (MYFACES-2333) Necessary extension to allow custom classloading to be plugged into myfaces in a server compatible way
Necessary extension to allow custom classloading to be plugged into myfaces in a server compatible way -- Key: MYFACES-2333 URL: https://issues.apache.org/jira/browse/MYFACES-2333 Project: MyFaces Core Issue Type: New Feature Components: Extension Feature Affects Versions: 1.2.8-SNAPSHOT Reporter: Werner Punz Additions to the shared part and to the ServletContextListener are done to allow the hot plugging of custom classloading into myfaces. This is done to allow the pluggability of scripting engines without having to add a custom classloader to our system. Classloaders are inherently problematic in server environments. Theoretically anything can be plugged in, but for now we use it only to allow the pluggability of a groovy classloader. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-2333) Necessary extension to allow custom classloading to be plugged into myfaces in a server compatible way
[ https://issues.apache.org/jira/browse/MYFACES-2333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Werner Punz resolved MYFACES-2333. -- Resolution: Fixed done but the code will be refactored in the long run as usual it is a first attempt Necessary extension to allow custom classloading to be plugged into myfaces in a server compatible way -- Key: MYFACES-2333 URL: https://issues.apache.org/jira/browse/MYFACES-2333 Project: MyFaces Core Issue Type: New Feature Components: Extension Feature Affects Versions: 1.2.8-SNAPSHOT Reporter: Werner Punz Assignee: Werner Punz Additions to the shared part and to the ServletContextListener are done to allow the hot plugging of custom classloading into myfaces. This is done to allow the pluggability of scripting engines without having to add a custom classloader to our system. Classloaders are inherently problematic in server environments. Theoretically anything can be plugged in, but for now we use it only to allow the pluggability of a groovy classloader. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
myfaces groovy bindings now checked in
Hello everyone I just checked in the current state of the myfaces groovy/scripting bindings. First of all the url is: https://svn.apache.org/repos/asf/myfaces/extensions/scripting/trunk also you need to check out the latest myfaces 1.2 trunk, since a plugin mechanism was added which allowed to enable this extension. If you run the included very rough so please do not hammer me it is a testing ground example, you can change the various jsf artefacts located under WEB-INF/groovy/... on the fly either with a request reload or with a regeneration of the component tree, depending on the artefact you can see the change instantly. Sort of like javarebel, but on scripting level. Sorry for the huge delay for posting it, one year late, but as many know my private situation I have become father a while ago, so my sparetime currently is limited. Werner
Re: myfaces groovy bindings now checked in
Werner, thank you very much for this. This is a huge deal for MyFaces! Sent from my iPhone On Aug 17, 2009, at 11:13 AM, Werner Punz werner.p...@gmail.com wrote: Hello everyone I just checked in the current state of the myfaces groovy/scripting bindings. First of all the url is: https://svn.apache.org/repos/asf/myfaces/extensions/scripting/trunk also you need to check out the latest myfaces 1.2 trunk, since a plugin mechanism was added which allowed to enable this extension. If you run the included very rough so please do not hammer me it is a testing ground example, you can change the various jsf artefacts located under WEB-INF/groovy/... on the fly either with a request reload or with a regeneration of the component tree, depending on the artefact you can see the change instantly. Sort of like javarebel, but on scripting level. Sorry for the huge delay for posting it, one year late, but as many know my private situation I have become father a while ago, so my sparetime currently is limited. Werner
[jira] Commented: (TOMAHAWK-1441) JSCookMenu over HTTPS in IE6
[ https://issues.apache.org/jira/browse/TOMAHAWK-1441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12744159#action_12744159 ] Pedro Busko commented on TOMAHAWK-1441: --- The menu simply does not appear. My enviroment is Microsoft IIS redirecting the HTTPS(port 443) connections to WebSphere Application Server. No extra configurations in the IIS besides the WAS plug-in. I don't know if the JSCookMenu component makes some connection that is forced not secure. I'm using the TOMAHWAK 1.1.9 nad did not change de JavaScript implementation. JSCookMenu over HTTPS in IE6 Key: TOMAHAWK-1441 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1441 Project: MyFaces Tomahawk Issue Type: Bug Components: JS Cook Menu Affects Versions: 1.1.9 Environment: IE 6 Reporter: Pedro Busko Priority: Blocker JSCookMenu in Tomahawk 1.1.9 does not work over HTTPS in IE6, even with the 2.0.4 JavaScript implementation of the JSCookMenu . The menu simply does not show. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TOBAGO-786) Page submit on window resize
[ https://issues.apache.org/jira/browse/TOBAGO-786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12744169#action_12744169 ] Bernd Bohmann commented on TOBAGO-786: -- Can you review the current impl, please. Page submit on window resize Key: TOBAGO-786 URL: https://issues.apache.org/jira/browse/TOBAGO-786 Project: MyFaces Tobago Issue Type: Improvement Components: Core Affects Versions: 1.0.22 Environment: All Reporter: Helmut Swaczinna Assignee: Bernd Bohmann Priority: Minor Fix For: 1.0.23, 1.1.0 Attachments: Tobago-786.diff When the browser window gets resized by the user the page should be (optionally) submited to use the PageState object to recalculate the page layout. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TOBAGO-787) The MessagesRenderer should consider the messages filter properties of UIMessages for calculating the height
The MessagesRenderer should consider the messages filter properties of UIMessages for calculating the height Key: TOBAGO-787 URL: https://issues.apache.org/jira/browse/TOBAGO-787 Project: MyFaces Tobago Issue Type: Improvement Affects Versions: 1.0.23 Reporter: Bernd Bohmann Assignee: Bernd Bohmann -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: myfaces groovy bindings now checked in
Its not quite there where I want it to be but it is a start. The issues are I want more than groovy in, but for now as far as I could see only groovy allows direct classloading. JRuby for instance only allows object loading or jsr 223. The same probably applies to jython. We probably can work around the object only limitation in the long run. But lets get the groovy stuff proper first :-) Werner Grant Smith schrieb: Werner, thank you very much for this. This is a huge deal for MyFaces! Sent from my iPhone On Aug 17, 2009, at 11:13 AM, Wernecr Punz werner.p...@gmail.com wrote: Hello everyone I just checked in the current state of the myfaces groovy/scripting bindings. First of all the url is: https://svn.apache.org/repos/asf/myfaces/extensions/scripting/trunk also you need to check out the latest myfaces 1.2 trunk, since a plugin mechanism was added which allowed to enable this extension. If you run the included very rough so please do not hammer me it is a testing ground example, you can change the various jsf artefacts located under WEB-INF/groovy/... on the fly either with a request reload or with a regeneration of the component tree, depending on the artefact you can see the change instantly. Sort of like javarebel, but on scripting level. Sorry for the huge delay for posting it, one year late, but as many know my private situation I have become father a while ago, so my sparetime currently is limited. Werner
Re: myfaces groovy bindings now checked in
Can't wait to finish my Bean Validation stuff and try the Groovy example. I think Grant is right and it is indeed a very good thing for MyFaces to have Goovy support. Thanks for making the time! /Jan-Kees 2009/8/17 Grant Smith work.gr...@gmail.com: Werner, thank you very much for this. This is a huge deal for MyFaces! Sent from my iPhone On Aug 17, 2009, at 11:13 AM, Werner Punz werner.p...@gmail.com wrote: Hello everyone I just checked in the current state of the myfaces groovy/scripting bindings. First of all the url is: https://svn.apache.org/repos/asf/myfaces/extensions/scripting/trunk also you need to check out the latest myfaces 1.2 trunk, since a plugin mechanism was added which allowed to enable this extension. If you run the included very rough so please do not hammer me it is a testing ground example, you can change the various jsf artefacts located under WEB-INF/groovy/... on the fly either with a request reload or with a regeneration of the component tree, depending on the artefact you can see the change instantly. Sort of like javarebel, but on scripting level. Sorry for the huge delay for posting it, one year late, but as many know my private situation I have become father a while ago, so my sparetime currently is limited. Werner
Re: myfaces groovy bindings now checked in
Jan-Kees van Andel schrieb: Can't wait to finish my Bean Validation stuff and try the Groovy example. I think Grant is right and it is indeed a very good thing for MyFaces to have Goovy support. Thanks for making the time! Thanks a lot as I said i am not fully there yet, the code needs some overhaul which I will do the next weeks. A lot of code will be dropped soon, because the original classloader stuff is not needed anymore. So if you look into the code, it still is somewhat dirty and rough around the edges, my bigger priority was to get the codebase in a working condition into the repo, and then move on from then. Wenrer
Re: myfaces groovy bindings now checked in
+1 thanks Werner! This is really à great thing! Sent from my iPod. On 17.08.2009, at 20:26, Grant Smith work.gr...@gmail.com wrote: Werner, thank you very much for this. This is a huge deal for MyFaces! Sent from my iPhone On Aug 17, 2009, at 11:13 AM, Werner Punz werner.p...@gmail.com wrote: Hello everyone I just checked in the current state of the myfaces groovy/scripting bindings. First of all the url is: https://svn.apache.org/repos/asf/myfaces/extensions/scripting/trunk also you need to check out the latest myfaces 1.2 trunk, since a plugin mechanism was added which allowed to enable this extension. If you run the included very rough so please do not hammer me it is a testing ground example, you can change the various jsf artefacts located under WEB-INF/groovy/... on the fly either with a request reload or with a regeneration of the component tree, depending on the artefact you can see the change instantly. Sort of like javarebel, but on scripting level. Sorry for the huge delay for posting it, one year late, but as many know my private situation I have become father a while ago, so my sparetime currently is limited. Werner
