I'm not sure if i assigned this to proper module - reassign after
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
description The requested resource () is not available.
Project was successfully built but wasn't deployed.
Note: with english locales all works just fine
Created attachment 30996 [details]
Fixed i18n problems in the Tomcat plug-in, reassigning to the sunappserv module
Checking in config/WebappConfiguration.java;
new revision: 220.127.116.11; previous revision: 18.104.22.168
Checking in TomcatManagerImpl.java;
new revision: 22.214.171.124.2.3; previous revision: 126.96.36.199.2.2
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.
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]
after i added a bean to the app, the project deployed. But it did not redeploy,
and gave the error that you see.
Glassfish has issues undeploying a web app that has mbyte characters in the
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]
Created attachment 39372 [details]
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)
this appears to be blocked by GF issue 3456 (https://glassfish.dev.java.net/issues/show_bug.cgi?id=3456) for directory
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
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.
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 ?
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...