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 14258 - Do not mount timerbean.jar and other beans in restore ()
Summary: Do not mount timerbean.jar and other beans in restore ()
Status: CLOSED DUPLICATE of bug 18312
Alias: None
Product: guibuilder
Classification: Unclassified
Component: Code (show other bugs)
Version: 3.x
Hardware: PC Linux
: P2 blocker (vote)
Assignee: issues@guibuilder
Depends on:
Reported: 2001-08-08 10:47 UTC by Jaroslav Tulach
Modified: 2013-01-21 17:45 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
Description Jaroslav Tulach 2001-08-08 10:47:28 UTC
Please rewrite the mounting of beans to use module layer instead of
module.restored code. At least the timerbean should be provided in module layer.

See usersguide for example how to do it.

I talked with Trung about the problem and he tried to convince me that
everything is more complicated than I see, so if you will encounter any
problems, let me know, I'll be glad to help.

But in general if you place the timerbean into module layer, you can delete
GlobalJarFileSystem because it will be global from definition.
Comment 1 Tomas Pavek 2001-08-08 14:36:36 UTC
Yes, it is more complicated.

Mounting the TimerBean.jar is a part of "beans autoloading" process. 
This way beans can be installed just by putting JAR files to beans 
directory (out of IDE). An important side effect is that it's ensured 
that all the JARs in beans directory are mounted. This is done also 
for beans already installed before - so theoretically we would not 
have to care about their JARs. Unfortunatelly this was not true so 
far due to problems with projects and Co., causing various 
neverending "TimerBean problems". The GlobalJarFileSystem is just 
another hack to deal with these problems. We used to listen to 
project opening before...

Now (in last builds) this redundant mounting causes the JARs to be 
mounted again each time the IDE is started, because when autoloading 
is running, the filesystems are not restored yet, so the autoloading 
process thinks that the JARs are missing and mounts them.

If we can rely on the JAR filesystem presence now and for the future, 
then we can modify the autoloading.

But we still cannot avoid mounting new JARs during autoloading for 
beans *not* installed yet. (Then we had to cancel the autoloading 
completely.) This is also the case of the Timer bean during the first 
start. We can handle the TimerBean JAR using module layer, but then 
we would have to make some hack to exclude the TimerBean.jar from 
autoloading. But I hate to make another "TimerBean" hack. The 
simplest way would be to place the TimerBean.jar somewhere else than 
in "beans" directory, but where?

Anyway, I think that the whole "TimerBean" stuff should be moved to 
usersguide module. It is just an example of bean, similar to other 
examples, so why it should be in Form Editor? Usersguide could 
install the JAR as well as the bean through the module layer. The 
only problem to solve is where to place the JAR...

BTW we still need GlobalJarFileSystem for dynamically installed beans 
from JARs - unless there was another way how to create "global" 
filesystems (module layer is of course not usable here)...

(Well, you were warned this is a bit more complicated...)
Comment 2 Jaroslav Tulach 2001-10-18 15:14:42 UTC
The form module causes significant problems to core trying to add its
TimerBean.jar into repository each time the IDE starts. Because the
core has to remove it when opening project.

Please consider this as high priority issue for next development
Comment 3 Tomas Pavek 2001-12-03 17:58:11 UTC
I've made a TASK issue 18312 for tracking rewrite of "beans 
autoloading", Timer bean placement and behavior, and related issues 
(which I don't think to be Form Editor bugs in 3.3).

*** This issue has been marked as a duplicate of 18312 ***
Comment 4 Quality Engineering 2003-06-30 18:20:25 UTC
Resolved for 3.3.x or earlier, no new info since then -> closing.
Comment 5 Quality Engineering 2003-06-30 18:28:25 UTC
Resolved for 3.3.x or earlier, no new info since then -> closing.