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 <[email protected]>:
> @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.
>

Reply via email to