On Tue, Nov 29, 2011 at 6:49 PM, Tim Quinn <tim.quinn_at_oracle.com> wrote:
> Ah, this is such fun!
>
> If you look at the JavaDoc for URLClassLoader, you find this little morsel:
>
> "This class loader is used to load classes and resources from a search
> path of URLs referring to both JAR files and directories. Any URL that ends
> with a '/' is assumed to refer to a directory. Otherwise, the URL is
> assumed to refer to a JAR file which will be opened as needed. "
>
> Just about every useful class loader you'll come across extends
> URLClassLoader, either directly or indirectly, so while the trailing slash
> is NOT required by the manifest or JAR spec, it IS required by the
> URLClassLoader contract.
>
Well ..... does this mandate that a directory mentioned in the
'Class-Path' header of MANIFEST.MF has a trailing slash?
If the URLClassLoader needs this it could also be the responsibility of the
container to add that slash .. isn't it?
-Bernhard
> - Tim
>
>
> On Nov 29, 2011, at 10:23 AM, Bernhard Thalmayr wrote:
>
>
>
> On Tue, Nov 29, 2011 at 5:08 PM, Cheng Fang <cheng.fang_at_oracle.com> wrote:
>
>> If you write a java app with the same structure, you will also get the
>> same behavior. So not a Java EE or GlassFish bug.
>>
>> Yes, both jar files and directories can be members of Class-Path. This
>> part is governed by Java Jar Specification.
>>
>
> If I read
>
> http://docs.oracle.com/javase/7/docs/technotes/guides/jar/jar.html
>
> I don't see where it's sepcified that 'directories' need to thave a
> trailing slash .... is this a litle inaccuracy?
>
> IIRC I can do 'new File("dir").mkdir()' ....
>
> -Bernhard
>
>>
>> -cheng
>>
>>
>> On 11/29/11 10:35 AM, Bernhard Thalmayr wrote:
>>
>> Thanks for the pointer Cheng.
>>
>> I removed the 'lib' prefixes (actually I know about lib-directory .. but
>> this is a 3rd party app and I don't want to change to much at the beginnin)
>> and put 'classes/' into 'Class-Path' header.
>>
>> BTW should I consider it as a bug that I the directory must have a
>> trainling '/'?
>>
>> Unfortuantely I can not deploy the app anymore to an instance directly
>> (using --target <instance>).
>>
>> Deploying for target 'domain' works, but when I try to create the
>> application-reference I always get the following error .... I don't see any
>> reason how this could be related to the change
>>
>> [#|2011-11-29T16:25:11.814+0100|SEVERE|glassfish3.1.1|com.sun.grizzly.config.GrizzlyServiceListener|_ThreadID=157;_ThreadName=Thread-2;|GRIZZLY0039:
>> Request URI is too large.
>> java.nio.BufferOverflowException
>> at
>> com.sun.grizzly.tcp.http11.InternalInputBuffer.fill(InternalInputBuffer.java:765)
>> at
>> com.sun.grizzly.tcp.http11.InternalInputBuffer.parseRequestLine(InternalInputBuffer.java:467)
>> at
>> com.sun.grizzly.http.ProcessorTask.parseRequest(ProcessorTask.java:861)
>> at
>> com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:692)
>> at
>> com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1019)
>> at
>> com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
>> at
>> com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
>> at
>> com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
>> at
>> com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
>> at
>> com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
>> at
>> com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
>> at
>> com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
>> at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
>> at
>> com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
>> at
>> com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
>> at java.lang.Thread.run(Thread.java:722)
>> |#]
>>
>> [#|2011-11-29T16:25:11.817+0100|SEVERE|glassfish3.1.1|com.sun.grizzly.config.GrizzlyServiceListener|_ThreadID=157;_ThreadName=Thread-2;|GRIZZLY0051:
>> ProcessorTask exception.
>> java.lang.NullPointerException
>> at java.nio.CharBuffer.put(CharBuffer.java:915)
>> at com.sun.enterprise.
>> web.accesslog.DefaultAccessLogFormatterImpl.appendRequestInfo
>> (DefaultAccessLogFormatterImpl.java:494)
>> at com.sun.enterprise.
>> web.accesslog.DefaultAccessLogFormatterImpl.appendLogEntry
>> (DefaultAccessLogFormatterImpl.java:264)
>> at com.sun.enterprise.web.PEAccessLogValve.postInvoke
>> (PEAccessLogValve.java:592)
>> at
>> com.sun.enterprise.web.VirtualServer$2.onParsingError(VirtualServer.java:1698)
>> at
>> com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:709)
>> at
>> com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1019)
>> at
>> com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
>> at
>> com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
>> at
>> com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
>> at
>> com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
>> at
>> com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
>> at
>> com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
>> at
>> com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
>> at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
>> at
>> com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
>> at
>> com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
>> at java.lang.Thread.run(Thread.java:722)
>> |#]
>>
>> Thanks and regards,
>> Bernhard
>>
>> On Tue, Nov 29, 2011 at 1:51 PM, Cheng Fang <cheng.fang_at_oracle.com>wrote:
>>
>>> Hi Bernhard,
>>>
>>> Change Class-Path: lib/lib1.jar lib/lib2.jar classes to Class-Path:
>>> lib/lib1.jar lib/lib2.jar classes/
>>>
>>> Another point is, in Java EE 6, EAR/lib/ is the default EAR
>>> library-directory and all jars in that directory are automatically made
>>> available to your application. Having them also in Class-Path results in
>>> duplicates but that should affect functioning.
>>>
>>> -cheng
>>>
>>>
>>> On 11/29/11 5:13 AM, Bernhard Thalmayr wrote:
>>>
>>> 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 (Class-Path: lib/lib1.jar lib/lib2.jar classes)
>>>
>>> ejb2.jar
>>> |_META-INF/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 ?
>>>
>>> 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.
>>>
>>> -Bernhard
>>> --
>>> IT-Consulting Bernhard Thalmayr
>>> - Painstaking Minds -
>>> 83620 Vagen (Munich area)
>>> Germany
>>>
>>>
>>
>>
>> --
>> IT-Consulting Bernhard Thalmayr
>> - Painstaking Minds -
>> 83620 Vagen (Munich area)
>> Germany
>>
>>
>
>
> --
> IT-Consulting Bernhard Thalmayr
> - Painstaking Minds -
> 83620 Vagen (Munich area)
> Germany
>
>
>
--
IT-Consulting Bernhard Thalmayr
- Painstaking Minds -
83620 Vagen (Munich area)
Germany