[GLASSFISH-17287] [UB]General Vulnerability Assessment -> NonIntrusive -> Web Server Created: 12/Sep/11  Updated: 15/Mar/13

Status: Open
Project: glassfish
Component/s: docs
Affects Version/s: v3.0.1
Fix Version/s: v3.0.1

Type: Bug Priority: Major
Reporter: fraggie Assignee: Paul Davies
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Solaris 10, SPARC and X86


Tags: Assessment, General, Glassfish, Security, Vulnerability

 Description   

The following security flaw has been identidfied:

http://www.mcafee.com/us/resources/release-notes/foundstone/fsl_05_11_2011.pdf11907 - Oracle Sun Products Suite Glassfish Denial Of Service

Category: General Vulnerability Assessment -> NonIntrusive -> Web Server

Risk Level: High

CVE: CVE-2011-0807

DISA IAVA: 2011-A-0054

Description

A denial of service vulnerability is present in some versions of Oracle Sun GlassFish Enterprise Server and Sun Java System

Application Server.

Observation

A denial of service vulnerability is present in some versions of Oracle Sun GlassFish Enterprise Server and Sun Java System

Application Server.

Oracle Sun GlassFish Enterprise Server 2.1, 2.1.1, and 3.0.1, and Sun Java System Application Server 9.1 are prone to a

unspecified vulnerability related to Administration. Successful exploitation could allow an attacker to cause a denial of service

This may be already fixed, but is not evident in the latest release notes:

Glassfish 3.1 release note: http://java.net/jira/secure/ReleaseNote.jspa?projectId=10231&version=10968

Glassfish 3.1.1 release note: http://glassfish.java.net/docs/3.1/release-notes.pdf



 Comments   
Comment by Shing Wai Chan [ 12/Sep/11 ]

From http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-0807 , we have

Unspecified vulnerability in Oracle Sun GlassFish Enterprise Server 2.1, 2.1.1, and 3.0.1, and Sun Java System Application Server 9.1, allows remote attackers to affect confidentiality, integrity, and availability via unknown vectors related to Administration.

I have confirmed from admin team that this has been fixed in 3.1 and 3.1.1.

Comment by fraggie [ 13/Sep/11 ]

Hi Shing Wai Chan,

Thank you for that and the prompt reply, much appreciated.

One last thing, would it be possible for you to highlight where is states in the release notes that this has been fixed?

(Just for our records).

Regards,
Dónal

Comment by Bhakti Mehta [ 14/Oct/11 ]

Assigning to Shingwai for more input on the submitter's question

Comment by Anissa Lam [ 18/Oct/11 ]

As stated above, the bug exists in
Oracle Sun GlassFish Enterprise Server 2.1, 2.1.1, and 3.0.1, and Sun Java System Application Server 9.1
but not in v3.1 and 3.1.1.

3.1 and 3.1.1 ships before the bug was discovered/reported, thus the release notes of those release doesn't mention about that.

I am transferring this to doc. If they think this should be mentioned in the release note of next release, they can add that in.

Comment by Rebecca Parks [ 12/Dec/11 ]

It sounds to me like it's the Release Notes for 3.1/3.1.1 that need to be fixed. It's too bad I didn't look at this bug sooner, I just updated the 3.1/3.1.1 Release Notes. I think I can get this added for the next patch, scheduled for 1/13/12.

If it's added to the 3.1/3.1.1 Release Notes, it seems to me that it doesn't need to be in the 3.1.2 Release Notes as well, but I'd like to hear other opinions.

Comment by Rebecca Parks [ 04/Jan/12 ]

I checked with the doc team, and it is unfixed bugs that appear in the Release Notes, not fixed ones. So this would go in the SGES 2.1.1, SGCS 2.0, and OGS 3.0.1 Release Notes. I am currently updating the 2.1.1/2.0 Release Notes, so I will retarget this bug to 3.0.1.

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.

Comment by Rebecca Parks [ 06/Mar/12 ]

Changed the fix version back to 3.0.1. This needs to be added to the 3.0.1 Release Notes at the next patch update.

Comment by Tom Mueller [ 07/Mar/12 ]

Bulk update to set Fix Version to "not determined" for issues that had it set to a version that has already been released.

Comment by Rebecca Parks [ 07/Mar/12 ]

Please don't make me do this AGAIN.

Comment by Mike Fitch [ 16/Feb/13 ]

As this applies to unbundled documentation, moving to 4.0.1

Comment by Mike Fitch [ 15/Mar/13 ]

Changed fix version to 3.0.1 as per Rebecca's comment of 06/Mar/12 10:41 PM:

Changed the fix version back to 3.0.1. This needs to be added to the 3.0.1 Release Notes at the next patch update.





[GLASSFISH-14837] [UB][sun-appserv-deploy] Install Directory of application server not known. Sepcify either the installDir attribute or the asinstall.dir property Created: 26/Nov/10  Updated: 26/May/11  Resolved: 26/May/11

Status: Resolved
Project: glassfish
Component/s: docs
Affects Version/s: v3.0.1
Fix Version/s: v3.0.1

Type: Bug Priority: Major
Reporter: jthoennes Assignee: Scott Fordin
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3-1-exclude, v3_0_1_approved

 Description   

If the "asinstalldir" property is missing from the "sun-appserv-deploy" task, then the error message:

[sun-appserv-deploy] Install Directory of application server not known. Sepcify either the installDir attribute or the asinstall.dir property

is displayed, which also contains a spelling error "Sepcify".

But the 3.0.1 docs at http://docs.sun.com/app/docs/doc/821-1752/fvyby?l=pt_BR&a=view
still say "asinstalldir".

Please correct both errors. Thanks.

As per Oracle service request:
SR#73857860 - GFv3.0.1 sun-appserv-deploy task does neither support "asinstalldir" nor the asadmin option "--property



 Comments   
Comment by jthoennes [ 09/Dec/10 ]

The following issues have to be corrected:

  • Property name is "installdir", not "asinstall.dir" as in doc or "installDir" as in error message.
  • Consider to rename "sun-appserv-deploy" / "sun-appserv-undeploy" to "glassfish-deploy" / "glassfish-undeploy"
    • Rename task and provide ant macro / task def for the old name to provide backwards compatibility.
  • Correct spelling error "Sepcify".
Comment by Bhavanishankar [ 21/Dec/10 ]

How bad is its impact? (Severity)
Medium

How often does it happen? Will many users see this problem? (Frequency)
Always

How much effort is required to fix it? (Cost)
The fix will mainly be in the documentation. The code change is only to fix the spelling error "Sepcify". Once I check-in the code, I will transfer this to documentation.

What is the risk of fixing it and how will the risk be mitigated? (Risk)
Low.

Comment by Nazrul [ 21/Dec/10 ]

Approved for checkin

Comment by Bhavanishankar [ 22/Dec/10 ]

I have checked in the code change http://java.net/projects/glassfish/lists/commits/archive/2010-12/message/780

The documentation @ http://docs.sun.com/app/docs/doc/821-1752/fvyby?a=view should change "asinstalldir" to "asinstall.dir"

Hence transferring to docs category.

Comment by Paul Davies [ 23/Dec/10 ]

Affects unbundled documentation. Prefixed summary with [UB]. Reassigned to Rebecca Parks.

Comment by Rebecca Parks [ 04/Jan/11 ]

I have been told that the Ant tasks are not supported for 3.1. Closing bug. If the Ant tasks will be resurrected in the future, this bug can be also.

Comment by Rebecca Parks [ 01/Feb/11 ]

For 3.1 Ant is a separate module, but for 3.0.1 this bug can be addressed in the release notes. Reopening as requested by Olaf Hey. Assigning to Paul Davies for reassignment to the sustaining writer.

Comment by Paul Davies [ 01/Feb/11 ]

Reassigned to sfordin for consideration for an update to the 3.0.1 Release Notes.

Comment by Scott Fordin [ 11/Feb/11 ]

Will add topic to 3.0.1 Release Notes the next time I touch that book.

Comment by Scott Fordin [ 25/Mar/11 ]

Added 3-1-exclude tag because this is a 3.0.1 Release Note issue.

Comment by Scott Fordin [ 26/May/11 ]

Added issue to 3.0.1 Release Notes. Will be public next time document is republished. Here is the text I added:

------------------------------- Snip -------------------------------
Install Directory of application server not known. Specify either the installDir attribute or the asinstall.dir property (14837)

Description

The reference information and examples in "The sun-appserv-deploy Task" in Oracle GlassFish Server 3.0.1 Application Development Guide [link: http://download.oracle.com/docs/cd/E19798-01/821-1752/beaer/index.html] refer to an asinstalldir attribute, which is incorrect. In addition, the error message string returned by the sun-appserv-deploy Ant task incorrectly states, "Sepcify either the installDir attribute or the asinstall.dir property."

Solution

Note the following corrections:

  • asinstalldir should be asinstall.dir.
  • "Sepcify" in the error message string should be "Specify."
                                                              • Snip -------------------------------




[GLASSFISH-12105] jms l10n jar files missing Created: 02/Jun/10  Updated: 02/Jun/10  Resolved: 02/Jun/10

Status: Resolved
Project: glassfish
Component/s: packaging
Affects Version/s: v3.0.1
Fix Version/s: v3.0.1

Type: Bug Priority: Critical
Reporter: gmurr Assignee: Snjezana Sevo-Zenzerovic
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 12,105

 Description   

jms l10n jar files missing are missing from l10n bundles



 Comments   
Comment by Snjezana Sevo-Zenzerovic [ 02/Jun/10 ]

glassfish-jms-l10n package needs to be installed during open source edition
distribution assembly. Note that issue does not affect ogs-* and Java EE SDK
bundles.

Comment by Snjezana Sevo-Zenzerovic [ 02/Jun/10 ]

Distribution assembly fixed.





[GLASSFISH-12093] uninstall glassfish fail as jdk location reason Created: 01/Jun/10  Updated: 11/Jun/10  Resolved: 11/Jun/10

Status: Resolved
Project: glassfish
Component/s: installation
Affects Version/s: v3.0.1
Fix Version/s: v3.0.1

Type: Bug Priority: Critical
Reporter: leonfan Assignee: scatari
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: other
Platform: Other


Issuezilla Id: 12,093

 Description   

I install jdk under it's default directory "c:\Program Files\Java" on Windows 7
simplified chinese version. Then install glassfish ml version on that machine
successful. After that, I try to uninstall glassfish, one error dialog popup:

Error: couldn't find Java 2 Runtime Environment in '(null)'.

I couldn't uninstall it successfully.



 Comments   
Comment by leonfan [ 02/Jun/10 ]

One more issue, it mention user can try 'uninstall.exe -javahome <Java
installation directory>'. But it's should be '-j' instead of '-javahome' . I can
uninstall it by follow command:

uninstall.exe -j "C:\Program Files\Java\jre6"

Comment by scatari [ 02/Jun/10 ]

Can u try running the "uninstall" under start->program->[GlassFish bundename]?

Comment by leonfan [ 02/Jun/10 ]

Uninstall from cli and from Windows menu, both are fail.

Comment by mzh777 [ 09/Jun/10 ]

I encountered the same issue with the SDK b20 on windows. When uninstall the GF
SDK bits either from command with "uninstall.exe" or from manual
(start->program->glassfish->uninstall), the uninstaller complain can not find
compatible JDK. But if I specify java_home with -j option, it went through.

Comment by mzh777 [ 09/Jun/10 ]

The SDK bits described above was not packaged with a JDK. If I use the SDK bits
packaged with JDK, the uninstall from either manual or command line went through
fine.

Comment by scatari [ 09/Jun/10 ]

Dup of 12204.

      • This issue has been marked as a duplicate of 12204 ***
Comment by mzh777 [ 10/Jun/10 ]

Reopen the issue since I still see the issue on windows 7. The workaround is to
specify the Java home:
.\uninstall.exe -j "c:\Program Files\Java\jdk1.6.0_20"

Comment by mzh777 [ 10/Jun/10 ]

The latest build used is sdk b21 without JDK bundled:
java_ee_sdk-6u1-b21-windows.exe

Comment by scatari [ 11/Jun/10 ]

This should be documented in the install guide as the limitation/work around.
Too late to fix this in 3.0.1.

Comment by Scott Fordin [ 11/Jun/10 ]

Added topic to 3.0.1 Installation Guide and 3.0.1 Release Notes.





[GLASSFISH-12083] Unable to start domain on SDK Web distros Created: 28/May/10  Updated: 07/Jun/10  Resolved: 07/Jun/10

Status: Resolved
Project: glassfish
Component/s: installation
Affects Version/s: v3.0.1
Fix Version/s: v3.0.1

Type: Bug Priority: Critical
Reporter: Alex Pineda Assignee: Snjezana Sevo-Zenzerovic
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 12,083

 Description   

I tried the SDK-Web distro and it looks like the installation completes,
however, when I try to start the domain, I get the following message:
"CLI302 There are no domains in
/export/hudson/workspace/sdk_web/glassfishv3/glassfish/domains"

Below is part of the installation log file:

[#|2010-05-28T13:09:05.762-07:00|INFO|Install
Engine|org.openinstaller.provider.conf.InstallationConfigurator||javaHome:
/export/hudson/tools/jdk1.6.0_18/jre:javaHome:
/export/hudson/tools/jdk1.6.0_18/jre|#]
[#|2010-05-28T13:09:05.763-07:00|INFO|Install
Engine|org.openinstaller.provider.conf.InstallationConfigurator||jdkHome:
../../jdk:jdkHome: ../../jdk|#]
[#|2010-05-28T13:09:05.764-07:00|INFO|Install
Engine|org.openinstaller.provider.conf.InstallationConfigurator||Creating
GlassFish domain:Creating GlassFish domain|#]
[#|2010-05-28T13:09:05.764-07:00|INFO|Install
Engine|org.openinstaller.provider.conf.InstallationConfigurator||Admin
port:4848:Admin port:4848|#]
[#|2010-05-28T13:09:05.765-07:00|INFO|Install
Engine|org.openinstaller.provider.conf.InstallationConfigurator||HTTP
port:8080:HTTP port:8080|#]
[#|2010-05-28T13:09:05.765-07:00|INFO|Install
Engine|org.openinstaller.provider.conf.InstallationConfigurator||User:admin:User:admin|#]
[#|2010-05-28T13:09:05.765-07:00|INFO|Install
Engine|org.openinstaller.provider.conf.InstallationConfigurator||Existing PATH:
/export/hudson/tools/jdk1.6.0_18/bin:/export/hudson/tools/ant-1.7.1/bin:/export/hudson/tools/maven-2.0.10/bin:/export/hudson/tools/jdk1.6.0_18/bin:/export/hudson/tools/ant-1.7.1/bin:/export/hudson/tools/maven-2.0.10/bin:/usr/local/bin:/bin:/usr/bin:Existing
PATH:
/export/hudson/tools/jdk1.6.0_18/bin:/export/hudson/tools/ant-1.7.1/bin:/export/hudson/tools/maven-2.0.10/bin:/export/hudson/tools/jdk1.6.0_18/bin:/export/hudson/tools/ant-1.7.1/bin:/export/hudson/tools/maven-2.0.10/bin:/usr/local/bin:/bin:/usr/bin|#]
[#|2010-05-28T13:09:05.766-07:00|INFO|Install
Engine|org.openinstaller.provider.conf.InstallationConfigurator||New PATH:
../../jdk/bin:/export/hudson/tools/jdk1.6.0_18/bin:/export/hudson/tools/ant-1.7.1/bin:/export/hudson/tools/maven-2.0.10/bin:/export/hudson/tools/jdk1.6.0_18/bin:/export/hudson/tools/ant-1.7.1/bin:/export/hudson/tools/maven-2.0.10/bin:/usr/local/bin:/bin:/usr/bin:New
PATH:
../../jdk/bin:/export/hudson/tools/jdk1.6.0_18/bin:/export/hudson/tools/ant-1.7.1/bin:/export/hudson/tools/maven-2.0.10/bin:/export/hudson/tools/jdk1.6.0_18/bin:/export/hudson/tools/ant-1.7.1/bin:/export/hudson/tools/maven-2.0.10/bin:/usr/local/bin:/bin:/usr/bin|#]
[#|2010-05-28T13:09:05.814-07:00|INFO|Install
Engine|org.openinstaller.provider.conf.InstallationConfigurator||Asadmin output:
/export/hudson/workspace/sdk_web/glassfishv3/glassfish/bin/asadmin: line 19:
/../../jdk/bin/java: No such file or directory
/export/hudson/workspace/sdk_web/glassfishv3/glassfish/bin/asadmin: line 19:
exec: /../../jdk/bin/java: cannot execute: No such file or directory
:Asadmin output:
/export/hudson/workspace/sdk_web/glassfishv3/glassfish/bin/asadmin: line 19:
/../../jdk/bin/java: No such file or directory
/export/hudson/workspace/sdk_web/glassfishv3/glassfish/bin/asadmin: line 19:
exec: /../../jdk/bin/java: cannot execute: No such file or directory

#]


 Comments   
Comment by scatari [ 28/May/10 ]

This could be due to usage of relative paths and current work directory. Assigning to Snjezana.

Comment by Snjezana Sevo-Zenzerovic [ 28/May/10 ]

Asadmin output shows an extra slash character in front of relative JDK location
path which is incorrect - still investigating where that slash comes from...

Comment by Snjezana Sevo-Zenzerovic [ 01/Jun/10 ]

Issue is fixed in 3.0.1 release by installer configurator workaround - for the
time being, bundled JDK path will be resolved to absolute value and that value
written into asenv config file instead of relative value. Only side-effect of
this is that user will not be able to relocate installation directory into
different location without updating asenv value, but relocation already requires
some other manual steps such as cleanup of OSGi cache directory.

Full fix will require asadmin enhancement so that asadmin scripts can resolve
and use relative JDK paths defined by AS_JAVA environment variable. Issue 12088
targeted for 3.1 release has been filed to track this.

Comment by Alex Pineda [ 07/Jun/10 ]

Verified fix on SDK build 20 promoted build.





[GLASSFISH-12082] Unable to install SDK distros that contain JDK bundle Created: 28/May/10  Updated: 07/Jun/10  Resolved: 07/Jun/10

Status: Resolved
Project: glassfish
Component/s: installation
Affects Version/s: v3.0.1
Fix Version/s: v3.0.1

Type: Bug Priority: Critical
Reporter: Alex Pineda Assignee: Snjezana Sevo-Zenzerovic
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 12,082

 Description   

While installing the SDK distributions that contain JDK 6_20, I'm seeing the
following error when I ran the installer in silent mode as
machine% ./latest-sdk-jdk-solaris-sparc.sh -a statefile -s -j $JAVA_HOME

The error that I get is:
"Cannot retrieve UI Properties for product jdk: Error: Cannot locate UI
definition for the specified product. Product=jdk"

When I try to use the GUI installer, I get an error at the point after selecting
"Next" in the Updatool screen.

I see the same problem on all the distributions that I tried (Windows, x86,
Sparc and Linux)

When I do the same procedures with the SDK build that has no JDK, I don't have
any problems.



 Comments   
Comment by Snjezana Sevo-Zenzerovic [ 28/May/10 ]

Adjusting subcomponent, since this is actually SDK installer and not packaging
issue.

The root cause is corrupted screen sequence file used for SDK full profile
distributions with bundled JDK which contained reference to non-existent "jdk"
configuration screen. Note that web profile SDK distributions with bundled JDK
are not affected by this issue since they contain correct screen sequence.

Fix is checked into SDK workspace, awaiting confirmation that web profile
distributions do work in silent mode before starting nightly build with the fix.

Comment by Snjezana Sevo-Zenzerovic [ 28/May/10 ]

Installation failure is fixed by the checkin, so marking as fixed. Domain
creation issue tracked separately in issue# 12083.

Comment by Alex Pineda [ 07/Jun/10 ]

Verified fix in SDK build 20 promoted builds.





[GLASSFISH-11999] Version class does not return correct branding when server is not running Created: 24/May/10  Updated: 24/May/10  Resolved: 24/May/10

Status: Resolved
Project: glassfish
Component/s: admin
Affects Version/s: v3.0.1
Fix Version/s: v3.0.1

Type: Bug Priority: Critical
Reporter: Snjezana Sevo-Zenzerovic Assignee: Byron Nevins
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 11,999

 Description   

I am filing this as P2 since it should be resolved for 3.0.1 release.

'asadmin version' output when server is not running does not return values
specified through branding extension. As the result, all distributions will
return the same product name value, i.e. "GlassFish Server Open Source Edition".
This is incorrect in the case of Oracle branded distributions.

The root cause is that branding implementation is not being loaded by asadmin
since it runs in non-HK2 mode.



 Comments   
Comment by Byron Nevins [ 24/May/10 ]

Done.

C:\gf_other\3.0.1>svn commit
Sending admin\cli\pom.xml
Sending
admin\cli\src\main\java\com\sun\enterprise\admin\cli\VersionCommand.java
Sending
common\common-util\src\main\java\com\sun\appserv\server\util\VersionTemplate
Transmitting file data ...
Committed revision 37229.





[GLASSFISH-11902] Use bundled JDK wherever appopriate when launching SDK installer Created: 14/May/10  Updated: 19/May/10  Resolved: 19/May/10

Status: Resolved
Project: glassfish
Component/s: installation
Affects Version/s: v3.0.1
Fix Version/s: v3.0.1

Type: Bug Priority: Major
Reporter: scatari Assignee: scatari
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 11,902

 Description   

One of the Java EE SDK bundles also include a JDK. The install wrapper however does not use it in case if a
valid JDK cannot be found in user environment.



 Comments   
Comment by scatari [ 14/May/10 ]

The wrapper(on all platforms) will be modified to also look for and use bundled JDK in case a compatible
JDK cannot be found in user's machine. The fix has already been checked into 3.0.1 source tree to cover
windows platform.

Comment by scatari [ 19/May/10 ]

Fixed and fix also ported to 3.1.





[GLASSFISH-11889] Java SE 1.6.0_19 breaks Java Web Start launches of app clients Created: 13/May/10  Updated: 20/May/10  Resolved: 20/May/10

Status: Resolved
Project: glassfish
Component/s: standalone_client
Affects Version/s: v3.0.1
Fix Version/s: v3.0.1

Type: Bug Priority: Blocker
Reporter: Tim Quinn Assignee: Tim Quinn
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 11,889

 Description   

Changes in how Java Web Start loads classes in signed vs. unsigned JARs in Java
SE 1.6.0_19 has broken app client launches using Java Web Start. (The changes
are described here:
http://java.sun.com/javase/6/docs/technotes/guides/jweb/mixed_code.html)

Users are prompted with a warning that they are about to start an app containing
a mix of signed and unsigned content. Even if they agree to continue, Java Web
Start now uses different class loaders for signed vs. unsigned content and that
breaks the Java Web Start launch.



 Comments   
Comment by Tim Quinn [ 13/May/10 ]

I am looking into some possible ways of fixing this.

Comment by Tim Quinn [ 17/May/10 ]

For 3.0.1, the fix I am looking at will be for the Java Web Start support code
in GlassFish to sign all the GlassFish JARs. (In 3.0 only gf-client.jar was
signed.) Because the user can override the default signing alias with one of
his or her own choosing during deployment, GlassFish will maintain possibly
multiple copies of the system JARs, each signed with a different alias.
GlassFish will record the need for a signed set of system JARs during deployment
but will not actually sign a given system JAR until it receives the first
reference to a particular signed system JAR as part of a Java Web Start client
launch.

The Java Web Start support code in GlassFish will know whether signed JARs for a
particular alias have already been prepared and will not duplicate the work.

There will be a performance penalty for having to do this, but by signing all
the JARs Java Web Start will no longer warn the user that the app contains both
signed and unsigned code and will load all the classes using the same class
loader (which is necessary for the app client container and the client to work
correctly as written).

Comment by Tim Quinn [ 20/May/10 ]

Fixed in 3.0.1 via the commit below (and in 3.1 in the commit described in a
later update to this issue).

Note that this fix will cause GlassFish to create signed copies of the GlassFish
JARs which are used during Java Web Start launches. These signed JARs are
created when GlassFish first receives a Java Web Start request for them. This
means that the first user who launches a client using Java Web Start after a new
GlassFish installation might see a longer-than-usual delay while GlassFish
creates the signed copies of the JARs. But once any Java Web Start launch
occurs, the signed copies of the JARs will be used for any Java Web Start launch
of any application from any user.

By default, the copies will be signed using the domain's self-signed certificate
with alias s1as. If the user specified the optional jar-signing-alias property
while deploying an app, then GlassFish will create separate copies of the
required GlassFish JARs using that alias. Again, the same copy will be shared
across all apps deployed with that jar-signing-alias and across all users
launching those apps.

Because the JARs downloaded are signed, Java Web Start on the client will take
some additional time to verify these JARs before using them, as happens whenever
a signed JAR opened. Note that this verification will occur each time a user
launches an app, even if the locally cached copies of the GlassFish system JARs
are used.

Author: tjquinn
Date: 2010-05-20 15:00:10+0000
New Revision: 37116

Modified:

branches/3.0.1/appclient/server/core/src/main/java/org/glassfish/appclient/server/core/AppClientDeployerHelper.java

branches/3.0.1/appclient/server/core/src/main/java/org/glassfish/appclient/server/core/NestedAppClientDeployerHelper.java

branches/3.0.1/appclient/server/core/src/main/java/org/glassfish/appclient/server/core/StandaloneAppClientDeployerHelper.java

branches/3.0.1/appclient/server/core/src/main/java/org/glassfish/appclient/server/core/jws/AppClientHTTPAdapter.java

branches/3.0.1/appclient/server/core/src/main/java/org/glassfish/appclient/server/core/jws/JWSAdapterManager.java

branches/3.0.1/appclient/server/core/src/main/java/org/glassfish/appclient/server/core/jws/JavaWebStartInfo.java

branches/3.0.1/appclient/server/core/src/main/java/org/glassfish/appclient/server/core/jws/NamingConventions.java

branches/3.0.1/appclient/server/core/src/main/java/org/glassfish/appclient/server/core/jws/servedcontent/TokenHelper.java

branches/3.0.1/appclient/server/core/src/main/resources/org/glassfish/appclient/server/core/jws/templates/appclientMainDocumentTemplate.jnlp

branches/3.0.1/appclient/server/core/src/main/resources/org/glassfish/appclient/server/core/jws/templates/systemJarsDocumentTemplate.jnlp

Comment by Tim Quinn [ 20/May/10 ]

Fixed in 3.1.

Author: tjquinn
Date: 2010-05-20 15:14:01+0000
New Revision: 37118

Modified:

trunk/v3/appclient/server/core/src/main/java/org/glassfish/appclient/server/core/jws/AppClientHTTPAdapter.java

trunk/v3/appclient/server/core/src/main/java/org/glassfish/appclient/server/core/jws/JWSAdapterManager.java

trunk/v3/appclient/server/core/src/main/java/org/glassfish/appclient/server/core/jws/JavaWebStartInfo.java

trunk/v3/appclient/server/core/src/main/java/org/glassfish/appclient/server/core/jws/NamingConventions.java

trunk/v3/appclient/server/core/src/main/java/org/glassfish/appclient/server/core/jws/servedcontent/TokenHelper.java

trunk/v3/appclient/server/core/src/main/resources/org/glassfish/appclient/server/core/jws/templates/appclientMainDocumentTemplate.jnlp

trunk/v3/appclient/server/core/src/main/resources/org/glassfish/appclient/server/core/jws/templates/systemJarsDocumentTemplate.jnlp





[GLASSFISH-11881] JAXB unmarshaller throws "no implementation of regex was found" Created: 11/May/10  Updated: 19/May/10  Resolved: 19/May/10

Status: Resolved
Project: glassfish
Component/s: web_services
Affects Version/s: V3
Fix Version/s: v3.0.1

Type: Bug Priority: Critical
Reporter: mallas Assignee: Martin Grebac
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Zip Archive fix2.zip     Zip Archive fixver.zip     Text File test.zip    
Issuezilla Id: 11,881

 Description   

JAXB generated schema unmarshalling fails on Glassfish v3 for AnyURIType with
the following exception:

java.lang.Error: no implementation of regexp was found.
at
com.sun.msv.datatype.xsd.regex.RegExpFactory.createFactory(RegExpFactory.java:28)
at com.sun.msv.datatype.xsd.AnyURIType.createRegExp(AnyURIType.java:175)
at com.sun.msv.datatype.xsd.AnyURIType.<clinit>(AnyURIType.java:128)
at sun.misc.Unsafe.ensureClassInitialized(Native Method)
at
sun.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(UnsafeFieldAccessorFactory.java:25)
at sun.reflect.ReflectionFactory.newFieldAccessor(ReflectionFactory.java:122)
at java.lang.reflect.Field.acquireFieldAccessor(Field.java:918)
at java.lang.reflect.Field.getFieldAccessor(Field.java:899)
at java.lang.reflect.Field.getLong(Field.java:528)
at java.io.ObjectStreamClass.getDeclaredSUID(ObjectStreamClass.java:1614)
at java.io.ObjectStreamClass.access$700(ObjectStreamClass.java:52)
at java.io.ObjectStreamClass$2.run(ObjectStreamClass.java:425)
at java.security.AccessController.doPrivileged(Native Method)
at java.io.ObjectStreamClass.<init>(ObjectStreamClass.java:413)
at java.io.ObjectStreamClass.lookup(ObjectStreamClass.java:310)
at java.io.ObjectStreamClass.initNonProxy(ObjectStreamClass.java:547)
at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1583)
at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1732)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
at
com.sun.xml.bind.unmarshaller.DatatypeDeserializer.deserialize(DatatypeDeserializer.java:56)
at com.sun.samples.jaxb.impl.TokenAssertionTypeImpl.<clinit>(Unknown Source)
at com.sun.samples.jaxb.ObjectFactory.createX509TokenElement(Unknown Source)
at com.sun.samples.Test.createX509TokenElement(Unknown Source)
at org.apache.jsp.jaxb_002dtest_jsp._jspService(jaxb_002dtest_jsp.java from :65)

Same thing works well on Glassfish v2.x and earlier versions.

I am uploading a zip file that has a sample test case.

1. unzip the test.zip

2. ant (from a directory where this is extracted)

3. Deploy the war file from built/dist/test.war

4. Access http://<host>:<port>/test/jaxb-test.jsp

Btw, this is for OpenSSO release.



 Comments   
Comment by mallas [ 11/May/10 ]

Created an attachment (id=4352)
test zip file

Comment by Bhakti Mehta [ 12/May/10 ]

Martin pls can you look in this. Most likely I suspect the packages may not be
getting exported.

Comment by Martin Grebac [ 13/May/10 ]

Yes, I've been looking at it and it seems the msv/xsdlib packages are not
correctly imported/exported. Btw, my nick is 'snajper' ;O)

Comment by Martin Grebac [ 13/May/10 ]

First part of the issue is that jdk regexp loader in xsdlib/msv source is
defined to load class from apache.xerces.impl.xpath.regex.RegularExpression,
whereas that should definitely be
com.sun.org.apache.xerces.internal.impl.xpath.regex.RegularExpression.
That fixes standalone run of your test (other way/workaround to fix standalone
run is to add xercesImpl to classpath).
This does not help in the GF run, because the app does not seem to be able to
import the package. I'll ask Sahoo/Bhakti what are the osgi possibilities there.

Comment by Martin Grebac [ 14/May/10 ]

Created an attachment (id=4355)
Patched files for fix verification

Comment by Martin Grebac [ 14/May/10 ]

Please find the attached zip file with patched jaxb bundles and felix
config.properties which exports the
com.sun.org.apache.xerces.internal.impl.xpath.regex package from JDK. I didn't
get hold of Sahoo yet so this might not be final solution, but please verify if
this fixes your issue.

Comment by Martin Grebac [ 14/May/10 ]

Hi, please see fix2.zip which contains a more robust solution and does not
necessarily require the felix config.properties change: in case the internal
regex package is not exported by osgi container, the code defers to jdk regex api.
Please verify - I'm not able to proceed without verification.

Comment by Martin Grebac [ 14/May/10 ]

Created an attachment (id=4356)
Fix which does not require felix config.properties changes

Comment by mallas [ 14/May/10 ]

Thanks Martin. Verified that the fix is working with my test program and as well
as with OpenSSO binaries. Please let us know which build of GF we should be
using for official testing.

Comment by Martin Grebac [ 19/May/10 ]

Fixed in Metro 2.0.1.





[GLASSFISH-11876] CDI 1.0.1 TCK Test Failure:Assertion Error: Test For Active Request/Application Scope During EJB Timeout Created: 10/May/10  Updated: 11/May/10  Resolved: 11/May/10

Status: Resolved
Project: glassfish
Component/s: cdi
Affects Version/s: v3.0.1
Fix Version/s: v3.0.1

Type: Bug Priority: Critical
Reporter: rogerk Assignee: ksak
Resolution: Incomplete Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Macintosh


Issuezilla Id: 11,876

 Description   

See: https://jira.jboss.org/jira/browse/CDITCK-157



 Comments   
Comment by rogerk [ 10/May/10 ]

target 3.0.1

Comment by rogerk [ 10/May/10 ]

This issue also relates to Application scope.
See: https://jira.jboss.org/jira/browse/CDITCK-157

Comment by rogerk [ 11/May/10 ]

As it turns out, SessionBeanInterceptor is registered in GF v3.0.1.
The tests CDI TCK tests were written in such a way as to cause a race condition
(the bug lies with the CDI TCK tests).
See: https://jira.jboss.org/jira/browse/CDITCK-157





[GLASSFISH-11863] web-incorporation pkg should depend on jersey 1.* rather than 1.1.* Created: 06/May/10  Updated: 11/May/10  Resolved: 11/May/10

Status: Resolved
Project: glassfish
Component/s: packaging
Affects Version/s: v3.0.1
Fix Version/s: v3.0.1

Type: Bug Priority: Major
Reporter: Jakub Podlesak Assignee: Snjezana Sevo-Zenzerovic
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Linux


Attachments: Text File gf-3.0.1-jersey-version-relax.diff    
Issuezilla Id: 11,863

 Description   

To allow later Jersey upgrade in GF v 3.0.1, the dependency defined in
packager/glassfish-web-incorporation/src/main/resources/pkg_proto.py
should change from jersey@1.1 to jersey@1. (Going to attach the diff)

Original constraint was fine with respect to the old Jersey versioning schema
(1.1.1, 1.1.2, 1.1.3, 1.1.4). This has changed after the 1.1.5 relase.
The next Jersey release is going to be 1.2, then 1.3 and so on.



 Comments   
Comment by Jakub Podlesak [ 06/May/10 ]

Created an attachment (id=4341)
patch

Comment by Snjezana Sevo-Zenzerovic [ 06/May/10 ]

I will apply this to 3.1 (trunk) shortly - do you also need this change done in
3.0.1 branch?

Comment by Jakub Podlesak [ 06/May/10 ]

trunk should already be fine, we need this change in 3.0.1 branch

Comment by Snjezana Sevo-Zenzerovic [ 06/May/10 ]

OK, I am setting target milestone to 3.0.1...

Comment by Jakub Podlesak [ 06/May/10 ]

Great, thanks!

Comment by Snjezana Sevo-Zenzerovic [ 11/May/10 ]

Fix checked into 3.0.1 branch, will be available in promoted build 18.





[GLASSFISH-11854] tool not reporting errors/warnings from upgrade Created: 04/May/10  Updated: 05/May/10  Resolved: 05/May/10

Status: Resolved
Project: glassfish
Component/s: upgrade_tool
Affects Version/s: v3.0.1
Fix Version/s: v3.0.1

Type: Bug Priority: Critical
Reporter: Bobby Bissett Assignee: Bobby Bissett
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Macintosh


Issuezilla Id: 11,854

 Description   

Saw this once during some testing and need to verify that it's actually working,
or fix if not. The asadmin command output is parsed for warning or error
messages and the tool is supposed to warn the user if one is encountered, but I
saw a server log containing a warning that did not appear in the tool as well.

Would be good to have this fixed in 3.0.1.



 Comments   
Comment by Bobby Bissett [ 05/May/10 ]

Output switched from "<LEVEL>:<text>" to "<text>|<LEVEL>|<text>" somewhere along
the line. Am changing regex pattern to match now. Can change it to just look for
the level string by itself if this continues to be an issue. That could result
in some false positives, but that's better than missing an error.

Testing now....

Comment by Bobby Bissett [ 05/May/10 ]

Fixed in the 3.0.1 branch, revision 36781.





[GLASSFISH-11831] [regression] jpa validation failure in bvcallbackbmt Created: 28/Apr/10  Updated: 18/May/10  Resolved: 18/May/10

Status: Resolved
Project: glassfish
Component/s: entity-persistence
Affects Version/s: v3.0.1
Fix Version/s: v3.0.1

Type: Bug Priority: Critical
Reporter: sherryshen Assignee: Mitesh Meswani
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Text File bvcallbackbmt.zip    
Issuezilla Id: 11,831

 Description   

v3.0.1 b16
In bvcallbackbmt tests, the long name is persisted without
getting Bean Validation exception.

To reproduce the issue:
1) deploy war
asadmin deploy bvcallbackbmt.war

2) access url to persist short name
http://localhost:8080/bvcallbackbmt/test?tc=initialize
Test passed.

3) access url to persist long name
http://localhost:8080/bvcallbackbmt/test?tc=validatePersist
Test failed.

The server.log shows that long name is persisted.
[#|2010-04-28T15:01:52.509-0700|INFO|glassfish3.0|javax.enterprise.system.std.com.sun.
enterprise.v3.services.impl|_ThreadID=26;_ThreadName=Thread-1;|
2. Persisting employee with long name....|#]

[#|2010-04-28T15:01:52.512-0700|FINE|glassfish3.0|org.eclipse.persistence.session.file:
/space/test1/v3/glassfish/domains/domain1/applications/bvcallbackbmt/WEB-INF/classes/_pu1.sql|
_ThreadID=26;
_ThreadName=Thread-1;ClassName=null;MethodName=null;|
INSERT INTO BV_EMPL (ID, NAME, SALARY) VALUES (?, ?, ?)
bind => [5, myLongName5, 5000]|#]

[#|2010-04-28T15:01:52.532-0700|INFO|glassfish3.0|javax.enterprise.system.std.com.sun.enterprise.v3.services.impl|
_ThreadID=26;_ThreadName=Thread-1;|
Error: not get BV ex for persist|#]

The war file and source code will be attached.

The same tests passed on v3.0.1 b15.



 Comments   
Comment by sherryshen [ 28/Apr/10 ]

Created an attachment (id=4319)
war file and test source

Comment by sherryshen [ 04/May/10 ]

The issue is reported and fixed at
https://bugs.eclipse.org/bugs/show_bug.cgi?id=311225

Comment by Mitesh Meswani [ 14/May/10 ]

This issue never surfaced in 3.0.1 branch as result of above EclipseLink issue. We
have rolled back to previous version of EclipseLink into 3.0.1 branch.
We had never pulled in EclipseLink code with this bug into trunk (3.1). The latest
version of EclipseLink integrated contains fix for the issue.

Marking the issue as fixed

Comment by sherryshen [ 18/May/10 ]

Verified the fix on v3.0.1 b19 promoted, which has EclipseLink,
version: Eclipse Persistence Services - 2.0.1.v20100213-r6600.

The failure occurred on v3.0.1 b16 with the integration of
EclipseLink 2.0.2, and the integration was rolled back later.

Comment by sherryshen [ 18/May/10 ]

A correction to my previous comment.
The fix is verified on b18 promoted (not b19 promoted).





[GLASSFISH-11824] grizzly threads not closed, stays in preClose0 and holds lock Created: 27/Apr/10  Updated: 27/Apr/10  Resolved: 27/Apr/10

Status: Resolved
Project: glassfish
Component/s: grizzly-kernel
Affects Version/s: V3
Fix Version/s: v3.0.1

Type: Bug Priority: Major
Reporter: johanvos Assignee: oleksiys
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Linux
Platform: Linux


Issuezilla Id: 11,824

 Description   

I observe "hangs" in GF3 when all threads in the http-threadgroup are blocked,
waiting on a particular thread to release a lock. The particular thread is in
sun.nio.ch.FileDispatcher.preClose0(Native Method) and never returns, hence the
lock is never released.

The stacktrace of this thread:

Thread "Thread-11" thread-id: 27 thread-state: RUNNABLE Running in native
at: sun.nio.ch.FileDispatcher.preClose0(Native Method)
at: sun.nio.ch.SocketDispatcher.preClose(SocketDispatcher.java:41)
at:
sun.nio.ch.SocketChannelImpl.implCloseSelectableChannel(SocketChannelImpl.java:684)
at:
java.nio.channels.spi.AbstractSelectableChannel.implCloseChannel(AbstractSelectableChannel.java:201)
at:
java.nio.channels.spi.AbstractInterruptibleChannel.close(AbstractInterruptibleChannel.java:97)
at: sun.nio.ch.SocketAdaptor.close(SocketAdaptor.java:352)
at:
com.sun.grizzly.TCPSelectorHandler.closeChannel(TCPSelectorHandler.java:1354)
at:
com.sun.grizzly.BaseSelectionKeyHandler.doAfterKeyCancel(BaseSelectionKeyHandler.java:229)
at:
com.sun.grizzly.BaseSelectionKeyHandler.cancel(BaseSelectionKeyHandler.java:216)
at:
com.sun.grizzly.http.SelectorThreadKeyHandler.cancel(SelectorThreadKeyHandler.java:80)
at:
com.sun.enterprise.v3.services.impl.monitor.MonitorableSelectionKeyHandler.cancel(MonitorableSelectionKeyHandler.java:80)
at:
com.sun.grizzly.TCPSelectorHandler.addPendingKeyCancel(TCPSelectorHandler.java:613)
at:
com.sun.grizzly.http.SelectorThreadKeyHandler.expire(SelectorThreadKeyHandler.java:136)
at:
com.sun.grizzly.TCPSelectorHandler.postSelect(TCPSelectorHandler.java:556)
at:
com.sun.grizzly.SelectorHandlerRunner.doSelect(SelectorHandlerRunner.java:206)
at:
com.sun.grizzly.SelectorHandlerRunner.run(SelectorHandlerRunner.java:130)
at:
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at:
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at: java.lang.Thread.run(Thread.java:619)



 Comments   
Comment by oleksiys [ 27/Apr/10 ]

this is duplicate
https://grizzly.dev.java.net/issues/show_bug.cgi?id=547

it will be fixed in 3.0.1

Comment by oleksiys [ 27/Apr/10 ]

fix target





[GLASSFISH-11817] [regression] bmt_txlocal_apptimeout test failed to get web response Created: 22/Apr/10  Updated: 05/May/10  Resolved: 05/May/10

Status: Resolved
Project: glassfish
Component/s: web_container
Affects Version/s: v3.0.1
Fix Version/s: v3.0.1

Type: Bug Priority: Critical
Reporter: sherryshen Assignee: Shing Wai Chan
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Sun


Issuezilla Id: 11,817

 Description   

bmt_txlocal_apptimeout test failed to get web response

On v3.0.1 b15, bmt_txlocal_apptimeout test gets null response.
The same test passed on v3.0.1 b14.

To reproduce the issue:
do "ant all" with sqe env and in the directory of
appserver-sqe/pe/transaction/bmt/txlocal/timeout/apptimeout

To get test source and setup env, please refer core test instruction,
http://agni-1.sfbay.sun.com/JSPWiki/Wiki.jsp?page=SQECoreFULL
You can check out transaction module only with co-transaction.

The same failure was reported in v2.1.2 previously.
https://glassfish.dev.java.net/issues/show_bug.cgi?id=11747



 Comments   
Comment by sherryshen [ 23/Apr/10 ]

To debug the failure on my local machine, the problem
seems related to the usage of sleep.
java.lang.InterruptedException: sleep interrupted

do "ant clean build setup deploy" (no error)
do "ant run" (see error at client and server below on b15, but not on b14)

v3.0.1 b15 client output and server.log
runweb:
[webtest] Full Path of Result File->
/space/test1/SRC/c301/appserver-sqe/reports/pe-pe/sparc_win60_SunOS/tx-gtest-results.xml
[webtest] This is the new GTest version. in request dispatch...
[webtest] Non SSL request...
[webtest] In Session :bmt_txlocal_apptimeout
[webtest] RedirectResponse=HTTP/1.0
[webtest] authMethod OTHER
[webtest] ERROR (false,true)in : GET
/txbmt-txlocal-apptimeout-web/txbmt-txlocal-apptimeout?timeout=30 HTTP/1.0
[webtest] Expected Output ****************************************
[webtest] <html><head><title>AppTimeout Test Client</title></head><body>
[webtest] <p>Got Home Object of Session Bean from JNDI Context
[webtest] <p>Got EJB Object of Session Bean from home object
[webtest] <p>Start Transaction with Timeout: 30
[webtest] <p>Removed Stateful Bean
[webtest] <p>Transaction Rolledback after Timeout
[webtest] <p>BMT_TxLocal_AppTimeout STATUS: *PASSED*
[webtest] </body></html>
[webtest]
[webtest] ********************************************************
[webtest] Actual Output ##########################################
[webtest] null
[webtest] #####################################################
[webtest] FAIL No description (GET
/txbmt-txlocal-apptimeout-web/txbmt-txlocal-apptimeout?timeout=30 HTTP/1.0)
[webtest] lastTask

BUILD SUCCESSFUL
Total time: 35 seconds
test1@win60%

[#|2010-04-23T09:13:05.126-0700|INFO|glassfish3.0|javax.enterprise.system.std.com.sun.enterprise.v3.services.impl|
_ThreadID=27;_ThreadName=Thread-1;|setDivision() in Entity Bean|#]

[#|2010-04-23T09:13:34.880-0700|WARNING|glassfish3.0|com.sun.grizzly.config.GrizzlyServiceListener|
_ThreadID=15;_ThreadName=Thread-1;|Interrupting idle Thread:
http-thread-pool-8080-(1)|#]

[#|2010-04-23T09:13:34.881-0700|INFO|glassfish3.0|javax.enterprise.system.std.com.sun.enterprise.v3.services.impl|
_ThreadID=27;_ThreadName=Thread-1;|Error! in doGet() of ServletClient|#]

[#|2010-04-23T09:13:34.884-0700|SEVERE|glassfish3.0|javax.enterprise.system.std.com.sun.enterprise.v3.services.impl|
_ThreadID=27;_ThreadName=Thread-1;|java.lang.InterruptedException: sleep interrupted
at java.lang.Thread.sleep(Native Method)
at
com.sun.s1peqe.transaction.bmt.txlocal.timeout.apptimeout.web.ServletClient.doGet(ServletClient.java:72)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:734)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
at
org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1523)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:279)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:188)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:641)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:97)
at
com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:85)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:185)
at
org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:332)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:233)
at
com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:165)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:791)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:693)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:954)
at
com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:170)
at
com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:135)
at
com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:102)
at
com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:88)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:76)
at
com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:53)
at
com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:57)
at com.sun.grizzly.ContextTask.run(ContextTask.java:69)
at
com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:330)
at
com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:309)
at java.lang.Thread.run(Thread.java:619)

#]

v3.0.1 b14 client output and server.log
runweb:
[webtest] Full Path of Result File->
/space/test1/SRC/c301/appserver-sqe/reports/pe-pe/sparc_win60_SunOS/tx-gtest-results.xml
[webtest] This is the new GTest version. in request dispatch...
[webtest] Non SSL request...
[webtest] In Session :bmt_txlocal_apptimeout
[webtest] RedirectResponse=HTTP/1.0
[webtest] authMethod OTHER
[webtest] OK -->GET
/txbmt-txlocal-apptimeout-web/txbmt-txlocal-apptimeout?timeout=30 HTTP/1.0
[webtest] lastTask

BUILD SUCCESSFUL
Total time: 54 seconds
[#|2010-04-23T09:25:33.844-0700|INFO|glassfish3.0|javax.enterprise.system.std.com.sun.enterprise.v3.services.impl|
_ThreadID=25;_ThreadName=Thread-1;|setDivision() in Entity Bean|#]
.....
[#|2010-04-23T09:26:18.878-0700|INFO|glassfish3.0|javax.enterprise.system.std.com.sun.enterprise.v3.services.impl|
_ThreadID=25;_ThreadName=Thread-1;|ejbPassivate() in Entity Bean|#]

[#|2010-04-23T09:26:18.879-0700|INFO|glassfish3.0|javax.enterprise.system.std.com.sun.enterprise.v3.services.impl|
_ThreadID=25;_ThreadName=Thread-1;|Expected Rollback Exception is thrown:
javax.transaction.RollbackException: Transaction rolled back due to time out.|#]

[#|2010-04-23T09:26:18.918-0700|INFO|glassfish3.0|javax.enterprise.system.std.com.sun.enterprise.v3.services.impl|
_ThreadID=25;_ThreadName=Thread-1;|removeEntity() in Stateful Bean|#]

Comment by Shing Wai Chan [ 26/Apr/10 ]

If I change the timeout configuration from 30 to 10, then the test passes.

Comment by Shing Wai Chan [ 27/Apr/10 ]

This is fixed by grizzly integration 1.9.18-o.

Comment by sherryshen [ 05/May/10 ]

Verified the fix on v3.0.1 b16.





[GLASSFISH-11797] OSGi/HHTP Service incorrectly populates initParams in ServletConfig Created: 15/Apr/10  Updated: 15/Apr/10  Resolved: 15/Apr/10

Status: Resolved
Project: glassfish
Component/s: OSGi-JavaEE
Affects Version/s: v3.0.1
Fix Version/s: v3.0.1

Type: Bug Priority: Major
Reporter: Sanjeeb Sahoo Assignee: Sanjeeb Sahoo
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 11,797

 Description   

The following patch pretty much explains the bug:

Index:
/home/ss141213/WS/gf/v3/osgi-javaee/osgi-http/src/main/java/org/glassfish/osgihttp/OSGiServletConfig.java
===================================================================

/home/ss141213/WS/gf/v3/osgi-javaee/osgi-http/src/main/java/org/glassfish/osgihttp/OSGiServletConfig.java
(revision 36452)
+++
/home/ss141213/WS/gf/v3/osgi-javaee/osgi-http/src/main/java/org/glassfish/osgihttp/OSGiServletConfig.java
(working copy)
@@ -61,8 +61,9 @@
if (initParams != null) {
Enumeration e = initParams.keys();
while (e.hasMoreElements())

{ - this.initParams.put((String) e.nextElement(), - (String) initParams.get(e)); + final Object key = e.nextElement(); + this.initParams.put((String) key, + (String) initParams.get(key)); }

}
}

We need this to be fixed in 3.0.1. I came across this while helping a vaadin
user use GlassFish [1].

[1]
http://vaadin.com/forum/-/message_boards/message/137711;jsessionid=4ED5C6E6085E81A459A5D4831A2475DF#_19_message_137981



 Comments   
Comment by Sanjeeb Sahoo [ 15/Apr/10 ]

Fixing it in trunk:
Sending
home/ss141213/WS/gf/v3/osgi-javaee/osgi-http/src/main/java/org/glassfish/osgihttp/OSGiServletConfig.java
Transmitting file data .
Committed revision 36472.

Will wait for approval from Abhijit before commiting in 3.0.1.

Comment by Sanjeeb Sahoo [ 15/Apr/10 ]

Now fixing in 3.0.1 branch:
Sending osgi-http/src/main/java/org/glassfish/osgihttp/OSGiServletConfig.java
Transmitting file data .
Committed revision 36483.





[GLASSFISH-11777] Authentication problem with servlets registered through HTTP service Created: 10/Apr/10  Updated: 12/Apr/10  Resolved: 12/Apr/10

Status: Resolved
Project: glassfish
Component/s: OSGi-JavaEE
Affects Version/s: v3.0.1
Fix Version/s: v3.0.1

Type: Bug Priority: Major
Reporter: erikengerd Assignee: Sanjeeb Sahoo
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Linux


Issuezilla Id: 11,777
Tags: v3_0_1_approved

 Description   

I have installed the OSGI HTTP service through admin console and after that
deployed the felix webconsole 2.0.6. This webconsole provides a webinterface for
the installed OSGI bundles and uses default username/password = admin/admin.

What happens is that I have to enter the username and password twice before the
authentication succeeds. The issue is similar with the felix webconsole version
3.0.0 but did not try that in detail. (should be checked as well for solving
this bug).

Since the felix webconsole registers the servlet through the HTTP service this
problem is in the area of OSGI-Java EE integration.



 Comments   
Comment by kumara [ 12/Apr/10 ]

Fix in 3.0.1

Comment by Sanjeeb Sahoo [ 12/Apr/10 ]

This is already fixed in trunk as part of revision #36233). No, committing fix
to 3.0.1 branch:
Sending
osgi-javaee/osgi-http/src/main/java/org/glassfish/osgihttp/GlassFishHttpService.java
Transmitting file data .
Committed revision 36444.

This will be part of v3.0.1 build #13.





[GLASSFISH-11773] Application Server image is not a link Created: 09/Apr/10  Updated: 05/May/10  Resolved: 05/May/10

Status: Resolved
Project: glassfish
Component/s: admin_gui
Affects Version/s: v2.1.2
Fix Version/s: v3.0.1

Type: Bug Priority: Major
Reporter: kenpaulsen Assignee: kenpaulsen
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 11,773

 Description   

The Application Server Tree Node's image is not clickable – it should be.



 Comments   
Comment by kenpaulsen [ 09/Apr/10 ]

The image has now been converted to a clickable image. Although it cannot be
tabbed to (intentional for 508 usability), it can be clicked on with the mouse
now. This issue is resolved.

Comment by Anissa Lam [ 09/Apr/10 ]

add cc.

Comment by sb110099 [ 04/May/10 ]

Verified that the images in the tree node are not "tabbed to" which satisfies
508 compliance.

Comment by sb110099 [ 05/May/10 ]

Changed target to 3.0.1





[GLASSFISH-11772] 508: Service Assembly folder speech is incorrect. Created: 09/Apr/10  Updated: 05/May/10  Resolved: 05/May/10

Status: Resolved
Project: glassfish
Component/s: admin_gui
Affects Version/s: v2.1.2
Fix Version/s: v3.0.1

Type: Bug Priority: Major
Reporter: kenpaulsen Assignee: kenpaulsen
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 11,772

 Description   

When tabbing on the service assembly folder when using a screen reader like
ORCA, the speech incorrectly says something about deployment.



 Comments   
Comment by kenpaulsen [ 09/Apr/10 ]

The folder nodes are no longer accessible by keyboard. This is intentional so
that the link text is not read multiple times. This issue should now be resolved.

Comment by Anissa Lam [ 09/Apr/10 ]

add cc.

Comment by sb110099 [ 05/May/10 ]

Changed target milestone to 3.0.1

Comment by Anissa Lam [ 05/May/10 ]

Service Assembly is only available in v2 , provided by the JBI team. However,
support for JBI is not in v3, there is no such thing as JBI package to add to v3.

I would say that as long as QA can verify that ALL folder nodes are no longer
accessible by keyboard, as according to Ken's comment, this bug can mark as
verified.





[GLASSFISH-11771] 508: Tabbing through doc links pops up a new window Created: 09/Apr/10  Updated: 05/May/10  Resolved: 05/May/10

Status: Resolved
Project: glassfish
Component/s: admin_gui
Affects Version/s: v2.1.1
Fix Version/s: v3.0.1

Type: Bug Priority: Major
Reporter: kenpaulsen Assignee: kenpaulsen
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 11,771

 Description   

When tabbing through the common task page links, when you get to the doc links a
new window is popped up if you hit any key (such as tab). We should not execute
a link unless the user hits enter or clicks on it.



 Comments   
Comment by kenpaulsen [ 09/Apr/10 ]
  • Removed keypress event to prevent unwanted window from popping up.
Comment by Anissa Lam [ 09/Apr/10 ]

Fixed in 2.1.2.
This probably doesn't exist for 3.0.1, but Sudipa please verify when testing
3.0.1. thanks.

Comment by sb110099 [ 04/May/10 ]


Verified with b16 of V3.0.1. The issue is fixed .

Comment by sb110099 [ 05/May/10 ]

Changed target milestone to 3.0.1





[GLASSFISH-11769] EJB creation fails when JPA artifacts are moved to utility jar Created: 09/Apr/10  Updated: 04/Jun/10  Resolved: 04/Jun/10

Status: Resolved
Project: glassfish
Component/s: ejb_container
Affects Version/s: V3
Fix Version/s: v3.0.1

Type: Bug Priority: Critical
Reporter: theodan Assignee: ksak
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All
URL: http://forums.java.net/jive/message.jspa?messageID=396062#396062


Attachments: File App with JPA in EAR Lib.ear    
Issuezilla Id: 11,769

 Description   

I have a simple EAR containing an EJB module and a JPA utility jar in EAR/lib.
The JPA utility jar contains a persistence unit, an entity, a Dao interface,
and a DaoImpl class. My EJB uses @PersistenceContext to inject an
EntityManager, and @Inject to inject the Dao.

Deployment of this EAR succeeds, but in Admin Console > Applications, the
Engines column shows only "[ejb, webservices, weld]" (note lack of "jpa").
When I deploy a similar EAR that has the JPA utility jar contents merged into
the EJB module, the Engines column shows "[ejb, webservices, jpa, weld]". So
that is one indicator that something is wrong when the JPA stuff is separated
into a utility jar.

The main issue is that, upon invoking my EJB, it fails as follows:

Caused by: java.lang.NullPointerException
at java.util.concurrent.ConcurrentHashMap.get
(ConcurrentHashMap.java:768)
at org.jboss.weld.manager.BeanManagerImpl.getBean
(BeanManagerImpl.java:1171)
at org.jboss.weld.manager.BeanManagerImpl.getBean
(BeanManagerImpl.java:132)
at org.glassfish.weld.services.JCDIServiceImpl.injectEJBInstance
(JCDIServiceImpl.java:135)
at com.sun.ejb.containers.BaseContainer.injectEjbInstance
(BaseContainer.java:1604)
at com.sun.ejb.containers.StatelessSessionContainer.createStatelessEJB
(StatelessSessionContainer.java:487)
... 72 more

Sahoo had this to say:

http://forums.java.net/jive/message.jspa?messageID=396062#396062

"This does look like a bug. Can you report it under ejb subcategory? Let's
start with ejb dev looking into it. I am sure it will end up in cdi
subcategory as I believe the bug is in cdi integration layer."



 Comments   
Comment by theodan [ 09/Apr/10 ]

Created an attachment (id=4298)
EAR with JPA artifacts moved into a utility JAR

Comment by theodan [ 09/Apr/10 ]

Requesting 3.0.1 target.

Comment by jhasenbe [ 01/Jun/10 ]

We have the same issue in our application with the same module and library
structure (except that our EJBs are not exposed as WebService).
Trying to create an SLSB that has the DAO injected fails at exactly the same
location. It even fails as soon as we turn on CDI (see below).

This is critical for future development and I therefor rise the priority by one
level.

One thing we noticed:

Our SLSB was in the very beginning using JPA like this:
@PersistenceContext EnitityManager em;
This worked fine in GF 3.0.1, build 19. At that time, we did not have the file
META-INF/beans.xml in the EJB module.
Then, we wanted to get the DAO classes (which have the injected EntityManager
reference) injected via CDI and added the required META-INF/beans.xml to the EJB
module.
Immediately after doing this, we get the described behavior even without trying
to inject anything via CDI. Looks like enabling CDI changes the container
strategy to inject JPA resources (WELD?) and that is not working.

Comment by jhasenbe [ 01/Jun/10 ]

add me to cc

Comment by marina vatkina [ 04/Jun/10 ]

duplicate

      • This issue has been marked as a duplicate of 11888 ***




[GLASSFISH-11767] Persistence deployer ignores @PersistenceUnit / @PersistenceContext annotations in CDI managed beans Created: 08/Apr/10  Updated: 07/Jun/10  Resolved: 07/Jun/10

Status: Resolved
Project: glassfish
Component/s: entity-persistence
Affects Version/s: V3
Fix Version/s: v3.0.1

Type: Bug Priority: Major
Reporter: theodan Assignee: Mitesh Meswani
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All
URL: http://forums.java.net/jive/message.jspa?messageID=395980#395980


Attachments: File App.ear    
Issuezilla Id: 11,767

 Description   

@PersistenceUnit and @PersistenceContext annotations are not being honored in
CDI managed beans in an EJB module if there isn't at least one EJB that also
uses the annotations.

I am attaching an EAR containing a single EJB module. The EJB module contains
one EJB, one Dao interface, and one DaoImpl class. The @PersistenceContext in
the DaoImpl class is ignored, given the EAR contents as they are. If you
add "@PersistenceContext EntityManager em;" at the top of the EJB, then both
annotations are honored (in the EJB and in the DaoImpl).

The expected result is that the @PersistenceContext in the DaoImpl should be
honored regardless of whether there's also an EJB with @PersistenceContext.

Sahoo told me the cause of this bug here:

http://forums.java.net/jive/message.jspa?messageID=395980#395980

"The persistence deployer in GlassFish is thinking that there is no component
in the EAR using the persistence-unit, so it does not initialize it. Obviously
that's a bug. It is not parsing managed beans."



 Comments   
Comment by theodan [ 08/Apr/10 ]

Created an attachment (id=4297)
EAR with EJB module and source code

Comment by theodan [ 08/Apr/10 ]

I'm asking for a v3.0.1 target.

Comment by theodan [ 08/Apr/10 ]

Setting URL to forum discussion.

Comment by Hong Zhang [ 09/Apr/10 ]

assign to mitesh for initial evaluation

Comment by Mitesh Meswani [ 07/Jun/10 ]

Fixed with http://fisheye4.atlassian.com/changelog/glassfish-svn/?cs=37568





[GLASSFISH-11761] Need to document Secure Naming Service for Standalone client Created: 07/Apr/10  Updated: 14/Jun/10  Resolved: 14/Jun/10

Status: Resolved
Project: glassfish
Component/s: docs
Affects Version/s: v3.0.1
Fix Version/s: v3.0.1

Type: Task Priority: Major
Reporter: Nithya Ramakrishnan Assignee: Paul Davies
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 11,761
Tags: v3_0_1_approved

 Description   

There was a recent change to enable SSL for the naming service in EJBs. For the appclient, this is done (as
in GF v2) using the sun-acc.xml. For standalone client, a new system property
"com.sun.CSIV2.ssl.standalone.client.required" is to be passed while running the client to contact the name
service of the GF server securely. This has to be documented for 3.0.1



 Comments   
Comment by Paul Davies [ 08/Apr/10 ]

Set target milestone to 3.0.1

Comment by Paul Davies [ 09/Apr/10 ]

Approved in email by Jerome.

Comment by Scott Fordin [ 11/Jun/10 ]

Added bullet item to "What's New?" section of 3.0.1 Release Notes. Topic should
be added in more detail to the Developer's Guide.

Comment by Paul Davies [ 14/Jun/10 ]

Standalone clients are not officially supported and should not be mentioned in
the product documentation.





[GLASSFISH-11751] loading admin gui alters mime type mappings Created: 05/Apr/10  Updated: 26/Apr/10  Resolved: 26/Apr/10

Status: Resolved
Project: glassfish
Component/s: web_container
Affects Version/s: v3.0.1
Fix Version/s: v3.0.1

Type: Bug Priority: Major
Reporter: vince kraemer Assignee: Shing Wai Chan
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Mac OS X
Platform: Macintosh


Issuezilla Id: 11,751
Tags: v3_0_1_approved

 Description   

See http://netbeans.org/bugzilla/show_bug.cgi?id=183460 for details.

I was able to reproduce this issue without NB in the picture.

here is a quick sbs...

touch the file domains/domain1/docroot/wgfaSftCapture3.wmv

start the server

run the app attached to the NB issue... note the content type...

use the browser to open the admin gui

run the app attached to the nb issue... the content-type is different.



 Comments   
Comment by jluehe [ 05/Apr/10 ]

Before the admin gui is accessed, a request for

domains/domain1/docroot/wgfaSftCapture3.wmv

will be handled by the Grizzly layer directly, that is, default-web.xml is not
in the picture.

Accessing the admin gui will cause the web container to be launched. From that
point onward, a request for

domains/domain1/docroot/wgfaSftCapture3.wmv

will be handled by the (dummy) web module created around the virtual server's
docroot, and the MIME mappings in default-web.xml will be consulted.

Comment by Shing Wai Chan [ 05/Apr/10 ]

...

Comment by Shing Wai Chan [ 05/Apr/10 ]

Sending web-core/src/main/java/org/apache/catalina/Connector.java
Sending web-core/src/main/java/org/apache/catalina/connector/Connector.java
Sending
web-core/src/main/java/org/apache/catalina/connector/CoyoteAdapter.java
Sending
web-glue/src/main/java/com/sun/enterprise/web/connector/coyote/PECoyoteConnector.java
Transmitting file data ....
Committed revision 36305.

Comment by Shing Wai Chan [ 06/Apr/10 ]

Sending src/main/java/org/apache/catalina/connector/CoyoteAdapter.java
Transmitting file data .
Committed revision 36321.

Comment by Shing Wai Chan [ 07/Apr/10 ]

Revert the previous fix as it breaks Servlet 3.0 TCK.
Sending web-core/src/main/java/org/apache/catalina/Connector.java
Sending web-core/src/main/java/org/apache/catalina/connector/Connector.java
Sending
web-core/src/main/java/org/apache/catalina/connector/CoyoteAdapter.java
Sending
web-glue/src/main/java/com/sun/enterprise/web/connector/coyote/PECoyoteConnector.java
Transmitting file data ....
Committed revision 36338.

The correct fix should be in Grizzly. And the code is under reviewed.

Comment by Shing Wai Chan [ 08/Apr/10 ]

Fix checkin in Grizzly.
Sending http/src/main/java/com/sun/grizzly/http/ProcessorTask.java
Transmitting file data .
Committed revision 4420.

The fix will be available in the coming Grizzly integration.

Comment by Shing Wai Chan [ 12/Apr/10 ]

add v3.0.1_approved, will commit the change to branch soon

Comment by Shing Wai Chan [ 12/Apr/10 ]

Port fix to Grizzly 1.9.18m tags
Sending http/src/main/java/com/sun/grizzly/http/ProcessorTask.java
Transmitting file data .
Committed revision 4429.

Comment by Shing Wai Chan [ 12/Apr/10 ]

Sending PECoyoteConnector.java
Transmitting file data .
Committed revision 36442.

Comment by Shing Wai Chan [ 26/Apr/10 ]

additional fix in Grizzly that allow setting default response type to be null
Sending http/src/main/java/com/sun/grizzly/http/ProcessorTask.java
Transmitting file data .
Committed revision 4479.





[GLASSFISH-11750] url-patterns does not behave as agreed upon in the EG recently. Created: 02/Apr/10  Updated: 08/Apr/10  Resolved: 08/Apr/10

Status: Resolved
Project: glassfish
Component/s: web_container
Affects Version/s: v3.0.1
Fix Version/s: v3.0.1

Type: Bug Priority: Critical
Reporter: Rajiv Mordani Assignee: Shing Wai Chan
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 11,750

 Description   

url-patterns from web-fragment are not additive to the one in the web.xml. The
one in the web.xml wins. This applies to servlet mappings.



 Comments   
Comment by Shing Wai Chan [ 08/Apr/10 ]

Sending
deployment/dol/src/main/java/com/sun/enterprise/deployment/LocalStrings.properties
Sending
deployment/dol/src/main/java/com/sun/enterprise/deployment/ServletFilterDescriptor.java
Sending
deployment/dol/src/main/java/com/sun/enterprise/deployment/ServletFilterMappingDescriptor.java
Sending
deployment/dol/src/main/java/com/sun/enterprise/deployment/WebBundleDescriptor.java
Sending
deployment/dol/src/main/java/com/sun/enterprise/deployment/WebComponentDescriptor.java
Sending
deployment/dol/src/main/java/com/sun/enterprise/deployment/WebFragmentDescriptor.java
Transmitting file data ......
Committed revision 36374.

Comment by Shing Wai Chan [ 08/Apr/10 ]

removed extra space
Sending WebBundleDescriptor.java
Transmitting file data .
Committed revision 36377.

Comment by Shing Wai Chan [ 08/Apr/10 ]

Sending
deployment/dol/src/main/java/com/sun/enterprise/deployment/LocalStrings.properties
Sending
deployment/dol/src/main/java/com/sun/enterprise/deployment/ServletFilterDescriptor.java
Sending
deployment/dol/src/main/java/com/sun/enterprise/deployment/ServletFilterMappingDescriptor.java
Sending
deployment/dol/src/main/java/com/sun/enterprise/deployment/WebBundleDescriptor.java
Sending
deployment/dol/src/main/java/com/sun/enterprise/deployment/WebComponentDescriptor.java
Sending
deployment/dol/src/main/java/com/sun/enterprise/deployment/WebFragmentDescriptor.java
Transmitting file data ......
Committed revision 36379.





[GLASSFISH-11738] need to include "Connector Specification" in Java EE Support section in "features.html" Created: 30/Mar/10  Updated: 17/May/10  Resolved: 17/May/10

Status: Resolved
Project: glassfish
Component/s: docs
Affects Version/s: v3.0.1
Fix Version/s: v3.0.1

Type: Bug Priority: Major
Reporter: Jagadish Assignee: Paul Davies
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 11,738
Tags: v3_0_1_approved

 Description   

GlassFish installation has "features.html" in "docs" directory that lists the
new features introduced in GlassFish v3.
This also lists the Java EE 6 standards implemented as part of the release.

Refer the section "Java EE Support"

We need to include "Java EE Connector Architecture 1.6" in the list.

Need the same change in v3.1 also.



 Comments   
Comment by Paul Davies [ 08/Apr/10 ]

Set target milestone to 3.0.1

Comment by Paul Davies [ 09/Apr/10 ]

Approved in email by Jerome.

Comment by Paul Davies [ 17/May/10 ]

Fix available for 3.0.1





[GLASSFISH-11732] Error in : http://docs.sun.com/app/docs/doc/820-4502/beato?a=view Created: 29/Mar/10  Updated: 13/Apr/10  Resolved: 13/Apr/10

Status: Resolved
Project: glassfish
Component/s: docs
Affects Version/s: V3
Fix Version/s: v3.0.1

Type: Bug Priority: Critical
Reporter: kumarjayanti Assignee: Rebecca Parks
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 11,732
Tags: v3_0_1_approved

 Description   

The page : http://docs.sun.com/app/docs/doc/820-4502/beato?a=view

has an error where it describes the short form IOR as "input-output redirection".

An IOR stands for "Interoperable Object Reference".



 Comments   
Comment by Paul Davies [ 08/Apr/10 ]

Set target milestone to 3.01. Reassigned to junesm

Comment by Paul Davies [ 09/Apr/10 ]

Approved in email by Jerome.

Comment by Rebecca Parks [ 13/Apr/10 ]

Fixed in Application Deployment Guide for 3.0.1.





[GLASSFISH-11708] Number of available updates discrepancy in the admin console Created: 19/Mar/10  Updated: 30/Apr/10  Resolved: 30/Apr/10

Status: Resolved
Project: glassfish
Component/s: admin_gui
Affects Version/s: V3
Fix Version/s: v3.0.1

Type: Bug Priority: Major
Reporter: Chris Kasso Assignee: Anissa Lam
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 11,708

 Description   

After installing GFv3 I accessed the admin console. It indicated in the upper
left area:

There are 41 update(s) available.

Clicking on that string takes me to the Available Updates tab:

http://localhost:4848/updateCenter/update.jsf

which indicates there are no updates available. At this point a user goes huh?

This is going to frustrate even the most patient of users.

Likely the updates are available for packages which are installed from the
preferred repo but the updated package is in a non-preferred repo.

This may be caused by pkg(5) issue:

http://defect.opensolaris.org/bz/show_bug.cgi?id=2772

Until that gets fixed it is probably best to work around the issue in the admin
console.

Note that updatetool and the desktop notifier are in sync here and match the
behavior of the Available Updates tab in the admin console.



 Comments   
Comment by Anissa Lam [ 30/Apr/10 ]

When calculating the update count to be displayed in the masthead, the code does
an inventory, which includes potential updates to packages from different
authorities.

In the Update Tab, besides does the inventory, we also check to make sure that
those potential updates would actually be applied by an install plan.

Thus sometimes, there is discrepancy between them.
I have changed the code so that the # displayed in the header is derived using
the same algorithm. The code for the update tab was factored to be used by both.

The fix has been checked in to both trunk and 3.0.1 branch.

Author: anilam
Date: 2010-04-30 23:39:03+0000
New Revision: 36687

Modified:

branches/3.0.1/admingui/updatecenter/src/main/java/org/glassfish/uc/admingui/UpdateCenterHandlers.java

Log:
issue# 11708. Fix the available updates discrepancy in the header and the
available update tab.

----------------

Author: anilam
Date: 2010-04-30 23:47:21+0000
New Revision: 36688

Modified:

trunk/v3/admingui/updatecenter/src/main/java/org/glassfish/uc/admingui/UpdateCenterHandlers.java

Log:
issue# 11708. Fix the available updates discrepancy in the header and the
available update tab.

Marking as fixed.





[GLASSFISH-11707] No documentation about pre-configured UC repositories Created: 19/Mar/10  Updated: 16/Jun/10  Resolved: 16/Jun/10

Status: Resolved
Project: glassfish
Component/s: docs
Affects Version/s: V3
Fix Version/s: v3.0.1

Type: Bug Priority: Critical
Reporter: Chris Kasso Assignee: Mike Fitch
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 11,707
Tags: v3_0_1_approved

 Description   

The different GF distros come preconfigured with a set of pkg(5) based repositories:

dev.glassfish.sun.com
contrib.glassfish.org
contrib.glassfish.sun.com
dev.glassfish.org
release.glassfish.sun.com

Generally one of the repos is marked as "preferred".

In reviewing the GF docs I could find no information about the definition and
purpose of any of the repositories.

The docs should contain:

1) General definition of what a repo is.
2) Purpose of the "preferred" repo and why a user may want to change it.
3) How the "preferred" repo impacts available updates.
4) Definition/purpose/contents of each of the GF public repos.
5) How to configure and access a "support" repo.
6) How to browse a repo via the web.

I have also filed UC issue 2097:

https://updatecenter2.dev.java.net/issues/show_bug.cgi?id=2097

The updatetool should also provide a repo description field.



 Comments   
Comment by Paul Davies [ 08/Apr/10 ]

Set target milestone to v3.0.1

Comment by Paul Davies [ 09/Apr/10 ]

Approved in email by Jerome.

Comment by Paul Davies [ 09/Apr/10 ]

Reassigned to oncered.

Comment by Mike Fitch [ 26/May/10 ]

Online help updated to refer to Admin Guide, which will contain details about
the repos for GlassFish.

Comment by Mike Fitch [ 16/Jun/10 ]

The requested information, to the level of detail appropriate to a GlassFish
user, has been added to the Oracle GlassFish Server 3.0.1 Administration Guide
in the section "Preconfigured Repositories for GlassFish Server". See
http://docs.sun.com/doc/821-1751/gjzko for details.





[GLASSFISH-11706] Windows installer crash on some systems Created: 19/Mar/10  Updated: 14/Jul/10  Resolved: 14/Jul/10

Status: Closed
Project: glassfish
Component/s: installation
Affects Version/s: V3
Fix Version/s: v3.0.1

Type: Bug Priority: Major
Reporter: Snjezana Sevo-Zenzerovic Assignee: gmurr
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Windows XP
Platform: All


Attachments: Zip Archive BugGlassFishBrazil.zip    
Issuezilla Id: 11,706

 Description   

I am opening this issue to track Windows installer crash as reported in this
forum thread:

http://forums.java.net/jive/thread.jspa?messageID=392678

Problem apparently persists on affected systems. Self-extracting installer seems
to start OI wizard but only the initial splash screen shows up before the crash.



 Comments   
Comment by javanoide [ 21/Mar/10 ]

Created an attachment (id=4276)
Installation error step by step (print screens and computer configuration)

Comment by gatto [ 25/Apr/10 ]

I had the same problem and I have a workaround. I'm running windows vista SP2,
English version, fully updated. I have my regional an language settings set to
"Portuguese (Brazil)" and that seems to be the problem.

I switched to "English (United States)" and the installer worked. You should be
able to reproduce the bug by changing your settings to "Portuguese (Brazil)".

Comment by scatari [ 26/Apr/10 ]

Georges,
Could u please take a look at this to see if it has anything to do with locale settings and missing
resources? Please feel free to assign it back to me after evaluation.

Thanks

Comment by gmurr [ 26/Apr/10 ]

This is caused by translation issue in pt_BR installer property file. Will be
fixed in 3.0.1

Comment by gmurr [ 14/Jul/10 ]

fixed in 3.0.1

Comment by gmurr [ 14/Jul/10 ]

issue fixed





[GLASSFISH-11703] poor output from asadmin version Created: 18/Mar/10  Updated: 11/May/10  Resolved: 11/May/10

Status: Resolved
Project: glassfish
Component/s: admin
Affects Version/s: v3.0.1
Fix Version/s: v3.0.1

Type: Bug Priority: Major
Reporter: vince kraemer Assignee: Snjezana Sevo-Zenzerovic
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Sun


Issuezilla Id: 11,703
Tags: v3_0_1_approved

 Description   

I have installed
http://download.java.net/glassfish/3.0.1/promoted/glassfish-3.0.1-b09.zip.

after I start the server, I see this

bash-3.2$ /export/home/vkraemer/GlassFish_3_100318/glassfish/bin/asadmin version -v
Version = GlassFish v3 (build 9), JRE version 1.6.0_18
Command version executed successfully.

While I know that I did not install
http://download.java.net/glassfish/v3/promoted/glassfish-v3-b09.zip, others may
have problems determining that.

Could we change the output to something like

Version = GlassFish 3.0.1 (build 9), JRE version 1.6.0_18
Command version executed successfully.



 Comments   
Comment by Snjezana Sevo-Zenzerovic [ 18/Mar/10 ]

Taking ownership.

Comment by kumara [ 05/Apr/10 ]

Approved for 3.0.1.

Comment by Snjezana Sevo-Zenzerovic [ 28/Apr/10 ]

It turned out that current GlassFish Version class defines only major and minor
version. So, we would need to either add update version field or use version
suffix to tack ".1" at the end - the problem with latter is that we currently
also add space between the version and version suffix content while assembling
full version output...

Comment by Snjezana Sevo-Zenzerovic [ 11/May/10 ]

Fix checked into 3.0.1 branch, will be available in promoted build 18.





[GLASSFISH-11702] possible NPE during undeploy --cascade=true RAR Created: 18/Mar/10  Updated: 12/Apr/10  Resolved: 12/Apr/10

Status: Resolved
Project: glassfish
Component/s: jca
Affects Version/s: v3.0.1
Fix Version/s: v3.0.1

Type: Bug Priority: Major
Reporter: Jagadish Assignee: Jagadish
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 11,702
Tags: v3_0_1_approved

 Description   

Please refer issue 11698 for complete details. This is a placeholder issue for
v3.0.1



 Comments   
Comment by Jagadish [ 18/Mar/10 ]

setting correct target milestone

Comment by kumara [ 05/Apr/10 ]

Approved for 3.0.1.

Comment by Jagadish [ 12/Apr/10 ]

FIX INFORMATION :

svn log -v -r 36427

https://glassfish-svn.dev.java.net/servlets/ReadMsg?list=commits&msgNo=18961

Fix will be available in 3.0.1 promoted-build-13
http://download.java.net/glassfish/v3.0.1/promoted/





[GLASSFISH-11701] failure in loading RAR should result in RAR deployment failure Created: 18/Mar/10  Updated: 12/Apr/10  Resolved: 12/Apr/10

Status: Resolved
Project: glassfish
Component/s: jca
Affects Version/s: v3.0.1
Fix Version/s: v3.0.1

Type: Bug Priority: Major
Reporter: Jagadish Assignee: Jagadish
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 11,701
Tags: v3_0_1_approved

 Description   

Please refer issue 11699 for complete details. This is a placeholder issue for 3.0.1



 Comments   
Comment by Jagadish [ 18/Mar/10 ]

setting correct target milestone

Comment by kumara [ 05/Apr/10 ]

Approved for 3.0.1.

Comment by Jagadish [ 12/Apr/10 ]

FIX INFORMATION :

svn log -v -r 36427

https://glassfish-svn.dev.java.net/servlets/ReadMsg?list=commits&msgNo=18961

Fix will be available in 3.0.1 promoted-build-13
http://download.java.net/glassfish/v3.0.1/promoted/





[GLASSFISH-11696] work context need not be validated for 1.0 RAR Created: 17/Mar/10  Updated: 12/Apr/10  Resolved: 12/Apr/10

Status: Resolved
Project: glassfish
Component/s: jca
Affects Version/s: v3.0.1
Fix Version/s: v3.0.1

Type: Bug Priority: Major
Reporter: Jagadish Assignee: Jagadish
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 11,696
Tags: v3_0_1_approved

 Description   

Please refer issue 11691 for complete details. This is a placeholder issue for
v3.0.1



 Comments   
Comment by Jagadish [ 17/Mar/10 ]

setting correct target milestone

Comment by kumara [ 05/Apr/10 ]

Approved for 3.0.1.

Comment by Jagadish [ 12/Apr/10 ]

FIX INFORMATION :

svn log -v -r 36424

https://glassfish-svn.dev.java.net/servlets/ReadMsg?list=commits&msgNo=18958

Fix will be available in 3.0.1 promoted-build-13
http://download.java.net/glassfish/v3.0.1/promoted/





[GLASSFISH-11695] possible NPE during web-container startup Created: 17/Mar/10  Updated: 20/May/10  Resolved: 20/May/10

Status: Resolved
Project: glassfish
Component/s: web_container
Affects Version/s: 3.1
Fix Version/s: v3.0.1

Type: Bug Priority: Major
Reporter: Jagadish Assignee: Shing Wai Chan
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 11,695

 Description   

WebContainer during startup looks at all of the network-listeners in each
<config> element in domain.xml

QL - AMX tests seems to create the following configuration :

<config name="AMXConfigProxyTests.TEST" dynamic-reconfiguration-enabled="false">
<property description="desc.for.prop0" name="prop0" value="prop0-value" />
<property description="desc.for.prop1" name="prop1" value="prop1-value" />
<property description="desc.for.prop2" name="prop2" value="prop2-value" />
<property description="desc.for.prop3" name="prop3" value="prop3-value" />
<property description="desc.for.prop4" name="prop4" value="prop4-value" />
</config>

As a result of this configuration (no network-listeners in this configuration),
web-container startup, while configuring network-listeners fails with the
following NPE :

[#|2010-03-18T00:31:15.164+0530|SEVERE|glassfishv3.0|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=25;_ThreadName=Thread-1;|Cannot
start container web
java.lang.NullPointerException
at com.sun.enterprise.web.WebContainer.postConstruct(WebContainer.java:532)
at com.sun.hk2.component.AbstractWombImpl.inject(AbstractWombImpl.java:174)
at com.sun.hk2.component.ConstructorWomb$1.run(ConstructorWomb.java:87)
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.hk2.component.ConstructorWomb.initialize(ConstructorWomb.java:84)
at com.sun.hk2.component.AbstractWombImpl.get(AbstractWombImpl.java:77)
at
com.sun.hk2.component.SingletonInhabitant.get(SingletonInhabitant.java:58)
at com.sun.hk2.component.LazyInhabitant.get(LazyInhabitant.java:107)
at
com.sun.hk2.component.AbstractInhabitantImpl.get(AbstractInhabitantImpl.java:60)
at org.glassfish.internal.data.EngineInfo.getContainer(EngineInfo.java:91)
at
com.sun.enterprise.v3.server.ApplicationLifecycle.startContainers(ApplicationLifecycle.java:719)
at
com.sun.enterprise.v3.server.ApplicationLifecycle.setupContainerInfos(ApplicationLifecycle.java:464)
at
org.glassfish.javaee.full.deployment.EarDeployer.prepareBundle(EarDeployer.java:265)
at
org.glassfish.javaee.full.deployment.EarDeployer.access$200(EarDeployer.java:80)
at
org.glassfish.javaee.full.deployment.EarDeployer$1.doBundle(EarDeployer.java:132)
at
org.glassfish.javaee.full.deployment.EarDeployer$1.doBundle(EarDeployer.java:130)
at
org.glassfish.javaee.full.deployment.EarDeployer.doOnBundles(EarDeployer.java:198)
at
org.glassfish.javaee.full.deployment.EarDeployer.doOnAllTypedBundles(EarDeployer.java:207)
at
org.glassfish.javaee.full.deployment.EarDeployer.doOnAllBundles(EarDeployer.java:236)
at
org.glassfish.javaee.full.deployment.EarDeployer.prepare(EarDeployer.java:130)
at
com.sun.enterprise.v3.server.ApplicationLifecycle.prepareModule(ApplicationLifecycle.java:647)
at
com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:299)
at
com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:186)
at
org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:276)
at
com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:313)
at
com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:328)
at
com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1190)
at
com.sun.enterprise.v3.admin.CommandRunnerImpl.access$900(CommandRunnerImpl.java:84)
at
com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1249)
at
com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1238)
at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:365)
at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:204)
at
com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:166)
at
com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:113)
at
com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:245)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:811)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:708)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1017)
at
com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:171)
at
com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:135)
at
com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:102)
at
com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:88)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:76)
at
com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:53)
at
com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:57)
at com.sun.grizzly.ContextTask.run(ContextTask.java:69)
at
com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:526)
at
com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:507)
at java.lang.Thread.run(Thread.java:619)

#]


 Comments   
Comment by jluehe [ 18/Mar/10 ]

Shing Wai, can you take a look?

Comment by Shing Wai Chan [ 19/Mar/10 ]

Sending src/main/java/com/sun/enterprise/web/WebContainer.java
Transmitting file data .
Committed revision 36046.

Port the fix to 3.0.1 branch:
ending src/main/java/com/sun/enterprise/web/WebContainer.java
Transmitting file data .
Committed revision 36047.





[GLASSFISH-11682] integrate new schema documentation command Created: 15/Mar/10  Updated: 24/Mar/10  Resolved: 24/Mar/10

Status: Resolved
Project: glassfish
Component/s: command_line_interface
Affects Version/s: v3.0.1
Fix Version/s: v3.0.1

Type: Bug Priority: Major
Reporter: Justin Lee Assignee: Justin Lee
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Macintosh


Issuezilla Id: 11,682

 Description   

Integrate the command into v3 proper. Original web site can found at
http://kenai.com/projects/schema-doc



 Comments   
Comment by Justin Lee [ 15/Mar/10 ]

targetting 3.0.1

Comment by Justin Lee [ 17/Mar/10 ]

will rename to generate-domain-schema

Comment by Justin Lee [ 24/Mar/10 ]

committed to trunk rev 36090
committed to branches/3.0.1 rev 36096





[GLASSFISH-11675] NullPointerException encountered and Error message is not clear when deploying a RA application without <resourceadapter-class> tag in ra.xml Created: 12/Mar/10  Updated: 12/Apr/10  Resolved: 12/Apr/10

Status: Resolved
Project: glassfish
Component/s: jca
Affects Version/s: v3.0.1
Fix Version/s: v3.0.1

Type: Bug Priority: Major
Reporter: Jagadish Assignee: Jagadish
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 11,675
Tags: v3_0_1_approved

 Description   

This is a placeholder for issue 11566 so as to provide a fix in 3.0.1
Please refer issue 11566 for complete details



 Comments   
Comment by Jagadish [ 13/Mar/10 ]

setting correct target milestone

Comment by kumara [ 05/Apr/10 ]

Approved for 3.0.1.

Comment by Jagadish [ 12/Apr/10 ]

FIX INFORAMATION :

svn log -v -r 36426

https://glassfish-svn.dev.java.net/servlets/ReadMsg?list=commits&msgNo=18960

Fix will be available in 3.0.1 promoted-build-13
http://download.java.net/glassfish/v3.0.1/promoted/





[GLASSFISH-11662] undeploying .ear with embedded .rar does not remove associated resources when --cascade=true Created: 08/Mar/10  Updated: 12/Apr/10  Resolved: 12/Apr/10

Status: Resolved
Project: glassfish
Component/s: jca
Affects Version/s: v3.0.1
Fix Version/s: v3.0.1

Type: Bug Priority: Major
Reporter: Jagadish Assignee: Jagadish
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 11,662
Tags: v3_0_1_approved

 Description   

Please refer issue 11590 for complete details. This is a placeholder issue for 3.0.1



 Comments   
Comment by Jagadish [ 08/Mar/10 ]

setting correct target milestone

Comment by kumara [ 05/Apr/10 ]

Approved for 3.0.1.

Comment by Jagadish [ 12/Apr/10 ]

FIX INFORMATION :

svn log -v -r 36427

https://glassfish-svn.dev.java.net/servlets/ReadMsg?list=commits&msgNo=18961

Fix will be available in 3.0.1 promoted-build-13
http://download.java.net/glassfish/v3.0.1/promoted/





[GLASSFISH-11661] use Connector Classloader while loading wrapper class of jdbc driver class during transaction recovery Created: 08/Mar/10  Updated: 12/Apr/10  Resolved: 12/Apr/10

Status: Resolved
Project: glassfish
Component/s: jca
Affects Version/s: v3.0.1
Fix Version/s: v3.0.1

Type: Bug Priority: Major
Reporter: Jagadish Assignee: Jagadish
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 11,661
Tags: v3_0_1_approved

 Description   

Please refer issue 11569 for complete details. This is a placeholder issue for 3.0.1



 Comments   
Comment by Jagadish [ 08/Mar/10 ]

setting correct target milestone

Comment by kumara [ 05/Apr/10 ]

Approved for 3.0.1.

Comment by Jagadish [ 12/Apr/10 ]

FIX INFORMATION :

svn log -v -r 36428

https://glassfish-svn.dev.java.net/servlets/ReadMsg?list=commits&msgNo=18962

Fix will be available in 3.0.1 promoted-build-13
http://download.java.net/glassfish/v3.0.1/promoted/





[GLASSFISH-11657] No Documentation for 'asadmin create-service' on Windows Created: 08/Mar/10  Updated: 25/May/10  Resolved: 25/May/10

Status: Resolved
Project: glassfish
Component/s: docs
Affects Version/s: v3.0.1
Fix Version/s: v3.0.1

Type: Bug Priority: Major
Reporter: Byron Nevins Assignee: Paul Davies
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 11,657
Tags: v3_0_1_approved

 Description   

create-service is implemented for Windows and works but there is no
documentation for it. This was my fault as I let it fall through the cracks.
But let's fix it for V3.0.1 !



 Comments   
Comment by Paul Davies [ 08/Apr/10 ]

Set target milestone to 3.0.1

Comment by Paul Davies [ 09/Apr/10 ]

Approved in email by Jerome.

Comment by Paul Davies [ 19/May/10 ]

Source files updated; changes not yet propagated to the GF builds.

Comment by Paul Davies [ 25/May/10 ]

Fix to create-service is in nightly build of May 25, 2010





[GLASSFISH-11647] Standalone EJB Client & SSL - not fully encrypted Created: 04/Mar/10  Updated: 14/Jun/10  Resolved: 14/Jun/10

Status: Resolved
Project: glassfish
Component/s: security
Affects Version/s: V3
Fix Version/s: v3.0.1

Type: Bug Priority: Major
Reporter: ajvok Assignee: kumarjayanti
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Linux
URL: http://forums.java.net/jive/thread.jspa?threadID=75841&tstart=0


Issuezilla Id: 11,647
Tags: v3_0_1_approved

 Description   

I would like ALL comms between a Standalone-EJB-client and the GF server to be
entirely encrypted.

Currently, using the settings:

<ior-security-config>
<transport-config>
<integrity>required</integrity>
<confidentiality>required</confidentiality>
</transport-config>
</ior-security-config>

partially solves the problem, but there is still some unencrypted traffic on
port 3700.

This has been discussed in
http://forums.java.net/jive/thread.jspa?threadID=75841&tstart=0 and, but there
is as yet no solution and the only promising idea is use of AppClient.

I would like a way of doing this using a standalone client (not AppClient)

Without a solution, it seems that it is not possible to use a
standalone-EJB-client without risk that someone will sniff the unencrypted
traffic on port 3700. They might not be able to see your data (that should be
encrypted - forced by the above config), but (I think) they will be able to see
what objects you are looking up.

Thanks for looking at this.



 Comments   
Comment by kumara [ 08/Mar/10 ]

Approved for 3.0.1

Comment by Nithya Ramakrishnan [ 25/Mar/10 ]

This issue has now been fixed in v3 for both the appclient and the standalone
client cases. For the appclient, the sun-acc.xml should have a security element
to indicate a secure client connection. For the standalone client, a system
property : com.sun.CSIV2.ssl.standalone.client.required=true needs to be passed
so that a SSL handshake is requested by the client.

Comment by ajvok [ 29/Mar/10 ]

Thank you for looking at this issue.
I have run into trouble using the fix.

I have re-opened this issue & apologise if it is my stupidity that is preventing
this from working.

Any advice much appreciated.

=====================================

Using Nightly Build from Mar 29.

While trying to get this working I'm also running the following command to watch
what is being sent to ports 3700 & 3820:
tcpdump -i any -p -s 0 dst port 3820 or 3700

Run previous version of my client program, with the new GlassFish build:
tcpdump reports activity on both 3820 & 3700.
This is as expected and represents the issue at hand (i.e. we don't want
activity on 3700).
Client program completes successfully.

Add the line:
System.setProperty("com.sun.CSIV2.ssl.standalone.client.required","true");

Run again: Activity only on 3700. Program fails.

Add the line:
System.setProperty("javax.net.debug", "all");

Run again: It looks my client is trying to make an SSL connection on the non-SSL
3700.

Add the line:
props.setProperty("org.omg.CORBA.ORBInitialPort", "3820");

Run again: Still only activity on 3700.

Change the server config so that 3700 uses SSL rather than plaintext:
For orb-listener-1, tick 'security enabled' and save.
Remove the line: props.setProperty("org.omg.CORBA.ORBInitialPort", "3820");

Run again: Still only activity on 3700 (Expected). Program fails. Looks like
3700 is still a plaintext port.

Restart the server - make sure previous orb config has taken hold.

Run again: no difference.

Look again at the server config. On orb-listener-1, see the SSL tab. Change the
certificate nickname from blank to s1as (same as for the SSL listener).
Save & restart the server.
The server fails to start.

Am I missing some simple config trick in either the client or the server?

Where do I go from here?

Thanks.
===========================================

Comment by ajvok [ 29/Mar/10 ]

Another half hour messing with this has produced a result.

Previously I was doing this:
=======================================================
props.setProperty("org.omg.CORBA.ORBInitialPort", "3820");
Context ctx = new InitialContext(props);
=======================================================

But when I replace the first line with:
System.setProperty("org.omg.CORBA.ORBInitialPort", "3820");

...all is well.

Now, I only have activity on port 3820 and the program completes successfully.

That wraps it up for me.

Thank you for resolving this issue so promptly.

Comment by Dhiru Pandey [ 14/Jun/10 ]

Closing this bug as the fix was verified by submitter





[GLASSFISH-11630] Unable to lookup configured jdbc pools without security policy Created: 01/Mar/10  Updated: 04/Oct/10  Resolved: 04/Oct/10

Status: Resolved
Project: glassfish
Component/s: jca
Affects Version/s: v3.0.1
Fix Version/s: v3.0.1

Type: Bug Priority: Major
Reporter: eileeny Assignee: Jagadish
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 11,630

 Description   

Exception thrown when trying to look up configured jdbc resources. User error
is unlikely since these errors were thrown during automated testing which is
unchanged from previous builds.

jdbc resource is configured as follows:
<jdbc-connection-pool steady-pool-size="200" max-pool-size="200" datasource-c
lassname="oracle.jdbc.pool.OracleDataSource" name="tpcw">
<property name="URL" value="jdbc:oracle:thin:@sjsdata:1521:benchdb" />
<property name="Password" value="tpcw" />
<property name="User" value="tpcw" />
<property name="ImplicitCachingEnabled" value="true" />
<property name="MaxStatements" value="200" />
</jdbc-connection-pool>
<jdbc-resource pool-name="tpcw" jndi-name="jdbc/tpcw" />

Exceptions from server.log:
[#|2010-03-01T10:00:10.162-0800|SEVERE|glassfishv3.0|javax.enterprise.resource.re
sourceadapter.com.sun.enterprise.connectors.service|_ThreadID=24;_ThreadName=Thre
ad-1;|RAR8061: failed to load resource-adapter-config or RA [ __ds_jdbc_ra ], com
.sun.appserv.connectors.internal.api.ConnectorRuntimeException: Error in creating
active RAR|#]

[#|2010-03-01T10:00:10.163-0800|SEVERE|glassfishv3.0|javax.enterprise.resource.re
sourceadapter.com.sun.enterprise.connectors.service|_ThreadID=24;_ThreadName=Thre
ad-1;|RAR8060: Unable to lookup pool [ tpcw ], javax.naming.NamingException: Look
up failed for '__SYSTEM/pools/tpcw' in SerialContext [Root exception is javax.na
ming.NameNotFoundException: pools]|#]

[#|2010-03-01T10:00:10.163-0800|SEVERE|glassfishv3.0|javax.enterprise.resource.re
sourceadapter.com.sun.enterprise.connectors.service|_ThreadID=24;_ThreadName=Thre
ad-1;|RAR6017 : Failed to get connection pool object via JNDI lookup : tpcw|#]

[#|2010-03-01T10:00:10.164-0800|SEVERE|glassfishv3.0|javax.enterprise.resource.re
sourceadapter.com.sun.enterprise.connectors.service|_ThreadID=24;_ThreadName=Thre
ad-1;|
com.sun.appserv.connectors.internal.api.ConnectorRuntimeException: rardeployment.
jndi_lookup_failed



 Comments   
Comment by Shalini [ 02/Mar/10 ]

Seems like the way of doing lookup is wrong. How is the lookup of the datasource
"jdbc/tpcw" done? Please attach a snippet of the code that does the lookup to
evaluate this issue further.

Comment by eileeny [ 02/Mar/10 ]

Here's the code for resource lookup. It's very simple and has not changed since
we started testing with the benchmark for sjsas8.1.

datasourceName = ContextParameterHelper.getJdbcName();
try {
InitialContext ic = new InitialContext();
Context c = null;
try

{ // Tomcat requires lookup this way, even though no one else does... c = (Context) ic.lookup("java:/comp/env"); }

catch (NamingException ne)

{ c = ic; }

datasource = (DataSource)c.lookup(datasourceName);
} catch(NamingException ne) {

I'm also seeing the same problem with SPECjAppServer and SPECjEnterprise
benchmarks that we run on every build.

Comment by eileeny [ 02/Mar/10 ]

Reassigning to security and lowering priority since there is an easy workaround.

Performance testing systematically removes the security policy from the java
command line to ensure that security is disabled.

<jvm-options>-Djava.security.policy=$

{com.sun.aas.instanceRoot}

/config/
server.policy</jvm-options>

Once this option is reintroduced in the java commandline, the jdbc lookup is
fine. Why is this option now required for resource lookups? And what is the
correct way to ensure security is disabled for 10.0.1?

Comment by Shalini [ 02/Mar/10 ]

reassigning to security team.

Comment by kumarjayanti [ 04/Oct/10 ]

Hi eileeny,

This bug has been assigned to security team but i am not clear what is the real issue here and what needs
to be fixed by the security team here. Can you please elaborate.

Comment by Jagadish [ 04/Oct/10 ]

This fixed as part of issues 6858162 in 3.0.1 and 3.1 (2 issues for 3.1 :
6858162 and 6933825).

Fix was made available in 3.0.1-b14

Comment by Jagadish [ 04/Oct/10 ]

re-opening to assign it to myself.

Comment by Jagadish [ 04/Oct/10 ]

-> jr158900

Comment by Jagadish [ 04/Oct/10 ]

Fixed.





[GLASSFISH-11622] PipeHelper.getClientSecurityContext returns context from web container invocation Created: 26/Feb/10  Updated: 05/Mar/10  Resolved: 05/Mar/10

Status: Resolved
Project: glassfish
Component/s: security
Affects Version/s: 9.0pe
Fix Version/s: v3.0.1

Type: Bug Priority: Critical
Reporter: monzillo Assignee: kumarjayanti
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Sun


Issuezilla Id: 11,622
Tags: v3_0_1_approved

 Description   

returned context may be for prior invocation



 Comments   
Comment by kumarjayanti [ 04/Mar/10 ]

checked in a fix.

Can you try with the latest build from :

http://hudson.glassfish.org/job/gf-trunk-build-continuous/

and let us know if it fixes.

make sure the build number is >= 3810.

Comment by kumara [ 05/Mar/10 ]

Approved for v3.0.1. Please commit to the branch also.

Comment by vdeschenes [ 05/Mar/10 ]

I confirm the issue to be resolved.
With this change I am not able to reproduce the problem anymore using my test case.

I will however wait for a stable mount before to deploy and test on QC server.

Many thanks !





[GLASSFISH-11620] ClassNotFoundException when server has CORBA system properties set and receives a remote call from an appclient Created: 26/Feb/10  Updated: 22/Apr/10  Resolved: 22/Apr/10

Status: Resolved
Project: glassfish
Component/s: orb
Affects Version/s: V3
Fix Version/s: v3.0.1

Type: Bug Priority: Critical
Reporter: paise_s Assignee: Ken Cavanaugh
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Linux
Platform: Linux


Issuezilla Id: 11,620
Tags: v3_0_1_approved

 Description   

Scenario:
Attempting to setup Glassfish to accept remote EJB calls through a firewall as
per documentation http://docs.sun.com/app/docs/doc/820-7695/ghbpc?a=view

Problem:
When Glassfish accepts the remote call, the following stack trace is logged in
server.log, and the call will eventually timeout for the client:

[#|2010-02-26T10:29:56.927+0000|SEVERE|glassfishv3.0|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=11;_ThreadName=Thread-1;|Exception
while loading the app
java.lang.RuntimeException: EJB Container initialization error
at
org.glassfish.ejb.startup.EjbApplication.loadContainers(EjbApplication.java:219)
at org.glassfish.ejb.startup.EjbDeployer.load(EjbDeployer.java:197)
at org.glassfish.ejb.startup.EjbDeployer.load(EjbDeployer.java:63)
at org.glassfish.internal.data.ModuleInfo.load(ModuleInfo.java:175)
at
org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:216)
at
com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:338)
at
com.sun.enterprise.v3.server.ApplicationLoaderService.processApplication(ApplicationLoaderService.java:340)
at
com.sun.enterprise.v3.server.ApplicationLoaderService.postConstruct(ApplicationLoaderService.java:163)
at com.sun.hk2.component.AbstractWombImpl.inject(AbstractWombImpl.java:174)
at com.sun.hk2.component.ConstructorWomb$1.run(ConstructorWomb.java:87)
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.hk2.component.ConstructorWomb.initialize(ConstructorWomb.java:84)
at com.sun.hk2.component.AbstractWombImpl.get(AbstractWombImpl.java:77)
at
com.sun.hk2.component.SingletonInhabitant.get(SingletonInhabitant.java:58)
at com.sun.hk2.component.LazyInhabitant.get(LazyInhabitant.java:107)
at
com.sun.hk2.component.AbstractInhabitantImpl.get(AbstractInhabitantImpl.java:60)
at
com.sun.enterprise.v3.server.AppServerStartup.run(AppServerStartup.java:236)
at
com.sun.enterprise.v3.server.AppServerStartup.start(AppServerStartup.java:128)
at com.sun.enterprise.module.bootstrap.Main.launch(Main.java:457)
at com.sun.enterprise.module.bootstrap.Main.launch(Main.java:401)
at org.jvnet.hk2.osgiadapter.HK2Main.start(HK2Main.java:125)
at
org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:640)
at org.apache.felix.framework.Felix.activateBundle(Felix.java:1700)
at org.apache.felix.framework.Felix.startBundle(Felix.java:1622)
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:915)
at org.jvnet.hk2.osgimain.Main.start(Main.java:140)
at
org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:640)
at org.apache.felix.framework.Felix.activateBundle(Felix.java:1700)
at org.apache.felix.framework.Felix.startBundle(Felix.java:1622)
at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1077)
at org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:264)
at java.lang.Thread.run(Thread.java:619)
Caused by: java.lang.RuntimeException: IIOP Protocol Manager initialization
failed. Possible cause is that ORB is not available in this container
at
com.sun.ejb.containers.BaseContainer.initializeProtocolManager(BaseContainer.java:813)
at com.sun.ejb.containers.BaseContainer.<init>(BaseContainer.java:558)
at
com.sun.ejb.containers.StatelessSessionContainer.<init>(StatelessSessionContainer.java:150)
at
com.sun.ejb.containers.StatelessSessionContainer.<init>(StatelessSessionContainer.java:144)
at
com.sun.ejb.containers.ContainerFactoryImpl.createContainer(ContainerFactoryImpl.java:99)
at
org.glassfish.ejb.startup.EjbApplication.loadContainers(EjbApplication.java:207)
... 31 more
Caused by: java.lang.RuntimeException: Orb initialization erorr
at
org.glassfish.enterprise.iiop.api.GlassFishORBHelper.getORB(GlassFishORBHelper.java:150)
at
org.glassfish.enterprise.iiop.api.GlassFishORBHelper.getProtocolManager(GlassFishORBHelper.java:189)
at
com.sun.ejb.containers.BaseContainer.initializeProtocolManager(BaseContainer.java:810)
... 36 more
Caused by: java.lang.RuntimeException: org.omg.CORBA.BAD_OPERATION: vmcid: SUN
minor code: 227 completed: No
at
org.glassfish.enterprise.iiop.impl.GlassFishORBManager.initORB(GlassFishORBManager.java:638)
at
org.glassfish.enterprise.iiop.impl.GlassFishORBManager.getORB(GlassFishORBManager.java:286)
at
org.glassfish.enterprise.iiop.impl.GlassFishORBFactoryImpl.createORB(GlassFishORBFactoryImpl.java:83)
at
org.glassfish.enterprise.iiop.api.GlassFishORBHelper.getORB(GlassFishORBHelper.java:122)
... 38 more
Caused by: org.omg.CORBA.BAD_OPERATION: vmcid: SUN minor code: 227 completed: No
at
com.sun.corba.ee.impl.logging.ORBUtilSystemException.orbConfiguratorError(ORBUtilSystemException.java:559)
at
com.sun.corba.ee.impl.logging.ORBUtilSystemException.orbConfiguratorError(ORBUtilSystemException.java:577)
at com.sun.corba.ee.impl.orb.ORBImpl.postInit(ORBImpl.java:581)
at com.sun.corba.ee.impl.orb.ORBImpl.set_parameters(ORBImpl.java:680)
at com.sun.corba.ee.impl.orb.ORBImpl.setParameters(ORBImpl.java:666)
at com.sun.corba.ee.spi.osgi.ORBFactory.initialize(ORBFactory.java:91)
at
org.glassfish.enterprise.iiop.impl.GlassFishORBManager.initORB(GlassFishORBManager.java:601)
... 41 more
Caused by: org.omg.CORBA.BAD_OPERATION: vmcid: SUN minor code: 254 completed: No
at
com.sun.corba.ee.impl.logging.ORBUtilSystemException.classActionException(ORBUtilSystemException.java:1323)
at
com.sun.corba.ee.impl.logging.ORBUtilSystemException.classActionException(ORBUtilSystemException.java:1342)
at
com.sun.corba.ee.spi.orb.OperationFactory$ClassAction.operate(OperationFactory.java:278)
at
com.sun.corba.ee.spi.orb.OperationFactory$ComposeAction.operate(OperationFactory.java:490)
at
com.sun.corba.ee.impl.orb.PrefixParserAction.apply(PrefixParserAction.java:93)
at com.sun.corba.ee.spi.orb.PropertyParser.parse(PropertyParser.java:81)
at com.sun.corba.ee.spi.orb.ParserImplBase.init(ParserImplBase.java:81)
at
com.sun.corba.ee.impl.orb.ORBConfiguratorImpl.runUserConfigurators(ORBConfiguratorImpl.java:185)
at
com.sun.corba.ee.impl.orb.ORBConfiguratorImpl.configure(ORBConfiguratorImpl.java:176)
at com.sun.corba.ee.impl.orb.ORBImpl.postInit(ORBImpl.java:579)
... 45 more
Caused by: java.lang.RuntimeException: java.lang.ClassNotFoundException:
com.sun.corba.ee.impl.plugin.hwlb.VirtualAddressAgentImpl
at com.sun.corba.ee.spi.orb.ORB$2.evaluate(ORB.java:817)
at com.sun.corba.ee.spi.orb.ORB$2.evaluate(ORB.java:812)
at com.sun.corba.ee.spi.orb.ORB$3.evaluate(ORB.java:838)
at com.sun.corba.ee.spi.orb.ORB$3.evaluate(ORB.java:834)
at
com.sun.corba.ee.spi.orb.OperationFactory$ClassAction.operate(OperationFactory.java:275)
... 52 more
Caused by: java.lang.ClassNotFoundException:
com.sun.corba.ee.impl.plugin.hwlb.VirtualAddressAgentImpl
at
com.sun.enterprise.loader.ASURLClassLoader.findClassData(ASURLClassLoader.java:736)
at
com.sun.enterprise.loader.ASURLClassLoader.findClass(ASURLClassLoader.java:626)
at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
at com.sun.corba.ee.spi.orb.ORB$2.evaluate(ORB.java:815)
... 56 more

Setup:
1. A new Glassfish V3 installation on Linux (Centos).
2. Client and Server on same machine.
3. Client defines system properties org.omg.CORBA.ORBInitialPort=3700 and
org.omg.CORBA.ORBInitialPHost=<ip address> to avoid using the loopback address.
4. System properties set on server using the commands as specified in documentation:

asadmin create-jvm-options -Dcom.sun.corba.ee.ORBVAAHost=public-IP-adress
asadmin create-jvm-options -Dcom.sun.corba.ee.ORBVAAPort=public-port
asadmin create-jvm-options
-Dcom.sun.corba.ee.ORBUserConfigurators.com.sun.corba.ee.impl.plugin.hwlb.VirtualAddressAgentImpl=x

5. Server restart applied after setting system properties.



 Comments   
Comment by paise_s [ 01/Mar/10 ]

Exception occurs on startup if an EJB is already deployed to the server.

Tested on V3.1 (nightly build - 27 FEB 2010), and same problem exists.

Comment by Sanjeeb Sahoo [ 01/Mar/10 ]

reassign to orb subcomponent.

Comment by Ken Cavanaugh [ 16/Mar/10 ]

This is almost certainly an OSGi problem, in that the ORB cannot find the
class due to the OSGi ClassLoader structure. I think we probably need
to add the VirtualAddressAgent to the ORB-Class-Provider list in
the glassfish-corba-orb.bnd file, but I'll need to verify this.

Comment by Ken Cavanaugh [ 23/Mar/10 ]

P1 is inappropriate for this, as the problem does not affect the
entire system. Moving to P2, and considering this bug for v3.0.1.

Comment by kumara [ 05/Apr/10 ]

Approved for 3.0.1.

Comment by Ken Cavanaugh [ 22/Apr/10 ]

Fixed in GF 3.0.1 b15.





[GLASSFISH-11618] Wrong selection of ssl cipher suites Created: 26/Feb/10  Updated: 24/Apr/15  Resolved: 15/Mar/10

Status: Resolved
Project: glassfish
Component/s: grizzly-kernel
Affects Version/s: V3
Fix Version/s: v3.0.1

Type: Bug Priority: Major
Reporter: nasradu8 Assignee: Justin Lee
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 11,618

 Description   

The SSL configuration page in admin GUI says: "If no cipher suite is added, ALL cipher suites will be
chosen."

But, when any app is run with no cipher suite explicitly configured, the following error is observed in
the server log.
[#|2010-02-
26T16:11:55.318+0530|WARNING|glassfishv3.0|com.sun.grizzly.config.GrizzlyServiceListener|_ThreadI
D=27;_ThreadName=http-thread-pool-8181(3);|pewebcontainer.all_ssl_ciphers_disabled|#]

This essentially means that no cipher suites are configured.

The correct behavior must be to enable a default set which is returned by
SSLSocketFactory.getDefault().getDefaultCipherSuites(), when there are no cipher suites enabled.



 Comments   
Comment by nasradu8 [ 26/Feb/10 ]

Adding Kumar and Oleksiy to cc list

Comment by kumarjayanti [ 26/Feb/10 ]

changed the target server

Comment by oleksiys [ 26/Feb/10 ]

I guess it's grizzly kernel issue.
Reassigning to Justin to check config module.

Comment by Dies Koper [ 26/Feb/10 ]

Please don't forget to fix the message too. It seems a message key is logged
instead of the real message.

Comment by Dies Koper [ 26/Feb/10 ]

Please don't forget to fix the message too. It seems a message key is logged
instead of the real message.

Comment by nasradu8 [ 01/Mar/10 ]

If any one particular cipher suite is enabled, then the warning dissapears.

Comment by Justin Lee [ 01/Mar/10 ]

One problem here is that the key used to find the logging message in grizzly is
out of sync with what's used in glassfish. I'ved updated that key to match and
changed the logging level to FINE instead of warning. Here's what glassfish
should be logging:

WEB0308: All SSL cipher suites disabled for network-listener

{0}, using SSL
implementation specific default [{0}

]s

So in the absence of any configured ciphers (and protocols), grizzly will use
the defaults as defined by the JDK implementation.

Given the logging level change (to reduce unnecessary chatter) and the
explanation given by the message, I think this bug can be marked as
closed/fixed. Does this satisfy everyone?

Comment by Justin Lee [ 12/Mar/10 ]

alexey removed the logging of this message in grizzly commit 4303

Comment by Justin Lee [ 12/Mar/10 ]

updated messages in grizzly commit 4307

Comment by Justin Lee [ 15/Mar/10 ]

updating target version to 3.0.1. Will require a grizzly integration whose exact
version has not been formally stated. Probably another 1.9.18 mini-release but
that needs to be decided soon.

Comment by HeinBloed [ 24/Apr/15 ]

Is it possible that this bug reappeared in GF 4.1 ...? At least I'm getting this log message with 4.1: "WARNING: All SSL cipher suites disabled for network-listener(s). Using SSL implementation specific defaults", although I didn't add any cipher suite in the admin GUI, as described above. I also stumbled across this thread: http://stackoverflow.com/questions/29726581/cant-use-localhost-version-of-glassfish-4-1-server-on-eclipse-luna, where someone else seems to get the same log message, presumably after not doing any (SSL) reconfigurations either.

EDIT: Actually, I made one modification to the SSL settings (in http-listener-2), I replaced the default certificate with a self-made one.





[GLASSFISH-11613] Bug in javax.servlet.MultipartConfigElement constructor Created: 25/Feb/10  Updated: 25/Feb/10  Resolved: 25/Feb/10

Status: Resolved
Project: glassfish
Component/s: web_container
Affects Version/s: V3
Fix Version/s: v3.0.1

Type: Bug Priority: Major
Reporter: jluehe Assignee: jluehe
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Macintosh


Issuezilla Id: 11,613

 Description   

Non-null "location" argument value is not saved in the "location" field.



 Comments   
Comment by jluehe [ 25/Feb/10 ]

Fixed on v3.1 trunk:

Sending javax.servlet/src/main/java/javax/servlet/MultipartConfigElement.java
Transmitting file data .
Committed revision 35745.

Backported fix to v3.0.1:

Sending javax.servlet/src/main/java/javax/servlet/MultipartConfigElement.java
Transmitting file data .
Committed revision 35746.





[GLASSFISH-11612] Bug or wrong documentation for org.glassfish.resources.custom.factory.PropertiesFactor Created: 25/Feb/10  Updated: 13/Apr/10  Resolved: 13/Apr/10

Status: Resolved
Project: glassfish
Component/s: docs
Affects Version/s: V3
Fix Version/s: v3.0.1

Type: Bug Priority: Major
Reporter: sstlaurent2 Assignee: Rebecca Parks
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 11,612
Tags: v3_0_1_approved

 Description   

Feel free to point me out if my issue is not filled correctly

Glassfish v3 documention at http://docs.sun.com/app/docs/doc/820-7695/giysn?a=view say that programmer must use org.glassfish.resources.custom.factory.PropertiesFactory with "file-location" property,
but my test shown that programmer must use "org.glassfish.resources.custom.factory.PropertiesFactory.fileName" instead,
took from glassfishv3\glassfish\lib\install\templates\resources\custom\properties_custom_resource.xml

I'm using GlassFish v3 (build 74.2)



 Comments   
Comment by Hong Zhang [ 25/Feb/10 ]

as this is resource related, assign to jagadish for initial evaluation

Comment by Jagadish [ 26/Feb/10 ]

The expected property name is "fileName". Assigning to "docs" team for changing
the documentation accordingly.

We need the docs change in 3.0.1 as well 3.1

Comment by Paul Davies [ 26/Feb/10 ]

Reassigned to junesm

Comment by kumara [ 05/Mar/10 ]

Approved for 3.0.1

Comment by Rebecca Parks [ 13/Apr/10 ]

Fixed in Application Development Guide for 3.0.1.





[GLASSFISH-11601] Use of unshareable connections leads to "Cannot use resource in unshareable scope" Created: 22/Feb/10  Updated: 01/Mar/10  Resolved: 01/Mar/10

Status: Resolved
Project: glassfish
Component/s: jdbc
Affects Version/s: V3
Fix Version/s: v3.0.1

Type: Bug Priority: Major
Reporter: Shalini Assignee: Shalini
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Linux


Issuezilla Id: 11,601
Tags: v3_0_1_approved

 Description   

Issue 7249 has to be fixed for V3.0.1. Creating a new issue to track this.



 Comments   
Comment by kumara [ 24/Feb/10 ]

Approved for 3.0.1

Comment by Shalini [ 01/Mar/10 ]

Fixed the issue in branch v3.0.1

Sending
connectors/connectors-runtime/src/main/java/com/sun/enterprise/connectors/ConnectionManagerImpl.java
Sending
connectors/connectors-runtime/src/main/java/com/sun/enterprise/resource/ConnectorXAResource.java
Sending
connectors/connectors-runtime/src/main/java/com/sun/enterprise/resource/allocator/LocalTxConnectorAllocator.java
Transmitting file data ...
Committed revision 35801.





[GLASSFISH-11594] Messages not logged from DataSourceObjectBuilder Created: 19/Feb/10  Updated: 10/Mar/10  Resolved: 10/Mar/10

Status: Resolved
Project: glassfish
Component/s: jdbc
Affects Version/s: V3
Fix Version/s: v3.0.1

Type: Bug Priority: Major
Reporter: Shalini Assignee: Shalini
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Linux


Issuezilla Id: 11,594
Tags: v3_0_1_approved

 Description   

Issue 11371 should be fixed for V3.0.1. Creating a new issue to track this.



 Comments   
Comment by kumara [ 24/Feb/10 ]

Approved for 3.0.1

Comment by Shalini [ 10/Mar/10 ]

Wrong logger is being used in a certain package. Modified this as part of this
fix and included log messages in the appropriate properties file.

Sending
jdbc/jdbc-ra/jdbc-core/src/main/java/com/sun/gjc/common/DataSourceObjectBuilder.java
Sending
jdbc/jdbc-ra/jdbc-core/src/main/java/com/sun/gjc/spi/ManagedConnectionFactory.java
Sending
jdbc/jdbc-ra/jdbc-core/src/main/resources/com/sun/gjc/spi/LogStrings.properties
Sending
jdbc/jdbc-ra/jdbc-core/src/main/resources/com/sun/gjc/util/LogStrings.properties
Transmitting file data ....
Committed revision 35947.





[GLASSFISH-11593] connection matching monitoring stats are always 0 Created: 19/Feb/10  Updated: 10/Mar/10  Resolved: 10/Mar/10

Status: Resolved
Project: glassfish
Component/s: jdbc
Affects Version/s: V3
Fix Version/s: v3.0.1

Type: Bug Priority: Major
Reporter: Shalini Assignee: Shalini
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Linux


Issuezilla Id: 11,593
Tags: v3_0_1_approved

 Description   

Issue 11376 should be fixed for V3.0.1. Creating a new issue to track this.



 Comments   
Comment by kumara [ 24/Feb/10 ]

Approved for 3.0.1

Comment by Shalini [ 10/Mar/10 ]

Fixed issue by turning on the connection matched stats.

Sending
connectors/connectors-runtime/src/main/java/com/sun/enterprise/resource/pool/ConnectionPool.java
Transmitting file data .
Committed revision 35946.





[GLASSFISH-11592] The feature to disable connection pooling has no effect. Created: 19/Feb/10  Updated: 10/Mar/10  Resolved: 10/Mar/10

Status: Resolved
Project: glassfish
Component/s: jdbc
Affects Version/s: V3
Fix Version/s: v3.0.1

Type: Bug Priority: Major
Reporter: Shalini Assignee: Shalini
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Linux


Issuezilla Id: 11,592
Tags: v3_0_1_approved

 Description   

Issue 11369 should be fixed for V3.0.1. Creating a new issue to track this.



 Comments   
Comment by kumara [ 24/Feb/10 ]

Approved for 3.0.1

Comment by Shalini [ 10/Mar/10 ]

Fixed by returning the right pool type for "Pooling disabled" case and checking
for the same when a flush connection pool is done.

Sending
connectors/connectors-runtime/src/main/java/com/sun/enterprise/connectors/service/ConnectorConnectionPoolAdminServiceImpl.java
Sending
connectors/connectors-runtime/src/main/resources/com/sun/enterprise/connectors/service/LocalStrings.properties
Sending
connectors/connectors-runtime/src/main/resources/com/sun/logging/enterprise/resource/resourceadapter/LogStrings.properties
Transmitting file data ...
Committed revision 35945.





[GLASSFISH-11591] Dynamic reconfig of SQL trace listeners fails Created: 19/Feb/10  Updated: 10/Mar/10  Resolved: 10/Mar/10

Status: Resolved
Project: glassfish
Component/s: jdbc
Affects Version/s: V3
Fix Version/s: v3.0.1

Type: Bug Priority: Major
Reporter: Shalini Assignee: Shalini
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Linux


Issuezilla Id: 11,591
Tags: v3_0_1_approved

 Description   

When SQL tracing listeners attribute is set to a custom listener, sql tracing
happens as expected. When the attribute is reconfigured by adding an additional
default sql trace listener along with the custom listener, the same test case
fails.

Test case to reproduce: appserv-tests/devtests/jdbc/tracingsql

This is because of a classloader issue and needs to be fixed.



 Comments   
Comment by kumara [ 24/Feb/10 ]

Approved for 3.0.1

Comment by Shalini [ 10/Mar/10 ]

Connector classloader is used as the context classloader to access resource
adapter classes during reconfiguration of resource related attributes.

Sending
common/container-common/src/main/java/org/glassfish/javaee/services/ResourceManager.java
Transmitting file data .
Committed revision 35948.





[GLASSFISH-11562] Use of shareable connections leads to "Cannot use resource in unshareable scope" Created: 15/Feb/10  Updated: 17/Feb/10  Resolved: 17/Feb/10

Status: Resolved
Project: glassfish
Component/s: jca
Affects Version/s: v3.0.1
Fix Version/s: v3.0.1

Type: Bug Priority: Major
Reporter: Jagadish Assignee: Jagadish
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 11,562
Tags: v3_0_1_approved

 Description   

Please refer issue 7568 for complete details, It is fixed in 9.1.1 patch
releases, GlassFish v3.1 (trunk).

Need to backport the fix from GF v3.1 to GF v3.0.1



 Comments   
Comment by Jagadish [ 15/Feb/10 ]

setting appropriate target milestone

Comment by kumara [ 16/Feb/10 ]

Approving for v3.0.1

Comment by Jagadish [ 17/Feb/10 ]

FIX INFORMATION :

svn log -v -r 35683
svn log -v -r 35682

https://glassfish-svn.dev.java.net/servlets/ReadMsg?list=commits&msgNo=18216
https://glassfish-svn.dev.java.net/servlets/ReadMsg?list=commits&msgNo=18215

Fix will be available from v3.0.1 build 06
http://download.java.net/glassfish/v3.0.1/promoted/





[GLASSFISH-11561] Failed to look up jms resources from other web servers Created: 15/Feb/10  Updated: 17/Feb/10  Resolved: 17/Feb/10

Status: Resolved
Project: glassfish
Component/s: jca
Affects Version/s: v3.0.1
Fix Version/s: v3.0.1

Type: Bug Priority: Major
Reporter: Jagadish Assignee: Jagadish
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 11,561
Tags: v3_0_1_approved

 Description   

please refer issue 4159 for complete details.
This is fixed in v3.1 (trunk).

Need to back port the fix in v3.0.1



 Comments   
Comment by Jagadish [ 15/Feb/10 ]

setting appropriate target milestone

Comment by kumara [ 16/Feb/10 ]

Approving for v3.0.1

Comment by Jagadish [ 17/Feb/10 ]

FIX INFORMATION :

svn log -v -r 35682

https://glassfish-svn.dev.java.net/servlets/ReadMsg?list=commits&msgNo=18215

Fix will be available from v3.0.1 build 06
http://download.java.net/glassfish/v3.0.1/promoted/





[GLASSFISH-11560] need to deactivate endpoints during RAR undeploy or server shutdown Created: 15/Feb/10  Updated: 17/Feb/10  Resolved: 17/Feb/10

Status: Resolved
Project: glassfish
Component/s: jca
Affects Version/s: v3.0.1
Fix Version/s: v3.0.1

Type: Bug Priority: Major
Reporter: Jagadish Assignee: Jagadish
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 11,560
Tags: v3_0_1_approved

 Description   

refer issue 11559 for complete details.
This is a placeholder issue for v3.0.1



 Comments   
Comment by Jagadish [ 15/Feb/10 ]

setting appropriate target milestone

Comment by kumara [ 16/Feb/10 ]

Approving for v3.0.1

Comment by Jagadish [ 17/Feb/10 ]

FIX INFORMATION :

svn log -v -r 35684

https://glassfish-svn.dev.java.net/servlets/ReadMsg?list=commits&msgNo=18217

Fix will be available from v3.0.1 build 06
http://download.java.net/glassfish/v3.0.1/promoted/





[GLASSFISH-11549] Grizzly config : Compression=integer does not work Created: 12/Feb/10  Updated: 30/Apr/10  Resolved: 30/Apr/10

Status: Resolved
Project: glassfish
Component/s: web_container
Affects Version/s: V3
Fix Version/s: v3.0.1

Type: Bug Priority: Major
Reporter: sb110099 Assignee: Justin Lee
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 11,549

 Description   

According to Jan and Jean-Francois, "compression=integer" should work.
Also confirmed through Shing-Wai's blog .

But it is Not working for V3. I had one test added for the same and
it currently fails as below :
"
com.sun.enterprise.admin.cli.CommandException: remote failure: Could not change the attributes:
org.jvnet.hk2.config.ValidationException:
Constraints for this bean violated.
Message = compression must match "on|off|force
org.jvnet.hk2.config.ValidationException: Constraints for this bean
violated. Message = compression must match "on|off|force"
"

This is what Jan had responded earlier :

Compression=
>> [...] or a numerical integer value (which is equivalent to
>> "on", but specifies the minimum amount of data before the output is
>> compressed).

So here is my understanding , when you set "compression=x" (where x is integer), this will bipass
"compressionMinSize " and set min size to "x" as well as compression=on.

You may also checkout the same at Shing-wai's blog at :
http://blogs.sun.com/swchan/entry/compression_and_compressionminsize_in_glassfish

As per Justin, it is not supported in current code :
"
> What are you expecting compression="integer" to do. As I recall, the
> code only ever really accepted on/off/force and anything outside of
> that was likely considered to be "off." So I think the only real
> change here is the validation we added to that bean to constrain that
> value.
>

Thanks,
Sudipa



 Comments   
Comment by jluehe [ 12/Feb/10 ]

...

Comment by Justin Lee [ 17/Feb/10 ]

updated validation to @Pattern(regexp = "on|off|force|
d+"). fixed in grizzly
commit 4223

Comment by sb110099 [ 26/Feb/10 ]

Changing target milestone as 3.0.1 .
This fix is not in 3.0.1. In case of a grizzly integration, I can verify the fix
in 3.0.1 .

Comment by sherryshen [ 26/Feb/10 ]

Which glassfish promoted build can we verify the fix? Thanks!

Comment by sb110099 [ 26/Apr/10 ]

Verified fix with last grizzly integration in b15 of V3.0.1.

Comment by sb110099 [ 30/Apr/10 ]


Verified this issue as "fixed" with latest grizzly integration into b15 of GF V3.0.1





[GLASSFISH-11534] undeploying .ear with embedded .rar does not fail when resources of .rar exist Created: 09/Feb/10  Updated: 15/Feb/10  Resolved: 15/Feb/10

Status: Resolved
Project: glassfish
Component/s: jca
Affects Version/s: v3.0.1
Fix Version/s: v3.0.1

Type: Bug Priority: Major
Reporter: Jagadish Assignee: Jagadish
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 11,534
Tags: v3_0_1_approved

 Description   

refer issue 11533 for complete details.
This is a placeholder issue for v3.0.1



 Comments   
Comment by Jagadish [ 09/Feb/10 ]

setting correct target

Comment by kumara [ 09/Feb/10 ]

Approving for inclusion in v3.0.1

Comment by kumara [ 09/Feb/10 ]

Approving for inclusion in v3.0.1

Comment by Jagadish [ 15/Feb/10 ]

FIX INFORMATION :

svn log -v -r 35642

https://glassfish-svn.dev.java.net/servlets/ReadMsg?list=commits&msgNo=18175

Fix will be available in GF v3.0.1 build 05.
http://download.java.net/glassfish/v3.0.1/promoted/





[GLASSFISH-11532] Update Glassfish CACERTS please! Created: 08/Feb/10  Updated: 16/Feb/10  Resolved: 16/Feb/10

Status: Resolved
Project: glassfish
Component/s: security
Affects Version/s: V3
Fix Version/s: v3.0.1

Type: Bug Priority: Major
Reporter: thorsten_l Assignee: kumarjayanti
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 11,532
Tags: v3_0_1_approved

 Description   

could you please update/synchronize the cacerts.jks file in the Glassfish
distribution with the current jdk1.6.

At this time one certificate is invalid and i am really missing the
'deutschetelekomrootca2' certificate which is already present in jdk1.6 since
update 11.

I know how to import the cert into the keystore but it would be nicer if i
does'nt have to do this.

Kind regards

Thorsten



 Comments   
Comment by kumara [ 09/Feb/10 ]

Security team -> Please evaluate and reassign as needed.

Comment by kumara [ 16/Feb/10 ]

Approving for v3.0.1

Comment by nasradu8 [ 16/Feb/10 ]

Committed revision 35672.





[GLASSFISH-11530] JCA - cleanup call for ManagedConnection after connection.close() Created: 07/Feb/10  Updated: 03/Jun/10  Resolved: 03/Jun/10

Status: Resolved
Project: glassfish
Component/s: jca
Affects Version/s: v3.0.1
Fix Version/s: v3.0.1

Type: Bug Priority: Major
Reporter: Shalini Assignee: Shalini
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Linux


Issuezilla Id: 11,530
Tags: v3_0_1_approved

 Description   

https://glassfish.dev.java.net/issues/show_bug.cgi?id=3682 should be fixed for
V3.0.1. Creating a new issue to track this.



 Comments   
Comment by kumara [ 09/Feb/10 ]

Approved for v3.0.1.

Comment by Shalini [ 01/Mar/10 ]

Fixed the issue in V3.0.1 branch.

Sending
connectors/connectors-runtime/src/main/java/com/sun/enterprise/resource/pool/AssocWithThreadResourcePool.java
Sending
connectors/connectors-runtime/src/main/java/com/sun/enterprise/resource/pool/ConnectionPool.java
Sending
connectors/connectors-runtime/src/main/java/com/sun/enterprise/resource/pool/PoolManagerImpl.java
Sending
connectors/connectors-runtime/src/main/resources/com/sun/logging/enterprise/resource/resourceadapter/LogStrings.properties
Sending
jdbc/jdbc-ra/jdbc-core/src/main/java/com/sun/gjc/spi/ManagedConnection.java
Transmitting file data .....
Committed revision 35800.

Comment by cjruffy [ 03/Jun/10 ]

Has this issue been fixed for v2.1 (9.1.1) (build b60e-fcs)? As i have the same
problem and will have to revert back to Open MQ

The comments relate to b57 being fixed

Fix will be available in b57

------- Additional comments from jr158900 Fri Oct 17 11:02:11 +0000 2008 -------

Fixed

------- Additional comments from sm157516 Mon Jan 18 08:26:27 +0000 2010 -------

Comment by Shalini [ 03/Jun/10 ]

Issue 3682 which was originally opened for fixing in the 9.1.1 mentions that the
issue is fixed in b57.

Closing this issue.





[GLASSFISH-11526] Monitor levels unl10ned Created: 05/Feb/10  Updated: 19/Apr/10  Resolved: 19/Apr/10

Status: Resolved
Project: glassfish
Component/s: l10n
Affects Version/s: v3.0.1
Fix Version/s: v3.0.1

Type: Bug Priority: Major
Reporter: simonfojtu Assignee: ogino
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: PNG File gfv3u1b02_de_09.png    
Issuezilla Id: 11,526
Tags: v3_0_1_approved

 Description   

How to reproduce:
Configuration -> Monitor
See there are unl10ned levels (Though in the text above it is localized).

This bug is derived from GLASSFISH-11250, which was marked as FIXED from i18n point of
view, but the strings were not actualy localized.

OS: Suse10; locale: de; gfv3 u1 b02



 Comments   
Comment by simonfojtu [ 05/Feb/10 ]

Created an attachment (id=4209)
unl10ned levels

Comment by simonfojtu [ 05/Feb/10 ]

Actually, the strings (HIGH, LOW, OFF) were localized for: de, es, fr and pt
but still not for: zh, ko and ja

Comment by gmurr [ 05/Feb/10 ]

Could you please fix it for zh, ko and ja and double check for EMEA locales

Comment by kumara [ 09/Feb/10 ]

Approving for inclusion in v3.0.1

Comment by kumara [ 09/Feb/10 ]

Approving for inclusion in v3.0.1

Comment by pierrot [ 10/Feb/10 ]

We doubled checked the EMEA languages, and it is well translated there. Still it
is displayed in English in the software, so we believe there is still some bug
from the i18n point of view.

Comment by ogino [ 19/Apr/10 ]

Closing as duplicate of 11250, as submitter mentioned. The fix was in trunk,
however not in 3.0.1 branch. Will ask backporting changes and that will be
tracked in 11250.

      • This issue has been marked as a duplicate of 11250 ***




[GLASSFISH-11522] in-flight transactions recovery has problems Created: 04/Feb/10  Updated: 05/Mar/10  Resolved: 05/Mar/10

Status: Resolved
Project: glassfish
Component/s: jts
Affects Version/s: V3
Fix Version/s: v3.0.1

Type: Bug Priority: Major
Reporter: Dies Koper Assignee: marina vatkina
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Text File server.log    
Issuezilla Id: 11,522
Tags: v3_0_1_approved

 Description   

In-flight transactions recovery fails (vs. server crash that should work
correctly accordingly to Marina, I have not tried).

On Oracle, using the test application and instructions from issue #11409 to
create an in-doubt transaction, followed by 'asadmin recover-transactions
server', the following error messages are seen in server.log. The database
remains in 'in-doubt' state.

[#|2010-02-02T12:53:22.678+1100|INFO|glassfishv3.0|javax.enterprise.resource.resourceadapter.com.sun.enterprise.connectors.inbound|_ThreadID=34;_ThreadName=Thread-1;|Recovery
of Inbound Transactions started.|#]

[#|2010-02-02T12:53:22.694+1100|WARNING|glassfishv3.0|javax.enterprise.resource.resourceadapter.com.sun.enterprise.resource.recovery|_ThreadID=34;_ThreadName=Thread-1;|RAR5005:Error
in accessing XA resource with JNDI name [__TimerPool] for recovery|#]

[#|2010-02-02T12:53:22.740+1100|WARNING|glassfishv3.0|javax.enterprise.resource.resourceadapter.com.sun.enterprise.resource.recovery|_ThreadID=34;_ThreadName=Thread-1;|RAR5005:Error
in accessing XA resource with JNDI name [ora1] for recovery|#]

[#|2010-02-02T12:53:22.944+1100|WARNING|glassfishv3.0|javax.enterprise.resource.resourceadapter.com.sun.enterprise.resource.recovery|_ThreadID=34;_ThreadName=Thread-1;|RAR5005:Error
in accessing XA resource with JNDI name [ora2] for recovery|#]

On Derby, Marina reported seeing another error message:

JTS5029: Exception [org.omg.CORBA.INTERNAL: vmcid: 0x0 minor code: 0
completed: Maybe] on [OTSResource rollback] operation during resync.

I saw a different error message on Derby too (might have been JTS5029), but
unfortunately did not back up the log file.



 Comments   
Comment by marina vatkina [ 05/Feb/10 ]

Dies,

Can you set log level to FINE for 'transaction' and 'resourceadapter'?

With Derby the failure seems like a Derby issue because with the correct logging
added for IT 11409, I get this exception in the log:

#|2010-02-05T14:02:04.617-0800|WARNING|glassfishv3.0|javax.enterprise.system.core.transaction.com.sun.jts.jtsxa|_ThreadID=28;_ThreadName=http-thread-pool-4848(2);|JTS5067:
Unexpected error occurred in commit
org.apache.derby.client.am.XaException: XAER_RMERR : Error executing a
XAResource.commit(), server returned XAER_RMERR.
at org.apache.derby.client.net.NetXAResource.throwXAException(Unknown
Source)
at org.apache.derby.client.net.NetXAResource.commit(Unknown Source)
at com.sun.gjc.spi.XAResourceImpl.commit(XAResourceImpl.java:80)
at
com.sun.jts.jtsxa.OTSResourceImpl.commit_one_phase(OTSResourceImpl.java:170)
at
com.sun.jts.CosTransactions.RecoveryManager.recoverIncompleteTx(RecoveryManager.java:1544)
at
com.sun.enterprise.transaction.jts.ResourceRecoveryManagerImpl.recoverIncompleteTx(ResourceRecoveryManagerImpl.java:130)
at
org.glassfish.jts.admin.cli.RecoverTransactions.execute(RecoverTransactions.java:123)

I'll fix the message not to always say it was a rollback.

Comment by Dies Koper [ 10/Feb/10 ]

Created an attachment (id=4216)
server log (FINE level) showing ClassNotFoundException: OracleXAResource

Comment by marina vatkina [ 11/Feb/10 ]

Jagadish, please take a look - there are several exceptions happening in the
connector area

Comment by Jagadish [ 16/Feb/10 ]

Of the three exceptions seen in the attached log,
-------------------------------------------------------------------------------
"[#|2010-02-11T16:50:20.943+1100|FINE|glassfishv3.0|javax.enterprise.resource.resourceadapter.com.sun.enterprise.resource.recovery|_ThreadID=31;_ThreadName=Thread-1;ClassName=com.sun.enterprise.resource.recovery.JdbcRecoveryResourceHandler;MethodName=loadXAResourcesAndItsConnections;|RAR5042:Error
in accessing XA resource for recovery
java.lang.NullPointerException
"
-------------------------------------------------------------------------------
first one is due to __TimerPool not providing credentials in the connection pool
configuration.

Other two exceptions are due to not able to access the class
"com.sun.enterprise.transaction.jts.OracleXAResource" provided by transactions
module.
-------------------------------------------------------------------------------
[#|2010-02-11T16:50:21.130+1100|FINE|glassfishv3.0|javax.enterprise.resource.resourceadapter.com.sun.enterprise.resource.recovery|_ThreadID=31;_ThreadName=Thread-1;ClassName=com.sun.enterprise.resource.recovery.JdbcRecoveryResourceHandler;MethodName=loadXAResourcesAndItsConnections;|RAR5042:Error
in accessing XA resource for recovery
java.lang.ClassNotFoundException:
com.sun.enterprise.transaction.jts.OracleXAResource
-------------------------------------------------------------------------------

There are two parts to the fix.
1) Use connector classloader so as to get access to the driver class or any of
the wrapper class (eg: com.sun.enterprise.transaction.jts.OracleXAResource).
2) v3/transaction/jts need to export the package that
"com.sun.enterprise.transaction.jts" in its osgi.bundle

Raised an issue 11569 for (1).

Transferring to Marina for fixing (2).

Comment by marina vatkina [ 17/Feb/10 ]

The fix for package export is checked in into trunk:

Sending
connectors/connectors-runtime/src/main/java/com/sun/enterprise/resource/recovery/JdbcRecoveryResourceHandler.java
Sending transaction/jts/osgi.bundle
Sending
transaction/jts/src/main/java/com/sun/enterprise/transaction/jts/JavaEETransactionManagerJTSDelegate.java
Deleting
transaction/jts/src/main/java/com/sun/enterprise/transaction/jts/OracleXAResource.java
Deleting
transaction/jts/src/main/java/com/sun/enterprise/transaction/jts/SybaseXAResource.java
Adding
transaction/jts/src/main/java/com/sun/enterprise/transaction/jts/recovery
Adding
transaction/jts/src/main/java/com/sun/enterprise/transaction/jts/recovery/OracleXAResource.java
Adding
transaction/jts/src/main/java/com/sun/enterprise/transaction/jts/recovery/SybaseXAResource.java
Transmitting file data .....
Committed revision 35681.

Dies, please verify if it works for you.

Comment by Dies Koper [ 23/Feb/10 ]

It still doesn't work.

First I see the NPE again (I've reopened issue #11569 for that), followed by:

[#|2010-02-24T11:52:11.597+1100|WARNING|glassfishv3.0|javax.enterprise.system.core.transaction.com.sun.jts.CosTransactions|_ThreadID=25;_ThreadName=Thread-1;|JTS5028:
XAException occurred during recovery of XAResource objects; XA Error Code : [0]|#]

[#|2010-02-24T11:52:11.597+1100|WARNING|glassfishv3.0|javax.enterprise.system.core.transaction.com.sun.jts.CosTransactions|_ThreadID=25;_ThreadName=Thread-1;|
javax.transaction.xa.XAException: SQL Exception thrown from oracle driver:
java.sql.SQLSyntaxErrorException: ORA-00942: table or view does not exist

at
com.sun.enterprise.transaction.jts.recovery.OracleXAResource.recoverList(OracleXAResource.java:116)
at
com.sun.enterprise.transaction.jts.recovery.OracleXAResource.recover(OracleXAResource.java:85)
at
com.sun.jts.CosTransactions.RecoveryManager.getInDoubtXids(RecoveryManager.java:883)
at
com.sun.jts.CosTransactions.RecoveryManager.recoverIncompleteTx(RecoveryManager.java:1464)
at
com.sun.enterprise.transaction.jts.ResourceRecoveryManagerImpl.recoverIncompleteTx(ResourceRecoveryManagerImpl.java:130)

When I run the query (select pending.local_tran_id from SYS.PENDING_TRANS$
pending, SYS.DBA_2PC_NEIGHBORS) in SQLPlus, it works fine.

Comment by Dies Koper [ 28/Feb/10 ]

I must have missed granting privileges on one of the instances. Sorry about that.
Recovery went fine after running the following statements as SYSDBA on both
instances:

grant select on dba_pending_transactions to APP;

grant execute on SYS.DBMS_XA to APP;

grant execute on SYS.DBMS_SYSTEM to APP;

grant select on SYS.PENDING_TRANS$ to APP;

grant select on SYS.DBA_2PC_NEIGHBORS to APP;

(it was the latter that ORA-00942 was logged for)

Thanks!

I'll raise a separate issue about the message key that was logged in the process.

Comment by marina vatkina [ 04/Mar/10 ]

Reopen to fix in 3.0.1

Comment by kumara [ 05/Mar/10 ]

Approved for 3.0.1

Comment by marina vatkina [ 05/Mar/10 ]

Fixed in 3.0.1:

Sending
connectors/connectors-runtime/src/main/java/com/sun/enterprise/resource/recovery/JdbcRecoveryResourceHandler.java
Sending transaction/jts/osgi.bundle
Sending
transaction/jts/src/main/java/com/sun/enterprise/transaction/jts/JavaEETransactionManagerJTSDelegate.java
Deleting
transaction/jts/src/main/java/com/sun/enterprise/transaction/jts/OracleXAResource.java
Deleting
transaction/jts/src/main/java/com/sun/enterprise/transaction/jts/SybaseXAResource.java
Adding
transaction/jts/src/main/java/com/sun/enterprise/transaction/jts/recovery
Adding
transaction/jts/src/main/java/com/sun/enterprise/transaction/jts/recovery/OracleXAResource.java
Adding
transaction/jts/src/main/java/com/sun/enterprise/transaction/jts/recovery/SybaseXAResource.java
Transmitting file data ...
Committed revision 35886.





[GLASSFISH-11521] partial translation for license for locales Created: 04/Feb/10  Updated: 14/Apr/10  Resolved: 14/Apr/10

Status: Resolved
Project: glassfish
Component/s: l10n
Affects Version/s: v3.0.1
Fix Version/s: v3.0.1

Type: Bug Priority: Major
Reporter: leonfan Assignee: gmurr
Resolution: Incomplete Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Macintosh


Attachments: Text File license.tiff    
Issuezilla Id: 11,521
Tags: v3_0_1_approved

 Description   

We should keep whole license for installer in english. But I found there have
one term 'definition' has been translation for all locales. It must caused by
leverage. We should back it to english as whole license show in english.



 Comments   
Comment by leonfan [ 04/Feb/10 ]

Created an attachment (id=4204)
license

Comment by gmurr [ 05/Feb/10 ]

Will fix it in next l10n hadn-off

Comment by kumara [ 09/Feb/10 ]

Approving for inclusion in v3.0.1

Comment by kumara [ 09/Feb/10 ]

Approving for inclusion in v3.0.1

Comment by gmurr [ 14/Apr/10 ]

license text will be removed from installer





[GLASSFISH-11513] Form based login does not enforce transport constraints on the login page. Created: 03/Feb/10  Updated: 09/Feb/10  Resolved: 09/Feb/10

Status: Resolved
Project: glassfish
Component/s: security
Affects Version/s: V3
Fix Version/s: v3.0.1

Type: Bug Priority: Major
Reporter: Nithya Ramakrishnan Assignee: kumarjayanti
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 11,513
Tags: v3_0_1_approved

 Description   

When using a form-based login, when a request is made to an auth-constrained
resource that is NOT subject to a user-data-constraint, the FormAuthenticator
should be made to decide whether to forward to the login page or whether to
REDIRECT THE CURRENT REQUEST to a protected transport.

The decision should be based on the transport characteristics of the current
request AND whether the login page requires a protected transport. If the
characteristics of the current request are not sufficient to match the
requirements of the login page the current request should be redirected to
https; ultimately the request should be FORWARDED to the login page.



 Comments   
Comment by Nithya Ramakrishnan [ 04/Feb/10 ]

Fixed as suggested in the description..

Comment by kumara [ 09/Feb/10 ]

Approved for v3.0.1.





[GLASSFISH-11509] Various mistranslated strings in Admin GUI to French Created: 03/Feb/10  Updated: 05/Feb/10  Resolved: 05/Feb/10

Status: Resolved
Project: glassfish
Component/s: l10n
Affects Version/s: V3
Fix Version/s: v3.0.1

Type: Bug Priority: Major
Reporter: miga Assignee: pierrot
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Mac OS X
Platform: Macintosh


Issuezilla Id: 11,509
Tags: v3_0_1_approved

 Description   

In admin GUI:
Entreprise Server -> right frame
Rédemarrer should be Redémarrer (note the e acute at the second position, not at the first one).

Current Tasks (Tâches courantes) -> right frame
Déployé une Application should be Déployer une application (notice er at the end, not e acute)



 Comments   
Comment by gmurr [ 03/Feb/10 ]

Pierre, could you please fix the translations.

Comment by kumara [ 04/Feb/10 ]

Approved for v3.0.1

Comment by simonfojtu [ 05/Feb/10 ]

Fixed in WorldServer, needs to be integrated.





[GLASSFISH-11508] Number of updates not translated in human language Created: 03/Feb/10  Updated: 07/Oct/10  Resolved: 07/Oct/10

Status: Closed
Project: glassfish
Component/s: l10n
Affects Version/s: 3.1
Fix Version/s: v3.0.1

Type: Bug Priority: Major
Reporter: miga Assignee: gmurr
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Mac OS X
Platform: Macintosh


Attachments: PNG File Image 2.png    
Issuezilla Id: 11,508

 Description   

At the top of the Console Admin, under Sun GlassFish Entreprise Server v3, there is an update icon with
normally the number of available update.
Here's what I get:

{sessionScope.numUpdatesAvailable}

mise(s) à jour est/sont disponible(s).

litterally.

It would be nice to get the sessionScope... translated into human language.



 Comments   
Comment by miga [ 03/Feb/10 ]

Created an attachment (id=4200)
The part in question

Comment by Anissa Lam [ 30/Apr/10 ]

This is an i18n issue. In the Strings.properties file, the line says:

msg.updatesAvailable=There are #

{sessionScope.numUpdatesAvailable} update(s)
available.

During the translation, the # was omitted.
The translation needs to make sure that #{sessionScope.numUpdatesAvailable}

be
all in one word, without missing any character.

Transfer to i18n.

Since this is reported in v3, I am marking the target Milestone to 3.0.1.
This is critical and needs to be fixed in 3.0.1 release.
Georges, please make sure this is fixed in 3.0.1. thanks.

Comment by gmurr [ 30/Apr/10 ]

Pierre, could you please check the translation.

Comment by simonfojtu [ 18/Jun/10 ]

All occurances of "sessionScope.numUpdatesAvailable" are correct in TM.

Comment by gmurr [ 07/Oct/10 ]

fixed

Comment by gmurr [ 07/Oct/10 ]

fixed





[GLASSFISH-11507] Creation of LDAP Realm using admin GUI fails Created: 02/Feb/10  Updated: 09/Feb/10  Resolved: 09/Feb/10

Status: Resolved
Project: glassfish
Component/s: admin_gui
Affects Version/s: V3
Fix Version/s: v3.0.1

Type: Bug Priority: Major
Reporter: nasradu8 Assignee: Anissa Lam
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: File error.tiff     File first.tiff     Text File server.log    
Issuezilla Id: 11,507

 Description   

An attempt to create an LDAP Realm using the admin GUI fails. The following seems to be the cause of
this problem.

org.jvnet.hk2.config.TransactionFailure: Unexpected exception during isValid call
at org.jvnet.hk2.config.ConfigSupport._apply(ConfigSupport.java:194)
at org.jvnet.hk2.config.ConfigSupport.apply(ConfigSupport.java:130)
at org.glassfish.admin.amx.impl.config.AMXConfigImpl.createChildren(AMXConfigImpl.java:548)
at org.glassfish.admin.amx.impl.config.AMXConfigImpl.createChild(AMXConfigImpl.java:650)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.glassfish.admin.amx.impl.mbean.AMXImplBase.invoke(AMXImplBase.java:1039)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:836
)
at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:761)
at
javax.management.MBeanServerInvocationHandler.invoke(MBeanServerInvocationHandler.java:288)
at org.glassfish.admin.amx.util.jmx.MBeanProxyHandler.invoke(MBeanProxyHandler.java:454)
at org.glassfish.admin.amx.core.proxy.AMXProxyHandler._invoke(AMXProxyHandler.java:823)
at org.glassfish.admin.amx.core.proxy.AMXProxyHandler.invoke(AMXProxyHandler.java:527)
at $Proxy126.createChild(Unknown Source)
at org.glassfish.admingui.common.handlers.SecurityHandler.saveRealm(SecurityHandler.java:253)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.jsftemplating.layout.descriptors.handler.Handler.invoke(Handler.java:442)
at
com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:
420)
at
com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:
394)
at
com.sun.jsftemplating.layout.event.CommandActionListener.invokeCommandHandlers(CommandAction
Listener.java:150)
at
com.sun.jsftemplating.layout.event.CommandActionListener.processAction(CommandActionListener.jav
a:98)
at javax.faces.event.ActionEvent.processListener(ActionEvent.java:88)
at javax.faces.component.UIComponentBase.broadcast(UIComponentBase.java:772)
at javax.faces.component.UICommand.broadcast(UICommand.java:300)
at com.sun.webui.jsf.component.WebuiCommand.broadcast(WebuiCommand.java:160)
at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:775)
at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:1267)
at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:82)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:312)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1518)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:339)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:211)
at com.sun.webui.jsf.util.UploadFilter.doFilter(UploadFilter.java:240)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:211)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:171)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:643)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:591)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:96)
at
com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.ja
va:87)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:158)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:328)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:229)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:239)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:811)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:708)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1017)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:171)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:135)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:102)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:88)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:76)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:53)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:57)
at com.sun.grizzly.ContextTask.run(ContextTask.java:69)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:526)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:507)
at java.lang.Thread.run(Thread.java:637)
Caused by: javax.validation.ValidationException: Unexpected exception during isValid call
at org.hibernate.validator.engine.ConstraintTree.validateSingleConstraint(ConstraintTree.java:144)
at org.hibernate.validator.engine.ConstraintTree.validateConstraints(ConstraintTree.java:118)
at org.hibernate.validator.metadata.MetaConstraint.validateConstraint(MetaConstraint.java:121)
at org.hibernate.validator.engine.ValidatorImpl.validateConstraint(ValidatorImpl.java:334)
at
org.hibernate.validator.engine.ValidatorImpl.validateConstraintsForRedefinedDefaultGroup(ValidatorImp
l.java:278)
at
org.hibernate.validator.engine.ValidatorImpl.validateConstraintsForCurrentGroup(ValidatorImpl.java:26
0)
at org.hibernate.validator.engine.ValidatorImpl.validateInContext(ValidatorImpl.java:213)
at org.hibernate.validator.engine.ValidatorImpl.validate(ValidatorImpl.java:119)
at org.jvnet.hk2.config.WriteableView.canCommit(WriteableView.java:286)
at org.jvnet.hk2.config.Transaction.commit(Transaction.java:96)
at org.jvnet.hk2.config.ConfigSupport._apply(ConfigSupport.java:173)
... 65 more
Caused by: java.lang.NullPointerException
at
com.sun.enterprise.config.serverbeans.customvalidators.FileRealmPropertyCheckValidator.isValid(FileRe
almPropertyCheckValidator.java:61)
at
com.sun.enterprise.config.serverbeans.customvalidators.FileRealmPropertyCheckValidator.isValid(FileRe
almPropertyCheckValidator.java:49)
at org.hibernate.validator.engine.ConstraintTree.validateSingleConstraint(ConstraintTree.java:141)
... 75 more

I have attached the server log and snapshots of the admin gui page.



 Comments   
Comment by nasradu8 [ 02/Feb/10 ]

Created an attachment (id=4197)
server log

Comment by nasradu8 [ 02/Feb/10 ]

Created an attachment (id=4198)
Entered properties for the realm creation

Comment by nasradu8 [ 02/Feb/10 ]

Created an attachment (id=4199)
Error page snapshot

Comment by nasradu8 [ 02/Feb/10 ]

Forgot to mention. The realm creation works fine from command line.

Comment by Anissa Lam [ 09/Feb/10 ]

This is duplicate of #11382. Marking as such and will be fixed in u1.

      • This issue has been marked as a duplicate of 11382 ***




[GLASSFISH-11504] Glassfishv3 j_security_check causes No active contexts errors Created: 01/Feb/10  Updated: 13/Jul/10  Resolved: 13/Jul/10

Status: Resolved
Project: glassfish
Component/s: web_container
Affects Version/s: V3
Fix Version/s: v3.0.1

Type: Bug Priority: Major
Reporter: cosmic Assignee: jluehe
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 11,504

 Description   

It seems that Glassfishv3 does not currently work with form based authentication?

When it is lazy authentication by stipulating a security-constraint on a url-pattern in web.xml which should redirect to the form-login-page, I get the error.

Or whether I access the form-login-page directly and submit an incorrect username/password combination, I also get the error (a valid user in this case will log in correctly).

Is there something other than the above to get this to work? It seems it is a Weld issue?
I have an empty beans.xml file in the WEB-INF directory of my WAR.

An example exception I get from the latest Glassfishv3.1 nightly is:

javax.enterprise.context.ContextNotActiveException: No active contexts for scope type javax.enterprise.context.RequestScoped
at org.jboss.weld.BeanManagerImpl.getContext(BeanManagerImpl.java:928)
at org.jboss.weld.bean.proxy.ClientProxyMethodHandler.getProxiedInstance(ClientProxyMethodHandler.java:140)
at org.jboss.weld.bean.proxy.ClientProxyMethodHandler.invoke(ClientProxyMethodHandler.java:101)
at org.jboss.weld.servlet.HttpSessionManager_$$javassist_14.setSession(HttpSessionManager$$_javassist_14.java)
at org.jboss.weld.jsf.WeldPhaseListener.initiateSessionAndConversation(WeldPhaseListener.java:169)
at org.jboss.weld.jsf.WeldPhaseListener.beforeRestoreView(WeldPhaseListener.java:118)
at org.jboss.weld.jsf.WeldPhaseListener.beforePhase(WeldPhaseListener.java:87)
at com.sun.faces.lifecycle.Phase.handleBeforePhase(Phase.java:228)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:99)
at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:110)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:312)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1518)
at org.apache.catalina.core.ApplicationDispatcher.doInvoke(ApplicationDispatcher.java:784)
at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:646)
at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:479)
at org.apache.catalina.core.ApplicationDispatcher.doDispatch(ApplicationDispatcher.java:450)
at org.apache.catalina.core.ApplicationDispatcher.dispatch(ApplicationDispatcher.java:346)
at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:296)
at org.apache.catalina.authenticator.FormAuthenticator.forwardToLoginPage(FormAuthenticator.java:458)
at org.apache.catalina.authenticator.FormAuthenticator.authenticate(FormAuthenticator.java:249)
at com.sun.web.security.RealmAdapter.invokeAuthenticateDelegate(RealmAdapter.java:1184)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:542)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:604)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:98)
...

NOTE: this came about from the forum post: http://forums.java.net/jive/thread.jspa?threadID=73860



 Comments   
Comment by jluehe [ 11/Feb/10 ]

Request boundaries in Weld are implemented using a ServletRequestListener.

Normally, the requestInitialized and requestDestroyed events are fired as part
of StandardContextValve#preInvoke and StandardContextValve#postInvoke,
respectively. However, when FormAuthenticator performs a FORWARD dispatch to the
form's login or error page, StandardContextValve will be bypassed, as is evident
from the above stacktrace, where the form's login page is JSF based (search for
FacesServlet#service). As a result, no requestInitialized event will have been
fired by the time WeldPhaseListener#initiateSessionAndConversation is called,
causing the ContextNotActiveException.

The issue can be fixed by having ApplicationDispatcher check whether
requestInitialized was already fired for a given request, and fire it (and the
corresponding requestDestroyed) in case it was not.

Comment by jluehe [ 12/Feb/10 ]
      • Issue 11544 has been marked as a duplicate of this issue. ***
Comment by jluehe [ 12/Feb/10 ]

Sending web-core/src/main/java/org/apache/catalina/Context.java
Sending
web-core/src/main/java/org/apache/catalina/authenticator/FormAuthenticator.java
Sending
web-core/src/main/java/org/apache/catalina/core/ApplicationDispatcher.java
Sending web-core/src/main/java/org/apache/catalina/core/StandardContext.java
Sending
web-core/src/main/java/org/apache/catalina/core/StandardContextValve.java
Sending
web-core/src/main/java/org/apache/catalina/core/StandardHostValve.java
Transmitting file data ......
Committed revision 35608.

Comment by jluehe [ 14/Feb/10 ]

Ported fix to v3.0.1:

Sending web-core/src/main/java/org/apache/catalina/Context.java
Sending
web-core/src/main/java/org/apache/catalina/authenticator/FormAuthenticator.java
Sending
web-core/src/main/java/org/apache/catalina/core/ApplicationDispatcher.java
Sending web-core/src/main/java/org/apache/catalina/core/StandardContext.java
Sending
web-core/src/main/java/org/apache/catalina/core/StandardContextValve.java
Sending
web-core/src/main/java/org/apache/catalina/core/StandardHostValve.java
Transmitting file data ......
Committed revision 35620.

Comment by jluehe [ 15/Feb/10 ]

Changing target milestone to v3.0.1, because the fix has been back-ported there.

Comment by jluehe [ 18/Feb/10 ]

Added unit test at
https://svn.dev.java.net/svn/glassfish-svn/trunk/v2/appserv-tests/devtests/web/weldJsfLoginPage

Comment by cosmic [ 13/Jul/10 ]

This bug appears to have resurfaced when forwarding from a ServerAuthModule:
http://forums.java.net/jive/thread.jspa?threadID=151707

Comment by cosmic [ 13/Jul/10 ]

As requested by Shing Wai Chan, I have created Issue #12642 for the different scenario.





[GLASSFISH-11502] exception when opened Edit Audit Module or Edit Message Security Configuration page Created: 01/Feb/10  Updated: 26/May/10  Resolved: 26/May/10

Status: Resolved
Project: glassfish
Component/s: admin_gui
Affects Version/s: v3.0.1
Fix Version/s: v3.0.1

Type: Bug Priority: Major
Reporter: ogino Assignee: gmurr
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Solaris
Platform: Macintosh


Issuezilla Id: 11,502
Tags: v3_0_1_approved

 Description   

Tested using sges-v3u1-b02-unix-ml.sh. Happens when browser language is set to ja, zh_CN, or
zh_TW.

Following is an output in log. Exception message suggests that 'Develops an audit trail of all
authentication and authorization decisions.' (key for this message is auditModule.EditPageTitleHelp) is
not in format: "[bundleID].[bundleKey]". However, I cannot find problems around that message
translations and relatives so far.

[#|2010-02-
01T18:57:48.048+0900|WARNING|glassfishv3.0|javax.enterprise.system.container.web.com.sun.enterp
rise.web|_ThreadID=29;_ThreadName=http-thread-pool-4848-
(1);|StandardWrapperValve[FacesServlet]: PWC1406: Servlet.service() for servlet FacesServlet threw
exception
java.lang.IllegalArgumentException: '�����証�よ���決定�監査証跡を開発���。' is not in
format: "[bundleID].[bundleKey]"!
at
com.sun.jsftemplating.el.VariableResolver$ResourceBundleDataSource.getValue(VariableResolver.java:1
219)
at com.sun.jsftemplating.el.VariableResolver.resolveVariables(VariableResolver.java:252)
at com.sun.jsftemplating.el.VariableResolver.resolveVariables(VariableResolver.java:488)
at com.sun.jsftemplating.component.ComponentUtil.setOption(ComponentUtil.java:444)
at
com.sun.jsftemplating.component.factory.ComponentFactoryBase.setOption(ComponentFactoryBase.jav
a:134)
at
com.sun.jsftemplating.component.factory.ComponentFactoryBase.setOptions(ComponentFactoryBase.ja
va:106)
at com.sun.jsftemplating.component.factory.sun.TitleFactory.create(TitleFactory.java:61)
at
com.sun.jsftemplating.component.ComponentUtil.createChildComponent(ComponentUtil.java:416)
at
com.sun.jsftemplating.layout.descriptors.LayoutComponent.getChild(LayoutComponent.java:291)
at
com.sun.jsftemplating.layout.LayoutViewHandler.buildUIComponentTree(LayoutViewHandler.java:556)
at
com.sun.jsftemplating.layout.LayoutViewHandler.buildUIComponentTree(LayoutViewHandler.java:585)
at
com.sun.jsftemplating.layout.LayoutViewHandler.buildUIComponentTree(LayoutViewHandler.java:551)
at
com.sun.jsftemplating.layout.LayoutViewHandler.buildUIComponentTree(LayoutViewHandler.java:507)
at
com.sun.jsftemplating.layout.LayoutViewHandler.buildUIComponentTree(LayoutViewHandler.java:507)
at com.sun.jsftemplating.layout.LayoutViewHandler.createView(LayoutViewHandler.java:255)
at com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:253)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:110)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:312)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1523)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:343)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:215)
at com.sun.webui.jsf.util.UploadFilter.doFilter(UploadFilter.java:240)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:215)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:277)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:188)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:641)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:97)
at
com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.ja
va:85)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:185)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:332)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:233)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:239)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:791)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:693)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:954)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:170)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:135)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:102)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:88)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:76)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:53)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:57)
at com.sun.grizzly.ContextTask.run(ContextTask.java:69)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:330)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:309)
at java.lang.Thread.run(Thread.java:619)

#]


 Comments   
Comment by gmurr [ 01/Feb/10 ]

This seems to be a regression in v3.0.1.
The messages that are causing the problem are:
auditModule.EditPageTitleHelp and msgSecurity.EditMsgSecurityInfo in:
org/glassfish/common/admingui/Strings.properties
The problem does not happen in v3-b74
The translations are still the same as in v3-b74. However, after I reverted
these 2 messages back to EN, the exception is gone.
Anissa, could you please evaluate this issue

Comment by ogino [ 04/Feb/10 ]

Exception of same sort also thrown when tried to create new lifecyle module. Message mentioned in
server.log were following.

org/glassfish/common/admingui/Strings.properties:lifecycleModules.titleHelp
org/glassfish/common/admingui/Strings.properties:lifecycleModule.newPageTitleHelp

Comment by Anissa Lam [ 04/Feb/10 ]

Georges, I don't understand what you mean here:
"The problem does not happen in v3-b74
The translations are still the same as in v3-b74. However, after I reverted
these 2 messages back to EN, the exception is gone. "

do you mean you still runs in other locale, all messages is localized except
these 2 remains in english ?

I have never heard that 3.0.1 branch is open for checkin, so 'nothing' is
changed in that branch as far as GUI is concerned.

can you attach the properties file here that causes the issue ?

thanks

Comment by kumara [ 04/Feb/10 ]

Approved for v3.0.1

Comment by leonfan [ 04/Feb/10 ]

New 'JACC Provider' also happen same issue.
Click 'SOAP' under 'message security happen same issue.
New Lifecycle module happen same issue

Comment by leonfan [ 04/Feb/10 ]
      • Issue 11519 has been marked as a duplicate of this issue. ***
Comment by Anissa Lam [ 04/Feb/10 ]

There is something fundamentally wrong. All these are basic operations that
have gone through all the test and worked fine before.
Please attach the properties file here so we can reproduce this.
Request Jason to take a look.

Comment by Anissa Lam [ 31/Mar/10 ]

We do not have enough info to work on this bug.
I am assigning to Georges, so he can try to reproduce this with the latest 3.0.1
build. Please use the latest build nightly from:
http://download.java.net/glassfish/3.0.1/nightly/

If this is reproducible and you believe this is admingui issue, please attach
the Strings.properties file that shows this issue and step-by-step instruction
on how to reproduce this.

thanks.

Comment by gmurr [ 01/Apr/10 ]

We do not have recent ML builds for v3.0.1. Could be an issue with the l10n jar
file in previous v3.0.1 ml build because there is no issue with ML build
3.0-b74. I will try it once we have new 3.0.1 ML builds with new translations.

Comment by ogino [ 19/Apr/10 ]

Seems like in such .jsf files with following error ('$resource' twice..) are
causing the exception.
helpText="$resource{$resource{i18nc.auditModule.EditPageTitleHelp}}"

bash-3.00$ find . -exec grep '$resource{$resource' {} +
./applications/lifecycleEdit.jsf:<sun:title id="propertyContentPage"
title="$resource

{i18nc.lifecycleModule.editPageTitle}"
helpText="$resource{$resource{i18nc.lifecycleModule.editPageTitleHelp}}">
./applications/lifecycleNew.jsf:<sun:title id="propertyContentPage"
title="$resource{i18nc.lifecycleModule.newPageTitle}"
helpText="$resource{$resource{i18nc.lifecycleModule.newPageTitleHelp}}">
./security/auditModules/auditModuleEdit.jsf: <sun:title
id="propertyContentPage" title="$resource{i18nc.auditModule.EditPageTitle}"
helpText="$resource{$resource{i18nc.auditModule.EditPageTitleHelp}}">
./security/jacc/jaccProviderNew.jsf: <sun:title id="propertyContentPage"
title="$resource{i18nc.jacc.NewPageTitle}"
helpText="$resource{$resource{i18nc.jacc.NewPageHelp}}">
./security/msgSecurity/providerEdit.jsf: <sun:title
id="propertyContentPage" title="$resource{i18nc.msgProvider.EditPageTitle}"
helpText="$resource{$resource{i18nc.msgProvider.EditPageTitleHelp}}">
./security/msgSecurity/providerNew.jsf: <sun:title
id="propertyContentPage" title="$resource{i18nc.msgSecProvider.NewPageTitle}"
helpText="$resource{$resource{i18nc.msgSecProvider.NewPageTitleHelp}}">
./security/msgSecurity/msgSecurityEdit.jsf: <sun:title
id="propertyContentPage" title="$resource{i18nc.msgSecurity.EditMsgSecurity}"
helpText="$resource{$resource{i18nc.msgSecurity.EditMsgSecurityInfo}}">


Suggested fix;

diff -rc orig/applications/lifecycleEdit.jsf fix/applications/lifecycleEdit.jsf
*** orig/applications/lifecycleEdit.jsf Mon Apr 19 19:13:02 2010
— fix/applications/lifecycleEdit.jsf Mon Apr 19 19:30:33 2010
***************
*** 60,66 ****
#include "/common/shared/alertMsg.inc"

<!-- Page Title -->
! <sun:title id="propertyContentPage"
title="$resource{i18nc.lifecycleModule.editPageTitle}

"
helpText="$resource{$resource{i18nc.lifecycleModule.editPageTitleHelp}}">
#include "/common/applications/lifecycleButtons.inc"
</sun:title>
"<br><br>
— 60,66 ----
#include "/common/shared/alertMsg.inc"

<!-- Page Title -->
! <sun:title id="propertyContentPage"
title="$resource

{i18nc.lifecycleModule.editPageTitle}

"
helpText="$resource

{i18nc.lifecycleModule.editPageTitleHelp}

">
#include "/common/applications/lifecycleButtons.inc"
</sun:title>
"<br><br>
diff -rc orig/applications/lifecycleNew.jsf fix/applications/lifecycleNew.jsf

      • orig/applications/lifecycleNew.jsf Mon Apr 19 19:13:02 2010
      • fix/applications/lifecycleNew.jsf Mon Apr 19 19:13:26 2010
        ***************
      • 59,65 ****
        #include "/common/shared/alertMsg.inc"

<!-- Page Title -->
! <sun:title id="propertyContentPage"
title="$resource

{i18nc.lifecycleModule.newPageTitle}"
helpText="$resource{$resource{i18nc.lifecycleModule.newPageTitleHelp}}">
#include "/common/applications/lifecycleButtons.inc"
</sun:title>
"<br><br>
— 59,65 ----
#include "/common/shared/alertMsg.inc"

<!-- Page Title -->
! <sun:title id="propertyContentPage"
title="$resource{i18nc.lifecycleModule.newPageTitle}

"
helpText="$resource

{i18nc.lifecycleModule.newPageTitleHelp}

">
#include "/common/applications/lifecycleButtons.inc"
</sun:title>
"<br><br>
diff -rc orig/security/auditModules/auditModuleEdit.jsf
fix/security/auditModules/auditModuleEdit.jsf

      • orig/security/auditModules/auditModuleEdit.jsf Mon Apr 19 19:12:36 2010
      • fix/security/auditModules/auditModuleEdit.jsf Mon Apr 19 19:13:26 2010
        ***************
      • 68,74 ****
        #include "/common/shared/alertMsg.inc"

<!-- Page Title -->
! <sun:title id="propertyContentPage"
title="$resource

{i18nc.auditModule.EditPageTitle}"
helpText="$resource{$resource{i18nc.auditModule.EditPageTitleHelp}}">
#include "/common/shared/editPageButtons.inc"
</sun:title>
"<br><br>
— 68,74 ----
#include "/common/shared/alertMsg.inc"

<!-- Page Title -->
! <sun:title id="propertyContentPage"
title="$resource{i18nc.auditModule.EditPageTitle}

"
helpText="$resource

{i18nc.auditModule.EditPageTitleHelp}

">
#include "/common/shared/editPageButtons.inc"
</sun:title>
"<br><br>
diff -rc orig/security/jacc/jaccProviderNew.jsf
fix/security/jacc/jaccProviderNew.jsf

      • orig/security/jacc/jaccProviderNew.jsf Mon Apr 19 19:12:36 2010
      • fix/security/jacc/jaccProviderNew.jsf Mon Apr 19 19:31:08 2010
        ***************
      • 60,66 ****
        #include "/common/shared/alertMsg.inc"

<!-- Page Title -->
! <sun:title id="propertyContentPage"
title="$resource

{i18nc.jacc.NewPageTitle}"
helpText="$resource{$resource{i18nc.jacc.NewPageHelp}}">
#include "/common/shared/editPageButtons.inc"
</sun:title>
"<br><br>
— 60,66 ----
#include "/common/shared/alertMsg.inc"

<!-- Page Title -->
! <sun:title id="propertyContentPage"
title="$resource{i18nc.jacc.NewPageTitle}

"
helpText="$resource

{i18nc.jacc.NewPageHelp}

">
#include "/common/shared/editPageButtons.inc"
</sun:title>
"<br><br>
diff -rc orig/security/msgSecurity/msgSecurityEdit.jsf
fix/security/msgSecurity/msgSecurityEdit.jsf

      • orig/security/msgSecurity/msgSecurityEdit.jsf Mon Apr 19 19:12:36 2010
      • fix/security/msgSecurity/msgSecurityEdit.jsf Mon Apr 19 19:13:26 2010
        ***************
      • 71,77 ****
        #include "/common/shared/alertMsg.inc"

<!-- Page Title -->
! <sun:title id="propertyContentPage"
title="$resource

{i18nc.msgSecurity.EditMsgSecurity}"
helpText="$resource{$resource{i18nc.msgSecurity.EditMsgSecurityInfo}}">
#include "/common/shared/editPageButtons.inc"
</sun:title>
"<br>
— 71,77 ----
#include "/common/shared/alertMsg.inc"

<!-- Page Title -->
! <sun:title id="propertyContentPage"
title="$resource{i18nc.msgSecurity.EditMsgSecurity}

"
helpText="$resource

{i18nc.msgSecurity.EditMsgSecurityInfo}

">
#include "/common/shared/editPageButtons.inc"
</sun:title>
"<br>
diff -rc orig/security/msgSecurity/providerEdit.jsf
fix/security/msgSecurity/providerEdit.jsf

      • orig/security/msgSecurity/providerEdit.jsf Mon Apr 19 19:12:36 2010
      • fix/security/msgSecurity/providerEdit.jsf Mon Apr 19 19:31:54 2010
        ***************
      • 67,73 ****
        #include "/common/shared/alertMsg.inc"

<!-- Page Title -->
! <sun:title id="propertyContentPage"
title="$resource

{i18nc.msgProvider.EditPageTitle}"
helpText="$resource{$resource{i18nc.msgProvider.EditPageTitleHelp}}">
#include "providerButtons.inc"
</sun:title>
"<br><br>
— 67,73 ----
#include "/common/shared/alertMsg.inc"

<!-- Page Title -->
! <sun:title id="propertyContentPage"
title="$resource{i18nc.msgProvider.EditPageTitle}

"
helpText="$resource

{i18nc.msgProvider.EditPageTitleHelp}

">
#include "providerButtons.inc"
</sun:title>
"<br><br>
diff -rc orig/security/msgSecurity/providerNew.jsf
fix/security/msgSecurity/providerNew.jsf

      • orig/security/msgSecurity/providerNew.jsf Mon Apr 19 19:12:36 2010
      • fix/security/msgSecurity/providerNew.jsf Mon Apr 19 19:32:31 2010
        ***************
      • 59,65 ****
        #include "/common/shared/alertMsg.inc"

<!-- Page Title -->
! <sun:title id="propertyContentPage"
title="$resource

{i18nc.msgSecProvider.NewPageTitle}"
helpText="$resource{$resource{i18nc.msgSecProvider.NewPageTitleHelp}}">
#include "providerButtons.inc"
</sun:title>
"<br><br>
— 59,65 ----
#include "/common/shared/alertMsg.inc"

<!-- Page Title -->
! <sun:title id="propertyContentPage"
title="$resource{i18nc.msgSecProvider.NewPageTitle}

"
helpText="$resource

{i18nc.msgSecProvider.NewPageTitleHelp}

">
#include "providerButtons.inc"
</sun:title>
"<br><br>

Comment by gmurr [ 19/Apr/10 ]

I think it is l10n packaging issue. If new l10n packages does not fix it, we can
ask Anissa to look into it.

Comment by Anissa Lam [ 26/Apr/10 ]

Thanks Shinya for pointing out the issue.
I searched all the code and there are a total of 7 files that have the same
issue. I have fixed them in both the trunk for 3.1 and 3.0.1

Request Georges test this again with nightly build after 4/27

Here is the checkin for 3.0.1

Author: anilam
Date: 2010-04-26 20:10:14+0000
New Revision: 36584

Modified:
branches/3.0.1/admingui/common/src/main/resources/applications/lifecycleEdit.jsf
branches/3.0.1/admingui/common/src/main/resources/applications/lifecycleNew.jsf

branches/3.0.1/admingui/common/src/main/resources/security/auditModules/auditModuleEdit.jsf

branches/3.0.1/admingui/common/src/main/resources/security/jacc/jaccProviderNew.jsf

branches/3.0.1/admingui/common/src/main/resources/security/msgSecurity/msgSecurityEdit.jsf

branches/3.0.1/admingui/common/src/main/resources/security/msgSecurity/providerEdit.jsf

branches/3.0.1/admingui/common/src/main/resources/security/msgSecurity/providerNew.jsf

Log:
issue# 11592; $resource{} is repeated unexpectedly causing error in other locale.

Comment by Anissa Lam [ 26/Apr/10 ]


changed this to admingui since this is admin console code problem.

Comment by ogino [ 26/May/10 ]

Verified this is fixed in promoted b19.





[GLASSFISH-11499] Embedded app client requires current loader = ACCClassLoader; too restrictive Created: 29/Jan/10  Updated: 04/Feb/10  Resolved: 04/Feb/10

Status: Resolved
Project: glassfish
Component/s: standalone_client
Affects Version/s: V3
Fix Version/s: v3.0.1

Type: Bug Priority: Major
Reporter: Tim Quinn Assignee: Tim Quinn
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 11,499
Tags: v3_0_1_approved

 Description   

The ACC code currently casts the thread's context classloader to ACCClassLoader.
This does not work for the embedded case and, in fact, the ACC does not need to
be that restrictive.

The ACC does need to be able to find out the URLs which the thread's context
class loader handles, so it is sufficient for the ACC to cast the loader to
URLClassLoader.

Attempts to use embedded result in class cast exceptions when the cast to
ACCClassLoader fails.



 Comments   
Comment by Tim Quinn [ 29/Jan/10 ]

A while ago I checked in a fix for this into the trunk. I'm creating this
primarily so we can evaluate whether it should be fixed for ur1.

Comment by kumara [ 04/Feb/10 ]

Approved for v3.0.1

Comment by Tim Quinn [ 04/Feb/10 ]

Fix checked in for v3.0.1.

Author: tjquinn
Date: 2010-02-04 22:39:18+0000
New Revision: 35558

Modified:

branches/3.0.1/appclient/client/acc/src/main/java/org/glassfish/appclient/client/acc/AppClientContainerBuilder.java





[GLASSFISH-11498] provide a userful error message instead of the NPE when user tries to deploy a non JavaEE module as JavaEE module Created: 29/Jan/10  Updated: 08/Feb/10  Resolved: 08/Feb/10

Status: Resolved
Project: glassfish
Component/s: deployment
Affects Version/s: V3
Fix Version/s: v3.0.1

Type: Bug Priority: Major
Reporter: Hong Zhang Assignee: Hong Zhang
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 11,498
Tags: v3_0_1_approved

 Description   

In v3, if user tries to deploy a non JavaEE module as JavaEE module, it will
trigger a NPE in deployment code which does not look good. We should provide a
meaningful error message to user in this case.

Please see this issue for details:
https://glassfish.dev.java.net/issues/show_bug.cgi?id=11323

This was already fixed in the v3.1 trunk, but thinking we should probably fix it
in v3.0.1 as well because it will improve user experience.



 Comments   
Comment by Hong Zhang [ 29/Jan/10 ]

change the target milestone from the default (v3.1) to v3.0.1.

Comment by kumara [ 04/Feb/10 ]

Approved for v3.0.1

Comment by Hong Zhang [ 08/Feb/10 ]

ported fix to 3.0.1





[GLASSFISH-11494] Launching app client using Java 6u18 triggers NPE Created: 28/Jan/10  Updated: 23/Mar/10  Resolved: 23/Mar/10

Status: Resolved
Project: glassfish
Component/s: standalone_client
Affects Version/s: v3.0.1
Fix Version/s: v3.0.1

Type: Bug Priority: Critical
Reporter: Tim Quinn Assignee: Tim Quinn
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 11,494
Tags: v3_0_1_approved

 Description   

Several users have reported this, as have CTS and SQE. I've reproduced this on
a Windows system. Using exactly the same GlassFish build this does not happen
with earlier Java releases, and does not happen on Mac OS X running Apple's Java
implementation (6u17).

Attempting to launch any app client results in a stack trace like the one below.
The logic in ACCLogger has retrieved all known logger names using
LogManager.getLogManager().getLoggerNames() and then for each name uses
LogManager.getLogManager().getLogger(name). For (at least) one of the names,
the returned logger is null.

I have checked in a work around for this into the main trunk for GlassFish, but
we probably need to include this in 3.0u1 because clients will begin breaking
for many users as they upgrade to Java 6u18.

java.lang.NullPointerException
at org.glassfish.appclient.client.acc.ACCLogger$1.run(ACCLogger.java:149)
at java.security.AccessController.doPrivileged(Native Method)
at org.glassfish.appclient.client.acc.ACCLogger.reviseLogger(ACCLogger.java:146)
at org.glassfish.appclient.client.acc.ACCLogger.init(ACCLogger.java:93)
at org.glassfish.appclient.client.acc.ACCLogger.<init>(ACCLogger.java:80)
at
org.glassfish.appclient.client.AppClientFacade.createBuilder(AppClientFacade.java:360)
at
org.glassfish.appclient.client.AppClientFacade.prepareACC(AppClientFacade.java:247)
at
org.glassfish.appclient.client.acc.agent.AppClientContainerAgent.premain(AppClientContainerAgent.java:75)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
sun.instrument.InstrumentationImpl.loadClassAndStartAgent(InstrumentationImpl.java:323)
at
sun.instrument.InstrumentationImpl.loadClassAndCallPremain(InstrumentationImpl.java:338)



 Comments   
Comment by Tim Quinn [ 28/Jan/10 ]

Marking target release as 3.0.1. The Java problem will affect all v3 app
clients and I don't think we can wait for a Java fix which would require users
to fall back to an earlier Java release until then.

Comment by sherryshen [ 28/Jan/10 ]

Thanks Tim for the analysis and workaround.

Comment by dbenegiamo [ 01/Feb/10 ]

Added in CC (the web interface needs to write something...).

Comment by grootr [ 02/Feb/10 ]

I'm affected by this issue.
Can I work around it somehow without using the nightly build (e.g. using GlassFish
V3 final) ?

Comment by Tim Quinn [ 02/Feb/10 ]

grootr,

Because the problem is in Java SE 6u18, the only workaround I'm aware of that
would work with the GlassFish v3 fcs release would be to drop back to Java SE
6u17 or earlier.

If others know of some other workaround, please share it.

I expect that the workaround in GlassFish code for this will make it into the
next planned update release for v3 but I realize that does not help you today.

Comment by kumara [ 04/Feb/10 ]

Approved for v3.0.1

Comment by Tim Quinn [ 04/Feb/10 ]

Fix checked in for v3.0.1.

Author: tjquinn
Date: 2010-02-04 22:43:26+0000
New Revision: 35559

Modified:

branches/3.0.1/appclient/client/acc/src/main/java/org/glassfish/appclient/client/acc/ACCLogger.java

branches/3.0.1/appclient/client/acc/src/main/resources/org/glassfish/appclient/client/acc/LogStrings.properties

Comment by sherryshen [ 12/Feb/10 ]

Verified the fix on v3.0.1 build 4 promoted.
Thanks Tim for the fix.

Comment by pjiricka [ 23/Mar/10 ]

Hi, can someone please send a pointer to the JDK bug? Thanks.

Comment by Tim Quinn [ 23/Mar/10 ]

The Java SE bug for this is 6921073.





[GLASSFISH-11483] Admin GUI "Disk Space Memory Leak" (Generated JSPs) Created: 25/Jan/10  Updated: 08/Feb/13  Resolved: 09/Apr/10

Status: Resolved
Project: glassfish
Component/s: deployment
Affects Version/s: V3
Fix Version/s: v3.0.1

Type: Bug Priority: Major
Reporter: domdorn Assignee: Hong Zhang
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Linux
Platform: Linux


Attachments: File test.war    
Issue Links:
Related
is related to GLASSFISH-19162 Loader_<xxx> directories in generated... Resolved
Issuezilla Id: 11,483
Tags: v3_0_1_approved

 Description   

The Glassfish Admin GUI generates around 17MB of JSPs. It seems, that those JSPs
don't get deleted, when one restarts the server.

I was wondering why my glassfish installation directory contained over 1GB of
data. I found out:

domdorn@camelion ~/tmp/glassfish/glassfishv3/glassfish/domains/domain1 $ du -skh *
4.0K applications
12K autodeploy
4.0K bin
184K config
12K docroot
1.1G generated
20K lib
112K logs
4.0K master-password
61M osgi-cache
domdorn@camelion ~/tmp/glassfish/glassfishv3/glassfish/domains/domain1 $ cd
generated/
domdorn@camelion ~/tmp/glassfish/glassfishv3/glassfish/domains/domain1/generated
$ du -skh *
16K ejb
1.1G jsp
92K policy
16K xml
domdorn@camelion
~/tmp/glassfish/glassfishv3/glassfish/domains/domain1/generated/jsp $ du -skh *
976K JSUGVereinsverwaltung
524K Lyrix
4.0K Quercus PHP
4.0K WebApplication4-1.0-SNAPSHOT
1.1G __admingui
4.0K __default-web-module-server
domdorn@camelion
~/tmp/glassfish/glassfishv3/glassfish/domains/domain1/generated/jsp/__admingui $
du -skh *
17M loader_1004578760
17M loader_1061554762
17M loader_1067685269
17M loader_1109964066
17M loader_1127971736
17M loader_1234708995
17M loader_125580560
17M loader_1260856114
19M loader_1298789758
17M loader_1322688819
17M loader_1359773020
17M loader_1372142570
708K loader_1383036331
17M loader_1403025700
17M loader_1404415528
17M loader_1545440185
17M loader_1565696439
17M loader_1577347516
17M loader_1595091963
17M loader_159746358
17M loader_1610520132
17M loader_1659856006
17M loader_1682409871
17M loader_1696125627
17M loader_1743298331
17M loader_1851988795
17M loader_1886704194
17M loader_1898479173
17M loader_1902900148
17M loader_1905478085
17M loader_1969670732
17M loader_1981133419
17M loader_1999931588
17M loader_2012201363
17M loader_2051482795
17M loader_2137117149
17M loader_254981780
17M loader_262282046
17M loader_283632623
17M loader_341326414
17M loader_3505516
17M loader_396570317
17M loader_446463486
19M loader_517401794
17M loader_58465917
17M loader_593563423
17M loader_608083147
17M loader_652357099
17M loader_676091391
17M loader_695716855
17M loader_731141617
17M loader_779018293
17M loader_806763397
17M loader_835142742
17M loader_838070635
17M loader_839771990
17M loader_840137015
17M loader_849286339
17M loader_851206054
17M loader_872986037
17M loader_874554907
17M loader_899281125
17M loader_987729793



 Comments   
Comment by Anissa Lam [ 25/Jan/10 ]

Request jdlee to take a look. Will see if its possible to fix for U1.

Comment by Jason Lee [ 23/Feb/10 ]

My observation is that generated files for the admingui are removed when the
server is properly shutdown. If you are seeing a problem still, please give
exact version information, steps to reproduce, and the results you expect to
see. Thanks.

Comment by richardss [ 29/Mar/10 ]

Hi,

I'm not the original bug raiser, but I see the same issue. I'm using the release
GlassFish v3 (build 74.2) on Solaris 10 and the steps to repeat are below:

I would expect either the generated/jsp directory to be cleaned each time, or
perhaps the 'loader_nnn' directory to persist and be reused on the next startup

  • unless the admingui had changed in which case a new loader_nnn directory could
    be created and the old version deleted.

richard@myhost:~$ /usr/local/glassfishv3/bin/asadmin create-domain adminguitest
Enter admin user name [Enter to accept default "admin" / no password]>
Using port 4848 for Admin.
Using default port 8080 for HTTP Instance.
Using default port 7676 for JMS.
Using default port 3700 for IIOP.
Using default port 8181 for HTTP_SSL.
Using default port 3820 for IIOP_SSL.
Using default port 3920 for IIOP_MUTUALAUTH.
Using default port 8686 for JMX_ADMIN.
Using default port 6666 for OSGI_SHELL.
Distinguished Name of the self-signed X.509 Server Certificate is:
[CN=myhost.zur.swissbank.com,OU=GlassFish,O=Sun Microsystems,L=Santa
Clara,ST=California,C=US]
No domain initializers found, bypassing customization step
Domain adminguitest created.
Domain adminguitest admin port is 4848.
Domain adminguitest allows admin login as user "admin" with no password.
Command create-domain executed successfully.

richard@myhost:~$ ls -l
/usr/local/glassfishv3/glassfish/domains/adminguitest/generated/jsp/__admingui/
ls:
/usr/local/glassfishv3/glassfish/domains/adminguitest/generated/jsp/__admingui/:
No such file or directory

richard@myhost:~$ /usr/local/glassfishv3/bin/asadmin start-domain adminguitest
Waiting for DAS to start .........................
Started domain: adminguitest
Domain location: /usr/local/glassfishv3/glassfish/domains/adminguitest
Log file: /usr/local/glassfishv3/glassfish/domains/adminguitest/logs/server.log
Admin port for the domain: 4848
Command start-domain executed successfully.

richard@myhost:~$ ls -l
/usr/local/glassfishv3/glassfish/domains/adminguitest/generated/jsp/__admingui/
ls:
/usr/local/glassfishv3/glassfish/domains/adminguitest/generated/jsp/__admingui/:
No such file or directory

richard@myhost:~$ GET http://localhost:4848/ | grep '<title>'
<title>GlassFish Administration Console - Installation in Progress...</title>

richard@myhost:~$ GET http://localhost:4848/ | grep '<title>'
<title>GlassFish Administration Console - Installation in Progress...</title>

richard@myhost:~$ GET http://localhost:4848/ | grep '<title>'
<title>Login</title>

richard@myhost:~$ ls -l
/usr/local/glassfishv3/glassfish/domains/adminguitest/generated/jsp/__admingui/
total 1
drwxr-xr-x 8 richard richard 512 Mar 29 16:41 loader_15116093

richard@myhost:~$ cat
/usr/local/glassfishv3/glassfish/domains/adminguitest/config/pid
1864

richard@myhost:~$ ps -ef | grep 1864
richard 1878 27126 0 16:42:21 pts/1 0:00 grep 1864
richard 1864 1 0 16:40:44 pts/1 0:42
/usr/local/jdk/v1.6.0_18/bin/java -cp /usr/local/glassfishv3/glassfi

richard@myhost:~$ /usr/local/glassfishv3/bin/asadmin stop-domain adminguitest
Waiting for the domain to stop ....
Command stop-domain executed successfully.

richard@myhost:~$ ps -ef | grep 1864
richard 1883 27126 0 16:42:51 pts/1 0:00 grep 1864

richard@myhost:~$ ls -l
/usr/local/glassfishv3/glassfish/domains/adminguitest/generated/jsp/__admingui/
total 1
drwxr-xr-x 8 richard richard 512 Mar 29 16:41 loader_15116093

richard@myhost:~$ /usr/local/glassfishv3/bin/asadmin start-domain adminguitest
Waiting for DAS to start .........
Started domain: adminguitest
Domain location: /usr/local/glassfishv3/glassfish/domains/adminguitest
Log file: /usr/local/glassfishv3/glassfish/domains/adminguitest/logs/server.log
Admin port for the domain: 4848
Command start-domain executed successfully.

richard@myhost:~$ ls -l
/usr/local/glassfishv3/glassfish/domains/adminguitest/generated/jsp/__admingui/
total 1
drwxr-xr-x 8 richard richard 512 Mar 29 16:41 loader_15116093

richard@myhost:~$ GET http://localhost:4848/ | grep '<title>'
<title>GlassFish Administration Console - Installation in Progress...</title>

richard@myhost:~$ GET http://localhost:4848/ | grep '<title>'
<title>GlassFish Administration Console - Installation in Progress...</title>

richard@myhost:~$ GET http://localhost:4848/ | grep '<title>'
<title>Login</title>

richard@myhost:~$ ls -l
/usr/local/glassfishv3/glassfish/domains/adminguitest/generated/jsp/__admingui/
total 2
drwxr-xr-x 8 richard richard 512 Mar 29 16:41 loader_15116093
drwxr-xr-x 8 richard richard 512 Mar 29 16:43 loader_386128

richard@myhost:~$ cat
/usr/local/glassfishv3/glassfish/domains/adminguitest/config/pid
1888

richard@myhost:~$ ps -ef | grep 1888
richard 1888 1 0 16:43:03 pts/1 0:39
/usr/local/jdk/v1.6.0_18/bin/java -cp /usr/local/glassfishv3/glassfi
richard 1903 27126 0 16:44:10 pts/1 0:00 grep 1888

richard@myhost:~$ /usr/local/glassfishv3/bin/asadmin stop-domain adminguitest
Waiting for the domain to stop .............
Command stop-domain executed successfully.

richard@myhost:~$ ps -ef | grep 1888
richard 1908 27126 0 16:44:51 pts/1 0:00 grep 1888

richard@myhost:~$ ls -l
/usr/local/glassfishv3/glassfish/domains/adminguitest/generated/jsp/__admingui/
total 2
drwxr-xr-x 8 richard richard 512 Mar 29 16:41 loader_15116093
drwxr-xr-x 8 richard richard 512 Mar 29 16:43 loader_386128

(nb: I have formatted this output for easier reading, and anonymized some bits
because of paranoia, but these are the exact commands run in the exact sequence
without anything else done behind the scenes)

Comment by Alexis MP [ 06/Apr/10 ]

cc

Comment by Anissa Lam [ 06/Apr/10 ]
      • Issue 11752 has been marked as a duplicate of this issue. ***
Comment by Jason Lee [ 06/Apr/10 ]

richardss, thanks for the detailed report. This doesn't appear to be an
admingui issue, as the gui doesn't create or manage those files. I think the
appropriate subcomponent is the web container (or possibly deployment), so I'm
going to transfer this issue to the container team so they can take a look at it.

Comment by Anissa Lam [ 06/Apr/10 ]

I am using latest build of 3.0.1 and can reproduce the issue consistently.
All the following way of stopping the server behaves the same.

  • just kill the server
  • using asadmin stop-domain command
  • stop-domain through admin console

the generated/jsp/__admingui/ directory will have more and keep growing with
loader_xxxxx directory.

right now, i am seeing:

~/Awork/V3/u1v3/3.0.1/dist-gf/glassfish/domains/domain1/generated 126) ls -l
jsp/__admingui/
total 0
drwxr-xr-x 11 anilam owner 374 Apr 6 08:42 loader_1475241596/
drwxr-xr-x 11 anilam owner 374 Apr 6 08:41 loader_1740430143/
drwxr-xr-x 11 anilam owner 374 Apr 6 08:37 loader_1779604093/

I think we should try to fix this for 3.0.1
thanks

Comment by Anissa Lam [ 06/Apr/10 ]

Also wanted to add that Ken confirmed the same issue on his linux as well.

Comment by Jason Lee [ 06/Apr/10 ]

My apologies. After talking with Ken and Anissa, I realized my script was
pruning that directory. After fixing that, we have confirmed that this issue
occurs on Mac and Linux.

Comment by jluehe [ 06/Apr/10 ]

The "loader_<webappClassLoaderInstance.hashCode()" directories are a side-effect
of the fix for https://glassfish.dev.java.net/issues/show_bug.cgi?id=9894
("IWebMvc2 errors on startup").

Some of the relevant comments for that issue copied below.

It looks like during a domain shutdown, the web container is not receiving the
appropriate lifecycle event that would cause it to destroy the class loaders of
all deployed web applications, which in turn would cause the
"loader_<webappClassLoaderInstance.hashCode()" directories to be deleted.

------- Additional comments from jluehe Fri Oct 23 02:06:13 +0000 2009 -------

Here's my analysis: During deployment, the backend creates 2 instances of
WebappClassLoader for each app: one temporary ("DeploymentClassLoader"), the
other permanent ("ApplicationClassLoader").

Both classloaders share the same repository for static resources extracted from
JAR files located in the application's WEB-INF/lib directory, whose location is
given as

[...]domain1/generated/jsp/<appname>/loader

This is also where the log4j.properties resource from
iwebmvc-core-2.0-SNAPSHOT.jar gets extracted:

[...]domain1/generated/jsp/<appname>/loader/log4j.properties

During deployment, the "DeploymentClassLoader" is destroyed, and in the course
of being destroyed, it closes all its JAR files and also removes the

[...]domain1/generated/jsp/<appname>/loader

folder. This causes a problem later on, because any attempt to open a URL
returned by the getResource() method of the "ApplicationClassLoader" will now
result in a FileNotFoundException, as in the case of log4j.properties:

[#|2009-10-23T09:04:11.880+0800|SEVERE|glassfish|null|_ThreadID=27;_ThreadName=Thread-3;|log4j:ERROR
Could not read configuration file from URL
file:/space/luehe/ws/v3/distributions/glassfish/target/glassfishv3/glassfish/domains/domain1/generated/jsp/IWebMvc2-Final_RC/loader/log4j.properties.|#]

[#|2009-10-23T09:04:11.883+0800|SEVERE|glassfish|null|_ThreadID=27;_ThreadName=Thread-3;|java.io.FileNotFoundException:
/space/luehe/ws/v3/distributions/glassfish/target/glassfishv3/glassfish/domains/domain1/generated/jsp/IWebMvc2-Final_RC/loader/log4j.properties
(No such file or directory)

The fix would be to assign a separate "loader" directory for each of the two
classloaders, to prevent the classloaders from interfering with each other.

------- Additional comments from jluehe Fri Oct 23 16:27:09 +0000 2009 -------

Changed folder name "loader" to "loader_<webappClassLoaderInstance.hashCode()":

Sending web/war-util/src/main/java/org/glassfish/web/loader/WebappClassLoader.java
Transmitting file data .
Committed revision 33232.

Comment by kumara [ 06/Apr/10 ]

Approved for fixing in 3.0.1 branch.

Comment by jluehe [ 06/Apr/10 ]

Hi Hong, I think this is a deployment issue.

The directories in question normally get deleted as part of
WebappClassLoader#stop, which, among other things, executes this code:

if (loaderDir != null)

{ deleteDir(loaderDir); }

In the case of an undeployment, WebappClassLoader#stop is invoked by the
following (partial) call chain:

org.glassfish.web.loader.WebappClassLoader.stop(WebappClassLoader.java:1729)
at
org.glassfish.web.loader.WebappClassLoader.preDestroy(WebappClassLoader.java:1636)
at
org.glassfish.internal.data.ApplicationInfo.unload(ApplicationInfo.java:293)
at
com.sun.enterprise.v3.server.ApplicationLifecycle.unload(ApplicationLifecycle.java:763)
at
com.sun.enterprise.v3.server.ApplicationLifecycle.undeploy(ApplicationLifecycle.java:793)

However, during a domain shutdown, WebappClassLoader#stop is never called for
any of the deployed apps.

Comment by Hong Zhang [ 07/Apr/10 ]

Jan: Thanks for the investigation!

We actually do try to unload applications as part of the server shutdown (see
ApplicationLoaderService.preDestroy), but what's missing here is we only did it
for user applications and not system applications!

I have added the code to stop/unload system applications in the
ApplicationLoaderService.preDestroy as well and the problem seems go away now.
But there is still one piece of puzzle left, when the system application (admin
gui app) was being stopped from the web container, there was an exception
happening. This does not happen to user applications, as admin gui is loaded on
demand, not sure if there is some special code needs to be put there to stop
it. I tried to trace the web code and I found myself lost in the deep stack
trace, so I will let you take a look at this part. For now, I have added a
try/catch block on the stopping part.

I have checked in my changes in v3.1, you can take a look at this with the
trunk code. I will next check in my changes in v3.0.1.

Comment by jluehe [ 07/Apr/10 ]

Hi Hong, when I investigated the issue, I was able to reproduce it with a user
application as well.

I'm going to attach my test app. Please deploy and access /test/hello.txt

After shutdown, you'll see a loader_<xxx> directory under

domains/domain1/generated/jsp/test

with (in my case) these contents:

loader_583158213/
loader_583158213//META-INF
loader_583158213//META-INF/MANIFEST.MF
loader_583158213//META-INF/resources
loader_583158213//META-INF/resources/hello.txt

I have not tried again with the changes you just committed ...

Comment by jluehe [ 07/Apr/10 ]

Created an attachment (id=4295)
Test application that reproduces the issue

Comment by Hong Zhang [ 07/Apr/10 ]

Jan: I tried on an installation before my changes (from last night), the loader
directory got created after I accessed the app, and the loader directory got
deleted after I shut down the domain. The only thing left was test_SESSIONS.ser
under the generated/jsp/test.

Comment by Hong Zhang [ 07/Apr/10 ]

Also checked in my changes for 3.0.1

Comment by jluehe [ 07/Apr/10 ]

Great! Thanks for verifying your fix with my user app. So it looks like there
used to be an issue with both user and system apps.

Note that test_SESSIONS.ser is expected to be created during a domain shutdown.
It contains all of the sessions of "test" (that were active prior to the domain
shutdown) in serialized format, so that those sessions may be resumed following
a subsequent domain restart. test_SESSIONS.ser will be removed once its contents
have been read during a subsequent domain restart.

Comment by Hong Zhang [ 09/Apr/10 ]

I am marking the bug fixed as the primary issue reported by user is now fixed.

Comment by afrappe [ 07/Feb/13 ]

Hello, I'm using liferay bundled with glassfish 3.1.2 and it seems that this bug is still present.

Comment by Hong Zhang [ 08/Feb/13 ]

Yes, there was a regression for this (see issue 19162 which is now linked to this issue) and the regression was fixed in GlassFish 4.0.





[GLASSFISH-11481] create connection pool creates wrong name for EAR-packaged RAR Created: 25/Jan/10  Updated: 31/Mar/10  Resolved: 31/Mar/10

Status: Resolved
Project: glassfish
Component/s: admin_gui
Affects Version/s: V3
Fix Version/s: v3.0.1

Type: Bug Priority: Major
Reporter: matthiasfraass Assignee: Anissa Lam
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Windows XP
Platform: All


Attachments: File myjca.rar     File TestJCA.ear    
Issuezilla Id: 11,481
Tags: v3_0_1_approved

 Description   

There's a difference between if a resource adapter is deployed separately or
within a EAR file. I suspect the name is set wrong when configuring it via
Admin-GUI. But let me explain the scenario:

a) Deploying a resource adapter separately (e.g. see attached "myjca.rar" from
[1])
b) Deploying a resource adapter within a EAR (e.g. TestJCA.EAR/myjca.rar - see
the attached sample)

Scenario (b) won't work when creating resources (e.g. connection pools) with the
Admin GUI!

You can see the difference in the Admin GUI when adding a "New Connector
Connection Pool":
For (a) you see "myjca" in the drop down box.
Continue to create the pool and call it "test1".
Now "ping" it - it will succeed.

For (b) you see "TestJCA#genericra.rar" in the drop down box. See the additional
".rar" suffix? I think that's wrong.
Continue to create the pool and call it "test2".
Now "ping" it - it will fail:

[#|2010-01-
25T13:55:36.796+0100|WARNING|glassfishv3.0|javax.enterprise.resource.resourceada
pter.com.
sun.enterprise.connectors.util|_ThreadID=26;_ThreadName=Thread-1;|RAR8055:
Exception while getting c
onnector descriptor for RAR [ TestJCA#myjca.rar ],
java.lang.IllegalArgumentException: myjca.rar.rar

#]
[#
2010-01-
25T13:55:36.796+0100
SEVERE glassfishv3.0 javax.enterprise.resource.resourceadap
ter.com.s
un.enterprise.connectors.service
_ThreadID=26;_ThreadName=Thread-1; RAR7134: RAR
[ TestJCA#myjca.rar
] is not deployed
#]
[#
2010-01-
25T13:55:36.796+0100
SEVERE glassfishv3.0 javax.enterprise.resource.resourceadap
ter.com.s
un.enterprise.connectors.service
_ThreadID=26;_ThreadName=Thread-1; RAR8062:
failed to load resource
s for RA[ TestJCA#myjca.rar ],
com.sun.appserv.connectors.internal.api.ConnectorRuntimeException
#]
[#
2010-01-
25T13:55:36.796+0100
WARNING glassfishv3.0 javax.enterprise.resource.resourceada
pter.com.
sun.enterprise.connectors.service
_ThreadID=26;_ThreadName=Thread-1; RAR7010:
Pool not reachable.
#
]
[#
2010-01-
25T13:55:36.796+0100
WARNING glassfishv3.0 javax.enterprise.resource.resourceada
pter.com.
sun.enterprise.connectors.service
_ThreadID=26;_ThreadName=Thread-1; RAR8054:
Exception while creati
ng an unpooled [test] connection for pool [ test2 ], This pool is not registered
with the runtime en
vironment : test2
#]

See the double "rar" suffix in the first error message: "myjca.rar.rar"? I think
that's wrong.

When creating the connection pool via asadmin, it works!
>asadmin create-connector-connection-pool --raname TestJCA#myjca –
connectiondefinition javax.sql.DataSource test3

>asadmin ping-connection-pool test3
Command ping-connection-pool executed successfully.

So this seems to be a Admin-GUI specific problem!

Best Regards,

Matthias

[1] http://www.javaworld.com/javaworld/jw-02-2002/jw-0201-jca2.html#resources



 Comments   
Comment by matthiasfraass [ 25/Jan/10 ]

Created an attachment (id=4177)
sample EAR with packaged RAR inside

Comment by matthiasfraass [ 25/Jan/10 ]

Created an attachment (id=4178)
sample RAR file

Comment by Anissa Lam [ 25/Jan/10 ]

For the details and attaching the sample apps.
For any embedded component, the format is like "application-name#module-name"
where module-name is supposed to include the extension.
eg, if you deploy a ear with an embedded war, you will see this
"myEar#myweb.war" as the choice of default web module in the Virtual Server page.

Transferring to 'jca' so this can be fixed, hopefully in U1.

Comment by Anissa Lam [ 25/Jan/10 ]

"For the details and attaching the sample apps."
OOps, the above should begin with a 'Thanks'

Comment by Jagadish [ 08/Feb/10 ]

We have come across this issue some time back and we had a workaround by
ignoring the .rar extension in the AMX api to GUI. However that does not work
for all use-cases and hence this issue is seen.

While evaluating this issue, we thought of fixing it in the backend by ignoring
".rar", however, there seems to be a documented naming mechanism that is followed
http://docs.sun.com/app/docs/doc/820-4336/bealq?a=view
which indicates the format to be AppName#EmbeddedAppName (no file type extensions)

We also need to consider the upgrade scenario from v2 to v3 domain.xml
where we expect the configuration of the connection pool to work fine
out of the box. [as simple as copying the elements from v2's domain.xml
to v3's domain.xml]

Requesting the GUI team to fix the issue by displaying AppName#EmbeddedAppName
thereby matching 9.x/8.x versions of App.server.

Comment by Anissa Lam [ 09/Feb/10 ]

change target milestone to v3.0.1. will fix this in u1.

Comment by kumara [ 09/Feb/10 ]

Approving for inclusion in v3.0.1

Comment by kumara [ 09/Feb/10 ]

Approving for inclusion in v3.0.1

Comment by Jagadish [ 15/Feb/10 ]
      • Issue 11564 has been marked as a duplicate of this issue. ***
Comment by Anissa Lam [ 31/Mar/10 ]

This is fixed in both 3.0.1 and 3.1
Tested with the attached app.

========
Author: anilam
Date: 2010-04-01 00:04:08+0000
New Revision: 36229

Modified:

trunk/v3/admingui/jca/src/main/java/org/glassfish/jca/admingui/handlers/ConnectorsHandlers.java
trunk/v3/admingui/jca/src/main/resources/connectorConnectionPoolNew1.jsf

=========
Author: anilam
Date: 2010-03-31 23:58:12+0000
New Revision: 36228

Modified:

branches/3.0.1/admingui/jca/src/main/java/org/glassfish/jca/admingui/handlers/ConnectorsHandlers.java
branches/3.0.1/admingui/jca/src/main/resources/connectorConnectionPoolNew1.jsf

========





[GLASSFISH-11475] Do Platform Services work with 64 bit Windows? Created: 22/Jan/10  Updated: 08/Mar/10  Resolved: 08/Mar/10

Status: Resolved
Project: glassfish
Component/s: admin
Affects Version/s: V3
Fix Version/s: v3.0.1

Type: Bug Priority: Major
Reporter: Byron Nevins Assignee: Byron Nevins
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 11,475

 Description   

A problem was reported in the Forum about this. Need to verify and fix if
necessary.



 Comments   
Comment by Byron Nevins [ 08/Mar/10 ]

I checked with Kohsuke. The native tool we use is really a .NET application.
So, like Java, it is not 32 or 64 bit.

Comment by Byron Nevins [ 08/Mar/10 ]

.





[GLASSFISH-11470] NPE on doSelect that kills the server Created: 21/Jan/10  Updated: 08/Apr/10  Resolved: 08/Apr/10

Status: Resolved
Project: glassfish
Component/s: grizzly-kernel
Affects Version/s: V3
Fix Version/s: v3.0.1

Type: Bug Priority: Blocker
Reporter: iminar Assignee: oleksiys
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Solaris
Platform: Macintosh


Issuezilla Id: 11,470
Tags: v3_0_1_approved

 Description   

I have gf v3 running our rails app in production. The server is configured with this monitoring:

set server.monitoring-service.module-monitoring-levels.http-service=LOW
set server.monitoring-service.module-monitoring-levels.jvm=LOW

Over night the server stopped accepting any http connections. The jvm remained running and otherwise healthy.

The server log contained this last message:

[#|2010-01-21T03:06:47.045-0800|SEVERE|glassfishv3.0|grizzly|_ThreadID=19;_ThreadName=Thread-1;|doSelect exception
java.lang.NullPointerException
at com.sun.enterprise.v3.services.impl.monitor.MonitorableSelectorHandler.acceptWithoutRegistration(MonitorableSele
ctorHandler.java:96)
at com.sun.grizzly.http.SelectorThreadHandler.onAcceptInterest(SelectorThreadHandler.java:91)
at com.sun.grizzly.SelectorHandlerRunner.handleSelectedKey(SelectorHandlerRunner.java:295)
at com.sun.grizzly.SelectorHandlerRunner.handleSelectedKeys(SelectorHandlerRunner.java:258)
at com.sun.grizzly.SelectorHandlerRunner.doSelect(SelectorHandlerRunner.java:195)
at com.sun.grizzly.SelectorHandlerRunner.run(SelectorHandlerRunner.java:130)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:619)

#]

I'm going to turn off the monitoring and see if that helps, but even if that helps I believe that this is a serious issue that should be fixed quickly.



 Comments   
Comment by iminar [ 21/Jan/10 ]

I should add that the app is deployed as war using warbler. But I don't think that
matters.

Comment by iminar [ 22/Jan/10 ]

This issue happened again last night. With http-service monitoring set to OFF. I'm
changing the priority to Blocker.

Comment by oleksiys [ 25/Jan/10 ]

Fixed.

Author: oleksiys
Date: 2010-01-25 19:43:05+0000
New Revision: 35447

Modified:

trunk/v3/core/kernel/src/main/java/com/sun/enterprise/v3/services/impl/monitor/MonitorableSelect
orHandler.java

Log:
fix issue #11470
https://glassfish.dev.java.net/issues/show_bug.cgi?id=11470
"NPE on doSelect that kills the server"

Comment by kumara [ 26/Mar/10 ]

Reopen to fix in 3.0.1

Comment by oleksiys [ 08/Apr/10 ]

integrated into 3.0.1

Date: 2010-04-08 09:57:10+0000
New Revision: 36355

Modified:

branches/3.0.1/core/kernel/src/main/java/com/sun/enterprise/v3/services/impl/monitor/Monitorabl
eSelectorHandler.java

Log:
fix the issue #11470
https://glassfish.dev.java.net/issues/show_bug.cgi?id=11470
"NPE on doSelect that kills the server"

Approved by Jerome





[GLASSFISH-11467] Missing implementation of createNamedQuery(String,Class<?>) ? Created: 21/Jan/10  Updated: 01/Feb/10  Resolved: 01/Feb/10

Status: Resolved
Project: glassfish
Component/s: entity-persistence
Affects Version/s: V3
Fix Version/s: v3.0.1

Type: Bug Priority: Major
Reporter: romainmuller Assignee: tware
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 11,467

 Description   

Hello,

My glassfish instance keeps throwing an odd UnsupportedOperationException on thr
following line of code:

final TypedQuery<LoaderTable> listLoaderTables =
config.createNamedQuery("listLoaderTables", LoaderTable.class);

Where "config" refers to an EntityManager instance that is injected into an EJB.
All situations I've tried so far get to the same issue so I don't think this is
related to the way I use the EntityManager, rater a missing implementation. The
exact full StackTrace is:

java.lang.UnsupportedOperationException
at
org.eclipse.persistence.internal.jpa.EntityManagerImpl.createNamedQuery(EntityManagerImpl.java:974)
at
com.sun.enterprise.container.common.impl.EntityManagerWrapper.createNamedQuery(EntityManagerWrapper.java:555)
at somepackage.LoaderDefaultConfig.initialize(LoaderDefaultConfig.java:38)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
com.sun.ejb.containers.interceptors.BeanCallbackInterceptor.intercept(InterceptorManager.java:1006)
at
com.sun.ejb.containers.interceptors.CallbackChainImpl.invokeNext(CallbackChainImpl.java:61)
at
com.sun.ejb.containers.interceptors.CallbackInvocationContext.proceed(CallbackInvocationContext.java:109)
at
com.sun.ejb.containers.interceptors.SystemInterceptorProxy.doCallback(SystemInterceptorProxy.java:133)
at
com.sun.ejb.containers.interceptors.SystemInterceptorProxy.init(SystemInterceptorProxy.java:115)
at sun.reflect.GeneratedMethodAccessor716.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
com.sun.ejb.containers.interceptors.CallbackInterceptor.intercept(InterceptorManager.java:961)
at
com.sun.ejb.containers.interceptors.CallbackChainImpl.invokeNext(CallbackChainImpl.java:61)
at
com.sun.ejb.containers.interceptors.InterceptorManager.intercept(InterceptorManager.java:390)
at
com.sun.ejb.containers.interceptors.InterceptorManager.intercept(InterceptorManager.java:373)
at
com.sun.ejb.containers.AbstractSingletonContainer.createSingletonEJB(AbstractSingletonContainer.java:518)
... 38 more



 Comments   
Comment by romainmuller [ 21/Jan/10 ]

Oh and if that's of some use, the entity is defined as:

@Entity
@NamedQuery(name = "listLoaderTables", query = "SELECT lt FROM LoaderTable lt
WHERE 1=1")
public class LoaderTable implements Serializable

{ /* Some pretty classical JPA-enabled class code there. */ }
Comment by Dies Koper [ 21/Jan/10 ]

That's interesting..
This method is not in the JPA2.0 spec and not in the Java EE 6 javadoc.
But it is there in the interface, and EclipseLink (confirmed with the latest
source) simply throws an UnsupportedOperationException() with no message, and
no comments in the code with more details..

Comment by romainmuller [ 21/Jan/10 ]

If I may correct, the method IS at list in the JavaEE6 Javadoc. See
http://java.sun.com/javaee/6/docs/api/javax/persistence/EntityManager.html#createNamedQuery%28java.lang.String,%20java.lang.Class%29

Comment by Dies Koper [ 21/Jan/10 ]

I stand corrected, you are right. I tried so hard to be careful not to look at
the JavaEE 5 javadocs but it looks like I did.

Other similar methods (like the createQuery equivalent) have been implemented,
it's just this one that's throwing the UnsupportedOperationException. Also, CTS
does check for this method's existence. I haven't gone through all tests, but I
suppose it has no tests that actually use this method.

Comment by Mitesh Meswani [ 21/Jan/10 ]

https://bugs.eclipse.org/bugs/show_bug.cgi?id=300412 tracks this issue in
EclipseLink.The fix has been integrated in EclipseLink and will be integrated in
GlassFish with next promoted build of EclipseLink

Comment by Mitesh Meswani [ 21/Jan/10 ]

Setting the target milestone...

Comment by Mitesh Meswani [ 28/Jan/10 ]

Checked in http://fisheye4.atlassian.com/changelog/glassfish-svn/?cs=35508

Comment by Mitesh Meswani [ 01/Feb/10 ]

Integrated http://fisheye4.atlassian.com/changelog/glassfish-svn/?cs=35529 in
trunk





[GLASSFISH-11461] MQ hangs appserver due to incorrect sychronization Created: 20/Jan/10  Updated: 21/Jan/10  Resolved: 21/Jan/10

Status: Resolved
Project: glassfish
Component/s: jms
Affects Version/s: V3
Fix Version/s: v3.0.1

Type: Bug Priority: Critical
Reporter: Scott Oaks Assignee: Nigel Deakin
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 11,461

 Description   

This is a tracking issue for OpenMQ issue 42
(https://mq.dev.java.net/issues/show_bug.cgi?id=42). We need to pick up the new
MQ build when it has fixed that issue.



 Comments   
Comment by kumara [ 20/Jan/10 ]

Setting target to 3.0.1.

Comment by Nigel Deakin [ 21/Jan/10 ]

Assigned to Nigel

Comment by Nigel Deakin [ 21/Jan/10 ]

I have committed a fix into the MQ4.4U1P2 repository; the fix will be released
in whatever build of Glassfish V3 U1 incorporates the first build of MQ4.4U1P2.





[GLASSFISH-11449] Timerevents to be added for monitoring in the security module Created: 18/Jan/10  Updated: 09/Feb/10  Resolved: 09/Feb/10

Status: Resolved
Project: glassfish
Component/s: security
Affects Version/s: V3
Fix Version/s: v3.0.1

Type: Bug Priority: Major
Reporter: Nithya Ramakrishnan Assignee: Nithya Ramakrishnan
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 11,449
Tags: v3_0_1_approved

 Description   

Requirement for monitoring module - Timer events are to be inserted in the
security module for probing the start and end times for the various security events



 Comments   
Comment by Nithya Ramakrishnan [ 18/Jan/10 ]

Added the timer probes and inserted the probes at appropriate places in the
security module.

Comment by kumara [ 09/Feb/10 ]

Approved for v3.0.1





[GLASSFISH-11448] cannot create custom realm from admin console Created: 18/Jan/10  Updated: 09/Feb/10  Resolved: 09/Feb/10

Status: Resolved
Project: glassfish
Component/s: admin_gui
Affects Version/s: V3
Fix Version/s: v3.0.1

Type: Bug Priority: Major
Reporter: ymajoros Assignee: Anissa Lam
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 11,448

 Description   

on build 74.2,

Tring to add a realm, defined in login.conf, when I press on "save", I get the
message: "An error as occured". Couldn't find the cause in the logs, just had
following stacktrace.

Last comment on http://blogs.sun.com/nithya/entry/groups_in_custom_realms
(Posted by Sascha on January 05, 2010 at 05:34 PM SCT #) looked similar.

[#|2010-01-18T09:30:10.150+0100|INFO|glassfishv3.0|javax.enterprise.system.tools.admin.org.glassfish.server|_ThreadID=28;_ThreadName=Thread-1;|Can't
create children

org.jvnet.hk2.config.TransactionFailure: Unexpected exception during isValid call

at org.jvnet.hk2.config.ConfigSupport._apply(ConfigSupport.java:194)

at org.jvnet.hk2.config.ConfigSupport.apply(ConfigSupport.java:130)

at
org.glassfish.admin.amx.impl.config.AMXConfigImpl.createChildren(AMXConfigImpl.java:518)

at
org.glassfish.admin.amx.impl.config.AMXConfigImpl.createChild(AMXConfigImpl.java:620)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)

at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

at java.lang.reflect.Method.invoke(Method.java:597)

at org.glassfish.admin.amx.impl.mbean.AMXImplBase.invoke(AMXImplBase.java:1038)

at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:836)

at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:761)

at
javax.management.MBeanServerInvocationHandler.invoke(MBeanServerInvocationHandler.java:288)

at
org.glassfish.admin.amx.util.jmx.MBeanProxyHandler.invoke(MBeanProxyHandler.java:453)

at
org.glassfish.admin.amx.core.proxy.AMXProxyHandler._invoke(AMXProxyHandler.java:822)

at
org.glassfish.admin.amx.core.proxy.AMXProxyHandler.invoke(AMXProxyHandler.java:526)

at $Proxy126.createChild(Unknown Source)

at
org.glassfish.admingui.common.handlers.SecurityHandler.saveRealm(SecurityHandler.java:253)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)

at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

at java.lang.reflect.Method.invoke(Method.java:597)

at
com.sun.jsftemplating.layout.descriptors.handler.Handler.invoke(Handler.java:442)

at
com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:420)

at
com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:394)

at
com.sun.jsftemplating.layout.event.CommandActionListener.invokeCommandHandlers(CommandActionListener.java:150)

at
com.sun.jsftemplating.layout.event.CommandActionListener.processAction(CommandActionListener.java:98)

at javax.faces.event.ActionEvent.processListener(ActionEvent.java:88)

at javax.faces.component.UIComponentBase.broadcast(UIComponentBase.java:772)

at javax.faces.component.UICommand.broadcast(UICommand.java:300)

at com.sun.webui.jsf.component.WebuiCommand.broadcast(WebuiCommand.java:160)

at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:775)

at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:1267)

at
com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:82)

at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)

at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)

at javax.faces.webapp.FacesServlet.service(FacesServlet.java:312)

at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1523)

at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:343)

at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:215)

at com.sun.webui.jsf.util.UploadFilter.doFilter(UploadFilter.java:240)

at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)

at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:215)

at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:277)

at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:188)

at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:641)

at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:97)

at
com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:85)

at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:185)

at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:332)

at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:233)

at
com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:239)

at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:791)

at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:693)

at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:954)

at
com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:170)

at
com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:135)

at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:102)

at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:88)

at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:76)

at
com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:53)

at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:57)

at com.sun.grizzly.ContextTask.run(ContextTask.java:69)

at
com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:330)

at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:309)

at java.lang.Thread.run(Thread.java:619)

Caused by: javax.validation.ValidationException: Unexpected exception during
isValid call

at
org.hibernate.validator.engine.ConstraintTree.validateSingleConstraint(ConstraintTree.java:144)

at
org.hibernate.validator.engine.ConstraintTree.validateConstraints(ConstraintTree.java:118)

at
org.hibernate.validator.metadata.MetaConstraint.validateConstraint(MetaConstraint.java:121)

at
org.hibernate.validator.engine.ValidatorImpl.validateConstraint(ValidatorImpl.java:334)

at
org.hibernate.validator.engine.ValidatorImpl.validateConstraintsForRedefinedDefaultGroup(ValidatorImpl.java:278)

at
org.hibernate.validator.engine.ValidatorImpl.validateConstraintsForCurrentGroup(ValidatorImpl.java:260)

at
org.hibernate.validator.engine.ValidatorImpl.validateInContext(ValidatorImpl.java:213)

at org.hibernate.validator.engine.ValidatorImpl.validate(ValidatorImpl.java:119)

at org.jvnet.hk2.config.WriteableView.canCommit(WriteableView.java:286)

at org.jvnet.hk2.config.Transaction.commit(Transaction.java:96)

at org.jvnet.hk2.config.ConfigSupport._apply(ConfigSupport.java:173)

... 64 more

Caused by: java.lang.NullPointerException

at
com.sun.enterprise.config.serverbeans.customvalidators.FileRealmPropertyCheckValidator.isValid(FileRealmPropertyCheckValidator.java:61)

at
com.sun.enterprise.config.serverbeans.customvalidators.FileRealmPropertyCheckValidator.isValid(FileRealmPropertyCheckValidator.java:49)

at
org.hibernate.validator.engine.ConstraintTree.validateSingleConstraint(ConstraintTree.java:141)

... 74 more

#]


 Comments   
Comment by ymajoros [ 18/Jan/10 ]

Also found this in the logs:

[#|2010-01-18T09:30:10.087+0100|INFO|glassfishv3.0|javax.enterprise.system.std.com.sun.enterprise.v3.services.impl|_ThreadID=28;_ThreadName=Thread-1;|[auth-realm
=

{classname=null, name=epcRealm}

[ property =

{description=, name=datasource-jndi, value=jdbc/epcCurrent}

property =

{description=, name=jaas-context, value=epcRealm}

]]|#]

Looks to me like the class name is not taken into account, just the one from the
dropdown list (empty, in my case).

Comment by ymajoros [ 18/Jan/10 ]

Defined the realm manually in domain.xml --> "successfully created" in logs but
properties not displayed in admin console, although still in domain.xml

Comment by Anissa Lam [ 22/Jan/10 ]

will fix this in u1.

Comment by Anissa Lam [ 09/Feb/10 ]

This is duplicate of 11382. Marking as such and will be fixed in u1.

      • This issue has been marked as a duplicate of 11382 ***




[GLASSFISH-11441] Skip default error page if HttpServletResponse#setStatus is called with an error code Created: 14/Jan/10  Updated: 15/Feb/10  Resolved: 15/Feb/10

Status: Resolved
Project: glassfish
Component/s: web_container
Affects Version/s: V3
Fix Version/s: v3.0.1

Type: Bug Priority: Major
Reporter: jluehe Assignee: jluehe
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Sun


Issuezilla Id: 11,441

 Description   

Calling HttpServletResponse#setStatus with an error code correctly skips any
custom error pages, as required by the spec:

  • <p>If this method is used to set an error code, then the container's
  • error page mechanism will not be triggered. If there is an error and
  • the caller wishes to invoke an error page defined in the web
  • application, then {@link #sendError}

    must be used instead.

However, the default error page is included in the response, which is an error.

This can be seen by accessing a Servlet of the form:

public void doGet(HttpServletRequest request,
HttpServletResponse response)
throws ServletException, IOException

{ response.setStatus(500); }

which currently produces this response:

HTTP/1.1 500 Internal Server Error
X-Powered-By: Servlet/3.0
Server: GlassFish v3
Content-Type: text/html
Content-Length: 1018
Date: Thu, 14 Jan 2010 22:21:24 GMT
Connection: close

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"><html><head><title>GlassFish
v3 - Error report</title><style type="text/css"><!--H1

{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:22px;}

H2

{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:16px;}

H3

{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:14px;}

BODY

{font-family:Tahoma,Arial,sans-serif;color:black;background-color:white;}

B

{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;}

P

{font-family:Tahoma,Arial,sans-serif;background:white;color:black;font-size:12px;}

A

{color : black;}

HR

{color : #525D76;}

--></style> </head><body><h1>HTTP Status
500 - </h1><hr/><p><b>type</b> Status
report</p><p><b>message</b></p><p><b>description</b>The server encountered an
internal error () that prevented it from fulfilling this
request.</p><hr/><h3>GlassFish v3</h3></body></html>Connection to localhost
closed by foreign host.

In this case, the response body should be empty.



 Comments   
Comment by jluehe [ 14/Jan/10 ]

Sending web-core/src/main/java/org/apache/catalina/core/StandardHostValve.java
Transmitting file data .
Committed revision 35367.

Comment by jluehe [ 15/Feb/10 ]

Ported fix to v3.0.1:

Sending
web-core/src/main/java/org/apache/catalina/core/StandardHostValve.java
Transmitting file data .
Committed revision 35654.





[GLASSFISH-11436] Unable to lookup datasource from a OSGi bundle unless the datasource is already looked up. Created: 14/Jan/10  Updated: 15/Feb/10  Resolved: 15/Feb/10

Status: Resolved
Project: glassfish
Component/s: jca
Affects Version/s: V3
Fix Version/s: v3.0.1

Type: Bug Priority: Major
Reporter: Sanjeeb Sahoo Assignee: Jagadish
Resolution: Fixed Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Java Archive File lookuptest.jar    
Issuezilla Id: 11,436
Tags: v3_0_1_approved

 Description   

User pjurak reported a similar issue at
http://weblogs.java.net/blog/2009/06/16/our-second-hybrid-application-ejb-osgi-service#comment-11840

There appears to be some context class loader issue here. To reproduce, follow
the instructions below:

1. Start glassfish (with no apps deployed)
2. Start JavaDB database, as this test uses DerbyPool
3. Copy the attached OSGi bundle to domain1/autodeploy/bundles/ directory.
You shall see the following exception in the server.log (More details about
exception is at the end of this description):

RAR6035 : Resource adapter start failed :

{0}
javax.validation.ValidationException: Unable to find a default provider

4. Run "asadmin ping DerbyPool"

5. Now if you "touch domain1/autodeploy/bundles/lookuptest.jar," you can see it
being successful in looking up the datasource.

Relevant portion of server.log is attached here with:
[#|2010-01-14T17:48:56.946+0530|SEVERE|glassfishv3.0|javax.enterprise.resource.resourceadapter.com.sun.enterprise.connectors|_ThreadID=21;_ThreadName={felix.fileinstall.poll=5000, service.pid=org.apache.felix.fileinstall.ec1bf2e9-d8e5-4403-bd59-45d6a604bf56, felix.fileinstall.bundles.new.start=true, felix.fileinstall.dir=/space/ss141213/software/glassfishv3/glassfish/domains/domain1/autodeploy/bundles/, service.factorypid=org.apache.felix.fileinstall, felix.fileinstall.filename=org.apache.felix.fileinstall-autodeploy-bundles.cfg, felix.fileinstall.debug=1};|RAR6035 : Resource adapter start failed : {0}

javax.validation.ValidationException: Unable to find a default provider
at javax.validation.Validation$GenericBootstrapImpl.configure(Validation.java:264)
at
com.sun.enterprise.connectors.util.ConnectorJavaBeanValidator.getBeanValidator(ConnectorJavaBeanValidator.java:100)
at
com.sun.enterprise.connectors.util.ConnectorJavaBeanValidator.validateJavaBean(ConnectorJavaBeanValidator.java:59)
at
com.sun.enterprise.connectors.ActiveOutboundResourceAdapter.init(ActiveOutboundResourceAdapter.java:118)
at
com.sun.enterprise.connectors.ActiveRAFactory.instantiateActiveResourceAdapter(ActiveRAFactory.java:130)
at
com.sun.enterprise.connectors.ActiveRAFactory.createActiveResourceAdapter(ActiveRAFactory.java:101)
at
com.sun.enterprise.connectors.service.ResourceAdapterAdminServiceImpl.createActiveResourceAdapter(ResourceAdapterAdminServiceImpl.java:216)
at
com.sun.enterprise.connectors.service.ResourceAdapterAdminServiceImpl.createActiveResourceAdapter(ResourceAdapterAdminServiceImpl.java:338)
at
com.sun.enterprise.connectors.ConnectorRuntime.createActiveResourceAdapter(ConnectorRuntime.java:330)
at
com.sun.enterprise.connectors.service.ConnectorService.loadDeferredResourceAdapter(ConnectorService.java:164)
at
com.sun.enterprise.connectors.service.ConnectorService.loadResourcesAndItsRar(ConnectorService.java:133)
at
com.sun.enterprise.connectors.service.ConnectorService.checkAndLoadPool(ConnectorService.java:307)
at
com.sun.enterprise.connectors.service.ConnectorResourceAdminServiceImpl.createConnectorResource(ConnectorResourceAdminServiceImpl.java:91)
at
com.sun.enterprise.connectors.ConnectorRuntime.createConnectorResource(ConnectorRuntime.java:269)
at
com.sun.enterprise.resource.deployer.JdbcResourceDeployer.deployResource(JdbcResourceDeployer.java:107)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:84)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:432)
at javax.naming.InitialContext.lookup(InitialContext.java:392)
at javax.naming.InitialContext.lookup(InitialContext.java:392)
at foo.Activator.start(Activator.java:9)
at
org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:640)
at org.apache.felix.framework.Felix.activateBundle(Felix.java:1700)
at org.apache.felix.framework.Felix.startBundle(Felix.java:1622)
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:915)
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:902)
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.start(DirectoryWatcher.java:1027)
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.start(DirectoryWatcher.java:1013)
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.startAllBundles(DirectoryWatcher.java:1006)
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:396)
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:206)

#]

[#|2010-01-14T17:48:56.953+0530|SEVERE|glassfishv3.0|javax.enterprise.resource.resourceadapter.com.sun.enterprise.connectors.service|_ThreadID=21;_ThreadName=

{felix.fileinstall.poll=5000, service.pid=org.apache.felix.fileinstall.ec1bf2e9-d8e5-4403-bd59-45d6a604bf56, felix.fileinstall.bundles.new.start=true, felix.fileinstall.dir=/space/ss141213/software/glassfishv3/glassfish/domains/domain1/autodeploy/bundles/, service.factorypid=org.apache.felix.fileinstall, felix.fileinstall.filename=org.apache.felix.fileinstall-autodeploy-bundles.cfg, felix.fileinstall.debug=1};|RAR8061: failed to load resource-adapter-config or
RA [ __ds_jdbc_ra ],
com.sun.appserv.connectors.internal.api.ConnectorRuntimeException: Failed to
start resource adapter : Unable to find a default provider|#]

[#|2010-01-14T17:48:56.953+0530|SEVERE|glassfishv3.0|javax.enterprise.resource.resourceadapter.com.sun.enterprise.connectors.service|_ThreadID=21;_ThreadName={felix.fileinstall.poll=5000,service.pid=org.apache.felix.fileinstall.ec1bf2e9-d8e5-4403-bd59-45d6a604bf56,felix.fileinstall.bundles.new.start=true,felix.fileinstall.dir=/space/ss141213/software/glassfishv3/glassfish/domains/domain1/autodeploy/bundles/,service.factorypid=org.apache.felix.fileinstall,felix.fileinstall.filename=org.apache.felix.fileinstall-autodeploy-bundles.cfg,felix.fileinstall.debug=1}

;|RAR8060: Unable to lookup pool [ DerbyPool ],
javax.naming.NamingException: Lookup failed for '__SYSTEM/pools/DerbyPool' in
SerialContext [Root exception is javax.naming.NameNotFoundException: pools]|#]

[#|2010-01-14T17:48:56.954+0530|SEVERE|glassfishv3.0|javax.enterprise.resource.resourceadapter.com.sun.enterprise.connectors.service|_ThreadID=21;_ThreadName=

{felix.fileinstall.poll=5000, service.pid=org.apache.felix.fileinstall.ec1bf2e9-d8e5-4403-bd59-45d6a604bf56, felix.fileinstall.bundles.new.start=true, felix.fileinstall.dir=/space/ss141213/software/glassfishv3/glassfish/domains/domain1/autodeploy/bundles/, service.factorypid=org.apache.felix.fileinstall, felix.fileinstall.filename=org.apache.felix.fileinstall-autodeploy-bundles.cfg, felix.fileinstall.debug=1};|RAR6017 : Failed to get connection pool object via
JNDI lookup : DerbyPool|#]

[#|2010-01-14T17:48:56.954+0530|SEVERE|glassfishv3.0|javax.enterprise.resource.resourceadapter.com.sun.enterprise.connectors.service|_ThreadID=21;_ThreadName={felix.fileinstall.poll=5000,service.pid=org.apache.felix.fileinstall.ec1bf2e9-d8e5-4403-bd59-45d6a604bf56,felix.fileinstall.bundles.new.start=true,felix.fileinstall.dir=/space/ss141213/software/glassfishv3/glassfish/domains/domain1/autodeploy/bundles/,service.factorypid=org.apache.felix.fileinstall,felix.fileinstall.filename=org.apache.felix.fileinstall-autodeploy-bundles.cfg,felix.fileinstall.debug=1}

;|
com.sun.appserv.connectors.internal.api.ConnectorRuntimeException:
rardeployment.jndi_lookup_failed
at
com.sun.enterprise.connectors.service.ConnectorResourceAdminServiceImpl.createConnectorResource(ConnectorResourceAdminServiceImpl.java:132)
at
com.sun.enterprise.connectors.ConnectorRuntime.createConnectorResource(ConnectorRuntime.java:269)
at
com.sun.enterprise.resource.deployer.JdbcResourceDeployer.deployResource(JdbcResourceDeployer.java:107)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:84)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:432)
at javax.naming.InitialContext.lookup(InitialContext.java:392)
at javax.naming.InitialContext.lookup(InitialContext.java:392)
at foo.Activator.start(Activator.java:9)
at
org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:640)
at org.apache.felix.framework.Felix.activateBundle(Felix.java:1700)
at org.apache.felix.framework.Felix.startBundle(Felix.java:1622)
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:915)
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:902)
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.start(DirectoryWatcher.java:1027)
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.start(DirectoryWatcher.java:1013)
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.startAllBundles(DirectoryWatcher.java:1006)
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:396)
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:206)
Caused by: javax.naming.NamingException: Lookup failed for
'__SYSTEM/pools/DerbyPool' in SerialContext [Root exception is
javax.naming.NameNotFoundException: pools]
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:442)
at javax.naming.InitialContext.lookup(InitialContext.java:392)
at
com.sun.enterprise.connectors.service.ConnectorResourceAdminServiceImpl.createConnectorResource(ConnectorResourceAdminServiceImpl.java:100)
... 17 more
Caused by: javax.naming.NameNotFoundException: pools
at
com.sun.enterprise.naming.impl.TransientContext.resolveContext(TransientContext.java:252)
at
com.sun.enterprise.naming.impl.TransientContext.lookup(TransientContext.java:171)
at
com.sun.enterprise.naming.impl.TransientContext.lookup(TransientContext.java:172)
at
com.sun.enterprise.naming.impl.SerialContextProviderImpl.lookup(SerialContextProviderImpl.java:58)
at
com.sun.enterprise.naming.impl.LocalSerialContextProviderImpl.lookup(LocalSerialContextProviderImpl.java:101)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:430)
... 19 more

#]

[#|2010-01-14T17:48:56.966+0530|SEVERE|glassfishv3.0|javax.enterprise.system.std.com.sun.enterprise.v3.services.impl|_ThreadID=21;_ThreadName=

{felix.fileinstall.poll=5000, service.pid=org.apache.felix.fileinstall.ec1bf2e9-d8e5-4403-bd59-45d6a604bf56, felix.fileinstall.bundles.new.start=true, felix.fileinstall.dir=/space/ss141213/software/glassfishv3/glassfish/domains/domain1/autodeploy/bundles/, service.factorypid=org.apache.felix.fileinstall, felix.fileinstall.filename=org.apache.felix.fileinstall-autodeploy-bundles.cfg, felix.fileinstall.debug=1}

;|javax.naming.NamingException: Lookup failed for
'jdbc/__default' in SerialContext [Root exception is
javax.naming.NamingException: Unable to lookup resource : jdbc/__default [Root
exception is com.sun.appserv.connectors.internal.api.ConnectorRuntimeException:
rardeployment.jndi_lookup_failed]]
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:442)
at javax.naming.InitialContext.lookup(InitialContext.java:392)
at javax.naming.InitialContext.lookup(InitialContext.java:392)
at foo.Activator.start(Activator.java:9)
at
org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:640)
at org.apache.felix.framework.Felix.activateBundle(Felix.java:1700)
at org.apache.felix.framework.Felix.startBundle(Felix.java:1622)
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:915)
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:902)
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.start(DirectoryWatcher.java:1027)
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.start(DirectoryWatcher.java:1013)
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.startAllBundles(DirectoryWatcher.java:1006)
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:396)
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:206)
Caused by: javax.naming.NamingException: Unable to lookup resource :
jdbc/__default [Root exception is
com.sun.appserv.connectors.internal.api.ConnectorRuntimeException:
rardeployment.jndi_lookup_failed]
at
org.glassfish.javaee.services.ResourceProxy.throwResourceNotFoundException(ResourceProxy.java:116)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:88)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:432)
... 13 more
Caused by: com.sun.appserv.connectors.internal.api.ConnectorRuntimeException:
rardeployment.jndi_lookup_failed
at
com.sun.enterprise.connectors.service.ConnectorResourceAdminServiceImpl.createConnectorResource(ConnectorResourceAdminServiceImpl.java:132)
at
com.sun.enterprise.connectors.ConnectorRuntime.createConnectorResource(ConnectorRuntime.java:269)
at
com.sun.enterprise.resource.deployer.JdbcResourceDeployer.deployResource(JdbcResourceDeployer.java:107)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:84)
... 14 more
Caused by: javax.naming.NamingException: Lookup failed for
'__SYSTEM/pools/DerbyPool' in SerialContext [Root exception is
javax.naming.NameNotFoundException: pools]
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:442)
at javax.naming.InitialContext.lookup(InitialContext.java:392)
at
com.sun.enterprise.connectors.service.ConnectorResourceAdminServiceImpl.createConnectorResource(ConnectorResourceAdminServiceImpl.java:100)
... 17 more
Caused by: javax.naming.NameNotFoundException: pools
at
com.sun.enterprise.naming.impl.TransientContext.resolveContext(TransientContext.java:252)
at
com.sun.enterprise.naming.impl.TransientContext.lookup(TransientContext.java:171)
at
com.sun.enterprise.naming.impl.TransientContext.lookup(TransientContext.java:172)
at
com.sun.enterprise.naming.impl.SerialContextProviderImpl.lookup(SerialContextProviderImpl.java:58)
at
com.sun.enterprise.naming.impl.LocalSerialContextProviderImpl.lookup(LocalSerialContextProviderImpl.java:101)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:430)
... 19 more

#]


 Comments   
Comment by Sanjeeb Sahoo [ 14/Jan/10 ]

Created an attachment (id=4162)
Test case. Source code is part of the jar file

Comment by Jagadish [ 22/Jan/10 ]

Provided a fix in the trunk.

svn log -v -r 35427

https://glassfish-svn.dev.java.net/servlets/ReadMsg?list=commits&msgNo=17960

Fix should be made available in the 23-Jan-2010 nightly :
http://download.java.net/glassfish/v3.1/nightly/

I also see a 3.0.1 branch created.
I am waiting for the confirmation on whether it will be sync-ed automatically to
3.0.1 branch. If not, I will port it to the 3.0.1 branch too.

Comment by kumara [ 04/Feb/10 ]

Approved for v3.0.1

Comment by Jagadish [ 15/Feb/10 ]

FIX INFORMATION for v3.0.1

svn log -v -r 35641

https://glassfish-svn.dev.java.net/servlets/ReadMsg?list=commits&msgNo=18174

Fix will be available in GF v3.0.1 build 05.
http://download.java.net/glassfish/v3.0.1/promoted/





[GLASSFISH-11435] Weld integration breaks with weld 1.0.1 because of bad import. Created: 14/Jan/10  Updated: 17/Feb/10  Resolved: 17/Feb/10

Status: Resolved
Project: glassfish
Component/s: cdi
Affects Version/s: V3
Fix Version/s: v3.0.1

Type: Bug Priority: Major
Reporter: justinwyer Assignee: rogerk
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Text File weld_spi_fix.diff    
Issuezilla Id: 11,435

 Description   

The file WebComponentInjectionManager.java imports and uses
org.jboss.weld.BeanManagerImpl this breaks with weld 1.0.1 because this class
moves to a different package. It should rather import
javax.enterprise.inject.spi.BeanManager the SPI exposed interface which
org.jboss.weld.BeanManagerImpl implements.



 Comments   
Comment by justinwyer [ 14/Jan/10 ]

Created an attachment (id=4161)
Proposed fix.

Comment by rogerk [ 14/Jan/10 ]

Looks good. r=rogerk

Comment by rogerk [ 08/Feb/10 ]

Fix to Weld Integration WebComponentInjectionManager checked in.

Comment by jpleed3 [ 17/Feb/10 ]

Why is this issue (and a few others for that matter) targeted for v3.1? Weld
1.0.1-GA should be released within a week and it can't be used with Glassfish
v3, even with weld-integration 3.0.1-b05.

Comment by rogerk [ 17/Feb/10 ]

I think that should be targeted for 3.0.1 - oversight of not changing the target.

Comment by rogerk [ 17/Feb/10 ]

Target 3.0.1





[GLASSFISH-11426] Add documentation for "errorReportValve" virtual server property Created: 12/Jan/10  Updated: 26/May/10  Resolved: 26/May/10

Status: Resolved
Project: glassfish
Component/s: docs
Affects Version/s: V3
Fix Version/s: v3.0.1

Type: Bug Priority: Major
Reporter: jluehe Assignee: Mike Fitch
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Sun


Issuezilla Id: 11,426
Tags: v3_0_1_approved

 Description   

Name: errorReportValve

Synopsis: The fully qualified class name of the virtual server's custom valve
implementation for producing default error pages for any of the applications
deployed on the virtual server, or the empty string if the default error page
mechanism should be disabled for the virtual server

Default: org.apache.catalina.valves.ErrorReportValve

Support for this property was added in v3. See
https://glassfish.dev.java.net/issues/show_bug.cgi?id=7418 for motivation



 Comments   
Comment by jluehe [ 12/Jan/10 ]

To make it clear, "errorReportValve" is a <property> of <virtual-server> in
domain.xml

Comment by Paul Davies [ 12/Jan/10 ]

Reassigned to junesm to update the Domain File Format Reference.

Added dixiep and chaase3 to the interest list and the man pages and online help
might also require updting.

Comment by Rebecca Parks [ 13/Jan/10 ]

Added the errorReportValve property to the Domain File Format Reference with the
following description:

Specifies a fully qualified class name of a custom valve that produces default
error pages for applications on this virtual server. Specify an empty string to
disable the default error page mechanism for this virtual server.

Reassigning to Paul, who can reassign appropriately when bundled docs are
updated for an update release.

Comment by Rebecca Parks [ 13/Jan/10 ]

Changing status to STARTED

Comment by Kim Haase [ 13/Jan/10 ]

Added the property to the "Properties Specific to Virtual Servers" online help
topic, using the same language as in the DFFR.

Comment by Paul Davies [ 08/Apr/10 ]

Set target milestone to 3.0.1. Reassigned issue to oncered.

Comment by Paul Davies [ 09/Apr/10 ]

Approved in email by Jerome.

Comment by Mike Fitch [ 26/May/10 ]

HTML committed to GF docs trunk at revision 37162.

Comment by Mike Fitch [ 26/May/10 ]

Fix available beginning in nightly build of May 25, 2010.





[GLASSFISH-11409] No response after executing 'asadmin freeze-transaction-service' after in-doubt transaction Created: 07/Jan/10  Updated: 05/Mar/10  Resolved: 05/Mar/10

Status: Resolved
Project: glassfish
Component/s: jts
Affects Version/s: V3
Fix Version/s: v3.0.1

Type: Bug Priority: Major
Reporter: tak09 Assignee: marina vatkina
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Text File jts-freeze.patch     Text File jts-freeze.patch     Zip Archive testprogram.zip     Zip Archive threaddumps.zip     Text File transaction-indoubt-observations.txt    
Issuezilla Id: 11,409
Tags: v3_0_1_approved

 Description   

Problem
----------
If 'asadmin freeze-transaction-service' is executed after an in-doubt
transaction, there is no message or response for 10 minutes. After 10 minutes,
it terminates with the timeout error message.

Software version
-----------------
Glassfish Server: Glassfish v3 build 74.2, Windows XP
Oracle Database Server: Oracle 11g Release 1 (11.1.0.6.0), Windows Server 2003

Setting up Oracle database
----------------------------
1. Create two instances of Oracle Database.
For example, I created instances called 'test1' and 'test2' using the Oracle
Database Configuration Assistant.
2. Login to Oracle as sysdba and execute user.sql to create a user on 'test1'
instance.
C:\> sqlplus /@test1 as sysdba
SQL> @c:\sql\user.sql ;
SQL> exit;
3. Login to Oracle as the new user and execute create.sql to create tables on
'test1' instance.
C:\> sqlplus APP/APP@test1
SQL> @c:\sql\create.sql ;
SQL> exit;
4. Repeat the same step on 'test2' instance.
C:\> sqlplus /@test2 as sysdba
SQL> @c:\sql\user.sql ;
SQL> exit;
5. Repeat the same step on 'test2' instance.
C:\> sqlplus APP/APP@test2
SQL> @c:\sql\create.sql ;
SQL> exit;

Setting up Oracle JDBC driver
------------------------------------
1. Download a suitable Oracle JDBC driver from this URL. 'ojdbc6.jar' is used
for my environment.
http://www.oracle.com/technology/software/tech/java/sqlj_jdbc/htdocs/jdbc_111060.html
2. Copy ojdbc6.jar to glassfish lib directory. (ie. C:\glassfishv3\glassfish\lib)

Creating JDBC pools
------------------
1. Open the CreateOracleJDBC.bat and update the Oracle database server IP
address according to your environment.
2. Start glassfish
3. Execute the CreateOracleJDBC.bat to create JDBC Resources and Connection Pools.

Deploying EJB and creating client stubs
----------------------------------------
1. Execute the deploy.bat to deploy the ear file to create stubs in the client
directory.

Executing the test application to create in-doubt transaction
--------------------------------------------------------------
1. Execute run.bat
2. The server program waits for 60 seconds while the database is in prepared state.
FailureInducer.setWaitPoint(FailureInducer.PREPARED, 60);
3. Shutdown one of the Oracle instance while it is waiting and simulate the
problem.
SQL> shutdown abort;
4. The test program exits with exceptions and the transaction is in-doubt status.

Checking the Oracle database status
-----------------------------------
1. Start up the Oracle database instance that you shutdown previously.
2. Log in to the Oracle database / as sysdba
3. Check the transaction status. You would see the state is still 'prepared'.
SQL> select local_tran_id, state, fail_time from dba_2pc_pending;

Freezing transaction service (Reproducing the problem)
--------------------------------------------------------
1. Execute freeze transaction service, but no response from the command.
C:\>asadmin --user admin --passwordfile password.txt freeze-transaction-service

2. After 10 minutes, the command terminates with the following timeout error.

I/O Error: Read timed out
Command freeze-transaction-service failed.

Force committing the in-doubt transaction
----------------------------------------------
The ORA-01591 error is displayed when updating the database with prepare status.
You need to force commit before executing the run.bat again.

1. Log in / as sysdba
C:\> sqlplus /@test1 as sysdba
SQL> commit force 'local_tran_id';
(Use the local_tran_id found in the previous step.)

Note
------
I tested this issue using Derby as a back-end database, but the problem did not
reproduce with Derby. Derby handles in-double transaction differently. Please
use Oracle for testing.



 Comments   
Comment by tak09 [ 07/Jan/10 ]

Created an attachment (id=4149)
test program

Comment by marina vatkina [ 08/Jan/10 ]

Which GF version are you using?

asadmin freeze-transaction-service doesn't access the database, but allows to
rollback in-flight transactions. If you want to recover in-flight transactions,
you need to use 'asadmin recover-transactions'
(http://docs.sun.com/app/docs/doc/820-7701/recover-transactions-1?a=view)

Comment by tak09 [ 10/Jan/10 ]

Thank you very much.
Glassfish version is v3 build 74.2