You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Jukka Zitting (JIRA)" <ji...@apache.org> on 2006/01/26 12:56:09 UTC
[jira] Created: (JCR-309) Extract the public API interfaces from
o.a.j.core to o.a.j.api
Extract the public API interfaces from o.a.j.core to o.a.j.api
--------------------------------------------------------------
Key: JCR-309
URL: http://issues.apache.org/jira/browse/JCR-309
Project: Jackrabbit
Type: Task
Components: API
Reporter: Jukka Zitting
Fix For: 1.0
To better document and track the public JCR extensions and component API provided by Jackrabbit and to allow more room for refactoring within the Jackrabbit core, we shoud move (or create) the supported API interfaces to a new org.apache.jackrabbit.api package.
At least the following interfaces should be moved along with any supporting implementation-independent classes:
* PersistenceManager
* FileSystem
* AccessManager
* QueryHandler
* TextFilter
Possible dependencies to implementation-specific classes should preferably be abstracted using extra interfaces.
Also the workspace and node type administration methods should be published as Jackrabbit-specific extensions to the JCR API interfaces.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Resolved: (JCR-309) Extract the public API interfaces from
o.a.j.core to o.a.j.api
Posted by "Jukka Zitting (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JCR-309?page=all ]
Jukka Zitting resolved JCR-309:
-------------------------------
Resolution: Fixed
Added the o.a.j.api.JackrabbitNodeTypeManager extension interface in revision 378211. The new API methods are implemented quite simplistically using the existing NodeTypeReader and NodeTypeRegistry methods. Currently only text/xml (and application/xml) are supported, we can add support for CND when the CND parser is promoted from contrib.
Together with previous commits this should cover the major JCR extensions in Jackrabbit, so I'm resolving this issue as Fixed. Please file a new issue if other public extensions are needed.
> Extract the public API interfaces from o.a.j.core to o.a.j.api
> --------------------------------------------------------------
>
> Key: JCR-309
> URL: http://issues.apache.org/jira/browse/JCR-309
> Project: Jackrabbit
> Type: Task
> Components: API
> Reporter: Jukka Zitting
> Assignee: Jukka Zitting
> Fix For: 1.0
> Attachments: jackrabbit-api.patch
>
> To better document and track the public JCR extensions and component API provided by Jackrabbit and to allow more room for refactoring within the Jackrabbit core, we shoud move (or create) the supported API interfaces to a new org.apache.jackrabbit.api package.
> At least the following interfaces should be moved along with any supporting implementation-independent classes:
> * PersistenceManager
> * FileSystem
> * AccessManager
> * QueryHandler
> * TextFilter
> Possible dependencies to implementation-specific classes should preferably be abstracted using extra interfaces.
> Also the workspace and node type administration methods should be published as Jackrabbit-specific extensions to the JCR API interfaces.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Assigned: (JCR-309) Extract the public API interfaces from
o.a.j.core to o.a.j.api
Posted by "Jukka Zitting (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JCR-309?page=all ]
Jukka Zitting reassigned JCR-309:
---------------------------------
Assign To: Jukka Zitting
> Extract the public API interfaces from o.a.j.core to o.a.j.api
> --------------------------------------------------------------
>
> Key: JCR-309
> URL: http://issues.apache.org/jira/browse/JCR-309
> Project: Jackrabbit
> Type: Task
> Components: API
> Reporter: Jukka Zitting
> Assignee: Jukka Zitting
> Fix For: 1.0
> Attachments: jackrabbit-api.patch
>
> To better document and track the public JCR extensions and component API provided by Jackrabbit and to allow more room for refactoring within the Jackrabbit core, we shoud move (or create) the supported API interfaces to a new org.apache.jackrabbit.api package.
> At least the following interfaces should be moved along with any supporting implementation-independent classes:
> * PersistenceManager
> * FileSystem
> * AccessManager
> * QueryHandler
> * TextFilter
> Possible dependencies to implementation-specific classes should preferably be abstracted using extra interfaces.
> Also the workspace and node type administration methods should be published as Jackrabbit-specific extensions to the JCR API interfaces.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (JCR-309) Extract the public API interfaces from
o.a.j.core to o.a.j.api
Posted by "Jukka Zitting (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JCR-309?page=comments#action_12364102 ]
Jukka Zitting commented on JCR-309:
-----------------------------------
> well, some of those groups are rather interfaces that provide a backend service, and are not usefull for the 'client'
Agreed, that's what I was trying to convey with "component API". You are right that SPI is a better term for those interfaces.
Perhaps we should create o.a.j.api for the JCR API extensions and o.a.j.spi for the component interfaces.
> Extract the public API interfaces from o.a.j.core to o.a.j.api
> --------------------------------------------------------------
>
> Key: JCR-309
> URL: http://issues.apache.org/jira/browse/JCR-309
> Project: Jackrabbit
> Type: Task
> Components: API
> Reporter: Jukka Zitting
> Fix For: 1.0
>
> To better document and track the public JCR extensions and component API provided by Jackrabbit and to allow more room for refactoring within the Jackrabbit core, we shoud move (or create) the supported API interfaces to a new org.apache.jackrabbit.api package.
> At least the following interfaces should be moved along with any supporting implementation-independent classes:
> * PersistenceManager
> * FileSystem
> * AccessManager
> * QueryHandler
> * TextFilter
> Possible dependencies to implementation-specific classes should preferably be abstracted using extra interfaces.
> Also the workspace and node type administration methods should be published as Jackrabbit-specific extensions to the JCR API interfaces.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (JCR-309) Extract the public API interfaces from
o.a.j.core to o.a.j.api
Posted by "Tobias Bocanegra (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JCR-309?page=comments#action_12364096 ]
Tobias Bocanegra commented on JCR-309:
--------------------------------------
well, some of those groups are rather interfaces that provide a backend service, and are not usefull for the 'client'. so i would devide:
Client Interface:
- NodeType stuff
Service Provider Interface
- PersistenceManager
- FileSystem
- AccessManager
- QueryHandler
- TextFilter
> Extract the public API interfaces from o.a.j.core to o.a.j.api
> --------------------------------------------------------------
>
> Key: JCR-309
> URL: http://issues.apache.org/jira/browse/JCR-309
> Project: Jackrabbit
> Type: Task
> Components: API
> Reporter: Jukka Zitting
> Fix For: 1.0
>
> To better document and track the public JCR extensions and component API provided by Jackrabbit and to allow more room for refactoring within the Jackrabbit core, we shoud move (or create) the supported API interfaces to a new org.apache.jackrabbit.api package.
> At least the following interfaces should be moved along with any supporting implementation-independent classes:
> * PersistenceManager
> * FileSystem
> * AccessManager
> * QueryHandler
> * TextFilter
> Possible dependencies to implementation-specific classes should preferably be abstracted using extra interfaces.
> Also the workspace and node type administration methods should be published as Jackrabbit-specific extensions to the JCR API interfaces.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (JCR-309) Extract the public API interfaces from
o.a.j.core to o.a.j.api
Posted by "Stefan Guggisberg (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JCR-309?page=comments#action_12364543 ]
Stefan Guggisberg commented on JCR-309:
---------------------------------------
> Attached a patch for creating public interfaces for RepositoryImpl.shutdown()
> and WorkspaceImpl.createWorkspace(String). Does this look OK? If so, I'll go
> ahead and commit it.
+1
maybe we should add an optional Properties argument to the createWorkspace signatur.
> ... or should we create an alternative like NodeTypeManagerImpl.registerNodeTypes(InputStream)?
i prefer NodeTypeManagerImpl.registerNodeTypes(InputStream)
> Extract the public API interfaces from o.a.j.core to o.a.j.api
> --------------------------------------------------------------
>
> Key: JCR-309
> URL: http://issues.apache.org/jira/browse/JCR-309
> Project: Jackrabbit
> Type: Task
> Components: API
> Reporter: Jukka Zitting
> Fix For: 1.0
> Attachments: jackrabbit-api.patch
>
> To better document and track the public JCR extensions and component API provided by Jackrabbit and to allow more room for refactoring within the Jackrabbit core, we shoud move (or create) the supported API interfaces to a new org.apache.jackrabbit.api package.
> At least the following interfaces should be moved along with any supporting implementation-independent classes:
> * PersistenceManager
> * FileSystem
> * AccessManager
> * QueryHandler
> * TextFilter
> Possible dependencies to implementation-specific classes should preferably be abstracted using extra interfaces.
> Also the workspace and node type administration methods should be published as Jackrabbit-specific extensions to the JCR API interfaces.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (JCR-309) Extract the public API interfaces from
o.a.j.core to o.a.j.api
Posted by "Jukka Zitting (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JCR-309?page=comments#action_12364609 ]
Jukka Zitting commented on JCR-309:
-----------------------------------
InputSource makes little sense to non-XML data like the CND. How about the following?
/** Registers node types from the given node type XML stream. */
NodeType[] registerNodeTypes(InputSource in) throws ...;
/** Registers node types from the given input stream of the given type. */
NodeType[] registerNodeTypes(InputStream in, String contentType) throws ...;
// Constants for the supported content types
String XML = "text/xml";
String CND = "text/x-jcr-cnd";
(The implementation should also support application/xml as the XML content type.)
> Extract the public API interfaces from o.a.j.core to o.a.j.api
> --------------------------------------------------------------
>
> Key: JCR-309
> URL: http://issues.apache.org/jira/browse/JCR-309
> Project: Jackrabbit
> Type: Task
> Components: API
> Reporter: Jukka Zitting
> Fix For: 1.0
> Attachments: jackrabbit-api.patch
>
> To better document and track the public JCR extensions and component API provided by Jackrabbit and to allow more room for refactoring within the Jackrabbit core, we shoud move (or create) the supported API interfaces to a new org.apache.jackrabbit.api package.
> At least the following interfaces should be moved along with any supporting implementation-independent classes:
> * PersistenceManager
> * FileSystem
> * AccessManager
> * QueryHandler
> * TextFilter
> Possible dependencies to implementation-specific classes should preferably be abstracted using extra interfaces.
> Also the workspace and node type administration methods should be published as Jackrabbit-specific extensions to the JCR API interfaces.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (JCR-309) Extract the public API interfaces from
o.a.j.core to o.a.j.api
Posted by "Tobias Bocanegra (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JCR-309?page=comments#action_12364545 ]
Tobias Bocanegra commented on JCR-309:
--------------------------------------
if find NodeTypeManagerImpl.registerNodeTypes(InputStream) very useless. since clients would need to fake XML in order to create the node types.
i suggest to elaborate NodeType stuff for 2.0 and then expose this api.
> Extract the public API interfaces from o.a.j.core to o.a.j.api
> --------------------------------------------------------------
>
> Key: JCR-309
> URL: http://issues.apache.org/jira/browse/JCR-309
> Project: Jackrabbit
> Type: Task
> Components: API
> Reporter: Jukka Zitting
> Fix For: 1.0
> Attachments: jackrabbit-api.patch
>
> To better document and track the public JCR extensions and component API provided by Jackrabbit and to allow more room for refactoring within the Jackrabbit core, we shoud move (or create) the supported API interfaces to a new org.apache.jackrabbit.api package.
> At least the following interfaces should be moved along with any supporting implementation-independent classes:
> * PersistenceManager
> * FileSystem
> * AccessManager
> * QueryHandler
> * TextFilter
> Possible dependencies to implementation-specific classes should preferably be abstracted using extra interfaces.
> Also the workspace and node type administration methods should be published as Jackrabbit-specific extensions to the JCR API interfaces.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (JCR-309) Extract the public API interfaces from
o.a.j.core to o.a.j.api
Posted by "Jukka Zitting (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JCR-309?page=comments#action_12364555 ]
Jukka Zitting commented on JCR-309:
-----------------------------------
Stefan:
> maybe we should add an optional Properties argument to the createWorkspace signatur.
What should it do? The current WorkspaceImpl.createWorkspace signature doesn't have it so we'd need to specify how the given properties will be interpreted and implement that interpretation.
We can add JackrabbitWorkspace.createWorkspace(String,Properties) without breaking backwards compatibility also later during the 1.x cycle. I suggest that we do so only when the given properties are actually used.
Felix:
> IMHO, the InputStream solution is not the best of all solutions, but it is still far better than nothing.
Agreed. We must have at least one officially supported node type registration mechanism in 1.0. The InputStream solution covers at least the basic use case without exposing too much of the Jackrabbit internals.
A more integrated tool can always use the internal Jackrabbit interfaces directly to get more control over the registration process, but there would be no guarantees of backwards compatibility for such clients.
> Extract the public API interfaces from o.a.j.core to o.a.j.api
> --------------------------------------------------------------
>
> Key: JCR-309
> URL: http://issues.apache.org/jira/browse/JCR-309
> Project: Jackrabbit
> Type: Task
> Components: API
> Reporter: Jukka Zitting
> Fix For: 1.0
> Attachments: jackrabbit-api.patch
>
> To better document and track the public JCR extensions and component API provided by Jackrabbit and to allow more room for refactoring within the Jackrabbit core, we shoud move (or create) the supported API interfaces to a new org.apache.jackrabbit.api package.
> At least the following interfaces should be moved along with any supporting implementation-independent classes:
> * PersistenceManager
> * FileSystem
> * AccessManager
> * QueryHandler
> * TextFilter
> Possible dependencies to implementation-specific classes should preferably be abstracted using extra interfaces.
> Also the workspace and node type administration methods should be published as Jackrabbit-specific extensions to the JCR API interfaces.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (JCR-309) Extract the public API interfaces from
o.a.j.core to o.a.j.api
Posted by "Tobias Bocanegra (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JCR-309?page=comments#action_12364607 ]
Tobias Bocanegra commented on JCR-309:
--------------------------------------
ok. lets add the register nodetype. but i would prefer an 'org.xml.sax.InputSource' instead of the input stream. and maybe an additional content type:
public NodeType[] NodeTypeManagerImpl.registerNodeTypes(InputSource in, String contentType);
contentType is either: text/xml or text/cnd
the advantage of the inputsource is: it has a systemId that can be used to resolve entities (eg: relatvie DVDs), and also for better error reporting.
> Extract the public API interfaces from o.a.j.core to o.a.j.api
> --------------------------------------------------------------
>
> Key: JCR-309
> URL: http://issues.apache.org/jira/browse/JCR-309
> Project: Jackrabbit
> Type: Task
> Components: API
> Reporter: Jukka Zitting
> Fix For: 1.0
> Attachments: jackrabbit-api.patch
>
> To better document and track the public JCR extensions and component API provided by Jackrabbit and to allow more room for refactoring within the Jackrabbit core, we shoud move (or create) the supported API interfaces to a new org.apache.jackrabbit.api package.
> At least the following interfaces should be moved along with any supporting implementation-independent classes:
> * PersistenceManager
> * FileSystem
> * AccessManager
> * QueryHandler
> * TextFilter
> Possible dependencies to implementation-specific classes should preferably be abstracted using extra interfaces.
> Also the workspace and node type administration methods should be published as Jackrabbit-specific extensions to the JCR API interfaces.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (JCR-309) Extract the public API interfaces from
o.a.j.core to o.a.j.api
Posted by "Jukka Zitting (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JCR-309?page=all ]
Jukka Zitting updated JCR-309:
------------------------------
Attachment: jackrabbit-api.patch
Attached a patch for creating public interfaces for RepositoryImpl.shutdown() and WorkspaceImpl.createWorkspace(String). Does this look OK? If so, I'll go ahead and commit it.
I also investigated the options for doing the same to node type registration. Exposing the current NodeTypeManagerImpl.getNodeTypeRegistry().registerNodeTypes(Collection) method will require also the *Def interfaces (optionally also the *DefImpl classes) to be exposed. This will also bring a dependency to the QName class. Is it OK to expose so much (essentially promising that they will not change much before Jackrabbit 2.0) or should we create an alternative like NodeTypeManagerImpl.registerNodeTypes(InputStream)?
> Extract the public API interfaces from o.a.j.core to o.a.j.api
> --------------------------------------------------------------
>
> Key: JCR-309
> URL: http://issues.apache.org/jira/browse/JCR-309
> Project: Jackrabbit
> Type: Task
> Components: API
> Reporter: Jukka Zitting
> Fix For: 1.0
> Attachments: jackrabbit-api.patch
>
> To better document and track the public JCR extensions and component API provided by Jackrabbit and to allow more room for refactoring within the Jackrabbit core, we shoud move (or create) the supported API interfaces to a new org.apache.jackrabbit.api package.
> At least the following interfaces should be moved along with any supporting implementation-independent classes:
> * PersistenceManager
> * FileSystem
> * AccessManager
> * QueryHandler
> * TextFilter
> Possible dependencies to implementation-specific classes should preferably be abstracted using extra interfaces.
> Also the workspace and node type administration methods should be published as Jackrabbit-specific extensions to the JCR API interfaces.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Kommentiert: (JCR-309) Extract the public API interfaces
from o.a.j.core to o.a.j.api
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JCR-309?page=comments#action_12364547 ]
Felix Meschberger commented on JCR-309:
---------------------------------------
While I tend to agree with Tobias that it would probably be better to have the item definition classes available for the casual use, it would probably also be usefull to be able to just register node types from pre-canned xml files.
Imagine a repository application which requires a set of node types. The definitions would be distributed in the form of XML - or better yet the new CND - format and could just be registered by handing a stream to the respective file.
IMHO, the InputStream solution is not the best of all solutions, but it is still far better than nothing.
> Extract the public API interfaces from o.a.j.core to o.a.j.api
> --------------------------------------------------------------
>
> Key: JCR-309
> URL: http://issues.apache.org/jira/browse/JCR-309
> Project: Jackrabbit
> Type: Task
> Components: API
> Reporter: Jukka Zitting
> Fix For: 1.0
> Attachments: jackrabbit-api.patch
>
> To better document and track the public JCR extensions and component API provided by Jackrabbit and to allow more room for refactoring within the Jackrabbit core, we shoud move (or create) the supported API interfaces to a new org.apache.jackrabbit.api package.
> At least the following interfaces should be moved along with any supporting implementation-independent classes:
> * PersistenceManager
> * FileSystem
> * AccessManager
> * QueryHandler
> * TextFilter
> Possible dependencies to implementation-specific classes should preferably be abstracted using extra interfaces.
> Also the workspace and node type administration methods should be published as Jackrabbit-specific extensions to the JCR API interfaces.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira