You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Rudy De Busscher <rd...@gmail.com> on 2011/05/23 12:24:19 UTC
[Test] MYFACESTEST50 : Review
@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.
Re: [Test] MYFACESTEST50 : Review
Posted by Rudy De Busscher <rd...@gmail.com>.
hi All,
There was a small piece missing in the TestPerClassLoader (see
https://issues.apache.org/jira/browse/MYFACESTEST-54) to make it completely
functional for MyFaces core.
In attachment the patch for MyFaces core to use the TestPerClassLoader for
the test class FactoryFinderProviderTest if you like to test it your self.
regards
Rudy.
On 26 May 2011 15:43, Rudy De Busscher <rd...@gmail.com> wrote:
> 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 <lu...@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 <rd...@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.
>> >
>>
>
>
Re: [Test] MYFACESTEST50 : Review
Posted by Rudy De Busscher <rd...@gmail.com>.
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 <lu...@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 <rd...@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.
> >
>
Re: [Test] MYFACESTEST50 : Review
Posted by Leonardo Uribe <lu...@gmail.com>.
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 <rd...@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.
>