Showing posts with label weblogic. Show all posts
Showing posts with label weblogic. Show all posts

Thursday, April 9, 2015

How to setup remote debug with WebLogic and Eclipse

Setup remote debug with WebLogic and Eclipse

As always there is the clean way, and the one-off way.
We will see how to setup debug for weblogic using the clean way which is to leverage all the built-in items already present but not clear that they are.

<domain>/bin/setDomainEnv.sh has interesting items: 

  • First there is the debugFlag="true"
  • Then there is DEBUG_ PORT="8453"
  • Then you will also see:
JAVA_DEBUG="-Xdebug -Xnoagent -Xrunjdwp:transport=dt_socket,address=${DEBUG_PORT},server=y,suspend=n -Djava.compiler=NONE

So the clean answer lies somewhere between these three. Also while there is the command line option as well (as you can see at the bottom of the setDomainEnv.sh).

Note: In production mode the debug is disabled by default by unsetting the flag. We can however get around this by re-setting the flag after this piece of code.

So here are the steps

Set the debug Flag

After around line number 203 in setDomainEnv.sh add the lines (ignore echo if you don't want the noise). This will also get around the production mode issue mentioned above

Add after this block (around Line 203):
if [ "${PRODUCTION_MODE}" = "true" ] ; then
        debugFlag="false"
        export debugFlag
        testConsoleFlag="false"
        export testConsoleFlag
        iterativeDevFlag="false"
        export iterativeDevFlag
        logErrorsToConsoleFlag="false"
        export logErrorsToConsoleFlag
fi
echo "Setting debug flag"
export debugFlag="true"

If you are not using just the Admin Server:

If your deployment is using a specific managed server, then you can modify the above as:
if [ "${SERVER_NAME}" = "mgdserver1" ] ; then
      echo "Setting debug flag for mgdserver1"
      export debugFlag="true"
fi

If you have to remote debug more than one managed server

The above block also allows you to specify a different port number for this server. And you can duplicate the same block for each of your servers if needed.
if [ "${SERVER_NAME}" = "mgdserver1" ] ; then
      echo "Setting debug flag for mgdserver1 and port to 8454"
      export debugFlag="true"
      export DEBUG_PORT="8454"
fi

Eclipse setup

In Eclipse the setup is simple.
  • Right click on the Project containing the deployed items. Select "Debug as">"Debug Configurations"
  • Locate "Remote Java Application" in the list on the left
  • Create a new configuration with hostname and debug port of the weblogic server


Tuesday, June 4, 2013

WebLogic wlst.sh how to set the JVM args

It is completely, entirely, unbelievable to me that something as simple as this was not clearly documented.

My previous solution was:
Edit:

${WL_HOME}/server/bin/setWLSEnv.sh

And add below the line:
. "${WL_HOME}/common/bin/commEnv.sh"

The following lines:
 
if [ -n "${CUSTOM_WLST_ENV}" ]
then
    if [ -f "${CUSTOM_WLST_ENV}" ]
    then

        . "${CUSTOM_WLST_ENV}"
    fi
fi

Well, guess what? there is a hidden custom script sourcing line exactly but not exactly like what I did. in the setWLSEnv.sh around line 64 there is a line that sources an extEnv.sh.
One big caveat - they expect it to be in the $PATH environment so that it can be invoked by just ". extEnv.sh". I would think this is not ideal, but it is still manageable.

 62 # Import extended environment
 63 
 64 if [ -f extEnv.sh ]; then
 65   . extEnv.sh
 66 fi

Therefore to introduce custom attributes into this mix, you will have to create an extEnv.sh. And then add its directory to the path, and export it such that it precedes all other PATH items:
export PATH= "<extEnv.sh's dir>:$PATH"
Then running wlst.sh should include the extEnv.sh in the above path.
Simplest would be to add the dot "." in the $PATH to indicate current directory and place an extEnv.sh in the current directory. The dot in the PATH in unix'es is not a recommended practice and it is generally a better practice to run scripts explicitly.

Some important variables:
CONFIG_JVM_ARGS: sets JVM args for the java, so all your "-D" properties can go here. Be sure to not wipe out existing ones and use: CONFIG_JVM_ARGS=$CONFIG_JVM_ARGS -D... form so existing values are copied.


-- Old Stuff I am keeping for editing later --

Now you in the calling script or shell you can create an external shell script with the overrides for the values in commEnv.sh

For example add this to: customwlstenv.sh:
 
export MEM_ARGS="-Xms512m -Xmx1024m -XX:PermSize=128m -XX:MaxPermSize=256m"
Then export - note it is important to fully qualify the path so that commEnv.sh can execute it from wherever it is running:
export CUSTOM_WLST_ENV="$PWD/customwlstenv.sh"

If you now run the wlst.sh script it should pick up on the MEM_ARGS and override the ones in commEnv.sh