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.
Randomly reproduced on deadlock during c/v tests run. no specific steps to reproduce. Newly created XML Document recognized as PHP file (see attached screen shot)
Created attachment 65378 [details] screen shot
Probably should be component 'php', no?
Created attachment 65500 [details] the same problem with ruby files
meta-inf registered mime resolvers often need to lookup in the content of file, definitely true for php mime resolver. php resolver expects to be called just in case when declarative resolvers were not able to resolve (forlorn hope). Order affects also performance. Evaluating this issue I see that declarative mime resolvers were: - moved to openide.filesystems - logic isn't as I expected Simple fix should be enough to fix this problem - just calling of declarative resolvers first (see attachment). I'm not sure if this fix is OK and will not lead to other problems. Reassigned to core, please review the fix and apply or reassign back to me (but please then comment and let me know the way how to fix it). Increasing priority.
Created attachment 65503 [details] suggested patch
thanks for evaluation
*** Issue 141333 has been marked as a duplicate of this issue. ***
I think the suggested patch makes sense. (MIMEResolver.java's Javadoc would also need to be changed.) BTW I don't follow why the procedural PHP resolver is recognizing XML and Ruby files, regardless of the order in which it was invoked. This looks like a bug in the php component to me.
I don't see any bug in php mime resolver yet. php mime resolver doesn't care about name or extension (and cannot reliably), just finds pattern <?php. When I implemented it I relied on the fact that ruby (and other well known) files are already resolved and for the unrecognized files is OK to say "its php" if contains <?php. php tags can be easily processed no matter whether file is *.php or *.xml (especially if run as command line - where no apache config.is needed)
I don't see any "<?php" in the main.rb in the screenshot, and it would be pretty weird if the XMLDocument.xml in C/V contained this string. Why would the PHP procedural resolver claim these files?
The only problem might be that as soon as I resolve a file as a php, then its extension is kept and all other files with such extension are considered as php. 2 reasons for doing it: 1.perf., 2. editing a file - deleting a recreating a characters <?php would lead to different mime types in time - which is something that NB isn't ready for as far as I know.
I don't follow rmatous's last comment. The only problem with what? Who is "keeping" an extension? All I asked in my last comment was why files which do not appear to have anything whatsoever to do with PHP are being claimed by its resolver. Invoking that resolver much later might reduce the symptoms of its bugginess but that would not make it correct.
My previous comment is answer to you last comment about missing <?php in the screenshot. I could also add that other *.rb file could contain <?php sequence or even file in the screenshot contained also missing "hp" to complete "<?php" and so on. Naturally I can have a bug in the code, but I don't know about it yet.
> I don't follow rmatous's last comment. The only problem with what? Who is "keeping" an extension? php mime resolver as soon as finds mentioned magic chars will claim it php file. Lets say the magic chars are found in *.rb then all *.rb files will be later resolved as php files by this mime resolver (reasons explained). Extension is kept by php mime resolver for later use (as explained above). >All I asked in my last comment was why files which do not appear to have anything whatsoever to do with PHP are being claimed by its resolver. How should I know which files have something to to do with PHP. OK I can check extensions "*.rb, *.rhtml" (BTW already fixed) and else? Should I enumerate all known extensions. As I mentioned it could be absolutely OK to treat *.xml files as php (even someone mentioned it once like a real use case). If there was api that would return me all registered extensions in NB I wouldn't recognize them as php (but its not necessary if my resolver was called as the last one). >Invoking that resolver much later might reduce the symptoms of its bugginess but that would not make it correct. Not sure whether I understand which bugginess you have in mind (in condition that order is fixed according to patch). If someone will find a bug, I'm ready to fix it.
Recognizing all *.foo files as PHP just because some.foo happened to contain "<?php" seems dangerous to me.
In the scenario I ran into, there were no files that contained "php" anywhere inside them (JavaApplication3, RubyApplication33 in my screenshot). I think the userdirectory was new too, but I'm not 100% sure about that. The reason there are HTML tags and "<?p" in the screenshot is that I suddenly noticed the PHP icon in the file explorer, and since I thought the file had no syntax highlighting (all text was black with just the Ruby code there), I added some HTML markup, noticed element syntax highlighting, then added <?p to see if I could get PHP code completion too (which I did.) > "How should I know which files have something to to do with PHP. OK I can check extensions "*.rb, *.rhtml" (BTW already fixed)" I assume you meant "have -nothing- to do with PHP", in other words, .rb and .rhtml (or any of the 10 other Ruby standard file extensions referred in ruby/src/**/RubyMimeResolver.java) will never be treated as PHP, correct?
> In the scenario I ran into, there were no files that contained "php" anywhere inside resolver looks for either for "<?php" or "<?[whitespace]" (also called short tag). Definitely the code on the screenshot isn't recognized as php file for me(thus cannot reproduce). > I assume you meant "have -nothing- to do with PHP", yes > in other words, .rb and .rhtml (or any of the 10 other Ruby standard file extensions referred in ruby/src/**/RubyMimeResolver.java) will never be treated as PHP, correct? If your RubyMimeResolver.java will be called before php mime resolver, then these ruby files will never be treated as PHP if your mime resolver works fine :) naturally. If my resolver will be called befor yours then it depends whether "<?php" or "<?[whitespace]" will be found in those file (just in first 4kB - which is limit that was permitted me by perf.team - this can btw. also lead to unreliable resolving).
Treating anything with "<? " as a PHP file seems wrong to me. This could just be any XML processor instruction (I think).
You are right. "<?xml" is common, not sure about "<? ". "<? " is going to be deprecated (not yet) and still often used instead of "<?php". If my mime resolver was the last one, then such file could be php file(instead of unknown), actually why not. Not sure if it is worse to mark not php file as php file than not recognize php file and treat it as unknown.
Correction: <?foo bie="bletch"?> is a valid XML processor instruction, but <? foo bie="bletch"?> is not. Still, "<? " seems like a pretty generic character sequence that is not obviously indicative of PHP.
If it seemed to be a problem we could consider not to support short tags("<? ") as default, but this is question for Petr Pisl, but I wouldn't solve it earlier than the order will be changed and until we run into any problems related to it. If someone let me know what other indication I should use, I will do it (probably someone familiar with php - Tomas, Petr any idea?).
> Recognizing all *.foo files as PHP just because some.foo happened to contain "<?php" seems dangerous to me. why, if there was guaranteed that nobody else handles *.foo files because php resolver is last and moreover the file contains "<?php"?
Radek defines his resolver in META-INF.services/org.openide.filesystems.MIMEResolver this way: org.netbeans.modules.php.project.PhpMimeResolver #position=999 Is there an option to get position number from lookup and sort accordingly within declaritive resolvers? I am afraid there isn't because MetaInfServicesLookup.Item.position is private. In that case seems to me appropriate to apply Radek's patch.
> not to support short tags("<? ") as default We _have_ to support short open tags because _many_ existing PHP projects use short open tags - but this is must for editor. I think that we could remove short open tags detection from this MIME resolver because all our templates use "<?php". However more important issue is IMHO in the ordering of MIME resolvers.
Patch applied and javadoc updated. http://hg.netbeans.org/core-main/rev/10d30eec11f7
Right, we can't intermix M-I/s resolvers with Services/MIMEResolver resolvers meaningfully. MIMESupport Javadoc did not need to be touched; it is package private. But may be helpful for someone reading code.
I agree with Tomas. For this resolver is important mainly <?php, because we use only this delimiter in our templates.
short tags don't indicate php files anymore, fixed: http://hg.netbeans.org/main/rev/280928439638
verified