[GLASSFISH-14405] Use consistent mbean object name Created: 03/Nov/10  Updated: 23/Apr/15

Status: In Progress
Project: glassfish
Component/s: amx
Affects Version/s: 4.0
Fix Version/s: future release

Type: Bug Priority: Critical
Reporter: Nazrul Assignee: Peter Bower
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issue Links:
Dependency
blocks GLASSFISH-14357 [BLOCKING] cannot access web applicat... Resolved
Issuezilla Id: 14,405
Tags: 3_1-exclude, javaee_ri_target

 Description   

[Tracking Issue]

Refer to issue 14357 for context.

We seem to be using both "amx:" and "com.sun.appserv:". We should be using one
name consistently for all GlassFish object names.

Given that we are de-emphasiging AMX, should we use "com.sun.appserv:" (for JSR
77, monitoring mbeans, etc.)?

Since email thread did not work, I am creating this issue to finalize a decision
on this.



 Comments   
Comment by Nazrul [ 09/Nov/10 ]

If we are able to change, using something like "glassfish:" is probably a good
choice.

Comment by Amy Roh [ 16/Nov/10 ]

Fixed in web container.

Sending
core/kernel/src/main/java/com/sun/enterprise/v3/server/ServerContextImpl.java
Transmitting file data .
Committed revision 42857.

Comment by Nazrul [ 01/Dec/10 ]

See also issue GLASSFISH-14923

Comment by Nazrul [ 06/Dec/10 ]

The tomcat created mbeans were conflicting during load time of AMX mbeans. Since this is late in 3.1, we decided to leave the tomcat created mbeans under "glassfish-web:". We will also try to comment out (not create) mbeans that are not needed by web container initialization. During 3.2, we will try to not rely on mbeans for configuration update notification in web container.

Prasad will try to rename "amx:" to "glassfish:" if there are no issues.

Comment by Amy Roh [ 06/Dec/10 ]

Changed web domain to "glassfish-web" in svn 43495 and removed unused Tomcat MBeans registration in svn 43514

Comment by prasads [ 06/Dec/10 ]

This would be fixed in 3.2

Comment by prasads [ 09/Dec/10 ]

There are a couple of issues that we need to look at :
1. There is a conflict due to two Mbeans being created for a WebModule/Servlet/Wrapper. This is confusing.
2. Since there are two MBeans being created both of them are being registered as NotificationHandlers for mbean notifications.
3. These Mbeans are loaded at different times . The ones created by Tomcat are loaded at startup and the ones created by AMX are loaded on demand.

The outcome of #1 is that its confusing to see two MBeans of same type being created for a single WebModule, Servlet under the same domain. While one represents the JSR77 Mbean created by GlassFish, the other one represents the MBean created by Tomcat for its internal lifecycle management. The user would need to use the former, but there is no way for him/her to know which one to use.

The outcome of #2 is that the wrong mBean handles the notification coming from the mBean Server . This results in an ugly message.
[#|2010-11-23T13:42:34.233+0530|WARNING|glassfish3.1|org.apache.catalina.connector.MapperListener|_ThreadID=15;_ThreadName=Thread-1;|Error registering Wrapper glassfish:pp=/J2EEDomain/J2EEServer/WebModule[jsfastrologer],type=Servlet,name=default,j2eeType=Servlet,J2EEServer=server,WebModule=jsfastrologer,J2EEApplication=null
javax.management.MBeanException
at org.glassfish.admin.amx.impl.mbean.AMXImplBase.handleException(AMXImplBase.java:830)
at org.glassfish.admin.amx.impl.mbean.AMXImplBase.handleInvokeThrowable(AMXImplBase.java:846)
at org.glassfish.admin.amx.impl.mbean.AMXImplBase.invoke(AMXImplBase.java:878)
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:857)
at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:795)
at com.sun.enterprise.v3.admin.DynamicInterceptor.invoke(DynamicInterceptor.java:353)
at org.apache.catalina.connector.MapperListener.registerWrapper(MapperListener.java:667)
at org.apache.catalina.connector.MapperListener.handleNotification(MapperListener.java:369)
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor$ListenerWrapper.handleNotification(DefaultMBeanServerInterceptor.java:1776)
at javax.management.NotificationBroadcasterSupport.handleNotification(NotificationBroadcasterSupport.java:274)
at javax.management.NotificationBroadcasterSupport$SendNotifJob.run(NotificationBroadcasterSupport.java:339)
at javax.management.NotificationBroadcasterSupport$1.execute(NotificationBroadcasterSupport.java:324)
at javax.management.NotificationBroadcasterSupport.sendNotification(NotificationBroadcasterSupport.java:247)
at javax.management.MBeanServerDelegate.sendNotification(MBeanServerDelegate.java:205)
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.sendNotification(DefaultMBeanServerInterceptor.java:1563)
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.internal_addObject(DefaultMBeanServerInterceptor.java:1538)
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:986)
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:938)
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:330)
at com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:516)
at com.sun.enterprise.v3.admin.DynamicInterceptor.registerMBean(DynamicInterceptor.java:438)
at org.glassfish.admin.amx.impl.j2ee.RegistrationSupport.registerJ2EEChild(RegistrationSupport.java:555)
at org.glassfish.admin.amx.impl.j2ee.RegistrationSupport.registerWebModuleAndItsComponents(RegistrationSupport.java:408)
at org.glassfish.admin.amx.impl.j2ee.RegistrationSupport.createAppMBeans(RegistrationSupport.java:267)
at org.glassfish.admin.amx.impl.j2ee.RegistrationSupport.processApplicationRef(RegistrationSupport.java:527)
at org.glassfish.admin.amx.impl.j2ee.RegistrationSupport.registerApplications(RegistrationSupport.java:479)
at org.glassfish.admin.amx.impl.j2ee.RegistrationSupport.<init>(RegistrationSupport.java:163)
at org.glassfish.admin.amx.impl.j2ee.J2EEServerImpl.registerChildren(J2EEServerImpl.java:121)
at org.glassfish.admin.amx.impl.j2ee.DASJ2EEServerImpl.registerChildren(DASJ2EEServerImpl.java:73)
at org.glassfish.admin.amx.impl.mbean.AMXImplBase.postRegisterHook(AMXImplBase.java:972)
at org.glassfish.admin.amx.impl.mbean.MBeanImplBase.postRegister(MBeanImplBase.java:352)
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.postRegisterInvoke(DefaultMBeanServerInterceptor.java:1058)
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:997)
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:938)
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:330)
at com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:516)
at com.sun.enterprise.v3.admin.DynamicInterceptor.registerMBean(DynamicInterceptor.java:438)
at org.glassfish.admin.amx.impl.mbean.AMXImplBase.registerChild(AMXImplBase.java:1025)
at org.glassfish.admin.amx.impl.j2ee.J2EEDomainImpl.registerChildren(J2EEDomainImpl.java:104)
at org.glassfish.admin.amx.impl.mbean.AMXImplBase.postRegisterHook(AMXImplBase.java:972)
at org.glassfish.admin.amx.impl.mbean.MBeanImplBase.postRegister(MBeanImplBase.java:352)
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.postRegisterInvoke(DefaultMBeanServerInterceptor.java:1058)
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:997)
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:938)
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:330)
at com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:516)
at com.sun.enterprise.v3.admin.DynamicInterceptor.registerMBean(DynamicInterceptor.java:438)
at org.glassfish.admin.amx.impl.j2ee.loader.AMXJ2EEStartupService.loadAMXMBeans(AMXJ2EEStartupService.java:253)
at org.glassfish.admin.amx.impl.AMXStartupService$AMXLoaderThread.run(AMXStartupService.java:305)
Caused by: java.lang.NoSuchMethodException: no operation findMappingObjectnull in glassfish:pp=/J2EEDomain/J2EEServer/WebModule[jsfastrologer],type=Servlet,name=default,j2eeType=Servlet,J2EEServer=server,WebModule=jsfastrologer,J2EEApplication=null
at org.glassfish.admin.amx.impl.mbean.AMXImplBase.invokeManually(AMXImplBase.java:897)
at org.glassfish.admin.amx.impl.mbean.AMXImplBase.invoke(AMXImplBase.java:874)

The #3 ,makes it hard for us to plugin the Tomcat created MBeans into the AMX subsystem instead of creating a new Mbean .

All these 3 issues have to be considered and an optimal solution found. The time required for this effort makes it impossible to fix in v3.1

Comment by prasads [ 20/Feb/11 ]

Assigning issues to Naman

Comment by Peter Bower [ 13/Mar/13 ]

Object names are part of the public API. Therefore, we can't remove them at this time.





[GLASSFISH-17107] LDAP authentication gets replaced by File authentication as a side-effect of bootAMX Created: 26/Jul/11  Updated: 06/Jan/12

Status: Open
Project: glassfish
Component/s: amx
Affects Version/s: 9.0pe, 3.1.1_b10
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: paal Assignee: prasads
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7


Tags: 3_1_1-next, 3_1_1-scrubbed, 3_1_2-exclude

 Description   

We have an enterprise application consisting of several parts where access is restricted to users holding specific roles. The server-config's default realm is an LDAPRealm. One of our EJBs uses AMX to retrieve details about available connection pools. To make sure AMX is available, the EJB invokes bootAMX the first time this information is requested:

final MBeanServer mBeanServer = java.lang.management.ManagementFactory.getPlatformMBeanServer();
...
final ObjectName jdbcPoolObjName = new ObjectName("amx:type=jdbc-connection-pool,*");
Set<ObjectName> connectionPoolNames = mBeanServer.queryNames(jdbcPoolObjName, null);
if (connectionPoolNames.isEmpty()) {
mBeanServer.invoke(new ObjectName("amx-support:type=boot-amx"), "bootAMX", new Object[0], new String[0]);
...

This works fine for the first request, but any following requests are rejected with authentication failure. From the server.log I can see that File authentication is attempted for these requests:

...
Caused by: javax.security.auth.login.LoginException: Failed file login for user1.
at com.sun.enterprise.security.auth.login.FileLoginModule.authenticate(FileLoginModule.java:84)
...

This is also the case for attempts to access other part of our application. The same problem occurs if AMX is booted by other means, e.g. by making a connection to the Admin Service with JConsole. It looks like the AMX boot process has a side-effect that makes GlassFish ignore its default realm.

However, if I log in to the GlassFish Admin Console after booting AMX, the situation goes back to normal. The server.log output from this is (I use the default settings for logging):

[#|2011-07-26T08:42:39.492+0200|INFO|glassfish3.1.1|com.sun.jersey.server.impl.application.WebApplicationImpl|_ThreadID=26;_ThreadName=Thread-2;|Initiating Jersey application, version 'Jersey: 1.8 06/24/2011 12:17 PM'|#]

Somehow, this has a side-effect that brings the default realm back into play.

(The problem was discovered when migrating the application from GlassFish version 2. It has been reproduced with both b10 and b13 of the 3.1.1 version.)



 Comments   
Comment by kumarjayanti [ 26/Jul/11 ]

I do believe this is an issue and i had filed a similar issue on AMX earlier though it is not resolved yet. I think that bug became irrelevant because Admin GUI no longer uses AMX.

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

Assigning to AMX team.

Comment by paal [ 26/Jul/11 ]

I have tried to switch to LDAPRealm for authentication of GlassFish admin user, by redefining the server-config's 'admin-realm' as an LDAPRealm, adding a group named 'asadmin' in OpenDS, and adding a user 'admin2' as member of the 'asadmin' group. This works fine for login as 'admin2' in the GlassFish Admin Console, but booting AMX still switches things to File authentication.

However, if I also define the default-config's 'admin-realm' as an LDAPRealm, and remove all FileRealms and CertificateRealms from both server-config and default-config, the problem finally disappears. I have confirmed that the presence of another type of realm (DataSourceRealm, our own custom realm) does not cause similar problems.

Comment by prasads [ 06/Jan/12 ]

Excluding from 3.1.2





[GLASSFISH-20987] Setting imq.hostname in broker breaks JMX access Created: 17/Feb/14  Updated: 23/Apr/15

Status: Open
Project: glassfish
Component/s: amx, jms
Affects Version/s: 4.0
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: electricsam Assignee: prasads
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Linux, jdk 1.7.0_45


Tags: javaee_ri_target

 Description   

I am trying to use an enhanced LOCAL broker cluster in my setup and would like to set up some monitoring. However, I was unable to connect to the MBeans though jconsole.

I used the following command to get the uri for the JMX connection:

imqcmd -b <hostname>:27676 list jmx

which produced:

service:jmx:rmi://<hostname>/jndi/rmi://<hostname>:1099/<hostname>/7676/jmxrmi

When I tried to use that in jconsole, I received a connection error.

To try to narrow the problem down, I set up a remote broker and configured it with an HA configuration and started removing properties. As soon as I removed the imq.hostname property, I was able to connect.






[GLASSFISH-12842] Admin-GUI startup resets runtime Default Realm to FileRealm incorrectly Created: 30/Jul/10  Updated: 06/Nov/13

Status: Open
Project: glassfish
Component/s: amx
Affects Version/s: 3.1
Fix Version/s: not determined

Type: Bug Priority: Major
Reporter: kumarjayanti Assignee: Peter Bower
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Macintosh


Attachments: JPEG File grab-1.jpg     JPEG File grab-2.jpg     JPEG File grab-2.jpg    
Issuezilla Id: 12,842
Tags: 3_1-exclude

 Description   

I have a server config where i have set the default-realm attribute on security-service to "ldaprealm".
Everytime i start Admin-GUI then the default realm gets reset to "filerealm" which happens to be the
default when nothing was explicitly given.

If i try to see the value of default-realm in GUI after loading however it does show the correct
value"ldaprealm". But the internal RuntimeValue in Security Realm.java has been changed to "filerealm"

I debugged this and found that the issue is in AMX code. Attached are call stacks when admin gui is
loading to show the issue.

Steps to reproduce :

1. Open Admin GUI and under Configuration->Security set the default realm to something otherthan
filerealm.

2. You can for example create another realm in GUI first (which can be another filerealm with different
name) and set that as the default.

3. Now restart the server and access admin gui in the browser.

After the browser has loaded Admin-GUI, the default realm in the security runtime would be changed
back to original filerealm and not the one created in step 2.

I also notice that the call to Realm.setDefaultRealm() happens many many times during loading of
Admin GUI which seems somehow unnecessary.

Marking as P2 since without this being fixed we are blocked on the Oracle Access Manager integration
where we require the default glassfish realm to be an ldaprealm. And things only work as long as the
Admin GUI is not loaded.



 Comments   
Comment by kumarjayanti [ 30/Jul/10 ]

Created an attachment (id=4613)
call stack 1

Comment by kumarjayanti [ 30/Jul/10 ]

Created an attachment (id=4614)
call stack 2

Comment by kumarjayanti [ 30/Jul/10 ]

Created an attachment (id=4615)
call stack 2

Comment by prasads [ 07/Oct/10 ]

...

Comment by prasads [ 07/Oct/10 ]

Kumar
, does this issue happen now since Admin GUI does not use AMX.

Comment by prasads [ 07/Oct/10 ]

Downgrading to a P3 now.

Comment by sanandal [ 08/Oct/10 ]

...

Comment by prasads [ 15/Dec/10 ]

Excluding this for v3.1 since GUI does not use AMX

Comment by prasads [ 20/Feb/11 ]

Assigning issues to Naman

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 Peter Butkovic [ 06/Nov/13 ]

The same problem is reproducible when connecting with JConsole (via Remote Process only).

Tested with:

  • Glassfish 3.1.2.2.
  • Windows and Linux




[GLASSFISH-12862] cannot determine anonymous login after session timout Created: 01/Aug/10  Updated: 11/Feb/13

Status: Open
Project: glassfish
Component/s: amx
Affects Version/s: 3.1
Fix Version/s: not determined

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

Operating System: All
Platform: All


Issuezilla Id: 12,862
Tags: 3_1-exclude

 Description   

Very often, when the session timeout, I cannot just get back to the GUI
automatically. The login screen is displayed and require me to enter the login
info. I have to enter "admin" as username and leave the password field empty.
Not sure is its GUI's, security or AMX issue.

Here is the info from server.log

[#|2010-08-01T14:30:30.300-0700|INFO|glassfish3.1|org.glassfish.admingui|_ThreadID=62;_ThreadName=http-thread-pool-4848(5);|admin
console: initSessionAttributes()|#]

[#|2010-08-01T14:30:31.621-0700|WARNING|glassfish3.1|javax.enterprise.system.tools.admin.org.glassfish.server|_ThreadID=62;_ThreadName=http-thread-pool-4848(5);|getRealmNames():
Can't get realm names
java.lang.NullPointerException
at org.glassfish.admin.amx.impl.ext.RealmsImpl.getAuthRealms(RealmsImpl.java:107)
at
org.glassfish.admin.amx.impl.ext.RealmsImpl.getConfiguredRealmNames(RealmsImpl.java:113)
at org.glassfish.admin.amx.impl.ext.RealmsImpl.loadRealms(RealmsImpl.java:122)
at org.glassfish.admin.amx.impl.ext.RealmsImpl.getRealmNames(RealmsImpl.java:194)
at sun.reflect.GeneratedMethodAccessor368.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.glassfish.admin.amx.impl.mbean.AMXImplBase.getAttributeByMethod(AMXImplBase.java:548)
at
org.glassfish.admin.amx.impl.mbean.AMXImplBase.getAttributeInternal(AMXImplBase.java:465)
at
org.glassfish.admin.amx.impl.mbean.AMXImplBase.getAttribute(AMXImplBase.java:420)
at
org.glassfish.admin.amx.impl.mbean.AMXImplBase.getAttributes(AMXImplBase.java:504)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttributes(DefaultMBeanServerInterceptor.java:726)
at com.sun.jmx.mbeanserver.JmxMBeanServer.getAttributes(JmxMBeanServer.java:665)
at
org.glassfish.admin.amx.util.jmx.MBeanProxyHandler.getAttributes(MBeanProxyHandler.java:274)
at
org.glassfish.admin.amx.core.proxy.AMXProxyHandler.attributesMap(AMXProxyHandler.java:1194)
at
org.glassfish.admin.amx.core.proxy.AMXProxyHandler.attributesMap(AMXProxyHandler.java:1204)
at
org.glassfish.admin.amx.core.proxy.AMXProxyHandler.handleSpecialMethod(AMXProxyHandler.java:415)
at
org.glassfish.admin.amx.core.proxy.AMXProxyHandler._invoke(AMXProxyHandler.java:793)
at
org.glassfish.admin.amx.core.proxy.AMXProxyHandler.invoke(AMXProxyHandler.java:527)
at $Proxy111.attributesMap(Unknown Source)
at
org.glassfish.admingui.common.handlers.ProxyHandlers.getProxyAttribute(ProxyHandlers.java:316)
at sun.reflect.GeneratedMethodAccessor387.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
com.sun.jsftemplating.layout.descriptors.handler.Handler.invoke(Handler.java:442)
at
com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:420)
at
com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:394)
at
com.sun.jsftemplating.layout.descriptors.LayoutDefinition.dispatchInitPageHandlers(LayoutDefinition.java:332)
at
com.sun.jsftemplating.layout.template.TemplateLayoutDefinitionManager.getLayoutDefinition(TemplateLayoutDefinitionManager.java:201)
at
com.sun.jsftemplating.layout.LayoutDefinitionManager.getLayoutDefinition(LayoutDefinitionManager.java:152)
at
com.sun.jsftemplating.layout.LayoutViewHandler.buildUIComponentTree(LayoutViewHandler.java:507)
at
com.sun.jsftemplating.layout.LayoutViewHandler.buildUIComponentTree(LayoutViewHandler.java:507)
at
com.sun.jsftemplating.layout.LayoutViewHandler.buildUIComponentTree(LayoutViewHandler.java:507)
at
com.sun.jsftemplating.layout.LayoutViewHandler.createView(LayoutViewHandler.java:255)
at com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:238)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:97)
at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:107)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:114)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:334)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1518)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:339)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:211)
at com.sun.webui.jsf.util.UploadFilter.doFilter(UploadFilter.java:240)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:211)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:171)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:651)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:591)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:94)
at
com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:87)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:158)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:651)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:591)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:318)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:222)
at
com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:240)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:823)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:720)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1013)
at
com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:220)
at
com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:135)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:102)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:88)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:76)
at
com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:53)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:57)
at com.sun.grizzly.ContextTask.run(ContextTask.java:69)
at
com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:530)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:511)
at java.lang.Thread.run(Thread.java:637)

#]

[#|2010-08-01T14:30:34.181-0700|INFO|glassfish3.1|org.glassfish.admingui|_ThreadID=62;_ThreadName=http-thread-pool-4848(5);|UpdateCheckFrequency
is set to NEVER by user. Component update count not performed. |#]

[#|2010-08-01T14:30:45.695-0700|SEVERE|glassfish3.1|null|_ThreadID=60;_ThreadName=http-thread-pool-4848(3);|java.lang.reflect.UndeclaredThrowableException|#]

[#|2010-08-01T14:30:46.111-0700|SEVERE|glassfish3.1|null|_ThreadID=60;_ThreadName=http-thread-pool-4848(3);|
at $Proxy133.getAnonymousUser(Unknown Source)|#]

[#|2010-08-01T14:30:46.111-0700|SEVERE|glassfish3.1|null|_ThreadID=60;_ThreadName=http-thread-pool-4848(3);|
at
org.glassfish.admingui.common.handlers.CommonHandlers.testLoginBypass(CommonHandlers.java:470)|#]

[#|2010-08-01T14:30:46.112-0700|SEVERE|glassfish3.1|null|_ThreadID=60;_ThreadName=http-thread-pool-4848(3);|
at sun.reflect.GeneratedMethodAccessor407.invoke(Unknown Source)|#]

[#|2010-08-01T14:30:46.112-0700|SEVERE|glassfish3.1|null|_ThreadID=60;_ThreadName=http-thread-pool-4848(3);|
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)|#]

[#|2010-08-01T14:30:46.112-0700|SEVERE|glassfish3.1|null|_ThreadID=60;_ThreadName=http-thread-pool-4848(3);|
at java.lang.reflect.Method.invoke(Method.java:597)|#]

[#|2010-08-01T14:30:46.112-0700|SEVERE|glassfish3.1|null|_ThreadID=60;_ThreadName=http-thread-pool-4848(3);|
at
com.sun.jsftemplating.layout.descriptors.handler.Handler.invoke(Handler.java:442)|#]

[#|2010-08-01T14:30:46.112-0700|SEVERE|glassfish3.1|null|_ThreadID=60;_ThreadName=http-thread-pool-4848(3);|
at
com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:420)|#]

[#|2010-08-01T14:30:46.112-0700|SEVERE|glassfish3.1|null|_ThreadID=60;_ThreadName=http-thread-pool-4848(3);|
at
com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:394)|#]

[#|2010-08-01T14:30:46.113-0700|SEVERE|glassfish3.1|null|_ThreadID=60;_ThreadName=http-thread-pool-4848(3);|
at
com.sun.jsftemplating.layout.descriptors.LayoutDefinition.dispatchInitPageHandlers(LayoutDefinition.java:332)|#]

[#|2010-08-01T14:30:46.113-0700|SEVERE|glassfish3.1|null|_ThreadID=60;_ThreadName=http-thread-pool-4848(3);|
at
com.sun.jsftemplating.layout.template.TemplateLayoutDefinitionManager.getLayoutDefinition(TemplateLayoutDefinitionManager.java:201)|#]

[#|2010-08-01T14:30:46.113-0700|SEVERE|glassfish3.1|null|_ThreadID=60;_ThreadName=http-thread-pool-4848(3);|
at
com.sun.jsftemplating.layout.LayoutDefinitionManager.getLayoutDefinition(LayoutDefinitionManager.java:152)|#]

[#|2010-08-01T14:30:46.113-0700|SEVERE|glassfish3.1|null|_ThreadID=60;_ThreadName=http-thread-pool-4848(3);|
at
com.sun.jsftemplating.layout.ViewRootUtil.getLayoutDefinition(ViewRootUtil.java:257)|#]

[#|2010-08-01T14:30:46.113-0700|SEVERE|glassfish3.1|null|_ThreadID=60;_ThreadName=http-thread-pool-4848(3);|
at
com.sun.jsftemplating.layout.ViewRootUtil.getLayoutDefinition(ViewRootUtil.java:228)|#]

[#|2010-08-01T14:30:46.113-0700|SEVERE|glassfish3.1|null|_ThreadID=60;_ThreadName=http-thread-pool-4848(3);|
at
com.sun.jsftemplating.layout.LayoutViewHandler.createView(LayoutViewHandler.java:201)|#]

[#|2010-08-01T14:30:46.113-0700|SEVERE|glassfish3.1|null|_ThreadID=60;_ThreadName=http-thread-pool-4848(3);|
at com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:238)|#]

[#|2010-08-01T14:30:46.113-0700|SEVERE|glassfish3.1|null|_ThreadID=60;_ThreadName=http-thread-pool-4848(3);|
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:97)|#]

[#|2010-08-01T14:30:46.113-0700|SEVERE|glassfish3.1|null|_ThreadID=60;_ThreadName=http-thread-pool-4848(3);|
at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:107)|#]

[#|2010-08-01T14:30:46.113-0700|SEVERE|glassfish3.1|null|_ThreadID=60;_ThreadName=http-thread-pool-4848(3);|
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:114)|#]

[#|2010-08-01T14:30:46.113-0700|SEVERE|glassfish3.1|null|_ThreadID=60;_ThreadName=http-thread-pool-4848(3);|
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:334)|#]

[#|2010-08-01T14:30:46.113-0700|SEVERE|glassfish3.1|null|_ThreadID=60;_ThreadName=http-thread-pool-4848(3);|
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1518)|#]

[#|2010-08-01T14:30:46.113-0700|SEVERE|glassfish3.1|null|_ThreadID=60;_ThreadName=http-thread-pool-4848(3);|
at
org.apache.catalina.core.ApplicationDispatcher.doInvoke(ApplicationDispatcher.java:831)|#]

[#|2010-08-01T14:30:46.114-0700|SEVERE|glassfish3.1|null|_ThreadID=60;_ThreadName=http-thread-pool-4848(3);|
at
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:693)|#]

[#|2010-08-01T14:30:46.114-0700|SEVERE|glassfish3.1|null|_ThreadID=60;_ThreadName=http-thread-pool-4848(3);|
at
org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:495)|#]

[#|2010-08-01T14:30:46.114-0700|SEVERE|glassfish3.1|null|_ThreadID=60;_ThreadName=http-thread-pool-4848(3);|
at
org.apache.catalina.core.ApplicationDispatcher.doDispatch(ApplicationDispatcher.java:466)|#]

[#|2010-08-01T14:30:46.114-0700|SEVERE|glassfish3.1|null|_ThreadID=60;_ThreadName=http-thread-pool-4848(3);|
at
org.apache.catalina.core.ApplicationDispatcher.dispatch(ApplicationDispatcher.java:356)|#]

[#|2010-08-01T14:30:46.114-0700|SEVERE|glassfish3.1|null|_ThreadID=60;_ThreadName=http-thread-pool-4848(3);|
at
org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:296)|#]

[#|2010-08-01T14:30:46.114-0700|SEVERE|glassfish3.1|null|_ThreadID=60;_ThreadName=http-thread-pool-4848(3);|
at
org.apache.catalina.authenticator.FormAuthenticator.forwardToLoginPage(FormAuthenticator.java:463)|#]

[#|2010-08-01T14:30:46.114-0700|SEVERE|glassfish3.1|null|_ThreadID=60;_ThreadName=http-thread-pool-4848(3);|
at
org.apache.catalina.authenticator.FormAuthenticator.authenticate(FormAuthenticator.java:251)|#]

[#|2010-08-01T14:30:46.115-0700|SEVERE|glassfish3.1|null|_ThreadID=60;_ThreadName=http-thread-pool-4848(3);|
at
com.sun.web.security.RealmAdapter.invokeAuthenticateDelegate(RealmAdapter.java:1183)|#]

[#|2010-08-01T14:30:46.115-0700|SEVERE|glassfish3.1|null|_ThreadID=60;_ThreadName=http-thread-pool-4848(3);|
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:580)|#]

[#|2010-08-01T14:30:46.115-0700|SEVERE|glassfish3.1|null|_ThreadID=60;_ThreadName=http-thread-pool-4848(3);|
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:619)|#]

[#|2010-08-01T14:30:46.115-0700|SEVERE|glassfish3.1|null|_ThreadID=60;_ThreadName=http-thread-pool-4848(3);|
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:591)|#]

[#|2010-08-01T14:30:46.115-0700|SEVERE|glassfish3.1|null|_ThreadID=60;_ThreadName=http-thread-pool-4848(3);|
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:94)|#]

[#|2010-08-01T14:30:46.115-0700|SEVERE|glassfish3.1|null|_ThreadID=60;_ThreadName=http-thread-pool-4848(3);|
at
com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:87)|#]

[#|2010-08-01T14:30:46.115-0700|SEVERE|glassfish3.1|null|_ThreadID=60;_ThreadName=http-thread-pool-4848(3);|
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:158)|#]

[#|2010-08-01T14:30:46.115-0700|SEVERE|glassfish3.1|null|_ThreadID=60;_ThreadName=http-thread-pool-4848(3);|
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:651)|#]

[#|2010-08-01T14:30:46.115-0700|SEVERE|glassfish3.1|null|_ThreadID=60;_ThreadName=http-thread-pool-4848(3);|
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:591)|#]

[#|2010-08-01T14:30:46.115-0700|SEVERE|glassfish3.1|null|_ThreadID=60;_ThreadName=http-thread-pool-4848(3);|
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:318)|#]

[#|2010-08-01T14:30:46.115-0700|SEVERE|glassfish3.1|null|_ThreadID=60;_ThreadName=http-thread-pool-4848(3);|
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:222)|#]

[#|2010-08-01T14:30:46.116-0700|SEVERE|glassfish3.1|null|_ThreadID=60;_ThreadName=http-thread-pool-4848(3);|
at
com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:240)|#]

[#|2010-08-01T14:30:46.116-0700|SEVERE|glassfish3.1|null|_ThreadID=60;_ThreadName=http-thread-pool-4848(3);|
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:823)|#]

[#|2010-08-01T14:30:46.116-0700|SEVERE|glassfish3.1|null|_ThreadID=60;_ThreadName=http-thread-pool-4848(3);|
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:720)|#]

[#|2010-08-01T14:30:46.116-0700|SEVERE|glassfish3.1|null|_ThreadID=60;_ThreadName=http-thread-pool-4848(3);|
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1013)|#]

[#|2010-08-01T14:30:46.116-0700|SEVERE|glassfish3.1|null|_ThreadID=60;_ThreadName=http-thread-pool-4848(3);|
at
com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:220)|#]

[#|2010-08-01T14:30:46.116-0700|SEVERE|glassfish3.1|null|_ThreadID=60;_ThreadName=http-thread-pool-4848(3);|
at
com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:135)|#]

[#|2010-08-01T14:30:46.116-0700|SEVERE|glassfish3.1|null|_ThreadID=60;_ThreadName=http-thread-pool-4848(3);|
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:102)|#]

[#|2010-08-01T14:30:46.116-0700|SEVERE|glassfish3.1|null|_ThreadID=60;_ThreadName=http-thread-pool-4848(3);|
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:88)|#]

[#|2010-08-01T14:30:46.116-0700|SEVERE|glassfish3.1|null|_ThreadID=60;_ThreadName=http-thread-pool-4848(3);|
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:76)|#]

[#|2010-08-01T14:30:46.116-0700|SEVERE|glassfish3.1|null|_ThreadID=60;_ThreadName=http-thread-pool-4848(3);|
at
com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:53)|#]

[#|2010-08-01T14:30:46.116-0700|SEVERE|glassfish3.1|null|_ThreadID=60;_ThreadName=http-thread-pool-4848(3);|
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:57)|#]

[#|2010-08-01T14:30:46.117-0700|SEVERE|glassfish3.1|null|_ThreadID=60;_ThreadName=http-thread-pool-4848(3);|
at com.sun.grizzly.ContextTask.run(ContextTask.java:69)|#]

[#|2010-08-01T14:30:46.117-0700|SEVERE|glassfish3.1|null|_ThreadID=60;_ThreadName=http-thread-pool-4848(3);|
at
com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:530)|#]

[#|2010-08-01T14:30:46.117-0700|SEVERE|glassfish3.1|null|_ThreadID=60;_ThreadName=http-thread-pool-4848(3);|
at
com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:511)|#]

[#|2010-08-01T14:30:46.117-0700|SEVERE|glassfish3.1|null|_ThreadID=60;_ThreadName=http-thread-pool-4848(3);|
at java.lang.Thread.run(Thread.java:637)|#]

[#|2010-08-01T14:30:46.117-0700|SEVERE|glassfish3.1|null|_ThreadID=60;_ThreadName=http-thread-pool-4848(3);|Caused
by: javax.management.AttributeNotFoundException: Attribute not found:
"AnonymousUser" of MBean amx:pp=/ext,type=realms[null]|#]

[#|2010-08-01T14:30:46.117-0700|SEVERE|glassfish3.1|null|_ThreadID=60;_ThreadName=http-thread-pool-4848(3);|
at
org.glassfish.admin.amx.impl.mbean.AMXImplBase.rethrowAttributeNotFound(AMXImplBase.java:532)|#]

[#|2010-08-01T14:30:46.117-0700|SEVERE|glassfish3.1|null|_ThreadID=60;_ThreadName=http-thread-pool-4848(3);|
at
org.glassfish.admin.amx.impl.mbean.AMXImplBase.getAttributeByMethod(AMXImplBase.java:553)|#]

[#|2010-08-01T14:30:46.118-0700|SEVERE|glassfish3.1|null|_ThreadID=60;_ThreadName=http-thread-pool-4848(3);|
at
org.glassfish.admin.amx.impl.mbean.AMXImplBase.getAttributeInternal(AMXImplBase.java:465)|#]

[#|2010-08-01T14:30:46.118-0700|SEVERE|glassfish3.1|null|_ThreadID=60;_ThreadName=http-thread-pool-4848(3);|
at
org.glassfish.admin.amx.impl.mbean.AMXImplBase.getAttribute(AMXImplBase.java:420)|#]

[#|2010-08-01T14:30:46.118-0700|SEVERE|glassfish3.1|null|_ThreadID=60;_ThreadName=http-thread-pool-4848(3);|
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(DefaultMBeanServerInterceptor.java:666)|#]

[#|2010-08-01T14:30:46.118-0700|SEVERE|glassfish3.1|null|_ThreadID=60;_ThreadName=http-thread-pool-4848(3);|
at com.sun.jmx.mbeanserver.JmxMBeanServer.getAttribute(JmxMBeanServer.java:638)|#]

[#|2010-08-01T14:30:46.118-0700|SEVERE|glassfish3.1|null|_ThreadID=60;_ThreadName=http-thread-pool-4848(3);|
at
org.glassfish.admin.amx.util.jmx.MBeanProxyHandler.getAttribute(MBeanProxyHandler.java:248)|#]

[#|2010-08-01T14:30:46.118-0700|SEVERE|glassfish3.1|null|_ThreadID=60;_ThreadName=http-thread-pool-4848(3);|
at
org.glassfish.admin.amx.util.jmx.MBeanProxyHandler.invoke(MBeanProxyHandler.java:386)|#]

[#|2010-08-01T14:30:46.118-0700|SEVERE|glassfish3.1|null|_ThreadID=60;_ThreadName=http-thread-pool-4848(3);|
at
org.glassfish.admin.amx.core.proxy.AMXProxyHandler._invoke(AMXProxyHandler.java:823)|#]

[#|2010-08-01T14:30:46.118-0700|SEVERE|glassfish3.1|null|_ThreadID=60;_ThreadName=http-thread-pool-4848(3);|
at
org.glassfish.admin.amx.core.proxy.AMXProxyHandler.invoke(AMXProxyHandler.java:527)|#]

[#|2010-08-01T14:30:46.118-0700|SEVERE|glassfish3.1|null|_ThreadID=60;_ThreadName=http-thread-pool-4848(3);|
... 54 more|#]

[#|2010-08-01T14:30:46.118-0700|SEVERE|glassfish3.1|org.glassfish.admingui|_ThreadID=60;_ThreadName=http-thread-pool-4848(3);|Cannot
determine anonymous login. Login enforced.|#]



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

Since the NPE is from amx, I am transferring this to AMX for investigation.

Comment by prasads [ 07/Oct/10 ]

Is this issue even relevant now , since Admin GUI does not use AMX ? Assigning
to Anissa for a response.

Comment by Anissa Lam [ 13/Oct/10 ]

Its true that GUI doesn't depend on AMX for 3.1.
However, the stack trace shows clearly that there is an NPE in getting the realm
names. It means there is an issue within AMX.
It is up to the amx team to determine if they want to fix this or not.

[#|2010-08-01T14:30:31.621-0700|WARNING|glassfish3.1|javax.enterprise.system.tools.admin.org.glassfish.server|_ThreadID=62;_ThreadName=http-thread-pool-4848(5);|getRealmNames():
Can't get realm names
java.lang.NullPointerException
at org.glassfish.admin.amx.impl.ext.RealmsImpl.getAuthRealms(RealmsImpl.java:107)
at
org.glassfish.admin.amx.impl.ext.RealmsImpl.getConfiguredRealmNames(RealmsImpl.java:113)
at org.glassfish.admin.amx.impl.ext.RealmsImpl.loadRealms(RealmsImpl.java:122)
at org.glassfish.admin.amx.impl.ext.RealmsImpl.getRealmNames(RealmsImpl.java:194)
at sun.reflect.GeneratedMethodAccessor368.invoke(Unknown Source)
at

Comment by prasads [ 08/Dec/10 ]

Excluding this issue from this release , since its not reproducible for now.

Comment by prasads [ 20/Feb/11 ]

Assigning issues to Naman

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.





[GLASSFISH-8893] Problem when getting deployment status form JetBrains IDEA ide Created: 27/Jul/09  Updated: 04/May/11

Status: Open
Project: glassfish
Component/s: amx
Affects Version/s: v2.2
Fix Version/s: None

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

Operating System: Windows Vista
Platform: Other


Issuezilla Id: 8,893
Status Whiteboard:

3.1-exclude v3_exclude

Tags: 3_1-exclude

 Description   

Trying to deploy war project form IDEA ide. When plugin tries to get deployment
status from Glassfish following one of the following stacktraces is swhon in
logs

Stacktrace 1

java.lang.reflect.UndeclaredThrowableException
at $Proxy119.getStandaloneServerConfigMap(Unknown Source)
at
com.sun.enterprise.deployment.client.DeploymentFacilityImpl.listAppRefs(Deployme
ntFacilityImpl.java:275)
at
com.fuhrer.idea.glassfish.server.GlassfishServer2.getDeploymentStatus(GlassfishS
erver2.java:156)
at
com.fuhrer.idea.glassfish.server.GlassfishServer2.handleDeployment(GlassfishServ
er2.java:83)
at
com.fuhrer.idea.javaee.server.JavaeeServerInstance$4.run(JavaeeServerInstance.ja
va:158)
at
com.intellij.openapi.application.impl.ApplicationImpl$5.run(ApplicationImpl.java
:10)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:8
86)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)
at
com.intellij.openapi.application.impl.ApplicationImpl$1$1.run(ApplicationImpl.ja
va:10)
Caused by: java.io.IOException
at
java.io.ObjectInputStream$PeekInputStream.readFully(ObjectInputStream.java:2281)
at
java.io.ObjectInputStream$BlockDataInputStream.readShort(ObjectInputStream.java:
2750)
at
java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:780)
at java.io.ObjectInputStream.<init>(ObjectInputStream.java:280)
at
com.sun.enterprise.admin.jmx.remote.comm.ServletConnection.receive(ServletConnec
tion.java:136)
at
com.sun.enterprise.admin.jmx.remote.comm.MBeanServerMessageConductor.invoke(MBea
nServerMessageConductor.java:84)
at
com.sun.enterprise.admin.jmx.remote.internal.RemoteMBeanServerConnection.getAttr
ibute(RemoteMBeanServerConnection.java:297)
at
com.sun.appserv.management.client.handler.AMXProxyHandler.invokeTarget(AMXProxyH
andler.java:460)
at
com.sun.appserv.management.client.handler.AMXProxyHandler.invokeProxyMapGetter(A
MXProxyHandler.java:654)
at
com.sun.appserv.management.client.handler.AMXProxyHandler._invoke(AMXProxyHandle
r.java:1101)
at
com.sun.appserv.management.client.handler.AMXProxyHandler.invoke(AMXProxyHandler
.java:1024)
... 13 more

Stacktrace 2

java.lang.reflect.UndeclaredThrowableException
at $Proxy119.getStandaloneServerConfigMap(Unknown Source)
at
com.sun.enterprise.deployment.client.DeploymentFacilityImpl.listAppRefs(Deployme
ntFacilityImpl.java:275)
at
com.fuhrer.idea.glassfish.server.GlassfishServer2.getDeploymentStatus(GlassfishS
erver2.java:156)
at
com.fuhrer.idea.glassfish.server.GlassfishServer2.handleDeployment(GlassfishServ
er2.java:83)
at
com.fuhrer.idea.javaee.server.JavaeeServerInstance$4.run(JavaeeServerInstance.ja
va:158)
at
com.intellij.openapi.application.impl.ApplicationImpl$5.run(ApplicationImpl.java
:10)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:8
86)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)
at
com.intellij.openapi.application.impl.ApplicationImpl$1$1.run(ApplicationImpl.ja
va:10)
Caused by: java.io.IOException
at
java.io.ObjectInputStream$PeekInputStream.readFully(ObjectInputStream.java:2281)
at
java.io.ObjectInputStream$BlockDataInputStream.readShort(ObjectInputStream.java:
2750)
at
java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:780)
at java.io.ObjectInputStream.<init>(ObjectInputStream.java:280)
at
com.sun.enterprise.admin.jmx.remote.comm.ServletConnection.receive(ServletConnec
tion.java:136)
at
com.sun.enterprise.admin.jmx.remote.comm.MBeanServerMessageConductor.invoke(MBea
nServerMessageConductor.java:84)
at
com.sun.enterprise.admin.jmx.remote.internal.RemoteMBeanServerConnection.getAttr
ibute(RemoteMBeanServerConnection.java:297)
at
com.sun.appserv.management.client.handler.AMXProxyHandler.invokeTarget(AMXProxyH
andler.java:460)
at
com.sun.appserv.management.client.handler.AMXProxyHandler.invokeProxyMapGetter(A
MXProxyHandler.java:654)
at
com.sun.appserv.management.client.handler.AMXProxyHandler._invoke(AMXProxyHandle
r.java:1101)
at
com.sun.appserv.management.client.handler.AMXProxyHandler.invoke(AMXProxyHandler
.java:1024)
... 13 more



 Comments   
Comment by zlowred [ 27/Jul/09 ]

PS
same works fine on Linux and MacOS.
PPS
doesn't work on WindowsXP on different PC

Comment by llc [ 27/Jul/09 ]

I won't be looking at this unless instructed to do so as a priority.

Comment by zlowred [ 27/Jul/09 ]

Maybe anyone else can take care of it?
Or, can you give any estimation when it can be done?

We are commercial developers and IDEA is a standard for commercial development. Because of this issue
we were forced to use JBoss as platform for our product. I don't think that this helps Glassfish to become
No1 open source enterprise platform.

Thanks

Comment by llc [ 27/Jul/09 ]

This is almost certainly not an AMX issue, the stack trace is deep down in DeploymentFacilityImpl.

I've inquired as to whether we'll fix this.

Comment by kumara [ 27/Jul/09 ]

GlassFish does JMX operations by sending serialized java objects over http and it looks like on some
platforms there is some data loss over the network and hence the exceptions while trying to read
objects from ServletConnection. The root cause could be anywhere from the issues on the local network
(where test is being run), for example firewall software to the configuration of http stack in glassfish
(maybe it needs to wait longer for all packets to arrive) to a plain bug.

To make further progress, it is important to get either a well defined test case to reproduce the problem
or detailed information on which APIs are being used and how (so we can create a test case).

As a workaround, it might be possible to use standard JMX RMI connector.

Comment by zlowred [ 27/Jul/09 ]

I don't this that it is related to local network config (doesn't work when running server on local PC) nor PC
config (doesn't work on different PC with different configuration and OS).
I'll try to communicate with JetBrains developer responsible for Glassfish integration.

Comment by kumara [ 24/Oct/09 ]

Excluding from v3 list because we no longer use the mechanism of "serialized java objects over http" for
deployment. We are still interested in getting a test case that can be used to reproduce the problem so it
can be fixed in next v2.x release.

Comment by Nazrul [ 15/May/10 ]

Excluding from 3.1





[GLASSFISH-4316] jdbc enhancement requirement Created: 29/Feb/08  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: amx
Affects Version/s: V3
Fix Version/s: not determined

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

Operating System: All
Platform: All


Issuezilla Id: 4,316
Status Whiteboard:

v3-prd-item


 Description   

Issue# 4129 is filed against GUI for jdbc enhancement.
However, GUI will not be able to provide them without backend support.
Here is the list:

  • Support for statement caching
  • Custom validation in jdbc-connection-pool
  • init-sql for jdbc-connection-pool
  • Flush Connection Pool (jdbc-connection-pool)
  • Clustered Pool, Load balancing
  • Associate with thread
  • Switch off connection pooling
  • Support Driver Manager based MCF
  • IT 3322
  • IT 3333

At this point, i don't know exactly which one of the list should come from admin
backend and which from jdbc group.
I am just opening up this issue so admin team is aware of this task.
We can work together and discuss about this more.



 Comments   
Comment by Anissa Lam [ 29/Feb/08 ]

set keyword and dependency.

Comment by km [ 07/Jan/10 ]

Since this is what GUI wants, AMX needs to be modified. Assigning to Lloyd.

Comment by llc [ 07/Jan/10 ]

"Since this is what GUI wants, AMX needs to be modified"
That's a non sequitor.

I'm not clear on what AMX should support here. But if there is a batch of custom functionality, it would be
long in some kind of worker MBean.

But strictly speaking, this is not an AMX issue at all— AMX is a framework, and does not need
"modification". Perhaps a new MBean needs to be created if there are new operations that are needed. Or
perhaps some of what is requested is already automatically exposed as methods derived form respective
config beans.

Comment by llc [ 07/Jan/10 ]

I need some actionable requirements eg a proposed API or APIs.

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.





[GLASSFISH-17933] Exception starting JMX connector Created: 08/Dec/11  Updated: 30/Jan/12

Status: Open
Project: glassfish
Component/s: amx
Affects Version/s: 3.1.2_b14
Fix Version/s: None

Type: Bug Priority: Major
Reporter: lidiam Assignee: prasads
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

ogs-3.1.2-b14-12_07_2011.zip, Windows XP


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

 Description   

When I start domain1, I see the following in server.log:

[#|2011-12-07T15:43:44.765-0800|WARNING|glassfish3.1.2|javax.enterprise.system.jmx.org.glassfish.admin.mbeanserver|_ThreadID=16;_ThreadName=Thread-2;|JMX007: Cannot start JMX connector JmxConnector config:

{ name = system, Protocol = rmi_jrmp, Address = 0.0.0.0, Port = 8686, AcceptAll = false, AuthRealmName = admin-realm, SecurityEnabled = false}

having exception java.io.IOException: Cannot bind to URL [rmi://jed-asqe-43.us.oracle.com:8686/jmxrmi]: javax.naming.CommunicationException [Root exception is java.rmi.ConnectIOException: Exception creating connection to: jed-asqe-43.us.oracle.com; nested exception is:

java.net.SocketException: Reply from SOCKS server has bad version]|#]

[#|2011-12-07T15:43:44.781-0800|SEVERE|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=16;_ThreadName=Thread-2;|java.io.IOException: Cannot bind to URL [rmi://jed-asqe-43.us.oracle.com:8686/jmxrmi]: javax.naming.CommunicationException [Root exception is java.rmi.ConnectIOException: Exception creating connection to: jed-asqe-43.us.oracle.com; nested exception is:

java.net.SocketException: Reply from SOCKS server has bad version]

at javax.management.remote.rmi.RMIConnectorServer.newIOException(RMIConnectorServer.java:804)

at javax.management.remote.rmi.RMIConnectorServer.start(RMIConnectorServer.java:417)

at org.glassfish.admin.mbeanserver.RMIConnectorStarter.start(RMIConnectorStarter.java:301)

at org.glassfish.admin.mbeanserver.JMXStartupService$JMXConnectorsStarterThread.startConnector(JMXStartupService.java:281)

at org.glassfish.admin.mbeanserver.JMXStartupService$JMXConnectorsStarterThread.run(JMXStartupService.java:322)

Caused by: javax.naming.CommunicationException [Root exception is java.rmi.ConnectIOException: Exception creating connection to: jed-asqe-43.us.oracle.com; nested exception is:

java.net.SocketException: Reply from SOCKS server has bad version]

at com.sun.jndi.rmi.registry.RegistryContext.rebind(RegistryContext.java:142)

at com.sun.jndi.toolkit.url.GenericURLContext.rebind(GenericURLContext.java:231)

at javax.naming.InitialContext.rebind(InitialContext.java:408)

at javax.naming.InitialContext.rebind(InitialContext.java:408)

at javax.management.remote.rmi.RMIConnectorServer.bind(RMIConnectorServer.java:623)

at javax.management.remote.rmi.RMIConnectorServer.start(RMIConnectorServer.java:412)

... 3 more

Caused by: java.rmi.ConnectIOException: Exception creating connection to: jed-asqe-43.us.oracle.com; nested exception is:

java.net.SocketException: Reply from SOCKS server has bad version

at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:614)

at sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:198)

at sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:184)

at sun.rmi.server.UnicastRef.newCall(UnicastRef.java:322)

at sun.rmi.registry.RegistryImpl_Stub.rebind(Unknown Source)

at com.sun.jndi.rmi.registry.RegistryContext.rebind(RegistryContext.java:140)

... 8 more

Caused by: java.net.SocketException: Reply from SOCKS server has bad version

at java.net.SocksSocketImpl.connectV4(SocksSocketImpl.java:269)

at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:437)

at java.net.Socket.connect(Socket.java:529)

at java.net.Socket.connect(Socket.java:478)

at java.net.Socket.<init>(Socket.java:375)

at java.net.Socket.<init>(Socket.java:189)

at sun.rmi.transport.proxy.RMIDirectSocketFactory.createSocket(RMIDirectSocketFactory.java:22)

at sun.rmi.transport.proxy.RMIMasterSocketFactory.createSocket(RMIMasterSocketFactory.java:128)

at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:595)

... 13 more

#]

Similar thing happens when starting a standalone instance:

[#|2011-12-07T17:33:01.281-0800|WARNING|glassfish3.1.2|javax.enterprise.system.jmx.org.glassfish.admin.mbeanserver|_ThreadID=17;_ThreadName=Thread-2;|JMX007: Cannot start JMX connector JmxConnector config:

{ name = system, Protocol = rmi_jrmp, Address = 0.0.0.0, Port = 28686, AcceptAll = false, AuthRealmName = admin-realm, SecurityEnabled = false}

having exception java.io.IOException: Cannot bind to URL [rmi://jed-asqe-43.us.oracle.com:28686/jmxrmi]: javax.naming.CommunicationException [Root exception is java.rmi.ConnectIOException: Exception creating connection to: jed-asqe-43.us.oracle.com; nested exception is:

java.net.SocketException: Reply from SOCKS server has bad version]|#]

[#|2011-12-07T17:33:01.281-0800|SEVERE|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=17;_ThreadName=Thread-2;|java.io.IOException: Cannot bind to URL [rmi://jed-asqe-43.us.oracle.com:28686/jmxrmi]: javax.naming.CommunicationException [Root exception is java.rmi.ConnectIOException: Exception creating connection to: jed-asqe-43.us.oracle.com; nested exception is:

java.net.SocketException: Reply from SOCKS server has bad version]

at javax.management.remote.rmi.RMIConnectorServer.newIOException(RMIConnectorServer.java:804)

at javax.management.remote.rmi.RMIConnectorServer.start(RMIConnectorServer.java:417)

at org.glassfish.admin.mbeanserver.RMIConnectorStarter.start(RMIConnectorStarter.java:301)

at org.glassfish.admin.mbeanserver.JMXStartupService$JMXConnectorsStarterThread.startConnector(JMXStartupService.java:281)

at org.glassfish.admin.mbeanserver.JMXStartupService$JMXConnectorsStarterThread.run(JMXStartupService.java:322)

Caused by: javax.naming.CommunicationException [Root exception is java.rmi.ConnectIOException: Exception creating connection to: jed-asqe-43.us.oracle.com; nested exception is:

java.net.SocketException: Reply from SOCKS server has bad version]

at com.sun.jndi.rmi.registry.RegistryContext.rebind(RegistryContext.java:142)

at com.sun.jndi.toolkit.url.GenericURLContext.rebind(GenericURLContext.java:231)

at javax.naming.InitialContext.rebind(InitialContext.java:408)

at javax.naming.InitialContext.rebind(InitialContext.java:408)

at javax.management.remote.rmi.RMIConnectorServer.bind(RMIConnectorServer.java:623)

at javax.management.remote.rmi.RMIConnectorServer.start(RMIConnectorServer.java:412)

... 3 more

Caused by: java.rmi.ConnectIOException: Exception creating connection to: jed-asqe-43.us.oracle.com; nested exception is:

java.net.SocketException: Reply from SOCKS server has bad version

at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:614)

at sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:198)

at sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:184)

at sun.rmi.server.UnicastRef.newCall(UnicastRef.java:322)

at sun.rmi.registry.RegistryImpl_Stub.rebind(Unknown Source)

at com.sun.jndi.rmi.registry.RegistryContext.rebind(RegistryContext.java:140)

... 8 more

Caused by: java.net.SocketException: Reply from SOCKS server has bad version

at java.net.SocksSocketImpl.connectV4(SocksSocketImpl.java:269)

at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:437)

at java.net.Socket.connect(Socket.java:529)

at java.net.Socket.connect(Socket.java:478)

at java.net.Socket.<init>(Socket.java:375)

at java.net.Socket.<init>(Socket.java:189)

at sun.rmi.transport.proxy.RMIDirectSocketFactory.createSocket(RMIDirectSocketFactory.java:22)

at sun.rmi.transport.proxy.RMIMasterSocketFactory.createSocket(RMIMasterSocketFactory.java:128)

at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:595)

... 13 more

#]


 Comments   
Comment by Joe Di Pol [ 30/Jan/12 ]

Not a 3.1.2 stopper.





[GLASSFISH-18968] Possible atomicity violations because of misusing ConcurrentHashMap Created: 01/Aug/12  Updated: 01/Aug/12

Status: Open
Project: glassfish
Component/s: amx
Affects Version/s: 3.1.2
Fix Version/s: None

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

Attachments: Text File glassfish-3.1.2-amx.patch    

 Description   

My name is Yu Lin. I'm a Ph.D. student in the CS department at
UIUC. I'm currently doing research on mining Java concurrent library
misusages. I found some possible misuses of ConcurrentHashMap in amx
component of GlassFish 3.1.2, which may result in potential atomicity
violation bugs.

The code below is a snapshot of the code in file
common/amx-core-impl/src/main/java/org/glassfish/admin/amx/impl/mbean/PathnamesImpl.java
from line 85 to 164

L85 public ObjectName resolvePath(final String path) {
L86 ObjectName result = mPathnameCache.get(path);
L87 if (result != null)

{ L88 return result; L89 }

... // create "objectName"
L159 if (objectName != null)

{ L160 //cdebug( "Matched " + path + " to " + objectName); L161 mPathnameCache.put(path, objectName); L162 }

L164 return objectName;
L165 }

In the code above, there might be an atomicity violation: suppose a
thread T1 executes line 86 and finds out the concurrent hashmap
"mPathnameCache" does not contain the key "path". Before it
gets to execute line 161, another thread T2 puts a pair <path, v>
in the map "mPathnameCache". Now thread T1 resumes execution and
it will overwrite the value written by thread T2. Thus, the code no
longer preserves the "put-if-absent" semantics, and thread T2 will
return an "objectName" that is not in the map "mPathnameCache". May this
thread interleaving happen? Will it result in buggy behavior?

Similar problem can be found in
common/amx-core/src/main/java/org/glassfish/admin/amx/core/proxy/ProxyFactory.java
line 434.

This issue is related to GLASSFISH-18964. I attach a patch to fix the problem.






[GLASSFISH-18852] NullPointerException in method AMXConfigImpl.translateResult Created: 27/Jun/12  Updated: 18/Feb/13

Status: Open
Project: glassfish
Component/s: amx
Affects Version/s: 3.1.2, 4.0_b01, 4.0_b02, 4.0_b03, 4.0_b04, 4.0_b05, 4.0_b06, 4.0_b08, 4.0_b09, 4.0_b10, 4.0_b11, 4.0_b12, 4.0_b13, 4.0_b14, 4.0_b15, 4.0_b16, 4.0_b17, 4.0_b18, 4.0_b19, 4.0_b20, 4.0_b21, 4.0_b22, 4.0_b23, 4.0_b24, 4.0_b25, 4.0_b26, 4.0_b27, 4.0_b28, 4.0_b29, 4.0_b30, 4.0_b31, 4.0_b32_ms1, 4.0_b33, 4.0_b34, 4.0_b35, 4.0_b36, 4.0_b37, 4.0_b38_ms2, 4.0_b39, 4.0_b40, 4.0_b41, 4.0_b42
Fix Version/s: None

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

Linux Fedora 16 x64
GlassFish 3.1.2


Tags: AMX, JMX, administration, configuration

 Description   

While remotely calling method "void deleteResourceRef(String)" of a Server instance execution fails with NullPointerException thrown from method "Object AMXConfigImpl.translateResult(Object)" with argument result==null. I think null is a normal situation in case of remote method with void return value.



 Comments   
Comment by mahairod [ 06/Jan/13 ]

Will be there some progress? It's very simple task I can even do it by myself

Comment by prasads [ 18/Feb/13 ]

Re-assigning to Peter Bower who looks after JMX





[GLASSFISH-15740] Numerous exceptions when connecting to JMX port when running in Turkish locale Created: 28/Jan/11  Updated: 11/Feb/13

Status: Open
Project: glassfish
Component/s: amx
Affects Version/s: 3.1_b39
Fix Version/s: None

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

Linux


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

 Description   

While investigating whether issue 3851 is still a problem, I encountered some problems with using JMX when the server is running in the Turkish locale. Here is how to recreate the problem:

export LANG=tr_TR
asadmin create-domain domain2
asadmin start-domain domain2

(everything is ok so far).

Now, start the jconsole program and create a remote connection to the DAS on port 8686.
Many exceptions will be output to the log, starting with this one:

[#|2011-01-28T08:28:36.864-0800|INFO|glassfish3.1|javax.enterprise.system.tools.admin.org.glassfish.server|_ThreadID=120;_ThreadName=ComplianceMonitor.ValidatorThread;|amx:pp=/,type=system-ýnfo

org.glassfish.admin.amx.core.AMXValidator$ValidationFailureException: "Illegal type "system-ýnfo", does not match ([**$a-zA-Z0-9._-][**$a-zA-Z0-9._-]*)"
org.glassfish.admin.amx.core.AMXValidator.fail(AMXValidator.java:750)
org.glassfish.admin.amx.core.AMXValidator.validateObjectName(AMXValidator.java:825)
org.glassfish.admin.amx.core.AMXValidator._validate(AMXValidator.java:540)
org.glassfish.admin.amx.core.AMXValidator.validate(AMXValidator.java:1344)
org.glassfish.admin.amx.impl.mbean.ComplianceMonitor$ValidatorThread.doRun(ComplianceMonitor.java:237)
org.glassfish.admin.amx.impl.mbean.ComplianceMonitor$ValidatorThread.run(ComplianceMonitor.java:214)

java.lang.IllegalArgumentException: "Illegal type: system-ýnfo"
org.glassfish.admin.amx.core.PathnameParser.checkType(PathnameParser.java:364)
org.glassfish.admin.amx.core.PathnameParser.pathPart(PathnameParser.java:380)
org.glassfish.admin.amx.core.PathnameParser.pathPart(PathnameParser.java:374)
org.glassfish.admin.amx.core.PathnameParser.path(PathnameParser.java:393)
org.glassfish.admin.amx.core.proxy.AMXProxyHandler.path(AMXProxyHandler.java:1011)
org.glassfish.admin.amx.core.proxy.AMXProxyHandler.handleSpecialMethod(AMXProxyHandler.java:431)
org.glassfish.admin.amx.core.proxy.AMXProxyHandler._invoke(AMXProxyHandler.java:797)
org.glassfish.admin.amx.core.proxy.AMXProxyHandler.invoke(AMXProxyHandler.java:531)
$Proxy179.path(Unknown Source)
org.glassfish.admin.amx.core.AMXValidator._validate(AMXValidator.java:603)
org.glassfish.admin.amx.core.AMXValidator.validate(AMXValidator.java:1344)
org.glassfish.admin.amx.impl.mbean.ComplianceMonitor$ValidatorThread.doRun(ComplianceMonitor.java:237)
org.glassfish.admin.amx.impl.mbean.ComplianceMonitor$ValidatorThread.run(ComplianceMonitor.java:214)

General test failure:
java.lang.IllegalArgumentException: "Illegal type: system-ýnfo"
org.glassfish.admin.amx.core.PathnameParser.checkType(PathnameParser.java:364)
org.glassfish.admin.amx.core.PathnameParser.pathPart(PathnameParser.java:380)
org.glassfish.admin.amx.core.PathnameParser.pathPart(PathnameParser.java:374)
org.glassfish.admin.amx.core.PathnameParser.path(PathnameParser.java:393)
org.glassfish.admin.amx.core.proxy.AMXProxyHandler.path(AMXProxyHandler.java:1011)
org.glassfish.admin.amx.core.proxy.AMXProxyHandler.handleSpecialMethod(AMXProxyHandler.java:431)
org.glassfish.admin.amx.core.proxy.AMXProxyHandler._invoke(AMXProxyHandler.java:797)
org.glassfish.admin.amx.core.proxy.AMXProxyHandler.invoke(AMXProxyHandler.java:531)
$Proxy179.path(Unknown Source)
org.glassfish.admin.amx.core.AMXValidator._validate(AMXValidator.java:672)
org.glassfish.admin.amx.core.AMXValidator.validate(AMXValidator.java:1344)
org.glassfish.admin.amx.impl.mbean.ComplianceMonitor$ValidatorThread.doRun(ComplianceMonitor.java:237)
org.glassfish.admin.amx.impl.mbean.ComplianceMonitor$ValidatorThread.run(ComplianceMonitor.java:214)

1 failures.
1 MBeans tested.|#]

Note that the letter "I" is output as "ý" in the exception message. Issue 3851 also mentions problems with the Turkish locale and the letter I. Details of the problem are in this article: http://java.sys-con.com/node/46241

After the exceptions are generated, the JMX connection is lost, and jconsole cannot connect to the domain anymore. Restarting the domain in an English locale fixes the problem.



 Comments   
Comment by Tom Mueller [ 28/Jan/11 ]

The attached server.log file contains all of the exception messages that were generated when connecting to the DAS that is running in the Turkish locale from jconsole.

Comment by Nazrul [ 03/Feb/11 ]

In the last meeting with Prasad, this was slated to be excluded from 3.1. So, adding 3.1-exclude.

Comment by prasads [ 20/Feb/11 ]

Assigning issues to Naman

Comment by naman_mehta [ 29/Mar/11 ]

I tried to reproduce the issue but can't. I followed the steps as mention in the issue.

But when I am starting jconsole it works fine for me. No exception in server.log also.

So the question,
Do I need to change the my machine locale also from where I am running jconsole? Is this reproducible on any machine?

I am getting below message:
jconsole
default to Motif 2.1, os is: 2.6.35-28-generic
Warning: Cannot convert string "dejavu-dejavu sans-medium-r-normal-140-p-iso10646-1" to type FontStruct

(process:8013): Gtk-WARNING **: Locale not supported by C library.
Using the fallback 'C' locale.

Comment by Tom Mueller [ 29/Mar/11 ]

Try running the server on Linux. The locale for running jconsole doesn't matter.

Comment by ozhanduz [ 18/Apr/11 ]

RMI and JMX has bug related with this problem.

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

Comment by naman_mehta [ 07/Dec/11 ]

This is the turkish locale problem with Java. So I am excluding this bug fo 3.1.2 cycle.





[GLASSFISH-21193] Attaching to the JMX port causes the default realm to change to file Created: 11/Sep/14  Updated: 11/Sep/14

Status: Open
Project: glassfish
Component/s: amx
Affects Version/s: 3.1.2_b05
Fix Version/s: None

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


 Description   

We have seen the following issue with two separate JAAS realm configurations. In both cases the default realm is NOT set to file however, as soon as we attach to the JMX port using JConsole, Glassfish starts to authenticate all users via the file realm. As a result the application is unusable.






[GLASSFISH-20879] JMXConnectorFactory.connect() method takes too long and reports "User [] from host null does not have administration access" Created: 29/Oct/13  Updated: 29/Oct/13

Status: Open
Project: glassfish
Component/s: amx
Affects Version/s: 3.1.2.2
Fix Version/s: None

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

Windows 7/Ubuntu


Tags: amx, jmx

 Description   

The problem is that every time i start my server and make a connection to jmx with JMXConnectorFactory.connect(url, credentials) i get a lot of messages like this "User [] from host null does not have administration access" and after about a minute the connection is made successful. Credentials are correct and in my case they are "admin/a". Also i receive this message when querying REST API with a Jersey client. Just to be sure does the connection establishment has to be that long on the first attempt or it is because of login problems reported by glassfish?



 Comments   
Comment by ser9giu [ 29/Oct/13 ]

I just made some tests, and it seems connecting to the DAS through Jconsole also takes about a minute and it logs same thing "com.su_.GenericAdminAuthenticator|175|User [] from host null does not have administration access". Is there any workaround?





[GLASSFISH-21214] QL AMX/JMX test failure with JDK8 Created: 25/Sep/14  Updated: 16/Oct/15

Status: Open
Project: glassfish
Component/s: amx
Affects Version/s: 4.1
Fix Version/s: future release

Type: Bug Priority: Major
Reporter: Romain Grécourt Assignee: Vinay Vishal
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

JDK8



 Description   

Test output shows:

   [testng] PROBLEMS:
   [testng] null:type=Null,name=Null

Nothing obvious in the server log.

Title and Description to be updated when initial investigation is done.



 Comments   
Comment by prasads [ 09/Jul/15 ]

Vinay, Can you work with Shaifali to debug this case please ?

Comment by Jill Sato [ 16/Oct/15 ]

This test is ignored under quicklook. Please comment back it when bug has been resolved. Thanks.

trunk/main/appserver/tests/quicklook/amx/src/test/amx/AMXProxyTests.java
/** test all MBeans generically */

  • @Test
    + @Test(/* GLASSFISH-21214 */enabled=false)
    public void testAllGenerically()
    {




[GLASSFISH-10300] Failed to read attribute XXX from MBean com.sun.appserv:type=Manager,path=/logs,host=server if /logs failed to deploy Created: 15/Oct/09  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: amx
Affects Version/s: 9.1peur2
Fix Version/s: not determined

Type: Bug Priority: Minor
Reporter: dobes Assignee: naman_mehta
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 10,300
Status Whiteboard:

V2.1.1_exclude

Tags: 3_1-exclude

 Description   

I get a whole bunch of errors in the logs each time I start glassfish, each
looking the same except a different attribute is reported; this seems to be
related to an app that failed to deploy.

If deployment fails, it should probably not bother with whatever is causing
these errors:

[#|2009-10-15T06:17:48.343-0700|SEVERE|sun-appserver9.1|org.apache.catalina.core.StandardContext|_ThreadID=10;_ThreadName=main;_RequestID=67431d93-b914-4021-8047-0830b9a68b1d;|PWC1300:
Error starting resources in context /logs|#]

[#|2009-10-15T06:17:48.343-0700|SEVERE|sun-appserver9.1|org.apache.catalina.core.StandardContext|_ThreadID=10;_ThreadName=main;_RequestID=67431d93-b914-4021-8047-0830b9a68b1d;|PWC4430:
Document base
/usr/local/glassfish/domains/domain1/applications/j2ee-modules/glassfish-dashboard
does not exist or is not a readable directory|#]

[#|2009-10-15T06:17:48.349-0700|SEVERE|sun-appserver9.1|org.apache.catalina.core.StandardContext|_ThreadID=10;_ThreadName=main;_RequestID=67431d93-b914-4021-8047-0830b9a68b1d;|PWC1306:
Startup of context /logs failed due to previous errors|#]

[#|2009-10-15T06:17:48.349-0700|INFO|sun-appserver9.1|org.apache.catalina.core.StandardContext|_ThreadID=10;_ThreadName=main;|PWC1240:
Container WebModule[/logs] has not been started|#]

[#|2009-10-15T06:17:48.367-0700|SEVERE|sun-appserver9.1|javax.enterprise.system.container.web.pwc|_ThreadID=15;_ThreadName=Thread-12;_RequestID=8573594f-aae6-4863-9379-157dce0bdcf4;|PWC1002:
Failed to read attribute expiredSessions from MBean
com.sun.appserv:type=Manager,path=/logs,host=server
javax.management.InstanceNotFoundException: This operation failed, because it
could not be handled by this domain.
An example of such an operation is creating application server instances or
clusters when they are not supported by the given domain.
The actual error is: MBean instance not found:
com.sun.appserv:type=Manager,path=/logs,host=server
at
com.sun.enterprise.admin.server.core.jmx.SunoneInterceptor.manufactureAndRegisterMBean(SunoneInterceptor.java:663)
at
com.sun.enterprise.admin.server.core.jmx.SunoneInterceptor.registerWithPersistenceCheck(SunoneInterceptor.java:692)
at
com.sun.enterprise.admin.server.core.jmx.SunoneInterceptor.getAttribute(SunoneInterceptor.java:315)
at
com.sun.enterprise.interceptor.DynamicInterceptor.getAttribute(DynamicInterceptor.java:192)
at
com.sun.enterprise.web.monitor.impl.PwcWebModuleStatsImpl.queryStatistic(PwcWebModuleStatsImpl.java:418)
at
com.sun.enterprise.web.monitor.impl.PwcWebModuleStatsImpl.getExpiredSessionsTotal(PwcWebModuleStatsImpl.java:248)
at
com.sun.enterprise.web.stats.WebModuleStatsImpl.getExpiredSessionsTotal(WebModuleStatsImpl.java:256)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
com.sun.enterprise.admin.monitor.stats.GenericStatsImpl.getStatistic(GenericStatsImpl.java:119)
at
com.sun.enterprise.admin.monitor.stats.GenericStatsImpl.getStatisticsOneByOne(GenericStatsImpl.java:145)
at
com.sun.enterprise.admin.monitor.stats.GenericStatsImpl.getStatistics(GenericStatsImpl.java:136)
at
com.sun.enterprise.web.stats.WebModuleStatsImpl.getStatistics(WebModuleStatsImpl.java:347)
at
com.sun.enterprise.admin.monitor.registry.spi.StatsHolderMBeanImpl.getStatistics(StatsHolderMBeanImpl.java:398)
at
com.sun.enterprise.admin.monitor.registry.spi.StatsHolderMBeanImpl.invoke(StatsHolderMBeanImpl.java:213)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:836)
at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:761)
at sun.reflect.GeneratedMethodAccessor14.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
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.management.support.DelegateToMBeanDelegate.invoke(DelegateToMBeanDelegate.java:184)
at
com.sun.enterprise.management.support.MappedDelegate.invoke(MappedDelegate.java:389)
at
com.sun.enterprise.management.support.DelegateInvocationHandler.invoke(DelegateInvocationHandler.java:98)
at com.sun.enterprise.management.monitor.$Proxy13.getStatistics(Unknown Source)
at
com.sun.enterprise.management.monitor.MonitoringStatsImplBase.checkUnderlyingMBean(MonitoringStatsImplBase.java:347)
at
com.sun.enterprise.management.monitor.MonitoringStatsImplBase.preRegisterHook(MonitoringStatsImplBase.java:912)
at
com.sun.enterprise.management.support.AMXImplBase.preRegister(AMXImplBase.java:2215)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.preRegisterInvoke(DefaultMBeanServerInterceptor.java:1010)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:938)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:917)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:312)
at com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:482)
at
com.sun.enterprise.interceptor.DynamicInterceptor.registerMBean(DynamicInterceptor.java:263)
at com.sun.enterprise.management.support.Loader.registerNew(Loader.java:427)
at
com.sun.enterprise.management.support.LoaderOfOld.registerNew(LoaderOfOld.java:212)
at
com.sun.enterprise.management.support.LoaderOfOld.ensureNew(LoaderOfOld.java:397)
at
com.sun.enterprise.management.support.LoaderOfOld.syncWithOld(LoaderOfOld.java:417)
at com.sun.enterprise.management.support.Loader._sync(Loader.java:548)
at com.sun.enterprise.management.support.Loader.sync(Loader.java:522)
at
com.sun.enterprise.management.support.Loader.handleMBeanRegistered(Loader.java:209)
at
com.sun.enterprise.management.support.LoaderRegThread.processRegistration(LoaderRegThread.java:204)
at
com.sun.enterprise.management.support.LoaderRegThread.process(LoaderRegThread.java:253)
at
com.sun.enterprise.management.support.LoaderRegThread.run(LoaderRegThread.java:154)

#]

Steps to reproduce:

1. Deploy a war
2. Delete the war folder without undeploying it
3. Now glassfish is angry

Sometimes we have to bypass glassfish' undeploy because glassfish won't start
due to something that is deployed; in that case we deleted the folder but
glassfish still tries to deploy it and then prints all those errors.



 Comments   
Comment by jagadesh [ 15/Oct/09 ]

Will not be fixed for V2.1.1

Comment by jagadesh [ 15/Oct/09 ]

Will not be fixed for V2.1.1

Comment by Tom Mueller [ 23/Jun/10 ]

Lloyd no longer on project.

Comment by prasads [ 07/Oct/10 ]

Excluding these issues from v3.1

Comment by prasads [ 20/Feb/11 ]

Assigning issues to Naman

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.





[GLASSFISH-11403] Invalid JMX object name for deployment unit under Windows-OS Created: 07/Jan/10  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: amx
Affects Version/s: V3
Fix Version/s: not determined

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

Operating System: Windows Vista
Platform: PC


Issuezilla Id: 11,403

 Description   

Stack-Trace:

[#|2010-01-07T13:54:25.435+0100|INFO|glassfishv3.0|javax.enterprise.system.tools.admin.org.glassfish.server|_ThreadID=30;_ThreadName=Thread-1;|Exception
registering application: atm
java.lang.RuntimeException: Cannot register
J2EEApplication=C:-Development-projects-atm-trunk-projectroot-build-atm-domain-applications-atm
as child of amx:pp=/J2EEDomain,type=J2EEServer,name=server,j2eeType=J2EEServer
at
org.glassfish.admin.amx.impl.j2ee.RegistrationSupport.registerJ2EEChild(RegistrationSupport.java:554)
at
org.glassfish.admin.amx.impl.j2ee.RegistrationSupport.createAppMBeans(RegistrationSupport.java:246)
at
org.glassfish.admin.amx.impl.j2ee.RegistrationSupport.processApplicationRef(RegistrationSupport.java:522)
at
org.glassfish.admin.amx.impl.j2ee.RegistrationSupport.registerApplications(RegistrationSupport.java:474)
at
org.glassfish.admin.amx.impl.j2ee.RegistrationSupport.<init>(RegistrationSupport.java:158)
at
org.glassfish.admin.amx.impl.j2ee.J2EEServerImpl.registerChildren(J2EEServerImpl.java:116)
at
org.glassfish.admin.amx.impl.j2ee.DASJ2EEServerImpl.registerChildren(DASJ2EEServerImpl.java:68)
at
org.glassfish.admin.amx.impl.mbean.AMXImplBase.postRegisterHook(AMXImplBase.java:1168)
at
org.glassfish.admin.amx.impl.mbean.MBeanImplBase.postRegister(MBeanImplBase.java:448)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.postRegisterInvoke(DefaultMBeanServerInterceptor.java:1035)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:974)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:917)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:312)
at
com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:482)
at
org.glassfish.admin.amx.impl.mbean.AMXImplBase.registerChild(AMXImplBase.java:1243)
at
org.glassfish.admin.amx.impl.j2ee.J2EEDomainImpl.registerChildren(J2EEDomainImpl.java:93)
at
org.glassfish.admin.amx.impl.mbean.AMXImplBase.postRegisterHook(AMXImplBase.java:1168)
at
org.glassfish.admin.amx.impl.mbean.MBeanImplBase.postRegister(MBeanImplBase.java:448)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.postRegisterInvoke(DefaultMBeanServerInterceptor.java:1035)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:974)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:917)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:312)
at
com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:482)
at
org.glassfish.admin.amx.impl.j2ee.loader.AMXJ2EEStartupService.loadAMXMBeans(AMXJ2EEStartupService.java:133)
at
org.glassfish.admin.amx.impl.AMXStartupService$AMXLoaderThread.run(AMXStartupService.java:321)
Caused by: java.lang.RuntimeException: Invalid character ':' in value part of
property
at org.glassfish.admin.amx.util.jmx.JMXUtil.newObjectName(JMXUtil.java:158)
at org.glassfish.admin.amx.util.jmx.JMXUtil.newObjectName(JMXUtil.java:176)
at
org.glassfish.admin.amx.impl.util.ObjectNameBuilder.buildChildObjectName(ObjectNameBuilder.java:188)
at
org.glassfish.admin.amx.impl.util.ObjectNameBuilder.buildChildObjectName(ObjectNameBuilder.java:145)
at
org.glassfish.admin.amx.impl.j2ee.RegistrationSupport.registerJ2EEChild(RegistrationSupport.java:549)
... 24 more
Caused by: javax.management.MalformedObjectNameException: Invalid character ':'
in value part of property
at javax.management.ObjectName.construct(ObjectName.java:602)
at javax.management.ObjectName.<init>(ObjectName.java:1403)
at org.glassfish.admin.amx.util.jmx.JMXUtil.newObjectName(JMXUtil.java:154)
... 28 more

#]

Proposed patch:

Index: deployment/dol/src/main/java/com/sun/enterprise/deployment/Application.java
===================================================================
— deployment/dol/src/main/java/com/sun/enterprise/deployment/Application.java
(revision 35236)
+++ deployment/dol/src/main/java/com/sun/enterprise/deployment/Application.java
(working copy)
@@ -860,6 +860,7 @@
*/
public void setName(String name) {
name = name.replace('/', '-');
+ name = name.replace(':', '-'); // for building valid JMX object names
name = name.replace('
', '-'); // for deploying from NT to solaris &
vice versa. This will
// need to be cleaned when we clean up the backend for registering apps
super.setName(name);



 Comments   
Comment by Hong Zhang [ 07/Jan/10 ]

assign to lloyd for initial evaluation

Comment by llc [ 07/Jan/10 ]

The ":" is the only real issue here for JMX.

This could be fixed in AMX, or we can choose to not generate such application names (probably a good
idea).

Comment by llc [ 26/Jan/10 ]

For JMX ObjectNames, a '/' in the name is perfectly acceptable; it is already used intentionally for the "pp"
attribute. A '\' is not a problem either.

It is the ':" that is the issue.

Go ahead and make the change for the ':', and unless there is a reason, I'd suggest not whacking the /
and \ characters.

Comment by llc [ 26/Jan/10 ]

One concern I have here: make sure that we do not get a divergence from config/monitoring/runtime
names otherwise there is no easy programmatic way to know what config or monitoring MBean matches
with the runtime MBean.

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.





[GLASSFISH-11272] duplicate VS can be created, causing web container failed to startup Created: 07/Dec/09  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: amx
Affects Version/s: V3
Fix Version/s: not determined

Type: Bug Priority: Minor
Reporter: simonfojtu Assignee: prasads
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: other
Platform: PC


Attachments: PNG File gfv3_b74a_es_12.png     Text File server.log    
Issuezilla Id: 11,272
Status Whiteboard:

v3_exclude

Tags: 3_1-exclude

 Description   

Providing an already existing name causes error, but user doesn't know what's
wrong (just "An error has occurred")

How to reproduce:

  • Configuration -> Virtual Servers -> New
  • Enter a name which is already used, e.g. 'server', click Next
  • Error message "An error has occurred"


 Comments   
Comment by simonfojtu [ 07/Dec/09 ]

Created an attachment (id=4058)
screenshot with localized generic error message

Comment by Anissa Lam [ 07/Dec/09 ]

Normally, if you create an object that has already exists, you get some error
message saying 'Key' is not unique. That isn't perfect either, but that should
be what to expect.

However, virtual server seems to be handled differently.
There is no exception thrown by the backend, and whats worst, after i did this
couple times, say, trying to create a virtual server with the name "server", I
saw many written out to domain.xml, like this:

<http-service>
<access-log />
<virtual-server id="server"
network-listeners="http-listener-1,http-listener-2" />
<virtual-server id="__asadmin" network-listeners="admin-listener" />
<virtual-server id="server" />
<virtual-server id="server" />
<virtual-server id="server" />
<virtual-server id="server" />
</http-service>

And the web container can't even startup when i restart the server, giving this
error:

[#|2009-12-07T10:15:22.258-0800|SEVERE|glassfishv3.0|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=23;_ThreadName=Thread-23;|Cannot
start container web
java.lang.IllegalArgumentException: addChild: Child name 'server' is not unique
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:922)

Given the severeness of the consequence of this issue, (any duplicate vs name,
not just "server", will cause the web container failed to startup),
I mark this as P2 so it can be looked at asap and decide if this should be
release noted.

CLI is able to give the correct error msg:
com.sun.enterprise.admin.cli.CommandException: remote failure: Virtual Server
named server already exists.

I am not sure if i should transfer to configuration or amx, please reassign if
needed.

I changed the summary to reflect this better also.

Comment by kumara [ 07/Dec/09 ]

The issue is about error handling and therefore is not a show stopper for GlassFish v3 release.

Comment by Anissa Lam [ 07/Dec/09 ]

Just to clarify when i say 'no exception thrown by backend'.
There is an exception logged, but somehow got lost and amx.createChild() doesn't
throw the exception.

[#|2009-12-07T10:51:30.053-0800|SEVERE|glassfishv3.0|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=31;_ThreadName=pool-17-thread-1;|Exception
while processing config bean changes :
java.lang.IllegalArgumentException: addChild: Child name 'server' is not unique
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:922)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:912)
at org.apache.catalina.core.StandardEngine.addChild(StandardEngine.java:359)
at com.sun.enterprise.web.WebContainer.createHost(WebContainer.java:1180)
at
com.sun.enterprise.web.reconfig.WebConfigListener$1.changed(WebConfigListener.java:122)
at org.jvnet.hk2.config.ConfigSupport.sortAndDispatch(ConfigSupport.java:271)
at
com.sun.enterprise.web.reconfig.WebConfigListener.changed(WebConfigListener.java:113)
at
org.jvnet.hk2.config.Transactions$ConfigListenerJob.process(Transactions.java:365)
at
org.jvnet.hk2.config.Transactions$ConfigListenerJob.process(Transactions.java:355)
at
org.jvnet.hk2.config.Transactions$ConfigListenerNotifier$1$1.call(Transactions.java:248)
at
org.jvnet.hk2.config.Transactions$ConfigListenerNotifier$1$1.call(Transactions.java:246)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:637)

#]
Comment by Anissa Lam [ 07/Dec/09 ]

Created an attachment (id=4060)
server.log when creating dup. VS in GUI

Comment by ne110415 [ 07/Dec/09 ]

I see two exceptions. One from Config backend. And another one –
InstanceAlreadyExistsException from AMX (AMX tries to create an MBean with same
name and it fails). (See the trace below)

So are you saying GUI does not get the AMX exception?

----- TRACE FOR AMX EXCEPTION-----

javax.management.InstanceAlreadyExistsException:
"amx:pp=/domain/configs/config[server-config]/http-service,type=virtual-server,name=server"
com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:453)
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.internal_addObject(DefaultMBeanServerInterceptor.java:1484)
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:963)
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:917)
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:312)
com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:482)
org.glassfish.admin.amx.impl.config.AMXConfigLoader.createAndRegister(AMXConfigLoader.java:665)
org.glassfish.admin.amx.impl.config.AMXConfigLoader._registerConfigBeanAsMBean(AMXConfigLoader.java:637)
org.glassfish.admin.amx.impl.config.AMXConfigLoader.registerConfigBeanAsMBean(AMXConfigLoader.java:605)
org.glassfish.admin.amx.impl.config.AMXConfigLoader.access$100(AMXConfigLoader.java:80)
org.glassfish.admin.amx.impl.config.AMXConfigLoader$AMXConfigLoaderThread.registerOne(AMXConfigLoader.java:513)
org.glassfish.admin.amx.impl.config.AMXConfigLoader$AMXConfigLoaderThread.doRun(AMXConfigLoader.java:583)
org.glassfish.admin.amx.impl.config.AMXConfigLoader$AMXConfigLoaderThread.run(AMXConfigLoader.java:533)

#]

----TRACE FOR CONFIG EXCEPTION----

[#|2009-12-07T11:01:37.038-0800|SEVERE|glassfishv3.0|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=29;_ThreadName=pool-16-thread-1;|Exception
while processing config bean changes :
java.lang.IllegalArgumentException: addChild: Child name 'server' is not unique
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:922)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:912)
at org.apache.catalina.core.StandardEngine.addChild(StandardEngine.java:359)
at com.sun.enterprise.web.WebContainer.createHost(WebContainer.java:1180)
at
com.sun.enterprise.web.reconfig.WebConfigListener$1.changed(WebConfigListener.java:122)
at org.jvnet.hk2.config.ConfigSupport.sortAndDispatch(ConfigSupport.java:271)
at
com.sun.enterprise.web.reconfig.WebConfigListener.changed(WebConfigListener.java:113)
at
org.jvnet.hk2.config.Transactions$ConfigListenerJob.process(Transactions.java:365)
at
org.jvnet.hk2.config.Transactions$ConfigListenerJob.process(Transactions.java:355)
at
org.jvnet.hk2.config.Transactions$ConfigListenerNotifier$1$1.call(Transactions.java:248)
at
org.jvnet.hk2.config.Transactions$ConfigListenerNotifier$1$1.call(Transactions.java:246)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:637)

#]

[#|2009-12-07T11:01:37.038-0800|SEVERE|glassfishv3.0|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=29;_ThreadName=pool-16-thread-1;|Exception
while processing config bean changes :
java.lang.IllegalArgumentException: addChild: Child name 'server' is not unique
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:922)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:912)
at org.apache.catalina.core.StandardEngine.addChild(StandardEngine.java:359)
at com.sun.enterprise.web.WebContainer.createHost(WebContainer.java:1180)
at
com.sun.enterprise.web.reconfig.WebConfigListener$1.changed(WebConfigListener.java:122)
at org.jvnet.hk2.config.ConfigSupport.sortAndDispatch(ConfigSupport.java:271)
at
com.sun.enterprise.web.reconfig.WebConfigListener.changed(WebConfigListener.java:113)
at
org.jvnet.hk2.config.Transactions$ConfigListenerJob.process(Transactions.java:365)
at
org.jvnet.hk2.config.Transactions$ConfigListenerJob.process(Transactions.java:355)
at
org.jvnet.hk2.config.Transactions$ConfigListenerNotifier$1$1.call(Transactions.java:248)
at
org.jvnet.hk2.config.Transactions$ConfigListenerNotifier$1$1.call(Transactions.java:246)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:637)

#]

[#|2009-12-07T11:01:37.038-0800|SEVERE|glassfishv3.0|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=29;_ThreadName=pool-16-thread-1;|Exception
while processing config bean changes :
java.lang.IllegalArgumentException: addChild: Child name 'server' is not unique
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:922)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:912)
at org.apache.catalina.core.StandardEngine.addChild(StandardEngine.java:359)
at com.sun.enterprise.web.WebContainer.createHost(WebContainer.java:1180)
at
com.sun.enterprise.web.reconfig.WebConfigListener$1.changed(WebConfigListener.java:122)
at org.jvnet.hk2.config.ConfigSupport.sortAndDispatch(ConfigSupport.java:271)
at
com.sun.enterprise.web.reconfig.WebConfigListener.changed(WebConfigListener.java:113)
at
org.jvnet.hk2.config.Transactions$ConfigListenerJob.process(Transactions.java:365)
at
org.jvnet.hk2.config.Transactions$ConfigListenerJob.process(Transactions.java:355)
at
org.jvnet.hk2.config.Transactions$ConfigListenerNotifier$1$1.call(Transactions.java:248)
at
org.jvnet.hk2.config.Transactions$ConfigListenerNotifier$1$1.call(Transactions.java:246)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:637)

#]

[#|2009-12-07T11:01:37.038-0800|SEVERE|glassfishv3.0|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=29;_ThreadName=Thread-1;|Exception
while processing config bean changes :
java.lang.IllegalArgumentException: addChild: Child name 'server' is not unique
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:922)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:912)
at org.apache.catalina.core.StandardEngine.addChild(StandardEngine.java:359)
at com.sun.enterprise.web.WebContainer.createHost(WebContainer.java:1180)
at
com.sun.enterprise.web.reconfig.WebConfigListener$1.changed(WebConfigListener.java:122)
at org.jvnet.hk2.config.ConfigSupport.sortAndDispatch(ConfigSupport.java:271)
at
com.sun.enterprise.web.reconfig.WebConfigListener.changed(WebConfigListener.java:113)
at
org.jvnet.hk2.config.Transactions$ConfigListenerJob.process(Transactions.java:365)
at
org.jvnet.hk2.config.Transactions$ConfigListenerJob.process(Transactions.java:355)
at
org.jvnet.hk2.config.Transactions$ConfigListenerNotifier$1$1.call(Transactions.java:248)
at
org.jvnet.hk2.config.Transactions$ConfigListenerNotifier$1$1.call(Transactions.java:246)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:637)

#]
Comment by Anissa Lam [ 07/Dec/09 ]

exactly.
AMXConfigProxy child = amx.createChild(childType, attrs);
doesn't give me any exception, child is returned as null which isn't what
normally happen, and GUI doesn't expect that and throws NPE.

But why is this entry get created in domain.xml ?
<virtual-server id="server" />

Comment by llc [ 07/Dec/09 ]

There is a longstanding bug in HK2 that allows creation of more than one element having the same key
value. So this bug is probably a duplicate.

AMX passes things through. HK2 will create the conflicting element, but then of course AMX cannot
register an MBean for it because of a name conflict.

I'd have to look at the code to see why 'null' comes back. It's a tricky asynchronous process so that might
have something to do with it.

Comment by llc [ 07/Dec/09 ]

This issue might be related, probably good to look at it in context.

https://glassfish.dev.java.net/issues/show_bug.cgi?id=9150

Comment by ne110415 [ 07/Dec/09 ]

9150 is a camel case conversion issue. I doubt it can be related to this.

We have two issues to handle:
1. null coming out of addChild() instead of the right exception that AMX throws.
(11c is looking into this)
2. An element seems to get added to domain.xml inspite of a config exception.(I
am looking into this)

Comment by llc [ 07/Dec/09 ]

DEFINITELY a problem here.

I've added two tests to QuickLook (via AMX): one for <property> and one for <virtual-server>. Both fail.

[testng] java.lang.AssertionError
[testng] at amxtest.AMXConfigProxyTests.duplicateVirtualServerTest(AMXConfigProxyTests.java:609)
[testng] ... Removed 22 stack frames
[testng] FAILED: duplicatePropertyTest
[testng] java.lang.AssertionError: More than one property with the same name can be created!
[testng] at amxtest.AMXConfigProxyTests.duplicatePropertyTest(AMXConfigProxyTests.java:568)
[testng] ... Removed 22 stack frames

Comment by llc [ 07/Dec/09 ]

To clarify: while the tests I added in the AMX test suite, the culprit is HK2, which allows the conflicting
elements to be created.

Comment by llc [ 07/Dec/09 ]

fixed spelling error in summary

Comment by Gail Risdal [ 08/Dec/09 ]

Does this issue need to be documented in the GF v3 release notes? If so, what
needs to be said about it (concise description and workaround).

Comment by Nazrul [ 15/May/10 ]

-> Tom

Comment by Tom Mueller [ 02/Jul/10 ]

In 3.1, an attempt to create a duplicate virtual server via asadmin fails with a
proper error message:

$ glassfishv3/bin/asadmin create-virtual-server --hosts localhost server
remote failure: Virtual Server named server already exists.

Command create-virtual-server failed.

So the problem with this issue is really with how AMX returns the error. The
configuration infrastructure is working properly. Changing the category to AMX.

Since the consle is using rest rather than AMX for 3.1, lowering the priority of
is issue.

Comment by prasads [ 07/Oct/10 ]

Excluding these issues from v3.1

Comment by Tom Mueller [ 06/Mar/12 ]

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





[GLASSFISH-10093] Warning: IllegalArgumentException: "timers" / OldTypesBase.oldObjectNameToJ2EEType Created: 08/Oct/09  Updated: 20/Feb/11

Status: Open
Project: glassfish
Component/s: amx
Affects Version/s: 9.1peur2
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: hegalor Assignee: naman_mehta
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 10,093
Status Whiteboard:

V2.1.1_exclude


 Description   

According to:

GlassFish log every startup and deploy:

[#|2008-10-10T13:45:33.511+0200|WARNING|sun-appserver9.1|javax.enterprise.system.tools.admin|_ThreadID=16;_ThreadName=Thread-17;_RequestID=f3d46049-f163-4b65-b286-617e104cefcd;|java.lang.IllegalArgumentException:
"timers"
com.sun.enterprise.management.support.OldTypesBase.oldObjectNameToJ2EEType(OldTypesBase.java:153)
com.sun.enterprise.management.support.oldconfig.OldProps.<init>(OldProps.java:187)
com.sun.enterprise.management.support.LoaderOfOldMonitor.oldToNewObjectName(LoaderOfOldMonitor.java:265)
com.sun.enterprise.management.support.LoaderOfOld.syncWithOld(LoaderOfOld.java:415)
com.sun.enterprise.management.support.Loader._sync(Loader.java:548)
com.sun.enterprise.management.support.Loader.sync(Loader.java:522)
com.sun.enterprise.management.support.Loader.handleMBeanRegistered(Loader.java:209)
com.sun.enterprise.management.support.LoaderRegThread.processRegistration(LoaderRegThread.java:204)
com.sun.enterprise.management.support.LoaderRegThread.process(LoaderRegThread.java:253)
com.sun.enterprise.management.support.LoaderRegThread.run(LoaderRegThread.java:154)

#]

Is there any thing very bad, or is this only a wrong logging?



 Comments   
Comment by hegalor [ 08/Oct/09 ]
      • Issue 10093 has been confirmed by votes. ***
Comment by marina vatkina [ 08/Oct/09 ]

-> AMX

Comment by llc [ 08/Oct/09 ]

This is not relevant to V3, and never will be.

The message indicates that there is a configuration element which is not represented as an MBean.

It can safely be ignored.

Comment by jagadesh [ 15/Oct/09 ]

Will not be fixed for V2.1.1

Comment by Tom Mueller [ 23/Jun/10 ]

Lloyd no longer on project.

Comment by prasads [ 20/Feb/11 ]

Assigning issues to Naman





[GLASSFISH-12796] Problem reading AMX beans after Glassfish restart Created: 26/Jul/10  Updated: 17/Jun/13

Status: Open
Project: glassfish
Component/s: amx
Affects Version/s: 3.1
Fix Version/s: not determined

Type: Bug Priority: Minor
Reporter: snobbles1 Assignee: Peter Bower
Resolution: Unresolved Votes: 5
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Zip Archive Issue12796.zip    
Issuezilla Id: 12,796

 Description   

I'm accessing the jdbc resources in Glassfish via the AMX JMX beans, but I've
having problems on a Glassfish restart
If my war is deployed, and Glassfish is restarted, the war fails to deploy on
the Glassfish restart - this is due to the bean amx:pp=/domain,type=resources
not being present.
The AMX service is only started if its required (eg if the admin console is
loaded)
I've tried manually starting the AMX service from my war:
I've tried calling the method new
AMXGlassfish(AMXGlassfish.DEFAULT_JMX_DOMAIN).bootAMX() from my war, but on
restarting glassfish, the call to bootAMX() hangs indefinitely
I've also tried connecting to the AMX JMX bean with the URL
service:jmx:rmi://<local host>:8686/jndi/rmi://<local host>:8686/jmxrmi
This works if I'm deploying after Glassfish has been started, and the admin
console hasn't been loaded.
If the war is deployed, and Glassfish is restarted, this fails as Glassfish
cannot connect to the RMI JMX service.
From looking at glassfish logs, the start up sequence seems to be that Glassfish
does not launch JMX until after all existing war files have been deployed.
Version of glassfish: v3



 Comments   
Comment by prasads [ 07/Oct/10 ]

Can you please let me know the following details :

1. How does one reproduce this issue ?
2. Can you attach a sample war ?

The reason I am a bit confused is because if a application refers to a JDBC
resource, it should not need AMX to load these MBeans on a restart. The
resources should be loaded on a restart and create the required MBeans which
then would be available via AMX.

Comment by sanandal [ 08/Oct/10 ]

...

Comment by prasads [ 02/Dec/10 ]

I am downgrading this issue as I have not heard more about this issue.

Comment by prasads [ 20/Feb/11 ]

Assigning issues to Naman

Comment by sennen [ 31/Mar/11 ]

We have the same problem - and it's a bit of a show-stopper for us in trying to support both GlassFish 2.1 and 3.1.

In our case, we want to query the "amx:" tree to determine GlassFish version and then use appropriate JMX object path names and code to manipulate file-realm users, in support of a Web Service. We do this in a servlet context listener (i.e. prior to the first use of the Web Service after deployment or appserver restart).

I attach the file issue12796.zip which contains a Maven web application project created under Netbeans 6.9.1. It is a do-nothing servlet, with all the interesting stuff in the servlet context listener (MyContextListener.java). Source is included, and you will find a .war file in the "target" directory.

To repeat the problem, load the .war file into a running GlassFish 3.1 server, the log should show:

INFO: MyContextListener: constructor
INFO: MyContextListener: contextInitialized
INFO: MyContextListener: start AMX
INFO: Initialized AMXStartupServiceNew in 14 ms, registered as amx-support:type=amx-loader,name=startup
INFO: In the registerChildren of MonitoringRootImpl instance Name = server
INFO: AMX ComplianceMonitor: ValidationLevel = full, UnregisterNonCompliant = false, LogInaccessibleAttributes = true
INFO: In AMXConfigLoader : loader == null
INFO: AMX config read, domain config registered as amx:pp=/,type=domain
INFO: J2EEDomain registered at amx:pp=/,type=J2EEDomain,j2eeType=J2EEDomain,name=amx
INFO: AMXStartupServiceNew: AMX ready for use, DomainRoot = amx:pp=,type=domain-root
INFO: MyContextListener: AMX started
INFO: MyContextListener: version=Glassfish V3.1
INFO: MyContextListener: users=[user1,user2,user3]
INFO: WEB0671: Loading application [Issue12796] at [/Issue12796]
INFO: Issue12796 was successfully deployed in 1,395 milliseconds.

However, if you then restart the GlassFish application server:

INFO: MyContextListener: constructor
INFO: MyContextListener: contextInitialized
INFO: MyContextListener: start AMX
SEVERE: MyContextListener: context initialization failed
javax.management.InstanceNotFoundException: amx-support:type=boot-amx
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getMBean(DefaultMBeanServerInterceptor.java:1094)
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:833)
at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:761)
at com.sun.enterprise.v3.admin.DynamicInterceptor.invoke(DynamicInterceptor.java:387)
at webapp.issue12796.MyContextListener.contextInitialized(MyContextListener.java:25)
at org.apache.catalina.core.StandardContext.contextListenerStart(StandardContext.java:4690)
at com.sun.enterprise.web.WebModule.contextListenerStart(WebModule.java:534)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:5305)
at com.sun.enterprise.web.WebModule.start(WebModule.java:500)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:917)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:901)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:755)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1980)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1630)
at com.sun.enterprise.web.WebApplication.start(WebApplication.java:100)
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:286)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:461)
at com.sun.enterprise.v3.server.ApplicationLoaderService.processApplication(ApplicationLoaderService.java:364)
at com.sun.enterprise.v3.server.ApplicationLoaderService.postConstruct(ApplicationLoaderService.java:208)
at com.sun.hk2.component.AbstractCreatorImpl.inject(AbstractCreatorImpl.java:131)
at com.sun.hk2.component.ConstructorCreator.initialize(ConstructorCreator.java:91)
at com.sun.hk2.component.AbstractCreatorImpl.get(AbstractCreatorImpl.java:82)
at com.sun.hk2.component.SingletonInhabitant.get(SingletonInhabitant.java:67)
at com.sun.hk2.component.EventPublishingInhabitant.get(EventPublishingInhabitant.java:139)
at com.sun.hk2.component.AbstractInhabitantImpl.get(AbstractInhabitantImpl.java:76)
at com.sun.enterprise.v3.server.AppServerStartup.run(AppServerStartup.java:243)
at com.sun.enterprise.v3.server.AppServerStartup.start(AppServerStartup.java:135)
at com.sun.enterprise.glassfish.bootstrap.GlassFishImpl.start(GlassFishImpl.java:79)
at com.sun.enterprise.glassfish.bootstrap.GlassFishMain$Launcher.launch(GlassFishMain.java:117)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.enterprise.glassfish.bootstrap.GlassFishMain.main(GlassFishMain.java:97)
at com.sun.enterprise.glassfish.bootstrap.ASMain.main(ASMain.java:55)

INFO: WEB0671: Loading application [Issue12796] at [/Issue12796]
INFO: CORE10010: Loading application Issue12796 done in 2,790 ms
INFO: GlassFish Server Open Source Edition 3.1 (43) startup time : Felix (1,866ms), startup services(3,530ms), total(5,396ms)
INFO: JMXStartupService: Started JMXConnector, JMXService URL = service:jmx:rmi://mypc.mydomain.org:8686/jndi/rmi://mypc.mydomain.org:8686/jmxrmi

Ideally, we'd want the "amx:" business ready and waiting for us at servlet context initialisation time.
Even better: we'd also prefer not to have to boot AMX ourselves - can it be set to start in configuration, in an end-user-friendly manner?

Comment by sennen [ 31/Mar/11 ]

Attachment as per my previous comment.

Comment by zlj [ 14/Dec/11 ]

I face nearly the same issue on GF 3.1.1.

When I do not "boot" AMX manually, I can't request any AMX/MBean attributes for my web-applications. "boot" means executing bootAMX() in MBean "amx-support:type=boot-amx".

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 Wasomumba [ 15/Jun/13 ]

The comments in this ticket address different issues. I'm talking about the problem, that the AMX Service is not available at startup, as described by sennen above.

This is caused by the fact, that the amx service is started AFTER startup of the server.

To fix this issue, i think the runlevel from "org.glassfish.admin.mbeanserver.JMXStartupService" and "org.glassfish.admin.mbeanserver.MBeanServerFactory" should be changed from "PostStartupRunLevel" to "InitRunLevel".

What do you think?

Comment by naman_mehta [ 17/Jun/13 ]

hi peter,

Assigning this issue to you. Let me know if you need any details from my side.

Naman





[GLASSFISH-7089] Hierarchical Custom MBeans Created: 26/Jan/09  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: amx
Affects Version/s: 9.0pe
Fix Version/s: not determined

Type: Bug Priority: Minor
Reporter: jmenendez Assignee: naman_mehta
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 7,089
Status Whiteboard:

v2.1.1_exclude


 Description   

Provide a way to register a Custom MBean so it shows in a hierarchical layout in
the glassfish admin console.

For example if ObjetName is "user/agents:type=impl.Agent,name=agent1" it should
show a mbean call agent1 in a subtree called "agents" under "Custom MBeans"



 Comments   
Comment by Ed Bratt [ 15/Oct/09 ]

Will not fix in v2.1.1

Comment by Tom Mueller [ 23/Jun/10 ]

Lloyd no longer on project.

Comment by prasads [ 20/Feb/11 ]

Assigning issues to Naman

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.





[GLASSFISH-4093] incorrect state after stopping modules through AMX Created: 06/Feb/08  Updated: 20/Feb/11

Status: Open
Project: glassfish
Component/s: amx
Affects Version/s: v2.1
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: ocorbun Assignee: naman_mehta
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Linux
Platform: Linux


Issuezilla Id: 4,093
Status Whiteboard:

as911-na


 Description   

Stopping a web module through AMX ends up in an incorrect state in its JSR77 MBean.

To reproduce the problem:

  • deploy a web module
  • look for the web nodule with AMX and get a J2EEDeployedObject.
  • invoke stop() on the J2EEDeployedObject that is in the STATE_RUNNING
    (1) state.
  • the web module is stopped and not available anymore in my browser
  • look again for the web module via AMX and check the state
  • the web module is in the STATE_STARTING (0) state !!!
  • after that you may invoke start() via AMX, the web module is restarted
    and gets STATE_RUNNING again.

Looks like it is a binary (0/1) state machine instead of following the states
described in StateManageable.



 Comments   
Comment by llc [ 11/Feb/08 ]

The request for attribute 'state' is passed through to the com.sun.appserv MBean, so this is a bug at
that level.

The logic in stop() looks correct, it's hard to see how the module could be in STATE_STARTING.

try

{ this.state = this.STOPPING_STATE; this.stateChanged("j2ee.state.stopping"); module.stop(this); this.state = this.STOPPED_STATE; this.stateChanged("j2ee.state.stopped"); }

catch(Exception ex)

{ this.state = this.FAILED_STATE; this.stateChanged("j2ee.state.failed"); if(ex instanceof RuntimeException) throw (RuntimeException)ex; throw new RuntimeException(ex); }

Furthermore, if the module is started in STATE_STARTING, an exception should be thrown:
public void start() {

if ((this.state == this.STARTING_STATE) ||
(this.state == this.RUNNING_STATE) ||
(this.state == this.STOPPING_STATE))

{ throw new RuntimeException( new Exception ("cannot start because the current state is " + this.state)); }

So none of this makes any sense at all; it's "impossible".

This would have to be debugged to understand what's going on.

Comment by llc [ 11/Feb/08 ]

Whlle the logic looks OK, the code is not thread safe; variable 'state' is not protected by anything. Still, it
seems highly unlikely to the the issue given typical write-through processor caches. To fix the thread
safety issue (but possibly not the bug), change the variable to:

private volatile int state = this.RUNNING_STATE;

However, there is also a setstate() method. I suspect that the problem is caused by an "external force"
which is whacking the 'state' variable to the wrong value, since the logic inside J2EEDeployedObjectMdl
seems OK.

Comment by harpreet [ 16/Apr/08 ]

assigning to Sreenivas for further investigation.

Comment by msreddy [ 16/Apr/08 ]

Based on jsr77, user is allowed to do such operations only when the
state-management attribute is set to true, in our case that is false.

Comment by harpreet [ 16/Apr/08 ]

Marking for next release

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 [ 10/Feb/11 ]

It appears that a web module cannot even be stopped via JMX in 3.1.
When the operation is tried via jconsole, you get a InvocationTargetException

Comment by prasads [ 20/Feb/11 ]

Assigning issues to Naman





[GLASSFISH-3894] fix AMX unit test failure: ProfilerConfig Created: 03/Dec/07  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: amx
Affects Version/s: v2.1
Fix Version/s: not determined

Type: Bug Priority: Minor
Reporter: llc Assignee: naman_mehta
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Macintosh


Issuezilla Id: 3,894
Status Whiteboard:

as91ur1-na


 Description   

Investigate why a ProfilerConfig cannot be removed during the unit tests runs.

[java] [java] *** testing com.sun.enterprise.management.config.ProfilerConfigTest ***
[java] [java] .E.
[java] [java] Time: 0.026
[java] [java] There was 1 error:
[java] [java] 1)
testCreateRemoveProfiler(com.sun.enterprise.management.config.ProfilerConfigTest)java.lang.Assertion
Error: Can't remove ProfilerConfig from amx:j2eeType=X-JavaConfig,name=na,X-
ConfigConfig=server-config
[java] [java] at
com.sun.enterprise.management.config.ProfilerConfigTest.testCreateRemoveProfiler(ProfilerConfigTest.
java:123)
[java] [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[java] [java] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[java] [java] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[java] [java] at com.sun.enterprise.management.TestRunner.runSuite(TestRunner.java:103)
[java] [java] at com.sun.enterprise.management.TestRunner.testClass(TestRunner.java:112)
[java] [java] at com.sun.enterprise.management.TestRunner.runTests(TestRunner.java:131)
[java] [java] at com.sun.enterprise.management.TestRunner.runAll(TestRunner.java:333)
[java] [java] at com.sun.enterprise.management.TestMain.iterateTests(TestMain.java:925)
[java] [java] at com.sun.enterprise.management.TestMain.<init>(TestMain.java:887)
[java] [java] at com.sun.enterprise.management.TestMain.main(TestMain.java:220)



 Comments   
Comment by llc [ 03/Dec/07 ]

This is one of several fixed to yield a clean AMX unit test run.

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 [ 23/Jun/10 ]

Lloyd no longer on project.

Comment by prasads [ 20/Feb/11 ]

Assigning issues to Naman

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.





[GLASSFISH-3893] fix AMX unit test failure: BeeanPoolMonitors missing Container MBean Created: 03/Dec/07  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: amx
Affects Version/s: v2.1
Fix Version/s: not determined

Type: Bug Priority: Minor
Reporter: llc Assignee: naman_mehta
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Macintosh


Issuezilla Id: 3,893
Status Whiteboard:

as91ur1-na


 Description   

Some xxx are missing their Container MBeans during the AMX unit test run. Investigate and determine
if this is a time/transition problem or a real issue with missing MBeans.

      • testing com.sun.enterprise.management.base.AMXTest ***
        .checkContainerObjectName failed for: "amx:j2eeType=X-BeanPoolMonitor,name=bean-pool,X-
        ApplicationMonitor=InboundMessageApp,X-EJBModuleMonitor=mailconnectorEjb.jar,X-
        MessageDrivenBeanMonitor=JavaMailMDB,X-ServerRootMonitor=server" with Exception of type
        javax.management.AttributeNotFoundException, msg = Attribute not found: "ContainerObjectName"
        [amx:j2eeType=X-MessageDrivenBeanMonitor,name=JavaMailMDB,X-
        EJBModuleMonitor=mailconnectorEjb.jar,X-ServerRootMonitor=server,X-
        ApplicationMonitor=InboundMessageApp,*]
        [java] [java] checkContainerObjectName failed for: "amx:j2eeType=X-
        BeanPoolMonitor,name=bean-pool,X-ApplicationMonitor=SimpleMessageApp,X-
        EJBModuleMonitor=mdb-simpleEjb.jar,X-MessageDrivenBeanMonitor=SimpleMessageEJB,X-
        ServerRootMonitor=server" with Exception of type javax.management.AttributeNotFoundException, msg
        = Attribute not found: "ContainerObjectName" [amx:j2eeType=X-
        MessageDrivenBeanMonitor,name=SimpleMessageEJB,X-EJBModuleMonitor=mdb-simpleEjb.jar,X-
        ServerRootMonitor=server,X-ApplicationMonitor=SimpleMessageApp,*]
        [java] [java] E.....Can't get container for: amx:name=bean-pool,X-
        EJBModuleMonitor=mailconnectorEjb.jar,X-ApplicationMonitor=InboundMessageApp,X-
        ServerRootMonitor=server,j2eeType=X-BeanPoolMonitor,X-MessageDrivenBeanMonitor=JavaMailMDB


 Comments   
Comment by llc [ 03/Dec/07 ]

This is one of several bugs that fixing will allow a clean AMX unit test run.

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 [ 23/Jun/10 ]

Lloyd no longer on project.

Comment by prasads [ 20/Feb/11 ]

Assigning issues to Naman

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.





[GLASSFISH-3892] fix AMX unit test failure: WebModuleVirtualServerMonitor statistics Created: 03/Dec/07  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: amx
Affects Version/s: v2.1
Fix Version/s: not determined

Type: Bug Priority: Minor
Reporter: llc Assignee: naman_mehta
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Macintosh


Issuezilla Id: 3,892
Status Whiteboard:

as91ur1-na


 Description   

Failure is caused by underlying com.sun.appserv MBeans, fix needs to be done there.

WebModuleVirtualServerMonitor

..checkStatsClassSuppliesAllStatistics failed for: "amx:j2eeType=X-
WebModuleVirtualServerMonitor,name=//server/,X-ApplicationMonitor=null,X-
ServerRootMonitor=server" with Exception of type java.lang.AssertionError, msg = Statistic names for
"amx:j2eeType=X-WebModuleVirtualServerMonitor,name=//server/,X-ApplicationMonitor=null,X-
ServerRootMonitor=server" obtained via Statistic names do not match those obtained via introspection:



 Comments   
Comment by llc [ 03/Dec/07 ]

This is one of several fixes designed to allow a zero-error run of the AMX unit tests.

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 [ 23/Jun/10 ]

Lloyd no longer on project.

Comment by prasads [ 20/Feb/11 ]

Assigning issues to Naman

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.





[GLASSFISH-4518] Exceptions in server.log - dotted property names Created: 27/Mar/08  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: amx
Affects Version/s: 9.1peur1
Fix Version/s: not determined

Type: Bug Priority: Minor
Reporter: gopalan Assignee: naman_mehta
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 4,518
Status Whiteboard:

v3_exclude, v2.1.1_exclude

Tags: 3_1-exclude

 Description   

Lloyd L Chambers wrote:
> One theory (without looking at the parsing code): Properties with a "." in
them might not work (eg "com.sun.caps.domain.name"); they cannot be parsed
because the "." is the delimiter for dotted names themeselves.
>
> However, there is another similar problem I've seen with dotted names, so it
might not be a parsing problem.
>
> You can file a bug on this. Perhaps for V3 there can be a fix. For V2 it's
something that could be prioritized.
>
> Lloyd
>
> On Mar 26, 2008, at 7:40 PM, Gopalan Suresh Raj wrote:
>> I work in the SOA/BI division on the Java CAPS product.
>>
>> We take GlassFish and add Java CAPS, AM, and other Sun products on top of it
to create the Java CAPS product.
>>
>> When we install the product, and start the App Server, we get the following
exceptions in the server.log.
>>
>> On examining these, I am guessing these exceptions are being thrown from
either AMX or CLI. All of these are related to MBeans registered on the
com.sun.appserv domain. If you look at the MBeans in question, they are all
coming from MBeans that have a getProperties() operation with the keys that
either AMX or CLI is complaining about (I am guessing it is AMX or CLI since
they all happen with MBeans registered on the com.sun.appserv domain, and are
logged from javax.enterprise.system.tools.admin during application server
startup). These are logged on each and every startup of the GlassFish App Server.
>>
>> Can you advise on why this is happening, and what could be done to get rid of
these exceptions?
>>
>> Cheers
>> Gopalan.
>>
>>
>>
>>
[#|2008-03-26T17:09:40.897-0700|INFO|sun-appserver9.1|javax.enterprise.system.tools.admin|_ThreadID=20;_ThreadName=RMI
TCP Connection(6)-129.153.167.46;|javax.management.InstanceNotFoundException: No
object matches the specified name
"server.security-service.message-security-config.SOAP.provider-config.XWS_ClientProvider.property.signature.key.alias"|#]
>>
>>
[#|2008-03-26T17:09:40.913-0700|INFO|sun-appserver9.1|javax.enterprise.system.tools.admin|_ThreadID=20;_ThreadName=RMI
TCP Connection(6)-129.153.167.46;|javax.management.InstanceNotFoundException: No
object matches the specified name
"domain.applications.lifecycle-module.JBIFramework.property.com.sun.jbi.home"|#]
>>
>>
[#|2008-03-26T17:09:40.929-0700|INFO|sun-appserver9.1|javax.enterprise.system.tools.admin|_ThreadID=20;_ThreadName=RMI
TCP Connection(6)-129.153.167.46;|javax.management.InstanceNotFoundException: No
object matches the specified name
"server.security-service.message-security-config.SOAP.provider-config.XWS_ServerProvider.property.encryption.key.alias"|#]
>>
>>
[#|2008-03-26T17:09:40.944-0700|INFO|sun-appserver9.1|javax.enterprise.system.tools.admin|_ThreadID=20;_ThreadName=RMI
TCP Connection(6)-129.153.167.46;|javax.management.InstanceNotFoundException: No
object matches the specified name
"server.applications.lifecycle-module.domain1stcms1.property.com.sun.caps.domain.name"|#]
>>
>>
[#|2008-03-26T17:09:40.944-0700|INFO|sun-appserver9.1|javax.enterprise.system.tools.admin|_ThreadID=20;_ThreadName=RMI
TCP Connection(6)-129.153.167.46;|javax.management.InstanceNotFoundException: No
object matches the specified name
"server.security-service.message-security-config.SOAP.provider-config.ClientProvider.property.security.config"|#]
>>
>>
[#|2008-03-26T17:09:40.960-0700|INFO|sun-appserver9.1|javax.enterprise.system.tools.admin|_ThreadID=20;_ThreadName=RMI
TCP Connection(6)-129.153.167.46;|javax.management.InstanceNotFoundException: No
object matches the specified name
"server.security-service.message-security-config.SOAP.provider-config.ClientProvider.property.encryption.key.alias"|#]
>>
>>
[#|2008-03-26T17:09:40.960-0700|INFO|sun-appserver9.1|javax.enterprise.system.tools.admin|_ThreadID=20;_ThreadName=RMI
TCP Connection(6)-129.153.167.46;|javax.management.InstanceNotFoundException: No
object matches the specified name
"server.security-service.message-security-config.SOAP.provider-config.ServerProvider.property.security.config"|#]
>>
>>
[#|2008-03-26T17:09:40.975-0700|INFO|sun-appserver9.1|javax.enterprise.system.tools.admin|_ThreadID=20;_ThreadName=RMI
TCP Connection(6)-129.153.167.46;|javax.management.InstanceNotFoundException: No
object matches the specified name
"server.applications.lifecycle-module.JBIFramework.property.com.sun.jbi.home"|#]
>>
>>
[#|2008-03-26T17:09:40.991-0700|INFO|sun-appserver9.1|javax.enterprise.system.tools.admin|_ThreadID=20;_ThreadName=RMI
TCP Connection(6)-129.153.167.46;|javax.management.InstanceNotFoundException: No
object matches the specified name
"server.security-service.message-security-config.SOAP.provider-config.ClientProvider.property.dynamic.username.password"|#]
>>
>>
[#|2008-03-26T17:09:41.054-0700|INFO|sun-appserver9.1|javax.enterprise.system.tools.admin|_ThreadID=20;_ThreadName=RMI
TCP Connection(6)-129.153.167.46;|javax.management.InstanceNotFoundException: No
object matches the specified name
"server.applications.lifecycle-module.domain1stcms1.property.com.sun.caps.jms.name"|#]
>>
>>
[#|2008-03-26T17:09:41.054-0700|INFO|sun-appserver9.1|javax.enterprise.system.tools.admin|_ThreadID=20;_ThreadName=RMI
TCP Connection(6)-129.153.167.46;|javax.management.InstanceNotFoundException: No
object matches the specified name
"domain.applications.lifecycle-module.domain1stcms1.property.com.sun.caps.jms.sslport"|#]
>>
>>
[#|2008-03-26T17:09:41.054-0700|INFO|sun-appserver9.1|javax.enterprise.system.tools.admin|_ThreadID=20;_ThreadName=RMI
TCP Connection(6)-129.153.167.46;|javax.management.InstanceNotFoundException: No
object matches the specified name
"server.security-service.message-security-config.SOAP.provider-config.ServerProvider.property.signature.key.alias"|#]
>>
>>
[#|2008-03-26T17:09:41.069-0700|INFO|sun-appserver9.1|javax.enterprise.system.tools.admin|_ThreadID=20;_ThreadName=RMI
TCP Connection(6)-129.153.167.46;|javax.management.InstanceNotFoundException: No
object matches the specified name
"domain.applications.lifecycle-module.domain1stcms1.property.com.sun.caps.jms.name"|#]
>>
>>
[#|2008-03-26T17:09:41.069-0700|INFO|sun-appserver9.1|javax.enterprise.system.tools.admin|_ThreadID=20;_ThreadName=RMI
TCP Connection(6)-129.153.167.46;|javax.management.InstanceNotFoundException: No
object matches the specified name
"server.security-service.message-security-config.SOAP.provider-config.XWS_ClientProvider.property.dynamic.username.password"|#]
>>
>>
[#|2008-03-26T17:09:41.069-0700|INFO|sun-appserver9.1|javax.enterprise.system.tools.admin|_ThreadID=20;_ThreadName=RMI
TCP Connection(6)-129.153.167.46;|javax.management.InstanceNotFoundException: No
object matches the specified name
"domain.applications.lifecycle-module.domain1stcms1.property.com.sun.caps.jms.port"|#]
>>
>>
[#|2008-03-26T17:09:41.069-0700|INFO|sun-appserver9.1|javax.enterprise.system.tools.admin|_ThreadID=20;_ThreadName=RMI
TCP Connection(6)-129.153.167.46;|javax.management.InstanceNotFoundException: No
object matches the specified name
"domain.applications.lifecycle-module.domain1stcms1.property.com.sun.caps.domain.name"|#]
>>
>>
[#|2008-03-26T17:09:41.069-0700|INFO|sun-appserver9.1|javax.enterprise.system.tools.admin|_ThreadID=20;_ThreadName=RMI
TCP Connection(6)-129.153.167.46;|javax.management.InstanceNotFoundException: No
object matches the specified name
"server.security-service.message-security-config.SOAP.provider-config.XWS_ClientProvider.property.encryption.key.alias"|#]
>>
>>
[#|2008-03-26T17:09:41.069-0700|INFO|sun-appserver9.1|javax.enterprise.system.tools.admin|_ThreadID=20;_ThreadName=RMI
TCP Connection(6)-129.153.167.46;|javax.management.InstanceNotFoundException: No
object matches the specified name
"server.security-service.message-security-config.SOAP.provider-config.ClientProvider.property.signature.key.alias"|#]
>>
>>
[#|2008-03-26T17:09:41.085-0700|INFO|sun-appserver9.1|javax.enterprise.system.tools.admin|_ThreadID=20;_ThreadName=RMI
TCP Connection(6)-129.153.167.46;|javax.management.InstanceNotFoundException: No
object matches the specified name
"server.security-service.message-security-config.SOAP.provider-config.ServerProvider.property.encryption.key.alias"|#]
>>
>>
[#|2008-03-26T17:09:41.085-0700|INFO|sun-appserver9.1|javax.enterprise.system.tools.admin|_ThreadID=20;_ThreadName=RMI
TCP Connection(6)-129.153.167.46;|javax.management.InstanceNotFoundException: No
object matches the specified name
"server.applications.lifecycle-module.domain1stcms1.property.com.sun.caps.jms.sslport"|#]
>>
>>
[#|2008-03-26T17:09:41.085-0700|INFO|sun-appserver9.1|javax.enterprise.system.tools.admin|_ThreadID=20;_ThreadName=RMI
TCP Connection(6)-129.153.167.46;|javax.management.InstanceNotFoundException: No
object matches the specified name
"server.applications.lifecycle-module.domain1stcms1.property.com.sun.caps.jms.port"|#]
>>
>>
[#|2008-03-26T17:09:41.100-0700|INFO|sun-appserver9.1|javax.enterprise.system.tools.admin|_ThreadID=20;_ThreadName=RMI
TCP Connection(6)-129.153.167.46;|javax.management.InstanceNotFoundException: No
object matches the specified name
"server.security-service.message-security-config.SOAP.provider-config.XWS_ServerProvider.property.signature.key.alias"|#]
>>
>>
[#|2008-03-26T17:10:20.641-0700|INFO|sun-appserver9.1|com.sun.jbi.framework|_ThreadID=21;_ThreadName=httpWorkerThread-4848-1;|JBIFW0012:
JBI framework startup complete.|#]
>>
>>
[#|2008-03-26T17:10:21.344-0700|INFO|sun-appserver9.1|javax.enterprise.system.tools.deployment|_ThreadID=18;_ThreadName=Timer-10;|deployed
with moduleid = amserver|#]



 Comments   
Comment by mwhite [ 28/Jul/08 ]

Adding myself to receive notification of activity on this 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 vince kraemer [ 30/Mar/09 ]

this is generating questions from folks in the nbj2ee@netbeans.org...

http://www.netbeans.org/servlets/ReadMsg?list=nbj2ee&msgNo=10442

Since SGES v2.1 has shipped, I guess it is time to raise the priority again...

Comment by vince kraemer [ 15/Apr/09 ]

issue filed in NB issue tracker...
http://www.netbeans.org/issues/show_bug.cgi?id=162762.

Any news about this?

Comment by Alexis MP [ 24/May/09 ]

adding myself to CC list

Comment by vince kraemer [ 27/May/09 ]

closed an issue as a dup of the NB issue cited in
https://glassfish.dev.java.net/issues/show_bug.cgi?id=4518#desc5

Comment by vince kraemer [ 27/May/09 ]

This issue is not closed yet. there was a new issue in the nb tracker, that I
closed as a dup of http://www.netbeans.org/issues/show_bug.cgi?id=162762...

Both these NB issues are really just a manifestation of this issue...

Comment by vince kraemer [ 19/Jun/09 ]

Here is another mention of this...
http://forums.java.net/jive/thread.jspa?messageID=352087

Comment by junqian [ 10/Aug/09 ]

This is an often-reported issue in the NetBeans IssueTracker. See
http://www.netbeans.org/issues/show_bug.cgi?id=146212. There are about 10
duplicates in this ticket.

Adding myself to the CC list.

Comment by kumara [ 01/Sep/09 ]

-> llc

Comment by kumara [ 02/Oct/09 ]

Does not apply to GlassFish v3 and hence excluded from tracking list.

Comment by Ed Bratt [ 15/Oct/09 ]

Will not fix for v2.1.1

Comment by Ed Bratt [ 15/Oct/09 ]

Will not fix in v2.1.1

Comment by Tom Mueller [ 23/Jun/10 ]

Lloyd no longer on project.

Comment by prasads [ 07/Oct/10 ]

Excluding these issues from v3.1

Comment by prasads [ 20/Feb/11 ]

Assigning issues to Naman

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.





[GLASSFISH-970] amx AppserverConnectionSource failures return non published class Created: 18/Aug/06  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: amx
Affects Version/s: 9.0pe
Fix Version/s: not determined

Type: Bug Priority: Minor
Reporter: ludo Assignee: naman_mehta
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 970
Tags: 3_1-exclude

 Description   

If I have a Main program using appsrv-ext.jar for AMX usage, then if I enter a
wrong password in this code:

new AppserverConnectionSource(
AppserverConnectionSource.PROTOCOL_RMI, host, 8686, username,
WRONGpassword, null, null);

then I get an exception showing ClassNotFoundException for
"com.sun.enterprise.security.LoginException"

See:

Aug 15, 2006 5:49:14 PM com.sun.appserv.management.client.ProxyFactory getInstance
SEVERE: ProxyFactory.getInstance: Failure trying to create a new ProxyFactory:
java.lang.ClassNotFoundException: "com.sun.enterprise.security.LoginException
(no security manager: RMI class loader disabled)"
sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:375)
sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:165)
java.rmi.server.RMIClassLoader$2.loadClass(RMIClassLoader.java:620)
java.rmi.server.RMIClassLoader.loadClass(RMIClassLoader.java:247)
sun.rmi.server.MarshalInputStream.resolveClass(MarshalInputStream.java:197)
java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1575)



 Comments   
Comment by km [ 01/Feb/07 ]

This is a bit tricky to fix.

Comment by km [ 28/Mar/07 ]

I am not sure how this can be fixed without making rather massive changes.
For one, I think the security exception class should be an exposed interface.

I accept that it is rather embarrassing, but can't do much.

I tend to make it a P4. Do you agree?

Comment by gfbugbridge [ 05/Apr/07 ]

<BT6543236>

Comment by Tom Mueller [ 23/Jun/10 ]

Kedar no longer on project.

Comment by prasads [ 07/Oct/10 ]

Excluding these issues from v3.1

Comment by prasads [ 20/Feb/11 ]

Assigning issues to Naman

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.





[GLASSFISH-17010] [JMX] Multiple [2] JMX MBeanServer instances exist Created: 11/Jul/11  Updated: 29/Sep/11

Status: Open
Project: glassfish
Component/s: amx, ejb_container
Affects Version/s: 3.1.1_b09
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: ancoron Assignee: prasads
Resolution: Unresolved Votes: 10
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

On a 3.1.1 promoted build I currently get those warnings when the EJBTimer application is starting up:

WARNING: Multiple [2] JMX MBeanServer instances exist, we will use the server at index [0] : [com.sun.enterprise.v3.admin.DynamicInterceptor@43c0ae76].
WARNING: JMX MBeanServer in use: [com.sun.enterprise.v3.admin.DynamicInterceptor@43c0ae76] from index [0] 
WARNING: JMX MBeanServer in use: [com.sun.jmx.mbeanserver.JmxMBeanServer@bbe5d86] from index [1]

It doesn't seem to affect functionality. Therefore lower priority.



 Comments   
Comment by alan94539 [ 14/Aug/11 ]

I agree it is minor, but is there a workaround to make this stop coming up? I suspect there is a configuration parameter somewhere to set which MBeanServer to use but I can't find it.

Comment by anlog [ 29/Sep/11 ]

I have found a workaround to continue: I get the ResultList size before get the element list.

int it = emf.createEntityManager().createNamedQuery("User.findAll").getResultList().size();
String users = "";
for( int i=0; i<it; i++)

{ User user = (User)emf.createEntityManager().createNamedQuery("User.findAll").getResultList().get(i); users += "id: " + user.getId() + " - "; users += "username: " + user.getUsername() + " - "; users += "<br>"; }




[GLASSFISH-21272] JDBC Monitoring MBeans not working in JConsole Created: 16/Dec/14  Updated: 16/Dec/14

Status: Open
Project: glassfish
Component/s: amx
Affects Version/s: 4.1
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: smillidge-c2b2 Assignee: prasads
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Some of the attributes of the jdbc-connection-pool-mon MBean do not show up but instead show as Unavailable due to an Invocation Target Exception.



 Comments   
Comment by smillidge-c2b2 [ 16/Dec/14 ]

Suggested fix is in this Payara commit.

https://github.com/payara/Payara/commit/f6fc06e3a0175c87b76a4f5b3ad4da1f3a076c5d





[GLASSFISH-19602] BootAMX error logged during shutdown, even though shutdown completes Created: 29/Jan/13  Updated: 29/Jan/13

Status: Open
Project: glassfish
Component/s: amx
Affects Version/s: 3.1.2.2
Fix Version/s: future release

Type: Bug Priority: Minor
Reporter: Tim Quinn Assignee: prasads
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to GLASSFISH-18878 AMX errors prevent stopping (and remo... Resolved

 Description   

Sometimes during shutdown the server logs a BootAMX error. I have pasted Luis's comments from his forum posting here, as well as his stack trace.

Hi gentlemen,

We keep finding this exception every time we stop/restart any instance

  • > "AMXStartupServiceNew.loadAMXMBeans:
    java.lang.IllegalStateException: BootAMX listener was not called"

After doing some digging I believe that the instance is properly shut down.
However, there seem to be some other processes happening right after that
which cause the exception.

I have browsed the web finding similar issues with no results. Hence I come
here.

This stack trace is coming from the instance's log file:

[#|2013-01-21T15:37:12.692-0700|INFO|glassfish3.1.2|javax.enterprise.system.tools.admin.com.sun.enterprise.v3.admin.cluster|_ThreadID=47;_ThreadName=Thread-2;|Server
shutdown initiated|#]

[#|2013-01-21T15:37:14.821-0700|INFO|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=47;_ThreadName=Thread-2;|2013-01-21
15:37:14,821 PWAssessment[-1] INFO MessagingDispatcher.java:233
MessagingDispatcher - Shutting down transport LoopbackTransport
|#]

[#|2013-01-21T15:37:14.823-0700|INFO|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=47;_ThreadName=Thread-2;|2013-01-21
15:37:14,823 PWAssessment[-1] INFO MessagingDispatcher.java:233
MessagingDispatcher - Shutting down transport JMSTransport
|#]

[#|2013-01-21T15:37:14.832-0700|INFO|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=47;_ThreadName=Thread-2;|2013-01-21
15:37:14,831 PWAssessment[-1] INFO MessagingDispatcher.java:233
MessagingDispatcher - Shutting down transport HTTPTransport
|#]

[#|2013-01-21T15:37:14.870-0700|INFO|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=47;_ThreadName=Thread-2;|2013-01-21
15:37:14,870 PWBClinician[-1] INFO MessagingDispatcher.java:233
MessagingDispatcher - Shutting down transport LoopbackTransport
|#]

[#|2013-01-21T15:37:14.874-0700|INFO|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=47;_ThreadName=Thread-2;|2013-01-21
15:37:14,874 PWBClinician[-1] INFO MessagingDispatcher.java:233
MessagingDispatcher - Shutting down transport JMSTransport
|#]

[#|2013-01-21T15:37:14.881-0700|INFO|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=47;_ThreadName=Thread-2;|2013-01-21
15:37:14,881 PWBClinician[-1] INFO MessagingDispatcher.java:233
MessagingDispatcher - Shutting down transport HTTPTransport
|#]

[#|2013-01-21T15:37:14.928-0700|INFO|glassfish3.1.2|javax.resourceadapter.mqjmsra.lifecycle|_ThreadID=48;_ThreadName=Thread-2;|MQJMSRA_RA1101:
GlassFish MQ JMS Resource Adapter stopping...|#]

[#|2013-01-21T15:37:14.929-0700|INFO|glassfish3.1.2|javax.resourceadapter.mqjmsra.lifecycle|_ThreadID=48;_ThreadName=Thread-2;|MQJMSRA_RA1101:
GlassFish MQ JMS Resource Adapter stopped.|#]

[#|2013-01-21T15:37:14.929-0700|INFO|glassfish3.1.2|javax.enterprise.resource.resourceadapter.com.sun.enterprise.connectors.service|_ThreadID=49;_ThreadName=Thread-2;|RAR7094:
jmsra shutdown successful.|#]

[#|2013-01-21T15:37:16.722-0700|INFO|glassfish3.1.2|javax.org.glassfish.gms.org.glassfish.gms|_ThreadID=47;_ThreadName=Thread-2;|GMSAD1008:
GMSAdapter for member: APOC-Assessment-n03x01 group: APOC-Assessment
received GlassfishEventType: server_shutdown|#]

[#|2013-01-21T15:37:16.724-0700|INFO|glassfish3.1.2|ShoalLogger|_ThreadID=47;_ThreadName=Thread-2;|GMS1096:
member: APOC-Assessment-n03x01 is leaving group: APOC-Assessment|#]

[#|2013-01-21T15:37:16.725-0700|INFO|glassfish3.1.2|ShoalLogger|_ThreadID=47;_ThreadName=Thread-2;|GMS1010:
Leaving GMS group: APOC-Assessment with shutdown type set to
InstanceShutdown|#]

[#|2013-01-21T15:37:16.729-0700|CONFIG|glassfish3.1.2|ShoalLogger|_ThreadID=50;_ThreadName=Thread-2;|GMS1065:
Completed processing outstanding master node messages for member:
APOC-Assessment-n03x01 group: APOC-Assessment outstandingMessages to
process: 0|#]

[#|2013-01-21T15:37:16.732-0700|INFO|glassfish3.1.2|ShoalLogger.monitor|_ThreadID=47;_ThreadName=Thread-2;|BlockingIOMulicastSender
monitoring stats: received: 30813 core poolsize:10 largest pool size:10
task count:30813 max queue size:0 rejected execution:0|#]

[#|2013-01-21T15:37:16.732-0700|INFO|glassfish3.1.2|ShoalLogger|_ThreadID=51;_ThreadName=Thread-2;|GMS1110:
Thread IP Multicast Listener for /228.9.158.231:13386 has completed.|#]

[#|2013-01-21T15:37:16.894-0700|INFO|glassfish3.1.2|ShoalLogger.monitor|_ThreadID=47;_ThreadName=Thread-2;|GMS1115:
router signal queue high water mark: 0 signal queue capacity: 600|#]

[#|2013-01-21T15:37:16.893-0700|INFO|glassfish3.1.2|ShoalLogger|_ThreadID=52;_ThreadName=Thread-2;|GMS1088:
MessageWindow thread for group: APOC-Assessment terminated due to shutdown
notification|#]

[#|2013-01-21T15:37:16.893-0700|INFO|glassfish3.1.2|ShoalLogger|_ThreadID=12;_ThreadName=Thread-2;|GMS1091:
View Window event processing thread for group: APOC-Assessment terminated
normally|#]

[#|2013-01-21T15:37:16.894-0700|INFO|glassfish3.1.2|ShoalLogger|_ThreadID=53;_ThreadName=Thread-2;|GMS1107:
SignalHandler task named GMS SignalHandler for Group-APOC-Assessment thread
exiting|#]

[#|2013-01-21T15:37:16.987-0700|INFO|glassfish3.1.2|javax.enterprise.system.tools.admin.org.glassfish.server|_ThreadID=47;_ThreadName=Thread-2;|Initialized
AMXStartupServiceNew in 27 ms, registered as
amx-support:type=amx-loader,name=startup|#]

[#|2013-01-21T15:37:17.096-0700|INFO|glassfish3.1.2|javax.enterprise.system.amx.org.glassfish.admin.amx.impl.mbean|_ThreadID=47;_ThreadName=Thread-2;|AMX024:
Register children for instance name APOC-Assessment-n03x01|#]

[#|2013-01-21T15:37:17.110-0700|INFO|glassfish3.1.2|javax.enterprise.system.amx.org.glassfish.admin.amx.impl.mbean|_ThreadID=47;_ThreadName=Thread-2;|AMX020:
AMX ComplianceMonitor: ValidationLevel = full, UnregisterNonCompliant =
false, LogInaccessibleAttributes = true|#]

[#|2013-01-21T15:37:17.147-0700|INFO|glassfish3.1.2|javax.enterprise.system.amx.org.glassfish.admin.amx.impl.config|_ThreadID=54;_ThreadName=Thread-2;|AMX012:
In AMXConfigLoader : Loading null|#]

[#|2013-01-21T15:37:18.089-0700|INFO|glassfish3.1.2|javax.enterprise.system.amx.org.glassfish.admin.amx.impl.config|_ThreadID=54;_ThreadName=Thread-2;|AMX013:
AMX domain config registered as amx:pp=/,type=domain|#]

[#|2013-01-21T15:37:18.346-0700|INFO|glassfish3.1.2|javax.enterprise.system.amx.org.glassfish.admin.amx.impl.j2ee.loader|_ThreadID=55;_ThreadName=Thread-2;|AMX014:
J2EEDomain registered at
amx:pp=/,type=J2EEDomain,j2eeType=J2EEDomain,name=amx|#]

[#|2013-01-21T15:37:18.349-0700|INFO|glassfish3.1.2|javax.enterprise.system.tools.admin.org.glassfish.server|_ThreadID=47;_ThreadName=Thread-2;|AMXStartupServiceNew:
AMX ready for use, DomainRoot = amx:pp=,type=domain-root|#]

[#|2013-01-21T15:37:18.350-0700|INFO|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=47;_ThreadName=Thread-2;|AMXStartupServiceNew.loadAMXMBeans:
java.lang.IllegalStateException: BootAMX listener was not called|#]

[#|2013-01-21T15:37:18.352-0700|WARNING|glassfish3.1.2|javax.enterprise.system.core.org.glassfish.kernel.event|_ThreadID=47;_ThreadName=Thread-2;|Exception
while dispatching an event
javax.management.RuntimeMBeanException: java.lang.RuntimeException:
java.lang.IllegalStateException: BootAMX listener was not called
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.rethrow(DefaultMBeanServerInterceptor.java:856)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.rethrowMaybeMBeanException(DefaultMBeanServerInterceptor.java:869)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:838)
at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:761)
at org.glassfish.admin.mbeanserver.BootAMX.bootAMX(BootAMX.java:163)
at
org.glassfish.admin.mbeanserver.AdminAuthorizedMBeanServer$Handler.amxDomain(AdminAuthorizedMBeanServer.java:154)
at
org.glassfish.admin.mbeanserver.AdminAuthorizedMBeanServer$Handler.isAMX(AdminAuthorizedMBeanServer.java:149)
at
org.glassfish.admin.mbeanserver.AdminAuthorizedMBeanServer$Handler.isAMX(AdminAuthorizedMBeanServer.java:142)
at
org.glassfish.admin.mbeanserver.AdminAuthorizedMBeanServer$Handler.isAllowed(AdminAuthorizedMBeanServer.java:136)
at
org.glassfish.admin.mbeanserver.AdminAuthorizedMBeanServer$Handler.invoke(AdminAuthorizedMBeanServer.java:101)
at $Proxy185.unregisterMBean(Unknown Source)
at
org.glassfish.admin.mbeanserver.JMXStartupService$JMXConnectorsStarterThread.shutdown(JMXStartupService.java:239)
at
org.glassfish.admin.mbeanserver.JMXStartupService.shutdown(JMXStartupService.java:160)
at
org.glassfish.admin.mbeanserver.JMXStartupService.access$000(JMXStartupService.java:94)
at
org.glassfish.admin.mbeanserver.JMXStartupService$ShutdownListener.event(JMXStartupService.java:128)
at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:128)
at
com.sun.enterprise.v3.server.AppServerStartup.stop(AppServerStartup.java:439)
at
com.sun.enterprise.glassfish.bootstrap.GlassFishImpl.stop(GlassFishImpl.java:88)
at
com.sun.enterprise.glassfish.bootstrap.GlassFishDecorator.stop(GlassFishDecorator.java:68)
at com.sun.enterprise.v3.admin.StopServer.doExecute(StopServer.java:70)
at
com.sun.enterprise.v3.admin.cluster.StopInstanceInstanceCommand.execute(StopInstanceInstanceCommand.java:94)
at
com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:348)
at
com.sun.enterprise.v3.admin.CommandRunnerImpl$2.run(CommandRunnerImpl.java:377)
Caused by: java.lang.RuntimeException: java.lang.IllegalStateException:
BootAMX listener was not called
at
org.glassfish.admin.amx.impl.AMXStartupService.loadAMXMBeans(AMXStartupService.java:247)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:93)
at
com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:27)
at
com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:208)
at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:120)
at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:262)
at javax.management.StandardMBean.invoke(StandardMBean.java:391)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:836)
... 20 more
Caused by: java.lang.IllegalStateException: BootAMX listener was not called
at
org.glassfish.admin.amx.impl.AMXStartupService._loadAMXMBeans(AMXStartupService.java:376)
at
org.glassfish.admin.amx.impl.AMXStartupService.loadAMXMBeans(AMXStartupService.java:244)
... 31 more
|#]

[#|2013-01-21T15:37:18.355-0700|INFO|glassfish3.1.2|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=47;_ThreadName=Thread-2;|Shutdown
procedure finished|#]

This stack trace is coming from the domain's log file:

[#|2013-01-21T15:37:12.598-0700|INFO|glassfish3.1.2|org.glassfish.admingui|_ThreadID=121;_ThreadName=Thread-2;|
https://localhost:4848/management/domain/servers/server/APOC-Assessment-n03x01/stop-instance|#
]

[#|2013-01-21T15:37:12.608-0700|INFO|glassfish3.1.2|javax.enterprise.system.tools.admin.com.sun.enterprise.v3.admin.cluster|_ThreadID=122;_ThreadName=Thread-2;|Instance
APOC-Assessment-n03x01 shutdown initiated|#]

[#|2013-01-21T15:37:16.720-0700|INFO|glassfish3.1.2|ShoalLogger|_ThreadID=25;_ThreadName=Thread-2;|GMS1092:
GMS View Change Received for group: APOC-Assessment : Members in view for
PEER_STOP_EVENT(before change analysis) are :
1: MemberId: APOC-Assessment-n01x01, MemberType: CORE, Address:
192.168.10.81:9140:228.9.158.231:13386
:APOC-Assessment:APOC-Assessment-n01x01
2: MemberId: APOC-Assessment-n02x01, MemberType: CORE, Address:
192.168.10.82:9200:228.9.158.231:13386
:APOC-Assessment:APOC-Assessment-n02x01
3: MemberId: server, MemberType: SPECTATOR, Address: 192.168.10.81:9119
:228.9.158.231:13386:APOC-Assessment:server
|#]

[#|2013-01-21T15:37:16.720-0700|INFO|glassfish3.1.2|ShoalLogger|_ThreadID=25;_ThreadName=Thread-2;|GMS1016:
Analyzing new membership snapshot received as part of event:
PEER_STOP_EVENT for member: APOC-Assessment-n03x01 of group:
APOC-Assessment|#]

[#|2013-01-21T15:37:16.720-0700|INFO|glassfish3.1.2|ShoalLogger|_ThreadID=25;_ThreadName=Thread-2;|GMS1017:
Received PlannedShutdownEvent Announcement from member:
APOC-Assessment-n03x01 with shutdown type: INSTANCE_SHUTDOWN of group:
APOC-Assessment|#]

[#|2013-01-21T15:37:16.720-0700|INFO|glassfish3.1.2|ShoalLogger|_ThreadID=111;_ThreadName=Thread-2;|GMS1008:
Sending PlannedShutdownSignals to registered Actions for shutdownType
INSTANCE_SHUTDOWN member: APOC-Assessment-n03x01 ...|#]


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

This is related to part of 18878, a partial fix to which seemed to improve things a bit at least.

Comment by Tim Quinn [ 29/Jan/13 ]

A partial fix to 18878 made some improvement in this. Linking to that issue in case it's helpful.





[GLASSFISH-20462] DAS is slow to stop if JMX RMI bind URL is no longer reachable when stop-domain is run Created: 03/May/13  Updated: 03/May/13

Status: Open
Project: glassfish
Component/s: amx
Affects Version/s: 4.0_b87_RC3
Fix Version/s: future release

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


 Description   

Occasionally, the asadmin stop-domain command fails to stop the server. It times out after 60 seconds waiting for the DAS to stop:

$ asadmin stop-domain
Waiting for the domain to stop ........................................................
Timed out (60 seconds) waiting for the domain to stop.
Command stop-domain failed.

Here is some of the jstack output from the DAS after this occurs:

The problem appears to be in the thread the is running the stop-domain command:

"Thread-22" daemon prio=5 tid=0x00007fcbf92b2000 nid=0xd233 runnable [0x000000013d324000]
java.lang.Thread.State: RUNNABLE
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339)

  • locked <0x000000012cd628d0> (a java.net.SocksSocketImpl)
    at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200)
    at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182)
    at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:391)
    at java.net.Socket.connect(Socket.java:579)
    at java.net.Socket.connect(Socket.java:528)
    at java.net.Socket.<init>(Socket.java:425)
    at java.net.Socket.<init>(Socket.java:208)
    at sun.rmi.transport.proxy.RMIDirectSocketFactory.createSocket(RMIDirectSocketFactory.java:40)
    at sun.rmi.transport.proxy.RMIMasterSocketFactory.createSocket(RMIMasterSocketFactory.java:146)
    at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:613)
    at sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:216)
    at sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:202)
    at sun.rmi.server.UnicastRef.newCall(UnicastRef.java:340)
    at sun.rmi.registry.RegistryImpl_Stub.unbind(Unknown Source)
    at com.sun.jndi.rmi.registry.RegistryContext.unbind(RegistryContext.java:173)
    at com.sun.jndi.toolkit.url.GenericURLContext.unbind(GenericURLContext.java:272)
    at javax.naming.InitialContext.unbind(InitialContext.java:435)
    at javax.naming.InitialContext.unbind(InitialContext.java:435)
    at javax.management.remote.rmi.RMIConnectorServer.stop(RMIConnectorServer.java:561)
    at org.glassfish.admin.mbeanserver.ConnectorStarter.stop(ConnectorStarter.java:125)
  • locked <0x0000000118b93bf8> (a org.glassfish.admin.mbeanserver.RMIConnectorStarter)
    at org.glassfish.admin.mbeanserver.RMIConnectorStarter.stopAndUnexport(RMIConnectorStarter.java:310)
    at org.glassfish.admin.mbeanserver.JMXStartupService$JMXConnectorsStarterThread.shutdown(JMXStartupService.java:245)
    at org.glassfish.admin.mbeanserver.JMXStartupService.shutdown(JMXStartupService.java:193)
  • locked <0x00000001184d4ca0> (a org.glassfish.admin.mbeanserver.JMXStartupService)
    at org.glassfish.admin.mbeanserver.JMXStartupService.access$000(JMXStartupService.java:96)
    at org.glassfish.admin.mbeanserver.JMXStartupService$ShutdownListener.event(JMXStartupService.java:163)
    at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:131)
    at com.sun.enterprise.v3.server.AppServerStartup.stop(AppServerStartup.java:478)
  • locked <0x0000000118773f38> (a com.sun.enterprise.v3.server.AppServerStartup)
    at com.sun.enterprise.glassfish.bootstrap.GlassFishImpl.stop(GlassFishImpl.java:88)
  • locked <0x00000001187835f8> (a com.sun.enterprise.glassfish.bootstrap.GlassFishImpl)
    at com.sun.enterprise.glassfish.bootstrap.GlassFishDecorator.stop(GlassFishDecorator.java:68)
    at com.sun.enterprise.glassfish.bootstrap.osgi.EmbeddedOSGiGlassFishImpl.stop(EmbeddedOSGiGlassFishImpl.java:82)
    at com.sun.enterprise.v3.admin.StopServer.doExecute(StopServer.java:79)
    at com.sun.enterprise.v3.admin.StopDomainCommand.execute(StopDomainCommand.java:96)
    at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:527)
    at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:523)
    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:522)
    at org.glassfish.api.AsyncImpl$1$1.run(AsyncImpl.java:76)

This problem seems to occur after the server has been up for a while (for example overnight).



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

In this situation, eventually the DAS does exit. Apparently, the Socket.connect call eventually times out and the server finishes exiting. So the mystery here is why is javax.naming.InitialContext.unbind making a socket connection during shutdown.

Comment by Tom Mueller [ 03/May/13 ]

To reproduce this problem, start the server while connected to VPN (so the hostname/IP address of the server is set). While the server is running, disconnect from VPN so the IP address is no longer associated with the host. Then run stop-domain. (This sometimes causes the problem).

The JMX unbind request is being done on a URL like this:

"rmi://192.168.0.16:8686/jmxrmi"

or sometimes, like this:

"rmi://dhcp-adc-twvpn-3-vpnpool-10-154-105-156.vpn.oracle.com:8686/jmxrmi"

In the first case, the URL uses the IP address of my host on the local LAN. In the second case, it uses the VPN hostname of the VPN address. If the JMX URL is of this latter kind, and the host is disconnected from the VPN at the time stop-domain is run, the unbind request will attempt to connect to the URL and it will fail but with a long timeout. This causes the DAS exit to take a long time so the stop-domain times out.

Comment by Tom Mueller [ 03/May/13 ]

Lowering the priority, deferring to a future release and changing the component to AMX.





[GLASSFISH-2018] amx:j2eeType=X-WebModuleVirtualServerMonitor Created: 11/Jan/07  Updated: 20/Feb/11

Status: Reopened
Project: glassfish
Component/s: amx
Affects Version/s: 9.1pe
Fix Version/s: 9.1pe

Type: Bug Priority: Minor
Reporter: llc Assignee: naman_mehta
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 2,018

 Description   

AMX unit tests detect inconcistencey problems:

.getAllMonitoringStats, 25 MBeans: 58ms
checkStatsClassSuppliesAllStatistics failed for: "amx:j2eeType=X-
WebModuleVirtualServerMonitor,name=//__asadmin/,X-ApplicationMonitor=null,X-
ServerRootMonitor=server" with Exception of type java.lang.AssertionError, msg = Statistic names for
"amx:j2eeType=X-WebModuleVirtualServerMonitor,name=//__asadmin/,X-ApplicationMonitor=null,X-
ServerRootMonitor=server" obtained via Statistic names do not match those obtained via introspection:
via names:

{ActiveSessionsCurrent,ActiveSessionsHigh,ExpiredSessionsTotal,JSPCount,JSPErrorCount,JSPReloadCoun t,RejectedSessionsTotal,ServletProcessingTimes,Sessions,SessionsTotal}
via introspection: {ActiveSessionsCurrent,ActiveSessionsHigh,CachedSessionsCurrent,ContainerLatency,ExpiredSessionsTo tal,JSPCount,JSPErrorCount,JSPReloadCount,PassivatedSessionsCurrent,RejectedSessionsTotal,ServletPro cessingTimes,SessionPersistTime,SessionSize,Sessions,SessionsTotal}
checkStatsClassSuppliesAllStatistics failed for: "amx:j2eeType=X-
WebModuleVirtualServerMonitor,name=//server/,X-ApplicationMonitor=null,X-
ServerRootMonitor=server" with Exception of type java.lang.AssertionError, msg = Statistic names for
"amx:j2eeType=X-WebModuleVirtualServerMonitor,name=//server/,X-ApplicationMonitor=null,X-
ServerRootMonitor=server" obtained via Statistic names do not match those obtained via introspection:
via names:{ActiveSessionsCurrent,ActiveSessionsHigh,ExpiredSessionsTotal,JSPCount,JSPErrorCount,JSPReloadCount,RejectedSessionsTotal,ServletProcessingTimes,Sessions,SessionsTotal}

via introspection:

{ActiveSessionsCurrent,ActiveSessionsHigh,CachedSessionsCurrent,ContainerLatency,ExpiredSessionsTo tal,JSPCount,JSPErrorCount,JSPReloadCount,PassivatedSessionsCurrent,RejectedSessionsTotal,ServletPro cessingTimes,SessionPersistTime,SessionSize,Sessions,SessionsTotal}

Ran test method checkStatsClassSuppliesAllStatistics on 25 candidates in 306ms



 Comments   
Comment by gfbugbridge [ 17/Jan/07 ]

<BT>

Comment by gfbugbridge [ 17/Jan/07 ]

<BT6514375>

Comment by km [ 01/Feb/07 ]

Monitoring.

Comment by sirajg [ 15/Feb/07 ]

Some stats appear to be missing - need to add the missing stats

Comment by sirajg [ 23/Feb/07 ]

The difference in the 2 lists described in the bug report are the follo statistics :
CachedSessionsCurrent
ContainerLatency
PassivatedSessionsCurrent
SessionSize

These are all exposed to the user through the admin infrastructure in EE. There
may have been something wrong with the test that generated these results.

Comment by llc [ 27/Feb/07 ]

The error message is correct: the names do not match what is actually in the Stats object.

Comment by sirajg [ 12/Apr/07 ]

All the relevant monitoring statistics are exposed in admin interfaces.

Comment by llc [ 13/Apr/07 ]

The unit test is still failing. Looks like all the problems have been rectified except one: the Statistic
"PassivatedSessionsCurrent" is supplied from getStatistics(), but is not supplied in getStatisticNames():

checkStatsClassSuppliesAllStatistics failed for: "amx:j2eeType=X-
WebModuleVirtualServerMonitor,name=//__asadmin/web1,X-ApplicationMonitor=null,X-
ServerRootMonitor=server" with Exception of type java.lang.AssertionError,
msg = Statistic names for "amx:j2eeType=X-WebModuleVirtualServerMonitor,name=//__asadmin/
web1,X-ApplicationMonitor=null,X-ServerRootMonitor=server" obtained via Statistic names do not
match those obtained via introspection:

via names:
ActiveSessionsCurrent, OK
ActiveSessionsHigh, OK
ExpiredSessionsTotal, OK
JSPCount, OK
JSPErrorCount, OK
JSPReloadCount, OK
RejectedSessionsTotal, OK
ServletProcessingTimes, OK
Sessions, OK
SessionsTotal OK

via introspection:
ActiveSessionsCurrent, OK
ActiveSessionsHigh, OK
ExpiredSessionsTotal, OK
JSPCount, OK
JSPErrorCount, OK
JSPReloadCount, OK
PassivatedSessionsCurrent, **** NOT OK ***
RejectedSessionsTotal, OK
ServletProcessingTimes, OK
Sessions, OK
SessionsTotal OK

1) testStatsClassSuppliesAllStatistics(com.sun.enterprise.management.monitor.MonitorTest)
java.lang.AssertionError
at com.sun.enterprise.management.AMXTestBase.testAll(AMXTestBase.java:562)
at com.sun.enterprise.management.monitor.MonitorTest.testStatsClassSuppliesAllStatistics
(MonitorTest.java:513)

Comment by sirajg [ 23/May/07 ]
      • Issue 3036 has been marked as a duplicate of this issue. ***
Comment by llc [ 25/May/07 ]

Statistic names come from other module classes. Not sure which exact piece of code to look at, but I think
it should be somewhere in
appser-core-ee\com.sun.enterprise.ee.web.stats.EEWebModuleStatsImpl or
appserv-core\com.sun.enterprise.web.stats.WebModuleStatsImpl

Comment by prasads [ 20/Feb/11 ]

Assigning issues to Naman





[GLASSFISH-1799] No NB project files Created: 18/Dec/06  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: amx
Affects Version/s: 9.0pe
Fix Version/s: not determined

Type: Bug Priority: Minor
Reporter: Byron Nevins Assignee: pa100654
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 1,799

 Description   

appserv-api module does not have NB project files.



 Comments   
Comment by km [ 01/Feb/07 ]

Prashanth – why don't you just checkin the nbproject folder we created that day?

Comment by pa100654 [ 02/Apr/07 ]

Need a fix

Comment by gfbugbridge [ 05/Apr/07 ]

<BT6543237>

Comment by llc [ 06/Apr/07 ]

I don't use NetBeans. Prashanth feel free to add the file(s).

Comment by llc [ 12/Apr/07 ]

This is low priority, changing to P4.

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.





Generated at Wed Dec 07 09:38:12 UTC 2016 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.