Performance test reports there is a NetBeans startup regression which is caused by the loading of the following classes:
Please don't load these classes during NetBeans startup.
Additional comment from jtulach: "I gave them an exception. Maybe report bug to fix this for post-6.5."
Created attachment 66450 [details]
We will look at it after NB 6.5.
P4 - we need these classes now, keep it just as a reminder - will be evaluated later
There is no way how to achieve this functionality by declarative mime-resolver. Reassigning to core for deeper eval. to
come up with any idea.
I would like to ask for review of my changes in declarative MIME resolvers. I added two new elements to MIME resolver
DTD. Element 'name' is intended for file name checking (issue 118977). For example this
<name name="makefile" substring="true"/>
matches files like makefile, Makefile, gnumakefile, etc.
Element 'pattern' inspired by PhpMimeResolver is intended for checking string pattern in file content. For example this
<pattern value="<HTML>" range="255" ignorecase="true">
<pattern value="<?php" range="4000"/>
matches files with '<HTML>' in first 255 bytes and '<?php' in first 4000 bytes (checked only if outer condition is
I also added a logic that <ext name=""/> matches files without extension. Using these new elements I rewrote procedural
ShellScriptResolver, RubyMimeResolver, CndSniffyMIMEResolver and PhpMimeResolver. Only CndMIMEResolver is remaining in
standard distribution. It is possible to rewrite it but there is some UI in Options dialog connected to it.
I will attach separate diff for openide.filesystems and separate for other modules (php.project, cnd, ruby,
languages.sh). Comments welcome. Thanks.
Created attachment 73152 [details]
Changes in openide.filesystems.
Created attachment 73153 [details]
Changes in php.project, cnd, ruby, languages.sh.
Y01 Too little documentation. I really like your description in this issue, however most of the people will only read
javadoc and for them you have just two lines in apichanges. That is not enough, imho. Is not there a special page
about mime resolving that needs to be updated?
Y02 Versioning. Update the version number and make all modules that use the new functionality request this version of
Y03 Right now one can match name as substring, would not it be better to offer match by regexp?
Y04 The "#!" needs to be at beginning. Then there can be spaces and then "/bin/sh". The proposed change checks for
different situation. Maybe one could specify "^#! */bin/sh" regexp?
Y05 The php resolver reads 255 and then 4000 bytes. That is 4255, which is more than 4192. How much bytes are read by
the infrastructure? If 4192, then this resolver causes two disk touches and that is not good, imho.
I will attach new patches. Except below mentioned changes I fixed functionality of the <exit/> element. Now it escapes
resolving if conditions are fulfilled. No next <file> element is checked.
> Y01 Too little documentation.
I added topic to wiki (http://wiki.netbeans.org/DevFaqMIMEResolver) and updated existing documentation at
org.openide.filesystems.doc-files. Examples are in comments of elements in DTD documentation (linked from wiki).
> Y02 Versioning
> Y03 Right now one can match name as substring, would not it be better to offer match by regexp?
Regex is time expensive. At the time I was not able to rewrite only two hopefully corner cases in ruby. Files with
"#!/bin/rubystuff/bin/ksh" and "#! /usr/b\nin/ruby" header are mistakenly resolved as ruby files. Tor could comment
whether it is a blocker for removal of procedural RubyMimeResolver.
> Y04 Maybe one could specify "^#! */bin/sh" regexp?
It is more or less fulfilled by the following construct:
<pattern value="#!" range="2">
<pattern value="/bin/bash" range="40"/>
> Y05 The php resolver reads 255 and then 4000 bytes. That is 4255, which is more than 4192.
A range attribute of the pattern element always means number of bytes from the beginning. I checked it and there was a
mistake in MIMESupport.CachedInputStream which I fixed. So now only 4000 bytes are read if there are two embedded
pattern elements. I also added an assertion into MIMEResolverImpl (if a resolver wants to read more that 4000 bytes).
Created attachment 73582 [details]
Changes in openide.filesystems - version2
Created attachment 73583 [details]
Changes in php.project, cnd, ruby, languages.sh - version2.
Seems, I don't see makefile declarative resolver in your changes, only in examples.
+ do not see where /cnd/src/org/netbeans/modules/cnd/resources/mime-resolver-content-based.xml
catch lines like:
#![any number of spaces]/bin/bash
in fact, this is responsibility of sh module, so you can review shells declared by cnd and remove it from cnd completely
by adding into sh module (cnd declared shell resolvers, only because sh module didn't)
I can comment on CndMIMEResolver.
As I understand you handle declarative resolvers and fill some internal infrastructure with it.
- programmatic way to get all extensions associated with interested mime-type
- programmatic way to add new extension for interested mime-type + this must be persisted between sessions
In this case we can easily stay with our UI and will remember in own preferences default extension.
Btw, having "default extension" attribute provided by your infrastructure would be useful for us as well. Default
extension is used when new file of correspondent mime-type is created (try to create new C++ file)
> VV: Seems, I don't see makefile declarative resolver in your changes, only in examples.
It is in CndMIMEResolver and I didn't touch it at all.
> VV: #![any number of spaces]/bin/bash
Yes, it is covered by nested <pattern> element.
> VV: you can review shells declared by cnd and remove it from cnd completely.
OK, I will move shell script resolvers to languages.sh module.
> VV: - programmatic way to get all extensions associated with interested mime-type
Theoretically possible. But I doubt it is necessary to offer to choose extension while creating a new file. It could
offer default file name like newmain.cpp with possibility to edit it.
> VV: - programmatic way to add new extension for interested mime-type.
To add a new extension is possible in Tools > Options > Miscellaneous > Files. I don't think there should be two ways of
doing the same thing.
> VV: Btw, having "default extension" attribute provided by your infrastructure would be useful for us as well.
It doesn't make sense for MIME resolvers to define something like "default extension". It should be handled in cnd if
you need it.
I will integrate proposed changes. I filed issue 153204 and issue 153202 to separatelly track changes necessary for
[JG01] You cannot add new elements to an existing DTD. You need to make a separate DTD with a new public ID, e.g.
"-//NetBeans//DTD MIME Resolver 1.1//EN", and use this public ID on the resolvers you are changing. The new DTD needs to
be registered into the system catalog (currently in o.n.core/src/org/netbeans/core/resources/mf-layer.xml, though
perhaps these entries would better be moved to openide.filesystems), and should probably also be published at
to match the documented remote system ID.
Integrated into 'main-golden', will be available in build *200811191401* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
User: Jiri Skrivanek <email@example.com>
Log: #142760 - Added new elements to declarative MIME resolver DTD. The name element to check file names and the pattern element to check file content. Procedural resolvers ShellScriptResolver, RubyMimeResolver, CndSniffyMIMEResolver and PhpMimeResolver were rewritten using these new features.
Integrated into 'main-golden', will be available in build *200811220201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
User: Jiri Skrivanek <firstname.lastname@example.org>
Log: #142760 - MIME resolver DTD version increased.
Verified with 081125
*** Bug 118977 has been marked as a duplicate of this bug. ***