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(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
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>
>>
>> _______________________________________________
>> jboss-as7-dev mailing list
>> jboss-as7-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
>