OpenOffice---服务管理器与组件上下文

根对象（与 StarSuite以及与任何 UNO 应用程序连接的根对象 – 服务管理器）用作每个 UNO 应用程序的入口点，并在实例化过程中被传送到每个 UNO 组件。

 

服务管理器

com.sun.star.lang.ServiceManager 是每个 UNO 应用程序中的主要工厂。它按服务名称实例化服务，以枚举某项具体服务的所有实现，并在运行时添加或删除某项具体服务的工厂。实例化时，服务管理器被传送到每个 UNO 组件。

 

XMultiServiceFactory 接口

服务管理器的主要接口是 com.sun.star.lang.XMultiServiceFactory 接口。它提供三个方法：createInstance()、createInstanceWithArguments() 和getAvailableServiceNames()。

 

interface XMultiServiceFactory: com::sun::star::uno::XInterface

{

com::sun::star::uno::XInterface createInstance( [in] string aServiceSpecifier )

raises( com::sun::star::uno::Exception );

com::sun::star::uno::XInterface createInstanceWithArguments(

[in] string ServiceSpecifier,[in] sequence<any> Arguments )

raises( com::sun::star::uno::Exception );

sequence<string> getAvailableServiceNames();

};

 

• createInstance() 返回一个默认构造的服务实例。返回的服务保证至少支持所有接口，这些接口是通过请求的服务名称来指定的。现在，可以从返回的 XInterface 引用中查询服务说明中指定的接口。

使用服务名称时，调用程序不会对实例化哪个具体实现产生任何影响。如果某项服务存在多个实现，服务管理器就可以自由决定采用哪个实现。这一般不会对调用程序产生影响，因为每个实现都确实履行服务合同。性能或其他细节可能会有所不同。因此，也可以传送实现名称，而不是服务名称；但是，不建议这样做，因为实现名称可能会更改。

如果服务管理器没有为某个请求提供实现，将会返回一个空引用，因此必须进行检查。实例化时，可能会抛出所有 UNO 异常。有些可能会在要实例化的服务的规范中说明，例如，由于具体实现的配置不正确。另一个原因可能是缺少某个具体桥，例如，Java-C++ 桥，以防从 C++ 代码实例化 Java 组件。

 

• createInstanceWithArguments() 使用附加参数实例化服务。一项服务表示在通过支持com.sun.star.lang.XInitialization 接口进行实例化时需要参数。服务定义应该说明序列中每个元素的意义。可能有些服务必须使用参数来实例化。

 

• getAvailableServiceNames() 返回服务管理器确实支持的所有服务名称。

 

 

XContentEnumerationAccess 接口

com.sun.star.container.XContentEnumerationAccess 接口允许创建具体服务名称的所有实现的枚举。

 

interface XContentEnumerationAccess: com::sun::star::uno::XInterface

{

com::sun::star::container::XEnumeration createContentEnumeration( [in] string aServiceName );

sequence<string> getAvailableServiceNames();

};

createContentEnumeration() 方法返回一个 com.sun.star.container.XEnumeration 接口。请注意，如果枚举为空，此方法可能会返回空引用。

 

interface XEnumeration: com::sun::star::uno::XInterface

{

boolean hasMoreElements();

any nextElement()

raises( com::sun::star::container::NoSuchElementException,com::sun::star::lang::WrappedTargetException );

};

在上面的示例中，方法 Xenumeration.nextElement() 返回的 any 中，包含一个与此特定服务的每个实现对应的 com.sun.star.lang.XSingleServiceFactory 接口。例如，我们可以遍历某项具体服务的所有实现，并检查附加的已实现服务的每个实现。XSingleServiceFactory 接口就提供这样的方法。利用此方法，可以实例化一个服务丰富的功能实现。

 

XSet 接口

com.sun.star.container.XSet 接口允许在运行时将com.sun.star.lang.XSingleServiceFactory 或com.sun.star.lang.XSingleComponentFactory 实现插入到服务管理器或从中删除而不保存这些更改。办公软件应用程序终止时，所有更改将失效。对象还必须支持com.sun.star.lang.XServiceInfo 接口，用于提供有关组件实现的实现名称和所支持服务的信

息。

在开发阶段可能会对此功能可能特别感兴趣。例如，您可以连接到正在运行的办公软件，在服务管理器中插入新的工厂，以及在不需要提前注册的情况下直接实例化新服务。

 

组件上下文

前面将服务管理器描述为主要工厂，它被传送到每个新实例化的组件。部署应用程序后，一个组件通常需要更多可以交换的功能或信息。在这种环境中，服务管理器方法具有局限性。因此，创建了组件上下文的概念。将来，此概念将会成为每个 UNO 应用程序的主要对象。它基本上是一个提供命名值的只读容器。其中一个命名值就是服务管理器。实例化时， 组件上下文被传送到一个组件。这可以理解为一种组件生存环境（关系类似于 shell 环境变量与可执行程序）。

 

ComponentContext API

组件上下文仅支持 com.sun.star.uno.XComponentContext 接口。

// module com::sun::star::uno

interface XComponentContext : XInterface

{

any getValueByName( [in] string Name );

com::sun::star::lang::XMultiComponentFactory getServiceManager();

};

getValueByName()方法返回一个命名值。getServiceManager()是一种获取命名值/singleton /com.sun.star.lang.theServiceManager 的便捷方法。它返回 ServiceManagersingleton，因为多数组件需要访问服务管理器。组件上下文至少提供三种命名值：

singleton (/singletons/...)

在 StarSuite 6.0 PP2 中，只有ServiceManager singleton。从 StarSuite 7 开始，增加了一个 singleton /singletons/com.sun.star.util.theMacroExpander，此 singleton 可用于在配置文件中扩展宏。在 IDL 引用中可以找到其他可能的 singleton 。

实现属性（尚未定义）

这些属性自定义某个具体实现，并且在每个组件的模块说明中指定。模块说明是某个模块（DLL或 jar 文件）基于 XML 的说明，其中包含一个或多个组件的一般说明。

服务属性（尚未定义）

这些属性可以自定义与实现无关的某项具体服务，而且是在一项服务的 IDL 规范中指定的。注意，服务环境属性不同于服务属性。服务环境属性无法更改，而且对于所有共享同一组件上下文的服务实例都是相同的。每个实例可以具有不同的服务属性，而且在运行时可以通过XPropertySet 接口更改服务属性。

 

请注意，在上述模式中，ComponentContext 引用了服务管理器，而不是相反的情况。除了前面讨论的接口以外，ServiceManager 还支持com.sun.star.lang.XMultiComponentFactory 接口。

interface XMultiComponentFactory : com::sun::star::uno::XInterface

{

com::sun::star::uno::XInterface createInstanceWithContext(

[in] string aServiceSpecifier,

[in] com::sun::star::uno::XComponentContext Context )

raises (com::sun::star::uno::Exception);

com::sun::star::uno::XInterface createInstanceWithArgumentsAndContext(

[in] string ServiceSpecifier,

[in] sequence<any> Arguments,

[in] com::sun::star::uno::XComponentContext Context )

raises (com::sun::star::uno::Exception);

sequence< string > getAvailableServiceNames();

};

它替代 XMultiServiceFactory 接口。对于两种对象建立方法，它提供了一个附加的XComponentContext 参数。此参数使调用程序能够定义组件新实例可以接收的组件上下文。多数组件使用其初始组件上下文来实例化新组件。这样就可以进行环境传播。

 

可用性

可以在 StarSuite 6.0 和 OpenOffice 1.0 中使用组件上下文的最终 API。使用此API 取代服务管理器部分中说明的 API。目前，组件上下文无法进行永久存储，因此，无法将命名值添加到一个已部署StarSuite 的环境中。在发布未来版本之前，新 API 目前没有其他优点。

 

兼容性问题和移植路径

如前所述，办公软件内目前同时使用了这两个概念。ServiceManager 支持com.sun.star.lang.XMultiServiceFactory 和 com.sun.star.lang.XMultiComponentFactory

接口。将XMultiServiceFactory 接口调用授权给 XMultiComponentFactory 接口。服务管理器使用自己的 XComponentContext 引用来填充未设定的参数。可以用 'DefaultContext' 通过 XPropertySet接口来获取 ServiceManager 的组件上下文。

// Query for the XPropertySet interface.

// Note xOfficeServiceManager is the object retrieved by the

// UNO URL resolver

XPropertySet xPropertySet = (XPropertySet)

UnoRuntime.queryInterface(XPropertySet.class, xOfficeServiceManager);

// Get the default context from the office server.

Object oDefaultContext = xpropertysetMultiComponentFactory.getPropertyValue("DefaultContext");

// Query for the interface XComponentContext.

xComponentContext = (XComponentContext) UnoRuntime.queryInterface(

XComponentContext.class, objectDefaultContext);

此解决方案允许使用同一服务管理器实例，不管此实例使用旧式 API 还是 新式 API。将来，所有StarSuite 代码将仅使用新 API。但是，还将保留旧 API，目的是为了确保兼容性。