Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Jackrabbit Wiki" for change notification.

The "JackrabbitOsgi" page has been changed by FelixMeschberger.
http://wiki.apache.org/jackrabbit/JackrabbitOsgi?action=diff&rev1=2&rev2=3

--------------------------------------------------

    * Provide some degree of dynamic extensibility (at least provide the pluggability currently supported by the Sling Jackrabbit Server bundle)
  
  
- === Jackrabbit Core Bundle and Embedded Dependencies ===
+ ==== Jackrabbit Core Bundle and Embedded Dependencies ====
  
  The biggest issue when bundelizing the Jackrabbit Core bundle is the is the list of dependencies and extensibility. 
  
@@ -52, +52 @@

  The current approach followed in the [[http://svn.apache.org/repos/asf/jackrabbit/sandbox/jackrabbit2-bundle|Jackrabbit 2 Bundle Sandbox]] is to embed libraries, which are not available as bundles and to not embed libraries available as bundles.
  
  
- === Easy Startup and Access ===
+ ==== Easy Startup and Access ====
  
  For easy startup and access the OSGi specification offers great functionalities: To startup an embedded repository instance, we need a location to store the filesystem data to and a location to access a configuration. Both properties can easily be provided through the OSGi Configuration Admin Service. This is what we do in the Sling Jackrabbit Server bundle and thus this is also implemented in the current approach.
  
@@ -63, +63 @@

  As for the configuration file: The Jackrabbit Core library contains a default repository.xml file ({{{OSGI-INF/repository_osgi.xml}}}) which is used as a configuration file if none is provided.
  
  
- === Extensibility ===
+ ==== Extensibility ====
  
  
  Jackrabbit configuration is the subject of a book of its own. Yet some things may be setup rather dynamically in the sense of extensible at runtime by the system administrator. Things in this area, we have at the moment in the Sling Jackrabbit Server bundle are a framework to extend login modules and a support to plugin extensible access controllers.
  
  Both should, if possible, be migrated to the Jackrabbit Core bundle; possibly even enhancing it. Of course such extensibility points will have to be exported from the Jackrabbit Core bundle and as such will be placed into separate locations.
  
+ 
+ 
+ == Pluggable LoginModule ==
+ 
+ The goal of a pluggable login module system is to provide a simple means to extend the functionality of the {{{DefaultLoginModule}}} which is part of the internal API (but is one of those things, which cannot easily be exported without exposing internal implementation). One major use case of such pluggable login module functionality is to account for authentication mechanisms which require more than just the final {{{SimpleCredentials}}} class but otherwise would benefit from all the {{{Principal}}} resolution support of the {{{DefaultLoginModule}}}.
+ 
+ The {{{PluggableDefaultLoginModule}}} overwrites the following methods of the {{{DefaultLoginModule}}} and the {{{AbstractLoginModule}}}:
+ 
+  doInit:: Locates a login module plugin which is capable of handling the credentials provided in the {{{Repository.login}}} method.
+  commit:: Allows the login module plugin to properly cleanup after a successful login attempt
+  abort:: Allows the login module plugin to properly cleanup after a failed login attempt
+  supportsCredentials:: Locates a login module plugin which is capable of handlig the credentials. If none can be found, the base class implementation is called.
+  getUserID:: Overwrites the {{{AbstractLoginModule}}} implementation to check whether one of the plugins can provide the user ID for the given credentials. If not the base class implementation is called.
+  getPrincipal:: Overwrites the {{{DefaultLoginModule}}} implementation to check whether one of the plugins can provide a Principal. If not the base class implementation is called.
+  getPrincipals:: Calls base class implementation to get the base set of principals and the calls the currently used plugin to add further prinicipals and returns the completed set.
+  authenticate:: Calls the authenticate method of the plugin handling the given credentials and returns {{{true}}}. If no plugin can handle the credentials the result of calling the base class implementation is returned. If the plugin fails to authenticate the credentials for the principal a {{{FailedLoginException}}} is thrown.
+  impersonate:: Calls the impersonate method of the plugin handling the given credentials and returns {{{true}}} or {{{false}}} if the plugin handles impersonation. If no plugin can handle the credentials or the selected plugin does not handle impersonation the result of calling the base class implementation is returned. If impersonation either by the plugin or the base class implementation fails a {{{FailedLoginException}}} is thrown.
+ 
+ 
+ Because login modules are created for each login request and may keep internal state while handling the login request, the service API for pluggable login modules defines a factory interface:
+ 
+ 
+ 
+ 
+ == Pluggable Access Control Manager ==
+ 
+ TBD
+