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'm not sure if i assigned this to proper module - reassign after evaluation pls. Product Version = NetBeans 5.5 Dev (Build 200606090200) Operating System = Windows XP version 5.1 running on x86 Java; VM; Vendor; Home = 1.5.0_07; Java HotSpot(TM) Client VM 1.5.0_07-b02; Sun Microsystems Inc.; F:\Java\jdk1.5.0_07\jre System Locale; Encoding = ja_JP (nb); MS932 - Using pseudolocalized windows with jappanise locales. I created New Project | Enterprise | Enterprise Application (all file names contains jappanise multi-byte characters) (with glassfish as j2ee server) and simply runed this project - web browser is opened but with error -- HTTP Status 404 - type Status report message description The requested resource () is not available. -- Project was successfully built but wasn't deployed. see attachment Note: with english locales all works just fine
Created attachment 30996 [details] glassfish output
Fixed i18n problems in the Tomcat plug-in, reassigning to the sunappserv module Checking in config/WebappConfiguration.java; /cvs/tomcatint/tomcat5/src/org/netbeans/modules/tomcat5/config/Attic/WebappConfiguration.java,v <-- WebappConfiguration.java new revision: 1.1.2.3; previous revision: 1.1.2.2 done Checking in TomcatManagerImpl.java; /cvs/tomcatint/tomcat5/src/org/netbeans/modules/tomcat5/TomcatManagerImpl.java,v <-- TomcatManagerImpl.java new revision: 1.41.10.2.2.3; previous revision: 1.41.10.2.2.2 done
Stepan - in general, was it an encoding handling kind of problem - since this kind of situation has been seen in other project types or in different kind of files under web or j2ee projects, it will help to know, so can add to guidelines. ken.frank@sun.com
Please attach ear file that triggers the exception
Created attachment 31497 [details] required ear file
The ear file that is attached is invalid. It contains an ejb-jar file that contains no ejbs.... Please zip up the project and attach it. I will be able to correct it, if I have the whole thing.
Created attachment 31533 [details] whole project
after i added a bean to the app, the project deployed. But it did not redeploy, and gave the error that you see. Opened https://glassfish.dev.java.net/issues/show_bug.cgi?id=862
Glassfish has issues undeploying a web app that has mbyte characters in the context root. A work-around would be to apply character xformation on the context-root element that gets put into the application.xml Putting in that work-around makes it possible that issues like this one never gain the attention of the right people and get resolved correctly.
Created attachment 39371 [details] initial deploy
Created attachment 39372 [details] secondary deploy
Created attachment 39373 [details] log from start through second deploy
Created attachment 39374 [details] the domain.xml file
Created attachment 39375 [details] the newer test ear file
this issue has gotten worse in 6.0/v2 case. trying to deploy a web-app that has an MB context-root (created in Netbeans) fails to deploy; from NetBeans, from asadmin and/or the admin GUI. Opened https://glassfish.dev.java.net/issues/show_bug.cgi?id=3293 and https://glassfish.dev.java.net/issues/show_bug.cgi?id=3294 to track some of this.
Vince - is it that if user changes the context root to mbyte that this happens ? that is, web project by default subsitutes underscores for mbyte (and perhaps extended ascii) and it can deploy. or is it that some otherparts of web app or other project types or file types/functionality, don't use this modified context root or set it themselves but dont do the substitution -- and thats what causes problem as in this issue ? I think there was a valid reason why the substitution was done originally; I don't know if that is still valid reason. ( I'll look at the 2 gf issues you mention) ken.frank@sun.com
this appears to be blocked by GF issue 3456 (https://glassfish.dev.java.net/issues/show_bug.cgi?id=3456) for directory deployment. The archive deploys correctly. But, when the user calls Run a second time, something tells the plugin to distribute instead of redeploy. I wrote a q&d jsr88 test to verify that the server's 88 impl isn't at fault. Needs more investigation. hopeful.
The GlassFish issue was downgraded to P4 and is not planned to be fixed in 9.1. What does that mean for this bug? Will we need to waive it or is there another solution?
Investigating this now. Will update with comments. From Vince's comment it appears that the GlassFish issue is part of the problem. If another solution cannot be found, then need to waive it.
GlassFish Build b58WinXP Deployed a web-app that has an MB context-root (created in Netbeans) "と粮t粮粤ろ" changed NB generated context root to one with MB characters Was able to successfully deploy, redeploy and run webapp. But browser is launched with the following url http://localhost:8080/??t???/ though the ide's output window shows deployment finished : 100% Deploying application in domain completed successfully Trying to create reference for application in target server completed successfully Trying to start application in target server completed successfully Deployment of application と粮t粮粤ろ completed successfully run-deploy: Browsing: http://localhost:8080/と粮t粮粤ろ/ run-display-browser: run: BUILD SUCCESSFUL (total time: 26 seconds) Could be a configuration issue with my machine as far as the browser is concerned. Ken any ideas?? Cannot reproduce issue seen by Vince. Note, GlassFish issue https://glassfish.dev.java.net/issues/show_bug.cgi?id=3293 regarding deployment of web module with MB context root was resolved on July 26 in b58. Will test an EAR containg EJB and Web modules with MB characters next.
Nitya, I thought that nb web apps substituted mbyte with underscore chars to workaround some problems some browsers had with interpreting multibyte, for example the url you mention with the ??? But I think you mentioned below that you changed the context root to one with mbyte characters ? was it orignally with the underscores ? I don't know if the original reason why the underscore approach was impelementd was about the gf issues mention in this issue or some other ones, or some gf (AS at that time) limitations, but I think someone on j2ee team would know, and it might give a clue for this issue. (I think the original problem that led to use of underscore was before the issue 3293, that was reported as recently fixed below). Actually if the problem that led to underscore is still valid, perhaps nb could do some error checking if user tries to change it via props editor ? ken.frank@sun.com
This appears to work now... when an app is archive deployed. I am working on resolving a file copying issue for "redeploy" when an app is run a second time.
opened new issue to track the directory deploy component of this (issue 112792). closing this issue as a WFM... due to changes in recent GF builds...