This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
| Summary: | Subfolder jars from V3 are not included in web project classpath on windows. | ||
|---|---|---|---|
| Product: | serverplugins | Reporter: | wimv <wimv> |
| Component: | GlassFish | Assignee: | Vince Kraemer <vkraemer> |
| Status: | VERIFIED FIXED | ||
| Severity: | blocker | CC: | pcw, sustaining |
| Priority: | P2 | ||
| Version: | 6.x | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Issue Type: | DEFECT | Exception Reporter: | |
| Attachments: |
screenshot of "Glassfish V3 Prelude" server libraries in Netbeans 6.5 on windows xp
candidate patch Screen shot |
||
|
Description
wimv
2008-11-04 18:30:45 UTC
Created attachment 73221 [details]
screenshot of "Glassfish V3 Prelude" server libraries in Netbeans 6.5 on windows xp
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. 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. 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. i will work this one. 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? Created attachment 73267 [details]
candidate patch
pcw: please take a look at this patch... It seems to resolve the issue. 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. 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. set Davis as the qa contact Integrated into 'main-golden', will be available in build *200811070201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/6c7ddc78a5c2 User: vkraemer@netbeans.org Log: #152333: jars missing from GF library on windows. *** Issue 153434 has been marked as a duplicate of this issue. *** This fix is verified in trunk IDE Build 200812011401 Created attachment 74381 [details]
Screen shot
The fix was ported into release65_fixes repository. http://hg.netbeans.org/release65_fixes/rev/90c243bb85b8 |