OSGi Service Platform Service Compendium：详尽参考指南

需积分: 9 89 浏览量更新于2024-07-26 收藏 3.03MB PDF 举报

OSGi Service Platform Service Compendium 是由 The OSGi Alliance 发布的第四版技术规范，版本为 4.0.1，发布日期为2006年7月。该文档是作为参考材料，详尽介绍了 OSGi（Open Services Gateway Initiative）服务平台的核心概念和服务组件。Osgi Alliance 对其内容进行了数字签名，确保了准确性和完整性，并声明了版权，所有权利保留。 OSGi 是一个开放的框架，主要用于模块化、动态加载和管理软件组件，尤其是在企业级应用和服务架构中。Service Compendium 版本的焦点在于服务组件，它定义了如何在 OSGi 环境中注册、查找和使用服务，确保了服务之间的松耦合和互操作性。这份文档的核心内容包括： 1. **服务生命周期管理**：涵盖了如何创建、发布、订阅、撤销和更新服务，以及服务提供者和消费者之间的交互模型。 2. **服务注册与发现**：服务提供者通过注册机制将自己的服务公开，消费者通过搜索服务接口来发现并使用它们。 3. **服务接口和契约**：定义了服务的接口规范，确保不同供应商提供的服务可以无缝集成。 4. **服务绑定与依赖管理**：允许服务消费者自动绑定到满足特定条件的服务，简化了配置和维护。 5. **服务事件和通知**：支持服务状态变化时的通知机制，帮助消费者及时响应服务的改变。 6. **服务引用和引用管理**：提供了对服务实例的引用，以及处理引用生命周期管理的方法。 7. **安全性考虑**：包括了对服务访问权限的控制，以及如何确保数据的安全传输和访问。 8. **实现指南和最佳实践**：提供了开发者如何实现符合 OSGi 规范的详细指导，以及如何避免常见问题和优化性能的建议。遵循 OSGi Service Platform Service Compendium 的规范，开发人员可以构建高度模块化、可扩展且易于管理的应用程序，适应不断变化的业务需求。这份文档对于任何从事Java EE、微服务架构或者服务导向架构的开发人员来说，都是不可或缺的技术参考资料。

The Log Service Interface Log Service Specification Version 1.3

6-434 OSGi Service Platform Release 4

Figure 101.1 Log Service Class Diagram org.osgi.service.log package

101.2 The Log Service Interface

The LogService interface allows bundle developers to log messages that can

be distributed to other bundles, which in turn can forward the logged

entries to a file system, remote system, or some other destination.

The LogService interface allows the bundle developer to:

• Specify a message and/or exception to be logged.

• Supply a log level representing the severity of the message being logged.

This should be one of the levels defined in the LogService interface but it

may be any integer that is interpreted in a user-defined way.

• Specify the Service associated with the log requests.

By obtaining a LogService object from the Framework service registry, a

bundle can start logging messages to the LogService object by calling one of

the LogService methods. A Log Service object can log any message, but it is

primarily intended for reporting events and error conditions.

The LogService interface defines these methods for logging messages:

• log(int, String) – This method logs a simple message at a given log level.

• log(int, String, Throwable) – This method logs a message with an

exception at a given log level.

• log(ServiceReference, int, String) – This method logs a message asso-

ciated with a specific service.

• log(ServiceReference, int, String, Throwable) – This method logs a

message with an exception associated with a specific service.

While it is possible for a bundle to call one of the log methods without pro-

viding a ServiceReference object, it is recommended that the caller supply

the ServiceReference argument whenever appropriate, because it provides

important context information to the operator in the event of problems.

<<interface>>

LogService

<<interface>>

LogReader

Service

<<interface>>

LogEntry

<<interface>>

LogListener

a Log Reader

Service impl.

LogEntry impl

a Log user bundle

a Log Service

impl

a Log reader user

Log a

message

Store a message in the log for retrieval

message log

send new log entry

retrieve log

0..n (impl dependent maximum)

0..n

LogEntry has references to

ServiceReference,

Throwable and Bundle

or register

listener

Bundle using

Log Service

Bundle using

Log Reader

Service

Log implementation bundle

Log Reader Service Log Service Specification Version 1.3

8-434 OSGi Service Platform Release 4

101.4 Log Reader Service

The Log Reader Service maintains a list of LogEntry objects called the log.

The Log Reader Service is a service that bundle developers can use to

retrieve information contained in this log, and receive notifications about

LogEntry objects when they are created through the Log Service.

The size of the log is implementation-specific, and it determines how far

into the past the log entries go. Additionally, some log entries may not be

recorded in the log in order to save space. In particular, LOG_DEBUG log

entries may not be recorded. Note that this rule is implementation-depen-

dent. Some implementations may allow a configurable policy to ignore cer-

tain LogEntry object types.

The LogReaderService interface defines these methods for retrieving log

entries.

• getLog() – This method retrieves past log entries as an enumeration with

the most recent entry first.

• addLogListener(LogListener) – This method is used to subscribe to the

Log Reader Service in order to receive log messages as they occur. Unlike

the previously recorded log entries, all log messages must be sent to sub-

scribers of the Log Reader Service as they are recorded.

A subscriber to the Log Reader Service must implement the LogListener

interface.

After a subscription to the Log Reader Service has been started, the sub-

scriber's LogListener.logged method must be called with a LogEntry

object for the message each time a message is logged.

The LogListener interface defines the following method:

• logged(LogEntry) – This method is called for each LogEntry object

created. A Log Reader Service implementation must not filter entries to

the LogListener interface as it is allowed to do for its log. A LogListener

object should see all LogEntry objects that are created.

The delivery of LogEntry objects to the LogListener object should be done

asynchronously.

101.5 Log Entry Interface

The LogEntry interface abstracts a log entry. It is a record of the information

that was passed when an event was logged, and consists of a superset of

information which can be passed through the LogService methods. The

LogEntry interface defines these methods to retrieve information related to

LogEntry objects:

• getBundle() – This method returns the Bundle object related to a Log-

Entry object.

• getException() – This method returns the exception related to a Log-

Entry object. In some implementations, the returned exception may not

be the original exception. To avoid references to a bundle defined

exception class, thus preventing an uninstalled bundle from being

garbage collected, the Log Service may return an exception object of an

OSGi Service Platform Release 4 9-434

Log Service Specification Version 1.3 Mapping of Events

implementation defined Throwable subclass. This object will attempt to

return as much information as possible, such as the message and stack

trace, from the original exception object .

• getLevel() – This method returns the severity level related to a LogEntry

object.

• getMessage() – This method returns the message related to a LogEntry

object.

• getServiceReference() –This method returns the ServiceReference

object of the service related to a LogEntry object.

• getTime() – This method returns the time that the log entry was created.

101.6 Mapping of Events

Implementations of a Log Service must log Framework-generated events

and map the information to LogEntry objects in a consistent way. Frame-

work events must be treated exactly the same as other logged events and dis-

tributed to all LogListener objects that are associated with the Log Reader

Service. The following sections define the mapping for the three different

event types: Bundle, Service, and Framework.

101.6.1 Bundle Events Mapping

A Bundle Event is mapped to a LogEntry object according to Table 101.2,

“Mapping of Bundle Events to Log Entries,” on page 9.

101.6.2 Service Events Mapping

A Service Event is mapped to a LogEntry object according to Table 101.3,

“Mapping of Service Events to Log Entries,” on page 10.

101.6.3 Framework Events Mapping

A Framework Event is mapped to a LogEntry object according to Table

101.4, “Mapping of Framework Event to Log Entries,” on page 10.

Table 101.2 Mapping of Bundle Events to Log Entries

Log Entry method Information about Bundle Event

getLevel() LOG_INFO

getBundle() Identifies the bundle to which the event happened. In other words, it

identifies the bundle that was installed, started, stopped, updated, or

uninstalled. This identification is obtained by calling getBundle()

on the BundleEvent object.

getException() null

getServiceReference() null

getMessage() The message depends on the event type:

• INSTALLED – "BundleEvent INSTALLED"

• STARTED – "BundleEvent STARTED"

• STOPPED – "BundleEvent STOPPED"

• UPDATED – "BundleEvent UPDATED"

• UNINSTALLED – "BundleEvent UNINSTALLED"

• RESOLVED – "BundleEvent RESOLVED"

• UNRESOLVED – "BundleEvent UNRESOLVED"

Mapping of Events Log Service Specification Version 1.3

10-434 OSGi Service Platform Release 4

101.6.4 Log Events

Log events must be delivered to the Event Admin service asynchronously

under the topic:

org/osgi/service/log/LogEntry/<event type>

The logging level is used as event type:

LOG_ERROR

LOG_WARNING

LOG_INFO

Table 101.3 Mapping of Service Events to Log Entries

Log Entry method Information about Service Event

getLevel() LOG_INFO, except for the ServiceEvent.MODIFIED event. This

event can happen frequently and contains relatively little informa-

tion. It must be logged with a level of LOG_DEBUG.

getBundle() Identifies the bundle that registered the service associated with

this event. It is obtained by calling

getServiceReference().getBundle() on the ServiceEvent object.

getException() null

getServiceReference() Identifies a reference to the service associated with the event. It is

obtained by calling getServiceReference() on the ServiceEvent

object.

getMessage() This message depends on the actual event type. The messages are

mapped as follows:

• REGISTERED – "ServiceEvent REGISTERED"

• MODIFIED – "ServiceEvent MODIFIED"

• UNREGISTERING – "ServiceEvent UNREGISTERING"

Table 101.4 Mapping of Framework Event to Log Entries

Log Entry method Information about Framework Event

getLevel() LOG_INFO, except for the FrameworkEvent.ERROR event. This event

represents an error and is logged with a level of LOG_ERROR.

getBundle() Identifies the bundle associated with the event. This may be the sys-

tem bundle. It is obtained by calling getBundle() on the

FrameworkEvent object.

getException() Identifies the exception associated with the error. This will be null

for event types other than ERROR. It is obtained by calling

getThrowable() on the FrameworkEvent object.

getServiceReference() null

getMessage() This message depends on the actual event type. The messages are

mapped as follows:

• STARTED – "FrameworkEvent STARTED"

• ERROR – "FrameworkEvent ERROR"

• PACKAGES_REFRESHED – "FrameworkEvent PACKAGES

REFRESHED"

• STARTLEVEL_CHANGED – "FrameworkEvent STARTLEVEL

CHANGED"

• WARNING – "FrameworkEvent WARNING"

• INFO – "FrameworkEvent INFO"

剩余443页未读，继续阅读

走在架构的小路上

粉丝: 27
资源: 70

OSGi Service Platform Service Compendium：详尽参考指南

org.osgi.compendium-4.2.0.jar

org.osgi.compendium-1.2.0.jar

OSGi Service Platform 4.1

使用Tycho构建OSGi插件项目

osgi android

Springboot框架如何集成OSGI

osgi + rcp

用kotlin写一套基于osgi框架的Android代码

OSGI container

Spring OSGI 如何使用HystrixCommand

最新资源