<< Back to previous view

[GLASSFISH-16728] [UB]There is no support for Kerberos in AIX Environment.Needs to documented. Created: 24/May/11  Updated: 06/Jul/11  Resolved: 06/Jul/11

Status: Resolved
Project: glassfish
Component/s: docs, web_services
Affects Version/s: None
Fix Version/s: 3.1.1

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

AIX, GF 3.1.1, Metro 2.1.1


Tags: 3_1-next_release-note-added 3_1-next_release-notes
Participants: Paul Davies, Rebecca Parks, Scott Fordin and Sreekanth

 Description   

Kerberos is not supported in Metro / Glassfish in AIX environment.Once there was a plan to support for metro 2.0 and later it was dropped.

Here are the issues :

1. We used a lot of Sun JDK copied code for supporting Kerberos on JDK 5 and 6
2. For JDK 7 again we are using an API that is proprietary to Sun JDK

This needs to be documented in release docs.Hence filing this issue.



 Comments   
Comment by Scott Fordin [ 31/May/11 10:14 AM ]

Reassigning to Paul Davies.

Comment by Paul Davies [ 21/Jun/11 02:15 AM ]

Reassigned to Rebecca, who is responsible for the Release Notes.

Comment by Rebecca Parks [ 21/Jun/11 01:39 PM ]

This issue is no longer appearing on my dashboard. Anyone know why?

Comment by Rebecca Parks [ 06/Jul/11 09:40 PM ]

Added to the 3.1.1 Release Notes section "Restrictions and Deprecated Functionality":

No Support for Kerberos on AIX

GlassFish Server 3.1.1 does not support Kerberos on the AIX platform.

For the complete report about this issue, see <link GLASSFISH-16728>.





[GLASSFISH-16592] Capture 3.1.1 issues for inclusion in GF3.1.1 Release Notes Created: 10/May/11  Updated: 06/Jun/11  Due: 19/Jun/20  Resolved: 06/Jun/11

Status: Resolved
Project: glassfish
Component/s: docs
Affects Version/s: 3.1.1
Fix Version/s: 3.1.1_b06

Type: Task Priority: Major
Reporter: Scott Fordin Assignee: Scott Fordin
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1-next_release-notes 3_1-next_release-note-added
Participants: scatari and Scott Fordin

 Description   

Create new subsection in the 3.1-3.1.1 Release Notes for JIRA issues specifically flagged with the 3_1-next_release-notes tag.



 Comments   
Comment by Scott Fordin [ 24/May/11 08:42 AM ]

Section created and 3.1-3.1.1 Release Notes restructured accordingly. Also created 3_1-next_release-notes, 3_1-next_release-note-added, and 3_1-next_need-more-info JIRA tags to capture 3.1.1 RN issues moving forward. These were the primary purposes for creating GLASSFISH-16592. Now that the new section has been created and seeded with an issue, and the JIRA tags created, this GLASSFISH-16592 umbrella issue is no longer necessary.

Comment by scatari [ 06/Jun/11 04:16 PM ]

Fixing the target version to include the correct build number.





[GLASSFISH-16491] [UB]Additional Instructions for setting up LB on OEL+ OHS 64-bit to be included Created: 27/Apr/11  Updated: 07/Mar/12

Status: In Progress
Project: glassfish
Component/s: docs, load_balancer
Affects Version/s: 3.1.1
Fix Version/s: not determined

Type: Bug Priority: Major
Reporter: Jothir Ganesan Assignee: Mike Fitch
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

OEL + OHS 64-bit + Glassfish lb plugin


Issue Links:
Related
is related to GLASSFISH-17806 [UB]Docs need to be corrected to refl... Open
Tags: 3_1-next_need-more-info
Participants: Jothir Ganesan, kshitiz_saxena, Mike Fitch, Scott Fordin and Tom Mueller

 Description   

I configured lb plugin on 64-bit OHS according to the instructions given in
http://download.oracle.com/docs/cd/E18930_01/html/821-2426/gktke.html

When I start OHS, the https listeners of the instances are being detected as unhealthy.

Need to add the following to bin/apachectl script:
NSS_STRICT_NOFORK=DISABLED; export NSS_STRICT_NOFORK



 Comments   
Comment by Scott Fordin [ 18/May/11 02:05 PM ]

We clearly state at the beginning of "Configuring Web Servers for HTTP Load Balancing" chapter in the HA Admin Guide that, "The Loadbalancer Plug-In does not support web servers running in 64–bit mode, except for Microsoft IIS with 32–bit application support enabled." We also state in the "Configuring Oracle HTTP Server" instructions in that same chapter that, "These procedures apply to Oracle HTTP Server 11.1.1.4+ (32–bit) only. Other versions of Oracle HTTP Server are not supported." So I guess I'm confused. Do we now want to say that we support 64-bit? If so, this will require changes in several locations, not just this one bit in one particular step.

Comment by Scott Fordin [ 31/May/11 10:14 AM ]

Reassigning to Paul Davies.

Comment by kshitiz_saxena [ 14/Jul/11 08:29 AM ]

This issue is not specific to 64 bit OHS. This change is generic. Please capture is under point 3.

Comment by Mike Fitch [ 19/Jul/11 09:08 PM ]

Information added as per Description

Comment by Tom Mueller [ 07/Mar/12 02:47 PM ]

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





[GLASSFISH-16490] [UB]Additional Instructions for setting up LB on Solaris 10 Sparc + apache 64-bit to be included Created: 27/Apr/11  Updated: 07/Mar/12

Status: Open
Project: glassfish
Component/s: docs, load_balancer
Affects Version/s: 3.1.1
Fix Version/s: not determined

Type: Bug Priority: Major
Reporter: Jothir Ganesan Assignee: Mike Fitch
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Solaris 10 Sparc + Apache 64-bit with OpenSSl


Issue Links:
Related
is related to GLASSFISH-17806 [UB]Docs need to be corrected to refl... Open
Tags: 3_1-next_need-more-info
Participants: Jothir Ganesan, kshitiz_saxena, Mike Fitch, Scott Fordin and Tom Mueller

 Description   

Configure openssl as below :
1. ./Configure shared --openssldir=<openssl-install-dir> --prefix=<openssl-install-dir> solaris64-sparcv9-cc
2. make
3. make install

Configure Apache as below:
export CFLAGS="-m64"
export LDFLAGS="-m64"
export LD_LIBRARY_PATH=/usr/lib/64:/usr/sfw/lib/64
use sun studio compiler instead of gcc for 64-bit:
1../configure --with-mpm=worker --with-included-apr --with-ssl=/export/kshitiz/64bit/openssl/install --prefix=/export/kshitiz/64bit/apache2.2/install --enable-ssl --enable-so CC=/usr/dist/share/sunstudio_sparc/SUNWspro/bin/cc

2. make
3. make install



 Comments   
Comment by Scott Fordin [ 18/May/11 02:09 PM ]

Similar comment to http://java.net/jira/browse/GLASSFISH-16491, we clearly state at the beginning of "Configuring Web Servers for HTTP Load Balancing" chapter in the HA Admin Guide that, "The Loadbalancer Plug-In does not support web servers running in 64–bit mode, except for Microsoft IIS with 32–bit application support enabled." We also state in the "Configuring Apache HTTP Server" instructions in that same chapter that, "The Loadbalancer Plug-In supports Apache HTTP Server 2.2.x (32–bit)." So I guess I'm confused. Do we now want to say that we support 64-bit? If so, this will require changes in several locations, not just this one bit in one particular step.

Comment by Scott Fordin [ 31/May/11 10:14 AM ]

Reassigning to Paul Davies.

Comment by kshitiz_saxena [ 14/Jul/11 08:32 AM ]

In 3.1.1, we support 64 bit load-balancer plugin. Please refer to issue GLASSFISH-16905.

Comment by Mike Fitch [ 19/Jul/11 09:17 PM ]

Pushing this issue to "future release". For 3.1.1, description of 64-bit LBP support is limited to the Release Notes.

Comment by Tom Mueller [ 07/Mar/12 02:47 PM ]

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





[GLASSFISH-16385] Firefox 4.0 does not work for the Admin Console Targeting dialogs Created: 19/Apr/11  Updated: 25/Jul/11  Due: 19/Apr/11  Resolved: 19/Apr/11

Status: Resolved
Project: glassfish
Component/s: docs
Affects Version/s: 3.1
Fix Version/s: None

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

File Attachments: JPEG File ff5_gf_console_issue.jpg    
Tags: 3_1-release-note-added 3_1-release-notes
Participants: Anissa Lam, Scott Fordin and Thorsten Gilfert

 Description   

Firefox 4.0 does not work for the Administration Console Targeting dialogs. All other web pages display correctly.

"Targeting dialogs" refer to those dialogs in which two adjacent columns of options are displayed, one for "Available Targets" and the other for "Selected Targets." A user can select the desired options and move them from one column to other.

For example, such a dialog can be displayed by navigating to the Resources->JDBC->JDBC Resources-><resource-name>->Target page and then clicking Manage Targets. The resulting Manage Resource Targets page will not be displayed correctly in Firefox 4.0. Specifically, the CSS page formatting is not rendered, leaving just plain text and no layout.

Workaround

None. This is a rendering issue in Firefox 4.0. Other browsers and earlier versions of Firefox do not exhibit this behavior.



 Comments   
Comment by Scott Fordin [ 19/Apr/11 01:23 PM ]

Added issue to 3.1 Release Notes.

Comment by Anissa Lam [ 18/Jul/11 08:06 PM ]

FF4 is EOL'ed and is not a supported browser.

FF5 has replaced FF4, and we have tested Console works fine in FF5.

Comment by Thorsten Gilfert [ 25/Jul/11 07:47 AM ]

I get the same issue with FireFox 5 (Win Vista) too. See attached screenshot.





[GLASSFISH-16349] [UB]Better document max-pool-size in the EJB setting Created: 12/Apr/11  Updated: 06/Jun/11  Resolved: 20/May/11

Status: Resolved
Project: glassfish
Component/s: docs
Affects Version/s: 3.1
Fix Version/s: 3.1.1_b06

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

Tags:
Participants: marina vatkina, scatari and Scott Fordin

 Description   

In Application Development Guide-> Using Enterprise JavaBeans Technology-> Value Added Features-> Pooling and Caching, there is a note about steady-pool-size but not max-pool-size: "... parameter does not necessarily guarantee that no more than steady-pool-size instances exist at a given time. ...."

It probably should say max-pool-size. Neither one is a bound value - they are rather the pool conditions (i.e. no more than max-pool-size instances can be in a pool at any given time, and when the pool is steady, it's size is determined by the steady-pool size variable).

When document is updated, please send for review to Mahesh and me.



 Comments   
Comment by Scott Fordin [ 19/May/11 02:04 PM ]

The subsection in which the paragraph in question is located begins, "One of the most important parameters of GlassFish Server pooling is steady-pool-size. When steady-pool-size is set to greater than 0, the container not only pre-populates the bean pool with the specified number of beans, but also attempts to ensure that this number of beans is always available in the free pool. This ensures that there are enough beans in the ready to serve state to process user requests."

The item to which you refer in this issue is the first sentence in the subsequent paragraph. The problem I'm having here is that most of this entire subsection talks about steady-pool-size. Are you saying it's sufficient to replace "steady-pool-size" with "max-pool-size" in just the one instance you cite? Or must the entire subsection be recast to focus on max-pool-size?

Comment by marina vatkina [ 19/May/11 02:51 PM ]

May be we should mention both in the 2nd par?

Comment by Scott Fordin [ 20/May/11 02:33 PM ]

After following up with Marina, we reworked the subsection to read as follows:

---------------------------------- Snip ----------------------------------
One of the most important parameters for GlassFish Server pooling is steady-pool-size. When steady-pool-size is set to a value greater than 0, the container not only pre-populates the bean pool with the specified number of beans, but also attempts to ensure that this number of beans is always available in the free pool. This ensures that there are enough beans in the ready-to-serve state to process user requests.

Note that the steady-pool-size and max-pool-size parameters only govern the number of instances that are pooled over a long period of time. They do not necessarily guarantee that the number of instances that may exist in the JVM at a given time will not exceed the value specified by max-pool-size. For example, suppose an idle stateless session container has a fully-populated pool with a steady-pool-size of 10. If 20 concurrent requests arrive for the EJB component, the container creates 10 additional instances to satisfy the burst of requests. The advantage of this is that it prevents the container from blocking any of the incoming requests. However, if the activity dies down to 10 or fewer concurrent requests, the additional 10 instances are discarded.

Another parameter, pool-idle-timeout-in-seconds, allows the administrator to specify the amount of time a bean instance can be idle in the pool. When pool-idle-timeout-in-seconds is set to greater than 0, the container removes or destroys any bean instance that is idle for this specified duration.
---------------------------------- Snip ----------------------------------

Comment by scatari [ 06/Jun/11 04:28 PM ]

Updating the fix in version to correct build #.





[GLASSFISH-16211] restart required not shown after calling set-log-attributes Created: 14/Mar/11  Updated: 10/Apr/11  Resolved: 10/Apr/11

Status: Closed
Project: glassfish
Component/s: logging
Affects Version/s: 3.1
Fix Version/s: 3.1.1_b01

Type: Bug Priority: Major
Reporter: Anissa Lam Assignee: naman_mehta
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: Anissa Lam, naman_mehta and Scott Fordin

 Description   

The following is in recent email discussion from Naman

"As per the logging side, if user changes any attributes needs restart of the server as it's picked by the start up code. Any change in the log level doesn't need restart. I already sent this comment when I reviewed logging documentation and man pages.

So if you use the logging command like set-log-levels or rotate-log, restart is not required. If you use set-log-attributes command needs restart of the server.

Regards,
Naman
"
However using the CLI set-log-attributes command, or changing log attributes in the GUI (GUI code eventually calls set-log-attributes), I don't see the server status change to restart required. This needs to be fixed by the logging component.



 Comments   
Comment by Scott Fordin [ 18/Mar/11 01:12 PM ]

Added topic under "Restart Required" umbrella issue (http://java.net/jira/browse/GLASSFISH-16040) in 3.1 Release Notes.

Comment by naman_mehta [ 21/Mar/11 11:06 PM ]

Fixed the same. It shows restart required when user changes and attributes from logger settings page.





[GLASSFISH-16210] Setting a property on individual http-listener fails Created: 14/Mar/11  Updated: 15/Mar/11  Resolved: 15/Mar/11

Status: Resolved
Project: glassfish
Component/s: docs
Affects Version/s: 3.1
Fix Version/s: 3.1

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

Tags:
Participants: ramapulavarthi, Scott Fordin and Tom Mueller

 Description   

Following the documentation http://download.oracle.com/docs/cd/E18930_01/html/821-2426/abdhs.html to set authPassThrough property on individual listener fails, where as it succeeds on the http-service.
Either there is a bug in the docs or in the command implementation.
Docs say
-----------------------
To set the authPassthroughEnabled property on all HTTP/HTTPS listeners, use the following command:

asadmin> set cluster-name-config.http-service.property.authPassthroughEnabled=true

To set it on an individual listener, use the following command:

asadmin> set cluster-name-config.http-service.http-listener.listener-name.property.authPassthroughEnabled=true
-----------------------
See the following execution to see the error.

rama@shepherd:~/glassfish3/glassfish/bin$ ./asadmin list-clusters
houndpac running
Command list-clusters executed successfully.
rama@shepherd:~/glassfish3/glassfish/bin$ ./asadmin list-http-listeners
http-listener-1
http-listener-2
admin-listener
Command list-http-listeners executed successfully.
rama@shepherd:~/glassfish3/glassfish/bin$ ./asadmin
Use "exit" to exit and "help" for online help.
asadmin> set houndpac-config.http-service.http-listener.http-listener-1.property.authPassthroughEnabled=true
remote failure: No configuration found for houndpac-config.http-service.http-listener.http-listener-1.property.authPassthroughEnabled
Command set failed.
asadmin> set houndpac-config.http-service.property.authPassthroughEnabled=true
hound2:
houndpac-config.http-service.property.authPassthroughEnabled=true

hound1:
houndpac-config.http-service.property.authPassthroughEnabled=true

houndpac-config.http-service.property.authPassthroughEnabled=true
Command set executed successfully.
asadmin>



 Comments   
Comment by Tom Mueller [ 15/Mar/11 07:24 AM ]

In this case, the documentation is incorrect. To set a property on a specific HTTP listener in 3.x, the command is:

asadmin set cluster-name-config.network-config.network-listeners.network-listener.http-listener-1.property.authPassthroughEnabled=true

Changing this to be a docs bug.

Comment by Scott Fordin [ 15/Mar/11 04:08 PM ]

Made correction in HA Admin Guide.





[GLASSFISH-16183] *-resource-ref* man pages: Examples have deprecated syntax Created: 09/Mar/11  Updated: 30/Jun/11  Resolved: 30/Jun/11

Status: Resolved
Project: glassfish
Component/s: docs
Affects Version/s: 3.1_b43
Fix Version/s: 3.1.1

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

Issue Links:
Dependency
blocks GLASSFISH-16178 Umbrella bug. For several *ref comman... Resolved
Tags: 3_1-exclude
Participants: Paul Davies and Scott Fordin

 Description   

Build 43.

The syntax in the examples in the man pages for create-resource-ref, list-resource-refs, and delete-resource-ref is deprecated. These examples include the asadmin options --user and passwordfile in a multimode session after the subcommand:

asadmin> create-resource-ref --user admin
--passwordfile passwords.txt --target Cluster1 jms/Topic
Command create-resource-ref executed successfully.
asadmin> list-resource-refs --user admin
--passwordfile passwords.txt
jms/Topic
Command list-resource-refs executed successfully.
asadmin> delete-resource-ref --user admin2
--passwordfile passwords.txt --target NewServer jms/Topic
Command delete-resource-ref executed successfully.

When these examples are run, the asadmin utility displays a message that the syntax is deprecated.

To fix, delete the asadmin options from the examples.



 Comments   
Comment by Scott Fordin [ 15/Mar/11 04:15 PM ]

Will make fix in 3.2 man pages.

Comment by Paul Davies [ 27/May/11 09:58 AM ]

Under consideration for fixing in 3.1.1.

Comment by Scott Fordin [ 31/May/11 10:14 AM ]

Reassigning to Paul Davies.

Comment by Paul Davies [ 30/Jun/11 08:48 PM ]

Fix committed in revision 47759.





[GLASSFISH-16177] For: list-file-users, list-log-attributes, list-jacc-providers, list-jndi-resources --help wrongly describes: --target. Created: 08/Mar/11  Updated: 11/Jul/11  Resolved: 11/Jul/11

Status: Closed
Project: glassfish
Component/s: docs
Affects Version/s: 3.1_b43
Fix Version/s: 3.1.1

Type: Bug Priority: Major
Reporter: easarina Assignee: kevinmcd
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: easarina, kevinmcd, kumarjayanti, Paul Davies and Scott Fordin

 Description   

Build 43. Solaris 10 Sparc. Executed:

asadmin <commnd_name> --help for the follow commands:
list-file-users
list-log-attributes
list-jacc-providers
list-jndi-resources

For these commnds asadmin <commnd_name> --help returned an info that exists:

[--target target] option. But really the attempt to use --target returned such error message, for example:

asadmin list-jacc-providers --target c1
Invalid option: --target
Usage: asadmin [asadmin-utility-options] list-jacc-providers
[?|-help[=<help(default:false)>]] [target]
Command list-jacc-providers failed

Also for list-jndi-resources the command: asadmin list-jndi-resources -help returns: [targetoperand]. What does it mean? For all other commnds this is simple: [target].



 Comments   
Comment by kumarjayanti [ 08/Mar/11 08:42 PM ]

The usage string for list-file-users shows the following correct usage :

$ ./asadmin list-file-users -lX
Invalid option: l
Usage: asadmin [asadmin-utility-options] list-file-users
[--authrealmname <authrealmname>] [?|-help[=<help(default:false)>]]
[target]
Command list-file-users failed.

Comment by kumarjayanti [ 08/Mar/11 08:43 PM ]

same for list-jacc-providers

./asadmin list-jacc-providers -lx
Invalid option: l
Usage: asadmin [asadmin-utility-options] list-jacc-providers
[?|-help[=<help(default:false)>]] [target]
Command list-jacc-providers failed.

Comment by easarina [ 08/Mar/11 08:46 PM ]

For all these commnds the usage string gave a correct info, but --help gave wrong information.

Comment by Scott Fordin [ 15/Mar/11 04:18 PM ]

Will make fix to 3.2 man pages.

Comment by Paul Davies [ 27/May/11 10:01 AM ]

Under consideration for fixing in 3.1.1.

Comment by Scott Fordin [ 31/May/11 10:15 AM ]

Reassigning to Paul Davies.

Comment by Paul Davies [ 07/Jun/11 02:31 PM ]

Reassigned to security writer. Kevin, as the fix is the same, please also fix the man pages affected that are not security related.

Comment by kevinmcd [ 22/Jun/11 03:12 PM ]

I removed the --target option usage and added target as an operand for the following man pages: list-file-users, list-log-attributes, and list-jacc-providers. (Paul Davies also changed list-jndi-resources as part of GLASSFISH-15875.)

However, I have a question about the allowable values for target. From testing these commands, it looks like all four of the commands allow these values:

server_name (The default value is server.)
instance_name
configuration_name
cluster_name

Is this correct?

Comment by kevinmcd [ 24/Jun/11 01:38 PM ]

Kumar answered/confirmed query via email, changes made as indicated. Will update status of the bug when updated manpage available in build.

Comment by kevinmcd [ 11/Jul/11 08:57 PM ]

Change appears in svn revision 47759, which I checked in the nightly build of 07-Jul-2011.





[GLASSFISH-16160] Document setup for automatic EJB Timer migration in a cluster Created: 04/Mar/11  Updated: 21/Apr/11  Resolved: 16/Mar/11

Status: Resolved
Project: glassfish
Component/s: docs
Affects Version/s: 3.1
Fix Version/s: None

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

Tags:
Participants: marina vatkina and Scott Fordin

 Description   

To enable automatic EJB Timer migration upon a clustered instance failure (crash), the delegated transaction recovery should be enabled in a cluster (see Transaction Service for details).

Timer migration after the planned clustered instance shutdown is always enabled



 Comments   
Comment by Scott Fordin [ 16/Mar/11 07:04 PM ]

Not a whole lot of information provided in this issue, so I'm hoping I've captured what you're looking for. I added some explanatory text and a new subtask to the Migrating EJB Timers section in the HA Admin Guide.

Comment by marina vatkina [ 16/Mar/11 07:11 PM ]

It's available out of the box. Why would it be documented only in HA?

Comment by Scott Fordin [ 17/Mar/11 02:43 PM ]

Well, because that's where the section titled "Migrating EJB Timers" is located. Is there a different or additional location in which you'd like to see it documented?

Comment by marina vatkina [ 17/Mar/11 03:46 PM ]

Can we add a ref to it from the EJB Timer Service chapter?

Comment by Scott Fordin [ 21/Apr/11 11:47 AM ]

Okay, added a reference to the HAAG Migrating EJB Timers section from the EJB Timer Service chapter.





[GLASSFISH-16159] asupgrade fails without internet connection Created: 04/Mar/11  Updated: 14/Mar/12  Resolved: 04/Mar/11

Status: Resolved
Project: glassfish
Component/s: upgrade_tool
Affects Version/s: 3.1
Fix Version/s: 3.1.1_b01, 4.0_b37

Type: Bug Priority: Major
Reporter: Bobby Bissett Assignee: Bobby Bissett
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

File Attachments: File gf-16159.diff    
Tags: 3_1-next 3_1-release-note-added 3_1-release-notes 3_1-upgrade
Participants: Bobby Bissett, Scott Fordin and Snjezana Sevo-Zenzerovic

 Description   

Without an internet connection, the upgrade tool fails while trying to parse the version out of the source domain.xml. The failure is here in UpgradeUtils.java:

/*

  • We don't need to validate the xml document now as that is the
  • job of the upgrade code in the application server. We're only
  • interested in the version information here, and if that is
  • somehow wrong then the upgrade process will fail downstream
  • as the document is parsed into serverbeans objects.
    */
    public Document getDomainDocumentElement(String domainFileName) {
    DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
    factory.setNamespaceAware(true);
    Document resultDoc = null;
    try { DocumentBuilder builder = factory.newDocumentBuilder(); resultDoc = builder.parse(new File(domainFileName)); } catch (Exception ex)
    Unknown macro: { logger.log(Level.WARNING, stringManager.getString("upgrade.common.could_not_create_doc", new Object [] {domainFileName, ex.toString()})); }

    return resultDoc;
    }

Example error:

Could not create xml document object from file name /home/oracle/SUNWappserver/domains/domain1/config/domain.xml due to: java.net.UnknownHostException: www.sun.com

The fix for this is simple – what's bad is that this code hasn't changed since the initial commit in the v3 workspace, and no one has reported it till now (though GLASSFISH-14951 came close). We should fix this for any 3.1.next release.



 Comments   
Comment by Bobby Bissett [ 04/Mar/11 12:38 PM ]

The workaround is easy:

1. Copy source domain to the target domains directory (first rename the 3.1 domain if it has the same name as the one to be upgraded).
2. "asadmin start-domain --upgrade <domainname>"

Comment by Bobby Bissett [ 04/Mar/11 01:44 PM ]

Patch, take 1.

Comment by Bobby Bissett [ 04/Mar/11 02:18 PM ]

This is fixed in revision 45411.

Comment by Scott Fordin [ 15/Mar/11 10:42 AM ]

Does this still need to be included in the 3.1 Release Notes?

Comment by Bobby Bissett [ 15/Mar/11 11:05 AM ]

Thanks for checking. I guess it probably should include that you can run into this when using the upgrade tool with a 2.x domain and no internet connection. Let me know if you want me to file a separate issue or something.

Comment by Scott Fordin [ 15/Mar/11 11:30 AM ]

Ah, I can see where this could start to get messy. Two questions: 1) Should this information be included in the Upgrade Guide proper rather than the Release Notes? For example, it go in the Correcting Potential Upgrade Problems section (http://download.oracle.com/docs/cd/E18930_01/html/821-2437/gkrfh.html) 2) More messy, does this issue not have implications for performing closed network upgrades, as described in http://download.oracle.com/docs/cd/E18930_01/html/821-2416/gjcya.html?

I suppose I can just add the topic to Release Notes, but the closed network upgrade bit concerns me. Is there something I'm missing that makes this issue moot in closed network upgrade context? I mean, a user could copy the source domain to the target domain, as you state in the workaround, but would this workaround be necessary when the repositories are configured to be local?

Comment by Snjezana Sevo-Zenzerovic [ 15/Mar/11 12:10 PM ]

As far as I can tell we are OK when it comes to closed network upgrade section since there we tell user to run 'asadmin start-domain --upgrade' command which is not affected by this...

This affects only the scenario where user has side-by-side installations and runs 'upgradetool' to upgrade domain config. So, closed network updates (and regular updates) which upgrade the domain config "in place" using asadmin flag should be fine. It doesn't matter if repositories are local or remote.

Comment by Bobby Bissett [ 16/Mar/11 04:53 AM ]

Thanks Snjezana – I didn't get to this yesterday. I agree that we're ok on the closed-network upgrade/update. In fact, we're fine on any update since this only affects the case of upgrading from a 2.X domain. Only 2.X domains have a schema in them, and the stupid stupid stupid code in the upgrade tool tries to check that schema when it parses the domain (and it's only parsing it in order to check a version, nothing else).

So this only affects the internal version checking code in the tool, and doesn't apply to an actual upgrade at all. The "asadmin start-domain --upgrade" workaround is unaffected. To answer Scott's big question, this should probably be in the "correcting potential..." section, as it may be fairly common. (This isn't technically an upgrade problem, but that's irrelevant.) There could be a lot of people doing an upgrade from 2.X internally, and it would be good if they don't have to hunt for this info. Scott, let me know if there's something else you'd like me to do on this.

I will be so happy if/when we drop the upgrade tool for 3.2.

Comment by Scott Fordin [ 08/Apr/11 03:55 PM ]

Added topic to 3.1 Upgrade Guide.

Comment by Scott Fordin [ 13/Apr/11 11:24 AM ]

Also added issue to 3.1 Release Notes.





[GLASSFISH-16153] Admin GUI hangs on first access after installation on some Solaris Server Hardware. Created: 04/Mar/11  Updated: 07/Apr/11  Resolved: 04/Mar/11

Status: Resolved
Project: glassfish
Component/s: admin_gui
Affects Version/s: 3.1_b43
Fix Version/s: 3.1.1_b01

Type: Bug Priority: Major
Reporter: tecknobabble Assignee: sirajg
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

File Attachments: File prtfru    
Tags: 3_1-next 3_1-release-note-added 3_1-release-notes
Participants: Anissa Lam, Scott Fordin, sirajg and tecknobabble

 Description   

This has been logged twice internally by the support organization in different Geos after performing installations of GF 3.1 on Solaris servers (i.e. bigger than your under-the-desk workstation).

Please refer to defects 7023434 and 7023307 for additional detail.

The problem is that during the generation of the registration page, if the SolarisSystemEnvironment.getSNViaPrtfruX() method is called, then if the output from the prtfru -x command is significant (a good sized server could output over 3000 lines/150Kbytes) then the page generation will hang.

The problem is the SystemEnvironment.getCommandOutput() implementation. This simply forks a process and waits for it to complete, without considering that the command might produce enough output to fill its standard out / standard error buffers, which would lead to the command being blocked until the buffers are drained:

ProcessBuilder pb = new ProcessBuilder(command);
p = pb.start();
p.waitFor();

This is not good. What the end user sees is the initial "Admin Console" loading screen, which is then replaced will a blank white screen and the browser hangs indefinitely. The only way to continue is to kill the prtfru command that is hung.

The solution is already available in the code base, and would be to reuse the com.sun.enterprise.universal.process.ProcessStreamDrainer:

ProcessBuilder pb = new ProcessBuilder(command);
p = pb.start();
psd = ProcessStreamDrainer.save("RegEnvCommandProcess", p);
return psd.getOutString();



 Comments   
Comment by Anissa Lam [ 04/Mar/11 08:50 AM ]

sounds like we are generating the registration.jsf during console initialization, maybe we should move the code to till user press the 'GlassFish Registration' button in the common task page.
Siraj, do we have workaround for this ? maybe a way to stop this generation from happening ?

Comment by sirajg [ 04/Mar/11 09:32 AM ]

A fix has been checked into the trunk, so that the registration html generation happens when the user presses the register button. There are three work arounds :

Workaround 1 :

kill the process running prtfru, for example:

  1. ptree `cat /path/to/install-dir/glassfish/domains/your-domain-name/config/pid`
    20365 /usr/jdk/jdk1.6.0_23/bin/java -cp /path/to/install-dir/glassfish/modules/glass
    20385 /usr/sbin/prtfru
  2. kill -9 20385

Workaround 2:
Prior to logging into the DAS for the first time run:

Make the directory <install-dir>/glassfish/lib/registration/ read-only - i.e. chmod -w <install-dir>/glassfish/lib/registration/
This will result in the registration file not being generated. Registration option will not be displayed.

Workaround 3:

Prior to logging into the DAS for the first time run:

touch <install-dir>/glassfish/lib/registration/registration.html

The downside to approach (2) and (3) is that registering the product is not possible.

Comment by tecknobabble [ 04/Mar/11 10:07 AM ]

Okay, you are deferring the generation of the registration page But are you changing the code that will still hang when you press the "Register" button?

The crux of this is the SystemEnvironment.getCommandOutput() doesn't drain the command's output as it runs, and hence if the command produces enough output to fill its output buffers any further output will block waiting for the buffers to be read. Since the getCommandOutput() just does a p.waitFor() it will sit forever until someone goes and kills the forked process.

Comment by tecknobabble [ 04/Mar/11 10:15 AM ]

This is a shell script that can be used to simulate the problem seen on larger servers.

Rename your existing /usr/sbin/prtfru and replace it with this copy. Make sure it has execute privileges on it.

Comment by Scott Fordin [ 04/Mar/11 10:17 AM ]

Added issue to 3.1 Release Notes.

Comment by sirajg [ 04/Mar/11 10:36 AM ]

A fix has also been checked in to ensure that the command output is drained. This was the underlying issue. So the fix consists of two parts :

1) Delay registration file generation till it is needed.
2) Drain command output in SystemEnvironment.getCommandOutput().

Comment by Anissa Lam [ 04/Mar/11 11:26 AM ]

change fix version to 3.1_b01 since this is fixed in the trunk.
add 3_1-next tag as requested by Chris.





[GLASSFISH-16144] Performance Tuning Guide missing a cross-reference to Performance Tuner OLH Created: 03/Mar/11  Updated: 16/Mar/11  Resolved: 16/Mar/11

Status: Resolved
Project: glassfish
Component/s: docs
Affects Version/s: 3.1
Fix Version/s: None

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

Tags:
Participants: Jennifer Chou and Scott Fordin

 Description   

I looked through Performance Tuning Guide but could not find mention of the Performance Tuner or its OLH.
http://download.oracle.com/docs/cd/E18930_01/html/821-2431/index.html

From Paul:
I think that a passing mention of the Performance Tuner with a reference to its online help should be sufficient for the Performance Tuning Guide for Oracle GlassFish Server only



 Comments   
Comment by Scott Fordin [ 16/Mar/11 07:08 PM ]

Numerous references to the online help have been added to the updated guide.





[GLASSFISH-16100] Restart required for java mail session debug change, exception in server.log Created: 24/Feb/11  Updated: 07/Jul/11  Resolved: 04/May/11

Status: Closed
Project: glassfish
Component/s: jca
Affects Version/s: 3.1_b43
Fix Version/s: 3.1.1_b05

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

this is a full download build on Mac


File Attachments: JPEG File restartreq-error.JPG     Text File server.log    
Tags: 3_1_1-approved 3_1_1-verified
Participants: Anissa Lam, Cheng Fang, Jagadish, lidiam, Nazrul and Scott Fordin

 Description   

Steps to reproduce:

1. Create javamail session with Enabled unchecked and Debug checked.
2. Go to the new session and disable debug, save - restart required icon shows up. Click on it and the following reason is displayed:

Error while handling Change event.

server.log contains exception:

[#|2011-02-24T15:25:43.057-0800|SEVERE|oracle-glassfish3.1|LogStrings.org.glassfish.javaee.services|_ThreadID=169;_ThreadName=Thread-1;|RAR9607: Error while handling Change event.
javax.naming.NameNotFoundException: Cannot find name to unbind
at com.sun.enterprise.naming.impl.TransientContext.doUnbind(TransientContext.java:398)
at com.sun.enterprise.naming.impl.TransientContext.unbind(TransientContext.java:420)
at com.sun.enterprise.naming.impl.SerialContextProviderImpl.unbind(SerialContextProviderImpl.java:124)
at com.sun.enterprise.naming.impl.SerialContext.unbind(SerialContext.java:740)
at javax.naming.InitialContext.unbind(InitialContext.java:416)
at javax.naming.InitialContext.unbind(InitialContext.java:416)
at com.sun.enterprise.naming.impl.GlassfishNamingManagerImpl.unpublishObject(GlassfishNamingManagerImpl.java:246)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.unpublishObject(ResourceNamingService.java:184)
at com.sun.enterprise.resource.deployer.MailResourceDeployer.deleteResource(MailResourceDeployer.java:178)
at com.sun.enterprise.resource.deployer.MailResourceDeployer.undeployResource(MailResourceDeployer.java:171)
at com.sun.enterprise.resource.deployer.MailResourceDeployer.redeployResource(MailResourceDeployer.java:193)
at org.glassfish.javaee.services.ResourceManager$PropertyChangeHandler.handleChangeEvent(ResourceManager.java:378)
at org.glassfish.javaee.services.ResourceManager$PropertyChangeHandler.changed(ResourceManager.java:328)
at org.jvnet.hk2.config.ConfigSupport.sortAndDispatch(ConfigSupport.java:332)
at org.glassfish.javaee.services.ResourceManager.changed(ResourceManager.java:275)
at org.jvnet.hk2.config.Transactions$ConfigListenerJob.process(Transactions.java:379)
at org.jvnet.hk2.config.Transactions$ConfigListenerJob.process(Transactions.java:369)
at org.jvnet.hk2.config.Transactions$ConfigListenerNotifier$1$1.call(Transactions.java:259)
at org.jvnet.hk2.config.Transactions$ConfigListenerNotifier$1$1.call(Transactions.java:257)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
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:680)

#]


 Comments   
Comment by lidiam [ 24/Feb/11 03:38 PM ]

This only happens with a session that's created with disabled status.

Comment by Anissa Lam [ 24/Feb/11 06:03 PM ]

The exception comes from the backend.
Assigning this to 'naming' for initial evaluation.

Comment by Cheng Fang [ 14/Mar/11 04:58 PM ]

Does it happen to other types of resources, like jdbc resources?

Comment by Cheng Fang [ 17/Mar/11 11:45 AM ]

custom resource also has this problem. Create a custom resource for Integer with enable=false. After saving it, add a new property and save. Check the server.log for the same exception.

I also tested with a jdbc pool and jms queue connection factory resource, they seem to work fine.

We may need to skip calling unpublishObject for disabled resources. Assign to jca for further evaluation.

Comment by Scott Fordin [ 18/Mar/11 01:13 PM ]

Added topic under "Restart Required" umbrella issue (http://java.net/jira/browse/GLASSFISH-16040) in 3.1 Release Notes.

Comment by Nazrul [ 20/Apr/11 12:50 PM ]

We should try to fix this in 3.1.1

Comment by Jagadish [ 24/Apr/11 09:20 PM ]

Planning to fix this in 3.1.1

Comment by Jagadish [ 02/May/11 11:01 AM ]
  • Why fix this issue in 3.1.1?
    This issue will be seen whenever a disabled resource is reconfigured.
  • Which is the targeted build of 3.1.1 for this fix?
    3.1.1 promoted build-04
  • Do regression tests exist for this issue?
    Manually tested to make sure that re-configuration is not done for disabled resource thereby confirming that the reported issues is not seen.
  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
    Minor fix and hence should not destabilize GlassFish. If needed, Connector-SQE, resource related tests can be executed.

Tests Passed : QL (Web, Classic), connector-dev, jdbc-dev, connector-standalone-cts (Web, Classic), connector-sqe, resources-admin-cli.

Comment by Jagadish [ 04/May/11 08:50 PM ]

FIX INFORMATION :
svn log -v -r 46656
------------------------------------------------------------------------
r46656 | jr158900 | 2011-05-04 21:18:10 +0530 (Wed, 04 May 2011) | 4 lines
Changed paths:
M /branches/3.1.1/connectors/connectors-runtime/src/main/java/com/sun/enterprise/resource/deployer/AdminObjectResourceDeployer.java
M /branches/3.1.1/connectors/connectors-runtime/src/main/java/com/sun/enterprise/resource/deployer/ConnectorResourceDeployer.java
M /branches/3.1.1/connectors/connectors-runtime/src/main/java/com/sun/enterprise/resource/deployer/CustomResourceDeployer.java
M /branches/3.1.1/connectors/connectors-runtime/src/main/java/com/sun/enterprise/resource/deployer/ExternalJndiResourceDeployer.java
M /branches/3.1.1/connectors/connectors-runtime/src/main/java/com/sun/enterprise/resource/deployer/JdbcResourceDeployer.java
M /branches/3.1.1/connectors/connectors-runtime/src/main/java/com/sun/enterprise/resource/deployer/MailResourceDeployer.java

Comment by lidiam [ 07/Jul/11 12:47 AM ]

Verified in build ogs-3.1.1-b11-07_04_2011-aix.zip.





[GLASSFISH-16094] On Windows the first time pkg.bat or updatetool.bat is run they may echo garbage Created: 24/Feb/11  Updated: 26/Apr/11  Resolved: 15/Mar/11

Status: Resolved
Project: glassfish
Component/s: update_center
Affects Version/s: 3.1_b43
Fix Version/s: 3.1.1

Type: Bug Priority: Minor
Reporter: Joe Di Pol Assignee: Joe Di Pol
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
depends on UPDATECENTER2-2176 Windows bootstub wrapper script has e... In Progress
Tags: 3_1-exclude 3_1-next 3_1-release-note-added 3_1-release-notes
Participants: Joe Di Pol and Scott Fordin

 Description   

On Windows if you don't install the Update Center via the installer, the first time you run pkg.bat (or updatetool.bat) the scripts echo a bunch of stuff before prompting the user asking them if they would like to install the software. Things work, it's just ugly.



 Comments   
Comment by Joe Di Pol [ 24/Feb/11 09:38 AM ]

This is caused by a bad "@echo on" statement in the pkg.bat bootstrap wrapper script. One work-around is to remove the echo statement (immediately after the copyright block), but more likely is the users should just ignore the garbage.

This is covered by UC issue UPDATECENTER2-2176 and we may want to mention it in the GlassFish release notes.

Comment by Scott Fordin [ 15/Mar/11 11:15 AM ]

Added topic to 3.1 Release Notes. Will appear in next doc set refresh.

Comment by Joe Di Pol [ 26/Apr/11 05:18 PM ]

This will be fixed in the product when uc2.3.4-B53 is picked up, which is planned for GlassFish 3.1.1





[GLASSFISH-16091] man page for asadmin collect-log-files references renamed parameter Created: 23/Feb/11  Updated: 30/Jun/11  Resolved: 30/Jun/11

Status: Resolved
Project: glassfish
Component/s: docs
Affects Version/s: None
Fix Version/s: 3.1.1

Type: Bug Priority: Minor
Reporter: Joe Fialli Assignee: Paul Davies
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3-1-exclude
Participants: Joe Fialli, Paul Davies and Scott Fordin

 Description   

assadmin collect-log-files --help has the following outdated reference.

--outputfilepath

The name of the directory in which the ZIP archive will
be saved. This option is required.

The ZIP file name is constructed from the specified tar-
get and timestamp, as follows:

target_yyyy-mm-dd_hh-min-sec.zip

The new parameter name is --retrieve. It is mentioned in the usage method so this is easily worked around.

$ asadmin collect-log-files --outputfilepath l
Invalid option: --outputfilepath
Usage: asadmin [asadmin-utility-options] collect-log-files [--target <target>]
[--retrieve[=<retrieve(default:false)>]]
[?|-help[=<help(default:false)>]] [retrievefilepath]
Command collect-log-files failed.



 Comments   
Comment by Scott Fordin [ 16/Mar/11 07:10 PM ]

man page will be updated for the 3.2 release.

Comment by Paul Davies [ 27/May/11 10:05 AM ]

Under consideration for fixing in the 3.1.1 bundled docs

Comment by Scott Fordin [ 31/May/11 10:15 AM ]

Reassigning to Paul Davies.

Comment by Paul Davies [ 30/Jun/11 08:50 PM ]

Fix committed in revision 47759.





[GLASSFISH-16090] during load-balancer configurator installation and configuration, it requires 8 char iWS Admin password Created: 23/Feb/11  Updated: 20/Apr/11

Status: Open
Project: glassfish
Component/s: load_balancer
Affects Version/s: 3.1_b43
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Homer Yau Assignee: kshitiz_saxena
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

load-balancer configurator b05 iws 7.0.9


Tags: 3_1 glassfish plugin rel_notes_candidate
Participants: Homer Yau, kshitiz_saxena and Scott Fordin

 Description   

during load-balancer configurator installation and configuration, it requires 8 char iWS Admin password.

The is a test scenario we face if iplanet webserver admin password is shorter than 8 character.

Workaround:
It is to use wadm to reset the admin password, restart the iws admin-server and then continue load-balancer configurator's installation.
reset web server admin password
cd <webserver_install_dir>/bin

  1. ./wadm reset-admin-password --user admin --host localhost --port 8989
    Please enter admin-password> <new_passsword>
    Please enter admin-password again> <new_password>


 Comments   
Comment by Homer Yau [ 23/Feb/11 01:48 PM ]

We need to accommodate/support for the user that have existing or new iPlanet Web Server that have admin password that have less than eight character in the future release.

Comment by Scott Fordin [ 20/Apr/11 11:56 AM ]

Added note to 3.1 HA Admin Guide.





[GLASSFISH-16082] There doesn't appear to be any explanation about the classpath-prefix and classpath-suffix in the GF 3.x documentation. Created: 23/Feb/11  Updated: 03/Mar/11  Resolved: 25/Feb/11

Status: Resolved
Project: glassfish
Component/s: docs
Affects Version/s: 3.1_b43
Fix Version/s: None

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

Tags:
Participants: Andreas Rieck, Paul Davies, Rebecca Parks, Scott Fordin and tecknobabble

 Description   

In GF 2.x/9.x, AS 8.x and 7.x, the JVM options provided a classpath-prefix and classpath-suffix attributes that allow a customer to add jar files or directories either in front of, or after the application server's system classpath.

In GF 3.x this appears to have been removed - navigating to the JVM section of a configuration the text fields for the classpath-prefix and classpath-suffix, along with whether the classpath from the environment should be used, are greyed out and cannot be edited. They also have the text "not supported in v3".

Given the length of time, and the number of versions of the Application Server that these attributes have been available I'm surprised that I've not been able to find any mention of this change in the Release Notes, Admin Guide, Upgrade Guide or Application Developers Guide (Classloading section).

At the very least the absence of this feature needs to be documented, at this point I suspect in the Release Notes for 3.1, along with an explanation with what the alternatives are for a customer that has used this, for example, to refer to a collection of common jar files present in a directory on their system that is outside of the GlassFish installation directory hierarchy.



 Comments   
Comment by Rebecca Parks [ 23/Feb/11 03:51 PM ]

The classpath-prefix and classpath-suffix options were labeled "do not use" starting with v3 Preview. It was switching to OSGi that made maintaining these unworkable. So these haven't been available in all of v3.x. IMO, this should be handled in a Release Note entry, or maybe the Upgrade Guide. Reassigning to Paul for assignment to the Release Notes or Upgrade Guide writer.

Comment by Rebecca Parks [ 23/Feb/11 03:52 PM ]

Please reassign to the Release Notes or Upgrade Guide writer.

Comment by Paul Davies [ 23/Feb/11 03:57 PM ]

The issue goes beyond upgrade, though. How would a user of 3.1 who hasn't upgraded from a previous release obtain a similar result? Is the class loader documentation not an appropriate place for this information?

Comment by Rebecca Parks [ 23/Feb/11 04:13 PM ]

It is my understanding that classpath-prefix was typically used to substitute another package for one of the GF packages, for example if a newer one was available. That can be done with the Java Endorsed Standards Override Mechanism or on a per-app basis with the --libraries option of the deploy command. These are documented in the class loaders chapter of the Application Development Guide. The Java Optional Package Mechanism, which is also documented in the same chapter, does what classpath-suffix used to do.

Comment by Paul Davies [ 23/Feb/11 04:16 PM ]

This issue now has the sufficient information to enable the Release Notes or Upgrade Guide to be updated appropriately.

Comment by tecknobabble [ 24/Feb/11 12:19 AM ]

Customers have, and are using these to refer to jar files that are present locally on the machine, rather than having to duplicate and copy those jars into the domain's lib directory. I've done this myself. A simple example would be if you have a database installation on the same machine, should you have to copy the jars from that, increasing the admin overhead of having to copy those files back over whenever the database installation is patched?

I will agree that often sustaining test fixes were placed on the classpath prefix location, and I know that with OSGi that practice will have to change because of the way modules embed information about where they load classes from. However, it doesn't change the fact that customers have been legitimately able to refer to java content elsewhere on their machines and now can't.

Most customers using the enterprise versions of the previous Application Server releases are only just starting to look at GF 3.x as it offers the features they are already using, and they will trip over this. I know of at least one major European customer that will probably log a technical RFE on the product asking for this features return.

In any case, if the current restriction is documented that's excellent. The detail above is really because I do think this will end up being something customer's will push on for a change in the product and without any detail of the thinking behind the change its difficult for them to understand why the restriction has been imposed.

Comment by Scott Fordin [ 25/Feb/11 08:22 PM ]

Topic added to 3.1 Release Notes.

Comment by Andreas Rieck [ 03/Mar/11 11:04 AM ]

Thanks for documenting the issue at the release notes at
http://download.oracle.com/docs/cd/E18930_01/html/821-2434/ggrvi.html#gkuhf

However "Oracle GlassFish Server 3.1 High Availability Administration Guide"
still explizit describes get and set of class path prefix and suffix, which might confuse.
see:
http://download.oracle.com/docs/cd/E18930_01/html/821-2426/gkrdd.html#gksav





[GLASSFISH-16067] 3.1 GlassFish installer takes longer to bootstrap Update Center than in 3.0.1 Created: 21/Feb/11  Updated: 02/Dec/11  Resolved: 15/Jun/11

Status: Resolved
Project: glassfish
Component/s: update_center
Affects Version/s: 3.1
Fix Version/s: 3.1.1_b08, 4.0

Type: Bug Priority: Major
Reporter: Joe Di Pol Assignee: Snjezana Sevo-Zenzerovic
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
depends on UPDATECENTER2-2175 Bootstrapper performance regression f... In Progress
Status Whiteboard:

Flagging for release notes. There is no workaround (although not using a proxy server, if possible, can improve performance).

If the user wishes to confirm the download process is making progress they can look in "glassfish3/.org.opensolaris,pkg/download/<number>" and verify that the number of files is increasing over time.

Tags: 3_1-exclude 3_1-next 3_1-release-note-added 3_1-release-notes 3_1_1-approved
Participants: Joe Di Pol, Nazrul, scatari, Scott Fordin and Snjezana Sevo-Zenzerovic

 Description   

On my MacBook it takes the 3.1 installer about 4m30s to bootstrap the Update Center (go from 41% to 69%). With 3.0.1 it takes about 1m30s. This is likely caused by a performance regression in UC 2.3.3. See issue UPDATECENTER2-2175

This was with the Unix installer, B43 web profile.



 Comments   
Comment by Joe Di Pol [ 23/Feb/11 08:13 AM ]

The times in the description where using a network proxy. When I removed the proxy the time improved to 3m30s – a bit of an improvement.

Comment by Joe Di Pol [ 22/Mar/11 11:00 AM ]

A fix that improves the performance has been checked into Update Center (see linked bug). We will integrate this for 3.2.

Comment by Scott Fordin [ 12/Apr/11 04:19 PM ]

Added issue to 3.1 Release Notes.

Comment by Joe Di Pol [ 20/Apr/11 02:27 PM ]

A fix for UPDATECENTER2-2175 was integrated in UC 2.3.4-B53. This will be picked up for GlassFish 3.1.1.

That fix significantly speeds up downloaded performance over what is in UC 2.3.3/GF 3.1 (over twice as fast), but is still not as fast as UC 2.3.2/3.0.1 on most networks.

Comment by Nazrul [ 21/Apr/11 11:10 AM ]

We should integrate the current UC fix (UC issue 2175) in 3.1.1

Comment by Joe Di Pol [ 22/Apr/11 11:34 AM ]

Assigning to Snjezana to pick up UC 2.3.4,0-53 in the GlassFish build.

Comment by scatari [ 06/Jun/11 12:14 PM ]

Pre-approving this fix for 3.1.1.

Comment by Snjezana Sevo-Zenzerovic [ 15/Jun/11 03:33 PM ]

Fixed in 3.1.1 b08 and the trunk since updated pkg-client.jar has been integrated.





[GLASSFISH-16066] set-web-context-param, set-web-env-entry man pages: incorrect case for --ignoredescriptoritem option Created: 21/Feb/11  Updated: 30/Jun/11  Resolved: 30/Jun/11

Status: Resolved
Project: glassfish
Component/s: docs
Affects Version/s: 3.1_b42
Fix Version/s: 3.1.1

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

Tags: 3_1-release-note-added 3_1-release-notes
Participants: Paul Davies and Scott Fordin

 Description   

The case of the --ignoredescriptoritem option of the set-web-context-param and set-web-env-entry subcommands has been changed from camel case to all lowercase. However, the man pages for these subcommands have not been updated to reflect this change and still list the option as --ignoreDescriptorItem.



 Comments   
Comment by Paul Davies [ 03/Mar/11 03:51 PM ]

Reassigned to writer who will fix it in 3.2. As this issue is tagged for inclusion in the release notes, the issue need not be assigned to the release notes writer.

Comment by Scott Fordin [ 24/Mar/11 02:31 PM ]

Added topic to 3.1 Release Notes. Added "3_1-release-note-added" tag.

Comment by Paul Davies [ 27/May/11 10:07 AM ]

Under consideration for fixing in the 3.1.1 bundled docs

Comment by Paul Davies [ 30/Jun/11 08:50 PM ]

Fix committed in revision 47759.





[GLASSFISH-16061] could not find Factory: javax.faces.context.FacesContextFactory Created: 21/Feb/11  Updated: 17/May/11  Resolved: 11/May/11

Status: Closed
Project: glassfish
Component/s: jsf
Affects Version/s: 3.1_b43
Fix Version/s: None

Type: Bug Priority: Major
Reporter: bleathem Assignee: rogerk
Resolution: Won't Fix Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Linux, Seam 3


Tags: 3_1-exclude 3_1-release-note-added 3_1-release-notes
Participants: bleathem, rogerk and Scott Fordin

 Description   

On running my JSF/Seam 3 application (using netbeans), the application startup fails with the message:

WARNING: StandardWrapperValve[FacesServlet]: PWC1382: Allocate exception for servlet FacesServlet
java.lang.IllegalStateException: Application was not properly initialized at startup, could not find Factory: javax.faces.context.FacesContextFactory

I have to undeploy my application, restart glassfish, and re-deploy my application (sometimes several times) to get this problem to go away.

This problem is intermittent.

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

Stack trace:

WARNING: StandardWrapperValve[FacesServlet]: PWC1382: Allocate exception for servlet FacesServlet
java.lang.IllegalStateException: Application was not properly initialized at startup, could not find Factory: javax.faces.context.FacesContextFactory
at javax.faces.FactoryFinder$FactoryManager.getFactory(FactoryFinder.java:815)
at javax.faces.FactoryFinder.getFactory(FactoryFinder.java:317)
at javax.faces.webapp.FacesServlet.init(FacesServlet.java:253)
at org.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.java:1439)
at org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:1071)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:189)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:595)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:98)
at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:91)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:162)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:326)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:227)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:170)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:822)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:719)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1013)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:662)



 Comments   
Comment by rogerk [ 21/Feb/11 09:49 AM ]

Can you provide a war for this app?

Comment by bleathem [ 21/Feb/11 10:07 AM ]

I'll see if I can put together a simplified war that exhibits this behaviour.

Comment by rogerk [ 21/Feb/11 11:48 AM ]

Simplified app would be nice. I know that there are probably a lot of libraries with a Seam3 aopp.

Comment by rogerk [ 21/Feb/11 11:48 AM ]

Simplified app would be nice. I know that there are probably a lot of libraries with a Seam3 aopp.

Comment by rogerk [ 21/Feb/11 12:36 PM ]

Tagging until more information is available.

Comment by bleathem [ 22/Mar/11 11:16 PM ]

I can now reproduce this behaviour, and I have a workaround, with a small caveat.

I cannot run my app with the weld-osgi-bundle.jar provided with glassfish, so I replace it with the latest weld-osgi-bundle snapshot.

The error comes up consistently in my sample app, and I can make it consistently going away by adding the following to my web.xml:

<servlet>
<servlet-name>Faces Servlet</servlet-name>
<servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>

I can provide you with the sample app if this information is not enough to go on.

Comment by rogerk [ 23/Mar/11 12:09 PM ]

Are you saying your app was not configured to go through the FacesServlet?

Comment by Scott Fordin [ 23/Mar/11 06:25 PM ]

Need more info to add issue to 3.1 Release Notes.

Comment by rogerk [ 11/May/11 03:59 AM ]

Closing as I have not heard back from reporter and this appears to be a configuration issue - in addition the reporter has workaround for config issue.

Comment by bleathem [ 16/May/11 09:08 PM ]

This issue is sporadic issue, and is observed when a JSF application does not register the Faces Servlet in the web.xml.

com.sun.faces.config.FacesInitializer will attempt to initialize the JSF Servlet, which normally works fine, except when Seam Faces is included in the application, which also tries to initialize the Servlet.

This bug is not deterministic due to the random ordering of listeners by Glassfish.

For more information, please see the corresponding issue in SeamFaces:
https://issues.jboss.org/browse/SEAMFACES-163

Comment by Scott Fordin [ 17/May/11 09:24 AM ]

Added issue to 3.1 Known Issues section of the 3.1-3.1.1 Release Notes.





[GLASSFISH-16048] Application info page: status not show correctly and virtual servers changes not saved. Created: 18/Feb/11  Updated: 22/Jun/11  Resolved: 18/Feb/11

Status: Closed
Project: glassfish
Component/s: admin_gui
Affects Version/s: 3.1_b43
Fix Version/s: 3.1.1_b01

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

Issue Links:
Duplicate
is duplicated by GLASSFISH-16054 Regression: Status showed incorrectly... Resolved
Tags: 3_1-exclude 3_1-release-note-added 3_1-release-notes
Participants: Anissa Lam, Scott Fordin and shaline

 Description   

I just notice 2 issues in application information page after application is deployed.
This only occurs in DAS ONLY environment.

  • The status checkbox is always unchecked regardless whether the application is enabled or disabled. The display is wrong.
  • Changing the list of virtual servers is not persisted.

The display for the status was not correct is a regression i introduced when fixing GLASSFISH-15848.
Not able to save the virtual servers is due to the capitalization of the attribute variable. I believe the issue has been there for a while.



 Comments   
Comment by Anissa Lam [ 18/Feb/11 11:33 AM ]

The issue has been fixed in the trunk,

Sending appEdit.layout
Transmitting file data .
Committed revision 45179.
==================

We want to release note this to provide a workaround for user.
User will only see this issue when there is NO clusters or standalone instances created in the domain.

  • For the status of the application, always look at the applications table that lists out the applications. The status is correctly displayed there, and user can use this table to change the status as well.
  • To change the virtual server for the deployed application, use the CLI set command.

use the following CLI to see the info:

%asadmin get server.application-ref.<APPLICATION_NAME>.*

and set command to change the list of virtual servers for this application.

%asadmin set server.application-ref.<APPLICATION_NAME>.virtual-servers=<list-of-vs-separated-by-comman>

example of get :
%asadmin get server.application-ref.hello

examples of set:
%asadmin set server.application-ref.hello.virtual-servers=server,myVS
or
%asadmin set server.application-ref.hello.virtual-servers=myVS

Comment by Anissa Lam [ 18/Feb/11 11:33 AM ]

Fixed in the trunk.

Comment by Scott Fordin [ 12/Apr/11 05:06 PM ]

Added issue to 3.1 Release Notes.

Comment by shaline [ 22/Jun/11 03:30 PM ]

Verified on promoted b08.





[GLASSFISH-16044] appclient in cygwin passing extra empty string Created: 17/Feb/11  Updated: 07/Apr/11  Resolved: 30/Mar/11

Status: Resolved
Project: glassfish
Component/s: standalone_client
Affects Version/s: 3.1_b43
Fix Version/s: 3.1.1_b01

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

Windows, Cygwin


File Attachments: File AppClientTest.ear     Java Archive File AppClientTestClient.jar    
Tags: 3_1-exclude 3_1-release-note-added 3_1-release-notes 3_1windows
Participants: Scott Fordin, Sreekanth and Tim Quinn

 Description   

When running appclient on a windows machine with cygwin, the appclient is passing an extra empty String to the program arguments.

But when running on command line in windows doesnt show that problem.

See below:

Linux run:
===========
sreekanth@spidy:~/NetBeansProjects/AppClientTest$ asadmin deploy --retrieve dist --force=true dist/AppClientTest.ear
Authentication failed with password from login store: /home/sreekanth/.asadminpass
Enter admin password for user "admin">
Application deployed with name AppClientTest.
Command deploy executed successfully.
sreekanth@spidy:~/NetBeansProjects/AppClientTest$ appclient -client dist/AppClientTestClient.jar Arguments length is :0
sreekanth@spidy:~/NetBeansProjects/AppClientTest$

Window Run:
===========

aroot@bigapp-x2250-1 /cygdrive/c/ha/tmp-sree
$ /cygdrive/c/ha/glassfish3/glassfish/bin/asadmin deploy --retrieve . --force=true AppClientTest.ear
Application deployed with name AppClientTest.
Command deploy executed successfully.

aroot@bigapp-x2250-1 /cygdrive/c/ha/tmp-sree
$ /cygdrive/c/ha/glassfish3/glassfish/bin/appclient -client AppClientTestClient.jar
Arguments length is :1



 Comments   
Comment by Tim Quinn [ 18/Feb/11 12:03 PM ]

Sreekanth,

Please contact me directly via e-mail so I can arrange to investigate this on your system.
Thanks.

Comment by Tim Quinn [ 20/Feb/11 07:40 PM ]

I have reproduced this issue on a Windows system with cygwin installed.

Investigating.

Comment by Tim Quinn [ 21/Feb/11 11:56 AM ]

We are excluding this from 3.1.

It seems to be due to an interaction between the way the CLIBootstrap class generates the java command for launching the app client and how the cygwin shell parses the command into arguments. There is currently a trailing blank in the generated command line. This is not an issue in other environments, but cygwin in this case seems to treat the blank as a separator in front of an empty argument.

Users who have app clients that process a variable number of arguments and run those clients on Windows using cygwin should be aware of this issue. One workaround would be to make sure the client deals correctly with an empty argument.

Comment by Tim Quinn [ 14/Mar/11 03:45 PM ]

Release notes info:

Summary: Using cygwin on Windows, the app client container (ACC) passes an extra empty-string argument to the client's main method. This might result in the app client throwing an index-out-of-range exception if the client does not guard itself against empty argument values.

Workarounds (reiterating from the Feb. 21. comment):
1. If your client works with a variable number of arguments make sure that it protects itself against empty argument values.

2. Avoid using cygwin on Windows for clients that cannot be made to guard against an empty argument value.

Comment by Tim Quinn [ 17/Mar/11 11:12 AM ]

Fix checked in:

Project: glassfish
Repository: svn
Revision: 45605
Author: tjquinn
Date: 2011-03-17 18:03:10 UTC
Link:

Log Message:
------------
Fix for 16044

Under cygwin on Windows, a trailing blank on the generated java command line was parsed as an empty additional command-line argument and passed as such to the client.

This change causes the generated java command to no longer contain an extra trailing blank.

Tests: QL, deployment devtests, cygwin on Windows test

Revisions:
----------
45605

Modified Paths:
---------------
trunk/v3/appclient/client/acc/src/main/java/org/glassfish/appclient/client/CLIBootstrap.java

Comment by Tim Quinn [ 24/Mar/11 01:52 PM ]

The earlier fix causes problems when the user enters JVM options on the appclient command line. There is a missing space between the user-provided JVM options and some JVM options which CLIBootstrap adds to the generated java command line.

Comment by Scott Fordin [ 24/Mar/11 02:00 PM ]

Added topic to 3.1 Release Notes. Added "release note added" tag.

Comment by Tim Quinn [ 30/Mar/11 08:59 AM ]

Fix checked in.

Project: glassfish
Repository: svn
Revision: 45773
Author: tjquinn
Date: 2011-03-30 15:57:40 UTC
Link:

Log Message:
------------
Additional refinement for fix to 16044

This change resolves a problem in which user-specified JVM options were not separated from other options by a space. It also cleans up the earlier fix logic a bit and adds some javadoc for some methods.

Tests: QL, deployment devtests, cygwin on Windows test

Revisions:
----------
45773

Modified Paths:
---------------
trunk/v3/appclient/client/acc/src/main/java/org/glassfish/appclient/client/CLIBootstrap.java





[GLASSFISH-16040] ReleaseNotes: document Restar Required issues Created: 17/Feb/11  Updated: 08/Jul/11  Resolved: 18/Mar/11

Status: Closed
Project: glassfish
Component/s: docs
Affects Version/s: 3.1_b43
Fix Version/s: None

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

Tags: 3_1-release-note-added 3_1-release-notes
Participants: Anissa Lam, lidiam and Scott Fordin

 Description   

This is an umbrella bug for documenting numerous issues with Restart Required. Please find the details in the following query:

http://java.net/jira/secure/IssueNavigator.jspa?mode=hide&requestId=10358

Each bug in the query should be documented in Release Notes for 3.1.



 Comments   
Comment by Scott Fordin [ 03/Mar/11 07:09 PM ]

Added issue to 3.1 Release Notes.

Comment by Anissa Lam [ 14/Mar/11 04:37 PM ]

I am re-opening this issue so that the next doc refresh can have the correct summary.
Currently, it says:

"Description
There are a number of functions in that you can perform through the GlassFish Server
Administration Console. These functions require a server restart, but the Administration
Console does not correctly convey this."

This is not quite correct. It is saying that the Admin Console does not show the correct information to user, when in fact, the information that console shown is correct. It is that the backend or each of the components in the bug list doesn't specify that restart is required.
In order word, even if user is using CLI to look at the status, eg. list-domains or list-instances to check if instance need restart, they will see the wrong information.

So, i think the wording should be changed to reflect the issue more accurately.

Comment by Scott Fordin [ 18/Mar/11 01:36 PM ]

Reworded issue description. Added ulinks to umbrella issues.

Comment by Scott Fordin [ 24/Mar/11 02:01 PM ]

Added "release note added" tag.

Comment by lidiam [ 08/Jul/11 11:46 PM ]

Verified in Release Notes for 3.1 release.





[GLASSFISH-16037] create-jvm-options subcommand options incorrectly parsed by asadmin Created: 17/Feb/11  Updated: 07/Apr/11  Resolved: 18/Feb/11

Status: Resolved
Project: glassfish
Component/s: command_line_interface
Affects Version/s: 3.1_b38
Fix Version/s: 3.1.1_b01

Type: Bug Priority: Major
Reporter: Paul Davies Assignee: Bill Shannon
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1-exclude 3_1-release-note-added 3_1-release-notes
Participants: Bill Shannon, Paul Davies and Scott Fordin

 Description   

The asadmin utility is incorrectly interpreting options of the create-jvm-options subcommand as asadmin utility options. As a result, an attempt to create an option, for example -Xrs, fails:

asadmin> create-jvm-options -Xrs
Non-boolean option: X, not allowed in argument: -Xrs
Usage: asadmin [-H|--host <host(default:localhost)>]
[-p|--port <port(default:4848)>] [-u|--user <user(default:admin)>]
[-W|--passwordfile <passwordfile>]
[t|-terse[=<terse(default:false)>]]
[s|-secure[=<secure(default:false)>]]
[e|-echo[=<echo(default:false)>]]
[I|-interactive[=<interactive(default:true)>]]
[?|-help[=<help(default:false)>]]
create-jvm-options [command-specific options]
Command create-jvm-options failed.

The usage message appears to be in the style of a v2 usage message. In GlasFish 3, asadmin utility options are not provided in the usage message.

To workaround this problem, run the create-jvm-options command in single mode specifying at least one asadmin utility option, for example:

dashost$ asadmin --host dashost create-jvm-options -Xrs
Created 1 option(s)
Command create-jvm-options executed successfully.



 Comments   
Comment by Bill Shannon [ 18/Feb/11 02:07 PM ]

Missed one case in the special cases for commands that treat unknown
options as operands.

Also, some asadmin hidden commands had short option names, which was
further confusing things. I'm removing the short names for the hidden
options.

Comment by Scott Fordin [ 24/Mar/11 02:13 PM ]

Added topic to 3.1 Release Notes. Added "release note added" tag.





[GLASSFISH-16029] Log Viewer: details garbled after navigating to earlier records, exception in server.log Created: 16/Feb/11  Updated: 05/Jul/11  Resolved: 05/Jul/11

Status: Closed
Project: glassfish
Component/s: logging
Affects Version/s: 3.1_b43
Fix Version/s: 3.1.1_b11

Type: Bug Priority: Major
Reporter: lidiam Assignee: naman_mehta
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

promoted build b43


File Attachments: JPEG File DAS-log-details-garbled.jpg     Text File das.server.log     XML File domain.xml     Text File instance.server.log     JPEG File logviewer-detail-das.jpg     JPEG File logviewer-detail-instance.jpg     JPEG File logviewer-records-table-missing.jpg     Text File server.log     Text File third.server.log    
Issue Links:
Duplicate
is duplicated by GLASSFISH-14277 Log entry detail page is empty Resolved
Tags: 3_1_1-approved
Participants: Anissa Lam, lidiam, naman_mehta, scatari, Scott Fordin and sirajg

 Description   

Steps to reproduce:

1. Create a standalone instance and start it.
2. Go to server (Admin Server) and click on View Log Files button.
3. In log viewer see details of a DAS server.log message - it's displayed fine.
4. In log viewer change instance to standalone instance and click on a message for details - Issue 1: no details are displayed, only log level (see attached). Close details.
5. In log viewer, go back to DAS server.log and click on a message for details again. Issue 2: this time many messages are displayed together (see attached screenshot, logviewer-details-das.jpg).

This may be an issue with my specific log files/configuration, which I'll attach as well.



 Comments   
Comment by Anissa Lam [ 17/Feb/11 12:00 AM ]

Not a show stopper, exclude from 3.1

Comment by lidiam [ 17/Feb/11 04:38 PM ]

There are certainly issues with log viewer, though may be difficult to reproduce exactly. I wanted to see if I could reproduce the problem from this bug on a clean install, but first I encountered another issues:

1. Unzip the distribution and start DAS.
2. In Admin Console go to server (Admin Server) node, click View Log Files button.
3. In my case I have a total of 47 records, 8 through 47 displayed.
4. Click on "previous" button, in my case "Records before 8" - the first 8 records correctly display.
5. Click on "next" equivalent, in my case "Records after 7" - the records table disappeared (will attach screenshot).

Tried the above scenario second time and this time it behaved correctly.

Now I went back to Log Viewer, repeated steps 4 and 5 above, and then clicked on the top record's details link. Got the same garbled result as in the logviewer-detail-das.jpg.

Comment by lidiam [ 17/Feb/11 04:43 PM ]

The second attempt server.log, when records table did not display, after previous/next navigation. I hit Search after that to get the table displayed, but got an error instead. I'll attach more information, if I manage to reproduce it again.

Comment by lidiam [ 17/Feb/11 05:09 PM ]

I have just tried this again on a clean install (unzipped ogs bundle). I started DAS and then restarted it from the console, to have enough results in server.log to have the "Records before x" button displayed. Steps:

1. Launched Log Viewer for DAS.
2. Clicked on Details link for a few records - all display fine.
3. Clicked "Records before 50" button - saw the following exception in server.log (attaching as third.server.log):

[#|2011-02-17T16:58:40.489-0800|WARNING|oracle-glassfish3.1|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=87;_ThreadName=Thread-1;|StandardWrapperValve[FacesServlet]: PWC1406: Servlet.service() for servlet FacesServlet threw exception
java.lang.NullPointerException: List not found via expression: '$property{list}'.
at com.sun.jsftemplating.layout.descriptors.LayoutForEach.getList(LayoutForEach.java:113)
at com.sun.jsftemplating.layout.descriptors.LayoutForEach.encode(LayoutForEach.java:167)
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.encode(LayoutElementBase.java:348)
at com.sun.jsftemplating.layout.descriptors.LayoutDefinition.encode(LayoutDefinition.java:250)
at com.sun.jsftemplating.renderer.TemplateRenderer.encodeEnd(TemplateRenderer.java:139)
at javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:875)
at com.sun.webui.jsf.util.RenderingUtilities.renderComponent(RenderingUtilities.java:99)
at com.sun.webui.jsf.renderkit.html.PropertyRenderer.renderPropertyComponents(PropertyRenderer.java:195)
at com.sun.webui.jsf.renderkit.html.PropertyRenderer.encodeEnd(PropertyRenderer.java:156)
at javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:875)
at com.sun.webui.jsf.util.RenderingUtilities.renderComponent(RenderingUtilities.java:99)
at com.sun.webui.jsf.renderkit.html.PropertySheetSectionRenderer.renderProperties(PropertySheetSectionRenderer.java:183)
at com.sun.webui.jsf.renderkit.html.PropertySheetSectionRenderer.renderPropertySheetSection(PropertySheetSectionRenderer.java:143)
at com.sun.webui.jsf.renderkit.html.PropertySheetSectionRenderer.encodeEnd(PropertySheetSectionRenderer.java:86)
at javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:875)
at com.sun.webui.jsf.util.RenderingUtilities.renderComponent(RenderingUtilities.java:99)
at com.sun.webui.jsf.renderkit.html.PropertySheetRenderer.renderPropertySheetSections(PropertySheetRenderer.java:164)
at com.sun.webui.jsf.renderkit.html.PropertySheetRenderer.encodeEnd(PropertySheetRenderer.java:114)
at javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:875)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1763)
at javax.faces.render.Renderer.encodeChildren(Renderer.java:168)
at com.sun.webui.jsf.renderkit.html.ContentPageTitleRenderer.encodeChildren(ContentPageTitleRenderer.java:169)
at javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:845)
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.encodeChild(LayoutElementBase.java:551)
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.encodeChild(LayoutElementBase.java:555)
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.encodeChild(LayoutElementBase.java:555)
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.encodeChild(LayoutElementBase.java:555)
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.encodeChild(LayoutElementBase.java:555)
at com.sun.jsftemplating.layout.descriptors.LayoutComponent.encode(LayoutComponent.java:243)
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.encode(LayoutElementBase.java:348)
at com.sun.jsftemplating.layout.descriptors.LayoutDefinition.encode(LayoutDefinition.java:246)
at com.sun.jsftemplating.layout.LayoutViewHandler.renderView(LayoutViewHandler.java:683)
at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:121)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:410)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1534)
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:233)
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:279)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655)
at org.apache.catalina.core.StandardPipeline.doChainInvoke(StandardPipeline.java:600)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:96)
at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:91)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:162)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:326)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:227)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:228)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:822)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:719)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1013)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:619)

#]

4. Clicked on Details for the first record - details page results are garbled as per the already attached screenshot (logviewer-details-das).

Once the Log Viewer is restarted, records are displayed ok again. However, this means that in Log Viewer users will not be able to view details of records earlier than last 40.

Comment by lidiam [ 17/Feb/11 05:10 PM ]

server.log file from the third attempt at this scenario.

Comment by lidiam [ 17/Feb/11 06:18 PM ]

Record's details are also garbled after performing a search in Log Viewer.

Comment by sirajg [ 15/Mar/11 01:57 PM ]

The issue is caused by the missing value for logFile in the URL for the detailed screen. For example it may look like :
http://localhost:4848/common/logViewer/logEntryDetail.jsf?instanceName=server&logLevel=INFO&logFile=&recNumber=10

i.e .....logFile=&recNumber=...., which has a missing value for logFile.

The workaround is to specify the value of the logFile in the URL manually. So for example, it could look something like :
http://localhost:4848/common/logViewer/logEntryDetail.jsf?instanceName=server&logLevel=INFO&logFile=server.log&recNumber=10

Comment by Scott Fordin [ 12/Apr/11 05:25 PM ]

Added issue to 3.1 Release Notes.

Comment by sirajg [ 20/Apr/11 02:52 PM ]

Why fix this issue in 3.1.1?
o May result in support call
Which is the targeted build of 3.1.1 for this fix?
o b02 (The fix has been checked in the trunk, just need to backport the change to the branch.)
Do regression tests exist for this issue?
o No. need manual testing
Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
o verify the bug reported is fixed.

Comment by scatari [ 20/Apr/11 04:59 PM ]

Approved. BTW, b02 is happening in a few hours, if you cannot checkin by tonight(04/20), then please retarget this to b03.

Comment by sirajg [ 20/Apr/11 07:31 PM ]

Make results pageSession instead of requestScope

— src/main/resources/logViewer/logEntryDetail.jsf (revision 46272)
+++ src/main/resources/logViewer/logEntryDetail.jsf (working copy)
@@ -74,7 +74,7 @@
logRecords="#{requestScope.queryResult.data.records}"
truncate="false"
truncateLength="-1"

  • result="#{requestScope.results}"
    + result="#{pageSession.results}"
    );
Comment by lidiam [ 24/Jun/11 05:00 PM ]

Viewing details of standalone instance log works fine now, but details of server.log of DAS are still garbled (will attach screenshot). They were incorrect for me from the start, no need to switch between the views.

Comment by lidiam [ 24/Jun/11 05:03 PM ]

Attaching DAS-log-details-garbled screenshot.

Comment by sirajg [ 26/Jun/11 06:37 PM ]

Could not reproduce on 3.1.1 b09.

Comment by sirajg [ 27/Jun/11 08:25 PM ]

Can be reproduced in 3.1.1 on Windows.
The REST query : ...../view-log/details/lognames.json returns data which includes "InstanceLogFileNames". This contains the log file name which is then used by parts of the log viewer. On Unix a correct value ("server.log") is obtained. On Windows this value is empty. As a result, the log viewer detail window has the URL :
http://<host:port>/common/logViewer/logEntryDetail.jsf?instanceName=server&logLevel=INFO&logFile=&recNumber=<recno>
instead of
http://<host:port>/common/logViewer/logEntryDetail.jsf?instanceName=server&logLevel=INFO&logFile=server.log&recNumber=<recno>

i.e. the logFile is missing, resulting in the undesirable output. Transferring to logging.

Comment by naman_mehta [ 04/Jul/11 11:34 AM ]

Why fix this issue in 3.1.1?
o May result in support call
Which is the targeted build of 3.1.1 for this fix?
o b11
Do regression tests exist for this issue?
o No. need manual testing
Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
o verify the bug reported is fixed.

This is reproducible on windows only. And it's due to file path contains \ and / both.

Attached file diff for the same:
Index: src/main/java/com/sun/enterprise/server/logging/logviewer/backend/LogFilter.java
===================================================================
— src/main/java/com/sun/enterprise/server/logging/logviewer/backend/LogFilter.java (revision 47737)
+++ src/main/java/com/sun/enterprise/server/logging/logviewer/backend/LogFilter.java (working copy)
@@ -217,7 +217,8 @@
try { // getting log file attribute value from logging.properties file logFileDetailsForServer = loggingConfig.getLoggingFileDetails(); - logFileDetailsForServer = TranslatedConfigView.getTranslatedValue(logFileDetailsForServer).toString(); + logFileDetailsForServer = TranslatedConfigView.getTranslatedValue(logFileDetailsForServer).toString(); + logFileDetailsForServer = new File(logFileDetailsForServer).getAbsolutePath(); } catch (Exception ex) { logger.log(Level.SEVERE, "logging.backend.error.fetchrecord", ex); return new Vector(); @@ -245,7 +246,7 @@ return allInstanceFileNames; }

Comment by naman_mehta [ 05/Jul/11 06:21 AM ]

Approved by Bhavani.

Comment by naman_mehta [ 05/Jul/11 06:21 AM ]

Log Message:
------------
Fixing bug 16029.

Revisions:
----------
47846

Modified Paths:
---------------
branches/3.1.1/core/logging/src/main/java/com/sun/enterprise/server/logging/logviewer/backend/LogFilter.java

Diffs:
------
Index: branches/3.1.1/core/logging/src/main/java/com/sun/enterprise/server/logging/logviewer/backend/LogFilter.java
===================================================================
— branches/3.1.1/core/logging/src/main/java/com/sun/enterprise/server/logging/logviewer/backend/LogFilter.java (revision 47845)
+++ branches/3.1.1/core/logging/src/main/java/com/sun/enterprise/server/logging/logviewer/backend/LogFilter.java (revision 47846)
@@ -217,7 +217,8 @@
try { // getting log file attribute value from logging.properties file logFileDetailsForServer = loggingConfig.getLoggingFileDetails(); - logFileDetailsForServer = TranslatedConfigView.getTranslatedValue(logFileDetailsForServer).toString(); + logFileDetailsForServer = TranslatedConfigView.getTranslatedValue(logFileDetailsForServer).toString(); + logFileDetailsForServer = new File(logFileDetailsForServer).getAbsolutePath(); } catch (Exception ex) { logger.log(Level.SEVERE, "logging.backend.error.fetchrecord", ex); return new Vector(); @@ -245,7 +246,7 @@ return allInstanceFileNames; }

  • /*
    + /*
    This function is used to get log file details from logging.properties file for given target.
    */




[GLASSFISH-16025] Domain.xml: setting protocol.http-listener-1.http.max-connections set in 1 or -1 Created: 16/Feb/11  Updated: 13/Dec/11  Resolved: 13/Dec/11

Status: Resolved
Project: glassfish
Component/s: grizzly-kernel
Affects Version/s: 3.1_b38
Fix Version/s: 3.1.1

Type: Bug Priority: Minor
Reporter: tetyanac Assignee: oleksiys
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows XP


Tags: 3_1-release-note-added 3_1-release-notes
Participants: oleksiys, Scott Fordin and tetyanac

 Description   

Hi there,

with old documentaton for GF 3.0.1 I found that :

"http.max-connections property (optional) Specifies the maximum number of requests that can be pipelined until the connection is closed by the server. Set this property to 1 to disable HTTP/1.0 keep-alive, as well as HTTP/1.1 keep-alive and pipelined until the connection is closed by the server. A value of 0 means requests are always rejected. A value of -1 sets no limit to the number of keep-alive connections. "

Now I use the GF 3.1 (build 42) and I set protocol.http-listener-1.http.max-connections set into 1 and seems that connections are not closed(they are keep-alive). Is such behaviour correct?

When I set into -1, all connections are closed, but I am expecting to see them alive.

Could anybody explain how this setting works now for version 3.1?

Thank you



 Comments   
Comment by oleksiys [ 21/Feb/11 05:55 AM ]

it's a bug.

Workaround is following:

-1 is not working as unlimited, please use some big number up to Integer.MAX_VALUE.
1 - will let you process 1 keep-alive request, and close the connection after processing 2nd request on the same connection
0 - will disable keep-alive for the connection

Comment by Scott Fordin [ 13/Apr/11 11:58 AM ]

Added issue to 3.1 Release Notes.

Comment by oleksiys [ 13/Dec/11 02:35 PM ]

mark as fixed





[GLASSFISH-16013] RestartRequired: changing http port does not trigger restart required message for a standalone instance Created: 16/Feb/11  Updated: 08/Jul/11  Resolved: 07/Jul/11

Status: Closed
Project: glassfish
Component/s: web_container
Affects Version/s: 3.1_b43
Fix Version/s: 3.1.1_b05

Type: Bug Priority: Major
Reporter: lidiam Assignee: Amy Roh
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

promoted build b43


File Attachments: JPEG File change-ins-http-port.JPG    
Tags: 3_1_1-approved 3_1_1-verified
Participants: Amy Roh, lidiam, scatari, Scott Fordin and Tom Mueller

 Description   

Steps to reproduce:

1. Create a standalone instance and start it.
2. Go to instance's configuration, System Properties page and click on Instance Values link for HTTP port.
5. On the next page change the port to a new value, e.g. 28880, and save.
6. Go to instance's page and notice it's still running and does not report requiring restart. CLI reports instance as running as well:

  1. a list-instances
    in1 running

Attempting to access server on the newly specified port fails (28880), while it still responds on the old, default port 28080, hence restart is clearly required for the changes to take effect. The General tab for the instance lists new http port, even though the server is not listening on that port. This is misleading.



 Comments   
Comment by lidiam [ 16/Feb/11 02:14 PM ]

Testing of this feature was earlier blocked by http://java.net/jira/browse/GLASSFISH-14283.

Comment by Tom Mueller [ 17/Feb/11 07:01 AM ]

This is similar to issue GLASSFISH-15987.

If we automatically trigger a restart required notice when any system property is changed, then this bug will be resolved too.

Comment by Scott Fordin [ 18/Mar/11 01:14 PM ]

Added topic under "Restart Required" umbrella issue (http://java.net/jira/browse/GLASSFISH-16040) in 3.1 Release Notes.

Comment by Tom Mueller [ 21/Mar/11 09:35 AM ]

This issue turns out to be unrelated to issue 15987, since 15987 is specifically about system properties that are used in the JavaConfig.

Comment by Tom Mueller [ 22/Mar/11 07:19 AM ]

The root cause of this issue is that the ConfigListener that listens for changes to the NetworkListeners for the web container does not listen for changes to system properties, even though it resolved a system property in order to get the value of the port.

This appears to be an issue in the WebConfigListener class.

Note: a change in the port value due to a system property change may come from the domain, config, cluster, or server object. For example of a listener that listens for system property changes in all of these objects, see the GenericJavaConfigListener class in the core/kernel module.

Reassigning to the web container component.

Comment by Amy Roh [ 23/Mar/11 07:41 PM ]

Sending core/kernel/src/main/java/com/sun/enterprise/v3/admin/listener/GenericJavaConfigListener.java
Sending web/web-glue/src/main/java/com/sun/enterprise/web/WebContainer.java
Sending web/web-glue/src/main/java/com/sun/enterprise/web/reconfig/WebConfigListener.java
Transmitting file data ...
Committed revision 45700.

Fixed in web container so NotProcessed is triggered for SystemProperty events.

[#|2011-03-23T19:34:28.854-0700|WARNING|glassfish3.2|null|_ThreadID=21;_ThreadName=Thread-1;|Unprocessed event : UnprocessedChangeEvent{PropertyName=system-property, OldValue = null, NewValue = GlassFishConfigBean.com.sun.enterprise.config.serverbeans.SystemProperty, Source = GlassFishConfigBean.com.sun.enterprise.config.serverbeans.Server}, reason = The system-property, HTTP_LISTENER_PORT, that is referenced by the Java configuration, was modified, when = 1300934068647|#]

Although UnprocessedChangeEvent gets triggered correctly and displayed in instance's server.log, Admin GUI doesn't show restart required sign. Assigning to Admin GUI team to investigate and to display the sign correctly in the GUI.

Comment by Amy Roh [ 05/Apr/11 12:39 PM ]

Assigning it back to myself to fix dynamic reconfig to happen rather than returning UnprocessedChangeEvent when System Property for ports have been updated.

Comment by Amy Roh [ 07/Apr/11 10:18 AM ]

Fixed. Added dynamic reconfig support for http port on standalone instance.

Sending core/kernel/src/main/java/com/sun/enterprise/v3/services/impl/DynamicConfigListener.java
Sending core/kernel/src/main/java/com/sun/enterprise/v3/services/impl/GrizzlyService.java
Sending web/web-glue/src/main/java/com/sun/enterprise/web/reconfig/WebConfigListener.java
Committed revision 45965.

Comment by Amy Roh [ 10/May/11 10:52 AM ]

Why fix this issue in 3.1.1?


A partial fix (svn 45700) for issue 16013 went into the 3.1.1 branch because the 3.1.1 branch was created after the partial patch went in. Since the branch was created, the complete fix (svn 45965) was committed to the trunk to ignore unrelated events. The same should apply to the branch.

Which is the targeted build of 3.1.1 for this fix?

Build 5.

Do regression tests exist for this issue?

No.

Which tests should QA (re)run to verify the fix did not destabilize GlassFish?

SQE webtier tests

Comment by scatari [ 10/May/11 11:13 AM ]

Approved.

Comment by lidiam [ 06/Jul/11 11:56 PM ]

Tested on ogs-3.1.1-b11-07_04_2011-aix.zip and the issue is still present. Changed HTTP_LISTENER_PORT of standalone instance, in1, to 85 but there is no restart required message:

/export/sqe/lidia/glassfish3/glassfish % asadmin list-instances
in1 running
cl1in1 running
cl1in2 running
Command list-instances executed successfully.

However, the fix may have affected a different issue just logged: http://java.net/jira/browse/GLASSFISH-16976.

Comment by lidiam [ 07/Jul/11 12:01 AM ]

Attaching screenshot of changed http port.

Comment by Amy Roh [ 07/Jul/11 12:51 AM ]

There is no restart required message because restart is not required.

After changing the instance's HTTP_LISTENER_PORT, accessing server on the newly specified port should succeed.





[GLASSFISH-16010] Restart Required: After changing JMS Type server instance is not reported as requiring restart Created: 16/Feb/11  Updated: 07/Jul/11  Resolved: 05/May/11

Status: Closed
Project: glassfish
Component/s: jms
Affects Version/s: 3.1_b43
Fix Version/s: 3.1.1_b05

Type: Bug Priority: Major
Reporter: lidiam Assignee: Satish Kumar
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

promoted build b43


Tags: 3_1_1-approved 3_1_1-verified
Participants: Chris Kasso, lidiam, Nazrul, Satish Kumar, sb110099, scatari and Scott Fordin

 Description   

Steps to reproduce:

1. In Admin Console create a standalone instance and start it.
2. Go to instance's coniguration, Java Message Service page.
3. Change Type field from EMBEDDED to REMOTE and click Save.
4. Go to standalone instance page - it shows as running and restart required image is not displayed.

Please see a related issue http://java.net/jira/browse/GLASSFISH-15516.



 Comments   
Comment by Chris Kasso [ 16/Feb/11 01:46 PM ]

We have a collection of "Restart Required" issues that remain unresolved in 3.1. This likely warrants an umbrella Release Note item which addresses the more general problems we are seeing in this area. Here's a query that identifies many of the existing "Restart Required" issues:

http://java.net/jira/secure/IssueNavigator.jspa?mode=hide&requestId=10358

Comment by sb110099 [ 17/Feb/11 12:22 PM ]

Agree . Lidia will open an umbrella doc bug and link this query for all bugs related to "restart-required" for 3.1 Release Notes.

Just to clarify here, there is a lack of clarity from dev side regarding where "restart required " is to be triggered. We faced this issue earlier in the release and could not continue with V2 documentation. We are revisiting this area and making sure we have most of the bugs that can eventually fixed in future release and/or doc is updated accordingly . We still cannot ensure we have tried all scenarios unless there is a guiding document describing the expected functionality,

--Sudipa

Comment by lidiam [ 17/Feb/11 02:30 PM ]

Created an umbrella doc bug http://java.net/jira/browse/GLASSFISH-16040.

Comment by Scott Fordin [ 07/Mar/11 05:08 PM ]

Added issue to 3.1 Release Notes as part of "Restart Required" umbrella issue.

Comment by Scott Fordin [ 24/Mar/11 02:35 PM ]

Added "3_1-release-note-added" tag. Reopened issue because it was not mine to close.

Comment by Nazrul [ 20/Apr/11 01:12 PM ]

We should try to fix this during 3.1.1

Comment by scatari [ 29/Apr/11 12:08 PM ]

Approved.

Comment by Satish Kumar [ 05/May/11 09:12 PM ]

Added support for showing restart required when changes are made to the jms-service element.

Comment by lidiam [ 07/Jul/11 12:29 AM ]

Verified in build ogs-3.1.1-b11-07_04_2011-aix.zip - restart is required now.





[GLASSFISH-15999] Description of create-jacc-provider references JSR196 but the command has nothing to do with JSR196 and JAAS Created: 15/Feb/11  Updated: 11/Jul/11  Resolved: 11/Jul/11

Status: Closed
Project: glassfish
Component/s: docs
Affects Version/s: 3.1_b41
Fix Version/s: 3.1.1

Type: Bug Priority: Major
Reporter: kumarjayanti Assignee: kevinmcd
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1-exclude
Participants: kevinmcd, kumarjayanti, Paul Davies and Scott Fordin

 Description   

The description of create-jacc-provider references JSR196 and JAAS but it has nothing to do with those specs.

Here is what the Description should look like :

The create-jacc-provider subcommand creates a JSR-115
compliant Java Authorization Contract for Containers (JACC)
provider that can be used for authorization of applications
running in GlassFish Server. The JACC provider is created as
a jacc-provider element within the security-service element
in the domain's domain.xml file.

The default GlassFish Server installation includes two JACC
providers, named default and simple. Any JACC providers
created with the create-jacc-provider subcommand are in
addition to these two default providers. The default GlassF-
ish Server JACC providers implement a simple, file-based
authorization engine that complies with the JACC specifica-
tion. The create-jacc-provider subcommand makes it possible
to specify additional third-party JACC providers.

Any number of jacc-provider's can be created under the security-service
but the GlassFish runtime would use one of them at any given point. The jacc
attribute on the security-service points to the name of the provider that is
currently in use by glassfish. Any change to the jacc attribute (to make it
point to a different jacc-provider) would require restart of the server.
This command is supported in remote mode only.



 Comments   
Comment by kumarjayanti [ 15/Feb/11 08:47 PM ]

there is also some extra "\fR" character appearing in the sample commandline, not sure if this is some standard way of showing things. IMO it should be cleaned up.

---------current----
asadmin> create-jacc-provider \fR
--policyproviderclass com.sun.enterprise.security.provider.PolicyWrapper
--policyconfigfactoryclass com.sun.enterprise.security.provider.PolicyConfigurationFactoryImpl
-------------------

should be :

asadmin> create-jacc-provider
--policyproviderclass com.sun.enterprise.security.provider.PolicyWrapper
--policyconfigfactoryclass com.sun.enterprise.security.provider.PolicyConfigurationFactoryImpl

Comment by kumarjayanti [ 15/Feb/11 08:58 PM ]

In the description of delete-jacc-provider please reword the following paragraph :

--------
Authorization modules that depend on the JACC provider to be
deleted should be reconfigured to work with an alternate
provider before the deletion.

---------

TO

--------
The JACC provider used by GlassFish for authorization is specified by the jacc attribute on the security-service configuration element. So if you are deleting the provider pointed to by the jacc attribute then make sure the attribute value is also changed to the name of some other jacc-provider that exists under the security-service. Any change to the jacc attribute of a running service would require restart of the server.
--------

Comment by Scott Fordin [ 21/Mar/11 05:28 PM ]

Added topic to 3.1 Release Notes. Will make corrections to man pages for 3.2 release. Removing release notes tag.

Comment by Paul Davies [ 27/May/11 10:11 AM ]

Under consideration for fixing in the 3.1.1 bundled docs

Comment by Scott Fordin [ 31/May/11 10:14 AM ]

Reassigning to Paul Davies.

Comment by Paul Davies [ 07/Jun/11 02:25 PM ]

Reassigned to the security writer

Comment by kevinmcd [ 15/Jun/11 02:33 PM ]

Text changed as indicated. I reworded it a little, and changed "jacc attribute" to "jacc-provider element." I will update the bug status when the revised manpages are available in the build.

Comment by kevinmcd [ 11/Jul/11 08:58 PM ]

Change appears in svn revision 47759, which I checked in the nightly build of 07-Jul-2011.





[GLASSFISH-15998] Man page for list-supported-cipher-suites Created: 15/Feb/11  Updated: 11/Jul/11  Resolved: 11/Jul/11

Status: Closed
Project: glassfish
Component/s: docs
Affects Version/s: 3.1_b41
Fix Version/s: 3.1.1

Type: Bug Priority: Major
Reporter: kumarjayanti Assignee: kevinmcd
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1-exclude
Participants: kevinmcd, kumarjayanti, Paul Davies and Scott Fordin

 Description   

The man page of list-supported-cipher-suites lists the kerberos cipher (KRB5) suites. But the command output does not list them.

here is the command output :

SSL_RSA_WITH_RC4_128_MD5
SSL_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_DSS_WITH_AES_128_CBC_SHA
TLS_DHE_DSS_WITH_AES_256_CBC_SHA
SSL_RSA_WITH_3DES_EDE_CBC_SHA
SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
SSL_RSA_WITH_DES_CBC_SHA
SSL_DHE_RSA_WITH_DES_CBC_SHA
SSL_DHE_DSS_WITH_DES_CBC_SHA
SSL_RSA_EXPORT_WITH_RC4_40_MD5
SSL_RSA_EXPORT_WITH_DES40_CBC_SHA
SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
TLS_EMPTY_RENEGOTIATION_INFO_SCSV
SSL_RSA_WITH_NULL_MD5
SSL_RSA_WITH_NULL_SHA
SSL_DH_anon_WITH_RC4_128_MD5
TLS_DH_anon_WITH_AES_128_CBC_SHA
TLS_DH_anon_WITH_AES_256_CBC_SHA
SSL_DH_anon_WITH_3DES_EDE_CBC_SHA
SSL_DH_anon_WITH_DES_CBC_SHA
SSL_DH_anon_EXPORT_WITH_RC4_40_MD5
SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA

Note: many months ago the CLI code was fixed to explicitly exclude the Kerberos ones. But i guess this was not communicated explicitly to docs team.



 Comments   
Comment by Paul Davies [ 16/Feb/11 07:20 PM ]

Too late for 3.1.

Comment by Scott Fordin [ 17/Mar/11 04:14 PM ]

Added the topic to 3.1 Release Notes. Will correct the man page in the 3.2 build. Removing release notes tag from the issue now.

Comment by Paul Davies [ 27/May/11 10:13 AM ]

Under consideration for fixing in the 3.1.1 bundled docs

Comment by Scott Fordin [ 31/May/11 10:14 AM ]

Reassigning to Paul Davies.

Comment by Paul Davies [ 07/Jun/11 02:13 PM ]

Reassigned to security writer.

Comment by kevinmcd [ 14/Jun/11 07:34 AM ]

I have removed the KRB5 cipher suites from the manpage. I'll update the status when this version of the manpage is available.

Comment by kevinmcd [ 11/Jul/11 09:00 PM ]

Change appears in svn revision 47759, which I checked in the nightly build of 07-Jul-2011.





[GLASSFISH-15997] Intermittent issue : Left tree not refreshed when new elements are added/removed in IE and firefox. Created: 15/Feb/11  Updated: 12/Mar/13

Status: Open
Project: glassfish
Component/s: admin_gui
Affects Version/s: 3.1_b43
Fix Version/s: 4.0

Type: Bug Priority: Minor
Reporter: shaline Assignee: Jason Lee
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

OS: Windows 2008, and Sparc.
Browsers : IE7, 8 and firefox 3.6


File Attachments: JPEG File screenshot-1.jpg    
Issue Links:
Duplicate
is duplicated by GLASSFISH-16967 GUI does not correctly synchronize tr... Resolved
is duplicated by GLASSFISH-17230 Deleting a cluster does not refresh t... Resolved
is duplicated by GLASSFISH-18286 Regression: nodes tree not updated wi... Resolved
Tags:
Participants: Anissa Lam, Jason Lee, lidiam, Scott Fordin and shaline

 Description   

Build used : GF V3.1 promoted b43.

Sometimes in IE and firefox browsers, when new elements are added, Ex: JDBC Pools, resources, new Configurations, Virtual servers, etc, the left tree node does not get refreshed, while we do see the new items in the right table. This issue is not consistently reproducible and is very intermittent. Reloading the Console solves the issue and displays the new values in the left tree node.
This issue can be documented.



 Comments   
Comment by lidiam [ 16/Feb/11 09:58 PM ]

This is happening very often for me. I think it depends how long Admin Console is in use. The bad thing is that once I remove an element, e.g. a cluster, it is not removed from the nodes tree. I can still click on it there and get the following error:

An error has occurred
The target, c1, is not an instance, cluster, domain, node or config.

I'll attach a screenshot for that.

Once this problem starts, it does not go away till the url is reloaded.

Comment by Anissa Lam [ 14/Mar/11 05:21 PM ]

Summary and workaround:

This issue is not consistently reproducible and is very intermittent. Reloading the Console by pressing the Home button or browser's reload button solves the issue and displays the new values in the left tree node.

Comment by Scott Fordin [ 13/Apr/11 12:21 PM ]

Added issue to 3.1 Release Notes.

Comment by shaline [ 08/Nov/11 12:47 AM ]

I still see this issue on GF 3.1.2 promoted and nightly builds. This issue shows up if the Admin Console is used for quite sometime, and then any new elements added like resources, network listeners, virtual servers, realms, clusters, instances etc , do not show up in the left tree. Even the deleted elements does not get deleted from the left tree. We have to use the browser's reload button for this problem to go away.

Comment by Anissa Lam [ 12/Feb/13 12:27 AM ]

Issues need to be addressed before 4.0 HCF (3/25)

Comment by Anissa Lam [ 12/Mar/13 05:28 PM ]

This is Intermittent with easy work around.
We will continue release notes this. The work around is to click the Home button and the tree should be refreshed correctly.





[GLASSFISH-15987] Display Restart Required when a system-property which is referenced by a jvm-option is changed Created: 15/Feb/11  Updated: 07/Apr/11  Resolved: 17/Mar/11

Status: Resolved
Project: glassfish
Component/s: admin
Affects Version/s: 3.1_b41
Fix Version/s: 3.1.1_b01

Type: Bug Priority: Major
Reporter: Jennifer Chou Assignee: Tom Mueller
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1-exclude 3_1-release-note-added 3_1-release-notes
Participants: Chris Kasso, Jennifer Chou, Scott Fordin and Tom Mueller

 Description   

Restart Required should also appear in Admin Console and 'asadmin list-domains' when a change is made to the system-property which is referenced by a jvm-option. In the code we need to
check if the system property is changed and referenced by a jvm-options
and show the Restart Required.

For example in server-config:

1) Create a system property
<system-property name="JVM_HEAP_SIZE" value="1090m"></system-property>

2) Change jvm option to use system property
<jvm-options>-Xmx${JVM_HEAP_SIZE}</jvm-options>

3) Restart GlassFish

4) Change system property value for JVM_HEAP_SIZE

5) Upper left of Admin Console does not show Restart Required
asadmin list-domains does not show 'requires restart'

Checked on v2.1.1, that changing a system-property referenced by a jvm-option, show restart required in asadmin list-domains (The Admin Console doesn't display):

C:\glassfish-v2.1.1-b31g\glassfish\bin>asadmin list-domains
domain1 requires restart
Command list-domains executed successfully.



 Comments   
Comment by Jennifer Chou [ 15/Feb/11 09:47 AM ]

I checked in v2.1.1 that even a change to a system property that's not referenced by anything else, will trigger a restart required to be displayed.

C:\glassfish-v2.1.1-b31g\glassfish\bin>asadmin list-domains
domain1 requires restart
Command list-domains executed successfully.

So in the code, we can just check whether a system property is changed and trigger a restart required state.

Comment by Chris Kasso [ 16/Feb/11 01:45 PM ]

We have a collection of "Restart Required" issues that remain unresolved in 3.1. This likely warrants an umbrella Release Note item which addresses the more general problems we are seeing in this area. Here's a query that identifies many of the existing "Restart Required" issues:

http://java.net/jira/secure/IssueNavigator.jspa?mode=hide&requestId=10358

Comment by Tom Mueller [ 01/Mar/11 02:55 PM ]

The root cause of this problem is that when a system property change is made, the GenericJavaConfigListener class does not take into account that some JVM options, such as -Xmx, might be depending on the value of a system property, so the system property change event is not returned from GenericJavaConfigListener as an UnprocessedChangeEvent, so the UnprocessedConfigListener doesn't pick it up to set the restart required flag.

The processing of the JVM options, including resolution of property values, occurs within the launcher, which is executed by asadmin, not the server (specifically in the GFLauncher class when it calls TokenResolver). There is no record kept of what tokens were resolved, or where they came from.

Considering this a bit deeper, the token resolution that occurs for JVM options uses as its sources the following:

1. the shell environment, e.g., "export a=b"
2. values in the asenv.conf or asenv.bat file
3. values passed via -Da=b as specified in the asadmin script
4. system-properties in the domain.xml (server, config, and domain)
5. JVM options (-Da=b in the jvm-options in the domain.xml)
6. profiler properties (from the domain.xml)

If any of these change such that the JVM options would be recalculated for the instance, then a restart-required should be triggered. For example, if the asenv.conf file or asadmin file is edited, or the user changes their environment. The server cannot detect changes in the latter, but it could be looking at those files. This bug is only about changes to system-properties in the domain.xml, but it does raise the question of what else should be checked too.

The suggested fix for this bug is to modify the GenericJavaConfigListener class so that it looks at the token that are referenced by the JVM options, and if the value of a token changes, then the change should be returned as an UnprocessedChangeEvent. This will require making GenericJavaConfigListener listen for system property change notifications.

Comment by Scott Fordin [ 07/Mar/11 05:14 PM ]

Added issue to 3.1 Release Notes as part of "Restart Required" umbrella issue.

Comment by Tom Mueller [ 08/Mar/11 11:15 AM ]

This isn't actually fixed yet.

Comment by Tom Mueller [ 17/Mar/11 01:10 PM ]

Fixed in revision 45608 on the trunk.

If a system-property is referenced by a JVM option, any change to that any system property with that name will cause a restart-required, even if the actual value did not change. For example, consider this:

<domain>
<system-property name="foo" value="bar"/>
<servers>
<server config-ref="server-config">
<system-property name="foo" value="baz"/>
</server>
</servers>
<configs>
<config name="server-config">
<java-config>
<jvm-options>-Dabc=${foo}</jvm-options>
</java-config>
</config>
</configs>
</domain>

If you then do:
asadmin create-system-property --target domain foo=xyz

This will trigger the restart-required flag, even though the <server> value is really overriding the value for foo, so when the server restarts, the value of the abc property won't change.

If this really bothers you, please file another issue.

However, the fix that is checked in fixes the problem from the initial description.

Comment by Scott Fordin [ 18/Mar/11 01:09 PM ]

Added topic under "Restart Required" umbrella issue (http://java.net/jira/browse/GLASSFISH-16040) in 3.1 Release Notes.

Comment by Scott Fordin [ 24/Mar/11 02:37 PM ]

Added "3_1-release-note-added" tag.





[GLASSFISH-15986] Column APPLICATIONID is missing from bundled sql scripts for ejb timer table creation. Created: 15/Feb/11  Updated: 13/Apr/11  Resolved: 04/Mar/11

Status: Resolved
Project: glassfish
Component/s: ejb_container
Affects Version/s: 3.1_b41
Fix Version/s: 3.1.1_b01

Type: Bug Priority: Major
Reporter: sonymanuel Assignee: marina vatkina
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1-exclude 3_1-release-note-added 3_1-release-notes
Participants: marina vatkina, Scott Fordin and sonymanuel

 Description   

In 3.1, the bundled timer table creation sql scripts are missing column APPLICATIONID.

sony@nila:/home2/sony/builds/glassfish3/glassfish/lib/install/databases$ cat ejbtimer_derby.sql
CREATE TABLE EJB_TIMER_TBL (
CREATIONTIMERAW BIGINT NOT NULL,
BLOB BLOB(2G),
TIMERID VARCHAR(255) NOT NULL,
CONTAINERID BIGINT NOT NULL,
OWNERID VARCHAR(255),
STATE INTEGER NOT NULL,
PKHASHCODE INTEGER NOT NULL,
INTERVALDURATION BIGINT NOT NULL,
INITIALEXPIRATIONRAW BIGINT NOT NULL,
LASTEXPIRATIONRAW BIGINT NOT NULL,
SCHEDULE VARCHAR(255),
CONSTRAINT PK_EJB_TIMER_TBL PRIMARY KEY (TIMERID)
) ;



 Comments   
Comment by marina vatkina [ 15/Feb/11 09:56 AM ]

I'm not sure how this could happen, but all but one .sql files are missing this column. The sql files are for the user as a ref point, or to be able to create the table themselves. By default EJB Timer service creates the table on the 1st deploy.

Fixing the files won't affect the execution.

Comment by marina vatkina [ 15/Feb/11 10:15 AM ]

Fixed on trunk with rev 45149

Comment by Scott Fordin [ 04/Mar/11 11:03 AM ]

Need more information to add to notes.

Comment by Scott Fordin [ 04/Mar/11 11:50 AM ]

Added issue to 3.1 Release Notes.

Comment by Scott Fordin [ 24/Mar/11 02:38 PM ]

Added "3_1-release-note-added" tag.





[GLASSFISH-15985] NullPointerException when accessing OSGi web application Created: 15/Feb/11  Updated: 04/Nov/11  Resolved: 04/Nov/11

Status: Resolved
Project: glassfish
Component/s: jsf
Affects Version/s: 3.1_b38, 3.1_b41 , 3.1_b42
Fix Version/s: 3.1.1_b01

Type: Bug Priority: Major
Reporter: chaoslayer Assignee: Ed Burns
Resolution: Fixed Votes: 4
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

File Attachments: File dummy-web.war     Text File message.txt     Text File server-3.1-b36.log     Text File server-3.1-b37.log    
Status Whiteboard:

jsf_2_1_1

Tags: 3_1-exclude 3_1-release-note-added 3_1-release-notes
Participants: chaoslayer, Ed Burns, rogerk, Sanjeeb Sahoo, Scott Fordin and Shing Wai Chan

 Description   

Deployment of the web application works fine:

INFO: Installed /srv/server/glassfish/3.1-b42/glassfish/domains/domain1/autodeploy/bundles/dummy-web.war
INFO: Started bundle: file:/srv/server/glassfish/3.1-b42/glassfish/domains/domain1/autodeploy/bundles/dummy-web.war
INFO: Started bundle: file:/srv/server/glassfish/3.1-b42/glassfish/domains/domain1/autodeploy/bundles/dummy-web.war
INFO: Expanded at file:/tmp/osgiapp6345962157332461681/
INFO: SEC1002: Security Manager is OFF.
INFO: SEC1010: Entering Security Startup Service
INFO: SEC1143: Loading policy provider com.sun.enterprise.security.provider.PolicyWrapper.
INFO: SEC1115: Realm [admin-realm] of classtype [com.sun.enterprise.security.auth.realm.file.FileRealm] successfully created.
INFO: SEC1115: Realm [file] of classtype [com.sun.enterprise.security.auth.realm.file.FileRealm] successfully created.
INFO: SEC1115: Realm [certificate] of classtype [com.sun.enterprise.security.auth.realm.certificate.CertificateRealm] successfully created.
INFO: SEC1011: Security Service(s) Started Successfully
INFO: WEB0169: Created HTTP listener [http-listener-1] on host/port [0.0.0.0:8080]
INFO: WEB0169: Created HTTP listener [http-listener-2] on host/port [0.0.0.0:8181]
INFO: WEB0169: Created HTTP listener [admin-listener] on host/port [0.0.0.0:4848]
INFO: WEB0171: Created virtual server [server]
INFO: WEB0171: Created virtual server [__asadmin]
INFO: WEB0172: Virtual server [server] loaded default web module []
INFO: Portable JNDI names for EJB DummySingleton : [java:global/org.glassfish.osgi.dummy-web_1.0.0.SNAPSHOT/DummySingleton, java:global/org.glassfish.osgi.dummy-web_1.0.0.SNAPSHOT/DummySingleton!org.glassfish.osgi.web.dummy.DummySingletonLocal]
INFO: WELD-000900 ${parsedVersion (osgiVersion})
INFO: Instantiated an instance of org.hibernate.validator.engine.resolver.JPATraversableResolver.
INFO: total number of classes with faces annotation = 0
INFO: Total number of available updates : 0
INFO: Initializing Mojarra 2.1.0 (FCS 2.1.0-b11) for context '/dummy-web'
INFO: Faces Config uris excluding the ones named as faces-config.xml = []
INFO: Facelet Config uris = [embeddedjar:bundle://252.0:0/WEB-INF/lib/prettyfaces-jsf2-3.2.0.jar!/META-INF/ocpsoft-pretty-faces.taglib.xml]
INFO: PrettyFilter starting up...
INFO: PrettyFilter initialized.
INFO: WEB0671: Loading application [org.glassfish.osgi.dummy-web_1.0.0.SNAPSHOT] at [/dummy-web]
INFO: Registered ServletContext as a service with properties: {osgi.web.symbolicname=org.glassfish.osgi.dummy-web, osgi.web.version=1.0.0.SNAPSHOT, osgi.web.contextpath=/dummy-web}
INFO: deployed bundle org.glassfish.osgi.dummy-web [252] at file:/tmp/osgiapp6345962157332461681/

...but when I try to access it via HTTP:

SEVERE: WebModule[/dummy-web]PWC1321: Error invoking requestInitialized method on ServletRequestListener com.ocpsoft.pretty.faces.config.PrettyConfigListener
java.lang.NullPointerException
at com.sun.faces.application.ServletContextSensitiveSingletonStore.<init>(ServletContextSensitiveSingletonStore.java:83)
at com.sun.faces.application.ApplicationFactoryImpl.getApplication(ApplicationFactoryImpl.java:92)
at com.ocpsoft.pretty.faces.util.FacesFactory.getApplication(FacesFactory.java:31)
at com.ocpsoft.pretty.faces.config.PrettyConfigListener.requestInitialized(PrettyConfigListener.java:34)
at org.apache.catalina.core.StandardContext.fireRequestInitializedEvent(StandardContext.java:4551)
at org.apache.catalina.core.StandardHostValve.preInvoke(StandardHostValve.java:626)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:154)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:326)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:227)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:170)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:822)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:719)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1013)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:662)

attached a test case (dummy-web.war).

I've tested this against b33, b36, b38, b41, and b42. Up to b36 all was fine, starting with b41 the above exception is being thrown.

In b38, the behavior was even more strange:

^^ ???

...HTTP access returned a 404 (expected after those lines), but a OSGi bundle "refresh" yield this:

INFO: Expanded at file:/tmp/osgiapp8864019535236458366/
INFO: Deleted /tmp/osgiapp8864019535236458366
SEVERE: Failed while deploying bundle org.glassfish.osgi.dummy-web [369]
INFO: Removed bundle 369 against context path /dummy-web
WARNING: Failed to deploy bundle org.glassfish.osgi.dummy-web [369]
org.glassfish.osgijavaeebase.DeploymentException: Deployment of org.glassfish.osgi.dummy-web [369] failed because of following reason: Failed while deploying bundle org.glassfish.osgi.dummy-web [369] : java.lang.RuntimeException: Failed to deploy bundle [ org.glassfish.osgi.dummy-web [369] ], root cause: Application name org.glassfish.osgi.dummy-web_1.0.0.SNAPSHOT is already in use. Please pick a different name.
at org.glassfish.osgijavaeebase.AbstractOSGiDeployer.deploy(AbstractOSGiDeployer.java:125)
at org.glassfish.osgijavaeebase.OSGiContainer.deploy(OSGiContainer.java:154)
at org.glassfish.osgijavaeebase.JavaEEExtender.deploy(JavaEEExtender.java:107)
at org.glassfish.osgijavaeebase.JavaEEExtender.access$200(JavaEEExtender.java:61)
at org.glassfish.osgijavaeebase.JavaEEExtender$HybridBundleTrackerCustomizer$1.call(JavaEEExtender.java:151)
at org.glassfish.osgijavaeebase.JavaEEExtender$HybridBundleTrackerCustomizer$1.call(JavaEEExtender.java:148)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
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:662)
Caused by: java.lang.RuntimeException: Failed to deploy bundle [ org.glassfish.osgi.dummy-web [369] ], root cause: Application name org.glassfish.osgi.dummy-web_1.0.0.SNAPSHOT is already in use. Please pick a different name.
at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.deploy(OSGiDeploymentRequest.java:196)
at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.execute(OSGiDeploymentRequest.java:118)
at org.glassfish.osgijavaeebase.AbstractOSGiDeployer.deploy(AbstractOSGiDeployer.java:121)
... 10 more



 Comments   
Comment by Shing Wai Chan [ 15/Feb/11 10:35 AM ]

This is an OSGi jsf web application.
There are two issues here:
(1) The first access of OSGi web application have NPE.
(2) There is a problem in redeployment of OSGi web application.

Assign to jsf team to investigate (1).

Comment by rogerk [ 15/Feb/11 10:38 AM ]

Assigning to Ed as prior commit may be the cause.

Comment by Ed Burns [ 15/Feb/11 11:26 AM ]

Does the server configuration in which this bug manifests use clusters or virtual servers?

Comment by Ed Burns [ 15/Feb/11 11:28 AM ]

Because this is an OSGi web application, I assume I must deploy it with "--type osgi" correct?

Comment by Ed Burns [ 15/Feb/11 11:32 AM ]

I can reproduce the problem.

Here is the log output.

Comment by Ed Burns [ 15/Feb/11 11:39 AM ]

By omitting the --type osgi argument from the deployment, this causes the problem to not manifest. Of course, it is a real bug, but it is not a blocker for 3.1.

Comment by chaoslayer [ 15/Feb/11 12:02 PM ]

I usually deploy those WABs using the .../autodeploy/bundles/ Felix FileInstall watch directory.

Apart from that I disagree by excluding this for the 3.1 release because it is a real regression and OSGi/JavaEE is a real target for GlassFish 3.1 and we already use it (currently with b36) just short before our application release.

As there are numerous issues resolved since b36 regarding stability/performance and bugfixes we are seriously looking forward to use a later build and hopefully switch to the final release.

However, this bug would completely block us doing so and we'll have to live with workarounds/hacks.

Comment by Sanjeeb Sahoo [ 16/Feb/11 09:56 AM ]

Can anyone tell me which check-in caused this regression? It is sad that we have caused a regression in builds just prior to release of 3.1.

Comment by chaoslayer [ 16/Feb/11 11:21 AM ]

Just tested the b37 and even that one is affected by this problem.

I've attached two log files for comparison both with felix log level set to DEBUG in order to see, if that's a wiring problem, but doesn't seem so.

Log files:

  • server-3.1-b36.log - OK
  • server-3.1-b37.log - FAIL
Comment by chaoslayer [ 16/Feb/11 03:17 PM ]

Well, as the "FacesContext.getCurrentInstance()" returns "null" (introduced by Mojarra 2.1-b10), I just thought about adding a custom faces-config (stored in a file "META-INF/weld.faces-config.xml") with the following content:

<faces-config xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-facesconfig_2_0.xsd"
version="2.0">
<factory>
<application-factory>org.glassfish.weld.jsf.WeldApplicationFactory</application-factory>
</factory>

</faces-config>

...and now it works. So basically it seems, that FacesContext.setCurrentInstance is not called unless I provide a specific application factory class, weird...

...a little debugging against a 3.1-b41 with mojarra 2.1-b11 yield the following:

Breakpoint hit at line 83 in class com.sun.faces.application.ServletContextSensitiveSingletonStore by thread http-thread-pool-8080(3).
Thread http-thread-pool-8080(3) stopped at ServletContextSensitiveSingletonStore.java:83.
User program running
Breakpoint hit at line 845 in class javax.faces.context.FacesContext by thread http-thread-pool-8080(3).
Thread http-thread-pool-8080(3) stopped at FacesContext.java:845.
User program running
Breakpoint hit at line 83 in class com.sun.faces.application.ServletContextSensitiveSingletonStore by thread http-thread-pool-8080(3).
Thread http-thread-pool-8080(3) stopped at ServletContextSensitiveSingletonStore.java:83.
User program running
Breakpoint hit at line 845 in class javax.faces.context.FacesContext by thread http-thread-pool-8080(3).
Thread http-thread-pool-8080(3) stopped at FacesContext.java:845.
User program running

...so the "FacesContext.setCurrentInstance()" is always called after the call to "FacesContext.getCurrentInstance()" is issued by the ServletContextSensitiveSingletonStore which is obviously the wrong order things should happen.

Using the custom *.faces-config.xml file I see the following invocations:

Breakpoint hit at line 845 in class javax.faces.context.FacesContext by thread http-thread-pool-8080(4).
Thread http-thread-pool-8080(4) stopped at FacesContext.java:845.
User program running
Breakpoint hit at line 83 in class com.sun.faces.application.ServletContextSensitiveSingletonStore by thread http-thread-pool-8080(4).
Thread http-thread-pool-8080(4) stopped at ServletContextSensitiveSingletonStore.java:83.
User program running
Breakpoint hit at line 845 in class javax.faces.context.FacesContext by thread http-thread-pool-8080(4).
Thread http-thread-pool-8080(4) stopped at FacesContext.java:845.
User program running
Breakpoint hit at line 845 in class javax.faces.context.FacesContext by thread http-thread-pool-8080(4).
Thread http-thread-pool-8080(4) stopped at FacesContext.java:845.
User program running
Breakpoint hit at line 83 in class com.sun.faces.application.ServletContextSensitiveSingletonStore by thread http-thread-pool-8080(4).
Thread http-thread-pool-8080(4) stopped at ServletContextSensitiveSingletonStore.java:83.
User program running
Breakpoint hit at line 845 in class javax.faces.context.FacesContext by thread http-thread-pool-8080(4).
Thread http-thread-pool-8080(4) stopped at FacesContext.java:845.
User program running

...which seems totally correct.

Comment by chaoslayer [ 21/Feb/11 01:57 AM ]

Any progress on this one?

Comment by Ed Burns [ 02/Mar/11 12:58 PM ]

Ok, I see the same problem, even today.

Investigating further.

Comment by Ed Burns [ 03/Mar/11 09:31 PM ]

Committed to trunk.

Sending jsf-ri/src/main/java/com/sun/faces/application/ApplicationAssociate.java
Sending jsf-ri/src/main/java/com/sun/faces/application/ApplicationFactoryImpl.java
Sending jsf-ri/src/main/java/com/sun/faces/application/InjectionApplicationFactory.java
Deleting jsf-ri/src/main/java/com/sun/faces/application/ServletContextSensitiveSingletonStore.java
Sending jsf-ri/src/main/java/com/sun/faces/application/WebappLifecycleListener.java
Sending jsf-ri/src/main/java/com/sun/faces/config/ConfigureListener.java
Adding jsf-test/GLASSFISH-15985
Adding jsf-test/GLASSFISH-15985/build.xml
Adding (bin) jsf-test/GLASSFISH-15985/dummy-web.war
Sending jsf-test/build.xml
Transmitting file data ........
Committed revision 8887.

Comment by Ed Burns [ 04/Mar/11 09:38 PM ]

Sending jsf-ri/src/main/java/com/sun/faces/application/ApplicationAssociate.java
Sending jsf-ri/src/main/java/com/sun/faces/application/ApplicationFactoryImpl.java
Sending jsf-ri/src/main/java/com/sun/faces/application/InjectionApplicationFactory.java
Deleting jsf-ri/src/main/java/com/sun/faces/application/ServletContextSensitiveSingletonStore.java
Sending jsf-ri/src/main/java/com/sun/faces/application/WebappLifecycleListener.java
Sending jsf-ri/src/main/java/com/sun/faces/config/ConfigureListener.java
Adding jsf-test/GLASSFISH-15985
Adding jsf-test/GLASSFISH-15985/build.xml
Adding (bin) jsf-test/GLASSFISH-15985/dummy-web.war
Sending jsf-test/build.xml
Transmitting file data ......
Committed revision 8899.

Comment by Sanjeeb Sahoo [ 04/Mar/11 09:41 PM ]

This bug needs to remain opened until a version of mojarra containing the fix is integrated.

Comment by Scott Fordin [ 23/Mar/11 06:32 PM ]

Need more info to add issue to 3.1 Release Notes.

Comment by Ed Burns [ 08/Apr/11 11:27 AM ]

Integrated into GlassFish 3.1.1

Comment by Scott Fordin [ 13/Apr/11 08:09 AM ]

Release Note still needed?

Comment by Ed Burns [ 14/Apr/11 04:57 AM ]

Release notes are only needed if you are writing releasenotes for 3.1.

Comment by Scott Fordin [ 14/Apr/11 06:34 AM ]

Thanks. I go back to my previous comment then: I need more info to include these in the 3.1 Release Notes. Specifically, a concise description and workaround.

Comment by Scott Fordin [ 12/May/11 01:19 PM ]

Added topic to 3.1 Known Issues section of the 3.1-3.1.1 Release Notes. Not convinced I have all the information I need. For example, not clear to me what the downsides are to omitting --type osgi from the deploy subcommand. Also not clear what the implications are, if any, when deploying from an autodeploy directory or the Admin Console.





[GLASSFISH-15975] lazy-init attribute missing from admin console Edit IIOP Listener page Created: 14/Feb/11  Updated: 07/Feb/13

Status: Open
Project: glassfish
Component/s: orb
Affects Version/s: None
Fix Version/s: 4.0.1

Type: Bug Priority: Major
Reporter: Tom Mueller Assignee: Harshad Vilekar
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1-exclude 3_1-next 3_1-release-note-added 3_1-release-notes 3_1_1-scrubbed 3_1_2-exclude
Participants: Anissa Lam, Harshad Vilekar, Ken Cavanaugh, Nazrul, scatari, Scott Fordin and Tom Mueller

 Description   

There isn't any way to view or edit the lazy-init setting for the IIOP listener from the admin console.



 Comments   
Comment by Anissa Lam [ 14/Feb/11 10:46 AM ]

This sounds like a new attribute added in iiop-listener, not sure if this is since 3.0 or 3.1.
The module owner should have contacted GUI regarding this change so that it can be incorporated in the GUI page.

When looking at config-api, I see that there is only get() method, but not set() for this attribute
@Attribute(defaultValue="false", dataType=Boolean.class)
String getLazyInit();

Is this a read-only attribute ?
Please confirm or fix this. Transfer to 'orb'.

Comment by Tom Mueller [ 14/Feb/11 11:11 AM ]

The IiopListener config bean has the following code:

/**

  • Sets the value of lazyInit property
    *
  • Specify is this listener should be started as part of server startup or not
    *
  • @param value true if the listener is to be started lazily; false otherwise
    */
    void String(boolean value);

It looks like this "String" method was supposed to be a "setLazyInit" method - maybe a typo?

Comment by Ken Cavanaugh [ 14/Feb/11 11:34 AM ]

This was added in 3.0. I'm not sure who was working on the IiopListener class at that
point, but it belongs to the orb now. I think Tom's comment is correct, and
the method should be

void setLazyInit( boolean value )

This is probably not worth fixing this late in 3.1. I'm marking this issue for inclusion
in the release notes.

I think it's probably OK for 3.1, because I don't think there is much need to change the default
value.

Comment by Anissa Lam [ 14/Feb/11 11:41 AM ]

>> I think it's probably OK for 3.1, because I don't think there is much need to change the default
value.

Do you mean the default value or out-of-box value ? They are different.
And is there a reason why default value is different than out-of-box value ? This is always very confusing to user when this happen.

Comment by Ken Cavanaugh [ 14/Feb/11 12:26 PM ]

I don't know what the difference is between default and out-of-the-box.
I just know that I always see lazy-init="true" for the orb-listener-1
IIOP listener in the config.xml file.

Comment by Tom Mueller [ 14/Feb/11 12:38 PM ]

Default is the value that is in the config bean Java source code, in this case "false".

Out-of-the-box is the value that is in the domain.xml template file, in this case "true" for orb-listener-1 and "false" for SSL and SSL_MULTIAUTH.

If a user clicks "New" in the admin console or runs the create-iiop-listener command (which also doesn't provide any way to set lazy-init), the user gets the default value, i.e., "false".

Comment by Scott Fordin [ 23/Mar/11 06:33 PM ]

Need more info to add issue to 3.1 Release Notes.

Comment by Tom Mueller [ 24/Mar/11 06:58 AM ]

For the release notes:

The problem is that a user cannot set the lazy-init value for an IIOP listener from either the console or the CLI. Note that even the asadmin "set" command cannot be used to change the value. The only way to workaround this issue is to edit the domain.xml file directly. The domain.xml file may have:

<iiop-listener port="3700" id="orb-listener-1" address="0.0.0.0" lazy-init="true"></iiop-listener>

In this case, the lazy-init value can be changed to false.

Or, the domain.xml file may have:

<iiop-listener port="3700" id="orb-listener-1" address="0.0.0.0"></iiop-listener>

Here, the default value of false is in effect. To change it to true, add:

lazy-init="true"

to the iiop-listener element.

Comment by Scott Fordin [ 24/Mar/11 01:43 PM ]

Added topic to 3.1 Release Notes. Removed "need more info" tag, added "release note added" tag.

Comment by Nazrul [ 21/Apr/11 11:01 AM ]

Given that there is no way to manage lazy-init attribute using CLI and GUI, it would be useful to consider fixing this issue during 3.1.1

Comment by scatari [ 23/Jun/11 04:15 PM ]

Any GUI change in 3.1.1 requires recertification for 508 compliance that is too late to consider. Marking for next release.

Comment by Anissa Lam [ 23/Jun/11 04:40 PM ]

Before it gets to GUI, the backend needs to be fixed first.
No one has fixed the config bean code to allow setting of the value. I still see:

/**
     * Sets the value of lazyInit property
     *
     * Specify is this listener should be started as part of server startup or not
     *
     * @param value true if the listener is to be started lazily; false otherwise
     */
    void String(boolean value);

Until this is fixed, GUI can't do anything.
When the above is fixed, then this can be assigned to GUI to add the UI.

Comment by Tom Mueller [ 07/Feb/13 03:25 PM ]

Targeting for 4.0.1 as bugs related to the orb do not need to be fixed for the RI/SDK.





[GLASSFISH-15937] RMIConnectorStarter constructs invalid URLs with a literal IPv6 address Created: 10/Feb/11  Updated: 07/Dec/11  Resolved: 07/Dec/11

Status: Closed
Project: glassfish
Component/s: amx
Affects Version/s: 3.1_b41
Fix Version/s: 4.0

Type: Bug Priority: Major
Reporter: Tom Mueller Assignee: naman_mehta
Resolution: Fixed Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
is duplicated by GLASSFISH-15924 [ipv6] glassfish 3.1 b41 could not st... Resolved
Tags: 3_1_1-scrubbed 3_1_2-review
Participants: naman_mehta, prasads, sb110099, Scott Fordin and Tom Mueller

 Description   

The RMIConnectorStarter class, if given a literal IPv6 address, constructs an invalid URL in the start method at lines 276-286. When literal IPv6 addresses are used in URLs, they need to be enclosed in square brackets ([]). See RFC 2732 for details (http://www.ietf.org/rfc/rfc2732.txt). However, this code doesn't take that into account. This causes the following exception if a literal address is used in the address field for the JMX service:

[#|2011-02-09T16:27:12.701-0800|WARNING|oracle-glassfish3.1|javax.enterprise.system.tools.admin.org.glassfish.server|_ThreadID=71;_ThreadName=Thread-1;|Cannot start JMX connector: JmxConnector config: { name = system, Protocol = rmi_jrmp, Address = fe80::21b:24ff:fe5c:2e59, Port = 8686, AcceptAll = false, AuthRealmName = admin-realm, SecurityEnabled = false}: java.net.MalformedURLException: Bad port number: "": java.lang.NumberFormatException: For input string: ""|#]

[#|2011-02-09T16:27:12.702-0800|SEVERE|oracle-glassfish3.1|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=71;_ThreadName=Thread-1;|java.net.MalformedURLException: Bad port number: "": java.lang.NumberFormatException: For input string: ""
at javax.management.remote.JMXServiceURL.<init>(JMXServiceURL.java:193)
at org.glassfish.admin.mbeanserver.RMIConnectorStarter.start(RMIConnectorStarter.java:288)
at org.glassfish.admin.mbeanserver.JMXStartupService$JMXConnectorsStarterThread.startConnector(JMXStartupService.java:243)
at org.glassfish.admin.mbeanserver.JMXStartupService$JMXConnectorsStarterThread.run(JMXStartupService.java:283)

#]

This problem was originally reported in issue GLASSFISH-15924.

Workarounds for this issue include:

  • use square brackets in the domain.xml, i.e, address="[fe80::216:3eff:fe3e:4c35]"
  • use a DNS name that points to an IPv6 address instead

Tagging this as 3_1-exclude because there are workarounds and this is not a release stopper.



 Comments   
Comment by sb110099 [ 10/Feb/11 10:08 AM ]

Added tag : 3_1-release-notes .

Wondering how else can we make this workaround info available to customers ?

--Sudipa

Comment by prasads [ 20/Feb/11 08:03 AM ]

Assigning issues to Naman

Comment by Scott Fordin [ 23/Mar/11 06:34 PM ]

Need more info to add issue to 3.1 Release Notes.

Comment by Tom Mueller [ 24/Mar/11 07:06 AM ]

For the release notes:

When using GlassFish on a system that uses IPv6 addressing, and there is a desire to make the JMX service listen on a specific IPv6 address, and you specify the address as a literal IPv6 address, you will run into this problem. For example, if your domain.xml has the following:

<jmx-connector port="8686" address="e80::216:3eff:fe3e:4c35" security-enabled="false" auth-realm-name="admin-realm" name="system"></jmx-connector>

The server will not open the JMX RMI port successfully and exceptions will be reported in the log file.

The recommended workaround for this problem is to not use a literal address. Instead, define a name, either in DNS or the hosts file, for the address, and then use that name as the value for the address. An alternate workaround is to enclose the address value in square braces, i.e., use:

<jmx-connector port="8686" address="[e80::216:3eff:fe3e:4c35]" security-enabled="false" auth-realm-name="admin-realm" name="system"></jmx-connector>

However, this workaround will cause the system to operate incorrectly when the bug is fixed. The square braces will need to be removed after the fix is applied.

Comment by Scott Fordin [ 24/Mar/11 12:13 PM ]

Added issue to 3.1 Release Notes. Removed "need more info" tag.

Comment by Tom Mueller [ 24/Mar/11 12:42 PM ]

Please do not mark an issue as fixed just because it has been documented in the release notes. The bug is still in the software so the issue must remain open.

Comment by Scott Fordin [ 24/Mar/11 02:15 PM ]

Added 3_1-release-note-added tag.

Comment by naman_mehta [ 07/Dec/11 06:54 AM ]

Made changes to determine ipv4 and ipv6 address and based on that returning valid hostname ...

Comment by naman_mehta [ 07/Dec/11 06:54 AM ]

Fixed for both 3.1.2 and 4.0 ...





[GLASSFISH-15929] man-page-review umbrella issue Created: 09/Feb/11  Updated: 24/Mar/11  Due: 13/Feb/11  Resolved: 16/Feb/11

Status: Resolved
Project: glassfish
Component/s: docs
Affects Version/s: 3.1
Fix Version/s: 3.1_b42

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

Issue Links:
Dependency
depends on GLASSFISH-15958 man page: webtier CLIs Resolved
depends on GLASSFISH-15878 man-page-review : create-jdbc-connect... Resolved
depends on GLASSFISH-15877 man-page-review : remove the section ... Resolved
depends on GLASSFISH-15879 man-page-review : note about resource... Resolved
depends on GLASSFISH-15962 Man page for update-node-config is wr... Resolved
depends on GLASSFISH-15876 man-page-review : list-connector-reso... Resolved
depends on GLASSFISH-15873 man-page-review : delete-resource-ada... Resolved
depends on GLASSFISH-15872 man-page : flush-connection-pool, pin... Resolved
depends on GLASSFISH-15875 man-page-review : list-admin-objects,... Resolved
depends on GLASSFISH-15874 man-page-review : delete-connector-re... Resolved
depends on GLASSFISH-15566 change-master-password --help has wro... Resolved
depends on GLASSFISH-15485 Error in man pages for restart-local-... Resolved
depends on GLASSFISH-15867 documentation of create-system-proper... Resolved
depends on GLASSFISH-15919 man-page-review: jms CLIs Resolved
depends on GLASSFISH-3198 Synopsis for asadmin help create-cust... Resolved
depends on GLASSFISH-15564 create-http-health-checker man page e... Resolved
depends on GLASSFISH-15956 man page: remove --upgrade option fro... Closed
depends on GLASSFISH-15947 Remove --upgrade from start-local-ins... Resolved
Tags: 3_1-approved 3_1-release-note-added 3_1-release-notes
Participants: Chris Kasso, Jagadish, Paul Davies and Scott Fordin

 Description   

Raising an umbrella issue for the man pages of various commands for Bugswat review. Please refer the "depends on" issues list.



 Comments   
Comment by Paul Davies [ 11/Feb/11 08:00 AM ]

This bug is the umbrella bug for all man page fixes for the RC 3 build. I have increased the priority to ensure that it is approved for integration in RC 3.

Comment by Paul Davies [ 11/Feb/11 09:39 AM ]

How bad is its impact? (Severity)
The fix needs to occur now because the issue:

  • Is likely to generate a customer support call
  • Significantly impacts the operation of a primary release driver feature
  • Is an in-your-face issue that will touch the majority of users

How often does it happen? (Frequency)
Every time a user requests help on an affected subcommand.

How much effort is required to fix it? (Cost)
Approx 4 writer days (3 writers working 1 day each on the fixes, + 1 day for integration and testing)

What is the risk of fixing it? (Risk)
Low.

Does a work around for the issue exist? Can the workaround be reasonably employed by the end user?
Yes - deliver the fixes only in the version that is published on the web.The workaround could be employed by an end user but only if the user is aware of the workaround.

If the issue is not fixed should the issue and its workaround (if applicable) be described in the Release Notes?
Yes.

How long has the bug existed in the product?
The errors were introduced in this release.

Do regression tests exist for this issue?
N/A

Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
QuickLook would be sufficient for this purpose.

When will a tested fix be ready for integration?
Before the RC 3 build is started.

Comment by Chris Kasso [ 11/Feb/11 10:34 AM ]

Approved for RC3.

Comment by Chris Kasso [ 11/Feb/11 10:39 AM ]

These changes will not be localized for 3.1 thus users in non-EN locales will continue to see the incorrect man pages. The release notes should direct these users to the unbundled versions of the man pages for the corrections.

Comment by Paul Davies [ 13/Feb/11 04:10 PM ]

For the 3.1 branch, change is committed in revision 45101.

Comment by Paul Davies [ 16/Feb/11 01:42 PM ]

For the trunk, the fix is committed in revision 45163.

Comment by Scott Fordin [ 24/Mar/11 03:00 PM ]

Added topic to 3.1 Release Notes. Added "3_1-release-note-added" tag.





[GLASSFISH-15925] Cluster -> Resources tab: Should not include resources not included in the web distribution in the table dropdown Created: 09/Feb/11  Updated: 20/Apr/11  Resolved: 14/Apr/11

Status: Resolved
Project: glassfish
Component/s: admin_gui
Affects Version/s: 3.1_b41
Fix Version/s: 3.1.1_b02, 4.0_b02

Type: Bug Priority: Major
Reporter: Harshad Vilekar Assignee: Anissa Lam
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1_1-approved
Participants: Anissa Lam, Harshad Vilekar, Nazrul and Scott Fordin

 Description   

GlassFish 3.1 Web distributions does not contain any of the JMS or MQ components. However, some of the Admin GUI menu items point to JMS related functionality. This needs to be removed. Example:

Steps:

  • install: latest-ogs-web.zip
  • Create and start 2 instance cluster
  • Click on clusters - cluster1 - resources - new - destination resource

------------
HTTP Status 404 - type Status report - message description
The requested resource () is not available.
Oracle GlassFish Server 3.1
------------
Server log:
[#|2011-02-09T18:14:46.411-0800|SEVERE|oracle-glassfish3.1|org.apache.jasper.servlet.JspServlet|_ThreadID=24;_ThreadName=admin-thread-pool-4848(1);|PWC6117: File "%2Fexport%2Fhome%2Fglassfish3%2Fglassfish%2Flib%2Finstall%2Fapplications%2F__admingui%2Fjms%2FjmsDestinationNew.jsp" not found|#]
------------

Similar issue with: server - resources - new - destination resource



 Comments   
Comment by Anissa Lam [ 09/Feb/11 07:31 PM ]

The not supported resources will not show up in the tree node.
The only way to get to this error is by going to the cluster -> Resources Tab, and then use the Resources dropdown to create the resources that is not suppose to be in the web distribution, then they encounter this problem.

What should be implemented is a plugin to this dropdown, instead having the dropdown shows everything.
They get a 404 and thats it. No other functionality is lost. and they can just click the cluster tree node again.

We can release note that some of the resources that is shown in the Resources Tab dropdown is available only in the glassfish profile.

-Destination Resources
-Connection Factory

  • JavaMail
  • Custom Resources
  • External Resources
Comment by Anissa Lam [ 18/Feb/11 12:14 PM ]

change summary to reflect the problem more accurately for the release note.

Comment by Anissa Lam [ 14/Mar/11 05:39 PM ]

Since the above mentioned resource is not included in the web distribution, not able to show them is expected.
The workaround to refresh the exception screen is by clicking the cluster node in the tree or refresh the browser.

Comment by Scott Fordin [ 13/Apr/11 02:55 PM ]

Added issue to 3.1 Release Notes.

Comment by Anissa Lam [ 14/Apr/11 04:53 PM ]

change implementation of the dropdown. Instead of hardcode, it is now a plugin from different plugin module. So, if the module doesn't exist in web profile, eg, jms, it won't show up in the dropdown.

Fixed in the trunk for 3.2 b02. Will try to fix in 3.1.1 branch if approved.

Project: glassfish
Repository: svn
Revision: 46166
Author: anilam
Date: 2011-04-14 23:50:15 UTC
Link:

Log Message:
------------
GLASSFISH-19529. Change the New Dropdown and Filter Dropdown of the Resource table in Resource tab of standalone instance and cluster.
These dropdown should be a plugin from different plugin module.

Revisions:
----------
46166

Modified Paths:
---------------
trunk/v3/admingui/common/src/main/resources/resourceNode/targetResourceTableButtons.inc
trunk/v3/admingui/jca/src/main/resources/META-INF/admingui/console-config.xml
trunk/v3/admingui/jdbc/src/main/resources/META-INF/admingui/console-config.xml
trunk/v3/admingui/jms-plugin/src/main/resources/META-INF/admingui/console-config.xml
trunk/v3/admingui/full/src/main/resources/META-INF/admingui/console-config.xml

Comment by Nazrul [ 15/Apr/11 10:21 AM ]
  • Why fix this issue in 3.1.1?
    o This is at-your-face issue, selecting some of the dropdown option that doesn't exist in web profile causes 404 error.
  • Which is the targeted build of 3.1.1 for this fix?
    o b02 (The fix has been checked in the trunk, just need to backport the change to the branch.)
  • Do regression tests exist for this issue?
    o yes, i just add back a dev test that tests this resource table that is the only table affected by this change.
  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
    o verify the bug reported is fixed.
Comment by Anissa Lam [ 20/Apr/11 06:33 PM ]

Log Message:
------------
GLASSFISH-19529. Change the New Dropdown and Filter Dropdown of the Resource table in Resource tab of standalone instance and cluster.
These dropdown should be a plugin from different plugin module.
Fix has been checked into trunk for 3.2
Now, backport to 3.1.1

Revisions:
----------
46292

Modified Paths:
---------------
branches/3.1.1/admingui/jms-plugin/src/main/resources/META-INF/admingui/console-config.xml
branches/3.1.1/admingui/jca/src/main/resources/META-INF/admingui/console-config.xml
branches/3.1.1/admingui/common/src/main/resources/resourceNode/targetResourceTableButtons.inc
branches/3.1.1/admingui/jdbc/src/main/resources/META-INF/admingui/console-config.xml
branches/3.1.1/admingui/full/src/main/resources/META-INF/admingui/console-config.xml





[GLASSFISH-15909] New Grizzly integration required for http://java.net/jira/browse/GRIZZLY-970 Created: 09/Feb/11  Updated: 13/Apr/11  Resolved: 03/Mar/11

Status: Resolved
Project: glassfish
Component/s: grizzly-kernel
Affects Version/s: 3.1_b41
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: Ryan Lubke Assignee: Ryan Lubke
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1-exclude 3_1-release-note-added 3_1-release-notes
Participants: Chris Kasso, Ryan Lubke and Scott Fordin

 Description   

See http://java.net/jira/browse/GRIZZLY-970 for details.

I've checked the web container code and have found similar logic which I will fix along with the grizzly integration.



 Comments   
Comment by Ryan Lubke [ 09/Feb/11 08:28 AM ]

How bad is its impact? (Severity)
Identify why the fix needs to occur now:

  • Impacts product security

How often does it happen? (Frequency)

  • anytime a specially crafted header is sent to the web container

How much effort is required to fix it? (Cost)

  • minimal

What is the risk of fixing it? (Risk)

  • minimal

Does a work around for the issue exist? Can the workaround be reasonably employed by the end user?

  • none

If the issue is not fixed should the issue and its workaround (if applicable) be described in the Release Notes?

How long has the bug existed in the product?

  • It's a JVM issue that's been around for some time. The issue has just recently started getting a lot of press.

Do regression tests exist for this issue?

  • in Grizzly, not in glassfish.

Which tests should QA (re)run to verify the fix did not destabilize GlassFish?

  • N/A

When will a tested fix be ready for integration?

  • 2/9/2011
Comment by Chris Kasso [ 09/Feb/11 02:04 PM ]

Oracle has issued the following sec alert on this issue:

http://blogs.oracle.com/security/2011/02/security_alert_for_cve-2010-44.html

If the customer upgrades to Java Runtime Environment 6 update 24 when it is released they will no longer be vulnerable to this issue. Information about this vulnerability along with how to mitigate it should be included in the Release Notes.

The fixed version of Grizzly should be incorporated in the first patch released for GF 3.1.

Comment by Scott Fordin [ 03/Mar/11 07:02 PM ]

Added issue to 3.1 Release Notes.





[GLASSFISH-15879] man-page-review : note about resource-ref in multiple resource related commands Created: 07/Feb/11  Updated: 10/Feb/11  Resolved: 10/Feb/11

Status: Resolved
Project: glassfish
Component/s: docs
Affects Version/s: None
Fix Version/s: 3.1

Type: Bug Priority: Critical
Reporter: Jagadish Assignee: Scott Fordin
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
blocks GLASSFISH-15929 man-page-review umbrella issue Resolved
Tags:
Participants: Jagadish and Scott Fordin

 Description   

Raising this issue as part of man pages review process of docs :

http://wikis.sun.com/display/GlassFish/GlassFish+Server+Open+Source+Edition+3.1+Connectors+Documentation+Review

affected man-pages :

create-admin-object
create-connector-resource
create-custom-resource
create-jdbc-resource
create-jndi-resource

----------------------------------------------------------------------------------------------------------------------------------------------------------
Note - The resource is always created for the domain as a whole, but the <resource-ref>
element for the resource is only created for the specified --target. This means that
although the resource is defined at the domain level, it is only active at the specified
--target.

can be re-worded as :

Note - The resource is always created for the domain as a whole, but the resource-ref
for the resource is only created for the specified --target. This means that
although the resource is defined at the domain level, it is only available at the specified
target. Use create-resource-ref command to refer the resource in multiple targets if needed.
----------------------------------------------------------------------------------------------------------------------------------------------------------



 Comments   
Comment by Jagadish [ 07/Feb/11 06:32 AM ]

delete-resource related comments.

man-pages affected :

delete-admin-object
delete-connector-resource
delete-custom-resource
delete-jdbc-resource
delete-jndi-resource

----------------------------------------------------------------------------------------------------------------------------------------------------------
Note - Resources are always created for a domain as a whole but are only active for targets
for which a <resource-ref> has been created using the --target option when the
resource was created. This means that deleting a resource only deletes the <resource-ref>
element for the specified --target, and does not delete the resource from the domain as a
whole unless domain is specified as the --target for the deletion.

can be re-worded as :

Note - Resources are always created for a domain as a whole but are available only for the target
for which resource-ref is created. Deleting the resource against a target will succeed if the resource
is referred (resource-ref) only in that target and not in multiple targets. Use delete-resource-ref command to delete
resource-ref(s) when there are multiple targets referring the resource and then delete the resource.
----------------------------------------------------------------------------------------------------------------------------------------------------------

Comment by Scott Fordin [ 10/Feb/11 06:03 PM ]

Completed edits to man pages and checked pages into doc workspace.





[GLASSFISH-15878] man-page-review : create-jdbc-connection-pool Created: 07/Feb/11  Updated: 10/Feb/11  Due: 11/Feb/11  Resolved: 10/Feb/11

Status: Resolved
Project: glassfish
Component/s: docs
Affects Version/s: None
Fix Version/s: 3.1

Type: Bug Priority: Critical
Reporter: Jagadish Assignee: Scott Fordin
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
blocks GLASSFISH-15929 man-page-review umbrella issue Resolved
Status Whiteboard:

Completed man page edits and checked page into doc workspace.

Tags:
Participants: Jagadish and Scott Fordin

 Description   

Raising this issue as part of man pages review process of docs :

http://wikis.sun.com/display/GlassFish/GlassFish+Server+Open+Source+Edition+3.1+Connectors+Documentation+Review

affected man-page : create-jdbc-connection-pool

CHANGE-1 :
----------------------------------------------------------------------------------------------------------------------------------------------------------
If --restype = java.sql.Driver, then the --driverclassname option is required.
You can also specify the --datasourceclassname option.

Remove the last line so that the description becomes :

If --restype = java.sql.Driver, then the --driverclassname option is required.
----------------------------------------------------------------------------------------------------------------------------------------------------------

CHANGE-2 :
----------------------------------------------------------------------------------------------------------------------------------------------------------
If --restype = javax.sql.DataSource, javax.sql.XADataSource or ,
javax.sql.ConnectionPoolDataSource, then the --datasourceclassname option is
required. You can also specify the --driverclassname option

Remove the last line so that the description becomes :

If --restype = javax.sql.DataSource, javax.sql.XADataSource or ,
javax.sql.ConnectionPoolDataSource, then the --datasourceclassname option is
required.
----------------------------------------------------------------------------------------------------------------------------------------------------------

CHANGE-3 :
----------------------------------------------------------------------------------------------------------------------------------------------------------
--statementleakreclaim
Specifies whether leaked statements are closed and reclaimed after statement leak tracing is
complete. Possible values are as follows:
false
Leaked statements are not closed and reclaimed (default).
true
Leaked statements are closed and reclaimed.

must be re-worded as :

--statementleakreclaim
Specifies whether leaked statements are reclaimed after the statements leak.
Possible values are as follows:
false
Leaked statements are not reclaimed (default).
true
Leaked statements are reclaimed.
----------------------------------------------------------------------------------------------------------------------------------------------------------

CHANGE-4 :
----------------------------------------------------------------------------------------------------------------------------------------------------------
dynamic-reconfiguration-wait-timeout-in-seconds
Specifies the time after which in-use connections and in-flight transactions must be
retried after a an attribute or property change to the JDBC connection pool. Existing
requests that occur within this timeout period will be transparently rolled over to the
new pool configuration.New requests will wait for the pool reconfiguration to complete
and connections will be acquired using the modified pool configuration.

can be re-worded as :

dynamic-reconfiguration-wait-timeout-in-seconds
Used to enable dynamic reconfiguration of connection pool transparent to the applications
that are using the pool so that applications need not be re-enabled for the attribute or property changes
of pool to take effect. Any in-flight transaction's connection requests will be allowed for completion
with old pool configuration as long as the connection request is within the time-out period,
so as to complete the transaction. New connection requests will wait for the pool reconfiguration
to complete and connections will be acquired using the modified pool configuration.
----------------------------------------------------------------------------------------------------------------------------------------------------------

CHANGE-5 :
----------------------------------------------------------------------------------------------------------------------------------------------------------
[--sqltracelisteners=sqltracelisteners[,sqltracelisteners] \
[time-to-keep-queries-in-minutes=minutes] [number-of-top-queries-to-report=number]]

should be :
[--sqltracelisteners=sqltracelisteners[,sqltracelisteners]

as the newly introduced properties are not directly related to the above attribute.
[These properties are used when jdbc-connection-pool monitoring and sqltracelisteners are enabled. Please refer the changes (6) and (7) below]
----------------------------------------------------------------------------------------------------------------------------------------------------------

CHANGE-6 :
----------------------------------------------------------------------------------------------------------------------------------------------------------
--sqltracelisteners
A list of one or more custom modules that provide custom logging of database activities.
Each module must implement the org.glassfish.api.jdbc.SQLTraceListener public
interface. When set to an appropriate value, SQL statements executed by applications are
traced. This option has no default value.
The following properties can be used when SQL tracing is enabled :
time-to-keep-queries-in-minutes Specifies the number of minutes will be cached
for use in calculating frequently used queries.
The default value is 5 minutes.
number-of-top-queries-to-report Specifies the number of queries to list when
reporting the top and most frequently used
queries. The default value is 10 queries.

--sqltracelisteners
A list of one or more custom modules that provide custom logging of database activities.
Each module must implement the org.glassfish.api.jdbc.SQLTraceListener public
interface. When set to an appropriate value, SQL statements executed by applications are
traced. This option has no default value.
----------------------------------------------------------------------------------------------------------------------------------------------------------

CHANGE-7
----------------------------------------------------------------------------------------------------------------------------------------------------------
Add the two properties in --property section of man page instead of keeping it as part of --sqltracelisteners

--property section :

The following monitoring statistics configuration properties will take effect when SQL tracing and monitoring
are enabled for JDBC Connection Pool :

"time-to-keep-queries-in-minutes" Specifies the number of minutes will be cached
for use in calculating frequently used queries. The default value is 5 minutes.

"number-of-top-queries-to-report" Specifies the number of queries to list when
reporting the top and most frequently used queries. The default value is 10 queries.

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



 Comments   
Comment by Scott Fordin [ 10/Feb/11 02:57 PM ]

Completed man page edits and checked page into doc workspace.

Comment by Scott Fordin [ 10/Feb/11 02:57 PM ]

Completed man page edits and checked page into doc workspace.

Comment by Scott Fordin [ 10/Feb/11 04:49 PM ]

Reopening so I can mark the bug as Resolved rather than Fixed.

Comment by Scott Fordin [ 10/Feb/11 04:50 PM ]

Reopened so I could mark the bug as Resolved rather than Fixed. Work has been completed and is awaiting verification.





[GLASSFISH-15877] man-page-review : remove the section "Application Scoped Resources" from multiple resource man-pages Created: 07/Feb/11  Updated: 10/Feb/11  Resolved: 10/Feb/11

Status: Resolved
Project: glassfish
Component/s: docs
Affects Version/s: None
Fix Version/s: 3.1

Type: Bug Priority: Critical
Reporter: Jagadish Assignee: Scott Fordin
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
blocks GLASSFISH-15929 man-page-review umbrella issue Resolved
Tags:
Participants: Jagadish and Scott Fordin

 Description   

Raising this issue as part of man pages review process of docs :

http://wikis.sun.com/display/GlassFish/GlassFish+Server+Open+Source+Edition+3.1+Connectors+Documentation+Review

man-pages affected :

1) create-resource-adapter-config
2) create-connector-work-security-map
3) update-connector-work-security-map
4) delete-connector-work-security-map
5) list-connector-work-security-maps

----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
The description about Application-scoped-resources is not applicable in the following man-pages as these commands are not used to modify/create/affect the application scoped resources. Hence, we should remove the description about "Application Scoped Resources" in the above man-pages.
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------



 Comments   
Comment by Scott Fordin [ 10/Feb/11 04:41 PM ]

Completed edits to man pages and checked pages into doc workspace.

Comment by Scott Fordin [ 10/Feb/11 04:51 PM ]

Reopening so I can mark the bug as Resolved rather than Fixed.

Comment by Scott Fordin [ 10/Feb/11 04:52 PM ]

Reopened so I could mark the bug as Resolved rather than Fixed. Work has been completed and is awaiting verification.





[GLASSFISH-15876] man-page-review : list-connector-resources, list-jndi-resources Created: 07/Feb/11  Updated: 10/Feb/11  Resolved: 10/Feb/11

Status: Resolved
Project: glassfish
Component/s: docs
Affects Version/s: None
Fix Version/s: 3.1

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

Issue Links:
Dependency
blocks GLASSFISH-15929 man-page-review umbrella issue Resolved
Tags:
Participants: Jagadish and Scott Fordin

 Description   

Raising this issue as part of man pages review process of docs :

http://wikis.sun.com/display/GlassFish/GlassFish+Server+Open+Source+Edition+3.1+Connectors+Documentation+Review

affected man-pages :
1) list-connector-resources
2) list-jndi-resources
------------------------------------------------------------------------------------------------------------------------------------
"configuration_name" is not a valid value of the "target" operand.
Instead, "domain" is a valid value which should be added.
------------------------------------------------------------------------------------------------------------------------------------

9.x docs references :
http://download.oracle.com/docs/cd/E19879-01/820-4332/6nfq988tm/index.html
http://download.oracle.com/docs/cd/E19879-01/820-4332/6nfq988ue/index.html



 Comments   
Comment by Scott Fordin [ 10/Feb/11 06:29 PM ]

Completed edits to man pages and checked pages into doc workspace.





[GLASSFISH-15875] man-page-review : list-admin-objects, list-connector-resources, list-jndi-resources Created: 07/Feb/11  Updated: 30/Jun/11  Resolved: 30/Jun/11

Status: Resolved
Project: glassfish
Component/s: docs
Affects Version/s: 3.1_b43
Fix Version/s: 3.1.1

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

Issue Links:
Dependency
blocks GLASSFISH-15929 man-page-review umbrella issue Resolved
Tags: 3_1-exclude
Participants: Jagadish, Paul Davies and Scott Fordin

 Description   

Raising this issue as part of man pages review process of docs :

http://wikis.sun.com/display/GlassFish/GlassFish+Server+Open+Source+Edition+3.1+Connectors+Documentation+Review

man-pages affected :
1) list-admin-objects
2) list-connector-resources
3) list-jndi-resources
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
"target" is an "operand" and not an "option" and hence it should be described under the section "operand" in the above commands' man pages.
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------



 Comments   
Comment by Scott Fordin [ 11/Feb/11 07:26 AM ]

Completed edits to man pages and checked pages into doc workspace.

Comment by Jagadish [ 16/Feb/11 08:34 PM ]

I still see that "target" is listed in "options" section apart from the appropriate "operands" section.
This can be fixed for 3.2 as its too late for 3.1

Comment by Scott Fordin [ 17/Mar/11 06:17 PM ]

Will update man pages for 3.2.

Comment by Paul Davies [ 27/May/11 10:15 AM ]

Under consideration for fixing in the 3.1.1 bundled docs.

Comment by Scott Fordin [ 31/May/11 10:14 AM ]

Reassigning to Paul Davies.

Comment by Paul Davies [ 30/Jun/11 08:51 PM ]

Fix committed in revision 47759.





[GLASSFISH-15874] man-page-review : delete-connector-resource, delete-jdbc-resource, delete-jndi-resource Created: 07/Feb/11  Updated: 11/Feb/11  Resolved: 11/Feb/11

Status: Resolved
Project: glassfish
Component/s: docs
Affects Version/s: None
Fix Version/s: 3.1

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

Issue Links:
Dependency
blocks GLASSFISH-15929 man-page-review umbrella issue Resolved
Tags:
Participants: Jagadish and Scott Fordin

 Description   

Raising this issue as part of man pages review process of docs :

http://wikis.sun.com/display/GlassFish/GlassFish+Server+Open+Source+Edition+3.1+Connectors+Documentation+Review

man-pages affected :

1) delete-connector-resource
2) delete-jdbc-resource
3) delete-jndi-resource

There is a description about cluster profile or enterprise profile, which is not applicable any more in GlassFish 3.1

Following text under "--target" need to be removed for all of the above man-pages
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------
"This option is valid only in domains that are configured to support clusters, such as
domains that are created with the cluster profile or the enterprise profile."
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------



 Comments   
Comment by Scott Fordin [ 11/Feb/11 07:55 AM ]

Completed edits to man pages and checked pages into doc workspace.





[GLASSFISH-15873] man-page-review : delete-resource-adapter-config Created: 07/Feb/11  Updated: 11/Feb/11  Resolved: 11/Feb/11

Status: Resolved
Project: glassfish
Component/s: docs
Affects Version/s: None
Fix Version/s: 3.1

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

Issue Links:
Dependency
blocks GLASSFISH-15929 man-page-review umbrella issue Resolved
Tags:
Participants: Jagadish and Scott Fordin

 Description   

Raising this issue as part of man pages review process of docs :

http://wikis.sun.com/display/GlassFish/GlassFish+Server+Open+Source+Edition+3.1+Connectors+Documentation+Review

Affected man-page :
delete-resource-adapter-config

--target is deprecated since older versions of GlassFish (eg: GlassFish v2)
http://download.oracle.com/docs/cd/E19879-01/820-4332/6nfq988s0/index.html

----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
--target
This option is valid only in domains that are configured to support clusters.
Valid targets are described below.
server
Deletes the resource from the default server instance. This is the default value
domain
Deletes the resource from the domain
cluster_name
Deletes the resource for every server instance in the cluster
instance_name
Deletes the resource from the specified server instance

must be re-worded as :

--target
This option is deprecated.
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------



 Comments   
Comment by Scott Fordin [ 11/Feb/11 06:44 AM ]

Completed edits to man page and checked page into doc workspace.





[GLASSFISH-15872] man-page : flush-connection-pool, ping-connection-pool Created: 07/Feb/11  Updated: 10/Feb/11  Resolved: 10/Feb/11

Status: Resolved
Project: glassfish
Component/s: docs
Affects Version/s: None
Fix Version/s: 3.1

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

Issue Links:
Dependency
blocks GLASSFISH-15929 man-page-review umbrella issue Resolved
Tags:
Participants: Jagadish and Scott Fordin

 Description   

Raising this issue as part of man pages review process of docs :

http://wikis.sun.com/display/GlassFish/GlassFish+Server+Open+Source+Edition+3.1+Connectors+Documentation+Review

man-pages affected :

1) flush-connection-pool
2) ping-connection-pool

----------------------------------------------------------------------------------------------------------------------------------------------------------
--appname
An application-scoped resource.
--modulename
A module-scoped resource

must be re-worded as :

--appname
name of the application in which the application scoped resource is defined.
--modulename
name of the module in which the module scoped resource is defined.
----------------------------------------------------------------------------------------------------------------------------------------------------------

----------------------------------------------------------------------------------------------------------------------------------------------------------
operands

pool_name
Name of the connection pool to be reinitialized.
application
JNDI name for an application-scoped resource.
module
JNDI name for a module-scoped resource.

[application and module are not valid operands here and hence the operand "pool_name" alone is sufficient.]

pool_name
Name of the connection pool to be reinitialized.
----------------------------------------------------------------------------------------------------------------------------------------------------------



 Comments   
Comment by Scott Fordin [ 10/Feb/11 03:25 PM ]

Completed edits to man pages and checked pages into doc workspace.

Comment by Scott Fordin [ 10/Feb/11 04:58 PM ]

Reopening so I can mark the bug as Resolved rather than Fixed.

Comment by Scott Fordin [ 10/Feb/11 04:58 PM ]

Reopened so I could mark the bug as Resolved rather than Fixed. Work has been completed and is awaiting verification.





[GLASSFISH-15867] documentation of create-system-properties has inconsistencies Created: 05/Feb/11  Updated: 11/Feb/11  Resolved: 11/Feb/11

Status: Resolved
Project: glassfish
Component/s: docs
Affects Version/s: 3.1_b37
Fix Version/s: 3.1

Type: Bug Priority: Major
Reporter: vince kraemer Assignee: Scott Fordin
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

mac os x 10.6.6
Java(TM) SE Runtime Environment (build 1.6.0_22-b04-307-10M3261)
Java HotSpot(TM) 64-Bit Server VM (build 17.1-b03-307, mixed mode)
Version = GlassFish Server Open Source Edition 3.1-b37 (build 37)


Issue Links:
Dependency
blocks GLASSFISH-15929 man-page-review umbrella issue Resolved
Tags:
Participants: Paul Davies, Scott Fordin and vince kraemer

 Description   

The synopsis for the command says...

create-system-properties [--help][--target target-name][name=value)[:name=value]*]

And this appears to be correct.

The example usage at the bottom of the page appears to be incorrect

asadmin> create-system-properties myserver http-listener-port=1088

Here is what you get if you enter the command based on the example

$ bin/asadmin create-system-properties myserver http-listener-port=1088
Command create-system-properties only accepts one operand
Usage: asadmin [asadmin-utility-options] create-system-properties
[--target <target(default:server)>] [?|-help[=<help(default:false)>]]
(name=value)[:name=value]*



 Comments   
Comment by Paul Davies [ 10/Feb/11 04:02 PM ]

Looks as if myserver should be preceded by the --target option:

asadmin create-system-properties --target myserver http-listener-port=1088
Command create-system-properties executed successfully.

Comment by vince kraemer [ 11/Feb/11 10:02 AM ]

you may want to extend the text to explain that the --target myserver will change the property for that target...

Comment by Scott Fordin [ 11/Feb/11 11:57 AM ]

Completed edits to man page and checked page into doc workspace. Note that I added a new entry in the Operands section, listing the valid targets.





[GLASSFISH-15865] @DSD defined in EJBs bundled in a .war is not available for JPA during prepare() phase. Created: 05/Feb/11  Updated: 13/Apr/11  Resolved: 13/Apr/11

Status: Resolved
Project: glassfish
Component/s: jdbc
Affects Version/s: 3.1
Fix Version/s: 3.1

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

Tags: 3_1-exclude 3_1-release-note-added 3_1-release-notes
Participants: Jagadish and Scott Fordin

 Description   

Following use-case/application setup results in @DSD not found.

a) @DSD defined in an EJB bundled in a .war
+
b) JPA is also in the .war and JPA depends on the @DSD exported by the EJB.

In the above application setup, @DSD is not available during "prepare()" phase for JPA to create tables.
The @DSD is available after deployment.



 Comments   
Comment by Jagadish [ 05/Feb/11 06:52 AM ]

Workaround for 3.1 :

JPA can lookup only app scoped ("java:app") DSDs and so they can be defined in the enclosing .war's web.xml/application.xml/Servlet instead of defining in the EJB.

Fix for 3.2 is made available :
svn log -v -r 44940
Modified Paths:
---------------
trunk/v3/connectors/connectors-runtime/src/main/java/com/sun/enterprise/resource/deployer/DataSourceDefinitionDeployer.java

Comment by Scott Fordin [ 24/Mar/11 03:03 PM ]

Need more info to add to 3.1 Release Notes.

Comment by Jagadish [ 31/Mar/11 09:51 PM ]

Consider the following application layout :

EJBs are bundled in the .war and the Servlet in the .war makes use of JPA (Persistence Unit).
@DSD (DataSourceDefinition) is defined in the EJB.
If the Persistence Unit depends on @DSD defined in EJB, it will not be available in the above setup (ie., EJBs bundled in .war).

Workaround would be to define the DataSourceDefinition in web.xml/application.xml/Servlet instead of defining it in the EJB.

Comment by Jagadish [ 07/Apr/11 10:24 PM ]

Transferring to Scott for making appropriate docs changes for 3.1 (if any).
Scott : Please close this issue if its already taken care of.

Comment by Jagadish [ 07/Apr/11 10:24 PM ]

setting version as 3.1 as docs changes are needed only for 3.1 and not for 3.2

Comment by Scott Fordin [ 13/Apr/11 09:10 AM ]

Added issue to 3.1 Release Notes.





[GLASSFISH-15862]  build 40 : list-jmsdest for the cluster1 not working, it just hang Created: 04/Feb/11  Updated: 27/Jun/11  Resolved: 27/Jun/11

Status: Resolved
Project: glassfish
Component/s: jms
Affects Version/s: 3.1_b40
Fix Version/s: 3.1.1_b05, 3.1.1_b10

Type: Bug Priority: Major
Reporter: Homer Yau Assignee: Satish Kumar
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

OEL 5.5, Browser Firefox 3.6.13


Issue Links:
Duplicate
is duplicated by GLASSFISH-16581 Unable to list JMS Destinations when ... Closed
Tags: 3_1_1-approved glassfish
Participants: Anissa Lam, Homer Yau, Nazrul, Satish Kumar, scatari and Scott Fordin

 Description   

Admin Console build 40 it hangs, when clicking on Clusters- cluster1 "JMS Physical Destinations" tab.

GUI Install OGS build 40 (ogs-b40.unix.sh installer build)
Start domain

Login to Admin Console
Create node
Create cluster
Create 3 instance on the cluster-node.

When clicking on Clusters- cluster1 "JMS Physical Destinations" tab , it just hang.

Test with few remote admin command and they works.

Below the CLI command test.

Even the trying list-jmsdest for the cluster1 not working, it just hang.

  1. /export/hudson/glassfish3/glassfish/bin/asadmin list-jmsdest cluster1

No response from Domain Admin Server after 600 seconds.
The command is either taking too long to complete or the server has failed.
Please see the server log files for command status.
Command list-jmsdest failed.

  1. /export/hudson/glassfish3/glassfish/bin/asadmin list-applications
    Nothing to list.
    Command list-applications executed successfully.
  1. /export/hudson/glassfish3/glassfish/bin/asadmin list-instances
    i1 running
    i2 running
    i3 running
    Command list-instances executed successfully.
  1. /export/hudson/glassfish3/glassfish/bin/asadmin list-clusters
    cluster1 running
    Command list-clusters executed successfully.

Detail exception:

[#|2011-02-04T17:36:06.932-0800|WARNING|oracle-glassfish3.1|com.sun.grizzly.conf
ig.GrizzlyServiceListener|_ThreadID=13;_ThreadName=Thread-1;|GRIZZLY0023: Interr
upting idle Thread: admin-thread-pool-4848(2).|#]

[#|2011-02-04T17:36:06.933-0800|WARNING|oracle-glassfish3.1|com.sun.grizzly.conf
ig.GrizzlyServiceListener|_ThreadID=13;_ThreadName=Thread-1;|GRIZZLY0023: Interr
upting idle Thread: admin-thread-pool-4848(6).|#]

[#|2011-02-04T17:36:06.986-0800|WARNING|oracle-glassfish3.1|javax.resourceadapte
r.mqjmsra.lifecycle|_ThreadID=23;_ThreadName=Thread-1;|MQJMSRA_RA4001: getJMXSer
viceURLList:Exception:Message=Caught exception when contacing portmapper.|#]

[#|2011-02-04T17:36:06.988-0800|WARNING|oracle-glassfish3.1|javax.resourceadapte
r.mqjmsra.lifecycle|_ThreadID=23;_ThreadName=Thread-1;|MQJMSRA_RA4001: getJMXSer
viceURLList:Exception:Message=Caught exception when contacing portmapper.|#]

[#|2011-02-04T17:36:08.268-0800|WARNING|oracle-glassfish3.1|javax.enterprise.sys
tem.container.web.com.sun.enterprise.web|_ThreadID=110;_ThreadName=Thread-1;|Sta
ndardWrapperValve[FacesServlet]: PWC1406: Servlet.service() for servlet FacesSer
vlet threw exception
java.lang.IllegalStateException: Application was not properly initialized at sta
rtup, could not find Factory: javax.faces.render.RenderKitFactory
at javax.faces.FactoryFinder$FactoryManager.getFactory(FactoryFinder.jav
a:815)
at javax.faces.FactoryFinder.getFactory(FactoryFinder.java:317)
at com.sun.faces.context.FacesContextImpl.<init>(FacesContextImpl.java:1
28)
at com.sun.faces.context.FacesContextFactoryImpl.getFacesContext(FacesCo
ntextFactoryImpl.java:93)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:399)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java
:1534)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl
icationFilterChain.java:343)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF
ilterChain.java:215)
at com.sun.webui.jsf.util.UploadFilter.doFilter(UploadFilter.java:233)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl
icationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF
ilterChain.java:215)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperV
alve.java:279)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextV
alve.java:175)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.j
ava:655)
at org.apache.catalina.core.StandardPipeline.doChainInvoke(StandardPipel
ine.java:600)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:96)
at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESess
ionLockingStandardPipeline.java:91)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.j
ava:162)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.j
ava:326)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.jav
a:227)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(Container
Mapper.java:228)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:8
22)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:719)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1013)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFil
ter.java:225)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultPro
tocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.jav
a:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.jav
a:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java
:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextT
ask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.
java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadP
ool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool
.java:513)
at java.lang.Thread.run(Thread.java:662)

#]


 Comments   
Comment by Anissa Lam [ 04/Feb/11 09:36 PM ]

As you mentioned:
"Even the trying list-jmsdest for the cluster1 not working, it just hang.

No response from Domain Admin Server after 600 seconds.
The command is either taking too long to complete or the server has failed.
Please see the server log files for command status.
Command list-jmsdest failed."

I don't understand why this is an admin console issue.
Transfer to 'jms'.

Comment by Satish Kumar [ 07/Feb/11 02:23 AM ]

list-jmsdest is not working on this setup since the MQ broker for the instance is not started. list-jmsdest (and other jmsdest related operations require the MQ broker and the GF instance to be running. The 'JMS Physical Destinations' tab opened correctly when the cluster was running.

Comment by Anissa Lam [ 07/Feb/11 08:02 AM ]

How do you define "the cluster was running" ?
At least 1 instance is running or ALL instance has to be running ?
I would like GUI to check for this before calling list-jmsdest.

Comment by Satish Kumar [ 07/Feb/11 05:40 PM ]

It checks for the first configured instance in the cluster list

Comment by Nazrul [ 07/Feb/11 06:46 PM ]

We should handle this more gracefully in our backend implementation. For example, the CLI could check for the first instance and report back instead of hanging.

Comment by Scott Fordin [ 23/Mar/11 06:36 PM ]

Need more info to add issue to 3.1 Release Notes.

Comment by Satish Kumar [ 13/Apr/11 04:55 AM ]

The list-jmsdest command (and the create-jmsdest, delete-jmsdest and flush-jmsdest commands) requires the MQ broker to be running for the command to succeed. If it is not running, it will fail resulting in the exception reported in this bug description.

Comment by Scott Fordin [ 13/Apr/11 09:29 AM ]

Added issue to 3.1 Release Notes.

Comment by Nazrul [ 21/Apr/11 10:47 AM ]

It would be good to address this hang issue during 3.1.1

Comment by scatari [ 29/Apr/11 12:10 PM ]

Approved.

Comment by Satish Kumar [ 05/May/11 09:14 PM ]

Changes to list-jmsdest to display a more meaningful message when the cluster is not started.

Comment by Anissa Lam [ 09/May/11 11:41 AM ]

I have the latest 3.1.1 build. Although the message is better now,

% ./asadmin list-jmsdest c1
remote failure: Unable to list JMS Destinations. Please ensure that the Message Queue Brokers are running.
Command list-jmsdest failed.

there is NPE in server.log with a long exception. I don't think this is acceptable.
Should we reopen this bug to fix this NPE, or you prefer a new bug to be filed ?

Here is the exception logged if you try to do list-jmsdest on a cluster that is not running.

[#|2011-05-09T11:34:13.445-0700|SEVERE|glassfish3.1|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=21;_ThreadName=admin-thread-pool-4848(2);|java.lang.NullPointerException
at javax.management.remote.JMXServiceURL.<init>(JMXServiceURL.java:122)
at org.glassfish.jms.admin.cli.MQJMXConnectorInfo.getMQMBeanServerConnection(MQJMXConnectorInfo.java:124)
at org.glassfish.jms.admin.cli.ListJMSDestinations.listJMSDestinations(ListJMSDestinations.java:165)
at org.glassfish.jms.admin.cli.ListJMSDestinations.execute(ListJMSDestinations.java:126)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:355)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:370)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1045)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1200(CommandRunnerImpl.java:96)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1244)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1232)
at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:455)
at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:212)
at com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:168)
at com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:117)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:238)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:822)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:719)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1013)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:680)

#]

[#|2011-05-09T11:34:13.447-0700|WARNING|glassfish3.1|javax.enterprise.system.tools.admin.org.glassfish.jms.admin.cli|_ThreadID=21;_ThreadName=admin-thread-pool-4848(2);|java.lang.NullPointerException
at javax.management.remote.JMXServiceURL.<init>(JMXServiceURL.java:122)
at org.glassfish.jms.admin.cli.MQJMXConnectorInfo.getMQMBeanServerConnection(MQJMXConnectorInfo.java:124)
at org.glassfish.jms.admin.cli.ListJMSDestinations.listJMSDestinations(ListJMSDestinations.java:165)
at org.glassfish.jms.admin.cli.ListJMSDestinations.execute(ListJMSDestinations.java:126)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:355)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:370)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1045)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1200(CommandRunnerImpl.java:96)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1244)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1232)
at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:455)
at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:212)
at com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:168)
at com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:117)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:238)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:822)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:719)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1013)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:680)

#]

[#|2011-05-09T11:34:13.455-0700|SEVERE|glassfish3.1|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=21;_ThreadName=admin-thread-pool-4848(2);|org.glassfish.jms.admin.cli.JMSAdminException:
at org.glassfish.jms.admin.cli.JMSDestination.logAndHandleException(JMSDestination.java:515)
at org.glassfish.jms.admin.cli.ListJMSDestinations.listJMSDestinations(ListJMSDestinations.java:208)
at org.glassfish.jms.admin.cli.ListJMSDestinations.execute(ListJMSDestinations.java:126)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:355)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:370)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1045)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1200(CommandRunnerImpl.java:96)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1244)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1232)
at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:455)
at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:212)
at com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:168)
at com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:117)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:238)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:822)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:719)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1013)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:680)

#]
Comment by Satish Kumar [ 10/May/11 04:51 AM ]

Reopening this issue to fix the NPE in the server.log.

Comment by Satish Kumar [ 27/Jun/11 09:06 AM ]

Suppressed the exception logging





[GLASSFISH-15839] [LB] Unable to setup LB's Admin-Ease-Of-Use feature on Apache2.2/Sparc Created: 04/Feb/11  Updated: 23/May/11  Resolved: 24/Feb/11

Status: Closed
Project: glassfish
Component/s: load_balancer
Affects Version/s: 3.1_b40
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: varunrupela Assignee: kshitiz_saxena
Resolution: Cannot Reproduce Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1-exclude
Participants: Jothir Ganesan, kshitiz_saxena, Nazrul, Scott Fordin and varunrupela

 Description   

GF Build: 40
LB Configurator Build: 05
Platform: Solaris Sparc 10

On running apply-http-lb-changes on Apache, LB gets initialized successfully but the requests are not processed because of :
(70007)The timeout specified has expired: SSL input filter read failed.

Snippet from apache/logs/error_log:

[Fri Feb 04 18:40:22 2011] [notice] lb.runtime: DEBUG0001: buff returned : <?xml version="1.0" encoding="UTF-8"?>\n<!DOCTYPE loadbalancer PUBLIC "-//Sun Microsystems Inc.//DTD Sun Java System Application Server 9.1//EN" "glassfish-loadbalancer_1_3.dtd">\n<loadbalancer>\n <cluster name="st-cluster" policy="weighted-round-robin">\n <instance disable-timeout-in-minutes="30" enabled="true" listeners="http://sf-171s-163.india.sun.com:28080 https://sf-171s-163.india.sun.com:28181" name="instance101" weight="100"/>\n <instance disable-timeout-in-minutes="30" enabled="true" listeners="http://sf-171s-165.india.sun.com:28080 https://sf-171s-165.india.sun.com:28181" name="instance103" weight="100"/>\n <instance disable-timeout-in-minutes="30" enabled="true" listeners="http://sf-171s-164.india.sun.com:28081 https://sf-171s-164.india.sun.com:28182" name="instance104" weight="100"/>\n <instance disable-timeout-in-minutes="30" enabled="true" listeners="http://sf-171s-164.india.sun.com:28080 https://sf-171s-164.india.sun.com:28181" name="instance102" weight="100"/>\n <instance disable-timeout-in-minutes="30" enabled="true" listeners="http://sf-171s-165.india.sun.com:28081 https://sf-171s-165.india.sun.com:28182" name="instance105" weight="100"/>\n <web-module context-root="/clusterjsp" disable-timeout-in-minutes="30" enabled="true"/>\n <health-checker interval-in-seconds="10" timeout-in-seconds="30" url="/"/>\n </cluster>\n <cluster name="my-cluster-2" policy="round-robin">\n <instance disable-timeout-in-minutes="30" enabled="true" listeners="http://sf-171s-163.india.sun.com:28081 https://sf-171s-163.india.sun.com:28182" name="myIns101" weight="100"/>\n <instance disable-timeout-in-minutes="30" enabled="true" listeners="http://sf-171s-164.india.sun.com:28082 https://sf-171s-164.india.sun.com:28183" name="myIns102" weight="100"/>\n <instance disable-timeout-in-minutes="30" enabled="true" listeners="http://sf-171s-165.india.sun.com:28082 https://sf-171s-165.india.sun.com:28183" name="myIns103" weight="100"/>\n <health-checker interval-in-seconds="10" timeout-in-seconds="30" url="/"/>\n </cluster>\n <property name="response-timeout-in-seconds" value="120"/>\n <property name="reload-poll-interval-in-seconds" value="7"/>\n <property name="https-routing" value="false"/>\n <property name="preferred-failover-instance" value="true"/>\n <property name="require-monitor-data" value="false"/>\n <property name="rewrite-location" value="true"/>\n <property name="number-healthcheck-retries" value="3"/>\n <property name="active-healthcheck-enabled" value="false"/>\n <property name="rewrite-cookies" value="false"/>\n</loadbalancer>\n<!--\n This file was generated on: [Fri Feb 04 18:40:22 IST 2011].\n-->\n
[Fri Feb 04 18:40:22 2011] [notice] lb.runtime: CNFG1028 : Successfully initialized Load Balancer with DAS configuration update.
[Fri Feb 04 18:40:27 2011] [info] [client 10.12.171.163] (70007)The timeout specified has expired: SSL input filter read failed.
[Fri Feb 04 18:40:27 2011] [info] [client 10.12.171.163] Connection closed to child 0 with standard shutdown (server sf-171s-163.

The setup details will be sent by e-mail to Kshitiz.



 Comments   
Comment by kshitiz_saxena [ 06/Feb/11 11:51 PM ]

Does this log message result in any failure?

This error message may be harmless as mentioned in CR 6780589.

Comment by Nazrul [ 07/Feb/11 11:52 AM ]

This does not look like a stopper. Please advise if this should be release noted.

Comment by kshitiz_saxena [ 07/Feb/11 06:57 PM ]

This is not a show stopper. If this is really an issue, then it will be release noted.

Comment by Nazrul [ 07/Feb/11 11:44 PM ]

Please remove the release note tag if we don't need to add this to the release note.

Comment by Jothir Ganesan [ 08/Feb/11 08:50 PM ]

After lb config is updated, when the request is sent, webserver is not able to process the request because of
"The timeout specified has expired: SSL input filter read failed.
[Fri Feb 04 18:40:27 2011] [info] [client 10.12.171.163] Connection closed to child 0 with standard shutdown (server sf-171s-163. " and the server throws a 500 response

If there is any additional step to configure apache for this, it needs to be clearly documented.

Comment by Jothir Ganesan [ 14/Feb/11 11:22 PM ]

According to CR 6780589, the issue was with only HTTPS requests.
But a 500 response is thrown even for HTTP request in this case, inspite of the loadbalancer.xml having correct details about the instances.

Comment by varunrupela [ 24/Feb/11 06:59 PM ]

We were able to get admin-ease-of-use to work with apache on a Solaris box.

Comment by Scott Fordin [ 24/Mar/11 03:04 PM ]

Does this in fact need to be added to the Release Notes?

Comment by Scott Fordin [ 23/May/11 02:10 PM ]

Looks like it doesn't need to be added to Release Notes.





[GLASSFISH-15836] @Remote EJBs involving inheritance cause CORBA serialization error in embedded Glassfish Created: 04/Feb/11  Updated: 23/May/11  Resolved: 11/Feb/11

Status: Resolved
Project: glassfish
Component/s: embedded
Affects Version/s: 3.1_b40
Fix Version/s: 3.1

Type: Bug Priority: Major
Reporter: ljnelson Assignee: Bhavanishankar
Resolution: Fixed Votes: 2
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

File Attachments: GZip Archive glassfish-15836-1.0-SNAPSHOT-src.tar.gz     GZip Archive glassfish-15836-1.0-SNAPSHOT_v2.tar.gz     Zip Archive marina.zip     Text File run.log.txt     Text File stack.txt    
Tags: 3_1-exclude 3_1-fishcat
Participants: Bhavanishankar, ljnelson, marina vatkina, Nazrul, Scott Fordin and smsiebe

 Description   

I have a (Serializable) business interface (SimpleStateless).

I have a class that implements it but which is not an EJB of any kind (SimpleStatelessBean).

I have a class that extends SimpleStatelessBean (SimpleStatelessBeanExtension). It is annotated as @Stateless(name="Extension") and @Remote.

When this small module is tested with the maven-embedded-glassfish-plugin, a CORBA serialization error occurs. If you remove the inheritance (and adjust annotations accordingly), everything works fine.

(In the attached test case please note that the interesting bits are all in src/test/java, not src/main/java. The attached test case as written will only function when http://java.net/jira/browse/GLASSFISH-15835 is fixed.)

Bhavani is already working on this.



 Comments   
Comment by ljnelson [ 04/Feb/11 09:19 AM ]

The stack, in case it matters, and for those too impatient to run the test case. Note that the stack appears to be in the core Glassfish componentry, not the embedded stuff:

<pre>
org.omg.CORBA.BAD_PARAM: WARNING: IOP00100006: Class com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate is not Serializable vmcid: SUN minor code: 6 completed: Maybe
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at com.sun.corba.ee.spi.orbutil.logex.corba.CorbaExtension.makeException(CorbaExtension.java:248)
at com.sun.corba.ee.spi.orbutil.logex.corba.CorbaExtension.makeException(CorbaExtension.java:95)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator.handleFullLogging(WrapperGenerator.java:387)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator.access$400(WrapperGenerator.java:107)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator$2.invoke(WrapperGenerator.java:511)
at com.sun.corba.ee.spi.orbutil.proxy.CompositeInvocationHandlerImpl.invoke(CompositeInvocationHandlerImpl.java:99)
at $Proxy122.notSerializable(Unknown Source)
at com.sun.corba.ee.impl.orbutil.ORBUtility.throwNotSerializableForCorba(ORBUtility.java:783)
at com.sun.corba.ee.impl.encoding.CDROutputStream_1_0.write_abstract_interface(CDROutputStream_1_0.java:697)
at com.sun.corba.ee.impl.encoding.CDROutputObject.write_abstract_interface(CDROutputObject.java:545)
at com.sun.corba.ee.impl.javax.rmi.CORBA.Util.writeAbstractObject(Util.java:493)
at com.sun.corba.ee.impl.io.IIOPOutputStream.writeObjectField(IIOPOutputStream.java:771)
at com.sun.corba.ee.impl.io.IIOPOutputStream.outputClassFields(IIOPOutputStream.java:846)
at com.sun.corba.ee.impl.io.IIOPOutputStream.defaultWriteObjectDelegate(IIOPOutputStream.java:245)
at com.sun.corba.ee.impl.io.IIOPOutputStream.outputObject(IIOPOutputStream.java:614)
at com.sun.corba.ee.impl.io.IIOPOutputStream.simpleWriteObject(IIOPOutputStream.java:196)
at com.sun.corba.ee.impl.io.ValueHandlerImpl.writeValueInternal(ValueHandlerImpl.java:235)
at com.sun.corba.ee.impl.io.ValueHandlerImpl.writeValueWithVersion(ValueHandlerImpl.java:216)
at com.sun.corba.ee.impl.io.ValueHandlerImpl.writeValue(ValueHandlerImpl.java:180)
at com.sun.corba.ee.impl.encoding.CDROutputStream_1_0.callWriteValue(CDROutputStream_1_0.java:852)
at com.sun.corba.ee.impl.encoding.CDROutputStream_1_0.writeRMIIIOPValueType(CDROutputStream_1_0.java:837)
at com.sun.corba.ee.impl.encoding.CDROutputStream_1_0.write_value(CDROutputStream_1_0.java:962)
at com.sun.corba.ee.impl.encoding.CDROutputStream_1_0.write_value(CDROutputStream_1_0.java:930)
at com.sun.corba.ee.impl.encoding.CDROutputStream_1_0.write_value(CDROutputStream_1_0.java:976)
at com.sun.corba.ee.impl.encoding.CDROutputStream_1_0.write_value(CDROutputStream_1_0.java:706)
at com.sun.corba.ee.impl.encoding.CDROutputObject.write_value(CDROutputObject.java:527)
at com.sun.corba.ee.impl.io.IIOPOutputStream.writeObjectField(IIOPOutputStream.java:775)
at com.sun.corba.ee.impl.io.IIOPOutputStream.outputClassFields(IIOPOutputStream.java:846)
at com.sun.corba.ee.impl.io.IIOPOutputStream.defaultWriteObjectDelegate(IIOPOutputStream.java:245)
at com.sun.corba.ee.impl.io.IIOPOutputStream.outputObject(IIOPOutputStream.java:614)
at com.sun.corba.ee.impl.io.IIOPOutputStream.simpleWriteObject(IIOPOutputStream.java:196)
at com.sun.corba.ee.impl.io.ValueHandlerImpl.writeValueInternal(ValueHandlerImpl.java:235)
at com.sun.corba.ee.impl.io.ValueHandlerImpl.writeValueWithVersion(ValueHandlerImpl.java:216)
at com.sun.corba.ee.impl.io.ValueHandlerImpl.writeValue(ValueHandlerImpl.java:180)
at com.sun.corba.ee.impl.encoding.CDROutputStream_1_0.callWriteValue(CDROutputStream_1_0.java:852)
at com.sun.corba.ee.impl.encoding.CDROutputStream_1_0.writeRMIIIOPValueType(CDROutputStream_1_0.java:837)
at com.sun.corba.ee.impl.encoding.CDROutputStream_1_0.write_value(CDROutputStream_1_0.java:962)
at com.sun.corba.ee.impl.encoding.CDROutputStream_1_0.write_value(CDROutputStream_1_0.java:976)
at com.sun.corba.ee.impl.encoding.CDROutputObject.write_value(CDROutputObject.java:521)
at com.sun.corba.ee.impl.corba.TCUtility.marshalIn(TCUtility.java:157)
at com.sun.corba.ee.impl.corba.AnyImpl.write_value(AnyImpl.java:627)
at com.sun.corba.ee.impl.encoding.CDROutputStream_1_0.write_any(CDROutputStream_1_0.java:627)
at com.sun.corba.ee.impl.encoding.CDROutputObject.write_any(CDROutputObject.java:489)
at com.sun.corba.ee.impl.javax.rmi.CORBA.Util.writeAny(Util.java:366)
at com.sun.corba.ee.impl.presentation.rmi.DynamicMethodMarshallerImpl$10.write(DynamicMethodMarshallerImpl.java:307)
at com.sun.corba.ee.impl.presentation.rmi.DynamicMethodMarshallerImpl.writeResult(DynamicMethodMarshallerImpl.java:489)
at com.sun.corba.ee.impl.presentation.rmi.ReflectiveTie._invoke(ReflectiveTie.java:178)
at com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatchToServant(CorbaServerRequestDispatcherImpl.java:528)
at com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatch(CorbaServerRequestDispatcherImpl.java:199)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequestRequest(CorbaMessageMediatorImpl.java:1624)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:1486)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleInput(CorbaMessageMediatorImpl.java:990)
at com.sun.corba.ee.impl.protocol.giopmsgheaders.RequestMessage_1_2.callback(RequestMessage_1_2.java:214)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:742)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.dispatch(CorbaMessageMediatorImpl.java:539)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.doWork(CorbaMessageMediatorImpl.java:2324)
at com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.performWork(ThreadPoolImpl.java:497)
at com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:540)
Feb 4, 2011 11:46:11 AM com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator handleFullLogging
WARNING: IOP01000001: Missing local value implementation
org.omg.CORBA.NO_IMPLEMENT: WARNING: IOP01000001: Missing local value implementation vmcid: SUN minor code: 1 completed: Maybe
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at com.sun.corba.ee.spi.orbutil.logex.corba.CorbaExtension.makeException(CorbaExtension.java:248)
at com.sun.corba.ee.spi.orbutil.logex.corba.CorbaExtension.makeException(CorbaExtension.java:95)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator.handleFullLogging(WrapperGenerator.java:387)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator.access$400(WrapperGenerator.java:107)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator$2.invoke(WrapperGenerator.java:511)
at com.sun.corba.ee.spi.orbutil.proxy.CompositeInvocationHandlerImpl.invoke(CompositeInvocationHandlerImpl.java:99)
at $Proxy122.missingLocalValueImpl(Unknown Source)
at com.sun.corba.ee.impl.io.FVDCodeBaseImpl.implementation(FVDCodeBaseImpl.java:113)
at com.sun.org.omg.SendingContext._CodeBaseImplBase._invoke(_CodeBaseImplBase.java:64)
at com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatchToServant(CorbaServerRequestDispatcherImpl.java:528)
at com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatch(CorbaServerRequestDispatcherImpl.java:199)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequestRequest(CorbaMessageMediatorImpl.java:1624)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:1486)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleInput(CorbaMessageMediatorImpl.java:990)
at com.sun.corba.ee.impl.protocol.giopmsgheaders.RequestMessage_1_2.callback(RequestMessage_1_2.java:214)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:742)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.dispatch(CorbaMessageMediatorImpl.java:539)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.doWork(CorbaMessageMediatorImpl.java:2324)
at com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.performWork(ThreadPoolImpl.java:497)
at com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:540)
Caused by: java.lang.ClassNotFoundException: ljnelson.glassfish.embedded.bug._EJB31_GeneratedSimpleStatelessBeanExtensionIntf__Bean_ (no security manager: RMI class loader disabled)
at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:375)
at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:165)
at java.rmi.server.RMIClassLoader$2.loadClass(RMIClassLoader.java:620)
at java.rmi.server.RMIClassLoader.loadClass(RMIClassLoader.java:202)
at java.rmi.server.RMIClassLoader.loadClass(RMIClassLoader.java:135)
at com.sun.corba.ee.impl.util.JDKBridge.loadClassM(JDKBridge.java:319)
at com.sun.corba.ee.impl.util.JDKBridge.loadClass(JDKBridge.java:228)
at com.sun.corba.ee.impl.javax.rmi.CORBA.Util.loadClass(Util.java:640)
at com.sun.corba.ee.impl.util.RepositoryId.getClassFromType(RepositoryId.java:577)
at com.sun.corba.ee.impl.io.ValueHandlerImpl.getClassFromType(ValueHandlerImpl.java:373)
at com.sun.corba.ee.impl.io.FVDCodeBaseImpl.implementation(FVDCodeBaseImpl.java:105)
... 12 more
</pre>

Comment by ljnelson [ 07/Feb/11 06:53 AM ]

Thanks for your hard work on all these related issues. I was wondering what kind of progress had been made here.

Comment by ljnelson [ 07/Feb/11 12:57 PM ]

This is a false alarm.

As it turns out, @Remote isn't the problem. Inheritance is the problem.

If SimpleStatelessBeanExtension is annotated with @Stateless, and extends the POJO SimpleStatelessBean, and if SimpleStatelessBean implements SimpleStateless, this exception will also occur.

Comment by ljnelson [ 07/Feb/11 02:54 PM ]

The attached test case, glassfish-15836-1.0-SNAPSHOT-src.tar.gz, reproduces this error with as few external concerns as possible.

The previous test case should be deleted.

Comment by marina vatkina [ 07/Feb/11 03:01 PM ]

It's probably still a Remote issue - I've just updated 2 test cases (v2/appserv-tests/devtests/ejb/ejb31/embedded/modulewithlibs & v2/appserv-tests/devtests/ejb/ejb31/embedded/twomoduleswithlibs) to which I added a base pojo class which implements an interface. If nothing else is changed, there is no problem.

What's a bit strange though is that if I mark the interface as @Local, the bean seems to be treated as a non-interface bean (but that's a different problem)

Comment by marina vatkina [ 07/Feb/11 03:40 PM ]

@Local interface on a pojo superclass works fine (the printed JNDI name is not correct)

Comment by ljnelson [ 07/Feb/11 03:44 PM ]

Well, wait, now; do I understand you correctly to be saying that the "middle" class, when annotated, works OK? Because my test case deliberately does NOT annotate the middle class, and in my real-world scenario, I only want the "grandchild" to be annotated.

Comment by marina vatkina [ 07/Feb/11 03:52 PM ]

I didn't go that far away in history . My test has a parent and a child, with an interface placed on a parent.

Comment by ljnelson [ 07/Feb/11 03:55 PM ]

OK, so long as the test case to this bug eventually passes. I'll be VERY curious to learn what the root issue is....

Comment by Nazrul [ 07/Feb/11 06:58 PM ]

Since this did not make it into RC2, excluding from 3.1 count.

Comment by ljnelson [ 08/Feb/11 06:47 AM ]

Marina, I cannot make the attached test case pass by doing any of the following:

1. Removing @Remote from BusinessInterfaceSLSB
2. Putting @Local on BusinessInterfaceSLSB
3. Removing @Local and @Remote from BusinessInterfaceSLSB, putting @Local on BusinessInterface

Could you kindly make the required adjustment to the attached test case, and attach it again so that I can see how you worked around this bug?

Comment by marina vatkina [ 08/Feb/11 01:36 PM ]

This is the modified version of the test that uses @Local on the child (according to the EJB spec section 4.9.2.1 the interfaces must be declared on the bean itself), and using embeddable EJB container API with a static-shell.jar. I moved things around a little bit, and made it a simple Java test that (sorry) I compiled and ran manually.

Comment by marina vatkina [ 08/Feb/11 01:37 PM ]

I meant to say that the attached test works fine.

Comment by ljnelson [ 08/Feb/11 01:42 PM ]

Yes, but please note that it does NOT work fine when run via the embedded plugin.

Thanks for the work required for the extra attachment.

Comment by marina vatkina [ 08/Feb/11 01:46 PM ]

Did you try with the same changes to the SimpleStatelessBeanExtension?

Comment by ljnelson [ 08/Feb/11 01:51 PM ]

Well, I deleted that test case (see http://java.net/jira/browse/GLASSFISH-15836?focusedCommentId=301960&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_301960), so the one that is attached doesn't even include SimpleStatelessBeanExtension.

Anyway, yes, I ran the attached test case after adding @Local(BusinessInterface.class) to BusinessInterfaceSLSB.java, and got a CORBA serialization error.

I will (again) delete the attached test case and re-attach a version annotated in the way that you describe.

Comment by ljnelson [ 08/Feb/11 01:53 PM ]

This attachment is the latest test case and hopefully incorporates your suggested workarounds. Unfortunately the test still fails.

Comment by ljnelson [ 08/Feb/11 01:56 PM ]

I will also attach the stack that results from running the attached test case as is.

Comment by ljnelson [ 08/Feb/11 01:57 PM ]

I have just attached the stack trace that results from running the attached test case.

To run the attached test case, just gunzip/tar xf it, cd into the root directory, and run mvn clean install. Tested with Maven 3.0.2.

Comment by smsiebe [ 09/Feb/11 03:43 PM ]

Verified test case glassfish-15836-1.0-SNAPSHOT errors on test.

Apache Maven 3.0 (r1004208; 2010-10-04 07:50:56-0400)
Java version: 1.6.0_16
Java home: C:\Sun\SDK\jdk\jre
Default locale: en_US, platform encoding: Cp1252
OS name: "windows vista" version: "6.0" arch: "x86" Family: "windows"

Comment by Bhavanishankar [ 10/Feb/11 09:55 AM ]

In the current test case you have attached viz., glassfish-15836-1.0-SNAPSHOT-src.tar.gz, you are deploying a local EJB using the maven-embedded-glassfish-plugin and trying to look up that EJB from your JUnit test which runs in surefire-plugin. Since the plugins run on their own classloader, you will not be able to do the look up of the local EJB in your JUnit test.

The original test case you had attached was with remote EJB and was a correct test case. Could you please attach it again?

Comment by ljnelson [ 10/Feb/11 11:38 AM ]

Will do immediately; thanks.

Comment by ljnelson [ 10/Feb/11 11:52 AM ]

Hallelujah; that worked. b05 of the embedded plugin works and resolves this issue.

(Now to figure out how I'm going to test local EJBs without using the plugin...if you have an idea on how I could test local EJBs WITH the plugin I'm all ears. Do I need to go back to using the embeddable Glassfish container directly?)

Comment by Bhavanishankar [ 10/Feb/11 09:55 PM ]

For the local EJBs, v3/tests/embedded/maven-plugin/localejbs should help? Let me know otherwise.

Also, for remote EJBs, could you please attach the working test case?

Comment by Bhavanishankar [ 11/Feb/11 02:33 AM ]

This works fine with 3.1-b05 of the plugin (i.e., 3.1-b41)

Changing @Local(BusinessInterface.class) to @Remote(BusinessInterface.class) in BusinessInterfaceSLSB.java is necessary.

I attach the modified test and the successful run log.

Comment by Scott Fordin [ 24/Mar/11 03:07 PM ]

Does this need to be Release Noted?

Comment by Scott Fordin [ 23/May/11 02:13 PM ]

In the absence of additional information and the fact that this bug is closed and fixed in 3.1, I'm thinking that this no longer needs to be included in the Release Notes.





[GLASSFISH-15812] LB Plugin Installer should add platform specific libs to envvars script for Apache installs Created: 03/Feb/11  Updated: 21/Oct/11  Resolved: 21/Oct/11

Status: Resolved
Project: glassfish
Component/s: load_balancer
Affects Version/s: 3.1_b40
Fix Version/s: 3.1.1

Type: Improvement Priority: Minor
Reporter: tecknobabble Assignee: kshitiz_saxena
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1 glassfish ssl
Participants: kshitiz_saxena, Scott Fordin and tecknobabble

 Description   

On Solaris systems, the mod_loadbalancer.so plugin depends on shared libraries in /usr/lib/mps, for example libssl3.so.

Either:
1) The lb plugin should detect that /usr/lib/mps is present and add it to the LD_LIBRARY_PATH when it updates the envvars script.
or
2) The mod_loadbalancer.so should be linked with -R with /usr/lib/mps in the path list so that the shared library has that dependency embedded in it.



 Comments   
Comment by Scott Fordin [ 23/Mar/11 06:37 PM ]

Need more info to add issue to 3.1 Release Notes.

Comment by tecknobabble [ 25/Mar/11 02:33 AM ]

Not sure why its flagged as a release note issue.

I raised this as part of the doc review on the HA Guide, specifically this section:

http://download.oracle.com/docs/cd/E18930_01/html/821-2426/abdhg.html#gidfs

where it states:

"To configure the Apache 2.2.x security files to work with the Loadbalancer Plugin, append /usr/lib/mps to the LD_LIBRARY_PATH in the apache-install-dir/bin/envvars file."

Honestly, the LB installer should be able to check to see if that directory exists and update the envvars script itself. This shouldn't be a manual step. The more the installer can do the better to eliminate the chance of human error. With the 2.x installer I believe it made all the requisite changes for configuring Apache with the LB plugin.

Comment by Scott Fordin [ 13/Apr/11 09:32 AM ]

Sounds like this does not need to be added to the Release Notes as it is already documented in the location to which tecknobabble points. Removing Release Notes tag.

Comment by kshitiz_saxena [ 13/Jun/11 01:57 AM ]

Fix is not needed in 3.1.1 as SSL libraries are bundled along with load-balancer plugin in 3.1.1.

Comment by kshitiz_saxena [ 21/Oct/11 05:53 AM ]

This issue is no longer reproducible in 3.1.1 as SSL libraries to distribution.

Comment by kshitiz_saxena [ 21/Oct/11 11:11 AM ]

Reopened to add fix version

Comment by kshitiz_saxena [ 21/Oct/11 11:12 AM ]

Fixed in version 3.1.1.





[GLASSFISH-15809] JSF PhaseListener executed for each virtual host Created: 02/Feb/11  Updated: 04/Nov/11  Resolved: 04/Nov/11

Status: Resolved
Project: glassfish
Component/s: jsf
Affects Version/s: v3.0.1
Fix Version/s: 3.1.1_b01

Type: Bug Priority: Major
Reporter: bjornstenfeldt Assignee: Ed Burns
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

We're running GlassFish 3.0.1 with JSF 2.1.0b11 on Windows 2007/7 64-bit.


File Attachments: Text File 20110217-1558-i_gf_15809.patch     Text File 20110222-1610-i_gf_15809.patch     Text File i_gf_15809-workaround.txt    
Issue Links:
Dependency
depends on JAVASERVERFACES-1907 need to create a dev test for multipl... Closed
Status Whiteboard:

jsf_2_1_1

Tags: 3_1-exclude 3_1-release-note-added 3_1-release-notes
Participants: bjornstenfeldt, Ed Burns, Jason Lee, Scott Fordin and tedgoddard

 Description   

We recently spend 2 months changing from JSF 1.2 to 2.0 and GlassFish 2 to 3.0.1. When we were finish with the conversion and ready to go live, we realised that JSF and virtual servers doesn't work together at all on GlassFish 3.0.1 with JSF 2.0. Luckily, this happened on January 27, 2011, the same day that JSF 2.1.0b11 became available with this fix included: http://java.net/jira/browse/GLASSFISH-11984. Otherwise we would have been completely screwed.

However, it didn't take many hours online, before we realised that something was horrible wrong. We have 6 virtual servers in addition to the default. We can't run with less than that. The problem is that all of our PhaseListeners are now executed one time per virtual server for a total of 7 times per request. And not just ours. PhaseListeners included in other projects, such as PrettyFaces, as well.

The problem has forced us to roll back to GF 2 and our 2 months old code once again.



 Comments   
Comment by Ed Burns [ 04/Feb/11 07:37 AM ]

The lack of a dev test bites us again.

Comment by Ed Burns [ 04/Feb/11 07:46 AM ]

Checking out the 2.1.0 branch now.

svn checkout https://svn.java.net/svn/mojarra~svn/branches/MOJARRA_2_1X_ROLLING mojarra-MOJARRA_2_1X_ROLLING

Sheetal, make sure you do the same.

Comment by Ed Burns [ 04/Feb/11 08:36 AM ]

Thankfully, Sheetal's patch for JAVASERVERFACES-1907 looks pretty good. I'm making a couple of small changes to ease the process of iteratively developing a reproducer for this issue (15809) and I'll attach that as a patch to 1907.

Comment by Ed Burns [ 04/Feb/11 10:27 PM ]

I'm going to attempt a workaround along the following lines. Provide a lifecyclefactory that decorates the original one and ensures there is one instance of each kind of lifecycle type per ServletContext.

Comment by Ed Burns [ 05/Feb/11 09:49 AM ]

Still getting the kinks worked out of JAVASERVERFACES-1907, working around little league practices.

Comment by Ed Burns [ 07/Feb/11 08:56 AM ]

After fixing JAVASERVERFACES-1907, I have a solid, automatable, reproducer for this issue.

container.name=glassfishV3.1_no_cluster

ant container.start
ant -Dinstance.numbers=1,2,3,4,5,6 create.virtual.servers
cd jsf-ri/systest-per-webapp
ant -Dcreate-virtual-servers=false -Dinstance.numbers=1,2,3,4,5,6 -Dapplication=replace-lifecycle install-virtual-server
ant -Dcreate-virtual-servers=false -Dinstance.numbers=1,2,3,4,5,6 -Dapplication=replace-lifecycle test-virtual-server
This shows the phaseListener getting called 6 times.

The workaround, which I will produce now, is to provide a custom LifecycleFactory instance that correctly handles the virtual server case.

Comment by Ed Burns [ 07/Feb/11 03:33 PM ]

I will write up the workaround and post it in the bug report.

Comment by Ed Burns [ 08/Feb/11 11:50 AM ]

Workaround description in plain text.

Comment by Ed Burns [ 17/Feb/11 12:59 PM ]

Snapshot, in progress.

Comment by Ed Burns [ 22/Feb/11 01:12 PM ]

snapshot. ClusterTest fails:

Running com.sun.faces.systest.ClusterNoAgressiveSessionDirtyingTestCase
Testsuite: com.sun.faces.systest.ClusterNoAgressiveSessionDirtyingTestCase
Tests run: 1, Failures: 1, Errors: 0, Time elapsed: 3.38 sec
Tests run: 1, Failures: 1, Errors: 0, Time elapsed: 3.38 sec

Testcase: testSimpleObject took 3.103 sec
FAILED
null
junit.framework.AssertionFailedError
at com.sun.faces.systest.ClusterNoAgressiveSessionDirtyingTestCase.assertSimpleObjectOutput(ClusterNoAgressiveSessionDirtyingTestCase.java:115)
at com.sun.faces.systest.ClusterNoAgressiveSessionDirtyingTestCase.testSimpleObject(ClusterNoAgressiveSessionDirtyingTestCase.java:84)
at com.sun.faces.htmlunit.AbstractTestCase.runTest(AbstractTestCase.java:628)

About to stop container.

Comment by Ed Burns [ 22/Feb/11 02:44 PM ]

Small but fundamental change to FactoryFinder http://java.net/jira/browse/GLASSFISH-15809

The root cause of our virtual server woes is an invalid assumption
FactoryFinder has made since its first commit. The assumption. There
is a 1:1 mapping between ServletContext and web-app ClassLoader. This
assumption is not valid in the case of virtual servers. In a deployment
with N virtual servers, there are N ServletContexts for each web-app
ClassLoader. According to Shing-wai, this is not a bug, and I agree
with him.

SECTION: Modified Files
----------------------------
M jsf-api/src/main/java/javax/faces/FactoryFinder.java

  • Instead of having the FactoryManagerCache use ClassLoader alone as the
    key for the FactoryManager instances, use a new class,
    FactoryManagerCacheKey that combines the ClassLoader with the
    ServletContext instance. I had to be careful to handle the case when
    FacesContext.getCurrentInstance() returns null.

M jsf-ri/src/main/java/com/sun/faces/config/ConfigureListener.java

  • When an app is undeployed, release its factories, which will cause
    them to be removed from the FactoryManagerCache.

M jsf-api/src/test/java/javax/faces/component/NamingContainerTestCase.javaM jsf-api/src/test/java/javax/faces/component/UIComponentTestCase.java
M jsf-api/src/test/java/javax/faces/validator/ValidatorTestCase.java
M jsf-api/src/test/java/javax/faces/webapp/TagTestCaseBase.java
M jsf-ri/test/com/sun/faces/config/TestFactoryInjection.java
M jsf-ri/build.xml

  • add deploy target

M jsf-ri/systest-per-webapp/replace-lifecycle/src/java/com/sun/faces/systest/SimplePhaseListener.java
M jsf-ri/systest-per-webapp/replace-lifecycle/src/java/com/sun/faces/systest/ReplaceLifecycleTestCase.java

  • test changes to verify 15809 is fixed.

M lib/jsf-extensions-test-time.jar

  • Fix a bug in MockFacesContext that doesn't actually release the threadlocal.

SECTION: Diffs
----------------------------
Index: jsf-api/src/test/java/javax/faces/component/NamingContainerTestCase.java
===================================================================
— jsf-api/src/test/java/javax/faces/component/NamingContainerTestCase.java (revision 8870)
+++ jsf-api/src/test/java/javax/faces/component/NamingContainerTestCase.java (working copy)
@@ -117,16 +117,16 @@
request.setAttribute("reqScopeName", "reqScopeValue");
response = new MockHttpServletResponse();

+ externalContext =
+ new MockExternalContext(servletContext, request, response);
+ lifecycle = new MockLifecycle();
+ facesContext = new MockFacesContext(externalContext, lifecycle);
// Set up Faces API Objects
FactoryFinder.setFactory(FactoryFinder.APPLICATION_FACTORY,
"com.sun.faces.mock.MockApplicationFactory");
FactoryFinder.setFactory(FactoryFinder.RENDER_KIT_FACTORY,
"com.sun.faces.mock.MockRenderKitFactory");

  • externalContext =
  • new MockExternalContext(servletContext, request, response);
  • lifecycle = new MockLifecycle();
  • facesContext = new MockFacesContext(externalContext, lifecycle);
    ApplicationFactory applicationFactory = (ApplicationFactory)
    FactoryFinder.getFactory(FactoryFinder.APPLICATION_FACTORY);
    application = (MockApplication) applicationFactory.getApplication();
    Index: jsf-api/src/test/java/javax/faces/component/UIComponentTestCase.java
    ===================================================================
      • jsf-api/src/test/java/javax/faces/component/UIComponentTestCase.java (revision 8870)
        +++ jsf-api/src/test/java/javax/faces/component/UIComponentTestCase.java (working copy)
        @@ -164,18 +164,18 @@
        request.setAttribute("reqScopeName", "reqScopeValue");
        response = new MockHttpServletResponse();

+ externalContext =
+ new MockExternalContext(servletContext, request, response);
+ Map map = new HashMap();
+ externalContext.setRequestParameterMap(map);
+ lifecycle = new MockLifecycle();
+ facesContext = new MockFacesContext(externalContext, lifecycle);
// Set up Faces API Objects
FactoryFinder.setFactory(FactoryFinder.APPLICATION_FACTORY,
"com.sun.faces.mock.MockApplicationFactory");
FactoryFinder.setFactory(FactoryFinder.RENDER_KIT_FACTORY,
"com.sun.faces.mock.MockRenderKitFactory");

  • externalContext =
  • new MockExternalContext(servletContext, request, response);
  • Map map = new HashMap();
  • externalContext.setRequestParameterMap(map);
  • lifecycle = new MockLifecycle();
  • facesContext = new MockFacesContext(externalContext, lifecycle);
    ApplicationFactory applicationFactory = (ApplicationFactory)
    FactoryFinder.getFactory(FactoryFinder.APPLICATION_FACTORY);
    application = (MockApplication) applicationFactory.getApplication();
    Index: jsf-api/src/test/java/javax/faces/validator/ValidatorTestCase.java
    ===================================================================
      • jsf-api/src/test/java/javax/faces/validator/ValidatorTestCase.java (revision 8870)
        +++ jsf-api/src/test/java/javax/faces/validator/ValidatorTestCase.java (working copy)
        @@ -124,16 +124,16 @@
        request.setAttribute("reqScopeName", "reqScopeValue");
        response = new MockHttpServletResponse();

+ externalContext =
+ new MockExternalContext(servletContext, request, response);
+ lifecycle = new MockLifecycle();
+ facesContext = new MockFacesContext(externalContext, lifecycle);
// Set up Faces API Objects
FactoryFinder.setFactory(FactoryFinder.APPLICATION_FACTORY,
"com.sun.faces.mock.MockApplicationFactory");
FactoryFinder.setFactory(FactoryFinder.RENDER_KIT_FACTORY,
"com.sun.faces.mock.MockRenderKitFactory");

  • externalContext =
  • new MockExternalContext(servletContext, request, response);
  • lifecycle = new MockLifecycle();
  • facesContext = new MockFacesContext(externalContext, lifecycle);
    ApplicationFactory applicationFactory = (ApplicationFactory)
    FactoryFinder.getFactory(FactoryFinder.APPLICATION_FACTORY);
    application = (MockApplication) applicationFactory.getApplication();
    Index: jsf-api/src/test/java/javax/faces/webapp/TagTestCaseBase.java
    ===================================================================
      • jsf-api/src/test/java/javax/faces/webapp/TagTestCaseBase.java (revision 8870)
        +++ jsf-api/src/test/java/javax/faces/webapp/TagTestCaseBase.java (working copy)
        @@ -142,16 +142,16 @@
        pageContext.initialize(servlet, request, response, null,
        true, 1024, true);

+ externalContext =
+ new MockExternalContext(servletContext, request, response);
+ externalContext.setRequestParameterMap(new HashMap());
+ lifecycle = new MockLifecycle();
+ facesContext = new MockFacesContext(externalContext, lifecycle);
// Set up Faces API Objects
FactoryFinder.setFactory(FactoryFinder.APPLICATION_FACTORY,
"com.sun.faces.mock.MockApplicationFactory");
FactoryFinder.setFactory(FactoryFinder.RENDER_KIT_FACTORY,
"com.sun.faces.mock.MockRenderKitFactory");

  • externalContext =
  • new MockExternalContext(servletContext, request, response);
  • externalContext.setRequestParameterMap(new HashMap());
  • lifecycle = new MockLifecycle();
  • facesContext = new MockFacesContext(externalContext, lifecycle);
    ApplicationFactory applicationFactory = (ApplicationFactory)
    FactoryFinder.getFactory(FactoryFinder.APPLICATION_FACTORY);
    application = (MockApplication) applicationFactory.getApplication();
    Index: jsf-api/src/main/java/javax/faces/FactoryFinder.java
    ===================================================================
      • jsf-api/src/main/java/javax/faces/FactoryFinder.java (revision 8870)
        +++ jsf-api/src/main/java/javax/faces/FactoryFinder.java (working copy)
        @@ -67,6 +67,8 @@
        import java.lang.reflect.Constructor;
        import java.net.URL;
        import java.net.URLConnection;
        +import java.util.Set;
        +import javax.faces.context.FacesContext;

/**
@@ -680,8 +682,8 @@
*/
private static final class FactoryManagerCache {

  • private ConcurrentMap<ClassLoader,Future<FactoryManager>> applicationMap =
  • new ConcurrentHashMap<ClassLoader, Future<FactoryManager>>();
    + private ConcurrentMap<FactoryManagerCacheKey,Future<FactoryManager>> applicationMap =
    + new ConcurrentHashMap<FactoryManagerCacheKey, Future<FactoryManager>>();

// ------------------------------------------------------ Public Methods
@@ -689,8 +691,10 @@

private FactoryManager getApplicationFactoryManager(ClassLoader cl) {

+ FactoryManagerCacheKey key = new FactoryManagerCacheKey(cl, applicationMap);
+
while (true) {

  • Future<FactoryManager> factories = applicationMap.get(cl);
    + Future<FactoryManager> factories = applicationMap.get(key);
    if (factories == null) {
    Callable<FactoryManager> callable =
    new Callable<FactoryManager>() {
    @@ -702,7 +706,7 @@

FutureTask<FactoryManager> ft =
new FutureTask<FactoryManager>(callable);

  • factories = applicationMap.putIfAbsent(cl, ft);
    + factories = applicationMap.putIfAbsent(key, ft);
    if (factories == null) { factories = ft; ft.run(); @@ -717,14 +721,14 @@ ce.toString(), ce); }
  • applicationMap.remove(cl);
    + applicationMap.remove(key);
    } catch (InterruptedException ie) {
    if (LOGGER.isLoggable(Level.FINEST)) { LOGGER.log(Level.FINEST, ie.toString(), ie); }
  • applicationMap.remove(cl);
    + applicationMap.remove(key);
    } catch (ExecutionException ee) { throw new FacesException(ee); }
    @@ -735,14 +739,89 @@

public void removeApplicationFactoryManager(ClassLoader cl) { + FactoryManagerCacheKey key = new FactoryManagerCacheKey(cl, applicationMap); - applicationMap.remove(cl); + applicationMap.remove(key); }

} // END FactoryCache

+ private static final class FactoryManagerCacheKey {
+ private ClassLoader cl;
+ private Object context;

+ private static final String KEY = FactoryFinder.class.getName() + "." ++ FactoryManagerCacheKey.class.getSimpleName();
+
+ public FactoryManagerCacheKey(ClassLoader cl,
+ Map<FactoryManagerCacheKey,Future<FactoryManager>> factoryMap) {
+ this.cl = cl;
+ FacesContext facesContext = FacesContext.getCurrentInstance();
+ if (null != facesContext) {
+ Map<String, Object> appMap = facesContext.getExternalContext().getApplicationMap();
+ Object val = appMap.get(KEY);
+ if (null == val) { + context = new Long(System.currentTimeMillis()); + appMap.put(KEY, context); + } else { + context = val; + }
+ } else {
+ // We don't have a FacesContext.
+ // Our only recourse is to inspect the keys of the
+ // factoryMap and see if any of them has a classloader
+ // equal to our argument cl.
+ Set<FactoryManagerCacheKey> keys = factoryMap.keySet();
+ FactoryManagerCacheKey match = null;
+ for (FactoryManagerCacheKey cur : keys) {
+ if (this.cl.equals(cur.cl)) {
+ match = cur;
+ if (null != match) { + LOGGER.log(Level.WARNING, "Multiple JSF Applications found on same ClassLoader. Unable to safely determine which FactoryManager instance to use. Defaulting to first match."); + }
+ }
+ }
+ if (null != match) { + this.context = match.context; + }
+ }
+ }
+
+ private FactoryManagerCacheKey() {}
+
+ @Override
+ public boolean equals(Object obj) {
+ if (obj == null) { + return false; + }
+ if (getClass() != obj.getClass()) { + return false; + } }
+ final FactoryManagerCacheKey other = (FactoryManagerCacheKey) obj;
+ if (this.cl != other.cl && (this.cl == null || !this.cl.equals(other.cl))) { + return false; + }
+ if (this.context != other.context && (this.context == null || !this.context.equals(other.context))) { + return false; + } }
+ return true;
+ }
+
+ @Override
+ public int hashCode() { + int hash = 7; + hash = 97 * hash + (this.cl != null ? this.cl.hashCode() : 0); + hash = 97 * hash + (this.context != null ? this.context.hashCode() : 0); + return hash; + }
+
+
+
+
+ }
+
+
/**

  • Maintains the factories for a single web application.
    */
    Index: jsf-ri/test/com/sun/faces/config/TestFactoryInjection.java
    ===================================================================
      • jsf-ri/test/com/sun/faces/config/TestFactoryInjection.java (revision 8870)
        +++ jsf-ri/test/com/sun/faces/config/TestFactoryInjection.java (working copy)
        @@ -235,7 +235,9 @@

// invoke the FactoryConfigProcessor
FactoryConfigProcessor fcp = new FactoryConfigProcessor(false);
+ InitFacesContext initContext = new InitFacesContext(sc);
fcp.process(sc, new DocumentInfo[]{new DocumentInfo(d, null)});
+ initContext.release();

// now get an FacesContext instance from the Factory and ensure
// no injection occured.
@@ -264,7 +266,9 @@
// process the document. This should cause the the InjectionFacesContextFactory
// to be put into play since there is more than one FacesContextFactory // being configured
+ initContext = new InitFacesContext(sc);
fcp.process(sc, new DocumentInfo[]{new DocumentInfo(d, null)});
+ initContext.release();

// get the FacesContextFactory instance. The top-level factory should
// be the InjectionFacesContextFactory.
Index: jsf-ri/src/main/java/com/sun/faces/config/ConfigureListener.java
===================================================================
— jsf-ri/src/main/java/com/sun/faces/config/ConfigureListener.java (revision 8870)
+++ jsf-ri/src/main/java/com/sun/faces/config/ConfigureListener.java (working copy)
@@ -348,6 +348,7 @@
ApplicationAssociate.setCurrentInstance(null);
// Release the initialization mark on this web application
ConfigManager.getInstance().destory(context);
+ FactoryFinder.releaseFactories();
if (initContext != null) { initContext.release(); }
Index: jsf-ri/build.xml
===================================================================
— jsf-ri/build.xml (revision 8870)
+++ jsf-ri/build.xml (working copy)
@@ -700,7 +700,7 @@

<target name="passthru">

  • <ant antfile="build-tests.xml" target="execute.cactus.tests"
    + <ant antfile="build-tests.xml" target="passthru"
    inheritAll="true">
    <property name="force.no.cluster" value="true" />
    </ant>
    @@ -715,6 +715,14 @@

</target>

+ <target name="deploy">
+ <ant antfile="build-tests.xml" target="deploy"
+ inheritAll="true">
+ <property name="force.no.cluster" value="true" />
+ </ant>
+
+ </target>
+
<target name="prepare.cactus.webapp">
<ant antfile="build-tests.xml" target="prepare.test.webapp"/>
</target>
Index: jsf-ri/systest-per-webapp/replace-lifecycle/src/java/com/sun/faces/systest/SimplePhaseListener.java
===================================================================
— jsf-ri/systest-per-webapp/replace-lifecycle/src/java/com/sun/faces/systest/SimplePhaseListener.java (revision 8870)
+++ jsf-ri/systest-per-webapp/replace-lifecycle/src/java/com/sun/faces/systest/SimplePhaseListener.java (working copy)
@@ -43,6 +43,7 @@
import javax.faces.event.PhaseEvent;
import javax.faces.event.PhaseId;
import javax.faces.event.PhaseListener;
+import java.util.Map;

public class SimplePhaseListener implements PhaseListener {

@@ -57,8 +58,12 @@

public void beforePhase(PhaseEvent event) { - event.getFacesContext().getExternalContext().getRequestMap().put("beforePhase", - "beforePhase"); + Map<String, Object> requestMap = + event.getFacesContext().getExternalContext().getRequestMap(); + String message = requestMap.containsKey("beforePhase") ? + requestMap.get("beforePhase").toString() : ""; + requestMap.put("beforePhase", + message + " beforePhase"); event.getFacesContext().getExternalContext().getRequestMap().put("lifecycleImpl", event.getSource()); }
Index: jsf-ri/systest-per-webapp/replace-lifecycle/src/java/com/sun/faces/systest/ReplaceLifecycleTestCase.java
===================================================================
— jsf-ri/systest-per-webapp/replace-lifecycle/src/java/com/sun/faces/systest/ReplaceLifecycleTestCase.java (revision 8870)
+++ jsf-ri/systest-per-webapp/replace-lifecycle/src/java/com/sun/faces/systest/ReplaceLifecycleTestCase.java (working copy)
@@ -128,7 +128,10 @@

public void testReplaceLifecycle() throws Exception { HtmlPage page = getPage("/faces/test.jsp"); - assertTrue(-1 != page.asText().indexOf("beforePhase")); + String pageText = page.asText(); + assertTrue(-1 != pageText.indexOf("beforePhase")); + // Ensure the phaseListener is only called once. + assertTrue(!pageText.matches("(?s).*beforePhase.*beforePhase.*")); }

Index: lib/jsf-extensions-test-time.jar
===================================================================
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream

Comment by Jason Lee [ 23/Feb/11 08:47 AM ]

The changes look good to me.

r=jdlee

Comment by Ed Burns [ 23/Feb/11 08:52 AM ]

Sending jsf-api/src/main/java/javax/faces/FactoryFinder.java
Sending jsf-api/src/test/java/javax/faces/component/NamingContainerTestCase.java
Sending jsf-api/src/test/java/javax/faces/component/UIComponentTestCase.java
Sending jsf-api/src/test/java/javax/faces/validator/ValidatorTestCase.java
Sending jsf-api/src/test/java/javax/faces/webapp/TagTestCaseBase.java
Sending jsf-ri/build.xml
Sending jsf-ri/src/main/java/com/sun/faces/config/ConfigureListener.java
Sending jsf-ri/systest-per-webapp/replace-lifecycle/src/java/com/sun/faces/systest/ReplaceLifecycleTestCase.java
Sending jsf-ri/systest-per-webapp/replace-lifecycle/src/java/com/sun/faces/systest/SimplePhaseListener.java
Sending jsf-ri/test/com/sun/faces/config/TestFactoryInjection.java
Sending lib/jsf-extensions-test-time.jar
Transmitting file data ...........
Committed revision 8871.

Comment by Ed Burns [ 23/Feb/11 10:36 AM ]

add jsf_2_1_1 to status whiteboard

Comment by tedgoddard [ 22/Mar/11 03:46 PM ]

The following WARNING is seen when visiting the first page in an application running on Tomcat:

Mar 22, 2011 4:35:49 PM javax.faces.FactoryFinder$FactoryManagerCacheKey <init>
WARNING: Multiple JSF Applications found on same ClassLoader.  Unable to safely determine which FactoryManager instance to use. Defaulting to first match.

It has no functional impact.

Comment by Scott Fordin [ 24/Mar/11 03:09 PM ]

Does this still need to be added to the Release Notes? If so, I need more information.

Comment by Ed Burns [ 08/Apr/11 11:34 AM ]

Integrated into GlassFish 3.1.1

Comment by Scott Fordin [ 12/May/11 01:20 PM ]

Still need a more concise workaround.

Comment by Scott Fordin [ 17/May/11 09:35 AM ]

Added issue to 3.1 Known Issues section of 3.1-3.1.1 Release Notes. In the absence of a more concise workaround, I linked to the i_gf_15809-workaround.txt file that is attached to this issue.

Comment by bjornstenfeldt [ 26/Sep/11 06:48 AM ]

I'm finding it rather frustrating that I'm now getting around 1000 lines of "Multiple JSF Applications found on same ClassLoader. Unable to safely determine which FactoryManager instance to use. Defaulting to first match." in my log, every single second. Maybe a context-param in web.xml to disable this warning?

Comment by Ed Burns [ 26/Sep/11 03:41 PM ]

Hello Björn,

I am sincerely sorry for your frustration.

Is it acceptable to request that you modify your logging configuration, as described in <http://wikis.sun.com/display/GlassFish/JavaServerFacesRI#JavaServerFacesRI-HowcanIturnonlogging%3F> to prevent that logging message from being displayed?

Specifically, modify your logging.properties like this:

— logging.properties 2011-07-19 21:42:46.000000000 -0400
+++ logging_GLASSFISH-15809.properties 2011-09-26 11:40:23.000000000 -0400
@@ -113,3 +113,4 @@
javax.enterprise.system.ssl.security.level=INFO
ShoalLogger.level=CONFIG
org.eclipse.persistence.session.level=INFO
+javax.faces.level=INFO

Does that help?

Comment by bjornstenfeldt [ 27/Sep/11 11:28 AM ]

It will definitely fix it (javax.faces.level=SEVERE), but I worry that it might disables a lot of other information or warnings too, which is why I've been hesitating to use this method.

Comment by Ed Burns [ 27/Sep/11 08:48 PM ]

I can assure you that even though a logger such as javax.faces seems very "low level", there are very few log messages controlled by that logger. The vast majority of JSF related log messages are in the javax.enterprise.resource.webcontainer.jsf and sub loggers.

Comment by bjornstenfeldt [ 28/Sep/11 06:06 AM ]

Alright, I'll give it a chance.





[GLASSFISH-15775] Remote EJBs fail with ClassCastException in embeddable Glassfish Created: 31/Jan/11  Updated: 27/Sep/13  Resolved: 30/May/11

Status: Resolved
Project: glassfish
Component/s: embedded
Affects Version/s: 3.1_b39
Fix Version/s: 3.1.1_b07 , 4.0

Type: Bug Priority: Major
Reporter: ljnelson Assignee: Bhavanishankar
Resolution: Fixed Votes: 13
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

File Attachments: Zip Archive glassfish-test-arquillian.zip    
Tags: 3_1-exclude 3_1-fishcat 3_1-release-note-added 3_1-release-notes 3_1_1-next 3_1_1-approved
Participants: Bhavanishankar, jyrkip, ljnelson, marina vatkina, Nazrul, Sanjeeb Sahoo, Scott Fordin and vasilievip

 Description   

I think I've found a specification violation in the embeddable Glassfish project. My apologies if it turns out that this is not the case, but I've taken the liberty of setting the priority to Major because I don't see any wiggling out of this one.

Here's what the specification has to say about business interfaces of stateless session beans in section 4.9.7:

"If the business interface is a remote business interface, the argument and return values must be of valid types for RMI/IIOP. The remote business interface is not required or expected to be a java.rmi.Remote interface."

My business interface is declared thusly:

public interface AppealTypeManager extends DAO<Long, AppealType> { public Collection <? extends AppealType> findAllAppealTypes(final PagingControl pagingControl); }

(Note the lack of @Remote, and the lack of "extends Remote".)

My bean class is declared thusly:

@Stateless//(name = "AppealTypeManager")
@TransactionAttribute(TransactionAttributeType.REQUIRED)
@Remote(AppealTypeManager.class)
public class AppealTypeManagerBean extends AbstractDAO<Long, AppealType, AppealTypeEntity> implements AppealTypeManager { // ...etc. }

I look up a reference to the remote business interface like this:

final Context c = new InitialContext();
final AppealTypeManager a = (AppealTypeManager)c.lookup("java:global/test-classes/AppealTypeManagerBean");

When I deploy my EJB module to embeddable Glassfish, I get the following error upon lookup:

javax.naming.NamingException: Lookup failed for 'java:global/test-classes/AppealTypeManagerBean' in SerialContext[myEnv={java.naming.factory.initial=com.sun.enterprise.naming.impl.SerialInitContextFactory, java.naming.factory.state=com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl, java.naming.factory.url.pkgs=com.sun.enterprise.naming} [Root exception is javax.naming.NamingException: ejb ref resolution error for remote business interfacecom.jenzabar.ngp.ia.designation.api.AppealTypeManager [Root exception is java.lang.ClassCastException]]
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:525)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:392)
at javax.naming.InitialContext.lookup(InitialContext.java:392)
at com.jenzabar.junit.ejb.dbunit.mem.GlassfishEmbeddedStrategy.getBean(GlassfishEmbeddedStrategy.java:126)
at com.jenzabar.junit.ejb.dbunit.mem.AbstractEJBTestCase.setUp(AbstractEJBTestCase.java:98)
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.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:27)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
at org.junit.runners.BlockJUnit4ClassRunner.runNotIgnored(BlockJUnit4ClassRunner.java:79)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:71)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:49)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:59)
at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:120)
at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:145)
at org.apache.maven.surefire.Surefire.run(Surefire.java:104)
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.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:290)
at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1017)
Caused by: javax.naming.NamingException: ejb ref resolution error for remote business interfacecom.jenzabar.ngp.ia.designation.api.AppealTypeManager [Root exception is java.lang.ClassCastException]
at com.sun.ejb.EJBUtils.lookupRemote30BusinessObject(EJBUtils.java:434)
at com.sun.ejb.containers.RemoteBusinessObjectFactory.getObjectInstance(RemoteBusinessObjectFactory.java:75)
at javax.naming.spi.NamingManager.getObjectInstance(NamingManager.java:304)
at com.sun.enterprise.naming.impl.SerialContext.getObjectInstance(SerialContext.java:559)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:521)
... 34 more
Caused by: java.lang.ClassCastException
at com.sun.corba.ee.impl.javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:262)
at javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:137)
at com.sun.corba.ee.impl.presentation.rmi.DynamicMethodMarshallerImpl$12.read(DynamicMethodMarshallerImpl.java:353)
at com.sun.corba.ee.impl.presentation.rmi.DynamicMethodMarshallerImpl.readResult(DynamicMethodMarshallerImpl.java:483)
at com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.privateInvoke(StubInvocationHandlerImpl.java:203)
at com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.invoke(StubInvocationHandlerImpl.java:152)
at com.sun.corba.ee.impl.presentation.rmi.codegen.CodegenStubBase.invoke(CodegenStubBase.java:227)
at com.sun.ejb.codegen._GenericEJBHome_Generated_DynamicStub.create(com/sun/ejb/codegen/_GenericEJBHome_Generated_DynamicStub.java)
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.EJBUtils.lookupRemote30BusinessObject(EJBUtils.java:422)
... 38 more
Caused by: java.lang.ClassCastException: Object is not of remote type java.rmi.Remote
at com.sun.corba.ee.impl.javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:254)
... 50 more

Again, the specification does not require a remote business interface to extend java.rmi.Remote, but it would appear that the Glassfish embedded runtime thinks it's necessary.



 Comments   
Comment by Bhavanishankar [ 31/Jan/11 08:53 PM ]

This seems to be an EJB container (or may be naming) issue. Hence re-categorizing.

It can also be easily reproducible by running v2/appserv-tests/devtests/ejb/ejb31/embedded/remote

Comment by ljnelson [ 01/Feb/11 06:20 AM ]

This bug is present back through build 33; prior to that the API changed.

(Of course it looks from the signature of the devtest you're talking about that this goes back to Glassfish 2?)

"Forum" discussion here: http://www.java.net/forum/topic/glassfish/glassfish/glassfish-embedded-specification-violati

Comment by ljnelson [ 01/Feb/11 01:06 PM ]

This bug seems to have something to do with http://java.net/jira/browse/EMBEDDED_GLASSFISH-119, or rather both of them probably have the same underlying problem.

It is my understanding that javax.ejb.embeddable.EJBContainer is under no obligation to support @Remote EJBs, and that org.glassfish.embeddable.* MUST (or at least is intended to) support @Remote EJBs.

Comment by marina vatkina [ 01/Feb/11 05:38 PM ]

Bhavani, please take a look: changes for rev 38343 & 38344 caused this regression. If you think that EJB container needs to adjust for these changes, it'd be helpful to know what it should be aware of. I do not see anything suspicious about the CLs used in the EJBUtils.lookupRemote30BusinessObject.

Comment by Bhavanishankar [ 03/Feb/11 06:40 AM ]

Marina, the change revs you are referring to seem like the changes related to OSGi.
IMO that can not be the cause for this. Why do you think otherwise?

Comment by marina vatkina [ 03/Feb/11 05:35 PM ]

Bhavani, ejb31/embedded/remote passes with rev 38342 and fails with the ClassCastException: Object is not of remote type java.rmi.Remote with rev 38344.

Comment by Nazrul [ 07/Feb/11 06:59 PM ]

Since this did not make it into RC2, excluding from 3.1 count.

Comment by Sanjeeb Sahoo [ 07/Feb/11 10:44 PM ]

This is a Thread context class loader issue. GlassFish.start() sets the context class loader to an internal class loader and forgets to reset it after the call is complete. This is why user's classes can no longer be loaded using the context class loader in the thread that starts the server. Bhavani & I have discussed this and it will be addressed soon.

"A possible work around is to set the context class loader before looking up the remote EJB." e.g.,

GlassFish gf = GlassFishRuntime.bootstrap().newGlassFish();
gf.start();
gf.getDeployer().deploy(myapp);
ClassLoader oldCl = Thread.currentThread().getContextClassLoader();
try { Thread.currentThread().setContextClassLoader(getClass().getClassLoader()); new InitialContext().lookup(myEJB); } finally { Thread.currentThread().setContextClassLoader(oldCl); }

Comment by Bhavanishankar [ 07/Feb/11 10:56 PM ]

Just added a devtest under v3/tests/embedded/ejb/remoteejb which follows the workaround.

Comment by Scott Fordin [ 23/Mar/11 06:38 PM ]

Need more info to add issue to 3.1 Release Notes.

Comment by Scott Fordin [ 13/Apr/11 09:34 AM ]

Does this still need to be included in the 3.1 Release Notes? If so, I need more information.

Comment by Scott Fordin [ 17/May/11 01:30 PM ]

Went with what information I had. Added issue to 3.1 Known Issues section of 3.1-3.1.1 Release Notes.

Comment by Bhavanishankar [ 27/May/11 10:33 AM ]

Why fix this issue in 3.1.1?

> This is issue that is directly reported by community.

Which is the targeted build of 3.1.1 for this fix?

> b07

Do regression tests exist for this issue?

> Yes – embedded devtests/fidelity tests.

Which tests should QA (re)run to verify the fix did not destabilize GlassFish?

> Regular QA tests should be run. No new test is required. Embedded devtest will take care of verifying the fix.

Comment by Bhavanishankar [ 30/May/11 07:17 AM ]

Adding 3.2 also as the fixVersion

Comment by vasilievip [ 05/Aug/11 10:15 AM ]

Bug still exists on GF 3.1.1, please reopen.
Please find attached testcase.

Comment by jyrkip [ 27/Sep/13 06:29 AM ]

Happens on embedded 4.0 too.





[GLASSFISH-15763] [UB][regression] jpaRLCreateEMF failure on sybase Created: 31/Jan/11  Updated: 02/Dec/11  Resolved: 13/Apr/11

Status: Resolved
Project: glassfish
Component/s: docs
Affects Version/s: 3.1
Fix Version/s: 4.0

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

Solaris and Linux


Tags: 3_1-release-note-added 3_1-release-notes
Participants: Scott Fordin and sherryshen

 Description   

jpaRLCreateEMF failure on sybase
glassfisg-3.1-b39.zip

StandardWrapperValve[JpaServlet]:
PWC1406: Servlet.service() for servlet JpaServlet threw exception javax.persistence.PersistenceException:
Exception [EclipseLink-7197] (Eclipse Persistence Services - 2.2.0.v20110114-r8831):
org.eclipse.persistence.exceptions.ValidationException Exception Description:
Null or zero primary key encountered in unit of work clone [[JpaBean id=0, name=JpaBean]], primary key [0].
Set descriptors IdValidation or
the "eclipselink.id-validation" property. at org.eclipse.persistence.internal.jpa.EntityManagerImpl.flush(EntityManagerImpl.java:747)

The test passed on derby with v3.1 b39.
The test passed on sybassdd with b3.0 b64.



 Comments   
Comment by sherryshen [ 31/Jan/11 09:57 AM ]

To reproduce the failure:
set env with referece of
http://agni-1.us.oracle.com/JSPWiki/Wiki.jsp?page=V31CoreInstruction
where db info is in workspace
appserver-sqe/build-config/sybase_datadirect.properties
To run test,
cvs co appserver-sqe/bootstrap.xml
cd $SPS_HOME
ant -f bootstrap.xml co-ejb
ant start-domain
ant sybase-setup
cd pe/ejb/ejb30/war/jpaRLCreateEMF
ant sybasedd all

The clinet output shows:

[java] WS HOME appserver-sqe
[java] url=http://localhost:8080/RLCreateEMF/index.jsp
[java] url=http://localhost:8080/RLCreateEMF/jpa
[java] Unexpected return code: 500
.....
[java] -----------------------------------------
[java] - EJB3-RLCreateEMF-WAR-J2DB:jsp: PASS -
[java] - EJB3-RLCreateEMF-WAR-J2DB:servlet: FAIL -

server.log with FINE EL is saved in
http://agni-1.us.oracle.com/asqe-logs/export1/v3.1/Results/build39/dbtest/server.log.fine.jpaRLCreateEMF
which gives sybase info.
[#|2011-01-31T10:25:54.468-0800|INFO|glassfish3.1|
javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=104;_ThreadName=Thread-1;|
[EL Config]: 2011-01-31 10:25:54.467-ServerSession(32895865)-Connection(22292204)
--Thread(Thread[http-thread-pool-8080(4),5,grizzly-kernel])
--Connected: jdbc:datadirect:sybase://jsepc11.east.sun.com:5000;CATALOGOPTIONS=2;CONNECTIONRETRYDELAY=1;BULKLOADBATCHSIZE=1000;DATABASENAME=;MAXPOOLEDSTATEMENTS=0;PROGRAMID=0000016a;TRUSTSTOREPASSWORD=;VALIDATESERVERCERTIFICATE=true;CODEPAGEOVERRIDE=;CONNECTIONRETRYCOUNT=5;ENABLEBULKLOAD=false;BATCHPERFORMANCEWORKAROUND=false;INITIALIZATIONSTRING=;FAILOVERPRECONNECT=false;WORKSTATIONID=;RESULTSETMETADATAOPTIONS=0;CLIENTUSER=;QUERYTIMEOUT=0;FAILOVERGRANULARITY=nonAtomic;HOSTNAMEINCERTIFICATE=;APPLICATIONNAME=;JAVADOUBLETOSTRING=false;LOADLIBRARYPATH=;IMPORTSTATEMENTPOOL=;ALTERNATESERVERS=;ERRORBEHAVIOR=Exception;ENCRYPTIONMETHOD=NoEncryption;ACCOUNTINGINFO=;CONVERTNULL=1;TRUSTSTORE=;JDBCBEHAVIOR=1;FAILOVERMODE=connect;AUTHENTICATIONMETHOD=UserIdPassword;LOGINTIMEOUT=0;LONGDATACACHESIZE=2048;LOADBALANCING=false;PREPAREMETHOD=storedProcIfParam;TRANSACTIONMODE=explicit;USEALTERNATEPRODUCTINFO=false;WORKAROUNDS=0;INSENSITIVERESULTSETBUFFERSIZE=2048;PACKETSIZE=0;CLIENTHOSTNAME=;SERVICEPRINCIPALNAME=;SELECTMETHOD=direct
User: dbo
Database: SQL Server Version: Adaptive Server Enterprise/15.5/EBF 17218 SMP/P/NT (IX86)/Windows 2003/ase155/2391/32-bit/OPT/Mon Nov 09 14:18:14 2009
Driver: Sybase Version: 4.2.0.017715 (F044224.U015808)

#]
Comment by sherryshen [ 01/Feb/11 10:59 AM ]

I used dd driver from sqe v3.0 fcs branch.
I adjusted sqe trunk db properties according to sqe branch

http://agni-1.us.oracle.com/net/asqe-logs/export1/v3.1/Results/build39/dbtest/sybase_datadirect.properties.diff

! db.driver=com.sun.sql.jdbc.sybase.SybaseDriver
! db.class=com.sun.sql.jdbcx.sybase.SybaseDataSource
! db.xaclass=com.sun.sql.jdbcx.sybase.SybaseDataSource
! db.url=jdbc:sun:sybase://${db.host}:${db.port};SID=${db.sid};PrepareMethod=direct

Then, I ran tests with sqe trunk and v3.1 build 39, and tests passed.
server.log gives driver version.
http://agni-1.us.oracle.com/net/asqe-logs/export1/v3.1/Results/build39/dbtest/server.log.sybasedd.v30driver
[#|2011-02-01T10:32:20.730-0800|INFO|glassfish3.1|javax.enterprise.system.std.com.sun.enterprise.server.logging|
_ThreadID=99;_ThreadName=Thread-1;|[EL Config]: 2011-02-01 10:32:20.73-ServerSession(3243394)Connection(31389825)-Thread(Thread[http-thread-pool-8080(1),5,
grizzly-kernel])--Connected: jdbc:sun:sybase://jsepc11.east.sun.com:5000;CATALOGOPTIONS=2;CONNECTIONRETRYDELAY=1;BULKLOADBATCHSIZE=1000;DATABASENAME=;MAXPOOLEDSTATEMENTS=0;PROGRAMID=0000016a;TRUSTSTOREPASSWORD=;VALIDATESERVERCERTIFICATE=true;CODEPAGEOVERRIDE=;CONNECTIONRETRYCOUNT=5;ENABLEBULKLOAD=false;INITIALIZATIONSTRING=;FAILOVERPRECONNECT=false;WORKSTATIONID=;RESULTSETMETADATAOPTIONS=0;CLIENTUSER=;QUERYTIMEOUT=0;FAILOVERGRANULARITY=nonAtomic;HOSTNAMEINCERTIFICATE=;CATALOGINCLUDESSYNONYMS=true;APPLICATIONNAME=;JAVADOUBLETOSTRING=false;LOADLIBRARYPATH=;IMPORTSTATEMENTPOOL=;ALTERNATESERVERS=;ERRORBEHAVIOR=Exception;ENCRYPTIONMETHOD=NoEncryption;ACCOUNTINGINFO=;CONVERTNULL=1;TRUSTSTORE=;JDBCBEHAVIOR=1;FAILOVERMODE=connect;AUTHENTICATIONMETHOD=UserIdPassword;LOGINTIMEOUT=0;LONGDATACACHESIZE=2048;PREPAREMETHOD=direct;LOADBALANCING=false;TRANSACTIONMODE=explicit;USEALTERNATEPRODUCTINFO=false;SID=cts5;WORKAROUNDS=0;INSENSITIVERESULTSETBUFFERSIZE=2048;PACKETSIZE=0;CLIENTHOSTNAME=;SERVICEPRINCIPALNAME=;SELECT METHOD=direct
User: dbo
Database: Adaptive Server Enterprise Version: Adaptive Server Enterprise/15.5/EBF
17218 SMP/P/NT (IX86)/Windows 2003/ase155/2391/32-bit/OPT/Mon Nov 09 14:18:14 2009
Driver: Sybase Version: 4.0.016204 (040313.014801)

Comment by sherryshen [ 01/Feb/11 01:29 PM ]

Mitesh and I recalled that this is an old doc issue.
http://java.net/jira/browse/GLASSFISH-2431

Tests passed with new driver 4.2 and v3.1 b39 after
adjusting db properties.
RCS file: /m/jws/appserver-sqe/build-config/sybase_datadirect.properties,v

! db.url=jdbc:datadirect:sybase://${db.host}:${db.port}
— 9,15 ----
! db.url=jdbc:datadirect:sybase://${db.host}:${db.port};PrepareMethod=direct

Comment by sherryshen [ 01/Feb/11 01:34 PM ]

Transfer this bug to docs.
Please verify if it is in RN.

Enclosed is the note from Mitesh
for reference.

When using Data direct driver with Basely, if you are trying to insert
an entity that uses GenerationType.IDENTITY, it will fail. This is
because Datadirect driver creates a stored procedure for every
parameterized prepared statement. Please set property
PrepareMethod=direct on the corresponding datasource to change this
behavior and workaround this issue.

Comment by Scott Fordin [ 13/Apr/11 03:05 PM ]

Added issue to 3.1 Release Notes.





[GLASSFISH-15758] Restart Required status for remote instances does not get reset even when instance is restarted. Created: 30/Jan/11  Updated: 20/Feb/13  Resolved: 25/Mar/11

Status: Resolved
Project: glassfish
Component/s: admin
Affects Version/s: 3.1_b39
Fix Version/s: 4.0

Type: Bug Priority: Major
Reporter: shaline Assignee: Tom Mueller
Resolution: Cannot Reproduce Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 2008 Server.
browser : IE 7


Tags: 3_1-exclude
Participants: Anissa Lam, luisjotapepe, Scott Fordin, shaline and Tom Mueller

 Description   

On promoted build 39, when we add a JVM option to a remote instance ( on a SSH node), the restart required status shows up, but the status does not reset even after restarting the instance.
The status does not show when we Stop and Start the instance.

Steps:

Installed GF on 2 machines( A and B) , DAS Host is machine A, From the Admin Console on m/c A, created a remote node on machine B, using SSH (provided SSH user and password). The remote node in the machine B was created succesfully.
Created a new instance(std-ins1) on this remote-node and started the instance from the console.
In the remote-instances configuration (std-ins1-config),JVM Options,Add a JVM option, and Click Save.

Now for the remote instance "Restart Required" status gets displayed.
If we click " Restart" button , the process restarts the instance, but the instances status does not say "Running", but always displays as "Restart Required".

I tried list-instances -l option, I do see in CLI, the instance is restarted, as the PID is different, but the status still says "Restart Required".
I added the below JVM option " -Djava.security.manager" to the remote instance, on a SSH node.



 Comments   
Comment by Anissa Lam [ 30/Jan/11 04:37 PM ]

>> "I tried list-instances -l option, I do see in CLI, the instance is restarted, as the PID is different, but the status still says "Restart Required".

then why is this an admingui bug ?
transfer to 'admin'.

Comment by Tom Mueller [ 31/Jan/11 10:07 AM ]

When run strictly from the CLI, the restart-required indicated doesn't even show up as it should. So there are definitely some problems in this area.

This is not a critical issue that needs to be fixed for 3.1. Deferring to 3.2.

Comment by Tom Mueller [ 31/Jan/11 10:25 AM ]

I tried to reproduce this problem as follows:

Browser running on Windows XP (host laptop)
DAS running on Linux (host adc2180966)
Instance i1 running on Solaris x86 (host glassfish-x86-2)

Secure admin is enabled (has to be see browser is on different host than DAS).

When a JVM option is added or deleted from i1 using the console, the instance would correctly show that it needed to be restarted. A restart or a stop/start from the console would clear the restart required status.

However, creating a JVM option from the CLI would not cause the restart-required status to even be shown.

So in summary, I'm not seeing the behavior in the description, but I'm seeing other incorrect behavior.

Question: when seeing this for the first time, is secure admin enabled?
2nd: If so, are the DAS and the instance running JDK 1.6_22 or later?

Comment by shaline [ 31/Jan/11 11:33 AM ]

Hi Tom, Secure admin was not enabaled in my case.
my setup is as follows:
DAS host =windows 2008 server (bigapp-oblade-3)
remote host = windows 2008 server(asqe-oblade-20)
accessing Console from machine C (windows XP laptop).

JDK used is both DAS and remote host machine and the laptop is jdk 1.6.0_23.

I saw this issue on promoted b40 as well, when we add JVM option to a remote host (running), the "Restart" button does not reset the status. "Stop" and "Start" button does, but not "Restart".

Comment by Scott Fordin [ 18/Mar/11 01:14 PM ]

Added topic under "Restart Required" umbrella issue (http://java.net/jira/browse/GLASSFISH-16040) in 3.1 Release Notes.

Comment by Tom Mueller [ 25/Mar/11 04:09 PM ]

Can you still reproduce this issue?
With the latest trunk build, I'm not seeing it.

If you can provide a sequence of asadmin commands that reproduce the problem, that would be great. I'm resolving this as "cannot reproduce". If you can reproduce it, please reopen the bug.

Comment by luisjotapepe [ 20/Feb/13 07:59 AM ]

I am seeing this issue in GlassFish Server Open Source Edition 3.1.2.2 (build 5)
I have 5 servers
I installed GF on the first one
Through the admin console I created 4 GF SSH nodes
Deploy apps to all nodes
I start them all up
I changed a JVM options which is applied to all apps
Instances say Restart-Required
I restart all instances from CLI - asadmin restart-instance insatnceName
Only the instances in domain1 (where the DAS resides) says Running. The rest still say Restart Required

Does restart do full sync?

Comment by Tom Mueller [ 20/Feb/13 02:26 PM ]

What do you mean by "only the instances in domain1 (...) says Running"? Aren't all of the instances in domain1?

A restart synchronizes the files that need to be synced. In the case of a JVM option change, the domain.xml file would be synced.





[GLASSFISH-15724] Glassfish Installer does not update MQ config file (imqenv.conf) with values Created: 27/Jan/11  Updated: 07/Apr/11  Resolved: 03/Mar/11

Status: Resolved
Project: glassfish
Component/s: installation
Affects Version/s: 3.1_b39
Fix Version/s: 3.1.1_b01

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

All


Tags: 3_1-exclude 3_1-release-note-added 3_1-release-notes glassfish-3-1 install messagequeue
Participants: Jill Sato, mathim, scatari and Scott Fordin

 Description   

Glassfish Installer does not update MQ config file (imqenv.conf) with values (for example, JDK HOME dir). This would be useful when MQ is run independent of glassfish.

I think the earlier versions of glassfish installers updated this file with Jdk home and other values.

Appropriate workaround would be to update the imqenv.conf file (located under MQ_HOME/etc directory) manually.



 Comments   
Comment by scatari [ 27/Jan/11 06:27 PM ]

3.x installers haven't done this configuration required for MQ. Anyway this is too late to fix in 3.1, if its a requirement then we will address this in 3.2.

Comment by scatari [ 27/Jan/11 06:28 PM ]

Not sure if this is a possible release note candidate. If the MQ team feels that way, please do bring to "docs" team's attention.

Comment by mathim [ 03/Mar/11 01:19 PM ]

provide more info to doc team

Comment by Jill Sato [ 03/Mar/11 01:19 PM ]

Optionally for release notes (nice to have):
------------------------------------------

MQ executables will use the 'java' in the user's PATH.
The user can also specify another Java Runtime by setting
IMQ_DEFAULT_JAVAHOME in the imqenv.conf file.

On Unix (e.g.)
IMQ_DEFAULT_JAVAHOME=/usr/jdk/jdk1.6.0

On Windows (e.g.)
IMQ_DEFAULT_JAVAHOME=c:\path\to\jdk

Comment by Scott Fordin [ 03/Mar/11 06:50 PM ]

Issue added to 3.1 Release Notes.

Comment by Scott Fordin [ 24/Mar/11 03:12 PM ]

Added "3_1-release-note-added" tag.





[GLASSFISH-15721] "injection points in one bean deployment archive cannot be satisfied by a bean in a separate bean archive, even when they are from libraries in the same module (web archive)" Created: 27/Jan/11  Updated: 18/Jul/11  Resolved: 09/Jun/11

Status: Resolved
Project: glassfish
Component/s: cdi
Affects Version/s: 3.1_b39
Fix Version/s: 3.1.1_b05

Type: Bug Priority: Critical
Reporter: stuartdouglas Assignee: Sivakumar Thyagarajan
Resolution: Fixed Votes: 20
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

File Attachments: Java Archive File weld-osgi-bundle.jar    
Issue Links:
Duplicate
duplicates GLASSFISH-15906 CDI resolver issues Resolved
is duplicated by GLASSFISH-15888 CDI not working well on Glassfish v3.... Resolved
is duplicated by GLASSFISH-15794 JAX-RS injection broken for library @... Resolved
Tags: 3_1-exclude 3_1-release-note-added 3_1-release-notes 3_1_1-review
Participants: cbarragan, DiegoCoronel, eratzlaff, mimik789, mojavelinux, Nazrul, scatari, Scott Fordin, Sivakumar Thyagarajan, stuartdouglas, toomanyryans, vostok and vrcollins

 Description   

The Bean Deployment Archive visibility graph does not correctly implement the spec.

Beans in WEB-INF/lib are made availible to beans in WEB-INF/classes, however the converse is not true (i.e. beans is WEB-INF/classes cannot be injected into WEB-INF/lib injection points), and beans in one jar in WEB-INF/lib cannot be injected into beans in a different jar in WEB-INF/lib.

According to the CDI and EE6 Platform spec both of these should work.

https://svn.dev.java.net/svn/glassfish-svn/trunk/v3/web/weld-integration/src/main/java/org/glassfish/weld/DeploymentImpl.java



 Comments   
Comment by mojavelinux [ 27/Jan/11 11:22 PM ]

Two tests have been prepared to demonstrate cases when beans within the same bean archive are not visible to each other.

https://github.com/seam/solder/blob/master/impl/src/test/java/org/jboss/seam/solder/test/compat/TypeVisibilityForExtensionInNonBeanArchiveTest.java
https://github.com/seam/solder/blob/master/impl/src/test/java/org/jboss/seam/solder/test/compat/TypeVisibilityWithinBeanArchiveTest.java

These tests can be run from the root of the Solder project as follows:

mvn clean test -Dincontainer-glassfish-rest -Dtest=TypeVisibilityForExtensionInNonBeanArchiveTest
mvn clean test -Dincontainer-glassfish-rest -Dtest=TypeVisibilityWithinBeanArchiveTest

These tested use the new Arquillian GlassFish adapter created by Jason Porter and based on the GlassFish REST API.

Comment by Sivakumar Thyagarajan [ 01/Feb/11 10:29 AM ]

Investigation in progress. It appears to be an issue with the way Weld handles accessibility of cyclic references among BeanDeploymentArchives. I have requested the help of Weld engineering team to understand this better, and will update this issue.

Comment by Sivakumar Thyagarajan [ 02/Feb/11 02:12 AM ]

This issue occurs because of the way Weld handles cyclic references among BDAs. I have raised https://issues.jboss.org/browse/WELD-846 to track the Weld side change needed to fix this issue. We will integrate the next available release of Weld that provides a fix for this issue in the next update release of GlassFish 3.1.

Release note/Workaround:
Until then the application could be repackaged such that either:

  • Beans in WEB-INF/classes are not used/injected in classes bundled in WEB-INF/lib/*.jar
  • All Beans are available as part of WEB-INF/classes [ie collapse the bundled library in WEB-INF/lib/*.jar into WEB-INF/classes].
Comment by Sivakumar Thyagarajan [ 11/Feb/11 06:19 AM ]

FWIW, Weld has fixed the root issue https://github.com/stuartwdouglas/core/tree/WELD-846 in their trunk and this scenario would work again once we integrate the Weld 1.2.0.Beta distribution when it becomes available.

I also tried this scenario against a local build of Weld trunk(attached the weld-osgi-bundle.jar that I used at http://java.net/jira/secure/attachment/44919/weld-osgi-bundle.jar , place this under $INSTALL_ROOT/modules and restart the domain to reproduce this).

Comment by mimik789 [ 11/Feb/11 06:48 AM ]

I tested provided weld-osgi-bundle.jar in GF3 b_41 (web), and also in latest nightly build - as described in guidliness https://issues.jboss.org/browse/WELD-846 (in exception to that I have to remove content from arquillian.xml config file for jboss - without that test can't be executed, and that I need to replace test with integration-test).
ie:
1/
mvn clean integration-test -Dincontainer-glassfish-rest -Dtest=TypeVisibilityWithinBeanArchiveTest

2/
mvn clean integration-test -Dincontainer-glassfish-rest -Dtest=TypeVisibilityForExtensionInNonBeanArchiveTest

first test (TypeVisibilityWithinBeanArchiveTest) passes OK

but second test (TypeVisibilityForExtensionInNonBeanArchiveTest) FAIL with:

org.jboss.weld.exceptions.DeploymentException: WELD-001409 Ambiguous dependencies for type [BeanClassToRegister] with qualifiers [@Default] at injection point [[field] @Inject private org.jboss.seam.solder.test.compat.AnotherBeanClassToRegister.collaborator]. Possible dependencies [[Managed Bean [class org.jboss.seam.solder.test.compat.BeanClassToRegister] with qualifiers [@Any @Default], Managed Bean [class org.jboss.seam.solder.test.compat.BeanClassToRegister] with qualifiers [@Any @Default]]]
at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:309)
at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:139)
at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:162)
at org.jboss.weld.bootstrap.Validator.validateBeans(Validator.java:385)
at org.jboss.weld.bootstrap.Validator.validateDeployment(Validator.java:371)
at org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:394)
at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:190)
...

having same issue?

Comment by vostok [ 16/Feb/11 02:35 AM ]

I'm experiencing a lot of problems in 3.1 versions with my modular project using CDI. It works great (despite CDI memory leaks issues, manually fixed) with 3.0.1 but I cannot deploy it with 3.1 RCs!

Tags: 3_1-exclude 3_1-release-notes

^

----- Solving this bug is being excluded from 3.1 final???

Comment by eratzlaff [ 16/Feb/11 06:36 AM ]

It would be nice to have this bug fix for glassfish 3.1 release.

Comment by mimik789 [ 21/Feb/11 03:43 AM ]

You may be interested with this good news:
http://seamframework.org/Community/SeamFacesPersistenceServletCatchProduceNullPointerException#comment149620

for lazy guys and girls: I'm attaching fixed weld-core.jar (weld-osgi-bundle.jar) built from:
https://github.com/stuartwdouglas/core/tree/WELD-859

Comment by DiegoCoronel [ 10/Mar/11 05:52 AM ]

The jar attached does not resolved my problem. I deleted osgi-cache after change the jar and it does not worked.
My war classes cant inject my jar classes.

It works fine in glassfish 3.0.1 final.

In my specific case i have this scenary

myWebModule.war
– MyJarProject1.jar (depends:MyFramework, myWebModule.war)
– MyJarProject2.jar (depends:MyFramework, MyJarProject1, myWebModule.war)
– MyFramework.jar (depends:myWebModule.war)

where all jar modules depends on war because they inject EntityManager that is produced by war because it does not worked if jar produce EntityManager.

Comment by mojavelinux [ 21/Mar/11 11:20 PM ]

Here's an updated test case:

https://github.com/seam/solder/blob/master/impl/src/test/java/org/jboss/seam/solder/test/compat/visibility/VisibilityOfBeanInWebModuleFromBeanManagerInBeanLibraryTest.java

Comment by Scott Fordin [ 23/Mar/11 06:41 PM ]

Need more info to add issue to 3.1 Release Notes.

Comment by Nazrul [ 21/Apr/11 11:11 AM ]

It would be useful to look into this issue for 3.1.1

Comment by vrcollins [ 05/May/11 01:29 PM ]

I am in the same boat as vostok. I am able to get everything working fine in glassfish 3.0.1. I am using glassfish 3.1 with build 43. I have replaced the weld-osgi-bundle.jar file with the one in this ticket. I am getting the same errors.

Comment by toomanyryans [ 10/May/11 02:51 PM ]

I think I've been running into this bug. Assume I have two .jars:

WEB-INF/lib/jarA
WEB-INF/lib/jarB

If jarB is dependent on jarA, is it possible they could get scanned in a different order depending on the system I'm deploying to? Specifically, embedded Glassfish on Windows vs normal Glassfish on Linux?

I noticed that Glassfish 3.1.1-b04 is using Weld 1.1.1.Final and it fixes my problem. The Weld issue mentioned here (WELD-846) was fixed for 1.1.1.Final, so I think this maybe resolved in Glassfish 3.1.1-b04+. It may be worth testing again if you're watching this issue.

Comment by Scott Fordin [ 17/May/11 11:43 AM ]

Added issue to 3.1 Known Issues section in 3.1-3.1.1 Release Notes.

Comment by scatari [ 24/May/11 03:43 PM ]

Fix expected by first week of June.

Comment by Sivakumar Thyagarajan [ 09/Jun/11 08:26 AM ]

This issue has been fixed since the integration of Weld 1.1.1.Final (that fixes root cause WELD-846) into GlassFish 3.1.1(b4+) and GlassFish trunk.

Through svn revision 47397, I have also added the following developer tests to cover this scenario
javaee-integration/cdi-servlet-3.0-annotation-with-web-inf-lib/

Comment by cbarragan [ 14/Jul/11 09:44 AM ]

As for Glassfish 3.1.1b11 I think the issue might not be solved, although my problem differs from the original issue.

I have an EAR with an ejb module and some jars in the lib directory.
A dependency in a class that resides in the lib directory cannot be satisfied. This dependency should be solved by a class in my ejb module, but it seems that the class in the ejb module is not visible to the class in the lib directory. Is this another issue? If so, is there an issue related to this problem?

Comment by Sivakumar Thyagarajan [ 18/Jul/11 07:00 PM ]

@cbarragan:

As per section 5.1 of the CDI 1.0 specification:
"In the Java EE module architecture, a bean class is accessible in a module if and only if it is required to be accessible according to the class loading requirements defined by the Java EE platform specification."

In the scenario you had mentioned above: as the EJB module class is not required to be accessible to a jar in the lib directory, the bean class is not available for injection.





[GLASSFISH-15715] [UB] document jdbc/__default for a cluster Created: 27/Jan/11  Updated: 17/Mar/11  Resolved: 17/Mar/11

Status: Resolved
Project: glassfish
Component/s: docs
Affects Version/s: 3.1
Fix Version/s: 3.1

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

Tags:
Participants: marina vatkina, Nazrul and Scott Fordin

 Description   

In a stand-alone server (like 3.0.x) has jdbc/__default available out of the box. In a clustered environment the user needs to perform extra steps if they still want to use this resource. If this is the same behavior as in 2.x, it should have been already documented somewhere. If it is not, we need to add some notes.

Refer to this issue: http://java.net/jira/browse/GLASSFISH-13755



 Comments   
Comment by Scott Fordin [ 11/Feb/11 12:25 PM ]

Not clear to me where and what you want me to say to address this issue. Can someone please advise?

Comment by marina vatkina [ 15/Feb/11 10:26 AM ]

See Elena's comment in http://java.net/jira/browse/GLASSFISH-12878 from 14/Feb/11 11:47 AM. All but step #5 apply here.

Comment by Scott Fordin [ 20/Feb/11 07:15 PM ]

Added topic to Application Development Guide.

Comment by marina vatkina [ 21/Feb/11 04:44 PM ]

jdbc/__default setup in a cluster should be documented in a centralized location

Comment by Scott Fordin [ 17/Mar/11 06:24 PM ]

We went through several review cycles for this issue and it was signed off for 3.1. Among other places, this topic has been documented in the Administration Guide, in "Enabling the jdbc/__default Resource in a Clustered Environment" (http://download.oracle.com/docs/cd/E18930_01/html/821-2416/ggndx.html#gkudf), which is about as centralized a location as we can get.





[GLASSFISH-15713] [UB]Non-sticky Load Balancer not supported in GlassFish HA Created: 27/Jan/11  Updated: 07/Mar/12

Status: In Progress
Project: glassfish
Component/s: docs
Affects Version/s: 3.1_b39
Fix Version/s: not determined

Type: Bug Priority: Major
Reporter: Rajiv Mordani Assignee: Mike Fitch
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1-approved 3_1-need_more_info
Participants: Mike Fitch, Paul Davies, Rajiv Mordani, Scott Fordin and Tom Mueller

 Description   

Need to document that when GlassFish is front ended with a non sticky load balancer HA is not supported. It may result in some data loss. Please see bug
http://java.net/jira/browse/GLASSFISH-15575



 Comments   
Comment by Paul Davies [ 27/Jan/11 12:32 PM ]

Reassigned to sfordin. Corrected typo in tag.

Comment by Scott Fordin [ 11/Feb/11 12:04 PM ]

With all the back-and-forth in the comments on this issue, it is unclear to me what actually needs to be said in the docs here, and even in which doc this issue would be most appropriately discussed. Can someone please advise me here?

Comment by Scott Fordin [ 17/Mar/11 06:26 PM ]

Second request: I still need more information to document this issue. It is not clear to me what needs to be said here and where it needs to be said. Can someone please advise?

Comment by Scott Fordin [ 31/May/11 10:14 AM ]

Reassigning to Paul Davies.

Comment by Tom Mueller [ 07/Mar/12 02:47 PM ]

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





[GLASSFISH-15712] java.security.AccessControlException thrown from the MBeanServer when SecurityManager is turned ON Created: 27/Jan/11  Updated: 08/Dec/11  Resolved: 08/Dec/11

Status: Closed
Project: glassfish
Component/s: amx
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: prasads Assignee: naman_mehta
Resolution: Cannot Reproduce Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

All OSes, if the security manager is turned on


Tags: 3_1_2-review
Participants: naman_mehta, Nazrul, prasads and Scott Fordin

 Description   

When the Security Manager is turned on and the QLs are run , then we see this exception
Caused by: java.lang.RuntimeException: Can't add NotificationListener
at org.glassfish.external.amx.MBeanListener.startListening(MBeanListener.java:253)
at org.glassfish.gmbal.impl.JMXRegistrationManager.setRoot(JMXRegistrationManager.java:128)
at org.glassfish.gmbal.impl.MBeanTree.setRoot(MBeanTree.java:114)
... 109 more
Caused by: java.security.AccessControlException: access denied (javax.management.MBeanPermission javax.management.MBeanServerDelegate#-[JMImplementation:type=MBeanServerDelegate] addNotificationListener)
at java.security.AccessControlContext.checkPermission(AccessControlContext.java:323)
at java.security.AccessController.checkPermission(AccessController.java:546)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.checkMBeanPermission(DefaultMBeanServerInterceptor.java:1806)
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.checkMBeanPermission(DefaultMBeanServerInterceptor.java:1789)
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.addNotificationListener(DefaultMBeanServerInterceptor.java:1191)
at com.sun.jmx.mbeanserver.JmxMBeanServer.addNotificationListener(JmxMBeanServer.java:799)

This happens because invoking these methods on the MBeanServer requires explicit permissions which have to be provided either via the server.policy or by invoking the method in a doPrivileged block.

--------------------------------
Here are the answers to the questions :
How bad is its impact? (Severity)

--> If the security manager is turned in then the MBeanServer operation out-of-the-box would be impacted.
Identify why the fix needs to occur now:

  • Likely to generate a customer support call

How often does it happen?

--> Only when the Security Manager is turned on

How much effort is required to fix it? (Cost)

--> There is a fix, and its in the DynamicInterceptor.

What is the risk of fixing it? (Risk)

--> It should not affect the code when the security manager is not turned on. But the change is incisive. Risk is 3 on a scale of 5

Does a work around for the issue exist? Can the workaround be reasonably employed by the end user?

--> Yes, by adding permissions in the server.policy.

If the issue is not fixed should the issue and its workaround (if applicable) be described in the Release Notes?
--> Yes.



 Comments   
Comment by Nazrul [ 04/Feb/11 03:40 PM ]

Based on discussion with Prasad, we are investigating a manual step (update server.policy) to resolve this. I am marking this issue to be release noted.

Comment by prasads [ 20/Feb/11 08:03 AM ]

Assigning issues to Naman

Comment by Scott Fordin [ 23/Mar/11 06:43 PM ]

Need more info to add issue to 3.1 Release Notes.

Comment by Scott Fordin [ 17/May/11 01:57 PM ]

Still need more info before I can add topic to Release Notes. Specifically, what permissions should be added to server.policy? Can you please provide an example?

Comment by naman_mehta [ 08/Dec/11 10:43 AM ]

Not reproducible with latest 3.1.2 build. Rung GF QL with security manager ON.





[GLASSFISH-15709] [UB]Accessing encoded URLS throws 403: Forbidden Created: 27/Jan/11  Updated: 07/Jul/11  Resolved: 07/Jul/11

Status: Resolved
Project: glassfish
Component/s: docs
Affects Version/s: 3.1
Fix Version/s: 3.1.1

Type: Bug Priority: Major
Reporter: Jothir Ganesan Assignee: Rebecca Parks
Resolution: Fixed Votes: 0
Remaining Estimate: