[jira] [Comment Edited] (OAK-2919) Refactor DocumentNodeStoreService and dependencies

["Robert Munteanu (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/OAK-2919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15346142#comment-15346142 ] 

Robert Munteanu edited comment on OAK-2919 at 6/23/16 9:23 AM:
---------------------------------------------------------------

Hm, looking back the enums serve no real purpose, since we can't use them to avoid casting to a specific type. Further refinements of the idea:

{code:java}public abstract class DocumentNodeStoreBuilder {
  public static MongoDocumentNodeStoreBuilder getMongoDocumentStoreNodeBuilder() { ... };
  public static RDBDocumentNodeStoreBuilder getRDBDocumentStoreNodeBuilder() { ... };
  public static DocumentNodeStoreBuilder getDocumentNodeStoreBuilder(Class<DocumentNodeStoreBuilder> klazz) { ... };
  // contains common methods and hooks

  public DocumentNodeStore getNodeStore() { ... };
}{code}

This will help with opening up the API, but just from a method signature point of view. We still need to have some kind of registry of Class → DocumentNodeStoreBuilder, and we can't use it to downcast to the proper DocumentNodeStoreBuilder type.

If we decide to go that way, due to the way OSGi works the registry is better suited to instances rather than classes, so we're going to need a separate BuilderFactory or BuilderRegistry class which centralises and creates these kinds of builders. The Factory/Registry is probably going to make use of OSGi via the Whiteboard so we will be able to use the extension points for the 'internal' builders as well - Mongo, RDB, Memory.

I can look into this in addition to breaking up DocumentMK.Builder, if you think that's something worth pursuing.

_edit_: removed unfinished sentence, s/generics/enums/


was (Author: rombert):
Hm, looking back the generics serve no real purpose, since we can't use them to avoid casting to a specific type. Further refinements of the idea:

{code:java}public abstract class DocumentNodeStoreBuilder {
  public static MongoDocumentNodeStoreBuilder getMongoDocumentStoreNodeBuilder() { ... };
  public static RDBDocumentNodeStoreBuilder getRDBDocumentStoreNodeBuilder() { ... };
  public static DocumentNodeStoreBuilder getDocumentNodeStoreBuilder(Class<DocumentNodeStoreBuilder> klazz) { ... };
  // contains common methods and hooks

  public DocumentNodeStore getNodeStore() { ... };
}{code}

This will help with opening up the API, but just from a method signature point of view. We still need to have some kind of registry of Class → DocumentNodeStoreBuilder, and we can't use it to downcast to the proper DocumentNodeStoreBuilder type.

If we decide to go that way, due to the way OSGi works the registry is better suited to instances rather than classes, so we're going to need a separate BuilderFactory or BuilderRegistry class which centralises and creates these kinds of builders. The Factory/Registry is probably going to make use of OSGi via the Whiteboard so we will be able to use the extension points for the 'internal' builders as well - Mongo, RDB, Memory.

I can look into this in addition to breaking up DocumentMK.Builder, if you think that's something worth pursuing.

_edit_: removed unfinished sentence

> Refactor DocumentNodeStoreService and dependencies
> --------------------------------------------------
>
>                 Key: OAK-2919
>                 URL: https://issues.apache.org/jira/browse/OAK-2919
>             Project: Jackrabbit Oak
>          Issue Type: Improvement
>          Components: blob, mongomk
>            Reporter: Philipp Suter
>              Labels: technical_debt
>
> Change how DocumentNodeStoreService, DocumentNodeStore, DocumentStore, BlobStore, DocumentMK.Builder are wired. It is unclear why registerNodeStoreIfPossible and registerNodeStore need additional logic to load the right BlobStore and DocumentStore.
> - Ideally (Document)NodeStore references one DocumentStore and one BlobStore. Configuration for them are loaded over respective OSGi configurations.
> - Cache should be handled in (Document)NodeStore and be independent from DocumentStore, BlobStore.
> - DocumentMK.Builder and DocumentNodeStoreService should be obsolete.
> - DocumentNodeStore is too long and could ideally be split in smaller files.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)