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.
Hi. After the rewrite of loaders: http://wiki.netbeans.org/FitnessAgainstForgetfulness I re-registered all loaders to use new scheme, but I could not handle all of them. So loaders seem to be missing their own mime type. This is bad, as it makes them eagerly loaded on startup - we need to fix it for 6.5. Please fix: org-netbeans-modules-j2ee-sun-ddloaders-SunDescriptorDataLoader and other loaders that you recognize under Loaders/content/unknown/Factories in various layer files. That folder shall be empty. Thanks.
Hi Peter, can you fix this, please?
Certainly, but I may need some help here -- FileType wizard requires either file extension or XML Doctype. This loader handles SUN DD's which are XML files, but the dataobject is required to handle indeterminate state when doctype is being changed, such as if the user is upgrading or downgrading the descriptor version. Currently this is handled by being an XML Dataloader but matching on file name (sun-web.xml, etc.) rather than the DOCTYPE. How do I solve this problem with the new design? It doesn't appear that the currently solution is allowed anymore.
Basically ask yourself: What is the mime type of the file that you want to recognize? Presumably it is not "content/unknown". As such register your loader into that mimetype. In case you have multiple mimetypes, feel free to register your loader into multiple places.
As I recall, mimetypes for XML files are connected to the DOCTYPE declaration (or schema header, but those are not involved here) of the XML file. We have a single loader that supports over a dozen distinct DOCTYPES for all the sun-???.xml files from AS 7.0 through AS 9.1. The interesting use case is if the user is changing the version of sun-web.xml (or other) from one version to another. There is an intermediate state where the DOCTYPE is not valid (no mimetype at all) and of course, if it becomes valid again, it presumably will be a different mimetype. In all of these states, even the invalid case, I want our dataloader to be the one called to handle the file, hence why the existing dataloader triggers on filename. I can just try it the new way and see what happens, but I suspect something bad will happen in the editor when I attempt to change the version. I don't suppose there is a way to map a mimetype to an entire file name (not just an extension)?
This is the spec: http://bits.netbeans.org/dev/javadoc/org-openide-filesystems/org/openide/filesystems/doc-files/HOWTO-MIME.html I do not think anybody maintains it, but if you miss ability to match whole filename, then feel free to submit API enhancement as a patch...
You can always use a procedural MIMEResolver implementation if the declarative XML format is not powerful enough.
I added declarative entries based on the root node name (sun-web-app, sun-ejb-jar, etc.). I think I may need/want to add a procedural mime-resolver for a more correct solution, but for now, this follows the new design and gets the Sun DD Editor working again. http://hg.netbeans.org/main/rev/43c119d445d4 Marking fixed.
Yarda you may want to review this - looks like there are still multiple loaders registered under a single MIME type in a few cases, which is probably a mistake. The recent patch seems to have added new registrations but not cleaned up the old ones.
Then also consider this diff (removes Yarda's <unknown> entry for the Sun DD loader - I removed it after pushing the original patch) http://hg.netbeans.org/main/rev/32e22f6dff04 I reread the issue description. I see the original issue applied to many loaders under content/unknown, not just the Sun DD Loader. Not sure which ones though -- there are a few left from what I can tell via <layer in context> and a grep through all the layer files. JavaEE standard descriptor loaders are not addressed by this patch. I filed issue 137853 to fix the JavaEE loaders.
http://hg.netbeans.org/main/rev/25853bf0447f