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: | Security exception from disabled TimerBean instance | ||
|---|---|---|---|
| Product: | guibuilder | Reporter: | Jesse Glick <jglick> |
| Component: | Code | Assignee: | issues@guibuilder <issues> |
| Status: | CLOSED DUPLICATE | ||
| Severity: | blocker | CC: | jpokorsky, jzajicek |
| Priority: | P3 | ||
| Version: | 3.x | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Issue Type: | DEFECT | Exception Reporter: | |
| Bug Depends on: | 14024 | ||
| Bug Blocks: | |||
| Attachments: | AccessControlException from timerbean instance | ||
|
Description
Jesse Glick
2001-07-23 14:04:35 UTC
Created attachment 1933 [details]
AccessControlException from timerbean instance
*** Issue 13895 has been marked as a duplicate of this issue. *** It is not harmless - the Timer bean is quite unusable (e.g. dev build 20010725). When instantiated (e.g. be InstanceDataObject), it tries to start its thread - but this fails on security restriction (see the exception). Some security policy must have been changed, as this worked so far... Opinion of core? This one depends on 14024. assigning The bug is in InstanceNode.initName it MUST NOT ever call instanceCreate. I guess looking at this, it seems that (1) yes InstanceNode should avoid creating the instance if it can in fact avoid it, at least for performance reasons; (2) the security exception is correct - code loaded from a user filesystem cannot be trusted and should run in a sandbox; (3) the TimerBean is probably mostly to blame for starting a thread in its constructor, which is not very polite behavior for a bean IMHO: a bean to be used at design time should cause no side-effects just by construction; in this case it should do nothing until start() is called on it. Since (1) is already being worked on and (2) is I think correct, I would vote for this bug to be reassigned to the Form Editor for shipping an impolite example. I agree. I see two possible solutions. (1) fix the TimerBean behavior as Jesse proposed, (2) define TimerBean in a module layer + annotate the file with SystemFileSystem.localizedBundle. It would be greate to do both. Reassigned to the Form Editor. Target milestone -> 3.3.1. 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 *** Timer bean has just been changed - starts no more in ctor. Resolved for 3.3.x or earlier, no new info since then -> closing. Resolved for 3.3.x or earlier, no new info since then -> closing. |