Developing exteNd Director Applications
CHAPTER 3
You can change your exteNd Director EAR or WAR by:
Changing the configuration of various subsystems, including their resource sets
Adding subsystems from the same or another template
This section describes ways you can change configuration settings. It includes three topics:
To change configuration settings using a wizard:
In the Project Configuration dialog, click the tab for the subsystem whose settings you want to change:
To change configuration settings by editing the config.xml file directly:
Locate the config.xml file for the subsystem you want to change.
The config.xml files are located in the project's ConfigService.jar.
For example, in a WAR the Directory subsystem has a config.xml file in the WEB-INF\lib\ConfigService\ConfigService.spf\DirectoryService-conf subdirectory.
exteNd Director provides a standard key/value editor for config.xml files:
TIP: You can edit the XML source view if you prefer.
In some versions of exteNd Director, the XML source view does not include multiple-line comments. You can open the XML file in a text editor to be sure that you see the complete source.
To change configuration settings using a predefined view:
Go to the View tab within the Resources tab and select settings.ear.xml.
The settings.ear.xml view lets you find configuration settings in an EAR project (in a WAR project, you need to use the settings.war.xml view).
The settings view includes a folder containing the configuration files for all subsystems.
You can use the Setup Wizard to add subsystems to an existing 5.0 EAR project.
NOTE: This menu option is only enabled when you are working with a Version 5.0 EAR project. It is disabled for all other project types.
You can add subsystems from any template—you don't have to use the same template you used to create the project. The Setup Wizard copies subsystem files to the project directory, adds subprojects to the project file, and makes configuration changes where necessary.
To add subsystems to your exteNd Director project:
On the Template Location panel, specify the directory for the template that contains the subsystems you want to add, then click Next.
For information about selecting templates, see Creating an exteNd Director project.
On the Subsystem Selection panel, select the subsystems you want to add.
Make configuration settings as appropriate.
Creating an exteNd Director project has information about these panels (for example: see Content Management caching configuration, Content Management caching configuration, and Summary panel.)
On the last panel, check the summary information and optionally clear the Build project after wizard is finished check box.
Just as with the wizard for creating the exteNd Director project, this wizard takes some time to copy subsystem files from the template to the project directory. Then it builds the project, if you selected that option. When it finishes, you're ready to continue work on your application.
NOTE: For 5.0 EAR projects only.
The Setup Wizard lets you remove or disable any installed subsystem.
Removing means the subsystem is removed from the project and references are removed from the project definition. Its files are deleted from disk.
Disabling means the subsystem files remain part of the project, but the subsystem is omitted from the archive when the project is built. The subsystem files are still in the project and you can reenable it when you want to.
In both cases, references to the subsystem are removed from configuration files and classpaths in manifest files.
To remove subsystems from your exteNd Director project:
On the Setup Option panel of the Setup Wizard, select Modify.
On the Subsystem Setup panel, clear the Selected check box for a subsystem you want to remove. Click Yes when the wizard asks if you are sure, warning that its files will be deleted.
TIP: If you select a subsystem that another subsystem depends on, the wizard won't allow it to be deleted. A message tells you what subsystems depend on it.
The wizard deletes the subsystem from the project and the subsystem files from disk.
Delete additional subsystems if you want, and click Finish when you are done.
To enable or disable subsystems:
On the Setup Option panel of the Setup Wizard, select Modify.
Disable a subsystem by clearing its Enabled check box. Then click Yes when the wizard asks if you are sure you want to disable the subsystem.
The wizard deletes the subsystem from the project but leaves the files on disk so that you can reenable the project later.
Disable or enable additional subsystems if you want, and click Finish when you are done.
To find out what subsystems are enabled:
Select Project>Director>Information.
The Subsystem Information dialog displays the version and enabled status of the subsystems in your project.
exteNd Director evaluation and beta software includes a project license that expires after a certain number of days. This means that you will not be able to create new exteNd Director projects or access deployed exteNd Director applications (built using that license) after it expires. You'll know when your project license has expired when you get an error message such as:
|
Occurence |
Error message |
|---|---|
|
Design time |
License string nnnn has expired |
|
Run time |
Maximum license count 0 exceeded |
To update an evaluation or beta license for new and existing projects, you'll need to:
Obtaining a new project license You can obtain a new project license by:
Purchasing an unrestricted license and updating the template license as described in the procedure To update the template license:. Contact your sales representative for information about obtaining this type of license.
Purchasing and installing a commercial version of exteNd Director.
If you have existing exteNd Director projects that you want to continue to use (and they were created using the beta or evaluation software) you'll need to update those projects as described in the procedure To update the template license:).
Updating the license The exteNd Director project license is stored in the default project template and in each individual project.
|
To update this project license |
See this procedure |
|---|---|
|
Existing projects that I want to continue to use |
|
|
Template license for all new projects |
If you have existing exteNd Director projects, you'll need to update each project individually. Follow the steps
To update the template license:
Click Update License template.
The currently open project is updated with the new license and any subsequent exteNd Director projects that you create will include this new license.
To update a project with expired licenses:
exteNd Director relies on JARs to provide subsystem resources. For example, each subsystem has one or more archives associated with it. In addition to the subsystem JARs, exteNd Director applications require other third-party JARs for successful execution. Examples of these other JARs include: Xalan.jar and xercesImpl.jar.
You can decide how exteNd Director should package the JARs used by your projects. The JAR configuration options are described in the following table:
|
If you want to |
Choose this configuration |
|---|---|
|
Include all of the needed JARs within your project |
This is called a nonshared library configuration. By default, the Project Wizard creates all exteNd Director projects in this configuration.
|
|
Include only the exteNd Director subsystem JARs within the project . Copy the third-party JARs to a well-known location on the deployment application server |
This is called a 3rd party JARs (partial shared library) configuration
|
|
Don't include any framework or subsystem JARs within the project. Copy all of the framework, subsystem and 3rd party JARs to a well-known location on your deployment application server |
This is called a shared library configuration. You must use this configuration:
|
By default, exteNd Director applications (except for portlet applications) are created using the nonshared library configuration.
In the nonshared library configuration:
Each exteNd Director application is a self-contained unit.
All of exteNd Director's services are embedded within an exteNd Director EAR or WAR project. The application server does not share any files among the exteNd Director applications that are deployed.
The classes are loaded by individual J2EE WAR or EAR class loaders.
You can deploy multiple portals to the application server, but they must use different exteNd Director databases.
You might not choose the nonshared library environment because:
The project size is large resulting in a longer deployment time.
Portlet application WARs must be included in an exteNd Director EAR for deployment. In the nonshared library configuration, portlet application WARs cannot be deployed independently.
Changes to the application require a redeployment of the archive.
For more information on changing to a different configuration, see Procedures for changing the project configuration.
In a shared library configuration, the JAR files and classes that provide exteNd Director's services are installed on your application server in a well-known location. This means that the JARs can be shared across all exteNd Director Web applications deployed on that application server. The classes in the shared libraries are loaded by a single class loader, and the Web application class loaders extend from that class loader.
The shared library's benefits and restrictions are outlined below:
For more information on changing to a different configuration, see Procedures for changing the project configuration.
In the 3rd party JAR configuration:
The JAR files and classes that provide exteNd Director's services are included in in the project.
The 3rd party JARs are installed on your application server and thus can be shared across all exteNd Director Web applications deployed on that application server.
The benefits to the 3rd party JAR configuration include:
For more information on changing to a different configuration, see Procedures for changing the project configuration.
By default, exteNd Director projects use a nonshared library configuration.
To determine the current project configuration:
Choose Project>Director>Shared Lib.
The Shared Lib dialog displays.
If the Shared Lib check box is not selected, the project is a nonshared library project.
To determine the application server's configuration:
To determine your application server's configuration, you'll need to check the appropriate server directory and see which JARs are there (or not).
If the location contains:
JARs (like jaxrpc-api.jar, jdom.jar, js.jar, and log4j.jar), but none of exteNd Director's subsystem JARs, then it is a 3rd party shared library configuration.
exteNd Director's subsystem JARs (like FrameworkService.jar, RuleService.jar, or DirectoryService.jar), then it is a full shared library configuration.
Neither 3rd party nor exteNd Director's subsystem JARs, then it is a nonshared library configuration.
To change a nonshared library server to a full or 3rd party shared library configuration:
Undeploy any exteNd Director projects that require a nonshared library environment.
NOTE: This procedure also changes the structure of the project.
You are prompted for a directory location to copy the JARs to.
Update the application server's classpath so that the server can locate the JARs you just copied.
To change from a shared library server configuration to a nonshared library configuration:
Undeploy any exteNd Director projects that require a shared library environment.
NOTE: This procedure also changes the structure of the project.
Unselect the Shared Lib checkbox and (if checked) the Only 3rd party JARs.
Remove the exteNd Director subsystem JARs and the 3rd party JARs from the server's directory.
Remove the exteNd Director subsystem JARs and the 3rd party JARs from the server's classpath.
Copyright © 2004 Novell, Inc. All rights reserved. Copyright © 1997, 1998, 1999, 2000, 2001, 2002, 2003 SilverStream Software, LLC. All rights reserved. more ...
