felix-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From build...@apache.org
Subject svn commit: r963800 [16/16] - in /websites/staging/felix/trunk/content: ./ documentation/ documentation/community/ documentation/development/ documentation/faqs/ documentation/subprojects/ documentation/subprojects/apache-felix-commons/ documentation/s...
Date Tue, 01 Sep 2015 06:05:20 GMT
Modified: websites/staging/felix/trunk/content/miscellaneous/cat-scan-project-proposal/cat-scan-002-profiles.html
==============================================================================
--- websites/staging/felix/trunk/content/miscellaneous/cat-scan-project-proposal/cat-scan-002-profiles.html (original)
+++ websites/staging/felix/trunk/content/miscellaneous/cat-scan-project-proposal/cat-scan-002-profiles.html Tue Sep  1 06:05:17 2015
@@ -39,7 +39,18 @@
     </div>
     
     <div class="menu"> 
-      <p><a href="/news.html">news</a>  <br />
+      <style type="text/css">
+/* The following code is added by mdx_elementid.py
+   It was originally lifted from http://subversion.apache.org/style/site.css */
+/*
+ * Hide class="elementid-permalink", except when an enclosing heading
+ * has the :hover property.
+ */
+.headerlink, .elementid-permalink {
+  visibility: hidden;
+}
+h2:hover > .headerlink, h3:hover > .headerlink, h1:hover > .headerlink, h6:hover > .headerlink, h4:hover > .headerlink, h5:hover > .headerlink, dt:hover > .elementid-permalink { visibility: visible }</style>
+<p><a href="/news.html">news</a>  <br />
 <a href="/license.html">license</a>  <br />
 <a href="/downloads.cgi">downloads</a>  <br />
 <a href="/documentation.html">documentation</a>  <br />
@@ -66,14 +77,25 @@
       </div>
 
       <h1>CAT-Scan-002 Profiles</h1>
-      <p>It does not seem reasonable to expect that all OSGi framework implementors have the time and resources to provide full CAT-Scan capabilities to their framework.  CAT-Scan offers cohesive sets of capabilities, called profiles, that increase in complexity and reporting capabilities.  The minimal set, called the Basic Profile, is required of all implementations that claim to provide CAT-Scan capabilities.</p>
-<h3 id="profiles">Profiles</h3>
+      <style type="text/css">
+/* The following code is added by mdx_elementid.py
+   It was originally lifted from http://subversion.apache.org/style/site.css */
+/*
+ * Hide class="elementid-permalink", except when an enclosing heading
+ * has the :hover property.
+ */
+.headerlink, .elementid-permalink {
+  visibility: hidden;
+}
+h2:hover > .headerlink, h3:hover > .headerlink, h1:hover > .headerlink, h6:hover > .headerlink, h4:hover > .headerlink, h5:hover > .headerlink, dt:hover > .elementid-permalink { visibility: visible }</style>
+<p>It does not seem reasonable to expect that all OSGi framework implementors have the time and resources to provide full CAT-Scan capabilities to their framework.  CAT-Scan offers cohesive sets of capabilities, called profiles, that increase in complexity and reporting capabilities.  The minimal set, called the Basic Profile, is required of all implementations that claim to provide CAT-Scan capabilities.</p>
+<h3 id="profiles">Profiles<a class="headerlink" href="#profiles" title="Permanent link">&para;</a></h3>
 <ul>
 <li><a href="/miscellaneous/cat-scan-project-proposal/cat-scan-002-profiles/cat-scan-002-001-basic-profile.html">CAT-Scan-002-001 Basic Profile</a></li>
 </ul>
 <p>{scrollbar}</p>
       <div class="timestamp" style="margin-top: 30px; font-size: 80%; text-align: right;">
-        Rev. 1422427 by fmeschbe on Sun, 16 Dec 2012 00:36:51 +0000
+        Rev. 1700393 by cziegeler on Tue, 1 Sep 2015 06:04:06 +0000
       </div>
       <div class="trademarkFooter"> 
         Apache Felix, Felix, Apache, the Apache feather logo, and the Apache Felix project

Modified: websites/staging/felix/trunk/content/miscellaneous/cat-scan-project-proposal/cat-scan-002-profiles/cat-scan-002-001-basic-profile.html
==============================================================================
--- websites/staging/felix/trunk/content/miscellaneous/cat-scan-project-proposal/cat-scan-002-profiles/cat-scan-002-001-basic-profile.html (original)
+++ websites/staging/felix/trunk/content/miscellaneous/cat-scan-project-proposal/cat-scan-002-profiles/cat-scan-002-001-basic-profile.html Tue Sep  1 06:05:17 2015
@@ -39,7 +39,18 @@
     </div>
     
     <div class="menu"> 
-      <p><a href="/news.html">news</a>  <br />
+      <style type="text/css">
+/* The following code is added by mdx_elementid.py
+   It was originally lifted from http://subversion.apache.org/style/site.css */
+/*
+ * Hide class="elementid-permalink", except when an enclosing heading
+ * has the :hover property.
+ */
+.headerlink, .elementid-permalink {
+  visibility: hidden;
+}
+h2:hover > .headerlink, h3:hover > .headerlink, h1:hover > .headerlink, h6:hover > .headerlink, h4:hover > .headerlink, h5:hover > .headerlink, dt:hover > .elementid-permalink { visibility: visible }</style>
+<p><a href="/news.html">news</a>  <br />
 <a href="/license.html">license</a>  <br />
 <a href="/downloads.cgi">downloads</a>  <br />
 <a href="/documentation.html">documentation</a>  <br />
@@ -68,7 +79,7 @@
       <h1>CAT-Scan-002-001 Basic Profile</h1>
       
       <div class="timestamp" style="margin-top: 30px; font-size: 80%; text-align: right;">
-        Rev. 1422427 by fmeschbe on Sun, 16 Dec 2012 00:36:51 +0000
+        Rev. 1700393 by cziegeler on Tue, 1 Sep 2015 06:04:06 +0000
       </div>
       <div class="trademarkFooter"> 
         Apache Felix, Felix, Apache, the Apache feather logo, and the Apache Felix project

Modified: websites/staging/felix/trunk/content/miscellaneous/cat-scan-project-proposal/cat-scan-003-run-log-archive.html
==============================================================================
--- websites/staging/felix/trunk/content/miscellaneous/cat-scan-project-proposal/cat-scan-003-run-log-archive.html (original)
+++ websites/staging/felix/trunk/content/miscellaneous/cat-scan-project-proposal/cat-scan-003-run-log-archive.html Tue Sep  1 06:05:17 2015
@@ -39,7 +39,18 @@
     </div>
     
     <div class="menu"> 
-      <p><a href="/news.html">news</a>  <br />
+      <style type="text/css">
+/* The following code is added by mdx_elementid.py
+   It was originally lifted from http://subversion.apache.org/style/site.css */
+/*
+ * Hide class="elementid-permalink", except when an enclosing heading
+ * has the :hover property.
+ */
+.headerlink, .elementid-permalink {
+  visibility: hidden;
+}
+h2:hover > .headerlink, h3:hover > .headerlink, h1:hover > .headerlink, h6:hover > .headerlink, h4:hover > .headerlink, h5:hover > .headerlink, dt:hover > .elementid-permalink { visibility: visible }</style>
+<p><a href="/news.html">news</a>  <br />
 <a href="/license.html">license</a>  <br />
 <a href="/downloads.cgi">downloads</a>  <br />
 <a href="/documentation.html">documentation</a>  <br />
@@ -66,9 +77,20 @@
       </div>
 
       <h1>CAT-Scan-003 Run-Log Archive</h1>
-      <p>{scrollbar}</p>
+      <style type="text/css">
+/* The following code is added by mdx_elementid.py
+   It was originally lifted from http://subversion.apache.org/style/site.css */
+/*
+ * Hide class="elementid-permalink", except when an enclosing heading
+ * has the :hover property.
+ */
+.headerlink, .elementid-permalink {
+  visibility: hidden;
+}
+h2:hover > .headerlink, h3:hover > .headerlink, h1:hover > .headerlink, h6:hover > .headerlink, h4:hover > .headerlink, h5:hover > .headerlink, dt:hover > .elementid-permalink { visibility: visible }</style>
+<p>{scrollbar}</p>
       <div class="timestamp" style="margin-top: 30px; font-size: 80%; text-align: right;">
-        Rev. 1422427 by fmeschbe on Sun, 16 Dec 2012 00:36:51 +0000
+        Rev. 1700393 by cziegeler on Tue, 1 Sep 2015 06:04:06 +0000
       </div>
       <div class="trademarkFooter"> 
         Apache Felix, Felix, Apache, the Apache feather logo, and the Apache Felix project

Modified: websites/staging/felix/trunk/content/miscellaneous/cat-scan-project-proposal/cat-scan-004-api-reference.html
==============================================================================
--- websites/staging/felix/trunk/content/miscellaneous/cat-scan-project-proposal/cat-scan-004-api-reference.html (original)
+++ websites/staging/felix/trunk/content/miscellaneous/cat-scan-project-proposal/cat-scan-004-api-reference.html Tue Sep  1 06:05:17 2015
@@ -39,7 +39,18 @@
     </div>
     
     <div class="menu"> 
-      <p><a href="/news.html">news</a>  <br />
+      <style type="text/css">
+/* The following code is added by mdx_elementid.py
+   It was originally lifted from http://subversion.apache.org/style/site.css */
+/*
+ * Hide class="elementid-permalink", except when an enclosing heading
+ * has the :hover property.
+ */
+.headerlink, .elementid-permalink {
+  visibility: hidden;
+}
+h2:hover > .headerlink, h3:hover > .headerlink, h1:hover > .headerlink, h6:hover > .headerlink, h4:hover > .headerlink, h5:hover > .headerlink, dt:hover > .elementid-permalink { visibility: visible }</style>
+<p><a href="/news.html">news</a>  <br />
 <a href="/license.html">license</a>  <br />
 <a href="/downloads.cgi">downloads</a>  <br />
 <a href="/documentation.html">documentation</a>  <br />
@@ -66,9 +77,20 @@
       </div>
 
       <h1>CAT-Scan-004 API Reference</h1>
-      <p>{scrollbar}</p>
+      <style type="text/css">
+/* The following code is added by mdx_elementid.py
+   It was originally lifted from http://subversion.apache.org/style/site.css */
+/*
+ * Hide class="elementid-permalink", except when an enclosing heading
+ * has the :hover property.
+ */
+.headerlink, .elementid-permalink {
+  visibility: hidden;
+}
+h2:hover > .headerlink, h3:hover > .headerlink, h1:hover > .headerlink, h6:hover > .headerlink, h4:hover > .headerlink, h5:hover > .headerlink, dt:hover > .elementid-permalink { visibility: visible }</style>
+<p>{scrollbar}</p>
       <div class="timestamp" style="margin-top: 30px; font-size: 80%; text-align: right;">
-        Rev. 1422427 by fmeschbe on Sun, 16 Dec 2012 00:36:51 +0000
+        Rev. 1700393 by cziegeler on Tue, 1 Sep 2015 06:04:06 +0000
       </div>
       <div class="trademarkFooter"> 
         Apache Felix, Felix, Apache, the Apache feather logo, and the Apache Felix project

Modified: websites/staging/felix/trunk/content/miscellaneous/cat-scan-project-proposal/cat-scan-005-technical-compatibility-kit.html
==============================================================================
--- websites/staging/felix/trunk/content/miscellaneous/cat-scan-project-proposal/cat-scan-005-technical-compatibility-kit.html (original)
+++ websites/staging/felix/trunk/content/miscellaneous/cat-scan-project-proposal/cat-scan-005-technical-compatibility-kit.html Tue Sep  1 06:05:17 2015
@@ -39,7 +39,18 @@
     </div>
     
     <div class="menu"> 
-      <p><a href="/news.html">news</a>  <br />
+      <style type="text/css">
+/* The following code is added by mdx_elementid.py
+   It was originally lifted from http://subversion.apache.org/style/site.css */
+/*
+ * Hide class="elementid-permalink", except when an enclosing heading
+ * has the :hover property.
+ */
+.headerlink, .elementid-permalink {
+  visibility: hidden;
+}
+h2:hover > .headerlink, h3:hover > .headerlink, h1:hover > .headerlink, h6:hover > .headerlink, h4:hover > .headerlink, h5:hover > .headerlink, dt:hover > .elementid-permalink { visibility: visible }</style>
+<p><a href="/news.html">news</a>  <br />
 <a href="/license.html">license</a>  <br />
 <a href="/downloads.cgi">downloads</a>  <br />
 <a href="/documentation.html">documentation</a>  <br />
@@ -66,9 +77,20 @@
       </div>
 
       <h1>CAT-Scan-005 Technical Compatibility Kit</h1>
-      <p>{scrollbar}</p>
+      <style type="text/css">
+/* The following code is added by mdx_elementid.py
+   It was originally lifted from http://subversion.apache.org/style/site.css */
+/*
+ * Hide class="elementid-permalink", except when an enclosing heading
+ * has the :hover property.
+ */
+.headerlink, .elementid-permalink {
+  visibility: hidden;
+}
+h2:hover > .headerlink, h3:hover > .headerlink, h1:hover > .headerlink, h6:hover > .headerlink, h4:hover > .headerlink, h5:hover > .headerlink, dt:hover > .elementid-permalink { visibility: visible }</style>
+<p>{scrollbar}</p>
       <div class="timestamp" style="margin-top: 30px; font-size: 80%; text-align: right;">
-        Rev. 1422427 by fmeschbe on Sun, 16 Dec 2012 00:36:51 +0000
+        Rev. 1700393 by cziegeler on Tue, 1 Sep 2015 06:04:06 +0000
       </div>
       <div class="trademarkFooter"> 
         Apache Felix, Felix, Apache, the Apache feather logo, and the Apache Felix project

Modified: websites/staging/felix/trunk/content/miscellaneous/cat-scan-project-proposal/cat-scan-006-glossary.html
==============================================================================
--- websites/staging/felix/trunk/content/miscellaneous/cat-scan-project-proposal/cat-scan-006-glossary.html (original)
+++ websites/staging/felix/trunk/content/miscellaneous/cat-scan-project-proposal/cat-scan-006-glossary.html Tue Sep  1 06:05:17 2015
@@ -39,7 +39,18 @@
     </div>
     
     <div class="menu"> 
-      <p><a href="/news.html">news</a>  <br />
+      <style type="text/css">
+/* The following code is added by mdx_elementid.py
+   It was originally lifted from http://subversion.apache.org/style/site.css */
+/*
+ * Hide class="elementid-permalink", except when an enclosing heading
+ * has the :hover property.
+ */
+.headerlink, .elementid-permalink {
+  visibility: hidden;
+}
+h2:hover > .headerlink, h3:hover > .headerlink, h1:hover > .headerlink, h6:hover > .headerlink, h4:hover > .headerlink, h5:hover > .headerlink, dt:hover > .elementid-permalink { visibility: visible }</style>
+<p><a href="/news.html">news</a>  <br />
 <a href="/license.html">license</a>  <br />
 <a href="/downloads.cgi">downloads</a>  <br />
 <a href="/documentation.html">documentation</a>  <br />
@@ -66,9 +77,20 @@
       </div>
 
       <h1>CAT-Scan-006 Glossary</h1>
-      <p>{scrollbar}</p>
+      <style type="text/css">
+/* The following code is added by mdx_elementid.py
+   It was originally lifted from http://subversion.apache.org/style/site.css */
+/*
+ * Hide class="elementid-permalink", except when an enclosing heading
+ * has the :hover property.
+ */
+.headerlink, .elementid-permalink {
+  visibility: hidden;
+}
+h2:hover > .headerlink, h3:hover > .headerlink, h1:hover > .headerlink, h6:hover > .headerlink, h4:hover > .headerlink, h5:hover > .headerlink, dt:hover > .elementid-permalink { visibility: visible }</style>
+<p>{scrollbar}</p>
       <div class="timestamp" style="margin-top: 30px; font-size: 80%; text-align: right;">
-        Rev. 1422427 by fmeschbe on Sun, 16 Dec 2012 00:36:51 +0000
+        Rev. 1700393 by cziegeler on Tue, 1 Sep 2015 06:04:06 +0000
       </div>
       <div class="trademarkFooter"> 
         Apache Felix, Felix, Apache, the Apache feather logo, and the Apache Felix project

Modified: websites/staging/felix/trunk/content/miscellaneous/cat-scan-project-proposal/cat-scan-007-references.html
==============================================================================
--- websites/staging/felix/trunk/content/miscellaneous/cat-scan-project-proposal/cat-scan-007-references.html (original)
+++ websites/staging/felix/trunk/content/miscellaneous/cat-scan-project-proposal/cat-scan-007-references.html Tue Sep  1 06:05:17 2015
@@ -39,7 +39,18 @@
     </div>
     
     <div class="menu"> 
-      <p><a href="/news.html">news</a>  <br />
+      <style type="text/css">
+/* The following code is added by mdx_elementid.py
+   It was originally lifted from http://subversion.apache.org/style/site.css */
+/*
+ * Hide class="elementid-permalink", except when an enclosing heading
+ * has the :hover property.
+ */
+.headerlink, .elementid-permalink {
+  visibility: hidden;
+}
+h2:hover > .headerlink, h3:hover > .headerlink, h1:hover > .headerlink, h6:hover > .headerlink, h4:hover > .headerlink, h5:hover > .headerlink, dt:hover > .elementid-permalink { visibility: visible }</style>
+<p><a href="/news.html">news</a>  <br />
 <a href="/license.html">license</a>  <br />
 <a href="/downloads.cgi">downloads</a>  <br />
 <a href="/documentation.html">documentation</a>  <br />
@@ -66,9 +77,20 @@
       </div>
 
       <h1>CAT-Scan-007 References</h1>
-      <p>{scrollbar}</p>
+      <style type="text/css">
+/* The following code is added by mdx_elementid.py
+   It was originally lifted from http://subversion.apache.org/style/site.css */
+/*
+ * Hide class="elementid-permalink", except when an enclosing heading
+ * has the :hover property.
+ */
+.headerlink, .elementid-permalink {
+  visibility: hidden;
+}
+h2:hover > .headerlink, h3:hover > .headerlink, h1:hover > .headerlink, h6:hover > .headerlink, h4:hover > .headerlink, h5:hover > .headerlink, dt:hover > .elementid-permalink { visibility: visible }</style>
+<p>{scrollbar}</p>
       <div class="timestamp" style="margin-top: 30px; font-size: 80%; text-align: right;">
-        Rev. 1422427 by fmeschbe on Sun, 16 Dec 2012 00:36:51 +0000
+        Rev. 1700393 by cziegeler on Tue, 1 Sep 2015 06:04:06 +0000
       </div>
       <div class="trademarkFooter"> 
         Apache Felix, Felix, Apache, the Apache feather logo, and the Apache Felix project

Modified: websites/staging/felix/trunk/content/miscellaneous/incubator-status-report-january-2007.html
==============================================================================
--- websites/staging/felix/trunk/content/miscellaneous/incubator-status-report-january-2007.html (original)
+++ websites/staging/felix/trunk/content/miscellaneous/incubator-status-report-january-2007.html Tue Sep  1 06:05:17 2015
@@ -39,7 +39,18 @@
     </div>
     
     <div class="menu"> 
-      <p><a href="/news.html">news</a>  <br />
+      <style type="text/css">
+/* The following code is added by mdx_elementid.py
+   It was originally lifted from http://subversion.apache.org/style/site.css */
+/*
+ * Hide class="elementid-permalink", except when an enclosing heading
+ * has the :hover property.
+ */
+.headerlink, .elementid-permalink {
+  visibility: hidden;
+}
+h2:hover > .headerlink, h3:hover > .headerlink, h1:hover > .headerlink, h6:hover > .headerlink, h4:hover > .headerlink, h5:hover > .headerlink, dt:hover > .elementid-permalink { visibility: visible }</style>
+<p><a href="/news.html">news</a>  <br />
 <a href="/license.html">license</a>  <br />
 <a href="/downloads.cgi">downloads</a>  <br />
 <a href="/documentation.html">documentation</a>  <br />
@@ -66,7 +77,18 @@
       </div>
 
       <h1>Incubator Status Report (January 2007)</h1>
-      <p>Community
+      <style type="text/css">
+/* The following code is added by mdx_elementid.py
+   It was originally lifted from http://subversion.apache.org/style/site.css */
+/*
+ * Hide class="elementid-permalink", except when an enclosing heading
+ * has the :hover property.
+ */
+.headerlink, .elementid-permalink {
+  visibility: hidden;
+}
+h2:hover > .headerlink, h3:hover > .headerlink, h1:hover > .headerlink, h6:hover > .headerlink, h4:hover > .headerlink, h5:hover > .headerlink, dt:hover > .elementid-permalink { visibility: visible }</style>
+<p>Community
 <em> The community is working toward incubator gradution.
 </em> Continued organization of the wiki (and generated web site), creating the subproject documentation section with new documentation on for various subprojects, including a placeholder for the Felix Commons initiative.
 <em> Voted Karl Pauls as Release Manager.
@@ -89,7 +111,7 @@
 </em> Committed OSGi Alliance Foundation source code (licensed under the Apache license), which provides stubs for javax.microedition.io, so that we can compile everything again.
 * A patch from Felix Meschberger for the URL Handlers service was put on hold since it was not clear if their were any licensing implications as a result of its inspiration from Equinox code. The patch/functionality is targeted to be resolved for the 1.0.0 release.</p>
       <div class="timestamp" style="margin-top: 30px; font-size: 80%; text-align: right;">
-        Rev. 1422427 by fmeschbe on Sun, 16 Dec 2012 00:36:51 +0000
+        Rev. 1700393 by cziegeler on Tue, 1 Sep 2015 06:04:06 +0000
       </div>
       <div class="trademarkFooter"> 
         Apache Felix, Felix, Apache, the Apache feather logo, and the Apache Felix project

Modified: websites/staging/felix/trunk/content/miscellaneous/incubator-status-report-october-2006.html
==============================================================================
--- websites/staging/felix/trunk/content/miscellaneous/incubator-status-report-october-2006.html (original)
+++ websites/staging/felix/trunk/content/miscellaneous/incubator-status-report-october-2006.html Tue Sep  1 06:05:17 2015
@@ -39,7 +39,18 @@
     </div>
     
     <div class="menu"> 
-      <p><a href="/news.html">news</a>  <br />
+      <style type="text/css">
+/* The following code is added by mdx_elementid.py
+   It was originally lifted from http://subversion.apache.org/style/site.css */
+/*
+ * Hide class="elementid-permalink", except when an enclosing heading
+ * has the :hover property.
+ */
+.headerlink, .elementid-permalink {
+  visibility: hidden;
+}
+h2:hover > .headerlink, h3:hover > .headerlink, h1:hover > .headerlink, h6:hover > .headerlink, h4:hover > .headerlink, h5:hover > .headerlink, dt:hover > .elementid-permalink { visibility: visible }</style>
+<p><a href="/news.html">news</a>  <br />
 <a href="/license.html">license</a>  <br />
 <a href="/downloads.cgi">downloads</a>  <br />
 <a href="/documentation.html">documentation</a>  <br />
@@ -66,7 +77,18 @@
       </div>
 
       <h1>Incubator Status Report (October 2006)</h1>
-      <p>Community
+      <style type="text/css">
+/* The following code is added by mdx_elementid.py
+   It was originally lifted from http://subversion.apache.org/style/site.css */
+/*
+ * Hide class="elementid-permalink", except when an enclosing heading
+ * has the :hover property.
+ */
+.headerlink, .elementid-permalink {
+  visibility: hidden;
+}
+h2:hover > .headerlink, h3:hover > .headerlink, h1:hover > .headerlink, h6:hover > .headerlink, h4:hover > .headerlink, h5:hover > .headerlink, dt:hover > .elementid-permalink { visibility: visible }</style>
+<p>Community
 <em> Proper wiki/web page created by Marcel Offermans and Ronald Spierenburg.
 </em> Manuel Santillán, Jose L. Ruiz, and Juan C. Dueñas added as committers for their work with JMX and OSGi (i.e., JMood).
 * Didier Donsez added as a committer for his long-time work around OSGi and Felix.</p>
@@ -83,7 +105,7 @@
 <em> Attempt for gradution was post-poned to concentrate on creating a release that addresses any and all outstanding obstacles for release.
 </em> Removed javax.microedition.io dependency for the time being until a proper licensed version is available from the OSGi Alliance.</p>
       <div class="timestamp" style="margin-top: 30px; font-size: 80%; text-align: right;">
-        Rev. 1422427 by fmeschbe on Sun, 16 Dec 2012 00:36:51 +0000
+        Rev. 1700393 by cziegeler on Tue, 1 Sep 2015 06:04:06 +0000
       </div>
       <div class="trademarkFooter"> 
         Apache Felix, Felix, Apache, the Apache feather logo, and the Apache Felix project

Modified: websites/staging/felix/trunk/content/miscellaneous/osgi-bundle-service-diagrams.html
==============================================================================
--- websites/staging/felix/trunk/content/miscellaneous/osgi-bundle-service-diagrams.html (original)
+++ websites/staging/felix/trunk/content/miscellaneous/osgi-bundle-service-diagrams.html Tue Sep  1 06:05:17 2015
@@ -39,7 +39,18 @@
     </div>
     
     <div class="menu"> 
-      <p><a href="/news.html">news</a>  <br />
+      <style type="text/css">
+/* The following code is added by mdx_elementid.py
+   It was originally lifted from http://subversion.apache.org/style/site.css */
+/*
+ * Hide class="elementid-permalink", except when an enclosing heading
+ * has the :hover property.
+ */
+.headerlink, .elementid-permalink {
+  visibility: hidden;
+}
+h2:hover > .headerlink, h3:hover > .headerlink, h1:hover > .headerlink, h6:hover > .headerlink, h4:hover > .headerlink, h5:hover > .headerlink, dt:hover > .elementid-permalink { visibility: visible }</style>
+<p><a href="/news.html">news</a>  <br />
 <a href="/license.html">license</a>  <br />
 <a href="/downloads.cgi">downloads</a>  <br />
 <a href="/documentation.html">documentation</a>  <br />
@@ -66,7 +77,18 @@
       </div>
 
       <h1>OSGi Bundle-Service Diagrams</h1>
-      <p>!bundle-services.jpg|align=center!</p>
+      <style type="text/css">
+/* The following code is added by mdx_elementid.py
+   It was originally lifted from http://subversion.apache.org/style/site.css */
+/*
+ * Hide class="elementid-permalink", except when an enclosing heading
+ * has the :hover property.
+ */
+.headerlink, .elementid-permalink {
+  visibility: hidden;
+}
+h2:hover > .headerlink, h3:hover > .headerlink, h1:hover > .headerlink, h6:hover > .headerlink, h4:hover > .headerlink, h5:hover > .headerlink, dt:hover > .elementid-permalink { visibility: visible }</style>
+<p>!bundle-services.jpg|align=center!</p>
 <p>From Peter Kriens' blog on {link:Bundle-Service Diagrams | http://www.osgi.org/blog/2006/04/details-are-important-when-you-are.html}:
 {quote}
 ... use a circle for a bundle and a triangle for a service.  The service can be used in 3 different ways by a bundle, and this needs to be depicted:</p>
@@ -75,14 +97,13 @@
 <li>Implementer - The bundle that implements the service must register it. This is depicted by drawing a line to a corner of the triangle. An OSGi service can be registered many times by the same or different bundles.</li>
 <li>Listener - A listener bundle connects to one of the angled lines of the triangle. A listener is notified of registrations, modifications and unregistrations of the service. A service can have many listeners.</li>
 </ol>
-<p>A service is identified by its <em>interface</em>.
-{quote}</p>
-<h2 id="materials">Materials</h2>
+<p quote="quote">A service is identified by its <em>interface</em>.</p>
+<h2 id="materials">Materials<a class="headerlink" href="#materials" title="Permanent link">&para;</a></h2>
 <ul>
 <li><a href="">Bundle-Service Diagram Dia Diagram Editor file</a></li>
 </ul>
       <div class="timestamp" style="margin-top: 30px; font-size: 80%; text-align: right;">
-        Rev. 1422427 by fmeschbe on Sun, 16 Dec 2012 00:36:51 +0000
+        Rev. 1700393 by cziegeler on Tue, 1 Sep 2015 06:04:06 +0000
       </div>
       <div class="trademarkFooter"> 
         Apache Felix, Felix, Apache, the Apache feather logo, and the Apache Felix project

Modified: websites/staging/felix/trunk/content/miscellaneous/sandbox.html
==============================================================================
--- websites/staging/felix/trunk/content/miscellaneous/sandbox.html (original)
+++ websites/staging/felix/trunk/content/miscellaneous/sandbox.html Tue Sep  1 06:05:17 2015
@@ -39,7 +39,18 @@
     </div>
     
     <div class="menu"> 
-      <p><a href="/news.html">news</a>  <br />
+      <style type="text/css">
+/* The following code is added by mdx_elementid.py
+   It was originally lifted from http://subversion.apache.org/style/site.css */
+/*
+ * Hide class="elementid-permalink", except when an enclosing heading
+ * has the :hover property.
+ */
+.headerlink, .elementid-permalink {
+  visibility: hidden;
+}
+h2:hover > .headerlink, h3:hover > .headerlink, h1:hover > .headerlink, h6:hover > .headerlink, h4:hover > .headerlink, h5:hover > .headerlink, dt:hover > .elementid-permalink { visibility: visible }</style>
+<p><a href="/news.html">news</a>  <br />
 <a href="/license.html">license</a>  <br />
 <a href="/downloads.cgi">downloads</a>  <br />
 <a href="/documentation.html">documentation</a>  <br />
@@ -66,9 +77,20 @@
       </div>
 
       <h1>Sandbox</h1>
-      <p>Place to put pages documenting sandbox development.</p>
+      <style type="text/css">
+/* The following code is added by mdx_elementid.py
+   It was originally lifted from http://subversion.apache.org/style/site.css */
+/*
+ * Hide class="elementid-permalink", except when an enclosing heading
+ * has the :hover property.
+ */
+.headerlink, .elementid-permalink {
+  visibility: hidden;
+}
+h2:hover > .headerlink, h3:hover > .headerlink, h1:hover > .headerlink, h6:hover > .headerlink, h4:hover > .headerlink, h5:hover > .headerlink, dt:hover > .elementid-permalink { visibility: visible }</style>
+<p>Place to put pages documenting sandbox development.</p>
       <div class="timestamp" style="margin-top: 30px; font-size: 80%; text-align: right;">
-        Rev. 1422427 by fmeschbe on Sun, 16 Dec 2012 00:36:51 +0000
+        Rev. 1700393 by cziegeler on Tue, 1 Sep 2015 06:04:06 +0000
       </div>
       <div class="trademarkFooter"> 
         Apache Felix, Felix, Apache, the Apache feather logo, and the Apache Felix project

Modified: websites/staging/felix/trunk/content/miscellaneous/sandbox/composite-bundles.html
==============================================================================
--- websites/staging/felix/trunk/content/miscellaneous/sandbox/composite-bundles.html (original)
+++ websites/staging/felix/trunk/content/miscellaneous/sandbox/composite-bundles.html Tue Sep  1 06:05:17 2015
@@ -39,7 +39,18 @@
     </div>
     
     <div class="menu"> 
-      <p><a href="/news.html">news</a>  <br />
+      <style type="text/css">
+/* The following code is added by mdx_elementid.py
+   It was originally lifted from http://subversion.apache.org/style/site.css */
+/*
+ * Hide class="elementid-permalink", except when an enclosing heading
+ * has the :hover property.
+ */
+.headerlink, .elementid-permalink {
+  visibility: hidden;
+}
+h2:hover > .headerlink, h3:hover > .headerlink, h1:hover > .headerlink, h6:hover > .headerlink, h4:hover > .headerlink, h5:hover > .headerlink, dt:hover > .elementid-permalink { visibility: visible }</style>
+<p><a href="/news.html">news</a>  <br />
 <a href="/license.html">license</a>  <br />
 <a href="/downloads.cgi">downloads</a>  <br />
 <a href="/documentation.html">documentation</a>  <br />
@@ -66,7 +77,18 @@
       </div>
 
       <h1>Composite Bundles</h1>
-      <h1 id="1-overview">1. Overview</h1>
+      <style type="text/css">
+/* The following code is added by mdx_elementid.py
+   It was originally lifted from http://subversion.apache.org/style/site.css */
+/*
+ * Hide class="elementid-permalink", except when an enclosing heading
+ * has the :hover property.
+ */
+.headerlink, .elementid-permalink {
+  visibility: hidden;
+}
+h2:hover > .headerlink, h3:hover > .headerlink, h1:hover > .headerlink, h6:hover > .headerlink, h4:hover > .headerlink, h5:hover > .headerlink, dt:hover > .elementid-permalink { visibility: visible }</style>
+<h1 id="1-overview">1. Overview<a class="headerlink" href="#1-overview" title="Permanent link">&para;</a></h1>
 <p>The OSGi framework supports deploying bundles into a flat and basically globally bundle space. The idea behind this approach can be summarized as, "the deployed set of bundles is your application configuration." This approach has performed well over the years; however, as OSGi technology is used in more and more complicated scenarios, this approach is not always sufficient. For example, when trying to run multiple applications in a single framework instance or when applications become so large that sets of bundles start mapping onto logical subsystems. In these types of situations, it is possible for the configurations of different applications or subsystems to interfere with each other. To address such issues, this proposal introduces a composite bundle concept built on top of virtual bundles.</p>
 <p>The two main goals of this proposal are:</p>
 <ol>
@@ -74,7 +96,7 @@
 <li>To implement this mechanism as a layer above the framework.</li>
 </ol>
 <p>The remainder of this proposal describes the technical approach for achieving these two goals.</p>
-<h1 id="2-use-cases">2. Use cases</h1>
+<h1 id="2-use-cases">2. Use cases<a class="headerlink" href="#2-use-cases" title="Permanent link">&para;</a></h1>
 <p>Some potential use cases for composite bundles:</p>
 <ul>
 <li>Large application subsystems can be modeled as a composite bundle.</li>
@@ -83,7 +105,7 @@
 <li>Groups of bundles needing lifecycle management as a whole can be modeled as a composite bundle.</li>
 </ul>
 <p>This list is not intended to be exhaustive.</p>
-<h1 id="3-terminology">3. Terminology</h1>
+<h1 id="3-terminology">3. Terminology<a class="headerlink" href="#3-terminology" title="Permanent link">&para;</a></h1>
 <p>The following terms are used in this document:</p>
 <ul>
 <li>Composite bundle - a bundle whose contents is actually a set of bundles that appear to be running inside of another framework instance.</li>
@@ -92,7 +114,7 @@
 <li>Required bundle - a bundle required by a composite bundle from the parent framework.</li>
 <li>Provided bundle - a constituent bundle from a composite bundle made available in the parent framework. </li>
 </ul>
-<h1 id="4-technical-approach">4. Technical approach</h1>
+<h1 id="4-technical-approach">4. Technical approach<a class="headerlink" href="#4-technical-approach" title="Permanent link">&para;</a></h1>
 <p>The overall technical approach is to use the virtual bundle concept (proposed separately) to manage composite bundles as a layer above the framework. This proposal forgoes an API-based approach to support a simple, declarative approach. The technical approach is divided into two halves:</p>
 <ol>
 <li>A simple composite model that supports only package and service sharing.</li>
@@ -100,9 +122,9 @@
 </ol>
 <p>NOTE 1: The purpose is not to actually treat the two models as separate entities, but to more clearly illustrate the extra cost in complexity by supporting transparency.</p>
 <p>NOTE 2: Although this document is API-less, the goal is not to completely rule out any API, but to keep things simple until some real-world experience is gained at which point API could potentially be introduced.</p>
-<h2 id="41-simple-composite-model">4.1 Simple composite model</h2>
+<h2 id="41-simple-composite-model">4.1 Simple composite model<a class="headerlink" href="#41-simple-composite-model" title="Permanent link">&para;</a></h2>
 <p>The simple composite model supports installing groups of bundles as a single composite bundle with the ability to import packages/services from the parent framework into the composite bundle and to export packages/services from the composite bundle to the parent framework. The lifecycle of the constituent bundles are managed by the lifecycle of the composite bundle in the parent framework.</p>
-<h3 id="411-simple-composite-description">4.1.1 Simple composite description</h3>
+<h3 id="411-simple-composite-description">4.1.1 Simple composite description<a class="headerlink" href="#411-simple-composite-description" title="Permanent link">&para;</a></h3>
 <p>A composite bundle is declared using a set of manifest-like headers, which is familiar to bundle developers and fits well with the virtual bundle proposal, where virtual bundles are installed with a given set of headers. The following headers are reused for declaring a composite bundle:</p>
 <ul>
 <li><code>Import-Package</code> - the packages imported by the composite bundle from the parent framework.</li>
@@ -135,9 +157,9 @@
 <p>These declarative headers define the entire capabilities of a simple composite bundle. To summarize, these capabilities are: containing bundles, importing/exporting packages, and importing/exporting services.</p>
 <p>NOTE 1: It is not clear if <code>Import-Package</code> should essentially support an "export as" directive where the composite creator explicitly specifies how the imported package gets converted to an export internally or if this should be somehow automatically derived from the actual injected wire. If the latter, then this relates to the rich wiring section in the open issues.</p>
 <p>NOTE 2: Any "uses" constraints for the composite bundle's exported packages must be specified in the metadata, which will be used by parent framework to ensure consistency like normal.</p>
-<h3 id="412-simple-composite-lifecycle-management">4.1.2 Simple composite lifecycle management</h3>
+<h3 id="412-simple-composite-lifecycle-management">4.1.2 Simple composite lifecycle management<a class="headerlink" href="#412-simple-composite-lifecycle-management" title="Permanent link">&para;</a></h3>
 <p>Since composite bundles are implemented as virtual bundles, access to their content and portions of their lifecycle are controlled by an external manager. This section describes various lifecycle management issues for simple composite bundles.</p>
-<h4 id="4121-composite-manager">4.1.2.1 Composite manager</h4>
+<h4 id="4121-composite-manager">4.1.2.1 Composite manager<a class="headerlink" href="#4121-composite-manager" title="Permanent link">&para;</a></h4>
 <p>The composite manager results from the use of virtual bundles and is largely responsible for realizing the capabilities embodied in the composite description. This means it is the composite manager's responsibility to:</p>
 <ul>
 <li>Manage a composite bundle's constituent bundles.</li>
@@ -146,27 +168,27 @@
 <li>Manage the overall lifecycle of composite bundles.</li>
 </ul>
 <p>The precise approach the composite manager uses to accomplish these responsibilities is not specified, but one potential approach is for the composite manager to create a separate framework instance for each composite bundle. Another approach would be to create a static wiring of the constituent bundles and just mimic framework behavior for them.</p>
-<h4 id="4122-installing-composites">4.1.2.2 Installing composites</h4>
+<h4 id="4122-installing-composites">4.1.2.2 Installing composites<a class="headerlink" href="#4122-installing-composites" title="Permanent link">&para;</a></h4>
 <p>If an "install hook" is introduced in the virtual bundle proposal, then the composite manager can use it to seamlessly install composite bundles via the <code>BundleContext.installBundle()</code> method like a normal bundle. If install hooks are not proposed, then it could provide a simple service for installing composites. A composite is installed with a complete composite description, which forms the manifest of the installed virtual bundle. As such, composite installation is effectively atomic from the perspective of the parent framework.</p>
-<h4 id="4123-resolving-composites">4.1.2.3 Resolving composites</h4>
+<h4 id="4123-resolving-composites">4.1.2.3 Resolving composites<a class="headerlink" href="#4123-resolving-composites" title="Permanent link">&para;</a></h4>
 <p>The composite bundle's wires for its imported packages are injected into the composite's virtual module by the framework, like for all virtual bundles. The composite manager uses these wires for delegation purposes out to the parent framework for the constituent bundles. If a composite bundle is resolved, then it is possible to load classes from it.</p>
 <p>NOTE: Resolving a composite bundle could actually be combined with some sort of verification step, where the manager verifies whether or not the composite bundle can provide what it says it can provide. It is not clear if this needs to be specified, since such verification does not happen for normal bundles. In other words, it is a reasonable approach to just trust the metadata.</p>
-<h4 id="4124-starting-and-stopping-composites">4.1.2.4 Starting and stopping composites</h4>
+<h4 id="4124-starting-and-stopping-composites">4.1.2.4 Starting and stopping composites<a class="headerlink" href="#4124-starting-and-stopping-composites" title="Permanent link">&para;</a></h4>
 <p>Starting a composite bundle starts all internal constituent bundles. Likewise, stopping a composite bundle stops all constituent bundles. Composite bundles do not have user-defined activators, although the composite manager may make use of an activator. For active composites, the composite manager must provide constituent bundles access to services imported from the parent framework and must make exported services available in the parent framework. Conversely, when a composite bundle is no longer active, it must stop providing access to these services.</p>
 <p>After a composite bundle is stopped, it should remain resolved and continue to provide access to its exported packages.</p>
 <p>NOTE: Since this proposal does not propose an API to expose the constituent bundles, individual lifecycle manipulation of the constituent bundles is not expected. To keep things simple, constituent bundles are either active or not based on the state of their composite bundle. If more fine-grained control is required it would be possible. Starting and stopping individual constituent bundles would offer no real issue, although allowing them to be refreshed or uninstalled might cause the composite manager to force the outer composite bundle to refresh if the export signature is impacted.</p>
-<h4 id="4125-updating-a-composite">4.1.2.5 Updating a composite</h4>
+<h4 id="4125-updating-a-composite">4.1.2.5 Updating a composite<a class="headerlink" href="#4125-updating-a-composite" title="Permanent link">&para;</a></h4>
 <p>When a composite bundle is updated, the composite manager must continue to support the associated virtual module; i.e., it must still be possible to load classes from it. At the point in time when the bundle is refreshed and returned to the installed state, then the composite manager can dispose of the old virtual module. If the composite was updated to a normal bundle (or a different kind of virtual bundle), then the composite manager will no longer manage it. On the other hand, if was updated to another composite bundle, then the composite manager will reinstall a new virtual module for it.</p>
-<h4 id="4126-uninstalling-a-composite">4.1.2.6 Uninstalling a composite</h4>
+<h4 id="4126-uninstalling-a-composite">4.1.2.6 Uninstalling a composite<a class="headerlink" href="#4126-uninstalling-a-composite" title="Permanent link">&para;</a></h4>
 <p>When a bundle is uninstalled, that does not mean that it is no longer in use by the framework, since it must still be possible to load classes from it. Unfortunately, the framework provides no additional callbacks or state changes to notify when it is really done with an uninstalled bundle. As a result, if a composite bundle is uninstalled, the composite manager must immediately refresh it to perform proper clean up, since it will not get a later lifecycle callback when the uninstalled bundle is eventually refreshed.</p>
 <p>NOTE: This could be improved with a <code>VirtualModule.dispose()</code> method, which would be invoked by the framework to indicate when it was done with the virtual module.</p>
-<h4 id="4127-refreshing-a-composite">4.1.2.7 Refreshing a composite</h4>
+<h4 id="4127-refreshing-a-composite">4.1.2.7 Refreshing a composite<a class="headerlink" href="#4127-refreshing-a-composite" title="Permanent link">&para;</a></h4>
 <p>When refreshing a composite bundle, all constituent bundles are refreshed and the composite bundle returns to the installed state. Following normal framework behavior, any bundles depending on the composite bundle will also be refreshed. Likewise, if the composite bundle depends on another bundle being refreshed in the parent framework, then it too will be refreshed.</p>
-<h4 id="4128-relationship-to-composite-manager-lifecycle">4.1.2.8 Relationship to composite manager lifecycle</h4>
+<h4 id="4128-relationship-to-composite-manager-lifecycle">4.1.2.8 Relationship to composite manager lifecycle<a class="headerlink" href="#4128-relationship-to-composite-manager-lifecycle" title="Permanent link">&para;</a></h4>
 <p>Since the composite manager manages all aspects of the composite's content, its active lifetime scopes its managed composites. In other words, if the composite manager is stopped, then it explicitly causes all of its managed composites to refresh and return to the installed state.</p>
-<h2 id="42-transparent-composite-model">4.2 Transparent composite model</h2>
+<h2 id="42-transparent-composite-model">4.2 Transparent composite model<a class="headerlink" href="#42-transparent-composite-model" title="Permanent link">&para;</a></h2>
 <p>The simple composite model fits fairly well within the constraints of the OSGi framework since it aligns well with the concepts embodied in the original OSGi specification (i.e., packages and services). However, some use cases may require support beyond these original concepts. For such cases, this proposal defines a transparent composite model that extends the simple composite model to include additional support for provided and required bundles at the expense of added complexity.</p>
-<h3 id="421-transparent-composite-description">4.2.1 Transparent composite description</h3>
+<h3 id="421-transparent-composite-description">4.2.1 Transparent composite description<a class="headerlink" href="#421-transparent-composite-description" title="Permanent link">&para;</a></h3>
 <p>Transparent composite bundles can require bundles using the following header:</p>
 <ul>
 <li><code>Require-Bundle</code> - the bundles required by the composite from the parent framework.</li>
@@ -176,12 +198,12 @@
 <li><code>Provide-Bundle</code> - a comma-delimited set of symbolic names specifying the constituent bundles provided by the composite bundle to the parent framework.</li>
 </ul>
 <p>The provided bundles will be manifested in the parent framework as virtual bundles themselves. This means that in addition to the composite bundle in the parent framework, there will ultimately be additional virtual bundles installed by the composite manager for each provided bundle; since this is related to the transparent composite bundle lifecycle, more details will be present in the next section.</p>
-<h3 id="422-transparent-composite-lifecycle-management">4.2.2 Transparent composite lifecycle management</h3>
+<h3 id="422-transparent-composite-lifecycle-management">4.2.2 Transparent composite lifecycle management<a class="headerlink" href="#422-transparent-composite-lifecycle-management" title="Permanent link">&para;</a></h3>
 <p>To provide access to constituent bundles into the parent framework, the composite manager must proxy provided constituent bundles as separate virtual bundles in the parent framework. This complicates lifecycle management since it creates separate points of control for the composite bundle and it also complicates maintaining class space consistency for clients of the provided bundle. This section discusses these issues in more detail.</p>
 <p>NOTE: Depending on how composite bundles are implemented, these issues may also apply to required bundles inside the composite bundle.</p>
-<h4 id="4221-two-phase-resolve">4.2.2.1 Two-phase resolve</h4>
+<h4 id="4221-two-phase-resolve">4.2.2.1 Two-phase resolve<a class="headerlink" href="#4221-two-phase-resolve" title="Permanent link">&para;</a></h4>
 <p>When a composite providing access to a constituent bundle is first installed, the provided bundle cannot be made available immediately. Once the composite bundle is resolved (i.e., the composite's associated virtual module is injected with its wires), then the composite manager can install a virtual bundle proxying the provided bundle. At this point, the proxy provided bundle is available for use by other bundles in the parent framework, although it will still be in the installed state in the parent until someone actually causes it to resolve. However, resolving the proxy provided bundle technically has no real effect since it is actually resolved internal to the composite.</p>
-<h4 id="4222-maintaining-class-space-consistency">4.2.2.2 Maintaining class space consistency</h4>
+<h4 id="4222-maintaining-class-space-consistency">4.2.2.2 Maintaining class space consistency<a class="headerlink" href="#4222-maintaining-class-space-consistency" title="Permanent link">&para;</a></h4>
 <p>If the packages exported by a provided bundle do not have uses constraints or if the uses constraints are confined to other packages exported by the provided bundle itself, then the proxying described in the last section is sufficient to provide access in the parent framework. On the other hand, if the provided bundle's exported packages have uses constraints on packages imported by the provided bundle, then this poses a potential issue for clients of the proxy provided bundle in the parent framework. The provided bundle's uses constraints must be modeled in the parent framework so it can maintain class space consistency.</p>
 <p>To achieve this, when such a situation is detected, the composite manager must install an additional virtual bundle in the parent framework that acts as a uses constraint proxy bundle by exporting any packages imported by the provided bundle that are part of a uses constraint. Additionally, the proxy provided bundle must be generated such that it explicitly imports its packages from the uses constraint proxy bundle in the parent framework. This will ensure the parent framework correct observes the uses constraints and enforces them for potential clients. To clarify via an example, consider the following hypothetical (and completely irrational) composite description:</p>
 <div class="codehilite"><pre><span class="n">Bundle</span><span class="o">-</span><span class="n">ManifestVersion</span><span class="p">:</span> 2
@@ -225,19 +247,19 @@
 <p>If a composite provides multiple bundles, then shared and potentially conflicting packages among the provided bundles would need to be correctly modeled. For each provided bundle, a package space would need to be calculated for any imported package participating in a uses constraint. Any common packages with the same provider among the provided bundles would need to be modeled on a common uses constraint bundle in the parent framework, where the same package coming from different providers would need to be modeled with a separate uses constraint bundles. Non-overlapping packages could be lumped into a single uses constraint bundle. This algorithm would be non-trivial, but since it is just walking existing wires, it should not suffer from similar performance issues like the resolver algorithm.</p>
 <p>One special case to note, if the provided bundle has a uses constraint on an imported package that was actually imported from the parent framework via the composite description, then it is not necessary to model this import in the parent framework since it already exists. For this case, the generated proxy provided bundle must simply explicitly import the package from the original bundle in the parent framework.</p>
 <p>NOTE: This approach requires richer wiring information as discussed in the open issues.</p>
-<h4 id="4223-lifecycle-of-proxied-bundles">4.2.2.3 Lifecycle of proxied bundles</h4>
+<h4 id="4223-lifecycle-of-proxied-bundles">4.2.2.3 Lifecycle of proxied bundles<a class="headerlink" href="#4223-lifecycle-of-proxied-bundles" title="Permanent link">&para;</a></h4>
 <p>As discussed, the support for providing bundles results in the composite manager installing proxy bundles for the provided bundle and its uses constraints in the parent framework in addition to the original composite bundle. This raises questions about the lifecycle of proxied bundles.</p>
 <p>The lifetime of the proxied bundles is dependent on the resolved lifetime of the associated composite bundle. If the composite is refreshed, then the provided bundles should be uninstalled and refreshed. (Technically, it would be possible to simply refresh them and leave them unresolvable.)</p>
 <p>Performing individual lifecycle operations on the proxied bundles should function like normal in the parent framework, but should have no impact on the internal constituent bundles of the composite. For example, you can start, stop, and even uninstall provided bundles, but this just impacts the state of the bundles in the parent framework, which may render them unresolvable.</p>
-<h1 id="5-open-issues">5. Open issues</h1>
-<h2 id="51-rich-wiring-information">5.1 Rich wiring information</h2>
+<h1 id="5-open-issues">5. Open issues<a class="headerlink" href="#5-open-issues" title="Permanent link">&para;</a></h1>
+<h2 id="51-rich-wiring-information">5.1 Rich wiring information<a class="headerlink" href="#51-rich-wiring-information" title="Permanent link">&para;</a></h2>
 <p>Currently, the wiring information provided by the virtual bundle proposal has been kept purposely simplistic. To fully implement aspects of composites, like requiring/providing bundles, it is necessary to get richer information from the wires, such as the type of capability. Further, the wiring information needs to be at the module-level (i.e., bundle revision level), not at the bundle level. The refactoring of the Package Admin API addresses some of these issues, but not all of them.</p>
-<h1 id="6-considered-alternatives">6. Considered alternatives</h1>
-<h2 id="scoping-approach">Scoping approach</h2>
+<h1 id="6-considered-alternatives">6. Considered alternatives<a class="headerlink" href="#6-considered-alternatives" title="Permanent link">&para;</a></h1>
+<h2 id="scoping-approach">Scoping approach<a class="headerlink" href="#scoping-approach" title="Permanent link">&para;</a></h2>
 <p>Another potential approach for providing similar capabilities is to try to use virtual bundles to implement a scoping approach. Scoping can be modeled reasonably well as manifest rewriting (i.e., mandatory attributes and renaming). If it were possible to install bundles and "lock" them in the <code>INSTALLED</code> state, then these bundles could be used like templates for creating scopes via manifest rewriting in a virtual bundle. The same template bundle could be copied into different scopes using different virtual bundles in the different scopes or could be shared among scopes by appropriately rewriting the metadata. This approach could also scope the service registry, since it would be possible to inject proxied bundle contexts into the scoped bundles (via their virtual bundle wrapper) that only show services in the appropriate scope.</p>
 <p>The biggest issue here is achieving complete fidelity with the OSGi specification for handling of bundles. The virtual bundle mechanism would need to include support for dynamic imports, fragments, and lazy activation. All of these are potentially feasible, but would need to be fleshed out.</p>
       <div class="timestamp" style="margin-top: 30px; font-size: 80%; text-align: right;">
-        Rev. 1422427 by fmeschbe on Sun, 16 Dec 2012 00:36:51 +0000
+        Rev. 1700393 by cziegeler on Tue, 1 Sep 2015 06:04:06 +0000
       </div>
       <div class="trademarkFooter"> 
         Apache Felix, Felix, Apache, the Apache feather logo, and the Apache Felix project

Modified: websites/staging/felix/trunk/content/miscellaneous/sandbox/virtual-bundles.html
==============================================================================
--- websites/staging/felix/trunk/content/miscellaneous/sandbox/virtual-bundles.html (original)
+++ websites/staging/felix/trunk/content/miscellaneous/sandbox/virtual-bundles.html Tue Sep  1 06:05:17 2015
@@ -39,7 +39,18 @@
     </div>
     
     <div class="menu"> 
-      <p><a href="/news.html">news</a>  <br />
+      <style type="text/css">
+/* The following code is added by mdx_elementid.py
+   It was originally lifted from http://subversion.apache.org/style/site.css */
+/*
+ * Hide class="elementid-permalink", except when an enclosing heading
+ * has the :hover property.
+ */
+.headerlink, .elementid-permalink {
+  visibility: hidden;
+}
+h2:hover > .headerlink, h3:hover > .headerlink, h1:hover > .headerlink, h6:hover > .headerlink, h4:hover > .headerlink, h5:hover > .headerlink, dt:hover > .elementid-permalink { visibility: visible }</style>
+<p><a href="/news.html">news</a>  <br />
 <a href="/license.html">license</a>  <br />
 <a href="/downloads.cgi">downloads</a>  <br />
 <a href="/documentation.html">documentation</a>  <br />
@@ -66,11 +77,22 @@
       </div>
 
       <h1>Virtual Bundles</h1>
-      <h1 id="overview">Overview</h1>
+      <style type="text/css">
+/* The following code is added by mdx_elementid.py
+   It was originally lifted from http://subversion.apache.org/style/site.css */
+/*
+ * Hide class="elementid-permalink", except when an enclosing heading
+ * has the :hover property.
+ */
+.headerlink, .elementid-permalink {
+  visibility: hidden;
+}
+h2:hover > .headerlink, h3:hover > .headerlink, h1:hover > .headerlink, h6:hover > .headerlink, h4:hover > .headerlink, h5:hover > .headerlink, dt:hover > .elementid-permalink { visibility: visible }</style>
+<h1 id="overview">Overview<a class="headerlink" href="#overview" title="Permanent link">&para;</a></h1>
 <p>The OSGi framework supports deploying and managing bundles, which are reusable units of code and resources. Although the OSGi specification does not explicitly require bundles to be packaged as JAR files, it does require that bundles look like JAR files (i.e., they have a manifest and named byte entries). For the most part, this abstraction as worked well and has allowed framework implementations to support other archive formats and even install-by-reference semantics (to some degree). However, there are limitations limitations as to what can be achieved by this approach.</p>
 <p>The “JAR abstraction” employed by the OSGi specification for bundles requires that the framework is always in control of all aspects of class loading (e.g., searching for bytes, defining classes from bytes, etc.). While this makes sense since the framework must enforce consistency, it limits the framework to scenarios where a bundle can be modeled as a JAR file. Overall, this limitation might not seem so onerous, but the result is that every new requirement that comes along at the bundle level results in modifications (and bloating) of the core framework specification.</p>
 <p>To avoid bloat and added conceptual complexity, this proposal introduces the primitive concept of a virtual bundle to the OSGi framework. A virtual bundle can quite succinctly be described as a bundle whose content is not managed by the framework. More specifically, the idea is to weaken the “JAR abstraction” where the framework expects to have access to byte entries in an archive and instead allow another entity to manage entry access and more importantly bundle class loading. The ultimate goal is to reduce the need to modify the framework to support niche requirements by enabling their support in upper layers.</p>
-<h1 id="use-cases">Use cases</h1>
+<h1 id="use-cases">Use cases<a class="headerlink" href="#use-cases" title="Permanent link">&para;</a></h1>
 <p>Some potential use cases for virtual bundles:</p>
 <ul>
 <li>Composite bundles – virtual bundles could wrap a composite bundle concept (i.e., a bundle composed of other bundles).</li>
@@ -81,7 +103,7 @@
 <li>Exotic use cases – for example, supporting bundles whose class path refers to external content.</li>
 </ul>
 <p>This is not a complete list of use cases, but provides some potential examples.</p>
-<h1 id="terminology">Terminology</h1>
+<h1 id="terminology">Terminology<a class="headerlink" href="#terminology" title="Permanent link">&para;</a></h1>
 <p>The following terms are used in this document:</p>
 <ul>
 <li>bundle – a normal, framework-managed bundle.</li>
@@ -93,13 +115,13 @@
 <li>management object – the object injected by the manager into the framework to manage the virtual bundle's content (this is an implementation of <code>VirtualModule</code> as will be described shortly).</li>
 <li>manager-owned class loader – this term is used to indicate that the associated class loader comes from a third party.</li>
 </ul>
-<h1 id="technical-approach">Technical approach</h1>
+<h1 id="technical-approach">Technical approach<a class="headerlink" href="#technical-approach" title="Permanent link">&para;</a></h1>
 <p>To support a virtual bundle concept, we need to introduce a few new interfaces to manage access to the virtual bundle's content and to provide it access to its own wiring state. This section discusses these interfaces as well as other technical issues.</p>
-<h2 id="proposed-api">Proposed API</h2>
+<h2 id="proposed-api">Proposed API<a class="headerlink" href="#proposed-api" title="Permanent link">&para;</a></h2>
 <p>This proposal defines the following new interfaces and/or augmentations to existing interfaces to support adding a virtual bundle concept to the framework.</p>
 <p>NOTE 1: The package name used for this prototype is <code>org.apache.felix.framework.ext</code> to avoid an IP issues regarding the development of the prototype in the open at Apache Felix. If we want to change it to the <code>org.osgi.framework</code> namespace, we need some way of making timely updates of the proposed packages available to the public.</p>
 <p>NOTE 2: All names in this document (e.g., interfaces, methods, etc.) are subject to change and were merely chosen for the purposes of making progress on the prototype.</p>
-<h2 id="virtualmodule"><code>VirtualModule</code></h2>
+<h2 id="virtualmodule"><code>VirtualModule</code><a class="headerlink" href="#virtualmodule" title="Permanent link">&para;</a></h2>
 <p>The <code>VirtualModule</code> interface abstracts access to the virtual bundle's content and is the management object handling content access. The name might seem confusing, but results from how framework implementations must handle bundles. Normally in the OSGi framework, a bundle is not necessarily associated with a single bundle archive; instead, it may have multiple archives associated with it at run time depending on whether it has been updated or not. In the Felix framework implementation, we call these things modules and this naming was chosen for that reason:</p>
 <div class="codehilite"><pre>    <span class="n">public</span> <span class="n">interface</span> <span class="n">VirtualModule</span> <span class="p">{</span>
         <span class="n">void</span> <span class="n">resolve</span><span class="p">(</span><span class="n">Wire</span> <span class="n">bootWire</span><span class="p">,</span> <span class="n">List</span><span class="o">&lt;</span><span class="n">Wire</span><span class="o">&gt;</span> <span class="n">wires</span><span class="p">)</span> <span class="n">throws</span> <span class="n">BundleException</span><span class="p">;</span>
@@ -120,7 +142,7 @@
 <p>NOTE 1: Technically, we could merge <code>bootWire</code> into <code>wires</code> or we could eliminate wires and just have a single <code>delegateWire</code> that wraps the actual wires.</p>
 <p>For clarity, the class- and resource-related methods take into account wiring delegation; the entry-related methods do not. This is similar for normal bundles.</p>
 <p>NOTE 2: We could potentially use a <code>dispose()</code> method that is called when the framework is really done with the virtual module (i.e., when it is refreshed).</p>
-<h2 id="wire"><code>Wire</code></h2>
+<h2 id="wire"><code>Wire</code><a class="headerlink" href="#wire" title="Permanent link">&para;</a></h2>
 <p>The <code>Wire</code> interface provides a delegation mechanism to the manager of virtual module class loaders:</p>
 <div class="codehilite"><pre>    <span class="n">public</span> <span class="n">interface</span> <span class="n">Wire</span> <span class="p">{</span>
         <span class="n">Class</span> <span class="n">loadClass</span><span class="p">(</span><span class="n">String</span> <span class="n">name</span><span class="p">)</span> <span class="n">throws</span> <span class="n">ClassNotFoundException</span><span class="p">;</span>
@@ -137,7 +159,7 @@
 <li>If the method throws an exception, then the manager-owned class loader should stop its search and throw an exception.</li>
 </ul>
 <p>Injection of wires into a virtual module does not compel the manager-owned class loader to obey proper OSGi delegation patterns. It is recommended to do so to ensure consistency, but the third-party provider has the flexibility to deviate as it sees fit, but it must live with the consequences.</p>
-<h2 id="felixbundlecontext"><code>FelixBundleContext</code></h2>
+<h2 id="felixbundlecontext"><code>FelixBundleContext</code><a class="headerlink" href="#felixbundlecontext" title="Permanent link">&para;</a></h2>
 <p>The framework needs to provide explicit support for installing virtual bundles and currently this happens via two new methods on the <code>BundleContext</code> interface. For the prototype, these methods are added to a specialization of <code>BundleContext</code>:</p>
 <div class="codehilite"><pre>    <span class="n">public</span> <span class="n">interface</span> <span class="n">FelixBundleContext</span> <span class="n">extends</span> <span class="n">BundleContext</span> <span class="p">{</span>
         <span class="n">VirtualModuleContext</span> <span class="n">installBundle</span><span class="p">(</span><span class="n">String</span> <span class="n">location</span><span class="p">,</span> <span class="n">Map</span> <span class="n">headers</span><span class="p">,</span> <span class="n">VirtualModule</span> <span class="n">vm</span><span class="p">)</span>
@@ -151,7 +173,7 @@
 <p>The <code>installBundle()</code> method is how a manager installs a virtual bundle for the first time. The <code>location</code> parameter is the normal bundle location string, the <code>headers</code> parameter is the virtual bundle's manifest, and the <code>vm</code> parameter is the virtual bundle's <code>VirtualModule</code> implementation. The <code>reinstallBundle()</code> method is used by a manager to reinstall or reattach a <code>VirtualModule</code> implementation to a previously installed virtual bundle, such as on framework restart.</p>
 <p>NOTE 1: Technically, it would be possible to avoid passing in the <code>VirtualModule</code> instance to <code>installBundle()</code> and force the manager to always attach <code>VirtualModule</code> implementations using <code>reinstallBundle()</code>, but this approach at least makes the first install atomic.</p>
 <p>NOTE 2: Perhaps <code>reinstallBundle()</code> should be on the <code>Bundle</code> interface.</p>
-<h2 id="virtualmodulecontext"><code>VirtualModuleContext</code></h2>
+<h2 id="virtualmodulecontext"><code>VirtualModuleContext</code><a class="headerlink" href="#virtualmodulecontext" title="Permanent link">&para;</a></h2>
 <p>When a manager installs or reinstalls a virtual bundle, it receives a <code>VirtualModuleContext</code>:</p>
 <div class="codehilite"><pre>    <span class="n">public</span> <span class="n">interface</span> <span class="n">VirtualModuleContext</span> <span class="p">{</span>
         <span class="n">Bundle</span> <span class="n">getBundle</span><span class="p">();</span>
@@ -162,26 +184,26 @@
 
 <p>The sole purpose of a <code>VirtualModuleContext</code> is to provide the manager with access to the virtual bundle's private data area. The <code>VirtualModuleContext</code> is valid even when the virtual bundle is not <code>ACTIVE</code>, but becomes invalid once the virtual bundle is <code>UNINSTALLED</code>.</p>
 <p>NOTE: This could be implemented as a super interface of <code>BundleContext</code>.</p>
-<h2 id="virtual-bundle-lifecycle">Virtual bundle lifecycle</h2>
+<h2 id="virtual-bundle-lifecycle">Virtual bundle lifecycle<a class="headerlink" href="#virtual-bundle-lifecycle" title="Permanent link">&para;</a></h2>
 <p>In an effort to minimize the impact to the framework, the lifecycle handling for virtual bundles has been kept purposely simplistic. There was a conscious decision to avoid making the framework responsible for reifying the relationship between a virtual bundle and its manager; instead, this is solely the manager's responsibility. This does have some have some potential ramifications on issues like ordering, which will be discussed shortly along with other lifecycle-related issues.</p>
-<h2 id="persistence-of-virtual-bundles">Persistence of virtual bundles</h2>
+<h2 id="persistence-of-virtual-bundles">Persistence of virtual bundles<a class="headerlink" href="#persistence-of-virtual-bundles" title="Permanent link">&para;</a></h2>
 <p>When a virtual bundle is installed, it is installed persistently; however, this has a different meaning than for normal bundles. A virtual bundle is recorded persistently in the bundle cache and its specified headers are cached for it; this means the headers cannot change after installation unless updated, like a normal bundle. The managed object (i.e., the <code>VirtualModule</code> instance) associated with a virtual bundle is not persisted. This means on subsequent framework restarts, the framework is able to reconstitute a virtual bundle and maintains its private data area, but the reconstituted virtual bundle is merely an empty shell. It is the managers responsibility to reinstall the virtual bundle's associated <code>VirtualModule</code>.</p>
-<h2 id="managervirtual-bundle-ordering">Manager/virtual bundle ordering</h2>
+<h2 id="managervirtual-bundle-ordering">Manager/virtual bundle ordering<a class="headerlink" href="#managervirtual-bundle-ordering" title="Permanent link">&para;</a></h2>
 <p>In many cases it will be important for the manager to start before anyone attempts to use a virtual bundle. If so, the manager should be placed in a lower start level than its virtual bundles. Although not optimal, this is acceptable since virtual bundles are quite low level and are effectively extending the framework. This may not be necessary in all cases and could potentially be alleviated to some degree if the framework were proactive during the reinstall phase of a virtual bundle (e.g., it could immediately try to restart persistently started bundles after a reinstall).</p>
 <p>NOTE: This is also related to the “active dependencies” topic of RFC-154; if the framework managed some active dependencies then this could be resolved that way, but that opens another whole can of worms.</p>
-<h2 id="refreshing-a-virtual-bundle">Refreshing a virtual bundle</h2>
+<h2 id="refreshing-a-virtual-bundle">Refreshing a virtual bundle<a class="headerlink" href="#refreshing-a-virtual-bundle" title="Permanent link">&para;</a></h2>
 <p>When a normal bundle is refreshed, the framework throws away the class loader associated with the bundle and will ultimately create a new one when needed. For virtual bundles, the first part is the similar, but the second is not since the framework has no way to create the needed <code>VirtualModule</code> instance. Thus, when a virtual bundle is refreshed, the framework throws away the associated <code>VirtualModule</code> instance and sets the associated state of the virtual bundle to <code>INSTALLED</code>. It is the manager's responsibility to detect this situation and reinstall the needed <code>VirtualModule</code> instance.</p>
 <p>NOTE: Technically, I think it may be possible to achieve this somewhat atomically with a synchronous bundle listener.</p>
 <p>Refreshing a virtual bundle does not necessarily have a direct impact on the manager. In other words, the virtual bundle does not necessarily have an implicit dependency on its manager.</p>
-<h2 id="refreshing-a-manager">Refreshing a manager</h2>
+<h2 id="refreshing-a-manager">Refreshing a manager<a class="headerlink" href="#refreshing-a-manager" title="Permanent link">&para;</a></h2>
 <p>The framework must maintain dependencies from a manager to its installed virtual bundles so when a manager is refreshed, then all of its virtual bundles will be refreshed too. If the class implementing the <code>VirtualModule</code> instance comes from a bundle other than the manager, then the framework should associate an implicit dependency between this other bundle and the virtual module too so it is refreshed when this other bundle is refreshed, in addition to the manager.</p>
 <p>NOTE: It is not necessarily clear that we need to directly support this last case.</p>
-<h2 id="effective-time-of-a-virtual-module">Effective time of a virtual module</h2>
+<h2 id="effective-time-of-a-virtual-module">Effective time of a virtual module<a class="headerlink" href="#effective-time-of-a-virtual-module" title="Permanent link">&para;</a></h2>
 <p>The effective time of a virtual module instance is related to the lifecycle of the virtual bundle itself and the virtual bundle's manager. It seems obvious that a virtual module instance should be valid (i.e., used by the framework) while the virtual bundle state is <code>RESOLVED</code>, <code>STARTING</code>, <code>ACTIVE</code>, <code>STOPPING</code>, and <code>UNINSTALLED</code> (until refreshed); this mimics normal bundle behavior. With respect to the manager's lifecycle, the prototype currently assumes the virtual module is valid during these same lifecycle states in the manager. In other words, the manager does not need to be active after the fact for the virtual bundles to continue to function, it just needs to be active to install them initially.</p>
 <p>NOTE: The alternative is to treat this as some sort of “active dependency” where if the manager is stopped, its associated virtual bundles are refreshed immediately.</p>
-<h1 id="open-issues">Open issues</h1>
+<h1 id="open-issues">Open issues<a class="headerlink" href="#open-issues" title="Permanent link">&para;</a></h1>
 <p>This section documents open and/or unaddressed issues.</p>
-<h2 id="installation-interception">Installation interception</h2>
+<h2 id="installation-interception">Installation interception<a class="headerlink" href="#installation-interception" title="Permanent link">&para;</a></h2>
 <p>Some form of bundle installation interception is necessary to integrate cleanly with existing management agents that use <code>BundleContext.installBundle()</code> to deploy bundles. One possibility is to introduce a new service interface used by the framework, such as:</p>
 <div class="codehilite"><pre>    <span class="n">public</span> <span class="n">interface</span> <span class="n">InstallHook</span> <span class="p">{</span>
         <span class="n">boolean</span> <span class="n">installBundle</span><span class="p">(</span><span class="n">String</span> <span class="n">location</span><span class="p">);</span>
@@ -191,10 +213,10 @@
 
 
 <p>Managers could register such a service which would be used by the framework during bundle installation to call out to the managers to given them an opportunity to process the bundle installation instead of using the default handling. This is somewhat analogous to resource processors in the Deployment Admin specification.</p>
-<h2 id="updating-a-virtual-bundle">Updating a virtual bundle</h2>
+<h2 id="updating-a-virtual-bundle">Updating a virtual bundle<a class="headerlink" href="#updating-a-virtual-bundle" title="Permanent link">&para;</a></h2>
 <p>No issues are foreseen in the normal update scenario (i.e., updating a bundle to a completely new version of a bundle whether it is virtual or not). It should be possible to update a virtual bundle to a new virtual module (and headers), as well as updating a normal bundle to a virtual bundle or vice versa. This will likely require adding another <code>update()</code> method to <code>Bundle</code> that accepts the appropriate parameters (e.g., <code>Bundle.update(Map headers, VirtualModule vm)</code>).</p>
 <p>A more complicated case is related to ordering, which is how to deal with bundles that were installed before the manager was present and/or activated. In this case, a normal update is not completely sufficient since the manager really wants to update the bundle to a virtual bundle, but keep its existing content. Technically, this is possible with the current API by using the entry-related <code>Bundle</code> methods to reconstruct the installed bundle, then performing an update on it to convert it to a virtual bundle.</p>
-<h2 id="resource-handling">Resource handling</h2>
+<h2 id="resource-handling">Resource handling<a class="headerlink" href="#resource-handling" title="Permanent link">&para;</a></h2>
 <p>Typically, a framework implementation has to know something about the content of a bundle to create resource URLs. For example, both Felix and Equinox create resource URLs something like this:</p>
 <div class="codehilite"><pre>    <span class="n">bundle</span><span class="p">:</span><span class="o">//&lt;</span><span class="n">framework</span><span class="o">-</span><span class="n">id</span><span class="o">&gt;&lt;</span><span class="n">bundle</span><span class="o">-</span><span class="n">id</span><span class="o">&gt;</span><span class="p">:</span><span class="o">&lt;</span><span class="n">classpath</span><span class="o">-</span><span class="n">idx</span><span class="o">&gt;/</span><span class="n">path</span><span class="o">/</span><span class="n">to</span><span class="o">/</span><span class="n">resource</span><span class="p">.</span><span class="n">txt</span>
 </pre></div>
@@ -203,18 +225,18 @@
 <p>This sort of approach is necessary since the specification requires that resource URLs can be used as the context to create other resource URLs. Unfortunately, this breaks the module's encapsulation of its content (i.e., the framework must be aware that there is a bundle class path concept).</p>
 <p>Currently, a manager must manager register a URL stream handler to provide a protocol to access its virtual modules' content as resources if it cannot be handled via an existing protocol. The downside of this approach is that, for now, a manager has to be active to provide a stream handler service, which means resource access will stop working if the manager is stopped.</p>
 <p>A potential solution to this is to inject the virtual module with a resource URL factory which allows the manager to inject its own “opaque” index integer into the framework's normal resource URL.</p>
-<h2 id="dynamic-imports">Dynamic imports</h2>
+<h2 id="dynamic-imports">Dynamic imports<a class="headerlink" href="#dynamic-imports" title="Permanent link">&para;</a></h2>
 <p>It is possible to add support for dynamic imports through the injection of a special type of wire in the <code>VirtualModule.resolve()</code> method. Like the boot wire, this dynamic wire would be special and would be searched by the manager-owned class loader after its own content and would potentially result in a dynamic import.</p>
-<h2 id="fragments">Fragments</h2>
+<h2 id="fragments">Fragments<a class="headerlink" href="#fragments" title="Permanent link">&para;</a></h2>
 <p>It may technically be possible to support fragments. Currently, a virtual module is injected with wires that provide access to classes and resources. Conceptually, we could handle fragments by injecting the virtual module with a set of fragment bundles from which it could load entries. The only trick is that the injected bundles could not be a normal bundle since a normal bundle can have multiple bundle revisions associated with it; the injected fragment bundle would need to be a wrapper around a specific revision. Other approach it to create a new wire-like interface for fragment access which could be injected into the virtual module.</p>
-<h2 id="security">Security</h2>
+<h2 id="security">Security<a class="headerlink" href="#security" title="Permanent link">&para;</a></h2>
 <p>One possible approach to deal with security is to inject the virtual module with a protection domain for it to use when defining classes. For virtual modules using predefined classes, then it won't be possible to assign additional permissions to those classes.</p>
-<h2 id="lazy-activation">Lazy activation</h2>
+<h2 id="lazy-activation">Lazy activation<a class="headerlink" href="#lazy-activation" title="Permanent link">&para;</a></h2>
 <p>Too support lazy activation across normal bundles and virtual bundles, API would need to be defined for them to participate in this process. Mostly likely, the virtual module would need to be injected with some object for keep track of which classes are being created and which bundles need to be activated.</p>
-<h1 id="considered-alternatives">Considered alternatives</h1>
+<h1 id="considered-alternatives">Considered alternatives<a class="headerlink" href="#considered-alternatives" title="Permanent link">&para;</a></h1>
 <p>TBD</p>
       <div class="timestamp" style="margin-top: 30px; font-size: 80%; text-align: right;">
-        Rev. 1422427 by fmeschbe on Sun, 16 Dec 2012 00:36:51 +0000
+        Rev. 1700393 by cziegeler on Tue, 1 Sep 2015 06:04:06 +0000
       </div>
       <div class="trademarkFooter"> 
         Apache Felix, Felix, Apache, the Apache feather logo, and the Apache Felix project

Modified: websites/staging/felix/trunk/content/miscellaneous/sandbox/web-console-ng.html
==============================================================================
--- websites/staging/felix/trunk/content/miscellaneous/sandbox/web-console-ng.html (original)
+++ websites/staging/felix/trunk/content/miscellaneous/sandbox/web-console-ng.html Tue Sep  1 06:05:17 2015
@@ -39,7 +39,18 @@
     </div>
     
     <div class="menu"> 
-      <p><a href="/news.html">news</a>  <br />
+      <style type="text/css">
+/* The following code is added by mdx_elementid.py
+   It was originally lifted from http://subversion.apache.org/style/site.css */
+/*
+ * Hide class="elementid-permalink", except when an enclosing heading
+ * has the :hover property.
+ */
+.headerlink, .elementid-permalink {
+  visibility: hidden;
+}
+h2:hover > .headerlink, h3:hover > .headerlink, h1:hover > .headerlink, h6:hover > .headerlink, h4:hover > .headerlink, h5:hover > .headerlink, dt:hover > .elementid-permalink { visibility: visible }</style>
+<p><a href="/news.html">news</a>  <br />
 <a href="/license.html">license</a>  <br />
 <a href="/downloads.cgi">downloads</a>  <br />
 <a href="/documentation.html">documentation</a>  <br />
@@ -66,8 +77,19 @@
       </div>
 
       <h1>Web Console NG</h1>
-      <p>As discussed on the <a href="http://markmail.org/message/3c5y77mg3tiqgegt">list</a> stipulated by [Valentin Valchev's comment on FELIX-3773|https://issues.apache.org/jira/browse/FELIX-3773?focusedCommentId=13503120&amp;page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13503120] lets collect <em>data</em> in a next generation Web Console...</p>
-<h1 id="ideas">Ideas</h1>
+      <style type="text/css">
+/* The following code is added by mdx_elementid.py
+   It was originally lifted from http://subversion.apache.org/style/site.css */
+/*
+ * Hide class="elementid-permalink", except when an enclosing heading
+ * has the :hover property.
+ */
+.headerlink, .elementid-permalink {
+  visibility: hidden;
+}
+h2:hover > .headerlink, h3:hover > .headerlink, h1:hover > .headerlink, h6:hover > .headerlink, h4:hover > .headerlink, h5:hover > .headerlink, dt:hover > .elementid-permalink { visibility: visible }</style>
+<p>As discussed on the <a href="http://markmail.org/message/3c5y77mg3tiqgegt">list</a> stipulated by [Valentin Valchev's comment on FELIX-3773|https://issues.apache.org/jira/browse/FELIX-3773?focusedCommentId=13503120&amp;page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13503120] lets collect <em>data</em> in a next generation Web Console...</p>
+<h1 id="ideas">Ideas<a class="headerlink" href="#ideas" title="Permanent link">&para;</a></h1>
 <ul>
 <li>New extension API built from ground up</li>
 <li>Compatibility layer to support old plugins</li>
@@ -77,7 +99,7 @@
 ... please add ...</li>
 </ul>
       <div class="timestamp" style="margin-top: 30px; font-size: 80%; text-align: right;">
-        Rev. 1422427 by fmeschbe on Sun, 16 Dec 2012 00:36:51 +0000
+        Rev. 1700393 by cziegeler on Tue, 1 Sep 2015 06:04:06 +0000
       </div>
       <div class="trademarkFooter"> 
         Apache Felix, Felix, Apache, the Apache feather logo, and the Apache Felix project

Modified: websites/staging/felix/trunk/content/miscellaneous/subproject-release-status.html
==============================================================================
--- websites/staging/felix/trunk/content/miscellaneous/subproject-release-status.html (original)
+++ websites/staging/felix/trunk/content/miscellaneous/subproject-release-status.html Tue Sep  1 06:05:17 2015
@@ -39,7 +39,18 @@
     </div>
     
     <div class="menu"> 
-      <p><a href="/news.html">news</a>  <br />
+      <style type="text/css">
+/* The following code is added by mdx_elementid.py
+   It was originally lifted from http://subversion.apache.org/style/site.css */
+/*
+ * Hide class="elementid-permalink", except when an enclosing heading
+ * has the :hover property.
+ */
+.headerlink, .elementid-permalink {
+  visibility: hidden;
+}
+h2:hover > .headerlink, h3:hover > .headerlink, h1:hover > .headerlink, h6:hover > .headerlink, h4:hover > .headerlink, h5:hover > .headerlink, dt:hover > .elementid-permalink { visibility: visible }</style>
+<p><a href="/news.html">news</a>  <br />
 <a href="/license.html">license</a>  <br />
 <a href="/downloads.cgi">downloads</a>  <br />
 <a href="/documentation.html">documentation</a>  <br />
@@ -68,7 +79,7 @@
       <h1>Subproject Release Status</h1>
       
       <div class="timestamp" style="margin-top: 30px; font-size: 80%; text-align: right;">
-        Rev. 1422427 by fmeschbe on Sun, 16 Dec 2012 00:36:51 +0000
+        Rev. 1700393 by cziegeler on Tue, 1 Sep 2015 06:04:06 +0000
       </div>
       <div class="trademarkFooter"> 
         Apache Felix, Felix, Apache, the Apache feather logo, and the Apache Felix project

Modified: websites/staging/felix/trunk/content/miscellaneous/tlp-task-list.html
==============================================================================
--- websites/staging/felix/trunk/content/miscellaneous/tlp-task-list.html (original)
+++ websites/staging/felix/trunk/content/miscellaneous/tlp-task-list.html Tue Sep  1 06:05:17 2015
@@ -39,7 +39,18 @@
     </div>
     
     <div class="menu"> 
-      <p><a href="/news.html">news</a>  <br />
+      <style type="text/css">
+/* The following code is added by mdx_elementid.py
+   It was originally lifted from http://subversion.apache.org/style/site.css */
+/*
+ * Hide class="elementid-permalink", except when an enclosing heading
+ * has the :hover property.
+ */
+.headerlink, .elementid-permalink {
+  visibility: hidden;
+}
+h2:hover > .headerlink, h3:hover > .headerlink, h1:hover > .headerlink, h6:hover > .headerlink, h4:hover > .headerlink, h5:hover > .headerlink, dt:hover > .elementid-permalink { visibility: visible }</style>
+<p><a href="/news.html">news</a>  <br />
 <a href="/license.html">license</a>  <br />
 <a href="/downloads.cgi">downloads</a>  <br />
 <a href="/documentation.html">documentation</a>  <br />
@@ -66,8 +77,19 @@
       </div>
 
       <h1>TLP Task List</h1>
-      <h1 id="svn-repository">SVN Repository</h1>
-<table>
+      <style type="text/css">
+/* The following code is added by mdx_elementid.py
+   It was originally lifted from http://subversion.apache.org/style/site.css */
+/*
+ * Hide class="elementid-permalink", except when an enclosing heading
+ * has the :hover property.
+ */
+.headerlink, .elementid-permalink {
+  visibility: hidden;
+}
+h2:hover > .headerlink, h3:hover > .headerlink, h1:hover > .headerlink, h6:hover > .headerlink, h4:hover > .headerlink, h5:hover > .headerlink, dt:hover > .elementid-permalink { visibility: visible }</style>
+<h1 id="svn-repository">SVN Repository<a class="headerlink" href="#svn-repository" title="Permanent link">&para;</a></h1>
+<table class="table">
 <thead>
 <tr>
 <th>Task</th>
@@ -93,8 +115,8 @@
 </tr>
 </tbody>
 </table>
-<h1 id="web-site">Web Site</h1>
-<table>
+<h1 id="web-site">Web Site<a class="headerlink" href="#web-site" title="Permanent link">&para;</a></h1>
+<table class="table">
 <thead>
 <tr>
 <th>Task</th>
@@ -124,8 +146,8 @@
 </tr>
 </tbody>
 </table>
-<h1 id="mailing-lists">Mailing Lists</h1>
-<table>
+<h1 id="mailing-lists">Mailing Lists<a class="headerlink" href="#mailing-lists" title="Permanent link">&para;</a></h1>
+<table class="table">
 <thead>
 <tr>
 <th>Task</th>
@@ -143,8 +165,8 @@
 </tr>
 </tbody>
 </table>
-<h1 id="cleanup">Cleanup</h1>
-<table>
+<h1 id="cleanup">Cleanup<a class="headerlink" href="#cleanup" title="Permanent link">&para;</a></h1>
+<table class="table">
 <thead>
 <tr>
 <th>Task</th>
@@ -163,7 +185,7 @@
 </tbody>
 </table>
       <div class="timestamp" style="margin-top: 30px; font-size: 80%; text-align: right;">
-        Rev. 1422427 by fmeschbe on Sun, 16 Dec 2012 00:36:51 +0000
+        Rev. 1700393 by cziegeler on Tue, 1 Sep 2015 06:04:06 +0000
       </div>
       <div class="trademarkFooter"> 
         Apache Felix, Felix, Apache, the Apache feather logo, and the Apache Felix project



Mime
View raw message