Skip to main content

[webtier] Re: JARs in lib/applibs not available to JSP compiler?

2 replies [Last post]
Anonymous

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Jan Luehe

On 09/14/08 11:46 AM, glassfish@javadesktop.org wrote:
> Sun Java System Application Server 9.1_02 (build b04-fcs)
>
> When deploying an EAR, jars specified in the --libraries parameter are visible to servlet classes, but not to the JSP compiler, causing NoClassDefFound exceptions and breaking the JSPs in the application. The only workaround I have found is to add a classloader extra-class-path attribute to the sun-web.xml before building the EAR. This couples the binding information inside the WAR, rather than keeping it as a 'pure' deployment fact.
>
> Am I missing something?

No, this is a known issue, see

https://glassfish.dev.java.net/issues/show_bug.cgi?id=4883
("Application specific classloder (applibs / --libraries) not used by
JSP compilation")

Jan

> I've tried all 8 iterations of the following tests:
>
> - Explicitly declare the JspServlet in my WAR/WEB-INF/web.xml - hoping that it will share a classloader with the rest of the application - no luck
>
> - Specify --libraries more explicitly, using ${com.sun.aas.instanceRoot}/lib/applibs/someclasses.jar - no luck
>
> In each of the above cases, the Jasper compiler lists its complete classpath, which does not include anything in /lib/applibs
>
> The one case that does work is:
>
> - Add the line
>
> to WEB-INF/sun-web.xml inside the WAR - this works, but is kind of gross. In the first place, the path is relative to the WAR's docroot, implying that classes are normally found within the WAR. There's already a J2EE standard way to reference resources that are contained in the WAR. In the second place, it requires the application to 'know' the folder structure of the container it's being deployed to, which injects container/version dependency.
>
> Personally, I would rather see the --libraries classpath entries automatically passed to the JSP compiler. I fully expect to hear suggestions that I bundle the required JARs into the EAR, or include them in WAR/WEB-INF/lib, or X or Y or Z. I'll do that if absolutely necessary, but the real goal here is to simplify management of my JARs by placing them in a single repository within the instance, for all applications to share. Isn't that the intent of being able to provide library information during deployment?
> [Message sent by forum member 'jpedwardsdotcom' (jpedwardsdotcom)]
>
> http://forums.java.net/jive/thread.jspa?messageID=299262
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: webtier-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: webtier-help@glassfish.dev.java.net

Jan Luehe

On 09/15/08 06:35 PM, Jan Luehe wrote:
> On 09/14/08 11:46 AM, glassfish@javadesktop.org wrote:
>> Sun Java System Application Server 9.1_02 (build b04-fcs)
>>
>> When deploying an EAR, jars specified in the --libraries parameter
>> are visible to servlet classes, but not to the JSP compiler, causing
>> NoClassDefFound exceptions and breaking the JSPs in the application.
>> The only workaround I have found is to add a classloader
>> extra-class-path attribute to the sun-web.xml before building the
>> EAR. This couples the binding information inside the WAR, rather than
>> keeping it as a 'pure' deployment fact.
>>
>> Am I missing something?
>
> No, this is a known issue, see
>
> https://glassfish.dev.java.net/issues/show_bug.cgi?id=4883
> ("Application specific classloder (applibs / --libraries) not used by
> JSP compilation")

Can you confirm that the issue exists only for WAR files bundled inside
an EAR?

In other words, if I deploy a standalone WAR file with "--libraries
xyz.jar", its JSPs compile
just fine (both during precompilation and at runtime) when they
reference classes from
xyz.jar

Thanks,

Jan

>
>
> Jan
>
>
>> I've tried all 8 iterations of the following tests:
>>
>> - Explicitly declare the JspServlet in my WAR/WEB-INF/web.xml -
>> hoping that it will share a classloader with the rest of the
>> application - no luck
>>
>> - Specify --libraries more explicitly, using
>> ${com.sun.aas.instanceRoot}/lib/applibs/someclasses.jar - no luck
>>
>> In each of the above cases, the Jasper compiler lists its complete
>> classpath, which does not include anything in /lib/applibs
>>
>> The one case that does work is:
>>
>> - Add the line >> extra-class-path="../../../../lib/applibs/someclasses.jar" />
>> to WEB-INF/sun-web.xml inside the WAR - this works, but is kind of
>> gross. In the first place, the path is relative to the WAR's docroot,
>> implying that classes are normally found within the WAR. There's
>> already a J2EE standard way to reference resources that are contained
>> in the WAR. In the second place, it requires the application to
>> 'know' the folder structure of the container it's being deployed to,
>> which injects container/version dependency.
>>
>> Personally, I would rather see the --libraries classpath entries
>> automatically passed to the JSP compiler. I fully expect to hear
>> suggestions that I bundle the required JARs into the EAR, or include
>> them in WAR/WEB-INF/lib, or X or Y or Z. I'll do that if absolutely
>> necessary, but the real goal here is to simplify management of my
>> JARs by placing them in a single repository within the instance, for
>> all applications to share. Isn't that the intent of being able to
>> provide library information during deployment?
>> [Message sent by forum member 'jpedwardsdotcom' (jpedwardsdotcom)]
>>
>> http://forums.java.net/jive/thread.jspa?messageID=299262
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
>> For additional commands, e-mail: users-help@glassfish.dev.java.net
>>
>>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: webtier-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: webtier-help@glassfish.dev.java.net