[GLASSFISH-12188] Connections with empty password produce undocumented null exception Created: 09/Jun/10  Updated: 22/Aug/13  Resolved: 23/Mar/11

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

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

Operating System: All
Platform: Linux


Attachments: XML File domain.xml    
Issue Links:
Duplicate
is duplicated by GLASSFISH-6271 asadmin create-jdbc-connection-pool p... Resolved
Issuezilla Id: 12,188

 Description   

Since v3.0.1 b18 it is not possible to connect to our MySQL database with an
empty password. In earlier versions it worked.

The following exception occurs, when I ping the ConnectionPool with the empty
password:
Error An error has occurred
Ping failed Exception - null Please check the server.log for more details.

How to reproduce the error:
You need a database that has a user with an empty password.

1. Create ConnectionPool for the database, either with asadmin, from the admin
gui or by hand inside the domain.xml
2. The password is set to "()", the empty word representation, inside the admin gui
3. Open the ConnectionPool inside the admin gui and click on ping
-> The following exception occurs: Ping failed Exception - null Please check
the server.log for more details.
-> server.log
[#|2010-06-09T14:02:15.525+0200|WARNING|glassfish3.0.1|javax.enterprise.resource.resourceadapter.com.sun.enterprise.connectors.service|_ThreadID=38;_ThreadName=Thread-1;|RAR8054:
Exception while creating an unpooled [test] connection for pool [ GPMSPool ],
null|#]

4. Change password to some nonesense password, e.g. abc
5. Ping works as expected
-> Ping failed Exception - Connection could not be allocated because: Access
denied for user 'user'@'host' (using password: YES) Please check the server.log
for more details.

6. Remove password
7. Ping works as expected
-> Ping failed Exception - No PasswordCredential found Please check the
server.log for more details

I could reproduce this exception for newer builds (19,20 and 21).



 Comments   
Comment by rjdkolb [ 09/Jun/10 ]

add cc

Comment by rjdkolb [ 09/Jun/10 ]

This issue is probably related to :
https://glassfish.dev.java.net/issues/show_bug.cgi?id=912
But that issue is for GlassFish 2.1 and has been demoted to P4

I am going to try reproduce on MySQL and Oracle

Comment by rjdkolb [ 14/Jun/10 ]

I was unable to recreate in 3.0.1 b21 and creating the pool in the Admin GUI
I connected to my MySQL database as user root and password I left blank.

Can you please attach your offending domain.xml

Step I used
1) Install new GlassFish 3.0.1 B21
2) Copy in MySQL driver mysql-connector-java-5.1.12-bin.jar
3) start glassfish
4) connect to admin GUI
5) Create new connection pool of vendor MySQL
6) specify Url and URL as jdbc:mysql://127.0.0.1:3306/
7) Leave Password blank
8) Ping via GUI
9) Success

Can you please try again. Maybe there is something different you are doing.
If you can identify that, we have an issue

Comment by Lukas Jelonek [ 14/Jun/10 ]

Beforehands I used an old mysql connector. But an update from 5.1.6 to the
latest one 5.1.12 did not change anything. I observe the problem using Ubuntu
linux and solaris connecting to a mysql-db. I also installed Gf b21 from scratch.

Hi thanks for checking. Does your root user need a password, e.g. is it needed
to run the mysql commandline tool with -p as parameter and then enter no
password to access the database via commandline?

In the admin console -> In the properties for the connection pool -> Do you have
the following properties:

databaseName = testdb
serverName = localhost
user = anon
password = ()

The password property is the important one.

Here is the same information from the domain.xml

<jdbc-connection-pool
datasource-classname="com.mysql.jdbc.jdbc2.optional.MysqlDataSource" name="MyPool">
<property name="user" value="anon" />
<property name="databaseName" value="testdb" />
<property name="serverName" value="localhost" />
<property name="password" value="" />
</jdbc-connection-pool>
<jdbc-resource pool-name="MyPool" jndi-name="jdbc/MyConnection" />

Comment by rjdkolb [ 14/Jun/10 ]

> Does your root user need a password, e.g. is it needed
> to run the mysql commandline tool with -p as parameter and then enter no
> password to access the database via commandline?

Yes, as in I hit enter when prompted

> password = ()
>
> The password property is the important one.

Yes, I leave it blank. i.e. I don't fill anything in

> Here is the same information from the domain.xml
> <property name="password" value="" />

This is where we differ, I have a huge amount of properties, but password is not
in there. If I go to the admin GUI, I see password is not in the list.
Will attach my domain.xml because the section is huge

Which database vendor did you select ?

Comment by rjdkolb [ 14/Jun/10 ]

Created an attachment (id=4429)
Domain.xml of working domain, empty password

Comment by Lukas Jelonek [ 15/Jun/10 ]

>
>> password = ()
>>
>> The password property is the important one.
>
> Yes, I leave it blank. i.e. I don't fill anything in
>
You have to enter the brackets () as a placeholder for the empty string.
Otherwise the property will not be set.

> This is where we differ, I have a huge amount of properties, but password is not
> in there. If I go to the admin GUI, I see password is not in the list.
> Will attach my domain.xml because the section is huge

The large amount of properties is not that important. You can ignore them or
simply remove them. The problem does not depend on them. You can simply add the
password property or create a new connection pool and enter () in the password
field.

I neither see the user property in your domain.xml.

> Which database vendor did you select
MySql

Comment by Shalini [ 15/Jun/10 ]

This is a regression from the fix made to ManagedConnectionFactory as part of
https://glassfish-svn.dev.java.net/source/browse/glassfish-svn?rev=36846&view=rev.

Fixing this in 3.1.

Sending jdbc-core/src/main/java/com/sun/gjc/spi/ManagedConnectionFactory.java
Transmitting file data .
Committed revision 37775.

Comment by rjdkolb [ 15/Jun/10 ]

Just a note; after the fix, oops

My ping only passed because I did not spec a user.
When I spec a username and password of () I got this issue.

Comment by ceefour [ 03/Mar/11 ]

Please reopen this issue! It's NOT fixed.

I'm using GlassFish v3.1 and I cannot specify empty password.

The only way to specify empty password is to edit domain.xml file manually. However when editing the JDBC Connection Pool using the Admin Console UI, the UI will delete the password property and causing "No PasswordCredential found"

Comment by sumasri [ 22/Mar/11 ]

In a property table, if the property value/name is empty, that property will not be created and if the property value is (), property will be persisted with the empty value.

Added a test in WebContainerTest to test the property table.

Comment by ceefour [ 22/Mar/11 ]

Shouldn't the "Fix For" field be changed?

The bug still affects GlassFish 3.1.

Comment by sumasri [ 22/Mar/11 ]

GUI side, taken care of empty values in a property table. and transferring it to Shalini for further investigation..

Comment by Shalini [ 23/Mar/11 ]

Fixed in GUI by Suma in r45654. Issue not seen with command line interface. Any property that requires an empty value should be created using "()" as the value. It is persisted in the domain.xml as
<property name="someproperty" value=""/>

Comment by chammers [ 22/Aug/13 ]

This works - at least one time, then after the next save, the Password attribute is removed again.
Tested with GlassFish Server Open Source Edition 3.1.2.2 (build 5)





[GLASSFISH-16162] Cannot start standalone instance Created: 04/Mar/11  Updated: 09/Jan/13  Resolved: 10/Apr/11

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

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

solaris sparc


Attachments: HTML File 8691     HTML File 8743     File server.log.started-notrunning    

 Description   

I'm trying to start a standalone instance but the action hangs from both Admin Console and CLI. After trying with --verbose, with Joe's advice, here is what I see:

tuppy(j2eetest):/export/home/j2eetest/v3.1/glassfish3/glassfish# a start-local-instance --verbose in1
CLI801 Instance is already synchronized
Mar 4, 2011 5:52:23 PM com.sun.enterprise.admin.launcher.GFLauncherLogger info
INFO: JVM invocation command line:
/export/home/j2eetest/jdk/bin/java
-cp
/export/home/j2eetest/v3.1/glassfish3/glassfish/modules/glassfish.jar
-XX:+UnlockDiagnosticVMOptions
-XX:MaxPermSize=192m
-XX:NewRatio=2
-Xmx512m
-javaagent:/export/home/j2eetest/v3.1/glassfish3/glassfish/lib/monitor/btrace-agent.jar=unsafe=true,noServer=true
-server
-Dosgi.shell.telnet.maxconn=1
-Dfelix.fileinstall.disableConfigSave=false
-Djdbc.drivers=org.apache.derby.jdbc.ClientDriver
-Dfelix.fileinstall.dir=/export/home/j2eetest/v3.1/glassfish3/glassfish/modules/autostart/
-Djavax.net.ssl.keyStore=/export/home/j2eetest/v3.1/glassfish3/glassfish/nodes/localhost-domain1/in1/config/keystore.jks
-Dosgi.shell.telnet.port=26666
-Djava.security.policy=/export/home/j2eetest/v3.1/glassfish3/glassfish/nodes/localhost-domain1/in1/config/server.policy
-Dfelix.fileinstall.log.level=3
-Dfelix.fileinstall.poll=5000
-Dcom.sun.aas.instanceRoot=/export/home/j2eetest/v3.1/glassfish3/glassfish/nodes/localhost-domain1/in1
-Dosgi.shell.telnet.ip=127.0.0.1
-Dcom.sun.enterprise.config.config_environment_factory_class=com.sun.enterprise.config.serverbeans.AppserverConfigEnvironmentFactory
-Djava.endorsed.dirs=/export/home/j2eetest/v3.1/glassfish3/glassfish/modules/endorsed:/export/home/j2eetest/v3.1/glassfish3/glassfish/lib/endorsed
-Dcom.sun.aas.installRoot=/export/home/j2eetest/v3.1/glassfish3/glassfish
-Dfelix.fileinstall.bundles.startTransient=true
-Djava.ext.dirs=/export/home/j2eetest/jdk/lib/ext:/export/home/j2eetest/jdk/jre/lib/ext:/export/home/j2eetest/v3.1/glassfish3/glassfish/nodes/localhost-domain1/in1/lib/ext
-Dfelix.fileinstall.bundles.new.start=true
-Djavax.net.ssl.trustStore=/export/home/j2eetest/v3.1/glassfish3/glassfish/nodes/localhost-domain1/in1/config/cacerts.jks
-Dorg.glassfish.additionalOSGiBundlesToStart=org.apache.felix.shell,org.apache.felix.gogo.runtime,org.apache.felix.gogo.shell,org.apache.felix.gogo.command
-Dcom.sun.enterprise.security.httpsOutboundKeyAlias=s1as
-Djava.security.auth.login.config=/export/home/j2eetest/v3.1/glassfish3/glassfish/nodes/localhost-domain1/in1/config/login.conf
-DANTLR_USE_DIRECT_CLASS_LOADING=true
Dgosh.args=-noshutdown -c noop=true
-Djava.library.path=/export/home/j2eetest/v3.1/glassfish3/glassfish/lib:/export/home/j2eetest/jdk/jre/lib/sparc/server:/export/home/j2eetest/jdk/jre/lib/sparc:/export/home/j2eetest/jdk/lib/sparc:/usr/jdk/packages/lib/sparc:/lib:/usr/lib
com.sun.enterprise.glassfish.bootstrap.ASMain
-asadmin-args
-host,,,localhost,,,port,,,4848,,,secure=false,,,terse=false,,,echo=false,,,interactive=false,,,start-local-instance,,,verbose=true,,,-debug=false,,,in1
-instancename
in1
-verbose
true
-debug
false
-asadmin-classpath
/export/home/j2eetest/v3.1/glassfish3/glassfish/modules/admin-cli.jar
-asadmin-classname
com.sun.enterprise.admin.cli.AsadminMain
-upgrade
false
-type
INSTANCE
-instancedir
/export/home/j2eetest/v3.1/glassfish3/glassfish/nodes/localhost-domain1/in1
-read-stdin
true
Mar 4, 2011 5:52:23 PM com.sun.enterprise.admin.launcher.GFLauncherLogger info
INFO: Successfully launched in 100 msec.
Launching GlassFish on Felix platform
Exception in thread "main" 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.enterprise.glassfish.bootstrap.GlassFishMain.main(GlassFishMain.java:97)
at com.sun.enterprise.glassfish.bootstrap.ASMain.main(ASMain.java:55)
Caused by: java.lang.NullPointerException
at com.sun.enterprise.server.logging.SyslogHandler.postConstruct(SyslogHandler.java:88)
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 org.jvnet.hk2.component.Habitat$5.get(Habitat.java:701)
at java.util.AbstractList$Itr.next(AbstractList.java:345)
at com.sun.enterprise.server.logging.LogManagerService.postConstruct(LogManagerService.java:263)
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:219)
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)
... 6 more

The exception seems to come from logging, hence I'm logging this bug under this module.

A little background: I've been using this solaris system for verifying 3.1 bugs for the past week or so. I encountered this issue yesterday. The last thing I did was undeploy a hello.war application from this instance while it was stopped (didn't actually mean to do this). When I went to the standalone instance's page and clicked on Start button. The "processing, please wait" message was displayed and never went away. I checked CLI and it reported this instance as stopped but with odd status:

tuppy(j2eetest):/export/home/j2eetest/v3.1/glassfish3/glassfish/domains/domain1/logs# a list-instances
in1 not running [pending config changes are: _get-runtime-info; _get-runtime-info; ]
c1in1 running
in2 not running
Command list-instances executed successfully.

After reloading Admin Console, the instance was reported as stopped there too.

I checked jps -v and it looked like there were two in1 processes running:

tuppy(j2eetest):/export/home/j2eetest/v3.1/glassfish3/glassfish/domains/domain1/logs# jps -v
8743 ASMain -XX:+UnlockDiagnosticVMOptions -XX:MaxPermSize=192m -XX:NewRatio=2 -Xmx512m -javaagent:/export/home/j2eetest/v3.1/glassfish3/glassfish/lib/monitor/btrace-agent.jar=unsafe=true,noServer=true -Dosgi.shell.telnet.maxconn=1 -Dfelix.fileinstall.disableConfigSave=false -Djdbc.drivers=org.apache.derby.jdbc.ClientDriver -Dfelix.fileinstall.dir=/export/home/j2eetest/v3.1/glassfish3/glassfish/modules/autostart/ -Djavax.net.ssl.keyStore=/export/home/j2eetest/v3.1/glassfish3/glassfish/nodes/localhost-domain1/in1/config/keystore.jks -Dosgi.shell.telnet.port=26666 -Djava.security.policy=/export/home/j2eetest/v3.1/glassfish3/glassfish/nodes/localhost-domain1/in1/config/server.policy -Dfelix.fileinstall.log.level=3 -Dfelix.fileinstall.poll=5000 -Dcom.sun.aas.instanceRoot=/export/home/j2eetest/v3.1/glassfish3/glassfish/nodes/localhost-domain1/in1 -Dosgi.shell.telnet.ip=127.0.0.1 -Dcom.sun.enterprise.config.config_environment_factory_class=com.sun.enterprise.config.serverbeans.AppserverConfigEnvironmentFactory -Djava.endorsed.
...
8691 ASMain -XX:+UnlockDiagnosticVMOptions -XX:MaxPermSize=192m -XX:NewRatio=2 -Xmx512m -javaagent:/export/home/j2eetest/v3.1/glassfish3/glassfish/lib/monitor/btrace-agent.jar=unsafe=true,noServer=true -Dosgi.shell.telnet.maxconn=1 -Dfelix.fileinstall.disableConfigSave=false -Djdbc.drivers=org.apache.derby.jdbc.ClientDriver -Dfelix.fileinstall.dir=/export/home/j2eetest/v3.1/glassfish3/glassfish/modules/autostart/ -Djavax.net.ssl.keyStore=/export/home/j2eetest/v3.1/glassfish3/glassfish/nodes/localhost-domain1/in1/config/keystore.jks -Dosgi.shell.telnet.port=26666 -Djava.security.policy=/export/home/j2eetest/v3.1/glassfish3/glassfish/nodes/localhost-domain1/in1/config/server.policy -Dfelix.fileinstall.log.level=3 -Dfelix.fileinstall.poll=5000 -Dcom.sun.aas.instanceRoot=/export/home/j2eetest/v3.1/glassfish3/glassfish/nodes/localhost-domain1/in1 -Dosgi.shell.telnet.ip=127.0.0.1 -Dcom.sun.enterprise.config.config_environment_factory_class=com.sun.enterprise.config.serverbeans.AppserverConfigEnvironmentFactory -Djava.endorsed.

At this point I asked Joe for help and he confirmed that indeed there were two in1 processes on the system. I'm attaching thread dump for both of them. I also checked instance's server.log and it looks like the shutdown from that day was not clean. Here is the output of the shutdown from a couple days earlier on the same instance that completed:

[#|2011-02-23T19:04:20.327-0800|INFO|oracle-glassfish3.1|javax.enterprise.system
.tools.admin.org.glassfish.server|_ThreadID=79;_ThreadName=Thread-2;|JMXStartupS
ervice: Stopped JMXConnectorServer: null|#]

[#|2011-02-23T19:04:20.329-0800|INFO|oracle-glassfish3.1|javax.enterprise.system
.tools.admin.org.glassfish.server|_ThreadID=79;_ThreadName=Thread-2;|JMXStartupS
ervice and JMXConnectors have been shut down.|#]

[#|2011-02-23T19:04:20.330-0800|INFO|oracle-glassfish3.1|javax.enterprise.system
.core.com.sun.enterprise.v3.server|_ThreadID=79;_ThreadName=Thread-2;|Shutdown p
rocedure finished|#]

Feb 25, 2011 12:13:58 PM com.sun.enterprise.admin.launcher.GFLauncherLogger info
INFO: JVM invocation command line:
/export/home/j2eetest/jdk/bin/java

While the latest shutdown is missing the "Shutdown procedure finished" line:

[#|2011-03-03T15:49:31.811-0800|INFO|oracle-glassfish3.1|javax.enterprise.system
.tools.admin.org.glassfish.server|_ThreadID=1120;_ThreadName=Thread-2;|JMXStartu
pService: Stopped JMXConnectorServer: null|#]

[#|2011-03-03T15:49:31.813-0800|INFO|oracle-glassfish3.1|javax.enterprise.system
.tools.admin.org.glassfish.server|_ThreadID=1120;_ThreadName=Thread-2;|JMXStartu
pService and JMXConnectors have been shut down.|#]

Mar 3, 2011 3:51:25 PM com.sun.enterprise.admin.launcher.GFLauncherLogger info
INFO: JVM invocation command line:
/export/home/j2eetest/jdk/bin/java

At this point, I killed both processes and tried to start the instance again - it would still hang and the output of the verbose option is listed at the top (hence we came the full circle). I'm attaching server.log from the start of testing till the initial startup hang and thread dumps of both processes that belonged to the instance. The machine is still available for debugging.



 Comments   
Comment by naman_mehta [ 07/Mar/11 ]

Don't able to reproduce the same. Please provide me the exact steps to reproduce.

Looks like it's machine specific issue.

Comment by naman_mehta [ 21/Mar/11 ]

hi lidia,

Wouldn't able to reproduce the same. Assigning this issue in your name. If still reproducible by you then give me exact steps and machine details.

Comment by lidiam [ 22/Mar/11 ]

It is not an issue that can be easily reproduced. I do not know what caused it in the first place, however, since the outcome was quite severe, I was asked to log an issue. You can close it if you want. If anybody encounters it in the future, we can reopen.

Comment by lidiam [ 22/Mar/11 ]

One more note, Joe Di Pol was helping debug this issue and this is how far we got. I kept the machine intact for a couple of days for debugging, but Glassfish has been reinstalled since. Glassfish worked flawlessly on this machine for months, so it's not necessarily a machine specific issue. After reinstall everything is working fine again. Series of many steps got Glassfish in this situation and unfortunately can't be reproduced.

Comment by naman_mehta [ 22/Mar/11 ]

As per the comments by lidia this issue is not reproducible.

But to avoid NPE in the code made some changes to catch the same. Committed revision 45678.

Comment by Matthias Wimmer [ 14/Apr/11 ]

Same problem existed here today. I found the reason for this to be some configuration properties missing in the file logging.properties in the config directory within the domain.
The first missing properties, causing this exception was "com.sun.enterprise.server.logging.SyslogHandler.useSystemLogging". After I have added this property, glassfish did not catch a NullPointerException in line 88 of SyslogHandler.java. But I got the next exception for the property "com.sun.enterprise.server.logging.GFFileHandler.file", which was missing as well.
As I expected even more properties would miss, I then copied a logging.properties file from a working domain on an other server. With the new logging.properties glassfish did start again.

Probably the broken logging.properties file was produced by editing a log level setting using the web interface by one of my coleagues last night.

The broken logging.properties file produced by the web interface we had, solely contains the following content:

#GlassFish logging.properties list
#Wed Apr 13 22:02:29 UTC 2011
javax.enterprise.system.tools.admin.level=INFO
javax.enterprise.system.ssl.security.level=OFF
org.apache.jasper.level=INFO
javax.enterprise.system.tools.backup.level=INFO
javax.enterprise.resource.corba.level=INFO
javax.enterprise.resource.webcontainer.jsf.resource.level=INFO
javax.enterprise.system.core.classloading.level=INFO
javax.enterprise.resource.jta.level=INFO
java.util.logging.ConsoleHandler.level=FINEST
javax.enterprise.system.webservices.saaj.level=INFO
javax.enterprise.system.tools.deployment.level=INFO
javax.enterprise.system.container.ejb.level=INFO
javax.enterprise.system.core.transaction.level=INFO
org.apache.catalina.level=INFO
javax.enterprise.resource.webcontainer.jsf.lifecycle.level=INFO
javax.enterprise.resource.webcontainer.jsf.config.level=INFO
javax.enterprise.system.container.ejb.mdb.level=INFO
javax.enterprise.resource.webcontainer.jsf.timing.level=INFO
javax.enterprise.system.core.level=INFO
org.apache.coyote.level=INFO
javax.level=INFO
javax.enterprise.resource.webcontainer.jsf.taglib.level=INFO
com.nicbase.server.infra.keyvalue.level=FINEST
javax.enterprise.resource.javamail.level=INFO
javax.enterprise.system.webservices.rpc.level=INFO
javax.enterprise.system.container.web.level=INFO
javax.enterprise.system.util.level=INFO
javax.enterprise.resource.webcontainer.jsf.facelets.level=INFO
javax.enterprise.resource.resourceadapter.level=INFO
javax.org.glassfish.persistence.level=INFO
javax.enterprise.resource.webcontainer.jsf.context.level=INFO
javax.enterprise.resource.webcontainer.jsf.application.level=INFO
javax.enterprise.resource.jms.level=INFO
javax.enterprise.system.core.config.level=INFO
org.jvnet.hk2.osgiadapter.level=INFO
javax.enterprise.system.level=INFO
javax.enterprise.system.core.security.level=INFO
javax.enterprise.resource.sqltrace.level=FINE
javax.enterprise.resource.webcontainer.jsf.renderkit.level=INFO
javax.enterprise.system.webservices.registry.level=INFO
javax.enterprise.system.core.selfmanagement.level=INFO
javax.enterprise.resource.webcontainer.jsf.managedbean.level=INFO
org.glassfish.admingui.level=INFO
javax.enterprise.resource.jdo.level=INFO
javax.enterprise.system.core.naming.level=INFO

Comment by naman_mehta [ 14/Apr/11 ]

We added code for checking that properties is present or not so NPE is avoided now.

Tried to made changes under Logger Settings page from admin GUI but couldn't reproduce broken logging.properties file. So question is how to reproduce broken logging.properties file from web interface. Let me know if it's reproducible.

Comment by juergenschmied [ 22/Feb/12 ]

Same problem. Rebuilding logging.properties helped.

Comment by roinou [ 06/Apr/12 ]

Same problem here.

It happened in our PRODUCTION environment this morning. After a routine restart, it was no longer possible to restart the server. Thanks to this issue, we reconstructed the "logging.properties" from our ACCEPTANCE and it fixed the problem.

The question is, HOW did this file get corrupted? last modification date stated 2012/03/29, today is 2012/04/06. This is a serious issue, we lost 3 hours of working time this morning.

Comment by cobre420 [ 09/Jan/13 ]

Same trouble today (9.1.2013) with glassfish 3.1.2.2. end of stacktrace
at com.sun.enterprise.server.logging.SyslogHandler.postConstruct(SyslogHandler.java:86)
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:78)
at org.jvnet.hk2.component.Habitat$5.get(Habitat.java:703)
at java.util.AbstractList$Itr.next(AbstractList.java:345)
at com.sun.enterprise.server.logging.LogManagerService.postConstruct(LogManagerService.java:374)
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:78)
at com.sun.enterprise.v3.server.AppServerStartup.run(AppServerStartup.java:229)
at com.sun.enterprise.v3.server.AppServerStartup.doStart(AppServerStartup.java:145)
at com.sun.enterprise.v3.server.AppServerStartup.start(AppServerStartup.java:136)
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:69)
at com.sun.enterprise.glassfish.bootstrap.GlassFishMain$Launcher.launch(GlassFishMain.java:117)

Replacing the logging.properties helped.. Any advice or help, how to prevent from this behavior?





[GLASSFISH-16073] GMS1077 gms total message size is too big (default max is 4MB) is repeated in server log Created: 22/Feb/11  Updated: 14/Mar/12  Resolved: 20/Apr/11

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

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

Tags: 3-1_exclude, 3_1-next

 Description   

An attempt to send a message larger than GMS max message size results in repeated reporting of the WARNING
in server.log.

Here is sample message:
[#|2011-02-22T17:06:00.412-0500|WARNING|glassfish3.1|ShoalLogger|_ThreadID=24;_ThreadName=Thread-1;|GMS1077: total message size is too big: size = 12,584,300, max size = 4,196,352|#]

[#|2011-02-22T17:06:00.548-0500|WARNING|glassfish3.1|ShoalLogger|_ThreadID=32;_ThreadName=Thread-1;|GMS1077: total message size is too big: size = 12,584,366, max size = 4,196,352|#]

************************************

WORKAROUND:

A workaround exists if the default max gms message size is too small.
To create a cluster with a larger max message size, use the following command:

% asadmin create-cluster --properties "GMS_MAX_MESSAGE_LENGTH=8200000" theClusterName

****

To increase the max message size for an already created cluster, use the following command with cluster running.

$ asadmin set clusters.cluster.myCluster.property.GMS_MAX_MESSAGE_LENGTH=8200000
clusters.cluster.myCluster.property.GMS_MAX_MESSAGE_LENGTH=81200000
Command set executed successfully.

After setting the value, stop the cluster and DAS domain, then restart the DAS and the cluster with the new settings.



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

Fix is already known for this issue and is checked into shoal gms trunk.

Comment by Bobby Bissett [ 20/Apr/11 ]

This was integrated into GF in rev 45770 (before 3.1.1 branch was created).





[GLASSFISH-16108] validate-multicast tool can give duplicate results Created: 28/Feb/11  Updated: 14/Mar/12  Resolved: 29/Mar/11

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

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

Issue Links:
Dependency
depends on SHOAL-115 MultiCastReceiverThread is not cleari... Resolved
Tags: 3_1-next

 Description   

When running the "asadmin validate-multicast" command, there can be duplicate entries shown so that a host shows up more than once. For instance:

Received data from myhost (loopback)
Received data from someotherhost
Received data from myhost

'myhost' appears twice, when it should only be there once. This is a minor issue, and is due to a bug in the gms code that does not clear out the data buffer between receive() calls on the socket. If you run the tool with the --verbose option, you can see the full messages that are being received that cause the duplicate entries.

What's important is that the host name shows up at all, not how many times it shows up. But this could cause confusion with users (it confused me).



 Comments   
Comment by Bobby Bissett [ 28/Feb/11 ]

Adding a dependency to the Shoal issue. Will fix in trunk there and integrate into GF with another Shoal promotion.

Comment by Bobby Bissett [ 03/Mar/11 ]

This is now fixed in the Shoal workspace and will be in the next Shoal integration into GlassFish.

Comment by Bobby Bissett [ 29/Mar/11 ]

Fixed in revision 45770.





[GLASSFISH-16103] GMS fails to start on IPv6 only system Created: 25/Feb/11  Updated: 14/Mar/12  Resolved: 20/Apr/11

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

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

Oracle Enterprise Linux 5, with an IPv6-only stack. The ifconfig output is below. Note that
the eth0 interface is down but it is the first one listed.

  1. ifconfig -a
    eth0 Link encap:Ethernet HWaddr 00:09:3D:10:CF:C8
    BROADCAST MULTICAST MTU:1500 Metric:1
    RX packets:0 errors:0 dropped:0 overruns:0 frame:0
    TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:1000
    RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
    Interrupt:185 Memory:fe810000-fe820000

eth1 Link encap:Ethernet HWaddr 00:09:3D:10:CF:C9
inet6 addr: fe80::209:3dff:fe10:cfc9/64 Scope:Link
inet6 addr: fc01::25/96 Scope:Global
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:293292 errors:0 dropped:0 overruns:0 frame:0
TX packets:347212 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:228022244 (217.4 MiB) TX bytes:378699726 (361.1 MiB)
Interrupt:193 Memory:fe830000-fe840000

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:6863 errors:0 dropped:0 overruns:0 frame:0
TX packets:6863 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:6932837 (6.6 MiB) TX bytes:6932837 (6.6 MiB)

sit0 Link encap:IPv6-in-IPv4
NOARP MTU:1480 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)


Attachments: Java Archive File shoal-gms-impl.jar     File shoal.dif    
Tags: 3_1-exclude, 3_1-next

 Description   

To recreate the problem, create a cluster on an IPv6-only system with a single instance on another node. The cluster has to be created with the multicast address set as follows:

asadmin create-cluster --multicastaddress ff02::1 c1

Then restart the domain. The log will contain the following exception message:

[#|2011-02-24T22:43:19.510+0100|SEVERE|glassfish3.2|javax.org.glassfish.gms.org.glassfish.gms|_ThreadID=1;_ThreadName=Thread-1;|GMSAD1017: GMS failed to start. See stack trace for additional information.
com.sun.enterprise.ee.cms.core.GMSException: failed to join group c1
at com.sun.enterprise.ee.cms.impl.base.GMSContextImpl.join(GMSContextImpl.java:182)
at com.sun.enterprise.ee.cms.impl.common.GroupManagementServiceImpl.join(GroupManagementServiceImpl.java:381)
at org.glassfish.gms.GMSAdapterImpl.initializeGMS(GMSAdapterImpl.java:573)
at org.glassfish.gms.GMSAdapterImpl.initialize(GMSAdapterImpl.java:199)
at org.glassfish.gms.bootstrap.GMSAdapterService.loadModule(GMSAdapterService.java:218)
at org.glassfish.gms.bootstrap.GMSAdapterService.checkCluster(GMSAdapterService.java:192)
at org.glassfish.gms.bootstrap.GMSAdapterService.checkAllClusters(GMSAdapterService.java:180)
at org.glassfish.gms.bootstrap.GMSAdapterService.postConstruct(GMSAdapterService.java:132)
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)
Caused by: com.sun.enterprise.ee.cms.core.GMSException: initialization failure
at com.sun.enterprise.mgmt.ClusterManager.<init>(ClusterManager.java:142)
at com.sun.enterprise.ee.cms.impl.base.GroupCommunicationProviderImpl.initializeGroupCommunicationProvider(GroupCommunicationProviderImpl.java:164)
at com.sun.enterprise.ee.cms.impl.base.GMSContextImpl.join(GMSContextImpl.java:176)
... 23 more
Caused by: java.net.SocketException: Cannot assign requested address
at java.net.PlainDatagramSocketImpl.socketSetOption(Native Method)
at java.net.PlainDatagramSocketImpl.setOption(PlainDatagramSocketImpl.java:299)
at java.net.MulticastSocket.setNetworkInterface(MulticastSocket.java:506)
at com.sun.enterprise.mgmt.transport.BlockingIOMulticastSender.start(BlockingIOMulticastSender.java:165)
at com.sun.enterprise.mgmt.transport.grizzly.GrizzlyNetworkManager.start(GrizzlyNetworkManager.java:434)
at com.sun.enterprise.mgmt.ClusterManager.<init>(ClusterManager.java:140)
... 25 more

#]

The exception message persists even if the bind address is set to variables different values: the IPv6 site scope address, the IPv6 link scope address.

A shoal-gms-impl.jar file that fixes the problem, with the diffs is attached. Just put this JAR file into the glassfish/modules directory and GMS works fine on an IPv6-only system.

It is still unknown as to whether the existence of the eth0 that is disabled or the sit0 interfaces have anything to do with this problem, or whether there is some other IPv6 configuration change that could be made to workaround this problem. The problem does not show up on a dual stack system that uses both IPv4 and IPv6.

There are several Java problems related to multicast sockets and IPv6 reported in the past. The one that seems most relevant to this issue is:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6262075

The enclosed patch works around the issue by calling MulticastSocket.setInterface() instead of
setNetworkInteface and we are explicitly checking if network interface is considered UP before using it.



 Comments   
Comment by Joe Fialli [ 25/Feb/11 ]

Checked fix into shoal trunk.

Still needs to be integrated into glassfish 3.1.

Comment by Bobby Bissett [ 20/Apr/11 ]

This was integrated into GF in revision 45770 (before 3.1.1 branch created).





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

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

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

Attachments: File gf-16159.diff    
Tags: 3_1-next, 3_1-release-note-added, 3_1-release-notes, 3_1-upgrade

 Description   

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

/*

  • We don't need to validate the xml document now as that is the
  • job of the upgrade code in the application server. We're only
  • interested in the version information here, and if that is
  • somehow wrong then the upgrade process will fail downstream
  • as the document is parsed into serverbeans objects.
    */
    public Document getDomainDocumentElement(String domainFileName) {
    DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
    factory.setNamespaceAware(true);
    Document resultDoc = null;
    try { DocumentBuilder builder = factory.newDocumentBuilder(); resultDoc = builder.parse(new File(domainFileName)); }

    catch (Exception ex)

    Unknown macro: { logger.log(Level.WARNING, stringManager.getString("upgrade.common.could_not_create_doc", new Object [] {domainFileName, ex.toString()})); }

    return resultDoc;
    }

Example error:

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

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



 Comments   
Comment by Bobby Bissett [ 04/Mar/11 ]

The workaround is easy:

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

Comment by Bobby Bissett [ 04/Mar/11 ]

Patch, take 1.

Comment by Bobby Bissett [ 04/Mar/11 ]

This is fixed in revision 45411.

Comment by Scott Fordin [ 15/Mar/11 ]

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

Comment by Bobby Bissett [ 15/Mar/11 ]

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

Comment by Scott Fordin [ 15/Mar/11 ]

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

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

Comment by Snjezana Sevo-Zenzerovic [ 15/Mar/11 ]

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

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

Comment by Bobby Bissett [ 16/Mar/11 ]

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

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

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

Comment by Scott Fordin [ 08/Apr/11 ]

Added topic to 3.1 Upgrade Guide.

Comment by Scott Fordin [ 13/Apr/11 ]

Also added issue to 3.1 Release Notes.





[GLASSFISH-16276] get-health reports incorrect status using jdk7 b136 after cluster is stopped Created: 28/Mar/11  Updated: 14/Mar/12  Resolved: 16/Apr/11

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

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

10-machine cluster setup on linux 64bit



 Description   

used jdk7_b136 on b43 and get-health reported incorrect status after a successful cluster shutdown.
However, after stopping the cluster I get:
n1c1m1 failed since Mon Mar 28 02:32:24 UTC 2011
n1c1m2 failed since Mon Mar 28 02:32:24 UTC 2011
n1c1m3 stopped since Mon Mar 28 02:32:16 UTC 2011
n1c1m4 failed since Mon Mar 28 02:32:24 UTC 2011
n1c1m5 failed since Mon Mar 28 02:32:26 UTC 2011
n1c1m6 failed since Mon Mar 28 02:32:24 UTC 2011
n1c1m7 failed since Mon Mar 28 02:32:24 UTC 2011
n1c1m8 failed since Mon Mar 28 02:32:24 UTC 2011
n1c1m9 failed since Mon Mar 28 02:32:24 UTC 2011
Command get-health executed successfully.

http://aras2.us.oracle.com:8080/logs/gf31/gms//set_03_27_11_t_19_33_25/scenario_installonecluster_Sun_Mar_27_19_33_48_PDT_2011.html



 Comments   
Comment by Joe Fialli [ 28/Mar/11 ]

The instances are being stopped by stop-cluster. All instances are stopped in their server.log

>[#|2011-03-28T02:32:16.172+0000|INFO|glassfish3.1|ShoalLogger|_ThreadID=18;_ThreadName=Thread-1;|
> GMS1015: Received Group Shutting down message from member: server of group: clusterz1|#]
>
>[#|2011-03-28T02:32:16.315+0000|INFO|glassfish3.1|
>javax.enterprise.system.tools.admin.com.sun.enterprise.v3.admin.cluster|_ThreadID=115;_ThreadName=Thread-1;|
>Server shutdown initiated|#]
>
>[#|2011-03-28T02:32:16.322+0000|INFO|glassfish3.1|ShoalLogger|_ThreadID=115;_ThreadName=Thread-1;|
>GMS1096: member: n1c1m1 is leaving group: clusterz1|#]

The UDP notification message from the stopped instance to the DAS is being lost for 8 out of the 9
instances. The planned shutdown notification for n1c1m3 is received in DAS.

Could the test be rerun with following log-level set to FINEST to help track what is going wrong.

% asadmin set-log-level --target clusterz1 ShoalLogger=FINEST // enable FINEST ShoalLogger in clustered instances
% asadmin set-log-level ShoalLogger=FINEST // enable ShoalLogger in DAS server.log

Comment by Joe Fialli [ 30/Mar/11 ]

recreated failure and verified fix.

fix integrated into glassfish 3 trunk. should be in next build.

Comment by Joe Fialli [ 16/Apr/11 ]

fix integrated into 3.1.1 branch.





[GLASSFISH-16109] get-health command not showing rejoins Created: 28/Feb/11  Updated: 14/Mar/12  Resolved: 29/Mar/11

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

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

Issue Links:
Dependency
depends on SHOAL-116 rejoin subevent is null in JoinedAndR... Closed
Tags: 3_1-next

 Description   

When a rejoin event happens (an instance fails and restarts before GF knows it has failed), the status for it in 'asadmin get-health' shows started instead of rejoined. This is happening because the rejoin subevent is null in the JoinedAndReadyNotificationSignal. Am filing this for GF integration and will file a more technical one against Shoal to get the fix in.

This is a minor issue now because instances probably won't restart this quickly. But it would be good to get the fix in. To cause this, here's a snippet of domain.xml that leads to an absurdly long time to kill/restart an instance:

<group-management-service>
<failure-detection
heartbeat-frequency-in-millis="1800000"
max-missed-heartbeats="30"></failure-detection>
</group-management-service>



 Comments   
Comment by Bobby Bissett [ 28/Feb/11 ]

Adding dependency.

Comment by Bobby Bissett [ 02/Mar/11 ]

This has been fixed in the shoal workspace and will be in the next integration of shoal into glassfish.

Comment by Bobby Bissett [ 29/Mar/11 ]

Fixed in revision 45770.





[GLASSFISH-15866] Need to process EJB descriptors within .war for resource-adapter references Created: 05/Feb/11  Updated: 02/Dec/11  Resolved: 05/Feb/11

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

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

Tags: 3_1-exclude

 Description   

In order to determine the resource-adapter visibility for an application, we look at the applications descriptors for "resources", "resource-adapter-mid" related references.

In case of such a reference defined in an EJB in a .war, we seem to be missing them as we do not process "extensions" descriptors.

Fix would be to consider the extension descriptors of all of the bundle descriptors which will solve the potential issue.



 Comments   
Comment by Jagadish [ 05/Feb/11 ]

FIX INFORMATION :

svn log -v -r 44941
Modified Paths:
---------------
trunk/v3/connectors/connectors-internal-api/src/main/java/com/sun/appserv/connectors/internal/api/AppSpecificConnectorClassLoaderUtil.java





[GLASSFISH-16286] IllegalArgumentException: port out of range:-1 after config upgrades unit test Created: 30/Mar/11  Updated: 02/Dec/11  Resolved: 30/Mar/11

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

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


 Description   

[java] [#|2011-03-30T09:39:34.635-0700|SEVERE|glassfish3.2|com.sun.pkg.client.SystemInfo|_ThreadID=10;_ThreadName=main;|badproxy|#]
[java]
[java] [#|2011-03-30T09:39:34.639-0700|SEVERE|glassfish3.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=10;_ThreadName=main;|java.lang.IllegalArgumentException: port out of range:-1
[java] at java.net.InetSocketAddress.<init>(InetSocketAddress.java:118)
[java] at com.sun.pkg.client.AuthProxy.newProxy(AuthProxy.java:105)
[java] at com.sun.pkg.client.SystemInfo.loadProxyInfo(SystemInfo.java:201)
[java] at com.sun.pkg.client.SystemInfo.getProxySelector(SystemInfo.java:168)
[java] at com.sun.pkg.client.Image.<init>(Image.java:965)
[java] at com.sun.pkg.client.Image.<init>(Image.java:983)
[java] at com.sun.enterprise.registration.glassfish.RegistrationUtil.getUpdateCenterImage(RegistrationUtil.java:180)
[java] at com.sun.enterprise.registration.glassfish.RegistrationUtil.setUpdateCenterUUID(RegistrationUtil.java:187)
[java] at com.sun.enterprise.registration.glassfish.RegistrationUtil.synchUUID(RegistrationUtil.java:174)
[java] at com.sun.enterprise.registration.glassfish.PingService.postConstruct(PingService.java:92)
[java] at com.sun.hk2.component.AbstractCreatorImpl.inject(AbstractCreatorImpl.java:131)
[java] at com.sun.hk2.component.ConstructorCreator.initialize(ConstructorCreator.java:91)
[java] at com.sun.hk2.component.AbstractCreatorImpl.get(AbstractCreatorImpl.java:82)
[java] at com.sun.hk2.component.SingletonInhabitant.get(SingletonInhabitant.java:67)
[java] at com.sun.hk2.component.EventPublishingInhabitant.get(EventPublishingInhabitant.java:139)
[java] at com.sun.hk2.component.AbstractInhabitantImpl.get(AbstractInhabitantImpl.java:76)
[java] at com.sun.enterprise.v3.server.AppServerStartup.run(AppServerStartup.java:326)
[java] at com.sun.enterprise.v3.server.AppServerStartup.start(AppServerStartup.java:135)
[java] at com.sun.enterprise.v3.server.UpgradeStartup.start(UpgradeStartup.java:170)
[java] at com.sun.enterprise.glassfish.bootstrap.GlassFishImpl.start(GlassFishImpl.java:79)
[java] at com.sun.enterprise.glassfish.bootstrap.GlassFishMain$Launcher.launch(GlassFishMain.java:117)
[java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[java] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[java] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[java] at java.lang.reflect.Method.invoke(Method.java:597)
[java] at com.sun.enterprise.glassfish.bootstrap.GlassFishMain.main(GlassFishMain.java:97)
[java] at com.sun.enterprise.glassfish.bootstrap.ASMain.main(ASMain.java:55)
[java] |#]
[java]
[java] [#|2011-03-30T09:39:34.686-0700|INFO|glassfish3.2|null|_ThreadID=10;_ThreadName=main;|Exiting after upgrade|#]



 Comments   
Comment by Justin Lee [ 30/Mar/11 ]

these tests weren't exactly correct and are handled elsewhere so I just removed them.





[GLASSFISH-16057] Log Levels set for GF Handler is not working on start up. Created: 21/Feb/11  Updated: 02/Dec/11  Resolved: 10/Apr/11

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

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

Tags: 3_1-next

 Description   

If user reduce the log level for GF Handler 'SEVERE' it will not log any log messages rather than 'SEVERE'.

But in current GF release it's not working need to fix this in next release.



 Comments   
Comment by naman_mehta [ 05/Apr/11 ]

Fixed this issue. Added properties in logging templates which allows user to set log levels for the same and start up code will consider the same.





[GLASSFISH-16331] stop/start/restart domain local commands are yet not perfect Created: 10/Apr/11  Updated: 02/Dec/11  Resolved: 11/Apr/11

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

Type: Bug Priority: Critical
Reporter: Byron Nevins Assignee: Bill Shannon
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
depends on GLASSFISH-16335 Windows is still the Red-Haired StepC... Closed

 Description   

On (my) Windows QuickLook fails 100% of the time with one failure [1].

Here is what is happening:

(0) There is an empty (zero-byte) local-password file in the domain's config directory and the domain is definitely running.
(1) restart-domain is a subclass of StopDomain. StopDomain.executeCommand() sees that there is no valid local-password
(2) by DEFINITION, (1) means that the domain is NOT running.
(3) So now asadmin thinks that there is no DAS running – so it tries the improvement that was added --> start the domain
(4) (3) is done inside RestartDomain's dasNotRunning() method. It calls start-domain
(5) start-domain detects that its admin port is in use – and fails because of that.

Result – impossible to restart the running DAS without a forcible OS-level kill. It can not be restarted locally. It can not be stopped locally the normal way.

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

Question: What happened to the local-password file? Unknown. I didn't look into that. QL tests are hostile to debugging – it takes forever.

==============================
But this is a good bug that QL uncovered. This behavior is bad. It is fragile (brittle?). stopdomain shouldn't merely look for the magic file. It ought to also check and see if the admin port is in use. If so – it can call the _localdirectories(sp?) command on that port and see if it REALLY is the domain. Then emit a severe/warning message about the weird empty local password file.

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

Another EASY way to reproduce this bug –
1) start a domain
2) edit the local-password file. Make it empty and save it
3) restart-domain

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

Also –
restart-domain --kill is NOT working:

D:\glassfish3\glassfish\domains\domain1\config>asadmin restart-domain --kill
Server is not running, will attempt to start it...
There is a process already using the admin port 4848 – it probably is another instance of a GlassFish server.

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

[1]
test.admincli.RestartDomainTests:restartDomainTest

Restart domain failed. expected:<true> but was:<false>
org.testng.Assert.fail(Assert.java:84)
at org.testng.Assert.failNotEquals(Assert.java:438)
at org.testng.Assert.assertEquals(Assert.java:108)
at org.testng.Assert.assertEquals(Assert.java:239)
at test.admincli.RestartDomainTests.parseTestResults(RestartDomainTests.java:90)
at test.admincli.RestartDomainTests.restartDomainTest(RestartDomainTests.java:62)
23 lines not shown



 Comments   
Comment by Byron Nevins [ 10/Apr/11 ]

Wait a minute. Not so fast. I just ran

stop-domain --kill
start-domain

And there is a zero-byte local-password file! Maybe this was caused by Tim's recent changes?

Comment by Tim Quinn [ 10/Apr/11 ]

I am continuing this discussion in e-mail with Byron. Someone will post the net result here.

Comment by Byron Nevins [ 10/Apr/11 ]

LocalPasswordImpl runs before the logging service starts.
LocalPasswordImpl makes logging calls. These messages disappear into thin air.

This is what happens on my computer (Windows 7)

if (!(
localPasswordFile.setWritable(false, false) && // take from all
localPasswordFile.setWritable(true, true) && // owner only
localPasswordFile.setReadable(false, false) && // take from all
localPasswordFile.setReadable(true, true)
))

{ // owner only logger.log(Level.WARNING, "localpassword.cantchmod", localPasswordFile.toString()); // if we can't protect it, don't write it return; }

The if fires - a log message is written to thin air and it returns without writing the file.
The file will never fix itself – this will continue to fail forever - until the user deletes it, I suppose.

Catastrophic! I recommend deleting it in ALL cases – if possible. Then log to EarlyLogger with a *severe* message.

Even more curious is that the code above the chunk I pasted calls delete() on the file and true is returned but the file was NOT deleted.

Comment by Byron Nevins [ 10/Apr/11 ]

46057 is the culprit.

The security checks always fail on Windows.

Raising the priority for now. It is catastrophic for asadmin on windows

Comment by Bill Shannon [ 11/Apr/11 ]

Went back to ignoring the return values from these filesystem operations.
Fixed in trunk and 3.1.1 branch.





[GLASSFISH-15957] Need to return valid (existing) system rar names as per the distribution Created: 10/Feb/11  Updated: 02/Dec/11  Resolved: 12/Feb/11

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

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

Tags: 3_1-exclude

 Description   

Currently, connector runtime does not determine the profile in which its running while listing the system resource-adapters via hidden CLI commands for GUI,
as well while validating the resources (jms/connector) in a particular profile (web/classic).

Fix will be to determine the profile (by some means, eg: presence of RAR) and provide the system rars list appropriately. This way, in web profile, user will not be able to create a connector-connection-pool for jmsra/jaxr-ra (both are not included in web-profile) and appropriate error message (invalid RA name) can be provided.



 Comments   
Comment by Jagadish [ 10/Feb/11 ]

Refer the related issues :

http://java.net/jira/browse/GLASSFISH-15931
http://java.net/jira/browse/GLASSFISH-15933
http://java.net/jira/browse/GLASSFISH-15932

Comment by Jagadish [ 12/Feb/11 ]

FIX INFORMATION :

svn log -v -r 45077

Modified Paths:
---------------
trunk/v3/connectors/admin/src/main/java/org/glassfish/connectors/admin/cli/ConnectorConnectionPoolManager.java
trunk/v3/connectors/connectors-internal-api/src/main/java/com/sun/appserv/connectors/internal/api/ConnectorsUtil.java
trunk/v3/connectors/connectors-runtime/src/main/java/com/sun/enterprise/connectors/ConnectorRuntime.java
trunk/v3/connectors/connectors-internal-api/src/main/java/com/sun/appserv/connectors/internal/api/ConnectorsClassLoaderUtil.java
trunk/v3/connectors/admin/src/main/java/org/glassfish/connectors/admin/cli/AdminObjectManager.java





[GLASSFISH-16059] failure while processing resource-type of a resource-ref in an application that uses a resource-adapter artifact on non-DAS target Created: 21/Feb/11  Updated: 02/Dec/11  Resolved: 03/Mar/11

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

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

Tags: 3_1-exclude

 Description   

1) Deploy the resource-adapter to the instance
2) Create pool and resource with "target" as the instance
3) Deploy the application that uses the resources of the
resource-adapter to the instance.
[This will fail in DAS as there seem to be some processing happening in
DAS though the target is "instance"]

Exact failure is due to EjbBundleValidator making sure that the
resource-type of the resource-ref specified is valid.
[Refer EJBBundleValidator calling "resRef.checkType()" in the method
"accept()" ]

Above check will fail in DAS as the resource-adapter is not enabled (and
hence not available for the classloader hierarchy).

Workaround would be to deploy the resource-adapter and the application that uses the resource-adapter in DAS and then create application-ref in appropriate targets.



 Comments   
Comment by Hong Zhang [ 28/Feb/11 ]

This is related to my fix to
http://java.net/jira/browse/GLASSFISH-15058

Seems we should invoke the validation in the naming code like in v2 where the resource is actually being used (looked up).

Assign to Cheng to take a look.

Comment by Cheng Fang [ 03/Mar/11 ]

Sending common/container-common/src/main/java/com/sun/enterprise/container/common/impl/ComponentEnvManagerImpl.java
Sending deployment/dol/src/main/java/com/sun/enterprise/deployment/EnvironmentProperty.java
Sending deployment/dol/src/main/java/com/sun/enterprise/deployment/JmsDestinationReferenceDescriptor.java
Sending deployment/dol/src/main/java/com/sun/enterprise/deployment/util/EjbBundleValidator.java
Committed revision 45383.

I've moved the checkType from EjbBundleValidator to ComponentEnvManagerImpl,
which is roughly the equivalent as in v2.
I also added the same checkType for res-env-ref to be consistent with resource-ref.

I tested with invalid res-ref-type and res-env-ref-type (as in issue 15058), and either one will cause the deployment to fail with the correct exception and error message.

Jagadish tested with the resource adapter (thanks!) with the following comments:
<quote>
I tried with the resource-adapter that I was using before. It works fine
now. ie., even though the RAR (and the resource) are not available in DAS,
deployment works fine with your fix.
If I dont have the RAR available in the instance and try to deploy
the .ear that uses the resource of RAR, it fails as expected.
</quote>





[GLASSFISH-15809] JSF PhaseListener executed for each virtual host Created: 02/Feb/11  Updated: 04/Nov/11  Resolved: 04/Nov/11

Status: Resolved
Project: glassfish
Component/s: jsf
Affects Version/s: v3.0.1
Fix Version/s: 3.1.1_b01

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

We're running GlassFish 3.0.1 with JSF 2.1.0b11 on Windows 2007/7 64-bit.


Attachments: Text File 20110217-1558-i_gf_15809.patch     Text File 20110222-1610-i_gf_15809.patch     Text File i_gf_15809-workaround.txt    
Issue Links:
Dependency
depends on JAVASERVERFACES-1907 need to create a dev test for multipl... Closed
Status Whiteboard:

jsf_2_1_1

Tags: 3_1-exclude, 3_1-release-note-added, 3_1-release-notes

 Description   

We recently spend 2 months changing from JSF 1.2 to 2.0 and GlassFish 2 to 3.0.1. When we were finish with the conversion and ready to go live, we realised that JSF and virtual servers doesn't work together at all on GlassFish 3.0.1 with JSF 2.0. Luckily, this happened on January 27, 2011, the same day that JSF 2.1.0b11 became available with this fix included: http://java.net/jira/browse/GLASSFISH-11984. Otherwise we would have been completely screwed.

However, it didn't take many hours online, before we realised that something was horrible wrong. We have 6 virtual servers in addition to the default. We can't run with less than that. The problem is that all of our PhaseListeners are now executed one time per virtual server for a total of 7 times per request. And not just ours. PhaseListeners included in other projects, such as PrettyFaces, as well.

The problem has forced us to roll back to GF 2 and our 2 months old code once again.



 Comments   
Comment by Ed Burns [ 04/Feb/11 ]

The lack of a dev test bites us again.

Comment by Ed Burns [ 04/Feb/11 ]

Checking out the 2.1.0 branch now.

svn checkout https://svn.java.net/svn/mojarra~svn/branches/MOJARRA_2_1X_ROLLING mojarra-MOJARRA_2_1X_ROLLING

Sheetal, make sure you do the same.

Comment by Ed Burns [ 04/Feb/11 ]

Thankfully, Sheetal's patch for JAVASERVERFACES-1907 looks pretty good. I'm making a couple of small changes to ease the process of iteratively developing a reproducer for this issue (15809) and I'll attach that as a patch to 1907.

Comment by Ed Burns [ 04/Feb/11 ]

I'm going to attempt a workaround along the following lines. Provide a lifecyclefactory that decorates the original one and ensures there is one instance of each kind of lifecycle type per ServletContext.

Comment by Ed Burns [ 05/Feb/11 ]

Still getting the kinks worked out of JAVASERVERFACES-1907, working around little league practices.

Comment by Ed Burns [ 07/Feb/11 ]

After fixing JAVASERVERFACES-1907, I have a solid, automatable, reproducer for this issue.

container.name=glassfishV3.1_no_cluster

ant container.start
ant -Dinstance.numbers=1,2,3,4,5,6 create.virtual.servers
cd jsf-ri/systest-per-webapp
ant -Dcreate-virtual-servers=false -Dinstance.numbers=1,2,3,4,5,6 -Dapplication=replace-lifecycle install-virtual-server
ant -Dcreate-virtual-servers=false -Dinstance.numbers=1,2,3,4,5,6 -Dapplication=replace-lifecycle test-virtual-server
This shows the phaseListener getting called 6 times.

The workaround, which I will produce now, is to provide a custom LifecycleFactory instance that correctly handles the virtual server case.

Comment by Ed Burns [ 07/Feb/11 ]

I will write up the workaround and post it in the bug report.

Comment by Ed Burns [ 08/Feb/11 ]

Workaround description in plain text.

Comment by Ed Burns [ 17/Feb/11 ]

Snapshot, in progress.

Comment by Ed Burns [ 22/Feb/11 ]

snapshot. ClusterTest fails:

Running com.sun.faces.systest.ClusterNoAgressiveSessionDirtyingTestCase
Testsuite: com.sun.faces.systest.ClusterNoAgressiveSessionDirtyingTestCase
Tests run: 1, Failures: 1, Errors: 0, Time elapsed: 3.38 sec
Tests run: 1, Failures: 1, Errors: 0, Time elapsed: 3.38 sec

Testcase: testSimpleObject took 3.103 sec
FAILED
null
junit.framework.AssertionFailedError
at com.sun.faces.systest.ClusterNoAgressiveSessionDirtyingTestCase.assertSimpleObjectOutput(ClusterNoAgressiveSessionDirtyingTestCase.java:115)
at com.sun.faces.systest.ClusterNoAgressiveSessionDirtyingTestCase.testSimpleObject(ClusterNoAgressiveSessionDirtyingTestCase.java:84)
at com.sun.faces.htmlunit.AbstractTestCase.runTest(AbstractTestCase.java:628)

About to stop container.

Comment by Ed Burns [ 22/Feb/11 ]

Small but fundamental change to FactoryFinder http://java.net/jira/browse/GLASSFISH-15809

The root cause of our virtual server woes is an invalid assumption
FactoryFinder has made since its first commit. The assumption. There
is a 1:1 mapping between ServletContext and web-app ClassLoader. This
assumption is not valid in the case of virtual servers. In a deployment
with N virtual servers, there are N ServletContexts for each web-app
ClassLoader. According to Shing-wai, this is not a bug, and I agree
with him.

SECTION: Modified Files
----------------------------
M jsf-api/src/main/java/javax/faces/FactoryFinder.java

  • Instead of having the FactoryManagerCache use ClassLoader alone as the
    key for the FactoryManager instances, use a new class,
    FactoryManagerCacheKey that combines the ClassLoader with the
    ServletContext instance. I had to be careful to handle the case when
    FacesContext.getCurrentInstance() returns null.

M jsf-ri/src/main/java/com/sun/faces/config/ConfigureListener.java

  • When an app is undeployed, release its factories, which will cause
    them to be removed from the FactoryManagerCache.

M jsf-api/src/test/java/javax/faces/component/NamingContainerTestCase.javaM jsf-api/src/test/java/javax/faces/component/UIComponentTestCase.java
M jsf-api/src/test/java/javax/faces/validator/ValidatorTestCase.java
M jsf-api/src/test/java/javax/faces/webapp/TagTestCaseBase.java
M jsf-ri/test/com/sun/faces/config/TestFactoryInjection.java
M jsf-ri/build.xml

  • add deploy target

M jsf-ri/systest-per-webapp/replace-lifecycle/src/java/com/sun/faces/systest/SimplePhaseListener.java
M jsf-ri/systest-per-webapp/replace-lifecycle/src/java/com/sun/faces/systest/ReplaceLifecycleTestCase.java

  • test changes to verify 15809 is fixed.

M lib/jsf-extensions-test-time.jar

  • Fix a bug in MockFacesContext that doesn't actually release the threadlocal.

SECTION: Diffs
----------------------------
Index: jsf-api/src/test/java/javax/faces/component/NamingContainerTestCase.java
===================================================================
— jsf-api/src/test/java/javax/faces/component/NamingContainerTestCase.java (revision 8870)
+++ jsf-api/src/test/java/javax/faces/component/NamingContainerTestCase.java (working copy)
@@ -117,16 +117,16 @@
request.setAttribute("reqScopeName", "reqScopeValue");
response = new MockHttpServletResponse();

+ externalContext =
+ new MockExternalContext(servletContext, request, response);
+ lifecycle = new MockLifecycle();
+ facesContext = new MockFacesContext(externalContext, lifecycle);
// Set up Faces API Objects
FactoryFinder.setFactory(FactoryFinder.APPLICATION_FACTORY,
"com.sun.faces.mock.MockApplicationFactory");
FactoryFinder.setFactory(FactoryFinder.RENDER_KIT_FACTORY,
"com.sun.faces.mock.MockRenderKitFactory");

  • externalContext =
  • new MockExternalContext(servletContext, request, response);
  • lifecycle = new MockLifecycle();
  • facesContext = new MockFacesContext(externalContext, lifecycle);
    ApplicationFactory applicationFactory = (ApplicationFactory)
    FactoryFinder.getFactory(FactoryFinder.APPLICATION_FACTORY);
    application = (MockApplication) applicationFactory.getApplication();
    Index: jsf-api/src/test/java/javax/faces/component/UIComponentTestCase.java
    ===================================================================
      • jsf-api/src/test/java/javax/faces/component/UIComponentTestCase.java (revision 8870)
        +++ jsf-api/src/test/java/javax/faces/component/UIComponentTestCase.java (working copy)
        @@ -164,18 +164,18 @@
        request.setAttribute("reqScopeName", "reqScopeValue");
        response = new MockHttpServletResponse();

+ externalContext =
+ new MockExternalContext(servletContext, request, response);
+ Map map = new HashMap();
+ externalContext.setRequestParameterMap(map);
+ lifecycle = new MockLifecycle();
+ facesContext = new MockFacesContext(externalContext, lifecycle);
// Set up Faces API Objects
FactoryFinder.setFactory(FactoryFinder.APPLICATION_FACTORY,
"com.sun.faces.mock.MockApplicationFactory");
FactoryFinder.setFactory(FactoryFinder.RENDER_KIT_FACTORY,
"com.sun.faces.mock.MockRenderKitFactory");

  • externalContext =
  • new MockExternalContext(servletContext, request, response);
  • Map map = new HashMap();
  • externalContext.setRequestParameterMap(map);
  • lifecycle = new MockLifecycle();
  • facesContext = new MockFacesContext(externalContext, lifecycle);
    ApplicationFactory applicationFactory = (ApplicationFactory)
    FactoryFinder.getFactory(FactoryFinder.APPLICATION_FACTORY);
    application = (MockApplication) applicationFactory.getApplication();
    Index: jsf-api/src/test/java/javax/faces/validator/ValidatorTestCase.java
    ===================================================================
      • jsf-api/src/test/java/javax/faces/validator/ValidatorTestCase.java (revision 8870)
        +++ jsf-api/src/test/java/javax/faces/validator/ValidatorTestCase.java (working copy)
        @@ -124,16 +124,16 @@
        request.setAttribute("reqScopeName", "reqScopeValue");
        response = new MockHttpServletResponse();

+ externalContext =
+ new MockExternalContext(servletContext, request, response);
+ lifecycle = new MockLifecycle();
+ facesContext = new MockFacesContext(externalContext, lifecycle);
// Set up Faces API Objects
FactoryFinder.setFactory(FactoryFinder.APPLICATION_FACTORY,
"com.sun.faces.mock.MockApplicationFactory");
FactoryFinder.setFactory(FactoryFinder.RENDER_KIT_FACTORY,
"com.sun.faces.mock.MockRenderKitFactory");

  • externalContext =
  • new MockExternalContext(servletContext, request, response);
  • lifecycle = new MockLifecycle();
  • facesContext = new MockFacesContext(externalContext, lifecycle);
    ApplicationFactory applicationFactory = (ApplicationFactory)
    FactoryFinder.getFactory(FactoryFinder.APPLICATION_FACTORY);
    application = (MockApplication) applicationFactory.getApplication();
    Index: jsf-api/src/test/java/javax/faces/webapp/TagTestCaseBase.java
    ===================================================================
      • jsf-api/src/test/java/javax/faces/webapp/TagTestCaseBase.java (revision 8870)
        +++ jsf-api/src/test/java/javax/faces/webapp/TagTestCaseBase.java (working copy)
        @@ -142,16 +142,16 @@
        pageContext.initialize(servlet, request, response, null,
        true, 1024, true);

+ externalContext =
+ new MockExternalContext(servletContext, request, response);
+ externalContext.setRequestParameterMap(new HashMap());
+ lifecycle = new MockLifecycle();
+ facesContext = new MockFacesContext(externalContext, lifecycle);
// Set up Faces API Objects
FactoryFinder.setFactory(FactoryFinder.APPLICATION_FACTORY,
"com.sun.faces.mock.MockApplicationFactory");
FactoryFinder.setFactory(FactoryFinder.RENDER_KIT_FACTORY,
"com.sun.faces.mock.MockRenderKitFactory");

  • externalContext =
  • new MockExternalContext(servletContext, request, response);
  • externalContext.setRequestParameterMap(new HashMap());
  • lifecycle = new MockLifecycle();
  • facesContext = new MockFacesContext(externalContext, lifecycle);
    ApplicationFactory applicationFactory = (ApplicationFactory)
    FactoryFinder.getFactory(FactoryFinder.APPLICATION_FACTORY);
    application = (MockApplication) applicationFactory.getApplication();
    Index: jsf-api/src/main/java/javax/faces/FactoryFinder.java
    ===================================================================
      • jsf-api/src/main/java/javax/faces/FactoryFinder.java (revision 8870)
        +++ jsf-api/src/main/java/javax/faces/FactoryFinder.java (working copy)
        @@ -67,6 +67,8 @@
        import java.lang.reflect.Constructor;
        import java.net.URL;
        import java.net.URLConnection;
        +import java.util.Set;
        +import javax.faces.context.FacesContext;

/**
@@ -680,8 +682,8 @@
*/
private static final class FactoryManagerCache {

  • private ConcurrentMap<ClassLoader,Future<FactoryManager>> applicationMap =
  • new ConcurrentHashMap<ClassLoader, Future<FactoryManager>>();
    + private ConcurrentMap<FactoryManagerCacheKey,Future<FactoryManager>> applicationMap =
    + new ConcurrentHashMap<FactoryManagerCacheKey, Future<FactoryManager>>();

// ------------------------------------------------------ Public Methods
@@ -689,8 +691,10 @@

private FactoryManager getApplicationFactoryManager(ClassLoader cl) {

+ FactoryManagerCacheKey key = new FactoryManagerCacheKey(cl, applicationMap);
+
while (true) {

  • Future<FactoryManager> factories = applicationMap.get(cl);
    + Future<FactoryManager> factories = applicationMap.get(key);
    if (factories == null) {
    Callable<FactoryManager> callable =
    new Callable<FactoryManager>() {
    @@ -702,7 +706,7 @@

FutureTask<FactoryManager> ft =
new FutureTask<FactoryManager>(callable);

  • factories = applicationMap.putIfAbsent(cl, ft);
    + factories = applicationMap.putIfAbsent(key, ft);
    if (factories == null) { factories = ft; ft.run(); @@ -717,14 +721,14 @@ ce.toString(), ce); }
  • applicationMap.remove(cl);
    + applicationMap.remove(key);
    } catch (InterruptedException ie) {
    if (LOGGER.isLoggable(Level.FINEST)) { LOGGER.log(Level.FINEST, ie.toString(), ie); }
  • applicationMap.remove(cl);
    + applicationMap.remove(key);
    } catch (ExecutionException ee) { throw new FacesException(ee); }

    @@ -735,14 +739,89 @@

public void removeApplicationFactoryManager(ClassLoader cl)

{ + FactoryManagerCacheKey key = new FactoryManagerCacheKey(cl, applicationMap); - applicationMap.remove(cl); + applicationMap.remove(key); }

} // END FactoryCache

+ private static final class FactoryManagerCacheKey {
+ private ClassLoader cl;
+ private Object context;

+ private static final String KEY = FactoryFinder.class.getName() + "." ++ FactoryManagerCacheKey.class.getSimpleName();
+
+ public FactoryManagerCacheKey(ClassLoader cl,
+ Map<FactoryManagerCacheKey,Future<FactoryManager>> factoryMap) {
+ this.cl = cl;
+ FacesContext facesContext = FacesContext.getCurrentInstance();
+ if (null != facesContext) {
+ Map<String, Object> appMap = facesContext.getExternalContext().getApplicationMap();
+ Object val = appMap.get(KEY);
+ if (null == val)

{ + context = new Long(System.currentTimeMillis()); + appMap.put(KEY, context); + }

else

{ + context = val; + }

+ } else {
+ // We don't have a FacesContext.
+ // Our only recourse is to inspect the keys of the
+ // factoryMap and see if any of them has a classloader
+ // equal to our argument cl.
+ Set<FactoryManagerCacheKey> keys = factoryMap.keySet();
+ FactoryManagerCacheKey match = null;
+ for (FactoryManagerCacheKey cur : keys) {
+ if (this.cl.equals(cur.cl)) {
+ match = cur;
+ if (null != match)

{ + LOGGER.log(Level.WARNING, "Multiple JSF Applications found on same ClassLoader. Unable to safely determine which FactoryManager instance to use. Defaulting to first match."); + }

+ }
+ }
+ if (null != match)

{ + this.context = match.context; + }

+ }
+ }
+
+ private FactoryManagerCacheKey() {}
+
+ @Override
+ public boolean equals(Object obj) {
+ if (obj == null)

{ + return false; + }
+ if (getClass() != obj.getClass()) { + return false; + }

+ final FactoryManagerCacheKey other = (FactoryManagerCacheKey) obj;
+ if (this.cl != other.cl && (this.cl == null || !this.cl.equals(other.cl)))

{ + return false; + }
+ if (this.context != other.context && (this.context == null || !this.context.equals(other.context))) { + return false; + }

+ return true;
+ }
+
+ @Override
+ public int hashCode()

{ + int hash = 7; + hash = 97 * hash + (this.cl != null ? this.cl.hashCode() : 0); + hash = 97 * hash + (this.context != null ? this.context.hashCode() : 0); + return hash; + }

+
+
+
+
+ }
+
+
/**

  • Maintains the factories for a single web application.
    */
    Index: jsf-ri/test/com/sun/faces/config/TestFactoryInjection.java
    ===================================================================
      • jsf-ri/test/com/sun/faces/config/TestFactoryInjection.java (revision 8870)
        +++ jsf-ri/test/com/sun/faces/config/TestFactoryInjection.java (working copy)
        @@ -235,7 +235,9 @@

// invoke the FactoryConfigProcessor
FactoryConfigProcessor fcp = new FactoryConfigProcessor(false);
+ InitFacesContext initContext = new InitFacesContext(sc);
fcp.process(sc, new DocumentInfo[]

{new DocumentInfo(d, null)});
+ initContext.release();

// now get an FacesContext instance from the Factory and ensure
// no injection occured.
@@ -264,7 +266,9 @@
// process the document. This should cause the the InjectionFacesContextFactory
// to be put into play since there is more than one FacesContextFactory // being configured
+ initContext = new InitFacesContext(sc);
fcp.process(sc, new DocumentInfo[]{new DocumentInfo(d, null)}

);
+ initContext.release();

// get the FacesContextFactory instance. The top-level factory should
// be the InjectionFacesContextFactory.
Index: jsf-ri/src/main/java/com/sun/faces/config/ConfigureListener.java
===================================================================
— jsf-ri/src/main/java/com/sun/faces/config/ConfigureListener.java (revision 8870)
+++ jsf-ri/src/main/java/com/sun/faces/config/ConfigureListener.java (working copy)
@@ -348,6 +348,7 @@
ApplicationAssociate.setCurrentInstance(null);
// Release the initialization mark on this web application
ConfigManager.getInstance().destory(context);
+ FactoryFinder.releaseFactories();
if (initContext != null)

{ initContext.release(); }

Index: jsf-ri/build.xml
===================================================================
— jsf-ri/build.xml (revision 8870)
+++ jsf-ri/build.xml (working copy)
@@ -700,7 +700,7 @@

<target name="passthru">

  • <ant antfile="build-tests.xml" target="execute.cactus.tests"
    + <ant antfile="build-tests.xml" target="passthru"
    inheritAll="true">
    <property name="force.no.cluster" value="true" />
    </ant>
    @@ -715,6 +715,14 @@

</target>

+ <target name="deploy">
+ <ant antfile="build-tests.xml" target="deploy"
+ inheritAll="true">
+ <property name="force.no.cluster" value="true" />
+ </ant>
+
+ </target>
+
<target name="prepare.cactus.webapp">
<ant antfile="build-tests.xml" target="prepare.test.webapp"/>
</target>
Index: jsf-ri/systest-per-webapp/replace-lifecycle/src/java/com/sun/faces/systest/SimplePhaseListener.java
===================================================================
— jsf-ri/systest-per-webapp/replace-lifecycle/src/java/com/sun/faces/systest/SimplePhaseListener.java (revision 8870)
+++ jsf-ri/systest-per-webapp/replace-lifecycle/src/java/com/sun/faces/systest/SimplePhaseListener.java (working copy)
@@ -43,6 +43,7 @@
import javax.faces.event.PhaseEvent;
import javax.faces.event.PhaseId;
import javax.faces.event.PhaseListener;
+import java.util.Map;

public class SimplePhaseListener implements PhaseListener {

@@ -57,8 +58,12 @@

public void beforePhase(PhaseEvent event)

{ - event.getFacesContext().getExternalContext().getRequestMap().put("beforePhase", - "beforePhase"); + Map<String, Object> requestMap = + event.getFacesContext().getExternalContext().getRequestMap(); + String message = requestMap.containsKey("beforePhase") ? + requestMap.get("beforePhase").toString() : ""; + requestMap.put("beforePhase", + message + " beforePhase"); event.getFacesContext().getExternalContext().getRequestMap().put("lifecycleImpl", event.getSource()); }

Index: jsf-ri/systest-per-webapp/replace-lifecycle/src/java/com/sun/faces/systest/ReplaceLifecycleTestCase.java
===================================================================
— jsf-ri/systest-per-webapp/replace-lifecycle/src/java/com/sun/faces/systest/ReplaceLifecycleTestCase.java (revision 8870)
+++ jsf-ri/systest-per-webapp/replace-lifecycle/src/java/com/sun/faces/systest/ReplaceLifecycleTestCase.java (working copy)
@@ -128,7 +128,10 @@

public void testReplaceLifecycle() throws Exception

{ HtmlPage page = getPage("/faces/test.jsp"); - assertTrue(-1 != page.asText().indexOf("beforePhase")); + String pageText = page.asText(); + assertTrue(-1 != pageText.indexOf("beforePhase")); + // Ensure the phaseListener is only called once. + assertTrue(!pageText.matches("(?s).*beforePhase.*beforePhase.*")); }

Index: lib/jsf-extensions-test-time.jar
===================================================================
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream

Comment by Jason Lee [ 23/Feb/11 ]

The changes look good to me.

r=jdlee

Comment by Ed Burns [ 23/Feb/11 ]

Sending jsf-api/src/main/java/javax/faces/FactoryFinder.java
Sending jsf-api/src/test/java/javax/faces/component/NamingContainerTestCase.java
Sending jsf-api/src/test/java/javax/faces/component/UIComponentTestCase.java
Sending jsf-api/src/test/java/javax/faces/validator/ValidatorTestCase.java
Sending jsf-api/src/test/java/javax/faces/webapp/TagTestCaseBase.java
Sending jsf-ri/build.xml
Sending jsf-ri/src/main/java/com/sun/faces/config/ConfigureListener.java
Sending jsf-ri/systest-per-webapp/replace-lifecycle/src/java/com/sun/faces/systest/ReplaceLifecycleTestCase.java
Sending jsf-ri/systest-per-webapp/replace-lifecycle/src/java/com/sun/faces/systest/SimplePhaseListener.java
Sending jsf-ri/test/com/sun/faces/config/TestFactoryInjection.java
Sending lib/jsf-extensions-test-time.jar
Transmitting file data ...........
Committed revision 8871.

Comment by Ed Burns [ 23/Feb/11 ]

add jsf_2_1_1 to status whiteboard

Comment by tedgoddard [ 22/Mar/11 ]

The following WARNING is seen when visiting the first page in an application running on Tomcat:

Mar 22, 2011 4:35:49 PM javax.faces.FactoryFinder$FactoryManagerCacheKey <init>
WARNING: Multiple JSF Applications found on same ClassLoader.  Unable to safely determine which FactoryManager instance to use. Defaulting to first match.

It has no functional impact.

Comment by Scott Fordin [ 24/Mar/11 ]

Does this still need to be added to the Release Notes? If so, I need more information.

Comment by Ed Burns [ 08/Apr/11 ]

Integrated into GlassFish 3.1.1

Comment by Scott Fordin [ 12/May/11 ]

Still need a more concise workaround.

Comment by Scott Fordin [ 17/May/11 ]

Added issue to 3.1 Known Issues section of 3.1-3.1.1 Release Notes. In the absence of a more concise workaround, I linked to the i_gf_15809-workaround.txt file that is attached to this issue.

Comment by bjornstenfeldt [ 26/Sep/11 ]

I'm finding it rather frustrating that I'm now getting around 1000 lines of "Multiple JSF Applications found on same ClassLoader. Unable to safely determine which FactoryManager instance to use. Defaulting to first match." in my log, every single second. Maybe a context-param in web.xml to disable this warning?

Comment by Ed Burns [ 26/Sep/11 ]

Hello Björn,

I am sincerely sorry for your frustration.

Is it acceptable to request that you modify your logging configuration, as described in <http://wikis.sun.com/display/GlassFish/JavaServerFacesRI#JavaServerFacesRI-HowcanIturnonlogging%3F> to prevent that logging message from being displayed?

Specifically, modify your logging.properties like this:

— logging.properties 2011-07-19 21:42:46.000000000 -0400
+++ logging_GLASSFISH-15809.properties 2011-09-26 11:40:23.000000000 -0400
@@ -113,3 +113,4 @@
javax.enterprise.system.ssl.security.level=INFO
ShoalLogger.level=CONFIG
org.eclipse.persistence.session.level=INFO
+javax.faces.level=INFO

Does that help?

Comment by bjornstenfeldt [ 27/Sep/11 ]

It will definitely fix it (javax.faces.level=SEVERE), but I worry that it might disables a lot of other information or warnings too, which is why I've been hesitating to use this method.

Comment by Ed Burns [ 27/Sep/11 ]

I can assure you that even though a logger such as javax.faces seems very "low level", there are very few log messages controlled by that logger. The vast majority of JSF related log messages are in the javax.enterprise.resource.webcontainer.jsf and sub loggers.

Comment by bjornstenfeldt [ 28/Sep/11 ]

Alright, I'll give it a chance.





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

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

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

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

jsf_2_1_1

Tags: 3_1-exclude, 3_1-release-note-added, 3_1-release-notes

 Description   

Deployment of the web application works fine:

INFO: Installed /srv/server/glassfish/3.1-b42/glassfish/domains/domain1/autodeploy/bundles/dummy-web.war
INFO: Started bundle: file:/srv/server/glassfish/3.1-b42/glassfish/domains/domain1/autodeploy/bundles/dummy-web.war
INFO: Started bundle: file:/srv/server/glassfish/3.1-b42/glassfish/domains/domain1/autodeploy/bundles/dummy-web.war
INFO: Expanded at file:/tmp/osgiapp6345962157332461681/
INFO: SEC1002: Security Manager is OFF.
INFO: SEC1010: Entering Security Startup Service
INFO: SEC1143: Loading policy provider com.sun.enterprise.security.provider.PolicyWrapper.
INFO: SEC1115: Realm [admin-realm] of classtype [com.sun.enterprise.security.auth.realm.file.FileRealm] successfully created.
INFO: SEC1115: Realm [file] of classtype [com.sun.enterprise.security.auth.realm.file.FileRealm] successfully created.
INFO: SEC1115: Realm [certificate] of classtype [com.sun.enterprise.security.auth.realm.certificate.CertificateRealm] successfully created.
INFO: SEC1011: Security Service(s) Started Successfully
INFO: WEB0169: Created HTTP listener [http-listener-1] on host/port [0.0.0.0:8080]
INFO: WEB0169: Created HTTP listener [http-listener-2] on host/port [0.0.0.0:8181]
INFO: WEB0169: Created HTTP listener [admin-listener] on host/port [0.0.0.0:4848]
INFO: WEB0171: Created virtual server [server]
INFO: WEB0171: Created virtual server [__asadmin]
INFO: WEB0172: Virtual server [server] loaded default web module []
INFO: Portable JNDI names for EJB DummySingleton : [java:global/org.glassfish.osgi.dummy-web_1.0.0.SNAPSHOT/DummySingleton, java:global/org.glassfish.osgi.dummy-web_1.0.0.SNAPSHOT/DummySingleton!org.glassfish.osgi.web.dummy.DummySingletonLocal]
INFO: WELD-000900 $

{parsedVersion (osgiVersion}

)
INFO: Instantiated an instance of org.hibernate.validator.engine.resolver.JPATraversableResolver.
INFO: total number of classes with faces annotation = 0
INFO: Total number of available updates : 0
INFO: Initializing Mojarra 2.1.0 (FCS 2.1.0-b11) for context '/dummy-web'
INFO: Faces Config uris excluding the ones named as faces-config.xml = []
INFO: Facelet Config uris = [embeddedjar:bundle://252.0:0/WEB-INF/lib/prettyfaces-jsf2-3.2.0.jar!/META-INF/ocpsoft-pretty-faces.taglib.xml]
INFO: PrettyFilter starting up...
INFO: PrettyFilter initialized.
INFO: WEB0671: Loading application [org.glassfish.osgi.dummy-web_1.0.0.SNAPSHOT] at [/dummy-web]
INFO: Registered ServletContext as a service with properties:

{osgi.web.symbolicname=org.glassfish.osgi.dummy-web, osgi.web.version=1.0.0.SNAPSHOT, osgi.web.contextpath=/dummy-web}


INFO: deployed bundle org.glassfish.osgi.dummy-web [252] at file:/tmp/osgiapp6345962157332461681/

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

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

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

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

In b38, the behavior was even more strange:

^^ ???

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

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



 Comments   
Comment by Shing Wai Chan [ 15/Feb/11 ]

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

Assign to jsf team to investigate (1).

Comment by rogerk [ 15/Feb/11 ]

Assigning to Ed as prior commit may be the cause.

Comment by Ed Burns [ 15/Feb/11 ]

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

Comment by Ed Burns [ 15/Feb/11 ]

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

Comment by Ed Burns [ 15/Feb/11 ]

I can reproduce the problem.

Here is the log output.

Comment by Ed Burns [ 15/Feb/11 ]

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

Comment by chaoslayer [ 15/Feb/11 ]

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

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

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

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

Comment by Sanjeeb Sahoo [ 16/Feb/11 ]

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

Comment by chaoslayer [ 16/Feb/11 ]

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

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

Log files:

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

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

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

</faces-config>

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

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

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

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

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

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

...which seems totally correct.

Comment by chaoslayer [ 21/Feb/11 ]

Any progress on this one?

Comment by Ed Burns [ 02/Mar/11 ]

Ok, I see the same problem, even today.

Investigating further.

Comment by Ed Burns [ 03/Mar/11 ]

Committed to trunk.

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

Comment by Ed Burns [ 04/Mar/11 ]

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

Comment by Sanjeeb Sahoo [ 04/Mar/11 ]

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

Comment by Scott Fordin [ 23/Mar/11 ]

Need more info to add issue to 3.1 Release Notes.

Comment by Ed Burns [ 08/Apr/11 ]

Integrated into GlassFish 3.1.1

Comment by Scott Fordin [ 13/Apr/11 ]

Release Note still needed?

Comment by Ed Burns [ 14/Apr/11 ]

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

Comment by Scott Fordin [ 14/Apr/11 ]

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

Comment by Scott Fordin [ 12/May/11 ]

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





[GLASSFISH-16704] FileNotFoundException passing password to asadmin through std in Created: 23/May/11  Updated: 04/Nov/11  Resolved: 04/Nov/11

Status: Resolved
Project: glassfish
Component/s: command_line_interface
Affects Version/s: 3.1.1, 4.0_b03
Fix Version/s: 3.1.1_b01

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

Tags: 3_1_1-upgrade

 Description   

In 3.1, the upgrade tool could pass the master password into asadmin by using the -passwordfile option with the value "". This told asadmin to accept the password on standard in so we could avoid writing the password out in plain text to a file. In the 3.1.1 branch, this is now causing a file not found exception. Easy to reproduce on command line:

In 3.1:
hostname% ./target/glassfish3/glassfish/bin/asadmin --passwordfile - start-domain
[asadmin waits on std in]

In 3.1.1:
./branch/glassfish3/glassfish/bin/asadmin --passwordfile - start-domain
java.io.FileNotFoundException: /Users/bobby/eraseme/- (No such file or directory)
Command start-domain failed.

This will block using the upgrade tool for any source domain that has a non-default master password.



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

This problem shows up on the trunk as well.

Comment by Tom Mueller [ 23/May/11 ]

The root cause of this problem is due to a change in revision 45444 made for issue GLASSFISH-16150. That change introduced a call to SmartFile.sanitize in the ProgramOptions.getPasswordFile method. This results in the return value being an absolute pathname rather than the "" that CLIUtil.readPasswordFileOptions checks for later. The fix for issue GLASSFISH-16150 will need to be changed so that passing in "" for the passwordfile option still works.

Revision 45444 was made on March 8, so this is why the problem shows up in 3.1.1 and on the trunk. It needs to be fixed in both places.

Comment by Byron Nevins [ 23/May/11 ]

Trivial.

D:\3.1.1\admin\cli>svn commit
Sending cli\src\main\java\com\sun\enterprise\admin\cli\ProgramOptions.java
Transmitting file data .
Committed revision 47042.

D:\gf\v3\admin\cli>svn commit
Sending cli\src\main\java\com\sun\enterprise\admin\cli\ProgramOptions.java
Transmitting file data .
Committed revision 47043.

Comment by Bobby Bissett [ 24/May/11 ]

And verified.





[GLASSFISH-13774] Win. Deployment with contextroot: Application [] contains no valid components Created: 03/Oct/10  Updated: 26/Jul/11  Resolved: 11/Mar/11

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

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

Operating System: All
Platform: All


Attachments: File bookstore.war     Text File derby.bookstore.sql     Text File server.log    
Issue Links:
Duplicate
is duplicated by GLASSFISH-13773 Win. Deployment with contextroot: The... Resolved
Related
is related to GLASSFISH-17094 deployment of war files packaged in e... Resolved
Issuezilla Id: 13,774
Tags: 3_1-exclude, 3_1-release-note-added, 3_1-release-notes

 Description   

Promoted b22, Win7 machine. On this machine was created a cluster with two
instances. The deployment with contextroot to the cluster, i.e.:
asadmin deploy --target <cluster> --contextroot temp --name qwerty1, failed for
several apps with such messages (see bellow). The same command did not create
any issues on Mac, Linux, Solaris. I've attached an app.

=====================================================================
DEPLOY WITH CONTEXT bookstore
[#|2010-10-03T16:33:07.208-
0700|SEVERE|glassfish3.1|javax.enterprise.system.core.com.sun.enterprise.v3.serv
er|_ThreadID=15;_ThreadName=Thread-1;|Exception while deploying the app
[qwerty1]|#]

[#|2010-10-03T16:33:07.212-
0700|SEVERE|glassfish3.1|javax.enterprise.system.tools.admin.org.glassfish.deplo
yment.admin|_ThreadID=15;_ThreadName=Thread-1;|Exception while deploying the app
[qwerty1] : Application [] contains no valid components|#]

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



 Comments   
Comment by Hong Zhang [ 03/Oct/10 ]

I don't see the attached app, is it the same one as in issue 13773?

Tim: can you take a look at this as it only happens on windows? Thanks!

Comment by easarina [ 03/Oct/10 ]

For this app were created such resources:

$S1AS_HOME/bin/asadmin create-jdbc-connection-pool --target $CLUSTER --property
User=BOOKSTORE:Password=BOOKSTORE:dataBaseN
ame=DerbyDB:serverName=localhost:portNumber=1527 --restype javax.sql.DataSource
--datasourceclassname org.apache.derby.jdbc
.ClientDataSource bookstorePool
$S1AS_HOME/bin/asadmin create-jdbc-resource --target $CLUSTER --connectionpoolid
bookstore-pool jdbc/BookDB

Comment by easarina [ 03/Oct/10 ]

Created an attachment (id=5054)
bookstore.war

Comment by easarina [ 03/Oct/10 ]

Created an attachment (id=5055)
derby.bookstore.sql

Comment by Tim Quinn [ 04/Oct/10 ]

Hi, Elena.

Do you happen to know if this happens on Windows XP also? That's the type of
Windows system I have access to.

I will try it myself soon; I just wondered if you already knew. Thanks.

Comment by Tim Quinn [ 04/Oct/10 ]

Setting expected target milestone to MS 7.

Comment by easarina [ 04/Oct/10 ]

I've reproduced this issue on XP machine.

Comment by easarina [ 26/Oct/10 ]

Re-run the test on Win7 against b25 10/25. Did not see this issue.

Comment by easarina [ 28/Oct/10 ]

Did not see this issue for b26

Comment by easarina [ 18/Nov/10 ]

Run the same test on Win 2008 machine. (I have two Win 2008 machines). I've run
the test at least 10 times, using b30. For both machines just one time this
exception was not seen. In all other cases. This exection wax seen for:

1) SingletonCMT

org.glassfish.api.admin.CommandException: remote failure: Error occurred during
deployment: Exception while deploying the app [qwerty1] : Application []
contains no valid components. Please see server.log for more details.
Command deploy failed.
org.glassfish.api.admin.CommandException: remote failure: Application with name
[qwerty1] is not deployed
Command redeploy failed.
org.glassfish.api.admin.CommandException: remote failure: Application qwerty1
is not deployed on this target [my-c1]
Command undeploy failed.

2) bookstore

org.glassfish.api.admin.CommandException: remote failure: Error occurred during
deployment: Exception while deploying the app [qwerty1] : Application []
contains no valid components. Please see server.log for more details.
Command deploy failed.
org.glassfish.api.admin.CommandException: remote failure: Application with name
[qwerty1] is not deployed
Command redeploy failed.
org.glassfish.api.admin.CommandException: remote failure: Application qwerty1
is not deployed on this target [my-c1]
Command undeploy failed.

3) SLSBNICMT
org.glassfish.api.admin.CommandException: remote failure: Error occurred during
deployment: Exception while deploying the app [qwerty1] : Application []
contains no valid components. Please see server.log for more details.
Command deploy failed.
org.glassfish.api.admin.CommandException: remote failure: Application with name
[qwerty1] is not deployed
Command redeploy failed.
org.glassfish.api.admin.CommandException: remote failure: Application qwerty1
is not deployed on this target [my-c1]
Command undeploy failed.

See, for example, hudson job:

http://sqe-hudson.us.oracle.com:8080/hudson/view/Elena_Jobs/job/deployment/49/

Comment by easarina [ 01/Dec/10 ]

I've run a deployment test against nightly build 31 11/30 on Win 2008 machine. See the results of the run under:

http://sqe-hudson.us.oracle.com:8080/hudson/view/Elena_Jobs/job/deployment/56/artifact/appserver-sqe/reports/pe-pe/amd64_JED-ASQE-21_Windows_NT/html/summaryreport.html

The deployment of several apps:
SLSBNICMT
SingletonCMT
bookstore

failed with this message.

Comment by Tim Quinn [ 03/Dec/10 ]

This is some of the server.log output Elena sent to us (thanks, Elena).

[#|2010-11-30T19:34:47.639-0800|SEVERE|glassfish3.1|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=17;_ThreadName=Thread-1;|Exception while deploying the app [qwerty1]|#]

[#|2010-11-30T19:34:47.639-0800|SEVERE|glassfish3.1|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=17;_ThreadName=Thread-1;|Application [] contains no valid components
java.lang.IllegalArgumentException: Application [] contains no valid components
at com.sun.enterprise.deployment.util.ApplicationValidator.accept(ApplicationValidator.java:77)
at com.sun.enterprise.deployment.Application.visit(Application.java:1764)
at com.sun.enterprise.deployment.archivist.ApplicationArchivist.validate(ApplicationArchivist.java:794)
at com.sun.enterprise.deployment.archivist.ApplicationArchivist.openWith(ApplicationArchivist.java:273)
at com.sun.enterprise.deployment.archivist.ApplicationArchivist.open(ApplicationArchivist.java:228)
at com.sun.enterprise.deployment.archivist.ApplicationArchivist.open(ApplicationArchivist.java:80)
at com.sun.enterprise.deployment.archivist.ApplicationFactory.openArchive(ApplicationFactory.java:165)
at org.glassfish.javaee.core.deployment.DolProvider.load(DolProvider.java:179)
at org.glassfish.javaee.core.deployment.DolProvider.load(DolProvider.java:92)
at com.sun.enterprise.v3.server.ApplicationLifecycle.loadDeployer(ApplicationLifecycle.java:825)
at com.sun.enterprise.v3.server.ApplicationLifecycle.setupContainerInfos(ApplicationLifecycle.java:767)
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:369)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:354)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:369)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1061)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1200(CommandRunnerImpl.java:95)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1257)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1246)
at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:449)
at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:216)
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:234)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:817)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:718)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1007)
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)

#]

[#|2010-11-30T19:34:47.643-0800|SEVERE|glassfish3.1|javax.enterprise.system.tools.admin.org.glassfish.deployment.admin|_ThreadID=17;_ThreadName=Thread-1;|Exception while deploying the app [qwerty1] : Application [] contains no valid components|#]

Comment by Tim Quinn [ 03/Dec/10 ]

Using an up-to-date workspace I have been working with a Windows 7 system. I have not yet been able to reproduce the problem. It might be because I am using a fast system that does not show the race condition Elena has encountered. Still looking.

Comment by Tim Quinn [ 03/Dec/10 ]

I think part of the reason I might not see the same error is that the provisioned system I am using to test is virtual with a single virtual CPU.

Considering this is a race condition it might appear only in a multi-CPU/multi-core environment.

Elena, is your testing on a multi-CPU/multi-core system?

Comment by easarina [ 03/Dec/10 ]

The last time I saw this issue on such Win 2008 machine
Processor: AMD Opteron (tm) Processor 154 2.80 GHz
RAM 2.00 GB
System Type: 64-bit OS.

I saw this issue during hudson runs, I'm not sure that it is easy to reproduce this issue manually.

Comment by Hong Zhang [ 06/Dec/10 ]

I could not reproduce the problem with bookstore.war on the windows machine where we reproduced issue 13775.

As you said, this problem might only happen during hudson runs. It will be very hard to look into the problem if we can only reproduce the problem with running the whole test suite. It will be great if you can narrow it down to a small set of the steps for us to look into it.

One question, during the hudson run where this is reproducible, after the whole test suite finished (I assume all applications will be undeployed at that point), what's left behind in the domains/domain1/applications directory?

Also you mentioned two other applications also having this problem:
SLSBNICMT and SingletonCMT. Can you attach the archives for them? Want to see if we have any luck reproduce the problem with these other two applications.

Comment by easarina [ 07/Dec/10 ]

I've tried to narrow the issue. I've run the tests many times with a small subsets of the archives on Win 2008 against latest b31 and b32. I was able to reproduce the issue one time, please see:

http://sqe-hudson.us.oracle.com:8080/hudson/view/Elena_Jobs/job/deployment/66/

In this run also was presented an issue http://java.net/jira/browse/GLASSFISH-13773, it happened with table-generatorApp.

All archives, that were used in this run, can be checked out from appserver-sqe/pe/deployment_v3/archives

Comment by easarina [ 07/Dec/10 ]

I've reproduced the issue one more time with the same small set of apps on another Win 2008 machine, please see:
http://sqe-hudson.us.oracle.com:8080/hudson/view/Elena_Jobs/job/deployment/77/

Again along with bug http://java.net/jira/browse/GLASSFISH-13773.

Comment by easarina [ 08/Dec/10 ]

DAS server.log file from http://sqe-hudson.us.oracle.com:8080/hudson/view/Elena_Jobs/job/deployment/78/ execution.

Comment by Tim Quinn [ 13/Dec/10 ]

Here is the underlying problem.

1. A deployment of (for example) RosterApp.ear using "--name qwerty1" leaves a locked JAR file here:

applications/qwerty1/RosterApp_war/WEB-INF/lib/RosterAppEjb.jar

2. A later deployment of another app (for example bookstore.war) also using "--name qwerty1" fails because the ArchivistFactory.getPrivateArchivistsFor(ReadableArchive) method (line 131) checks composite archivists first. Although there is no std or runtime DD for an EAR present in the expanded directory, the ApplicationArchivist.postHandles method sees the left-over RosterApp_war directory (which could not be deleted because of the locked JAR contained within) and concludes that the app is an EAR and so returns true.

Later on, the validation fails because this is not in fact an EAR.

Comment by Tim Quinn [ 13/Dec/10 ]

I have some changes in my workspace which resolve the immediate problem I've described earlier. The presence of unused "leftover" JARs in the applications/appName directory no longer confuses GlassFish about what kind of archive it really is.

Now that the code goes beyond that point different problems have emerged. For example, after deploying the embeddable-embeddedApp.ear, disabling it, and enabling it, an attempt to deploy it with --force=true fails with errors resolving persistence units. This is the result of some of the JARs in the applications/appName directory being locked.

I have in my workspace some further changes that seem to relieve that problem. But it is too late to run the necessary tests to make sure these changes would not break anything.

My feeling had been that the original problem might be one we could live with. It happens only on Windows and only if the user deploys different types of applications in succession using the same application name.

But this new problem I have discovered causes problems in a much more common case: redeployment of an EAR with persistence units (on Windows). We should consider this for milestone 8.

Comment by Tim Quinn [ 15/Dec/10 ]

I am marking this to be fixed in 3.2; I do not think it rises to meet the criteria for fixing in 3.1.

  • Impacts product security (no)
  • Represents a CTS failure (no)
  • Is a regression of functionality or performance available in a prior release (no)
  • Introduces an incompatibility (no)
  • Likely to generate a customer support call (possible but relatively unlikely)
  • Significantly impacts the operation of a primary release driver feature (no)
  • An in-your-face issue that will touch the majority of users (no)

All of the following must occur to trigger this problem:

  • OS is Windows.
  • One (or more) JAR files in the expanded applications/appName directory are locked as part of deployment or accessing the application, so that the JAR(s) are not removed during undeployment.
  • The same or another application is later deployed with the same name.
  • The new application does not contain the previously-locked JAR file in the same location.
  • Some code in GlassFish searches all JARs in the application for some reason (e.g., annotation detection, persistence unit searching, sniffer work to identify the type of application).

Elena's very good test case revealed this problem by reusing the same application name when deploying different apps of different types. Because JARs from the earlier app were locked and remained behind, this confused various parts of GlassFish in different ways.

I have a working fix in my workspace. I plan to check the changes in for 3.2 rather than 3.1 Several classes that are affected are ones that are used in many places in GlassFish (FileArchive, for one) and because the bug is relatively rare the risk outweighs the benefit for a 3.1 fix.

Comment by Tim Quinn [ 26/Jan/11 ]

Issue 15691 is a duplicate of this one, at least in some respects.

The general deployment changes will work around such problems, but I have reassigned 15691 to the web container team for them to look at for 3.2 to eliminate the underlying cause.

Comment by Tim Quinn [ 03/Feb/11 ]

Fix checked in (trunk).

Project: glassfish
Repository: svn
Revision: 44886
Author: tjquinn
Date: 2011-02-04 00:10:13 UTC
Link:

Log Message:
------------
Fix for 13774

On Windows, deploy an EAR then undeploy it. (for example, stateless-session.ear from the devtests) Next, deploy a web app but use the same name as the just-undeployed EAR. (for example, webapps-caching.war from SQE) The undeploy of the EAR did not clean out the applications/appName directory because of a locked JAR. The deployment of the web app fails because GlassFish finds the "left-over" file and tries to treat it as part of the web app - which does not work.

These fixes change the FileArchive implementation so that it recognizes entries only if the entries are dated after a hidden timestamp maintained in the FileArchive's directory. This hides "left-over" files from a previous deployment that were not cleaned up.

Tests: error scenario in the issue on Windows, QL tests

Revisions:
----------
44886

Modified Paths:
---------------
trunk/v3/deployment/common/src/main/java/com/sun/enterprise/deploy/shared/FileArchive.java
trunk/v3/deployment/javaee-full/src/main/java/org/glassfish/javaee/full/deployment/EarHandler.java
trunk/v3/deployment/common/src/main/java/org/glassfish/deployment/common/DeploymentUtils.java
trunk/v3/core/kernel/src/main/java/com/sun/enterprise/v3/server/ApplicationLifecycle.java
trunk/v3/deployment/common/src/main/java/com/sun/enterprise/deployment/deploy/shared/InputJarArchive.java
trunk/v3/deployment/common/src/test/java/com/sun/enterprise/deployment/deploy/shared/InputJarArchiveTest.java
trunk/v3/deployment/dol/src/main/java/com/sun/enterprise/deployment/archivist/ApplicationArchivist.java

Comment by Tim Quinn [ 25/Feb/11 ]

One of the new unit tests failed for Jane on a Windows build.

testCreateWithOlderLeftoverEntryAndThenOpen(com.sun.enterprise.deploy.shared.FileArchiveTest)

Further, Amy reported problems with the web devtests on a Hudson system:
webtier-dev-tests-v3

So I am reopening this issue.

Comment by Tim Quinn [ 11/Mar/11 ]

Fix checked in.

Repository: svn
Revision: 45495
Author: tjquinn
Date: 2011-03-11 20:14:42 UTC
Link:

Log Message:
------------
Fix for 13774.

These changes implement a "stale" file handling mechanism for the FileArchive class which prevents stale files that were left over from a previous use of the same directory from being visible to a client of the FileArchive. This scenario would happen with some frequency on Windows when an app was deployed with a name, a JAR file remained open and so the expanded directory in applications/ could not be deleted, and a different app entirely was deployed using the same name. The applications/(appname) directory would be reused - since it remained from the previous app - and the stale file(s) within would confuse GlassFish. Now, such stale files are detected and are suppressed so they are not treated as part of the FileArchive.

A hidden file at the top level of the FileArchive directory records such stale files so even after a server restart the stale files are not visible.

pom change approved by Sahoo and Jane
Test: deployment devtests on Mac OS X and Windows; error scenario on both OS types; added unit tests

Revisions:
----------
45495

Modified Paths:
---------------
trunk/v3/deployment/common/src/main/java/com/sun/enterprise/deploy/shared/FileArchive.java
trunk/v3/deployment/common/src/main/resources/com/sun/logging/enterprise/system/tools/deployment/LogStrings.properties
trunk/v3/deployment/javaee-full/src/main/java/org/glassfish/javaee/full/deployment/EarHandler.java
trunk/v3/deployment/common/pom.xml
trunk/v3/deployment/common/src/test/java/com/sun/enterprise/deploy/shared/FileArchiveTest.java
trunk/v3/deployment/admin/src/main/java/org/glassfish/deployment/admin/DeployCommand.java
trunk/v3/deployment/admin/src/main/java/org/glassfish/deployment/admin/LocalStrings.properties
trunk/v3/deployment/admin/src/main/java/org/glassfish/deployment/admin/UndeployCommand.java
trunk/v3/deployment/common/src/main/java/org/glassfish/deployment/common/DeploymentUtils.java
trunk/v3/deployment/dol/src/main/java/com/sun/enterprise/deployment/archivist/ApplicationArchivist.java
trunk/v3/deployment/common/src/main/java/com/sun/enterprise/deployment/deploy/shared/InputJarArchive.java

Comment by Tim Quinn [ 14/Mar/11 ]

Release note info:

Summary:
On Windows under certain very specific conditions deploying the same or different applications using the same app name can result in unexpected errors.

To see this problem all of the following conditions must be true (from the Dec. 15 comment):

  • User deploys an application with name appName.
  • One (or more) JAR files in the expanded applications/appName directory are locked as part of deployment or accessing the application, so that the JAR(s) are not removed during undeployment.
  • The same or another application is later deployed with the same name.
  • The new application does not contain the previously-locked JAR file in the same location.
  • Some code in GlassFish searches all JARs in the application for some reason (e.g., annotation detection, persistence unit searching, sniffer work to identify the type of application).

GlassFish will consider the left-over file to be part of the second application, even though it it is not. This can cause various errors, most notably "Application [] contains no valid components."

Workarounds: (again, relevant only on Windows)
1. Avoid deploying different applications using the same app name.
2. If you need to redeploy an application but have removed a file from the app and that file remains in the applications/appName directory tree even though you redeploy the app, consider deploying the revised app using a different app name.
3. If you see this error, restart the domain admin server (use the asadmin stop-domain command or stop the domain using the admin console) and then deploy or redeploy the app.

Comment by Scott Fordin [ 15/Apr/11 ]

Added issue to 3.1 Release Notes.





[GLASSFISH-16087] console login fails with ConnectException if admin-listener is bound to a specific address Created: 23/Feb/11  Updated: 16/Jul/11  Resolved: 23/Feb/11

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

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


 Description   

If the admin-listener network listener address is changed to point to a specific IP address, then one can no longer use the admin console (it freezes on the console loading page), and the exception shown below is output to the log. Here is an example admin-listener network listener element in the domain.xml file:

<network-listener port="4848" protocol="admin-listener" address="adc2180966.us.oracle.com" transport="tcp" name="admin-listener" thread-pool="admin-thread-pool"></network-listener>

To recreate the problem:

1. edit the domain.xml to have a specific address
2. start the domain
3. access port 4848 (the console)

At this point, the browser will just stay on the console loading page, and the exception can be found in the log.

Adding an additional listener that listens on localhost:4848 changes the behavior. Instead of freezing, you get the login page, but you cannot login, and there are no exceptions. So it seems that something is trying to connect to localhost.

[#|2011-02-23T12:45:50.889-0800|WARNING|glassfish3.2|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=91;_ThreadName=Thread-1;|ApplicationDispatcher[] PWC1231: Servlet.service() for servlet FacesServlet threw exception
java.lang.RuntimeException: java.lang.reflect.InvocationTargetException while attempting to process a 'beforeCreate' event for 'event1'.
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:422)
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:394)
at com.sun.jsftemplating.layout.descriptors.LayoutComponent.beforeCreate(LayoutComponent.java:348)
at com.sun.jsftemplating.layout.descriptors.LayoutComponent.getChild(LayoutComponent.java:288)
at com.sun.jsftemplating.layout.LayoutViewHandler.buildUIComponentTree(LayoutViewHandler.java:556)
at com.sun.jsftemplating.layout.LayoutViewHandler.createView(LayoutViewHandler.java:255)
at com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:244)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:113)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:409)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1534)
at org.apache.catalina.core.ApplicationDispatcher.doInvoke(ApplicationDispatcher.java:787)
at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:649)
at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:483)
at org.apache.catalina.core.ApplicationDispatcher.doDispatch(ApplicationDispatcher.java:454)
at org.apache.catalina.core.ApplicationDispatcher.dispatch(ApplicationDispatcher.java:350)
at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:300)
at org.glassfish.admingui.common.security.AdminConsoleAuthModule.validateRequest(AdminConsoleAuthModule.java:204)
at com.sun.enterprise.security.jmac.config.GFServerConfigProvider$GFServerAuthContext.validateRequest(GFServerConfigProvider.java:1171)
at com.sun.web.security.RealmAdapter.validate(RealmAdapter.java:1328)
at com.sun.web.security.RealmAdapter.invokeAuthenticateDelegate(RealmAdapter.java:1206)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:551)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:623)
at org.apache.catalina.core.StandardPipeline.doChainInvoke(StandardPipeline.java:600)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:96)
at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:91)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:162)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:326)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:227)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:228)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:822)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:719)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1013)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:662)
Caused by: 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.jsftemplating.layout.descriptors.handler.Handler.invoke(Handler.java:442)
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:420)
... 44 more
Caused by: com.sun.jersey.api.client.ClientHandlerException: java.net.ConnectException: Connection refused
at com.sun.jersey.client.urlconnection.URLConnectionClientHandler.handle(URLConnectionClientHandler.java:131)
at com.sun.jersey.api.client.Client.handle(Client.java:629)
at com.sun.jersey.api.client.WebResource.handle(WebResource.java:601)
at com.sun.jersey.api.client.WebResource.access$200(WebResource.java:74)
at com.sun.jersey.api.client.WebResource$Builder.get(WebResource.java:459)
at org.glassfish.admingui.common.util.RestUtil.get(RestUtil.java:659)
at org.glassfish.admingui.common.util.RestUtil.restRequest(RestUtil.java:184)
at org.glassfish.admingui.common.handlers.RestApiHandlers.restRequest(RestApiHandlers.java:210)
... 50 more
Caused by: java.net.ConnectException: Connection refused
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333)
at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)
at java.net.Socket.connect(Socket.java:529)
at java.net.Socket.connect(Socket.java:478)
at sun.net.NetworkClient.doConnect(NetworkClient.java:163)
at sun.net.www.http.HttpClient.openServer(HttpClient.java:394)
at sun.net.www.http.HttpClient.openServer(HttpClient.java:529)
at sun.net.www.http.HttpClient.<init>(HttpClient.java:233)
at sun.net.www.http.HttpClient.New(HttpClient.java:306)
at sun.net.www.http.HttpClient.New(HttpClient.java:323)
at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:975)
at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:916)
at sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:841)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1177)
at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:379)
at com.sun.jersey.client.urlconnection.URLConnectionClientHandler._invoke(URLConnectionClientHandler.java:217)
at com.sun.jersey.client.urlconnection.URLConnectionClientHandler.handle(URLConnectionClientHandler.java:129)
... 57 more

#]


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

When i add the address attribute, I can't get to the loading page or the login page. The browser can't establish a connection.
I can't get to REST either.
Can you access REST after adding the address attribute ?

Comment by Tom Mueller [ 23/Feb/11 ]

Yes, the REST interface works fine. What address did you use? You should use the address that you normally use to login to the system.

Comment by Jason Lee [ 23/Feb/11 ]

I can confirm that REST works, but I never get the console login screen.

Comment by Anissa Lam [ 23/Feb/11 ]

I WFH today, and connect using VPN, my hostname becomes something like "dhcp-whq-twvpn-.......oracle.com" and thats what i put in the address field. I am not getting anywhere with this specified.

Comment by Jason Lee [ 23/Feb/11 ]

I think the culprit is this line in domain.xml:

<property name="restAuthURL" value="http://localhost:$

{ADMIN_LISTENER_PORT}/management/sessions"></property>

You can work around this for now by issuing this command:

asadmin --host $NEWHOST set configs.config.server-config.security-service.message-security-config.HttpServlet.provider-config.GFConsoleAuthModule.property.restAuthURL="http://$NEWHOST:\${ADMIN_LISTENER_PORT}

/management/sessions"

I'll see if I can find a better to handle that.

Comment by Tom Mueller [ 23/Feb/11 ]

Confirmed that when I replace "localhost" with the same name as is used with the admin-listener, then the admin console comes up fine.

Comment by Jason Lee [ 23/Feb/11 ]

I just committed a fix to trunk (r45246) that should address this issue without the property change workaround. My tests locally showed the issue is resolved.

Comment by walec51 [ 16/Jul/11 ]

Reopen this bug.

Got the exact same error with glassfish-3.1.1-b11

I using Debian 64 git and OpenJDK:

OpenJDK Runtime Environment (IcedTea6 1.8.7) (6b18-1.8.7-2~lenny1)
OpenJDK 64-Bit Server VM (build 14.0-b16, mixed mode)

I remember that 3.0.1 had problems this JSF under OpenJDK too.

Comment by walec51 [ 16/Jul/11 ]

PS. I can't login even if the address attribute is set or not

Comment by walec51 [ 16/Jul/11 ]

However my stack trace is a little different:

[#|2011-07-16T17:07:55.400+0200|WARNING|glassfish3.1.1|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=24;_ThreadName=Thread-2;|ApplicationDispatcher[] PWC1231: Servlet.service() for servlet FacesServlet threw exception
java.lang.RuntimeException: java.lang.reflect.InvocationTargetException while attempting to process a 'beforeCreate' event for 'event1'.
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:422)
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:394)
at com.sun.jsftemplating.layout.descriptors.LayoutComponent.beforeCreate(LayoutComponent.java:348)
at com.sun.jsftemplating.layout.descriptors.LayoutComponent.getChild(LayoutComponent.java:288)
at com.sun.jsftemplating.layout.LayoutViewHandler.buildUIComponentTree(LayoutViewHandler.java:556)
at com.sun.jsftemplating.layout.LayoutViewHandler.createView(LayoutViewHandler.java:255)
at com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:247)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:116)
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.ApplicationDispatcher.doInvoke(ApplicationDispatcher.java:787)
at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:649)
at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:483)
at org.apache.catalina.core.ApplicationDispatcher.doDispatch(ApplicationDispatcher.java:454)
at org.apache.catalina.core.ApplicationDispatcher.dispatch(ApplicationDispatcher.java:350)
at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:300)
at org.glassfish.admingui.common.security.AdminConsoleAuthModule.validateRequest(AdminConsoleAuthModule.java:231)
at com.sun.enterprise.security.jmac.config.GFServerConfigProvider$GFServerAuthContext.validateRequest(GFServerConfigProvider.java:1171)
at com.sun.web.security.RealmAdapter.validate(RealmAdapter.java:1445)
at com.sun.web.security.RealmAdapter.invokeAuthenticateDelegate(RealmAdapter.java:1323)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:551)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:623)
at org.apache.catalina.core.StandardPipeline.doChainInvoke(StandardPipeline.java:600)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:96)
at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:91)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:162)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:330)

...

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:636)
Caused by: 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:616)
at com.sun.jsftemplating.layout.descriptors.handler.Handler.invoke(Handler.java:442)
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:420)
... 44 more
Caused by: java.lang.UnsupportedOperationException: Cannot create XMLStreamReader or XMLEventReader from a javax.xml.transform.stream.StreamSource
at com.sun.xml.internal.stream.XMLInputFactoryImpl.jaxpSourcetoXMLInputSource(XMLInputFactoryImpl.java:283)
at com.sun.xml.internal.stream.XMLInputFactoryImpl.createXMLStreamReader(XMLInputFactoryImpl.java:143)
at org.jvnet.hk2.config.ConfigParser.parse(ConfigParser.java:115)
at org.jvnet.hk2.config.ConfigParser.parse(ConfigParser.java:110)
at org.jvnet.hk2.config.ConfigParser.parse(ConfigParser.java:106)
at org.glassfish.admingui.plugin.ConsolePluginService.init(ConsolePluginService.java:126)
at org.glassfish.admingui.plugin.ConsolePluginService.getIntegrationPoints(ConsolePluginService.java:428)
at org.glassfish.admingui.common.handlers.PluginHandlers.getIntegrationPoints(PluginHandlers.java:164)
at org.glassfish.admingui.handlers.ThemeHandlers.getThemeFromIntegrationPoints(ThemeHandlers.java:102)
... 50 more

Comment by walec51 [ 16/Jul/11 ]

A workaround is to install Sun's JVM and JDK:

java version "1.6.0_22"
Java(TM) SE Runtime Environment (build 1.6.0_22-b04)
Java HotSpot(TM) 64-Bit Server VM (build 17.1-b03, mixed mode)

I would really hope the Glassfish team would test on OpenJDK.
We should move to OpenJDK after the acquisition of Sun right ?
Is OpenJDK on the focus of Oracle or will it keep releasing SunJDK ?





[GLASSFISH-15965] Clustered instance page is missing Rotate Log button Created: 11/Feb/11  Updated: 06/Jul/11  Resolved: 25/Mar/11

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

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

promoted b41


Tags: 3-1_next, 3_1-exclude, 3_1_1-verified

 Description   

I thought this has already been logged a while back but cannot find a relevant issue, hence logging it here.

Clustered instance page is missing Rotate Log button. The backend functionality is there, since I can execute asadmin rotate-log --target=<clustered instance> and it works fine. Initially logging backend only allowed rotating of the log files for the whole cluster, but that's been changed. Therefore we should add Rotate Log button to clustered instance page to make it consistent with CLI and standalone instance page.



 Comments   
Comment by sirajg [ 25/Mar/11 ]

Fixed revision 45745

+ <sun:button id="rotateLog" text="$resource

{i18n.button.rotateLog}

" primary="#

{false}

" disabled="#

{pageSession.isStopped}

"
+ onClick="if ( getConfirm(this, '$resource

{i18nc.msg.JS.confirmRotateLog}

') )
+ { return submitAndDisable(this, '$resource

{i18n.button.Processing}

');}
+ else

{return false;}

" >
+ <!command
+ createMap(result="#

{requestScope.map}");
+ mapPut(map="#{requestScope.map}

", key="target", value="#

{pageSession.encodedInstanceName}

");
+ gf.restRequest(
+ endpoint="#

{sessionScope.REST_URL}

/rotate-log"
+ attrs="#

{requestScope.map}

"
+ method="POST"
+ result="#

{pageSession.props}

");
+ gf.redirect("#

{pageSession.selfPage}

");/>
+
+ </sun:button>
+

Comment by lidiam [ 06/Jul/11 ]

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





[GLASSFISH-15992] Properties: table wiped out on sort, error displayed afterwards Created: 15/Feb/11  Updated: 24/Jun/11  Resolved: 20/Feb/11

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

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

promoted build b43


Attachments: JPEG File noproperties-clickinstance.JPG     JPEG File noproperties.JPG     Text File server.log    
Tags: 3_1-exclude, 3_1_1-verified

 Description   

Steps to reproduce:

1. Click on server (Admin Server), Properties tab.
2. Click Add Property and fill out the blanks. Before or after hitting save (makes no difference), click on Override Value link, that sorts the table. Issue 1: At this point all the properties from the table disappear.
3. Click on Instance Properties tab - issue 2: the following error is displayed:

An error has occurred
REST Request 'http://localhost:4848/management/domain/servers/server//system-properties' failed with response code '404'.

Clicking anywhere in nodes tree clears out the issue.

This problem exists with cluster system properties table as well. Without adding any properties, if I click Override Value link, the table content disappears and the "wait, long running process" message shows and never goes away (have to reload the url). In case of standalone instance, table content disappears but the "wait" message does not come on.

This problem is present for both Current Value and Override Value sorting links on the properties tabs. Once the error occurs clicking on any tab for the same cluster or instance produces the 404 error.

In case of the sorting link Instance Variable Name on the standalone instance system properties tab, once I clicked that the "wait" message appeared and never went away.



 Comments   
Comment by lidiam [ 17/Feb/11 ]

Removed the exclude tag, so that the issue can be evaluated.

Comment by Anissa Lam [ 17/Feb/11 ]

This doesn't classify as show stopper. Add 3_1-exclude and Jason can fix this for 3.2.

Comment by Anissa Lam [ 20/Feb/11 ]

The value specified to sort the column is wrong, thus causing the issue.
Also notice that the value specified in the currentValue column for sorting is wrong too, fixed it as well.
Fix checked into the trunk.

Project: glassfish
Repository: svn
Revision: 45189
Author: anilam
Date: 2011-02-20 18:16:12 UTC
Link:

Log Message:
------------
GLASSFISH-15992 Fix the value that should be used to sort the currentValue and overrideValue column in the Systems Properties table.

Revisions:
----------
45189

Modified Paths:
---------------
trunk/v3/admingui/common/src/main/resources/configuration/systemProperties.jsf

Diffs:
------
Index: trunk/v3/admingui/common/src/main/resources/configuration/systemProperties.jsf
===================================================================
— trunk/v3/admingui/common/src/main/resources/configuration/systemProperties.jsf (revision 45188)
+++ trunk/v3/admingui/common/src/main/resources/configuration/systemProperties.jsf (revision 45189)
@@ -2,7 +2,7 @@

DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS HEADER.

  • Copyright (c) 2010 Oracle and/or its affiliates. All rights reserved.
    + Copyright (c) 2010-2011 Oracle and/or its affiliates. All rights reserved.

The contents of this file are subject to the terms of either the GNU
General Public License Version 2 only ("GPL") or the Common Development
@@ -114,12 +114,12 @@
<sun:tableColumn headerText="$resource

{i18n.systemProps.colInstanceName}

" sort="name" rowHeader="$boolean

{false}" id="col2">
<sun:textField columns="$int{40}" maxLength="#{sessionScope.fieldLengths['maxLength.common.PropertyName']}" id="col1St" value="#{td.value.name}" />
</sun:tableColumn>
- <sun:tableColumn id="currentValueCol" headerText="$resource{i18n.systemProps.ColCurrentValue}" sort="value" rowHeader="$boolean{false}

" id="col3">
+ <sun:tableColumn id="currentValueCol" headerText="$resource

{i18n.systemProps.ColCurrentValue}

" sort="currentValue" rowHeader="$boolean

{false}" id="col3">
<h:outputText id="currentVal" value="#{td.value.currentValue}" />
</sun:tableColumn>
- <sun:tableColumn id="overrideValCol" headerText="$resource{i18n.inst.ColOverrideValue}" sort="value" rowHeader="$boolean{false}

">
+ <sun:tableColumn id="overrideValCol" headerText="$resource

{i18n.inst.ColOverrideValue}

" sort="overrideValue" rowHeader="$boolean

{false}

">
<sun:textField id="overrideVal" columns="$int

{40}

" maxLength="#

{sessionScope.fieldLengths['maxLength.common.PropertyValue']}

" value="#

{td.value.overrideValue}

"/>
</sun:tableColumn>

Comment by lidiam [ 24/Jun/11 ]

Verified in build b08.





[GLASSFISH-15993] Properties: runtime exception on cancel for DAS instance properties Created: 15/Feb/11  Updated: 24/Jun/11  Resolved: 19/Feb/11

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

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

promoted build b43


Attachments: JPEG File properties-runtime-exception.JPG     Text File server.log    
Tags: 3_1-exclude, 3_1_1-verified

 Description   

Steps to reproduce:

1. Click on server (Admin Server), Properties tab.
2. Click on Instance Properties.
3. Click Cancel - runtime exeption is printed on screen.

This only happens for DAS Instance Properties tab. Cancel works fine on System Properties screen for DAS and on all other properties tabs for clusters, clustered instances and standalone instances.



 Comments   
Comment by lidiam [ 15/Feb/11 ]

Removed the 3_1-exclude tag, so that this issue can be evaluated.

Comment by Anissa Lam [ 15/Feb/11 ]

Not show stopper. exclude from 3.1

Comment by Anissa Lam [ 19/Feb/11 ]

Fixed in trunk.

Project: glassfish
Repository: svn
Revision: 45186
Author: anilam
Date: 2011-02-20 00:32:27 UTC
Link:
Log Message:
------------
GLASSFISH-15993. Specify parent page for DAS instance properties page's cancel button redirect to.

Revisions:
----------
45186

Modified Paths:
---------------
trunk/v3/admingui/common/src/main/resources/appServer/instanceProperties.jsf

Diffs:
------
Index: trunk/v3/admingui/common/src/main/resources/appServer/instanceProperties.jsf
===================================================================
— trunk/v3/admingui/common/src/main/resources/appServer/instanceProperties.jsf (revision 45185)
+++ trunk/v3/admingui/common/src/main/resources/appServer/instanceProperties.jsf (revision 45186)
@@ -2,7 +2,7 @@

DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS HEADER.

  • Copyright (c) 2010 Oracle and/or its affiliates. All rights reserved.
    + Copyright (c) 2010-2011 Oracle and/or its affiliates. All rights reserved.

The contents of this file are subject to the terms of either the GNU
General Public License Version 2 only ("GPL") or the Common Development
@@ -54,8 +54,7 @@
urlencode(value="#

{pageSession.instanceName}

" encoding="UTF-8" result="#

{pageSession.encodedInstanceName}");
setSessionAttribute(key="serverInstTabs" value="instanceProps");
setPageSessionAttribute(key="listLink" value="#{request.contextPath}/common/appServer/instanceProperties.jsf?instanceName=${instanceName}");
-
-
+ setPageSessionAttribute(key="parentPage", value="#{request.contextPath}/common/appServer/serverInstGeneralPe.jsf?instanceName=#{pageSession.encodedInstanceName}

");
setPageSessionAttribute(key="selfPage", value="#

{request.contextPath}

/common/appServer/instanceProperties.jsf?instanceName=#

{pageSession.encodedInstanceName}");
setPageSessionAttribute(key="parentUrl", value="#{sessionScope.REST_URL}/servers/server/#{pageSession.encodedInstanceName}

");
setPageSessionAttribute(key="selfUrl", value="#

{pageSession.parentUrl}

");

Comment by lidiam [ 24/Jun/11 ]

Verified in build b08.





[GLASSFISH-15995] Configuration: server config displayed, when GMS for any other config is chosen in right frame Created: 15/Feb/11  Updated: 23/Jun/11  Resolved: 19/Feb/11

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

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

promoted build b43


Attachments: JPEG File wrong-config.JPG    
Issue Links:
Duplicate
is duplicated by GLASSFISH-16027 Configuration: right hand side GMS li... Closed
Tags: 3_1-exclude, 3_1_1-verified

 Description   

Steps to reproduce:

1. Create a cluster, e.g. c-1.
2. Click on cluster's configuration Tree Node.
3. In the right hand frame click on Group Management Services - notice that the right item is highlighted in the nodes tree, however at the top of the page it says:

Configuration Name:

server-config

This only happens when clicking on GMS in the right hand list. If it's clicked through the expansion of the nodes tree, in the left frame, the correct config is displayed.

The same issue exists for a standalone instance - if GMS is chosen on the right, server-config GMS is displayed, even though tree highlighting will be correctly showing standalone instance's GMS.



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

The tree highlight is wrong.
Always look at the configuration name of the page.

This is a bug that there is no config name passed to the GMS page, and so it just use server-config.

Comment by lidiam [ 17/Feb/11 ]

This problem occurs for any config, when GMS is clicked in the right hand side panel. Also, there is no GMS under server-config, which makes it even more confusing.

Comment by Anissa Lam [ 19/Feb/11 ]

Project: glassfish
Repository: svn
Revision: 45187
Author: anilam
Date: 2011-02-20 00:51:28 UTC
Link:

Log Message:
------------
GLASSFISH-15995. Fix configName for the GMS configuration plugin link.

Revisions:
----------
45187

Modified Paths:
---------------
trunk/v3/admingui/cluster/src/main/resources/configuration/gmsConfigurationLink.inc

Diffs:
------
Index: trunk/v3/admingui/cluster/src/main/resources/configuration/gmsConfigurationLink.inc
===================================================================
— trunk/v3/admingui/cluster/src/main/resources/configuration/gmsConfigurationLink.inc (revision 45186)
+++ trunk/v3/admingui/cluster/src/main/resources/configuration/gmsConfigurationLink.inc (revision 45187)
@@ -43,7 +43,7 @@
<sun:property rendered="#

{pageSession.gmsShowIt}">
<sun:hyperlink rendered="#{pageSession.gmsShowIt}

"
toolTip="$resource

{i18ncs.tree.gms.tooltip}

"

  • url="/cluster/configuration/gms.jsf?configName=$ {configName}

    "
    + url="/cluster/configuration/gms.jsf?configName=#

    {pageSession.configName}

    "
    >

<sun:image url="/resource/cluster/images/management_services.gif" />

Comment by lidiam [ 23/Jun/11 ]

Verified in build b08.





[GLASSFISH-15990] Properties: success message on save not displayed Created: 15/Feb/11  Updated: 23/Jun/11  Resolved: 10/Mar/11

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

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

promoted build b43


Tags: 3-1_next, 3_1_1-verified

 Description   

Steps to reproduce:

1. Create a cluster with one instance.
2. Go to clustered instance page, Properties tab.
3. Click Add Property and fill in the blanks. Hit Save and notice that "New values successfully saved" message does not appear.

This only happens for a clustered instance. The message is displayed fine for a standalone instance.



 Comments   
Comment by Jason Lee [ 10/Mar/11 ]

Fix committed (r45473)

Comment by lidiam [ 23/Jun/11 ]

Verified in build b08.





[GLASSFISH-15996] Regression: nodes tree not updated with new lifecycle module Created: 15/Feb/11  Updated: 23/Jun/11  Resolved: 03/Mar/11

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

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

build: promoted b43


Tags: 3_1_1-verified

 Description   

Tried this on Firefox on windows xp and safari on mac with the same result: newly created lifecycle module is not displayed in the tree. Steps to reproduce:

1. Click on Lifecycle Modules, New button.
2. Fill in the required fields and click Save to create a new lifecycle module.
3. New module is displayed in the table, but the tree on the left is never updated with it.

Workaround: reload the Admin Console url.

This worked in earlier builds, e.g. b28 (see issue http://java.net/jira/browse/GLASSFISH-14598).



 Comments   
Comment by Anissa Lam [ 03/Mar/11 ]

Fixed in the trunk on 3/3/2011.

Sending common/src/main/resources/applications/lifecycles.jsf
Transmitting file data .
Committed revision 45394.

Comment by lidiam [ 23/Jun/11 ]

Verified in build b08.





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

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

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

Issue Links:
Duplicate
is duplicated by GLASSFISH-16054 Regression: Status showed incorrectly... Resolved
Tags: 3_1-exclude, 3_1-release-note-added, 3_1-release-notes

 Description   

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

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

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



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

The issue has been fixed in the trunk,

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

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

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

use the following CLI to see the info:

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

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

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

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

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

Comment by Anissa Lam [ 18/Feb/11 ]

Fixed in the trunk.

Comment by Scott Fordin [ 12/Apr/11 ]

Added issue to 3.1 Release Notes.

Comment by shaline [ 22/Jun/11 ]

Verified on promoted b08.





[GLASSFISH-14902] Cannot tell what clustered instace page I'm on Created: 30/Nov/10  Updated: 20/Jun/11  Resolved: 09/Mar/11

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

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

build: ogs-3.1-b31-11_30_2010.zip



 Description   

Create a cluster with two instances. Click on instance one and go to Properties tab. Once there, one cannot tell which instance the properties refer to. The same goes for the Monitoring tab.



 Comments   
Comment by Anissa Lam [ 01/Dec/10 ]

Fixed. And also ensure all tabs for standalone, cluster, cluster instance and server page has the cluster name or instance name shown.

Comment by lidiam [ 03/Mar/11 ]

The only remaining tab that does not have the instance/cluster information is JMS Physical Destinations.

Comment by Anissa Lam [ 09/Mar/11 ]

Besides adding the cluster name, also notice that the standalone instance and DAS JMS Phys. Dest also missing this info.
Change apply to all these pages.

Project: glassfish
Repository: svn
Revision: 45457
Author: anilam
Date: 2011-03-10 00:25:11 UTC
Link:

Log Message:
------------
GLASSFISH-14902. Add Cluster name/Instance name to the JMS Phy Dest page.

Revisions:
----------
45457

Modified Paths:
---------------
trunk/v3/admingui/jms-plugin/src/main/resources/physdest/serverPhysDest.jsf
trunk/v3/admingui/jms-plugin/src/main/resources/physdest/clusterPhysDest.jsf
trunk/v3/admingui/jms-plugin/src/main/resources/physdest/standaloneInstPhysDest.jsf

Comment by lidiam [ 20/Jun/11 ]

Verified in 3.1.1 build b08.





[GLASSFISH-16223] admin_gui gets undeployed after my application redeploy Created: 16/Mar/11  Updated: 15/Jun/11  Resolved: 11/Apr/11

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

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

Attachments: Text File fullstacktrace.txt     PNG File Екран.png    

 Description   

After i redeploy my app on server - admin gui shows this error and gets undeployed. Application is redeployed fine but after this i can't access admin_gui anymore: instead of it Server is running page showed.

See text error below and in attachment

HTTP Status 500 -

type Exception report

message

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

exception

javax.servlet.ServletException: Application was not properly initialized at startup, could not find Factory: javax.faces.application.ApplicationFactory

root cause

java.lang.IllegalStateException: Application was not properly initialized at startup, could not find Factory: javax.faces.application.ApplicationFactory

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



 Comments   
Comment by mariohmol [ 26/Mar/11 ]

Same here! Every time i redeploy i have to restart the glassfish.

Version: GlassFish Server Open Source Edition 3.1 (build 43).

Full stack trace attached here!

Regards,

Comment by Anissa Lam [ 29/Mar/11 ]

I don't know if you redeploy your app using CLI or GUI, but i assume both results the same.
If you undeploy instead of redeploy, you are seeing the same thing also ?

mariohomol/illia , please provide a test app that i can use to reproduce the problem. Not much i can do without a test app to reproduce the problem. Really appreciate your help here.

Comment by mariohmol [ 29/Mar/11 ]

HY, I'm using reeploy from GUI.

About the apps, rigth now i'm using 4 projects in early stages. All was created as a Enterprise Application on Netbeans (EAR-EJB-WAR), all using JEE6.

In this server i'm monitoring and at all times ther is 2.5gb free ram memory and processor dont get up to 50%.

Doing undeploy I get same error, i didnt have the chance to deploy again. So maybe the problem is related to undeploy.

Try to create a new EAR on Netbeans and using GF, if you do not get the error, say to me that i can try to get on of this projects, clean it and try to reproduce the error.

Regards,

Comment by Anissa Lam [ 29/Mar/11 ]

Can you try using CLI to undeploy ? Does this bring down the GUI as well ?
This will tell me if this is due to the fact that the deploy/undeploy of app is running in the same thread as the GUI, as reported in GLASSFISH-15905.
I am currently working on fixing GLASSFISH-15905.
Still requesting you to attach your app thats created from netbeans. thanks a lot.

Comment by mariohmol [ 29/Mar/11 ]

Hy,

could you please show me how to do it using CLI?

I made some tests here and you are ritgh, i simple EAR project on Netbeans works. I will see if it is possible to clean some classes on a project and send to you.

Regards,

Comment by Anissa Lam [ 29/Mar/11 ]

Hi, here is the instruction using CLI, assuming you did not deploy the app to other cluster or instances.

%cd <glassfish3>/glassfish/bin

%asadmin list-applications <== this should give you the list of applications you have deployed.

%asadmin undeploy hello <== assuming hello is on the list returned from above cmd.

You can then try go to the console, click on the applications node. IF everything works, the undeployed application should not list here. (of course, if GUI is working).

thanks for trying to get me the test app.

Comment by mariohmol [ 29/Mar/11 ]

Hy,

same error using CLI.

If you send me your email and promise to no publish the ear on web, i can send to help you on testing.

Regards,

Comment by Anissa Lam [ 31/Mar/11 ]

mariohmol, i have sent the private email to you 2 days ago. waiting for your reply.

Comment by Illia Romanenko [ 31/Mar/11 ]

Please contact me off the list i will send you war file with the same promise

Comment by mariohmol [ 03/Apr/11 ]

Hy guys,

with the nightly build works partially.
http://dlc.sun.com.edgesuite.net/glassfish/3.2/nightly/glassfish-3.2-b01-04_02_2011.zip

I have 2 applications in two differentes virtual servers. When I redeploy Application 2 it shows me a error about context of Application 1.

Exception while loading the app : java.lang.Exception: WEB0113: Virtual server [server] already has a web module [App1-war.war] loaded at [/]; therefore web module App2#App2-war.war cannot be loaded at this context path on this virtual server.

If I Undeploy and Afterwards Deploy, works.

So the Redploy still not working.

Regards,

Comment by Anissa Lam [ 07/Apr/11 ]

mariohmol,
what you described above about 2 app not working properly with re-deploy seems to be a different bug than what is reported here.
Please open up another bug, maybe filed against deployment.

What is reported here is about the console no longer works after undeploy or redeploy an existing app.
I can no longer reproduce that with 3.2 build 01

Please confirm that with 3.2 build 01, admin console works properly after you undeploy/redeploy your application.

Comment by Anissa Lam [ 07/Apr/11 ]

Illia, thanks for the app.
I have verified that with the changes from DF to using REST API, I no longer see the problem.

I have tried the following sequence using CLI: deploy, undeploy, deploy, deploy with --force=true, undeploy
and also with GUI:

  • deploy, undeploy, deploy with force checkbox, undeploy, deploy, redeploy, undeploy

Admin console works perfectly after each request.
And your application works fine too.

Please try that with b01 (you can download that from http://dlc.sun.com.edgesuite.net/glassfish/3.2/promoted/) and let me know if you see any issue.

Comment by mariohmol [ 10/Apr/11 ]

Hy,

you are right, the admin console still workign after redeploy, what does not work is the redeploy itself.

Anyway, to me is ok right now because i can undeploy and then deploy afterwards.

Good work!

Regards,

Comment by Anissa Lam [ 11/Apr/11 ]

I am marking this bug resolved.
The fix is checked in before the 3.1.1 branch created, so I the fix is in both 3.1.1 b01 and 3.2 b01/MS1.

mariohmol, if i understand it right, there is issue with your app if you 'redeploy' it, but 'undeploy' follow by 'deploy' again works fine. Maybe you should open up a bug against deployment.

Comment by Illia Romanenko [ 12/Apr/11 ]

Sorry for delay - i can confirm now that it works but still my app not being reinitialized after redeploy... But if i'm doing undeploy and then deploy - it works fine

Comment by Illia Romanenko [ 12/Apr/11 ]

Thanks Anissa

Comment by Anissa Lam [ 15/May/11 ]

The fix for GLASSFISH-15905 by using REST API instead of Deployment Facility API for application deployment also fixes this issue.
The fix is checked in before the 3.1.1 branch created, so I the fix is in since 3.1.1 b01 and 3.2 b01/MS1.

Comment by rdelaplante [ 26/May/11 ]

FYI the root cause of this bug may be related to a bug in JSF that was recently fixed: JAVASERVERFACES-1542

Comment by Illia Romanenko [ 26/May/11 ]

rdelaplante, not sure about this - because it works fine on prev versions of glassfish

Comment by rdelaplante [ 26/May/11 ]

We've been running on GlassFish since 2.0 and the bug in JAVASERVERFACES-1542 didn't affect us until we upgraded to GlassFish 3.1. I'm not sure why it just started happening, but that's why I thought it could be related to this ticket. When the problem happens to us, we get the same error except it complains about RenderKitFactory instead of ApplicationFactory. The ticket says all factories are affected.

Comment by rdelaplante [ 15/Jun/11 ]

Earlier I thought that JAVASERVERFACES-1542 was the cause of this bug. JSF 2.1.2 has since been released, and I tried replacing jsf-impl.jar in glassfish/modules to see if it solves this ticket's problem. It does not. I have not yet tried GlassFish 3.1.1.

Comment by Anissa Lam [ 15/Jun/11 ]

I am getting confused. Are you saying the issue comes back ?
Lets start from the beginning.

1. If you deploy your app, does Admin Console still work correctly ?

2. If you undeploy your app, does Admin Console still work correctly ?

3. If you do deploy then undeploy then deploy again, does Admin Console still work correctly ?

4. If you deploy, then do "deploy --force=true" , does Admin Console still work correctly ?

If the answer is No to any of the above, please attach a sample app, reopen the bug so I can look into this again.

You mentioned "I have not yet tried GlassFish 3.1.1.". Please try the above step using latest promoted build available on http://dlc.sun.com.edgesuite.net/glassfish/3.1.1/promoted/

Comment by rdelaplante [ 15/Jun/11 ]

I was only following up on my own hypothesis from May 26 in case anyone is interested. I suggested that the fix in this ticket may have been unnecessary because the root cause of the problem might be a bug in JSF which is now fixed. Knowing that your fix is in GlassFish 3.1.1 and not 3.1.0, I decided to test my hypothesis by replacing jsf-impl.jar in GlassFish 3.1.0 with a newer version that contains the fix I am talking about. That did not solve the problem, and therefore I was wrong. The bug in JSF is not related to this ticket.

Comment by Anissa Lam [ 15/Jun/11 ]

I see. Thanks for clarifying this.





[GLASSFISH-16335] Windows is still the Red-Haired StepChild of GlassFish Created: 11/Apr/11  Updated: 06/Jun/11  Resolved: 06/Jun/11

Status: Closed
Project: glassfish
Component/s: build_system
Affects Version/s: None
Fix Version/s: 3.1.1_b01

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

Issue Links:
Dependency
blocks GLASSFISH-16331 stop/start/restart domain local comma... Resolved

 Description   

Right now GlassFish 3.2 on Windows is fairly hosed because of 16331.

What happens is that you can not successfully stop or restart a server using asadmin. Probably a bunch of other commands would fail as well – I didn't try.

So right now restart-domain and restart-local-instance WILL NOT WORK at all.

Quick Look tests will not pass on Windows now. The tests are doing exactly what they are supposed to do – loudly screaming a warning that something broke. But we would never know this because we have no Hudson build on Windows that also runs the QL tests on Windows (I think).

Luckily I run on Windows and I noticed the problem 2 days after it occurred.

My Recommendation: Have the Windows trunk build also run the QL tests as part of every build.



 Comments   
Comment by Byron Nevins [ 11/Apr/11 ]

It "blocks" because there is no "official" way to check if Windows-only bugs are fixed – like we do with the regular hudson jobs for regular bug fixes.

Comment by scatari [ 02/Jun/11 ]

The related bug http://java.net/jira/browse/GLASSFISH-16335 is resolved.

Comment by scatari [ 06/Jun/11 ]

Fixing the target version to include the correct build number.





[GLASSFISH-16150] Created a domain with master password, restart-instance - failed. Created: 03/Mar/11  Updated: 06/Jun/11  Resolved: 08/Mar/11

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

Type: Bug Priority: Major
Reporter: easarina 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-16146 Umbrella bug. Created a domain with ... Open
Tags: 3_1-next

 Description   

Executed steps that were described in the umbrella bug 16146.

Then executed restart-instance:
=======================================================
asadmin --passwordfile ./password.txt --port 9999 --host localhost --user admin restart-instance in9
No response from Domain Admin Server after 600 seconds.
The command is either taking too long to complete or the server has failed.
Please see the server log files for command status.
Command restart-instance failed.
====================================================
According to the messages in the server.log the instance was stopped. After the mesages regarding the stopping of the instance, no other correspondent messages were seen.

The password.txt file had such content:

AS_ADMIN_PASSWORD=adminadmin
AS_ADMIN_MASTERPASSWORD=admin123



 Comments   
Comment by Byron Nevins [ 07/Mar/11 ]

This is user error.

restart-domain is clearly documented as stopping the server followed by starting it up EXACTLY the same way as it was originally started. You did not originally start it with a password file.

For a fair test – you need to call start-domain (not restart) with the arguments documented in this issue. After that a restart-domain ought to work. If it doesn't please document all of your steps and reopen.

Comment by easarina [ 07/Mar/11 ]

This bug talks about restart-instance, not restart-domain. The steps are3 listed in the bug.

Comment by Byron Nevins [ 07/Mar/11 ]

Reassigning to Elena.

restart-domain, restart-instance. My previous comment applies to both.

Go to the machine with the instance on it and start it (not restart it) with the password file. Then you can restart it.

You can reassign to me if the above fails – else close it.

Comment by easarina [ 07/Mar/11 ]

Please see all previous steps in the umbrella bug:

http://java.net/jira/browse/GLASSFISH-16146

The instance was started with passwordfile. Then I've tried to restart instance with and without step 6 from 16146, stop-local-instance. In both cases restart-instance created timeout.

Comment by Byron Nevins [ 08/Mar/11 ]

Confirmed! Nice job Elena.

Here is my Windows script for reproducing:

rem ===== 16150.bat =====================

call asadmin --passwordfile ./password.txt --user admin create-domain --domaindir /glassfish3/glassfish/domains --adminport 9999 --instanceport 4444 --savemasterpassword=true --usemasterpassword=true --savelogin=false --checkports=true --nopassword=false domain12
pause

call asadmin start-domain domain12
pause

call asadmin --passwordfile ./password.txt --port 9999 --host localhost --user admin create-cluster c1
pause

call asadmin --passwordfile ./password.txt --port 9999 --host localhost --user admin create-local-instance --cluster c1 --node localhost-domain12 in9
pause

call asadmin --passwordfile ./password.txt --port 9999 --host localhost --user admin start-local-instance --node localhost-domain12 in9
pause

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

The I tried to restart like this:

call asadmin --passwordfile ./password.txt --port 9999 --host localhost --user admin restart-instance in9

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

result – server stopped but never restarted.

Comment by Byron Nevins [ 08/Mar/11 ]

Here is the problem – which is trivial to fix.

(1) GlassFish servers always always always have the current working directory set to their config directory
(2) You gave a RELATIVE path to the password file.

So – the running server had NO WAY of knowing what directory you originally ran the command from. So the running server created a JVM and then told asadmin to use a password file that is located in the config directory! At that point it "hung". But not really. Your client asadmin called restart-instance and then waited for it to restart. It has NO WAY of knowing that it failed to restart. Meantime the running server was killed, and the new JVM ran asadmin which resulted in EXACTLY what would happen if you ran this command:

asadmin --passwordfile /i_dont_exist --port 9999 --host localhost --user admin start-local-instance --node localhost-domain12 in9

I.e. asadmin printed an error into space and exited. And you waited for a pointless 10 minutes.

Note: If you ran with verbose mode – you would have seen no problem at all. Try it! This would have been a VERY useful clue.

WORK-AROUND FOR END-USER:

(1) copy the password.txt to the config dir – which is where it ought to be anyways!
==or==
(2) give the full path for the password file

FIX FOR GF CODE:

(1) asadmin itself should see that the value of --passwordfile is a file – and automatically change ALL such options to the full path using SmartFile.sanitize()

Comment by Byron Nevins [ 08/Mar/11 ]

D:\gf\v3\admin\cli>svn commit
Sending cli\src\main\java\com\sun\enterprise\admin\cli\ProgramOptions.java
Transmitting file data .
Committed revision 45444.

Comment by scatari [ 06/Jun/11 ]

Fixing the target version to include the correct build number.





[GLASSFISH-16232] If an instance was stopped, restart-instance doesn't start it. Created: 17/Mar/11  Updated: 06/Jun/11  Resolved: 19/Mar/11

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

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

Tags: 3_1-next

 Description   

Latest continuous build.

Executed the follow commands:
Started domain1, created a local instance using localhost-domain1 node, started an instance, then stopped the instance. Then executed
==============================================================
asadmin restart-instance in1
remote failure: Error trying to restart the instance named in1 : Remote server does not listen for requests on [localhost:24848]. Is the server up?
Command restart-instance failed.
------------------------------------------------------------------------------
asadmin restart-local-instance --nodedir=$S1AS_HOME/nodes --node localhost-domain1 --debug=true --force=true --kill=true in1
Server is not running, will attempt to start it...
CLI801 Instance is already synchronized
Waiting for in1 to start ................
Successfully started the instance: in1
instance Location: /opt/glassfish3/glassfish/nodes/localhost-domain1/in1
Log File: /opt/glassfish3/glassfish/nodes/localhost-domain1/in1/logs/server.log
Admin Port: 24848
Command restart-local-instance executed successfully.
=====================================================

Then stopped an instance and domain and executed:
=======================================================================
asadmin restart-domain --debug=true --domaindir=$S1AS_HOME/domains --force=true --kill=true domain1
Server is not running, will attempt to start it...
Waiting for domain1 to start .......
Successfully started the domain : domain1
================================================================

Then I've created ssh node and created an instance for that node using create-instance, then run start-instance, stop-instance

After that executed restart-instance against that instance:

asadmin restart-instance in2
remote failure: Error trying to restart the instance named in2 : Remote server does not listen for requests on [localhost:24849]. Is the server up?
Command restart-instance failed.
jed-asqe-7#/opt/appserver-sqe/ee/adm_cli] asadmin list-instances
in1 running
in2 not running
Command list-instances executed successfully.
asadmin list-instances --long
NAME HOST PORT PID CLUSTER STATE
in1 localhost 24848 2813 — running
in2 localhost 24849 -1 — not running
Command list-instances executed successfully.
asadmin list-nodes --long
NODE NAME TYPE NODE HOST INSTALL DIRECTORY REFERENCED BY
localhost-domain1 CONFIG localhost /opt/glassfish3 in1
node2 SSH localhost /opt/glassfish3 in2
Command list-nodes executed successfully.

I.e. if instance/domain were stopped, restart-local-instance and restart-domain start the correspondent server, but restart-instance - not. First this is an inconsistent behavior, I believe all restart commands have the same behavior.

Second, I think that restart-instance have to have the same behavior , as start-instance if it would be executed against an instance that was stopped.



 Comments   
Comment by Tom Mueller [ 17/Mar/11 ]

restart-instance should be like restart-domain and restart-local-instance in that if the instance isn't up, it should at least try to start it.

Comment by Tom Mueller [ 18/Mar/11 ]

Carla, Byron requested that you take a look at this.

Comment by Byron Nevins [ 18/Mar/11 ]

I think this should not be "fixed".

I think it was a BIG mistake when restart-server commands were changed to start the server if they are not running.

It is illogical. It is over-engineering. I said RESTART – not START!

This opens a HUGE can of expensive worms and it is already guaranteed to be IMPOSSIBLE to implement correctly in all cases. A very common case is that the instance is not running on a remote machine and there is no SSH connection. That means it is impossible to start it.

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

If you decide to go ahead anyways this should go to Joe to do this:
--> if the instance is NOT running AND the instance is on a remote machine AND SSH is setup –
then call start-local-instance for it via SSH
Otherwise if the instance is co-located with DAS – call start-instance
====================================================
The Final case is when the instance lives on a different machine and there is no SSH in case we need to emit a new complicated message explaining it
====================================================
When that's all done Doc needs to be updated to explain this complicated behavior

Comment by Tom Mueller [ 18/Mar/11 ]

As Elena pointed out in the issuee, all of the restart-* command should behave the same. restart-domain and restart-local-instance already do a start if the server isn't running. Restart-instance should at least try to do the start if it can.

Comment by Byron Nevins [ 18/Mar/11 ]

Assigned to Tom to think it over.
Maybe we should discuss at next Admin iTeam?

Comment by Byron Nevins [ 19/Mar/11 ]

D:\gf\v3\cluster>svn commit
Sending cluster\admin\src\main\java\com\sun\enterprise\v3\admin\cluster\LocalStrings.properties
Sending cluster\admin\src\main\java\com\sun\enterprise\v3\admin\cluster\RestartInstanceCommand.java
Sending cluster\admin\src\main\java\com\sun\enterprise\v3\admin\cluster\StartInstanceCommand.java
Transmitting file data ...
Committed revision 45632.

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

Now restart-instance calls start-instance (with default args) if the instance isn't already running.

Comment by scatari [ 06/Jun/11 ]

Fixing the target version to include the correct build number.





[GLASSFISH-15914] Sporadical error messages Created: 09/Feb/11  Updated: 27/May/11  Resolved: 26/May/11

Status: Resolved
Project: glassfish
Component/s: web_container
Affects Version/s: 3.1_b40
Fix Version/s: 3.1.1_b01

Type: Bug Priority: Major
Reporter: rsmogura Assignee: Amy Roh
Resolution: Invalid Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Cluster with virtual server (hosting), two instances few virtual hosts


Tags: 3_1-next

 Description   

I got sometimes error message. Probelm disapear after few refreshes or after going to other virtual host.

Report of HTTP
HTTP Status 500 - Cannot find message associated with key standardEngine.noHost
type Exception report
messageCannot find message associated with key standardEngine.noHost
descriptionThe server encountered an internal error (Cannot find message associated with key standardEngine.noHost) that prevented it from fulfilling this request.
exception
java.lang.IllegalStateException
note The full stack traces of the exception and its root causes are available in the GlassFish Server Open Source Edition 3.1 logs.

Logs shows
[#|2011-02-09T19:47:42.466+0100|WARNING|glassfish3.1|javax.enterprise.system.container.web.com.sun.enterprise.web._vs.server|_ThreadID=123;_ThreadName=Thread-14;|StandardWrapperValve[default]: PWC1406: Servlet.service() for servlet default threw exception
java.lang.IllegalStateException
at org.apache.catalina.connector.ResponseFacade.sendError(ResponseFacade.java:505)
at org.apache.catalina.servlets.DefaultServlet.serveResource(DefaultServlet.java:810)
at org.apache.catalina.servlets.DefaultServlet.doGet(DefaultServlet.java:414)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:735)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:848)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1534)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:281)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:595)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:98)
at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:91)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:162)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:326)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:227)
at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:232)
at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:337)
at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:817)
at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:746)
at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:939)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
at java.lang.Thread.run(Thread.java:662)



 Comments   
Comment by Shing Wai Chan [ 09/Feb/11 ]

Fix for the error message:

Sending web-core/src/main/java/org/apache/catalina/connector/CoyoteAdapter.java
Sending web-core/src/main/resources/org/apache/catalina/connector/LocalStrings.properties
Transmitting file data ..
Committed revision 45022.

Comment by Shing Wai Chan [ 09/Feb/11 ]

Note that the above means that request.getHost() is null.
The fixed error message will print information about getRequest().getServerName().
This will help us to identify if there is any issue in a particular configuration.

Comment by rsmogura [ 12/May/11 ]

I saw this again with version 3.2-b03.

P.S. Any way to reopen issue?

Comment by Shing Wai Chan [ 12/May/11 ]

My previous fix is for "HTTP Status 500 - Cannot find message associated with key standardEngine.noHost". Do you still see that?

There is an IllegalStateException as the response is already committed.
From stack trace, mod_jk is used.

Do you have the steps to reproduce this?

Comment by rsmogura [ 16/May/11 ]

Sorry. I see similar error, in same situation and configuration, but different content, after some time of stand by (no processing) I got message something about no host name and IP address, what is interesting I saw this IP address changes, and after few requests everything works correct. I should have properly configured virtual hosting as well with GF and mod_jk.

Maybe later I will be able to grab detailed message, as in logs I have only java.lang.IllegalStateException.

Maybe Your patch just fixed message, but I wonder why I got 500 with no host.

If You want I may open new bug.

Comment by rsmogura [ 19/May/11 ]

I captured this error, it's only visible as error response, logs only shows IlleglaStateException without any usable root cause.

HTTP Status 500 - No Host matches server name 217.118.26.142
type Exception report
message No Host matches server name 217.118.26.142

descriptionThe server encountered an internal error (No Host matches server name 217.118.26.142) that prevented it from fulfilling this request.
exception
java.lang.IllegalStateException
note The full stack traces of the exception and its root causes are available in the GlassFish Server Open Source Edition 3.2-b03 logs.

After refresh page loads, but for one (image) file in response I got 500 error. Next refresh gives "No Host matches server name 217.118.26.143" in content of CSS file (IP changed), debugging shows browser doesn't sends cookie that points requests to particular node. Next refresh and everything works correctly.

Comment by Amy Roh [ 23/May/11 ]

Please include your domain.xml and complete server.log in order to understand your setup and reproduce the error.

Comment by rsmogura [ 26/May/11 ]

domain.xml - stripped from passwords, resources IPs, user's names etc

Comment by Amy Roh [ 26/May/11 ]

This is apache configuration, dns, or file permission problem. Do you have 217.118.26.142 in the /etc/hosts file?

I found these configuration setup suggestions to avoid the "No Host matches server name" issue and there are others you can find online.

http://rc3.org/2004/12/12/no-host-matches-server-name
http://www.webmasterworld.com/apache/3038131.htm





[GLASSFISH-16035] In b43 - WebServices Samples in javaee SDK fail to deploy Created: 17/Feb/11  Updated: 19/May/11  Resolved: 19/May/11

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

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

RHEL 5 system 64 bit OS, Browser is Firefox 3.6.13, Build java_ee_sdk-6u2-b43-jdk-linux.sh. JDK 1.6.0_24 or JDK1.6.0_23 Linux.


Attachments: Text File GLASSFISH-16035.patch    
Tags: 3_1-exclude

 Description   

With build43 using SDK with Linux JDK, the Web Services samples fail to deploy. This problem was not seen on build41. Just verified to make sure. Nor the failures are seen with the latest jdk (JDK1.6.0_24)

The deployment failure is shown when invoking "ant all" in /glassfish3/glassfish/samples/javaee6/webservices/hello-singleton-ejb (as one example). The error is:

deploy:
[exec] Deprecated syntax, instead use:
[exec] asadmin --user admin --passwordfile /home/sqe/Workspace/glassfish3/glassfish/samples/bp-project/passwordfile --host localhost --port 4848 deploy [options] ...
[exec] Command deploy failed.
[exec] remote failure: Error occurred during deployment: Exception while deploying the app [hello-singleton-ejb] : com.sun.enterprise.deployment.EjbBundleDescriptor cannot be cast to com.sun.enterprise.deployment.WebServicesDescriptor. Please see server.log for more details.

In the server.log, the following is displayed:
[#|2011-02-17T08:52:59.785-0800|SEVERE|glassfish3.1|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=80;_ThreadName=Thread-1;|Exception while deploying the app [hello-singleton-ejb]|#]

[#|2011-02-17T08:52:59.786-0800|SEVERE|glassfish3.1|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=80;_ThreadName=Thread-1;|com.sun.enterprise.deployment.EjbBundleDescriptor cannot be cast to com.sun.enterprise.deployment.WebServicesDescriptor
java.lang.ClassCastException: com.sun.enterprise.deployment.EjbBundleDescriptor cannot be cast to com.sun.enterprise.deployment.WebServicesDescriptor
at com.sun.enterprise.deployment.io.runtime.WLWebServicesDeploymentDescriptorFile.<init>(WLWebServicesDeploymentDescriptorFile.java:62)
at com.sun.enterprise.deployment.archivist.Archivist.writeWLWebServicesDescriptors(Archivist.java:1092)
at com.sun.enterprise.deployment.archivist.Archivist.writeWLRuntimeDeploymentDescriptors(Archivist.java:1034)
at com.sun.enterprise.deployment.archivist.Archivist.writeExtraDeploymentDescriptors(Archivist.java:1045)
at com.sun.enterprise.deployment.archivist.Archivist.writeDeploymentDescriptors(Archivist.java:961)
at com.sun.enterprise.deployment.archivist.DescriptorArchivist.write(DescriptorArchivist.java:176)
at com.sun.enterprise.deployment.archivist.DescriptorArchivist.write(DescriptorArchivist.java:83)
at org.glassfish.javaee.core.deployment.DolProvider.saveAppDescriptor(DolProvider.java:304)
at org.glassfish.javaee.core.deployment.DolProvider.load(DolProvider.java:199)
at org.glassfish.javaee.core.deployment.DolProvider.load(DolProvider.java:93)
at com.sun.enterprise.v3.server.ApplicationLifecycle.loadDeployer(ApplicationLifecycle.java:826)
at com.sun.enterprise.v3.server.ApplicationLifecycle.setupContainerInfos(ApplicationLifecycle.java:768)
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:370)
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:1067)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1200(CommandRunnerImpl.java:96)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1247)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1235)
at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:465)
at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:222)
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:234)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:822)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:719)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1013)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:662)

#]

[#|2011-02-17T08:52:59.792-0800|SEVERE|glassfish3.1|javax.enterprise.system.tools.admin.org.glassfish.deployment.admin|_ThreadID=80;_ThreadName=Thread-1;|Exception while deploying the app [hello-singleton-ejb] : com.sun.enterprise.deployment.EjbBundleDescriptor cannot be cast to com.sun.enterprise.deployment.WebServicesDescriptor|#]

The steps to reproduce this issue are:

  • Install java_ee_sdk-6u2-b43-jdk-linux.sh
  • Insert the Glassfish Server location in the build.properties file under <GF_Dir>/samples/bp-project/build.properties (in my case, I set javaee.home=/Users/sqe/glassfish3/glassfish)
  • Start the server (asadmin start-domain)
  • Go to the singleton-ejb Web Services sample location (/Users/sqe/glassfish3/glassfish/samples/javaee6/webservices/hello-singleton-ejb)
  • Execute "ant all"
    The deployment failure is seen.

The same issue is seen on the other 2 WebServices samples - hello-jaxws2.2 and hello-webserviceref



 Comments   
Comment by Chris Kasso [ 17/Feb/11 ]

Alex, in the description you say: "Nor the failures are seen with the latest jdk (JDK1.6.0_24)".

Is this saying the failure is not seen with _24?

Have you tried these on other platforms?

Comment by Alex Pineda [ 17/Feb/11 ]

I can make the system available for debugging if required. Just contact me and I will provide the username/password on the machine.

And just to clarify. On build41 the samples work with JDK1.6.0_23 or JDK1.6.0_24.

Comment by Alex Pineda [ 17/Feb/11 ]

Have not tried on other platforms yet. I will do so later today (Win7 and OEL5).

Comment by scatari [ 17/Feb/11 ]

Alex,
Can u please try the following on the same machine?

-Install B41(SDK with JDK) on a different directory.

-Make B43 GlassFish binaries to point to B41's jdk by editing asenv.conf and setting JAVA_HOME and PATH.

-Run the tests on B43 binaries to see if you can reproduce. If you can, then this can be isolated to a potential issue in the new JDK drop.

Comment by Alex Pineda [ 17/Feb/11 ]

Scatari,

I did a similar experiment.
o I installed B41 SDK. I edited the asenv.conf file to point to B43's JDK and the sample deployed correctly.
o Also, I pointed B43 to my local (not B41's) JDK which is JDK1.6.0_23 and it failed to deploy.

Comment by Hong Zhang [ 17/Feb/11 ]

I am not sure why the cast exception will happen, Bhakti might have better idea. But the stack trace attached would only be triggered when the -Dwriteout.xml=true debug option is turned on (to write out generated deployment descriptor).
And when VNC into the test machine, I did see the problematic installation (/home/sqe/Workspace/glassfish3) has this jvm option.
<jvm-options>-Dwriteout.xml=true</jvm-options>
in the domain.xml.
And the installation that worked (/home/sqe/SDK/glassfish3) did not have this jvm-option set in the domain.xml.
This could possibly explain why one had problem and the other not. Please use the default setting (with no debug jvm-option) to run the test again to see if it makes a difference.
We should also try to figure out why we would have the stack trace when the debug option is turned on. But that's a less serious issue.

Comment by Alex Pineda [ 17/Feb/11 ]

Hong,

I will try your suggestion and comment out the jvm option in domain.xml and report back.

Comment by ramapulavarthi [ 18/Feb/11 ]

I reproduced the issue and its a bug in writing out the Web Services runtime descriptor when writeout.xml system property is set.
Attaching a patch for this issue.

Comment by ramapulavarthi [ 18/Feb/11 ]

Patch for the issue.

Comment by Alex Pineda [ 18/Feb/11 ]

Hong,

I commented out "<jvm-options>-Dwriteout.xml=true</jvm-options>" in domain.xml, and the sample deployed properly on the system. Thanks for the investigative work.

Comment by Hong Zhang [ 18/Feb/11 ]

Great, thanks Alex. So that mystery is now solved. We now just need to decide whether Rama's fix should make in 3.1 or not (it probably would not as the error just happen when the debug option is turned on).

Comment by Alex Pineda [ 18/Feb/11 ]

Thanks for clarifying about the fix. Be aware that I did not explicitly add this option to domain.xml. I installed the same on both installations. I'm going to try to figure out how his happened in my testing. I'll wait to hear about the fix.

Comment by Alex Pineda [ 18/Feb/11 ]

Removing the Regression label and tag as the test case does not insert a Debug option. In other words, this is not a regression as the test has not been, to my knowledge, been executed with a jvm debug option. It's still an issue, but not a regression.

Comment by ramapulavarthi [ 18/Feb/11 ]

I would like to understand if the test execution has enabled this debug option explicitly or the domain was created with this option by default. If it is the later, then we have an issue.

Comment by Alex Pineda [ 18/Feb/11 ]

I don't believe the Installer domain creation is inserting this option as evidenced by the fact that the new installation, provided as reference, does not show the debug option in domain.xml. The test case that I execute, does not insert this option either. My guess is that a previous test that I executed, did the insertion. I plan to investigate this further. In short, the installer does not insert this option by default. That is my conclusion at this point.

Comment by Snjezana Sevo-Zenzerovic [ 18/Feb/11 ]

Correct - 'asadmin create-domain' does not create the domain with this option out of the box and this is true for all distributions. This had to be the artifact of the BAT test run.

Comment by Chris Kasso [ 18/Feb/11 ]

Based on the information we have this is not a stopper. Excluding it from 3.1.

Comment by ramapulavarthi [ 18/Feb/11 ]

Committed a fix to the trunk.

Log Message:
------------
GLASSFISH-16035: WLWebServicesDeploymentDescriptorFile expects only WebServicesDescriptor in the constructor.

Revisions:
----------
45182

Modified Paths:
---------------
trunk/v3/deployment/dol/src/main/java/com/sun/enterprise/deployment/archivist/Archivist.java

Comment by ramapulavarthi [ 19/May/11 ]

Fixed in v3.1.1 as rev:45182





[GLASSFISH-16300] Resync not working for library files for specific cluster instance Created: 01/Apr/11  Updated: 05/May/11  Resolved: 04/Apr/11

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

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

Linux/debian


Issue Links:
Duplicate
is duplicated by GLASSFISH-16559 Manual per-node intervention required... Resolved

 Description   

I'm establishing two clusters on two nodes with 2 instances each. One cluster is for production use, the other is for deployment of new release versions so I can change software versions without loss of availability. I don't need session persistence so session replication to the new cluster is not necessary. Environment: Linux/GF 3.1 b43

However, I've got a problem with synchronization between the DAS and the instances. Because the two clusters are running in the same domain, I use different configurations, one for each cluster. Now, the High Availability Administration Guide (HAAG) tells me, to put all cluster specific libraries in <domain-dir>/config/<config-name>/lib directory. Again, the HAAG tells me to trigger a resync on instance restart by 'touch'-ing a top-level file in the directory mentioned above. After restarting the instance(s) the timestamp on the library directory in the config/<config-name> directory changed, but the contents of the directory is not synced.

After trying for half a day I did an export-sync-bundle call and looked into the generated sync-zip-file. What I saw was, that the library directory appears in the file, but - again - the contents of the directory does not appear in the zip-file. I've already double checked the locations and existence of the file in the DAS. It's all there.

According to tmueller: In the ServerSynchronizer.synchronizeConfigSpecificDir method, the call to getFileName passes in SyncLevel.DIRECTORY rather than SyncLevel.RECURSIVE, which means that only the files at the top level of the config specific directory are synchronized rather than all files under the directory.

See: http://www.java.net/forum/topic/glassfish/glassfish/resync-not-working-library-files-specific-cluster-instance



 Comments   
Comment by Tom Mueller [ 01/Apr/11 ]

Bill, here is the bug that we were discussing over email.

Comment by Bill Shannon [ 04/Apr/11 ]

Yes, it needed to tell the Payload to replace the entire directory contents
if the config-specific lib directory (for instance) changed.

Comment by Tim Quinn [ 11/Apr/11 ]

I've just checked in partial changes for this to the 3.1.1 branch.

Project: glassfish
Repository: svn
Revision: 46086
Author: tjquinn
Date: 2011-04-11 20:48:59 UTC
Link:

Log Message:
------------
Partial fix for 16300 (already checked into trunk)

Payload handling when a directory file is attached to the payload was not correct. Also fixed an unrelated logging error.

Approval: Jane
Tests: QL

Revisions:
----------
46086

Modified Paths:
---------------
branches/3.1.1/common/common-util/src/main/java/org/glassfish/admin/payload/LocalStrings.properties
branches/3.1.1/common/common-util/src/main/java/org/glassfish/admin/payload/PayloadFilesManager.java
branches/3.1.1/admin/cli/src/main/java/com/sun/enterprise/admin/cli/AsadminMain.java
branches/3.1.1/common/common-util/src/main/java/org/glassfish/admin/payload/PayloadImpl.java

Added Paths:
------------
branches/3.1.1/common/common-util/src/test/java/org/glassfish/admin/payload/PayloadImplTest.java





[GLASSFISH-11274] Provide better user experience to customize Eclipselink loggers Created: 07/Dec/09  Updated: 03/May/11  Resolved: 10/Apr/11

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

Type: Improvement Priority: Major
Reporter: Mitesh Meswani Assignee: naman_mehta
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 11,274
Tags: 3_1-next

 Description   

Adding property org.eclipse.persistence.session.level=INFO to logging.properties
will allow a user to control EclipseLink loggers using GUI and hence a better
user experience.



 Comments   
Comment by Gail Risdal [ 08/Dec/09 ]

Added to v3 Release Notes.

Comment by jthoennes [ 28/Mar/11 ]

Please correct this for Glassfish 3.2.

Comment by naman_mehta [ 28/Mar/11 ]

Committed revision 45761.

Comment by jthoennes [ 29/Mar/11 ]

Great, many thanks.





[GLASSFISH-16499] Virtual Server not working Created: 29/Apr/11  Updated: 03/May/11  Resolved: 03/May/11

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

Type: Bug Priority: Blocker
Reporter: bjornstenfeldt Assignee: Shing Wai Chan
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7 pro & Windows 2008. Both 64-bit.


Tags: server, virtual

 Description   

We're trying to deploy a few EAR projects on GF3.1 and need to use virtual servers. Our setup works in GF3.0, which we're forced to use instead. It's rather troublesome though, as NetBeans 7 is bundled with GF3.1 and we need to install 3.0 to use it. Furthermore, when we use GF3.0, we must replace the JSF version every time we install it, due to a bug with PhaseListeners and virtual machines in GF3.0.

Here's what we do:

1) Install our project, tracker-ear.ear.
2) Create a new virtual server called tracker.
3) Set the default web module on our virtual server to tracker-ear#tracker-web.war.
4) Test if it's working. It's not. HTTP-error 500.
5) Restart GF.
6) Test if it's working. It's not. HTTP-error 500.
7) Look in the log file. It contains the following exception.

[#|2011-04-29T09:39:27.193+0200|SEVERE|glassfish3.1|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=83;_ThreadName=Thread-1;|WEB0149: Unable to set default-web-module [/tracker-web] for virtual server [tracker]
org.apache.catalina.LifecycleException: java.lang.Exception: No context matching /tracker-web deployed on virtual server tracker
at com.sun.enterprise.web.WebContainer.updateDefaultWebModule(WebContainer.java:2034)
at com.sun.enterprise.web.WebContainer.loadDefaultWebModulesAfterAllAppsProcessed(WebContainer.java:1451)
at com.sun.enterprise.web.WebContainer.event(WebContainer.java:599)
at org.glassfish.kernel.event.EventsImpl$1.run(EventsImpl.java:120)
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.Exception: No context matching /tracker-web deployed on virtual server tracker
at com.sun.grizzly.util.http.mapper.Mapper.addDefaultContext(Mapper.java:795)
at com.sun.grizzly.util.http.mapper.Mapper.setDefaultContextPath(Mapper.java:759)
at com.sun.enterprise.web.WebContainer.updateDefaultWebModule(WebContainer.java:2026)
... 9 more

#]


 Comments   
Comment by Shing Wai Chan [ 29/Apr/11 ]

According to the above log message, the corresponding web app is not deployed to the virtual server 'tracker'.
One has to associate the application to the virtual server 'tracker' before setting the default-web-module of the virtual server.
This can be achieved through Admin Console: Applications > tracker-ear > Virtual Servers

Note that one has to set the http-listeners in a given virtual servers.
Now, you can set the default web module of the given virtual server.
If we do this, then there is no need to restart the server.

I have verified that it is working fine.

Comment by bjornstenfeldt [ 02/May/11 ]

Ok, it seems to be working now, but not quite as easy as you describe it. Here is what we did:

1) Deploy tracker-ear.ear.
2) Create a new virtual server called tracker on http-listener-1. (No default-web-module)
3) Update Applications > tracker-ear > Virtual Servers and select tracker. This fails and tracker isn't selected. Furthermore, tracker-ear is now disabled.
4) Edit domain.xml and force tracker-ear to use tracker virtual server.
5) Restart GF.
6) Enable tracker-ear. It will throw an exception, but is still enabled. See the exception below.
7) Select a default-web-module for tracker virtual server.
8) Test it. It works.

[#|2011-05-02T09:23:41.377+0200|INFO|glassfish3.1|javax.enterprise.resource.webcontainer.jsf.config|_ThreadID=40;_ThreadName=Thread-1;|Initializing Mojarra 2.1.0 (FCS 2.1.0-b11) for context '/tracker-web'|#]

[#|2011-05-02T09:23:42.424+0200|INFO|glassfish3.1|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=130;_ThreadName=Thread-1;|WEB0671: Loading application tracker-ear#tracker-web.war at [tracker-web]|#]

[#|2011-05-02T09:23:42.429+0200|INFO|glassfish3.1|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=185;_ThreadName=Thread-1;|CORE10010: Loading application tracker-ear done in 0 ms|#]

[#|2011-05-02T09:23:42.535+0200|INFO|glassfish3.1|org.glassfish.admingui|_ThreadID=40;_ThreadName=Thread-1;|Exception in prepareAlert():null|#]

[#|2011-05-02T09:23:42.540+0200|WARNING|glassfish3.1|javax.enterprise.resource.webcontainer.jsf.lifecycle|_ThreadID=40;_ThreadName=Thread-1;|java.lang.reflect.InvocationTargetException while attempting to process a 'command' event for 'button2'.
java.lang.RuntimeException: java.lang.reflect.InvocationTargetException while attempting to process a 'command' event for 'button2'.
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:422)
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:394)
at com.sun.jsftemplating.layout.event.CommandActionListener.invokeCommandHandlers(CommandActionListener.java:150)
at com.sun.jsftemplating.layout.event.CommandActionListener.processAction(CommandActionListener.java:98)
at javax.faces.event.ActionEvent.processListener(ActionEvent.java:88)
at javax.faces.component.UIComponentBase.broadcast(UIComponentBase.java:769)
at javax.faces.component.UICommand.broadcast(UICommand.java:300)
at com.sun.webui.jsf.component.WebuiCommand.broadcast(WebuiCommand.java:166)
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:409)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1534)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:343)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:215)
at com.sun.webui.jsf.util.UploadFilter.doFilter(UploadFilter.java:233)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:215)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:279)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655)
at org.apache.catalina.core.StandardPipeline.doChainInvoke(StandardPipeline.java:600)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:96)
at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:91)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:162)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:326)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:227)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:228)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:822)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:719)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1013)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:662)
Caused by: 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.jsftemplating.layout.descriptors.handler.Handler.invoke(Handler.java:442)
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:420)
... 43 more
Caused by: java.lang.NullPointerException
at com.sun.jsftemplating.layout.LayoutViewHandler.getResourcePath(LayoutViewHandler.java:425)
at com.sun.jsftemplating.layout.LayoutViewHandler.createView(LayoutViewHandler.java:137)
at com.sun.jsftemplating.handlers.NavigationHandlers.navigate(NavigationHandlers.java:162)
at org.glassfish.admingui.common.handlers.CommonHandlers.navigate(CommonHandlers.java:577)
... 49 more

#]

[#|2011-05-02T09:23:42.547+0200|SEVERE|glassfish3.1|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=130;_ThreadName=Thread-1;|javax.faces.FacesException: java.lang.reflect.InvocationTargetException while attempting to process a 'command' event for 'button2'.
at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:89)
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:409)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1534)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:343)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:215)
at com.sun.webui.jsf.util.UploadFilter.doFilter(UploadFilter.java:233)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:215)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:279)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655)
at org.apache.catalina.core.StandardPipeline.doChainInvoke(StandardPipeline.java:600)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:96)
at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:91)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:162)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:326)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:227)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:228)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:822)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:719)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1013)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:662)
Caused by: java.lang.RuntimeException: java.lang.reflect.InvocationTargetException while attempting to process a 'command' event for 'button2'.
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:422)
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:394)
at com.sun.jsftemplating.layout.event.CommandActionListener.invokeCommandHandlers(CommandActionListener.java:150)
at com.sun.jsftemplating.layout.event.CommandActionListener.processAction(CommandActionListener.java:98)
at javax.faces.event.ActionEvent.processListener(ActionEvent.java:88)
at javax.faces.component.UIComponentBase.broadcast(UIComponentBase.java:769)
at javax.faces.component.UICommand.broadcast(UICommand.java:300)
at com.sun.webui.jsf.component.WebuiCommand.broadcast(WebuiCommand.java:166)
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)
... 33 more
Caused by: 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.jsftemplating.layout.descriptors.handler.Handler.invoke(Handler.java:442)
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:420)
... 43 more
Caused by: java.lang.NullPointerException
at com.sun.jsftemplating.layout.LayoutViewHandler.getResourcePath(LayoutViewHandler.java:425)
at com.sun.jsftemplating.layout.LayoutViewHandler.createView(LayoutViewHandler.java:137)
at com.sun.jsftemplating.handlers.NavigationHandlers.navigate(NavigationHandlers.java:162)
at org.glassfish.admingui.common.handlers.CommonHandlers.navigate(CommonHandlers.java:577)
... 49 more

#]
Comment by Anissa Lam [ 02/May/11 ]

Looking at Step #3 and Step #4

>> 3) Update Applications > tracker-ear > Virtual Servers and select tracker. This fails and tracker isn't selected. Furthermore, tracker-ear is now disabled.
>> 4) Edit domain.xml and force tracker-ear to use tracker virtual server.

You are hitting GLASSFISH-16048.
You need to use CLI to set the virtual server, and if you do a SAVE on that screen, ensure that the enabled checkbox is checked.

Comment by Shing Wai Chan [ 02/May/11 ]

Can you try 3.1.1 promoted build to see whether the jsftemplating exception is resolved?

Comment by Shing Wai Chan [ 02/May/11 ]

One more remark, both virtual servers `tracker' and `server' has http-listener-1. We should not do this.

Comment by bjornstenfeldt [ 03/May/11 ]

Thanks, I'll see if we can find time to do a 3.1.1 deployment, but we really need to get moving with our projects. I think this work-around can get us by until next GF is release.

Comment by Shing Wai Chan [ 03/May/11 ]

Duplicate of http://java.net/jira/browse/GLASSFISH-16048





[GLASSFISH-16015] My JAX-RPC client app needs to be redeployed every time I restart GlassFish V3.1 Created: 16/Feb/11  Updated: 27/Apr/11  Resolved: 01/Mar/11

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

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

GlassFish 3.1 b43 on Windows XP


Attachments: Java Archive File deployment-javaee-core.jar    
Tags: 3_1_1-approved

 Description   

When I deploy a JAX-RPC client .war file to GlassFish I am able to use the application. When I restart GlassFish, I get the following exception when trying to use the JAX-RPC client. The only way I can resolve it is to undeploy then deploy the application, then restart GlassFish. If I don't restart GlassFish after redeploying then I still get the error. When I try using the "redeploy" feature in GlassFish, I seem to still have the problem.

[#|2011-02-16T17:33:44.378-0500|WARNING|glassfish3.1|javax.enterprise.webservices.org.glassfish.webservices|_ThreadID=93;_ThreadName=Thread-1;|
javax.xml.ws.WebServiceException: null is not a valid service
at com.sun.xml.ws.client.WSServiceDelegate.<init>(WSServiceDelegate.java:198)
at com.sun.xml.ws.client.WSServiceDelegate.<init>(WSServiceDelegate.java:186)
at com.sun.xml.ws.spi.ProviderImpl.createServiceDelegate(ProviderImpl.java:111)
at javax.xml.ws.Service.<init>(Service.java:92)
at javax.xml.ws.Service.create(Service.java:722)
at org.glassfish.webservices.WebServiceReferenceManagerImpl.resolveWSReference(WebServiceReferenceManagerImpl.java:193)
at com.sun.enterprise.container.common.impl.ComponentEnvManagerImpl$WebServiceRefProxy.create(ComponentEnvManagerImpl.java:1036)
at com.sun.enterprise.naming.impl.GlassfishNamingManagerImpl.lookup(GlassfishNamingManagerImpl.java:772)
at com.sun.enterprise.naming.impl.GlassfishNamingManagerImpl.lookup(GlassfishNamingManagerImpl.java:740)
at com.sun.enterprise.naming.impl.JavaURLContext.lookup(JavaURLContext.java:172)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:498)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(InitialContext.java:392)
at javax.naming.InitialContext.lookup(InitialContext.java:392)
at com.ijws.folioservice.client.demo.DisplayFolioServlet.getFolioService(DisplayFolioServlet.java:202)
at com.ijws.folioservice.client.demo.DisplayFolioServlet.getFolioServiceSEIPort(DisplayFolioServlet.java:223)
at com.ijws.folioservice.client.demo.DisplayFolioServlet.searchFolios(DisplayFolioServlet.java:145)
at com.ijws.folioservice.client.demo.DisplayFolioServlet.processRequest(DisplayFolioServlet.java:62)
at com.ijws.folioservice.client.demo.DisplayFolioServlet.doGet(DisplayFolioServlet.java:184)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:735)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:848)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1534)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:281)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:595)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:98)
at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:91)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:162)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:326)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:227)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:170)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:822)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:719)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1013)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:662)

#]

This is the line that causes the problem:

folioService = (com.ijws.folioservice.client.FolioService) ic.lookup("java:comp/env/service/FolioService");

This program is a few years old. It works on GlassFish 2.1.1, 3.0.1. The first time I noticed this problem is with GlassFish 3.1.



 Comments   
Comment by Bhakti Mehta [ 16/Feb/11 ]

I have reproduced this issue locally and working to identify the cause. However it is too risky to fix this late in the release cycle so have excluded it for 3.1. Will attach a patch to this issue soon

Comment by Bhakti Mehta [ 16/Feb/11 ]

Just to give more update. I tried with my local workspace and see the following . If I deploy the client and endpoint and restart glassfish I see this error when accessing the client.
However if I try either of the following
case 1 undeploy and deploy the client app or
case 2 just redeploy client app I do not need to restart gf it works fine for me in both these cases and I can access the client application.

Comment by rdelaplante [ 16/Feb/11 ]

Great job finding and fixing it so quickly. Isn't the purpose of these release candidates to fix bugs for the final release? This seems pretty critical to me (having to redeploy each time I restart GlassFish)

Comment by Bhakti Mehta [ 16/Feb/11 ]

Sorry I do not have the patch as yet I am still working on identifying the cause

Comment by rdelaplante [ 17/Feb/11 ]

Just making some noise about the 3_1-exclude tag in hopes to change your mind... This is a regression, and unless fixed then we cannot use GlassFish 3.1 in production. Having to re-deploy every time the server is restarted is too risky.

If you fixed it the day after 3.1 goes final, would I have to wait 3 - 6 months for GlassFish 3.1.1 to be released so I can get the patch?

Comment by Bhakti Mehta [ 17/Feb/11 ]

Here is a jar file with the fix. This works for me please can you try that.
Here is the patch
Index: src/main/java/org/glassfish/javaee/core/deployment/JavaEEDeployer.java
===================================================================
— src/main/java/org/glassfish/javaee/core/deployment/JavaEEDeployer.java (revision 45171)
+++ src/main/java/org/glassfish/javaee/core/deployment/JavaEEDeployer.java (working copy)
@@ -198,8 +198,6 @@
try {
prepareScratchDirs(dc);

  • if (! dc.getCommandParameters(OpsParams.class).origin.isArtifactsPresent()) { - // only generate artifacts when there is no artifacts present //In jaxrpc it was required to run //Wscompile to generate the artifacts for clients too. @@ -211,7 +209,9 @@ jaxrpcCodeGenFacade.run(habitat,dc,getModuleClassPath(dc), true) ; }

    }

  • generateArtifacts(dc);
    + if (! dc.getCommandParameters(OpsParams.class).origin.isArtifactsPresent()) { + // only generate artifacts when there is no artifacts present + generateArtifacts(dc); }

    return true;
    } catch (Exception ex) {

Comment by rdelaplante [ 18/Feb/11 ]

Thank you, it works!

Pre-tests:
==========

1) Started from a state where JAX-RPC client did not work.

2) From GlassFish web admin console I "reloaded" or "restarted" the application, then tested again. It still did not work.

3) I re-deployed the application from GlassFish web admin console, and the application worked again.

4) I restarted GlassFish, and the application stopped working.

Testing the patch:
==================

1) Shut down GlassFish 3.1-b42

2) Replace deployment-javaee-core.jar in \glassfish\modules\

3) Started GlassFish

4) Tried the application again, and it works!

5) Restarted GlassFish and tried again. It still works!

Comment by Bhakti Mehta [ 01/Mar/11 ]

Fixed svn rev 45200. Added the 3_1-next tag so this can be considered for the next patch,update or dot dot release

Comment by Bhakti Mehta [ 27/Apr/11 ]

Also committed to 3.1.1 branch 46172





[GLASSFISH-16327] com.sun.aas.instanceName in log configuration not used initially Created: 07/Apr/11  Updated: 17/Apr/11  Resolved: 17/Apr/11

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

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

Glassfish 3.1, Tested on Windows XP, Redhat 5.6



 Description   

I'm using Glassfish 3.1 and was attempting to set the log file to a common location for my server instances by using the "/logs/$

{com.sun.aas.instanceName}/${com.sun.aas.instanceName}

.log" set on the logging configuration page or "com.sun.enterprise.server.logging.GFFileHandler.file" setting with asadmin for the server-config

This results in the first set of log statements are being written to a file literally called "/logs/$

{com.sun.aas.instanceName}/${com.sun.aas.instanceName}

.log". After the start-up args are logged the logs start flowing to "/logs/server/server.log" as expected.



 Comments   
Comment by naman_mehta [ 17/Apr/11 ]

Made required changes and closed the same.

Comment by naman_mehta [ 17/Apr/11 ]

Re-Open to changed fixed version...





[GLASSFISH-13129] Session is null in request with URL containing jsessionid parameter Created: 26/Aug/10  Updated: 15/Apr/11  Resolved: 24/Mar/11

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

Type: Bug Priority: Blocker
Reporter: bht Assignee: oleksiys
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Zip Archive PanelReplacementMavenGlassFish.zip     Zip Archive PanelReplacementNetBeans.zip    
Issuezilla Id: 13,129
Tags: 3_1_1-approved

 Description   

If cookie support is disabled in the browser, then with the attached testcase,
GlassFish does not return a session as expected.

My apologies for not writing a more basic testcase.

The failure manifests itself in a Wicket framework message "Page Expired" when
clicking on the link "Go to Panel 2".

When debugging the testcase, check WicketFilter.doGet(..) and WicketFilter line
425 calling AbstractHttpSessionStore.getSessionId(...).
AbstractHttpSessionStore.getSessionId(...) returns a null session directly from
a request
that has a URL containing the jsessionid parameter.

The testcase runs normally with the Tomcat and Jetty servlet containers.



 Comments   
Comment by bht [ 26/Aug/10 ]

Created an attachment (id=4741)
Maven project in zip file

Comment by bht [ 26/Aug/10 ]

Created an attachment (id=4742)
NetBeans project for Wicket 1.4.10 (not included)

Comment by acraphae [ 26/Aug/10 ]
      • Issue 13129 has been confirmed by votes. ***
Comment by Shing Wai Chan [ 31/Aug/10 ]

At least two issues are identified. We are working on the fix.

Comment by oleksiys [ 01/Sep/10 ]

one part has to be fixed by this:

Date: 2010-09-01 14:31:41+0000
New Revision: 40359

Modified:
trunk/v3/core/kernel/src/main/java/com/sun/enterprise/v3/services/impl/ContainerMapper.java
trunk/v3/core/kernel/src/main/java/com/sun/enterprise/v3/services/impl/SnifferAdapter.java

Log:
partial fix for the issue #13129
"Session is null in request with URL containing jsessionid parameter"
https://glassfish.dev.java.net/issues/show_bug.cgi?id=13129

Do not cut the URI part followed by semicolon

Comment by Shing Wai Chan [ 02/Sep/10 ]

I have verified that Oleksiys' fix resolves the issue.

Comment by Shing Wai Chan [ 02/Sep/10 ]

The fix will be in 3.1 build 19.

Comment by oleksiys [ 24/Mar/11 ]

we were able to reproduce the issue.
it's reproducible, when URI looks like
http://localhost:8080/a/;jsessionid=.....

in this case Glassfish/Grizzly Mapper tries to find correct welcome resource for this URI, it tries
http://localhost:8080/a/index.html,
http://localhost:8080/a/index.htm,
http://localhost:8080/a/index.jsp
...
when attempting different options it removes the jsessionid information, so it gets corrupted.

The easiest workaround is to provide specific resource (welcome file) in the original request, like
http://localhost:8080/a/index.jsp;jsessionid=.....

in this case it should work.

Anyways we work on the fix.

Comment by oleksiys [ 24/Mar/11 ]

reassigning to Shing Wai, who's currently working on webcontainer side patch for this issue.

Comment by Shing Wai Chan [ 24/Mar/11 ]

I have put a fix in CoyoteAdapter.java

Sending web-core/src/main/java/org/apache/catalina/connector/CoyoteAdapter.java
Transmitting file data .
Committed revision 45709.

Similar fix need to be applied to ContainerMapper.java.
Assign to Olesksiys to fix that.

Comment by oleksiys [ 24/Mar/11 ]

ContainerMapper is fixed

Project: glassfish
Repository: svn
Revision: 45722
Date: 2011-03-25 01:57:21 UTC

Comment by oleksiys [ 24/Mar/11 ]

fixed on GF trunk.





[GLASSFISH-15573] Load Balancer configurator in console mode not working properly Created: 14/Jan/11  Updated: 15/Apr/11  Resolved: 03/Mar/11

Status: Resolved
Project: glassfish
Component/s: load_balancer
Affects Version/s: 3.1_b36
Fix Version/s: 3.1.1_b01

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

SuSe Enterprise Linux 11 with Oracle Glassfish build 37


Tags: 3_1, 3_1-exclude, glasfish-3, glassfish

 Description   

Download glassfish-lbconfigurator-3_1-b04.jar and test using console mode on iPlanet WebServer 7.0.9, and it is not working properly at all.

Issue:
1) LBConfigurator does not have clear steps and wordings to guide user to use console mode.
2) LBConfigurator b04 could not determine which type of webserver during installation.
3) New more Usabilty design.

Try two scenario.

[aroot@liz-vm14:/export/ha/downloads] $ java -jar glassfish-lbconfigurator-3_1-b04.jar -console
Configuration information
------------------------------------------

This is a description for radio buttons
0 [x] the first choice
1 [ ] the second choice
input selection:

press 1 to continue, 2 to quit, 3 to redisplay
1
dir field collection not implemented
Configuration information
------------------------------------------

[ ] Oracle iPlanet Web Server 7.x
input 1 to select, 0 to deseclect:
1

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

DAS Certificate File: []

------------------------------------------
Note: * indicates mandatory field.
press 1 to continue, 2 to quit, 3 to redisplay
1
[ Starting to unpack ]
[ Processing package: Base (1/1) ]
[ ERROR: Could not create directory
$

{ws_install_dir}

/../glassfish-lbplugin/lib/webserver-plugin/linux/apache2.2 ]
[ Unpacking finished ]
[aroot@liz-vm14:/export/ha/downloads] $

>
> [aroot@liz-vm14:/export/ha/downloads] $ java -jar glassfish-lbconfigurator-3_1-b04.jar -console
> Configuration information
> ------------------------------------------
>
> This is a description for radio buttons
> 0 [x] the first choice
> 1 [ ] the second choice
> input selection:
> 1
>
> press 1 to continue, 2 to quit, 3 to redisplay
> 1
> dir field collection not implemented
> Configuration information
> ------------------------------------------
>
>
> ------------------------------------------
>
> DAS Certificate File: []
>
>
> ------------------------------------------
> Note: * indicates mandatory field.
> press 1 to continue, 2 to quit, 3 to redisplay
> 1
> [ Starting to unpack ]
> [ Processing package: Base (1/1) ]
> [ Unpacking finished ]
> Install was successeful
> application installed on /usr/local/LBPlugin
> [ Console installation done ]
> [aroot@liz-vm14:/export/ha/downloads] $



 Comments   
Comment by Nazrul [ 14/Jan/11 ]

Are we supporting the CLI? If do not support CLI, please use 3_1-exclude tag to exclude this issue from 3.1.

Comment by Homer Yau [ 03/Feb/11 ]

We need to add to the release note for 3.1.
We could take it out if 3.1 fix this issue.

Comment by Scott Fordin [ 03/Mar/11 ]

LB Configurator 3.1 docs thoroughly reworked and vetted.





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

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

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

Tags: 3_1-exclude, 3_1-release-note-added, 3_1-release-notes

 Description   

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

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



 Comments   
Comment by marina vatkina [ 15/Feb/11 ]

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

Fixing the files won't affect the execution.

Comment by marina vatkina [ 15/Feb/11 ]

Fixed on trunk with rev 45149

Comment by Scott Fordin [ 04/Mar/11 ]

Need more information to add to notes.

Comment by Scott Fordin [ 04/Mar/11 ]

Added issue to 3.1 Release Notes.

Comment by Scott Fordin [ 24/Mar/11 ]

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





[GLASSFISH-14756] wss/ejbclient test failed in cluster with javax.xml.ws.WebserviceException Created: 17/Nov/10  Updated: 13/Apr/11  Resolved: 13/Apr/11

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

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

Operating System: All
Platform: All


Attachments: Text File 14756.log     Text File server.log     Text File server.log     Text File server.log.ejbclient    
Issue Links:
Duplicate
duplicates GLASSFISH-15242 Fix the webservices scripts since mai... Resolved
Issuezilla Id: 14,756
Status Whiteboard:

There are 6 test cases failed due to this bug.

Tags: 3_1-exclude, 3_1-regression

 Description   

OS: solaris10
build: promoted build 30

The wss/ejbclient test is ported from V2.x and it passed for V2.x cluster mode
and also passed for V3.1 DAS mode. It only failed in cluster mode against V3.1

Steps to reproduce the bug:
1.Checkout SQE workspace:
cvs co appserver-sqe/bootstrap.xml
(CVSROOT=:pserver:cvsguest@sunsw.sfbay.sun.com:/m/jws)
cd appserver-sqe
ant -f bootstrap.xml co-security
2. install GF V3.1, DO NOT start domain1
3. Setup env. variables
S1AS_HOME <GF installation dir> (example: /export/sonia/v3/glassfish3/glassfish
SPS_HOME <workspace dir> (example: /export/sonia/appserver-sqe)
ANT_HOME <ant dir>
JAVA_HOME <java dir> (I use jdk1.6.0_18)
4. cd appserver-sqe/, run "ant setup-cluster-profile" (this target will create a
cluster sqe-cluster and two instances)
5. cd appserver-sqe/pe/security/wss, run
ant ee setup enable-wss-log restart (Please don't forget the "ee" target)
6. cd appserver-sqe/pe/security/wss/ejbws, run "ant ee build-deploy-run"
7. cd appserver-sqe/pe/security/wss/ejbclient, run "ant ee all"
The test failed and the following exceptions displayed in the cluster server log:
[#|2010-11-17T12:34:15.412-0800|INFO|glassfish3.1|javax.enterprise.system.tools.admin.org.glassfish.deployment.admin|_ThreadID=16;_ThreadName=Thread-1;|wss-ejbws-ejbcApp
was successfully deployed in 24,435 milliseconds.|#]

[#|2010-11-17T12:35:15.556-0800|INFO|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|In
ClientBean::ejbCreate !!|#]

[#|2010-11-17T12:35:16.422-0800|WARNING|glassfish3.1|javax.enterprise.webservices.org.glassfish.webservices|_ThreadID=16;_ThreadName=Thread-1;|
javax.xml.ws.WebServiceException: null is not a valid service
at com.sun.xml.ws.client.WSServiceDelegate.<init>(WSServiceDelegate.java:198)
at com.sun.xml.ws.client.WSServiceDelegate.<init>(WSServiceDelegate.java:186)
at com.sun.xml.ws.spi.ProviderImpl.createServiceDelegate(ProviderImpl.java:111)
at javax.xml.ws.Service.<init>(Service.java:57)
at javax.xml.ws.Service.create(Service.java:687)
at
org.glassfish.webservices.WebServiceReferenceManagerImpl.resolveWSReference(WebServiceReferenceManagerImpl.java:193)
at
com.sun.enterprise.container.common.impl.ComponentEnvManagerImpl$WebServiceRefProxy.create(ComponentEnvManagerImpl.java:986)
at
com.sun.enterprise.naming.impl.GlassfishNamingManagerImpl.lookup(GlassfishNamingManagerImpl.java:771)
at
com.sun.enterprise.naming.impl.GlassfishNamingManagerImpl.lookup(GlassfishNamingManagerImpl.java:740)
at com.sun.enterprise.naming.impl.JavaURLContext.lookup(JavaURLContext.java:166)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:538)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:491)
at javax.naming.InitialContext.lookup(InitialContext.java:392)
at javax.naming.InitialContext.lookup(InitialContext.java:392)
at
com.sun.appserv.sqe.security.wss.ejbws.taxcal.ejbclient.ClientBean.callFedTaxService(ClientBean.java:48)
at
com.sun.appserv.sqe.security.wss.ejbws.taxcal.ejbclient.ClientBean.getFedTax(ClientBean.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
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:5367)
at com.sun.ejb.EjbInvocation.invokeBeanMethod(EjbInvocation.java:619)
at
com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:801)
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:862)
at
com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:801)
at
com.sun.ejb.containers.interceptors.InterceptorManager.intercept(InterceptorManager.java:371)
at com.sun.ejb.containers.BaseContainer.__intercept(BaseContainer.java:5339)
at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:5327)
at
com.sun.ejb.containers.EJBObjectInvocationHandler.invoke(EJBObjectInvocationHandler.java:206)
at
com.sun.ejb.containers.EJBObjectInvocationHandler.invoke(EJBObjectInvocationHandler.java:123)
at $Proxy183.getFedTax(Unknown Source)
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.presentation.rmi.ReflectiveTie.dispatchToMethod(ReflectiveTie.java:144)
at
com.sun.corba.ee.impl.presentation.rmi.ReflectiveTie._invoke(ReflectiveTie.java:174)
at
com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatchToServant(CorbaServerRequestDispatcherImpl.java:528)
at
com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatch(CorbaServerRequestDispatcherImpl.java:199)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequestRequest(CorbaMessageMediatorImpl.java:1624)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:1486)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleInput(CorbaMessageMediatorImpl.java:990)
at
com.sun.corba.ee.impl.protocol.giopmsgheaders.RequestMessage_1_2.callback(RequestMessage_1_2.java:214)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:742)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.dispatch(CorbaMessageMediatorImpl.java:539)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.doWork(CorbaMessageMediatorImpl.java:2324)
at
com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.performWork(ThreadPoolImpl.java:496)
at
com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:537)

#]

[#|2010-11-17T12:35:16.445-0800|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|javax.naming.NamingException:
Lookup failed for 'java:comp/env/service/TaxCalEjbService' in
SerialContext[targetHost=null,targetPort=null [Root exception is
javax.naming.NamingException [Root exception is
javax.xml.ws.WebServiceException: null is not a valid service]]|#]

[#|2010-11-17T12:35:16.446-0800|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:561)|#]

[#|2010-11-17T12:35:16.446-0800|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:491)|#]

[#|2010-11-17T12:35:16.447-0800|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|
at javax.naming.InitialContext.lookup(InitialContext.java:392)|#]

[#|2010-11-17T12:35:16.447-0800|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|
at javax.naming.InitialContext.lookup(InitialContext.java:392)|#]

[#|2010-11-17T12:35:16.447-0800|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|
at
com.sun.appserv.sqe.security.wss.ejbws.taxcal.ejbclient.ClientBean.callFedTaxService(ClientBean.java:48)|#]

[#|2010-11-17T12:35:16.448-0800|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|
at
com.sun.appserv.sqe.security.wss.ejbws.taxcal.ejbclient.ClientBean.getFedTax(ClientBean.java:32)|#]

[#|2010-11-17T12:35:16.448-0800|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)|#]

[#|2010-11-17T12:35:16.448-0800|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)|#]

[#|2010-11-17T12:35:16.449-0800|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)|#]

[#|2010-11-17T12:35:16.449-0800|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|
at java.lang.reflect.Method.invoke(Method.java:597)|#]

[#|2010-11-17T12:35:16.449-0800|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|
at
org.glassfish.ejb.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1052)|#]

[#|2010-11-17T12:35:16.450-0800|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|
at
org.glassfish.ejb.security.application.EJBSecurityManager.invoke(EJBSecurityManager.java:1124)|#]

[#|2010-11-17T12:35:16.450-0800|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|
at com.sun.ejb.containers.BaseContainer.invokeBeanMethod(BaseContainer.java:5367)|#]

[#|2010-11-17T12:35:16.450-0800|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|
at com.sun.ejb.EjbInvocation.invokeBeanMethod(EjbInvocation.java:619)|#]

[#|2010-11-17T12:35:16.451-0800|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|
at
com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:801)|#]

[#|2010-11-17T12:35:16.451-0800|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|
at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:571)|#]

[#|2010-11-17T12:35:16.451-0800|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|
at
com.sun.ejb.containers.interceptors.SystemInterceptorProxy.doAround(SystemInterceptorProxy.java:162)|#]

[#|2010-11-17T12:35:16.452-0800|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|
at
com.sun.ejb.containers.interceptors.SystemInterceptorProxy.aroundInvoke(SystemInterceptorProxy.java:144)|#]

[#|2010-11-17T12:35:16.452-0800|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)|#]

[#|2010-11-17T12:35:16.453-0800|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)|#]

[#|2010-11-17T12:35:16.453-0800|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)|#]

[#|2010-11-17T12:35:16.454-0800|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|
at java.lang.reflect.Method.invoke(Method.java:597)|#]

[#|2010-11-17T12:35:16.454-0800|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|
at
com.sun.ejb.containers.interceptors.AroundInvokeInterceptor.intercept(InterceptorManager.java:862)|#]

[#|2010-11-17T12:35:16.455-0800|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|
at
com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:801)|#]

[#|2010-11-17T12:35:16.455-0800|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|
at
com.sun.ejb.containers.interceptors.InterceptorManager.intercept(InterceptorManager.java:371)|#]

[#|2010-11-17T12:35:16.456-0800|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|
at com.sun.ejb.containers.BaseContainer.__intercept(BaseContainer.java:5339)|#]

[#|2010-11-17T12:35:16.456-0800|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|
at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:5327)|#]

[#|2010-11-17T12:35:16.457-0800|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|
at
com.sun.ejb.containers.EJBObjectInvocationHandler.invoke(EJBObjectInvocationHandler.java:206)|#]

[#|2010-11-17T12:35:16.457-0800|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|
at
com.sun.ejb.containers.EJBObjectInvocationHandler.invoke(EJBObjectInvocationHandler.java:123)|#]

[#|2010-11-17T12:35:16.458-0800|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|
at $Proxy183.getFedTax(Unknown Source)|#]

[#|2010-11-17T12:35:16.458-0800|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)|#]

[#|2010-11-17T12:35:16.459-0800|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)|#]

[#|2010-11-17T12:35:16.459-0800|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)|#]

[#|2010-11-17T12:35:16.460-0800|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|
at java.lang.reflect.Method.invoke(Method.java:597)|#]

[#|2010-11-17T12:35:16.461-0800|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|
at
com.sun.corba.ee.impl.presentation.rmi.ReflectiveTie.dispatchToMethod(ReflectiveTie.java:144)|#]

[#|2010-11-17T12:35:16.461-0800|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|
at
com.sun.corba.ee.impl.presentation.rmi.ReflectiveTie._invoke(ReflectiveTie.java:174)|#]

[#|2010-11-17T12:35:16.462-0800|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|
at
com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatchToServant(CorbaServerRequestDispatcherImpl.java:528)|#]

[#|2010-11-17T12:35:16.462-0800|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|
at
com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatch(CorbaServerRequestDispatcherImpl.java:199)|#]

[#|2010-11-17T12:35:16.463-0800|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequestRequest(CorbaMessageMediatorImpl.java:1624)|#]

[#|2010-11-17T12:35:16.463-0800|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:1486)|#]

[#|2010-11-17T12:35:16.464-0800|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleInput(CorbaMessageMediatorImpl.java:990)|#]

[#|2010-11-17T12:35:16.464-0800|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|
at
com.sun.corba.ee.impl.protocol.giopmsgheaders.RequestMessage_1_2.callback(RequestMessage_1_2.java:214)|#]

[#|2010-11-17T12:35:16.465-0800|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:742)|#]

[#|2010-11-17T12:35:16.465-0800|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.dispatch(CorbaMessageMediatorImpl.java:539)|#]

[#|2010-11-17T12:35:16.466-0800|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.doWork(CorbaMessageMediatorImpl.java:2324)|#]

[#|2010-11-17T12:35:16.466-0800|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|
at
com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.performWork(ThreadPoolImpl.java:496)|#]

[#|2010-11-17T12:35:16.467-0800|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|
at
com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:537)|#]

[#|2010-11-17T12:35:16.468-0800|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|Caused
by: javax.naming.NamingException [Root exception is
javax.xml.ws.WebServiceException: null is not a valid service]|#]

[#|2010-11-17T12:35:16.468-0800|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|
at
org.glassfish.webservices.WebServiceReferenceManagerImpl.resolveWSReference(WebServiceReferenceManagerImpl.java:275)|#]

[#|2010-11-17T12:35:16.469-0800|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|
at
com.sun.enterprise.container.common.impl.ComponentEnvManagerImpl$WebServiceRefProxy.create(ComponentEnvManagerImpl.java:986)|#]

[#|2010-11-17T12:35:16.469-0800|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|
at
com.sun.enterprise.naming.impl.GlassfishNamingManagerImpl.lookup(GlassfishNamingManagerImpl.java:771)|#]

[#|2010-11-17T12:35:16.470-0800|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|
at
com.sun.enterprise.naming.impl.GlassfishNamingManagerImpl.lookup(GlassfishNamingManagerImpl.java:740)|#]

[#|2010-11-17T12:35:16.470-0800|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|
at com.sun.enterprise.naming.impl.JavaURLContext.lookup(JavaURLContext.java:166)|#]

[#|2010-11-17T12:35:16.471-0800|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:538)|#]

[#|2010-11-17T12:35:16.471-0800|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|
... 46 more|#]

[#|2010-11-17T12:35:16.472-0800|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|Caused
by: javax.xml.ws.WebServiceException: null is not a valid service|#]

[#|2010-11-17T12:35:16.472-0800|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|
at com.sun.xml.ws.client.WSServiceDelegate.<init>(WSServiceDelegate.java:198)|#]

[#|2010-11-17T12:35:16.472-0800|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|
at com.sun.xml.ws.client.WSServiceDelegate.<init>(WSServiceDelegate.java:186)|#]

[#|2010-11-17T12:35:16.473-0800|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|
at com.sun.xml.ws.spi.ProviderImpl.createServiceDelegate(ProviderImpl.java:111)|#]

[#|2010-11-17T12:35:16.473-0800|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|
at javax.xml.ws.Service.<init>(Service.java:57)|#]

[#|2010-11-17T12:35:16.473-0800|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|
at javax.xml.ws.Service.create(Service.java:687)|#]

[#|2010-11-17T12:35:16.474-0800|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|
at
org.glassfish.webservices.WebServiceReferenceManagerImpl.resolveWSReference(WebServiceReferenceManagerImpl.java:193)|#]

[#|2010-11-17T12:35:16.474-0800|SEVERE|glassfish3.1|null|_ThreadID=16;_ThreadName=Thread-1;|
... 51 more|#]

— the server.log is attached to bug.



 Comments   
Comment by sonialiu [ 17/Nov/10 ]

Created an attachment (id=5504)
server.log

Comment by sonialiu [ 17/Nov/10 ]

The wss/webclient test also failed in cluster with the same exception.

Comment by kumarjayanti [ 18/Nov/10 ]

This seems like a JSR-109 issue in cluster mode.

reassigning.

Comment by ramapulavarthi [ 18/Nov/10 ]

Reassigning to Bhakti.

Comment by Bhakti Mehta [ 07/Dec/10 ]

Please can you try with the latest bits tomorrow. I followed all your instructions and set it up with today's workspace.
This is what I see in clustered_instance1 and clustered_instance2's logs. It seems to be working fine. I do not get the error Attaching my server logs for you to check

Comment by Bhakti Mehta [ 07/Dec/10 ]

clustered_instance1 logs

Comment by Bhakti Mehta [ 07/Dec/10 ]

clustered_instance2 logs too. I am unable to reproduce this issue

Comment by Bhakti Mehta [ 08/Dec/10 ]

As I have mentioned in the previous comments I tried yesterday with the setup and cannot reproduce this issue, you can see my attached logs too. Please try with latest builds and reopen if you face any problems.

Comment by sonialiu [ 17/Dec/10 ]

I tried promoted b33 and latest nightly build (12/16) and I still could get this test pass. But at this time, the test failed at this step (step 6):
cd appserver-sqe/pe/security/wss/ejbws
ant ee build-deploy-run

wscompile-gen-client:
[exec] Exception in thread "main" java.lang.NoClassDefFoundError: javax/mail/internet/MimeMultipart
[exec] at com.sun.xml.rpc.encoding.soap.StandardSOAPTypeMappings.<init>(StandardSOAPTypeMappings.java:927)
[exec] at com.sun.xml.rpc.encoding.StandardTypeMappings.getSoap(StandardTypeMappings.java:49)
[exec] at com.sun.xml.rpc.client.BasicService.createSoapMappings(BasicService.java:247)
[exec] at com.sun.xml.rpc.client.BasicService.createStandardTypeMappingRegistry(BasicService.java:219)
[exec] at com.sun.xml.rpc.processor.generator.SerializerRegistryGenerator.writeGetRegistry(SerializerRegistryGenerator.java:485)
[exec] at com.sun.xml.rpc.processor.generator.SerializerRegistryGenerator.generateSerializerRegistry(SerializerRegistryGenerator.java:364)
[exec] at com.sun.xml.rpc.processor.generator.SerializerRegistryGenerator.postVisitService(SerializerRegistryGenerator.java:176)
[exec] at com.sun.xml.rpc.processor.generator.GeneratorBase.visit(GeneratorBase.java:238)
[exec] at com.sun.xml.rpc.processor.model.Service.accept(Service.java:119)
[exec] at com.sun.xml.rpc.processor.generator.GeneratorBase.visitModel(GeneratorBase.java:228)
[exec] at com.sun.xml.rpc.processor.generator.GeneratorBase.visit(GeneratorBase.java:216)
[exec] at com.sun.xml.rpc.processor.model.Model.accept(Model.java:156)
[exec] at com.sun.xml.rpc.processor.generator.GeneratorBase.doGeneration(GeneratorBase.java:205)
[exec] at com.sun.xml.rpc.processor.generator.GeneratorBase.perform(GeneratorBase.java:150)
[exec] at com.sun.xml.rpc.processor.Processor.runActions(Processor.java:105)
[exec] at com.sun.xml.rpc.tools.wscompile.CompileTool.run(CompileTool.java:763)
[exec] at com.sun.xml.rpc.util.ToolBase.run(ToolBase.java:60)
[exec] at com.sun.xml.rpc.tools.wscompile.Main.main(Main.java:39)
[exec] Caused by: java.lang.ClassNotFoundException: javax.mail.internet.MimeMultipart
[exec] at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
[exec] at java.security.AccessController.doPrivileged(Native Method)
[exec] at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
[exec] at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
[exec] at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
[exec] at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
[exec] ... 18 more

From the glassfish dev email threads, I see engineering team also noticed this issue.

Comment by Bhakti Mehta [ 17/Dec/10 ]

This has been fixed today duplicate of 15242

Comment by sonialiu [ 05/Jan/11 ]

Test still failed against latest nightly build (01/04/2011). But I did not see the earlier errors/exceptions at this time, there was no exceptions in the server log. Here is the test run output:
runclient-ssl-pe:

get-testsuite-name:
[echo] testsuite=TaxCalEjbbasedWS-EJBClient

update-didnotrun-file:
[copy] Copying 1 file to /export/sonia/appserver-sqe/pe/security/wss/ejbclient
[echo] Test TaxCalEjbbasedWS-EJBClient
[echo] is running on Platform Edition!
[exec] org.glassfish.appclient.client.acc.UserError: arg 13 = TaxCalEjbbasedWS-EJBClient
[exec] not recognized

----------------------
And I noticed that the same test also failed in DAS mode against the later builds with the same error, but it was passing in DAS mode while I reporting the original bug.
To reproduce the bug in DAS mode, follow steps below:
1. Install GF, start domain1
2. cd appserver-sqe/pe/security/wss, run "ant setup enable-wss-log restart"
3. cd appserver-sqe/pe/security/ejbws, run "ant build-deploy-run"
4. cd appserver-sqe/pe/security/ejbcleint, run "ant all"

Comment by Bhakti Mehta [ 06/Jan/11 ]

I can reproduce this error locally now. I had run the test successfully on dec 7. I see the code which throws the error is CLIBootstrap. Requesting Tim to look in this,

Comment by Bhakti Mehta [ 06/Jan/11 ]

Requesting Tim to look into this since the error is coming from appclient

Comment by Tim Quinn [ 07/Jan/11 ]

The CLIBootstrap class essentially converts the appclient command line the user enters into a java command line, with quite different settings, to actually launch the ACC and the client. CLIBootstrap uses the Pattern and Matcher classes to parse the command line. The final command-line argument passed in this test is the test suite name, which is read from a properties file and then passed as part of an <arg line-"..."/> element in the ant build.xml script.

What is happening is that the test suite name, when it is passed to the CLIBootstrap program, has a trailing newline character. This causes the regex pattern to not match for that argument, which leads to the error message.

Working on a fix in my workspace.

Comment by Tim Quinn [ 07/Jan/11 ]

How bad is its impact? (Severity)
This is a regression.

How often does it happen? Will many users see this problem? (Frequency)
Not clear. Probably fairly rare, but certain previously-working invocations of appclient will fail.

How much effort is required to fix it? (Cost)
I have a very simple fix in my workspace which has already passed the sqe test mentioned in the issue and the deployment and ejb devtests. QL tests running now.

What is the risk of fixing it and how will the risk be mitigated? (Risk)
Very small - not quite a one-line change but close to it. Running the usual tests which invoke the appclient script have passed.

Comment by Tim Quinn [ 07/Jan/11 ]

Fix checked in:

Project: glassfish
Repository: svn
Revision: 44329
Author: tjquinn
Date: 2011-01-07 21:45:10 UTC
Link:

Log Message:
------------
Fix for 14756

Regex-based handling of appclient command arguments (last November) uses the pattern .* for arguments to be passed to the client. The original implementation did not specify the DOTALL flag, and an sqe web services test happened to create a command line argument with a trailing newline which exposed this problem.

Specifying DOTALL for the command-line arguments pattern solved this problem.

Processes paths as strings instead of URIs. This greatly simplifies handling Windows-format paths, with device letters, etc.

Approved: Nazrul
Reviewed: Hong

Tests: sqe test; QL; deployment and ejb devtests

Revisions:
----------
44329

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

Comment by sonialiu [ 01/Feb/11 ]

I am still seeing the exception "javax.xml.ws.WebServiceException: null is not a valid service" that I reported in the original bug for cluster run against b39/40. The test passed in DAS mode. Could you please take a look at the issue. Thanks.

Comment by Bhakti Mehta [ 02/Feb/11 ]

Tim asked me to look into this so taking this up. I tried with b40 and I am not getting the same error as Sonia. I am attaching the log what I see. Will follow up with Sonia

Comment by Bhakti Mehta [ 02/Feb/11 ]

This is the log when I tried with b40.

Comment by Bhakti Mehta [ 02/Feb/11 ]

I am excluding this for 3.1. This is too risky to fix at this point and I will not want to cause regressions in other areas due to this fix. I will work with Sonia since I am not even getting the same error as her and target this for 3.2

Comment by Bhakti Mehta [ 13/Apr/11 ]

Fixed in 3.1.1 and trunk

Comment by Bhakti Mehta [ 13/Apr/11 ]

svn rev 45200 Thanks to Sonia for verifying with 3.2 build

Comment by sonialiu [ 13/Apr/11 ]

Verified against v3.2 b02 and the bug is fixed.





[GLASSFISH-6967] several security test cases failed on AIX against b60d Created: 23/Dec/08  Updated: 13/Apr/11  Resolved: 13/Apr/11

Status: Resolved
Project: glassfish
Component/s: security
Affects Version/s: v2.1
Fix Version/s: 3.1.1_b01

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

Operating System: All
Platform: All


Attachments: Text File server.log.runas    
Issuezilla Id: 6,967

 Description   

OS: AIX/jdk1.5.0
build: 60d
Several security test cases failed on AIX machine due to authorized user failed
to access resources. The same test cases passed on all other platforms.
Steps to reproduce the bug:
1. Install Glassfish 9.1.1. start domain
2. Checkout SQE workspace cvs co -r SJSAS911_FCS_BRANCH appserver-sqe/boostrap.xml
(CVSROOT: :pserver:<user>@redcvs.red.iplanet.com:/m/jws)
cd appserver-sqe
ant -f bootstrap.xml -Dtag=SJSAS911_FCS_BRANCH bootstrap.xml co-security
3.set env variables
S1AS_HOME <as install dir>
SPS_HOME <appserver-sqe>
ANT_HOME
JAVA_HOME
5. cd appserver-sqe/pe/security/jsr115mr/RunAs/ejbmodule2, run "ant setup build
deploy run", one test failed.
[exec] -----------------------------------------
[exec]- ejbmodule2 methodIsNotAuthorized test: PASS -
[exec]- ejbmodule2 methodIsAuthorized test: FAIL -
[exec] Total PASS: 1
[exec] Total FAIL: 1
[exec] Total DNR: 0
[exec] -------------------------------------------
6. Attachecd server.log



 Comments   
Comment by sonialiu [ 23/Dec/08 ]

Created an attachment (id=2169)
server.log

Comment by sanandal [ 11/Jan/09 ]

"Reclassifying as P4 because this issue is not deemed "must fix" for this v2.1
release whose primary release driver is SailFin.
This issue will be scrubbed after this release and will be given the right
priority for the next release."

Comment by kumara [ 01/Sep/09 ]

Changing version from 9.1.1 to v2.1 to reflect new name/version.

Comment by kumarjayanti [ 13/Apr/11 ]

Sonia,

Can you please try this scenario in AIX to see if the problem persists with V3.1.1.





[GLASSFISH-16301] jsessionID drop after form-submit & redirect cycle Created: 01/Apr/11  Updated: 13/Apr/11  Resolved: 12/Apr/11

Status: Closed
Project: glassfish
Component/s: web_container
Affects Version/s: V3, v3.0.1, 3.1
Fix Version/s: 3.1.1_b01

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

All 3.0.0; 3.0.1; 3.1;



 Description   

This problem takes place when using wicket; It's depending on glassfish 3.0/ 3.0.1/ 3.1 as JBOSS 6; TOMCAT 6; 7; JETTY; are all not showing this behaviour;

My idea is that an access to root path of a webapp is not considered necessary of jsessionId en/decoding;

To reproduce just get a Wicket-App like the BrixDemo (https://github.com/brix-cms/brix-cms) and run it, then do following steps:

-> Page with Tile holding stateful Form (stateless is also not working but less dramatic): accessing it via disables cookies
-> url e.g.: /brixdemo/demos/stockquote.html;jsessionid=1F89CE840F7281BA2A92F2272CD74A60 then send form
-> url: /brixdemo/;jsessionid=1F89CE840F7281BA2A92F2272CD74A60?wicket:interface=:2:brix-tile-8:form::IFormSubmitListener::

then one is immeadiatly redirected to the mapped path at "/" with a clean, new session! - in case the session would still be existing, then the request would be handled differend;

This can be reproduced by starting brix-demo on Glassfish 3 and 3.1 and going to the Stockquote forms with cookies disabled;

I originally thought this was a BrixCMS bug, but it turned out that only glassfish is affected, therefore this bug report;



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

Can you provide a unit test for the scenario?

Comment by KBachl [ 10/Apr/11 ]

Hello Shing Wai,

apologise for my late answer. At the moment I can't provde a unit-test, however, the reproduction is quite simple as stated above. Just get the project above and do a mvn clean install, afterwards drop in the brix-demo.war (or alternatively use this one: http://code.google.com/p/brix-cms/downloads/detail?name=brix-demo-1.1.0.war ) into GF 3 and follow the steps above and you see the loss of session.

go to $

{applicationPath}

/demos/stockquote with a browser that has disabled cookies, then send the form at the bottom (it has stateful written over it) and you see that you end having a brand new jsession; compare this to a deploy at e.g: jetty or tomcat where you won't loose the session;

I hope this helps, if you have any questions left please do not hesitate to contact me,

Best,

KBachl

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

I don't see the issue in trunk.
This looks like the issue specified in
http://java.net/jira/browse/GLASSFISH-13129

You may like to download 3.1.1 build or 3.2 build from trunk.

Comment by KBachl [ 13/Apr/11 ]

Hello Shing Wai,

I can confirm that the issue is fixed in 3.1.1-continous build from today; Seems it was the Issue you mentioned; Any ETA on 3.1.1 final release?

Thank you and Best Regards





[GLASSFISH-10843] some of the ldap properties are not deleted when new ldapRealm is created Created: 05/Nov/09  Updated: 12/Apr/11  Resolved: 12/Apr/11

Status: Closed
Project: glassfish
Component/s: admin
Affects Version/s: V3
Fix Version/s: 3.1.1_b01

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

Operating System: All
Platform: PC


Issuezilla Id: 10,843
Tags: 3_1-exclude

 Description   
  1. asadmin create-domain domain1
  2. asadmin start-domain

configure a ldapRealm with a group
---------------------------------

  1. asadmin configure-ldap-for-admin --basedn
    ou=glassfish,o=sunmicrosystemsinc,c=usa,dc=sfbay,dc=sun,dc=com --url
    ldap://easqesf5.sfbay.sun.com:389 -g administration
    LDAP server at ldap://easqesf5.sfbay.sun.com:389 is accessible.
    ...
    The LDAP Auth Realm admin-realm was configured correctly in admin server's
    configuration.

Command configure-ldap-for-admin executed successfully.

-------------------------------------------
domain.xml after first realm configuration
-------------------------------------------

<auth-realm name="admin-realm"
classname="com.sun.enterprise.security.auth.realm.ldap.LDAPRealm">
<property name="directory" value="ldap://easqesf5.sfbay.sun.com:389" />
<property name="base-dn"
value="ou=glassfish,o=sunmicrosystemsinc,c=usa,dc=sfbay,dc=sun,dc=com" />
<property name="jaas-context" value="ldapRealm" />
<property name="group-mapping" value="administration->asadmin" />
</auth-realm>

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

Now I create another ldapRealm configuration without a group.
-------------------------------------------------------------

  1. asadmin configure-ldap-for-admin --basedn
    ou=glassfish,o=sunmicrosystemsinc,c=usa,dc=sfbay,dc=sun,dc=com --url
    ldap://easqesf5.sfbay:389
    Enter admin user name> gfuser1
    Enter admin password for user "gfuser1">
    LDAP server at ldap://easqesf5.sfbay.sun.com:389 is accessible.
    ...
    The LDAP Auth Realm admin-realm was configured correctly in admin server's
    configuration.

Command configure-ldap-for-admin executed successfully.

see below the domain.xml still has the group from previous config which is a bug.

<auth-realm name="admin-realm"
classname="com.sun.enterprise.security.auth.realm.ldap.LDAPRealm">
<property name="directory" value="ldap://easqesf5.sfbay:389" />
<property name="base-dn"
value="ou=glassfish,o=sunmicrosystemsinc,c=usa,dc=sfbay,dc=sun,dc=com" />
<property name="jaas-context" value="ldapRealm" />
<property name="group-mapping" value="administration->asadmin" />
</auth-realm>



 Comments   
Comment by sankarpn [ 05/Nov/09 ]

cc

Comment by vince kraemer [ 05/Nov/09 ]

are you sure that a new ldap realm is created? try changing the other args like
basedn and/or url

Comment by sankarpn [ 05/Nov/09 ]

>are you sure that a new ldap realm is created?
yes it is created
>try changing the other args like basedn and/or url
I verified that it indeed creates a new realm but with a old group info retained.

Comment by kumara [ 09/Nov/09 ]

I looked at the code and I believe there is some work needed to convert the entire operation to a single
"config" transaction. Re-running configure-ldap-for-admin results in old configuration being deleted
and a new one being added, so theoretically it should not have retained the group property from the
previous command (delete is supposed to clean up). However, it looks like somewhere the realm object
is being retained.

We can do a workaround and explicitly delete group property if the user does not specify group option
but I think that will not address the root cause of the problem.

Given that running configure-ldap-for-admin is an infrequently used command and test case requires
running the command twice and second run is a very specific scenario (do not specify group), I am
going to lower this to P4 and we will revisit it when km is back.

Comment by Tom Mueller [ 15/Feb/11 ]

Upping priority based on age of issue. This should be fixed in 3.2.

Comment by Nithya Ramakrishnan [ 23/Feb/11 ]

This issue is not reproducible in the latest 3.1 builds. On recreating the admin ldap realm without the -g option, the ldapRealm groupname mapping is not present in domain.xml:

<auth-realm classname="com.sun.enterprise.security.auth.realm.ldap.LDAPRealm" name="admin-realm">
<property name="directory" value="ldap://localhost:1389"></property>
<property name="base-dn" value="dc=example,dc=com"></property>
<property name="jaas-context" value="ldapRealm"></property>
</auth-realm>

Comment by Nithya Ramakrishnan [ 08/Apr/11 ]

Could you please let us know if the same error is happening currently in the latest build? When we had tested last, this was found to be working correctly as expected.
If the same error is found to be happening, please provide us details of the ldap setup, so that we could reconfirm if the error happens.

Thanks
Nithya

Comment by Nithya Ramakrishnan [ 12/Apr/11 ]

Re-opened by mistake. Closed as per previous observation.

Comment by Nithya Ramakrishnan [ 12/Apr/11 ]

Re-opening to change the fix version

Comment by Nithya Ramakrishnan [ 12/Apr/11 ]

Fixed





[GLASSFISH-16112] Admin GUI fails with NPE when attempting to undeploy an application, and redeploy also fails - must manually clean domain Created: 01/Mar/11  Updated: 11/Apr/11  Resolved: 11/Apr/11

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

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

Ubuntu Linux 10.04 x86, Sun JVM 1.6.0_24-b07, Mozilla Firefox 3.6.13


Attachments: GZip Archive deploy-undeploy-logs.tar.gz     XML File domain.xml     File hello.war     File stateless-simple.ear    

 Description   

When attempting to undeploy an application, even if undeploy is successful, the UI shows the "Long operation detected" mini-dialog, only to fail with an NPE moments later. Afterwards, the Admin UI is no longer accessible and Glassfish displays the "default welcome" page where the UI should be.

Inspecting the domain.xml, it appears that the undeployment is successful (no further reference of the application is visible).

Stack trace from GUI undeploy failure:

INFO: JSF1027: [null] The ELResolvers for JSF were not registered with the JSP container.
INFO: file:/opt/gf3.1/glassfish/domains/domain1/applications/teos-1.0.7-r2712/WEB-INF/lib/teos-core-1.0.7.jar_TEOS Core logout successful
INFO: No timers to be deleted for id: 85130494774476800
INFO: Admin Console: Initializing Session Attributes...
WARNING: java.lang.reflect.InvocationTargetException while attempting to process a 'command' event for 'button1'.
java.lang.RuntimeException: java.lang.reflect.InvocationTargetException while attempting to process a 'command' event for 'button1'.
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:422)
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:394)
at com.sun.jsftemplating.layout.event.CommandActionListener.invokeCommandHandlers(CommandActionListener.java:150)
at com.sun.jsftemplating.layout.event.CommandActionListener.processAction(CommandActionListener.java:98)
at javax.faces.event.ActionEvent.processListener(ActionEvent.java:88)
at javax.faces.component.UIComponentBase.broadcast(UIComponentBase.java:769)
at javax.faces.component.UICommand.broadcast(UICommand.java:300)
at com.sun.webui.jsf.component.WebuiCommand.broadcast(WebuiCommand.java:166)
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:409)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1534)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:343)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:215)
at com.sun.webui.jsf.util.UploadFilter.doFilter(UploadFilter.java:233)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:215)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:279)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655)
at org.apache.catalina.core.StandardPipeline.doChainInvoke(StandardPipeline.java:600)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:96)
at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:91)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:162)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:326)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:227)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:228)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:822)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:719)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1013)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:662)
Caused by: 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.jsftemplating.layout.descriptors.handler.Handler.invoke(Handler.java:442)
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:420)
... 43 more
Caused by: java.lang.IllegalStateException: REST Server Name not set!
at org.glassfish.admingui.common.util.GuiUtil.initSessionAttributes(GuiUtil.java:158)
at org.glassfish.admingui.common.util.GuiUtil.getSessionValue(GuiUtil.java:241)
at org.glassfish.admingui.common.handlers.DeploymentHandler.removeFromDefaultWebModule(DeploymentHandler.java:335)
at org.glassfish.admingui.common.handlers.DeploymentHandler.undeploy(DeploymentHandler.java:318)
... 49 more

SEVERE: javax.faces.FacesException: java.lang.reflect.InvocationTargetException while attempting to process a 'command' event for 'button1'.
at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:89)
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:409)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1534)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:343)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:215)
at com.sun.webui.jsf.util.UploadFilter.doFilter(UploadFilter.java:233)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:215)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:279)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655)
at org.apache.catalina.core.StandardPipeline.doChainInvoke(StandardPipeline.java:600)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:96)
at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:91)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:162)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:326)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:227)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:228)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:822)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:719)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1013)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:662)
Caused by: java.lang.RuntimeException: java.lang.reflect.InvocationTargetException while attempting to process a 'command' event for 'button1'.
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:422)
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:394)
at com.sun.jsftemplating.layout.event.CommandActionListener.invokeCommandHandlers(CommandActionListener.java:150)
at com.sun.jsftemplating.layout.event.CommandActionListener.processAction(CommandActionListener.java:98)
at javax.faces.event.ActionEvent.processListener(ActionEvent.java:88)
at javax.faces.component.UIComponentBase.broadcast(UIComponentBase.java:769)
at javax.faces.component.UICommand.broadcast(UICommand.java:300)
at com.sun.webui.jsf.component.WebuiCommand.broadcast(WebuiCommand.java:166)
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)
... 33 more
Caused by: 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.jsftemplating.layout.descriptors.handler.Handler.invoke(Handler.java:442)
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:420)
... 43 more
Caused by: java.lang.IllegalStateException: REST Server Name not set!
at org.glassfish.admingui.common.util.GuiUtil.initSessionAttributes(GuiUtil.java:158)
at org.glassfish.admingui.common.util.GuiUtil.getSessionValue(GuiUtil.java:241)
at org.glassfish.admingui.common.handlers.DeploymentHandler.removeFromDefaultWebModule(DeploymentHandler.java:335)
at org.glassfish.admingui.common.handlers.DeploymentHandler.undeploy(DeploymentHandler.java:318)
... 49 more

WARNING: StandardWrapperValve[FacesServlet]: PWC1406: Servlet.service() for servlet FacesServlet threw exception
java.lang.NullPointerException
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:410)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1534)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:343)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:215)
at com.sun.webui.jsf.util.UploadFilter.doFilter(UploadFilter.java:233)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:215)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:279)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655)
at org.apache.catalina.core.StandardPipeline.doChainInvoke(StandardPipeline.java:600)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:96)
at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:91)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:162)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:326)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:227)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:228)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:822)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:719)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1013)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:662)



 Comments   
Comment by drivera [ 01/Mar/11 ]

I made a mistake above - the environment is Ubuntu 10.10, not 10.04. Sorry about that - should be "same difference", though.

Comment by Anissa Lam [ 01/Mar/11 ]

Looking at the stack trace,

Caused by: java.lang.IllegalStateException: REST Server Name not set!
at org.glassfish.admingui.common.util.GuiUtil.initSessionAttributes(GuiUtil.java:158)
at org.glassfish.admingui.common.util.GuiUtil.getSessionValue(GuiUtil.java:241)
at org.glassfish.admingui.common.handlers.DeploymentHandler.removeFromDefaultWebModule(DeploymentHandler.java:335)
at org.glassfish.admingui.common.handlers.DeploymentHandler.undeploy(DeploymentHandler.java:318)

GUI has lost its session information and needs to initialize it again, yet doesn't have enough info.
I am not sure what is causing it as it is in the middle of undeployment and shouldn't caused by session timeout.
Please let me know the following:

  • Do you see this consistently and always reproducible ?
  • If you use the same browser, open up another browser window and launch GUI from there, will that work ?
  • If the above doesn't, can you try a different browser and will GUI come up then ?
  • Is this the same app that is causing the problem in GLASSFISH-16113 or GLASSFISH-16114 ?
  • Will it be possible attach the war for me to reproduce the issue ?

thanks.

Comment by drivera [ 01/Mar/11 ]

Yes, 100% reproducible.

Same browser, new browser window ineffectual - UI is gone as in no longer in Kansas
Different browser - same effect, UI is gone.

Yes, it's the same app as for those two issues, but those other two issues happen with all apps. The application itself does no "black magic" - no funky threading, no runtime manipulation, no advanced reflection, no runtime instrumentation, etc.

I'm afraid I can't provide the WAR due to licensing constraints. In addition, there would be substantial setup to be made to prepare a "test" environment (databases, paths, etc).

Comment by drivera [ 01/Mar/11 ]

But, if you like, I can make some time available and help you in your research - perhaps even provide you remote access to the testing instance so you can latch on a debugger? E-mail me privately and we can coordinate.

Comment by Anissa Lam [ 01/Mar/11 ]

Thanks for the offer
You mentioned this is an app that does no "black magic", but the issue is 100% reproducible.
Can you try with a simple hello.war to see if you run into this same problem ? I want to isolate if this issue only occurs for this particular app or this is an environment issue.
I have attached both hello.war and another .ear file, please deploy and undeploy that to see what happens. thanks

Comment by drivera [ 01/Mar/11 ]

Both deployed and undeployed fine. I can't think of why the app would work on 3.0.1 but not 3.1 - if there were something glaringly broken, then I'd expect either:

1) the app to not work with 3.0.1
2) plenty of errors pointing out the actual API/model usage problems (in 3.1)

Would you agree?

Granted, this is the real world...

Let me know how else I can help you. I'm hoping to succeed with deploying on 3.1 because we're being afflicted by a memory leak that I believe is due to the well-known CDI memory issues in 3.0.1. I just need to confirm it.

However, with these issues, it'll be a tough sell even if we succeed...

Comment by drivera [ 01/Mar/11 ]

Sorry - my previous comment may be misleading. The app DOES deploy and work in 3.1 - but it causes the aforementioned undeployment problems when undeploying via the UI. Undeploy via command line works.

Furthermore, the app is afflicted with the issue described in GLASSFISH-16115, which is the only part we've been unable to test (for obvious reasons).

Comment by Anissa Lam [ 01/Mar/11 ]

As you said the 2 attached app doesn't have issue, yet undeploying your app shows the issue 100% of time, there must be something related to your app that triggers the problem.
If you do the following:

  • launch GUI
  • deploy the app (using GUI or CLI, whatever you have been using before)
  • undeploy the app using CLI

Does GUI work after the undeployment using CLI ?

Does the app deploy to "server" (DAS), or cluster ?
What virtual server does this app deploy to ?
Is there any other config change you made, eg, create new VS and deploy to this new VS etc ?
Will it be possible for you to attach domain.xml after the app is deployed, but BEFORE undeploy ?

  • one more thing, once you see this problem, even using another browser cannot bring up GUI. How about restarting the server ? Can you launch GUI after restarting server ?
Comment by drivera [ 01/Mar/11 ]

Domain XML attached, as requested.

Your answers:

  • KEY POINT: After CLI undeploy, the Admin UI also goes offline.

This was the procedure followed:

1) Start the server
2) Deploy the app
3) bring up the Admin UI
4) Go to Apps page, to see the app listed
5) hit the app main page, login, make sure it's up, etc
6) undeploy via CLI
7) Navigate to the "Lifecycle Modules" entry on the navigation panel

  • UI now returns either 404 (not found), or if a reload to the base URL (http://localhost:4848) it shows the "placeholder" page.
  • IMPORTANT: There are NO exceptions in the log, whatsoever.

More info...

  • The app deploys to "whatever the default deployment target is from asadmin deploy", which I expect is server since I've not configured it to anything else.
  • No clustering is in use
  • No VS or additional server configuration (except the requisite DataSources) has been created
  • Some JVM flags have been added (noted in the attached domain.xml)
  • Admin UI works fine upon a server reboot
Comment by drivera [ 01/Mar/11 ]

More info

  • KEY POINT: After CLI undeploy, the Admin UI was accessible.

This was the procedure followed:

1) Start the server
2) Deploy the app
3) hit the app main page, login, make sure it's up, etc
4) undeploy via CLI
5) bring up the Admin UI (which starts up fine)
6) Admin UI seems to be fine

So the problem seems to be (in this particular case, obviously): when an undeploy is executed while the Admin UI is up, the undeploy drags the Admin UI with it...

Is there a command I could re-run afterwards to re-deploy the admin UI and see if that works in bringing it back online? At least that would tell us if that's what's happening.

Keep in mind the last two are wild, shot-from-the-hip guesses...

Comment by Anissa Lam [ 04/Mar/11 ]

>> Is there a command I could re-run afterwards to re-deploy the admin UI and see if that works in bringing it back online?
If you start up GUI with a new browser, GUI initialize for that session.
One thing we can try is to set the logger level to FINEST for all, restart the domain and repeat the steps. Hopefully, it will give us more information.
To do that, go to Configuration -> server-config -> Logger Settings and then the Log Levels tab. change the level and save.

Can you tell us more on what kind of app this is ? Will you be able to scale down your app and provide us a copy of your app with 'sensitive info' removed so we can reproduce the case ? It is really hard to know what is going on without any knowledge of your app.

Since there is workaround and you can undeploy the app with CLI and then bring up the console, i am downgrading this to P3.

Comment by drivera [ 04/Mar/11 ]

I'm not sure I agree with the priority drop, since this is a pretty glaring defect in a part of the UI where one as an administrator would least expect it to fail.

Having said that, yes - I'll get you this information as soon as I can. Also, the workaround is limited since if I re-deploy, and then undeploy after the UI is 'initialized', then clearly we're back in the same hole.

I'll get you the info tomorrow during my next "playtime" session.

Cheers.

Comment by drivera [ 05/Mar/11 ]

Requested log files attached. Logs are split into two files: one file is the log from the deployment of the application, the other is the log from the undeployment of the application.

Hopefully, this will shed more light. I'm working on permission to give you a copy of the app so you may reproduce, but I'm not hopeful. Also, the setup is somewhat complex so that might be another barrier.

Let me know if there's anything else I can help you with in the meantime.

Comment by Anissa Lam [ 23/Mar/11 ]

If it is not feasible for you to provide a stripped down application for us to reproduce the problem, please provide more info about your app.
Actually you can remove all your business logic, and i don't care about setting up the database etc. either since i just want to deploy and undeploy to reproduce the issue. I really don't need the app to run successfully.

What library is packaged with it ?
Can you give the directory structure of your app ?

Comment by scott6666 [ 29/Mar/11 ]

Looks like I just ran into the same issue.

War file runs fine. Redeploy killed the gui. Restarted gui and app was not enabled. Restarted server and came up ok.

Same basic app ran fine under 3.0.1. Had been developed a bit since then but no changes in technology stack or components used.

[#|2011-03-29T17:01:39.346+0000|SEVERE|glassfish3.1|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=99;_ThreadName=Thread-1;|javax.faces.FacesException: java.lang.reflect.InvocationTargetException while attempting to process a 'command' event for 'reloadLink'.
at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:89)
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:409)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1534)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:343)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:215)
at com.sun.webui.jsf.util.UploadFilter.doFilter(UploadFilter.java:233)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:215)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:279)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655)
at org.apache.catalina.core.StandardPipeline.doChainInvoke(StandardPipeline.java:600)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:96)
at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:91)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:162)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:326)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:227)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:228)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:822)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:719)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1013)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:619)
Caused by: java.lang.RuntimeException: java.lang.reflect.InvocationTargetException while attempting to process a 'command' event for 'reloadLink'.
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:422)
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:394)
at com.sun.jsftemplating.layout.event.CommandActionListener.invokeCommandHandlers(CommandActionListener.java:150)
at com.sun.jsftemplating.layout.event.CommandActionListener.processAction(CommandActionListener.java:98)
at javax.faces.event.ActionEvent.processListener(ActionEvent.java:88)
at javax.faces.component.UIComponentBase.broadcast(UIComponentBase.java:769)
at javax.faces.component.UICommand.broadcast(UICommand.java:300)
at com.sun.webui.jsf.component.WebuiCommand.broadcast(WebuiCommand.java:166)
at com.sun.webui.jsf.component.TableRowGroup.broadcast(TableRowGroup.java:1989)
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)
... 33 more
Caused by: 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.jsftemplating.layout.descriptors.handler.Handler.invoke(Handler.java:442)
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:420)
... 44 more
Caused by: java.lang.IllegalStateException: REST Server Name not set!
at org.glassfish.admingui.common.util.GuiUtil.initSessionAttributes(GuiUtil.java:158)
at org.glassfish.admingui.common.util.GuiUtil.getSessionValue(GuiUtil.java:241)
at org.glassfish.admingui.common.util.GuiUtil.getDeploymentFacility(GuiUtil.java:251)
at org.glassfish.admingui.common.util.DeployUtil.enableApp(DeployUtil.java:169)
at org.glassfish.admingui.common.util.DeployUtil.reloadApplication(DeployUtil.java:156)
at org.glassfish.admingui.common.handlers.ApplicationHandlers.reloadApplication(ApplicationHandlers.java:483)
... 50 more

#]

[#|2011-03-29T17:01:39.350+0000|WARNING|glassfish3.1|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=99;_ThreadName=Thread-1;|StandardWrapperValve[FacesServlet]: PWC1406: Servlet.service() for servlet FacesServlet threw exception
java.lang.NullPointerException
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:410)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1534)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:343)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:215)
at com.sun.webui.jsf.util.UploadFilter.doFilter(UploadFilter.java:233)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:215)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:279)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655)
at org.apache.catalina.core.StandardPipeline.doChainInvoke(StandardPipeline.java:600)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:96)
at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:91)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:162)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:326)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:227)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:228)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:822)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:719)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1013)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:619)

#]
Comment by Anissa Lam [ 07/Apr/11 ]

I have requested several times for a test app, or at least the list of contents of your app, but i never get any answer.

GLASSFISH-16223 is reporting the same issue, that the console is not available after undeployment of their app.
The deployment code in the console has been changed to use REST API, and with the application provided by the submitter in GLASSFISH-16223, I can no longer reproduce the problem.

So, Please try 3.2 b01 that is available from http://dlc.sun.com.edgesuite.net/glassfish/3.2/promoted/
Hopefully that fix your problem as well.

Comment by Anissa Lam [ 11/Apr/11 ]

I am marking this bug resolved as his is reporting the same problem as in GLASSFISH-16223.
Using the application given to me by the submitter of GLASSFISH-16223, I verified that the issue is fixed after I convert the code to use REST for application deployment.

This is fixed in both 3.1.1 b01 and 3.2 b01 as fix checked in before the 3.1.1 branch get created.





[GLASSFISH-16330] sqlserver datasource class does not mention the ones documented on MS's homepage Created: 08/Apr/11  Updated: 10/Apr/11  Resolved: 10/Apr/11

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

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


 Description   

I think we could be using an old driver class name for SQLServer.

GlassFish has the following entry (in cpds.properties):

MICROSOFTSQLSERVER=com.microsoft.sqlserver.jdbc.ConnectionPoolSQLServerDataSource

According to the following article from Microsoft (on SQLServer 2008 R2) it's another class:

http://msdn.microsoft.com/en-us/library/ms378484.aspx

com.microsoft.sqlserver.jdbc.SQLServerConnectionPoolDataSource
or
com.microsoft.sqlserver.jdbc.SQLServerXADataSource



 Comments   
Comment by Shalini [ 10/Apr/11 ]

Fixing this issue.

Sending jdbc/templates/src/main/resources/glassfish/lib/install/databases/dbvendormapping/cpds.properties
Transmitting file data .
Committed revision 46074.





[GLASSFISH-16099] [patch] NPE in UniformLogFormatter when trying to log collections/maps with null values/keys Created: 24/Feb/11  Updated: 10/Apr/11  Resolved: 10/Apr/11

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

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

Attachments: Text File UniformLogFormatter-null.patch    
Tags: 3_1-next

 Description   

When trying to log some message with parameters which in turn contain null values/keys the UniformLogFormatter class throws a NPE because it doesn't handle such situations:

java.lang.NullPointerException
at com.sun.enterprise.server.logging.UniformLogFormatter.getNameValuePairs(UniformLogFormatter.java:208)
at com.sun.enterprise.server.logging.UniformLogFormatter.uniformLogFormat(UniformLogFormatter.java:276)
at com.sun.enterprise.server.logging.UniformLogFormatter.format(UniformLogFormatter.java:161)
at java.util.logging.StreamHandler.publish(StreamHandler.java:179)
at java.util.logging.ConsoleHandler.publish(ConsoleHandler.java:88)
at java.util.logging.Logger.log(Logger.java:458)

The attached patch (against SVN rev. 45202) fixes this problem.



 Comments   
Comment by naman_mehta [ 24/Feb/11 ]

I will verify and plan to check-in the same.

Comment by chaoslayer [ 25/Feb/11 ]

So, this will not make it into 3.1?

Comment by naman_mehta [ 25/Feb/11 ]

Right now 3.1 branch is closed so we can make it patch for 3.1. But it will be check-in in the 3.2 by monday.

Comment by chaoslayer [ 25/Feb/11 ]

OK, so how do we get those patches if we want to use a version build from upstream (=you)?

Or is this then scheduled for inclusion to a patch release?

Comment by naman_mehta [ 27/Feb/11 ]

It would be added in next patch.

Comment by naman_mehta [ 24/Mar/11 ]

Made changes required for the same. Bug is fixed now.

Comment by ancoron [ 25/Mar/11 ]

Which revision?

Comment by naman_mehta [ 25/Mar/11 ]

Right now you can find in latest nightly build and soon it will be part of 3.1 next release.





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

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

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


 Description   

The following is in recent email discussion from Naman

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

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

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



 Comments   
Comment by Scott Fordin [ 18/Mar/11 ]

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

Comment by naman_mehta [ 21/Mar/11 ]

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





[GLASSFISH-16139] add ShoalLogger.level=CONFIG to glassfish/lib/templates/logging.properties Created: 03/Mar/11  Updated: 10/Apr/11  Resolved: 10/Apr/11

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

Type: Bug Priority: Major
Reporter: Joe Fialli Assignee: naman_mehta
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-14674 Log Level setting not honored Closed
Tags: 3_1-next

 Description   

ShoalLogger is not showing up by default in asadmin GUI Configurations => cluster-config => Logger Settings => LogLevels => Logger Name.

Workaround is to explicitly set ShoalLogger using following cli command.

% asadmin set-log-levels ShoalLogger=CONFIG
% asadmin set-log-levels --target <clustername>-config ShoalLogger=CONFIG

I noticed if I manually added ShoalLogger to glassfish/lib/templates/logging.properties,
that this addresses the issue.



 Comments   
Comment by Joe Fialli [ 03/Mar/11 ]

Glassfish issue 14674 was incorrectly reopened due to this issue.

Comment by naman_mehta [ 20/Mar/11 ]

Made changes in logging.properties template for the same.





[GLASSFISH-16132] Bug in create-http-lb command with --lbenableallapplications=true when the application is already availability enabled. Created: 02/Mar/11  Updated: 08/Apr/11  Resolved: 05/Apr/11

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

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


 Description   

I deployed a Web Application to a GF Cluster cluster1 with availability enabled.

Now When I try to create http load balancer config for all applications deployed on that cluster, I get the following error.

./asadmin create-http-lb --devicehost retriever --deviceport 8989 --target cluster1 --lbenableallinstances=true --lbenableallapplications=true my-http-lb
remote failure: Application [WebApplication] is already enabled for [cluster1].
Command create-http-lb failed.

If the app is already availability enabled, it should just continue and not throw an error.
One more interesting thing, though it says the command failed, it did create the http-lb-config as shown below.

[rama@shepherd]$ ./asadmin list-http-lb-configs
my-http-lb_LB_CONFIG
Command list-http-lb-configs executed successfully.



 Comments   
Comment by Yamini K B [ 05/Apr/11 ]

Sending src/main/java/org/glassfish/loadbalancer/admin/cli/CreateHTTPHealthCheckerCommand.java
Sending src/main/java/org/glassfish/loadbalancer/admin/cli/DisableHTTPLBApplicationCommand.java
Sending src/main/java/org/glassfish/loadbalancer/admin/cli/DisableHTTPLBServerCommand.java
Sending src/main/java/org/glassfish/loadbalancer/admin/cli/EnableHTTPLBApplicationCommand.java
Sending src/main/java/org/glassfish/loadbalancer/admin/cli/EnableHTTPLBServerCommand.java
Transmitting file data .....
Committed revision 45929.





[GLASSFISH-15884] Unable to use a custom Keystore for SSL with embedded version Created: 08/Feb/11  Updated: 07/Apr/11  Resolved: 08/Feb/11

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

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

Windows XP SP3
Java 1.6 for business u18
Glassfish-embedded-all-b41.jar


Tags: 3_1-exclude, embedded, ssl

 Description   

Hello,

I'm trying to use a custom keystore to configure a HTTPS listener in glassfish with the following code :

GlassFish glassfish = GlassFishRuntime.bootstrap().newGlassFish();
glassfish.start();

// Create a web container, and https listener.
WebContainer webcontainer = glassfish.getService(WebContainer.class);
HttpsListener listener = new HttpsListener();
listener.setPort(9191);
listener.setId("https-listener-2");
listener.setProtocol("https"); // enable security
SslConfig sslConfig = new SslConfig();
sslConfig.setKeyStore("C:\\temp
mykeystore.jks");
sslConfig.setKeyPassword("Abcd1234");
sslConfig.setTrustStore(new File("C:\\temp
mykeystore.jks"));
listener.setSslConfig(sslConfig);
webcontainer.addWebListener(listener);

When a connect to my server in the 9191 port, the certificate used is not the one in my keystore, but the one located in

{instanceRoot}

/config/keystore.jks

After digging in the open and resolved issues on Embedded-Glassfish, it appears that the issue is caused by the fix of "GLASSFISH-14572 - Unable to create https listeners in embedded glassfish" which force the value of the KeyStore/TrustStore properties through the jvm-options in the embedded domain.xml (in org.glassfish.embed package)

After doing a rollback of the change (i.e removing the 2 jvm-options lines from the domain.xml) the glassfish server correctly use the system properties defined.

However, setting the KeyStore/TrustStore/Password through the org.glassfish.embeddable.web.config.SslConfig object does not seem to have any impact. If the system properties are set, they take precedence. If they are not set, the following error is thrown :

SEVERE: Failed to load keystore type JKS with path null due to null
java.lang.NullPointerException
at java.io.File.<init>(File.java:222)
at com.sun.grizzly.util.net.jsse.JSSESocketFactory.getStore(JSSESocketFactory.java:326)
at com.sun.grizzly.util.net.jsse.JSSESocketFactory.getKeystore(JSSESocketFactory.java:272)
at com.sun.grizzly.util.net.jsse.JSSE14SocketFactory.getKeyManagers(JSSE14SocketFactory.java:203)
...

Once the SslConfig usage is fixed, it would be nice to be able to change the KeyStore type to something else than JKS through the same object.



 Comments   
Comment by Bhavanishankar [ 08/Feb/11 ]

The fix for 14572 was to made so that HTTPS listener creation works out of the box. As you rightly pointed out, you can always specify -Djavax.net.ssl.keyStore and -Djavax.net.ssl.trustStore when launching your embedded program.

Assigning to web container to look into why the configurations specified programmatically via SslConfig don't take precedence over the system properties.

Comment by gastush [ 08/Feb/11 ]

The problem with setting -Djavax.net.ssl.keyStore when launching the program is that it gets overrideng by the "default" values taken from the domain.xml file.
Just do the following to see it in action :

System.out.println(System.getProperty("javax.net.ssl.keyStore"));
GlassFishRuntime gfr = GlassFishRuntime.bootstrap();
GlassFish glassfish = gfr.newGlassFish();
glassfish.start();
System.out.println(System.getProperty("javax.net.ssl.keyStore"));

run with java -Djavax.net.ssl.keyStore=somekeystore.jks argument

And you will see that the value before and after are different, which is not what I was expecting.
After starting the glassfish server, the javax.net.ssl.keyStore property contains the value defined in the domain.xml and not the one given on the command line.

Comment by Bhavanishankar [ 08/Feb/11 ]

Okay, I see. So, basically we have 2 issues here:

1. keyStore & trustStore settings from domain.xml is always getting used.

2. listener.setSslConfig(sslConfig) is not working as expected.

Workaround for #1 is to get the domain.xml from http://embedded-glassfish.java.net/domain.xml and change keystore/truststore vm options and use it while embedding GlassFish, like this:

GlassFishRuntime gfr = GlassFishRuntime.bootstrap();
GlassFishProperties gfProps = new GlassFishProperties();
gfProps.setConfigFileURI(new File("modified-domain.xml").toURI().toString());
GlassFish glassfish = gfr.newGlassFish(gfProps);
glassfish.start();

IMO, #1 is a generic issue in the sense that any vm options supplied by the user should always take precedence over what is in domain.xml. So, I will file a separate issue for #1, and leave this issue for addressing #2.

Comment by Bhavanishankar [ 08/Feb/11 ]

I meant "#1 is a generic issue in the sense that any 'system property' supplied by the user should always take precedence over what is in domain.xml's jvm-options."

Comment by Amy Roh [ 08/Feb/11 ]

The ability to configure SSL connector over the system properties will be implemented in 3.2.

Comment by Amy Roh [ 08/Feb/11 ]

Fixed

Sending web-embed/api/src/main/java/org/glassfish/embeddable/web/HttpsListener.java
Sending web-embed/api/src/main/java/org/glassfish/embeddable/web/config/SslConfig.java
Sending web-embed/impl/src/main/java/org/glassfish/web/embed/impl/WebContainerImpl.java
Transmitting file data ...
Committed revision 45006.





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

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

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

Windows, Cygwin


Attachments: File AppClientTest.ear     Java Archive File AppClientTestClient.jar    
Tags: 3_1-exclude, 3_1-release-note-added, 3_1-release-notes, 3_1windows

 Description   

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

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

See below:

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

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

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

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



 Comments   
Comment by Tim Quinn [ 18/Feb/11 ]

Sreekanth,

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

Comment by Tim Quinn [ 20/Feb/11 ]

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

Investigating.

Comment by Tim Quinn [ 21/Feb/11 ]

We are excluding this from 3.1.

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

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

Comment by Tim Quinn [ 14/Mar/11 ]

Release notes info:

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

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

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

Comment by Tim Quinn [ 17/Mar/11 ]

Fix checked in:

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

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

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

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

Tests: QL, deployment devtests, cygwin on Windows test

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

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

Comment by Tim Quinn [ 24/Mar/11 ]

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

Comment by Scott Fordin [ 24/Mar/11 ]

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

Comment by Tim Quinn [ 30/Mar/11 ]

Fix checked in.

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

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

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

Tests: QL, deployment devtests, cygwin on Windows test

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

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





[GLASSFISH-15833] asadminenv.conf is included in distributions but not used Created: 04/Feb/11  Updated: 07/Apr/11  Resolved: 21/Feb/11

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

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

Tags: 3_1-exclude

 Description   

From a peek at the code this file does not appear to be referred to anywhere but in some upgrade code.
If its not used, why is it part of an installation in the first place?

Within support, when you are supporting multiple versions (I have 30+ installs on a machine) pretty much every domain is custom and putting the environment variable settings in the asadminenv.conf was a simple way of recording key config information and made administering and making changes to a particular install's domain simpler.

Environment variables are still supported, so I can set: AS_ADMIN_PORT, for example, but shouldn't the contents of the asadminenv.conf be read in and used as initial values that are then either overridden from first the environment, or by a command line argument.

If the use of the asadminenv.conf file is deprecated is that documented? There's no mention in the asadmin --help man page.

At the vary least if it is deprecated add a comment to the asadminenv.conf file to say so and make it clear that its contents are not used (though that won't help a customer that upgrades from 2.x to 3.1 and wonders why their settings aren't being used).

Personally I'd like it to stay and work as it did in 2.x - it was a very handy addition to 2.x and it'll be a shame to see it go.



 Comments   
Comment by Tom Mueller [ 04/Feb/11 ]

Agreed that the asadminenv.conf file is not used in v3 and should be removed from the distribution.

I have not found any mention of this file in either the 2.1 or 3.0 documentation for the asadmin command. Looked in these places:

3.0.1: http://download.oracle.com/docs/cd/E19798-01/821-1758/6nmnj7q2l/index.html
2.1.1: http://download.oracle.com/docs/cd/E19879-01/820-4332/6nfq9891d/index.html

So this appears to have been an undocumented feature, so it isn't surprising that there is no documentation that it went away.

In GlassFish 3.1, the glassfish/config/asenv.conf file can be used set environment variables for the asadmin command because the asadmin shell script sources asenv.conf. For example, to set the default port used by asadmin, add this to the file:

export AS_ADMIN_PORT=4849

Given this, the asadminenv.conf file is not needed anymore.

Comment by tecknobabble [ 04/Feb/11 ]

The asadminenv.conf was mentioned in the online help for the admin console.

Its not easy to provide a link to a copy as a result but if you logged into a 2.x domain, went to the help, the the "Application Server Profiles" and "To Create a Domain With a Specific Profile" both made a small mention about the asadminenv.conf file as the file that contained the setting for the default profile the asadmin create-domain command would use if there was no --profile <profile>.

But since the asenv.conf can be used then that's fine. It would save confusion if the asadminenv.conf file is removed from the distribution.

Comment by Tom Mueller [ 21/Feb/11 ]

Fixed in revision 45195 on the trunk.
The asadminenv.conf file has been removed from the distribution.





[GLASSFISH-6620] make it easy to directory deploy web apps that have an ejb-jar in lib Created: 22/Oct/08  Updated: 07/Apr/11  Resolved: 23/Mar/11

Status: Resolved
Project: glassfish
Component/s: deployment
Affects Version/s: V3
Fix Version/s: 3.1.1_b01

Type: Improvement Priority: Critical
Reporter: vince kraemer Assignee: Tim Quinn
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 6,620

 Description   

directory deployment is a "developer" feature.

It would be great to be able to put an exploded ejb-jar in the WEB-INF/lib
directory... not just a packaged jar... since this could eliminate 'package the
jar' steps out of a developer's build and deploy processing/ant scripts.



 Comments   
Comment by Anissa Lam [ 22/Oct/08 ]

add cc.

Comment by Hong Zhang [ 23/Mar/11 ]

Yes, I think we do support the directory deployment for this case now. A recent fix for this is http://java.net/jira/browse/GLASSFISH-16216





[GLASSFISH-3525] user image rotation code cause GF server global crash when VM is not headless enabled (security impact) Created: 23/Aug/07  Updated: 07/Apr/11  Resolved: 28/Feb/11

Status: Resolved
Project: glassfish
Component/s: configuration
Affects Version/s: 9.1pe
Fix Version/s: 3.1.1_b01

Type: Bug Priority: Major
Reporter: bjb 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: Linux


Issuezilla Id: 3,525
Tags: 3_1-exclude

 Description   

On 91build33 with JDK1.6.0.2 on Linux x586 (headless ?), applying rotation will
cause GF to stop (!!).

This is a "security" issue as a user code could cause denial of service y
auto-stoping an appserver.

The exact reason of this unexpected stop (crash ?) has not been investigated
yet. But a known workaround is to use the headlessmode by adding
-Djava.awt.headless=true to the GF VM start parameters !

The problem is always reproductible. The workaround fix the problem.

Could you add BY DEFAULT headless enabling property for the VM to GF
configuration. AFAIK, I see no reason not to be in headless mode for an
application server

Here is the code that cause the issue, server is crashing on .filter() :

/**

  • Apply a quadrant centered rotation to the source image
  • @param originalImage The source image
  • @param numQuadrants Number of quadrant rotations
  • @return The rotated image
    */
    public BufferedImage rotate(BufferedImage originalImage, int numQuadrants){
    AffineTransform tx =
    AffineTransform.getQuadrantRotateInstance(numQuadrants,originalImage.getWidth()
    / 2, originalImage.getHeight() / 2);
    AffineTransformOp op = new AffineTransformOp(tx,
    AffineTransformOp.TYPE_BILINEAR);
    Rectangle rect = op.getBounds2D(originalImage).getBounds();
    BufferedImage result = new BufferedImage(rect.width, rect.height,
    BufferedImage.TYPE_INT_ARGB);
    switch (numQuadrants & 3) { //case 0 : DO NOTHING case 1 : tx.translate(rect.getX(), -rect.getY()); op = new AffineTransformOp(tx,AffineTransformOp.TYPE_BILINEAR); break; //case 2 : DO NOTHING case 3: tx.translate(-rect.getX(), rect.getY()); op = new AffineTransformOp(tx,AffineTransformOp.TYPE_BILINEAR); break; }

//return op.filter(originalImage,
op.createCompatibleDestImage(originalImage, null) );
return op.filter(originalImage, result );
}



 Comments   
Comment by km [ 23/Aug/07 ]

Interesting. I am confused however. The Java Blueprints that run on top of
GlassFish (petstore example) uses this call to filter, I believe. (See:
/petstore/util/ImageScaler.java in Petstore by downloading the source for
blueprints – go to blueprints.dev.java.net or use GlassFish Update Center).

So, is there a real need to have this by default? Sorry, I need help
understanding why this is needed by default.

Mark Basler: Can you comment on the issue? Do you actually set this property
when configuring blueprints on GlassFish?

Also, I am marking this as a P3 since work-around exists.

Comment by basler [ 23/Aug/07 ]

What version of petstore is being used. I checked the cvs log and can't find
the example section of code anywhere, including
com.sun.javaee.blueprints.petstore.util.ImageScaler.

Anyways, the only place the ImageScaler is used is in the
com.sun.javaee.blueprints.petstore.controller.FileUploadBean which any
exceptions thrown are caught in a try/catch block and logged.

If Glassfish stops when AffineTransformOp's filter's method is called, then I
would think this is a JDK problem.

Have you tried with other versions of the JDK on your linux box?

Comment by Tom Mueller [ 28/Feb/11 ]

Fixed on the trunk in revision 45332.





[GLASSFISH-13826] Remove hard runtime dependency of web-glue on CDI Created: 06/Oct/10  Updated: 07/Apr/11  Resolved: 04/Mar/11

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

Type: Improvement Priority: Major
Reporter: Snjezana Sevo-Zenzerovic Assignee: Shing Wai Chan
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issue Links:
Dependency
blocks GLASSFISH-11335 glassfish-web has a runtime dependenc... Resolved
Issuezilla Id: 13,826

 Description   

From the parent issue 11335:

<quote>
The IPS glassfish-web package includes web-glue.jar which imports
javax.enterprise.inject.spi;version="1.0"

The implementation for javax.enterprise.inject.spi is part of glassfish-jcdi
(weld-osgi-bundle.jar in fact).

While Weld/Mojarra are not started if not needed, there should either be an
explicit dependency between glassfish-web and glassfish-jcdi packages (not a
good idea) or the hard runtime dependency on Weld/CDI should be removed.
</quote>

So, please evaluate whether it is possible to remove hard dependency of web-glue
on weld-osgi-bundle.jar so that web container can function normally if CDI is
not used.



 Comments   
Comment by Sivakumar Thyagarajan [ 07/Oct/10 ]

I am not sure if the the JCDI bundle can be removed from a web-profile as the
original issue 11335 seems to suggest. There is an explicit dependency between
web-glue and weld-osgi-bundle as the BeanManager is used to get the CDI
ELResolver to allow the usage of contextual CDI named bean references in JSP ELs.

So, if a JSP application that is CDI-enabled is deployed to a web-profile
implementation with the weld bundle removed, EL references to CDI beans would
fail. Marking this as b7 for now as part of the scrubbing process. Will update
the issue based on further discussion with the JSP and JSF experts.

Comment by Snjezana Sevo-Zenzerovic [ 07/Oct/10 ]

Just to clarify the actual requirement: if CDI-enabled application gets deployed
to a customized installation where CDI package content has been removed, server
is perfectly free to fail The goal is to have normal behavior of the server
in such installation as long as deployed applications do not use CDI.

Adding Alexis as the submitter of the original issue to the cc list...

Comment by Sivakumar Thyagarajan [ 07/Oct/10 ]

I understand your requirement. However this would need to be a change on the
weld-glue layer. web-glue needs to express an optional dependency on BeanManager
API and handle it accordingly. Requesting the web-tier (Rajiv) team to look into
this.

Comment by Shing Wai Chan [ 18/Oct/10 ]

Per discussion with Alexis Moussine-Pouchkine, we will change this into RFE.

Comment by Shing Wai Chan [ 04/Mar/11 ]

Sending common/container-common/pom.xml
Sending common/container-common/src/main/java/com/sun/enterprise/container/common/spi/JCDIService.java
Sending web/web-glue/pom.xml
Sending web/web-glue/src/main/java/com/sun/enterprise/web/WebContainer.java
Sending web/web-glue/src/main/java/com/sun/enterprise/web/WebModuleListener.java
Sending web/weld-integration/src/main/java/org/glassfish/weld/services/JCDIServiceImpl.java
Transmitting file data ......
Committed revision 45409.





[GLASSFISH-15818] Default target should be DAS -- especially if no other targets exist Created: 03/Feb/11  Updated: 07/Apr/11  Resolved: 24/Mar/11

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

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

Tags: 3_1-exclude

 Description   

C:\temp>asadmin list-network-listeners
Enter the value for the target operand>

– But I only have one target, DAS! It is pointless busy-work to force me to enter the name of the DAS server element. What if I don't happen to know that the name is "server"? "das" certainly won't work.

We should make the commands easy to use for the simplest configurations.

Recommended Fix: Set the default for the target option to "server"

Note: I ran into this while attempting to upgrade an real website to 3.1

I don't know if this bug should go to Grizzly or Admin – so I'm setting to Admin for now...



 Comments   
Comment by Nazrul [ 03/Feb/11 ]

Justin owns list-network-listeners command.

Comment by marina vatkina [ 03/Feb/11 ]

It would be nice if we could default on some other admin commands (like stop/start-cluster for a single cluster)

Comment by Justin Lee [ 24/Mar/11 ]

fix for http://java.net/jira/browse/GLASSFISH-15818

File summary : 1 files affected in 1 modules.
Modules affected : admin

Module [admin]:
1 Modified files:
src/main/java/org/glassfish/web/admin/cli/ListNetworkListeners.java 42265=>45721

Committed at Mar 24, 2011 8:59:11 PM

Comment by Justin Lee [ 25/Mar/11 ]

a better fix for http://java.net/jira/browse/GLASSFISH-15818. caught a similar failure in list-protocols.

File summary : 2 files affected in 1 modules.
Modules affected : admin

Module [admin]:
2 Modified files:
src/main/java/org/glassfish/web/admin/cli/ListNetworkListeners.java 45721=>45726
src/main/java/org/glassfish/web/admin/cli/ListProtocols.java 42265=>45726

Committed at Mar 25, 2011 8:19:33 AM





[GLASSFISH-15953] Web Embedded API support for security related configuration for webapp Created: 10/Feb/11  Updated: 07/Apr/11  Resolved: 01/Mar/11

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

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


 Description   

Web Embedded API support for web application security related configuration such as login configuration, web resource collection, and security constraints.



 Comments   
Comment by Nithya Ramakrishnan [ 23/Feb/11 ]

Can you please elucidate about the requirement. Support for all that you mention is available in the embedded mode even in 3.1, as in-memory data.

Comment by Amy Roh [ 23/Feb/11 ]

The description should read "Web Embedded API programmatic support for web application security related configuration". The summary and description have been changed to be more clear.

Comment by Amy Roh [ 01/Mar/11 ]

Fixed in svn 45210 and 45283.





[GLASSFISH-15982] Log Viewer passing wrong file name to the backend code... Created: 14/Feb/11  Updated: 07/Apr/11  Resolved: 10/Mar/11

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

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

All


Tags: 3-1_next, 3_1-exclude

 Description   

When user views rotated server log file for any instances and now change instance drop down value, it passes old log file name to the back end code.

e.g.
Server having two log files.

1. server.log
2. server.log_rotated_log_file

in1 having two log files.

1. server.log
2. in1_server.log_rotated_log_file

Now user opens log viewer and viewing instance 'server' log file is 'server.log_rotated_log_file'. It gives correct output. Now user changes instance drop down to 'in1' and at that time admin gui passes wrong file name to back end code. It passes instance name as 'in1' and log file name as 'server.log_rotated_log_file' which are totally wrong and mismatching.

Need following changes to avoid:
When user changes drop down for instance admin gui must have to pass value as server.log as file name. Don't pass any rotated log file name when user changes instance drop down value.



 Comments   
Comment by sirajg [ 10/Mar/11 ]

Diffs :
— src/main/resources/logViewer/logViewer.jsf (revision 45406)
+++ src/main/resources/logViewer/logViewer.jsf (working copy)
@@ -354,6 +354,7 @@
gf.getMapKeys(Map="#

{requestScope.servers.data.extraProperties.childResources}

" Keys="#

{requestScope.servers}

");
</ui:event>
<ui:event type="command">
+ setAttribute(key="logFile", value="#

{null}

");
gf.navigate(page="#

{request.contextPath}

/common/logViewer/logViewer.jsf");
</ui:event>





[GLASSFISH-16136] For WARs in EARs web sessions are not retained after redeploy Created: 03/Mar/11  Updated: 07/Apr/11  Resolved: 07/Mar/11

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

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

Windows XP


Attachments: File TestEAR.ear     File TestWeb.war    
Tags: http_sessions, keep_state, sessions, web_sessions

 Description   

If an EAR application, containing a WAR module is deployed and then the same EAR is redeployed the web sessions are lost although the option "Keep state" was checked in admin GUI before redeployment.

I am attaching a simple WAR and EAR to demonstrate the issue. The EAR is nothing more but a container for the same WAR.
Steps to reproduce.
1. Deploy TestEAR.ear
2. Open the TestWeb index page in a web browser ( http://localhost:8080/TestWeb/ ). You will see a webpage with a simple "Counter: 0"
3. Refresh the page a couple of times. You will see the counter increasing.
4. Redeploy the application from GUI with "Keep state" on. (I also tested with asadmin keepSessions=true with the same result)
5. Refresh the page in the browser again. You will see that the counter is reset to 0.

If you go through the above steps with the WAR file ( TestWeb.war ) instead of the EAR you should see that the counter is not reset in step 5. The problem I describe is for version 3.1, it does not seem to occur for v3-final even with the EAR redeployment.



 Comments   
Comment by Shing Wai Chan [ 07/Mar/11 ]

Sending web-glue/src/main/java/com/sun/enterprise/web/WebApplication.java
Transmitting file data .
Committed revision 45422.





[GLASSFISH-16175] When a domain was down, restart-domain did not start it, but created a wrong error message. Created: 08/Mar/11  Updated: 07/Apr/11  Resolved: 16/Mar/11

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

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


 Description   

Build 43, Solaris 10 Sparc. Created a domain, started domain and stopped domain, then tried to execute:
==================================================================
asadmin restart-domain --debug=true --domaindir=/opt/glassfish3/glassfish/domains --force=false --kill=true domain2

Invalid option: --force=false
Usage: asadmin [asadmin-utility-options] restart-domain
[-debug[=<debug(default:false)>]] [-force[=<force(default:true)>]]
[--kill[=<kill(default:false)>]] [--domaindir <domaindir>]
[?|-help[=<help(default:false)>]] [domain_name]
Server is not running, will attempt to start it...
Command restart-domain failed.

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

If to remove from the commnd line --force=false it start to comlain about --kill and so on.

I believe that when domain is down the restart-domain command has to start it. And in any case should not create a wrong error message like: "Invalid option: --force=false"



 Comments   
Comment by Byron Nevins [ 09/Mar/11 ]

THe problem is in this method in RestartDomainCommand:

@Override
protected int dasNotRunning(boolean local) throws CommandException

{ if (!local) throw new CommandException( Strings.get("restart.dasNotRunningNoRestart")); logger.warning(strings.get("restart.dasNotRunning")); CLICommand cmd = habitat.getComponent(CLICommand.class, "start-domain"); // XXX - assume start-domain accepts all the same options return cmd.execute(argv); }

}

See the "XXX" comment? The comment's hopes are dashed. They do indeed have different options.

Comment by Bill Shannon [ 10/Mar/11 ]

When --force and --kill were added to restart-domain, it broke
the assumption that all arguments to restart-domain were valid
arguments to start-domain.

Rather than passing all the original arguments through, restart-domain
needs to pass through only the options that are valid for start-domain.

The same problem exists with restart-local-instance/start-local-instance.
I fixed both.

Comment by easarina [ 16/Mar/11 ]

Was used latest continuous build. The problem still is not fixed there. Were seen such messages during restarting of domain and local instance, that were not running.

asadmin restart-domain --debug=true --domaindir=$S1AS_HOME/domains --force=true --kill=true domain4
Server is not running, will attempt to start it...
Command start-domain only accepts one operand
Usage: asadmin [asadmin-utility-options] restart-domain
[-debug[=<debug(default:false)>]] [-force[=<force(default:true)>]]
[--kill[=<kill(default:false)>]] [--domaindir <domaindir>]
[?|-help[=<help(default:false)>]] [domain_name]
Command restart-domain failed.

asadmin restart-local-instance --nodedir=$S1AS_HOME/nodes --node localhost-domain4 --debug=true --force=true --kill=true in42
Server is not running, will attempt to start it...
Command start-local-instance only accepts one operand
Usage: asadmin [asadmin-utility-options] restart-local-instance
[-debug[=<debug(default:false)>]] [-force[=<force(default:true)>]]
[--kill[=<kill(default:false)>]] [--nodedir <nodedir>] [--node <node>]
[?|-help[=<help(default:false)>]] [instance_name]
Command restart-local-instance failed.

Comment by Bill Shannon [ 16/Mar/11 ]

Oops. Forgot to add the command name to the argv passed to the start
command.





[GLASSFISH-3365] <BT6581137>typo in "sun-domain_1_3.dtd" file Created: 17/Jul/07  Updated: 07/Apr/11  Resolved: 28/Feb/11

Status: Resolved
Project: glassfish
Component/s: admin
Affects Version/s: 9.1pe
Fix Version/s: 3.1.1_b01

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

Operating System: Solaris
Platform: All


Issuezilla Id: 3,365
Tags: 3_1-exclude

 Description   

*********READ-ONLY Data from Bugtraq*********************
Inside SWAN :http://swsblweb1.central.sun.com:8080/CrPrint?id=6581137
Outside SWAN :http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6581137
**********READ-ONLY Data from Bugtraq Ends********
*********READ-ONLY Data from Bugtraq*********************
Description AS 9.1 PEbld. b55

There is a typo in sun-domain_1_3.dtd. For "DNS" lookup, dtd has "DNL" lookup. It should be "DNS"

<!-- http-access-log

attributes
iponly
if the IP address of the user agent should be specified or a
DNL lookup should be done

To reproduce:

  • open <install-dir>lib->dtds->sun-domain_1_3.dtd
  • Search for the above

**********READ-ONLY Data from Bugtraq Ends********
*********READ-ONLY Data from Bugtraq*********************
Evaluation Typo in comment.
**********READ-ONLY Data from Bugtraq Ends********
*********READ-ONLY Data from Bugtraq*********************
Justification Priority changed from [] to [3-Medium]typo in XXXXXX 2007-07-16 19:42:17 GMT

**********READ-ONLY Data from Bugtraq Ends********
*********READ-ONLY Data from Bugtraq*********************
Suggested Fix Replace "DNL" with "DNS"
**********READ-ONLY Data from Bugtraq Ends********



 Comments   
Comment by sanandal [ 11/Jan/09 ]

"Reclassifying as P4 because this issue is not deemed "must fix" for this v2.1
release whose primary release driver is SailFin.
This issue will be scrubbed after this release and will be given the right
priority for the next release."

Comment by Tom Mueller [ 28/Feb/11 ]

Fixed in revision 45331





[GLASSFISH-6271] asadmin create-jdbc-connection-pool problem with blank password Created: 23/Sep/08  Updated: 07/Apr/11  Resolved: 06/Apr/11

Status: Resolved
Project: glassfish
Component/s: jdbc
Affects Version/s: 9.1peur2
Fix Version/s: 3.1.1_b01

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

Operating System: All
Platform: Sun


Issue Links:
Duplicate
duplicates GLASSFISH-12188 Connections with empty password produ... Resolved
Issuezilla Id: 6,271
Tags: 3_1-exclude

 Description   

Using asadmin create-jdbc-connection-pool with --property
"username=sa:password=:database=jdbc:hsqldb:lportal", asadmin does not accept
the blank password property. I have tried adding empty quotes but that does not
work either. Bumping up the priority based on age and the lack of a good workaround.



 Comments   
Comment by sanandal [ 11/Jan/09 ]

"Reclassifying as P4 because this issue is not deemed "must fix" for this v2.1
release whose primary release driver is SailFin.
This issue will be scrubbed after this release and will be given the right
priority for the next release."

Comment by Tom Mueller [ 14/Feb/11 ]

This problem still exists in GlassFish 3.1.

The only work-around for this problem is to create the pool with a different password and then manually edit the domain.xml file to set the password to a blank. Using the "asadmin set" command to change th