[GLASSFISH-11715] ST from classloader Created: 23/Mar/10
Status:
Project:
Component/s:
Affects
Version/s:
Fix Version/s:
Resolved
glassfish
deployment
9.1.1
Type:
Reporter:
Resolution:
Labels:
Remaining
Estimate:
Time Spent:
Original
Estimate:
Environment:
Bug
vince kraemer
Incomplete
None
Not Specified
Attachments:
appserv-admin_manifest.txt
11,715
Issuezilla Id:
Updated: 07/Apr/10 Resolved: 07/Apr/10
v2.1.2
Priority:
Assignee:
Votes:
Critical
Hong Zhang
1
Not Specified
Not Specified
Operating System: Windows Vista
Platform: Sun
bug-log.txt
Description
See http://netbeans.org/bugzilla/show_bug.cgi?id=181872 for details.
The ST is in the first comment.
Comments
Comment by Sanjeeb Sahoo [ 24/Mar/10 ]
See if the issue exists in v3.
Comment by vince kraemer [ 25/Mar/10 ]
Since v3 doesn't support clustering and the like, I do not think we can tell the user to switch to
v3.
Why do you think this issue is 'invalid'?
Comment by cistox [ 05/Apr/10 ]
Created an attachment (id=4292)
Execution log where the exception is raised - SUN Glassfish 2.1.1
Comment by cistox [ 05/Apr/10 ]
Created an attachment (id=4293)
The appserv-admin.jar manifest is showing there should be also a localized jar for other
languages: details inside
Comment by cistox [ 05/Apr/10 ]
This is a grave localization issue because:
1) Glassfish 2.1.1 (English en_US) is unusable on a computer with another
default locale. (except it is specifically installed the multi-language version
and your language is supported)
2) Even forcing the JVM to use the en_US as default locale the retrieval of
resource bundles (LocaleStrings...) is wrong because a
LocaleString_en_US.properties is searched... and of course it doesn't exists.
So we have to be all English !!!
3) By inspecting the multi-language version of Glassfish 2.1.1
see: lib/appserv-rt_l10n.jar
...it is clearly missing any LocaleString for the raised issue:
com/sun/enterprise/management/deploy/DeployThread/LogStrings_en_US.properties
com/sun/enterprise/management/deploy/DeployThread/LogStrings_es_ES.properties
com/sun/enterprise/management/deploy/DeployThread/LogStrings_it_IT.properties
...
Morover, the whole com/sun/enterprise/management/deploy folder is missing into
the appserv-rt_l10n.jar
Please provide a workaround, I am loosing my customers
Roberto Cisternino
Comment by Sanjeeb Sahoo [ 05/Apr/10 ]
Seems like a deployment issue, so filing under appropriate subcategory.
User is also advised to see if there is something wrong in their environment,
because I see messages like these in the log file:
LDR5203: An error occurred while adding URL
file:/C:/workspace/BusDox-AP/dist/gfdeploy/BusDox-LIME-Client.jar to the EJB
class loader. Please check the content of this URL.
"DPL8004: file open failure; file =
C:\workspace\BusDox-AP\dist\gfdeploy\BusDox-LIME-Client.jar"
...
In any case, supply a reproducible test case.
Comment by cistox [ 05/Apr/10 ]
Hello,
I evaluated better the issue and I found that this error (and others in the log
I provided) are caused by the association of Projects in the Enterprise
Application libraries.
To be more clear, I initially associated some JAR projects as libraries of the
Enterprise Application.
From the Enterprise Application's properties I went to the libraries and added a
Project.
Into this case I experience several issues while deploying the Enterprise
Application.
Instead I moved my JAR projects under the packaged resources of the EAR (always
from the properties view)
As I am coming from WebSphere and Eclipse I was following my J2EE
knowledge/experience to deploy the EAR and I used to specify JAR libraries in a
separated view from the J2EE modules.
Now I removed any JAR project from the EAR libraries and all is going fine,
finally !
So the libraries selection seems to be useful for pre-packaged libraries only.
Moreover I noted that I do not need to add any JAR library in the EAR (as I did
before to provide a library for all J2EE modules) as the Netbeans deployment
seems to be able to include any library by itself by collecting those available
into any J2EE module associated to the EAR.
It is curious... as I did it always by hand in the EAR... now I have to avoid this.
Comment by Hong Zhang [ 06/Apr/10 ]
Thanks for the additional information. A few follow up questions:
1. What are the Jar projects you mentioned here? Are they pure library jars, or
are they component jars, like ejb jar, appclient jar?
2. I am not very familiar with NB, can you show me the packaging/contents of
the ear in both cases (before you remove the jars from ear libraries and after)?
3. And to confirm, this is all done on v2.x right?
Comment by cistox [ 07/Apr/10 ]
This exception is caused by associating JAR Projects to the libraries section of
an Enterprise Application.
The library section is intended to provide some JARs for debugging purposes,
thus it should not be used for Projects but for external pre-packaged libraries.
By adding JAR Projects to the EAR libraries section results are unpredictable
during Build or Deployment.
The bug is closed as it is related to Netbeans.
Anyway I suggest the Glassfish Team to revise the Localization as this resourec
should not be searched if not existing:
com/sun/enterprise/management/deploy/DeployThread/LogStrings_es_ES.properties
Best Regards
Roberto Cisternino
Generated at Sun Mar 06 08:37:42 UTC 2016 using JIRA 6.2.3#6260sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.