Hi, Bernhard
>
> first of all, I am assuming that you consistently made a typo: the
> manifest must be named MANIFEST.MF (not .FM) in order to be read.
>
>
> Thanks for your pointers Andreas.
>
> Of course this '.FM' was a typo ...
>
>
> The error most probably is that the Class-Path entry seems to
> process only zipped or "exploded" JAR files, but not directories
> in classical "classes" style (i.e. the name of which does not end
> in .jar):
>
> I've never seen that in practice, and section 8.2.1 on page 177
> seems to conform with my assumption:
>
> "*Only JAR format files or directories* containing class files or
> resources to be loaded directly by a standard class loader should
> be the *target of a Class-Path reference*; such files *are always
> named with a .jar extension*."
>
>
> However in the same sectio you can read
>
> The Java EE deployment tools must process *all such referenced files
> and directories* when processing a Java EE module.
>
> How could a 'directory' have a '.jar' extension?
>
> If there's room for speculation it might be a good idea to make the
> specification even more precise.
I think we do support .jar directories (it's just an expanded jar folder
named with x.jar) as JDK does. You can give it a try to see what happens.
>
>
> Do you have a particular reason why you cannot JAR up your classes
> to be contained in the "classes" dir before creating the EAR?
>
>
> Actually it's a 3rd party application and I don't want to change too
> much ....
>
> Everything works fine using GF 2.1.1 but it's a major issue to migrate
> to GF 3.1.1.
As I mentioned in the other email to you, when we moved to a new code
base when started with 3.*, we probably lost some of the non-standard
features from v2.*. We do intend to support all the standard features
(as defined in the spec), and also support non-standard product backward
compatibility as much as we could (or help find workaround when it's too
complex or does not make sense to implement it in 3.* code base).
Thanks,
- Hong
>
>
>
>
> Am 29.11.2011 11:13, schrieb Bernhard Thalmayr:
>> Hi experts,
>>
>> classloading and 'portable JEE application' seems to be very
>> challenging in GF 3.1.1
>>
>> I have a (3rd party) enterprise app with layout
>>
>> META-INF/application.xml
>> ejb1.jar
>> |_ META-INF/MANIFEST.FM <http://MANIFEST.FM> (Class-Path:
>> lib/lib1.jar lib/lib2.jar classes)
>>
>> ejb2.jar
>> |_META-INF/MANIFEST.FM <http://MANIFEST.FM> (Class-Path:
>> lib/lib1.jar lib/lib3.jar classes)
>>
>> lib/lib1.jar
>> lib/lib2.jar
>> lib/lib3.jar
>> classes/<package-structure>
>>
>> A 'NoClassDefFoundError' is raised
>>
>> java.lang.NoClassDefFoundError: <class-from-classes-directory>
>> at java.lang.ClassLoader.defineClass1(Native Method)
>> at java.lang.ClassLoader.defineClass(ClassLoader.java:791)
>> at
>> com.sun.enterprise.loader.ASURLClassLoader.findClass(ASURLClassLoader
>> .java:756)
>> at java.lang.ClassLoader.loadClass(ClassLoader.java:423)
>> at java.lang.ClassLoader.loadClass(ClassLoader.java:410)
>> at java.lang.ClassLoader.loadClass(ClassLoader.java:410)
>> at java.lang.ClassLoader.loadClass(ClassLoader.java:356)
>> at java.lang.Class.forName0(Native Method)
>> at java.lang.Class.forName(Class.java:186)
>> at <method-of-class-from-ejb1.jar>
>>
>>
>> As far as I interpret chapter 'EE.8' of JEE 6 specification I
>> packaged the appliation correctly.
>>
>> Could it be that GF 3.1.1 does not honour directories mentioned
>> in MANIFEST.FM <http://MANIFEST.FM> ?
>>
>> Section 8.2.1 states ...
>>
>> "The Java EE deployment tools must process all such referenced
>> files and directories when processing a Java EE module."
>>
>> Thanks for any pointers.
>
> --
> Andreas Loew | Senior Java Architect
> Oracle Advanced Customer Services
> ORACLE Deutschland B.V. & Co. KG
>
>
>
>
> --
> IT-Consulting Bernhard Thalmayr
> - Painstaking Minds -
> 83620 Vagen (Munich area)
> Germany