You may be right but AS 7 only looks for it in META-INF/MANIFEST.MF. If that is wrong we should fix our end

On 15 Feb 2011, at 17:58, Andrew Lee Rubinger wrote: > Hey Kabir: > > Hmm, I'm not sure which, then, is the correct location. Have a look at: > > https://issues.jboss.org/browse/SHRINKWRAP-241 > > My comment on 09/Jan/11 notes the mappings we've chosen; for a WebArchive the manifest location is: > > /WEB-INF/classes/META-INF > > Disagree? > > I'm not finding docs that really support either position specifically for MANIFEST.MF in web archives. persistence.xml for instance goes in WEB-INF/classes/META-INF. > > S, > ALR > > On 02/15/2011 06:50 AM, Kabir Khan wrote: >> Hey Andrew, >> >> It seems that WebArchive.setManifest() adds the Manifest to WEB-INF/classes/META-INF/MANIFEST.MF instead of /META-INF/MANIFEST.MF. >> >> Begin forwarded message: >> >>> From: Kabir Khan&lt;kabir.khan(a)jboss.com&gt; >>> Date: 15 February 2011 11:49:22 GMT >>> To: Stan Silvert&lt;ssilvert(a)redhat.com&gt; >>> Subject: Re: [jboss-as7-dev] testsuite >>> >>> This commit fixes it so that the manifest.mf containing the typical arquillian module dependencies goes in the right place (/META-INF/MANIFEST.MF): >>> https://github.com/kabir/jboss-as/commit/a14f3013d68ab14e85cb4f17cf30af08... >>> >>> I still get this on the server, which is probably ok: >>> 10:54:13,415 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/test]] (pool-2-thread-3) Servlet /test threw load() exception: java.lang.IllegalStateException: Application was not properly initialized at startup, could not find Factory: javax.faces.context.FacesContextFactory >>> at javax.faces.FactoryFinder$FactoryManager.getFactory(FactoryFinder.java:804) [jsf-api-2.0.2-FCS.jar:2.0.2-FCS] >>> at javax.faces.FactoryFinder.getFactory(FactoryFinder.java:306) [jsf-api-2.0.2-FCS.jar:2.0.2-FCS] >>> at javax.faces.webapp.FacesServlet.init(FacesServlet.java:166) [jsf-api-2.0.2-FCS.jar:2.0.2-FCS] >>> at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1208) [jbossweb-7.0.0.Beta1.jar:7.0.0.Alpha2-SNAPSHOT] >>> >>> And this now in the test report (i.e. shrinkwrap's Asset is now visible): >>> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 7.383 sec<<< FAILURE! >>> testInitialPage(org.jboss.jsfunit.example.hellojsf.HelloJSFTest) Time elapsed: 0.263 sec<<< ERROR! >>> java.lang.NoClassDefFoundError: org/jboss/jsfunit/jsfsession/JSFServerSession >>> at java.lang.Class.getDeclaredMethods0(Native Method) >>> at java.lang.Class.privateGetDeclaredMethods(Class.java:2427) >>> at java.lang.Class.getDeclaredMethods(Class.java:1791) >>> at org.junit.runners.model.TestClass.<init>(TestClass.java:38) >>> at org.junit.runners.ParentRunner.<init>(ParentRunner.java:65) >>> at org.junit.runners.BlockJUnit4ClassRunner.<init>(BlockJUnit4ClassRunner.java:59) >>> at org.jboss.arquillian.junit.Arquillian.<init>(Arquillian.java:74) >>> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) >>> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) >>> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) >>> at java.lang.reflect.Constructor.newInstance(Constructor.java:513) >>> at org.junit.internal.builders.AnnotatedBuilder.buildRunner(AnnotatedBuilder.java:31) >>> at org.junit.internal.builders.AnnotatedBuilder.runnerForClass(AnnotatedBuilder.java:24) >>> at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:57) >>> at org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:29) >>> at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:57) >>> at org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:24) >>> >>> So you'll need a module in AS for jsf if one isn't there already. Then you need to either include the dependency in a manifest.mf provided to your test archive, such as: >>> ---- >>> Manifest-Version: 1.0 >>> Dependencies: my.jsf.module >>> ---- >>> The demos contain more examples of manifests. OR if you determine early that this is a JSF deployment, you will probably want to always add the jsf dependencies in a deployment unit processor. See ManagedBeanDependencyProcessor which adds a dependency on the javaee.api for all managed beans deployments. >>> >>> >>> >>> On 15 Feb 2011, at 11:03, Kabir Khan wrote: >>> >>>> I think there is a problem with how the manifest containing the additional deps gets added to the war by ModuleApplicationProcessor. I added some debugging to make sure that the jboss arquillian processors get invoked >>>> >>>> The raw jar >>>> test.war: >>>> /WEB-INF/ >>>> /WEB-INF/faces-config.xml >>>> /WEB-INF/beans.xml >>>> /WEB-INF/web.xml >>>> /WEB-INF/classes/ >>>> /WEB-INF/classes/org/ >>>> /WEB-INF/classes/org/jboss/ >>>> /WEB-INF/classes/org/jboss/jsfunit/ >>>> /WEB-INF/classes/org/jboss/jsfunit/example/ >>>> /WEB-INF/classes/org/jboss/jsfunit/example/hellojsf/ >>>> /WEB-INF/classes/org/jboss/jsfunit/example/hellojsf/HelloJSFTest.class >>>> /WEB-INF/classes/META-INF/ >>>> /WEB-INF/classes/META-INF/beans.xml >>>> /index.xhtml >>>> >>>> After ModuleApplicationArchiveProcessor has added the deps >>>> test.war: >>>> /WEB-INF/ >>>> /WEB-INF/faces-config.xml >>>> /WEB-INF/beans.xml >>>> /WEB-INF/web.xml >>>> /WEB-INF/classes/ >>>> /WEB-INF/classes/org/ >>>> /WEB-INF/classes/org/jboss/ >>>> /WEB-INF/classes/org/jboss/jsfunit/ >>>> /WEB-INF/classes/org/jboss/jsfunit/example/ >>>> /WEB-INF/classes/org/jboss/jsfunit/example/hellojsf/ >>>> /WEB-INF/classes/org/jboss/jsfunit/example/hellojsf/HelloJSFTest.class >>>> /WEB-INF/classes/org/jboss/jsfunit/cdi/ >>>> /WEB-INF/classes/org/jboss/jsfunit/cdi/FormAuthentication.class >>>> /WEB-INF/classes/org/jboss/jsfunit/cdi/Browser.class >>>> /WEB-INF/classes/org/jboss/jsfunit/cdi/InitialRequest.class >>>> /WEB-INF/classes/org/jboss/jsfunit/cdi/InitialPage.class >>>> /WEB-INF/classes/org/jboss/jsfunit/cdi/BrowserVersion.class >>>> /WEB-INF/classes/org/jboss/jsfunit/cdi/JSFSessionFactory.class >>>> /WEB-INF/classes/org/jboss/jsfunit/cdi/Cookies.class >>>> /WEB-INF/classes/org/jboss/jsfunit/cdi/Proxy.class >>>> /WEB-INF/classes/org/jboss/jsfunit/cdi/BasicAuthentication.class >>>> /WEB-INF/classes/META-INF/ >>>> /WEB-INF/classes/META-INF/MANIFEST.MF<<<<<<<<< I think this should be in /META-INF/MANIFEST.MF >>>> /WEB-INF/classes/META-INF/beans.xml >>>> /index.xhtml >>>> >>>> I'll try to make it appear in the proper place >>>> >>>> >>>> On 14 Feb 2011, at 23:35, ssilvert(a)redhat.com wrote: >>>> >>>>> Thanks for your help. It's really strange. >>>>> >>>>> Among other things, if you open up the war you will see that the only classes under WEB-INF are my test class and some JSFUnit CDI classes that JSFUnit puts there with an ApplicationArchiveProcessor. >>>>> >>>>> >>>>> Quoting Kabir Khan&lt;kabir.khan(a)jboss.com&gt;: >>>>> >>>>>> I've had a quick look and can't see anything obvious, I'll take proper look tomorrow >>>>>> On 14 Feb 2011, at 20:38, ssilvert(a)redhat.com wrote: >>>>>> >>>>>>> I'm creating a WebArchive. This test runs fine when it deploys against AS6. Can you take a quick look at it? >>>>>>> >>>>>>> * svn checkout http://anonsvn.jboss.org/repos/jsfunit/trunk/gettingstarted >>>>>>> * Start AS7 >>>>>>> * mvn -Pjbossas-remote-7 test >>>>>>> >>>>>>> The test won't actually pass because JSF is not there yet. But it should still deploy and run. >>>>>>> >>>>>>> Stan >>>>>>> >>>>>>> Quoting Kabir Khan&lt;kabir.khan(a)jboss.com&gt;: >>>>>>> >>>>>>>> >>>>>>>> On 14 Feb 2011, at 18:44, ssilvert(a)redhat.com wrote: >>>>>>>> >>>>>>>>> So let me ask it this way. What's the easiest way to get an >>>>>>>>> Arquillian test running with AS7? It looks like the answer might be >>>>>>>>> to use remote. I almost got that running with >>>>>>>>> jboss-as-arquillian-container-remote. Am I required to use the forked >>>>>>>>> Surefire with remote? >>>>>>>> >>>>>>>> The forked surefire plugin (which is not really being used yet) is not required for remote. To do an embedded test, simply copy what the smoke tests do. >>>>>>>> >>>>>>>>> >>>>>>>>> Without it, I got this message in the AS7 console: >>>>>>>>> >>>>>>>>> 13:06:33,072 INFO [org.jboss.as.server.deployment] (pool-3-thread-4) >>>>>>>>> Content wi >>>>>>>>> th name test.war added at location >>>>>>>>> C:\projects\as7trunk\jboss-as\build\target\jb >>>>>>>>> oss-7.0.0.Alpha2\standalone\data\content\24\5a3cbc919f50f4d7384197c5755fd7fb5c83 >>>>>>>>> 9a\content >>>>>>>>> >>>>>>>>> But there were two strange things. First, I got this in my test output: >>>>>>>>> ------------------------------------------------------------------------------- >>>>>>>>> Test set: org.jboss.jsfunit.example.hellojsf.HelloJSFTest >>>>>>>>> ------------------------------------------------------------------------------- >>>>>>>>> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 13.846 >>>>>>>>> sec<<< FAILURE! >>>>>>>>> testInitialPage(org.jboss.jsfunit.example.hellojsf.HelloJSFTest) Time >>>>>>>>> elapsed: 6.089 sec<<< ERROR! >>>>>>>>> java.lang.ClassNotFoundException: >>>>>>>>> org.jboss.jsfunit.example.hellojsf.HelloJSFTest >>>>>>>>> >>>>>>>>> I can see that the test class was indeed added to the WEB-INF/classes. >>>>>>>>> So I shouldn't get ClassNotFoundException. >>>>>>>>> >>>>>>>>> But, it looks like jboss-as-arquillian-container-remote doesn't know >>>>>>>>> I'm creating a WAR because it put all the supporting classes in the >>>>>>>>> root of my WAR instead of putting them in WEB-INF/lib or >>>>>>>>> WEB-INF/classes. >>>>>>>> >>>>>>>> Unless you tell Shrinkwrap you're creating a web archive it will create a normal jar. From WarTestCase in smoke tests: >>>>>>>> >>>>>>>> @Deployment >>>>>>>> public static Archive<?> getDeployment(){ >>>>>>>> return ShrinkWrapUtils.createWebArchive("demos/war-example.war", SimpleServlet.class.getPackage()); >>>>>>>> } >>>>>>>> >>>>>>>> public static WebArchive createWebArchive(String archiveName, Package...packages) { >>>>>>>> WebArchive archive = ShrinkWrap.create(WebArchive.class, getBaseArchiveName(archiveName)); >>>>>>>> addPackages(archive, packages); >>>>>>>> addResources(archiveName, archive); >>>>>>>> return archive; >>>>>>>> } >>>>>>>> >>>>>>>> IIRC ShrinkWrap will put things in the right place if you create a WebArchive. For all other archive types root is the default location >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>> >> _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

You may be right but AS 7 only looks for it in META-INF/MANIFEST.MF. If that is wrong we should fix our end On 15 Feb 2011, at 17:58, Andrew Lee Rubinger wrote: > Hey Kabir: > > Hmm, I'm not sure which, then, is the correct location. Have a look at: > > https://issues.jboss.org/browse/SHRINKWRAP-241 > > My comment on 09/Jan/11 notes the mappings we've chosen; for a WebArchive the manifest location is: > > /WEB-INF/classes/META-INF > > Disagree? > > I'm not finding docs that really support either position specifically for MANIFEST.MF in web archives. persistence.xml for instance goes in WEB-INF/classes/META-INF. > > S, > ALR > > On 02/15/2011 06:50 AM, Kabir Khan wrote: >> Hey Andrew, >> >> It seems that WebArchive.setManifest() adds the Manifest to WEB-INF/classes/META-INF/MANIFEST.MF instead of /META-INF/MANIFEST.MF. >> >> Begin forwarded message: >> >>> From: Kabir Khan&lt;kabir.khan(a)jboss.com&gt; >>> Date: 15 February 2011 11:49:22 GMT >>> To: Stan Silvert&lt;ssilvert(a)redhat.com&gt; >>> Subject: Re: [jboss-as7-dev] testsuite >>> >>> This commit fixes it so that the manifest.mf containing the typical arquillian module dependencies goes in the right place (/META-INF/MANIFEST.MF): >>> https://github.com/kabir/jboss-as/commit/a14f3013d68ab14e85cb4f17cf30af08... >>> >>> I still get this on the server, which is probably ok: >>> 10:54:13,415 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/test]] (pool-2-thread-3) Servlet /test threw load() exception: java.lang.IllegalStateException: Application was not properly initialized at startup, could not find Factory: javax.faces.context.FacesContextFactory >>> at javax.faces.FactoryFinder$FactoryManager.getFactory(FactoryFinder.java:804) [jsf-api-2.0.2-FCS.jar:2.0.2-FCS] >>> at javax.faces.FactoryFinder.getFactory(FactoryFinder.java:306) [jsf-api-2.0.2-FCS.jar:2.0.2-FCS] >>> at javax.faces.webapp.FacesServlet.init(FacesServlet.java:166) [jsf-api-2.0.2-FCS.jar:2.0.2-FCS] >>> at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1208) [jbossweb-7.0.0.Beta1.jar:7.0.0.Alpha2-SNAPSHOT] >>> >>> And this now in the test report (i.e. shrinkwrap's Asset is now visible): >>> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 7.383 sec<<< FAILURE! >>> testInitialPage(org.jboss.jsfunit.example.hellojsf.HelloJSFTest) Time elapsed: 0.263 sec<<< ERROR! >>> java.lang.NoClassDefFoundError: org/jboss/jsfunit/jsfsession/JSFServerSession >>> at java.lang.Class.getDeclaredMethods0(Native Method) >>> at java.lang.Class.privateGetDeclaredMethods(Class.java:2427) >>> at java.lang.Class.getDeclaredMethods(Class.java:1791) >>> at org.junit.runners.model.TestClass.<init>(TestClass.java:38) >>> at org.junit.runners.ParentRunner.<init>(ParentRunner.java:65) >>> at org.junit.runners.BlockJUnit4ClassRunner.<init>(BlockJUnit4ClassRunner.java:59) >>> at org.jboss.arquillian.junit.Arquillian.<init>(Arquillian.java:74) >>> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) >>> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) >>> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) >>> at java.lang.reflect.Constructor.newInstance(Constructor.java:513) >>> at org.junit.internal.builders.AnnotatedBuilder.buildRunner(AnnotatedBuilder.java:31) >>> at org.junit.internal.builders.AnnotatedBuilder.runnerForClass(AnnotatedBuilder.java:24) >>> at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:57) >>> at org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:29) >>> at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:57) >>> at org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:24) >>> >>> So you'll need a module in AS for jsf if one isn't there already. Then you need to either include the dependency in a manifest.mf provided to your test archive, such as: >>> ---- >>> Manifest-Version: 1.0 >>> Dependencies: my.jsf.module >>> ---- >>> The demos contain more examples of manifests. OR if you determine early that this is a JSF deployment, you will probably want to always add the jsf dependencies in a deployment unit processor. See ManagedBeanDependencyProcessor which adds a dependency on the javaee.api for all managed beans deployments. >>> >>> >>> >>> On 15 Feb 2011, at 11:03, Kabir Khan wrote: >>> >>>> I think there is a problem with how the manifest containing the additional deps gets added to the war by ModuleApplicationProcessor. I added some debugging to make sure that the jboss arquillian processors get invoked >>>> >>>> The raw jar >>>> test.war: >>>> /WEB-INF/ >>>> /WEB-INF/faces-config.xml >>>> /WEB-INF/beans.xml >>>> /WEB-INF/web.xml >>>> /WEB-INF/classes/ >>>> /WEB-INF/classes/org/ >>>> /WEB-INF/classes/org/jboss/ >>>> /WEB-INF/classes/org/jboss/jsfunit/ >>>> /WEB-INF/classes/org/jboss/jsfunit/example/ >>>> /WEB-INF/classes/org/jboss/jsfunit/example/hellojsf/ >>>> /WEB-INF/classes/org/jboss/jsfunit/example/hellojsf/HelloJSFTest.class >>>> /WEB-INF/classes/META-INF/ >>>> /WEB-INF/classes/META-INF/beans.xml >>>> /index.xhtml >>>> >>>> After ModuleApplicationArchiveProcessor has added the deps >>>> test.war: >>>> /WEB-INF/ >>>> /WEB-INF/faces-config.xml >>>> /WEB-INF/beans.xml >>>> /WEB-INF/web.xml >>>> /WEB-INF/classes/ >>>> /WEB-INF/classes/org/ >>>> /WEB-INF/classes/org/jboss/ >>>> /WEB-INF/classes/org/jboss/jsfunit/ >>>> /WEB-INF/classes/org/jboss/jsfunit/example/ >>>> /WEB-INF/classes/org/jboss/jsfunit/example/hellojsf/ >>>> /WEB-INF/classes/org/jboss/jsfunit/example/hellojsf/HelloJSFTest.class >>>> /WEB-INF/classes/org/jboss/jsfunit/cdi/ >>>> /WEB-INF/classes/org/jboss/jsfunit/cdi/FormAuthentication.class >>>> /WEB-INF/classes/org/jboss/jsfunit/cdi/Browser.class >>>> /WEB-INF/classes/org/jboss/jsfunit/cdi/InitialRequest.class >>>> /WEB-INF/classes/org/jboss/jsfunit/cdi/InitialPage.class >>>> /WEB-INF/classes/org/jboss/jsfunit/cdi/BrowserVersion.class >>>> /WEB-INF/classes/org/jboss/jsfunit/cdi/JSFSessionFactory.class >>>> /WEB-INF/classes/org/jboss/jsfunit/cdi/Cookies.class >>>> /WEB-INF/classes/org/jboss/jsfunit/cdi/Proxy.class >>>> /WEB-INF/classes/org/jboss/jsfunit/cdi/BasicAuthentication.class >>>> /WEB-INF/classes/META-INF/ >>>> /WEB-INF/classes/META-INF/MANIFEST.MF<<<<<<<<< I think this should be in /META-INF/MANIFEST.MF >>>> /WEB-INF/classes/META-INF/beans.xml >>>> /index.xhtml >>>> >>>> I'll try to make it appear in the proper place >>>> >>>> >>>> On 14 Feb 2011, at 23:35, ssilvert(a)redhat.com wrote: >>>> >>>>> Thanks for your help. It's really strange. >>>>> >>>>> Among other things, if you open up the war you will see that the only classes under WEB-INF are my test class and some JSFUnit CDI classes that JSFUnit puts there with an ApplicationArchiveProcessor. >>>>> >>>>> >>>>> Quoting Kabir Khan&lt;kabir.khan(a)jboss.com&gt;: >>>>> >>>>>> I've had a quick look and can't see anything obvious, I'll take proper look tomorrow >>>>>> On 14 Feb 2011, at 20:38, ssilvert(a)redhat.com wrote: >>>>>> >>>>>>> I'm creating a WebArchive. This test runs fine when it deploys against AS6. Can you take a quick look at it? >>>>>>> >>>>>>> * svn checkout http://anonsvn.jboss.org/repos/jsfunit/trunk/gettingstarted >>>>>>> * Start AS7 >>>>>>> * mvn -Pjbossas-remote-7 test >>>>>>> >>>>>>> The test won't actually pass because JSF is not there yet. But it should still deploy and run. >>>>>>> >>>>>>> Stan >>>>>>> >>>>>>> Quoting Kabir Khan&lt;kabir.khan(a)jboss.com&gt;: >>>>>>> >>>>>>>> >>>>>>>> On 14 Feb 2011, at 18:44, ssilvert(a)redhat.com wrote: >>>>>>>> >>>>>>>>> So let me ask it this way. What's the easiest way to get an >>>>>>>>> Arquillian test running with AS7? It looks like the answer might be >>>>>>>>> to use remote. I almost got that running with >>>>>>>>> jboss-as-arquillian-container-remote. Am I required to use the forked >>>>>>>>> Surefire with remote? >>>>>>>> >>>>>>>> The forked surefire plugin (which is not really being used yet) is not required for remote. To do an embedded test, simply copy what the smoke tests do. >>>>>>>> >>>>>>>>> >>>>>>>>> Without it, I got this message in the AS7 console: >>>>>>>>> >>>>>>>>> 13:06:33,072 INFO [org.jboss.as.server.deployment] (pool-3-thread-4) >>>>>>>>> Content wi >>>>>>>>> th name test.war added at location >>>>>>>>> C:\projects\as7trunk\jboss-as\build\target\jb >>>>>>>>> oss-7.0.0.Alpha2\standalone\data\content\24\5a3cbc919f50f4d7384197c5755fd7fb5c83 >>>>>>>>> 9a\content >>>>>>>>> >>>>>>>>> But there were two strange things. First, I got this in my test output: >>>>>>>>> ------------------------------------------------------------------------------- >>>>>>>>> Test set: org.jboss.jsfunit.example.hellojsf.HelloJSFTest >>>>>>>>> ------------------------------------------------------------------------------- >>>>>>>>> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 13.846 >>>>>>>>> sec<<< FAILURE! >>>>>>>>> testInitialPage(org.jboss.jsfunit.example.hellojsf.HelloJSFTest) Time >>>>>>>>> elapsed: 6.089 sec<<< ERROR! >>>>>>>>> java.lang.ClassNotFoundException: >>>>>>>>> org.jboss.jsfunit.example.hellojsf.HelloJSFTest >>>>>>>>> >>>>>>>>> I can see that the test class was indeed added to the WEB-INF/classes. >>>>>>>>> So I shouldn't get ClassNotFoundException. >>>>>>>>> >>>>>>>>> But, it looks like jboss-as-arquillian-container-remote doesn't know >>>>>>>>> I'm creating a WAR because it put all the supporting classes in the >>>>>>>>> root of my WAR instead of putting them in WEB-INF/lib or >>>>>>>>> WEB-INF/classes. >>>>>>>> >>>>>>>> Unless you tell Shrinkwrap you're creating a web archive it will create a normal jar. From WarTestCase in smoke tests: >>>>>>>> >>>>>>>> @Deployment >>>>>>>> public static Archive<?> getDeployment(){ >>>>>>>> return ShrinkWrapUtils.createWebArchive("demos/war-example.war", SimpleServlet.class.getPackage()); >>>>>>>> } >>>>>>>> >>>>>>>> public static WebArchive createWebArchive(String archiveName, Package...packages) { >>>>>>>> WebArchive archive = ShrinkWrap.create(WebArchive.class, getBaseArchiveName(archiveName)); >>>>>>>> addPackages(archive, packages); >>>>>>>> addResources(archiveName, archive); >>>>>>>> return archive; >>>>>>>> } >>>>>>>> >>>>>>>> IIRC ShrinkWrap will put things in the right place if you create a WebArchive. For all other archive types root is the default location >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>> >> _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

BTW the oddball JPA requirement I think was a screwup. I raised the issue on the EE EG. On 2/15/11 10:43 PM, Jason T. Greene wrote: > That's totally wrong. The specs are pretty clear that META-INF is a root > level directory under a WAR, that's where class-path, signing, and > extensions go. They also state that the web server must not treat > META-INF as a resource. > > On 2/15/11 12:01 PM, Kabir Khan wrote: >> You may be right but AS 7 only looks for it in META-INF/MANIFEST.MF. If that is wrong we should fix our end >> On 15 Feb 2011, at 17:58, Andrew Lee Rubinger wrote: >> >>> Hey Kabir: >>> >>> Hmm, I'm not sure which, then, is the correct location. Have a look at: >>> >>> https://issues.jboss.org/browse/SHRINKWRAP-241 >>> >>> My comment on 09/Jan/11 notes the mappings we've chosen; for a WebArchive the manifest location is: >>> >>> /WEB-INF/classes/META-INF >>> >>> Disagree? >>> >>> I'm not finding docs that really support either position specifically for MANIFEST.MF in web archives. persistence.xml for instance goes in WEB-INF/classes/META-INF. >>> >>> S, >>> ALR >>> >>> On 02/15/2011 06:50 AM, Kabir Khan wrote: >>>> Hey Andrew, >>>> >>>> It seems that WebArchive.setManifest() adds the Manifest to WEB-INF/classes/META-INF/MANIFEST.MF instead of /META-INF/MANIFEST.MF. >>>> >>>> Begin forwarded message: >>>> >>>>> From: Kabir Khan&lt;kabir.khan(a)jboss.com&gt; >>>>> Date: 15 February 2011 11:49:22 GMT >>>>> To: Stan Silvert&lt;ssilvert(a)redhat.com&gt; >>>>> Subject: Re: [jboss-as7-dev] testsuite >>>>> >>>>> This commit fixes it so that the manifest.mf containing the typical arquillian module dependencies goes in the right place (/META-INF/MANIFEST.MF): >>>>> https://github.com/kabir/jboss-as/commit/a14f3013d68ab14e85cb4f17cf30af08... >>>>> >>>>> I still get this on the server, which is probably ok: >>>>> 10:54:13,415 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/test]] (pool-2-thread-3) Servlet /test threw load() exception: java.lang.IllegalStateException: Application was not properly initialized at startup, could not find Factory: javax.faces.context.FacesContextFactory >>>>> at javax.faces.FactoryFinder$FactoryManager.getFactory(FactoryFinder.java:804) [jsf-api-2.0.2-FCS.jar:2.0.2-FCS] >>>>> at javax.faces.FactoryFinder.getFactory(FactoryFinder.java:306) [jsf-api-2.0.2-FCS.jar:2.0.2-FCS] >>>>> at javax.faces.webapp.FacesServlet.init(FacesServlet.java:166) [jsf-api-2.0.2-FCS.jar:2.0.2-FCS] >>>>> at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1208) [jbossweb-7.0.0.Beta1.jar:7.0.0.Alpha2-SNAPSHOT] >>>>> >>>>> And this now in the test report (i.e. shrinkwrap's Asset is now visible): >>>>> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 7.383 sec<<< FAILURE! >>>>> testInitialPage(org.jboss.jsfunit.example.hellojsf.HelloJSFTest) Time elapsed: 0.263 sec<<< ERROR! >>>>> java.lang.NoClassDefFoundError: org/jboss/jsfunit/jsfsession/JSFServerSession >>>>> at java.lang.Class.getDeclaredMethods0(Native Method) >>>>> at java.lang.Class.privateGetDeclaredMethods(Class.java:2427) >>>>> at java.lang.Class.getDeclaredMethods(Class.java:1791) >>>>> at org.junit.runners.model.TestClass.<init>(TestClass.java:38) >>>>> at org.junit.runners.ParentRunner.<init>(ParentRunner.java:65) >>>>> at org.junit.runners.BlockJUnit4ClassRunner.<init>(BlockJUnit4ClassRunner.java:59) >>>>> at org.jboss.arquillian.junit.Arquillian.<init>(Arquillian.java:74) >>>>> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) >>>>> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) >>>>> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) >>>>> at java.lang.reflect.Constructor.newInstance(Constructor.java:513) >>>>> at org.junit.internal.builders.AnnotatedBuilder.buildRunner(AnnotatedBuilder.java:31) >>>>> at org.junit.internal.builders.AnnotatedBuilder.runnerForClass(AnnotatedBuilder.java:24) >>>>> at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:57) >>>>> at org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:29) >>>>> at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:57) >>>>> at org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:24) >>>>> >>>>> So you'll need a module in AS for jsf if one isn't there already. Then you need to either include the dependency in a manifest.mf provided to your test archive, such as: >>>>> ---- >>>>> Manifest-Version: 1.0 >>>>> Dependencies: my.jsf.module >>>>> ---- >>>>> The demos contain more examples of manifests. OR if you determine early that this is a JSF deployment, you will probably want to always add the jsf dependencies in a deployment unit processor. See ManagedBeanDependencyProcessor which adds a dependency on the javaee.api for all managed beans deployments. >>>>> >>>>> >>>>> >>>>> On 15 Feb 2011, at 11:03, Kabir Khan wrote: >>>>> >>>>>> I think there is a problem with how the manifest containing the additional deps gets added to the war by ModuleApplicationProcessor. I added some debugging to make sure that the jboss arquillian processors get invoked >>>>>> >>>>>> The raw jar >>>>>> test.war: >>>>>> /WEB-INF/ >>>>>> /WEB-INF/faces-config.xml >>>>>> /WEB-INF/beans.xml >>>>>> /WEB-INF/web.xml >>>>>> /WEB-INF/classes/ >>>>>> /WEB-INF/classes/org/ >>>>>> /WEB-INF/classes/org/jboss/ >>>>>> /WEB-INF/classes/org/jboss/jsfunit/ >>>>>> /WEB-INF/classes/org/jboss/jsfunit/example/ >>>>>> /WEB-INF/classes/org/jboss/jsfunit/example/hellojsf/ >>>>>> /WEB-INF/classes/org/jboss/jsfunit/example/hellojsf/HelloJSFTest.class >>>>>> /WEB-INF/classes/META-INF/ >>>>>> /WEB-INF/classes/META-INF/beans.xml >>>>>> /index.xhtml >>>>>> >>>>>> After ModuleApplicationArchiveProcessor has added the deps >>>>>> test.war: >>>>>> /WEB-INF/ >>>>>> /WEB-INF/faces-config.xml >>>>>> /WEB-INF/beans.xml >>>>>> /WEB-INF/web.xml >>>>>> /WEB-INF/classes/ >>>>>> /WEB-INF/classes/org/ >>>>>> /WEB-INF/classes/org/jboss/ >>>>>> /WEB-INF/classes/org/jboss/jsfunit/ >>>>>> /WEB-INF/classes/org/jboss/jsfunit/example/ >>>>>> /WEB-INF/classes/org/jboss/jsfunit/example/hellojsf/ >>>>>> /WEB-INF/classes/org/jboss/jsfunit/example/hellojsf/HelloJSFTest.class >>>>>> /WEB-INF/classes/org/jboss/jsfunit/cdi/ >>>>>> /WEB-INF/classes/org/jboss/jsfunit/cdi/FormAuthentication.class >>>>>> /WEB-INF/classes/org/jboss/jsfunit/cdi/Browser.class >>>>>> /WEB-INF/classes/org/jboss/jsfunit/cdi/InitialRequest.class >>>>>> /WEB-INF/classes/org/jboss/jsfunit/cdi/InitialPage.class >>>>>> /WEB-INF/classes/org/jboss/jsfunit/cdi/BrowserVersion.class >>>>>> /WEB-INF/classes/org/jboss/jsfunit/cdi/JSFSessionFactory.class >>>>>> /WEB-INF/classes/org/jboss/jsfunit/cdi/Cookies.class >>>>>> /WEB-INF/classes/org/jboss/jsfunit/cdi/Proxy.class >>>>>> /WEB-INF/classes/org/jboss/jsfunit/cdi/BasicAuthentication.class >>>>>> /WEB-INF/classes/META-INF/ >>>>>> /WEB-INF/classes/META-INF/MANIFEST.MF<<<<<<<<< I think this should be in /META-INF/MANIFEST.MF >>>>>> /WEB-INF/classes/META-INF/beans.xml >>>>>> /index.xhtml >>>>>> >>>>>> I'll try to make it appear in the proper place >>>>>> >>>>>> >>>>>> On 14 Feb 2011, at 23:35, ssilvert(a)redhat.com wrote: >>>>>> >>>>>>> Thanks for your help. It's really strange. >>>>>>> >>>>>>> Among other things, if you open up the war you will see that the only classes under WEB-INF are my test class and some JSFUnit CDI classes that JSFUnit puts there with an ApplicationArchiveProcessor. >>>>>>> >>>>>>> >>>>>>> Quoting Kabir Khan&lt;kabir.khan(a)jboss.com&gt;: >>>>>>> >>>>>>>> I've had a quick look and can't see anything obvious, I'll take proper look tomorrow >>>>>>>> On 14 Feb 2011, at 20:38, ssilvert(a)redhat.com wrote: >>>>>>>> >>>>>>>>> I'm creating a WebArchive. This test runs fine when it deploys against AS6. Can you take a quick look at it? >>>>>>>>> >>>>>>>>> * svn checkout http://anonsvn.jboss.org/repos/jsfunit/trunk/gettingstarted >>>>>>>>> * Start AS7 >>>>>>>>> * mvn -Pjbossas-remote-7 test >>>>>>>>> >>>>>>>>> The test won't actually pass because JSF is not there yet. But it should still deploy and run. >>>>>>>>> >>>>>>>>> Stan >>>>>>>>> >>>>>>>>> Quoting Kabir Khan&lt;kabir.khan(a)jboss.com&gt;: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 14 Feb 2011, at 18:44, ssilvert(a)redhat.com wrote: >>>>>>>>>> >>>>>>>>>>> So let me ask it this way. What's the easiest way to get an >>>>>>>>>>> Arquillian test running with AS7? It looks like the answer might be >>>>>>>>>>> to use remote. I almost got that running with >>>>>>>>>>> jboss-as-arquillian-container-remote. Am I required to use the forked >>>>>>>>>>> Surefire with remote? >>>>>>>>>> >>>>>>>>>> The forked surefire plugin (which is not really being used yet) is not required for remote. To do an embedded test, simply copy what the smoke tests do. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Without it, I got this message in the AS7 console: >>>>>>>>>>> >>>>>>>>>>> 13:06:33,072 INFO [org.jboss.as.server.deployment] (pool-3-thread-4) >>>>>>>>>>> Content wi >>>>>>>>>>> th name test.war added at location >>>>>>>>>>> C:\projects\as7trunk\jboss-as\build\target\jb >>>>>>>>>>> oss-7.0.0.Alpha2\standalone\data\content\24\5a3cbc919f50f4d7384197c5755fd7fb5c83 >>>>>>>>>>> 9a\content >>>>>>>>>>> >>>>>>>>>>> But there were two strange things. First, I got this in my test output: >>>>>>>>>>> ------------------------------------------------------------------------------- >>>>>>>>>>> Test set: org.jboss.jsfunit.example.hellojsf.HelloJSFTest >>>>>>>>>>> ------------------------------------------------------------------------------- >>>>>>>>>>> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 13.846 >>>>>>>>>>> sec<<< FAILURE! >>>>>>>>>>> testInitialPage(org.jboss.jsfunit.example.hellojsf.HelloJSFTest) Time >>>>>>>>>>> elapsed: 6.089 sec<<< ERROR! >>>>>>>>>>> java.lang.ClassNotFoundException: >>>>>>>>>>> org.jboss.jsfunit.example.hellojsf.HelloJSFTest >>>>>>>>>>> >>>>>>>>>>> I can see that the test class was indeed added to the WEB-INF/classes. >>>>>>>>>>> So I shouldn't get ClassNotFoundException. >>>>>>>>>>> >>>>>>>>>>> But, it looks like jboss-as-arquillian-container-remote doesn't know >>>>>>>>>>> I'm creating a WAR because it put all the supporting classes in the >>>>>>>>>>> root of my WAR instead of putting them in WEB-INF/lib or >>>>>>>>>>> WEB-INF/classes. >>>>>>>>>> >>>>>>>>>> Unless you tell Shrinkwrap you're creating a web archive it will create a normal jar. From WarTestCase in smoke tests: >>>>>>>>>> >>>>>>>>>> @Deployment >>>>>>>>>> public static Archive<?> getDeployment(){ >>>>>>>>>> return ShrinkWrapUtils.createWebArchive("demos/war-example.war", SimpleServlet.class.getPackage()); >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> public static WebArchive createWebArchive(String archiveName, Package...packages) { >>>>>>>>>> WebArchive archive = ShrinkWrap.create(WebArchive.class, getBaseArchiveName(archiveName)); >>>>>>>>>> addPackages(archive, packages); >>>>>>>>>> addResources(archiveName, archive); >>>>>>>>>> return archive; >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> IIRC ShrinkWrap will put things in the right place if you create a WebArchive. For all other archive types root is the default location >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >> >> >> _______________________________________________ >> jboss-as7-dev mailing list >> jboss-as7-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev > >

That's one of the references. Note the key phrase in your quote: "When packaged into such a form, a META-INF directory will be present which contains information useful to Java archive tools." The java archive tools operate on META-INF/MANIFEST.MF Another reference, 10.7.1, use of extension-list, which is a JAR standard described META-INF/MANIFEST.MF: "The application developer depending on such an extension or extensions must provide a META-INF/MANIFEST.MF entry in the WAR file listing all extensions needed by the WAR. The format of the manifest entry should follow standard JAR manifest format." Yet another reference: "A single file that contains all of the components of a web application. This archive file is created by using standard JAR tools which allow any or all of the web components to be signed." (in the glossary) Signed is referring to jar signing. The standard tool for signing, jarsigner looks in META-INF/MANIFEST.MF And there is also EE 8.2.1: "A JAR format file (such as a .jar file, .war file, or .rar file) may reference a .jar file or directory by naming the referenced .jar file or directory in a Class-Path header in the referencing JAR file’s Manifest file. The referenced .jar file or directory is named using a URL relative to the URL of the refer- encing JAR file. The Manifest file is named META-INF/MANIFEST.MF in the JAR file. The Class-Path entry in the Manifest file is of the form" On 2/16/11 1:53 AM, Andrew Lee Rubinger wrote: > Are you referring to Servlet 3.0 10.6? I don't find it incredibly > explicit, except that it clearly notes that a top-level META-INF is to > be excluded from servicing client requests: > > "Web applications can be packaged and signed into a Web ARchive format > (WAR) file > using the standard Java archive tools. For example, an application for > issue tracking > might be distributed in an archive file called issuetrack.war. > When packaged into such a form, a META-INF directory will be present > which > contains information useful to Java archive tools. This directory must > not be directly > served as content by the container in response to a Web client’s > request, though its > contents are visible to servlet code via the getResource and > getResourceAsStream > calls on the ServletContext. Also, any requests to access the resources > in META-INF > directory must be returned with a SC_NOT_FOUND(404) response." > > S, > ALR > > On 02/16/2011 12:02 AM, Jason T. Greene wrote: >> BTW the oddball JPA requirement I think was a screwup. I raised the >> issue on the EE EG. >> >> On 2/15/11 10:43 PM, Jason T. Greene wrote: >>> That's totally wrong. The specs are pretty clear that META-INF is a >>> root >>> level directory under a WAR, that's where class-path, signing, and >>> extensions go. They also state that the web server must not treat >>> META-INF as a resource. >>> >>> On 2/15/11 12:01 PM, Kabir Khan wrote: >>>> You may be right but AS 7 only looks for it in META-INF/MANIFEST.MF. >>>> If that is wrong we should fix our end >>>> On 15 Feb 2011, at 17:58, Andrew Lee Rubinger wrote: >>>> >>>>> Hey Kabir: >>>>> >>>>> Hmm, I'm not sure which, then, is the correct location. Have a look >>>>> at: >>>>> >>>>> https://issues.jboss.org/browse/SHRINKWRAP-241 >>>>> >>>>> My comment on 09/Jan/11 notes the mappings we've chosen; for a >>>>> WebArchive the manifest location is: >>>>> >>>>> /WEB-INF/classes/META-INF >>>>> >>>>> Disagree? >>>>> >>>>> I'm not finding docs that really support either position >>>>> specifically for MANIFEST.MF in web archives. persistence.xml for >>>>> instance goes in WEB-INF/classes/META-INF. >>>>> >>>>> S, >>>>> ALR >>>>> >>>>> On 02/15/2011 06:50 AM, Kabir Khan wrote: >>>>>> Hey Andrew, >>>>>> >>>>>> It seems that WebArchive.setManifest() adds the Manifest to >>>>>> WEB-INF/classes/META-INF/MANIFEST.MF instead of >>>>>> /META-INF/MANIFEST.MF. >>>>>> >>>>>> Begin forwarded message: >>>>>> >>>>>>> From: Kabir Khan&lt;kabir.khan(a)jboss.com&gt; >>>>>>> Date: 15 February 2011 11:49:22 GMT >>>>>>> To: Stan Silvert&lt;ssilvert(a)redhat.com&gt; >>>>>>> Subject: Re: [jboss-as7-dev] testsuite >>>>>>> >>>>>>> This commit fixes it so that the manifest.mf containing the >>>>>>> typical arquillian module dependencies goes in the right place >>>>>>> (/META-INF/MANIFEST.MF): >>>>>>> https://github.com/kabir/jboss-as/commit/a14f3013d68ab14e85cb4f17cf30af08... >>>>>>> >>>>>>> >>>>>>> >>>>>>> I still get this on the server, which is probably ok: >>>>>>> 10:54:13,415 ERROR >>>>>>> [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/test]] >>>>>>> >>>>>>> (pool-2-thread-3) Servlet /test threw load() exception: >>>>>>> java.lang.IllegalStateException: Application was not properly >>>>>>> initialized at startup, could not find Factory: >>>>>>> javax.faces.context.FacesContextFactory >>>>>>> at >>>>>>> javax.faces.FactoryFinder$FactoryManager.getFactory(FactoryFinder.java:804) >>>>>>> >>>>>>> [jsf-api-2.0.2-FCS.jar:2.0.2-FCS] >>>>>>> at javax.faces.FactoryFinder.getFactory(FactoryFinder.java:306) >>>>>>> [jsf-api-2.0.2-FCS.jar:2.0.2-FCS] >>>>>>> at javax.faces.webapp.FacesServlet.init(FacesServlet.java:166) >>>>>>> [jsf-api-2.0.2-FCS.jar:2.0.2-FCS] >>>>>>> at >>>>>>> org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1208) >>>>>>> >>>>>>> [jbossweb-7.0.0.Beta1.jar:7.0.0.Alpha2-SNAPSHOT] >>>>>>> >>>>>>> And this now in the test report (i.e. shrinkwrap's Asset is now >>>>>>> visible): >>>>>>> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: >>>>>>> 7.383 sec<<< FAILURE! >>>>>>> testInitialPage(org.jboss.jsfunit.example.hellojsf.HelloJSFTest) >>>>>>> Time elapsed: 0.263 sec<<< ERROR! >>>>>>> java.lang.NoClassDefFoundError: >>>>>>> org/jboss/jsfunit/jsfsession/JSFServerSession >>>>>>> at java.lang.Class.getDeclaredMethods0(Native Method) >>>>>>> at java.lang.Class.privateGetDeclaredMethods(Class.java:2427) >>>>>>> at java.lang.Class.getDeclaredMethods(Class.java:1791) >>>>>>> at org.junit.runners.model.TestClass.<init>(TestClass.java:38) >>>>>>> at org.junit.runners.ParentRunner.<init>(ParentRunner.java:65) >>>>>>> at >>>>>>> org.junit.runners.BlockJUnit4ClassRunner.<init>(BlockJUnit4ClassRunner.java:59) >>>>>>> >>>>>>> >>>>>>> at org.jboss.arquillian.junit.Arquillian.<init>(Arquillian.java:74) >>>>>>> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native >>>>>>> Method) >>>>>>> at >>>>>>> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) >>>>>>> >>>>>>> >>>>>>> at >>>>>>> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) >>>>>>> >>>>>>> >>>>>>> at java.lang.reflect.Constructor.newInstance(Constructor.java:513) >>>>>>> at >>>>>>> org.junit.internal.builders.AnnotatedBuilder.buildRunner(AnnotatedBuilder.java:31) >>>>>>> >>>>>>> >>>>>>> at >>>>>>> org.junit.internal.builders.AnnotatedBuilder.runnerForClass(AnnotatedBuilder.java:24) >>>>>>> >>>>>>> >>>>>>> at >>>>>>> org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:57) >>>>>>> >>>>>>> >>>>>>> at >>>>>>> org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:29) >>>>>>> >>>>>>> >>>>>>> at >>>>>>> org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:57) >>>>>>> >>>>>>> >>>>>>> at >>>>>>> org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:24) >>>>>>> >>>>>>> >>>>>>> >>>>>>> So you'll need a module in AS for jsf if one isn't there already. >>>>>>> Then you need to either include the dependency in a manifest.mf >>>>>>> provided to your test archive, such as: >>>>>>> ---- >>>>>>> Manifest-Version: 1.0 >>>>>>> Dependencies: my.jsf.module >>>>>>> ---- >>>>>>> The demos contain more examples of manifests. OR if you determine >>>>>>> early that this is a JSF deployment, you will probably want to >>>>>>> always add the jsf dependencies in a deployment unit processor. >>>>>>> See ManagedBeanDependencyProcessor which adds a dependency on the >>>>>>> javaee.api for all managed beans deployments. >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 15 Feb 2011, at 11:03, Kabir Khan wrote: >>>>>>> >>>>>>>> I think there is a problem with how the manifest containing the >>>>>>>> additional deps gets added to the war by >>>>>>>> ModuleApplicationProcessor. I added some debugging to make sure >>>>>>>> that the jboss arquillian processors get invoked >>>>>>>> >>>>>>>> The raw jar >>>>>>>> test.war: >>>>>>>> /WEB-INF/ >>>>>>>> /WEB-INF/faces-config.xml >>>>>>>> /WEB-INF/beans.xml >>>>>>>> /WEB-INF/web.xml >>>>>>>> /WEB-INF/classes/ >>>>>>>> /WEB-INF/classes/org/ >>>>>>>> /WEB-INF/classes/org/jboss/ >>>>>>>> /WEB-INF/classes/org/jboss/jsfunit/ >>>>>>>> /WEB-INF/classes/org/jboss/jsfunit/example/ >>>>>>>> /WEB-INF/classes/org/jboss/jsfunit/example/hellojsf/ >>>>>>>> /WEB-INF/classes/org/jboss/jsfunit/example/hellojsf/HelloJSFTest.class >>>>>>>> >>>>>>>> >>>>>>>> /WEB-INF/classes/META-INF/ >>>>>>>> /WEB-INF/classes/META-INF/beans.xml >>>>>>>> /index.xhtml >>>>>>>> >>>>>>>> After ModuleApplicationArchiveProcessor has added the deps >>>>>>>> test.war: >>>>>>>> /WEB-INF/ >>>>>>>> /WEB-INF/faces-config.xml >>>>>>>> /WEB-INF/beans.xml >>>>>>>> /WEB-INF/web.xml >>>>>>>> /WEB-INF/classes/ >>>>>>>> /WEB-INF/classes/org/ >>>>>>>> /WEB-INF/classes/org/jboss/ >>>>>>>> /WEB-INF/classes/org/jboss/jsfunit/ >>>>>>>> /WEB-INF/classes/org/jboss/jsfunit/example/ >>>>>>>> /WEB-INF/classes/org/jboss/jsfunit/example/hellojsf/ >>>>>>>> /WEB-INF/classes/org/jboss/jsfunit/example/hellojsf/HelloJSFTest.class >>>>>>>> >>>>>>>> >>>>>>>> /WEB-INF/classes/org/jboss/jsfunit/cdi/ >>>>>>>> /WEB-INF/classes/org/jboss/jsfunit/cdi/FormAuthentication.class >>>>>>>> /WEB-INF/classes/org/jboss/jsfunit/cdi/Browser.class >>>>>>>> /WEB-INF/classes/org/jboss/jsfunit/cdi/InitialRequest.class >>>>>>>> /WEB-INF/classes/org/jboss/jsfunit/cdi/InitialPage.class >>>>>>>> /WEB-INF/classes/org/jboss/jsfunit/cdi/BrowserVersion.class >>>>>>>> /WEB-INF/classes/org/jboss/jsfunit/cdi/JSFSessionFactory.class >>>>>>>> /WEB-INF/classes/org/jboss/jsfunit/cdi/Cookies.class >>>>>>>> /WEB-INF/classes/org/jboss/jsfunit/cdi/Proxy.class >>>>>>>> /WEB-INF/classes/org/jboss/jsfunit/cdi/BasicAuthentication.class >>>>>>>> /WEB-INF/classes/META-INF/ >>>>>>>> /WEB-INF/classes/META-INF/MANIFEST.MF<<<<<<<<< I think this >>>>>>>> should be in /META-INF/MANIFEST.MF >>>>>>>> /WEB-INF/classes/META-INF/beans.xml >>>>>>>> /index.xhtml >>>>>>>> >>>>>>>> I'll try to make it appear in the proper place >>>>>>>> >>>>>>>> >>>>>>>> On 14 Feb 2011, at 23:35, ssilvert(a)redhat.com wrote: >>>>>>>> >>>>>>>>> Thanks for your help. It's really strange. >>>>>>>>> >>>>>>>>> Among other things, if you open up the war you will see that >>>>>>>>> the only classes under WEB-INF are my test class and some >>>>>>>>> JSFUnit CDI classes that JSFUnit puts there with an >>>>>>>>> ApplicationArchiveProcessor. >>>>>>>>> >>>>>>>>> >>>>>>>>> Quoting Kabir Khan&lt;kabir.khan(a)jboss.com&gt;: >>>>>>>>> >>>>>>>>>> I've had a quick look and can't see anything obvious, I'll >>>>>>>>>> take proper look tomorrow >>>>>>>>>> On 14 Feb 2011, at 20:38, ssilvert(a)redhat.com wrote: >>>>>>>>>> >>>>>>>>>>> I'm creating a WebArchive. This test runs fine when it >>>>>>>>>>> deploys against AS6. Can you take a quick look at it? >>>>>>>>>>> >>>>>>>>>>> * svn checkout >>>>>>>>>>> http://anonsvn.jboss.org/repos/jsfunit/trunk/gettingstarted >>>>>>>>>>> * Start AS7 >>>>>>>>>>> * mvn -Pjbossas-remote-7 test >>>>>>>>>>> >>>>>>>>>>> The test won't actually pass because JSF is not there yet. >>>>>>>>>>> But it should still deploy and run. >>>>>>>>>>> >>>>>>>>>>> Stan >>>>>>>>>>> >>>>>>>>>>> Quoting Kabir Khan&lt;kabir.khan(a)jboss.com&gt;: >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 14 Feb 2011, at 18:44, ssilvert(a)redhat.com wrote: >>>>>>>>>>>> >>>>>>>>>>>>> So let me ask it this way. What's the easiest way to get an >>>>>>>>>>>>> Arquillian test running with AS7? It looks like the answer >>>>>>>>>>>>> might be >>>>>>>>>>>>> to use remote. I almost got that running with >>>>>>>>>>>>> jboss-as-arquillian-container-remote. Am I required to use >>>>>>>>>>>>> the forked >>>>>>>>>>>>> Surefire with remote? >>>>>>>>>>>> >>>>>>>>>>>> The forked surefire plugin (which is not really being used >>>>>>>>>>>> yet) is not required for remote. To do an embedded test, >>>>>>>>>>>> simply copy what the smoke tests do. >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Without it, I got this message in the AS7 console: >>>>>>>>>>>>> >>>>>>>>>>>>> 13:06:33,072 INFO [org.jboss.as.server.deployment] >>>>>>>>>>>>> (pool-3-thread-4) >>>>>>>>>>>>> Content wi >>>>>>>>>>>>> th name test.war added at location >>>>>>>>>>>>> C:\projects\as7trunk\jboss-as\build\target\jb >>>>>>>>>>>>> oss-7.0.0.Alpha2\standalone\data\content\24\5a3cbc919f50f4d7384197c5755fd7fb5c83 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 9a\content >>>>>>>>>>>>> >>>>>>>>>>>>> But there were two strange things. First, I got this in my >>>>>>>>>>>>> test output: >>>>>>>>>>>>> ------------------------------------------------------------------------------- >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Test set: org.jboss.jsfunit.example.hellojsf.HelloJSFTest >>>>>>>>>>>>> ------------------------------------------------------------------------------- >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time >>>>>>>>>>>>> elapsed: 13.846 >>>>>>>>>>>>> sec<<< FAILURE! >>>>>>>>>>>>> testInitialPage(org.jboss.jsfunit.example.hellojsf.HelloJSFTest) >>>>>>>>>>>>> >>>>>>>>>>>>> Time >>>>>>>>>>>>> elapsed: 6.089 sec<<< ERROR! >>>>>>>>>>>>> java.lang.ClassNotFoundException: >>>>>>>>>>>>> org.jboss.jsfunit.example.hellojsf.HelloJSFTest >>>>>>>>>>>>> >>>>>>>>>>>>> I can see that the test class was indeed added to the >>>>>>>>>>>>> WEB-INF/classes. >>>>>>>>>>>>> So I shouldn't get ClassNotFoundException. >>>>>>>>>>>>> >>>>>>>>>>>>> But, it looks like jboss-as-arquillian-container-remote >>>>>>>>>>>>> doesn't know >>>>>>>>>>>>> I'm creating a WAR because it put all the supporting >>>>>>>>>>>>> classes in the >>>>>>>>>>>>> root of my WAR instead of putting them in WEB-INF/lib or >>>>>>>>>>>>> WEB-INF/classes. >>>>>>>>>>>> >>>>>>>>>>>> Unless you tell Shrinkwrap you're creating a web archive it >>>>>>>>>>>> will create a normal jar. From WarTestCase in smoke tests: >>>>>>>>>>>> >>>>>>>>>>>> @Deployment >>>>>>>>>>>> public static Archive<?> getDeployment(){ >>>>>>>>>>>> return >>>>>>>>>>>> ShrinkWrapUtils.createWebArchive("demos/war-example.war", >>>>>>>>>>>> SimpleServlet.class.getPackage()); >>>>>>>>>>>> } >>>>>>>>>>>> >>>>>>>>>>>> public static WebArchive createWebArchive(String >>>>>>>>>>>> archiveName, Package...packages) { >>>>>>>>>>>> WebArchive archive = ShrinkWrap.create(WebArchive.class, >>>>>>>>>>>> getBaseArchiveName(archiveName)); >>>>>>>>>>>> addPackages(archive, packages); >>>>>>>>>>>> addResources(archiveName, archive); >>>>>>>>>>>> return archive; >>>>>>>>>>>> } >>>>>>>>>>>> >>>>>>>>>>>> IIRC ShrinkWrap will put things in the right place if you >>>>>>>>>>>> create a WebArchive. For all other archive types root is the >>>>>>>>>>>> default location >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>> >>>> >>>> _______________________________________________ >>>> jboss-as7-dev mailing list >>>> jboss-as7-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >>> >>> >> >>

On Feb 16, 2011, at 06:02, Jason T. Greene wrote: > BTW the oddball JPA requirement I think was a screwup. I raised the > issue on the EE EG. It's to mark the classes folder as the unit to look in as opposed to the complete war (which includes libs etc.) But would be interested to hear how else that can be interpreted ;)