in black and white
Main menu
Share a book About us Home
Biology Business Chemistry Computers Culture Economics Fiction Games Guide History Management Mathematical Medicine Mental Fitnes Physics Psychology Scince Sport Technics

More Java Pitfalls Share Reactor - Daconta M,C.

Daconta M,C. More Java Pitfalls Share Reactor - Wiley publishing, 2003. - 476 p.
ISBN: 0-471-23751-5
Download (direct link): morejavapitfallssharereactor2003.pdf
Previous << 1 .. 39 40 41 42 43 44 < 45 > 46 47 48 49 50 51 .. 166 >> Next

Figure 13.1 shows the architecture of the Java Extension Mechanism. There are sets of classes that make up the core system classes, and developers can provide the ability to add their own classes into the Java Runtime Environment. These are called "optional packages" (formerly known as "standard extensions").
The Failure to Execute 111
We should note that in our previous example, there were references to three optional packages: jaxp.jar, xerces.jar, and xalan.jar. When the executable JAR file shown in that example is executed, the Java Runtime Environment knows to look in those JAR files for classes needed to execute the application. It should be noted that it checks those only if they are not already available in the system class loader; therefore, redundant references to JAR files are not a problem. Class loading from the JAR files is lazy, or as needed.
Sealed Packages
Developers can choose to seal their optional packages. The purpose of sealing a package is to ensure consistency among versions of a particular JAR file. When a package is sealed, it means that every class defined in this JAR must originate from this JAR. Therefore, a sealed Xerces package would assume precedence over other xerces.jar files. This can cut both ways, and it requires that developers are cognizant of which of the optional packages may be controlling the loading of classes.
A perfect example of this is when it becomes necessary to change the order in which JAR files are placed in the CLASSPATH. If a sealed package is loaded first, and then a
112 Item 14
newer version is loaded later in the sequence, the newer version will not be used; in fact, ClassNotFoundExceptions and ClassCastExceptions are common symptoms. Tomcat 3.x versions are known to have this problem in regard to XML. It should be noted that this is addressed in another pitfall regarding the endorsed standards override mechanism.
Listing 13.2 gives an example of the Java Versioning Specification combined with the optional package sealing mechanism.
01 Name: org/javapitfalls/
02 Sealed: true
03 Extension-List: ThisClass ThatClass
04 ThisClass-Extension-Name: org.javapitfalls.ThisClass
05 ThisClass-Specification-Version: 1.2
06 ThisClass-Implementation-Version: 1.2
07 ThisClass-Implementation-Vendor-Id: org.javapitfalls
08 ThisClass-Implementation-URL:
09 ThatClass-Extension-Name: org.javapitfalls.ThatClass
10 ThatClass-Specification-Version: 1.2
11 ThatClass-Implementation-Version: 1.2
12 ThatClass-Implementation-Vendor-Id: org.javapitfalls
13 ThatClass-Implementation-URL:
Listing 13.2 Versioning and sealing an optional package
This shows that any files in the org.javapitfalls package will be sealed—that is, they must all come from this JAR file. The rest shows the appropriate information to allow ClassLoaders to understand the versioning of extensions. The Plug-in is an example of an application that will use this to determine the need to download this version of the package.
These installed optional packages are restricted to the sandbox unless they are from a trusted source. This requires a signing of the JAR file and appropriate permissions being handled in the Java security policy for the application that uses the extension.
Executable JAR files, CLASSPATHs, JAR conflicts—these are all things that challenge developers as they deploy their Java applications. Frequently, developers run into problems because of inadequate understanding of the Java extension mechanism. This pitfall costs a developer time and effort and can lead to substantial configuration control issues.
Item 14: What Do You Collect?
We are building a system that provides a "virtual file cabinet" to browse articles available all over the World Wide Web. The Web site provides a hierarchical format that organizes
What Do You Collect? 113
knowledge for visibility. The topics can be nested inside each other to go as deeply as the content organizer desires. Each topic maps over to one or more categories. Furthermore, a category can appear in multiple topics. This scenario might seem a bit confused, but it is based on a real system. Essentially, the topics refer to how the Web site wants to organize content, and the categories refer to how content syndicates tag their documents.
As the folders are opened, subfolders are displayed below it on the tree, and the appropriate documents for the categories are displayed in the right pane. Users can browse down the hierarchy to view the data that they want.
This whole logic is based on an XML file that maintains the nesting of topics and mappings to categories. Listing 14.1 shows an excerpt of the XML document that the Web site uses.
01 <?xml version = "1.0" encoding = "UTF-8"?>
02 <navigation>
03 <taxonomy text = "Donnie's Subscription Service" value = "default">
04 <topic value = "1" text = "Computer Technology News">
05 <topic value = "3" text = "Software Technology">
Previous << 1 .. 39 40 41 42 43 44 < 45 > 46 47 48 49 50 51 .. 166 >> Next