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<kabir.khan(a)jboss.com>
>> Date: 15 February 2011 11:49:22 GMT
>> To: Stan Silvert<ssilvert(a)redhat.com>
>> 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<kabir.khan(a)jboss.com>:
>>>>
>>>>> 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<kabir.khan(a)jboss.com>:
>>>>>>
>>>>>>>
>>>>>>> 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
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
>