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.
I have subclasses of JavaDataObject, JavaNode, and JavaDataLoader. In addition to java/class files, I recognize a secondary important file which has my own extension and is an xml file. In NB 3.3.2, I added a mime resolver to the layer, but didn't tie it to the loader - just gave it a hint whether files of my extension are binary or text by setting the mime type. Now I load my module in 3.4 dev and my loader is active with my special icon and node, but in addition to that node, I see an extra xml node in the explorer for my secondary file. This is a regression.
Rochelle, can you try to disable some (especially XML) modules in the 3.4 distribution? The problem may be caused by interaction with those modules...
If I disable all the xml modules, it works properly. I didn't try figuring out which of them (a smaller subset) would do the trick. Also, I got some errors (mostly about zombie class loaders) when disabling. I'll attach my log.
Created attachment 6451 [details] Log file
Fine to hear that if XML module is disabled, everything works. In such case, do not disable the module and go to Tools/Options/.../Object Types and change order of the loaders, so your loader is placed before the loader of XML. That should also work. In order to make it work by default, add Install-Before section into your loader definition manifest section to place it before the XML loader... I am closing this issue, because there is no problem in infrastructure, just in communication between pieces of the system. Also it is not regression - if you install XML modules in 3.3 version (are on autoupdate) you will very likely recieve the same behaviour.
Sorry, but it *is* a regression. I have all 6 xml modules installed in FFJ 4.0 (3.3.2 NB base) and there's no problem. This only happens in 3.4. Could it have something to do with the fix for issue 22628? If it turns out that I now need to list the xml data object in my before list, that's fine, but this needs to be documented in the upgrade guide since the behavior has changed.
Ok. It works without xml modules installed, so if there is any regression it is in xml modules. changing component -> xml
Declare loaders order as Yarda suggested. XML module now recogniizes all files with +xml MIME type suffix. It is not regresion, it is feature. Is it all right?
It's okay with me as long as you add it to the upgrade guide and if you discuss it with Evan and he doesn't consider this a 3.3->3.4 regression. At the very least, this requires documentation.
Sorry, but it is not infrastructure regresion. Besides we contacted Andrew Sherman and Jesse Grodnik and asked them if they need to define some XML infrastructure. They replied: The only thing we need is to add Xalan to binaries (as nice to have). We can add it to XML module FAQ. Upgrade guide is not good place for module issues. John could you handle it.
Turning to task as it is not P2 bug in XML modules.
Set target milestone to TBD
Is there something that 3.4 users need to know about this? If so, could somebody suggest some text that I could put in the readme?
Suggestion: 3.4 XML module handles in generic manner wider family of XNL documents. It may affect a functionality of currenty intalled modules. User have to go to Object Types and reorder loaders accordingly.
I am not inclined to include this in the readme for NB 3.4 (end users) as the problem does not occur with any modules in the standard distribution, so it's hard to be explicit in the description of the problem or the remedy. I also wonder if there is the danger that the remedy might be worse than the problem (if the user does not know which object types to reorder). Here's my attempt at the release note. If somebody can't improve on this or reassure me, I will not include it: "If you have installed an extension module that uses special XML objects, the objects may appear as multiple nodes in the Explorer and behave differently than they did in the NetBeans 3.3 release. Workaround: Choose Tools | Options. Then expand IDE Configuration | System | Object Types. Under Object Types, find the node that represents he type of object that is not being represented correctly in the Explorer. Right click the node and use the Move Up command to place that object type before the type of XML object that the IDE is treating it as."
I'm not really keen on the proposed release note text; sounds like something module authors should be taking care of, not users. I will add a note to the 3.4 Upgrade Guide (shipped with the APIs). Note to Petr: the upgrade guide already includes highlights of changes in module APIs (or behavior) of special interest to other module developers, it is fine to add such a note there.
Still release note makes sense. User may be hit by it if a module author does not preorder loaders using layer. If migration guide can contain hint without any warranty (I strongly dislike to export XML data object class name) I can mention it there. Suggested note start: "If you have installed an extension module that handles special XML objects and it does not seem to have desired effect then try" ....
I have added a note to the upgrade guide: http://www.netbeans.org/source/browse/~checkout~/openide/api/doc/org/openide/doc-files/upgrade.html#3.4i-xml-mime Could still have a release note item for end-users, I don't have an opinion. Re. exporting XMLDataObject class name: sorry, that's exactly what you have to do in order to let people order relative to it... it's not supposed to be a guarantee that the class name will never change. The upgrade guide is supposed to be practical, not a definition of the APIs. See also issue #21104 for another example of the same type of phenomenon, this time for 3.3 though.
Updrade guide note text sounds good. I think it is worth to mention it in end user release notes as well. Why should we inform developers only?
Petr, my concern is that it is hard to write the release note in a way that means anything to the user. By the time they see the problem, they probably will have forgotten about the release note. Also, I don't think it's a good idea to tell them to change the order of loaders without specific instructions on what to change. If I don't release note this bug, it won't be the only. I'm mainly concentrating on the ones that have severe effects and that affect a lot of users. I don't think this one will affect that many users. Am I wrong?
It is hard to predict. I affect all users that install such a module.
Requirement for new loaders is to resolve secondary files ownership overlaps.
Lost task, marking it as invalid. Please open a new issue if you disagree.