Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

EclipseLink/DesignDocs/316513

< EclipseLink‎ | DesignDocs
Revision as of 10:18, 29 July 2010 by Michael.obrien.oracle.com (Talk | contribs) (DI 6: 20100722: Add generic jmx.moduleName and jmx.applicationName overrides for persistence.xml)

Contents

Design Specification: Extend WebLogic 10.3 JMX MBean support to JBoss 5.1.0, WebSphere 7 and GlassFish V3 as generic API

Work in Queue

Completed Work

JPA EAR, EJB, WAR and SE (DDL Generation) WebLogic 10.3 J2EE application Eclipse projects in SVN - use to perform JMX MBean registration

Document History

Date Author Version Description & Notes
2010-06-10 Michael O'Brien 0.1 Starting Draft for Generic JMX MBean support to extend WebLogic 10.3 support to JBoss 5.1.0 EAP and WebSphere 7 for ER 316513
2010-06-22 Michael O'Brien 0.2 Develop/Document JBoss 5.1.0 EAP JMX registration code ER 316511 as work has been approved for the next release. We will concentrate on a POC for both servers before examining a rearchitecture as we move from WebLogic to include JBoss and WebSphere possibly using a new JMXPolicy interface instead of refactoring up into ServerPlatformBase
2010-07-05 Michael O'Brien 0.3 JBoss 5.0.1 EAP, Glassfish V2 2.1.0, Glassfish V3 3.0.1 all register functional EclipseLink MBeans now.

Project overview

QuickStart for Implementors

  • 1) Enable MBeans via System property

All Platforms Configuration

WebLogic Specific Configuration

JBoss Specific Configuration

WebSphere Specific Configuration

GlassFish Specific Configuration

Analysis

DI 1: Architecture for new JMX Platform Implementors

  • This design issue discusses how we will rearchitect the JMX support in EclipseLink. Currently only the WebLogic_10 platform supports JMX MBeans - we are extending this to JBoss 5 and WebSphere 7. There are a couple ways of implementing this change that involves consolidating duplicated functionality and extending only those platforms that support JMX in EclipseLink at this point - while at the same time providing a policy framework for further expansion of JMX support.
  • The big issue is how do we handle multiple inheritance with a combination of new Abstract or Interface classes without changing the entire ServerPlatform hierarchy.

Option 1: Move everything generic up to ServerPlatformBase

  • This issue with this is that we will only have 3 of the 6 platforms JMX enabled - by moving JMX code too high up in the class hierarchy we introduce functionality that OC4J, SAP and SUNAS support but not within the current EclipseLink version.

Option 2: Create a new JMXServer Policy or Interface

  • Although an interface is not required, it would be usefull in specifying which functions the actual platform where we register MBeans must implement.

Option 3: Create a new abstract JMXServerPlatform below ServerPlatformBase

Option 4: Create both a new abstract JMXServerPlatform abstract class and a JMXEnabledPlatform interface

  • Verify constructor does not leak unitialized variables during super() call

Option 5: Use the Decorator pattern: refactor the Platform package to use composition instead of inheritance

  • Each platform subclass no longer subclasses - it has a final private field of the superclass
  • Each method call on the private class is wrapped/forwarded to the wrapper class.
  • Benefits is that a superclass change does not affect the subclass
  • See Item 14 in Effective Java

Decision DI 1:

  • Currently option 4 - new JMX Interface and a new abstract JMXServerPlatformBase below ServerPlatformBase
  • All platforms will inherit from JMXServerPlatformBase instead of the original superclass ServerPlatformBase. This is where all generic JMX functions will preside but be disabled by default.
  • In the actual platforms where we enable JMX support these will implement the new JMXEnabledPlatform interface.
    • The use of the interface is to notify developers of the server specific functions required for JMX enabled platforms.
  • We used to have the hierarchy and still do for platforms like OC4J and NetWeaver
  • ServerPlatformBase(A)
    • PlatformSuperclass
      • VersionedPlatform
  • We now have the following hierarchy for platforms where at least on version of the server implements JMXEnabledPlatform(I)
  • ServerPlatformBase(A)
    • JMXServerPlatformBase(A)
      • PlatformSuperclass
        • VersionedPlatform implements JMXEnabledPlatform(I)

DI 2: Enabling JMX MBeans

WebLogic

rem dev bean is deprecated and slated for removal
rem set JAVA_OPTIONS=%JAVA_OPTIONS% -Declipselink.register.dev.mbean=true
set JAVA_OPTIONS=%JAVA_OPTIONS% -Declipselink.register.run.mbean=true

JBoss

  • jboss-eap-5.0/jboss/as/bin/run.bat:83
// after
set JAVA_OPTS=%JAVA_OPTS% "-Djava.library.path=%JBOSS_NATIVE_HOME%;%PATH%;%SYSTEMROOT%"
// add
set JAVA_OPTS=%JAVA_OPTS% -Declipselink.register.run.mbean=true

WebSphere

GlassFish

DI 3: MBean Registration and Deregistration

  • These steps are mostly the same for all servers
    • 1) Get JNDI context to lookup an 'MBeanServer
    • 2) Create a new ObjectName for the MBean
    • 3) Create a server specific MBean via 1a) JNDI lookup or 1b) Direct API factory
    • 4) call registerMBean using the MBean and ObjectName
    • 5) discard the ObjectInstance return of registerMBean but cache the MBean*RuntimeServices MBean

MBean Registration

Option 1: JNDI Lookup
Option 2: Direct factory reference via JMX API
  • Get the first server in the list - usually the only one unless we are running on Oracle JRockit.
MBeanServer mBeanServerRuntime = (MBeanServer) MBeanServerFactory.findMBeanServer(null).get(0);
// or
MBeanServer mBeanServerRuntime = ManagementFactory.getPlatformMBeanServer();
  • Which one are we using? currently MBeanServerFactory.
  • What is the difference between using the MBeanServerFactory or ManagementFactory?
  • Note: This registration functionality works for all 4 servers WebLogic, WebSphere, Glassfish and JBoss so far.
  • The key here is that we use the same generic lookup for all platforms without using server specific JNDI.
  • Here is the refactored WebLogic_10_Platform using this non-JNDI lookup and registration - via the JRockit MC JConsole viewer.

Jrockit jconsole mbeans via non jndi generic spec lookup.JPG

Option 3: Direct factory reference via JBoss API
org.jboss.system.ServiceMBeanSupport

WebSphere MBean Registration

Option 1: JNDI Lookup

WebLogic MBean Registration

Option 1: JNDI Lookup

GlassFish MBean Registration

DI 4: 20100624: Verify correct MBeanServer available when running multiple MBeanServer Instances

  • We may have more than one MBeanServer in use - we will use the one at index 0
14:18:55,645 INFO  [LogNotificationListener] Adding notification listener for logging mbean "jboss.system:service=Logging,type=Log4jService" to server org.jboss.mx.server.MBeanServerImpl@1d351d35[ defaultDomain='jboss' ]
...
14:19:14,373 INFO  [STDOUT] [EL Warning]: 2010-07-09 14:19:14.373--Thread(Thread[http-127.0.0.1-8080-1,5,jboss])--
Multiple [2] JMX MBeanServer instances exist, we are registering the MBean on the first indexed one [org.jboss.mx.server.MBeanServerImpl@1d351d35[ defaultDomain='jboss' ]].
14:19:14,373 INFO  [STDOUT] [EL Info]: 2010-07-09 14:19:14.373--Thread(Thread[http-127.0.0.1-8080-1,5,jboss])--
JMX MBeanServer instance found: [org.jboss.mx.server.MBeanServerImpl@1d351d35[ defaultDomain='jboss' ]].
14:19:14,373 INFO  [STDOUT] [EL Info]: 2010-07-09 14:19:14.373--Thread(Thread[http-127.0.0.1-8080-1,5,jboss])--
JMX MBeanServer instance found: [org.jboss.mx.server.MBeanServerImpl@30263026[ defaultDomain='null' ]].
14:19:14,373 INFO  [STDOUT] [EL Finest]: 2010-07-09 14:19:14.373--Thread(Thread[http-127.0.0.1-8080-1,5,jboss])--
Registered MBean: org.eclipse.persistence.services.mbean.MBeanDevelopmentServices[TopLink:Name=Development-vfszip_/C_/opt/jboss-eap-5.0b/jboss-as/server/default/deploy/org.eclipse.persistence.example.jpa.server.jboss.EnterpriseEAR.ear/org.eclipse.persistence.example.jpa.server.jboss.EnterpriseEJB.jar/_example,Type=Configuration]
14:19:14,373 INFO  [STDOUT] [EL Finest]: 2010-07-09 14:19:14.373--Thread(Thread[http-127.0.0.1-8080-1,5,jboss])--
Registered MBean: org.eclipse.persistence.services.jboss.MBeanJBossRuntimeServices[TopLink:Name=Session(vfszip_/C_/opt/jboss-eap-5.0b/jboss-as/server/default/deploy/org.eclipse.persistence.example.jpa.server.jboss.EnterpriseEAR.ear/org.eclipse.persistence.example.jpa.server.jboss.EnterpriseEJB.jar/_example)]

DI 5: 20100712: Upgrade from JMX 1.2 to JMX Remoting:JSR-160

  • One of the application servers we support will be deprecating JMX 1.2 support in favor of the new JSR=160 JMX Remoting API which standardizes JNDI and IIOP connectivity.
  • The code changes will be the following

DI 6: 20100722: Add generic jmx.moduleName and jmx.applicationName overrides for persistence.xml

  • See documentation bug# 321229
  • The following 2 properties were introduced as of SVN rev 7901 in EclipseLink 2.1.1 as manual overrides available to persistence units published to the servers that support EclipseLink JMX MBeans as of enhancement bug# 316513 for WebLogic, WebSphere, JBoss and Glassfish.
  <property name="eclipselink.jmx.applicationName" value="app_override"/>
  <property name="eclipselink.jmx.moduleName" value="mod_override"/>
  • By default these overrides are not set and we use the ConversionManager ClassLoader from the Platform to extract the identifier names for the EAR.
  • The previous weblogic specific override properties have been deprecated.

Design

WebLogic JMX Integration

JBoss JMX Integration

  • 20100622: This section details the JMX registration code for EclipseLink MBeans on JBoss 5.1.0 EAP
  • See jar signing and JMX prepending issues solved in bug# 305331 specific to the JBoss EAP edition that need to be covered off.

Modules

NEW: core:services.mbean.jboss.MBeanJBossRuntimeServices.java
NEW: core:services.mbean.jboss.MBeanJBossRuntimeServicesMBean.java
NEW: core:services.mbean.jboss.JBossRuntimeServices.java
MOD: core:services.mbean.weblogic.ClassSummaryDetail.java moved up to parent package
MOD: core:platform.server.jboss.JBossPlatform.java
MOD: core:services.mbean.weblogic.WebLogic_10_platform.java
  • Move the now generic system properties up to ServerPlatformBase
    /** This System property "eclipselink.register.dev.mbean" when set to true will enable registration/unregistration of the DevelopmentServices MBean */
    public static final String JMX_REGISTER_DEV_MBEAN_PROPERTY = "eclipselink.register.dev.mbean";
    /** This System property "eclipselink.register.run.mbean" when set to true will enable registration/unregistration of the RuntimeServices MBean */    
    public static final String JMX_REGISTER_RUN_MBEAN_PROPERTY = "eclipselink.register.run.mbean";

WebSphere JMX Integration

GlassFish JMX Integration

  • No work scheduled at this point of 20100622

Design Issue NN:

Analysis NN:

Solution NN:

Implementation

Phase 1: Customer Preliminary Preview

Phase 2: Complete Generic Refactor

  • verify movement of interface functions from server specific RuntimeServices to superclass interface

Phase 3: Close off bug and code review changes

  • Refactor common functions in server specific RuntimeServices classes to parent RuntimeServies
  • Change Vector and Hashtable ussage in RuntimeServices.getMappedClassNames to use HashMap (ConcurrentHashMap not required)
  • Refactor Vector usage in getNumberOfObjectsInAllIdentityMaps
  • Refactor Hashtable usage in getNumberOfPersistentClasses
  • Refactor Vector ussage out of getClassSummaryDetailsArray()
  • buildLowlevelDetailsForNew() is not referenced in any RuntimeServices implementation - remove it

Testing

JBoss Specific EAR Configuration

  • The following scenario specifies @Remote on the remote interface and @Stateless on the stateless session bean.
    • This results in the following JNDI name emitted by the server on EAR deploy
@Stateless(name="ApplicationService", mappedName="ApplicationService")
@Remote(ApplicationServiceRemote.class)
public class ApplicationService implements ApplicationServiceRemote  {
	@PersistenceContext(unitName="example", type=PersistenceContextType.TRANSACTION)	
	private EntityManager entityManager;
...
}
 
public class FrontController extends HttpServlet implements Servlet {
    public static final String APPLICATION_SERVICE_JNDI_NAME 
      = "org.eclipse.persistence.example.jpa.server.jboss.EnterpriseEAR/ApplicationService/remote-org.eclipse.persistence.example.jpa.server.business.ApplicationServiceRemote";    
 
    /**
     * Get the SSB ApplicationService bean - using a JNDI context lookup (no EJB injection was used on this servlet)
     * @param viaJNDILookup
     * @return
     */
    public ApplicationServiceRemote getApplicationService(boolean viaJNDILookup) {
        if(null == applicationService && viaJNDILookup) {
            try {
                Hashtable<String, String> env = new Hashtable<String, String>();      
                env.put(Context.INITIAL_CONTEXT_FACTORY, "org.jnp.interfaces.NamingContextFactory");     
                env.put(Context.PROVIDER_URL, "localhost");      
                env.put(Context.URL_PKG_PREFIXES, "org.jboss.naming:org.jnp.interfaces" );     
                InitialContext ctx = new InitialContext(env);
                System.out.println("FrontController.getApplicationService() JNDI lookup of " + APPLICATION_SERVICE_JNDI_NAME);
                return (ApplicationServiceRemote) ctx.lookup(APPLICATION_SERVICE_JNDI_NAME);            
            } catch (Exception e) {
                e.printStackTrace();
                throw new RuntimeException("Exception looking up session bean: ", e);
            }
        } else {
            return applicationService;
        }
    }
...
}

JBoss Proof of Concept Registration 1

  • First POC results positive using a non-JNDI JMX spec findMBeanServer() first server returned lookup (fine only for non-JRockit JVMs)

JBoss JMX View of Services MBean after EM creation via EAR application run

Jboss501eap toplink services mbean view POC cap.JPG

mBeanServerRuntime = (MBeanServer) MBeanServerFactory.findMBeanServer(null).get(0);
  • we register via
runtimeInstance = mBeanServerRuntime.registerMBean(runtimeServices, anObjectName);
  • to
server	MBeanServerImpl  (id=400)	
	classLoaderRepository	UnifiedLoaderRepository3  (id=409)	
	listeners	MBeanServerListenerRegistry  (id=417)	
	outer	MBeanServerImpl  (id=400)	
		classLoaderRepository	UnifiedLoaderRepository3  (id=409)	
		listeners	MBeanServerListenerRegistry  (id=417)	
		outer	MBeanServerImpl  (id=400)	
		registry	BasicMBeanRegistry  (id=419)	
			defaultDomain	"jboss" (id=426)	
			delegate	MBeanServerDelegate  (id=427)	
			domainMap	ConcurrentReaderHashMap  (id=432)	
			fMbInfosToStore	null	
			loaderRepository	UnifiedLoaderRepository3  (id=409)	
			mbeanInfoService	ObjectName  (id=436)	
			registrationNotificationSequence	SynchronizedLong  (id=439)	
			server	MBeanServerImpl  (id=400)	
			unregistrationNotificationSequence	SynchronizedLong  (id=444)	
	registry	BasicMBeanRegistry  (id=419)	
  • giving us
16:56:54,376 INFO  [STDOUT] [EL Finest]: 2010-06-22 16:56:54.376--Thread(Thread[http-127.0.0.1-8080-2,5,jboss])--Registered MBean: org.eclipse.persistence.services.jboss.MBeanJBossRuntimeServices[TopLink:Name=Session(vfszip_/C_/opt/jboss-eap-5.0b/jboss-as/server/default/deploy/org.eclipse.persistence.example.jpa.server.jboss.EnterpriseEAR.ear/org.eclipse.persistence.example.jpa.server.jboss.EnterpriseEJB.jar/_example)]

runtimeInstance	ServerObjectInstance  (id=519)	
	agentID	"xps435_1277239942304" (id=436)	
	className	"org.eclipse.persistence.services.jboss.MBeanJBossRuntimeServices" (id=521)	
	name	ObjectName  (id=501)	
		_ca_array	ObjectName$Property[1]  (id=523)	
		_canonicalName	"TopLink:Name=Session(vfszip_/C_/opt/jboss-eap-5.0b/jboss-as/server/default/deploy/org.eclipse.persistence.example.jpa.server.jboss.EnterpriseEAR.ear/org.eclipse.persistence.example.jpa.server.jboss.EnterpriseEJB.jar/_example)" (id=524)

Example JMX MBean call - printAllIdentityMapTypes

11:37:53,836 INFO  [STDOUT] [EL Info]: 2010-06-24 11:37:53.836--ServerSession(16405579)--Thread(Thread[http-127.0.0.1-8080-1,5,jboss])--Identity Map [org.eclipse.persistence.example.jpa.server.business.Cell] class = class org.eclipse.persistence.internal.identitymaps.SoftCacheWeakIdentityMap
11:37:53,836 INFO  [STDOUT] [EL Info]: 2010-06-24 11:37:53.836--ServerSession(16405579)--Thread(Thread[http-127.0.0.1-8080-1,5,jboss])--Identity Map [org.eclipse.persistence.example.jpa.server.business.CellAttribute] class = class org.eclipse.persistence.internal.identitymaps.SoftCacheWeakIdentityMap

WebSphere 7 JMX View of Services MBean after EM creation via EAR application run

Glassfish 2.1 JMX View of Services MBean after EM creation via EAR application run

Glassfish 3.0.1 JMX View of Services MBean after EM creation via EAR application run

Glassfish V3 JMXServiceURL

service:jmx:rmi://xps435:8686/jndi/rmi://xps435:8686/jmxrmi

Testing Data Model

Viewing EclipseLink MBeans by Application Server

WebLogic on JRockit JVM

####<14-Jul-2010 10:26:49 o'clock AM EDT> <Info> <JMX> <xps435> <AdminServer> <[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1279117609637> <BEA-149512> <JMX Connector Server started at service:jmx:iiop://[2001:0:4137:9e76:de:26c4:f563:cb0d]:7001/jndi/weblogic.management.mbeanservers.runtime .> 
####<14-Jul-2010 10:26:49 o'clock AM EDT> <Info> <JMX> <xps435> <AdminServer> <[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1279117609637> <BEA-149512> <JMX Connector Server started at service:jmx:iiop://[2001:0:4137:9e76:de:26c4:f563:cb0d]:7001/jndi/weblogic.management.mbeanservers.edit .> 
####<14-Jul-2010 10:26:49 o'clock AM EDT> <Info> <JMX> <xps435> <AdminServer> <[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1279117609657> <BEA-149512> <JMX Connector Server started at service:jmx:iiop://[2001:0:4137:9e76:de:26c4:f563:cb0d]:7001/jndi/weblogic.management.mbeanservers.domainruntime .> 

WebLogic on SUN JVM

JBoss on SUN JVM

WebSphere on IBM J9 JVM

WebSphere on SUN JVM

  • Has issues - not tested

GlassFish on SUN JVM

  • Launch JConsole
    • Select remote process
GlassFish V3
  • JMXServiceURL for GlassFish V3 is a really odd non-JMX spec
    • service:jmx:rmi://xps435:8686/jndi/rmi://xps435:8686/jmxrmi
    • instead of an expected
    • service:jmx:rmi://xps435:8686/jndi/jmxrmi
GlassFish V2
  • JMXServiceURL
    • service:jmx:rmi:///jndi/rmi://xps435:8686/jmxrmi

Identifier testing: getApplicationName() and getModuleName()

  • The following outputs occur during MBean registration on the appropriate EE server.
  • The applicationName for Glassfish needs to be cleaned up, also we need testing for multiple modules via multiple persistence units in mixed/multi ejb/war deployments
  • See SVN rev# 7901
  • Testing results for non-reflective module/application name calls in the JMX code

WebLogic

  • WebLogic 10.3.3.0 via Eclipse 3.5 OEPE
[EL Finest]: 2010-07-22 14:31:33.025--Thread(Thread[[ACTIVE] ExecuteThread: '3'
for queue: 'weblogic.kernel.Default (self-tuning)',5,Pooled Threads])--The
applicationName for the MBean attached to session
[file:/F:/view_w35_wls1033/examples/org.eclipse.persistence.example.jpa.server.weblogic.enterpriseEJB/build/classes/_example] 
is [org.eclipse.persistence.example.jpa.server.weblogic.enterpriseEAR]
[EL Finest]: 2010-07-22 14:31:33.025--Thread(Thread[[ACTIVE] ExecuteThread: '3'
for queue: 'weblogic.kernel.Default (self-tuning)',5,Pooled Threads])--The
moduleName for the MBean attached to session
[file:/F:/view_w35_wls1033/examples/org.eclipse.persistence.example.jpa.server.weblogic.enterpriseEJB/build/classes/_example] 
is [enterprise]

JBoss

  • JBoss 5.0.1EAP via Eclipse 3.5
12:45:09,602 INFO  [STDOUT] [EL Finest]: 2010-07-22
12:45:09.601--Thread(Thread[http-127.0.0.1-8080-1,5,jboss])--The
applicationName for the MBean attached to session
[vfszip:/C:/opt/jboss-eap-5.0b/jboss-as/server/default/deploy/org.eclipse.persistence.example.jpa.server.jboss.EnterpriseEAR.ear/org.eclipse.persistence.example.jpa.server.jboss.EnterpriseEJB.jar/_example2] 
is [org.eclipse.persistence.example.jpa.server.jboss.EnterpriseEAR.ear]
12:45:09,602 INFO  [STDOUT] [EL Finest]: 2010-07-22
12:45:09.602--Thread(Thread[http-127.0.0.1-8080-1,5,jboss])--The moduleName for
the MBean attached to session
[vfszip:/C:/opt/jboss-eap-5.0b/jboss-as/server/default/deploy/org.eclipse.persistence.example.jpa.server.jboss.EnterpriseEAR.ear/org.eclipse.persistence.example.jpa.server.jboss.EnterpriseEJB.jar/_example2] 
is [_example2]

WebSphere

  • WebSphere 7.0.0.5 via Eclipse 3.5 (no server launch)
[7/22/10 12:25:41:108 EDT] 00000013 SystemOut     O [EL Finest]: 2010-07-22
12:25:41.108--Thread(Thread[WebContainer : 0,5,main])--The applicationName for
the MBean attached to session
[jar:file:/C:/opt/was7b/AppServer/profiles/AppSrv01/installedApps/xps435Node01Cell/org.eclipse.persistence.example.jpa.server.websphere.EnterpriseEAR.ear/org.eclipse.persistence.example.jpa.server.websphere.EnterpriseEJB.jar!/_example] 
is [org.eclipse.persistence.example.jpa.server.websphere.EnterpriseEAR]

[7/22/10 12:25:41:108 EDT] 00000013 SystemOut     O [EL Finest]: 2010-07-22
12:25:41.108--Thread(Thread[WebContainer : 0,5,main])--The moduleName for the
MBean attached to session
[jar:file:/C:/opt/was7b/AppServer/profiles/AppSrv01/installedApps/xps435Node01Cell/org.eclipse.persistence.example.jpa.server.websphere.EnterpriseEAR.ear/org.eclipse.persistence.example.jpa.server.websphere.EnterpriseEJB.jar!/_example] 
is [_example]

Glassfish

  • GlassFish 3.0.1 via NetBeans 6.9
FINEST: The applicationName for the MBean attached to session
[file:/C:/wnb69/GlassfishV3EAR/dist/gfdeploy/GlassfishV3EAR/GlassfishV3EAR-ejb_jar/_example]
 is
[C:/wnb69/GlassfishV3EAR/dist/gfdeploy/GlassfishV3EAR/GlassfishV3EAR-ejb_jar/_URLEntry
_file:/C:/opt/nbgf301/glassfish/domains/domain1/generated/ejb/GlassfishV3EAR/GlassfishV3EAR-ejb_jar]
FINEST: The moduleName for the MBean attached to session
[file:/C:/wnb69/GlassfishV3EAR/dist/gfdeploy/GlassfishV3EAR/GlassfishV3EAR-ejb_jar/_example] 
is [_example]

Regression Testing

  • change server names, IPs and HD paths to your environment
  • 1) Download my 20100629:0000 patch and rebuild your eclipselink.jar with these changes that are not yet in SVN.
    • Note: comments and error handling are not finished yet
  • 2) Note: currently Services MBean enablement is hardcoded to true for testing - it will be reverted to customer selectable before checkin
  • 3) Note: on non-WebLogic platforms the getModuleName/getApplicationName reflection code is not enabled yet
  • 4) The 20100630:1018 jar currently contains support for WebLogic 10.3, WebSphere 7 and JBoss (5 or 6)
  • 5) Run any EAR application that deploys an EntityManager such as the ones in the examples folder off of trunk,
    • Or use the EAR attached to bug# 316511 for JBoss
    • You should see the JBoss JMX screen capture above after you invoke http://127.0.0.1:8080/enterprise/FrontController?action=demo
    • The EAR demo will run out of the box with the DefaultDS HQSL datasource provided you have copied eclipselink.jar to the \common\lib directory
      • <jta-data-source>java:/DefaultDS</jta-data-source>
  • 6) Run a JMX viewer like one of the following to view and exercise TopLink MBeans
    • JBoss: http://127.0.0.1:8080/jmx-console/
    • WebLogic: JRockit MC (C:\opt\wls10330\jrockit_160_17_R28.0.0-679\bin\jrmc.exe)
    • WebSphere: TBD (J9 JConsole is having issues)
    • GlassFish: JConsole
      • V3 Remote process: service:jmx:rmi://xps435:8686/jndi/rmi://xps435:8686/jmxrmi
      • V2 Remote process: service:jmx:rmi:///jndi/rmi://xps435:8686/jmxrmi

Open Issues

References

Back to the top