[ https://issues.apache.org/jira/browse/ORCHESTRA-45?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12786813#action_12786813
]
Leonardo Uribe commented on ORCHESTRA-45:
-----------------------------------------
Actually, in orchestra we have in trunk 3 modules:
core
core12
core20
It follows the same strategy as tomahawk core12. In fact, there is no a full branch as in
myfaces core or trinidad, just a submodule that takes all code that does not change from its
previous version and add the files that changes and compiles everything.
In jsf 2.0 there are two points to take into account:
- TagHandler hierarchy changes
- New Wrappers.
The second is not critical but the first one is, so if you use orchestra12 with jsf 2.0, all
associated code related with ConverterTagHandler will not work.
Note also that for release any jar file we need at least one pom.xml file (we can't use maven
profiles to execute the same module multiple times without create multiple poms). Also, each
version has a different set of dependencies.
The good about the solution committed is that if you fix something in core not related to
ConverterTagHandler class or new wrappers, with just one commit it will be on core12 and core20.
The only drawback about this strategy is the information related to svn. Since you create
new files in core12 and core20, to look the full history of a file you have to look the file
on each module.
> Support for JSF 2.0
> -------------------
>
> Key: ORCHESTRA-45
> URL: https://issues.apache.org/jira/browse/ORCHESTRA-45
> Project: MyFaces Orchestra
> Issue Type: Improvement
> Components: FrameworkAdapter
> Affects Versions: 1.3.1
> Reporter: Martin Marinschek
> Assignee: Leonardo Uribe
> Fix For: 1.4
>
> Attachments: jsf20upgrade.patch
>
>
> Orchestra should support JSF 2.0. The supplied patch changes the decorators in Orchestra
to allow this, however, the patch is not backwards compatible with the 1.2/1.1 version (and
contrary to supporting both 1.1 and 1.2 in one version, this is not possible with 2.0 anymore,
as the interfaces have new methods which in turn have parameters/return types which are only
available in JSF 2.0). The question will be how we will be able to continue. I see two options:
> a) a branch, and two independent releases
> b) adding a common JSF 1.2 compatibility library, which would allow to a certain extent
to mimick basic JSF 2.0 infrastructure (it would not try to reimplement features from 2.0,
however)
> I will also post this question to the MyFaces mailing-list, and we will see how to proceed
from here.
> regards,
> Martin
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/ORCHESTRA-45?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12786455#action_12786455
]
Bernhard Huemer commented on ORCHESTRA-45:
------------------------------------------
Unfortunately I'm not really experienced regarding JSF 2.0, but are those decorators really
the only thing that you have to change in order to make Orchestra JSF 2.0 compatible? I'm
just wondering, because that means that there's only a set of like three or four classes that
demands the introduction of another branch? That looks like there's going to be a lot of redundant
work in the future then if both versions will be maintained, isn't it? Even though this issue
has already been marked as resolved, I'd hence like to propose a different solution (btw.
I couldn't manage to find the discussion thread on the MyFaces mailing list? - otherwise I
would have proposed it there).
Apparently the problem is that if we want to support both, JSF 1.x and JSF 2.0 at once, we'll
have to provide two different sets of decorators, one set that implements / extends the JSF
1.x API and one set that implements the JSF 2.0 API. The compiler can't differ between those
different versions and thus the whole project has to stick to a certain version. However,
to be more specific, a single compiler configuration can't differ between different versions,
multiple compiler configurations in fact can! Unfortunately Maven doesn't really support the
usage of multiple compiler configurations, but I've already managed to implement something
similar. Basically we would have to write a custom CompilerMojo that lets you configure the
compile classpath to use for a certain source folder. At runtime Orchestra would have to determine
the current JSF version (which is really easy to do) and depending on this version number
it would choose the set of decorators to use. For example, the project layout could as a
result of that look like the following:
- src\main\java - Common code for all JSF versions (even though it's called common, it compiles
against the JSF 2.0 API)
- src\main\jsf1x - JSF 1.x specific code (i.e. JSF 1.x specific decorators)
- src\main\jsf20 - JSF 2.0 specific code (i.e. JSF 2.0 specific decorators)
Basically it's as if we introduced three different modules, orchestra-common, orchestra-jsf1x
and orchestra-jsf20, but it's still just a single Maven module. Of course, this solutions
has got some drawbacks as well, as it will definitely confuse IDEs, i.e. you'll end up with
several error messages that the IDE complains about even though it actually compiles without
any errors at all.
Just let me know, what you think about it. :-)
> Support for JSF 2.0
> -------------------
>
> Key: ORCHESTRA-45
> URL: https://issues.apache.org/jira/browse/ORCHESTRA-45
> Project: MyFaces Orchestra
> Issue Type: Improvement
> Components: FrameworkAdapter
> Affects Versions: 1.3.1
> Reporter: Martin Marinschek
> Assignee: Leonardo Uribe
> Fix For: 1.4
>
> Attachments: jsf20upgrade.patch
>
>
> Orchestra should support JSF 2.0. The supplied patch changes the decorators in Orchestra
to allow this, however, the patch is not backwards compatible with the 1.2/1.1 version (and
contrary to supporting both 1.1 and 1.2 in one version, this is not possible with 2.0 anymore,
as the interfaces have new methods which in turn have parameters/return types which are only
available in JSF 2.0). The question will be how we will be able to continue. I see two options:
> a) a branch, and two independent releases
> b) adding a common JSF 1.2 compatibility library, which would allow to a certain extent
to mimick basic JSF 2.0 infrastructure (it would not try to reimplement features from 2.0,
however)
> I will also post this question to the MyFaces mailing-list, and we will see how to proceed
from here.
> regards,
> Martin
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
partialTriggers doesn't take a space separated list of Strings
--------------------------------------------------------------
Key: TRINIDAD-1654
URL: https://issues.apache.org/jira/browse/TRINIDAD-1654
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components, Facelets
Affects Versions: 1.2.12-core
Environment: Facelets 1.1.14, Trinidad 1.2.12, Glassfish v2.1
Reporter: Bart Kummel
When using Facelets, the partiaTriggers attribute doesn't accept any String value, it only
accepts an array of Strings. While this is fine in Java code, it should be possible to use
a space-separated list directly in a Facelets page definition, like this:
<tr:inputText partialTriggers="comp1 comp2"/>
However, the above example will give the following stack trace, even if only one component
is referenced (partialTriggers="comp1"):
java.lang.IllegalArgumentException: Cannot convert comp1 of type class java.lang.String to
class [Ljava.lang.String;
at com.sun.facelets.el.TagValueExpression.getValue(TagValueExpression.java:76)
at org.apache.myfaces.trinidad.bean.FacesBeanImpl.getProperty(FacesBeanImpl.java:68)
at org.apache.myfaces.trinidad.bean.util.ValueMap.get(ValueMap.java:66)
at org.apache.myfaces.trinidad.component.UIXComponentBase.decode(UIXComponentBase.java:693)
at org.apache.myfaces.trinidad.component.UIXComponentBase.processDecodes(UIXComponentBase.java:802)
at org.apache.myfaces.trinidad.component.UIXEditableValue.processDecodes(UIXEditableValue.java:236)
at org.apache.myfaces.trinidad.component.UIXComponentBase.decodeChildrenImpl(UIXComponentBase.java:988)
at org.apache.myfaces.trinidad.component.UIXComponentBase.decodeChildren(UIXComponentBase.java:974)
at org.apache.myfaces.trinidad.component.UIXComponentBase.processDecodes(UIXComponentBase.java:799)
at org.apache.myfaces.trinidad.component.UIXComponentBase.decodeChildrenImpl(UIXComponentBase.java:988)
at org.apache.myfaces.trinidad.component.UIXComponentBase.decodeChildren(UIXComponentBase.java:974)
at org.apache.myfaces.trinidad.component.UIXComponentBase.processDecodes(UIXComponentBase.java:799)
at org.apache.myfaces.trinidad.component.UIXComponentBase.decodeChildrenImpl(UIXComponentBase.java:988)
at org.apache.myfaces.trinidad.component.UIXComponentBase.decodeChildren(UIXComponentBase.java:974)
at org.apache.myfaces.trinidad.component.UIXForm.processDecodes(UIXForm.java:75)
at org.apache.myfaces.trinidad.component.UIXComponentBase.decodeChildrenImpl(UIXComponentBase.java:988)
at org.apache.myfaces.trinidad.component.UIXComponentBase.decodeChildren(UIXComponentBase.java:974)
at org.apache.myfaces.trinidad.component.UIXComponentBase.processDecodes(UIXComponentBase.java:799)
at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:705)
at javax.faces.component.UIViewRoot.access$001(UIViewRoot.java:62)
at javax.faces.component.UIViewRoot$1.process(UIViewRoot.java:121)
at javax.faces.component.UIViewRoot.process(UIViewRoot.java:260)
at javax.faces.component.UIViewRoot.processDecodes(UIViewRoot.java:117)
at org.apache.myfaces.lifecycle.ApplyRequestValuesExecutor.execute(ApplyRequestValuesExecutor.java:32)
at org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:103)
at org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:76)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:151)
at org.apache.catalina.core.ApplicationFilterChain.servletService(ApplicationFilterChain.java:427)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:333)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl._doFilterImpl(TrinidadFilterImpl.java:247)
at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl.doFilter(TrinidadFilterImpl.java:157)
at org.apache.myfaces.trinidad.webapp.TrinidadFilter.doFilter(TrinidadFilter.java:92)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:313)
at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:287)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:218)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:648)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:593)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:94)
at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:98)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:222)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:648)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:593)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:587)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1096)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:166)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:648)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:593)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:587)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1096)
at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:288)
at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.invokeAdapter(DefaultProcessorTask.java:647)
at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.doProcess(DefaultProcessorTask.java:579)
at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.process(DefaultProcessorTask.java:831)
at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.executeProcessorTask(DefaultReadTask.java:341)
at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:263)
at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:214)
at com.sun.enterprise.web.connector.grizzly.TaskBase.run(TaskBase.java:265)
at com.sun.enterprise.web.connector.grizzly.ssl.SSLWorkerThread.run(SSLWorkerThread.java:106)
Caused by: java.lang.IllegalArgumentException: Cannot convert comp1 of type class java.lang.String
to class [Ljava.lang.String;
at com.sun.el.lang.ELSupport.coerceToType(ELSupport.java:381)
at com.sun.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:209)
at com.sun.facelets.el.TagValueExpression.getValue(TagValueExpression.java:71)
... 60 more
Note that this issue is a duplicate of TRINIDAD-1417, but that one was not clear and Matthais
advised to create a new issue. Hope the description is more clear now.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/ORCHESTRA-45?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12786436#action_12786436
]
Leonardo Uribe commented on ORCHESTRA-45:
-----------------------------------------
Yes, it works with myfaces latest snapshot and with RI.
> Support for JSF 2.0
> -------------------
>
> Key: ORCHESTRA-45
> URL: https://issues.apache.org/jira/browse/ORCHESTRA-45
> Project: MyFaces Orchestra
> Issue Type: Improvement
> Components: FrameworkAdapter
> Affects Versions: 1.3.1
> Reporter: Martin Marinschek
> Assignee: Leonardo Uribe
> Fix For: 1.4
>
> Attachments: jsf20upgrade.patch
>
>
> Orchestra should support JSF 2.0. The supplied patch changes the decorators in Orchestra
to allow this, however, the patch is not backwards compatible with the 1.2/1.1 version (and
contrary to supporting both 1.1 and 1.2 in one version, this is not possible with 2.0 anymore,
as the interfaces have new methods which in turn have parameters/return types which are only
available in JSF 2.0). The question will be how we will be able to continue. I see two options:
> a) a branch, and two independent releases
> b) adding a common JSF 1.2 compatibility library, which would allow to a certain extent
to mimick basic JSF 2.0 infrastructure (it would not try to reimplement features from 2.0,
however)
> I will also post this question to the MyFaces mailing-list, and we will see how to proceed
from here.
> regards,
> Martin
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
myfaces 1.2. example doesn't run on Windoze...
----------------------------------------------
Key: EXTSCRIPT-27
URL: https://issues.apache.org/jira/browse/EXTSCRIPT-27
Project: MyFaces Extensions Scripting
Issue Type: Bug
Reporter: Matthias Weßendorf
Assignee: Werner Punz
2009-12-05 13:46:20.312::WARN: Error starting handlers
java.lang.ExceptionInInitializerError
at org.apache.myfaces.shared_impl.webapp.webxml.WebXml.init(WebXml.java:243)
at org.apache.myfaces.shared_impl.webapp.webxml.WebXml.getWebXml(WebXml.java:228)
at org.apache.myfaces.webapp.AbstractFacesInitializer.initFaces(AbstractFacesInitializer.java:74)
at org.apache.myfaces.webapp.StartupServletContextListener.contextInitialized(StartupServletContextListener.java:139)
at org.mortbay.jetty.handler.ContextHandler.startContext(ContextHandler.java:511)
at org.mortbay.jetty.servlet.Context.startContext(Context.java:135)
at org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1191)
at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:481)
at org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:434)
at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40)
at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:147)
at org.mortbay.jetty.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:120)
at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40)
at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:147)
at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40)
at org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:117)
at org.mortbay.jetty.Server.doStart(Server.java:210)
at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40)
at org.mortbay.jetty.plugin.Jetty6PluginServer.start(Jetty6PluginServer.java:134)
at org.mortbay.jetty.plugin.AbstractJettyMojo.startJetty(AbstractJettyMojo.java:332)
at org.mortbay.jetty.plugin.AbstractJettyMojo.execute(AbstractJettyMojo.java:277)
at org.mortbay.jetty.plugin.AbstractJettyRunMojo.execute(AbstractJettyRunMojo.java:195)
at org.mortbay.jetty.plugin.Jetty6RunMojo.execute(Jetty6RunMojo.java:183)
at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:453)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:513)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:483)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:331)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:292)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:301)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: java.lang.StringIndexOutOfBoundsException: String index out of range: 1
at java.lang.String.charAt(String.java:687)
at java.util.regex.Matcher.appendReplacement(Matcher.java:703)
at java.util.regex.Matcher.replaceAll(Matcher.java:813)
at java.lang.String.replaceAll(String.java:2190)
at org.apache.myfaces.scripting.api.BaseWeaver.loadScriptingClassFromName(BaseWeaver.java:159)
at org.apache.myfaces.scripting.core.CoreWeaver.loadScriptingClassFromName(CoreWeaver.java:85)
at org.apache.myfaces.scripting.servlet.CustomChainLoader.forName(CustomChainLoader.java:110)
at org.apache.myfaces.shared_impl.util.ClassUtils.classForName(ClassUtils.java:158)
at org.apache.myfaces.shared_impl.config.MyfacesConfig.<clinit>(MyfacesConfig.java:202)
... 41 more
2009-12-05 13:46:20.312::WARN: Nested in java.lang.ExceptionInInitializerError:
java.lang.StringIndexOutOfBoundsException: String index out of range: 1
at java.lang.String.charAt(String.java:687)
at java.util.regex.Matcher.appendReplacement(Matcher.java:703)
at java.util.regex.Matcher.replaceAll(Matcher.java:813)
at java.lang.String.replaceAll(String.java:2190)
at org.apache.myfaces.scripting.api.BaseWeaver.loadScriptingClassFromName(BaseWeaver.java:159)
at org.apache.myfaces.scripting.core.CoreWeaver.loadScriptingClassFromName(CoreWeaver.java:85)
at org.apache.myfaces.scripting.servlet.CustomChainLoader.forName(CustomChainLoader.java:110)
at org.apache.myfaces.shared_impl.util.ClassUtils.classForName(ClassUtils.java:158)
at org.apache.myfaces.shared_impl.config.MyfacesConfig.<clinit>(MyfacesConfig.java:202)
at org.apache.myfaces.shared_impl.webapp.webxml.WebXml.init(WebXml.java:243)
at org.apache.myfaces.shared_impl.webapp.webxml.WebXml.getWebXml(WebXml.java:228)
at org.apache.myfaces.webapp.AbstractFacesInitializer.initFaces(AbstractFacesInitializer.java:74)
at org.apache.myfaces.webapp.StartupServletContextListener.contextInitialized(StartupServletContextListener.java:139)
at org.mortbay.jetty.handler.ContextHandler.startContext(ContextHandler.java:511)
at org.mortbay.jetty.servlet.Context.startContext(Context.java:135)
at org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1191)
at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:481)
at org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:434)
at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40)
at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:147)
at org.mortbay.jetty.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:120)
at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40)
at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:147)
at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40)
at org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:117)
at org.mortbay.jetty.Server.doStart(Server.java:210)
at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40)
at org.mortbay.jetty.plugin.Jetty6PluginServer.start(Jetty6PluginServer.java:134)
at org.mortbay.jetty.plugin.AbstractJettyMojo.startJetty(AbstractJettyMojo.java:332)
at org.mortbay.jetty.plugin.AbstractJettyMojo.execute(AbstractJettyMojo.java:277)
at org.mortbay.jetty.plugin.AbstractJettyRunMojo.execute(AbstractJettyRunMojo.java:195)
at org.mortbay.jetty.plugin.Jetty6RunMojo.execute(Jetty6RunMojo.java:183)
at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:453)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:513)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:483)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:331)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:292)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:301)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/ORCHESTRA-45?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12786375#action_12786375
]
Matthias Weßendorf commented on ORCHESTRA-45:
---------------------------------------------
Leo,
does this work with current myfaces as well ?
I see you are (currently) only using RI 2.0 ......
> Support for JSF 2.0
> -------------------
>
> Key: ORCHESTRA-45
> URL: https://issues.apache.org/jira/browse/ORCHESTRA-45
> Project: MyFaces Orchestra
> Issue Type: Improvement
> Components: FrameworkAdapter
> Affects Versions: 1.3.1
> Reporter: Martin Marinschek
> Assignee: Leonardo Uribe
> Fix For: 1.4
>
> Attachments: jsf20upgrade.patch
>
>
> Orchestra should support JSF 2.0. The supplied patch changes the decorators in Orchestra
to allow this, however, the patch is not backwards compatible with the 1.2/1.1 version (and
contrary to supporting both 1.1 and 1.2 in one version, this is not possible with 2.0 anymore,
as the interfaces have new methods which in turn have parameters/return types which are only
available in JSF 2.0). The question will be how we will be able to continue. I see two options:
> a) a branch, and two independent releases
> b) adding a common JSF 1.2 compatibility library, which would allow to a certain extent
to mimick basic JSF 2.0 infrastructure (it would not try to reimplement features from 2.0,
however)
> I will also post this question to the MyFaces mailing-list, and we will see how to proceed
from here.
> regards,
> Martin
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/TRINIDAD-1642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12786373#action_12786373
]
Matthias Weßendorf commented on TRINIDAD-1642:
----------------------------------------------
B) sounds fine with me, but I see this ticket has already been solved ...
> Trinidad 2 - server side state saving does not work
> ---------------------------------------------------
>
> Key: TRINIDAD-1642
> URL: https://issues.apache.org/jira/browse/TRINIDAD-1642
> Project: MyFaces Trinidad
> Issue Type: Bug
> Reporter: Gabrielle Crawford
> Assignee: Gabrielle Crawford
> Fix For: 2.0.0-core
>
>
> Server side state saving is not working in Trinidad 2.0, instead of writing a token to
the client the full state is written to the client.
> In Trinidad we have
> * our own stateManager which wraps the RI's state manager.
> * our own responseStateManager which does not wrap the RI's state manager
> For server side state saving we delegate to the RI's state manager. In JSF 1.2 the RI's
stateManager handled saving the state on the session for server side state saving. So server
side state saving worked in Trinidad 1.2.
> In JSF 2.0 the StateManager no longer handles server side state saving, now the ResponseStateManager
handles server side state saving. Trinidad's CoreResponseStateManager just writes out whatever
state it was given, so it writes out the full state instead of writing out a token and saving
the state in the session.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
+1 On Fri, Dec 4, 2009 at 8:14 PM, Gabrielle Crawford <gabrielle.crawford@oracle.com> wrote: > Hi, > > For Trinidad 2 to fix server side state saving I'm planning to make > javax.faces.STATE_SAVING_METHOD = server configuration go through the > trinidad state cache. > > More detail is available here: > https://issues.apache.org/jira/browse/TRINIDAD-1642 > > If anyone objects to this please let me know. > > Thanks, > > Gabrielle > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
[ https://issues.apache.org/jira/browse/MYFACES-2396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leonardo Uribe updated MYFACES-2396:
------------------------------------
Resolution: Fixed
Fix Version/s: 2.0.0-alpha-2
Status: Resolved (was: Patch Available)
Thanks to Jakob Korherr for provide this patch
> @PreDestroy method of Bean in CustomScope not invoked
> -----------------------------------------------------
>
> Key: MYFACES-2396
> URL: https://issues.apache.org/jira/browse/MYFACES-2396
> Project: MyFaces Core
> Issue Type: Bug
> Components: JSR-314
> Reporter: Jakob Korherr
> Assignee: Leonardo Uribe
> Fix For: 2.0.0-alpha-2
>
> Attachments: myfaces-2396-final.patch, myfaces-2396-no-loop.patch, myfaces_2396_proposal.patch
>
>
> Testing the mojarra 2.0.1 sample "custom-bean-scope", MyFaces does NOT behave like Mojarra.
> The problem is that MyFaces does not propagate a PreDestroyCustomScopeEvent correctly.
The following code is from the mojarra sample and shows how the event is published:
> public void notifyDestroy() {
> // notify interested parties that this scope is being
> // destroyed
> ScopeContext scopeContext = new ScopeContext(SCOPE_NAME, this);
> application.publishEvent(FacesContext.getCurrentInstance(), PreDestroyCustomScopeEvent.class,
scopeContext);
> }
> However, the @PreDestroy method of the Bean, which is stored in the scope, is not invoked.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/ORCHESTRA-45?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leonardo Uribe resolved ORCHESTRA-45.
-------------------------------------
Resolution: Fixed
Fix Version/s: 1.4
Assignee: Leonardo Uribe
Module for jsf 2.0 created and added some tests.
> Support for JSF 2.0
> -------------------
>
> Key: ORCHESTRA-45
> URL: https://issues.apache.org/jira/browse/ORCHESTRA-45
> Project: MyFaces Orchestra
> Issue Type: Improvement
> Components: FrameworkAdapter
> Affects Versions: 1.3.1
> Reporter: Martin Marinschek
> Assignee: Leonardo Uribe
> Fix For: 1.4
>
> Attachments: jsf20upgrade.patch
>
>
> Orchestra should support JSF 2.0. The supplied patch changes the decorators in Orchestra
to allow this, however, the patch is not backwards compatible with the 1.2/1.1 version (and
contrary to supporting both 1.1 and 1.2 in one version, this is not possible with 2.0 anymore,
as the interfaces have new methods which in turn have parameters/return types which are only
available in JSF 2.0). The question will be how we will be able to continue. I see two options:
> a) a branch, and two independent releases
> b) adding a common JSF 1.2 compatibility library, which would allow to a certain extent
to mimick basic JSF 2.0 infrastructure (it would not try to reimplement features from 2.0,
however)
> I will also post this question to the MyFaces mailing-list, and we will see how to proceed
from here.
> regards,
> Martin
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/MYFACES-2450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leonardo Uribe resolved MYFACES-2450.
-------------------------------------
Resolution: Fixed
Fix Version/s: 2.0.0-alpha-2
> ViewHandler.deriveViewId must check is viewId really exists
> -----------------------------------------------------------
>
> Key: MYFACES-2450
> URL: https://issues.apache.org/jira/browse/MYFACES-2450
> Project: MyFaces Core
> Issue Type: Bug
> Components: JSR-314
> Affects Versions: 2.0.0-alpha
> Reporter: Leonardo Uribe
> Assignee: Leonardo Uribe
> Fix For: 2.0.0-alpha-2
>
>
> ViewHandler.deriveViewId must check is viewId really exists.
> Actually, we are using this method on RestoreViewExecutor to retrieve a valid vdl instance.
But it seems the intention of this method is be called from NavigationHandlerImpl.
> The effect of do not check is that if there is a commandButton or link with an action="someString"
and this string does not point to any page and someString.jsp/someString.xhtml does not exists
(derived from preemptive navigation), a 404 response happens, and the normal case has been
always execute a postback.
> Note that if we call it from RestoreViewExecutor and we check for file, TCK will fail
because some tests create dummy views. The solution is add a proper method in RestoreViewSupport
to deal with this fact (do the same as deriveViewId, but do not check).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
ViewHandler.deriveViewId must check is viewId really exists
-----------------------------------------------------------
Key: MYFACES-2450
URL: https://issues.apache.org/jira/browse/MYFACES-2450
Project: MyFaces Core
Issue Type: Bug
Components: JSR-314
Affects Versions: 2.0.0-alpha
Reporter: Leonardo Uribe
Assignee: Leonardo Uribe
ViewHandler.deriveViewId must check is viewId really exists.
Actually, we are using this method on RestoreViewExecutor to retrieve a valid vdl instance.
But it seems the intention of this method is be called from NavigationHandlerImpl.
The effect of do not check is that if there is a commandButton or link with an action="someString"
and this string does not point to any page and someString.jsp/someString.xhtml does not exists
(derived from preemptive navigation), a 404 response happens, and the normal case has been
always execute a postback.
Note that if we call it from RestoreViewExecutor and we check for file, TCK will fail because
some tests create dummy views. The solution is add a proper method in RestoreViewSupport to
deal with this fact (do the same as deriveViewId, but do not check).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/MYFACES-2434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leonardo Uribe reopened MYFACES-2434:
-------------------------------------
I have this bugs when orchestra for jsf 2.0 is used:
java.lang.UnsupportedOperationException: This request class is an empty placehol
der
at org.apache.myfaces.application._SystemEventServletRequest$1.invoke(_SystemEventServletRequest.java:55)
at $Proxy34.getServletPath(Unknown Source)
at javax.servlet.http.HttpServletRequestWrapper.getServletPath(HttpServletRequestWrapper.java:218)
at org.apache.myfaces.context.servlet.ServletExternalContextImpl.<init>(ServletExternalContextImpl.java:117)
at org.apache.myfaces.context.ExternalContextFactoryImpl.getExternalContext(ExternalContextFactoryImpl.java:61)
at org.apache.myfaces.context.FacesContextFactoryImpl.getFacesContext(FacesContextFactoryImpl.java:130)
at org.apache.myfaces.webapp.filter.TomahawkFacesContextFactory.getFacesContext(TomahawkFacesContextFactory.java:107)
at org.apache.myfaces.orchestra.lib.jsf.OrchestraFacesContextFactory.getFacesContext(OrchestraFacesContextFactory.java:70)
at org.apache.myfaces.orchestra.requestParameterProvider.jsf.RequestParameterFacesContextFactory.getFacesContext(RequestParameterFacesContextFactory.java:93)
at org.apache.myfaces.webapp.AbstractFacesInitializer.dispatchInitDestroyEvent(AbstractFacesInitializer.java:140)
at org.apache.myfaces.webapp.AbstractFacesInitializer.initFaces(AbstractFacesInitializer.java:109)
at org.apache.myfaces.webapp.StartupServletContextListener.contextInitialized(StartupServletContextListener.java:138)
at org.mortbay.jetty.handler.ContextHandler.startContext(ContextHandler.java:548)
GRAVE: An error occured while initializing MyFaces: This request class is an emp
ty placeholder
java.lang.UnsupportedOperationException: This request class is an empty placeholder
at org.apache.myfaces.application._SystemEventServletRequest$1.invoke(_SystemEventServletRequest.java:55)
at $Proxy34.getPathInfo(Unknown Source)
at javax.servlet.http.HttpServletRequestWrapper.getPathInfo(HttpServletRequestWrapper.java:133)
at org.apache.myfaces.context.servlet.ServletExternalContextImpl.<init>(ServletExternalContextImpl.java:118)
at org.apache.myfaces.context.ExternalContextFactoryImpl.getExternalContext(ExternalContextFactoryImpl.java:61)
at org.apache.myfaces.context.FacesContextFactoryImpl.getFacesContext(FacesContextFactoryImpl.java:130)
at org.apache.myfaces.webapp.filter.TomahawkFacesContextFactory.getFacesContext(TomahawkFacesContextFactory.java:107)
at org.apache.myfaces.orchestra.lib.jsf.OrchestraFacesContextFactory.getFacesContext(OrchestraFacesContextFactory.java:70)
at org.apache.myfaces.orchestra.requestParameterProvider.jsf.RequestParameterFacesContextFactory.getFacesContext(RequestParameterFacesContextFactory.jav
a:93)
at org.apache.myfaces.webapp.AbstractFacesInitializer.dispatchInitDestroyEvent(AbstractFacesInitializer.java:140)
at org.apache.myfaces.webapp.AbstractFacesInitializer.initFaces(AbstractFacesInitializer.java:109)
at org.apache.myfaces.webapp.StartupServletContextListener.contextInitialized(StartupServletContextListener.java:138)
at org.mortbay.jetty.handler.ContextHandler.startContext(ContextHandler.java:548)
at org.mortbay.jetty.servlet.Context.startContext(Context.java:136)
at org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1250)
2009-12-04 14:47:28,234 ERROR org.apache.myfaces.orchestra.lib.jsf.OrchestraFace
sContextFactory - Problem initialising RequestHandler
java.lang.UnsupportedOperationException: This request class is an empty placeholder
at org.apache.myfaces.application._SystemEventServletRequest$1.invoke(_SystemEventServletRequest.java:55)
at $Proxy34.getSession(Unknown Source)
at javax.servlet.http.HttpServletRequestWrapper.getSession(HttpServletRequestWrapper.java:227)
at org.apache.myfaces.context.servlet.SessionMap.getSession(SessionMap.java:79)
at org.apache.myfaces.context.servlet.SessionMap.getAttribute(SessionMap.java:49)
at org.apache.myfaces.util.AbstractAttributeMap.get(AbstractAttributeMap.java:94)
at org.apache.myfaces.orchestra.frameworkAdapter.jsf.JsfFrameworkAdapter.getSessionAttribute(JsfFrameworkAdapter.java:129)
at org.apache.myfaces.orchestra.conversation.ConversationManager.getInstance(ConversationManager.java:127)
at org.apache.myfaces.orchestra.lib.jsf.ContextLockRequestHandler.init(ContextLockRequestHandler.java:68)
at org.apache.myfaces.orchestra.lib.jsf.OrchestraFacesContextFactory$1.<init>(OrchestraFacesContextFactory.java:122)
at org.apache.myfaces.orchestra.lib.jsf.OrchestraFacesContextFactory.getFacesContext(OrchestraFacesContextFactory.java:103)
at org.apache.myfaces.orchestra.requestParameterProvider.jsf.RequestParameterFacesContextFactory.getFacesContext(RequestParameterFacesContextFactory.java:93)
at org.apache.myfaces.webapp.AbstractFacesInitializer.dispatchInitDestroyEvent(AbstractFacesInitializer.java:140)
at org.apache.myfaces.webapp.AbstractFacesInitializer.initFaces(AbstractFacesInitializer.java:109)
at org.apache.myfaces.webapp.StartupServletContextListener.contextInitialized(StartupServletContextListener.java:138)
at org.mortbay.jetty.handler.ContextHandler.startContext(ContextHandler.java:548)
at org.mortbay.jetty.servlet.Context.startContext(Context.java:136)
at org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1250)
java.lang.NullPointerException
at org.apache.myfaces.el.unified.resolver.ManagedBeanResolver.getValue(ManagedBeanResolver.java:183)
at javax.el.CompositeELResolver.getValue(CompositeELResolver.java:175)
at org.apache.myfaces.el.unified.resolver.FacesCompositeELResolver.getValue(FacesCompositeELResolver.java:140)
at org.apache.myfaces.el.VariableResolverImpl.resolveVariable(VariableResolverImpl.java:64)
at org.apache.myfaces.orchestra.viewController.jsf.ViewControllerVariableResolver.resolveVariable(ViewControllerVariableResolver.java:51)
at org.springframework.web.jsf.DelegatingVariableResolver.resolveOriginal(DelegatingVariableResolver.java:123)
at org.springframework.web.jsf.DelegatingVariableResolver.resolveVariable(DelegatingVariableResolver.java:105)
at org.apache.myfaces.el.convert.VariableResolverToELResolver.getValue(VariableResolverToELResolver.java:96)
at javax.el.CompositeELResolver.getValue(CompositeELResolver.java:175)
at org.apache.myfaces.el.unified.resolver.FacesCompositeELResolver.getValue(FacesCompositeELResolver.java:140)
at org.apache.myfaces.el.VariableResolverToApplicationELResolverAdapter.resolveVariable(VariableResolverToApplicationELResolverAdapter.java:45)
at org.apache.myfaces.orchestra.frameworkAdapter.jsf.JsfFrameworkAdapter.getBean(JsfFrameworkAdapter.java:177)
at org.apache.myfaces.orchestra.FactoryFinder.getConversationManagerFactory(FactoryFinder.java:66)
at org.apache.myfaces.orchestra.conversation.ConversationManager.getInstance(ConversationManager.java:144)
at org.apache.myfaces.orchestra.conversation.ConversationManager.getInstance(ConversationManager.java:99)
at org.apache.myfaces.orchestra.lib.jsf.ConversationManagerRequestHandler.init(ConversationManagerRequestHandler.java:43)
at org.apache.myfaces.orchestra.lib.jsf.OrchestraFacesContextFactory$1.(OrchestraFacesContextFactory.java:122)
at org.apache.myfaces.orchestra.lib.jsf.OrchestraFacesContextFactory.getFacesContext(OrchestraFacesContextFactory.java:103)
at org.apache.myfaces.orchestra.requestParameterProvider.jsf.RequestParameterFacesContextFactory.getFacesContext(RequestParameterFacesContextFactory.java:93)
at javax.faces.webapp.FacesServlet.prepareFacesContext(FacesServlet.java:500)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:189)
at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1166)
at org.apache.myfaces.examples.filter.RequestEncodingFilter.doFilter(RequestEncodingFilter.java:41)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)
at org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(ExtensionsFilter.java:341)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)
at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:388)
at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765)
at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:418)
at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230)
at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
at org.mortbay.jetty.Server.handle(Server.java:326)
at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:536)
at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:915)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:539)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:405)
at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:409)
at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)
In few words, the wrappers should use HttpServletXXX for create the proxy (because ServletExternalContextImpl
check for it) and contains some dummy methods to make it work. Note RI uses some classes that
return null, 0 or empty list/collection when initialization occur. For now, I'll commit only
the ones I need.
> dummy request/response classes for system event listeners will break with Servlet 3.0
> -------------------------------------------------------------------------------------
>
> Key: MYFACES-2434
> URL: https://issues.apache.org/jira/browse/MYFACES-2434
> Project: MyFaces Core
> Issue Type: Bug
> Components: JSR-314
> Affects Versions: 2.0.0-alpha
> Reporter: Michael Concini
> Assignee: Michael Concini
> Fix For: 2.0.0-alpha-2
>
>
> Currently the _SystemEventServletRequest and _SystemEventServletResponse classes implement
ServletRequest and ServletResponse directly. There are several new methods that must be
implemented in the servlet 3.0 updates of those interfaces.
> This can be resolved by changing them to extend ServletRequestWrapper and ServletResponseWrapper
instead of implementing directly.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/MYFACES-2434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leonardo Uribe resolved MYFACES-2434.
-------------------------------------
Resolution: Fixed
> dummy request/response classes for system event listeners will break with Servlet 3.0
> -------------------------------------------------------------------------------------
>
> Key: MYFACES-2434
> URL: https://issues.apache.org/jira/browse/MYFACES-2434
> Project: MyFaces Core
> Issue Type: Bug
> Components: JSR-314
> Affects Versions: 2.0.0-alpha
> Reporter: Michael Concini
> Assignee: Michael Concini
> Fix For: 2.0.0-alpha-2
>
>
> Currently the _SystemEventServletRequest and _SystemEventServletResponse classes implement
ServletRequest and ServletResponse directly. There are several new methods that must be
implemented in the servlet 3.0 updates of those interfaces.
> This can be resolved by changing them to extend ServletRequestWrapper and ServletResponseWrapper
instead of implementing directly.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
ManagedBeanResolver and ScopedAttributeResolver could be called before UIViewRoot is available
----------------------------------------------------------------------------------------------
Key: MYFACES-2449
URL: https://issues.apache.org/jira/browse/MYFACES-2449
Project: MyFaces Core
Issue Type: Task
Components: JSR-314
Affects Versions: 2.0.0-alpha
Reporter: Leonardo Uribe
This happens when orchestra for jsf 2.0 is used
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/MYFACES-2449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leonardo Uribe resolved MYFACES-2449.
-------------------------------------
Resolution: Fixed
Fix Version/s: 2.0.0-alpha-2
Assignee: Leonardo Uribe
> ManagedBeanResolver and ScopedAttributeResolver could be called before UIViewRoot is
available
> ----------------------------------------------------------------------------------------------
>
> Key: MYFACES-2449
> URL: https://issues.apache.org/jira/browse/MYFACES-2449
> Project: MyFaces Core
> Issue Type: Task
> Components: JSR-314
> Affects Versions: 2.0.0-alpha
> Reporter: Leonardo Uribe
> Assignee: Leonardo Uribe
> Fix For: 2.0.0-alpha-2
>
>
> This happens when orchestra for jsf 2.0 is used
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/MYFACES-2448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leonardo Uribe resolved MYFACES-2448.
-------------------------------------
Resolution: Fixed
Fix Version/s: 2.0.0-alpha-2
> Wrappers created in 1.2 version should wrap new methods added in 2.0
> --------------------------------------------------------------------
>
> Key: MYFACES-2448
> URL: https://issues.apache.org/jira/browse/MYFACES-2448
> Project: MyFaces Core
> Issue Type: Task
> Components: JSR-314
> Affects Versions: 2.0.0-alpha
> Reporter: Leonardo Uribe
> Assignee: Leonardo Uribe
> Fix For: 2.0.0-alpha-2
>
>
> Wrappers created in 1.2 version should wrap new methods added in 2.0
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Wrappers created in 1.2 version should wrap new methods added in 2.0
--------------------------------------------------------------------
Key: MYFACES-2448
URL: https://issues.apache.org/jira/browse/MYFACES-2448
Project: MyFaces Core
Issue Type: Task
Components: JSR-314
Affects Versions: 2.0.0-alpha
Reporter: Leonardo Uribe
Assignee: Leonardo Uribe
Wrappers created in 1.2 version should wrap new methods added in 2.0
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/MYFACES-2446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leonardo Uribe updated MYFACES-2446:
------------------------------------
Resolution: Fixed
Fix Version/s: 2.0.0-alpha-2
Assignee: Leonardo Uribe
Status: Resolved (was: Patch Available)
Thanks to Jakob Korherr for provide this patch
> ExceptionHandlerImpl is not correct
> -----------------------------------
>
> Key: MYFACES-2446
> URL: https://issues.apache.org/jira/browse/MYFACES-2446
> Project: MyFaces Core
> Issue Type: Task
> Components: JSR-314
> Affects Versions: 2.0.0-alpha-2
> Reporter: Jakob Korherr
> Assignee: Leonardo Uribe
> Fix For: 2.0.0-alpha-2
>
> Attachments: myfaces-2446.patch
>
>
> While performing a lot of ExceptionHandler related tests on mojarra, I found out that
MyFaces' ExceptionHandlerImpl behaves differently in some cases.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/MYFACES-2444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leonardo Uribe updated MYFACES-2444:
------------------------------------
Resolution: Fixed
Fix Version/s: 2.0.0-alpha-2
Assignee: Leonardo Uribe
Status: Resolved (was: Patch Available)
Thanks to Michael Kurz for provide this patch
> Implement new JSF 2 c:set features
> ----------------------------------
>
> Key: MYFACES-2444
> URL: https://issues.apache.org/jira/browse/MYFACES-2444
> Project: MyFaces Core
> Issue Type: Improvement
> Components: JSR-314
> Affects Versions: 2.0.0-alpha
> Reporter: Michael Kurz
> Assignee: Leonardo Uribe
> Fix For: 2.0.0-alpha-2
>
> Attachments: MYFACES-2444.patch
>
>
> I implemented new features for c:set as defined in the pdl doc. I am not sure what to
do with the value attribute. On the one hand it is not required but then in the two cases
stated it is needed again...
> Anyway added most of the new functionality I guess.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/MYFACES-2445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leonardo Uribe updated MYFACES-2445:
------------------------------------
Resolution: Fixed
Fix Version/s: 2.0.0-alpha-2
Assignee: Leonardo Uribe
Status: Resolved (was: Patch Available)
Thanks to Michael Kurz for provide this patch
> NPE on rendering outcome target links
> -------------------------------------
>
> Key: MYFACES-2445
> URL: https://issues.apache.org/jira/browse/MYFACES-2445
> Project: MyFaces Core
> Issue Type: Bug
> Components: JSR-314
> Affects Versions: 2.0.0-alpha
> Reporter: Michael Kurz
> Assignee: Leonardo Uribe
> Fix For: 2.0.0-alpha-2
>
> Attachments: MYFACES-2445.patch
>
>
> A NPE is thrown on rendering outcome target links that have no parameters set.
> Reason is that HtmlRendererUtils.getOutcomeTargetLinkHref only creates parameters map
if an actual parameter exists but this map is always accessed in further processing.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/TRINIDAD-1642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gabrielle Crawford resolved TRINIDAD-1642.
------------------------------------------
Resolution: Fixed
Fix Version/s: 2.0.0-core
> Trinidad 2 - server side state saving does not work
> ---------------------------------------------------
>
> Key: TRINIDAD-1642
> URL: https://issues.apache.org/jira/browse/TRINIDAD-1642
> Project: MyFaces Trinidad
> Issue Type: Bug
> Reporter: Gabrielle Crawford
> Assignee: Gabrielle Crawford
> Fix For: 2.0.0-core
>
>
> Server side state saving is not working in Trinidad 2.0, instead of writing a token to
the client the full state is written to the client.
> In Trinidad we have
> * our own stateManager which wraps the RI's state manager.
> * our own responseStateManager which does not wrap the RI's state manager
> For server side state saving we delegate to the RI's state manager. In JSF 1.2 the RI's
stateManager handled saving the state on the session for server side state saving. So server
side state saving worked in Trinidad 1.2.
> In JSF 2.0 the StateManager no longer handles server side state saving, now the ResponseStateManager
handles server side state saving. Trinidad's CoreResponseStateManager just writes out whatever
state it was given, so it writes out the full state instead of writing out a token and saving
the state in the session.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Hi, For Trinidad 2 to fix server side state saving I'm planning to make javax.faces.STATE_SAVING_METHOD = server configuration go through the trinidad state cache. More detail is available here: https://issues.apache.org/jira/browse/TRINIDAD-1642 If anyone objects to this please let me know. Thanks, Gabrielle
Hi,
Andy is at a conference, I can try to talk to him about this next week.
Thanks,
Gabrielle
Martin Koci wrote:
> Hi,
>
> regarding component.getAttributes() vs. bean.getProperty() performance:
>
> do you have info under which circumstances is that difference
> noticeable? I do some profiling on two apps: the first one is
> trinidad12/jsf12 based and the second is JSF2 based. In both cases I
> have same view but JSF2 based application uses UIComponent and newly
> developed renderers instead trinidad. For example: CoreInputText ->
> NewInputText and SimpleInputTextRenderer -> NewSimpleInputTextRenderer.
> Algorithm in new renderers is the same as in trinidad but uses
> getAttributes() directly.
>
> I didn't notice a performance regression but maybe I look at wrong
> places. Obviously it must cost something especially during render
> response. Test is done for very complex view, loading is simulated as
> 100 concurrently working users - but YourKitProfiler shows very similar
> results for render response phase. Memory profiling I didn't do yet.
>
>
> Thanks,
>
> Martin Kočí
>
> Gabrielle Crawford píše v Čt 03. 12. 2009 v 09:29 -0800:
>
>> Hi,
>>
>> Our implementation of facesBean in 1.2 already supported
>> partialStateSaving, and for JSF 2 it's now a partialStateHolder
>> https://issues.apache.org/jira/browse/TRINIDAD-1630
>>
>> One reason is FacesBean uses propertyKeys, which allow additional
>> information like capabilities.
>>
>> Beyond that Andy Schwartz had actually taken a look at this previously.
>> Here's what he found.
>>
>> In theory the ideal solution should be to remove FacesBean in favor of
>> the new standard APIs. However, in practice, there are two issues:
>>
>> 1. We need to maintain backwards compatibility.
>> 2. Trinidad's FacesBean solution is more efficient than the standard
>> solution.
>>
>> Note that the compatibility issues (#1) mainly impact component/renderer
>> authors (not application developers), yet is still an important issue
>> for us.
>>
>> Regarding efficiency (#2)... FacesBean has two benefits over the
>> standard solution. First, FacesBean supports indexed property keys,
>> allowing for very efficient property lookups. Second, the Trinidad
>> approach avoids overhead involved in the JSF's attribute-property
>> transparency mechanism. When using the RI's implementation of
>> UIComponent.getAttributes().get("foo"), the following steps are performed:
>>
>> * First, look up the attribute in the attribute map.
>> * If not found, use reflection to call the property getter (eg.
>> getFoo()) on the component instance.
>> * The getter then performs yet another lookup on the StateHelper.
>>
>> This approach allows property look ups to be more easily customized via
>> subclassing (ie. by overriding accessor methods). Trinidad sacrifices
>> this flexibility for performance. Attribute lookups are routed directly
>> to the FacesBean without invoking component accessor methods.
>>
>> Thanks,
>>
>> Gabrielle
>>
>>
>> Matthias Wessendorf wrote:
>>
>>> quick comment...
>>>
>>> one reason to keep that structure is that the components (trinidad) offer
>>> more APIs and behavior.
>>>
>>> Also, not sure if we really want to go with JSF 2.0's partial state saving.
>>> Looks like FacesBean has still some advantages.
>>>
>>> Gabrielle, can you provide some data here ?
>>>
>>> -Matthias
>>>
>>> On Thu, Dec 3, 2009 at 11:20 AM, Jan-Kees van Andel
>>> <jankeesvanandel@gmail.com> wrote:
>>>
>>>
>>>> Hey,
>>>>
>>>> I'm just asking this out of curiosity, so no offense intended. ;-)
>>>>
>>>> I see a lot of JSF 2.0 related activity in Trinidad and I was
>>>> wondering, why not leverage the JSF 2.0 code in MyFaces Core?
>>>> Are there (legacy) reasons to keep the UIX classes and not replace
>>>> them (maybe partially) with their JSF 2.0 equivalents?
>>>>
>>>> I can imagine that interoperability with other libraries increases
>>>> when Trinidad builds on (or extends) the JSF 2.0 API.
>>>>
>>>> Regards,
>>>> Jan-Kees
>>>>
>>>>
>>>>
>>>
>>>
>>>
>
>
>
[ https://issues.apache.org/jira/browse/TRINIDAD-1642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12786074#action_12786074
]
Gabrielle Crawford commented on TRINIDAD-1642:
----------------------------------------------
In JSF 1.2 things worked like this in trinidad
1] javax.faces.STATE_SAVING_METHOD = server, then you're using the JSF RI server side state
saving. This does not work correctly with multiple windows.
2] javax.faces.STATE_SAVING_METHOD = client and org.apache.myfaces.trinidad.CLIENT_STATE_METHOD
= all. This is true client side state saving.
3] javax.faces.STATE_SAVING_METHOD = client and org.apache.myfaces.trinidad.CLIENT_STATE_METHOD
= token. This uses trinidad's token/cache. Trinidad's token/cache mechanism handles multiple
windows correctly.
However in JSF 2 server side state saving (#1 above) no longer works. There are 2 solutions
A] Continue to delegate to the RI's stateManager but instead of using our coreResponseStateManager
use the the RI's ResponseStateManager.
B] Stop delegating to the RI's stateManager and make 1] and 3] use the trinidad token/cache
mechanism
My vote is for B since trinidad's token/cache does everything the RI's caching does, plus
it handles multiple windows correctly.
> Trinidad 2 - server side state saving does not work
> ---------------------------------------------------
>
> Key: TRINIDAD-1642
> URL: https://issues.apache.org/jira/browse/TRINIDAD-1642
> Project: MyFaces Trinidad
> Issue Type: Bug
> Reporter: Gabrielle Crawford
> Assignee: Gabrielle Crawford
>
> Server side state saving is not working in Trinidad 2.0, instead of writing a token to
the client the full state is written to the client.
> In Trinidad we have
> * our own stateManager which wraps the RI's state manager.
> * our own responseStateManager which does not wrap the RI's state manager
> For server side state saving we delegate to the RI's state manager. In JSF 1.2 the RI's
stateManager handled saving the state on the session for server side state saving. So server
side state saving worked in Trinidad 1.2.
> In JSF 2.0 the StateManager no longer handles server side state saving, now the ResponseStateManager
handles server side state saving. Trinidad's CoreResponseStateManager just writes out whatever
state it was given, so it writes out the full state instead of writing out a token and saving
the state in the session.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
PhaseListeners not invoked correctly
------------------------------------
Key: MYFACES-2447
URL: https://issues.apache.org/jira/browse/MYFACES-2447
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 2.0.0-alpha-2
Reporter: Jakob Korherr
See spec 12.3 PhaseListener for details.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/MYFACES-2446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jakob Korherr updated MYFACES-2446:
-----------------------------------
Status: Patch Available (was: Open)
> ExceptionHandlerImpl is not correct
> -----------------------------------
>
> Key: MYFACES-2446
> URL: https://issues.apache.org/jira/browse/MYFACES-2446
> Project: MyFaces Core
> Issue Type: Task
> Components: JSR-314
> Affects Versions: 2.0.0-alpha-2
> Reporter: Jakob Korherr
> Attachments: myfaces-2446.patch
>
>
> While performing a lot of ExceptionHandler related tests on mojarra, I found out that
MyFaces' ExceptionHandlerImpl behaves differently in some cases.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
ExceptionHandlerImpl is not correct
-----------------------------------
Key: MYFACES-2446
URL: https://issues.apache.org/jira/browse/MYFACES-2446
Project: MyFaces Core
Issue Type: Task
Components: JSR-314
Affects Versions: 2.0.0-alpha-2
Reporter: Jakob Korherr
While performing a lot of ExceptionHandler related tests on mojarra, I found out that MyFaces'
ExceptionHandlerImpl behaves differently in some cases.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
PopupActionListener has wrong popup reference if Component tree is rebuild before render view
---------------------------------------------------------------------------------------------
Key: TOBAGO-834
URL: https://issues.apache.org/jira/browse/TOBAGO-834
Project: MyFaces Tobago
Issue Type: Bug
Components: Core
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.
Check to introduce jQuery
-------------------------
Key: TOBAGO-833
URL: https://issues.apache.org/jira/browse/TOBAGO-833
Project: MyFaces Tobago
Issue Type: Task
Components: Core
Reporter: Udo Schnurpfeil
Assignee: Udo Schnurpfeil
We should use a JavaScript library in Tobago.
In Tobago 1.0.x Prototype is used, but for 1.5 we decided to replace it.
The AJAX-Stuff is implemented with Dojo in the moment.
Now I want to check, if it is a good idea to use jQuery instead.
I've use it the reimplementation of the menu.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Reimplementation of the menu
----------------------------
Key: TOBAGO-832
URL: https://issues.apache.org/jira/browse/TOBAGO-832
Project: MyFaces Tobago
Issue Type: Improvement
Components: Core
Reporter: Udo Schnurpfeil
Assignee: Udo Schnurpfeil
The menu in Tobago 1.0.x was rendered with JavaScript.
The main disadvantage is, that the menu items need a short time to be displayed on the browser,
the menu always occure later (like the tree) than other components. That is not nice.
An other disadvantage is, that the DOM (which is build by JavaScript) is not in the source
code. That it make a little more complicated to debug and develop it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/TRINIDAD-1171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12785944#action_12785944
]
Markus Krätzig commented on TRINIDAD-1171:
------------------------------------------
I guess the reason for the blocking is the following:
Taking off _doPprStartBlocking from the current thread via
a0._pprTimeoutFunc=a0.setTimeout("_doPprStartBlocking(window);",1);
in function _pprStartBlocking leads in function _submitPartialChange to the situation
where
_pprStartBlocking(window);
var a3=submitForm(a0,a1,a2,true);
_pprStopBlocking(window);
is not called in the order expected, instead, startBlocking is called after stopBlocking due
to the timeout. The only way to release the blocking is then via _pprConsumeClick, for which
the user
must click outside the body area.
The simplest way to fix this is to revert TRINIDAD-952. If the timeout should be kept in,
then
the threads must somehow be synchronized. But as far as I know there's not much provided by
javascript to do this.
I think fixing this issue should be prioritized, because it renders TRINIDAD pretty useless
on all IE versions.
> A failing client-side validator while using PPR causes a page hang with hourglass in
IE when clicking in a empty spot on the page
> ---------------------------------------------------------------------------------------------------------------------------------
>
> Key: TRINIDAD-1171
> URL: https://issues.apache.org/jira/browse/TRINIDAD-1171
> Project: MyFaces Trinidad
> Issue Type: Bug
> Components: Components
> Affects Versions: 1.0.7-core, 1.0.8-core, 1.0.9-core
> Environment: Windows IE6 and IE7
> Reporter: Mark van den Boomen
> Attachments: Trinidad-1.0.8_revert_TRINIDAD-952, TrinidadJira1171Validation.war
>
>
> Code to reproduce:
> <tr:form id="testValidationForm">
> <tr:inputDate value="#{test.myDate}" id="myDate" partialTriggers="validate">
> <tr:convertDateTime pattern="dd-MM-yyyy" />
> </tr:inputDate>
> <tr:commandButton text="Validate" partialSubmit="true" id="validate" />
> </tr:form>
> Steps to reproduce:
> 1. fill in something in the date field so the (date) validation will fail (eg. "hello")
> 2. press "Validate"
> 3. Now click on a spot on the page (but within the body area)
> Now the hourglass shows in IE. The only way to get rid of it is to click outside the
body of the page of on the toolbar of IE.
> I traced the problem back to bug TRINIDAD-952 whose fix is causing the problem, after
reverting the change everything works ok in 1.0.8 .
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/TRINIDAD-1171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Markus Krätzig updated TRINIDAD-1171:
-------------------------------------
Status: Patch Available (was: Reopened)
> A failing client-side validator while using PPR causes a page hang with hourglass in
IE when clicking in a empty spot on the page
> ---------------------------------------------------------------------------------------------------------------------------------
>
> Key: TRINIDAD-1171
> URL: https://issues.apache.org/jira/browse/TRINIDAD-1171
> Project: MyFaces Trinidad
> Issue Type: Bug
> Components: Components
> Affects Versions: 1.0.7-core, 1.0.8-core, 1.0.9-core
> Environment: Windows IE6 and IE7
> Reporter: Mark van den Boomen
> Attachments: Trinidad-1.0.8_revert_TRINIDAD-952, TrinidadJira1171Validation.war
>
>
> Code to reproduce:
> <tr:form id="testValidationForm">
> <tr:inputDate value="#{test.myDate}" id="myDate" partialTriggers="validate">
> <tr:convertDateTime pattern="dd-MM-yyyy" />
> </tr:inputDate>
> <tr:commandButton text="Validate" partialSubmit="true" id="validate" />
> </tr:form>
> Steps to reproduce:
> 1. fill in something in the date field so the (date) validation will fail (eg. "hello")
> 2. press "Validate"
> 3. Now click on a spot on the page (but within the body area)
> Now the hourglass shows in IE. The only way to get rid of it is to click outside the
body of the page of on the toolbar of IE.
> I traced the problem back to bug TRINIDAD-952 whose fix is causing the problem, after
reverting the change everything works ok in 1.0.8 .
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
see my other reply, I noticed by your email address, that I already replied to you earlier ;-) On Fri, Dec 4, 2009 at 10:41 AM, Ivan <xhhsld@gmail.com> wrote: > Hi, > Acutally, I have asked it in the MyFaces dev list. For Geronimo 3.0 is > running in the OSGI runtime, which means each jar file should be a bundle > first. And currently, the servlet API is updated to version 3.0.0, while in > the manifest of MyFaces 2.0, it has a constraint like : > javax.servlet;version="[2.5.0, 3.0.0)", so the MyFaces bundles would fail to > start. > > > 2009/12/4 Matthias Wessendorf <matzew@apache.org> >> >> Hey Ivan, >> >> can you follow up on the dev@myfaces list on that ? >> >> thanks! >> Matthias >> >> On Fri, Dec 4, 2009 at 2:18 AM, Ivan <xhhsld@gmail.com> wrote: >> > I am afraid that MyFaces 2.0 may not work in the Geronimo 3.0 now, for >> > currently it does not accept Servlet 3.0 API, it seems that I could not >> > start the MyFaces bundle in the OSGI environment. :-( >> > >> > 2009/12/3 Matthias Wessendorf <matzew@apache.org> >> >> >> >> Hi guys, >> >> >> >> on the road map for the Web Profile stuff [1], I saw an (kinda) >> >> incorrect status of the MyFaces 2.0 stuff for JSF 2.0 >> >> (Status of JEE6 Activity). >> >> >> >> Apache MyFaces is activly working on a release. As a matter of fact, >> >> there is a first alpha (TCK not passed) release out, >> >> see [2] for the download details. >> >> >> >> HTH, >> >> Matthias >> >> >> >> [1] http://cwiki.apache.org/GMOxDEV/road-map-for-jee6-web-profile.html >> >> [2] http://myfaces.apache.org/download.html >> >> >> >> -- >> >> Matthias Wessendorf >> >> >> >> blog: http://matthiaswessendorf.wordpress.com/ >> >> sessions: http://www.slideshare.net/mwessendorf >> >> twitter: http://twitter.com/mwessendorf >> > >> > >> > >> > -- >> > Ivan >> > >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf > > > > -- > Ivan > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Hey Ivan, I think that Michael is working on some Servlet 3.0 stuff, or started looking at it. See http://markmail.org/message/ks5hf4j6jwcpc5kb -M On Thu, Nov 26, 2009 at 3:17 PM, Ivan <xhhsld@gmail.com> wrote: > Hi, is it possible to update the accepted servlet spec version to 3.0.0 in > the configurations of maven-bundle-plugin? > Thanks ! > > 2009/11/26 Werner Punz <werner.punz@gmail.com> >> >> +1 >> >> Leonardo Uribe schrieb: >>> >>> Hi, >>> >>> I was running the needed tasks to get the 2.0.0-alpha release of Apache >>> MyFaces core out. >>> >>> Please note that this vote concerns all of the following parts: >>> 1. Maven artifact group "org.apache.myfaces.shared" v4.0.1-alpha [1] >>> 2. Maven artifact group "org.apache.myfaces.test" v1.0.0-alpha [1] >>> 3. Maven artifact group "org.apache.myfaces.core" v2.0.0-alpha [1] >>> >>> The artifacts are deployed to my private Apache account ([1] and [3] >>> for binary and source packages). >>> >>> The release notes could be found at [4]. >>> >>> Also the clirr test does not show binary incompatibilities with >>> myfaces-api. >>> >>> Please take a look at the "2.0.0-alpha" artifacts and vote! >>> >>> Please note: This vote is "majority approval" with a minimum of three >>> +1 votes (see [3]). >>> >>> ------------------------------------------------ >>> [ ] +1 for community members who have reviewed the bits >>> [ ] +0 >>> [ ] -1 for fatal flaws that should cause these bits not to be released, >>> and why.............. >>> ------------------------------------------------ >>> >>> Thanks, >>> Leonardo Uribe >>> >>> [1] http://people.apache.org/~lu4242/myfaces200alpha >>> [2] http://www.apache.org/foundation/voting.html#ReleaseVotes >>> [3] http://people.apache.org/~lu4242/myfaces200alphabinsrc >>> [4] >>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600&styleName=Html&version=12313389 >>> >> > > > > -- > Ivan > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Hi,
Acutally, I have asked it in the MyFaces dev list. For Geronimo 3.0 is
running in the OSGI runtime, which means each jar file should be a bundle
first. And currently, the servlet API is updated to version 3.0.0, while in
the manifest of MyFaces 2.0, it has a constraint like :
javax.servlet;version="[2.5.0, 3.0.0)", so the MyFaces bundles would fail to
start.
2009/12/4 Matthias Wessendorf <matzew@apache.org>
> Hey Ivan,
>
> can you follow up on the dev@myfaces list on that ?
>
> thanks!
> Matthias
>
> On Fri, Dec 4, 2009 at 2:18 AM, Ivan <xhhsld@gmail.com> wrote:
> > I am afraid that MyFaces 2.0 may not work in the Geronimo 3.0 now, for
> > currently it does not accept Servlet 3.0 API, it seems that I could not
> > start the MyFaces bundle in the OSGI environment. :-(
> >
> > 2009/12/3 Matthias Wessendorf <matzew@apache.org>
> >>
> >> Hi guys,
> >>
> >> on the road map for the Web Profile stuff [1], I saw an (kinda)
> >> incorrect status of the MyFaces 2.0 stuff for JSF 2.0
> >> (Status of JEE6 Activity).
> >>
> >> Apache MyFaces is activly working on a release. As a matter of fact,
> >> there is a first alpha (TCK not passed) release out,
> >> see [2] for the download details.
> >>
> >> HTH,
> >> Matthias
> >>
> >> [1] http://cwiki.apache.org/GMOxDEV/road-map-for-jee6-web-profile.html
> >> [2] http://myfaces.apache.org/download.html
> >>
> >> --
> >> Matthias Wessendorf
> >>
> >> blog: http://matthiaswessendorf.wordpress.com/
> >> sessions: http://www.slideshare.net/mwessendorf
> >> twitter: http://twitter.com/mwessendorf
> >
> >
> >
> > --
> > Ivan
> >
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
>
--
Ivan
[ https://issues.apache.org/jira/browse/TRINIDAD-1648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12785819#action_12785819
]
Matthias Weßendorf commented on TRINIDAD-1648:
----------------------------------------------
entire IllegalStateException stack trace:
WARNING: The id "sp11" is used more than once.
java.lang.IllegalStateException: Parent was not null, but this component not related
at javax.faces.component.UIComponentBase.eraseParent(UIComponentBase.java:520)
at javax.faces.component.UIComponentBase.access$400(UIComponentBase.java:104)
at javax.faces.component.UIComponentBase$ChildrenList.add(UIComponentBase.java:2437)
at javax.faces.component.UIComponentBase$ChildrenList.add(UIComponentBase.java:2411)
at javax.faces.component.UIViewRoot.addComponentResource(UIViewRoot.java:531)
at com.sun.faces.renderkit.html_basic.ScriptStyleBaseRenderer.processEvent(ScriptStyleBaseRenderer.java:99)
at javax.faces.component.UIComponent$ComponentSystemEventListenerAdapter.processEvent(UIComponent.java:2342)
at javax.faces.event.SystemEvent.processListener(SystemEvent.java:102)
at com.sun.faces.application.ApplicationImpl.processListeners(ApplicationImpl.java:1993)
at com.sun.faces.application.ApplicationImpl.invokeComponentListenersFor(ApplicationImpl.java:1941)
at com.sun.faces.application.ApplicationImpl.publishEvent(ApplicationImpl.java:285)
at com.sun.faces.application.ApplicationImpl.publishEvent(ApplicationImpl.java:243)
at javax.faces.component.UIComponentBase.publishAfterViewEvents(UIComponentBase.java:2005)
at javax.faces.component.UIComponentBase.doPostAddProcessing(UIComponentBase.java:1691)
at javax.faces.component.UIComponentBase.setParent(UIComponentBase.java:403)
at org.apache.myfaces.trinidad.component.ChildArrayList.add(ChildArrayList.java:61)
at org.apache.myfaces.trinidad.component.ChildArrayList.add(ChildArrayList.java:69)
at org.apache.myfaces.trinidad.component.ChildArrayList.add(ChildArrayList.java:33)
at com.sun.faces.facelets.tag.jsf.ComponentSupport.addComponent(ComponentSupport.java:346)
at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:220)
at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:114)
at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:91)
at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:120)
at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:204)
at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:114)
at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:91)
at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:120)
at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:204)
at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:114)
at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:91)
at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:120)
at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:204)
at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:114)
at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:91)
at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:120)
at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:204)
at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:114)
at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:91)
at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:120)
at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:204)
at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:114)
at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:91)
at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:120)
at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:204)
at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:114)
at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:120)
at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:204)
at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:114)
at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:120)
at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:204)
at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:114)
at com.sun.faces.facelets.tag.jsf.core.ViewHandler.apply(ViewHandler.java:149)
at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:91)
at com.sun.faces.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:86)
at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:91)
at com.sun.faces.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:75)
at com.sun.faces.facelets.impl.DefaultFacelet.apply(DefaultFacelet.java:145)
at com.sun.faces.application.view.FaceletViewHandlingStrategy.buildView(FaceletViewHandlingStrategy.java:715)
at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:106)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:311)
at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:502)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)
at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl._doFilterImpl(TrinidadFilterImpl.java:247)
at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl.doFilter(TrinidadFilterImpl.java:157)
at org.apache.myfaces.trinidad.webapp.TrinidadFilter.doFilter(TrinidadFilter.java:92)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1148)
at org.apache.myfaces.trinidaddemo.webapp.RedirectFilter.doFilter(RedirectFilter.java:97)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1148)
at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:387)
at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765)
at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:417)
at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230)
at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
at org.mortbay.jetty.Server.handle(Server.java:324)
at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:535)
at org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:880)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:747)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:218)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:409)
at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:520)
Dec 4, 2009 9:04:34 AM org.apache.myfaces.trinidadinternal.renderkit.core.CoreRenderKit createResponseWriter
SEVERE: No RenderingContext has been created.
> IllegalStateException in UIComponentBase when trying to add a resource (outputScript)
to the body target...
> -----------------------------------------------------------------------------------------------------------
>
> Key: TRINIDAD-1648
> URL: https://issues.apache.org/jira/browse/TRINIDAD-1648
> Project: MyFaces Trinidad
> Issue Type: New Feature
> Components: Components
> Affects Versions: 2.0.0-core
> Environment: Running Trinidad 2.0.x; with Facelets; no Partial State Saving and
using JSF Ajax request rather than the Trinidad PPR mechanism
> Reporter: Pavitra Subramaniam
> Attachments: IllegalStateException-II.patch, IllegalStateException.patch
>
>
> 1. I have a simple usecase where I have changed the Trinidad PPR code to use the jsf.ajax.
The client postback works ok and the command is processed on the server properly. almost...
> 2. During render response phase though, an <h:outputScript> tag present in the
page, gets re-targeted to be under the <body> tag and this causes an IllegalStateException
in the following method in UICOmponentBase.java.
> 3. It appears that the JSF RI, throws an ISE when the parent does not contain a child
either in its child list or the facets.
> * <p>If the specified {@link UIComponent} has a non-null parent,
> * remove it as a child or facet (as appropriate) of that parent.
> * As a result, the <code>parent</code> property will always be
> * <code>null</code> when this method returns.</p>
> *
> private static void eraseParent(UIComponent component)
> 4. To reproduce the problem ,
> a. download the patch provided.
> b. Run the ajaxPPRDemos.jspx. Notice the page comes up fine. also notice the <h:outputScript>
used.
> c. Click on the 'partial Submit' button. This is wired to use the JSF Ajax mechanism.
On the server notice the ISE as mentioned above.
> 5. from debugging it appears to be a weird bug in the RI implementation.
> a. Before adding the component (in this case the h:outputScript) to the current parent,
it does doPostAddProcessing() which publishes a PostAddToViewEvent. It calls the listener
registered for the SystemEvent (as one is available for the source component, ComponentSystemEventListenerAdapter).
> b. The event listener gets called, which eventually calls the ScriptStyleBaseRenderer,
which determines that the component actually needs to be added to the facets in the body and
then adds it. It's all fine until here.
> c. But when the component is being added to the facet, it's also erased from its current
parent. When it can't find the component in the current parent it throws an ISE. But we got
here in the first place because we were trying to add it to the parent. Anyways, the ISE in
UIComponentBase.eraseParent() seems like a bug to me.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
On Thu, Dec 3, 2009 at 6:46 PM, Matthias Wessendorf <matzew@apache.org> wrote:
> lemme put that into our "nice" MoinMoin wiki.
> we can add stuff in the future there as well.
here:
http://wiki.apache.org/myfaces/Trinidad_FacesBean_and_PartialStateSaving
feel free to add numbers on performance etc
>
> -M
>
> On Thu, Dec 3, 2009 at 6:29 PM, Gabrielle Crawford
> <gabrielle.crawford@oracle.com> wrote:
>> Hi,
>>
>> Our implementation of facesBean in 1.2 already supported partialStateSaving,
>> and for JSF 2 it's now a partialStateHolder
>> https://issues.apache.org/jira/browse/TRINIDAD-1630
>>
>> One reason is FacesBean uses propertyKeys, which allow additional
>> information like capabilities.
>>
>> Beyond that Andy Schwartz had actually taken a look at this previously.
>> Here's what he found.
>>
>> In theory the ideal solution should be to remove FacesBean in favor of the
>> new standard APIs. However, in practice, there are two issues:
>>
>> 1. We need to maintain backwards compatibility.
>> 2. Trinidad's FacesBean solution is more efficient than the standard
>> solution.
>>
>> Note that the compatibility issues (#1) mainly impact component/renderer
>> authors (not application developers), yet is still an important issue for
>> us.
>>
>> Regarding efficiency (#2)... FacesBean has two benefits over the standard
>> solution. First, FacesBean supports indexed property keys, allowing for very
>> efficient property lookups. Second, the Trinidad approach avoids overhead
>> involved in the JSF's attribute-property transparency mechanism. When using
>> the RI's implementation of UIComponent.getAttributes().get("foo"), the
>> following steps are performed:
>>
>> * First, look up the attribute in the attribute map.
>> * If not found, use reflection to call the property getter (eg. getFoo())
>> on the component instance.
>> * The getter then performs yet another lookup on the StateHelper.
>>
>> This approach allows property look ups to be more easily customized via
>> subclassing (ie. by overriding accessor methods). Trinidad sacrifices this
>> flexibility for performance. Attribute lookups are routed directly to the
>> FacesBean without invoking component accessor methods.
>>
>> Thanks,
>>
>> Gabrielle
>>
>>
>> Matthias Wessendorf wrote:
>>>
>>> quick comment...
>>>
>>> one reason to keep that structure is that the components (trinidad) offer
>>> more APIs and behavior.
>>>
>>> Also, not sure if we really want to go with JSF 2.0's partial state
>>> saving.
>>> Looks like FacesBean has still some advantages.
>>>
>>> Gabrielle, can you provide some data here ?
>>>
>>> -Matthias
>>>
>>> On Thu, Dec 3, 2009 at 11:20 AM, Jan-Kees van Andel
>>> <jankeesvanandel@gmail.com> wrote:
>>>
>>>>
>>>> Hey,
>>>>
>>>> I'm just asking this out of curiosity, so no offense intended. ;-)
>>>>
>>>> I see a lot of JSF 2.0 related activity in Trinidad and I was
>>>> wondering, why not leverage the JSF 2.0 code in MyFaces Core?
>>>> Are there (legacy) reasons to keep the UIX classes and not replace
>>>> them (maybe partially) with their JSF 2.0 equivalents?
>>>>
>>>> I can imagine that interoperability with other libraries increases
>>>> when Trinidad builds on (or extends) the JSF 2.0 API.
>>>>
>>>> Regards,
>>>> Jan-Kees
>>>>
>>>>
>>>
>>>
>>>
>>>
>>
>
>
>
> --
> 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
[ https://issues.apache.org/jira/browse/MYFACES-2396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jakob Korherr updated MYFACES-2396:
-----------------------------------
Status: Patch Available (was: Reopened)
> @PreDestroy method of Bean in CustomScope not invoked
> -----------------------------------------------------
>
> Key: MYFACES-2396
> URL: https://issues.apache.org/jira/browse/MYFACES-2396
> Project: MyFaces Core
> Issue Type: Bug
> Components: JSR-314
> Reporter: Jakob Korherr
> Assignee: Leonardo Uribe
> Attachments: myfaces-2396-final.patch, myfaces-2396-no-loop.patch, myfaces_2396_proposal.patch
>
>
> Testing the mojarra 2.0.1 sample "custom-bean-scope", MyFaces does NOT behave like Mojarra.
> The problem is that MyFaces does not propagate a PreDestroyCustomScopeEvent correctly.
The following code is from the mojarra sample and shows how the event is published:
> public void notifyDestroy() {
> // notify interested parties that this scope is being
> // destroyed
> ScopeContext scopeContext = new ScopeContext(SCOPE_NAME, this);
> application.publishEvent(FacesContext.getCurrentInstance(), PreDestroyCustomScopeEvent.class,
scopeContext);
> }
> However, the @PreDestroy method of the Bean, which is stored in the scope, is not invoked.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/ORCHESTRA-47?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leonardo Uribe resolved ORCHESTRA-47.
-------------------------------------
Resolution: Fixed
Fix Version/s: 1.4
Assignee: Leonardo Uribe
> Merge orchestra core15 branch into core, since orchestra will be JDK 1.5 compatible
> -----------------------------------------------------------------------------------
>
> Key: ORCHESTRA-47
> URL: https://issues.apache.org/jira/browse/ORCHESTRA-47
> Project: MyFaces Orchestra
> Issue Type: Task
> Reporter: Leonardo Uribe
> Assignee: Leonardo Uribe
> Fix For: 1.4
>
>
> Merge orchestra core15 branch into core, since orchestra will be JDK 1.5 compatible,
as discussed on dev list
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.