[GLASSFISH-19636] configure-jms-cluster for an enhanced PostgreSQL-backed JMS cluster is broken Created: 04/Feb/13  Updated: 05/Feb/13  Resolved: 05/Feb/13

Status: Resolved
Project: glassfish
Component/s: jms
Affects Version/s: 3.1.2.2
Fix Version/s: 4.0_b71

Type: Bug Priority: Major
Reporter: Michael van der Westhuizen Assignee: David Zhao
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Linux x86_64 (Ubuntu 12.10)
java version "1.7.0_13"
Java(TM) SE Runtime Environment (build 1.7.0_13-b20)
Java HotSpot(TM) 64-Bit Server VM (build 23.7-b01, mixed mode)


Tags: admin-cli

 Description   

There's a typo in the CLI handler for configure-jms-cluster that insists that the user type "postgressql" for a PostgreSQL database (note the extra "s"). This breaks IMQ. The attached patch addresses the problem and allows the following to work:

sudo -u glassfish /opt/glassfish3/bin/asadmin --passwordfile passwords.txt --host 172.16.252.251 --port 4048 --user admin configure-jms-cluster --clustertype=enhanced --dbvendor postgresql --dbuser openmq --dburl jdbc:postgresql://172.16.252.252:5432/openmq --property imq.persist.jdbc.postgresql.opendburl=jdbc\\:postgresql\\://172.16.252.252\\:5432/openmq:imq.persist.jdbc.postgresql.createdburl=jdbc\\:postgresql\\://172.16.252.252\\:5432\/openmq c1

After applying this patch I get a working clustered OpenMQ.



 Comments   
Comment by Michael van der Westhuizen [ 04/Feb/13 ]

It appears that I can't figure out how to attach a patch...

[michael@heresy glassfish]$ cat configure-jms-cluster-postgresql.patch
Index: jms/admin/src/main/java/org/glassfish/jms/admin/cli/ConfigureJMSCluster.java
===================================================================
— jms/admin/src/main/java/org/glassfish/jms/admin/cli/ConfigureJMSCluster.java (revision 59070)
+++ jms/admin/src/main/java/org/glassfish/jms/admin/cli/ConfigureJMSCluster.java (working copy)
@@ -77,7 +77,7 @@
//@TargetType(

{CommandTarget.CLUSTER}

)

public class ConfigureJMSCluster implements AdminCommand {

  • final private static String SUPPORTED_DB_VENDORS = "oracle|postgressql|mysql|derby|db2";
    + final private static String SUPPORTED_DB_VENDORS = "oracle|postgresql|mysql|derby|db2";
    final private static LocalStringManagerImpl localStrings = new LocalStringManagerImpl(ConfigureJMSCluster.class);
    final private static String MASTER_BROKER = "masterbroker";
    final private static String SHARED_DB = "shareddb";
Comment by David Zhao [ 05/Feb/13 ]

Fixed in 4.0





[GLASSFISH-19629] Unable to deploy EAR archive in embedded mode with latest glassfish-embedded-all.jar Created: 03/Feb/13  Updated: 04/Feb/13  Resolved: 04/Feb/13

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

Type: Bug Priority: Blocker
Reporter: Bhavanishankar Assignee: Bhavanishankar
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-19596 ServiceLocator#getService(ArchiveType... Resolved

 Description   

When trying to deploy a EAR file in embedded mode with the latest embedded uber jar i..e, glassfish-embedded-all-4.0-SNAPSHOT.jar, it fails with the following error:

Feb 03, 2013 4:36:23 AM ContainerStarter startContainer
INFO: Snifer org.glassfish.javaee.full.deployment.EarSniffer@188b9 set up following modules: []
Feb 03, 2013 4:36:23 AM org.glassfish.api.ActionReport failure
SEVERE: Exception while deploying the app [sear]
Feb 03, 2013 4:36:23 AM com.sun.enterprise.v3.server.ApplicationLifecycle deploy
SEVERE: Exception during lifecycle processing
java.lang.IllegalArgumentException: type cannot be null
	at com.sun.enterprise.deployment.Application.getModuleDescriptorsByType(Application.java:1033)
	at com.sun.enterprise.deployment.archivist.ApplicationArchivist.sortModules(ApplicationArchivist.java:648)
	at com.sun.enterprise.deployment.archivist.ApplicationArchivist.readModulesDescriptors(ApplicationArchivist.java:540)
	at com.sun.enterprise.deployment.archivist.ApplicationArchivist.openWith(ApplicationArchivist.java:229)
	at com.sun.enterprise.deployment.archivist.ApplicationFactory.openWith(ApplicationFactory.java:232)
	at org.glassfish.javaee.core.deployment.DolProvider.processDOL(DolProvider.java:188)
	at org.glassfish.javaee.core.deployment.DolProvider.load(DolProvider.java:222)
	at org.glassfish.javaee.core.deployment.DolProvider.load(DolProvider.java:96)
	at com.sun.enterprise.v3.server.ApplicationLifecycle.loadDeployer(ApplicationLifecycle.java:879)
	at com.sun.enterprise.v3.server.ApplicationLifecycle.setupContainerInfos(ApplicationLifecycle.java:819)
	at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:374)
	at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
	at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:491)


 Comments   
Comment by Bhavanishankar [ 03/Feb/13 ]

This is because of change in implementation of ApplicationArchivist.java in GlassFish 4.0

In 4.0, DOLUtils.carType() is used to obtain the CAR module type instead of how it was done in 3.x version where XModuleType.CAR was used.

In 3.x, XModuleType.CAR was just an enum/constant value. However, in 4.0, the DOLUtils.carType() computes the CAR module type by doing:


serviceLocator.getService(ArchiveType.class, "car");

The above code returns a non null module type value only if the application server distribution contains the container that could handle the CAR modules.

But glassfish-embedded-all.jar does not bundle the appclient container so the above code return NULL. Hence the EAR application fails.

Comment by Bhavanishankar [ 03/Feb/13 ]

This issue can be reproduced by running appserver/tests/embedded/scatteredarchive test.

Comment by Bhavanishankar [ 04/Feb/13 ]

Fixed with check-in rev 59069.





[GLASSFISH-19600] Improved error message when MDB destination not found Created: 29/Jan/13  Updated: 30/Jan/13  Resolved: 30/Jan/13

Status: Resolved
Project: glassfish
Component/s: jms
Affects Version/s: 4.0_b72_EE7MS4
Fix Version/s: 4.0_b71

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


 Description   

In most versions of GlassFish including b72, if you define a MDB whose
mappedName attribute is set to "jms/aaa", but there is no destination
bound to that location (and the destination is not configured any other
way), then you get the message "JMS resource not created".

This word "created" is misleading here since it suggests that this code
is creating something. It should give a similar message to the case
where destinationLookup specifies a bad name: something like
"Invalid destination jms/aaa for MDB: JNDI name not found".



 Comments   
Comment by David Zhao [ 30/Jan/13 ]

Fixed.





[GLASSFISH-19590] ClassNotFoundException: com.sun.enterprise.ee.cms.core.CallBack/GroupManagementService running Embedded Created: 25/Jan/13  Updated: 28/Jan/13  Resolved: 28/Jan/13

Status: Resolved
Project: glassfish
Component/s: embedded
Affects Version/s: 4.0_b70
Fix Version/s: 4.0_b71

Type: Bug Priority: Major
Reporter: Amy Roh Assignee: Romain Grécourt
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Embedded builds are failing due to ClassNotFoundException: com.sun.enterprise.ee.cms.core package classes.

Jan 25, 2013 3:59:51 PM com.sun.enterprise.web.WebContainer loadSystemDefaultWebModules
INFO: Virtual server server loaded default web module
Jan 25, 2013 3:59:52 PM org.glassfish.internal.data.ModuleInfo load
SEVERE: Exception while invoking class org.glassfish.ejb.startup.EjbDeployer load method
java.lang.RuntimeException: EJB Container initialization error
at org.glassfish.ejb.startup.EjbApplication.loadContainers(EjbApplication.java:234)
at org.glassfish.ejb.startup.EjbDeployer.load(EjbDeployer.java:291)
at org.glassfish.ejb.startup.EjbDeployer.load(EjbDeployer.java:99)
at org.glassfish.internal.data.ModuleInfo.load(ModuleInfo.java:190)
at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:278)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:494)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:491)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:529)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:525)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:356)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:524)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:548)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1425)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1500(CommandRunnerImpl.java:109)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1760)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1676)
at com.sun.enterprise.admin.cli.embeddable.DeployerImpl.deploy(DeployerImpl.java:133)
at com.sun.enterprise.admin.cli.embeddable.DeployerImpl.deploy(DeployerImpl.java:109)
at org.glassfish.maven.PluginUtil.doDeploy(PluginUtil.java:108)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.glassfish.maven.AbstractDeployMojo.doDeploy(AbstractDeployMojo.java:259)
at org.glassfish.maven.DeployMojo.execute(DeployMojo.java:69)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
Caused by: java.lang.RuntimeException: IIOP Protocol Manager initialization failed. Possible cause is that ORB is not available in this container
at com.sun.ejb.containers.BaseContainer.initializeProtocolManager(BaseContainer.java:827)
at org.glassfish.ejb.mdb.MessageBeanContainer.<init>(MessageBeanContainer.java:160)
at org.glassfish.ejb.mdb.MessageBeanContainerFactory.createContainer(MessageBeanContainerFactory.java:61)
at org.glassfish.ejb.startup.EjbApplication.loadContainers(EjbApplication.java:221)
... 47 more
Caused by: java.lang.NoClassDefFoundError: com/sun/enterprise/ee/cms/core/CallBack
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:791)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:449)
at java.net.URLClassLoader.access$100(URLClassLoader.java:71)
at java.net.URLClassLoader$1.run(URLClassLoader.java:361)
at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
at java.lang.ClassLoader.loadClass(ClassLoader.java:423)
at java.lang.ClassLoader.loadClass(ClassLoader.java:356)
at org.glassfish.enterprise.iiop.impl.GlassFishORBManager.setFOLBProperties(GlassFishORBManager.java:423)
at org.glassfish.enterprise.iiop.impl.GlassFishORBManager.initORB(GlassFishORBManager.java:459)
at org.glassfish.enterprise.iiop.impl.GlassFishORBManager.getORB(GlassFishORBManager.java:264)
at org.glassfish.enterprise.iiop.impl.GlassFishORBFactoryImpl.createORB(GlassFishORBFactoryImpl.java:93)
at org.glassfish.enterprise.iiop.api.GlassFishORBHelper.getORB(GlassFishORBHelper.java:163)
at org.glassfish.enterprise.iiop.api.GlassFishORBHelper.getProtocolManager(GlassFishORBHelper.java:231)
at com.sun.ejb.containers.BaseContainer.initializeProtocolManager(BaseContainer.java:824)
... 50 more
Caused by: java.lang.ClassNotFoundException: com.sun.enterprise.ee.cms.core.CallBack
at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
at java.lang.ClassLoader.loadClass(ClassLoader.java:423)
at java.lang.ClassLoader.loadClass(ClassLoader.java:356)
... 68 more

test(org.glassfish.tests.embedded.web.EmbeddedAddWebListenerTest) Time elapsed: 1.358 sec <<< ERROR!
MultiException stack 1 of 4
java.lang.IllegalStateException: Error while getting fields of class org.glassfish.gms.admin.GMSAnnounceBeforeStartClusterCommand
at org.jvnet.hk2.internal.Utilities.getAllFieldKeys(Utilities.java:746)
at org.jvnet.hk2.internal.Utilities.getAllFields(Utilities.java:725)
at org.jvnet.hk2.internal.Utilities.findInitializerFields(Utilities.java:1012)
at org.jvnet.hk2.internal.ClazzCreator.<init>(ClazzCreator.java:121)
at org.jvnet.hk2.internal.SystemDescriptor.reify(SystemDescriptor.java:574)
at org.jvnet.hk2.internal.ServiceLocatorImpl.reifyDescriptor(ServiceLocatorImpl.java:362)
at org.jvnet.hk2.internal.ServiceLocatorImpl.narrow(ServiceLocatorImpl.java:1634)
at org.jvnet.hk2.internal.ServiceLocatorImpl.internalGetAllServiceHandles(ServiceLocatorImpl.java:1017)
at org.jvnet.hk2.internal.ServiceLocatorImpl.getAllServiceHandles(ServiceLocatorImpl.java:964)
at org.jvnet.hk2.internal.ServiceLocatorImpl.getAllServiceHandles(ServiceLocatorImpl.java:953)
at com.sun.enterprise.v3.admin.SupplementalCommandExecutorImpl.getSupplementalCommandsList(SupplementalCommandExecutorImpl.java:165)
at com.sun.enterprise.v3.admin.SupplementalCommandExecutorImpl.listSuplementalCommands(SupplementalCommandExecutorImpl.java:90)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1114)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1500(CommandRunnerImpl.java:109)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1760)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1676)
at com.sun.enterprise.admin.cli.embeddable.DeployerImpl.deploy(DeployerImpl.java:133)
at com.sun.enterprise.admin.cli.embeddable.DeployerImpl.deploy(DeployerImpl.java:109)
at org.glassfish.tests.embedded.web.EmbeddedAddWebListenerTest.test(EmbeddedAddWebListenerTest.java:128)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.junit.internal.runners.TestMethodRunner.executeMethodBody(TestMethodRunner.java:99)
at org.junit.internal.runners.TestMethodRunner.runUnprotected(TestMethodRunner.java:81)
at org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34)
at org.junit.internal.runners.TestMethodRunner.runMethod(TestMethodRunner.java:75)
at org.junit.internal.runners.TestMethodRunner.run(TestMethodRunner.java:45)
at org.junit.internal.runners.TestClassMethodsRunner.invokeTestMethod(TestClassMethodsRunner.java:66)
at org.junit.internal.runners.TestClassMethodsRunner.run(TestClassMethodsRunner.java:35)
at org.junit.internal.runners.TestClassRunner$1.runUnprotected(TestClassRunner.java:42)
at org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34)
at org.junit.internal.runners.TestClassRunner.run(TestClassRunner.java:52)
at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140)
at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:165)
at org.apache.maven.surefire.Surefire.run(Surefire.java:107)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:289)
at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:993)
Caused by: java.lang.NoClassDefFoundError: Lcom/sun/enterprise/ee/cms/core/GroupManagementService;
at java.lang.Class.getDeclaredFields0(Native Method)
at java.lang.Class.privateGetDeclaredFields(Class.java:2308)
at java.lang.Class.getDeclaredFields(Class.java:1760)
at org.jvnet.hk2.internal.Utilities$2.run(Utilities.java:176)
at org.jvnet.hk2.internal.Utilities$2.run(Utilities.java:172)
at java.security.AccessController.doPrivileged(Native Method)
at org.jvnet.hk2.internal.Utilities.getDeclaredFields(Utilities.java:172)
at org.jvnet.hk2.internal.Utilities.getAllFieldKeys(Utilities.java:742)
... 42 more
Caused by: java.lang.ClassNotFoundException: com.sun.enterprise.ee.cms.core.GroupManagementService
at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
at java.lang.ClassLoader.loadClass(ClassLoader.java:423)
at java.lang.ClassLoader.loadClass(ClassLoader.java:356)
at org.apache.maven.surefire.booter.IsolatedClassLoader.loadClass(IsolatedClassLoader.java:103)
... 50 more
MultiException stack 2 of 4
java.lang.IllegalArgumentException: Errors were discovered while reifying SystemDescriptor(
implementation=org.glassfish.gms.admin.GMSAnnounceBeforeStartClusterCommand
name=_gms-announce-before-start-cluster-command
contracts=

{org.glassfish.gms.admin.GMSAnnounceBeforeStartClusterCommand,org.glassfish.api.admin.AdminCommand}

scope=org.glassfish.hk2.api.PerLookup
qualifiers=

{org.glassfish.api.admin.Supplemental,org.glassfish.api.admin.RestEndpoints}
descriptorType=CLASS
descriptorVisibility=NORMAL
metadata=target={start-cluster}
rank=0
loader=org.glassfish.hk2.bootstrap.impl.Hk2LoaderPopulatorPostProcessor$1@273b003e
proxiable=null
id=605
locatorId=0
identityHashCode=311229073
reified=false)
at org.jvnet.hk2.internal.SystemDescriptor.reify(SystemDescriptor.java:663)
at org.jvnet.hk2.internal.ServiceLocatorImpl.reifyDescriptor(ServiceLocatorImpl.java:362)
at org.jvnet.hk2.internal.ServiceLocatorImpl.narrow(ServiceLocatorImpl.java:1634)
at org.jvnet.hk2.internal.ServiceLocatorImpl.internalGetAllServiceHandles(ServiceLocatorImpl.java:1017)
at org.jvnet.hk2.internal.ServiceLocatorImpl.getAllServiceHandles(ServiceLocatorImpl.java:964)
at org.jvnet.hk2.internal.ServiceLocatorImpl.getAllServiceHandles(ServiceLocatorImpl.java:953)
at com.sun.enterprise.v3.admin.SupplementalCommandExecutorImpl.getSupplementalCommandsList(SupplementalCommandExecutorImpl.java:165)
at com.sun.enterprise.v3.admin.SupplementalCommandExecutorImpl.listSuplementalCommands(SupplementalCommandExecutorImpl.java:90)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1114)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1500(CommandRunnerImpl.java:109)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1760)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1676)
at com.sun.enterprise.admin.cli.embeddable.DeployerImpl.deploy(DeployerImpl.java:133)
at com.sun.enterprise.admin.cli.embeddable.DeployerImpl.deploy(DeployerImpl.java:109)
at org.glassfish.tests.embedded.web.EmbeddedAddWebListenerTest.test(EmbeddedAddWebListenerTest.java:128)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.junit.internal.runners.TestMethodRunner.executeMethodBody(TestMethodRunner.java:99)
at org.junit.internal.runners.TestMethodRunner.runUnprotected(TestMethodRunner.java:81)
at org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34)
at org.junit.internal.runners.TestMethodRunner.runMethod(TestMethodRunner.java:75)
at org.junit.internal.runners.TestMethodRunner.run(TestMethodRunner.java:45)
at org.junit.internal.runners.TestClassMethodsRunner.invokeTestMethod(TestClassMethodsRunner.java:66)
at org.junit.internal.runners.TestClassMethodsRunner.run(TestClassMethodsRunner.java:35)
at org.junit.internal.runners.TestClassRunner$1.runUnprotected(TestClassRunner.java:42)
at org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34)
at org.junit.internal.runners.TestClassRunner.run(TestClassRunner.java:52)
at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140)
at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:165)
at org.apache.maven.surefire.Surefire.run(Surefire.java:107)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:289)
at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:993)
MultiException stack 3 of 4
java.lang.IllegalStateException: Error while getting fields of class org.glassfish.gms.admin.GMSAnnounceBeforeStopClusterCommand
at org.jvnet.hk2.internal.Utilities.getAllFieldKeys(Utilities.java:746)
at org.jvnet.hk2.internal.Utilities.getAllFields(Utilities.java:725)
at org.jvnet.hk2.internal.Utilities.findInitializerFields(Utilities.java:1012)
at org.jvnet.hk2.internal.ClazzCreator.<init>(ClazzCreator.java:121)
at org.jvnet.hk2.internal.SystemDescriptor.reify(SystemDescriptor.java:574)
at org.jvnet.hk2.internal.ServiceLocatorImpl.reifyDescriptor(ServiceLocatorImpl.java:362)
at org.jvnet.hk2.internal.ServiceLocatorImpl.narrow(ServiceLocatorImpl.java:1634)
at org.jvnet.hk2.internal.ServiceLocatorImpl.internalGetAllServiceHandles(ServiceLocatorImpl.java:1017)
at org.jvnet.hk2.internal.ServiceLocatorImpl.getAllServiceHandles(ServiceLocatorImpl.java:964)
at org.jvnet.hk2.internal.ServiceLocatorImpl.getAllServiceHandles(ServiceLocatorImpl.java:953)
at com.sun.enterprise.v3.admin.SupplementalCommandExecutorImpl.getSupplementalCommandsList(SupplementalCommandExecutorImpl.java:165)
at com.sun.enterprise.v3.admin.SupplementalCommandExecutorImpl.listSuplementalCommands(SupplementalCommandExecutorImpl.java:90)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1114)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1500(CommandRunnerImpl.java:109)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1760)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1676)
at com.sun.enterprise.admin.cli.embeddable.DeployerImpl.deploy(DeployerImpl.java:133)
at com.sun.enterprise.admin.cli.embeddable.DeployerImpl.deploy(DeployerImpl.java:109)
at org.glassfish.tests.embedded.web.EmbeddedAddWebListenerTest.test(EmbeddedAddWebListenerTest.java:128)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.junit.internal.runners.TestMethodRunner.executeMethodBody(TestMethodRunner.java:99)
at org.junit.internal.runners.TestMethodRunner.runUnprotected(TestMethodRunner.java:81)
at org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34)
at org.junit.internal.runners.TestMethodRunner.runMethod(TestMethodRunner.java:75)
at org.junit.internal.runners.TestMethodRunner.run(TestMethodRunner.java:45)
at org.junit.internal.runners.TestClassMethodsRunner.invokeTestMethod(TestClassMethodsRunner.java:66)
at org.junit.internal.runners.TestClassMethodsRunner.run(TestClassMethodsRunner.java:35)
at org.junit.internal.runners.TestClassRunner$1.runUnprotected(TestClassRunner.java:42)
at org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34)
at org.junit.internal.runners.TestClassRunner.run(TestClassRunner.java:52)
at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140)
at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:165)
at org.apache.maven.surefire.Surefire.run(Surefire.java:107)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:289)
at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:993)
Caused by: java.lang.NoClassDefFoundError: Lcom/sun/enterprise/ee/cms/core/GroupManagementService;
at java.lang.Class.getDeclaredFields0(Native Method)
at java.lang.Class.privateGetDeclaredFields(Class.java:2308)
at java.lang.Class.getDeclaredFields(Class.java:1760)
at org.jvnet.hk2.internal.Utilities$2.run(Utilities.java:176)
at org.jvnet.hk2.internal.Utilities$2.run(Utilities.java:172)
at java.security.AccessController.doPrivileged(Native Method)
at org.jvnet.hk2.internal.Utilities.getDeclaredFields(Utilities.java:172)
at org.jvnet.hk2.internal.Utilities.getAllFieldKeys(Utilities.java:742)
... 42 more
Caused by: java.lang.ClassNotFoundException: com.sun.enterprise.ee.cms.core.GroupManagementService
at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
at java.lang.ClassLoader.loadClass(ClassLoader.java:423)
at java.lang.ClassLoader.loadClass(ClassLoader.java:356)
at org.apache.maven.surefire.booter.IsolatedClassLoader.loadClass(IsolatedClassLoader.java:103)
... 50 more
MultiException stack 4 of 4
java.lang.IllegalArgumentException: Errors were discovered while reifying SystemDescriptor(
implementation=org.glassfish.gms.admin.GMSAnnounceBeforeStopClusterCommand
name=_gms-announce-before-stop-cluster-command
contracts={org.glassfish.gms.admin.GMSAnnounceBeforeStopClusterCommand,org.glassfish.api.admin.AdminCommand}
scope=org.glassfish.hk2.api.PerLookup
qualifiers={org.glassfish.api.admin.Supplemental,org.glassfish.api.admin.RestEndpoints}

descriptorType=CLASS
descriptorVisibility=NORMAL
metadata=target=

{stop-cluster}

rank=0
loader=org.glassfish.hk2.bootstrap.impl.Hk2LoaderPopulatorPostProcessor$1@53501237
proxiable=null
id=606
locatorId=0
identityHashCode=769393564
reified=false)
at org.jvnet.hk2.internal.SystemDescriptor.reify(SystemDescriptor.java:663)
at org.jvnet.hk2.internal.ServiceLocatorImpl.reifyDescriptor(ServiceLocatorImpl.java:362)
at org.jvnet.hk2.internal.ServiceLocatorImpl.narrow(ServiceLocatorImpl.java:1634)
at org.jvnet.hk2.internal.ServiceLocatorImpl.internalGetAllServiceHandles(ServiceLocatorImpl.java:1017)
at org.jvnet.hk2.internal.ServiceLocatorImpl.getAllServiceHandles(ServiceLocatorImpl.java:964)
at org.jvnet.hk2.internal.ServiceLocatorImpl.getAllServiceHandles(ServiceLocatorImpl.java:953)
at com.sun.enterprise.v3.admin.SupplementalCommandExecutorImpl.getSupplementalCommandsList(SupplementalCommandExecutorImpl.java:165)
at com.sun.enterprise.v3.admin.SupplementalCommandExecutorImpl.listSuplementalCommands(SupplementalCommandExecutorImpl.java:90)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1114)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1500(CommandRunnerImpl.java:109)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1760)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1676)
at com.sun.enterprise.admin.cli.embeddable.DeployerImpl.deploy(DeployerImpl.java:133)
at com.sun.enterprise.admin.cli.embeddable.DeployerImpl.deploy(DeployerImpl.java:109)
at org.glassfish.tests.embedded.web.EmbeddedAddWebListenerTest.test(EmbeddedAddWebListenerTest.java:128)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.junit.internal.runners.TestMethodRunner.executeMethodBody(TestMethodRunner.java:99)
at org.junit.internal.runners.TestMethodRunner.runUnprotected(TestMethodRunner.java:81)
at org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34)
at org.junit.internal.runners.TestMethodRunner.runMethod(TestMethodRunner.java:75)
at org.junit.internal.runners.TestMethodRunner.run(TestMethodRunner.java:45)
at org.junit.internal.runners.TestClassMethodsRunner.invokeTestMethod(TestClassMethodsRunner.java:66)
at org.junit.internal.runners.TestClassMethodsRunner.run(TestClassMethodsRunner.java:35)
at org.junit.internal.runners.TestClassRunner$1.runUnprotected(TestClassRunner.java:42)
at org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34)
at org.junit.internal.runners.TestClassRunner.run(TestClassRunner.java:52)
at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140)
at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:165)
at org.apache.maven.surefire.Surefire.run(Surefire.java:107)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:289)
at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:993)



 Comments   
Comment by Amy Roh [ 28/Jan/13 ]

Missing classes are part of shoal-gms-api.jar. The hk2-locator/default file is not merged correct. Assign it to Romain to fix this packaging issue.

Comment by Amy Roh [ 28/Jan/13 ]

Fixed in 58828 & 58834.





[GLASSFISH-19586] Upgrade to Felix 4.0.3 Created: 25/Jan/13  Updated: 26/Jan/13  Resolved: 26/Jan/13

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

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


 Description   

We should upgrade to Felix 4.0.3 from 4.0.2.

It requires running various tests.



 Comments   
Comment by TangYong [ 26/Jan/13 ]

The updating result is as following:

1 Felix 4.0.3's updating

main/nucleus/pom.xml

<dependency>
<groupId>org.apache.felix</groupId>
<artifactId>org.apache.felix.main</artifactId>
<version>4.0.3</version>
</dependency>

2 distro's confirmation

1)main/nucleus/distributions/nucleus/target/stage/nucleus/osgi/felix/bin/felix.jar

[META-INF/MANIFEST.MF]
Bundle-Version: 4.0.3

2)main/appserver/distributions/glassfish/target/stage/glassfish3/glassfish/osgi/felix/bin/felix.jar

[META-INF/MANIFEST.MF]
Bundle-Version: 4.0.3

3 QL Test Result

After executing the following command,

D:\20130125\main\nucleus\tests\quicklook>mvn -Dnucleus.home=D:\20130125\main\nucleus\distributions\nucleus\target\stage\nucleus test

Although the following tests failed, NucleusStartStopTest is sucessful.

Failed tests:
testAdminCommandEndpoint(org.glassfish.nucleus.quicklook.RestTest)
testChildConfigBeanEndpoint(org.glassfish.nucleus.quicklook.RestTest)
testPostGetDelete(org.glassfish.nucleus.quicklook.RestTest)
testManagementEndpoint(org.glassfish.nucleus.quicklook.RestTest)

The above failed tests belong to org.glassfish.nucleus.quicklook.RestTest, and the following is detailed test result:

<?xml version="1.0" encoding="UTF-8"?>
<testng-results skipped="0" failed="4" total="15" passed="11">
<reporter-output>
</reporter-output>
<suite name="Command line suite" duration-ms="57359" started-at="2013-01-26T14:25:29Z" finished-at="2013-01-26T14:26:26Z">
<groups>
</groups>
<test name="Command line test" duration-ms="57359" started-at="2013-01-26T14:25:29Z" finished-at="2013-01-26T14:26:26Z">
<class name="org.glassfish.nucleus.quicklook.MiscCommandsTest">
<test-method status="PASS" signature="version1()[pri:0, instance:org.glassfish.nucleus.quicklook.MiscCommandsTest@11c001]" name="version1" duration-ms="922" started-at="2013-01-26T14:25:38Z" finished-at="2013-01-26T14:25:39Z">
</test-method>
<test-method status="PASS" signature="version2()[pri:0, instance:org.glassfish.nucleus.quicklook.MiscCommandsTest@11c001]" name="version2" duration-ms="10562" started-at="2013-01-26T14:25:39Z" finished-at="2013-01-26T14:25:50Z">
</test-method>
<test-method status="PASS" signature="uptime()[pri:0, instance:org.glassfish.nucleus.quicklook.MiscCommandsTest@11c001]" name="uptime" duration-ms="1828" started-at="2013-01-26T14:25:50Z" finished-at="2013-01-26T14:25:52Z">
</test-method>
</class>
<class name="org.glassfish.nucleus.quicklook.RestTest">
<test-method status="FAIL" signature="testAdminCommandEndpoint()[pri:0, instance:org.glassfish.nucleus.quicklook.RestTest@1e7dfbc]" name="testAdminCommandEndpoint" duration-ms="985" started-at="2013-01-26T14:25:37Z" finished-at="2013-01-26T14:25:38Z">
<exception class="java.lang.AssertionError">
<message>
<![CDATA[expected:<200> but was:<503>]]>
</message>
<full-stacktrace>
<![CDATA[java.lang.AssertionError: expected:<200> but was:<503>
at org.testng.AssertJUnit.fail(AssertJUnit.java:59)
at org.testng.AssertJUnit.failNotEquals(AssertJUnit.java:364)
at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:80)
at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:245)
at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:252)
at org.glassfish.nucleus.quicklook.RestTest.testAdminCommandEndpoint(RestTest.java:73)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80)
at org.testng.internal.Invoker.invokeMethod(Invoker.java:691)
at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:883)
at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1208)
at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
at org.testng.TestRunner.privateRun(TestRunner.java:758)
at org.testng.TestRunner.run(TestRunner.java:613)
at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:329)
at org.testng.SuiteRunner.privateRun(SuiteRunner.java:291)
at org.testng.SuiteRunner.run(SuiteRunner.java:240)
at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:53)
at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:87)
at org.testng.TestNG.runSuitesSequentially(TestNG.java:1137)
at org.testng.TestNG.runSuitesLocally(TestNG.java:1062)
at org.testng.TestNG.run(TestNG.java:974)
at org.apache.maven.surefire.testng.TestNGExecutor.run(TestNGExecutor.java:62)
at org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.execute(TestNGDirectoryTestSuite.java:141)
at org.apache.maven.surefire.Surefire.run(Surefire.java:177)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:345)
at org.apache.maven.surefire.booter.SurefireBooter.run(SurefireBooter.java:241)
at org.apache.maven.plugin.surefire.SurefirePlugin.execute(SurefirePlugin.java:537)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
]]>
</full-stacktrace>
</exception>
</test-method>
<test-method status="FAIL" signature="testChildConfigBeanEndpoint()[pri:0, instance:org.glassfish.nucleus.quicklook.RestTest@1e7dfbc]" name="testChildConfigBeanEndpoint" duration-ms="78" started-at="2013-01-26T14:25:38Z" finished-at="2013-01-26T14:25:38Z">
<exception class="java.lang.AssertionError">
<message>
<![CDATA[expected:<200> but was:<503>]]>
</message>
<full-stacktrace>
<![CDATA[java.lang.AssertionError: expected:<200> but was:<503>
at org.testng.AssertJUnit.fail(AssertJUnit.java:59)
at org.testng.AssertJUnit.failNotEquals(AssertJUnit.java:364)
at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:80)
at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:245)
at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:252)
at org.glassfish.nucleus.quicklook.RestTest.testChildConfigBeanEndpoint(RestTest.java:82)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80)
at org.testng.internal.Invoker.invokeMethod(Invoker.java:691)
at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:883)
at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1208)
at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
at org.testng.TestRunner.privateRun(TestRunner.java:758)
at org.testng.TestRunner.run(TestRunner.java:613)
at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:329)
at org.testng.SuiteRunner.privateRun(SuiteRunner.java:291)
at org.testng.SuiteRunner.run(SuiteRunner.java:240)
at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:53)
at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:87)
at org.testng.TestNG.runSuitesSequentially(TestNG.java:1137)
at org.testng.TestNG.runSuitesLocally(TestNG.java:1062)
at org.testng.TestNG.run(TestNG.java:974)
at org.apache.maven.surefire.testng.TestNGExecutor.run(TestNGExecutor.java:62)
at org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.execute(TestNGDirectoryTestSuite.java:141)
at org.apache.maven.surefire.Surefire.run(Surefire.java:177)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:345)
at org.apache.maven.surefire.booter.SurefireBooter.run(SurefireBooter.java:241)
at org.apache.maven.plugin.surefire.SurefirePlugin.execute(SurefirePlugin.java:537)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
]]>
</full-stacktrace>
</exception>
</test-method>
<test-method status="PASS" signature="testMonitoringEndpoint()[pri:0, instance:org.glassfish.nucleus.quicklook.RestTest@1e7dfbc]" name="testMonitoringEndpoint" duration-ms="140" started-at="2013-01-26T14:25:38Z" finished-at="2013-01-26T14:25:38Z">
</test-method>
<test-method status="FAIL" signature="testPostGetDelete()[pri:0, instance:org.glassfish.nucleus.quicklook.RestTest@1e7dfbc]" name="testPostGetDelete" duration-ms="141" started-at="2013-01-26T14:25:38Z" finished-at="2013-01-26T14:25:38Z">
<exception class="java.lang.AssertionError">
<message>
<![CDATA[expected:<200> but was:<503>]]>
</message>
<full-stacktrace>
<![CDATA[java.lang.AssertionError: expected:<200> but was:<503>
at org.testng.AssertJUnit.fail(AssertJUnit.java:59)
at org.testng.AssertJUnit.failNotEquals(AssertJUnit.java:364)
at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:80)
at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:245)
at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:252)
at org.glassfish.nucleus.quicklook.RestTest.testPostGetDelete(RestTest.java:90)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80)
at org.testng.internal.Invoker.invokeMethod(Invoker.java:691)
at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:883)
at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1208)
at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
at org.testng.TestRunner.privateRun(TestRunner.java:758)
at org.testng.TestRunner.run(TestRunner.java:613)
at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:329)
at org.testng.SuiteRunner.privateRun(SuiteRunner.java:291)
at org.testng.SuiteRunner.run(SuiteRunner.java:240)
at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:53)
at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:87)
at org.testng.TestNG.runSuitesSequentially(TestNG.java:1137)
at org.testng.TestNG.runSuitesLocally(TestNG.java:1062)
at org.testng.TestNG.run(TestNG.java:974)
at org.apache.maven.surefire.testng.TestNGExecutor.run(TestNGExecutor.java:62)
at org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.execute(TestNGDirectoryTestSuite.java:141)
at org.apache.maven.surefire.Surefire.run(Surefire.java:177)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:345)
at org.apache.maven.surefire.booter.SurefireBooter.run(SurefireBooter.java:241)
at org.apache.maven.plugin.surefire.SurefirePlugin.execute(SurefirePlugin.java:537)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
]]>
</full-stacktrace>
</exception>
</test-method>
<test-method status="FAIL" signature="testManagementEndpoint()[pri:0, instance:org.glassfish.nucleus.quicklook.RestTest@1e7dfbc]" name="testManagementEndpoint" duration-ms="78" started-at="2013-01-26T14:25:38Z" finished-at="2013-01-26T14:25:38Z">
<exception class="java.lang.AssertionError">
<message>
<![CDATA[expected:<200> but was:<503>]]>
</message>
<full-stacktrace>
<![CDATA[java.lang.AssertionError: expected:<200> but was:<503>
at org.testng.AssertJUnit.fail(AssertJUnit.java:59)
at org.testng.AssertJUnit.failNotEquals(AssertJUnit.java:364)
at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:80)
at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:245)
at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:252)
at org.glassfish.nucleus.quicklook.RestTest.testManagementEndpoint(RestTest.java:55)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80)
at org.testng.internal.Invoker.invokeMethod(Invoker.java:691)
at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:883)
at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1208)
at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
at org.testng.TestRunner.privateRun(TestRunner.java:758)
at org.testng.TestRunner.run(TestRunner.java:613)
at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:329)
at org.testng.SuiteRunner.privateRun(SuiteRunner.java:291)
at org.testng.SuiteRunner.run(SuiteRunner.java:240)
at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:53)
at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:87)
at org.testng.TestNG.runSuitesSequentially(TestNG.java:1137)
at org.testng.TestNG.runSuitesLocally(TestNG.java:1062)
at org.testng.TestNG.run(TestNG.java:974)
at org.apache.maven.surefire.testng.TestNGExecutor.run(TestNGExecutor.java:62)
at org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.execute(TestNGDirectoryTestSuite.java:141)
at org.apache.maven.surefire.Surefire.run(Surefire.java:177)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:345)
at org.apache.maven.surefire.booter.SurefireBooter.run(SurefireBooter.java:241)
at org.apache.maven.plugin.surefire.SurefirePlugin.execute(SurefirePlugin.java:537)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
]]>
</full-stacktrace>
</exception>
</test-method>
</class>
<class name="org.glassfish.nucleus.quicklook.ClusterTest">
<test-method status="PASS" signature="createClusterTest()[pri:0, instance:org.glassfish.nucleus.quicklook.ClusterTest@1549a4e]" name="createClusterTest" duration-ms="8110" started-at="2013-01-26T14:25:29Z" finished-at="2013-01-26T14:25:37Z">
</test-method>
<test-method status="PASS" signature="createInstancesTest()[pri:0, instance:org.glassfish.nucleus.quicklook.ClusterTest@1549a4e]" name="createInstancesTest" duration-ms="3438" started-at="2013-01-26T14:25:52Z" depends-on-methods="org.glassfish.nucleus.quicklook.ClusterTest.createClusterTest" finished-at="2013-01-26T14:25:55Z">
</test-method>
<test-method status="PASS" signature="startInstancesTest()[pri:0, instance:org.glassfish.nucleus.quicklook.ClusterTest@1549a4e]" name="startInstancesTest" duration-ms="16359" started-at="2013-01-26T14:25:55Z" depends-on-methods="org.glassfish.nucleus.quicklook.ClusterTest.createInstancesTest" finished-at="2013-01-26T14:26:11Z">
</test-method>
<test-method status="PASS" signature="checkClusterTest()[pri:0, instance:org.glassfish.nucleus.quicklook.ClusterTest@1549a4e]" name="checkClusterTest" duration-ms="3406" started-at="2013-01-26T14:26:11Z" depends-on-methods="org.glassfish.nucleus.quicklook.ClusterTest.startInstancesTest" finished-at="2013-01-26T14:26:15Z">
</test-method>
<test-method status="PASS" signature="stopInstancesTest()[pri:0, instance:org.glassfish.nucleus.quicklook.ClusterTest@1549a4e]" name="stopInstancesTest" duration-ms="6250" started-at="2013-01-26T14:26:15Z" depends-on-methods="org.glassfish.nucleus.quicklook.ClusterTest.checkClusterTest" finished-at="2013-01-26T14:26:21Z">
</test-method>
<test-method status="PASS" signature="deleteInstancesTest()[pri:0, instance:org.glassfish.nucleus.quicklook.ClusterTest@1549a4e]" name="deleteInstancesTest" duration-ms="4110" started-at="2013-01-26T14:26:21Z" depends-on-methods="org.glassfish.nucleus.quicklook.ClusterTest.stopInstancesTest" finished-at="2013-01-26T14:26:25Z">
</test-method>
<test-method status="PASS" signature="deleteClusterTest()[pri:0, instance:org.glassfish.nucleus.quicklook.ClusterTest@1549a4e]" name="deleteClusterTest" duration-ms="890" started-at="2013-01-26T14:26:25Z" depends-on-methods="org.glassfish.nucleus.quicklook.ClusterTest.deleteInstancesTest" finished-at="2013-01-26T14:26:26Z">
</test-method>
</class>
<class name="org.glassfish.nucleus.quicklook.NucleusStartStopTest">
<test-method status="PASS" signature="setUp()[pri:0, instance:org.glassfish.nucleus.quicklook.NucleusStartStopTest@66b0e6]" name="setUp" is-config="true" duration-ms="12594" started-at="2013-01-26T14:25:16Z" finished-at="2013-01-26T14:25:29Z">
</test-method>
<test-method status="PASS" signature="tearDown()[pri:0, instance:org.glassfish.nucleus.quicklook.NucleusStartStopTest@66b0e6]" name="tearDown" is-config="true" duration-ms="1500" started-at="2013-01-26T14:26:26Z" finished-at="2013-01-26T14:26:28Z">
</test-method>
</class>
</test>
</suite>
</testng-results>

Comment by TangYong [ 26/Jan/13 ]

About failed tests, maybe we should request Tom to see whether these rest tests can be reproduced.

Comment by TangYong [ 26/Jan/13 ]

I have created a new jira GLASSFISH-19592 to handle the issue and I think that felix 4.0.3's updating looks fine.

Comment by Sanjeeb Sahoo [ 26/Jan/13 ]

Tang,

1. Did you run nucleus QL before making changes to just get the benchmark right? You can quickly try by copying felix-4.0.2 jar to nucleus/osgi/felix/bin/ and rerunning the tests. If the same tests fail, then the regressions are not caused by your change.

2. I don't see appserver QuickLook test results? You can execute them like this:

cd appserver/tests/quicklook

  1. Run test against full profile
    mvn clean test -Dglassfish.home=.../main/appserver/distributions/glassfish/target/stage/glassfish3/glassfish/
  1. Run test against web profile
    mvn clean test -P test_wd -Dglassfish.home=.../main/appserver/distributions/web/target/stage/glassfish3/glassfish/

Thanks,
Sahoo

Comment by TangYong [ 26/Jan/13 ]

Hi sahoo,

Thanks your informing me and I almost forgot this is a right way to judge whether the regressions are caused by my change.

>1. Did you run nucleus QL before making changes to just get the benchmark right? You can quickly try by copying >felix-4.0.2 jar to nucleus/osgi/felix/bin/ and rerunning the tests. If the same tests fail, then the regressions are >not caused by your change.

OK, I will do it.

>2. I don't see appserver QuickLook test results? You can execute them like this:
OK, I will do it also.

Thanks

Comment by TangYong [ 26/Jan/13 ]

>1. Did you run nucleus QL before making changes to just get the benchmark right? You can quickly try by copying >felix-4.0.2 jar to nucleus/osgi/felix/bin/ and rerunning the tests. If the same tests fail, then the regressions are >not caused by your change.

The result is the same as felix-4.0.3 as following:

Failed tests:
testAdminCommandEndpoint(org.glassfish.nucleus.quicklook.RestTest)
testChildConfigBeanEndpoint(org.glassfish.nucleus.quicklook.RestTest)
testPostGetDelete(org.glassfish.nucleus.quicklook.RestTest)
testManagementEndpoint(org.glassfish.nucleus.quicklook.RestTest)

The exception contents are the same too.

Comment by TangYong [ 26/Jan/13 ]

1 [Result] Run test against full profile using felix 4.0.3
because of my env's problem, please ignore the test result, and according to sahoo's comment,
will re-create a new domain and do tests.

Comment by Sanjeeb Sahoo [ 26/Jan/13 ]

The appserver QL failures are worrying me. They definitely pass with Felix 4.0.2.
Can you create a new domain and run the tests?
Also make sure you run
the tests once with Felix 4.0.2 to see if the regressions are a result of new Felix version or not.

Comment by TangYong [ 26/Jan/13 ]

Yes, other than restrelated failed tests which are same as nucleus, there are some other types of tests(eg. cluster deploying..) which
are tested failed.

I am doing web profile tests, and once finishing it , I will test felix 4.0.2 and see whether having regressions.

In addition, maybe my machine has a litter slow and caused these failed tests.

A question: while doing appserver QL tests, whether needing to start derby database or not?

Comment by TangYong [ 26/Jan/13 ]

1 [Result] Run test against web profile using felix 4.0.3 and felix 4.0.2

The two versions's results are the same while creating a new domain seperately.

===============================================
QuickLookTests
Total tests run: 90, Failures: 8, Skips: 0
===============================================

Among failed tests, rest related tests still failed!
So, if previously being successful, I think that recently there are some commits which cause regression.

I will re-create a new domain for full profile tests. Please wait.

Comment by TangYong [ 26/Jan/13 ]

2 [Result] Run test against full profile using felix 4.0.3 and felix 4.0.2

The two versions's results are the same too while creating a new domain seperately.

===============================================
QuickLookTests
Total tests run: 112, Failures: 8, Skips: 0
===============================================

Among failed tests, rest related tests still failed!

BTW: in oder to see which tests failed clearly, please seeing the following(many related to admin):

<!DOCTYPE suite SYSTEM "http://testng.org/testng-1.0.dtd">
<suite thread-count="5" verbose="2" name="Failed suite [QuickLookTests]" junit="false" annotations="JDK">
<parameter name="MDB_APP_DIR" value="./dist/mdb/"/>
<parameter name="BATCH_FILE1" value="ejb/mdb/create_resources.asadmin"/>
<parameter name="BATCH_FILE2" value="ejb/mdb/delete_resources.asadmin"/>
<parameter name="amx.debug" value="true"/>
<parameter name="admin.password" value=""/>
<parameter name="admin.console.url" value="http://localhost:4848/"/>
<parameter name="amx.rmiport" value="8686"/>
<parameter name="admin.user" value="admin"/>
<parameter name="resources.xml.relative.path" value="admin/resources/resources.xml"/>
<parameter name="admin.url" value="http://localhost:4848/__asadmin"/>
<test name="adminconsole_tests(failed)" junit="false" annotations="JDK">
<parameter name="MDB_APP_DIR" value="./dist/mdb/"/>
<parameter name="BATCH_FILE1" value="ejb/mdb/create_resources.asadmin"/>
<parameter name="BATCH_FILE2" value="ejb/mdb/delete_resources.asadmin"/>
<parameter name="amx.debug" value="true"/>
<parameter name="admin.password" value=""/>
<parameter name="admin.console.url" value="http://localhost:4848/"/>
<parameter name="amx.rmiport" value="8686"/>
<parameter name="admin.user" value="admin"/>
<parameter name="resources.xml.relative.path" value="admin/resources/resources.xml"/>
<parameter name="admin.url" value="http://localhost:4848/__asadmin"/>
<classes>
<class name="test.admin.AdminConsoleTests">
<methods>
<include name="testDeployedAppPage"/>
<include name="testCommonTasks"/>
<include name="shutdownClient"/>
<include name="loginBeforeTest"/>
<include name="testRealmsList"/>
</methods>
</class>
</classes>
</test>
<test name="admincli_tests(failed)" junit="false" annotations="JDK">
<parameter name="MDB_APP_DIR" value="./dist/mdb/"/>
<parameter name="BATCH_FILE1" value="ejb/mdb/create_resources.asadmin"/>
<parameter name="BATCH_FILE2" value="ejb/mdb/delete_resources.asadmin"/>
<parameter name="amx.debug" value="true"/>
<parameter name="admin.password" value=""/>
<parameter name="admin.console.url" value="http://localhost:4848/"/>
<parameter name="amx.rmiport" value="8686"/>
<parameter name="admin.user" value="admin"/>
<parameter name="resources.xml.relative.path" value="admin/resources/resources.xml"/>
<parameter name="admin.url" value="http://localhost:4848/__asadmin"/>
<classes>
<class name="test.admincli.RestartDomainTests">
<methods>
<include name="restartDomainTest"/>
</methods>
</class>
</classes>
</test>
<test name="rest_tests(failed)" junit="false" annotations="JDK">
<parameter name="MDB_APP_DIR" value="./dist/mdb/"/>
<parameter name="BATCH_FILE1" value="ejb/mdb/create_resources.asadmin"/>
<parameter name="BATCH_FILE2" value="ejb/mdb/delete_resources.asadmin"/>
<parameter name="amx.debug" value="true"/>
<parameter name="admin.password" value=""/>
<parameter name="admin.console.url" value="http://localhost:4848/"/>
<parameter name="amx.rmiport" value="8686"/>
<parameter name="admin.user" value="admin"/>
<parameter name="resources.xml.relative.path" value="admin/resources/resources.xml"/>
<parameter name="admin.url" value="http://localhost:4848/__asadmin"/>
<classes>
<class name="test.admin.RestTests">
<methods>
<include name="testManagementEndpoint"/>
<include name="testEndpointWithEncodedSlash"/>
<include name="testAdminCommandEndpoint"/>
<include name="testChildConfigBeanEndpoint"/>
</methods>
</class>
</classes>
</test>
</suite>

Comment by TangYong [ 26/Jan/13 ]

Conclusion(My opinion):

1 updating felix 4.0.3 does not cause current trunk's regression.

2 compared to previous gf, recently maybe some components have caused regression.

Deeply, if running QL tests on previous gf's version has not any failed test, currently, the following components need to be confirmed whether causing regression.

1) Admin Rest and Rest Related Modules
2) Admin Console
3) Admin CLI
4) QL Test Cases self

Thanks.

Comment by Sanjeeb Sahoo [ 26/Jan/13 ]

Thanks for verifying that there are no regressions caused by Felix 4.0.3.

I will integrate your patch ASAP.

Thanks,
Sahoo

Comment by Sanjeeb Sahoo [ 26/Jan/13 ]

------------------------------------------------------------------------
r58813 | ss141213 | 2013-01-26 17:11:43 +0530 (Sat, 26 Jan 2013) | 3 lines

GLASSFISH-19586: Upgrade to Felix 4.0.3
Patch provided by Tang Yong.





[GLASSFISH-19561] Remove references to JMSConnectionFactoryDefinition maxIdleTime attribute Created: 21/Jan/13  Updated: 24/Jan/13  Resolved: 24/Jan/13

Status: Resolved
Project: glassfish
Component/s: jms
Affects Version/s: 4.0_b73
Fix Version/s: 4.0_b71

Type: New Feature Priority: Major
Reporter: Nigel Deakin Assignee: Simon Meng
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: jms-2-implementation

 Description   

JMS 2.0 has removed the maxIdleTime attribute from JMSConnectionFactoryDefinition, and Java EE 7 has removed the <max-idle-time> sub-element from the <jms-connection-factory> element.

Please make sure that GlassFish does not contain references to this property.



 Comments   
Comment by Simon Meng [ 24/Jan/13 ]

Fix at revision 58777





[GLASSFISH-19558] Deploy MDB with any single property of destinationLookup, mappedName and destination specified. Created: 19/Jan/13  Updated: 24/Jan/13  Resolved: 24/Jan/13

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

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

Issue Links:
Dependency
blocks MQ-250 Implement JMSRA activation properties... Closed
Tags: jms-2-implementation

 Description   

With current jms implementation, if mappedName or <message-destination> in DD is not specified, whether or not destinationLookup/destination is specified in activationSpec is specified, the MDB deployment will fail by error message "missing destination JNDI name". This is incorrect.

It is expected that any single property of destinationLookup, mappedName and destination specified can take effect for sucessful MDB deployment. If all of them are provided, the desired overriding order should be "destinationLookup over destination, and destination over mappedName".

One more thing that can be enhanced is about the error message, which could be misleading: "missing destination JNDI name". It is proposed being changed to "MDB destination not specified".



 Comments   
Comment by David Zhao [ 24/Jan/13 ]

Fixed by revision 58778.





[GLASSFISH-19557] Embedded server startup failing due to "Could not find the alias glassfish-instance in the key store" Created: 18/Jan/13  Updated: 25/Jan/13  Resolved: 25/Jan/13

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

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


 Description   

Jan 18, 2013 3:37:22 PM com.sun.enterprise.v3.server.AppServerStartup$StartupActivator activate
SEVERE: Startup service failed to start
MultiException stack 1 of 2
java.lang.RuntimeException: java.lang.IllegalArgumentException: Could not find the alias glassfish-instance in the key store
at com.sun.enterprise.security.admin.cli.SecureAdminStartupCheck.postConstruct(SecureAdminStartupCheck.java:93)
at org.jvnet.hk2.internal.ClazzCreator.postConstructMe(ClazzCreator.java:249)
at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:288)
at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:429)
at org.glassfish.hk2.runlevel.internal.RunLevelContext.findOrCreate(RunLevelContext.java:119)
at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:1931)
at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:93)
at com.sun.enterprise.v3.server.AppServerStartup$StartupActivator.activate(AppServerStartup.java:531)
at org.glassfish.hk2.runlevel.utilities.RunLevelControllerImpl$Worker.activateRunLevel(RunLevelControllerImpl.java:828)
at org.glassfish.hk2.runlevel.utilities.RunLevelControllerImpl$Worker.upActiveRecorder(RunLevelControllerImpl.java:782)
at org.glassfish.hk2.runlevel.utilities.RunLevelControllerImpl$Worker.run(RunLevelControllerImpl.java:677)
at org.glassfish.hk2.runlevel.utilities.RunLevelControllerImpl$SyncProceedToWorker.proceedTo(RunLevelControllerImpl.java:948)
at org.glassfish.hk2.runlevel.utilities.RunLevelControllerImpl.proceedTo(RunLevelControllerImpl.java:565)
at org.glassfish.hk2.runlevel.utilities.RunLevelControllerImpl.proceedTo(RunLevelControllerImpl.java:349)
at com.sun.enterprise.v3.server.AppServerStartup.proceedTo(AppServerStartup.java:374)
at com.sun.enterprise.v3.server.AppServerStartup.run(AppServerStartup.java:259)
at com.sun.enterprise.v3.server.AppServerStartup.doStart(AppServerStartup.java:177)
at com.sun.enterprise.v3.server.AppServerStartup.start(AppServerStartup.java:168)
at com.sun.enterprise.glassfish.bootstrap.GlassFishImpl.start(GlassFishImpl.java:79)
at org.glassfish.tests.embedded.web.EmbeddedAddServletAndFilterByClassNameTest.setupServer(EmbeddedAddServletAndFilterByClassNameTest.java:80)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.junit.internal.runners.BeforeAndAfterRunner.invokeMethod(BeforeAndAfterRunner.java:74)
at org.junit.internal.runners.BeforeAndAfterRunner.runBefores(BeforeAndAfterRunner.java:50)
at org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:33)
at org.junit.internal.runners.TestClassRunner.run(TestClassRunner.java:52)
at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140)
at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:165)
at org.apache.maven.surefire.Surefire.run(Surefire.java:107)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:289)
at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:993)
Caused by: java.lang.IllegalArgumentException: Could not find the alias glassfish-instance in the key store
at com.sun.enterprise.security.admin.cli.SecureAdminHelperImpl.getDN(SecureAdminHelperImpl.java:111)
at com.sun.enterprise.security.admin.cli.SecureAdminUpgradeHelper.addPrincipalForAlias(SecureAdminUpgradeHelper.java:196)
at com.sun.enterprise.security.admin.cli.SecureAdminUpgradeHelper.ensureSecureAdminReady(SecureAdminUpgradeHelper.java:179)
at com.sun.enterprise.security.admin.cli.SecureAdminStartupCheck.postConstruct(SecureAdminStartupCheck.java:89)
... 37 more
MultiException stack 2 of 2
java.lang.IllegalStateException: Unable to create or inject com.sun.enterprise.security.admin.cli.SecureAdminStartupCheck
at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:302)
at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:429)
at org.glassfish.hk2.runlevel.internal.RunLevelContext.findOrCreate(RunLevelContext.java:119)
at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:1931)
at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:93)
at com.sun.enterprise.v3.server.AppServerStartup$StartupActivator.activate(AppServerStartup.java:531)
at org.glassfish.hk2.runlevel.utilities.RunLevelControllerImpl$Worker.activateRunLevel(RunLevelControllerImpl.java:828)
at org.glassfish.hk2.runlevel.utilities.RunLevelControllerImpl$Worker.upActiveRecorder(RunLevelControllerImpl.java:782)
at org.glassfish.hk2.runlevel.utilities.RunLevelControllerImpl$Worker.run(RunLevelControllerImpl.java:677)
at org.glassfish.hk2.runlevel.utilities.RunLevelControllerImpl$SyncProceedToWorker.proceedTo(RunLevelControllerImpl.java:948)
at org.glassfish.hk2.runlevel.utilities.RunLevelControllerImpl.proceedTo(RunLevelControllerImpl.java:565)
at org.glassfish.hk2.runlevel.utilities.RunLevelControllerImpl.proceedTo(RunLevelControllerImpl.java:349)
at com.sun.enterprise.v3.server.AppServerStartup.proceedTo(AppServerStartup.java:374)
at com.sun.enterprise.v3.server.AppServerStartup.run(AppServerStartup.java:259)
at com.sun.enterprise.v3.server.AppServerStartup.doStart(AppServerStartup.java:177)
at com.sun.enterprise.v3.server.AppServerStartup.start(AppServerStartup.java:168)
at com.sun.enterprise.glassfish.bootstrap.GlassFishImpl.start(GlassFishImpl.java:79)
at org.glassfish.tests.embedded.web.EmbeddedAddServletAndFilterByClassNameTest.setupServer(EmbeddedAddServletAndFilterByClassNameTest.java:80)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.junit.internal.runners.BeforeAndAfterRunner.invokeMethod(BeforeAndAfterRunner.java:74)
at org.junit.internal.runners.BeforeAndAfterRunner.runBefores(BeforeAndAfterRunner.java:50)
at org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:33)
at org.junit.internal.runners.TestClassRunner.run(TestClassRunner.java:52)
at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140)
at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:165)
at org.apache.maven.surefire.Surefire.run(Surefire.java:107)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:289)
at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:993)



 Comments   
Comment by Amy Roh [ 18/Jan/13 ]

Regression is caused by svn revision 58646.

To reproduce

(1) build embedded distro from main/appserver/extras/embedded/all
(2) run embedded tests from main/appserver/tests/embedded/web

Comment by Bhavanishankar [ 21/Jan/13 ]

Checked-in a fix for this.

Sending appserver/extras/embedded/build.xml
Transmitting file data .
Committed revision 58663.

[See http://java.net/projects/glassfish/lists/commits/archive/2013-01/message/776]

Comment by Amy Roh [ 25/Jan/13 ]

Fixed in 58663.





[GLASSFISH-19531] asadmin usage message is missing the --detach option Created: 14/Jan/13  Updated: 22/Jan/13  Resolved: 22/Jan/13

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

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


 Description   

The Usage.full message in the resource bundle for the asadmin command is missing the --detach option, therefore it is missing from the asadmin output:

$ ./asadmin -x
Invalid option: -x
Usage: asadmin [-H|--host <host(default:localhost)>]
[-p|--port <port(default:4848)>] [-u|--user <user(default:admin)>]
[-W|--passwordfile <passwordfile>]
[t|-terse[=<terse(default:false)>]]
[s|-secure[=<secure(default:false)>]]
[e|-echo[=<echo(default:false)>]]
[I|-interactive[=<interactive(default:true)>]]
[?|-help[=<help(default:false)>]] [subcommand [options] [operands]]

I'm creating a bug rather than fixing this myself because I wasn't sure whether this omission was intentional.

Ideally, a fix for this should be checked in today because the strings are submitted for l10n tomorrow.



 Comments   
Comment by Bhakti Mehta [ 22/Jan/13 ]

Fixed in svn rev 68727





[GLASSFISH-19524] Servlet - when ReadListener.onDataAvailable() gets called, the context class loader of the Thread is not WebAppClassloader. Created: 11/Jan/13  Updated: 11/Jan/13  Resolved: 11/Jan/13

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

Type: Bug Priority: Major
Reporter: stepan.kopriva Assignee: Amy Roh
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

java build 1.7.0_09-b05



 Description   

1) When client sends HttpRequest and then application data to server, when ReadListener.onDataAvailable() gets called, the context class loader of the Thread is not WebAppClassloader.

2) When client sends HttpRequest to the server, then reads response and then sends application data to server, when ReadListener.onDataAvailable() gets called, the context class loader of the Thread is not WebAppClassloader.



 Comments   
Comment by Amy Roh [ 11/Jan/13 ]

Fixed in revision 58297.





GlassFish services and components to conform with configuration modularity (GLASSFISH-19408)

[GLASSFISH-19522] Diagnostic service configuration to conform with configuration modularity Created: 11/Jan/13  Updated: 01/Feb/13

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

Type: Sub-task Priority: Major
Reporter: Masoud Kalali Assignee: tvlatas
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Comments   
Comment by tvlatas [ 16/Jan/13 ]

I grabbed the changes that were listed for removing the DiagnosticService from the templates and reproduced the admin dev test failures here.

I took a look and the problem with the changes is that there apparently is also a org.glassfish.config.support.DefaultConfigUpgrade.postConstruct() which relies on both the order and existence of elements in the domain templates.

When I removed the createDiagnosticServiceConfig(defaultConfig); from the postConstruct() these tests passed.

I'm not familiar with that code, so I don't know if removing that call will have other side effects, so I may find other issues as I test this out.

Comment by tvlatas [ 18/Jan/13 ]

quick update on the testing.

The admin dev tests for upgrade are failing for me with the above mentioned change I made, but they appear to be unrelated to my change and looks more like those tests don't run properly on JDK 7:

[java] Exception in thread "main" MultiException stack 1 of 2
[java] java.lang.UnsupportedClassVersionError: com/sun/enterprise/admin/cli/optional/BackupDomainCommand : Unsupported major.minor version 51.0
[java] at java.lang.ClassLoader.defineClass1(Native Method)
[java] at java.lang.ClassLoader.defineClass(ClassLoader.java:634)
[java] at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
[java] at java.net.URLClassLoader.defineClass(URLClassLoader.java:277)

Comment by tvlatas [ 18/Jan/13 ]

Found the problem the issue was that while the JAVA_HOME was set, the PATH was still finding an older version of the JDK (so thus the mismatch).

Setting the path to the JDK 1.7 and rerunning the tests passed.

I'm going to rerun the full set locally, but it looks like this change should be OL.

Comment by tvlatas [ 01/Feb/13 ]

Revision 58967 was committed to address this

Comment by tvlatas [ 01/Feb/13 ]

In reviewing the one-pager for config modularity, I believe that the original set of changes the config team had listed to resolve this on their wiki was insufficient. It only addressed the domain defaults.

The DiagnosticService configuration allows extensions, and the pattern for that is changing, so we also need to review and update to align with the new pattern/annotations there now as well.





[GLASSFISH-19503] T13y: deployment container Created: 09/Jan/13  Updated: 14/Jan/13  Resolved: 14/Jan/13

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

Type: Bug Priority: Major
Reporter: michael.y.chen Assignee: Hong Zhang
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The translatability (t13y) group has run an audit on the GlassFish message .properties files. This audit has identified a number of strings that will cause issues for the translators.

This bug requests that the issues described in the report for the following areas be addressed:

glassfish/appserver/jms
glassfish/appserver/appclient/client
glassfish/appserver/verifier
glassfish/nucleus/deployment
glassfish/appserver/deployment
glassfish/appserver/ejb
glassfish/appserver/web
glassfish/appserver/webservices
glassfish/appserver/transaction

The report is available at:

http://aseng-wiki.us.oracle.com/asengwiki/download/attachments/-884998132/WPTG_T13Y_compare-fmw-glassfish-4.0.0-drop1-3.1-drop1-ui-1.xlsx?version=1

Note that the report consists of 3 different sheet (tabs). Each sheet lists issues for a specific category of error.

Please go through all tabs and look for references to the .properties files for the GlassFish areas listed above, and address the specific issue described.

General guidance for how to address the issues in each category are given here:
http://aseng-wiki.us.oracle.com/asengwiki/display/GlassFish/Java+EE+7+T13y



 Comments   
Comment by Tim Quinn [ 09/Jan/13 ]

I've fixed problems in the app client-related modules and sent a separate e-mail update to Joe.

Project: glassfish
Repository: svn
Revision: 58236
Author: tjquinn
Date: 2013-01-09 15:41:02 UTC
Link:

Log Message:
------------
Partial fix for 19503

Corrects some translatability problems in the app client-related modules.

Revisions:
----------
58236

Modified Paths:
---------------
trunk/main/appserver/appclient/client/acc/src/main/resources/org/glassfish/appclient/client/acc/LocalStrings.properties

Comment by Martin Grebac [ 09/Jan/13 ]

Fixed webservices related issues:
commit -m "Fix of GLASSFISH-19503" /Users/snajper/work/sources/glassfish/trunk/appserver/webservices/jsr109-impl/src/main/resources/org/glassfish/webservices/monitoring/LocalStrings.properties
Committed revision 58239.
Author : snajper
Date : Jan 9, 2013 5:36:37 PM
Fix of GLASSFISH-19503

Comment by Hong Zhang [ 09/Jan/13 ]

Fixed high priority l10n issues for deployment area (svn 58243).

Revisions:
----------
58243

Modified Paths:
---------------
trunk/main/nucleus/deployment/autodeploy/src/main/java/org/glassfish/deployment/autodeploy/LocalStrings.properties
trunk/main/nucleus/deployment/autodeploy/src/main/java/org/glassfish/deployment/autodeploy/AutodeployRetryManager.java
trunk/main/appserver/deployment/dol/src/main/java/com/sun/enterprise/deployment/LocalStrings.properties
trunk/main/appserver/deployment/dol/src/main/java/com/sun/enterprise/deployment/annotation/handlers/LocalStrings.properties
trunk/main/appserver/deployment/client/src/main/java/org/glassfish/deployapi/LocalStrings.properties
trunk/main/nucleus/deployment/admin/src/main/java/org/glassfish/deployment/admin/LocalStrings.properties

Comment by Sanjeeb Sahoo [ 10/Jan/13 ]

Fixed verifier issues identified in the spreadsheet in svn rev #58256.

Comment by David Zhao [ 14/Jan/13 ]

Fixed 2 T13Y issues (items 6 and 15 in the Concatenation tab) of JMS module with changelist 58316.

Comment by Hong Zhang [ 14/Jan/13 ]

All the high priority issues for the areas listed in this issue are now addressed. I am going to mark the issue as resolved. If we have time to address additional medium/low issues, we can continue to do so and update this issue accordingly.





[GLASSFISH-19498] Java Web Start generated files intermittently being deleted, causing Web Start applications to fail Created: 07/Jan/13  Updated: 08/Jan/13  Resolved: 08/Jan/13

Status: Resolved
Project: glassfish
Component/s: standalone_client
Affects Version/s: 3.1.2.2
Fix Version/s: 4.0_b71

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

Java7u9 64Bit, Linux Fedora 17



 Description   

Somewhat rarely, our WebStart application's <glassfish_home>/glassfish/domains/domain1/generated/xml directory is getting deleted. We can not seem to determine the cause, or reproduce consistently. But it does happen fairly often. We have about 10 QA machines, and this happens to 1 or 2 a week it seems.

It seems to happen most of the time after a machine reboot. We have 3 WebStart applications, and all 3 of their generated/xml directories, and all the contents completely disappear. But our web applications generated/xml directories remain (Although they are empty, but they were always empty).

There was another report of a similar issue, but it was closed as can not reproduce. GLASSFISH-17341

Any thoughts on how we can help debug this? I'm sure it will be tricky to reproduce?

Here is the last message before server shutdown (related to the Web Start app)
[#|2013-01-07T08:55:06.276-0500|INFO|glassfish3.1.2|javax.enterprise.system.container.appclient.org.glassfish.appclient.server.core|_Threa
dID=9658;_ThreadName=Thread-2;|ACDEPL104: Java Web Start services stopped for the app client POS-terminal-ear-8.0.0.0-SNAPSHOT/POS-termina
l.jar|#]

And here is an error after the reboot:

[#|2013-01-07T09:08:25.824-0500|SEVERE|glassfish3.1.2|javax.enterprise.system.tools.deployment.org.glassfish.deployment.common|_ThreadID=1
;_ThreadName=Thread-2;|Exception while invoking class org.glassfish.appclient.server.core.AppClientServerApplication start method
java.lang.RuntimeException: java.io.FileNotFoundException: /opt/glassfish3/glassfish/domains/domain1/generated/xml/POS-terminal-ear-8.0.0.0-SNAPSHOT/POS-terminal_jar/POS-terminalClient.jar
at org.glassfish.appclient.server.core.jws.JavaWebStartInfo$1.run(JavaWebStartInfo.java:259)
at org.glassfish.appclient.server.core.jws.JavaWebStartState.transition(JavaWebStartState.java:85)
at org.glassfish.appclient.server.core.jws.JavaWebStartInfo.start(JavaWebStartInfo.java:253)
at org.glassfish.appclient.server.core.AppClientServerApplication.start(AppClientServerApplication.java:150)
at org.glassfish.appclient.server.core.AppClientServerApplication.start(AppClientServerApplication.java:139)
at org.glassfish.internal.data.EngineRef.start(EngineRef.java:130)
at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:269)
at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:301)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:461)
at com.sun.enterprise.v3.server.ApplicationLoaderService.processApplication(ApplicationLoaderService.java:375)
at com.sun.enterprise.v3.server.ApplicationLoaderService.postConstruct(ApplicationLoaderService.java:219)
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:253)
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)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at com.sun.enterprise.glassfish.bootstrap.GlassFishMain.main(GlassFishMain.java:97)
at com.sun.enterprise.glassfish.bootstrap.ASMain.main(ASMain.java:55)
Caused by: java.io.FileNotFoundException: /opt/glassfish3/glassfish/domains/domain1/generated/xml/POS-terminal-ear-8.0.0.0-SNAPSHOT/POS-terminal_jar/POS-terminalClient.jar
at org.glassfish.appclient.server.core.jws.servedcontent.AutoSignedContent.<init>(AutoSignedContent.java:66)
at org.glassfish.appclient.server.core.jws.JavaWebStartInfo.createSignedStaticContent(JavaWebStartInfo.java:605)
at org.glassfish.appclient.server.core.jws.JavaWebStartInfo.createAndAddSignedStaticContent(JavaWebStartInfo.java:596)
at org.glassfish.appclient.server.core.jws.JavaWebStartInfo.createAndAddSignedStaticContentFromGeneratedFile(JavaWebStartInfo.java:576)
at org.glassfish.appclient.server.core.jws.JavaWebStartInfo.initClientStaticContent(JavaWebStartInfo.java:486)
at org.glassfish.appclient.server.core.jws.JavaWebStartInfo.addClientContentToHTTPAdapters(JavaWebStartInfo.java:456)
at org.glassfish.appclient.server.core.jws.JavaWebStartInfo.startJWSServices(JavaWebStartInfo.java:326)
at org.glassfish.appclient.server.core.jws.JavaWebStartInfo.access$000(JavaWebStartInfo.java:98)
at org.glassfish.appclient.server.core.jws.JavaWebStartInfo$1.run(JavaWebStartInfo.java:257)
... 29 more

#]


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

There are at least two possibilities, and maybe more we haven't thought of yet.

The first, the one you have mentioned, is that the files are indeed being deleted. Unless the application containing the app client is being undeployed, GlassFish should not be deleting the files itself. That would happen only during undeployment. You could try manually changing the file permissions on the files that disappear to prevent their deletion, then see if any exceptions appear in the GlassFish log or other logs.

Here is a second possibility. Since the problem seems more likely (always?) to happen after a reboot, the IP address of the system could change if the addresses are assigned using DHCP which could confuse things. For example, the cached main JNLP document might contain what used to be the correct IP address for the server, but the reboots might have assigned that IP address to another server (just by luck) that does not have that app installed. Could you review the IP addresses assigned to the servers before and after the reboots and see if that might be contributing to the problem?

Comment by skrall [ 07/Jan/13 ]

The files are certainly being deleted, I'm not sure how or why. But the files are gone. If we goto the Admin Console, and look at the applications. Glassfish still sees the Web Start applications, so they haven't been undeployed - at least totally. We will change the permissions on the file, see if that generates any logging.

The IP Addresses are static, but each machine does have 2 IpAddresses. One for an internal network, and one for an external facing network. There is a 192.168.0.x network which is very small, and a 10.30.x network wich is larger. All the traffic for the Web Start applications will happen over the 192.168.0.x network.

Here is the output of tree on a machine that has had the issue (Files deleted).

.
├── __admingui
├── Common
├── Dashboard
├── eforms-ear-8.0.0.0-SNAPSHOT
│   └── eForms-war-8.0.0.0-SNAPSHOT_war
├── ejb-timer-service-app
├── genericra
├── Makeline
├── Orderentry
├── Profit-ear-8.0.0.0-SNAPSHOT
│   ├── ProfitApi-war-8.0.0.0-SNAPSHOT_war
│   ├── Profit-ejb-8.0.0.0-SNAPSHOT_jar
│   └── ProfitRestfulServices-8.0.0.0-SNAPSHOT_war
├── ProfitMiddleware-ear-8.0.0.0-SNAPSHOT
│   └── Profit-messaging-8.0.0.0-SNAPSHOT_jar
├── System
├── Timeclock
└── wstx-services

Here is the tree from the generated/xml directory on a machine that is working correctly. (We've only launched POS-terminal, the other two web start applications are freshly deployed.)

.
├── __admingui
├── Common
├── Dashboard
├── DriverDispatch-ear-8.0.0.0-SNAPSHOT
│   ├── DriverDispatch-ear-8.0.0.0-SNAPSHOTClient.jar
│   ├── DriverDispatch_jar
│   │   └── DriverDispatchClient.jar
│   └── signed
│   └── DriverDispatch_jar
├── eforms-ear-8.0.0.0-SNAPSHOT
│   └── eForms-war-8.0.0.0-SNAPSHOT_war
├── ejb-timer-service-app
├── genericra
├── Makeline
├── Orderentry
├── POS-terminal-ear-8.0.0.0-SNAPSHOT
│   ├── POS-terminal-ear-8.0.0.0-SNAPSHOTClient.jar
│   ├── POS-terminal_jar
│   │   └── POS-terminalClient.jar
│   └── signed
│   ├── POS-terminal-ear-8.0.0.0-SNAPSHOTClient
│   │   ├── AnimatedTransitions-1.0.jar
│   │   ├── aopalliance-1.0.jar
│   │   ├── commons-codec-1.5.jar
│   │   ├── commons-collections-3.2.1.jar
│   │   ├── commons-exec-1.1.jar
│   │   ├── commons-logging-1.1.jar
│   │   ├── dpuareu-2.1.1.jar
│   │   ├── jms-1.1.jar
│   │   ├── jms-6.3.jar
│   │   ├── lizard-1.1.3.jar
│   │   ├── logback-classic-1.0.7.jar
│   │   ├── logback-core-1.0.7.jar
│   │   ├── posrealm-1.0.4.jar
│   │   ├── POS-terminal.jar
│   │   ├── ProfitApiWebServiceClients-8.0.0.0-SNAPSHOT.jar
│   │   ├── ProfitServices-8.0.0.0-SNAPSHOT.jar
│   │   ├── slf4j-api-1.7.2.jar
│   │   ├── spring-aop-3.0.6.RELEASE.jar
│   │   ├── spring-asm-3.0.6.RELEASE.jar
│   │   ├── spring-beans-3.0.6.RELEASE.jar
│   │   ├── spring-context-3.0.6.RELEASE.jar
│   │   ├── spring-core-3.0.6.RELEASE.jar
│   │   ├── spring-expression-3.0.6.RELEASE.jar
│   │   ├── spring-jms-3.0.6.RELEASE.jar
│   │   ├── spring-tx-3.0.6.RELEASE.jar
│   │   └── timingframework-classic-1.1.jar
│   ├── POS-terminal-ear-8.0.0.0-SNAPSHOTClient.jar
│   └── POS-terminal_jar
│   └── POS-terminalClient.jar
├── ProfitDesktopApp-ear-8.0.0.0-SNAPSHOT
│   ├── ProfitDesktopApp-ear-8.0.0.0-SNAPSHOTClient.jar
│   ├── ProfitDesktopApp_jar
│   │   └── ProfitDesktopAppClient.jar
│   └── signed
│   └── ProfitDesktopApp_jar
├── Profit-ear-8.0.0.0-SNAPSHOT
│   ├── ProfitApi-war-8.0.0.0-SNAPSHOT_war
│   ├── Profit-ejb-8.0.0.0-SNAPSHOT_jar
│   └── ProfitRestfulServices-8.0.0.0-SNAPSHOT_war
├── ProfitMiddleware-ear-8.0.0.0-SNAPSHOT
│   └── Profit-messaging-8.0.0.0-SNAPSHOT_jar
├── System
├── Timeclock
└── wstx-services

Comment by skrall [ 07/Jan/13 ]

I just noticed a stack trace right above the one I posted previously. Here is the stack trace that was just before. I see these in the logs from time to time, but it may be a large problem when they happen to web start apps? I'm not even sure if the stack trace is related, but it seems suspicious that it happened right before the other one. And we do include a jms-1.1.jar in our web start project.

[#|2013-01-07T09:08:25.266-0500|SEVERE|glassfish3.1.2|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=48;_ThreadName=Thread-2;|Exception while visiting javax/jms/TopicSession.class of size 852
java.lang.NullPointerException
at org.glassfish.hk2.classmodel.reflect.impl.TypesImpl.getType(TypesImpl.java:78)
at org.glassfish.hk2.classmodel.reflect.impl.ModelClassVisitor.visit(ModelClassVisitor.java:119)
at org.objectweb.asm.ClassReader.accept(Unknown Source)
at org.objectweb.asm.ClassReader.accept(Unknown Source)
at org.glassfish.hk2.classmodel.reflect.Parser$5.on(Parser.java:363)
at com.sun.enterprise.v3.server.ReadableArchiveScannerAdapter.handleEntry(ReadableArchiveScannerAdapter.java:171)
at com.sun.enterprise.v3.server.ReadableArchiveScannerAdapter.onSelectedEntries(ReadableArchiveScannerAdapter.java:133)
at org.glassfish.hk2.classmodel.reflect.Parser.doJob(Parser.java:348)
at org.glassfish.hk2.classmodel.reflect.Parser.access$300(Parser.java:70)
at org.glassfish.hk2.classmodel.reflect.Parser$3.call(Parser.java:307)
at org.glassfish.hk2.classmodel.reflect.Parser$3.call(Parser.java:296)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)

#]

[#|2013-01-07T09:08:25.824-0500|SEVERE|glassfish3.1.2|javax.enterprise.system.tools.deployment.org.glassfish.deployment.common|_ThreadID=1;_ThreadName=Thread-2;|Exception while invoking class org.glassfish.appclient.server.core.AppClientServerApplication start method
java.lang.RuntimeException: java.io.FileNotFoundException: /opt/glassfish3/glassfish/domains/domain1/generated/xml/POS-terminal-ear-8.0.0.0-SNAPSHOT/POS-terminal_jar/POS-terminalClient.jar
at org.glassfish.appclient.server.core.jws.JavaWebStartInfo$1.run(JavaWebStartInfo.java:259)
at org.glassfish.appclient.server.core.jws.JavaWebStartState.transition(JavaWebStartState.java:85)
at org.glassfish.appclient.server.core.jws.JavaWebStartInfo.start(JavaWebStartInfo.java:253)
at org.glassfish.appclient.server.core.AppClientServerApplication.start(AppClientServerApplication.java:150)
at org.glassfish.appclient.server.core.AppClientServerApplication.start(AppClientServerApplication.java:139)
at org.glassfish.internal.data.EngineRef.start(EngineRef.java:130)
at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:269)
at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:301)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:461)
at com.sun.enterprise.v3.server.ApplicationLoaderService.processApplication(ApplicationLoaderService.java:375)
at com.sun.enterprise.v3.server.ApplicationLoaderService.postConstruct(ApplicationLoaderService.java:219)
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:253)
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)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at com.sun.enterprise.glassfish.bootstrap.GlassFishMain.main(GlassFishMain.java:97)
at com.sun.enterprise.glassfish.bootstrap.ASMain.main(ASMain.java:55)
Caused by: java.io.FileNotFoundException: /opt/glassfish3/glassfish/domains/domain1/generated/xml/POS-terminal-ear-8.0.0.0-SNAPSHOT/POS-terminal_jar/POS-terminalClient.jar
at org.glassfish.appclient.server.core.jws.servedcontent.AutoSignedContent.<init>(AutoSignedContent.java:66)
at org.glassfish.appclient.server.core.jws.JavaWebStartInfo.createSignedStaticContent(JavaWebStartInfo.java:605)
at org.glassfish.appclient.server.core.jws.JavaWebStartInfo.createAndAddSignedStaticContent(JavaWebStartInfo.java:596)
at org.glassfish.appclient.server.core.jws.JavaWebStartInfo.createAndAddSignedStaticContentFromGeneratedFile(JavaWebStartInfo.java:576)
at org.glassfish.appclient.server.core.jws.JavaWebStartInfo.initClientStaticContent(JavaWebStartInfo.java:486)
at org.glassfish.appclient.server.core.jws.JavaWebStartInfo.addClientContentToHTTPAdapters(JavaWebStartInfo.java:456)
at org.glassfish.appclient.server.core.jws.JavaWebStartInfo.startJWSServices(JavaWebStartInfo.java:326)
at org.glassfish.appclient.server.core.jws.JavaWebStartInfo.access$000(JavaWebStartInfo.java:98)
at org.glassfish.appclient.server.core.jws.JavaWebStartInfo$1.run(JavaWebStartInfo.java:257)
... 29 more

#]
Comment by Tim Quinn [ 07/Jan/13 ]

Thanks for the update. The new stack trace doesn't tell (not to me at least) a lot of information; it does not track back to an identifiable part of the code.

That said, the Java Web Start-related stack trace is run only during deployment or start-up, and in fact in many ways GlassFish does much the same thing during restart and during deployment. One possible explanation could be that the system detects the NullPointerException (in the new exception) during start-up while processing part of the app, and in its attempt to recover the system or part of the system is incorrectly cleaning up the directories you mentioned. During deployment, cleaning up after such an error make sense, but not during restart.

Am I correct that these errors are reported during restart?

My suspicion is that there are at least two errors you've revealed: One is that the NPE should not occur, and the other is that if an error does occur the files should not disappear.

I'll check with others on the team to see if they have any ideas about what might be triggering the original NPE and the file deletions.

Comment by skrall [ 07/Jan/13 ]

Yes, the errors are reporting after a restart. The applications would have been deployed fine for a period of time (usually days or weeks). But after a restart, sometimes, the files disappear.

I noticed a couple of other bugs related to the NPE that were open. We see the message on some other class files too, but don't seem to notice any ill effects. The other bugs are GLASSFISH-18702, GLASSFISH-18609 and GLASSFISH-18513

Comment by Hong Zhang [ 08/Jan/13 ]

Tim and I had some discussions on this. One theory Tim has was if the application failed to load during server restart for some reason (for example due to this NPE or other cause), the deployment failure roll back logic would try to clean up the generated directories and resulted in the JWS file being cleaned up.

So I have updated this part of the deployment logic to only clean up for initial deployment failure and not for subsequent loading (like during server restart) so the JWS files will not be removed if the application failed to load during server start.

We however are not too sure why the application would fail to load, that particular NPE as you found out most times seems harmless, maybe it's due to some other cause. But in any case the NPE issue is tracked through other issues already, so we will not create another new issue for that. The fix I have checked in will at least address the problem that the generated files got deleted when the application failed to load during restart when they should not be.

Comment by skrall [ 08/Jan/13 ]

Is there a way we can get a patched 3.1.2.2 jar file? This is fairly painful for us, we keep having server's intermittently have this issue, which causes our application to not start.

Comment by Hong Zhang [ 08/Jan/13 ]

Let me see if I can make a 3.1.2 patch jar and send to you...

Comment by skrall [ 08/Jan/13 ]

Thanks, 3.1.2.2, you just have 3.1.2 in your comment, just want to avoid confusion.

And we will be able to test and let you know if it totally fixes the issue or not.

Comment by Hong Zhang [ 08/Jan/13 ]

Thanks for the clarification. I have built a patch jar locally for 3.1.2.2 now and I will send it to you via email (as the attachments are disabled in the JIRA issue now).





[GLASSFISH-19494] list-log-attributes does not include "multiLineMode" nor "ODLLogFormatter.excludeFields" Created: 04/Jan/13  Updated: 19/Feb/13  Resolved: 19/Feb/13

Status: Resolved
Project: glassfish
Component/s: logging
Affects Version/s: 4.0_b70
Fix Version/s: 4.0_b71

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

Issue Links:
Dependency
blocks GLASSFISH-19618 ODLLogFormatter.excludeFields should ... Resolved
blocks GLASSFISH-19491 Add all the new attributes relating t... Resolved

 Description   

2 issues relating ot the logging attributes.

#1. The logging attribute
"com.sun.enterprise.server.logging.GFFileHandler.multiLineMode" is not included in the out-of-box loggings.properties file. As a result,
%asadmin list-log-attributes
does not include this attribute and value.

Need to add this attribute to the loggings.properties file so that list-log-attributes will include it.
Basically, I need the list-log-attributes to return this attribute and value out-of-box.

============
#2. According to the logging requirement doc, one can set the excludes fields as followed. But running the set-log-attributes command returns error.

%asadmin set-log-attributes com.sun.enterprise.server.logging.ODLLogFormatter.excludeFields=userid
remote failure: Invalid logging attribute name found com.sun.enterprise.server.logging.ODLLogFormatter.excludeFields.
Command set-log-attributes failed.


 Comments   
Comment by Anissa Lam [ 05/Jan/13 ]

I have worked around #1 in the console, so the multi line mode is already available in the logging attribute screen.
I still think that should be fixed.

After #2 is fixed, i will add the UI for that.

Comment by Anissa Lam [ 21/Jan/13 ]

The console screen has added the 'Load Default' button.
Console allows editing of the "com.sun.enterprise.server.logging.GFFileHandler.multiLineMode" attribute with the work around.
However, since this is not included in the defaultLoggingProperties list either, this is treated as no default value when user press the Load Default Button.

Comment by sandeep.shrivastava [ 01/Feb/13 ]

Committed revision 58987. Added the properties in the template config file.

Comment by Anissa Lam [ 18/Feb/13 ]

I am reopening the issue.
I just updated my workspace to the latest version, there is still the following issues.

According to the logging requirement
http://aseng-wiki.us.oracle.com/asengwiki/display/GlassFish/Logging+Requirements+One+Pager#LoggingRequirementsOnePager-4.1.6LogFormat

The attribute name should be "ODLLogFormatter.excludeFields'. I will expect list-log-attributes to return this.
But list-log-attributes still does not include that.
Here is the result:

{{
~/Awork/BG/glassfish4/glassfish/bin 4) asadmin list-log-attributes
com.sun.enterprise.server.logging.GFFileHandler.excludeFields <>
com.sun.enterprise.server.logging.GFFileHandler.file <$

{com.sun.aas.instanceRoot}

/logs/server.log>
com.sun.enterprise.server.logging.GFFileHandler.flushFrequency <1>
com.sun.enterprise.server.logging.GFFileHandler.formatter <com.sun.enterprise.server.logging.UniformLogFormatter>
com.sun.enterprise.server.logging.GFFileHandler.logtoConsole <false>
com.sun.enterprise.server.logging.GFFileHandler.maxHistoryFiles <0>
com.sun.enterprise.server.logging.GFFileHandler.multiLineMode <false>
com.sun.enterprise.server.logging.GFFileHandler.retainErrorsStasticsForHours <0>
com.sun.enterprise.server.logging.GFFileHandler.rotationLimitInBytes <2000000>
com.sun.enterprise.server.logging.GFFileHandler.rotationOnDateChange <false>
com.sun.enterprise.server.logging.GFFileHandler.rotationTimelimitInMinutes <0>
com.sun.enterprise.server.logging.SyslogHandler.useSystemLogging <false>
handlerServices <com.sun.enterprise.server.logging.GFFileHandler>
handlers <java.util.logging.ConsoleHandler>
java.util.logging.ConsoleHandler.formatter <com.sun.enterprise.server.logging.UniformLogFormatter>
java.util.logging.FileHandler.count <1>
java.util.logging.FileHandler.formatter <java.util.logging.XMLFormatter>
java.util.logging.FileHandler.limit <50000>
java.util.logging.FileHandler.pattern <%h/java%u.log>
log4j.logger.org.hibernate.validator.util.Version <warn>
Command list-log-attributes executed successfully.
}}

so, ODLLogFormatter.excludeFields is still missing.

Also, there is still no way to set that attribute:
{{
~/Awork/BG/glassfish4/glassfish/bin 5) asadmin set-log-attributes com.sun.enterprise.server.logging.ODLLogFormatter.excludeFields=userid
remote failure: Invalid logging attribute name found com.sun.enterprise.server.logging.ODLLogFormatter.excludeFields.
Command set-log-attributes failed.

}}

Comment by Anissa Lam [ 19/Feb/13 ]

Sandeep mentioned that the attribute should be com.sun.enterprise.server.logging.GFFileHandler.excludeFields.
Console will be using this attribute name. He can close this bug after updating the one page to correctly reflect the change.

Comment by sandeep.shrivastava [ 19/Feb/13 ]

The one-pager is now updated to reflect the correct attribute name.





[GLASSFISH-19492] MDB @MessageDriven listens on Topic for @JMSDestinationDefinition className="javax.jms.Queue" Created: 03/Jan/13  Updated: 06/Jan/13  Resolved: 06/Jan/13

Status: Resolved
Project: glassfish
Component/s: jms
Affects Version/s: 4.0_b68_EE7MS3
Fix Version/s: 4.0_b71

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

Issue Links:
Duplicate
is duplicated by MQ-264 Async receiver does not receive the m... Closed
Tags: jms-2-implementation

 Description   

Please see Arun's async receiver sample (which is currently commented as not working in the following blog link) and analysis in MQ-264
https://blogs.oracle.com/arungupta/entry/simple_jms_2_0_sample



 Comments   
Comment by Nigel Deakin [ 03/Jan/13 ]

I have tried this in the debugger and agree that this appears to be the problem.

If you define a MDB which uses mappedName to refer to a queue resource created in the normal way (e.g. using glassfish-resources.xml) then ActivationSpec.setDestinationType() is called with a value of "javax.jms.Queue".

However if you define a MDB which uses mappedName to refer to a queue resource created using a @JMSDestinationDefinition annotation then ActivationSpec.setDestinationType() is NOT called. As a result the MDB creates a consumer on a topic (but the correct physical name).

So this seems to be an issue specifically with resources created using a @JMSDestinationDefinition annotation.

There is a workaround, which is to explicitly specify the destinationType activation property. Note that setting this property should not be necessary.

@MessageDriven(mappedName = "java:global/jms/myQueue", activationConfig =
 {@ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Queue")})
Comment by arungupta [ 03/Jan/13 ]

Tried the workaround in my simple sample and it worked.

Comment by Simon Meng [ 05/Jan/13 ]

Assume we create a jms destination resource via the following command:
asadmin create-jms-resource --restype javax.jms.Queue --property Name=myQueue jms/myQueue
The resource should be created successfully. It appears in domain.xml

In an application (a MDB), it also defines a jms destination by annotation

@JMSDestinationDefinition(name = "jms/myQueue",
resourceAdapterName = "jmsra",
className = "javax.jms.Queue",
destinationName="myQueue9",
description="My Queue9")

@MessageDriven(mappedName = "jms/myQueue")
public class MessageReceiverAsync implements MessageListener

{ .... }

When deploy a MDB, we need use the mappedName to find jms destination resource in domain.xml or EJbMessageBeanDescriptor. I need know the clear answer for the following questions:

1. If the mappedName does not start with "java:" prefix, whether need add "java:comp/env" prefix to match the resources.
2. If two jms destination resources have the same name (name does not start with "java:" prefix), the two resources are defined in both domain.xml and application, which resource should be used.

Comment by Simon Meng [ 06/Jan/13 ]

Fixed at revision 57990.





[GLASSFISH-19491] Add all the new attributes relating to logging to the Logger Settings screen Created: 03/Jan/13  Updated: 09/Jan/13  Resolved: 09/Jan/13

Status: Resolved
Project: glassfish
Component/s: admin_gui
Affects Version/s: None
Fix Version/s: 4.0_b71, 4.0

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

Issue Links:
Dependency
depends on GLASSFISH-19494 list-log-attributes does not include ... Resolved
Sub-Tasks:
Key
Summary
Type
Status
Assignee
GLASSFISH-19510 OLH : new logging attributes added t... Sub-task Resolved Gail Risdal  

 Description   

There are many new attributes added for 4.0 relating to logging. Need to have UI for that.
This includes:

  • excludeFields (tid, userId, ecid, timeMillis, levelValue)
  • Formatter. Allows switching between ODL and ULF. (not sure about allowing customized formatter, waiting for Sandeep to confirm)
  • Multiline mode: true or false.


 Comments   
Comment by Anissa Lam [ 05/Jan/13 ]
  • Dropdown has been added for the log file formatter and console formatter, user can select ODL or ULF.
  • multi line mode rendered as checkbox.
  • exclude field for ODL format cannot be implemented due to GLASSFISH-19490.
Comment by Anissa Lam [ 09/Jan/13 ]

I am closing this RFE as all the logging attributes that backend supports has been implemented.

The excludeFields attribute is still not working.

%asadmin set-log-attributes com.sun.enterprise.server.logging.ODLLogFormatter.excludeFields=userid
remote failure: Invalid logging attribute name found com.sun.enterprise.server.logging.ODLLogFormatter.excludeFields.
Command set-log-attributes failed.

When this is implemented by logging backend, then console will fix that as a bug.





[GLASSFISH-19490] provide API for returning the logging attributes default value Created: 03/Jan/13  Updated: 18/Jan/13  Resolved: 18/Jan/13

Status: Resolved
Project: glassfish
Component/s: logging
Affects Version/s: 4.0_b69
Fix Version/s: 4.0_b71, 4.0

Type: New Feature Priority: Major
Reporter: Anissa Lam Assignee: sandeep.shrivastava
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
blocks GLASSFISH-16394 Add 'Delete Log Levels' and 'Load Def... Resolved

 Description   

GLASSFISH-16394 requests admin console to provide a "Default" button so user can get the default value for all the logging attributes.
However, there is no API for console to use to get these default settings. All the logging attributes is stored in logging.properties file.
Talked to Sandeep so he can provide such API, and ensure that it is available through a REST endpoint management/domain/...



 Comments   
Comment by Anissa Lam [ 09/Jan/13 ]

Will there be support to provide default value for the logging properties before 1/11 ?
Feature freeze is on 1/14, I need this be available through a REST endpoint by 1/11.

Comment by Anissa Lam [ 09/Jan/13 ]

add target to 4.0.

Comment by sandeep.shrivastava [ 18/Jan/13 ]

Committed revision 58649. The REST data now includes a defaultLoggingProperties map that includes the default logging configuration.





[GLASSFISH-19482] several issues with list-jms-resources Created: 27/Dec/12  Updated: 10/Jan/13  Resolved: 10/Jan/13

Status: Resolved
Project: glassfish
Component/s: jms
Affects Version/s: 4.0_b68_EE7MS3
Fix Version/s: 4.0_b71

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

Issue Links:
Dependency
blocks GLASSFISH-19488 UI changes related to JMS resources Resolved

 Description   

I created an admin object resources and here is what it read in domain.xml

<admin-object-resource enabled="false" res-adapter="genericra" res-type="javax.jms.Queue" description="" jndi-name="ABC" class-name="com.sun.genericra.outbound.QueueProxy"></admin-object-resource>

When i run
%asadmin list-jms-resources --restype javax.jms.Queue
ABC
Command list-jms-resources executed successfully.

ABC should not be returned since it is using "genericra" as its res-adapter.



 Comments   
Comment by Anissa Lam [ 27/Dec/12 ]

I have changed the summary since i found more issues with list-jms-resources command.

#1. list-jms-resources doesn't filter out Admin Object Resources thats not using jmsra adapter
This is described in previous comment.

#2. list-jms-resources returns the connection-pool name if specifying "javax.jms.TopicConnectionFactory" as the restype option.

Without specifying any restype in the option:

%asadmin list-jms-resources
jms/__defaultConnectionFactory
ABC
Command list-jms-resources executed successfully.

But if i specify restype
%asadmin list-jms-resources --restype javax.jms.TopicConnectionFactory
ABC-Connection-Pool
Command list-jms-resources executed successfully.

It should have returned the resource name, "ABC" not the connection pool name.
Here is whats in domain.xml:

<connector-connection-pool max-pool-size="250" steady-pool-size="1" name="ABC-Connection-Pool" resource-adapter-name="jmsra" connection-definition-name="javax.jms.TopicConnectionFactory"></connector-connection-pool>
<connector-resource pool-name="ABC-Connection-Pool" jndi-name="ABC"></connector-resource>

Comment by Anissa Lam [ 28/Dec/12 ]

Another issue.

#3. When --restype is specified, the 'jmsResources' is not included in the ExtraProperties thats returned in the action report.
To reproduce, run
%asadmin create-jms-resource --restype javax.jms.Queue TEST

Now, go to browser, enter
http://localhost:4848/management/domain/resources/list-jms-resources
This has the jmsResources key in the Extra Properties map (refer to no-restype-option.png attached)

try specifying the restype type:
http://localhost:4848/management/domain/resources/list-jms-resources?id=&resType=javax.jms.Queue&__remove_empty_entries__=true
Note that the jmsResources key is missing. (refer to restype-option.png attached)

Comment by Anissa Lam [ 28/Dec/12 ]

I just realized that we cannot do attachment to the issue.
Will send the 2 screenshot to David offline.

Comment by David Zhao [ 04/Jan/13 ]

Fixed.

Comment by Anissa Lam [ 07/Jan/13 ]

I have to reopen the issue for the case where no JMS resources is available.
It should not return the Children with "Nothing to list" in it.

eg list-jms-resources --restype javax.jms.TopicConnectionFactory

{extraProperties={methods=[

{name=GET}

, {messageParameters={id=

{acceptableValues=, optional=true, defaultValue=, type=string}, resType={acceptableValues=, optional=true, defaultValue=, type=string}

}}], commandLog=[list-jms-resources --resType javax.jms.TopicConnectionFactory], jmsResources=[]}, message=, exit_code=SUCCESS, command=list-jms-resources AdminCommand, children=[{message=Nothing to list, properties={}}]}, responseBody={"message":"","command":"list-jms-resources AdminCommand","exit_code":"SUCCESS","extraProperties":{"methods":[

{"name":"GET"}

,{"messageParameters":{"id":

{"acceptableValues":"","optional":"true","type":"string","defaultValue":""}

,"resType":

{"acceptableValues":"","optional":"true","type":"string","defaultValue":""}

}}],"jmsResources":[],"commandLog":["list-jms-resources --resType javax.jms.TopicConnectionFactory"]},"children":[{"message":"Nothing to list","properties":{}}]

When console parses the data returned, there is the children, with message "Nothing to list". This should be the name of a resource if it exists.
The 'children' key should not exist if there is no children.

Please look at other list resources command, and have the list-jms-resources behave the same.
eg.
http://localhost:4848/management/domain/resources/list-jndi-resources

Comment by David Zhao [ 10/Jan/13 ]

Don't return "Nothing to list" for list-jms-resources, list-jmsdest and list-jms-hosts.





[GLASSFISH-19472] When delete-connector-resource fails, console prints incorrect message Created: 20/Dec/12  Updated: 16/Jan/13  Resolved: 16/Jan/13

Status: Resolved
Project: glassfish
Component/s: admin_gui
Affects Version/s: 4.0_b68_EE7MS3
Fix Version/s: 4.0_b71

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


 Description   

The delete-connector-resource command for the "jms/__defaultConnectionFactory" resource now fails (see GLASSFISH-19252). However, if an attempt is made to delete that resource from the console, the error message is:

An error has occurred
Expected constant (true)!

The expected message is:

The jms/__defaultConnectionFactory resource cannot be deleted as it is required to be configured in the system.

which is the output from the CLI.



 Comments   
Comment by Anissa Lam [ 16/Jan/13 ]

This has been fixed when making other changes related to jms.
It now shows the error properly.





[GLASSFISH-19450] 12 moxy test failures on b67 Created: 15/Dec/12  Updated: 10/Jan/13  Resolved: 10/Jan/13

Status: Resolved
Project: glassfish
Component/s: jax-rs
Affects Version/s: 4.0_b67_ms7
Fix Version/s: 4.0_b71

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

RHL5.x and JDK1.7.0_03


Tags: 40-regression

 Description   

glassfish-4.0-b67.zip
12 moxy test failures on b67
The moxy tests all passed on b66.

To reproduce the failure, use
appserver-sqe/pe/ejb/moxy/jaxrs3
with test env and steps in
http://java.net/jira/browse/GLASSFISH-19304
http://java.net/jira/browse/GLASSFISH-18813



 Comments   
Comment by sherryshen [ 10/Jan/13 ]

All moxy tests passed on b71 promoted build.





[GLASSFISH-19449] EJB 3.2 Remove restrictions on Timer and TimerHandle for access by EJBs only Created: 15/Dec/12  Updated: 29/Jan/13  Resolved: 29/Jan/13

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

Type: New Feature Priority: Major
Reporter: marina vatkina Assignee: amy.yang
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: ejb_3_2

 Description   

Any component or non-component can call methods of Timer and TimerHandle, even Timer.cancel



 Comments   
Comment by amy.yang [ 29/Jan/13 ]

fix is checked in via r58796.

test cases are checked in via r58816, 58820, 58844

Comment by amy.yang [ 29/Jan/13 ]

Closing this





[GLASSFISH-19448] Cannot get the logs details to be displayed in the admin console logviewer Created: 15/Dec/12  Updated: 04/Jan/13  Resolved: 04/Jan/13

Status: Resolved
Project: glassfish
Component/s: logging
Affects Version/s: 4.0_b67_ms7
Fix Version/s: 4.0_b71

Type: Bug Priority: Critical
Reporter: Anissa Lam Assignee: sandeep.shrivastava
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-19447 Cannot get the list of log file names Closed

 Description   

The admin console uses the following REST endpoint to get the list of logs to be displayed in the log viewer.

http://localhost:4848/management/domain/view-log/details.json

However, this is now returning FAILURE as the status.
Debugging the code shows that the following lines is throwing the exception.

private String getWithType(
            String logFileName,
            long startIndex,
            boolean searchForward,
            int maximumNumberOfResults,
            long fromTime,
            long toTime,
            String logLevel, boolean onlyLevel, String anySearch, List<String> listOfModules,
            String instanceName,
            String type) throws IOException {
        if (habitat.getService(LogManager.class) == null) {
            //the logger service is not install, so we cannot rely on it.
            //return an error
            throw new IOException("The GlassFish LogManager Service is not available. Not installed?");
        }

The REST endpoint should return something like this:

{"records": [{"recordNumber":337,"loggedDateTimeInMS":1355531068978,"loggedLevel":"WARNING","productName":"glassfish3.1.2","loggerName":"org.apache.catalina.connector.Request","nameValuePairs":"_ThreadID=51;_ThreadName=Thread-2;","messageID":"PWC4011","Message":" Unable to set request character encoding to UTF-8 from context , because request parameters have already been read, or ServletRequest.getReader() has already been called"},{"recordNumber":336,"loggedDateTimeInMS":1355531051885,"loggedLevel":"WARNING","productName":"glassfish3.1.2","loggerName":"org.apache.catalina.connector.Request","nameValuePairs":"_ThreadID=80;_ThreadName=Thread-2;","messageID":"PWC4011","Message":" Unable to set request character encoding to UTF-8 from context , because request parameters have already been read, or ServletRequest.getReader() has already been called"}

Since we still need to support the old format, so the current resource to get the logs have to work like before.



 Comments   
Comment by sandeep.shrivastava [ 24/Dec/12 ]

There seems to be some issue with HK2 ServiceLocator in not being able to find the service. I created the following asadmin command to isolate the issue.

When the jar containing the asadmin command is dropped into the modules dir, the following is the trace of the execution. While the normal @Inject works OK the ServiceLocator injected using the @Context is not working as expected.

[sanshriv@adc6260176 glassfish3]$ bin/asadmin log-manager --help
NAME
log-manager

SYNOPSIS
Usage: log-manager [--usehabitat=false]

OPTIONS
--usehabitat

Command log-manager executed successfully.

[sanshriv@adc6260176 glassfish3]$ bin/asadmin log-manager
Logging props file=/scratch/sanshriv/software/oracle-glassfish/glassfish3/glassfish/domains/domain1/config/logging.properties
Log files=[server.log_2012-12-18T12-13-48, server.log]
Command log-manager executed successfully.

[sanshriv@adc6260176 glassfish3]$ bin/asadmin log-manager --useHabitat true
remote failure: java.lang.NullPointerException
Command log-manager failed.

The command source code used is reproduced below.

/*

  • Copyright (c) 2012 Oracle and/or its affiliates. All rights reserved.
    */

package com.oracle.diagnostics.logging.commands;

import java.io.File;
import java.util.logging.Logger;

import javax.inject.Inject;
import javax.ws.rs.core.Context;

import org.glassfish.api.ActionReport;
import org.glassfish.api.Param;
import org.glassfish.api.admin.AdminCommand;
import org.glassfish.api.admin.AdminCommandContext;
import org.glassfish.api.admin.ExecuteOn;
import org.glassfish.api.admin.FailurePolicy;
import org.glassfish.api.admin.RestEndpoint;
import org.glassfish.api.admin.RestEndpoints;
import org.glassfish.api.admin.RuntimeType;
import org.glassfish.api.admin.ServerEnvironment;
import org.glassfish.config.support.CommandTarget;
import org.glassfish.config.support.TargetType;
import org.glassfish.hk2.api.PerLookup;
import org.glassfish.hk2.api.ServiceLocator;
import org.jvnet.hk2.annotations.Service;

import com.sun.enterprise.config.serverbeans.Domain;
import com.sun.enterprise.server.logging.logviewer.backend.LogFilter;

@ExecuteOn(value =

{RuntimeType.INSTANCE}

, ifOffline = FailurePolicy.Error, ifNeverStarted = FailurePolicy.Error)
@Service(name = "log-manager")
@TargetType(

{CommandTarget.DAS, CommandTarget.STANDALONE_INSTANCE, CommandTarget.CLUSTER, CommandTarget.CLUSTERED_INSTANCE}

)
@PerLookup
@RestEndpoints(

{ @RestEndpoint(configBean=Domain.class, opType=RestEndpoint.OpType.POST, path="log-manager", description="Log Manager") }

)
public class LogManager implements AdminCommand {

private static Logger LOGGER = Logger.getLogger(LogManager.class.getName());

@Inject
ServerEnvironment env;

@Inject
Domain domain;

@Inject
org.glassfish.internal.api.LogManager logManager;

@Inject
LogFilter logFilter;

@Context
protected ServiceLocator habitat;

@Param(optional=true, defaultValue="false")
boolean useHabitat;

public void execute(AdminCommandContext context) {

final ActionReport report = context.getActionReport();

String instanceName = env.getInstanceName();
LOGGER.info("Running command log-manager on instance " + instanceName);

if (useHabitat)

{ logManager = habitat.getService(org.glassfish.internal.api.LogManager.class); }

File logFile;
try

{ logFile = logManager.getLoggingFile(); report.addSubActionsReport().appendMessage( "Logging props file="+logFile.getAbsolutePath()); report.addSubActionsReport().appendMessage( "Log files="+logFilter.getInstanceLogFileNames(instanceName)); report.setActionExitCode(ActionReport.ExitCode.SUCCESS); }

catch (Exception e)

{ report.setFailureCause(e); report.setActionExitCode(ActionReport.ExitCode.FAILURE); return; }

}

}

Comment by sandeep.shrivastava [ 24/Dec/12 ]

John,

Could you take a look at the ServiceLocator issue we are running into?

Another way to reproduce the issue is to invoke the logviwer in the console.

http://localhost:4848/common/logViewer/logViewer.jsf?instanceName=server&loglevel=INFO&viewResults=true

Thanks

Sandeep

Comment by jwells [ 02/Jan/13 ]

Where can I find this "LogManager.java" file? It does not appear to be in either open or closed workspace.

I can find a LogManager.java, but it is an interface in the org.glassfish.internal.api package and does not
seem to be related. Is this code you haven't checked in yet? In which case, could I get the LogManager.java
you are talking about?

Also, if normal @Inject works is there a reason you can't just use that rather than @Context habitat?

These are the sort of questions I have about this use case...

Comment by sandeep.shrivastava [ 02/Jan/13 ]

The org.glassfish.internal.api.LogManager interface is implemented by the com.sun.enterprise.server.logging.LogManagerService class in main/nucleus/core/logging module in the open source.

It is referred by the all/main/nucleus/admin/rest/rest-service module which is part of the Admin Console.

The classes in question are the org.glassfish.admin.rest.resources.custom.LogNamesResource and org.glassfish.admin.rest.resources.custom.StructuredLogViewerResource

This it where it is failing:

if (habitat.getService(LogManager.class) == null)

{ //the logger service is not install, so we cannot rely on it. //return an error throw new IOException("The GlassFish LogManager Service is not available. Not installed?"); }

It is not able to find the service either using @Inject or the habitat.

You can exercise this by launching the Admin console, selecting the server(Admin Server) node from the left navtree and clicking "View Log Files".

Comment by jwells [ 02/Jan/13 ]

Ah, the fact that you are using a Rest resource is the reason for this issue! The issue is that you are getting the Jersey service locator (which does not have the GlassFish services in it) and thus that ServiceLocator cannot see the GlassFish services.

If you need access to the the GlassFish services (which you do) you will need to use:

org.glassfish.internal.api.Globals.getDefaultBaseServiceLocator(), which will return the GlassFish ServiceLocator, which has the LogManager in it.

Note that this "Globals" class is going to be scrutinized the in following months for a better mechanism for applications (such as the console) to get the GlassFish ServiceLocator but that for now using Globals is the best mechanism.

Comment by jwells [ 02/Jan/13 ]

I realized I should re-open this an assign it back since I haven't actually fixed it lol!

Comment by sandeep.shrivastava [ 04/Jan/13 ]

This should be fixed with revision 57956.





[GLASSFISH-19442]  @JMSConnectionFactoryDefinition ignores clientId attribute Created: 14/Dec/12  Updated: 16/Jan/13  Resolved: 16/Jan/13

Status: Resolved
Project: glassfish
Component/s: jms
Affects Version/s: 4.0_b47
Fix Version/s: 4.0_b71

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

Tags: jms-2-implementation

 Description   

If I define a JMS connection factory using the following annotation:

@JMSConnectionFactoryDefinition(
    name="java:global/jms/demoConnectionFactory",
    className= "javax.jms.ConnectionFactory",
    description="ConnectionFactory to use in demonstration",
    clientId="myClientID",
    resourceAdapterName="jmsra",
    user="guest",
    password="guest"
)  

then inject it into my session bean using:

    @Resource(lookup = "java:global/jms/demoConnectionFactory")
    ConnectionFactory connectionFactory;

use it to create a connection

Connection connection = connectionFactory.createConnection();

and then report the clientid

String clientId = connection.getClientID();
System.out.println("ClientID = "+clientId);

I get a value of null printed,

However if I change the annotation to

@JMSConnectionFactoryDefinition(
    name="java:global/jms/demoConnectionFactory",
    className= "javax.jms.ConnectionFactory",
    description="ConnectionFactory to use in demonstration",
    properties="clientId=myClientID",
    resourceAdapterName="jmsra",
    user="guest",
    password="guest"
)     

then the correct clientId is displayed.

Both ways to configure clientId should work.



 Comments   
Comment by Simon Meng [ 04/Jan/13 ]
@JMSConnectionFactoryDefinition(
    name="java:global/jms/demoConnectionFactory",
    className= "javax.jms.ConnectionFactory",
    description="ConnectionFactory to use in demonstration",
    clientId="myClientIDAttribute",
    properties="clientId=myClientIDProperty",
    resourceAdapterName="jmsra",
    user="guest",
    password="guest"
)    

If clientId is defined in both annotation attribute and property list, which one takes effect?

Comment by Nigel Deakin [ 04/Jan/13 ]

I would suggest processing the "properties" attribute after the other attributes.

Comment by Simon Meng [ 05/Jan/13 ]

Fixed at revision 57972.

Comment by saradak [ 11/Jan/13 ]

Reopening the bug as test is still failing with latest glassfish build(b-71)after the fix.

CTS test(Client_checkClientIDOnDurableConnFactoryTest) failed at getting client id that is defined in the annotation for the
connection factory. This fixed the descriptor version but not the annotation version.

-Sarada

Comment by Simon Meng [ 11/Jan/13 ]

getClientID works fine with the reporter provide sample.
How to get the CTS code and run it? I need check the failed case.

Comment by Simon Meng [ 16/Jan/13 ]

@JMSConnectionFactoryDefinition works fine. The root cause is in MQ, relative bug is MQ-270.





[GLASSFISH-19441] ConnectionFactory created using @JMSConnectionFactoryDefinition does not use default credentials Created: 14/Dec/12  Updated: 05/Jan/13  Resolved: 05/Jan/13

Status: Resolved
Project: glassfish
Component/s: jms
Affects Version/s: 4.0_b67_ms7
Fix Version/s: 4.0_b71

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

Attachments: Zip Archive JMS20Demo.zip     Text File server.log    
Tags: jms-2-implementation

 Description   

I have a simple application which defines a JMS connection factory using the following annotation:

@JMSConnectionFactoryDefinition(
    name="java:global/jms/demoConnectionFactory",
    className= "javax.jms.ConnectionFactory",
    description="ConnectionFactory to use in demonstration",
    resourceAdapterName="jmsra"
)  

It then uses the following annotation to inject a connection factory:

    @Resource(lookup = "java:global/jms/demoConnectionFactory")
    ConnectionFactory connectionFactory;

and uses it to create a connection:

Connection connection = connectionFactory.createConnection();

This fails with

SEVERE: com.sun.messaging.jmq.auth.api.FailedLoginException: [B4051]: Forbidden guest

See attached server log for the full exception.

To reproduce the problem, unzip the attached Netbeans project and deploy in GlassFish (I used build 67). The navigate directly to http://localhost:8080/JMS20Demo/Servlet1?option=JavaEESenderOld and look in the server log.

The code itself is in the session bean JavaEESenderOld. Note that the same business method also creates a connection using a connection factory defined in glassfish-resources.xml. That works fine using the default credentials.

A quick analysis of the exception in the debugger suggests that if the connection factory is created using glassfish-resources.xml then the password used us "guest", but if the connection factory is created using @JMSConnectionFactoryDefinition then the password used is "", which is invalid.

If you explicitly set user and password in @JMSConnectionFactoryDefinition then it works fine. The problem is if user/password is not set. A quick analysis in the debugger suggests that JMSRA is passing a correct user/password to the connection pool (using a javax.resource.spi.ConnectionRequestInfo). However the password is getting overridden somewhere.

This example was demonstrated at JavaOne in October 2012, and so is a regression since then.



 Comments   
Comment by Nigel Deakin [ 02/Jan/13 ]

Confirmed that this is still an issue with glassfish-4.0-b70-12_31_2012.

This is a regression since glassfish-4.0-b56-09_24_2012.

Comment by Simon Meng [ 04/Jan/13 ]

@JMSConnectionFactoryDefinition(
name="java:global/jms/demoConnectionFactory",
className= "javax.jms.ConnectionFactory",
description="ConnectionFactory to use in demonstration",
properties=

{"UserName=myuser", "Password=mypassword"}

,
resourceAdapterName="jmsra",
user="guest",
password="guest"
)

If user and password are defined in both annotation attribute and property list, which one takes effect?

Comment by Simon Meng [ 05/Jan/13 ]

Fixed at revision 57972.





[GLASSFISH-19419] properties are not persisted properly into the domain.xml file Created: 09/Dec/12  Updated: 09/Jan/13  Resolved: 09/Jan/13

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

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

jdk 7u9 x64 windows


Attachments: PNG File debug.png    

 Description   

using the latest postgresql jdbc jar (http://jdbc.postgresql.org/download/postgresql-9.2-1002.jdbc4.jar) I tried to configure a jdbc connection pool.

I used:
resource type of javax.sql.DataSource
database driver vendor: postgresql
introspect: not checked.

On the next page (after clicking 'next') I was presented with the usual suspects in terms of additional properties, and I populated these:

user
databaseName
password
serverName
portNumber

and hit 'finish'

the admin gui reported that the ping had failed.

I then checked the additional properties page, and found that only the 'user' value appeared.

I found that this was the only value for this connection pool that was present in the domain.xml file.



 Comments   
Comment by Anissa Lam [ 09/Dec/12 ]

Sounds like a gui issue. Will look into that

Comment by Anissa Lam [ 13/Dec/12 ]

I looked into this, and see that this is not specific to the JDBC properties. All the properties screen in the console cannot add properties correctly. So, I am bumping this up to P2.
In any property table, only one new property will be added even though the user adds more than 1 property.
I trace it down to the REST code and then the admin command. The 'set' command is called with the parameters map consisting of all the new properties.

In CommandRunnerImpl.goCommand:1420
report = doCommand(model, command, context, progressHelper);

The 'values' of command seems correct, consisting of all the new properties that should be set. (see attached debug image from debugger).

However, in the execute() method of SetCommand, it failed in the 2nd SetOperation, and thus didn't continue with setting the rest.
This corresponds to setting the description which is empty.
"resources.jdbc-connection-pool.DerbyPool.property.FIRST.description=""

Looks like setting the description field is the curlpit. Not sure if REST or admin code needs to be fixed.

I also narrowed it down to that promoted build 59 is still working fine, but b60 is showing this issue.

To reproduce this using console, follow this step
1. In the navigation tree, go to Resources -> JDBC -> JDBC Connection Pool -> Derby Pool
2. Go to the Additional Tab of Derby Pool
3. Add the pair of property: FIRST : firstValue and SECOND : secondValue
4. click Save.

You will then see that only FIRST is saved.

Comment by Tim Quinn [ 04/Jan/13 ]

Tom has correctly noted that this particular case has not worked since the changes in SetCommand to handle authorization.

He has also pointed out this easy CLI example which triggers the problem:

asadmin set resources.jdbc-connection-pool.DerbyPool.property.FIRST=firstValue resources.jdbc-connection-pool.DerbyPool.property.FIRST.description=bar

When first run, the command fail. If that command is repeated, it succeeds.

The underlying problem is that the current SetCommand implementation tries to find out some information about each operation specified on the command line as part of preparing the security access controls. Getting that information depends on the config hierarchy above the target being in place, and that is not true for the second part of the example "set" command above. That causes the current implementation's attempt to execute the second part to fail when the command is first run. On the second run, though, the expected parent is in place (established by the first part of the command) and the command succeeds.

Comment by Tim Quinn [ 09/Jan/13 ]

Fixes checked in.

Project: glassfish
Repository: svn
Revision: 58187
Author: tjquinn
Date: 2013-01-07 18:49:41 UTC
Link:

Log Message:
------------
Further fix for 19419

The new test in "prepare" for identifying a dotted name reference to a property assumed that the "property" string identifying that the target is a property would not be the first part of the string, but that's actually permitted. The GlassFish admin devtests revealed this.

Tests: the offending admin devtest

Revisions:
----------
58187

Modified Paths:
---------------
trunk/main/nucleus/core/kernel/src/main/java/com/sun/enterprise/v3/admin/SetCommand.java

===========================================================================================
Project: glassfish
Repository: svn
Revision: 58181
Author: tjquinn
Date: 2013-01-07 15:42:21 UTC
Link:

Log Message:
------------
Fix for 19419

Earlier changes to allow us to authorize each name/value pair separately did not correctly handle cases in which a later name/value pair's validity depended on the successful execution of an earlier name/value pair assignment.

This change returns the set command implementation closer to its original implementation. We still need to do some preparation work as part of preAuthorization, before each name/value pair assignment is actually performed, but the new implementation works for the case described above.

Tests: QL, admin devtests

Revisions:
----------
58181

Modified Paths:
---------------
trunk/main/nucleus/core/kernel/src/main/java/com/sun/enterprise/v3/admin/SetCommand.java





[GLASSFISH-19402] Syslog logging utf-8 bug and message formatting Created: 04/Dec/12  Updated: 03/Jan/13  Resolved: 03/Jan/13

Status: Resolved
Project: glassfish
Component/s: logging
Affects Version/s: 3.1.2.2
Fix Version/s: 4.0_b71

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

Linux



 Description   

1- If the java logged message contains UTF-8 multi-bytes characters, the syslog message is truncated.

Syslog.java use the following code :
DatagramPacket dp = new DatagramPacket(what.getBytes(), what.length(), addr, PACKET_SIZE);

what.length() should take care of UTF-8 strings containing multi-byte characters.

2- Syslog enabled logging (SyslogHandler.java) does not manage MessageFormat messages
ConsoleHandler use UniformLogFormatter which use MessageFormat to handle formatted messages with parameters.
SyslogHandler.java does not.



 Comments   
Comment by sandeep.shrivastava [ 03/Jan/13 ]

This should be fixed with revision 57921.





[GLASSFISH-19320] javax.servlet.ReadListener#onDataAvailable is never called Created: 12/Nov/12  Updated: 08/Jan/13  Resolved: 08/Jan/13

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

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

Attachments: Zip Archive read-listener.zip    

 Description   

I'm working on Websocket spec implementation and I need to integrate with servlet (3.1). I'm registering my own ProtocolHandler which registers new ReadListener to ServletInputStream and I would expect that onDataAvailable method will be called when entity arrives.

Testcase attached; deploy war file and run org.glassfish.bugs.Test (it creates Jersey client and sends POST request to created filter). I can see "##### data.read: 109|#]" in the log file, but "##### OnDataAvailable" is not there and onDataAvailable(), thus onDataAvailable is not called (verified in debugging session).



 Comments   
Comment by Amy Roh [ 12/Nov/12 ]

FYI, we have a testcase using a ReadListener where onDataAvailable is called in http://java.net/projects/glassfish/sources/svn/show/trunk/v2/appserv-tests/devtests/web/servlet-3.1/upgradeEcho. See upgradeEcho/servlet/test/EchoProtocolHandler.java. I will investigate why this isn't working for your testcase.





[GLASSFISH-19311] GenericDeleteCommand.java assumes clustering Created: 09/Nov/12  Updated: 03/Jan/13  Resolved: 03/Jan/13

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

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


 Description   

It requires copy-config cmd which is related to clustering.



 Comments   
Comment by Tom Mueller [ 03/Jan/13 ]

Fixed on the trunk in revision 57927.





[GLASSFISH-19289] Move javax.interceptor to its own module Created: 06/Nov/12  Updated: 25/Jan/13  Resolved: 25/Jan/13

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

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

Tags: ejb_3_2

 Description   

Interceptors spec is no longer part of the EJB spec, so its API should be in their own module



 Comments   
Comment by marina vatkina [ 25/Jan/13 ]

Fixed by Romain. See api/javaee-api/javax.interceptor





[GLASSFISH-19214] Implementation of Upgrade in Servlet 3.1 Created: 23/Oct/12  Updated: 15/Jan/13  Resolved: 15/Jan/13

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

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


 Description   

Need to implement the upgrade mechanism in Servlet 3.1



 Comments   
Comment by Shing Wai Chan [ 15/Jan/13 ]

The trunk has code according to Servlet 3.1 Public Review.





[GLASSFISH-19213] Implementation of Non-blocking IO for Servlet 3.1 Created: 23/Oct/12  Updated: 15/Jan/13  Resolved: 15/Jan/13

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

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


 Description   

Need to implement non-blocking IO features in Servlet 3.1



 Comments   
Comment by Shing Wai Chan [ 15/Jan/13 ]

The trunk has code according to Servlet 3.1 Public Review.





Support for Common Resource Infrastructure (GLASSFISH-19172)

[GLASSFISH-19179] Support for deployment order for resources Created: 18/Oct/12  Updated: 08/Jan/13  Resolved: 08/Jan/13

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

Type: Sub-task 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


 Description   

http://aseng-wiki.us.oracle.com/asengwiki/display/GlassFish/Deployment+Order+for+GF+resources+to+be+in-line+with+current+WLS+support

Needs to have a way for the kinds of deployment artifacts to be ordered so that when the server starts, the artifacts are deployed in the desired order. In addition, BG needs a way to order the artifacts that are the same kind to that they are deployed in the desired order.



 Comments   
Comment by naman_mehta [ 08/Jan/13 ]

Made changes to support Resource Deployment Order for BG.
http://aseng-wiki.us.oracle.com/asengwiki/display/GlassFish/BG+Deployment+Order+One+Pager

Run all required tests.

Revisions:
58201





[GLASSFISH-19156] Handle Throwable parameter in logging calls Created: 15/Oct/12  Updated: 16/Jan/13  Resolved: 16/Jan/13

Status: Resolved
Project: glassfish
Component/s: logging
Affects Version/s: 4.0_b01
Fix Version/s: 4.0_b71

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

Tags: EE7_GF4

 Description   

We need a way to pass Throwable in a localized log call and print the stack trace in the log file. The usage will be something like:

@LogMessageInfo(message = "Error unbinding ejb bundle [

{0}

] dependency namespace")
public static final String EJB_ERROR_UNBINDING_BUNDLE = "AS-EJB-00003"

Object params[] =

{ ejbBundle.getModuleName(), e }

; // pass Throwable as the last parameter
_logger.log( Level.WARNING, EJB_ERROR_UNBINDING_BUNDLE, params);

The formatter should handle the Throwable (passed as a last parameter) in a way so that the stacktrace is printed in the log file.



 Comments   
Comment by sandeep.shrivastava [ 24/Oct/12 ]

This issue is now fixed with revision svn revision #56710.

Comment by sandeep.shrivastava [ 24/Oct/12 ]

Users should now be able to pass in a Throwable as the last param in the log method invocation and it will appear in the log message body.

@LogMessageInfo(message = "Cannot read test configuration file

{0}

", level="SEVERE",
cause="An exception has occurred while reading the logging configuration file.",
action="Take appropriate action based on the exception message.")
public static final String ERROR_READING_TEST_CONF_FILE = "TEST-LOGGING-00001";

LOGGER.log(Level.SEVERE, ERROR_READING_TEST_CONF_FILE,
new Object[]

{TEST_CONF_FILE, new Exception(TEST_EXCEPTION_MESSAGE)}

);

Comment by Sanjeeb Sahoo [ 10/Jan/13 ]

This fix should be rolledback. Any behavior which is not guaranteed by JUL will cause our code to behave differently when it gets embedded in other environment which may not have the JUL extensions installed. We may not even have the opportunity to install JUL extensions as the embedder decides the platform.

Comment by sandeep.shrivastava [ 16/Jan/13 ]

The formatter enhancement has been rolled back and there is a LogHelper API provided. This is submitted via change 58568.





[GLASSFISH-19141] EJB 3.2 Make sure SessionContext is thread safe in Singletons Created: 10/Oct/12  Updated: 25/Jan/13  Resolved: 25/Jan/13

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

Type: New Feature Priority: Major
Reporter: marina vatkina Assignee: marina vatkina
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: ejb_3_2

 Description   

EJB 3.2 spec states: "Independent of the bean's concurrency management type, the container must ensure that concurrent access to the SessionContext object is thread-safe."



 Comments   
Comment by marina vatkina [ 25/Jan/13 ]

The only method that requires extra synchronization is lookup()

Comment by marina vatkina [ 25/Jan/13 ]

Fixed with rev 58795





[GLASSFISH-18960] Cleanup non logging related dependencies from logging code. Created: 30/Jul/12  Updated: 04/Jan/13  Resolved: 04/Jan/13

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

Type: Bug Priority: Minor
Reporter: sandeep.shrivastava Assignee: sandeep.shrivastava
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 5 days
Time Spent: Not Specified
Original Estimate: 5 days


 Description   

This bug is being filed to refactor the non-logging related dependencies out of the logging code in GlassFish.

Here is a description of the problem reported by Amy Kang.

We'd like to have only dependency to logger module for logging usages. For example the dependency on GlassFish's Version.java in UniformLogFormatter.java caused it to pull in a whole lot of stuff for it's in comm-util.jar which has classes that can not be loaded arbitrarily in GlassFish environment - that causes problem if MQ running embedded in GlassFish also needs to load comm-util.jar.



 Comments   
Comment by sandeep.shrivastava [ 04/Jan/13 ]

This should be fixed with revision 57955.





[GLASSFISH-18956] asadmin --property preserves leading/trailing spaces in property name Created: 30/Jul/12  Updated: 09/Jan/13  Resolved: 09/Jan/13

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

Type: Bug Priority: Minor
Reporter: Paul Benedict Assignee: Tom Mueller
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The format of the properties are "p1=v1:p2=v2". I am setting these via ant but if spaces lead/trail the property name, those are preserved. These should be trimmed. I don't see a valid use case while they would be preserved.

<exec executable="asadmin.bat" failonerror="true">
  <arg value="some-command" />
  <arg value="--property" />
  <arg value="
    property1=helloworld:
    property2=2525:
    property3=true" />
</exec>


 Comments   
Comment by Tom Mueller [ 09/Jan/13 ]

Fixed on the trunk in revision 58237.

Now leading and trailing space on property names is ignored.





[GLASSFISH-18862] NPE in logging annotation processor when not doing clean build Created: 03/Jul/12  Updated: 18/Jan/13  Resolved: 18/Jan/13

Status: Resolved
Project: glassfish
Component/s: logging
Affects Version/s: 4.0_b43
Fix Version/s: 4.0_b71

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

Linux/jdk1.6_31/maven 3



 Description   

Running the following command on a module which was already built but only one file needed recompilation
mvn -f appserver/common/glassfish-naming/pom.xml install

resulted in build error decsribed at [1], but if I do clean install, then it succeeds. So, this is definitely a bug in the annotation processor.

[INFO] Compiling 1 source file to /space/ss141213/WS/gf/trunk/appserver/common/glassfish-naming/target/classes
error: org.glassfish.annotation.processing.logging.LogMessagesResourceBundleGenerator: Resource bundle name not specified for logger
...

An annotation processor threw an uncaught exception.
Consult the following stack trace for details.
java.lang.NullPointerException
at org.glassfish.annotation.processing.logging.LogMessagesResourceBundleGenerator.getRBFileObject(LogMessagesResourceBundleGenerator.java:246)
at org.glassfish.annotation.processing.logging.LogMessagesResourceBundleGenerator.loadLogMessages(LogMessagesResourceBundleGenerator.java:186)
at org.glassfish.annotation.processing.logging.LogMessagesResourceBundleGenerator.process(LogMessagesResourceBundleGenerator.java:149)
at com.sun.tools.javac.processing.JavacProcessingEnvironment.callProcessor(JavacProcessingEnvironment.java:627)
at com.sun.tools.javac.processing.JavacProcessingEnvironment.discoverAndRunProcs(JavacProcessingEnvironment.java:556)
at com.sun.tools.javac.processing.JavacProcessingEnvironment.doProcessing(JavacProcessingEnvironment.java:701)
at com.sun.tools.javac.main.JavaCompiler.processAnnotations(JavaCompiler.java:987)
at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:727)
at com.sun.tools.javac.main.Main.compile(Main.java:353)
at com.sun.tools.javac.main.Main.compile(Main.java:279)
at com.sun.tools.javac.main.Main.compile(Main.java:270)
at com.sun.tools.javac.Main.compile(Main.java:69)
at com.sun.tools.apt.main.Main.compile(Main.java:1071)
at com.sun.tools.apt.Main.processing(Main.java:95)
at com.sun.tools.apt.Main.process(Main.java:85)
at com.sun.enterprise.module.maven.HK2CompileMojo$1.compileInProcess(HK2CompileMojo.java:126)
at com.sun.enterprise.module.maven.AptCompiler.compile(AptCompiler.java:106)
at org.apache.maven.plugin.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:528)
at com.sun.enterprise.module.maven.CompilerMojo.execute(CompilerMojo.java:155)
at com.sun.enterprise.module.maven.HK2CompileMojo.execute(HK2CompileMojo.java:140)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
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.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.glassfish.hk2:hk2-maven-plugin:2.0.4:hk2-compile (default-hk2-compile) on project glassfish-naming: Fatal error compiling: APT failed: 3 -> [Help 1]
[ERROR]



 Comments   
Comment by naman_mehta [ 03/Jul/12 ]

Assigning to Sandeep to look into this...

Comment by michael.cico [ 07/Sep/12 ]

I've run into what seems like a different manifestation of this. At times I will get errors like the following when running a "mvn install", which can usually be worked around by running a "mvn clean install":

[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:2.4:compile (default-compile) on project diagnostics-services: Compilation failure: Compilation failure:
[ERROR] error: org.glassfish.annotation.processing.logging.LogMessagesResourceBundleGenerator: No resource bundle name found. Atleast one String literal constant needs to be decorated with the LogMessagesResourceBundle annotation.
[ERROR] error: org.glassfish.annotation.processing.logging.LoggerInfoMetadataGenerator: Unable to generate LoggerMetadataInfoService class: null
[ERROR] -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:2.4:compile (default-compile) on project diagnostics-services: Compilation failure

The annotations are defined properly, and as mentioned this goes away with a "clean install".

Comment by rajendra_inamdar [ 07/Sep/12 ]

This am able to reproduce this by touching a source file and running mvn install, which resulted in the following (with a change to annotation processor to print stacktrace):

java.lang.UnsupportedOperationException
at com.sun.tools.javac.util.DefaultFileManager$RegularFileObject.openReader(DefaultFileManager.java:1299)
at javax.tools.ForwardingFileObject.openReader(ForwardingFileObject.java:74)
at org.glassfish.annotation.processing.logging.BaseLoggingProcessor.loadLogMessages(BaseLoggingProcessor.java:103)
at org.glassfish.annotation.processing.logging.LoggerInfoMetadataGenerator.generateLoggerInfoMetadataService(LoggerInfoMetadataGenerator.java:171)
at org.glassfish.annotation.processing.logging.LoggerInfoMetadataGenerator.process(LoggerInfoMetadataGenerator.java:131)
at com.sun.tools.javac.processing.JavacProcessingEnvironment.callProcessor(JavacProcessingEnvironment.java:627)
at com.sun.tools.javac.processing.JavacProcessingEnvironment.discoverAndRunProcs(JavacProcessingEnvironment.java:556)
at com.sun.tools.javac.processing.JavacProcessingEnvironment.doProcessing(JavacProcessingEnvironment.java:701)
at com.sun.tools.javac.main.JavaCompiler.processAnnotations(JavaCompiler.java:987)
at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:727)
at com.sun.tools.javac.main.Main.compile(Main.java:353)
at com.sun.tools.javac.main.Main.compile(Main.java:279)
at com.sun.tools.javac.main.Main.compile(Main.java:270)
at com.sun.tools.javac.Main.compile(Main.java:87)
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.codehaus.plexus.compiler.javac.JavacCompiler.compileInProcess0(JavacCompiler.java:554)
at org.codehaus.plexus.compiler.javac.JavacCompiler.compileInProcess(JavacCompiler.java:530)
at org.codehaus.plexus.compiler.javac.JavacCompiler.compile(JavacCompiler.java:165)
at org.apache.maven.plugin.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:627)
at org.apache.maven.plugin.CompilerMojo.execute(CompilerMojo.java:128)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
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.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)

Comment by sandeep.shrivastava [ 31/Oct/12 ]

Committed revision 56815 for the logging-annotation-processor which emits a warning message instead of an error when either the LogMessages resource bundle name or set of LogMessageInfo annotations is empty. This should be available when the GlassFish build is revved to 1.3 version of this module.

Comment by Romain Grécourt [ 03/Dec/12 ]

Seems like the preprocessor limits the glassfish build.
It could instead be implemented as a maven plugin, and instrospect the compiled classes under $

{project.build.outputDirectory}

.

Since the plugin will likely run against all modules, it could be convenient to provide a way to skip the execution.
the plugin configuration will define something like:

<configuration>
    <skip>${loggingPlugin.skip}</skip>
</configuration>

A module that wants to skip the execution of the logging plugin could do the following:

<properties>
   <loggingPlugin.skip>true</loggingPlugin.skip>
</properties>
Comment by sandeep.shrivastava [ 18/Jan/13 ]

Committed revision 58655. Revved the logging-annotation-processor module to version 1.3 which includes the fix to support incremental build. The build output contains a META-INF/logmessages/LogMessagesMetadata.properties file which includes the name of the package for the LogMessages.properties resource for the module that is used when not building from scratch.





[GLASSFISH-18806] Thread used to process AdminAdapter request has context class loader set Created: 14/Jun/12  Updated: 07/Jan/13  Resolved: 07/Jan/13

Status: Resolved
Project: glassfish
Component/s: grizzly-kernel
Affects Version/s: 4.0_b41
Fix Version/s: 4.0_b71

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


 Description   

The AdminAdapter is a Grizzly Adapter. When the onMissingResource method is called, the context class loader is already set in the Thread. It isn't clear where this is being set. Is it from some previous request that used that thread? Is Grizzly setting this?

The class loader is a Felix class loader.

It seems that a thread used to process a Grizzly request should not have the context class loader already set.



 Comments   
Comment by oleksiys [ 15/Jun/12 ]

it happens on admin port, right?
does admin console use Grizzly "servlet" container?

Comment by Tom Mueller [ 15/Jun/12 ]

Yes, this is on the admin port.
AdminAdapter extends org.glassfish.grizzly.http.server.StaticHttpHandler

Sorry for the reference to "Grizzly Adapter" above, that should have been Grizzly StaticHttpHandler.

Comment by Ryan Lubke [ 20/Jun/12 ]

I've verified that the only location that Grizzly ever calls setContextClassLoader() is within our Servlet container code, which doesn't appear to be used here.

Given this, I've set a break point in Thread.setContextClassLoader() and have found the following:

  • initial request received; context classloader set to felix classloader by HK2Dispatcher

at com.sun.enterprise.v3.server.HK2Dispatcher.dispatch(HK2Dispatcher.java:111)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:236)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:164)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:169)

  • the AdminAdapter is invoked by the dispatch call:

at com.sun.enterprise.v3.admin.AdminAdapter.onMissingResource(AdminAdapter.java:232)
at org.glassfish.grizzly.http.server.StaticHttpHandler.service(StaticHttpHandler.java:298)
at com.sun.enterprise.v3.server.HK2Dispatcher.dispatch(HK2Dispatcher.java:113)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:236)

Comment by Tom Mueller [ 20/Jun/12 ]

Ryan, thanks for finding this.
I see that HK2Dispatcher just set the thread context class loader to be the class loader for the adapter class. Any idea why it does this?

Comment by Ryan Lubke [ 20/Jun/12 ]

I can't really say. This is Jerome's code - and based on svn annotation output, this class has remained mostly unchanged since '07.

Comment by Tom Mueller [ 24/Dec/12 ]

Reassigning to the hk2 component.

The HK2Dispatcher class (in the nucleus/core/kernel) module is setting the context class loader for requests that are handled by an HttpAdapter to the adapter class loader even when the context class loader that is passed in for that class is null. It isn't clear why the HK2Dispatcher class is doing this. It isn't even clear why we have the HK2Dispatcher class, since most of it is commented out now.

Please evaluate whether HK2Dispatcher is still needed and if it isn't, then delete it.

Comment by jwells [ 07/Jan/13 ]

I have removed HK2Dispatcher. However, I replicated the code that was setting the CCL in ContainerMapper since I did not want to break anything. However, that should make it clear that it has nothing to do with HK2 anymore.

If you look at ContainerMapper you will see the method I added. It does make the logic more clear and obviously can now be handled directly in the ContainerMapper without worrying about how it would affect anything else.

Comment by jwells [ 07/Jan/13 ]

I would also like to add that I have no idea why this code used to set the CCL to the adapter if no ClassLoader was passed to it. To me that doesn't seem correct in this instance...

Comment by Ryan Lubke [ 07/Jan/13 ]

After a brief discussion with Tom, we both agree we'll probably never really know the purpose of this code and to go ahead and try to remove it.

Comment by Ryan Lubke [ 07/Jan/13 ]

Sending nucleus/core/kernel/src/main/java/com/sun/enterprise/v3/services/impl/ContainerMapper.java
Transmitting file data .
Committed revision 58191.





[GLASSFISH-16236] RunAs does not propagate Identity from Servlet.init Created: 18/Mar/11  Updated: 03/Jan/13  Resolved: 03/Jan/13

Status: Resolved
Project: glassfish
Component/s: security, web_container
Affects Version/s: 3.1_b43
Fix Version/s: 4.0_b71

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

java version "1.6.0_23"
Java(TM) SE Runtime Environment (build 1.6.0_23-b05)
Java HotSpot(TM) 64-Bit Server VM (build 19.0-b09, mixed mode)


Attachments: File runastest.ear    
Tags: 3_1_1-scrubbed, 3_1_2-exclude, init, runas, servlet

 Description   

Calls to Injected EJB in a Servlet are not propagated when calling the EJB from init.
Per Servlet Spec Appendix 8:
"Clarification: "run-as" identity must apply to all calls from a servlet including
init() and destroy() (12.7)"

See forum discussion http://www.java.net/forum/topic/glassfish/glassfish/security-identity-propogation-servlet-runas?force=641

See attached Example Application EAR. The example application deploys an ejb and web module.

The EJB module deploys 2 beans:

package runasejb;

import javax.annotation.Resource;
import javax.annotation.security.DeclareRoles;
import javax.annotation.security.PermitAll;
import javax.ejb.SessionContext;
import javax.ejb.Stateless;

/**

  • The RunAsEJB is declares SystemRole as a used role. This is defined
  • in the application.xml and sun-application.xml. The EJB has two methods
  • to return the string value of the caller principal and boolean value
  • if the caller has SystemRole
  • @author joel@stewbeans.com
    */
    @Stateless
    @DeclareRoles("SystemRole")
    @PermitAll
    public class RunAsEJB
    {

@Resource
SessionContext context;

public String getCallerPrincipal()

{ return context.getCallerPrincipal().getName(); }

public boolean isCallerInSystemRole(){ return context.isCallerInRole("SystemRole"); }
}



package runasejb;

import javax.annotation.Resource;
import javax.annotation.security.DeclareRoles;
import javax.annotation.security.PermitAll;
import javax.ejb.SessionContext;
import javax.ejb.Stateless;

/**
* The RunAsEJB declares SystemRole as a used role. This is defined
* in the application.xml and sun-application.xml. The EJB has two methods
* to return the string value of the caller principal and boolean value
* if the caller has SystemRole
* @author joel@stewbeans.com
*/
@Stateless
@DeclareRoles("SystemRole")
@PermitAll
public class RunAsEJB
{

@Resource
SessionContext context;

public String getCallerPrincipal()
{ return context.getCallerPrincipal().getName(); }

public boolean isCallerInSystemRole()

{ return context.isCallerInRole("SystemRole"); }

}

The Web Module has servlet:

package runastest;

import java.io.IOException;
import java.util.logging.Logger;
import javax.annotation.PostConstruct;
import javax.annotation.security.RunAs;
import javax.ejb.EJB;
import javax.servlet.ServletContextEvent;
import javax.servlet.ServletContextListener;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import runasejb.RunAsEJB;

/**

  • The StartupServlet declares runas SystemRole. The
  • injected TestRunAsEJB should be passed the SystemRole identity as
  • configured in the web.xml / sun-web.xml
  • @author joel@stewbeans.com
    */
    @RunAs("SystemRole")
    public class StartupServlet extends HttpServlet implements ServletContextListener{

Logger log = Logger.getLogger(StartupServlet.class.getName());

@EJB
RunAsEJB runAsEJB;

@Override
public void contextInitialized(ServletContextEvent sce)

{ log.info("In StartupServlet contextInitialized()"); }

@PostConstruct
public void postConstruct()

{ log.info("In StartupServlet postConstruct()"); }

/**

  • Init is called after &PostConstruct and ServletContextListener Context initialized.
    */
    public void init(){
    log.info("In StartupServlet init()");

String val = runAsEJB.getCallerPrincipal();

if ("SystemUser".equals(val))

{ log.info("StartupServlet propagates SystemUser Principal."); }

else

{ log.warning("StartupServlet did NOT propagate SystemUser Principal."); }

if (runAsEJB.isCallerInSystemRole())

{ log.info("StartupServlet propogates SystemRole Role."); }

else

{ log.warning("StartupServlet did NOT propagate SystemRole Role"); }

}

protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException{

log.info("In StartupServlet doGet()");

String val = runAsEJB.getCallerPrincipal();

if ("SystemUser".equals(val))

{ log.info("StartupServlet.doGet() propagates SystemUser Principal."); }

else

{ log.warning("StartupServlet.doGet() did NOT propagate SystemUser Principal."); }

if (runAsEJB.isCallerInSystemRole())

{ log.info("StartupServlet.doGet() propogates SystemRole Role."); }

else

{ log.warning("StartupServlet.doGet() did NOT propagate SystemRole Role"); }

}

@Override
public void contextDestroyed(ServletContextEvent sce)
{

}
}

The Web Module has deployment descriptors:

<?xml version="1.0" encoding="UTF-8"?>
<web-app version="3.0" 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-app_3_0.xsd">

<listener>
<listener-class>runastest.StartupServlet</listener-class>
</listener>

<servlet>
<servlet-name>RunAsTest</servlet-name>
<servlet-class>runastest.StartupServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>

<servlet-mapping>
<servlet-name>RunAsTest</servlet-name>
<url-pattern>/*</url-pattern>
</servlet-mapping>

<!-- Form authentication configuration parameters -->
<login-config>
<auth-method>FORM</auth-method>
<realm-name>admin-realm</realm-name>
</login-config>

<security-role>
<description/>
<role-name>SystemRole</role-name>
</security-role>

</web-app>

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE sun-web-app PUBLIC "-//Sun Microsystems, Inc.//DTD GlassFish Application Server 3.0 Servlet 3.0//EN" "http://www.sun.com/software/appserver/dtds/sun-web-app_3_0-0.dtd">
<sun-web-app error-url="">
<context-root>/RunAsTestEar-war</context-root>
<class-loader delegate="true"/>
<jsp-config>
<property name="keepgenerated" value="true">
<description>Keep a copy of the generated servlet class' java code.</description>
</property>
</jsp-config>
</sun-web-app>

(note the security-role-mapping is defined in application.xml - addign to sun-web.xml as well makes no difference)

The application has descriptors
<?xml version="1.0" encoding="UTF-8"?>
<application version="6" 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/application_6.xsd">
<display-name>RunAsTest</display-name>
<module>
<ejb>RunAsTestEar-ejb.jar</ejb>
</module>
<module>
<web>
<web-uri>RunAsTestEar-war.war</web-uri>
<context-root>runastest</context-root>
</web>
</module>
<security-role>
<role-name>SystemRole</role-name>
</security-role>
</application>

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE sun-application PUBLIC "-//Sun Microsystems, Inc.//DTD GlassFish Application Server 3.0 Java EE Application 6.0//EN" "http://www.sun.com/software/appserver/dtds/sun-application_6_0-0.dtd">
<sun-application>
<security-role-mapping>
<role-name>SystemRole</role-name>
<principal-name>SystemUser</principal-name>
</security-role-mapping>
<realm>admin-realm</realm>
</sun-application>

Startup Logging Output:
WARNING: Realm admin-realm: com.sun.enterprise.security.auth.realm.NoSuchUserException: No such user [SystemUser].
WARNING: Realm admin-realm: com.sun.enterprise.security.auth.realm.NoSuchUserException: No such user [SystemUser].
WARNING: DPL8019: The run-as principal SystemUser was assigned by the deployment system based on the specified role. Please consider defining an explicit run-as principal in the sun-specific deployment descriptor.
WARNING: DPL8019: The run-as principal SystemUser was assigned by the deployment system based on the specified role. Please consider defining an explicit run-as principal in the sun-specific deployment descriptor.
INFO: Portable JNDI names for EJB RunAsEJB : [java:global/RunAsTestEar/RunAsTestEar-ejb/RunAsEJB, java:global/RunAsTestEar/RunAsTestEar-ejb/RunAsEJB!runasejb.RunAsEJB]
INFO: Portable JNDI names for EJB SingletonEJB : [java:global/RunAsTestEar/RunAsTestEar-ejb/SingletonEJB, java:global/RunAsTestEar/RunAsTestEar-ejb/SingletonEJB!runasejb.SingletonEJB]
WARNING: Realm admin-realm: com.sun.enterprise.security.auth.realm.NoSuchUserException: No such user [SystemUser].
WARNING: Realm admin-realm: com.sun.enterprise.security.auth.realm.NoSuchUserException: No such user [SystemUser].
INFO: In SingletonEJB PostConstruct
INFO: SingletonEJB propagates SystemUser Principal.
INFO: SingletonEJB propogates SystemRole Role.
INFO: In StartupServlet postConstruct()
INFO: In StartupServlet contextInitialized()
INFO: In StartupServlet postConstruct()
INFO: In StartupServlet init()
WARNING: StartupServlet did NOT propagate SystemUser Principal.
WARNING: StartupServlet did NOT propagate SystemRole Role
INFO: WEB0671: Loading application RunAsTestEar#RunAsTestEar-war.war at [runastest]
INFO: RunAsTestEar was successfully deployed in 551 milliseconds.

Access the Servlet get method at /runastest and you will see output:
INFO: In StartupServlet doGet()
INFO: StartupServlet.doGet() propagates SystemUser Principal.
INFO: StartupServlet.doGet() propogates SystemRole Role.

CONCLUSION:
1_ Caller identity IS propagated from the Startup EJB post construct.
2_ The Servlet init method does NOT propagate the caller identity !!!!BUG!!!!
3_ Caller identity IS propagated from Servlet Get (telling me the configuration is correct).
4_ (also - the PostConstruct on the servlet is called twice BUG)



 Comments   
Comment by joelstewart [ 18/Mar/11 ]

SingletonEJB source code:

package runasejb;

import java.util.logging.Logger;
import javax.annotation.PostConstruct;
import javax.annotation.security.RunAs;
import javax.ejb.EJB;
import javax.ejb.Singleton;
import javax.ejb.Startup;
import javax.ejb.Stateless;

/**

  • The SingletonEJB demonstrates how StartupEJBs properly assume the
  • SystemUser identity in PostConstruct.
  • @author joel@stewbeans.com
    */
    @Singleton
    @Startup
    @RunAs("SystemRole")
    public class SingletonEJB {

Logger log = Logger.getLogger(SingletonEJB.class.getName());

@EJB
RunAsEJB runAsEJB;

@PostConstruct
public void postConstruct(){
log.info("In SingletonEJB PostConstruct");

String val = runAsEJB.getCallerPrincipal();

if ("SystemUser".equals(val))

{ log.info("SingletonEJB propagates SystemUser Principal."); }

else

{ log.warning("SingletonEJB did NOT propagate SystemUser Principal."); }

if (runAsEJB.isCallerInSystemRole())

{ log.info("SingletonEJB propogates SystemRole Role."); }

else

{ log.warning("SingletonEJB did NOT propagate SystemRole Role"); }

}
}

Comment by Hong Zhang [ 18/Mar/11 ]

assign to Shingwai for initial evaluation

Comment by Shing Wai Chan [ 21/Mar/11 ]

Need clarifications on Servlet spec on @RunAs for init / destroy.

Comment by joelstewart [ 25/Mar/11 ]

Can I assist you in clarification?

The Spec: JSR-000315 Java(tm) Servlet 3.0 Specification ("Specification")
Version: 3.0
Status: Final Release
Release: 10 December 2009

Appendix A.8 page 202.

The next to last bullet point:

  • Clarification: “run-as” identity must apply to all calls from a servlet including
    init() and destroy() (12.7)
Comment by Shing Wai Chan [ 02/Jun/11 ]

The following is comment from Ron Monzillo:


I took a closer look at the spec, and in "A.8 Changes Since Servlet 2.3", it states

Clarification: “run-as” identity must apply to all calls from a servlet including init() and destroy() (12.7)

I can't find any such clarification in the section 12.7 or in the security chapter, so the clarification may have been
lost, but the appendix clearly notes the intent, and thus I think it is is required that a specified run-as identity be in effect during init() and destroy().

Note that section 15.3.1 Propagation of Security Identity in EJB Calls, requires that propagation occur whenever
an ejb is called by a servlet (without consideration of the Servlet method form which the ejb call is made). That may be going too far, but it would at least support that run-as should be honored within init(); where it is has become common practice to invoke ejbs, and where (unlike the case of calls to ejbs from servlet context listeners), there is a mapping to a specific servlet on which to look for a run-as specification.

bullet 5 under section "2.3.3.3 Asynchronous processing", made some clarification wrt to Asynchronous processing,
which may have resulted in some reconsideration or simplification of the clarification for init() and destroy(), but unless there was an explicit decision to rescind the prior clarification, I think the RI must ensure that runas is set during init() and destroy().

please note that when a run-as identity is set by annotation, the annotation has no effect on init() and destory() unless those methods are declared (i.e., overridden) in the servlet implementation class.


We may like to clarify the spec and do the corresponding implementation.

Comment by scatari [ 02/Jun/11 ]

Needs to be clarified in the spec.

Comment by Shing Wai Chan [ 07/Aug/12 ]

assign to security team

Comment by Shing Wai Chan [ 23/Oct/12 ]

Per discussion with Michael, we will change this to "Improvement" for tracking purpose.

Comment by jazheng [ 03/Jan/13 ]

Sending appserver/security/webintegration/src/main/java/com/sun/web/security/RealmAdapter.java
Sending appserver/web/web-glue/src/main/java/com/sun/enterprise/web/WebComponentInvocation.java
Sending appserver/web/web-glue/src/main/java/com/sun/web/server/J2EEInstanceListener.java
Sending nucleus/common/glassfish-api/src/main/java/org/glassfish/api/invocation/ComponentInvocation.java

Committed revision 57924.

Cause of the problem:
The web security event handler needs to retrieve RunAs based on the servletName, but servletName is not available from servlet instance before servlet.init() is called.

Changes:
Add an optional instanceName field to ComponentInvocation/WebComponentInvocation, so the event handler can retrieve it later.





[GLASSFISH-6703] Durable subscriber Topic test failed against IBM MQ Created: 03/Nov/08  Updated: 28/Feb/13  Resolved: 28/Feb/13

Status: Resolved
Project: glassfish
Component/s: jms
Affects Version/s: v2.1
Fix Version/s: 4.0_b71

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

Operating System: All
Platform: All


Attachments: Text File server.log    
Issuezilla Id: 6,703

 Description   

OS: soarlis
build: promoted build 58
This is a GRA test failiure.
summary: Durable subscriber Topic test failed to deploy against IBM MQ. However,
with the same setup/configuration, all other GRA test cases passed. Only the
durable subscriber test had the problem.
Test description:
Servlet calls EJB method which sends a message to a topic that is a durable
subscriber. Server is restarted and servlet checks that the message is received.
Steps to reproduce the bug:
1. Install V2 promoted build 56. 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 co-gra
3.set env. variables
S1AS_HOME <as install dir>
SPS_HOME <appserver-sqe>
ANT_HOME
JAVA_HOME
4. cd appserver-sqe/pe/, open file config.properties, modify admin.user,
admin.password, admin.port... values based on your AS install information
5. follow the following README file to setup IBM MQ to run GRA test:
http://server-rel.red.iplanet.com/h/nimitz.red.iplanet.com/export2/GRA/GRA2.0/GRA_IBMMQ_Readme.html
5. cd appserver-sqe/pe/genericra/test15, run command
ant build deploy run
The test failed to deploy the test application. The server.log shows the
following error:
[#|2008-11-03T14:52:18.110-0800|WARNING|sun-appserver9.1|javax.enterprise.system.stream.err|_ThreadID=14;_ThreadName=httpSSLWorkerThread-4848-0;_RequestID=c72cb32f-3716-4de3-bc63-775b5e305ecb;|
javax.resource.ResourceException: MQJMS5053: *** No broker response. Please
ensure that the broker is running. If you are using the WebSphere MQ broker
check that your brokerVersion is set to V1 ***
at
com.sun.genericra.util.ExceptionUtils.newResourceException(ExceptionUtils.java:73)
at
com.sun.genericra.inbound.async.EndpointConsumer._start(EndpointConsumer.java:131)
at com.sun.genericra.inbound.async.EndpointConsumer.start(EndpointConsumer.java:83)
at com.sun.genericra.GenericJMSRA.endpointActivation(GenericJMSRA.java:216)
at
com.sun.enterprise.connectors.inflow.ConnectorMessageBeanClient.setup(ConnectorMessageBeanClient.java:252)
at
com.sun.ejb.containers.MessageBeanContainer.<init>(MessageBeanContainer.java:209)
at
com.sun.ejb.containers.ContainerFactoryImpl.createContainer(ContainerFactoryImpl.java:280)
at com.sun.enterprise.server.AbstractLoader.loadEjbs(AbstractLoader.java:537)
at com.sun.enterprise.server.ApplicationLoader.doLoad(ApplicationLoader.java:191)
at
com.sun.enterprise.server.TomcatApplicationLoader.doLoad(TomcatApplicationLoader.java:126)
at
com.sun.enterprise.server.ExtendedApplicationLoader.doLoad(ExtendedApplicationLoader.java:134)
at com.sun.enterprise.server.AbstractLoader.load(AbstractLoader.java:245)
at
com.sun.enterprise.server.ApplicationManager.applicationDeployed(ApplicationManager.java:336)
at
com.sun.enterprise.server.ApplicationManager.applicationDeployed(ApplicationManager.java:210)
at
com.sun.enterprise.server.ApplicationManager.applicationDeployed(ApplicationManager.java:645)
at
com.sun.enterprise.admin.event.AdminEventMulticaster.invokeApplicationDeployEventListener(AdminEventMulticaster.java:958)
at
com.sun.enterprise.admin.event.AdminEventMulticaster.handleApplicationDeployEvent(AdminEventMulticaster.java:942)
at
com.sun.enterprise.admin.event.AdminEventMulticaster.processEvent(AdminEventMulticaster.java:467)
at
com.sun.enterprise.admin.event.AdminEventMulticaster.multicastEvent(AdminEventMulticaster.java:182)
at
com.sun.enterprise.admin.server.core.DeploymentNotificationHelper.multicastEvent(DeploymentNotificationHelper.java:308)
at
com.sun.enterprise.deployment.phasing.DeploymentServiceUtils.multicastEvent(DeploymentServiceUtils.java:230)
at
com.sun.enterprise.deployment.phasing.ServerDeploymentTarget.sendStartEvent(ServerDeploymentTarget.java:298)
at
com.sun.enterprise.deployment.phasing.ApplicationStartPhase.runPhase(ApplicationStartPhase.java:132)
at
com.sun.enterprise.deployment.phasing.DeploymentPhase.executePhase(DeploymentPhase.java:108)
at
com.sun.enterprise.deployment.phasing.PEDeploymentService.executePhases(PEDeploymentService.java:934)
at
com.sun.enterprise.deployment.phasing.PEDeploymentService.start(PEDeploymentService.java:605)
at
com.sun.enterprise.deployment.phasing.PEDeploymentService.start(PEDeploymentService.java:649)
at
com.sun.enterprise.admin.mbeans.ApplicationsConfigMBean.start(ApplicationsConfigMBean.java:773)
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:585)
at com.sun.enterprise.admin.MBeanHelper.invokeOperationInBean(MBeanHelper.java:381)
at com.sun.enterprise.admin.MBeanHelper.invokeOperationInBean(MBeanHelper.java:364)
at com.sun.enterprise.admin.config.BaseConfigMBean.invoke(BaseConfigMBean.java:477)
at com.sun.jmx.mbeanserver.DynamicMetaDataImpl.invoke(DynamicMetaDataImpl.java:213)
at com.sun.jmx.mbeanserver.MetaDataImpl.invoke(MetaDataImpl.java:220)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:815)
at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:784)
at sun.reflect.GeneratedMethodAccessor18.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at com.sun.enterprise.admin.util.proxy.ProxyClass.invoke(ProxyClass.java:90)
at $Proxy1.invoke(Unknown Source)
at
com.sun.enterprise.admin.server.core.jmx.SunoneInterceptor.invoke(SunoneInterceptor.java:304)
at
com.sun.enterprise.interceptor.DynamicInterceptor.invoke(DynamicInterceptor.java:174)
at
com.sun.enterprise.admin.jmx.remote.server.callers.InvokeCaller.call(InvokeCaller.java:69)
at
com.sun.enterprise.admin.jmx.remote.server.MBeanServerRequestHandler.handle(MBeanServerRequestHandler.java:155)
at
com.sun.enterprise.admin.jmx.remote.server.servlet.RemoteJmxConnectorServlet.processRequest(RemoteJmxConnectorServlet.java:122)
at
com.sun.enterprise.admin.jmx.remote.server.servlet.RemoteJmxConnectorServlet.doPost(RemoteJmxConnectorServlet.java:193)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:754)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
at sun.reflect.GeneratedMethodAccessor68.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:292)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAsPrivileged(Subject.java:517)
at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:325)
at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:208)
at
org.apache.catalina.core.ApplicationFilterChain.servletService(ApplicationFilterChain.java:420)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:315)
at
org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:287)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:218)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:648)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:593)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:94)
at
com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:98)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:222)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:648)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:593)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:587)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1096)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:166)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:648)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:593)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:587)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1096)
at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:288)
at
com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.invokeAdapter(DefaultProcessorTask.java:647)
at
com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.doProcess(DefaultProcessorTask.java:579)
at
com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.process(DefaultProcessorTask.java:831)
at
com.sun.enterprise.web.connector.grizzly.DefaultReadTask.executeProcessorTask(DefaultReadTask.java:341)
at
com.sun.enterprise.web.connector.grizzly.ssl.SSLReadTask.process(SSLReadTask.java:440)
at
com.sun.enterprise.web.connector.grizzly.ssl.SSLReadTask.doTask(SSLReadTask.java:228)
at com.sun.enterprise.web.connector.grizzly.TaskBase.run(TaskBase.java:265)
at
com.sun.enterprise.web.connector.grizzly.ssl.SSLWorkerThread.run(SSLWorkerThread.java:106)
Caused by: com.ibm.mq.jms.NoBrokerResponseException: MQJMS5053: *** No broker
response. Please ensure that the broker is running. If you are using the
WebSphere MQ broker check that your brokerVersion is set to V1 ***
at
com.ibm.mq.jms.MQBrokerSubscriptionEngine.getBrokerResponse(MQBrokerSubscriptio|#]

[#|2008-11-03T14:52:18.114-0800|WARNING|sun-appserver9.1|javax.enterprise.system.stream.err|_ThreadID=14;_ThreadName=httpSSLWorkerThread-4848-0;_RequestID=c72cb32f-3716-4de3-bc63-775b5e305ecb;|nEngine.java:3041)
at
com.ibm.mq.jms.MQBrokerSubscriptionEngine.openDurableSubscription(MQBrokerSubscriptionEngine.java:1058)
at
com.ibm.mq.jms.MQMigrateSubscriptionEngine.openDurableSubscription(MQMigrateSubscriptionEngine.java:547)
at com.ibm.mq.jms.MQConnectionBrowser.pubSubSetup(MQConnectionBrowser.java:440)
at
com.ibm.mq.jms.MQConnectionBrowser.MQConnectionBrowserInit(MQConnectionBrowser.java:306)
at com.ibm.mq.jms.MQConnectionBrowser.<init>(MQConnectionBrowser.java:155)
at
com.ibm.mq.jms.MQConnection.createDurableConnectionBrowser(MQConnection.java:3470)
at com.ibm.mq.jms.MQConnectionConsumer.<init>(MQConnectionConsumer.java:461)
at
com.ibm.mq.jms.MQConnection.createDurableConnectionConsumer(MQConnection.java:3364)
at
com.sun.genericra.inbound.async.InboundJmsResourcePool.createDurableConnectionConsumer(InboundJmsResourcePool.java:139)
at
com.sun.genericra.inbound.async.EndpointConsumer._start(EndpointConsumer.java:112)
... 85 more

#]
---------------------- Attached server.log --------------


 Comments   
Comment by sonialiu [ 03/Nov/08 ]

Created an attachment (id=2049)
server.log

Comment by Satish Kumar [ 04/Nov/08 ]

Based on the attached log records the problem does not seem to be due to
GenericRA but rather a setup/configuration issue. Firstly, pls ensure that the
broker is running. Secondly, set forBrokerVersion=V1 in the
TopicConnectionFactory.

If this does not solve the problem, pls attach the IBM MQ logs.

Comment by sonialiu [ 04/Nov/08 ]

As per Satish's suggestion I have add forBrokerVersion=V1 while creating
connection pool. Here is the command:
create-connection-pool:
[exec] create-connector-connection-pool --interactive=true --passwordfile /
export2/sonia/appserver-sqe/build-config/adminpassword.txt --user admin --terse=
false --connectiondefinition javax.jms.TopicConnectionFactory --property Connect
ionFactoryJndiName=XATCF1:SupportsXA=false:forBrokerVersion=V1 --host localhost
--transactionsupport NoTransaction --raname genericra --echo=true --port 4848 tc
pool
When I ran the test, the deployment still failed.
Then I double checked that QM was running.
#dspmq
QMName(QM1) STATUS(Running)
...

I checked the MQ broker port 9000 and it was listening.

  1. netstat -a|grep 9000
    .9000 *. 0 0 49152 0 LISTEN
    treeps.34576 treeps.9000 49152 0 49152 0 ESTABLISHED
    treeps.9000 treeps.34576 49152 0 49152 0 ESTABLISHED
    treeps.34577 treeps.9000 49152 0 49152 0 ESTABLISHED
    treeps.9000 treeps.34577 49152 0 49152 0 ESTABLISHED
    .9000 *. 0 0
    49152 0 LISTEN
    then I ran another GRA test using the same setup, the test passed. And Only the
    durable subscriber Topic test cases failed (test18 and test15).
Comment by harpreet [ 06/Nov/08 ]

Is this a critical issue for v2.1

Comment by Satish Kumar [ 25/Nov/08 ]

This clearly appears to be a Websphere MQ configuration issue. I tried this
with various combinations to figure out whether this is a configuration issue
or a bug including trying the test with GRA 1.7 (with GF 2.1) and AS 9.1. I am
seeing the same exception in all cases and the message in the exception seems
to clearly point to a configuration problem. The tests pass with SUN MQ. I have
raised this question in the Websphere MQ forum but I haven't got a reply yet. I
will update the bug once I get a reply.

Lowering the priority of this bug to a P4 since in all probability it appears
to be a configuration issue.

Comment by kumara [ 01/Sep/09 ]

Changing version from 9.1.1 to v2.1 to reflect new name/version.

Comment by Tom Mueller [ 06/Mar/12 ]

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

Comment by jigang [ 28/Feb/13 ]

May be Websphere MQ fixed this issue.
Durable subscriber Topic test passed to deploy against IBM MQ7.5
OS:win7
glassfish build: promoted build 71
GenericRA:v1.7-final and v2.1b
Websphere MQ:WMQ 7.5
Test description:
Steps for using the Generic Resource Adapter for JMS to integrate IBM - See more at: http://genericjmsra.java.net/docs/websphere-mq-integration-guide/webspheremq_integration_guide.html#sthash.rJVZuBbX.dpuf

To make a MDB into a durable subscriber, you can add a couple of lines to the sun-ejb-jar.xml:
<activation-config-property>
<activation-config-property-name>ClientId</activation-config-property-name>
<!-- this ia the JNDI name of the inbound destination in Weblogic's JNDI -->
<activation-config-property-value>testTopic</activation-config-property-value>
</activation-config-property>
<activation-config-property>
<activation-config-property-name>SubscriptionDurability</activation-config-property-name>
<!-- this ia the JNDI name of the inbound destination in Weblogic's JNDI -->
<activation-config-property-value>Durable</activation-config-property-value>
</activation-config-property>
<activation-config-property>
<activation-config-property-name>SubscriptionName</activation-config-property-name>
<!-- this ia the JNDI name of the inbound destination in Weblogic's JNDI -->
<activation-config-property-value>testtopic</activation-config-property-value>
</activation-config-property>

We can deploy this MDB against IBM MQ7.5 successfully and receive its messages even after the mdb is disabled and then reenabled.
Steps as follows:
1.deploy the durable subscriber MDB
2.send the message to the topic
3.MDB can receive its messages
4.disabled MDB
5.send the message to the topic
6.reenbaled MDB
7.MDB can receive its messages





[GLASSFISH-6492] Messages drop from queue when broker fails/restarts Created: 09/Oct/08  Updated: 24/Jan/13  Resolved: 24/Jan/13

Status: Resolved
Project: glassfish
Component/s: jms
Affects Version/s: v2.1
Fix Version/s: 4.0_b71

Type: Bug Priority: Minor
Reporter: rgafney Assignee: David Zhao
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Linux
Platform: DEC


Attachments: Text File log.txt    
Issuezilla Id: 6,492

 Description   

I am running load/stress tests on an application that routes messages to a
persistent queue. At my test start the message count of the queue was 23334. The
load was set up to send 500 messages to the initial destination topic at a rate
that varied between 44-50 messages per second when run once. The load was set up
to repeat 100 times (50000 message total). After 22000 messages had been sent
the process rate had dropped to 5 messages per secondat which point the broker
failed and restarted. After teh broker restart occurred the message count of the
target persist Queue was 11670. It appears the none of the 22000 sent messages
had made it to the persistent queue and an additional 11664 of the original
messages had been lost from the queue.



 Comments   
Comment by rgafney [ 09/Oct/08 ]

Created an attachment (id=1944)
log file from glassfish/nodeagents/gallifreyAgent/gallifreyInstance/imq/instances/collectorclustergallifreyInstance/log showing broker failure

Comment by rgafney [ 12/Nov/08 ]

Priority raised since no response has been received and the problem is becoming
a major product issue.

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 Tom Mueller [ 06/Mar/12 ]

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

Comment by jigang [ 24/Jan/13 ]

The filer is out of touch.I Configured a GlassFish Cluster to Use a Remote Broker Cluster and deployed an remote EJB job to send the message to queue.
In the process of sending 23334 messages to the Queue ,I killed and started the broker,there are no messages dropped from the Queue.
Please refer the links below to configure a GlassFish Cluster to Use a Remote Broker Cluster http://docs.oracle.com/cd/E18930_01/html/821-2426/abdbx.html#abdby
Here are my steps:
1.Start Domain
asadmin start-domain
2.Create Glassfish Server cluster,but not yet created instances for the cluster
asadmin create-cluster c1
3.Set the jms service type of the c1
asadmin set c1.jms-service.type=REMOTE
4.Delete the default_JMS_host JMS host
asadmin delete-jms-host --target c1 default_JMS_host
5.Create a JMS host for each broker in the broker cluster
asadmin create-jms-host --target c1 --mqhost localhost --mqport 7601 --mquser admin --mqpassword admin localhost1
asadmin create-jms-host --target c1 --mqhost localhost --mqport 7602 --mquser admin --mqpassword admin localhost2
6.Create two instances
asadmin create-local-instance --cluster c1 instance1
asadmin create-local-instance --cluster c1 instance2
7.Create connectionfactory and destination
asadmin create-jms-resource --target c1 --restype javax.jms.ConnectionFactory --property ReconnectEnabled=true MyConnectionFactory
asadmin create-jms-resource --target c1 --restype javax.jms.Queue MyQueue
8.restart the cluster
asadmin stop-cluster c1
asadmin start-cluster c1
9.Start the brokers in the cluster by using the Message Queue
imqbrokerd.exe -vmargs "-Xms256m -Xmx1024m" -name b1 -port 7601
imqbrokerd.exe -vmargs "-Xms256m -Xmx1024m" -name b2 -port 7602
10.Deploy a remote EJB
asadmin deploy --createtables=true --target c1 MYEJB.jar
11.Use standalone client invoke the remote EJB
MySessionBeanRemote beanRemote = (MySessionBeanRemote) ctx.lookup(MySessionBeanRemote.RemoteJNDIName);
beanRemote.sendMessage();





Generated at Thu Jul 02 21:40:29 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.