Modified: jackrabbit/site/live/oak/docs/dev_getting_started.html URL: http://svn.apache.org/viewvc/jackrabbit/site/live/oak/docs/dev_getting_started.html?rev=1535337&r1=1535336&r2=1535337&view=diff ============================================================================== --- jackrabbit/site/live/oak/docs/dev_getting_started.html (original) +++ jackrabbit/site/live/oak/docs/dev_getting_started.html Thu Oct 24 10:42:02 2013 @@ -1,436 +1,436 @@ - - - - - - - - - Jackrabbit Oak - - - - - - - - - - - - - - - - - - - Fork me on GitHub - - - - - - - - - -
- - - - - -
-
- -
- - -
- -
-

Getting Started

-

Many parts of Oak are still under construction, so it may be a bit difficult to find your way around the codebase. The README files, the Jackrabbit 3 wiki page, and the Oak mailing list archives are good places to start learning about Oak.

-

To get started developing Oak, build the latest sources with Maven 3 and Java 6 (or higher) like this:

- -
-
mvn clean install
-
-

To enable all integration tests, including the JCR TCK, use:

- -
-
mvn clean install -PintegrationTesting
-
-

Before committing changes or submitting a patch, please make sure that the above integration testing build passes without errors. If you like, you can enable integration tests by default by setting the OAK_INTEGRATION_TESTING environment variable.

-
-

MongoDB integration

-

Parts of the Oak build expects a MongoDB instance to be available for testing. By default a MongoDB instance running on localhost is expected, and the relevant tests are simply skipped if such an instance is not found. You can also configure the build to use custom MongoDB settings with the following properties (shown with their default values):

- -
-
-Dmongo.host=127.0.0.1
--Dmongo.port=27017
--Dmongo.db=MongoMKDB
--Dmongo.db2=MongoMKDB2
-
-

Note that the configured test databases will be dropped by the test cases.

-
-

Components

-

The build consists of the following main components:

- -
    - -
  • oak-parent - parent POM
  • - -
  • oak-doc - Oak documentation
  • - -
  • oak-commons - shared utility code
  • - -
  • oak-mk-api - MicroKernel API
  • - -
  • oak-mk - default MicroKernel implementation
  • - -
  • oak-mk-remote - MicroKernel remoting
  • - -
  • oak-core - Oak repository API and implementation
  • - -
  • oak-jcr - JCR binding for the Oak repository
  • - -
  • oak-sling - integration with Apache Sling
  • - -
  • oak-solr-core - Apache Solr indexing and search
  • - -
  • oak-solr-embedded - Apache Solr on an embedded Solr instance
  • - -
  • oak-solr-remote - Apache Solr on an remote (HTTP) Solr instance
  • - -
  • oak-http - HTTP binding for Oak
  • - -
  • oak-lucene - Lucene-based query index
  • - -
  • oak-run - runnable jar packaging
  • - -
  • oak-upgrade - tooling for upgrading Jackrabbit repositories to Oak
  • - -
  • oak-it - integration tests - -
      - -
    • oak-it/mk - integration tests for MicroKernel
    • - -
    • oak-it/osgi - integration tests for OSGi
    • -
  • -
-

TODO: Link to additional readmes (benchmark runner, …)

-
-
-
- -
- - - + + + + + + + + + Jackrabbit Oak - + + + + + + + + + + + + + + + + + + Fork me on GitHub + + + + + + + + + +
+ + + + + +
+
+ +
+ + +
+ +
+

Getting Started

+

Many parts of Oak are still under construction, so it may be a bit difficult to find your way around the codebase. The README files, the Jackrabbit 3 wiki page, and the Oak mailing list archives are good places to start learning about Oak.

+

To get started developing Oak, build the latest sources with Maven 3 and Java 6 (or higher) like this:

+ +
+
mvn clean install
+
+

To enable all integration tests, including the JCR TCK, use:

+ +
+
mvn clean install -PintegrationTesting
+
+

Before committing changes or submitting a patch, please make sure that the above integration testing build passes without errors. If you like, you can enable integration tests by default by setting the OAK_INTEGRATION_TESTING environment variable.

+
+

MongoDB integration

+

Parts of the Oak build expects a MongoDB instance to be available for testing. By default a MongoDB instance running on localhost is expected, and the relevant tests are simply skipped if such an instance is not found. You can also configure the build to use custom MongoDB settings with the following properties (shown with their default values):

+ +
+
-Dmongo.host=127.0.0.1
+-Dmongo.port=27017
+-Dmongo.db=MongoMKDB
+-Dmongo.db2=MongoMKDB2
+
+

Note that the configured test databases will be dropped by the test cases.

+
+

Components

+

The build consists of the following main components:

+ +
    + +
  • oak-parent - parent POM
  • + +
  • oak-doc - Oak documentation
  • + +
  • oak-commons - shared utility code
  • + +
  • oak-mk-api - MicroKernel API
  • + +
  • oak-mk - default MicroKernel implementation
  • + +
  • oak-mk-remote - MicroKernel remoting
  • + +
  • oak-core - Oak repository API and implementation
  • + +
  • oak-jcr - JCR binding for the Oak repository
  • + +
  • oak-sling - integration with Apache Sling
  • + +
  • oak-solr-core - Apache Solr indexing and search
  • + +
  • oak-solr-embedded - Apache Solr on an embedded Solr instance
  • + +
  • oak-solr-remote - Apache Solr on an remote (HTTP) Solr instance
  • + +
  • oak-http - HTTP binding for Oak
  • + +
  • oak-lucene - Lucene-based query index
  • + +
  • oak-run - runnable jar packaging
  • + +
  • oak-upgrade - tooling for upgrading Jackrabbit repositories to Oak
  • + +
  • oak-it - integration tests + +
      + +
    • oak-it/mk - integration tests for MicroKernel
    • + +
    • oak-it/osgi - integration tests for OSGi
    • +
  • +
+

TODO: Link to additional readmes (benchmark runner, …)

+
+
+
+ +
+ + + \ No newline at end of file Modified: jackrabbit/site/live/oak/docs/differences.html URL: http://svn.apache.org/viewvc/jackrabbit/site/live/oak/docs/differences.html?rev=1535337&r1=1535336&r2=1535337&view=diff ============================================================================== --- jackrabbit/site/live/oak/docs/differences.html (original) +++ jackrabbit/site/live/oak/docs/differences.html Thu Oct 24 10:42:02 2013 @@ -1,526 +1,545 @@ - - - - - - - - - Jackrabbit Oak - - - - - - - - - - - - - - - - - - - Fork me on GitHub - - - - - - - - - -
- - - - - -
-
- -
- - -
- -

Backward compatibility

-

Oak implements the JCR API and we expect most applications to work out of the box. However, the Oak code base is very young and not yet on par with Jackrabbit 2. Some of the more obscure parts of JCR are not (yet) implemented. If you encounter a problem running your application on Oak, please cross check against Jackrabbit 2 before reporting an issue against Oak.

-

Reporting issues

-

If you encounter a problem where functionality is missing or Oak does not behave as expected please check whether this is a known change in behaviour or a known issue. If in doubt ask on the Oak dev list. Otherwise create a new issue.

-

Notable changes

-

This section gives a brief overview of the most notable changes in Oak with respect to Jackrabbit 2. These changes are generally caused by overall design decisions carefully considering the benefits versus the potential backward compatibility issues.

-
-

Session state and refresh behaviour

-

In Jackrabbit 2 sessions always reflects the latest state of the repository. With Oak a session reflects a stable view of the repository from the time the session was acquired (MVCC model). This is a fundamental design aspect for achieving the distributed nature of an Oak repository.

-

This change can cause subtle differences in behavior when two sessions perform modifications relying on one session seeing the other session’s changes. Oak requires explicit calls to Session.refresh()in this case.

- -
-

Note: To ease migration to Oak, sessions being idle for more than one minute will log a warning to the log file. Furthermore sessions are automatically synchronised to reflect the same state across accesses within a single thread. That is, an older session will see the changes done through a newer session given both sessions are accessed from within the same thread.

-

Automatic session synchronisation is a transient feature and will most probably be removed in future versions of Oak. See OAK-803 for further details regarding session backwards compatibility and OAK-960 regarding in thread session synchronisation.

-
-

On Oak Item.refresh() is deprecated and will always cause an Session.refresh(). The former call will result in a warning written to the log in order to facilitate locating trouble spots.

-

On Oak Item.save() is deprecated and will per default log a warning and fall back to Session.save(). This behaviour can be tweaked with -Ditem-save-does-session-save=false in which case no fall back to Session#save() will happen but an UnsupportedRepositoryException is thrown if the sub-tree rooted at the respective item does not contain all transient changes. See OAK-993 for details.

-
-

Query

-

Oak does not index content by default as does Jackrabbit 2. You need to create custom indexes when necessary, much like in traditional RDBMSs. If there is no index for a specific query then the repository will be traversed. That is, the query will still work but probably be very slow.

-

See the query overview page for how to create a custom index.

-
-

Observation

-

Regarding observation listeners:

- -
    - -
  • -

    Event.getUserId(), Event.getUserData()and Event.getDate() will only be available for locally generated events (i.e. on the same cluster node). To help identifying potential trouble spots, calling any of these methods without a previous call to JackrabbitEvent#isExternal() will write a warning to the log file.

  • - -
  • -

    Push notification mechanisms like JCR observation weight heavy on distributed systems. Therefore, if an application requirement is not actually an “eventing problem” consider using different means like query and custom indexes. Apache Sling identified and classified common usage patterns of observation and recommendations on alternative solutions where applicable.

  • - -
  • -

    Touched properties: Jackrabbit 2 used to generate a PROPERTY_CHANGED event when touching a property (i.e. setting a property to its current value). Oak keeps closer to the specification and omits such events.

  • - -
  • -

    Event.NODE_MOVED is not supported. Instead Event.NODE_ADDED and Event.Node_REMOVED events are reported as long as they don’t cancel each other (e.g. in case of reordering of nodes).

  • -
-
-

Same name siblings

-

Same name siblings (SNS) are deprecated in Oak. We figured that the actual benefit supporting same name siblings as mandated by JCR is dwarfed by the additional implementation complexity. Instead there are ideas to implement a feature for automatic disambiguation of node names.

-

In the meanwhile we have basic support for same name siblings but that might not cover all cases.

-
-

Authentication

-

Please refer to OAK-793 for a general overview of changes with respect to Jackrabbit 2.

-
-

Access Control Management

-

Refer to OAK-792 for a general overview of changes with respect to Jackrabbit 2.

-

The following modification are most likely to have an effect on existing applications:

- -
    - -
  • AccessControlManager#hasPrivilege() and AccessControlManager#getPrivileges() will throw a PathNotFoundException if the node for the specified path is not accessible. The Jackrabbit 2 implementation is wrong and we fixed that in OAK (OAK-886). If the new behaviour turns out to be a problem with existing applications we might consider adding backward compatible behaviour.
  • -
-
-

Permissions

-

Refer to OAK-942 for a general overview of changes with respect to Jackrabbit 2.

- -
    - -
  • -

    As of Oak Node#remove() only requires sufficient permissions to remove the target node. In contrast to jackrabbit the validation will not traverse the tree and verify remove permission on all child nodes/properties. There exists a configuration flag that aims to produce best effort backwards compatibility but this flag is currently not enabled by default. Please let us know if you suspect this causes wrong behavior in your application.

  • - -
  • -

    By default user management operations require the specific user mgt related permission that has been introduced with OAK-1.0. This behavior can be turned off by setting the corresponding configuration flag.

  • - -
  • -

    As of OAK reading and writing items in the version store does not follow the regular permission evaluation but depends on access rights present on the corresponding versionable node OAK-444.

  • -
-
-

Privilege Management

-

Refer to OAK-910 for a general overview of changes with respect to Jackrabbit 2.

-
-

User Management

-

Refer to OAK-791 for a general overview of changes with respect to Jackrabbit 2.

-
-

Principal Management

-

Refer to OAK-909 for a general overview of changes with respect to Jackrabbit 2.

-

Known issues

-

All known issues are listed in the Apache JIRA. Changes with respect to Jackrabbit-core are collected in OAK-14 and its sub-tasks.

- -
    - -
  • Locking: - -
      - -
    • Locking and unlocking of nodes is not implemented yet. You will not see an exception as long as the TODO-flag prevents the implementation from throwing UnsupportedOperationException, but the node will not be locked. See OAK-150
    • -
  • -
- -
    - -
  • Versioning OAK-168: - -
      - -
    • VersionHistory#removeVersion() is not implemented yet
    • - -
    • VersionManager#merge() is not implemented yet
    • - -
    • VersionManager#restore() with version-array is not implemented yet
    • - -
    • Activities are not implemented
    • - -
    • Configurations are not implemented
    • -
  • -
- -
    - -
  • Query: - -
      - -
    • Known issue with OR statements in full text queries See OAK-902
    • -
  • -
- -
    - -
  • Workspace Operations: - -
      - -
    • Cross workspace operations are not implemented yet See OAK-916
    • - -
    • Workspace Management (creating/deleting workspaces) is not implemented yet See OAK-916
    • - -
    • Workspace#copy() is not properly implemented See OAK-917 and sub tasks - -
        - -
      • copy of versionable nodes does not create new version history See OAK-918
      • - -
      • copy of locked nodes does not remove the lock See OAK-919
      • - -
      • copy of trees with limited read access See OAK-920
      • -
    • -
  • -
- -
    - -
  • Access Control Management and Permissions: - -
      - -
    • Move operations are not properly handled wrt. permissions See OAK-710
    • -
  • -
- -
    - -
  • User Management: - -
      - -
    • Group membership stored in tree structure is not yet implemented See OAK-482
    • -
  • -
-

In some cases Oak throws Runtime exceptions instead of a properly typed exception. We are working on correcting this. Please do not work around this by adapting catch clauses in your application.

-
-
-
- -
- - - + + + + + + + + + Jackrabbit Oak - + + + + + + + + + + + + + + + + + + Fork me on GitHub + + + + + + + + + +
+ + + + + +
+
+ +
+ + +
+ +

Backward compatibility

+

Oak implements the JCR API and we expect most applications to work out of the box. However, the Oak code base is very young and not yet on par with Jackrabbit 2. Some of the more obscure parts of JCR are not (yet) implemented. If you encounter a problem running your application on Oak, please cross check against Jackrabbit 2 before reporting an issue against Oak.

+

Reporting issues

+

If you encounter a problem where functionality is missing or Oak does not behave as expected please check whether this is a known change in behaviour or a known issue. If in doubt ask on the Oak dev list. Otherwise create a new issue.

+

Notable changes

+

This section gives a brief overview of the most notable changes in Oak with respect to Jackrabbit 2. These changes are generally caused by overall design decisions carefully considering the benefits versus the potential backward compatibility issues.

+
+

Session state and refresh behaviour

+

In Jackrabbit 2 sessions always reflects the latest state of the repository. With Oak a session reflects a stable view of the repository from the time the session was acquired (MVCC model). This is a fundamental design aspect for achieving the distributed nature of an Oak repository.

+

This change can cause subtle differences in behavior when two sessions perform modifications relying on one session seeing the other session’s changes. Oak requires explicit calls to Session.refresh()in this case.

+ +
+

Note: To ease migration to Oak, sessions being idle for more than one minute will log a warning to the log file. Furthermore sessions are automatically synchronised to reflect the same state across accesses within a single thread. That is, an older session will see the changes done through a newer session given both sessions are accessed from within the same thread.

+

Automatic session synchronisation is a transient feature and will most probably be removed in future versions of Oak. See OAK-803 for further details regarding session backwards compatibility and OAK-960 regarding in thread session synchronisation.

+
+

On Oak Item.refresh() is deprecated and will always cause an Session.refresh(). The former call will result in a warning written to the log in order to facilitate locating trouble spots.

+

On Oak Item.save() is deprecated and will per default log a warning and fall back to Session.save(). This behaviour can be tweaked with -Ditem-save-does-session-save=false in which case no fall back to Session#save() will happen but an UnsupportedRepositoryException is thrown if the sub-tree rooted at the respective item does not contain all transient changes. See OAK-993 for details.

+
+

Query

+

Oak does not index content by default as does Jackrabbit 2. You need to create custom indexes when necessary, much like in traditional RDBMSs. If there is no index for a specific query then the repository will be traversed. That is, the query will still work but probably be very slow.

+

See the query overview page for how to create a custom index.

+
+

Observation

+ +
    + +
  • +

    Event.getUserId(), Event.getUserData()and Event.getDate() will only be available for locally generated events (i.e. on the same cluster node). To help identifying potential trouble spots, calling any of these methods without a previous call to JackrabbitEvent#isExternal() will write a warning to the log file.

  • + +
  • +

    Push notification mechanisms like JCR observation weight heavy on distributed systems. Therefore, if an application requirement is not actually an “eventing problem” consider using different means like query and custom indexes. Apache Sling identified and classified common usage patterns of observation and recommendations on alternative solutions where applicable.

  • + +
  • +

    Event generation is done by looking at the difference between two revisions of the persisted content trees. Items not present in a previous revision but present in the current revision are reported as Event.NODE_ADDED and Event.PROPERTY_ADDED, respectively. Items present in a previous revision but not present in the current revision are reported as Event.NODE_REMOVED and Event.PROPERTY_REMOVED, respectively. Properties that changed in between the previous revision and the current revision are reported as PROPERTY_CHANGED. As a consequence operations that cancelled each others in between the previous revision and the current revision are not reported. Furthermore the order of the events depends on the underlying implementation and is not specified. In particular there are some interesting consequences:

    + +
      + +
    • Event.NODE_MOVED is not supported. Instead Event.NODE_ADDED and Event.Node_REMOVED events are reported for the respective subtrees.
    • +
    + + + +
      + +
    • Touched properties: Jackrabbit 2 used to generate a PROPERTY_CHANGED event when touching a property (i.e. setting a property to its current value). Oak keeps closer to the specification and omits such events. More generally removing a subtree and replacing it with the same subtree will not generate any event.
    • +
    + +
      + +
    • Removing a referenceable node and adding it again will result in a PROPERTY_CHANGED event for jcr:uuid.
    • +
  • + +
  • +

    The sequence of differences Oak generates observation events from is guaranteed to contain the before and after states of all cluster local changes. This guarantee does not hold for cluster external changes. That is, cancelling operations from cluster external events might not be reported event though they stem from separate commits (Session.save()).

  • +
+
+

Same name siblings

+

Same name siblings (SNS) are deprecated in Oak. We figured that the actual benefit supporting same name siblings as mandated by JCR is dwarfed by the additional implementation complexity. Instead there are ideas to implement a feature for automatic disambiguation of node names.

+

In the meanwhile we have basic support for same name siblings but that might not cover all cases.

+
+

Authentication

+

Please refer to OAK-793 for a general overview of changes with respect to Jackrabbit 2.

+
+

Access Control Management

+

Refer to OAK-792 for a general overview of changes with respect to Jackrabbit 2.

+

The following modification are most likely to have an effect on existing applications:

+ +
    + +
  • AccessControlManager#hasPrivilege() and AccessControlManager#getPrivileges() will throw a PathNotFoundException if the node for the specified path is not accessible. The Jackrabbit 2 implementation is wrong and we fixed that in OAK (OAK-886). If the new behaviour turns out to be a problem with existing applications we might consider adding backward compatible behaviour.
  • +
+
+

Permissions

+

Refer to OAK-942 for a general overview of changes with respect to Jackrabbit 2.

+ +
    + +
  • +

    As of Oak Node#remove() only requires sufficient permissions to remove the target node. In contrast to jackrabbit the validation will not traverse the tree and verify remove permission on all child nodes/properties. There exists a configuration flag that aims to produce best effort backwards compatibility but this flag is currently not enabled by default. Please let us know if you suspect this causes wrong behavior in your application.

  • + +
  • +

    By default user management operations require the specific user mgt related permission that has been introduced with OAK-1.0. This behavior can be turned off by setting the corresponding configuration flag.

  • + +
  • +

    As of OAK reading and writing items in the version store does not follow the regular permission evaluation but depends on access rights present on the corresponding versionable node OAK-444.

  • +
+
+

Privilege Management

+

Refer to OAK-910 for a general overview of changes with respect to Jackrabbit 2.

+
+

User Management

+

Refer to OAK-791 for a general overview of changes with respect to Jackrabbit 2.

+
+

Principal Management

+

Refer to OAK-909 for a general overview of changes with respect to Jackrabbit 2.

+

Known issues

+

All known issues are listed in the Apache JIRA. Changes with respect to Jackrabbit-core are collected in OAK-14 and its sub-tasks.

+ +
    + +
  • Locking: + +
      + +
    • Locking and unlocking of nodes is not implemented yet. You will not see an exception as long as the TODO-flag prevents the implementation from throwing UnsupportedOperationException, but the node will not be locked. See OAK-150
    • +
  • +
+ +
    + +
  • Versioning OAK-168: + +
      + +
    • VersionHistory#removeVersion() is not implemented yet
    • + +
    • VersionManager#merge() is not implemented yet
    • + +
    • VersionManager#restore() with version-array is not implemented yet
    • + +
    • Activities are not implemented
    • + +
    • Configurations are not implemented
    • +
  • +
+ +
    + +
  • Query: + +
      + +
    • Known issue with OR statements in full text queries See OAK-902
    • +
  • +
+ +
    + +
  • Workspace Operations: + +
      + +
    • Cross workspace operations are not implemented yet See OAK-916
    • + +
    • Workspace Management (creating/deleting workspaces) is not implemented yet See OAK-916
    • + +
    • Workspace#copy() is not properly implemented See OAK-917 and sub tasks + +
        + +
      • copy of versionable nodes does not create new version history See OAK-918
      • + +
      • copy of locked nodes does not remove the lock See OAK-919
      • + +
      • copy of trees with limited read access See OAK-920
      • +
    • +
  • +
+ +
    + +
  • Access Control Management and Permissions: + +
      + +
    • Move operations are not properly handled wrt. permissions See OAK-710
    • +
  • +
+ +
    + +
  • User Management: + +
      + +
    • Group membership stored in tree structure is not yet implemented See OAK-482
    • +
  • +
+

In some cases Oak throws Runtime exceptions instead of a properly typed exception. We are working on correcting this. Please do not work around this by adapting catch clauses in your application.

+
+
+
+ +
+ + + \ No newline at end of file