Re: [jira] [Comment Edited] (MYFACES-3804) Use the same key in server side state saving for ajax requests
Well thanks Mike. Its possible to view the unedited comments from mail list and edited ones in Jira. But expressions such as smileys are not good in mail list :) Regarding use the same key in server side state saving for ajax requests it is ok since use of navigation with ajax is rare and so may be redirect. On Tuesday, November 5, 2013 9:56 PM, Mike Kienenberger (JIRA) dev@myfaces.apache.org wrote: [ https://issues.apache.org/jira/browse/MYFACES-3804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13814014#comment-13814014] Mike Kienenberger edited comment on MYFACES-3804 at 11/5/13 4:24 PM: - Dora, We need to move discussion to the developer mailing list, and reserve the JIRA for resolving issues. There are a number of reasons why the JIRA issue is not the best place for discussion, which I wrote about here: http://mail-archives.apache.org/mod_mbox/myfaces-dev/201311.mbox/%3CCAM1yOjZHhSRwrAQ2Va_Em0yAcPD9mA9D-7daCG7z-eHfr%3DZ0-g%40mail.gmail.com%3E I'm sorry that I didn't speak up a while back when I first noticed it happening, but we need to resume using the developer mailing list for its intended purpose. Please repost your comments from here directly on the developer mailing list. was (Author: mkienenb): Dora, We need to move discussion to the developer mailing list, and reserve the JIRA for resolving issues. There are a number of reasons why the JIRA issue is not the best place for discussion, which I wrote about here: http://mail-archives.apache.org/mod_mbox/myfaces-dev/201311.mbox/%3CCAM1yOjZHhSRwrAQ2Va_Em0yAcPD9mA9D-7daCG7z-eHfr%3DZ0-g%40mail.gmail.com%3E I'm sorry that I didn't speak up a while back when I first noticed it happening, but we need to resume using the developer mailing list for its intended purpose. Use the same key in server side state saving for ajax requests -- Key: MYFACES-3804 URL: https://issues.apache.org/jira/browse/MYFACES-3804 Project: MyFaces Core Issue Type: Improvement Components: JSR-344 Reporter: Leonardo Uribe Attachments: ajaxviewkeytest.patch, ajaxviewkeytest2.patch, ajaxviewsamekey.patch, ajaxviewsamekey2.patch, ajaxviewsamekey3.patch The current code for server side state saving creates one key per request to store the view state. This is ok, but it is not necessary for ajax requests. The reason why is not necessary is because you can never go back to a page when using ajax. If you are on page A and the current request is an ajax request and it returns to the same page and the view is the same that the one that has been restored, the key or the token sent does not need to change, what changes is the internal state of the view. From the client side the page is the same. We can take advantage of this fact and just update the state stored in SerializedViewCollection for the view. The challenge here is detect when this strategy is applicable. For example, what happen if there is an ajax redirect? It looks is a good idea for implement in 2.2, because it avoids to store unnecessary information into session and optimize the use of each view slot. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (TRINIDAD-2406) externalize skin repositories by using SkinProvider SPI
[ https://issues.apache.org/jira/browse/TRINIDAD-2406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anand V Nath updated TRINIDAD-2406: --- Resolution: Fixed Fix Version/s: 2.1.0-core Status: Resolved (was: Patch Available) externalize skin repositories by using SkinProvider SPI --- Key: TRINIDAD-2406 URL: https://issues.apache.org/jira/browse/TRINIDAD-2406 Project: MyFaces Trinidad Issue Type: Improvement Components: Skinning Affects Versions: 2.1.0-core Reporter: Anand V Nath Fix For: 2.1.0-core Attachments: er-skin-provider-ver7.patch, er-skin-provider-ver8.patch, skin-addition-bug-trinidad.patch, spr-bugfix.patch Introduce SkinProvider SPI. Users can use this to create their own skip repositories and expose their skins to the skinning framework. Provide an API to query skin using skin family, skin id, render kit - This will make use of the existing SkinFactory APIs. Only change here is that it should go over all the available SkinProvider SPIs to find a match. Create internal SkinProvider SPIs to handle the Trinidad and RCF skins (or skins defined using trinidad-skins.xml). Provide an API to list all the available skins from all SkinProvider SPIs and make the skin metadata thus available. Make SkinExtension part of public API so that users can use this class to create the Skin objects which they expose through their SkinProvider SPIs -- This message was sent by Atlassian JIRA (v6.1#6144)
Re: [VOTE] Release of Trinidad Maven Plugins 2.0.8
Hey Scott - I attempted to do a clean Trinidad build against the new plugins. I happened to notice this exception during the build: [INFO] --- maven-faces-plugin:2.0.8:generate-jsp-taglibs (default) @ trinidad-impl --- [INFO] ClassNotFound error resolving type org.apache.myfaces.trinidad.model.DateListProvider java.lang.ClassNotFoundException: org.apache.myfaces.trinidad.model.DateListProvider at org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:50) at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:244) at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:230) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:169) at org.apache.myfaces.trinidadbuild.plugin.faces.util.ClassLoaderUtils.loadClass(ClassLoaderUtils.java:86) at org.apache.myfaces.trinidadbuild.plugin.faces.util.ClassLoaderUtils.loadClass(ClassLoaderUtils.java:47) at org.apache.myfaces.trinidadbuild.plugin.faces.generator.taglib.AbstractTagGenerator.resolveType(AbstractTagGenerator.java:247) at org.apache.myfaces.trinidadbuild.plugin.faces.generator.taglib.TrinidadValidatorTagGenerator.writeSetProperty(TrinidadValidatorTagGenerator.java:115) at org.apache.myfaces.trinidadbuild.plugin.faces.generator.taglib.AbstractValidatorTagGenerator.writeSetProperties(AbstractValidatorTagGenerator.java:185) at org.apache.myfaces.trinidadbuild.plugin.faces.generator.taglib.AbstractValidatorTagGenerator.generateTagHandler(AbstractValidatorTagGenerator.java:62) at org.apache.myfaces.trinidadbuild.plugin.faces.GenerateJspTaglibsMojo._generateTagHandlers(GenerateJspTaglibsMojo.java:794) at org.apache.myfaces.trinidadbuild.plugin.faces.GenerateJspTaglibsMojo.execute(GenerateJspTaglibsMojo.java:104) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) 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.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) [INFO] Generated 145 JSP tag(s) I have no idea whether this exception in new in 2.0.8. Is this something that we should look at before rolling out the plugins release? Andy On Mon, Nov 4, 2013 at 4:29 PM, Scott O'Bryan darkar...@gmail.com wrote: I was running the tasks needed to release the Trinidad Maven Plugins version 2.0.8 which is needed as a prerequisite to a Trinidad release. I have compiled the Release Notes[1] for the 2.0.8 release. I have generated the tag [2] and have deployed the built artifacts to nexus [3]. Lastly I have included a source archive [4]. I've done preliminary testing and building, updated the plugins to comply with checkstyle, and made sure the build passed rat:check. Please take a look at the Trinidad Maven Plugins 2.0.8 release artifacts now and vote. Please note: This vote is majority approval with a minimum of three +1 votes (see [5]). [ ] +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, Scott O'Bryan [1] https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310661version=12319290 [2]
[jira] [Reopened] (MYFACES-3817) ajax redirect loosing state information when changes are executed with redirect
[ https://issues.apache.org/jira/browse/MYFACES-3817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dora Rajappan reopened MYFACES-3817: Reopening bug with a better test case. Ajax redirect is loosing state information when changes are executed with redirect normal navigation. Navigate or Redirect from page1 to page2 through ajax request. And navigate (not redirect) from page2 to page1. In this case page1 is built from SerialisedViewCollection and it is found that the state changes are lost. ajax redirect loosing state information when changes are executed with redirect Key: MYFACES-3817 URL: https://issues.apache.org/jira/browse/MYFACES-3817 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 2.2.0-beta Environment: Windows 8 Reporter: Dora Rajappan Original Estimate: 0.8h Remaining Estimate: 0.8h Ajax redirect loosing state information when changes are executed with redirect. This can be addressed #1 By putting a flag in redirect and write it in response after save state in rendering phase. #2 This behaviour true for redirect via navigation handler. In render phase it goes to response complete and state saving is avoided. When its a redirect not make the response complete true and flag it so that in rendering phase state is saved. -- This message was sent by Atlassian JIRA (v6.1#6144)
Re: [VOTE] Release of Trinidad Maven Plugins 2.0.8
Andy, Yeah, I was seeing this too. I was trying to track this as part of my work for the next Trinidad release, but I think your right. This may be handled better in the plugin. At the very least we should evaluate it. What's happening here is a new check was added to test if a class for an attribute happens to be an enumeration. In the case where we get the error, DateListProvider hasn't been built yet since the plugins generate the source BEFORE the plugins are built. I'm going to generate a JIRA ticket and I for one think we need to fix this issue before releasing the plugins. As such. my vote is a -1 pending this issue. -- Scott O'Bryan On November 6, 2013 at 7:42:03 AM, Andy Schwartz (andy.g.schwa...@gmail.com) wrote: Hey Scott - I attempted to do a clean Trinidad build against the new plugins. I happened to notice this exception during the build: [INFO] --- maven-faces-plugin:2.0.8:generate-jsp-taglibs (default) @ trinidad-impl --- [INFO] ClassNotFound error resolving type org.apache.myfaces.trinidad.model.DateListProvider java.lang.ClassNotFoundException: org.apache.myfaces.trinidad.model.DateListProvider at org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:50) at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:244) at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:230) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:169) at org.apache.myfaces.trinidadbuild.plugin.faces.util.ClassLoaderUtils.loadClass(ClassLoaderUtils.java:86) at org.apache.myfaces.trinidadbuild.plugin.faces.util.ClassLoaderUtils.loadClass(ClassLoaderUtils.java:47) at org.apache.myfaces.trinidadbuild.plugin.faces.generator.taglib.AbstractTagGenerator.resolveType(AbstractTagGenerator.java:247) at org.apache.myfaces.trinidadbuild.plugin.faces.generator.taglib.TrinidadValidatorTagGenerator.writeSetProperty(TrinidadValidatorTagGenerator.java:115) at org.apache.myfaces.trinidadbuild.plugin.faces.generator.taglib.AbstractValidatorTagGenerator.writeSetProperties(AbstractValidatorTagGenerator.java:185) at org.apache.myfaces.trinidadbuild.plugin.faces.generator.taglib.AbstractValidatorTagGenerator.generateTagHandler(AbstractValidatorTagGenerator.java:62) at org.apache.myfaces.trinidadbuild.plugin.faces.GenerateJspTaglibsMojo._generateTagHandlers(GenerateJspTaglibsMojo.java:794) at org.apache.myfaces.trinidadbuild.plugin.faces.GenerateJspTaglibsMojo.execute(GenerateJspTaglibsMojo.java:104) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) 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.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) [INFO] Generated 145 JSP tag(s) I have no idea whether this exception in new in 2.0.8. Is this something that we should look at before rolling out the plugins release? Andy On Mon, Nov 4, 2013 at 4:29 PM, Scott O'Bryan darkar...@gmail.com wrote: I was running the tasks needed to release the Trinidad Maven Plugins version 2.0.8 which is needed as a prerequisite to a Trinidad release. I have compiled the Release Notes[1] for the 2.0.8 release. I have generated the tag [2] and have deployed the built artifacts to nexus
[jira] [Created] (TRINIDAD-2425) New plugins issue a warning on unavailability of uncompiled code
Scott O'Bryan created TRINIDAD-2425: --- Summary: New plugins issue a warning on unavailability of uncompiled code Key: TRINIDAD-2425 URL: https://issues.apache.org/jira/browse/TRINIDAD-2425 Project: MyFaces Trinidad Issue Type: Bug Components: Plugins Affects Versions: 2.0.8-plugins Reporter: Scott O'Bryan Assignee: Scott O'Bryan Priority: Blocker The current 2.0.8 tag candidate tries to reference an object to determine type while attempting to generate tags. If this class is in the module where the tags are being generated, this can cause a ClassNotFoundException. This error is being generated multiple times while running a Trinidad Build: [INFO] ClassNotFound error resolving type org.apache.myfaces.trinidad.model.Date ListProvider java.lang.ClassNotFoundException: org.apache.myfaces.trinidad.model.DateListProv ider at java.net.URLClassLoader$1.run(URLClassLoader.java:202) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:190) at java.lang.ClassLoader.loadClass(ClassLoader.java:307) at org.codehaus.classworlds.RealmClassLoader.loadClassDirect(RealmClassL oader.java:195) at org.codehaus.classworlds.DefaultClassRealm.loadClass(DefaultClassReal m.java:255) at org.codehaus.classworlds.DefaultClassRealm.loadClass(DefaultClassReal m.java:274) at org.codehaus.classworlds.RealmClassLoader.loadClass(RealmClassLoader. java:214) at java.lang.ClassLoader.loadClass(ClassLoader.java:248) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:169) at org.apache.myfaces.trinidadbuild.plugin.faces.generator.taglib.Abstra ctTagGenerator.resolveType(AbstractTagGenerator.java:247) at org.apache.myfaces.trinidadbuild.plugin.faces.generator.taglib.Trinid adValidatorTagGenerator.writeSetProperty(TrinidadValidatorTagGenerator.java:96 ) at org.apache.myfaces.trinidadbuild.plugin.faces.generator.taglib.Abstra We need to handle this accordingly -- This message was sent by Atlassian JIRA (v6.1#6144)
Re: [VOTE] Release of Trinidad Maven Plugins 2.0.8
I'm changing my vote to +1. I was able to fix this issue in the trinidad poms
by adding:
dependencies
dependency
groupIdorg.apache.myfaces.trinidad/groupId
artifactIdtrinidad-api/artifactId
version${project.version}/version
/dependency
/dependencies
To the maven-faces plugin definition in trinidad-impl. So I'll handle the
ticket under trinidad and make sure its part of the next release. The key was
found in the maven class loading guide:
http://maven.apache.org/guides/mini/guide-maven-classloading.html
I noticed that the error was being issued in the impl package which should have
had access to the api. But the dependencies are only explicitly available to
the javacc plugin or can be referenced manually by the mojo. Our mojo doesn't
handle dependencies, so the configuration is necessary. Might be nice to add
it at some point though.
Andy, does this work for you?
--
Scott O'Bryan
On November 6, 2013 at 8:32:00 AM, Scott O'Bryan (darkar...@gmail.com) wrote:
Andy,
Yeah, I was seeing this too. I was trying to track this as part of my work for
the next Trinidad release, but I think your right. This may be handled better
in the plugin. At the very least we should evaluate it. What's happening here
is a new check was added to test if a class for an attribute happens to be an
enumeration. In the case where we get the error, DateListProvider hasn't been
built yet since the plugins generate the source BEFORE the plugins are built.
I'm going to generate a JIRA ticket and I for one think we need to fix this
issue before releasing the plugins. As such. my vote is a -1 pending this
issue.
--
Scott O'Bryan
On November 6, 2013 at 7:42:03 AM, Andy Schwartz (andy.g.schwa...@gmail.com)
wrote:
Hey Scott -
I attempted to do a clean Trinidad build against the new plugins. I happened
to notice this exception during the build:
[INFO] --- maven-faces-plugin:2.0.8:generate-jsp-taglibs (default) @
trinidad-impl ---
[INFO] ClassNotFound error resolving type
org.apache.myfaces.trinidad.model.DateListProvider
java.lang.ClassNotFoundException:
org.apache.myfaces.trinidad.model.DateListProvider
at
org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:50)
at
org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:244)
at
org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:230)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:169)
at
org.apache.myfaces.trinidadbuild.plugin.faces.util.ClassLoaderUtils.loadClass(ClassLoaderUtils.java:86)
at
org.apache.myfaces.trinidadbuild.plugin.faces.util.ClassLoaderUtils.loadClass(ClassLoaderUtils.java:47)
at
org.apache.myfaces.trinidadbuild.plugin.faces.generator.taglib.AbstractTagGenerator.resolveType(AbstractTagGenerator.java:247)
at
org.apache.myfaces.trinidadbuild.plugin.faces.generator.taglib.TrinidadValidatorTagGenerator.writeSetProperty(TrinidadValidatorTagGenerator.java:115)
at
org.apache.myfaces.trinidadbuild.plugin.faces.generator.taglib.AbstractValidatorTagGenerator.writeSetProperties(AbstractValidatorTagGenerator.java:185)
at
org.apache.myfaces.trinidadbuild.plugin.faces.generator.taglib.AbstractValidatorTagGenerator.generateTagHandler(AbstractValidatorTagGenerator.java:62)
at
org.apache.myfaces.trinidadbuild.plugin.faces.GenerateJspTaglibsMojo._generateTagHandlers(GenerateJspTaglibsMojo.java:794)
at
org.apache.myfaces.trinidadbuild.plugin.faces.GenerateJspTaglibsMojo.execute(GenerateJspTaglibsMojo.java:104)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
[jira] [Commented] (TRINIDAD-2425) New plugins issue a warning on unavailability of uncompiled code
[ https://issues.apache.org/jira/browse/TRINIDAD-2425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13815085#comment-13815085 ] Scott O'Bryan commented on TRINIDAD-2425: - I actually found a solution to this by editing the pom of trinidad. Our plugins are not aware of the project dependencies. Until that code is written, we need to add a dependency list when defining the plugin. I'll handle this as a Trinidad bug. New plugins issue a warning on unavailability of uncompiled code Key: TRINIDAD-2425 URL: https://issues.apache.org/jira/browse/TRINIDAD-2425 Project: MyFaces Trinidad Issue Type: Bug Components: Plugins Affects Versions: 2.0.8-plugins Reporter: Scott O'Bryan Assignee: Scott O'Bryan Priority: Blocker Original Estimate: 24h Remaining Estimate: 24h The current 2.0.8 tag candidate tries to reference an object to determine type while attempting to generate tags. If this class is in the module where the tags are being generated, this can cause a ClassNotFoundException. This error is being generated multiple times while running a Trinidad Build: [INFO] ClassNotFound error resolving type org.apache.myfaces.trinidad.model.Date ListProvider java.lang.ClassNotFoundException: org.apache.myfaces.trinidad.model.DateListProv ider at java.net.URLClassLoader$1.run(URLClassLoader.java:202) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:190) at java.lang.ClassLoader.loadClass(ClassLoader.java:307) at org.codehaus.classworlds.RealmClassLoader.loadClassDirect(RealmClassL oader.java:195) at org.codehaus.classworlds.DefaultClassRealm.loadClass(DefaultClassReal m.java:255) at org.codehaus.classworlds.DefaultClassRealm.loadClass(DefaultClassReal m.java:274) at org.codehaus.classworlds.RealmClassLoader.loadClass(RealmClassLoader. java:214) at java.lang.ClassLoader.loadClass(ClassLoader.java:248) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:169) at org.apache.myfaces.trinidadbuild.plugin.faces.generator.taglib.Abstra ctTagGenerator.resolveType(AbstractTagGenerator.java:247) at org.apache.myfaces.trinidadbuild.plugin.faces.generator.taglib.Trinid adValidatorTagGenerator.writeSetProperty(TrinidadValidatorTagGenerator.java:96 ) at org.apache.myfaces.trinidadbuild.plugin.faces.generator.taglib.Abstra We need to handle this accordingly -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (TRINIDAD-2425) New plugins issue a warning on unavailability of uncompiled code
[ https://issues.apache.org/jira/browse/TRINIDAD-2425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott O'Bryan resolved TRINIDAD-2425. - Resolution: Fixed Fix Version/s: 2.1.0-core r1539418 | sobryan | 2013-11-06 18:20:22 + | 6 lines Changed paths: M /myfaces/trinidad/trunk/pom.xml M /myfaces/trinidad/trunk/trinidad-impl/pom.xml TRINIDAD-2425 - New plugins issue a warning on unavailability of uncompiled code * Added a dependency section to the plugin definition imll * Changed plugin dependency to be 2.0.8 instead of 2.0.8-SNAPSHOT Until 2.0.8 is officially released, you'll need to build the plugins from the tag @ https://svn.apache.org/repos/asf/myfaces/trinidad-maven/tags/maven-plugin-parent-2.0.8 New plugins issue a warning on unavailability of uncompiled code Key: TRINIDAD-2425 URL: https://issues.apache.org/jira/browse/TRINIDAD-2425 Project: MyFaces Trinidad Issue Type: Bug Components: Build Affects Versions: 2.1.0-core Reporter: Scott O'Bryan Assignee: Scott O'Bryan Priority: Blocker Fix For: 2.1.0-core Original Estimate: 24h Remaining Estimate: 24h The current 2.0.8 tag candidate tries to reference an object to determine type while attempting to generate tags. If this class is in the module where the tags are being generated, this can cause a ClassNotFoundException. This error is being generated multiple times while running a Trinidad Build: [INFO] ClassNotFound error resolving type org.apache.myfaces.trinidad.model.Date ListProvider java.lang.ClassNotFoundException: org.apache.myfaces.trinidad.model.DateListProv ider at java.net.URLClassLoader$1.run(URLClassLoader.java:202) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:190) at java.lang.ClassLoader.loadClass(ClassLoader.java:307) at org.codehaus.classworlds.RealmClassLoader.loadClassDirect(RealmClassL oader.java:195) at org.codehaus.classworlds.DefaultClassRealm.loadClass(DefaultClassReal m.java:255) at org.codehaus.classworlds.DefaultClassRealm.loadClass(DefaultClassReal m.java:274) at org.codehaus.classworlds.RealmClassLoader.loadClass(RealmClassLoader. java:214) at java.lang.ClassLoader.loadClass(ClassLoader.java:248) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:169) at org.apache.myfaces.trinidadbuild.plugin.faces.generator.taglib.Abstra ctTagGenerator.resolveType(AbstractTagGenerator.java:247) at org.apache.myfaces.trinidadbuild.plugin.faces.generator.taglib.Trinid adValidatorTagGenerator.writeSetProperty(TrinidadValidatorTagGenerator.java:96 ) at org.apache.myfaces.trinidadbuild.plugin.faces.generator.taglib.Abstra We need to handle this accordingly -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (MYFACES-3817) ajax redirect loosing state information when changes are executed with redirect
[ https://issues.apache.org/jira/browse/MYFACES-3817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13815158#comment-13815158 ] Leonardo Uribe commented on MYFACES-3817: - I see. Theorically the spec does not handle this case, but it is hard to find a use case when this could be a problem, because most of the time the component state is not relevant after an ajax redirect. But it is just the same for normal POST requests. Once the navigation to a new page is done, the state of the previous page is not saved, but the next one which is rendered is saved into the state. The fact is over the time nobody has complained about this effect, because usually the changes that matters are inside the model. Note this behavior is not fixable in client side state saving, because the token cannot be updated on the client side, but theoretically you can send the view state token with the redirect. I don't think this could be fixed. ajax redirect loosing state information when changes are executed with redirect Key: MYFACES-3817 URL: https://issues.apache.org/jira/browse/MYFACES-3817 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 2.2.0-beta Environment: Windows 8 Reporter: Dora Rajappan Original Estimate: 0.8h Remaining Estimate: 0.8h Ajax redirect loosing state information when changes are executed with redirect. This can be addressed #1 By putting a flag in redirect and write it in response after save state in rendering phase. #2 This behaviour true for redirect via navigation handler. In render phase it goes to response complete and state saving is avoided. When its a redirect not make the response complete true and flag it so that in rendering phase state is saved. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (MYFACES-3820) UIInput.setSubmittedValue() cause recursive call when calling getSubmittedValue() on Debug
Leonardo Uribe created MYFACES-3820: --- Summary: UIInput.setSubmittedValue() cause recursive call when calling getSubmittedValue() on Debug Key: MYFACES-3820 URL: https://issues.apache.org/jira/browse/MYFACES-3820 Project: MyFaces Core Issue Type: Bug Components: JSR-344 Reporter: Leonardo Uribe Assignee: Leonardo Uribe Under certain conditions where getSubmittedValue() is overriden a stackoverflow exception can be caused on debug mode because the code on setSubmittedValue() calls getSubmittedValue(). To prevent that there is no other choice than directly get the value from the state helper. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (MYFACES-3821) Implement UIData.setDataModel(...)
Leonardo Uribe created MYFACES-3821: --- Summary: Implement UIData.setDataModel(...) Key: MYFACES-3821 URL: https://issues.apache.org/jira/browse/MYFACES-3821 Project: MyFaces Core Issue Type: Bug Components: JSR-344 Reporter: Leonardo Uribe Assignee: Leonardo Uribe By historical reasons, UIData.setDataModel(...) throws UnsupportedOperationException. The reason is the implementation done in MyFaces does not requires it, but I have found some old code that uses it. To make MyFaces compatible with that code, the solution is just provide an implementation, even if it is not called from the default implementation. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (MYFACES-3821) Implement UIData.setDataModel(...)
[ https://issues.apache.org/jira/browse/MYFACES-3821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe resolved MYFACES-3821. - Resolution: Fixed Fix Version/s: 2.2.0 Implement UIData.setDataModel(...) -- Key: MYFACES-3821 URL: https://issues.apache.org/jira/browse/MYFACES-3821 Project: MyFaces Core Issue Type: Bug Components: JSR-344 Reporter: Leonardo Uribe Assignee: Leonardo Uribe Fix For: 2.2.0 By historical reasons, UIData.setDataModel(...) throws UnsupportedOperationException. The reason is the implementation done in MyFaces does not requires it, but I have found some old code that uses it. To make MyFaces compatible with that code, the solution is just provide an implementation, even if it is not called from the default implementation. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (MYFACES-3815) Lazy instantiation of Renderer classes
[ https://issues.apache.org/jira/browse/MYFACES-3815?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe resolved MYFACES-3815. - Resolution: Fixed Fix Version/s: 2.2.0 Lazy instantiation of Renderer classes -- Key: MYFACES-3815 URL: https://issues.apache.org/jira/browse/MYFACES-3815 Project: MyFaces Core Issue Type: Improvement Components: JSR-344 Reporter: Leonardo Uribe Assignee: Leonardo Uribe Fix For: 2.2.0 The initialization algorithm create all Renderer instances at startup time. The side effect is a lot of classes are loaded into permgen memory without need. With a clever trick we can avoid that, providing a custom interfaces LazyRenderKit and making html basic renderkit implements it. Then, in the init code we check for that interface and if is present, we use it to register the Renderer in a lazy way, otherwise we use the standard form. Add the required method to RenderKit looks like a good idea for include it in the spec. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (MYFACES-3820) UIInput.setSubmittedValue() cause recursive call when calling getSubmittedValue() on Debug
[ https://issues.apache.org/jira/browse/MYFACES-3820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe resolved MYFACES-3820. - Resolution: Fixed UIInput.setSubmittedValue() cause recursive call when calling getSubmittedValue() on Debug -- Key: MYFACES-3820 URL: https://issues.apache.org/jira/browse/MYFACES-3820 Project: MyFaces Core Issue Type: Bug Components: JSR-344 Reporter: Leonardo Uribe Assignee: Leonardo Uribe Fix For: 2.2.0 Under certain conditions where getSubmittedValue() is overriden a stackoverflow exception can be caused on debug mode because the code on setSubmittedValue() calls getSubmittedValue(). To prevent that there is no other choice than directly get the value from the state helper. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (MYFACES-3809) Add http://java.sun.com/jstl/core as a valid namespace for c jstl library in facelets
[ https://issues.apache.org/jira/browse/MYFACES-3809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe resolved MYFACES-3809. - Resolution: Fixed Fix Version/s: 2.2.0 Add http://java.sun.com/jstl/core as a valid namespace for c jstl library in facelets --- Key: MYFACES-3809 URL: https://issues.apache.org/jira/browse/MYFACES-3809 Project: MyFaces Core Issue Type: Task Components: JSR-344 Reporter: Leonardo Uribe Assignee: Leonardo Uribe Fix For: 2.2.0 This namespace was used in the early stages of JSF 2.0 development, but later it was fixed to use the same syntax for jsp. But some applications still uses the old syntax and it is too hard to fix hundreds of files using this namespace, so in JSF 2.2 it was decided to add this namespace as an alternative synonym. I discover this one trying to run the compatibility test against the latest snapshot. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (MYFACES-3810) Add compatibility mode for facelets 1.1.x behavior
[ https://issues.apache.org/jira/browse/MYFACES-3810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe resolved MYFACES-3810. - Resolution: Fixed Add compatibility mode for facelets 1.1.x behavior -- Key: MYFACES-3810 URL: https://issues.apache.org/jira/browse/MYFACES-3810 Project: MyFaces Core Issue Type: Task Components: JSR-344 Reporter: Leonardo Uribe Assignee: Leonardo Uribe Fix For: 2.2.0 Some big improvements and fixes has been done over the time in MyFaces 2.0.x / 2.1.x . But on the way some changes were done over some tags like: - c:set - ui:param - user custom tag handlers And others. See this issues: - MYFACES-3169 - MYFACES-2753 - MYFACES-2293 The current changes are completely justified and there is no turning back. These changes are very important to allow techniques like EL expression caching to work correctly. But it is also true that Mojarra still has the old behavior, and there are still web applications out there that relies on that behavior. Users trying to migrate from Mojarra to MyFaces usually found this problem. The proposal for this issue is create a web config param called org.apache.myfaces.STRICT_JSF_2_FACELETS_COMPATIBILITY by default false that when is enabled, the old way to do things is activated. Legacy versions of c:set, uiparam and user tag handler are activated. The aim is just provide a workaround for those cases and incentive users to change their application code to a more standard and stable form. -- This message was sent by Atlassian JIRA (v6.1#6144)
Re: [VOTE] Release of Trinidad Maven Plugins 2.0.8
Hey Scott -
Great, thanks for tracking this down. +1 for me then.
Andy
On Wed, Nov 6, 2013 at 12:55 PM, Scott O'Bryan darkar...@gmail.com wrote:
I'm changing my vote to +1. I was able to fix this issue in the trinidad
poms by adding:
dependencies
dependency
groupIdorg.apache.myfaces.trinidad/groupId
artifactIdtrinidad-api/artifactId
version${project.version}/version
/dependency
/dependencies
To the maven-faces plugin definition in trinidad-impl. So I'll handle
the ticket under trinidad and make sure its part of the next release. The
key was found in the maven class loading guide:
http://maven.apache.org/guides/mini/guide-maven-classloading.html
I noticed that the error was being issued in the impl package which should
have had access to the api. But the dependencies are only explicitly
available to the javacc plugin or can be referenced manually by the mojo.
Our mojo doesn't handle dependencies, so the configuration is necessary.
Might be nice to add it at some point though.
Andy, does this work for you?
--
Scott O'Bryan
On November 6, 2013 at 8:32:00 AM, Scott O'Bryan
(darkar...@gmail.com//darkar...@gmail.com)
wrote:
Andy,
Yeah, I was seeing this too. I was trying to track this as part of my
work for the next Trinidad release, but I think your right. This may be
handled better in the plugin. At the very least we should evaluate it.
What's happening here is a new check was added to test if a class for an
attribute happens to be an enumeration. In the case where we get the
error, DateListProvider hasn't been built yet since the plugins generate
the source BEFORE the plugins are built.
I'm going to generate a JIRA ticket and I for one think we need to fix
this issue before releasing the plugins. As such. my vote is a -1 pending
this issue.
--
Scott O'Bryan
On November 6, 2013 at 7:42:03 AM, Andy Schwartz (
andy.g.schwa...@gmail.com //andy.g.schwa...@gmail.com) wrote:
Hey Scott -
I attempted to do a clean Trinidad build against the new plugins. I
happened to notice this exception during the build:
[INFO] --- maven-faces-plugin:2.0.8:generate-jsp-taglibs (default) @
trinidad-impl ---
[INFO] ClassNotFound error resolving type
org.apache.myfaces.trinidad.model.DateListProvider
java.lang.ClassNotFoundException:
org.apache.myfaces.trinidad.model.DateListProvider
at
org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:50)
at
org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:244)
at
org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:230)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:169)
at
org.apache.myfaces.trinidadbuild.plugin.faces.util.ClassLoaderUtils.loadClass(ClassLoaderUtils.java:86)
at
org.apache.myfaces.trinidadbuild.plugin.faces.util.ClassLoaderUtils.loadClass(ClassLoaderUtils.java:47)
at
org.apache.myfaces.trinidadbuild.plugin.faces.generator.taglib.AbstractTagGenerator.resolveType(AbstractTagGenerator.java:247)
at
org.apache.myfaces.trinidadbuild.plugin.faces.generator.taglib.TrinidadValidatorTagGenerator.writeSetProperty(TrinidadValidatorTagGenerator.java:115)
at
org.apache.myfaces.trinidadbuild.plugin.faces.generator.taglib.AbstractValidatorTagGenerator.writeSetProperties(AbstractValidatorTagGenerator.java:185)
at
org.apache.myfaces.trinidadbuild.plugin.faces.generator.taglib.AbstractValidatorTagGenerator.generateTagHandler(AbstractValidatorTagGenerator.java:62)
at
org.apache.myfaces.trinidadbuild.plugin.faces.GenerateJspTaglibsMojo._generateTagHandlers(GenerateJspTaglibsMojo.java:794)
at
org.apache.myfaces.trinidadbuild.plugin.faces.GenerateJspTaglibsMojo.execute(GenerateJspTaglibsMojo.java:104)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
Re: [VOTE] Release of Trinidad Maven Plugins 2.0.8
+1 for me as well. Presumably we won't run into this problem later since the
tags are generated in impl and Enums showing up in their api should be in the
api package. We could have this problem if we added enum support to
components, but the component generation has access to the component metadata,
which knows that this is an enum case.
-- Blake Sullivan
On Nov 6, 2013, at 1:35 PM, Andy Schwartz wrote:
Hey Scott -
Great, thanks for tracking this down. +1 for me then.
Andy
On Wed, Nov 6, 2013 at 12:55 PM, Scott O'Bryan darkar...@gmail.com wrote:
I'm changing my vote to +1. I was able to fix this issue in the trinidad
poms by adding:
dependencies
dependency
groupIdorg.apache.myfaces.trinidad/groupId
artifactIdtrinidad-api/artifactId
version${project.version}/version
/dependency
/dependencies
To the maven-faces plugin definition in trinidad-impl. So I'll handle the
ticket under trinidad and make sure its part of the next release. The key
was found in the maven class loading guide:
http://maven.apache.org/guides/mini/guide-maven-classloading.html
I noticed that the error was being issued in the impl package which should
have had access to the api. But the dependencies are only explicitly
available to the javacc plugin or can be referenced manually by the mojo.
Our mojo doesn't handle dependencies, so the configuration is necessary.
Might be nice to add it at some point though.
Andy, does this work for you?
--
Scott O'Bryan
On November 6, 2013 at 8:32:00 AM, Scott O'Bryan (darkar...@gmail.com) wrote:
Andy,
Yeah, I was seeing this too. I was trying to track this as part of my work
for the next Trinidad release, but I think your right. This may be handled
better in the plugin. At the very least we should evaluate it. What's
happening here is a new check was added to test if a class for an attribute
happens to be an enumeration. In the case where we get the error,
DateListProvider hasn't been built yet since the plugins generate the source
BEFORE the plugins are built.
I'm going to generate a JIRA ticket and I for one think we need to fix this
issue before releasing the plugins. As such. my vote is a -1 pending this
issue.
--
Scott O'Bryan
On November 6, 2013 at 7:42:03 AM, Andy Schwartz (andy.g.schwa...@gmail.com)
wrote:
Hey Scott -
I attempted to do a clean Trinidad build against the new plugins. I
happened to notice this exception during the build:
[INFO] --- maven-faces-plugin:2.0.8:generate-jsp-taglibs (default) @
trinidad-impl ---
[INFO] ClassNotFound error resolving type
org.apache.myfaces.trinidad.model.DateListProvider
java.lang.ClassNotFoundException:
org.apache.myfaces.trinidad.model.DateListProvider
at
org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:50)
at
org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:244)
at
org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:230)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:169)
at
org.apache.myfaces.trinidadbuild.plugin.faces.util.ClassLoaderUtils.loadClass(ClassLoaderUtils.java:86)
at
org.apache.myfaces.trinidadbuild.plugin.faces.util.ClassLoaderUtils.loadClass(ClassLoaderUtils.java:47)
at
org.apache.myfaces.trinidadbuild.plugin.faces.generator.taglib.AbstractTagGenerator.resolveType(AbstractTagGenerator.java:247)
at
org.apache.myfaces.trinidadbuild.plugin.faces.generator.taglib.TrinidadValidatorTagGenerator.writeSetProperty(TrinidadValidatorTagGenerator.java:115)
at
org.apache.myfaces.trinidadbuild.plugin.faces.generator.taglib.AbstractValidatorTagGenerator.writeSetProperties(AbstractValidatorTagGenerator.java:185)
at
org.apache.myfaces.trinidadbuild.plugin.faces.generator.taglib.AbstractValidatorTagGenerator.generateTagHandler(AbstractValidatorTagGenerator.java:62)
at
org.apache.myfaces.trinidadbuild.plugin.faces.GenerateJspTaglibsMojo._generateTagHandlers(GenerateJspTaglibsMojo.java:794)
at
org.apache.myfaces.trinidadbuild.plugin.faces.GenerateJspTaglibsMojo.execute(GenerateJspTaglibsMojo.java:104)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
Re: [VOTE] Release of Trinidad Maven Plugins 2.0.8
Thanks for the input guys. Any other votes? I'll likely try to close this
later this evening.
--
Scott O'Bryan
On November 6, 2013 at 2:43:33 PM, Blake Sullivan (blake.sulli...@oracle.com)
wrote:
+1 for me as well. Presumably we won't run into this problem later since the
tags are generated in impl and Enums showing up in their api should be in the
api package. We could have this problem if we added enum support to
components, but the component generation has access to the component metadata,
which knows that this is an enum case.
-- Blake Sullivan
On Nov 6, 2013, at 1:35 PM, Andy Schwartz wrote:
Hey Scott -
Great, thanks for tracking this down. +1 for me then.
Andy
On Wed, Nov 6, 2013 at 12:55 PM, Scott O'Bryan darkar...@gmail.com wrote:
I'm changing my vote to +1. I was able to fix this issue in the trinidad poms
by adding:
dependencies
dependency
groupIdorg.apache.myfaces.trinidad/groupId
artifactIdtrinidad-api/artifactId
version${project.version}/version
/dependency
/dependencies
To the maven-faces plugin definition in trinidad-impl. So I'll handle the
ticket under trinidad and make sure its part of the next release. The key was
found in the maven class loading guide:
http://maven.apache.org/guides/mini/guide-maven-classloading.html
I noticed that the error was being issued in the impl package which should have
had access to the api. But the dependencies are only explicitly available to
the javacc plugin or can be referenced manually by the mojo. Our mojo doesn't
handle dependencies, so the configuration is necessary. Might be nice to add
it at some point though.
Andy, does this work for you?
--
Scott O'Bryan
On November 6, 2013 at 8:32:00 AM, Scott O'Bryan (darkar...@gmail.com) wrote:
Andy,
Yeah, I was seeing this too. I was trying to track this as part of my work for
the next Trinidad release, but I think your right. This may be handled better
in the plugin. At the very least we should evaluate it. What's happening here
is a new check was added to test if a class for an attribute happens to be an
enumeration. In the case where we get the error, DateListProvider hasn't been
built yet since the plugins generate the source BEFORE the plugins are built.
I'm going to generate a JIRA ticket and I for one think we need to fix this
issue before releasing the plugins. As such. my vote is a -1 pending this
issue.
--
Scott O'Bryan
On November 6, 2013 at 7:42:03 AM, Andy Schwartz (andy.g.schwa...@gmail.com)
wrote:
Hey Scott -
I attempted to do a clean Trinidad build against the new plugins. I happened
to notice this exception during the build:
[INFO] --- maven-faces-plugin:2.0.8:generate-jsp-taglibs (default) @
trinidad-impl ---
[INFO] ClassNotFound error resolving type
org.apache.myfaces.trinidad.model.DateListProvider
java.lang.ClassNotFoundException:
org.apache.myfaces.trinidad.model.DateListProvider
at
org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:50)
at
org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:244)
at
org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:230)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:169)
at
org.apache.myfaces.trinidadbuild.plugin.faces.util.ClassLoaderUtils.loadClass(ClassLoaderUtils.java:86)
at
org.apache.myfaces.trinidadbuild.plugin.faces.util.ClassLoaderUtils.loadClass(ClassLoaderUtils.java:47)
at
org.apache.myfaces.trinidadbuild.plugin.faces.generator.taglib.AbstractTagGenerator.resolveType(AbstractTagGenerator.java:247)
at
org.apache.myfaces.trinidadbuild.plugin.faces.generator.taglib.TrinidadValidatorTagGenerator.writeSetProperty(TrinidadValidatorTagGenerator.java:115)
at
org.apache.myfaces.trinidadbuild.plugin.faces.generator.taglib.AbstractValidatorTagGenerator.writeSetProperties(AbstractValidatorTagGenerator.java:185)
at
org.apache.myfaces.trinidadbuild.plugin.faces.generator.taglib.AbstractValidatorTagGenerator.generateTagHandler(AbstractValidatorTagGenerator.java:62)
at
org.apache.myfaces.trinidadbuild.plugin.faces.GenerateJspTaglibsMojo._generateTagHandlers(GenerateJspTaglibsMojo.java:794)
at
org.apache.myfaces.trinidadbuild.plugin.faces.GenerateJspTaglibsMojo.execute(GenerateJspTaglibsMojo.java:104)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at
[RESULT] [VOTE] Release of Trinidad Maven Plugins 2.0.8
This vote is now closed and has passed. We have 4 binding +1 votes: Blake Sullivan Andy Schwartz Max Starets Scott O'Bryan Thanks to everyone who voted, I'll prepare the artifacts and the announcement. -- Scott O'Bryan
Re: [VOTE] Release of Trinidad Maven Plugins 2.0.8
Thanks everyone. The vote is now closed.
--
Scott O'Bryan
On November 6, 2013 at 3:46:39 PM, Max Starets (max.star...@oracle.com) wrote:
+1
Max
On 11/6/2013 5:42 PM, Scott O'Bryan wrote:
Thanks for the input guys. Any other votes? I'll likely try to close this
later this evening.
--
Scott O'Bryan
On November 6, 2013 at 2:43:33 PM, Blake Sullivan (blake.sulli...@oracle.com)
wrote:
+1 for me as well. Presumably we won't run into this problem later since the
tags are generated in impl and Enums showing up in their api should be in the
api package. We could have this problem if we added enum support to
components, but the component generation has access to the component metadata,
which knows that this is an enum case.
-- Blake Sullivan
On Nov 6, 2013, at 1:35 PM, Andy Schwartz wrote:
Hey Scott -
Great, thanks for tracking this down. +1 for me then.
Andy
On Wed, Nov 6, 2013 at 12:55 PM, Scott O'Bryan darkar...@gmail.com wrote:
I'm changing my vote to +1. I was able to fix this issue in the trinidad poms
by adding:
dependencies
dependency
groupIdorg.apache.myfaces.trinidad/groupId
artifactIdtrinidad-api/artifactId
version${project.version}/version
/dependency
/dependencies
To the maven-faces plugin definition in trinidad-impl. So I'll handle the
ticket under trinidad and make sure its part of the next release. The key was
found in the maven class loading guide:
http://maven.apache.org/guides/mini/guide-maven-classloading.html
I noticed that the error was being issued in the impl package which should have
had access to the api. But the dependencies are only explicitly available to
the javacc plugin or can be referenced manually by the mojo. Our mojo doesn't
handle dependencies, so the configuration is necessary. Might be nice to add
it at some point though.
Andy, does this work for you?
--
Scott O'Bryan
On November 6, 2013 at 8:32:00 AM, Scott O'Bryan (darkar...@gmail.com) wrote:
Andy,
Yeah, I was seeing this too. I was trying to track this as part of my work for
the next Trinidad release, but I think your right. This may be handled better
in the plugin. At the very least we should evaluate it. What's happening here
is a new check was added to test if a class for an attribute happens to be an
enumeration. In the case where we get the error, DateListProvider hasn't been
built yet since the plugins generate the source BEFORE the plugins are built.
I'm going to generate a JIRA ticket and I for one think we need to fix this
issue before releasing the plugins. As such. my vote is a -1 pending this
issue.
--
Scott O'Bryan
On November 6, 2013 at 7:42:03 AM, Andy Schwartz (andy.g.schwa...@gmail.com)
wrote:
Hey Scott -
I attempted to do a clean Trinidad build against the new plugins. I happened
to notice this exception during the build:
[INFO] --- maven-faces-plugin:2.0.8:generate-jsp-taglibs (default) @
trinidad-impl ---
[INFO] ClassNotFound error resolving type
org.apache.myfaces.trinidad.model.DateListProvider
java.lang.ClassNotFoundException:
org.apache.myfaces.trinidad.model.DateListProvider
at
org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:50)
at
org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:244)
at
org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:230)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:169)
at
org.apache.myfaces.trinidadbuild.plugin.faces.util.ClassLoaderUtils.loadClass(ClassLoaderUtils.java:86)
at
org.apache.myfaces.trinidadbuild.plugin.faces.util.ClassLoaderUtils.loadClass(ClassLoaderUtils.java:47)
at
org.apache.myfaces.trinidadbuild.plugin.faces.generator.taglib.AbstractTagGenerator.resolveType(AbstractTagGenerator.java:247)
at
org.apache.myfaces.trinidadbuild.plugin.faces.generator.taglib.TrinidadValidatorTagGenerator.writeSetProperty(TrinidadValidatorTagGenerator.java:115)
at
org.apache.myfaces.trinidadbuild.plugin.faces.generator.taglib.AbstractValidatorTagGenerator.writeSetProperties(AbstractValidatorTagGenerator.java:185)
at
org.apache.myfaces.trinidadbuild.plugin.faces.generator.taglib.AbstractValidatorTagGenerator.generateTagHandler(AbstractValidatorTagGenerator.java:62)
at
org.apache.myfaces.trinidadbuild.plugin.faces.GenerateJspTaglibsMojo._generateTagHandlers(GenerateJspTaglibsMojo.java:794)
at
org.apache.myfaces.trinidadbuild.plugin.faces.GenerateJspTaglibsMojo.execute(GenerateJspTaglibsMojo.java:104)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
