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 27123 - Provide equivalent of .instance loaded from project paths
Summary: Provide equivalent of .instance loaded from project paths
Alias: None
Product: java
Classification: Unclassified
Component: Unsupported (show other bugs)
Version: 3.x
Hardware: PC Linux
: P4 blocker (vote)
Assignee: Tomas Zezula
Keywords: API
: 27826 (view as bug list)
Depends on:
Blocks: 27112 27637 28450
  Show dependency tree
Reported: 2002-09-09 10:44 UTC by Svata Dedic
Modified: 2007-09-26 09:14 UTC (History)
1 user (show)

See Also:
Issue Type: TASK
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
Description Svata Dedic 2002-09-09 10:44:50 UTC
See #27112. Form Editor's Component Palette will
probably need to construct GUI beans from the user
project's classpath. If so, the "normal" .instance
files cannot be used as they use module
classloaders and will not be able to properly use

Provide InstanceCookie through a ProjectObject,
rather than DataObject and have instanceCreate to
use a classloader, which loads classes from
ProjectPath.RUNTIME classpath (or some derived,
Form-module provided one ?).
Should these InstanceObjects reside on project fs
or will be Component Palette global ?

Issues: what to do w/ several classpaths within
one project (different build targets with
different sets of libraries) ?
Comment 1 Tomas Pavek 2002-09-10 16:27:19 UTC
Some comments...

> Should these InstanceObjects reside on project fs or will
> be Component Palette global?

Currently, the palette is global (the instance files are placed in
default filesystem). For several reasons I think it should stay global
also in future.

The global form of palette makes some serious implications, e.g. like:
(1) as the classpath is defined by projects, some palette items
(defined by user) can be unavailable at the moment (depending on
opened project),
(2) it's hardly possible to deliver project context to instance file.

(1) requires the InstanceCookie provider to be able to recover from
errors (ClassNotFound...) when classpath changes (i.e. another project
is opened). This is where current InstanceDataObject fails.

(2) means that the InstanceCookie provider should probably use
classpath from all opened projects (so working still on DataObject,
not ProjectObject).

I guess these ideas can be wild for someone, so I'm waiting for
comments - before writing the other requirements ;-)
Comment 2 Svata Dedic 2002-10-02 08:04:32 UTC
Provided that you want to have the Component Palette global, then you
indeed need a merge of all classpaths from all projects for loading
your beans. This could be solved with the currentClassLoader() and/or
union filesystem (see issues #27112, #27386).

Though it's none of my business indeed, what is the user model for the
component palette ? Is it OK if it offers a bean from another project,
so the source becomes uncompilable ?
Comment 3 Vitezslav Stejskal 2003-04-03 16:11:27 UTC
*** Issue 27826 has been marked as a duplicate of this issue. ***
Comment 4 Tomas Pavek 2003-04-15 17:33:45 UTC
Well, it is not so obvious now if this will be really needed by form
module. See issue 27181 - form editor could probably handle this by
itself. In other words, it does not need whole InstanceCookie
functionality (needs just the class name), but on the other hand, more
stored information is needed (i.e. JAR/project an item belongs to).

More important seems to be the related issue with classloader (see
issue 27182). Should we create a new issue in java module for this? Or
reopen/reword issue 27826?
Comment 5 Tomas Zezula 2003-04-16 08:00:13 UTC
I am not sure about the use case of this feature. The FormEditor can
use a FileSet to store actual PMs and the currentClassLoader to create
instances as Svata has already described.

Priority changed from P1 to P4.

BTW: I don't want to make the Java module API like the Multics, "the
tool for everything".
If there is a simple way how to do it I don't see a reason why Java 
Module API should provide an additional contract.
Comment 6 Tomas Zezula 2003-07-17 14:59:46 UTC
See comments above, especially
 Additional Comments From Svatopuk Dedic 2002-10-02 00:04 PDT 
Comment 7 Jan Becicka 2003-11-25 14:04:45 UTC
As described in the
current work on projects prototype has been stopped.

Marking issue as VERIFIED --->
Comment 8 Jan Becicka 2003-11-25 14:13:54 UTC