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.
Could you introduce a Filter(NbEditor)Kit class. It could take in constructor another Kit instance and by default delegate all functionality to it. It would allow constructs like: EditorKit original = getEditorKitForMIME("text/xml"); class CustomizedKit extends FilterKit { CustomizedKit(EditorKit original) { super(original); } public Action[] createActions() { Action[] parentActions = super.createActions(); // enrich them and return them ... } } CustomizedKit kit = new CustomizedKit(original); registerKitForMIME("text/x-ejb-deployment-descriptor+xml", kit); I hope that it is allowed by the EditorKit specs.
I vote for this solution. I would appreciate it much. There are many examples where this could be applied : - special xml files like deployment descriptors, different configuration files (where we don't want to change editor kit) - special jsp files - special java files (like servlets, servlet-filters, servlet listeners)
Set target milestone to TBD
There is a risk of zombie classloaders once the kit provider module is uninstalled. To solve it a module should be able to dynamicaly add a dependency i.e.: EditorKit k = getEditorKitForMIME("text/xml"); String d = Modules.getProvider(k.getClass()); Modules.addDependency("my.module", d); Jesse would it work?
Re. dynamic module dependencies: no way. You can already in fact find which module owns a class, listen for it to be disabled, and if so disable yourself or take some special action (disable or refresh yourself), though I don't think it is a good idea. I guess you mean that the problem is that if module A (XML Text, e.g.) provides a kit for MIME type text/a, and module B (Ant, e.g.) provides a kit for text/b delegating to text/a, but B does not depend on A, then if A is disabled, the text/b kit will try to continue to delegate to the text/a kit, but AEditorKit.class is now in a zombie classloader and may or may not work. So solve the actual problem: when A is uninstalled, the text/b kit must stop delegating to A's text/a kit, and must revert to delegating to the generic kit (or whatever text/a would be bound to when A is disabled). One hacky possibility is that the FilterKit keep only a WeakReference to the delegate. If A is disabled, hopefully it unregisters text/a; the module system will run a full GC and so the prototype AEditorKit will get collected. The FilterKit should check for a null referent, and ask JEditorPane for a prototype kit again. Another approach is for the prototype FilterKit to not refer to its delegate at all; only keep the MIME type. When cloned, it should look up the prototype delegate kit and bind to it. This is not quite perfect - e.g. if a file of type text/b is open when A is disabled, it will continue to use AEditorKit so long as it stays open - but at least newly opened (or reopened?) text/b files will revert to delegating to the plain kit. Need to investigate whether it even makes sense to switch the delegate for an existing (non-prototype) EditorKit. Since a kit impl controls things like how to read/write from stream, the Document in memory could in principle not match the disk file: e.g. you read a .java file with guarded blocks using the Java kit, then switch to the plain kit and save it, and the //GEN-BEGIN:initComponents etc. disappear! The FilterKit would need to ensure that the document is not modified (prompt to save if necessary), discard the Document, and reload it, and maybe reload the Caret etc. etc. - kind of a mess.
I don't think we want to implement this. In fact our long term plan is to get rid of EditorKits from the editor APIs. EditorKit should be just an implementation artifact provided by the editor infrastructure to collect declaratively registered services from modules and hook them with the Swing text APIs.