| Re: [eclipselink-users] JVM properties vs persistence.xml |
Nathan, Work was done to support JMX on JBoss 5/6, WebLogic, (GlassFish 3 and WebSphere 7 needs to be reverified) http://wiki.eclipse.org/EclipseLink/DesignDocs/316513#JBoss_Proof_of_Concept_Registration_1 WebSphere https://bugs.eclipse.org/bugs/show_bug.cgi?id=316510 JBoss https://bugs.eclipse.org/bugs/show_bug.cgi?id=316511 GlassFish https://bugs.eclipse.org/bugs/show_bug.cgi?id=316512 https://bugs.eclipse.org/bugs/attachment.cgi?id=173484 Work was also prototyped to register in all SE application-managed environments – the NoServerPlatform https://bugs.eclipse.org/bugs/show_bug.cgi?id=265540 See JMX viewers… Run a JMX viewer like one of the following to view and exercise TopLink MBeans
C:\>jconsole -J-Djava.class.path=C:/opt/wls1031_l16/jdk160_11/lib/jconsole.jar;C:/opt/wls1031_l16/jdk160_11/l ib/tools.jar;C:/opt/wls1031_l16/wlserver_10.3/server/lib/wljmxclient.jar -J-Djmx.remote.protocol.provider.pkgs=weblogic.management.remote -J-Dcom.sun.management.jmxremote
-Djavax.management.builder.initial=weblogic.management.jmx.mbeanserver.WLSMBeanServerBuilder
§ V3 Remote process: service:jmx:rmi://xps435:8686/jndi/rmi://xps435:8686/jmxrmi § V2 Remote process: service:jmx:rmi:///jndi/rmi://xps435:8686/jmxrmi 2) By JVM properties – I mean JVM options or parameters like -Declipselink.register.run.mbean=true The JXM registration is on by default I believe. Other properties unrelated to JMX may also work at the command line level. /F. Michael O’Brien From: eclipselink-users-bounces@xxxxxxxxxxx [mailto:eclipselink-users-bounces@xxxxxxxxxxx] On Behalf Of Nathan Drew Hi Michael, That seems like it might be useful, but a couple of points: · Is the JMX MBean support only for WebLogic? If others are supported, are there examples for those (such as WebSphere and GlassFish)? · What happened to JVM System properties? TopLink Essentials seemed to have this ability so has EclipseLink development removed this ability? Some customers may not be able to attach JMX MBean browser clients so JVM properties would be another tool that would be great to have. Kind Regards Nathan From: eclipselink-users-bounces@xxxxxxxxxxx [mailto:eclipselink-users-bounces@xxxxxxxxxxx] On Behalf Of Michael O'Brien Nathan, Good question, yes, in addition to deployment-time you can also change the logging level at runtime and do other things like clear the cache – dynamically for a specific container managed persistence context running in an EE server like WebLogic for example. Use JConsole, JRMC or any other JMX spec compliant MBean browser client to obtain a reference to the methods and properties of the EclipseLink services MBean named “TopLink_[session-name]”. You can refer to the design document on exposing the MBean that I was involved with. It contains all necessary references, screen captures and documentation links. http://wiki.eclipse.org/EclipseLink/DesignDocs/248748 You will be running the following method via the JMX API client. § public synchronized void setCurrentEclipseLogLevel(String newLevel) Your customers, once they have enabled access to the MBeans can then run or view any of the properties listed in the design document Thank you /F. Michael O’Brien From: eclipselink-users-bounces@xxxxxxxxxxx [mailto:eclipselink-users-bounces@xxxxxxxxxxx] On Behalf Of Nathan Drew Hi, Having gone through the process of needing to vary the logging levels for EclipseLink, and thinking of the case when we might have to support a customer using our application and want to get more debug information from them without rebuilding our application from scratch… shouldn’t the JVM property for eclipselink.logging.level override the value set in persistence.xml? That’s the general model in most JEE things - configure in the app, then allow the "deployer" to override values. Was this the case for Toplink Essentials? Kind Regards Nathan |