Leonardo, Thx for your input.
It is indeed probably better to just copy the excluded.properties file to the test20 codebase then adding a lot of not very readable stuff in the pom.xml. The contents of the file will probably never change. About the FactoryFinderProviderTest, i'll have a look at it to use the TestPerClassLoaderRunner. It should be rather easy. Regards Rudy. On 24 May 2011 12:23, Leonardo Uribe <lu4...@gmail.com> wrote: > Hi Rudy > > I don't think it could be any side effect caused by the change. The > working setup in test20 just copy all java source files from test12 > that does not have an alternate in test20. So I think the best in this > case is just copy excluded.properties to test20 codebase. Feel free to > do the change. > > There is one test case that requires to run with a isolate classloader > in myfaces core 2.0.x, but right now it uses another trick. It could > be good to use TestPerClassLoaderRunner, but I don't have idea how to > do it. See org.apache.myfaces.spi.FactoryFinderProviderTest. I use > this setup on myfaces-impl pom.xml > > <execution> > <id>isolateCLTests</id> > <phase>test</phase> > <goals> > <goal>test</goal> > </goals> > <configuration> > <forkMode>always</forkMode> > > <testNGArtifactName>none:none</testNGArtifactName> > <includes> > > <include>**/FactoryFinderProviderTest*</include> > </includes> > <excludes> > > <exclude>**/JspStateManagerImplTest*</exclude> > > <exclude>**/DefaultViewHandlerSupportTest*</exclude> > <exclude>**/ApplicationImplTest*</exclude> > </excludes> > </configuration> > </execution> > > look the <forkMode> entry. I would like to use > TestPerClassLoaderRunner in this case. If I run this test with the > other ones (doing mvn install over impl module) this exception is > thrown: > > testGetFactory(org.apache.myfaces.spi.FactoryFinderProviderTest) Time > elapsed: 0.015 sec <<< ERROR! > java.lang.IllegalStateException: No Factories configured for this > Application. This happens if the faces-initialization does not work at > all - make sure that you properly include all configuration settings > necessary for a basic faces application and that all the necessary > libs are included. Also check the logging output of your web > application and your container for any exceptions! > If you did that and find nothing, the mistake might be due to the fact > that you use some special web-containers which do not support > registering context-listeners via TLD files and a context listener is > not setup in your web.xml. > A typical config looks like this; > <listener> > > > <listener-class>org.apache.myfaces.webapp.StartupServletContextListener</listener-class> > </listener> > > at javax.faces.FactoryFinder._getFactory(FactoryFinder.java:242) > at javax.faces.FactoryFinder.getFactory(FactoryFinder.java:191) > at > org.apache.myfaces.spi.FactoryFinderProviderTest.testGetFactory(FactoryFinderProviderTest.java:55) > 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.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44) > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41) > at > org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) > at > org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) > at > org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:76) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184) > at org.junit.runners.ParentRunner.run(ParentRunner.java:236) > at > org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:59) > at > org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:115) > at > org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:102) > at org.apache.maven.surefire.Surefire.run(Surefire.java:180) > 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.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:350) > at > org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1021) > > but running it with eclipse no errors are shown because it that case > it runs in a isolate classloader. It is a nice example to check if the > feature is working well or not. > > regards, > > Leonardo Uribe > > 2011/5/23 Rudy De Busscher <rdebussc...@gmail.com>: > > @All, > > > > Matt Benson identified that the file excluded.properties, required for > the > > TestPerClassLoaderRunner to function, isn't packaged in the test20.jar. > > > > I verified his fix to the pom.xml file by copying the test cases we have > for > > TestPerClassLoaderRunner from test12 to test20. (see the second > attachment > > to the issue) > > > > As far as I can see, the test20 artifact is only used in the MyFaces Core > > (https://svn.apache.org/repos/asf/myfaces/core/trunk) and it still > builds > > with the changes. > > > > I also verified that the changes to the POM results in only one change to > > the jar, the addition of the excluded.properties file. > > > > > > The reason for this message is that changes to the POM file could have > some > > unexpected results in other projects. So I would like to ask if someone > > else also can have a look at the proposed chnges and the possible impact. > > (so that I'm sure I didn't missed something) > > > > > > I'll commit the proposed patch by the end of the week if no one has any > > objections. > > > > Regards > > Rudy. > > >
