[jboss-as7-dev] testsuite
Andrew Lee Rubinger
andrew.rubinger at redhat.com
Wed Feb 16 02:53:58 EST 2011
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<kabir.khan at jboss.com>
>>>>>> Date: 15 February 2011 11:49:22 GMT
>>>>>> To: Stan Silvert<ssilvert at 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/a14f3013d68ab14e85cb4f17cf30af082e35d093
>>>>>>
>>>>>> 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 at 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 at 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 at 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 at jboss.com>:
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 14 Feb 2011, at 18:44, ssilvert at 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 at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>
>>
>
>
More information about the jboss-as7-dev
mailing list