Debugging WebLogic Platform Internals </p>

</span></b>

http://weblogic.sys-con.com/node/42733 </p>

</span>

</p>

 

</span>

Note: this article is for WebLogic 6.x,7.x </p>

</span>

clip_image001 </p>

</span>

BY STEVE BUZZARD </p>

</span></strong>

MARCH 27, 2003 12:00 AM EST </p>

</span>

If you’ve ever worked as a Weblogic consultant, chances are this scenario will look all too familiar:
You’re at a high-profile client site as the "BEA WebLogic Expert." You were called in last minute because they are having "intermittent" problems in their newly deployed production system. The problems appear related to the WebLogic (Server/Portal/Integration) subsystem, but you can’t be sure. There is absolutely nothing unusual in the standard output; neither is there anything amiss in the WebLogic server or domain logs.</span></i> </p>

</span>

Despite poring over the docs, newsgroups, dev2dev, and the support site ("Ask BEA"), you still can’t get a handle on the problem. You’ve double and triple checked the client’s code and their WebLogic configuration, and verified that they’re following the specs. You finish off the usual checklist:  </p>

</span></i>

·  Is the OS Patch Level reasonably current (at least to the level required by the JVM used)? </p>

</span></i>

·  How’s the OS environment (file descriptors, TCP parameters, network parameters, ulimit settings, etc.)? </p>

</span></i>

·  Anything really off with JVM version and/or parameters? </p>

</span>

·  Any type-2 JDBC drivers or other native code lurking about that could cause problems? </p>

</span>

No smoking gun here, unfortunately, and the client senior management is beginning to breathe down your neck. You’d fire up your favorite debugger in their QA environment (can you reproduce it there?) in an attempt to track it down, but it’s not really that kind of "bug." It could very well be a product issue, you think.  You check the latest release notes but nothing seems even vaguely related.  Better open up a support case.  You open up t
he case and the support engineer is researching the issue but can find no related CRs, so the odds of a quick fix or workaround are long.  Maybe it’s not a product issue  …
</p>

</span>

Does this provide you with a touch of déja` vu? I’ve run into variations of this scenario countless times and have subsequently uncovered a set of "undocumented" debugging parameters and properties that have helped me track down the source of trouble and saved my hide on more than one occasion. Several of these parameters have been bandied about quite a bit on the various BEA newsgroups, but never specified as a whole. </p>

</span></span>

Warning: The debugging parameters I’m about to describe are undocumented. This means that they are also officially unsupported by BEA and subject to change (or removal) at any time. </p>

</span>

WebLogic Server 5.1
For those who still indulge in 5.1, Table 1 lists its debugging parameters. They are specified as system properties (either on the command line or within the global, cluster, and/or server weblogic.properties files). </p>

</span>

WebLogic Server 6.x/7.x
The WebLogic Server 6.x and 7.x Debugging Parameters are tied to the ServerDebug MBean within the app server’s JMX infrastructure. A WebLogic Domain’s admin server and each associated managed server have a corresponding element within the config.xml file (subordinate to that server’s element). Note that because these parameters are undocumented, you cannot update them using the WebLogic Console but must hand-edit the config.xml file directly. For the uninitiated, the config.xml file holds the configuration for a WebLogic Domain and lives in the domain’s top-level directory for the admin server. Almost all the parameters are of the "true/false" variety (a noted exception is "DebugJAXRPCDebugLevel", which is an integer value greater than 0: the higher the number, the more verbose the output). Be sure that the administration server is not running before you edit the config.xml (otherwise, your changes may get overwritten by the running server). Also be sure that you back up the config.xml file before you begin modifying it so that you have a valid configuration should you "mess up." Note that the debugging parameters I list below are based on 7.0 sp1 and some parameters are not valid in 6.1 (the server will quickly let you know which ones upon start up!). The debug information is printed to the standard output, so ensure that you are not redirecting stdout to /dev/null (as is often the case in a test or production environment). Also, setting these parameters to "true" can result in very verbose output, so flip the debug "switches" judiciously, based on the subsystem you suspect is associated with the problems you’re trying to track down (e.g., if it’s an EJB-related issue, set only the DebugEJB… parameters to "true"; see Listing 1). </p>

</span>

In addition to these JMX-based debugging parameters, there is a set of system properties you can set for additional debugging information that is written to the WebLogic log. Most of the properties are set as such: </p>

</span>

-Dweblogic.Debug=<debug-parameter1,
debug-parameter2,debug-parameter3,…>
</p>

</span>

These debug parameters include: </p>

</span>

IIOP </p>

</span>

·  weblogic.iiop.ots </p>

</span>

·  weblogic.iiop.transport </p>

</span>

·  weblogic.iiop.marshal </p>

</span>

·  weblogic.iiop.startup </p>

</span>

JDBC/Data Sources </p>

</span>

·  weblogic.JDBCConn </p>

</span>

·  weblogic.JDBCSQL </p>

</span>

·  weblogic.JDBCConnStackTrace </p>

</span>

JMX/Deployment </p>

</span>

·  weblogic.commoAdmin </p>

</span>

·  weblogic.commoProxy </p>

</span>

·  weblogic.deployerRuntime </p>

</span>

·  weblogic.MasterDeployer </p>

</span>

·  weblogic.deployTask </p>

</span>

·  weblogic.deployHelper </p>

</span>

·  weblogic.MasterDeployer </p>

</span>

·  weblogic.OamDelta </p>

</span>

·  weblogic.OamVersion </p>

</span>

·  weblogic.slaveDeployer.semaphore </p>

</span>

·  weblogic.slaveDeployer </p>

</span>

·  weblogic.ConfigMBean </p>

</span>

·  weblogic.ConfigMBeanEncrypt </p>

</span>

·  weblogic.ConfigMBeanSetAttribute </p>

</span>

·  weblogic.management.DynamicMBeanImpl </p>

</span>

·  weblogic.management.DynamicMBeanImpl.setget </p>

</span>

·  weblogic.mbeanProxyCache </p>

</span>

·  weblogic.mbeanDelete </p>

</span>

·  weblogic.mbeanQuery </p>

</span>

·  weblogic.MBeanInteropList </p>

</span>

·  weblogic.mbeanProxy </p>

</span>

·  weblogic.registerMBean </p>

</span>

·  weblogic.getMBeanInfo </p>

</span>

·  weblogic.getMBeanAttributes </p>

</span>

·  weblogic.addDependenciesRecursively </p>

</span>

·  weblogic.MBeanListener </p>

</span>

·  weblogic.application </p>

</span>

·  weblogic.deployer </p>

</span>

·  weblogic.appPoller </p>

</span>

·  weblogic.appManager </p>

</span>

·  weblogic.BootstrapServlet </p>

</span>

·  weblogic.fileDistributionServlet </p>

</span>

Application Deployment </p>

</span>

·  weblogic.J2EEApplication </p>

</span>

·  weblogic.applicat
ion </p>

</span>

·  weblogic.appPoller </p>

</span>

·  weblogic.appManager </p>

</span>

JTA </p>

</span>

·  weblogic.JTAGateway </p>

</span>

·  weblogic.JTAGatewayStackTrace </p>

</span>

·  weblogic.JTA2PC </p>

</span>

·  weblogic.JTA2PCStackTrace </p>

</span>

·  weblogic.JTAHealth </p>

</span>

·  weblogic.JTAPropagate </p>

</span>

·  weblogic.JTARecovery </p>

</span>

·  weblogic.JTAXA </p>

</span>

·  weblogic.JTAXAStackTrace </p>

</span>

·  weblogic.JTAResourceHealth </p>

</span>

·  weblogic.JTAMigration </p>

</span>

·  weblogic.JTARecoveryStackTrace </p>

</span>

·  weblogic.JTANaming </p>

</span>

·  weblogic.JTATLOG </p>

</span>

·  weblogic.JTALifecycle </p>

</span>

A concrete example of debugging a TxDataSource problem might be to set the following on your server’s start-up command line: </p>

</span>

-Dweblogic.Debug=weblogic.JDBCConn,
weblogic.JDBCSQL,weblogic.JTA2PC
</p>

</span>

There are also a few other system properties floating around WebLogic Server that are set on the command line:  </p>

</span>

·  Dweblogic.ejb.cache.debug </p>

</span>

·  Dweblogic.ejb.cache.verbose </p>

</span>

·  Dejb.enableCacheDump </p>

</span>

·  Dweblogic.ejb20.cmp.rdbms.debug </p>

</span>

·  Dweblogic.ejb20.cmp.rdbms.verbose </p>

</span>

·  Dweblogic.ejb20.persistence.debug </p>

</span>

·  Dweblogic.ejb20.persistence.verbose </p>

</span>

·  Dweblogic.ejb20.compliance.debug </p>

</span>

·  Dweblogic.ejb20.compliance.verbose </p>

</span>

·  Dweblogic.ejb.deployment.debug </p>

</span>

·  Dweblogic.ejb.deployment.verbose </p>

</span>

·  Dweblogic.ejb20.dd.xml </p>

</span>

·  Dweblogic.ejb.deployer.debug </p>

</span>

·  Dweblogic.ejb.deployer.verbose </p>

</span>

·  Dweblogic.ejb.verbose.deployment </p>

</span>

·  Dweblogic.ejb20.ejbc.debug </p>

</span>

·  Dweblogic.ejb20.ejbc.verbose </p>

</span>

·  Dweblogic.ejb.runtime.debug </p>

</span>

·  Dweblogic.ejb.runtime.verbose </p>

</span>

·  Dweblogic.ejb20.jms.poll.debug </p>

</span>

·  Dweblogic.ejb20.jms.poll.verbose </p>

</span>

·  Dweblogic.ejb20.security.debug </p>

</span>

·  Dweblogic.ejb20.security.verbose </p>

</span>

·  Dweblogic.ejb.locks.debug </p>

</span>

·  Dweblogic.ejb.locks.verbose </p>

</span>

·  Dweblogic.ejb.bean.manager.debug </p>

</span>

·  Dweblogic.ejb.bean.manager.verbose </p>

</span>

·  Dweblogic.ejb.pool.InstancePool.debug </p>

</span>

·  Dweblogic.ejb.pool.InstancePool.verbose </p>

</span>

·  Dweblogic.ejb.swap.debug </p>

</span>

·  Dweblogic.ejb.swap.verbose </p>

</span>

·  Dweblogic.j2ee.dd.xml </p>

</span>

·  Dweblogic.kernel.debug </p>

</span>

WebLogic Portal
WebLogic Portal (both 4.0 and 7.0) uses System Properties to control their debug output. These Portal properties are tied to specific classes and can be set in two different ways: 
1.   Set one or more system properties on the command line. These property names are of the form: </p>

</span>

debug..</span> </p>

</span>

For example, if I want debugging information on the processing of the Entitlements Access Controller class, I’d add the following to my Portal Server start-up command line: </p>

</span>

-Ddebug.com.bea.p13n.entitlements.
accesscontroller.AccessController=true
</p>

</span>

2.   Create a file entitled "debug.properties" in the Portal Server working directory (in 7.0, this is the domain directory; in 4.0, this is the parent of the "config" directory). For each Portal class you desire debug output from, add a line in this file of the form: </p>

</span>

=true.</span> </p>

</span>

For example, if I want debugging information on the Portal Management sub-system, I create a "debug.properties" file with content similar to: </p>

</span>

com.bea.portal.manager.internal.PortalManagerDelegateImpl=true
com.bea.portal.manager.internal.PagePersonalizationImpl=true
com.bea.portal.manager.internal.PortalParser=true
com.bea.portal.manager.internal.PortalPersistenceManager=true
com.bea.portal.manager.internal.PortletParser=true
com.bea.portal.manager.internal.PortletPersistenceManager=true
com.bea.portal.manager.internal.PortletStateImpl=true
com.bea.portal.manager.internal.UserPortalStatePolicy=true
</p>

</span>

WebLogic Integration
WebLogic Integration also uses System Properties to enable debugging information, but the scheme here is less complex (and, some would say, less flexible) than that of Portal. Simply set the following properties on your WLI Server start up command line according to your needs:  </p>

</span>

·  Dwlc.debug.signature=true </p>

</span>

·  Deci.repository.helper.debug=true </p>

</span>

·  Dwli.bpm.client.security.debug=true </p>

</span>

·  Dwli.bpm.studio.timeprocessor.debug=true </p>

</span>

·  Dwli.bpm.studio.debug=true </p>

</span>

·  Dwli.bpm.server.common.timedevent.debug=true </p>

</span>

·  Dwli.bpm.server.common.xmltemplate.debug=true </p>

</span>

·  Dwli.bpm.server.eventprocessor.addrmsgdebug=true </p>

</span>

·  Dwli.bpm.server.eventprocessor.debug=true </p>

</span>

·  Dwli.bpm.server.jms.debug=true </p>

</span>

·  Dwli.bpm.server.plugin.debug=true </p>

</span>

·  Dwli.bpm.server.workflow.debug=true </p>

</span>

·  Dwli.bpm.server.businesscalendar.debug=true </p>

</span>

·  Dwli.bpm.server.busop.debug=true </p>

</span>

·  Dwli.bpm.server.workflow.action.taskduedate.debug=true </p>

</span>

·  Dwli.bpm.server.workflow.timedevent.debug=true </p>

</span>

·  Dwli.bpm.server.xml.debug=true </p>

</span>

·  Dwli.bpm.server.xslt.debug=true </p>

</span>

·  Dwli.bpm.server.workflow.start.debug=true </p>

</span>

·  Dwli.bpm.server.workflowprocessor.debug=true </p>

</span>

·  Dwli.common.server.errorlistener.debug=true </p>

</span>

Summary
These debugging parameters can be of great help (BEA Support often recommends trying out particular debugging parameters to help track down specific issues) and can also aid in your understanding of how the WebLogic Server, Portal, and Integration internals operate (which in turn sharpens your troubleshooting skills). Although they are official undocumented and unsupported (who needs real "support" for a debug property?), they can truly be a lifesaver. </p>

</span>

© 2008 SYS-CON Media Inc. </p>

</span>

</p>

 

</span>

转载请注明:WebLogic Android 博客 » Debugging WebLogic 6.x 7.x Platform Internals[forward]