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.
Description: BuildID : RC2 & RC5 JDK : 1.4FCS OS : Solaris8 & Solaris9 Ja To Reproduce : - Mount "application" directory as local directory,load Wizard "New Wizard - Session Bean" - Create <multibyte>EJB Session Bean - Right Click,<multibyte>EJB Bean node choose "Create NewEJB Test Application" from the context menu. - Choose default values,click OK - Highlight the <multibyte>J2EE Application,Right click, choose "Export Application EAR File "from the Context menu - Choose default values,Click OK - Highlight the <Multibyte>EAR File created in IDE,Right click,choose"Extract Ear File" from the context menu - The <multibyte>Ear file is extracted as import-<multibyte> in the IDE. - Highlight import-<multibyte>,Rightclick choose "Find" from the context menu. -Enter <multibyte>EJB bean,as Substring to search for - Check "Use this criterion for search" to enable Search button - Click Search -It says "No matching nodes were found" The same operation when performed in an English EJB displays 8 matching nodes. Evaluation: The "Find" option is a core NB one. xxx@xxxx 2002-06-11 A comment.
> Evaluation: > The "Find" option is a core NB one. wrong. "Find" is in NB utilities module, not core.
I will try to investigate it. Changing priority to P3 because it is not so critical problem.
Set target milestone to TBD
So what is the result of your investigation, Libor?
Since type of an object (Java source file, EJB Bean, ...) is not taken into account during search, I tried to search a simple Java source file. I tried it with the current development build, on two platforms: Japanese Solaris 9 running on Intel: Searching worked as expected. US Solaris 8 running on Sparc: Searching did not work. I see two possible causes of this bug: 1) The way how objects created in the IDE are saved on the disk. In the IDE, I created a simple Java source file containing a short Japanese string. I looked at how the file was saved into a file an the OS-level - the japanese strings were replaced with question marks. Indeed, when I restarted the IDE, the Japanese characters were gone (the question marks were displayed instead). 2) Conflict between encoding used for saving the file and the default encoding used by the searching algorithm. If different encodings are used, the searching mechanism actually searches different contents of files.
Reporter, could you please describe your configuration? I mean: - version of Solaris - language settings of your installation of Solaris - encoding used in file(s) you cannot search (if you have such information available) I will appreciate if you attach a sample file you cannot search. The file may be compressed (.zip, .gz, .bz) to avoid problems with encoding during the transport.
I asked the person who (probably) filed this report to enter the required data. I did it via e-mail since this bug report seems to be kind of broken (reporter's ID is missing).
I could not reproduce this bug on systems with support for multibyte characters. I could not contact the reporter. Closing as WORKSFORME.