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 26798 - move Natures definition on system filesystem
Summary: move Natures definition on system filesystem
Status: RESOLVED FIXED
Alias: None
Product: projects
Classification: Unclassified
Component: Generic Infrastructure (show other bugs)
Version: 3.x
Hardware: All All
: P1 blocker (vote)
Assignee: David Konecny
URL:
Keywords: API
Depends on:
Blocks:
 
Reported: 2002-08-27 09:27 UTC by David Konecny
Modified: 2003-12-11 14:25 UTC (History)
0 users

See Also:
Issue Type: TASK
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description David Konecny 2002-08-27 09:27:37 UTC
Originally simple tasks is getting more
complicated. I'm recording it into issuezilla just
to track what I'm working on. 

The problem which appeared is that if nature is on
system filesystem the project filesystem is
composed of a filter filesystems which wraps
project natures. The problem is that Project.find
does not work for the instances created from this
filter filesystem. The solution we discussed with
Vita is to wrap also the fileobjects created on
FilterFS. Hopefully no other problems will appear.
Comment 1 David Konecny 2002-08-27 09:29:19 UTC
Description does not sound very descriptive. If necessary I can
provide more info. 

Adding API and M3 keywords.
Comment 2 David Konecny 2002-08-28 15:00:41 UTC
Implemented in:

Checking in
projects/src/org/netbeans/modules/projects/FilterFileObject.java;
new revision: 1.1.2.1; previous revision: 1.1
Checking in
projects/src/org/netbeans/modules/projects/FilterFilesystem.java;
new revision: 1.1.2.1; previous revision: 1.1
Checking in projects/src/org/netbeans/api/projects/Project.java;
new revision: 1.1.2.28; previous revision: 1.1.2.27
Checking in
projects/src/org/netbeans/modules/projects/wizards/ProjectLocationPanel.java;
new revision: 1.1.2.7; previous revision: 1.1.2.6

Checking in
projects/src/org/netbeans/modules/projects/resources/generic-nature.xml;
new revision: 1.1.2.4; previous revision: 1.1.2.3
Checking in
projects/src/org/netbeans/modules/projects/resources/projects-layer.xml;
new revision: 1.22.2.47; previous revision: 1.22.2.46

Checking in
web/core/src/org/netbeans/modules/web/project/resources/layer.xml;
new revision: 1.1.2.10; previous revision: 1.1.2.9
Checking in
web/core/src/org/netbeans/modules/web/project/resources/web-nature.xml;
new revision: 1.1.2.3; previous revision: 1.1.2.2

Checking in java/src/org/netbeans/modules/java/resources/java-nature.xml;
new revision: 1.1.2.5; previous revision: 1.1.2.4
Checking in java/src/org/netbeans/modules/java/resources/mf-layer.xml;
new revision: 1.26.6.14; previous revision: 1.26.6.13
Comment 3 David Konecny 2002-08-28 15:23:25 UTC
Let me provide more info about the problem & solution.

The problem lies in behaviour of MultiFilesystem. Imagine you have MFS
composed from fsA and fsB. If you ask a file from MFS for an attribute
which value is defined as methodValue, the method is called and the
FileObject passed to this method is FileObject either from fsA or from
fsB, but (and this is _important_) definitely not FileObject from MFS.
This is as I heard know problem of MFS, which does not have solution
at the moment.

The project filesystem is MFS and what happened was following. Some
nature registered instance with methodValue and in its method the
first call was Project.find(FO) where FO is parameter passed to
methodValue. If the FO was FileObject from ProjectFS then the project
would be find. Unfortunatelly because of behaviour of MFS I described
above the passed instance was not from ProjectFS, but (in this case)
FO from systemFS on which the nature definition lies. For this FO, the
Project.find cannot find the project.

The solution (or to be honest _hack_!) is that I created
FilterFilesystem and FilterFileObject. Instance of this FS is created
for each nature and project. It wraps original FOs from systemFS _and_
when FilterFileObject.getAttribute is called, the ThreadLocal variable
(FilterFileObject.CONTEXT) is used to store the Project. If
Project.find fails to found project, it checks this variable and if it
is set, this project is used.