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.

Bug 135951 - Visualweb is completely broken because of incomplete implementation of "classpath/packaged" classpath type
Summary: Visualweb is completely broken because of incomplete implementation of "class...
Status: RESOLVED DUPLICATE of bug 136016
Alias: None
Product: javaee
Classification: Unclassified
Component: Web Project (show other bugs)
Version: 6.x
Hardware: All All
: P1 blocker (vote)
Assignee: Milos Kleint
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-05-28 03:17 UTC by _ deva
Modified: 2008-05-30 14:58 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description _ deva 2008-05-28 03:17:32 UTC 
In case of visualweb while constructing designtime classloader, we look for "classpath/packaged" classpath type, if it 
exists we use it get the classpath entries. Otherwise, we get the "classpath/compile" classpath and remove the app 
server jars ourselves. See http://www.netbeans.org/issues/show_bug.cgi?id=130231 and 
http://www.netbeans.org/issues/show_bug.cgi?id=131785

Now we see that web project supports "classpath/packaged" classpath type, but the classpath entries from it are empty, 
hence our classloader doesn't have the right urls in its classpath. Because of this we have a P1 bug 
http://www.netbeans.org/issues/show_bug.cgi?id=135929
Comment 1 David Konecny 2008-05-28 03:50:09 UTC 
Web project does not support "classpath/packaged" - this was not implemented yet; issue 131785 tracks this. So until
131785 is implemented you should keep your workaround in place. That was agreement. Or has something changed?
Comment 2 _ deva 2008-05-28 04:16:37 UTC 
Why do I get a ClassPath object with empty entries when I ask for "classpath/packaged" classpath

I had the logic to test for "classpath/packaged" classpath type first and then use the workaround. This used to work 
fine till recently. What has changed for this to fail?
Comment 3 David Konecny 2008-05-28 04:48:12 UTC 
No changes on web side AFAIK. Do you have Maven pluging installed? That's probably the only one who returns something
for this classpath type. Disable it and if everything works talk to Milos Kleint. If you do not have Maven then debug
classpath provider and you should quickly see the culprit.
Comment 4 Lukas Jungmann 2008-05-28 07:32:39 UTC 
could it be caused by issue 134341 ?
Comment 5 David Konecny 2008-05-28 11:40:33 UTC 
I would not think so but you never know.
Comment 6 _ deva 2008-05-28 16:37:48 UTC 
When I debugged further, I did see that the changes for http://www.netbeans.org/issues/show_bug.cgi?id=134341 is 
causing the problem. Because of those changes, when you ask for a classpath type which doesn't exist, it simply 
creates a new empty one, see line 104 to 114 in org\netbeans\spi\java\project\support\ClassPathProviderMerger.java
Comment 7 David Konecny 2008-05-28 23:03:32 UTC 
deva, thanks for debugging it.
Comment 8 David Konecny 2008-05-28 23:06:40 UTC 
Milos, ClassPathProviderMerger issue. Could you have a look please.
Comment 9 Milos Kleint 2008-05-29 07:51:28 UTC 
oh, oh..
I'm sorry. I haven't thought of that when doing the merger. But the merger needs to return an instance in any case,
which unfortunately means I have to hack a special workaround for classpath/packaged until the web projects implement it.
Comment 10 Milos Kleint 2008-05-30 14:58:12 UTC 
i suppose a duplicate of issue 136016, i've hotfixed that one. the hotfix can be removed once dkonecny implements issue
131785 





*** This issue has been marked as a duplicate of 136016 ***