You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@felix.apache.org by dj...@apache.org on 2021/07/11 23:13:49 UTC
[felix-antora-site] branch main updated (5d17807 -> f7b386c)
This is an automated email from the ASF dual-hosted git repository.
djencks pushed a change to branch main
in repository https://gitbox.apache.org/repos/asf/felix-antora-site.git.
from 5d17807 start on download page
new 6ed7c13 remove .mdtext files
new cc79e75 remove autoconf doc (unmaintained)
new ddb481c remove commons doc (unmaintained)
new a52ef9a remove deployment admin doc (unmaintained)
new 59ddb56 remove ipojo doc (unmaintained)
new 9daa925 remove jaas doc (unmaintained)
new d2d2098 remove lightweight http service doc (unmaintained)
new 5edb28e remove mangen doc (unmaintained)
new 219c70e remove maven obr plugin doc (unmaintained)
new 148d343 remove maven osgi plugin doc (unmaintained)
new d7c6896 remove maven scr plugin doc (unmaintained)
new 3212787 remove mosgi doc (unmaintained)
new 7485f26 remove osgi-core doc (unmaintained)
new ee60a51 remove script-console-plugin doc (unmaintained)
new 000b836 remove serialization framework doc (unmaintained)
new 778aa40 remove upnp doc (unmaintained)
new 9913ed4 remove user admin doc (unmaintained)
new f7b386c shorten urls to felix-site-pub
The 18 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails. The revisions
listed as "add" were already present in the repository and have only
been added to this reference.
Summary of changes:
modules/ROOT/pages/documentation.mdtext | 18 -
modules/ROOT/pages/documentation/community.mdtext | 4 -
.../documentation/community/contributing.mdtext | 43 -
.../documentation/community/project-info.mdtext | 48 -
.../community/projects-using-felix.mdtext | 13 -
.../ROOT/pages/documentation/development.mdtext | 7 -
.../development/coding-standards.mdtext | 481 ------
.../development/dependencies-file-template.mdtext | 43 -
.../development/provisional-osgi-api-policy.mdtext | 27 -
.../development/release-management-nexus.mdtext | 345 -----
.../documentation/development/site-how-to.mdtext | 201 ---
.../using-the-osgi-compliance-tests.mdtext | 213 ---
modules/ROOT/pages/documentation/faqs.mdtext | 6 -
.../faqs/apache-felix-bundle-plugin-faq.mdtext | 179 ---
.../faqs/apache-felix-scr-plugin-faq.mdtext | 71 -
.../pages/documentation/getting-started.mdtext | 11 -
modules/ROOT/pages/documentation/subprojects.adoc | 46 +-
.../ROOT/pages/documentation/subprojects.mdtext | 61 -
.../subprojects/apache-felix-autoconf.adoc | 4 -
.../subprojects/apache-felix-autoconf.mdtext | 4 -
.../subprojects/apache-felix-commons.adoc | 152 --
.../subprojects/apache-felix-commons.mdtext | 68 -
.../creating-bundles-using-bnd.adoc | 88 --
.../creating-bundles-using-bnd.mdtext | 84 -
.../apache-felix-dependency-manager.mdtext | 62 -
.../guides/annotations.mdtext | 347 -----
.../guides/background.mdtext | 28 -
.../guides/bundles-and-dependencies.mdtext | 23 -
.../guides/design-patterns.mdtext | 161 --
.../guides/development.mdtext | 48 -
.../guides/dm-lambda.mdtext | 943 ------------
.../guides/history.mdtext | 15 -
.../guides/javadocs.mdtext | 4 -
.../guides/migrating-from-earlier-versions.mdtext | 69 -
.../guides/migrating-from-other-solutions.mdtext | 2 -
.../guides/performance-tuning.mdtext | 37 -
.../guides/resources.mdtext | 97 --
.../guides/whatsnew-r15.mdtext | 199 ---
.../guides/whatsnew.mdtext | 68 -
.../reference/component-adapter.mdtext | 44 -
.../reference/component-aspect.mdtext | 35 -
.../reference/component-bundle-adapter.mdtext | 35 -
.../component-factory-configuration-adapter.mdtext | 44 -
.../reference/component-resource-adapter.mdtext | 114 --
.../reference/component-singleton.mdtext | 63 -
.../reference/components.mdtext | 227 ---
.../reference/dependencies.mdtext | 32 -
.../reference/dependency-bundle.mdtext | 34 -
.../reference/dependency-configuration.mdtext | 105 --
.../reference/dependency-resource.mdtext | 93 --
.../reference/dependency-service.mdtext | 35 -
.../reference/dm-annotations.mdtext | 1611 --------------------
.../reference/external-links.mdtext | 7 -
.../reference/service-scopes.mdtext | 221 ---
.../reference/thread-model.mdtext | 113 --
.../tutorials/getting-started.mdtext | 195 ---
.../tutorials/leveraging-the-shell.mdtext | 97 --
.../tutorials/sample-code.mdtext | 63 -
.../tutorials/working-with-annotations.mdtext | 214 ---
.../subprojects/apache-felix-deployment-admin.adoc | 4 -
.../apache-felix-deployment-admin.mdtext | 4 -
.../subprojects/apache-felix-event-admin.mdtext | 225 ---
.../subprojects/apache-felix-file-install.mdtext | 104 --
.../apache-felix-framework-security.mdtext | 50 -
.../subprojects/apache-felix-framework.mdtext | 8 -
.../apache-felix-framework-bundle-cache.mdtext | 66 -
...felix-framework-configuration-properties.mdtext | 82 -
.../apache-felix-framework-faq.mdtext | 60 -
...-felix-framework-launching-and-embedding.mdtext | 784 ----------
...ache-felix-framework-usage-documentation.mdtext | 179 ---
.../subprojects/apache-felix-gogo.mdtext | 195 ---
.../apache-felix-gogo/rfc-147-overview.mdtext | 158 --
.../subprojects/apache-felix-healthchecks.mdtext | 19 -
.../subprojects/apache-felix-inventory.mdtext | 133 --
.../subprojects/apache-felix-ipojo.adoc | 50 -
.../subprojects/apache-felix-ipojo.mdtext | 83 -
.../dive-into-the-ipojo-manipulation-depths.adoc | 244 ---
.../dive-into-the-ipojo-manipulation-depths.mdtext | 209 ---
.../how-to-use-ipojo-manipulation-metadata.adoc | 85 --
.../how-to-use-ipojo-manipulation-metadata.mdtext | 79 -
.../how-to-write-your-own-handler.adoc | 985 ------------
.../how-to-write-your-own-handler.mdtext | 821 ----------
.../apache-felix-ipojo-eclipse-integration.adoc | 72 -
.../apache-felix-ipojo-eclipse-integration.mdtext | 60 -
.../apache-felix-ipojo-feature-overview.adoc | 51 -
.../apache-felix-ipojo-feature-overview.mdtext | 54 -
.../apache-felix-ipojo-dosgi.adoc | 161 --
.../apache-felix-ipojo-dosgi.mdtext | 132 --
.../how-to-use-ipojo-annotations.adoc | 377 -----
.../how-to-use-ipojo-annotations.mdtext | 375 -----
.../ipojo-advanced-tutorial.adoc | 602 --------
.../ipojo-advanced-tutorial.mdtext | 518 -------
.../ipojo-composition-tutorial.adoc | 620 --------
.../ipojo-composition-tutorial.mdtext | 504 ------
.../ipojo-hello-word-maven-based-tutorial.adoc | 547 -------
.../ipojo-hello-word-maven-based-tutorial.mdtext | 428 ------
.../ipojo-in-10-minutes.adoc | 609 --------
.../ipojo-in-10-minutes.mdtext | 514 -------
.../apache-felix-ipojo-junit4osgi.adoc | 30 -
.../apache-felix-ipojo-junit4osgi.mdtext | 26 -
...apache-felix-ipojo-junit4osgi-architecture.adoc | 43 -
...ache-felix-ipojo-junit4osgi-architecture.mdtext | 39 -
.../apache-felix-ipojo-junit4osgi-maven.adoc | 225 ---
.../apache-felix-ipojo-junit4osgi-maven.mdtext | 211 ---
.../apache-felix-ipojo-junit4osgi-methods.adoc | 84 -
.../apache-felix-ipojo-junit4osgi-methods.mdtext | 74 -
.../apache-felix-ipojo-junit4osgi-tutorial.adoc | 345 -----
.../apache-felix-ipojo-junit4osgi-tutorial.mdtext | 311 ----
.../apache-felix-ipojo-keypoints.adoc | 70 -
.../apache-felix-ipojo-keypoints.mdtext | 46 -
.../apache-felix-ipojo-successstories.adoc | 69 -
.../apache-felix-ipojo-successstories.mdtext | 54 -
.../apache-felix-ipojo-supportedosgi.adoc | 53 -
.../apache-felix-ipojo-supportedosgi.mdtext | 80 -
.../apache-felix-ipojo-supportedvms.adoc | 74 -
.../apache-felix-ipojo-supportedvms.mdtext | 106 --
.../apache-felix-ipojo-testing-components.adoc | 104 --
.../apache-felix-ipojo-testing-components.mdtext | 87 --
.../apache-felix-ipojo-online-manipulator.adoc | 61 -
.../apache-felix-ipojo-online-manipulator.mdtext | 51 -
.../apache-felix-ipojo-tools/ipojo-ant-task.adoc | 129 --
.../apache-felix-ipojo-tools/ipojo-ant-task.mdtext | 124 --
.../ipojo-arch-command.adoc | 179 ---
.../ipojo-arch-command.mdtext | 169 --
.../ipojo-karaf-feature.adoc | 24 -
.../ipojo-karaf-feature.mdtext | 31 -
.../ipojo-maven-plug-in.adoc | 241 ---
.../ipojo-maven-plug-in.mdtext | 245 ---
.../ipojo-webconsole-plugin.adoc | 73 -
.../ipojo-webconsole-plugin.mdtext | 70 -
.../apache-felix-ipojo-tools/junit4osgi.adoc | 219 ---
.../apache-felix-ipojo-tools/junit4osgi.mdtext | 191 ---
.../apache-felix-ipojo-api.adoc | 375 -----
.../apache-felix-ipojo-api.mdtext | 321 ----
.../apache-felix-ipojo-instances.adoc | 427 ------
.../apache-felix-ipojo-instances.mdtext | 391 -----
.../describing-components.adoc | 34 -
.../describing-components.mdtext | 34 -
.../describing-components/Callback.jpeg | Bin 9842 -> 0 bytes
.../architecture-handler.adoc | 65 -
.../architecture-handler.mdtext | 59 -
.../configuration-handler.adoc | 181 ---
.../configuration-handler.mdtext | 155 --
.../controller-lifecycle-handler.adoc | 61 -
.../controller-lifecycle-handler.mdtext | 56 -
.../event-admin-handlers.adoc | 345 -----
.../event-admin-handlers.mdtext | 321 ----
.../extender-pattern-handler.adoc | 148 --
.../extender-pattern-handler.mdtext | 133 --
.../injecting-bundle-context.adoc | 72 -
.../injecting-bundle-context.mdtext | 66 -
.../describing-components/ipojo-jmx-handler.adoc | 291 ----
.../describing-components/ipojo-jmx-handler.mdtext | 307 ----
.../lifecycle-callback-handler.adoc | 168 --
.../lifecycle-callback-handler.mdtext | 146 --
.../providing-osgi-services.adoc | 435 ------
.../providing-osgi-services.mdtext | 396 -----
.../service-requirement-handler.adoc | 867 -----------
.../service-requirement-handler.mdtext | 734 ---------
.../temporal-service-dependency.adoc | 187 ---
.../temporal-service-dependency.mdtext | 142 --
.../white-board-pattern-handler.adoc | 159 --
.../white-board-pattern-handler.mdtext | 151 --
.../instance-vs-service-controller.adoc | 84 -
.../instance-vs-service-controller.mdtext | 77 -
.../ipojo-advanced-topics.adoc | 9 -
.../ipojo-advanced-topics.mdtext | 17 -
.../combining-ipojo-and-configuration-admin.adoc | 306 ----
.../combining-ipojo-and-configuration-admin.mdtext | 298 ----
...tructing-pojo-objects-with-factory-methods.adoc | 42 -
...ucting-pojo-objects-with-factory-methods.mdtext | 43 -
.../how-to-use-ipojo-factories.adoc | 298 ----
.../how-to-use-ipojo-factories.mdtext | 239 ---
.../ipojo-extender-configuration.adoc | 145 --
.../ipojo-extender-configuration.mdtext | 168 --
.../ipojo-factory-service.adoc | 169 --
.../ipojo-factory-service.mdtext | 145 --
.../ipojo-hierarchical-composition-overview.adoc | 313 ----
.../ipojo-hierarchical-composition-overview.mdtext | 250 ---
.../service-binding-interceptors.adoc | 241 ---
.../service-binding-interceptors.mdtext | 200 ---
.../using-ipojo-introspection-api.adoc | 274 ----
.../using-ipojo-introspection-api.mdtext | 267 ----
.../ipojo-advanced-topics/using-stereotypes.adoc | 94 --
.../ipojo-advanced-topics/using-stereotypes.mdtext | 83 -
.../apache-felix-ipojo-userguide/ipojo-faq.adoc | 431 ------
.../apache-felix-ipojo-userguide/ipojo-faq.mdtext | 448 ------
.../using-xml-schemas.adoc | 68 -
.../using-xml-schemas.mdtext | 90 --
.../apache-felix-ipojo-why-choose-ipojo.adoc | 107 --
.../apache-felix-ipojo-why-choose-ipojo.mdtext | 74 -
.../articles-and-presentations.adoc | 18 -
.../articles-and-presentations.mdtext | 16 -
.../developing-camel-mediators-with-ipojo.adoc | 164 --
.../developing-camel-mediators-with-ipojo.mdtext | 157 --
.../subprojects/apache-felix-ipojo/download.adoc | 118 --
.../subprojects/apache-felix-ipojo/download.mdtext | 61 -
.../subprojects/apache-felix-ipojo/ipojo-news.adoc | 89 --
.../apache-felix-ipojo/ipojo-news.mdtext | 42 -
.../apache-felix-ipojo/ipojo-reference-card.adoc | 904 -----------
.../apache-felix-ipojo/ipojo-reference-card.mdtext | 886 -----------
.../apache-felix-ipojo/ipojo-support.adoc | 29 -
.../apache-felix-ipojo/ipojo-support.mdtext | 24 -
.../apache-felix-ipojo/related-works.adoc | 18 -
.../apache-felix-ipojo/related-works.mdtext | 18 -
.../subprojects/apache-felix-jaas.adoc | 315 ----
.../subprojects/apache-felix-jaas.mdtext | 306 ----
.../apache-felix-lightweight-http-service.adoc | 30 -
.../apache-felix-lightweight-http-service.mdtext | 18 -
.../subprojects/apache-felix-log.mdtext | 200 ---
.../subprojects/apache-felix-logback.mdtext | 173 ---
.../apache-felix-manifest-generator-mangen.adoc | 662 --------
.../apache-felix-manifest-generator-mangen.mdtext | 534 -------
.../apache-felix-maven-bundle-plugin-bnd.mdtext | 921 -----------
.../subprojects/apache-felix-maven-obr-plugin.adoc | 212 ---
.../apache-felix-maven-obr-plugin.mdtext | 196 ---
.../apache-felix-maven-osgi-plugin.adoc | 22 -
.../apache-felix-maven-osgi-plugin.mdtext | 287 ----
.../subprojects/apache-felix-maven-scr-plugin.adoc | 80 -
.../apache-felix-maven-scr-plugin.mdtext | 49 -
.../apache-felix-maven-scr-plugin-use.mdtext | 144 --
.../apache-felix-scr-ant-task-use.mdtext | 162 --
.../apache-felix-scr-bndtools-use.mdtext | 142 --
.../extending-scr-annotations.mdtext | 63 -
.../scr-annotations.mdtext | 367 -----
.../scr-javadoc-tags.mdtext | 162 --
.../apache-felix-metatype-service.mdtext | 124 --
.../apache-felix-osgi-bundle-repository.mdtext | 324 ----
.../subprojects/apache-felix-osgi-core.adoc | 5 -
.../subprojects/apache-felix-osgi-core.mdtext | 3 -
.../apache-felix-preferences-service.mdtext | 86 --
.../subprojects/apache-felix-remote-shell.mdtext | 32 -
.../apache-felix-script-console-plugin.adoc | 170 ---
.../apache-felix-script-console-plugin.mdtext | 157 --
.../apache-felix-serialization-framework.adoc | 45 -
.../apache-felix-serialization-framework.mdtext | 42 -
.../subprojects/apache-felix-shell-tui.mdtext | 9 -
.../subprojects/apache-felix-shell.mdtext | 239 ---
.../subprojects/apache-felix-upnp.adoc | 23 -
.../subprojects/apache-felix-upnp.mdtext | 21 -
.../apache-felix-upnp/upnp-acknowledgments.adoc | 11 -
.../apache-felix-upnp/upnp-acknowledgments.mdtext | 5 -
.../upnp-driver-architecture.adoc | 61 -
.../upnp-driver-architecture.mdtext | 45 -
.../apache-felix-upnp/upnp-getting-started.adoc | 56 -
.../apache-felix-upnp/upnp-getting-started.mdtext | 52 -
.../apache-felix-upnp/upnp-known-issues.adoc | 12 -
.../apache-felix-upnp/upnp-known-issues.mdtext | 13 -
.../apache-felix-upnp/upnp-testing-devices.adoc | 54 -
.../apache-felix-upnp/upnp-testing-devices.mdtext | 38 -
.../upnp-testing-devices/upnp-examples.adoc | 41 -
.../upnp-testing-devices/upnp-examples.mdtext | 24 -
.../upnp-examples/upnp-writing-cd-and-cp.adoc | 117 --
.../upnp-examples/upnp-writing-cd-and-cp.mdtext | 60 -
.../subprojects/apache-felix-user-admin.adoc | 11 -
.../subprojects/apache-felix-user-admin.mdtext | 12 -
.../apache-felix-user-admin-background.adoc | 25 -
.../apache-felix-user-admin-background.mdtext | 20 -
.../apache-felix-user-admin-file-store.adoc | 25 -
.../apache-felix-user-admin-file-store.mdtext | 11 -
.../apache-felix-user-admin-getting-started.adoc | 30 -
.../apache-felix-user-admin-getting-started.mdtext | 31 -
.../apache-felix-user-admin-introduction.adoc | 4 -
.../apache-felix-user-admin-introduction.mdtext | 3 -
.../apache-felix-user-admin-mongodb-store.adoc | 25 -
.../apache-felix-user-admin-mongodb-store.mdtext | 16 -
.../subprojects/apache-felix-web-console.mdtext | 180 ---
.../extending-the-apache-felix-web-console.mdtext | 10 -
.../branding-the-web-console.mdtext | 115 --
.../providing-resources.mdtext | 22 -
.../providing-web-console-plugins.mdtext | 62 -
.../web-console-logging.mdtext | 21 -
.../web-console-output-templating.mdtext | 66 -
.../web-console-restful-api.mdtext | 345 -----
.../web-console-security-provider.mdtext | 104 --
.../subprojects/mosgi-managed-osgi-framework.adoc | 108 --
.../mosgi-managed-osgi-framework.mdtext | 83 -
.../mosgi-managed-osgi-framework/probeguide.adoc | 180 ---
.../mosgi-managed-osgi-framework/probeguide.mdtext | 149 --
.../tutorials-examples-and-presentations.mdtext | 35 -
.../apache-felix-application-demonstration.mdtext | 139 --
.../apache-felix-osgi-faq.mdtext | 123 --
.../apache-felix-osgi-tutorial.mdtext | 16 -
.../apache-felix-tutorial-example-1.mdtext | 117 --
.../apache-felix-tutorial-example-2.mdtext | 153 --
.../apache-felix-tutorial-example-2b.mdtext | 129 --
.../apache-felix-tutorial-example-3.mdtext | 149 --
.../apache-felix-tutorial-example-4.mdtext | 242 ---
.../apache-felix-tutorial-example-5.mdtext | 163 --
.../apache-felix-tutorial-example-6.mdtext | 327 ----
.../apache-felix-tutorial-example-7.mdtext | 161 --
.../apache-felix-tutorial-example-8.mdtext | 251 ---
.../apache-felix-tutorial-example-9.mdtext | 115 --
modules/ROOT/pages/errors/403.mdtext | 24 -
modules/ROOT/pages/errors/404.mdtext | 25 -
modules/ROOT/pages/index.mdtext | 20 -
modules/ROOT/pages/license.mdtext | 206 ---
modules/ROOT/pages/media.mdtext | 8 -
modules/ROOT/pages/miscellaneous.mdtext | 2 -
.../ROOT/pages/miscellaneous/apache-karaf.mdtext | 5 -
.../ROOT/pages/miscellaneous/board-reports.mdtext | 6 -
.../apache-felix-board-report-template.mdtext | 17 -
.../board-reports/board-report-2007-04.mdtext | 23 -
.../board-reports/board-report-2007-05.mdtext | 21 -
.../board-reports/board-report-2007-06.mdtext | 25 -
.../board-reports/board-report-2007-09.mdtext | 22 -
.../board-reports/board-report-2007-12.mdtext | 23 -
.../board-reports/board-report-2008-03.mdtext | 18 -
.../board-reports/board-report-2008-06.mdtext | 20 -
.../board-reports/board-report-2008-09.mdtext | 18 -
.../board-reports/board-report-2008-12.mdtext | 20 -
.../board-reports/board-report-2009-03.mdtext | 22 -
.../board-reports/board-report-2009-06.mdtext | 34 -
.../board-reports/board-report-2009-09.mdtext | 25 -
.../board-reports/board-report-2009-12.mdtext | 34 -
.../board-reports/board-report-2010-03.mdtext | 26 -
.../board-reports/board-report-2010-06.mdtext | 39 -
.../board-reports/board-report-2010-09.mdtext | 26 -
.../board-reports/board-report-2010-12.mdtext | 29 -
.../board-reports/board-report-2011-03.mdtext | 30 -
.../board-reports/board-report-2011-06.mdtext | 32 -
.../board-reports/board-report-2011-09.mdtext | 32 -
.../board-reports/board-report-2011-12.mdtext | 32 -
.../board-reports/board-report-2012-03.mdtext | 29 -
.../board-reports/board-report-2012-06.mdtext | 34 -
.../board-reports/board-report-2012-09.mdtext | 31 -
.../board-reports/board-report-2012-12.mdtext | 32 -
.../board-reports/board-report-2013-03.mdtext | 23 -
.../miscellaneous/cat-scan-project-proposal.mdtext | 12 -
.../cat-scan-001-use-cases.mdtext | 3 -
.../cat-scan-002-profiles.mdtext | 10 -
.../cat-scan-002-001-basic-profile.mdtext | 2 -
.../cat-scan-003-run-log-archive.mdtext | 3 -
.../cat-scan-004-api-reference.mdtext | 3 -
...cat-scan-005-technical-compatibility-kit.mdtext | 3 -
.../cat-scan-006-glossary.mdtext | 3 -
.../cat-scan-007-references.mdtext | 3 -
.../incubator-status-report-january-2007.mdtext | 26 -
.../incubator-status-report-october-2006.mdtext | 20 -
.../osgi-bundle-service-diagrams.mdtext | 18 -
modules/ROOT/pages/miscellaneous/sandbox.mdtext | 3 -
.../miscellaneous/sandbox/composite-bundles.mdtext | 242 ---
.../miscellaneous/sandbox/virtual-bundles.mdtext | 220 ---
.../miscellaneous/sandbox/web-console-ng.mdtext | 12 -
.../miscellaneous/subproject-release-status.mdtext | 100 --
.../ROOT/pages/miscellaneous/tlp-task-list.mdtext | 30 -
modules/ROOT/pages/news.mdtext | 455 ------
347 files changed, 23 insertions(+), 49492 deletions(-)
delete mode 100644 modules/ROOT/pages/documentation.mdtext
delete mode 100644 modules/ROOT/pages/documentation/community.mdtext
delete mode 100644 modules/ROOT/pages/documentation/community/contributing.mdtext
delete mode 100755 modules/ROOT/pages/documentation/community/project-info.mdtext
delete mode 100644 modules/ROOT/pages/documentation/community/projects-using-felix.mdtext
delete mode 100644 modules/ROOT/pages/documentation/development.mdtext
delete mode 100644 modules/ROOT/pages/documentation/development/coding-standards.mdtext
delete mode 100644 modules/ROOT/pages/documentation/development/dependencies-file-template.mdtext
delete mode 100644 modules/ROOT/pages/documentation/development/provisional-osgi-api-policy.mdtext
delete mode 100644 modules/ROOT/pages/documentation/development/release-management-nexus.mdtext
delete mode 100644 modules/ROOT/pages/documentation/development/site-how-to.mdtext
delete mode 100644 modules/ROOT/pages/documentation/development/using-the-osgi-compliance-tests.mdtext
delete mode 100644 modules/ROOT/pages/documentation/faqs.mdtext
delete mode 100644 modules/ROOT/pages/documentation/faqs/apache-felix-bundle-plugin-faq.mdtext
delete mode 100644 modules/ROOT/pages/documentation/faqs/apache-felix-scr-plugin-faq.mdtext
delete mode 100644 modules/ROOT/pages/documentation/getting-started.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-autoconf.adoc
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-autoconf.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-commons.adoc
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-commons.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-commons/creating-bundles-using-bnd.adoc
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-commons/creating-bundles-using-bnd.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/guides/annotations.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/guides/background.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/guides/bundles-and-dependencies.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/guides/design-patterns.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/guides/development.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/guides/dm-lambda.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/guides/history.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/guides/javadocs.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/guides/migrating-from-earlier-versions.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/guides/migrating-from-other-solutions.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/guides/performance-tuning.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/guides/resources.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/guides/whatsnew-r15.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/guides/whatsnew.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/reference/component-adapter.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/reference/component-aspect.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/reference/component-bundle-adapter.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/reference/component-factory-configuration-adapter.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/reference/component-resource-adapter.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/reference/component-singleton.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/reference/components.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/reference/dependencies.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/reference/dependency-bundle.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/reference/dependency-configuration.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/reference/dependency-resource.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/reference/dependency-service.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/reference/dm-annotations.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/reference/external-links.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/reference/service-scopes.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/reference/thread-model.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/tutorials/getting-started.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/tutorials/leveraging-the-shell.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/tutorials/sample-code.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/tutorials/working-with-annotations.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-deployment-admin.adoc
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-deployment-admin.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-event-admin.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-file-install.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-framework-security.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-framework.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-framework/apache-felix-framework-bundle-cache.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-framework/apache-felix-framework-configuration-properties.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-framework/apache-felix-framework-faq.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-framework/apache-felix-framework-launching-and-embedding.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-framework/apache-felix-framework-usage-documentation.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-gogo.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-gogo/rfc-147-overview.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-healthchecks.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-inventory.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo.adoc
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-devguide/dive-into-the-ipojo-manipulation-depths.adoc
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-devguide/dive-into-the-ipojo-manipulation-depths.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-devguide/how-to-use-ipojo-manipulation-metadata.adoc
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-devguide/how-to-use-ipojo-manipulation-metadata.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-devguide/how-to-write-your-own-handler.adoc
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-devguide/how-to-write-your-own-handler.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-eclipse-integration.adoc
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-eclipse-integration.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-feature-overview.adoc
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-feature-overview.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/apache-felix-ipojo-dosgi.adoc
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/apache-felix-ipojo-dosgi.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/how-to-use-ipojo-annotations.adoc
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/how-to-use-ipojo-annotations.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/ipojo-advanced-tutorial.adoc
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/ipojo-advanced-tutorial.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/ipojo-composition-tutorial.adoc
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/ipojo-composition-tutorial.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/ipojo-hello-word-maven-based-tutorial.adoc
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/ipojo-hello-word-maven-based-tutorial.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/ipojo-in-10-minutes.adoc
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/ipojo-in-10-minutes.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-junit4osgi.adoc
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-junit4osgi.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-junit4osgi/apache-felix-ipojo-junit4osgi-architecture.adoc
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-junit4osgi/apache-felix-ipojo-junit4osgi-architecture.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-junit4osgi/apache-felix-ipojo-junit4osgi-maven.adoc
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-junit4osgi/apache-felix-ipojo-junit4osgi-maven.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-junit4osgi/apache-felix-ipojo-junit4osgi-methods.adoc
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-junit4osgi/apache-felix-ipojo-junit4osgi-methods.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-junit4osgi/apache-felix-ipojo-junit4osgi-tutorial.adoc
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-junit4osgi/apache-felix-ipojo-junit4osgi-tutorial.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-keypoints.adoc
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-keypoints.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-successstories.adoc
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-successstories.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-supportedosgi.adoc
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-supportedosgi.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-supportedvms.adoc
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-supportedvms.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-testing-components.adoc
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-testing-components.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-tools/apache-felix-ipojo-online-manipulator.adoc
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-tools/apache-felix-ipojo-online-manipulator.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-tools/ipojo-ant-task.adoc
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-tools/ipojo-ant-task.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-tools/ipojo-arch-command.adoc
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-tools/ipojo-arch-command.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-tools/ipojo-karaf-feature.adoc
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-tools/ipojo-karaf-feature.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-tools/ipojo-maven-plug-in.adoc
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-tools/ipojo-maven-plug-in.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-tools/ipojo-webconsole-plugin.adoc
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-tools/ipojo-webconsole-plugin.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-tools/junit4osgi.adoc
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-tools/junit4osgi.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/apache-felix-ipojo-api.adoc
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/apache-felix-ipojo-api.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/apache-felix-ipojo-instances.adoc
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/apache-felix-ipojo-instances.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components.adoc
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/Callback.jpeg
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/architecture-handler.adoc
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/architecture-handler.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/configuration-handler.adoc
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/configuration-handler.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/controller-lifecycle-handler.adoc
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/controller-lifecycle-handler.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/event-admin-handlers.adoc
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/event-admin-handlers.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/extender-pattern-handler.adoc
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/extender-pattern-handler.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/injecting-bundle-context.adoc
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/injecting-bundle-context.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/ipojo-jmx-handler.adoc
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/ipojo-jmx-handler.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/lifecycle-callback-handler.adoc
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/lifecycle-callback-handler.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/providing-osgi-services.adoc
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/providing-osgi-services.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/service-requirement-handler.adoc
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/service-requirement-handler.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/temporal-service-dependency.adoc
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/temporal-service-dependency.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/white-board-pattern-handler.adoc
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/white-board-pattern-handler.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/instance-vs-service-controller.adoc
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/instance-vs-service-controller.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/ipojo-advanced-topics.adoc
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/ipojo-advanced-topics.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/ipojo-advanced-topics/combining-ipojo-and-configuration-admin.adoc
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/ipojo-advanced-topics/combining-ipojo-and-configuration-admin.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/ipojo-advanced-topics/constructing-pojo-objects-with-factory-methods.adoc
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/ipojo-advanced-topics/constructing-pojo-objects-with-factory-methods.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/ipojo-advanced-topics/how-to-use-ipojo-factories.adoc
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/ipojo-advanced-topics/how-to-use-ipojo-factories.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/ipojo-advanced-topics/ipojo-extender-configuration.adoc
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/ipojo-advanced-topics/ipojo-extender-configuration.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/ipojo-advanced-topics/ipojo-factory-service.adoc
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/ipojo-advanced-topics/ipojo-factory-service.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/ipojo-advanced-topics/ipojo-hierarchical-composition-overview.adoc
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/ipojo-advanced-topics/ipojo-hierarchical-composition-overview.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/ipojo-advanced-topics/service-binding-interceptors.adoc
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/ipojo-advanced-topics/service-binding-interceptors.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/ipojo-advanced-topics/using-ipojo-introspection-api.adoc
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/ipojo-advanced-topics/using-ipojo-introspection-api.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/ipojo-advanced-topics/using-stereotypes.adoc
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/ipojo-advanced-topics/using-stereotypes.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/ipojo-faq.adoc
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/ipojo-faq.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/using-xml-schemas.adoc
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/using-xml-schemas.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-why-choose-ipojo.adoc
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-why-choose-ipojo.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/articles-and-presentations.adoc
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/articles-and-presentations.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/developing-camel-mediators-with-ipojo.adoc
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/developing-camel-mediators-with-ipojo.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/download.adoc
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/download.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/ipojo-news.adoc
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/ipojo-news.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/ipojo-reference-card.adoc
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/ipojo-reference-card.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/ipojo-support.adoc
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/ipojo-support.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/related-works.adoc
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/related-works.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-jaas.adoc
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-jaas.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-lightweight-http-service.adoc
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-lightweight-http-service.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-log.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-logback.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-manifest-generator-mangen.adoc
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-manifest-generator-mangen.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-maven-bundle-plugin-bnd.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-maven-obr-plugin.adoc
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-maven-obr-plugin.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-maven-osgi-plugin.adoc
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-maven-osgi-plugin.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-maven-scr-plugin.adoc
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-maven-scr-plugin.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-maven-scr-plugin/apache-felix-maven-scr-plugin-use.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-maven-scr-plugin/apache-felix-scr-ant-task-use.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-maven-scr-plugin/apache-felix-scr-bndtools-use.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-maven-scr-plugin/extending-scr-annotations.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-maven-scr-plugin/scr-annotations.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-maven-scr-plugin/scr-javadoc-tags.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-metatype-service.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-osgi-bundle-repository.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-osgi-core.adoc
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-osgi-core.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-preferences-service.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-remote-shell.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-script-console-plugin.adoc
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-script-console-plugin.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-serialization-framework.adoc
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-serialization-framework.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-shell-tui.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-shell.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-upnp.adoc
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-upnp.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-upnp/upnp-acknowledgments.adoc
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-upnp/upnp-acknowledgments.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-upnp/upnp-driver-architecture.adoc
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-upnp/upnp-driver-architecture.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-upnp/upnp-getting-started.adoc
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-upnp/upnp-getting-started.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-upnp/upnp-known-issues.adoc
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-upnp/upnp-known-issues.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-upnp/upnp-testing-devices.adoc
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-upnp/upnp-testing-devices.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-upnp/upnp-testing-devices/upnp-examples.adoc
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-upnp/upnp-testing-devices/upnp-examples.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-upnp/upnp-testing-devices/upnp-examples/upnp-writing-cd-and-cp.adoc
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-upnp/upnp-testing-devices/upnp-examples/upnp-writing-cd-and-cp.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-user-admin.adoc
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-user-admin.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-user-admin/apache-felix-user-admin-background.adoc
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-user-admin/apache-felix-user-admin-background.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-user-admin/apache-felix-user-admin-file-store.adoc
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-user-admin/apache-felix-user-admin-file-store.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-user-admin/apache-felix-user-admin-getting-started.adoc
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-user-admin/apache-felix-user-admin-getting-started.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-user-admin/apache-felix-user-admin-introduction.adoc
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-user-admin/apache-felix-user-admin-introduction.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-user-admin/apache-felix-user-admin-mongodb-store.adoc
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-user-admin/apache-felix-user-admin-mongodb-store.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-web-console.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-web-console/extending-the-apache-felix-web-console.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-web-console/extending-the-apache-felix-web-console/branding-the-web-console.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-web-console/extending-the-apache-felix-web-console/providing-resources.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-web-console/extending-the-apache-felix-web-console/providing-web-console-plugins.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-web-console/extending-the-apache-felix-web-console/web-console-logging.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-web-console/extending-the-apache-felix-web-console/web-console-output-templating.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-web-console/web-console-restful-api.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/apache-felix-web-console/web-console-security-provider.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/mosgi-managed-osgi-framework.adoc
delete mode 100644 modules/ROOT/pages/documentation/subprojects/mosgi-managed-osgi-framework.mdtext
delete mode 100644 modules/ROOT/pages/documentation/subprojects/mosgi-managed-osgi-framework/probeguide.adoc
delete mode 100644 modules/ROOT/pages/documentation/subprojects/mosgi-managed-osgi-framework/probeguide.mdtext
delete mode 100644 modules/ROOT/pages/documentation/tutorials-examples-and-presentations.mdtext
delete mode 100644 modules/ROOT/pages/documentation/tutorials-examples-and-presentations/apache-felix-application-demonstration.mdtext
delete mode 100644 modules/ROOT/pages/documentation/tutorials-examples-and-presentations/apache-felix-osgi-faq.mdtext
delete mode 100644 modules/ROOT/pages/documentation/tutorials-examples-and-presentations/apache-felix-osgi-tutorial.mdtext
delete mode 100644 modules/ROOT/pages/documentation/tutorials-examples-and-presentations/apache-felix-osgi-tutorial/apache-felix-tutorial-example-1.mdtext
delete mode 100644 modules/ROOT/pages/documentation/tutorials-examples-and-presentations/apache-felix-osgi-tutorial/apache-felix-tutorial-example-2.mdtext
delete mode 100644 modules/ROOT/pages/documentation/tutorials-examples-and-presentations/apache-felix-osgi-tutorial/apache-felix-tutorial-example-2b.mdtext
delete mode 100644 modules/ROOT/pages/documentation/tutorials-examples-and-presentations/apache-felix-osgi-tutorial/apache-felix-tutorial-example-3.mdtext
delete mode 100644 modules/ROOT/pages/documentation/tutorials-examples-and-presentations/apache-felix-osgi-tutorial/apache-felix-tutorial-example-4.mdtext
delete mode 100644 modules/ROOT/pages/documentation/tutorials-examples-and-presentations/apache-felix-osgi-tutorial/apache-felix-tutorial-example-5.mdtext
delete mode 100644 modules/ROOT/pages/documentation/tutorials-examples-and-presentations/apache-felix-osgi-tutorial/apache-felix-tutorial-example-6.mdtext
delete mode 100644 modules/ROOT/pages/documentation/tutorials-examples-and-presentations/apache-felix-osgi-tutorial/apache-felix-tutorial-example-7.mdtext
delete mode 100644 modules/ROOT/pages/documentation/tutorials-examples-and-presentations/apache-felix-osgi-tutorial/apache-felix-tutorial-example-8.mdtext
delete mode 100644 modules/ROOT/pages/documentation/tutorials-examples-and-presentations/apache-felix-osgi-tutorial/apache-felix-tutorial-example-9.mdtext
delete mode 100644 modules/ROOT/pages/errors/403.mdtext
delete mode 100644 modules/ROOT/pages/errors/404.mdtext
delete mode 100644 modules/ROOT/pages/index.mdtext
delete mode 100644 modules/ROOT/pages/license.mdtext
delete mode 100644 modules/ROOT/pages/media.mdtext
delete mode 100644 modules/ROOT/pages/miscellaneous.mdtext
delete mode 100644 modules/ROOT/pages/miscellaneous/apache-karaf.mdtext
delete mode 100644 modules/ROOT/pages/miscellaneous/board-reports.mdtext
delete mode 100644 modules/ROOT/pages/miscellaneous/board-reports/apache-felix-board-report-template.mdtext
delete mode 100644 modules/ROOT/pages/miscellaneous/board-reports/board-report-2007-04.mdtext
delete mode 100644 modules/ROOT/pages/miscellaneous/board-reports/board-report-2007-05.mdtext
delete mode 100644 modules/ROOT/pages/miscellaneous/board-reports/board-report-2007-06.mdtext
delete mode 100644 modules/ROOT/pages/miscellaneous/board-reports/board-report-2007-09.mdtext
delete mode 100644 modules/ROOT/pages/miscellaneous/board-reports/board-report-2007-12.mdtext
delete mode 100644 modules/ROOT/pages/miscellaneous/board-reports/board-report-2008-03.mdtext
delete mode 100644 modules/ROOT/pages/miscellaneous/board-reports/board-report-2008-06.mdtext
delete mode 100644 modules/ROOT/pages/miscellaneous/board-reports/board-report-2008-09.mdtext
delete mode 100644 modules/ROOT/pages/miscellaneous/board-reports/board-report-2008-12.mdtext
delete mode 100644 modules/ROOT/pages/miscellaneous/board-reports/board-report-2009-03.mdtext
delete mode 100644 modules/ROOT/pages/miscellaneous/board-reports/board-report-2009-06.mdtext
delete mode 100644 modules/ROOT/pages/miscellaneous/board-reports/board-report-2009-09.mdtext
delete mode 100644 modules/ROOT/pages/miscellaneous/board-reports/board-report-2009-12.mdtext
delete mode 100644 modules/ROOT/pages/miscellaneous/board-reports/board-report-2010-03.mdtext
delete mode 100644 modules/ROOT/pages/miscellaneous/board-reports/board-report-2010-06.mdtext
delete mode 100644 modules/ROOT/pages/miscellaneous/board-reports/board-report-2010-09.mdtext
delete mode 100644 modules/ROOT/pages/miscellaneous/board-reports/board-report-2010-12.mdtext
delete mode 100644 modules/ROOT/pages/miscellaneous/board-reports/board-report-2011-03.mdtext
delete mode 100644 modules/ROOT/pages/miscellaneous/board-reports/board-report-2011-06.mdtext
delete mode 100644 modules/ROOT/pages/miscellaneous/board-reports/board-report-2011-09.mdtext
delete mode 100644 modules/ROOT/pages/miscellaneous/board-reports/board-report-2011-12.mdtext
delete mode 100644 modules/ROOT/pages/miscellaneous/board-reports/board-report-2012-03.mdtext
delete mode 100644 modules/ROOT/pages/miscellaneous/board-reports/board-report-2012-06.mdtext
delete mode 100644 modules/ROOT/pages/miscellaneous/board-reports/board-report-2012-09.mdtext
delete mode 100644 modules/ROOT/pages/miscellaneous/board-reports/board-report-2012-12.mdtext
delete mode 100644 modules/ROOT/pages/miscellaneous/board-reports/board-report-2013-03.mdtext
delete mode 100644 modules/ROOT/pages/miscellaneous/cat-scan-project-proposal.mdtext
delete mode 100644 modules/ROOT/pages/miscellaneous/cat-scan-project-proposal/cat-scan-001-use-cases.mdtext
delete mode 100644 modules/ROOT/pages/miscellaneous/cat-scan-project-proposal/cat-scan-002-profiles.mdtext
delete mode 100644 modules/ROOT/pages/miscellaneous/cat-scan-project-proposal/cat-scan-002-profiles/cat-scan-002-001-basic-profile.mdtext
delete mode 100644 modules/ROOT/pages/miscellaneous/cat-scan-project-proposal/cat-scan-003-run-log-archive.mdtext
delete mode 100644 modules/ROOT/pages/miscellaneous/cat-scan-project-proposal/cat-scan-004-api-reference.mdtext
delete mode 100644 modules/ROOT/pages/miscellaneous/cat-scan-project-proposal/cat-scan-005-technical-compatibility-kit.mdtext
delete mode 100644 modules/ROOT/pages/miscellaneous/cat-scan-project-proposal/cat-scan-006-glossary.mdtext
delete mode 100644 modules/ROOT/pages/miscellaneous/cat-scan-project-proposal/cat-scan-007-references.mdtext
delete mode 100644 modules/ROOT/pages/miscellaneous/incubator-status-report-january-2007.mdtext
delete mode 100644 modules/ROOT/pages/miscellaneous/incubator-status-report-october-2006.mdtext
delete mode 100644 modules/ROOT/pages/miscellaneous/osgi-bundle-service-diagrams.mdtext
delete mode 100644 modules/ROOT/pages/miscellaneous/sandbox.mdtext
delete mode 100644 modules/ROOT/pages/miscellaneous/sandbox/composite-bundles.mdtext
delete mode 100644 modules/ROOT/pages/miscellaneous/sandbox/virtual-bundles.mdtext
delete mode 100644 modules/ROOT/pages/miscellaneous/sandbox/web-console-ng.mdtext
delete mode 100644 modules/ROOT/pages/miscellaneous/subproject-release-status.mdtext
delete mode 100644 modules/ROOT/pages/miscellaneous/tlp-task-list.mdtext
delete mode 100644 modules/ROOT/pages/news.mdtext
[felix-antora-site] 10/18: remove maven osgi plugin doc
(unmaintained)
Posted by dj...@apache.org.
This is an automated email from the ASF dual-hosted git repository.
djencks pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/felix-antora-site.git
commit 148d3433d973b3299d6031308e97b6dafdf35050
Author: David Jencks <dj...@apache.org>
AuthorDate: Sun Jul 11 15:45:22 2021 -0700
remove maven osgi plugin doc (unmaintained)
---
modules/ROOT/pages/documentation/subprojects.adoc | 2 +-
.../apache-felix-maven-osgi-plugin.adoc | 22 ----------------------
2 files changed, 1 insertion(+), 23 deletions(-)
diff --git a/modules/ROOT/pages/documentation/subprojects.adoc b/modules/ROOT/pages/documentation/subprojects.adoc
index 5069fd6..32b2c4d 100644
--- a/modules/ROOT/pages/documentation/subprojects.adoc
+++ b/modules/ROOT/pages/documentation/subprojects.adoc
@@ -122,7 +122,7 @@ The last documentation may be found in the https://github.com/apache/felix-site-
* https://github.com/apache/felix-site-pub/blob/last-cms/documentation/subprojects/apache-felix-lightweight-http-service.html[Lightweight HTTP Service]
* https://github.com/apache/felix-site-pub/blob/last-cms/documentation/subprojects/apache-felix-manifest-generator-mangen.html[Manifest Generator (mangen)]
* https://github.com/apache/felix-site-pub/blob/last-cms/documentation/subprojects/apache-felix-maven-obr-plugin.html[Maven OBR Plugin]
-* xref:documentation/subprojects/apache-felix-maven-osgi-plugin.adoc[Maven OSGi Plugin]
+* https://github.com/apache/felix-site-pub/blob/last-cms/documentation/subprojects/apache-felix-maven-osgi-plugin.html[Maven OSGi Plugin]
* xref:documentation/subprojects/apache-felix-maven-scr-plugin.adoc[Maven SCR Plugin]
* xref:documentation/subprojects/mosgi-managed-osgi-framework.adoc[MOSGi Managed OSGi framework]
* xref:documentation/subprojects/apache-felix-osgi-core.adoc[OSGi Core]
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-maven-osgi-plugin.adoc b/modules/ROOT/pages/documentation/subprojects/apache-felix-maven-osgi-plugin.adoc
deleted file mode 100644
index e663c28..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-maven-osgi-plugin.adoc
+++ /dev/null
@@ -1,22 +0,0 @@
-= Apache Felix Maven OSGi Plugin
-
-WARNING:: totally obsolete.
-WARNING:: most of the mdtext content was not converted.
-Consult git history
-
-The OSGi plugin for Maven 2.0 is currently under development at the http://incubator.apache.org/felix[Apache Felix] project, and this page documents the plugin's current state of functionality and will serve as a how-to guide for its use.
-
-The main task this plugin aims to accomplish is the generation of OSGi-compliant bundle archives.
-To this end, the plugin provides an integraton with Maven 2's project object model (POM) with particular focus on manipulation of the bundle's manifest and the automated generation of some headers (e.g., Bundle-ClassPath, Import-Package, and Bundle-Activator).
-
-== Current Plugin Functionality
-
-=== Standard Features
-
-The plugin provides the user with two ways to manipulate the contents of a bundle's manifest:
-
-. Path and filename of a manifest.mf file in which the contents will be merged with the default entries generated by Maven 2.
-Note that _any_ manifest entry can be added to the bundle's manifest using this technique - java-standard, osgi-standard, or custom entries.
-The path name is relative to the root of the Maven 2 project, and is specified using the following POM notation:
-
-
[felix-antora-site] 08/18: remove mangen doc (unmaintained)
Posted by dj...@apache.org.
This is an automated email from the ASF dual-hosted git repository.
djencks pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/felix-antora-site.git
commit 5edb28eb8e461a34ab96abb15387fdba2decb337
Author: David Jencks <dj...@apache.org>
AuthorDate: Sun Jul 11 15:43:20 2021 -0700
remove mangen doc (unmaintained)
---
modules/ROOT/pages/documentation/subprojects.adoc | 2 +-
.../apache-felix-manifest-generator-mangen.adoc | 662 ---------------------
2 files changed, 1 insertion(+), 663 deletions(-)
diff --git a/modules/ROOT/pages/documentation/subprojects.adoc b/modules/ROOT/pages/documentation/subprojects.adoc
index 7793f49..32fcbce 100644
--- a/modules/ROOT/pages/documentation/subprojects.adoc
+++ b/modules/ROOT/pages/documentation/subprojects.adoc
@@ -120,7 +120,7 @@ The last documentation may be found in the https://github.com/apache/felix-site-
* https://github.com/apache/felix-site-pub/blob/last-cms/documentation/subprojects/apache-felix-ipojo.html[iPOJO]
* https://github.com/apache/felix-site-pub/blob/last-cms/documentation/subprojects/apache-felix-jaas.html[JAAS Support]
* https://github.com/apache/felix-site-pub/blob/last-cms/documentation/subprojects/apache-felix-lightweight-http-service.html[Lightweight HTTP Service]
-* xref:documentation/subprojects/apache-felix-manifest-generator-mangen.adoc[Manifest Generator (mangen)]
+* https://github.com/apache/felix-site-pub/blob/last-cms/documentation/subprojects/apache-felix-manifest-generator-mangen.html[Manifest Generator (mangen)]
* xref:documentation/subprojects/apache-felix-maven-obr-plugin.adoc[Maven OBR Plugin]
* xref:documentation/subprojects/apache-felix-maven-osgi-plugin.adoc[Maven OSGi Plugin]
* xref:documentation/subprojects/apache-felix-maven-scr-plugin.adoc[Maven SCR Plugin]
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-manifest-generator-mangen.adoc b/modules/ROOT/pages/documentation/subprojects/apache-felix-manifest-generator-mangen.adoc
deleted file mode 100644
index ea55c8b..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-manifest-generator-mangen.adoc
+++ /dev/null
@@ -1,662 +0,0 @@
-= Apache Felix Manifest Generator (mangen)
-
-== `mangen` - http://www.osgi.org[OSGi] Bundle Manifest generator
-
-== Introduction
-
-[cols=4*]
-|===
-| The http://www.osgi.org[OSGi] model provides a very powerful and flexible framework for developing Java applications in a modular fashion with a high degree of control over classloading inter-dependencies between modules.
-Projects such as [Oscar
-| http://oscar.objectweb.org/] and [Felix
-| http://incubator.apache.org/felix/] have recognised this power and implemented open source implementations of the framework.
-Adding to this is a growing availability of open source application bundles such as those offered via the [Oscar Bundle Repository
-| http://oscar-osgi.sourceforge.net/] (aka OBR).
-|===
-
-As an active developer of OSGi based application, http://www.ascert.com/[Ascert's] technical staff grappled with the cumbersome task of manually creating OSGi Bundle Manifests.
-This task is never particularly interesting and only gets bigger and nastier as applications grow in size and the number of bundles present.
-To alleviate this chore the `mangen` tool has been created, with the following goals:
-
-* Provide automatic scanning of an OSGi bundle JAR to detect references to external classes which require imports and possible export packages
-* Support scanning of multiple bundle JARs in a single pass, including any JAR files within a specified directory tree
-* Detect the majority of common import and export cases and provide manual override mechanisms to include cases that are not detected
-* Provide a simple, extensible, rule based mechansim to allow the required imports and possible exports sets to be refined e.g.
-removing un-needed packages, automatic resolving to packages in other JARs etc.
-* Provide a simple, extensible, reporting mechanism of actions taken
-* Automatic updating of each bundle JAR's Manifest, including a means to easily switch between either OSGi R3 or R4 compatible Manifest headers
-
-If you're not a Java developer, or you're not sure what OSGi is yet, then this tool is probably not for you!
-
-=== Licensing
-
-The `mangen` utility was originally created as a copyrighted ©
-work of Ascert LLC, and released as _OSI Certified Open Source Software_ for use under the under the terms of the http://www.opensource.org/licenses/cpl1.0.php[Common Public License]
-
-[cols=2*]
-|===
-| To promote wider use and enhancement, Ascert submitted version 1.0.1 of `mangen` to the http://incubator.apache.org/felix/[Apache Felix] project, where it will be actively developed and maintained by Felix project team.
-Availability is now under an [Apache 2.0 style license
-| http://www.apache.org/licenses/LICENSE-2.0]
-|===
-
-Included third-party libraries and contributions are copyrighted ©
-works of their respective owners and are provided under the terms of their specified licenses.
-
-== Using `mangen`
-
-=== Basic operation
-
-Using mangen is very simple.
-Unpack the distribution file to an installation directory, change to this directory and type the following command:
-
- java -jar lib/mangen.jar <file-list>
-
-_Note: on Windows platforms you will need to use a '' in place of the '/' file separator_
-
-Where:
-
-* *<file-list>* - is either a list of bundle JARs to be processed or a list of directories, or a mix of both.
-Each directory will be scanned and all JAR files in the directory, or any sub-directories will be included in the bundle JARs processed.
-
-The basic behaviour of `mangen` is to process the set of bundle JARs supplied and scan the classes within each JAR to build up a set of the possible exports and required imports for each JAR.
-Where inner jars are defined using the OSGi `Bundle-ClassPath` header the classes in these will also be scanned and the possible exports and required imports will be included in the sets generated for their enclosing JAR.
-
-Two phases of process happen after JAR scanning has completed:
-
-* Rule execution - typically rules will process the sets of imports and exports determined by `mangen` for each JAR, refining them according to the rule types being executed and the specific rule options
-* Report production - typically generating narrative reports on the bundles processed and the rules executed.
-
-[cols=2*]
-|===
-| Use of the word 'typically' is significant in the above descriptions.
-A basic set of xref:#_rules[rules] and xref:#_reports[reports] are included with `mangen` to perform various useful tasks.
-This set is infinitely extensible, however, and `mangen` places no restriction on the types of tasks that rules and reports can perform.
-|===
-
-The exact rules and reports to be run are entirely controlled by user configurable properties as described below.
-If no properties are supplied `mangen` will simply run, process the specified JAR files and exit.
-
-=== Configuring `mangen` with Properties
-
-Properties to control `mangen` behaviour can either be supplied on the command line using the normal `-D` syntax or, for most cases in a `mangen.properties` file.
-If the same property name is specified in both then the `-D` command line property value will take precedence of the property file value.
-
-For added flexibility a simple variable expansion syntax is provided to allow the value of one Property value to be used within another property.
-Every property value will be scanned for `$\{property-name}` markers.
-Where these are found the marker will be replaced with the value of the associated `property-name`.
-
-_Example:_
-
- mangen.osgi.level=3
- ...
- mangen.rulesets=mangen-rule-R${mangen.osgi.level}-
-
-==== mangen.properties
-
-The `mangen.properties` Property is used to instruct mangen where to find it's properties file.
-By default, `mangen` will look for a file named `mangen.properties` in the same directory in which `mangen.jar` was installed (i.e.
-`lib/mangen.properties`).
-By including a `-Dmangen.properties` setting on the command line a different properties file can be specified.
-
-_Example:_
-
- java -jar lib/mangen.jar -Dmangen.properties=my_mangen.properties my_app.jar
-
-==== mangen.osgi.level
-
-There are two places in which the `mangen.osgi.level` Property is used:
-
-* internally within `mangen` to determine the correct format of Manifest headers to be processed and generated.
-* as a means to guide which rulesets are executed, using the xref:#_configuring_mangen_with_properties[variable-expansion syntax]
-
-At present, this Property should be set to a value of '3' or '4' (the default if not specified will be '3');
-
-==== mangen.rulesets
-
-Rules are the engine room of `mangen`, providing the basic means for refining the `mangen` detected import and export package sets e.g.
-removing un-needed or unused exports, supplying package version information, including undetectable package cases such as dynamic classloading.
-
-Rulesets provide a simple means of organising the rules to be executed into groups of rule sets.
-The rulesets are specified as a list of comma-separated values, each value specifying the ruleset name prefix.
-The following example shows a ruleset definition for 2 rules:
-
- mangen.rulesets=mangen-rule-first- , mangen-rule-final-
- ...
- mangen-rule-first-0=...
- mangen-rule-first-1=...
- mangen-rule-first-2=...
- ...
- mangen-rule-final-0=...
- mangen-rule-final-1=...
-
-As shown in the example, `mangen` will take each ruleset name and look for sequentially numbered properties, starting from 0 and finishing when no property name is found.
-Each rule found will be executed to completion against the processed set of bundle JARs before the next rule property is processed.
-
-Rulesets can be combined with xref:#_configuring_mangen_with_properties[variable-expansion] to provide OSGi version dependent rules as shown the following example.
-
- mangen.osgi.level=3
- mangen.rulesets=mangen-rule-R${mangen.osgi.level}-
- ...
- mangen-rule-R3-0=...
- ...
- mangen-rule-R4-0=...
-
-Rules themselves are simply specified as a rule type followed by a space separate list of rule specific options e.g.
-
- mangen.R4.syspackages=java\\..*
- ...
- mangen-rule-basic-0=Ignore imports(${mangen.R4.syspackages})
- mangen-rule-basic-1=DontImportOwnExports
-
-See the xref:#_rules[Rules] section for full details of the currently support rule types.
-
-==== mangen-report
-
-Reports in `mangen` work in a similar fashion to rules but without the ruleset concept.
-The set of sequentially numbered `mangen-report-` properties will be scanned to determine which reports should be run e.g.
-
- mangen-report-0=RuleReport .*
- mangen-report-1=BundleReport .*
-
-See the xref:#_reports[Reports] section for full details of the currently support report types.
-
-==== mangen.failonerror
-
-If set `on` will cause `mangen` to exit with a `System.exit()` error status of 3 if any errors occured.
-Typical usage is to allow an external build tool, such as Ant, detect that there were errors.
-Additionally, any error messages will also be sent to `stderr` as well as `stdout` if this property is set.
-
-Default is `on`.
-
-==== mangen.failonwarning
-
-If set `on` will cause `mangen` to exit with a `System.exit()` error status of 5 if any warnings occured.
-Typical usage is to allow an external build tool, such as Ant, detect that there were warnings.
-Additionally, any warning messages will also be sent to `stderr` as well as `stdout` if this property is set.
-
-Default is `off`.
-
-=== Rules
-
-The Rule concept in `mangen` was adopted to avoid hard-coding the types of post-processing steps that a user would be able to perform on the `mangen` generated set of package imports and exports.
-The rule syntax is as follows:
-
- <rule-type> <rule-options>
-
-Where:
-
-* *<rule-type>* - must be the name of a valid existing rule type, details of which can be found in this section.
-* *<rule-options>* - will be a list of one or more of the standard options and/or rule specific options.
-The standard options are as follows:
-** `imports()` - a comma seperated list of package patterns, using the JDK regex format.
-These will be matched against a bundle's own import packages during rule processing, the specific handling undertaken for each match being dependent on the *<rule-type>*.
-*Note: each pattern must be separated from the next by a comma (,) and the list must not contain any space characters.*
-** `exports()` - a comma seperated list of package patterns, using the JDK regex format.
-These will be matched against a bundle's own export packages during rule processing, the specific handling undertaken for each match being dependent on the *<rule-type>*.
-** `sys-packages()` - a comma seperated list of standard 'system package' patterns, using the JDK regex format.
-The specific handling undertaken for each match being dependent on the *<rule-type>*
-
-Rules will can have either "global" scope, in which case every bundle JAR processed will have the rule appplied, or "local" scope meaning that they will only apply to a single bundle JAR.
-Global rules will be included in the `mangen.properties` file.
-Local rules are placed within the Manifest for the appropriate bundle in a special `mangen` attributes section e.g.
-
-----
- Bundle-Name: Help Component
- Bundle-ClassPath: .,help4.jar,oracle_ice.jar,ohj-jewt.jar
- Metadata-Location: metadata.xml
-
- Name: com/ascert/openosgi/mangen
- mangen-rule-0: Ignore imports(com\.adobe\.acrobat.*,webeq\..*,javax\.help,javax\.media)
-----
-
-Details are included below showing whether a *<rule-type>* can be used in a global or a local context
-
-==== AttributeStamp
-
-[cols=2*]
-|===
-| _Usable globally_
-| `yes`
-
-| _Usable locally_
-| `yes`
-
-| _Standard options_
-| `imports`, `exports`
-
-| _Rule specific options_
-|
-|===
-
-When processing a bundle JAR `mangen` can only detect the name of a required import package or a possible export package.
-Within an OSGi environment it's possible to also include qualifying information on a package name, such as versioning information.
-The AttributeStamp rule allows this information to be "stamped" over a detected package name.
-
-The rule may be supplied locally, in which case it will only apply to instances of a package name match with a specific bundle JAR, or globally in which case it will be applied to all instances of a package name match across all JARs.
-
-The `imports` or `exports` options allow stamping of attributes to either imported or exported packages respectively.
-The rule will perform a regex package name match against each entry in the list and if the name matches, will augment the matched package name with any additional attributes suppled.
-The following shows an example of this.
-
-_Example:_
-
- mangen-rule-1=AttributeStamp imports(org\\.osgi\\.framework;version="1.2.0")
-
-If the rule finds a package name pattern match and the package already has additional attributes an error will be thrown if the stamped attributes do not match the existing attributes.
-This could be the case as a result of either a previous AttributeStamp or Merge rule.
-
-==== DontImportOwnExports
-
-[cols=2*]
-|===
-| _Usable globally_
-| `yes`
-
-| _Usable locally_
-| `yes`
-
-| _Standard options_
-|
-
-| _Rule specific options_
-|
-|===
-
-In many application cases it's not necessary for a bundle JAR to import it' own exports.
-This rule may be used locally or globally to remove from a bundle's import list any package which it also exports.
-
-==== Ignore
-
-[cols=2*]
-|===
-| _Usable globally_
-| `yes`
-
-| _Usable locally_
-| `yes`
-
-| _Standard options_
-| `imports`, `exports`
-
-| _Rule specific options_
-|
-|===
-
-There are several cases where a `mangen` detected possible export or required import may not actually be desired:
-
-* Standard JDK classes, particularly in an OSGi R3 environment where these packages are resolved without needing import statements
-* Packages which `mangen` detects as needing imports but won't actually be used in a running environment.
-One example of these is third party JARs which include Ant tasks for use in a development environment but which would probably never be instantiated in a running application.
-
-The Ignore rule will remove matching package entries from either the import or export lists, or both, as specified in the options.
-
-_Example:_
-
- mangen.R4.syspackages=java\\..*
- mangen-rule-R4-0=Ignore imports(${mangen.R4.syspackages})
-
-==== Merge
-
-[cols=2*]
-|===
-| _Usable globally_
-| `yes`
-
-| _Usable locally_
-| `yes`
-
-| _Standard options_
-| `imports`, `exports`
-
-| _Rule specific options_
-| `existing`, `fixed`
-|===
-
-In some cases the simplest way to use `mangen` will be to provide a list of known imports and exports and then have `mangen` "merge" any remaining required imports and possible exports into these lists as needed.
-The Merge rule provides two mechanisms in which these known imports and exports can be supplied:
-
-* Using `existing` Manifest entries - in which case `mangen` will take any current Import-Package and Export-Package headers and merge them into the detected import and export package sets
-* By specifying a set of `fixed` Manifest entries - allowing a limited set of pre-determined entries to be listed in the special `mangen` attributes of the Manifest which will be merged in.
-
-_Example:_
-
-----
- Manifest-Version: 1.0
- Bundle-Name: mybundle
- Export-Package: my.bundle.package
-
- Name: com/ascert/openosgi/mangen
- Import-Package: some.other.package
-----
-
-A `Merge existing` rule using the above example would ensure that `my.bundle.package` appeared in the list of packages to export.
-A `Merge fixed` would ensure that `some.other.package` appeared in the list of packages to import.
-
-It's possible to use both `Merge existing` and `Merge fixed` within a given set of application rules although it's more likely that only one of these would be used to meet a given application build strategy.
-
-The imports and exports options allow constraints on the packages to be merged based on regex package name pattern matches.
-
-One other aspect to note with the Merge option is that it also provides an alternative way to "stamp" OSGi attributes on a `mangen` detected pakcage name, since if the package being merged was already in the set of `mangen` detected packages it's entry will be augmented with any additional attributes supplied from the package entry being merged.
-
-==== ProcessBundles
-
-[cols=2*]
-|===
-| _Usable globally_
-| `yes`
-
-| _Usable locally_
-| `no`
-
-| _Standard options_
-|
-
-| _Rule specific options_
-|
-|===
-
-By default, `mangen` will not actually process any of the JAR files specified, it will simply create objects to access them.
-
-Being able to skip `mangen` processing of bundle JARs is useful behaviour in a small number of instances, such as the xref:#_obrreport[ObrReport] that will generally be run against existing bundle Manifest headers rather than `mangen` generated sets of imports and exports.
-
-For most cases, however, `mangen` import and export processing will be required and this Rule should be included.
-
-_Example:_
-
-----
- mangen.rulesets=mangen-rule-initial- , mangen-rule-Ant- , mangen-rule-R${mangen.osgi.level}- , mangen-rule- , mangen-rule-final-
-
- mangen-rule-initial-0=ProcessBundles
- ...
-----
-
-==== ResolveImportsToExports
-
-[cols=2*]
-|===
-| _Usable globally_
-| `yes`
-
-| _Usable locally_
-| `no`
-
-| _Standard options_
-| `sys-packages`
-
-| _Rule specific options_
-|
-|===
-
-Some OSGi developers use the framework as a basis for creating packaged applications, in fact it is just this usage which Ascert make of OSGi and Oscar and which motivated the creation of =mangen.
-In such cases, the simplest and possibly most powerful rule use case is simply to supply `mangen` with a complete set of application bundles and let it work out the matrix of imports and exports required to resolve every bundle dependency.
-This is exactly what the ResolveImportsToExports does.
-
-ResolveImportsToExports can only be used globally and will prune down the set of possible exports and required imports to just those required to satisfy every bundle dependency.
-It will generate `+*** WARNING ***+` report lines for the following cases:
-
-* duplicate exports where more than one bundle could be an exporter of the same package which is a necessary import of some other bundle.
-In these cases, at present, the first possible exporter found will be picked and all others removed and a warning generated
-* missing exports i.e.
-packages required by one or more bundles that are never exported.
-Erroneous warnings for standard JDK packages can be avoided using the `sys-packages` option.
-
-At present, the known cases where this rule may fail to create a consistent and resolved set of bundle Manifests are:
-
-* cases of dynamic classloading
-* certain third party JARs, such as Xerces, which use the awkaward-to-handle OSGi case of `Thread.getContextClassLoader()` to determine the classloader for dynamic classloading.
-
-==== UpdateBundles
-
-[cols=2*]
-|===
-| _Usable globally_
-| `yes`
-
-| _Usable locally_
-| `no`
-
-| _Standard options_
-|
-
-| _Rule specific options_
-| `overwrite`
-|===
-
-By default, `mangen` will only report on the generated list of imports and exports for each bundle processed.
-The UpdateBundles rule can be used to instruct `mangen` to update each bundle's Manifest wth the set of generated packages.
-
-This rule can only be used globaly.
-If the `overwrite` option is specified, the bundle JAR will overwritten with a new bundle JAR containing the new Manifest.
-Without this option, the update will create new JARs of the same name as each existing JAR but with a suffix of `.new.jar`.
-
-=== Reports
-
-Reports are really like a simplified case of rules.
-At present only a couple of simple reports are included.
-
-All reports at present send their output to `System.out`, which can of course be redirected to a text file if a persistent copy is desired.
-
-==== RuleReport
-
-This report will show any Rule generated output.
-
-==== BundleReport
-
-[cols=2*]
-|===
-| _Report options_
-| `show-differences` `show-local-rules`
-|===
-
-This report will create a simple overview of the refined set of a bundle's imports and exports, together with a report of any local rules which have been run for the bundle.
-The following options are supported:
-
-* `show-differences` - will show details of _ADDED_ and _REMOVED_ packages by comparing the generate set of import and export packages against the existing Import-Package and Export-Package attributes.
-If this option is omitted a simple list of generated imports and exports will be shown
-* `show-local-rules` - will show report output from any local rules run for each bundle JAR
-
-==== ObrReport
-
-[cols=2*]
-|===
-| _Report options_
-| `skip-jars`
-|===
-
-Produce a report for each bundle JAR that can be used as an OBR descriptor.
-
-The `skip-jars` option can be used to specify a comma separated list of JAR name regex patterns for which OBR descriptors are not required (e.g.
-source JARs).
-
-OBR descriptor production is a quite different aspect of `mangen` usage to import/export generation and so a separate example `obr.properties` file has been included to show typical settings for it's usage.
-The `-Dmangen.properties` setting can be used to run `mangen` with these settings e.g.
-
-_Example:_
-
- java -Dmangen.properties=lib\obr.properties -jar lib\mangen.jar e:\obr\repo\
-
-The example `obr.properties` includes a number of features:
-
-* there is no _ProcessBundles_ rule, meaning that `mangen` will not automatically generate imports and exports.
-* there is a _Merge existing_ rule meaning `mangen` will use existing Manifest headers in each bundle JAR to generate the ObrReport
-* there is an `mangen.obr.ver` property that can be used to control the format of the OBR descriptors produced
-* text templates are included that allow the OBR version 1 and version 2 descriptors to be changed without needing to modify the ObrReport code.
-
-Whilst running, the ObrReport will look for a number of specific properties to aid it's processing:
-
-* `mangen.obr.ver` - to determine which format of OBR descriptor to produce
-* `mangen.obr.descr.<obr-ver>` - the main text template used to produce the OBR descriptor for each bundle
-* `mangen.obr.import.<obr-ver>` - the template used to produce the descriptor text for each import.
-* `mangen.obr.export.<obr-ver>` - the template used to produce the descriptor text for each export.
-* `mangen.obr.import.ver.<obr-ver>` - the template used to produce a "version" descriptor for an import which has an explicit version specified.
-* `mangen.obr.export.ver.<obr-ver>` - the template used to produce a "version" descriptor for an export which has an explicit version specified.
-
-The templates include a simple "tag substitution" mechanism that will expand the following tags:
-
-* `@@hdr:<header-name>@@` - include the attribute value of <header-name>from the bundle's Manifest.
-The `mangen` attributes will be searched first, followed by the Main attributes
-* `@@imports@@` - process the list of imports and generate descriptor text based on the `mangen.obr.import.<obr-ver>` template
-* `@@exports@@` - process the list of exports and generate descriptor text based on the `mangen.obr.export.<obr-ver>` template
-* `@@import-ver@@` - will be expanded using `mangen.obr.import.ver.<obr-ver>` if an explicit version was included for the import package
-* `@@export-ver@@` - will be expanded using `mangen.obr.export.ver.<obr-ver>` if an explicit version was included for the export package
-* `@@pkg:name@@` - name of the import or export package currently being processed
-* `@@pkg:ver@@` - version of the import or export package currently being processed
-
-=== Contents of the distribution file
-
-The current `mangen` distribution includes the following:
-
-* pre-compiled versions of `mangen` and libraries
-* full source code and Ant build files
-* this documentation in HTML format.
-The original documentation is maintained in TWiki format at Ascert's intranet set and a copy of the raw TWiki file is included.
-
-The following third party libraries are also included in the distribution:
-
-* http://incubator.apache.org/felix/[Felix] library JARs - required Felix library JARs, used by `mangen` in Manifest processing, and generation
-* http://asm.objectweb.org/[ASM] - the ASM java bytecode parsing toolkit used by the `ASMClassScanner` class scanning implementation.
-* http://jakarta.apache.org/bcel/[BCEL] - the BCEL java bytecode parsing toolkit used by the `BCELScanner` class scanning implementation.
-
-Thanks also go to the following contributors:
-
-* link:{{ refs.mailto-heavy-ungoverned-org.path }}[Richard S. Hall] - both for his assistance in the development and testing of `mangen` and for his contribution of the ASM based class scanning implementation.
-
-== Extending `mangen`
-
-First things first.
-You need to be a reasonably proficient Java developer to undertake extending `mangen`.
-If you're not, then you should consider a Java programming course or tutorial of some kind.
-
-Extensions to `mangen` can be performed in the following ways:
-
-* creating new or enhanced Rules
-* creating new or enhanced Reports
-* supporting alternative class scanning implementations
-* Modifying the core source code
-
-The idea is that as `mangen` matures most extension cases will be possible via the first two means, with new class scanners and core modifications being the exception.
-
-For detailed information, Javadoc API documentation for `mangen` can be found @@api-index-loc@@.
-
-=== Creating new Rule types
-
-A rule type is in fact just a Java class which implements the `com.ascert.openosgi.Rule` interface.
-If no package name is specified, these will be assumed to be in the `com.ascert.openosgi.mangen.rules` package.
-Although somewhat less readable, a fully-qualified class name can be supplied for rule types in other packages.
-
-At present, the simplest way to learn about creating new rules is to look at the source code for existing rules to understand how they're put together and what can be done in them.
-
-=== Creating new Report types
-
-Reports are similar to rules.
-A Report type is a Java class which implements the `com.ascert.openosgi.Report` interface.
-Unqualified report types will be assumed to be in `com.ascert.openosgi.mangen.reports` package, with the option to use fully-qualified class names if desired.
-
-As with rules, the source code for the existing reports is the best place to learn about creating new reports.
-
-=== Alternative class scanners
-
-To parse the class files of an application `mangen` needs a class file bytecode scanning library.
-So that alternative scanning tools may be used `mangen` does not make direct usage of any library implementation.
-Instead a wrapper class is used which implements the `ClassScanner` interface, and hence insulates `mangen` from the specific details of different bytecode scanning tools.
-The `mangen.scanner.class` property can be used to control which scanner implementation class is used.
-
-[cols=2*]
-|===
-| At present, implementations of the `ClassScanner` interface have been include for the ObjectWeb http://asm.objectweb.org/[ASM] toolkit and the [Apache BCEL
-| http://jakarta.apache.org/bcel/] toolkit.
-|===
-
-== Ongoing Development
-
-=== Change Log
-
-==== Version 1.0.1
-
-* Initial version submitted to Felix project.
-* Package names changed and license headers changed to Apache license
-* `OsgiPackage` classes changed to use Felix manifest handling classes.
-* ASM and BCEL sources removed and maven dependencies created to pull these in from repositories.
-* Compiles and builds using normal maven build, but as yet doesn't create a standalone distribution which includes dependent jars and config `.properties` files.
-* No analysis work has been performed to determine enhancements and additional rules desirable to integrate with Felix build and take advantage of `mangen` class scanning.
-
-==== 0.1.x Versions
-
-The 0.1.x versions of `mangen` are the original versions developed to work with Oscar.
-The versions and documentation can still be downloaded from the http://oscar-osgi.sourceforge.net/mangen/[OBR Sourceforge site].
-The change history has been maintained here for completeness.
-
-===== Version 0.1.2
-
-* Inclusion of xref:#_obrreport[ObrReport] for generation of OBR descriptors _[ oscar-osgi-Feature Requests-1221468 ]_
-* Removed "default" processing of JARs.
-Now an explicit xref:#_processbundles[ProcessBundles] must be included to force JAR processing to take place.
-This allows reports, such as the new ObrReport to skip `mangen` import/export processing and just work from existing manifests.
-* default `mangen.properties` now explicitly lists each non java.* package rather than using wildcards, proved safer and more reliable when creating OSGi R4 manifests
-
-===== Version 0.1.1
-
-* Support for errors and warnings to cause non-zero exit status to be returned
-* Fix for occasional failures to update bundle JARs _link:{{ refs.-oscar-osgi-bugs-1218334.path }}[oscar-osgi-Bugs-1218334]_
-
-===== Version 0.1.0
-
-* First version
-* Support for current OSGi Release 3 (R3) manifest headers, and basic support for proposed upcoming R4 headers
-* Processing of JARs and directories containing JARs and parsing of contained classes using a subset of BCEL.
-* Simple but extensible rule based engine for import and export set manipulation.
-* Simple but extensible reporting engine
-* Updating of process bundle JARs via an UpdateBundles rule
-* Pluggable interface to allow alternative class byte code scanners to be used
-
-=== Possible Enhancements
-
-As with any piece of software, there are always more things you'd like to do than time available in which to work on them.
-This library is no exception.
-
-In it's present form it `mangen` is simple, reasonably fast, and usable.
-Ideas on some of the more significant areas where it could be enhanced or improved are described in the sections below.
-
-Most `mangen` enhancement ideas have now been created as issues in the https://issues.apache.org/jira/secure/IssueNavigator.jspa?component=12310910&sorter/field=priority&mode=hide&reset=true&pid=12310100&sorter/order=ASC[Apache JIRA list].
-
-Those which are more speculative have been left below.
-
-==== Online usage within an OSGi environment
-
-[cols=3*]
-|===
-| Extending the concept of Manifest-less usage (no link) comes an interesting possibility that a specific OSGi platform such as [Oscar
-| http://oscar.objectweb.org/] could be extended to load any JAR and automatically 'fix-up' a usable Manifest.
-This would require internal access/knowledge of the specific platform's implementation since the existing standard OSGi API would not supply sufficient details and access to the set of loaded bundle JARs.
-Additionally, it would probably need to be a "multi-step" process since until a largely complete set of bundle JARs were loaded it may not be possible to resolve all imports and exports.
-This perhaps implies some form of platform extension to allow a set of JARs to be passed to some form of "pre-load" mechanism capable of resolving their imports and exports within the JAR set, and possibly from existing loaded bundle JARs or even an external [OBR
-| http://oscar-osgi.sourceforge.net/].
-|===
-
-== Acknowledgements
-
-Ascert is pleased to acknowledge the following projects, organisations and individuals whose tools have been used in the creation of this software:
-
-* http://asm.objectweb.org/[ASM] - ObjectWeb's bytecode scanning and manipulation toolkit.
-* http://jakarta.apache.org/bcel/[BCEL] - Apache's bytecode scanning and manipulation toolkit.
-* http://www.jedit.org[jEdit] - home of the powerful and flexible jEdit editor
-* http://ant.apache.org[Ant] - home of the Apache Ant build tool
-* {blank}
-+
-[cols=2*]
-|===
-| http://www.bluemarsh.com/[Blue Marsh Softworks] - authors of the excellent [JSwat
-| http://www.bluemarsh.com/java/jswat/index.html] Java debugger.
-|===
-
-* {blank}
-+
-[cols=3*]
-|===
-| http://subversion.tigris.org/[Subversion] - home of the Subversion (aka SVN) version control system, and [Regnis
-| http://www.regnis.de/] and [TortoiseSVN
-| http://tortoisesvn.tigris.org/], both of which are excellent SVN GUI clients
-|===
-
-* http://java.sun.com[Sun Java] - home of all things Java and a place we love.
[felix-antora-site] 06/18: remove jaas doc (unmaintained)
Posted by dj...@apache.org.
This is an automated email from the ASF dual-hosted git repository.
djencks pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/felix-antora-site.git
commit 9daa925d45310faaa1c6fecd4178c28575b05b01
Author: David Jencks <dj...@apache.org>
AuthorDate: Sun Jul 11 15:41:23 2021 -0700
remove jaas doc (unmaintained)
---
modules/ROOT/pages/documentation/subprojects.adoc | 2 +-
.../subprojects/apache-felix-jaas.adoc | 315 ---------------------
2 files changed, 1 insertion(+), 316 deletions(-)
diff --git a/modules/ROOT/pages/documentation/subprojects.adoc b/modules/ROOT/pages/documentation/subprojects.adoc
index ba582b2..a05e913 100644
--- a/modules/ROOT/pages/documentation/subprojects.adoc
+++ b/modules/ROOT/pages/documentation/subprojects.adoc
@@ -118,7 +118,7 @@ The last documentation may be found in the https://github.com/apache/felix-site-
* https://github.com/apache/felix-site-pub/blob/last-cms/documentation/subprojects/apache-felix-commons.html[Commons]
* https://github.com/apache/felix-site-pub/blob/last-cms/documentation/subprojects/apache-felix-deployment-admin.html[Deployment Admin]
* https://github.com/apache/felix-site-pub/blob/last-cms/documentation/subprojects/apache-felix-ipojo.html[iPOJO]
-* xref:documentation/subprojects/apache-felix-jaas.adoc[JAAS Support]
+* https://github.com/apache/felix-site-pub/blob/last-cms/documentation/subprojects/apache-felix-jaas.html[JAAS Support]
* xref:documentation/subprojects/apache-felix-lightweight-http-service.adoc[Lightweight HTTP Service]
* xref:documentation/subprojects/apache-felix-manifest-generator-mangen.adoc[Manifest Generator (mangen)]
* xref:documentation/subprojects/apache-felix-maven-obr-plugin.adoc[Maven OBR Plugin]
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-jaas.adoc b/modules/ROOT/pages/documentation/subprojects/apache-felix-jaas.adoc
deleted file mode 100644
index fbf628f..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-jaas.adoc
+++ /dev/null
@@ -1,315 +0,0 @@
-= Apache Felix JAAS Support
-
-
-
-Apache Felix JAAS support aims to simplify usage of JAAS in OSGi.
-
-It supports following features
-
-. It can work both in Standalone and AppServer deployments i.e.
-in those environment where global JAAS configuration might be used by other applications and our usage of JAAS should not affect them
-. It enables usage of OSGi Configuration support to dynamically configure the login modules.
-. It allows LoginModule instances to be created via factories registered in OSGi Service Registry
-. It does not require the client to depend on any OSGi API
-. It works well with the dynamic nature of the OSGi env
-. Implementation depends only on Core OSGi API and ConfigAdmin (RFC 104)
-
-== The Problem
-
-The basic problem when using JAAS in OSGi is that it creates the LoginModule instance using reflection.
-This poses problem in OSGi env as the client bundle does not have the visibility of all the required LoginModule classes.
-
-A typical use of JAAS login looks like below
-
-[source,java]
- // let the LoginContext instantiate a new Subject
- LoginContext lc = new LoginContext("myApp");
- lc.login();
-
-In this mode the `LoginContext` would access the global JAAS `Configuration` internally via `Configuration.getConfiguration()`.
-It would then instantiate the LoginModule instance based on the configuration value.
-It uses the Thread Context ClassLoader (TCCL) to create the instance.
-This approach fails to work when used in OSGi
-
-. The Thread Context ClassLoader is not defined in general in an OSGi context.
-It can and has to be set by the caller and OSGi cannot generally enforce that.
-. Instantiating a LoginModule generally requires access to internal implementation classes, by exporting these classes an implementing bundle would break its encapsulation.
-. Even if an implementation class was exported, importing this class in a consumer bundle would bind it to the specific implementation package provided, which violates the principle of loose coupling.
-
-== Usage
-
-The JAAS support involves following parts
-
-. LoginModule Registration - Mechanism by which LoginModule is registered with a given `realm`.
-. LoginContext Creation - Refers to the client code which constructs the LoginContext and then perform login operation
-
-In section below we would first provide details on various ways by which a `LoginModule` would be configured so that it can participate in JAAS flow and then about various ways in which the client code can invoke the JAAS logic
-
-=== LoginModule registration
-
-The login modules can be registered via two mechanism
-
-* OSGi Configuration - LoginModule are registered via OSGi configuration
-* LoginModuleFactory - LoginModule are registered with the OSGi ServiceRegistry via `LoginModuleFactory`
-
-==== A - OSGi Configuration
-
-LoginModules can also be configured via configuration which is somewhat similar to the file based configuration.
-It consist of two parts
-
-* Information around which bundle provides a specific LoginModule module
-* Configuration required to be passed to that LoginModule
-
-===== Manifest Header Entry
-
-Any bundle which provides a LoginModule class needs to provide this information via _Jaas-ModuleClass_ manifest header.
-[source,xml]
- <Jaas-ModuleClass>org.apache.felix.example.jaas.config.internal.SampleConfigLoginModule</Jaas-ModuleClass>
-
-===== Configuration
-
-JAAS module depends on OSGi Configuration for managing the LoginModule configuration.
-The configuration factory PID is `org.apache.felix.jaas.Configuration.factory`.It provides the required metatype descriptor thus enabling configuration via "Configuration" tab of Felix WebConsole
-
-image::documentation/subprojects/jaas-config.png[]
-
-Configuration properties
-
-* `jaas.classname` - Fully qualified name of the LoginModule class
-* `jaas.controlFlag` - LoginControlFlag to use like required, optional, requisite, sufficient.
-Default is set to required
-* `jaas.realmName` - JAAS Realm name.
-If specified then LoginModule would be registered against given realm otherwise it is bound to a 'other' realm
-* `jaas.ranking` - Ranking for the LoginModule.
-It would be used to order the various login modules.
-The entries are sorted in a descending order (i.e.
-higher value ranked configurations come first)
-
-For an example refer to http://svn.apache.org/repos/asf/felix/trunk/examples/jaas/launcher/src/main/config/org.apache.felix.jaas.Configuration.factory-simple.cfg[Sample Configuration].
-It configures a SampleConfigLoginModule for `sample` realm
-
-==== B - LoginModuleFactory
-
-Any bundle which want to provide a LoginModule implementation would need to provide a factory service which implements the http://svn.apache.org/repos/asf/felix/trunk/jaas/src/main/java/org/apache/felix/jaas/LoginModuleFactory.java[LoginModuleFactory] interface.
-The factory needs to be registeredwith following optional properties
-
-* `jaas.controlFlag` - LoginControlFlag to use like required, optional, requisite, sufficient.
-Default is set to required
-* `jaas.realmName` - JAAS Realm name.
-If specified then LoginModule would be registered against given realm otherwise it is bound to a 'other' realm.
-* `service.ranking` - Ranking for the LoginModule.
-It would be used to order the various login modules.
-
-Interface
-
-[source,java]
-----
-/**
- * A factory for creating {@link LoginModule} instances.
- */
-public interface LoginModuleFactory
-{
- /**
- * Property name specifying whether or not a <code>LoginModule</code> is
- * REQUIRED, REQUISITE, SUFFICIENT or OPTIONAL. Refer to {@link javax.security.auth.login.Configuration}
- * for more details around the meaning of these flags
- *
- * By default the value is set to REQUIRED
- */
- String JAAS_CONTROL_FLAG = "jaas.controlFlag";
-
- /**
- * Property name specifying the Realm name (or application name) against which the
- * LoginModule would be registered.
- *
- * <p>If no realm name is provided then LoginModule would registered with a default realm
- * as configured
- */
- String JAAS_REALM_NAME = "jaas.realmName";
-
- /**
- * Creates the LoginModule instance
- * @return loginModule instance
- */
- LoginModule createLoginModule();
-}
-----
-
-Refer to http://svn.apache.org/repos/asf/felix/trunk/examples/jaas/lm-jdbc/src/main/java/org/apache/felix/example/jaas/jdbc/JdbcLoginModuleFactory.java[JdbcLoginModuleFactory] for one example of its usage.
-It constructs a JdbcLoginModule based on the configuration and passes on the datasource.
-
-=== LoginContext creation patterns
-
-There are various ways through which a JAAS Client can invoke the JAAS login.
-
-==== LoginContextFactory Mode
-
-In this mode the client logic obtains a reference to the `org.apache.felix.jaas.LoginContextFactory` service and then creates a `LoginContext` instance
-
- :java
- LoginContextFactory loginContextFactory = ...
- CallbackHandler handler = ...;
- Subject subject = new Subject();
- try
- {
- LoginContext lc = loginContextFactory.createLoginContext("sample",subject,handler);
- lc.login();
- ...
- }
- catch (LoginException e)
- {
- handleAuthenticationFailure(e);
- }
-
-Refer to http://svn.apache.org/repos/asf/felix/trunk/examples/jaas/app/src/main/java/org/apache/felix/example/jaas/app/internal/FactoryDemoServlet.java[FactoryDemoServlet] for an example.
-Following points to be noted for this usage pattern
-
-* Client code needs to depend on Apache Felix JAAS Support API
-* No need to manage Thread Context Classloader while invoking `LoginContext`
-* No need to import LoginModule related packages
-
-==== Configuration SPI with Default Policy Mode
-
-In this mode the client logic explicitly fetch the JAAS Configuration and then pass it on to the LoginContext.
-In this mode the <<configuration-spi,JAAS Configuration Policy>> is set to `Default`.
-
-[source,java]
-----
-CallbackHandler handler = ...;
-
-Subject subject = new Subject();
-final ClassLoader cl = Thread.currentThread().getContextClassLoader();
-try
-{
- Configuration config = Configuration.getInstance(
- 'JavaLoginConfig', //Algorithm name
- null, //Extra params to be passed. For this impl its null
- 'FelixJaasProvider' //Name of the config provider
- );
- Thread.currentThread().setContextClassLoader(getClass().getClassLoader());
- LoginContext lc = new LoginContext("sample", subject, handler, config);
- lc.login();
-
- ...
-}
-finally
-{
- Thread.currentThread().setContextClassLoader(cl);
-}
-----
-
-In above flow the `Configuration` instance is explicitly fetched and passed on to the
-
-Refer to http://svn.apache.org/repos/asf/felix/trunk/examples/jaas/app/src/main/java/org/apache/felix/example/jaas/app/internal/TCCLDemoServlet.java[TCCLDemoServlet] for an example.
-Following points to be noted for this usage pattern
-
-* Client code needs to be aware of the name of the config provider.
-* Client bundle would need to have an import for package `org.apache.felix.jaas.boot`.
-Refer to <<boot-classpath,Boot classpath>> section for more details
-* Global configuration is not modified so other users of JAAS are not affected
-
-==== Replace Global Configuration Mode
-
-In this mode the JAAS bundle would replace the Global configuration through Configuration.setConfiguration call.
-In this mode the client code would use the normal LoginContext creation and the <<configuration-spi,JAAS Configuration Policy>> is set to `Replace Global Configuration`.
-
-[source,java]
-----
-final ClassLoader cl = Thread.currentThread().getContextClassLoader();
-try
-{
- Thread.currentThread().setContextClassLoader(getClass().getClassLoader());
-
- // let the LoginContext instantiate a new Subject
- LoginContext lc = new LoginContext("appName");
- lc.login();
-}
-finally
-{
- Thread.currentThread().setContextClassLoader(cl);
-}
-----
-
-Following points need to be considered this mode
-
-* Client code is not aware of the provider name
-* Client bundle would need to have an import for package `org.apache.felix.jaas.boot`.
-Refer to <<boot-classpath,Boot classpath>> section for more details
-* Global configuration is modified.
-So it might cause issue while running in co deployed scenarios like Application Server.
-
-Refer to http://svn.apache.org/repos/asf/felix/trunk/examples/jaas/app/src/main/java/org/apache/felix/example/jaas/app/internal/GlobalConfigDemoServlet.java[GlobalConfigDemoServlet] for an example
-
-[[boot-classpath]]
-==== Modified Boot Classpath Mode
-
-In previous modes (except the LoginContextFactory mode) the client code needs to switch the Thread Context Classloader (TCCL).
-This is due the way JAAS logic instantiates the `LoginModule`.
-The Felix JAAS Support provides a `ProxyLoginModule` which takes care of routing the LoginModule calls properly.
-However for this class to be visible to JAAS logic one of the two approaches can be used
-
-*Manage TCCL Explicitly*
-
-The client bundle would need to
-
-. Have an explicit import for `org.apache.felix.jaas.boot` package and
-. Manage TCCL explicitly which making JAAS related calls.
-
- [source,java]
- final Thread current = Thread.currentThread();
- final ClassLoader orig = current.getContextClassLoader();
- try {
- current.setContextClassLoader(getClass().getClassLoader());
- loginContext = new LoginContext(appName, subject,callbackHandler, config);
- } finally{
- current.setContextClassLoader(orig);
- }
-
-Note that in above flow the TCCL is managed explicitly
-
-*Modify Boot Classpath*
-
-Another way would involve modifying the boot classpath.
-
-. Place the `org.apache.felix.jaas-xxx-boot.jar` in the boot classpath via `-Xbootclasspath:bootclasspath` option
-. Make the `org.apache.felix.jaas.boot` part of boot delegation list
-
- [source,java]
- LoginContext lc = new LoginContext("sample", subject, handler);
- lc.login();
-
-Note that in above code we do not have to manage TCCL and neither add an import to `org.apache.felix.jaas.boot` package
-
-Refer to http://svn.apache.org/repos/asf/felix/trunk/examples/jaas/app/src/main/java/org/apache/felix/example/jaas/app/internal/BootClasspathDemoServlet.java[BootClasspathDemoServlet] for code sample
-
-[[configuration-spi]]
-=== JAAS Configuration SPI Settings
-
-There are various ways in which LoginContext can be created depending on the usage mode.
-The JAAS support exposes following properties
-
-image::documentation/subprojects/jaas-spi-config.png[]
-
-* `Default JAAS Realm` - Name of the realm to use in case a LoginModule does not provide an explicit realmName.
-This is useful for single application mode where all LoginModule in an OSGi container are to be used.
-Usage of realm help in global settings because same config file is used to capture settings for all applications running on same JVM
-* `JAAS Config Provider name` - Name against which the Configuration SPI provider should register
-* `Configuration Policy` - This would be explained in next section
- ** `Default` - Global configuration is not touched.
-Client code are expected to use the Configuration Spi mode
- ** `Replace Global Configuration` - In this the global configuration is replaced with OSGi configuration.
-Client code need not perform any special configuration handling.
-At most they need to switch the Thread Context Classloader
- ** `Proxy Global Configuration` - Similar to previous one but it saves the default configuration and does a fallback check on that also.
-This should minimize any disruption in shared mode
-
-== WebConsole Plugin
-
-The runtime JAAS realm is exposed via a WebConsole Plugin.
-
-image::documentation/subprojects/jaas-plugin.png[]
-
-== Resources
-
-. http://docs.oracle.com/javase/1.5.0/docs/guide/security/jaas/JAASRefGuide.html[Java JAAS Reference Guide]
-. http://docs.oracle.com/javase/1.5.0/docs/guide/security/jaas/tutorials/LoginConfigFile.html[JAAS Login Configuration File]
[felix-antora-site] 05/18: remove ipojo doc (unmaintained)
Posted by dj...@apache.org.
This is an automated email from the ASF dual-hosted git repository.
djencks pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/felix-antora-site.git
commit 59ddb56a6e0c064d6c01ba2b5625c1d3f61d98cf
Author: David Jencks <dj...@apache.org>
AuthorDate: Sun Jul 11 15:40:09 2021 -0700
remove ipojo doc (unmaintained)
---
modules/ROOT/pages/documentation/subprojects.adoc | 5 +-
.../subprojects/apache-felix-ipojo.adoc | 50 --
.../dive-into-the-ipojo-manipulation-depths.adoc | 244 -----
.../how-to-use-ipojo-manipulation-metadata.adoc | 85 --
.../how-to-write-your-own-handler.adoc | 985 ---------------------
.../apache-felix-ipojo-eclipse-integration.adoc | 72 --
.../apache-felix-ipojo-feature-overview.adoc | 51 --
.../apache-felix-ipojo-dosgi.adoc | 161 ----
.../how-to-use-ipojo-annotations.adoc | 377 --------
.../ipojo-advanced-tutorial.adoc | 602 -------------
.../ipojo-composition-tutorial.adoc | 620 -------------
.../ipojo-hello-word-maven-based-tutorial.adoc | 547 ------------
.../ipojo-in-10-minutes.adoc | 609 -------------
.../apache-felix-ipojo-junit4osgi.adoc | 30 -
...apache-felix-ipojo-junit4osgi-architecture.adoc | 43 -
.../apache-felix-ipojo-junit4osgi-maven.adoc | 225 -----
.../apache-felix-ipojo-junit4osgi-methods.adoc | 84 --
.../apache-felix-ipojo-junit4osgi-tutorial.adoc | 345 --------
.../apache-felix-ipojo-keypoints.adoc | 70 --
.../apache-felix-ipojo-successstories.adoc | 69 --
.../apache-felix-ipojo-supportedosgi.adoc | 53 --
.../apache-felix-ipojo-supportedvms.adoc | 74 --
.../apache-felix-ipojo-testing-components.adoc | 104 ---
.../apache-felix-ipojo-online-manipulator.adoc | 61 --
.../apache-felix-ipojo-tools/ipojo-ant-task.adoc | 129 ---
.../ipojo-arch-command.adoc | 179 ----
.../ipojo-karaf-feature.adoc | 24 -
.../ipojo-maven-plug-in.adoc | 241 -----
.../ipojo-webconsole-plugin.adoc | 73 --
.../apache-felix-ipojo-tools/junit4osgi.adoc | 219 -----
.../apache-felix-ipojo-api.adoc | 375 --------
.../apache-felix-ipojo-instances.adoc | 427 ---------
.../describing-components.adoc | 34 -
.../describing-components/Callback.jpeg | Bin 9842 -> 0 bytes
.../architecture-handler.adoc | 65 --
.../configuration-handler.adoc | 181 ----
.../controller-lifecycle-handler.adoc | 61 --
.../event-admin-handlers.adoc | 345 --------
.../extender-pattern-handler.adoc | 148 ----
.../injecting-bundle-context.adoc | 72 --
.../describing-components/ipojo-jmx-handler.adoc | 291 ------
.../lifecycle-callback-handler.adoc | 168 ----
.../providing-osgi-services.adoc | 435 ---------
.../service-requirement-handler.adoc | 867 ------------------
.../temporal-service-dependency.adoc | 187 ----
.../white-board-pattern-handler.adoc | 159 ----
.../instance-vs-service-controller.adoc | 84 --
.../ipojo-advanced-topics.adoc | 9 -
.../combining-ipojo-and-configuration-admin.adoc | 306 -------
...tructing-pojo-objects-with-factory-methods.adoc | 42 -
.../how-to-use-ipojo-factories.adoc | 298 -------
.../ipojo-extender-configuration.adoc | 145 ---
.../ipojo-factory-service.adoc | 169 ----
.../ipojo-hierarchical-composition-overview.adoc | 313 -------
.../service-binding-interceptors.adoc | 241 -----
.../using-ipojo-introspection-api.adoc | 274 ------
.../ipojo-advanced-topics/using-stereotypes.adoc | 94 --
.../apache-felix-ipojo-userguide/ipojo-faq.adoc | 431 ---------
.../using-xml-schemas.adoc | 68 --
.../apache-felix-ipojo-why-choose-ipojo.adoc | 107 ---
.../articles-and-presentations.adoc | 18 -
.../developing-camel-mediators-with-ipojo.adoc | 164 ----
.../subprojects/apache-felix-ipojo/download.adoc | 118 ---
.../subprojects/apache-felix-ipojo/ipojo-news.adoc | 89 --
.../apache-felix-ipojo/ipojo-reference-card.adoc | 904 -------------------
.../apache-felix-ipojo/ipojo-support.adoc | 29 -
.../apache-felix-ipojo/related-works.adoc | 18 -
67 files changed, 1 insertion(+), 14166 deletions(-)
diff --git a/modules/ROOT/pages/documentation/subprojects.adoc b/modules/ROOT/pages/documentation/subprojects.adoc
index ec0e33e..ba582b2 100644
--- a/modules/ROOT/pages/documentation/subprojects.adoc
+++ b/modules/ROOT/pages/documentation/subprojects.adoc
@@ -64,10 +64,6 @@ If this project is not using Maven, refer to the docs for the subproject on how
| A simple and extensible framework to retrieve inventory information about applications running in an OSGi Framework.
| https://github.com/apache/felix-dev/tree/master/inventory[source]
-| xref:documentation/subprojects/apache-felix-ipojo.adoc[iPOJO]
-| A sophisticated service-oriented component model to simplify OSGi-based development.
-| https://github.com/apache/felix-dev/tree/master/ipojo[source]
-
| xref:documentation/subprojects/apache-felix-log.adoc[Log]
| A simple, memory-based implementation of the OSGi Log service specification.
| https://github.com/apache/felix-dev/tree/master/log[source]
@@ -121,6 +117,7 @@ The last documentation may be found in the https://github.com/apache/felix-site-
* https://github.com/apache/felix-site-pub/blob/last-cms/documentation/subprojects/apache-felix-autoconf.html[Auto Configuration]
* https://github.com/apache/felix-site-pub/blob/last-cms/documentation/subprojects/apache-felix-commons.html[Commons]
* https://github.com/apache/felix-site-pub/blob/last-cms/documentation/subprojects/apache-felix-deployment-admin.html[Deployment Admin]
+* https://github.com/apache/felix-site-pub/blob/last-cms/documentation/subprojects/apache-felix-ipojo.html[iPOJO]
* xref:documentation/subprojects/apache-felix-jaas.adoc[JAAS Support]
* xref:documentation/subprojects/apache-felix-lightweight-http-service.adoc[Lightweight HTTP Service]
* xref:documentation/subprojects/apache-felix-manifest-generator-mangen.adoc[Manifest Generator (mangen)]
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo.adoc b/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo.adoc
deleted file mode 100644
index 78885fe..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo.adoc
+++ /dev/null
@@ -1,50 +0,0 @@
-= Apache Felix iPOJO
-
-image::/ipojo/ipojo-logo-150.png[]
-
-current iPOJO release: {{ipojo.release}}
-current iPOJO snapshot: {{ipojo.snapshot}}
-
-== What's iPOJO ?
-
-*iPOJO* is a _service component runtime_ aiming to simplify OSGi application development.
-It natively supports *ALL* the dynamism of OSGi.
-iPOJO is made to run modern applications exhibiting modularity and requiring runtime adaption and autonomic behavior.</p> image:/ipojo/cubes.png[]
-
-== Main features
-
-* __ Components are developed as POJOs - no dependencies or complex API
-* __ Use annotations, XML or a fluent API to declare your components and instances
-* __ Require and provide services without requiring code, while being amazingly powerful
-* __ iPOJO applications are natively resilient to dynamism
-* __ Extensible and customizable, develop your own component model
-* __ iPOJO applications are supporting dynamic adaptation, and exhibit autonomic behavior
-
-== Why choose iPOJO
-
-* xref:documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-successstories.adoc#schneider[iPOJO at Schneider Electric]
-* xref:documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-successstories.adoc#ugasp[iPOJO at Ubidreams]
-* xref:documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-successstories.adoc[others success stories]
-* xref:documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-keypoints.adoc[iPOJO Key points]
-* xref:documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-why-choose-ipojo.adoc[Why choose iPOJO]
-
-== Getting started
-
-* __ http://repo1.maven.org/maven2/org/apache/felix/org.apache.felix.ipojo.distribution.quickstart/{{ipojo.release}}/org.apache.felix.ipojo.distribution.quickstart-{{ipojo.release}}.zip[Quickstart Distribution]
-* xref:documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/ipojo-in-10-minutes.adoc[iPOJO in 10 minutes]
-* xref:documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/how-to-use-ipojo-annotations.adoc[Using Annotations]
-* xref:documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/ipojo-hello-word-maven-based-tutorial.adoc[Maven tutorial]
-* xref:documentation/subprojects/apache-felix-ipojo/ipojo-support.adoc[Support]
-
-== The developer corner
-
-* xref:documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components.adoc[Describing components]
-* xref:documentation/subprojects/apache-felix-ipojo/ipojo-reference-card.adoc[iPOJO Reference Card]
-* xref:documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-eclipse-integration.adoc[Eclipse Integration]
-* xref:documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-tools/apache-felix-ipojo-online-manipulator.adoc[Online Manipulator]
-* xref:documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/ipojo-faq.adoc[FAQ]
-
-'''
-
-== News {{ refs.ipojo-news.headers.excerpt|markdown }}
-__ [all news\...]({{ refs.ipojo-news.path }})
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-devguide/dive-into-the-ipojo-manipulation-depths.adoc b/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-devguide/dive-into-the-ipojo-manipulation-depths.adoc
deleted file mode 100644
index f6ffd79..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-devguide/dive-into-the-ipojo-manipulation-depths.adoc
+++ /dev/null
@@ -1,244 +0,0 @@
-= Dive into the iPOJO Manipulation depths
-
-iPOJO (primitive) components are managed using byte code manipulation.
-Don't be afraid, you don't have to be fluent in byte code to understand components.
-This page explains how the manipulation works and how your class file is transformed.
-This manipulation takes care to *NOT* change the behavior of the manipulated class.
-
-
-
-== Why manipulate bundle byte code?
-
-The iPOJO byte code manipulation goals are two-fold:
-
-* Preparing classes to be managed at run time and
-* Translating XML or annotation metadata into an internal format to avoid run-time XML and annotation parsing.
-
-image::documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-devguide/process.png[]
-
-[cols=2*]
-|===
-| iPOJO follows a container approach and more specially employs http://en.wikipedia.org/wiki/Inversion_of_control[inversion of control] and [dependency injections
-| http://en.wikipedia.org/wiki/Dependency_injection].
-The iPOJO container manages component instantiation and injection (service, properties and so on...).
-To inject values and supervise the execution inside component implementation class, iPOJO uses an interception and injection framework.
-To facilitate this, iPOJO uses class byte code manipulation.
-|===
-
-image::documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-devguide/injection.png[]
-
-Besides manipulating byte code, iPOJO translates the XML or annotation metadata to an internal syntax.
-This eliminates any run-time dependencies on the particular metadata format.
-
-== How bundle byte code is manipulated
-
-For each class used as a component implementation class, the manipulation process prepares the class to be managed at run time.
-This means providing the ability to intercept methods and field accesses.
-This manipulation is independent of the component metadata.
-A component class will always result in the same final manipulated class, regardless of its metadata.
-This means it is possible to use a class as the implementation of several component types.
-As illustrated in the following image, the manipulated class instance interacts with an instance manager that delegates to handlers.
-The metadata impacts the set of handlers;
-it does not impact the manipulated class, nor the instance manager (which is the iPOJO container foundation).
-
-image::documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-devguide/principles.png[]
-
-The following image explains what happens during the manipulation.
-
-image::documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-devguide/manipulation.png[]
-
-First, each manipulated class implements the `POJO` interface.
-This interface introduces a method to get a reference to the instance container.
-So, you can detect whether an object is managed by iPOJO by checking if the object implements this interface.
-A special field, named `\*\*IM` is injected, which contains a reference to the instance container object (`InstanceManager` at run time.
-
-For each field, getter and setter methods are generated.
-They are called `\*\*get$FIELD*NAME` and `\*\*set$FIELD*NAME`.
-A boolean field is injected named `\*\*F$FIELD_NAME`.
-This flag enables or disables the container delegation for this field.
-When delegation is disabled, the field is managed as a regular field: getter and setter methods just return and set the field value.
-When delegation is enabled, the field never receives a value, the container stores the field value.
-The getter method asks the container to get the value.
-The setter method asks to the container to update the stored value.
-All the field accesses (except ones from specific constructors) of the class are adapted to call the getter or the setter method.
-
-In order to intercept methods, each method is substituted by a generated method.
-Each method is renamed to `\*\*METHOD_NAME` and becomes private.
-The original method is replaced by iPOJO code.
-This code allows method interception.
-As with fields, method delegation is enabled or disabled by an injected boolean field.
-If the method is not to be intercepted, the iPOJO-generated method just calls the original method.
-Otherwise, the iPOJO-generated method notifies the container of method entries, exits, and potential errors.
-
-Finally, the constructors are also manipulated.
-Empty constructors and constructors receiving a `BundleContext` object are manipulated as others methods.
-However, they receive another argument: the `InstanceManager`.
-This instance manager is set just after the call to the super constructor.
-While setting the instance manager, all flags enabling/disabling delegation are set.
-This allows the component to use injected values inside the constructor code itself.
-Constructors receiving other kind of arguments are not manipulated, and so can be used to create non-managed instance.
-In this case, fields won't be delegated, and methods won't be intercepted.
-
-=== The annotation special case
-
-The manipulation has a special behavior when a visible (at run time) method or constructor annotation is detected.
-As the methods are replaced by private methods, the annotations are moved to the iPOJO-generated methods, such as in:
-
-[source,java]
- public class MyClass {
- @MyAnnotation
- public void myMethod() {
- //my code here
- }
- }
-
-is transformed into:
-
-[source,java]
- public class MyClass {
- @MyAnnotation
- public void myMethod() {
- // iPojo code here
- }
- private void _myMethod() {
- // my code here
- }
-
-== Avoiding XML at run time
-
-iPOJO does not use XML or annotations at run time.
-The manipulation process replaces the XML or annotation metadata by an internal format (between LISP and XML).
-The XML or annotation metadata are translated and written into the bundle manifest.
-Additionally, various type information in the component metadata is computed during the byte code manipulation phase to avoid having to use reflection at run time (which would require loading the class) to get class elements (such as available fields, methods, implemented interfaces, and so on).
-
-If you want to see how XML or annotation metadata are _tortured_, just open the manifest file of a manipulated bundle, and look at the `iPOJO-COMPONENTS` entry (and appreciate the Lisp-like syntax :-))...
-
-== Extending manipulator
-
-Annotations are more and more used to provide a simple and elegant programming model.
-iPOJO had supported generic annotations (`@Component`, `@Handler`, ...) for a long time.
-But supporting your own annotations and bind them to a particular handler in iPOJO was awkward (naming conventions, id and parent resolution, ...).
-
-For example, how to re-use an external annotation (let's say `@javax.inject.Inject`) that do not respect the iPOJO naming convention ?
-Or how can you contribute information to the component's metadata when an annotation is found ?
-
-The solution is to extend the manipulator with new annotation' support.
-
-=== Annotation Binding Module
-
-That can be done through the implementation of a `Module`:
-
-[source,java]
-----
-import org.apache.felix.ipojo.manipulator.spi.AbsBindingModule;
-import org.apache.felix.ipojo.manipulator.spi.AnnotationVisitorFactory;
-import org.apache.felix.ipojo.manipulator.spi.BindingContext;
-import org.objectweb.asm.AnnotationVisitor;
-
-public class SampleBindingModule extends AbsBindingModule {
-
- public void configure() {
- // When @Hello is found, execute the provided AnnotationVisitor
- bind(Hello.class)
- .to(new AnnotationVisitorFactory() {
- public AnnotationVisitor newAnnotationVisitor(BindingContext context) {
- return new HelloVisitor(context.getWorkbench());
- }
- });
- }
-}
-----
-
-The `AbsBindingModule.configure()` method has to be implemented by each new Module.
-It contains the annotation binding specification(s).
-An annotation binding simply declares what to do when a given annotation is found.
-
-In the example case, when the `@Hello` annotation is encountered in a class' bytecode, the manipulator will find an annotation binding for `@Hello` and call it's `AnnotationVisitorFactory.newAnnotationVisitor()` method to obtain a dedicated `AnnotationVisitor` (here `HelloVisitor`).
-
-=== Visitors
-
-Here are the `@Hello` annotation and `HelloVisitor` class for better understanding:
-
-[source,java]
- @Target(ElementType.TYPE)
- public @interface Hello {
- String name();
- }
-
-The `@Hello` annotation has a mandatory `name` attribute.
-
-[source,java]
-----
-public class HelloVisitor extends EmptyVisitor implements AnnotationVisitor {
-
- private Element hello = new Element("hello", "org.apache.felix.ipojo.sample");
-
- private ComponentWorkbench workbench;
-
- public HelloVisitor(ComponentWorkbench workbench) {
- this.workbench = workbench;
- }
-
- /**
- * Visit @Hello annotation attributes.
- */
- public void visit(String name, Object value) {
- if (name.equals("name")) {
- hello.addAttribute(new Attribute("name", value.toString()));
- return;
- }
- }
-
- /**
- * Append to the "component" element computed attribute.
- */
- public void visitEnd() {
- workbench.getElements().put(hello, null);
- }
-}
-----
-
-The `HelloVisitor` is an ASM `AnnotationVisitor`.
-`AnnotationVisitor.visit(String, Object)` is called for each declared attribute of the annotation.
-Declared means that if an attribute is non-mandatory and was not part of the annotation declaration, it will not be visible by the `AnnotationVisitor`.
-Each attribute is visited only once.
-In HelloVisitor we only react to the `name` attribute, and store its value as an Attribute in the Element.
-
-Finally, in `visitEnd()`, we contribute our Element to the workbench.
-
-=== Declaring the Module
-
-Last work to do: declare the new `Module` in a `META-INF/services/org.apache.felix.ipojo.manipulator.spi.Module` file:
-
-[source,sh]
- org.apache.felix.ipojo.sample.SampleBindingModule
-
-At this point, we can use the jar file that contains the extension within the manipulator.
-In maven, it's as simple as adding a plugin dependency to the `maven-bundle-plugin` (in addition of the `bnd-ipojo-plugin`).
-In ant, It's probably a matter of changing the classpath.
-
-=== Finally
-
-At the end, all this mechanics will help you to simply your code from:
-[source,xml]
- <ipojo xmlns:s="org.apache.felix.ipojo.sample">
- <component ...>
- <s:hello name="Guillaume" />
- </component>
- </ipojo>
-
-with a non-annotated component's class:
-
-[source,java]
- public class MyComponent {
- // ...
- }
-
-to a more elegant (and concise), with no XML:
-
-[source,java]
- @Component
- @Hello(name = "Guillaume")
- public class MyComponent {
- // ...
- }
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-devguide/how-to-use-ipojo-manipulation-metadata.adoc b/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-devguide/how-to-use-ipojo-manipulation-metadata.adoc
deleted file mode 100644
index 533fb80..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-devguide/how-to-use-ipojo-manipulation-metadata.adoc
+++ /dev/null
@@ -1,85 +0,0 @@
-= How to use iPOJO Manipulation Metadata
-
-_During the manipulation process, iPOJO gathers information about the manipulated classes.
-These metadata are stored inside the bundle manifest and are used to avoid reflection on the manipulated class.
-By using these metadata, your handler can check that the implementation class contains required fields, methods, check implemented interfaces._
-
-
-
-== Contained information
-
-Manipulation metadata contains:
-
-* Interfaces implemented by component type implementation
-* Fields of the component type implementation
-* Methods of the component type implementation
-
-Field Metadata contains field name and type.
-Method Metadata contains method name, the sorted list of argument types and return type.
-
-== Building Manipulation Metadata
-
-Manipulation (i.e.
-PojoMetadata) can be obtained form the factory of a (primitive) component type such as in:
-
-[source,java]
- public void configure(InstanceManager im, Element metadata, Dictionary configuration) {
- ...
- PojoMetadata manipulation = getFactory().getPojoMetadata();
- ...
- }
-
-== Getting Metadata
-
-From the manipulation metadata, you can query manipulation information by using following methods:
-
-* `MethodMetadata[] getMethods()` : Get all methods
-* `FieldMetadata[] getFields()` : Get all fields
-* `String[] getInterfaces()` : Get all implemented interfaces
-* `FieldMetadata getField(String name)` : Look for the field with the given name.
-Returns null if not found.
-* `FieldMetadata getField(String name, String type)`: Look for the field with the given name and type.
-Returns null if not found.
-* `boolean isInterfaceImplemented(String itf)` : Is the given interface name implemented by the manipulated class.
-* `MethodMetadata getMethod(String name)` : Look for the method with the given name.
-Returns null if not found.
-Returns the first found if several method match.
-* `MethodMetadata[] getMethods(String name)` : Look for all methods with the given name.
-Returns an empty array if not found.
-* `MethodMetadata getMethod(String name, String[] types)` : Look for the method with the given name and argument type list.
-Returns null if not found.
-
-From a Field Metadata object, you can obtain the field name, type, and 'reflective' type.
-From a Method Metadata object, you can obtain the method name, the argument type array, and the returned type ('void' for void method).
-
-== Creating Callback from Manipulation Metadata
-
-You often need to invoke method on the POJO objects.
-iPOJO provides an helper class, named Callback, allow you to manage this invocation easily.
-You can obtain a Callback object from the Method Metadata.
-By this way, you are sure that the method exists in the implementation.
-To create the callback, use the following code:
-
-[source,java]
- PojoMetadata manip = getFactory().getPojoMetadata();
- MethodMetadata method = manip.getMethod("your_method_name");
- Callback cb = new Callback(method, im);
-
-Then you can directly invoke your method:
-
-[source,java]
- Object[] args = ...; // Build your argument array
- cb.call(args);
- ...
-
-== Types & Reflective Types
-
-When querying field (or a method argument) type, the API returns following code identifiers:
-
-* For primitive types : int, long, short, byte, char, double, float, boolean
-* For primitives type arrays : int[], long[], short[], byte[], char[], double[], float[], boolean[]
-* For object : qualified class name as java.lang.String
-* For object arrays : the qualified class name of the content type followed by [] as java.lang.String[]
-
-Array types are different from Java internal/reflective array types.
-To get the internal/reflective array type for field type you can use the `getReflectiveType` method.
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-devguide/how-to-write-your-own-handler.adoc b/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-devguide/how-to-write-your-own-handler.adoc
deleted file mode 100644
index a7d3192..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-devguide/how-to-write-your-own-handler.adoc
+++ /dev/null
@@ -1,985 +0,0 @@
-= How to write your iPOJO Handler
-
-_This document explains how developers can use iPOJO extensibility mechanism to extend the (primitive) component instance container.
-Such extensibility mechanism does not require to modify the iPOJO core._
-
-
-
-First, iPOJO concepts are briefly explained.
-The second section explains the steps to create a handler.
-The two last sections describes the implementation and the usage of two small example handlers : a Log Handler, logging messages inside the OSGi log service, and a Property Handler, injecting properties values inside fields.
-
-The code is available in this link:{attachmentsdir}/ipojo/ipojo-handler-tutorial-project.zip[archive file].
-
-== iPOJO Concepts
-
-iPOJO is a service oriented component model aiming to simplify OSGi applications development.
-iPOJO is based on the POJO concepts.
-A POJO is a simple Java class without any dependency on its runtime environment.
-In iPOJO, POJO are encapsulated in a container managing the relation between the POJO and the external world.
-This container keeps separated the POJO from the external "wild" world.
-Moreover, this container can be extended, using handlers.
-
-Basically, iPOJO contains two main concepts: component type and component instance.
-A component type is a type of component.
-A component type defines its implementation class, its creation policy, and its container.
-A component instance is a configured instance of a component type.
-This instance is created with the component type factory.
-A component instance inherits of all component type characteristics but has a unique name and its own configuration (set of <key, value>).
-
-Above these concepts, iPOJO runtime will manage component type factories and component instances.
-Each component instance is managed separately (but the factory can delete them).
-
-A component type declares its container configuration.
-Each component instance owns its container conform to the component type container configuration.
-An iPOJO container is composed by an `InstanceManager`, encapsulating the POJO, on which are plugged handlers.
-A handler manages one non functional concern.
-Handlers participate to the component instance lifecycle;
-can interact with the POJO;
-can manage relations with external entity like database, or other POJOs...
-For example, a persistence handler may interact with a database to store and inject POJO state, while an administration handler may use JMX to allow remote configuration of instance properties.
-
-image::documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-devguide/POJO-Container-Handler.png[]
-
-iPOJO is an extensible model allowing developer to manage other non functional concerns.
-Indeed, handlers can be developed singly, without modifying the iPOJO core.
-At runtime, iPOJO looks for each handler needed by a component instance and plugs an instance of each (required) handler on the container.
-So iPOJO containers are flexible, light and adaptable to each component.
-When a needed handler cannot be found, the component instance cannot be created.
-
-An external handler is identified by a namespace.
-This namespace will be used by developers to refer to the external handler (when he configures its component type) and by iPOJO to instantiate the handler object.
-
-iPOJO core contains 6 "core" handlers managing service providing, service dependencies, lifecycle callbacks, lifecycle controller, instance dynamic configuration, and component instance architecture.
-Theses handlers follow the same rules than external handlers, except that they use the iPOJO default namespace (i.e.
-`org.apache.felix.ipojo`).
-
-== Handler development basis
-
-=== Fundamentals
-
-As explain above, the handler interacts with the POJO, with the component's container and with the external world (e.g.
-: other components, services, bundles, the OSGi framework, ...).
-The skeleton of such an agent is defined in iPOJO is defined by the `PrimitiveHandler` (abstract) class that can be found in the `org.apache.felix.ipojo` package.
-
-You need to implement the three basic lifecycle methods of this class, but you can extends this model by redefining some other methods (e.g.
-: to intercept POJO method calls, field accesses, ...).
-
-=== Declaring your handler
-
-You first need to declare your handler, so iPOJO will be able to initialize, configure and use it when needed.
-First, you must give a name and a namespace to your handler.
-By doing that, iPOJO can recognize that a certain component uses your handler, so it can initialize it.
-You need to declare, using the `@Handler` annotations.
-You can, of course, declare several handlers, and even declare components using these handlers, in the same bundle.
-
-[source,java]
- @Handler(name = "Log", namespace = LogHandler.NAMESPACE)
- public class LogHandler extends PrimitiveHandler {
- public static final String NAMESPACE = "org.apache.felix.ipojo.log.handler";
- // ...
- }
-
-Then, you must know that a handler is a component (almost) like standard iPOJO components : it can use other handlers (like core handlers : service requirements, provided services, ...).
-You can consequently describe your handler's required services, provided services, etc.
-
-In order to use iPOJO annotations processing, the namespace must be a valid package name and the name must be a valid annotation name (without the '@').
-Refer to the <<annotations,annotations>> section.
-
-=== Handler lifecycle
-
-A handler lifecycle is composed of four different states.
-
-image::documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-devguide/Handler-Lifecycle.png[]
-
-* First, when iPOJO parses the metadata of a bundle, it detects that a certain component type use your handler (using XML qualified names, see the following _Using your handler_ section).
-When it finds such a reference, it initializes the handler by calling the `initializeComponentFactory()` method.
-This method should be static but actually can't be so for some technical reasons.
-Consequently, a _mock_ instance of the handler is created, the `initializeComponentFactory()` method is called, and this instance is destroyed.
-This method aims to check the validity of the component type description, avoiding starting invalid factories.If you override this method, you should here set up the component description (e.g.
-: common properties, exported services, ...) and check the handler configuration.
-The parameters passed to this method are the `ComponentTypeDescription` and the component's `Metadata` (i.e.
-: the structure of the component type declaration).
-* Once your handler has been initialized, iPOJO configures it for each created instance of the using components.
-The `ComponentTypeDescription` and the instance specific properties are passed to the `configure()` method of your handler.This method is mandatory so you have to implement it.
-Here you should check the handler configuration (if not already done in the `initializeComponentFactory()` method) and configure the handler with given instance specific properties.
-* Then, iPOJO starts the handler, following the component instance lifecycle, by calling the `start()` method.
-You have to put in this method the activation code of your handler.
-A freshly started handler is by default in an active state (if all its used handlers, like required services, are in an active state).
-* Once started, the handler state can be either in a valid or in an invalid state, depending on its used handlers (a handler is an iPOJO component, so it can depend on other handlers, like service dependencies, provided services, ...
-See the _Handler extends Component_ section).
-The validity of your handler depends on used handlers status, but it also can be changed in your handler code by using the `setValidity()` method.
-* Finally, when the component instance is stopped (generally just before being destroyed), the stop method of the handler is called.
-Place here the inactivation code of your handler.
-
-Keep in mind that the `stop()` method of your handler is called when the component instance is stopped (not necessarily destroyed).
-This instance can be restarted later, so the same instance of your handler must have to ability to restart too.
-
-=== Reading handler and instance configurations
-
-Your handler need to read how it is configured in the using component type description.
-The configuration is written in the `metadata.xml` of the using bundle, but is passed to the `initializeComponentFactory()` and `configure()` methods as an `Element` object.
-
-The `Element` type (from the `org.apache.felix.ipojo.metadata package`), coupled with the `Attribute` type, is used to retrieve the structure and the content of the component configuration.
-The `Element` parameter, passed to the initialization and configuration methods, represents the root of the component type description (i.e.
-the root of the tree is the `component` tag).
-
-Several methods allows to browse the entire configuration from the root `Element` :
-
-* The `getElement()` methods let you access the content of an `Element` (i.e.
-the children elements)
-* The `getAttribute()` methods allows you to access the attributes of an `Element`.
-* The `containsElement()` and `containsAttribute()` methods test the presence of a child-element or an attribute in an `Element`.
-
-_Note :_ As described in the <<description,description>> section, a name and a namespace are associated to each handler.
-To safely retrieve the configuration of this handler from the component metadata, you can take inspiration from the following snippet (the `componentMetadata` variable is the component root `Element` passed to the `initializeComponentFactory()` and `configure()` methods) :
-
-[source,java]
- Element[] log_elements = metadata.getElements("log", NAMESPACE);
-
-For example, the log handler provided in the archive file has the following configure method:
-
-[source,java]
-----
-/**
- * Parses the component's metadata to retrieve the log level in which we log messages.
- *
- * @param metadata component's metadata
- * @param configuration instance configuration (unused in this example)
- * @throws ConfigurationException the configuration is inconsistent
- */
-@Override
-public void configure(Element metadata, Dictionary configuration) throws ConfigurationException {
- // First parse the metadata to check if the log handler logLevel
-
- // Get all Namespace:log element from the metadata
- Element[] log_elements = metadata.getElements("log", NAMESPACE);
-
- // If an element match, parse the logLevel attribute of the first found element
- if (log_elements[0].containsAttribute("level")) {
- String l = log_elements[0].getAttribute("level");
- if (l.equalsIgnoreCase("info")) {
- logLevel = LogService.LOG_INFO;
- } else if (l.equalsIgnoreCase("error")) {
- logLevel = LogService.LOG_ERROR;
- } else if (l.equalsIgnoreCase("warning")) {
- logLevel = LogService.LOG_WARNING;
- }
- }
-
- instanceManager = getInstanceManager();
-}
-----
-
-You can also access instance configuration (properties defined in the `instance` tag).
-The instance properties are directly passed, as a `Dictionary,` to the `configure()` method.
-With these properties, you can easily allow instances to override some component fixed configuration.
-The property handler given in the archive file extract the location of the loaded properties file from the instance configuration:
-
-[source,java]
- // Look if the instance overrides file location :
- String instanceFile = (String) configuration.get("properties.file");
- if (instanceFile != null) {
- m_file = instanceFile;
- }
-
-=== Interacting with the POJO
-
-One of the most interesting features of an handler is the ability to interact with the component's POJO.
-Indeed, you can intercept method calls and returns, inject values in the POJO's fields...
-
-The `getPojoMetadata()` method of the PrimitiveHandler class lets you access the structure of the POJO (represented by the `PojoMetadata` type) without having to use (slow) reflection.
-It allows you to list all fields and methods of the POJO, and get informations about implemented interfaces and the super-class.
-The `PojoMetadata` class implements the following operations :
-
-* The `getInterfaces()` method returns the list of implemented interfaces, while the `isInterfaceImplemented()` methods test if a given interface is implemented by the POJO.
-* The `getSuperClass()` method returns the name of the class extended by the POJO (or `null` instead of `java.lang.Object`).
-* The `getField()` methods lets you access the fields of the POJO.
-The returned object is a `FieldMetadata` that provides information about a particular field inside the POJO.
-* The `getMethod()` methods lets you access the methods of the POJO.
-The returned object is a `MethodMetadata` that provides information about a particular method in the POJO.
-
-Once you've retrieved informations about the POJO structure, you can interact with it, via the `InstanceManager`, accessible in your handler by the `getInstanceManager()` method.
-It allows you to register interceptors, that are called before and after POJO method calls or field accesses.
-
-The property handler is registering field interceptors on injected properties:
-
-[source,java]
-----
-//First get Pojo Metadata metadata :
-PojoMetadata pojoMeta = getPojoMetadata();
-Enumeration e = m_properties.keys();
-while (e.hasMoreElements()) {
- String field = (String) e.nextElement();
- FieldMetadata fm = pojoMeta.getField(field);
-
- if (fm == null) { // The field does not exist
- throw new ConfigurationException("The field " + field + " is declared in the properties file but does not exist in the pojo");
- }
-
- // Then check that the field is a String field
- if (!fm.getFieldType().equals(String.class.getName())) {
- throw new ConfigurationException("The field " + field + " exists in the pojo, but is not a String");
- }
-
- // All checks are ok, register the interceptor.
- getInstanceManager().register(fm, this);
-}
-----
-
-The InstanceManager manages the component instance attached to your handler instance.
-Thus, it can't be available in the `initializeComponentFactory()` because this method is run before the creation of any component instance.
-
-You need to implement some of the following methods to intercept fields accesses :
-
-* The `void onSet(Object pojo, String fieldName, Object value)` method: This method is called each time a field of the POJO is assigned.
-The first parameter is the instance of the concerned POJO, the second is the name of the accessed field and the third is the value assigned to the POJO's field.
-If the field type is a primitive type, this method receives the boxed object.
-* The `Object onGet(Object pojo, String fieldName, Object value)` method : This method is called each time a field of the POJO is read.
-The first parameter is the instance of the concerned POJO, the second is the name of the accessed field and the third is the actual value of the POJO's field.
-If the field type is a primitive type, this method receives the boxed object.
-The returned object is the value the intercepted read process will return.
-It's the standard way to inject a value in the field : returning a specific object whatever the field really contains.
-
-The property handler contains the following ``onGetz and ``onSet` methods:
-
-[source,java]
-----
-/**
- * This method is called at each time the pojo 'get' a listened field. The method return the stored value.
- * @param pojo : pojo object getting the field
- * @param field : field name.
- * @param o : previous value.
- * @return the stored value.
- */
-public Object onGet(Object pojo, String field, Object o) {
- // When the pojo requires a value for a managed field, this method is invoked.
- // So, we have just to return the stored value.
- return m_properties.get(field);
-}
-
-/**
- * This method is called at each time the pojo 'set' a listened field. This method updates the local properties.
- * @param pojo : pojo object setting the field
- * @param field : field name
- * @param newvalue : new value
- */
-public void onSet(Object pojo, String field, Object newvalue) {
- // When the pojo set a value to a managed field, this method is invoked.
- // So, we update the stored value.
- m_properties.put(field, newvalue);
-}
-----
-
-You need to implements some of the following methods to intercept methods accesses.
-When these methods are called, the first parameter is the POJO's instance on which the intercepted method is called and the second parameter contains the descriptor of the called method.
-
-* The `void onEntry(Object pojo, Member method, Object[] args)` method: This method is called before the execution of an intercepted method.
-The third parameter is the list of parameters with which the method have been called.
-The method is executed just after the execution of the `onEntry()` callback.
-* The `void onExit(Object pojo, Member method, Object returnedObj)` method: This method is called right after the successful execution of an intercepted method.
-The third parameter is the value returned by the method (or `null` if the method return type is `void`).
-This value must not be modified.
-* The `void onError(Object pojo, Member method, Throwable throwable)` method: This method is called right after the unexpected return of an intercepted method (i.e.
-when an uncaught exception occurred).
-The third parameter is the thrown object that caused the method termination.
-* The `void onFinally(Object pojo, Member method)` method: This method is called after the termination of an intercepted method (expected or not), after the call of the `onExit()` or `onError()` callback.
-
-The `InstanceManager` has to know your handler wants to intercept fields or methods access, otherwise the implemented callbacks won't be called.
-Thus you need to register each field and method you want to intercept, so the `InstanceManager` will call the appropriated callbacks when the specified field or method is accessed :
-
-The `PrimitiveHandler` abstract class implements the `FieldInterceptor` and `MethodInterceptor` interfaces, which declares the methods described just above.
-You can create your own interceptor class (implementing one or both of these interfaces) and give it to the `InstanceManager` register method instead of the handler object itself.
-
-=== Using your handler
-
-Once your handler has been declared, you can use it in iPOJO components.
-To do so, you first have to be bound to your handler's namespace (using standard XML namespace declaration).
-Then you can configure the handler in your components type description.
-An example of bundle's `metadata.xml` declaring components using the handler is shown hereafter :
-[source,xml]
- <ipojo xmlns:your-shortcut="the.namespace.of.your.handler">
- ...
- <component className="your.component.class">
- ...
- <your-shortcut:HandlerName param1="value1" ...>
- <!--
- Configuration of your handler for
- this component type
- -->
- </your-shortcut:HandlerName>
- ...
- </component>
- ...
- </ipojo>
-
-Obviously, you probably want to use annotations.
-You just have to provide the annotation classes: `handler_namespace.handler_element`.
-For instance, the log handler provides the `org.apache.felix.ipojo.log.handler.Log` annotation:
-
-[source,java]
-----
-package org.apache.felix.ipojo.log.handler;
-
-/**
- * The annotation used to configure the LogHandler.
- */
-public @interface Log {
-
- public enum Level {
- INFO, ERROR, WARNING
- }
-
- /**
- * @return the log level
- */
- Level level();
-}
-----
-
-The remainder of this document describes two examples of handlers:
-
-* A log handler logging messages in the OSGi Log Service
-* A properties handler reading a property files to configure POJO field
-
-== Log Handler example
-
-This section describes how to create a simple handler.
-This handler logs a message in the _OSGi Log Service_ (if present) when the component instance state changes.
-
-=== Handler metadata
-
-The handler namespace is `org.apache.felix.ipojo.log.handler.LogHandler`.
-It is also the name of the handler implementation class.
-You can note that the handler has an optional dependency on a OSGi log service.
-
-[source,java]
-----
-// Declare a handler.
-@Handler(name = "Log", namespace = LogHandler.NAMESPACE)
-public class LogHandler extends PrimitiveHandler {
-
- public static final String NAMESPACE = "org.apache.felix.ipojo.log.handler";
-
- // Handlers are iPOJO components, so can use service dependencies
- @Requires(optional = true, nullable = false)
- LogService log;
- private InstanceManager instanceManager;
- private int logLevel;
-
-//...
-----
-
-=== Handler implementation
-
-The handler needs to override following methods:
-
-* `configure` : to parse the metadata and load the properties file
-* `stateChanged` : to log messages when the instance state changes.
-
-==== LogHandler class
-
-The handler is implemented inside the `LogHandler` class in the `org.apache.felix.ipojo.handler.log` package.
-This class extends the `org.apache.felix.ipojo.PrimitiveHandler` class.
-The handler needs to be notified when component instances becomes valid or invalid, thus it implements the `InstanceStateListener` interface.
-
-==== Configure Method
-
-This method reads the component description and configures the handler.
-Then, the handler registers itself to the instance manager to be informed of the component's validity changes.
-
-[source,java]
-----
-/**
- * Parses the component's metadata to retrieve the log level in which we log messages.
- *
- * @param metadata component's metadata
- * @param configuration instance configuration (unused in this example)
- * @throws ConfigurationException the configuration is inconsistent
- */
-@Override
-public void configure(Element metadata, Dictionary configuration) throws ConfigurationException {
- // First parse the metadata to check if the log handler logLevel
-
- // Get all Namespace:log element from the metadata
- Element[] log_elements = metadata.getElements("log", NAMESPACE);
-
- // If an element match, parse the logLevel attribute of the first found element
- if (log_elements[0].containsAttribute("level")) {
- String l = log_elements[0].getAttribute("level");
- if (l.equalsIgnoreCase("info")) {
- logLevel = LogService.LOG_INFO;
- } else if (l.equalsIgnoreCase("error")) {
- logLevel = LogService.LOG_ERROR;
- } else if (l.equalsIgnoreCase("warning")) {
- logLevel = LogService.LOG_WARNING;
- }
- }
-
- instanceManager = getInstanceManager();
-}
-----
-
-==== StateChanged Method
-
-This method is called by the instance manager to notify that the component instance state changes.
-The handler needs to log a message containing the new state.
-
-[source,java]
- /**
- * Logging messages when the instance state is changing
- *
- * @param state the new state
- */
- public void stateChanged(int state) {
- if (log != null) {
- if (state == InstanceManager.VALID) {
- System.out.println("The component instance " + instanceManager.getInstanceName() + " becomes valid");
- log.log(logLevel, "The component instance " + instanceManager.getInstanceName() + " becomes valid");
- }
- if (state == InstanceManager.INVALID) {
- System.out.println("The component instance " + instanceManager.getInstanceName() + " becomes invalid");
- log.log(logLevel, "The component instance " + instanceManager.getInstanceName() + " becomes invalid");
- }
- }
- }
-
-=== Start and Stop
-
-The handler also contains two methods called by the instance manager when the underlying instance starts and stops.
-
-[source,java]
-----
-/**
- * The instance is starting.
- */
-public void start() {
- if (log != null) {
- log.log(logLevel, "The component instance " + instanceManager.getInstanceName() + " is starting");
- }
-}
-
-/**
- * The instance is stopping.
- */
-public void stop() {
- if (log != null) {
- log.log(logLevel, "The component instance " + instanceManager.getInstanceName() + " is stopping");
- }
-}
-----
-
-== Handler packaging
-
-This handler needs to be packaged inside an iPOJO bundle.
-The bundle will import the `org.apache.felix.ipojo`, `org.osgi.framework` and `org.osgi.service.log` packages.
-
-=== Handler usage
-
-To use this handler, a component use the `Log` annotation, with a level attribute.
-This level attribute's value can be `"error"`, `"warning"` or `"info"`.
-Here is an usage example:
-
-[source,java]
-----
-package org.apache.felix.ipojo.log.handler.example;
-
-import org.apache.felix.ipojo.annotations.*;
-import org.apache.felix.ipojo.foo.FooService;
-import org.apache.felix.ipojo.log.handler.Log;
-
-@Component(immediate = true)
-@Log(level = Log.Level.INFO) // We configure the handler.
-@Instantiate(name = "my.simple.consumer")
-public class SimpleComponent {
-
- @Requires
- FooService fs;
-
- @Validate
- public void starting() {
- System.out.println("Starting...");
- fs.foo();
- }
-
- @Invalidate
- public void stopping() {
- System.out.println("Stopping...");
- }
-}
-----
-
-=== Playing with the handler
-
-The archive contains a project named `Log-Handler-In-Felix`, which once built, provides a Felix framework with all the bundles deployed.
-
-Unzip the archive, and build the whole project using Maven: `mvn clean install`.
-It builds the log handler and the property handler.
-Then navigate to the felix-framework-VERSION directory:
-
-[source,sh]
- mvn clean install
- #...
- cd Log-Handler-In-Felix/target/felix-framework-4.2.1/
- java -jar bin/felix.jar
-
-Once you have launched Felix, you get the Gogo Shell prompt:
-
-[source,sh]
-----
-Starting...
-Foo
-The component instance my.simple.consumer becomes valid
-____________________________
-Welcome to Apache Felix Gogo
-
-g! lb
-START LEVEL 1
- ID|State |Level|Name
- 0|Active | 0|System Bundle (4.2.1)
- 1|Active | 1|Apache Felix Bundle Repository (1.6.6)
- 2|Active | 1|Apache Felix Gogo Command (0.12.0)
- 3|Active | 1|Apache Felix Gogo Runtime (0.10.0)
- 4|Active | 1|Apache Felix Gogo Shell (0.10.0)
- 5|Active | 1|Apache Felix iPOJO (1.8.6)
- 6|Active | 1|Apache Felix iPOJO Gogo Command (1.0.1)
- 7|Active | 1|iPOJO Log Handler Consumer (1.9.0.SNAPSHOT)
- 8|Active | 1|iPOJO Foo Service (1.9.0.SNAPSHOT)
- 9|Active | 1|iPOJO Log Handler (1.9.0.SNAPSHOT)
- 10|Active | 1|Apache Felix Log Service (1.0.1)
-g!
-----
-
-You can already see some of the messages printed by the handler (`The component instance my.simple.consumer becomes valid`).
-To see more message, stop and start the Foo Service bundle:
-
-[source,sh]
- g! stop 8
- The component instance my.simple.consumer becomes invalid
- Stopping...
- g! start 8
- g! Starting...
- Foo
- The component instance my.simple.consumer becomes valid
-
-By stopping the Foo service bundle, you withdrew the foo service from the service registry making our component invalid (and unhappy).
-The handler is notified of the new state and logs a message.
-When the bundle restarts, the service is republished.
-So the instance becomes valid again.
-The handler is notified and logs another message.
-
-== Properties Handler example
-
-This section presents a second handler.
-This handler loads a property file containing field name and initial value.
-Then it injects and maintains these values inside POJO fields.
-In this example, only String values are managed.
-
-This handler is always valid, so do not participate to the component instance lifecycle.
-Moreover, the handler does not need to be notified when the component instance state changed.
-But, it need to be notified when POJO fields need a value or change their value.
-
-=== Handler implementation
-
-The handler needs to override following methods:
-
-* `configure` : to parse the metadata and load the properties file
-* `stop` : to store the properties
-* `onGet` : to inject a values inside a field
-* `onSet` : to obtain the new field value
-
-==== PropertiesHandler class
-
-The handler is implemented by the `PropertiesHandler` class present in the `org.apache.felix.ipojo.properties.handler` package.
-The class has several fields:
-
-* The properties to maintain (`m_properties`)
-* The properties file name (`m_file`)
-
-NOTE: the file name is the absolute path on the local machine of the file.
-
-[source,java]
-----
-/**
- * This handler load a properties file containing property value.
- * The handler injects this values inside fields. When stopped the handler stores updated value inside the file. The
- * properties file contains <pre>field-name : field-value</pre> (field-value are strings)
- *
- * Instances can override file locations by setting the {@literal properties.file} property.
- *
- * @author <a href="mailto:dev@felix.apache.org">Felix Project Team</a>
- */
-@Handler(name="properties", namespace = PropertiesHandler.NAMESPACE)
-public class PropertiesHandler extends PrimitiveHandler {
-
- /**
- * The Handler namespace.
- */
- public static final String NAMESPACE = "org.apache.felix.ipojo.handler.properties";
-
- /**
- * The loaded properties.
- */
- private Properties m_properties = new Properties();
-
- /**
- * The properties file location, configured in the component's metadata.
- */
- private String m_file;
-----
-
-==== Configure Method
-
-This method begins by parsing the component type metadata.
-The handler needs a properties element from its namespace.
-According to the result, the configure method can return immediately or parse the file attribute (to get the properties file path).
-Then, it builds a field list (String array) to register to field notification.
-By registering with a field array, the handler is going to be notified of field access.
-
-[source,java]
-----
-/**
- * This method is the first to be invoked.
- * This method aims to configure the handler. It receives the component type metadata and the instance
- * configuration. The method parses given metadata and registers fields to inject.
- *
- * Step 3 : when the instance configuration contains the properties.file property, it overrides the properties file location.
- *
- * @param metadata : component type metadata
- * @param configuration : instance description
- * @throws ConfigurationException : the configuration of the handler has failed.
- */
-@SuppressWarnings("unchecked")
-public void configure(Element metadata, Dictionary configuration) throws ConfigurationException {
- // Get all elements to configure the handler
- Element[] elem = metadata.getElements("properties", NAMESPACE);
-
- switch (elem.length) {
- case 0:
- // No matching element in metadata, throw a configuration error.
- // It actually happen only if you force the handler to be plugged.
- throw new ConfigurationException("No properties found");
- case 1:
- // One 'properties' found, get attributes.
- m_file = elem[0].getAttribute("file");
- if (m_file == null) {
- // if file is null, throw a configuration error.
- throw new ConfigurationException("Malformed properties element : file attribute must be set");
- }
- break;
- default:
- // To simplify we handle only one properties element.
- throw new ConfigurationException("Only one properties element is supported");
- }
-
- // Look if the instance overrides file location :
- String instanceFile = (String) configuration.get("properties.file");
- if (instanceFile != null) {
- m_file = instanceFile;
- }
-
- // Load properties
- try {
- loadProperties();
- } catch (IOException e) {
- throw new ConfigurationException("Error when reading the " + m_file + " file : " + e.getMessage());
- }
-
- // Register fields
- // By convention, properties file entry are field name, so look for each property to get field list.
-
- //First get Pojo Metadata metadata :
- PojoMetadata pojoMeta = getPojoMetadata();
- Enumeration e = m_properties.keys();
- while (e.hasMoreElements()) {
- String field = (String) e.nextElement();
- FieldMetadata fm = pojoMeta.getField(field);
-
- if (fm == null) { // The field does not exist
- throw new ConfigurationException("The field " + field + " is declared in the properties file but does not exist in the pojo");
- }
-
- // Then check that the field is a String field
- if (!fm.getFieldType().equals(String.class.getName())) {
- throw new ConfigurationException("The field " + field + " exists in the pojo, but is not a String");
- }
-
- // All checks are ok, register the interceptor.
- getInstanceManager().register(fm, this);
- }
-}
-----
-
-Notice that the handler is using the instance configuration.
-So instances can set their own file location using the `properties.file` property.
-
-==== The start and stop methods
-
-The start method does nothing, but needs to be implemented.
-
-[source,java]
- public void start() {}
-
-The stop method stores properties inside the properties file.
-
-[source,java]
- public void stop() {
- try {
- saveProperties();
- } catch (IOException e) {
- // Log an error message by using the iPOJO logger
- error("Cannot read the file : " + m_file, e);
- }
- m_properties = null;
- }
-
-==== onGet and onSet methods
-
-The onGet method is called when the POJO need a field value.
-When called, the method needs to return the stored value.The onSet method is called when the POJO modifies a field value.
-If the new value if null, the handler will remove this properties from the property list.
-
-[source,java]
-----
-public Object onGet(Object pojo, String field, Object o) {
- // When the pojo requires a value for a managed field,
- // this method is invoked.
- // So, we have just to return the stored value.
- return m_properties.get(field);
-}
-
-public void onSet(Object pojo, String field, Object newvalue) {
- // When the pojo set a value to a managed field,
- // this method is invoked.
- // So, we update the stored value.
- m_properties.put(field, newvalue);
-}
-----
-
-=== Creating the annotation
-
-The handler provides an annotation to ease its use:
-
-[source,java]
-----
-package org.apache.felix.ipojo.handler.properties;
-
-/**
- * The Properties annotation.
- * This annotation may be used in POJO class to used the Property handler.
- * @author <a href="mailto:dev@felix.apache.org">Felix Project Team</a>
- */
-public @interface Properties {
-
- /**
- * Returns the property file used by the handler.
- */
- String file();
-
-}
-----
-
-=== Handler packaging
-
-This handler needs to be inside a bundle importing the `org.apache.felix.ipojo` packages and exporting the `org.apache.felix.ipojo.properties.handler` package.
-
-=== Playing with the handler
-
-As for the log handler , the archive contains a felix distribution with all bundles deployed.
-
-[source,sh]
- cd Property-Handler-In-Felix/target/felix-framework-4.2.1/
- java -jar bin/felix.jar
-
-In Gogo you immediately see the loaded properties:
-
-[source,sh]
- -- listing properties --
- property2="bbb"
- property1="aaa"
- PropertiesTester is starting ...
- Property 1 : "aaa"
- Property 2 : "bbb"
- Update properties
- -- listing properties --
- property2="bbb"
- property1="aaa"
- PropertiesTester is starting ...
- Property 1 : "aaa"
- Property 2 : "bbb"
- Update properties
- ____________________________
- Welcome to Apache Felix Gogo
- g!
-
-In this example, we have two instances of the same component type loading different properties files.
-The first instance loads the default properties file.
-The second one is configured to read another one.
-This configuraiton is given in the instance configuration:
-[source,xml]
- <ipojo>
- <!-- Declare an instance illustrating instance configuration -->
- <instance component="PropertiesTester"
- name="instance-using-properties-i1">
- <property name="props.file"
- value="props\properties-i1.properties" />
- </instance>
- </ipojo>
-
-== Advanced topics
-
-=== Handler reconfiguration
-
-iPOJO has the ability to reconfigure component instances while they are running.
-When instances are reconfigured, their used handler need to update their configuration (if they support such an operation).
-To do so, reconfigurable handlers must override the `reconfigure()` method, which notify the concerned handlers of the new instance configuration (represented as a `Dictionary`).
-
-
-[#description]
-=== Describing your handler
-
-Handlers have the possibility to describe their state, overriding the `getDescription()` method and the `HandlerDescription` class.
-By default, only the handler's name and validity are displayed in component instance's description (informations displayed by the (`arch -instance an.instance.name` command).
-The standard way to add description to your handler is shown hereafter :
-
-[source,java]
- public class YourHandler extends PrimitiveHandler {
- ...
- // Method returning the handler description.
- public HandlerDescription getDescription() {
- return new YourHandlerDescription(this);
- }
-
- ...
-
- private class YourHandlerDescription extends HandlerDescription {
- public Description(PrimitiveHandler h) { super(h); }
-
- // Method returning the custom description of this handler.
- public Element getHandlerInfo() {
- // Needed to get the root description element.
- Element elem = super.getHandlerInfo();
- // Add here attributes and sub-elements
- // into the root description element.
- // Example : elem.addAttribute(new Attribute("param", "value"));
- Element subElement = new Element("subElement", "");
- subElement.addAttribute(new Attribute("subParam", "subValue"));
- elem.addElement(subElement);
- ...
- return elem;
- }
- }
- }
-
-[#annotations]
-== Handler's annotations
-
-Your handle can also provide annotations.
-Annotations will allows users to configure the Handler from the source code (avoiding XML edition).
-iPOJO supports annotation of external handlers.
-Indeed, it detects annotations and re-creates the `Element-Attribute` structure.
-So, first, external Handler annotations _MUST_ follow some principles:
-
-* The annotation package must be the Handler namespace
-* The annotation name must be the Handler name
-* The package must contain either the 'ipojo' or the 'handler' word.
-
-So, when iPOJO detects the annotation, an Element is created with the annotation package as the `Element namespace` and the annotation name as the `Element name`.
-Then, 'scalar' annotation attributes are mapped to Attribute.
-Sub-annotations (annotation attribute) are mapped to sub-elements.
-For example, the annotation for the property handler is:
-
-[source,java]
-----
-package org.apache.felix.ipojo.properties.handler;
-
-import java.lang.annotation.ElementType;
-import java.lang.annotation.Target;
-
-@Target(ElementType.TYPE)
-public @interface Properties {
-
- String file();
-
-}
-----
-
-This annotations is put on the {\{class}} element, and allows setting the property file:
-
-[source,java]
- @Component
- @Properties(file="/Users/clement/felix/properties/i1.properties")
- public class Example {
- ...
- }
-
-However, your handler can also provide several annotations to represent Element and sub-elements.
-Your annotations can also be placed on different code elements (Type, Field, Method).
-In this case, to recreate the Element/Sub-Element hierarchy, iPOJO processes as following:
-
-* The first annotation of a package `P` is processed by creating the root Element (component sub-element).
-* All others annotations of the package `P` are processed as sub-element of the previously created Element.
-
-For example, the following code:
-
-[source,java]
-----
-import org.apache.felix.ipojo.annotations.Component;
-import org.apache.felix.ipojo.handlers.jmx.Config;
-import org.apache.felix.ipojo.handlers.jmx.Method;
-import org.apache.felix.ipojo.handlers.jmx.Property;
-
-@Component
-@Config(domain="my-domain", usesMOSGi=false) // External handler annotation
-public class JMXSimple {
-
- @Property(name="prop", notification=true, rights="w") //External handler annotation
- String m_foo;
-
- @Method(description="set the foo prop") //External handler annotation
- public void setFoo(String mes) {
- System.out.println("Set foo to " + mes);
- m_foo = mes;
- }
-
- @Method(description="get the foo prop") //External handler annotation
- public String getFoo() {
- return m_foo;
- }
-}
-----
-
-will be translated to:
-
-[source,sh]
- component {
- $classname="org.apache.felix.ipojo.test.scenarios.component.jmx.JMXSimple"
- $public="true" $name="org.apache.felix.ipojo.test.scenarios.component.jmx.JMXSimple"
- org.apache.felix.ipojo.handlers.jmx:config {
- $usesmosgi="false" $domain="my-domain"
- org.apache.felix.ipojo.handlers.jmx:property {
- $rights="w" $notification="true" $field="m_foo" $name="prop" }
- org.apache.felix.ipojo.handlers.jmx:method {
- $description="set the foo prop" $method="setFoo" }
- org.apache.felix.ipojo.handlers.jmx:method {
- $description="get the foo prop" $method="getFoo" }
- }
- }
-
-NOTE: To customize this hierarchy, you can also use the `id/parent` annotation attributse.
-The id attribute is used to refer to an Element.
-An annotation with a `parent` (targeting an `id`) attribute will be processed as a sub-element of the Element identified by the given `id`.
-
-[#schemas]
-== Handler's XSD
-
-Coming soon...
-
-== Conclusion
-
-In this document, we present how-to develop handler for your components.
-We describe two small examples : a log handler and a properties handler.
-These handlers are plugged on (primitive) instance.
-However, it is possible to extends `CompositeHandler` too to customize the composition model.
-
-If you develop handler and you want to share it, feel free to contact us by sending a mail on the Felix mailing list.
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-eclipse-integration.adoc b/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-eclipse-integration.adoc
deleted file mode 100644
index 5311ffe..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-eclipse-integration.adoc
+++ /dev/null
@@ -1,72 +0,0 @@
-= Building and Running iPOJO bundles from Eclipse
-
-_This page explains how to build and run iPOJO bundles without exiting Eclipse and breaking the compile-run cycle.
-Bundles are executed inside Equinox._
-
-
-
-== 1) Import the iPOJO Bundle project
-
-Download the link:MyiPOJOBundle-1.4.2.zip[project archive], and import it as an _Existing Project into the Workspace_
-
-image:documentation/subprojects/apache-felix-ipojo/Picture 1.png[] image:documentation/subprojects/apache-felix-ipojo/Picture 2.png[] image:documentation/subprojects/apache-felix-ipojo/Picture 3.png[]
-
-Then click on _finish_
-
-== 2) Configure the target platform
-
-image:documentation/subprojects/apache-felix-ipojo/Picture 4.png[] image:documentation/subprojects/apache-felix-ipojo/Picture 5.png[]
-
-The resulting project, you looks like the left picture.
-
-== 3) Develop you bundle
-
-The imported project contains a very simple component using annotations.
-But, obviously you can delete/change it.
-For XML-metadata, use `metadata.xml` file is in the project root.
-
-[source,java]
-----
-@Component
-public class MyComponentImpl {
-
- @Validate
- public void start() {
- System.out.println("I'm started !!!");
- }
-
- @Invalidate
- public void stop() {
- System.out.println("I'm leaving :-(...");
- }
-
-}
-----
-
-Once you're done, you are able to run your bundle !
-
-== 4) Run your bundle
-
-image::documentation/subprojects/apache-felix-ipojo/Picture 6.png[]
-
-Right-click on the _.launch_ file and then go on _Run-As \-> MyiPOJOBundle_.
-Equinox will be started and your iPOJO bundle deployed and started: Once run for the first time, you can re-run it from the {\{run}} icon.
-In the console view, you get your Equinox shell, and you see your application result.
-If you don't edit the given development, the output is as:
-
-image::documentation/subprojects/apache-felix-ipojo/Picture 8.png[]
-
-== Iterate :-)
-
-Then, go back to the step 3, change your components, and see the new result...
-That's it !
-
-== Changes in the 1.4.0
-
-[cols=2*]
-|===
-| The 1.4.0+ iPOJO manipulator allows manipulating classes from a directory ([FELIX-943
-| http://cwiki.apache.org/jira/browse/FELIX-943]).
-This feature is very convenient for the Eclipse integration because it avoids creating the Jar and unzipping it inside the Eclipse build directory.
-Moreover, it allows reusing the Java Eclipse builder (compiling classes).
-|===
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-feature-overview.adoc b/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-feature-overview.adoc
deleted file mode 100644
index c3557df..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-feature-overview.adoc
+++ /dev/null
@@ -1,51 +0,0 @@
-= Apache Felix iPOJO Feature Overview
-
-_This page is an attempt to put all of the features and benefits of iPOJO into a single high-level list so that it is easy to see why you will want to use iPOJO for your applications.
-This list is not exhaustive, but represents the set of features that are potentially most likely to be needed or are unique._
-
-== Core Features
-
-* _POJO-based approach_ - Most components can simply be POJOs and need not have iPOJO- or OSGi-specific API in them.
-* _Simple service provisioning_ - iPOJO manages all aspects of providing an OSGi service.
-* _Service property management_
- ** Can be controlled by configuration properties.
- ** Can be mapped to member fields and automatically updated by the component instance at run time by just changing the member field value.
-* Service life cycle participation
- ** The component instance can participate in the service life cycle by declaring a boolean member field that indicates when the service is actually valid (normally a service is assumed to be valid if the component instance's dependencies are satisfied).
-* _Rich service dependency model_ - Automatically manages a full spectrum of service dependencies.
- ** _Optional/mandatory_ service dependencies.
- ** _Singular/aggregate_ service dependencies.
- ** _Default service implementations_ - The component can provide default implementations of dependent services if no providers are available.
- ** _Member field or method injection_ - Also supported in combination.
- *** Member field injection does not require cluttering component code with bind/unbind methods.
- *** Member method injection supports various method signatures
- **** method() - Acts as a simple event-callback mechanism.
- **** method(<service-interface>svc) - Receives the service object cast to the appropriate interface.
- **** method(ServiceReference ref) - Receives the OSGi ServiceReference for the service object.
- **** method(ServiceReference ref, <service-interface>svc) - Receives the OSGi ServiceReference and the service object cast to the appropriate interface.
- ** _Binding policies_ - Allow components to control how/when their dependencies are bound.
- *** _Static_ - Static dependencies _cannot_ change without invalidating the component instance, so injected services typically do not change at run time and service departures typically result in the component instance being destroyed and potentially recreated.
- *** _Dynamic_ - Dynamic dependencies _can_ change without invalidating the component instance, so injected services can change at run time, but _do not_ change with respect to service priority changes (i.e., they do not automatically switch if a higher priority service appears).
- *** _Dynamic priority_ - Dynamic priority dependencies _can_ change without invalidating the component instance and _do_ dynamically update based on service priority rankings at run time.
-* _Configuration property management_ - Integrated with OSGi Configuration Admin service.
-* _Member field/member method injection_ - Also supported in combination.
- ** _Service property propagation_ - Configuration properties can be configured to update service properties if the component instance is providing a service.
-* _Sophisticated concurrency handling_ - Externalizes concurrency issues so that component code does not need to worry about services changing while they are in use (i.e., no locking protocol in component code).
-* _Deferred instance creation_ - POJO instances are not created until they are actually needed, thus reducing start-up overhead.
-* _Introspection support_ - Supports introspecting a component instance and the state of its dependencies.
- ** Interactive introspection is supported by an arch command for Felix' shell.
-* _Extensible_ - All iPOJO features are implemented via a set of `handlers`, which is an extensibility mechanism open to developers by which they can support custom functionality (e.g., exporting a provided service remotely, etc.).
-
-== Advanced/Experimental Features
-
-* _Composite model_ - iPOJO supports a flexible architectural-like model for composing services.
- ** _Flexible composites_ - A composite is an abstract component implementation.
- ** _Sub-services and sub-components_ - Unlike traditional component composition, an iPOJO composite can be described in terms of services in addition to sub-components;
-thus sub-service implementation selection is deferred until run time.
- ** _Optional/mandatory_ sub-services and/or sub-components.
- ** _Singular/aggregate_ sub-services and/or sub-components.
- ** _Hierarchical_ - A composite component may contain other composite components.
- ** _Composite scoping_ - A composite acts as a scoping mechanism where sub-services/sub-components are not visible externally and external services are not visible internally.
- ** _Service dependencies_ - A composite has the full expressive capabilities of primitive components when it comes to service dependencies (see above description of service dependencies in core features).
- ** For a composite, a service dependency effectively imports an external service into the composite scope from its parent composite (which may be the OSGi service registry in the root case).
- ** _Composite is just a component_ - Composites can be instantiated and automatically managed just like a primitive component.
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/apache-felix-ipojo-dosgi.adoc b/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/apache-felix-ipojo-dosgi.adoc
deleted file mode 100644
index 4e7451e..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/apache-felix-ipojo-dosgi.adoc
+++ /dev/null
@@ -1,161 +0,0 @@
-= Using Distributed Services with iPOJO
-
-_Distributed Service defines how to deal with remote services in OSGi.
-This page describes the CXF Distributed OSGi with iPOJO demo.This demo uses iPOJO to create a remote OSGi service from an iPOJO component.
-The consumer side also uses iPOJO to create a component that consumes the remote OSGi service.
-By using iPOJO, you don't need to write code to interact with the OSGi Service Registry at all.
-That's all handled through injection, which hugely simplifies the code.
-Moreover thanks to iPOJO's advanced features such as property propagation, the service is exported without any impact on its implementation._
-
-In this demo, you will show how to use iPOJO:
-
-* to expose a service
-* to propagate properties to make the service remotely accessible
-* to use a "remote" service
-
-This demo can be used with any DOSGi distribution, in this document the single-bundle distribution (1.1) is used with iPOJO 1.6.0 and Felix (2.0.5)
-
-
-
-== Demo design
-
-This demo is quite similar to the DS demo of DOSGi demo in structure.
-It consists of 5 bundles:
-
-* An interface bundle defining the Adder Service interface.
-* This bundle is deployed on both sides.
-* An Adder Service implementation bundle.
-(The service will be exported)
-* An Adder Service importer bundle containing the remote-service file explaining to DOSGi how to import and from where to import the Adder service.
-* An Adder Service consumer bundle.
-
-image::documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/design.png[]
-
-The service implementation and consumer bundle are built using iPOJO.
-The Adder Service interface is as follows:
-
-[source,java]
- public interface AdderService {
- int add(int a,int b);
- }
-
-== Sources
-
-The sources and a pre-configured version of Felix are available in the http://people.apache.org/~clement/ipojo/tutorials/dosgi/dosgi-tutorial.zip[dosgi-tutorial archive].
-Once downloaded unzip the archive.
-To compile, run from the root : `mvn clean install`.
-To run the application.
-go to the `felix` directory containing a pre-configured Felix.
-
-== The Adder Service Implementation
-
-The service implementation is a simplistic implementation of the Adder service, which is instantiated as an iPOJO component.
-This implementation uses annotations to define its component type.
-The `@provides` annotation just says that it provides a service.
-Moreover, the `propagation=true` attribute enables property propagation.
-
-In the http://svn.apache.org/repos/asf/felix/sandbox/clement/ipojo-tutorials/dosgi/AdderServiceProvider/src/main/resources/metadata.xml[metadata.xml] file, an instance of the component type is declared.
-Note that this instance declaration defines three properties used by DOSGi to exports the service.
-These properties instruct Distributed OSGi into making the service available on http://localhost:9090/adder.
-Those properties are not declared in the component type itself.
-Indeed, the component type enables property propagation;
-so all defined properties will be published on exported services.
-This propagation also works with the configuration admin.
-This feature is pretty nice, as it does not impact the component implementation and its description.
-[source,xml]
- <instance component="org.apache.felix.ipojo.remote.adder.impl.AdderServiceImpl">
- <property name="osgi.remote.interfaces"value="*"/>
- <property name="osgi.remote.configuration.type"value="pojo"/>
- <property name="osgi.remote.configuration.pojo.address"value="http://localhost:9090/adder"/>
- </instance>
-
-So let's install the server side in Felix.
-Launch Felix from the `felix` directory with:
-
-[source,sh]
- java -jar bin/felix.jar server
-
-Once the shell prompt appears, execute the following command in the shell:
-
-[source,sh]
- start file:../AdderServiceInterface/target/AdderServiceInterface-0.0.1-SNAPSHOT.jar
- start file:../AdderServiceProvider/target/AdderServiceProvider-0.0.1-SNAPSHOT.jar
-
-At this point, the service should be available remotely (wait until the console stops printing stuff), you can check this by obtaining the WSDL: http://localhost:9090/adder?wsdl
-
-image::documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/wsdl.png[,600px]
-
-== The Adder Service Consumer
-
-The service consumer is also created using iPOJO.
-Thanks to DOSGi, iPOJO can inject the service as any regular OSGi service.
-So, the code is pretty simple:
-
-[source,java]
-----
-@Component
-public class AdderConsumer {
-
- @Requires
- private AdderService adder;
-
- public AdderConsumer() {
- System.out.println("Using adder service: 1 + 1 = "+ adder.add(1, 1));
- }
-}
-----
-
-[cols=2*]
-|===
-| This implementation use iPOJO field injection to receive the AdderService.
-Then, it uses it as a regular field.
-This bundle also contains a [metadata.xml
-| http://svn.apache.org/repos/asf/felix/sandbox/clement/ipojo-tutorials/dosgi/AdderServiceConsumer/src/main/resources/metadata.xml] file declaring an instance of this type without any special configuration:
-|===
-[source,xml]
- <instance component="org.apache.felix.ipojo.remote.consumer.AdderConsumer"/>
-
-However, now we have to tell to DOSGi to import our Adder service.
-To achieve that, we create a very simple bundle that just contains the http://svn.apache.org/repos/asf/felix/sandbox/clement/ipojo-tutorials/dosgi/AdderServiceImporter/src/main/resources/OSGI-INF/remote-service/remote-services.xml[remote-services.xml] file.
-This file is analyzed by CXF in order to import the service.
-[source,xml]
- <service-descriptions xmlns="http://www.osgi.org/xmlns/sd/v1.0.0">
- <service-description>
- <provide interface="org.apache.cxf.dosgi.samples.ds.AdderService"/>
- <property name="osgi.remote.interfaces">*</property>
- <property name="osgi.remote.configuration.type">pojo</property>
- <property name="osgi.remote.configuration.pojo.address">http://localhost:9090/adder</property>
- </service-description>
- </service-descriptions>
-
-Now, let's start another instance of Felix:
-
-[source,sh]
- java -jar bin/felix.jar client
-
-Then, execute the following command in the shell:
-
-[source,sh]
-----
-start file:../AdderServiceInterface/target/AdderServiceInterface-0.0.1-SNAPSHOT.jar
-start file:../AdderServiceConsumer/target/AdderServiceConsumer-0.0.1-SNAPSHOT.jar
-start file:../AdderServiceImporter/target/AdderServiceImporter-0.0.1-SNAPSHOT.jar
-
-... log messages may appear, after a little while the following message appears:
-
-Using adder service: 1 + 1 = 2
-----
-
-The remote adder service has now been invoked.
-You will see the following line on the server side window:
-
-[source,sh]
- Adder service invoked: 1 + 1 = 2
-
-That's it !
-
-== Conclusion
-
-This tutorial has illustrated how to easily create remote services and consume them with iPOJO.
-Subscribe to the Felix users mailing list by sending a message to link:mailto:users-subscribe@felix.apache.org[users-subscribe@felix.apache.org];
-after subscribing, email questions or feedback to link:mailto:users@felix.apache.org[users@felix.apache.org].
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/how-to-use-ipojo-annotations.adoc b/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/how-to-use-ipojo-annotations.adoc
deleted file mode 100644
index 6c3c6aa..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/how-to-use-ipojo-annotations.adoc
+++ /dev/null
@@ -1,377 +0,0 @@
-= How to use iPOJO annotations
-
-_You can use annotations to define your component types.
-This page presents supported annotations._
-
-
-
-== Getting iPOJO Annotations:
-
-iPOJO Annotations are defines inside the `org.apache.felix.ipojo.annotations project`.
-You can download the Jar file of this project from the link:{{ refs.download.path }}[download] page.
-Sources are available on the [Felix trunk|http://felix.apache.org/site/sourcecode.html].
-Once added to your class path / build path / dependencies, you can use the annotations as normal annotations.
-These annotations are automatically processed by the iPOJO manipulator, and do *not* need to be deployed at runtime.
-
-=== With Eclipse (or any other IDE)
-
-Add the org.apache.felix.ipojo.annotations jar file in your build path.
-Do not forget to use a Java compiler accepting annotations (1.5 or higher).
-
-=== With Maven
-
-Add the following dependency:
-[source,xml]
- <dependency>
- <groupId>org.apache.felix</groupId>
- <artifactId>org.apache.felix.ipojo.annotations</artifactId>
- <version>{{ipojo.release}}</version>
- </dependency>
-
-Moreover, you need to set that the source code and the target code are Java 1.5 code.
-To achieve this, just add the following plugin in your plugins section:
-[source,xml]
- <plugin>
- <groupId>org.apache.maven.plugins</groupId>
- <artifactId>maven-compiler-plugin</artifactId>
- <configuration>
- <source>1.5</source>
- <target>1.5</target>
- </configuration>
- </plugin>
-
-=== With Ant
-
-Just add the org.apache.felix.ipojo.annotations jar file in your class path.
-
-== An example of usage
-
-To illustrate annotations usage, let taking the tutorial example.
-In this tutorial, there are two components:
-
-* The first one provides the hello service
-* The second one uses the provided hello service You can download the archive containing the examples and a preconfigured version of Felix http://people.apache.org/~clement/ipojo/tutorials/annotations/annotation-tutorial.zip[here].
-
-=== Hello Service Provider
-
-The provider uses two annotations.
-The "component" annotation is mandatory and defines that the class defines a component type.
-Then the "provides" annotation just declare that the defined component type provides a service.
-
-[source,java]
-----
-package ipojo.example.hello.impl;
-
-import ipojo.example.hello.Hello;
-
-import org.apache.felix.ipojo.annotations.Component;
-import org.apache.felix.ipojo.annotations.Provides;
-
-/**
- * Component implementing the Hello service.
- **/
-@Component
-@Provides
-public class HelloImpl implements Hello {
- public String sayHello(String name) {
- return "hello " + name;
- }
-}
-----
-
-=== Hello Service Consumer
-
-The Hello Service Consumer use more annotations.
-First it used the component annotation.
-To defines its "immediate" behavior, it add the 'immediate' attribute.
-Then, it uses the requires annotation to define a service dependency.
-Finally, it uses the validate and invalidate annotations to define lifecycle callbacks.
-
-[source,java]
-----
-package ipojo.example.hello.client;
-
-import org.apache.felix.ipojo.annotations.Component;
-import org.apache.felix.ipojo.annotations.Invalidate;
-import org.apache.felix.ipojo.annotations.Requires;
-import org.apache.felix.ipojo.annotations.Validate;
-
-import ipojo.example.hello.Hello;
-
-@Component(name="AnnotatedHelloClient", immediate=true)
-@Instantiate
-public class HelloClient implements Runnable {
-
-@Requires
-private Hello[] m_hello;
-
-private final static int DELAY=10000;
-private boolean end;
-
- public void run() {
- while (!end) {
- try {
- invoke();
- Thread.sleep(DELAY);
- } catch (InterruptedException ie) { }
- }
-}
-
-public void invoke() {
- for (int i = 0; i < m_hello.length; i++) {
- System.out.println(m_hello[i].
- sayHello("iPOJO"));
- }
-}
-
- @Validate
- public void starting() {
- Thread thread = new Thread(this);
- end = false;
- thread.start();
- }
-
- @Invalidate
- public void stopping() {
- end = true;
- }
-}
-----
-
-== Defined Annotations
-
-This section lists defined annotations and how to use them.
-
-=== @Component
-
-_Goal:_ Defines a component type _Target:_ The component implementation class _Attributes:_
-
-* name : defines the component type name (optional, default = the class name)
-* immediate: defines the component type as immediate (optional, default = "false")
-* architecture: enable the architecture exposition (optional, default = "false")
-* propagation: enable configuration property propagation (on provided services) (optional, default = "false")
-* managedservice : set the Managed Service PID.
-(optional, default = no PID (i.e.
-the managed service will not be exposed)).
-* factoryMethod : set the factory-method.
-The specified method must be a static method and return a pojo object.(optional, default = iPOJO uses the 'regular' constructor).
-* publicFactory : set if the component type is public.
-(optional, default = true).
-
-=== @Provides
-
-_Goal:_ Defines that the component type provide services _Target:_ The component implementation class _Attributes:_
-
-* specifications: defines the provided interface (optional, default = all implemented interfaces)
-* strategy : the service object creation strategy.
-Possible values : SINGLETON, SERVICE, METHOD, INSTANCE or the strategy class name.
-With SINGLETON there is only one POJO per component instance, SERVICE means OSGi Service factory, METHOD delegates the creation to the factory-method of the component, INSTANCE creates one service object per requiring instance.
-For other strategies, specify the qualified name of the CreationStrategy class.
-(optional, default = SINGLETON)
-* properties : array containing `@StaticServiceProperties` defining service properties not attached to fields.
-
-*OSGi Service Factory* The SERVICE strategy refers to the OSGi service factory.
-So, one service object per asking bundle will be created.
-
-=== @Requires
-
-_Goal:_ Defines a service dependency _Target:_ Field, Constructor Parameter _Attributes:_
-
-* filter: defines the LDAP filter (optional)
-* optional: defines if the dependency is optional (optional, default = "false")
-* id: defines the dependency Id (useful to identify bind & unbind methods) (optional, default = field name) (if a dependency with the same id is already created (by a @bind or @unbind annotation), it merges the dependencies).
-* nullable: enable or disable the Null Object injection when the dependency is optional and no providers are available (optional, default = "true")
-* defaultimplementation: set the Default-Implmentation (optional, by default iPOJO uses a Null object)
-* exception : the class of the runtime exception to throw when no service providers are available
-* policy: defines the binding policy (optional)
-* comparator: defines the comparator to use to sort service references (optional, default = OSGi Service Reference Comparator)
-* from : defines the specific provider to use
-* specification : the required service specification.
-This attribute is required for Collection field.
-(optional, default = annotated field type).
-* proxy : enables / disables the proxy injection (enabled by default)
-* timeout : the timeout ins millisecond to wait before applying the _no service action_
-
-=== @ServiceProperty
-
-_Goal:_ Defines a service property _Target:_ Field _Attributes:_
-
-* name: property name (optional, default=field name
-* value: property value (optional, default=no value)
-* mandatory : is the property mandatory?
-(optional, default=false)
-
-*Mandatory property* + A mandatory property must receive a value either from the component type description (value attribute), or the instance configuration.
-
-=== @ServiceController
-
-_Goal:_ Control the service exposition _Target:_ Field (Boolean) _Attributes:_
-
-* value : the default value.
-If set to false, it disables the initial exposition
-* specification : set the target of the controller, must be an exposed service interface.
-By default, the controller targets all services.
-
-=== @Property
-
-_Goal:_ Defines a property _Target:_ Field, Method, Constructor Parameter _Attributes:_
-
-* name: property name (optional, default=field name computed by removing "set" from the method name (for instance setFoo(String ff) will get the Foo name), the argument name for constructor injection)
-* value: property value (optional, default=no value)
-* mandatory : is the property mandatory?
-(optional, default=false)
-
-*Field, Method, Constructor* + If another property with the same name is defined, the method or field or constructor argument is added to the existing property.
-
-=== @Updated
-
-_Goal:_ Defines method called when a reconfiguration is completed.
-_Target:_ a method (receiving a dictionary in argument)
-
-=== @Bind
-
-_Goal:_ Defines a bind method _Target:_ Method _Attributes:_
-
-* Id: Dependency Id, if the id is already defines in a "@requires " or "@unbind" annotation, it adds this method as a bind method of the already created dependency.
-(optional, default= no id, compute an id if the method name begin by "bind" (for instance "bindFoo" will have the "Foo" id))
-* Specification : required dependency (optional)
-* Aggregate : is the dependency an aggregate dependency (optional, default= "false")
-* Optional: is the dependency an optional dependency (optional, default= "false")
-* Filter: dependency LDAP filter (optional)
-* Policy: defines the binding policy (optional)
-* Comparator: defines the comparator to use to sort service references (optional, default = OSGi Service Reference Comparator)
-* From : defines the specific provider to use
-
-=== @Unbind
-
-_Goal:_ Defines an unbind method _Target:_ Method _Attributes:_
-
-* Id: Dependency Id, if the id is already defines in a "@requires" or "@bind" annotation, it adds this method as an unbind method of the already created dependency.
-(optional, default= no id, compute an id if the method name begin by "unbind" (for instance "unbindFoo" will have the "Foo" id))
-* Specification : required dependency (optional)
-* Aggregate : is the dependency an aggregate dependency (optional, default= "false")
-* Optional: is the dependency an optional dependency (optional, default= "false")
-* Filter: dependency LDAP filter (optional)
-* Policy: defines the binding policy (optional)
-* Comparator: defines the comparator to use to sort service references (optional, default = OSGi Service Reference Comparator)
-* From : defines the specific provider to use
-
-=== @Modified
-
-_Goal:_ Defines an `modified` method, called when a bound service is udpated.
-_Target:_ Method _Attributes:_
-
-* Id: Dependency Id, if the id is already defines in a "@requires" or "@bind" annotation, it adds this method as an unbind method of the already created dependency.
-(optional, default= no id, compute an id if the method name begin by "unbind" (for instance "unbindFoo" will have the "Foo" id))
-* Specification : required dependency (optional)
-* Aggregate : is the dependency an aggregate dependency (optional, default= "false")
-* Optional: is the dependency an optional dependency (optional, default= "false")
-* Filter: dependency LDAP filter (optional)
-* Policy: defines the binding policy (optional)
-* Comparator: defines the comparator to use to sort service references (optional, default = OSGi Service Reference Comparator)
-* From : defines the specific provider to use
-
-=== @Validate
-
-_Goal:_ defines a validate lifecycle callback _Target:_ method
-
-=== @Invalidate
-
-_Goal:_ defines a validate lifecycle callback _Target:_ method
-
-=== @PostRegistration
-
-_Goal:_ defines a callback invoked after service registration.
-The callback must have the following signature : `public void name(ServiceReference ref)` _Target:_ method
-
-=== @PostUnregistration
-
-_Goal:_ defines a callback invoked after service unregistration.
-The callback must have the following signature : `public void name(ServiceReference ref)` _Target:_ method
-
-=== @Instantiate
-
-_Goal:_ declare a simple instance (this is equivalent to `+<instance component="..."></instance>+` _Target:_ class _Attribute:_
-
-* name: the instance name (optional)
-
-=== Temporal Dependencies (external handler)
-
-The temporal dependency handler is an external handler.
-However, it can be used with an annotation defined in the iPOJO annotations jar file.
-The annotation is `org.apache.felix.ipojo.handler.temporal.Requires` and targets a field.
-_Attributes:_
-
-* filter : specify the dependency filter
-* timeout : specify the dependency timeout (optional)
-* onTimeout : specify the onTimeout action (null, nullable, empty-array, default-implementation (specify the class name in this case) (optional).
-* specification : the required service specification.
-This attribute is required for Collection field.
-(optional, default = annotated field type).
-* proxy : Inject a proxy instead of the real object.
-This allows passing this reference to collaborators.
-(Default = false)
-
-=== Exposing instances as a JMX MBean (external handler)
-
-The JMX Handler allows exposing an instance as a JMX MBean.
-To configure the JMX handler directly from your code, three annotations are provided.
-They are in the `org.apache.felix.ipojo.handlers.jmx` package
-
-The `@org.apache.felix.ipojo.handlers.jmx.Config` (`@Config` if the package it correctly imported) annotation is a type annotation (so placed on the `class` element.
-This annotation indicates that the instance will be exposed as an MBean.
-This annotation supports:
-
-* usesMOSGi: set to `true` to use MOSGi.
-Otherwise, the MBean will be exposed in the MBean Platform Server (default: `false`).
-* objectname: set the MBean objectname.
-The objectname must follow JMX specification.
-(default: `package-name:factory-name:instance-name`)
-* domain: set the MBean domain.
-(default: `package-name`)
-* name: set the MBean name.
-(default: `instance-name`).
-
-The `@org.apache.felix.ipojo.handlers.jmx.Property` (`@Property`) annotation is a field annotation indicating that the field is exposed in the MBean.
-The supported attributes are:
-
-* name: set the property name
-* rights: set the access permission.
-Possible values are `r` (read only) and `w` (read and write).
-By default, properties are in read-only mode.
-* notification: enables notification on this property.
-By default notifications are disabled.
-
-The `@org.apache.felix.ipojo.handlers.jmx.Method` (`@Method`) annotation is a method annotation indicating that the method is exposed in the MBean.
-Only one attribute can be customized:
-
-* description: set the method description.
-
-== Advanced topics and FAQ
-
-=== Metadata file and annotation merge
-
-It is possible to defines component type both in the metadata file (in XML) and by using annotation.
-However, if a component type defined by using annotations has the same name than a type define in the XML file, the XML descriptor override the annotation defined type.
-However, a warning message is launched during the manipulation.
-
-=== Instance creation
-
-The @Instantiate annotation allows creating an instance, but this declaration is limited:
-
-* it does not support configuration
-* it does not allow naming
-* the instance is created in the global scope (so no composition)
-
-To define instances, you should use the XML descriptor.
-Instance can refer to annotated types by referring to their names.
-
- ::xml
- <instance component="ipojo.example.hello.impl.HelloImpl"/>
- <instance component="AnnotedHelloClient"/>
-
-=== Using Custom Annotations
-
-External handlers can provides their own annotations.
-Using these annotations just requires to add them to your build path.
-To external handlers annotations, please refer to the external handler documentation.
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/ipojo-advanced-tutorial.adoc b/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/ipojo-advanced-tutorial.adoc
deleted file mode 100644
index 78c8333..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/ipojo-advanced-tutorial.adoc
+++ /dev/null
@@ -1,602 +0,0 @@
-= iPOJO Advanced Tutorial: The iPOJO Snack Bar
-
-_This tutorial illustrates some advanced features of iPOJO_
-
-
-
-== Context
-
-This tutorial is based on a very simple application;
-customers are using a vendor service to buy hot dog or pop corn according to the availability of appropriate providers.
-Both of the vendors implement (and provide) the vendor service.
-The hot dog vendor depends on two others services to get the ingredients (buns and wiener).
-To sell pop corn, the pop corn vendor requires having enough corn in stock.
-
-image::documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/vendor.png[]
-
-== Preparing the tutorial
-
-The tutorial archive is available http://people.apache.org/~clement/ipojo/tutorials/advanced/advanced.tutorial.zip[here].
-This archive contains both the source code and a pre-configured version of Felix.
-First, unzip the archive.
-Then, launch `ant` to compile the bundles composing this tutorial.
-Once compiled, you can launch Felix and start the tutorial.
-To launch, Felix launch the following command from the `felix` directory:
-
-[source,sh]
- java -jar bin/felix.jar
-
-== Writing a component providing two services
-
-The sources of this project are inside the _vendor.buns-and-wieners_ directory.
-The hot dog vendor requires at the same time the bun service and the wiener service.
-In our application these services are provided by the same component.
-This component can be implemented as follows (src\org\apache\felix\ipojo\example\vendor\provider\BunWienerProvider.java):
-
-[source,java]
-----
-public class BunWienerProvider implements BunService, WienerService {
-
- public void getBun() {
- System.out.println("Get a bun");
- }
-
- public void getWiener() {
- System.out.println("Get a wiener");
- }
-}
-----
-
-This class just implements the two service interfaces.
-Its descriptor (contained in the metadata.xml file) is:
-
-[source,xml]
-----
-<ipojo>
-<component
- classname="org.apache.felix.ipojo.example.vendor.provider.BunWienerProvider"
- name="buns_and_wieners" public="false">
- <provides/>
-</component>
-
-<instance component="buns_and_wieners"/>
-</ipojo>
-----
-
-In the descriptor, we declare a component type for this vendor which contains the implementation class.
-The `classname` attribute contains the qualified name of the component implementation.
-The "name" attribute is the component type name.
-It is only used to refer to this type.
-
-The `public=false` attribute disables factory exposition.
-A component type publishing a factory provides a way to create instance of this type from outside this descriptor.
-In our case, we want to guarantee that only one instance (singleton) can be created, so we disable the factory mechanism.
-
-iPOJO manages service publication and providing automatically at runtime.
-The `<provides/>` element means that the component provides services.
-If this element is not present, iPOJO will publish all implemented interfaces by the implementation class (and parent class too).
-In our case, it will publish the BunService and WienerService interfaces.
-
-Finally, we create one instance of our component.
-The instance contains the component attribute describing the component type to use.
-We use the component type name to target the wanted component type.
-
-At runtime, the bundle containing this component will create an instance which provides the BunService and the WienerService.
-
-== Publishing service properties
-
-The sources of this project are inside the _vendor.hotdog_ directory.
-The hot dog vendor only provides the Vendor service.
-To provide this service, it uses a bun service and a wiener service.
-The following code (contained in the _src/org/apache/felix/ipojo/example/vendor/hotdog/HotDogVendor.java_ file) shows a very simple implementation of this component:
-
-[source,java]
- public class HotDogVendor implements Vendor {
-
- /**
- * Bun provider (required service).
- */
- private Bun bunProvider;
-
- /**
- * Wiener provider (required service).
- */
- private Wiener wienerProvider;
-
- /**
- * Sell method.
- * To provide an hotdog, the vendor consume a bun and a wiener.
- * This method is synchronized to avoid serving to client
- * at the same time.
- * @return a hotdog.
- * @see org.apache.felix.ipojo.example.vendor.service.Vendor#sell()
- */
- public synchronized Product sell() {
- bunProvider.getBun();
- wienerProvider.getWiener();
- return new HotDog();
- }
-
-Once implemented, we need to describe this component type.
-The descriptor file is the _metadata.xml_ file.
-The field attributes in the "requires" elements are used to inject the required services.
-At runtime, iPOJO injects automatically a BunService provider in the "bunProvider" field and a WienerService provider in the "wienerProvider" field.
-The implementation uses these fields the same way it would have used any other fields (as illustrated in the sell method).
-
-[source,xml]
-----
-<ipojo>
-<component
- classname="org.apache.felix.ipojo.example.vendor.hotdog.HotDogVendor"
- name="HD" public="false">
- <provides/>
- <requires field="bunProvider"/>
- <requires field="wienerProvider"/>
-</component>
-
-<instance component="HD"/>
-</ipojo>
-----
-
-The component type declares a provided service (the Vendor Service).
-Then, the component declares the two service dependencies (using the "requires" element).
-However, we would like to add a service property on the Vendor service describing the sold product (here, "hotdog").
-To achieve this, we just need to add a property element in the "provides" tags:
-
-[source,xml]
-----
-<ipojo>
-<component
- classname="org.apache.felix.ipojo.example.vendor.hotdog.HotDogVendor"
- name="HD" public="false">
- <provides>
- <property name="product" type="string" value="hotdog"/>
- </provides>
- <requires field="bunProvider"/>
- <requires field="wienerProvider"/>
-</component>
-
-<instance component="HD"/>
-</ipojo>
-----
-
-iPOJO then publishes the "product" property in the "vendor" service registration.
-This property has the "hotdog" value.
-
-== Publishing 'dynamic' properties
-
-The bun service and the wiener service can also expose service properties.
-In our case, these service properties will describe the stock of ingredients.
-Each time the service is used, the property value is decreased.
-To achieve this, we modify the current implementation to add a field representing the property:
-
-[source,java]
-----
-public class BunWienerProvider implements BunService, WienerService {
-
- private int bunStock;
-
- private int wienerStock;
-
- public synchronized void getBun() {
- bunStock = bunStock - 1;
- }
-
- public synchronized void getWiener() {
- wienerStock = wienerStock - 1;
- }
-}
-----
-
-The stock accesses are synchronized to avoid multiple accesses at the same time.
-The component type metadata must also be modified in order to describe this property:
-
-[source,xml]
-----
-<ipojo>
-<component
- classname="org.apache.felix.ipojo.example.vendor.provider.BunProvider"
- name="buns_and_wieners" public="false">
- <provides>
- <property name="buns" field="bunStock" value="10"/>
- <property name="wieners" field="wienerStock" value="10"/>
- </provides>
-</component>
-
-<instance component="buns_and_wieners"/>
-</ipojo>
-----
-
-In the `provides` element, two properties are added.
-This property contains a `field` attribute aiming to attach the service property with a field of the implementation class.
-Then a default value is given.
-In the code, the property fields will obtain the initial value (10).
-Then each time the fields are modified, the service property is updated (as well as the OSGi™ service registration).
-Notice that iPOJO support method injection for property too.
-In this case, a getter method is called to inject the property value.
-
-== Configuring instances
-
-In the previous example, the properties were configured in the component type description.
-It is also possible to customize any property value in the instance declaration.
-This way, each instance can obtain different values.
-
-[source,xml]
-----
-<ipojo>
-<component
- classname="org.apache.felix.ipojo.example.vendor.provider.BunProvider"
- name="buns_and_wieners" public="false">
- <provides>
- <property name="buns" field="bunStock" value="10"/>
- <property name="wieners" field="wienerStock" value="10"/>
- </provides>
-</component>
-
-<instance component="buns_and_wieners">
- <property name="buns" value="9"/>
- <property name="wieners" value="8"/>
-</instance>
-</ipojo>
-----
-
-The previous metadata shows how to push a configuration in instance declarations.
-The instance declaration contains two property elements containing the name of the value of the property.
-Instance configuration override component type initial value.
-Properties are optional by default ; that's means that they do not need to receive a value.
-In this case, default values are the same as the Java default fields values (boolean : false, int : 0, double : 0.0d, ...).
-You can specify that a property must receive a default value from either the component type description or the instance configuration by setting the `mandatory` attribute to `true`.
-
-== Using filter in service requirements
-
-Now that bun and wiener providers publish their remaining stock, the hot dog provider can look for a bun service and a wiener service with a non empty stock.
-To achieve this, we must describe an LDAP filter in the service requirement description.
-The following XML snipped shows this metadata:
-
-[source,xml]
-----
-<ipojo>
-<component
- classname="org.apache.felix.ipojo.example.vendor.hotdog.HotDogVendor"
- name="HD" public="false">
- <provides>
- <property name="product" type="string" value="hotdog"/>
- </provides>
- <requires field="bunProvider" filter="(buns>=1)"/>
- <requires field="wienerProvider" filter="(wieners>=1)"/>
-</component>
-
-<instance component="HD"/>
-</ipojo>
-----
-
-When a provider does no more matches with the LDAP filter, the provider is no more used, and another (matching with the filter) is tracked.
-If no provider fulfilling the constraint is found, the instance becomes invalid and waits a matching provider.
-
-*Instance invalidation and services* + When an instance becomes invalid, all its provided services are withdrawn from the service registry.
-So, this instance is no more *accessible* from the service registry.
-
-== Immediate component instance
-
-Now that we get the hot dog provider, we are going to implement customers.
-Customers are implemented in the _vendor.customer_ project).
-A customer simply looks for a vendor service and buys a product:
-
-[source,java]
- public class Customer {
-
- private VendorService vendor;
-
- private String name;
-
- public Customer() {
- System.out.println("Customer " + name + " bought "
- + vendor.sell() + " from " + vendor.getName());
- }
-
-The previous code shows a possible implementation of a customer.
-However, the "sell" method is called in a constructor, and the constructor can only be called only if an object of the class is created.
-With iPOJO there are two different way to "activate" an instance as soon as it becomes valid.
-
-The first one uses the lifecycle callback (described in the previous tutorial).
-The second one is by declaring the component as an immediate component.
-An immediate component instance creates an object of its implementation as soon as it becomes valid.
-[source,xml]
- <ipojo>
- <component
- classname="org.apache.felix.ipojo.example.vendor.customer.Customer"
- name="customer" immediate="true">
- <requires field="vendor"/>
- <properties>
- <property field="name"/>
- </properties>
- </component>
- </ipojo>
-
-To declare a component immediate, just add `immediate=true` in the component descriptor.
-Then as soon as the vendor service is available, the object is created.
-Moreover, this type declares a property (to give a name to the customers).
-This property is not a service property, but just an internal property.
-As for service properties, the name field will be injected by a value necessary given during the instance creation (i.e.
-contained inside the instance configuration).
-
-By default, all all components that do not provide any service are immediate.
-Other components create call their constructors when they are used for the first time.
-
-*Difference between 'validate' and 'immediate'* + There is a difference between immediate components and components with a `validate` lifecycle callback.
-Indeed, the callback is call at each time the instance becomes valid and calls the constructor only if no object already exists.
-On the other side, the immediate component's constructor is call only once.
-
-== Creating instances from an external component type
-
-In the previous section we have declared a customer component type, which does not have the `public=false` attribute.
-This feature allows separate deployment from instance creation.
-Moreover, we didn't declare instances in the descriptor.
-
-Another metadata file can be used to declare instances from the customer type, this descriptor being contained in another bundle.
-The following descriptor creates 10 customer instances (look at the _vendor.customer.creator\metadata.xml_ file):
-[source,xml]
- <ipojo>
- <instance component="customer">
- <property name="name" value="customer-1"/>
- </instance>
- <instance component="customer">
- <property name="name" value="customer-2"/>
- </instance>
- <instance component="customer">
- <property name="name" value="customer-3"/>
- </instance>
- <instance component="customer">
- <property name="name" value="customer-4"/>
- </instance>
- <instance component="customer">
- <property name="name" value="customer-5"/>
- </instance>
- <instance component="customer">
- <property name="name" value="customer-6"/>
- </instance>
- <instance component="customer">
- <property name="name" value="customer-7"/>
- </instance>
- <instance component="customer">
- <property name="name" value="customer-8"/>
- </instance>
- <instance component="customer">
- <property name="name" value="customer-9"/>
- </instance>
- <instance component="customer">
- <property name="name" value="customer-10"/>
- </instance>
- </ipojo>
-
-Once deployed, this bundle looks for the required factory.
-If it's not available the bundle waits for the factory.
-As soon as the required factory is available, all instances are created.
-When this bundle is stopped, all instances are destroyed.
-
-== Deploying the application
-
-Compile the bundles, by launching ant at the root of the tutorial.
-Then launch Felix is indicated above.
-Once started, launch the following commands
-
-[source,sh]
- start file:../vendor.services/output/vendor.services.jar
- start file:../vendor.buns-and-wieners/output/vendor.buns-and-wieners.jar
- start file:../vendor.hotdog/output/vendor.hotdog.jar
- start file:../vendor.customer/output/vendor.customer.jar
- start file:../vendor.customer.creator/output/vendor.customer.creator.jar
-
-Something like this should appear:
-
-[source,sh]
- Customer customer-1 bought Hotdog from Fenway Park
- Customer customer-2 bought Hotdog from Fenway Park
- Customer customer-3 bought Hotdog from Fenway Park
- Customer customer-4 bought Hotdog from Fenway Park
- Customer customer-5 bought Hotdog from Fenway Park
- Customer customer-6 bought Hotdog from Fenway Park
- Customer customer-7 bought Hotdog from Fenway Park
- Customer customer-8 bought Hotdog from Fenway Park
-
-Only 8 customers can buy a hot-dog, as the stock of wieners and buns can't supply more hot-dog.
-The remainder of this tutorial will try to solve the problem of these two hungry customers.
-
-== Using the lifecycle controller
-
-Sometimes you want to invalidate your instance in the code (for example: to unregister a service).
-That's possible with the lifecycle controller handler.
-Let's take the popcorn vendor with a corn stock from the _vendor.popcorn_ project.
-Each time it sells some popcorn, its stock is decreased.
-When the stock reaches 0, it cannot sell popcorns any more (so the vendor service needs to be withdrawn).
-
-The following implementation (_src\org\apache\felix\ipojo\example\vendor\popcorn\PopCornVendor.java_) uses a field to control the lifecycle.
-
-[source,java]
-----
-/**
- * The corn stock.
- */
-private int m_corn_stock;
-
-/**
- * Lifecycle controller.
- * If set to false, the instance becomes invalid.
- */
-private boolean m_can_sell = true;
-
-/**
- * The sell method.
- * To provide popcorn, the vendor needs to decrease its corn stock level.
- * This method is synchronized to avoid to client being serve at
- * the same time.
- * @return
- * @see org.apache.felix.ipojo.example.vendor.service.Vendor#sell()
- */
-public synchronized Product sell() {
- m_corn_stock--;
- if (m_corn_stock == 0 && m_can_sell) { // Last pop corn
- m_can_sell = false;
- System.out.println("Stop selling popcorn
- ... Run out of stock");
- return new PopCorn();
- } else if (m_corn_stock > 0) { // Normal case
- return new PopCorn();
- } else { // Cannot serve.
- return PopCorn.NO_MORE_POPCORN;
- }
-}
-----
-
-Once the field is set to "false", the instance is invalidated (the vendor service is no more available).
-To configure the controller, you can use the following metadata:
-
-[source,xml]
-----
-<ipojo>
-<component
- classname="org.apache.felix.ipojo.example.vendor.popcorn.PopCornVendor"
- name="popcorn" public="false" architecture="true">
- <provides/>
- <controller field="m_can_sell"/>
-</component>
-
-<instance component="popcorn"/>
-</ipojo>
-----
-
-The instance can be re-validated by setting the field to true.
-So, no deploy the pop corn vendor.
-
-[source,sh]
- -> start file:../vendor.popcorn/output/vendor.popcorn.jar
- Customer customer-10 bought popcorn from D & P
- Customer customer-9 bought popcorn from D & P
-
-Our two last customers are no more hungry.
-However, new customers arrives, we have the following situation:
-
-[source,sh]
- -> update 10
- Customer customer-1 bought popcorn from D & P
- Customer customer-2 bought popcorn from D & P
- Stop selling popcorn ... Run out of stock
- Customer customer-3 bought popcorn from D & P
-
-To recreate new customers, just update the customer.creator bundle (bundle 10).
-So, now we have 7 customers hungry!
-There is neither popcorn nor hotdog!
-
-== Reconfiguring an instance
-
-OSGi specified the Configuration Admin mechanism aiming to handler service and bundle configuration.
-This section will describe how you can use the Configuration Admin and iPOJO to add corn inside our popcorn vendor.
-First, we will change the pop corn vendor to add a method reinjecting the new stock:
-
-[source,java]
- /**
- * A transporter refills the stock of corn.
- * This method is synchronized to avoid to client being served
- * during the update.
- * @param newStock : the stock of corn to add to the current stock.
- */
- public synchronized void refillStock(int newStock) {
- m_corn_stock += newStock;
- System.out.println("Refill the stock : " + m_corn_stock);
- if (m_corn_stock > 0) {
- m_can_sell = true;
- }
- }
-
-Once added, we need to update the component type descriptor to use this method:
-
-[source,xml]
-----
-<ipojo>
-<component
- classname="org.apache.felix.ipojo.example.vendor.popcorn.PopCornVendor"
- name="popcorn" architecture="true">
- <provides/>
- <controller field="m_can_sell"/>
- <properties>
- <property name="stock" method="refillStock" value="5"/>
- </properties>
-</component>
-
-<instance component="popcorn" name="SuperPopCorn">
- <property name="managed.service.pid" value="Super.PopCorn.Stock"/>
-</instance>
-</ipojo>
-----
-
-We add two different things.
-First we add a "stock" property attached to the _refillStock_ method.
-When this instance is configured or reconfigured, this method is called to push the new stock value.
-Then we add the _managed.service.pid_ property inside the instance creation.
-This property will be used by the Configuration Admin to attach configuration to instances.
-The property value must be unique.
-So now, our popcorn vendor can be reconfigured dynamically to get increments its corn stock.
-However, we need to create something refilling the stock ...
-a corn transporter !
-
-Inside the _vendor.corn.transporter_ project, we have a component dealing with the ConfigurationAdmin to push the new pop corn vendor configuration.
-The implementation is contained in the _src\org\apache\felix\ipojo\example\vendor\corn\transporter\CornTransporter.java_ file.
-
-[source,java]
- public class CornTransporter {
-
- private ConfigurationAdmin m_configAdmin;
-
-
- /**
- * Reconfigure the popcorn vendor with the configuration admin.
- */
- public void refillStock() {
- try {
- // Retrieve or Create the instance configuration
- // from the configuration admin
- Configuration configuration =
- m_configAdmin.getConfiguration("Super.PopCorn.Stock",
- "file:../vendor.popcorn/output/vendor.popcorn.jar");
- configuration.setBundleLocation(
- "file:../vendor.popcorn/output/vendor.popcorn.jar");
- Properties props = new Properties();
- props.put("stock", new Integer(15)); // Delivered corn
- configuration.update(props);
- System.out.println("Update the configuration of "
- + configuration.getPid() + "("
- + configuration.getBundleLocation() + ")");
- configuration.delete();
- } catch (IOException e) {
- e.printStackTrace();
- }
- }
- }
-
-Create a new configuration from the configuration admin and configure this configuration to add corn.
-Then, we update this configuration.
-This will reconfigured our popcorn vendor.
-More information on the Configuration Admin is available in the OSGi R4 Compendium.
-
-So, now if we deploy this bundle, we will provide enough corn to feed all the customers:
-
-[source,sh]
- -> start file:../vendor.corn.transporter/output/vendor.corn.transporter.jar
- Update configuration of Super.PopCorn.Stock(
- file:../vendor.popcorn/output/vendor.popcorn.jar)
- Refill the stock : 5
- Customer customer-10 bought popcorn from D & P
- Customer customer-9 bought popcorn from D & P
- Customer customer-8 bought popcorn from D & P
- Customer customer-7 bought popcorn from D & P
- Customer customer-6 bought popcorn from D & P
- Customer customer-5 bought popcorn from D & P
- Customer customer-4 bought popcorn from D & P
-
-That's it!
-
-== Conclusion
-
-This small tutorial has presented some of of the iPOJO features.
-Subscribe to the Felix users mailing list by sending a message to link:mailto:users-subscribe@felix.apache.org[users-subscribe@felix.apache.org];
-after subscribing, email questions or feedback to link:mailto:users@felix.apache.org[users@felix.apache.org].
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/ipojo-composition-tutorial.adoc b/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/ipojo-composition-tutorial.adoc
deleted file mode 100644
index e2f00f6..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/ipojo-composition-tutorial.adoc
+++ /dev/null
@@ -1,620 +0,0 @@
-= iPOJO Composition Tutorial
-
-_This page describes how works the composition mechanisms provided by iPOJO and how to use it.
-this feature allows you to design applications that will natively support the dynamism and the evolution._
-
-
-
-== Why providing a composition layer?
-
-iPOJO aims to simplify the creation of OSGi (dynamic) applications.
-Creating such as applications is basically a two steps process:
-
-* Developing services and components
-* Assembling them together to create the application
-
-To tackle the first step, iPOJO provides an easy-to-use development model.
-But, this does not help to design the application.
-To conduct the second step, iPOJO provides a composition language allowing to:
-
-* Assemble components and services together
-* Assert service isolation inside a composition
-* Hide/Abstract implementations
-
-=== What about privacy?
-
-Service or component composition has a stringent requirement.
-How to isolate components and services of an application to avoid side effects as an unexpected access to a used service ...iPOJO composites just provide an isolation mechanism.
-Services provided inside a composite ARE NOT published globally (inside the OSGi service registry).
-So, only the component instances living in the same composite can access to those services.
-However, it is also possible to import a service from the parent/global service registry, as well as to export a service to the parent (i.e.
-superior) composite.
-
-== The different types of composition in the OSGi world
-
-Basically there is two types of composition in OSGi:
-
-* The intra-bundle composition
-* The service-based composition
-
-=== Intra-bundle composition
-
-The intra-bundle composition is the policy followed by Spring-DM.
-Each bundle contains components.
-These components can require and provide services from the global (OSGi) registry.
-Moreover, these components can collaborate together inside the bundle without providing/requiring services.
-So the isolation scope of intra-bundle composition is the _bundle_.
-This type of composition allows providing coarse-grain services provided by the collaboration of several components.
-However, it is not possible to update one of those components, as the update unity is the bundle.
-
-=== Service-based composition
-
-There are two types of service composition.
-The behavioral service composition is like http://www.ibm.com/developerworks/library/specification/ws-bpel/[BPEL] for the web services.
-An orchestrator supervises the execution and the collaboration of services like:
-
-. Call service A
-. Call service B
-. ...
-
-The second type of service composition is the structural service composition.
-This aims to provide a kind of Architecture Description Language for service-based applications.
-iPOJO follows this trend.
-This way as several advantages:
-
-* Avoids coupling a composition to specific implementation, and so it supports the dynamic substitution
-* Allows the evolution of used services and components at runtime
-
-This is also the way followed by http://www.ibm.com/developerworks/library/specification/ws-sca/[SCA].
-However, SCA does not specify how the dynamism should be handled.
-
-== The iPOJO composition theory for the dummies
-
-The distinction between component types and instances When you declare a `<component>` (or a `<composite>`) in your metadata, you're declaring a component type.
-Then you declare instances from these component types.
-This mechanism is critic for the iPOJO composition.
-Indeed, inside a composite, you're able to create instances from any (public) component types (Refer to the xref:documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/ipojo-advanced-topics/how-to-use-ipojo-factories.adoc[Factory] web page for further details).
-On the top of this mechanism, we can define the concept of service implementation.
-A service implementation is just a component type where the instances provide a service.
-For example, if the instance from a component type provides the service S, the component type is a service implementation of S, and so can be used to create a provider of S.
-
-== The service context concept
-
-The service context is the concept allowing service isolation.
-OSGi bundle context allows accessing both to bundle-based functionality (like `loadClass`) and to the service registry.
-However, OSGi defines only one service registry, accessible by any bundles.
-iPOJO splits these two interaction types.
-Instances receive an iPOJO Bundle Context delegating bundle-related methods to the "regular" bundle context, and service-related methods to a service context.
-This service context can access to the OSGi service registry or to a new one.
-Each composition instances have a service registry.
-Instances creates inside the composition used this service registry through received the iPOJO Bundle Context.
-
-== Downloads
-
-Download the http://people.apache.org/~clement/ipojo/tutorials/composite/composite-tutorial.zip[archive].
-This archive contains:
-
-* The different applications and component types implemented in this tutorial
-* A preconfigured version of Felix
-* Deployment scripts
-
-Launch `ant` from the base directory of the unzipped archive to create every bundles.
-Then, you can test the different examples by copying and pasting commands from the `script.txt` file (in the felix folder) in the Felix shell.
-
-== Let's start with a first composition
-
-In the xref:documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/ipojo-in-10-minutes.adoc[iPOJO in 10 minutes] tutorial, we created an application checking a sentence against dictionaries.
-We'll reuse this simple application in this tutorial.
-So first, we need to implements several component types:
-
-* The dictionary service implementation, containing words
-* The Check service implementation, providing methods to check words against dictionaries
-* And the client GUI, using a Check Service to indicate misspelled words.
-
-We will reuse the same implementation than in the previous tutorial.
-The current application is designed as follow:
-
-image::documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/app1.png[]
-
-However, imagine that you want to isolate services provided and required by your application.
-For example, you want to isolate a stateful service or a critical (private) resource.
-
-So, let's imagine a second version of our spellchecker application.
-In this application, the dictionary service, and the checker service are isolated inside a composite.
-So, those services will be accessible only from instances living in the composite.
-The GUI will also be instantiated inside the composite.
-The composition will be something like:
-
-image::documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/app2.png[]
-
-The descriptor of this application is:
-
-[source,xml]
-----
-<ipojo>
-
-<!-- Declares a composition -->
-<composite name="composition1">
- <!-- Instantiates an instance of the English dictionary -->
- <instance component="spell.english.EnglishDictionary"/>
-
- <!-- Instantiates an instance of the Checker -->
- <instance component="spell.checker.SpellCheck"/>
-
- <!-- Instantiates an instance of the GUI -->
- <instance component="spell.gui.SpellCheckerGui"/>
-</composite>
-
-<!-- Instantiates an instance of our composition -->
-<instance component="composition1"/>
-
-</ipojo>
-----
-
-First, a composite type is declared inside an iPOJO descriptor.
-A composite contain always a `name` attribute, which is the component type name.
-Inside the `<composite></composite>`, three instances are declared: the three instances used by our application.
-Remark that these instances are declared as 'regular' instances.
-The `component` attribute indicates the component type to use.
-Instances can be configured as regular iPOJO instances.
-Finally, an instance of our type is also declared.
-
-To execute our composition, go in the felix directory and launch the following command:
-
-[source,sh]
- java -jar bin/felix.jar
-
-This version of Felix starts with the iPOJO framework, the iPOJO Arch command and the composite support.
-So, we just need to install our component types and the composition.
-
-In the Felix prompt, launch the following commands:
-
-[source,sh]
- start file:../spell.services/output/spell.services.jar
- start file:../spell.english/output/spell.english.jar
- start file:../spell.checker/output/spell.checker.jar
- start file:../spell.checker.gui/output/spell.checker.gui.jar
-
-Those commands deploy the component types.
-Remark that no 'functional' (i.e.
-neither Check service, nor Dictionary service) services are provided.
-Deployed bundles provide only iPOJO Factory services:
-
-[source,sh]
- -> inspect s c
- System Bundle (0) provides:
- ---------------------------
- org.osgi.service.startlevel.StartLevel
- org.osgi.service.packageadmin.PackageAdmin
- Apache Felix Shell Service (1) provides:
- ----------------------------------------
- ...
- Apache Felix Bundle Repository (3) provides:
- --------------------------------------------
- org.osgi.service.obr.RepositoryAdmin
- iPOJO (4) provides:
- -------------------
- ...
- iPOJO Composite (6) provides:
- -----------------------------
- ...
- spell.english (8) provides:
- ---------------------------
- org.apache.felix.ipojo.Factory, org.osgi.service.cm.ManagedServiceFactory
- spell.checker (9) provides:
- ---------------------------
- org.apache.felix.ipojo.Factory, org.osgi.service.cm.ManagedServiceFactory
- spell.checker.gui (10) provides:
- -------------------------------
- org.apache.felix.ipojo.Factory, org.osgi.service.cm.ManagedServiceFactory
-
-Now, when can deploy our composition:
-
-[source,sh]
- start file:../example1/output/composition1.jar
-
-Once deployed and started, the fancy GUI appears:
-
-image::documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/ss-comp.png[]
-
-Now, you can check that the functional services are not unavailable outside the composite:
-
-[source,sh]
- -> inspect s c
- System Bundle (0) provides:
- ---------------------------
- org.osgi.service.startlevel.StartLevel
- org.osgi.service.packageadmin.PackageAdmin
- Apache Felix Shell Service (1) provides:
- ----------------------------------------
- ...
- Apache Felix Bundle Repository (3) provides:
- --------------------------------------------
- org.osgi.service.obr.RepositoryAdmin
- iPOJO (4) provides:
- -------------------
- ...
- iPOJO Composite (6) provides:
- -----------------------------
- ...
- spell.english (8) provides:
- ---------------------------
- org.apache.felix.ipojo.Factory, org.osgi.service.cm.ManagedServiceFactory
- spell.checker (9) provides:
- ---------------------------
- org.apache.felix.ipojo.Factory, org.osgi.service.cm.ManagedServiceFactory
- spell.checker.gui (10) provides:
- -------------------------------
- org.apache.felix.ipojo.Factory, org.osgi.service.cm.ManagedServiceFactory
- Bundle 11 provides:
- -------------------
- org.apache.felix.ipojo.Factory, org.osgi.service.cm.ManagedServiceFactory
-
-Of course, if you stop a bundle providing a required service type, the application is stopped:
-
-[source,sh]
- -> stop 8
- -> start 8
-
-Then, the application also supports component type update.
-However the component type name must not change.
-We will see later how we can avoid this issue by abstracting implementations.
-
-== Importing a service inside a composite
-
-Let's imagine a second version of the checker service implementation (spell.checker-v2).
-This implementation removes the trace when wrong words are detected.
-Indeed, this implementation uses a log service to store such kind of errors.
-
-If we use this implementation, we need to make a log service available inside the composite.
-Else, the checker will not be valid.
-To achieve this, use the following composite:
-
-[source,xml]
-----
-<ipojo>
-
-<!-- Declares a composition -->
-<composite name="composition2">
- <!-- Instantiates an instance of the English dictionary -->
- <instance component="spell.english.EnglishDictionary"/>
-
- <!-- Instantiates an instance of the Checker -->
- <instance component="spell.checker.SpellCheck"/>
-
- <!-- Instantiates an instance of the GUI -->
- <instance component="spell.gui.SpellCheckerGui"/>
-
- <!-- Imports the log service -->
- <subservice action="import"
- specification="org.osgi.service.log.LogService"/>
-</composite>
-
-<!-- Instantiates an instance of our composition -->
-<instance component="composition2"/>
-
-</ipojo>
-----
-
-This composite just adds a `subservice` nested element.
-This subservice allows importing a service inside the composite.
-The `action` attribute specifies that we want to import the service from the parent scope (i.e.
-superior).
-The `specification` attribute indicates the required service.
-
-image::documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/app3.png[]
-
-Now, relaunch Felix and enter another profile name (`composition2` for example).
-Once started, executes the following commands:
-
-[source,sh]
- start file:../spell.services/output/spell.services.jar
- start file:../spell.english/output/spell.english.jar
- start file:../spell.checker-v2/output/spell.checker-v2.jar
- start file:../spell.checker.gui/output/spell.checker.gui.jar
- start file:../example2/output/composition2.jar
-
-Those commands deploy required component type (note that we deploy spell.checker-v2) and an implementation of the OSGi Log Service.
-When you execute the last command, the fancy interface re-appears.
-
-Try to enter a wrong word (as `composite`), and click on the check button.
-The trace does no more appear...
-the message is logged inside the log service.
-Of course, such composite support dynamism.
-Try the following scenario
-
-[source,sh]
- stop 9
- start 9
- stop 10
- start 10
-
-When the log service is stopped, the GUI disappears.
-In fact, the service can no more be imported, and so, the composition becomes invalid.
-When you stop a bundle containing a used component type, the same behavior occurs.
-
-Like in the previous example, you can check that only the log service is globally available.
-Other services are isolated inside the composite.
-In this case the parent scope is the OSGi service registry, but composite can also contain other composite.
-In such context, the import tracks services from the superior composite.
-An example of hierarchical composition is described later in this tutorial.
-
-*Service Resolution*
-
-== Abstracting implementation... Composing services
-
-We saw in the first composition that we depend on specific component types.
-This can be avoided by specifying the composition in term of services instead of component types.
-So, every available service implementation can be used.
-Moreover, if the used one disappears, another one can be immediately used to replace the missing service.
-Let's illustrate this.
-
-In the first composition, we create an instance of the English dictionary service implementation.
-We can remove this coupling to this specific implementation.
-To do this, we will target any implementation of the dictionary service regardless the language.
-
-[source,xml]
-----
-<ipojo>
-
-<!-- Declares a composition -->
-<composite name="composition3">
- <!-- Instantiates an instance of the English dictionary -->
- <subservice action="instantiate"
- specification="spell.services.DictionaryService"/>
-
- <!-- Instantiates an instance of the Checker -->
- <instance component="spell.checker.SpellCheck"/>
-
- <!-- Instantiates an instance of the GUI -->
- <instance component="spell.gui.SpellCheckerGui"/>
-</composite>
-
-<!-- Instantiates an instance of our composition -->
-<instance component="composition3"/>
-
-</ipojo>
-----
-
-The previous composition instantiates a dictionary service.
-This means that the composite looks for an implementation of the Dictionary service and creates an instance of this implementation (i.e.
-component type) inside the composition.
-If several implementations are available, the composite chooses one, and switches to another one if the used implementation becomes unavailable.
-
-image::documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/app4.png[]
-
-To execute this composition, launch Felix and execute the following command:
-
-[source,sh]
- start file:../spell.services/output/spell.services.jar
- start file:../spell.english/output/spell.english.jar
- start file:../spell.checker/output/spell.checker.jar
- start file:../spell.checker.gui/output/spell.checker.gui.jar
- start file:../example3/output/composition3.jar
-
-These commands deploy component types and the composition.
-Only one implementation of the dictionary service is available (English).
-You can check this by executing the `service 8` command.
-
-[source,sh]
- -> inspect s c 9
- spell.english (9) provides:
- ---------------------------
- component.class = spell.english.EnglishDictionary
- component.description = <unknown value type>
- component.properties = <unknown value type>
- component.providedServiceSpecifications = spell.services.DictionaryService
- factory.name = spell.english.EnglishDictionary
- factory.state = 1
- objectClass = org.apache.felix.ipojo.Factory,
- org.osgi.service.cm.ManagedServiceFactory
- service.id = 39
- service.pid = spell.english.EnglishDictionary
-
-Note the `component.providedServiceSpecifications` property indicating provided services.
-Now deploy another implementation of the dictionary service, such as the French dictionary service ☺
-
-[source,sh]
- start file:../spell.french/output/spell.french.jar
-
-Write `welcome` in the GUI and then check.
-The word is correctly spelled.
-Then, stop the bundle providing the English dictionary.
-
-[source,sh]
- stop 9
-
-Write `welcome` in the GUI, and check.
-The word is misspelled!
-Try to write `bienvenue` and check.
-The word is correctly spelled.
-This means that the composite has substitutes the previous English dictionary by the French one.
-This one will be use until it disappears.
-If you stop the bundle containing this implementation, the composite becomes invalid.
-
-== Publishing services
-
-A composition can also provide services.
-iPOJO composites support two methods to provide services :
-
-* The service export: re-export a service from the composite to the parent context
-* The service implementation: the composite computes a delegation scheme to delegate every method of the provided service on internal entities (services and instances)
-
-This section addresses the export.
-Exporting a service is the opposite of the service import.
-It tracks services from the composites to publish it in the parent (superior) context.
-So, let's imagine a fourth version of our application.
-In this application, the GUI is externalized and lives in the global context (i.e.
-OSGi).
-So, the composition exports the spell checker service.
-
-[source,xml]
-----
-<ipojo>
-
-<!-- Declares a composition -->
-<composite name="composition4">
- <!-- Instantiates an instance of the English dictionary -->
- <subservice action="instantiate"
- specification="spell.services.DictionaryService"/>
-
- <!-- Instantiates an instance of the Checker -->
- <instance component="spell.checker.SpellCheck"/>
-
- <!-- Export the SpellChecker service -->
- <provides action="export"
- specification="spell.services.SpellChecker"/>
-</composite>
-
-<!-- Instantiates an instance of our composition -->
-<instance component="composition4"/>
-
-<!-- Instantiates an instance of the GUI in the global context -->
-<instance component="spell.gui.SpellCheckerGui"/>
-
-</ipojo>
-----
-
-In the previous composition, the composite exports the spell checker service.
-Moreover, the GUI is also created but in the global context.
-At runtime, the result will be as following:
-
-image::documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/app5.png[]
-
-The composite published the spell checker service in the OSGi service registry.
-The GUI tracks this service in the OSGi service registry too.
-To execute this composition, launch Felix and execute following the commands:
-
-[source,sh]
- start file:../spell.services/output/spell.services.jar
- start file:../spell.english/output/spell.english.jar
- start file:../spell.checker/output/spell.checker.jar
- start file:../spell.checker.gui/output/spell.checker.gui.jar
- start file:../example4/output/composition4.jar
-
-You can check that the composition exports the service with the following command:
-
-[source,sh]
- -> services 12
- Bundle 12 provides:
- -------------------
- component.description = <unknown value type>
- component.properties = <unknown value type>
- component.providedServiceSpecifications = spell.services.SpellChecker
- factory.name = composition4
- factory.state = 1
- objectClass = org.apache.felix.ipojo.Factory,
- org.osgi.service.cm.ManagedServiceFactory
- service.id = 36
- service.pid = composition4
- ----
- factory.name = composition4
- instance.name = composition4-0
- objectClass = spell.services.SpellChecker
- service.id = 37
-
-So, now you can play with dynamism.
-Stop the bundle containing the Check service implementation.
-The GUI disappears.
-Restart it.
-The GUI reappears.
-Now, stop the bundle containing the GUI implementation.
-The checker service stills available.
-Indeed, the GUI is no more inside the composition, and so stills valid despite the unavailability of the GUI:
-
-[source,sh]
- -> stop 9
- -> start 9
- -> stop 11
- -> inspect s c 12
- Bundle 12 provides:
- -------------------
- component.description = <unknown value type>
- component.properties = <unknown value type>
- component.providedServiceSpecifications = spell.services.SpellChecker
- factory.name = composition4
- factory.state = 1
- objectClass = org.apache.felix.ipojo.Factory,
- org.osgi.service.cm.ManagedServiceFactory
- service.id = 36
- service.pid = composition4
- ----
- factory.name = composition4
- instance.name = composition4-0
- objectClass = spell.services.SpellChecker
- service.id = 41
- ->
-
-== Hierarchical composites
-
-A composition can also contain others compositions.
-Let's imagine a variation of the latest application.
-In this case, we define a composite containing the GUI and the previous composite.
-
-[source,xml]
-----
-<ipojo>
-
-<!-- Declares the same composition than the latest one -->
-<composite name="composition4">
- <!-- Instantiates an instance of the English dictionary -->
- <subservice action="instantiate"
- specification="spell.services.DictionaryService"/>
-
- <!-- Instantiates an instance of the Checker -->
- <instance component="spell.checker.SpellCheck"/>
-
- <!-- Exports the SpellChecker service -->
- <provides action="export"
- specification="spell.services.SpellChecker"/>
-</composite>
-
-<!-- Declares another composition containing an instance of the previous
- composition and an instance of the GUI
- -->
-<composite name="composition5">
- <!-- Instantiates the previous composition
- You can access to composition by following the
- same way as for other types
- -->
- <instance component="composition4"/>
-
- <!-- Instantiates an instance of the GUI in the composite -->
-<instance component="spell.gui.SpellCheckerGui"/>
-</composite>
-
-<!-- Instantiates an instance of our composition -->
-<instance component="composition5"/>
-
-</ipojo>
-----
-
-The `composition5` contains an instance of the `composition4` and of the GUI.
-So the spell checker service exported by the composition4 is published inside the service context of the `composite 5` (the parent context).
-The GUI instance lives in this service context, and so can access to the exported Spell checker service.
-
-image::documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/app6.png[]
-
-To execute this composition, restart Felix and launch the following commands:
-
-[source,sh]
- start file:../spell.services/output/spell.services.jar
- start file:../spell.english/output/spell.english.jar
- start file:../spell.checker/output/spell.checker.jar
- start file:../spell.checker.gui/output/spell.checker.gui.jar
- start file:../example5/output/composition5.jar
-
-You can check that the composite does no more publish the spell checker service in the OSGi service registry.
-
-== Conclusion
-
-This page has presented how to use iPOJO composition model.
-Several topics were not addressed and will be added shortly:
-
-* Dynamic service implementation
-* The dependency model
-* _Composable_ services and composition consistency
-* Context-awareness
-
-Subscribe to the Felix users mailing list by sending a message to link:mailto:users-subscribe@felix.apache.org[users-subscribe@felix.apache.org];
-after subscribing, email questions or feedback to link:mailto:users@felix.apache.org[users@felix.apache.org].
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/ipojo-hello-word-maven-based-tutorial.adoc b/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/ipojo-hello-word-maven-based-tutorial.adoc
deleted file mode 100644
index 4cd8350..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/ipojo-hello-word-maven-based-tutorial.adoc
+++ /dev/null
@@ -1,547 +0,0 @@
-= iPOJO Hello Word (Maven-Based) tutorial
-
-_This page presents how to use the iPOJO runtime and its associated service component model.
-The concepts of the service component model are introduced, followed by a simple example that demonstrates the features of iPOJO._
-
-== Introduction
-
-iPOJO aims to simplify service-oriented programming on OSGi frameworks;
-the name iPOJO is an abbreviation for _injected POJO_.
-iPOJO provides a new way to develop OSGi service components with the main goal being to simplify service component implementation by transparently managing the dynamics of the environment as well as other non-functional requirements.
-The iPOJO framework allows developers to more clearly separate functional code (i.e., the POJO) from the non-functional code (i.e., dependency management, service provision, configuration, etc.).
-iPOJO combines the functional and non-functional aspects at run time.
-To achieve this, iPOJO provides a simple and extensible service component model based on POJOs.
-
-== The POJO concept
-
-POJO is an acronym for Plain Old Java Object, but it embodies a concept that the simpler and less intrusive the design of a given framework, the better.
-The name is used to emphasize that a given object is not somehow special, but is an ordinary Java Object.
-Martin Fowler, Rebecca Parsons and Josh Mackenzie coined the term POJO in September 2000: "We wondered why people were so against using regular objects in their systems and concluded that it was because simple objects lacked a fancy name.
-So we gave them one, and it's caught on very nicely." From the developer's perspective, the iPOJO framework strives to only require POJOs in as much as it is possible.
-
-== iPOJO service component overview
-
-A service component is able to provide and/or require services, where a service is an object that implements a given service interface embodied as a Java interface.
-In addition, iPOJO introduces a callback concept to notify a component about various state changes.
-
-The component is the central concept in iPOJO.
-In the core iPOJO model, a component describes service dependencies, provided services, and callbacks;
-this information is recorded in the component's metadata.
-Then, the second important concept in iPOJO is component instances.
-A component instances is a special _version_ of the component.
-By merging component metadata and instance configuration, the iPOJO runtime is able to manage the component, i.e., manage its life cycle, inject required services, publish provided services, discover needed services.
-
-== A simple example
-
-The following is a simple example illustrating how to use the core iPOJO concepts.
-The example is comprised of two components, one providing a _Hello_ service and one requiring any number of _Hello_ services.
-The components are packaged into three different bundles using Maven.
-The _hello.service_ bundle contains the service interface.
-The _hello.impl_ bundle contains a component implementing the service.
-The _hello.client_ bundle contains the consumer component.
-
-Download the tutorial archive http://repo1.maven.org/maven2/org/apache/felix/org.apache.felix.ipojo.distribution.maventutorial/{{ipojo.release}}/org.apache.felix.ipojo.distribution.maventutorial-{{ipojo.release}}.zip[here].
-This archive contains a version of Felix (configured with iPOJO), and the projects explained below.
-
-=== Preparing Maven & Installing the tutorial
-
-The first step is to download and install Maven;
-the example was created using Maven 2.1.
-Once maven is installed on your machine, you can compile the tutorial by unzipping the archive, and by launching the `mvn clean install` command at the root of tutorial.
-
-_Be aware that Maven outputs a lot of information while it executes and often downloads a lot of required JAR files into its local repository._
-
-=== Hello Service
-
-The first project is the _hello.service_ project.
-This project contains only the _hello_ service interface.
-Look at the `src/main/java/ipojo/example/hello/Hello.java` file:
-
-[source,java]
-----
-/**
- * Hello Interface.
- * @author <a href="mailto:dev@felix.apache.org">Felix Project Team</a>
- */
-public interface Hello {
-
- /**
- * Returns a message like: "Hello $user_name".
- * @param name the name
- * @return the hello message
- */
- String sayHello(String name);
-}
-----
-
-In the project directory, the pom.xml file contains the instructions to build the bundle.
-The bundle uses the _maven-bundle-plugin_ (see here for more information on this plug-in).<div class="pom"><project>
-
-[source,xml]
-----
-<modelVersion>4.0.0</modelVersion>
-<packaging>bundle</packaging>
-<groupId>ipojo.example</groupId>
-<artifactId>hello.service</artifactId>
-<version>1.0.0</version>
-<name>Hello Service</name>
-
-<build>
-<plugins>
-
-<plugin>
-
-
-<groupId>org.apache.felix</groupId>
-
-
-<artifactId>maven-bundle-plugin</artifactId>
-
-
-<version>2.0.1</version>
-
-
-<extensions>true</extensions>
-
-
-<configuration>
-
-
-
-<instructions>
-
-
-
-
-<Bundle-SymbolicName>
-
-
-
-
-
-${pom.artifactId}
-
-
-
-
-</Bundle-SymbolicName>
-
-
-
-
-<Export-Package>
-
-
-
-
-
-
-ipojo.example.hello
-
-
-
-
-</Export-Package>
-
-
-
-</instructions>
-
-
-</configuration>
-
-</plugin>
-</plugins> </build>
-
-</project>
-----
-
-Then, the project is ready to be built issuing the following Maven command inside the project directory:
-
-[source,sh]
- mvn clean install
-
-Maven should report that the build was a success;
-if an error was reported then verify the previous steps.
-Upon success the _Hello_ service component JAR file is installed into the local Maven repository.
-A copy of the bundle JAR file will also be present in the "target" directory inside the project directory.
-
-=== Hello Service Provider
-
-The component implementation of the service is a simple Java class implementing the _Hello_ service interface.
-The implementation is in the _hello.impl_ project.
-The file `src/main/java/ipojo/example/hello/impl/HelloImpl.java` contains the following service implementation:
-
-[source,java]
-----
-/**
- * Component implementing the Hello service.
- * @author <a href="mailto:dev@felix.apache.org">Felix Project Team</a>
- */
-public class HelloImpl implements Hello {
-
- /**
- * Returns an 'Hello' message.
- * @param name : name
- * @return Hello message
- * @see ipojo.example.hello.Hello#sayHello(java.lang.String)
- */
- public String sayHello(String name) { return "hello " name; }
-}
-----
-
-To manage the component, iPOJO needs some metadata to understand that the component provides the _Hello_ service.
-iPOJO metadata file is at the root of the _hello.impl_ project ("metadata.xml").
-It contains the following metadata (Note: iPOJO also supports a JAR manifest-based syntax):
-[source,xml]
- <?xml version="1.0" encoding="UTF-8"?>
- <ipojo
- xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
- xsi:schemaLocation="org.apache.felix.ipojo http://felix.apache.org/ipojo/schemas/CURRENT/core.xsd"
- xmlns="org.apache.felix.ipojo">
-
- <component classname="ipojo.example.hello.impl.HelloImpl"
- name="HelloProvider">
- <provides />
- </component>
-
- <instance component="HelloProvider" name="HelloService" />
- </ipojo>
-
-In the above XML-based metadata, the _component_ element has a mandatory '__classname'__attribute.
-This attribute tells iPOJO the implementation class of the component.
-Since the component in this example provides a service, the component element also specifies a child '_provides_' element.
-The '_provides_' element informs iPOJO that it must manage the publishing of a service.
-When the '_provides_' element does not contain an interface attribute, as is the case in this example, iPOJO will expose all implemented interfaces of the component as a service;
-it is also possible to specify the precise service interface.
-The '_instance_' element asks iPOJO to create an instance of your component when the bundle is started.
-
-Finally, the `pom.xml` file contains instructions to build the bundle:
-
-[source,xml]
-----
-<project>
- <modelVersion>4.0.0</modelVersion>
-<packaging>bundle</packaging> <groupId>ipojo.example</groupId> <artifactId>hello.impl</artifactId> <version>1.0.0</version>
-
-<name>Hello Service Provider</name>
-
-
-<dependencies>
-<dependency> <!--Compilation (i.e.
-class) dependency on the service interface -->
-<groupId>ipojo.example</groupId>
-<artifactId>hello.service</artifactId>
-<version>1.0.0</version>
-</dependency>
-</dependencies>
-
-<build>
-<plugins>
-<plugin>
-<groupId>org.apache.felix</groupId>
-<artifactId>maven-bundle-plugin</artifactId>
-<version>2.0.1</version>
-<extensions>true</extensions>
-<configuration>
-<instructions>
-<Bundle-SymbolicName>${pom.artifactId}</Bundle-SymbolicName>
-<Private-Package>ipojo.example.hello.impl</Private-Package>
-</instructions>
-</configuration>
-</plugin>
-<plugin>
-<groupId>org.apache.felix</groupId>
-<artifactId>maven-ipojo-plugin</artifactId>
-
-
-
-<version>{{ipojo.release}}</version> <executions>
-<execution>
-<goals>
-<goal>ipojo-bundle</goal>
-</goals>
-</execution>
-</executions>
-</plugin>
-</plugins> </build> </project>
-----
-
-The text highlighted in red above indicates the important information related to the project.
-The first part of the POM file indicates that the packaging format is an iPOJO bundle and also includes some information about the project (name, groupId, and artifactId).
-This information is not used by iPOJO, but is used by Maven.
-The rest of the POM file contains the bundle configuration.
-In the _instructions_ element, you need to enter the bundle name, the bundle description, and the exported packages.
-The service provider bundle exports the package of _Hello_ interface.
-
-Then, the project is ready to be built issuing the following Maven command inside the project directory:
-
-[source,sh]
- mvn clean install
-
-Maven should report that the build was a success;
-if an error was reported then verify the previous steps.
-Upon success the _Hello_ service component JAR file is installed into the local Maven repository.
-A copy of the bundle JAR file will also be present in the "target" directory inside the project directory.
-
-=== Hello Service Client
-
-The Hello service consumer is inside the _hello.client_ project.
-The file `src/main/java/ipojo/example/hello/client/HelloClient.java` contains the following _Hello_ service client:
-
-[source,java]
-----
-package ipojo.example.hello.client;
-
-import ipojo.example.hello.Hello;
-
-/**
- * Hello Service simple client.
- * @author <a href="mailto:dev@felix.apache.org">Felix Project Team</a>
- */
-public class HelloClient implements Runnable {
-
- /**
- * Delay between two invocations.
- */
- private static final int DELAY = 10000;
-
- /**
- * Hello services.
- * Injected by the container.
- * */
- private Hello[] m_hello;
-
- /**
- * End flag.
- * */
- private boolean m_end;
-
- /**
- * Run method.
- * @see java.lang.Runnable#run()
- */
- public void run() {
- while (!m_end) {
- try {
- invokeHelloServices();
- Thread.sleep(DELAY);
- } catch (InterruptedException ie) {
- /* will recheck end */
- }
- }
- }
-
- /**
- * Invoke hello services.
- */
- public void invokeHelloServices() {
- for (int i = 0; i < m_hello.length; i) {
- // Update with your name.
- System.out.println(m_hello[i]({{ refs.i.path }}).sayHello("world"));
- }
- }
-
- /**
- * Starting.
- */
- public void starting() {
- Thread thread = new Thread(this);
- m_end = false;
- thread.start();
- }
-
- /**
- * Stopping.
- */
- public void stopping() {
- m_end = true;
- }
-}
-----
-
-The _Hello_ service client creates a thread that periodically invokes the available _Hello_ services.
-The thread starts when at least one _Hello_ service provider is present using iPOJO's call back mechanism.
-In the client code, to use the _hello_ the component implementation simply declares a field of the type of the service and then simply uses it directly in its code.
-In this example, it is the m_hello field is declared as the service field;
-notice that the field is an array of _Hello_.
-In iPOJO an array of services represents an aggregate or multiple cardinality dependency, whereas if a scalar value represents a singular or unary cardinality dependency.
-In other words, for a singular dependency simply remove the array brackets from the example (e.g., HelloService m_hello[].
-After declaring a field for the service, the rest of the component code can simply assume that the service field will be initialized, e.g., m_hello[i].sayHello("world").
-
-Notice that iPOJO manages service synchronization too.
-So, the service invocations do not require synchronization blocks.
-This synchronization is maintained on a per thread basis, where each method that accesses a service is instrumented to attach the given service instance to the thread so that the thread will continue to see the same service instances even across nested method invocations.
-The thread will not see different service instances until it completely exits from the first method it entered which used a services.
-Thus, you would not want to access services in the {{run()}} method above, because the thread would always see the same service instance.
-
-The component provides two callback methods for its activation and deactivation, starting() and stopping(), respectively.
-Callbacks are used when the component needs to be informed about a component state change.
-In iPOJO, the component state is either _INVALID_ (i.e., not all of the component's constraints are satisfied) or _VALID_ (i.e., all of the component's constraints are satisfied).
-In this example, the starting callback method creates and starts a thread;
-the stopping callback method stops the thread.
-The component metadata will instruct iPOJO to invoke these methods when the component's state changes to _VALID_ or _INVALID_ respectively.
-
-The iPOJO metadata file describing the component is "metadata.xml" and contains the following metadata:
-
-[source,xml]
-----
-<?xml version="1.0" encoding="UTF-8"?>
-<ipojo
- xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
- xsi:schemaLocation="org.apache.felix.ipojo http://felix.apache.org/ipojo/schemas/CURRENT/core.xsd"
- xmlns="org.apache.felix.ipojo">
-
- <component classname="ipojo.example.hello.client.HelloClient">
- <requires field="m_hello" />
- <callback transition="validate" method="starting" />
- <callback transition="invalidate" method="stopping" />
- <properties>
- <property field="m_name" name="hello.name" />
- </properties>
- </component>
-
- <instance component="ipojo.example.hello.client.HelloClient">
- <property name="hello.name" value="clement" />
- </instance>
-</ipojo>
-----
-
-The component element again has the '_classname'_ attribute that refers to the component implementation class.
-The '_requires_' element describes the _Hello_ service dependency by simply specifying its associated component field.
-The '__callback'__elements describe which method to invoke when the component's state changes.
-Then the '_instance_' element asks iPOJO to create an instance of the component (notice that no instance name is provided here, iPOJO will give an instance name to the instance automatically).
-
-Finally, the `pom.xml` file contains instructions to build the bundle:
-
-[source,xml]
-----
-<project> <modelVersion>4.0.0</modelVersion> <packaging>bundle</packaging> <groupId>ipojo.example</groupId> <artifactId>hello.client</artifactId> <version>1.0.0</version> <name>Hello Client</name>
-
-<dependencies>
-<dependency> <!-- Compilation (i.e.
-class) dependency on the service interface -->
-<groupId>ipojo.example</groupId>
-<artifactId>hello.service</artifactId>
-<version>1.0.0</version>
-</dependency>
-</dependencies>
-
-
-<build>
-<plugins>
-<plugin>
-<groupId>org.apache.felix</groupId>
-<artifactId>maven-bundle-plugin</artifactId>
-<version>2.0.1</version>
-<extensions>true</extensions>
-<configuration>
-<instructions>
-<Bundle-SymbolicName>${pom.artifactId}</Bundle-SymbolicName>
-<Private-Package>ipojo.example.hello.client</Private-Package>
-</instructions>
-</configuration>
-</plugin>
-<plugin>
-<groupId>org.apache.felix</groupId>
-<artifactId>maven-ipojo-plugin</artifactId>
-
-
-<version>{{ipojo.release}}</version>
-<executions>
-<execution>
-<goals>
-<goal>ipojo-bundle</goal>
-</goals>
-
-
-
-
-</execution>
-
-
-
-</executions>
-</plugin> </plugins>
-</build> </project>
-----
-
-The text highlighted in red</code> above indicates the information related to the project.
-The _dependencies_ element tells Maven that the client bundle has a compilation dependency on the service provider bundle.
-In this case, the client bundle needs the _Hello_ service interface to compile.
-After building the service provider bundle JAR file, Maven installs it into a local repository on your machine.
-To resolve compilation dependencies, Maven looks in the local repository to find required JAR files.
-After the skeleton "pom.xml" file is modified, the project is ready to be built issuing the following Maven command inside the project directory:
-
-[source,sh]
- mvn clean install
-
-Maven should report that the build was a success;
-if an error was reported then verify the previous steps.
-Upon success the _Hello_ service component JAR file is installed into the local Maven repository.
-A copy of the bundle JAR file will also be present in the "target" directory inside the project directory.
-
-== Running the example
-
-To run the example, start Felix.
-A distribution of Felix is provided in the felix-1.0.3 directory.
-This version is configured to launch iPOJO automatically.
-From the Felix directory, launch the following command to start the framework
-
-[source,sh]
- java -jar bin/felix.jar
-
-You can check installed bundles by using the '_ps'_ command:
-
-[source,sh]
- -> ps
- START LEVEL 1
- ID State Level Name
- [ 0] [Active ] [ 0] System Bundle (2.0.5)
- [ 1] [Active ] [ 1] Apache Felix Bundle Repository (1.4.3)
- [ 2] [Active ] [ 1] Apache Felix iPOJO ({{ipojo.release}})
- [ 3] [Active ] [ 1] Apache Felix iPOJO Arch Command (1.6.0)
- [ 4] [Active ] [ 1] Apache Felix Shell Service (1.4.2)
- [ 5] [Active ] [ 1] Apache Felix Shell TUI (1.4.1)
- ->
-
-iPOJO runtime is the bundle 4.
-The bundle 5 is a Felix shell command allowing the introspection of iPOJO component instances (see herefor further information).
-
-Install the Hello service bundle, the _Hello_ service provider and the client that were created above:
-
-[source,sh]
- start file:../hello.service/target/hello.service-1.0.0.jar
- start file:../hello.impl/target/hello.impl-1.0.0.jar
- start file:../hello.client/target/hello.client-1.0.0.jar
-
-By starting the _Hello_ service provider bundle, the client component will automatically be activated.
-So, the _'hello world'_ messages are displayed.
-
-[source,sh]
- -> hello world
- hello world
-
-Stop the provider (with the '_stop 7_' command) and the client will automatically be deactivated since its dependency is no longer valid.
-If multiple Hello services are deployed, the client will connect to all of them.
-If you restart the bundle (with the _start 7_ command), the client becomes valid.
-
-During these operations, you can use the arch command to check the state of instances.
-
-[source,sh]
--> stop 7 -> arch Instance ArchCommand -> valid Instance ipojo.example.hello.client.HelloClient-0 -> invalid -> arch -instance ipojo.example.hello.client.HelloClient-0 instance name="ipojo.example.hello.client.HelloClient-0" component.type="ipojo.example.hello.client.HelloClient" state="invalid" bundle="8"
-object name="ipojo.example.hello.client.HelloClient@137c60d"
-handler name="org.apache.felix.ipojo.handlers.dependency.DependencyHandler" state="invalid" requires aggregate="true" optional="false" state="resolved" specification="ipojo.example.hello.Hello"
-handler name="org.apache.felix.ipojo.handlers.lifecycle.callback.LifecycleCallbackHandler" state="valid"
-handler name="org.apache.felix.ipojo.handlers.architecture.ArchitectureHandler" state="valid" -> start 7 hello world -> arch Instance ArchCommand -> valid Instance ipojo.example.hello.client.HelloClient-0 -> valid Instance HelloService -> valid -> arch -instance ipojo.example.hello.client.HelloClient-0 instance name="ipojo.example.hello.client.HelloClient-0" component.type="ipojo.example.hello.client.HelloClient"
-state="valid" bundle="8"
-object name="ipojo.example.hello.client.HelloClient@137c60d"
-handler name="org.apache.felix.ipojo.handlers.dependency.DependencyHandler" state="valid" requires aggregate="true" optional="false" state="resolved" specification="ipojo.example.hello.Hello" uses service.id="38" instance.name="HelloService"
-handler name="org.apache.felix.ipojo.handlers.lifecycle.callback.LifecycleCallbackHandler" state="valid"
-handler name="org.apache.felix.ipojo.handlers.architecture.ArchitectureHandler" state="valid"
-
-== Conclusion
-
-We saw how to use easily iPOJO to build service-oriented components.
-Subscribe to the Felix users mailing list by sending a message to link:mailto:users-subscribe@felix.apache.org[users-subscribe@felix.apache.org];
-after subscribing, email questions or feedback to link:mailto:users@felix.apache.org[users@felix.apache.org].
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/ipojo-in-10-minutes.adoc b/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/ipojo-in-10-minutes.adoc
deleted file mode 100644
index 7d6aefc..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/ipojo-in-10-minutes.adoc
+++ /dev/null
@@ -1,609 +0,0 @@
-= iPOJO in 10 minutes
-
-This page presents how to use the iPOJO runtime and its associated service component model.
-The concepts of the service component model are introduced, followed by a simple example that demonstrates the features of iPOJO.
-This tutorial uses annotations to describe components.
-However, you can also use XML or a programmatic API to create iPOJO applications.
-
-== Introduction
-
-iPOJO aims to simplify service-oriented programming on OSGi frameworks;
-the name iPOJO is an abbreviation for _injected POJO_.
-iPOJO provides a new way to develop OSGi service components, simplifying service component implementation by transparently managing the dynamics of the environment as well as other non-functional requirements.
-The iPOJO framework allows developers to more clearly separate functional code (i.e., POJOs) from the non-functional code (i.e., dependency management, service provision, configuration, etc.).
-At run time, iPOJO combines the functional and non-functional aspects.
-To achieve this, iPOJO provides a simple and extensible service component model based on POJOs.
-
-== The POJO concept
-
-"POJO" is just an acronym for Plain Old Java Object, but it embodies a concept that the simpler and less intrusive the design of a given framework, the better.
-The name is used to emphasize that a given object is not somehow special, but is an ordinary Java Object.
-Martin Fowler, Rebecca Parsons and Josh Mackenzie coined the term POJO in September 2000: "We wondered why people were so against using regular objects in their systems and concluded that it was because simple objects lacked a fancy name.
-So we gave them one, and it's caught on very nicely." From a developer's perspective, the iPOJO framework strives as much as possible to only require POJOs.
-
-== iPOJO service component overview
-
-A service component is able to provide and/or require services, where a service is an object that implements a given Java interface.
-In addition, iPOJO introduces a callback concept to notify a component about various state changes.
-
-The component is a central concept in iPOJO.
-In the core iPOJO model, a component describes service dependencies, provided services, and callbacks;
-this information is recorded in the component's metadata.
-After components, the next most important concept in iPOJO is the component instance.
-A component instance is a special _version_ of a component.
-By merging component metadata and instance configuration, the iPOJO runtime is able to discover and inject required services, publish provided services, and manage the component's life cycle.
-
-== A simple example
-
-In this tutorial we will present how to:
-
-* Publish an OSGi service
-* Require an OSGi service
-* Use lifecycle callbacks to activate and deactivate components
-
-=== Presentation of the _Spell_ application
-
-To illustrate iPOJO features, we will implement a very simple application.
-This application is composed by three components:
-
-* A component implementing a dictionary service
-* A component requiring the dictionary service and providing a spellchecker service
-* A component requiring the spellchecker and providing an user interface
-
-image::documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/spell.png[]
-
-=== Preparing the tutorial
-
-This tutorial is based on Ant.
-So, you need to have the Ant program accessible in your path (see http://ant.apache.org/[here] to download and install Ant).
-Download the tutorial archive available http://repo1.maven.org/maven2/org/apache/felix/org.apache.felix.ipojo.distribution.10mintutorial/{{ipojo.release}}/org.apache.felix.ipojo.distribution.10mintutorial-{{ipojo.release}}.zip[here] and then unzip it.
-The archive contains seven directories:
-
-* spell.services contains service interfaces used by the applications
-* spell.english contains an implementation of the Dictionary service (containing English words)
-* spell.checker contains an implementation of a Spell Checker.
-The spell checker requires a dictionary service and check if an input passage is correct (according to the words contained in the dictionary).
-* spell.gui contains a very simple user interface.
-This component uses a spell checker service.
-Then the user can interact with the spell checker with this user interface.
-* The task directory contains Ant tasks used to build the project
-* The solution directory contains an already developed version of the application.
-* Finally, the felix folder contains a configured version of the Felix runtime
-
-=== The spell.services project
-
-The spell.services project contains only service interfaces.
-It is not an iPOJO powered bundle.
-
-Go inside the spell.services directory and open the file "src/spell/services/DictionaryService.java".
-It's a very simple service interface with one method:
-
-[source,java]
- package spell.services;
- /**
- * A simple service interface that defines a dictionary service.
- * A dictionary service simply verifies the existence of a word.
- **/
- public interface DictionaryService {
- /**
- * Check for the existence of a word.
- * @param word the word to be checked.
- * @return true if the word is in the dictionary,
- * false otherwise.
- **/
- public boolean checkWord(String word);
- }
-
-Then, open the file `src/spell/services/SpellChecker.java`, and replace the `TODO` comment with for the following `check` method:
-
-[source,java]
- package spell.services;
- /**
- * A simple service interface that defines a spell checker service.
- * A spell checker service checks the spelling of all words in a
- * given passage. A passage is any number of words separated by
- * a space character and the following punctuation marks: comma,
- * period, exclamation mark, question mark, semi-colon, and colon.
- **/
- public interface SpellChecker {
- /**
- * Checks a given passage for spelling errors. A passage is any
- * number of words separated by a space and any of the following
- * punctuation marks: comma (,), period (.), exclamation mark (!),
- * question mark (?), semi-colon (;), and colon(:).
- * @param passage the passage to spell check.
- * @return An array of misspelled words or null if no
- * words are misspelled.
- **/
- public String[] check(String passage);
- }
-
-Once created, you can build the project by launching Ant from the project directory.
-
-[source,sh]
- $ ant
- Buildfile: build.xml
- clean:
- compile:
- [mkdir] Created dir: d:\clement\workspaces\sandbox\ipojo\examples\tutorial-ant\
- spell.services\output
- [mkdir] Created dir: d:\clement\workspaces\sandbox\ipojo\examples\tutorial-ant\
- spell.services\output\classes
- [javac] Compiling 2 source files to d:\clement\workspaces\sandbox\ipojo\examples\
- tutorial-ant\spell.services\output\classes
- package:
- [bnd] spell.services 2
- BUILD SUCCESSFUL
- Total time: 0 seconds
-
-The created bundle is inside the output directory (spell.services.jar).
-The build process uses http://bnd.bndtools.org/[BND].
-The bundle manifest is described in the spell.services.bnd file.
-
-Once this project is done, we are able to implement a Dictionary service.
-
-=== The spell.english project: Providing an OSGi service
-
-The spell.english project is a simple dictionary implementation of the Dictionary service.
-It contains few English words.
-This implementation is an iPOJO component.
-
-The first step is to implement the service.
-Go in the spell.english directory and open the "src/spell/english/EnglishDictionary.java" file.
-Replace its content with:
-
-[source,java]
-----
-package spell.english;
-
-import org.apache.felix.ipojo.annotations.Component;
-import org.apache.felix.ipojo.annotations.Instantiate;
-import org.apache.felix.ipojo.annotations.Provides;
-import spell.services.DictionaryService;
-
-/**
- * An implementation of the Dictionary service containing English words
- * see DictionaryService for details of the service.
- **/
-@Component // It's an iPOJO Component
-@Provides // We provide a service
-@Instantiate // We declare an instance of our component
-public class EnglishDictionary implements DictionaryService {
-
- // The set of words contained in the dictionary.
- String[] dictionary = { "welcome", "to", "the", "ipojo", "tutorial" };
-
- /**
- * Implements DictionaryService.checkWord(). Determines
- * if the passed in word is contained in the dictionary.
- * @param word the word to be checked.
- * @return true if the word is in the dictionary,
- * false otherwise.
- **/
- public boolean checkWord(String word) {
- word = word.toLowerCase();
-
- // This is very inefficient
- for (String dict : dictionary) {
- if (dict.equals(word)) {
- return true;
- }
- }
- return false;
- }
-}
-----
-
-Notice that this class does not contains neither OSGi nor iPOJO specific code except a few annotations.
-It is just an implementation of the Dictionary Service interface.
-
-The `@Component` annotation is used to declare an iPOJO component.
-The `@Provides` annotation indicates that the component provides a service.
-Provided service interfaces are computed by iPOJO, so it is not necessary to specify them.
-Finally, the `@Instantiate` annotation instructs iPOJO to create an instance of our component.
-The relation between components and instances is the same than between classes and objects in the object-oriented programming.
-
-Then, we are able to create the bundle.
-In the spell.english directory launch the ant command:
-
-
-[source,sh]
-----
-$ ant
-Buildfile: /Users/clement/Projects/felix-trunk/ipojo/distributions/ten-minutes-tutorial/target/test/spell.english/build.xml
-
-clean:
-
-buildclasspath:
- [copy] Copying 1 file to /Users/clement/Projects/felix-trunk/ipojo/distributions/ten-minutes-tutorial/target/test/spell.english/libs
- [copy] Copying 1 file to /Users/clement/Projects/felix-trunk/ipojo/distributions/ten-minutes-tutorial/target/test/spell.english/libs
-
-compile:
- [mkdir] Created dir: /Users/clement/Projects/felix-trunk/ipojo/distributions/ten-minutes-tutorial/target/test/spell.english/output
- [mkdir] Created dir: /Users/clement/Projects/felix-trunk/ipojo/distributions/ten-minutes-tutorial/target/test/spell.english/output/classes
- [javac] /Users/clement/Projects/felix-trunk/ipojo/distributions/ten-minutes-tutorial/target/test/spell.english/build.xml:57: warning: 'includeantruntime' was not set, defaulting to build.sysclasspath=last; set to false for repeatable builds
- [javac] Compiling 1 source file to /Users/clement/Projects/felix-trunk/ipojo/distributions/ten-minutes-tutorial/target/test/spell.english/output/classes
-
-package:
- [bnd] # addAll 'output/classes' with :,
- [bnd] # addAll 'spell.english.bnd' with ,
- [bnd] Updating classpath after classpathref setting
- [bnd] # spell.english (spell.english.jar) 1
- [ipojo] Input bundle file : /Users/clement/Projects/felix-trunk/ipojo/distributions/ten-minutes-tutorial/target/test/spell.english/output/spell.english.jar
- [ipojo] No metadata file found - trying to use only annotations
- [ipojo] Start manipulation
-Apache Felix iPOJO Manipulator - 1.9.0-SNAPSHOT
- [ipojo] Bundle manipulation - SUCCESS
- [ipojo] Output file : /Users/clement/Projects/felix-trunk/ipojo/distributions/ten-minutes-tutorial/target/test/spell.english/output/spell.english.jar
-
-BUILD SUCCESSFUL
-Total time: 0 seconds
-----
-
-The created bundle is inside the output directory (spell.english.jar).
-The build process is based on BND and on the iPOJO Ant task.
-The manifest of the bundle is described in the `spell.english.bnd` file.
-
-=== The spell.checker project: Requiring an OSGi service
-
-The spell.checker project aims to provide a _spell checker_ service.
-However, to serve this service, this implementation requires a _dictionary_ service.
-During this step, we will create an iPOJO component requiring a Dictionary service and providing the Spell Checker service.
-
-First, go the the spell.checker directory and open the file `src/spell/checker/SpellCheck.java`.
-Replace its content with:
-
-[source,java]
-----
-package spell.checker;
-
-import org.apache.felix.ipojo.annotations.Component;
-import org.apache.felix.ipojo.annotations.Instantiate;
-import org.apache.felix.ipojo.annotations.Provides;
-import org.apache.felix.ipojo.annotations.Requires;
-import spell.services.DictionaryService;
-import spell.services.SpellChecker;
-
-import java.util.ArrayList;
-import java.util.List;
-import java.util.StringTokenizer;
-
-@Component
-@Provides
-@Instantiate
-public class SpellCheck implements SpellChecker {
-
- @Requires // This is a service dependency.
- private DictionaryService dictionary;
-
- /**
- * Implements SpellChecker.check(). Checks the given passage for misspelled words.
- *
- * @param passage the passage to spell check.
- * @return An array of misspelled words or null if no words are misspelled.
- */
- public String[] check(String passage) {
- // No misspelled words for an empty string.
- if ((passage == null) || (passage.length() == 0)) {
- return null;
- }
-
- List<String> errorList = new ArrayList<String>();
-
- // Tokenize the passage using spaces and punctuation.
- StringTokenizer st = new StringTokenizer(passage, " ,.!?;:");
-
- // Loop through each word in the passage.
- while (st.hasMoreTokens()) {
- String word = st.nextToken();
-
- // Check the current word.
- if (!dictionary.checkWord(word)) {
- // If the word is not correct, then add it
- // to the incorrect word list.
- errorList.add(word);
- }
- }
-
- // Return null if no words are incorrect.
- if (errorList.size() == 0) {
- return null;
- }
-
- // Return the array of incorrect words.
- System.out.println("Wrong words:" + errorList);
- return errorList.toArray(new String[errorList.size()]);
- }
-}
-----
-
-This class implements the SpellChecker service interface as it provides it.
-Moreover, it has a _special_ field `dictionary`.
-This field represents the required service.
-iPOJO injects a Dictionary service when needed.
-So, the class can use it directly.
-Notice that this class as no OSGi specific code, both the service providing and the requiring are managed by iPOJO and described using annotations.
-When the used dictionary service leaves, iPOJO tries to find another provider.
-If no more providers are available, the instance is invalidated, and the provided service is withdrawn from the service registry.
-
-The @Component, @Instantiate and @Provides annotations were already presented.
-The `@Requires` annotation specifies a service dependency.
-This example shows field injection, but iPOJO also supports constructor injection and method injection (with `@Bind` and `@Unbind`).
-
-Finally, we are able to build the bundle.
-As for previous projects, launch Ant from the project directory.
-
-=== The spell.checker.gui project
-
-The spell.check.gui project contains a very simple user interface (in Swing) allowing a user to interact with a _spell checker_ service.
-
-Go to the spell.checker.gui directory.
-Open the `src\spell\gui\SpellCheckerGui.java`.
-Replace its content with:
-
-[source,java]
-----
-package spell.gui;
-
-import org.apache.felix.ipojo.annotations.*;
-import spell.services.SpellChecker;
-
-import javax.swing.*;
-
-/**
- * A very simple Gui interacting with the CheckSpeller service
- */
-@Component
-@Instantiate
-public class SpellCheckerGui extends JFrame {
-
- private static final long serialVersionUID = 1L;
-
- /**
- * Swing component where the user write the passage to check.
- */
- private JTextField passage = null;
-
- /**
- * Area where the result is displayed.
- */
- private JLabel result = null;
-
- /**
- * Service dependency on the SpellChecker.
- */
- @Requires
- private SpellChecker checker;
-
- /**
- * Constructor.
- * Initialize the GUI.
- */
- public SpellCheckerGui() {
- super();
- initComponents();
- this.setTitle("Spellchecker Gui");
- }
-
- /**
- * Initialize the Swing Gui.
- */
- private void initComponents() {
- java.awt.GridBagConstraints gridBagConstraints;
-
- // The check button
- JButton checkButton = new JButton();
- result = new JLabel();
- passage = new JTextField();
-
- setDefaultCloseOperation(javax.swing.WindowConstants.EXIT_ON_CLOSE); // Stop Felix...
- getContentPane().setLayout(new java.awt.GridBagLayout());
-
- checkButton.setText("Check");
- checkButton.addActionListener(new java.awt.event.ActionListener() {
- public void actionPerformed(java.awt.event.ActionEvent e) {
- check();
- }
- });
- gridBagConstraints = new java.awt.GridBagConstraints();
- gridBagConstraints.gridx = 0;
- gridBagConstraints.gridy = 1;
- gridBagConstraints.insets = new java.awt.Insets(2, 2, 2, 2);
- getContentPane().add(checkButton, gridBagConstraints);
-
- result.setPreferredSize(new java.awt.Dimension(175, 20));
- gridBagConstraints = new java.awt.GridBagConstraints();
- gridBagConstraints.gridx = 0;
- gridBagConstraints.gridy = 2;
- gridBagConstraints.fill = java.awt.GridBagConstraints.HORIZONTAL;
- gridBagConstraints.insets = new java.awt.Insets(2, 2, 2, 2);
- getContentPane().add(result, gridBagConstraints);
-
- passage.setPreferredSize(new java.awt.Dimension(175, 20));
- gridBagConstraints = new java.awt.GridBagConstraints();
- gridBagConstraints.gridx = 0;
- gridBagConstraints.gridy = 0;
- gridBagConstraints.fill = java.awt.GridBagConstraints.HORIZONTAL;
- gridBagConstraints.insets = new java.awt.Insets(2, 2, 2, 2);
- getContentPane().add(passage, gridBagConstraints);
-
- pack();
- }
-
- /**
- * Check Button action.
- * Collects the user input and checks it.
- */
- private void check() {
- String[] result = checker.check(passage.getText());
- if (result != null) {
- this.result.setText(result.length + " word(s) are misspelled");
- } else {
- this.result.setText("All words are correct");
- }
- }
-
- /**
- * Start callback.
- * This method will be called when the instance becomes valid.
- * It set the Gui visibility to true.
- */
- @Validate
- public void start() {
- this.setVisible(true);
- }
-
- /**
- * Stop callback.
- * This method will be called when the instance becomes invalid or stops.
- * It deletes the Gui.
- */
- @Invalidate
- public void stop() {
- this.dispose();
- }
-}
-----
-
-Look at the three last methods.
-The _check_ methods collects the user input and uses a _Check speller_ service to check this input.
-The speller is injected into the `checker` field thanks to the `@Requires` annotation.
-This method is called when the user presses the button.
-The _start_ and _stop_ methods are lifecycle callbacks.
-As we display the user interface when the instance is created and to dispose it when the instance stops, we need a way to be notified when we need to execute these actions.
-iPOJO provides an easy way to do this.
-The component provides two callback methods for its activation and deactivation.
-Callbacks are used when the component needs to be informed about a component state change.
-In iPOJO, the component state is either _INVALID_ (i.e., not all of the component's constraints are satisfied) or _VALID_ (i.e., all of the component's constraints are satisfied).
-In this example, the start callback method sets the GUI visibility to true;
-the stop callback method deletes the GUI.
-The `@Validate` and `@Invalidate` annotations are used to specify these callbacks.
-
-Once this file is created, you can compile the project by launching _ant_ in the spell.checker.gui directory.
-
-== Running the application
-
-We have all the bundles required to start playing with the application.
-
-To run the example, start Felix.
-A distribution of Felix is provided in the felix-framework-VERSION directory.
-This version is configured to launch iPOJO automatically.
-From the Felix directory, launch the following command to start the framework.
-Then enter a profile name.
-
-[source,sh]
- java -jar bin/felix.jar
-
-You can check installed bundles by using the '_lb_' command:
-
-[source,sh]
-----
-____________________________
-Welcome to Apache Felix Gogo
-
-g! lb
-START LEVEL 1
- ID|State |Level|Name
- 0|Active | 0|System Bundle (4.2.1)
- 1|Active | 1|Apache Felix Bundle Repository (1.6.6)
- 2|Active | 1|Apache Felix Gogo Command (0.12.0)
- 3|Active | 1|Apache Felix Gogo Runtime (0.10.0)
- 4|Active | 1|Apache Felix Gogo Shell (0.10.0)
- 5|Active | 1|Apache Felix iPOJO (1.9.0.SNAPSHOT)
- 6|Active | 1|Apache Felix iPOJO Gogo Command (1.0.1)
-g!
-----
-
-iPOJO runtime is the bundle 5.
-Once started, install the four created bundles as below:
-
-[source,sh]
-----
- start file:../spell.services/output/spell.services.jar
- start file:../spell.english/output/spell.english.jar
- start file:../spell.checker/output/spell.checker.jar
- start file:../spell.checker.gui/output/spell.checker.gui.jar
-----
-
-The new set of bundles is:
-
-[source,sh]
-----
- g! lb
- START LEVEL 1
- ID|State |Level|Name
- 0|Active | 0|System Bundle (4.2.1)
- 1|Active | 1|Apache Felix Bundle Repository (1.6.6)
- 2|Active | 1|Apache Felix Gogo Command (0.12.0)
- 3|Active | 1|Apache Felix Gogo Runtime (0.10.0)
- 4|Active | 1|Apache Felix Gogo Shell (0.10.0)
- 5|Active | 1|Apache Felix iPOJO (1.9.0.SNAPSHOT)
- 6|Active | 1|Apache Felix iPOJO Gogo Command (1.0.1)
- 7|Active | 1|spell.services (0.0.0)
- 8|Active | 1|spell.english (0.0.0)
- 9|Active | 1|spell.checker (0.0.0)
- 10|Active | 1|spell.checker.gui (0.0.0)
-----
-
-iPOJO provides a command to check created instances:
-
-[source,sh]
-----
- g! instances
- Instance org.apache.felix.ipojo.arch.gogo.Arch-0 -> valid
- Instance spell.checker.SpellCheck-0 -> valid
- Instance spell.gui.SpellCheckerGui-0 -> valid
- Instance spell.english.EnglishDictionary-0 -> valid
-----
-
-As you can see, all our instances are valid.
-
-In the gui (that should have appeared), you can interact with the spell service by entering a passage and clicking on the check button:
-
-image::documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/ss.png[]
-
-Then, stop the _Dictionary_ service provider (with the _stop 8_) command.
-The GUI disappears.
-Indeed, Spell Checker service cannot be provided as it depends on the Dictionary service.
-
-image::documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/spell2.png[]
-
-You can check the validity of the instances and see that the SpellChecker and the Gui are invalid.
-
-[source,sh]
-----
- g! instances
- Instance org.apache.felix.ipojo.arch.gogo.Arch-0 -> valid
- Instance spell.checker.SpellCheck-0 -> invalid
- Instance spell.gui.SpellCheckerGui-0 -> invalid
-----
-
-Then, restart the Dictionary service provider with the _start 8_ command.
-The GUI reappears immediately.
-You can try to stop the _check speller_ service provider without stopping the _dictionary_ service provider with the _stop 9_ command.
-As for the last manipulation, the GUI disappears.
-
-image::documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/spell3.png[]
-
-This time, the Gui is invalid, but the English dictionary is valid:
-
-[source,sh]
-----
- g! instances
- Instance org.apache.felix.ipojo.arch.gogo.Arch-0 -> valid
- Instance spell.gui.SpellCheckerGui-0 -> invalid
- Instance spell.english.EnglishDictionary-0 -> valid
-----
-
-== Conclusion
-
-We saw how to use easily iPOJO to build service-oriented component.
-In this tutorial, we have demonstrated how to:
-
-* Publish OSGi services
-* Require OSGi services
-* Use lifecycle callbacks to activate and deactivate components
-
-iPOJO provides a lot of others features that you can try in the others available tutorials.
-Subscribe to the Felix users mailing list by sending a message to link:mailto:users-subscribe@felix.apache.org[users-subscribe@felix.apache.org];
-after subscribing, email questions or feedback to link:mailto:users@felix.apache.org[users@felix.apache.org].
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-junit4osgi.adoc b/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-junit4osgi.adoc
deleted file mode 100644
index bbf197c..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-junit4osgi.adoc
+++ /dev/null
@@ -1,30 +0,0 @@
-= The JUnit4OSGi framework: a simple test framework for OSGi
-
-_JUnit4OSGi is a test framework executing JUnit tests on an OSGi runtime.
-JUnit4OSGi provides a JUnit{pp} environment specialized for OSGi, several runners and a maven plugin executing your tests during your build process_
-
-== Why JUnit4OSGi ?
-
-OSGi is a great technology to create modular and dynamic applications.
-However, creating modular applications raise the need of integration tests: How to be sure that all my modules/services...
-collaborate correctly.
-Unit test is great, but does not really check my whole system and the relation between my modules.
-Junit4OSGi is a framework allowing the execution of JUnit tests in an OSGi environment !
-It stems from the fact that testing applications on top on OSGi is quite complex compared to classic Java unitary tests.
-With junit4osgi you will be able to test all your bundles together and check that everything works correctly (integration tests).
-
-The goal of JUnit4OSGi is to provide the same mechanisms as unitary tests in an OSGi context.
-It allows using the JUnit concepts, although tests are run in an OSGi framework, using all of its distinctiveness.
-The JUnit4OSGi framework allows you to :
-
-* Perform OSGi services tests.
-* Test applications on different VMs, OSGi implementations.
-* Test dynamism impact.
-
-Interested by `junit4osgi`...
-start the adventure !
-
-* xref:documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-junit4osgi/apache-felix-ipojo-junit4osgi-tutorial.adoc[Tutorial]
-* xref:documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-junit4osgi/apache-felix-ipojo-junit4osgi-methods.adoc[OSGi and firends methods]
-* xref:documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-junit4osgi/apache-felix-ipojo-junit4osgi-architecture.adoc[junit4osgi architecture]
-* xref:documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-junit4osgi/apache-felix-ipojo-junit4osgi-maven.adoc[Running your test in Maven]
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-junit4osgi/apache-felix-ipojo-junit4osgi-architecture.adoc b/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-junit4osgi/apache-felix-ipojo-junit4osgi-architecture.adoc
deleted file mode 100644
index 7c5b335..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-junit4osgi/apache-felix-ipojo-junit4osgi-architecture.adoc
+++ /dev/null
@@ -1,43 +0,0 @@
-= junit4osgi framework architecture
-
-_This page describes the architecture of the junit4osgi framework.
-This does not include the maven-junit4osgi-plugin._
-
-== Global architecture
-
-[cols=2*]
-|===
-| !junit4osgi-arch.png
-| align=center, width=50%, height=50%!
-|===
-
-A system tested with junit4OSGi is divide in three parts:
-
-. The tested system composed by bundles/services/...
-composing the system under tests.
-This can be the `true` application.
-. Tests bundles containing tests stressing/checking the system under tests.
-. The junit4OSGi framework composed by a runtime bundle (executing tests) and a runner bundle (launching test).
-
-junit4OSGi does not impacts anything on the system under test.
-Test bundles interact with the system under test via services/events ...
-Bundle containing tests declared contained test suites in there `manifest` such as:
-
- Test-Suite: org.apache.felix.ipojo.test.scenarios.ps.ProvidedServiceTestSuite, org.apache.felix.ipojo.scenarios.ps.StrategyTestSuite
-
-Thanks to this `manifest` header, the junit4OSGi runtime bundle collects tests.
-This bundle is the core of the test framework, and manage both collection and execution of tests.
-The runner bundle just launch tests.
-According to the runner implementation, test selection can also be done.
-Several runner have been developped:
-
-* `junit` Felix command: executing test from the Felix shell (only for Felix)
-* Swing runner: executing test from a Swing application (works for Felix, Equinox and Knopflerfish)
-* Immediate runner: executing test as soon the runner arrives in the framework (works for Felix, Equinox and Knopflerfish)
-* Maven runner: launching an embedded Felix with required bundle and launching test automatically during the Maven build process.
-
-== Why junit 3 ?
-
-The junit4OSGi framework use junit 3 because it was design and developed to test embedded systems.
-So, the junit4OSGi framework runs on a J2ME Foundation Profile 1.1 virtual machine (such as Mika).
-However, soon, junit4OSGi will evolve to support Junit4 and TestNG.
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-junit4osgi/apache-felix-ipojo-junit4osgi-maven.adoc b/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-junit4osgi/apache-felix-ipojo-junit4osgi-maven.adoc
deleted file mode 100644
index 51b73a4..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-junit4osgi/apache-felix-ipojo-junit4osgi-maven.adoc
+++ /dev/null
@@ -1,225 +0,0 @@
-= The Maven-junit4OSGi-plugin
-
-_junit4OSGi tests can also be executed automatically during the `integration-test` phase of a maven build process.
-This page describes the maven-junit4osgi-plugin allowing a seamless maven integration._
-
-== What does the maven-junit4osgi-plugin provide?
-
-----
-* Allows testing OSGi applications
-* Integrated in a Maven-based build process
-* Provides the same output as Surefire
-* Supports Maven site generation
-----
-
-== Using the plug-in
-
-=== Download and building the plug-in
-
-The plug-in sources are available in the iPOJO trunk.
-However the junit4osgi and iPOJO runtime are also required.
-So, download the source of iPOJO: `+svn co http://svn.apache.org/repos/asf/felix/trunk/ipojo/+` To compile it, run the following commands:
-
- cd ipojo
- mvn clean install -Pexamples
-
-== Simple configuration
-
-So, first the project using the plug-in is not the project under test.
-It's another project containing either only integration-test packaged in a bundle, or is empty (and so depends on other bundles containing integration tests).
-Tests contained in the project are developed with junit4osgi, and are packaged in a bundle with the maven-bundle-plugin.
-In the pom file, add the following plugin configuration to use the maven-junit4osgi-plugin:
-
- <plugin>
- <groupid>org.apache.felix</groupid>
- <artifactid>maven-junit4osgi-plugin</artifactid>
- <executions>
- <execution>
- <goals>
- <goal>test</goal>
- </goals>
- <configuration>
- <deployprojectartifact>true</deployprojectartifact>
- </configuration>
- </execution>
- </executions>
- </plugin>
-
-== Plugin parameter
-
-The plug-in has only one parameter.
-The `deployProjectArtifact` parameter enables or disables the current artifact deployment.
-If the current project contains tests, the plug-in can deploy the built artifact (as illustrated in this pom).
-Otherwise, the current project artifact is not deployed.
-This can be useful if the project just depends on other test bundles and sets the test configuration (as this pom).
-
-=== Configuring the set of bundles to deploy
-
-There is two different ways to configure the plug-in to deploy other bundles.
-If the bundle to deploy is a maven artifact, just add this artifact as a maven project dependency.
-Here is an example:
-
- <dependency>
- <artifactid>tests.manipulation.metadata</artifactid>
- <groupid>ipojo.tests</groupid>
- <version>1.1.0-SNAPSHOT</version>
- </dependency>
-
-If your bundle is not a maven artifact, you can configure the plugin with the bundle URL (from where the bundle will be deployed)
-
- <configuration>
- <deployprojectartifact>true</deployprojectartifact>
- <bundles>
- <param>file:/Users/clement/bundles/test-metadata.jar</param>
- </bundles>
- </configuration>
-
-Set bundles are installed and started.
-You can depend on bundle that does not contain test as well as bundle containing tests.
-
-=== Configuring Felix
-
-It is also possible to set Felix properties in the configuration:
-
- <configuration>
- <configuration>
- <org.osgi.http.port>8083</org.osgi.http.port>
- </configuration>
- </configuration>
-
-=== Showing/hiding test trace
-
-The plugin collects System.out, System.err and logged messages to write them in the test report.
-Moreover, the plugin allows hiding traces when tests are executed.
-To achieve this just add the `hideOutputs` parameter.
-
- <configuration>
- <hideOutputs>true</hideOutputs>
- </configuration>
-
-=== Disabling/Enabling the Log Service
-
-The plugin exposed a LogService in the OSGi framework to collects logged messaged.
-This service enabled by default.
-You can diable it by launching the plugin with the `logService` property set to `false`
-
- mvn clean integration-test -DlogService=false
-
-=== Skipping integration-test
-
-Sometimes you want to skip tests :-(.
-The plugin uses the `maven.test.skip` property to skip tests such as
-
- mvn clean install -Dmaven.test.skip=true
-
-=== Ignoring failures
-
-If tests throws errors or have failures, the plugin breaks the Maven build.
-You can by-pass this behavior by ignoring errors and failures.
-This is useful during test generation.
-
- mvn clean install -Dmaven.test.failure.ignore=true
-
-== Executing the plug-in
-
-To execute test, just launch the `mvn clean integration-test` command.
-
-----
-[INFO] Scanning for projects...
-[INFO] ------------------------------------------------------------------------
-[INFO] Building iPOJO Primitive Manipulation Test Suite
-[INFO] task-segment: [integration-test]
-[INFO] ------------------------------------------------------------------------
-[INFO] [resources:resources]
-[INFO] Using default encoding to copy filtered resources.
-[INFO] [compiler:compile]
-[INFO] Nothing to compile - all classes are up to date
-[INFO] [resources:testResources]
-[INFO] Using default encoding to copy filtered resources.
-[INFO] [compiler:testCompile]
-[INFO] No sources to compile
-[INFO] [surefire:test]
-[INFO] No tests to run.
-[INFO] [bundle:bundle]
-[INFO] [ipojo:ipojo-bundle {execution: default}]
-[INFO] Start bundle manipulation
-[INFO] Metadata file : /Users/clement/Documents/workspaces/felix-trunk/ipojo/tests/manipulator/primitives/target/classes/metadata.xml
-[INFO] Input Bundle File : /Users/clement/Documents/workspaces/felix-trunk/ipojo/tests/manipulator/primitives/target/tests.manipulation.primitives-1.1.0-SNAPSHOT.jar
-[INFO] Bundle manipulation - SUCCESS
-[INFO] [junit4osgi:test {execution: default}]
-Analyzing org.apache.felix.ipojo - compile
-Analyzing org.apache.felix.ipojo.metadata - compile
-Analyzing org.osgi.core - compile
-Analyzing junit - compile
-Analyzing org.apache.felix.ipojo.junit4osgi - compile
-Analyzing tests.manipulation.metadata - test
-
--------------------------------------------------------
-T E S T S
--------------------------------------------------------
-Deploy : /Users/clement/Documents/workspaces/felix-trunk/ipojo/tests/manipulator/primitives/target/tests.manipulation.primitives-1.1.0-SNAPSHOT.jar
-Loading org.apache.felix.ipojo.test.scenarios.manipulation.ManipulationTestSuite
-Loading org.apache.felix.ipojo.test.scenarios.manipulation.ManipulationTestSuite
-Junit Extender starting ...
-Running Manipulation Metadata Test Suite
-Tests run: 16, Failures: 0, Errors: 0, Time elapsed: 0 sec
-Running Primitive Manipulation Test Suite
-Tests run: 17, Failures: 0, Errors: 0, Time elapsed: 0 sec
-
-Results :
-
-Tests run: 33, Failures: 0, Errors:0
-
-Unload test suites [class org.apache.felix.ipojo.test.scenarios.manipulation.ManipulationTestSuite]
-Unload test suites [class org.apache.felix.ipojo.test.scenarios.manipulation.ManipulationTestSuite]
-Cleaning test suites ...
-[INFO] ------------------------------------------------------------------------
-[INFO] BUILD SUCCESSFUL
-[INFO] ------------------------------------------------------------------------
-[INFO] Total time: 6 seconds
-[INFO] Finished at: Mon Nov 10 21:30:21 CET 2008
-[INFO] Final Memory: 9M/18M
-[INFO] ------------------------------------------------------------------------
-----
-
-Failures and errors are reported in the plugin output.
-
-== Generating the report web page
-
-When test are executed, the plug-in generates XML reports (int the target/junit4osgi-reports directory) using the same convention as Surefire.
-So, it is possible to configure Surefire to generate the web page with test results.
-To do this, add the following report configuration to the project executing tests:
-
- <reporting>
- <plugins>
- <plugin>
- <groupid>org.apache.maven.plugins</groupid>
- <artifactid>maven-surefire-report-plugin</artifactid>
- <version>2.4.3</version>
- <configuration>
- <showsuccess>true</showsuccess>
- </configuration>
- </plugin>
- </plugins>
- </reporting>
-
-This snippet configures the maven-surefire-report-plugin to collect results from the 'target/surefire-reports' directory.
-Then execute the plugin with the following command: {code:none} mvn org.apache.maven.plugins:maven-surefire-report-plugin:2.4.3:report
-
-----
-This command generates the web page with test results in 'target/site'. This page shows an example of page generated with this command.
-
-h2. Plug-in design
-The plug-in is quiet simple, it just starts an embedded Felix with a special activator installing and starting the junit4osgi framework and specified bundles.
-Then, before executing test, the plug-in waits for "stability". Indeed, as bundle activation can be asynchronous, the plug-in need to wait that the configuration is stable. Stability is obtained when all bundles are activated, and no new services appear or disappear on a 500 ms period. If after several second the stability cannot be reached, the plug-in stops.
-Once the stability is reached, the junit4ogsi runner service is used to execute tests. Then results are collected and reports are generated.
-
-h2. Conclusion
-This page has presented a front-end automating the execution of junit4osgi tests. Now it is possible to integrate OSGi application tests in a build process. The presented maven plugin provides following features:
- * An easy integration in a Maven-based build process
- * A good flexibility allowing reproducing production execution environments to test the application
- * Test result output is the same as surefire
- * Is able to generate Surefire-like reports
-\\
-\\
-----
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-junit4osgi/apache-felix-ipojo-junit4osgi-methods.adoc b/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-junit4osgi/apache-felix-ipojo-junit4osgi-methods.adoc
deleted file mode 100644
index f9d2401..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-junit4osgi/apache-felix-ipojo-junit4osgi-methods.adoc
+++ /dev/null
@@ -1,84 +0,0 @@
-= OSGi and friends methods
-
-_Developing OSGi tests can be definitely boring.
-First, testing is generally not a very exciting experience, but imagine if you have to handle all the OSGi issues in your tests...
-Don't worry junit4osgi provides methods allowing to interact easily with OSGi!_
-
-== OSGi methods
-
-junit4osgi test case extends the `OSGiTestCase` class.
-This class provides useful methods allowing to find services, get them, get the `PackageAdmin` service...
-The description of these methods can be found afterward.
-
-The most part of the methods are available statically and non-statically.
-Static methods require a `Bundle`.
-Non static methods use the current bundle context, and track get services to release them when the test is done.
-So, we advise you to use the non-static methods.
-Static methods just allow you to check that a specific bundle can access to services / resources.
-
-=== Service interaction
-
-* `boolean isServiceAvailable(String svc)` : returns `true` if the service `svc` is available.
-* `boolean isServiceAvailableByPID(String itf, String pid)` : return `true` if the service `svc` is available and exposed with `pid` as `service.pid`.
-* `ServiceReference getServiceReference(String itf)`: returns a service reference exposing the `itf` service specification, or `null` if not available.
-* `ServiceReference getServiceReference(String itf, String filter)`: returns a service reference matching with the <service interface, filter> request, or `null` is not available.
-* `ServiceReference getServiceReferenceByPID(String itf, String pid)`: returns a service reference exposing the service `itf` and exposed with a `service.pid` equals to `pid`, or `null` if not available.
-* `ServiceReference[]({{ refs..path }}) getServiceReferences(String itf, String filter)`: returns all the service references matching with the <service interface, filter> request, or an empty array is not available.
-* `Object getServiceObject(String itf, String filter)`: returns a service object matching with the <service interface, filter> request or `null` is not available.
-* `Object getServiceObject(ServiceReference ref)`: returns the service object associated with the given `service reference` or `null` if not available.
-* `Object[]({{ refs..path }}) getServiceObjects(String itf, String filter)`: gets all the service objects matching with the <service interface, filter> request or an empty array is no providers are available.
-* `void waitForService(String itf, String filter, long timeout)`: waits for a service arrival matching with the <service interface, filter> request.
-If the timeout expires, this method fails.
-
-=== Get the bundle context
-
-* `BundleContext getContext()` : gives access to the OSGiTestCase bundle context.
-
-=== Install/Start/Uninstall bundles
-
-* `Bundle installBundle(String url)`: installs a bundle from the given url.
-This method fails if the bundle cannot be installed.
-* `Bundle installBundle(String url, InputStream stream)`: installs a bundle from the given input stream.
-This methods fails if the bundle cannot be installed.
-* `Bundle installAndStart(String url)`: installs a bundle from the given url and starts it.
-This methods fails if the bundle cannot be installed and started correctly.
-* `Bundle installAndStart(String url, InputStream stream)`: installs a bundle from the given input stream and starts it.
-This methods fails if the bundle cannot be installed and started correctly.
-* `Bundle getBundle(long bundleId)`: gets an installed bundle by its bundle id, or `null` if not found.
-* `Bundle getBundle(String name)`: gets an installed bundle by its symbolic name.
-Fails if not found.
-
-=== PackageAdmin
-
-* `PackageAdmin getPackageAdmin()`: gives access to the `Package Admin` service exposed by the framework.
-* `refresh()`: refresh package wires.
-
-== Extensibility: Helper objects
-
-junit4osgi provides an extensibility mechanism to reduce the pain of testing.
-So, if you're interacting with specific services or environment, you can use `Helper` objects.
-Those object have to be created in the `setUp` method and `disposed` in the `tearDown` method.
-
-So, for example, if you write iPOJO tests, you can use the iPOJO helper providing a lot of utility functions simplifying the development of tests.
-{code:java} public class MyTest extends OSGiTestCase { ComponentInstance fooProvider1, fooProvider2;
-
-----
-IPOJOHelper helper; // Helper object
-
-public void setUp() {
- helper = new IPOJOHelper(this); // Create the object.
-String type2 = "PS-FooProviderType";
-
-fooProvider1 = helper.createComponentInstance(type2, p3);
- fooProvider2 = helper.createComponentInstance(type2, "FooProvider-4");
-}
-
-public void tearDown() {
-helper.dispose(); // Dispose it, instances will be disposed too.
-}
-
-
-You can also implements your own helper (for specific purpose) by just implementing the {{Helper}} interface.
-\\
-\\
-----
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-junit4osgi/apache-felix-ipojo-junit4osgi-tutorial.adoc b/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-junit4osgi/apache-felix-ipojo-junit4osgi-tutorial.adoc
deleted file mode 100644
index 19af386..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-junit4osgi/apache-felix-ipojo-junit4osgi-tutorial.adoc
+++ /dev/null
@@ -1,345 +0,0 @@
-= junit4osgi quick start
-
-_This page describes how using the junit4osgi framework.
-With the archive tutorial, a pre-configured version of Felix (with the test framework already installed) is also provided._
-
-== Getting JUnit4OSGi
-
-[cols=2*]
-|===
-| The JUnit4OSGi framework is available from the http://felix.apache.org/site/downloads.cgi[Felix downloads].
-Source code is also available in the iPOJO sub-project ([sources
-| Download]).
-The JUnit4OSGi framework and the different launchers are built when you compile Felix.
-|===
-
-== How to run test?
-
-Firs of all to execute test you must deploy in your OSGi container:
-
-. Your tests
-. The junit4osgi runtime (executing tests)
-. A runner launching tests
-
-Several runner are available:
-
-* You can use the JUnit4OSGi immediate-runner, which run tests contained in all the test-bundles.
-The results are displayed in the framework console output.
-* The JUnit4OSGi Felix Command (available only for the Apache Felix OSGi framework), allows you to run tests contained in a specific bundle.
-Test results are also displayed in the framework console output.
-The syntax of the command is very simple : ** To run tests contained in the bundle with the given id :``+{noformat}junit <bundle id>{noformat+``} ** To run tests contained in all the test-bundles installed in the framework :``junit all``
-* The JUnit4OSGi Swing GUI lets you select the test cases and test suites to execute and shows you graphically the result of the tests.
-You can double-click on a test case result to show its details.
-
-!http://felix.apache.org/site/apache-felix-ipojo-junit4osgi.data/screenshot-junit4ogsi-swing-runner.PNG!
-
-== TestCase, TestSuite
-
-A test case is an environment (made of conditions and variables) under which a tester will check that a requirement is satisfied.
-For JUnit, test cases are classes that define several test methods ; each test method tests an aspect of the targeted requirement.
-Test cases are often collected into test suites.
-A test suite aggregates several test cases (and even other test suites), including the notion of test hierarchy.
-Tests can be organized according to the different requirements they try to validate.
-The skeleton of a JUnit `TestCase` and `TestSuite` is shown just above :
-
-----
-/**
- * The skeleton of a JUnit test case
- */
-public class MyTestCase extends junit.framework.TestCase {
- ...
-
- public void setUp() {
- // Performs actions BEFORE running any test case.
- }
-
- public void testSomething() throws AnyException {
- // A test method
- ...
- assertTrue(myTest);
- assertEquals(myValue, expectedValue);
- ...
- }
-
- public void testAnotherThing() {
- // Another test method
- ...
- }
-
-
- public void tearDown() {
- // Performs actions AFTER running all test cases.
- }
-}
-
-
-
-/**
- * The skeleton of a JUnit test suite
- */
-public class MyTestSuite extends junit.framework.TestSuite {
- /**
- * The skeleton of a JUnit test suite
- */
- public static Test suite() {
- TestSuite suite = new TestSuite("The name of the test suite");
- suite.addTestSuite(MyTestCase.class);
- suite.addTestSuite(AnotherTestCase.class);
- ...
- return suite;
- }
-}
-----
-
-First, tests methods are declared in the test case.
-Their name must begin with "test", so JUnit will execute them on demand.
-The test are expressed in terms of JUnit assertions ; the `assert*()` methods causes JUnit test failure if the given assertion is false.
-The setUp() and tearDown() methods perform specific actions before and after test cases are run.
-Then, the test suite collect various test cases.
-It must implement the `suite()` method that returns the global (and organized) test suite to JUnit.
-
-== OSGiTestCase and OSGiTestSuite
-
-An OSGi test case, is a test case that runs in an OSGi context.
-`OSGiTestCase` is the class that all the OSGi test cases you write must extend.
-This class is a kind of bridge between the JUnit TestCase class and the OSGi environment.
-The only thing the `OSGiTestCase` class adds is the access to the bundle context of the bundle containing tests, and some utility methods, giving an easy access to other bundles and services registered in the OSGi framework.
-
-The structure of an `OSGiTestCase` is exactly the same as a classic JUnit `TestCase` :
-
-----
- /**
- * The structure of an OSGiTestCase
- */
- public class MyOSGiTestCase extends OSGiTestCase {
- public void setUp() {...}
- public void testSomething() {
- // You can access here the bundle context through
- // the 'getContext()' method
- getContext().getServiceReference(...);
-
- ...
- }
- public void testAnotherThing() {...}
- ...
- public void tearDown() {...}
- }
-----
-
-By extension, OSGi test suites are collections of OSGi test cases.
-But you can also add classic JUnit test cases inside your `OSGiTestSuite`.
-The skeleton of an OSGiTestSuite is globally the same as a TestSuite, except the fact that a reference to the bundle context is passed :
-
- public class MyOSGiTestSuite {
- /**
- * This method returns the suite of tests to run.
- */
- public static Test suite(BundleContext bc) {
- OSGiTestSuite suite = new OSGiTestSuite("My OSGi test suite", bc);
- suite.addTestSuite(MyFirstTest.class);
- suite.addTestSuite(MySecondTest.class);
- ...
- // Here, we add a sub test suite in this test suite.
- suite.addTest(AnotherTestSuite.suite(bc));
- ...
- return suite;
- }
- }
-
-== How to declare test suites
-
-This section explains how to declare your test suites in order to expose them to the JUnit4OSGi bundle.
-
-The written OSGi test suites must be declared by the bundle containing them.
-To do so, you define add the Test-Suite property in your bundle's header.
-The following snippets show you how to configure your bundle generation tool to add this property in the header.
-You can even declare test cases in it.
-The Junit4OSGi bundle will detect such an header in installed bundle (using the extender pattern) and execute contained tests on demand.
-
-With the maven-bundle-plugin, add the following lines in your project's pom :
-
- <plugin>
- <groupId>org.apache.felix</groupId>
- <artifactId>maven-bundle-plugin</artifactId>
- ...
- <extensions>true</extensions>
- <configuration>
- <instructions>
- ...
- <!-- Declare here the test cases and test suites of your bundle -->
- <Test-Suite>
- a.package.MyFirstTestSuite,
- yet.another.package.MySingleTestCase
- ...
- </Test-Suite>
- </instructions>
- </configuration>
- </plugin>
-
-With the aQute Bnd Ant task, add the following lines in your project bnd file:
-
- Test-Suite: a.package.MyFirstTestSuite, yet.another.package.MySingleTestCase, ...
-
-== Quick examples
-
-The following examples show you how to perform unitary tests on your OSGi platform.
-The first example recovers the example given in the JUnit Cookbook, "bundlizes" it so tests can be run in an OSGi environment.
-None of the JUnit4OSGi specific features is used, but it shows how to adapt classic JUnit tests.
-The second example is more OSGi-oriented, and shows how a unitary test can access to the framework via its bundle context.
-
-These examples can be downloaded http://people.apache.org/~clement/ipojo/tutorials/junit4osgi/junit4osgi-tutorial.zip[here].
-
-=== Bundles to deploy to use junit4osgi
-
-If you don't use the archive, you can deploy the junit4osgi framework manually.
-Here is the list of the bundles to deploy and start:
-
-* org.apache.felix.ipojo-1.6.0.jar: iPOJO Core bundle
-* org.apache.felix.ipojo.handler.extender-1.6.0.jar: iPOJO Extender pattern handler
-* org.apache.felix.ipojo.junit4osgi-1.1.0-SNAPSHOT.jar: the JUnit4OSGi framework
-* org.apache.felix.ipojo.junit4osgi.felix-command-1.1.0-SNAPSHOT.jar: the command line junit4osgi runner
-
-=== The remixed JUnit example
-
-This example is a simple conversion of a classic JUnit example derived from the JUnit Cookbook.
-The test case and the test suite are shown to remind you JUnit principles.
-
-----
-package junit.example;
-import junit.framework.TestCase;
-import junit.money.Money;
-
-public class SimpleTestCase extends TestCase {
- private Money f12CHF;
- private Money f14CHF;
- public void setUp() {
- f12CHF= new Money(12, "CHF");
- f14CHF= new Money(14, "CHF");
- }
- public void testEquals() {
- assertTrue(!f12CHF.equals(null));
- assertEquals(f12CHF, f12CHF);
- assertEquals(f12CHF, new Money(12, "CHF"));
- assertTrue(!f12CHF.equals(f14CHF));
- }
- public void testSimpleAdd() {
- Money expected= new Money(26, "CHF");
- Money result= f12CHF.add(f14CHF);
- assertTrue(expected.equals(result));
- }
-}
-
-
-
-package junit.example;
-import junit.framework.Test;
-import junit.framework.TestSuite;
-public class SimpleTestSuite {
- public static Test suite() {
- TestSuite suite = new TestSuite("Money Simple Test Suite");
- suite.addTestSuite(SimpleTestCase.class);
- return suite;
- }
-}
-----
-
-The following bnd file declares the test suite in the target bundle's header :
-
- Private-Package: junit.money, junit.example
- Test-Suite: junit.example.SimpleTestSuite
-
-Once built, the bundle must be deployed in the provided Felix framework, and tests can be performed using the `'junit'` command :
-
- -> ps
- START LEVEL 1
- ID State Level Name
- ...
- [ 12] [Active ] [ 1] Junit-Example (0)
- ...
- -> junit 12
- Executing [Money Simple Test Suite]
- ..
- Time: 0
- OK (2 tests)
- ->
-
-As you can see above, all tests have been correctly executed !
-
-== An OSGi-based JUnit example
-
-This example shows you how to interact with the OSGi framework within your tests.
-The test bundle provide a service (HelloService) and tests its work normally.
-To get the service reference of the HelloService, it uses the bundle context field of the OSGiTestCase class (named `'context'`) and interacts with it like any other OSGi bundle does.
-
-----
-package junit.example;
-
-import junit.service.hello.HelloService;
-
-import org.apache.felix.ipojo.junit4osgi.OSGiTestCase;
-import org.osgi.framework.ServiceReference;
-
-public class SimpleTestCase extends OSGiTestCase {
-
- public void testHelloAvailability() {
- ServiceReference ref = getServiceReference(HelloService.class.getName());
- assertNotNull("Assert Availability", ref);
- }
-
- public void testHelloAvailability2() {
- ServiceReference ref = getServiceReference(HelloService.class.getName(), null);
- assertNotNull("Assert Availability", ref);
- }
-
- public void testHelloMessage() {
- ServiceReference ref = getServiceReference(HelloService.class.getName());
- assertNotNull("Assert Availability", ref);
- HelloService hs = (HelloService) getContext().getService(ref);
- String message = hs.getHelloMessage();
- assertNotNull("Check the message existence", message);
- assertEquals("Check the message", "hello", message);
- // Don't need to unget references, they are unget by junit4osgi
- }
-
- public void testHelloMessage2() {
- assertTrue("Check availability of the service",
- isServiceAvailable(HelloService.class.getName()));
- HelloService hs = (HelloService) getServiceObject(HelloService.class.getName(), null);
- String message = hs.getHelloMessage();
- assertNotNull("Check the message existence", message);
- assertEquals("Check the message", "hello", message);
- }
-}
-----
-
-The performed tests give out the following results :
-
- -> ps
- START LEVEL 1
- ID State Level Name
- ...
- [ 17] [Active ] [ 1] Junit-OSGi-Example (0)
- ...
- -> services 17
- Junit-OSGi-Example (17) provides:
- ---------------------------------
- objectClass = junit.service.hello.HelloService
- service.id = 36
- -> junit 17
- Executing [Hello Service Test Suite]
- ..
- Time: 0,015
- OK (4 tests)
- ->
-
-== Simple right?
-
-[cols=2*]
-|===
-| So now you know everything required to run test inside OSGi.
-You can start developing your own test.
-To help you a little bit, junit4osgi provides xref:documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-junit4osgi/apache-felix-ipojo-junit4osgi-methods.adoc[utilities methods] greatly reducing the amount of code to write in your tests.
-Moreover, if you're a Maven user, the [maven-junit4osgi-plugin
-| apache-felix-ipojo-junit4osgi-maven] is made for you.
-It just runs your test directly during the maven build process.
-|===
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-keypoints.adoc b/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-keypoints.adoc
deleted file mode 100644
index 9f75804..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-keypoints.adoc
+++ /dev/null
@@ -1,70 +0,0 @@
-= iPOJO Key Points
-
-_iPOJO is a service-oriented component model.
-What_'_s made iPOJO different?
-Just read this page._
-
-== Used
-
-iPOJO is used a several and really heterogeneous domain.
-iPOJO is today used in mobile phone, in home gateway as well as in JEE servers!
-Module Fusion also proposes to use iPOJO for enterprise applications.
-
-== Philosophy
-
-iPOJO aims to be simple.
-The proposed development model is definitely simple.
-Do worry about all the obscured technical service and bindings details, just focus on your code.
-iPOJO manages the everything for you.
-Moreover, it was designed for the OSGi environment.
-It places the service concept as a top-level concept providing a better reusability, allowing implementation substitution and managing the dynamism.
-
-== Supported
-
-iPOJO is now supported by different companies and research center such as akquinet, Grenoble University, Bull...
-
-== Easy to use
-
-Based on the POJO concept and thanks to its different injection mechanisms, iPOJO allows you to reuse he high majority of your existing code!
-The business code does not depend on the OSGi environment or on specific technical services.
-The container manages everything for you.
-
-with iPOJO you're free!
-To describe your component, you have the choice among XML, Annotations or an API.
-
-== Reliable and Efficient
-
-iPOJO relies on:
-
-* An OSGi R4.1 framework
-* A J2ME Foundation 1.1 java virtual machine
-
-So, you can use iPOJO on Apache Felix, Eclipse Equinox or any OSGi implementation compliant with the OSGi R4.1 specification.
-Moreover, iPOJO just relies on J2ME Foundation 1.1 profile.
-So, you can easily embed it...
-However, this does not limit iPOJO in term of performance.
-iPOJO is one of the most efficient component models for OSGi.
-
-== Embeddable
-
-As told in the previous section, iPOJO does not required advanced Java Virtual Machine.
-Moreover its footprint is quite small.
-iPOJO Core size is only 200Kb !
-No more is required to use iPOJO...
-
-== Adaptable
-
-iPOJO provides a very simple extensibility mechanism.
-So, you can extend iPOJO for your own requirement.
-Just look to the list of available handler (i.e.
-extension).
-Almost everything is possible...
-
-== Going further
-
-* Want to go further;
-read the xref:documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-why-choose-ipojo.adoc[Why choose iPOJO page].
-* Want to try;
-look at the xref:documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-gettingstarted/ipojo-in-10-minutes.adoc[iPOJO in 10 minutes tutorial]
-* Want more information;
-feel free to send an email on link:mailto:users@felix.apache.org[users@felix.apache.org]
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-successstories.adoc b/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-successstories.adoc
deleted file mode 100644
index 3df1c81..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-successstories.adoc
+++ /dev/null
@@ -1,69 +0,0 @@
-= iPOJO Success Stories
-
-_On this page, you will find comments from industrial users of iPOJO.
-They come from different domains such as home gateways, mobile phones, or enterprise applications._
-
-[#schneider]
-[quote,'Sylvain Marie, Software Architect, Schneider Electric']
-____
-Over 90% of processors are now used for embedded applications.
-At Schneider Electric we believe that java is a fantastic opportunity to develop some of our applications faster and better.
-OSGi is an excellent way to ensure that developed java software comes with built-in best practices such as reusability, high cohesion, loose coupling, high flexibility and dynamism.But we definitely don't want our anticipation teams to spend more time on OSGi mechanisms than on Energy Management, our core business!
-iPOJO helps us to develop quickly, by making developing modules as simple as writing plain old java.
-We also use it for our open source OSGi DPWS Base Driver ('SOA for devices' forge, on http://forge.soa4d.org/).
-And it's not just about us: partners of the SOA4D forge are using it, too.
-____
-
-
-'''
-
-[#ugasp]
-[quote,'Romain Pellerin, Ubidreams CEO']
-____
-Ubiquitous Multi-player games are one of next trends of mobile games.
-This type of games offers new experience: users interact with the real world and with the virtual world at the same time!
-So, player actions such as moves, interactions with smart objects or others players impact the virtual part of the game.
-The state of the virtual games also impacts the possibilities in the physical part of the games.
-Creating this kind of games requires managing several types of technologies such as embedded devices (mobile phones, PDA, sensors\...), smart objects (RFID, environmental sensors\...) and network connectivity (GSM, Edge, 3G, Wifi, Bluetooth\...).
-uGasp (Ubiquitous Gaming Services Platform) is a middleware used to execute ubiquitous multi-player games.
-It provides an abstraction layer hiding the inherent complexity of such games.
-uGasp is a major evolution of the Gasp framework using a monolithic stack not suitable to embedded devices.
-To tackle this issue, we adopted a dynamic, modular, extensible and configurable architecture.
-But in order to speed up the development, uGasp is based on a service -oriented component model offering all the features "for free" and simplifying the development of dynamic applications.
-uGasp is based on Apache Felix and iPOJO.
-We chose iPOJO for several reasons:
-
-* iPOJO drastically simplifies the development of OSGi-based applications.
-The intuitive XML description is really simple to use even for a novice developer.
-* iPOJO allows reusing a lot of object-oriented code thanks to the field injection.
-So, migrating GASP to uGASP takes only three weeks!
-* The factory principles offered by iPOJO allows creating several games instance at the same time.
-* Finally, the isolation characteristic was a critical requirement in the uGasp middleware.
-Moreover, for the developer point of view, this is completely hidden.
-
-To get more info about uGasp, visit our http://gasp.objectweb.org/ubiquitous-osgi-middleware.html[web site] or contact http://www.ubidreams.com[Ubidreams].
-____
-
-
-'''
-
-[#jonas]
-[quote,'Guillaume Sauthier, JOnAS Application Server Developer']
-____
-JOnAS is a Java EE server developed inside the OW2 consortium.
-It embraces the new trend of modular and dynamic application servers and aims at implementing the entire Java EE specification by re-using third-part components.
-JOnAS also focuses on providing a great flexibility for the developer, for the administrator and for clustering.
-To enable this flexibility and dynamism in the application server components' integration, the JOnAS team chose to rely on an OSGi runtime.
-However, it quickly appeared that any manual management of the dynamism would be too expensive: not only very few programmers understand the complexity of the dynamism, but also manual maintaining is extremely difficult and error-prone.
-That's why JOnAS uses a service-oriented component model.
-We first chose iPOJO because this technology sounded really promising.
-Moreover, iPOJO is able to evolve against new requirements, thanks to the handler-based extensibility model it promotes.
-In the JOnAS application server all the technical services are implemented by iPOJO components.
-Thanks to this framework, they are pluggable and upgradeable on-demand.
-As iPOJO reduces drastically the impact on the code, we have reused the high majority of our code and the migration from the former JOnAS to this one has been surprisingly quick.
-The JOnAS team is very happy with iPOJO, and will go on using, promoting and improving it.
-If you want more info on JOnAS visit our http://wiki.jonas.objectweb.org/xwiki/bin/view/Main/WebHome[website].
-____
-
-*Are you also using iPOJO ?* + You are using iPOJO, and you want to be listed there to tell how you are using iPOJO.
-Feel free to send us link:mailto:clement@apache.org[a mail] with your story.
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-supportedosgi.adoc b/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-supportedosgi.adoc
deleted file mode 100644
index ec73332..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-supportedosgi.adoc
+++ /dev/null
@@ -1,53 +0,0 @@
-= Supported OSGi Implementations
-
-_Despite iPOJO is an Apache Felix subproject, it relies only on *OSGi R4_ features.
-So, it is possible to use it on others OSGi implementations.*
-
-|===
-| Features | Apache Felix | Eclipse Equinox | Knowplerfish
-
-| Core features
-| __
-| __
-| __
-
-| Composites features
-| __
-| __
-| __
-
-| Configuration Admin
-| __
-| __
-| __
-
-| Temporal service dependencies
-| __
-| __
-| __
-
-| Whiteboard and Extender pattern handler
-| __
-| __
-| __
-
-| Event admin handler
-| __
-| __
-| __
-
-| JMX handler
-| __
-| __
-| __
-|===
-
-Feel free to send a mail on the Felix mailing list, if an implementation is not listed here.
-
-'''
-
-ALERT: Old version of Knopflerfish does not allow getting a service during its unregistration.
-To enable this feature, launch the Knopflerfish framework with the `-Dorg.knopflerfish.servicereference.valid.during.unregistering=true` property.
-You can add this property in the `props.xargs` file.
-
-Recent version of KF does no more require this property.
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-supportedvms.adoc b/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-supportedvms.adoc
deleted file mode 100644
index 26fbf7f..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-supportedvms.adoc
+++ /dev/null
@@ -1,74 +0,0 @@
-= Supported Java Virtual Machines
-
-|===
-| Features | Sun JVM (1.4, 5, 6) | Oracle JVM and OpenJDK | Harmony | JamVM | Mika | JRockit | Dalvik (Android)
-
-| Core features
-| __
-| __
-| __
-| __
-| __
-| __
-| __
-
-| Composites features
-| __
-| __
-| __
-| __
-| __
-| __
-| __
-
-| Configuration Admin
-| __
-| __
-| __
-| __
-| __
-| __
-| __
-
-| Temporal service dependencies
-| __
-| __
-| __
-| __
-| __
-| __
-| __
-
-| Whiteboard and Extender pattern handler
-| __
-| __
-| __
-| __
-| __
-| __
-| __
-
-| Event admin handler
-| __
-| __
-| __
-| __
-| __
-| __
-| __
-|===
-
-Feel free to send a mail on the Felix mailing list if a JVM is not listed here.
-
-'''
-
-INFO: *Note about Android* iPOJO is supported on Android except for two features:
-
-* Nullable are not supported (Default-Implementations are supported)
-* Composites cannot provide services (but they can export services)
-
-These two limitations comes from the Android VM (Dalvik) that does not support the definition of new classes at runtime (i.e.
-dynamically generated classes).
-
-INFO: *Note about Android* iPOJO 1.6+ uses smart proxy by default.
-On Android this is not supported, however, you can disable the proxies with: `proxy="false"` in the service requirements.
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-testing-components.adoc b/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-testing-components.adoc
deleted file mode 100644
index 1403c9f..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-testing-components.adoc
+++ /dev/null
@@ -1,104 +0,0 @@
-= How to test iPOJO Components
-
-Testing components is a required step in the application development process.
-This page explains strategies to test iPOJO-based components and applications.
-
-== Introduction
-
-Basically, we can distinguish 2 types of tests:
-
-* Unitary tests
-* Integration tests
-
-[cols=2*]
-|===
-| Unitary tests are famous and were popularized with the proliferation of frameworks like http://junit.org[Junit] and [TestNG
-| http://testng.org/doc/].
-These tests check the behavior of classes.
-More specially, these tests check the method results according to different parameter values.
-These test are executed outside the execution environment, can use mock object (link) to replace/simulate missing dependencies...
-|===
-
-Integration tests focus on the execution of the application inside the execution environment.
-It checks the global behavior of a service or an application.
-In the case of iPOJO, those tests are executed on OSGi.
-Some dependencies can be also replaced by mock services/objects.
-
-== Executing unitary tests on iPOJO components
-
-Unitary tests allow checking the internal behavior of an iPOJO component.
-Those tests ignore the injected dependencies and focus only on the business code of the component.
-
-To test components, you can use Junit.
-A special constructor setting fields can do the dependency injection.
-These tests are executed before the bundlelization.
-
-Let's imagine a maven project.
-Unitary tests are placed in the src/test/java folder.
-You can use mock object as illustrated in the example.
-When you launch the `mvn clean install` command, maven compiles your classes and executes the tests.
-If the tests are executed successfully, the build process continues and creates the bundle as follows:
-
-----
-[INFO] Scanning for projects...
-[INFO] ------------------------------------------------------------------------
-[INFO] Building Dummy Component
-[INFO] task-segment: [clean, install]
-[INFO] ------------------------------------------------------------------------
-[INFO] [clean:clean]
-[INFO] Deleting directory /Users/clement/Documents/workspaces/ipojo-dev/UnitaryTest/target
-[INFO] [resources:resources]
-[INFO] Using default encoding to copy filtered resources.
-[INFO] [compiler:compile]
-[INFO] Compiling 1 source file to /Users/clement/Documents/
- workspaces/ipojo-dev/UnitaryTest/target/classes
-[INFO] [resources:testResources]
-[INFO] Using default encoding to copy filtered resources.
-[INFO] [compiler:testCompile]
-[INFO] Compiling 1 source file to /Users/clement/Documents/
- workspaces/ipojo-dev/UnitaryTest/target/test-classes
-[INFO] [surefire:test]
-[INFO] Surefire report directory: /Users/clement/Documents/
- workspaces/ipojo-dev/UnitaryTest/target/surefire-reports
-
--------------------------------------------------------
- T E S T S
--------------------------------------------------------
-Running org.apache.felix.ipojo.ut.component.test.MyTestCase
-Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.076 sec
-
-Results :
-
-Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
-
-[INFO] [bundle:bundle]
-[INFO] [ipojo:ipojo-bundle {execution: default}]
-[INFO] Start bundle manipulation
-[INFO] Metadata file : /Users/clement/Documents/
- workspaces/ipojo-dev/UnitaryTest/target/classes/metadata.xml
-[INFO] Input Bundle File : /Users/clement/Documents/workspaces/
- ipojo-dev/UnitaryTest/target/org.apache.felix.ipojo.test.dummy.component-1.1.0-SNAPSHOT.jar
-[INFO] Bundle manipulation - SUCCESS
-[INFO] [install:install]
-[INFO] Installing /Users/clement/Documents/workspaces/
- ipojo-dev/UnitaryTest/target/org.apache.felix.ipojo.test.dummy.component-1.1.0-SNAPSHOT.jar
- to /Users/clement/.m2/repository/ipojo/tests/org.apache.felix.ipojo.test.dummy.component/1.1.0-SNAPSHOT
- /org.apache.felix.ipojo.test.dummy.component-1.1.0-SNAPSHOT.jar
-[INFO] [bundle:install]
-[INFO] Parsing file:/Users/clement/.m2/repository/repository.xml
-[INFO] Installing ipojo/tests/org.apache.felix.ipojo.test.dummy.component/
- 1.1.0-SNAPSHOT/org.apache.felix.ipojo.test.dummy.component-1.1.0-SNAPSHOT.jar
-[INFO] Writing OBR metadata
-[INFO] ------------------------------------------------------------------------
-[INFO] BUILD SUCCESSFUL
-[INFO] ------------------------------------------------------------------------
-[INFO] Total time: 6 seconds
-[INFO] Finished at: Tue Oct 21 14:03:03 CEST 2008
-[INFO] Final Memory: 11M/25M
-[INFO] ------------------------------------------------------------------------
-----
-
-== Executing integration tests
-
-We recommend to use Pax Exam 3 to test iPOJO components.
-More details about pax exam 3 are available https://ops4j1.jira.com/wiki/display/PAXEXAM3/Pax+Exam[here].
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-tools/apache-felix-ipojo-online-manipulator.adoc b/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-tools/apache-felix-ipojo-online-manipulator.adoc
deleted file mode 100644
index bf56c76..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-tools/apache-felix-ipojo-online-manipulator.adoc
+++ /dev/null
@@ -1,61 +0,0 @@
-= Apache Felix iPOJO Online Manipulator
-
-_iPOJO generally requires an additional packaging step to prepare the bundle to be managed by iPOJO.
-Despite this step doesn't change the class semantic, it can be a little annoying.
-The online manipulator avoids this offline step!_
-
-
-
-== Features
-
-iPOJO is based on a bytecode manipulation.
-This manipulate is _safe_ and does not change the class semantics.
-Classes can still used after the manipulation without iPOJO.
-However this manipulation is required for iPOJO management.
-Generally, this manipulation occurs offline during the packaging time.
-The online manipulator allows to do this manipulation at install time.
-
-The online manipulator:
-
-* avoids offline manipulation
-* supports annotations
-* supports XSD schema
-
-This is quite useful if you don't want to add an extra packaging step, and provides the same capabilities as the "regular" way.
-
-== Usage
-
-The online-manipulator is in fact an URL Handler.
-So, it will process every bundle using a special URL prefix.
-To use it, just follows the below instructions:
-
-=== Install and Start the URL Handler
-
-Download and install the iPOJO online manipulator.
-You can download it from the http://felix.apache.org/downloads.cgi[Felix download page]
-
-=== Install a bundle using the _ipojo:_ URL prefix
-
-Using the handler is quite easy.
-When you want to deploy a non-manipulated iPOJO bundle just use an url like
-
-[source,sh]
- install ipojo:file:/.../bundle.jar
-
-The complete URL syntax is
-
-[source,sh]
- install ipojo:bundle_url[!metadata_url]
-
-When using the `ipojo:` prefix, the OSGi platform delegates the loading to the url handler manipulating the bundle before its installation.
-This manipulation is exactly the same as the offline manipulation.
-
-== Dealing with metadata
-
-If the installed bundle contains a `metadata.xml` file either in its root or in the `META-INF` directory, the online manipulator will use it.
-However, you can also provide an external `metadata.xml` file by indicating the url of the file like in
-
-[source,sh]
- install ipojo:bundle_url!metadata_url
-
-If you provide such url, it will override the contained `metadata.xml` file.
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-tools/ipojo-ant-task.adoc b/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-tools/ipojo-ant-task.adoc
deleted file mode 100644
index 1924e3e..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-tools/ipojo-ant-task.adoc
+++ /dev/null
@@ -1,129 +0,0 @@
-= iPOJO Ant Task
-
-_iPOJO Ant Task allows automating the iPOJO manipulation process within an Ant build process.
-This page explains how to use the iPOJO Ant Task and how to combine them with the BND Tasks._
-
-
-
-== Downloading the iPOJO Ant Task
-
-The iPOJO Ant Task can ben downloaded from http://felix.apache.org/downloads.cgi[here].
-
-== How to use the Ant Task
-
-The iPOJO Ant task take an input bundle and a metadata file and create the final (i.e.
-manipulated) bundle.
-To use the task declare a target in your build.xml as:
-[source,xml]
- <target name="main">
- <!-- Change the path to point on the iPOJO Ant task jar-->
- <taskdef name="ipojo"
- classname="org.apache.felix.ipojo.task.IPojoTask"
- classpath="org.apache.felix.ipojo.ant-{{ipojo.release}}.jar"/>
- <ipojo
- input="foo.jar"
- metadata = "meta.xml"
- />
- </target>
-
-First, define the new task.
-Then simply use it.
-The input argument describe the input bundle (must exists) and the metadata argument describes the metadata file (must exist too).
-The input bundle must be a well-formed bundle.
-
-== Ant Task Arguments
-
-The iPOJO Ant Task as three different arguments:
-
-* Input: describes the input bundle.
-This argument is mandatory.
-* Output: describes the output bundle.
-This argument is optional.
-If not present, the output file will be input file.
-* Metadata: describes the metadata file.
-This argument is optional.
-By default, it tries with a metadata.xml file (in the same directory as the build.xml file).
-If the default file is not present, it tries to use only iPOJO annotations.
-* IgnoreAnnotations: if set to `true`, the manipulator skips annotations processing (can reduce significantly the processing time on huge bundle).
-* IgnoreEmbeddedSchemas: if set to `true`, the manipulator doesn't use embedded XML-Schemas
-
-== Combining the iPOJO Ant Task and BND
-
-The iPOJO Ant Task requires an input bundle.
-BND is a tools simplifying bundle creation.
-So, it is possible to combine the two tools to create your bundle automatically.
-The following build.xml shows you an example of combination.
-[source,xml]
- <project default="main" basedir=".">
- <target name="bnd">
- <!-- Change to use the latest BND version -->
- <taskdef resource="aQute/bnd/ant/taskdef.properties"
- classpath="bnd-0.0.178.jar"/>
- <bnd
- classpath="src"
- eclipse="true"
- failok="false"
- exceptions="true"
- files="foo.bnd"/>
- </target>
- <target name="main" depends="bnd">
- <echo message="Call main"/>
- <!-- Change the path to point on the iPOJO Ant task jar -->
- <taskdef name="ipojo"
- classname="org.apache.felix.ipojo.task.IPojoTask"
- classpath="org.apache.felix.ipojo.ant-{{ipojo.release}}.jar" />
- <!-- the input attribute must fit the .bnd file name -->
- <ipojo
- input="foo.jar"
- metadata = "meta.xml"
- />
- </target>
- </project>
-
-The first target creates the bundle with BND.
-More details on the BND Ant Task are available here.
-To combine the BND output and the iPOJO input, the iPOJO input need to be the same as the BND file but with the ".jar" extension.
-For instance, the BND file is foo.bnd, so the input jar must be foo.jar.
-To be sure that the BND bundle is already created, you can add the "_depends_" clause in the target using the iPOJO task to the target creating the bundle.
-
-However, it is possible to create only one target doing the two operations as:
-[source,xml]
- <target name="main">
- <!-- Change to use the latest BND version -->
- <taskdef
- resource="aQute/bnd/ant/taskdef.properties"
- classpath="bnd-0.0.178.jar"/>
- <!-- Change the path to point on the iPOJO Ant task jar -->
- <taskdef name="ipojo"
- classname="org.apache.felix.ipojo.task.IPojoTask"
- classpath="org.apache.felix.ipojo.ant-{{ipojo.release}}.jar"/>
- <bnd
- classpath="src"
- eclipse="true"
- failok="false"
- exceptions="true"
- files="foo.bnd"/>
- <ipojo
- input="foo.jar"
- metadata = "meta.xml"/>
- </target>
-
-== Directory manipulation
-
-The manipulator can take a directory in input.
-In this case, classes from this folder is manipulated.
-You can also set the manifest file location too.
-Here in an example of configuration using this mode:
-[source,xml]
- <target name="manipulate">
- <!-- Set the manipulated directory and manifest location -->
- <ipojo
- dir="${output..}"
- metadata="metadata.xml"
- manifest="META-INF/MANIFEST.MF"
- />
- </target>
-
-=== ALERT Manifest location
-
-If not set, the manifest is searched in the given `directory/META-INF` folder (_i.e._ `$dir/META-INF/MANIFEST.MF`).
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-tools/ipojo-arch-command.adoc b/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-tools/ipojo-arch-command.adoc
deleted file mode 100644
index 1b13867..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-tools/ipojo-arch-command.adoc
+++ /dev/null
@@ -1,179 +0,0 @@
-= iPOJO architecture commands
-
-_Architecture introspection is required when the system doesn't work as expected.
-In this case, having a quick access to instances states and interconnection is a stringent requirement.
-The architecture commands allows getting these data from the Felix Shell, from the Equinox shell and Gogo._
-
-
-
-== Installation
-
-According to your shell, download the adequate bundles from http://felix.apache.org/downloads.cgi[the Felix download page]
-
-== Gogo
-
-The Gogo commands are the following:
-
-* `ipojo:instances` (or just `instances`) lists the instances and state
-* `ipojo:instance $instance_name` (or just `instance $instance_name`) displays the complete information about the specified $instance_name
-* `ipojo:factories` (or just `factories`) lists the available public factories
-* `ipojo:factory $factory_name` (or just `factory $factory_name`) displays complete information about the factory $factory_name
-* `ipojo:handlers` (or just `handlers` lists available handlers
-
-For example:
-
-[source,sh]
-----
-$ instances
-Instance ArchCommand -> valid
-Instance spell.english.EnglishDictionary-0 -> valid
-Instance spell.checker.SpellCheck-0 -> valid
-Instance spell.gui.SpellCheckerGui-0 -> valid
-
-$ instance spell.checker.SpellCheck-0
-instance component.type="spell.checker.SpellCheck" state="valid" bundle="8" name="spell.checker.SpellCheck-0"
- handler state="valid" name="org.apache.felix.ipojo.handlers.dependency.DependencyHandler"
- requires optional="false" aggregate="false" state="resolved" binding-policy="dynamic" specification="spell.services.DictionaryService"
- handler state="valid" name="org.apache.felix.ipojo.handlers.providedservice.ProvidedServiceHandler"
- provides service.id="36" state="registered" specifications="[spell.services.SpellChecker]"
- property value="spell.checker.SpellCheck" name="factory.name"
- property value="spell.checker.SpellCheck-0" name="instance.name"
- handler state="valid" name="org.apache.felix.ipojo.handlers.architecture.ArchitectureHandler"
-----
-
-== Equinox and Felix Shells
-
-On Equinox and Felix (old) shell, the command is named _arch_:
-
-* arch \=> displays instances name & state (equivalent to arch -instances)
-* arch -instance $instance__name \=> displays complete information about the instance $instance__name
-* arch -factories \=> display the list of available factories
-* arch -factory $factory__name \=> display complete information about the factory $factory__name
-* arch -handlers \=> list available handlers
-
-=== Examples
-
-[source,sh]
-----
--> arch
-Instance ArchCommand -> valid
-Instance spell.english.EnglishDictionary-0 -> valid
-Instance spell.checker.SpellCheck-0 -> valid
-Instance spell.gui.SpellCheckerGui-0 -> valid
-
--> arch -instance spell.checker.SpellCheck-0
-instance component.type="spell.checker.SpellCheck" state="valid" bundle="8" name="spell.checker.SpellCheck-0"
- handler state="valid" name="org.apache.felix.ipojo.handlers.dependency.DependencyHandler"
- requires optional="false" aggregate="false" state="resolved" binding-policy="dynamic" specification="spell.services.DictionaryService"
- handler state="valid" name="org.apache.felix.ipojo.handlers.providedservice.ProvidedServiceHandler"
- provides service.id="36" state="registered" specifications="[spell.services.SpellChecker]"
- property value="spell.checker.SpellCheck" name="factory.name"
- property value="spell.checker.SpellCheck-0" name="instance.name"
- handler state="valid" name="org.apache.felix.ipojo.handlers.architecture.ArchitectureHandler"
-----
-
-== Reading instance architecture:
-
-Instance architecture is organized as follows:
-
-* On the first line, are displayed the component type (i.e.
-factory), the instance state (`valid` or `invalid`), the bundle from which the instance is created, and the instance name.
-* Then, the information is organized handler by handler (a piece of container).
-For each handler plugged on the instance can participate to the instance architecture.
-For each handler its name (such as ` org.apache.felix.ipojo.handlers.dependency.DependencyHandler`` for iPOJO service dependencies, `` org.apache.felix.ipojo.handlers.providedservice.ProvidedServiceHandler``+ for iPOJO service providing...) and the state (either +``valid`` or ``invalid` are displayed.
-Remember that an instance is valid only and only if all plugged handlers are valid.
-* The `org.apache.felix.ipojo.handlers.dependency.DependencyHandler` provides data on service dependencies and more precisely on the state of service dependencies.
-In the previous example, the dependency on ` spell.services.DictionaryService` was resolved.
-On the following example, the same dependency is no more resolved.
-
-As an example, the following snippet dumps the architecture of an instance:
-
-[source,sh]
- instance component.type="spell.checker.SpellCheck" state="invalid" bundle="8" name="spell.checker.SpellCheck-0"
- handler state="invalid" name="org.apache.felix.ipojo.handlers.dependency.DependencyHandler"
- requires optional="false" aggregate="false" state="unresolved" binding-policy="dynamic" specification="spell.services.DictionaryService"
- handler state="valid" name="org.apache.felix.ipojo.handlers.providedservice.ProvidedServiceHandler"
- provides state="unregistered" specifications="[spell.services.SpellChecker]"
- property value="spell.checker.SpellCheck" name="factory.name"
- property value="spell.checker.SpellCheck-0" name="instance.name"
- handler state="valid" name="org.apache.felix.ipojo.handlers.architecture.ArchitectureHandler"
-
-Notes that, the instance also becomes invalid and that the provided service is unregistered.
-If the provider comes back, the dependency becomes `resolved` and the instance becomes `valid` If an instance begins to use a service, the bound providers are described in the instance architecture:
-
-[source,sh]
- instance component.type="spell.checker.SpellCheck" state="valid" bundle="8" name="spell.checker.SpellCheck-0"
- object name="spell.checker.SpellCheck@e222eb"
- handler state="valid" name="org.apache.felix.ipojo.handlers.dependency.DependencyHandler"
- requires optional="false" aggregate="false" state="resolved" binding-policy="dynamic" specification="spell.services.DictionaryService"
- uses service.id="41" instance.name="spell.english.EnglishDictionary-0"
- handler state="valid" name="org.apache.felix.ipojo.handlers.providedservice.ProvidedServiceHandler"
- provides service.id="42" state="registered" specifications="[spell.services.SpellChecker]"
- property value="spell.checker.SpellCheck" name="factory.name"
- property value="spell.checker.SpellCheck-0" name="instance.name"
- handler state="valid" name="org.apache.felix.ipojo.handlers.architecture.ArchitectureHandler"
-
-In the previous case, the dependency on ` spell.services.DictionaryService`` use the service 41 from the iPOJO instance named `` spell.english.EnglishDictionary-0`` You can also check created POJO objects (implementation class objet).
-Here, only one object was created (``spell.checker.SpellCheck@e222eb`).
-
-== List available factories
-
-You can access factory list using the `factories` gogo command or the `arch -factories` on Felix's shell.
-For every available (public) factories,the name and the state are displayed.
-A factory is valid if and only if all required handlers are available.
-
-[source,sh]
- -> arch -factories
- Factory spell.checker.SpellCheck (VALID)
- Factory spell.gui.SpellCheckerGui (VALID)
- Factory spell.english.EnglishDictionary (VALID)
- -> arch -factory spell.english.EnglishDictionary
- factory implementation-class="spell.english.EnglishDictionary" state="valid" bundle="7" name="spell.english.EnglishDictionary"
- provides specification="spell.services.DictionaryService"
- missinghandlers list="[]"
- requiredhandlers list="[org.apache.felix.ipojo:provides, org.apache.felix.ipojo:architecture]"
-
-On Gogo:
-
-[source,sh]
- $factories
- Factory spell.checker.SpellCheck (VALID)
- Factory spell.gui.SpellCheckerGui (VALID)
- Factory spell.english.EnglishDictionary (VALID)
- $factory spell.english.EnglishDictionary
- factory implementation-class="spell.english.EnglishDictionary" state="valid" bundle="7" name="spell.english.EnglishDictionary"
- provides specification="spell.services.DictionaryService"
- missinghandlers list="[]"
- requiredhandlers list="[org.apache.felix.ipojo:provides, org.apache.felix.ipojo:architecture]"
-
-On the first line, you get the implementation class of the type, the state of the factory, the bundle declaring the type and the name of the type.
-You also get the list of required and missing handlers.
-
-== List available handlers
-
-Like listing factories, you can get the list of handlers.
-
-[source,sh]
- -> arch -handlers
- Handler org.apache.felix.ipojo:controller (VALID)
- Handler org.apache.felix.ipojo:callback (VALID)
- Handler org.apache.felix.ipojo:requires (VALID)
- Handler org.apache.felix.ipojo:provides (VALID)
- Handler org.apache.felix.ipojo:properties (VALID)
- Handler org.apache.felix.ipojo:architecture (VALID)
- Handler org.apache.felix.ipojo.handler.whiteboard:wbp (VALID)
-
-On Gogo:
-
-[source,sh]
- $handlers
- Handler org.apache.felix.ipojo:controller (VALID)
- Handler org.apache.felix.ipojo:callback (VALID)
- Handler org.apache.felix.ipojo:requires (VALID)
- Handler org.apache.felix.ipojo:provides (VALID)
- Handler org.apache.felix.ipojo:properties (VALID)
- Handler org.apache.felix.ipojo:architecture (VALID)
- Handler org.apache.felix.ipojo.handler.whiteboard:wbp (VALID)
-
-Handlers with the `org.apache.felix.ipojo` namespace (section before `:`) are core handlers (provided by the iPOJO core bundles).
-Others are external handlers (provided by others bundles).
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-tools/ipojo-karaf-feature.adoc b/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-tools/ipojo-karaf-feature.adoc
deleted file mode 100644
index ae3282b..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-tools/ipojo-karaf-feature.adoc
+++ /dev/null
@@ -1,24 +0,0 @@
-= iPOJO Karaf Features
-
-If you are using http://karaf.apache.org[Apache Karaf], there is a set of _features_ easing the deployment of iPOJO bundles and related tools on Karaf.
-
-== Add the features file
-
-First, launch Karaf and add the http://repo1.maven.org/maven2/org/apache/felix/org.apache.felix.ipojo.features/{{ipojo.release}}/org.apache.felix.ipojo.features-{{ipojo.release}}.xml[iPOJO Feature] file:
-
-[source,sh]
- features:addurl http://repo1.maven.org/maven2/org/apache/felix/org.apache.felix.ipojo.features/{{ipojo.release}}/org.apache.felix.ipojo.features-{{ipojo.release}}.xml
-
-== Installing features:
-
-Several features are available:
-
-* `ipojo`: contains the iPOJO Core Runtime
-* `ipojo-command`: extends the `ipojo` feature with the iPOJO Shell Commands
-* `ipojo-all`: contains the iPOJO Core Runtime, Shell Commands, Composition Model, and API
-* `ipojo-webconsole`: install the Apache Felix WebConsole, iPOJO Core Runtime and the iPOJO Plugin for the Web Console.
-
-Installing a feature is quite simple:
-
-[source,sh]
- features:install ipojo-command
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-tools/ipojo-maven-plug-in.adoc b/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-tools/ipojo-maven-plug-in.adoc
deleted file mode 100644
index 78b6036..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-tools/ipojo-maven-plug-in.adoc
+++ /dev/null
@@ -1,241 +0,0 @@
-= How to use the iPOJO Maven Plug-in
-
-== Basic configuration
-
-To use the iPOJO Maven plug-in, edit the following pom.xml (replace all $XXX elements):
-[source,xml]
- <project>
- <modelVersion>4.0.0</modelVersion>
- <groupId>$YOUR_GROUP_ID</groupId>
- <artifactId>$YOUR_ARTIFACT_ID</artifactId>
- <version>$YOUR_ARTIFACT_VERSION</version>
- <name>$YOUR_PROJECT_NAME</name>
- <!-- Use the bundle packaging type -->
- <packaging>bundle</packaging>
- <dependencies>
- $YOUR_MAVEN_DEPENDENCIES
- </dependencies>
- <build>
- <plugins>
- <!-- BND Maven Plugin Configuration -->
- <plugin>
- <groupId>org.apache.felix</groupId>
- <artifactId>maven-bundle-plugin</artifactId>
- <extensions>true</extensions>
- <configuration>
- <instructions>
- <Bundle-SymbolicName>${pom.artifactId}</Bundle-SymbolicName>
- <Private-Package>$YOUR_PRIVATE_PACKAGE</Private-Package>
- <Export-Package>$YOUR_EXPORTED_PACKAGE</Export-Package>
- </instructions>
- </configuration>
- </plugin>
- <plugin>
- <groupId>org.apache.felix</groupId>
- <artifactId>maven-ipojo-plugin</artifactId>
- <version>{{ipojo.release}}</version>
- <executions>
- <execution>
- <goals>
- <goal>ipojo-bundle</goal>
- </goals>
- </execution>
- </executions>
- </plugin>
- </plugins>
- </build>
- </project>
-
-The iPOJO Maven Plug-in is generally used with the BND Maven Plug-in (more details here).
-However the two configurations are completely separated.
-So, you can use all BND Maven plug-in features.
-The iPOJO configuration section can be used as previously written without any changes.
-However it requires that your metadata file is either inside `src/main/ipojo` or inside the `src/main/resources` folder and named "metadata.xml".
-
-== Execution
-
-To manipulate your project, use the "_mvn clean install_" command.
-The output should be like:
-
-[source,sh]
- [INFO] Scanning for projects...
- [INFO] ----------------------------------------------------------------------------
- [INFO] Building Hello Client
- [INFO] task-segment: [clean, install]
- [INFO] ----------------------------------------------------------------------------
- [INFO] [clean:clean]
- [INFO] Deleting directory ...hello.client\target
- [INFO] Deleting directory ...hello.client\target\classes
- [INFO] Deleting directory ...hello.client\target\test-classes
- [INFO] Deleting directory ...hello.client\target\site
- [INFO] [resources:resources]
- [INFO] Using default encoding to copy filtered resources.
- [INFO] Copying 1 resource
- [INFO] [compiler:compile]
- [INFO] Compiling 1 source file to ...hello.client\target\classes
- [INFO] [resources:testResources]
- [INFO] Using default encoding to copy filtered resources.
- [INFO] Resource directory does not exist: ...hello.client\src\test\resources
- [INFO] [compiler:testCompile]
- [INFO] No sources to compile
- [INFO] [surefire:test]
- [INFO] No tests to run.
- [INFO] [bundle:bundle]
- [INFO] [org.apache.felix.ipojo.:ipojo-bundle {execution: default}]
- [INFO] Start bundle manipulation
- [INFO] Metadata File : ...hello.client\target\classes\metadata.xml
- [INFO] Input Bundle File : ...hello.client\target\hello.client-0.0.1.jar
- [INFO] Bundle manipulation - SUCCESS
- [INFO] [install:install]
- [INFO] Installing ...hello.client\target\hello.client-0.0.1.jar to D:\Dev\maven-repo\ipojo\example\hello.client\0.0.1\hello.client-0.0.1.jar
- [INFO] ------------------------------------------------------------------------
- [INFO] BUILD SUCCESSFUL
- [INFO] ------------------------------------------------------------------------
- [INFO] Total time: 9 seconds
- [INFO] Finished at: Mon Aug 13 14:04:55 CEST 2007
- [INFO] Final Memory: 6M/13M
- [INFO] ------------------------------------------------------------------------
-
-== Configuration Options
-
-You can configure the localization of the iPOJO metadata file as following:
-[source,xml]
- <plugin>
- <groupId>org.apache.felix</groupId>
- <artifactId>maven-ipojo-plugin</artifactId>
- <version>{{ipojo.release}}</version>
- <executions>
- <execution>
- <goals>
- <goal>ipojo-bundle</goal>
- </goals>
- <configuration>
- <metadata>ipojo/meta.xml</metadata>
- </configuration>
- </execution>
- </executions>
- </plugin>
-
-In the metadata element, you can specify your metadata file or directory.
-The given file path is relative to the root directory ("./ipojo/meta.xml").
-If the specified location is a directory, all contained XML files will be used.
-By default, the plugin searches metadata files into the `src/main/ipojo` folder.
-If not found then it searches for `target/classes/metadata.xml` and `./metadata.xml`.
-
-The directory support was introduced in the `1.7.0` version.
-Previously only one metadata file was found.
-Before the `1.7.0`, the set location was searched in all resource folders.
-This is no more supported because it's an anti-pattern.
-
-The second option allows skipping annotations processing, by using the `ignoreAnnotations` element:
-[source,xml]
- <plugin>
- <groupId>org.apache.felix</groupId>
- <artifactId>maven-ipojo-plugin</artifactId>
- <version>{{ipojo.release}}</version>
- <executions>
- <execution>
- <goals>
- <goal>ipojo-bundle</goal>
- </goals>
- <configuration>
- <ignoreAnnotations>true</ignoreAnnotations>
- </configuration>
- </execution>
- </executions>
- </plugin>
-
-You can also ignore embedded XML-Schemas to use external ones.
-To do so, add the `ignoreEmbeddedSchemas`.
-If set to `true`, the manipulator doesn't use embedded XML-Schemas:
-[source,xml]
- <plugin>
- <groupId>org.apache.felix</groupId>
- <artifactId>maven-ipojo-plugin</artifactId>
- <version>{{ipojo.release}}</version>
- <executions>
- <execution>
- <goals>
- <goal>ipojo-bundle</goal>
- </goals>
- <configuration>
- <ignoreEmbeddedSchemas>true</ignoreEmbeddedSchemas>
- </configuration>
- </execution>
- </executions>
- </plugin>
-
-== Generate the skeleton of your iPOJO bundle
-
-The maven-ipojo-plugin provides a way to generate the skeleton of your project.
-To generate this structure, just launch the following command:
-
-[source,sh]
- mvn org.apache.maven.plugins:maven-archetype-plugin:generate \
- -DarchetypeArtifactId=maven-ipojo-plugin \
- -DarchetypeGroupId=org.apache.felix \
- -DartifactId=ARTIFACT_NAME_OF_YOUR_PROJECT \
- -DgroupId=GROUP_ID_OF_YOUR_PROJECT \
- -DarchetypeVersion=VERSION_OF_YOUR_PROJECT \
- -DpackageName=PACKAGE_NAME
-
-This command generates :
-
-* a pom file (to update),
-* the src/main/java and src/main/resources folders,
-* the structure of your package name.
-
-The generated project uses iPOJO annotation and is ready to be deployed.
-
-INFO: [discrete]
-==== Maven Archetype
-
-The maven-ipojo-plugin archetype generates a pom file using the latest released version of the maven-ipojo-plugin.
-
-== Describing iPOJO configuration in the pom file
-
-It is also possible to describe iPOJO components and instances inside the pom file (avoiding using a externalized file).
-The configuration can be described in the `metadata` attribute inside a CDATA block.
-[source,xml]
- <plugin>
- <groupId>org.apache.felix</groupId>
- <artifactId>maven-ipojo-plugin</artifactId>
- <version>{{ipojo.release}}</version>
- <executions>
- <execution>
- <goals>
- <goal>ipojo-bundle</goal>
- </goals>
- <configuration>
- <ignoreAnnotations>true</ignoreAnnotations>
- <metadata>
- <![CDATA[
- <ipojo
- xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
- xsi:schemaLocation="org.apache.felix.ipojo http://felix.apache.org/ipojo/schemas/CURRENT/core.xsd"
- xmlns="org.apache.felix.ipojo">
- <component
- classname="org.apache.felix.ipojo.test.scenarios.component.LifecycleControllerTest"
- name="LFC-Test">
- <provides />
- <controller field="m_state" />
- <properties>
- <property name="conf" field="m_conf" method="setConf" />
- </properties>
- </component>
- <component
- classname="org.apache.felix.ipojo.test.scenarios.component.LifecycleControllerTest"
- name="LFC-Test-Immediate" immediate="true" architecture="true">
- <provides />
- <controller field="m_state" />
- <properties>
- <property name="conf" field="m_conf" method="setConf" />
- </properties>
- </component>
- </ipojo>
- ]]>
- </metadata>
- </configuration>
- </execution>
- </executions>
- </plugin>
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-tools/ipojo-webconsole-plugin.adoc b/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-tools/ipojo-webconsole-plugin.adoc
deleted file mode 100644
index 049a7ef..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-tools/ipojo-webconsole-plugin.adoc
+++ /dev/null
@@ -1,73 +0,0 @@
-= iPOJO Webconsole Plugin
-
-_If you like the Apache Felix Web Console, you will be interested by the iPOJO plugin.
-This plugin gives you all the information about iPOJO instances, factories and handlers deployed on the framework._
-
-
-
-== Features
-
-* Lists created instances
-* Gives details about instances (state, factory, required services, provided services, used instances, and raw architecture)
-* Lists available factories
-* Gives details about factories (state, created instances, required handlers, missing handlers, raw architecture, properties...)
-* List available handlers
-* Instance and Factories are `navigable`, so you can easily understand the system architecture
-
-== Using the plugin
-
-To use the plugin you need an OSGi platform with:
-
-* a HTTP Service
-* The Apache Felix Webconsole
-* iPOJO
-* The iPOJO Web console plugin
-
-You can download link:{attachmentsdir}/ipojo/ipojo-webconsole-quicktart-distribution.zip[this Felix distribution] as a deployment example.
-Unzip the archive and go to the Felix directory to launch Felix:
-
-[source,sh]
- cd ipojo-webconsole-quicktart-1.9.0-SNAPSHOT/felix-framework-4.2.1/
- java -jar bin/felix.jar
-
-Once launched, you can check the deployed bundles:
-
-[source,sh]
-----
-[INFO] Started jetty 6.1.x at port(s) HTTP:8080
-____________________________
-Welcome to Apache Felix Gogo
-
-g! INFO : org.apache.felix.webconsole.plugins.memoryusage (17): Storing Memory Dumps in /Users/clement/Projects/felix-trunk/ipojo/distributions/ipojo-webconsole-quicktart/target/ipojo-webconsole-quicktart-1.9.0-SNAPSHOT/felix-framework-4.2.1/./felix-cache/bundle17/data/dumps
-INFO : org.apache.felix.webconsole.plugins.memoryusage (17): Setting Automatic Memory Dump Threshold to 0% for pools [CMS Old Gen, CMS Perm Gen, Code Cache]
-INFO : org.apache.felix.webconsole.plugins.memoryusage (17): Automatic Memory Dump cannot be set for pools [Par Eden Space, Par Survivor Space]
-INFO : org.apache.felix.webconsole.plugins.memoryusage (17): Setting Automatic Memory Dump Interval to 21600 seconds
-
-g! lb
-START LEVEL 1
- ID|State |Level|Name
- 0|Active | 0|System Bundle (4.2.1)
- 1|Active | 1|Java Servlet API (2.4.0)
- 2|Active | 1|Commons FileUpload (1.2.2)
- 3|Active | 1|Commons IO (2.4.0)
- 4|Active | 1|Apache Felix Bundle Repository (1.6.6)
- 5|Active | 1|Apache Felix Gogo Command (0.12.0)
- 6|Active | 1|Apache Felix Gogo Runtime (0.10.0)
- 7|Active | 1|Apache Felix Gogo Shell (0.10.0)
- 8|Active | 1|Apache Felix Http Api (2.2.0)
- 9|Active | 1|Apache Felix Http Base (2.2.0)
- 10|Active | 1|Apache Felix Http Jetty (2.2.0)
- 11|Active | 1|Apache Felix iPOJO (1.8.6)
- 12|Active | 1|Apache Felix iPOJO Annotations (1.8.6)
- 13|Active | 1|Apache Felix iPOJO Gogo Command (1.0.1)
- 15|Active | 1|Apache Felix iPOJO WebConsole Plugins (1.7.0.SNAPSHOT)
- 16|Active | 1|Apache Felix Web Management Console (4.0.0)
- 17|Active | 1|Apache Felix Web Console Memory Usage Plugin (1.0.2)
- 18|Active | 1|Apache Felix Web Console Package Admin Service Plugin (1.0.0)
- 19|Active | 1|osgi.cmpn (4.2.0.200908310645)
- 20|Active | 1|OW2 Chameleon - JSON Bundle (from org.json) (20090911.0.0.0002)
-----
-
-You access the web console at: http://localhost:8080/system/console/.
-The login/password are _admin_/_admin_.
-The iPOJO tabs gives you all the iPOJO information of the system.
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-tools/junit4osgi.adoc b/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-tools/junit4osgi.adoc
deleted file mode 100644
index a272753..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-tools/junit4osgi.adoc
+++ /dev/null
@@ -1,219 +0,0 @@
-= JUnit4OSGi : Executing Unitary and Integration Test on OSGi
-
-This page is _deprecated_
-
-'''
-
-== Goals
-
-Executing tests on OSGi became a stringent requirement as several aspects need to be tested.
-Indeed, modularity, services (and the inherent dynamism) and the business logic need to be tested.
-The goal of JUnit4OSGi is to provide an execution gateway in order to test bundles and services.
-Instead of injecting mock objects, as provided by regular test frameworks to hide the underlying Executing environment, tests are directly executed on OSGi and so have access to all the features provided by the OSGi framework.
-This allows developers checking modularity aspect and service dynamism in addition to the business logic.
-
-== Principles
-
-Junit4OSGi is split in several pieces.
-First the core bundle (Junit4OSGi) contains an extended version of Junit (3.8.1).
-On the top of this framework, several runners are implemented:
-
-* Immediate runner : launch every available test suite
-* Command line runner : Felix command line allowing to choose the test suite(s) to launch
-* Swing Runner : a very simple Swing runner
-* Maven runner: a maven plug-in allowing to automate tests during the project build process
-
-The different runners give a great flexibility to the framework that can be used during the build process or to test an application in a special environment (such as J2ME).
-Test suites and test cases are package inside bundles.
-Junit4OSGi extend Junit to support OSGi test suite and OSGi test case.
-These two kinds of test classes are able to use the bundle context of the bundle and so are able to deal with the underlying OSGi framework.
-
-== Installing the framework
-
-Except if you use the maven front end (automating the launch a an OSGi framework (Felix) and deploying required bundles), to launch the Junit framework you need to deploy and start
-
-* http://people.apache.org/~clement/ipojo/binaries/org.apache.felix.ipojo-0.8.0-SNAPSHOT.jar[iPOJO 0.8.0-SNASPHOT]
-* http://people.apache.org/~clement/ipojo/binaries/org.apache.felix.ipojo.handler.extender.pattern-0.8.0-SNAPSHOT.jar[iPOJO Extender Pattern Handler 0.8.0-SNAPSHOT]
-* http://people.apache.org/~clement/ipojo/junit4osgi/org.apache.felix.ipojo.junit4osgi-0.8.0-SNAPSHOT.jar[The Junit4OSGi bundle]
-* One runner such as the http://people.apache.org/~clement/ipojo/junit4osgi/org.apache.felix.ipojo.junit4osgi.felix-command-0.8.0-SNAPSHOT.jar[Felix command] one
-
-The archive available http://people.apache.org/~clement/ipojo/junit4osgi/junit4osgi.tutorial.zip[here] contains a pre-configured version of Felix with the previously mentionned bundles.
-
-== Writing Junit Test Case and Test Suite
-
-This section describes briefly how to write test cases and test suites and how they are used by the Junit4OSGi framework.
-More details are available on the Junit web site http://www.junit.org/.
-
-The Money class was introduced in the Junit tutorial and was implemented as the following:
-
-----
-package junit.money;
-
-public class Money {
- private int fAmount;
- private String fCurrency;
-
- public Money(int amount, String currency) {
- fAmount= amount;
- fCurrency= currency;
- }
-
- public int amount() {
- return fAmount;
- }
-
- public String currency() {
- return fCurrency;
- }
-
- public Money add(Money m) {
- return new Money(amount()+m.amount(), currency());
- }
-
- public boolean equals(Object anObject) {
- if (anObject instanceof Money) {
- Money aMoney= (Money)anObject;
- return aMoney.currency().equals(currency())
- && amount() == aMoney.amount();
- }
- return false;
- }
-----
-
-So, to test this implementation, we decide to write a simple class testing the equals and add methods.
-This class can be implemented as the following:
-
- public class SimpleTestCase extends TestCase {
- private Money f12CHF;
- private Money f14CHF;
- public void setUp() {
- f12CHF= new Money(12, "CHF");
- f14CHF= new Money(14, "CHF");
- }
- public void testEquals() {
- assertTrue(!f12CHF.equals(null));
- assertEquals(f12CHF, f12CHF);
- assertEquals(f12CHF, new Money(12, "CHF"));
- assertTrue(!f12CHF.equals(f14CHF));
- }
- public void testSimpleAdd() {
- Money expected= new Money(26, "CHF");
- Money result= f12CHF.add(f14CHF);
- assertTrue(expected.equals(result));
- }
- }
-
-Moreover, in order to launch these tests, we create a test suite (declaring the list of test to execute):
-
- public class SimpleTestSuite {
-
- public static Test suite() {
- TestSuite suite = new TestSuite("Money Simple Test Suite");
- suite.addTestSuite(SimpleTestCase.class);
- return suite;
- }
- }
-
-Now, we have to package our tests and the Money class inside a bundle.
-Of course, it should be packaged in two different bundles but to keep simple we choose to create just one.
-To create the bundle, launch "ant" at the root of the junit-example directory.
-The resulting bundle contains our three classes.
-These tests are connected to the junit4osgi framework by specifying a special header in the manifest:
-
- Test-Suite: junit.example.SimpleTestSuite
-
-This header lists the test suite contained in the bundle.
-Once packaged, we can launch our tests.
-Start the pre-configured Felix with the following command launched from the Felix directory:
-
- java -jar bin/felix.jar
-
-Then deploy the created bundle:
-
- start file:../junit-example/output/junit-example.jar
-
-Finally, run the test with the junit command
-
- junit 8
-
-The argument indicates the bundle containing the test suite to execute.
-The "all" special argument runs every available test suites.
-
-----
--> junit 8
-Executing [Money Simple Test Suite]
-..
-Time: 0,001
-
-OK (2 tests)
-----
-
-== Writing Junit Test Case and Test Suite specialized for OSGi
-
-The previous example has illustrated how creating thest cases and test suites by using the regular Junit framework.
-However, junit4osgi has the particularity to support specialized test for OSGi.
-For example, imagine the very simple Hello Service implemented by the following class:
-
-----
-public class HelloProvider implements HelloService {
-
- public String getHelloMessage() {
- return "hello";
- }
-}
-----
-
-The bundle containing this implementation should register it.
-So you can decide to check this and to check the returned hello message.
-Instead of extending TestCase, this test case will extend OSGiTestCase (provided by the Junit4OSGi framework):
-
-----
-public class SimpleTestCase extends OSGiTestCase {
-
- public void testHelloAvailability() {
- ServiceReference ref = context.getServiceReference(HelloService.class.getName());
- assertNotNull("Assert Availability", ref);
- }
-
- public void testHelloMessage() {
- ServiceReference ref =
- context.getServiceReference(HelloService.class.getName());
- assertNotNull("Assert Availability", ref);
- HelloService hs = (HelloService) context.getService(ref);
- String message = hs.getHelloMessage();
- assertNotNull("Check the message existence", message);
- assertEquals("Check the message", "hello", message);
- }
-
-}
-----
-
-First, note that this class follows the same rules than regular test cases.
-All methods with a name starting with _test_ will be executed.
-However, this class can access to the bundle context of its bundle by using the _context_ field.
-By using this field, the class can check the availability of services ...
-OSGi test cases are gathered in OSGi test suite such as:
-
- public class SimpleTestSuite {
-
- public static Test suite(BundleContext context) {
- OSGiTestSuite suite = new OSGiTestSuite(
- "Hello Service Test Suite",
- context
- );
- suite.addTestSuite(SimpleTestCase.class);
- return suite;
- }
- }
-
-Note that the suite method receives the bundle context allowing the creation of an OSGi Test Suite object.
-The execution of these tests follows the same steps than the previous example:
-
-* Compile the tests and create the bundle by launching ant from the junit-osgi-example directory
-* Start Felix
-* Deploy the bundle with the following command: `start file:../junit-osgi-example/output/junit-osgi-example.jar`
-* Execute the test by using the junit command
-
-== Maven front end: automating tests in your build process
-
-_Coming soon_
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/apache-felix-ipojo-api.adoc b/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/apache-felix-ipojo-api.adoc
deleted file mode 100644
index 49cba77..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/apache-felix-ipojo-api.adoc
+++ /dev/null
@@ -1,375 +0,0 @@
-= iPOJO API
-
-_The iPOJO API provides a third way to describe iPOJO components and instances.
-With the API, you can dynamically create new components types and create instances from them.
-Your component types are described with a Java API.
-To use the API, deploy and start the iPOJO-API bundle and the iPOJO core bundle._
-
-
-
-== A simple example
-
-Let's imagine a simple component providing a service Foo.
-The following code is the implementation class of our component:
-
-[source,java]
-----
-package org.example.service.impl;
-
-import org.example.service.Foo;
-
-public class FooImpl implements Foo {
-
- public void doSomething() {
- // Do something...
- }
-
-}
-----
-
-To create the component type and an instance of the component type just create a class, get the bundle context (either from a Bundle-Activator, or from an iPOJO component), and write the following code:
-
-[source,java]
- new PrimitiveComponentType()
- .setBundleContext(context)
- .setClassName(FooImpl.class.getName())
- .addService(new Service()) // Provide the Foo service
- .createInstance(); // Create the instance
-
-So, now let's imagine another component using this service.
-The following code is the implementation class of this component type:
-
-[source,java]
-----
-package org.example.service.impl;
-
-import org.example.service.Foo;
-
-public class MyComponentImpl {
- private Foo myFoo;
-
- public void start() {
- myFoo.doSomething();
- }
-
-}
-----
-
-It is a regular iPOJO component expecting to get a Foo service in the `myFoo` field.
-It also has a method executed when the instance is valid using the Foo service.
-To describe this component, just write the following lines:
-
-[source,java]
- new PrimitiveComponentType()
- .setBundleContext(context)
- .setClassName(MyComponentImpl.class.getName())
- .addDependency(new Dependency().setField("myFoo"))
- .setValidateMethod("start")
- .createInstance();
-
-== Deploying the API
-
-Before being able to create component types at runtime, you need to deploy 3 bundles:
-
-* iPOJO (core)
-* iPOJO Composite
-* iPOJO API
-
-== Primitive Component Type basics
-
-When you create a new Primitive component type (so, using a Java class as implementation), you must set the bundle context and the class name.
-Everything else is optional.
-
-Note about inner classes: iPOJO is based on a bytecode manipulation.
-The API embeds the manipulator.
-So, when you initialize the component type, the specified class name is manipulated (if not already manipulated).
-So, as this force using a customized classloader, inner classes cannot be manipulated.
-So, inner class injection is not supported with the API.
-
-== Immediate Component, Validate and Invalidate Method
-
-To set the component type as immediate, just call the `setImmediate(immediate)` method on the primitive component type object.
-To set validate and invalidate methods, just call the `setValidate(method)` and `setInvalidate(method)`.
-Specify the method name that you want to call in argument.
-
-== Declaring services
-
-To declare that a component provides a service, add a new service to your primitive component type.
-The Service object can be configured.
-By default, it exposed every implemented interface (regular iPOJO behavior).
-So, you can:
-
-* Add service property
-* Set the creation strategy
-* Set the exposed service specifications
-+
-[source,java]
- new PrimitiveComponentType()
- .setBundleContext(context)
- .setClassName(org.example.service.impl.MyComponentImpl.class.getName())
- .addService(new Service()
- .addProperty(new ServiceProperty()
- .setField("myServiceProperty")
- .setName("sample.myProperty"))
- .setCreationStrategy(Service.INSTANCE_STRATEGY))
- .createInstance();
-
-== Service Dependencies
-
-To declare a service dependency, create and add a Dependency object.
-The dependency object offers all the iPOJO service dependency features.
-You can set the injected field and/or bind/unbind methods.
-Here is an example:
-
-[source,java]
- new PrimitiveComponentType()
- .setBundleContext(context)
- .setClassName(org.example.service.impl.MyComponentImpl.class.getName())
- .addDependency(
- new Dependency().setField("myFoo")
- .setOptional(true)
- .setDefaultImplementation("org.sample.FooDefaultImplementation")
- )
- .createInstance();
-
-== Properties
-
-Thanks to the `addProperty` method, you can create component properties.
-Here is some example of properties:
-
-[source,java]
- new PrimitiveComponentType()
- .setBundleContext(context)
- .setClassName(MyComponentImpl.class.getName())
- .addProperty(new Property()
- .setField("myProperty")
- .setValue("default-value")
- )
- .addProperty(new Property()
- .setMethod("setMethod")
- .setName("prop")
- )
- .createInstance();
-
-== Temporal Dependencies
-
-Temporal dependencies are also supported:
-
-[source,java]
- new PrimitiveComponentType()
- .setBundleContext(context)
- .setClassName(MyComponentImpl.class.getName())
- .addDependency(
- new TemporalDependency().setField("myFoo")
- .setOnTimeoutPolicy(TemporalDependency.NULLABLE)
- .setTimeout(3000)
- .setProxy(true)
- )
- .createInstance();
-
-== Instance creation
-
-The API allows you to create instances from the component type you described.
-Three differents methods.
-The `createInstance()` method just creates an instance.
-The `createInstance(String name)` method allows to set the instance name.
-Finally, the `createInstance(Dictionary configuration)` allows setting the instance configuration.
-All those methods returns the ComponentInstance object allowing to manage the instance (stop, start, dispose).
-
-== Managed Service and Propagation
-
-You can enable/disable the property propagation thanks to the `setPropagation` method on the PrimitiveComponentType object.
-You can also set the the managed service PID with the `setManagedServicePID` method.
-This method should be only use to give a default value of for singleton component.
-In all other case, the managed service pid has to be provided inside the instance configuration.
-
-== Managing iPOJO Factory
-
-Beyond the PrimitiveComponentType, an iPOJO factory is hidden.
-You can configure this factory to be public or private with the `setPublic` method.
-You can also set the name of the factory with the `setName` method.
-
-Then, you can access to the Factory object by calling the `getFactory` method.
-
-== Access to the introspection API
-
-The API provides bridge to get access to the iPOJO introspection API.
-The introspection API allows reconfiguring at runtime an instance (properties, service dependencies...).
-From Service and Dependency, Property and ServiceProperty objects, call the `getXXXDescription` method.
-You must give the instance that you want to introspect in argument.
-If the lookup success, you get an object allowing reconfiguring the service, dependency or property.
-
-== Singleton Component Type
-
-If you are sure to create only one instance of your component type, you can use the singleton component type class.
-This is a kind of primitive component type, but when you start it (with the `create` method), it will automatically create an instance.
-
-[source,java]
- PrimitiveComponentType type = new SingletonComponentType()
- .setBundleContext(context)
- .setClassName(org.example.service.impl.MyComponentImpl.class.getName())
- .addDependency(new Dependency().setField("myFoo"))
- .setValidateMethod("start");
-
- ((SingletonComponentType) type)
- .setObject(new MyComponentImpl(5)) // Inject a pojo object
- .create();// Create an instance
-
-The type created with the singleton component type are set to `private` by default.
-Instead of calling the `start` method, you have to call one of the `create` methods to start the type and create the instance.
-
-You can also set the contained POJO object by using the `setObject` method.
-The given object MUST be compatible with the component implementation class.
-
-== Using external handlers
-
-iPOJO is extensible...
-So, it makes sense that the API is also extensible.
-So component type provides a method allowing to add external handler configuration:
-
-[source,java]
- return new PrimitiveComponentType()
- .setBundleContext(context)
- .setClassName(HostImpl.class.getName())
- .addHandler(new Whiteboard()
- .onArrival("arrival")
- .onDeparture("departure")
- .setFilter("(foo=foo)")
- );
-
-The `addHandler` method allows you to add any handler description.
-A handler description is an object of a class implementing `org.apache.felix.ipojo.api.HandlerConfiguration`.
-Handler provider willing to support the API have to provide this class.
-For example, the example above uses `Whiteboard` that is the Whiteboard pattern handler description.
-This class is very simple, and is shown below:
-
-[source,java]
-----
-public class Whiteboard implements HandlerConfiguration {
-
- public static final String NAME = "wbp";
-
- public static final String NAMESPACE = "org.apache.felix.ipojo.whiteboard";
-
- private String arrival;
-
- private String departure;
-
- private String modification;
-
- private String filter;
-
- public Whiteboard onArrival(String method) {
- arrival = method;
- return this;
- }
-
- public Whiteboard onDeparture(String method) {
- departure = method;
- return this;
- }
-
- public Whiteboard onModification(String method) {
- modification = method;
- return this;
- }
-
- public Whiteboard setFilter(String fil) {
- filter = fil;
- return this;
- }
-
- public Element getElement() {
- ensureValidity();
- // Create the root element.
- Element element = new Element(NAME, NAMESPACE);
- // Mandatory attributes
- element.addAttribute(new Attribute("onArrival", arrival));
- element.addAttribute(new Attribute("onDeparture", departure));
- element.addAttribute(new Attribute("filter", filter));
-
- // Optional attribute
- if (modification != null) {
- element.addAttribute(new Attribute("onModification", modification));
- }
-
- return element;
- }
-
- private void ensureValidity() {
- if (arrival == null) {
- throw new IllegalStateException("The whiteboard pattern configuration must have a onArrival method");
- }
- if (departure == null) {
- throw new IllegalStateException("The whiteboard pattern configuration must have a onDeparture method");
- }
- if (filter == null) {
- throw new IllegalStateException("The whiteboard pattern configuration must have a filter");
- }
-
- }
-----
-
-The only required method is `getElement` returning the `Element-Attribute` structure representing the handler configuration (this uses the internal iPOJO data format).
-If the metadata cannot be generated, the class throws IllegalStateExceptions.
-
-== Creating compositions with the API
-
-The API also allows you to create iPOJO compositions in a pretty simple way.
-So you can create compositions:
-
-* containing internal instances
-* importing services
-* instantiating sub-services
-* exporting services
-* providing services (by delegation)
-
-Here are some examples:
-
-[discrete]
-==== Creating instances inside a composite:
-
-[source,java]
- PrimitiveComponentType prov = createAProvider(); // Create a primitive type
- PrimitiveComponentType cons = createAConsumer(); // Create another primitive type
-
- CompositeComponentType type = new CompositeComponentType()
- .setBundleContext(context)
- .setComponentTypeName("comp1")
- .addInstance(new Instance(prov.getFactory().getName())) // Create an instance in the composite
- .addInstance(new Instance(cons.getFactory().getName()));
-
- ComponentInstance ci = type.createInstance();
-
-[discrete]
-==== Importing a service
-
-[source,java]
- CompositeComponentType type = new CompositeComponentType()
- .setBundleContext(context)
- .setComponentTypeName("comp3")
- .addSubService(new ImportedService() // Importation
- .setSpecification(Foo.class.getName())
- .setOptional(true));
-
-[discrete]
-==== Instantiating a service
-
-[source,java]
- CompositeComponentType type = new CompositeComponentType()
- .setBundleContext(context)
- .setComponentTypeName("comp2")
- .addSubService(new InstantiatedService() // Instantiated service
- .setSpecification(Foo.class.getName()))
- .addInstance(new Instance(cons.getFactory().getName()));
-
-[discrete]
-==== Exporting a service
-
-[source,java]
- CompositeComponentType type = new CompositeComponentType()
- .setBundleContext(context)
- .setComponentTypeName("compExport")
- .addSubService(new InstantiatedService().setSpecification(Foo.class.getName()))
- .addService(new ExportedService()
- .setSpecification(Foo.class.getName())); // Exports a service
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/apache-felix-ipojo-instances.adoc b/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/apache-felix-ipojo-instances.adoc
deleted file mode 100644
index f348941..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/apache-felix-ipojo-instances.adoc
+++ /dev/null
@@ -1,427 +0,0 @@
-= Creating instances
-
-== Component types and instances
-
-iPOJO is a component model enforcing strictly the distinction between component types and instances.
-The relationship between types and instances is the same as the one between classes and objects in OOP.
-You can _instantiate_ as many instances as you want from a component type.
-These instances can be configured with different properties.
-As a consequence, just using @Component or <component> declares a component type, not an instance.
-So, at runtime, nothing will happen until you actually declare or create an instance.
-
-iPOJO provides several ways to create instances, this page presents these possibilities:
-
-* @Instantiate to create an instance directly from the a class annotated with @Component
-* @Configuration to declare a set of instances
-* using <instance>in the XML metadata
-* using the iPOJO Factory service
-* using the OSGi Configuration Admin
-* using the `DeclarationBuilderService`
-
-== @Instantiate
-
-The @Instantiate annotation is the simplest way to declare an instance.
-In a class annotated with @Component, you just add the @Instantiate annotation.
-It instructs iPOJO to declare an instance of the component type described by the current class.
-
-[source,java]
-----
-import org.apache.felix.ipojo.annotations.Component;
-import org.apache.felix.ipojo.annotations.Instantiate;
-
-@Component
-@Instantiate
-public class MyComponent {
- //...
-}
-----
-
-Optionally, you can set the instance name, using the `name` attribute.
-
-[source,java]
-----
-import org.apache.felix.ipojo.annotations.Component;
-import org.apache.felix.ipojo.annotations.Instantiate;
-
-@Component
-@Instantiate(name="myInstance")
-public class MyComponent {
- //...
-}
-----
-
-The @Instantiate annotation is easy to use but, has a couple of limitations:
-
-* it must be used in the @Component class
-* you can't provide a configuration to the instance
-* you can declare only one instance
-
-=== Declaring a singleton instance
-
-The @Instance annotation is particularly useful to declare singleton instances, i.e.
-a component type with only one instance.
-To create a singleton instance, combine the @Instantiate annotation and the `publicFactory` attribute of the @Component annotation:
-
-[source,java]
-----
-import org.apache.felix.ipojo.annotations.Component;
-import org.apache.felix.ipojo.annotations.Instantiate;
-
-@Component(publicFactory=false)
-@Instantiate
-public class MySingleton {
- //...
-}
-----
-
-The `publicFactory=false` attribute makes the component type _private_, so invisible from other bundles.
-No one else would be able to create another instance of the component type.
-
-== @Configuration
-
-This second annotation is used on classes to create one or several instances using a fluent API.
-
-[source,java]
- import org.apache.felix.ipojo.configuration.Configuration;
- import org.apache.felix.ipojo.configuration.Instance;
- import static org.apache.felix.ipojo.configuration.Instance.instance;
- @Configuration
- public class ConfigureOneInstance {
- Instance myInstance = instance().of(MyComponent.class)
- .with("property").setto("value");
- }
-
-The class is annotated with @Configuration.
-All fields of type Instance (`org.apache.felix.ipojo.configuration.Instance`) are read and declares an instance.
-In the previous example, an instance of the `MyComponent` component type is declared with a property `property` set to `value`.
-The instance is named `myInstance` (the field name).
-
-You can declare several instances in the same @Configuration class:
-
-[source,java]
-----
- @Configuration
-public class ConfigureTwoInstances {
-
- // Declare an instance of MyComponent named myInstance
- Instance myInstance1 = instance().of(MyComponent.class)
- .with("property").setto("value");
-
- // Declare an instance of MyComponent
- Instance myInstance2 = instance().of(MyComponent.class)
- .with("property").setto("value2");
-
- // Declare an instance of AnotherComponent
- Instance myInstance2 = instance().of(AnotherComponent.class);
- }
-----
-
-By default, the instance name is set to the field name.
-However, you can also set the instance name:
-
-[source,java]
- // Declare an instance of MyComponent named hello
- Instance myInstance2 = instance().of(MyComponent.class)
- .named("hello")
- .with("property").setto("value");
-
-Using this configuration DSL allows creating a set of instances that you can configure easily.
-
-=== Configuration including lists and maps
-
-The `setto` method accepts any object.
-To ease creating collections, the API proposed two methods to handle lists and maps:
-
-[source,java]
- instance()
- .of(Mycomponent.class)
- // Lists
- .with("list").setto(list(1, 2, 3))
- .with("list2").setto(list().with(1).with(2).with(3))
- // Maps
- .with("map").setto(map().with(pair("entry", "value")))
- .with("map2")
- .setto(map()
- .with(entry("key", 1), entry("key2", 2)));
-
-=== Methods returning Instance objects
-
-The class annotated with @Configuration does not only handle fields, but also handles methods returning Instance object.
-These methods can have either no arguments or the BundleContext as unique argument.
-
-[source,java]
-----
-Instance instance1() {
- return instance().of(MyComponent.class);
-}
-
-Instance instance2(BundleContext bc) {
- return instance().of(MyComponent.class);
-}
-----
-
-As for fields, the method name is used as instance name except if the instance already received a name.
-
-NOTE: the injected BundleContext is the BundleContext of the bundle containing the annotated class.
-
-== Declaring instances in XML
-
-You can declare instances using the iPOJO XML descriptor.
-If you use XML to describe you component type, you probably want to use this way to create your instances.
-[source,xml]
- <instance component="factory.name">
- <property name="property" value="value"/>
- <property name="another property" value="another value"/>
- </instance>
-
-The _component_ attribute specifies the targeted component type.
-Generally it's the qualified classname of the component class, but can also be the name of the factory if one is specified.
-
-The _property_ elements have a mandatory `name` attribute to set the property name, and a `value` attribute to specify the String form of the property's value.
-
-You can declare as many as you want instances in the XML descriptor.
-They can targets component types declared within the same bundles or not.
-
-=== Setting the instance name
-
-To set the instance name you can use the _name_ attribute of the _instance_ element or the _instance.name_ property:
-[source,xml]
- <instance component="…MyComponent" name="my-instance"/>
- <instance component="…MyComponent">
- <property name="instance.name" value="my-instance-2"/>
- </instance>
-
-=== Describing complex properties in XML
-
-The _property_ element can be used to configure complex types such as arrays, lists and maps.
-[source,xml]
- <!--Creates a string array-->
- <property name="array" type="array">
- <property value="a"/>
- <property value="b"/>
- </property>
- <!--Creates a list containing string-->
- <property name="list" type="list">
- <property value="a"/>
- <property value="b"/>
- </property>
- <!--Creates a dictionary containing string-->
- <property name="dict" type="dictionary">
- <property name="a" value="a"/>
- <property name="b" value="b"/>
- </property>
- <!--Creates a map containing string-->
- <property name="map" type="map">
- <property name="a" value="a"/>
- <property name="b" value="b"/>
- </property>
- <!--A complex type can contain other complex objects:-->
- <property name="complex-array" type="array">
- <property type="list">
- <property value="a"/>
- <property value="b"/>
- </property>
- <property type="list">
- <property value="c"/>
- <property value="d"/>
- </property>
- </property>
- <!--Empty structures will create empty objects-->
- <property name="empty-array" type="array"/>
- <property name="empty-list" type="list"/>
- <property name="empty-map" type="map"/>
-
-== Creating instances using the Factory service
-
-In previous technics to create instances were declarative.
-You declare an instance.
-This instance is going to be created as soon as the component type becomes available, and disappears as soon as the component type leaves.
-The technic presented here is a programatic way.
-
-Each (non private) component types are exposed as an OSGi service.
-You can use this OSGi service to create, reconfigure and dispose instances from your code.
-
-=== The Factory service
-
-The published service interface is `[org.apache.felix.ipojo.Factory](http://felix.apache.org/ipojo/api/{{ipojo.release}}/org/apache/felix/ipojo/Factory.html)` and provides the following methods:
-
-[source,java]
-----
-/**
- * Creates an instance manager (i.e. component type instance).
- * @param configuration the configuration properties for this component.
- * @return the created instance manager.
- * @throws UnacceptableConfiguration if the given configuration is not valid.
- * @throws MissingHandlerException if an handler is missing.
- * @throws ConfigurationException if the instance configuration failed.
- */
-ComponentInstance createComponentInstance(Dictionary configuration) throws UnacceptableConfiguration, MissingHandlerException, ConfigurationException;
-
-/**
- * Reconfigures an instance already created. This configuration needs to
- * have the name property to identify the instance.
- * @param conf the configuration to reconfigure the instance. The instance.name property must be set to identify the instance to reconfigure.
- * @throws UnacceptableConfiguration if the given configuration is not consistent for the targeted instance.
- * @throws MissingHandlerException if an handler is missing.
- */
-void reconfigure(Dictionary conf) throws UnacceptableConfiguration, MissingHandlerException;
-----
-
-You can identify the factory using the _factory.name_.
-So target a specific component type, use the following filter:
-
-[source,sh]
- (factory.name=...MyComponent)
-
-If you grab all factories, you can check their names using the `getName()` method.
-
-=== Creating instances
-
-Once you have the right Factory service, you can create instances using `createComponentInstance` method.
-This method returns a reference on the created instance.
-This method receives an optional configuration containing key-value pairs.
-Values are either objects (of the adequate type) or Strings used to create objects.
-This configuration can be 'null' if no properties have to be pushed.
-
-You can set the instance name using the 'instance.name' property can be used to specify the instance name.
-
-Instances are automatically started when created.
-However, the instance can be invalid, if at least one handler is not valid.
-
-The instance creation process can fail.
-Three exceptions can be thrown during the creation:
-
-* `UnacceptableConfiguration` means that mandatory properties are missing in the instance configuration
-* `MissingHandlerException` means that the factory is not valid (i.e.
-an external handler is missing)
-* `ConfigurationException` means that the instance configuration has failed.
-The cause can be either an issue in the component type description or an invalid property type.
-
-If an error occurs, a comprehensive message is reported in order to solve the issue.
-
-The next snippet shows an example of instance creation:
-
-[source,java]
- // Assume we get a Factory in the `fact` field
- Properties props = new Properties();
- props.put("instance.name","instance-name");
- props.put("foo", "blablabla");
- try {
- instance = fact.createComponentInstance(props);
- } catch(Exception e) {
- fail("Cannot create the instance : " e.getMessage());
- }
-
-=== Disposing created instance
-
-You can only disposed instances that you created.
-To dispose an instance, just call the `dispose` method on the ComponentInstance object (returned by the createComponentInstance method).
-
-[source,java]
- instance.dispose();
-
-=== Reconfiguring instance
-
-To reconfigure an instance, call the 'reconfigure' method on the ComponentInstance object.
-This method receives the new set of properties.
-Be aware that the 'instance.name' property cannot be changed.
-
-[source,java]
- Properties props2 = new Properties();
- props2.put("foo", "abc");
- instance.reconfigure(props2);
-
-=== Following the factory state
-
-Factories can becomes invalid if one of the handler they require is not available.
-Basically, handlers are pieces of iPOJO containers.
-
-You can check the factory state using the `Factory.getState()` method.
-This method returns `1` if the factory is valid, `0` if not.
-
-You can also register a `org.apache.felix.ipojo.FactoryStateListener` object on the factory to be notified of the changes.
-
-== Creating instances using the OSGi Configuration Admin
-
-The configuration admin service is a standard service specified by the OSGi Alliance to handle configurations.
-It allows an operator to configured the deployed bundles, and so iPOJO instances.
-
-iPOJO supports the configuration admin and you can create, reconfigure and dispose instanced using this service.
-
-=== Creating instances
-
-Creating an instance is done by creating a _factory_ configuration:
-
-[source,java]
-----
-ConfigurationAdmin admin = ...// Let's assume with have the configuration admin
-Configuration conf = admin.createFactoryConfiguration("...MyComponent", "?");
-
-// Build the instance configuration
-Dictionary dict = new Hashtable();
-//...
-
-// Push the configuration to the configuration admin
-conf.update(dict);
-----
-
-To create the _factory_ configuration, use the `createFactoryConfiguration` method on the Configuration Admin object.
-The first argument is the factory name.
-The second is the location binding.
-Using "?" is a wildcard, for more details, check the configuration admin specification.
-
-You populate this configuration with a dictionary.
-The configuration is actually created using the `update` method.
-
-=== Reconfiguring instances
-
-If the instance was created using the Configuration Admin and you own the Configuration object used for the creation, the reconfiguration is done by calling the `update` method with the new properties.
-
-If the instance was already created, you can configure it using a _regular_ configuration.
-The pid given to this configuration is the instance name.
-
-=== Disposing instances
-
-To dispose an instance, just call the `delete` method on the configuration object you used to configure the instance.
-
-== Creating instances with declarations
-
-Declarations offer a nice way to declares instances in a programmatic way.
-If not retracted by hand, they're bound to the declaring bundle lifecycle (i.e.
-are unregistered when the bundle is not `ACTIVE` anymore).
-
-Declarations can be build using the `DeclarationBuilderService` (see interface below).
-Instances (of components), types (components) and iPOJO extensions can also be build using this service.
-
-[source,java]
- public interface DeclarationBuilderService {
- InstanceBuilder newInstance(String type);
- InstanceBuilder newInstance(String type, String name);
- InstanceBuilder newInstance(String type, String name, String version);
- DeclarationHandle newExtension(String name, FactoryBuilder builder);
- DeclarationHandle newType(Element description);
- }
-
-Instances created through declaration can indeed be configured.
-
-[source,java]
-----
-// Obtain the service through the service registry
-DeclarationBuilderService service = ...
-
-// Get a fresh instance builder
-InstanceBuilder builder = service.newInstance("my-factory");
-
-DeclarationHandle handle = builder.name("a-unique-name") // Make sure name is unique for the expected type
- .configure()
- .property("a-property", "a-value")
- .property("another-property", "another-value")
- .build();
-
-// Push the InstanceDeclaration service in the registry
-handle.publish();
-----
-
-The builder ultimately produces handles to declarations.
-Handles are the live link to the underlying declarations: service publication and un-registration are done through the `handle.publish()` and `handle.retract()` methods.
-Declaration status (is it bound or not) is also accessible with `handle.getStatus()`.
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components.adoc b/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components.adoc
deleted file mode 100644
index cb66331..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components.adoc
+++ /dev/null
@@ -1,34 +0,0 @@
-= Describing your iPOJO components
-
-_This section describes the different features supported by iPOJO.
-This page aims to answer to the following question: "What can I write in my iPOJO component descriptor?"_
-
-== Core features
-
-Core features are provided with the iPOJO runtime bundles.
-You can use it directly, as soon as the iPOJO runtime is deployed.
-
-* xref:documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/service-requirement-handler.adoc[How to require a service]
-* xref:documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/providing-osgi-services.adoc[How to publish and provide a service]
-* xref:documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/lifecycle-callback-handler.adoc[How to react to lifecycle state changes]
-* xref:documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/configuration-handler.adoc[How to description component configuration]
-* xref:documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/architecture-handler.adoc[How to enable/disable instance introspection]
-* xref:documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/controller-lifecycle-handler.adoc[How to act on the instance state from the implementation]
-
-== Extensions
-
-Extensions _extend_ the iPOJO model to add a specific functionality.
-This is made thanks to the external handler mechanism.
-So before using one of these features, deploy the attached external handler.
-
-* xref:documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/event-admin-handlers.adoc[How to receive and send events with the Event Admin]
-* xref:documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/ipojo-jmx-handler.adoc[How to reconfigure instances with JMX]
-* xref:documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/extender-pattern-handler.adoc[How to implement an extender pattern]
-* xref:documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/white-board-pattern-handler.adoc[How to implement a whiteboard pattern]
-* xref:documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/temporal-service-dependency.adoc[How to wait for services and inject proxies]
-
-== A missing functionality ?
-
-iPOJO component model is extensible.
-So, you can implement your own handler managing you specific requirement.
-Refer the handler development guide (xref:documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-devguide/how-to-write-your-own-handler.adoc[How to write your own handler]) for more details.
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/Callback.jpeg b/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/Callback.jpeg
deleted file mode 100644
index 13873dc..0000000
Binary files a/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/Callback.jpeg and /dev/null differ
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/architecture-handler.adoc b/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/architecture-handler.adoc
deleted file mode 100644
index bf9d371..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/architecture-handler.adoc
+++ /dev/null
@@ -1,65 +0,0 @@
-= Introspection and Architecture
-
-_The architecture feature allows obtaining an architectural / component view of your systems.
-It exposes a snapshot of the present instances & factories, the state of these instances...
-Moreover;
-iPOJO defines an 'arch' command displaying this architecture in Felix.
-You need to install xref:documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-tools/ipojo-arch-command.adoc[the arch command]._
-
-
-
-== Reflection on component instances
-
-The architecture feature does "reflection" on the iPOJO containers.
-It gathers information about the component (state, class name ...), requirement (state, multiple, optional ...), provided services (state, properties) ...
-Each handler can participate to the architecture.
-This information allows you to know why an instance does not start, or why the component does not publish / provide a service.
-
-== Metadata
-
-The architecture (i.e.
-instance introspection) is activated by default.
-To disable it, you need to add an attribute `architecture="false"` to the component element:
-[source,xml]
- <component classname="org.apache.felix.ipojo.hello.impl.HelloServiceImpl" architecture="false">
-
-By default, the architecture feature is enabled.
-
-== The "arch" command
-
-The Gogo commands are the following:
-
-* `ipojo:instances` (or just `instances`) lists the instances and state
-* `ipojo:instance $instance_name` (or just `instance $instance_name`) displays the complete information about the specified $instance_name
-* `ipojo:factories` (or just `factories`) lists the available public factories
-* `ipojo:factory $factory_name` (or just `factory $factory_name`) displays complete information about the factory $factory_name
-* `ipojo:handlers` (or just `handlers` lists available handlers
-
-For example:
-
-[source,sh]
-----
-$ instances
-Instance ArchCommand -> valid
-Instance spell.english.EnglishDictionary-0 -> valid
-Instance spell.checker.SpellCheck-0 -> valid
-Instance spell.gui.SpellCheckerGui-0 -> valid
-
-$ instance spell.checker.SpellCheck-0
-instance component.type="spell.checker.SpellCheck" state="valid" bundle="8" name="spell.checker.SpellCheck-0"
- handler state="valid" name="org.apache.felix.ipojo.handlers.dependency.DependencyHandler"
- requires optional="false" aggregate="false" state="resolved" binding-policy="dynamic" specification="spell.services.DictionaryService"
- handler state="valid" name="org.apache.felix.ipojo.handlers.providedservice.ProvidedServiceHandler"
- provides service.id="36" state="registered" specifications="[spell.services.SpellChecker]"
- property value="spell.checker.SpellCheck" name="factory.name"
- property value="spell.checker.SpellCheck-0" name="instance.name"
- handler state="valid" name="org.apache.felix.ipojo.handlers.architecture.ArchitectureHandler"
-----
-
-More info on the `arch` command are available xref:documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-tools/ipojo-arch-command.adoc[here].
-
-== Technical information
-
-In fact, when a component enables the architecture introspection, its container exposes an `Architecture` service.
-Any architecture requester can obtain information about the instance.
-For example, the arch command requests all the architecture services and prints the information.
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/configuration-handler.adoc b/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/configuration-handler.adoc
deleted file mode 100644
index 93dca4c..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/configuration-handler.adoc
+++ /dev/null
@@ -1,181 +0,0 @@
-= Configuration Handler
-
-_This page presents how to configure component instances.
-This is managed by the configuration handler.
-This handler allows the configuration and dynamic reconfiguration of instances.
-A configuration is basically a set of couple (name, value).
-The name can be a field name or a property name associated to a field or/and a method.
-iPOJO also supports complex properties composed by maps, dictionaries, lists and arrays._
-
-
-
-== Configurable Properties
-
-To support configuration, the component type needs to declare which properties are configurable.
-These properties are not necessarily service properties but can be internal component properties.
-
-== Examples
-
-The following code depicts a simple configurable component.
-The 'm_foo' field will be injected using the 'foo' property, and will also be exposed as a service property.
-The `updateArray` method is a 'setter' method where the 'array' property will be injected.
-Properties injected into field are available in the constructor, setter method are available only after the constructor.
-
-[source,java]
-----
-@Component
-@Provides
-public class MyComponent implements MyService {
- @Property(name=".foo")
- private String m_foo;
-
- public MyComponent(@Property String message) {
- //...
- }
-
- @Property(name="array")
- public void updateArray(String[] array) {
- //...
- }
-}
-----
-
-The previous component can also be described using XML:
-[source,xml]
- <component classname="...MyComponent">
- <properties propagation="false"/>
- <property name=".foo" field="m_foo"/>
- <property name="array" method="updateArray"/>
- <property name="message" constructor-index="1"/>
- </properties>
- </component>
-
-The instance contains the configuration:
-[source,xml]
- <instance component="...MyComponent">
- <property name="foo" value="bar"/>
- <property name="array" value="{1, 2, 3}"/>
- <property name="message" value="hello"/>
- </instance>
-
-In the previous snippet, you can see three configurable properties.
-The first is a configurable property attached to the field 'foo' that is a service property too.
-The second is an array property attached to a method (updatArray).
-These three properties are configured by the instance configuration.
-
-By default all properties that do not start with the `.` (such as `.foo`) are _propagated_.
-Thus, properties are propagated to the service registration.
-It means that at each time that the configuration of the instance is updated;
-all properties contained in the configuration are propagated to the service registrations.
-For example, in the previous example, not only `foo` will be published but `array` are also published.
-To disable propagation use:
-
-[source,java]
- @Component(propagation=false)
-
-If a property has a method, this method is invoked each time that the property value changes (the method is called to push the initial value just after the constructor).
-The method receives one argument of the type of the property (an integer array in the example).
-
-When an instance is reconfigured, an updated callback can also be called:
-
-[source,java]
-----
-@Updated
-public void updated() {
- // The instance was reconfigured
-}
-
-// OR
-@Updated
-public void updated(Dictionary conf) {
- // The instance was reconfigured, conf is the new configuration.
-}
-----
-
-== Exposing a Managed Service
-
-The ManagedService is a service specified in the OSGi Compendium.
-It allows reconfiguring an instance with the Configuration Admin.
-There is two way for an iPOJO instance to expose a Managed Service.
-
-* In the `@Component` annotation the `managedservice` attribute defines the managed service PID.
-In XML this is done using the `pid` attribute in the properties element (XML)
-* In the instance configuration by configuring the `managed.service.pid` property
-
-So, using annotation, you should use the `managedservice` attribute as follow:
-
-[source,java]
-----
-@Component(managedservice="my.pid")
-public class MyComponent {
-
-}
-----
-
-In XML, the `pid` attribute of the `properties` element does the same job.
-[source,xml]
- <component classname="...MyComponent">
- <!-- ... -->
- <properties pid="my.pid"/>
- <!-- ... -->
- </properties>
- </component>
-
-Finally, instance may configure the managed service using the `managed.service.pid` configuration property:
-[source,xml]
- <instance component="...MyComponent">
- <property name="managed.service.pid" value="my.pid.2"/>
- </instance>
-
-=== ALERT SUCCESS Type vs. Instance configuration
-
-If the managed service pid is specified both in the component type and in the instance configuration, the instance configuration is used.
-
-The managed service pid is the identifier used by the Configuration Admin to attach configuration to Managed Services.
-First this pid must be unique (as any pid in OSGi).
-Moreover, this pid cannot be the same one that the pid used in the Managed Service Factory to create the instance (if you use this way to create your instance).
-
-When an instance is reconfigured with the Managed Service, the configuration is propagated if the propagation is enabled.
-
-== Dynamic Reconfiguration using Factories or ManagedServiceFactories
-
-iPOJO instances support dynamic reconfiguration.
-To reconfigure an instance you can use both iPOJO `Factory` and the `ManagedServiceFactory` services exposed by the factory of the targeted instance.
-By calling the method _reconfigure_ or _update_ (according of the service you use), the handler receive the new configuration and apply it.
-If the propagation is activated, the service registrations are updated too.
-If there is an `updated` callback, the callback is invoked.
-
-== Being notified when a reconfiguration is completed
-
-Sometimes you need to be notified when a reconfiguration is done (all setter method called).
-This can be done thanks to the `updated` attribute.
-This attribute specifies a method claeed when a configuration/reconfiguration is completed.
-This method receives a `Dictionary` containing the properties (pair <key,value>).
-Properties with no value are not in the received configuration.
-
-Updated callback are declared as follow using annotations:
-
-[source,java]
-----
-@Updated
-public void updated() {
- // The instance was reconfigured
-}
-
-// OR
-@Updated
-public void updated(Dictionary conf) {
- // The instance was reconfigured, conf is the new configuration.
-}
-----
-
-In XML, the method name is given as an attribute of the {\{properties}} element.
-[source,xml]
- <component className="...MyComponent">
- <!-- ... -->
- <properties updated="updated"/>
- <!-- ... -->
- </properties>
- </Component>
-
-The callback is called _AFTER_ the successful application of the reconfiguration.
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/controller-lifecycle-handler.adoc b/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/controller-lifecycle-handler.adoc
deleted file mode 100644
index 41446bc..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/controller-lifecycle-handler.adoc
+++ /dev/null
@@ -1,61 +0,0 @@
-= Lifecycle Controller Handler
-
-_The lifecycle controller allows a component implementation to participate to the instance lifecycle.
-So, you can immediately decide to stop an instance if the configuration is incorrect (correct properties, accessible resources...).
-The licecyel controller impacts the instance lifecycle, if you want to impact only the registered service, have a look to the service controller (xref:documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/providing-osgi-services.adoc[service providing]._
-
-
-
-== iPOJO instance lifecycle & Lifecycle controller
-
-Once started, iPOJO instances can be either valid or invalid.
-The decision comes from handlers.
-An instance is valid if every plugged handler are valid.
-Basically it means that all required services are available.
-As soon as one handler becomes invalid, the instance becomes invalid.
-
-The lifecycle controller just monitors a field inside the POJO class.
-When this field becomes `false`, the handler becomes invalid, and so the instance becomes invalid.
-When the field get the `true` value, the handler becomes valid, and if all handlers are valid, the instance becomes valid.
-
-== An example
-
-Imagine the following component :
-
-[source,java]
-----
-@Component
-public class LifecycleControllerTest {
-
- @Controller
- private boolean m_state;
-
- @Property
- public void setConf(String newConf) {
- System.out.println("setConf : " + newConf);
- if (newConf.equals("a correct value")) {
- m_state = true; // update controller value.
- } else {
- m_state = false; // update control value
- }
- }
-}
-----
-
-If you don't want to use annotations, the following snippet does the same job using XML:
-[source,xml]
- <component
- classname="org.apache.felix.ipojo.test.scenarios.component.LifecycleControllerTest">
- <controller field="m_state"/>
- <properties>
- <property name="conf" method="setConf"/>
- </properties>
- </component>
-
-The component requires the `conf` property.
-iPOJO checks if this property is inside the pushed configuration, but cannot checks if the configuration is correct according to the component semantic.
-When the instance is created, the `setConf` method is called with the given value.
-If the given `conf` property is "valid" the `m_state` field (i.e.
-the controller) is set to `true`.
-Else, the `m_state` is set to `false`.
-It means that the lifecycle controller handler becomes invalid and as a consequence, the instance becomes invalid.
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/event-admin-handlers.adoc b/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/event-admin-handlers.adoc
deleted file mode 100644
index 9426e07..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/event-admin-handlers.adoc
+++ /dev/null
@@ -1,345 +0,0 @@
-= Event Admin Handlers
-
-_The goal of the Event Admin Handlers is to allow event communications between iPOJO component instances.
-The implementation of these handlers relies on an event admin services.
-It enables the iPOJO component to listen to a list of topics and to receive all related events.
-It also allows components to send events in an easy way._
-
-ALERT:: The 1.2.0 version use the namespace : `org.apache.felix.ipojo.handlers.event` instead of `org.apache.felix.ipojo.handlers.event.EventAdminHandler`.
-
-WARNING: *change in the 1.7.0*
-
-The `@Publisher` annotation is now deprecated and replaced by `@Publishes`.
-
-== An example
-
-Hereafter is presented a small example :
-
-[source,java]
-----
-@Component
-@Instantiate
-public class MyComponent {
-
- @Publishes( // or @Publisher before the 1.7.0
- name="myPublisher",
- topics="bar,nuts")
- private Publisher m_publisher;
-
- @Subscriber(
- name="mySubscriber",
- topics="foo")
- public void receive(Event e) {
- // Event received
- // Do something with the event
- }
-}
-----
-
-This component can also be described using the XML formalism:
-[source,xml]
- <ipojo
- xmlns:ev="org.apache.felix.ipojo.handlers.event">
- <component className="...MyComponent">
- <ev:subscriber
- name="mySubscriber"
- callback="receive"
- topics="foo"/>
- <ev:publisher
- name="myPublisher"
- field="m_publisher"
- topics="bar,nuts"/>
- </component>
- <instance component="...MyComponent"/>
- </ipojo>
-
-In XML, you need to specify the namespace of the Handler.
-You can find here one event subscriber (named mySubscriber) and one event publisher (named myPublisher).
-In these handler configurations, the name parameter is mandatory.
-The topics parameter is optional as it can be specified in the instance configuration.
-The callback parameter of the mySubscriber element is mandatory and indicates the method that handles received events.
-In this case, this method must have a single argument of type org.osgi.service.event.Event.
-The field parameter of the myPublisher element indicates the field (of type org.apache.felix.ipojo.handlers.event.publisher.Publisher) that is used by the POJO to send events on the specified topics.
-All type compliance will be checked by the handler at component instantiation time.
-
-== Download
-
-The event admin handlers (to send and receive events) are available in the Felix trunk in the iPOJO project.
-See the link:{{ refs.download.path }}[Download] page to download and compile these sources.
-
-== How does it work?
-
-The handler will parse the description provided in the metadata, and register for you the EventHandler in the OSGi Registry.
-On one hand, your POJO will receive each event through the handler.
-With this handler you can specify different callback methods for different topics.
-On the other side, the handler instantiates and injects configured Publisher references in your POJO, so you can send events transparently through these publishers.
-
-== EventHandler Specification
-
-Here you can find all configuration options of the EventAdmin handler.
-As seen before, the handler contains two components : the event subscriber and the event publisher.
-These components can be configured, using several attributes, as described below.
-Some of these attributes can be (re)defined in the instance configuration.
-
-_Handler namespace :_ _org.apache.felix.ipojo.handlers.event_
-
-=== Event subscriber attributes
-
-|===
-| Attribute name | Required | Description
-
-| name
-| yes
-| The name of the event subscriber, acting as a unique identifier.
-
-| callback
-| yes
-| The name of the POJO's method that will be called each time an event is received.
-This method takes only one parameter, of type `org.osgi.service.event.Event` by default, but this type can be overridden by defining the data-key and/or the data-type attributes.
-
-| topics
-| yes
-| The comma-separated-list of the topics that the handler will listen to.
-Each event sent on a topic present in this list will be sent to the specified callback method.
-The topics can be set in the instance configuration.
-
-| filter
-| no
-| The event filter is used to filter incoming events before sending them to the callback.
-The syntax of this field is described in the OSGi Event Admin Specification.
-If you don't specify a filter, all events sent on the listened topics will be considered.
-The filter can be set in the instance configuration.
-
-| data-key
-| no
-| The data key is used when you want to receive data events.
-This attribute's value is the key corresponding to the received data in the event's dictionary.
-If you use this attribute, the parameter passed to the callback method is the the value associated to this key, not the whole event.
-This attribute is generally used with the **data-type** attribute to specify the received object type.
-If an event is received and it does not contain such a key, it is ignored (with a warning message).
-
-| data-type
-| no
-| This attribute is associated to the data-key attribute.
-It specifies the type of objects (`java.lang.Object` by default) that the callback expects.
-It is used to determine the unique callback method (in case of multiple methods with the same name) and to check type compliance at event reception.
-Data events that are not corresponding to the specified type will be ignored (with a warning message).
-|===
-
-=== Event publisher attributes
-
-|===
-| Attribute name | Required | Description
-
-| name
-| yes
-| The name of the event publisher, acting as a unique identifier.
-
-| field
-| yes
-| The name of the POJO's field that will be used to send events.
-The field is initialized at component instantiation time.
-The type of the field must be : `org.apache.felix.ipojo.handlers.event.publisher.Publisher`.
-Despite it creates a dependency between the component code and the handler, this system allows hiding the whole complexity of event sending.
-
-| topics
-| yes
-| The comma-separated-list of the topics on which events will be sent.
-Topics can be set in the instance configuration
-
-| data-key
-| no
-| The data key is used when you want to send data events.
-This attribute's value is the key, in the event's dictionary, in which sent data are stored.
-When you use the `sendData` method of the Publisher, the given object is placed in the event dictionary, associated with the specified data-key.
-The default value of this attribute is `user.data`.
-
-| synchronous
-| no
-| Determines if event sending is synchronous or not.
-By default, events are sent asynchronously, but you can specify there the desired behaviour of the Publisher.
-|===
-
-=== Instance configuration
-
-Some of the described attributes can be (re)defined in the instance configuration section of your metadata file.
-Its permits to configure event management instance by instance.
-The following properties are used by the handler :
-
-* _event.topics_ : overrides _topics_ attribute, available for both subscribers and publishers configuration
-* _event.filter_ : overrides _filter_ attribute, available for subscribers configuration only.
-
-=== Publisher interface
-
-The Publisher interface is the link between the component code and the handler.
-It permits to publish events on the topics specified in the component's description (or instance configuration).
-The implemented methods are :
-
-* `public void send(Dictionary content)` : This method is used to send a standard event, with the specified content.
-Some specific properties may be added in the content to satisfy EventAdmin specification (e.g., event.topic).
-* `public void sendData(Object o)` : This method is the easier way to send data.
-The given object is placed in the event dictionary according to the _data-key_ attribute (or its default value).
-Then, this dictionary is sent as a regular event.
-
-== Handler Architecture
-
-Here is shown the global architecture of the EventHandler : the interactions between the user components (i.e., POJO), the handler and the OSGi runtime environment.
-
-image::documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/handler-arch.png[]
-
-== EventHandler Features
-
-In this section, you will find some examples of the handler's features.
-
-=== Instance customization
-
-As described in the 'Instance configuration' section, you can (re)define some of the subscribers or publishers attributes.
-You can notice that required attributes that are not defined in the component description must be defined in the instance configuration section.
-Hereafter is an example of an instance configuration of this handler :
-[source,xml]
- <ipojo>
- <instance component="...MyComponent">
- <property name="event.topics">
- <property name="mySubscriber" value="foo"/>
- <property name="myPublisher" value="bar,nuts"/>
- </property>
- <property name="event.filter">
- <property name="mySubscriber"
- value="|((arg=Minibar)(arg=Coconuts))"/>
- </property>
- </instance>
- </ipojo>
-
-=== Data events
-
-One of the most important features of the EventHandler is the capability of sending and receiving data events.
-You may know that the OSGi EventAdmin Service allows bundles to send custom objects in events, inserting them in the event's dictionary.
-The EventHandler hides the dictionary manipulation and allows iPOJO components to receive custom objects at any time.
-
-First, you have define the _data-key_ attribute in the publisher configuration (`dataKey` in annotations).
-Sent objects will be contained in the event dictionary and are accessible with the "user.data" key.
-[source,xml]
- <ipojo
- xmlns:ev="org.apache.felix.ipojo.handlers.event">
- <component className="...DataPublisher">
- <ev:publisher
- name="myPublisher"
- field="m_publisher"
- topics="myTopic"
- data-key="my.data"/>
- </component>
- <instance component="...DataPublisher"/>
- </ipojo>
-
-Then you can use the _sendData_ method of your configured publisher.
-
-[source,java]
-----
-import org.apache.felix.ipojo.handlers.event.publisher.Publisher;
-//...
-public class DataPublisher ... {
- private Publisher m_publisher;
-
- public void doSomething() {
- // MyFavoriteType extends MyFavoriteInterface
- MyFavoriteType data = new MyFavoriteType(...);
- //...
- // Send a data event
- m_publisher.sendData(data);
- }
-}
-----
-
-The second step is to configure an event subscriber to receive such events.
-The _data-key_ attribute's value of the subscriber must be the same than the publisher's one.
-The _data-type_ describes the type of received data events, and thus, must be compatible with the sent object's type (i.e., super-class or inherited interface).
-Then you can finally receive the sent object in the callback method.
-The parameter type of the callback must be the same than the data-type attribute value.
-[source,xml]
- <ipojo
- xmlns:ev="org.apache.felix.ipojo.handlers.event">
- <component className="...DataEventSubscriber">
- <ev:subscriber
- name="mySubscriber"
- callback="handleData"
- topics="myTopic"
- data-key="my.data"
- data-type="my.package.MyFavoriteInterface"/>
- </component>
- <instance component="...DataEventSubscriber"/>
- </ipojo>
-
-
-
-[source,java]
- import my.package.MyFavoriteInterface;
- //...
- public class DataEventSubscriber ... {
- public void handleData(MyFavoriteInterface o) {
- // Object received
- //...
- }
- }
-
-Annotations use a different set of attributes:
-
-* data-key is replaced by `dataKey`
-* data-type is replaced by `dataType`
-
-=== Note on synchronous event sending
-
-By default, events are sent using asynchronous sending (a.k.a._post_ in OSGi EventAdmin).
-You can use synchronous sending by defining the _synchronous_ attribute of your publisher to true.
-
-The behavior of synchronous event sending is particular when you specify several topics in the publisher description.
-The event is synchronously sent to each topic, one by one.
-So when you return from this function, you can be sure that the event has been delivered to each topic.
-
-=== Publisher instance information
-
-All events sent by a publisher contains the name of the component instance that sent them.
-Its enables to filter received events depending the sender instance.
-The instance name is accessible in the event dictionary by the key _publisher.instance.name_.
-Despite it goes against MOM principles, this property is useful to trace events and especially event sources.
-
-=== Configuring the handler with annotations
-
-It is possible to configure the handler with a simple annotations available in the annotation pack ('annotation' project in the iPOJO trunk).
-Here is an example of usage:
-
-[source,java]
-----
-import org.apache.felix.ipojo.annotations.Component;
-import org.apache.felix.ipojo.handlers.event.Subscriber;
-import org.apache.felix.ipojo.handlers.event.Publishes;
-import org.apache.felix.ipojo.handlers.event.publisher.Publisher;
-import org.osgi.service.event.Event;
-
-
-@Component
-public class PubSub {
- @Publishes(name="p1", synchronous=true)
- Publisher publisher1;
-
- @Publishes(name="p2", synchronous=false, topics="foo,bar", data_key="data")
- Publisher publisher2;
-
- @Publishes(name="p3", synchronous=true, topics="bar")
- Publisher publisher3;
-
- @Subscriber(name="s1", data_key="data")
- public void receive1(Object foo) {
- // Process event
- }
-
- @Subscriber(name="s2", topics="foo,bar", filter="(foo=true)")
- public void receive2(Event foo) {
- // Process event
- }
-
- @Subscriber(name="s3", topics="foo", data*key="data", data*type="java.lang.String")
- public void receive3(String foo) {
- // Process event
- }
-}
-----
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/extender-pattern-handler.adoc b/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/extender-pattern-handler.adoc
deleted file mode 100644
index 5103874..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/extender-pattern-handler.adoc
+++ /dev/null
@@ -1,148 +0,0 @@
-= The Extender Pattern handler
-
-_The objective of this handler is to simplify the development of extender-based architecture.
-This architecture-style is based on two different entities:_
-
-* _The extender (also called host)_
-* _The extensions_
-
-
-
-== The Extender pattern
-
-This architecture-style is based on two different roles:
-
-* The extender
-* The extension
-
-image::documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/extender.png[]
-
-The relation is basically a 1..n relation.
-The extender tracks extensions.
-The particularity of this architecture-style is that extensions are packaged in different bundles.
-An extension is detected by analyzing the bundle.
-Indeed these bundles can have a special mark in their manifest of a special file...
-Implementing an extender pattern could be complex as the extender needs to track these marks dynamically.
-When a bundle starts, it needs to look at the mark.
-Then a bundle leave, the extender must release all object created from this bundle.
-This handler tracks bundle for you based on the specified required mark.
-At each time a matching bundle appears or disappears, a callback is invoked.
-The mark is currently a header in the bundle manifest.
-Nowadays, a lot of frameworks use this pattern such as iPOJO it-self (to find both bundles containing components and bundles adding a new implementation type), Spring-DM ...
-
-== Using the handler
-
-First of all, you need to configure the component type to use the handler such as:
-
-[source,xml]
-----
-<ipojo xmlns:extender="org.apache.felix.ipojo.extender">
- <component
- classname="org.apache.felix.ipojo.extender.MyExtender">
-
- <!-- Extender Pattern handler configuration -->
- <extender:extender
- extension="My-Extension"
- onArrival="onBundleArrival"
- onDeparture="onBundleDeparture"
- />
-
- <callback transition="invalidate" method="stopping" />
- <callback transition="validate" method="starting" />
- <provides />
- </component>
-</ipojo>
-----
-
-Notice that, this handler is an external handler.
-So, it uses the "org.apache.felix.ipojo.extender" namespace.
-You can also use annotations:
-
-[source,java]
-----
-@Component
-@Extender(
- onArrival="onBundleArrival",
- onDeparture="onBundleDeparture",
- extension="My-Extension")
-public class MyExtender {
-
- @Validate
- public void starting() {
- // ...
- }
-
- @Invalidate
- public void stopping {
- // ...
- }
-
- void onBundleArrival(Bundle bundle, String header) {
- // Do something
- }
-
- void onBundleDeparture(Bundle bundle) {
- // Do something
- }
-}
-----
-
-The methods specified methods will be called when a matching bundle arrives or leaves.
-In the previous example, these methods could be:
-
-[source,java]
-----
-void onBundleArrival(Bundle bundle, String header) {
- // Do something
-}
-
-void onBundleDeparture(Bundle bundle) {
- // Do something
-}
-----
-
-Notice the different signatures of the methods.
-The arrival method is called with the arriving bundle and the matching header value (i.e.
-the value of the My-Extension header of the bundle manifest).
-The departure method just receives the leaving bundle.
-
-== Configuration
-
-The handler has only three mandatory attributes:
-
-* Extension: declaring the looked manifest header.
-* onArrival: declaring the method to invoke when a matching bundle arrives
-* onDeparture: declaring the method to invoke when a matching bundle leaves
-
-*Called despite being invalid*
-
-== Configuring the handler with annotations
-
-It is possible to configure the handler with a simple annotation available in the annotation pack ('annotations' project in the iPOJO trunk).
-Here is an example of usage:
-
-[source,java]
-----
-import org.apache.felix.ipojo.annotations.Component;
-import org.osgi.framework.Bundle;
-
-@Component
-@org.apache.felix.ipojo.extender.Extender(extension="foo", onArrival="onArrival", onDeparture="onDeparture")
-public class Extender {
-
- public void onArrival(Bundle bundle, String foo) {
- // do something
- }
-
- public void onDeparture(Bundle bundle) {
- // do something
- }
-}
-----
-
-The `extension` attribute allows setting the bundle filter.
-
-== A more realistic example
-
-The Junit4OSGi framework, available https://svn.apache.org/repos/asf/felix/trunk/ipojo/examples/junit4osgi[here], uses this handler to track Junit Test Suite offered by the installed bundles.
-The Junit4Osgi bundle has a component using this handler to be notified when a bundle with the `Test-Suite` header appears or leaves.
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/injecting-bundle-context.adoc b/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/injecting-bundle-context.adoc
deleted file mode 100644
index 4453292..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/injecting-bundle-context.adoc
+++ /dev/null
@@ -1,72 +0,0 @@
-= Accessing the Bundle Context
-
-_Despite iPOJO hides most of the OSGi mechanisms, you often need to access the `Bundle Context`.
-This page explains how you can access to the bundle context from your component code._
-
-
-
-== Bundle Context
-
-The `BundleContext` is an object provided by the OSGi Framework to access services as well as resources contained in bundles.
-Using the bundle context is often required in the later case, i.e.
-loading files contained in the bundle.
-The API of the bundle context is available http://www.osgi.org/javadoc/r4v43/core/org/osgi/framework/BundleContext.html[here].
-
-== Retrieving the Bundle Context as constructor parameter
-
-The first way to retrieve the bundle context is as a constructor parameter:
-
-[source,java]
- public MyComponent(BundleContext context) {
- // context is the bundle context
- }
-
-With such way, the bundle context of the bundle declaring the component is injected.
-Notice that such injection can be mixed with other constructor injection such as `@Requires` for service dependencies and `@Property` to configuration property.
-
-== Using `@Context` (version 1.11.2+)
-
-The second way to retrieve the `Bundle Context` uses a _bundle context handler_ responsible for injecting the bundle context.
-This handler let you inject the bundle context in a field, in a setter method or as constructor parameter:
-
-[source,java]
-----
-@Component
-public MyComponent {
- /**
- * Field injection.
- */
- @Context
- private BundleContext context;
-
- /**
- * Constructor injection, equivalent to the the previous approach.
- */
- public MyComponent(@Context BundleContext context) {
- // ...
- }
-
- /**
- * Method injection.
- */
- @Context
- public void setBundleContext(BundleContext context) {
- // ...
- }
-}
-----
-
-The `@Context` annotation takes an optional parameter indicating which `Bundle Context` has to be injected.
-By default it injects the `component` bundle context, meaning the bundle context of the bundle declaring the component.
-But, you can asks iPOJO to injects the `instance` bundle context, i.e.
-the bundle context of the bundle declaring the instance:
-
-[source,java]
- @Component
- public MyComponent {
- /**
- * Injects the instance bundle context
- */
- @Context(Context.Source.INSTANCE)
- private BundleContext context;
- }
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/ipojo-jmx-handler.adoc b/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/ipojo-jmx-handler.adoc
deleted file mode 100644
index 4ba16ad..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/ipojo-jmx-handler.adoc
+++ /dev/null
@@ -1,291 +0,0 @@
-= iPOJO JMX Handler
-
-_This handler provides JMX management of component instance.
-It could be useful to manage instance remotely.
-As the handler exposes MBeans, you must have a MBean server running on your platform (as the platform MBean server or the MOSGi MBean Server)._
-
-
-
-== Features
-
-The handler allows to:
-
-* Expose attributes accessible via JMX (with right management).
-* Expose methods to be called through JMX.
-* Get notifications when attributes are modified .
-
-== Prerequisites
-
-To be functional this handler must register on an MBean Server,thus you obviously need it.
-Several servers are currently supported : the standard platform MBean server (included in the Java Virtual Machine since version 5), MOSGi (Apache Felix sub-project), ...
-
-== Download
-
-The JMX handler is available in the Felix trunk in the iPOJO project.
-See the link:{{ refs.download.path }}[Download] page to download and compile these sources.
-
-== How to use it
-
-The handler needs to be added in the metadata.xml, you just add a namespace (e.g., jmx) :
-[source,xml]
- <ipojo xmlns:jmx="org.apache.felix.ipojo.handlers.jmx">
- ...
- </ipojo>
-
-So, you could now expose in JMX properties and methods of your component.
-They are surrounded by the <jmx:config>tag.
-[source,xml]
- <jmx:config>
- <jmx:property name="message" field="m_msg" rights="w" notification="true"/>
- <jmx:method name="doSomethingBad"/>
- <jmx:method name="doSomethingGood"/>
- </jmx:config>
-
-[discrete]
-==== ALERT Serialization
-
-Be careful that the argument and return type of methods must be serializable.
-In case of several methods have the same name, each of them will be exposed.
-
-== JMX Handler options
-
-Here you can find all configuration options of the JMX handler.
-There are two kinds of manageable elements : properties and methods.
-First is described the global configuration of the handler.
-Then elements can be configured, using several attributes, as described below.
-
-== Global handler attributes
-
-|===
-| Attribute name | Required | Description
-
-| objectName
-| No
-| The complete object name of the managed component.
-The syntax of this attribute must be compliant with the ObjectName syntax, detailed in the JMX specification.
-If neither domain nor name attributes are specified, the default value is determined by the package, the type and the instance name of the component.
-This attribute overrides the domain and name attributes.
-_Example:_ `"my.domain:type=myType,name=myName"`
-
-| domain
-| No
-| The domain of the managed object (i.e., the left part of the object name).
-This attribute must be compliant with the domain syntax, as described in the JMX specification.
-_Example:_ `"my.domain:type=myType,name=my.domain"`
-
-| name
-| No
-| The name property of the managed object.
-The value of this attribute must comply with the ObjectName value syntax, as described in the JMX specification.
-
-| usesMOSGi
-| No
-| Determines if the component must be register on the MOSGi MBean server or not.
-
-| preRegister, postRegister, preDeregister, postDeregister
-| No
-| These attributes allow to specify methods to carry out operations before and after being registered or unregistered from the MBean server.
-|===
-
-== Properties attributes
-
-+++<table class="table table-bordered">++++++<thead>++++++<tr>++++++<th>+++Attribute name+++</th>+++
- +++<th>+++Required+++</th>+++
- +++<th>+++Description+++</th>++++++</tr>++++++</thead>+++
- +++<tbody>++++++<tr>++++++<td>+++field+++</td>+++
- +++<td>+++Yes+++</td>+++
- +++<td>+++The name of the component's field to expose.+++</td>++++++</tr>+++
-
- +++<tr>++++++<td>+++rights+++</td>+++
- +++<td>+++No+++</td>+++
- +++<td>+++The domain of the managed object (i.e., the left part of the object name). This attribute must be compliant with the domain syntax, as described in the JMX specification. +++<em>+++Example:+++</em>+++ +++<code>+++"my.domain:type=myType,name=my.domain"+++</code>++++++</td>++++++</tr>+++
-
- +++<tr>++++++<td>+++name+++</td>+++
- +++<td>+++No+++</td>+++
- +++<td>+++Specify the access permission of the exposed field. The accepted values are :
- +++<ul>++++++<li>+++"r" : read-only access, the default value.+++</li>+++
- +++<li>+++"w" : read and write access.+++</li>++++++</ul>++++++</td>++++++</tr>+++
-
- +++<tr>++++++<td>+++notification+++</td>+++
- +++<td>+++No+++</td>+++
- +++<td>+++Enable or disable attribute change notification sending for this property. If set to `true`, a notification is sent each time the value of the field changes.+++</td>++++++</tr>++++++</tbody>++++++</table>+++
-
-== Methods attributes
-
-|===
-| Attribute name | Required | Description
-
-| name
-| Yes
-| The name of the method to expose.
-If multiple methods have the same name, all of them are exposed.
-
-| description
-| No
-| The description of the exposed method, as it will appear in JMX.
-|===
-
-== Examples
-
-In this part, we will give you a complete example of a component managed with JMX, using the JConsole provided by the SUN JDK.
-
-=== Exposing Attributes
-
-In first time we create a simple component named MyComponent.
-We have add two fields named m__level (int) and m__message (String).
-
-[source,java]
- public class MyComponent ... {
- // Exposed attributes
- private String m_message;
- private int m_level;
- }
-
-We expose now the attributes in the jmx:config tag in the metadata :
-
-[source,xml]
-----
-<?xml version="1.0" encoding="UTF-8"?>
-<iPOJO xmlns:jmx="org.apache.felix.ipojo.handlers.jmx">
- <component className="...MyComponent"
- architecture="true"
- immediate="true">
-
- <provides/>
- <jmx:config>
- <!-- Exposed properties -->
- <jmx:property field="m_level"
- name="The level"
- rights="r"/>
- <jmx:property field="m_message"
- name="The message"
- rights="w"/>
- </jmx:config>
- </component>
- <instance
- component="...MyComponent"/>
-</iPOJO>
-----
-
-Now, we could get and write the properties in the JConsole :
-
-image::documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/JMXHandler_1.png[]
-
-=== Exposing Methods
-
-We could now add methods in the initial class :
-
-[source,java]
-----
-/**
-Do something good
-*/
-public void doSomethingGood() {
- ...
-}
-
-/**
-Do something bad
-*/
-public void doSomethingBad() {
- ...
-}
-
-/**
-Do nothing
-*/
-public void doNothing() {
- ...
-}
-----
-
-We add corresponding tags in the metadata to expose these methods:
-[source,xml]
- <!-- Exposed methods -->
- <jmx:method name="doSomethingGood"
- description="Do something good."/>
- <jmx:method name="doSomethingBad"
- description="Do something bad."/>
- <jmx:method name="doNothing"
- description="Do absolutely nothing."/>
-
-Now the three methods are exposed in the operations tab of the JConsole.
-We can invoked these methods :
-
-image::documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/JMXHandler_2.png[]
-
-=== Attribute Notifications:
-
-You could subscribe to attribute notification by adding the notification attribute in property tag.
-In our example if we want to be notified when m_level is modified, we change the property line in the metatada like this:
-[source,xml]
- <jmx:property field="m_level"
- name="The level"
- rights="r"
- notification="true"/>
-
-So now if we change the string through JConsole (or in the VisualVM) or if the POJO is modified in other way, a notification will be sent to every listener.
-For example, we subscribe in the notification tab, and we get notification when the message changes :
-
-image::documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/JMXHandler_3.png[]
-
-== Configuring the handler with annotations
-
-It is possible to configure the handler with simple annotations available with iPOJO annotations.
-Here is an example of usage:
-
-[source,java]
-----
-import org.apache.felix.ipojo.annotations.Component;
-import org.apache.felix.ipojo.handlers.jmx.Config;
-import org.apache.felix.ipojo.handlers.jmx.Method;
-import org.apache.felix.ipojo.handlers.jmx.Property;
-
-@Component
-@Config(domain="my-domain", usesMOSGi=false)
-public class JMXSimple {
-
- @Property(name="prop", notification=true, rights="w") // Field published in the MBean
- String m_foo;
-
- @Method(description="set the foo prop") // Method published in the MBean
- public void setFoo(String mes) {
- System.out.println("Set foo to " + mes);
- m_foo = mes;
- }
-
- @Method(description="get the foo prop") // Method published in the MBean
- public String getFoo() {
- return m_foo;
- }
-}
-----
-
-The `@org.apache.felix.ipojo.handlers.jmx.Config` (`@Config` if the package it correctly imported) annotation is a type annotation (so placed on the `class` element.
-This annotation indicates that the instance will be exposed as an MBean.
-This annotation supports:
-
-* usesMOSGi: set to `true` to use MOSGi.
-Otherwise, the MBean will be exposed in the MBean Platform Server (default: `false`).
-* objectname: set the MBean objectname.
-The objectname must follow JMX specification.
-(default: `package-name:factory-name:instance-name`)
-* domain: set the MBean domain.
-(default: `package-name`)
-* name: set the MBean name.
-(default: `instance-name`).
-
-The `@org.apache.felix.ipojo.handlers.jmx.Property` (`@Property`) annotation is a field annotation indicating that the field is exposed in the MBean.
-The supported attributes are:
-
-* name: set the property name
-* rights: set the access permission.
-Possible values are `r` (read only) and `w` (read and write).
-By default, properties are in read-only mode.
- ** notification: enables notification on this property.
-By default notifications are disabled.
-
-The `@org.apache.felix.ipojo.handlers.jmx.Method` annotation is a method annotation indicating that the method is exposed in the MBean.
-Only one attribute can be customized:
-
-* description: set the method description.
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/lifecycle-callback-handler.adoc b/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/lifecycle-callback-handler.adoc
deleted file mode 100644
index 437d0c7..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/lifecycle-callback-handler.adoc
+++ /dev/null
@@ -1,168 +0,0 @@
-= Lifecycle callbacks
-
-_It is often necessary to create a POJO object as soon the instance becomes valid (i.e.
-required services are available).
-It is also often needed to be able to stop it nicely.
-This pages presents the iPOJO capabilities to achieve such actions.
-iPOJO allows you to invoke methods (callbacks) on the POJO object when instance's state changed.
-For example, it allows invoking a `start` method when the instance becomes valid and a `stop` method when the instance becomes invalid.
-It allows the creation of `immediate` component.
-This page presents how to use this handler._
-
-
-
-== Instance Lifecycle
-
-iPOJO instances have a very simple lifecycle.
-This lifecycle contains two states: `INVALID` and `VALID`.
-Once an instance is created, this instance can only be valid if all its plugged handlers are valid.
-In the most basic case it means all required services are available.
-For example, an instance requiring a service (and so using the dependency handler) cannot be valid if the required service is unavailable.
-
-An instance starts and stops in the invalid state.
-
-image::documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/lifecycle.png[,25%]
-
-== Lifecycle callback
-
-This handler supports two kinds of callback.
-The INVALID\=>VALID callback are invoked when the instance becomes valid (at starting or when an event allows the instance to become valid).
-The VALID\=>INVALID callback are invoked when the instance becomes invalid (at stopping or when an event invalids the instance).
-
-image::documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/callback.png[,10%]
-
-== An example
-
-Let's take an example.
-The following class requires a FooService and has two lifecycle callbacks: start and stop.
-
-[source,java]
-----
-@Component
-@Instantiate
-public class Foo {
- @Requires
- FooService fs;
-
- @Validate
- private void start() {
- // Starting method
- //...
- fs.foo();
- //...
- }
-
- @Invalidate
- protected void stop() {
- // Stopping method
- if(fs!=null) { fs.foo(); }
- }
-}
-----
-
-You can also remove the annotations to use the XML format:
-[source,xml]
- <component className="...Foo">
- <requires field="fs"/>
- <callback transition="validate" method="start"/>
- <callback transition="invalidate" method="stop"/>
- </component>
- <instance component="...Foo"/>
-
-When an instance of this component type is created, the start method is called as soon as the `Foo` Service (service requirement) becomes available.
-If the `Foo` Service is no more available or when the instance is stopped, the stop method is called.
-
-The invoked methods have no argument, but could be private, protected or public.
-Public methods can be in parent classes too.
-Moreover, the `+INVALID=>VALID+` (validate) method can use service dependencies (the instance becomes valid means that all required services are available);
-however, in the stop method (invalidate) it is possible that one of these dependency can be `null`.
-Indeed, the departure of a service can be the cause of the instance invalidation.
-
-== Managing threads
-
-One usage of lifecycle callback is when the instance needs to create threads.
-Indeed, the thread can be created in the validate callback, and stopped in the invalidate method.
-The next class shows an example of a class handling a thread by using lifecycle callbacks.
-
-[source,java]
-----
-@Component
-@Instantiate
-public class HelloRequesterImpl implements Runnable {
-
- final static int DELAY=10000;
-
- @Requires
- HelloService[] m_hello; // Service Dependency
-
- boolean end;
-
- public void run() {
- while (!end) {
- try {
- synchronized (this) {
- for(int i = 0; i < m_hello.length; i++) {
- System.out.println(m_hello[i].sayHello("Clement"));
- }
- }
- Thread.sleep(DELAY);
- } catch (InterruptedException ie) {
- /* will recheck quit */
- }
- }
- }
-
- @Validate
- public void starting() {
- Thread T = new Thread(this);
- end = false;
- T.start();
- }
-
- @Invalidate
- public void stopping() { end = true; }
-----
-
-== Invalidate callbacks and services
-
-The invalidate callback has to be developed defensively.
-Indeed, inside this callback, it might be possible that a service is no more there (the departure of this service has thrown the instance invalidation, which calls the callback).
-So, you must check that the service is not `null` before using it:
-
-[source,java]
- @Invalidate
- public void stop() {
- if (myservice != null) {
- // you can use the service
- }
- // ...
- }
-
-Thanks to the iPOJO synchronization model, you can be sure that if the service is available, it will be there until the end of the method.
-
-== Immediate component
-
-An instance of an `immediate` component type is instantiated as soon it becomes valid.
-It means that, when the instance becomes valid, the constructor of the implementation class is called.
-This can replace the validate callback.
-However, it stills a difference between the immediate and the validate callback.
-The constructor is call only once time.
-The validate callback is re-called each time the instance becomes valid.
-Components that do not provide services are automatically set as immediate.
-
-image::documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/constructor.png[]
-
-To set a component as immediate you must add the `immediate` attribute to `component`:
-
-[source,java]
- @Component(immediate=true)
- @Instantiate
- public class MyComponent implements MyService {
- // ...
- }
-
-However as there is no 'destructor' in Java, the invalidate callback is necessary if some actions are needed when stopping.
-
-== Callback on several objects
-
-If you instance has created several objects (called the implementation class constructor several times), the callback is called on each object in the creation order.
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/providing-osgi-services.adoc b/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/providing-osgi-services.adoc
deleted file mode 100644
index 43e2966..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/providing-osgi-services.adoc
+++ /dev/null
@@ -1,435 +0,0 @@
-= Providing OSGi services
-
-_This pages explains how to publish OSGi services with iPOJO.
-It presents:_
-
-* _service publication_
-* _service properties publication and management_
-* _service object creation and creation strategies_
-* _service un-registration_
-* _configuration property propagation_
-* _the management of the exposition from the implementation class_
-
-
-
-== A simple example
-
-The following code snippet shows a simple class implementing the `FooService` interface:
-
-[source,java]
-----
-@Component
-@Provides
-public class FooProviderType1 implements FooService {
- private String m_foo = "foo";
-
- public void foo() {
- System.out.println("foo " + m_foo);
- }
-
-}
-----
-
-To provide a service, the implementation class _MUST_ implement the service interface.
-
-In XML, to provide the service, the component type needs to contain the `<provides/>` element:
-[source,xml]
- <component className="...FooProviderType1">
- <provides/>
- </component>
-
-image::documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/ps-foo.png[]
-
-The `<provides/>` or `@Provides` suffice to declare that each instance of this type will provide the FooService (for more info about instances see 'xref:documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/ipojo-advanced-topics/how-to-use-ipojo-factories.adoc[How to use iPOJO factories]`).
-The provided specifications can be discovered by analyzing the implementation class.
-By default, all implemented interface are published in the same service registration.
-iPOJO looks down the entire inheritance tree.
-
-== Service Publication
-
-The provided service handler manages service publication.
-For each declared `<provides/>`, the handler registers a service.
-Since the `@Provides` annotation can be used only once, only one service is registered that provides all interfaces.
-The service is published as long as the instance is valid.
-If the instance becomes invalid, the service is removed from the service registry.
-
-By default, it publishes all interfaces implemented by the implementation class of the component class.
-It collects all super-interfaces (interfaces implemented by implemented interfaces and by the super class).
-However, it is possible to explicitly declare which service specifications are published with the `specifications` attribute, such as:
-
-[source,java]
- @Component
- @Provides(specifications={FooService.class})
- public class FooProviderType1 implements FooService, Runnable {
- // ...
- }
-
-=== Specification checking
-
-If you use the `specifications` attribute, the handler checks that all declared interfaces are really implemented by the implementation class.
-If an interface is not implemented, the handler logs a warning.
-
-=== No service
-
-If the implementation class does not implement any interface, you cannot provide a service.
-In this case, the handler throws an error.
-
-== Service Properties
-
-You can also attach properties to a service registration.
-Service properties are attached to published service and allow consumer filtering/selecting providers.
-A property can be attached to a field (contained in the component implementation class), and so can be handle dynamically.
-
-Let's take a new example very closed of the last one:
-
-[source,java]
-----
-@Component
-@Provides
-public class FooProviderType1 implements FooService {
-
- @ServiceProperty(name="foo", value="Foo")
- private String m_foo;
-
- public void foo() {
- System.out.println("foo " + m_foo);
- m_foo = "bar";
- }
-}
-----
-
-Using XML, it gives:
-[source,xml]
- <component classname="...FooProviderType1">
- <provides>
- <property name="foo" field="m_foo" value="Foo"/>
- </provides>
- </component>
-
-The declared property is attached to the `m_foo` field.
-This property is published with the name `foo`.
-This property has a default value "Foo".
-This value will be injected into the `m*foo` field, when this field asks for a value.
-A property with a field attribute does not need to declare a type (the type can be discovered by analyzing the implementation class).
-
-The implementation class set a new value to the `m_foo` field in the code.
-When this action occurs, the service publication is updated.
-If a published property value becomes `null`, the property is unpublished since it has a new value.
-
-You can also publish 'static' properties (not attached to a field):
-
-[source,java]
-----
-@Component
-@Provides(properties= {
- @StaticServiceProperty(name="static", type="java.lang.String", value="this is a static property")
- })
-public class FooProviderType1 implements FooService {
-
- @ServiceProperty(name="foo", value="Foo")
- private String m_foo;
-
- public void foo() {
- System.out.println("foo " + m_foo);
- m_foo = "bar";
- }
-}
-----
-
-The second property (`Static`) is published as a static property.
-This property is not attached to a field, so, we need to declare the property type.
-All primitive types or objects can be used has property type (for object, the qualified name of the class is used as java.lang.String).
-
-In XML, this can also be done:
-[source,xml]
- <component classname="...FooProviderType1">
- <provides>
- <property name="foo" field="m_foo" value="Foo"/>
- <property name="static" type="java.lang.String" value="this is a static property"/>
- </provides>
- </component>
-
-Properties may have a default value (set using the `value` attribute).
-This value will be used as initial value.
-The value can be given in the instance configuration.
-The default value will be overridden in this case:
-[source,xml]
- <instance component="...FooProviderType1">
- <property name="foo" value="My New Foo Value"/>
- <property name="static" value="My Value For Static"/>
- </instance>
-
-Properties can also be 'mandatory'.
-Mandatories properties must receive a value from the instance configuration.
-If the instance configuration _forgets_ a mandatory properties, the configuration is rejected.
-Mandatory attribute let you be sure to receive the complete set of initialization values:
-
-[source,java]
-----
-@Component
-@Provides
-public class MyComponent implements MyService {
-
- @ServiceProperty(name="username", mandatory=true)
- private String m_username;
-
- @Property(name="password", mandatory=true)
- private String m_password;
-
- //...
-}
-----
-
-For the previous components:
-
-* `+(name=myname, password=****)+` is a valid configuration
-* `+(password=****)+` is an invalid configuration that will be rejected by iPOJO
-
-== Advanced features
-
-=== Service Serving & Object Creation
-
-When a consumer requires the published service, the handler sends an object (from the component class) of the implementation class.
-By default, it is always the same POJO object.
-If no objects already exists, an instance is created.
-
-However, the handler supports the OSGi _Service Factory_.
-In this case, for each requester bundle, the handler sends a new object.
-To activate this policy, add the `strategy` attribute in the `provides` element:
-
-[source,java]
- @Component
- @Provides(strategy="SERVICE")
- public class MyComponent implements MyService {
- //...
- }
-
-or:
-[source,xml]
- <provides strategy="SERVICE"/>
-
-Other strategies are available:
-
-* `strategy="instance"` allows creating one service object per iPOJO instance using the service
-* it is possible to create your own creation strategy by extending the `org.apache.felix.ipojo.handlers.providedservice.CreationStrategy` class and by indicating the qualified class name in the `strategy` attribute:
-+
-[source,java]
- @Component @Provides(strategy="org.acme.foo.MyCreationStrategy") public class MyComponent implements MyService { //...
-}
-
-=== Providing Several Services (XML only)
-
-In XML, you can declare several `provides` inside the same component.
-All those provided services will be managed individually, so will be published using several publication (i.e.
-`org.osgi.frameowrk.ServiceRegistration`).
-This case is useful when service properties are different for the different services.
-[source,xml]
- <component classname="...FooProviderType1">
- <provides specifications="...Foo"/>
- <provides specifications="...Bar">
- <property name="foo" value="baz"/>
- </provides>
- </component>
-
-image::documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/ps-foobar2.png[]
-
-=== Service Property Propagation
-
-The configuration handler has the possibility to propagate received properties to service publication.
-So, when the propagation is activated (on the `properties` element or on the `@Component` annotation), all properties received by the configuration handler will be propagated to all published services.
-If some properties are mapped on methods, these methods are invoked with the new value in argument.
-
-image::documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/ps-propagation.png[]
-
-If an instance configuration contains properties starting with `service.`, they are automatically propagated.
-In the following example, the `service.pid` is automatically propagated.
-[source,xml]
- <instance component="...">
- <property name="service.pid" value="my.pid"/>
- </instance>
-
-=== Instance reconfiguration
-
-iPOJO supports instance reconfiguration.
-When an instance is dynamically reconfigured and if the instance published service properties, the values are updated with the new configuration.
-For example, let's take the following component.
-
-[source,java]
-----
-@Component
-@Instantiate
-@Provides
-public class MyComponent implements MyService {
-
- @ServiceProperty(name="prop", value="initial")
- private String myProp;
-
- //...
-
-}
-----
-
-The previous code also declares an instance (created without any configuration).
-This instance registers `MyService` with the service property `prop=initial`.
-If this instance is reconfigured using a configuration like: `{prop="my value"}`, the published properties will be updated with the new value, so `prop=my value`.
-
-=== Publishing an abstract or concrete class as a Service
-
-It is also possible to expose an abstract or concrete class as a service.
-To to this, just specify the published class in the `specifications` attribute:
-
-[source,java]
- @Component
- @Provides(specifications=MyComponent.class)
- public class MyComponent {
- // ...
- }
-
-or in XML:
-[source,xml]
- <component classname="...FooProviderType1">
- <provides specifications="...AbstractFoo"/>
- </component>
- <component classname="...FooBarProviderType1">
- <provides specifications="[...AbstractFoo, ...Bar]"/>
- </component>
-
-As illustrated with the example using annotation, the component can also publish itself as a service.
-However, such practice is not recommended.
-
-=== Controlling the service exposition from the implementation class
-
-To control the exposition of the published service, you can use a `service controller`.
-A service controller is a boolean field of the component class.
-The injected boolean field allows the code to impact the service publication.
-Setting the field to `false` unregisters the service from the service registry.
-Setting it back to `true` re-publishes the service.
-
-[source,java]
-----
-@Component
-@Provides
-public class ControllerCheckService implements FooService, CheckService {
-
- @ServiceController
- private boolean controller; // Service Controller
-
- public boolean foo() {
- return controller;
- }
-
- public boolean check() {
- System.out.println("Before : " + controller);
- controller = ! controller; // Change the publication
- System.out.println("After : " + controller);
- return controller;
- }
-}
-----
-
-Using XML, the previous component description is:
-[source,xml]
- <component classname="org.apache.felix.ipojo.test.scenarios.component.controller.ControllerCheckService"
- name="PS-Controller-1-default">
- <provides>
- <controller field="controller"/>
- </provides>
- </component>
-
-The `controller` may have a value attribute setting the initial value.
-Setting this value to `false` disables the initial service registration:
-
-[source,java]
-----
-@Component
-@Provides
-public class ControllerCheckService implements FooService, CheckService {
-
- @ServiceController(value=false)
- private boolean controller; // Service Controller
-
- public boolean foo() {
- return controller;
- }
-
- public boolean check() {
- System.out.println("Before : " + controller);
- controller = ! controller; // Change the publication
- System.out.println("After : " + controller);
- return controller;
- }
-
-}
-----
-
-If several interfaces are exposed, the controller may have a `specification` attribute indicating the impacted service:
-
-[source,java]
-----
-@Component
-@Provides
-public class ControllerCheckService implements FooService, CheckService {
-
- @ServiceController(value=false, specification=FooService.class)
- private boolean controller; // Service Controller
-
- public boolean foo() {
- return controller;
- }
-
- public boolean check() {
- System.out.println("Before : " + controller);
- controller = ! controller; // Change the publication
- System.out.println("After : " + controller);
- return controller;
- }
-
-}
-----
-
-In XML, each `provides` can have one `controller` element.
-[source,xml]
- <component classname="org.apache.felix.ipojo.test.scenarios.component.controller.ControllerCheckService"
- name="PS-Controller-1-false">
- <provides>
- <controller field="controller" value="false"/>
- </provides>
- </component>}
-
-=== Being notified of the service registration and unregistration
-
-You can also be notified when the service is published and unpublished.
-This is done by specifying the two callbacks in the `<provides/>` element:
-[source,xml]
- <component
- classname="org.apache.felix.ipojo.test.scenarios.component.callbacks.CallbacksCheckService"
- name="PS-Callbacks-both-1">
- <provides
- specifications="org.apache.felix.ipojo.test.scenarios.ps.service.FooService"
- post-unregistration="unregistered" post-registration="registered"/>
- <provides
- specifications="org.apache.felix.ipojo.test.scenarios.ps.service.CheckService"
- post-unregistration="unregistered" post-registration="registered"/>
- </component>
-
-Or by using the `@PostRegistration` and `@PostUnregistration` annotations:
-
-[source,java]
-----
-@PostRegistration
-public void registered(ServiceReference ref) {
- System.out.println("Registered");
-}
-
-@PostUnregistration
-public void unregistered(ServiceReference ref) {
- System.out.println("Unregistered");
-}
-----
-
-* The `post-registration` callback is called after the service publication
-* The `post-unregistration` callback is called after the service unpublication
-
-Those callback methods must have the following signature: `public void name(ServiceReference ref)`.
-So they receive the published / unpublished service reference.
-The callbacks are called in the _same thread_ as the publication / unpublication itself.
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/service-requirement-handler.adoc b/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/service-requirement-handler.adoc
deleted file mode 100644
index 1fffc37..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/service-requirement-handler.adoc
+++ /dev/null
@@ -1,867 +0,0 @@
-= Requiring services
-
-_One of the main iPOJO feature is the service injection.
-So, a component can consume a service without managing the service discovery, tracking and binding.
-iPOJO manages all these interactions and injects required service into the component.
-This page explains how to use services._
-
-
-
-== Service Dependency
-
-=== What's a service dependency?
-
-A required service is described by a service dependency.
-The dependency defines what kind of service is required, how to select the it, the resilience to its dynamism...
-iPOJO handles all these aspects for you, just tell, iPOJO tracks, selects, binds and injects the matching services directly in your code.
-Service dependencies can be:
-
-* Scalar or Aggregate : the component can require one or several service providers
-* Mandatory or Optional : a component can declare an optional dependency, and defined what should be done when no services are available
-* Filtered : a component can filter available providers, and even choose a specific provider
-* Resilient to dynamism : iPOJO supports three binding policy depending on your reaction to dynamism
-
-=== Dynamism, Resilience & Instance Lifecycle
-
-In OSGi™, services can appear and disappear dynamically.
-This implies dependencies can target a provider which can appear or disappear dynamically.
-So, dependencies need to manage this dynamism by tracking every time available services.
-At any moment, a dependency can be unresolved (i.e.
-no more provider can fulfill the requirement).
-In the case of a mandatory requirement, the instance becomes invalid (an invalid instance is no more accessible externally, for example provided services are unpublished).
-If a service, resolving the unfilled dependency appears, the instance becomes valid.
-In consequence, dependencies affect directly the instance state, and must manage correctly OSGi dynamism to allow a complete unloading when a service goes away.
-As soon a mandatory dependency cannot be fulfilled, the instance is invalidated.
-
-By default, dependencies are managed dynamically (as previously explained).
-However, iPOJO supports two other types of binding policies:
-
-* Static : if a bound service disappears, the instance is invalidated and cannot be revalidated (binding broken forever)
-* Dynamic-Priority: at each injection, the _best_ provider is injected, or the providers array is sorted according to the OSGi Ranking policy or to a specified sorting algorithm.
-
-== Service Requirement Injection Mechanisms
-
-iPOJO support several types of injections:
-
-*Field injection*: a field contains the service object.
-As soon as the field is used, a consistent service object is injected.
-This injection type fully hides the dynamism
-
-[source,java]
- @Requires
- private LogService log;
-
-*Method invocation*: when a service appears, or disappears a method in the component is invoked.
-For each dependency, bind / unbind / modified methods are invoked to notify the component of the event.
-
-[source,java]
- @Bind
- public void bindLogService(LogService log) { /*...*/ }
- @Unbind
- public void unbindLogService(LogService log) { /*...*/ }
- @Modified
- public void modifiedLogService(LogService log) { /*...*/ }
-
-*Constructor injection*: services can also be injected as constructor parameter (only if proxies are enabled).
-_1.7.0-SNAPSHOT_
-
-[source,java]
- public MyComponent(@Requires LogService log) { /*...*/ }
-
-Moreover, the injections types can be mixed.
-A component can declare a requirement containing both a field and 'binding' methods.
-
-=== Field injection
-
-Let's imagine a Hello service with one method 'getMessage' returning a "Hello Message".
-The following component implementation can use this service by attaching this service to a field and by using the field:
-
-[source,java]
-----
-@Component
-@Instantiate
-public class HelloConsumer {
- @Requires
- private Hello m_hello;
-
- public doSomething() {
- System.out.println(m_hello.getMesage());
- }
-}
-----
-
-You can also use XML to describe this component type:
-[source,xml]
- <component classname="...HelloConsumer">
- <requires field="m_hello"/>
- ...
- </component>
-
-The metadata contains a 'requires' element (representing the service dependency) and specify a field used to inject the service.
-The implementation uses the field as a normal field without managing service interactions.
-
-=== Method invocation
-
-The second injection mechanism uses methods in the implementation class.
-By this way, the dynamics can be managed directly by the developer.
-Each dependency can declare three methods:
-
-* A bind method called when a service appears
-* An unbind method called when a service disappears
-* A modified method called when a service is modified (the service properties have changed, but the service still matches the requirement)
-
-Moreover, callbacks can be in the component super class (in this case methods must be public).
-These methods can have one of these signatures:
-
-* Without any argument: the method is just a notification
-
- [source,java]
- public void bindService() {
- // ...
- }
-
-* With the service object: the object is the implicated service object.
-Service dependency type is inferred from the parameter's type.
-
- [source,java]
- public void bindService(HelloService hello) {
- m_hello = hello;
- }
-
-* With an OSGi service reference: the service reference appearing or disappearing.
-
- [source,java]
- public void bindService(ServiceReference<HelloService> reference) {
- // ...
- }
- public void bindService(ServiceReference reference) {
- // ...
- }
- public void bindService(ServiceReference reference) {
- // ...
- }
-
-* With the service object and the OSGi service reference.
-
- [source,java]
- public void bindService(HelloService hello, ServiceReference<HelloService> reference) {
- // ...
- }
-
-* With the service object and the service properties inside a Map (no adherence to OSGi APIs).
-
- [source,java]
- public void bindService(HelloService hello, Map<String, Object> properties) {
- // ...
- }
-
-* With the service object and the service properties inside a Dictionary (no adherence to OSGi APIs).
-
- [source,java]
- public void bindService(HelloService hello, Dictionary<String, Object> properties) {
- // ...
- }
-
-=== ALERT Important
-
-Notice that, when missing (typically no interface can be inferred from the code) dependency information must be supplied to iPOJO in some way
-
-* `@Bind` with `specification` and/or `filter` attribute
-* Using XML metadata declaration
-
-The following component implementation shows an example of implementation using this mechanism:
-
-[source,java]
-----
-@Component
-public class HelloConsumer {
- private Hello m_hello;
-
- @Bind
- public void bindHello(Hello h) { m_hello = h; }
- @Unbind
- public void unbindHello() { m_hello = null; }
- public doSomething() { System.out.println(m_hello.getMesage()); }
-}
-----
-
-The `modified` callback is not mandatory.
-The following XML metadata are describing the same component type:
-[source,xml]
- <component classname="...HelloConsumer">
- <requires>
- <callback type="bind" method="bindHello"/>
- <callback type="unbind" method="unbindHello"/>
- </requires>
- ...
- </component>
-
-Note, that the different callbacks can be have different signatures.
-By using this mechanism, you need to be sure to manage the dynamism correctly.
-(<<note-on-service-interface-discovery,See note on type discovery>>
-
-Using the `@Modified` callback is also quite simple:
-
-[source,java]
-----
-@Component
-public class HelloConsumer {
- private Hello m_hello;
-
- @Bind
- public void bindHello(Hello h) { m_hello = h; }
- @Unbind
- public void unbindHello() { m_hello = null; }
- @Modified
- public void modifiedHello() { /* ... */ }
- public doSomething() { System.out.println(m_hello.getMesage()); }
-}
-----
-
-=== Using constructor injection (_1.7.0-SNAPSHOT_)
-
-Services can also be injected using constructor parameters:
-
-[source,java]
-----
-@Component
-public class MyComponent {
- private LogService log;
-
- public MyComponent(@Requires LogService log) {
- this.log = log;
- }
-}
-----
-
-=== Mixing injections types
-
-The different mechanisms can be used together.
-In this case, the field receives the value before the bind method invocation.
-Constructor parameters get their values during the constructor invocation.
-So, if the field is used in the method, the returned value will be up to date.
-The following component implementation uses this mechanism:
-
-[source,java]
-----
-public class HelloConsumer {
- @Requires(id="hello")
- private Hello m_hello; // Injected Field
-
- @Bind(id="hello")
- public void bindHello() { System.out.println("Hello appears"); }
- @Unbind(id="hello")
- public void unbindHello() { System.out.println("Hello disapears"); }
-
- public doSomething() { System.out.println(m_hello.getMesage()); }
-}
-----
-
-In XML, it results in:
-[source,xml]
- <component classname="...HelloConsumer">
- <requires field="m_hello">
- <callback type="bind" method="bindHello"/>
- <callback type="unbind" method="unbindHello"/>
- </requires>
- ...
- </component>
-
-The `id` attribute is used to determine which callbacks / fields go together.
-If ommitted, it is computed automaticcally:
-
-* for field it uses the field type.
-* for method starting with `bind` / `unbind` / `modified`, it extract the end of the method name (`+bindFoo => Foo+`)
-* for constructor parameter, it uses the parameter index
-
-So, it is strongly recommended to specify the id manually.
-
-=== Injection mechanisms & lazy object creation
-
-iPOJO creates objects only when required.
-When needed, iPOJO invokes the constructor of the implementation class.
-The implementation class can use field requirement because values are already injected and obviously constructor parameters.
-However, method dependencies are called _after_ the constructor.
-If the service is available before the constructor call, the invocation of the bind methods is delayed until the a component class object is created.
-
-== Examples
-
-For all examples both annotations and XML forms are given.
-Just choose what you'd like to use.
-
-=== Simple Requirement
-
-By default, a requirement is mandatory, non-filtered and simple (non-aggregate).
-The previous examples illustrate this kind of dependency.
-When services goes away and appears, the service substitution is hidden.
-Fields attached to simple requirement point always a consistent service object.
-For a simple dependency, the bind method is called once time when the service appears or just after the POJO constructor invocation is the service is available.
-When the service disappears the unbind method is called.
-The bind method is re-invoked as soon as another service provider is available.
-This invocation occurs immediately if another service provider if available.
-In this case, the instance is not invalidated.
-
-=== Aggregate Requirement
-
-When a component requires several providers of the same service, it declares an aggregate dependency.
-
-==== Aggregate Dependency with field injection
-
-[source,java]
- @Component
- public class HelloConsumer {
- @Requires
- private Hello m_hellos[]; // Array => Aggregate
- public doSomething() {
- for(int I = 0; I < m_hellos.length; i++) {
- System.out.println(m_hellos[i].getMessage());
- }
- }
- }
-
-For this component, XML metadata could be:
-[source,xml]
- <component classname="...HelloConsumer">
- <requires field="m_hellos"/>
- ...
- </component>
-
-To declare an aggregate field for field requirement, you only need to declare an array (instead of a scalar type).
-iPOJO will create and inject the service object array.
-iPOJO discover that the dependency is aggregate during the bytecode introspection.
-
-Array types cannot be 'proxied'.
-Moreover array dependencies cannot be injected as constructor parameter.
-
-==== Synchronization
-
-The synchronization is managed by iPOJO.
-As soon as you are 'touching' a dependency in a method, iPOJO ensure that you will keep these objects until the end of the method.
-Nested methods will share the same service object set.
-
-==== Aggregate Dependency with field injection: list, vector, collection and set
-
-It is also possible to inject service objects inside fields of the type:
-
-* list
-* vector
-* collection
-* set
-+
-[source,java]
-----
- @Component
- @Instantiate
- public class HelloConsumer {
- @Requires
- private Hello m_hello;
-
- public doSomething() {
- System.out.println(m_hello.getMesage());
- }
- }
-----
-For this component, XML metadata could be:
-
-[source,xml]
- <component classname="...HelloConsumer">
- <requires field="m_hellos" specification="org.apache.felix.ipojo.example.Hello"/>
- ...
- </component>
-
-In this case, just use the supported type that you want.
-iPOJO will automatically understand that it is an aggregate dependency, and will create the collection object containing service objects.
-However, you must specify the service specification.
-Indeed, generics types cannot be discovered at runtime reliably.
-
-==== Service specification discovery
-
-The service specification (i.e.
-interface) cannot be discovered when using these types as the bytecode does not provide enough information.
-So, you have to indicate the required service interface (with the 'specification' attribute) in the requirement description.
-
-==== How iPOJO manage the synchronization for you
-
-As in the previous case, the synchronization is managed by iPOJO.
-As soon as you are *touching* a dependency in a method, iPOJO ensure that you will keep these objects until the end of the method.
-Nested methods will share the same service object set.
-
-==== Aggregate Dependency with callbacks
-
-[source,java]
- public class HelloConsumer {
- private List m_hellos = new ArrayList();
- @Bind(aggregate=true)
- private void bindHello(Hello h) { m_hellos.add(h); }
- @Unbind
- private void unbindHello(Hello h) { m_hellos.remove(h); }
- public synchronized doSomething() {
- for(Hello h : m_hellos) {
- System.out.println(h.getMessage());
- }
- }
- }
- }
-
-This dependency can also be described in XML as follow:
-
-[source,xml]
- <requires aggregate="true">
- <callback type="bind" method="bindHello"/>
- <callback type="unbind" method="unbindHello"/>
- </requires>
-
-In this case, iPOJO cannot detect if the dependency is aggregate or not.
-So, you need to add the '_aggregate_' attribute.
-The bindHello and unbindHello will be called each time a Hello service appears or disappears.
-
-==== Synchronization
-
-To avoid the list modification during the loop, you need synchronized the block.
-Indeed, as the field is not an iPOJO requirement, iPOJO will not manage the synchronization.
-
-=== Optional Requirement (Scalar)
-
-An optional requirement does not invalidate the instance despite no providers are available.
-Moreover, it is possible to inject a default service implementation when no _real_ providers are available.
-
-==== Optional Requirement with field injection
-
-[source,java]
-----
-@Component
-public class HelloConsumer {
- @Requires(optional=true)
- private Hello m_hello;
-
- public doSomething() {
- System.out.println(m_hello.getMesage());
- }
-}
-----
-
-For this component, equivalent XML metadata could be:
-[source,xml]
- <component classname="...HelloConsumer">
- <requires field="m_hello" optional="true"/>
- ...
- </component>
-
-To declare an optional requirement, you need to add the _'optional'_ attribute.
-To avoid `null` pointer exception, iPOJO injects a `Nullable` object in the field when no service provider is available.
-The _nullable_ object implements the service interface, but does nothing.
-Moreover, it is possible to set a _default-implementation_ for the service.
-A default-implementation is a class implementing the service but used only when no others service providers are available.
-The default-implementation object will be injected instead of the _Nullable_ objet.
-For further information <<note-about-nullable-object-default-implementation,refer to the note about nullable object>>.
-
-==== Optional Dependency with callbacks invocation
-
-[source,java]
-----
-@Component
-public class HelloConsumer {
- private Hello m_hello;
-
- @Bind(optional=true)
- public void bindHello(Hello h) { m_hello = h; }
-
- @Unbind
- public void unbindHello() { m_hello = null; }
-
- public doSomething() {
- if(m_hello != null) { // Must be checked
- System.out.println(m_hello.getMesage());
- }
- }
-}
-----
-
-For this component, XML metadata could be:
-[source,xml]
- <component classname="...HelloConsumer">
- <requires optional="true">
- <callback type="bind" method="bindHello"/>
- <callback type="unbind" method="unbindHello"/>
- </requires>
- ...
- </component>
-
-As for field requirement, the dependency metadata needs to contain the optional attribute.
-iPOJO invokes the method only when a 'real' service is available, so you need to test if `m_hello` is `null` before to use it.
-
-=== Aggregate & Optional Requirement
-
-A dependency can be both aggregate and optional.
-
-==== Aggregate & Optional Dependency with field injection
-
-[source,java]
-----
-@Component
-public class HelloConsumer {
- @Requires(optional=true)
- private Hello m_hellos[];
-
- public doSomething() {
- for(Hello h : m_hellos) {
- System.out.println(h.getMessage());
- }
- }
-}
-----
-
-For this component, XML metadata could be:
-[source,xml]
- <component classname="...HelloConsumer">
- <requires field="m_hellos" optional="true"/>
- ...
- </component>
-
-To declare an optional & aggregate field requirement you need to write the optional attribute in the dependency metadata and to point on a field array.
-If no service available, iPOJO injects an empty array.
-
-==== Aggregate & Optional Requirement with callbacks
-
-[source,java]
-----
-@Component
-public class HelloConsumer {
-
- private List m_hellos<Hello> = new ArrayList<Hello>();
-
- @Bind(aggregate=true, optional=true)
- private void bindHello(Hello h) { m_hellos.add(h); }
-
- @Unbind
- private void unbindHello(Hello h) { m_hellos.remove(h); }
-
- public synchronized doSomething() {
- for(Hello h : m_hellos) {
- System.out.println(h.getMessage());
- }
- }
-}
-----
-
-For this component, XML metadata could be:
-[source,xml]
- <requires aggregate="true" optional="true">
- <callback type="bind" method="bindHello"/>
- <callback type="unbind" method="unbindHello"/>
- </requires>
-
-In this case, you need to add the _'aggregate'_ attribute and the __'optional'__attribute.
-The `bindHello` and `unbindHello` will be called each time a Hello service appears or disappears.
-These bind / unbind methods are not called when binding / unbinding a Nullable object (when both field and method are used).
-
-=== Filtered Requirement
-
-A filtered dependency applies an LDAP filter on service provider.
-iPOJO reuses OSGi LDAP filter ability.
-The following metadata illustrates how to use filters:
-
-[source,java]
-----
-@Requires(filter="(language=fr)")
-private String DictionaryService dict;
-[source,xml]
-<requires filter="(language=fr)" field="dict"/>
-----
-
-To add a filter, just add a 'filter' attribute in your dependency containing the LDAP filter.
-iPOJO will select only provider matching with this filter.
-
-When using a filter, you can also use the `modified` callback invoked when a matching service is _modified_ but still matches the filter:
-
-[source,java]
-----
-@Component
-public class MyComponent {
-
- @Bind(filter="(langage=en)")
- public void bindHDictionary(DictionaryService svc) { ... }
-
- @Unbind
- public void unbindDictionary() { ...}
-
- @Modified
- public void modifiedDictionary() { ... }
-}
-----
-
-Moreover, filters can be customized instance by instance.
-It is possible to specialize / change / add the filter of a component in the instance description.
-It is useful when you want to create different instances of the same component, with different filter.
-To achieve this customization, you have to identify your dependency with the 'id' attribute.
-Then, you can adapt the filter of the dependency in the instance description by using the property "requires.filters".
-In this property you can specify each dependency identified by its id and the new value of the filter.
-
-[source,xml]
-----
-<component
- className="org.apache.felix.ipojo.example.FilteredDependency">
- <requires field="m_foo" fiter="(foo.property=FOO)" id="id1">
- <callback type="bind" method="bind"/>
- <callback type="unbind" method="unbind"/>
- </requires>
-</component>
-
-<instance name="FOO1" component="FOO"/>
-
-<instance name="FOO2" component="FOO">
- <property name="requires.filters">
- <property name="id1" value="(foo.property=BAR)"/>
- </property>
-</instance>
-
-<instance name="FOO3" component="FOO">
... 4654 lines suppressed ...
[felix-antora-site] 09/18: remove maven obr plugin doc
(unmaintained)
Posted by dj...@apache.org.
This is an automated email from the ASF dual-hosted git repository.
djencks pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/felix-antora-site.git
commit 219c70e2ae3ca6b3f2f8307e97e9f4f5e76b57ce
Author: David Jencks <dj...@apache.org>
AuthorDate: Sun Jul 11 15:44:23 2021 -0700
remove maven obr plugin doc (unmaintained)
---
modules/ROOT/pages/documentation/subprojects.adoc | 2 +-
.../subprojects/apache-felix-maven-obr-plugin.adoc | 212 ---------------------
2 files changed, 1 insertion(+), 213 deletions(-)
diff --git a/modules/ROOT/pages/documentation/subprojects.adoc b/modules/ROOT/pages/documentation/subprojects.adoc
index 32fcbce..5069fd6 100644
--- a/modules/ROOT/pages/documentation/subprojects.adoc
+++ b/modules/ROOT/pages/documentation/subprojects.adoc
@@ -121,7 +121,7 @@ The last documentation may be found in the https://github.com/apache/felix-site-
* https://github.com/apache/felix-site-pub/blob/last-cms/documentation/subprojects/apache-felix-jaas.html[JAAS Support]
* https://github.com/apache/felix-site-pub/blob/last-cms/documentation/subprojects/apache-felix-lightweight-http-service.html[Lightweight HTTP Service]
* https://github.com/apache/felix-site-pub/blob/last-cms/documentation/subprojects/apache-felix-manifest-generator-mangen.html[Manifest Generator (mangen)]
-* xref:documentation/subprojects/apache-felix-maven-obr-plugin.adoc[Maven OBR Plugin]
+* https://github.com/apache/felix-site-pub/blob/last-cms/documentation/subprojects/apache-felix-maven-obr-plugin.html[Maven OBR Plugin]
* xref:documentation/subprojects/apache-felix-maven-osgi-plugin.adoc[Maven OSGi Plugin]
* xref:documentation/subprojects/apache-felix-maven-scr-plugin.adoc[Maven SCR Plugin]
* xref:documentation/subprojects/mosgi-managed-osgi-framework.adoc[MOSGi Managed OSGi framework]
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-maven-obr-plugin.adoc b/modules/ROOT/pages/documentation/subprojects/apache-felix-maven-obr-plugin.adoc
deleted file mode 100644
index a843834..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-maven-obr-plugin.adoc
+++ /dev/null
@@ -1,212 +0,0 @@
-= Apache Felix Maven OBR Plugin
-
-WARNING: The _maven-obr-plugin_ is _deprecated_ and its features have been _merged_ into the _1.4.0_ release of the xref:documentation/subprojects/apache-felix-maven-bundle-plugin-bnd.adoc[maven-bundle-plugin]
-
-This Maven plug-in aims to automate OBR (OSGi Bundle Repository) management.
-It helps manage a local OBR for your local Maven repository, and also supports remote OBRs for bundle distribution.
-The plug-in automatically computes bundle capabilities and requirements, using a combination of Bindex and Maven metadata.
-
-== Features
-
-The maven-obr-plugin supports:
-
-* Management of both local and remote OBRs
-* Registering Maven and non-Maven artifacts with OBRs
-* Automatically discovering bundle capabilities and requirements
-* Customizing bundle descriptions
-
-== How to use the maven-obr-plugin?
-
-The plug-in offers five Maven goals:
-
-* _install_ adds the current bundle project to the local OBR
-* _install-file_ adds a local bundle file to the local OBR
-* _deploy_ adds the current bundle project to a remote OBR
-* _deploy-file_ adds a local bundle file to a remote OBR
-* _clean_ cleans the local OBR, removing missing bundles
-
-Any of these goals can be disabled by setting `\-DobrRepository=NONE`
-
-== obr:install
-
-The _install_ goal updates the local OBR with the details of the installed bundle from the local Maven repository.
-
-(If the project has an `obr.xml` file somewhere in its resources, then it will be automatically detected and applied.)
-
-configuration:
-
-* _obrRepository_ path to local OBR, defaults to *<local-maven-repository>*`/repository.xml`
-
-To attach this goal to your project's lifecycle, use:
-
- <plugin>
- <groupId>org.apache.felix</groupId>
- <artifactId>maven-obr-plugin</artifactId>
- <version>1.2.0</version>
- <executions>
- <execution>
- <goals>
- <goal>install</goal>
- </goals>
- </execution>
- </executions>
- </plugin>
-
-== obr:install-file
-
-The _install-file_ goal updates the local OBR with the details of a bundle from the local filesystem.
-
-configuration:
-
-* _obrRepository_ path to local OBR, defaults to *<local-maven-repository>*`/repository.xml`
-* _groupId_ Maven groupId for the bundle, taken from _pomFile_ if given
-* _artifactId_ Maven artifactId for the bundle, taken from _pomFile_ if given
-* _version_ Maven version for the bundle, taken from _pomFile_ if given
-* _packaging_ Maven packaging type for the bundle, taken from _pomFile_ if given
-* _classifier_ Maven classifier type, defaults to none
-* _pomFile_ optional Pom file describing the bundle
-* _file_ bundle file, defaults to the bundle from the local Maven repository
-* _obrXml_ optional additional properties for the bundle
-
-Example:
-
- mvn org.apache.felix:maven-obr-plugin:1.2.0:install-file \
- -DpomFile=myPom.xml -Dfile=foo-1.0.jar
-
-== obr:deploy
-
-The _deploy goal_ updates the remote OBR with the details of the deployed bundle from the local Maven repository.
-The remote OBR is found by querying the `<distributionManagement>` section of the project, unless `\-DaltDeploymentRepository` is set.
-See http://maven.apache.org/plugins/maven-deploy-plugin/deploy-mojo.html for more details about these particular settings.
-
-(If the project has an `obr.xml` file somewhere in its resources, then it will be automatically detected and applied.)
-
-configuration:
-
-* _obrRepository_ name of remote OBR, defaults to `repository.xml`
-* _altDeploymentRepository_ alternative remote repository, _id::layout::url_
-* _ignoreLock_ ignore remote locking when updating the OBR
-
-To attach this goal to your project's lifecycle, use:
-
- <plugin>
- <groupId>org.apache.felix</groupId>
- <artifactId>maven-obr-plugin</artifactId>
- <version>1.2.0</version>
- <executions>
- <execution>
- <goals>
- <goal>deploy</goal>
- </goals>
- </execution>
- </executions>
- </plugin>
-
-== obr:deploy-file
-
-The _deploy-file_ goal updates the remote OBR with the details of a deployed bundle from the local filesystem.
-The remote OBR is found using the `\-DrepositoryId` and `\-Durl` parameters.
-See http://maven.apache.org/plugins/maven-deploy-plugin/deploy-file-mojo.html for more details about these particular settings.
-
-You can use the `\-DbundleUrl` parameter to give the public location of the deployed bundle, which may differ from the remote OBR location.
-
-configuration:
-
-* _obrRepository_ name of remote OBR, defaults to `repository.xml`
-* _repositoryId_ optional repository id, used to lookup authentication settings
-* _url_ remote repository transport URL, like
-+
-scpexe://host/path/to/obr
-
-* _bundleUrl_ public URL of deployed bundle, like
-+
-http://www.foo.org/bundles/foo.jar
-
-* _groupId_ Maven groupId for the bundle, taken from _pomFile_ if given
-* _artifactId_ Maven artifactId for the bundle, taken from _pomFile_ if given
-* _version_ Maven version for the bundle, taken from _pomFile_ if given
-* _packaging_ Maven packaging type for the bundle, taken from _pomFile_ if given
-* _classifier_ Maven classifier type, defaults to none
-* _pomFile_ optional Pom file describing the bundle
-* _file_ bundle file, defaults to the bundle from the local Maven repository
-* _obrXml_ optional additional properties for the bundle
-* _ignoreLock_ ignore remote locking when updating the OBR
-
-Example:
-
- mvn org.apache.felix:maven-obr-plugin:1.2.0:deploy-file \
- -DpomFile=myPom.xml -Dfile=foo-1.0.jar -Durl=file:/tmp/example/OBR \
- -DbundleUrl=http://www.foo.org/bundles/foo.jar
-
-== obr:clean
-
-Sometimes you would like to clean your local OBR because it contains bundles that are no longer in your local Maven repository.
-This case often occurs when artifacts were deleted manually.
-The maven-obr-plugin provides a simple goal to check for missing bundles, and remove them from the local OBR.
-
-configuration:
-
-* _obrRepository_ path to local OBR, defaults to *<local-maven-repository>*`{}{`}`/repository.xml`
-
-To attach this goal to your project's lifecycle, use:
-
- <plugin>
- <groupId>org.apache.felix</groupId>
- <artifactId>maven-obr-plugin</artifactId>
- <version>1.2.0</version>
- <executions>
- <execution>
- <goals>
- <goal>clean</goal>
- </goals>
- </execution>
- </executions>
- </plugin>
-
-== Concurrent updates
-
-With a remote OBR, several uploads may occur at the same time.
-However, the remote OBR is centralized in one file, so concurrent modification must be avoided.
-To achieve this, the plug-in implements a locking system.
-Each time the plug-in tries to modify the file it sets a file based lock.
-If it can't take the lock, it will wait and retry.
-After 3 attempts the upload process fails.
-To bypass this lock add `\-DignoreLock` to the command-line (or add `<ignoreLock>true<ignoreLock>` to the configuration section of your Pom).
-
-== FTP protocol
-
-Not all protocols are supported by Maven out of the box.
-For example the ftp protocol requires the _wagon-ftp_ component.
-To enable the ftp protocol add this to your Pom:
-
- <build>
- <extensions>
- <extension>
- <groupId>org.apache.maven.wagon</groupId>
- <artifactId>wagon-ftp</artifactId>
- <version>1.0-alpha-6</version>
- </extension>
- </extensions>
- </build>
-
-== How the plug-in computes the description of the bundle
-
-The description of the bundle comes from three different sources:
-
-* Bindex : Bindex is a tool that analyzes a bundle manifest to generate OBR description
-* pom.xml : by analyzing the pom file, various information is collected (symbolic name ...)
-* obr.xml : this file contains customized description and capabilities for the bundle
-
-These sources are merged together using the following precedence:
-
- Bindex
- | (overrides)
- pom.xml
- | (overrides)
- obr.xml
-
-A warning message is displayed when existing information is overridden.
-
-== Known issues & limitations
-
-. obr.xml (file given by the user to add properties not found by Bindex) must be correct, because the plug-in does not check its syntax.
[felix-antora-site] 02/18: remove autoconf doc (unmaintained)
Posted by dj...@apache.org.
This is an automated email from the ASF dual-hosted git repository.
djencks pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/felix-antora-site.git
commit cc79e75a0753cc9a0e5565abcc79ab2fb154728b
Author: David Jencks <dj...@apache.org>
AuthorDate: Sun Jul 11 15:34:24 2021 -0700
remove autoconf doc (unmaintained)
---
modules/ROOT/pages/documentation/subprojects.adoc | 7 ++++---
.../pages/documentation/subprojects/apache-felix-autoconf.adoc | 4 ----
2 files changed, 4 insertions(+), 7 deletions(-)
diff --git a/modules/ROOT/pages/documentation/subprojects.adoc b/modules/ROOT/pages/documentation/subprojects.adoc
index 460b2fc..d44b765 100644
--- a/modules/ROOT/pages/documentation/subprojects.adoc
+++ b/modules/ROOT/pages/documentation/subprojects.adoc
@@ -113,11 +113,12 @@ If this project is not using Maven, refer to the docs for the subproject on how
| https://github.com/apache/felix-dev/tree/master/webconsole[source]
|===
-== Maintenance
+== Retired projects
-The following projects are in maintenance mode meaning there is no active development anymore.
+The following projects are no longer maintained and are not documented in this site.
+The last documentation may be found in the https://github.com/apache/felix-site-pub/tree/last-cms repository.
-* xref:documentation/subprojects/apache-felix-autoconf.adoc[Auto Configuration]
+* https://github.com/apache/felix-site-pub/blob/last-cms/documentation/subprojects/apache-felix-autoconf.html[Auto Configuration]
* xref:documentation/subprojects/apache-felix-commons.adoc[Commons]
* xref:documentation/subprojects/apache-felix-deployment-admin.adoc[Deployment Admin]
* xref:documentation/subprojects/apache-felix-jaas.adoc[JAAS Support]
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-autoconf.adoc b/modules/ROOT/pages/documentation/subprojects/apache-felix-autoconf.adoc
deleted file mode 100644
index 824f863..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-autoconf.adoc
+++ /dev/null
@@ -1,4 +0,0 @@
-= Apache Felix Auto Configuration
-
-This project implements the OSGi Auto Configuration specification;
-please consult the OSGi Compendium Specification chapter 115 for more information.
[felix-antora-site] 16/18: remove upnp doc (unmaintained)
Posted by dj...@apache.org.
This is an automated email from the ASF dual-hosted git repository.
djencks pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/felix-antora-site.git
commit 778aa40604edc747ec3cd14c53e6caa2d5595cbd
Author: David Jencks <dj...@apache.org>
AuthorDate: Sun Jul 11 15:52:51 2021 -0700
remove upnp doc (unmaintained)
---
modules/ROOT/pages/documentation/subprojects.adoc | 2 +-
.../subprojects/apache-felix-upnp.adoc | 23 ----
.../apache-felix-upnp/upnp-acknowledgments.adoc | 11 --
.../upnp-driver-architecture.adoc | 61 -----------
.../apache-felix-upnp/upnp-getting-started.adoc | 56 ----------
.../apache-felix-upnp/upnp-known-issues.adoc | 12 ---
.../apache-felix-upnp/upnp-testing-devices.adoc | 54 ----------
.../upnp-testing-devices/upnp-examples.adoc | 41 --------
.../upnp-examples/upnp-writing-cd-and-cp.adoc | 117 ---------------------
9 files changed, 1 insertion(+), 376 deletions(-)
diff --git a/modules/ROOT/pages/documentation/subprojects.adoc b/modules/ROOT/pages/documentation/subprojects.adoc
index b125e82..2584fbe 100644
--- a/modules/ROOT/pages/documentation/subprojects.adoc
+++ b/modules/ROOT/pages/documentation/subprojects.adoc
@@ -128,5 +128,5 @@ The last documentation may be found in the https://github.com/apache/felix-site-
* https://github.com/apache/felix-site-pub/blob/last-cms/documentation/subprojects/apache-felix-osgi-core.html[OSGi Core]
* https://github.com/apache/felix-site-pub/blob/last-cms/documentation/subprojects/apache-felix-script-console-plugin.html[Script Console Plugin]
* https://github.com/apache/felix-site-pub/blob/last-cms/documentation/subprojects/apache-felix-serialization-framework.html[Serialization Framework]
-* xref:documentation/subprojects/apache-felix-upnp.adoc[UPnP]
+* https://github.com/apache/felix-site-pub/blob/last-cms/documentation/subprojects/apache-felix-upnp.html[UPnP]
* xref:documentation/subprojects/apache-felix-user-admin.adoc[User Admin]
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-upnp.adoc b/modules/ROOT/pages/documentation/subprojects/apache-felix-upnp.adoc
deleted file mode 100644
index d5a6cc4..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-upnp.adoc
+++ /dev/null
@@ -1,23 +0,0 @@
-= Apache Felix UPnP
-
-== Introduction
-
-The Felix UPnP project provides an implementation of the OSGi UPnP specification (version 1.1) as described in the http://www.osgi.org/Specifications/HomePage[OSGi Service Compendium (Release 4)] . The specification is implemented by the _org.apache.felix.upnp.basedriver_ bundle and it comes with other bundles, which have been developed to ease the writing and testing of UPnP code.
-
-The OSGi UPnP specification defines a set of interfaces which should be used by the developers in order to write UPnP Devices and UPnP Control Points on the OSGi Service Platform.
-From the OSGi point of view, UPnP devices are services registered with the framework, thus the different phases of the UPnP protocol stack, as defined in the http://www.upnp.org/resources/documents/CleanUPnPDA101-20031202s.pdf[UPnP™ Device Architecture (UDA 1.0)], have been mapped to the discovery and notification mechanisms offered by the OSGi framework.
-
-The specification defines a UPnP Base Driver component that acts as software bridge between UPnP networks and OSGi.
-Developers writing UPnP code do not need to interact directly with the driver through some API.
-The driver works in background by exporting the registered services as UPnP devices, and by registering as services the UPnP devices discovered on UPnP networks.
-However, the Felix UPnP project has defined few additional interfaces, so a base knowledge of the way the UPnP Base Driver works is useful and will help developers to write their code.
-
-Table of Content:
-
-. xref:documentation/subprojects/apache-felix-upnp/upnp-getting-started.adoc[Getting Started]
-. xref:documentation/subprojects/apache-felix-upnp/upnp-driver-architecture.adoc[Overview of the Base Driver Architecture]
-. xref:documentation/subprojects/apache-felix-upnp/upnp-testing-devices.adoc[Testing UPnP devices]
-. xref:documentation/subprojects/apache-felix-upnp/upnp-testing-devices/upnp-examples.adoc[The UPnP examples]
-. xref:documentation/subprojects/apache-felix-upnp/upnp-testing-devices/upnp-examples/upnp-writing-cd-and-cp.adoc[Writing UPnP Devices and Control Points]
-. xref:documentation/subprojects/apache-felix-upnp/upnp-known-issues.adoc[Known issues]
-. xref:documentation/subprojects/apache-felix-upnp/upnp-acknowledgments.adoc[Acknowledgments]
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-upnp/upnp-acknowledgments.adoc b/modules/ROOT/pages/documentation/subprojects/apache-felix-upnp/upnp-acknowledgments.adoc
deleted file mode 100644
index 8b8cf6b..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-upnp/upnp-acknowledgments.adoc
+++ /dev/null
@@ -1,11 +0,0 @@
-= UPnP Acknowledgments
-
-[cols=2*]
-|===
-| The Felix UPnP base driver and related bundles were originally developed by the http://domoware.isti.cnr.it/[Domoware] project which targeted the OSGi R3.
-The driver is based on a modified version of the "UPnP for Java" library released by the [Cyberlink
-| http://www.cybergarage.org/net/upnp/java/index.html] project.
-This version, called CyberDomo, is currently maintained by the Domoware project team and aligned to the Cyberlink library regularly.
-|===
-
-== xref:documentation/subprojects/apache-felix-upnp/upnp-known-issues.adoc[Known Issues]
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-upnp/upnp-driver-architecture.adoc b/modules/ROOT/pages/documentation/subprojects/apache-felix-upnp/upnp-driver-architecture.adoc
deleted file mode 100644
index 3c9a342..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-upnp/upnp-driver-architecture.adoc
+++ /dev/null
@@ -1,61 +0,0 @@
-= Overview of the Base Driver Architecture
-
-The Figure 4 shows a simplified component view of the base driver.
-The driver is composed of two components, the _exporter_ and _importer_;
-both using the _CyberDomo_ library, which is a modified version of the library released by the http://www.cybergarage.org/net/upnp/java/index.html["CyberLink for Java" project], maintained by the [Domoware project|http://domoware.isti.cnr.it/ ].
-The library implements a full UPnP stack.
-The base driver acts as a bridge between OSGi and the UPnP networks . !BaseDriverArchitecture.jpg!
-_Figure 4_ The UPnP Base Driver architecture
-
-In order to instantiate UPnP devices, developers must register services implementing the interfaces represented in Figure 5 and provided by the _org.osgi.compendium bundle_.
-The _exporter_ is registered as http://www.osgi.org/javadoc/r4/org/osgi/framework/ServiceListener.html[ServiceListener]with the framework and it automatically exposes on the networks each [UPnPDevice |http://www.osgi.org/javadoc/r4/org/osgi/service/upnp/UPnPDevice.html]service registered with the registration property [UPNP__EXPORT|http://www.osgi.org/javadoc/r4/org/osgi/service/upnp/UPnPDevice.html#UPNP__EXPORT].
-The _importer_ listens to the advertisements sent on the networks by external devices and registers with the framework one or more UPnPDevice services.
-Even if it is not required by the specification, the devices imported by the Felix base driver are labeled with the registration property [UPNP_IMPORT|http://svn.apache.org/viewvc/felix/trunk/upnp/basedriver/src/main/java/org/apache/felix/upnp/basedriver/util/Constants.java?view=markup].
-!UPnPDeviceInterfaces.jpg!
-_Figure 5_ The UPnP Device interfaces
-
-Working with UPnP Device from the OSGi point of view means to operate with services;
-the discovery, controlling and eventing phases of the UPnP protocol are naturally mapped to the OSGi service layer, which allows to publish, find, bind and notify events.
-There are some aspects that make it different to work with UPnP in OSGi with respect to other UPnP libraries, due basically to the centralized nature of the OSGi registry opposed to the distributed approach used in UPnP networks;
-some hints are provided in the section "Writing UPnP Devices and Control Points"
-
-The Felix base driver comes with some system properties you can use to configure it at startup.
-
-The system properties: • _cyberdomo.ssdp.mx_ (default 5) • _cyberdomo.ssdp.buffersize_ (default 2048) • _cyberdomo.ssdp.port_ (default 1900)
-
-[cols=2*]
-|===
-| are used by the UPnP stack library during the UPnP discovery process.
-The paper "http://w3.antd.nist.gov/~mills/papers/Paper521.pdf[Adaptive Jitter Control for UPnP M-Search]" [1] provides a good analysis of the tuning of such parameters related to scalability issues.
-The MX parameter default has been set to 5 sec.
-Higher values improve the discovery effectiveness but increase the latency for new device discovery.
-The Intel "[Device Spy
-| http://www.intel.com/cd/ids/developer/asmo-na/eng/downloads/upnp/index.htm]" tool uses a delay of 10 sec, the "CyberLink for Java" library 3 sec.
-The SSDP port in UPnP specification is by default 1900 we allow the modification of such parameter.
-|===
-
-The following system properties: • _felix.upnpbase.exporter.enabled_ (default true) • _felix.upnpbase.importer.enabled_ (default true)
-
-can be used to enable or disable the two main components of the base driver.
-For example with small devices (ARM-based processor), disabling the exporting or importing of devices might reduce the resource consumption.
-
-• _felix.upnpbase.log_ (default 2) • _felix.upnpbase.cyberdomo.log_ (default false)
-
-are properties used to enable the different logging facilities offered by the base driver.
-You can also modify them at run time by using the GUI provided by the UPnP Tester bundle
-
-Finally the following properties are used to set the networking parameters.
-The loopback interface is usually disabled :
-
-• _felix.upnpbase.cyberdomo.net.loopback_ (default false) • _felix.upnpbase.cyberdomo.net.onlyIPV4_ (default true) • _felix.upnpbase.cyberdomo.net.onlyIPV6_ (default false)
-
-[discrete]
-===== xref:documentation/subprojects/apache-felix-upnp/upnp-getting-started.adoc[Getting Started] [Testing UPnP Devices| UPnP Testing Devices]
-
-'''
-
-[1]({{ refs.1.path }}) K.
-Mills, C.
-Dabrowski "Adaptive Jitter Control for UPnP M-Search" IEEE International Conference on Communications, 2003.
-ICC '03.
-page(s): 1008- 1013 vol.2
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-upnp/upnp-getting-started.adoc b/modules/ROOT/pages/documentation/subprojects/apache-felix-upnp/upnp-getting-started.adoc
deleted file mode 100644
index 742bd04..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-upnp/upnp-getting-started.adoc
+++ /dev/null
@@ -1,56 +0,0 @@
-= Getting Started
-
-Assuming that, as described in xref:documentation/subprojects/building-felix.adoc[Building Felix] web page, you have already checked out the Felix project in the $FELIX__HOME directory, the Felix UPnP project is located at $FELIX__HOME/trunk/upnp directory.
-The project is organized in different directories shown in Figure 1.
-
-!UPnP-Project-Structure.jpg!
-_Figure 1_ The Felix UPnP project structure
-
-The _basedriver_ directory contains the project of the bundle implementing the UPnP spec.
-In the _samples{_}directory there are three projects implementing simple test devices, while the _tester_ and _extra_ directories are projects providing additional utilities for the UPnP development.
-At last, the _doc_ directory contains this documentation and a script file to launch all the Felix UPnP bundles.
-
-After building the Felix project, you can start the script file "upnp.sh.bat" inside the /upnp/doc directory;
-it launches a Felix runtime with all the UPnP bundles released by the project.
-The script file defines a profile called "upnp" and the list of bundles[1]({{ refs.1.path }})installed with the profile is shown in Figure 2.
-The UPnP Tester is a bundle that provides a browser utility to control and subscribe all the UPnP devices registered with the OSGi framework.
-After executing the script, you should see in the window opened by the UPnP Tester bundle three UPnP devices (left panel in Figure 3.a), which correspond to the TV, Clock and BinaryLight devices shown in Figure 3.
-Of course the number of discovered devices may be higher if other UPnP devices are installed in your local network
-
-!Bundle-List.jpg!
-_Figure 2_ Bundles installed by the script "upnp.sh.bat"
-
-[cols=2*]
-|===
-| To stop the devices launched by the script you can close their windows, while to start them again type "start 10 11 12 13" from the Felix shell.
-See the sections "xref:documentation/subprojects/apache-felix-upnp/upnp-testing-devices.adoc[Testing UPnP devices]" and "[The UPnP Examples
-| UPnP Examples]" for details on how to use the these bundles.
-|===
-
-d) UPnP BinaryLight | _Figure 3_ The GUIs started by the script "upnp.sh.bat"
-
-The Felix build process by default uses the JDK1.4 as target class library for all the UPnP bundles.
-The UPnP Base Driver can be built also with the JDK1.3 as target;
-to this end you have to define the "platform" property in the command line: type "mvn Dplatform=jdk13 install" from the /upnp/basedriver directory.
-For details on configuring your Eclipse IDE see [3]({{ refs.3.path }}).
-
-== Common Issues
-
-If you experience problems discovering the UPnP devices of your network:
-
-* Check the configuration of your firewalls.
-UPnP discovery is based on multicast messages over UDP that usually are not filtered by firewalls, on the contrary the XML description of devices is retrieved using HTTP protocol;
-usually bound to non standard ports which might be blocked.
-Check whether firewall is active on your host or on the host of the device you want discover.
-* Install a loopback interface if needed.
-The base driver by default is configured for not using the localhost as loopback interface.
-If you want to run and test UPnP devices on a machine disconnected by any network, you should install and activate a loopback interface.
-Pay attention to disable the loopback interface when you are connected to a network again, otherwise both interfaces will be used to expose the UPnP services registered with the framework.
-
-//
-* xref:documentation/subprojects/apache-felix-upnp.adoc[Introduction]
-* xref:documentation/subprojects/apache-felix-upnp/upnp-driver-architecture.adoc[UPnP Driver architecture]
-
-'''
-
-[1]({{ refs.1.path }}) The actual version of the bundles may be different
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-upnp/upnp-known-issues.adoc b/modules/ROOT/pages/documentation/subprojects/apache-felix-upnp/upnp-known-issues.adoc
deleted file mode 100644
index 633f11f..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-upnp/upnp-known-issues.adoc
+++ /dev/null
@@ -1,12 +0,0 @@
-= Known issues
-
-Currently the bundle does not support the following requirements:
-
-* upnp.ssdp.address Configuration Service
-* exported device changes: if a service already exported as UPnP Device changes its own configuration, i.e.: implements new service, changes the friendly name, etc., the new service description is not reflected on the UPnP Device
-* icons for exported device are not tested
-* no localization support
-
-//
-* xref:documentation/subprojects/apache-felix-upnp/upnp-testing-devices/upnp-examples/upnp-writing-cd-and-cp.adoc[Writing UPnP Devices and Control Points]
-* xref:documentation/subprojects/apache-felix-upnp/upnp-acknowledgments.adoc[UPnP Acknowledgments ]
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-upnp/upnp-testing-devices.adoc b/modules/ROOT/pages/documentation/subprojects/apache-felix-upnp/upnp-testing-devices.adoc
deleted file mode 100644
index e9cfd5d..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-upnp/upnp-testing-devices.adoc
+++ /dev/null
@@ -1,54 +0,0 @@
-= Testing UPnP devices
-
-The _org.apache.felix.upnp.tester_ bundle installs a component that shows the UPnP devices registered with the OSGi framework.
-It provides a GUI shown in the Figure 6 that can be used for controlling the discovered devices: by invoking actions and by subscribing for the state variable changes occurring on them.
-
-!TesterGUI.jpg!
-Figure6 The UPnP Tester GUI
-
-In the left panel you can browse the devices discovered on the OSGi platform.
-Remember that they may be registered by the base driver as well as by other bundles installed on the platform.
-Therefore stopping the base driver you will continue to see the local devices, but they will be no more exported.
-The devices with their hierarchy of the embedded devices and services are represented as nodes of a tree with the following icons:
-
-* !RootDevice.gif!
-Root Device
-* !EmbeddedDevice.gif!
-Embedded Device
-* !Service.gif!
-Service
-* !Action.gif!
-Action
-* !StateVariable.gif!
-State Variable
-* !EventedSteateVariable.gif!
-Evented State Variable
-* !SubscribedStateVariable.gif!
-Subscribed State Variable
-
-By clicking on the Root Device icon, the register properties defined by the device are shown on the right panel.
-You can distinguish between exported and imported devices by looking for the property key "UPnP.export" and "UPnP.device.imported" respectively.
-
-By right-clicking on the Root Device, Embedded device, or Service icon a context menu is displayed to open the XML description of devices and services (see Figure 6)
-
-By clicking on the Service icon, the Service Id and Type are shown in the right panel together with buttons for subscribing all the state variables of the service.
-The received notify message is displayed on the bottom panel.
-
-By clicking on the Action icons, the right panel displays a form where the input parameters of the action can be inserted.
-Use the "do Action" button to execute it;
-the results, if any, will be displayed in the table below the input parameters.
-
-Finally, by clicking on the state variables shows the associated property keys as the default value and minimum and maximum value, if any.
-
-_Menus_
-
-* The "Search" menu forces the UPnP Base Driver to execute a UPnP M-Search for UPnP Root Devices or for all types of devices.
-This search is usually automatically executed during the start up of the base driver.
-* The "Felix Logger" and "Cyber Debugger" menus enable displaying of the messages received and sent by the base driver (i.e.
-the content of the UDP communication).
-* The "Print Pending Devices" is a utility menu to verify whether incomplete hierarchy of embedded devices have been registered with the framework.
-* The "Check Errata UPnPDevices" menu may help the user verify that all the local UPnP Devices have been registered with the mandatory properties, otherwise they would not be exported.
-
-//
-* xref:documentation/subprojects/apache-felix-upnp/upnp-driver-architecture.adoc[Overview of the Base Driver Architecture]
-* xref:documentation/subprojects/apache-felix-upnp/upnp-testing-devices/upnp-examples.adoc[The Felix UPnP Examples| UPnP Examples]
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-upnp/upnp-testing-devices/upnp-examples.adoc b/modules/ROOT/pages/documentation/subprojects/apache-felix-upnp/upnp-testing-devices/upnp-examples.adoc
deleted file mode 100644
index b3221b9..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-upnp/upnp-testing-devices/upnp-examples.adoc
+++ /dev/null
@@ -1,41 +0,0 @@
-= The Felix UPnP Examples
-
-The UPnP examples released by the UPnP project are simple UPnP devices developed as a proof of concept.
-The first two examples, the TV and Clock, are used to check the importing and exporting capabilities of the base driver.
-The third one, the Binary Light, implements a standard UPnP DCP and provides additionally a UPnP presentation page.
-
-== Sample TV and Clock
-
-These devices are dual version of the sample devices developed by the project "Cyberlink for Java" by Satoshi Konno.
-They have been rewritten according to the OSGi specification and can be used to check the importing and exporting capabilities of the base driver.
-The simulated TV screen is used to show the messages received by the Clock device and other simulated device like the Air Conditionator and Washing Machine.
-When launching the original version of such devices you will see that the Felix TV running on the OSGi platform is able to receive the messages from UPnP devices running on different platform and imported in OSGi.
-At the same time, the Cyberlink TV is able to receive the time event generated by the Felix Clock device and exported by the base driver.
-| !FelixUPnPTV.jpg!
-| !FelixClock.jpg!
-| | _Figure 7_ The Felix UPnP TV GUI | _Figure 8_ The Felix UPnP Clock GUI | If you want to avoid installing the Cyberlink devices, you can run a second instance of Felix by clicking on the batch file again.
-In this case the Felix TV and Clock will be exported and re-imported by both Felix runtimes and you will see a duplicated TV and Clock device on each platform.
-Notice that you can stop in any moment a device by closing its window.
-You can start it again from the Felix shell by selecting the respective bundle ID.
-Starting with two running instances of the Felix Clock, you can stop the first one and the TVs will lose for a moment the time signal.
-In fact, being subscribed to the Clock device type and not to a specific device instance, they will receive the time event from the remaining device Clock.
-One TV will be notified from the clock running on the same platform, while the other will receive the events from an imported TV device.
-As soon as you stop also the second clock device, the Time message will disappear from both the TVs.
-
-== The BinaryLight example
-
-The Binary Light device, according the UPnP DCP, shows a graphical interface you can use to switch on/off the light and to simulate the breaking of the lamp bulb.
-In this last circumstance you can see, by using the Felix UPnPDevice Tester interface, that the values of the "Status" and "Target" variable may be different.
-While the "Target" variable represents the expected status after invoking the related action, the "Status" variable describes the real status of the Light Device.
-This example, by exploiting the Felix HTTP Service implementation, installs a UPnP presentation page.
-By code you can retrieve the presentation page URL by looking for the service property called "UPnP.presentationURL".
-This property is also visible, as link, through the interface provided by the Tester bundle.
-Accessing the presentation page by means of a web browser you can switch the light status by clicking on the Light image: the icon on the device windows changes accordingly.
-| !FelixLight.jpg!
-| !FelixLightBroken.jpg!
-| !LightPresentationPage.jpg!
-| _Figure 9_ The BinaryLight GUI and the presentation page
-
-The source code for the Binary light is slightly different from the one for TV and Clock code because it has been written starting from a Light model which notifies its changes through the PropertyChangeListener interface.
-
-=== xref:documentation/subprojects/apache-felix-upnp/upnp-testing-devices.adoc[Testing UPnP Devices] [Writing UPnP Devices and Control Points| UPnP Writing CD and CP]
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-upnp/upnp-testing-devices/upnp-examples/upnp-writing-cd-and-cp.adoc b/modules/ROOT/pages/documentation/subprojects/apache-felix-upnp/upnp-testing-devices/upnp-examples/upnp-writing-cd-and-cp.adoc
deleted file mode 100644
index 635dddb..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-upnp/upnp-testing-devices/upnp-examples/upnp-writing-cd-and-cp.adoc
+++ /dev/null
@@ -1,117 +0,0 @@
-= Writing UPnP Devices and Control Points
-
-[cols=2*]
-|===
-| The http://www.osgi.org/Specifications/HomePage[OSGi UPnP Specification (v 1.1)] dedicates section 111.6 "Working with a UPnP Device" to describe the details of implementing UPnP Devices on OSGi.
-Here we provide some hints on the main differences you may encounter working with OSGi with respect to the [UDA 1.0 Specification
-| http://www.upnp.org/resources/documents/CleanUPnPDA101-20031202s.pdf] .
-|===
-
-The first peculiarity is that OSGi provides a centralized register for discovering of UPnP devices as opposed to the distributed mechanism of the UPnP protocol stack.
-Thus, while in the UPnP networks the steps for subscribing the services of some device are typically 1) _discover_ the required device and 2) _subscribe_ the service, within the OSGi platform a Control Point may register an interest in receiving notify events even before the device is really plugged on the network.
-This is possible because the subscription mechanism is based on the http://www.osgi.org/javadoc/r4/org/osgi/service/upnp/UPnPEventListener.html[UPnPEventListener]interface that is used for registering OSGi services, which ultimately handles the notify messages sent by the producers of the events.
-The base driver (importer) keeps track of such UPnPEventListener services and as soon as a matching service is discovered on the UPnP network, a subscription is made on behalf of the registered listeners.
-
-[cols=3*]
-|===
-| On the other hand, even if it is enough to register a service implementing the http://www.osgi.org/javadoc/r4/org/osgi/service/upnp/UPnPDevice.html[UPnPDevice]interface to expose it as UPnP devices on the network, the developers have to implement on their own the event management required by the UPnP technology.
-From this point of view, for each evented state variable declared by the UPnP device, the developers have to monitor UPnPEventListenerservices that is error prone[1].
-The correct implementation of the UPnP eventing phase is left entirely to developers.
-In particular, in UDA 1.0, the first time a Control Point subscribes a service, the current value of its state variables should soon be delivered to it.
-To manage this situation in a standard way, the last OSGi UPnP specification defined the extended interface [UPnPLocalStateVariable
-| http://www.osgi.org/javadoc/r4/org/osgi/service/upnp/UPnPLocalStateVariable.html].
-In fact, the previous basic interface UPnPStateVariable provided only a descriptive interface which did not enable to get the value of a state variable without knowing the final implementation class.
-Every developer should use this new interface in order to allow the specification of helper classes that ease the subscription/notify management (see [UPnPEventNotifier
-| http://svn.apache.org/viewvc/felix/trunk/upnp/extra/src/main/java/org/apache/felix/upnp/extra/util/UPnPSubscriber.java?view=markup] below).
-|===
-
-We have factorized and released part of the code used by the UPnP examples with the _org.apache.felix.upnp.extra_ bundle.
-
-== The Extra bundle and the driver interfaces
-
-We provide some utility classes and services through the extra bundle and the services registered by the UPnP Base Driver.
-
-[cols=4*]
-|===
-| In the Extra bundle the class http://svn.apache.org/viewvc/felix/trunk/upnp/extra/src/main/java/org/apache/felix/upnp/extra/util/UPnPSubscriber.java?view=markup[org.apache.felix.upnp.extra.util.UPnPSubscriber] can be instantiated to subscribe one or more services.
-The constructor takes two parameters a [BundleContext
-| http://www.osgi.org/javadoc/r4/org/osgi/framework/BundleContext.html] reference and a [UPnPEventListener
-| http://www.osgi.org/javadoc/r4/org/osgi/service/upnp/UPnPEventListener.html] reference.
-In this class the method subscribe(Filter aFilter) is a general and powerful way to subscribe to any service by using an [LDAP filter
-| http://www.osgi.org/javadoc/r4/org/osgi/framework/Filter.html].
-For example by using the string :
-|===
-
- "(& (UPnP.device.type=urn:schemas-upnp-org:device:BinaryLight:1) (UPnP.service.type= urn:schemas-upnp-org:service:SwitchPower:1))"
-
-we would subscribe to the SwitchPower service offered by any device implementing the BinaryLight profile.
-Looking at the Felix UPnP TV sample code, the UPnPSubscriber class is used in the file http://svn.apache.org/viewvc/felix/trunk/upnp/samples/tv/src/main/java/org/apache/felix/upnp/sample/tv/TvDevice.java?view=markup[org.apache.felix.upnp.sample.tv.TVDevice] to subscribe to the different service types offered by the Cyberlink sample devices.
-However, in this case, the utility method {color:black}{_}subscribeEveryServiceType{_}\{color} is used to provide just the device and service types.
-
-----
-private final static String CLOCK_DEVICE_TYPE = "urn:schemas-upnp-org:device:clock:1";
-private final static String TIME_SERVICE_TYPE = "urn:schemas-upnp-org:service:timer:1";
-
-private final static String LIGHT_DEVICE_TYPE = "urn:schemas-upnp-org:device:light:1";
-private final static String POWER_SERVICE_TYPE = "urn:schemas-upnp-org:service:power:1";
-
-private final static String AIRCON_DEVICE_TYPE = "urn:schemas-upnp-org:device:aircon:1";
-private final static String TEMP_SERVICE_TYPE = "urn:schemas-upnp-org:service:temp:1";
-
-private final static String WASHER_DEVICE_TYPE = "urn:schemas-upnp-org:device:washer:1";
-private final static String STATUS_SERVICE_TYPE = "urn:schemas-upnp-org:service:state:1";
-
-public void doSubscribe() {
- subscriber = new UPnPSubscriber(Activator.context, this);
- subscriber.subscribeEveryServiceType(CLOCK_DEVICE_TYPE, TIME_SERVICE_TYPE);
- subscriber.subscribeEveryServiceType(AIRCON_DEVICE_TYPE, TEMP_SERVICE_TYPE);
- subscriber.subscribeEveryServiceType(LIGHT_DEVICE_TYPE, POWER_SERVICE_TYPE);
- subscriber.subscribeEveryServiceType(WASHER_DEVICE_TYPE, STATUS_SERVICE_TYPE);
-}
-
-public void undoSubscribe(){
- subscriber.unsubscribeAll();}
-----
-
-[cols=8*]
-|===
-| The class http://svn.apache.org/viewvc/felix/trunk/upnp/extra/src/main/java/org/apache/felix/upnp/extra/util/UPnPEventNotifier.java?view=markup[org.apache.felix.upnp.extra.util.UPnPEventNotifier] is a utility class that manages the delivery of notifications for you.
-There are two constructors.
-The first one takes a [BundleContext
-| http://www.osgi.org/javadoc/r4/org/osgi/framework/BundleContext.html], a [UPnPDevice
-| http://www.osgi.org/javadoc/r4/org/osgi/service/upnp/UPnPDevice.html] , and a [UPnPService
-| http://www.osgi.org/javadoc/r4/org/osgi/service/upnp/UPnPService.html] reference.
-They are internally used to keep trace of all the registered UPnPEvenListener that are interested in monitoring events generated by your UPnP service.
-UPnPEventNotifier implements the java beans [PropertyChangeListener
-| http://java.sun.com/j2se/1.4.2/docs/api/java/beans/PropertyChangeListener.html] interface;
-once changes of the service state variables occurs you should call the method propertyChange(PropertyChangeEvent evt).
-Alternatively, you may use the second constructor to pass a reference to a model implementing the interface: [EventSource
-| http://svn.apache.org/viewvc/felix/trunk/upnp/extra/src/main/java/org/apache/felix/upnp/extra/util/EventSource.java?view=markup] defined in the Extra bundle.
-This model should use the [PropertyChangeSupport
-| http://java.sun.com/j2se/1.4.2/docs/api/java/beans/PropertyChangeSupport.html] to keep trace of PropertyChangeListener, {color:}and the related method firePropertyChange\{color} to notify changes.
-The {color:black}EventSource\{color} interface is used internally by the UPnPEventNotifier to register itself as propertychangeListener of the model.
-Thus, in this case, you don't have to call propertyChange()directly: it is a duty of your model.
-As an example, take a look at [LightModel
-| http://svn.apache.org/viewvc/felix/trunk/upnp/samples/binarylight/src/main/java/org/apache/felix/upnp/sample/binaryLight/LightModel.java?view=markup] class in the BinaryLight bundle{color:black}.\{color}
-|===
-
-The Felix UPnP base driver registers a non standard service implementing two interfaces:
-
-http://svn.apache.org/viewvc/felix/trunk/upnp/basedriver/src/main/java/org/apache/felix/upnp/basedriver/controller/DevicesInfo.java?view=markup[org.apache.felix.upnp.basedriver.controller.DevicesInfo];
-http://svn.apache.org/viewvc/felix/trunk/upnp/basedriver/src/main/java/org/apache/felix/upnp/basedriver/controller/DriverController.java?view=markup[org.apache.felix.upnp.basedriver.controller.DriverController];
-
-The former can be used to retrieve the XML description of both devices and services.
-Other than be used for debugging purpose, it allows access to the UPnP schema extensions defined by UPnP Vendors.
-According to the UDA 1.0 they consist of elements inserted in different points of the XML description and by convention starting with the prefix "X_".
-This interface is used by the context menu handler of the UPnP Tester bundle.
-
-The latter interface can be used to change the log messages of the base driver at runtime.
-Two different methods are available to modify the log level of the base driver or to enable the visualization of low level messages related to the UPnP stack protocol (CyberDomo).
-Furthermore, the interface allows developers to send an M-SEARCH discovery message to the UPnP networks, thus refreshing the list of imported devices.
-
-* xref:documentation/subprojects/apache-felix-upnp/upnp-testing-devices/upnp-examples.adoc[The Felix UPnP Examples]
-* xref:documentation/subprojects/apache-felix-upnp/upnp-known-issues.adoc[Known Issues| UPnP Known Issues]
-
-'''
-
-[1]({{ refs.1.path }}) Developers should monitor UPnpEventListener services with a filter matching either the own service Id or service type, either the own device Id or device type and even a empty filter which are usually used to express interest for every UPnP device.
[felix-antora-site] 17/18: remove user admin doc (unmaintained)
Posted by dj...@apache.org.
This is an automated email from the ASF dual-hosted git repository.
djencks pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/felix-antora-site.git
commit 9913ed4a67c7051beb06093525dbf68f0c79a9e7
Author: David Jencks <dj...@apache.org>
AuthorDate: Sun Jul 11 15:53:47 2021 -0700
remove user admin doc (unmaintained)
---
modules/ROOT/pages/documentation/subprojects.adoc | 2 +-
.../subprojects/apache-felix-user-admin.adoc | 11 --------
.../apache-felix-user-admin-background.adoc | 25 ------------------
.../apache-felix-user-admin-file-store.adoc | 25 ------------------
.../apache-felix-user-admin-getting-started.adoc | 30 ----------------------
.../apache-felix-user-admin-introduction.adoc | 4 ---
.../apache-felix-user-admin-mongodb-store.adoc | 25 ------------------
7 files changed, 1 insertion(+), 121 deletions(-)
diff --git a/modules/ROOT/pages/documentation/subprojects.adoc b/modules/ROOT/pages/documentation/subprojects.adoc
index 2584fbe..1cb0389 100644
--- a/modules/ROOT/pages/documentation/subprojects.adoc
+++ b/modules/ROOT/pages/documentation/subprojects.adoc
@@ -129,4 +129,4 @@ The last documentation may be found in the https://github.com/apache/felix-site-
* https://github.com/apache/felix-site-pub/blob/last-cms/documentation/subprojects/apache-felix-script-console-plugin.html[Script Console Plugin]
* https://github.com/apache/felix-site-pub/blob/last-cms/documentation/subprojects/apache-felix-serialization-framework.html[Serialization Framework]
* https://github.com/apache/felix-site-pub/blob/last-cms/documentation/subprojects/apache-felix-upnp.html[UPnP]
-* xref:documentation/subprojects/apache-felix-user-admin.adoc[User Admin]
+* https://github.com/apache/felix-site-pub/blob/last-cms/documentation/subprojects/apache-felix-user-admin.html[User Admin]
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-user-admin.adoc b/modules/ROOT/pages/documentation/subprojects/apache-felix-user-admin.adoc
deleted file mode 100644
index 6671254..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-user-admin.adoc
+++ /dev/null
@@ -1,11 +0,0 @@
-= Apache Felix User Admin
-
-{include:Apache Felix User Admin - Introduction}
-
-== Table of contents
-
-* xref:documentation/subprojects/apache-felix-user-admin/apache-felix-user-admin-background.adoc[Background] explains the problem being solved and the main design goals;
-* xref:documentation/subprojects/apache-felix-user-admin/apache-felix-user-admin-getting-started.adoc[Getting Started] helps you with the basic concepts by example;
-* xref:documentation/subprojects/apache-felix-user-admin/apache-felix-user-admin-file-store.adoc[Using the file store] helps you with using the file-based repository store;
-* xref:documentation/subprojects/apache-felix-user-admin/apache-felix-user-admin-mongodb-store.adoc[Using the MongoDB store] helps you with using the MongoDB-based repository store;
-* xref:documentation/subprojects/apache-felix-user-admin/apache-felix-user-admin-custom-repository-store.adoc(broken link)Writing custom repository stores helps you in writing your own repository store.
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-user-admin/apache-felix-user-admin-background.adoc b/modules/ROOT/pages/documentation/subprojects/apache-felix-user-admin/apache-felix-user-admin-background.adoc
deleted file mode 100644
index 3492258..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-user-admin/apache-felix-user-admin-background.adoc
+++ /dev/null
@@ -1,25 +0,0 @@
-= Apache Felix User Admin - Background
-
-For a detailed overview on the UserAdmin service, see the OSGi compendium specification version 4.0 or later.
-
-== Roles
-
-The UserAdmin service defines two types of roles: _users_ and _groups_.
-Other types of roles are not and cannot be defined.
-
-=== Users
-
-According to the UserAdmin specification, a `User` role refers to "??any entity that may have any number of credentials associated with it that it may use to authenticate itself??." Normally, `User` roles are used to authenticate an initiator of a certain action.
-Although the name suggests otherwise, a `User` role can also denote anything other than a human being.
-Examples of valid `User` roles are:
-
-* A human being with a username and password;
-* A machine with a hostname and SSL-certificate.
-
-=== Groups
-
-A group is an aggregation of other users and groups, allowing you to create authorization schemes.
-Roles are either _required_ or _basic_ members of a group.
-The basic members of a group define the set of members that can be authorized.
-This set is further reduced by requiring an initiator of an action to imply all required member of a group.
-A group can be implied only if it has at least one basic member and at least one required member.
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-user-admin/apache-felix-user-admin-file-store.adoc b/modules/ROOT/pages/documentation/subprojects/apache-felix-user-admin/apache-felix-user-admin-file-store.adoc
deleted file mode 100644
index b1c97b3..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-user-admin/apache-felix-user-admin-file-store.adoc
+++ /dev/null
@@ -1,25 +0,0 @@
-= Apache Felix User Admin - File Store
-
-The Apache Felix User Admin file store provides a file-based store for use with the Felix UserAdmin service.
-It uses a binary file-format to persist the role information.
-This file will always be written in the data area of the bundle and be called "[.code]``ua_repo.dat``".
-
-The file-based store service this bundle provides can be configured at runtime by using the service PID "[.code]``org.apache.felix.useradmin.filestore``".
-The configuration options recognized by this service are:
-
-* "[.code]``background.write.disabled``";
-by default, all changes made to the UserAdmin repository are flushed to disk.
-By setting this value to "[.code]``true``", this no longer will happen for each change, but only when the file-store service is stopped.
-This value is optional and defaults to "[.code]``false``";
-* "[.code]``background.write.delay.value``";
-denotes the period after which the changes should be persisted to disk.
-If other changes to the repository occur during this period, the period will start over.
-This value is optional and defaults to "[.code]``500``";
-* "[.code]``background.write.delay.timeunit``";
-denotes the time unit for "background.write.delay.value".
-This value is optional and defaults to "[.code]``milliseconds``".
-Possible values are: "[.code]``days``", "[.code]``hours``", "[.code]``minutes``", "[.code]``seconds``", "[.code]``milliseconds``", "[.code]``microseconds``" and "[.code]``nanoseconds``".
-
-Alternatively, one can also supply the above mentioned configuration keys prefixed with "[.code]``org.apache.felix.useradmin.filestore.``" as system properties.
-For example by adding `-Dorg.apache.felix.useradmin.filestore.background.write.disabled=true` to your JVM arguments will disable persisting the changes upon each change.
-However, using system properties will imply that only a single store can be configured on a system (which could be a sensible default for some situations)!
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-user-admin/apache-felix-user-admin-getting-started.adoc b/modules/ROOT/pages/documentation/subprojects/apache-felix-user-admin/apache-felix-user-admin-getting-started.adoc
deleted file mode 100644
index c710512..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-user-admin/apache-felix-user-admin-getting-started.adoc
+++ /dev/null
@@ -1,30 +0,0 @@
-= Apache Felix User Admin - Getting Started
-
-== Authentication
-
-To test whether an initiator of an action is known to the UserAdmin service, it should be authenticated.
-To authenticate a user, you typically do something like:
-
-{code:java} private UserAdmin m_userAdmin;
-// ...
-User user = m_userAdmin.getUser("username", getUserName());
-if (user == null || !user.hasCredential("password", getPassword())) { throw new InvalidUsernameOrPasswordException();
-}
-
-----
-h2. Authorization
-
-Only authorized users should be able to initiate privileged actions. Whether a user is authorized to do so depends on its membership in groups. The UserAdmin service aids in this by providing an {{Authorization}} facade that helps you to determine whether or not users are authorized to initiate certain actions.
-
-Note that the UserAdmin only provides answer to the question whether a user is allowed to initiate a certain action, it does not actually shield it from doing this, like, for example, the SecurityManager in Java. This means that the common pattern used to authorize users with UserAdmin looks something like:
-
-{code:java}
-private UserAdmin m_userAdmin;
-// ...
-User user = m_userAdmin.getUser("username", getUserName());
-// assume user is already authenticated...
-Authorization auth = m_userAdmin.getAuthorization(user);
-if (!auth.hasRole("admin")) {
- throw new InsufficientRightsException();
-}
-----
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-user-admin/apache-felix-user-admin-introduction.adoc b/modules/ROOT/pages/documentation/subprojects/apache-felix-user-admin/apache-felix-user-admin-introduction.adoc
deleted file mode 100644
index 4518493..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-user-admin/apache-felix-user-admin-introduction.adoc
+++ /dev/null
@@ -1,4 +0,0 @@
-= Apache Felix User Admin - Introduction
-
-The Apache Felix User Admin provides an implementation of the OSGi UserAdmin compendium service.
-It allows you to manage roles (users and groups), define RBAC-like authorization schemes and test whether certain roles are authorized to initiate certain actions.
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-user-admin/apache-felix-user-admin-mongodb-store.adoc b/modules/ROOT/pages/documentation/subprojects/apache-felix-user-admin/apache-felix-user-admin-mongodb-store.adoc
deleted file mode 100644
index 52b5de7..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-user-admin/apache-felix-user-admin-mongodb-store.adoc
+++ /dev/null
@@ -1,25 +0,0 @@
-= Apache Felix User Admin - MongoDB Store
-
-The Apache Felix User Admin MongoDB store provides a MongoDB-based store for use with the Felix UserAdmin service.
-It uses MongoDB to persist the role information.
-
-Note that this driver additionally needs the http://www.mongodb.org/display/DOCS/Java+Language+Center[MongoDB java driver] in order to operate!
-
-The MongoDB-based store service this bundle provides can be configured at runtime by using the service PID "[.code]``org.apache.felix.useradmin.mongodb``".
-The configuration options recognized by this service are:
-
-* "[.code]``server``": a space separated string containing the MongoDB servers.
-The format for this string is: "[.code]``<host1:port1> <host2:port2>``".
-This value is optional and defaults to "[.code]``localhost:27017``";
-* "[.code]``dbname``": a string value containing the name of the database to use for this store.
-This value is optional and defaults to "[.code]``ua_repo``";
-* "[.code]``collection``": the name of the database collection to use for this store.
-This value is optional and defaults to "[.code]``useradmin``";
-* "[.code]``username``": a string value representing the name of the user to authenticate against MongoDB.
-This value is optional and defaults to "" (empty string);
-* "[.code]``password``": a string value representing the password to authenticate against MongoDB.
-This value is optional and defaults to "" (empty string).
-
-Alternatively, one can also supply the above mentioned configuration keys prefixed with "[.code]``org.apache.felix.useradmin.mongodb.``" as system properties.
-For example by adding `-Dorg.apache.felix.useradmin.mongodb.server=my.mongo.server:29000` to your JVM arguments will let this service use the MongoDB server at "[.code]``my.mongo.server``" on port 29000.
-However, using system properties will imply that only a single store can be configured on a system (which could be a sensible default for some situations)!
[felix-antora-site] 18/18: shorten urls to felix-site-pub
Posted by dj...@apache.org.
This is an automated email from the ASF dual-hosted git repository.
djencks pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/felix-antora-site.git
commit f7b386c6e077778cae42b169a0c251b47725629c
Author: David Jencks <dj...@apache.org>
AuthorDate: Sun Jul 11 15:57:51 2021 -0700
shorten urls to felix-site-pub
---
modules/ROOT/pages/documentation/subprojects.adoc | 38 ++++++++++++-----------
1 file changed, 20 insertions(+), 18 deletions(-)
diff --git a/modules/ROOT/pages/documentation/subprojects.adoc b/modules/ROOT/pages/documentation/subprojects.adoc
index 1cb0389..f4396b1 100644
--- a/modules/ROOT/pages/documentation/subprojects.adoc
+++ b/modules/ROOT/pages/documentation/subprojects.adoc
@@ -1,4 +1,6 @@
= Apache Felix Subproject Documentation
+:site-pub: https://github.com/apache/felix-site-pub
+:last-cms-subprojects: {site-pub}/blob/last-cms/documentation/subprojects
== Building Apache Felix
@@ -112,21 +114,21 @@ If this project is not using Maven, refer to the docs for the subproject on how
== Retired projects
The following projects are no longer maintained and are not documented in this site.
-The last documentation may be found in the https://github.com/apache/felix-site-pub/tree/last-cms repository.
-
-* https://github.com/apache/felix-site-pub/blob/last-cms/documentation/subprojects/apache-felix-autoconf.html[Auto Configuration]
-* https://github.com/apache/felix-site-pub/blob/last-cms/documentation/subprojects/apache-felix-commons.html[Commons]
-* https://github.com/apache/felix-site-pub/blob/last-cms/documentation/subprojects/apache-felix-deployment-admin.html[Deployment Admin]
-* https://github.com/apache/felix-site-pub/blob/last-cms/documentation/subprojects/apache-felix-ipojo.html[iPOJO]
-* https://github.com/apache/felix-site-pub/blob/last-cms/documentation/subprojects/apache-felix-jaas.html[JAAS Support]
-* https://github.com/apache/felix-site-pub/blob/last-cms/documentation/subprojects/apache-felix-lightweight-http-service.html[Lightweight HTTP Service]
-* https://github.com/apache/felix-site-pub/blob/last-cms/documentation/subprojects/apache-felix-manifest-generator-mangen.html[Manifest Generator (mangen)]
-* https://github.com/apache/felix-site-pub/blob/last-cms/documentation/subprojects/apache-felix-maven-obr-plugin.html[Maven OBR Plugin]
-* https://github.com/apache/felix-site-pub/blob/last-cms/documentation/subprojects/apache-felix-maven-osgi-plugin.html[Maven OSGi Plugin]
-* https://github.com/apache/felix-site-pub/blob/last-cms/documentation/subprojects/apache-felix-maven-scr-plugin.html[Maven SCR Plugin]
-* https://github.com/apache/felix-site-pub/blob/last-cms/documentation/subprojects/mosgi-managed-osgi-framework.html[MOSGi Managed OSGi framework]
-* https://github.com/apache/felix-site-pub/blob/last-cms/documentation/subprojects/apache-felix-osgi-core.html[OSGi Core]
-* https://github.com/apache/felix-site-pub/blob/last-cms/documentation/subprojects/apache-felix-script-console-plugin.html[Script Console Plugin]
-* https://github.com/apache/felix-site-pub/blob/last-cms/documentation/subprojects/apache-felix-serialization-framework.html[Serialization Framework]
-* https://github.com/apache/felix-site-pub/blob/last-cms/documentation/subprojects/apache-felix-upnp.html[UPnP]
-* https://github.com/apache/felix-site-pub/blob/last-cms/documentation/subprojects/apache-felix-user-admin.html[User Admin]
+The last documentation may be found in the {site-pub}/tree/last-cms repository.
+
+* {last-cms-subprojects}/apache-felix-autoconf.html[Auto Configuration]
+* {last-cms-subprojects}/apache-felix-commons.html[Commons]
+* {last-cms-subprojects}/apache-felix-deployment-admin.html[Deployment Admin]
+* {last-cms-subprojects}/apache-felix-ipojo.html[iPOJO]
+* {last-cms-subprojects}/apache-felix-jaas.html[JAAS Support]
+* {last-cms-subprojects}/apache-felix-lightweight-http-service.html[Lightweight HTTP Service]
+* {last-cms-subprojects}/apache-felix-manifest-generator-mangen.html[Manifest Generator (mangen)]
+* {last-cms-subprojects}/apache-felix-maven-obr-plugin.html[Maven OBR Plugin]
+* {last-cms-subprojects}/apache-felix-maven-osgi-plugin.html[Maven OSGi Plugin]
+* {last-cms-subprojects}/apache-felix-maven-scr-plugin.html[Maven SCR Plugin]
+* {last-cms-subprojects}/mosgi-managed-osgi-framework.html[MOSGi Managed OSGi framework]
+* {last-cms-subprojects}/apache-felix-osgi-core.html[OSGi Core]
+* {last-cms-subprojects}/apache-felix-script-console-plugin.html[Script Console Plugin]
+* {last-cms-subprojects}/apache-felix-serialization-framework.html[Serialization Framework]
+* {last-cms-subprojects}/apache-felix-upnp.html[UPnP]
+* {last-cms-subprojects}/apache-felix-user-admin.html[User Admin]
[felix-antora-site] 01/18: remove .mdtext files
Posted by dj...@apache.org.
This is an automated email from the ASF dual-hosted git repository.
djencks pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/felix-antora-site.git
commit 6ed7c13905b80395b30140f75b42dc5e63102181
Author: David Jencks <dj...@apache.org>
AuthorDate: Sun Jul 11 15:17:55 2021 -0700
remove .mdtext files
---
modules/ROOT/pages/documentation.mdtext | 18 -
modules/ROOT/pages/documentation/community.mdtext | 4 -
.../documentation/community/contributing.mdtext | 43 -
.../documentation/community/project-info.mdtext | 48 -
.../community/projects-using-felix.mdtext | 13 -
.../ROOT/pages/documentation/development.mdtext | 7 -
.../development/coding-standards.mdtext | 481 ------
.../development/dependencies-file-template.mdtext | 43 -
.../development/provisional-osgi-api-policy.mdtext | 27 -
.../development/release-management-nexus.mdtext | 345 -----
.../documentation/development/site-how-to.mdtext | 201 ---
.../using-the-osgi-compliance-tests.mdtext | 213 ---
modules/ROOT/pages/documentation/faqs.mdtext | 6 -
.../faqs/apache-felix-bundle-plugin-faq.mdtext | 179 ---
.../faqs/apache-felix-scr-plugin-faq.mdtext | 71 -
.../pages/documentation/getting-started.mdtext | 11 -
.../ROOT/pages/documentation/subprojects.mdtext | 61 -
.../subprojects/apache-felix-autoconf.mdtext | 4 -
.../subprojects/apache-felix-commons.mdtext | 68 -
.../creating-bundles-using-bnd.mdtext | 84 -
.../apache-felix-dependency-manager.mdtext | 62 -
.../guides/annotations.mdtext | 347 -----
.../guides/background.mdtext | 28 -
.../guides/bundles-and-dependencies.mdtext | 23 -
.../guides/design-patterns.mdtext | 161 --
.../guides/development.mdtext | 48 -
.../guides/dm-lambda.mdtext | 943 ------------
.../guides/history.mdtext | 15 -
.../guides/javadocs.mdtext | 4 -
.../guides/migrating-from-earlier-versions.mdtext | 69 -
.../guides/migrating-from-other-solutions.mdtext | 2 -
.../guides/performance-tuning.mdtext | 37 -
.../guides/resources.mdtext | 97 --
.../guides/whatsnew-r15.mdtext | 199 ---
.../guides/whatsnew.mdtext | 68 -
.../reference/component-adapter.mdtext | 44 -
.../reference/component-aspect.mdtext | 35 -
.../reference/component-bundle-adapter.mdtext | 35 -
.../component-factory-configuration-adapter.mdtext | 44 -
.../reference/component-resource-adapter.mdtext | 114 --
.../reference/component-singleton.mdtext | 63 -
.../reference/components.mdtext | 227 ---
.../reference/dependencies.mdtext | 32 -
.../reference/dependency-bundle.mdtext | 34 -
.../reference/dependency-configuration.mdtext | 105 --
.../reference/dependency-resource.mdtext | 93 --
.../reference/dependency-service.mdtext | 35 -
.../reference/dm-annotations.mdtext | 1611 --------------------
.../reference/external-links.mdtext | 7 -
.../reference/service-scopes.mdtext | 221 ---
.../reference/thread-model.mdtext | 113 --
.../tutorials/getting-started.mdtext | 195 ---
.../tutorials/leveraging-the-shell.mdtext | 97 --
.../tutorials/sample-code.mdtext | 63 -
.../tutorials/working-with-annotations.mdtext | 214 ---
.../apache-felix-deployment-admin.mdtext | 4 -
.../subprojects/apache-felix-event-admin.mdtext | 225 ---
.../subprojects/apache-felix-file-install.mdtext | 104 --
.../apache-felix-framework-security.mdtext | 50 -
.../subprojects/apache-felix-framework.mdtext | 8 -
.../apache-felix-framework-bundle-cache.mdtext | 66 -
...felix-framework-configuration-properties.mdtext | 82 -
.../apache-felix-framework-faq.mdtext | 60 -
...-felix-framework-launching-and-embedding.mdtext | 784 ----------
...ache-felix-framework-usage-documentation.mdtext | 179 ---
.../subprojects/apache-felix-gogo.mdtext | 195 ---
.../apache-felix-gogo/rfc-147-overview.mdtext | 158 --
.../subprojects/apache-felix-healthchecks.mdtext | 19 -
.../subprojects/apache-felix-inventory.mdtext | 133 --
.../subprojects/apache-felix-ipojo.mdtext | 83 -
.../dive-into-the-ipojo-manipulation-depths.mdtext | 209 ---
.../how-to-use-ipojo-manipulation-metadata.mdtext | 79 -
.../how-to-write-your-own-handler.mdtext | 821 ----------
.../apache-felix-ipojo-eclipse-integration.mdtext | 60 -
.../apache-felix-ipojo-feature-overview.mdtext | 54 -
.../apache-felix-ipojo-dosgi.mdtext | 132 --
.../how-to-use-ipojo-annotations.mdtext | 375 -----
.../ipojo-advanced-tutorial.mdtext | 518 -------
.../ipojo-composition-tutorial.mdtext | 504 ------
.../ipojo-hello-word-maven-based-tutorial.mdtext | 428 ------
.../ipojo-in-10-minutes.mdtext | 514 -------
.../apache-felix-ipojo-junit4osgi.mdtext | 26 -
...ache-felix-ipojo-junit4osgi-architecture.mdtext | 39 -
.../apache-felix-ipojo-junit4osgi-maven.mdtext | 211 ---
.../apache-felix-ipojo-junit4osgi-methods.mdtext | 74 -
.../apache-felix-ipojo-junit4osgi-tutorial.mdtext | 311 ----
.../apache-felix-ipojo-keypoints.mdtext | 46 -
.../apache-felix-ipojo-successstories.mdtext | 54 -
.../apache-felix-ipojo-supportedosgi.mdtext | 80 -
.../apache-felix-ipojo-supportedvms.mdtext | 106 --
.../apache-felix-ipojo-testing-components.mdtext | 87 --
.../apache-felix-ipojo-online-manipulator.mdtext | 51 -
.../apache-felix-ipojo-tools/ipojo-ant-task.mdtext | 124 --
.../ipojo-arch-command.mdtext | 169 --
.../ipojo-karaf-feature.mdtext | 31 -
.../ipojo-maven-plug-in.mdtext | 245 ---
.../ipojo-webconsole-plugin.mdtext | 70 -
.../apache-felix-ipojo-tools/junit4osgi.mdtext | 191 ---
.../apache-felix-ipojo-api.mdtext | 321 ----
.../apache-felix-ipojo-instances.mdtext | 391 -----
.../describing-components.mdtext | 34 -
.../architecture-handler.mdtext | 59 -
.../configuration-handler.mdtext | 155 --
.../controller-lifecycle-handler.mdtext | 56 -
.../event-admin-handlers.mdtext | 321 ----
.../extender-pattern-handler.mdtext | 133 --
.../injecting-bundle-context.mdtext | 66 -
.../describing-components/ipojo-jmx-handler.mdtext | 307 ----
.../lifecycle-callback-handler.mdtext | 146 --
.../providing-osgi-services.mdtext | 396 -----
.../service-requirement-handler.mdtext | 734 ---------
.../temporal-service-dependency.mdtext | 142 --
.../white-board-pattern-handler.mdtext | 151 --
.../instance-vs-service-controller.mdtext | 77 -
.../ipojo-advanced-topics.mdtext | 17 -
.../combining-ipojo-and-configuration-admin.mdtext | 298 ----
...ucting-pojo-objects-with-factory-methods.mdtext | 43 -
.../how-to-use-ipojo-factories.mdtext | 239 ---
.../ipojo-extender-configuration.mdtext | 168 --
.../ipojo-factory-service.mdtext | 145 --
.../ipojo-hierarchical-composition-overview.mdtext | 250 ---
.../service-binding-interceptors.mdtext | 200 ---
.../using-ipojo-introspection-api.mdtext | 267 ----
.../ipojo-advanced-topics/using-stereotypes.mdtext | 83 -
.../apache-felix-ipojo-userguide/ipojo-faq.mdtext | 448 ------
.../using-xml-schemas.mdtext | 90 --
.../apache-felix-ipojo-why-choose-ipojo.mdtext | 74 -
.../articles-and-presentations.mdtext | 16 -
.../developing-camel-mediators-with-ipojo.mdtext | 157 --
.../subprojects/apache-felix-ipojo/download.mdtext | 61 -
.../apache-felix-ipojo/ipojo-news.mdtext | 42 -
.../apache-felix-ipojo/ipojo-reference-card.mdtext | 886 -----------
.../apache-felix-ipojo/ipojo-support.mdtext | 24 -
.../apache-felix-ipojo/related-works.mdtext | 18 -
.../subprojects/apache-felix-jaas.mdtext | 306 ----
.../apache-felix-lightweight-http-service.mdtext | 18 -
.../subprojects/apache-felix-log.mdtext | 200 ---
.../subprojects/apache-felix-logback.mdtext | 173 ---
.../apache-felix-manifest-generator-mangen.mdtext | 534 -------
.../apache-felix-maven-bundle-plugin-bnd.mdtext | 921 -----------
.../apache-felix-maven-obr-plugin.mdtext | 196 ---
.../apache-felix-maven-osgi-plugin.mdtext | 287 ----
.../apache-felix-maven-scr-plugin.mdtext | 49 -
.../apache-felix-maven-scr-plugin-use.mdtext | 144 --
.../apache-felix-scr-ant-task-use.mdtext | 162 --
.../apache-felix-scr-bndtools-use.mdtext | 142 --
.../extending-scr-annotations.mdtext | 63 -
.../scr-annotations.mdtext | 367 -----
.../scr-javadoc-tags.mdtext | 162 --
.../apache-felix-metatype-service.mdtext | 124 --
.../apache-felix-osgi-bundle-repository.mdtext | 324 ----
.../subprojects/apache-felix-osgi-core.mdtext | 3 -
.../apache-felix-preferences-service.mdtext | 86 --
.../subprojects/apache-felix-remote-shell.mdtext | 32 -
.../apache-felix-script-console-plugin.mdtext | 157 --
.../apache-felix-serialization-framework.mdtext | 42 -
.../subprojects/apache-felix-shell-tui.mdtext | 9 -
.../subprojects/apache-felix-shell.mdtext | 239 ---
.../subprojects/apache-felix-upnp.mdtext | 21 -
.../apache-felix-upnp/upnp-acknowledgments.mdtext | 5 -
.../upnp-driver-architecture.mdtext | 45 -
.../apache-felix-upnp/upnp-getting-started.mdtext | 52 -
.../apache-felix-upnp/upnp-known-issues.mdtext | 13 -
.../apache-felix-upnp/upnp-testing-devices.mdtext | 38 -
.../upnp-testing-devices/upnp-examples.mdtext | 24 -
.../upnp-examples/upnp-writing-cd-and-cp.mdtext | 60 -
.../subprojects/apache-felix-user-admin.mdtext | 12 -
.../apache-felix-user-admin-background.mdtext | 20 -
.../apache-felix-user-admin-file-store.mdtext | 11 -
.../apache-felix-user-admin-getting-started.mdtext | 31 -
.../apache-felix-user-admin-introduction.mdtext | 3 -
.../apache-felix-user-admin-mongodb-store.mdtext | 16 -
.../subprojects/apache-felix-web-console.mdtext | 180 ---
.../extending-the-apache-felix-web-console.mdtext | 10 -
.../branding-the-web-console.mdtext | 115 --
.../providing-resources.mdtext | 22 -
.../providing-web-console-plugins.mdtext | 62 -
.../web-console-logging.mdtext | 21 -
.../web-console-output-templating.mdtext | 66 -
.../web-console-restful-api.mdtext | 345 -----
.../web-console-security-provider.mdtext | 104 --
.../mosgi-managed-osgi-framework.mdtext | 83 -
.../mosgi-managed-osgi-framework/probeguide.mdtext | 149 --
.../tutorials-examples-and-presentations.mdtext | 35 -
.../apache-felix-application-demonstration.mdtext | 139 --
.../apache-felix-osgi-faq.mdtext | 123 --
.../apache-felix-osgi-tutorial.mdtext | 16 -
.../apache-felix-tutorial-example-1.mdtext | 117 --
.../apache-felix-tutorial-example-2.mdtext | 153 --
.../apache-felix-tutorial-example-2b.mdtext | 129 --
.../apache-felix-tutorial-example-3.mdtext | 149 --
.../apache-felix-tutorial-example-4.mdtext | 242 ---
.../apache-felix-tutorial-example-5.mdtext | 163 --
.../apache-felix-tutorial-example-6.mdtext | 327 ----
.../apache-felix-tutorial-example-7.mdtext | 161 --
.../apache-felix-tutorial-example-8.mdtext | 251 ---
.../apache-felix-tutorial-example-9.mdtext | 115 --
modules/ROOT/pages/errors/403.mdtext | 24 -
modules/ROOT/pages/errors/404.mdtext | 25 -
modules/ROOT/pages/index.mdtext | 20 -
modules/ROOT/pages/license.mdtext | 206 ---
modules/ROOT/pages/media.mdtext | 8 -
modules/ROOT/pages/miscellaneous.mdtext | 2 -
.../ROOT/pages/miscellaneous/apache-karaf.mdtext | 5 -
.../ROOT/pages/miscellaneous/board-reports.mdtext | 6 -
.../apache-felix-board-report-template.mdtext | 17 -
.../board-reports/board-report-2007-04.mdtext | 23 -
.../board-reports/board-report-2007-05.mdtext | 21 -
.../board-reports/board-report-2007-06.mdtext | 25 -
.../board-reports/board-report-2007-09.mdtext | 22 -
.../board-reports/board-report-2007-12.mdtext | 23 -
.../board-reports/board-report-2008-03.mdtext | 18 -
.../board-reports/board-report-2008-06.mdtext | 20 -
.../board-reports/board-report-2008-09.mdtext | 18 -
.../board-reports/board-report-2008-12.mdtext | 20 -
.../board-reports/board-report-2009-03.mdtext | 22 -
.../board-reports/board-report-2009-06.mdtext | 34 -
.../board-reports/board-report-2009-09.mdtext | 25 -
.../board-reports/board-report-2009-12.mdtext | 34 -
.../board-reports/board-report-2010-03.mdtext | 26 -
.../board-reports/board-report-2010-06.mdtext | 39 -
.../board-reports/board-report-2010-09.mdtext | 26 -
.../board-reports/board-report-2010-12.mdtext | 29 -
.../board-reports/board-report-2011-03.mdtext | 30 -
.../board-reports/board-report-2011-06.mdtext | 32 -
.../board-reports/board-report-2011-09.mdtext | 32 -
.../board-reports/board-report-2011-12.mdtext | 32 -
.../board-reports/board-report-2012-03.mdtext | 29 -
.../board-reports/board-report-2012-06.mdtext | 34 -
.../board-reports/board-report-2012-09.mdtext | 31 -
.../board-reports/board-report-2012-12.mdtext | 32 -
.../board-reports/board-report-2013-03.mdtext | 23 -
.../miscellaneous/cat-scan-project-proposal.mdtext | 12 -
.../cat-scan-001-use-cases.mdtext | 3 -
.../cat-scan-002-profiles.mdtext | 10 -
.../cat-scan-002-001-basic-profile.mdtext | 2 -
.../cat-scan-003-run-log-archive.mdtext | 3 -
.../cat-scan-004-api-reference.mdtext | 3 -
...cat-scan-005-technical-compatibility-kit.mdtext | 3 -
.../cat-scan-006-glossary.mdtext | 3 -
.../cat-scan-007-references.mdtext | 3 -
.../incubator-status-report-january-2007.mdtext | 26 -
.../incubator-status-report-october-2006.mdtext | 20 -
.../osgi-bundle-service-diagrams.mdtext | 18 -
modules/ROOT/pages/miscellaneous/sandbox.mdtext | 3 -
.../miscellaneous/sandbox/composite-bundles.mdtext | 242 ---
.../miscellaneous/sandbox/virtual-bundles.mdtext | 220 ---
.../miscellaneous/sandbox/web-console-ng.mdtext | 12 -
.../miscellaneous/subproject-release-status.mdtext | 100 --
.../ROOT/pages/miscellaneous/tlp-task-list.mdtext | 30 -
modules/ROOT/pages/news.mdtext | 455 ------
251 files changed, 32735 deletions(-)
diff --git a/modules/ROOT/pages/documentation.mdtext b/modules/ROOT/pages/documentation.mdtext
deleted file mode 100644
index fbed85d..0000000
--- a/modules/ROOT/pages/documentation.mdtext
+++ /dev/null
@@ -1,18 +0,0 @@
-Title: Documentation
-
-In an effort to make it easier to find desired documentation, we have divided our documentation section into the following six areas:
-
-* [Getting started]({{ refs.getting-started.path }}) - This area captures a few links from the areas below that will help you get started with Felix.
-* [FAQs]({{ refs.faqs.path }}) - This area captures all FAQ documentation, which typically varies from subproject to subproject.
-* [Community]({{ refs.community.path }}) - This area captures documentation associated with how the Felix community works and how to become involved in it.
-* [Development]({{ refs.development.path }}) - This area captures documentation for Felix developers or those interested in becoming Felix developers; this is not intended for Felix users although some information may be useful.
-* [Subprojects]({{ refs.subprojects.path }}) - This area captures user documentation for the various Felix subprojects.
-* [Tutorials, examples, and presentations]({{ refs.tutorials-examples-and-presentations.path }}) - This area captures general user documentation that does not necessarily fit into any single subproject.
-
-In addition a [site map](https://felix.apache.org/sitemap.html) is available as a table of
-contents of the site.
-
-If you are unable to find the documentation you need, please ask on the [mailing lists]({{ refs.mailinglists.path }}). Also, feedback on improving the documentation and/or organization of this site is welcome.
-
-*The Felix web site and documentation are managed with the [Apache CMS](https://www.apache.org/dev/cms.html).
-For Apache Felix specific extensions see the [Site How-To]({{refs.site-how-to.path}}).*
\ No newline at end of file
diff --git a/modules/ROOT/pages/documentation/community.mdtext b/modules/ROOT/pages/documentation/community.mdtext
deleted file mode 100644
index ded7b9f..0000000
--- a/modules/ROOT/pages/documentation/community.mdtext
+++ /dev/null
@@ -1,4 +0,0 @@
-Title: Community Documentation
-
-{% for label, page in children %}* [{{ page.headers.title }}]({{ page.path }})
-{% endfor %}
diff --git a/modules/ROOT/pages/documentation/community/contributing.mdtext b/modules/ROOT/pages/documentation/community/contributing.mdtext
deleted file mode 100644
index 8630a8c..0000000
--- a/modules/ROOT/pages/documentation/community/contributing.mdtext
+++ /dev/null
@@ -1,43 +0,0 @@
-Title: Contributing
-
-Apache Felix is a volunteer effort, so there is always plenty of work that needs to be accomplished. If you want to help support Felix, this page is intended as a starting point for specific contribution ideas. To further understand how the Felix community operates, refer to the [Community Roles and Processes](https://www.apache.org/foundation/how-it-works.html) document and/or join the [mailing lists]({{ refs.project-info.path }}).
-
-The Felix project organizes its "to do" list using the [JIRA](https://issues.apache.org/jira/browse/Felix) issue tracking system. Specific items from Felix' JIRA issue tracking system are highlighted on this page, but are not limited to it. The purpose of the list here is to highlight issues that are either more important or serve as good entry points for new contributors.
-
-It is important to point out that you do not need to be a programmer to contribute to Felix. As such, we will break out the list of issues below for non-programmers and programmers.
-
-## Non-Programmers
-
-* Improve web site or documentation (e.g., create/propose FAQ entries). There is no specific JIRA issue for this task, but any contributions could be posted as new JIRA issues for the Documentation component.
-
-## Programmers
-
-Before contributing, make sure to be subscribed to the [developer mailing list]({{ refs.project-info.path }}). If you don't have your own issue to scratch, you can browse open issues in [JIRA](https://issues.apache.org/jira/browse/Felix) and submit a patch.
-
-Source code contributions fall into two categories: pull requests or grants. This document describes both and how to handle each.
-
-### Pull Requests
-
-A pull request is a small change to existing code, typically in response to a bug fix or improvement. If you have created a change, you should:
-
-1. Create a [JIRA](https://issues.apache.org/jira/browse/Felix) issue (or find a pertinent existing issue) describing the issue needing to be addressed.
-1. Create a pull requests against the git repository containing the code.
-1. The pull request will eventually be reviewed and applied (if accepted) by a Felix committer, but feel free to bug us \[nicely\]({{ refs.nicely.path }}) if you get impatient.
-
-Providing pull requests is a very good way to become a committer at Felix, since we'd rather have you review and apply the patches than us. :-)
-
-### Grants
-
-A grant involves donating a larger chunk of code developed elsewhere. The line dividing a patch and a grant is sort of like the definition of pornography, we know it when we see it. The steps for granting software are a little more complicated since we need to ensure proper IP handling. For grants, you should:
-
-1. Verify that you have the authorization to donate the code.
-1. Review our [developer documentation]({{ refs.development.path }}) as well as the general [Apache documentation|https://www.apache.org/foundation/getinvolved.html] to determine whether you would really like be involved with us and how we work.
-1. Assuming you're still interested, create a [JIRA](https://issues.apache.org/jira/browse/Felix) issue describing the code you wish to donate.
-1. Attach an archive containing the code along with an MD5 signature of the archive to the above issue. You should remove any existing headers from the source files and add the standard Apache header to each. Note that you keep the rights to your code and can do anything with it you want, you will just grant us the right to use it too.
-1. Allow the community time to discuss the contribution, after which a vote will be called to accept the contribution.
-1. If the vote passes, then you will need to submit a [software grant](https://www.apache.org/licenses/software-grant.txt) form.
-1. It is also a good idea to submit an [ICLA](https://www.apache.org/licenses/icla.txt) to ease future contributions. Depending on the company you work for, they may also want to contribute a [CCLA|https://www.apache.org/licenses/cla-corporate.txt], although this isn't strictly necessary from an Apache point of view, since it is your responsibility to verify your ability to submit an ICLA.
-1. Once all of this information is received, then we will gather it and perform [IP clearance](https://incubator.apache.org/ip-clearance/index.html).
-1. After a few days, if no red flags are raised, then we'll commit the code and we're good to go.
-
-Granting code is also a path to committership at Felix, since we look more highly on contributions from developers who wish to stay involved in the continuing evolution and maintenance of the donated code.
diff --git a/modules/ROOT/pages/documentation/community/project-info.mdtext b/modules/ROOT/pages/documentation/community/project-info.mdtext
deleted file mode 100755
index 610e738..0000000
--- a/modules/ROOT/pages/documentation/community/project-info.mdtext
+++ /dev/null
@@ -1,48 +0,0 @@
-Title: Apache Felix Project Info
-
-There are different roles with which Felix community members may be associated, these roles are: users, contributors, committers, and Project Management Committee (PMC) members. These roles are assigned and assumed based on merit. Everyone in the Felix community can participate to whatever level they desire, but participating and the resulting merit gained is directly linked to the role an individual may obtain. To further understand how the Felix community operates, refer to the [Commun [...]
-
-## Committers and Project Management Committee (PMC)
-
-See Apache Phone Book: [Apache Felix Committers and PMC members](https://people.apache.org/phonebook.html?pmc=felix)
-
-### Past members:
-
-* Niclas Hedhman (stepped down 1/26/2009)
-* Trustin Lee (stepped down 2/9/2008)
-* Upayavira (stepped down 9/11/2007)
-
-## Source Code
-
-This project uses [git](https://git-scm.com/) to manage its source code. Instructions on git can be found at [git docs](https://git-scm.com/docs).
-
-### Web Access
-
-The following is a link to the online source repository.
-
-[https://github.com/apache/felix-dev](https://github.com/apache/felix-dev)
-
-### Committer and anonymous access
-
-The Felix source code can be checked out (anonymously) with the following command:
-
- :::sh
- $ git clone https://github.com/apache/felix-dev
-
-## Mailing lists
-
-The following mailing lists have been established for Apache Felix. For each list, there is a subscribe, unsubscribe, and archive link.
-
-|Name|Subscribe|Unsubscribe|Archive|
-|--|--|--|--|
-|*Felix Users* - For people using Felix subprojects and/or developing bundles. |[Subscribe](mailto:users-subscribe@felix.apache.org)|[Unsubscribe](mailto:users-unsubscribe@felix.apache.org)|[www.mail-archive.com](https://www.mail-archive.com/users%40felix.apache.org/)|
-|*Felix Dev* - For people interested in the internal development of Felix subprojects. |[Subscribe](mailto:dev-subscribe@felix.apache.org)|[Unsubscribe](mailto:dev-unsubscribe@felix.apache.org)|[www.mail-archive.com](https://www.mail-archive.com/dev%40felix.apache.org/)|
-|*Felix Commits* - For people intested in Felix subproject code changes. |[Subscribe](mailto:commits-subscribe@felix.apache.org)|[Unsubscribe](mailto:commits-unsubscribe@felix.apache.org)|[www.mail-archive.com](https://www.mail-archive.com/commits%40felix.apache.org/)|
-
-## Issue Tracking
-
-This project uses [JIRA](https://www.atlassian.com/software/jira), a J2EE-based, issue tracking and project management application. We use it for bugs, tasks and code contributions.
-
-Before creating a new issue, please make sure nobody has already added the issue you're reporting. When you do add an issue, please try to make it as informative as possible.
-
-The issue tracker can be found at [https://issues.apache.org/jira/browse/FELIX](https://issues.apache.org/jira/browse/FELIX)
diff --git a/modules/ROOT/pages/documentation/community/projects-using-felix.mdtext b/modules/ROOT/pages/documentation/community/projects-using-felix.mdtext
deleted file mode 100644
index 5a48bb6..0000000
--- a/modules/ROOT/pages/documentation/community/projects-using-felix.mdtext
+++ /dev/null
@@ -1,13 +0,0 @@
-Title: Projects Using Felix
-
-This page highlights projects that use Apache Felix (listed alphabetically):
-
-* [Apache Karaf](https://karaf.apache.org) - A small, OSGi-based runtime that provides a lightweight container into which various components and applications can be deployed (formerly an Apache Felix subproject).
-* [Apache ServiceMix](https://servicemix.apache.org/) - an Enterprise Service Bus (using Felix via Karaf).
-* [Apache Sling](https://sling.apache.org/) - a framework for RESTful web-applications based on an extensible content tree
-* [Apache Tuscany](https://tuscany.apache.org/) - an open source implementation of [SCA|http://www.oasis-opencsa.org/].
-* [Ascert VersaTest](http://www.ascert.com/) - enterprise system testing platform
-* [DySoWeb](http://www.requea.com/dysoweb/rq/en/archi/dysoweb) - A platform for dynamic component deployment.
-* [GlassFish](http://glassfish.dev.java.net) - JavaEE application server.
-* [OW2 JOnAS](http://jonas.ow2.org/) - JavaEE application server.
-* [SIP Communicator](https://sip-communicator.dev.java.net/) - a multi-protocol instant messenger and SIP software phone.
diff --git a/modules/ROOT/pages/documentation/development.mdtext b/modules/ROOT/pages/documentation/development.mdtext
deleted file mode 100644
index 3f535ef..0000000
--- a/modules/ROOT/pages/documentation/development.mdtext
+++ /dev/null
@@ -1,7 +0,0 @@
-Title: Development
-
-This page contains links related to Felix project development.
-
-{% for label, page in children %}* [{{ page.headers.title }}]({{ page.path }})
-{% endfor %}
-
diff --git a/modules/ROOT/pages/documentation/development/coding-standards.mdtext b/modules/ROOT/pages/documentation/development/coding-standards.mdtext
deleted file mode 100644
index 40cf737..0000000
--- a/modules/ROOT/pages/documentation/development/coding-standards.mdtext
+++ /dev/null
@@ -1,481 +0,0 @@
-Title: Coding Standards
-
-## Guidelines Summary
-
-This style guide is intended to help the computer professional produce better Java programs. It presents a set of specific guidelines for using the features of Java in a disciplined manner. The goal is to develop high quality, reliable, reusable, portable software. For a number of reasons, no programming language can ensure the achievements of these desirable objectives on its own. Programming must be embedded in a disciplined development process that addresses a number of topics in a we [...]
-
-Clear, readable, understandable source text eases program evolution, adaptation and maintenance. First, such source text is more likely to be correct and reliable. Second, effective code adaptation is a prerequisite to code reuse, a technique that has the potential for drastic reductions in system development costs. Easy adaptation requires thorough understanding of the software, and that is facilitated considerably by clarity. Finally, since maintenance (really evolution) is a costly pr [...]
-
-This style guide is intended for those involved in the development of real software systems written in Java. Different roles in a software project can exploit the style guide in different ways. The programmer can use it as a reference on good Java style. It can be used in code reviews as a common reference. Finally, lessons learned in real projects can be captured by extending the style guide.
-
-## Class layout and comments
-
-### Files and filenames
-
-Files longer than 2000 lines are cumbersome and should be avoided.
-
-#### File names
-
-The file must be named after the class it represents. As for most cases each file contains only one class, this is an easy naming convention. For nested or inner classes the name of the main class must be the name of the file. As names in Java are case-sensitive, the filename is case-sensitive also.
-
-#### File organization
-
-Each Java source file contains a single class or interface. Of course, this excludes inner classes as these must be defined without an (outer) class, and thus in the same file.
-
-Java source files have the following ordering:
-
-- Beginning comments
-- Package and import statements
-- Class and interface declarations
-
-#### Beginning comments
-
-All source files must begin with the comments shown in the following code sample.
-
-
- /*
- * Licensed to the Apache Software Foundation (ASF) under one
- * or more contributor license agreements. See the NOTICE file
- * distributed with this work for additional information
- * regarding copyright ownership. The ASF licenses this file
- * to you under the Apache License, Version 2.0 (the
- * "License"); you may not use this file except in compliance
- * with the License. You may obtain a copy of the License at
- *
- * http://www.apache.org/licenses/LICENSE-2.0
- *
- * Unless required by applicable law or agreed to in writing,
- * software distributed under the License is distributed on an
- * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
- * KIND, either express or implied. See the License for the
- * specific language governing permissions and limitations
- * under the License.
- */
-
-
-Note that this comment part is not according to the JavaDoc style (See: How to write doc comments for JavaDoc - Sun Microsystems, Inc.) as this is file specific information that is not relevant in generated API documentation.
-
-##### Package and import Statements
-
-The first non-comment line of most Java source files is a package statement. After an empty line import statements can follow. For example:
-
-
- package org.apache.felix.whatever.this.is;
-
- import java.awt.Frame;
- import java.io.InputStream;
- import java.util.Vector;
-
-
-A few notes must be made here:
-1. Package rules.
- When not using an explicit package statement in your code the code still is in a package, the default package. This easily results in name clashes and as package naming should be a part of the design, always use an explicit package name. For naming rules of packages see 3.4 Naming conventions.
-1. Import statements need to be explicit in order to overcome name clashes.
- They should be grouped by name. When the number of import statements of the same package exceeds the 'readability' limit (please use common sense), then import the complete package by adding '.*'.
-1. Import order.
- First in this section should be the standard Java imports like: java.lang.Throwable. Second should be the Java extensions (i.e. javax), third, the third party stuff. Finally the project-specific imports should be added.
-
-##### Class and interface Declarations
-
-The following comment block is an example for the comment that belongs to the declaration of a class or an interface. The combination of JavaDoc syntax and keywords that are expanded by the source integrity tool result in the following block:
-
-
- /**
- * This class is not really a class, because this file is just
- * a template that shows how the file header and class header
- * should look like.
- *
- * @author <a href="mailto:dev@felix.apache.org">Felix Project Team</a>
- */
-
-
-The following table describes the parts of a class or interface declaration, in the order that they should appear.
-
-| Part of Class/Interface Declaration | Notes |
-|--|--|
-|Class/Interface documentation|According to comment block as shown above.|
-|Class or interface statement| |
-|Class (static) variables|These should be grouped by functionality rather than by scope.|
-|Instance variables|These should be grouped by functionality rather than by scope.|
-|Constructors|Start with the default constructor if any.|
-|Methods that belong to the class (see also 2.1.3.4 Class methods versus specific interface methods and event methods)|These methods should also be grouped by functionality rather than by scope or accessibility. E.g. a private class method can be in between two public instance methods. The goal is to make reading and understanding the code easier. When implementing an interface, group the methods that are part of the interface.|
-|Methods of interfaces that are implemented by the class.|Automatically grouped by functionality if grouped by interface.|
-|Inner classes|As they are only visible within their top-level class, they are placed at the bottom of the file.|
-
-### Indentation
-
-Four spaces should be used as unit of indentation. Use spaces or let your editor convert tabs to spaces as some editors might show the tabs different than they were intended! Tabs must be set exactly every 4 spaces.
-
-#### Line length
-
-There is no explicit limit for the length of a line. Make sure that the flow of the code is clear and that, when printing the file, it is well formed when using a reasonable font. A reasonable length would be around 80 characters.
-
-#### Wrapping lines
-
-When an expression will not fit on a single line, break it according to these general principles:
-- break after a comma;
-- break before an operator;
-- prefer higher level breaks to lower level breaks;
-- align the new line with the beginning of the expression after the assignment;
-- if the above rules lead to confusing code or to code that's squished up against the right margin, please use common sense.
-
-Some examples breaking an arithmetic expression. The first is preferred, since the break occurs outside the parenthesised expression:
-
-
- longName1 = longName2 * (longName3 + longName4 - longName5)
- + 4; // preferred
- longName1 = longName2 * (longName3 + longName4
- - longName5) + 4;
-
-
-### Comment
-
-#### Comment styles
-
-The Java language supports three different kinds of comments:
-
-
- // text
-
-
-The compiler ignores everything from // to the end of the line. Use this style when adding a description or some kind of explanation at the same line of code.
-
-
- /* text */
-
-
-The compiler ignores everything from /* to */. The next documentation style is preferred.
-
-
- /** Documentation. */
-
-
-This indicates a documentation comment (doc comment, for short). The compiler ignores this kind of comment, just like it ignores comments that use /* and */. The JDK JavaDoc tool uses doc comments when preparing automatically generated documentation (See: JavaDoc keywords and HTML tags). But JavaDoc only uses this documentation when it occurs at an expected position in the file like the class definition or a member declaration.
-
-#### Block comments
-
-Block comments are used to provide English descriptions of the contents of files, the task of methods and the description of data structures and algorithms. Block comments should be used at the beginning of each file and before each method. They can also be used in other places, such as within methods.
-
-For a description of class comment see 2.1.3.3 Class and Interface Declarations. A method block comment looks as follows:
-
-
- /**
- * Position the splitter location at a specified position.
- * This method can for instance be used when the last position
- * is stored as a preference setting for the user.
- *
- * @param position New position of divider, defined in pixels
- * from the left of the containing window
- * @see com.sun.java.swing.JSplitPane
- * @exception org.apache.felix.player.PositionException
- * Whenever an invalid position is passed.
- */
- public void setSplitterLocation(int position) throws PositionException
-
-
-#### JavaDoc keywords and HTML tags
-
-For class headers, method headers and member variables JavaDoc is used in order to generate API documentation from the source later on (See: JavaDoc homepage - Sun Microsystems, Inc.).
-A few specific JavaDoc keywords are:
-
-|Keyword|Short description|
-|--|--|
-|@version|Can be used to label a specific version of a package or application so the documentation shows this version number also.|
-|@author|The name entered here is shown as the author.|
-|@param|Used to define one parameter and describe this parameter.|
-|@see|When there are similarities with another class this tag is used to offer the reader a hyperlink to the mentioned class.|
-|@exception or @throws|Offered as hyperlink to the exception that can be thrown by a method.|
-|@return|Return value of a method|
-
-Some HTML-tags that can be used in order to make the comment blocks more readable:
-
-|Tag|Short description|
-|--|--|
-|<p>|New paragraph.|
-|<br>|Break, a carriage return. For separation of two paragraphs, usage of <p> is preferred.|
-|<ul><li></li></ul>|Unordered list of items; each item should start with a <li> tag. By most browsers, this is formatted as a bulleted list.|
-|<code></code>|Code samples; use this when refering to class names, method names, parameter names, etc.|
-|<pre></pre>|Preformatted text. Use these tags to protect figures and schemas "drawn" in Ascii, against formatting by the browser (which normally ignores whitespace and line breaks)|
-|<dl><dt></dt><dd></dd></dl>|Definition lists; <dt> specifies the term that is defined and <dd> the definition of this term. Not frequently used.|
-
-Note: there is no need to embed the parameter name in the @param tag in <code> tags; this is done by javadoc automatically. The same holds for the exception name in the @exception or @throws tag. In the clarifying text however, use the <code> tags when refering to parameter names etc. The example below shows the <code> tag being used for the array parameter in the text, but not in its definition.
-
-Example:
-
- /**
- * Prints a range from an object array. The range
- * is specified by the first element to print, and
- * ranges to the last element of the array.
- *
- * @param array contains the objects to print
- * @param first index of first element in
- * the <code>array</code> to print
- */
- public void printRange(Object[] array, int first)
-
-
-## Java syntax and its layout
-
-### Declarations
-
-When declaring a variable or method make the accessibility as restrictive as possible. When using multiple keywords use the following ordering of keywords:
-
-1. accessibility
- Start with the accessibility as it makes clear if the method or variable is reachable at all.
-1. static (if applicable)
-1. final (if applicable)
-1. return type (methods only) or type (for variables)
- The type is for readability as close as possible to the name.
-
-This order is also compatible with the order that is used in Java for the main() method. This results in following sequence:
-
-
- // A familiar one:
- public static void main(String[] args) {}
- private static String m_lastCreated = null;
- private static final int RED = 4711;
-
-
-#### Number per line
-
-One declaration per line is recommended since it encourages commenting and it does not lead to confusing code. It also is more clear about the explicit initialization of variables as discussed in Initialization.
-
-Example:
-
-
- int level = 0; // level where user enters the system
- int horizontalSize = 0; // horizontal size of current level layer
-
-
-is preferred over:
-
-
- int level, horizontalSize; // level and size of current level layer
-
-
-#### Placement
-
-In a method, declare local variables just before they are needed. This overcomes the problem of a big list of parameters at the beginning of a method and the use of a variable becomes more clearly in the context of the code, .e.g. its initialization.
-
-#### Initialization
-
-The initialization of class variables is strictly not necessary because of the default initialization that takes place for these kinds of members. For some types, e.g. Booleans, this requires detailed knowledge of all the default values so it is more clear and explicit to initialize each member.
-Variables that are used and declared within methods must always be initialized explicitly (the compiler will generate an error when you forget this).
-
-#### Class and Interface Declarations
-
-When coding Java classes and interfaces, the following formatting rules should be followed:
-
-- no space between a method and its parameter list
-- "\{" is on a line by itself indented to match its corresponding opening statetment, except when it is a null statement, in which case the "\{" should appear on the same line as the opening statement
-- "}" starts a line by itself indented to match its corresponding opening statement, except when it is a null statement, in which the case the "}" should appear immediately after the "\{".
-
-Example:
-
-
- class ShipmoTrial extends Trial
- {
- int m_index = 0;
-
- ShipmoTrial(int index)
- {
- m_index = index;
- }
-
- void emptyMethod() {}
- }
-
-
-### Statements
-
-#### Simple statements
-
-Each line should contain at most one statement.
-
-Example:
-
-
- // Do not use this
- argv++; argc++;
-
-
-#### Compound statements
-
-Compound statements are statements that contain lists of statements enclosed in braces ("\{...}"):
-
-- The enclosed statements should be indented one more level than the compound statement.
-- The opening brace should be at the end of the line that begins the compound statement; the closing brace should begin a line and be indented to the beginning of the compound statement.
-- Braces are used around all statements, even single statements, when they are part of a control structure, such as a if-else or for statement. This makes it easier to add statements without accidentally introducing bugs due to forgetting to add braces.
-
-#### if, if-else, if else-if else statements
-
-There are a lot of nested possibilities for if-else constructions. All these variations can be programmed in very cryptic ways that easily and often will lead to buggy code. By being more explicit in the used coding style a lot of confusion can be taken away.
-
-Note: When using only one statement in a compound block brackets are optional. It can be a good practice to use always brackets because mistakes can be made easily when adding a second statement and brackets are forgotten.
-
-The following example illustrates the correct use of brackets in a few different if-then-else constructions:
-
-
- if (condition)
- {
- statement1;
- statement2;
- }
- else
- {
- statement3;
- }
-
- if (condition)
- {
- statement1;
- statement2;
- }
- else if (condition1)
- {
- statement3;
- statement4;
- }
- else
- {
- statement5;
- statement6;
- }
-
-
-Note that in the example the else if construction is started at a new line so the statement can not be overlooked.
-
-#### switch
-
-When using a switch statement use following guidelines:
-
-- Every switch statement should include a default case. The break in the default case is redundant, but it prevents a fall-through error if later another case is added.
-- The so-called fall-through construction should be avoided. Only when there are good reasons to use it, make sure that it is very clear that a fall-through is used (comment it).
-
-The next example shows the sample code that uses the guidelines for a switch statement:
-
-
- switch (condition)
- {
- case A:
- statements;
- // falls through here!!
- case B:
- statements;
- break;
- default:
- statements;
- break;
- }
-
-
-#### try - catch
-
-A try - catch statement should have the following format:
-
-
- try
- {
- statements;
- }
- catch (ExceptionClass ex)
- {
- statements;
- }
-
-
-When using finally to add code that always will be executed this will look like:
-
-
- try
- {
- statements;
- }
- catch (ExceptionClass ex)
- {
- statements;
- }
- finally
- {
- statements;
- }
-
-
-Note that the catch and the finally start at a new line in order to be compliant to the guidelines for if-then-else statements.
-
-### White Space
-
-#### Blank lines
-
-Blank lines improve readability by setting of sections of code that are logically related.
-
-Two blank lines should always be used in the following circumstances:
-
-- between class and interface definitions;
-- between a group of methods that belong together (by its functionality or because they are part of the same interface).
-
-One blank line should always be used in the following circumstances:
-
-- between methods;
-- before a block or single line comment;
-- between logical sections inside a method to improve readability.
-
-#### Blank spaces
-
-Blank spaces should be used in the following circumstances:
-
-- A keyword followed by a parenthesis should be separated by a space.
-
- while (ready == false)
- {
- ...
- }
-
-Note that blanks should not be used between a method call and its opening parenthesis. This helps to distinguish keywords from function calls.
-- Blanks should appear after commas in argument lists.
-- All binary operators except "." should be separated from their operands by spaces. Blanks should never separate unary operators such as unary minus, increment("++") and decrement("--") from their operands.
-
- a += c + d;
- a = (a + b) / (c * d);
- xCoord++;
-
-- The expressions in a for statement should be separated by blanks.
-
- for (expr1; cond1; expr2)
-
-- Casts should be followed by a blank.
-
- myInstance.doIt((TreeFrame) frame);
-
-
-### Naming conventions
-
-Naming conventions make programs more understandable by making them easier to read. They can also give information about the function of the identifier.
-
-|Identifier Type|Rules for Naming|Examples|
-|--|--|--|
-
-
-|Interfaces|Interface names should be capitalized like class names.|interface Enumeration;|
-|Methods|Methods should be verbs in mixed case with the first letter lowercase. Within each method name capital letters separate words. Property methods or get-set methods are used as follows:
-
-
-
-
-
-
-|Constant (static final) variables|Names should be all uppercase with words separated by underscores ("_").|public static final int BLACK = 99;|
-|Exceptions|Like class names; always ending in "Exception"|InputException|
-|Packages|Lowercase only; avoid lengthy package names; always start with org.apache.felix.|org.apache.felix.demo.bundle|
-
-Note: All Java identifiers are case sensitive.
-
-## References
-
-- Java Code Conventions - Sun Microsystems, Inc.
- No ref. number, only hyperlink: http://java.sun.com/docs/codeconv/
-- How to Write Doc Comments for JavaDoc - Sun Microsystems, Inc.
- http://java.sun.com/products/jdk/javadoc/writingdoccomments.html
-- JavaDoc homepage - Sun Microsystems, Inc.
- http://java.sun.com/products/jdk/javadoc/
-- [Eclipse formatting template](https://issues.apache.org/jira/secure/attachment/12419890/Apache+Felix+Eclipse+Template.xml).
diff --git a/modules/ROOT/pages/documentation/development/dependencies-file-template.mdtext b/modules/ROOT/pages/documentation/development/dependencies-file-template.mdtext
deleted file mode 100644
index ac7f474..0000000
--- a/modules/ROOT/pages/documentation/development/dependencies-file-template.mdtext
+++ /dev/null
@@ -1,43 +0,0 @@
-Title: DEPENDENCIES file template
-
-Each released software archive must contain a DEPENDENCIES file in it to declare third-party dependencies and their licenses. The following template should be used:
-
-
- Apache Felix AAA
- Copyright BBB The Apache Software Foundation
-
- This software was developed at the Apache Software Foundation
- (http://www.apache.org) and may have dependencies on other
- Apache software licensed under Apache License 2.0.
-
- I. Included Third-Party Software
-
- CCC
-
- II. Used Third-Party Software
-
- DDD
-
- III. Overall License Summary
- - Apache License 2.0
- - EEE
-
-
-Where the placeholders have the following meaning:
-
-* AAA - Name of the Felix subproject.
-* BBB - Copyright year or range of years.
-* CCC - List of third-party software included in the archive.
-* DDD - List of third-party software used (but not included) by the archive.
-* EEE - List of additional third-party licenses as a result of the dependencies.
-
-The format for an individual third-party dependency is flexible, but should try to include the name of the developing organization or individual, a URL, a copyright, and the license. For example, a dependency on OSGi software would look like this:
-
-
- This product includes software developed at
- The OSGi Alliance (http://www.osgi.org/).
- Copyright (c) OSGi Alliance (2000, 2009).
- Licensed under the Apache License 2.0.
-
-
-If you need additional examples on how to fill out a DEPENDENCIES file, look at other examples in the SVN repo or ask on the dev@felix mailing list.
diff --git a/modules/ROOT/pages/documentation/development/provisional-osgi-api-policy.mdtext b/modules/ROOT/pages/documentation/development/provisional-osgi-api-policy.mdtext
deleted file mode 100644
index 6b07eb9..0000000
--- a/modules/ROOT/pages/documentation/development/provisional-osgi-api-policy.mdtext
+++ /dev/null
@@ -1,27 +0,0 @@
-Title: Provisional OSGi API Policy
-
-The OSGi Alliance exposes provisional API that may or may not become part of future OSGi specifications. This policy explains how and when Felix subprojects may relate to such API. Provisional OSGi API refers to anything in the `org.osgi.*` package namespace that is not part of a final released specification.
-
-## Policy
-1. No Felix release may contain or refer to provisional OSGi API.
-1. Provisional API may be included and used in unreleased source code, however the API must be part of a final released OSGi specification before this Felix source may be released.
-1. It is recommended that provisional OSGi API be committed separately from other changes and, if possible, with a reference to its source.
-1. Although it is STRONGLY NOT RECOMMENDED, modified versions of provisional api may be released with these modifications:
-
- 1. Any provisional OSGi API must be recreated in the `org.apache.felix.*` package name space; this effectively makes it provisional Felix API.
- 1. All Felix provisional API must be marked as deprecated.
- 1. All Felix provisional API exported from bundles should be exported with a mandatory attribute of `status="provisional"`.
-
-## Discussion
-
-The first goal of this policy is to completely avoid using provisional OSGi API in released Felix projects given the potential confusion and questions by doing so. The second goal is to make the existence of any released Felix provisional API completely obvious to downstream users and make it difficult for them to use it unknowingly. However, any such release is likely to involve numerous problems such as incorrect semantic versioning or version mismatch between the provisional and event [...]
-
-As an example, to provisionally export the `org.apache.felix.service.metatype` package, the
-`Export-Package` statement would look something like this:
-
- :::xml
- <Export-Package>
- org.apache.felix.service.metatype; version="0.1"; mandatory:="status"; status="provisional"
- </Export-Package>
-
-When working with new OSGi specifications, constructing a Felix provisional API will likely result in parallel package structures between the provisional OSGi and Felix APIs. When working with existing specifications, it may be necessary to create extensions to existing OSGi interfaces in the Felix package namespace.
diff --git a/modules/ROOT/pages/documentation/development/release-management-nexus.mdtext b/modules/ROOT/pages/documentation/development/release-management-nexus.mdtext
deleted file mode 100644
index c953d99..0000000
--- a/modules/ROOT/pages/documentation/development/release-management-nexus.mdtext
+++ /dev/null
@@ -1,345 +0,0 @@
-Title: Release Management
-
-*This is the release process for Apache Felix, based on Apache Maven [process](https://maven.apache.org/developers/release/releasing.html)
-
-## Basics
-
-Apache Felix artifacts are distributed in two channels: The Maven Repository and the Apache
-distribution channels.
-
-The basic steps for releasing are:
-
-* [Release the module with the Maven Release plugin deploying to the Nexus Staging repository](#staging-the-release-candidates)
-* Check the artifacts
-* [Call for vote](#starting-the-vote)
-* [Publish the release candidate](#promoting-the-release):
- * Publish the staged artifacts from Nexus Staging
- * `svn add` the artifacts to the `dist` Subversion repository and `svn rm` the artifacts from the previous release
-* [Announce the release](#create-an-announcement)
-
-<div class="note">
-The Apache Felix PMC appreciates all committers playing release manager for the projects they
-maintain. Due to restrictions imposed on us, only members of the PMC are actually able to
-commit the releases to the distribution repository (See <a href="#promoting-the-release">Publish the release candidate</a>).
-In this case please ask a member of the PMC to actually publish the release artifacts. Thanks.
-</div>
-
-## Prerequisites
-
-To prepare or perform a release you *MUST BE* at least an Apache Felix Committer.
-
-* each and every release must be [SIGNED](https://www.apache.org/dev/release-signing.html); your public key should be added to [https://www.apache.org/dist/felix/KEYS] (see *Appendix A*)
-* your public key should also be cross-signed by other Apache committers (not required, but suggested)
-* make sure you have all Apache servers defined in your [settings.xml](https://maven.apache.org/developers/committer-settings.html)
-* use Maven 3.5.0 (or higher)
-
-*Note*: Listing the Apache servers in the `settings.xml` file also requires adding the password to that file. Starting with Maven 2.1 this password may be encrypted and needs not be give in plaintext. Please refer to [Password Encryption](https://maven.apache.org/guides/mini/guide-encryption.html) for more information.
-
-In the past we staged release candidates on our local machines using a semi-manual process. Now that we inherit from the Apache parent POM version 5, a repository manager will automatically handle staging for you. This means you now only need to specify your GPG passphrase in the release profile of your `$\{user.home\}/.m2/settings.xml`:
-
- :::xml
- <settings>
- ...
- <profiles>
- <profile>
- <id>release</id>
- <properties>
- <gpg.passphrase> <!-- YOUR KEY PASSPHRASE --> </gpg.passphrase>
- </properties>
- </profile>
- </profiles>
- ...
- </settings>
-
-
-Everything else has been configured in the latest Felix parent POM:
-
- :::xml
- <parent>
- <groupId>org.apache.felix</groupId>
- <artifactId>felix-parent</artifactId>
- <version>6</version>
- <relativePath>../pom/pom.xml</relativePath>
- </parent>
-
-
-## Staging the Release Candidates
-
-First prepare your POMs for release:
-
-1. Make sure you have correct NOTICE, [DEPENDENCIES]({{ refs.dependencies-file-template.path }}), and LICENSE files. Remember to update the copyright year.
-1. Make sure you have an updated change log file, typically in `doc/changelog.txt` but in the project root is also acceptable.
-1. Make sure there are no snapshots in the POMs to be released
-1. Check that your POMs will not lose content when they are rewritten during the release process
- * `mvn release:prepare -DdryRun=true`
- * diff the original `pom.xml` with the one called `pom.xml.tag` to see if the license or any other info has been removed. This has been known to happen if the starting `<project>` tag is not on a single line. The only things that should be different between these files are the `<version>` and `<scm>` elements. If there are any other changes, you must fix the original `pom.xml` file and commit before proceeding with the release
-1. Publish a snapshot. This is useful for existing builds that still depend on a snapshot version of this artifact. It means that the snapshot they will be getting is effectively the same as
-the released version.
- <div class="codehilite"><code>$ mvn deploy
- ...
- [INFO] [deploy:deploy]
- [INFO] Retrieving previous build number from apache.snapshots.https
- ...</code></div>
- * if you experience an error during deployment like a HTTP 401 check your settings for the required server entries as outlined in the *Prerequisites*
- * be sure that the generated artifacts respect the Apache release [rules](https://www.apache.org/dev/release.html): NOTICE and LICENSE files should be present in the META-INF directory within the jar. For -sources artifacts, be sure that your POM does not use the maven-source-plugin:2.0.3 which is broken. The recommended version at this time is 2.0.4
- * you should verify the deployment under the [snapshot](https://repository.apache.org/content/groups/snapshots/org/apache/felix) repository on Apache
-1. Prepare the release
- <div class="codehilite"><code>$ mvn release:clean
- $ mvn release:prepare</code></div>
- * preparing the release will create the new tag in git, automatically checking in on your behalf
-1. Stage the release for a vote
- <div class="codehilite"><code>$ mvn release:perform</code></div>
- * the release will automatically be inserted into a temporary staging repository for you, see the Nexus [staging documentation](https://www.sonatype.com/books/nexus-book/reference/staging.html) for full details
- * you can continue to use `mvn release:prepare` and `mvn release:perform` on other sub-projects as necessary on the same machine and they will be combined in the same staging repository - this is useful when making a release of the Felix framework and its associated bundles.
-1. Close the staging repository
- * login to [https://repository.apache.org](https://repository.apache.org) using your Apache SVN credentials. Click on *Staging* on the left. Then click on *org.apache.felix* in the list of repositories. In the panel below you should see an open repository that is linked to your username and IP. Right click on this repository and select *Close*. This will close the repository from future deployments and make it available for others to view. If you are staging multiple releases togethe [...]
-1. Verify the staged artifacts
- * if you click on your repository, a tree view will appear below. You can then browse the contents to ensure the artifacts are as you expect them. Pay particular attention to the existence of \*.asc (signature) files. If you don't like the content of the repository, right click your repository and choose *Drop*. You can then rollback your release (see *Canceling the Release*) and repeat the process
- * note the staging repository URL (especially the number at the end of the URL) you will need this in your vote email.
-
-
-## Starting the Vote
-
-Propose a vote on the dev list with the closed issues, the issues left, and the staging repository - for example:
-
- :::text
- To: "Felix Developers List" <de...@felix.apache.org>
- Subject: [VOTE] Release Felix XXX version Y.Z
-
- Hi,
-
- We solved N issues in this release:
- https://issues.apache.org/jira/...
-
- There are still some outstanding issues:
- https://issues.apache.org/jira/...
-
- Staging repository:
- https://repository.apache.org/content/repositories/orgapachefelix-[YOUR REPOSITORY ID]/
-
- You can use this UNIX script to download the release and verify the signatures:
- https://github.com/apache/felix-dev/blob/master/check_staged_release.sh
-
- Usage:
- sh check_staged_release.sh [YOUR REPOSITORY ID] /tmp/felix-staging
-
- Please vote to approve this release:
-
- [ ] +1 Approve the release
- [ ] -1 Veto the release (please provide specific comments)
-
- This vote will be open for 72 hours.
-
-To get the JIRA release notes link, browse to the FELIX [JIRA](https://issues.apache.org/jira/browse/FELIX) page, select [Release Notes|https://issues.apache.org/jira/secure/ConfigureReleaseNote.jspa?projectId=12310100] and choose the relevant sub-project release and format (HTML)
-
-To get the list of issues left in JIRA, select the [Open Issues](https://issues.apache.org/jira/browse/FELIX?report=com.atlassian.jira.plugin.system.project:openissues-panel) tab on the main FELIX page, and select the relevant sub-project.
-
-## Wait for the Results
-
-From [Votes on Package Releases](https://www.apache.org/foundation/voting.html):
-
-> Votes on whether a package is ready to be released follow a format similar to majority approval -- except that the decision is officially determined solely by whether at least three +1 votes were registered. Releases may not be vetoed. Generally the community will table the vote to release if anyone identifies serious problems, but in most cases the ultimate decision, once three or more positive votes have been garnered, lies with the individual serving as release manager. The specifi [...]
-
-The list of binding voters is available at [{{ refs.project-management-committee-pmc.headers.title }}]({{ refs.project-management-committee-pmc.path }})
-
-If the vote is successful, post the result to the dev list - for example:
-
- :::text
- To: "Felix Developers List" <de...@felix.apache.org>
- Subject: [RESULT] [VOTE] Release Felix XXX version Y.Z
-
- Hi,
-
- The vote has passed with the following result :
-
- +1 (binding): <<list of names>>
- +1 (non binding): <<list of names>>
-
- I will copy this release to the Felix dist directory and
- promote the artifacts to the central Maven repository.
-
-If the vote is unsuccessful, you need to fix the issues and restart the process - see *Canceling the Release*.
-If the vote is successful, you need to promote and distribute the release - see *Promoting the Release*.
-
-## Canceling the Release
-
-If the vote fails, or you decide to redo the release:
-
-1. remove the release tag from Subversion (`svn rm ...`)
-1. login to [https://repository.apache.org](https://repository.apache.org) using your Apache SVN credentials. Click on *Staging* on the left. Then click on *org.apache.felix* in the list of repositories. In the panel below you should see a closed repository that is linked to your username and IP (if it's not yet closed you need to right click and select *Close*). Right click on this repository and select *Drop*.
-1. rollback the version in the `pom.xml` and commit any fixes you need to make
-
-<div class="info" markdown="1">
-The release manager is free to either reuse the same version when proposing a new release for vote (for example 2.1.2 after a failed 2.1.2 release attempt), or choose a different number (for example 2.1.4 after a failed 2.1.2 attempt). (cf. vote on 02/14/11).
-</div>
-
-
-## Promoting the Release
-
-If the vote passes:
-
-* [Upload the Artifacts](#upload-the-artifacts)
-* [Release to the Maven Repository](#release-to-the-maven-repository)
-* [Release Bundles to the OBR](#release-bundle-to-the-obr)
-* [Update the Site](#update-the-site)
-
-### Upload the Artifacts
-
-<div class="note">
-If you are not a member of the Apache Felix PMC you might have to ask a member of
-the PMC to execute this step.
-</div>
-
-<div class="note">
-It is recommended to use the check_staged_release.sh script to download your release prior to releasing the staging repository. This will make the task of uploading the release to the Felix releases repository easier.
-</div>
-
-We use the distribution mechanism as described in [How do I upload a release (newer way)?](https://www.apache.org/dev/release.html#upload-ci)
-
-1. Check out the [Felix releases repository](https://dist.apache.org/repos/dist/release/felix);
-1. `svn add` the artifacts to your checkout;
-1. `svn rm` the artifacts from the previous release from your checkout. This
-will remove the artifacts from the main distribution and the mirrors. They
-are still kept in the archive;
-1. `svn commit` your changes.
-
-After committing your changes, the [Apache Felix Dist](https://www.apache.org/dist/felix)
-folder is immediately updated. Updating the mirrors takes another few hours
-(up to a day).
-
-### Release to the Maven Repository
-
-1. Login to [Apache Nexus Repository](https://repository.apache.org) with your Apache SVN credentials;
-1. Click on *Staging*;
-1. Find your closed staging repository, select it, and click the *Release* button;
-1. Click on *Repositories*;
-1. Select the *Releases* repository;
-1. Validate that your artifacts are all there.
-
-### Release Bundles to the OBR
-
-If you're releasing bundles, you can also add them to the Felix Release OBR. To do this, execute the following command
-in a checkout of the release tag (target/checkout if is still around, otherwise a new one):
-
- :::bash
- $ export site=# your checkout of (https://svn.apache.org/repos/asf/felix/site/trunk/content)
- $ export obr=${site}/obr
- $ mvn clean install \
- org.apache.felix:maven-bundle-plugin:deploy \
- -DprefixUrl=https://repo1.maven.org/maven2 \
- -DremoteOBR=releases.xml \
- -DaltDeploymentRepository=apache.website::default::file:///${obr}
- $ svn commit -m"..." ${obr}/repository.xml
-
-After committing the site must be published. If you release to OBR before [updating the site](update-the-site) you can defer publishing until after that.
-Otherwise publish the site by visiting the [Site Publication](https://cms.apache.org/felix/publish) link.
-
-The [releases](https://felix.apache.org/obr/releases.xml) page is updated immediately.
-
-**Note**: the project building the bundle must use the [{{ maven-bundle-plugin.headers.title }}]({{ maven-bundle-plugin.path }}) and use a version equal to or higher than 1.4.2.
-
-**Note**: with Maven 3, you must add an extension to your `<build>` providing the SCP/SSH protocol:
-
- :::xml
- <build>
- ...
- <extensions>
- <extension>
- <groupId>org.apache.maven.wagon</groupId>
- <artifactId>wagon-ssh</artifactId>
- <version>1.0-beta-6</version>
- </extension>
- </extensions>
- </build>
-
-
-### Update the Site
-
-1. Update the news section on the website at [news](https://cms.apache.org/redirect?uri=http%3A//felix.apache.org/news.html);
-1. Update the download page on the website at [downloads](https://cms.apache.org/redirect?uri=http%3A//felix.apache.org/downloads.list) to point to the new release;
-1. Commit your changes (click the commit link);
-1. [Publish the site](https://cms.apache.org/felix/publish).
-
-For the last two tasks, it's better to give the mirrors some time to distribute the uploaded artifacts (one day should be fine). This ensures that once the website (news and download page) is updated, people can actually download the artifacts.
-
-
-## Update JIRA
-
-Go to [Admin](https://issues.apache.org/jira/secure/project/ViewProject.jspa?pid=12310100) section on the FELIX JIRA and mark the Y.Z version as released - create version Y.Z+1, if that hasn't already been done.
-
-
-## Publish Generated Documentation
-
-This procedure applies currently only to the `maven-bundle-plugin`:
-
-1. Checkout the release tag of the plugin
-1. Run `mvn clean package site`
-1. Create a new folder for the new version at `https://svn.apache.org/repos/asf/felix/site/trunk/content/components/bundle-plugin-archives/bundle-plugin-<version>` and publish the generated site from `target/site` there
-1. Remove the previous documentation from `components/bundle-plugin` and SVN-copy the new version there as well
-
-
-## Create an Announcement
-
-
- :::text
- To: "Felix Users List" <us...@felix.apache.org>
- Subject: [ANN] Felix XXX version Y.Z Released
-
- The Felix team is pleased to announce the release of Felix XXX version Y.Z
-
- <<insert short description of the sub-project>>
-
- https://felix.apache.org/site/apache-felix-XXX.html
-
- This release is available from https://felix.apache.org/site/downloads.cgi and Maven:
-
- <dependency>
- <groupId>org.apache.felix</groupId>
- <artifactId>org.apache.felix.XXX</artifactId>
- <version>Y.Z</version>
- </dependency>
-
- Release Notes:
-
- <<insert release notes in text format from JIRA>>
-
- Enjoy!
-
- -The Felix team
-
-
-Remember to forward this announcement to `users@felix.apache.org` - try *not* to cross-post (CC:\) announcements to both user and dev lists.
-
-*Remind Carsten about this release when he writes the next board report ;)*
-
-## Appendix A: create and add your key to https://www.apache.org/dist/felix/KEYS
-
-If you are using a *nix system with a working OpenSSH, GnuPG, and bash you can create and add your own key with the following command:
-
- :::bash
- $ gpg --gen-key
-
-When gpg asks for e-mail linked the key you *MUST USE* the <committer>@apache.org one.
-When gpg asks for comment linked the key you *SHOULD USE* "CODE SIGNING KEY".
-
-Second, *Add the key to* (https://dist.apache.org/repos/dist/release/felix/KEYS).
-
-Only PMC members can commit to files in the dist area, so you should do the key export in the
-shell commands below, and send the results along to a friendly PMC member for assistance.
-
-Type the following command replacing the word e-mail with your Apache's one (<committer>@apache.org). To update you have to checkout the Felix
-dist release repository (you also need this to publish a release):
-
- :::bash
- $ (gpg --list-sigs e-mail && gpg --export --armor e-mail) > toadd.key
-
-Provide the file to a PMC member, who will:
-
- :::bash
- $ svn checkout https://dist.apache.org/repos/dist/release/felix felix-dist
- $ cat toadd.key >> felix-dist/KEYS
- $ scn commit -m"KEYS += <committer>" felix-dist/KEYS
-
-You are now *DONE* and the changes are visible on https://www.apache.org/dist/felix/KEYS.
-
-
diff --git a/modules/ROOT/pages/documentation/development/site-how-to.mdtext b/modules/ROOT/pages/documentation/development/site-how-to.mdtext
deleted file mode 100644
index 99a5cd9..0000000
--- a/modules/ROOT/pages/documentation/development/site-how-to.mdtext
+++ /dev/null
@@ -1,201 +0,0 @@
-Title: Site How To
-
-The site is managed with the [Apache CMS](https://www.apache.org/dev/cms.html)
-where the source is kept in SVN at <https://svn.apache.org/repos/asf/felix/site/trunk/content>.
-
-## To update the documentation using the CMS system
-
-* Install the bookmarklet from the [cms](https://cms.apache.org/) page. You only have to do this once.
-* Navigate to the page you wish to edit (on the live site, not in the cms).
-* Click the bookmarklet. There will be a short pause while the CMS system is initialised for you.
-* Click on `Edit` (to skip this step hack the bookmarklet to add an 'action=edit' param to the query string)
-* The page editor should then be displayed.
-* Click `Submit` to save your edit to the workarea
-* Click `Commit` to save the updated file to SVN and trigger a staged build. (to skip this step click on the "Quick Commit" checkbox in the `Edit` form).
-* The results should appear shortly on the [staging](http://felix.staging.apache.org/content/documentation.html) site. (You may have to force the page to refresh in order to see the updated content)
-* Once you are happy with the updated page, click on `Publish Site` to deploy.
-
-There is also a [Reference Manual](https://www.apache.org/dev/cmsref.html) of the Apache CMS as well as a
-video tutorial at <http://s.apache.org/cms-tutorial>.
-
-## Features of the Apache Felix Site
-
-This section lists some Apache Felix features to help with the maintenance
-of the site, such as automatic link generation.
-
-Start the file with a `Title:` line to define the page title and the first H1 tag:
-
- Title: Page Title
-
- Here comes the content separated with a blank like from the
- header ...
-
-The last modification information from SVN (revision, committer, and
-date/time) is automatically added when the page is rendered
-
-Excerpts can be added to a page using the `Excerpt:` header:
-
- Title: Page Title
- Excerpt: Summary of the page for inclusion in other pages;
- continuation of the excerpt must be indented
-
- Here comes the content separated with a blank like from the
- header ...
-
-Metadata from child pages can be referred to in the content with the
-Django variable reference notation using the child page name (without
-extension) as its container; e.g. for the child page named `childpage`:
-
- :::django
- {{ y|default:"{{" }} children.childpage.headers.excerpt }}
- {{ y|default:"{{" }} children.childpage.headers.title }}
-
-Content Pages can contain Django templates of the form `{{ y|default:"{{" }}...}}` and `{{ y|default:"{%" }}...%}`.
-If so, the page content is evaluated as a Django template before running
-it through the page template.
-
-Any page in the site can be referenced with refs.pagename returning properties:
-
-`.path`
-: the absolute path of the page on the site
-
-`.headers`
-: page headers (e.g. `.title`, `.excerpt`)
-
-`.content`
-: the raw page content
-
-All pages in the children namespace are also available in the refs namespace
-
-Some usefull hints:
-
-Printing title of another page "handler":
-
- :::django
- {{ y|default:"{{" }} refs.handler.headers.title }}
-
-Printing excerpt of another page "handler":
-
- :::django
- {{ y|default:"{{" }} refs.handler.headers.excerpt }}
-
-Linking to another page "handler":
-
- :::django
- ({{ y|default:"{{" }} refs.handler.path }})
-
-Printing title as a link to another page "handler":
-
- :::django
- [{{ y|default:"{{" }} refs.handler.headers.title }}]({{ y|default:"{{" }} refs.handler.path }})
-
-Printing excerpt as a link to another page "handler":
-
- :::django
- [{{ y|default:"{{" }} refs.handler.headers.excerpt }}]({{ y|default:"{{" }} refs.handler.path }})
-
-Print a bullet pointed child page list:
-
- :::django
- {{ y|default:"{%" }} for label, page in children %}* [{{ y|default:"{{" }} page.headers.title }}]({{ y|default:"{{" }} page.path }})
- {{ y|default:"{%" }} endfor %}
-
-<div class="note">
-It is important to have the first part as a single line, otherwise
-the Django/Markdown combo will create a list for each entry.
-</div>
-
-
-## Code Highlighting
-
-Code Highlighting works by indenting code by four blanks. To indicate the
-type of highlighting preced the code style text with either `:::<lexer>` to
-get high lighted code using the given `<lexer>` or `#!<lexer>` to get high
-lighted code with line numbers using the given `<lexer>`. See
-<http://www.apache.org/dev/cmsref.html#code-hilighter> for main info and
-<http://pygments.org/docs/lexers/> for supported lexers
-
-
-## HTML and Markdown
-
-Markdown supports embedding HTML. But be aware that contents of HTML elements
-are not further handled by the Markdown converter. Thus it is not possible
-to embed Markdown syntax inside of HTML elements to have them converted.
-
-
-## Manual Generation
-
-When commiting changes to pages into SVN the pages are automatically
-generated in [the staging site](http://felix.staging.apache.org).
-
-<div class="info">
-<p>To generate the site locally, you must have checked out the complete SVN to access the tools:</p>
-
-<div class="codehilite"><pre><span class="nv">$ </span>svn <span class="s2">https://svn.apache.org/repos/asf/felix/site/ felix-site</span>
-</pre></div>
-</div>
-
-To manually generate the site or single pages the [site](http://svn.apache.org/repos/asf/felix/site)
-can be checked out from SVN. In addition Perl and Python must be installed
-for the build tools to work.
-
-To prepare for site build, the Markdown daemon has to be started:
-
- :::sh
- $ export MARKDOWN_SOCKET="$PWD/tools/build/../markdown.socket"
- $ export PYTHONPATH="$PWD/tools/build"
- $ python "$PWD/tools/build/markdownd.py"
-
-
-
-The `MARKDOWN_SOCKET` environment variables is also required by the `build_site.pl`
-and `build_file.pl` scripts to connect to the Markdown daemon.
-
-To build the complete site use the `build_site.pl` script:
-
- :::sh
- $ tools/build/build_site.pl --source-base $PWD/trunk \
- --target-base $PWD/trunk/target
-
-To build a single page use the `build_file.pl` script:
-
- :::sh
- $ tools/build/build_site.pl --source-base $PWD/trunk \
- --target-base $PWD/trunk/target \
- --source content/documentation.mdtext
-
-The argument to the `--source` parameter is relative to the `--source-base` folder.
-
-## Configuring site generation on Mac
-
-<div class="info">
-Those instructions were computed on Mountain Lion.
-</div>
-
-A couple of Python and Perl libraries are required and need to be installed
-
- :::sh
- $ sudo easy_install Pygments
- $ sudo easy_install Markdown
-
-And for the Perl modules:
-
- :::sh
- $ sudo cpan install XML::Atom::Feed
- $ sudo cpan install XML::RSS::Parser
- $ sudo cpan install XML::Parser::Lite
- $ sudo cpan install XML::RSS::Parser::Lite
- $ sudo cpan install Net::Twitter
- $ sudo cpan install SVN::Client
-
-Be careful that some of those commands require time... Once done, launch the mardown daemon with the following command from the SVN root:
-
- :::sh
- $ export MARKDOWN_SOCKET="$PWD/tools/build/../markdown.socket"
- $ export PYTHONPATH="$PWD/tools/build"
- $ python "$PWD/tools/build/markdownd.py"
-
-And finally, generate the web site from the svn root with:
-
- :::sh
- tools/build/build_site.pl --source-base $PWD/trunk --target-base $PWD/trunk/target
diff --git a/modules/ROOT/pages/documentation/development/using-the-osgi-compliance-tests.mdtext b/modules/ROOT/pages/documentation/development/using-the-osgi-compliance-tests.mdtext
deleted file mode 100644
index aa9ea6d..0000000
--- a/modules/ROOT/pages/documentation/development/using-the-osgi-compliance-tests.mdtext
+++ /dev/null
@@ -1,213 +0,0 @@
-Title: Using the OSGi Compliance Tests
-
-The OSGi Alliance provides Apache committers access to its Compliance Tests (CT). This
-page describes how to get access to the CTs and how to use them with Felix subprojects.
-
-
-## Gaining Access to OSGi CTs
-
-The general process is to send a request to the jcp-open@apache.org mailing requesting
-access. Since redistributing the OSGi CTs is not allowed, you will need to submit an
-[NDA](http://www.apache.org/jcp/ApacheNDA.pdf) to be granted access to the
-[SVN repo](https://svn.apache.org/repos/tck/osgi-cts) containing the binaries.
-
-
-## OSGi CT Overview
-
-The CT is delivered as three JAR files, one for the core CT, one of the enterprise CT and one for the compendium CT.
-Each JAR file is composed of several other JAR files, which are the actual compliance
-tests. Typically, there is one JAR per specification, except for the OSGi framework. The
-CT uses BND as its testing harness, which in turn uses the OSGi framework launching
-and embedding API to configure, launch, and install test bundles. Each test JAR file has
-an associated BND file which supplies the configuration BND needs to run the associated tests.
-
-
-## Modifying the BND files
-
-Modifying the BND files is fairly straightforward. A typical BND file looks like this:
-
- :::plaintext
- # bnd pack for project org.osgi.test.cases.startlevel
- # Mon Aug 31 18:50:18 EDT 2009
- build=.
-
- -target = \
- jar/org.osgi.test.cases.startlevel-4.2.0.jar;version=file,
-
- -runpath = \
- jar/org.eclipse.osgi-3.5.1.jar;version=file, \
- jar/com.springsource.junit-3.8.2.jar;version=file;export="junit.framework;version=3.8"
-
- -runbundles
-
- -runproperties = \
- report="true", \
- osgi.compatibility.bootdelegation="false", \
- osgi.resolverMode="strict"
-
-
-The important parts are the following settings:
-
-* `-target` specifies the bundles containing the tests.
-* `-runpath` specifies the class path used to run the tests.
-* `-runbundles` specifies the bundles to install for the tests.
-* `-runproperties` specifies configuration properties to pass into the framework.
-
-The following two examples show how to edit these files for the Felix framework and Felix
-bundle subprojects.
-
-## Testing the Felix framework
-
-The Felix framework is tested against the core CT. The first thing to do is extract the core
-CT JAR file, which includes test suites for:
-
-###Core functionality
-
-* Framework core (`org.osgi.test.cases.framework.bnd`)
-* Framework launching (`org.osgi.test.cases.framework.launch.bnd`)
-* Tracker Specification (`org.osgi.test.cases.tracker.bnd`)
-* URL Handlers (`org.osgi.test.cases.url.bnd`)
-
-While the Tracker and URL Handler specifications are optional as per the OSGi Specification, they are implemented by the
-Felix Framework and therefore the tests should be run and pass.
-
-The following CT tests from the Compendium/Enterprise CT also pass with the Felix framework:
-
-* XML Parser Specification (`org.osgi.test.cases.xml.bnd`)
-
-###Security components
-
-OSGi Security components are optional. They are supported by Felix but require
-security support to be enabled. See the [Security][1] section below for more details.
-
-* Framework security (`org.osgi.test.cases.framework.secure.bnd`)
-* Framework launching security (`org.osgi.test.cases.framework.launch.secure.bnd`)
-* Permission Admin (`org.osgi.test.cases.permissionadmin.bnd`)
-* Conditional Permission Admin (`org.osgi.test.cases.condpermadmin.bnd`)
-
-With security correctly enabled in Felix all the above security CT suites should pass.
-
-### Running the tests
-
-For each of the associated BND files, the `-runpath` needs to be edited to refer to the Felix
-framework. The easiest way to do this is by modifying the `shared.inc` file which is included by
-all BND files. It should look something like this after editing:
-
- :::plaintext
- -runpath = \
- /path/to/felix/framework/org.apache.felix.framework-4.4.1.jar;version=file, \
- jar/com.springsource.junit-3.8.2.jar;version=file;export="junit.framework;version=3.8"
-
-
-Typically, it is not necessary to change anything else in the BND files and it is normal that
-the `-runbundles` setting is empty, since there are no additional bundles associated with
-testing the framework.
-
-After editing the BND files, run the tests using:
-
- :::plaintext
- source runtests
-
-
-This will run all test suites for all BND files. To run a specific test suite, do the following:
-
-
- :::bash
- $ java -jar jar/bnd.jar runtests --title osgi.ct <bnd-file>
-
-
-Where `<bnd-file>` specifies one or more BND files associated with the desired test suites.
-
-<div class="note" markdown="1">
-<b>Be Aware</b>
-Tests for native code loading will fail on Java 6, so do not use this JDK for testing the
-framework.
-</div>
-
-Reports for the tests suites are generated in the `reports/` subdirectory and are named
-after the appropriate test suite.
-
-### <a id="security"></a>Security
-***TODO this section is unfinished.***
-
-The exception to this is for the framework test suites for security.
-To test with security enabled, you will need to add the framework security provider in
-`-runbundles` like this:
-
- :::plaintext
- -runbundles = \
- /path/to/felix/framework.security/org.apache.felix.framework.security-1.0.0.jar.jar;version=file
-
-
-### Deviations
-#### Core R5
-When running the Core R5 CT the following error appears:
-
- :::plaintext
- testEERequirement
- junit.framework.AssertionFailedError: Required Execution Environment is available: Unresolved constraint in bundle org.osgi.test.cases.framework.div.tb7a [214]: Unable to resolve 214.0: missing requirement [214.0] osgi.ee; (|(osgi.ee=div/tb7a)(osgi.ee=div/tb7b))
- at org.osgi.test.support.OSGiTestCase.fail(OSGiTestCase.java:70)
- at org.osgi.test.cases.framework.junit.div.DivTests.testEERequirement(DivTests.java:253)
-
-This is a known deviation in the Core R5 CT and can be ignored.
-
-#### Core R6
-When running the Core R6 CT the following error appears:
-
- :::plaintext
- testArrayServiceReferenceDTO
- junit.framework.AssertionFailedError: ServiceReferenceDTO[] for stopped bundle is null
- at junit.framework.Assert.fail(Assert.java:47)
- at junit.framework.Assert.assertTrue(Assert.java:20)
- at junit.framework.Assert.assertNotNull(Assert.java:217)
- at org.osgi.test.cases.framework.junit.dto.DTOTestCase.testArrayServiceReferenceDTO(DTOTestCase.java:429)
-
-This is a known deviation in the Core R6 CT and can be ignored.
-
-## Testing a Felix bundle
-
-The core CT tests the framework implementation and its related services. The compendium CT
-tests the various non-framework-related specifications, which are implemented as bundles. For
-the most part, testing a bundle is similar to testing the framework.
-
-Extract the compendium CT JAR file to access the individual test suites. Since most compendium
-service specification test suites require security, it is necessary to use a framework
-implementation that supports security. For the Felix framework, you will have to add the
-security provider to the `-runbundles` to enable security.
-
-For example, to test Felix' Event Admin bundle, edit the `-runbundles` setting in
-`org.osgi.test.cases.event.bnd` to look something like this:
-
- :::plaintext
- -runbundles = \
- /path/to/felix/eventadmin/org.apache.felix.eventadmin-1.0.0.jar;version=file,\
- /path/to/felix/framework.security/org.apache.felix.framework.security-1.0.0.jar.jar;version=file
-
-
-After editing the BND files to refer to the appropriate bundles, run the tests using:
-
-
- :::plaintext
- source runtests
-
-
-This will run all test suites for all BND files. To run a specific test suite, do the following:
-
-
- :::bash
- $ java -jar jar/bnd.jar runtests --title osgi.ct <bnd-file>
-
-
-Where `<bnd-file>` specifies one or more BND files associated with the desired test suites.
-Reports for the tests suites are generated in the `reports/` subdirectory and are named
-after the appropriate test suite.
-
-
-## Feedback
-
-For any questions or feedback, subscribe to the Felix developers mailing list by sending a
-message to [dev-subscribe@felix.apache.org](mailto:dev-subscribe@felix-apache-org); after
-subscribing, email questions or feedback to [dev@felix.apache.org](mailto:dev@felix.apache.org).
-
-
- [1]: #security
\ No newline at end of file
diff --git a/modules/ROOT/pages/documentation/faqs.mdtext b/modules/ROOT/pages/documentation/faqs.mdtext
deleted file mode 100644
index ed3f09d..0000000
--- a/modules/ROOT/pages/documentation/faqs.mdtext
+++ /dev/null
@@ -1,6 +0,0 @@
-Title: Frequently Asked Questions
-
-* [OSGi FAQ]({{ refs.apache-felix-osgi-faq.path }}) - Contains answers to general OSGi-related questions.
-* [Framework FAQ]({{ refs.apache-felix-framework-faq.path }}) - Contains answers to questions that are specifically related to Felix' OSGi framework implementation.
-* [Bundle Plugin FAQ]({{ refs.apache-felix-bundle-plugin-faq.path }}) - Contains answers to questions about the Felix maven-bundle-plugin
-* [SCR Plugin FAQ]({{ refs.apache-felix-scr-plugin-faq.path }}) - Contains answers to questions about the Felix maven-scr-plugin
diff --git a/modules/ROOT/pages/documentation/faqs/apache-felix-bundle-plugin-faq.mdtext b/modules/ROOT/pages/documentation/faqs/apache-felix-bundle-plugin-faq.mdtext
deleted file mode 100644
index eb8abae..0000000
--- a/modules/ROOT/pages/documentation/faqs/apache-felix-bundle-plugin-faq.mdtext
+++ /dev/null
@@ -1,179 +0,0 @@
-Title: Apache Felix Bundle Plugin Frequently Asked Questions
-
-[TOC]
-
-## When I embed a dependency why do I see duplicated content?
-
-Having two copies of classes, both unpacked and embedded as jars, is a sign that your Embed-Dependency and Export-Package instructions are overlapping. Export-Package tells BND to pull in classes found in the named packages from the build classpath and add them to the bundle, Embed-Dependency tells BND to embed (or inline if enabled) whole artifacts in the bundle.
-
-so say I have:
-
-
- Export-Package: org.objectweb.asm.*
-
-
-and I have the asm artifact as a compile scope dependency, then I would see the org.objectweb.asm classes unpacked in the bundle, ie. pulled in by BND.
-
-say I now decide to embed asm as a jar, for example with:
-
-
- Embed-Dependency: *;scope=compile|runtime
-
-
-I would now see the asm artifact embedded inside bundle - but I would also see the unpacked classes from before, because I'm still asking BND to pull them in (you will probably also see split package warnings during the build).
-
-ok - so how do I embed asm as a jar, but mark its packages as exported without pulling in the unpacked classes... well, there is another export instruction added for exactly this reason:
-
-
- -exportcontents: org.objectweb.asm.*
-
-
-(this is <_exportcontents> in the POM because a tag can't start with '-')
-
-this instruction is merged with Export-Package, after BND has decided on the content of the bundle - that is, it works just like Export-Package except that it won't alter the content of the bundle.
-
-So by removing org.objectweb.asm.* from Export-Package and using the -exportcontents instruction instead along with Embed-Dependency, I can now embed the asm artifact in my bundle and export its packages:
-
-
- Embed-Dependency: *;scope=compile|runtime
- -exportcontents: org.objectweb.asm.*
-
-
-## Why do I see more classes in my bundle after upgrading to maven-bundle-plugin 2.0.0?
-
-Before 2.0.0 the maven-bundle-plugin only passed local classes and compile scope dependencies to bnd. This was because the main BundlePlugin mojo used "@requiresDependencyResolution runtime" which asks Maven to only resolve dependencies of compile or runtime scope (the maven-bundle-plugin also explicitly filtered runtime scope dependencies from the classpath passed to bnd). Because bnd only had a fraction of the original classpath used to compile the bundle classes it meant that imported [...]
-
-In 2.0.0 a conscious decision was made to pass the complete classpath to bnd so it would have the complete set of information used during compilation. To do this the @requiresDependencyResolution setting was changed to "test" so all dependencies will now be resolved. Furthermore only test scope artifacts are now filtered from the final classpath passed to bnd.
-
-For most users passing more of the original compilation classpath to bnd simply means you get more accurate and consistent results. However, if you happened to rely on the old behaviour (perhaps by setting Private-Package: * to pull in all local and compile scope classes) then you will see more classes added to your bundle as the wildcard matches against additional content in the classpath.
-
-There are two solutions when this happens:
-
-* Change your Private-Package / Export-Package instructions to more accurately describe what you want in your bundle
-* Add the following setting to remove provided and runtime scope dependencies from the classpath passed to bnd:
-
- <plugin>
- <groupId>org.apache.felix</groupId>
- <artifactId>maven-bundle-plugin</artifactId>
- <configuration>
- <excludeDependencies>*;scope=provided|runtime</excludeDependencies>
- </configuration>
- </plugin>
-
-
-This second option effectively switches the maven-bundle-plugin back to the old 1.X behaviour.
-
-Please also note that since 2.0.0 the maven-bundle-plugin also sets default Export-Package and Private-Package instructions based on your local source files, so you might well find that simply removing any Private-Package and/or Export-Package instructions from your pom.xml will actually produce the correct result.
-
-## Why do I get an exception (Unsupported major.minor version 49.0) when I build with a 1.4 or earlier JDK?
-
-The latest maven-bundle-plugin (2.0.0) uses a new release of bnd which requires Java5. This means you now have to build your bundle projects using a Java5 (or later) JDK. Note that you can still compile classes for earlier releases of the JVM by setting the appropriate source and target levels in your pom.xml:
-
-
- <plugin>
- <artifactId>maven-compiler-plugin</artifactId>
- <configuration>
- <source>1.4</source>
- <target>1.4</target>
- </configuration>
- </plugin>
-
-
-## When I build a bundle, some classes are built in "target/classes" but they're not included in the final jar.
-
-The only classes that will appear in the bundle are the ones you ask it to include using Export-Package, Private-Package, Include-Resource, and Embed-Dependency - so just because a file exists under target/classes does NOT mean it will end up in the bundle. This is because this is the way the underlying [BND](http://bnd.bndtools.org/) tool works (it is primarily pull-based).
-
-Now the bundleplugin will look at your Maven project and add appropriate BND instructions to pull in resource files - and version 2.0.0 will also look at your source directory to set reasonable defaults for Export-Package and Private-Package (unless you set these yourself). So when using bundleplugin 2.0.0 I'd use the default Private-Package and Export-Package to begin with - I would then move towards using an explicit list of packages in Export-Package to add versioning, directives, etc.
-
-The only time I would set Private-Package would be to have more control over what ends up in the bundle - either to remove certain packages or perhaps pull in additional packages not found by the source scanner. Also note that both Export-Package and Private-Package accept wildcards such as "org.example.\*" which can reduce the number of entries in the list, but you should be careful not to set either the export or private instruction to "\*" as this would pull in the entire classpath... [...]
-
-## How do I remove the generated Maven information from the resulting bundle JAR file?
-
-Use the following archive setting:
-
-
- <configuration>
- <archive>
- <addMavenDescriptor>false</addMavenDescriptor>
- </archive>
- </configuration>
-
-
-Put this in either the JAR or bundle plugin configuration.
-
-## Why do some generated resources (such as Declarative Services XML files) appear in the final jar, but others don't?
-
-When you use the Service-Component instruction to specify Declarative Services the BND tool scans the project classpath for components and automatically adds its generated XML to the final bundle, therefore Include-Resource is not necessary. But if you generate files under OSGI-INF using another mechanism then they won't end up in the bundle unless you add that directory using Include-Resource (this goes back to the core design decision that BND pulls classes and resources into the bundl [...]
-
-## Use SCR metadata generated by BND in Unit Tests
-
-BND and the maven-bundle-plugin support the generation of SCR metadata for OSGi Declarative Service components annotated with the OSGi annotations from the Java package `org.osgi.service.component.annotations`.
-
-To enable this you have to set two special instructions in your maven-bundle-plugin configuration:
-
-
- <configuration>
- <instructions>
- <!-- Enable processing of OSGI DS component annotations -->
- <_dsannotations>*</_dsannotations>
- <!-- Enable processing of OSGI metatype annotations -->
- <_metatypeannotations>*</_metatypeannotations>
- </instructions>
- </configuration>
-
-
-This generates the SCR metadata files at `/OSGI-INF` and `/OSGI-INF/metatype` when building the JAR file.
-
-If you want to run unit test in the same maven projects that need these SCR metadata files when running the tests (e.g. when using [OSGi Mocks](http://sling.apache.org/documentation/development/osgi-mock.html)) you need some special configurations to ensure the SCR metadata is also generated in the filesystem in the maven target folder, and is already available when the unit tests are executed and not only in the package phase:
-
-
- <plugin>
- <groupId>org.apache.felix</groupId>
- <artifactId>maven-bundle-plugin</artifactId>
- <extensions>true</extensions>
- <executions>
- <!-- Configure extra execution of 'manifest' in process-classes phase to make sure SCR metadata is generated before unit test runs -->
- <execution>
- <id>scr-metadata</id>
- <goals>
- <goal>manifest</goal>
- </goals>
- <configuration>
- <supportIncrementalBuild>true</supportIncrementalBuild>
- </configuration>
- </execution>
- </executions>
- <configuration>
- <exportScr>true</exportScr>
- <instructions>
- <!-- Enable processing of OSGI DS component annotations -->
- <_dsannotations>*</_dsannotations>
- <!-- Enable processing of OSGI metatype annotations -->
- <_metatypeannotations>*</_metatypeannotations>
- </instructions>
- </configuration>
- </plugin>
-
-
-The flag `supportIncrementalBuild` is only necessary when you are using Eclipse and m2e, it supports generating the appropriate metadata during incremental builds. When you also want to support the old-style Felix SCR annotations from Java package `org.apache.felix.scr.annotations` you can add this BND plugin:
-
-
- <plugin>
- <groupId>org.apache.felix</groupId>
- <artifactId>maven-bundle-plugin</artifactId>
- <extensions>true</extensions>
- <configuration>
- <instructions>
- <!-- Support parsing of maven-scr-plugin annotations through the felix.scr.bnd plugin -->
- <_plugin>org.apache.felix.scrplugin.bnd.SCRDescriptorBndPlugin;destdir=${project.build.outputDirectory}</_plugin>
- </instructions>
- </configuration>
- <dependencies>
- <dependency>
- <groupId>org.apache.felix</groupId>
- <artifactId>org.apache.felix.scr.bnd</artifactId>
- <version>1.9.4</version>
- </dependency>
- </dependencies>
- </plugin>
-
diff --git a/modules/ROOT/pages/documentation/faqs/apache-felix-scr-plugin-faq.mdtext b/modules/ROOT/pages/documentation/faqs/apache-felix-scr-plugin-faq.mdtext
deleted file mode 100644
index 1ae7de2..0000000
--- a/modules/ROOT/pages/documentation/faqs/apache-felix-scr-plugin-faq.mdtext
+++ /dev/null
@@ -1,71 +0,0 @@
-Title: Apache Felix SCR Plugin Frequently Asked Questions
-
-[TOC]
-
-This page provides answers to frequently asked questions using the Maven
-SCR Plugin. See [{{ refs.apache-felix-maven-scr-plugin.headers.title }}]({{ refs.apache-felix-maven-scr-plugin.path }})
-for documentation on that plugin.
-
-## Should I still use the Apache Felix SCR annotations over the official OSGi annotations?
-
-Starting with the R6 release of the OSGi Declarative Services and Metatype specification, the official annotations support the same features as the Apache Felix SCR annotations in a more elegant manner and even provide additional functionality. Therefore the Apache Felix SCR annotations are now in maintenance mode and therefore you should rather use the official annotations. The Apache Felix maven-bundle-plugin, version 3.0.1 or higher supports those directly and there is no need for an [...]
-
-## Why are the (standard) annotations not processed?
-
-In order to process any annotations, a processor for them needs to be added as a dependency to your project. There are currently two different processors, one for the annotations defined within the Apache Felix project and another one for the standard annotations from the Declarative Services specification.
-## Syntax Error when Enums are used?
-
-During a SCR plugin run, a syntax error might occur if enums are used in the source code. This is a know problem of the used QDox version that reads the Java source files. Usually this happens when an enum is used inline and does not end with a ";". So adding this character should solve the problem:
-
- :::java
- public interface MyTest {
-
- /** more error codes may be added */
- enum Result {
- OK, UNKNOWN, ERROR, DENIED
- }; // <!-- HERE
-
- /** @return the result */
- public void getResult();
- }
-
-
-## NoClassDefFoundError during build
-
-This error might happen with older versions of the Maven SCR Plugins in combination with javadoc tags or newer versions in combination with the annotations.
-In both cases, the scanned classes have to be loaded and static fields have to be initialized. If you have have for example something like
-
- :::java
- private static final org.slf4f.Logger LOGGER = org.slf4j.LoggerFactory.getLogger("name");
-
-in your code, during the plugin run, a slf4j logger is tried to be instantiated. This requires an implementation of the logger. Ususally your module only depends on the slf4j API and therefore a
-
- :::plaintext
- java.lang.NoClassDefFoundError: org/slf4j/impl/StaticLoggerBinder
-
-is thrown - this often happens with slf4j but might also happen with other libraries.
-
-In these cases you should add a dependency to the missing class to the dependency list of the plugin, for example:
-
- :::xml
- <plugin>
- <groupId>org.apache.felix</groupId>
- <artifactId>maven-scr-plugin</artifactId>
- <version>...</version>
- <dependencies>
- <dependency>
- <groupId>org.slf4j</groupId>
- <artifactId>slf4j-simple</artifactId>
- <version>1.5.2</version>
- </dependency>
- </dependencies>
- ...
- </plugin>
-
-or in the special case of slf4j, using slf4j API 1.6 or higher solves the problem as well
-
-## No components or services available at runtime
-
-The SCR plugin generates a descriptor for Declarative Services (see OSGi compendium specification). Therefore at runtime, you must have an implementation of DS running in your OSGi framework, like the SCR implementation from the Apache Felix project.
-
-Otherwise your bundle might resolve fine, however no services are registered with the service registry and no components are activated.
\ No newline at end of file
diff --git a/modules/ROOT/pages/documentation/getting-started.mdtext b/modules/ROOT/pages/documentation/getting-started.mdtext
deleted file mode 100644
index 57763db..0000000
--- a/modules/ROOT/pages/documentation/getting-started.mdtext
+++ /dev/null
@@ -1,11 +0,0 @@
-Title: Getting Started
-
-For first-time users, here are a few links that might get you started more quickly:
-
-* [Downloads](https://felix.apache.org/downloads.cgi) - Go to the download page and download and extract the Felix release.
-* [Launching Felix]({{ refs.apache-felix-framework-usage-documentation.path }}) - Go to the Felix usage page to learn how to launch the Felix framework.
-* [OSGi tutorial]({{ refs.apache-felix-osgi-tutorial.path }}) - Go to the tutorial page to learn some OSGi basics.
-* [OSGi FAQ]({{ refs.apache-felix-osgi-faq.path }}) - Check out the OSGi FAQ for answers to common questions.
-* [Documentation]({{ refs.documentation.path }}) - Search the documentation pages for additional examples and presentations or subproject documentation to learn about specific subprojects.
-
-If you are unable to find the documentation you need, please ask on the [mailing lists]({{ refs.mailinglists.path }}). Also, feedback on improving the documentation and/or organization of this site is welcome.
diff --git a/modules/ROOT/pages/documentation/subprojects.mdtext b/modules/ROOT/pages/documentation/subprojects.mdtext
deleted file mode 100644
index 53fded2..0000000
--- a/modules/ROOT/pages/documentation/subprojects.mdtext
+++ /dev/null
@@ -1,61 +0,0 @@
-# Apache Felix Subproject Documentation
-
-## Building Apache Felix
-
-The Felix project is organized into subprojects, where each subproject targets a specific OSGi specification or OSGi-related technology. Most of these projects are in a single git repository, some have moved into separate git repositories.
-
-Use the below table of subprojects to find the git repository for that subproject, if you want to checkout the [main git repository](https://github.com/apache/felix-dev.git) with most subprojects use `git clone https://github.com/apache/felix-dev.git`, otherwise use the git repository mentioned in the table.
-
-To get started:
-
-- Most Apache Felix projects use Apache Maven as the build tool. Therefore, download and install the latest Apache Maven 3 release.
-- Check out or update the git repository (see above).
-- Go to the sub project you're interested in and type: "mvn clean install" to build it. If this project is not using Maven, refer to the docs for the subproject on how to build it.
-
-## Active subprojects
-
-|Name|Description|Source|
-|--|--|--|
-|[Atomos](https://github.com/apache/felix-atomos)|An OSGi module connector that enables loading bundles in a variety of environments, such as, jlink image, native-image, Android and flat class path. |[source](https://github.com/apache/felix-atomos)|
-|[Config Admin](https://github.com/apache/felix-dev/tree/master/configadmin)|An implementation of the [OSGi Configuration Admin service specification](https://osgi.org/specification/osgi.cmpn/7.0.0/service.cm.html) for managing bundle configuration properties.|[source](https://github.com/apache/felix-dev/tree/master/configadmin)|
-|[Dependency Manager](subprojects/apache-felix-dependency-manager.html)|An API-based component model to simplify OSGi-based development.|[source](https://github.com/apache/felix-dev/tree/master/dependencymanager)|
-|[Event Admin](subprojects/apache-felix-event-admin.html)|An implementation of the OSGi Event Admin service specification for event-based communication.|[source](https://github.com/apache/felix-dev/tree/master/eventadmin)|
-|[File Install](subprojects/apache-felix-file-install.html)|A simple, directory-based management agent for managing bundle deployment.|[source](https://github.com/apache/felix-dev/tree/master/fileinstall)|
-|[Framework](subprojects/apache-felix-framework.html)|An implementation of the OSGi R7 core framework.|[source](https://github.com/apache/felix-dev/tree/master/framework)|
-|[Framework Security](subprojects/apache-felix-framework-security.html)||[source](https://github.com/apache/felix-dev/tree/master/framework.security)|
-|[Gogo](subprojects/apache-felix-gogo.html)|An advanced shell for interacting with OSGi frameworks.|[source](https://github.com/apache/felix-dev/tree/master/gogo)|
-|[Health Checks](subprojects/apache-felix-healthchecks.html)|An extensible framework to monitor the status of the OSGi container at runtime.|[source](https://github.com/apache/felix-dev/tree/master/healthcheck)|
-|[HTTP Service](https://github.com/apache/felix-dev/tree/master/http)|An implementation of the [OSGi HTTP Whiteboard](https://osgi.org/specification/osgi.cmpn/7.0.0/service.http.whiteboard.html) and [Http Service specification](https://osgi.org/specification/osgi.cmpn/7.0.0/service.http.html).|[source](https://github.com/apache/felix-dev/tree/master/http)|
-|[Inventory Printer](subprojects/apache-felix-inventory.html)|A simple and extensible framework to retrieve inventory information about applications running in an OSGi Framework.|[source](https://github.com/apache/felix-dev/tree/master/inventory)|
-|[iPOJO](subprojects/apache-felix-ipojo.html)|A sophisticated service-oriented component model to simplify OSGi-based development.|[source](https://github.com/apache/felix-dev/tree/master/ipojo)|
-|[Log](subprojects/apache-felix-log.html)|A simple, memory-based implementation of the OSGi Log service specification.|[source](https://github.com/apache/felix-dev/tree/master/log)|
-|[Logback](subprojects/apache-felix-logback.html)|Apache Felix Logback is a small integration of the [Logback](https://logback.qos.ch/) backend with OSGi.|[source](https://github.com/apache/felix-dev/tree/master/logback)|
-|[Maven Bundle Plugin](subprojects/apache-felix-maven-bundle-plugin-bnd.html)|A Maven plugin to simplify building bundles.|[source](https://github.com/apache/felix-dev/tree/master/tools/maven-bundle-plugin)|
-|[Metatype](subprojects/apache-felix-metatype-service.html)|An implementation of the OSGi Metatype service to describe types needed by bundles.|[source](https://github.com/apache/felix-dev/tree/master/shell)|
-|[OSGi Bundle Repository](subprojects/apache-felix-osgi-bundle-repository.html)|A bundle repository service to simplify discovering and deploying bundles and their dependencies.|[source](https://github.com/apache/felix-dev/tree/master/org.osgi.service.obr)|
-|[Preferences Service](subprojects/apache-felix-preferences-service.html)|An implementation of the OSGi Preferences service specification for storing settings and preferences.|[source](https://github.com/apache/felix-dev/tree/master/preferences)|
-|[Remote Shell](subprojects/apache-felix-remote-shell.html)|A remote, text-based interface to the Apache Felix Shell.|[source](https://github.com/apache/felix-dev/tree/master/shell.remote)|
-|[Service Component Runtime](https://github.com/apache/felix-dev/tree/master/scr)|An implementation of the [OSGi Declarative Services specification](https://osgi.org/specification/osgi.cmpn/7.0.0/service.component.html) providing a service-oriented component model to simplify OSGi-based development.|[source](https://github.com/apache/felix-dev/tree/master/scr)|
-|[Shell](subprojects/apache-felix-shell.html)|A very simple shell service implemented as a bundle for interacting with an OSGi framework instance.|[source](https://github.com/apache/felix-dev/tree/master/shell)|
-|[Shell TUI](subprojects/apache-felix-shell-tui.html)|A simple, text-based interface to the Apache Felix Shell.|[source](https://github.com/apache/felix-dev/tree/master/shell.tui)|
-|[Web Console](subprojects/apache-felix-web-console.html)|A simple tool to inspect and manage OSGi framework instances using your favorite Web Browser.|[source](https://github.com/apache/felix-dev/tree/master/webconsole)|
-
-## Maintenance
-
-The following projects are in maintenance mode meaning there is no active development anymore.
-
-* [Auto Configuration](subprojects/apache-felix-autoconf.html)
-* [Commons](subprojects/apache-felix-commons.html)
-* [Deployment Admin](subprojects/apache-felix-deployment-admin.html)
-* [JAAS Support](subprojects/apache-felix-jaas.html)
-* [Lightweight HTTP Service](subprojects/apache-felix-lightweight-http-service.html)
-* [Manifest Generator (mangen)](subprojects/apache-felix-manifest-generator-mangen.html)
-* [Maven OBR Plugin](subprojects/apache-felix-maven-obr-plugin.html)
-* [Maven OSGi Plugin](subprojects/apache-felix-maven-osgi-plugin.html)
-* [Maven SCR Plugin](subprojects/apache-felix-maven-scr-plugin.html)
-* [MOSGi Managed OSGi framework](subprojects/mosgi-managed-osgi-framework.html)
-* [OSGi Core](subprojects/apache-felix-osgi-core.html)
-* [Script Console Plugin](subprojects/apache-felix-script-console-plugin.html)
-* [Serialization Framework](subprojects/apache-felix-serialization-framework.html)
-* [UPnP](subprojects/apache-felix-upnp.html)
-* [User Admin](subprojects/apache-felix-user-admin.html)
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-autoconf.mdtext b/modules/ROOT/pages/documentation/subprojects/apache-felix-autoconf.mdtext
deleted file mode 100644
index 869f6f8..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-autoconf.mdtext
+++ /dev/null
@@ -1,4 +0,0 @@
-Title: Apache Felix Auto Configuration
-
-This project implements the OSGi Auto Configuration specification; please consult the OSGi Compendium Specification chapter 115 for more information.
-
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-commons.mdtext b/modules/ROOT/pages/documentation/subprojects/apache-felix-commons.mdtext
deleted file mode 100644
index c5d220a..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-commons.mdtext
+++ /dev/null
@@ -1,68 +0,0 @@
-Title: Apache Felix Commons
-
-### Purpose
-
-Apache Felix Commons is a community effort to create OSGi bundle ("bundlized") versions of popular third-party open-source libraries. Today, OSGi developers must create bundles out of third-party libraries within their own development communities. The purpose of Felix Commons is to avoid duplicating the effort of bundle creation by sharing these bundlized artifacts. Our hope is that over time, the original developers of the third-party libraries can use these bundlized libraries to le [...]
-
-This web page will be used to document who is doing what and to provide pointers to more information.
-
-### How Can I Help?
-
-If you have libraries you have turned into bundles, then you can offer to contribute them. Additionally, you may request that a certain bundle be created. If you wish to submit a POM file for a specific library, you can attach it to a [Felix JIRA issue](http://issues.apache.org/jira/browse/Felix) under the "Felix Commons" component. For Apache purposes, contributing a bundle POM is the same as contributing code.
-
-### Getting Started
-
-In most cases, creating bundlized versions of a library is as simple as creating a POM file for the library using Felix' new [Maven Bundle Plugin]({{ refs.apache-felix-maven-bundle-plugin-bnd.path }}). The OSGi headers are non-intrusive. A JAR can be made in such a way that it runs on the Classpath as well as a bundle in an OSGi framework. In short you:
-1. Set the groupId to:
-
- <groupId>org.apache.felix.commons</groupId>
-
-1. Append "-osgi" to the name of the artifact:
-
- <artifactId>FOO-osgi</artifactId>
-
-1. Set the "packaging" to use the Maven Bundle Plugin:
-
- <packaging>bundle</packaging>
-
-1. Set any configuration options in the [Maven Bundle Plugin]({{ refs.apache-felix-maven-bundle-plugin-bnd.path }}).
-
-We recommend you read the longer [steps for converting a library to a bundle]({{ refs.creating-bundles-using-bnd.path }}).
-
-### Contributions
-
-| Library | Version | Description | Contributor | Grant OK | Committed |
-|--|--|--|--|--|--|
-| cglib | 2.0.2 | CGLib | Felix Meschberger | Yes | Yes |
-| commons-beanutils | 1.7.0 | BeanUtils | Felix Meschberger | Yes | Yes |
-| commons-codec | 1.2 | Codec | Felix Meschberger | Yes | Yes |
-| commons-configuration | 1.3 | Configuration | Felix Meschberger | Yes | Yes |
-| commons-digester | 1.8 | Digester | Felix Meschberger | Yes | Yes |
-| commons-el | 1.0 | EL | Felix Meschberger | Yes | Yes |
-| commons-fileupload | 1.1.1 | FileUpload | Felix Meschberger | Yes | Yes |
-| commons-httpclient | 3.0.1 | Client-side HTTP. | Felix Meschberger | Yes | Yes |
-| commons-io | 1.3 | IO | Felix Meschberger | Yes | Yes |
-| commons-lang | 2.2 | Lang | Felix Meschberger | Yes | Yes |
-| antlr | 2.7.6 | Parser generator. | John Conlon | Yes | Yes |
-| commons-collections | 3.2 | Data structures for collections. | John Conlon | Yes | Yes |
-| jzlib | 1.0.7 | Data compression library. | John Conlon | Yes | Yes |
-| commons-email | 1.0 | An API for sending email. | Felix Meschberger | Yes | Yes |
-
-### Supporting Libraries
-
-These are projects that have expressed support for the Felix Commons initiative and that are working directly within their respective projects to support OSGi.
-
-| Project | Description | Supporter(s) | More Information |
-|--|--|--|--|
-| Spring | | Adrian Colyer, Andy Piper | [Spring-OSGi](http://www.springframework.org/osgi) |
-| SLF4J | | Ceki Gülcü | [SLF4J](http://www.slf4j.org/) |
-| Logback | | Ceki Gülcü | [Logback](http://logback.qos.ch/) |
-| MINA | NIO framework | Trustin Lee | [DIRMINA-27](http://issues.apache.org/jira/browse/DIRMINA-27) |
-| HTTP Client | Client-side HTTP. | Roland Weber | [HTTPCLIENT-639](https://issues.apache.org/jira/browse/HTTPCLIENT-639) |
-| Apache OFBiz | Enterprise automation. | Christopher Snow | [Mailing list archives](http://mail-archives.apache.org/mod_mbox/incubator-felix-dev/200704.mbox/%3c8A31258D-1FB4-4F42-A145-94136D750EF0@coralms.com%3e) |
-| Jetty | Servlet engine. | Jan Bartel | Jetty 6.1.5 and onwards uses the 'maven-bundle-plugin'.|
-### Similar Efforts
-Eclipse Orbit - http://www.eclipse.org/orbit/
-{quote}
-... will provide a repository of bundled versions of third party libraries that are approved for use in one or more Eclipse projects.
-{quote}
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-commons/creating-bundles-using-bnd.mdtext b/modules/ROOT/pages/documentation/subprojects/apache-felix-commons/creating-bundles-using-bnd.mdtext
deleted file mode 100644
index 921f580..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-commons/creating-bundles-using-bnd.mdtext
+++ /dev/null
@@ -1,84 +0,0 @@
-Title: Creating Bundles Using BND
-
-##### Purpose
-
-Provide the list of steps required to create a library bundle by wrapping the library jar using bnd (http://bnd.bndtools.org/).
-
-##### Steps
-
-1. Use bnd to analyze the library jar (e.g., java -jar bnd-0.0.jar print path/to/FOO.jar)
-1. At the bottom of the bnd output, look for "Unresolved references to ..." which identify package dependencies. If found,
- a. Identifiy the library jars that provide the missing packages
- b. Recursively use this process on each dependency
-1. Create a directory that will be the project directory for the bundle (e.g., mkdir FOO-osgi)
-1. Copy the template pom.xml file to the bundle's project directory
-1. Edit the pom.xml file to tailor it for the library jar. Specifically,
- a. change artifactId
- b. verify description
- c. change version
- d. change FOO's library jar dependency (groupId, artifactId)
- e. add any other dependencies (from step 2b)
- f. change Export-Package
- g. change Private-Package or delete it if it's not needed
- h. All packages listed in step 1 should be in either Export-Package or Private-Package. Use the library's javadoc to identify the exported packages. The remaining packages should be private.
-1. Run "mvn package" to in the project directory to create the bundle
-1. Use bnd to verify the bundle's contents (e.g., java -jar bnd-0.0.jar print target/FOO-osgi-VERSION.jar)
-1. Run "mvn install" to install the bundle in the local repository
-
-##### Example POM
-
- <project
- xmlns="http://maven.apache.org/POM/4.0.0"
- xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
- xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
-
- <modelVersion>4.0.0</modelVersion>
- <groupId>org.apache.felix.commons</groupId>
- <artifactId>FOO-osgi</artifactId>
- <name>${pom.artifactId} bundle</name>
- <description>
- This bundle simply wraps FOO-${pom.version}.jar.
- </description>
- <version>X.Y</version>
- <packaging>bundle</packaging>
-
- <organization>
- <name>Apache Felix Project</name>
- <url>http://felix.apache.org/</url>
- </organization>
-
- <dependencies>
- <dependency>
- <groupId>FOO</groupId>
- <artifactId>FOO</artifactId>
- <version>${pom.version}</version>
- </dependency>
- </dependencies>
-
- <build>
- <plugins>
- <plugin>
- <groupId>org.apache.felix</groupId>
- <artifactId>maven-bundle-plugin</artifactId>
- <extensions>true</extensions>
- <configuration>
- <instructions>
- <Bundle-SymbolicName>${pom.artifactId}</Bundle-SymbolicName>
- <Export-Package>FOO</Export-Package>
- <Private-Package>FOO.impl</Private-Package>
- </instructions>
- </configuration>
- </plugin>
- </plugins>
- </build>
-
- </project>
-
-
-##### Resources
-
-Bnd - Bundle Tool
-http://bnd.bndtools.org/
-
-Bundle Plugin for Maven
-http://felix.apache.org/site/maven-bundle-plugin-bnd.html
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager.mdtext b/modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager.mdtext
deleted file mode 100644
index 0c95e19..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager.mdtext
+++ /dev/null
@@ -1,62 +0,0 @@
-Title: Apache Felix Dependency Manager
-
-Welcome to the Dependency Manager, a great bundle for managing your components and dependencies!
-
-## Introduction
-
-In a service oriented architecture, applications are built out of components that are packaged in bundles and interact through services. These components, that both publish services and depend on other services, form networks that are often dynamic in nature. That makes managing these dependencies something the developer needs to address.
-
-Whilst the OSGi framework provides the low-level building blocks to do that in the form of service listeners and trackers, these should not be used directly by developers. Instead, a more declarative approach works best, and the Dependency Manager provides this in the form of a declarative API and/or annotations that allow you to dynamically declare and change dependencies.
-
-On top of that, a set of OSGi design patterns are defined and supported that can be used as building blocks for more complex applications.
-
-The documentation for the dependency manager is split into three sections:
-
-1. Step-by-step tutorials which provide a good introduction to the technology and should get you started quickly.
-2. Overviews and guides that provide more in-depth knowledge about specific aspects of the dependency manager.
-3. Reference materials that describe all the individual nuts and bolts.
-
-Below is the full table of contents.
-
-## Table of Contents
-
-### Step-by-step Tutorials
-
-* [Getting started](apache-felix-dependency-manager/tutorials/getting-started.html)
-* [Leveraging the shell](apache-felix-dependency-manager/tutorials/leveraging-the-shell.html)
-* [Hello World example projects](apache-felix-dependency-manager/tutorials/sample-code.html)
-
-### Overviews and Guides
-
-* [History](apache-felix-dependency-manager/guides/history.html)
-* [Background](apache-felix-dependency-manager/guides/background.html)
-* [What's new in DM 4](apache-felix-dependency-manager/guides/whatsnew.html)
-* [What's new in release r15](apache-felix-dependency-manager/guides/whatsnew-r15.html)
-* [Bundles and dependencies](apache-felix-dependency-manager/guides/bundles-and-dependencies.html)
-* [Migrating from earlier versions](apache-felix-dependency-manager/guides/migrating-from-earlier-versions.html)
-* [Performance Tuning](apache-felix-dependency-manager/guides/performance-tuning.html)
-* [Development](apache-felix-dependency-manager/guides/development.html)
-* [Design Patterns](apache-felix-dependency-manager/guides/design-patterns.html)
-* [Resource Adapters](apache-felix-dependency-manager/guides/resources.html)
-* [Javadocs](apache-felix-dependency-manager/guides/javadocs.html)
-
-### Reference Guide
-
-* [Components](apache-felix-dependency-manager/reference/components.html)
- * [Singleton](apache-felix-dependency-manager/reference/component-singleton.html)
- * [Aspect](apache-felix-dependency-manager/reference/component-aspect.html)
- * [Adapter](apache-felix-dependency-manager/reference/component-adapter.html)
- * [Resource Adapter](apache-felix-dependency-manager/reference/component-resource-adapter.html)
- * [Bundle Adapter](apache-felix-dependency-manager/reference/component-bundle-adapter.html)
- * [Factory Configuration Adapter](apache-felix-dependency-manager/reference/component-factory-configuration-adapter.html)
-* [Dependencies](apache-felix-dependency-manager/reference/dependencies.html)
- * [Service](apache-felix-dependency-manager/reference/dependency-service.html)
- * [Configuration](apache-felix-dependency-manager/reference/dependency-configuration.html)
- * [Bundle](apache-felix-dependency-manager/reference/dependency-bundle.html)
- * [Resource](apache-felix-dependency-manager/reference/dependency-resource.html)
-* [Service Scopes](apache-felix-dependency-manager/reference/service-scopes.html)
-* [Dependency Manager Annotations](apache-felix-dependency-manager/reference/dm-annotations.html)
-* [Dependency Manager Lambda](apache-felix-dependency-manager/guides/dm-lambda.html)
-* [Thread Model](apache-felix-dependency-manager/reference/thread-model.html)
-* [External Links and Articles](apache-felix-dependency-manager/reference/external-links.html)
-
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/guides/annotations.mdtext b/modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/guides/annotations.mdtext
deleted file mode 100644
index cccc5b1..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/guides/annotations.mdtext
+++ /dev/null
@@ -1,347 +0,0 @@
-Title: Dependency Manager - Annotations
-
-This section presents a quick overview of the capabilities and usage of the DependencyManager Java annotations. In particular, we will recap the DependencyManager annotation architecture, and identify some simple usage scenarios using a SpellChecker
-sample application with annotated components. The application is available from the felix trunk, in the `dependencymanager/samples.annotation` subproject.
-
-## Architecture
-
-Instead of writing Activators which extends the DependencyActivatorBase class, service
-components can now be annotated using the annotations provided by the
-*org.apache.felix.dependencymanager.annotation* bundle. Annotations are not reflectively
-parsed at runtime; but we use a BND plugin which scans annotations at compilation phase
-and generates a compact metadata file in the bundle's META-INF/dependencymanager
-subdirectory. This has the following benefits:
-
-- JVM startup speed is not affected, and class files are not parsed when the framework is starting
-- Moreover, since the annotations are not retained by the VM at runtime, it is not necessary to load the annotation API bundle at runtime.
-
-At runtime, the metadata generated during the compilation phase are processed by a
-specific DependencyManager Runtime bundle, which is in charge of managing the service
-component lifecycle and dependencies. This Runtime bundle actually uses the
-DependencyManager programmatic API in order to manage the annotated components.
-Annotated components can then be inspected with the DependencyManager Gogo shell, as it is
-the case with DM components declared through the programmatic DM API.
-
-## Registering a Service
-
-To register a service, your can annotate your class with a *@Component* annotation, and
-an instance of your class will be registered under all directly implemented interfaces
-into the OSGi registry. You can however take control on the interfaces to be exposed, and
-in this case, you can use the *provides* attribute, which takes a list of classes to
-expose from the registry.
-
-To illustrate this, we are now introducing a SpellChecker application which provides a
-Felix "spellcheck" Gogo shell command. Gogo is the new shell supported by the Felix
-Framework. Our "spellcheck" command is implemented by the SpellChecker component which
-accepts a string as parameter. This string is then checked for proper existence. To do
-the checking, The SpellChecker class has a required/multiple (1..N) dependency over
-every available DictionaryService services. Such DictionaryService represents a real
-dictionary for a given language (it has a *lang* service property), and is
-configurable/instantiable from the OSGi Configuration Admin Service.
-
-Configuration Admin service provides a mechanism for configuring components
-(using ManagedService interfaces), and WebConsole actually implements this service.
-ConfigAdmin is also able to instantiate some Services (using ManagedServiceFactory
-interfaces).
-
-Now we have introduced the background, here is the SpellCheck component:
-
- :::java
- @Component(provides={SpellChecker.class},
- properties={@Property(name=CommandProcessor.COMMAND_SCOPE, value="dmsample.annotation"),
- @Property(name=CommandProcessor.COMMAND_FUNCTION, values={"spellcheck"})})
- public class SpellChecker {
- // --- Gogo Shell command
-
- @Descriptor("checks if word is found from an available dictionary")
- public void spellcheck(@Descriptor("the word to check")String word) {
- // Check the proper existence of the word parameter, using injected DictionaryService instances
- // ...
- }
- }
-
-
-In the code above, you see that the SpellCheck is annotated with the *@Component*
-annotation. Gogo runtime does not required shell commands to implement a specific
-interface. Commands just have to register some Pojos in the OSGi registry, but the only
-thing required is to provide the Pojos with two service properties ( COMMAND_SCOPE, and
-COMMAND_FUNCTION) which will be used by the Gogo runtime when instropecting the Pojo
-for invoking the proper functions.
-
-
-So, coming back to the sample code, the SpellChecker class registers itself into the OSGi registry, using the *provides* attribute, which just refer to our SpellChecker class, and the two mandatory Gogo service properties are also specified using the *@Property* annotation. It is not shown here, but service properties can also be provided dynamically from a method that can return a Map, and annotated with the *@Start* lifecycle callback, but we will see this feature in a another section.
-
-## Depending on a Service
-
-Our SpellChecker component can expose itself as a Gogo shell command, but before being
-registered into the OSGi registry, we also need to be injected with two dependencies:
-one required dependency (at minimum) on a DictionaryService, and another optional one on
-a LogService. First, let's look at the DictionaryService, which is a simple interface:
-
- :::java
- public interface DictionaryService {
- /**
- * Check for the existence of a word.
- * @param word the word to be checked.
- * @return true if the word is in the dictionary, false otherwise.
- */
- public boolean checkWord(String word);
- }
-
-And here is our previous SpellChecker component, augmented with two new ServiceDependency
-annotations:
-
- :::java
- @Component(provides={SpellChecker.class},
- properties={@Property(name=CommandProcessor.COMMAND_SCOPE, value="dmsample.annotation"),
- @Property(name=CommandProcessor.COMMAND_FUNCTION, values={"spellcheck"})})
- public class SpellChecker {
- @ServiceDependency(required = false)
- private LogService m_log;
-
- private CopyOnWriteArrayList<DictionaryService> m_dictionaries = new CopyOnWriteArrayList<DictionaryService>();
-
- @ServiceDependency(removed = "removeDictionary")
- protected void addDictionary(DictionaryService dictionary) {
- m_dictionaries.add(dictionary);
- }
-
- protected void removeDictionary(DictionaryService dictionary) {
- m_dictionaries.remove(dictionary);
- }
-
- // --- Gogo Shell command
-
- @Descriptor("checks if word is found from an available dictionary")
- public void spellcheck(@Descriptor("the word to check")String word) {
- m_log.log(LogService.LOG_INFO, "Checking spelling of word \"" + word
- + "\" using the following dictionaries: " + m_dictionaries);
-
- for (DictionaryService dictionary : m_dictionaries) {
- if (dictionary.checkWord(word)) {
- System.out.println("word " + word + " is correct");
- return;
- }
- }
- System.err.println("word " + word + " is incorrect");
- }
- }
-
-There are many things to describe in the code above:
-
-First, we define an optional dependency on the LogService, by defining a
-*@ServiceDependency(required=false)* annotation on our m_logService field: This
-means that our component will be provided into the OSGi registry even if there
-is no available LogService, and in this case, a NullObject will be injected in
-our class field;
-This will avoid to check for nullability, when using the m_logService field.
-All optional dependencies applied on class fields are injected with a
-NullObject (when not available).
-The NullObject can be invoked and will do nothing. For a lot of cases that is
-good enough to handle optional dependencies. But when you really want to check
-if an optional service is there or not, then you have to apply the optional
-dependency on a callback method, which will be called when the optional
-service is available.
-
-Next comes the dependency on the DictionaryService. Here, we use a *ServiceDependency*
-annotation, but this time we apply it on a method (*add/removeDictionary*). There is no
-need to specify the "*required=true*" flag because it is the default value. Notice that
-this behavior is different from the API, where service dependencies are optional by default
-. We use a callback method, because we just need to register all available
-DictionaryService services in our dictionary list, which is used when checking word
-existence. This list is a copy on write list because the dependency may be injected at
-any time, possibly from another thread. So, using a copy on write list avoid us to use synchronized methods.
-
-## Creating a Service from ConfigAdmin
-
-The *@Component* annotation is not the only one for creating services. Another one is
-the *@FactoryConfigurationAdapterService* annotation which allows to instantiate many
-instances of the same annotated service class from ConfigAdmin (and WebConsole).
-To illustrate this, let's take a look at our DictionaryImpl class which is part of the
-SpellChecker sample. This service is required by the SpellChecker component, when
-checking for proper word existence. And you can instantiate as many DictionaryService as
-you want, from ConfigAdmin ...
-
- :::java
- @FactoryConfigurationAdapterService(factoryPid="DictionaryImplFactoryPid", updated="updated")
- public class DictionaryImpl implements DictionaryService {
- /**
- * We store all configured words in a thread-safe data structure, because ConfigAdmin
- * may invoke our updated method at any time.
- */
- private final CopyOnWriteArrayList<String> m_words = new CopyOnWriteArrayList<String>();
-
- /**
- * Our Dictionary language.
- */
- private String m_lang;
-
- /**
- * Our service will be initialized from ConfigAdmin, and we also handle updates in this method.
- * @param config The configuration where we'll lookup our words list (key="words").
- */
- protected void updated(Dictionary<String, ?> config) {
- m_lang = (String) config.get("lang");
- m_words.clear();
- String[] words = (String[]) config.get("words");
- for (String word : words) {
- m_words.add(word);
- }
- }
-
- /**
- * Check if a word exists if the list of words we have been configured from ConfigAdmin/WebConsole.
- */
- public boolean checkWord(String word) {
- return m_words.contains(word);
- }
- }
-
-Our DictionaryImpl class implements a DictionaryService, and our class will be registered
-under that interface (all directly implemented interfaces are used when registering the
-service, but you can select some others using the *provides* attribute).
-The *@FactoryConfigurationAdapterService* annotation will instantiate our service for
-each configuration created from web console (and matching our "DictionaryImplFactoryPid"
-factoryPid).
-
-We also use the *updated* attribute, which specifies a callback method which will handle
-properties configured by ConfigAdmin. The updated callback will also be called when our
-properties are changing. Every properties are propagated to our service properties,
-unless the properties starting with a dot ("."). Configuration properties starting with
-a dot (".") are considered private and are not propagated.
-
-Notice that you can mix standard bnd metatype annotations with DM annotations, in order
-describe configurations meta data (default values, property labels, etc ... see http://bnd.bndtools.org/chapters/210-metatype.html).
-So, let's revisit our DisctionaryImpl service, but this time with meta type support:
-
-First, we define an interface for describing our configuration metadata, with bnd metatype annotations:
-
- :::java
- import java.util.List;
-
- import aQute.bnd.annotation.metatype.Meta.AD;
- import aQute.bnd.annotation.metatype.Meta.OCD;
-
- @OCD(name="Spell Checker Dictionary (annotation)", factory = true, description = "Declare here some Dictionary instances")
- public interface DictionaryConfiguration {
- @AD(description = "Describes the dictionary language", deflt = "en")
- String lang();
-
- @AD(description = "Declare here the list of words supported by this dictionary. This properties starts with a Dot and won't be propagated with Dictionary OSGi service properties")
- List<String> words();
- }
-
-Next, here is our DictionaryImpl that will use the bnd "Configurable" helper in order to retrieve the actual configuration:
-
- :::java
- import org.apache.felix.dm.annotation.api.FactoryConfigurationAdapterService;
- import org.apache.felix.dm.annotation.api.ServiceDependency;
- import org.apache.felix.dm.annotation.api.Start;
- import org.osgi.service.log.LogService;
- import aQute.bnd.annotation.metatype.Configurable;
-
- @FactoryConfigurationAdapterService(factoryPidClass = DictionaryConfiguration.class, propagate = true, updated = "updated")
- public class DictionaryImpl implements DictionaryService {
- private final CopyOnWriteArrayList<String> m_words = new CopyOnWriteArrayList<String>();
- private String m_lang;
-
- protected void updated(Dictionary<String, ?> config) {
- if (config != null) {
- // use bnd "Configurable" helper to get an implementation for our DictionaryConfiguration.
- DictionaryConfiguration cnf =
- Configurable.createConfigurable(DictionaryConfiguration.class, config);
-
- m_lang = cnf.lang();
- m_words.clear();
- for (String word : cnf.words()) {
- m_words.add(word);
- }
- }
- }
-
- public boolean checkWord(String word) {
- return m_words.contains(word);
- }
- }
-
-
-## Providing an Aspect
-
-As we have seen in the previous section, there are many annotations that can be used
-to specify a service. Another one is the *@AspectService* annotation. This annotation
-allows to *decorate* an existing service in order to add certain "capabilities" to it,
-like adding a specific caching mechanism to a storage service or implementing logging.
-Aspects can be plugged to an existing service at runtime, and can also be removed
-dynamically. This is transparent, and the clients using the existing service are not
-interrupted, they are just rebound with the aspect service.
-
-As an example, we go back to our SpellChecker application, and we are now looking at the
-DictionaryAspect class. This class uses the *@Aspect* Service annotation in
-order to add some custom words to an English DictionaryService (with the
-service property lang=en).
-The Extra words to add to the English Dictionary will be configured from
-ConfigAdmin. That's why the class also uses a *@ConfigurationDependency* annotation:
-
- :::java
- @AspectService(ranking = 10, filter = "(lang=en)")
- public class DictionaryAspect implements DictionaryService {
- /**
- * This is the service this aspect is applying to.
- */
- private volatile DictionaryService m_originalDictionary;
-
- /**
- * We store all configured words in a thread-safe data structure, because ConfigAdmin may
- * invoke our updated method at any time.
- */
- private CopyOnWriteArrayList<String> m_words = new CopyOnWriteArrayList<String>();
-
- /**
- * Defines a configuration dependency for retrieving our english custom words (by default,
- * our PID is our full class name).
- */
- @ConfigurationDependency
- protected void updated(Dictionary<String, ?> config) {
- m_words.clear();
- String[] words = (String[]) config.get("words");
- for (String word : words) {
- m_words.add(word);
- }
- }
-
- /**
- * Checks if a word is found from our custom word list. if not, delegate to the decorated
- * dictionary.
- */
- public boolean checkWord(String word) {
- if (m_words.contains(word)) {
- return true;
- }
- return m_originalDictionary.checkWord(word);
- }
- }
-
-The annotation does the following: because our class implements the DictionaryService
-contract, it will instantiate our service each time it finds another existing
-DictionaryService matching the filter attribute we provide in the annotation
-(filter="(lang=en)"). And it will inject the existing service in our
-m_originalDictionary field, by reflection. But we can also specify a field attribute in
-the annotation, if we want to explicitly inject the existing service in a given class
-field. So, any client depending on an English DictionaryService will be transparently
-rebound to our aspect Dictionary.
-
-In the Annotation, also notice the *ranking* attribute: It is the level used to organize
-the aspect chain ordering (multiple aspects may be applied on a given service).
-
-
-The *ConfigurationDependency* is another dependency that we have not seen before: it is
-used to configure the extra English words from ConfigAdmin. This annotation normally
-requires a pid parameter, which is a persistent identifier uniquely identifying our
-component, but by default, the pid is set to the fully qualified name of our class.
-
-## How to run the sample code
-
-Just import the Dependency source distribution in bndtools and check the following samples:
-
-* org.apache.felix.dependencymanager.samples/src/org/apache/felix/dependencymanager/samples/dictionary/annot/README
-* org.apache.felix.dependencymanager.samples/src/org/apache/felix/dependencymanager/samples/dictionary/api/README
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/guides/background.mdtext b/modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/guides/background.mdtext
deleted file mode 100644
index e9b9eb9..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/guides/background.mdtext
+++ /dev/null
@@ -1,28 +0,0 @@
-Title: Dependency Manager - Background
-
-## Background
-
-In an OSGi framework, services are deployed using bundles and these bundles feature two types of dependencies:
-
-1. Package dependencies. A bundle can export a package which others import. These dependencies, although dynamic, are relatively easy to handle and the whole resolution process is handled by the OSGi framework for you.
-1. Service dependencies. Services, implemented by components inside of bundles, can have their own life cycle within that of their containing bundle and therefore can be registered and unregistered at any time. Other components often depend on these services and need to deal with changes in their availability.
-
-When you look at dependency management, there are two aspects you need to take into account:
-
-The first is managing software configurations. This means you need to manage the dependencies from a configuration standpoint. What you are managing are bundles, since those are the units of deployment. What you need to manage are the package and service dependencies between bundles. Package dependencies are always visible by examining the bundle manifest and when a bundle is installed the framework will try to resolve such dependencies before that bundle can even be started. Service dep [...]
-
-The second is managing service dependencies at runtime. As mentioned before, a service oriented architecture is dynamic by design, so your implementation should be able to deal with this. Bundles can start in any order and any service can go away or be replaced by a different implementation at any point in time. OSGi itself offers basic assistance for tracking services. You can track them yourself by registering as a service listener. A slightly more advanced way is to create a service t [...]
-
-In real implementations, you are probably going to track multiple services. Using service trackers in such a scenario has the tendency to result in dependency logic that is entangled in the implementation instead of being expressed in a declarative way. Using a declarative way to specify dependencies has clear advantages when it comes to monitoring and managing them, a task that becomes more and more important in modern, federated, service oriented environments.
-
-The Dependency Manager provides you with the right building blocks to declaratively specify dependencies using a straightforward Java API that is easy to maintain and refactor.
-
-## Design Goals
-
-The goals that drove the design of the dependency manager are:
-
-* Provide a clean separation between a component implementation and the "glue" that binds it to the OSGi framework. The component implementation should not have to contain any OSGi specific code. In other words, it should be a POJO (Plain Old Java Object).
-* Minimize the amount of code that needs to be written. The specification and management of dependencies should be automated as much as possible, whilst still providing enough flexibility to customize the system.
-* Be extensible. Even though the core bundle provides a lot of different dependencies already, you should be able to add your own types of dependencies easily.
-* Easy to monitor and debug. Being a dynamic system, it's important to be able to see what the state of all components and dependencies are at any point in time.
-* Supporting powerful high level design patterns. When building real-world applications, more complex patterns need to be used, such as aspects and adapters. Support for these needs to be built into the core.
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/guides/bundles-and-dependencies.mdtext b/modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/guides/bundles-and-dependencies.mdtext
deleted file mode 100644
index 6a05899..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/guides/bundles-and-dependencies.mdtext
+++ /dev/null
@@ -1,23 +0,0 @@
-Title: Dependency Manager - Bundles and Dependencies
-
-The dependency manager project consists of the following bundles. For each bundle, we also list its dependencies in the form of package imports, plus a suggestion on a bundle that resolves them.
-
-* `org.apache.felix.dependencymanager` - 4.0.0 - This is the core bundle, containing the code for working with the Java based API.
- * org.osgi.framework;version="[1.5,2)" - provided by the OSGi framework itself
- * org.osgi.util.tracker;version="[1.4,2)" - provided by the OSGi framework itself
- * org.osgi.service.cm;version="[1.3,2)" - provided by Apache Felix Configuration Admin, or the OSGi Compendium bundle
- * org.osgi.service.metatype;version="[1.1,2)" - provided by Apache Felix Metatype, or the OSGi Compendium bundle
-
-* `org.apache.felix.dependencymanager.runtime` - 4.0.0 - This is the runtime bundle that you need, together with the core bundle above, if you want to work with annotations.
- * org.osgi.framework;version="[1.5,2)" - provided by the OSGi framework itself
- * org.osgi.service.packageadmin;version="[1.2,2)" - provided by the OSGi framework itself
- * org.apache.felix.dm;version="[4,5)" - provided by the core bundle
- * org.apache.felix.dm.context;version="[4,5)" - provided by the core bundle
- * org.osgi.service.log;version="[1.3,2)" - provided by Apache Felix Log Service, or the OSGi Compendium bundle
-
-* `org.apache.felix.dependencymanager.shell` - 4.0.0 - This is the shell bundle. It only contains the shell commands, so you need it if you want to use those.
- * org.apache.felix.dm;version="[4.0,5)" - provided by the core bundle
- * org.apache.felix.service.command;version="[0.10,1)";status=provisional
- * org.osgi.framework;version="[1.5,2)" - provided by the OSGi framework itself
-* `org.apache.felix.dependencymanager.annotation` - 4.0.0 - This is not a bundle, but code you need when compiling your bundles that contain annotations. Notice that the annotation jar contains OSGi headers in its manifest, but this bundle is not meant to be included in the OSGi framework runtime
-(the OSGi headers are only present in order to allow you to drag and drop the dependency manager annotation bundle in your buildpath project).
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/guides/design-patterns.mdtext b/modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/guides/design-patterns.mdtext
deleted file mode 100644
index 361434f..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/guides/design-patterns.mdtext
+++ /dev/null
@@ -1,161 +0,0 @@
-Title: Dependency Manager - Design Patterns
-
-This section lists a couple of design patterns as they can be applied in an OSGi context.
-
-## Singleton Service
-
-Provides a service as long as its dependencies are resolved.
-
-### Motivation
-
-In a dynamic framework, services can come and go. Components that publish a service are often themselves dependent on other services to perform their task. In such cases, they have a dependency on those services and it makes sense to only publish their own services when these dependencies are available. Being able to declare such dependencies in code ensures consistent life cycle behavior.
-
-### Structure
-
-<img src="./diagrams/singleton.png" alt="Singleton" style="width: 190px"/>
-
-### Code Example
-
-
- public class Activator extends DependencyActivatorBase {
- public void init(BundleContext context, DependencyManager manager) throws Exception {
- manager.add(createComponent()
- .setInterface(UserStore.class, new Properties() {{ put("store.id", "users"); }})
- .setImplementation(UserStoreImpl.class)
- .add(createServiceDependency()
- .setService(Store.class)
- .setRequired(true)
- )
- .add(createServiceDependency()
- .setService(LogService.class)
- .setRequired(false)
- )
- );
- }
-
- public void destroy(BundleContext context, DependencyManager manager) throws Exception {}
- }
-
-
-## Aspect Service
-
-Provides an aspect on top of a specific type of service.
-
-### Motivation
-
-In aspect oriented programming, supporting functions are isolated from the main application's business logic. This increases modularity at the source level by allowing the separation of cross-cutting concerns. In OSGi we want to extend this modularity to the runtime, therefore we implement aspects to work on certain services, where the aspect itself publishes that same service but (usually) with a higher priority. This allows you to dynamically add and remove aspects.
-
-### Structure
-
-<img src="./diagrams/aspect.png" alt="Aspect" style="width: 190px"/>
-
-### Code Example
-
-
- public class Activator extends DependencyActivatorBase {
- public void init(BundleContext context, DependencyManager manager) throws Exception {
- manager.add(createAspectService(Manageable.class, "(monitor=true)", 50)
- .setImplementation(ManageableMonitor.class)
- );
- }
-
- public void destroy(BundleContext context, DependencyManager manager) throws Exception {}
- }
-
- public interface Manageable {
- public void setProperty(String key, String value);
- }
-
- public class ManageableMonitor implements Manageable {
- private volatile Manageable m_manageable;
-
- public void setProperty(String key, String value) {
- System.out.println("Someone set " + key + " to " + value);
- m_manageable.setProperty(key, value);
- }
- }
-
-
-## Adapter Service
-
-Provides an adapter for a specific type of service.
-
-### Motivation
-
-Like with aspects, sometimes you want to create adapters for certain services, which add certain behavior that results in the publication of (in this case) a different service. Adapters can dynamically be added and removed and allow you to keep your basic services implementations clean and simple, adding extra features on top of them in a modular way.
-
-### Structure
-
-<img src="./diagrams/adapter.png" alt="Adapter" style="width: 190px"/>
-
-### Code Example
-
-
- public class Activator extends DependencyActivatorBase {
- public void init(BundleContext context, DependencyManager manager) throws Exception {
- manager.add(createAdapterService(Manageable.class, "(publish=servlet)")
- .setInterface(HttpServlet.class.getName(), null)
- .setImplementation(ManageableServlet.class)
- );
- }
-
- public void destroy(BundleContext context, DependencyManager manager) throws Exception {}
- }
-
- public interface Manageable {
- public void setProperty(String key, String value);
- }
-
- public class ManageableServlet implements HttpServlet {
- private volatile Manageable m_manageable;
-
- public void doPost(HttpRequest req, HttpResponse response) {
- String key = req.getProperty("key");
- String value = req.getProperty("value");
- m_manageable.setProperty(key, value);
- }
- }
-
-
-## Resource Adapter Service
-
-Provides an adapter for a specific type of resource.
-
-### Motivation
-
-Resource adapters are similar to normal adapters, but instead of requiring a service, they require a resource and provide a service on top of it. Resources are an abstraction that is introduced by the dependency manager, represented as a URL. They can be implemented to serve resources embedded in bundles, somewhere on a file system or in a content repository or database.
-
-### Structure
-
-<img src="./diagrams/resourceadapter.png" alt="Singleton" style="width: 180px"/>
-
-## Temporal Dependency
-
-Provides a proxy that hides the service dynamics of a dependency, even if it disappears for a short time.
-
-### Motivation
-
-As a service consumer, you sometimes do not want to deal with the dynamics of services and the fact that they tend to go away for short periods of time whilst their hosting bundle gets updated. A temporal dependency provides you with a proxy that hides these dynamics and blocks your calls if you try to invoke a method on a service that is currently "updating". The maximum time to wait is configurable and you will get an exception if no new service becomes available before that time.
-
-### Structure
-
-## Null Object
-
-Provides an implementation of an object that does nothing and can be used in the absence of the real object.
-
-### Motivation
-
-When a component depends on a service, but the dependency is optional, it means that it will use this service when available, but it can still operate if it's not. Constantly checking in your code if a service is actually available tends to lead to code with a lot of "`if (service != null) service.invoke();`" constructions which do not help with code readability. Instead, the dependency manager offers you a mechanism where it will inject null objects for services that are currently not a [...]
-
-### Structure
-
-## Whiteboard
-
-Handles listeners by leveraging the OSGi service registry to publish and look them up.
-
-### Motivation
-
-The traditional model for dealing with listeners in Java needlessly complicates things in an OSGi context. Instead of having listeners registering themselves with the component that will invoke them on any change, a listener simply registers itself in the service registry and the component will do a lookup of all relevant services. This is explained in more detail on the OSGi.org wiki in the ["Listeners considered harmful: the 'whiteboard' pattern"](http://www.osgi.org/wiki/uploads/Links [...]
-
-### Structure
-
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/guides/development.mdtext b/modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/guides/development.mdtext
deleted file mode 100644
index 5fac8c8..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/guides/development.mdtext
+++ /dev/null
@@ -1,48 +0,0 @@
-Title: Dependency Manager - Development
-
-When downloading or checking out the source code, please also consult release/resources/src/README.src for up to date instructions on how to build that particular version.
-
-## Prerequisites
-
-If you are using a corporate http proxy, you should set the following environment variables:
-
- $ export GRADLE_OPTS="-Dhttp.proxyHost=<your proxy ip> -Dhttp.proxyPort=<your proxy port> -Dhttps.proxyHost=<your proxy ip> -Dhttps.proxyPort=<your proxy port>"
- $ export http_proxy=<your proxy ip>:<your proxy port>
- $ export https_proxy=<your proxy ip>:<your proxy port>
-
-## Compilation Using gradle:
-
-- Install latest Java 8 (the dm libraries has been built and tested with java 1.8.0_74)
-
-- Compile Dependendency Manager annotations bndtools plugin:
-
- $ ./gradlew org.apache.felix.dependencymanager.annotation:jar
-
-- Compile all other bundles:
-
- $ ./gradlew jar
-
-- Run junit tests:
-
- $ ./gradlew test
-
-- Run integration tests:
-
- $ ./gradlew check
-
-## Compilation Using Eclipse:
-
-- Install Latest Eclipse Mars.
-- Use the dependency manager folder as the root of your workspace.
-- Configure two JREs for Java 8:
- * Go to Windows -> Preferences -> Java -> Installed JREs
- * Add your jdk8 JRE
-- Install BndTools 3.4.0 or later version and (optionally) a subversion plugin for Eclipse.
-- Open BndTools perspective
-- Import Dependency Manager into Eclipse, and compile everything
-- if it's the first time you import the project into eclipse, it may happen that some modules that requires the Dependency Manager Annotations bnd plugin don't compile: It's a know issue. To work around, restart eclipse and rebuild every modules.
-- Click on org.apache.felix.dependencymanager project and run it as "JUnit test".
-- Click on org.apache.felix.dependencymanager.shell and run it as "JUnit test"
-- Click on org.apache.felix.dependencymanager.itest and run it as "Bnd OSGi Test Launcher (Junit)".
-- Click on org.apache.felix.dependencymanager.runtime.itest and run it as ""Bnd OSGi Test Launcer (Junit)".
-- Click on org.apache.felix.dependencymanager.lambda.itest and run it as ""Bnd OSGi Test Launcer (Junit)".
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/guides/dm-lambda.mdtext b/modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/guides/dm-lambda.mdtext
deleted file mode 100644
index fa2f7c6..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/guides/dm-lambda.mdtext
+++ /dev/null
@@ -1,943 +0,0 @@
-Title: Dependency Manager Lambda
-
-----------
-
-**Welcome to Felix Dependency Manager Lambda.**
-
-## Introduction
-
-Since the R8 version, a new dm-lambda library has been introduced in the DM distribution. This new library allows to programmatically declare OSGi components
-using a new style based on java8 lambda expressions and other goodies like method references.
-
-The new library is based on the `builder` design pattern applied to java8 lambdas. Basically, you call a chain of methods from a
-fluent `builder`, and at the end of the chain, you call "`build()`" which returns the actual DM objects that you already know from
-the original DM API.
-We'll see later that using lambdas avoids to call the last "`build`" method and allows to automatically add the constructed DM Component into the
-DependencyManager object.
-
-Please notice that using the dm-lambda library requires the usage of a recent Java8 jvm (the library has been tested with java version "1.8.0_74").
-
-## Comparing two activators using old and new API:
-
-Before presenting the new API, let's get a jump start and dive into a comparison between the old and new API: assume we have a `ServiceConsumer` which depends on the following services:
-
-- a required dependency on `ServiceProvider` service with a "`(p1=v1)`" filter. The dependency is injected in the "`ServiceConsumer.setProvider()`" method.
-- a Configuration with pid="`org.apache.felix.dm.lambda.samples.hello.ServiceConsumer`".
-
-Now assume we have `ServiceProvider` provided with p1="v1" and p2=123 service properties; and the provider also depends on:
-
-- a required `LogService` service (injected in class fields).
-- a required `EventAdmin` service (injected in class fields).
-
-Then we have the following typical Activator (we define both components in the same Activator for simplicity):
-
- :::java
- import org.apache.felix.dm.DependencyActivatorBase;
- ...
-
- public class Activator extends DependencyActivatorBase {
- @Override
- public void init(BundleContext ctx, DependencyManager dm) throws Exception {
- // Declare our Consumer component
-
- Component consumer = createComponent()
- .setImplementation(ServiceConsumer.class)
- .add(createServiceDependency().setService(ServiceProvider.class, "(p1=v1)").setRequired(true).setCallbacks("setProvider", null))
- .add(createConfigurationDependency().setPid(ServiceConsumer.class.getName()));
- dm.add(consumer);
-
- // Declare our ServiceProvider service component
-
- Properties properties = new Properties();
- Properties.put("p1", "v1");
- properties.put("p2", 123);
- Component provider = createComponent()
- .setImplementation(ServiceProviderImpl.class)
- .setInterface(ServiceProvider.class.getName(), properties)
- .add(createServiceDependency().setService(LogService.class).setRequired(true))
- .add(createServiceDependency().setService(EventAdmin.class, null).setRequired(true));
- dm.add(provider);
- }
- }
-
-Now, let's rework the above example, using the new dm-lambda API:
-
- :::java
- import org.apache.felix.dm.lambda.DependencyManagerActivator;
- ...
-
- public class Activator extends DependencyManagerActivator {
- @Override
- public void init(BundleContext ctx, DependencyManager dm) throws Exception {
- // Declare our Consumer component
-
- component(comp -> comp.impl(ServiceConsumer.class)
- .withSvc(ServiceProvider.class, svc -> svc.required().filter("(p1=v1)").add(ServiceConsumer::setProvider))
- .withCnf(ServiceConsumer.class.getName()));
-
- // Declare our ServiceProvider service component:
-
- component(comp -> comp.impl(ServiceProviderImpl.class)
- .provides(ServiceProvider.class, p1 -> "v1", p2 -> 123)
- .withSvc(true, LogService.class, EventAdmin.class));
- }
-
-# Principle
-
-The new API is provided by the `org.apache.felix.dependencymanager.lambda.jar` bundle. The following builders are currently supported:
-
-- ComponentBuilder: it is used to build org.apache.felix.dm.Component from original DM API.
-- ServiceDependencyBuilder: builds org.apache.felix.dm.ServiceDependency from original DM API.
-- ConfigurationDependencyBuiler: builds org.apache.felix.dm.ConfigurationDependency from original DM API.
-- BundleAdapterBuilder: builds a bundle adapter component from the original DM API.
-- ServiceAdapterBuilder.java: builds a DM service adapter from the original DM API.
-- FactoryPidAdapterBuilder: builds a DM factory pid adapter from the original DM API.
-- FutureDependencyBuilder: it's a new feature allowing to "wait for" an asynchronous event represented by a standard jdk8 `CompletableFuture` object.
-
-(There is currently no builders for DM ResourceDependency and ResourceAdapter objects, but they will be supported soon).
-
-There are two ways to use these builders:
-
-You can first instantiate builders using some of the convenient factory methods available from the DependencyManagerActivator class, which is the new base class
-for dm-lambda activators:
-
- :::java
- import org.apache.felix.dm.lambda.DependencyManagerActivator;
- import org.apache.felix.dm.lambda.ComponentBuilder;
- import org.apache.felix.dm.Component;
-
- public class Activator extends DependencyManagerActivator {
- @Override
- public void init(BundleContext ctx, DependencyManager dm) throws Exception {
- ComponentBuilder builder = component();
- Component comp = builder.impl(Hello.class).build();
- dm.add(comp);
- }
- }
-
-The `component()` method returns a `ComponentBuilder` and the call to `build` at the end of the method calls chain returns the actual DM Component object.
-
-Here is a shorter version:
-
- :::java
- import org.apache.felix.dm.lambda.DependencyManagerActivator;
- import org.apache.felix.dm.Component;
-
- public class Activator extends DependencyManagerActivator {
- @Override
- public void init(BundleContext ctx, DependencyManager dm) throws Exception {
- Component comp = component().impl(Hello.class).build());
- dm.add(comp);
- }
- }
-
-
-Now, most of the time, in an Activator you usually create a Component and immediately add it to the `dm` object.
-So, in order to reduce the code size, you can then use a component() method that accepts a lambda which takes as
-argument a `Consumer<ComponentBuilder>` parameter.
-So, the lambda has just to invoke the chain of necessary methods from the builder, without having to call the last "`build`" method.
-The constructed Component is then automatically added to the `dm` object.
-
-The following is the same as above, using a `consumer<ComponentBuilder>` lambda expression:
-
- :::java
- import org.apache.felix.dm.lambda.DependencyManagerActivator;
- import org.apache.felix.dm.lambda.ComponentBuilder;
-
- public class Activator extends DependencyManagerActivator {
- @Override
- public void init(BundleContext ctx, DependencyManager dm) throws Exception {
- component((ComponentBuilder comp) -> comp.impl(Hello.class));
- }
- }
-
-Here is a more concise version where the type of the lambda parameter is not declared:
-
- :::java
- import org.apache.felix.dm.lambda.DependencyManagerActivator;
-
- public class Activator extends DependencyManagerActivator {
- @Override
- public void init(BundleContext ctx, DependencyManager dm) throws Exception {
- component(comp -> comp.impl(Hello.class));
- }
- }
-
-## Dependency default mode (required or optional ?)
-
-When you declare a dependency without explicitly invoking `optional()`, `required()`, or `required(boolean)`, then by default,
-the dependency is assumed to be optional. This is in line with the behavior of the Dependency Manager API.
-
-Now, you can change this default behavior by configuring the "`org.apache.felix.dependencymanager.lambda.defaultRequiredDependency`"
-system property. This property can be set with a list of java package prefixes (comma separated).
-When a component implementation class starts with one of the package prefixes specified in the above property, then dependencies will be
-assumed to be required by default.
-
-## Adding service dependencies injected in class fields.
-
-You can add a dependency using the "`withSvc`" methods available from the ComponentBuilder interface.
-Such methods accept a `Consumer<ServiceDependencyBuilder>` lambda expression, which may then configure the dependency using a chain of method calls (filter/callbacks,autoconfig, etc ...):
-When you don't specify callbacks, services are injected in class fields with compatible service dependency type, but you can specify a field name.
-Unavailable optional dependencies are injected as "`Null Objects`".
-
-The following example adds a service dependency on a LogService with a service filter.
-
- :::java
- import org.apache.felix.dm.lambda.DependencyManagerActivator;
- import org.apache.felix.dm.lambda.ServiceDependencyBuilder;
-
- public class Activator extends DependencyManagerActivator {
- @Override
- public void init(BundleContext ctx, DependencyManager dm) throws Exception {
- component(comp -> comp.impl(Hello.class)
- .withSvc(LogService.class, (ServiceDependencyBuilder svc) -> svc.filter("(vendor=apache)")));
- }
- }
-
-Here is a more concise version where the type of the `svc` lambda parameter is not declared:
-
- :::java
- import org.apache.felix.dm.lambda.DependencyManagerActivator;
-
- public class Activator extends DependencyManagerActivator {
- @Override
- public void init(BundleContext ctx, DependencyManager dm) throws Exception {
- component(comp -> comp.impl(Hello.class).withSvc(LogService.class, svc -> svc.filter("(vendor=apache)")));
- }
- }
-
-When injecting services in class fields (auto config mode), there are shotcuts that avoid using a lambda when defining a service dependency.
-These shortcuts are available from the ComponentBuilder interface.
-
-Examples:
-
-#### Declaring multiple auto config dependencies in one shot (using varargs of interfaces):
-
- :::java
- component(comp -> comp.impl(Hello.class).withSvc(ConfigurationAdmin.class, EventAdmin.class, MetatypeService.class));
-
-#### Declaring multiple auto config dependencies in one shot with a `required` flag:
-
- :::java
- component(comp -> comp.impl(Hello.class).withSvc(true, ConfigurationAdmin.class, EventAdmin.class, MetatypeService.class));
-
-#### Declaring an autoconfig dependency with a `required` flag:
-
- :::java
- component(comp -> comp.impl(Hello.class).withSvc(ConfigurationAdmin.class, true));
-
-#### Declaring an autoconfig dependency with a `filter ` and `required` flag:
-
- :::java
- component(comp -> comp.impl(Hello.class).withSvc(ConfigurationAdmin.class, "(vendor=apache)", true));
-
-#### Declaring a autoconfig dependency with a `filter `, an explicit class field, and `required` flag:
-
- :::java
- component(comp -> comp.impl(Hello.class).withSvc(ConfigurationAdmin.class, "(vendor=apache)", "configadmin", true));
-
-Dependency services can be injected in the following kind of fields:
-
-- a field having the same type as the dependency. If the field may be accessed by anythread, then the field should be declared
-volatile, in order to ensure visibility when the field is auto injected concurrently.
-- a field which is assignable to an `Iterable<T>` where T must match the dependency type. In this case, an Iterable will be
-injected by DependencyManager before the start callback is called. The Iterable field may then be traversed to inspect the
-currently available dependency services. The Iterable can possibly be set to a final value so you can choose the Iterable implementation of your choice (for example, a CopyOnWrite ArrayList, or a ConcurrentLinkedQueue).
-- a `Map<K,V>` where K must match the dependency type and V must exactly equals Dictionary class. In this case, a
-ConcurrentHashMap will be injected by DependencyManager before the start callback is called.
-The Map may then be consulted to lookup current available dependency services, including the dependency service properties
-(the map key holds the dependency services, and the map value holds the dependency service properties).
-The Map field may be set to a final value so you can choose a Map of your choice (Typically a ConcurrentHashMap).
-A ConcurrentHashMap is "weakly consistent", meaning that when traversing the elements, you may or may not see any concurrent
-updates made on the map. So, take care to traverse the map using an iterator on the map entry set,
-which allows to atomically lookup pairs of Dependency service/Service properties.
-
-## Service Dependency callbacks
-
-You can specify callbacks on the component implementation class using the "`add/change/remove/swap`" `ServiceDependencyBuilder` methods:
-
- :::java
- import org.apache.felix.dm.lambda.DependencyManagerActivator;
-
- public class Activator extends DependencyManagerActivator {
- @Override
- public void init(BundleContext ctx, DependencyManager dm) throws Exception {
- component(comp -> comp.impl(Hello.class).withSvc(LogService.class, svc -> svc.add("setLog")));
- }
- }
-
-Now you can also use a more type-safe callback using a Java 8 method reference:
-
- :::java
- import org.apache.felix.dm.lambda.DependencyManagerActivator;
-
- public class Activator extends DependencyManagerActivator {
- @Override
- public void init(BundleContext ctx, DependencyManager dm) throws Exception {
- component(comp -> comp.impl(Hello.class).withSvc(LogService.class, svc -> svc.add(Hello::setLog)));
- }
- }
-
-or:
-
- :::java
- import org.apache.felix.dm.lambda.DependencyManagerActivator;
-
- public class Activator extends DependencyManagerActivator {
- @Override
- public void init(BundleContext ctx, DependencyManager dm) throws Exception {
- component(comp -> comp.impl(Hello.class).withSvc(LogService.class, svc -> svc.add(Hello::setLog).remove(Hello::unsetLog)));
- }
- }
-
-The following callback methods signatures are supported when using method references:
-
-For add/change/remove method references:
-
- :::java
- method(S service)
- method(S service, ServiceReference<S> serviceRef),
- method(S service, Map<String, Object> serviceProperties)
- method(S service, Dictionary<String, Object> serviceProperties)
- method(S service, Component serviceComponent)
- method(S service, Component serviceComponent, ServiceReference<S> serviceRef)
-
-and for swap method references:
-
- :::java
- method(S oldService, S newService)
- method(S oldService, S newService, Component component))
- method(ServiceReference<S> oldRef, S old, ServiceReference<S> newRef, S newService)
- method(ServiceReference<S> oldRef, S old, ServiceReference<S> newRef, S newService, Component component)
-
-## Defining Service Dependency Object instance callback
-
-Sometimes, you want to inject the dependency to a separate object that is not part of the component implementation classes.
-For example, the following example injects a dependency in a DependencyHandler instance:
-
- :::java
- import org.apache.felix.dm.lambda.DependencyManagerActivator;
-
- public class Activator extends DependencyManagerActivator {
- @Override
- public void init(BundleContext ctx, DependencyManager dm) throws Exception {
- DependencyHandler depHandler = new DependencyHandler();
- component(comp -> comp.impl(Hello.class).withSvc(LogService.class, svc -> svc.add(depHandler, "setLog")));
- }
- }
-
-or using method reference:
-
- :::java
- import org.apache.felix.dm.lambda.DependencyManagerActivator;
-
- public class Activator extends DependencyManagerActivator {
- @Override
- public void init(BundleContext ctx, DependencyManager dm) throws Exception {
- DependencyHandler depHandler = new DependencyHandler();
- component(comp -> comp.impl(Hello.class).withSvc(LogService.class, svc -> svc.add(depHandler::setLog)));
- }
- }
-
-You can chain multiple callbacks:
-
- :::java
- import org.apache.felix.dm.lambda.DependencyManagerActivator;
-
- public class Activator extends DependencyManagerActivator {
- @Override
- public void init(BundleContext ctx, DependencyManager dm) throws Exception {
- DependencyHandler depHandler = new DependencyHandler();
- component(comp -> comp.impl(Hello.class).withSvc(LogService.class, svc -> svc.add(Hello::setLog).add(depHandler::setLog)));
- }
- }
-
-## Providing a service
-
-When a component provides a service with some properties, so far it was necessary to create a Dictionary and pass it to the `Component.setInterface()` method.
-
-Now you can pass properties directly to the `provides` method as varargs of properties (a suite of key-value properties):
-
- :::java
- import org.apache.felix.dm.lambda.DependencyManagerActivator;
-
- public class Activator extends DependencyManagerActivator {
- @Override
- public void init(BundleContext ctx, DependencyManager dm) throws Exception {
- component(comp -> comp.impl(Hello.class).provides(HelloService.class, "p1", "v1", "p2", 123));
- }
- }
-
-or if you build your application using the `-parameters` javac option, you can also use the "`FluentProperty`" lambda that allows to declare
-service properties as a suite of "`key -> value`" lambdas, like this:
-
- :::java
- import org.apache.felix.dm.lambda.DependencyManagerActivator;
-
- public class Activator extends DependencyManagerActivator {
- @Override
- public void init(BundleContext ctx, DependencyManager dm) throws Exception {
- component(comp -> comp.impl(Hello.class).provides(HelloService.class, p1 -> "v1", p2 -> 123));
- }
- }
-
-**CAUTION**: defining service properties using lambda parameters only works with Java8 , not
-Java9/10/11, and this feature may be removed in next version.
-
-## Depending on a configuration.
-
-Configuration dependency can be defined using the "`withCnf`" ComponentBuilder method.
-Two families of callbacks are supported:
-
-- reflection based callbacks: you specify a callback method name
-- method reference callbacks: you specify a java8 method reference
-
-Callbacks may accept a Dictionary, a Component, or a user defined configuration type interface. If you only specify a pid, by default the callback method name is assumed to be "updated".
-
-### configuration types
-
-Configuration types are a new feature that allows you to specify an interface that is implemented by DM and such interface is then injected to your callback instead of the actual Dictionary. Using such configuration interface provides a way for creating type-safe configurations from a actual Dictionary that is normally injected by Dependency Manager. The callback accepts in argument an interface that you have to provide, and DM will inject a proxy that converts method calls from your con [...]
-As proxies are injected, no implementations of the desired configuration-type are necessary!
-
-The lookups performed are based on the name of the method called on the configuration type. The method names are "mangled" to the following form: [lower case letter] [any valid character]*. Method names starting with get or is (JavaBean convention) are stripped from these prefixes. For example: given a dictionary with the key "foo" can be accessed from a configuration-type using the following method names: foo(), getFoo() and isFoo().
-
-The return values supported are: primitive types (or their object wrappers), strings, enums, arrays of primitives/strings, Collection types, Map types, Classes and interfaces. When an interface is returned, it is treated equally to a configuration type, that is, it is returned as a proxy.
-
-Arrays can be represented either as comma-separated values, optionally enclosed in square brackets. For example: [ a, b, c ] and a, b,c are both considered an array of length 3 with the values "a", "b" and "c". Alternatively, you can append the array index to the key in the dictionary to obtain the same: a dictionary with "arr.0" => "a", "arr.1" => "b", "arr.2" => "c" would result in the same array as the earlier examples.
-
-Maps can be represented as single string values similarly as arrays, each value consisting of both the key and value separated by a dot. Optionally, the value can be enclosed in curly brackets. Similar to array, you can use the same dot notation using the keys. For example, a dictionary with
-
- "map" => "{key1.value1, key2.value2}"
-
-and a dictionary with
-
- "map.key1" => "value1", "map2.key2" => "value2"
-
-result in the same map being returned. Instead of a map, you could also define an interface with the methods getKey1() and getKey2 and use that interface as return type instead of a Map.
-
-In case a lookup does not yield a value from the underlying map or dictionary, the following rules are applied:
-
-- primitive types yield their default value, as defined by the Java Specification;
-- string, Classes and enum values yield null;
-- for arrays, collections and maps, an empty array/collection/map is returned;
-- for other interface types that are treated as configuration type a null-object is returned.
-
-### multiple ways to define a configuration dependency
-
-You can first pass a configuration pid to the `withCnf` method. In this example, the Hello component has an "`updated(Dictionary properties)`" method called when configuration is available or updated.
-
- :::java
- component(comp -> comp.impl(Hello.class).withCnf("my.pid"))
-
-You can pass a "`configuration type`" to the `withCnf` method. The pid is assumed to be the fqdn of the type passed to the `withCnf` method, and the callback is assumed to be "`updated`"
-and to accept as argument an implementation of the specified configuration type:
-
- :::java
- component(comp -> comp.impl(Hello.class).withCnf(MyConfiguration.class))
-
-You can define the updated callback method explicitly using a ConfigurationDependencyBuilder lambda that you can pass to the "`withCnf`"
-method:
-
- :::java
- component(comp -> comp.impl(Hello.class).withCnf((ConfigurationDependencyBuilder cnf) -> cnf.pid("my.pid").update("modified")));
-
-Here is shorter version which does not declare the type of the lambda passed to the `withCnf` method:
-
- :::java
- component(comp -> comp.impl(Hello.class).withCnf(cnf -> cnf.pid("my.pid").update("modified")));
-
-You can also define the callback using a method reference:
-
- :::java
- component(comp -> comp.impl(Hello.class).withCnf(cnf -> cnf.pid("my.pid").update(Hello::modified)));
-
-And finally, you can define a configuration type, and a callback using a method reference. Here, the updated callback has to take
-in argument the configuration type parameter (the pid is assumed to be the fqdn of the configuration type):
-
- :::java
- component(comp -> comp.impl(Hello.class).withCnf(cnf -> cnf.update(MyConfiguration.class, Hello::modified)));
-
- class Hello {
- void modified(MyConfiguration properties) { ... }
- }
-
-#### Configuration Dependency Examples based on method references:
-
-Code example with a component that defines a Configuration Dependency using a specific callback method reference, and the method accepts in argument a configuration type
-(the pid is assumed to be the fqdn of the configuration type):
-
- :::java
- public interface MyConfig {
- String getAddress();
- int getPort();
- }
-
- public class ServiceImpl {
- void updated(MyConfig cnf) {
- if (cnf != null) {
- String addr = cnf.getAddress();
- int port = cnf.getPort();
- ...
- }
- }
- }
-
- public class Activator extends DependencyManagerActivator {
- public void init(BundleContext ctx, DependencyManager dm) throws Exception {
- component(comp -> comp.impl(ServiceImpl.class).withCnf(conf -> conf.update(MyConfig.class, ServiceImpl::updated)));
- }
- }
-
-Same example, using a shortcut for the `withCnf` dependency, which is only defining the configuration type
-(the pid is assumed to be the fqdn of the config type, and the callback name is assumed to be "updated"):
-
- public class Activator extends DependencyManagerActivator {
- public void init(BundleContext ctx, DependencyManager dm) throws Exception {
- component(comp -> comp.impl(ServiceImpl.class).withCnf(MyConfig.class));
- }
- }
-
-Code example with a component that defines a Configuration Dependency using a specific callback method reference which accepts a Dictionary in argument:
-
- :::java
- public class Activator extends DependencyManagerActivator {
- public void init(BundleContext ctx, DependencyManager dm) throws Exception {
- component(comp -> comp
- .impl(ServiceImpl.class)
- .withCnf(conf -> conf.pid("my.pid").update(ServiceImpl::setProperties)));
- }
- }
-
-#### Configuration Dependency Examples based on method reflection:
-
-Code example which defines a configuration dependency injected in the "ServiceImpl.updated(Dictionary)" callback
-(the pid is directly passed in argument to the `withCnf` method):
-
- :::java
- public class Activator extends DependencyManagerActivator {
- public void init(BundleContext ctx, DependencyManager dm) throws Exception {
- component(comp -> comp.impl(ServiceImpl.class).withCnf("my.pid")));
- }
- }
-
-Code example with a component that defines a Configuration Dependency using a specific callback method name:
-
- :::java
- public class Activator extends DependencyManagerActivator {
- public void init(BundleContext ctx, DependencyManager dm) throws Exception {
- component(comp -> comp.impl(ServiceImpl.class).withCnf(conf -> conf.pid("my.pid").update("modified")));
- }
- }
-
-
-## Managing components outside of Activators.
-
-You can manage Components outside of the Activator by using some static factory methods from the `DependencyManagerActivator` class.
-
-For example, consider a use case where you want to retrieve some information from some already injected services, and you then want to dynamically add more dependencies from your
-`init` component callback. First let's look at the Activator:
-
- :::java
- import org.apache.felix.dm.lambda.DependencyManagerActivator;
-
- public class Activator extends DependencyManagerActivator {
- @Override
- public void init(BundleContext ctx, DependencyManager dm) throws Exception {
- component(comp -> comp.impl(Pojo.class).withCnf("pojo.pid"));
- }
- }
-
-Here, we define a Configuration dependency with a "pojo.pid" configuration pid. So, now, the Pojo will then for example be able to parse an xml from the configuration, and depending on
-what it has parsed, it will possibly add more dependencies, like this:
-
- :::java
- import static org.apache.felix.dm.lambda.DependencyManagerActivator.*;
- import org.apache.felix.dm.Component;
-
- public class Pojo {
- void updated(Dictionary conf) throws Exception {
- parseXml(conf.get("some.xml.configuration"));
- }
-
- void init(Component c) { // lifecycle dm callback that allows you to add more dependencies
- if (xmlConfigurationRequiresEventAdmin) {
- component(c, comp -> comp.withSvc(EventAdmin.class));
- }
- }
- }
-
-The available variety of factory methods allows you to also create some DM objects and add them manually, like:
-
- :::java
- import static org.apache.felix.dm.lambda.DependencyManagerActivator.*;
- import org.apache.felix.dm.Component;
- import org.apache.felix.dm.ServiceDependency;
- import org.apache.felix.dm.DependencyManager;
-
- public class Pojo {
- void updated(Dictionary conf) throws Exception {
- parseXml(conf.get("some.xml.configuration"));
- }
-
- void init(Component c) { // lifecycle dm callback that allows you to add more dependencies
- if (xmlConfigurationRequiresEventAdmin) {
- DependencyManager dm = c.getDependencyManager();
- ServiceDependency dep = serviceDependency(c, EventAdmin.class).filter("(vendor=felix)").build();
- dm.add(dep);
- }
- }
- }
-
-And an example where you create a new DM component from the code:
-
- :::java
- import static org.apache.felix.dm.lambda.DependencyManagerActivator.*;
- import org.apache.felix.dm.DependencyManager;
-
- public class Pojo {
- volatile DependencyManager m_dm;
-
- void createComponent() {
- component(m_dm, comp -> comp.impl(NewComponent.class).withSvc(LogService.Class, EventAdmin.class));
- }
- }
-
-## Component Lifecycle Callbacks
-
-Like with DM API, default lifecycle callbacks are the following:
-
-- "init": the method is called on the component implementation class(es) once all required dependencies declared in the Activator
-have been injected. This method can then be used to possibly add more dependencies dynamically.
-- "start": the method is called on the component implementation class(es) once all required dependencies (including the ones added
-from the "init" callback) have been injected. Then the optional dependency callbacks are invoked (after the start callback).
-- "stop": the method is called on the component implementation class(es) when some required dependencies are being lost
-or when the component's bundle is stopping.
-- "destroy": the component is destroyed and may be re-created and re-initialized in case some required dependencies comes up again.
-
-You can change the callback names using the "init"/"start"/"stop"/"destroy" methods from the ComponentBuilder interface. For example:
-
- :::java
- component(comp -> comp.impl(Pojo.class)
- .init("initialize")
- .start("activate")
- .stop("deactivate")
- .destroy("shutdown"));
-
-Same example, but with some specific callback instance on which the callback should be invoked:
-
- CallbackHandler handler = new CallbackHandler();
- component(comp -> comp.impl(Pojo.class)
- .init(handler, "initialize")
- .start(handler, "activate")
- .stop(handler, "deactivate")
- .destroy(handler, "shutdown"));
-
-When using callback instances, you can also use method references using the callback instance object:
-
- CallbackHandler handler = new CallbackHandler();
- component(comp -> comp.impl(Pojo.class)
- .init(handler::initialize)
- .start(handler::activate)
- .stop(handler::deactivate)
- .destroy(handler::shutdown));
-
-Callbacks are empty-args, or may take a DM Component in argument.
-
-Method Reference for Component implementations class are not supported.
-## Creating Aspect Components
-
-Like with the original DM API, you can create a chain of aspects (service interceptors) ordered by a ranking attribute, using the "`aspect`" factory method.
-This method accepts in argument a ServiceAspectBuilder.
-
-Code example which provides a "LogService" aspect that performs spell-checking of each log message. The aspect decorates a LogService.
-The aspect also depends on a DictionaryService that is internally used to perform log spell checking.
-The LogService and DictionaryService services are injected in the aspect implementation using reflection on class
-fields:
-
- ::::java
- public class Activator extends DependencyManagerActivator {
- public void init(BundleContext ctx, DependencyManager dm) throws Exception {
- aspect(LogService.class, (ServiceAspectBuilder asp) -> asp.impl(SpellCheckLogAspect.class).rank(10).withSvc(DictionaryService.class));
- }
- }
-
-Same more concise example which does not declare the type of the lambda builder argument:
-
- ::::java
- public class Activator extends DependencyManagerActivator {
- public void init(BundleContext ctx, DependencyManager dm) throws Exception {
- aspect(LogService.class, asp -> asp.impl(SpellCheckLogAspect.class).rank(10).withSvc(DictionaryService.class));
- }
- }
-
-Same example, but using callbacks for injecting LogService and DictionaryService in the aspect implementation class:
-
- :::java
- public class Activator extends DependencyManagerActivator {
- public void init(BundleContext ctx, DependencyManager dm) throws Exception {
- aspect(LogService.class, asp -> asp
- .impl(SpellCheckLogAspect.class).rank(10)
- .add(SpellCheckLogAspect::setLogService)
- .withSvc(DictionaryService.class, svc -> svc.add(SpellCheckLogAspect::setDictionary)));
- }
- }
-
-## Creating Service Adapter Components
-
-DM service adapters allow to create adapter services when a given type of adapted service is found in the OSGI registry.
-Using the "`adapter`" factory method, you can pass to it consumer of an `ServiceAdapterBuilder` that
-can be used to construct a DM adapter component.
-
-Code example that adapts a "Device" service to an HttpServlet service. The adapter is created using a ServiceAdapterBuilder that is passed to the lambda.
-
- :::java
- public class Activator extends DependencyManagerActivator {
- public void init(BundleContext ctx, DependencyManager dm) throws Exception {
- adapter(Device.class, (ServiceAdapterBuilder adapt) -> adapt.impl(DeviceServlet.class).provides(HttpServlet.class).properties(alias -> "/device");
- }
- }
-
-Same more concise example which does not declare the type of lambda parameter:
-
- :::java
- public class Activator extends DependencyManagerActivator {
- public void init(BundleContext ctx, DependencyManager dm) throws Exception {
- adapter(Device.class, adapt -> adapt.impl(DeviceServlet.class).provides(HttpServlet.class).properties(alias -> "/device");
- }
- }
-
-## Creating Factory Configuration Adapter Components
-
-A Factory Configuration Adapter allows to create many instances of the same service, each time a configuration instance is created for a given factory pid.
-To declare a factory pid configuration adapter, use the `factoryPid` method available from the DependencyManagerActivator class and pass to it
-a lambda for the FactoryPidAdapterBuilder argument:
-
-Example that defines a factory configuration adapter service for the "foo.bar" factory pid. For each factory pid instance, an instance of the DictionaryImpl component will be created:
-
- :::java
- public class Activator extends DependencyManagerActivator {
- public void init(BundleContext ctx, DependencyManager dm) throws Exception {
- factoryPidAdapter((FactoryPidAdapterBuilder adapter) -> adapter
- .impl(DictionaryImpl.class).factoryPid("foo.bar").propagate().update(ServiceImpl::updated)
- .withSvc(LogService.class, log -> log.optional()));
- }
- }
-
-Same more concise example that is not declaring the type of the lambda type:
-
- :::java
- public class Activator extends DependencyManagerActivator {
- public void init(BundleContext ctx, DependencyManager dm) throws Exception {
- factoryPidAdapter(adapter -> adapter
- .impl(DictionaryImpl.class).factoryPid("foo.bar").propagate().update(ServiceImpl::updated)
- .withSvc(LogService.class, log -> log.optional()));
- }
- }
-
-Example that defines a factory configuration adapter using a user defined configuration type (the pid is by default assumed to match the fqdn of the configuration type):
-
- :::java
- public interface DictionaryConfiguration {
- public String getLanguage();
- public List<String> getWords();
- }
-
- public class Activator extends DependencyManagerActivator {
- public void init(BundleContext ctx, DependencyManager dm) throws Exception {
- factoryPidAdapter(adapter -> adapter
- .impl(DictionaryImpl.class).propagate().update(DictionaryConfiguration.class, ServiceImpl::updated)
- .withSvc(LogService.class, log -> log.optional()));
- }
- }
-
-## Creating a Bundle Adapter component
-
-A Bundle Adapter is used to create a Component when a bundle that matches a given filter is found.
-To build a DM adapter, you can use the "`bundleAdapter`" factory method: it takes in argument a consumer of a
-BundleAdapterBuilder object, which is used to construct a real DM BundleAdapter component.
-
-Example that creates a BundleAdapter service for each started bundle (the bundle is added using a method reference):
-
- :::java
- public class Activator extends DependencyManagerActivator {
- public void init(BundleContext ctx, DependencyManager dm) throws Exception {
- bundleAdapter(adapt -> adapt
- .impl(BundleAdapterImpl.class).provides(BundleAdapter.class).mask(Bundle.INSTALLED|Bundle.RESOLVED|Bundle.ACTIVE)
- .add(BundleAdapterImpl::bundleStarted)
- .withSvc(LogService.class, "(vendor=apache)"));
- }
- }
-
-## CompletableFuture dependency.
-
-The new library provides a new feature which allows your component to depend on the result of a jdk8 `CompletableFuture`.
-CompletableFuture java8 class provides an asynchronous event-driven model and you can now define dependencies on any asynchronous events,
-like if they were service dependencies.
-
-Let's explore this new dependency using an advanced example: assume you develop a component that needs to
-track any "Tracked" services registered in the Registry, using a classic whiteboard pattern. But before, you need to
-download a web page at initialization, before you component is started. The downloaded webpage is required to be able to
-handle Tracked services. Now, you don't want to block the initialization of your component because in a reactive word,
-it is forbidden to block on the current thread.
-
-So, you use an `HttpClient` which allows to asynchronously download a web page: this service is assumed to provide a doGET() method
-which does not block the current thread, but instead returns `CompletableFuture<String>`
-which represents the future result of the asynchronously downloaded page.
-
-From your component init() method, you can then declare a FutureDependency on the result of the `CompletableFuture<String>`.
-A Future Dependency can be defined using the "withFuture" method available from the ComponentBuilder interface, and this method takes as argument two args: a CompletableFuture, and a
-`consumer<FutureDependencyBuilder>`. The second arg is a lambda that can be used to configure the callback to invoke when the CF has completed.
-
-And once the result completes, start() will be called, and at this point, the Tracked services will then
-be injected (using DM, optional service callbacks are always invoked after the start() callback, never before).
-
-So, the Activator looks like this:
-
- :::java
- import org.apache.felix.dm.lambda.DependencyManagerActivator;
-
- public class Activator extends DependencyManagerActivator {
- @Override
- public void init(BundleContext ctx, DependencyManager dm) throws Exception {
- component(comp -> comp.impl(Pojo.class).provides(PojoService)
- .withCnf(cnf -> cnf.pid("foo.pid"))
- .withSvc(HttpClient.class, svc -> svc.required())
- .withSvc(Tracked.class, svc -> svc.optional().add(Pojo::bindTracked));
- }
- }
-
-Now, here is the implementation for our component which downloads the URL from its init method. The init method will declare a "FutureDependency"
-for the result of the `CompletableFuture<String>` returned by the HttpClient. And once the result is injected
-in the setPage callback, then the start() callback will be called, and finally, any registered Tracked services will be
-injected in the "bindTracked" method:
-
- :::java
- import static org.apache.felix.dm.lambda.DependencyManagerActivator.*;
- import org.apache.felix.dm.Component;
-
- public class Pojo implements PojoService {
- HttpClient m_httpClient; // injected.
- String m_url; // the URL to download using the http client.
-
- void updated(Dictionary<String, Object conf) throws Exception {
- m_url = (String) conf.get("download.url");
- }
-
- // lifecycle dm callback that allows you to add more dependencies. start will be called once the webpage has been downloaded.
- void init(Component c) {
- // Let's schedule a download for our web page.
- CompletableFuture<String> futurePage = m_httpClient.doGET(m_url);
-
- // Add a required dependency to the result of the CF, and inject the result in our setPage method.
- component(c, comp -> comp.withFuture(futurePage, future -> future.complete(this::setPage)));
- }
-
- void setPage(String content) {
- // Called when the CompletableFuture has completed
- }
-
- void start() {
- // We have downloaded the page, our component is starting and is about to be registered
- }
-
- void bindTracked(Tracked service) {
- // a Tracked service is injected, we can handle it because we are fully initialized.
- // (optional service callbacks are always invoked after the start callback).
- }
- }
-
-So, using the Future Dependency we can nicely reuse the jdk CompletableFuture as a required dependency. Without using the FutureDependency
-on the CompletableFuture returned by the HttpClient, we would then have to manually register our service using bundleContext.registerService (once the web page has been downloaded), and we
-would then have to check if the webpage has been downloaded each time a Tracked service is injected. And in case the page is not available, we would
-then have to cache the injected Tracked service and process it later, once the page has been downloaded.
-
-Also, notice that when the page is injected in the setPage() method, you absolutely don't need to deal with
-synchronization at all because in DM, all lifecycle and dependency callbacks are safely scheduled in a "serial queue" associated to the
-component.
-
-## Sample codes
-
-many samples codes are available from the distribution source release: Please take a look at the following:
-
-### org.apache.felix.dependencymanager.lambda.samples/src/org/apache/felix/dm/lambda/samples/hello/
-
-This sample provides a DM Activator declaring one service consumer and a service provider. The
-ServiceConsumer is also depending on a configuration pid (see org.apache.felix.dependencymanager.samples.hello.Configurator).
-
-### org.apache.felix.dependencymanager.lambda.samples/src/org/apache/felix/dm/lambda/samples/compositefactory/
-
-This Activator is an example usage of DM composite components. A composite component is implemented
-using a composition of multiple object instances, which are used to implement a given service.
-
-The sample also uses a Factory approach in order to instantiate the composition of objects: A
-"CompositionManager" is first injected with a Configuration that can possibly be used to create
-and configure all the composites.
-
-Dependencies are injected to some of the component implementation instances, using java8 method references. For instance,
-the LogService is only injected in the ProviderImpl and the ProviderComposite1 class and not in the ProviderComposite2 class.
-
-### org.apache.felix.dependencymanager.lambda.samples/src/org/apache/felix/dm/lambda/samples/device/
-
-This is an example showing a Dependency Manager "Adapter" in action. Two kinds of services are
-registered in the registry: some Device, and some DeviceParameter services. For each Device (having
-a given id), there is also a corresponding "DeviceParameter" service, having the same id.
-
-Then a "DeviceAccessImpl" adapter service is defined: it is used to "adapt" the "Device" service to
-a "DeviceAccess" service, which provides the union of each pair of Device/DeviceParameter having the
-same device.id . The adapter also dynamically propagate the service properties of the adapted Device
-service.
-
-### org.apache.felix.dependencymanager.lambda.samples/src/org/apache/felix/dm/lambda/samples/dictionary/
-
-This sample shows a "SpellChecker" application which provides a
-"dictionary:spellcheck" GOGO shell command. The GOGO "dictionary:spellcheck" command accepts a
-string as parameter, which is checked for proper exactness. The SpellChecker class has a
-required/multiple (1..N) dependency over every available "DictionaryService" services, which are
-internally used by the SpellChecker command, when checking word exactness.
-
-A DictionaryService is defined using a FactoryConfigurationAdapterService , allowing to instantiate
-many "DictionaryService" instances for each configuration that are added to the
-factory pid "Spell Checker Configuration" from web console.
-The factory pid configuration metatypes are defined using the bnd "metatype" annotations
-(see DictionaryConfiguration.java).
-
-The DictionaryService is decorated with a DictionaryAspect, which you can instantiate by adding a
-configuration to the "Spell Checker Aspect Dictionary" pid from web console. The
-aspect configuration metatype is also declared using the bnd metatype annotations (see
-DictionaryAspectConfiguration.java).
-
-Before running this sample, go to webconsole, and add some words in the "`Spell Checker Configuration`" factory PID, and
-in the "`Spell Checker Aspect Dictionary`" PID.
-
-Then go to gogo shell, and type dm help. You will normally see the dictionary:spellcheck command.
-Type dictionary:spellcheck with some words configured either in the spell checker configuration, or in the spell checker aspect configuration,
-and the dictionary will check for proper word exactness.
-
-### org.apache.felix.dependencymanager.lambda.samples/src/org/apache/felix/dm/lambda/samples/factory/
-
-This sample is an example usage of DM components that are created using a Factory object.
-The Factory is defined using java8 method references.
-
-### org.apache.felix.dependencymanager.lambda.samples/src/org/apache/felix/dm/lambda/samples/future/
-
-The purpose of this sample is to show an example usage of the new "CompletableFuture" dependency that has been
-added in the dm-lambda library. CompletableFuture java8 class provides functional operations and promotes an asynchronous event-driven model.
-
-In such model, you can use the new dm-lambda library to add dependencies on asynchronous events using the standard JDK CompletableFuture class.
-
-In this example, the Activator first defines a PageLink component that is used to download a given page from the web. The service then parses
-the content of the page and returns all available hrefs (links) found from the web page.
-
-The PageLink is initialized with the Felix web site URL, which is asynchronously downloaded from the PageLink::init method, using a CompletableFuture.
-The CF is then added as a "FutureDependency" in the PageLinkImpl.init() method, and when the CF completes, the PageLinkImpl.start() callback is invoked
-and the service is registered.
-
-The Activator is then getting injected with the PageLink service, and displays the links (hrefs) found from the Felix web site.
-
-Caution: if you are using a corporate http proxy, you have to fix the Activator in order to configure the ip addr and port number of your
-http proxy.
-
-## Javadoc
-
-You can find the javadoc for the new Dependency Manager Lambda library [here](../../../../apidocs/).
-
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/guides/history.mdtext b/modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/guides/history.mdtext
deleted file mode 100644
index c151caf..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/guides/history.mdtext
+++ /dev/null
@@ -1,15 +0,0 @@
-Title: Dependency Manager - History
-
-Dependency Manager has quite a long history, that starts over ten years ago.
-
-## The early years
-
-The first version of the Dependency Manager was created when Marcel started working on his first commercial OSGi project back in 2002. At that time, the OSGi specification was still at R2, and the only solution for managing dependencies was "service binder" which did not support the dynamics we needed at that time. Therefore, dependency manager was created, based on a fluent, declarative Java API.
-
-In 2005, after writing a white paper, dependency manager was presented at the OSGi DevCon in Paris. At that time, the project had been open sourced, but not yet at Apache. When the Oscar project finally decided to move to the incubator, where it became Felix, Dependency Manager was one of the subprojects that joined.
-
-## Life at Apache
-
-The move to Apache definitely gave the project a lot more visibility and, besides a larger user base, also attracted a few very talented developers. Xander did a lot of work in getting some of the higher level design patterns implemented, and Pierre added support for annotations and ensured that the code ran well on really big, multi-core systems.
-
-In 2014, after many discussions about new features and improvements we would like to add, we started experimenting with a completely new codebase, redesigning some aspects from the ground up based on all the knowledge and experience that we had gained over the years. About a year later, that lead to the release of Dependency Manager 4.
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/guides/javadocs.mdtext b/modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/guides/javadocs.mdtext
deleted file mode 100644
index 4148ab0..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/guides/javadocs.mdtext
+++ /dev/null
@@ -1,4 +0,0 @@
-Title: Dependency Manager - JavaDocs
-
-The various Dependency Manager JavaDocs for the API, the Annotations, and the Runtime can be found from the [main felix apidocs homepage](http://felix.apache.org/apidocs/).
-
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/guides/migrating-from-earlier-versions.mdtext b/modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/guides/migrating-from-earlier-versions.mdtext
deleted file mode 100644
index 98b74f2..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/guides/migrating-from-earlier-versions.mdtext
+++ /dev/null
@@ -1,69 +0,0 @@
-Title: Apache Felix Dependency Manager - Migrating from earlier versions
-
-Below is a guide to help you migrate from version 3. Whilst older versions obviously still exist, we don't think people are still actively using them.
-
-## Migrating from version 3
-
-DependencyManager 4.0 has some API changes that need to be taken into account when migrating from DependencyManager 3.
-
-* A dependency can no longer be shared accross components.
-* You no longer have to call setInstanceBound() when adding a dependency from within the init() method of a component. Therefore the setInstanceBound() method has been removed from all Dependency interfaces.
-* in the Dependency interface, the following method have been removed: isInstanceBound, invokeAdded, invokeRemoved, createCopy.
-* In the Component interface, the "Object Component.getService()" method has been replaced by the "<T> T getInstance()" method.
-* In the Component interface, the "void addStateListener(ComponentStateListener listener) method" has been replaced by the "add(ComponentStateListener listener)" method.
-* In the Component interface, the "start", "stop", "getDependencies" methods have been removed.
-* In the Component interface and in the DependencyManager class, the createTemporalServiceDependency() method is now taking a timeout parameter: createTemporalServiceDependency(long timeout).
-* The ComponentStateListener interface has changed: it is now providing a single "changed(Component c, ComponentState state)" method.
-* The DependencyManager 4 Shell commands are no longer available for framework specific shell implementations, and support the gogo shell only.
-* The TemporalServiceDependency interface has been removed.
-* The Annotations processor is not generating anymore the Import-Service/Export Service by default (no need to specify the "build-import-export-service=false" option in the
-annotations plugin if you don't need to generate automatically the deprecated headers).
-* The Dependency Manager metatype annotations are now deprecated and it is encouraged to use standard bnd metatypes annotation instead.
-See org.apache.felix.dependencymanager.samples/src/org/apache/felix/dependencymanager/samples/dictionary/annot/DictionaryConfiguration.java for an example.
-You can also check http://www.aqute.biz/Bnd/MetaType for more information about the bnd metatypes annotations.
-* Dependency Manager is now fully built using bndtools, and there is no Maven annotation plugin anymore. However, the workaround is simply the
-use a "_plugin" option in the pom, and to declare a dependency inside the "plugin" configuration.
-Notice that in the R1 version, we are not pushing DM distribution to maven, so you have to do manually push the DM artifacts in your own nexus server.
-We'll try to release DM artifacts to maven central in the next release (R2).
-
-For example:
-
- :::xml
- <project ...>
- <dependencies>
- ...
- <dependency>
- <groupId>org.apache.felix</groupId>
- <artifactId>org.apache.felix.dependencymanager.annotation</artifactId>
- <version>4.0.0</version>
- </dependency>
- </dependencies>
- <build>
- <plugins>
- ...
- <plugin>
- <groupId>org.apache.felix</groupId>
- <artifactId>maven-bundle-plugin</artifactId>
- <version>2.5.0</version>
- <extensions>true</extensions>
- <configuration>
- <instructions>
- <Bundle-Name>Test</Bundle-Name>
- <Bundle-SymbolicName>test</Bundle-SymbolicName>
- <Import-Package>*</Import-Package>
- <Private-Package>test.dmannotations.withbndplugininvokedfrompom</Private-Package>
- <_plugin>org.apache.felix.dm.annotation.plugin.bnd.AnnotationPlugin;log=debug</_plugin>
- </instructions>
- </configuration>
- <dependencies>
- <dependency>
- <groupId>org.apache.felix</groupId>
- <artifactId>org.apache.felix.dependencymanager.annotation</artifactId>
- <version>4.0.0</version>
- </dependency>
- </dependencies>
- </plugin>
- </plugins>
- </build>
- </project>
-
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/guides/migrating-from-other-solutions.mdtext b/modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/guides/migrating-from-other-solutions.mdtext
deleted file mode 100644
index 84df34c..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/guides/migrating-from-other-solutions.mdtext
+++ /dev/null
@@ -1,2 +0,0 @@
-Title: Dependency Manager - Migrating from other solutions.
-
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/guides/performance-tuning.mdtext b/modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/guides/performance-tuning.mdtext
deleted file mode 100644
index ba1ed3b..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/guides/performance-tuning.mdtext
+++ /dev/null
@@ -1,37 +0,0 @@
-Title: Dependency Manager - Performance Tuning
-
-To further tune the performance of an application using Dependency Manager and a lot of services, we created the concept of filter indices. They work similarly to the way indices speed up relational database queries and are explained below.
-
-## Filter Indices
-
-Filter indices allow you to speed up the service resolution process by skipping the services registry, in favor of a fast index on given service properties.
-
-The Dependency Manager will look for a set of filter indices in the `org.apache.felix.dependencymanager.filterindex` system property. This system property uses the following syntax,
-
- property-index ::= service-property | service-property ',' property-index
- index ::= '*aspect*' | '*adapter*' | property-index
- indices ::= index | indices ';' index
-
-The implementation ships with three kinds of index implementations.
-
-- *Service property indices* are based on a set of service properties, like a multi-column index in a database.
-- *Aspect indices* work with Dependency Manager Aspect services, and will provide indexing for the specific filters that they use.
-- *Adapter indices* work like Aspect indices, but for Adapter services.
-
-### Performance
-
-The index isn't free, but reduces the linear (and wasteful) filter-based lookup to an indexed log(n) lookup. You can expect noticeable speedup if you have at least several hundred services.
-
-### Examples
-
- -Dorg.apache.felix.dependencymanager.filterindex=objectClass
-Sets an index on `objectClass`, speeding up lookups for any filter that contains an `objectClass` in its filter (all regular services do).
-
- -Dorg.apache.felix.dependencymanager.filterindex=objectClass,id
-This filter helps if you have a lot of similar services, identified by some `id`.
-
- -Dorg.apache.felix.dependencymanager.filterindex=objectClass,id;objectClass,ipAddress
-This is a set of two filter indices, helping when you have one set of services that has an `id`, and another set that uses an `ipAddress` for identification.
-
- -Dorg.apache.felix.dependencymanager.filterindex=*aspect*
-Provides indexing for all Aspect services.
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/guides/resources.mdtext b/modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/guides/resources.mdtext
deleted file mode 100644
index af1709f..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/guides/resources.mdtext
+++ /dev/null
@@ -1,97 +0,0 @@
-Title: Dependency Manager - Resource adapters
-
-Resource adapters are a special type of adapters which can adapt a resource into an OSGi service. These resources can be all kinds of resources, e.g. bundle resources, files, database records, anything as long as it can be resolved though a URL.
-
-The diagram below illustrates the classes involved in the resource adapter pattern:
-
-<img src="./diagrams/resources.png" alt="Resource adapters" style="width: 780px"/>
-
-The yellow elements have to be implemented in order to use the pattern.
-
-A resource adapter is configured as follows:
-
-
- manager.add(createResourceAdapter("*.MF", true, null, "changed")
- .setImplementation(ManifestAdapter.class));
-
-The filter semantics depend on the resource repository. In this example the resource repository will be serving bundle resources, so we're using a standard file wildcard filter. As the filter specifies in this case the resource of interest is the bundle manifest. For each MANIFEST.MF found a new instance of ManifestAdapter will be created and registered. Each instance gets access to the resource by injecting the URL of the resource into the implementation object.
-
- public class ManifestAdapter {
-
- private volatile URL url;
-
- void start() {
- System.out.println("started: " + url);
- }
-
- }
-
-
-But how does DM know where to go looking for manifest files? We'll it does not automatically. It requires you to implement a resource repository component. For each resource adapter service DM launches a ResourceHandler service tracking the resources the resource adapter is interested in. A resource repository is responsible for tracking resources and notifying adding / changing and removal of the resources from the repository. Notifying these resource 'events' is done by invoking the co [...]
-
-We'll explain how to implement a resource repository by an example. The example resource repository is a bundle resource repository which as it's name says, is capable of serving bundle resources.
-
-A simplified bundle resource repository looks as follows:
-
-
- public class BundleResourceRepositoryImpl {
-
- private Map<ServiceReference, ResourceHandler> handlers = new ConcurrentHashMap<>();
- private volatile BundleContext context;
-
- // added callback
- void addHandler(ServiceReference ref, ResourceHandler handler) {
- handlers.put(ref, handler);
- if (ref.getProperty(ResourceHandler.URL) != null) {
- URL url = (URL) ref.getProperty(ResourceHandler.URL);
- notifyMatchingInitialResource(url, handler);
- } else {
- String filter = (String) ref.getProperty(ResourceHandler.FILTER);
- notifyMatchingInitialResources(filter, handler);
- }
- }
-
- // removed callback
- void removeHandler(ServiceReference ref, ResourceHandler handler) {
- handlers.remove(ref);
- }
-
- private void notifyMatchingInitialResource(URL url, ResourceHandler handler) {
- if (bundleContainsResource(url)) {
- handler.added(url, new Hashtable<String, String>());
- }
- }
-
- @SuppressWarnings("unchecked")
- private void notifyMatchingInitialResources(String filter, ResourceHandler handler) {
- Enumeration<URL> entries = context.getBundle().findEntries("/", filter, true);
- while (entries.hasMoreElements()) {
- URL entry = entries.nextElement();
- handler.added(entry, new Hashtable<String, String>());
- }
- }
-
- private boolean bundleContainsResource(URL url) {
- return true; // more specific checks required
- }
- }
-
-
-The resource repository is registered in the bundle activator as follows:
-
-
- manager.add(createComponent().setImplementation(BundleResourceRepositoryImpl.class)
- .add(createServiceDependency().setService(ResourceHandler.class).setCallbacks("addHandler", "removeHandler")));
-
-A resource repository implementation must have a dependency on resource handlers. The ResourceHandler service has two important service properties:
-
-- "filter" (`ResourceHandler.FILTER`)
-- "url" (`ResourceHandler.URL`)
-
-A resource handler service has either one of these properties, not both! A resource handler with a filter can match multiple resources whereas a resource handler with a url only matches a single resource. It's important the resource repository handles both situations.
-
-When a new handler is being added, the resource repository should inform the resource handler on the resources it has that match the handler's filter or url. This is done by invoking the `added(url, properties)` method on the ResourceHandler. This callback results in the ResourceAdapter's ResourceDependency being satisfied, the url being injected into the resource adapter implementation object and the resource adapter implementation component being started.
-
-Besides the added() callback the resource repository is also responsible for handling the changed() and removed() methods on change or removal of the resource from the resource repository. For a bundle resource repository that's not likely to happen, but for a filesystem resource repository this can very well be the case.
-
-
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/guides/whatsnew-r15.mdtext b/modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/guides/whatsnew-r15.mdtext
deleted file mode 100644
index 4dacff3..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/guides/whatsnew-r15.mdtext
+++ /dev/null
@@ -1,199 +0,0 @@
-Title:
-Notice: Licensed to the Apache Software Foundation (ASF) under one
- or more contributor license agreements. See the NOTICE file
- distributed with this work for additional information
- regarding copyright ownership. The ASF licenses this file
- to you under the Apache License, Version 2.0 (the
- "License"); you may not use this file except in compliance
- with the License. You may obtain a copy of the License at
- .
- http://www.apache.org/licenses/LICENSE-2.0
- .
- Unless required by applicable law or agreed to in writing,
- software distributed under the License is distributed on an
- "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
- KIND, either express or implied. See the License for the
- specific language governing permissions and limitations
- under the License.
-
-This section describes some enhancements and API modification which have been performed in the dependency manager r15 release.
-Mainly,
-
-- Support for Java 9/10/11
-- annotation API has been simplified
-- support for user-defined annotation property types
-- DM API has been reworked to simplify the definition of aspect and adapters.
-- Lightweight support for OSGI service scopes
-- The dependency manager is now built using bndtools 3.5.0 as well as with bndlib 3.5.0
-- dependencymanager-deps is not used anymore (all required build time binary dependencies are now downloaded from maven central, and the gradle wrapper jar is also downloaded from the gradlew script). Moreover semantic versioning is now using a baseline that is downloaded from maven central.
-
-## API enhancements
-
-Some enhancements have been done in the dm API:
-
-- the api to define aspects and adapters have been reworked (but dm API remains backward compatible)
-- support for [service scopes](http://felix.apache.org/documentation/subprojects/apache-felix-dependency-manager/reference/service-scopes.html)
-- you can now declare multiple property type interfaces when using Configuration Dependency or Factory Components (this was needed to implement the enhancements for the annotations)
-- configuration dependency using metatypes can now declare property types
-- Allow to specify if propagated configuration dependencies must override service service properties (it was not possible to override service properties with propagated service properties so far)
-- Added the following signatures in Component interface:
- * setInterface(Class serviceName, Dictionary properties)
- * setInterface(Class[] serviceNames, Dictionary properties)
-
-### Aspect/Adapters API enhancements
-
-So far, aspects or adapters were defined using many methods from DependencyManager or DependencyActivatorBase classes:
-
-For example, in DependencyManager.java, we have many signatures
-
- :::java
- public class DependencyManager {
- public Component createAdapterService(Class<?> serviceInterface, String serviceFilter) {...}
- public Component createAdapterService(Class<?> serviceInterface, String serviceFilter, String autoConfig) {...}
- public Component createAdapterService(Class<?> serviceInterface, String serviceFilter, String add, String change, String remove) {...}
- public Component createAdapterService(Class<?> serviceInterface, String serviceFilter, String add, String change, String remove, String swap) {...}
- public Component createAdapterService(Class<?> serviceInterface, String serviceFilter, String autoConfig, Object callbackInstance, String add, String change, String remove, String swap, boolean propagate) {...}
-
- public Component createFactoryConfigurationAdapterService(String factoryPid, String update, boolean propagate) {...}
- public Component createFactoryConfigurationAdapterService(String factoryPid, String update, boolean propagate, Object callbackInstance) {...}
- public Component createFactoryConfigurationAdapterService(String factoryPid, String update, boolean propagate, Class<?> configType) {...}
- public Component createFactoryConfigurationAdapterService(String factoryPid, String update, boolean propagate, Object callbackInstance, Class<?> configType) {...}
- public Component createAdapterFactoryConfigurationService(String factoryPid, String update, boolean propagate,String heading, String desc, String localization, PropertyMetaData[] propertiesMetaData) {...}
-
- public Component createBundleAdapterService(int bundleStateMask, String bundleFilter, boolean propagate) {...}
- public Component createBundleAdapterService(int bundleStateMask, String bundleFilter, boolean propagate, Object callbackInstance, String add, String change, String remove) {...}
-
- public Component createResourceAdapterService(String resourceFilter, boolean propagate, Object callbackInstance, String callbackChanged) {...}
- public Component createResourceAdapterService(String resourceFilter, boolean propagate, Object callbackInstance, String callbackSet, String callbackChanged)
- public Component createResourceAdapterService(String resourceFilter, Object propagateCallbackInstance, String propagateCallbackMethod, Object callbackInstance, String callbackChanged) {...}
- public Component createResourceAdapterService(String resourceFilter, Object propagateCallbackInstance, String propagateCallbackMethod, Object callbackInstance, String callbackSet, String callbackChanged) {...}
-
- public Component createAspectService(Class<?> serviceInterface, String serviceFilter, int ranking, String autoConfig) {...}
- public Component createAspectService(Class<?> serviceInterface, String serviceFilter, int ranking) {...}
- public Component createAspectService(Class<?> serviceInterface, String serviceFilter, int ranking, String add, String change, String remove) {...}
- public Component createAspectService(Class<?> serviceInterface, String serviceFilter, int ranking, String add, String change, String remove, String swap) {...}
- public Component createAspectService(Class<?> serviceInterface, String serviceFilter, int ranking, Object callbackInstance, String add, String change, String remove, String swap) {...}
-
-So, in this new release, we have simplified the usage of the aspect/adapters like this:
-instead of having to use some of the many methods from the DependencyManager or DependencyActivatorBase,
-we have added some new interfaces for the aspect and adapters, and these interfaces are extending the Component interface.
-All other existing methods have been moved to DependencyManagerCompat/DependencyActivatorBaseCompat classes and the
-DependencyManager/DependencyActovatorBase classes are now extending the compat classes: this allows to simplify the
-reading of the javadocs for DependencyManager/DependencyActovatorBase.
-
-For example, let's first show how an factory pid component was declared so far (a factory pid component is one which
-can be instantated multiple times using a "factory configuration" created using standard "configuration admin" service):
-
- :::java
- public class Activator extends DependencyActivatorBase {
- @Override
- public void init(BundleContext context, DependencyManager dm) throws Exception {
- dm.add(createFactoryConfigurationAdapterService("my.factory.pid", "updated", true, MyConfig.class)
- .setInterface(MyService.class.getName(), null)
- .setImplementation(MyServiceImpl.class)
- .add(createServiceDependency().setService(LogService.class))); // NullObject
- }
- }
-
-So, now, there is a new FactoryComponent interface which extends the Component interface and it contains all the
-various parameters used when declaring a factory pid component. So the example above becomes:
-
- :::java
- public class Activator extends DependencyActivatorBase {
- @Override
- public void init(BundleContext context, DependencyManager dm) throws Exception {
- dm.add(createFactoryComponent()
- .setFactoryPid("my.factory.pid")
- .setPropagate(true)
- .setConfigType(MyConfig.class)
- .setInterface(MyService.class.getName(), null)
- .setImplementation(MyServiceImpl.class)
- .add(createServiceDependency().setService(LogService.class))); // NullObject
- }
- }
-
-You will find the javadoc of the new dm api [here](http://felix.apache.org/apidocs/dependencymanager/r15)
-
-### Support for multiple configuration types in callbacks
-
-The ConfigurationDependency and Factory components can now support updated callbacks with multiple configuration types,
-for example, the following Activator defines a factory component (using the enhanced api) and multiple configuration
-types can now be provided:
-
- :::java
- public class Activator extends DependencyActivatorBase {
- @Override
- public void init(BundleContext context, DependencyManager dm) throws Exception {
- Component factoryComponent = createFactoryComponent()
- .setFactoryPid(pid).
- .setConfigType(MyConfig1.class, MyConfig2.class)
- .setImplementation(MyComponent.class);
- dm.add(factoryComponent);
- }
- }
-
- public class MyComponent {
- void updated(MyConfig1 cnf1, MyConfig2 cnf2) { ... }
- }
-
-Moreover, you can define a Dictionary parameter as the first argument in the updated callback, because sometimes,
-it's useful to be injected with the raw dictionary configuration, as well as with the configuration types.
-Example:
-
- :::java
- public class MyComponent {
- void updated(Dictionary<String, Object> rawConfig, MyConfig1 cnf1, MyConfig2 cnf2) { ... }
- }
-
-so, the new signatures for the updated callbacks are now the following (for both ConfigurationDependency and Factory Component):
-
- :::java
- updated(Dictionary cnf)
- updated(Component comp, Dictionary cnf)
- updated(Component comp, Property interfaces ...)
- updated(Property interfaces ...)
- updated(Dictionary cnf, Property interfaces ...)
- updated(Component comp, Dictionary cnf, Property interfaces ...)
-
-## Annotations enhancements and changes
-
-Essentially, the following enhancements and modifications have been done regarding annotations:
-
-- added support for new user defined property type annotations (similar to OSGI R7).
-- annotations using standard r7 @ComponentPropertyType are also supported. Indeed, not only declarative service is using this annotation, other r7 apis like jaxrs whiteboard are also defining some annotations that are themselves annotated with @ComponentPropertyType; so it is important to support this annotation (The dm annotation plugin has been enhanced by reusing some part of the ds annotation scanner from bndlib, which is full of reusable useful code which has been applied to dm (sca [...]
-- Allow ServiceDependency to auto detect the service type when the annotation is applied on a collection class field
-- removed FactoryComponentAdapterService (some attributes have been added in the Component annotation in order to declare factory pid components with the @Component annotation)
-- removed some old annotations / attributes. The attributes and annotations related to metatype have been removed since you can now use the standard metatype annotations. if users need to old version, then they can simply use the previous 4.2.1 from old dm annotation api. Notice that the dm runtime is compatible with old and new annotations version, so you can use latest dm annotation runtime and old annotation api.
-- removed "dereference" attribute in ServiceDependencyAnnotation, because we can now infer if the service dependency callbacks accepts a ServiceReference or a ServiceObjects parameter
-- propagated configuration dependencies are now taking precedence over component service properties, meaning that a component is defined with some service properties, then the service properties which are also found from the propagated configuration will be overriden (by the configuration properties)
-- Since some incompatible changes have been made, the major version of the annotation bundle has been bumped to 5.0.0.
-
-Please check new [dependency manager annotations doc](http://felix.apache.org/documentation/subprojects/apache-felix-dependency-manager/reference/dm-annotations.html)
-
-### Not backward compatible annotation changes
-
-The following has been removed in the annotation api:
-
-- removed FactoryConfigurationAdapterService annotation, which was too verbose. when you need to define some factory pid component, just reuse the @Component annotation and declare the new factoryPid/propagate/updated attributes that have been added in the @Component annotation
-- Removed PropertyMetadata annotation: it was related to metatypes, but as of today, osgi metatypes can be defined using standard metatype annotations. No need to support this anymore.
-- Removed ResourceAdapterService and ResourceDependency annotations because it was needed to depend on some classes from the dependency manager API. The DM Api should be used directly.
-- Removed the following attributes from the Component annotation: -- FACTORY_NAME -- FACTORY_INSTANCE -- factorySet -- factoryMethod These attributes were used to be able to create component instances multiple times. Now, simply use factoryPid Component attribute and use standard Configuration Admin in order to instantiate multiple instances of a given service (using factory configuration).
-- Removed PropertyMetaData annotation, which was related to osgi metatype. Simply use standard metatype annotation.
-- propagated configuration dependencies are now taking precedence over component service properties, meaning that a component is defined with some service properties, then the service properties which are also found from the propagated configuration will be overriden (by the configuration properties)
-
-## Usage of Java 9/10/11
-
-When using Java 9 / 10 / 11, then you can't use fluent service properties anymore with dm-lambda,
-because in these new jdk versions, the "-parameters" option does not generate lambda parameters
-metadata anymore. So, the following example won't work **using jdk 9/10/11**
-(but still works using Java 8):
-
- :::java
- component(comp -> comp.impl(Foo.class).provides(FooService.class, property -> "service property value"));
-
-With Java 9/10/11, use this instead:
-
- :::java
- component(comp -> comp.impl(Foo.class).provides(FooService.class, "property", "service property value"));
-
-The fluent service properties using lambda expression maybe removed in future DM version if a solution is not found to make it working with Java 9/10/11
\ No newline at end of file
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/guides/whatsnew.mdtext b/modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/guides/whatsnew.mdtext
deleted file mode 100644
index c6fa07d..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/guides/whatsnew.mdtext
+++ /dev/null
@@ -1,68 +0,0 @@
-Title: Dependency Manager - What's new in version 4?
-
-Even though the focus for this version is to completely redo the internals, we also added a few new features to the code. The most important one is the new thread model, described directly below. Apart from that we also added a few smaller features, enumerated below that.
-
-## New thread model
-
-DependencyManager 4 has been significantly reworked to improve support for concurrency. The following principles form the basis of the new concurrency model in DM4.
-
- * All external events that influence the state of dependencies are recorded and given to the serial executor of the component. We record whatever data comes in, so when the actual job is run by the serial executor, we still have access to the original data without having to access other sources whose state might have changed since.
- * The serial executor of a component will execute a job immediately if it is being called by the thread that is already executing jobs.
- * If the serial executor of a component had not yet started a job, it will queue and start it on the current thread.
- * If the serial executor gets invoked from a different thread than the one currently executing jobs, the job will be put at the end of the queue. As mentioned before, any data associated with the event will also be recorded so it is available when the job executes.
- * State in the component and dependency can only be modified via the serial executor thread. This means we don't need explicit synchronization anywhere.
-
-DependencyManager 4 now also supports parallel execution of component wiring.
-
-Added support for parallelism: To allow components to be started and handled in parallel, you can now register in the OSGi service registry a ComponentExecutorFactory service that is used to get an Executor for the management of all components dependencies/lifecycle callbacks. See javadoc from the org.apache.felix.dm.ComponentExecutorFactory interface for more information.
-
-You can also take a look at the the org.apache.felix.dependencymanager.samples project, which is registering a ComponentExecutorFactory from org.apache.felix.dependencymanager.samples.tpool bundle.
-
-See also the following property in the org.apache.felix.dependencymanager.samples/bnd.bnd
-
- org.apache.felix.dependencymanager.parallel=\
- '!org.apache.felix.dependencymanager.samples.tpool, *',\
-
-Here, all components will be handled by Executors provided by the ComponentExecutorFactory, except those having a package starting with "org.apache.felix.dependencymanager.samples.tpool" (because the threadpool is itself defined using the Dependency Manager API).
-
-You will find a full description of the new thread model in the [Reference](../reference/thread-model.html) section.
-
-## New features
-
-In addition, some new features have been implemented in dependency manager:
-
-* Auto Config Iterable fields: AutoConfig dependencies can be applied on Iterable<Service> fields in order to be able to traverse currently injected services safely. The Iterable must be parameterized with the Service type.
-[see this sample code](https://svn.apache.org/repos/asf/felix/trunk/dependencymanager/org.apache.felix.dependencymanager.samples/src/org/apache/felix/dependencymanager/samples/dictionary/api/SpellChecker.java) from the source distribution samples.
-
-* AutoConfig Map field: AutoConfig dependencies can be applied on a field with a Map<Service, Dictionary> type, allowing to traverse currently injected services safely, including service properties. The Map must be traversed using the Map.Entry iterator.
-See the *ServiceDependency.setAutConfig(boolean autoConfig)* [javadoc](http://felix.apache.org/apidocs/dependencymanager/4.0.0/org/apache/felix/dm/ServiceDependency.html) for more more informations.
-
-* Inject Configuration on separate callback instance (FELIX-2707): Configuration can be injected on a separate callback instance, like a CompositionManager for example.
-See the [composite factory example](https://svn.apache.org/repos/asf/felix/trunk/dependencymanager/org.apache.felix.dependencymanager.samples/src/org/apache/felix/dependencymanager/samples/compositefactory/) example available from the source distribution.
-
-* Added *propagate* flag in service Adapters (FELIX-4600): you can now choose to propagate or not adaptee service properties.
-
-* "Top" command in the shell: a "top" command is now available from the shell and can be used to display all top components sorted by their init/start elapsed time.
-
-* The Annotations plugin can now automatically generate a Require-Capability header on the Dependency Manager Runtime bundle.
-Use "add-require-capability=true" option in the plugin declaration property to enable this new feature (see FELIX-4676):
-
- -plugin: org.apache.felix.dm.annotation.plugin.bnd.AnnotationPlugin; add-require-capability=true
-
-* The Configuration Dependency annotation now supports a "name" attribute (FELIX-4777): allow to dynamically configure configuration pids from the @Init method.
-
-* Added a benchmark tool for dependency manager (not released, only available from the [trunk](https://svn.apache.org/repos/asf/felix/trunk/dependencymanager/org.apache.felix.dependencymanager.benchmark/).
-
-* The Annotations "Factory Sets" are deprecated (FELIX-4684): You can now use a DS-like ComponentFactory API by a nice api which is exported by the runtime bundle.
-See this [example](https://svn.apache.org/repos/asf/felix/trunk/dependencymanager/org.apache.felix.dependencymanager.samples/src/org/apache/felix/dependencymanager/samples/device/annot/DeviceAndParameterFactory.java) from the samples in the source distribution.
-
-* Since the R8 version, a new "`dm-lambda`" library has been introduced in the distribution. This new library allows to programmatically declare OSGi components using a new style based on java8 lambda expressions and other goodies like method references.
-
-* Since the R8 version, you can now provide "configuration types". Configuration types are a new feature that allows you to specify an interface that is implemented by DM and such interface is then injected to your configuration callback instead of an actual configuration dictionary.
-
-# Sample code
-
-The source distribution includes many sample codes which can be run directly under Eclipse and BndTools. The samples are available in the
-org.apache.felix.dependencymanager.samples/ module.
-Some of the samples require that you configure some pids or factory pids from Web Console, which can be accessed using *http://localhost:8080/system/console/configMgr* URL.
-Please consult org.apache.felix.dependencymanager.samples/README.samples for up to date instructions on how to execute the various examples.
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/reference/component-adapter.mdtext b/modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/reference/component-adapter.mdtext
deleted file mode 100644
index 5276c3f..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/reference/component-adapter.mdtext
+++ /dev/null
@@ -1,44 +0,0 @@
-Title: Dependency Manager - Adapter
-
-Adapters, like [aspects](component-aspect.html), are used to "extend" existing services, and can publish
-different services based on the existing one. An example would be implementing a management interface.
-
-An adapter will be applied to any service that matches the specified interface and filter.
-For each matching service an adapter will be created based on the adapter implementation class.
-The adapter will be registered with the specified interface and existing properties from the original
-service plus any extra properties you supply here. It will also inherit all dependencies, and if you declare
-the original service as a member it will be injected.
-
-To define an adapter component, you need to create an [AdapterComponent](http://felix.apache.org/apidocs/dependencymanager/r13/org/apache/felix/dm/AdapterComponent.html) component
-using the DependencyActivatorBase.createAdapterComponent() or the DependencyManager.createAdapterComponent() method.
-This interface extends the Component interface in order to add extra setters methods needed to define an adapter service component.
-
-## Usage example
-
-Here is a sample showing a HelloServlet adapter component which creates a servlet each time a HelloService is registered in the osgi service registry with the "foo=bar" service property.
-
- :::java
- public class Activator extends DependencyActivatorBase {
- &Override
- public void init(BundleContext context, DependencyManager dm) throws Exception {
- Component adapterComponent = createAdapterComponent()
- .setAdaptee(HelloService.class, "(foo=bar)")
- .setInterface(HttpServlet.class.getName(), null)
- .setImplementation(HelloServlet.class);
- dm.add(adapterComponent);
- }
- }
-
- public interface HelloService {
- String sayHello();
- }
-
- public class HelloServlet extends HttpServlet {
- volatile HelloService adatpee; // injected
-
- void doGet(HttpServletRequest req, HttpServletResponse resp) {
- ...
- resp.getWriter().println(adaptee.sayHello());
- }
- }
-
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/reference/component-aspect.mdtext b/modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/reference/component-aspect.mdtext
deleted file mode 100644
index 867050e..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/reference/component-aspect.mdtext
+++ /dev/null
@@ -1,35 +0,0 @@
-Title: Dependency Manager - Aspect
-
-Aspects, as part of aspect oriented programming, can be used in a dynamic environment
-such as OSGi to "extend" existing services and add certain "capabilities" to them.
-Examples of these are adding a specific caching mechanism to a storage service or
-implementing logging. Aspects in OSGi can be applied to services and can be added and
-removed at runtime.
-
-To define an aspect component, you need to create an [AspectComponent](http://felix.apache.org/apidocs/dependencymanager/r13/org/apache/felix/dm/AspectComponent.html) component
-using the DependencyActivatorBase.createAspectComponent() or the DependencyManager.createAspectComponent() method.
-This interface extends the Component interface in order to add extra setters methods needed to define an aspect service component.
-
-
-Usage example:
-
-In this example, a "DatabaseCache" aspect service is used to add caching functionality
-to an existing Database service. Here is the DatabaseCache aspect service will sit
-between any Database service consumer and the original Database service:
-
- :::java
- interface Database {
- String get(String key);
- }
-
- public class Activator extends DependencyActivatorBase {
- &Override
- public void init(BundleContext context, DependencyManager dm) throws Exception {
- Component aspectComponent = createAspectComponent()
- .setAspect(Database.class, null, 10)
- .setImplementation(DatabaseCache.class)
- .add(createServiceDependency().setService(LogService.class).setRequired(false));
- dm.add(aspectComponent);
- }
- }
-
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/reference/component-bundle-adapter.mdtext b/modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/reference/component-bundle-adapter.mdtext
deleted file mode 100644
index 9e5ac28..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/reference/component-bundle-adapter.mdtext
+++ /dev/null
@@ -1,35 +0,0 @@
-Title: Dependency Manager - Bundle Adapter
-
-Bundle adapters are similar to AdapterService, but instead of adapting a
-service, they adapt a bundle with a certain set of states (STARTED|INSTALLED|...),
-and provide a service on top of it.
-
-The bundle adapter will be applied to any bundle that matches the specified
-bundle state mask and filter conditions, which may match some of the bundle
-OSGi manifest headers. For each matching bundle an adapter will be created
-based on the adapter implementation class. The adapter will be registered
-with the specified interface and with service properties found from the
-original bundle OSGi manifest headers plus any extra properties you supply
-here. If you declare the original bundle as a member it will be injected.
-
-To define a bundle adapter component, you need to create a [BundleComponent](http://felix.apache.org/apidocs/dependencymanager/r13/org/apache/felix/dm/BundleComponent.html) component
-using the DependencyActivatorBase.createBundleComponent() or the DependencyManager.createBundleComponent() method.
-
-This interface extends the Component interface in order to add extra setters methods needed to define a bundle adapter service component.
-
-
-## Example usage
-
-In the following example, a "VideoPlayer" Service is registered into the OSGi registry each time an active bundle containing a "Video-Path" manifest header is detected:
-
- :::java
- public class Activator extends DependencyManagerActivator {
- public void init(BundleContext ctx, DependencyManager dm) throws Exception {
- Component c = dm.createBundleComponent()
- .setBundleFilter(Bundle.ACTIVE, "(Video-Path=*)")
- .setInterface(VideoPlayer.class.getName(), new Hashtable() {{ put("foo", "bar"); }})
- .setImplementation(VideoPlayerImpl.class);
- dm.add(c);
- }
- }
-
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/reference/component-factory-configuration-adapter.mdtext b/modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/reference/component-factory-configuration-adapter.mdtext
deleted file mode 100644
index f633e80..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/reference/component-factory-configuration-adapter.mdtext
+++ /dev/null
@@ -1,44 +0,0 @@
-Title: Dependency Manager - Factory Configuration Adapter Service
-
-A factory configuration adapter service creates an adapter for each matching configuration in
-Configuration Admin. For each new factory configuration matching the factoryPid, an adapter will be
-created based on the adapter implementation class. The adapter will be registered with the specified
-interface and with the specified adapter service properties. Depending on the propagate parameter, every
-public factory configuration properties (which don't start with ".") will be propagated along with the
-adapter service properties. It will also inherit all dependencies.
-
-To define an adapter component, you need to create an [FactoryComponent](http://felix.apache.org/apidocs/dependencymanager/r13/org/apache/felix/dm/FactoryComponent.html) component
-using the DependencyActivatorBase.createFactoryComponent() or the DependencyManager.createFactoryComponent() method.
-The FactoryComponent interface extends the Component interface in order to add extra setters methods needed to define a factory configuration adapter service component.
-
-
-Example usage:
-
-Here is a sample showing a "MyComponent" component, which can be instantiated multiple times using a factory configuration:
-
- :::java
- public interface MyConfig {
- int getPort();
- String getAddress();
- }
-
- public class MyComponent implements MyService {
- void updated(MyConfig cnf) {
- int port = cnf.getPort();
- String addr = cnf.getAddress();
- ...
- }
- }
-
- public class Activator extends DependencyActivatorBase {
- &Override
- public void init(BundleContext context, DependencyManager dm) throws Exception {
- Component factoryComponent = createFactoryComponent()
- .setFactoryPid("my.factory.pid")
- .setInterface(MySevice.class.getName(), null)
- .setImplementation(MyComponent.class)
- .setConfigType(MyConfig.class);
- dm.add(factoryComponent);
- }
- }
-
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/reference/component-resource-adapter.mdtext b/modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/reference/component-resource-adapter.mdtext
deleted file mode 100644
index fbbcd1c..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/reference/component-resource-adapter.mdtext
+++ /dev/null
@@ -1,114 +0,0 @@
-Title: Dependency Manager - Resource Adapter
-
-Resource adapters work just like adapters, but instead of working with services, they work with resources.
-Resources, represented as a URL, are an abstraction introduced to provide a generic way of dealing with
-"blobs" and can be resources inside a bundle, filesystem or some kind of data store.
-
-A resource adapter will be applied to any resource that matches the specified filter condition.
-For each matching resource an adapter will be created based on the adapter implementation class.
-The adapter will be registered with the specified interface and existing properties from the original
-resource plus any extra properties you supply here. It will also inherit all dependencies,
-and if you declare the original service as a member it will be injected.
-
-To define a resource adapter, you first need to create a [ResourceComponent](http://felix.apache.org/apidocs/dependencymanager/r13/org/apache/felix/dm/ResourceComponent.html)
-component using the DependencyActivatorBase.createResourceComponent() or the DependencyManager.createResourceComponent() method.
-
-The ResourceComponent extends the [Component](http://felix.apache.org/apidocs/dependencymanager/r13/org/apache/felix/dm/Component.html) and provides some additional
-setter methods related to resource adapters.
-
-
-Usage Example:
-
-Here, the "VideoPlayer" service provides a video service on top of any movie
-resources, with service properties "host"/"port"/"protocol"/"path" extracted
-from the resource URL. There will be one VideoPlayerImpl instantiated and started for each
-available URL:
-
- :::java
- public class VideoPlayerImpl implements VideoPlayer {
- // Injected by reflection
- volatile URL resource;
-
- void play() {} // play video referenced by this.resource
- void stop() {} // stop playing the video
- void transcode() {} // ...
- }
-
- public class Activator extends DependencyManagerActivator {
- public void init(BundleContext ctx, DependencyManager dm) throws Exception {
- Component c = manager.createResourceComponent()
- .setResourceFilter("(&(path=/videos/*.mkv)(host=localhost))")
- .setPropate(true)
- .setInterface(VideoPlayer.class.getName(), new Hashtable() {{ put("foo", "bar"); }})
- .setImplementation(VideoPlayerImpl.class);
- dm.add(c);
- }
- }
-
-Notice that resource adapters are only supported with the DM API, not using annotations or using DM lambda.
-
-Now, here is the resource provider, which provides two URLS:
-
- :::java
- public class Activator extends DependencyActivatorBase {
- @Override
- public void init(BundleContext ctx, DependencyManager dm) throws Exception {
- // add resource provider
- URL[] resourceURLs = new URL[] {
- new URL("file://localhost/path/to/file1.txt"),
- new URL("file://localhost/path/to/file2.txt")
- };
-
- Component resourceProvider = createComponent()
- .setImplementation(new ResourceProvider(ctx, resourceURLs))
- .add(dm.createServiceDependency().setService(ResourceHandler.class).setCallbacks("add", "remove"));
- dm.add(resourceProvider);
- }
- }
-
- class ResourceProvider {
- final URL[] m_resources;
- final BundleContext m_context;
- final Map<ResourceHandler, Filter> m_handlers = new HashMap<>();
-
- ResourceProvider(BundleContext ctx, URL ... resources) {
- m_context = ctx;
- m_resources = resources;
- }
-
- public void add(ServiceReference<?> ref, ResourceHandler handler) {
- String filterString = (String) ref.getProperty("filter");
- Filter filter = null;
- if (filterString != null) {
- try {
- filter = m_context.createFilter(filterString);
- }
- catch (InvalidSyntaxException e) {
- return;
- }
- }
- for (int i = 0; i < m_resources.length; i++) {
- if (filter == null || filter.match((Dictionary<String, ?>) ResourceUtil.createProperties(m_resources[i]))) {
- synchronized (m_handlers) {
- m_handlers.put(handler, filter);
- }
- handler.added(m_resources[i]);
- }
- }
- }
-
- public void remove(ServiceReference<?> ref, ResourceHandler handler) {
- Filter filter;
- synchronized (m_handlers) {
- filter = (Filter) m_handlers.remove(handler);
- }
- if (filter != null) {
- for (int i = 0; i < m_resources.length; i++) {
- if (filter == null || filter.match((Dictionary<String, ?>) ResourceUtil.createProperties(m_resources[i]))) {
- handler.removed(m_resources[i]);
- }
- }
- }
- }
- }
-
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/reference/component-singleton.mdtext b/modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/reference/component-singleton.mdtext
deleted file mode 100644
index a742373..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/reference/component-singleton.mdtext
+++ /dev/null
@@ -1,63 +0,0 @@
-Title: Dependency Manager - Singleton Component
-
-Components are the main building blocks for OSGi applications. They can publish themselves as a service, and they can have dependencies. These dependencies will influence their life cycle as component will only be activated when all required dependencies are available.
-
-## Example usage
-
-To define a singleton component, you can use the DependencyActivatorBase.createComponent() or
-the DependencyManager.createComponent() method,
-like in the following example which defines a "TranslationService" osgi service having one required
-dependency on the "LocalizationService" and one optional dependency on a "LogService".
-Dependencies are optional by default, unless you invoke the ServiceDependency.setRequired(boolean) method:
-
- :::java
- public class GoogleBasedTranslationService implements TranslationService {
- volatile LocalizationService m_localizationService; // injected by reflection
- volatile LogService m_log;
-
- ...
- }
-
- public class Activator extends DependencyActivatorBase {
- public void init(BundleContext ctx, DependencyManager dm) throws Exception {
- Component c = createComponent()
- .setInterface(TranslationService.class.getName(), null)
- .setImplementation(GoogleBasedTranslationService.class)
- .add(createServiceDependency()
- .setService(LocalizationService.class, "(language=en)")
- .setRequired(true))
- .add(createServiceDependency()
- .setService(LogService.class)
- .setRequired(false)));
- dm.add(c);
- }
- }
-
-
-You can also inject dependencies using callbacks:
-
- :::java
- public class GoogleBasedTranslationService implements TranslationService {
- volatile LocalizationService m_localizationService; // injected by reflection
- void bind(LogService log {...}
- ...
- }
-
- public class Activator extends DependencyActivatorBase {
- public void init(BundleContext ctx, DependencyManager dm) throws Exception {
- Component c = createComponent()
- .setInterface(TranslationService.class.getName(), null)
- .setImplementation(GoogleBasedTranslationService.class)
- .add(createServiceDependency()
- .setService(LocalizationService.class, "(language=en)")
- .setRequired(true))
- .add(createServiceDependency()
- .setService(LogService.class)
- .setCallbacks("bind", null /* no unbind method */)
- .setRequired(false)));
- dm.add(c);
- }
- }
-
-Notice that when you define an optional dependency without using callbacks, then a "NullObject" method is injected in the class field (by reflection) when the actual optional service is not available. In this case any invocation on the optional service won't do anything.
-
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/reference/components.mdtext b/modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/reference/components.mdtext
deleted file mode 100644
index cfe2d2b..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/reference/components.mdtext
+++ /dev/null
@@ -1,227 +0,0 @@
-Title: Dependency Manager - Components
-
-Components are declared by the dependency manager and can be implemented by POJOs that contain no references to the OSGi framework whatsoever. Components are the main building blocks of your OSGi application. They have a life cycle, can register themselves as services and have zero or more dependencies.
-
-You can either use the Java API or the Java Annotations and this reference section describes both.
-
-## Types of Components
-
-There are different types of Dependency Manager components:
-
-* [*Component*](component-singleton.html): Components are the main building blocks for OSGi applications. They can publish themselves as a service, and/or they can have dependencies. These dependencies will influence their life cycle as component will only be activated when all required dependencies are available.
-* [*Aspect Service*](component-aspect.html): A service that provides a non-functional aspect on top of an existing service. In aspect oriented programming, an aspect, or interceptor can sit between a client and another target service used by the client. An Aspect Service first tracks a target service and is created once the target service is detected. Then the Aspect Service is provided, but with a higher ranking, and the client is transparently updated with the aspect. Aspects can be c [...]
-* [*Adapter Service*](component-adapter.html): A Service that adapts another existing service into a new one. Like with aspects, sometimes you want to create adapters for certain services, which add certain behavior that results in the publication of (in this case) a different service. Adapters can dynamically be added and removed and allow you to keep your basic services implementations clean and simple, adding extra features on top of them in a modular way.
-* [*Bundle Adapter Service*](component-bundle-adapter.html): creates an OSGi service a service on top of a given bundle.
-* [*Resource Adapter Service*](component-resource-adapter.html): creates an OSGi service on top of a specific Resource.
-* [*Factory Configuration Adapter Service*](component-factory-configuration-adapter.html): creates an OSGi service from ConfigAdmin, using a factoryPid, and a ManagedServiceFactory.
-
-## Life cycle
-
-The dependency manager, as part of a bundle, shares the generic bundle life cycle explained in the OSGi specification. The life cycle of the dependency manager itself, and the components it manages, can be located inside the *active* state of the hosting bundle.
-
-Each component you define gets its own life cycle, which is explained in the state diagram below.
-
-<img src="./diagrams/statediagram.png" alt="State diagram" style="width: 430px"/>
-
-A component is associated with an instance. This instance can either be specified directly, or you can specify its class. If you do the latter, the actual instance will be created lazily.
-
-Changes in the state of the component will trigger the following life cycle methods:
-
-* `init`,
-* `start`,
-* `stop` and
-* `destroy`.
-
-The dependency manager will look for methods with these names and one of the following signatures in this order:
-
-* `(Component)`,
-* `()`.
-
-If you don't specify anything, the methods with these names will be invoked on the instance. By using `setCallbacks()` you can however change this behavior: You can change the names of the methods to look for. Any methods that are set to ` null ` will not be invoked at all. Another thing you can do is to specify a different instance to invoke these methods on. If you do that, you will usually want to use the first signature, which gives you a reference to the ` Component ` whose life cyc [...]
-
-Here is a descrition of the component states:
-
-* *Inactive state*: The Component is defined, but not enabled (not yet added to a
-DependencyManager object, or the bundle has been stopped).
-* *Waiting for required* state: The Component is enabled (has been added to a
-DependencyManager object) and the required dependencies declared in the Activator are
-tracked. The component remains in the current state until all required dependencies are
-available.
-* *Instantiated and waiting for required* state: All required dependencies declared
-in the Activator are available. The Component has been instantiated with required dependencies injected,
-and has been invoked in the *init* callback. Now, if some extra required dependencies have
-been dynamically added in the *init* callback, then the component remains in the
-current state until all extra required dependencies become available.
-* *Tracking optional*: All Required dependencies are injected (including the ones
-you dynamically added from the *init* method), the component *start* callback
-is called, the component service is registered in the OSGi registry, and finally the optional dependencies (with callbacks) are
-then tracked.
-
-
-## What happens during component instantiation ?
-
-1. The service is instantiated.
-2. The following special objects are injected through reflection on class fields, if
-they exist (but you can deactivate this behavior from the API):
- * BundleContext
- * ServiceRegistration
- * DependencyManager
- * Component
-3. *autoconfig* dependencies are injected through reflection on class fields, if they exist. If an *autoconfig*
-optional dependency is unavailable, a NullObject is then injected.
-4. Required dependency callbacks defined from the Activator are called.
-5. The component *init* method is called, and from that method you can then dynamically add
-more dependencies by using the Component parameter passed to the init method, or using
-a class field of *Component* type (which in this case has been injected during step 2).
-6. When all required dependencies (including dependencies dynamically added from the *init*
-method) are available, they are injected (using callbacks, or autoconfig).
-7. The component *start* callback is invoked.
-8. Optional dependencies (with callbacks) are then tracked.
-9. The component service(s) is then registered in the OSGi service registry
-
-When using Annotations, there are some specific behaviors:
-
-* The *@init* method may return a Map that contains filters in order to
-dynamically configure dependencies annotated with a *name* attribute, and the dependencies will
-then be injected after the *@init* method (exactly if you would have added the dependencies from the init method using the API).
-* The *@start* method may return a Map in order to dynamically add more service properties (if the component provides some services).
-* The component can be dynamically stopped or restarted using a special *@LifecycleController* annotation.
-
-## Interfaces and properties
-
-Components in the context of the dependency manager can be published as OSGi services under one or more interface names, plus optionally a set of properties. This is no different than a normal OSGi service. It's important to mention that you don't have to register a service. If you don't, you basically created a component that can do work and have dependencies and a managed life cycle.
-
-## Composition
-
-When implementing more complex components, you often find yourself using more than one
-instance. However, several of these instances might want to have dependencies injected.
-In such cases you need to tell the dependency manager which instances to consider.
-This has to be a fixed set of instances however.
-
-We now describe how to declare a service composition using the Api, and the Annotations:
-
-Example:
-
-When using the DependencyManager API, you can use the *Component.setComposition* method to declare a special callback in your component that
-returns the list of object that are part of the component, and all dependencies and lifecycle callbacks will be invoked
-on the objects returned by the method. Let's take an example, with a *ProviderImpl* top-level service implementation
-that is internally implemented using three Pojos: *ProviderImpl*, *ProviderParticipant1*, and
-*ProviderParticipant2*:
-
- :::java
- public class ProviderImpl implements Provider {
- private final ProviderParticipant1 m_participant1 = new ProviderParticipant1();
- private final ProviderParticipant2 m_participant2 = new ProviderParticipant2();
- private volatile LogService m_log; // injected
-
- Object[] getComposition() {
- return new Object[] { this, m_participant1, m_participant2 };
- }
-
- void start() {
- m_log.log(LogService.LOG_INFO, "ProviderImpl.start(): participants=" + m_participant1 + "," + m_participant2
- + ", conf=" + m_conf);
- }
- }
-
- public class ProviderParticipant1 {
- private volatile LogService m_log; // also injected since we are part of the composition
-
- void start() {
- m_log.log(LogService.LOG_INFO, "ProviderParticipant1.start()");
- }
- }
-
- public class ProviderParticipant2 {
- private volatile LogService m_log; // also injected since we are part of the composition
-
- void start() {
- m_log.log(LogService.LOG_INFO, "ProviderParticipant2.start()");
- }
- }
-
-And here is the Activator, which uses the *setComposition* method:
-
- :::java
- public class Activator extends DependencyActivatorBase {
- public void init(BundleContext ctx, DependencyManager m) throws Exception {
- m.add(createComponent()
- .setImplementation(ProviderImpl.class)
- .setComposition("getComposition")
- .add(createServiceDependency().setService(LogService.class).setRequired(true)));
- }
- }
-
-
-## Factories
-
-Out of the box, there already is support for lazy instantiation, meaning that the dependency manager can create component instances for you when their required dependencies are resolved. However, sometimes creating a single instance using a default constructor is not enough. In those cases, you can tell the dependency manager to delegate the creation process to a factory.
-
-Interestingly, you can also mix the usage of a Factory object and a Composition of objects returned by the Factory.
-The following is the same example as in the previous section (Composition), but using a Factory approach in order to instantiate a composition of objects:
-The "ProviderFactory" is first injected with a Configuration that can possibly be used to create
-and configure all the other objects that are part of the composition; each object will also be injected with
-the dependencies defined in the Activator.
-
- :::java
- public class ProviderFactory {
- private ProviderParticipant1 m_participant1;
- private ProviderParticipant2 m_participant2;
- private ProviderImpl m_providerImpl;
- private Dictionary<String, String> m_conf;
-
- public void updated(Dictionary<String, String> conf) throws Exception {
- // validate configuration and throw an exception if the properties are invalid
- m_conf = conf;
- }
-
- /**
- * Builds the composition of objects used to implement the "Provider" service.
- * The Configuration injected by Config Admin will be used to configure the components
- * @return The "main" object providing the "Provider" service.
- */
- Object create() {
- // Here, we can instantiate our object composition based on our injected configuration ...
-
- if ("true".equals(m_conf.get("some.parameter")) {
- m_participant1 = new ProviderParticipant1(); // depenencies and lifecycle callbacks will also be applied
- m_participant2 = new ProviderParticipant2(); // depenencies and lifecycle callbacks will also be applied
- } else {
- // Compose with some other objects ...
- m_participant1 = new ProviderParticipant3(); // depenencies and lifecycle callbacks will also be applied
- m_participant2 = new ProviderParticipant4(); // depenencies and lifecycle callbacks will also be applied
- }
-
- m_providerImpl = new ProviderImpl(m_participant1, m_participant2);
- return m_providerImpl; // Main object implementing the Provider service
- }
-
- /**
- * Returns the list of objects that are part of the composition for the Provider implementation.
- */
- Object[] getComposition() {
- return new Object[] { m_providerImpl, m_participant1, m_participant2 };
- }
- }
-
-
-And here is the Activator: notice the *setFactory* method that specifies the factory to use to create the implementation.
-Also pay attention to the *setComposition* method, which indicates the method to call in order to get all instances that
-are part of a composition and need dependencies injected:
-
- :::java
- public class Activator extends DependencyActivatorBase {
- public void init(BundleContext ctx, DependencyManager m) throws Exception {
- ProviderFactory factory = new ProviderFactory();
- m.add(createComponent()
- .setFactory(factory, "create") // factory.create() will return the implementation instance
- .setComposition(factory, "getComposition")
- .add(createConfigurationDependency()
- .setPid("some.pid")
- .setCallback(factory, "updated")) // will invoke "updated" on the factory instance
- .add(createServiceDependency().setService(LogService.class).setRequired(true)));
- }
- }
-
-You can refer to this [sample code](https://svn.apache.org/repos/asf/felix/trunk/dependencymanager/org.apache.felix.dependencymanager.samples/src/org/apache/felix/dependencymanager/samples/compositefactory/), which is part of the source distribution.
-
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/reference/dependencies.mdtext b/modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/reference/dependencies.mdtext
deleted file mode 100644
index 1f10d08..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/reference/dependencies.mdtext
+++ /dev/null
@@ -1,32 +0,0 @@
-Title: Dependency Manager - Dependencies
-
-The dependency manager supports many different types of dependencies, all of which can be required or optional. A dependency can be added to one or more components and it is possible to add them dynamically (even from within the component itself if necessary, which allows for some really dynamic dependency configuration).
-
-## Injection
-
-One way to deal with dependencies is to have them injected into your component instances automatically. All you need to do is simply declare a field of the same type as your dependency, make the member volatile so any changes will become visible immediately and you're done. If a dependency is optional, a null object will be injected if the dependency is not available.
-
-Sometimes you need more control over injection, so optionally you can even specify the name of the field to inject into. This allows you to depend on different dependencies of the same type, or simply to prevent injection into more than one field.
-
-## Callbacks
-
-When keeping track of multiple instances of a dependency, or when you simply want something to happen whenever a dependency becomes (un)available or changes, you can define callbacks, like `added`, `changed` and `removed`. Optionally, you can provide the dependency manager with an instance to invoke these callback methods on. If you don't, they'll be invoked on the component instance.
-
-## Types of Dependencies
-
-Out of the box, several types of dependencies are supported:
-
-* [Service](dependency-service.html)
-* [Configuration](dependency-configuration.html)
-* [Bundle](dependency-bundle.html)
-* [Resource](dependency-resource.html)
-
-However, it's quite easy to add your own custom type of dependency too, as is described below.
-
-## Implementing Your Own Dependency
-
-All dependencies share a common API which you can implement yourself if you need a special type of dependency. Whilst not entirely trivial, this allows you to create your own types of dependencies. This can be useful for various scenarios where you want to have components that depend on things that are not services, bundles or configuration.
-
-An example implementation can be found in the samples available in the source distribution.
-In the org.apache.felix.dependencymanager.samples module, you can refer to src/org/apache/felix/dependencymanager/samples/customdep/README file,
-which describes a custom "PathDependency" that tracks files that are added or removed from /tmp/ directory.
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/reference/dependency-bundle.mdtext b/modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/reference/dependency-bundle.mdtext
deleted file mode 100644
index 66412d5..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/reference/dependency-bundle.mdtext
+++ /dev/null
@@ -1,34 +0,0 @@
-Title: Dependency Manager - Bundle Dependency
-
-A bundle dependency allows you to depend on a bundle in a certain set of states, as indicated by a state mask.
-You can also use a filter condition that is matched against all manifest entries. Finally you can provide a
-reference to an existing bundle.
-
-To define a bundle dependency, you need to use the [BundleDependecy](http://felix.apache.org/apidocs/dependencymanager/r13/org/apache/felix/dm/BundleDependency.html) interface.
-This interface can be created using DependencyActivatorBase.createBundleDependency() or DependencyManager.createBundleDependency() methods;
-
-Here is an example of a component which tracks all ACTIVE bundles having a Service-Component header in the manifest:
-
-
- :::java
- public class Activator extends DependencyActivatorBase {
- @Override
- public void init(BundleContext ctx, DependencyManager dm) throws Exception {
- Component scr = createComponent()
- .setImplementation(ScrRuntime.class)
- .add(createBundleDependency().setFilter("(Service-Component=*").setStateMask(Bundle.ACTIVE).setCallbacks("bind", "unbind"));
- }
- }
-
- public class ScrRuntime {
- void bind(Bundle bundle) {
- // load SCR descriptors from the starting bundle
- }
-
- void unbind(Bundle bundle) {
- // unload SCR descriptors from the starting bundle
- }
- }
-
-The dependency is optional by default, and will invoke the ScrRuntime.bind callback each time a bundle containing some Declarative Service component is started.
-
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/reference/dependency-configuration.mdtext b/modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/reference/dependency-configuration.mdtext
deleted file mode 100644
index f42cbf1..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/reference/dependency-configuration.mdtext
+++ /dev/null
@@ -1,105 +0,0 @@
-Title: Dependency Manager - Configuration Dependency
-
-A configuration dependency is always required, and allows you to depend on the availability of a valid
-configuration for your component. Configuration dependency is required by default.
-
-To define a configuration dependency, you need to use the [ConfigurationDependency](http://felix.apache.org/apidocs/dependencymanager/r13/org/apache/felix/dm/ConfigurationDependency.html) interface.
-This interface can be created using DependencyActivatorBase.createConfigurationDependency() or DependencyManager.createConfigurationDependency() methods.
-
-
-The dependency injects by default the configuration in an "updated" callback which can accept the following parameters:
-
-- `updated(Dictionary)`
-- `updated(Component, Dictionary)`
-- `updated(<ConfigurationType>)`
-- `updated(Component, <ConfigurationType>)`
-
-If you only specify a pid, by default the callback method name is assumed to be "updated".
-
-Configuration types are a new feature that allows you to specify a Java interface that is implemented by DM and such interface is then injected to your callback instead of the actual Dictionary. Using such configuration interface provides a way for creating type-safe configurations from a actual Dictionary that is normally injected by Dependency Manager. The callback accepts in argument an interface that you have to provide, and DM will inject a proxy that converts method calls from your [...]
-As proxies are injected, no implementations of the desired configuration-type are necessary!
-
-The lookups performed are based on the name of the method called on the configuration type. The method names are "mangled" to the following form: [lower case letter] [any valid character]*. Method names starting with get or is (JavaBean convention) are stripped from these prefixes. For example: given a dictionary with the key "foo" can be accessed from a configuration-type using the following method names: foo(), getFoo() and isFoo().
-
-The return values supported are:
-
-- primitive types (or their object wrappers);
-- strings;
-- enums;
-- arrays of primitives/strings;
-- Collection types;
-- Map types;
-- Classes and interfaces.
-
-When an interface is returned, it is treated equally to a configuration type, that is, a proxy is returned.
-
-Arrays can be represented either as comma-separated values, optionally enclosed in square brackets. For example: `[ a, b, c ]` and `a, b,c` are both considered an array of length 3 with the values "a", "b" and "c". Alternatively, you can append the array index to the key in the dictionary to obtain the same: a dictionary with "arr.0" => "a", "arr.1" => "b", "arr.2" => "c" would result in the same array as the earlier examples.
-
-Maps can be represented as single string values similarly as arrays, each value consisting of both the key and value separated by a dot. Optionally, the value can be enclosed in curly brackets. Similar to array, you can use the same dot notation using the keys. For example, a dictionary with:
-
- map={key1.value1,key2.value2}
-
-and a dictionary with:
-
- map.key1=value1
- map.key2=value2
-
-result in the *same* map being returned. Instead of a map, you could also define an interface with the methods `getKey1()` and `getKey2()` and use that interface as return type instead of a Map.
-
-In case a lookup does not yield a value from the underlying map or dictionary, the following rules are applied:
-
-- primitive types yield their default value, as defined by the Java Specification;
-- string, Classes and enum values yield `null`;
-- for arrays, collections and maps, an *empty* array/collection/map is returned;
-- for other interface types that are treated as configuration type a Null-object is returned.
-
-Here is a component depends on a configuration:
-
- :::java
- public class ServiceImpl {
- void updated(Dictionary<String, Object> cnf) {
- if (cnf != null) {
- String addr = (String) cnf.get("address");
- int port = Integer.valueOf(cnf.get("port");
- ...
- }
- }
- }
-
- public class Activator extends DependencyActivatorBase {
- @Override
- public void init(BundleContext ctx, DependencyManager dm) throws Exception {
- dm.add(createComponent()
- .setImplementation(ServiceImpl.class)
- .add(createConfigurationDependency().setPid(ServiceImpl.class.getName()));
- }
- }
-
-Here is the same example, but a custom configuration type interface is used
-(by default, the FQDN of the configuration type is assumed to be the configuration pid):
-
- :::java
- public interface MyConfig {
- String getAddress();
- int getPort();
- }
-
- public class ServiceImpl {
- void modified(MyConfig cnf) {
- if (cnf != null) {
- String addr = cnf.getAddress();
- int port = cnf.getPort();
- ...
- }
- }
- }
-
- public class Activator extends DependencyActivatorBase {
- @Override
- public void init(BundleContext ctx, DependencyManager dm) throws Exception {
- dm.add(createComponent()
- .setImplementation(ServiceImpl.class)
- .add(createConfigurationDependency().setCallback("modified", MyConfig.class);
- }
- }
-
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/reference/dependency-resource.mdtext b/modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/reference/dependency-resource.mdtext
deleted file mode 100644
index dec0c2e..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/reference/dependency-resource.mdtext
+++ /dev/null
@@ -1,93 +0,0 @@
-Title: Dependency Manager - Resource Dependency
-
-A resource dependency allows you to depend on a resource. A resource is a URL and you can use a filter
-condition based on protocol, host, port, path and URL.
-
-To define a resource dependency, you need to use the [ResourceDependecy](http://felix.apache.org/apidocs/dependencymanager/r13/org/apache/felix/dm/ResourceDependency.html) interface.
-This interface can be created using DependencyActivatorBase.createResourceDependency() or DependencyManager.createResourceDependency() methods;
-
-Here is an example where a bundle activation declares a VideoPlayer component which depends on a resource URL.
-The component uses an optional dependency callback, which is invoked each time an URL is registered.
-
- :::java
- public class Activator extends DependencyActivatorBase {
- @Override
- public void init(BundleContext ctx, DependencyManager dm) throws Exception {
- Component videoPlayer = createComponent()
- .setImplementation(VideoPlayer.class)
- .add(createResourceDependency().setFilter("(&(path=/path/to/*.txt)(host=localhost))").setCallbacks("play", null));
- dm.add(videoPlayer);
- }
- }
-
- public class VideoPlayer {
- void play(URL url) {
- System.out.println("play: " + url);
-
- }
- }
-
-
-And here is a component which registers some URL resources:
-
- :::java
- public class Activator extends DependencyActivatorBase {
- @Override
- public void init(BundleContext ctx, DependencyManager dm) throws Exception {
- // add resource provider
- URL[] resourceURLs = new URL[] {
- new URL("file://localhost/path/to/file1.txt"),
- new URL("file://localhost/path/to/file2.txt")
- };
-
- Component resourceProvider = createComponent()
- .setImplementation(new ResourceProvider(ctx, resourceURLs))
- .add(dm.createServiceDependency().setService(ResourceHandler.class).setCallbacks("add", "remove"));
- dm.add(resourceProvider);
- }
- }
-
- class ResourceProvider {
- final URL[] m_resources;
- final BundleContext m_context;
- final Map<ResourceHandler, Filter> m_handlers = new HashMap<>();
-
- ResourceProvider(BundleContext ctx, URL ... resources) {
- m_context = ctx;
- m_resources = resources;
- }
-
- public void add(ServiceReference<?> ref, ResourceHandler handler) {
- String filterString = (String) ref.getProperty("filter");
- Filter filter = null;
- if (filterString != null) {
- try {
- filter = m_context.createFilter(filterString);
- }
- catch (InvalidSyntaxException e) {
- return;
- }
- }
- for (int i = 0; i < m_resources.length; i++) {
- if (filter == null || filter.match((Dictionary<String, ?>) ResourceUtil.createProperties(m_resources[i]))) {
- synchronized (m_handlers) {
- m_handlers.put(handler, filter);
- }
- handler.added(m_resources[i]);
- }
- }
- }
-
- public void remove(ServiceReference<?> ref, ResourceHandler handler) {
- Filter filter;
- synchronized (m_handlers) {
- filter = (Filter) m_handlers.remove(handler);
- }
- if (filter != null) {
- for (int i = 0; i < m_resources.length; i++) {
- if (filter == null || filter.match((Dictionary<String, ?>) ResourceUtil.createProperties(m_resources[i]))) {
- handler.removed(m_resources[i]);
- }
- }
- }
- }
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/reference/dependency-service.mdtext b/modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/reference/dependency-service.mdtext
deleted file mode 100644
index 015725d..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/reference/dependency-service.mdtext
+++ /dev/null
@@ -1,35 +0,0 @@
-Title: Dependency Manager - Service Dependency
-
-A service dependency allows you to depend on a service, either by type or by using an additional filter
-condition. You can even depend on an existing service directly by providing a reference to it.
-
-To define a service dependency, you need to use the [ServiceDependecy](http://felix.apache.org/apidocs/dependencymanager/r13/org/apache/felix/dm/ServiceDependency.html) interface.
-This interface can be created using DependencyActivatorBase.createServiceDependency() or DependencyManager.createServiceDependency() methods;
-
-Service dependencies can be injected on fields or using callbacks, can be required or optional, and NullObject pattern is supported for optional dependencies applied on class fields.
-
-Example:
-
- :::java
- public class Activator extends DependencyActivatorBase {
- public void init(BundleContext context, DependencyManager manager) throws Exception {
- manager.add(createComponent()
- .setImplementation(DataGenerator.class)
- .add(createServiceDependency()
- .setService(Store.class)
- .setRequired(true)
- )
- );
- }
- }
-
- public class DataGenerator {
- private volatile Store m_store;
-
- public void generate() {
- for (int i = 0; i < 10; i++) {
- m_store.put("#" + i, "value_" + i);
- }
- }
- }
-
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/reference/dm-annotations.mdtext b/modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/reference/dm-annotations.mdtext
deleted file mode 100644
index 7b30e7e..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/reference/dm-annotations.mdtext
+++ /dev/null
@@ -1,1611 +0,0 @@
-Title: Dependency Manager Annotations
-
-[TOC]
-
-This section presents an overview and a reference guide of the capabilities and usage of the
-DependencyManager annotations.
-
-# Overview
-
-Instead of writing Activators which extends the DependencyActivatorBase class, service
-components can also be annotated using the annotations provided by the
-*org.apache.felix.dependencymanager.annotation* bundle. Annotations are not reflectively
-parsed at runtime; but we use a BND plugin which scans annotations at compilation phase
-and generates a compact json metadata file in the bundle's META-INF/dependencymanager
-subdirectory. This has the following benefits: JVM startup speed is not affected, and class files
-are not parsed when the framework is starting. Moreover, since the annotations are not retained
-by the VM at runtime, it is not necessary to load the annotation API bundle at runtime.
-
-At runtime, the metadata generated during the compilation phase are processed by a
-specific DependencyManager Runtime bundle, which is in charge of managing the service
-component lifecycle and dependencies. This Runtime bundle actually uses the
-DependencyManager programmatic API in order to manage the annotated components.
-Annotated components can then be inspected with the DependencyManager Gogo shell, as it is
-the case with DM components declared through the programmatic DM API.
-
-To register a service, your can annotate your class with a *@Component* annotation, and
-an instance of your class will be registered under all directly implemented interfaces
-into the OSGi registry. You can however take control on the interfaces to be exposed, and
-in this case, you can use the *provides* attribute, which takes a list of classes to
-expose from the registry:
-
- :::java
- @Component
- class WebServiceImpl implements WebService {
- ...
- }
-
-To illustrate this, we are now introducing a SpellChecker application which provides a
-Felix "spellcheck" Gogo shell command. Our "spellcheck" command is implemented by the
-SpellChecker component which accepts a string as parameter. This string is then checked for proper existence.
-To do the checking, the SpellChecker class has a required/multiple (1..N) dependency over
-every available DictionaryService services. Such DictionaryService represents a real
-dictionary for a given language (it has a *lang* service property).
-
-Now we have introduced the background, let's define our SpellChecker component:
-
- :::java
- @Component(provides=SpellChecker.class)
- @Property(name=CommandProcessor.COMMAND_SCOPE, value="dmsample.annotation")
- @Property(name=CommandProcessor.COMMAND_FUNCTION, values={"spellcheck"})
- public class SpellChecker {
- // --- Gogo Shell command
-
- public void spellcheck(String word) {
- // Check the proper existence of the word parameter, using injected DictionaryService instances
- // ...
- }
- }
-
-
-In the code above, you see that the SpellCheck is annotated with the *@Component*
-annotation. Gogo runtime does not required shell commands to implement a specific
-interface. Commands just have to register some Pojos in the OSGi registry, but the only
-thing required is to provide the Pojos with two service properties ( COMMAND_SCOPE, and
-COMMAND_FUNCTION) which will be used by the Gogo runtime when instropecting the Pojo
-for invoking the proper functions.
-
-So, coming back to the sample code, the SpellChecker class registers itself into the OSGi registry, using the *provides* attribute, which just refer to our SpellChecker class, and the two mandatory Gogo service properties are also specified using the *@Property* annotation. It is not shown here, but service properties can also be provided dynamically from a method that can return a Map, and annotated with the *@Start* lifecycle callback, but we will see this feature in a another section.
-
-Our SpellChecker component can expose itself as a Gogo shell command, but before being
-registered into the OSGi registry, we also need to be injected with two dependencies:
-one required dependency (at minimum) on a DictionaryService, and another optional one on
-a LogService. First, let's look at the DictionaryService, which is a simple interface:
-
- :::java
- public interface DictionaryService {
- /**
- * Check for the existence of a word.
- * @param word the word to be checked.
- * @return true if the word is in the dictionary, false otherwise.
- */
- public boolean checkWord(String word);
- }
-
-And here is our previous SpellChecker component, augmented with two new ServiceDependency
-annotations:
-
- :::java
- @Component(provides=SpellChecker.class)
- @Property(name=CommandProcessor.COMMAND_SCOPE, value="dmsample.annotation")
- @Property(name=CommandProcessor.COMMAND_FUNCTION, values={"spellcheck"})
- public class SpellChecker {
- @ServiceDependency(required = false)
- private LogService m_log;
-
- private final CopyOnWriteArrayList<DictionaryService> m_dictionaries = new CopyOnWriteArrayList<DictionaryService>();
-
- @ServiceDependency(removed = "removeDictionary")
- protected void addDictionary(DictionaryService dictionary) {
- m_dictionaries.add(dictionary);
- }
-
- protected void removeDictionary(DictionaryService dictionary) {
- m_dictionaries.remove(dictionary);
- }
-
- // --- Gogo Shell command
-
- public void spellcheck(String word) {
- m_log.log(LogService.LOG_INFO, "Checking spelling of word \"" + word
- + "\" using the following dictionaries: " + m_dictionaries);
-
- for (DictionaryService dictionary : m_dictionaries) {
- if (dictionary.checkWord(word)) {
- System.out.println("word " + word + " is correct");
- return;
- }
- }
- System.err.println("word " + word + " is incorrect");
- }
- }
-
-There are many things to describe in the code above:
-
-First, we define an optional dependency on the LogService, by defining a
-*@ServiceDependency(required=false)* annotation on our m_logService field: This
-means that our component will be provided into the OSGi registry even if there
-is no available LogService, and in this case, a NullObject will be injected in
-our class field;
-This will avoid to check for nullability, when using the m_logService field.
-All optional dependencies applied on class fields are injected with a
-NullObject (when not available).
-The NullObject can be invoked and will do nothing. For a lot of cases that is
-good enough to handle optional dependencies. But when you really want to check
-if an optional service is there or not, then you have to apply the optional
-dependency on a callback method, which will be called when the optional
-service is available.
-
-Next comes the dependency on the DictionaryService. Here, we use a *ServiceDependency*
-annotation, but this time we apply it on a method (*add/removeDictionary*). There is no
-need to specify the "*required=true*" flag because it is the default value. Notice that
-this behavior is different from the API, where service dependencies are optional by default
-. We use a callback method, because we just need to register all available
-DictionaryService services in our dictionary list, which is used when checking word
-existence. This list is a copy on write list because the dependency may be injected at
-any time, possibly from another thread. So, using a copy on write list avoid us to use
-synchronized methods.
-
-Notice that the @ServiceDependency could also have been applied on the m_dictionaries field,
-and in this case, no need to define callback methods (addDictionary/removeDictionary).
-So, in this case the dictionaries will be automatically added in the collection field.
-
-# Component types
-
-The following types of components are supported when using annotations:
-
-- Component: Allows to define osgi services
-- Aspect Service: A service that provides a non-functional aspect on top of an existing service
-- Service Adapter: A Service that adapts another existing service into a new one
-- Bundle Adapter: Allows to provide an osgi service on top of an existing bundle
-
-## Component
-
-Components are the main building blocks for OSGi applications and can be annotated with @Component. They can publish themselves as a
-service, and/or they can have dependencies. These dependencies will influence their life cycle as component
-will only be activated when all required dependencies are available. To define a component, you can use the @Component annotation
-(see [@Component javadoc](http://felix.apache.org/apidocs/dependencymanager.annotations/r13/org/apache/felix/dm/annotation/api/Component.html)).
-
-Applying this annotation on top of a java class let it be a service component. All directly implemented
-interfaces will be registered in the osgi registry, but you can control the provided interfaces using the `provides` attribute.
-Sometimes, your class implements some interfaces, but yet you don't want them to be registered, in this case, declaring `provides={}` ensures that
-no services will be registered. However, the component can still define service dependencies and it will be invoked in the @Start callback when all required
-dependencies are satisfied.
-
-The default public constructor is used to initialize the component, but you can also specify a static method that will be used to instantiate the component (using the
-`factoryMethod` attribute). This allows for example to create the component instance using a dynamic proxy.
-
-Here is a sample showing a Hello component:
-
- :::java
- /**
- * This component will be activated once the bundle is started.
- */
- @Component
- class Hello implements HelloService {
- @Start
- void start() {
- // Our component is starting and is about to be registered in the OSGi registry as a HelloService service.
- }
- }
-
-By default, components are created automatically, when the Components' bundle is started and when the Component
-dependencies are satisfied. But certain software patterns require the creation of Services on demand.
-For example, a Service could represent an application that can be launched multiple times and each Service
-instance can then quit independently. Such a pattern requires a factory that creates the instances, and
-`Managed Service Factories` can be used to implement this use case. it is based on OSGi Configuration Admin service.
-Using the configuration admin service, you can create multiple dictionaries , and for each one a new service will be created
-The mapping between the dictionaries and the services are done using a so called `PID`.
-So, if you need your component to be instantiated multiple times, you first need to define the PID using the `factoryPid` attribute.
-
-Example:
-
- :::java
- /**
- * All component instances will be created/updated/removed by the "HelloFactory" component
- */
- @Component(factoryPid="my.factory.pid")
- class Hello implements HelloService {
- void updated(Dictionary conf) {
- // Configure or reconfigure our component. The conf is provided by the factory,
- }
-
- @Start
- void start() {
- // Our component is starting and is about to be registered in the OSGi registry as a Hello service.
- }
- }
-
- /**
- * This class will instantiate some Hello component instances
- */
- @Component
- class HelloFactory {
- @ServiceDependency
- void bind(ConfigurationAdmin cm) {
- // instantiate a first instance of Hello component
- Configuration c1 = cm.createFactoryConfiguration("my.factory.pid", "?");
- Hashtable props = new Hashtable();
- props.put("key", "value1");
- c1.update(props);
-
- // instantiate another instance of Hello component
- Configuration c2 = cm.createFactoryConfiguration("my.factory.pid", "?");
- props = new Hashtable();
- props.put("key", "value2");
- c2.update(props);
-
- // destroy the two instances of X component
- c1.delete();
- c2.delete();
- }
- }
-
-In the above example, the PID is "my.factory.pid", and the HelloFactory component uses the `ConfigurationAdmin`
-service in order to create some factory configurations using the "my.factory.pid". This pattern allows to
-programatically create/update/remove multiple instances of the same Component.
-
-By default, the HelloComponent can define an `updated(Dictionary)` callback: it will be called when the component
-is created, but you can override the method which receives the configuraiton using the `updated` attribute.
-
-When you want to propagate the configuration to the provided service properties, you can also define the `propagate` attribute.
-Notice that when you propagate the configuration to the provided service properties, then the the configuration takes precedence
-over the service properties, meaning that if a given property is declared in the service properties, then it
-will be overriden if the configation also contains the property.
-
-## Aspect component
-
-An aspect service in DM provides a non-functional aspect on top of an existing service.
-In aspect oriented programming, an aspect, or interceptor can sit between a client and another target service
-used by the client. An Aspect Service first tracks a target service and is created once the target service is
-detected. Then the Aspect Service is provided, but with a higher ranking, and the client is transparently
-updated with the aspect. Aspects can be chained and may apply to the same target service (and in this case,
-the ranking of the Aspect service is used to chain aspects in the proper order).
-
-You can define an aspect service using the @AspectService annotation (see
-[@AspectService javadoc](http://felix.apache.org/apidocs/dependencymanager.annotations/r13/org/apache/felix/dm/annotation/api/AspectService.html)).
-
-Usage example:
-
-Here, the `Aspect` class is registered into the OSGI registry each time an
-InterceptedService is found from the registry.
-
- :::java
- @AspectService(ranking=10))
- class Aspect implements InterceptedService {
- // The service we are intercepting (injected by reflection)
- volatile InterceptedService intercepted;
-
- public void doWork() {
- intercepted.doWork();
- }
- }
-
-The Aspect class intercepts the original InterceptedService, and decorates its "doWork()" method.
-This aspect uses a rank with value "10", meaning that it will intercept some other eventual aspects with
-lower ranks. It will also inherit of the original InterceptedService service properties.
-
-## Adapter component
-
-An adapter service component (@AdapterService) adapts another existing service into a new one. Like with aspects,
-sometimes you want to create adapters for certain services, which add certain behavior that results in
-the publication of (in this case) a different service. Adapters can dynamically be added and removed
-and allow you to keep your basic services implementations clean and simple, adding extra features on top of
-them in a modular way.
-
-You can define an aspect service using the @AdapterService annotation (see
-[@AdapterService javadoc](http://felix.apache.org/apidocs/dependencymanager.annotations/r13/org/apache/felix/dm/annotation/api/AdapterService.html)).
-
-Here, the AdapterService is registered into the OSGI registry each time an AdapteeService is
-found from the registry.
-
- :::java
- interface AdapteeService {
- void method1();
- void method2();
- }
-
- @Component
- @Property(name="p1", value="v1")
- class Adaptee implements AdapteeService {
- ...
- }
-
- interface AdapterService {
- void doWork();
- }
-
- @AdapterService(adapteeService = AdapteeService.class)
- @Property(name="p2", value="v2")
- class AdapterImpl implements AdapterService {
- // The service we are adapting (injected by reflection)
- volatile AdapteeService adaptee;
-
- public void doWork() {
- adaptee.method1();
- adaptee.method2();
- }
- }
-
-The AdapterImpl class adapts the AdapteeService to the AdapterService.
-The AdapterService will also have the following service property: p1=v1, p2=v2 :
-
-## Bundle adapter component
-
-Bundle adapters are similar to Adapter Components, but instead of adapting a service, they adapt a bundle
-with a certain set of states (STARTED|INSTALLED|...), and provide a service on top of it.
-
-You can define a bundle adapter service using the @BundleAdapterService annotation (see
-[@BundleAdapterService javadoc](http://felix.apache.org/apidocs/dependencymanager.annotations/r13/org/apache/felix/dm/annotation/api/BundleAdapterService.html)).
-
-The bundle adapter will be applied to any bundle that matches the specified bundle state mask and
-filter conditions, which may match some of the bundle OSGi manifest headers. For each matching bundle an
-adapter will be created based on the adapter implementation class. The adapter will be registered with the
-specified interface and with service properties found from the original bundle OSGi manifest headers plus any
-extra properties you supply here. If you declare the original bundle as a member it will be injected.
-
-In the following example, a "VideoPlayer" Service is registered into the OSGi registry each time an active bundle containing a "Video-Path" manifest header is detected:
-
- :::java
- @BundleAdapterService(filter = "(Video-Path=*)", stateMask = Bundle.ACTIVE, propagate=true)
- public class VideoPlayerImpl implements VideoPlayer {
- volatile Bundle bundle; // Injected by reflection
-
- void play() {
- URL mpegFile = bundle.getEntry(bundle.getHeaders().get("Video-Path"));
- // play the video provided by the bundle ...
- }
- }
-
-# Component lifecycle
-
-A component has a lifecycle that controls when it is started or stopped.
-A bundle must be started before the DM Runtime can process its components.
-When the bundle is started, the DM Runtime then parses a specific
-*DependencyManager-Component* manifest header, which points to a list of descriptors
-describing all annotated components. Such descriptors are actually generated at
-compilation time, and annotation are not reflectively parsed at runtime.
-Only the descriptor is used to process the components.
-
-For each component, the DM Runtime first ensures that all dependencies are satisfied before
-activating it. Likewise, the component is deactivated when some of the required dependencies
-are not available anymore or when the bundle is stopped. Unless the bundle is stopped, components may be deactivated
-and reactivated, depending on the departure and arrival of required dependencies. The
-manager which is in charge of maintaining the state of components is implemented in the
-DM Runtime bundle (org.apache.felix.dm.runtime bundle).
-
-
-
-So, during activation, the component goes through a number of states, where each transition
-includes the invocation of the following lifecycle method callbacks on the service implementation:
-
-- [@Init](http://felix.apache.org/apidocs/dependencymanager.annotations/r13/org/apache/felix/dm/annotation/api/Init.html):
-this callback is invoked after all required dependencies have been injected. In this method, you can
-yet add more dynamic dependencies using the DM API, or you can possibly configure other dependencies filter and required flags
-(see [Dynamic dependency configuration](## Dynamic dependency configuration)).
-
-- [@Start](http://felix.apache.org/apidocs/dependencymanager.annotations/r13/org/apache/felix/dm/annotation/api/Start.html):
-this callback is invoked after all required dependencies added in the @Init method have been injected.
-
-- [@Registered](http://felix.apache.org/apidocs/dependencymanager.annotations/r13/org/apache/felix/dm/annotation/api/Registered.html):
-this callback is invoked after the service component is registered (if the component provides a service).
-The callback can takes as argument a ServiceRegistration parameter.
-
-- [@Stop](http://felix.apache.org/apidocs/dependencymanager.annotations/r13/org/apache/felix/dm/annotation/api/Stop.html):
-this method is called when a required dependency is lost or when the bundle is stopped
-
-- [@Destoy](http://felix.apache.org/apidocs/dependencymanager.annotations/r13/org/apache/felix/dm/annotation/api/Destroy.html) annotations:
-the component is about to be destroyed
-
-## Component activation
-
-Activating a component consists of the following steps:
-
-1) Wait for all required dependencies to be available. When all required dependencies are
-available:
-
-- instantiate the component
-- inject all required dependencies (on class fields using reflection, or by invoking callback methods)
-- inject all optional dependencies defined on class fields, possibly with a *NullObject* if the
-dependency is not available.
-- call the component init method (annotated with *@Init*, see (see
-[@Init javadoc](http://felix.apache.org/apidocs/dependencymanager.annotations/r13/org/apache/felix/dm/annotation/api/Init.html)).).
-In the init method, you are yet allowed to add some additional dependencies using the Dependency
-Manager API or DM Lambda). Alternatively, you can also configure some dependencies dynamically
-(explained later, in [Dynamic Dependency Configuration](##dynamic-dependency-configuration).
-
-2) Wait for extra required dependencies optionally configured from the init() method. When all extra
-required dependencies are available:
-
-- inject extra required dependencies (if some were defined in init() method).
-- invoke the start method annotated with [@Start annotation](http://felix.apache.org/apidocs/dependencymanager.annotations/r13/org/apache/felix/dm/annotation/api/Start.html).
-The start method may return a Map<String, Object> that will
-be appended to the provided service properties (the the component provides a service).
-- start tracking optional dependencies applied on method callbacks (invoke optional dependency callbacks).
-Notice that NullObject pattern is not applied to optional callback dependencies.
-In other words, if the dependency is not there, your callback won't be invoked at all.
-If you need the NullObject pattern, then apply optional dependencies on class fields, not on
-callback methods.
-- register the OSGi service, if the component provides one.
-- invoke the method annotatated with [@Registered annotation](http://felix.apache.org/apidocs/dependencymanager.annotations/r13/org/apache/felix/dm/annotation/api/Registered.html).
-The method, if declared, takes as argument a `ServiceRegistration` which corresponds to the registered service.
-
-
-
-## Component deactivation
-
-Deactivating a component consists of the following steps:
-
-If the bundle is stopped or if some required dependencies are unavailable, or if the component
-has declared a factoryPid and the factory configuration has been delete, then:
-
-- Unbind optional dependencies (defined on callback methods).
-Notice that any optional dependency unavailability does not trigger the component deactivation;
-the *removed* callbacks are just invoked, if declared in the annotation.
-- Invoke the stop method (annotated wit *@Stop*), and unregister some OSGi services
-(if the components provides some services).
-- invoke destroy method (annotated with *@Destroy*).
-- invoke *removed* callbacks for required dependencies, if any.
-
-## Example
-
-The following example shows a basic component, which uses the @Start annotation:
-
- :::java
- /**
- * A Component Using lifecyce callbacks
- */
- @Component
- class X implements Y {
- @ServiceDependency
- void bindOtherService(OtherService other) {
- // Will be injected before we are started (because it's a required dependency).
- }
-
- @Start
- void start() {
- // All required dependencies are injected: initialize our component.
- }
- }
-
-The following example shows a component, which returns some service properties from its start method,
-and the component also defines the @Registered annotation in order to get the actual ServiceRegistration
-for the provided service:
-
- :::java
- /**
- * A Component Using lifecyce callbacks
- */
- @Component
- @Property(name="p1", value="v1") // service properties
- class X implements Y {
- @ServiceDependency
- void bindOtherService(OtherService other) {
- // Will be injected before we are started (because it's a required dependency).
- }
-
- @Start
- Map<String, Object> start() {
- // All required dependencies are injected: initialize our component.
- // Once we return, our Y service will be published in the OSGi registry, using the following
- // service properties appended to the ones specified on top of the class with the @Property
- // annotation (notice that returning a map is optional and our start() method could be
- // declared as void).
- Map<String, Object> additionalServiceProperties = new HashMap<>();
- additionalServiceProperties.put("p2", "v2");
- return additionalServiceProperties;
- }
-
- @Registered
- void registered(ServiceRegistration registration) {
- // once our service is registered, we can obtainer here the corresponding ServiceRegistration ...
- }
- }
-
-## Lifecycle control
-
-As explained in the *Component Activation* section, a component which provides a service
-is automatically registered into the OSGi registry, after the @Start method returns.
-But it is sometimes required to control when the service is really started/published or
-unpublished/stopped.
-
-This can be done using the [@LifecycleController](http://felix.apache.org/apidocs/dependencymanager.annotations/r13/org/apache/felix/dm/annotation/api/LifecycleController.html) annotation.
-This annotation injects a Runnable object that can be invoked when you want to trigger your service
-startup and publication. The @LifecycleController is like a required dependency and is injected before
-the @Init method is called.
-
-For instance, imagine that your component publishes an OSGi service, but before, it needs to
-register into a DHT (Distributed Hash Table), whose API is asynchronous: that is:
-the DHT API will callback you once you are inserted into a node in the DHT.
-In this case, what you would like to do is to publish your OSGi service, but only after you are
-inserted into the DHT (when the DHT callbacks you) ...
-Such a case is supported using the @LifecyceController annotation, which gives you
-full control of when your component is *started/published* and *unpublished/stopped*.
-
-Let's illustrate this use case with a concrete example: First here is the DHT asynchronous API:
-
- :::java
- /**
- * This is an element which can be inserted into the distributed hash table.
- */
- public interface DHTElement {
- void inserted(); // callback used to notify that the element is inserted into the DHT
- }
-
- /**
- * This is the DHTService, which registers a DHTElement asynchronously.
- */
- public interface DHTService {
- void insert(DHTElement element); // will callback element.inserted() later, once registered into the DHT.
- }
-
-Next, here is our service, which uses the @LifecycleController in order to take control of when the service is published into the OSGi registry:
-
- :::java
- @Component(provides={MyService.class})
- public class MyServiceImpl implements MyService, DHTElement {
- @ServiceDependency
- DHTService m_dht;
-
- @LifecycleController
- Runnable m_start; // will fire component startup, once invoked.
-
- @Init
- void init() {
- m_dht.insert(this); // asynchronous, will callback once registered into the DHT
- }
-
- public void inserted() {
- // We are inserted into the DHT: we can now trigger our component startup.
- // We just invoke the runnable injected by our @LifecycleController annotation, which will trigger our
- // service publication (we'll be called in our @Start method before)
- m_start.run();
- }
-
- @Start
- void start() {
- // method called only once we invoke our trigger Runnable (see inserted method).
- // Our Service will be published once this method returns.
- }
- }
-
-Same example as above, using java8 method reference:
-
- :::java
- @Component
- public class MyServiceImpl implements MyService {
- @ServiceDependency
- DHTService m_dht;
-
- @LifecycleController
- Runnable m_start; // will fire component startup, once invoked.
-
- @Init
- void init() {
- m_dht.insert(m_start::run); // asynchronous, will callback m_registered.run() once registered into the DHT
- }
-
- @Start
- void start() {
- // method called after the m_dht service has called the m_registered.run() method.
- }
- }
-
-
-# Dependencies
-
-## Service dependencies
-
-Service Dependencies can be defined using the [@ServiceDependency](http://felix.apache.org/apidocs/dependencymanager.annotations/r13/org/apache/felix/dm/annotation/api/ServiceDependency.html) annotation.
-
-Dependencies can either be required or optional. Required dependencies need to be resolved before
-the service can even become active. Optional dependencies can appear and disappear while the service
-is active. **Please notice that, unlike with the DM API, service dependencies are required by default.**
-
-### Field injection
-
-The dependency manager will automatically fill in any references
-to required @ServiceDependency that are applied on attributes. The same
-goes for optional dependencies if they are available. If not, those will
-be implemented by a null object [NULLOBJ]. In short, this allows
-you to simply use these interfaces as if they were always available.
-A good example of this is the LogService. If it’s available, we want
-to use it for logging. If not, we want to simply ignore log messages.
-Normally, you’d need to check a reference to this service for null
-before you can use it. By using a null object, this is not necessary
-anymore.
-
-When the @ServiceDependency annotation is defined on a class field, the following field
-types are supported:
-
-- a field having the same type as the dependency. If the field may be accessed by any thread,
-then the field should be declared volatile, in order to ensure visibility when the field is auto
-injected concurrently.
-
-- a field which is assignable to an `Iterable<T>` where T must match the dependency type.
-In this case, an Iterable will be injected by DependencyManager before the start callback is called.
-The Iterable field may then be traversed to inspect the currently available dependency services.
-The Iterable can possibly be set to a final value so you can choose the Iterable implementation
-of your choice (for example, a CopyOnWrite ArrayList, or a ConcurrentLinkedQueue).
-
-- a Map<K,V> where K must match the dependency type and V must exactly equals Dictionary class. In this case, a ConcurrentHashMap will be injected by DependencyManager before the start callback is called. The Map may then be consulted to lookup current available dependency services, including the dependency service properties (the map key holds the dependency services, and the map value holds the dependency service properties). The Map field may be set to a final value so you can choose [...]
-
-This is an example where you inject a `Dependency` service on a class field:
-
- :::java
- @Component
- class MyComponent {
- @ServiceDependency
- volatile Dependency m_dependency;
- }
-
-
-Another example, were we inject multiple dependencies to an Iterable field
-
- :::java
- @Component
- class MyComponent {
- @ServiceDependency
- final Iterable<Dependency> dependencies = new CopyOnWriteArrayList<>();
- }
-
-And next, we inject multiple dependencies to a Map field, allowing to inspect service
-dependency properties (the keys hold the services, and the values hold the associated service
-properties):
-
- :::java
- @Component
- class MyComponent {
- @ServiceDependency
- final Map<MyDependency, Dictionary<String, Object>> dependencies = new ConcurrentHashMap<>;
- }
-
-Optional dependencies applied on class fields will inject a NullObject when the dependency is unavailable. This allows you to avoid to check if the optional
-dependency is not null using a "if" statement, and invoking the NullObject will result in a No Op method call. When the optional dependency type is not an interface, then NullObject won't work because
-internally, the NullObject is implemented using a dynamic proxy. In this case you can use the
-ServiceDependency.defaultImpl attribute which allows to specify a default implementation when the optional dependency is unavailable.
-
-Example:
-
- :::java
- @Component
- public class MyComponent {
- @ServiceDependency(required=false, defaultImpl=MyDefaultImpl.class)
- volatile Dependency m_dependency;
- }
-
-in the above example, the MyDefaultImpl class will be injected on the m_dependency class field in case the dependency is unavailable.
-
-### Callback injection
-
-Optionally, a service can define callbacks for each dependency. These
-callbacks are invoked whenever a new dependency is discovered or
-an existing one is disappearing. They allow you to track these dependencies.
-This can be very useful if you, for example, want to implement the white board pattern.
-
-The callbacks allows to get notified when a service is added, and support the following signatures:
-
- (Component comp, ServiceReference ref, Service service)
- (Component comp, ServiceReference ref, Object service)
- (Component comp, ServiceReference ref)
- (Component comp, Service service)
- (Component comp, Object service)
- (Component comp)
- (Component comp, Map properties, Service service)
- (ServiceReference ref, Service service)
- (ServiceReference ref, Object service)
- (ServiceReference ref)
- (Service service)
- (Service service, Map properties)
- (Map properties, Service, service)
- (Service service, Dictionary properties)
- (Dictionary properties, Service service)
- (Object service)
- (ServiceReference<T> service)
- (ServiceObjects<T> service)
-
-Example:
-
- :::java
- @Component
- class MyComponent {
- @ServiceDependency
- void bind(MyDependency dependency) {}
- }
-
-Same example as before, but the callback signatures includes service properties:
-
- :::java
- @Component
- class MyComponent {
- @ServiceDependency
- void bind(MyDependency dependency, Map<String, Object> serviceProperties) {}
- }
-
-Same example as before, but this time we track service change:
-
- :::java
- @Component
- class MyComponent {
- @ServiceDependency(change="updated")
- void bind(MyDependency dependency, Map<String, Object> serviceProperties) {}
-
- void updated(MyDependency dependency, Map<String, Object> serviceProperties) {}
- }
-
-Example where you track added/changed/removed service:
-
- :::java
- @Component
- class MyComponent {
- @ServiceDependency(change="updated", remove="unbind")
- void bind(MyDependency dependency, Map<String, Object> serviceProperties) {}
-
- void updated(MyDependency dependency, Map<String, Object> serviceProperties) {}
-
- void unbind(MyDependency dependency, Map<String, Object> serviceProperties) {}
- }
-
-### Whiteboard pattern
-
-Required service dependency are always invoked before the start (@Start) callback is
-invoked.
-However, Optional dependency **callbacks** are always invoked **after** the start (@Start) callbacks.
-This allows to easily implement the whiteboard patter, because you can first make sure your component
-is fully initialized before it can start to track other services (whiteboard pattern).
-
-For example, assume you write a `TaskExecutor` component which tracks `Task` services. So, each time
-a Task is found from the registry, then you want to schedule the Task in an Executor, and you also
-want to maitain statistics on executed tasks. So, your `TaskExecutor` depends on two required services:
-an `Executor` service (used to schedule the tasks), as well as a `TaskMetrics` service which is used to
-maintain Task execution statistics. So what you need is to make sure your are injected with the TaskMetrics
-and the Executor service before you can actually start to handle Tasks.
-To do so, simply define two required dependencies on the `Executor` and the `TasksMetrics`, and
-define an optional dependency on the Task services. This will ensure that the Tasks callbacks are
-invoked after your component is started:
-
- :::java
- interface Task extends Runnable {
- }
-
- @Component
- TaskExecutor {
- @ServiceDependency
- volatile Executor m_executor;
-
- @ServiceDependency
- volatile TaskMetrics m_taskMetrics;
-
- @Start
- void start() {
- // at this point, all required dependencies have been injected and we can now start to track
- // the Task services
- }
-
- @ServiceDependency(required=false)
- void bind(Task task) {
- m_executor.execute(task);
- m_taskMetrics.taskScheduled();
- }
- }
-
-### Tracking any services matching a given filter
-
-Sometimes, you may want to be injected with any service objects matching a given filter,
-without any additional filter on the class service interface.
-In this case, you need to use the `service=ServiceDependency.ANY` attribute
-
-
-For example:
-
- :::java
- import org.apache.felix.dm.annotation.ServiceDependency;
- import org.apache.felix.dm.annotation.api.ServiceDependency.Any;
-
- @Component
- public class MyService {
- @ServiceDependency(service=Any.class, filter="(property=true)")
- void bind(Object allServices) {
- }
- }
-
-### Service dependency properties propagation
-
-It is possible to propagate the dependency service properties, using the ServiceDependency.propagate attribute.
-When the service dependency properties are propagated, they will be appended to the component service properties,
-but won't override them (the component service properties takes precedence over the propagated service dependencies).
-
-Example:
-
- :::java
- @Component
- @Properties(name="p1", value="v1")
- public class MyServiceImpl implements MyService {
- @ServiceDependency(propagate=true)
- void bind(OtherService other) {
- }
- }
-
-The service above will be registered with the p1=v1 service properties, as well as with any service properties which come from the Service Dependency.
-
-### defining a swap aspect callback
-
-When you define a service dependency, it is possible to define a swap callback in case an original service dependency is replaced by an aspect, and you
-then want to be called back at the time the service dependency is replaced.
-
-Example:
-
- :::java
- @Component
- public class MyServiceImpl {
- @ServiceDependency(swap="swap")
- void bind(OtherService other) {
- }
-
- void swap(OtherService old, OtherService replace) {
- }
- }
-
-So, if an aspect service is registered for the OtherService service, then your swap method will be called so you can take the service replacement into account.
-
-The swap callback supports the following signatures:
-
- :::java
- (Service old, Service replace)
- (Object old, Object replace)
- (ServiceReference old, Service old, ServiceReference replace, Service replace)
- (ServiceReference old, Object old, ServiceReference replace, Object replace)
- (Component comp, Service old, Service replace)
- (Component comp, Object old, Object replace)
- (Component comp, ServiceReference old, Service old, ServiceReference replace, Service replace)
- (Component comp, ServiceReference old, Object old, ServiceReference replace, Object replace)
- (ServiceReference old, ServiceReference replace)
- (Component comp, ServiceReference old, ServiceReference replace)
- (ServiceObjects old, ServiceObjects replace)
- (Component comp, ServiceObjects old, ServiceObjects replace)
-
-### Blocking a service invocation while it is updating.
-
-When an injected service dependency is an interface, it is possible to block the service invocation
-while it is being updated.
-Only useful for required stateless dependencies that can be replaced transparently.
-A Dynamic Proxy is used to wrap the actual service dependency (which must be an interface).
-When the dependency goes away, an attempt is made to replace it with another one which satisfies
-the service dependency criteria. If no service replacement is available, then any method invocation
-(through the dynamic proxy) will block during a configurable timeout. On timeout, an unchecked
-IllegalStateException exception is raised (but the service is not deactivated).
-
-To use this feature, you need to specify a `timeout` attribute like this:
-
- :::java
- @Component
- class MyServer implements Runnable {
- @ServiceDependency(timeout=15000)
- MyDependency dependency;.
-
- @Start
- void start() {
- (new Thread(this)).start();
- }
-
- public void run() {
- try {
- dependency.doWork();
- } catch (IllegalStateException e) {
- t.printStackTrace();
- }
- }
- }
-
-Notice that the changed/removed callbacks are not used when the timeout parameter is greater
-than -1. -1 means no timeout at all (default). 0 means that invocation on a missing service will
-fail immediately. A positive number represents the max timeout in millis to wait for the service
-availability.
-
-## Configuration dependencies
-
-A configuration dependency is required by default, and allows you to depend on
-the availability of a valid configuration for your component. Use the
-[@ConfigurationDependency annotation](http://felix.apache.org/apidocs/dependencymanager.annotations/r13/org/apache/felix/dm/annotation/api/ConfigurationDependency.html) to define a configuration dependency.
-
-This dependency requires the OSGi Configuration Admin Service.
-Configuration Dependency callback is always invoked before any service dependency
-callbacks, and before init/start callbacks.
-The annotation can be applied on a callback method which accepts the following
-parameters:
-
- callback(Dictionary)
- callback(Component, Dictionary)
- callback(Component, Configuration ... configTypes) // type safe configuration interface(s)
- callback(Configuration ... configTypes) // type safe configuration interface(s)
- callback(Dictionary, Configuration ... configTypes) // type safe configuration interfaces(s)
- callback(Component, Dictionary, Configuration ... configTypes) // type safe configuration interfaces(s)
-
-Configuration can be simply injected in the form of dictionaries, or in the form of type-safe configuration
-interfaces.
-
-the annotation attributes are the following:
-
-* pid: Returns the pid for a given service (by default, the pid is the service class name).
-* propagate: Returns true if the configuration properties must be published along with the service. The configuration properties takes precedence over the component service properties.
-* pidClass: Returns the pid from a class name.
-* required: Sets the required flag which determines if this configuration dependency is required or not.
-* name: used to dynamically configure the pid from an @Init method.
-
-### Type safe configuration
-
-Configuration types allows you to specify a Java interface that is implemented by
-DM and such interface is then injected to your callback instead of the actual Dictionary.
-Using such configuration interface provides a way for creating type-safe configurations
-from a actual Dictionary that is normally injected by Dependency Manager.
-The callback accepts in argument an interface that you have to provide, and
-DM will inject a proxy that converts method calls from your configuration-type
-to lookups in the actual map or dictionary. The results of these lookups are then
-converted to the expected return type of the invoked configuration method.
-As proxies are injected, no implementations of the desired configuration-type are
-necessary!
-
-The lookups performed are based on the name of the method called on the configuration
-type. The method names are "mangled" to the following form:
-
- [lower case letter] [any valid character]*.
-
-Method names starting with get or is (JavaBean convention) are stripped from these
-prefixes. For example: given a dictionary with the key "foo" can be accessed from a
-configuration-type using the following method names:
-
- foo(), getFoo() and isFoo().
-
-The return values supported are:
-
-* primitive types (or their object wrappers);
-* strings;
-* enums;
-* arrays of primitives/strings;
-* Collection types;
-* Map types;
-* Classes and interfaces.
-
-When an interface is returned, it is treated equally to a configuration type, that is,
-a proxy is returned.
-
-Arrays can be represented either as comma-separated values, optionally enclosed in
-square brackets. For example: [ a, b, c ] and a, b,c are both considered an array of
-length 3 with the values "a", "b" and "c".
-Alternatively, you can append the array index to the key in the dictionary to obtain
-the same: a dictionary with "arr.0" => "a", "arr.1" => "b", "arr.2" => "c" would result
-in the same array as the earlier examples.
-
-Maps can be represented as single string values similarly as arrays, each value
-consisting of both the key and value separated by a dot. Optionally, the value can be
-enclosed in curly brackets. Similar to array, you can use the same dot notation using
-the keys. For example, a dictionary with:
-
- map={key1.value1, key2.value2}
-
-and a dictionary with:
-
- map.key1=value1
- map.key2=value2
-
-result in the same map being returned.
-Instead of a map, you could also define an interface with the methods getKey1()
-and getKey2() and use that interface as return type instead of a Map.
-
-In case a lookup does not yield a value from the underlying map or dictionary,
-the following rules are applied:
-
-* primitive types yield their default value, as defined by the Java Specification;
-* string, Classes and enum values yield null;
-* for arrays, collections and maps, an empty array/collection/map is returned;
-* for other interface types that are treated as configuration type a Null-object is returned.
-
-### Examples
-
-In the following example, the "Printer" component depends on a configuration with
-"org.apache.felix.sample.Printer" PID:
-
- :::java
- package org.apache.felix.sample;
-
- @Component
- public class Printer {
- @ConfigurationDependency
- void updated(Dictionary config) {
- // load printer ip/port from the provided dictionary.
- }
- }
-
-Here is the same example using a type safe configuration:
-
- :::java
- package sample;
-
- public interface PrinterConfiguration {
- String ipAddress();
- int portNumber();
- }
-
- @Component
- public class Printer {
- @ConfigurationDependency // Will use pid "sample.PrinterConfiguration"
- void updated(PrinterConfiguration cnf) {
- if (cnf != null) {
- // load configuration from the provided dictionary, or throw an exception of any configuration error.
- String ip = cnf.ipAddress();
- int port = cnf.portNumber();
- ...
- }
- }
- }
-
-## Bundle dependency
-
-A bundle dependency allows you to depend on a bundle in a certain set of states
-(INSTALLED\|RESOLVED\|STARTED\|...), as indicated by a state mask.
-You can also use a filter condition that is matched against all manifest entries.
-When applied on a class field, optional unavailable dependencies are injected with a
-NullObject.
-
-Use the [@BundleDependency annotation](http://felix.apache.org/apidocs/dependencymanager.annotations/r13/org/apache/felix/dm/annotation/api/BundleDependency.html) to define a bundle dependency.
-
-Attributes:
-
-* changed: Returns the callback method to be invoked when the service have changed.
-* removed: Returns the callback method to invoke when the service is lost.
-* required: Returns whether the dependency is required or not.
-* filter: Returns the filter dependency
-* stateMask: Returns the bundle state mask (Bundle.INSTALLED \| Bundle.ACTIVE etc ...).
-* propagate: Specifies if the manifest headers from the bundle should be propagated to the service properties.
-* name: The name used when dynamically configuring this dependency from the init method.
-Specifying this attribute allows to dynamically configure the dependency filter and
-required flag from the Service's init method.
-All unnamed dependencies will be injected before the init() method;
-so from the init() method, you can then pick up whatever information needed from
-already injected (unnamed) dependencies, and configure dynamically your named
-dependencies, which will then be calculated once the init() method returns.
-
-
-In the following example, the "SCR" Component allows to track all bundles containing a
-specific "Service-Component" OSGi header, in order to load and manage all
-Declarative Service components specified in the SCR xml documents referenced by the
-header:
-
- :::java
- @Component
- public class SCR {
- @BundleDependency(required = false,
- removed = "unloadServiceComponents",
- filter = "(Service-Component=*)"
- stateMask = Bundle.ACTIVE)
- void loadServiceComponents(Bundle b) {
- String descriptorPaths = (String) b.getHeaders().get("Service-Component");
- // load all service component specified in the XML descriptorPaths files ...
- }
-
- void unloadServiceComponents(Bundle b) {
- // unload all service component we loaded from our "loadServiceComponents" method.
- }
- }
-
-## Dynamic dependency configuration
-
-We have seen that a component may declare some dependencies and is started when all required
-dependencies are available. But there are some cases when you may need to define some dependencies
-filters (and required flag) dynamically, possibly from data picked up from other dependencies.
-
-So, all this is possible using *named* dependencies: When you assign a name to a dependency;
-for instance *@ServiceDependency(name="foo")*, then this has an impact on how the dependency
-is handled.
-Indeed, all named dependencies are calculated *after* the @Init method returns.
-So from your @Init method, you can then configure your named dependencies, using data provided
-by already injected dependencies.
-
-To do so, your @Init method is allowed to return a Map containing the filters and required flags
-for each named dependencies.
-For a given named dependency, the corresponding filter and required flag must be stored in
-the Map, using the "*filter*" and "*required*" keys, prefixed with the name of the dependency.
-
-For instance, if you define a Dependency like this:
-
- :::java
- @ServiceDependency(name="foo")
- FooService fooService;
-
-Then you can return this map from your @Init method:
-
- :::java
- @Init
- Map init() {
- Map m = new HashMap();
- m.put("foo.filter", "(foo=bar)");
- m.put("foo.required", "false");
- return m;
- }
-
-So, after the init method returns, the map will be used to configure the dependency named "foo", which will then be evaluated.
-And once the dependency is available, then it will be injected and your @Start callback will be invoked.
-
-Usage example of a dynamic dependency:
-
-In this sample, the "PersistenceImpl" component dynamically configures the "storage"
-dependency from the "init" method. The dependency "required" flag and filter string are derived
-from an xml configuration that is already injected before the init method.
-
- :::java
- @Component
- public class PersistenceImpl implements Persistence {
- // Injected before init.
- @ConfigurationDependency
- void updated(Dictionary conf) {
- if (conf != null) {
- _xmlConfiguration = parseXmlConfiguration(conf.get("xmlConfiguration"));
- }
- }
-
- // Parsed xml configuration, where we'll get our storage service filter and required dependency flag.
- XmlConfiguration _xmlConfiguration;
-
- // Dynamically configure the dependency declared with a "storage" name.
- @Init
- Map<String, String> init() {
- Map<String, String> props = new HashMap<>();
- props.put("storage.required", Boolean.toString(_xmlConfiguration.isStorageRequired()))
- props.put("storage.filter", "(type=" + _xmlConfiguration.getStorageType() + ")");
- return props;
- }
-
- // Injected after init (dependency filter is defined dynamically from our init method).
- @ServiceDependency(name="storage")
- Storage storage;
-
- // All dependencies injected, including dynamic dependencies defined from init method.
- @Start
- void start() {
- log.log(LogService.LOG_WARNING, "start");
- }
-
- @Override
- void store(String key, String value) {
- storage.store(key, value);
- }
- }
-
-
-Notice that you can also add dynamic dependencies using the Dependency Manager API, or using DM-Lambda.
-In this case, no need to define service dependencies with annotations. Here is the same example as above,
-but this time, the dependency on the Storage service is defined from the init method using the DM API:
-
- :::java
- @Component
- public class PersistenceImpl implements Persistence {
- // Injected before init.
- @ConfigurationDependency
- void updated(Dictionary conf) {
- if (conf != null) {
- _xmlConfiguration = parseXmlConfiguration(conf.get("xmlConfiguration"));
- }
- }
-
- // Parsed xml configuration, where we'll get our storage service filter and required dependency flag.
- XmlConfiguration _xmlConfiguration;
-
- // Dynamically configure the dependency declared with a "storage" name.
- @Init
- void init(org.apache.felix.dm.Comppnent myComponent) {
- boolean required = _xmlConfiguration.isStorageRequired();
- String filter = _xmlConfiguration.getStorageType();
- DependencyManager dm = myComponent.getDependencyManager();
- myComponent.add(dm.createServiceDependency().setService(Storage.class, filter).setRequired(required));
- }
-
- // Injected after init, later, when the dependency added from the init() method is satisfied
- volatile Storage storage;
-
- // All dependencies injected, including dynamic dependencies defined from init method.
- @Start
- void start() {
- log.log(LogService.LOG_WARNING, "start");
- }
-
- @Override
- void store(String key, String value) {
- storage.store(key, value);
- }
- }
-
-Same example as above, but this time the dependency is added from the init method using the
-Dependency Manager Lambda API:
-
- :::java
- import static org.apache.felix.dm.lambda.DependencyManagerActivator.component;
-
- @Component
- public class PersistenceImpl implements Persistence {
- // Injected before init.
- @ConfigurationDependency
- void updated(Dictionary conf) {
- if (conf != null) {
- _xmlConfiguration = parseXmlConfiguration(conf.get("xmlConfiguration"));
- }
- }
-
- // Parsed xml configuration, where we'll get our storage service filter and required dependency flag.
- XmlConfiguration _xmlConfiguration;
-
- // Dynamically configure the dependency declared with a "storage" name.
- @Init
- void init(org.apache.felix.dm.Comppnent myComponent) {
- boolean required = _xmlConfiguration.isStorageRequired();
- String filter = _xmlConfiguration.getStorageType();
- component(myComponent, comp -> comp.withSvc(Storage.class, filter, required));
- }
-
- // Injected after init, later, when the dependency added from the init() method is satisfied
- volatile Storage storage;
-
- // All dependencies injected, including dynamic dependencies defined from init method.
- @Start
- void start() {
- log.log(LogService.LOG_WARNING, "start");
- }
-
- @Override
- void store(String key, String value) {
- storage.store(key, value);
- }
- }
-
-# Component Composition
-
-When implementing more complex services, you often find yourself using more than one instance for a given service.
-However, several of these instances might want to have dependencies injected. In such cases you need to tell the
-dependency manager which instances to consider. Within a Component (or an Aspect/Adapter), you can annotate a method
-with the @Composition annotation. This method is meant to return such composition of service instances, and the objects
-will be considered as part of the service implementation. So, all dependencies, as well as lifecycle annotations
-(@Init, @Start, @Stop, @Destroy) will be applied on every objects returned by the method annotated with the @Composition annotation.
-
-The following example illustrates a composition of two object instances, which are part of the implementation of a *MyService* service:
-
- :::java
- /**
- * Main implementation for the MyService Service
- */
- @Component
- public class MyServiceImpl implements MyService {
- // This object instance is also used to implement the service.
- private Helper helper = new Helper();
-
- // MyServiceImpl, and Helper objects are part of the composition
- @Composition
- Object[] getComposition() {
- return new Object[] { this, helper };
- }
-
- // This dependency is also applied to the Helper
- @ServiceDependency
- Dependency dep;
-
- // Same thing for this dependency
- @ServiceDependency
- void bind(Dependency2 dep2) {}
-
- // Lifecycle callbacks also applied on the Helper ...
-
- @Start
- void start() {}
-
- }
-
- public class Helper {
- // Also injected, since we are part of the composition
- volatile Dependency dep;
-
- // But since we are not interested by the Dependency2, we don't have to declare the bind(Dependency2) method ...
-
- // We only specify the start lifecycle callback because we need to return some extra service properties which will be published
- // along with the provided service ...
-
- Map start() {
- Map extraServiceProperties = new HashMap();
- extraServiceProperties.add("foo", "bar");
- return extraServiceProperties;
- }
- }
-
-Here, MyServiceImpl is the main component implementation, but is composed of the Helper object
-instance. So all Dependencies defined in MyServiceImpl
-will be also injected to the Helper (if the Helper declares the fields or methods).
-The Helper may also define annotated lifecycle callbacks (optionally).
-
-# Service scopes
-
-By default service providers are registered once in the osgi registry, and all service consumers share the same service provider instance.
-Now, you can control the scope of the provided services: From the provider side, a "scope" parameter
-is available for all types of DM components and allows to define the scope of the registered service.
-
-The `scope` attribute has three enum values: SINGLETON, BUNDLE, PROTOTYPE
-
-- SINGLETON: it's as before: your registered service is a singleton, meaning that the service must be
-instantiated and registered once, and all using services will share the same service instance of your component.
-- BUNDLE: the service will be registered as a ServiceFactory, meaning an instance of the component must be
-created for each bundle using the service.
-- PROTOTYPE: the service will be registered as a PrototypeServiceFactory, meaning the service is registered as
-a prototype scope service and an instance of the component must be created for each distinct service requester.
-
-Scoped Services are supported by all kind of DM service components:
-
-- Component
-- Aspect Service
-- Adapter Service
-- Bundle Adapter service
-
-When a consumer requests a service (using ServiceDependency), then DM will automatically
-dereference the service like this:
-
-- if the service has a SERVICE_SCOPE service property matching SCOPE_PROTOTYPE, the DM will
-internally derefence the service using the ServiceObject API: so, the consumer will get its own copy
-of the requested service instance.
-- else, DM will internally dereference the service, as before.
-When defining scoped component implementation, you can optionally define two special class fields
-in order to get injected with the client Bundle requesting the service, and the ServiceRegisgtration
-Object. Just use @Inject annotations in order to get injected with the client
-Bundle or the ServiceRegistration. You can also define a constructor which takes as argument the
-client bundle as well as the service registration.
-
-Example:
-
-Here is a MyService component with PROTOTYPE scope, each requester will get its own copy of
-MyService instance, and the MyServiceImpl.start() method will be called for each instance:
-
-
- :::java
- import org.apache.felix.dm.annotation.api.Component;
- import org.apache.felix.dm.annotation.api.ServiceScope;
-
- @Component(scope=ServiceScope.PROTOTYPE)
- public class MyServiceImpl implements MyService {
- @Start
- void start() {
- // called on each MyService instance
- }
- }
-
-The above service will then automatically be instantiated for each service requester:
-
- :::java
- import org.apache.felix.dm.annotation.api.Component;
- import org.apache.felix.dm.annotation.api.ServiceScope;
-
- @Component
- public class Client1 {
- @ServiceDependency
- void bind(MyService service) {
- // Client1 will be injected with its own MyService instance
- }
- }
-
- @Component
- public class Client2 {
- @ServiceDependency
- void bind(MyService service) {
- // Client2 will be injected with its own MyService instance
- }
- }
-
-The two Client1/Client2 above will be injected with two distinct component instances for the
-MyService service (each MyServiceImpl instance will be invoked in its start callback).
-Now, if you want to control the creation of the MyService, you can then define a bind method which
-takes as argument a ServiceObjects parameter like this:
-
- :::java
- import org.apache.felix.dm.annotation.api.Component;
- import org.apache.felix.dm.annotation.api.ServiceScope;
-
- @Component
- public static class Client {
- @ServiceDependency
- void bind(ServiceObject<MyService> serviceObjects) {
- MyService service;
- try {
- service = serviceObjects.getService();
- } finally {
- serviceObjects.ungetService(service);
- }
- }
- }
-
-Internally, DM will use the
-PrototypeServiceFactory.getService(Bundle clientBundle, ServiceRegistration reg) method in order to
-instantiate the MyServiceImpl component. So, the MyServiceImpl component can optionally use the
-@Inject annotation in order to get injected with the clientBundle and/or the service registration,
-like this:
-
- :::java
- import org.apache.felix.dm.annotation.api.Component;
- import org.apache.felix.dm.annotation.api.ServiceScope;
-
- @Component(scope=ServiceScope.PROTOTYPE)
- public static class MyServiceImpl implements MyService {
-
- @Inject
- Bundle m_clientBundle;
-
- @Inject
- ServiceRegisration m_registration;
-
- @Start
- void start() {
- // called on each MyService instance.
- }
- }
-
-The Bundle and ServiceRegistration can also be injected in the component Constructor:
-
- :::java
- import org.apache.felix.dm.annotation.api.Component;
- import org.apache.felix.dm.annotation.api.ServiceScope;
-
- @Component(scope=ServiceScope.PROTOTYPE)
- public static class MyServiceImpl implements MyService {
-
- public MyServiceImpl(Bundle clientBundle, ServiceRegistration registration) {
- ...
- }
-
- @Start
- void start() {
- // called on each MyService instance.
- }
- }
-
-**Notice that when defining a scoped service with annotations, it is not possible to return service
-properties dynamically from the start method (annotated with @Start).**
-
-# Service property types
-
-So far, you could define component service properties using DM @Property annotation,
-and component configuration could be declared as user defined interfaces.
-You can now declare user-defined annotations which can be used to specify both service
-properties and component configuration.
-It means that instead of declaring service properties using @Property annotation,
-you can now use your own annotations (which must be annotated with the new
-@PropertyType annotation, or possibly using the standard @ComponentPropertyType
-annotation).
-
-Usage example:
-
-Let’s assume your write an OSGi r7 jaxrs servlet context which needs the two
-following service properties:
-
-- `osgi.http.whiteboard.context.name`
-- `osgi.http.whiteboard.context.path`
-
-Then you can first define your own annotation (but you could also reuse the default
-annotations provided by the new upcomming jaxrs whiteboard r7 api, from the
-org.osgi.service.jaxrs.whiteboard.propertytypes package):
-
- :::java
- import org.apache.felix.dependencymanager.annotation.PropertyType;
-
- @PropertyType
- @interface ServletContext {
- String osgi_http_whiteboard_context_name() default AppServletContext.NAME;
- String osgi_http_whiteboard_context_path();
- }
-
-In the above, the underscore is mapped to ".", and you can apply the above annotation on
-top of your component like this:
-
- :::java
- @Component
- @ServletContext(osgi_http_whiteboard_context_path="/game")
- public class AppServletContext extends ServletContextHelper {
- }
-
-You can also use configuration admin service in order to override the default s
-ervice properties:
-
- :::java
- @Component
- @ServletContext(osgi_http_whiteboard_context_path="/game")
- public class AppServletContext extends ServletContextHelper {
- @ConfigurationDependency(propagate=true, pid="my.pid")
- void updated(ServletContext cnf) {
- // if some properties are not present in the configuration, then the ones used in the
- // annotation will be used.
- // The configuration admin properties, if defined, will override the default configurations
- // defined in the annotations
- }
- }
-
-You can also define multiple property type annotations, and possibly single valued
-annotation, like it is the case with standard r7 DS. In this case, you can use the
-standard R7 PREFIX_ constants in order to specify the property prefix, and the property
-name will be derived from the single valued annotation (using camel case convention):
-
- :::java
- @PropertyType
- @interface ContextName { // will map to "osgi.http.whiteboard.context.name" property name
- String PREFIX_="osgi.http.whiteboard.";
- String value();
- }
-
- @PropertyType
- @interface ContextPath { // will map to "osgi.http.whiteboard.context.path" property name
- String PREFIX_="osgi.http.whiteboard.";
- String value();
- }
-
- @Component
- @ContextName(AppServletContext.NAME)
- @ContextPath("/game")
- public class AppServletContext extends ServletContextHelper {
- }
-
-Same example as above, but also using configuration admin service in order to override
-default service properties: Here, as in OSGi r7 declarative service, you can define a
-callback method which accepts as arguments all (or some of) the defined property types:
-
- :::java
- @Component
- @ContextName(AppServletContext.NAME)
- @ContextPath("/game")
- public class AppServletContext extends ServletContextHelper {
- @ConfigurationDependency(propagate=true, pid="my.pid")
- void updated(ContextName ctxName, ContextPath ctxPath) {
- // if some properties are not present in the configuration, then the ones used in the annotation will be used.
- // The configuration admin properties, if defined, will override the default configurations defined in the annotations
- }
- }
-
-The following is the same example as above, but this time the configuration callback can also define a Dictionary in the first argument (in case you want to also get the raw configuration dictionary:
-
- :::java
- @Component
- @ContextName(AppServletContext.NAME)
- @ContextPath("/game")
- public class AppServletContext extends ServletContextHelper {
- @ConfigurationDependency(propagate=true, pid="my.pid")
- void updated(Dictionary<String, Object> rawConfig, ContextName ctxName) {
- // if some properties are not present in the configuration, then the ones used in the annotation will be used.
- // The configuration admin properties, if defined, will override the default configurations defined in the annotations
- }
- }
-
-Empty Marker annotations can also be used: when you define an empty annotation, it will be mapped to a java.lang.Boolean property type with Boolean.TRUE value. For example, the following component will be registered with "osgi.jaxrs.resource" service property with Boolean.TRUE value:
-
- :::java
- @PropertyType
- @interface JaxrsResource { // will map to "osgi.jaxrs.resource" property name
- String PREFIX_="osgi.";
- }
-
- @Component(provides = MyResource.class)
- @JaxrsResource
- public class MyResource {
- @Path(“foo”)
- @GET
- public void getFoo() {
- ...
- }
- }
-
-User defined property types can also be applied on factory components, for example,
-in the following, the service properties are declared using the user-defined annotations
-(they will be overriden from the factory configuratin, if present in the config):
-
- :::java
- @Component(factoryPid="my.factory.pid", propagate=true)
- @ContextName(AppServletContext.NAME)
- ContextPath("/game")
- class Hello implements HelloService {
- void updated(ContextName ctxName, ContextPath ctxPath) {
- // Configure or reconfigure our component. the default service
- // properties will be overriden by the factory configuration (if the
- // service properties are defined in the config)
- }
- }
-
-
-
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/reference/external-links.mdtext b/modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/reference/external-links.mdtext
deleted file mode 100644
index 604ef31..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/reference/external-links.mdtext
+++ /dev/null
@@ -1,7 +0,0 @@
-Title: Dependency Manager - External Links
-
-This page regroups Dependency Manager external articles and related links:
-
-* [BndTools based demo of Dependency Manager annotations](https://bitbucket.org/marrs/bndtools-dmdemo)
-* [Introduction to Dependency Manager](http://arnhem.luminis.eu/introduction-apache-felix-dependency-manager)
-* [Introduction to Dependency Manager, part II](http://arnhem.luminis.eu/introduction-apache-felix-dependencymanager-part-2)
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/reference/service-scopes.mdtext b/modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/reference/service-scopes.mdtext
deleted file mode 100644
index c34da95..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/reference/service-scopes.mdtext
+++ /dev/null
@@ -1,221 +0,0 @@
-Title:
-Notice: Licensed to the Apache Software Foundation (ASF) under one
- or more contributor license agreements. See the NOTICE file
- distributed with this work for additional information
- regarding copyright ownership. The ASF licenses this file
- to you under the Apache License, Version 2.0 (the
- "License"); you may not use this file except in compliance
- with the License. You may obtain a copy of the License at
- .
- http://www.apache.org/licenses/LICENSE-2.0
- .
- Unless required by applicable law or agreed to in writing,
- software distributed under the License is distributed on an
- "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
- KIND, either express or implied. See the License for the
- specific language governing permissions and limitations
- under the License.
-
-Dependency Manager - Service Scopes
-
-By default service providers are registered once in the osgi registry, and all service consumers share the same service provider instance.
-Now, you can control the scope of the provided services: From the provider side, a "scope" parameter
-is available for all types of DM components and allows to define the scope of the registered service.
-
-The `scope` attribute has three enum values: SINGLETON, BUNDLE, PROTOTYPE
-
-- SINGLETON: it's as before: your registered service is a singleton, meaning that the service must be
-instantiated and registered once, and all using services will share the same service instance of your component.
-- BUNDLE: the service will be registered as a ServiceFactory, meaning an instance of the component must be
-created for each bundle using the service.
-- PROTOTYPE: the service will be registered as a PrototypeServiceFactory, meaning the service is registered as
-a prototype scope service and an instance of the component must be created for each distinct service requester.
-
-Scoped Services are supported by all kind of DM service components:
-
-- Component
-- Aspects
-- Adapters
-- Bundle Adapters
-- Resource Adapters
-
-When a consumer requests a service (using ServiceDependency), then DM will automatically
-dereference the service like this:
-
-- if the service has a SERVICE_SCOPE service property matching SCOPE_PROTOTYPE, the DM will
-internally derefence the service using the ServiceObject API: so, the consumer will get its own copy
-of the requested service instance.
-- else, DM will internally dereference the service, as before.
-When defining scoped component implementation, you can optionally define two special class fields
-in order to get injected with the client Bundle requesting the service, and the ServiceRegisgtration
-Object. Just use @Inject annotations in order to get injected with the client
-Bundle or the ServiceRegistration. You can also define a constructor which takes as argument the
-client bundle as well as the service registration.
-
-# Examples
-
-So, here is a MyService component with PROTOTYPE scope, and each requester will get its own copy
-of MyService instance (the MyServiceImpl.start() method will be called for each MyServiceImpl
-instance):
-
- :::java
- public class Activator extends DependencyActivatorBase {
- @Override
- public void init(BundleContext context, DependencyManager dm) throws Exception {
- dm.add(createComponent()
- .setScope(ServiceScope.PROTOTYPE)
- .setInterface(MyService.class.getName(), null)
- .setImplementation(MyServiceImpl.class));
- }
- }
-
- public class MyServiceImpl implements MyService {
- void start() {
- // called on each MyService instance
- }
- }
-
-The MyServiceImpl, like with annotations, can define a constructor in order to be injected with
-the client bundle invoking the service and also the service Registration:
-
- :::java
- public class MyServiceImpl implements MyService {
- public MyServiceImpl(Bundle clientBundle, ServiceRegistration reg) { ... }
- void start() {
- // called on each MyService instance
- }
- }
-
-(if you want to auto configure the client Bundle, and the ServiceRegistration, then simply define class fields, they will be auto injected, unless you disable auto configuraiton for Bundle/ServiceRegistration using Component.setAutoConfig(Class, boolean) methods.
-
-Here is a Client component which simply depends on the MyService service using a basic DM
-activator (nothing special to do):
-
- :::java
- public class Activator extends DependencyActivatorBase {
- @Override
- public void init(BundleContext context, DependencyManager dm) throws Exception {
- dm.add(createComponent()
- .setImplementation(Client.class)
- .add(createServiceDependency()
- .setService(MyService.class, null).setRequired(true).setCallbacks("bind", "unbind"));
- }
- }
-
- public class Client {
- void bind(MyService service) {
- // our client is injected with a specific instance of the MyService component
- // that is created for our Client.
- // If another component defines a service dependency on MyService, then the other
- // component will get its own private copy of MyService component instance
- }
- }
-
-# Example using ServiceObjects API
-
-If now you want to control the creation of the MyService using raw OSGI ServiceObjects API,
-you can also do it like this:
-
-
- :::java
- public class Client {
- void bind(ServiceObjects<MyService> so) {
- MyService s1 = so.getService();
- MyService s2 = so.getService();
- ...
- so.ungetService(s1); // will deactivate the MyService s1 instance
- so.ungetService(s2); // will deactivate the MyService s2 instance
- }
- }
-
-# Scoped services and init/destroy callbacks
-
-When you need to specify dynamic required dependencies from your component.init() method,
-the following mechanism will be used:
-
-First, if your component defines an init callback, then one single component prototype instance singleton is created, as if the component is declared with SCOPE=SINGLETON.
-So, the prototype instance will be invoked in the init callback, but won't be called in start()/stop().
-And when all dependencies are satisfied and injected (including the dynamic dependencies defined in the init method),
-then the ServiceFactory (or PrototypeServiceFactory) is registered.
-And when one client will request a component instance, then a clone will be created and returned.
-
-Example of a scoped component which defines an init method:
-
- :::java
- public class Activator extends DependencyActivatorBase {
- @Override
- public void init(BundleContext context, DependencyManager dm) throws Exception {
- dm.add(createComponent()
- .setScope(ServiceScope.PROTOTYPE)
- .setInterface(MyService.class.getName(), null)
- .setImplementation(MyServiceImpl.class));
- }
- }
-
- public static class MyServiceImpl implements MyService {
- void init(Component comp) {
- // add required dependencies dynamically
- }
-
- void start() {
- // only called on clone, not on the prototype instance singleton
- }
-
- void stop() {
- // called on each clone, not on the prototype instance singleton
- }
- }
-
-So, if you don't specify an init callback then the prototype instance singleton won't be instantiated. Also,
-
-# Limitation when using DM ServiceDependency from API and ServiceObjects
-
-When using DependencyManager ServiceDependency from the DM API (not using annotations),
-you have to know that the ServiceDependency always internally dereferences the
-service dependency, even if you specify a ServiceObjecs
-parameter in your bind method. If now you really want to disable the auto-deref ServiceDependency
-(because you want to directly use the ServiceObjects API), you must then use the
-"setDereference(false") method on your ServiceDependency: in this way, you tell DM to never
-dereference internally the scoped service. Here is an example:
-
- :::java
- public class Activator extends DependencyActivatorBase {
- @Override
- public void init(BundleContext context, DependencyManager dm) throws Exception {
- dm.add(createComponent()
- .setImplementation(Client.class)
- .add(createServiceDependency()
- .setService(MyService.class, null).setRequired(true).setCallbacks("bind", "unbind")
- .setDereference(false));
- }
- }
-
- public class Client {
- void bind(ServiceObjects<MyService> so) {
- MyService s1 = so.getService();
- MyService s2 = so.getService();
- ...
- so.ungetService(s1); // will deactivate the MyService s1 instance
- so.ungetService(s2); // will deactivate the MyService s2 instance
- }
- }
-
-In the above example, the Activator defines the ServiceDependency using the
-ServiceDependency.setDereference(false) method because it's the Client.bind method which will
-create the MyService instances manually.
-
-In the future, I will try to auto detect the signatures of the Client.bind method in order to
-never auto-dereference the injected service in case the bind method takes as argument a
-ServiceObjects (or a ServiceReference) method.
-
-
-
-
-
-
-
-
-
-
-
-
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/reference/thread-model.mdtext b/modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/reference/thread-model.mdtext
deleted file mode 100644
index 3a0e732..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/reference/thread-model.mdtext
+++ /dev/null
@@ -1,113 +0,0 @@
-Title: Dependency Manager - Thread Model
-
-This section gives a brief overview of the default thread model used by Dependency Manager, and also explains how to start and handle components concurrently.
-
-## Default thread model
-
-By default, Dependency Manager uses a lock-free/single thread model:
-
-* When an external event that influence the state of a Component is taking place (for example, when a service dependency on which the Component is depending on is registered in the
-registry by a given thread), then DependencyManager does not perform any locking for the handling of the event. Instead of that, a job that will handle the event is inserted in an internal
-lock-free Serial Queue which is internally maintained in each Component.
-* All jobs scheduled in the Serial Queue are then executed in FIFO order, by the first thread which has triggered the first event. This avoid to use some blocking locks in DM internals, and
-also it simplifies the development of DM components, because all lifecycle callbacks (init/start/stop/destroy) and dependency injections are scheduled through the Serial Queue: This means
-that your component is not concurrently called in lifecycle callbacks and in dependency injection methods.
-* Now let's describe which thread is executing the jobs scheduled in a Component Serial Queue: When a job (J1) is scheduled in the queue while it is empty, then the current thread becomes
-the "master" and will immediately execute the Serial Queue tasks (synchronously). And if another thread triggers another event concurrently while the "master" thread is executing the job J1,
-then a job (J2) for this new event is just enqueued in the Serial Queue, but the other thread returns immediately to the caller, and the job J2 will then be executed by the "master" thread
-(after J1).
-
-This mechanism allows to serially handle all Component events (service dependencies) in FIFO order without maintaining any locks.
-
-The following diagram illustrates the thread model we just described:
-
-<img src="./diagrams/serial-queue.png" alt="Serial Queue" style="width: 600px"/>
-
-## Enabling parallelism with a *ComponentExecutorFactory*
-
-As described above, all the external events that influence the state of a given component are handed by jobs scheduled in the Serial Queue of the Component, and the jobs are getting
-executed serially by a single "master" thread. So usually, bundles are started from a single thread, meaning that all Components are then activated synchronously.
-
-But when you register in the OSGi service registry a ComponentExecutorFactory, that factory will be used by DependencyManager to create an Executor of your choice for each Component,
-typically a shared threadpool configured by yourself. And all the Component Serial Queues will be executed using the Executor returned by the getExecutorFor(Component) method. However,
-jobs scheduled in the Serial Queue of a given Component are still executed one at a time, in FIFO order and the Component remains single threaded, and independent Components may then each
-be managed and activated concurrently with respect to each other.
-
-Here is a diagram which illustrates all this:
-
-<img src="./diagrams/concurrent-serial-queue.png" alt="Concurrent Serial Queue" style="width: 600px"/>
-
-If you want to ensure that all Components are initialized after the ComponentExecutorFactory is registered in the OSGI registry, you can use the "org.apache.felix.dependencymanager.parallel"
-OSGi system property which specifies the list of components which must wait for the ComponentExecutorFactory service. This property value can be set to a wildcard ("*"), or a list of
-components implementation class prefixes (comma separated). So, all components whose class name starts with the specified prefixes will be cached until the ComponentExecutorFactory service
-is registered (In this way, it is not necessary to use the StartLevel service if you want to ensure that all components are started concurrently).
-
-Some class name prefixes can also be negated (using "!"), in order to exclude some components from the list of components using the ComponentExecutorFactory service.
-
-Notice that if the ComponentExecutorFactory itself and all its dependent services are defined using the Dependency Manager API, then you have to list the package of such components with a
-"!" prefix, in order to indicate that those components must not wait for a ComponentExecutorFactory service (since they are part of the ComponentExecutorFactory implementation !).
-
-
-### Examples usage of the *org.apache.felix.dependencymanager.parallel* property:
-
- org.apache.felix.dependencymanager.parallel=*
- -> means all components must be cached until a ComponentExecutorFactory comes up.
-
- org.apache.felix.dependencymanager.parallel=foo.bar, foo.zoo
- -> means only components whose implementation class names are starting with "foo.bar" or "foo.zoo"
- must be handled using an Executor returned by the ComponentExecutorFactory service. Other Components
- will be handled normally, as when there is no ComponentExecutorFactory available.
-
- org.apache.felix.dependencymanager.parallel=!foo.threadpool, *
- -> means all components must be delayed until the ComponentExecutorFactory comes up, except the
- components whose implementations class names are starting with "foo.threadpool" prefix).
-
-
-### Examples of a ComponentExecutorFactory that provides a shared threadpool:
-
-First, we define the OSGi bundle context system property to enable parallelism for all DM Components excepts the one which declares the ComponentExecutorFactory:
-
- org.apache.felix.dependencymanager.parallel=!com.acme.management.threadpool, *
-
-
-Next, here is the Activator which declares the ComponentExecutorFactory:
-
- :::java
- package com.acme.management.threadpool;
- import org.apache.felix.dm.*;
-
- public class Activator extends DependencyActivatorBase {
- public void init(BundleContext context, DependencyManager mgr) throws Exception {
- mgr.add(createComponent()
- .setInterface(ComponentExecutorFactory.class.getName(), null)
- .setImplementation(ComponentExecutorFactoryImpl.class)
- .add(createConfigurationDependency()
- .setPid("com.acme.management.threadpool.ComponentExecutorFactoryImpl")));
- }
- }
-
-
-And here is the implementation for our ComponentExecutorFactory:
-
- package com.acme.management.threadpool;
- import org.apache.felix.dm.ComponentExecutorFactory;
-
- public class ComponentExecutorFactoryImpl implements ComponentExecutorFactory {
- volatile Executor sharedThreadPool;
-
- void updated(Dictionary conf) {
- int size = Integer.parseInt((String) conf.get("threadpool.size"));
- sharedThreadPool = Executors.newFixedThreadPool(size);
- }
-
- @Override
- public Executor getExecutorFor(Component component) {
- return sharedThreadPool; // Use a shared threadpool for all Components
- }
- }
-
-You will find a live example in the source distribution [sample codes](https://svn.apache.org/repos/asf/felix/trunk/dependencymanager/org.apache.felix.dependencymanager.samples/):
-
-* [see the bnd.bnd](https://svn.apache.org/repos/asf/felix/trunk/dependencymanager/org.apache.felix.dependencymanager.samples/bnd.bnd) which configures the org.apache.felix.dependencymanager.parallel in the *-runproperties* option.
-* [see the executor factory](https://svn.apache.org/repos/asf/felix/trunk/dependencymanager/org.apache.felix.dependencymanager.samples/src/org/apache/felix/dependencymanager/samples/tpool/) sample code and README file to up-to-date informations.
-
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/tutorials/getting-started.mdtext b/modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/tutorials/getting-started.mdtext
deleted file mode 100644
index d01cc07..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/tutorials/getting-started.mdtext
+++ /dev/null
@@ -1,195 +0,0 @@
-Title: Dependency Manager - Getting Started
-
-When developing an OSGi bundle that has dependencies and possibly registers services, there are two classes in particular we need to implement:
-
-1. The bundle activator which controls the life-cycle of the bundle.
-1. The actual component, which can be a POJO.
-
-When using the dependency manager, your bundle activator is a subclass of `DependencyActivatorBase`. It needs to implement the `init` life cycle method and can optionally also implement a `destroy` method. Both methods take two arguments: `BundleContext` and `DependencyManager`. The latter is your interface to the declarative API you can use to define your components and dependencies.
-
-The following paragraphs will show various examples that explain how to do this. Subsequently, some more advanced scenarios will be covered that involve listening to dependency and component state changes and interacting with the OSGi framework from within your component implementation.
-
-To use the dependency manager, you should put the `org.apache.felix.dependencymanager.jar` in your classpath while compiling and in your OSGi framework when running.
-
-A recent java 8 jdk is required since the dependency manager r8 (the dm r8 release has been built and tested using java version 1.8.74).
-
-## Registering a service
-
-The first example is about registering a service. We extend `DependencyActivatorBase` and in the `init` method we use the reference to the `DependencyManager` to create and add a component. For this component we subsequently set its service interface and implementation. In this case the interface is the `Store` interface, the second parameter, `null`, allows you to provide properties along with the service registration. For the implementation, we only mention the `Class` of the implement [...]
-
-Notice that the dependency manager API uses method chaining to create a more or less "fluent" API that, with proper indentation, is very easy to read.
-
-
- public class Activator extends DependencyActivatorBase {
- public void init(BundleContext context, DependencyManager manager) throws Exception {
- manager.add(createComponent()
- .setInterface(Store.class, null)
- .setImplementation(MemoryStore.class)
- );
- }
- }
-
-
-This is the service interface. Nothing special here.
-
-
- public interface Store {
- public void put(String key, Object value);
- public Object get(String key);
- }
-
-
-And finally the implementation. Again, this is just a POJO, there is no reference here to any OSGi or dependency manager specific class or annotation.
-
-
- public class MemoryStore implements Store {
- private Map m_map = new HashMap();
-
- public Object get(String key) {
- return m_map.get(key);
- }
-
- public void put(String key, Object value) {
- m_map.put(key, value);
- }
- }
-
-
-## Depending on a service
-
-Our second example is that of a component that depends on two other services: our `Store` from the previous example and the standard OSGi `LogService`. Looking at the code, there is a small but important difference between the two: `Store` is a required dependency and `LogService` is not. This means that our component really needs a store to work, but if there is no logging available, it can work without. Also note that this component has no `setInterface` method, which simply means it i [...]
-
-
- public class Activator extends DependencyActivatorBase {
- public void init(BundleContext context, DependencyManager manager) throws Exception {
- manager.add(createComponent()
- .setImplementation(DataGenerator.class)
- .add(createServiceDependency()
- .setService(Store.class)
- .setRequired(true)
- )
- .add(createServiceDependency()
- .setService(LogService.class)
- .setRequired(false)
- )
- );
- }
- }
-
-
-Now let's look at our POJO. There are a couple of interesting things to explain. First of all, our dependencies are declared as fields, and they don't even have setters (or getters). When the dependency manager instantiates our class, it will (through reflection) inject the dependencies so they are just available for our class to use. That is also the reason these fields are declared as volatile: to make sure they are visible to all threads traversing our instance.
-
-One final note, since we defined our `LogService` dependency as optional, it might not be available when we invoke it. Still, the code does not contain any checks to avoid a null pointer exception. It does not need to, since the dependency manager makes sure to inject a null object when the real service is not available. The null object can be invoked and will do nothing. For a lot of cases that is good enough, but for those cases where it is not, our next example introduces callbacks th [...]
-
-
- public class DataGenerator {
- private volatile Store m_store;
- private volatile LogService m_log;
-
- public void generate() {
- for (int i = 0; i < 10; i++) {
- m_store.put("#" + i, "value_" + i);
- }
- m_log.log(LogService.LOG_INFO, "Data generated.");
- }
- }
-
-
-## Tracking services with callbacks
-
-Sometimes, simply injecting services does not give you enough control over a dependency because you might want to track more than one, or you might want to execute some code on changes. For all those cases, callbacks are your friends. Since one of our goals is to not introduce any kind of API in our POJO, callbacks are declared by specifying their method names instead of through some interface. In this case, we have a dependency on `Translator` services, and we define `added` and `remove [...]
-
-
- public class Activator extends DependencyActivatorBase {
- public void init(BundleContext context, DependencyManager manager) throws Exception {
- manager.add(createComponent()
- .setImplementation(DocumentTranslator.class)
- .add(createServiceDependency()
- .setService(Translator.class)
- .setRequired(false)
- .setCallbacks("added", "removed")
- )
- );
- }
- }
-
-
-This is the actual `Translator` service, which, for the purpose of this example, is not that important.
-
-
- public interface Translator {
- public boolean canTranslate(String from, String to);
- public Document translate(Document document, String from, String to);
- }
-
-
-Finally, here's our implementation. It declares the callback methods with one parameter: the `Translator` service. Actually, the dependency manager will look for several different signatures (all explained in more detail in the reference section).
-
-
- public class DocumentTranslator {
- private List<Translator> m_translators = new ArrayList<Translator>();
-
- public void added(Translator translator) {
- m_translators.add(translator);
- }
-
- public void removed(Translator translator) {
- m_translators.remove(translator);
- }
-
- public Document translate(Document document, String from, String to) {
- for (Translator translator : m_translators) {
- if (translator.canTranslate(from, to)) {
- return translator.translate(document, from, to);
- }
- }
- return null;
- }
- }
-
-## Depending on a configuration
-
-Not all dependencies are on services. There are several other types of dependencies
-that are supported, one of them is the configuration dependency.
-When defining the dependency, you must define the persistent ID of the service.
-The component will not become active until the configuration you depend on is available
-*and* is valid. The latter can be checked by your implementation as we will see below.
-
-
- public class Activator extends DependencyActivatorBase {
- public void init(BundleContext context, DependencyManager manager) throws Exception {
- manager.add(createComponent()
- .setImplementation(Task.class)
- .add(createConfigurationDependency()
- .setPid("config.pid")
- )
- );
- }
- }
-
-
-Here's our code that implements `ManagedService` and has an `updated` method.
-This method checks if the provided configuration is valid and throw a
-`ConfigurationException` if it is not. As long as this method does not accept the
-configuration, the corresponding component will not be activated.
-Notice that your component does not necessarily implement the ManagedService interface, and the updated callback
-can also throw any exceptions:
-
-
- public class Task implements ManagedService {
- private String m_interval;
-
- public void execute() {
- System.out.println("Scheduling task with interval " + m_interval);
- }
-
- public void updated(Dictionary properties) throws ConfigurationException {
- if (properties != null) {
- m_interval = (String) properties.get("interval");
- if (m_interval == null) {
- throw new ConfigurationException("interval", "must be specified");
- }
- }
- }
- }
-
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/tutorials/leveraging-the-shell.mdtext b/modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/tutorials/leveraging-the-shell.mdtext
deleted file mode 100644
index 872353e..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/tutorials/leveraging-the-shell.mdtext
+++ /dev/null
@@ -1,97 +0,0 @@
-Title: Dependency Manager - Leveraging the shell
-
-The shell bundle for the dependency manager extends the gogo shell with one new command called "dm". This command can be used to get insight in the actual components and services in a running OSGi framework.
-
-Typing help ```help dm``` in the gogo shell gives an overview of the available command options.
-
- dm - List dependency manager components
- scope: dependencymanager
- flags:
- compact, cp Displays components using a compact form
- nodeps, nd Hides component dependencies
- notavail, na Only displays unavailable components
- stats, stat, st Displays components statistics
- wtf Detects where are the root failures
- options:
- bundleIds, bid, bi, b <List of bundle ids or bundle symbolic
- names to display (comma separated)> [optional]
- componentIds, cid, ci <List of component identifiers to display
- (comma separated)> [optional]
- components, c <Regex(s) used to filter on component
- implementation class names (comma separated), can be
- negated using "!" prefix> [optional]
- services, s <OSGi filter used to filter some service
- properties> [optional]
- top <Max number of top components to display (0=all)> This
- command displays components callbacks (init/start)
- times> [optional]
- parameters:
- CommandSession
-
-## Usage examples
-Below are some examples for typical usage of the dependency manager shell commands. The examples are based on a simple component model with a dashboard which has a required dependency on four probes (temperature, humidity, radiation, pressure). The radiation probe requires a Sensor service but this sensor is not available.
-
-__List all dependency manager components__
-
-```dm```
-
-Sample output:
-
- [9] dm.demo
- [6] dm.demo.Probe(type=radiation) unregistered
- dm.demo.Sensor service required unavailable
- [7] dm.demo.Probe(type=humidity) registered
- [9] dm.demo.impl.Dashboard unregistered
- dm.demo.Probe (type=temperature) service required available
- dm.demo.Probe (type=radiation) service required unavailable
- dm.demo.Probe (type=humidity) service required available
- dm.demo.Probe (type=pressure) service required available
- [5] dm.demo.Probe(type=temperature) registered
- [8] dm.demo.Probe(type=pressure) registered
-
-All components are listed including the dependencies and the availability of these dependencies. The top level element is the bundle and below are the components registered with that bundle's bundle context. The lowest level is that of the component's dependencies.
-
- [bundleid] bundle
- [component id] component interfaces (service properties)
- dependency <availability>
-
-The following flags can be used to tailor the output:
-
-* ```compact, cp``` shortens package names and dependencies and therefore gives a more compressed output.
-* ```nodeps, nd``` omits the dependencies from the output.
-* ```notavail, na``` filters out all components that are registered wich results in the output only containing those components that are in the unregistered state due to one or more unsatisfied required dependencies. This is the command option most used when using the dependency manager shell commands.
-
-Sample output for ```dm na```:
-
- [9] dm.demo
- [14] dm.demo.impl.Dashboard unregistered
- dm.demo.Probe (type=radiation) service required unavailable
- [11] dm.demo.Probe(type=radiation) unregistered
- dm.demo.Sensor service required unavailable
-
-The flags can be used in conjunction with the other command options.
-
-__Find all components for a given classname__
-
-```dm c .*ProbeImpl```
-
-`dm c` or `components` finds all components for which the classname of the implementation matches the regular expression.
-
-__Find all services matching a service filter__
-
-```dm s "(type=temperature)"```
-
-`dm s` allows finding components based on the service properties of their registered services in the service registry using a standard OSGi service filter.
-
-__Find out why components are not registered__
-
-```dm wtf```
-
-Sample output:
-
- 2 missing dependencies found.
- -----------------------------
- The following service(s) are missing:
- * dm.demo.Sensor is not found in the service registry
-
-`wtf` gives the root cause for components not being registered and therefore their services not being available. In a typical application components have dependencies on services implemented by components that have dependencies on services etcetera. This transitivity means that an entire chain of components could be unregistered due to a (few) root dependencies not being satisfied. `wtf` is about discovering those dependencies.
\ No newline at end of file
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/tutorials/sample-code.mdtext b/modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/tutorials/sample-code.mdtext
deleted file mode 100644
index 8b45f8f..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/tutorials/sample-code.mdtext
+++ /dev/null
@@ -1,63 +0,0 @@
-Title: Dependency Manager sample projects
-
-You can download this [archive](dm.hello.tgz) which contains the following directories:
-
-- felix-framework-6.0.1/ -> this is a felix framework with pre-installed dependency manager r13 artifacts, as well as with
-configadmin and metatype bundles (these dependencies are required by dm)
-- hello.api/ -> provides a sample component using the dependency manager API.
-- hello.lambda/ -> provides a sample component using the dependency manager Lambda API.
-- hello.annotations -> provides a sample component using the dependency manager annotations.
-
-All samples can be built using either gradle or maven.
-To build with gradle, simply type "./gradlew jar", and to build with maven, type "mvn clean install".
-If you are using an http proxy, you must set the following environment:
-
-- for gradle: export GRADLE_OPTS="-Dhttp.proxyHost=<ip> -Dhttp.proxyPort=<port> -Dhttps.proxyHost=<ip> -Dhttps.proxyPort=<port>
-- for maven, you must setup your http proxy in your ~/.m2/settings.xml
-
-Once built, the three jars for all hello projects can be put in the felix-framework-6.0.1/bundles/ directory.
-Now start felix like this:
-
- cd felix-framework-6.0.1
- java -jar bin/felix.jar
-
-You should then see the following logs displayed to stdout:
-
- HelloComponent started using Dependency Manager API
- HelloComponent started using Dependency Manager Lambda
- HelloComponent started using Dependency Manager Annotations
-
-You can also play with the dm shell commands. First, type "help dm":
-
- g! help dm
-
- dm - List dependency manager components
- scope: dependencymanager
- flags:
- compact, cp Displays components using a compact form
- nodeps, nd Hides component dependencies
- notavail, na Only displays unavailable components
- stats, stat, st Displays components statistics
- wtf Detects where are the root failures
- options:
- bundleIds, bid, bi, b <List of bundle ids or bundle symbolic names to display (comma separated)> [optional]
- componentIds, cid, ci <List of component identifiers to display (comma separated)> [optional]
- components, c <Regex(s) used to filter on component implementation class names (comma separated), can be negated using "!" prefix> [optional]
- services, s <OSGi filter used to filter some service properties> [optional]
- top <Max number of top components to display (0=all)> This command displays components callbacks (init/start) times> [optional]
-
-Now type "dm" in order to see all dependency manager components:
-
- g! dm
- [1] hello.annotations
- [3] hello.HelloComponent registered
- [2] hello.api
- [0] hello.HelloComponent registered
- [3] hello.lambda
- [1] hello.HelloComponent registered
- [10] org.apache.felix.dependencymanager.runtime
- [2] org.apache.felix.dm.runtime.DependencyManagerRuntime registered
- active (DependencyManager-Component=*) bundle optional available
- org.osgi.service.packageadmin.PackageAdmin service required available
- org.osgi.service.log.LogService service optional unavailable
-
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/tutorials/working-with-annotations.mdtext b/modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/tutorials/working-with-annotations.mdtext
deleted file mode 100644
index 09164c8..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-dependency-manager/tutorials/working-with-annotations.mdtext
+++ /dev/null
@@ -1,214 +0,0 @@
-Title: Dependency Manager - Annotations
-
-The Dependency Manager provides a compact and versatile Java API that allows you to declaratively and programmatically register, acquire, and manage dynamic OSGi components. This has many advantages, but also means you need to implement your own `BundleActivator`. In cases where your dependencies are not that dynamic, an alternative is to use annotations on your component.
-
-This tutorial outlines how to setup and use such annotations to describe your components and dependencies. We present a simple "Hello World" component defined using annotations, and also explain how to build the bundle using either Bnd, Ant, or Maven.
-
-## Hello World Component
-
- package org.apache.felix.dependencymanager.samples.annotation.hello;
-
- import org.apache.felix.dm.annotation.api.Component;
- import org.apache.felix.dm.annotation.api.Start;
-
- @Component
- public class HelloWorld {
- @Start
- public void activate() {
- System.out.println("Hello world !");
- }
- }
-
-## Compiling with BndTools:
-
-This section is a step-by-step tutorial showing how to create a "greeting" project under BndTools and how to use Dependency Manager annotations.
-BndTools is a nice Eclipse plugin on top of the popular "Bnd" builder tool ([See The BndTools home page](http://bndtools.org/)).
-
-It is assumed that you have installed bndtools with a properly configured cnf project (using Bundle-Hub configuration).
-
-### Add DM annotation.jar to the build repository and to the buildpath
-
-Before creating a project that uses the DM annotations, you first have to add the DM annotation jar in the "cnd/buildrepo".
-(In the future, we'll push the DM annotation.jar to the Felix OBR, so you will then simply only have to create
-a bndtools remote repository that will point to the remote Felix OBR).
-
-* Select the "Repositories" Window
-* Select the "Build" repository
-* Then click on the "Add Bundles to Repository" -> "Add External Jar" and point the org.apache.felix.dependencymanager.anntation.jar.
-* Then click on "Finish" button
-
-Now, declare the DM annotation plugin in the BndTools plugin path:
-
-* Select "BndTools/Open ext/pluginpaths.bnd
-* Select the "+" button of the "Plugin Path" section, and select "buildrepo/org.apache.felix.dependencymanager.annotation/org.apache.felix.dependencymanager.annotation-X.Y.Z.jar (replace X.Y.Z by the actual version)
-* Then press "Ctrl-s" to save the configuration
-
-### Create the greeting project
-
-Now we have properly configured the DM annotation plugin in bndtools, we can then create our "greeting" project.
-
-* From the File menu, select "New -> Bndtools OSGi Project" for creating an empty project, and call it "greeting".
-* Click on bnd.bnd file of the greeting project, and click on the "Build" tab, then click on the "+" button, near the "Build Path" section.
-* Then select "Build/org.apache.felix.dependencymanager.annotation" bundle and click on "Add -->".
-* Click on Finish, and save the project (press Ctrl-s).
-
-### Creating the HelloWorld component
-
-Since we have configured the buildpath, we are now ready to create our first HelloWorld component using annotations.
-Create the following class in the greeting project:
-
- :::java
- package greeting;
-
- import org.apache.felix.dm.annotation.api.Component;
- import org.apache.felix.dm.annotation.api.Start;
-
- @Component
- public class HelloWorld {
- @Start
- void start() {
- System.out.println("Hello World");
- }
- }
-
-### Finalize the bnd configuration
-
-We have created our first HelloWorld component. We now have to finish the bnd configuration by specifying a Private-Package directive,
-and we also add the -plugin bnd directive in order to ask bnd to call the DM annotation plugin during compilation:
-
-* Click on the bnd.bnd file of the greeting project
-* Click on Contents and add the "greeting" package in the Private Packages
-* Finally, declare the DM annotation plugin by clicking on the "source" tab, and add the following:
- * -plugin org.apache.felix.dm.annotation.plugin.bnd.AnnotationPlugin;log=debug
-* Save configuration (Press Ctrl-s)
-* Click on "Build" and on "Rebuild"
-
-The greeting.jar should now be generated with a META-INF/dependencymanager/ directory. The plugin logs debug messages in /tmp/dmplugin/*
-
-So, the final bnd.bnd file should look like this:
-
- Bundle-Version: 0.0.0.${tstamp}
- -buildpath: org.apache.felix.dependencymanager.annotation
- Private-Package: greeting
- -plugin org.apache.felix.dm.annotation.plugin.bnd.AnnotationPlugin;log=debug
-
-### Testing the bundle under bndtools:
-
-We are now going to execute a Felix framework under Eclipse/BndTools, and run our HelloWorld example.
-
-First, install the following necessary bundles in the "Local" repository:
-(in the future, we'll release the DM bundles in the Felix OBR, so you will only have to declare a remote repository, instead of doing this):
-
-* Click on Repositories
-* Add the following DM bundles in the "Local" Repository:
- * org.apache.felix.dependencymanager.jar
- * org.apache.felix.dependencymanager.shell.jar
- * org.apache.felix.dependencymanager.runtime.jar
-
-Now, configure the Felix framework, as well as the list of the bundles to be executed:
-
-* Click on the bnd.bnd file of the greeting project
-* Click on the "Run" tab
-* In the Core Runtime, Select the latest version of Felix currently available
-* Select Execution Env=JavaSE-1.7
-* In the "Run Bundles" section, add the following list:
- * org.apache.felix.configadmin.jar
- * org.apache.felix.metatype.jar
- * org.apache.felix.log.jar
- * org.apache.felix.gogo.command
- * org.apache.felix.gogo.runtime
- * org.apache.felix.gogo.shell
- * org.apache.felix.dependencymanager
- * org.apache.felix.dependencymanager.runtime
- * org.apache.felix.dependencymanager.shell
-* Then save the configuration (Press Ctrl-s).
-
-Now, Click on "Run OSGi". You should now see in the Console the Gogo Shell prompt with the
-message displayed by the HelloWorld component:
-
- Hello World
- Welcome to Apache Felix Gogo
- g!
-
-Just type "dm" in the console, and you should see:
-
- [2] org.apache.felix.dependencymanager.runtime
- [0] org.apache.felix.dm.runtime.DependencyManagerRuntime registered
- active (DependencyManager-Component=*) bundle optional available
- org.osgi.service.packageadmin.PackageAdmin service required available
- org.osgi.service.log.LogService service optional available
- [10] greeting
- [1] greeting.HelloWorld registered
-
-The bundle [2] is the dependency manager runtime bundle that is in charge of managing all bundles containing annotated components.
-And the bundle [10] is our greeting bundle (and the "greeting.HelloWorld" component is registered).
-
-## Compiling with Ant:
-
-Since Bnd provides a Ant task, you can use the bnd directives above with the following build.xml:
-(it is assumed that directives.bnd, bnd.jar, json-20070829.jar and org.apache.felix.dependencymanager.annotation.jar are in the current directory)
-
- <project name="TestDM" default="bnd">
- <property name="bnd" value="bnd.jar" />
- <property name="json" value="json-20070829.jar" />
- <property name="dmannot" value="org.apache.felix.dependencymanager.annotation.jar" />
-
- <target name="compile">
- <delete dir="target/classes" quiet="yes" />
- <mkdir dir="target/classes" />
- <javac srcdir="src/main/java" destdir="target/classes" classpath="${dmannot}" />
- </target>
-
- <target name="bnd" depends="compile">
- <taskdef resource="aQute/bnd/ant/taskdef.properties" classpath="${dmannot}:${bnd}:${json}" />
- <bnd classpath="target/classes" eclipse="false" files="directives.bnd" output="org.apache.felix.dependencymanager.samples.annotation.hello.jar" />
- </target>
- </project>
-
-
-## Compiling with Maven:
-
-When compiling with Maven, you have to invoke the Dependency Manager Bnd plugin, using the special "_plugin" directive.
-In the R1 Dependency Manager distribution, the bundles are not published to maven central, and you
-have to manually install the org.apache.felix.dependencymanager.annotation.jar file to your local repository, or to your own corporate nexus server.
-([See this link](http://maven.apache.org/guides/mini/guide-3rd-party-jars-local.html) to manually install the dm annotation jar to your local repository.)
-
- :::xml
- <project ...>
- <dependencies>
- ...
- <dependency>
- <groupId>org.apache.felix</groupId>
- <artifactId>org.apache.felix.dependencymanager.annotation</artifactId>
- <version>4.0.0</version>
- </dependency>
- </dependencies>
- <build>
- <plugins>
- ...
- <plugin>
- <groupId>org.apache.felix</groupId>
- <artifactId>maven-bundle-plugin</artifactId>
- <version>2.5.0</version>
- <extensions>true</extensions>
- <configuration>
- <instructions>
- <Bundle-Name>Test</Bundle-Name>
- <Bundle-SymbolicName>test</Bundle-SymbolicName>
- <Import-Package>*</Import-Package>
- <Private-Package>test.dmannotations</Private-Package>
- <!-- when setting log=debug, logs are writen to /tmp/dmplugin/ directory -->
- <_plugin>org.apache.felix.dm.annotation.plugin.bnd.AnnotationPlugin;log=debug</_plugin>
- </instructions>
- </configuration>
- <dependencies>
- <dependency>
- <groupId>org.apache.felix</groupId>
- <artifactId>org.apache.felix.dependencymanager.annotation</artifactId>
- <version>4.0.0</version>
- </dependency>
- </dependencies>
- </plugin>
- </plugins>
- </build>
- </project>
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-deployment-admin.mdtext b/modules/ROOT/pages/documentation/subprojects/apache-felix-deployment-admin.mdtext
deleted file mode 100644
index 76e8ae9..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-deployment-admin.mdtext
+++ /dev/null
@@ -1,4 +0,0 @@
-Title: Apache Felix Deployment Admin
-
-This project implements the OSGi Deployment Admin specification; please consult the OSGi Compendium Specification chapter 114 for more information.
-
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-event-admin.mdtext b/modules/ROOT/pages/documentation/subprojects/apache-felix-event-admin.mdtext
deleted file mode 100644
index 4bb41a7..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-event-admin.mdtext
+++ /dev/null
@@ -1,225 +0,0 @@
-Title: Apache Felix Event Admin
-
-The Event Admin Service Specification, part of the OSGi Compendium specification, defines a general inter-bundle communication mechanism. The communication conforms to the popular publish/subscribe paradigm and can be performed in a synchronous or asysnchronous manner.
-
-The main components in a publish/subscribe communication are:
-
-* *Event Publisher* - sends events or messages related to a specific *topic*
-* *Event Handler* (or *Subscriber*) - expresses interest in one or more topics and receives all the messages belonging to such topics.
-
-Events are composed of two attributes:
-
-* a *topic* defining the nature of the event; topic names are usually arranged in a hierarchical namespace, where slashes are used to separate the levels (i.e. "org/osgi/framework/FrameworkEvent/STARTED") and
-* a set of *properties* describing the event.
-
-## Creating an Event Publisher
-
-An event publisher is a simple Java class that creates events and sends them using the `EventAdmin` service interface, for example:
-
-
- public void reportGenerated(Report report, BundleContext context)
- {
- ServiceReference ref = context.getServiceReference(EventAdmin.class.getName());
- if (ref != null)
- {
- EventAdmin eventAdmin = (EventAdmin) context.getService(ref);
-
- Dictionary properties = new Hashtable();
- properties.put("title", report.getTitle());
- properties.put("path" , report.getAbsolutePath());
- properties.put("time", System.currentTimeMillis());
-
- Event reportGeneratedEvent = new Event("com/acme/reportgenerator/GENERATED", properties);
-
- eventAdmin.sendEvent(reportGeneratedEvent);
- }
- }
-
-
-The `EventAdmin.sendEvent()` method sends the `Event` object synchronously. To send it asynchronously, use the `EventAdmin.postEvent()` method, such as:
-
-
- //..
- Event reportGeneratedEvent = new Event("com/acme/reportgenerator/GENERATED", properties);
- eventAdmin.postEvent(reportGeneratedEvent);
-
-
-## Creating an Event Handler
-
-Creating an event handler is as simple as implementing the `EventHandler` interface:
-
-
- public class ReportEventHandler implements EventHandler
- {
- public void handleEvent(Event event)
- {
- String reportTitle = (String) event.getProperty("title");
- String reportPath = (String) event.getProperty("path");
-
- sendReportByEmail(reportTitle, reportPath);
- }
-
- //..
-
-
-## Registering an Event Handler
-
-To receive event notifications, the event handler must be registered as a OSGi service under the object class `org.osgi.service.event.EventHandler`. When registering the service, a `String\[\]({{ refs..path }})` property named `*EVENT_TOPIC*` must be specified; this property describes the list of topics in which the event handler is interested. For example:
-
-
- String[] topics = new String[] {
- "com/acme/reportgenerator/GENERATED"
- };
-
- Dictionary props = new Hashtable();
- props.put(EventConstants.EVENT_TOPIC, topics);
- bundleContext.registerService(EventHandler.class.getName(), new ReportEventHandler() , props);
-
-
-It is possible to use '*' as a wildcard in the final character of the EVENT_TOPIC, like in this example:
-
-
-
- String[] topics = new String[] {
- "com/acme/reportgenerator/*"
- };
-
- Dictionary props = new Hashtable();
- props.put(EventConstants.EVENT_TOPIC, topics);
- bundleContext.registerService(EventHandler.class.getName(), new ReportEventHandler() , props);
-
-
-Finally, it is possible to specify an additional `EVENT_FILTER` property to filter event notifications; the filter expression follows, the normal LDAP syntax:
-
-
- String[] topics = new String[] {
- "com/acme/reportgenerator/GENERATED"
- };
-
- Dictionary props = new Hashtable();
- props.put(EventConstants.EVENT_TOPIC, topics);
- props.put(EventConstants.EVENT_FILTER, "(title=samplereport)");
- bundleContext.registerService(EventHandler.class.getName(), new ReportEventHandler() , props);
-
-
-## OSGi Events
-
-Every OSGi framework sends (asynchronously) a number of events that can be captured by any bundle.
-
-### Framework Events
-
-* org/osgi/framework/BundleEvent/STARTED
-* org/osgi/framework/BundleEvent/ERROR
-* org/osgi/framework/BundleEvent/PACKAGES_REFRESHED
-* org/osgi/framework/BundleEvent/STARTLEVEL_CHANGED
-* org/osgi/framework/BundleEvent/WARNING
-* org/osgi/framework/BundleEvent/INFO
-
-### Bundle Events
-
-* org/osgi/framework/BundleEvent/INSTALLED
-* org/osgi/framework/BundleEvent/STARTED
-* org/osgi/framework/BundleEvent/STOPPED
-* org/osgi/framework/BundleEvent/UPDATED
-* org/osgi/framework/BundleEvent/UNINSTALLED
-* org/osgi/framework/BundleEvent/RESOLVED
-* org/osgi/framework/BundleEvent/UNRESOLVED
-
-The followig properties are always present in a bundle event object:
-
-* *bundle.id*
-* *bundle.symbolicName*
-
-### Service Events
-
-* org/osgi/framework/ServiceEvent/REGISTERED
-* org/osgi/framework/ServiceEvent/MODIFIED
-* org/osgi/framework/ServiceEvent/UNREGISTERING
-
-The following properties are always present in a service event object:
-
-* *service*
-* *service.id*
-* *service.pid*
-
-Each of the aforementioned events actually contains a wider set of properties. Check the OSGi Compendium specification, section 113.6, for a complete list.
-
-## Configuration
-
-The Apache Felix Event Admin implementation is trying the deliver the events as fast as possible. Events sent from different threads are sent in parallel. Events from the same thread are sent in the order they are received (this is according to the spec).
-A timeout can be configured which is used for event handlers. If an event handler takes longer than the configured timeout to process an event, it is denied. Once a handler is in a denylist, it doesn't get sent any events anymore.
-The Felix Event Admin can be configured either through framework properties or through the configuration admin using PID `org.apache.felix.eventadmin.impl.EventAdmin`. This is a list of configuration properties:
-
-----
-**Thread Pool Size**
-
-*Property*: org.apache.felix.eventadmin.ThreadPoolSize
-*Default*: 20
-*Type*: Integer
-
-The size of the thread pool used for event delivery. The default value is 20. Increase in case of a large amount of events. A value of less then 2 triggers the default value. If the pool is exhausted, event delivery is blocked until a thread becomes available from the pool. Each event is delivered in a thread from the pool unless the ignore timeouts is configured for the receiving event handler.
-
-----
-
-**Async/sync Thread Pool Ratio**
-
-*Property*: org.apache.felix.eventadmin.AsyncToSyncThreadRatio
-*Since*: Release 1.4.2
-*Default*: 0.5
-*Type*: Double
-
-The ratio of asynchronous to synchronous threads in the internal thread pool. Ratio must be positive and may be adjusted to represent the distribution of post to send operations. Applications with higher number of post operations should have a higher ratio.
-
-----
-
-**Timeout**
-
-*Property*: org.apache.felix.eventadmin.Timeout
-*Default*: 5000
-*Type*: Integer
-
-The deny-listing timeout in milliseconds. The default value is 5000. Increase or decrease at own discretion. A value of less then 100 turns timeouts off. Any other value is the time in milliseconds granted to each event handler before it gets denied.
-
-----
-
-**Require Topic**
-
-*Property*: org.apache.felix.eventadmin.RequireTopic
-*Default*: true
-*Type*: Boolean
-
-Are event handlers required to be registered with a topic? This is enabled by default. The specification says that event handlers must register with a list of topics they are interested in. Disabling this setting will enable that handlers without a topic are receiving all events (i.e., they are treated the same as with a topic=*).
-
-----
-
-**Ignore Timeouts**
-
-*Property*: org.apache.felix.eventadmin.IgnoreTimeout
-*Default*: empty
-*Type*: String
-
-Configure event handlers to be called without a timeout. If a timeout is configured by default all event handlers are called using the timeout. For performance optimization it is possible to configure event handlers where the timeout handling is not used - this reduces the thread usage from the thread pools as the timout handling requires an additional thread to call the event handler. However, the application should work without this configuration property. It is a pure optimization! Th [...]
-
-----
-
-**Ignore Topics**
-
-*Property*: org.apache.felix.eventadmin.IgnoreTopic
-*Since*: Release 1.4.0
-*Default*: empty
-*Type*: String
-
-For performance optimization it is possible to configure topics which are ignored by the event admin implementation. In this case, a event is not delivered to registered event handlers. The value is a list of strings (separated by comma). " +If a single value ends with a dot, all topics in exactly this package are ignored. If a single value ends with a star, all topics in this package and all sub packages are ignored. If a single value neither ends with a dot nor with a start, this is as [...]
-
-----
-
-**Log Level**
-
-*Property*: org.apache.felix.eventadmin.LogLevel
-*Note*: This property can't be set through the OSGi configuration.
-*Default*: 2 (=WARNING)
-*Type*: Integer
-
-This sets the log level used for messages outputted by the event admin implementation. Valid values are 1 (=ERROR), 2 (=WARNING), 3 (=INFO), and 4 (=DEBUG). The default is 2 and an invalid value sets the level to the default value.
-
-----
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-file-install.mdtext b/modules/ROOT/pages/documentation/subprojects/apache-felix-file-install.mdtext
deleted file mode 100644
index 514f0c7..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-file-install.mdtext
+++ /dev/null
@@ -1,104 +0,0 @@
-Title: Apache Felix File Install
-
-File Install is a directory based OSGi management agent. It uses a directory in the file system to install and start a bundle when it is first placed there. It updates the bundle when you update the bundle file in the directory and, when the file is deleted, it will stop and uninstall the bundle.
-
-File Install can do the same for configuration configuration files. This surprisingly simple bundle is very powerful because there are so many programs that work with the file system. For example:
-
-* If you use Ant, you can just copy the resulting bundle to the watched directory.
-* You can download bundles from the web and directly install them without any extra effort.
-* You can easily drag and drop bundles in and out of the framework.
-
-## Setup
-
-The bundle runs on any framework. For its configuration, it will use the following system properties:
-
-|Property|Default|Description|
-|--|--|--|
-|`felix.fileinstall.poll`|2000 ms|Number of milliseconds between 2 polls of the directory|
-|`felix.fileinstall.dir`|./load|The name of the directory to watch. Several directories can be specified by using a comma separated list.|
-|`felix.fileinstall.log.level`|1|Threshold of logging information|
-|`felix.fileinstall.log.default`|stdout|Possible values are `stdout`, `jul`. Defines where to log when the OSGi LogService is not available.|
-|`felix.fileinstall.bundles.new.start`|true|Automatically start newly discovered bundles|
-|`felix.fileinstall.filter`| |A regular expression to be used to filter file names|
-|`felix.fileinstall.tmpdir`| |The name of the temporary directory to use with exploded or transformed bundles (defaults to the temporary dir for the JVM)|
-|`felix.fileinstall.noInitialDelay`|false|Determines if File Install waits `felix.fileinstall.poll` milliseconds before doing an initial scan or not.|
-|`felix.fileinstall.bundles.startTransient`|false|If `true`, File Install will start the bundles transiently.|
-|`felix.fileinstall.bundles.startActivationPolicy`|true|Start bundles with their default activation policy or not|
-|`felix.fileinstall.start.level`|0|If set to a value different from `0`, File Install will set the start level for deployed bundles to that value. If set to `0`, the default framework bundle start level will be used.|
-|`felix.fileinstall.active.level`|0|FileInstall won't scan for files unless the active framework start level is greater than this value|
-|`felix.fileinstall.enableConfigSave`|true|If `false`, File Install will not write back in the file configurations changes. Note that this setting is global and can not be modified per polled directory.|
-|`felix.fileinstall.configEncoding`|ISO-8859-1|The encoding used to read and write configuration files.|
-|`felix.fileinstall.bundles.updateWithListeners`|false|If `true`, FileInstall will update managed bundles when a new version of an artifact handler is detected. This detection is performed based on the last modification date of the bundle registering the handler.|
-|`felix.fileinstall.optionalImportRefreshScope`|all|Possible values are `none`, `managed`, `all`. Defines which bundles can be elected for refresh.|
-|`felix.fileinstall.fragmentRefreshScope`|all|Possible values are `none`, `managed`, `all`. Defines which bundles can be elected for refresh.|
-|`felix.fileinstall.disableNio2`|false|If `true`, File Install will not use NIO2 to scan directory and files.|
-|`felix.fileinstall.subdir.mode`|jar|Possible values are `jar`, `skip`, `recurse`. Defines the behavior for sub directories.|
-
-
-Once started, the values of these properties are printed to the console.
-
-## Configurations
-
-Configuration files are plain property files (`java.util.Property`). The format is simple:
-
-
- file ::= ( header | comment ) *
- header ::= <header> ( ':' | '=' ) <value> ( '\<nl> <value> ) *
- comment ::= '#' <any>
-
-
-Notice that this model only supports string properties. For example:
-
-
- # default port
- ftp.port = 21
-
-
-Configuration file names are related to the PID and factory PID. The structure of the file name is as follows:
-
-
- filename ::= <pid> ( '-' <subname> )? '.cfg'
-
-
-If the form is `<pid>.cfg`, the file contains the properties for a Managed Service. The `<pid>` is then the PID of the Managed Service. See the Configuration Admin service for details.
-
-When a Managed Service Factory is used, the situation is different. The `<pid>` part then describes the PID of the Managed Service Factory. You can pick any `<subname>`, this bundle will then create an instance for the factory for each unique name. For example:
-
-
- com.acme.xyz.cfg // configuration for Managed Service
- // com.acme.xyz
- com.acme.abc-default.cfg // Managed Service Factory,
- // creates an instance for com.acme.abc
-
-
-If a configuration managed by File Install is modified, File Install will write the configuration back to a property file to ensure peristence across restarts.
-
-## Property substitution in configuration files
-
-It is possible to use system properties to specify the values of properties in configuration files. This is achieved through system property substitution, which is instigated by using `$\{<property>\`} syntax, where <property> is the name of a system property to substitute. Bundle context properties will take precedence over system properties if available.
-Example:
-
-
- ftp.port = ${system.ftp.port}
-
-
-## Watching multiple directories with File Install
-
-Starting with version 3.1.0 it is possible to specify several directories to watch with the system property `felix.fileinstall.dir`; this property can either point to a single directory or a comma separated list of directories. In addition, Apache Felix File Install provides a ManagedServiceFactory to create multiple instances of File Install. Asuming you have a File Install bundle watching a `bundles` folder, creating a new instance is as simple as creating a new configuration file `org [...]
-
- felix.fileinstall.poll=2000
- felix.fileinstall.dir=/configDir
- felix.fileinstall.debug=-1
- felix.fileinstall.filter=.*\\.cfg
- felix.fileinstall.bundles.new.start=false
-
-
-## Exploded bundles
-
-Apache Felix File Install has the ability to watch for exploded bundles and automatically update such bundles if the content is changed in any way. If a watched directory contains a sub directory, its content will be jar'ed and deployed to the OSGi framework. Any change to a file in this directory or one of its subdirectories will result in the directory to be jar'ed again and the corresponding bundle to be updated.
-
-## Custom artifacts
-
-Apache Felix File Install can support deployment of custom artifacts. By default, configurations and plain OSGi bundles are supported, but other kind of artifacts can be deployed through custom artifact handlers.
-
-To add support for a custom artifact, a service implementing one of `org.apache.felix.fileinstall.ArtifactListener`'s sub interfaces must be registered in the OSGi registry.
\ No newline at end of file
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-framework-security.mdtext b/modules/ROOT/pages/documentation/subprojects/apache-felix-framework-security.mdtext
deleted file mode 100644
index f384b1d..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-framework-security.mdtext
+++ /dev/null
@@ -1,50 +0,0 @@
-Title: Apache Felix Framework Security
-
-The Felix Framework Security subproject is an implementation of the security part of the OSGi R4.2 core specification.
-
-# Installing
-
-Support for the OSGi R4.2 security specifications including `PermissionAdmin` and `ConditionalPermissionAdmin` is provided by the framework.security extension bundle. The bundle provides both, the packages as well as the services when it is installed.
-
-All that needs to be done is to install the `org.apache.felix.framework.security` bundle into the framework.
-
-# Using security
-
-Besides installing the security bundle three properties should be specified:
-
- - `org.osgi.framework.security="osgi"`
- - `java.security.policy=all.policy`
- - `org.osgi.framework.trust.repositories=<list of keystores>`
-
-The first installs a security manager on framework init (which in combination with the installed security bundle enables security).
-
-The second points to a security policy file (`all.policy`) that gives all permission like so:
-
- grant {
- permission java.security.AllPermission;
- };
-
-
-The third allows to specify a `File.pathSeparator` separated list of JKS keystores without a password. The certificates found inside the keystores are the trusted root certificates of the framework (setting this property is optional).
-
- $ java -Djava.security.policy=all.policy -Dorg.osgi.framework.security="osgi" -jar bin/felix.jar
-
- Welcome to Felix
- ================
-
- -> install file:org.apache.felix.framework.security.jar
- -> inspect s c 0
- System Bundle (0) provides services:
- ------------------------------------
- objectClass = org.osgi.service.startlevel.StartLevel
- service.id = 1
- ----
- objectClass = org.osgi.service.packageadmin.PackageAdmin
- service.id = 2
- ----
- objectClass = org.osgi.service.permissionadmin.PermissionAdmin
- service.id = 3
- ----
- objectClass = org.osgi.service.condpermadmin.ConditionalPermissionAdmin
- service.id = 4
-
\ No newline at end of file
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-framework.mdtext b/modules/ROOT/pages/documentation/subprojects/apache-felix-framework.mdtext
deleted file mode 100644
index a7d586f..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-framework.mdtext
+++ /dev/null
@@ -1,8 +0,0 @@
-Title: Apache Felix Framework
-
-The Felix Framework subproject is an implementation of the OSGi R6 core framework specification.
-
-## Framework documentation
-
-{% for label, page in children %}* [{{ page.headers.title }}]({{ page.path }})
-{% endfor %}
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-framework/apache-felix-framework-bundle-cache.mdtext b/modules/ROOT/pages/documentation/subprojects/apache-felix-framework/apache-felix-framework-bundle-cache.mdtext
deleted file mode 100644
index 14ec36a..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-framework/apache-felix-framework-bundle-cache.mdtext
+++ /dev/null
@@ -1,66 +0,0 @@
-Title: Apache Felix Framework Bundle Cache
-
-* [Introduction]({{ refs.-introduction.path }})
-* [Default Behavior]({{ refs.-default-behavior.path }})
-* [Configuring Default Behavior]({{ refs.-configuring-behavior.path }})
-
-
-
-# Introduction
-
-The OSGi specification states that the framework must cache bundles and their run-time state, but it does not explicitly define how this should be done. As a result, each OSGi framework implementation is likely to cache bundles differently. This document describes in detail how the Felix framework handles bundle caching by default and also describes the mechanisms to modify this default behavior.
-
-
-
-# Default Behavior
-
-Since the OSGi R4.2 specification, the standard framework launching and embedding API requires that frameworks should use "reasonable defaults" for all configuration properties so it is possible to start a framework without any configuration. One such default value is the location of the framework bundle cache. When the Felix framework is start, it creates a bundle cache directory, called `felix-cache`, in the current working directory by default. All bundle information is saved inside t [...]
-
-The structure of a bundle cache directory is reasonably simple; it contains a directory for each bundle, where the directory name corresponds to the bundle identifier number. Each bundle directory contains a file for the bundle's location, identifier, start level, state, and a directory containing the bundle JAR file and any extracted embedded JAR files or native libraries if any exist. As an example, the bundle cache directory for a bundle containing an embedded JAR file and a native li [...]
-
-
- ${user.dir}
- felix-cache/
- bundle4/
- bundle.id
- bundle.lastmodified
- bundle.location
- bundle.startlevel
- bundle.state
- data/
- version0.0/
- revision.location
- bundle.jar
- bundle.jar-embedded/
- embedded.jar
- bundle.jar-lib/
- 0/
- libnative.so
-
-
-The above directory structure indicates that the imaginary bundle is cached in the `felix-cache` in the current working directory and "4" is its bundle identifier. Additionally, besides the bundle JAR file, the bundle has one embedded JAR file and one native library. The naming convention is rather straightforward and consistent, although the directory structure may seem rather indirect. The precise details behind the rationale for the directory structure around embedded JAR files and na [...]
-
-All cached bundle directories will follow the basic pattern displayed above, except for the names of the embedded JAR files and native libraries. Embedded JAR files and native libraries use the names specified in the bundle manifest and may also include sub-directories to avoid name clashes. The naming convention for the directory containing the bundle JAR file, `version0.0`, requires further explanation.
-
-The bundle JAR directory uses a numbering scheme to keep track of the number of times a bundle is updated and the number of times it is refreshed; the name of the directory maps like this: `version<refresh-count>.<revision-count>`. The reasoning behind this is tricky. It is necessary to keep track of the revision count because the OSGi specification requires when a bundle is updated that the update takes effect immediately. However, it also requires that old packages from older revisions [...]
-
-For example, if a bundle provides package `foo` and it is updated and now provides packages `foo` and `bar`, then after the update `foo` will be supplied from the older revision and `bar` will be supplied from the newer revision. This is possible for any number of updates, thus the bundle JAR directory must keep each revision around until a refresh is performed. Such "revision directories" are generally only run-time directories and are removed when the framework is shutdown or refreshed [...]
-
-To illustrate, upon initial installation, the bundle JAR file is placed into a revision directory named `revision0.0`. When an update is performed, the updated bundle JAR file is placed in a directory named `revision0.1`. If another update is performed without a refresh of the framework, the newer revision will be placed into a directory named `revision0.2` and so on. When the framework is refreshed or shutdown, all revision directories are purged from the bundle cache and only the most [...]
-
-Simply purging the old revision directories may appear adequate for refreshing the framework, but it is not due to how the JVM handles native libraries. When a native library is loaded it is associated with a specific class loader; no other class loader can load the same native library. The uniqueness of a native library is determined by its absolute path in the file system. Consequently, when the framework is refreshed, it is necessary to recreate the class loaders for all refreshed bun [...]
-
-After purging all old revision directories, the current revision directory is renamed based on the current refresh count. By renaming the directory, it is possible to re-load the native library since its path in the file system has changed. The old class loaders and native libraries will eventually be garbage collected. The current refresh count is stored in a file, called `refresh.counter`, in the bundle's directory. To illustrate, if a bundle was updated and has two revision directorie [...]
-
-
-
-# Configuring Default Behavior
-
-It is possible to modify the default behavior of Felix' bundle cache by setting certain configuration properties; see the [usage document]({{ refs.apache-felix-framework-usage-documentation-configuring-framework.path }}) for information on how to set configuration properties for Felix. Felix' bundle cache recognizes the following configuration properties:
-
-* `org.osgi.framework.storage` \- Sets the directory to use as the bundle cache; by default bundle cache directory is `felix-cache` in the current working directory. The value should be a valid directory name. The directory name can be either absolute or relative. Relative directory names are relative to the current working directory. The specified directory will be created if it does not exist.
-* `org.osgi.framework.storage.clean` \- Determines whether the bundle cache is flushed. The value can either be "`none`" or "`onFirstInit`", where "`none`" does not flush the bundle cache and "`onFirstInit`" flushes the bundle cache when the framework instance is first initialized. The default value is "`none`".
-* `felix.cache.rootdir` \- Sets the root directory to use to calculate the bundle cache directory for relative directory names. If `org.osgi.framework.storage` is set to a relative name, by default it is relative to the current working directory. If this property is set, then it will be calculated as being relative to the specified root directory.
-* `felix.cache.bufsize` \- Sets the buffer size to be used by the cache; the default value is 4096. The integer value of this string provides control over the size of the internal buffer of the disk cache for performance reasons.
-
-To be clear, if a relative bundle cache directory is specified then the absolute location of the bundle cache directory is computed like this: `$\{felix.cache.rootdir}+$\{org.osgi.framework.storage`}, where `felix.cache.rootdir` has the default value of the current working directory. If `$\{org.osgi.framework.storage`} is specified as absolute, then it is used as the location of the bundle cache. If the bundle cache directory does not exist, it is created.
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-framework/apache-felix-framework-configuration-properties.mdtext b/modules/ROOT/pages/documentation/subprojects/apache-felix-framework/apache-felix-framework-configuration-properties.mdtext
deleted file mode 100644
index 21b7fe7..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-framework/apache-felix-framework-configuration-properties.mdtext
+++ /dev/null
@@ -1,82 +0,0 @@
-Title: Apache Felix Framework Configuration Properties
-
-* [Overview]({{ refs.-overview.path }})
-* [Framework configuration properties]({{ refs.-framework.path }})
-* [Launcher configuration properties]({{ refs.-launcher.path }})
-* [Mirgrating from earlier versions]({{ refs.-migrating.path }})
-* [Feedback]({{ refs.-feedback.path }})
-
-
-
-## Overview
-
-This document describes the various configuration properties related to the Apache Felix Framework. Technically, there are framework properties and launcher properties. If you are using the Felix Framework JAR file (i.e., `org.apache.felix.framework-x.y.x.jar`), then you can only use framework properties. On the other hand, if you are using the Felix Main launcher JAR (i.e., `felix.jar` or `org.apache.felix.main-x.y.z.jar`), then you can use both framework and launcher properties. This d [...]
-
-Note that the framework does not use system properties to find its configuration properties, it only consults the map passed into its constructor. In contrast to bundles, which use `BundleContext.getProperty()`, which exposes both configuration and system properties at execution time. In the case of overlap, the configuration properties override system properties. As a convenience, if you are using the Felix launcher, it will copy all configuration properties it finds in the system prope [...]
-
-
-
-## Framework configuration properties
-
-The following configuration properties are for the framework (properties starting with "`felix`" are specific to Felix, while those starting with "`org.osgi`" are standard OSGi properties):
-
-* `org.osgi.framework.executionenvironment` \- Sets the OSGi execution environment for the framework. The framework tries to set this to a reasonable default value. If you specify a value, it overrides the framework default. Refer to the OSGi specification for appropriate execution environment values.
-* `org.osgi.framework.storage` \- Sets the directory to use as the bundle cache; by default the bundle cache directory is `felix-cache` in the current working directory. The value should be a valid directory name. The directory name can be either absolute or relative. Relative directory names are relative to the current working directory. The specified directory will be created if it does not exist.
-* `felix.cache.rootdir` \- Sets the root directory used to calculate the bundle cache directory for relative directory names. If `org.osgi.framework.storage` is set to a relative name, by default it is relative to the current working directory. If this property is set, then it will be calculated as being relative to the specified root directory.
-* `org.osgi.framework.storage.clean` \- Determines whether the bundle cache is flushed. The value can either be "`none`" or "`onFirstInit`", where "`none`" does not flush the bundle cache and "`onFirstInit`" flushes the bundle cache when the framework instance is first initialized. The default value is "`none`".
-* `felix.cache.filelimit` \- The integer value of this string sets an upper limit on how many files the cache will open. The default value is zero, which means there is no limit. (Since 4.0)
-* `felix.cache.locking` \- Enables or disables bundle cache locking, which is used to prevent concurrent access to the bundle cache. This is enabled by default, but on older/smaller JVMs file channel locking is not available; set this property to `false` to disable it.
-* `felix.cache.bufsize` \- Sets the buffer size to be used by the cache; the default value is 4096. The integer value of this string provides control over the size of the internal buffer of the disk cache for performance reasons.
-* `org.osgi.framework.system.packages` \- Specifies a comma-delimited list of packages that should be exported via the System Bundle from the framework class loader. The framework will set this to a reasonable default. If the value is specified, it replaces any default value.
-* `org.osgi.framework.system.packages.extra` \- Specifies a comma-delimited list of packages that should be exported via the System Bundle from the framework class loader in addition to the packages in `org.osgi.framework.system.packages`. The default value is empty. If a value is specified, it is appended to the list of default or specified packages in `org.osgi.framework.system.packages`.
-* `org.osgi.framework.bootdelegation` \- Specifies a comma-delimited list of packages that should be made implicitly available to all bundles from the parent class loader. It is recommended not to use this property since it breaks modularity. The default value is empty.
-* `org.osgi.framework.bundle.parent` \- Specifies which class loader is used for boot delegation. Possible values are: `boot` for the boot class loader, `app` for the application class loader, `ext` for the extension class loader, and `framework` for the framework's class loader. The default is `boot`.
-* `felix.bootdelegation.implicit` \- Specifies whether the framework should try to guess when to implicitly boot delegate to ease integration with external code. The default value is `true`.
-* `felix.systembundle.activators` \- A `List` of `BundleActivator` instances that are started/stopped when the System Bundle is started/stopped. The specified instances will receive the System Bundle's `BundleContext` when invoked. (This property cannot be set in the configuration file since it requires instances; it can only be passed into Felix' constructor directly.)
-* `felix.log.logger` \- An instance of `org.apache.felix.framework.Logger` that the framework uses as its default logger. (This property cannot be set in the configuration file since it requires an instance; it can only be passed into Felix' constructor directly.)
-* `felix.log.level` \- An integer value indicating the degree of logging reported by the framework; the higher the value the more logging is reported. If zero ('0') is specified, then logging is turned off completely. The log levels match those specified in the OSGi Log Service (i.e., 1 = error, 2 = warning, 3 = information, and 4 = debug). The default value is 1.
-* `org.osgi.framework.startlevel.beginning` \- The initial start level of the framework once it starts execution; the default value is 1.
-* `felix.startlevel.bundle` \- The default start level for newly installed bundles; the default value is 1.
-* `felix.service.urlhandlers` \- Flag to indicate whether to activate the URL Handlers service for the framework instance; the default value is `true`. Activating the URL Handlers service will result in the `URL.setURLStreamHandlerFactory()` and `URLConnection.setContentHandlerFactory()` being called.
-* `felix.native.processor.alias.<procName>` \- An alias for resolving native processor requirements new with R6. This can be used to add new or override existing processors. The <procName> represents the key for the processor architecture such as x86-64 (which may not contain spaces) then the property value is a comma delimited list of aliases such as x86\_64,amd64. EX felix.native.processor.alias.x86-64=x86\_64,amd64
-* `felix.native.osname.alias.<osName>` \- An alias for resolving native operating system requirements new with R6. This can be used to add new or override existing operating systems. The <osName> represents the key for the operating system such as windows7 (which may not contain spaces) then the property value is a comma delimited list of aliases such as Windows 7,win32. EX felix.native.osname.alias.windows7=Windows 7,win32
-
-
-
-## Launcher configuration properties
-
-The following configuration properties are for the launcher:
-
-* `felix.auto.deploy.dir` \- Specifies the auto-deploy directory from which bundles are automatically deployed at framework startup. The default is the `bundle/` directory of the current directory.
-* `felix.auto.deploy.action` \- Specifies a comma-delimited list of actions to be performed on bundle JAR files found in the auto-deploy directory. The possible actions are `install`, `update`, `start`, and `uninstall`. An undefined or blank value is equivalent to disabling auto-deploy processing; there is no default value, so this value must be defined to enable it.
-* `felix.auto.install.<n>` \- Space-delimited list of bundle URLs to automatically install when Felix is started, where `<n>` is the start level into which the bundle will be installed (e.g., `felix.auto.install.2`).
-* `felix.auto.start.<n>` \- Space-delimited list of bundle URLs to automatically install and start when Felix is started, where `<n>` is the start level into which the bundle will be installed (e.g., `felix.auto.start.2`).
-* `felix.shutdown.hook` \- Specifies whether the launcher should install a shutdown hook to cleanly shutdown the framework on process exit. The default value is `true`.
-
-
-
-## Migrating from Earlier Versions
-
-Apache Felix Framework `2.0.0` introduced significant configuration property changes. This section describes the differences from older versions of the framework.
-
-* *Removed*
-** `felix.embedded.execution` \- No longer needed, since the framework now never calls `System.exit()`; the creator of the framework is now always responsible for exiting the VM.
-** `felix.strict.osgi` \- No longer needed, since all non-specification features have been removed.
-** `felix.cache.dir` \- No longer needed, since Felix no longer uses bundle cache profiles for saving sets of bundles.
-** `felix.cache.profile` \- No longer needed, since the framework no longer uses bundle cache profiles for saving sets of bundles.
-** `felix.fragment.validation` \- No longer needed, since the framework supports fragments.
-* *Renamed*
-** `felix.cache.profiledir` \- The equivalent of this property is now named `org.osgi.framework.storage`.
-** `felix.startlevel.framework` \- The equivalent of this property is now named `org.osgi.framework.startlevel.beginning`.
-* *Introduced*
-** `org.osgi.framework.system.packages.extra` \- New property, as described above, added to align with standard framework API.
-** `org.osgi.framework.storage.clean` \- New property, as described above, added to align with standard framework API.
-** `felix.cache.rootdir` \- Introduced as a result of removing bundle profiles to help resolve relative bundle cache directories.
-
-For the most part, these changes are minor and previous behavior achieved from older configuration properties is either easily attained with the new properties or no longer necessary.
-
-
-
-## Feedback
-
-Subscribe to the Felix users mailing list by sending a message to [users-subscribe@felix.apache.org]({{ refs.mailto-users-subscribe-felix-apache-org.path }}); after subscribing, email questions or feedback to [users@felix.apache.org|mailto:users@felix.apache.org].
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-framework/apache-felix-framework-faq.mdtext b/modules/ROOT/pages/documentation/subprojects/apache-felix-framework/apache-felix-framework-faq.mdtext
deleted file mode 100644
index 20be5cb..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-framework/apache-felix-framework-faq.mdtext
+++ /dev/null
@@ -1,60 +0,0 @@
-Title: Apache Felix Framework Frequently Asked Questions
-
-[TOC]
-
-## Is the Felix framework compliant with the OSGi specification?
-
-Refer to the [Apache Felix Framework OSGi R4.2 CT Results]({{ refs.apache-felix-framework-osgi-r4-2-ct-results.path }}) document.
-
-## If I use bundles from Felix, will my application be tied to the Felix framework?
-
-See the answer in the [OSGi FAQ]({{ refs.apache-felix-osgi-faq-felix-dependencies.path }}).
-
-## When I update my bundle, why are my bundle's old classes still being used?
-
-See the answer in the [OSGi FAQ]({{ refs.apache-felix-osgi-faq-bundle-not-updated.path }}).
-
-## Why do I get an "Unknown protocol: http" exception when I run Felix on a non-Sun JRE?
-
-Felix installs the URL Handlers service by default. If you do not want this service you can disable it, by setting the `felix.service.urlhandlers` property to `false` in the `config.properties` file. It is not recommended to disable this, but the main reason for doing so it because the URL Handlers implementation invokes methods to set the singleton factories for URL stream and content handler factories. Assuming that you want to use URL Handlers service, you must configure it if you are [...]
-
-The URL Handlers service extends the standard Java URL stream and content handler mechanism to work in an OSGi environment. The way that built-in URL protocol and content handlers are discovered is by probing packages for the appropriate classes to handle the protocol/content. For example, the default package for Sun protocol handlers is:
-
-
- sun.net.www.protocol
-
-
-If someone tries to create a URL for the "http" protocol, then the class to handle the protocol will be:
-
-
- sun.net.www.protocol.http.Handler
-
-
-A similar process is followed for content handlers, whose default package is:
-
-
- sun.net.www.content
-
-
-If you are running on a VM that is different than Sun's, then you must determine what are the default packages used for its protocol and content handlers. Once you know this information, then you can configure Felix to use those packages instead of the default one. You can configure Felix by setting the following system properties:
-
-
- java.protocol.handler.pkgs
-
-
-and
-
-
- java.content.handler.pkgs
-
-
-The value of these properties is a list of "|" delimited package names to be searched for protocol and content handlers, respectively. See the Java documentation for [stream](http://java.sun.com/javase/6/docs/api/java/net/URL.html#URL(java.lang.String,%20java.lang.String,%20int,%20java.lang.String)) and [content|http://java.sun.com/javase/6/docs/api/java/net/URLConnection.html#getContent()] handlers for more information.
-
-There are two ways to set these system properties. The first way is using the standard `-D<property>=<value>` syntax when executing `java` or if you are using Felix' standard `Main.java` launcher, you can put the system properties into the `conf/system.properties` file so that they get set automatically each time you execute Felix.
-
-## What is the daemon status of framework created threads?
-
-The framework creates a few threads for handling specific tasks, such as event delivery or handling start level change requests. All framework threads are explicitly started as daemon threads except the event dispatcher thread. The logic behind this is that the event dispatcher thread should exit when it is done delivering events. However, if an application is hosting an instance of the framework, it is possible to make the event dispatcher thread a daemon by starting your framework inst [...]
-
-For bundle developers, it is probably best to explicitly define any created threads as daemon or non-daemon to avoid any ambiguity.
-
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-framework/apache-felix-framework-launching-and-embedding.mdtext b/modules/ROOT/pages/documentation/subprojects/apache-felix-framework/apache-felix-framework-launching-and-embedding.mdtext
deleted file mode 100644
index ea7c567..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-framework/apache-felix-framework-launching-and-embedding.mdtext
+++ /dev/null
@@ -1,784 +0,0 @@
-Title: Apache Felix Framework Launching and Embedding
-
-*\[This document describes framework launching introduced in Felix Framework 2.0.0 and continuing with the latest releases; it is incompatible with older versions of the Felix framework.\]({{ refs.this-document-describes-framework-launching-introduced-in-felix-framework-2-0-0-and-continuing-with-the-latest-releases-it-is-incompatible-with-older-versions-of-the-felix-framework.path }})*
-
-* [Introduction]({{ refs.-introduction.path }})
-* [OSGi Launching and Embedding API Overview]({{ refs.-overview.path }})
-** [Creating and Configuring the Framework Instance]({{ refs.-creating-and-configuring.path }})
-** [Starting the Framework Instance]({{ refs.-starting-instance.path }})
-** [Stopping the Framework Instance]({{ refs.-stopping-instance.path }})
-* [Launching Felix]({{ refs.-launching.path }})
-** [Standard Felix Launcher]({{ refs.-standard-launcher.path }})
-** [Custom Felix Launcher]({{ refs.-custom-launcher.path }})
-* [Embedding Felix]({{ refs.-embedding.path }})
-** [Host/Felix Interaction]({{ refs.-host-interaction.path }})
-** [Providing Host Application Services]({{ refs.-host-services.path }})
-** [Using Services Provided by Bundles]({{ refs.-host-service-usage.path }})
-*** [Using Bundle Services via Reflection]({{ refs.-service-reflection.path }})
-*** [Other Approaches]({{ refs.-service-other.path }})
-* [Caveat]({{ refs.-caveat.path }})
-* [Feedback]({{ refs.-feedback.path }})
-
-
-
-# Introduction
-
-The Apache Felix Framework is intended to be easily launchable and embeddable. For example, the Felix framework implementation avoids the use of system properties for configuration, since these are globals and can cause interference if multiple framework instances are created in the same VM. The framework also tries to multiplex singleton facilities, like the URL stream handler factory. The goal is to make it possible to use the framework in a variety of scenarios; however, this is still [...]
-
-
-
-# OSGi Launching and Embedding API Overview
-
-The Felix framework is implemented by the `org.apache.felix.framework.Felix` class or just `Felix` for short. As part of the R4.2 OSGi specification, the launching and embedding API of the OSGi framework has been standardized. The approach is to have the framework implement the `org.osgi.framework.launch.Framework` interface, which extends the `org.osgi.framework.Bundle` interface. These interfaces provide the necessary means to launch and manage framework instances. The `Bundle` interfa [...]
-
-
- public interface Bundle
- {
- BundleContext getBundleContext();
- long getBundleId();
- URL getEntry(String name);
- Enumeration getEntryPaths(String path);
- Enumeration findEntries(String path, String filePattern, boolean recurse);
- Dictionary getHeaders();
- Dictionary getHeaders(String locale);
- long getLastModified();
- String getLocation();
- URL getResource(String name);
- Enumeration getResources(String name) throws IOException;
- ServiceReference[] getRegisteredServices();
- ServiceReference[] getServicesInUse();
- int getState();
- String getSymbolicName();
- Version getVersion();
- boolean hasPermission(Object obj);
- Class loadClass(String name) throws ClassNotFoundException;
- void start() throws BundleException;
- void stop() throws BundleException;
- void uninstall() throws BundleException;
- void update() throws BundleException;
- void update(InputStream is) throws BundleException;
- }
-
-
-The `Framework` interface is defined as:
-
-
- public interface Framework extends Bundle
- {
- void init();
- FrameworkEvent waitForStop(long timeout);
- }
-
-
-To actually construct a framework instance, the R4.2 specification defines the `FrameworkFactory` interface:
-
-
- public interface FrameworkFactory
- {
- Framework newFramework(Map config);
- }
-
-
-The framework factory can be used to create configured framework instances. It is obtained following the standard `META-INF/services` approach.
-
-
-
-## Creating and Configuring the Framework Instance
-
-You use the framework factory to construct and configure a framework instance (or by directly instantiating the Felix class). The configuration map may contain any of the framework configuration properties listed in the [Apache Felix Framework Configuration Properties]({{ refs.apache-felix-framework-configuration-properties.path }}) document, not the launcher configuration properties. The configuration map is copied and the keys are treated as case insensitive. You are not able to change [...]
-
-<div class="warning" markdown="1">
-**WARNING**
-Felix configuration properties have change considerably starting from `1.4.0`; if you are upgrading from an earlier version, the [configuration property document]({{ refs.apache-felix-framework-configuration-properties-migrating.path }}) describes the configuration property changes.
-</div>
-
-
-
-## Starting the Framework Instance
-
-The `start()` method is used to start the framework instance. If the `init()` method was not invoked prior to calling `start()`, then it is invoked by `start()`. The two methods result in two different framework state transitions:
-
-* `init()` results in the framework instance in the `Bundle.STARTING` state.
-* `start()` results in the framework instance in the `Bundle.ACTIVE` state.
-
-The `init()` method is necessary since the framework does not have a `BundleContext` when it is first created, so a transition to the `Bundle.STARTING` state is required to acquire its context (via `Bundle.getBundleContext()`) for performing various tasks, such as installing bundles. Note that the Felix framework also provides the `felix.systembundle.activators` property that serves a similar purpose, but is not standard. After the `init()` method completes, the follow actions have been [...]
-
-* Event handling is enabled.
-* The security manager is installed if it is enabled.
-* The framework is set to start level 0.
-* All bundles in the bundle caches are reified and their state is set to `Bundle.INSTALLED`.
-* The framework gets a valid `BundleContext`.
-* All framework-provided services are made available (e.g., PackageAdmin, StartLevel, etc.).
-* The framework enters the `Bundle.STARTING` state.
-
-A call to `start()` is necessary to start the framework instance, if the `init()` method is invoked manually. Invoking `init()` or `start()` on an already started framework as no effect.
-
-
-
-## Stopping the Framework Instance
-
-To stop the framework instance, invoke the `stop()` method, which will asynchronously stop the framework. To know when the framework has finished its shutdown sequence, use the `waitForStop()` method to wait until it is complete. A stopped framework will be in the `Bundle.RESOLVED` state. It is possible to restart the framework, using the normal combination of `init()`/`start()` methods as previously described.
-
-
-
-# Launching a Framework
-
-Launching a framework is fairly simple and involves only four steps:
-
-1. Define some configuration properties.
-1. Obtain framework factory.
-1. Use factory to create framework with the configuration properties.
-1. Invoke the `Framework.start()` method.
-
-In reality, the first step is optional, since all properties will have reasonable defaults, but if you are creating a launcher you will generally want to more than that, such as automatically installing and starting bundles when you start the framework instance. The default Felix launcher defines reusable functionality to automatically install and/or start bundles upon framework startup; see the [usage document]({{ refs.apache-felix-framework-usage-documentation-configuring-felix.path }} [...]
-
-The remainder of this section describes how the standard Felix launcher works as well as how to create a custom launcher.
-
-
-
-## Standard Felix Framework Launcher
-
-The standard Felix framework launcher is very simple and is not intended to solve every possible requirement; it is intended to work for most standard situations. Most special launching requirements should be resolved by creating a custom launcher. This section describes how the standard launcher works. The following code represents the complete `main()` method of the standard launcher, each numbered comment will be described in more detail below:
-
-
- public static void main(String[] args) throws Exception
- {
- // (1) Check for command line arguments and verify usage.
- String bundleDir = null;
- String cacheDir = null;
- boolean expectBundleDir = false;
- for (int i = 0; i < args.length; i++)
- {
- if (args[i].equals(BUNDLE_DIR_SWITCH))
- {
- expectBundleDir = true;
- }
- else if (expectBundleDir)
- {
- bundleDir = args[i];
- expectBundleDir = false;
- }
- else
- {
- cacheDir = args[i];
- }
- }
-
- if ((args.length > 3) || (expectBundleDir && bundleDir == null))
- {
- System.out.println("Usage: [-b <bundle-deploy-dir>] [<bundle-cache-dir>]");
- System.exit(0);
- }
-
- // (2) Load system properties.
- Main.loadSystemProperties();
-
- // (3) Read configuration properties.
- Properties configProps = Main.loadConfigProperties();
- if (configProps == null)
- {
- System.err.println("No " + CONFIG_PROPERTIES_FILE_VALUE + " found.");
- configProps = new Properties();
- }
-
- // (4) Copy framework properties from the system properties.
- Main.copySystemProperties(configProps);
-
- // (5) Use the specified auto-deploy directory over default.
- if (bundleDir != null)
- {
- configProps.setProperty(AutoProcessor.AUTO_DEPLOY_DIR_PROPERY, bundleDir);
- }
-
- // (6) Use the specified bundle cache directory over default.
- if (cacheDir != null)
- {
- configProps.setProperty(Constants.FRAMEWORK_STORAGE, cacheDir);
- }
-
- // (7) Add a shutdown hook to clean stop the framework.
- String enableHook = configProps.getProperty(SHUTDOWN_HOOK_PROP);
- if ((enableHook == null) || !enableHook.equalsIgnoreCase("false"))
- {
- Runtime.getRuntime().addShutdownHook(new Thread("Felix Shutdown Hook") {
- public void run()
- {
- try
- {
- if (m_fwk != null)
- {
- m_fwk.stop();
- m_fwk.waitForStop(0);
- }
- }
- catch (Exception ex)
- {
- System.err.println("Error stopping framework: " + ex);
- }
- }
- });
- }
-
- try
- {
- // (8) Create an instance and initialize the framework.
- FrameworkFactory factory = getFrameworkFactory();
- m_fwk = factory.newFramework(configProps);
- m_fwk.init();
- // (9) Use the system bundle context to process the auto-deploy
- // and auto-install/auto-start properties.
- AutoProcessor.process(configProps, m_fwk.getBundleContext());
- // (10) Start the framework.
- m_fwk.start();
- // (11) Wait for framework to stop to exit the VM.
- m_fwk.waitForStop(0);
- System.exit(0);
- }
- catch (Exception ex)
- {
- System.err.println("Could not create framework: " + ex);
- ex.printStackTrace();
- System.exit(0);
- }
- }
-
-
-The general steps of the standard launcher are quite straightforward:
-
-1. The launcher supports setting the auto-deploy directory (with the `-b` switch) and setting the bundle cache path with a single argument, so check for this and issue a usage message it there are more than one arguments.
-1. Load any system properties specified in the `system.properties` file; this file is typically located in the `conf/` directory of the Felix installation directory, but it can be specified directly using the `felix.system.properties` system property. This file is not needed to launch Felix and is provided merely for convenience when system properties must be specified. The file is a standard Java properties file, but it also supports property substitution using `$\{<property-name`} synt [...]
-1. Load any configuration properties specified in the `config.properties` file; this file is typically located in the `conf/` directory of the Felix installation directory, but it can be specified directly using the `felix.config.properties` system property. This file is used to configure the framework instance created by the launcher. The file is a standard Java properties file, but it also supports property substitution using "`$\{<property-name>`}" syntax. Property substitution can be [...]
-1. For convenience, any configuration properties that are set as system properties are copied into the set of configuration properties. This provide an easy way to add to or override configuration properties specified in the `config.properties` file, since the Felix instance will never look at system properties for configuration.
-1. If the `-b` switch was used to specify an auto-deploy directory, then use that to set the value of `felix.auto.deploy.dir`.
-1. If a single command-line argument is specified, then use that to set the value of `org.osgi.framework.storage`; relative paths are relative to the current directory unless the `felix.cache.rootdir` property is set.
-1. Add a shutdown hook to cleanly stop the framework, unless the hook is disabled.
-1. Create a framework instance using the `FrameworkFactory` passing in the configuration properties, then initialize the factory instance; see the [custom launcher example]({{ refs.-custom-launcher.path }}) below to see how the META-INF/services `FrameworkFactory` is obtained.
-1. Use `org.apache.felix.main.AutoProcessor`, which will automatically deploy any bundles in the auto-deploy directory as well as bundles specified in the `felix.auto.install` and `felix.auto.start` configuration properties during framework startup to automatically install and/or start bundles; see the usage document for more information [configuration properties]({{ refs.apache-felix-framework-usage-documentation-configuring-framework.path }}) and [bundle auto-deploy|Apache Felix Framew [...]
-1. Invoke `waitForStop()` to wait for the framework to stop to force the VM to exit; this is necessary because the framework never calls `System.exit()` and some libraries (e.g., Swing) create threads that will not allow the VM to exit.
-
-The framework is not active until the `start()` method is called. If no shell bundles are installed and started or if there is difficulty locating the shell bundles specified in the auto-start property, then it will appear as if the framework is hung, but it is actually running without any way to interact with it since the shell bundles provide the only means of interaction.
-
-
-
-## Custom Framework Launcher
-
-This section creates a bare-bones launcher to demonstrate the minimum requirements for creating an interactive launcher for the Felix framework. This example uses the standard Gogo shell bundles for interactivity, but any other bundles could be used instead. This example launcher project has the following directory structure:
-
-
- launcher/
- lib/
- org.apache.felix.main-3.0.0.jar
- bundle/
- org.apache.felix.gogo.command-0.6.0.jar
- org.apache.felix.gogo.runtime-0.6.0.jar
- org.apache.felix.gogo.shell-0.6.0.jar
- src/
- example/
- Main.java
-
-
-The `lib/` directory contains Felix' main JAR file, which also contains the OSGi core interfaces. The main JAR file is used so that we can reuse the default launcher's auto-install/auto-start configuration property handling; if these capabilities are not needed, then it would be possible to use the framework JAR file instead of the main JAR file. The `bundle/` directory contains the shell service and textual shell interface bundles that will be used for interacting with the framework ins [...]
-
-
- package example;
-
- import java.io.*;
- import org.osgi.framework.launch.*;
- import org.apache.felix.main.AutoProcessor;
-
- public class Main
- {
- private static Framework m_fwk = null;
-
- public static void main(String[] argv) throws Exception
- {
- // Print welcome banner.
- System.out.println("\nWelcome to My Launcher");
- System.out.println("======================\n");
-
- try
- {
- m_fwk = getFrameworkFactory().newFramework(null);
- m_fwk.init();
- AutoProcessor.process(null, m_fwk.getBundleContext());
- m_fwk.start();
- m_fwk.waitForStop(0);
- System.exit(0);
- }
- catch (Exception ex)
- {
- System.err.println("Could not create framework: " + ex);
- ex.printStackTrace();
- System.exit(-1);
- }
- }
-
- private static FrameworkFactory getFrameworkFactory() throws Exception
- {
- java.net.URL url = Main.class.getClassLoader().getResource(
- "META-INF/services/org.osgi.framework.launch.FrameworkFactory");
- if (url != null)
- {
- BufferedReader br = new BufferedReader(new InputStreamReader(url.openStream()));
- try
- {
- for (String s = br.readLine(); s != null; s = br.readLine())
- {
- s = s.trim();
- // Try to load first non-empty, non-commented line.
- if ((s.length() > 0) && (s.charAt(0) != '#'))
- {
- return (FrameworkFactory) Class.forName(s).newInstance();
- }
- }
- }
- finally
- {
- if (br != null) br.close();
- }
- }
-
- throw new Exception("Could not find framework factory.");
- }
- }
-
-
-This launcher relies on the default behavior of `AutoProcessor` to automatically deploy the shell bundles. This simple, generic launcher provides a good starting point if the default Felix launcher is not sufficient. Since very few configuration properties are specified, the default values are used. For the bundle auto-deploy directory, "`bundle`" in the current directory is used, while for the framework bundle cache, "`felix-cache`" in the current directory is used.
-
-By breaking down the above source code into small chunks, it is quite easy to see what is going on.
-
-
- m_fwk = getFrameworkFactory().newFramework(null);
- m_fwk.init()
-
-
-These steps get a the framework factory service and use it to create a framework instance with a default configuration. Once the framework instance is created, it is initialized with `init()`.
-
-
- AutoProcessor.process(null, m_fwk.getBundleContext());
-
-
-The `AutorProcessor` will automatically deploy bundles in the auto-deploy directory and any referenced from the auto-install/start properties. Since we are using an empty configuration, the auto-deploy directory is the `bundle` directory in the current directory and there are no auto properties. Therefore, in this case, the shell bundles will be installed.
-
-
- m_fwk.start();
- m_fwk.waitForStop(0);
- System.exit(0);
-
-
-These final steps start the framework and cause the launching application thread to wait for the framework to stop and when it does the launching thread calls `System.exit()` to make sure the VM actually exits.
-
-
- private static FrameworkFactory getFrameworkFactory() throws Exception
- {
- ...
- }
-
-
-This method retrieves the framework factory service by doing a META-INF/services resource lookup, which it can use to obtain the concrete class name for the factory. If you are using Java 6, then you can use the `ServiceLoader` API in the JRE to further simplify the factory service lookup.
-
-The following command compiles the launcher when run from the root directory of the launcher project:
-
-
- javac -d . -classpath lib/org.apache.felix.main-3.0.0.jar src/example/Main.java
-
-
-After executing this command, an `example/` directory is created in the current directory, which contains the generated class file. The following command executes the simple launcher when run from the root directory of the launcher project:
-
-
- java -cp .:lib/org.apache.felix.main-3.0.0.jar example.Main
-
-
-After executing this command, a "`felix-cache/`" directory is created that contains the cached bundles, which were installed from the `bundle/` directory.
-
-
-
-# Embedding the Felix Framework
-
-Embedding the Felix framework into a host application is a simple way to provide a sophisticated extensibility mechanism (i.e., a plugin system) to the host application. Embedding the Felix framework is very similar to launching it as described above, the main difference is that the host application typically wants to interact with the framework instance and/or installed bundles/services from the outside. This is fairly easy to achieve, but there are some subtle issues to understand. Thi [...]
-
-
-
-## Host/Felix Interaction
-
-In the section on [launching]({{ refs.-launching.path }}) the framework above, the `Felix` class accepts a configuration property called `felix.systembundle.activators`, which is a list of bundle activator instances. These bundle activator instances provide a convenient way for host applications to interact with the Felix framework.
-
-<div class="warning" markdown="1">
-**WARNING**
-The `felix.systembundle.activators` configuration property is specific to the Felix framework implementation. If you want your code to work with other framework implementations, you should call `init()` on the framework instance and use `getBundleContext()` directly. Otherwise, the approach would be very similar.
-</div>
-
-Each activator instance passed into the constructor effectively becomes part of the system bundle. This means that the `start()`/`stop()` methods of each activator instance in the list gets invoked when the system bundle's activator `start()`/`stop()` methods gets invoked, respectively. Each activator instance will be given the system bundle's `BundleContext` object so that they can interact with the framework. Consider following snippet of a bundle activator:
-
-
- public class HostActivator implements BundleActivator
- {
- private BundleContext m_context = null;
-
- public void start(BundleContext context)
- {
- m_context = context;
- }
-
- public void stop(BundleContext context)
- {
- m_context = null;
- }
-
- public Bundle[] getBundles()
- {
- if (m_context != null)
- {
- return m_context.getBundles();
- }
- return null;
- }
- }
-
-
-Given the above bundle activator, it is now possible to embed the Felix framework into a host application and interact with it as the following snippet illustrates:
-
-
- public class HostApplication
- {
- private HostActivator m_activator = null;
- private Felix m_felix = null;
-
- public HostApplication()
- {
- // Create a configuration property map.
- Map config = new HashMap();
- // Create host activator;
- m_activator = new HostActivator();
- List list = new ArrayList();
- list.add(m_activator);
- configMap.put(FelixConstants.SYSTEMBUNDLE_ACTIVATORS_PROP, list);
-
- try
- {
- // Now create an instance of the framework with
- // our configuration properties.
- m_felix = new Felix(config);
- // Now start Felix instance.
- m_felix.start();
- }
- catch (Exception ex)
- {
- System.err.println("Could not create framework: " + ex);
- ex.printStackTrace();
- }
- }
-
- public Bundle[] getInstalledBundles()
- {
- // Use the system bundle activator to gain external
- // access to the set of installed bundles.
- return m_activator.getBundles();
- }
-
- public void shutdownApplication()
- {
- // Shut down the felix framework when stopping the
- // host application.
- m_felix.stop();
- m_felix.waitForStop(0);
- }
- }
-
-
-Notice how the `HostApplication.getInstalledBundles()` method uses its activator instance to get access to the system bundle's context in order to interact with the embedded Felix framework instance. This approach provides the foundation for all interaction between the host application and the embedded framework instance.
-
-
-
-## Providing Host Application Services
-
-Providing services from the host application to bundles inside the embedded Felix framework instance follows the basic approach laid out in [above]({{ refs.-host-interaction.path }}). The main complication for providing a host application service to bundles is the fact that both the host application and the bundles must be using the same class definitions for the service interface classes. Since the host application cannot import classes from a bundle, this means that the service interfa [...]
-
-Consider the follow simple property lookup service:
-
-
- package host.service.lookup;
-
- public interface Lookup
- {
- public Object lookup(String name);
- }
-
-
-This package is simply part of the host application, which is potentially packaged into a JAR file and started with the "`java -jar`" command. Now consider the following host application bundle activator, which will be used to register/unregister the property lookup service when the embedded framework instance starts/stops:
-
-
- package host.core;
-
- import java.util.Map;
- import org.osgi.framework.BundleActivator;
- import org.osgi.framework.BundleContext;
- import org.osgi.framework.ServiceRegistration;
- import host.service.lookup;
-
- public class HostActivator implements BundleActivator
- {
- private Map m_lookupMap = null;
- private BundleContext m_context = null;
- private ServiceRegistration m_registration = null;
-
- public HostActivator(Map lookupMap)
- {
- // Save a reference to the service's backing store.
- m_lookupMap = lookupMap;
- }
-
- public void start(BundleContext context)
- {
- // Save a reference to the bundle context.
- m_context = context;
- // Create a property lookup service implementation.
- Lookup lookup = new Lookup() {
- public Object lookup(String name)
- {
- return m_lookupMap.get(name);
- }
- };
- // Register the property lookup service and save
- // the service registration.
- m_registration = m_context.registerService(
- Lookup.class.getName(), lookup, null);
- }
-
- public void stop(BundleContext context)
- {
- // Unregister the property lookup service.
- m_registration.unregister();
- m_context = null;
- }
- }
-
-
-Given the above host application bundle activator, the following code snippet shows how the host application could create an embedded version of the Felix framework and provide the property lookup service to installed bundles:
-
-
- package host.core;
-
- import java.util.List;
- import java.util.ArrayList;
- import java.util.Map;
- import java.util.HashMap;
- import host.service.lookup.Lookup;
- import org.apache.felix.framework.Felix;
- import org.apache.felix.framework.util.FelixConstants;
- import org.osgi.framework.Constants;
-
- public class HostApplication
- {
- private HostActivator m_activator = null;
- private Felix m_felix = null;
- private Map m_lookupMap = new HashMap();
-
- public HostApplication()
- {
- // Initialize the map for the property lookup service.
- m_lookupMap.put("name1", "value1");
-
- m_lookupMap.put("name2", "value2");
- m_lookupMap.put("name3", "value3");
- m_lookupMap.put("name4", "value4");
-
- // Create a configuration property map.
- Map configMap = new HashMap();
- // Export the host provided service interface package.
- configMap.put(Constants.FRAMEWORK_SYSTEMPACKAGES_EXTRA,
- "host.service.lookup; version=1.0.0");
- // Create host activator;
- m_activator = new HostActivator(m_lookupMap);
- List list = new ArrayList();
- list.add(m_activator);
- configMap.put(FelixConstants.SYSTEMBUNDLE_ACTIVATORS_PROP, list);
-
- try
- {
- // Now create an instance of the framework with
- // our configuration properties.
- m_felix = new Felix(configMap);
- // Now start Felix instance.
- m_felix.start();
- }
- catch (Exception ex)
- {
- System.err.println("Could not create framework: " + ex);
- ex.printStackTrace();
- }
- }
-
- public void shutdownApplication()
- {
- // Shut down the felix framework when stopping the
- // host application.
- m_felix.stop();
- m_felix.waitForStop(0);
- }
- }
-
-
-Rather than having the host application bundle activator register the service, it is also possible for the the host application to simply get the bundle context from the bundle activator and register the service directly, but the presented approach is perhaps a little cleaner since it allows the host application to register/unregister the service when the system bundle starts/stops.
-
-
-
-## Using Services Provided by Bundles
-
-Using services provided by bundles follows the same general approach of using a host application bundle activator. The main complication for the host application using a service from a bundle is the fact that both the host application and the bundle must be using the same class definitions for the service interface classes. Since the host application cannot import classes from a bundle, this means that the service interface classes *must* be accessible on the class path, typically as par [...]
-
-Consider the following simple command service interface for which bundles provide implementations, such as might be used to create an extensible interactive shell:
-
-
- package host.service.command;
-
- public class Command
- {
- public String getName();
- public String getDescription();
- public boolean execute(String commandline);
- }
-
-
-This package is simply part of the host application, which is potentially packaged into a JAR file and started with the "`java -jar`" command. Now consider the previously introduced host application bundle activator below, which simply provides access to the system bundle context:
-
-
- package host.core;
-
- import org.osgi.framework.BundleActivator;
- import org.osgi.framework.BundleContext;
-
- public class HostActivator implements BundleActivator
- {
- private BundleContext m_context = null;
-
- public void start(BundleContext context)
- {
- m_context = context;
- }
-
- public void stop(BundleContext context)
- {
- m_context = null;
- }
-
- public BundleContext getContext()
- {
- return m_context;
- }
- }
-
-
-With this bundle activator, the host application can use command services provided by bundles installed inside its embedded Felix framework instance. The following code snippet illustrates one possible approach:
-
-
- package host.core;
-
- import java.util.List;
- import java.util.ArrayList;
- import java.util.Map;
- import host.service.command.Command;
- import org.apache.felix.framework.Felix;
- import org.apache.felix.framework.util.FelixConstants;
- import org.apache.felix.framework.cache.BundleCache;
- import org.osgi.framework.Constants;
- import org.osgi.util.tracker.ServiceTracker;
-
- public class HostApplication
- {
- private HostActivator m_activator = null;
- private Felix m_felix = null;
- private ServiceTracker m_tracker = null;
-
- public HostApplication()
- {
- // Create a configuration property map.
- Map configMap = new HashMap();
- // Export the host provided service interface package.
- configMap.put(Constants.FRAMEWORK_SYSTEMPACKAGES_EXTRA,
- "host.service.command; version=1.0.0");
- // Create host activator;
- m_activator = new HostActivator();
- List list = new ArrayList();
- list.add(m_activator);
- configMap.put(FelixConstants.SYSTEMBUNDLE_ACTIVATORS_PROP, list);
-
- try
- {
- // Now create an instance of the framework with
- // our configuration properties.
- m_felix = new Felix(configMap);
- // Now start Felix instance.
- m_felix.start();
- }
- catch (Exception ex)
- {
- System.err.println("Could not create framework: " + ex);
- ex.printStackTrace();
- }
-
- m_tracker = new ServiceTracker(
- m_activator.getContext(), Command.class.getName(), null);
- m_tracker.open();
- }
-
- public boolean execute(String name, String commandline)
- {
- // See if any of the currently tracked command services
- // match the specified command name, if so then execute it.
- Object[] services = m_tracker.getServices();
- for (int i = 0; (services != null) && (i < services.length); i++)
- {
- try
- {
- if (((Command) services[i]).getName().equals(name))
- {
- return ((Command) services[i]).execute(commandline);
- }
- }
- catch (Exception ex)
- {
- // Since the services returned by the tracker could become
- // invalid at any moment, we will catch all exceptions, log
- // a message, and then ignore faulty services.
- System.err.println(ex);
- }
- }
- return false;
- }
-
- public void shutdownApplication()
- {
- // Shut down the felix framework when stopping the
- // host application.
- m_felix.stop();
- m_felix.waitForStop(0);
- }
- }
-
-
-The above example is overly simplistic with respect to concurrency issues and error conditions, but it demonstrates the overall approach for using bundle-provided services from the host application.
-
-
-
-### Using Bundle Services via Reflection
-
-It possible for the host application to use services provided by bundles without having access to the service interface classes and thus not needing to put the service interface classes on the class path. To do this, the host application uses the same general approach to acquire the system bundle context object, which it can use to look up service objects. Using either an LDAP filter or the service interface class name, the host application can retrieve the service object and then use st [...]
-
-
-
-### Other Approaches
-
-The [Transloader](http://code.google.com/p/transloader/) project is another attempt at dealing with issues of classes loaded from different class loaders and may be of interest.
-
-
-
-# Caveat
-
-The code in this document has not been thoroughly tested nor even compiled and may be out of date with respect to the current Felix source code. If you find errors please report them so the that they can be corrected.
-
-
-
-## Feedback
-
-Subscribe to the Felix users mailing list by sending a message to [users-subscribe@felix.apache.org]({{ refs.mailto-users-subscribe-felix-apache-org.path }}); after subscribing, email questions or feedback to [users@felix.apache.org|mailto:users@felix.apache.org].
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-framework/apache-felix-framework-usage-documentation.mdtext b/modules/ROOT/pages/documentation/subprojects/apache-felix-framework/apache-felix-framework-usage-documentation.mdtext
deleted file mode 100644
index c9f615e..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-framework/apache-felix-framework-usage-documentation.mdtext
+++ /dev/null
@@ -1,179 +0,0 @@
-Title: Apache Felix Framework Usage Documentation
-
-* [Downloading the Framework](#downloading-the-framework)
-* [Starting the Framework](#starting-the-framework)
-* [Framework Shell](#framework-shell)
- * [Installing Bundles](#installing-bundles)
- * [Web Proxy Issues when Installing Bundles](#web-proxy-issues-when-installing-bundles)
-* [Bundle Auto-Deploy](#bundle-auto-deploy)
-* [Configuring the Framework](#configuring-the-framework)
- * [System Property Substitution](#system-property-substitution)
-* [Configuring Bundles](#configuring-bundles)
-* [Feedback](#feedback)
-
-## Downloading the Framework
-
-Go to the [downloads]({{ refs.downloads.path }}) page and download the latest Felix framework distribution.
-
-
-
-## Starting the Framework
-
-Start the framework from the installation directory by typing:
-
-
- java -jar bin/felix.jar
-
-
-The framework launcher starts the framework and installs and starts all bundles contained in the `bundle` directory of the current directory. By default, the bundle directory contains shell-related bundles providing a textual user interface to interact with the framework. Bundles installed into the framework are copied into a bundle cache directory for subsequent executions. By default, the framework creates a cache directory, called `felix-cache`, in your current working directory. If y [...]
-
-
- java -jar bin/felix.jar <cache-path>
-
-
-Where `<cache-path>` is the path you want to use as the bundle cache. If you specify a relative cache path, then it will be treated as relative to the current working directory.
-
-<div class="info" markdown="1">
-<b>Useful Information</b><br/>
-Previous versions of the framework prompted for a profile name when executed. The profile name
-was used to create a directory inside <code>.felix/</code> in the user home directory. This
-approach allowed users to have different sets of bundles for different purposes, e.g., testing,
-production, etc. If this behavior is still desired, it is very easy to mimic. Modify
-<code>conf/config.properties</code> to include "<code>felix.cache.rootdir=${user.home}/.felix</code>".
-Now, if you start Felix with something like "<code>java -jar bin/felix.jar foo</code>", it will use
-"<code>${user.home}/.felix/foo/</code>" as the bundle cache directory, where
-"<code>${user.home}</code>" is automatically substituted with the appropriate system property by
-the launcher.
-</div>
-
-
-
-## Framework Shell
-
-The main way to interact with the framework is via the supplied Apache Felix Gogo shell. After starting the framework, type `help` into the shell to see the list of the available commands and `help <command-name>` to get help for a specific command.
-
-<div class="info" markdown="1">
-<b>Useful Information</b><br/>
-In Gogo, command names are made up of two parts: <code><scope>:<name></code>. This is similar
-to a fully qualified class name in Java and is used to avoid naming collisions. If the
-<code><name></code> portion of the command is unique, then you only need to type it. If not,
-then you must either type the full <code><scope>:<name></code> or arrange the scope search path accordingly.
-</div>
-
-To install bundles, use the `felix:install` command, which is described in more detail in the next [sub-section]({{ refs.-installing-bundles.path }}). To list installed bundles, use the `felix:lb` command. To stop the framework type `stop 0` to stop the System Bundle; any installed bundles will automatically be reloaded (and potentially restarted) the next time you launch with the associated cache.
-
-
-
-### Installing Bundles
-
-A bundle is the OSGi term for a component for the OSGi framework. A bundle is simply a JAR file containing a manifest and some combination of Java classes, embedded JAR files, native code, and resources. A bundle may provide some specific functionality for the user or it may implement a service that other bundles can use; bundles can only use functionality from other bundles through shared services and packages.
-
-The Felix framework distribution comes with three bundles, which are located in the `bundle/` directory of the framework distribution installation directory. These bundles include the Gogo Runtime (core command processing functionality), Gogo Shell (text-based shell user interface), Gogo Command (basic set of commands), and Bundle Repository (a bundle repository service). In addition to these bundles, the bundle repository provides access to other bundles for easy installation. The bundl [...]
-
-Before installing any bundles, it is important to understand how bundles are manually deployed into the framework. Bundles are deployed in two stages; first they are installed, then they are started. To install a bundle use the `felix:install` shell command followed by a bundle URL. For example, to install a `bundle.jar` bundle you type:
-
-
- felix:install file:/path/to/bundle/bundle.jar
-
-
-Once a bundle is installed, it can then be started by using the `felix:start` command and the bundle identifier of the desired bundle. The `felix:lb` command is used to list installed bundles and to obtain the bundle's identifier. The following Felix shell session illustrates how to start the `bundle.jar` bundle:
-
-
- g! install file:/path/to/bundle/bundle.jar
- g! lb
- START LEVEL 1
- ID|State |Level|Name
- 0|Active | 0|System Bundle (3.0.0)
- 1|Active | 1|Apache Felix Bundle Repository (1.6.2)
- 2|Active | 1|Apache Felix Gogo Command (0.6.0)
- 3|Active | 1|Apache Felix Gogo Runtime (0.6.0)
- 4|Active | 1|Apache Felix Gogo Shell (0.6.0)
- 5|Installed | 1|Example Bundle (1.0.0)
- g! start 5
- Hello from Bundle 5.
- g!
-
-
-The `felix:stop` command is used to stop a bundle and the `felix:uninstall` command is used to remove a bundle from the bundle cache. As an alternative to using the `felix:install` and `felix:start` commands explicitly, it is also possible to install and start a bundle in one step by using the `felix:start` command with a bundle URL.
-
-Bundles can be updated using the `felix:update` command. The update command allows you to specify an URL from which to retrieve the updated bundle, but if one is not specified it will try to update the bundle from the bundle's `Bundle-UpdateLocation` manifest attribute, if present, or the bundle's original location URL.
-
-<div class="info" markdown="1">
-<b>Useful Information</b><br/>
-When you use <code>felix:update</code> or <code>felix:uninstall</code>, the changes appear to take
-effect immediately, but in reality the changes are only partially enacted. If a bundle is updated
-or uninstalled and it was exporting packages, these packages are not removed until the framework
-is refreshed using the <code>PackageAdmin</code> service. The Felix shell offers a convenient
-<code>refresh</code> command for this purpose. This is the correct behavior as defined by the OSGi
-specification.
-</div>
-
-For an introduction to writing bundles and services, refer to the Felix bundle tutorial.
-
-
-
-### Web Proxy Issues when Installing Bundles
-
-If you use a proxy for Web access, then you may run into difficulty using the Gogo shell to install bundles from remote URLs. To remedy this situation, certain system properties must be set to make the framework work with your proxy. These properties are:
-
-* `http.proxyHost` \- the name of the proxy host.
-* `http.proxyPort` \- the port of the proxy host.
-* `http.proxyAuth` \- the user name and password to use when connecting to the proxy; this string should be the user name and password separated by a colon (e.g., `rickhall:mypassword`).
-
-These system properties can be set directly on the command line when starting the JVM using the standard "`\-D<prop>=<value>`" syntax
-or you can put them in the `lib/system.properties` file of your Felix installation; see the next section on [configuring Felix](#configuring-the-framework)
-for more information.
-
-
-
-## Bundle Auto-Deploy
-
-To minimize the amount of configuration necessary to install bundles when you launch the framework, the Felix launcher uses the concept of an "auto-deploy" directory. The Felix launcher deploys all bundles in the auto-deploy directory into the framework instance during startup. By default, the auto-deploy directory is "`bundle`" in the current directory, but it can be specified on the command line like this:
-
-
- java -jar bin/felix.jar -b /path/to/dir
-
-
-Specifying an auto-deploy directory replaces the default directory, it does not augment it. The framework distribution is configured to install and start bundles in the auto-deploy directory. Both the location of the auto-deploy directory and the deployment actions performed can be controlled by the following configuration properties, respectively:
-
-* `felix.auto.deploy.dir` \- Specifies the auto-deploy directory from which bundles are automatically deploy at framework startup. The default is the `bundle/` directory of the current directory.
-* `felix.auto.deploy.action` \- Specifies the auto-deploy actions to be performed on the bundle JAR files found in the auto-deploy directory. The possible actions are `install`, `update`, `start`, and `uninstall`. If no actions are specified, then the auto-deploy directory is not processed (i.e., it is disabled). There is no default value for this property, but the default `config.properties` file installed with the Felix framework distribution sets the value to: `install, start`
-
-The next section describes how to set and use configuration properties.
-
-
-
-## Configuring the Framework
-
-Both the Felix framework and the launcher use configuration properties to alter their default behavior. The framework can only be configured by passing properties into its constructor, but the launcher provides a mechanism to configure the framework via a property file. The framework launcher reads configuration properties from `conf/config.properties`. This file uses standard Java property file syntax.
-
-The launcher also supports setting system properties via the `conf/system.properties` file. This file is purely for convenience when you need to repeatedly set system properties when running the framework. While the framework itself does not look at system properties, the launcher does copy any framework configuration properties found in the system properties into the framework configuration map, also for your convenience.
-
-It is possible to specify different locations for these property files using the `felix.config.properties` and `felix.system.properties` system properties when executing the framework. For example:
-
-
- java -Dfelix.config.properties=file:/home/rickhall/config.properties -jar bin/felix.jar
-
-
-Configuration and system properties are accessible at run time via `BundleContext.getProperty()`, but configuration properties override system properties. For more information about available configuration properties, refer to the [Apache Felix Framework Configuration Properties]({{ refs.apache-felix-framework-configuration-properties.path }}) document. The Felix framework distribution contains a default `conf/config.properties`.
-
-
-
-### System Property Substitution
-
-It is possible to use system properties to specify the values of properties in the `conf/config.properties` file. This is achieved through system property substitution, which is instigated by using `$\{<property>\`} syntax, where `<property>` is the name of a system property to substitute. When the properties file is read, any such property values are substituted as appropriate. It is possible to have nested system property substitution, in which case the inner-most property is substitut [...]
-
-
-
-## Configuring Bundles
-
-Some bundles use properties to configure certain aspects of their behavior. It is a good idea, when implementing bundles, to parameterize them with properties where appropriate. To learn about the configuration options for specific bundles, refer to the documentation that accompanies them.
-
-Bundle properties may also be defined in the `conf/config.properties` property file. Any property placed in this file will be accessible via `BundleContext.getProperty()` at run time. The property file uses the standard Java property file syntax (i.e., attribute-value pairs). For information on changing the default location of this file, refer to the section on [configuring Felix](#configuring-the-framework).
-
-
-
-## Feedback
-
-Subscribe to the Felix users mailing list by sending a message to [users-subscribe@felix.apache.org](mailto:users-subscribe@felix.apache.org);
-after subscribing, email questions or feedback to [users@felix.apache.org](mailto:users@felix.apache.org).
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-gogo.mdtext b/modules/ROOT/pages/documentation/subprojects/apache-felix-gogo.mdtext
deleted file mode 100644
index b789009..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-gogo.mdtext
+++ /dev/null
@@ -1,195 +0,0 @@
-Title: Apache Felix Gogo
-
-Apache Felix Gogo is a subproject of Apache Felix implementing a command line shell for OSGi. It is used in many OSGi runtimes and servers (Felix distro, Eclipse IDE, Apache Karaf, ...).
-
-## Overview
-
-The Gogo subproject consists of three bundles:
-
-- *runtime* \- implements the core command processing functionality.
-- *command* \- implements a set of basic commands.
-- *jline* \- Advanced textual user interface with features like completion and colors
-- *shell* \- provides a simple textual user interface to interact with the command processor.
-
-## Working with the sources
-
-You can find the [sources on apache svn](https://svn.apache.org/repos/asf/felix/trunk/gogo/) there is also [a mirror at github](https://github.com/apache/felix/tree/trunk/gogo).
-
-Clone
- git clone https://github.com/apache/felix
-
-Build
- cd gogo
- mvn clean install
-
-## Using Gogo with the Felix Framework
-
-Gogo is included as the default shell in the felix framework distribution. To use it, you just start the framework like normal:
-
- $ java -jar bin/felix.jar
- _______________
- Welcome to Apache Felix Gogo
-
- g!
-
-Gogo shell integration in the framework distribution is also discussed in the [framework usage document]({{ refs.apache-felix-framework-usage-documentation.path }})
-
-## Built in shell features
-
-- TAB
-
- Completion for commands and parameters
-
-- Cursor left, Cursor right
-
- Edit inside current line
-
-- Cursor up, Cursor down
-
- Scroll through history
-
-- Ctrl-C
-
- Interrupt execution of current command
-
-- Ctrl-D
-
- Exit the shell
-
-- Ctrl-R
-
- Search in history
-
-- *\[command1\]* | *\[command2\]*
-
- Pipe output of command1 as input of command2
-
-## Basic commands
-
-- cat *\[URI\]*
-
- Read URI and print to stdout
-
-- cd *\[path\]*
-
- Change working directory
-
-- diag *\[bundleid\]*
-
- Shows why a bundle is not working
-
-- help
-
- Show the available commands
-
-- help *\[command\]*
-
- Shows detailed help about a command
-
-- head *\[bundleid\]*
-
- Print bundle headers
-
-- history
-
- Shows the history of executed commands
-
-- inspect capability service *\[bundleid\]*
-
- Lists all services provided by a bundle
-
-- inspect requirement service *\[bundleid\]*
-
- Lists all services required by a bundle
-
-- install *\[URI\]*
-
- Install a bundle from file or URI
-
-- lb
-
- List bundles
-
-- *\[command1\]* | less
-
- Show output of command1 in a paged view
-
-- less *\[file\]*
-
- Show file in a paged view
-
-- ls *\[directory\]*
-
- Show directory contents
-
-- start *\[bundleid\]*
-
- Start the given bundle
-
-- stop *\[bundleid\]*
-
- Stop the given bundle
-
-- tac
-
- Capture stdin as string and optionally write to file
-
-- tail *\[file\]*
-
- Shows the last lines of a file. Using -f allows to follow the file changes.
-
-- uninstall *\[bundleid\]*
-
- Uninstall given bundle
-
-## Changing shell colors
-
-The colors of the command shell cane be adjusted by setting a property in an init script or directly on the shell.
-
-HIGHLIGHTER_COLORS = "rs=35:st=32:nu=32:co=32:va=36:vn=36:fu=94:bf=91:re=90"
-
-The property above forms a map from highlight type to ANSI color code.
-
-These are the highlight types
-
-- rs : Reserved words
-- st : Strings
-- nu : Numbers
-- co : Constants
-- va : Variable
-- vn : Variable name
-- fu : Function
-- bf : Bad function
-- un : Unknown
-- re : Repair
-
-The colors of the ls output can be adjusted using
-
-LS_COLORS = "dr=1;91:ex=1;92:sl=1;96:ot=34;43"
-
-The color types are these:
-
-- dr : Directory
-- ex : Executable
-- sl : Symbolic Link
-- ot : Other
-
-Last but not least grep can also be adjusted
-
-GREP_COLORS = "mt=1;31:fn=35:ln=32:se=36"
-
-Types:
-
-- mt : Hits in the text (sets both ms and mc)
-- ms : Matching text in selected line
-- mc : Matching text in context line
-- fn : File names
-- ln : Line numbers
-- se : Selected lines
-- sl : Whole selected line
-- cx : Context lines
-- rv : If set and match is inverted, the meaning of sl and cx is inverted
-
-## Origin in RFC 147
-
-Gogo is based on the OSGi RFC 147, which describes a standard shell for OSGi-based environments. See [RFC 147 Overview]({{ refs.rfc-147-overview.path }}) for more information. Unfortunately this RFC was never made a standard.
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-gogo/rfc-147-overview.mdtext b/modules/ROOT/pages/documentation/subprojects/apache-felix-gogo/rfc-147-overview.mdtext
deleted file mode 100644
index 6f99cfb..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-gogo/rfc-147-overview.mdtext
+++ /dev/null
@@ -1,158 +0,0 @@
-Title: RFC 147 Overview
-
-The RFC-147 draft is not yet publicly available. It used to be called RFC-132, which can be found in an [early specification draft](http://www.osgi.org/download/osgi-4.2-early-draft.pdf)
-
-This is an overview of its main features:
-
-[TOC]
-
-## Standard way to implement and run commands for any OSGi 4.2 framework
-
-Commands are registered via service attributes, you don't have to register a specific service. This allows commands to be registered by existing services, just by adding the new attributes:
-
- :::java
- Dictionary<String, Object> dict = new Hashtable<String, Object>();
- dict.put(CommandProcessor.COMMAND_SCOPE, "shell");
- dict.put(CommandProcessor.COMMAND_FUNCTION, new String[] {"sleep", "grep"});
- context.registerService(name, service, dict);
-
-Scope is used to provide a namespace for commands. The commands above can be invoked as `shell:sleep` and `shell:grep`. If the scope is omitted (e.g. `sleep` and `grep`) then the first matching command is invoked.
-
-### Commands can have any signature
-
-Arguments are coerced to call the best matching method using reflection. A `CommandSession` argument is inserted if required:
-
- :::java
- public void sleep(long millis) throws InterruptedException{
- Thread.sleep(millis);
- }
-
- public void sleep(String[] args) throws Exception;
-
- public boolean grep(CommandSession session, String[] args) throws Exception;
-
-The `CommandSession` interface provides methods for executing commands and getting and setting session variables:
-
- :::java
- public interface org.apache.felix.service.command.CommandSession {
- Object execute(CharSequence commandline) throws Exception;
- Object get(String name);
- void put(String name, Object value);
- ...
- }
-
-### Easy to use interactively - no unnecessary syntax
-
-- basic commands
-
- :::shell
- g! echo hello world
- hello world
-
-- session variables
-
- :::shell
- g! msg = "hello world"
- g! echo $msg
- hello world
-
-- execution quotes `()` - similar to bash backquotes
-
- :::shell
- g! (bundle 1) location
- file:/Users/derek/Downloads/felix-framework-3.0.0/bundle/org.apache.felix.bundlerepository-1.6.2.jar
-
-### Lists, maps, pipes and closures
-
-- lists - `[]`
-
- :::shell
- g! list = [1 2 a b]
- 1
- 2
- a
- b
-
-- maps - `[]`
-
- :::shell
- g! map = [Jan=1 Feb=2 Mar=3]
- Jan 1
- Feb 2
- Mar 3
-
-- pipes - `|`
-
- :::shell
- g! bundles | grep gogo
- 2|Active | 1|org.apache.felix.gogo.command (0.6.0)
- 3|Active | 1|org.apache.felix.gogo.runtime (0.6.0)
- 4|Active | 1|org.apache.felix.gogo.shell (0.6.0)
-
-- closures - `{}`
-
- :::shell
- g! echo2 = { echo xxx $args yyy }
- g! echo2 hello world
- xxx hello world yyy
-
-### Leverages existing Java capabilities, via reflection
-
-- exception handling - console shows summary, but full context available
-
- :::shell
- g! start xxx
- E: Cannot coerce start[xxx] to any of [(Bundle)]
- g! $exception printstacktrace
- java.lang.IllegalArgumentException: Cannot coerce start[xxx] to any of [(Bundle)]
- at org.apache.felix.gogo.runtime.shell.Reflective.method(Reflective.java:162)
- at org.apache.felix.gogo.runtime.shell.Command.execute(Command.java:40)
- at org.apache.felix.gogo.runtime.shell.Closure.execute(Closure.java:211)
- at org.apache.felix.gogo.runtime.shell.Closure.executeStatement(Closure.java:146)
- at org.apache.felix.gogo.runtime.shell.Pipe.run(Pipe.java:91)
- ...
-
-- add all public methods on `java.lang.System` as commands:
-
- :::shell
- g! addcommand system (loadClass java.lang.System)
- g! system:getproperties
- sun.io.unicode.encodingUnicodeLittle
- java.version 1.5.0_19
- java.class.path bin/felix.jar
- java.awt.graphicsenvapple.awt.CGraphicsEnvironment
- user.language en
- sun.os.patch.level unknown
- os.version 10.6.2
- [snip]
-
-### Easy to implement and test commands without needing OSGi
-
-Command implementations don't need to reference any OSGi interfaces. They can use `System.in`, `System.out` and `System.err`, just as you would in a trivial Java application. The `ThreadIO` service transparently manages the singleton `System.out` etc, so that each thread sees the appropriate stream:
-
- :::java
- public void cat(String[] args) throws Exception {
- for (String arg : args) {
- IOUtil.copy(arg, System.out);
- }
- }
-
-### Normal commands can provide control primitives
-
- :::java
- public void each(CommandSession session, Collection<Object> list, Function closure) throws Exception {
- for (Object x : list) {
- closure.execute(session, null);
- }
- }
-
-then
-
- :::shell
- g! each [Jan Feb Mar] { echo $it | grep . }
- Jan
- Feb
- Mar
-
-**Note:** The default *echo* command _returns_ a String and does not write to System.out. Also, by default, the console prints the results of each command, so *echo* appears to behave as you would expect.
-However, the console does not see the *each* closure above, so the result of echo would not be seen. This is why it is piped into *grep*, as the _result_ of the command as well as its output is written to a pipeline.
\ No newline at end of file
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-healthchecks.mdtext b/modules/ROOT/pages/documentation/subprojects/apache-felix-healthchecks.mdtext
deleted file mode 100644
index f860123..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-healthchecks.mdtext
... 24520 lines suppressed ...
[felix-antora-site] 04/18: remove deployment admin doc
(unmaintained)
Posted by dj...@apache.org.
This is an automated email from the ASF dual-hosted git repository.
djencks pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/felix-antora-site.git
commit a52ef9a4ae2c8cb08bc6c961866c7b6da301fc2f
Author: David Jencks <dj...@apache.org>
AuthorDate: Sun Jul 11 15:37:19 2021 -0700
remove deployment admin doc (unmaintained)
---
modules/ROOT/pages/documentation/subprojects.adoc | 2 +-
.../documentation/subprojects/apache-felix-deployment-admin.adoc | 4 ----
2 files changed, 1 insertion(+), 5 deletions(-)
diff --git a/modules/ROOT/pages/documentation/subprojects.adoc b/modules/ROOT/pages/documentation/subprojects.adoc
index 67301bd..ec0e33e 100644
--- a/modules/ROOT/pages/documentation/subprojects.adoc
+++ b/modules/ROOT/pages/documentation/subprojects.adoc
@@ -120,7 +120,7 @@ The last documentation may be found in the https://github.com/apache/felix-site-
* https://github.com/apache/felix-site-pub/blob/last-cms/documentation/subprojects/apache-felix-autoconf.html[Auto Configuration]
* https://github.com/apache/felix-site-pub/blob/last-cms/documentation/subprojects/apache-felix-commons.html[Commons]
-* xref:documentation/subprojects/apache-felix-deployment-admin.adoc[Deployment Admin]
+* https://github.com/apache/felix-site-pub/blob/last-cms/documentation/subprojects/apache-felix-deployment-admin.html[Deployment Admin]
* xref:documentation/subprojects/apache-felix-jaas.adoc[JAAS Support]
* xref:documentation/subprojects/apache-felix-lightweight-http-service.adoc[Lightweight HTTP Service]
* xref:documentation/subprojects/apache-felix-manifest-generator-mangen.adoc[Manifest Generator (mangen)]
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-deployment-admin.adoc b/modules/ROOT/pages/documentation/subprojects/apache-felix-deployment-admin.adoc
deleted file mode 100644
index f6ce55e..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-deployment-admin.adoc
+++ /dev/null
@@ -1,4 +0,0 @@
-= Apache Felix Deployment Admin
-
-This project implements the OSGi Deployment Admin specification;
-please consult the OSGi Compendium Specification chapter 114 for more information.
[felix-antora-site] 03/18: remove commons doc (unmaintained)
Posted by dj...@apache.org.
This is an automated email from the ASF dual-hosted git repository.
djencks pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/felix-antora-site.git
commit ddb481c452fc0214017687488bde0c44fcce8b4e
Author: David Jencks <dj...@apache.org>
AuthorDate: Sun Jul 11 15:36:15 2021 -0700
remove commons doc (unmaintained)
---
modules/ROOT/pages/documentation/subprojects.adoc | 2 +-
.../subprojects/apache-felix-commons.adoc | 152 ---------------------
.../creating-bundles-using-bnd.adoc | 88 ------------
3 files changed, 1 insertion(+), 241 deletions(-)
diff --git a/modules/ROOT/pages/documentation/subprojects.adoc b/modules/ROOT/pages/documentation/subprojects.adoc
index d44b765..67301bd 100644
--- a/modules/ROOT/pages/documentation/subprojects.adoc
+++ b/modules/ROOT/pages/documentation/subprojects.adoc
@@ -119,7 +119,7 @@ The following projects are no longer maintained and are not documented in this s
The last documentation may be found in the https://github.com/apache/felix-site-pub/tree/last-cms repository.
* https://github.com/apache/felix-site-pub/blob/last-cms/documentation/subprojects/apache-felix-autoconf.html[Auto Configuration]
-* xref:documentation/subprojects/apache-felix-commons.adoc[Commons]
+* https://github.com/apache/felix-site-pub/blob/last-cms/documentation/subprojects/apache-felix-commons.html[Commons]
* xref:documentation/subprojects/apache-felix-deployment-admin.adoc[Deployment Admin]
* xref:documentation/subprojects/apache-felix-jaas.adoc[JAAS Support]
* xref:documentation/subprojects/apache-felix-lightweight-http-service.adoc[Lightweight HTTP Service]
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-commons.adoc b/modules/ROOT/pages/documentation/subprojects/apache-felix-commons.adoc
deleted file mode 100644
index f24389b..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-commons.adoc
+++ /dev/null
@@ -1,152 +0,0 @@
-= Apache Felix Commons
-
-== Purpose
-
-Apache Felix Commons is a community effort to create OSGi bundle ("bundlized") versions of popular third-party open-source libraries.
-Today, OSGi developers must create bundles out of third-party libraries within their own development communities.
-The purpose of Felix Commons is to avoid duplicating the effort of bundle creation by sharing these bundlized artifacts.
-Our hope is that over time, the original developers of the third-party libraries can use these bundlized libraries to learn how to add OSGi metadata to their project artifacts and to become comfortable with the overall non-invasive process.
-Felix Commons is thus a large "project" of POMs where each bundle POM simply has a dependency on the library it wants to convert.
-The Felix Maven Bundle Plugin will then convert the dependency automatically and the bundle will be available via existing Maven infrastructure.
-
-This web page will be used to document who is doing what and to provide pointers to more information.
-
-== How Can I Help?
-
-If you have libraries you have turned into bundles, then you can offer to contribute them.
-Additionally, you may request that a certain bundle be created.
-If you wish to submit a POM file for a specific library, you can attach it to a http://issues.apache.org/jira/browse/Felix[Felix JIRA issue] under the "Felix Commons" component.
-For Apache purposes, contributing a bundle POM is the same as contributing code.
-
-== Getting Started
-
-In most cases, creating bundlized versions of a library is as simple as creating a POM file for the library using Felix' new xref:documentation/subprojects/apache-felix-maven-bundle-plugin-bnd.adoc[Maven Bundle Plugin].
-The OSGi headers are non-intrusive.
-A JAR can be made in such a way that it runs on the Classpath as well as a bundle in an OSGi framework.
-In short you:
-
-. Set the groupId to: `<groupId>org.apache.felix.commons</groupId>`
-. Append "-osgi" to the name of the artifact: `<artifactId>FOO-osgi</artifactId>`
-. Set the "packaging" to use the Maven Bundle Plugin: `<packaging>bundle</packaging>`
-. Set any configuration options in the xref:documentation/subprojects/apache-felix-maven-bundle-plugin-bnd.adoc[Maven Bundle Plugin].
-
-We recommend you read the longer xref:documentation/subprojects/apache-felix-commons/creating-bundles-using-bnd.adoc[steps for converting a library to a bundle].
-
-== Contributions
-
-|===
-| Library | Version | Description | Contributor | Grant OK | Committed
-
-| cglib
-| 2.0.2
-| CGLib
-| Felix Meschberger
-| Yes
-| Yes
-
-| commons-beanutils
-| 1.7.0
-| BeanUtils
-| Felix Meschberger
-| Yes
-| Yes
-
-| commons-codec
-| 1.2
-| Codec
-| Felix Meschberger
-| Yes
-| Yes
-
-| commons-configuration
-| 1.3
-| Configuration
-| Felix Meschberger
-| Yes
-| Yes
-
-| commons-digester
-| 1.8
-| Digester
-| Felix Meschberger
-| Yes
-| Yes
-
-| commons-el
-| 1.0
-| EL
-| Felix Meschberger
-| Yes
-| Yes
-
-| commons-fileupload
-| 1.1.1
-| FileUpload
-| Felix Meschberger
-| Yes
-| Yes
-
-| commons-httpclient
-| 3.0.1
-| Client-side HTTP.
-| Felix Meschberger
-| Yes
-| Yes
-
-| commons-io
-| 1.3
-| IO
-| Felix Meschberger
-| Yes
-| Yes
-
-| commons-lang
-| 2.2
-| Lang
-| Felix Meschberger
-| Yes
-| Yes
-
-| antlr
-| 2.7.6
-| Parser generator.
-| John Conlon
-| Yes
-| Yes
-
-| commons-collections
-| 3.2
-| Data structures for collections.
-| John Conlon
-| Yes
-| Yes
-
-| jzlib
-| 1.0.7
-| Data compression library.
-| John Conlon
-| Yes
-| Yes
-
-| commons-email
-| 1.0
-| An API for sending email.
-| Felix Meschberger
-| Yes
-| Yes
-|===
-
-== Supporting Libraries
-
-These are projects that have expressed support for the Felix Commons initiative and that are working directly within their respective projects to support OSGi.
-
-| Project | Description | Supporter(s) | More Information | |--|--|--|--| | Spring | | Adrian Colyer, Andy Piper | http://www.springframework.org/osgi[Spring-OSGi] | | SLF4J | | Ceki Gülcü | http://www.slf4j.org/[SLF4J] | | Logback | | Ceki Gülcü | http://logback.qos.ch/[Logback] | | MINA | NIO framework | Trustin Lee | http://issues.apache.org/jira/browse/DIRMINA-27[DIRMINA-27] | | HTTP Client | Client-side HTTP.
-| Roland Weber | https://issues.apache.org/jira/browse/HTTPCLIENT-639[HTTPCLIENT-639] | | Apache OFBiz | Enterprise automation.
-| Christopher Snow | http://mail-archives.apache.org/mod_mbox/incubator-felix-dev/200704.mbox/%3c8A31258D-1FB4-4F42-A145-94136D750EF0@coralms.com%3e[Mailing list archives] | | Jetty | Servlet engine.
-| Jan Bartel | Jetty 6.1.5 and onwards uses the 'maven-bundle-plugin'.|
-
-== Similar Efforts
-
-Eclipse Orbit - http://www.eclipse.org/orbit/ \{quote} ...
-will provide a repository of bundled versions of third party libraries that are approved for use in one or more Eclipse projects.
-\{quote}
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-commons/creating-bundles-using-bnd.adoc b/modules/ROOT/pages/documentation/subprojects/apache-felix-commons/creating-bundles-using-bnd.adoc
deleted file mode 100644
index 3e0c312..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-commons/creating-bundles-using-bnd.adoc
+++ /dev/null
@@ -1,88 +0,0 @@
-= Creating Bundles Using BND
-
-== Purpose
-
-Provide the list of steps required to create a library bundle by wrapping the library jar using bnd (http://bnd.bndtools.org/).
-
-== Steps
-
-. Use bnd to analyze the library jar (e.g., java -jar bnd-0.0.jar print path/to/FOO.jar)
-. At the bottom of the bnd output, look for "Unresolved references to ..." which identify package dependencies.
-If found, a.
-Identifiy the library jars that provide the missing packages b.
-Recursively use this process on each dependency
-. Create a directory that will be the project directory for the bundle (e.g., mkdir FOO-osgi)
-. Copy the template pom.xml file to the bundle's project directory
-. Edit the pom.xml file to tailor it for the library jar.
-Specifically, a.
-change artifactId b.
-verify description c.
-change version d.
-change FOO's library jar dependency (groupId, artifactId) e.
-add any other dependencies (from step 2b) f.
-change Export-Package g.
-change Private-Package or delete it if it's not needed h.
-All packages listed in step 1 should be in either Export-Package or Private-Package.
-Use the library's javadoc to identify the exported packages.
-The remaining packages should be private.
-. Run "mvn package" to in the project directory to create the bundle
-. Use bnd to verify the bundle's contents (e.g., java -jar bnd-0.0.jar print target/FOO-osgi-VERSION.jar)
-. Run "mvn install" to install the bundle in the local repository
-
-== Example POM
-
-[source,xml]
-----
-<project
- xmlns="http://maven.apache.org/POM/4.0.0"
- xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
- xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
-
- <modelVersion>4.0.0</modelVersion>
- <groupId>org.apache.felix.commons</groupId>
- <artifactId>FOO-osgi</artifactId>
- <name>${pom.artifactId} bundle</name>
- <description>
- This bundle simply wraps FOO-${pom.version}.jar.
- </description>
- <version>X.Y</version>
- <packaging>bundle</packaging>
-
- <organization>
- <name>Apache Felix Project</name>
- <url>http://felix.apache.org/</url>
- </organization>
-
- <dependencies>
- <dependency>
- <groupId>FOO</groupId>
- <artifactId>FOO</artifactId>
- <version>${pom.version}</version>
- </dependency>
- </dependencies>
-
- <build>
- <plugins>
- <plugin>
- <groupId>org.apache.felix</groupId>
- <artifactId>maven-bundle-plugin</artifactId>
- <extensions>true</extensions>
- <configuration>
- <instructions>
- <Bundle-SymbolicName>${pom.artifactId}</Bundle-SymbolicName>
- <Export-Package>FOO</Export-Package>
- <Private-Package>FOO.impl</Private-Package>
- </instructions>
- </configuration>
- </plugin>
- </plugins>
- </build>
-
-</project>
-----
-
-== Resources
-
-Bnd - Bundle Tool http://bnd.bndtools.org/
-
-Bundle Plugin for Maven http://felix.apache.org/site/maven-bundle-plugin-bnd.html
[felix-antora-site] 14/18: remove script-console-plugin doc
(unmaintained)
Posted by dj...@apache.org.
This is an automated email from the ASF dual-hosted git repository.
djencks pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/felix-antora-site.git
commit ee60a5195d130c28253198dcbe59ec0e46d0db3a
Author: David Jencks <dj...@apache.org>
AuthorDate: Sun Jul 11 15:51:10 2021 -0700
remove script-console-plugin doc (unmaintained)
---
modules/ROOT/pages/documentation/subprojects.adoc | 2 +-
.../apache-felix-script-console-plugin.adoc | 170 ---------------------
2 files changed, 1 insertion(+), 171 deletions(-)
diff --git a/modules/ROOT/pages/documentation/subprojects.adoc b/modules/ROOT/pages/documentation/subprojects.adoc
index 567554d..7f192ca 100644
--- a/modules/ROOT/pages/documentation/subprojects.adoc
+++ b/modules/ROOT/pages/documentation/subprojects.adoc
@@ -126,7 +126,7 @@ The last documentation may be found in the https://github.com/apache/felix-site-
* https://github.com/apache/felix-site-pub/blob/last-cms/documentation/subprojects/apache-felix-maven-scr-plugin.html[Maven SCR Plugin]
* https://github.com/apache/felix-site-pub/blob/last-cms/documentation/subprojects/mosgi-managed-osgi-framework.html[MOSGi Managed OSGi framework]
* https://github.com/apache/felix-site-pub/blob/last-cms/documentation/subprojects/apache-felix-osgi-core.html[OSGi Core]
-* xref:documentation/subprojects/apache-felix-script-console-plugin.adoc[Script Console Plugin]
+* https://github.com/apache/felix-site-pub/blob/last-cms/documentation/subprojects/apache-felix-script-console-plugin.html[Script Console Plugin]
* xref:documentation/subprojects/apache-felix-serialization-framework.adoc[Serialization Framework]
* xref:documentation/subprojects/apache-felix-upnp.adoc[UPnP]
* xref:documentation/subprojects/apache-felix-user-admin.adoc[User Admin]
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-script-console-plugin.adoc b/modules/ROOT/pages/documentation/subprojects/apache-felix-script-console-plugin.adoc
deleted file mode 100644
index 32d53f3..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-script-console-plugin.adoc
+++ /dev/null
@@ -1,170 +0,0 @@
-= Apache Felix Script Console Plugin
-
-Script Console is a Felix web console plugin which allows evaluation of scripts within the OSGi container.
-It provides following features
-
-* Support evaluation of script in any e.g.
-Groovy, JavaScript, Ruby etc.
-You would need to ensure that relevant language bundle is deployed
-* Code editor with syntax highlighting support based on http://codemirror.net/[CodeMirror] Javascript library
-* Hot key support
-* Execute remote testcase via evaluating test scripts
-
-== Installation
-
-To make use of this plugin you need to
-
-=== A - Install the Script Console Plugin bundle
-
-Refer to http://felix.apache.org/downloads.cgi[downloads] for getting the bundle.
-
-For Maven use following coordinates
-[source,xml]
- <dependency>
- <groupId>org.apache.felix</groupId>
- <artifactId>org.apache.felix.webconsole.plugins.scriptconsole</artifactId>
- <version>1.0.0</version>
- </dependency>
-
-For latest build follow steps below
-
- $svn co https://svn.apache.org/repos/asf/felix/trunk/webconsole-plugins/script-console/
- $cd script-console
- $mvn clean install
- $mvn org.apache.sling:maven-sling-plugin:2.1.0:install -Dsling.url=http://localhost:8080/system/console
-
-=== B- Install the language specific bundle
-
-Install bundles for the Script Language you want to use
-
-* http://repo1.maven.org/maven2/org/codehaus/groovy/groovy-all/2.1.6/groovy-all-2.1.6.jar[Groovy]
-* http://repo1.maven.org/maven2/org/jruby/jruby/1.7.4/jruby-1.7.4.jar[JRuby]
-
-== Usage
-
-After installing it you would see a new tab "Script Console" in Felix Web Console.
-The plugin screen provides a textarea to author script code.
-One can select the language via the given dropdown.
-The generated output is shown in pane below.
-
-The script exposes following variables
-
-* `request` - Current HttpServletRequest instance
-* `response` - Current HttpServletResponse instance
-* `reader` - Direct access to the Reader of the request - same as request.getReader().
-Use it for reading the data of an HTTP request body.
-* `out` - Direct access to the PrintWriter of the response - same as response.getWriter().
-Use it for writing to the HTTP response body.
-* `osgi` - Provides convenience methods for scripts, mainly osgi.getService(foo.bar.Service.class) to retrieve OSGi services available in OSGi Container (Class notation depending on scripting language).
-* `bundleContext` - OSGi BundleContext instance for the script console plugin bundle.
-Can be used to access the OSGi runtime
-
-So simplest script that can work is
-
-[source,groovy]
- out.println ("Hello world!!");
-
-To access a service use `osgi.getService`
-
-[source,groovy]
- def httpService = osgi.getService(org.osgi.service.http.HttpService.class)
-
-To access a service satisfying OSGi filter
-
-[source,groovy]
- def eventPlugin = osgi.getServices(javax.servlet.Servlet.class,'(felix.webconsole.label=events)')[0]
-
-Following hotkeys work
-
-* Ctrl+F9 - Execute the script
-* Ctrl+q - Clear the output
-
-== HTTP API
-
-The plugin can also be invoked by making POST request.
-It supports following parameters
-
-* `code`- Script content.
-Can be norm form data or a multi part content
-* `lang` - Language extension.
- ** Groovy - groovy
- ** JavaScript - esp
-
-If any exception occurs while evaluating the script then it would return the exception message with status set to 500.
-Scripts can control what output they want to emit.
-
-== Sample Scripts
-
-Following are some sample scripts in Groovy.
-Note the scripts might be depending on implementation details to access the relevant data structures
-
-. Script to find out servlets which are registered problematically with Felix HTTP Service
-+
-[source,groovy]
-----
- import org.osgi.service.http.HttpService
- import org.osgi.framework.FrameworkUtil
- import org.osgi.framework.Bundle
-
- def httpService = osgi.getService(HttpService.class)
- httpService.handlerRegistry.aliasMap.each{alias,servlet ->
- Bundle bnd = FrameworkUtil.getBundle(servlet.class)
- println "$alias : ${servlet.class.name} ($bnd.symbolicName)"
- }
-----
-
-. Script to load a class which is not exported and then invoke some static method on that class.
-At times you need to access some private class to see the runtime state.
-+
-[source,groovy]
-----
- import org.osgi.framework.Bundle
- import org.osgi.framework.BundleContext
-
- //Script to load a class which is not exported and then invoke some static method on that class
-
- //Name of the class
- def className = "org.apache.sling.engine.impl.SlingMainServlet"
-
- def resPath = className.replaceAll('.','/')+".class"
- def bundles = bundleContext.getBundles().findAll{Bundle b ->
- b.getEntry(resPath) != null
- }
-
- if(!bundles){
- println "No bundle found for class $className"
- return
- }
-
- def b = bundles.asList().first()
- def clazz = b.loadClass(className)
-
- //Invoke some static method
- def result = clazz.metaClass.invokeStaticMethod(clazz, 'foo', arg1)
- println result
-----
-
-. Script to find out which bundle embeds a given class
-+
-[source,groovy]
-----
- import org.osgi.framework.Bundle
- import org.osgi.framework.BundleContext
-
- //Name of the class
- def className = "org.apache.sling.engine.impl.SlingMainServlet"
-
- def resPath = className.replaceAll('.','/')+".class"
- def bundles = bundleContext.getBundles().findAll{Bundle b ->
- b.getEntry(resPath) != null
- }
-
- println "Following bundles have the class"
- bundles.each{
- println it
- }
-----
-
-== Screenshots
-
-image::documentation/subprojects/script-console-1.png[]
[felix-antora-site] 07/18: remove lightweight http service doc
(unmaintained)
Posted by dj...@apache.org.
This is an automated email from the ASF dual-hosted git repository.
djencks pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/felix-antora-site.git
commit d2d209833a6acccd7ad49ee80fda20aa84ce5bda
Author: David Jencks <dj...@apache.org>
AuthorDate: Sun Jul 11 15:42:19 2021 -0700
remove lightweight http service doc (unmaintained)
---
modules/ROOT/pages/documentation/subprojects.adoc | 2 +-
.../apache-felix-lightweight-http-service.adoc | 30 ----------------------
2 files changed, 1 insertion(+), 31 deletions(-)
diff --git a/modules/ROOT/pages/documentation/subprojects.adoc b/modules/ROOT/pages/documentation/subprojects.adoc
index a05e913..7793f49 100644
--- a/modules/ROOT/pages/documentation/subprojects.adoc
+++ b/modules/ROOT/pages/documentation/subprojects.adoc
@@ -119,7 +119,7 @@ The last documentation may be found in the https://github.com/apache/felix-site-
* https://github.com/apache/felix-site-pub/blob/last-cms/documentation/subprojects/apache-felix-deployment-admin.html[Deployment Admin]
* https://github.com/apache/felix-site-pub/blob/last-cms/documentation/subprojects/apache-felix-ipojo.html[iPOJO]
* https://github.com/apache/felix-site-pub/blob/last-cms/documentation/subprojects/apache-felix-jaas.html[JAAS Support]
-* xref:documentation/subprojects/apache-felix-lightweight-http-service.adoc[Lightweight HTTP Service]
+* https://github.com/apache/felix-site-pub/blob/last-cms/documentation/subprojects/apache-felix-lightweight-http-service.html[Lightweight HTTP Service]
* xref:documentation/subprojects/apache-felix-manifest-generator-mangen.adoc[Manifest Generator (mangen)]
* xref:documentation/subprojects/apache-felix-maven-obr-plugin.adoc[Maven OBR Plugin]
* xref:documentation/subprojects/apache-felix-maven-osgi-plugin.adoc[Maven OSGi Plugin]
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-lightweight-http-service.adoc b/modules/ROOT/pages/documentation/subprojects/apache-felix-lightweight-http-service.adoc
deleted file mode 100644
index 9bce62e..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-lightweight-http-service.adoc
+++ /dev/null
@@ -1,30 +0,0 @@
-= Apache Felix Lightweight HTTP Service
-
-
-
-This is a _minimal_ implementation of the HTTP Service Specification as described in chapter 102 of the OSGi Compendium.
-The goal is to provide a basic HTTP Service for resource-constrained devices and other use cases where the standard HTTP Service may be overkill.
-The bundle requires Java 1.4 or above and implements the Servlet 2.4 API.
-
-== Targets
-
-The Apache Felix Lightweight HTTP Service comes in two targets: core and complete.
-Core provides the minimal server functionality and requires the HTTP Servlet and OSGi HTTP Service APIs to be provided by other bundles at runtime.
-The complete bundle packages these as well and has no external dependencies.
-Currently the complete bundle is about 2x the size of core (55Kb vs 98Kb).
-If space is a concern and the API packages are already provided by other bundles in your environment, the core target makes the most sense.
-However for easy installation and maintenance, the complete bundle may be the better choice.
-
-== Configuration Properties
-
-The service can only be configured using OSGi environment properties.
-The service supports a subset of the standard HTTP Service properties:
-
-* `org.osgi.service.http.port` - The port used for servlets and resources available via HTTP.
-The default is `8080`.
-* `org.apache.felix.http.enable` - Enable or disable the HTTP protocol.
-The default is enabled.
-* `org.apache.felix.https.enable` - Enable or disable the HTTPS protocol.
-Currently the lightweight HTTP Service does not support HTTPS, and setting this to true will only result in a log warning.
-* `felix.log.level` - The log level for messages originating from the bundle.
-The default is 1.
[felix-antora-site] 11/18: remove maven scr plugin doc
(unmaintained)
Posted by dj...@apache.org.
This is an automated email from the ASF dual-hosted git repository.
djencks pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/felix-antora-site.git
commit d7c689634ebc5b157240ff02da29f03a5c40f9c7
Author: David Jencks <dj...@apache.org>
AuthorDate: Sun Jul 11 15:46:14 2021 -0700
remove maven scr plugin doc (unmaintained)
---
modules/ROOT/pages/documentation/subprojects.adoc | 2 +-
.../subprojects/apache-felix-maven-scr-plugin.adoc | 80 ----------------------
2 files changed, 1 insertion(+), 81 deletions(-)
diff --git a/modules/ROOT/pages/documentation/subprojects.adoc b/modules/ROOT/pages/documentation/subprojects.adoc
index 32b2c4d..667865b 100644
--- a/modules/ROOT/pages/documentation/subprojects.adoc
+++ b/modules/ROOT/pages/documentation/subprojects.adoc
@@ -123,7 +123,7 @@ The last documentation may be found in the https://github.com/apache/felix-site-
* https://github.com/apache/felix-site-pub/blob/last-cms/documentation/subprojects/apache-felix-manifest-generator-mangen.html[Manifest Generator (mangen)]
* https://github.com/apache/felix-site-pub/blob/last-cms/documentation/subprojects/apache-felix-maven-obr-plugin.html[Maven OBR Plugin]
* https://github.com/apache/felix-site-pub/blob/last-cms/documentation/subprojects/apache-felix-maven-osgi-plugin.html[Maven OSGi Plugin]
-* xref:documentation/subprojects/apache-felix-maven-scr-plugin.adoc[Maven SCR Plugin]
+* https://github.com/apache/felix-site-pub/blob/last-cms/documentation/subprojects/apache-felix-maven-scr-plugin.html[Maven SCR Plugin]
* xref:documentation/subprojects/mosgi-managed-osgi-framework.adoc[MOSGi Managed OSGi framework]
* xref:documentation/subprojects/apache-felix-osgi-core.adoc[OSGi Core]
* xref:documentation/subprojects/apache-felix-script-console-plugin.adoc[Script Console Plugin]
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-maven-scr-plugin.adoc b/modules/ROOT/pages/documentation/subprojects/apache-felix-maven-scr-plugin.adoc
deleted file mode 100644
index 2c2f271..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-maven-scr-plugin.adoc
+++ /dev/null
@@ -1,80 +0,0 @@
-= Apache Felix Maven SCR Plugin
-
-NOTE: While the Apache Felix Maven SCR Plugin is a great tool (see below), for developing OSGi components using Declarative Services you should use the official annotations from the OSGi R6 specification.
-The development of the Apache Felix SCR Plugin is in maintenance mode.
-
-The Apache Felix Maven SCR Plugin is a great tool to ease the development of OSGi components and services.
-Components and services are defined through annotations and the plugin creates the necessary descriptors for the OSGi Declarative Services, Config Admin and Metatype services.
-Recent versions of the plugin support OSGi Declarative Services versions 1.0, 1.1, and 1.2.
-
-Make sure to see the xref:documentation/faqs/apache-felix-scr-plugin-faq.adoc[FAQ] for known problems.
-
-== Introduction
-
-In OSGi based systems functionality is mainly provided through services.
-Unlike traditional systems but comparable to Spring, a service is not reqiured to implement a framework defined interface.
-Instead services implement one or more interfaces, which stipulate the type of service provided.
-It is the lifetime of the bundle, which defines the lifetime of the service: A service object may be instantiated when the bundle is started and will automatically be removed when the bundle is stopped (and the service has not already been unregistered).
-
-Usually, the functionality of a bundle - be it the packages exported or be it the services provided - is made available to the rest of the system, when the bundle is started.
-To give the bundle a change to take action, a bundle may declare a `BundleActivator` class in the `Bundle-Activato` manifest header of the bundle.
-When the bundle is started, the `start(BundleContext)` method is called, while the `stop(BundleContext)` method is called when the bundle is stopped.
-These methods are one place to instantiate and register services with the service registry.
-
-The drawback of this method of service registration is that the services have to acquire other services whose functionality is used themselves and also have to observe the presence as services may come and go at any time.
-Though this observation is rather easy as basically a `ServiceListener` is to be implemented which listens for service registration and unregistration events, this is somewhat tedious and repeating for each service using other services.
-
-To overcome this situation, the OSGi Service Platform Compendium Specification provides the _Declarative Services Specification_.
-This specification enables the declaration of services in configuration files, which are read by the _Declarative Services Runtime_ to observe dependencies and activate (register) and deactivate (unregister) services depending on whether requirements can be met.
-Additionally, the dependencies may be supplied through declared methods.
-The specification calls a class declared this way a component.
-A component may or may not be a service registered with the service registry.
-
-Components are declared using XML configuration files contained in the respective bundle and listed in the `Service-Component` bundle manifest header.
-These configuration files may be handwritten and registered.
-To support automatic generation of the component descriptors, the Maven SCR Plugin helps in the generation of these files by means of JavaDoc tags embedded in the Java source code of the components.
-
-Related to declarative services is configuration support.
-To support configuration of services and components, OSGi provides the Configuration Admin Service Specification.
-This specification defines a service, which is the center of providing configuration to services and components.
-As such the Configuration Admin Service cares for storing configuration and deliver the configuration automatically or on-demand to clients.
-Configuration objects are identified by so-called Persistent Identifiers (PID) and are bound to bundles when used.
-For services implementing the special `ManagedService` or `ManagedServiceFactory` interfaces the PID has to be provided in the service properties as a property with the name `service.pid`.
-For Declarative Services, the name of the component is used as the PID to retrieve the configuration from the Configuration Admin Service.
-
-The Configuration Admin Service not only allows components to get or retrieve configuration, it also provides the entry point for Management Agents to retrieve and update configuration data.
-To help building Management Agents the OSGi Metatype Service Specification defines a descripton model which may be used to describe data used by components and services.
-The configuration properties and meta type description for a given PID together are used to build the user interface to configure the service and/or component.
-
-To summarize:
-
-. _Declarative Services_ provides a means to define components (and services) through one or more XML files.
-Each component may get default configuration from its own definition.
-. The _Configuration Admin Service_ provides functionality to provide configuration to components and services as well as to support management tools to update (and create) configuration data.
-. The _Metatype Service_ provides a description suitable for management tools to manage configurations provided by the Configuration Admin Service.
-The descriptions of the data is provided in one or more XML files and associated languag binding files.
-
-== Where to go from here
-
-* xref:documentation/subprojects/apache-felix-maven-scr-plugin/apache-felix-maven-scr-plugin-use.adoc[]
-* xref:documentation/subprojects/apache-felix-maven-scr-plugin/apache-felix-scr-ant-task-use.adoc[]
-* xref:documentation/subprojects/apache-felix-maven-scr-plugin/apache-felix-scr-bndtools-use.adoc[]
-* xref:documentation/subprojects/apache-felix-maven-scr-plugin/scr-annotations.adoc[]
-* xref:documentation/subprojects/apache-felix-maven-scr-plugin/scr-javadoc-tags.adoc[]
-* xref:documentation/subprojects/apache-felix-maven-scr-plugin/extending-scr-annotations.adoc[]
-
-== Differences between JavaDoc tags and annotations
-
-In general both mechanisms provide the same functionality.
-There are some subtle difference which are listed in this section:
-
-* JavaDoc tags are not supported in recent versions of the plugin, support has been removed with version 1.8.0.
-New features will only be implemented as annotations.
-* While the `metatype` flag is turned on by default for the JavaDoc tags, the default for the annotations is to generate no metadata.
-The reason for this is, that it turned out that services with metadata are less often used.
-* The JavaDoc support adds properties and references from super classes if the source is in the same module to a component even if the super class does not have the `@scr.component` tag.
-With the annotations the super class is required to have the `Component` annotation.
-* Property values are handled differently.
-While the JavaDoc version has an auto detection of types together with an explicit type parameter, the annotations version has several attributes.
-Each type has its own attribute (like `shortValue`, `intValue` and so on).
-This is because of a limitation in the Java annotations which only allow typed parameters.
[felix-antora-site] 13/18: remove osgi-core doc (unmaintained)
Posted by dj...@apache.org.
This is an automated email from the ASF dual-hosted git repository.
djencks pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/felix-antora-site.git
commit 7485f26efae522774fbf01eef54cb08f1c10592f
Author: David Jencks <dj...@apache.org>
AuthorDate: Sun Jul 11 15:49:53 2021 -0700
remove osgi-core doc (unmaintained)
---
modules/ROOT/pages/documentation/subprojects.adoc | 2 +-
.../ROOT/pages/documentation/subprojects/apache-felix-osgi-core.adoc | 5 -----
2 files changed, 1 insertion(+), 6 deletions(-)
diff --git a/modules/ROOT/pages/documentation/subprojects.adoc b/modules/ROOT/pages/documentation/subprojects.adoc
index ce7c83c..567554d 100644
--- a/modules/ROOT/pages/documentation/subprojects.adoc
+++ b/modules/ROOT/pages/documentation/subprojects.adoc
@@ -125,7 +125,7 @@ The last documentation may be found in the https://github.com/apache/felix-site-
* https://github.com/apache/felix-site-pub/blob/last-cms/documentation/subprojects/apache-felix-maven-osgi-plugin.html[Maven OSGi Plugin]
* https://github.com/apache/felix-site-pub/blob/last-cms/documentation/subprojects/apache-felix-maven-scr-plugin.html[Maven SCR Plugin]
* https://github.com/apache/felix-site-pub/blob/last-cms/documentation/subprojects/mosgi-managed-osgi-framework.html[MOSGi Managed OSGi framework]
-* xref:documentation/subprojects/apache-felix-osgi-core.adoc[OSGi Core]
+* https://github.com/apache/felix-site-pub/blob/last-cms/documentation/subprojects/apache-felix-osgi-core.html[OSGi Core]
* xref:documentation/subprojects/apache-felix-script-console-plugin.adoc[Script Console Plugin]
* xref:documentation/subprojects/apache-felix-serialization-framework.adoc[Serialization Framework]
* xref:documentation/subprojects/apache-felix-upnp.adoc[UPnP]
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-osgi-core.adoc b/modules/ROOT/pages/documentation/subprojects/apache-felix-osgi-core.adoc
deleted file mode 100644
index f30b816..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-osgi-core.adoc
+++ /dev/null
@@ -1,5 +0,0 @@
-= Apache Felix OSGi Core
-
-The Apache Felix OSGi Core sub-project simply repackages the standard OSGi core API packages provided by the OSGi Alliance into a Maven module.
-Nearly all OSGi-related projects will have a dependency on this module if using Maven or will require this module's JAR file in its class path in order to compile against the OSGi core APIs.
-The Felix framework has a compile-time dependency on the OSGi core module, but at packaging time it embeds the specific set of required packages so there is no longer a dependency on the module at execution time.
[felix-antora-site] 12/18: remove mosgi doc (unmaintained)
Posted by dj...@apache.org.
This is an automated email from the ASF dual-hosted git repository.
djencks pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/felix-antora-site.git
commit 32127876e8a3db618b0969334f70715acf0fab7e
Author: David Jencks <dj...@apache.org>
AuthorDate: Sun Jul 11 15:47:51 2021 -0700
remove mosgi doc (unmaintained)
---
modules/ROOT/pages/documentation/subprojects.adoc | 2 +-
.../subprojects/mosgi-managed-osgi-framework.adoc | 108 -------------
.../mosgi-managed-osgi-framework/probeguide.adoc | 180 ---------------------
3 files changed, 1 insertion(+), 289 deletions(-)
diff --git a/modules/ROOT/pages/documentation/subprojects.adoc b/modules/ROOT/pages/documentation/subprojects.adoc
index 667865b..ce7c83c 100644
--- a/modules/ROOT/pages/documentation/subprojects.adoc
+++ b/modules/ROOT/pages/documentation/subprojects.adoc
@@ -124,7 +124,7 @@ The last documentation may be found in the https://github.com/apache/felix-site-
* https://github.com/apache/felix-site-pub/blob/last-cms/documentation/subprojects/apache-felix-maven-obr-plugin.html[Maven OBR Plugin]
* https://github.com/apache/felix-site-pub/blob/last-cms/documentation/subprojects/apache-felix-maven-osgi-plugin.html[Maven OSGi Plugin]
* https://github.com/apache/felix-site-pub/blob/last-cms/documentation/subprojects/apache-felix-maven-scr-plugin.html[Maven SCR Plugin]
-* xref:documentation/subprojects/mosgi-managed-osgi-framework.adoc[MOSGi Managed OSGi framework]
+* https://github.com/apache/felix-site-pub/blob/last-cms/documentation/subprojects/mosgi-managed-osgi-framework.html[MOSGi Managed OSGi framework]
* xref:documentation/subprojects/apache-felix-osgi-core.adoc[OSGi Core]
* xref:documentation/subprojects/apache-felix-script-console-plugin.adoc[Script Console Plugin]
* xref:documentation/subprojects/apache-felix-serialization-framework.adoc[Serialization Framework]
diff --git a/modules/ROOT/pages/documentation/subprojects/mosgi-managed-osgi-framework.adoc b/modules/ROOT/pages/documentation/subprojects/mosgi-managed-osgi-framework.adoc
deleted file mode 100644
index 0e4b4a0..0000000
--- a/modules/ROOT/pages/documentation/subprojects/mosgi-managed-osgi-framework.adoc
+++ /dev/null
@@ -1,108 +0,0 @@
-= MOSGi Managed OSGi framework
-
-MOSGi enables the remote management of OSGi-compatible service gateways, using JMX.
-The framework is a reference architecture for end-to-end gateway management.
-It provides the following features:
-
-* relies on JMX management infrastructure (IP-based management),
-* provides two JMX agents: the standard Java 1.5 agent and a specific Java 1.4 lightweight embedded agent (MX4J agent deviation),
-* provides a way to deploy various probes on remote gateways,
-* provides a management console,
-* the graphical part of a probe (management console part) can be dynamically plugged in the management console and is dynamically downloaded.
-
-== Very fast QuickStart Guide
-
-Go into $FELIX_HOME/trunk/mosgi.doc and read Readme.txt.
-
-== General architecture
-
-The overall architecture is presented in the following picture :
-
-!MOSGiArchitecture.png!
-
-== How it works
-
-Managed OSGi gateways can install JMX probes from various repositories.
-A JMX probe is a standard OSGi bundle that registers an xref:#_mbean_definition[#MBean] component in the managed gateway's JMX agent.
-
-The management console (running in a standard OSGi framework) is connected to each gateway through the JMX remoting protocol.
-When it connects for the first time to a managed gateway, it asks for probes that are installed (i.e.
-all MBeans registered in the TabUI JMX domain).
-Then, for each MBean found, the management console asks for its graphical representation through a call to our standard API (component getUI() call).
-This call redirects to a bundle in the GUI probe repository that is installed by the management console.
-So the management console discovers at run-time the user interface it should use to supervise a specific remote gateway.
-
-Here is a description of different bundles that should be installed on both parts of the infrastructure (managed OSGi gateway and Management console).
-
-A managed OSGi gateway must host the following bundles :
-
-* JMX-MX4J Agent Service: provides a JMX agent.
-Either through a wrapper to jdk1.5 standard agent or through using a specific lightweight inner agent1 (originate from mx4j project).
-This agent service also declares a standard MBeanServer service interface..
-* JMX rmiregistry: wraps RMI registry life cycle.
-It's used by the JMX remoting infrastructure to register
-* JMX RMI connector: wraps a standard JMX remoting RMI connector
-* Remote Logger: notifies log informations
-
-A JMX Console is an OSGi framework also (for simplicity) which should host two bundles :
-
-* JMX Console: the graphical framework that will host graphical plugins
-* jmxconsole common tabs: tabs that are common to all gateways.
-For the moment it only concerns a tab that shows remote notification (it works whith remote logger)
-
-== OSGi/JMX MBean registration
-
-MOSGi installs JMX-MX4J agent at the gateways level.
-Any one can register an MBean to the JMX agent.
-The registration can be made in two ways.
-The direct code and the white board pattern.
-
-* In the direct code, one can register an MBean to the agent through the standard service interface : _javax.management.MBeanServer_
-
-Example:
-
- org.osgi.framework.ServiceReference sr == context.getServiceReference(javax.management.MBeanServer.class.getName());
- javax.management.MBeanServer mbs=(javax.management.MBeanServer)context.getService(sr);
- mbs.registerMBean(new MBeanImpl(), new ObjectName("Foo:FooName");
-
-Exemple of such code is uses in _mosgi.managedelements.bundlesprobes_ code in felix repository
-
-* In the whiteboard pattern, one can register an MBean through registering its interface to the framework as a service.
-If the interface name ends with MBean or if the interface is _javax.management.DynamicMBean_, the agent will automatically register the implementation as a standard MBean.
-The objectName of the MBean can either be defined at registration time with the _org.apache.felix.mosgi.jmx.agent.Constants.OBJECTNAME_ property name or automatically build through introspection.
-
-Example:
-
- java.util.Properties prop=new java.util.Properties();
- prop.add( org.apache.felix.mosgi.jmx.agent.Constants.OBJECTNAME, "Foo:FooName");
- context.registerService(test.FooMBean.class.getName(), new test.Foo(), prop);
-
-== Management Console
-
-The management console is a ad-hoc jmx compatible console.
-Its aim is not to be a concurrent to general purpose consoles like MX4J or JConsole but provides an ad-hoc user interface depending on the managed gateway.
-The console is based on a plugin framework.
-Each time the consol connects to a gateway it gets the list of available MBean.
-Then for each registered MBean it asks for specific local bundles for managing it.
-Each graphical bundle is integrated as a graphical tab in the management console.
-
-In the next screenshot, the gateway user has deployed 4 probes on the remote gateway : Remote Obr, Remote Bundle List, GNU/Linux and OSGi Plateform.!jmxconsoleGUI.png!
-
-In order to get these tabs, the gateway manager deploys the 4 probe bundles on the remote gateway and GUI tabs are automatically made available to the remote console.
-These bundles are :
-
-* ObrProbe : a probe that enables interaction with obr for bundle deployment
-* BundleProbe : a probe that enables the bundle life-cycle management
-* GNU-Linux : a probe that gets status from running host operating system
-* OSGi Platform : a probe that gets information from current running gateway
-
-These plugin are developed as simple examples and are available in felix repository.
-A xref:documentation/subprojects/mosgi-managed-osgi-framework/probeguide.adoc[ProbeGuide] that describes plugin integration is available.
-Plugin are dynamically removed and reinstalled each time you change your selected gateway.
-
-[discrete]
-==== MBean Definition
-
-An MBean is a Management Component for the JMX framework.
-It is made of an MBean interface and an implementation of it.
-The MBean interface is used to make remote management with the implementation.
diff --git a/modules/ROOT/pages/documentation/subprojects/mosgi-managed-osgi-framework/probeguide.adoc b/modules/ROOT/pages/documentation/subprojects/mosgi-managed-osgi-framework/probeguide.adoc
deleted file mode 100644
index b491123..0000000
--- a/modules/ROOT/pages/documentation/subprojects/mosgi-managed-osgi-framework/probeguide.adoc
+++ /dev/null
@@ -1,180 +0,0 @@
-= Developing probes for MOSGi framework
-
-\{quote}
-
-\{quote} MOSGi is a management infrastructure for OSGi gateways remote management.
-The architecture relies on JMX management infrastructure and is classically build on a three layered system:
-
-!ManagementLayers.png!
-
-* The probe layer: are low layer elements that drive the gateway.
-They can either get information from the gateway (gateway status) or set information on it (install a bundle),
-* The Agent layer: there is one agent per gateway and is responsible for maintaining access to a list of available probes,
-* The Manager layer is the remote environment that can communicate with the agent to get information from the gateway through the probes
-
-There are various way to implements this architecture (CIM/Wbem, Snmp, JMX).
-We have choose to use the JMX proposal because it is standardized in the java virtual machine since jdk1.5.
-
-== JMX management infrastructure synthesis
-
-Sun JMX proposal defines the following elements :
-
-!JMXLayers.png!
-
-* The agent is the registry for probes called MBeans and is accessed through connectors.
-* MBeans are java objects that register themselves to the agent under some name
-* Connectors are end points were external managers can communicate with.
-There are currently two available connectors : an xml/http connector and a rmi based connector.
-We are using the rmi connector (JSR160).
-
-In the JMX world probes are represented as MBeans.
-They are java singleton object that declare a single interface to the agent.
-This interface is registered under a unique name within the agent namespace.
-The JMX namespace is structured as a domainname:mbeanname unique name.
-The following html page represents an example of this kind of namespace (we use the httpconnector connector with the agent to get this information).
-
-!jmxmx4jhtml.png!
-
-These are various mbeans deployed on a specific gateway.
-We can identify 4 columns : the mbean registered name (and domain), its implementation, a comment and a function to unregister it.
-
-Mbeans are component that declare a management interface that should have a syntactic name similar to the class they instrument.
-For instance the class foo.Test should implement a management interface whose name is foo.TestMBean.
-The registration mechanism associates a implementation (conform to the management interface) with an objectName (a unique identifier).
-The corresponding call is something like :aMbeanServer.register(aMBeanImplementation, anObjectName);.
-There are many kinds of MBeans (standard, dynamic, model and simple) but their description is out of the scope of this document.
-
-== MOSGi probe developpement
-
-Our management infrastructure proposes a framework for deploying standard mbean within OSGi gateways.
-It also embeds a reference to a graphical part (manager view) directly in the Mbean itself.
-Thus the management console is automatically populated with client part of the management system.
-
-=== Gateway probes
-
-These probes are developed in conformance to the following elements.
-
-* A probe must be registered under the domain TabUI.
-It means that they will have a corresponding tab in our management console.
-* A probe must implement a management interface conform to the JMX specification (ie : foo.LinuxProbe -\-> foo.LinuxProbeMBean)
-* The management interface must extend TabIfc (which declares a single method : getBundleName()).
-This methods returns an url were the management console should find a tab that can establish a management dialog with the probe.
-* The probe is made available as a standard OSGi Mbean that will make its registration during the bundleActivator start method.
-
-The following picture illustrates relations between these elements.
-
-!MOSGiProbeClasses.png!
-
-For instance a Probe that declares a single management function _int getValue()_;should provide the following interface:
-
- package foo;
- import insa.jmxconsole.gui.service.TabIfc;
- public interface ProbeMBean extends TabIfc {
- public int getValue();
- }
-
-And the following class:
-
-----
-package foo;
-import org.osgi.framework.BundleActivator;
-import org.osgi.framework.BundleContext;
-import org.osgi.framework.ServiceReference;
-import insa.jmxconsole.gui.service.TabIfc;
-import javax.management.MBeanServer;
-public class Probe implements BundleActivator,ProbeMBean{
- //////////////////////////////////////////
- // BundleActivator Interface //
- //////////////////////////////////////////
- /* The probe lifecycle is linked to the bundle lifecycle */
- public void start(BundleContext bc){
- /* Here we register the Mbean within the agent */
- ServiceReference sr = context.getServiceReference(MBeanServer.class.getName());
- if (sr!=null){
- MBeanServer server = (MbeanServer)this.bc.getService(sr);
- server.registerMBean(this, new ObjectName("TabUI:name=Probe");
- }
- }
- public void stop(BundleContext bc){...}
- ///////////////////////////
- // Management interface //
- ///////////////////////////
- public int getValue(){return 10;}
-
- /* A getIfc function comes from RemoteIfc interface that enable the manager (remote console) to
- a bundle that can communicate whith this probe from a remote URL */
- public String getBundleName(){
- return "http://somewhere/agraphicaltab.jar"
- }
-}
-----
-
-Once the probe is made as a bundle it can be deployed on the remote gateway.
-Then a manager (management console) can ask communicate with the gateway agent to manage the probe.
-
-=== MOSGi JmxConsole architecture
-
-When a probe is deployed on a remote gateway it is manageable by standard management consoles like JConsole, MC4J...
-We have developed our own management console that is able to manage probe in a more dedicated approach.
-
-The management console is based on a plugin mechanism.
-Each plugin is represented as a tab and each tab manages a probe.
-The console is launched with two bundles.
-Remotegui.jar is the execution framework and remotecomponent.jar contains a sole remote logger service that gets remote notification from gateways.
-The screen represented the gateway status after it has been launched.!EmptyConsole.png!
-The left panel identifies connected gateways, The upper center panel is an container for tabs from managed gateways,
-
-The lower center panel contains the remote logger display that shows notifications from remote gateways.
-When the user selects a gateway (green flag) the console will do the following actions :
-
-. Ask all MBeans in the TabUI domain.
-. For each of these MBean, get the URL of bundle that provides the tab.
-This is done through the call to getBundleName( ) method in RemoteIfc interface.
-. Install the bundle on the gateway
-
-For instance if the user selects the green point he gets the following tabs.
-
-!TabbedConsole.png!
-
-4 probes have been deployed on the remote gateway and 4 graphical tabs have been installed.
-
-=== Graphical tab integration
-
-When developing a probe one shall provide a corresponding MOSGi tab.
-It should follow these guidelines.
-
-* It should be a bundle in order to be remotely installed on the console
-* It should implement Plugin interface with is the jmxconsole container interface specification.
-
-The plugin is mainly conform to the java beans specification development.
-The jmxconsole acts as a bean container and each tab is a bean in this infrastructure.
-This is the general architecture of a Tab class.!MOSGiConsoleTabClasses.png!
-
-The plugin interface has the following structure:
-
- package insa.jmxconsole.gui.service;
- import java.awt.Component;
- import java.beans.PropertyChangeListener;
- public interface Plugin extends PropertyChangeListener{
- public String getName(); /* The name of the tab */
- public Component getGUI(); /* This is called by the container to get the graphical component */
- public void registerServicePlugin(); /* This is called by the framework when a new gateway is selected */
- public void unregisterServicePlugin();
- /* see before */
- public String pluginLocation(); /* This a unique identifier of the plugin */
- /* These are constants that enable communication between container and plugins. They are treated in the
- propertyChange function brought by the javabean API */
- public static final String NEW_NODE_SELECTED="newNodeSelected";
- public static final String NEW_NODE_READY="newNodeReady";
- public static final String NEW_NODE_CONNECTION="newNodeConnection";
- public static final String EMPTY_NODE="emptyNode";
- public static final String PLUGIN_ADDED="pluggin_added";
- public static final String PLUGIN_REMOVED="pluggin_removed";
- }
-
-Implementation tabs are provided as open-source code.
-You can find various implementation of this interface in felix repository in the _mosgi.managedelements.xxx.tab_ elements.
-
-=== Function call sequence
-
-The next figure presents a function call sequence when using MOSGi framework.
[felix-antora-site] 15/18: remove serialization framework doc
(unmaintained)
Posted by dj...@apache.org.
This is an automated email from the ASF dual-hosted git repository.
djencks pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/felix-antora-site.git
commit 000b8367bd0af2f51367c2db2c4a6959c4efc66c
Author: David Jencks <dj...@apache.org>
AuthorDate: Sun Jul 11 15:51:55 2021 -0700
remove serialization framework doc (unmaintained)
---
modules/ROOT/pages/documentation/subprojects.adoc | 2 +-
.../apache-felix-serialization-framework.adoc | 45 ----------------------
2 files changed, 1 insertion(+), 46 deletions(-)
diff --git a/modules/ROOT/pages/documentation/subprojects.adoc b/modules/ROOT/pages/documentation/subprojects.adoc
index 7f192ca..b125e82 100644
--- a/modules/ROOT/pages/documentation/subprojects.adoc
+++ b/modules/ROOT/pages/documentation/subprojects.adoc
@@ -127,6 +127,6 @@ The last documentation may be found in the https://github.com/apache/felix-site-
* https://github.com/apache/felix-site-pub/blob/last-cms/documentation/subprojects/mosgi-managed-osgi-framework.html[MOSGi Managed OSGi framework]
* https://github.com/apache/felix-site-pub/blob/last-cms/documentation/subprojects/apache-felix-osgi-core.html[OSGi Core]
* https://github.com/apache/felix-site-pub/blob/last-cms/documentation/subprojects/apache-felix-script-console-plugin.html[Script Console Plugin]
-* xref:documentation/subprojects/apache-felix-serialization-framework.adoc[Serialization Framework]
+* https://github.com/apache/felix-site-pub/blob/last-cms/documentation/subprojects/apache-felix-serialization-framework.html[Serialization Framework]
* xref:documentation/subprojects/apache-felix-upnp.adoc[UPnP]
* xref:documentation/subprojects/apache-felix-user-admin.adoc[User Admin]
diff --git a/modules/ROOT/pages/documentation/subprojects/apache-felix-serialization-framework.adoc b/modules/ROOT/pages/documentation/subprojects/apache-felix-serialization-framework.adoc
deleted file mode 100644
index f0a893f..0000000
--- a/modules/ROOT/pages/documentation/subprojects/apache-felix-serialization-framework.adoc
+++ /dev/null
@@ -1,45 +0,0 @@
-= Apache Felix Serialization Framework
-
-== Problem
-
-When you have an object graph that consists of objects that were created by different bundles, serializing and deserializing such a graph becomes a problem, since there is no single bundle that can "see" all (implementation) objects in the graph.
-
-The problem manifests itself for example in Apache Wicket, but also in other applications.
-The serialization framework is a solution to this problem.
-
-== Design discussion sketch
-
-Made at ApacheCon EU 2009, Robert, Martijn, Felix and Marcel produced the following design on the flipover:
-
-[cols=2*]
-|===
-| !sf_design.jpg
-| thumbnail!
-|===
-
-== Service design
-
-Basically, we need two services:
-
-. The serialization service, that can serialize and deserialize an object graph to an output or input stream.
-. Helpers that are used to (de)serialize specific objects.
-
-=== Serialization Service
-
- interface SerializationService {
- void serialize(Object o, OutputStream s) throws IOException, UnknownObjectException;
- Object deserialize(InputStream s) throws IOException, UnknownObjectException;
- }
-
-The actual implementation of this service determines how objects are serialized.
-
-=== Serialization Helper
-
- interface SerializationHelper {
- // TODO
- }
-
-We also discussed adding a special manifest header to a bundle to create a sort of declarative serialization helper.
-That way the bundle does not need to implement and register the service (if all of them use the same helper anyway).
-
-Helpers in some way need to be linked to a specific serialization service (using an XML serialization with a JSON helper will probably not be what you want).