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 also in your WAR, which one takes precedence?
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-web-inf-classes in the weblogic.xml to have a webapp prefer its war instead of the parent loader. This option should be used with caution. While 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?
A: WebLogic Server creates the application classloaders during application deployment. When the container services a request, it ensures the request is dispatched to the correct application/classloader.
Q: Can I use breakpoints to debug?
A: Yes, BEA's WebLogic 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?
A: APP-INF is a BEA enhancement that has not made 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-INF.
You could port to an older WLS version by using manifest class-path. I would recommend 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-line 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 platform includes a properties file with all of the BEA taskdefs pre-defined.
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:
ddinit=weblogic.ant.taskdefs.ejb.DDInit
wldeploy=weblogic.ant.taskdefs.management.WLDeploy
wlserver=weblogic.ant.taskdefs.management.WLServer
wlconfig=weblogic.ant.taskdefs.management.WLConfig
wlcompile=weblogic.ant.taskdefs.build.WLCompileTask
wlpackage=weblogic.ant.taskdefs.build.WLPackageTask
wlappc=weblogic.ant.taskdefs.j2ee.Appc
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 Java 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 and 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 complained 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.,
A: The wlserver task can be used to stop servers as well. Simply set the action argument to "shutdown".
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 file to 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 called 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, your descriptor might reference http://test:7001, but in production this must be http://production:7001.
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 with 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-Workshop-enabled 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 end-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 to 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-located.
Q: Can two different licenses for WebLogic Server be loaded on one server to create two different environments with the same domain and port?
A: I’m not sure. I would ask support@bea.com about license questions.
Q: Our startup classes use EJBs, so we have to put EJB interfaces in the classpath. Is there a way to avoid this kind of dependency?
A: Server startup classes are called when the server is booted. Application-scoped listeners receive callbacks when their application is deployed. If you can wait until the application is deployed, you can use an ApplicationLifecycleListener 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 cluster goes down (normally or abnormally) so that one can do some clean up?
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 don'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 in?
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 directory is only supported for single-server development 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 environment?
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 remote, does co-location know not to do marshalling and unmarshalling?
A: EJBs using local interfaces always get call-by-reference (like standard java calls.) EJBs with remote interface get call-by-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.
1 comment:
Thank you for sharing
I really like
Post a Comment