Top 20 Tips for Developing Applications on BEA WebLogic Server
July 21, 2004
Q: Can you please explain what causes a NoClassDefFoundError?
A: The most common cause of NoClassDefFoundErrors in J2EE servers is classes in
parent classloaders which reference
classes only available in child classloaders; for
instance, a class in the $CLASSPATH which was extending a class only available in a
child classloader. There were further debugging tips in the slides.
Q: If you have a jar in your system/lib folder and a
lso in your WAR, which one
A: By default, Java classloaders are "parent
first," meaning they first ask their parent to
load a class and only attempt to load the class if their parent cannot. So if a class is found
in the $CLASSPATH, it
would be preferred over a class in the application classloader.
There is a WebLogic Server option to set prefer
classes in the weblogic.xml to
have a webapp prefer its war instead of the parent loader. This option should be used
with caution. Wh
ile it has its uses, it can also easily lead to ClassCastExceptions and
other unexpected classloader issues.
Q: How do threads in the thread pool get different classloader hierarchies as they
are assigned to process requests to different applications?
WebLogic Server creates the application classloaders during application deployment.
When the container services a request, it ensures the request is dispatched to the correct
Q: Can I use breakpoints to debug?
A: Yes, BEA's We
bLogic Workshop is a Java debugger that supports breakpoints. Any
other Java debugger or IDE that supports breakpoints should work as well.
Q: Is APP
INF a J2EE standard, or is it a WebLogic Server feature?
INF is a BEA enhancement that has not m
ade it back into the J2EE standard yet.
However, it is easy to use APP
INF and then later port to an older version of WLS or
another server that does not support APP
You could port to an older WLS version by using manifest class
path. I would
mend a build target that produces a portable ear. The build target would generate a
manifest file with manifest class
path entries for each jar file in APP
INF/lib. Then each
J2EE module would need this manifest file.
Q: Where would I find the wlpackage
/wlcompile commands? Are these command
tasks, or are they available from the WebLogic Admin Server Console?
A: wlpackage and wlcompile are ant tasks. The ant task implementations are located in
the weblogic.jar. The ant packaged with the WebLogic p
latform includes a properties
file with all of the BEA taskdefs pre
If you are using a different version of ant, you will need to manually use the taskdefs.
Here are some of the task names and classes defined in BEA's ant properties file:
Q: In developing mode, we need to change a Java class frequently. Once I change it,
do I need to redeploy the whole application?
A: It depends on where the Ja
va class is being loaded. If the class is in the
$CLASSPATH, you'll need to restart the server. If the class is in your application, you
can just redeploy the applicataion. Finally, if the class is located in a webapp, you can
redeploy just the webapp an
d not the whole app.
This is all related to the classloader structure diagram presented in the slides. If you
change something in a parent classloader, you must redeploy everything in the child
classloaders as well.
Q: I tried wlappc before, and it co
mplained that wlappc is not a recognized task.
What am I missing?
A: See above. You aren't using BEA's packaged version of ant, so you will need to
include a taskdef for wlappc. Something like this should work:
Q: Is there an Ant task for stopping WebLogic clusters, e.g., <wlserver>? I need to
stop a particular cluster and redeploy.
A: The wlserver task can be used to stop servers as well. Simply set the action a
Q: Sometimes we get temporary patches from support (CR####.jar). We obviously
put them before weblogic.jar in the server class path. However, if weblogic.jar is in
our application build classpath, do we then have to modify our build
reference this CR jar file, if we reference weblogic.jar in the build?
A: Yes, I would recommend you include patches in your build classpath as well. These
patches may include fixes to tools like weblogic.appc or weblogic.ejbc that might be
ed during your build.
Q: What's the best way to manage/package deployment descriptors to move from
dev (single server) to QA/production (clustered servers)?
A: Typically the challenge here is what we call bindables in the descriptor. For instance,
descriptor might reference http://test:7001, but in production this must be
I'd recommend solving this by including variables in your descriptors and then using a
preprocessor like sed, ant, perl, etc., to replace the variables wi
th the appropriate values.
For instance, you might have $SERVER in your descriptor and use sed to produce a test
descriptor where this was replaced with the test URL.
Q: Do you recommend deploying the Workshop
enabled applications and non
d applications on the same WebLogic domain?
A: Certainly you can run Workshop and non
workshop applications within the same
server or domain. Typically the decision on whether to run many applications on the
same WLS instance or machine depends on the en
user requirements. By separating
applications, you get better isolation at the cost of more servers to manage.
Q: Is co
location the default settings, or are config settings required?
A: There is no default setting per se. Applications are deployed t
o clusters and/or
servers. If you split your application into two separate parts deployed to two tiers, it
would be split. If you deployed a unified app to a single tier, it would be co
Q: Can two different licenses for WebLogic Server be loade
d on one server to create
two different environments with the same domain and port?
A: I’m not sure. I would ask email@example.com about license questions.
Q: Our startup classes use EJBs, so we have to put EJB interfaces in the classpath.
Is there a way t
o avoid this kind of dependency?
A: Server startup classes are called when the server is booted. Application
listeners receive callbacks when their application is deployed. If you can wait until the
application is deployed, you can use an Applicat
ionLifecycleListener or a servlet listener.
These have access to the application classloader and can call EJBs without having any
interfaces in the classpath.
Q: Does WebLogic provide an API/mechanism to perform a task when the last
machine in the cluste
r goes down (normally or abnormally) so that one can do some
A: I'm not aware of an API that informs you when the last machine in a cluster is shut
down. You can get a hook when each server shuts down normally. If a process crashes,
then you d
on't get a hook.
Q: Will JSP be slower and not as memory
efficient because it has to be loaded into a
separate classloader per file? What about a servlet? Which classloader will that be
A: All Servlets in a webapp are loaded by a common classloader.
JSPs are loaded by an
individual classloader whose parent is the webapp classloader.
WLS has been extensively performance
tested, and this JSP/classloader arrangement has
not been a limiting factor. The memory overhead for classloaders is relatively low
Q: If I have an ear file that includes war and EJB jars, do I need to build a new ear
with the changed war when making JSP changes? If so, doesn't that mean it'll
create a new class loader for the webapp and one for jsp?
A: As I mentioned in the talk
, I don't recommend using archived EARs during
development. If you're using the split
directory development system, just edit the jsp file
and hit reload in your browser.
Q: Is split directory not suitable for production purposes?
A: Correct. Split d
irectory is only supported for single
environments. The wlpackage task is used to package the application as a standard EAR
for production or testing.
Q: Do you have any additional tips for developing in a WebLogic cluster
A: I generally recommend that each developer has their own WLS instance. I prefer this
to a shared environment. I believe testing should be done on clustered environments, but
developers can generally work with a single server.
Q: If the beans are rem
ote, does co
location know not to do marshalling and
A: EJBs using local interfaces always get call
reference (like standard java calls.)
EJBs with remote interface get call
value by default.
When the remote caller and callee are co
located within the same WLS instance, remote
calls go through an optimized RMI stack. There is no socket opened, and the RMI stack
avoids marshalling/unmarshalling of immutable types like java.lang.String. Mutable
types will go through Java serialization.