Please use the Apache issue tracking system for new NetBeans issues ( !!
Bug 152333 - Subfolder jars from V3 are not included in web project classpath on windows.
Subfolder jars from V3 are not included in web project classpath on windows.
Product: serverplugins
Classification: Unclassified
Component: GlassFish
PC Windows XP
: P2 (vote)
: 6.x
Assigned To: Vince Kraemer
: 153434 (view as bug list)
Depends on:
  Show dependency treegraph
Reported: 2008-11-04 18:30 UTC by wimv
Modified: 2009-02-19 23:04 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT

screenshot of "Glassfish V3 Prelude" server libraries in Netbeans 6.5 on windows xp (9.02 KB, image/png)
2008-11-04 18:32 UTC, wimv
candidate patch (5.93 KB, text/plain)
2008-11-05 07:01 UTC, Vince Kraemer
Screen shot (44.79 KB, image/gif)
2008-12-02 09:29 UTC, dpkumar

Note You need to log in before you can comment on or make changes to this bug.
Description wimv 2008-11-04 18:30:45 UTC
When using Netbeans 6.5 RC2 with Glassfish V3 Prelude b28c
(windows xp sp3, jdk 1.6.0_06)

When selecting Glassfish V3 as server for a project, the added server libraries "Glassfish V3 Prelude", under libraries,
don't include javax.ejb. This has something to do with the fact that javax.ejb.jar was moved from glassfish/modules/ to
glassfish/modules/ejb/ in b28c of glassfish.

Moving javax.ejb.jar up one level in the glassfish directory tree (i.e. putting it in the modules directory, where it
used to be) acts as a workaround for this problem (this was tested).

Comment 1 wimv 2008-11-04 18:32:39 UTC
Created attachment 73221 [details]
screenshot of "Glassfish V3 Prelude" server libraries in Netbeans 6.5 on windows xp
Comment 2 _ pcw 2008-11-04 19:22:37 UTC
Looks like a regression from commit 103014 in Hk2PluginProperties.getClasses() -- the scanning rules put in place when
the skeleton javaee.jar was removed (and thus we couldn't rely on manifest entries anymore) do not include subfolders,
so the ejb container api's are not automatically added to web apps when the ejb container exists on disk.
Comment 3 _ pcw 2008-11-04 20:19:35 UTC
Changeset 104249 which added support for subfolders to the new algorithm for finding api jars is incomplete.

This does not work on Windows for any jars in subfolders.  Note the screenshot does not show jsf-impl.jar or
javax.servlet.jsp.jstl.jar either which are in web subfolder and are in the stock V3 installation.

This broke the out-of-the box functionality of JSTL applications.

It will work on UNIX based OS's (Solaris, Linux, Mac)

IMO should be fixed in a 6.5 patch.
Comment 4 _ pcw 2008-11-04 20:23:30 UTC
Note to self:  The actual bug is ServerUtilities.getJarName, line 177 where it checks for "/" to determine if the jar
candidate is in a subfolder.  The current jar algorithm is calling this method using filenames derived from the file
system (thus the windows backslash is not normalized) whereas formerly the filenames came from manifest entries or
hardcode strings and were normalized.

Might be feasible to use File.separatorChar, but have to check, as this method is used elsewhere.  Checking for both \
and / is wrong, as \ is a legal character (however uncommon) on UNIX systems.
Comment 5 Vince Kraemer 2008-11-04 22:35:59 UTC
i will work this one.
Comment 6 Vince Kraemer 2008-11-05 06:31:33 UTC
Peter, do we have a list of the 'expected' files that will need to be part of the 'server library' that aren't currently
in the library?
Comment 7 Vince Kraemer 2008-11-05 07:01:24 UTC
Created attachment 73267 [details]
candidate patch
Comment 8 Vince Kraemer 2008-11-05 07:34:55 UTC
pcw: please take a look at this patch...  It seems to resolve the issue.
Comment 9 _ pcw 2008-11-05 08:29:32 UTC
Well, not really.  The rules are in the code -- IIRC, any jar in glassfish/modules or 1 level lower that has a
Bundle-Symbolic-Name field containing javax is included and all others are not.  The first group form the EE api jars,
the remainder, the implementation.

Unfortunately, I'm sure these rules will change.  Again.
Comment 10 _ pcw 2008-11-05 09:52:37 UTC
I presume from the nature of this patch that you decided switching to using FileObject was the best way to solve the
normalization issue?

A couple of nits:

* New null check at the beginning of filterByManifest is redundant.  Maybe replace with assert.  This method should
never be passed a null FileObject.  (Or, allow nulls and eliminate the null check in the caller).

* The logging formerly at the end of filterByManifest was removed.  It should either move to the caller or become an
else case on the null check mentioned above.
Comment 11 Vince Kraemer 2008-11-05 20:40:42 UTC
set Davis as the qa contact
Comment 12 Vince Kraemer 2008-11-06 23:23:10 UTC
Comment 13 Quality Engineering 2008-11-07 05:03:07 UTC
Integrated into 'main-golden', will be available in build *200811070201* on (upload may still be in progress)
Log: #152333: jars missing from GF library on windows.
Comment 14 Vince Kraemer 2008-12-01 19:25:25 UTC
*** Issue 153434 has been marked as a duplicate of this issue. ***
Comment 15 dpkumar 2008-12-02 09:27:52 UTC
This fix is verified in trunk IDE Build 200812011401
Comment 16 dpkumar 2008-12-02 09:29:05 UTC
Created attachment 74381 [details]
Screen shot
Comment 17 pslechta 2008-12-16 13:58:35 UTC
The fix was ported into release65_fixes repository.

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo