Aspect scoping in a modularity runtime

A method and system are provided for aspect scoping in a modularity runtime. The method includes declaring a set of aspects of a bundle as public aspects in a first aspect configuration file, and filtering the aspect configuration files imported by a bundle to the files from bundles on which the importing bundle has a dependency. The method includes declaring a set of aspects of a bundle as private aspects in a second aspect configuration file. At weaving of aspects at a bundle, the weaving includes: any aspects defined as private aspects; any aspects defined as public aspects; any imported aspects; and any first configuration files from exporting bundles are declared.

FIELD OF THE INVENTION

This invention relates to the field of a modularity runtime environment. In particular, it relates to aspect scoping in a modularity runtime.

BACKGROUND

A runtime environment is a virtual machine state which provides software services for processes or programs while a computer is running. A runtime library is a collection of utility functions which support a program while it is running by working with the operating system. The Java Virtual Machine (JVM) (Java is a trademark of Sun Microsystems, Inc.) is an example of a runtime. The .NET framework is another example of a runtime.

The OSGi (Open Services Gateway initiative) modularity framework provides a dynamic component model for JVM environments. Applications or components in the form of bundles for deployment can be remotely managed and management of Java packages/classes is specified in detail. For example, the Eclipse platform (Eclipse is a trade mark of the Eclipse Foundation) is an open-source, platform independent software framework including the OSGi bundling framework.

The OSGi modularity framework provides the ability to define classes and resources (for example, configuration files) that are private to a particular application. It also allows an application to explicitly declare its dependence on other applications, frameworks or libraries. The net effect is that some classes are invisible to an application.

Aspect-oriented programming (AOP) aids programmers in the separation of concerns to improve modularity. Some aspects of system implementation, such as logging, error handling, standards enforcement and feature variations are notoriously difficult to implement in a modular way. The result is that code is tangled across a system and leads to quality, productivity and maintenance problems. AspectJ is a seamless aspect-oriented extension to the Java programming language that enables clean modularization of these “crosscutting concerns”. An aspect is treated as a class by OSGi in terms of visibility. A mechanism is required by AspectJ to determine which types in the system are aspects. The meta-data associated with the aspects must be visible to applications, except where an aspect is known to be private.

The load-time weaving (LTW) feature of AspectJ requires that the set of all aspects to be used to weave classes defined by a particular class loader are declared before any weaving takes place. This set must remain unchanged for the lifetime of the class loader. This emulates the process of weaving the set of classes that comprise an application during an earlier build process prior to execution.

An aspect configuration file is typically created during the compilation process and declares the aspects. In a runtime system, a complete set of all aspects visible to a class loader can be obtained without prior knowledge of the hierarchy topology.

A problem is that an aspect configuration file associated with a particular bundle is visible to every other bundle in the same runtime regardless of whether the aspects it declares are also visible (i.e. exported or imported). This causes a failure during LTW initialization that is indistinguishable from a user configuration error which may cause an application to behave incorrectly or fail.

One approach used by the AJEER project (AJEER is a trade mark of Open Source Technology Group) which provides AspectJ load-time aspect weaving (http://sourceforge.net/projects/ajeer/) is to register all aspects with the runtime and ensure they are all visible. However, this can have unexpected side affects on bundles if the scope of an aspect is incorrect. Also, in a moderately sized system (for example, the Eclipse platform) centrally published aspects are known to have an unacceptable affect on start-up performance.

Another approach would be to use one aspect configuration file for every exported package. That way a bundle could enumerate the set of visible bundles and attempt to load the corresponding configuration file. Unfortunately, the set of packages that is visible to a bundle cannot always be determined and a possibly large set of aspect configuration files would be difficult to maintain.

The problem described above is given in the context of aspects in the OSGi framework. However, the solution provided of aspect scoping may be applied to other modularity runtimes.

SUMMARY

It is an aim of the present invention to both restrict the set of aspects declared as public to a bundle, and filter the set of files actually imported by a bundle. In this way, filtering the set of aspects declared is carried out so that it coincides with the set that is visible.

According to a first aspect of the present invention there is provided a method for aspect scoping in a modularity runtime, comprising: declaring a set of aspects of a bundle as public aspects in a first aspect configuration file; and filtering the aspect configuration files imported by a bundle to the files from bundles on which the importing bundle has a dependency. The bundles may be bundles of applications or components.

The method may include declaring a set of aspects of a bundle as private aspects in a second aspect configuration file. A bundle may export a package defining an aspect and may export a first aspect configuration file. A bundle may import a package defining an aspect from another bundle and may import a first aspect configuration file from the exporting bundle.

When weaving aspects at a bundle, the weaving may include: any aspects defined as private aspects; any aspects defined as public aspects; any imported aspects; and wherein any first configuration files from exporting bundles are declared.

According to a second aspect of the present invention there is provided a system for aspect scoping in a modularity runtime having multiple bundles with declared aspects, comprising: means for declaring a set of aspects of a bundle as public aspects in a first aspect configuration file; and means for filtering the aspect configuration files imported by a bundle to the files from bundles on which the importing bundle has a dependency.

The system may also include means for declaring a set of aspects of a bundle as private aspects in a second aspect configuration file.

The system may include a dependency mechanism for determining the dependencies between bundles, and an aspect discovery mechanism for determining aspects which are public and the aspects which are private, the aspect discovery mechanism also including the means for filtering the aspect configuration files.

A bundle may include means for exporting a package defining an aspect and means for exporting a first aspect configuration file. A bundle may further include means for importing a package defining an aspect from another bundle and means for importing a first aspect configuration file from the exporting bundle.

A weaving mechanism for weaving of aspects at a bundle may include weaving: any aspects defined as private aspects; any aspects defined as public aspects; any imported aspects; and wherein any first configuration files from exporting bundles are declared.

According to a third aspect of the present invention there is provided a computer program product stored on a computer readable storage medium for aspect scoping in a modularity runtime, comprising computer readable program code means for performing the steps of: declaring a set of aspects of a bundle as public aspects in a first aspect configuration file; and filtering the aspect configuration files imported by a bundle to the files from bundles on which the importing bundle has a dependency.

Referring toFIG. 1, a block diagram shows a computer system100including a modularity framework as known in the art. The system100includes computer hardware101on which runs an operating system102. A framework110may run directly on the operating system102(for example, in the case of the .NET framework running on a Windows operating system (Windows is a trade mark of Microsoft Corporation). In the embodiment illustrated inFIG. 1, the framework110runs on a virtual operating system103which in turn runs on the operating system102. The virtual operating system103may be the Java Virtual Machine (JVM).

The framework110implements a dynamic component model and provides system services to applications or components which are defined in the form of bundles111-113. The system services may include life cycle management of the applications and components.

The modularity framework110provides an ability to define classes that are private to a particular application. It also allows an application to explicitly declare its dependence on other applications, frameworks or libraries. This means that some classes are invisible to an application.

In aspect-oriented programming (AOP), aspects are treated as a class by the modularity framework110in terms of visibility. A mechanism is required by the aspect-oriented extension to the Java programming language, AspectJ, to determine which types in the modularity framework110are aspects. The meta-data associated with the aspects must be visible to applications, except where an aspect is known to be private.

The weaving feature of AspectJ requires that the set of all aspects to be used to weave classes in a particular namespace are registered before any weaving takes place. This set must remain unchanged for the duration of the weaving process. For example the set of aspects used to weave the classes defined by a class loader must remain unchanged for the lifetime of that class loader. The weaving process may take place at different times, compile-time, post-compile time (also referred to as binary weaving), and load-time.

An aspect configuration file in XML (extended mark-up language) format, typically generated during the compilation process, is located in a well defined location (“META-INF/aop.xml”) relative to the aspects it declares. In the class loader hierarchy of a runtime system every aop.xml file defined by a particular class loader (for example, located in the classpath of a URLClassLoader) is visible to all its delegates. This approach means that with a single API (ClassLoader.getResources(String)) a complete set of all aspects visible to a class loader can be obtained without prior knowledge of the hierarchy topology.

The OSGi runtime environment abstracts the namespace associated with a class loader to a bundle. Additional meta-data associated with a bundle can restrict the set of classes and hence the aspects that are visible (exported) to other bundles. It may also determine the set of classes that a bundle wishes to use (import) from another bundle. This is done using package names.

However, the default meta-data directory used by aop.xml cannot be exported. When using AspectJ load-time weaving under OSGi, the aop.xml file is typically copied to the org.aspectj package which is exported. Unfortunately, this means that an aop.xml file associated with a particular bundle is visible to every other bundle in the same runtime regardless of whether the aspects it declares are also visible (i.e. exported or imported).

The solution is both to restrict the set of aspects declared as public to a bundle, and to filter the set of aspect configurations files (aop.xml files), actually imported by a bundle. In this way, filtering is carried out of the set of aspects declared so that it coincides with the set that is visible.

Referring toFIG. 2, a block diagram is shown of a described framework210. The framework210provides system services to bundles211-213of applications or components. The framework210includes a runtime library221, a set of class loaders222, one for each bundle211-213and a dependency mechanism227.

An aspect-oriented mechanism223includes a weaving mechanism224, an aspect discovery mechanism225and an aspect declaration mechanism226.

The aspect discovery mechanism225includes two levels. A first level231determines the set of aspects private to a bundle211-213. These are aspects which are only used locally in a bundle211-213. For example, this first level231of declaration could be in the form of an aspect configuration file “META-INF/aop.xml”.

A second level232of the aspect discovery mechanism225determines aspects which are public. These are aspects which are used locally in a bundle211-213and used by other bundles211-213. For example, this second level232of declaration could be in the form of an aspect configuration file “org/aspectj/aop.xml”.

In this example embodiment, the aspect configuration files are given as XML files. However, other forms of configuration file may also be used.

The aspect discovery mechanism225also includes a filtration mechanism233which ensures that only aspect configuration files from bundles211-213on which the importing bundle211-213has a dependency are used. It uses the dependency mechanism of227of the framework.

FIGS. 3A and 3Bshows a schematic representation of the described method. There are three bundles “apple”311, “banana”312, and “currant”313shown inFIG. 3A.

The aspects are declared as follows:Bundle “apple”311declares an aspect a.AspectA321in package a331. The public aspect declaration file341includes a.AspectA321. Bundle “apple”311exports package a331. The bundle “apple”311also exports the public aspect declaration file in package org.aspectj341.Bundle “banana”312declares an aspect b.AspectB322in package b332and exports it. Bundle “banana”312declares an aspect bb.AspectBB323in package bb333which it does not export. The public aspect declaration file342includes b.AspectB322. The private aspect declaration file343, located in the META-INF local directory of the bundle, includes bb.AspectBB323. Bundle “banana”312also imports package a331. Bundle “banana”312also exports the public aspect declaration file in package org.aspectj342.Bundle “currant”313imports package b332.

FIG. 3Bshows how the aspects are woven, for example, at load-time weaving, as follows:The locally defined aspect a.AspectA321is woven into bundle “apple”311.The aspect a.AspectA321is imported by and woven into bundle “banana”312. The locally defined aspects b.AspectB322and bb.AspectBB323are also woven into bundle “banana”312.Only aspect b.AspectB322is visible to, imported by and woven into bundle “currant”313. The aspect bb.AspectBB323is not visible but neither is it declared public. The public aspect declaration file (org/aspectj/aop.xml)341exported from bundle “apple”311is visible but the aspect a.AspectA321that it declares is not. As there is no dependency between bundle “currant”313and bundle “apple”311, the configuration is filtered and the aspects that the public aspect declaration file (org/aspectj/aop.xml)341lists are not declared.

The author of an aspect bundle need only create a single aspect configuration file (i.e. org/aspectj/aop.xml) to determine which aspects are public.

The author of an application bundle only need use existing OSGi meta-data (bundle-manifest) to determine which aspects are to be used. Aspects are typically declared in the same package and often the same bundle as the Java classes whose functionally they are helping to provide. Therefore, no additional configuration need be provided by a bundle wishing to use an aspect other than importing the org.aspectj package.

The extent of bundle weaving and hence good performance is not reliant on the scope of a particular aspect, but on OSGi meta-data. An aspect may be written without any prior knowledge of the system into which it will be deployed. If the author is too narrow with the scope of the aspect, (i.e. using specific class or package names) it may not be used with a range of different applications. However, if the scope is too broad the aspect may affect too many classes. By enabling a bundle author to specify exactly which packages and hence which aspects are to be used, the extent of bundle weaving can be better controlled.

When enumerating the set of aspect configuration files visible to a particular bundle using ClassLoader.getResources(String), it is possible to determine the exporting bundle. It is also possible to determine those bundles on which a particular bundle depends. By filtering the set of aspect configuration files to those exported by a dependent bundle, only those aspects that are visible will be declared.

Referring toFIG. 4, a computer system400is shown on which the present invention may be implemented. A computer system400has a central processing unit401with primary storage in the form of memory402(RAM and ROM). The memory402stores program information and data acted on or created by the programs. The program information includes the operating system code for the computer system400and application code for applications running on the computer system400. Secondary storage includes optical disk storage403and magnetic disk storage404. Data and program information can also be stored and accessed from the secondary storage.

The computer system400includes a network connection means405for interfacing the computer system400to a network such as a local area network (LAN) or the Internet. The computer system400may also have other external source communication means such as a fax modem or telephone connection.

The central processing unit401includes inputs in the form of, as examples, a keyboard406, a mouse407, voice input408, and a scanner409for inputting text, images, graphics or the like. Outputs from the central processing unit400may include a display means410, a printer411, sound output412, video output413, etc.

In a distributed system, a computer system400as shown inFIG. 4may be connected via a network connection405to a server on which applications may be run remotely from the central processing unit401which is then referred to as a client system.

Applications which may run on the computer systems from a storage means or via a network connection may include word processing programs, Internet access programs including search engines for searching the World Wide Web, other text indexing and retrieving programs for databases, machine translation programs for translating foreign language documents, optical character recognition programs for recognizing characters from scanned documents, etc.