[jira] Commented: (EXTCDI-130) InstanceProducer not serializable
[ https://issues.apache.org/jira/browse/EXTCDI-130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12993393#comment-12993393 ] Matthias Weßendorf commented on EXTCDI-130: --- Ah - ok one more bug in that direction. Do you have a Weld bug number? Would be nice to link to it, from here InstanceProducer not serializable - Key: EXTCDI-130 URL: https://issues.apache.org/jira/browse/EXTCDI-130 Project: MyFaces CODI Issue Type: Bug Reporter: Matthias Weßendorf Deploying a WAR file, which contains CoDI 0.9.2 to Glassfish 3.1 (RC2) I am getting a NotSerializableException -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Revision numbers in MANIFEST.MF file (was: Re: svn commit: r1069504 - in /myfaces/trinidad/trunk: trinidad-api/pom.xml trinidad-impl/pom.xml)
Hi, i agree to Bernd, the revision number for a release is not needed, but what is the Problem having this few more lines in any manifest? I would prefer having this info packaged. Regards, Volker 2011/2/10 Bernd Bohmann bernd.bohm...@googlemail.com: Hello Matthias, For a release the revision number is not needed. For a snapshot it might be helpful if someone reports a bug and it's not clear with revision was the base for the snapshot. Regards Bernd Am 10.02.2011 19:23 schrieb Matthias Wessendorf mat...@apache.org: Having the actual revision number inside of the manifest.mf file is nice. However, not sure if that is really needed for every build, therefore I commented it out. Perhaps this should be done only in the release profile ? What do you think ? -Matthias On Thu, Feb 10, 2011 at 7:05 PM, mat...@apache.org wrote: Author: matzew Date: Thu Feb 10 18:05:24 2011 New Revision: 1069504 URL: http://svn.apache.org/viewvc?rev=1069504view=rev Log: disabling the svn revision number plugin - should it be done only on release profile??? Modified: myfaces/trinidad/trunk/trinidad-api/pom.xml myfaces/trinidad/trunk/trinidad-impl/pom.xml Modified: myfaces/trinidad/trunk/trinidad-api/pom.xml URL: http://svn.apache.org/viewvc/myfaces/trinidad/trunk/trinidad-api/pom.xml?rev=1069504r1=1069503r2=1069504view=diff == --- myfaces/trinidad/trunk/trinidad-api/pom.xml (original) +++ myfaces/trinidad/trunk/trinidad-api/pom.xml Thu Feb 10 18:05:24 2011 @@ -172,7 +172,8 @@ !-- To make the current revision number, we use the buildnumber-maven-plugin. -- - plugin + !-- Perhaps this should be only enabled on release profile ? -- + !--plugin groupIdorg.codehaus.mojo/groupId artifactIdbuildnumber-maven-plugin/artifactId version1.0-beta-4/version @@ -190,7 +191,7 @@ getRevisionOnlyOncetrue/getRevisionOnlyOnce buildNumberPropertyNamescm.revision/buildNumberPropertyName /configuration - /plugin + /plugin-- plugin groupIdorg.apache.maven.plugins/groupId Modified: myfaces/trinidad/trunk/trinidad-impl/pom.xml URL: http://svn.apache.org/viewvc/myfaces/trinidad/trunk/trinidad-impl/pom.xml?rev=1069504r1=1069503r2=1069504view=diff == --- myfaces/trinidad/trunk/trinidad-impl/pom.xml (original) +++ myfaces/trinidad/trunk/trinidad-impl/pom.xml Thu Feb 10 18:05:24 2011 @@ -211,7 +211,8 @@ !-- To make the current revision number, we use the buildnumber-maven-plugin. -- - plugin + !-- Perhaps this should be only enabled on release profile ? -- + !--plugin groupIdorg.codehaus.mojo/groupId artifactIdbuildnumber-maven-plugin/artifactId version1.0-beta-4/version @@ -229,7 +230,7 @@ getRevisionOnlyOncetrue/getRevisionOnlyOnce buildNumberPropertyNamescm.revision/buildNumberPropertyName /configuration - /plugin + /plugin-- plugin groupIdorg.apache.maven.plugins/groupId -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- inexso - information exchange solutions GmbH Ofener Str. 30 | 26121 Oldenburg Tel.: +49 441 219 730 56 | FAX: +49 441 219 730 66 | eMail: volker.we...@inexso.de Firmensitz: Oldenburg | Amtsgericht Oldenburg HRB 205251 Geschäftsführer: Stefan Schulte, Michael Terschüren
Re: Revision numbers in MANIFEST.MF file (was: Re: svn commit: r1069504 - in /myfaces/trinidad/trunk: trinidad-api/pom.xml trinidad-impl/pom.xml)
hi, +1 for adding the revision number in any case. regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/2/11 Volker Weber v.we...@inexso.de Hi, i agree to Bernd, the revision number for a release is not needed, but what is the Problem having this few more lines in any manifest? I would prefer having this info packaged. Regards, Volker 2011/2/10 Bernd Bohmann bernd.bohm...@googlemail.com: Hello Matthias, For a release the revision number is not needed. For a snapshot it might be helpful if someone reports a bug and it's not clear with revision was the base for the snapshot. Regards Bernd Am 10.02.2011 19:23 schrieb Matthias Wessendorf mat...@apache.org: Having the actual revision number inside of the manifest.mf file is nice. However, not sure if that is really needed for every build, therefore I commented it out. Perhaps this should be done only in the release profile ? What do you think ? -Matthias On Thu, Feb 10, 2011 at 7:05 PM, mat...@apache.org wrote: Author: matzew Date: Thu Feb 10 18:05:24 2011 New Revision: 1069504 URL: http://svn.apache.org/viewvc?rev=1069504view=rev Log: disabling the svn revision number plugin - should it be done only on release profile??? Modified: myfaces/trinidad/trunk/trinidad-api/pom.xml myfaces/trinidad/trunk/trinidad-impl/pom.xml Modified: myfaces/trinidad/trunk/trinidad-api/pom.xml URL: http://svn.apache.org/viewvc/myfaces/trinidad/trunk/trinidad-api/pom.xml?rev=1069504r1=1069503r2=1069504view=diff == --- myfaces/trinidad/trunk/trinidad-api/pom.xml (original) +++ myfaces/trinidad/trunk/trinidad-api/pom.xml Thu Feb 10 18:05:24 2011 @@ -172,7 +172,8 @@ !-- To make the current revision number, we use the buildnumber-maven-plugin. -- - plugin + !-- Perhaps this should be only enabled on release profile ? -- + !--plugin groupIdorg.codehaus.mojo/groupId artifactIdbuildnumber-maven-plugin/artifactId version1.0-beta-4/version @@ -190,7 +191,7 @@ getRevisionOnlyOncetrue/getRevisionOnlyOnce buildNumberPropertyNamescm.revision/buildNumberPropertyName /configuration - /plugin + /plugin-- plugin groupIdorg.apache.maven.plugins/groupId Modified: myfaces/trinidad/trunk/trinidad-impl/pom.xml URL: http://svn.apache.org/viewvc/myfaces/trinidad/trunk/trinidad-impl/pom.xml?rev=1069504r1=1069503r2=1069504view=diff == --- myfaces/trinidad/trunk/trinidad-impl/pom.xml (original) +++ myfaces/trinidad/trunk/trinidad-impl/pom.xml Thu Feb 10 18:05:24 2011 @@ -211,7 +211,8 @@ !-- To make the current revision number, we use the buildnumber-maven-plugin. -- - plugin + !-- Perhaps this should be only enabled on release profile ? -- + !--plugin groupIdorg.codehaus.mojo/groupId artifactIdbuildnumber-maven-plugin/artifactId version1.0-beta-4/version @@ -229,7 +230,7 @@ getRevisionOnlyOncetrue/getRevisionOnlyOnce buildNumberPropertyNamescm.revision/buildNumberPropertyName /configuration - /plugin + /plugin-- plugin groupIdorg.apache.maven.plugins/groupId -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- inexso - information exchange solutions GmbH Ofener Str. 30 | 26121 Oldenburg Tel.: +49 441 219 730 56 | FAX: +49 441 219 730 66 | eMail: volker.we...@inexso.de Firmensitz: Oldenburg | Amtsgericht Oldenburg HRB 205251 Geschäftsführer: Stefan Schulte, Michael Terschüren
[jira] Created: (EXTCDI-132) CoDI crashes on Resin 4
CoDI crashes on Resin 4 --- Key: EXTCDI-132 URL: https://issues.apache.org/jira/browse/EXTCDI-132 Project: MyFaces CODI Issue Type: Bug Reporter: Matthias Weßendorf Deploying a demo app, containing codi to Resin, I am getting a Config excecption there -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (EXTCDI-132) CoDI crashes on Resin 4
[
https://issues.apache.org/jira/browse/EXTCDI-132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12993447#comment-12993447
]
Matthias Weßendorf commented on EXTCDI-132:
---
/home/matzew/work/source/JAX2011/Resin/resin-4.0.15/conf/resin.xml:110:
org.apache.myfaces.extensions.cdi.jsf.impl.scope.conversation.InstanceProducer.destroyAllConversations
is an invalid disposes method because it doesn't match a @Produces method
108:- Sets max-age for cacheable pages, e.g. static pages.
109: --
110: resin:if test=${resin.professional}
111: cache-mapping url-pattern=/ max-age=5s/
112: cache-mapping url-pattern=*.gif max-age=60s/
at
com.caucho.config.xml.XmlConfigContext.error(XmlConfigContext.java:1202)
at
com.caucho.config.xml.XmlConfigContext.configureChildNode(XmlConfigContext.java:461)
at
com.caucho.config.xml.XmlConfigContext.configureNodeAttributes(XmlConfigContext.java:408)
at
com.caucho.config.xml.XmlConfigContext.configureNode(XmlConfigContext.java:363)
at
com.caucho.config.xml.XmlConfigContext.configureChildBean(XmlConfigContext.java:668)
at
com.caucho.config.xml.XmlConfigContext.configureBeanProperties(XmlConfigContext.java:656)
at
com.caucho.config.xml.XmlConfigContext.configureChildNode(XmlConfigContext.java:454)
at
com.caucho.config.xml.XmlConfigContext.configureAttribute(XmlConfigContext.java:323)
at
com.caucho.config.program.NodeBuilderChildProgram.inject(NodeBuilderChildProgram.java:82)
at
com.caucho.config.program.ContainerProgram.inject(ContainerProgram.java:86)
at
com.caucho.config.program.ConfigProgram.configure(ConfigProgram.java:107)
at
com.caucho.env.deploy.EnvironmentDeployController.configureInstance(EnvironmentDeployController.java:452)
at
com.caucho.env.deploy.EnvironmentDeployController.configureInstance(EnvironmentDeployController.java:57)
at
com.caucho.env.deploy.DeployController.startImpl(DeployController.java:626)
at
com.caucho.env.deploy.StartAutoRedeployAutoStrategy.request(StartAutoRedeployAutoStrategy.java:129)
at
com.caucho.env.deploy.DeployController.request(DeployController.java:545)
at
com.caucho.server.webapp.WebAppVersioningController.startImpl(WebAppVersioningController.java:145)
at
com.caucho.server.webapp.WebAppVersioningController.startImpl(WebAppVersioningController.java:45)
at
com.caucho.env.deploy.StartAutoRedeployAutoStrategy.startOnInit(StartAutoRedeployAutoStrategy.java:77)
at
com.caucho.env.deploy.DeployController.startOnInit(DeployController.java:493)
at com.caucho.env.deploy.DeployContainer.start(DeployContainer.java:171)
at
com.caucho.server.webapp.WebAppContainer.start(WebAppContainer.java:713)
at com.caucho.server.host.Host.start(Host.java:675)
at
com.caucho.env.deploy.DeployController.startImpl(DeployController.java:630)
at
com.caucho.env.deploy.StartAutoRedeployAutoStrategy.startOnInit(StartAutoRedeployAutoStrategy.java:77)
at
com.caucho.env.deploy.DeployController.startOnInit(DeployController.java:493)
at com.caucho.env.deploy.DeployContainer.start(DeployContainer.java:171)
at com.caucho.server.host.HostContainer.start(HostContainer.java:542)
at com.caucho.server.cluster.Server.start(Server.java:1211)
at
com.caucho.server.cluster.ServletService.start(ServletService.java:72)
at
com.caucho.env.service.ResinSystem.startServices(ResinSystem.java:508)
at com.caucho.env.service.ResinSystem.start(ResinSystem.java:476)
at com.caucho.server.resin.Resin.start(Resin.java:892)
at com.caucho.server.resin.Resin.initMain(Resin.java:1020)
at com.caucho.server.resin.Resin.main(Resin.java:1287)
Caused by: com.caucho.config.ConfigException:
org.apache.myfaces.extensions.cdi.jsf.impl.scope.conversation.InstanceProducer.destroyAllConversations
is an invalid disposes method because it doesn't match a @Produces method
at
com.caucho.config.inject.ProducesBuilder.introspectProduces(ProducesBuilder.java:117)
at
com.caucho.config.inject.ManagedBeanImpl.introspectProduces(ManagedBeanImpl.java:358)
at
com.caucho.config.inject.InjectManager.addDiscoveredBean(InjectManager.java:3283)
at
com.caucho.config.inject.InjectManager.discoverBeanImpl(InjectManager.java:3228)
at
com.caucho.config.inject.InjectManager.processPendingAnnotatedTypes(InjectManager.java:2968)
at
com.caucho.config.inject.InjectManager.update(InjectManager.java:2949)
at
com.caucho.config.inject.InjectManager.getReferenceFactory(InjectManager.java:1345)
at
com.caucho.config.el.CandiElResolver.getValue(CandiElResolver.java:125)
at com.caucho.el.StackELResolver.getValue(StackELResolver.java:143)
[jira] Resolved: (EXTCDI-132) CoDI crashes on Resin 4
[ https://issues.apache.org/jira/browse/EXTCDI-132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthias Weßendorf resolved EXTCDI-132. --- Resolution: Fixed Fix Version/s: 0.9.3 this issue is not present with 0.9.3 CoDI crashes on Resin 4 --- Key: EXTCDI-132 URL: https://issues.apache.org/jira/browse/EXTCDI-132 Project: MyFaces CODI Issue Type: Bug Reporter: Matthias Weßendorf Fix For: 0.9.3 Deploying a demo app, containing codi to Resin, I am getting a Config excecption there -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] release for myfaces core 2.0.4
+1 Regards, Jakob 2011/2/9 Mark Struberg strub...@yahoo.de: +1 LieGrue, strub --- On Wed, 2/9/11, Gerhard gerhard.petra...@gmail.com wrote: From: Gerhard gerhard.petra...@gmail.com Subject: Re: [VOTE] release for myfaces core 2.0.4 To: MyFaces Development dev@myfaces.apache.org Date: Wednesday, February 9, 2011, 1:52 PM +1 regards,gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/2/9 Martin Koci martin.kocicak.k...@gmail.com +1 Leonardo Uribe píše v St 09. 02. 2011 v 01:07 -0500: Hi, I was running the needed tasks to get the 2.0.4 release of Apache MyFaces core out. The artifacts passed all TCK tests. Please note that this vote concerns all of the following parts: 1. Maven artifact group org.apache.myfaces.shared v4.0.5 [1] 2. Maven artifact group org.apache.myfaces.core v2.0.4 [1] The artifacts were deployed on nexus repo [1] and to my private Apache account [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.4 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] https://repository.apache.org/content/repositories/orgapachemyfaces-044/org/apache/myfaces/ [2] http://www.apache.org/foundation/voting.html#ReleaseVotes [3] http://people.apache.org/~lu4242/myfaces204binsrc [4] https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600version=12316153 Sucker-punch spam with award-winning protection. Try the free Yahoo! Mail Beta. http://advision.webevents.yahoo.com/mailbeta/features_spam.html -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
[jira] Commented: (EXTCDI-132) CoDI crashes on Resin 4
[
https://issues.apache.org/jira/browse/EXTCDI-132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12993462#comment-12993462
]
Mark Struberg commented on EXTCDI-132:
--
yes, the whole method got removed.
Nonetheless, the issue is a bug in CanDI, because this disposal method is
programmed in exaclty the way described in the spec paragraph
3.3.6. Declaring a disposer method
@Produces @ConversationScoped @UserDatabase
public EntityManager create(EntityManagerFactory emf) { ...
public void close(@Disposes @UserDatabase EntityManager em) {
please note that the disposal method doesn't need to mention the scope. (And
btw, it also doesn't need the qualifier afaik).
CoDI crashes on Resin 4
---
Key: EXTCDI-132
URL: https://issues.apache.org/jira/browse/EXTCDI-132
Project: MyFaces CODI
Issue Type: Bug
Reporter: Matthias Weßendorf
Fix For: 0.9.3
Deploying a demo app, containing codi to Resin, I am getting a Config
excecption there
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Revision numbers in MANIFEST.MF file (was: Re: svn commit: r1069504 - in /myfaces/trinidad/trunk: trinidad-api/pom.xml trinidad-impl/pom.xml)
+1, I totally agree with Bernd.. Releases have VERSION numbers. It's snapshots that need revision and I see no harm either way. On Feb 11, 2011, at 2:44 AM, Gerhard gerhard.petra...@gmail.com wrote: hi, +1 for adding the revision number in any case. regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/2/11 Volker Weber v.we...@inexso.de Hi, i agree to Bernd, the revision number for a release is not needed, but what is the Problem having this few more lines in any manifest? I would prefer having this info packaged. Regards, Volker 2011/2/10 Bernd Bohmann bernd.bohm...@googlemail.com: Hello Matthias, For a release the revision number is not needed. For a snapshot it might be helpful if someone reports a bug and it's not clear with revision was the base for the snapshot. Regards Bernd Am 10.02.2011 19:23 schrieb Matthias Wessendorf mat...@apache.org: Having the actual revision number inside of the manifest.mf file is nice. However, not sure if that is really needed for every build, therefore I commented it out. Perhaps this should be done only in the release profile ? What do you think ? -Matthias On Thu, Feb 10, 2011 at 7:05 PM, mat...@apache.org wrote: Author: matzew Date: Thu Feb 10 18:05:24 2011 New Revision: 1069504 URL: http://svn.apache.org/viewvc?rev=1069504view=rev Log: disabling the svn revision number plugin - should it be done only on release profile??? Modified: myfaces/trinidad/trunk/trinidad-api/pom.xml myfaces/trinidad/trunk/trinidad-impl/pom.xml Modified: myfaces/trinidad/trunk/trinidad-api/pom.xml URL: http://svn.apache.org/viewvc/myfaces/trinidad/trunk/trinidad-api/pom.xml?rev=1069504r1=1069503r2=1069504view=diff == --- myfaces/trinidad/trunk/trinidad-api/pom.xml (original) +++ myfaces/trinidad/trunk/trinidad-api/pom.xml Thu Feb 10 18:05:24 2011 @@ -172,7 +172,8 @@ !-- To make the current revision number, we use the buildnumber-maven-plugin. -- - plugin + !-- Perhaps this should be only enabled on release profile ? -- + !--plugin groupIdorg.codehaus.mojo/groupId artifactIdbuildnumber-maven-plugin/artifactId version1.0-beta-4/version @@ -190,7 +191,7 @@ getRevisionOnlyOncetrue/getRevisionOnlyOnce buildNumberPropertyNamescm.revision/buildNumberPropertyName /configuration - /plugin + /plugin-- plugin groupIdorg.apache.maven.plugins/groupId Modified: myfaces/trinidad/trunk/trinidad-impl/pom.xml URL: http://svn.apache.org/viewvc/myfaces/trinidad/trunk/trinidad-impl/pom.xml?rev=1069504r1=1069503r2=1069504view=diff == --- myfaces/trinidad/trunk/trinidad-impl/pom.xml (original) +++ myfaces/trinidad/trunk/trinidad-impl/pom.xml Thu Feb 10 18:05:24 2011 @@ -211,7 +211,8 @@ !-- To make the current revision number, we use the buildnumber-maven-plugin. -- - plugin + !-- Perhaps this should be only enabled on release profile ? -- + !--plugin groupIdorg.codehaus.mojo/groupId artifactIdbuildnumber-maven-plugin/artifactId version1.0-beta-4/version @@ -229,7 +230,7 @@ getRevisionOnlyOncetrue/getRevisionOnlyOnce buildNumberPropertyNamescm.revision/buildNumberPropertyName /configuration - /plugin + /plugin-- plugin groupIdorg.apache.maven.plugins/groupId -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- inexso - information exchange solutions GmbH Ofener Str. 30 | 26121 Oldenburg Tel.: +49 441 219 730 56 | FAX: +49 441 219 730 66 | eMail: volker.we...@inexso.de Firmensitz: Oldenburg | Amtsgericht Oldenburg HRB 205251 Geschäftsführer: Stefan Schulte, Michael Terschüren
[jira] Created: (MYFACES-3041) h:outputFormat does not use converter for parameters
h:outputFormat does not use converter for parameters -- Key: MYFACES-3041 URL: https://issues.apache.org/jira/browse/MYFACES-3041 Project: MyFaces Core Issue Type: Bug Components: JSR-127 Affects Versions: 2.0.3 Reporter: Michael Borgwardt Priority: Minor h:outputFormat simply does a toString() on its parameters, instead of properly using converters. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (TRINIDAD-2033) trh:tableLayout tag doc should call out table-layout:fixed as desirable for programmatically-resizable cell contents
trh:tableLayout tag doc should call out table-layout:fixed as desirable for programmatically-resizable cell contents Key: TRINIDAD-2033 URL: https://issues.apache.org/jira/browse/TRINIDAD-2033 Project: MyFaces Trinidad Issue Type: Bug Reporter: Matt Cooper Assignee: Matt Cooper The trh:tableLayout tag doc should call out table-layout:fixed as desirable for programmatically-resizable cell contents. If you have a tableLayout and have percentage-based widths assigned to a cellFormat that contains a programmatically-resizable child component whose width is dependent on the cellFormat's percentage width, the child won't resize when the tableLayout resizes unless the tableLayout has an inlineStyle=table-layout:fixed. This may not be obvious for people unfamiliar with how tables work so it needs to be mentioned in the tag documentation. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (TRINIDAD-2033) trh:tableLayout tag doc should call out table-layout:fixed as desirable for programmatically-resizable cell contents
[ https://issues.apache.org/jira/browse/TRINIDAD-2033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Cooper resolved TRINIDAD-2033. --- Resolution: Fixed trh:tableLayout tag doc should call out table-layout:fixed as desirable for programmatically-resizable cell contents Key: TRINIDAD-2033 URL: https://issues.apache.org/jira/browse/TRINIDAD-2033 Project: MyFaces Trinidad Issue Type: Bug Reporter: Matt Cooper Assignee: Matt Cooper Fix For: 1.2.15-core , 2.0.0-beta-2 The trh:tableLayout tag doc should call out table-layout:fixed as desirable for programmatically-resizable cell contents. If you have a tableLayout and have percentage-based widths assigned to a cellFormat that contains a programmatically-resizable child component whose width is dependent on the cellFormat's percentage width, the child won't resize when the tableLayout resizes unless the tableLayout has an inlineStyle=table-layout:fixed. This may not be obvious for people unfamiliar with how tables work so it needs to be mentioned in the tag documentation. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Issue 2995 - Leo please read
On Feb 10, 2011, at 9:39 PM, Leonardo Uribe wrote: Hi David There are some points to take into consideration for myfaces-api jar 1. It is preferred that myfaces-api have the less amount of compile or runtime dependencies to work. Right now, myfaces 2.0.x api and impl only require: commons-beanutils-1.8.3.jar commons-codec-1.4.jar commons-collections-3.2.1.jar commons-digester-1.8.jar commons-logging-1.1.1.jar (transitive from commons packages) jstl-1.2.jar The idea is simple: few dependencies means few things to think about when someone configures its custom webapp. The patch provided adds a new dependency, so additionally with myfaces-api and myfaces-impl it is required to include myfaces-api-spi in every webapp that uses future versions myfaces. Of course,a new module is required because the code cannot be on myfaces-impl (circular dependency). I would think that anyone who is concerned with how many myfaces jars they use would use the osgi bundle which is only one artifact rather than 2 (current) or 3 (proposed). 2. In some situations, a myfaces-api jar is used to only provide classes under javax.faces package, but it is not wanted to include classes under org.apache.myfaces package in that jar, to prevent users to import org.apache.myfaces packages and classes when they don't want. 3. It is wanted to keep coherence with the javadoc provided by the spec. That means, myfaces default behavior should do what the spec javadoc says, but it is not wanted web applications that runs only with myfaces and not with other jsf implementations, because after all that is the intention of take a lot of time and effort to do a specification. The patch proposed could be seen as an unofficial extension for FactoryFinder. I'm not saying we can't do that, just we need to take our time before do some change. IMO the jsf spec and reference implementation make the assumption that there is one classloader per war, probably because all existing containers do that, despite the explicit statememts in the ee spec that this is not required. So to me this is a spec defect. I don't think there's any chance of fixing this in the spec but it is possible to fix it with this extension. Now, let's review the previous response: DJ This is NOT for osgi. The ee classloading model does not require a separate DJ classloader for each war in an ear, whereas currently the myfaces api implementation DJ assumes that web apps can be distinguished by the thread context classloader. But this new feature is for geronimo, right? It is true the ee classloading model does not require a separate classloader ( well, is questionable, because only if something is not explicit mentioned does not means the opposite is true ) , but the truth is almost every ee container uses a different classloader for each war in an ear (maybe all). If that so, why bother us to put this stuff on myfaces api if this will be used by geronimo? if other container in the future wants to use this feature, I think it is a good bet they surely will use myfaces osgi bundle. This is not an osgi specific feature. Are you suggesting that geronimo provide its own FacesFactory implementation and pack up our own myfaces osgi bundle including this code? IMO if myfaces includes this code at all it should not be in a specifically osgi related form. Other option i can imagine is do something using java reflection api. In this way, the code could live in myfaces-impl (where all our spi interfaces are), but I have not dedicated too much time about it. I can write this so the spi-api is optional and is only used if the spi-api interface is available, but this would be significantly more complicated which is why I didn't suggest it at first. Let me know if you'd like to see this. I also think that putting it in myfaces impl is not a good idea because theoretically myfaces-api can be used with another jsf implementation. thanks david jencks regards, Leonardo Uribe
Re: Issue 2995 - Leo please read
Imo myfaces-api is pretty much bound to myfaces-impl. Like el-api is bound to the el-impl most of the times. (sadly) LieGrue, strub --- On Fri, 2/11/11, David Jencks david_jen...@yahoo.com wrote: From: David Jencks david_jen...@yahoo.com Subject: Re: Issue 2995 - Leo please read To: MyFaces Development dev@myfaces.apache.org, Leonardo Uribe lu4...@gmail.com Date: Friday, February 11, 2011, 6:23 PM On Feb 10, 2011, at 9:39 PM, Leonardo Uribe wrote: Hi David There are some points to take into consideration for myfaces-api jar 1. It is preferred that myfaces-api have the less amount of compile or runtime dependencies to work. Right now, myfaces 2.0.x api and impl only require: commons-beanutils-1.8.3.jar commons-codec-1.4.jar commons-collections-3.2.1.jar commons-digester-1.8.jar commons-logging-1.1.1.jar (transitive from commons packages) jstl-1.2.jar The idea is simple: few dependencies means few things to think about when someone configures its custom webapp. The patch provided adds a new dependency, so additionally with myfaces-api and myfaces-impl it is required to include myfaces-api-spi in every webapp that uses future versions myfaces. Of course,a new module is required because the code cannot be on myfaces-impl (circular dependency). I would think that anyone who is concerned with how many myfaces jars they use would use the osgi bundle which is only one artifact rather than 2 (current) or 3 (proposed). 2. In some situations, a myfaces-api jar is used to only provide classes under javax.faces package, but it is not wanted to include classes under org.apache.myfaces package in that jar, to prevent users to import org.apache.myfaces packages and classes when they don't want. 3. It is wanted to keep coherence with the javadoc provided by the spec. That means, myfaces default behavior should do what the spec javadoc says, but it is not wanted web applications that runs only with myfaces and not with other jsf implementations, because after all that is the intention of take a lot of time and effort to do a specification. The patch proposed could be seen as an unofficial extension for FactoryFinder. I'm not saying we can't do that, just we need to take our time before do some change. IMO the jsf spec and reference implementation make the assumption that there is one classloader per war, probably because all existing containers do that, despite the explicit statememts in the ee spec that this is not required. So to me this is a spec defect. I don't think there's any chance of fixing this in the spec but it is possible to fix it with this extension. Now, let's review the previous response: DJ This is NOT for osgi. The ee classloading model does not require a separate DJ classloader for each war in an ear, whereas currently the myfaces api implementation DJ assumes that web apps can be distinguished by the thread context classloader. But this new feature is for geronimo, right? It is true the ee classloading model does not require a separate classloader ( well, is questionable, because only if something is not explicit mentioned does not means the opposite is true ) , but the truth is almost every ee container uses a different classloader for each war in an ear (maybe all). If that so, why bother us to put this stuff on myfaces api if this will be used by geronimo? if other container in the future wants to use this feature, I think it is a good bet they surely will use myfaces osgi bundle. This is not an osgi specific feature. Are you suggesting that geronimo provide its own FacesFactory implementation and pack up our own myfaces osgi bundle including this code? IMO if myfaces includes this code at all it should not be in a specifically osgi related form. Other option i can imagine is do something using java reflection api. In this way, the code could live in myfaces-impl (where all our spi interfaces are), but I have not dedicated too much time about it. I can write this so the spi-api is optional and is only used if the spi-api interface is available, but this would be significantly more complicated which is why I didn't suggest it at first. Let me know if you'd like to see this. I also think that putting it in myfaces impl is not a good idea because theoretically myfaces-api can be used with another jsf implementation. thanks david jencks regards, Leonardo Uribe
Re: Issue 2995 - Leo please read
I agree with this, so long as the circular dependencies for compile time are not used. I also agree with many of tue others, the MyFaces API should be available at compile time and be BINARY compatible with the RI, and even though the impl only need be present at runtime, I don't think anyone expects to be able to run, say, a mojarra impl with a MyFaces API. On Feb 11, 2011, at 11:48 AM, Mark Struberg strub...@yahoo.de wrote: Imo myfaces-api is pretty much bound to myfaces-impl. Like el-api is bound to the el-impl most of the times. (sadly) LieGrue, strub --- On Fri, 2/11/11, David Jencks david_jen...@yahoo.com wrote: From: David Jencks david_jen...@yahoo.com Subject: Re: Issue 2995 - Leo please read To: MyFaces Development dev@myfaces.apache.org, Leonardo Uribe lu4...@gmail.com Date: Friday, February 11, 2011, 6:23 PM On Feb 10, 2011, at 9:39 PM, Leonardo Uribe wrote: Hi David There are some points to take into consideration for myfaces-api jar 1. It is preferred that myfaces-api have the less amount of compile or runtime dependencies to work. Right now, myfaces 2.0.x api and impl only require: commons-beanutils-1.8.3.jar commons-codec-1.4.jar commons-collections-3.2.1.jar commons-digester-1.8.jar commons-logging-1.1.1.jar (transitive from commons packages) jstl-1.2.jar The idea is simple: few dependencies means few things to think about when someone configures its custom webapp. The patch provided adds a new dependency, so additionally with myfaces-api and myfaces-impl it is required to include myfaces-api-spi in every webapp that uses future versions myfaces. Of course,a new module is required because the code cannot be on myfaces-impl (circular dependency). I would think that anyone who is concerned with how many myfaces jars they use would use the osgi bundle which is only one artifact rather than 2 (current) or 3 (proposed). 2. In some situations, a myfaces-api jar is used to only provide classes under javax.faces package, but it is not wanted to include classes under org.apache.myfaces package in that jar, to prevent users to import org.apache.myfaces packages and classes when they don't want. 3. It is wanted to keep coherence with the javadoc provided by the spec. That means, myfaces default behavior should do what the spec javadoc says, but it is not wanted web applications that runs only with myfaces and not with other jsf implementations, because after all that is the intention of take a lot of time and effort to do a specification. The patch proposed could be seen as an unofficial extension for FactoryFinder. I'm not saying we can't do that, just we need to take our time before do some change. IMO the jsf spec and reference implementation make the assumption that there is one classloader per war, probably because all existing containers do that, despite the explicit statememts in the ee spec that this is not required. So to me this is a spec defect. I don't think there's any chance of fixing this in the spec but it is possible to fix it with this extension. Now, let's review the previous response: DJ This is NOT for osgi. The ee classloading model does not require a separate DJ classloader for each war in an ear, whereas currently the myfaces api implementation DJ assumes that web apps can be distinguished by the thread context classloader. But this new feature is for geronimo, right? It is true the ee classloading model does not require a separate classloader ( well, is questionable, because only if something is not explicit mentioned does not means the opposite is true ) , but the truth is almost every ee container uses a different classloader for each war in an ear (maybe all). If that so, why bother us to put this stuff on myfaces api if this will be used by geronimo? if other container in the future wants to use this feature, I think it is a good bet they surely will use myfaces osgi bundle. This is not an osgi specific feature. Are you suggesting that geronimo provide its own FacesFactory implementation and pack up our own myfaces osgi bundle including this code? IMO if myfaces includes this code at all it should not be in a specifically osgi related form. Other option i can imagine is do something using java reflection api. In this way, the code could live in myfaces-impl (where all our spi interfaces are), but I have not dedicated too much time about it. I can write this so the spi-api is optional and is only used if the spi-api interface is available, but this would be significantly more complicated which is why I didn't suggest it at first. Let me know if you'd like to see this. I also think that putting it in myfaces impl is not a good idea because theoretically myfaces-api can be used with another jsf implementation. thanks david jencks regards, Leonardo Uribe
Re: [VOTE] release for myfaces core 2.0.4
+1 Am 11.02.11 12:54, schrieb Jakob Korherr: +1 Regards, Jakob 2011/2/9 Mark Strubergstrub...@yahoo.de: +1 LieGrue, strub --- On Wed, 2/9/11, Gerhardgerhard.petra...@gmail.com wrote: From: Gerhardgerhard.petra...@gmail.com Subject: Re: [VOTE] release for myfaces core 2.0.4 To: MyFaces Developmentdev@myfaces.apache.org Date: Wednesday, February 9, 2011, 1:52 PM +1 regards,gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/2/9 Martin Kocimartin.kocicak.k...@gmail.com +1 Leonardo Uribe píše v St 09. 02. 2011 v 01:07 -0500: Hi, I was running the needed tasks to get the 2.0.4 release of Apache MyFaces core out. The artifacts passed all TCK tests. Please note that this vote concerns all of the following parts: 1. Maven artifact group org.apache.myfaces.shared v4.0.5 [1] 2. Maven artifact group org.apache.myfaces.core v2.0.4 [1] The artifacts were deployed on nexus repo [1] and to my private Apache account [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.4 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] https://repository.apache.org/content/repositories/orgapachemyfaces-044/org/apache/myfaces/ [2] http://www.apache.org/foundation/voting.html#ReleaseVotes [3] http://people.apache.org/~lu4242/myfaces204binsrc [4] https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600version=12316153 Sucker-punch spam with award-winning protection. Try the free Yahoo! Mail Beta. http://advision.webevents.yahoo.com/mailbeta/features_spam.html
On an unrelated sidenote
I have become father of a nice little boy yesterday. My second child. Werner
Re: On an unrelated sidenote
congratulations! regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/2/11 Werner Punz werner.p...@gmail.com I have become father of a nice little boy yesterday. My second child. Werner
Re: On an unrelated sidenote
Congratulations Werner! I bet you are a very good father. On Sat, Feb 12, 2011 at 12:26 AM, Werner Punz werner.p...@gmail.com wrote: I have become father of a nice little boy yesterday. My second child. Werner -- Hazem Ahmed Saleh Ahmed Author of (The Definitive Guide to Apache MyFaces and Facelets): http://www.amazon.com/Definitive-Guide-Apache-MyFaces-Facelets/dp/1590597370 http://www.amazon.com/-/e/B002M052KY Visualize and share your social networks 2D and 3D: http://www.mapmysocial.com
Re: On an unrelated sidenote
Congrats!!! And forget sleeping... Bruno On 11 February 2011 22:36, Hazem Saleh haz...@apache.org wrote: Congratulations Werner! I bet you are a very good father. On Sat, Feb 12, 2011 at 12:26 AM, Werner Punz werner.p...@gmail.comwrote: I have become father of a nice little boy yesterday. My second child. Werner -- Hazem Ahmed Saleh Ahmed Author of (The Definitive Guide to Apache MyFaces and Facelets): http://www.amazon.com/Definitive-Guide-Apache-MyFaces-Facelets/dp/1590597370 http://www.amazon.com/-/e/B002M052KY Visualize and share your social networks 2D and 3D: http://www.mapmysocial.com
Re: On an unrelated sidenote
Awesome! Congratulations! On Fri, Feb 11, 2011 at 5:50 PM, Bruno Aranda brunoara...@gmail.com wrote: Congrats!!! And forget sleeping... Bruno On 11 February 2011 22:36, Hazem Saleh haz...@apache.org wrote: Congratulations Werner! I bet you are a very good father. On Sat, Feb 12, 2011 at 12:26 AM, Werner Punz werner.p...@gmail.comwrote: I have become father of a nice little boy yesterday. My second child. Werner -- Hazem Ahmed Saleh Ahmed Author of (The Definitive Guide to Apache MyFaces and Facelets): http://www.amazon.com/Definitive-Guide-Apache-MyFaces-Facelets/dp/1590597370 http://www.amazon.com/-/e/B002M052KY Visualize and share your social networks 2D and 3D: http://www.mapmysocial.com
Re: On an unrelated sidenote
Congrats!! On Friday, February 11, 2011, Zubin Wadia zwa...@gmail.com wrote: Awesome! Congratulations! On Fri, Feb 11, 2011 at 5:50 PM, Bruno Aranda brunoara...@gmail.com wrote: Congrats!!! And forget sleeping... Bruno On 11 February 2011 22:36, Hazem Saleh haz...@apache.org wrote: Congratulations Werner! I bet you are a very good father. On Sat, Feb 12, 2011 at 12:26 AM, Werner Punz werner.p...@gmail.com wrote: I have become father of a nice little boy yesterday. My second child. Werner -- Hazem Ahmed Saleh Ahmed Author of (The Definitive Guide to Apache MyFaces and Facelets): http://www.amazon.com/Definitive-Guide-Apache-MyFaces-Facelets/dp/1590597370 http://www.amazon.com/-/e/B002M052KY Visualize and share your social networks 2D and 3D: http://www.mapmysocial.com http://www.mapmysocial.com/ -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
[jira] Created: (EXTCDI-133) NPE in Caucho Resin 4.0.15
NPE in Caucho Resin 4.0.15 -- Key: EXTCDI-133 URL: https://issues.apache.org/jira/browse/EXTCDI-133 Project: MyFaces CODI Issue Type: Bug Reporter: Matthias Weßendorf Running the attached WAR file in Caucho Resin, I am getting a NPE when trying to access a page: java.lang.NullPointerException at org.apache.myfaces.extensions.cdi.jsf.impl.listener.phase.JsfRequestLifecycleBroadcaster.broadcastBeforeEvent(JsfRequestLifecycleBroadcaster.java:60) at org.apache.myfaces.extensions.cdi.jsf.impl.listener.phase.JsfRequestLifecyclePhaseListener.beforePhase(JsfRequestLifecyclePhaseListener.java:46) at com.sun.faces.lifecycle.Phase.handleBeforePhase(Phase.java:224) at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:95) at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:107) at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:114) at org.apache.myfaces.extensions.cdi.jsf2.impl.listener.phase.CodiLifecycleWrapper.execute(CodiLifecycleWrapper.java:84) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:308) at com.caucho.server.dispatch.ServletFilterChain.doFilter(ServletFilterChain.java:109) at com.caucho.server.webapp.WebAppFilterChain.doFilter(WebAppFilterChain.java:184) at com.caucho.server.webapp.AccessLogFilterChain.doFilter(AccessLogFilterChain.java:95) at com.caucho.server.dispatch.ServletInvocation.service(ServletInvocation.java:287) at com.caucho.server.http.HttpRequest.handleRequest(HttpRequest.java:794) at com.caucho.network.listen.TcpSocketLink.dispatchRequest(TcpSocketLink.java:729) at com.caucho.network.listen.TcpSocketLink.handleRequest(TcpSocketLink.java:688) at com.caucho.network.listen.TcpSocketLink.handleRequestsImpl(TcpSocketLink.java:668) at com.caucho.network.listen.TcpSocketLink.handleRequests(TcpSocketLink.java:616) at com.caucho.network.listen.AcceptTask.doTask(AcceptTask.java:104) at com.caucho.network.listen.ConnectionReadTask.runThread(ConnectionReadTask.java:98) at com.caucho.network.listen.ConnectionReadTask.run(ConnectionReadTask.java:81) at com.caucho.network.listen.AcceptTask.run(AcceptTask.java:67) at com.caucho.env.thread.ResinThread.runTasks(ResinThread.java:164) at com.caucho.env.thread.ResinThread.run(ResinThread.java:130) -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (EXTCDI-133) NPE in Caucho Resin 4.0.15
[ https://issues.apache.org/jira/browse/EXTCDI-133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12993841#comment-12993841 ] Matthias Weßendorf commented on EXTCDI-133: --- I also tried with a more recent Mojarra (mojarra-2.0.4-FCS-binary.zip), by replacing the one in $RESIN_HOME/lib NPE in Caucho Resin 4.0.15 -- Key: EXTCDI-133 URL: https://issues.apache.org/jira/browse/EXTCDI-133 Project: MyFaces CODI Issue Type: Bug Affects Versions: 0.9.3 Reporter: Matthias Weßendorf Attachments: Resin.war Running the attached WAR file in Caucho Resin, I am getting a NPE when trying to access a page: java.lang.NullPointerException at org.apache.myfaces.extensions.cdi.jsf.impl.listener.phase.JsfRequestLifecycleBroadcaster.broadcastBeforeEvent(JsfRequestLifecycleBroadcaster.java:60) at org.apache.myfaces.extensions.cdi.jsf.impl.listener.phase.JsfRequestLifecyclePhaseListener.beforePhase(JsfRequestLifecyclePhaseListener.java:46) at com.sun.faces.lifecycle.Phase.handleBeforePhase(Phase.java:224) at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:95) at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:107) at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:114) at org.apache.myfaces.extensions.cdi.jsf2.impl.listener.phase.CodiLifecycleWrapper.execute(CodiLifecycleWrapper.java:84) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:308) at com.caucho.server.dispatch.ServletFilterChain.doFilter(ServletFilterChain.java:109) at com.caucho.server.webapp.WebAppFilterChain.doFilter(WebAppFilterChain.java:184) at com.caucho.server.webapp.AccessLogFilterChain.doFilter(AccessLogFilterChain.java:95) at com.caucho.server.dispatch.ServletInvocation.service(ServletInvocation.java:287) at com.caucho.server.http.HttpRequest.handleRequest(HttpRequest.java:794) at com.caucho.network.listen.TcpSocketLink.dispatchRequest(TcpSocketLink.java:729) at com.caucho.network.listen.TcpSocketLink.handleRequest(TcpSocketLink.java:688) at com.caucho.network.listen.TcpSocketLink.handleRequestsImpl(TcpSocketLink.java:668) at com.caucho.network.listen.TcpSocketLink.handleRequests(TcpSocketLink.java:616) at com.caucho.network.listen.AcceptTask.doTask(AcceptTask.java:104) at com.caucho.network.listen.ConnectionReadTask.runThread(ConnectionReadTask.java:98) at com.caucho.network.listen.ConnectionReadTask.run(ConnectionReadTask.java:81) at com.caucho.network.listen.AcceptTask.run(AcceptTask.java:67) at com.caucho.env.thread.ResinThread.runTasks(ResinThread.java:164) at com.caucho.env.thread.ResinThread.run(ResinThread.java:130) -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
