 | Level: Intermediate Rick Robinson, IBM Software Services for WebSphere, IBM United Kingdom
19 Jun 2002 One of the trickier parts of developing enterprise Java applications is managing class visibility and class sharing across multiple Web modules, EJB modules, and JAR files. This in-depth article takes you through the classloader visibility options available in WebSphere Studio and WebSphere Application Server, and tells you how to select and implement them in order to simplify your applications and ensure compatibility with J2EE specifications.
Introduction and summary of recommendations This article describes the behavior of the classloader visibility
options available in IBM ® WebSphere® Application Server (hereafter called WebSphere),
and makes recommendations that simplify their use. Some techniques are provided
to make working with the classloaders easier, particularly when using WebSphere
Studio Application Developer (hereafter called WebSphere Studio, as these techniques
also apply to other WebSphere Studio configurations). The main recommendations are:
- Whenever possible, do not use Module visibility, as it can be complex,
difficult to deploy to, and is deprecated in WebSphere 4.03.
- Do use the new J2EE Application visibility provided in WebSphere
4.03, as it conforms to the J2EE 1.3 specification, and is therefore the
least likely to change in the future. Adopting this visibility now will simplify
migration to WebSphere Version 5.
- If you are working with WebSphere 4.02 or earlier and unable to upgrade
at this time, use Application visibility instead.
The discussion below includes these additional recommendations:
- Think carefully about how you implement the Singleton pattern, as
the behavior of the classic implementation is complex in an environment with
multiple JVMs and classloaders.
- If you use the Zip Creation Utility (see References)
to link non-J2EE JavaTM projects in WebSphere Studio with JAR files deployed
in enterprise application EAR files, specify a build path separate from the
source folders in the workspace. This avoids exporting source code into your
deployable application.
The topics covered are:
- WebSphere classloader settings and their evolution
- Which classloader setting should you choose?
- How and when should you implement the Singleton pattern in a J2EE application?
- How to specify interdependencies between application modules
- Upgrading the WebSphere Studio 4.03 Test Environment to WebSphere 4.03
- Creating JAR files Using WebSphere Studio and the Zip Creation Utility
What is a modular application? For the purposes of this article, modular J2EE applications:
- Contain web modules and/or EJB modules.
- Also contain one or more JAR files, which in turn contain common application
code or utility classes.
Some of these JAR files may be provided by third parties (such
as reporting utilities or Struts). Often, there are dependencies between
multiple JAR files in the same enterprise application. This article uses the
term utility JAR to mean a JAR file deployed within the .EAR file itself
(as opposed to the WEB-INF/lib directory of
a Web module, for example), and referenced by Web or EJB modules. The term JAR
file or just JAR refers to JAR files in general. References To make the most of this article, see also the following resources
on WebSphere Developer Domain: Software prerequisites
- Download the
WebSphere Studio Zip Creation plug-in if you haven't already done so.
- Both WebSphere Application Server and WebSphere Studio should be at Version
4.0.3 or later, or if this is not practical, then at least Version 4.0.2.
Previous levels do not have important fixes that allow the development and
execution of modular applications.
- WebSphere Studio version 4.03 does not provide a WebSphere Application
Server 4.03 Test Environment unless you specifically apply the WebSphere Application
Server Advanced Single Server Edition PTF 3 to the Test Environment plug-in
in WebSphere Studio. This paper shows you how to perform the required upgrade.
WebSphere classloader options and their evolution WebSphere Version 4 originally offered four classloader options:
- Server visibility provided a single classpath across all classloaders
in the entire application server -- all the classes in all the enterprise applications
could reference each other, however they were deployed.
- Compatibility visibility was provided to emulate the classloader
arrangements of WebSphere 3.5.
- Application visibility allowed all the classloaders within a single
enterprise application to reference each other. So, within each enterprise
application, classes deployed in any utility JAR or module could reference
classes deployed in any other utility JAR or module.
- Module visibility provided a separate classloader for each web or
EJB module in the Enterprise Application, and enforced a separate classpath
for each classloader. So, classes deployed in one utility JAR or module could
not reference classes deployed in any other utility JAR or module, unless
Manifest classpath entries were used to specify the dependency. These dependencies
could only be specified within a single enterprise application.
PTF 3 for WebSphere 4.0 (or 4.0.3) changed the behavior of
all the classloader settings. The recommendations in this article are intended
to avoid dependence on any aspect of the class loader behavior that changed
in PTF3, or that may change in the future. In particular, PTF3 added a new,
recommended setting: new J2EE Application mode visibility. Figure 1 below
shows a description of this setting, taken from the PTF3 release notes in the
WebSphere InfoCenter.
Figure 1. Classloader visibility changes in WebSphere 4.03
The new J2EE Application visibility setting is consistent
with Section 6.2.4.8 of the J2EE 1.3 Specification, Context Class Loader. The
system property configuration to enable this visibility is shown in Figure 2
below, which depicts the JVM Settings tab of the application server properties
in the WebSphere Application Server, Advanced Edition Administrator's Console.
This setting overrides any Module Visibility setting you specify in the General
tab of the Application Server properties.
Figure 2. Specifying new J2EE Application Visibility in WebSphere Application Server Advanced Edition
Which classloader setting should you choose?
- Do not use Server visibility -- it can result in hard-to-manage dependencies
between code in multiple applications -- see J2EE Packaging and Common Code
by Keys Botzum in the references above for discussion of problems relating
to sharing common code among multiple applications.
- Do not use Module visibility -- it can be too difficult to configure,
has been deprecated in WebSphere 4.0.3, and the behavior of its classloaders
is more complex than originally documented. See below for discussion.
- Do not use Compatibility visibility -- it is provided for backwards
compatibility, based on WebSphere 3.5 rather than the J2EE deployment model, and may be deprecated in future.
- Unless you are constrained to the WebSphere 4.0.2 run time, do not use
Application visibility -- it is not as recommended by the future J2EE
1.3 specification, and so may change or be deprecated in future.
- Do use new J2EE application visibility -- it is relatively simple,
and in line with the future J2EE 1.3 specification, and so less likely to
change. It is likely to provide your application with the maximum portability across J2EE application servers.
At this point it helps to clarify some differences between
Application visibility and new J2EE Application visibility in PTF3.
- Application visibility now provides a single classloader across all
web and EJB modules. All classes are shared across all modules.
- New J2EE Application visibility provides a separate classloader for
each Web module, and a shared classloader for all utility JAR files and EJB
modules.
- All Web modules can reference classes in all utility JAR files and EJB
modules.
- EJB modules can reference classes in all utility JAR files, but cannot
reference classes in Web modules.
- Classes in one Web module cannot reference classes in other Web modules.
To strengthen the recommendations, let's look at some of the
requirements you might have that appear to lead to one of the classloader visibilities
not recommended above. In many cases, the best answer is to stick with
new J2EE Application visibility. In particular, we'll address the differences
between Application visibility, new J2EE Application visibility, and Module visibility. Does the J2EE 1.2 specification recommend Module visibility? The J2EE 1.2 specification does not make any recommendations
on this topic. The J2EE 1.3 specification recommends the behavior found in
the new J2EE Application visibility setting. The original WebSphere
Version 4 documentation did recommend Module visibility, but that has changed
with the Release Notes for WebSphere 4.0.3. Why might you want to use Server visibility? If you have Web modules, EJB modules, or JAR files used by multiple applications,
you might want to simplify the deployment configuration by using Server visibility,
and deploying them once, in a single enterprise application on which other enterprise
applications depend. Some examples of modules and JAR files that you might want
to use in this way are:
- Infrastructure components, such as JMS drivers
- Third-party utilities, such as Struts, Log4J
- Bespoke utilities, such as command frameworks, common data objects
- An EJB module containing Entity EJBs representing common elements of the
business data model
However, this often leads to complications. For example, what
happens when one application requires a new version of one of the modules or
JAR files, but another application is unable to run a regression test against
the upgrade? For JAR files, it is often better to deploy them as utility
JARs within each enterprise application EAR file that needs them. Similarly,
you could consider deploying common EJB modules, or at least the associated
client stubs, in each enterprise application that uses them. This lets you manage
more than one version of the common code in the run time -- while there are
issues associated with managing multiple versions, this approach at least gives
you some flexibility. For JAR files that you do want to deploy once for use by multiple
applications, WebSphere provides the application extensions and runtime
extensions classpaths as an alternative to Server visibility. These
issues relate to hosting multiple applications on a single WebSphere server.
If you will only ever host a single application on each server, they may not
arise. However, this sort of rule is difficult to enforce in anything other
than the short term, and following the alternatives suggested above will produce
a more flexible, portable, and cleanly packaged application. For further discussion and advice, see J2EE Packaging and
Common Code, and Section 6.4.1, Setting Classpaths, in the WebSphere InfoCenter,
both included in References above. Why might you want to use Compatibility visibility? If you're running a WebSphere 3.5 application, or an application developed
in VisualAge® for Java Version 4, you'll need to run with Compatibility visibility.
However, this setting is now substantially similar to Application visibility
or new J2EE Application visibility, so you should consider migrating. In any
case, you should be planning to migrate away from any reliance on WebSphere
3.5 compatibility. Why might you want to use Application visibility? You may already be using Application visibility, in which
case you should get along fine for now. If you can apply PTF3 or use WebSphere
4.0.3, it's worth planning a migration to new J2EE Application visibility to
minimize the impact of any future changes. As described above, the main difference between Application
visibility and new J2EE Application visibility is that Application visibility
lets classes in EJB modules reference classes in Web modules, and classes in
one Web module reference classes in another Web module. If you need to do this,
you will need to use Application visibility. However, a better approach is to
consider restructuring your application to avoid the requirement. To illustrate this, suppose that your application needs to
display weather reports in various cities. This information is expensive to
retrieve from the data source, so you cache it in memory. The information is
required both by a servlet common to several Web sites that display a full weather
report, and by other servlets that display just the temperature as part of some
other content. So, you might deploy a WeatherReportServlet and WeatherReportCache
in one Web module, and your other servlets in different Web modules. Servlets
in any Web module can reference the WeatherReportCache class to access the data
they need. However, some points suggest a better arrangement of the code and
remove the need to use Application visibility.
- The shared code is not a servlet, it is just a class, so it can be deployed
in a utility JAR instead. This also makes the code accessible to any EJB modules
that might require it.
- So, the only reason to use Application visibility is if a servlet class
needs to be referenced by an EJB module or a servlet in another Web module.
However, neither of these references is really desirable:
- The intention of EJB components is to be independent as far as possible
from the client type (Web application, thick client, and so on). They
should not depend on specific client classes.
- The Servlet 2.2 specification prohibits servlets in any Web module from
sharing information in HTTPSession with servlets in other Web modules.
This makes it very difficult in practice to build a closely-coupled Web
application from servlets in multiple Web modules. It is better to view
each Web module as a standalone Web application. So, it's not a good idea
to introduce run-time code dependencies between Web modules.
Therefore we recommend that you remove run-time dependencies between EJB modules
and Web modules, and between multiple Web modules. Instead, deploy common code
in JAR files in the enterprise application. This will also enable your application
to run in new J2EE Application visibility. Why might you want to use Module visibility? If you have an EJB module and a Web module in the same EAR
file that need to reference different versions of the same classes, you might
want to run with Module visibility. However, changes to Module visibility in
PTF3 described below mean that this will not work. If more than one module in your application uses a utility
JAR that contains a singleton class, and both need to use an independent copy
of the singleton, you might want to run with Module visibility. However, as
described below, this does not work consistently in practice, particularly across
fixpak levels. The discussion below describes why Module visibility does
not address either of these requirements:
- If a class is deployed in and loaded by the Web or EJB modules, the class
and any singleton instance are specific to the module. This lets you deploy
separate copies of the same class, or provide separate instances of the same
singleton class.
- Until PTF3: If a class is deployed in a utility JAR used by only one
module: It is loaded by the module classloader, and is specific to the module.
This lets you deploy separate versions of the same class, or provide separate
instances of the same singleton class.
- Until PTF3: if a class is deployed in a utility JAR used by more than
one module: WebSphere creates an additional dependency classloader,
and the class is specific to this. This classloader is accessed by all modules
dependent on the utility JAR file, so the class and any singleton instances
are shared across all modules.
- After PTF3: All utility JAR files are loaded by the EJB/dependency
classloader. So, any class or singleton instance deployed in any utility JAR
is shared across all modules.
The behavior is depicted in Figures 3, 4, and 5. In the example, an enterprise
application is shown containing a single Web and a single EJB module. The Web
module uses the WebUtility.jar and SharedUtility.jar
archives; the EJB module uses the EJBUtility.jar
and SharedUtility.jar archives. Before PTF3, it can be seen that WebUtility.jar
is loaded by the Web module classloader, and EJBUtility.jar
is loaded by the EJB module classloader. However, SharedUtility.jar
is used by both modules, and is loaded by the dependency classloader. Therefore,
classes in SharedUtility.jar cannot reference
classes in WebUtility.jar, EJBUtility.jar,
the Web module, or the EJB module, and classes and instances in SharedUtility.jar
are shared between the Web and EJB Modules. After PTF3, it can be seen that all utility JAR files are
loaded by the EJB module Classloader. Therefore, classes and instances in
all utility JAR files are shared between the Web and EJB modules.
Figure 3. Sample modular application
Figure 4. Classloader behavior in Module visibility until PTF3
Figure 5. Classloader behavior in Module visibility after PTF3
The results are threefold:
- Module visibility does not fulfill these requirements in any simple manner.
- The behavior of the classloaders might change in future, so their detailed
behavior cannot be relied on.
- The complexity of this behavior means that only the most experienced Java
developers are likely to be comfortable with it. Such complexity is generally
not warranted -- it is better to find alternative, simpler approaches.
How and when should you implement the singleton pattern in a J2EE application? The previous section described how the behavior of singletons
depends on the precise arrangement of classpaths, and that this is liable to
change. So, it is very difficult to be sure of the scope within which the singleton
pattern guarantees a single instance. The implications of this for the role of the singleton pattern
in J2EE application design are:
- If you require a basic cache for common data or services, and are concerned
with minimizing the number of copies rather than ensuring that there
is only one, then a classic singleton implementation is still viable as there
will be a small number of instances per JVM. The exact number will depend
on the arrangement of the classloaders and their usage patterns.
- If you require a real, application scope single instance (that is,
not any J2EE or WebSphere usage of the word application, but your entire
customer information system or whatever), then a classic singleton
is not the answer -- even if there is only one instance per JVM, there will
be more than one JVM if you clone your application server. Probably the only
thing you can guarantee to be unique across the whole application is a row
in a database table -- so you might consider an Entity EJB and a single-valued
primary key instead.
- If you have a component that needs a number of instances defined at some
more granular level, then this granularity will either be defined in terms
of your application as a whole, or represent a more sophisticated form of
cache. In the former case, you might again consider an Entity EJB, this time
with a small, controlled number of primary keys. In the latter case, you could
extend the classic singleton implementation.
- There are more sophisticated problems related particularly to read/write
caches that are beyond the scope of this article, but this discussion should
at least have highlighted some issues that distributed J2EE applications introduce
to them.
Another way of looking at the Entity EJB solution is that
it is an alternative implementation of the singleton pattern: instead of using
class variables to provide universal scope, a database is used, and control
over the number of instances is provided by the ejbCreate()
method rather than a private constructor.
How to specify interdependencies between application modules The techniques to configure the run-time classloader dependencies
depend on whether the run time uses new J2EE Application, Application
or Module visibility, and are covered separately. This section applies
to WebSphere Studio, but should contain useful guidance for all WebSphere users. New J2EE application visibility configuration The Edit Module Dependencies facility in WebSphere Studio
should be used to configure MANIFEST.MF Class-Path entries of the Web and EJB
modules to explicitly indicate dependences on all the utility JAR files that
their code eventually uses. Application visibility configuration For this visibility, use the same process as for New J2EE application
visibility. Module visibility configuration Take the following steps:
- Using Edit Module Dependencies for the Web module, specify:
- The EJB module.
- Any utility JAR files that are directly referenced by the Web module.
- Using Edit Module Dependencies for the EJB module, specify:
- Any utility JAR files that are directly referenced by the EJB module.
- The JAR manifest extensions feature is needed to allow each individual
utility JAR to specify dependencies on other utility JAR files. This cannot
be specified at the Web or EJB module level using Edit Module Dependencies.
The manifest extensions feature works as follows:
- When the classloader loads any class from a JAR file, it looks in the
META-INF\MANIFEST.MF
file of the JAR for a Class-Path setting. Any entries specified there are
added to the classpath for classes loaded from the JAR file.
- The Class-Path setting is a space-delimited list of relative path names
of other JAR files. The path names are interpreted relative to the root of
the EAR file.
For example, consider an EAR file that contains:
utilityA.jarutilityB.jarextras\utilityC.jar If utilityA.jar depends on
both utilityB.jar and utilityC.jar,
then the MANIFEST.MF file of utilityA.jar
should look like this: ----- START ----
Manifest-Version: 1.0
Class-Path: utilityB.jar extras\utilityC.jar
------ END ------ |
Notes:
- Filenames are case sensitive.
- Manifest-Version and Class-Path should appear on separate lines.
- It is vital that one new line appears after the final entry in the Class-Path
setting. Without it, two things happen:
- The WebSphere Test Environment in WebSphere Studio will not recognize
the settings.
- When the Enterprise Application is exported as an EAR file, the Class-Path
setting in the manifest file will be lost.
So, how do we create the MANIFEST.MF file in WebSphere Studio?
- In the root of the Java project representing the utility JAR, create a
directory
META-INF and a file in that directory
MANIFEST.MF. Make sure all uppercase characters are used.
- Edit the
MANIFEST.MF file, and add the
Class-Path: setting as above, being careful to add one new line at the end.
- WebSphere Studio maps this file to the Java output directory, and the Zip
creation utility adds it to the utility JAR file.
- Repeat the process for all utility JAR files until all dependencies are
mapped.
Figure 6. Creating the MANIFEST.MF for a Java Project in WebSphere
Studio
It is interesting to note that this technique works for all
the classloader visibility settings. However, it is more complex than the simpler
techniques previously described for new J2EE Application visibility and
Application visibility. This is another indication that Module visibility
is too complex to use in practice. If you investigate the archive using WinZip, you may not see
the MANIFEST.MF file, because by default, WinZip
ignores files with all uppercase filenames. To change this behavior:
- Open WinZip and go to Options and Configuration.
- Check Allow all uppercase filenames.
Upgrading the WebSphere Studio Test Environment to WebSphere 4.03 WebSphere Studio 4.03 provides a WebSphere Test Environment at level 4.02,
not 4.03. In order to upgrade the test environment to level 4.03, and so be
able to test applications using new J2EE Application visibility, follow
the steps below. (These steps are for WebSphere Studio on Windows®.)
- Download PTF3
for WebSphere Application Server Advanced Single Server Edition.
Select the download package for your platform marked AEs not AE.
- Extract the fixpak from its ZIP file into a temporary directory.
- Close WebSphere Studio.
- Make a note of the WebSphere Studio installation directory.
- Create a temporary directory for the PTF installation logs and make a note
of it. Create subdirectories called Backup, Logs, and Temp within this directory.
- You now need to configure the application server fixpak to run in silent
mode. To do this, either follow the fixpak installation guide, or create a
.bat file in the temporary directory where you extracted the fixpak, and add the following commands to it:
set WS_HOME=<Enter the WebSphere studio installation directory here>
set LOG_HOME=
<Enter your temporary directory for the PTF installation logs here>
set WAS_UPDATE_HOME=%WS_HOME%\plugins\com.ibm.etools.websphere.runtime
set JDK_UPDATE_HOME=%WS_HOME%\plugins\com.ibm.etools.server.jdk
set BACKUP_DIR=%LOG_HOME%\Backup
set LOGS_DIR=%LOG_HOME%\Logs
set TMP=%LOG_HOME%\Temp |
The file I used looks like this: set WS_HOME=D:\Programs\WebSphere\WS
set LOG_HOME=D:\Programs\WebSphere\Install\WAS403WS
set WAS_UPDATE_HOME=%WS_HOME%\plugins\com.ibm.etools.websphere.runtime
set JDK_UPDATE_HOME=%WS_HOME%\plugins\com.ibm.etools.server.jdk
set BACKUP_DIR=%LOG_HOME%\Backup
set LOGS_DIR=%LOG_HOME%\Logs
set TMP=%LOG_HOME%\Temp |
From a command prompt in the directory containing the fixpak,
run the .bat file. Then run the fixpak installation
in silent mode using the command install.bat -silent.
The fixpak installation will upgrade the WebSphere Studio Test Environment to
level 4.03. In order to configure the upgraded test environment in WebSphere
Studio, add the system property com.ibm.ws.classloader.J2EEApplicationMode
as described in the PTF3 Release Notes. To do this, open the server instance
editor for the Test Environment, and add the system property on the Environments
tab, as shown in Figure 7 below. As with WebSphere Application Server, this system property
will override whatever classloader visibility option you specify in the Module
Visibility setting of the Test Environment Configuration Editor.
Figure 7. Specifying new J2EE application visibility in the
WebSphere Studio Test Environment
Creating JAR files using WebSphere Studio with the Zip Creation utility The WebSphere Studio plug-in referenced in the background
reading provides a facility to associate a Java Project with a JAR file contained
in an Enterprise Application Project or EAR file. This tool automatically updates
the JAR file within your Enterprise Application Project whenever the associated
Java project is updated. The JAR file can then be specified as a run-time and
compile-time dependency for the Web and EJB modules through the Edit Module
Dependencies wizard. By default, this plug-in uses the contents of the Java Project
Build output folder. This default is specified by the Include Java Output Folder
check box in the Zip Creation section of the Java Project properties. However,
by default, the Build output folder of a Java project is the Java project root,
so both source and compiled code are mapped to the generated JAR. As a result,
when the Enterprise Application EAR file is exported, this source code is also
exported (whether or not the Export source files option is checked in
the EAR export wizard). This can cause compilation errors at run time if JSPs
reference classes in the utility JAR file. The solution is to ensure that the project has a separate
build path from the source folders:
- Right-click on the Java Project root folder and select New => Folder.
Call this something like classes to indicate it is intended to contain the
compiled code.
- Open the Java Build Path page of the Java Project properties. Specify the
new folder as the Build output folder.
- Accept the default settings for the Zip Creation properties of the Java
project.
Figure 8. Specifying a build output folder for a Java project
in WebSphere Studio
The utility JAR files will now contain only compiled code.
Conclusion This article discussed some key issues surrounding the use
of the classloader visibility options in WebSphere Application Server Version
4 or later. It also discussed the very useful Zip creation utility, and the
implementation of singleton patterns in an environment with multiple JVMs and
classloaders. We hope you have a deeper understanding of the complex WebSphere
Application Server classloader structure, and the reasons why nearly all applications
should consider only the new J2EE Application visibility or Application
visibility options. The other classloader options, particularly Module
visibility, are simply too complex for practical use. In addition, the J2EE
1.3 specification gives a clear statement of direction for all application
servers, and choosing new J2EE Application visibility now will put you in a good position to move forward. Acknowledgements Thanks to Tom Alcott, Keys Botzum, Dave Artus, Alexandre Polozoff,
and Paul Gover for reviewing and contributing comments to this article. Thanks
also to Gary Martin for information on updating the WebSphere Studio Test Environment to Version 4.03.
Questions from users Question 1
Great info. One question -- if I already downloaded and installed WebSphere Application Server
Enterprise Edition 4.1, should I still install the package? Also, the article states that this PTF3 (FixPak3) fixes the server within
WebSphere Studio Application Developer to support J2EE 1.3. Is this fix also for WebSphere Application Server? Please clarify. Thanks for
your help, Igor Livshin? Response from author
If by "package" you mean the Zip creation utility, then yes, go ahead and install it.
Regarding the PTF3 Fixpak:
- PTF3 does not upgrade either WebSphere Studio Application Developer or WebSphere Application Server to J2EE 1.3 --
the article doesn't say this.
- PTF3 does upgrade WebSphere Application Server, including important changes to classloader behavior.
- One of the key points the article makes is that it is important that the classloaders in the development environment
(WebSphere Studio Application Developer) behave the same way as those in the run time (WebSphere Application Server).
So, after you've applied PTF3 to WebSphere Application Server, you need a way of applying the same changes
to the test environment in WebSphere Studio Application Developer
- There is no fixpak available specifically to do this for WebSphere Studio Application Developer. However, because the test environment
is an embedded version of WebSphere Application Server, you can apply the WebSphere Application Server PTF3
to WebSphere Studio Application Developer. That's what the article describes.
- The above points remain true if you have WebSphere Application Server Enterprise Edition 4.1.
Question 2
A question on the Zip Creation utility. The problem we've found with separating source and compiled code
in the utility project is that it's then difficult to debug from within the project(s) that use the JAR-ed code. Stepping into code
in a JAR requires that the source be in a JAR as well -- you can't simply point the debugger to the source within the workspace.
Any good way around this? Thanks. Response from author
The answer is that there is no easy way around this issue --
either you have source code in the JAR and can see it in the debugger, or you don't have it in the JAR and can't see it.
The approach I have started using is to begin with the source and compiled code in the same directory
-- .java and .class files together, meaning you get the source in the JAR and can debug. Once the code is stable,
I change the build output folder, delete the .class files from the source directory, and rebuild the project,
removing the source from the JAR file. It's all a bit manual, but it's the easiest way I know --
and you're still avoiding the need to continuously export and re-import the JAR file. Question 3
Thanks for a good article. I have some EJBs that are used by several applications. I want to deploy
them in one EAR file and then use the remote interface in other EAR files. I also have some common classes passed to and from the EJBs. The
only way I have been able to make this work is by deploying the common classes in the websphere/lib/app directory. But I would much rather
have the common class JAR in each of the EAR files, which works fine if the EJB EAR ear file is deployed on one server and the applications
on another. Is it possible to make this also work on one server -- all EAR files under one JVM? -- Thanks, Michael Schoning Response from author
The problem described here -- sharing common classes between two EJB JARs
in the same JVM -- is a known one. The particular issue is that the ORB in the JVM has difficulty with the calls between EJB
JARs if more than one classloader has loaded a common class -- as happens in this scenario. To fix this, set the system property: com.ibm.ws.classloader.classSharing=true |
This setting allows the ORB to share those classes that are common between the two modules.
You should be at WebSphere Application Server V4.0.4 (i.e. with PTF4) or later before using this setting.
WebSphere V5 does not have this problem. Question 4
I was hoping this article would explain how the classloader policy can be configured in WebSphere
V4.0.3 so an application-specific JAR can be used in preference to the run-time version, namely xerces.jar. I am having version conflicts on
this front and the Web info suggests using the PARENT_LAST classloader mode, which appears to be WebSphere V5 only. Can this be done in
WebSphere V4.0.3? Help urgently needed. Response from author
There are two answers to this question, depending on the precise meaning of
"application-specific." If "application-specific" means "I want to override a WebSphere provided JAR for all applications
on my server," then the Application Extensions (AEX) classpath, is the one to use.
It's described in the InfoCenter -- search on "classloader" and look for the topic "Setting classpaths."
On the other hand, if "application-specific" means "I want to override it for only one application,"
I'm not sure you can to do this in V4, but it would be worth raising the issue with
IBM support.
For further information on this question, see also References above. Question 5
This is the best article I have seen on classloading in WebSphere Studio. However, the solutions
offered do not solve a J2EE classloading problem I continue to have. I am using WebSphere Studio Application Developer AEs V4.0.3 ptf30217.01
and WebSphere Application Server AE V4.0.4 ptf40230.02. Classes that load fine during development throw errors
when run on WebSphere Application Server. Can you possibly offer some advice? Thanks. Response from author
I would need more information to fully diagnose this problem,
so you may want to raise the issue with IBM support.
In the meantime, here are some suggestions:
- Check that both WebSphere Application Server and the WebSphere Studio Test Environment have the same classloader visibility setting,
preferably J2EE application. (The defaults for the two products are different.)
- Use the instructions in my article to upgrade the WebSphere Studio Test Environment to PTF4 (the same level as the run time).
- Check exactly which classes have problems.
- If a class cast exception is being thrown, Java is trying to cast an object of type A into type B. Add some logging code
to the application to confirm what both types are, and then run in both WebSphere Application Server and WebSphere Studio
to find the difference.
Top of page
About the author | | | Rick Robinson is an Application Development Associate
for WebSphere Software Services in IBM United Kingdom. You can reach him at
rick_robinson@uk.ibm.com. |
Rate this page
| |
