03752: | Rework jar file structure for Connector Services to match other services |
Category: Connector
Status: ClosedSeverity: LOW
Reported against release: 0.8
Fixed in release: 0.8.2 (Beta Refresh 2)
PROBLEM:The jar file architecture for Connector Services does not conform to
the standard used throughout the other services. Here's an explanation:
For convenience, we've provided a mot_openwings.jar file that users can
put on their component's classpath. This jar file contains no actual
class files, instead it's manifest references a jar file for each of
the Openwings service specifications.
Each service, in turn, has its own top-level convenience jar file,
which references the other pieces of the implementation.
For example, Component Services has the convenience jar file
mot_component.jar. This jar file references the following jar files in
it's manifest: mot_component_core.jar, mot_component_jini.jar,
mot_component_policy.jar.
The Container Services implementation, in contrast, has one
mot_connector.jar file containing the entire set of Container
functionality, including connector generators for several protocols,
the ConnectorLoader implementation, and the ConnectorRepository
implementation. Additionally, there are separate jar files for the
ConnectorLoader and ConnectorRepository. This duplication is
unnecessary and causes confusion. ANALYSIS:The mot_connector.jar convenience jar file should contain no classes
but should instead point to the following jar files:
mot_connector_loader.jar
mot_connector_repository.jar
mot_connector_core.jar (new)
mot_connector_rmi.jar (new)
mot_connector_iiop.jar (new)
mot_connector_fiorano.jar (new)
mot_connector_openjms.jar (new)
The single class in the com.mot.openwings.connector package
(ConnectorClassJarer) is a utility that should be moved to
com.mot.openwings.connector.core, and be stored in the new jar file
mot_connector_core.jar.
The last four items in this list are new jar files - each connector
generator for a new protocol should be contained in its own jar file. |
