 |
|
 |
 |
||||||||||||||||||||||||||||||||||||||||||||
|
 Mandy Chung's Blog
OSGi Repository for Java Module SystemPosted by mandychung on July 24, 2008 at 08:57 AM | Permalink | Comments (0)The draft specification for supporting OSGi bundles in the Java Module System is currently under discussion in the JSR 277 Expert Group. To enable the EG and the community to provide feedback, we have included an OSGi repository prototype in the OpenJDK Modules project. The prototype currently supports only Apache Felix OSGi implementation for proof-of-concept. There are open issues to be resolved. The out-of-the-box support is yet to be designed and implemented. Supporting other OSGi implementations is to be investigated. We hope that this prototype enables the community to begin participating and provide feedback for OSGi interoperability support. We are working on posting a JDK binary built from the modules-dev project to make it ready for you to try out and experiment the JAM modules development as well as the OSGi support. In the meantime, you can clone the source from the Modules mercurial repository and build the JDK. The OSGi repository for the Java Module System The OSGi repository is packaged as <JAVA_HOME>/lib/osgi-repo.jar. To build the JDK with the OSGi repository, do the following (refer to the OpenJDK build instructions for details):
Note: We will remove the build dependency of the jar files for the OSGi core API and Felix in a future implementation. Setting up the OSGi repository The modules-dev implementation provides a repository configuration file (<JAVA_HOME>/lib/module/repository.properties) to set up the repositories created at VM startup. To set up the OSGi repository:
You can either update the <JAVA_HOME>/lib/module/repository.properties or override the repository properties file by specifying this system property in the command line:
Known bug: The VM does not exit when the Felix container has been started unless System.exit() is explicitly. The OSGi repository starts the Felix container during initialization which started a non-daemon thread ("FelixDispatchQueue" thread). Since the FelixDispatchQueue thread is still running, the program will not terminate. OSGi Repository Initialization When the OSGi repository is being initialized during the VM initialization, it will first load the configuration properties file that is "conf/config.properties" under the parent directory of the directory where felix.jar is located; if it doesn't exist, the default configuration properties will be loaded. Then it will load and start the Felix OSGi framework specified in the "osgi.container" property. All bundles in the source location of the OSGi repository will be automatically installed and started as the OSGi repository initialization. To start Felix, the bundle cache profile name or directory is required to be specified to indicate where the installed bundles will be cached. If there is no config.properties set up, you can set this system property at VM startup:
Develop a JAM module to use an OSGi bundle A JAM module that imports an OSGi bundle expresses its dependency in the same way as importing a JAM module. For example, each JAM module has a module-info.java file to express its module name, version, and its import dependency.
// hello/module-info.java
@Version("2.0")
@ImportModules({
@ImportModule(name="java.se"),
@ImportModule(name="com.foo.xml", version="[1.0, 3.0)"),
@ImportModule(name="com.bar.parser", version="2.0+")
})
@MainClass("hello.Main");
module hello;
This "hello" module imports two modules, "com.foo.xml" and "com.bar.parser" and they are specified in the @ImportModule annotation regardless of whether they are OSGi bundles or JAM modules. Say "com.foo.xml" is an OSGi bundle whereas "com.bar.parser" is a JAM module. To successfully resolve the imports, we will need to configure the OSGi repository as an ancestor of the repository for the "hello" module. The source location of the OSGi repository is where the "com.foo.xml" and other OSGi bundles are located. To launch this "hello" module application, it can be as simple as follows:
You can refer to the documentation in the Modules project for how to create and launch a JAM module in details. Questions and Feedback Please send your questions and feedback to modules-dev@openjdk.java.net. [Comment is closed for this blog because I will not be able to respond to any blog comment the next few weeks (on vacation).] JavaOne 2008Posted by mandychung on May 05, 2008 at 10:31 PM | Permalink | Comments (0)There are the Java Modularity session and BOF on Wednesday (5/7/2008)at JavaOne: TS-6185: Modularity in the Java™ Platform BOF-5032: Modularity in the Java™ Platform At the session, Stanley and Alex, the spec leads of JSR 277, will share the technical details of the Java Module System. At the BOF, we will show some simple demos of the JAM modules and also show a JAM module importing OSGi bundles using the JDK built from the OpenJDK modules project and then open for Q&A. Looking forward to meeting you there. For those who are not attending JavaOne, we will update you in our future blogs. Supporting OSGi Bundles in the Java Module SystemPosted by mandychung on April 28, 2008 at 10:38 PM | Permalink | Comments (1)A draft specification for supporting OSGi bundles in the Java Module System is put together based on the past EG discussion in particular the proposals and inputs from Glyn Normington, Richard Hall, and Bryan Atsatt. It is expected to evolve based on further inputs from the JSR 277 Expert Group. With the OSGi expertise from the JSR 277 EG and their contributions, we expect that this specification can be finalized soon. Your feedback is welcome and please send them to jsr-277-comments@jcp.org. Just to highlight a few main points: One thing noteworthy: JSR 277 defines the framework and API for the Java Module System and also defines the JAM module system as the default module system implementation for the Java SE platform and the JAM file format as its distribution format. JSR 277 Early Draft (EDR2) is being updated to clearly separate the distinction between the Java Module System framework and the JAM module system implementation. We recognized the issue with the JSR 277 EDR that didn't clearly separate the framework/abstraction from the JAM module system implementation that led to confusion and also skeptic about the OSGi interoperability support. Bryan Atsatt also identified and raised this concern to the EG. We hope that the EDR2 will be available in a few weeks after JavaOne. In the mean time, the draft spec includes some spec clarification relevant for this support. In addition, Bryan has a nice blog about JSR 277 interoperation that serves very well to set up the context ready for the coming discussion (thanks Bryan). I'd also like to blog more about this work but probably after JavaOne when I get some time.  |
|
July 2008
Search this blog:CategoriesJ2SEJavaOne Archives
July 2008 Recent EntriesOSGi Repository for Java Module System Supporting OSGi Bundles in the Java Module System | ||||||||||||||||||||||||||||||||||||||||||
Mandy Chung is a senior staff engineer at Sun Microsystems. She is working on the Java SE monitoring and management and other serviceability technologies. She leads the design and the implementation of the java.lang.management API, out-of-the-box manageability, and also the JConsole monitoring tool. Prior to joining Sun, she was the lead engineer working in the linker and dynamic loader project in Hewlett Packard.
 java.net RSS Feeds
|
