[GLASSFISH-18889] Register GlassFish as an OSGi service only after GlassFish is started Created: 11/Jul/12  Updated: 12/Jul/12  Resolved: 12/Jul/12

Status: Resolved
Project: glassfish
Component/s: OSGi
Affects Version/s: 3.1.2
Fix Version/s: 4.0

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

Tags: 3_1_x-exclude

 Description   

Currently we register GlassFish service in GlassFishRuntime.newGlassFish(). This causes problems for clients who try to use it as they can only call getStatus() method on the registered object until it is started. So, clients have to unnecessarily write polling logic. So, we should register when underlying service is started and unregistered when underlying service is stopped.



 Comments   
Comment by Sanjeeb Sahoo [ 12/Jul/12 ]

Log Message:
------------
GLASSFISH-18888: "Already bootstrapped" exception while updating glassfish.jar
GLASSFISH-18889: Register GlassFish as an OSGi service only after GlassFish is started
GLASSFISH-18891: Use decorator pattern for various GFRImpls and GFimpls

Revisions:
----------
55086

Modified Paths:
---------------
trunk/main/nucleus/core/bootstrap/src/main/java/com/sun/enterprise/glassfish/bootstrap/osgi/GlassFishMainActivator.java
trunk/main/nucleus/core/bootstrap/src/main/java/com/sun/enterprise/glassfish/bootstrap/osgi/OSGiGlassFishImpl.java
trunk/main/nucleus/core/bootstrap/src/main/java/com/sun/enterprise/glassfish/bootstrap/osgi/OSGiGlassFishRuntimeBuilder.java
trunk/main/nucleus/core/bootstrap/src/main/java/com/sun/enterprise/glassfish/bootstrap/osgi/OSGiGlassFishRuntime.java
trunk/main/nucleus/core/bootstrap/src/main/java/com/sun/enterprise/glassfish/bootstrap/osgi/EmbeddedOSGiGlassFishRuntime.java
trunk/main/nucleus/core/bootstrap/src/main/java/com/sun/enterprise/glassfish/bootstrap/osgi/EmbeddedOSGiGlassFishRuntimeBuilder.java
trunk/main/nucleus/core/bootstrap/src/main/java/com/sun/enterprise/glassfish/bootstrap/osgi/EmbeddedOSGiGlassFishImpl.java





[GLASSFISH-18888] "Already bootstrapped" exception while updating glassfish.jar Created: 11/Jul/12  Updated: 12/Jul/12  Resolved: 12/Jul/12

Status: Resolved
Project: glassfish
Component/s: OSGi
Affects Version/s: 3.1.2
Fix Version/s: 4.0

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

Tags: 3_1_x-exclude

 Description   

Do the following:

Step 1:
Edit felix/conf/config.properties to make system.bundle export org.glassfish.embeddable packages. This is a key step. This is what causes the exception, because GlassFishRuntime is loaded by system bundle, hence GlassFishMainActivator can't bootstrap it without shutting down and currently in GlassFishMainActivator.stop() does not call gfr.shutdown().

Step 2:
java -cp /space/ss141213/WS/gf/v3/publish/glassfish3/glassfish/modules/simple-glassfish-api.jar:bin/felix.jar org.apache.felix.main.Main
-> start file:/space/ss141213/WS/gf/v3/publish/glassfish3/glassfish/modules/glassfish.jar
...
-> update 5

You shall see:
Completed shutdown of Log manager service
[#|2012-07-11T21:46:48.989+0530|INFO|44.0|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=10;_ThreadName=Gogo shell;|Shutdown procedure finished|#]

Provisioning options are

{glassfish.osgi.auto.start=file:/space/ss141213/WS/gf/v3/publish/web/glassfish3/glassfish/modules/endorsed/ file:/space/ss141213/WS/gf/v3/publish/web/glassfish3/glassfish/modules/osgi-adapter.jar file:/space/ss141213/WS/gf/v3/publish/web/glassfish3/glassfish/modules/osgi-resource-locator.jar file:/space/ss141213/WS/gf/v3/publish/web/glassfish3/glassfish/modules/org.apache.felix.configadmin.jar file:/space/ss141213/WS/gf/v3/publish/web/glassfish3/glassfish/modules/org.apache.felix.fileinstall.jar file:/space/ss141213/WS/gf/v3/publish/web/glassfish3/glassfish/modules/autostart/ , glassfish.osgi.auto.install=file:/space/ss141213/WS/gf/v3/publish/web/glassfish3/glassfish/modules/endorsed/ file:/space/ss141213/WS/gf/v3/publish/web/glassfish3/glassfish/modules/ file:/space/ss141213/WS/gf/v3/publish/web/glassfish3/glassfish/modules/autostart/ }

org.glassfish.embeddable.GlassFishException: Already bootstrapped



 Comments   
Comment by Sanjeeb Sahoo [ 12/Jul/12 ]

Log Message:
------------
GLASSFISH-18888: "Already bootstrapped" exception while updating glassfish.jar
GLASSFISH-18889: Register GlassFish as an OSGi service only after GlassFish is started
GLASSFISH-18891: Use decorator pattern for various GFRImpls and GFimpls

Revisions:
----------
55086

Modified Paths:
---------------
trunk/main/nucleus/core/bootstrap/src/main/java/com/sun/enterprise/glassfish/bootstrap/osgi/GlassFishMainActivator.java
trunk/main/nucleus/core/bootstrap/src/main/java/com/sun/enterprise/glassfish/bootstrap/osgi/OSGiGlassFishImpl.java
trunk/main/nucleus/core/bootstrap/src/main/java/com/sun/enterprise/glassfish/bootstrap/osgi/OSGiGlassFishRuntimeBuilder.java
trunk/main/nucleus/core/bootstrap/src/main/java/com/sun/enterprise/glassfish/bootstrap/osgi/OSGiGlassFishRuntime.java
trunk/main/nucleus/core/bootstrap/src/main/java/com/sun/enterprise/glassfish/bootstrap/osgi/EmbeddedOSGiGlassFishRuntime.java
trunk/main/nucleus/core/bootstrap/src/main/java/com/sun/enterprise/glassfish/bootstrap/osgi/EmbeddedOSGiGlassFishRuntimeBuilder.java
trunk/main/nucleus/core/bootstrap/src/main/java/com/sun/enterprise/glassfish/bootstrap/osgi/EmbeddedOSGiGlassFishImpl.java





[GLASSFISH-18239] IllegalStateException when server is stopped via Ctrl^C or SIGINT Created: 24/Jan/12  Updated: 20/Dec/16  Resolved: 24/Jan/12

Status: Resolved
Project: glassfish
Component/s: OSGi
Affects Version/s: 4.0_dev
Fix Version/s: 4.0

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

Tags: 3_1_x-exclude

 Description   

^CCompleted shutdown of Log manager service
Error stopping framework: java.lang.IllegalStateException: Service already unregistered.
java.lang.IllegalStateException: Service already unregistered.
at org.apache.felix.framework.ServiceRegistrationImpl.unregister(ServiceRegistrationImpl.java:123)
at com.sun.enterprise.glassfish.bootstrap.osgi.EmbeddedOSGiGlassFishRuntime.remove(EmbeddedOSGiGlassFishRuntime.java:147)
at com.sun.enterprise.glassfish.bootstrap.osgi.EmbeddedOSGiGlassFishImpl.dispose(EmbeddedOSGiGlassFishImpl.java:68)
at com.sun.enterprise.glassfish.bootstrap.osgi.EmbeddedOSGiGlassFishRuntime.shutdown(EmbeddedOSGiGlassFishRuntime.java:106)
at com.sun.enterprise.glassfish.bootstrap.osgi.OSGiGlassFishRuntime.shutdown(OSGiGlassFishRuntime.java:84)
at com.sun.enterprise.glassfish.bootstrap.GlassFishMain$Launcher$1.run(GlassFishMain.java:203)



 Comments   
Comment by Sanjeeb Sahoo [ 24/Jan/12 ]

Revisions:
----------
52256

Modified Paths:
---------------
trunk/main/nucleus/core/bootstrap/src/main/java/com/sun/enterprise/glassfish/bootstrap/osgi/EmbeddedOSGiGlassFishRuntime.java





[GLASSFISH-18173] Support relocation of keystore and truststore (configure -Djavax.net.ssl.trustStore) Created: 12/Jan/12  Updated: 22/May/13

Status: Open
Project: glassfish
Component/s: admin
Affects Version/s: 3.1.2
Fix Version/s: future release

Type: New Feature Priority: Major
Reporter: Shing Wai Chan Assignee: kumara
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1_x-exclude

 Description   

1. move keystore.jks and cacerts.jks to /tmp
2. modify the -Djavax.net.ssl.keyStore, -Djavax.net.ssl.trustStore to point to /tmp/keystore.jks and /tmp/cacerts.jks respectively
3. Cannot start the server as it keeps prompting the master password

asadmin start-domain domain1
Enter master password (3) attempt(s) remain)>
Sorry, incorrect master password, retry
Enter master password (2) attempt(s) remain)>
Sorry, incorrect master password, retry
Enter master password (1) attempt(s) remain)>
Number of attempts (3) exhausted, giving up
Command start-domain failed.

But if I copy cacerts.jks back to domains/domain1/config, then I can start the server with https working properly with the certificate in /tmp/keystore.jks.



 Comments   
Comment by Tom Mueller [ 12/Jan/12 ]

The root cause of this issue is the LocalServerCommand.getJKS method, which has a hardcoded reference to

new File(new File(serverDirs.getServerDir(), "config"), "cacerts.jks")

for the file to use to verify the validity of the master password. This is incorrect for several reasons.

1) the certs file the user is using might not be called cacerts.jks
2) it might not be in the config directory (as pointed out by this issue)

A better way to verify the master password is to check it against the domain-passwords file the location of which is not configurable by the user.

Note: the change master password command is also hardcoded to reference the keystore.jks and cacerts.jks files in the domain's config directory. As least this command does not support having these files in another location.

However, the security guide, in the section that talks about generating a certificate (http://docs.oracle.com/cd/E18930_01/html/821-2435/ablqz.html#), has the following:

"Always generate the certificate in the directory containing the keystore and truststore files. The default is domain-dir/config."

The statement that the default is domain-dir/config would seem to imply that it is possible to store the keystore and truststore files somewhere else. However, the code in at least these two places does not support that.

Comment by Tom Mueller [ 13/Jan/12 ]

There are several functions within GlassFish that depend on the names and locations of the keystore and truststore files, including:

  • domain creation (PEDomainsManager)
  • change-master-password
  • DAS and instance startup (GFLauncher)
  • instance synchronization (hardcoded in config-files file)

In order to support moving and/or renaming these files, at least these places would need to be fixed.

Shing Wai reports that this was supported in 2.x, however it isn't clear what "this" is. Is it just that the javax.net.ssl.trustStore JVM property could be set, but these other functions do not handle it properly - or did everything work?

Comment by Tom Mueller [ 18/Jan/12 ]

I did some experimenting with GF 2.1.1 and here is what I found.

1. I moved the cacerts.jks and keystore.jks files to domains/domain1/tmp and edited the JVM options to point to them. Then started the domain and it started fine (this confirms the initial premise in the bug).

2. I stopped the domain and ran change-master-password. It prompted for the new password and appeared to run successfully - no error messages or log messages. Then I tried starting the domain. This time it prompted for the admin password and the master password. I entered an incorrect master password and it correctly detected that and the domain did not start. Next I started the domain again and entered the correct password, but the domain still did not start but it produce a different log message saying:

Caused by: java.lang.IllegalStateException: Keystore was tampered with, or password was incorrect

So clearly, the keystore in the new location did not have it's password changed by change-master-password.

3. I created a cluster that has a config with the keystore and truststore JVM options pointed at the new location. Instances in that cluster failed to start because the keystore.jks and cacerts.jks files were not synchronized from the DAS. The instances reported a file not found error.

So this confirms that GF 2.1.1 really doesn't support having the keystore or truststore files moved or renamed, at least it doesn't support this fully.

IMHO, this is not a regression.

Comment by Tom Mueller [ 18/Jan/12 ]

Changing this to be an RFE targeted for a future release. Excluding from 3.1.x releases.

Comment by Shing Wai Chan [ 18/Jan/12 ]

This is a regression on the DAS.





[GLASSFISH-18107] error message appearing after 'save' of new jdbc connection pool or resource Created: 30/Dec/11  Updated: 20/Dec/16  Resolved: 03/Jan/12

Status: Resolved
Project: glassfish
Component/s: admin_gui
Affects Version/s: 3.1.2_dev
Fix Version/s: 3.1.2_dev, 4.0_dev

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

windows 7, jdk 7u2, x64.


Attachments: File server_.7z    
Issue Links:
Duplicate
is duplicated by GLASSFISH-18129 Modifying values in LB Config throws ... Resolved
is duplicated by GLASSFISH-18136 Blocking: RuntimeException modifying ... Closed
Tags: 3_1_2-review, 3_1_x-exclude

 Description   

did a fresh install of glassfish 3.1.2 b16.

manually added the latest jdbc4 driver jar for postgresql to the domain

{x}

/lib directory then started the domain.

proceeded to add a JDBC Connection Pool, and after the initial 'save' button usage, was presented with (in the right hand pane) 'class java.lang.RuntimeException'.

I did find that the settings had been saved, however.

I proceeded to add a JDBC Resource for the newly added pool, and, upon using the 'save' button, was again rewarded with the same message being displayed.

Again, the pool definition did appear to have been saved.

I have attached the log file.



 Comments   
Comment by Anissa Lam [ 02/Jan/12 ]
  • What is the impact on the customer of the bug?
    User will not be able to save any property tables.
  • What is the cost/risk of fixing the bug?
    2 hours. Test and ensure the object type is a Map.
  • Is there an impact on documentation or message strings?
    No.
  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
    Test to ensure that password is still masked when logged in server.log. Also verify that page with Property table can be saved properly.
  • Which is the targeted build of 3.1.2 for this fix?
    3.1.2_b17

Index: src/main/java/org/glassfish/admingui/common/util/RestUtil.java
===================================================================
— src/main/java/org/glassfish/admingui/common/util/RestUtil.java (revision 51836)
+++ src/main/java/org/glassfish/admingui/common/util/RestUtil.java (working copy)
@@ -220,6 +220,9 @@

private static Map maskOffPassword(Map<String, Object> attrs){
Map masked = new HashMap();
+ if (attrs == null)

{ + return masked; + }

for(String key : attrs.keySet()){
if (pswdAttrList.contains(key.toLowerCase())){
@@ -307,7 +310,10 @@
// Parse the response
String message = "";
ExitCode exitCode = ExitCode.FAILURE;

  • Map maskedAttr = maskOffPassword((Map<String, Object>)attrs);
    + Object maskedAttr = attrs;
    + if ((attrs != null) && (attrs instanceof Map)) { + maskedAttr = maskOffPassword((Map<String, Object>)attrs); + }

    if (response != null) {
    try {
    int status = response.getResponseCode();

Comment by Anissa Lam [ 03/Jan/12 ]

28) svn commit
Sending common/src/main/java/org/glassfish/admingui/common/util/RestUtil.java
Transmitting file data .
Committed revision 51859.

Comment by Anissa Lam [ 20/Jan/12 ]

Also fixed in the trunk.

Revisions:
----------
52218
Modified Paths:
---------------
trunk/main/appserver/admingui/common/src/main/java/org/glassfish/admingui/common/util/RestUtil.java





[GLASSFISH-18086] incorrect manifest classpath in javaee.jar Created: 25/Dec/11  Updated: 20/Dec/16  Resolved: 10/Oct/12

Status: Resolved
Project: glassfish
Component/s: packaging
Affects Version/s: 4.0_dev
Fix Version/s: 4.0_dev

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

Tags: 3_1_x-exclude

 Description   

Can't find javax.servlet classes while using javaee.jar, so this bug must be caused by the maven artifact id change of api jars. Pl. fix all the affected classpath.



 Comments   
Comment by Snjezana Sevo-Zenzerovic [ 10/Oct/12 ]

This has been fixed back in February, resolving the issue.





Need to port the Nodes support to 4.0 (GLASSFISH-17961)

[GLASSFISH-17965] port help from 3.1.2 to 4.0 relates to Nodes Created: 09/Dec/11  Updated: 20/Dec/16

Status: Open
Project: glassfish
Component/s: docs
Affects Version/s: 4.0_dev
Fix Version/s: future release

Type: Sub-task Priority: Major
Reporter: Anissa Lam Assignee: Mike Fitch
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1_x-exclude, ee7ri_cleanup_deferred

 Description   

refer to main task






[GLASSFISH-17964] Following nodes commands needs to be exposed as REST endpoint Created: 09/Dec/11  Updated: 20/Dec/16  Resolved: 16/Dec/11

Status: Resolved
Project: glassfish
Component/s: admin
Affects Version/s: 4.0_dev
Fix Version/s: 4.0

Type: Improvement Priority: Major
Reporter: Anissa Lam Assignee: Yamini K B
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
blocks GLASSFISH-17961 Need to port the Nodes support to 4.0 Open
Tags: 3_1_x-exclude

 Description   

The commands related to nodes need to be exposed as REST endpoint, especially the following as the console needs to use it.

create-node-ssh
ping-node-ssh
update-node-ssh



 Comments   
Comment by Yamini K B [ 16/Dec/11 ]

Fix version r51620: Added REST endpoint for create-node-ssh. ping/update-node-ssh already have the endpoints declared.





[GLASSFISH-17963] setup-ssh needs to be converted to remote command Created: 09/Dec/11  Updated: 20/Dec/16  Resolved: 11/Dec/11

Status: Closed
Project: glassfish
Component/s: admin
Affects Version/s: 4.0_dev
Fix Version/s: 4.0

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

Issue Links:
Dependency
blocks GLASSFISH-17961 Need to port the Nodes support to 4.0 Open
Tags: 3_1_x-exclude

 Description   

setup-ssh is still a local command in 4.0
Console needs this to be changed to remote command, like in 3.1.2



 Comments   
Comment by Yamini K B [ 11/Dec/11 ]

Closing as duplicate of GLASSFISH-17524





[GLASSFISH-17962] Expose all DCOM nodes command as REST endpoint Created: 09/Dec/11  Updated: 20/Dec/16  Resolved: 20/Dec/11

Status: Resolved
Project: glassfish
Component/s: distributed management
Affects Version/s: 4.0_dev
Fix Version/s: 4.0

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

Issue Links:
Dependency
blocks GLASSFISH-17961 Need to port the Nodes support to 4.0 Open
Tags: 3_1_x-exclude

 Description   

All the DCOM nodes commands need to be exposed through REST so admin console can call it.
As of now, GUI only supports DCOM in 3.1.2 branch, and will port the changes to 4.0 once this is available.

You can do http://localhost:4848/management/domain/nodes.json and see the list of endpoints exposed. Note that the DCOM nodes command is not there.



 Comments   
Comment by Anissa Lam [ 13/Dec/11 ]

The DCOM nodes commands thats needed by the console include:

create-node-dcom
delete-node-dcom
update-node-dcom
ping-node-dcom
validate-dcom

Comment by Byron Nevins [ 20/Dec/11 ]

Done.
Reviewed by Jason Lee

d:\gf\trunk\main\nucleus\cluster\admin>svn commit
Sending admin\src\main\java\com\sun\enterprise\v3\admin\cluster\DeleteNodeRemoteCommand.java
Sending admin\src\main\java\com\sun\enterprise\v3\admin\cluster\DeleteNodeSshCommand.java
Sending admin\src\main\java\com\sun\enterprise\v3\admin\cluster\NodeUtils.java
Sending admin\src\main\java\com\sun\enterprise\v3\admin\cluster\ValidateDcom.java
Sending admin\src\main\java\com\sun\enterprise\v3\admin\cluster\dcom\CreateNodeDcom.java
Sending admin\src\main\java\com\sun\enterprise\v3\admin\cluster\dcom\DeleteNodeDcom.java
Sending admin\src\main\java\com\sun\enterprise\v3\admin\cluster\dcom\PingNodeDcomCommand.java
Sending admin\src\main\java\com\sun\enterprise\v3\admin\cluster\dcom\UpdateNodeDcomCommand.java
Transmitting file data ........
Committed revision 51660.





[GLASSFISH-17848] Unable to use IIOP listener from local instances deployed into a local cluster Created: 30/Nov/11  Updated: 20/Dec/16  Resolved: 04/Mar/13

Status: Resolved
Project: glassfish
Component/s: orb
Affects Version/s: 4.0_dev
Fix Version/s: 4.0_dev

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

Glassfish Opne Source Edition 3.1.1 (build 12)
Mac OS X Snow Leopard (Java build 1.6.0_29-b11-402-10M3527) , Windows 7 (Java 1.6_05)


Tags: 3_1_x-exclude

 Description   

Hi,

for dev and testing purpose i've tried to use a local cluster with 2 local instances.

My setup is :

bash$> asadmin

Entering asadmin then :

> create-domain test-cluster
> start-domain test-cluster
> copy-config default-config cluster-config
> create-cluster --config cluster-config cluster-dev
> create-node-config node1
> create-node-config node2
> create-local-instance --node node1 --cluster cluster-dev cluster-inst1
> create-local-instance --node node2 --cluster cluster-dev cluster-inst2
> start-cluster cluster-dev
> create-jms-resource --restype javax.jms.QueueConnectionFactory --target cluster-dev QCF
> ping-connection-pool QCF
>

The QCF is just there to get a thing to lookup through JNDI (i've also tried with Custom JNDI resource like String).

The cluster starts gracefully.
Every local instance has HTTP, JMX, ... ports opened but not IIOP ports.
I can use the JMX connection for every cluster instance , HTTP etc ... (but IIOP).

Then i built a standard Java client (not using ACC).

I'm unable to lookup any kind of resource through JNDI and InitialContext : i get a timeout and "could not connect" error on every cluster instance port.

If i deploy the QCF resource on main server and try to get it through JNDI (3700 port), it works perfectly.

If i create two separate domains and set two IIOP ports, i can get two running IIOP ports, it works perfectly.

But it seems that it's impossible (on mac os x and windows 7, not tried on Linux) to have a cluster on a single domain with two local instances and two working IIOP ports (as i said HTTP, JMX, works perfectly).

Thanks.



 Comments   
Comment by Harshad Vilekar [ 09/Dec/11 ]

This doesn't look like orb issue.

Try this:
create-jms-resource --restype javax.jms.QueueConnectionFactory QCF

Then, use admin to edit QCF - remove target "server", and add target "cluster-dev".

Then, Simple java client is able to do the lookup, using a command, like:
java -cp $S1AS_HOME/lib/javaee.jar:$S1AS_HOME/lib/appserv-rt.jar:build/jmsclient -Dorg.omg.CORBA.ORBInitialPort=23700 JMSClient

Reducing the priority, and changing category to jms - to review if this is a jms issue.

Comment by David Zhao [ 31/Mar/12 ]

I can reproduce it against GF trunk branch (4.0) by following the steps as description above:

> create-domain test-cluster
> start-domain test-cluster
> copy-config default-config cluster-config
> create-cluster --config cluster-config cluster-dev
> create-node-config node1
> create-node-config node2
> create-local-instance --node node1 --cluster cluster-dev cluster-inst1
> create-local-instance --node node2 --cluster cluster-dev cluster-inst2
> start-cluster cluster-dev
> create-jms-resource --restype javax.jms.QueueConnectionFactory --target cluster-dev QCF
> ping-connection-pool QCF

after ping-connection-pool, the ports 23700 is not ready and can not be seen by the command "netstat -an |grep 23700", which means the IIOP listener may be not started up at that time.

by tracing the svn log, I found the checkin may affect,

Revision:
48403
Time:
07/28/2011 11:49 PM
Author:
oleksiys
Path:
main/nucleus/core/kernel/src/main/java/com/sun/enterprise/v3/services/impl/GrizzlyService.java (trunk)
Message:
+ implement task #17114 http://java.net/jira/browse/GLASSFISH-17114 "moving lazy listeners out of GF kernel"

Forward this back to ORB team for confirmation.

Comment by Harshad Vilekar [ 12/Feb/13 ]

Reassigning to grizzly-kernel to evaluate revision 48403.

Above steps work OK on 3.1.x but not on 4.0.

After starting the cluster, deploying remote ejb on the cluster also fails with 4.0, works OK with 3.1.x

:
> start-cluster cluster-dev
> list-clusters
cluster-dev running
Command list-clusters executed successfully.
> deploy --target cluster-dev Sfulejb.jar
Application deployed with name Sfulejb.
Command deploy failed.

Comment by oleksiys [ 18/Feb/13 ]

It's not a Grizzly issue.
IIOP listener is getting initialized by Grizzly only when this listener is in lazy mode (lazy-init parameter is set to true)

      <iiop-service>
        <iiop-listener port="3700" id="orb-listener-1" address="0.0.0.0" *lazy-init="true"*></iiop-listener>
........

If lazy-init parameter is not set - ORB is becoming responsible to startup the listener.
As you can see the default domain.xml/iiop-listener has lazy-init parameter set to true, but one in the node does not. That's why this listener is not getting started by Grizzly. See the OrbConnectorStartup.java line 171

Comment by Harshad Vilekar [ 26/Feb/13 ]

Works OK with 4.0-b77. IIOP listeners on the clustered instances are started "after" the app is deployed on the cluster.

After the last step, try:

$ asadmin deploy --target cluster-dev Sfulejb.jar
Application deployed with name Sfulejb.
Command deploy executed successfully.
$ netstat -an
tcp6 0 0 :::23700 :::* LISTEN
tcp6 0 0 :::3700 :::* LISTEN
tcp6 0 0 :::23701 :::* LISTEN

oschmitt, Please confirm if this works for you.





[GLASSFISH-17805] HTTP LB is broken in GUI, HTTP 500 error when a health checker and lb config is deleted in CLI and accessed in Console Created: 23/Nov/11  Updated: 20/Dec/16

Status: Open
Project: glassfish
Component/s: admin_gui
Affects Version/s: 3.1.1_dev
Fix Version/s: future release

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

Issue Links:
Dependency
depends on GLASSFISH-17673 REST endpoint gives response as FAILURE Resolved
Tags: 3_1_x-exclude

 Description   

Steps to reproduce

1) Login Glassfish and create a new load balancer with a cluster target.
2) In CLI delete health checker of the lb cluster target using delete-http-health-checker
3) Click Edit health checker of the cluster target of LB in admin console.

Issue --> HTTP 500 error comes up.

Steps:

1) Login glassfish in admin console and create a new http load balancer
2) In CLI delete the LB config using delete-http-lb-config
3) In admin console click Http Load Balancers Tab in left pane.

Issue --> HTTP 500 error throws



 Comments   
Comment by Anissa Lam [ 23/Nov/11 ]

Add 3_1_x-exclude tag since this issue has been fixed in 3.1.2 branch as GLASSFISH-17770

Comment by srinik76 [ 16/Dec/11 ]

In trunk HTTB LB is broken because of rest point failures

Comment by Anissa Lam [ 11/Feb/13 ]

retarget to 4.0.1. Not required for RI release.





[GLASSFISH-17803] [Regression] Conflict of ORB ports not detected in GF 4.0 Created: 23/Nov/11  Updated: 19/Sep/14  Resolved: 29/May/13

Status: Closed
Project: glassfish
Component/s: hk2
Affects Version/s: 4.0
Fix Version/s: 4.1

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

System is running GF 4.0 build 10 full distribution. System is running OEL6, JDK1.6.0_29.


Attachments: Text File server.log     Text File server.log     File stateful-simple.ear    
Issue Links:
Duplicate
is duplicated by GLASSFISH-17892 [Regression] Conflict of instance por... Resolved
Tags: 3_1_x-exclude, 3x_regression

 Description   

The following test case is part of the AdminCLI SQE test suite. The scenario is the creation of two domains with the same ORB port. A simple ear app is deployed on both domains and the test case expects, one domain to work, but not the second. In GF 3.1.x, this negative scenario works as expected. In GF 4.0 it does not. This is an incosistent functional behavior. The test case name is "TESTNAME=start_domain_port_conflict_orb".

Please note that the same port number is used for the ORB. The exact commands executed are:

machine$ asadmin create-domain --domaindir $TEST_HOME/domains --adminport 10000 --user admin1
--passwordfile $HOME/template/t_passwd1.txt --domainproperties orb.listener.port=57569 testdomain

machine$ asadmin create-domain --domaindir $TEST_HOME/domains --adminport 11000 --user admin1
--passwordfile $HOME/template/t_passwd1.txt --domainproperties orb.listener.port=57569 testdomain2

machine$ asadmin start-domain testdomain
Waiting for testdomain to start ....
Successfully started the domain : testdomain
machine$ asadmin --user admin1 --passwordfile $HOME/template/t_passwd1.txt
--port 10000 deploy $HOME/apps/stateful-simple.ear
Application deployed with name stateful-simple.
Command deploy executed successfully.
machine$ asadmin stop-domain testdomain

machine$ asadmin start-domain testdomain2
Waiting for testdomain2 to start ....
Successfully started the domain : testdomain2
machine$ asadmin --port 11000 --user admin1 --passwordfile $HOME/template/t_passwd1.txt
deploy $HOME/apps/stateful-simple.ear
Application deployed with name stateful-simple.
Command deploy executed successfully.

machine$ asadmin start-domain testdomain

The expectation is for the start-domain to fail. The test case looks for a failure message as noted in COM_MSG="Command start-domain failed", but what is returned by the server is:
Waiting for testdomain to start .......
Successfully started the domain : testdomain

As a result the test case fails. In GF 3.1.x, this scenario works as expected. Below is the output from GF 3.1.1 FCS build.

Error starting domain testdomain.
The server exited prematurely with exit code 0. Before it died, it produced the following output:
Launching GlassFish on Felix platform
Nov 22, 2011 4:21:06 PM com.sun.enterprise.server.logging.LogManagerService postConstruct
SEVERE|oracle-glassfish3.1.1|grizzly|_ThreadID=11;_ThreadName=Grizzly-kernel-thread(1);|doSelect IOException
java.net.BindException: No free port within range:
39654=com.sun.enterprise.v3.services.impl.ServiceInitializerHandler@fab5b1
at com.sun.grizzly.TCPSelectorHandler.initSelector(TCPSelectorHandler.java:432)
at com.sun.grizzly.TCPSelectorHandler.preSelect(TCPSelectorHandler.java:378)
at com.sun.grizzly.SelectorHandlerRunner.doSelect(SelectorHandlerRunner.java:188)
at com.sun.grizzly.SelectorHandlerRunner.run(SelectorHandlerRunner.java:132)
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

javax.enterprise.resource.corba.org.glassfish.enterprise.iiop.impl|_ThreadID=10;_ThreadName=main;|
java.net.BindException: Address already in use

Reference:
appserver-sqe/pe/admincli/tonga/testbase/serverlifecycle/start_domain/start_domain_port_03.cfg
appserver-sqe/pe/admincli/tonga/testbase/serverlifecycle/start_domain/start_domain_port_03terse.cfg



 Comments   
Comment by Tom Mueller [ 23/Nov/11 ]

Doesn't apply to 3.1.x.

Comment by Tom Mueller [ 19/Dec/11 ]

This is working in 4.0 (the trunk).

Since the HTTP listener ports are not set differently between the domains, the 2nd domain fails to start because port 8080 (and 8081) are already in use. The test case specified in the description doesn't really test that duplicate IIOP ports are detected because the failure to find to port 8080 (and 8081) is detected first.

Here is the output in the log file from 4.0 when the server fails to start:

[#|2011-12-19T13:19:10.518-0800|INFO|44.0|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=10;_ThreadName=main;|WEB0671: Loading application sampleEA#sampleEA-war.war at [sampleEA-war]|#]

[#|2011-12-19T13:19:10.519-0800|INFO|44.0|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=10;_ThreadName=main;|CORE10010: Loading application sampleEA done in 2,805 ms|#]

[#|2011-12-19T13:19:10.520-0800|INFO|44.0|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=10;_ThreadName=main;|GlassFish Server Open Source Edition 4.0 (re-continuous) startup time : Felix (1,402ms), startup services(3,644ms), total(5,046ms)|#]

[#|2011-12-19T13:19:10.521-0800|SEVERE|44.0|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=10;_ThreadName=main;|Shutting down v3 due to startup exception : Address already in use|#]

[#|2011-12-19T13:19:10.535-0800|INFO|44.0|javax.enterprise.system.tools.admin.com.sun.enterprise.v3.admin|_ThreadID=11;_ThreadName=Thread-10;|Server shutdown initiated|#]

[#|2011-12-19T13:19:10.539-0800|INFO|44.0|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=11;_ThreadName=Thread-10;|Already stopped, so just returning|#]

Command start-domain failed.

Comment by Alex Pineda [ 01/May/12 ]

Modified the test case to specify http instance port to be unique for newly created domains, but the expected failure does not happen. To reiterate the test case, the steps are:

  • create testdomain (unique admin and http ports) with orb.listener.port=60868
  • create testdomain2 (unique admin and http ports) with orb.listener.port=60868
  • start-domain testdomain
  • deploy stateful-simple.ear on testdomain
  • stop-domain testdomain
  • start-domain testdomain2
  • deploy stateful-simple.ear on testdomain2
  • start-domain testdomain

The expectation of the test case is for the start-domain command to fail. In fact, the test case looks for string "Command start-domain failed", but the start-domain is successful. It seems there should br some functional conflict if two domains are assigned the same ORB port, deployed an application and are running. This is shat appears to be test case scenario that QA is trying to test. Since this appears to be an issue, I'm re-opening the bug.

Comment by Alex Pineda [ 02/May/12 ]

Unable to reproduce the problem manually, thus, I've added a 2 second delay between the deployment on testdomain2 and the starting of testdomain.

Comment by Tom Mueller [ 03/May/12 ]

Can you please attach the stateful-simple.ear file to the issue?

Comment by Tom Mueller [ 03/May/12 ]

Reassigning to the orb component. I tried recreating the problem with another EAR file, and the behavior that I saw is the following:

1. When testdomain is started by itself, the process listens on port 60868.
2. When testdomain2 is started by itself, the process listens on port 60868.
3. When both domains are started at the same time, the 2nd domain starts successfully and there is no log message saying that the 2nd process wasn't able to bind to port 60868.

Comment by Alex Pineda [ 03/May/12 ]

I will take back my previous statement. I'm able to reproduce the problem consistently and I have created a Hudson to show the issue. Please let me know if you want direct access to the Hudson job to understand the issue better. In addition, I'll attached the stateful-simple.ear file as requested.

Comment by Alex Pineda [ 03/May/12 ]

Attaching sample app used in this test case.

Comment by Harshad Vilekar [ 03/May/12 ]

ORB init is failing with expected "Java.net.BindException: Address already in use".

For some reason, this is not aborting domain startup.

=======================
[#|2012-05-02T14:09:37.055-0700|INFO|44.0|javax.enterprise.system.core.transaction.com.sun.jts.CosTransactions|_ThreadID=10;_ThreadName=Thread-2;|JTS5014: Recoverable JTS instance, serverId = [57569]|#]

[#|2012-05-02T14:09:37.246-0700|SEVERE|44.0|javax.enterprise.resource.corba.org.glassfish.enterprise.iiop.impl|_ThreadID=10;_ThreadName=Thread-2;|iiop.createsocket_exception|#]

[#|2012-05-02T14:09:37.246-0700|SEVERE|44.0|javax.enterprise.resource.corba.org.glassfish.enterprise.iiop.impl|_ThreadID=10;_ThreadName=Thread-2;|java.net.BindException: Address already in use
at java.net.PlainSocketImpl.socketBind(Native Method)
at java.net.PlainSocketImpl.bind(PlainSocketImpl.java:383)
at java.net.ServerSocket.bind(ServerSocket.java:328)
at java.net.ServerSocket.<init>(ServerSocket.java:194)
at javax.net.ssl.SSLServerSocket.<init>(SSLServerSocket.java:106)
at com.sun.net.ssl.internal.ssl.SSLServerSocketImpl.<init>(SSLServerSocketImpl.java:108)
at com.sun.net.ssl.internal.ssl.SSLServerSocketFactoryImpl.createServerSocket(SSLServerSocketFactoryImpl.java:72)
:
:
org.glassfish.enterprise.iiop.impl.GlassFishORBFactoryImpl.createORB(GlassFishORBFactoryImpl.java:93)
at org.glassfish.enterprise.iiop.api.GlassFishORBHelper.getORB(GlassFishORBHelper.java:163)
at org.glassfish.enterprise.iiop.api.GlassFishORBHelper.getProtocolManager(GlassFishORBHelper.java:231)
at com.sun.ejb.containers.BaseContainer.initializeProtocolManager(BaseContainer.java:810)
at com.sun.ejb.containers.BaseContainer.<init>(BaseContainer.java:555)
at com.sun.ejb.containers.StatefulSessionContainer.<init>(StatefulSessionContainer.java:209)
at com.sun.ejb.containers.StatefulSessionContainer.<init>(StatefulSessionContainer.java:204)
at com.sun.ejb.containers.builder.StatefulContainerBuilder.createContainer(StatefulContainerBuilder.java:156)
at com.sun.ejb.containers.builder.BaseContainerBuilder.buildContainer(BaseContainerBuilder.java:96)
at com.sun.ejb.containers.ContainerFactoryImpl.createContainer(ContainerFactoryImpl.java:102)
at org.glassfish.ejb.startup.EjbApplication.loadContainers(EjbApplication.java:228)
at org.glassfish.ejb.startup.EjbDeployer.load(EjbDeployer.java:294)
at org.glassfish.ejb.startup.EjbDeployer.load(EjbDeployer.java:103)
at org.glassfish.internal.data.ModuleInfo.load(ModuleInfo.java:186)
at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:264)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:482)
at com.sun.enterprise.v3.server.ApplicationLoaderService.processApplication(ApplicationLoaderService.java:390)
at com.sun.enterprise.v3.server.ApplicationLoaderService.postConstruct(ApplicationLoaderService.java:226)
at com.sun.hk2.component.AbstractCreatorImpl.inject(AbstractCreatorImpl.java:132)
at com.sun.hk2.component.ConstructorCreator.initialize(ConstructorCreator.java:117)
at com.sun.hk2.component.AbstractCreatorImpl.get(AbstractCreatorImpl.java:84)
at com.sun.hk2.component.SingletonInhabitant.get(SingletonInhabitant.java:67)
at com.sun.hk2.component.EventPublishingInhabitant.get(EventPublishingInhabitant.java:141)
at com.sun.hk2.component.AbstractInhabitantImpl.get(AbstractInhabitantImpl.java:135)
at com.sun.enterprise.v3.server.StartupRunLevelBridge.activate(StartupRunLevelBridge.java:93)
at com.sun.enterprise.v3.server.RunLevelBridge.postConstruct(RunLevelBridge.java:110)
at com.sun.enterprise.v3.server.StartupRunLevelBridge.postConstruct(StartupRunLevelBridge.java:65)
at com.sun.hk2.component.AbstractCreatorImpl.inject(AbstractCreatorImpl.java:132)
at com.sun.hk2.component.ConstructorCreator.initialize(ConstructorCreator.java:117)
at com.sun.hk2.component.AbstractCreatorImpl.get(AbstractCreatorImpl.java:84)
at com.sun.hk2.component.SingletonInhabitant.get(SingletonInhabitant.java:67)
at com.sun.hk2.component.EventPublishingInhabitant.get(EventPublishingInhabitant.java:141)
at com.sun.hk2.component.EventPublishingInhabitant.get(EventPublishingInhabitant.java:141)
at com.sun.hk2.component.RunLevelInhabitant.get(RunLevelInhabitant.java:110)
at com.sun.hk2.component.AbstractInhabitantImpl.get(AbstractInhabitantImpl.java:135)
at com.sun.enterprise.v3.server.AppServerStartup$StartupInhabitantActivator.activate(AppServerStartup.java:526)
at org.jvnet.hk2.component.internal.runlevel.DefaultRunLevelService$Worker.activateRunLevel(DefaultRunLevelService.java:1106)
at org.jvnet.hk2.component.internal.runlevel.DefaultRunLevelService$Worker.upActiveRecorder(DefaultRunLevelService.java:1060)
at org.jvnet.hk2.component.internal.runlevel.DefaultRunLevelService$Worker.run(DefaultRunLevelService.java:1026)
at org.jvnet.hk2.component.internal.runlevel.DefaultRunLevelService$SyncProceedToOp.proceedTo(DefaultRunLevelService.java:1256)
at org.jvnet.hk2.component.internal.runlevel.DefaultRunLevelService.proceedTo(DefaultRunLevelService.java:797)
at org.jvnet.hk2.component.internal.runlevel.DefaultRunLevelService.proceedTo(DefaultRunLevelService.java:759)
at com.sun.enterprise.v3.server.AppServerStartup.proceedTo(AppServerStartup.java:360)
at com.sun.enterprise.v3.server.AppServerStartup.run(AppServerStartup.java:254)
at com.sun.enterprise.v3.server.AppServerStartup.doStart(AppServerStartup.java:172)
at com.sun.enterprise.v3.server.AppServerStartup.start(AppServerStartup.java:163)
at com.sun.enterprise.glassfish.bootstrap.GlassFishImpl.start(GlassFishImpl.java:79)
at com.sun.enterprise.glassfish.bootstrap.GlassFishDecorator.start(GlassFishDecorator.java:63)
at com.sun.enterprise.glassfish.bootstrap.osgi.OSGiGlassFishImpl.start(OSGiGlassFishImpl.java:71)

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.enterprise.glassfish.bootstrap.GlassFishMain.main(GlassFishMain.java:97)
at com.sun.enterprise.glassfish.bootstrap.ASMain.main(ASMain.java:55)

#]
=================
Comment by Harshad Vilekar [ 03/May/12 ]

server log attached.

Comment by Alex Pineda [ 04/May/12 ]

Just to be clear. The test case looks at the start-domain status and message to determine if the ORB conflict is detected. So, from a QA perspective this is still an issue and needs to be resolved.

Comment by Harshad Vilekar [ 09/May/12 ]

In 3.1.2, core.kernel module, com.sun.enterprise.v3.server.AppServerStarup.run() is aborted, and shutdown() is initiated if bind to ORB port fails. That is not working is 4.0.

Comment by Harshad Vilekar [ 14/May/12 ]

Reassigning to review if this is can be handled by GlassFish Startup.

Comment by tbeerbower [ 22/May/12 ]

If I follow the steps to reproduce from above ...

create testdomain (unique admin and http ports) with orb.listener.port=60868
create testdomain2 (unique admin and http ports) with orb.listener.port=60868

start-domain testdomain
deploy stateful-simple.ear on testdomain
stop-domain testdomain

start-domain testdomain2
deploy stateful-simple.ear on testdomain2

start-domain testdomain

... the last start-domain succeeds even though there is an orb listener port conflict. The log contains the following ...

java.net.BindException: Address already in use

... as noted in the stack trace above.

Comment by tbeerbower [ 22/May/12 ]

In the above stack trace, the ORB creation is driven by the AppServerStartup and run level service code ...

at com.sun.enterprise.v3.server.StartupRunLevelBridge.activate(StartupRunLevelBridge.java:93)
at com.sun.enterprise.v3.server.RunLevelBridge.postConstruct(RunLevelBridge.java:110)
at com.sun.enterprise.v3.server.StartupRunLevelBridge.postConstruct(StartupRunLevelBridge.java:65)
at com.sun.hk2.component.AbstractCreatorImpl.inject(AbstractCreatorImpl.java:132)
at com.sun.hk2.component.ConstructorCreator.initialize(ConstructorCreator.java:117)
at com.sun.hk2.component.AbstractCreatorImpl.get(AbstractCreatorImpl.java:84)
at com.sun.hk2.component.SingletonInhabitant.get(SingletonInhabitant.java:67)
at com.sun.hk2.component.EventPublishingInhabitant.get(EventPublishingInhabitant.java:141)
at com.sun.hk2.component.EventPublishingInhabitant.get(EventPublishingInhabitant.java:141)
at com.sun.hk2.component.RunLevelInhabitant.get(RunLevelInhabitant.java:110)
at com.sun.hk2.component.AbstractInhabitantImpl.get(AbstractInhabitantImpl.java:135)
at com.sun.enterprise.v3.server.AppServerStartup$StartupInhabitantActivator.activate(AppServerStartup.java:526)
at org.jvnet.hk2.component.internal.runlevel.DefaultRunLevelService$Worker.activateRunLevel(DefaultRunLevelService.java:1106)
at org.jvnet.hk2.component.internal.runlevel.DefaultRunLevelService$Worker.upActiveRecorder(DefaultRunLevelService.java:1060)
at org.jvnet.hk2.component.internal.runlevel.DefaultRunLevelService$Worker.run(DefaultRunLevelService.java:1026)
at org.jvnet.hk2.component.internal.runlevel.DefaultRunLevelService$SyncProceedToOp.proceedTo(DefaultRunLevelService.java:1256)
at org.jvnet.hk2.component.internal.runlevel.DefaultRunLevelService.proceedTo(DefaultRunLevelService.java:797)
at org.jvnet.hk2.component.internal.runlevel.DefaultRunLevelService.proceedTo(DefaultRunLevelService.java:759)
at com.sun.enterprise.v3.server.AppServerStartup.proceedTo(AppServerStartup.java:360)
at com.sun.enterprise.v3.server.AppServerStartup.run(AppServerStartup.java:254)
at com.sun.enterprise.v3.server.AppServerStartup.doStart(AppServerStartup.java:172)
at com.sun.enterprise.v3.server.AppServerStartup.start(AppServerStartup.java:163)

The AppServerStartup code has changed in GF 4.0 and is suspected of causing the diff. The difference being that in GF 3.1.2 the port conflict supposedly causes a failure to start the server (not just a stack trace in the log).

Comment by tbeerbower [ 22/May/12 ]

The full stack trace from the log shows the following ...

at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:482)

The code in ApplicationLifecycle.deploy does the following ...

try {
    ...
    appInfo.load(context, tracker);
    ...
} catch(Throwable loadException) {
    ...
    tracker.actOn(logger);
    return null;
}

It looks like the exception is being logged and then discarded. In this case the exception is not being thrown out to the AppServerStartupCode. If the exception was rethrown then it should be handled in the AppServerStartupCode (line 536) and cause a server shutdown ...

} catch(RuntimeException e) {
    logger.log(level, e.getMessage(), e);
    ...
    events.send(new Event(EventTypes.SERVER_SHUTDOWN), false);
    forceShutdown();
    return;
}

The scenario where an exception is thrown out to the AppServerStartup code should be covered by the unit test AppServerStatupTest.testRunLevelServicesWithStartupException().

Comment by tbeerbower [ 22/May/12 ]

Following the above steps to reproduce using GF 3.1, I get the following...

./asadmin start-domain mydomain2
Waiting for mydomain2 to start ........
Successfully started the domain : mydomain2
domain  Location: /Users/tbeerbower/gf-old/glassfish3/glassfish/domains/mydomain2
Log File: /Users/tbeerbower/gf-old/glassfish3/glassfish/domains/mydomain2/logs/server.log
Admin Port: 5001
Command start-domain executed successfully.

... I can start the second domain and the log contains the following stack trace ...

java.net.BindException: Address already in use
	at java.net.PlainSocketImpl.socketBind(Native Method)
	at java.net.PlainSocketImpl.bind(PlainSocketImpl.java:383)
	at java.net.ServerSocket.bind(ServerSocket.java:328)
	at java.net.ServerSocket.<init>(ServerSocket.java:194)
	at javax.net.ssl.SSLServerSocket.<init>(SSLServerSocket.java:106)
	at com.sun.net.ssl.internal.ssl.SSLServerSocketImpl.<init>(SSLServerSocketImpl.java:108)
	at com.sun.net.ssl.internal.ssl.SSLServerSocketFactoryImpl.createServerSocket(SSLServerSocketFactoryImpl.java:72)
	at org.glassfish.enterprise.iiop.impl.IIOPSSLSocketFactory.createSSLServerSocket(IIOPSSLSocketFactory.java:402)
	at org.glassfish.enterprise.iiop.impl.IIOPSSLSocketFactory.createServerSocket(IIOPSSLSocketFactory.java:281)
	at com.sun.corba.ee.impl.transport.SocketOrChannelAcceptorImpl.initialize(SocketOrChannelAcceptorImpl.java:91)
	at com.sun.corba.ee.impl.transport.CorbaTransportManagerImpl.getAcceptors(CorbaTransportManagerImpl.java:243)
	at com.sun.corba.ee.impl.transport.CorbaTransportManagerImpl.addToIORTemplate(CorbaTransportManagerImpl.java:262)
	at com.sun.corba.ee.spi.oa.ObjectAdapterBase.initializeTemplate(ObjectAdapterBase.java:103)
	at com.sun.corba.ee.impl.oa.poa.POAImpl.initialize(POAImpl.java:553)
	at com.sun.corba.ee.impl.oa.poa.POAImpl.makeRootPOA(POAImpl.java:352)
	at com.sun.corba.ee.impl.oa.poa.POAFactory$1.evaluate(POAFactory.java:286)
	at com.sun.corba.ee.impl.orbutil.closure.Future.evaluate(Future.java:61)
	at com.sun.corba.ee.impl.resolver.LocalResolverImpl.resolve(LocalResolverImpl.java:55)
	at com.sun.corba.ee.impl.resolver.CompositeResolverImpl.resolve(CompositeResolverImpl.java:59)
	at com.sun.corba.ee.impl.orb.ORBImpl.resolve_initial_references(ORBImpl.java:1266)
	at com.sun.corba.ee.impl.naming.cosnaming.TransientNameService.initialize(TransientNameService.java:124)
	at com.sun.corba.ee.impl.naming.cosnaming.TransientNameService.<init>(TransientNameService.java:93)
	at org.glassfish.enterprise.iiop.impl.PEORBConfigurator.configure(PEORBConfigurator.java:161)
	at com.sun.corba.ee.impl.orb.ORBConfiguratorImpl.runUserConfigurators(ORBConfiguratorImpl.java:185)
	at com.sun.corba.ee.impl.orb.ORBConfiguratorImpl.configure(ORBConfiguratorImpl.java:170)
	at com.sun.corba.ee.impl.orb.ORBImpl.postInit(ORBImpl.java:625)
	at com.sun.corba.ee.impl.orb.ORBImpl.set_parameters(ORBImpl.java:704)
	at com.sun.corba.ee.impl.orb.ORBImpl.setParameters(ORBImpl.java:691)
	at com.sun.corba.ee.spi.osgi.ORBFactory.initialize(ORBFactory.java:107)
	at org.glassfish.enterprise.iiop.impl.GlassFishORBManager.initORB(GlassFishORBManager.java:581)
	at org.glassfish.enterprise.iiop.impl.GlassFishORBManager.getORB(GlassFishORBManager.java:263)
	at org.glassfish.enterprise.iiop.impl.GlassFishORBFactoryImpl.createORB(GlassFishORBFactoryImpl.java:93)
	at org.glassfish.enterprise.iiop.api.GlassFishORBHelper.getORB(GlassFishORBHelper.java:120)
	at org.glassfish.enterprise.iiop.api.GlassFishORBHelper.getProtocolManager(GlassFishORBHelper.java:187)
	at com.sun.ejb.containers.BaseContainer.initializeProtocolManager(BaseContainer.java:818)
	at com.sun.ejb.containers.BaseContainer.<init>(BaseContainer.java:566)
	at com.sun.ejb.containers.StatefulSessionContainer.<init>(StatefulSessionContainer.java:206)
	at com.sun.ejb.containers.StatefulSessionContainer.<init>(StatefulSessionContainer.java:201)
	at com.sun.ejb.containers.builder.StatefulContainerBuilder.createContainer(StatefulContainerBuilder.java:152)
	at com.sun.ejb.containers.builder.BaseContainerBuilder.buildContainer(BaseContainerBuilder.java:96)
	at com.sun.ejb.containers.ContainerFactoryImpl.createContainer(ContainerFactoryImpl.java:110)
	at org.glassfish.ejb.startup.EjbApplication.loadContainers(EjbApplication.java:234)
	at org.glassfish.ejb.startup.EjbDeployer.load(EjbDeployer.java:290)
	at org.glassfish.ejb.startup.EjbDeployer.load(EjbDeployer.java:101)
	at org.glassfish.internal.data.ModuleInfo.load(ModuleInfo.java:186)
	at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:249)
	at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:460)
	at com.sun.enterprise.v3.server.ApplicationLoaderService.processApplication(ApplicationLoaderService.java:364)
	at com.sun.enterprise.v3.server.ApplicationLoaderService.postConstruct(ApplicationLoaderService.java:208)
	at com.sun.hk2.component.AbstractCreatorImpl.inject(AbstractCreatorImpl.java:131)
	at com.sun.hk2.component.ConstructorCreator.initialize(ConstructorCreator.java:91)
	at com.sun.hk2.component.AbstractCreatorImpl.get(AbstractCreatorImpl.java:82)
	at com.sun.hk2.component.SingletonInhabitant.get(SingletonInhabitant.java:67)
	at com.sun.hk2.component.EventPublishingInhabitant.get(EventPublishingInhabitant.java:139)
	at com.sun.hk2.component.AbstractInhabitantImpl.get(AbstractInhabitantImpl.java:76)
	at com.sun.enterprise.v3.server.AppServerStartup.run(AppServerStartup.java:243)
	at com.sun.enterprise.v3.server.AppServerStartup.start(AppServerStartup.java:135)
	at com.sun.enterprise.glassfish.bootstrap.GlassFishImpl.start(GlassFishImpl.java:79)
	at com.sun.enterprise.glassfish.bootstrap.GlassFishMain$Launcher.launch(GlassFishMain.java:117)
	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.enterprise.glassfish.bootstrap.GlassFishMain.main(GlassFishMain.java:97)
	at com.sun.enterprise.glassfish.bootstrap.ASMain.main(ASMain.java:55)

This looks nearly identical to the GF 4.0 case, but with the older AppServerStartup code.

So, we can reproduce what is believed to be bad behavior in 4.0. However, it looks like the identical behavior exists in 3.1, given the above reproduction steps. At least I am unable to reproduce the failure case in 3.1.

Could you please provide the exact steps to reproduce the failure in 3.1 along with associated logs?

Comment by tbeerbower [ 22/May/12 ]

Reopen if you can provide exact failure steps in GF 3.1. See above comments...

Comment by Alex Pineda [ 22/May/12 ]

As noted in the bug, the test was done on GF 3.1.1 not GF 3.1. As mentioned, this test case comes from the GF v2.x test suite and according to the test case, the expected behavior (start-domain failure when port conflict is detected). In our test source workspace, it references a customer bug with it. I will try to dig it out and posted on this report.

I believe this is a real issue that needs to be resolved.

Comment by tbeerbower [ 23/May/12 ]

I think that I can reproduce in 3.1. Reopening.

Comment by tbeerbower [ 23/May/12 ]

svn commit -m "GLASSFISH-17803 : Use RunLevel annotation with GrizzlyService"
Sending nucleus/core/kernel/src/main/java/com/sun/enterprise/v3/server/RunLevelBridge.java
Sending nucleus/core/kernel/src/main/java/com/sun/enterprise/v3/services/impl/GrizzlyService.java
Transmitting file data ..
Committed revision 54221.

I now see the server abort in GF 4.0 for the scenario described above ...

[#|2012-05-23T12:15:29.741-0400|SEVERE|44.0|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=10;_ThreadName=main;|Shutting down v3 due to startup exception : Address already in use|#]

The issue was that the Grizzly service was already activated by the time the StartupRunLevelBridge picked it up for activation. Because of this, the Grizzly service Futures (the service is a FutureProvider) were not added to the list to be monitored for failure. The code in the StartupRunLevelBridge has been changed to not check the activation state of the service when adding to the Future list. Also, the Grizzly service has now been updated to use the newer RunLevel annotation.

Note that one of the stack traces above was a bit of a red herring in that the exception thrown from GlassFishORBFactoryImpl during the ApplicationLoaderService.postConstruct() is not thrown out to the AppServerStartup code. In other words, this exception is not the trigger for the server to abort (same in 3.1.x and 4.0). The BindException that actually causes the server abort occurs during the Grizzy initialization. You can see that in the stack trace in the original description.

Comment by Alex Pineda [ 22/May/13 ]

Re-opening the bug with the intent of understanding what the exact fix was and what is the expected behavior in this test scenario from the server on GF 4.0. From reviewing this issue again, I don't see any change. Both domains are started (testdomain1 and testdomain2) without any issues. The expectation is that one will fail because of the ORB port conflict.

My objective is to resolve the test scenario in our QA AdminCLI test suite (cleanup work for GF 4.0). Please advise.

Comment by Harshad Vilekar [ 28/May/13 ]

The issue could be duplicated with GF 4.0-b089. The ORB initialization is failing due to port conflict, resulting in following error:

================================
[2013-05-28T11:35:28.429-0700] [glassfish 4.0] [SEVERE] [] [javax.enterprise.system.tools.deployment.common] [tid: _ThreadID=1 _ThreadName=main] [timeMillis: 1369766128429] [levelValue: 1000] [[
Exception while invoking class org.glassfish.ejb.startup.EjbDeployer load method
java.lang.RuntimeException: EJB Container initialization error
================================

This should abort the domain startup. See attached GF4.0 server.log for full stack trace.

Comment by Alex Pineda [ 29/May/13 ]

Harshad,

Thanks for updating the bug with your analysis, however, in reviewing the test case further, there is one extra step that I did not document in the test scenario that is causing the Test case to continue to fail. The additional part is having the default domain (domain1) up and running. When you do so, the expected failure does not happen. So, the question is, should I file a new issue or can we use this JIRA report to resolve the second part of the problem. Please let me know.

The steps to reproduce the problem are:

start-domain domain1 (default domain)

create testdomain (unique admin and http ports) with orb.listener.port=60868
create testdomain2 (unique admin and http ports) with orb.listener.port=60868

start-domain testdomain
deploy stateful-simple.ear on testdomain
stop-domain testdomain

start-domain testdomain2
deploy stateful-simple.ear on testdomain2

start-domain testdomain

... the last start-domain succeeds even though there is an orb listener port conflict.

Comment by mtaube [ 29/May/13 ]

The RunLevelService was not being invoked to bring down the server completely because the kernel server state was "starting" in this scenario. This was an unexpected state for AppServerStartup.stop()

I am testing a fix for this now.

Comment by mtaube [ 29/May/13 ]

Sending nucleus/core/kernel/src/main/java/com/sun/enterprise/v3/server/AppServerStartup.java
Transmitting file data .
Committed revision 62124.





[GLASSFISH-17798] get-health always say instance as not started Created: 22/Nov/11  Updated: 17/Oct/12

Status: In Progress
Project: glassfish
Component/s: group_management_service
Affects Version/s: 4.0
Fix Version/s: not determined

Type: Bug Priority: Minor
Reporter: Anissa Lam Assignee: Joe Fialli
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File clustersetup.sh     Text File server.log    
Tags: 3_1_2-exclude, 3_1_x-exclude

 Description   

This is on latest workspace,rev# 51051 on the 3.1.2 branch.
Tried several times, and always reproducible.
I created a cluster (clusterABC) with 4 instances, all using the localhost-domain1 node.
I can start the instances, but get-health always says they are not started.

Here is the copy&paste of my commands. I will attach server.log as well.

~/Awork/V3/3.1.2/3.1.2 1)  cd $AS3/bin
~/Awork/V3/3.1.2/3.1.2/dist-gf/glassfish/bin 2)  asadmin list-clusters
clusterABC not running
Command list-clusters executed successfully.
~/Awork/V3/3.1.2/3.1.2/dist-gf/glassfish/bin 3)  asadmin list-instances --long
NAME   HOST       PORT   PID  CLUSTER     STATE         
ABC-4  localhost  24848  --   clusterABC   not running  
ABC-3  localhost  24849  --   clusterABC   not running  
ABC-2  localhost  24850  --   clusterABC   not running  
ABC-1  localhost  24851  --   clusterABC   not running  
Command list-instances executed successfully.
~/Awork/V3/3.1.2/3.1.2/dist-gf/glassfish/bin 4)  asadmin start-instance ABC-1
Waiting for ABC-1 to start ..........
Successfully started the instance: ABC-1
instance Location: /Users/anilam/Awork/V3/3.1.2/3.1.2/dist-gf/glassfish/nodes/localhost-domain1/ABC-1
Log File: /Users/anilam/Awork/V3/3.1.2/3.1.2/dist-gf/glassfish/nodes/localhost-domain1/ABC-1/logs/server.log
Admin Port: 24851
Command start-local-instance executed successfully.
The instance, ABC-1, was started on host localhost
Command start-instance executed successfully.
~/Awork/V3/3.1.2/3.1.2/dist-gf/glassfish/bin 5)  asadmin start-instance ABC-2
Waiting for ABC-2 to start ..........
Successfully started the instance: ABC-2
instance Location: /Users/anilam/Awork/V3/3.1.2/3.1.2/dist-gf/glassfish/nodes/localhost-domain1/ABC-2
Log File: /Users/anilam/Awork/V3/3.1.2/3.1.2/dist-gf/glassfish/nodes/localhost-domain1/ABC-2/logs/server.log
Admin Port: 24850
Command start-local-instance executed successfully.
The instance, ABC-2, was started on host localhost
Command start-instance executed successfully.
~/Awork/V3/3.1.2/3.1.2/dist-gf/glassfish/bin 6)  asadmin list-instances --long
NAME   HOST       PORT   PID    CLUSTER     STATE         
ABC-4  localhost  24848  --     clusterABC   not running  
ABC-3  localhost  24849  --     clusterABC   not running  
ABC-2  localhost  24850  12517  clusterABC   running      
ABC-1  localhost  24851  12507  clusterABC   running      
Command list-instances executed successfully.
~/Awork/V3/3.1.2/3.1.2/dist-gf/glassfish/bin 7)  asadmin get-health clusterABC
ABC-1 not started
ABC-2 not started
ABC-3 not started
ABC-4 not started
Command get-health executed successfully.
~/Awork/V3/3.1.2/3.1.2/dist-gf/glassfish/bin 8)  asadmin start-cluster clusterABC
Command start-cluster executed successfully.
~/Awork/V3/3.1.2/3.1.2/dist-gf/glassfish/bin 9)  asadmin list-instances --long
NAME   HOST       PORT   PID    CLUSTER     STATE     
ABC-4  localhost  24848  12540  clusterABC   running  
ABC-3  localhost  24849  12541  clusterABC   running  
ABC-2  localhost  24850  12517  clusterABC   running  
ABC-1  localhost  24851  12507  clusterABC   running  
Command list-instances executed successfully.
~/Awork/V3/3.1.2/3.1.2/dist-gf/glassfish/bin 10)  asadmin get-health clusterABC
ABC-1 not started
ABC-2 not started
ABC-3 not started
ABC-4 not started
Command get-health executed successfully.
~/Awork/V3/3.1.2/3.1.2/dist-gf/glassfish/bin 11)  



 Comments   
Comment by Joe Fialli [ 22/Nov/11 ]

Unable to recreate reported issue with build 51075.
Attached a shell script called clustersetup.sh to standardize HOW the cluster and instances are created.
(must configure GF_HOME to point to a valid 3.1.2 installation)
My results of running the script are counter to reported issue.

$GF_HOME/bin/asadmin list-instances
instance01 running
instance02 running
instance03 running
Command list-instances executed successfully.
$GF_HOME/bin/asadmin get-health myCluster
instance01 started since Tue Nov 22 11:38:25 EST 2011
instance02 started since Tue Nov 22 11:38:25 EST 2011
instance03 started since Tue Nov 22 11:38:25 EST 2011
Command get-health executed successfully.

***********
Analysis:

there is no evidence that multicast is working from the submitted DAS server.log.
Is it possible that this was attempted while connected with VPN?
VPN will interfer with multicast working.

Please submit output of "ifconfig -a" and also follow HA admin guide instructions for validating
that multicast is working properly for your system.
http://download.oracle.com/docs/cd/E18930_01/html/821-2426/gjfnl.html#gklhd
The instructions assume two different machines but you can check if multicast is working between processes
on same machine by opening two terminal windows on same machine.
Note that multicast does not work when one is connected via VPN.
(it disables multicast as a protection mechanism).

Specifying bindinterfaceaddress of 127.0.0.1 allows one to work with clusters on one machine while
connected via VPN.

Comment by Joe Fialli [ 22/Nov/11 ]

The attached shell script creates a domain, a cluster and 3 instances for the cluster and starts
up the cluster. Validates that cluster started using "asadmin get-health" and "asadmin list-instances".
User must edit script variable GF_HOME to point to a valid GF v3.1.2 installation.

Comment by Anissa Lam [ 22/Nov/11 ]

Yes, I saw the issue when I was working from home and using VPN.
So, is this a known issue that get-health will NOT provide a correct state of the instance when it is on VPN ?

I think that since there is no way to fix the code if one is on VPN, then even though you cannot gives the exact state like 'FAILED', 'STOPPED' and the timestamp, it should at least report the correct status. It shouldn't just say 'not started', instead, it should at least report the instance is running or not. Can the code detect that multicast is not working and code it like list-instances to find out the status of the instance and return that ?

Console is displaying whatever get-health returns, and telling user that the instance is 'not running' when it actually is doesn't sound acceptable. Especially when the Status from list-instance is displayed on the same screen, that says 'RUNNING', and the next line says 'not running' giving conflicting information.

Comment by Joe Fialli [ 22/Nov/11 ]

get-health reports the status of GMS.
GMS in multicast mode (the default) only works when multicast is working.

Please see bobby's blog, you are misinterpreting results.
asadmin get-health only works correctly when GMS is working correctly.
(asadmin get-health is a GMS client and it can only work as well as GMS subsystem is working)

http://blogs.oracle.com/bobby/entry/validating_multicast_transport_where_d

Comment by Anissa Lam [ 22/Nov/11 ]

As a user, when i am seeing the following:

~/Awork/V3/3.1.2/3.1.2/dist-gf/glassfish/bin 8) asadmin start-cluster clusterABC
Command start-cluster executed successfully.

~/Awork/V3/3.1.2/3.1.2/dist-gf/glassfish/bin 9) asadmin list-instances --long
NAME HOST PORT PID CLUSTER STATE
ABC-4 localhost 24848 12540 clusterABC running
ABC-3 localhost 24849 12541 clusterABC running
ABC-2 localhost 24850 12517 clusterABC running
ABC-1 localhost 24851 12507 clusterABC running
Command list-instances executed successfully.

~/Awork/V3/3.1.2/3.1.2/dist-gf/glassfish/bin 10) asadmin get-health clusterABC
ABC-1 not started
ABC-2 not started
ABC-3 not started
ABC-4 not started
Command get-health executed successfully.
~/Awork/V3/3.1.2/3.1.2/dist-gf/glassfish/bin 11)

I can only say that 'get-health' is giving me the wrong information. The server instance is obviously running, why 'get-health' says it is not started ?
If there is any issue that prevents "get-health" to give the correct information, then it should return an error informing the user what the problem is. Giving the wrong info and says executed successfully is not acceptable.

Comment by Joe Fialli [ 22/Nov/11 ]

reduced priority from critical to minor.

My recommendation is to change "not started" to "unknown".
The asadmin get-health command tells the state of the cluster
from the GMS point of view. If multicast is not working properly
and cluster is not forming properly, that is what the command should relay.

Comment by Bobby Bissett [ 23/Nov/11 ]

"I can only say that 'get-health' is giving me the wrong information. The server instance is obviously running, why 'get-health' says it is not started ?
If there is any issue that prevents "get-health" to give the correct information, then it should return an error informing the user what the problem is. Giving the wrong info and says executed successfully is not acceptable."

That's the way it is. The whole POINT of get-health is to tell you the state of the cluster. If the instances are up, but can't communicate, then there's a serious problem and the only way the user will know it is by running get-health and seeing the wrong result. This is all documented.

In the admin console, you can say whatever you want. The enum name is "NOT_RUNNING" but you can say whatever you want.

Comment by Bobby Bissett [ 23/Nov/11 ]

When the admin console gets the output from the get health command, it's getting the enum name from this enumeration:

// NOT_RUNNING means there is no time information associated
public static enum STATE {
NOT_RUNNING (strings.getString("state.not_running")),
RUNNING (strings.getString("state.running")),
REJOINED (strings.getString("state.rejoined")),
FAILURE (strings.getString("state.failure")),
SHUTDOWN (strings.getString("state.shutdown"));

private final String stringVal;

STATE(String stringVal)

{ this.stringVal = stringVal; }

@Override
public String toString()

{ return stringVal; }

}

There is no point in changing the name of the state in the enum, it's separate from the i18n'ed value that is presented to the user. So when the admin console sees that state, it can output anything you want. Are you using the LocalStrings.properties file in the gms-bootstrap module to get the actual text to use? If so, we can change that to say "not joined" instead. Otherwise, this issue doesn't really affect gms since you can use whatever text you want.

Just wanted to check to see if you're using our props file or your own for the text the user sees.

Comment by Anissa Lam [ 23/Nov/11 ]

I get it now.
I feel that it will be very nice if user can perform validate-multicast on the console.
Will it be possible to make validate-multicast a remote command so that console can call that ? Or its too much to ask for 3.1.2 ?
thanks Joe and Bobby for helping me to understand this.

Comment by Bobby Bissett [ 23/Nov/11 ]

Nope, validate-multicast has to be a local command only because it needs to be run on each machine that will host an instance. In fact, it's better if the server is not up when the command is run. If you're bored, you can watch a screen cast with the details

http://www.youtube.com/watch?v=sJTDao9OpWA

There is an RFE for a tool that's more centralized, which I think fits what you're looking for. It won't happen for 3.1.2, but it's possible it could happen later: GLASSFISH-13056

Comment by Joe Fialli [ 23/Nov/11 ]

Too big a change for 3.1.2 release to change the output of asadmin get-health that
is documented in asadmin get-health --help documentation.

Recommend considering fixing this in a major release.

We could release note in 3.1.2 that "asadmin get-health" "not started" status applies
to both the instance not running or the instance is running but the current configuration
is not allowing GMS communications. (could be multicast is not enabled properly or
non-multicast GMS mode is misconfigured.)

Comment by Joe Fialli [ 23/Nov/11 ]

Exclude changing asadmin get-health output in a minor release.





[GLASSFISH-17712] rename com.sun.enterprise.hk2 and org.jvnet.hk2.osgiadapter to org.glassfish.hk2 and org.glassfish.hk2.osgiadapter respectively Created: 11/Nov/11  Updated: 12/Oct/12

Status: Open
Project: glassfish
Component/s: OSGi
Affects Version/s: 4.0
Fix Version/s: None

Type: Task Priority: Major
Reporter: Sanjeeb Sahoo Assignee: Sanjeeb Sahoo
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1_x-exclude

 Description   

Streamline package names and constant names in hk2/osgi-adapter module to follow new convention of org.glassfish.hk2.



 Comments   
Comment by TangYong [ 12/Oct/12 ]

Hi sahoo,

The task should be considered combined with GLASSFISH-18928, because once in the future, moving osgi-adapter out of HK2, the task will be also dong at the same time.





[GLASSFISH-17683] admin-cli.jar classpath references JAR files which are not in nucleus Created: 09/Nov/11  Updated: 20/Dec/16  Resolved: 01/Feb/13

Status: Resolved
Project: glassfish
Component/s: command_line_interface
Affects Version/s: 4.0
Fix Version/s: 4.0_dev

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

Tags: 3_1_x-exclude, nucleus-cleanup

 Description   

The Class-Path manifest entry for the admin-cli.jar file (nucleus/admin/cli module) references the following JAR files that are not part of nucleus.

backup.jar
cli-optional.jar

Suggested fix:
backup.jar doesn't contain any local commands, so it can just be removed.

cli-optional.jar is defined in the appserver. It could be placed into the lib/asadmin directory so that it would be picked up by asadmin. However, it
has "backup.jar" in its classpath so if cli-optional.jar is moved, then backup.jar won't be found.

Nucleus needs a better way of allowing the asadmin command to be extended.

Note: lib/asadmin really should be called lib/nadmin now.



 Comments   
Comment by Tom Mueller [ 20/Jan/12 ]

One way to fix this is to make the following changes:

1. remove cli-optional.jar and backup.jar from the classpath for admin-cli.jar
2. change the packaging to put cli-optional.jar in lib/asadmin
3. modify the classpath for cli-optional.jar so that it references backup.jar and all other JAR files using ../modules/jarname.jar

Comment by Tom Mueller [ 01/Feb/13 ]

Fixed on the trunk in revision 59033.





[GLASSFISH-17649] create-domain is failing to start the embedded DAS for domain customization Created: 07/Nov/11  Updated: 19/Dec/11  Resolved: 19/Dec/11

Status: Resolved
Project: glassfish
Component/s: admin
Affects Version/s: 4.0
Fix Version/s: 4.0

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

Tags: 3_1_x-exclude

 Description   

create-domain is producing the following error message:

java.lang.NoClassDefFoundError: org/glassfish/grizzly/config/dom/NetworkConfig

The stack trace for this is:

at java.lang.Class.getDeclaredMethods0(Native Method)
at java.lang.Class.privateGetDeclaredMethods(Class.java:2427)
at java.lang.Class.privateGetPublicMethods(Class.java:2547)
at java.lang.Class.getMethods(Class.java:1410)
at sun.misc.ProxyGenerator.generateClassFile(ProxyGenerator.java:409)
at sun.misc.ProxyGenerator.generateProxyClass(ProxyGenerator.java:306)
at java.lang.reflect.Proxy.getProxyClass(Proxy.java:501)
at java.lang.reflect.Proxy.newProxyInstance(Proxy.java:581)
at org.glassfish.config.support.TranslatedConfigView.getProxy(TranslatedConfigView.java:136)
at org.glassfish.config.support.GlassFishConfigBean.createProxy(GlassFishConfigBean.java:98)
at org.jvnet.hk2.config.Dom.createProxy(Dom.java:866)
at org.jvnet.hk2.config.ConfigModel$CollectionNode$1.get(ConfigModel.java:430)
at org.jvnet.hk2.config.ConfigBean$2.get(ConfigBean.java:203)
at java.util.AbstractList$Itr.next(AbstractList.java:345)
at com.sun.enterprise.config.serverbeans.Server$Duck.getConfig(Server.java:407)
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.jvnet.hk2.config.Dom.invokeDuckMethod(Dom.java:948)
at org.jvnet.hk2.config.Dom.invoke(Dom.java:901)
at org.glassfish.config.support.TranslatedConfigView.invoke(TranslatedConfigView.java:119)
at $Proxy16.getConfig(Unknown Source)
at org.glassfish.config.support.DomainXml.decorate(DomainXml.java:149)
at org.glassfish.config.support.DomainXml.run(DomainXml.java:140)
at com.sun.enterprise.module.common_impl.AbstractModulesRegistryImpl.populateConfig(AbstractModulesRegistryImpl.java:190)
at com.sun.enterprise.module.common_impl.AbstractModulesRegistryImpl.createHabitat(AbstractModulesRegistryImpl.java:169)
at com.sun.enterprise.module.bootstrap.Main.createHabitat(Main.java:425)
at com.sun.enterprise.glassfish.bootstrap.StaticGlassFishRuntime.newGlassFish(StaticGlassFishRuntime.java:104)
at org.glassfish.internal.embedded.Server.<init>(Server.java:272)
at org.glassfish.internal.embedded.Server.<init>(Server.java:66)
at org.glassfish.internal.embedded.Server$Builder.build(Server.java:176)
at com.sun.enterprise.admin.servermgmt.cli.CreateDomainCommand.modifyInitialDomainXml(CreateDomainCommand.java:782)
at com.sun.enterprise.admin.servermgmt.cli.CreateDomainCommand.createTheDomain(CreateDomainCommand.java:565)
at com.sun.enterprise.admin.servermgmt.cli.CreateDomainCommand.executeCommand(CreateDomainCommand.java:359)
at com.sun.enterprise.admin.cli.CLICommand.execute(CLICommand.java:264)
at com.sun.enterprise.admin.cli.AsadminMain.executeCommand(AsadminMain.java:299)
at com.sun.enterprise.admin.cli.AsadminMain.main(AsadminMain.java:238)
Caused by: java.lang.ClassNotFoundException: org.glassfish.grizzly.config.dom.NetworkConfig
at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
... 38 more



 Comments   
Comment by Tom Mueller [ 19/Dec/11 ]

The root cause of this problem is that the various Grizzly JAR files, including grizzly-config.jar (which contains NetworkConfig.class) are being merged into a nucleus-grizzly-all.jar file within nucleus. Since that JAR file isn't in the classpath for any other JAR file, it is not being picked up by the create-domain command running within asadmin.

Comment by Tom Mueller [ 19/Dec/11 ]

Fixed on the trunk in revision 51652.





[GLASSFISH-17643] nucleus main process is called "ASMain" in glassfish.jar Created: 04/Nov/11  Updated: 21/Sep/15

Status: Open
Project: glassfish
Component/s: other
Affects Version/s: 4.0
Fix Version/s: 4.1.1

Type: Bug Priority: Major
Reporter: Tom Mueller Assignee: martin.mares
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1_x-exclude, nucleus-cleanup

 Description   

The class that contains the main method for nucleus is called "ASMain". It is contained in a JAR file called "glassfish.jar" When nucleus is used for other Java servers, these may not be appropriate names. The class name is visible to the user in the following cases:

  • in "jps" output
  • in the "jconsole" opening screen (here the whole package is visible: com.sun.enterprise.glassfish.bootstrap.ASMain

Possible solutions:

1. Leave this as it is.

2. Rename the class to something more generic. "Main" is probably too generic because other Java programs, most specifically, NetBeans, uses Main. "GFMain" might be appropriate since the Java package name contains "glassfish".

3. Rename the class to be something specific to nucleus, such as NucleusMain. Rename the JAR file to nucleus.jar. Expect that nucleus-derived products provide their own JAR file that contains main, i.e., a class that extends NucleusMain. This would also require modifying the launcher so that it could identify the right JAR file to launch when starting the server.

Related to this issue is other meta data that is associated with the main program. For example, the jvisualvm program displays the GlassFish logo and "GlassFish" next to the name of the process. This is based on the full class name showing up in the following file in jvisualvm: visualvm/application/src/com/sun/tools/visualvm/application/type/MainClassApplicationTypeFactory.java. If the name of the class is changed, then jvisualvm must be updated too.



 Comments   
Comment by Tom Mueller [ 24/Jan/12 ]

A suggested fix from Bill Shannon:
I would consider changing it so that glassfish.jar just has a main class
and a class path entry entry referring to nucleus.jar.

Comment by Bill Shannon [ 24/Jan/12 ]

To expand on the previous comment...

My suggestion was to put the nucleus content in a nucleus.jar with a main
class named Main.

(You could call it NucleusMain if you really wanted to, but almost no one will
be running the Nucleus alone.)

Put the app server content in a glassfish.jar with a main class named ASMain
that subclasses Main. Add a Main-Class attribute referring to ASMain. Add a
Class-Path attribute referring to nucleus.jar.

Other servers built on nucleus should do something similar.

Comment by Tom Mueller [ 07/Jan/13 ]

To implement the design idea in the previous comment, it would be necessary to change the start-domain and start-local-instance logic so that it would run the correct JAR file.

Currently, the GFDomainLauncher and GFInstanceLauncher classes have the "glassfish.jar" and the full classname of ASMain hardcoded. If glassfish.jar is defined by appserver (not nucleus), then there should be no references to glassfish.jar anywhere within the nucleus code. Same with the "ASMain" class.

The only other reference to the ASMain class in nucleus is in the bootstrap ReJar.java file.

It should be possible to do this refactoring - just noting it here so as to not miss this.

Comment by Tom Mueller [ 26/Mar/13 ]

Deferring to 4.0.1.





[GLASSFISH-17642] nucleus quicklook tests are missing Created: 04/Nov/11  Updated: 12/Jan/12  Resolved: 12/Jan/12

Status: Resolved
Project: glassfish
Component/s: test
Affects Version/s: 4.0
Fix Version/s: 4.0

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

Tags: 3_1_x-exclude, nucleus-cleanup

 Description   

There currently are no quicklook tests for nucleus. This means that when nucleus is built by hudson, there isn't any verification that the nucleus build that is produced actually works at all.

This issue is for introducing quicklook tests into nucleus and making sure that they are run by the continuous build.



 Comments   
Comment by Tom Mueller [ 12/Jan/12 ]

Fixed on the trunk in revision 52071.

Added a main/nucleus/tests/quicklook directory with 14 tests.

To run all tests on the staged distribution:
mvn test
To run one test class:
mvn -Dtest=MiscCommandsTest,NucleusStartStopTest test
To run with a particular build:
mvn -Dnucleus.home=...somedirectory/nucleus





[GLASSFISH-17641] nucleus creates .asadminpass, .asadmintruststore files which contain "asadmin" name (not nadmin) Created: 04/Nov/11  Updated: 20/Dec/16  Resolved: 10/May/12

Status: Resolved
Project: glassfish
Component/s: admin
Affects Version/s: 4.0
Fix Version/s: 4.0_dev

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

Tags: 3_1_x-exclude, nucleus-cleanup

 Description   

The asadmin command has been renamed to "nadmin" in nucleus, with the asadmin command now being provided by the app server. However, the "login" and "create-domain" subcommands still create a file called ".asadminpass" for storing obfuscated passwords. Also, the truststore file is called ".asadmintruststore"

Should these files be renamed? If so, this issue is for renaming them.

At the heart of this issue is whether the files should be shared between various products and product versions that use nucleus. As it stands now, these files are shared since they only have one name and they are written to the user's home directory. There are several options:

1. Leave it as it is. Files still have "asadmin" embedded in them, even though other products may use another name for the command.

2. Rename the files to have some neutral name, such as "nadmin" or "admin". The files would still be shared among all commands and all versions.

3. Move the files to live in some install-specific directory, such as the "config" directory of the installation. The problem with this is that the user that is running nadmin may not have write access to the config directory of the installation.

4. Have the script pass in an argument to admin-cli.jar Use that name to create the files. Thus when using "asadmin" the filename would stay the same. But "nadmin" or other named scripts would use different files.



 Comments   
Comment by Tom Mueller [ 10/May/12 ]

This has been fixed on the glassfish trunk.

The files are now stored in a directory $HOME/.gfclient. (option #2)





[GLASSFISH-17581] scale down issue in ConferencePlanner Native Created: 03/Nov/11  Updated: 13/Mar/12  Resolved: 03/Nov/11

Status: Resolved
Project: glassfish
Component/s: elasticity
Affects Version/s: 4.0
Fix Version/s: 4.0

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

glassfish on mac 10.5.8
firefox 6 on windows 7


Attachments: JPEG File ScaleDownNative-b08-ConferencePlanner-2-3-2.jpg     JPEG File ScaleDownNative-b08-ConferencePlanner.jpg     JPEG File ScaleDownNative-b08-SimpleSessionDemo.jpg    
Tags: 3_1_x-exclude

 Description   

glassfish-4.0-b08.zip
Since scale down works on one app, but not on another, I
record issue to see if it can be resolved with alert setting.



 Comments   
Comment by sherryshen [ 03/Nov/11 ]

Scale-Down works in SimpleSessionDemo Native.

For SimpleSessionDemo, the scale up/down works on Native
with build 08 + 3 jar files from demo instruction
http://glassfish.java.net/javaone2011/elasticitydemo.html
i.e.elastic-engine.jar elastic-api.jar and elastic-config.jar

1) setup and deploy app and see 3 instances
$ asadmin start-domain
$ asadmin enable paas-console
$ asadmin create-ims-config-native
$ asadmin create-template --indexes ServiceType=LB,VirtualizationType=Native LBNative
$ asadmin deploy --availabilityenabled=true SimpleSessionDemo.war
--see 3 cluster instances.

2) scale up from 3 to 4 instances.
$ asadmin create-alert --service SimpleSessionDemo --expression 'countTrue [avg(jvm_memory.heap.used)*100/jvm_memory.maxMemory > 50] /cluster_instance_size.currentSize * 100> 66' alert1
$ asadmin add-alert-action --service SimpleSessionDemo --actionref scale-up-action --state alarm-state alert1
$ asadmin increase-memory cloud-1
$ asadmin increase-memory cloud-2
--see 4 cluster instances. scaled up.

3)scale down from 4 to 3 instance
$ asadmin create-alert --service SimpleSessionDemo --expression 'countTrue[avg(jvm_memory.heap.used)*100/jvm_memory.maxMemory < 20] /cluster_instance_size.currentSize * 100 > 66' alert2
$ asadmin add-alert-action --service SimpleSessionDemo --actionref scale-down-action --state alarm-state alert2
$ asadmin decrease-memory cloud-2
--see 3 cluster instances. scaled down.
http://java.net/jira/secure/attachment/47933/ScaleDownNative-b08-SimpleSessionDemo.jpg

Comment by sherryshen [ 03/Nov/11 ]

Scale-down doesn't work in ConferencePlanner Native.

For ConferencePlanner, the scale up works, and scale down doesn't work on build 08.
1) setup, deploy app and then setup alerts.
$ asadmin deploy --availabilityenabled=true ConferencePlanner.war
$ asadmin create-memory-alert --servicename ConferencePlanner --threshold 50 alert1
$ asadmin create-alert --service ConferencePlanner --expression "countTrue[avg(jvm_memory.heap.used)/jvm_memory.maxMemory*100>20]<1" alert2
$ asadmin add-alert-action --service ConferencePlanner --actionref scale-down-action --state alarm-state alert2
--see 2 cluster instances.

2) From app gui, click the "Load Increase" button, and
--see 2 to 4 instances from paas console. scaled up.
http://java.net/jira/secure/attachment/47928/windows7_firefox6_native_b08.jpg

3) From app gui, click the "Load Decrease" button, and
--see 4 instances at paas console for 1 hour. Not scaled down. ??
http://java.net/jira/secure/attachment/47934/ScaleDownNative-b08-ConferencePlanner.jpg
jvm memory is lower than that in 2).

Comment by carlavmott [ 03/Nov/11 ]

Did the instances show that they were using enough less memory after the load Decrease button was pushed? Try setting to 30 percent instead of 20. It may be that the numbers are just off by a bit.

Comment by sherryshen [ 03/Nov/11 ]

Used 30 percent instead of 20 as Carla suggested.
Increased to 3 instances instead of 4 so that total memory
usage is less.
Then, scale down works on ConferencePlanner in native mode and b08.
http://java.net/jira/secure/attachment/47948/ScaleDownNative-b08-ConferencePlanner-2-3-2.jpg
Thank Carla for guiding me to test scale up and down.





[GLASSFISH-17578] [Regression] Some asadmin commands don't work against GF4.0 Created: 02/Nov/11  Updated: 24/Jun/13  Resolved: 07/Mar/13

Status: Resolved
Project: glassfish
Component/s: security
Affects Version/s: 4.0
Fix Version/s: 4.0

Type: Bug Priority: Major
Reporter: sonialiu Assignee: Tim Quinn
Resolution: Works as designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to GLASSFISH-20364 BadRealmException: java.lang.ClassNot... Resolved
Tags: 3_1_x-exclude, 3x_regression, 40_regression, 4_0-release-notes, 4_0-release-notes-completed, 4_0-release-notes-drafted

 Description   

OS: linux
build: GF4.0

***File the bug for backward compatibility issue ************

The following asadmin commands passed against GF3.x but failed for GF4.0, and it caused SQE test failures.

set-assign-groups-realm:
[echo] Setting groups to a given auth realm realmperapp...
[exec] Deprecated syntax, instead use:
[exec] asadmin --user admin --passwordfile /export/hudson/workspace/sonia-gf4-security-linux/appserver-sqe/build-config/adminpassword.txt --echo --terse=false --host localhost --port 4848 set [options] ...
[exec] asadmin --host localhost --port 4848 --user admin --passwordfile /export/hudson/workspace/sonia-gf4-security-linux/appserver-sqe/build-config/adminpassword.txt --interactive=false --echo=true --terse=false set server-config.security-service.auth-realm.realmperapp.property.assign-groups=DefaultGroup1
[exec] Command set failed.
[exec] remote failure: No configuration found for server-config.security-service.auth-realm.realmperapp.property.assign-groups
[exec] Result: 1



 Comments   
Comment by Tim Quinn [ 07/Mar/13 ]

Hi, Sonia.

Can you confirm whether this is still a problem?

A similar set command for the default "file" auth-realm worked fine for me with the current 4.0 build.

I'm closing this as not reproducible for now. Please re-open it if you still see the problem.

Comment by sonialiu [ 07/Mar/13 ]

The issue still exists in the latest build (03/07/2013 nightly), see command output below:
[uadmin@bigapp-opteron-12 bin]# ./asadmin set server-config.security-service.auth-realm.realmperapp.property.assign-groups=DefaultGroup1
remote failure: No configuration found for server-config.security-service.auth-realm.realmperapp.property.assign-groups
Command set failed.

I have to reopen the bug. Thanks.

Comment by sonialiu [ 07/Mar/13 ]

I found that the following command doesn't work in the GF4 (worked for GF3.x) and it caused the failures. The root cause is that the class
com.sun.enterprise.security.auth.realm.jdbc.JDBCRealm is removed in the GF4.

create-auth-realm:
[echo] Creating auth realm realmperapp ...
[exec] Deprecated syntax, instead use:
[exec] asadmin --user admin --passwordfile /export/sonia/appserver-sqe/build-config/adminpassword.txt --echo --terse=false --host localhost --port 4848 create-auth-realm [options] ...
[exec] asadmin --host localhost --port 4848 --user admin --passwordfile /export/sonia/appserver-sqe/build-config/adminpassword.txt --interactive=false --echo=true --terse=false create-auth-realm --classname com.sun.enterprise.security.auth.realm.jdbc.JDBCRealm --property jaas-context=jdbcRealm:datasource-jndi=jdbc/s1qeDB:user-table=usertable:user-name-column=userid:password-column=password:group-table=grouptable:group-name-column=groupid:digest-algorithm=MD5 --target server realmperapp
[exec] remote failure: Creation of Authrealm realmperapp failed. com.sun.enterprise.security.auth.realm.BadRealmException: java.lang.ClassNotFoundException: com.sun.enterprise.security.auth.realm.jdbc.JDBCRealm not found by org.glassfish.main.security [85]
[exec] com.sun.enterprise.security.auth.realm.BadRealmException: java.lang.ClassNotFoundException: com.sun.enterprise.security.auth.realm.jdbc.JDBCRealm not found by org.glassfish.main.security [85]
[exec] Command create-auth-realm failed.

The steps to run SQE test:
1. Install GF4.0, start domain
2. Checkout SQE workspace cvs co appserver-sqe/bootstrap.xml
(CVSROOT: :pserver:<your cvs user name>@sunsw.us.oracle.com:/m/jws
cd appserver-sqe
ant -f bootstrap.xml co-security
3.set following env. variables
S1AS_HOME <GF install dir>, for example: /export/sonia/v4/glassfish3/glassfish
SPS_HOME <appserver-sqe>, for example: /export/sonia/appserver-sqe
ANT_HOME <ant location>, for example: /export/sonia/ant-1.7.1
JAVA_HOME <java location>, for example: /export/sonia/jdk1.7.0
4. cd <workspace dir>/appserver-sqe/, run "ant startDerby"
5. cd <workspace dir>/appserver-sqe/pe/security/assigngroup/, run "ant all"

Comment by Tim Quinn [ 07/Mar/13 ]

Thanks to Anissa for pointing out that the name of the realm class

com.sun.enterprise.security.auth.realm.jdbc.JDBCRealm

has changed to

com.sun.enterprise.security.ee.auth.realm.jdbc.JDBCRealm

(Note the ".ee" inserted in the middle).

This change occurred in July of 2011, which is consistent with the original open date of this issue of Nov. 2011.

Anissa correctly pointed out that this could be a compatibility issue affecting 3.1.x and 4.0.

Sonia, please change the test script so that it uses the new class name in the create-realm command. If there are other uses of this class in other tests, those should also be changed.

I will leave the issue open until you make that change and report that the test works as expected.

Comment by JeffTancill [ 07/Mar/13 ]

Same issue reported in http://java.net/jira/browse/GLASSFISH-17451 and http://java.net/jira/browse/GLASSFISH-18697
I've 'resolved' those two, we can track the passing of revised tests here. The compatibility aspect seems like it should be filed as a separate JIRA issue??

Comment by JeffTancill [ 07/Mar/13 ]

Same issue for the class com.sun.enterprise.security.auth.realm.jdbc.JDBCRealm

it got repackaged to:
com.sun.enterprise.security.ee.auth.realm.jdbc

Anyone why this was done??

Comment by sonialiu [ 07/Mar/13 ]

If I recalled correctly, I remember that we repackaged GF2.x package com.sun.enterprise.security.ee.auth.realm.jdbc to com.sun.enterprise.security.auth.realm.jdbc for GF3.x release,
why we changed it back to com.sun.enterprise.security.ee.auth.realm.jdbc for GF4?

Comment by Tim Quinn [ 07/Mar/13 ]

Here is the svn check-in comment Kumar entered with the change in July, 2011, if this helps explain it at all:

r48354 | kumarjayanti | 2011-07-27 02:36:55 -0500 (Wed, 27 Jul 2011) | 4 lines

Cleaning up security/core by moving EE specific classes to core-ee. Pre-Req for
integrating security/core into nucleus.
Ran QL

Comment by sonialiu [ 07/Mar/13 ]

After modifying SQE test to use the renamed package for GF4.0, the test passed.
---------------------------------------
create-auth-realm:
[echo] Creating auth realm realmperapp ...
[exec] Deprecated syntax, instead use:
[exec] asadmin --user admin --passwordfile /export/sonia/appserver-sqe/build-config/adminpassword.txt --echo --terse=false --host localhost --port 4848 create-auth-realm [options] ...
[exec] asadmin --host localhost --port 4848 --user admin --passwordfile /export/sonia/appserver-sqe/build-config/adminpassword.txt --interactive=false --echo=true --terse=false create-auth-realm --classname com.sun.enterprise.security.auth.realm.file.FileRealm --property file=/export/sonia/v4/glassfish4/glassfish/domains/domain1/config/keyfile:jaas-context=fileRealm --target server realmperapp
[exec] Command create-auth-realm executed successfully.

---------
set-assign-groups-realm:
[echo] Setting groups to a given auth realm realmperapp...
[exec] Deprecated syntax, instead use:
[exec] asadmin --user admin --passwordfile /export/sonia/appserver-sqe/build-config/adminpassword.txt --echo --terse=false --host localhost --port 4848 set [options] ...
[exec] asadmin --host localhost --port 4848 --user admin --passwordfile /export/sonia/appserver-sqe/build-config/adminpassword.txt --interactive=false --echo=true --terse=false set server-config.security-service.auth-realm.realmperapp.property.assign-groups=DefaultGroup1
[exec] server-config.security-service.auth-realm.realmperapp.property.assign-groups=DefaultGroup1
[exec] Command set executed successfully.

Comment by Tim Quinn [ 07/Mar/13 ]

I'm closing this. Mike has tagged it with the release notes tag.

Thanks for the retest, Sonia.

Comment by Gail Risdal [ 31/May/13 ]

Added the following to the release notes:

[Regression] Some asadmin commands don't work against GF4.0 (17578)

Description
In GlassFish Server 4.0 the realm class was renamed to com.sun.enterprise.security.ee.auth.realm.jdbc.JDBCRealm (note the .ee). The subcommands create-auth-realm and set-assign-groups-realm fail if the correct realm class name is not used.

Workaround
Use the correct realm class name when running the subcommands: com.sun.enterprise.security.ee.auth.realm.jdbc.JDBCRealm.





[GLASSFISH-17551] Cannot access paas console after enabling secure admin Created: 01/Nov/11  Updated: 19/Oct/12  Resolved: 19/Oct/12

Status: Closed
Project: glassfish
Component/s: admin_gui
Affects Version/s: 4.0
Fix Version/s: None

Type: Bug Priority: Major
Reporter: lidiam Assignee: Anissa Lam
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

promoted build b08, windows xp


Attachments: Text File server.log    
Tags: 3_1_x-exclude

 Description   

I cannot access paas console after enabling secure admin. Steps to reproduce:

1. I deployed ConferencePlanner via paas console on promoted build b08 - all working fine.
2. Enabled secure admin and restart domain.
3. Access pass console again at http://localhost:8080/paas-console/ - initial screen is displayed.
Click Login and the following error is displayed:

HTTP Status 500 - Internal Server Error

type Exception report

messageInternal Server Error

descriptionThe server encountered an internal error (Internal Server Error) that prevented it from fulfilling this request.

exception

javax.servlet.ServletException: REST Request 'http://localhost:4848/management/domain/applications/list-applications' failed with response code '302'.

root cause

java.lang.RuntimeException: REST Request 'http://localhost:4848/management/domain/applications/list-applications' failed with response code '302'.

root cause

java.lang.RuntimeException: REST Request 'http://localhost:4848/management/domain/applications/list-applications' failed with response code '302'.

note The full stack traces of the exception and its root causes are available in the GlassFish Server Open Source Edition 4.0 logs.

I'll attach server.log. In order to get paas console working again, disable secure admin.



 Comments   
Comment by Anissa Lam [ 03/Jan/12 ]

Paas console is for 4.0, the trunk.
Thus exclude from 3.x release.

Comment by Anissa Lam [ 19/Oct/12 ]

PaaS console will not be delivered for 4.0. Won't fix.





[GLASSFISH-17550] ClassCastException when create alert Created: 01/Nov/11  Updated: 07/Feb/13  Resolved: 07/Feb/13

Status: Closed
Project: glassfish
Component/s: elasticity
Affects Version/s: 4.0
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: mzh777 Assignee: Mahesh Kannan
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Oracle Linux 5.4


Tags: 3_1_x-exclude

 Description   

GF4 b08.

Steps to reproduce:
1. Deploy ConferencePlanner app.
2. Create the 1st alert for auto-scale up: asadmin create-memory-alert --servicename ConferencePlanner alert1
3. Click the "Increase Load" button, was able to see the auto-scale up.
4. Create the 2nd alert for auto-scale down:

  1. asadmin create-alert --service ConferencePlanner --expression "countTrue [avg(jvm_memory.heap.used)*100/jvm_memory.maxMemory < 20] /cluster_instance_size.currentSize * 100 > 66" alert2
  2. asadmin add-alert-action --service ConferencePlanner --actionref scale-down-action --state alarm-state alert2
    5. Got ClassCastException exception:
    [#|2011-11-01T00:20:44.333+0000|INFO|44.0|elasticity-logger|_ThreadID=13;_ThreadName=Thread-2;|SCHEDULED Alert[name=alert2; schedule=30s; expression=countTrue [avg(jvm_memory.heap.used)*100/jvm_memory.maxMemory < 20] /cluster_instance_size.currentSize * 100 > 66; will be executed every= 30|#]

[#|2011-11-01T00:21:14.344+0000|WARNING|44.0|elasticity-logger|_ThreadID=34;_ThreadName=Thread-2;|Exception during alert execution
java.lang.ClassCastException: org.glassfish.elasticity.engine.util.ClusterSizeMetricHolder cannot be cast to java.lang.Number
at org.glassfish.elasticity.expression.ElasticExpressionEvaluator.evaluate(ElasticExpressionEvaluator.java:143)
at org.glassfish.elasticity.expression.ElasticExpressionEvaluator.evaluate(ElasticExpressionEvaluator.java:137)
at org.glassfish.elasticity.expression.ElasticExpressionEvaluator.evaluate(ElasticExpressionEvaluator.java:50)
at org.glassfish.elasticity.engine.util.ExpressionBasedAlert.execute(ExpressionBasedAlert.java:91)
at org.glassfish.elasticity.engine.container.AlertContextImpl.run(AlertContextImpl.java:71)
...
6. # asadmin list-metric-gatherers
Enter the value for the service option> ConferencePlanner
session_count
processingtime
cluster_instance_size
jvm_memory
Command list-metric-gatherers executed successfully.

  1. asadmin describe-metric-attributes cluster_instance-size
    Enter the value for the service option> ConferencePlanner
    remote failure: java.lang.NullPointerException
    Command describe-metric-attributes failed.


 Comments   
Comment by Tom Mueller [ 07/Feb/13 ]

The elasticity code has been moved out of GlassFish, so closing this issue.





[GLASSFISH-17538] nucleus Resources config bean contains comments that are too Java EE/app server specific Created: 31/Oct/11  Updated: 18/Feb/13  Resolved: 18/Feb/13

Status: Closed
Project: glassfish
Component/s: configuration
Affects Version/s: 4.0
Fix Version/s: 4.0

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

Tags: 3_1_x-exclude, nucleus-cleanup

 Description   

The Resources config bean contains the following comment:

/**

  • J2EE Applications look up resources registered with the Application server,
  • using portable JNDI names.
    */

The "J2EE" should be removed and the "Application server" should just be server. Also, the javadocs for the getResources method contains references to application server specific classes. While it is ok to keep those reference, the text needs to be revised so that these are just examples of possible resources. The text should indicate that other types of resources can be defined too and that a Resource is a general JNDI addressable entity in the server.



 Comments   
Comment by Jagadish [ 18/Feb/13 ]

Naman is taking care of the issue

Comment by naman_mehta [ 18/Feb/13 ]

Updated javadoc for the same.





[GLASSFISH-17537] ServerTags class in nucleus contains appserver-specific tags Created: 31/Oct/11  Updated: 02/Nov/11

Status: Open
Project: glassfish
Component/s: configuration
Affects Version/s: 4.0
Fix Version/s: None

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

Tags: 3_1_x-exclude, nucleus-cleanup

 Description   

The com.sun.enterprise.config.serverbeans.ServerTags class contains constant String values that are specific to interfaces that are defined in main/appserver classes. These Strings should be moved out of nucleus.






[GLASSFISH-17532] Execution of Init SQL includes derby classpath Created: 31/Oct/11  Updated: 08/Nov/11  Resolved: 31/Oct/11

Status: Resolved
Project: glassfish
Component/s: Service Provisioning Engine
Affects Version/s: 4.0
Fix Version/s: 4.0

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

Tags: 3_1_x-exclude

 Description   

The Java DB plugin, while executing Init SQL in a database, includes the absolute classpath of derby jars in the ant runtime explicitly. This needs to change to a more generic classpath.



 Comments   
Comment by Shalini [ 31/Oct/11 ]

Fixing this in trunk.

Sending appserver/paas/plugins/javadb-plugin/src/main/java/org/glassfish/paas/javadbplugin/DerbyProvisioner.java
Sending appserver/paas/plugins/javadb-plugin/src/main/java/org/glassfish/paas/javadbplugin/cli/CreateDerbyService.java
Transmitting file data ..
Committed revision 50587.





[GLASSFISH-17522] atomic distribution does not start because of missing modules Created: 28/Oct/11  Updated: 21/Sep/15

Status: Open
Project: glassfish
Component/s: packaging
Affects Version/s: 4.0
Fix Version/s: 4.1.1

Type: Bug Priority: Major
Reporter: Sanjeeb Sahoo Assignee: Snjezana Sevo-Zenzerovic
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1_x-exclude

 Description   

There seems to be missing modules which is causing atomic distribution to fail to start.



 Comments   
Comment by TangYong [ 22/Jun/12 ]

The issue seems to be the same as http://java.net/jira/browse/GLASSFISH-18642.

Comment by Sanjeeb Sahoo [ 18/Feb/13 ]

Exception seen in recent build (svn #59497)

Exception in thread "main" java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at com.sun.enterprise.glassfish.bootstrap.GlassFishMain.main(GlassFishMain.java:97)
at com.sun.enterprise.glassfish.bootstrap.ASMain.main(ASMain.java:55)
Caused by: A MultiException has 1 exceptions. They are:
1. org.glassfish.hk2.api.MultiException: A MultiException has 2 exceptions. They are:
1. com.sun.enterprise.module.ResolveError: Failed to start OSGiModuleImpl:: Bundle = [org.glassfish.main.common.util [47]], State = [NEW]
2. java.lang.IllegalStateException: Could not load descriptor SystemDescriptor(
implementation=org.glassfish.common.util.admin.HK2BindTracingService
contracts=

{org.glassfish.common.util.admin.HK2BindTracingService,org.glassfish.hk2.api.ValidationService}
scope=javax.inject.Singleton
qualifiers={}
descriptorType=CLASS
descriptorVisibility=NORMAL
metadata=Bundle-SymbolicName={org.glassfish.main.common.util},Bundle-Version={4.0.0.SNAPSHOT}
rank=0
loader=OsgiPopulatorPostProcessor.HK2Loader(OSGiModuleImpl:: Bundle = [org.glassfish.main.common.util [47]], State = [NEW],13171230)
proxiable=null
analysisName=null
id=425
locatorId=0
identityHashCode=10284000
reified=false)


at com.sun.enterprise.module.common_impl.AbstractModulesRegistryImpl.populateServiceLocator(AbstractModulesRegistryImpl.java:202)
at com.sun.enterprise.module.bootstrap.Main.createServiceLocator(Main.java:272)
at org.jvnet.hk2.osgiadapter.HK2Main.createServiceLocator(HK2Main.java:120)
at com.sun.enterprise.glassfish.bootstrap.osgi.EmbeddedOSGiGlassFishRuntime.newGlassFish(EmbeddedOSGiGlassFishRuntime.java:95)
at com.sun.enterprise.glassfish.bootstrap.GlassFishRuntimeDecorator.newGlassFish(GlassFishRuntimeDecorator.java:68)
at com.sun.enterprise.glassfish.bootstrap.osgi.OSGiGlassFishRuntime.newGlassFish(OSGiGlassFishRuntime.java:88)
at com.sun.enterprise.glassfish.bootstrap.GlassFishMain$Launcher.launch(GlassFishMain.java:113)
... 6 more
Caused by: A MultiException has 2 exceptions. They are:
1. com.sun.enterprise.module.ResolveError: Failed to start OSGiModuleImpl:: Bundle = [org.glassfish.main.common.util [47]], State = [NEW]
2. java.lang.IllegalStateException: Could not load descriptor SystemDescriptor(
implementation=org.glassfish.common.util.admin.HK2BindTracingService
contracts={org.glassfish.common.util.admin.HK2BindTracingService,org.glassfish.hk2.api.ValidationService}

scope=javax.inject.Singleton
qualifiers={}
descriptorType=CLASS
descriptorVisibility=NORMAL
metadata=Bundle-SymbolicName=

{org.glassfish.main.common.util}

,Bundle-Version=

{4.0.0.SNAPSHOT}

rank=0
loader=OsgiPopulatorPostProcessor.HK2Loader(OSGiModuleImpl:: Bundle = [org.glassfish.main.common.util [47]], State = [NEW],13171230)
proxiable=null
analysisName=null
id=425
locatorId=0
identityHashCode=10284000
reified=false)

at org.jvnet.hk2.internal.ServiceLocatorImpl.loadClass(ServiceLocatorImpl.java:1631)
at org.jvnet.hk2.internal.ServiceLocatorImpl.reifyDescriptor(ServiceLocatorImpl.java:360)
at org.jvnet.hk2.internal.ServiceLocatorImpl.reifyDescriptor(ServiceLocatorImpl.java:378)
at org.jvnet.hk2.internal.ServiceLocatorImpl.checkConfiguration(ServiceLocatorImpl.java:1268)
at org.jvnet.hk2.internal.ServiceLocatorImpl.addConfiguration(ServiceLocatorImpl.java:1536)
at org.jvnet.hk2.internal.DynamicConfigurationImpl.commit(DynamicConfigurationImpl.java:212)
at org.glassfish.hk2.bootstrap.HK2Populator.populate(HK2Populator.java:137)
at org.jvnet.hk2.osgiadapter.OSGiModuleImpl.parseInhabitants(OSGiModuleImpl.java:396)
at org.jvnet.hk2.osgiadapter.AbstractOSGiModulesRegistryImpl.parseInhabitants(AbstractOSGiModulesRegistryImpl.java:119)
at com.sun.enterprise.module.common_impl.AbstractModulesRegistryImpl.populateServiceLocator(AbstractModulesRegistryImpl.java:180)
... 12 more
Caused by: com.sun.enterprise.module.ResolveError: Failed to start OSGiModuleImpl:: Bundle = [org.glassfish.main.common.util [47]], State = [NEW]
at org.jvnet.hk2.osgiadapter.OSGiModuleImpl.start(OSGiModuleImpl.java:223)
at org.jvnet.hk2.osgiadapter.OsgiPopulatorPostProcessor$1.loadClass(OsgiPopulatorPostProcessor.java:79)
at org.jvnet.hk2.internal.ServiceLocatorImpl.loadClass(ServiceLocatorImpl.java:1623)
... 21 more
Caused by: org.osgi.framework.BundleException: Unresolved constraint in bundle org.glassfish.main.common.util [47]: Unable to resolve 47.0: missing requirement [47.0] osgi.wiring.package; (&(osgi.wiring.package=org.glassfish.api)(version>=4.0.0)(Unable to render embedded object: File ( Unable to resolve 52.0: missing requirement [52.0] osgi.wiring.package; (&(osgi.wiring.package=org.glassfish.grizzly.http.server)(version>=2.3.0)() not found.(version>=3.0.0))) [caused by: Unable to resolve 12.0: missing requirement [12.0] osgi.wiring.package; (osgi.wiring.package=org.glassfish.gmbal) [caused by: Unable to resolve 38.0: missing requirement [38.0] osgi.wiring.package; (osgi.wiring.package=org.glassfish.pfl.basic.algorithm)]]]
at org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3962)
at org.apache.felix.framework.Felix.startBundle(Felix.java:2025)
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:955)
at org.jvnet.hk2.osgiadapter.OSGiModuleImpl.start(OSGiModuleImpl.java:215)
... 23 more





[GLASSFISH-17521] non-osgi modules in modules/ Created: 28/Oct/11  Updated: 20/Dec/16  Resolved: 22/Jan/13

Status: Resolved
Project: glassfish
Component/s: packaging
Affects Version/s: 4.0
Fix Version/s: 4.0_dev

Type: Bug Priority: Critical
Reporter: Sanjeeb Sahoo Assignee: Romain Grécourt
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1_x-exclude

 Description   

I see two such jars in modules/:
activation.jar and easymock.jar



 Comments   
Comment by Snjezana Sevo-Zenzerovic [ 02/Nov/11 ]

Fixed activation.jar exclusion which regressed due to package content move. I don't see easymock.jar in recent distributions so that may have been transient problem.

Marking as fixed.

Comment by Sanjeeb Sahoo [ 01/Dec/11 ]

I see easymock.jar in recent builds as well:

ss141213@Sahoo:/space/ss141213/WS/gf/trunk$ unzip -l /home/ss141213/download/glassfish-4.0-b13.zip | grep easymock
80303 2011-11-30 14:55 glassfish3/glassfish/modules/easymock.jar

Comment by Sanjeeb Sahoo [ 01/Apr/12 ]

as of 1 Apr 2012:
/space/ss141213/WS/gf/v3/publish/glassfish3/glassfish/modules/jboss-interceptor-core.jar
/space/ss141213/WS/gf/v3/publish/glassfish3/glassfish/modules/javassist.jar
/space/ss141213/WS/gf/v3/publish/glassfish3/glassfish/modules/guava.jar
/space/ss141213/WS/gf/v3/publish/glassfish3/glassfish/modules/jboss-interceptors-api_1.1_spec.jar
/space/ss141213/WS/gf/v3/publish/glassfish3/glassfish/modules/cdi-api.jar
/space/ss141213/WS/gf/v3/publish/glassfish3/glassfish/modules/jboss-interceptor-spi.jar
/space/ss141213/WS/gf/v3/publish/glassfish3/glassfish/modules/jsr250-api.jar

Comment by Romain Grécourt [ 22/Jan/13 ]

the reported jar have been excluded from the GlassFish distribution.





[GLASSFISH-17502] HTTP IdleTimeout -1 not working Created: 27/Oct/11  Updated: 02/Dec/11  Resolved: 01/Dec/11

Status: Closed
Project: glassfish
Component/s: grizzly-kernel
Affects Version/s: 4.0
Fix Version/s: 4.0

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

Tags: 3_1_x-exclude

 Description   

I have this setting in my domain.xml

<http timeout-seconds="-1" .../>

which should disable the idle timeout. But instead, the socket is immediately closed after each request.



 Comments   
Comment by oleksiys [ 28/Oct/11 ]

grizzly issue
http://java.net/jira/browse/GRIZZLY-1102

Comment by Ryan Lubke [ 28/Oct/11 ]

2.1.6 has been integrated. Should be in 4.0-b09.

Comment by oleksiys [ 01/Dec/11 ]

reopen to set build version





[GLASSFISH-17501] Native ByteBuffers leaked from TCPNIOTransport [Grizzly tracking bug] Created: 27/Oct/11  Updated: 20/Dec/16  Resolved: 01/Dec/11

Status: Closed
Project: glassfish
Component/s: grizzly-kernel
Affects Version/s: 3.1.2_dev, 4.0
Fix Version/s: 4.0

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

Tags: 3_1_x-exclude

 Description   

Tracking bug for grizzly issue 1101; we can close when that fix is integrated.



 Comments   
Comment by Ryan Lubke [ 28/Oct/11 ]

2.1.6 has been integrated. Should be in 4.0-b09.

Comment by oleksiys [ 01/Dec/11 ]

reopen to set correct build numbers

Comment by oleksiys [ 01/Dec/11 ]

close





[GLASSFISH-17500] JVM options inappropriate for nucleus are in the nucleus domain.xml template Created: 27/Oct/11  Updated: 15/Dec/11  Resolved: 15/Dec/11

Status: Resolved
Project: glassfish
Component/s: configuration
Affects Version/s: 4.0
Fix Version/s: 4.0

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

Tags: 3_1_x-exclude, nucleus-cleanup

 Description   

The nucleus domain.xml template file contains JVM options that are inappropriate for nucleus. For example:

<jvm-options>-Djdbc.drivers=org.apache.derby.jdbc.ClientDriver</jvm-options>

This issue is for reviewing the JVM options in domain.xml and removing those that don't belong in nucleus.



 Comments   
Comment by Tom Mueller [ 15/Dec/11 ]

Fixed in revision 51586.

Removed definitions for jdbc.drivers and com.sun.enterprise.config.config_environment_factory_class.





[GLASSFISH-17489] Remove glassfish-naming from nucleus (move to main/appserver) Created: 25/Oct/11  Updated: 06/Mar/12  Resolved: 08/Feb/12

Status: Resolved
Project: glassfish
Component/s: naming
Affects Version/s: 4.0
Fix Version/s: 4.0

Type: Bug Priority: Major
Reporter: Tom Mueller Assignee: Cheng Fang
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
is duplicated by GLASSFISH-18303 Move glassfish-naming from nucleus to... Resolved
Related
is related to GLASSFISH-18340 consolidate packager/nucleus-corba-ba... Open
Tags: 3_1_x-exclude, nucleus-cleanup

 Description   

This is for removing the glassfish-naming.jar file and its dependencies from nucleus as it implements app server specific functionality.



 Comments   
Comment by Cheng Fang [ 03/Feb/12 ]

r52418 | cf126330 | 2012-02-02 23:02:41 -0500 (Thu, 02 Feb 2012) | 2 lines

pom.xml changes for issue 17489 move glassfish-naming module out of nucleus to appserver, reviewed by Jane.

r52419 | cf126330 | 2012-02-02 23:06:23 -0500 (Thu, 02 Feb 2012) | 1 line

Moving files for issue 17489 move glassfish-naming module out of nucleus to appserver.

r52420 | cf126330 | 2012-02-02 23:13:13 -0500 (Thu, 02 Feb 2012) | 1 line

update parent name from nucleus-common to common after moving this module from necleus to appserver.

Comment by Cheng Fang [ 08/Feb/12 ]

r52502 | cf126330 | 2012-02-08 10:21:20 -0500 (Wed, 08 Feb 2012) | 2 lines

Issue 17489 remove glassfish-corba-omgapi and glassfish-corba-internal-api from nucleus, reviewed by dev, ran QL.

Comment by Cheng Fang [ 08/Feb/12 ]

Further nucleus packaging adjustment is tracked in GLASSFISH-18340.

Comment by Cheng Fang [ 06/Mar/12 ]

Committed revision 52783.

Adding (bin) appserver/packager/appserver-base/lib/jndi-properties.jar
Deleting nucleus/packager/nucleus-base/lib/jndi-properties.jar





[GLASSFISH-17486] native: basic_paas_sample without services on ogs-4.0-b06.zip Created: 25/Oct/11  Updated: 20/Dec/16  Resolved: 30/May/12

Status: Resolved
Project: glassfish
Component/s: iaas
Affects Version/s: 4.0
Fix Version/s: 4.0_dev

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

OEL5.x and JDK1.6.0_28


Tags: 3_1_x-exclude

 Description   

ogs-4.0-b06.zip
In native mode, basic_paas_sample without services on ogs-4.0-b06.zip
The same sample has services on glassfish-4.0-b06.zip



 Comments   
Comment by sherryshen [ 25/Oct/11 ]

Test details are shown below.
http://sqe-hudson.us.oracle.com:8080/hudson/view/Sherry_paas/job/sherry-basic-paas-sample-oel/
#19, ogs-4.0-b06.zip, without services after deploy, tests failed.

From hudson console log
http://sqe-hudson.us.oracle.com:8080/hudson/view/Sherry_paas/job/sherry-basic-paas-sample-oel/19/console
Mon Oct 24 20:18:05 PDT 2011
+ asadmin deploy basic_paas_sample.war
Application deployed with name basic_paas_sample.
Command deploy executed successfully.
+ date
Mon Oct 24 20:18:08 PDT 2011
+ asadmin list-services
Nothing to list.
Command list-services executed successfully.

From admincli log
http://sqe-hudson.us.oracle.com:8080/hudson/view/Sherry_paas/job/sherry-basic-paas-sample-oel/19/artifact/cli.log

10/24/2011 20:17:58 EXIT: 0 asadmin start-domain --debug
10/24/2011 20:18:01 EXIT: 0 asadmin create-ims-config-native
10/24/2011 20:18:02 EXIT: 0 asadmin stop-domain
10/24/2011 20:18:05 EXIT: 0 asadmin start-domain --debug
10/24/2011 20:18:08 EXIT: 0 asadmin deploy basic_paas_sample.war
10/24/2011 20:18:08 EXIT: 0 asadmin list-services

#20 glassfish-4.0-b06.zip, with services after deploy, test passed.
+ date Mon Oct 24 20:27:46 PDT 2011
+ asadmin deploy basic_paas_sample.war
Application deployed with name basic_paas_sample.
Command deploy executed successfully.
+ date Mon Oct 24 20:28:12 PDT 2011
+ asadmin list-services
SERVICE-NAME IP-ADDRESS VM-ID SERVER-TYPE STATE SCOPE
basic NA NA cluster Running application
basic.cloud-1 10.133.185.1 cloud-1 clusterinstance Running application
basic.cloud-2 10.133.185.1 cloud-2 clusterinstance Running application
Command list-services executed successfully.

Comment by Shalini [ 27/Oct/11 ]

I tried with the latest ogs build with the following manual steps:

  • Remove paas.oracledbplugin.jar
  • Remove paas.lbplugin*.jar
  • Copy Native.xml into glassfish3/glassfish/config directory.

All other steps were the same.

The test passed and i was able to access the application without LB.

In ogs build, the Native.xml is not copied over to glassfish3/glassfish/config directory. This is needed for updating the template configuration. Transferring to Jerome to fix this.

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to reassign dochez issue to component lead.

Comment by sherryshen [ 30/May/12 ]

Test worked on ogs-4.0-b38-dev.zip with details in
https://bug.oraclecorp.com/pls/bug/webbug_edit.edit_info_top?rptno=14137928





[GLASSFISH-17459] nucleus: unable to run the nucleus GIOP example Created: 23/Oct/11  Updated: 18/Nov/11  Resolved: 23/Oct/11

Status: Closed
Project: glassfish
Component/s: other
Affects Version/s: None
Fix Version/s: None

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

Tags: 3_1_x-exclude

 Description   

unzip nucleus.zip, try the setup instruction for the GIOP example, it gives following errors

glassfish3/glassfish/bin > ./asadmin create-protocol giop-protocol
Command create-protocol not found.
Check the entry of command name. This command may be provided by a package that is not installed.
Command create-protocol failed.

glassfish3/glassfish/bin > ./asadmin create-protocol-filter --protocol giop-protocol --classname org.glassfish.grizzly.samples.filterchain.GIOPCodecFilter giop-codec-filter
Command create-protocol-filter not found.
Check the entry of command name. This command may be provided by a package that is not installed.
Command create-protocol-filter failed.
glassfish3/glassfish/bin > ./asadmin create-network-listener --listenerport 7777 --protocol http-listener-1 giop-listener-1
Command create-network-listener not found.
Check the entry of command name. This command may be provided by a package that is not installed.
Command create-network-listener failed.



 Comments   
Comment by amyk [ 23/Oct/11 ]

The latest nucleus nucleus-4.0-b06.zip is able to run the GIOP example by manually add the configuration to domain.xml, therefore closing the issue





[GLASSFISH-17452] paas console monitoring graph not shown on KVM Ubuntu 64bit firefox 6 Created: 21/Oct/11  Updated: 08/Nov/11  Resolved: 08/Nov/11

Status: Resolved
Project: glassfish
Component/s: paas-console
Affects Version/s: 4.0
Fix Version/s: 4.0

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

Ubuntu 10.10 x86_64 and Firefox 6


Attachments: JPEG File kvm_firefox6_ubuntu_b08_plus_fix.jpg     JPEG File kvm_monitoring_b08.jpg     JPEG File ubuntu_firefox6.jpg     JPEG File windows7_firefox6_native_b08.jpg     JPEG File windows7_firefox6_ovm_b08.jpg    
Tags: 3_1_x-exclude

 Description   

paas console monitoring graph not shown on KVM Ubuntu 64bit firefox 6

v4.0 build 7 nightly in glassfish.zip

During kvm tests, paas console monitoring graph not shown on Ubuntu 64bit firefox 6.
The monitoring page show the messages repeatedly,
"This component needs an SVG enable browser like ..., Fireofx 1.5+, ...".
The test browser is Firefox 6, i.e.
http://www.ubuntubuzz.com/2011/10/ubuntu-1110-review-and-features.html
Firefox 6 for Linux/Ubuntu 64bit (tar.bz2)



 Comments   
Comment by sherryshen [ 21/Oct/11 ]

The monitoring page show the messages repeatedly on b06.
http://java.net/jira/secure/attachment/47746/ubuntu_firefox6.jpg

Comment by Anissa Lam [ 02/Nov/11 ]

so, for native mode, some browser works and some doesn't.
For kvm, none of the browser works ?

Have you verified that with KVM setup, monitoring data is actually available ?

You can try the following REST endpoint using the browser.
Replace INSTANCE-NAME or CLUSTER-NAME with the actual name.

http://localhost:4848/monitoring/elasticity/domain/INSTANCE-NAME/session_count
http://localhost:4848/monitoring/elasticity/domain/server/cluster_instance_size/CLUSTER-NAME
http://localhost:4848/monitoring/elasticity/domain/INSTANCE-NAME/jvm_memory
http://localhost:4848/monitoring/elasticity/domain/INSTANCE-NAME/processingtime

Comment by sherryshen [ 02/Nov/11 ]

As b06, I thought that the graph problem was w.r.t. firefox on ubuntu.
With tests on b08, the graph problem may be general.

1) The same browser can view graph on 1 setup, but not another.
The one browser (firefox 6 on my laptop of windows 7) on b08
– Monitoring graph works with glassfish.zip with native and b08 on mac.
http://java.net/jira/secure/attachment/47928/windows7_firefox6_native_b08.jpg
http://asqe-xserver-1.us.oracle.com:8080/paas-console/

– Monitoring graph doesn't work with ogs.zip with ovm and b08 on oel
http://java.net/jira/secure/attachment/47927/windows7_firefox6_ovm_b08.jpg
http://asqe-x2250-st1.us.oracle.com:8080/paas-console

2) The same browser can view graph in old build, but not in new build.
Another browser (firefox 7 on office pc of windows xp)
– Monitoring graph works with native and b04 on mac.
– Monitoring graph doesn't work with native and b08 on mac.

Comment by mzh777 [ 02/Nov/11 ]

1. http://localhost:4848/monitoring/elasticity/domain/sca-pool1_ovm_ConferencePlanner-2Instance/seesion_count
No data
2. http://localhost:4848/monitoring/elasticity/domain/server/cluster_instance_size/ConferencePlanner
There are data.
3. http://localhost:4848/monitoring/elasticity/domain/sca-pool1_ovm_ConferencePlanner-2Instance/jvm_memory
There are data.
4. http://localhost:4848/monitoring/elasticity/domain/sca-pool1_ovm_ConferencePlanner-2Instance/processingtime
instance : sca-pool1_ovm_ConferencePlanner-2Instance

Comment by sherryshen [ 02/Nov/11 ]

kvm monitoring info with elasticity demo on b08.

I collected monitoring info from KVM with using Elasticity Demo in
http://java.net/jira/secure/attachment/47929/kvm_monitoring_b08.jpg
--No monitoring graph at paas console.
--The monitoring info in 4 URLs have data.
--Build 8 in glassfish.zip
--Firefox 6 on the test machine with ubuntu 10.10.

Comment by sumasri [ 03/Nov/11 ]

I am also using Ubuntu 10.04 64-bit machine and Firefox 8.0.. Charts are showing..

1) Please try the same with firefox7 and firefox8 also and see if the charts are showing up..and make sure that the data is in REST URL's.
2) One issue could be svg is not enabled in the browser..Try to install adobe svg viewer in the browser and try..

Can I get the access to those machines where the problem is ?

Comment by sherryshen [ 03/Nov/11 ]

build 8.
For native mode on mac, 1 browser works for Sherry, but several browsers (firefox and ie)
by 3 persons (Ming, Sherry, Sonia) don't work with monitoring graph.
For ovm mode on oel, all browsers by the 3 persons don't work.
For kvm mode on ubuntu, 1 browser doesn't work, not tested with other browsers.
Most browsers are used from pc on windows remotely.
Only kvm mode is tested with local browser.

The adobe svg plugin is installed in the browsers.
Some browsers can view monitoring graph on build 4, but not on build 8.
The login for test machines are sent to Suma and Anissa in email.

Comment by sumasri [ 04/Nov/11 ]

There is one duplicate line in chart.svg file..
In the test machine also, charts are showing up after making the change.
Sent a mail with all the information.
Will check in the change once it is reviewed from GUI team.

Comment by sherryshen [ 04/Nov/11 ]

The monitoring graph is shown on firefox 6 with kvm and ubuntu 10.10.
http://java.net/jira/secure/attachment/47961/kvm_firefox6_ubuntu_b08_plus_fix.jpg
This is build 08 with Suma's local fix. Thanks Suma.

Comment by mzh777 [ 04/Nov/11 ]

I was able to view the Monitoring page from FireFox 7.0.1 and IE 9 after deleting the extra line in glassfisha3/glassfish/lib/install/applications/__paas-console/images/chart.svg.

But found a lot error messages in server.log:
[#|2011-11-04T23:47:47.261+0000|WARNING|44.0|org.apache.myfaces.trinidadinternal.skin.SkinFactoryImpl|_ThreadID=26;_ThreadName=Thread-2;|Cannot find an unversioned skin for family console. We will use the versioned skin console.desktop.|#]

It repeats itself every 5 second and causing extra logging volume. If this is caused by chart.svg, please let me know and I'll file another bug.

Comment by Anissa Lam [ 04/Nov/11 ]

We are aware of this WARNING. It has nothing to do with this issue. It has been there since day 1.
However, to fix this, we will have to release another version of trinidad and we haven't done that.

Comment by sumasri [ 08/Nov/11 ]

Checked in the fix into trunk.

Sending webapp/src/main/webapp/images/chart.svg
Transmitting file data .
Committed revision 50703.





[GLASSFISH-17426] enhance the per instance/cluster library support Created: 14/Oct/11  Updated: 22/May/13

Status: Open
Project: glassfish
Component/s: admin
Affects Version/s: None
Fix Version/s: future release

Type: Improvement Priority: Major
Reporter: Hong Zhang Assignee: kumara
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to GLASSFISH-17409 Per instance/cluster libraries are no... Resolved
Tags: 3_1_x-exclude

 Description   

Today we have limited support for per instance/cluster library. There are some of the things we could possibly enhance in the next version:

1. Libraries to be picked up at runtime automatically instead of having to specify libraries option.

2. Support config/named-config/lib/ext.

3. Overcome the limitation that the same deployed application cannot be used with multiple different named-configs.



 Comments   
Comment by Tom Mueller [ 18/Oct/11 ]

Hong, can you explain what about #2 that we currently do not support? AFAIK, one just needs to install the config-specific library into config/named-config/lib/ext and then refer to it when deploying the application with

--libraries ../../config/named-config/lib/ext/whatever.jar

Comment by Hong Zhang [ 18/Oct/11 ]

Sahoo mentioned there is some additional work associated with extension libraries (validates the extension-list of the application against correct extensions?). I am not familiar with how our extension classloader is working today, we probably need to ask Sahoo to clarify with more details here.





[GLASSFISH-17425] Move Java EE specific dtds and schemas from nucleus to appserver Created: 14/Oct/11  Updated: 31/Oct/11  Resolved: 31/Oct/11

Status: Resolved
Project: glassfish
Component/s: packaging
Affects Version/s: 4.0
Fix Version/s: 4.0

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

Tags: 3_1_x-exclude, nucleus-cleanup

 Description   

The glassfish/lib/dtds directory contains many Java EE-specific DTDs which shouldn't be delivered with nucleus. All of the DTDs need to be moved. The glassfish/lib/schemas directory contains many Java EE-specific schemas which shouldn't be delivered with nucleus All of the schemas need to be moved.



 Comments   
Comment by Snjezana Sevo-Zenzerovic [ 14/Oct/11 ]

Not applicable to 3.1.x releases.

Comment by Snjezana Sevo-Zenzerovic [ 31/Oct/11 ]

Nucleus specific dtd and schema modules have been created in nucleus workspace. Marking the issue as fixed.





[GLASSFISH-17412] Annotations in plain java classes shouldn't be processed Created: 12/Oct/11  Updated: 20/Dec/16

Status: Open
Project: glassfish
Component/s: deployment
Affects Version/s: 3.1.1_dev
Fix Version/s: future release

Type: Bug Priority: Major
Reporter: omolenkamp Assignee: Hong Zhang
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: GZip Archive ejb-reference-testcase.tar.gz    
Tags: 3_1_x-exclude

 Description   

When deploying an EJB-module, Glassfish seems to scan for injection annotations in all classes, not just the ones marked as EJB.

This can lead to problems when plain java classes (no @Stateless, @Stateful, etc) contain annotations that would be invalid for container-managed classes, because Glassfish then refuses to deploy the application. It shouldn't do this, and instead ignore these annotations on unmanaged classes.

I've attached an example project that demonstrates this problem. It contains a non-EJB class AbstractTestA that contains an unresolvable @EJB annotation on a field, which causes deployment to fail:

SEVERE: Cannot resolve reference Local ejb-ref name=test.AbstractTestA/test,Local 3.x interface =test.TestA,ejb-link=null,lookup=,mappedName=,jndi-name=,refType=Session
SEVERE: Exception while deploying the app [ejb-reference-testcase]
SEVERE: Cannot resolve reference Local ejb-ref name=test.AbstractTestA/test,Local 3.x interface =test.TestA,ejb-link=null,lookup=,mappedName=,jndi-name=,refType=Session
java.lang.RuntimeException: Cannot resolve reference Local ejb-ref name=test.AbstractTestA/test,Local 3.x interface =test.TestA,ejb-link=null,lookup=,mappedName=,jndi-name=,refType=Session
at com.sun.enterprise.deployment.util.EjbBundleValidator.accept(EjbBundleValidator.java:608)
at com.sun.enterprise.deployment.EjbBundleDescriptor.visit(EjbBundleDescriptor.java:760)
at com.sun.enterprise.deployment.Application.visit(Application.java:1765)
at com.sun.enterprise.deployment.archivist.ApplicationFactory.openArchive(ApplicationFactory.java:195)
at org.glassfish.javaee.core.deployment.DolProvider.load(DolProvider.java:181)
at org.glassfish.javaee.core.deployment.DolProvider.load(DolProvider.java:93)
at com.sun.enterprise.v3.server.ApplicationLifecycle.loadDeployer(ApplicationLifecycle.java:828)
at com.sun.enterprise.v3.server.ApplicationLifecycle.setupContainerInfos(ApplicationLifecycle.java:770)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:368)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:240)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:382)
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:1064)
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:459)
at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:209)
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:828)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:725)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1019)
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)

SEVERE: Exception while deploying the app [ejb-reference-testcase] : Cannot resolve reference Local ejb-ref name=test.AbstractTestA/test,Local 3.x interface =test.TestA,ejb-link=null,lookup=,mappedName=,jndi-name=,refType=Session

My actual use case is only slightly more complex: I'm using a shared library jar in several EJB-modules, that contains both EJB interfaces and abstract implementations. The abstract implementations include an @EJB reference to their own interface, to be able to start certain operations in a new transaction.

Each EJB-module implements some (often not all) of the interfaces, using the provided abstract implementation. Because only the actual implementations are marked with @Stateless (etc) and the abstract ones are not, injection annotation processing should only happen for the beans that are actually implemented. This worked properly in Glassfish 2.1.



 Comments   
Comment by Cheng Fang [ 12/Oct/11 ]

@EJB and other annotations on the super classes of EJB bean class are part of the dependency of this EJB, and need to be processed. This is required by Java EE and EJB spec.

If some ejb-ref only apply to certain concrete EJB bean class, then the concrete bean class is better place than the common super class. You may want to use lookup, or have a non-annotated setter method in super class, to be overridden with a setter method annotated with @EJB in subclass if needed.

Comment by omolenkamp [ 12/Oct/11 ]

"@EJB and other annotations on the super classes of EJB bean class are part of the dependency of this EJB, and need to be processed. "

Yes, but what's happening is that these annotations are also processed on classes that aren't EJB's themselves, and don't have any subclasses that are EJB's either. There's no reason to do this, and it will break the setup I described.

Comment by Sanjeeb Sahoo [ 13/Oct/11 ]

Seems like a bug to me. @EJB should only be processed for classes that are "injection capable."

Comment by Cheng Fang [ 14/Oct/11 ]

Assign to deployment. Hong, can you take a look?

Comment by Hong Zhang [ 14/Oct/11 ]

Yes today we scan all the classes for annotations as it's hard to determine which we should scan and should not ahead of the time. But it might be possible to filter the processed results to remove the unwanted processing.
The reason it used to work in 2.* is we did not scan libraries for annotation processing which was a bug and we fixed that in 3.*.

Comment by Hong Zhang [ 18/Oct/11 ]

Will look at this for trunk (the changes for this will be too involving for 3.1.*).

Comment by Hong Zhang [ 28/Feb/13 ]

Scrub bugs for 4.0 HCF. Did not get a chance to look into this one, as the changes for this one will be very involving, re-target for later release.





[GLASSFISH-17410] Package versions used for Serlvet 3 specification Created: 11/Oct/11  Updated: 27/Mar/13  Resolved: 27/Mar/13

Status: Closed
Project: glassfish
Component/s: web_container
Affects Version/s: 3.1.1
Fix Version/s: future release

Type: Bug Priority: Major
Reporter: tjwatson Assignee: Shing Wai Chan
Resolution: Works as designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

All


Tags: 3_1_x-exclude

 Description   

Eclipse Jetty 8 uses the javax.servlet.jar bundle from glassfish. We have noticed that this bundle exports the javax.servlet packages at version=3.0. While this seems to be logical since the Servlet Specification version is 3.0 it does not follow the version guidelines documented by OSGi at http://osgi.org/wiki/uploads/Links/SemanticVersioning.pdf

My understanding is that the Servlet 3.0 specification is binary compatible for client applications but is breaking for Servlet container implementors. I don't think that is any different than the change from the Servlet Specification version 2.4->2.5. I would have expected the package version to be 2.6 not 3.0 for the OSGi package version.

Please see https://bugs.eclipse.org/bugs/show_bug.cgi?id=360245 for discussion.



 Comments   
Comment by Shing Wai Chan [ 14/Dec/11 ]

In this moment, all other spec versions are directly related to OSGi version.
If one makes it different, then one needs to maintain a mapping of versions.

Comment by Sanjeeb Sahoo [ 27/Mar/13 ]

OSGi metadata in general and package version in particular of various javax APIs have not received the kind of attention that they deserve. This problem is not only specific to APIs that are part of Java EE, but also to all non java.* packages that are part of Java SE platform. Lack of a standard here is really hurting OSGi application developers to write portable OSGi applications. The semantic versioning scheme proposed by OSGi Alliance is after implementations like GlassFish had started assigning version numbers to Java EE packages. Now going back to them will cause incompatibility with existing applications. More over, semantic versioning scheme is not binding. There was an effort started in OSGi Alliance to come up with a versioning scheme for javax APIs and there was even a proposal to do similar things in JCP, but neither took any shape. IIRC, that proposal talked about introduction of a specVersion attribute to javax APIs. e.g.,
Servlet 3.0 packages could be exported like:

Export-Package: javax.servlet; specVersion=2.5, javax.servlet; specVersion=3.0

Servlet 3.1 packages could be exported like:

Export-Package: javax.servlet; specVersion=2.5, javax.servlet; specVersion=3.0; javax.servlet; specVersion=3.1

Client built against Servlet 3.0 bundle would have their Import-Package generated like this:

Import-Package: javax.servlet; specVersion=3.0

It will continue to be satisfied when run against Servlet 3.1 bundle.

In GlassFish, we will continue to version the packages as per their spec version until a proposal like the above becomes effective. In the mean while, since javax packages are compatible, clients can relax their version constraints for javax packages if they like or deploy their own fragment bundle which reexports the javax packages with lesser version.

Comment by Shing Wai Chan [ 27/Mar/13 ]

According to comments from Sahoo, we will close the issue.





[GLASSFISH-17392] System property translation loops if a=${a} Created: 07/Oct/11  Updated: 21/Dec/11  Resolved: 21/Dec/11

Status: Resolved
Project: glassfish
Component/s: configuration
Affects Version/s: 3.1.1
Fix Version/s: 4.0

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

Tags: 3_1_x-exclude

 Description   

If a system property has the value a=$

{a}

, then the TranslatedConfigView class will loop forever trying to resolve the value. The bug is in TranslatedConfigView at about line 100.



 Comments   
Comment by Tom Mueller [ 19/Oct/11 ]

Excluding from 3.1.x releases.

Comment by Tom Mueller [ 21/Dec/11 ]

To recreate this problem, do:

asadmin create-system-properties 'a=$

{a}'
asadmin list-system-properties

The first command succeeds, but the second command pauses for a long time eventually times-out or has to be killed. This is because the server goes into an infinite loop trying to evaluate the value of a. Also, you will note that after the create-system-properties call, the server is consuming all of a CPU because of the infinite loop.

Also, after this system property is created, a list-system-properties after the server is restarted will also cause it to go into an infinite loop.

Other test cases are:

asadmin create-system-properties 'a=foo ${a}

'
asadmin create-system-properties 'a=foo $

{b}

:b=bar $

{a}

'

Comment by Tom Mueller [ 21/Dec/11 ]

Fixed in revision 51710.

The solution is to impose a limit of 100 on system property substitutions. This limit is arbitrarily chosen, but I expect this is large enough.





[GLASSFISH-17385] asadmin stop-domain does not end cleanly for MDB's Created: 06/Oct/11  Updated: 20/Dec/16

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: 3.1.1_dev
Fix Version/s: 4.1.1

Type: Bug Priority: Major
Reporter: tchng Assignee: marina vatkina
Resolution: Unresolved Votes: 5
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Java Archive File facelet.jar    
Tags: 3_1_x-exclude

 Description   

When trying to shut down glassfish using the command:

asadmin stop-domain --force=false

Looking at our logs, our Message Driven Beans will throw the following error when trying to finish processing by retrieving the messages that have been placed on the queue:

onMessage(): Failed to process JMS message.
javax.ejb.EJBException: Attempt to invoke when container is in STOPPED
at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1995) [ejb-container.jar:3.1.1]
at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1990) [ejb-container.jar:3.1.1]

When stopping our domain, we are unable to finish processing gracefully if this exception occurs.

Please advise.

Thanks!



 Comments   
Comment by tchng [ 06/Oct/11 ]

The feature we are looking for is:

"shutdown when work completes"

Comment by tchng [ 11/Oct/11 ]

This exception behavior still happens in Glassfish version 3.2-b06
15:20:17.360 [30b96561-d0d5-4cd8-a36d-dd8a5a610afb] [p: thread-pool-1; w: 17] ERROR c.b.z.s.w.SyncWorkflowMessageListener - onMessage(): Failed to process JMS message.
javax.ejb.EJBException: Attempt to invoke when container is in STOPPED
at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1996) [ejb-container.jar:3.2-b06]
at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1991) [ejb-container.jar:3.2-b06]
at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:222) ~[ejb-container.jar:3.2-b06]
at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:88) ~[ejb-container.jar:3.2-b06]
il.reflection.SecureReflectionAccess.run(SecureReflectionAccess.java:54) ~[na:na]
at org.jboss.weld.util.reflection.SecureReflectionAccess.runAsInvocation(SecureReflectionAccess.java:163) ~[na:na]
at org.jboss.weld.util.reflection.SecureReflections.invoke(SecureReflections.java:299) ~[na:na]

Comment by tchng [ 12/Oct/11 ]

We are able to simulate this problem beyond mdb's

Using a facelet page, that hits a JSF Managed bean which then iterates 40 times with a 1 second sleep hitting an EJB session bean, we then invoke:

asadmin stop-domain --force=false

The result of this creates the same exception:

[#|2011-10-12T14:58:09.808+0000|SEVERE|glassfish3.2|javax.enterprise.resource.webcontainer.jsf.application|_ThreadID=41;_ThreadName=Thread-2;|Error Rendering View[/index.xhtml]
javax.el.ELException: /index.xhtml: javax.ejb.EJBException: Attempt to invoke when container is in STOPPED
at com.sun.faces.facelets.compiler.TextInstruction.write(TextInstruction.java:88)
at com.sun.faces.facelets.compiler.UIInstructions.encodeBegin(UIInstructions.java:82)
at com.sun.faces.facelets.compiler.UILeaf.encodeAll(UILeaf.java:183)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1759)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1759)
at com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView(FaceletViewHandlingStrategy.java:401)
at com.sun.faces.application.view.MultiViewHandler.renderView(MultiViewHandler.java:131)
at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:288)
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:1562)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:286)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:173)
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:345)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:242)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:172)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:162)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:160)
at org.glassfish.grizzly.filterchain.ExecutorResolver$3.execute(ExecutorResolver.java:95)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:444)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:364)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:290)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:133)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:76)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:63)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:823)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:116)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$000(WorkerThreadIOStrategy.java:55)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$1.run(WorkerThreadIOStrategy.java:98)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:508)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:488)
at java.lang.Thread.run(Thread.java:680)
Caused by: javax.ejb.EJBException: Attempt to invoke when container is in STOPPED
at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1996)
at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1991)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:222)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:88)
at $Proxy313.getCounterValue(Unknown Source)
at com.test.bean._EJB31_GeneratedCounterSessionBeanIntf__Bean_.getCounterValue(Unknown Source)
at com.test.MyJSFManagedBean.getCount(MyJSFManagedBean.java:32)
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 javax.el.BeanELResolver.getValue(BeanELResolver.java:302)
at com.sun.faces.el.DemuxCompositeELResolver._getValue(DemuxCompositeELResolver.java:176)
at com.sun.faces.el.DemuxCompositeELResolver.getValue(DemuxCompositeELResolver.java:203)
at com.sun.el.parser.AstValue.getValue(AstValue.java:116)
at com.sun.el.parser.AstValue.getValue(AstValue.java:163)
at com.sun.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:219)
at org.jboss.weld.el.WeldValueExpression.getValue(WeldValueExpression.java:55)
at com.sun.faces.facelets.el.ELText$ELTextVariable.writeText(ELText.java:224)
at com.sun.faces.facelets.el.ELText$ELTextComposite.writeText(ELText.java:148)
at com.sun.faces.facelets.compiler.TextInstruction.write(TextInstruction.java:85)

It seems that the challenge is that when the web container invokes upon the ejb container while we are seeking to stop glassfish gracefully, this exception occurs which is not a graceful shut down.

The facelet skeleton project is an attachment.

Comment by tchng [ 12/Oct/11 ]

The facelet skeleton project that simulates this problem which occurs during the exection of:

asadmin stop-domain --force=false

That if a thread in the web-container is invoking something in the ejb-container in glassfish, we get the exception: javax.ejb.EJBException: Attempt to invoke when container is in STOPPED

Which when executing an mdb, the thread is expected to finish cleanly.

Comment by Satish Kumar [ 18/Nov/11 ]

Reassigning to Marina since this issue is related to the MDB container...

Comment by Cheng Fang [ 12/Dec/11 ]

A somewhat related issue is 17315 (cannot call EJB method from method sessionDestroyed (session listener) when web container wants undeploy enterprise application.), which has to do with the stop ordering between ejb container and web container.

Graceful shutdown of ejb container involves coordiation with other modules (JMS, JCA, etc). Also need to understand the level of gracefulness, e.g., do we still accept new method invocation belonging to the same txn, the same session, and shutdown timeout. Exclude it from 3.1.2 release.





[GLASSFISH-17372] Can't register a user if deploy with Init SQL File from paas console Created: 29/Sep/11  Updated: 26/Nov/12  Resolved: 26/Nov/12

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

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

glassfish on mac 10.5.8
mozilla firefox 7.0 on windows xp.


Tags: 3_1_x-exclude

 Description   

glassfish-4.0-b04.zip

For Conference+Planner
http://aseng-wiki.us.oracle.com/asengwiki/display/GlassFish/Conference+Planner
If I deploy with Init SQL File on paas console with a browser on windows xp,
I can't register a user with a browser on windows xp.
After deploying, data is loaded since "Tracks--Show Tracks" does show
sample data. When I register a new user, fill info and click "Register",
I don't get confirmation message, and can't login as that user.

If I deploy and load data with cli on mac, I can register a user from a
browser on windows xp.

The same build and test env are used.



 Comments   
Comment by arungupta [ 26/Nov/12 ]

This is likely fixed in a later version. The sample app is no longer actively developed anyway.





[GLASSFISH-17369] intermittent failure to edit schedule in Conference Planner demo Created: 28/Sep/11  Updated: 26/Nov/12  Resolved: 26/Nov/12

Status: Resolved
Project: glassfish
Component/s: sample_apps
Affects Version/s: 4.0
Fix Version/s: None

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

glassfish on mac 10.5.8
mozilla firefox 6.0.2 on windows xp


Tags: 3_1_x-exclude

 Description   

I observed the intermittent failure to edit schedule in
Conference Planner demo on several dev continuous builds
e.g. #9594 on Sept. 26, #9617 on Sept. 27.



 Comments   
Comment by sherryshen [ 28/Sep/11 ]

Conference Planner Demo in Native Mode

1) follow the instruction to setup demo app
http://aseng-wiki.us.oracle.com/asengwiki/display/GlassFish/Conference+Planner
I either deploy from admin console or from
admin cli, e.g.
asadmin start-domain
asadmin enable paas-console
asadmin create-ims-config-native
asadmin create-template --indexes ServiceType=LB,VirtualizationType=Native LBNative
asadmin deploy --availabilityenabled=true ConferencePlanner.war
svn co http://mercurial.us.oracle.com/svn/glassfish/branches/javaone-2011/LoadDatabase/
cd LoadDatabase
mvn scala:compile scala:run -Ddb=native

2) register a user and login from demo app
http://asqe-xserver-1.us.oracle.com:50080/ConferencePlanner/

3) click "My Schedule" --"Edit Schedule"
Some times, I saw the schedule correctly,
and other time I saw error no matter I deploy
from console or cli.

http://asqe-xserver-1.us.oracle.com:50080/ConferencePlanner/myschedule.xhtml
javax.servlet.ServletException:
Exception Description: An attempt was made to traverse a relationship using indirection that had a null Session.
This often occurs when an entity with an uninstantiated LAZY relationship is serialized and that lazy relationship is traversed after serialization. To avoid this issue, instantiate the LAZY relationship prior to serialization.
root cause
Exception [EclipseLink-7242] (Eclipse Persistence Services - 2.3.0.v20110604-r9504): org.eclipse.persistence.exceptions.ValidationException
Exception Description: An attempt was made to traverse a relationship using indirection that had a null Session. This often occurs when an entity with an uninstantiated LAZY relationship is serialized and that lazy relationship is traversed after serialization. To avoid this issue, instantiate the LAZY relationship prior to serialization.

Comment by sherryshen [ 28/Sep/11 ]

Saw the same error on today's build
http://gf-hudson.us.oracle.com/hudson/job/gf-trunk-build-continuous/
#9632 Sep 28, 2011 12:01:25 PM

0) Set up as above with admincli deploy and login with a new user.
1) My Schedue --Edit Schedule
See ex as before
2) Tracks – Show Track
OK with correct track.
3) My Schedule --Edit Schedule
OK with correct schedule

2) seems to be a workaround for demo to continue.

Comment by arungupta [ 26/Nov/12 ]

This sample is no longer actively developed but the reported issue was likely fixed in a later version.





[GLASSFISH-17360] paas console monitor label overlap Created: 28/Sep/11  Updated: 17/Oct/11  Resolved: 28/Sep/11

Status: Resolved
Project: glassfish
Component/s: paas-console
Affects Version/s: 4.0
Fix Version/s: 4.0

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

glassfish on mac 10.5.8
mozilla firefox 6.0 on windows 7


Attachments: PNG File paas_instance.png     PNG File paas_monitor.png     PNG File paas_monitor_9632.png    
Tags: 3_1_x-exclude

 Description   

dev continuous build #9617 on 9/27/2011

From Conference Planner demo, the elasticity feature is shown nicely
on paas console, "Cluster Instance Count Statistics" grahp, e.g.
2 to 3 instances when scaling up.
However, the label is overlapped.



 Comments   
Comment by sherryshen [ 28/Sep/11 ]

Label overlap in "Cluster Instance Count Statistics".

Comment by sherryshen [ 28/Sep/11 ]

color box and word are overlapped.

Comment by sherryshen [ 28/Sep/11 ]

Verified the fix with build #9632 on Sept. 28, 2011.
No overlapped labels.

Comment by sherryshen [ 28/Sep/11 ]

fixed.





[GLASSFISH-17359] "OSGi" not "OSGI" Created: 27/Sep/11  Updated: 18/Oct/11  Resolved: 28/Sep/11

Status: Resolved
Project: glassfish
Component/s: OSGi
Affects Version/s: 4.0
Fix Version/s: 4.0

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

Attachments: File osgi.diff    
Tags: 3_1_x-exclude

 Description   

Just some minor label changes.



 Comments   
Comment by Sanjeeb Sahoo [ 28/Sep/11 ]

svn rev #50006





[GLASSFISH-17350] NameNotFoundException thrown during undeployment of a WAR containing EJBs annotated with portable global JNDI names Created: 26/Sep/11  Updated: 20/Dec/16

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: 3.1.1_dev
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Vineet Reynolds Assignee: Srini
Resolution: Unresolved Votes: 4
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Zip Archive webejbexample.zip    
Tags: 3_1_x-exclude

 Description   

Original Java.net forum thread is http://www.java.net/forum/topic/glassfish/glassfish/namenotfoundexception-thrown-during-undeployment-war-containing-ejbs

The following exception stacktrace was produced during undeployment of a Web Archive containing EJBs with an explicit global and portable JNDI name:

[#|2011-09-26T17:39:47.229+0530|WARNING|glassfish3.1.1|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=20;_ThreadName=Thread-4;|WEB0610: [/WebEJBExample] failed to unbind namespace
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.TransientContext.unbind(TransientContext.java:424)
at com.sun.enterprise.naming.impl.TransientContext.unbind(TransientContext.java:424)
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.enterprise.container.common.impl.ComponentEnvManagerImpl.unbindFromComponentNamespace(ComponentEnvManagerImpl.java:355)
at com.sun.enterprise.web.WebModuleContextConfig.unbindFromComponentNamespace(WebModuleContextConfig.java:454)
at com.sun.enterprise.web.WebModuleContextConfig.stop(WebModuleContextConfig.java:447)
at com.sun.enterprise.web.WebModuleContextConfig.lifecycleEvent(WebModuleContextConfig.java:174)
at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:149)
at org.apache.catalina.core.StandardContext.stop(StandardContext.java:5603)
at com.sun.enterprise.web.WebModule.stop(WebModule.java:527)
at org.apache.catalina.core.ContainerBase.removeChild(ContainerBase.java:1049)
at com.sun.enterprise.web.WebContainer.unloadWebModule(WebContainer.java:2211)
at com.sun.enterprise.web.WebContainer.unloadWebModule(WebContainer.java:2166)
at com.sun.enterprise.web.WebApplication.stop(WebApplication.java:159)
at org.glassfish.internal.data.EngineRef.stop(EngineRef.java:169)
at org.glassfish.internal.data.ModuleInfo.stop(ModuleInfo.java:302)
at org.glassfish.internal.data.ApplicationInfo.stop(ApplicationInfo.java:322)
at com.sun.enterprise.v3.server.ApplicationLifecycle.unload(ApplicationLifecycle.java:999)
at com.sun.enterprise.v3.server.ApplicationLifecycle.undeploy(ApplicationLifecycle.java:1025)
at org.glassfish.deployment.admin.UndeployCommand.execute(UndeployCommand.java:330)
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:1064)
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:459)
at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:209)
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:828)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:725)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1019)
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)

#]

The error appears to occur when Glassfish attempts to undeploy the web module after undeploying the EJB module. The EJB module appears to be the one that owns the portable JNDI name, and when the web module attempts to unbind the non-existent JNDI name, the afore-mentioned exception is thrown. This has grave consequences in a more complicated scenario (like the usage of Hibernate as a JPA provider within the application), as the web-module does not appear to be completely undeployed, resulting in vague exceptions being thrown on a subsequent deployment and use of the application.

Surprisingly, the exception is not thrown when the EJB module is packaged in a EAR file, as an ejb-jar file. Also, no exceptions are thrown when no portable JNDI names are specified for the EJB using the @EJB annotation.

A testcase (an Eclipse project) to reproduce this is attached.



 Comments   
Comment by Hong Zhang [ 26/Sep/11 ]

assign to cheng for initial evaluation

Comment by Cheng Fang [ 27/Sep/11 ]

I was able to reproduce it. The use case is valid and should not cause exception logging. However, a cursory look at webModuleContextConfig.unbindFromComponentNamespace(...) method shows it only logs the exception, which shouldn't affect normal application flow. Can you provide more details how other parts of your app is affected?

Re-assign to web container for further evaluation.

From the above forum post, "the exception is not thrown when the EJB module is packaged in a EAR file, as an ejb-jar file. Also, no exceptions are thrown when no portable JNDI names are specified for the EJB using the @EJB annotation."

In addition, the exception is not thrown when @EJB is on servlet class.

The exception is thrown when @EJB is on ejb bean class and the ejb is packaged inside war.

Comment by Vineet Reynolds [ 28/Sep/11 ]

I'll attempt to enhance the provided test case with the failures I'm seeing in my application, since no exceptions are being thrown when using the redeployed testcase. My application currently uses Arquillian to deploy a WAR to a Glassfish instance via the REST interface. Manual deployment of the same WAR also gives the same problem, so we could rule out the REST interface. Currently, exceptions like the one shown in the below stacktrace are thrown, when attempting to use the application after redeployment. A restart of Glassfish always resolves this issue.

[#|2011-09-28T10:54:32.943+0530|WARNING|glassfish3.1.1|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=22;_ThreadName=Thread-4;|A system exception occurred during an invocation on EJB GroupRepository method public info.galleria.domain.Group info.galleria.service.jpa.GroupRepository.create(info.galleria.domain.Group)
javax.ejb.TransactionRolledbackLocalException: Exception thrown from bean
at com.sun.ejb.containers.BaseContainer.checkExceptionClientTx(BaseContainer.java:5049)
at com.sun.ejb.containers.BaseContainer.postInvokeTx(BaseContainer.java:4884)
at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:2039)
at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1990)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:236)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:88)
at $Proxy234.create(Unknown Source)
at info.galleria.service.jpa._EJB31_GeneratedGroupRepositoryIntf__Bean_.create(Unknown Source)
at info.galleria.service.ejb.GroupServiceImpl.createRegisteredUsersGroup(GroupServiceImpl.java:41)
at info.galleria.service.ejb.GroupServiceImpl.getOrCreateRegisteredUsersGroup(GroupServiceImpl.java:29)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.glassfish.ejb.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1052)
at org.glassfish.ejb.security.application.EJBSecurityManager.invoke(EJBSecurityManager.java:1124)
at com.sun.ejb.containers.BaseContainer.invokeBeanMethod(BaseContainer.java:5366)
at com.sun.ejb.EjbInvocation.invokeBeanMethod(EjbInvocation.java:619)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:800)
at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:571)
at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.doAround(SystemInterceptorProxy.java:162)
at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.aroundInvoke(SystemInterceptorProxy.java:144)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.ejb.containers.interceptors.AroundInvokeInterceptor.intercept(InterceptorManager.java:861)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:800)
at com.sun.ejb.containers.interceptors.InterceptorManager.intercept(InterceptorManager.java:370)
at com.sun.ejb.containers.BaseContainer.__intercept(BaseContainer.java:5338)
at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:5326)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:214)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:88)
at $Proxy237.getOrCreateRegisteredUsersGroup(Unknown Source)
at info.galleria.service.ejb.UserServiceImpl.signupUser(UserServiceImpl.java:54)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.glassfish.ejb.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1052)
at org.glassfish.ejb.security.application.EJBSecurityManager.invoke(EJBSecurityManager.java:1124)
at com.sun.ejb.containers.BaseContainer.invokeBeanMethod(BaseContainer.java:5366)
at com.sun.ejb.EjbInvocation.invokeBeanMethod(EjbInvocation.java:619)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:800)
at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:571)
at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.doAround(SystemInterceptorProxy.java:162)
at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.aroundInvoke(SystemInterceptorProxy.java:144)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.ejb.containers.interceptors.AroundInvokeInterceptor.intercept(InterceptorManager.java:861)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:800)
at com.sun.ejb.containers.interceptors.InterceptorManager.intercept(InterceptorManager.java:370)
at com.sun.ejb.containers.BaseContainer.__intercept(BaseContainer.java:5338)
at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:5326)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:214)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:88)
at $Proxy239.signupUser(Unknown Source)
at info.galleria.view.user.UserManager.signupUser(UserManager.java:71)
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.el.parser.AstValue.invoke(AstValue.java:234)
at com.sun.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:297)
at com.sun.faces.facelets.el.TagMethodExpression.invoke(TagMethodExpression.java:105)
at javax.faces.component.MethodBindingMethodExpressionAdapter.invoke(MethodBindingMethodExpressionAdapter.java:88)
at com.sun.faces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:102)
at javax.faces.component.UICommand.broadcast(UICommand.java:315)
at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:794)
at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:1259)
at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:81)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:593)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1539)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:343)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:217)
at org.primefaces.webapp.filter.FileUploadFilter.doFilter(FileUploadFilter.java:79)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:217)
at info.galleria.filters.UserRedirectFilter.doFilter(UserRedirectFilter.java:57)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:217)
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.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:330)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:231)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:174)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:828)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:725)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1019)
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)
Caused by: javax.persistence.PersistenceException: org.hibernate.PropertyAccessException: could not get a field value by reflection getter of info.galleria.domain.Group.groupId
at org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1179)
at org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1112)
at org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1118)
at org.hibernate.ejb.AbstractEntityManagerImpl.persist(AbstractEntityManagerImpl.java:618)
at com.sun.enterprise.container.common.impl.EntityManagerWrapper.persist(EntityManagerWrapper.java:269)
at info.galleria.service.jpa.GroupRepository.create(GroupRepository.java:31)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.glassfish.ejb.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1052)
at org.glassfish.ejb.security.application.EJBSecurityManager.invoke(EJBSecurityManager.java:1124)
at com.sun.ejb.containers.BaseContainer.invokeBeanMethod(BaseContainer.java:5366)
at com.sun.ejb.EjbInvocation.invokeBeanMethod(EjbInvocation.java:619)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:800)
at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:571)
at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.doAround(SystemInterceptorProxy.java:162)
at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.aroundInvoke(SystemInterceptorProxy.java:144)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.ejb.containers.interceptors.AroundInvokeInterceptor.intercept(InterceptorManager.java:861)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:800)
at com.sun.ejb.containers.interceptors.InterceptorManager.intercept(InterceptorManager.java:370)
at com.sun.ejb.containers.BaseContainer.__intercept(BaseContainer.java:5338)
at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:5326)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:214)
... 104 more
Caused by: org.hibernate.PropertyAccessException: could not get a field value by reflection getter of info.galleria.domain.Group.groupId
at org.hibernate.property.DirectPropertyAccessor$DirectGetter.get(DirectPropertyAccessor.java:62)
at org.hibernate.tuple.entity.AbstractEntityTuplizer.getIdentifier(AbstractEntityTuplizer.java:230)
at org.hibernate.persister.entity.AbstractEntityPersister.getIdentifier(AbstractEntityPersister.java:3852)
at org.hibernate.persister.entity.AbstractEntityPersister.isTransient(AbstractEntityPersister.java:3560)
at org.hibernate.engine.ForeignKeys.isTransient(ForeignKeys.java:204)
at org.hibernate.event.def.AbstractSaveEventListener.getEntityState(AbstractSaveEventListener.java:532)
at org.hibernate.event.def.DefaultPersistEventListener.onPersist(DefaultPersistEventListener.java:102)
at org.hibernate.event.def.DefaultPersistEventListener.onPersist(DefaultPersistEventListener.java:61)
at org.hibernate.impl.SessionImpl.firePersist(SessionImpl.java:800)
at org.hibernate.impl.SessionImpl.persist(SessionImpl.java:774)
at org.hibernate.impl.SessionImpl.persist(SessionImpl.java:778)
at org.hibernate.ejb.AbstractEntityManagerImpl.persist(AbstractEntityManagerImpl.java:612)
... 128 more
Caused by: java.lang.IllegalArgumentException: Can not set java.lang.String field info.galleria.domain.Group.groupId to info.galleria.domain.Group
at sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:146)
at sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:150)
at sun.reflect.UnsafeFieldAccessorImpl.ensureObj(UnsafeFieldAccessorImpl.java:37)
at sun.reflect.UnsafeObjectFieldAccessorImpl.get(UnsafeObjectFieldAccessorImpl.java:18)
at java.lang.reflect.Field.get(Field.java:358)
at org.hibernate.property.DirectPropertyAccessor$DirectGetter.get(DirectPropertyAccessor.java:59)
... 139 more

#]
Comment by Shing Wai Chan [ 11/Oct/11 ]

From the debugger, I see that "GreetingManager" was unbind twice and hence has the exception in the second invocation. Web container only logs the exception as it wants the undeployment to continue in this case.

The following are the two calling stack:
1. at com.sun.enterprise.naming.impl.TransientContext.unbind(TransientContext.java:420)
at com.sun.enterprise.naming.impl.TransientContext.unbind(TransientContext.java:424)
at com.sun.enterprise.naming.impl.TransientContext.unbind(TransientContext.java:424)
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.ejb.containers.BaseContainer$JndiInfo.unpublish(BaseContainer.java:5636)
at com.sun.ejb.containers.BaseContainer.doContainerCleanup(BaseContainer.java:4318)
at com.sun.ejb.containers.BaseContainer.undeploy(BaseContainer.java:4222)
at org.glassfish.ejb.startup.EjbApplication.stop(EjbApplication.java:305)
at org.glassfish.internal.data.EngineRef.stop(EngineRef.java:169)
at org.glassfish.internal.data.ModuleInfo.stop(ModuleInfo.java:302)
at org.glassfish.internal.data.ApplicationInfo.stop(ApplicationInfo.java:322)
at com.sun.enterprise.v3.server.ApplicationLifecycle.unload(ApplicationLifecycle.java:999)
at com.sun.enterprise.v3.server.ApplicationLifecycle.undeploy(ApplicationLifecycle.java:1025)
at org.glassfish.deployment.admin.UndeployCommand.execute(UndeployCommand.java:330)

2. 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.TransientContext.unbind(TransientContext.java:424)
at com.sun.enterprise.naming.impl.TransientContext.unbind(TransientContext.java:424)
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.enterprise.container.common.impl.ComponentEnvManagerImpl.unbindFromComponentNamespace(ComponentEnvManagerImpl.java:355)
at com.sun.enterprise.web.WebModuleContextConfig.unbindFromComponentNamespace(WebModuleContextConfig.java:454)
at com.sun.enterprise.web.WebModuleContextConfig.stop(WebModuleContextConfig.java:447)
at com.sun.enterprise.web.WebModuleContextConfig.lifecycleEvent(WebModuleContextConfig.java:174)
at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:149)
at org.apache.catalina.core.StandardContext.stop(StandardContext.java:5603)
at com.sun.enterprise.web.WebModule.stop(WebModule.java:527)
at org.apache.catalina.core.ContainerBase.removeChild(ContainerBase.java:1049)
at com.sun.enterprise.web.WebContainer.unloadWebModule(WebContainer.java:2216)
at com.sun.enterprise.web.WebContainer.unloadWebModule(WebContainer.java:2171)
at com.sun.enterprise.web.WebApplication.stop(WebApplication.java:159)
at org.glassfish.internal.data.EngineRef.stop(EngineRef.java:169)
at org.glassfish.internal.data.ModuleInfo.stop(ModuleInfo.java:302)
at org.glassfish.internal.data.ApplicationInfo.stop(ApplicationInfo.java:322)
at com.sun.enterprise.v3.server.ApplicationLifecycle.unload(ApplicationLifecycle.java:999)
at com.sun.enterprise.v3.server.ApplicationLifecycle.undeploy(ApplicationLifecycle.java:1025)
at org.glassfish.deployment.admin.UndeployCommand.execute(UndeployCommand.java:330)

The "GreetingManager" was unbind twice as the ejb reference presents in both ejb and web bundle descriptors. Note that those descriptors are from annotation processing for ejb in war.

Comment by Cheng Fang [ 08/Nov/11 ]

Added tag 3_1_x-exclude. There are various workaround as described in previous comments. The logged stack trace is only warning message and should not affect normal app functioning.

Comment by markokanala [ 20/Mar/13 ]

I stumbled upon this issue. I can confirm this breaks the redeploy cycle as the deploy after this exception fails. This very annoying in development use.

I'm not really sure what exactly breaks but it seems that injecting EJB's on redeploy fails.

[#|2013-03-20T15:18:25.528+0200|SEVERE|glassfish3.1.2|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=19;_ThreadName=Thread-3;|WebModule[/api]PWC1270: Exception starting filter VirtualHostingFilter
java.lang.InstantiationException
at org.apache.catalina.core.ApplicationFilterConfig.<init>(ApplicationFilterConfig.java:124)
...
Caused by: com.sun.enterprise.container.common.spi.util.InjectionException: Error creating managed object for class: class our.application.api.security.VirtualHostingFilter
at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.createManagedObject(InjectionManagerImpl.java:315)
at com.sun.enterprise.web.WebContainer.createFilterInstance(WebContainer.java:745)
...
Caused by: com.sun.enterprise.container.common.spi.util.InjectionException: Exception attempting to inject Local ejb-ref name= ... into nto class our.application.api.security.VirtualHostingFilter: Can not set our.application.core.service.CompanyService field our.application.api.security.VirtualHostingFilter.companyService to our.application.api.security.VirtualHostingFilter

and

[#|2013-03-20T15:18:25.919+0200|SEVERE|glassfish3.1.2|com.sun.jersey.server.impl.ejb.EJBComponentProviderFactoryInitilizer|_ThreadID=19;_ThreadName=Thread-3;|Error when configuring to use the EJB interceptor binding API. JAX-RS EJB support is disabled.
java.lang.reflect.InvocationTargetException
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.jersey.server.impl.ejb.EJBComponentProviderFactoryInitilizer.initialize(EJBComponentProviderFactoryInitilizer.java:80)

Comment by klaasjanelzinga [ 03/Sep/13 ]

My redeployment cycle worked again after adding the messagelistener to the ejb-jar.xml:

<enterprise-beans>
<message-driven>
<ejb-name>...</ejb-name>
<ejb-class>...</ejb-class>
</message-driven>
</enterprise-beans>

Only the @MessageDriven with beans.xml caused the JAX-RS EJB support is disabled.

Comment by marina vatkina [ 03/Sep/13 ]

This seems very similar to https://java.net/jira/browse/GLASSFISH-20616





[GLASSFISH-17347] TLD scanning cannot find file because of path error Created: 26/Sep/11  Updated: 20/Dec/16  Resolved: 21/Oct/11

Status: Resolved
Project: glassfish
Component/s: web_container
Affects Version/s: 3.1.1_dev, 3.1.1, 3.1.2_dev
Fix Version/s: None

Type: Bug Priority: Major
Reporter: suttridge_farm Assignee: kchung
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Occurs on both Linux and Windows - Glassfish V3.1.0 onwards.


Tags: 3_1_x-exclude

 Description   

I have a couple of enterprise applications (.ear) that contain EJB and web applications (.war). The components of these applications reference external library jar files that are installed in the domains/domain1/lib/ext sub-directory. On deployment of the applications, the server log contains a lot of noise relating to TLD scanning as shown below :-

PWC6351: In TLD scanning, the supplied resource file:/home/steve/glassfishv3.1.2-b04/glassfish/domains/domain1/applications/SuprimaHSP/lib/lib/joda-time-2.0.jar does not exist
java.util.zip.ZipException: error in opening zip file
at java.util.zip.ZipFile.open(Native Method)
at java.util.zip.ZipFile.<init>(ZipFile.java:127)
at java.util.jar.JarFile.<init>(JarFile.java:135)
at java.util.jar.JarFile.<init>(JarFile.java:72)
at sun.net.www.protocol.jar.URLJarFile.<init>(URLJarFile.java:72)
at sun.net.www.protocol.jar.URLJarFile.getJarFile(URLJarFile.java:48)
at sun.net.www.protocol.jar.JarFileFactory.get(JarFileFactory.java:70)
at sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:104)
at sun.net.www.protocol.jar.JarURLConnection.getJarFile(JarURLConnection.java:71)
at org.apache.jasper.runtime.TldScanner.scanJar(TldScanner.java:438)
at org.apache.jasper.runtime.TldScanner.scanJars(TldScanner.java:689)
at org.apache.jasper.runtime.TldScanner.scanTlds(TldScanner.java:350)
at org.apache.jasper.runtime.TldScanner.onStartup(TldScanner.java:239)
at org.apache.catalina.core.StandardContext.callServletContainerInitializers(StandardContext.java:5467)
at com.sun.enterprise.web.WebModule.callServletContainerInitializers(WebModule.java:581)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:5363)
at com.sun.enterprise.web.WebModule.start(WebModule.java:498)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:917)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:901)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:733)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:2005)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1656)
at com.sun.enterprise.web.WebApplication.start(WebApplication.java:109)

The referenced file (joda-time-2.0.jar) is not going to be found where the TldScanner is looking for it, since it is in lib/ext, and is NOT packaged with the application. This error is reported for all external libraries that are referenced. This bug has been present since almost the beginning of Glassfish V3, and is still present in the latest 3.1.2-b04.

Regards,

Steve



 Comments   
Comment by suttridge_farm [ 26/Sep/11 ]

Sorry - should have made this a minor bug - not major.

Comment by kchung [ 21/Oct/11 ]

Currently, system jars that contains TLDs needs to provide an implementation of org.glassfish.api.web.TldProvider (which is not documented publicly, unfortunately). Otherwise the TLDs will not be scanned. This is essentially a performance measure, since scanning all system jars has proved to be very expensive.





[GLASSFISH-17345] LB doesn't work after stopping and starting cluster Created: 26/Sep/11  Updated: 21/Sep/15

Status: Open
Project: glassfish
Component/s: admin
Affects Version/s: 4.0
Fix Version/s: 4.1.1

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

MacOS


Attachments: File SimpleSessionDemo.war    
Tags: 3_1_x-exclude

 Description   

running in native mode with load balancer setup and deploy a web application. Web page comes up as expected. stop and then start the cluster and go to the web page and I get a 404.



 Comments   
Comment by Mahesh Kannan [ 26/Sep/11 ]

We have seen this behavior in native mode.

Steps to reproduce:

1. asadmin start-domain
2. deploy the attached SimpleSessionDemo.war
3. Access the app from browser (localhost:50080/SimpleSessionDemo/DemoServlet)
(The above works)
4. asadmin stop-cluster SimpleSessionDemo
5. asadmin start-cluster SimpleSessionDemo
6. Now try to access localhost:50080/SimpleSessionDemo/DemoServlet. THIS FAILS

Comment by prasads [ 18/Feb/13 ]

Moving this to 4.0.1 since the LB support is not available in 4.0





[GLASSFISH-17335] top-level directory in glassfish.zip file is glassfish3 even though the version contained therein is 4.0 Created: 22/Sep/11  Updated: 20/Dec/16  Resolved: 07/Mar/13

Status: Resolved
Project: glassfish
Component/s: packaging
Affects Version/s: None
Fix Version/s: 4.0_dev

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

Tags: 3_1_x-exclude

 Description   

The top-level directory in the glassfish.zip file is still glassfish3 even though the GlassFish version is now 4.0.



 Comments   
Comment by Snjezana Sevo-Zenzerovic [ 14/Oct/11 ]

Issue not applicable for 3.x releases.





[GLASSFISH-17331] Non-daemon threads prevent embedded EJB container from closing Created: 22/Sep/11  Updated: 02/Nov/11  Resolved: 22/Sep/11

Status: Resolved
Project: glassfish
Component/s: elasticity
Affects Version/s: 4.0
Fix Version/s: 4.0

Type: Bug Priority: Critical
Reporter: marina vatkina Assignee: Mahesh Kannan
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1_x-exclude

 Description   

The ElasticEngineThreadPool by default creates non-daemon threads. This prevents embedded EJB tests from exit without an explicit System.exit call.

To reproduce, do 'ant all' in devtests/ejb/ejb31/embedded/profile test



 Comments   
Comment by Mahesh Kannan [ 22/Sep/11 ]

Fixed. Embedded test result:

[java] -----------------------------------------
[java] - embedded with profile: PASS -
[java] -----------------------------------------
[java] Total PASS: 1
[java] Total FAIL: 0
[java] Total DID NOT RUN: 0
[java] -----------------------------------------
[java]
[java] ==> Spent on CALL: 13 msec
[java] Sep 21, 2011 7:47:00 PM org.glassfish.paas.orchestrator.ServiceOrchestratorImpl logEvent
[java] INFO: ServiceOrchestrator receiving event
[java]

{ [Before] [Phase : STOP] [Command : undeploy] [Origin : undeploy] }

[java] Sep 21, 2011 7:47:00 PM org.glassfish.paas.orchestrator.ServiceOrchestratorImpl logEvent
[java] INFO: ServiceOrchestrator receiving event
[java]

{ [After] [Phase : STOP] [Command : undeploy] [Origin : undeploy] }

[java] Sep 21, 2011 7:47:00 PM org.glassfish.paas.orchestrator.ServiceOrchestratorImpl logEvent
[java] INFO: ServiceOrchestrator receiving event
[java]

{ [Before] [Phase : UNLOAD] [Command : undeploy] [Origin : undeploy] }

[java] Sep 21, 2011 7:47:00 PM org.glassfish.paas.orchestrator.ServiceOrchestratorImpl logEvent
[java] INFO: ServiceOrchestrator receiving event
[java]

{ [After] [Phase : UNLOAD] [Command : undeploy] [Origin : undeploy] }

[java] Sep 21, 2011 7:47:00 PM org.glassfish.paas.orchestrator.ServiceOrchestratorImpl logEvent
[java] INFO: ServiceOrchestrator receiving event
[java]

{ [Before] [Phase : CLEAN] [Command : undeploy] [Origin : undeploy] }

[java] Sep 21, 2011 7:47:00 PM org.glassfish.paas.orchestrator.ServiceOrchestratorImpl logEvent
[java] INFO: ServiceOrchestrator receiving event
[java]

{ [After] [Phase : CLEAN] [Command : undeploy] [Origin : undeploy] }

[java] Sep 21, 2011 7:47:00 PM org.glassfish.admin.mbeanserver.JMXStartupService shutdown
[java] INFO: JMX001: JMXStartupService and JMXConnectors have been shut down.
[java] Sep 21, 2011 7:47:00 PM org.glassfish.admin.mbeanserver.JMXStartupService shutdown
[java] INFO: JMX001: JMXStartupService and JMXConnectors have been shut down.
[java] Sep 21, 2011 7:47:00 PM com.sun.enterprise.v3.server.AppServerStartup stop
[java] INFO: Shutdown procedure finished
[java]
[java] ==> Spent on CLOSE: 80 msec
[java]
[java] ==> Spent on TEST: 5979 msec
[java] in flushAll , creating new testSuiteHash





[GLASSFISH-17330] stop-local-instance appears to not stop instance in Windows devtests Created: 21/Sep/11  Updated: 13/Oct/11  Resolved: 30/Sep/11

Status: Resolved
Project: glassfish
Component/s: admin
Affects Version/s: 4.0
Fix Version/s: 4.0

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

Tags: 3_1_x-exclude

 Description   

The admin devtests (cluster module) on Windows are failing about a third of the time due to the following:

[java] asadmin --host localhost --port 4848 --user admin --passwordfile C:/files/hudson/workspace/admin-devtests-trunk-windows/appserv-tests/config/adminpassword.txt --interactive=false --echo=true --terse=true delete-local-instance infrai1
[java]
[java] The instance is running. Stop it and then re-run the command.

The command sequence here is:

stop-local-instance infrai1
stop-local-instance infrai2
stop-local-instance infrai3
delete-local-instance infrai1 <- this one fails.

The previous three stop's pass.

I don't know if the stop is actually failing even though stop-local-instance succeeded, or the delete-local-instance is incorrectly thinking the instance is up when it isn't.

We are only seeing this on Windows. It does not happen everytime.



 Comments   
Comment by Tom Mueller [ 29/Sep/11 ]

The root cause of this issue is PID reuse on Windows. To check whether the GF instance is still running, the GF code on Windows uses the "tasklist" command. Sometimes, the tasklist command gets the same PID as the server that has already been stopped.

One partial solution to this problem is to verify that the process that is running is a "java.exe" process. If it isn't then the process isn't the GF instance.

Another possible solution is to use wmic rather than tasklist to get the process information. wmic allows one to get the process creation time. This value could be compared to the timestamp of the "pid.prev" file that is created by the server. If the creation time is after the time that file was written, then that process is not the GF instance. However, wmic is not available on all editions of Windows, specifically the Home edition.

Comment by Tom Mueller [ 29/Sep/11 ]

A preliminary fix which just checks that the process is a "java.exe" process has been checked into the trunk in revision 50045.

Comment by Tom Mueller [ 30/Sep/11 ]

Marking this as resolved.

Comment by Tom Mueller [ 13/Oct/11 ]

Adding the 3_1_x-exclude tag. This was found only in devtests on Windows and has not been reported by any customer. Unless running delete-local-instance in a script, it is highly unlikely that anyone would see this.
This doesn't meet the criteria for fixing in a minor release.





[GLASSFISH-17326] Nucleus class DeploymentUtils has Java EE references Created: 20/Sep/11  Updated: 20/Dec/16  Resolved: 26/Jul/12

Status: Resolved
Project: glassfish
Component/s: deployment
Affects Version/s: 4.0
Fix Version/s: 4.0_dev

Type: Bug Priority: Major
Reporter: Tom Mueller Assignee: Hong Zhang
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to GLASSFISH-18329 Deployment/kernel cleanup - Phase 4: ... Open
Tags: 3_1_x-exclude, nucleus-cleanup

 Description   

The DeploymentUtils class which resides in nucleus contains references to the Java EE deployment descriptor file names and other Java EE references, including an isJavaEE method. These need to be refactored.



 Comments   
Comment by Hong Zhang [ 17/Oct/11 ]

This is part of the nucleus clean up work for BG.

Comment by Hong Zhang [ 26/Apr/12 ]

Some progress made this week related to this:

1. Remove javax.enterprise.deploy dependency from nucleus distribution (deployment-common module). Move various methods of getting archive types from DeploymentUtils to DOLUtils and update the classes referencing the methods.

2. Have the archive handlers be responsible for returning the associated class path URLs for the archive instead of having the DeploymentUtils class do it for them. Add an ArchiveHandler.getClassPathURIs API for each archive handler to return its corresponding class path URLs and move out the relevant logic from DeploymentUtils (deploymenmt-common module) and SnifferManagerImpl (core-kernel module).

Comment by Sanjeeb Sahoo [ 27/Apr/12 ]

1. Pl. reference svn revision no. in JIRA and mention JIRA ids in svn comments wherever possible.
2. This task should either be closed or set as a child of GLASSFISH-18329

Comment by Hong Zhang [ 26/Jul/12 ]

Replace various isXXX methods with generic isArchiveOfType methods (one takes a DeploymentContext when it's applicable for optimization, and one does not for the case where DeploymentContext is not available from the calling code) to remove Java EE dependencies from DeploymentUtils. The container specific logic are moved to the corresponding container modules.

Committed svn version: svn 55221

Comment by Sanjeeb Sahoo [ 26/Jul/12 ]

Very nice. Thank you, Hong.





[GLASSFISH-17325] Application config bean has sniffer strings Created: 20/Sep/11  Updated: 20/Dec/16  Resolved: 08/Aug/12

Status: Resolved
Project: glassfish
Component/s: deployment
Affects Version/s: None
Fix Version/s: 4.0_dev

Type: Bug Priority: Major
Reporter: Tom Mueller Assignee: Hong Zhang
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1_x-exclude, nucleus-cleanup

 Description   

The Application config bean contains a list of Sniffer types (text strings). Since Sniffers can be defined by any container, there shouldn't be a list of Sniffer type text strings in nucleus.



 Comments   
Comment by Hong Zhang [ 17/Oct/11 ]

This is part of the nucleus clean up work for BG.

Comment by Hong Zhang [ 08/Aug/12 ]

Removed Sniffer Strings from Application config bean, svn revision 17325.





[GLASSFISH-17324] Nucleus cleanup: admin console start page Created: 20/Sep/11  Updated: 20/Dec/16

Status: Open
Project: glassfish
Component/s: admin_gui
Affects Version/s: 4.0_dev
Fix Version/s: future release

Type: Bug Priority: Major
Reporter: Tom Mueller Assignee: Anissa Lam
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
is duplicated by GLASSFISH-20465 Nucleus doesn't open admin console Resolved
Tags: 3_1_x-exclude, nucleus-cleanup

 Description   

When port 4848 is accessed on nucleus, the "admin console is loaded" page is shown, but then there is no admin console because nucleus doesn't have one.

After some discussion, the decision was made to keep the AdminConsoleAdapter in nucleus, but to do the following:

1. Modify the messages that are output from nucleus to indicate that there is no admin console. The "console loading" page should only been shown when there is a console that is being loaded. Or, if there is no console configured, then the AdminConsoleAdapter should not be configured at all, thereby resulting in nucleus displaying the default index.html page when http://host:484/ is accessed.

2. Modify the default configuration for nucleus so that there is no admin console configured.

3. Document the configuration data values related to the AdminConsoleAdapter. This should include information about how an admin console application can be installed and configured into nucleus. This documentation should allow a developer that is using nucleus to add a console to it.

4. Either remove the admin console upgrade code from nucleus or move it to appserver. Nucleus should not automatically configure an admin console.



 Comments   
Comment by Anissa Lam [ 11/Feb/13 ]

This issue involves different group, not just admin console.
I am marking this for MS6 for now. Will work with other team to get this addressed.

Comment by Anissa Lam [ 12/Feb/13 ]

Fix by HCF (3/25)

Comment by Anissa Lam [ 12/Feb/13 ]

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

Comment by Anissa Lam [ 12/Feb/13 ]

This is nucleus cleanup, defer to 4.0.1 according to the bug scrubbing guideline.





[GLASSFISH-17296] Remove sun-domain DTD files Created: 14/Sep/11  Updated: 13/Oct/11  Resolved: 14/Sep/11

Status: Resolved
Project: glassfish
Component/s: admin
Affects Version/s: None
Fix Version/s: 4.0

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

Tags: 3_1_x-exclude, nucleus-cleanup

 Description   

The sun-domain DTD files are no longer uses since the GlassFish v3 schema is determined by the config beans rather than a DTD. These DTD files can be removed now along with code that references them.



 Comments   
Comment by Tom Mueller [ 14/Sep/11 ]

Fixed on the trunk.

Comment by Tom Mueller [ 13/Oct/11 ]

Marking with the 3_1_x-exclude tag. This is a 4.0-only fix.





[GLASSFISH-17294] Server.isRunning() should not hang if instance system (machine) is down Created: 13/Sep/11  Updated: 20/Dec/16  Resolved: 30/Dec/11

Status: Resolved
Project: glassfish
Component/s: admin
Affects Version/s: 3.1.1, 4.0
Fix Version/s: 4.0_dev

Type: Bug Priority: Major
Reporter: Joe Di Pol Assignee: Byron Nevins
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1_x-exclude

 Description   

If a machine is down then Server.isRunning() can hang when it tests to see if an instance on that machine is running. This may become more common as we add IaaS support to GlassFish with instances running on virtual machines. The current behavior for stop-instance is to shutdown the virtual machine the instance is running on (if there is one). Once in this state any command that calls Server.isRunning() (like list-instances) on the instance will hang for a period of time waiting for the test connection to timeout.

I'm not sure there is a quick/efficient mechanism for determining if a remote machine is up or down. The ping command can also suffer from the timeout problem. One option is to reduce the connection timeout. Another would be to have Server.isRunning() check via IMS if the instance's virtual machine is up or down (assuming it somehow knows the instance is running on a virtual machine).



 Comments   
Comment by Tom Mueller [ 13/Sep/11 ]

Byron, is there anything we can do about this?

Comment by Byron Nevins [ 24/Oct/11 ]

Please no UTLA's in bug reports!

Comment by Tom Mueller [ 24/Oct/11 ]

IMS = IaaS Management Service

Comment by Byron Nevins [ 30/Dec/11 ]

I just looked at the code for Server.isRunning()

It's simple. It merely creates a socket (new Socket(host,port)).
If that throws an Exception – then it returns false. Otherwise it closes the socket and returns true.

Also this is ambiguous in the problem description:

"remote machine is down"

Machine is powered off?
GF server isn't running?

Comment by Byron Nevins [ 30/Dec/11 ]

It's astoundingly easy to run throw-away code in NetUtils. Add a few lines to the main method then "debug file" in NetBeans. You're instantly stepping through the code.

I tried 2 different kinds of "down"

(1) fake IP address pointing at nothing: 22 second timeout then returns false.
(2) valid address, fake port (11234): immediately returns false.

Comment by Byron Nevins [ 30/Dec/11 ]

I changed it to a 3 second timeout.
I also added a new isRunning method that takes a timeout option.

Tests:

Fake IP Address – no machine at that address – takes 3 sec
isRunning says: false for 10.0.0.5, 1234, 3005

Real machine, ports not in use:
isRunning says: false for adc6140387, 4848, 1281
isRunning says: false for adc6140387, 11234, 1289
isRunning says: false for improvident, 11234, 1155

Real machine, GF listening on those ports.
isRunning says: true for improvident, 8080, 65
isRunning says: true for improvident, 4848, 62

Note how when it returns true the time is ~~ 2% of the timeout. So three seconds should be safe.

The default timeout can be easily changed.

The default JDK timeout is 22 seconds on my machine.

JOE - This fix can easily be applied to 3.1.2 if you like.

Sending common-util\src\main\java\com\sun\enterprise\util\net\NetUtils.java
Transmitting file data .
Committed revision 51831.

Comment by Joe Di Pol [ 30/Dec/11 ]

Let's not port this to 3.1.2. I have not seen customers complain about this. It shows up more with 4.0 because stopping a virtual cluster results in the virtual machines being shutdown (not just the GF instance shut down).





[GLASSFISH-17282] Got "EJB Container initialization error" when deploy a WLS QA ejb test application to GlassFish Created: 08/Sep/11  Updated: 13/Dec/12

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: 4.0
Fix Version/s: None

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

windowsXP


Attachments: Text File server.log     File SimpleSFSBean.ear    
Tags: 3_1_x-exclude

 Description   

P.S. File the bug as per management's request.

I tried to deploy the attached WLS QA ejb test application to Glassfish v3.1.1 and it failed to deploy. And the same ear file was successfully deployed to Weblogic server.
I got the following error when deploying the app.
Error occurred during deployment: Exception while loading the app : EJB Container initialization error. Please see server.log for more details.

The server.log displayed the following exceptions:
----------------------------------------------------

[#|2011-09-08T13:50:21.531-0700|SEVERE|glassfish3.1.1|javax.enterprise.system.tools.deployment.org.glassfish.deployment.common|_ThreadID=25;_ThreadName=Thread-2;|Exception while invoking class org.glassfish.ejb.startup.EjbDeployer load method
java.lang.RuntimeException: EJB Container initialization error
at org.glassfish.ejb.startup.EjbApplication.loadContainers(EjbApplication.java:242)
at org.glassfish.ejb.startup.EjbDeployer.load(EjbDeployer.java:290)
at org.glassfish.ejb.startup.EjbDeployer.load(EjbDeployer.java:101)
at org.glassfish.internal.data.ModuleInfo.load(ModuleInfo.java:186)
at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:257)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:461)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:240)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:382)
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:1064)
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 org.glassfish.admin.rest.ResourceUtil.runCommand(ResourceUtil.java:202)
at org.glassfish.admin.rest.ResourceUtil.runCommand(ResourceUtil.java:195)
at org.glassfish.admin.rest.resources.TemplateListOfResource.createResource(TemplateListOfResource.java:148)
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.jersey.spi.container.JavaMethodInvokerFactory$1.invoke(JavaMethodInvokerFactory.java:60)
at com.sun.jersey.server.impl.model.method.dispatch.AbstractResourceMethodDispatchProvider$ResponseOutInvoker._dispatch(AbstractResourceMethodDispatchProvider.java:205)
at com.sun.jersey.server.impl.model.method.dispatch.ResourceJavaMethodDispatcher.dispatch(ResourceJavaMethodDispatcher.java:75)
at com.sun.jersey.server.impl.uri.rules.HttpMethodRule.accept(HttpMethodRule.java:288)
at com.sun.jersey.server.impl.uri.rules.SubLocatorRule.accept(SubLocatorRule.java:134)
at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
at com.sun.jersey.server.impl.uri.rules.SubLocatorRule.accept(SubLocatorRule.java:134)
at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
at com.sun.jersey.server.impl.uri.rules.ResourceClassRule.accept(ResourceClassRule.java:108)
at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
at com.sun.jersey.server.impl.uri.rules.RootResourceClassesRule.accept(RootResourceClassesRule.java:84)
at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1469)
at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1400)
at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1349)
at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1339)
at com.sun.jersey.server.impl.container.grizzly.GrizzlyContainer._service(GrizzlyContainer.java:182)
at com.sun.jersey.server.impl.container.grizzly.GrizzlyContainer.service(GrizzlyContainer.java:147)
at org.glassfish.admin.rest.adapter.RestAdapter.service(RestAdapter.java:184)
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:828)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:725)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1019)
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)
Caused by: java.lang.RuntimeException: Error while binding JNDI name wlstest.functional.ejb30.session.clientview.common.apps.stateful.annotated.HelperSFSRemoteIntf#wlstest.functional.ejb30.session.clientview.common.apps.stateful.annotated.HelperSFSRemoteIntf for EJB : HelperSFS
at com.sun.ejb.containers.BaseContainer.initializeHome(BaseContainer.java:1550)
at com.sun.ejb.containers.StatefulSessionContainer.initializeHome(StatefulSessionContainer.java:217)
at com.sun.ejb.containers.ContainerFactoryImpl.createContainer(ContainerFactoryImpl.java:167)
at org.glassfish.ejb.startup.EjbApplication.loadContainers(EjbApplication.java:230)
... 55 more
Caused by: javax.naming.NameAlreadyBoundException: Use rebind to override
at com.sun.enterprise.naming.impl.TransientContext.doBindOrRebind(TransientContext.java:333)
at com.sun.enterprise.naming.impl.TransientContext.bind(TransientContext.java:268)
at com.sun.enterprise.naming.impl.SerialContextProviderImpl.bind(SerialContextProviderImpl.java:98)
at com.sun.enterprise.naming.impl.LocalSerialContextProviderImpl.bind(LocalSerialContextProviderImpl.java:99)
at com.sun.enterprise.naming.impl.SerialContext.bind(SerialContext.java:672)
at com.sun.enterprise.naming.impl.SerialContext.bind(SerialContext.java:689)
at javax.naming.InitialContext.bind(InitialContext.java:404)
at javax.naming.InitialContext.bind(InitialContext.java:404)
at com.sun.enterprise.naming.impl.GlassfishNamingManagerImpl.publishObject(GlassfishNamingManagerImpl.java:208)
at com.sun.enterprise.naming.impl.GlassfishNamingManagerImpl.publishObject(GlassfishNamingManagerImpl.java:189)
at com.sun.ejb.containers.BaseContainer$JndiInfo.publish(BaseContainer.java:5607)
at com.sun.ejb.containers.BaseContainer.initializeHome(BaseContainer.java:1535)
... 58 more

#]
-------------------------------
The server.log is attached.


 Comments   
Comment by sonialiu [ 08/Sep/11 ]

The following lines in the server.log:

011-09-08T13:49:23.187-0700|INFO|glassfish3.1.1|org.glassfish.admingui|_Thre
=22;_ThreadName=Thread-2;|uploadFileName=SimpleSFSBean.ear|#]

011-09-08T13:49:23.812-0700|WARNING|glassfish3.1.1|javax.enterprise.system.t
.deployment.org.glassfish.deployment.common|_ThreadID=24;_ThreadName=Thread-
gnore META-INF/weblogic-ejb-jar.xml as it is not supported in this release.|

Does this mean we don't support weblogic-ejb-jar.xml in GF V3.1.1?

Comment by Cheng Fang [ 12/Sep/11 ]

Yes, weblogic-ejb-jar.xml is not supported in GlassFish 3.x.

Comment by Cheng Fang [ 21/Sep/11 ]

Since weblogic-ejb-jar.xml is ignored and so any product-specific jndi names will not take effect.

Meanwhile, if we configure GlassFish to disable product-specific jndi names, the test app deploys fine:

asadmin set server.ejb-container.property.disable-nonportable-jndi-names="true"

Comment by Cheng Fang [ 04/Nov/11 ]

Sonia, did the solution in my last comment work?

Comment by sonialiu [ 08/Nov/11 ]

As suggested, after set the server.ejb-container.property.disable-nonportable-jndi-names="true", I could deploy the app successfully. However, we might have to decide if BG will support the weblogic-ejb-jar.xml in the future.

Comment by Cheng Fang [ 08/Nov/11 ]

Thanks Sonia for verifying it. Added 3_1_x-exclude tag to exclude it from 3.1.x.





[GLASSFISH-17273] asadmin delete-cluster does not delete elastic-service Created: 06/Sep/11  Updated: 02/Dec/11  Resolved: 12/Oct/11

Status: Resolved
Project: glassfish
Component/s: elasticity
Affects Version/s: 4.0
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: Amy Roh Assignee: carlavmott
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1_x-exclude

 Description   

asadmin delete-cluster does not delete elastic-service config so subsequent create-cluster with the same name will fail with "A ElasticService instance with a "clusterA" name already exist in the configuration|"

asadmin create-cluster clusterA
asadmin delete-cluster clusterA

I still see the following elastic-service in the domain.xml

<elastic-services>
<elastic-service name="clusterA">
<metric-gatherers>
<metric-gatherer name="memory"></metric-gatherer>
</metric-gatherers>
<actions>
<scale-up-action name="scale-up-action"></scale-up-action>
</actions>
</elastic-service>
</elastic-services>

and subsequent create-cluster clusterA will fail

[#|2011-09-06T14:02:51.624-0700|SEVERE|glassfish3.2|javax.enterprise.system.tools.admin.org.glassfish.config.support|_ThreadID=12;_ThreadName=Thread-2;|A ElasticService instance with a "clusterA" name already exist in the configuration|#]

[#|2011-09-06T14:02:51.626-0700|SEVERE|glassfish3.2|javax.enterprise.system.tools.admin.org.glassfish.config.support|_ThreadID=12;_ThreadName=Thread-2;|Exception while adding the new configuration : A ElasticService instance with a "clusterA" name already exist in the configuration|#]

[#|2011-09-06T14:02:51.626-0700|SEVERE|glassfish3.2|javax.enterprise.system.tools.admin.org.glassfish.config.support|_ThreadID=12;_ThreadName=Thread-2;|Exception while adding the new configuration : Can not create elastic config info|#]



 Comments   
Comment by Tom Mueller [ 08/Sep/11 ]

Increasing the priority of this issue because it is causing the admin devtests to fail.

Comment by carlavmott [ 12/Oct/11 ]

I moved the elasticity elements out of the cluster element since it did not belong there.





[GLASSFISH-17266] custom resource factory cannot access webmodule during lifecycle events Created: 01/Sep/11  Updated: 21/Oct/11

Status: Open
Project: glassfish
Component/s: jca
Affects Version/s: v2.1
Fix Version/s: None

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

jdk6,winxp


Attachments: Zip Archive NetBeansProjects.zip    
Tags: 3_1_x-exclude

 Description   

When one has a custom factory class deployed under domain/lib and a resource is created which uses this factory to create an injectable class located in a webapp, then the following (or similar) exception is thrown during appserver startup:

javax.naming.CommunicationException: serial context communication ex [Root exception is java.lang.ClassNotFoundException: a.Config]
at com.sun.enterprise.naming.SerialContext.lookup(SerialContext.java:438)
at javax.naming.InitialContext.lookup(InitialContext.java:392)
at com.sun.enterprise.naming.NamingManagerImpl.bindObjects(NamingManagerImpl.java:391)
at com.sun.enterprise.web.WebModuleContextConfig.configureResource(WebModuleContextConfig.java:227)
at com.sun.enterprise.web.WebModuleContextConfig.lifecycleEvent(WebModuleContextConfig.java:167)
at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:159)
at org.apache.catalina.core.StandardContext.init(StandardContext.java:6476)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:4977)
at com.sun.enterprise.web.WebModule.start(WebModule.java:353)
at com.sun.enterprise.web.LifecycleStarter.doRun(LifecycleStarter.java:58)
at com.sun.appserv.management.util.misc.RunnableBase.runSync(RunnableBase.java:304)
at com.sun.appserv.management.util.misc.RunnableBase.run(RunnableBase.java:341)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
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.ClassNotFoundException: a.Config
at com.sun.enterprise.util.ConnectorClassLoader.loadClass(ConnectorClassLoader.java:222)
at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
at a.ConfigFactory.getObjectInstance(ConfigFactory.java:21)
at javax.naming.spi.NamingManager.getObjectInstance(NamingManager.java:304)
at com.sun.enterprise.naming.SerialContext.lookup(SerialContext.java:414)
... 17 more

The cause is that when the LifecycleStarter task is created in VirtualServer then the current thread's contextClassLoader is the ConnectorClassLoader and so that's the one which gets inherited by the RunnableBase.

I think if an injectable resource class is allowed to be local to a webapp then the appropriate classLoader should be utilized when doing any kind of work with the factories.

Proposed solution: VirtualServer might set the current thread's contextClassLoader to the webapp's loader every time it creates a runnable task for a WebModule and then set it back to the old value.

Couldn't reproduce it in v3.1. Attached are the factory jar under domain/lib and the webapp and here's the resource entry in domain.xml:

<custom-resource enabled="true" factory-class="a.ConfigFactory" jndi-name="testconfig" object-type="user" res-type="a.Config"/>



 Comments   
Comment by Sanjeeb Sahoo [ 20/Oct/11 ]

This bug is not applicable for 3.1 from what I understand from submitter's note.

Comment by Jagadish [ 21/Oct/11 ]

https://svn.java.net/svn/glassfish~svn/trunk/v2/appserv-tests/devtests/connector/v3/built-in-custom-resources
Above test-case that has a custom resource's factory which loads the JavaBean class copied in domain/lib directory, works fine in GlassFish 3.0 and above.

Marking as not applicable for 3.x and above.

Comment by Jagadish [ 21/Oct/11 ]

Transferring to Gajanan for evaluation in GlassFish 2.x.
Gajanan: Please transfer to appropriate team member.





[GLASSFISH-17261] [regression] NPE in DOL during processing of web fragments Created: 31/Aug/11  Updated: 19/Oct/11  Resolved: 01/Sep/11

Status: Resolved
Project: glassfish
Component/s: deployment
Affects Version/s: 4.0
Fix Version/s: 4.0

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

Tags: 3_1_x-exclude

 Description   

Starting with svn rev#49133, I am seeing following failure while deploying WAB withs web fragments. After analysing the stack trace, I am convinced that this problem should occur for regular apps with web fragments as well. See the exception below:

Exception while deploying the app [org.glassfish.fighterfish.test.app12_1.0.0.SNAPSHOT] 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 Caused by: java.lang.NullPointerException at com.sun.enterprise.deployment.archivist.Archivist.postValidate(Archivist.java:1778) at com.sun.enterprise.deployment.archivist.WebFragmentArchivist.postOpen(WebFragmentArchivist.java:141) at com.sun.enterprise.deployment.archivist.WebFragmentArchivist.postOpen(WebFragmentArchivist.java:68) at com.sun.enterprise.deployment.archivist.Archivist.open(Archivist.java:245) at com.sun.enterprise.deployment.archivist.Archivist.open(Archivist.java:252) at com.sun.enterprise.deployment.archivist.Archivist.open(Archivist.java:213) at com.sun.enterprise.deployment.archivist.WebArchivist.readStandardFragments(WebArchivist.java:413) at com.sun.enterprise.deployment.archivist.WebArchivist.postAnnotationProcess(WebArchivist.java:349) at com.sun.enterprise.deployment.archivist.WebArchivist.postAnnotationProcess(WebArchivist.java:90) at com.sun.enterprise.deployment.archivist.Archivist.readRestDeploymentDescriptors(Archivist.java:406) at com.sun.enterprise.deployment.archivist.Archivist.readDeploymentDescriptors(Archivist.java:380) at com.sun.enterprise.deployment.archivist.Archivist.open(Archivist.java:243) at com.sun.enterprise.deployment.archivist.Archivist.open(Archivist.java:252) at com.sun.enterprise.deployment.archivist.Archivist.open(Archivist.java:213) at com.sun.enterprise.deployment.archivist.ApplicationFactory.openArchive(ApplicationFactory.java:165) at org.glassfish.javaee.core.deployment.DolProvider.load(DolProvider.java:177) at org.glassfish.javaee.core.deployment.DolProvider.load(DolProvider.java:87) at com.sun.enterprise.v3.server.ApplicationLifecycle.loadDeployer(ApplicationLifecycle.java:859) at com.sun.enterprise.v3.server.ApplicationLifecycle.setupContainerInfos(ApplicationLifecycle.java:801) at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:375) at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:245) at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.deploy(OSGiDeploymentRequest.java:183) ... 12 more |#]

Watch http://gf-hudson.us.oracle.com/hudson/job/gf-trunk-fighterfish-it/600/. After fixing this, make sure this job returns to green.



 Comments   
Comment by Hong Zhang [ 31/Aug/11 ]

Can you attach the archive so it's easier for me to reproduce/verify the fix? Thanks!

Comment by Hong Zhang [ 31/Aug/11 ]

Looking at the line where the NPE happens:

ComponentPostVisitor postVisitor = habitat.getComponent(ComponentPostVisitor.class);

so the habitat is somehow null in this scenario? Is that expected?

Comment by Hong Zhang [ 31/Aug/11 ]

Further investigation shows the cause of the NPE: WebFragmentArchivist is not a Service class as other archivists, so the injection of Habitat in its super class Archivist does not work for it. Will follow up with Shingwai on this to see if we can change it to a Service class or get to habitat through another way.

Comment by Hong Zhang [ 01/Sep/11 ]

Fixed the issue by passing in the habitat through the constructor of the WebFragmentArchivist. The hudson job is now blue.

Comment by Hong Zhang [ 17/Oct/11 ]

This regression only happened in trunk and is not applicable to 3.1.* branch.

Comment by shreedhar_ganapathy [ 19/Oct/11 ]

Updated fixVersion to 4.0

Comment by shreedhar_ganapathy [ 19/Oct/11 ]

affectsVersion changed to 4.0





[GLASSFISH-17253] [osgi/ee-resources] osgi-ee-resources module does not work with GlassFish 4.0 builds Created: 30/Aug/11  Updated: 20/Dec/16  Resolved: 11/Mar/13

Status: Resolved
Project: glassfish
Component/s: jca, OSGi-JavaEE
Affects Version/s: 4.0
Fix Version/s: 4.0_dev

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

Tags: 3_1_2_exclude, 3_1_x-exclude

 Description   

Currently, due to a config refactoring, osgi-ee-resources module is disabled as a new maven promotion is needed.
This seems to be possible only after a 4.0 build promotion and the artifacts are published in maven repository. Raising this placeholder issue.



 Comments   
Comment by Sanjeeb Sahoo [ 08/Dec/11 ]

I see an osgi-ee-resources.jar in modules/autostart in 3.1.2 build. Is that jar not working then? Or, did you mean to file this bug against trunk?

Comment by Jagadish [ 08/Dec/11 ]

This issue was originally raised against 3.1.2 though it was meant only for trunk (4.0). Hence updated the descriptions, synopsis and tags accordingly.
osgi-ee-resources works fine in 3.1.2

Comment by Sanjeeb Sahoo [ 25/Jun/12 ]

While making this change in osgi-ee-resources module, please make sure to increase the major version of osgi-ee-resources module to mark it as an incompatible release.

Comment by Jagadish [ 06/Feb/13 ]

Transferring to Naman who is working on this issue.

Comment by Sanjeeb Sahoo [ 11/Mar/13 ]

Integrated osgi-ee-resources:2.0.0 in svn rev #60348





[GLASSFISH-17241] list-probes is not showing all probes! Created: 25/Aug/11  Updated: 26/Oct/11

Status: Open
Project: glassfish
Component/s: monitoring
Affects Version/s: 3.1.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Byron Nevins Assignee: Jennifer Chou
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1_x-exclude

 Description   

I want the 2 hours that I spent figuring this out back!

1) create these probes:

@Probe(name = "thisistorture")
public void torture(String s) {
}

@Probe(name = "thisistorture2")
public void torture(String[] ss) {
}

2) run list-probes
– the first will appear and the second will NOT. It has nothing to do with the name. Adding
@ProbeParam("nicename")
has no effect.

I finally figured this out by running MonApp – which shows that both Probes are really there.

I stepped through the Flashlight registration code. Everything worked perfectly.

String[] are a problem for list-probes.
int[] is NOT a problem



 Comments   
Comment by Jennifer Chou [ 26/Oct/11 ]

I checked that we don't have existing probes with params of String[] so 3.1.x is not affected. Added the 3_1_x-exclude tag.





[GLASSFISH-17223] System properties differ in config vs cluster and prevent proper jms startup Created: 23/Aug/11  Updated: 20/Dec/16  Resolved: 19/Apr/12

Status: Resolved
Project: glassfish
Component/s: jms
Affects Version/s: 3.1.1
Fix Version/s: 4.0_dev

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

Glassfish 3.1.1 open source release. Java version 1.6.0_26 64 bit. SLES 11.


Attachments: XML File domain.xml     Text File log.txt     Text File server.log    
Tags: 3_1_x-exclude

 Description   

I created a cluster using asadmin create-cluster and passed in system properties using the -systemproperties option. When I log in to the admin console and navigate to Clusters>[cluster name]>Properties I see the property values that I set on the command line. However, if I navigate to Configurations>[cluster name]config>System Properties I see the property values that were present in default-config instead of the ones that I passed in on the command line.

It seems that for the most part this doesn't really matter, and the properties that I see when looking at the cluster are the ones that are getting used. However, things get strange with JMS and it causes a problem. In my configuration I am using embedded JMS. When the brokers try to start I can see that they are passed the JMS_PROVIDER_PORT that is specified under the cluster itself for the port that they should listen on, but they are passed the port that is specified under the config as part of the address list of brokers in the cluster. As a result, they try to connect to the wrong port and never start up properly.



 Comments   
Comment by Satish Kumar [ 14/Dec/11 ]

I tried reproducing this with a setup that is similar to what you have described above, but I am seeing the issue reported above. Can you please attach the domain.xml for your setup along with the GlassFish server.log and the broker logs to help investigate this further?

Comment by sarnoth [ 28/Dec/11 ]

Here are the files you requested. The cluster Test2 is one that I created to demonstrate the bug. The server log and broker log are from the instance Test2-1 of this cluster. I created the cluster with this command:

asadmin --port 2448 create-cluster --systemproperties ASADMIN_LISTENER_PORT=23548:HTTP_LISTENER_PORT=23580:HTTP_SSL_LISTENER_PORT=23581:IIOP_LISTENER_PORT=23537:IIOP_SSL_LISTENER_PORT=23538:IIOP_SSL_MUTUALAUTH_PORT=23539:JAVA_DEBUGGER_PORT=23509:JMS_PROVIDER_PORT=23576:JMX_SYSTEM_CONNECTOR_PORT=23586:OSGI_SHELL_TELNET_PORT=23566 --properties GMS_MULTICAST_TIME_TO_LIVE=10:GMS_TCPSTARTPORT=23600:GMS_TCPENDPORT=23699 --multicastaddress 239.193.205.5 --multicastport 23501 Test2

This is a fresh test using version 3.1.2 b15 to confirm that the bug still exists. In the domain.xml you will also see a cluster named Test1. This is a cluster created like Test2, but I have edited the system properties in Test1-config to make them match what I passed on the command line during creation. JMS works correctly for Test1 but not for Test2.

Comment by David Zhao [ 19/Apr/12 ]

This has been fixed.

Revision:
53574
Time:
04/19/2012 04:11 PM
Author:
liang.x.zhao@oracle.com
Path:
main/appserver/jms/jms-core/src/main/java/com/sun/enterprise/connectors/jms/util/JmsRaUtil.java (trunk)
Message:
Fix GLASSFISH-17223. Add logic to read cluster system property JMS_PROVIDER_PORT when composing MQ url.





[GLASSFISH-17220] Remote clients cannot list global JNDI "jdbc" subcontext due to java.io.OptionalDataException Created: 22/Aug/11  Updated: 21/Sep/15

Status: Open
Project: glassfish
Component/s: naming
Affects Version/s: 3.1.1
Fix Version/s: 4.1.1

Type: Bug Priority: Major
Reporter: al130959 Assignee: lemon_zhang
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1_x-exclude, 4_0_1-reviewed

 Description   

With GF 3.1.1 default setup, i.e. global JNDI "jdbc" subcontext containing the following entries:

jdbc/__TimerPool
jdbc/__default
jdbc/sample

trying to do the following from a remote client:

Context ctx = new InitialContext(env);
ctx.list("jdbc");

or

Context ctx = new InitialContext(env);
ctx.listBindings("jdbc");

produces the following fatal result:

Aug 22, 2011 7:57:12 PM com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator handleFullLogging
WARNING: IOP00810011: Exception from readValue on ValueHandler in CDRInputStream
org.omg.CORBA.MARSHAL: WARNING: IOP00810011: Exception from readValue on ValueHandler in CDRInputStream vmcid: OMG minor code: 11 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 $Proxy24.valuehandlerReadException(Unknown Source)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.readRMIIIOPValueType(CDRInputStream_1_0.java:1022)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_value(CDRInputStream_1_0.java:1123)
at com.sun.corba.ee.impl.encoding.CDRInputObject.read_value(CDRInputObject.java:531)
at com.sun.corba.ee.impl.io.IIOPInputStream.inputObjectField(IIOPInputStream.java:2162)
at com.sun.corba.ee.impl.io.IIOPInputStream.inputClassFields(IIOPInputStream.java:2404)
at com.sun.corba.ee.impl.io.IIOPInputStream.inputObject(IIOPInputStream.java:1224)
at com.sun.corba.ee.impl.io.IIOPInputStream.simpleReadObject(IIOPInputStream.java:425)
at com.sun.corba.ee.impl.io.ValueHandlerImpl.readValueInternal(ValueHandlerImpl.java:308)
at com.sun.corba.ee.impl.io.ValueHandlerImpl.readValue(ValueHandlerImpl.java:274)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.readRMIIIOPValueType(CDRInputStream_1_0.java:1015)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_value(CDRInputStream_1_0.java:1123)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_value(CDRInputStream_1_0.java:935)
at com.sun.corba.ee.impl.encoding.CDRInputObject.read_value(CDRInputObject.java:525)
at com.sun.corba.ee.impl.corba.TCUtility.unmarshalIn(TCUtility.java:289)
at com.sun.corba.ee.impl.corba.AnyImpl.read_value(AnyImpl.java:605)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_any(CDRInputStream_1_0.java:775)
at com.sun.corba.ee.impl.encoding.CDRInputObject.read_any(CDRInputObject.java:482)
at com.sun.corba.ee.impl.javax.rmi.CORBA.Util.readAny(Util.java:452)
at com.sun.corba.ee.impl.presentation.rmi.DynamicMethodMarshallerImpl$10.read(DynamicMethodMarshallerImpl.java:299)
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.enterprise.naming.impl._SerialContextProvider_DynamicStub.lookup(com/sun/enterprise/naming/impl/_SerialContextProvider_DynamicStub.java)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:505)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at com.sun.enterprise.naming.impl.SerialContext.listBindings(SerialContext.java:866)
at javax.naming.InitialContext.listBindings(InitialContext.java:447)
at remotejndilookuptest.RemoteJNDILookupTest.main(RemoteJNDILookupTest.java:24)
Caused by: java.io.OptionalDataException
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.impl.io.IIOPInputStream.createOptionalDataException(IIOPInputStream.java:245)
at com.sun.corba.ee.impl.io.IIOPInputStream.handleOptionalDataMarshalException(IIOPInputStream.java:944)
at com.sun.corba.ee.impl.io.IIOPInputStream.readObjectDelegate(IIOPInputStream.java:393)
at com.sun.corba.ee.impl.io.IIOPInputStream.readObjectOverride(IIOPInputStream.java:544)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:344)
at java.util.HashMap.readObject(HashMap.java:1030)
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.corba.ee.impl.io.IIOPInputStream.invokeObjectReader(IIOPInputStream.java:1832)
at com.sun.corba.ee.impl.io.IIOPInputStream.inputObject(IIOPInputStream.java:1214)
at com.sun.corba.ee.impl.io.IIOPInputStream.simpleReadObject(IIOPInputStream.java:425)
at com.sun.corba.ee.impl.io.ValueHandlerImpl.readValueInternal(ValueHandlerImpl.java:308)
at com.sun.corba.ee.impl.io.ValueHandlerImpl.readValue(ValueHandlerImpl.java:274)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.readRMIIIOPValueType(CDRInputStream_1_0.java:1015)
... 28 more
Caused by: org.omg.CORBA.MARSHAL: FINE: IOP00800008: Not enough optional data available vmcid: SUN minor code: 8 completed: No
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 $Proxy27.rmiiiopOptionalDataIncompatible3(Unknown Source)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.checkBlockLength(CDRInputStream_1_0.java:377)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_2.alignAndCheck(CDRInputStream_1_2.java:105)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_long(CDRInputStream_1_0.java:496)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.readValueTag(CDRInputStream_1_0.java:1810)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_value(CDRInputStream_1_0.java:1040)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_value(CDRInputStream_1_0.java:935)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_abstract_interface(CDRInputStream_1_0.java:928)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_abstract_interface(CDRInputStream_1_0.java:918)
at com.sun.corba.ee.impl.encoding.CDRInputObject.read_abstract_interface(CDRInputObject.java:557)
at com.sun.corba.ee.impl.io.IIOPInputStream.readObjectDelegate(IIOPInputStream.java:391)
... 41 more
Exception in thread "main" javax.naming.CommunicationException: Communication exception for SerialContext[myEnv=

{java.naming.factory.initial=com.sun.enterprise.naming.impl.SerialInitContextFactory, java.naming.corba.orb=com.sun.corba.ee.impl.orb.ORBImpl@17a906e, java.naming.factory.url.pkgs=com.sun.enterprise.naming, java.naming.factory.state=com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl, com.sun.appserv.iiop.loadbalancingpolicy=ic-based, com.sun.appserv.ee.iiop.endpointslist=corbaloc:iiop:1.2@localhost:3700, com.sun.appserv.iiop.endpoints=localhost:3700}

[Root exception is java.rmi.MarshalException: CORBA MARSHAL 1330446347 Maybe; nested exception is:
org.omg.CORBA.MARSHAL: WARNING: IOP00810011: Exception from readValue on ValueHandler in CDRInputStream vmcid: OMG minor code: 11 completed: Maybe]
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:542)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at com.sun.enterprise.naming.impl.SerialContext.listBindings(SerialContext.java:866)
at javax.naming.InitialContext.listBindings(InitialContext.java:447)
at remotejndilookuptest.RemoteJNDILookupTest.main(RemoteJNDILookupTest.java:24)
Caused by: java.rmi.MarshalException: CORBA MARSHAL 1330446347 Maybe; nested exception is:
org.omg.CORBA.MARSHAL: WARNING: IOP00810011: Exception from readValue on ValueHandler in CDRInputStream vmcid: OMG minor code: 11 completed: Maybe
at com.sun.corba.ee.impl.javax.rmi.CORBA.Util.mapSystemException(Util.java:267)
at com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.privateInvoke(StubInvocationHandlerImpl.java:213)
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.enterprise.naming.impl._SerialContextProvider_DynamicStub.lookup(com/sun/enterprise/naming/impl/_SerialContextProvider_DynamicStub.java)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:505)
... 4 more
Caused by: org.omg.CORBA.MARSHAL: WARNING: IOP00810011: Exception from readValue on ValueHandler in CDRInputStream vmcid: OMG minor code: 11 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 $Proxy24.valuehandlerReadException(Unknown Source)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.readRMIIIOPValueType(CDRInputStream_1_0.java:1022)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_value(CDRInputStream_1_0.java:1123)
at com.sun.corba.ee.impl.encoding.CDRInputObject.read_value(CDRInputObject.java:531)
at com.sun.corba.ee.impl.io.IIOPInputStream.inputObjectField(IIOPInputStream.java:2162)
at com.sun.corba.ee.impl.io.IIOPInputStream.inputClassFields(IIOPInputStream.java:2404)
at com.sun.corba.ee.impl.io.IIOPInputStream.inputObject(IIOPInputStream.java:1224)
at com.sun.corba.ee.impl.io.IIOPInputStream.simpleReadObject(IIOPInputStream.java:425)
at com.sun.corba.ee.impl.io.ValueHandlerImpl.readValueInternal(ValueHandlerImpl.java:308)
at com.sun.corba.ee.impl.io.ValueHandlerImpl.readValue(ValueHandlerImpl.java:274)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.readRMIIIOPValueType(CDRInputStream_1_0.java:1015)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_value(CDRInputStream_1_0.java:1123)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_value(CDRInputStream_1_0.java:935)
at com.sun.corba.ee.impl.encoding.CDRInputObject.read_value(CDRInputObject.java:525)
at com.sun.corba.ee.impl.corba.TCUtility.unmarshalIn(TCUtility.java:289)
at com.sun.corba.ee.impl.corba.AnyImpl.read_value(AnyImpl.java:605)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_any(CDRInputStream_1_0.java:775)
at com.sun.corba.ee.impl.encoding.CDRInputObject.read_any(CDRInputObject.java:482)
at com.sun.corba.ee.impl.javax.rmi.CORBA.Util.readAny(Util.java:452)
at com.sun.corba.ee.impl.presentation.rmi.DynamicMethodMarshallerImpl$10.read(DynamicMethodMarshallerImpl.java:299)
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)
... 8 more
Caused by: java.io.OptionalDataException
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.impl.io.IIOPInputStream.createOptionalDataException(IIOPInputStream.java:245)
at com.sun.corba.ee.impl.io.IIOPInputStream.handleOptionalDataMarshalException(IIOPInputStream.java:944)
at com.sun.corba.ee.impl.io.IIOPInputStream.readObjectDelegate(IIOPInputStream.java:393)
at com.sun.corba.ee.impl.io.IIOPInputStream.readObjectOverride(IIOPInputStream.java:544)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:344)
at java.util.HashMap.readObject(HashMap.java:1030)
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.corba.ee.impl.io.IIOPInputStream.invokeObjectReader(IIOPInputStream.java:1832)
at com.sun.corba.ee.impl.io.IIOPInputStream.inputObject(IIOPInputStream.java:1214)
at com.sun.corba.ee.impl.io.IIOPInputStream.simpleReadObject(IIOPInputStream.java:425)
at com.sun.corba.ee.impl.io.ValueHandlerImpl.readValueInternal(ValueHandlerImpl.java:308)
at com.sun.corba.ee.impl.io.ValueHandlerImpl.readValue(ValueHandlerImpl.java:274)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.readRMIIIOPValueType(CDRInputStream_1_0.java:1015)
... 28 more
Caused by: org.omg.CORBA.MARSHAL: FINE: IOP00800008: Not enough optional data available vmcid: SUN minor code: 8 completed: No
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 $Proxy27.rmiiiopOptionalDataIncompatible3(Unknown Source)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.checkBlockLength(CDRInputStream_1_0.java:377)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_2.alignAndCheck(CDRInputStream_1_2.java:105)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_long(CDRInputStream_1_0.java:496)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.readValueTag(CDRInputStream_1_0.java:1810)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_value(CDRInputStream_1_0.java:1040)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_value(CDRInputStream_1_0.java:935)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_abstract_interface(CDRInputStream_1_0.java:928)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_abstract_interface(CDRInputStream_1_0.java:918)
at com.sun.corba.ee.impl.encoding.CDRInputObject.read_abstract_interface(CDRInputObject.java:557)
at com.sun.corba.ee.impl.io.IIOPInputStream.readObjectDelegate(IIOPInputStream.java:391)
... 41 more

Expected outcome: The listing of the "jdbc" subcontext should complete successfully without OptionalDataException.

Many thanks & best regards,

Andreas



 Comments   
Comment by Harshad Vilekar [ 01/Nov/11 ]

Assign to JDBC team for initial evaluation.

Comment by Shalini [ 14/Nov/11 ]

Assigning this issue to Naming module as jdbc module does not do anything special to list the jndi entries.

Comment by Cheng Fang [ 15/Nov/11 ]

Related issue http://java.net/jira/browse/GLASSFISH-17219 (Remote clients cannot list global JNDI root context due to non-Serializable objects in the context)

Comment by Cheng Fang [ 15/Nov/11 ]

The values of jndi entries are not required to be serializable. Requiring them to be so would put too much burden on the implementation. In the current implementation, when the remote client calls list or listBindings, it first tries to look up the param subcontext from remote context provider, and calls list(empty) on the subcontext. The subcontext from the first pass lookup may contain non-serializable content, hence the serialization failure.

Comment by Cheng Fang [ 12/Dec/11 ]

One option is to fully resolve jndi bindings (include leaf objects and all levels of subcontexts) for remote list* operations. So everything returned to the remote client is serializable. Exclude it from 3.1.2.

Comment by guojun.shan [ 29/May/13 ]

still exist on v4.0.
Caused by: org.omg.CORBA.BAD_PARAM: ---------BEGIN server-side stack trace---------
org.omg.CORBA.BAD_PARAM: WARNING: 00100006: Class org.glassfish.resourcebase.resources.api.ResourceProxy is not Serializable vmcid: SUN minor code: 6 completed: Maybe
at $Proxy318.notSerializable(Unknown Source)
at com.sun.corba.ee.impl.misc.ORBUtility.throwNotSerializableForCorba(ORBUtility.java:783)
at com.sun.corba.ee.impl.encoding.CDROutputStream_1_0.write_abstract_interface(CDROutputStream_1_0.java:556)
at com.sun.corba.ee.impl.encoding.CDROutputObject.write_abstract_interface(CDROutputObject.java:523)
at com.sun.corba.ee.impl.javax.rmi.CORBA.Util.writeAbstractObject(Util.java:492)
at com.sun.corba.ee.impl.io.IIOPOutputStream.writeObjectOverride(IIOPOutputStream.java:177)





[GLASSFISH-17210] Supplemental commands for the DAS will incorrectly be bypassed if there is 1 server and 0 clusters Created: 19/Aug/11  Updated: 13/Oct/11  Resolved: 22/Aug/11

Status: Resolved
Project: glassfish
Component/s: admin
Affects Version/s: 3.1.2, 4.0
Fix Version/s: 4.0

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

Tags: 3_1_x-exclude

 Description   

Currently, logic in CommandRunnerImpl will skip running supplemental commands if there is only one server and no clusters defined, even if the suppl. command is targeted to the DAS.

I don't believe we currently have any supplemental commands that do not also involved clusters or multiple instances, but this is still a bug.



 Comments   
Comment by Tim Quinn [ 19/Aug/11 ]

This should be fixed right away in the trunk. The orchestration logic is currently not working because this bug prevents the PostDeployCommand from running after DeployCommand completes.

Comment by Tom Mueller [ 22/Aug/11 ]

Fixed on the trunk in revision 48943.

Comment by shreedhar_ganapathy [ 01/Sep/11 ]

Is this fix required in 3.1.2 codeline ? If yes, could you please also check in there?

Comment by Tom Mueller [ 01/Sep/11 ]

The bug exists in 3.1.2 also. However, there are no supplemental commands in 3.1.2 of the sort that expose the bug. So this doesn't need to be fixed in 3.1.2 (unless one of those commands is added).

Comment by Tom Mueller [ 13/Oct/11 ]

Since the 3.1.x release does not have supplemental commands that need this, this doesn't need to be fixed in any 3.1.x release.
Adding the 3_1_x-exclude tag.





[GLASSFISH-17204] Got IllegalStateException when deploying a Webloig test application to GlassFish Created: 18/Aug/11  Updated: 20/Dec/16  Resolved: 12/Feb/13

Status: Resolved
Project: glassfish
Component/s: web_services
Affects Version/s: 3.1.1
Fix Version/s: 4.0_dev

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

Windows XP


Attachments: File Echo.war     Text File server.log    
Tags: 3_1_2-exclude, 3_1_x-exclude

 Description   

File this bug as per management's request...
I tried to use a weblogic test war file on glassfish and I could
not deploy it. The error said:
"Error occurred during deployment: Exception while deploying the app
[Echo] : Servlet [EchoServiceServlethttp] and Servlet [EchoService] have
the same url pattern: [/EchoService]at
org.glassfish.apf.AnnotationInfo@158530c. Please see server.log for more
details."

The server.log and the test war file have been attached to the bug.
Please note that the same test app works for WebLogic and I could deploy and run the test successfully.



 Comments   
Comment by Hong Zhang [ 18/Aug/11 ]

Assign to Rama to see if this is an expected exception with GlassFish. Rama had some previous discussions with Sonia on this already.

Comment by scatari [ 08/Nov/11 ]

Not critical for 3.1.2.

Comment by ramapulavarthi [ 09/Nov/11 ]

There are two issues with the deployment error thrown as in the bug description.
(1) The linking between Web Service class and web services.xml is mainly using port-component-name in web services.xml which should be equal to the value of @WebService(name) element or defaults to Impl class. Here they are different, JAX-WS runtime sees them as different endpoints and processes the annotations and tries to register another JAX-WS endpoint at the url pattern /EchoService.

(2) It is a JAX-RPC web service with jaxrpc-mapping file specified in the web services.xml, Glassfish does not support JAX-RPC web services with JSR-181 annotations.

Supporting (2) is a lot of work involved in JAX-RPC runtime code.

Giving a more meaningful error for (1) that it is a unsupported combination would be make it clear for the user. 109 runtime can be patched to see if another endpoint is registered at the url pattern and throw some meaningful error but this is not critical for 3.1.x releases as such there are issues with port-component-name specified by the user.

Comment by Lukas Jungmann [ 09/Feb/13 ]

meaningful error message will be provided as suggested by Rama, and annotation processing will be skipped in this case

Comment by Lukas Jungmann [ 12/Feb/13 ]

severe log message added in http://java.net/projects/glassfish/sources/svn/revision/59408





[GLASSFISH-17177] CommandRunnerImple is not able to print the duplicate records and new line character '\n'. Created: 10/Aug/11  Updated: 17/Oct/11  Resolved: 10/Aug/11

Status: Resolved
Project: glassfish
Component/s: command_line_interface
Affects Version/s: 3.1.1
Fix Version/s: 4.0

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

All


Attachments: Java Source File TestCommand.java    
Issue Links:
Dependency
blocks GLASSFISH-16981 asadmin show-log Open
Tags: 3_1_x-exclude

 Description   

CommandRunnerImpl is not allowed to print the duplicate records as part of part.setMessage(...);

As if logRecords are duplicate then it prints just once also not allowed to print line separator or new line character.

Attached the sample code for the same also.



 Comments   
Comment by Tom Mueller [ 10/Aug/11 ]

Fixed on the trunk in revision 48689.

Comment by Tom Mueller [ 12/Aug/11 ]

Additional revisions to include to fix this issue:
48698 on the trunk.
48706 on the trunk.
48735 on the trunk.

Comment by shreedhar_ganapathy [ 01/Sep/11 ]

Is this fix required in 3.1.2 codeline?

Comment by Tom Mueller [ 01/Sep/11 ]

This bug was exposed by a new feature being developed for the trunk that allows log messages to be output by an asadmin command. This output might include content with duplicate lines.

As long as this feature is not ported to 3.1.2, then this bug fix doesn't need to be in 3.1.2.
Please note that the tag does not contain 3_1-next.

Comment by naman_mehta [ 02/Sep/11 ]

Do we need to consider this for 3.1.2 then I am fine with the same? I am ready to commit changes in 3.1.2 for new command show-log-records.

Comment by Tom Mueller [ 17/Oct/11 ]

Marking as excluded from 3.1.x releases.





[GLASSFISH-17173] Build Errors on Java SE 7 Created: 09/Aug/11  Updated: 20/Dec/16  Resolved: 12/Dec/12

Status: Resolved
Project: glassfish
Component/s: build_system
Affects Version/s: None
Fix Version/s: 4.0_dev

Type: Bug Priority: Critical
Reporter: Byron Nevins Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1_x-exclude

 Description   

Isn't it time to solve this? GF can not be built using Java SE7. I am constantly going back and forth between 6 and 7 because of this.

[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Internal error in the plugin manager executing goal 'org.glassfish.hk2:hk2-maven-plugin:1.6.12:hk2-compile': Unable to load the mojo 'org.glassfish.hk2:hk2-maven-plugin:1.6.12:hk2-compile' in the plugin 'org.glassfish.hk2:hk2-maven-plugin'. A required class is missing: com/sun/mirror/apt/AnnotationProcessorFactory
com.sun.mirror.apt.AnnotationProcessorFactory



 Comments   
Comment by scatari [ 07/Nov/11 ]

GlassFish 3.1.x will not be built with JDK 7 to support compatibility.

Comment by Joe Di Pol [ 12/Dec/12 ]

This has been fixed in the 4.0 trunk.





[GLASSFISH-17155] CDI Events don't work when fired by a OSGi ServiceListener. Created: 06/Aug/11  Updated: 25/Mar/13

Status: Open
Project: glassfish
Component/s: OSGi-JavaEE
Affects Version/s: 3.1.1
Fix Version/s: future release

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

Windows 7 (64 bits)
java version "1.6.0_25"
Java(TM) SE Runtime Environment (build 1.6.0_25-b06)
Java HotSpot(TM) 64-Bit Server VM (build 20.0-b11, mixed mode)


Attachments: Zip Archive osgijee.zip     Zip Archive osgijee_tangyong.zip    
Status Whiteboard:

Workaround: Set TCL before raising CDI event inside serviceChanged()

Tags: 3_1_x-exclude, osgi-javaee

 Description   

Steps to reproduce the problem:

1) Download Glassfish

http://download.java.net/glassfish/3.1.1/release/glassfish-3.1.1.zip

2) Unzip and enable remote shell (item 10.4.1 from GF-OSGI-Features.pdf)

3) Download and unzip the file in attachment

4) Open a shell (cmd in Windows)

$>cd osgijee
$>mvn package

5) Run Glassfish

asadmin start-database
asadmin start-domain -v

6) Start gogo shell

$>telnet localhost 6666
g! install file:/F:/tmp/osgijee/core/target/core.jar
Bundle ID: 253
g! start 253
g! install file:/F:/tmp/osgijee/webclient/target/webclient.war
Bundle ID: 254
g! start 254

7) Access in your browser: http://localhost:8080/webclient/faces/home.xhtml. You must see a page with text: "No modules available."

8) Go back to gogo shell
g! install file:/F:/Users/ranophoenix_2/Documents/Pos-ESAB/Experimentos/tmp/osgijee/module1/target/module1.war
Bundle ID: 255
g! start 255
ERROR: Bundle ranophoenix.osgijee.webclient [254]: EventDispatcher: Error during dispatch. (java.lang.IllegalStateExcept
ion: Singleton not set for sun.misc.Launcher$AppClassLoader@1f7182c1)
java.lang.IllegalStateException: Singleton not set for sun.misc.Launcher$AppClassLoader@1f7182c1
at org.glassfish.weld.ACLSingletonProvider$ACLSingleton.get(ACLSingletonProvider.java:110)
at org.jboss.weld.Container.instance(Container.java:58)
at org.jboss.weld.resolution.ResolvableBuilder.checkQualifier(ResolvableBuilder.java:209)
at org.jboss.weld.resolution.ResolvableBuilder.addQualifier(ResolvableBuilder.java:174)
at org.jboss.weld.resolution.ResolvableBuilder.addQualifiers(ResolvableBuilder.java:202)
at org.jboss.weld.manager.BeanManagerImpl.resolveObserverMethods(BeanManagerImpl.java:474)
at org.jboss.weld.manager.BeanManagerImpl.fireEvent(BeanManagerImpl.java:625)
at org.jboss.weld.event.EventImpl.fire(EventImpl.java:75)
at ranophoenix.osgijee.webclient.impl.cdi.ModuleExtensionListener.serviceChanged(ModuleExtensionListener.java:45
)
at org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:871)
at org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:733)
at org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:662)
at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:3769)
at org.apache.felix.framework.Felix.access$000(Felix.java:80)
at org.apache.felix.framework.Felix$2.serviceChanged(Felix.java:722)
at org.apache.felix.framework.ServiceRegistry.registerService(ServiceRegistry.java:107)
at org.apache.felix.framework.Felix.registerService(Felix.java:2854)
at org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:251)
at org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:229)
at ranophoenix.osgijee.module1.impl.Activator.start(Activator.java:17)
at org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:629)
at org.apache.felix.framework.Felix.activateBundle(Felix.java:1835)
at org.apache.felix.framework.Felix.startBundle(Felix.java:1752)
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:922)
at org.apache.felix.gogo.command.Basic.start(Basic.java:758)
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.felix.gogo.runtime.Reflective.method(Reflective.java:136)
at org.apache.felix.gogo.runtime.CommandProxy.execute(CommandProxy.java:82)
at org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:469)
at org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:395)
at org.apache.felix.gogo.runtime.Pipe.run(Pipe.java:108)
at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:183)
at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:120)
at org.apache.felix.gogo.runtime.CommandSessionImpl.execute(CommandSessionImpl.java:89)
at org.apache.felix.gogo.shell.Console.run(Console.java:62)
at org.apache.felix.gogo.shell.Shell.console(Shell.java:203)
at org.apache.felix.gogo.shell.Shell.gosh(Shell.java:128)
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.felix.gogo.runtime.Reflective.method(Reflective.java:136)
at org.apache.felix.gogo.runtime.CommandProxy.execute(CommandProxy.java:82)
at org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:469)
at org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:395)
at org.apache.felix.gogo.runtime.Pipe.run(Pipe.java:108)
at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:183)
at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:120)
at org.apache.felix.gogo.runtime.CommandSessionImpl.execute(CommandSessionImpl.java:89)
at org.apache.felix.shell.remote.Shell.startGogoShell(Shell.java:108)
at org.apache.felix.shell.remote.Shell.run(Shell.java:81)
at java.lang.Thread.run(Thread.java:662)
Module1 started



 Comments   
Comment by ranophoenix [ 06/Aug/11 ]

Correcting the path in step 8:

8) Go back to gogo shell
g! install file:/F:/tmp/osgijee/module1/target/module1.war
...

Comment by ranophoenix [ 25/Aug/11 ]

The same problem occurs with Windows 7,JVM 1.6.0_27 64 bits and Glassfish 3.1.1 all of them installed from scratch.

Comment by Sanjeeb Sahoo [ 20/Oct/11 ]

I wish you had reminded me about this bug. I hope you didn't get stuck. As a simple work around, just set the context class loader inside the serviceChanged method like this:

public class ModuleExtensionListener implements ServiceListener {
...
public void serviceChanged(ServiceEvent event) {
ClassLoader origCl = Thread.currentThread().getContextClassLoader();
try

{ Thread.currentThread().setContextClassLoader(getClass().getClassLoader()); ... raise your CDI event here }

finally

{ Thread.currentThread().setContextClassLoader(origCl); }

}
}

Comment by Sanjeeb Sahoo [ 20/Oct/11 ]

Since there is a simple workaround available, we will defer fixing this bug till 4.0.

Comment by TangYong [ 10/Aug/12 ]

1) About ACLSingleton.getClassLoader()
If store hashtable does not contain Thread.currentThread().getContextClassLoader(),
the exception on GLASSFISH-17155 must happen. So, sahoo gave a solution. However, I have
confirmed that even if user set the current thread context classload on serviceChanged method,
the exception still existed. Why? Becasue the key put in store hashtable is WebappClassLoader
(for the WAB app) and the WebappClassLoader is set on WAB deploying, so, for the user, he/she can
not have chance to set the current thread context classload into the WebappClassLoader.

2) About CDI/OSGi Event
I have found that real problem on GLASSFISH-17155 is that currently,GF has not implemented the CDI/OSGi Event Integration.

I made a confirmation that even if I made the exception on GLASSFISH-17155 disappeared using a temp revise way, the sample can not still work. Why? When a new service is registered, although cdi event has been fired and WAB @observers method is also triggered, but on the WAB, there are two @Observes, one is to add the service and the other is to delete the service. When cdi event is fired, both the two @Observes are triggered.So, the service is not still added finally. That is to say, the @Observes can not judge the type of current OSGi Event.

Comment by TangYong [ 10/Aug/12 ]

Sahoo Said:

>1) About ACLSingleton.getClassLoader()
>...
So, are you saying that the suggested work around does not work any longer? I think your analysis is correct as well. I think a proper way to solve would be to set the class loader as an attribute in ServletContext during WAB deployment so that an application programmer can retrieve it inside serviceChanged() method and set it as the TCL
temporarily.

>2) About CDI/OSGi Event
>...
I think this is because the test application attached to the issue is not firing events correctly. It needs to fire events using BeanManager and use proper qualifiers such that methods will receive events they are interested in. See ServletContextBridgeListener.java in the test app for more details.

Comment by TangYong [ 10/Aug/12 ]

Yeah, I also think the way indeed can resolve the problem. However because the problem happened on cdi event case, I suggest that during resolving cdi/osgi event integration, finding a better way to resolve the problem. After all, I felt the problem is not simple.

Thanks your suggestion and I will see ServletContextBridgeListener.java. In addition, about how to firing events correctly(etc. when a osgi service has been registered...) and related using way, wishing siva can give some ideas, then we will launch another thread to discuss it.

Comment by TangYong [ 10/Aug/12 ]

Currently, a prototype is plan to implement the cdi/osgi event integraton.

https://github.com/tangyong/gf-cdi-osgi-integration

Comment by TangYong [ 19/Nov/12 ]

Waiting for GLASSFISH-15365 and I will modify the sample and make it available.

Comment by TangYong [ 22/Nov/12 ]

Waiting for finishing GLASSFISH-15365 test , then starting to resolve the bug.

Comment by TangYong [ 26/Nov/12 ]

Hi ranophoenix, sahoo, siva,

Based my event integration patch and ranophoenix's original sample, I re-made a new sample(osgijee_tangyong.zip) using osgi/cdi event annotation. Now, osgijee_tangyong.zip can work normally.

However, while executing the last step(module1's about.xhtml), there is a issue happening as following:

[#|2012-11-26T17:49:16.015+0900|WARNING|44.0|javax.enterprise.resource.webcontainer.jsf.lifecycle|_ThreadID=15;_ThreadName=http-listener-1(2);_TimeMillis=1353919756015;_LevelValue=900;|//about.xhtml @13,61 value="#

{aboutBean.message}": Target Unreachable, identifier 'aboutBean' resolved to null
javax.el.PropertyNotFoundException: //about.xhtml @13,61 value="#{aboutBean.message}

": Target Unreachable, identifier 'aboutBean' resolved to null
at com.sun.faces.facelets.el.TagValueExpression.getType(TagValueExpression.java:100)
at com.sun.faces.renderkit.html_basic.HtmlBasicInputRenderer.getConvertedValue(HtmlBasicInputRenderer.java:95)
at javax.faces.component.UIInput.getConvertedValue(UIInput.java:1031)
at javax.faces.component.UIInput.validate(UIInput.java:961)
at javax.faces.component.UIInput.executeValidate(UIInput.java:1234)
at javax.faces.component.UIInput.processValidators(UIInput.java:697)
at javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:1263)
at javax.faces.component.UIForm.processValidators(UIForm.java:253)
at javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:1263)
at javax.faces.component.UIViewRoot.processValidators(UIViewRoot.java:1169)
at com.sun.faces.lifecycle.ProcessValidationsPhase.execute(ProcessValidationsPhase.java:76)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:181)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:641)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1593)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:285)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:665)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:604)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:162)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:337)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:240)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:172)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:164)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:175)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:265)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:200)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:134)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:112)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:781)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:578)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:558)
at java.lang.Thread.run(Thread.java:662)
Caused by: javax.el.PropertyNotFoundException: Target Unreachable, identifier 'aboutBean' resolved to null
at com.sun.el.parser.AstValue.getTarget(AstValue.java:153)
at com.sun.el.parser.AstValue.getType(AstValue.java:84)
at com.sun.el.ValueExpressionImpl.getType(ValueExpressionImpl.java:200)
at org.jboss.weld.el.WeldValueExpression.getType(WeldValueExpression.java:93)
at com.sun.faces.facelets.el.TagValueExpression.getType(TagValueExpression.java:98)
... 38 more

#]

ranophoenix's mean is that he/she wants to make CDI Bean in module1's context root can work in webclient's context root. So, I wish that sahoo and siva can see the sample and confirm whether this behavior is right or not? And this is also related to register a cdi bean on runtime. On JBoss's JIRA, there is such a requirement[1]:
[1]: https://issues.jboss.org/browse/CDI-114

In addition, I think that combining cdi beans in two different context roots should be user's behavior, and osgi-cdi should not handle the scene because osgi-cdi's responsibility only triggers osgi events, as to how to handle these events, has been out of event integration's scope.

Thanks
--Tang

Comment by TangYong [ 25/Mar/13 ]

The bug is related to OSGi/CDI RFC 193. Currently, we have not enough time to implement it.So, we have a plan to fix the issue after v4 is released.





[GLASSFISH-17149] CLI messages don't follow the standard message format. Created: 05/Aug/11  Updated: 02/Dec/11  Resolved: 11/Aug/11

Status: Resolved
Project: glassfish
Component/s: admin
Affects Version/s: 4.0
Fix Version/s: 4.0

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

Operating System: All
Platform: All


Tags: 3_1_x-exclude

 Description   

When we specify an invalid string as a port number of DAS, CLI136 will be output without a colon(":").

>asadmin --port xxx create-cluster test
CLI136 Port abc should be a numeric value.
Command --port failed.

I checked LocalStrings.properties under trunk\v3\admin\cli directory of GFv3.2(r47843) and detected almost CLI messages don't have a colon(":"). For example, CLI017, CLI155, etc in trunk\v3\admin\cli\src\main\java\com\sun\enterprise\admin\cli\LocalStrings.properties.

These don't follow the following message id requirement in http://wikis.sun.com/display/GlassFish/GlassFishV3LoggingMessageFormat.
<Subsystem><4CharIntegerMessageId>: <message text>

Although I found the description that GlassFish CLI or exception messages do not require a message id in the above URL,
I think the message id format should be unified if it is added to a message so that users can deal with them simply.
Because some users would like to observe messages automatically using their own tool. In this case, the colon(":") will be a role of the delimiter for a whole message.



 Comments   
Comment by Tom Mueller [ 11/Aug/11 ]

Fixed on the trunk in revision 48709.

Comment by Tom Mueller [ 11/Aug/11 ]

Fixed more of these on the trunk in revision 48714.

Comment by Tom Mueller [ 13/Oct/11 ]

Adding the 3_1_x-exclude tag. This is a minor issue that does not need to be fixed in the 3.1.x release.





[GLASSFISH-17141] asadmin converts plus (+) in argument to a space Created: 01/Aug/11  Updated: 02/Dec/11  Resolved: 10/Oct/11

Status: Resolved
Project: glassfish
Component/s: command_line_interface
Affects Version/s: 3.1.1, 4.0
Fix Version/s: 4.0

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

Tags: 3_1_x-exclude

 Description   

When a plus ("+") is passed as an asadmin argument, it is converted to a space.

For example:

$ asadmin create-system-properties a=b+c
$ asadmin list-system-properties
The target server contains following 1 system properties
a=b c

This also happens with the create-jvm-options command:

$ asadmin create-jvm-options "-XX\:+PrintGCDetails"
$ asadmin list-jvm-options | grep PrintGC
-XX: PrintGCDetails

I suspect that the root cause of this problem is that the arguments are passed in a URL to the server, and a + in an HTTP URL is the URL encoding for a space.



 Comments   
Comment by Tom Mueller [ 10/Oct/11 ]

This is fixed on the trunk.





[GLASSFISH-17133] JMS resouce adapter is not accessable from a java client Created: 29/Jul/11  Updated: 20/Dec/16  Resolved: 31/Mar/12

Status: Resolved
Project: glassfish
Component/s: jms
Affects Version/s: 3.1.1_dev
Fix Version/s: 4.0_dev

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

glassfish@centos5, client@eclipse@windows7-64bit


Tags: 3_1_x-exclude, LOCAL, MQJMSRA_RA4001, REMOTE, broker, jms, resource_adapter

 Description   

Hi,

I tried to query a JMS factory by JNDI naming service like this:

InitialContext ctx = new InitialContext(serverContext);
Object factory = ctx.lookup("jms/responseTopicConnectionFactory");

The client running this code is a windows machine -
the glassfish us running on a centos server.

If i configure the JMS in LOCAL mode, i get the following
error on the client side, because the client tries to start
a imqbrokersvc (why?) using the program path from the server:


SCHWERWIEGEND: MQJMSRA_RA4001: start:Aborting:Exception starting LOCAL broker=Cannot run program "C:\opt\glassfish3\mq\bin\imqbrokersvc.exe": CreateProcess error=2, Das Syst\
em kann die angegebene Datei nicht finden
29.07.2011 13:44:01 com.sun.messaging.jms.blc.LifecycleManagedBroker start
INFO: SJSMQ LifecycleManagedBroker configuration=
brokerInstanceName =n1standalonen1standalone
brokerBindAddress =null
brokerPort =27676
brokerHomeDir =C:\opt\glassfish3\mq
brokerLibDir =C:\opt\glassfish3\mq\lib
brokerVarDir =C:\opt\glassfish3\glassfish\nodes\n1\n1.standalone\imq
brokerJavaDir =C:\opt\jdk1.6.0_26\jre
brokerArgs =null
MasterBroker =null
brokerId =null

Caused by: java.io.IOException: Cannot run program "C:\opt\glassfish3\mq\bin\imqbrokersvc.exe": CreateProcess error=2, Das System kann die angegebene Datei nicht finden
at java.lang.ProcessBuilder.start(ProcessBuilder.java:460)
at java.lang.Runtime.exec(Runtime.java:593)
at java.lang.Runtime.exec(Runtime.java:466)
at com.sun.messaging.jmq.admin.jmsspi.JMSAdminImpl.launchAndWatch(JMSAdminImpl.java:794)
at com.sun.messaging.jmq.admin.jmsspi.JMSAdminImpl.startProvider(JMSAdminImpl.java:789)
at com.sun.messaging.jms.blc.LocalBrokerRunner.start(LocalBrokerRunner.java:310)
at com.sun.messaging.jms.blc.LifecycleManagedBroker.start(LifecycleManagedBroker.java:431)


If I use the EMBEDDED mode, it doesn't work also because the client
try to access a property file using the wrong filename (Path somewhere on the server)

All tests was done with glassfish version 3.1.1_b12 and 3.1_stable

If I use the REMOTE mode and start a standalone /opt/MessageQueue4_5_1/mq/bin/imqbrokerd JMS-Server @centos,
the lookup works fine - without exception.

The setup using LOCAL-Mode in glassfish 2.1.1 works fine.

If I try to start the imqbrokerd from the glassfish bundle, i get an error (but may this is normal):
[B3276]: Starting a GlassFish-managed broker directly using imqbrokerd is not allowed

So, i think the JMS MQ resource adapter is broken.

Workaround: Do not use JMS LOCAL/EMBEDDED typ, but setup a standalone JMS server and
configure glassfish to use this Server as REMOTE typ.

Kind regards
Danny



 Comments   
Comment by David Zhao [ 31/Mar/12 ]

Can not reproduce it against GlassFish 4.0. In my testing, the jms client on win7 sends messages to GF4.0 server (in either LOCAL or EMBEDDED jms service type) on RedHat Linux successfully.





[GLASSFISH-17123] Parsing verifier options failed Created: 28/Jul/11  Updated: 13/Feb/13

Status: Open
Project: glassfish
Component/s: verifier
Affects Version/s: 4.0
Fix Version/s: future release

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

Operating System: Windows 7(64bit)


Tags: 3_1_x-exclude

 Description   

I can execute verifier.bat normally if I don't specify any options.
verifier $

{archiveName}

However verifier with any options always seems to fail except for --version and --help.
(Note that I translated some labels such as "Fatal" of command results into the corresponding English words when I wrote the following description because they were originally output as Japanese.)
I show the Case1 - Case 4 to explain this.

Case1) This is the same command as described in help description (--help).
verifier -v -ra -d ${absolutePathToResultDir} ${archiveName}

2011/07/28 16:56:30 com.sun.enterprise.tools.verifier.Initializer parseArgs
Detailed Level (Low): Setting verbose flag to TRUE.
2011/07/28 16:56:30 com.sun.enterprise.tools.verifier.Initializer parseArgs
Fatal: verifier: option [ - ] is not valid.
2011/07/28 16:56:30 com.sun.enterprise.tools.verifier.Initializer usage
Info:
usage: verifier [optional_params] <jarFile>

Case2) This command also returns the same results as Case 1. Parsing "-ra" doesn't work normally.
verifier -v -ra

Case3) This command seems to return collect result because I didn't specify any archives,
but I cannot find this usage in help description (--help).
verifier -vra

2011/07/28 17:08:54 com.sun.enterprise.tools.verifier.Initializer parseArgs
Detailed Level (Low): Setting verbose flag to TRUE.
2011/07/28 17:08:54 com.sun.enterprise.tools.verifier.Initializer setReportingLevel
Detailed Level (Low): Setting output report level to display all results.
2011/07/28 17:08:54 com.sun.enterprise.tools.verifier.Initializer parseArgs
Fatal: verifier: no <jarfilename> specified on command line.
2011/07/28 17:08:54 com.sun.enterprise.tools.verifier.Initializer usage
Info:
usage: verifier [optional_params] <jarFile>

Case4) In this case, the string of "a $

{archiveName}" was parsed as the reporting level wrongly.
verifier -vra ${archiveName}

2011/07/28 17:13:48 com.sun.enterprise.tools.verifier.Initializer parseArgs
Detailed Level (Low): Setting verbose flag to TRUE.
2011/07/28 17:13:48 com.sun.enterprise.tools.verifier.Initializer parseArgs
Fatal: verifier: missing argument for -r or unknown reporting level [ a $

{archiveName}

].
2011/07/28 17:13:48 com.sun.enterprise.tools.verifier.Initializer usage
Info:
usage: verifier [optional_params] <jarFile>

Note that I set up verifier on GFv3.2(r47843) in the following order to use verifier functionality.
1. unzip trunk/v3/packager/glassfish-verifier/target/glassfish-verifier.zip and copy it to glassfish3 dir.
2. get glassfish-javahelp-3.2-SNAPSHOT.zip from maven repo and copy javahelp.jar to glassfish3/glassfish/lib



 Comments   
Comment by Sanjeeb Sahoo [ 20/Oct/11 ]

Will fix it in 4.0 where the bug is reported.





[GLASSFISH-17098] Move network-configuration CLI commands to nucleus under "grizzly-glue" module Created: 25/Jul/11  Updated: 02/Dec/11

Status: Open
Project: glassfish
Component/s: grizzly-kernel
Affects Version/s: 4.0
Fix Version/s: None

Type: Task Priority: Major
Reporter: oleksiys Assignee: oleksiys
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1_x-exclude, nucleus-cleanup

 Description   

subj.






[GLASSFISH-17015] Transaction logging at FINE level causes NPE and transaction propagation failure Created: 11/Jul/11  Updated: 19/Oct/11  Resolved: 13/Jul/11

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

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

Tags: 3_1_1-scrubbed, 3_1_x-exclude

 Description   

In v2 the logging in jts code was governed by a private variable (!?) which meant that only a recompiled class would produce the output. I suspect it wasn't tested after some later changes. In v3 the 'if (debug)' was changed to the normal logging, and somehow never tested with the FINE level and tx propagation. SenderReceiver's In- and Out- logging messages can produce an NPE that will cause the incoming tx to fail...

The fix is easy - check the value before printing.



 Comments   
Comment by marina vatkina [ 13/Jul/11 ]

It looks like the switch from 'debug' to FINE logging was done in 3.2 only.

Comment by marina vatkina [ 17/Oct/11 ]

trunk is now 4.0





[GLASSFISH-16954] asadmin complains about "Unknown plain text format" when deployment fails Created: 04/Jul/11  Updated: 24/Oct/11  Resolved: 13/Jul/11

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

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

Win7 Pro SP1 64 Bit de_DE


Attachments: File basicwebapp.war    
Tags: 3_1_1-exclude, 3_1_1-scrubbed, 3_1_x-exclude

 Description   

I am trying to deploy an application using "asadmin deploy --retrieve . SuperSimple.ear". Due to a bug in that EAR, deployment fails. This is a typical situation when still in development, so asadmin should be clever enough to handle this with a message like "Deployment failed due to...".

But what it actually says is "Unknown plain text format.". Least programmers will understand that this actually means: "Everything is OK, you just have a typo in your EAR"...!

c:\Users\Karg\workspace\CreateComplaintsRS\dist>C:\glassfish3\bin\asadmin deploy --retrieve . SuperSimple.ear
remote failure: Unknown plain text format. A properly formatted response from a PlainTextActionReporter
always starts with one of these 2 strings: PlainTextActionReporterSUCCESS or PlainTextActionReporterFAILURE. The response we re
ceived from the server was not understood: Signature-Version: 1.0
message: Error occurred during deployment: Exception while preparing t
he app : Exception [EclipseLink-28018] (Eclipse Persistence Services

  • 2.2.0.v20110202-r8913): org.eclipse.persistence.exceptions.EntityMa
    nagerSetupException
    Exception Description: Predeployment of
    PersistenceUnit [QUIPSY] failed.
    Internal Exception: Excepti
    on [EclipseLink-7163] (Eclipse Persistence Services - 2.2.0.v20110202
    %%%EO13): org.eclipse.persistence.exceptions.ValidationException
    L%%%Exception Description: Entity class [class de.quipsy.persistency.
    suppliedPart.SuppliedPartPk] has both an @EmbdeddedId (on attribute [
    pk]) and an @Id (on attribute [customerId]. Both ID types cannot be s
    pecified on the same entity.. Please see server.log for more details.

Exception while invoking class org.glassfish.persistence.jpa
.JPADeployer prepare method : javax.persistence.PersistenceException:
Exception [EclipseLink-28018] (Eclipse Persistence Services - 2.2.0.
v20110202-r8913): org.eclipse.persistence.exceptions.EntityManagerSet
upException
Exception Description: Predeployment of Persiste
nceUnit [QUIPSY] failed.
Internal Exception: Exception [Ecli
pseLink-7163] (Eclipse Persistence Services - 2.2.0.v20110202-r8913):
org.eclipse.persistence.exceptions.ValidationException
Exce
ption Description: Entity class [class de.quipsy.persistency.supplied
Part.SuppliedPartPk] has both an @EmbdeddedId (on attribute [pk]) and
an @Id (on attribute [customerId]. Both ID types cannot be specified
on the same entity.
Exception [EclipseLink-28018] (Eclipse P
ersistence Services - 2.2.0.v20110202-r8913): org.eclipse.persistence
.exceptions.EntityManagerSetupException
Exception Description: Prede
ployment of PersistenceUnit [QUIPSY] failed.
Internal Exception: Exc
eption [EclipseLink-7163] (Eclipse Persistence Services - 2.2.0.v2011
0202-r8913): org.eclipse.persistence.exceptions.ValidationException

Exception Description: Entity class [class de.quipsy.persistency.supp
liedPart.SuppliedPartPk] has both an @EmbdeddedId (on attribute [pk])
and an @Id (on attribute [customerId]. Both ID types cannot be speci
fied on the same entity.
name_value: SuperSimple
name_name: name
keys: name
use-main-children-attribute: false
exit-code: FAILURE

Command deploy failed.

c:\Users\Karg\workspace\CreateComplaintsRS\dist>



 Comments   
Comment by mkarg [ 04/Jul/11 ]

In addition to that nasty and wrong message, it is not very smart that my CLI can handle e. g. 160 columns per row, but GlassFish decides to just send much less (80 or so): Yes, the above formatting was done by GlassFish, not by me...!

That's not You and it's not GlassFish. It's the JDK 1.1 Manifest class doing the formatting.

Comment by Tom Mueller [ 05/Jul/11 ]

I'm not sure if this is a bug in the deploy command or in the response framework, so I'm assigning this to Tim first to see if it is a bug in deploy. If it is a bug in the response framework, please assign to Byron.

Comment by Tim Quinn [ 05/Jul/11 ]

Markus,

Which build of GlassFish are you using?

Can you please attach your app to this issue? It would help us in recreating exactly the conditions which cause the problem you noted. If you would rather not post it publicly you can e-mail it to me directly if you prefer.

Comment by Tim Quinn [ 05/Jul/11 ]

Using a current build of 3.1.1, I deployed an app that creates tables in the database during deployment. Then I undeployed without removing the tables. The next deployment of the app was reported as "completed with warnings" after listing the database messages because the tables were already there.

I am not using Markus's application, so there clearly could be important differences. But at least in 3.1.1 this case looks to be working.

Markus, this emphasizes how valuable it will be for me to use your app itself. Thanks.

Comment by mkarg [ 06/Jul/11 ]

Tim, wanted to send you my EAR, but your server first refused the mail due to it's size, then refused to accept any mails:

tjquinn@oracle.com on 06.07.2011 09:20
The message cannot be delivered due to a configuration error on the server. Please contact your Administrator.
<quipsy.de #5.3.0 smtp;553 5.3.0 <tjquinn@oracle.com>... 550:5.7.1 Email address is not available.>

Can you please send me an email addess to karg@quipsy.de where I can push the EAR to?

Comment by mkarg [ 06/Jul/11 ]

Tim, cannot answer to the email you sent me via att.net:

Your message did not reach some or all of the intended recipients.

Subject: RE: Getting your app to test the GlassFish issue
Sent: 06.07.2011 13:26

The following recipient(s) cannot be reached:

Tim Quinn on 06.07.2011 13:26
There was a SMTP communication problem with the recipient's email server. Please contact your system administrator.
<quipsy.de #5.5.0 smtp;521-87.234.217.170 blocked by sbc:blacklist.mailrelay.att.net.>

If you like I can upload the encrypted ZIP to our public FTP server, but how to send you the secret password?

Comment by Tim Quinn [ 06/Jul/11 ]

I have diagnosed this problem this far:

The server is using a PropsFileActionReporter to capture the result of this command (as it does for all asadmin commands).

The admin CLI client fails, though, when it tries to convert the response into a Manifest (which is how command results are returned to the client after admin command execution). I stepped through it enough to know that the Attributes class (in Java SE) throws an IOException with "invalid header field" – from line 389 in the Attributes class - from the invocation of the Manifest(InputStream) constructor in the AdminCommandResponse constructor.

Because the RemoteResponseManager assumes that any IOException in reading the input stream as a manifest is due to it not being a manifest - as opposed to it being a manifest that's not properly formatted - it goes on and tries to interpret it as a plain text response message - which it is not - and that code then complains because the response lacks one of the expected prefixes for plain text responses.

I suspect that by composing the message for the action report by adding on the exception message is what's causing the problem. Looking at the message Markus posted in his original description, there is a blank line followed by

Exception while invoking class org.glassfish.persistence.jpa
.JPADeployer prepare method : (more text)

which I suspect the Manifest constructor is trying to interpret as a manifest attribute. Because the text to the left of the : is not a legal attribute name, the Attributes class throws the IOException.

I am looking at an inexpensive way to process such error messages in DeployCommand to prevent the manifest reader from incorrectly interpreting the error display as an attribute.

Comment by Tim Quinn [ 06/Jul/11 ]

As Tom suggested earlier, I am reassigning this to Byron.

The PropsFileActionReporter's setMessage method needs to format the message in a way that the message cannot be confused as a manifest attribute setting. It already does some similar work to handle line separators in the message.

This is not something the caller should do, because other formats of reporter do not have this restriction and other places other than the caller in this case (DeployCommand) might set the message to similar unfriendly values.

Comment by mkarg [ 07/Jul/11 ]

Side note: The above explanation is a good example while people nowadays tend to prefer REST. A RESTful asadmin would just do a HTTP PUT with the complete EAR, the server would try to deploy it, and send one single XML file back with a list of all deployment issues, which asadmin can parse by simple JAXP.unmarshal(file). No need to fiddle around with custom classes and complex things like Manifests and PropsFileActionReporters etc. Maybe the asadmin team likes to think about that for GF 4...

Comment by mkarg [ 11/Jul/11 ]

Any news?

Comment by Byron Nevins [ 11/Jul/11 ]

I have no way to reproduce this. There is no ear attachment.

Comment by Byron Nevins [ 11/Jul/11 ]

Please attach the output when AS_DEBUG is set to true.

Comment by Byron Nevins [ 11/Jul/11 ]

Reopen after providing a way to reproduce please...

Comment by Tim Quinn [ 11/Jul/11 ]

Marcus provided a sample app which I will (separately) send to Byron.

Comment by Byron Nevins [ 11/Jul/11 ]

Is there something wrong with attaching it to JIRA?

Comment by Byron Nevins [ 11/Jul/11 ]

I will reopen this if and when I can reproduce it.

Comment by Tim Quinn [ 11/Jul/11 ]

As I wrote to Byron separately, the app cannot be shared publicly so it cannot be attached to the issue.

Turns out my earlier e-mail to Byron did not go through. I am providing him the sample app separately.

Comment by Byron Nevins [ 11/Jul/11 ]

Mitesh says this should demonstrate the bug

Comment by Byron Nevins [ 11/Jul/11 ]

Nope. That war file does NOT show the bug:

=== This Issue remain non-reproducible ===

fetchCommandModel: got command opts: com.sun.enterprise.admin.util.CommandModelData@1037c71
doHttpCommand succeeds
Process program options
Parsing program options
Parse command options
params: {}
operands: [basicwebapp.war]
Prevalidate command options
Inject command options
Validate command options
asadmin --host localhost --port 4848 --user admin --interactive=true --echo=false --terse=true deploy --force=false --precompilejsp=false --verify=fal
se --generatermistubs=false --availabilityenabled=false --asyncreplication=true --keepreposdir=false --keepfailedstubs=false --isredeploy=false --logr
eportederrors=true basicwebapp.war
Execute command
removing --upload option
doUpload set to false
FILE PARAM: DEFAULT = D:\j2eeapps\basicwebapp.war
URI: /__asadmin/deploy?DEFAULT=D%3A%5Cj2eeapps%5Cbasicwebapp.war
URL: com.sun.enterprise.admin.util.HttpConnectorAddress@1ef8cf3
URL: http://localhost:4848/__asadmin/deploy?DEFAULT=D%3A%5Cj2eeapps%5Cbasicwebapp.war
Password options: null
Using auth info: User: admin, Password: <null>
------- RAW RESPONSE ---------
Signature-Version: 1.0
message: Error occurred during deployment: Exception while preparing t
he app : Exception [EclipseLink-28018] (Eclipse Persistence Services

  • 2.2.0.v20110202-r8913): org.eclipse.persistence.exceptions.EntityMa
    %%%EOL%%%Exception Description: Predeployment of
    %%%EOL%%%Internal Exception: Excep.
    tion [EclipseLink-7333] (Eclipse Persistence Services - 2.2.0.v201102
    %%%-r8913): org.eclipse.persistence.exceptions.ValidationException
    EOL%%%Exception Description: The reference column name [foo] mapped o
    n the element [field userCredentials] does not correspond to a valid
    field on the mapping reference.. Please see server.log for more detai
    ls.
    name_value: basicwebapp
    name_name: name
    keys: name
    use-main-children-attribute: false
    exit-code: FAILURE

------- RAW RESPONSE ---------
PROCESSING MANIFEST...
remote failure: Error occurred during deployment: Exception while preparing the app : Exception [EclipseLink-28018] (Eclipse Persistence Services - 2.
2.0.v20110202-r8913): org.eclipse.persistence.exceptions.EntityManagerSetupException
Exception Description: Predeployment of PersistenceUnit [pujavaee] failed.
Internal Exception: Exception [EclipseLink-7333] (Eclipse Persistence Services - 2.2.0.v20110202-r8913): org.eclipse.persistence.exceptions.Validation
Exception
Exception Description: The reference column name [foo] mapped on the element [field userCredentials] does not correspond to a valid field on the mappi
ng reference.. Please see server.log for more details.
Command deploy failed.

d:\j2eeapps>

Comment by Byron Nevins [ 13/Jul/11 ]

Comment from my code checkin

16954
GIGO. The server, actually Deployment, is sending back a corrupt (garbage!!) Manifest object. The JDK Manifest class implementation itself fails to parse it.
There is absolutely nothing that CLI can do to "fix" this.
BUT – the error message was not correct – it incorrectly assumed that it was a badly formatted plaintext return object.
I fixed the error message. The real fix must be done server-side in deployment code.

Comment by Hong Zhang [ 13/Jul/11 ]

assign to tim to follow up as tim had previously worked on it already

Comment by Tim Quinn [ 13/Jul/11 ]

I do not see how it is deployment that is the problem here. Deployment invokes the published methods on ActionReport to set the report's message. (DeployCommand, line 440)

It should be up to the various report implementations - such as PropsFileActionReporter - to do the right thing with the values presented to it. Because it's PropsFileActionReporter that knows it expresses the report as a manifest, it should be that class that does whatever is needed to correctly handle any value passed to it so it does not create an invalid manifest.

I'm passing the baton back to the admin component, because it cannot be deployment's responsibility to know that the particular implementation of ActionReport at hand is not handling the message correctly.

Comment by Byron Nevins [ 13/Jul/11 ]

Original problem is resolved





[GLASSFISH-16932] Adding and removing virtual server for an application does not take effect Created: 01/Jul/11  Updated: 20/Dec/16

Status: Open
Project: glassfish
Component/s: deployment
Affects Version/s: 3.1.1_dev
Fix Version/s: future release

Type: Bug Priority: Major
Reporter: lidiam Assignee: Hong Zhang
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

FF5, WinXP, ogs-3.1.1-b10-06_28_2011.zip


Attachments: File domain.xml.after.vs.remove     File domain.xml.vs.added     File hello.war    
Tags: 3_1_1-scrubbed, 3_1_x-exclude

 Description   

Adding or removing virtual servers to an already deployed application does not seem to take effect: after adding a virtual server application cannot be accessed. Once it's made accessible, after removing a virtual server from the application one can still access it on the virtual server listener port. Steps to reproduce follow.

1. Create a cluster with one instance, e.g. cl with clin.
2. Start cluster.
3. Deploy an application, e.g. hello.war, to DAS and cluster.
4. Go to cl-config, Virtual Servers and create a new virtual server: enter virtual server name only, e.g. clvs.
5. In cl-config create a Network Listener: type name, e.g. http-listener-clvs, select Create Protocol (it should be automatically populated), select clvs for Default Virtual Server, type port, e.g. 85 and address as 0.0.0.0 and select http-thread-pool.
6. At this point you should be able to access the new virtual server on http://<machine name>:85.
7. Go to Applications and select previously deployed hello.war. Click on Target tab, Manage Virtual Servers link for the cluster target, cl.
8. Add virtual server, clvs, to Selected Targets, click Save.
9. At this point the expectation is that the hello.war application should be available under http://<machine name>:85/hello but the url brings 404 error. The domain.xml file contains the virtual server in the application-ref:

<clusters>
<cluster gms-multicast-port="4932" gms-bind-interface-address="$

{GMS-BIND-IN TERFACE-ADDRESS-cl}" name="cl" gms-multicast-address="228.9.107.160" config-ref=
"cl-config">
<application-ref ref="hello" virtual-servers="server,clvs"></application-r
ef>

10. One way to force the application to work on the virtual server is to make it a Default Module: go to cl-config, clvs virtual server and select hello under Default Web Module. Save.
11. Now we can access the app at http://<machine name>:85/hello.
12. Go to the application targets, Manage Virtual Servers again and remove clvs from the Selected Targets, save.
13. The reference is removed from:

<clusters>
<cluster gms-multicast-port="4932" gms-bind-interface-address="${GMS-BIND-INTERFACE-ADDRESS-cl}

" name="cl" gms-multicast-address="228.9.107.160" config-ref=
"cl-config">
<application-ref ref="hello" virtual-servers="server"></application-ref>

but not from the clustered instance:

<servers>
<server name="clin" node-ref="localhost-domain1" config-ref="cl-config">
<application-ref ref="hello" virtual-servers="server,clvs"></application-ref>

I'm attaching domain.xml at this point. One can still access the application via http://<machine name>:85/hello.



 Comments   
Comment by lidiam [ 01/Jul/11 ]

Attaching domain.xml after the virtual server is added as target to the application: cluster app reference is updated but clustered instance is not.

Comment by Anissa Lam [ 01/Jul/11 ]

I believe console is doing the right thing and domain.xml reflects what user done correctly.
Transferring to web container for evaluation.
Please reassign if needed.

I changed the affected version to b09 since b10 is not out yet.

Comment by Anissa Lam [ 01/Jul/11 ]

I can reproduce this following the same steps.
To summarize the bug, adding a VS to a cluster doesn't propagate the VS info to the cluster's instance.

I see that when adding the VS to the cluster, the application-ref of the cluster is updated correctly to include the newly added VS.

<cluster gms-multicast-port="26825" gms-bind-interface-address="${GMS-BIND-INTERFACE-ADDRESS-ABC-TEST}" name="ABC-TEST" gms-multicast-address="228.9.5.2" config-ref="ABC-TEST-config">
      <application-ref ref="hello" virtual-servers="server,TESTvs"></application-ref>
      <server-ref ref="TEST-1"></server-ref>
      <property name="GMS_LISTENER_PORT" value="${GMS_LISTENER_PORT-ABC-TEST}"></property>
    </cluster>

however, the instance itself doesn't have the VS added.

<server name="TEST-1" node-ref="localhost-domain1" config-ref="ABC-TEST-config">
      <application-ref ref="hello" virtual-servers="server"></application-ref>
    </server>

I believe whoever is listening to the addition of VS to application-ref of a cluster, should propagate this to ALL its instance. The target is the cluster for user to issue commands, not each of the instance. CLI user will have the same problem when using dotted name to set the VS of the cluster's application-ref.

I am not sure who should be responsible to this part of the code, whether it is admin or deployment.

Comment by Shing Wai Chan [ 01/Jul/11 ]

When I run
asadmin set servers.server.clin.application-ref.hello.virtual-servers=server,clvs

it works. This confirms that the observation above.

Comment by Hong Zhang [ 05/Jul/11 ]

Will check with Tom to see if there is anything at admin level which handles this kind of cluster/instance config update.
Anissa: I vaguely remembered in v2 we had similar issue, and console sends explict config update request for each cluster instance as well as the overall cluster? Maybe we need to do something similar here?

Comment by Anissa Lam [ 06/Jul/11 ]

Summary of the issue: If an application is deployed to a cluster, then adding newly created Virtual Servers to this target will not be reflected
in the <application-ref> of the cluster's instance.

Workaround: Remove the cluster target, and then add this cluster target back.

Maybe there should be a command similar to create-application-ref.
create-application-ref takes in a cluster as target, and propagating the info to all the instance of the cluster (ie, create the application-ref),
this new command should also take in a cluster as target, and propagate the VS info to all the <application-ref> of the instance of this cluster.

relying on user to call the 'set' command to set the VS of the <application-ref> of the cluster, and then run the set command again on all the instances of the cluster
so that the cluster and instances <application-ref> reflects the same VS attribute is very error-prone.

Comment by Hong Zhang [ 18/Oct/11 ]

We will look at the new command in the trunk.

Comment by Hong Zhang [ 12/Dec/12 ]

Scrubbing issues for GlassFish 4.0.





[GLASSFISH-16868] Monitoring AMX MBeans not getting created Created: 15/Jun/11  Updated: 20/Dec/16  Resolved: 13/Dec/11

Status: Resolved
Project: glassfish
Component/s: monitoring
Affects Version/s: 4.0
Fix Version/s: 4.0_dev

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

WinXP


Tags: 3_1_1-exclude, 3_1_1-scrubbed, 3_1_x-exclude

 Description   

I see 404 messages with IDs MNTG0201 and MNTG0204 in my server.log after
a QL run on the latest 3.2 workspace but they do not show up in Hudson's
logs. Maybe a Windows only issue?

[#|2011-06-15T11:19:51.123+1000|WARNING|glassfish3.2|javax.enterprise.sy
stem.tools.monitor.org.glassfish.admin.monitor|_ThreadID=29;_ThreadName=
Thread-1;|MNTG0201:Flashlight listener registration failed for listener
class : com.sun.ejb.monitoring.stats.StatefulSessionBeanStatsProvider ,
will retry later |#]

[#|2011-06-15T11:19:51.170+1000|INFO|glassfish3.2|javax.enterprise.syste
m.tools.monitor.org.glassfish.admin.monitor|_ThreadID=29;_ThreadName=Thr
ead-1;|MNTG0204:com.sun.ejb.monitoring.stats.EjbMethodStatsProvider is
not a ManagedObject and will not be registered with Gmbal to create an
MBean|#]

Especially the latter is not particularly informative to users like me.
Can't it be logged with level FINE?

Jennifer added:
The MNTG0201 msg may be ok
The MNTG0204 msg means the monitoring AMX MBean are not getting
created. I ran ql on windows and see these messages also. And the
mbeans don't appear in jconsole.
Definitely a bug. Maybe it should be logged as SEVERE or WARNING.



 Comments   
Comment by Jennifer Chou [ 16/Jun/11 ]

In StatsProviderManagerDelegateImpl the call to ManagedObjectManagerFactory.createFederated(MONITORING_SERVER) is returning ManagedObjectManagerNOPImpl, which always returns false for isManagedObject(..).

In the ManagedObjectManagerFactory the call to objectNameCons.create( rootParentName ), where rootParentName is "amx:name=server,pp=/mon,type=server-mon", always returns null, which is why the ManagedObjectManagerNOPImpl is returned above.

Ken - Can you see why does create return null here?

StatsProviderManagerDelegateImpl.java (admin\monitor)
=====================================================

MONITORING_SERVER = AMXGlassfish.DEFAULT.serverMon(instanceName);

private ManagedObjectManager registerGmbal(Object statsProvider, String mbeanName) {
ManagedObjectManager mom = null;
try {
// 1 mom per statsProvider
mom = ManagedObjectManagerFactory.createFederated(MONITORING_SERVER);<-----
if (mom != null) {
mom.setJMXRegistrationDebug(true);
if (mom.isManagedObject(statsProvider))

{ ..................................................... }

else {
String spName = statsProvider.getClass().getName();
logger.log(Level.INFO, "notaManagedObject", new Object[]

{spName}

);
}
}

AMXGlassfish
============

public ObjectName serverMon(final String serverName)

{ return newObjectName("/mon", "server-mon", serverName); }

ManagedObjectManagerFactory (gmbal)
===========================

public static ManagedObjectManager createFederated(
final ObjectName rootParentName ) { <---- "amx:name=server,pp=/mon,type=server-mon"

ManagedObjectManager result = objectNameCons.create( rootParentName ) ;
if (result == null)

{ <----- result = null return ManagedObjectManagerNOPImpl.self ; }

else

{ return result ; }

}

The problem appears on windows but not on hudson.
To reproduce:

If you have run quicklook already:

1. asadmin start-domain
2. jconsole (connect remote localhost:8686, no user/password)

OR

1. asadmin start-domain
2. asadmin set configs.config.server-config.monitoring-service.module-monitoring-levels.jvm=HIGH
3. jconsole

Comment by Jennifer Chou [ 13/Jul/11 ]

Fixed by Snjezana on the GlassFish side:

47976 12.07.2011 21:22:19, by snjezana
Adding gmbal-api-only.jar to global exclude list since its presence is apparently
causing issues with monitoring runtime.
M /trunk/v3/packager/pom.xml

Justin - can you take a look on the Grizzly side if you need to scope this dependency on gmbal-api-only as "provided"?

Email thread on cause:

I see - gmbal-api-only.jar is being pulled into distribution as transitive maven dependency by recent trunk grizzly integrations. I think grizzly should be scoping this dependency as "provided" but in the meantime I'll add this jar to global exclude list so that should resolve the problem.

Thanks,

Snjezana

----- Original Message -----
From: jennifer.chou@oracle.com
To: snjezana.sevozenzerovic@oracle.com
Cc: jagadish.ramu@oracle.com, shalini.muthukrishnan@oracle.com
Sent: Tuesday, July 12, 2011 12:03:05 PM GMT -08:00 US/Canada Pacific
Subject: [Fwd: Re: Gmbal dependency]

Hi Snejzana,

Could the following be related to packaging changes? Somehow the gmbal-api-only.jar got added to the distribution. This is causing the monitoring mbeans to not get created (in ext4 filesystem). When I remove gmbal-api-only.jar from the modules directory, then the monitoring mbeans works fine.

Jennifer

-------- Original Message --------
Subject: Re: Gmbal dependency
Date: Tue, 12 Jul 2011 23:50:54 +0530
From: Jagadish Prasath Ramu <jagadish.ramu@oracle.com>
Reply-To: jagadish.ramu@oracle.com
Organization: Oracle
To: Jennifer Chou <jennifer.chou@oracle.com>
CC: Shalini <shalini.muthukrishnan@oracle.com>
References: <4E1BEB94.508@oracle.com> <4E1C7704.6090705@oracle.com>

Thanks to Sahoo, the root cause was due to the order in which the
modules get installed in a particular file system.
In ext4 filesystem, gmbal-api-only.jar is installed before gmbal.jar and
hence File.listFiles(..) bootstraps only gmbal-api.jar (Both
gmba-api.jar and gmbal.jar export common set of classes).
gmbal-api-only.jar looks for an implementation class which is in
gmbal.jar. As gmbal.jar is not resolved, MBeans were not registered.
As Shalini stated, duplicate classes should not be there.


Thanks,
-Jagadish
Sun, an Oracle Company.

On Tue, 2011-07-12 at 12:32 -0400, Jennifer Chou wrote:
> Ah ha thanks for finding this! I have been trying to track down which
> revision was the cause of breaking the monitoring mbeans because I
> noticed also the ManagedObjectManagerNOPImpl being returned.
>
> I can reproduce this also on my window laptop.
>
> Thanks,
> Jennifer
>
> On 7/12/2011 2:37 AM, Shalini wrote:
> > Hi Jennifer,
> >
> > We observed that there are 2 jars : gmbal.jar and gmbal-api-only.jar
> > in the latest trunk workspace, whereas in 3.1.1 there is just one :
> > gmbal.jar. gmbal-api-only.jar is a subset of the gmbal.jar and this
> > causes some issues on an ext4 filesystem. The ManagedObjectManagerImpl
> > could not be resolved and only a ManagedObjectManagerNOPImpl is
> > returned while a register is done on the stats provider object. When
> > this is used to do isManagedObject(), it always returns false and
> > hence the stats providers are not registered.
> >
> > This can be reproduced on any ext4 filesystem on the latest trunk
> > build. You could do an "ant all" under
> > appserv-tests/devtests/jdbc/markconnectionasbad.xa testcase. We would
> > get an InstanceNotFoundException. This should be fixed by removing the
> > duplicate gmbal-api-only.jar dependency.
> >
> > Thanks
> > Shalini.
> >

Comment by Jennifer Chou [ 13/Jul/11 ]

Can you check for Grizzly if you need to scope the dependency on gmbal-api-only as "provided"?

Comment by oleksiys [ 13/Dec/11 ]

had to be fixed as part of Grizzly->GF repackaging.





[GLASSFISH-16855] alarming info message about a file that can't be read Created: 13/Jun/11  Updated: 02/Dec/11  Resolved: 14/Jun/11

Status: Resolved
Project: glassfish
Component/s: admin
Affects Version/s: 4.0
Fix Version/s: 4.0

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

WinXP, Hudson CI


Tags: 3_1_x-exclude

 Description   

The following alarming 'info' message is logged during QL:

[#|2011-06-13T18:54:09.387-0700|INFO|glassfish3.2|javax.enterprise.system.tools.admin.com.sun.enterprise.admin.util|_ThreadID=14;_ThreadName=Thread-1;|unable to read instance state file /export/home1/java_re/BUILD_AREA/workspace/gf-trunk-build-continuous/gfv3-gp/glassfish3/glassfish/domains/domain1/config/.instancestate, recreating|#]

Messages in LogStrings.properties are supposed to have message IDs, but in this case it should either probably be changed to FINE level so as not to alarm users.



 Comments   
Comment by Tom Mueller [ 14/Jun/11 ]

Fixed on the trunk in revision 47465.

Comment by Tom Mueller [ 17/Oct/11 ]

Marking as excluded from 3.1.x releases.





[GLASSFISH-16852] [PERF] Large performance regression from grizzly character conversion Created: 13/Jun/11  Updated: 20/Dec/16  Resolved: 13/Dec/11

Status: Closed
Project: glassfish
Component/s: grizzly-kernel
Affects Version/s: 4.0
Fix Version/s: 4.0_dev

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

Issue Links:
Dependency
blocks GLASSFISH-16851 [PERF] Large peformance regressions i... Closed
Tags: 3_1-next, 3_1_1-scrubbed, 3_1_x-exclude, PSRBUG

 Description   

In glassfish tests after moving to grizzly 2.0 (glassfish b06), we see huge performance regressions from the encoding of page results. Profiles indicated that most of this time is spent in sun.nio.cs.UTF_8.newDecoder(), which is the result of org.glassfish.grizzly.memory.HeapBuffer calling new String(byte[], int, int, Charset).



 Comments   
Comment by oleksiys [ 15/Jun/11 ]

we created and fixed grizzly issue
http://java.net/jira/browse/GRIZZLY-1027

will mark this issue as fixed with the next grizzly integration

Comment by oleksiys [ 13/Dec/11 ]

fixed





[GLASSFISH-16843] Negative value reported for "number of open connections" Created: 10/Jun/11  Updated: 02/Dec/11  Resolved: 22/Sep/11

Status: Resolved
Project: glassfish
Component/s: grizzly-kernel
Affects Version/s: 4.0
Fix Version/s: 4.0

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

Mac OS X 10.6, glassfish 3.1


Tags: 3_1-next, 3_1_1-scrubbed, 3_1_x-exclude

 Description   

Turn monitoring to "HIGH" for WebContainer and HttpService. Executed the following CLI command :
get -m server.http-service.__asadmin.request.countopenconnections-count

Result :
server.http-service.__asadmin.request.countopenconnections-count = -148



 Comments   
Comment by Amy Roh [ 13/Jun/11 ]

ConnectionMonitor monitors the number of open connections via onAcceptEvent and onCloseEvent methods. The onAcceptEvent method only invokes the connectionAcceptedEvent and therefore increasing the open connection count if the connection's peer address is not NULL. However, the onCloseEvent method invokes the connectionClosedEvent and decrease the count regardless of the connection's peer address. This is causing the count to be a negative number.

@Override
public void onAcceptEvent(final Connection connection) {
final Object peerAddress = connection.getPeerAddress();

if (peerAddress != null)

{ // if peerAddress is null - it's a server connection. we should skip. grizzlyMonitoring.getConnectionQueueProbeProvider().connectionAcceptedEvent( monitoringId, connection.hashCode(), peerAddress.toString()); }

}

@Override
public void onCloseEvent(Connection connection)

{ grizzlyMonitoring.getConnectionQueueProbeProvider().connectionClosedEvent( monitoringId, connection.hashCode()); }

It appears that ConnectionMonitor#onAcceptEvent(final Connection connection) is always called with peer address NULL and the open connection count never gets incremented.

Assigning to Alexey to investigate why grizzly connection peer address is always NULL.

Comment by oleksiys [ 14/Jun/11 ]

just to make sure, it's Glassfish 3.2 related?

Comment by oleksiys [ 04/Jul/11 ]

ping

Comment by Jennifer Chou [ 21/Sep/11 ]

Forum user is also having an issue seeing negative activesessionscurrent.
http://forums.java.net/node/844876

Comment by Amy Roh [ 21/Sep/11 ]

I see that the part of the condition that was causing the discrepancy has been removed in 48946.

bash-3.2$ svn diff -r48076:48946 ConnectionMonitor.java
Index: ConnectionMonitor.java
===================================================================
— ConnectionMonitor.java (revision 48076)
+++ ConnectionMonitor.java (revision 48946)
@@ -61,15 +61,13 @@
}

@Override

  • public void onAcceptEvent(final Connection connection) {
  • final Object peerAddress = connection.getPeerAddress();
    + public void onAcceptEvent(final Connection serverConnection,
    + final Connection clientConnection) {
    + final Object peerAddress = clientConnection.getPeerAddress();
  • if (peerAddress != null) { // if peerAddress is null - it's a server connection. we should skip. - grizzlyMonitoring.getConnectionQueueProbeProvider().connectionAcceptedEvent( - monitoringId, connection.hashCode(), - peerAddress.toString()); - - }

    + grizzlyMonitoring.getConnectionQueueProbeProvider().connectionAcceptedEvent(
    + monitoringId, clientConnection.hashCode(),
    + peerAddress.toString());
    }

Comment by oleksiys [ 22/Sep/11 ]

fixed





[GLASSFISH-16826] Remove workaround in AdminAdapter for client SSL cert renegot; add new Grizzly config setting during enable-secure-admin Created: 09/Jun/11  Updated: 02/Dec/11  Resolved: 21/Sep/11

Status: Resolved
Project: glassfish
Component/s: admin
Affects Version/s: 4.0
Fix Version/s: 4.0

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

Tags: 3_1_1-scrubbed, 3_1_x-exclude

 Description   

The AdminAdapter contains a workaround to avoid checking for a client SSL cert if it's the DAS receiving the request. This avoids a problem triggered when Grizzly tries to renegotiate (to ask for the client cert) after the request's payload has begun to arrive.

With a new Grizzly integration into 3.2 this workaround will become unnecessary and should be removed. At the same time the enable-/disable-secure-admin commands should be changed to manage one more Grizzly config setting. The new attribute renegotiate-on-client-auth-want on the ssl element defaults to true; when enable-secure-admin creates the <network-config><protocol name="sec-admin-listener"><ssl> element it needs to set <ssl renegotiate-on-client-auth-want="false">.



 Comments   
Comment by Tim Quinn