Contentrepositoryapiforjavatechnologyspecification

《Contentrepositoryapiforjavatechnologyspecification》由会员分享，可在线阅读，更多相关《Contentrepositoryapiforjavatechnologyspecification（351页珍藏版）》请在装配图网上搜索。

1、Content Repository API for Java TechnologySpecificationJava Specification Request 283 version 2.0 RC2 + Binding v42DD MMMM 2006CONTENT REPOSITORY API FOR JAVA TECHNOLOGY SPECIFICATION11 PREFACE111.1 Documents Included112 INTRODUCTION122.1 Motivation122.2 Goals123 THE REPOSITORY MODEL143.1 API Basics

2、153.1.1 Traversal Access163.1.2 Direct Access173.1.3 Writing to the Repository173.1.4 Nodes, Properties and Items203.1.5 Nodes in multiple hierarchies (Binding)203.2 Compliance Levels213.3 SameName Siblings223.3.1 Index Notation223.3.2 Support for Same Name Siblings is Optional233.3.3 Properties Can

3、not Have Same Name Siblings233.4 Orderable Child Nodes233.4.1 Orderable Same Name Siblings233.4.2 Non-orderable Child Nodes243.4.3 Orderable Child Node Support is Optional243.4.4 Properties are Never Orderable243.5 Namespaces243.6 Path Syntax253.6.1 Names vs. Paths263.6.2 Current Item and Parent Ite

4、m263.7 Properties263.7.1 Multi-Value Properties273.7.2 Property Types with Special Semantics273.7.3 No Null Values283.8 Node Types293.9 Referenceable Nodes293.10 Workspaces313.10.1 Single Workspace Repositories313.10.2 Multiple Workspaces and Corresponding Nodes323.11 Versioning353.12 Metadata383.13

5、 Hierarchical versus Direct Access384 LEVEL 1 REPOSITORY FEATURES404.1 Accessing the Repository414.1.1 Repository Construction414.1.2 Repository Acquisition424.1.3 Sample Code424.1.4 Repository444.1.5 Credentials484.2 Reading Repository Content504.2.1 Session Read Methods504.2.2 Workspace Read Metho

6、ds534.2.3 Node Read Methods544.2.4 Property Read Methods604.2.5 Property Types644.2.6 Property Type Conversion704.2.7 Value734.2.8 Item Read Methods764.2.9 Effect of Access Denial on Read804.2.10 Example804.3 Namespaces834.3.1 Namespace Registry834.3.2 Prefix Syntax854.3.3 Session Namespace Mappings

7、854.3.4 Transactions and Namespaces874.4 XML Mappings884.4.1 System View XML Mapping884.4.2 Document View XML Mapping914.4.3 Escaping of Names954.4.4 Escaping of Values964.5 Exporting Repository Content984.5.1 Encoding1024.6 Searching Repository Content1034.6.1 XPath over Document View1034.6.2 XPath

8、 and SQL1044.6.3 XPath and Binding1044.6.4 Structure of a Query1044.6.5 Adapting XPath to the Content Repository1124.6.6 XPath Extensions1174.6.7 JCR XPath Grammar1234.6.8 XPath Grammar1234.6.9 XQuery Grammar1284.6.10 Search Scope1294.6.11 Query API1294.6.12 QueryManager1294.6.13 The Query Object131

9、4.6.14 The PreparedQuery Object1334.6.15 Persistent vs. Transient Queries1334.6.16 Query Results1344.6.17 Permissions1354.7 Node Types1364.7.1 What Constitutes a Node Type1364.7.2 Node Type Discovery in Level 11374.7.3 Primary and Mixin Node Types1384.7.4 Special Properties jcr:primaryType and jcr:m

10、ixinTypes1384.7.5 Property Definitions1394.7.6 Child Node Definitions1404.7.7 Inheritance Among Node Types1414.7.8 Discovering available Node Types1424.7.9 Discovering the Node Types of a Node1434.7.10 NodeTypeDefinition1444.7.11 NodeType1464.7.12 ItemDefinition1474.7.13 PropertyDefinition1494.7.14

11、NodeDefinition1514.7.15 Residual Definitions1534.7.16 Value Constraints1534.7.17 Automatic Item Creation1564.7.18 Discovery of Constraints on Existing Items1574.7.19 Predefined Node Types1584.7.20 Node Type Definitions in Content1604.7.21 Predefined Mixin Node Types1604.7.22 Predefined Primary Node

12、Types1614.8 System Node1714.9 Permission Checking1724.9.1 JAAS1724.9.2 Checking Permissions1724.10 JCR Address1745 LEVEL 2 REPOSITORY FEATURES1755.1 Writing Repository Content1765.1.2 Saving by UUID and Path1825.1.3 Reflecting Item State1825.1.4 Adding Nodes1865.1.5 Adding and Writing Properties1895

13、.1.6 Removing Nodes and Properties1995.1.7 Moving and Copying2015.1.8 Updating and Cloning Nodes across Workspaces2075.1.9 Referenceable Nodes2105.1.10 Treatment of UUIDs2105.1.11 Ordering Child Nodes2125.2 Adding and Deleting Namespaces2145.2.1 Visibility of Namespace Registry Changes2155.3 Importi

14、ng Repository Content2165.3.1 Import from System View2165.3.2 Import from Document View2165.3.3 Respecting Property Semantics2185.3.4 Determining Node Types2195.3.5 Determining Property Types2195.3.6 Workspace Import Methods2205.3.7 Session Import Methods2255.3.8 Importing jcr:root2295.4 Assigning N

15、ode Types2315.4.1 The Special Properties jcr:primaryType and jcr:mixinTypes2315.4.2 Assigning a Primary Node Type2315.4.3 Assigning Mixin Node Types2315.4.4 Automatic Addition and Removal of Mixins2345.4.5 Serialization and Node Types2345.5 Thread-Safety Requirements2366 OPTIONAL REPOSITORY FEATURES

16、2376.1 Transactions2386.1.1 Container Managed Transactions: Sample Request Flow2396.1.2 User Managed Transactions: Sample Code2396.1.3 Save vs. Commit2406.1.4 Single Session Across Multiple Transactions2406.1.5 Mention of Transactions within this Specification2416.2 Versioning2426.2.1 Versionable No

17、des2426.2.2 Version Storage2446.2.3 The Base Version2516.2.4 Initializing the Version History2516.2.5 Check In2526.2.6 Check Out2546.2.7 Restoring a Version2546.2.8 Restoring a Group of Versions2556.2.9 Update2566.2.10 Merge2566.2.11 OnParentVersion Attribute2606.2.12 The OnParentVersionAction Class

18、2636.2.13 Removal of Versions2646.2.14 Versioning API2646.2.15 Serialization of Version Storage2786.2.16 Versioning within a Transaction2786.2.17 Activities2786.2.18 Configurations and Baselines2816.2.19 Shallow Clone, Update and Merge2836.3 Observation2846.3.1 Discovering Observation Support2846.3.

19、2 Event Bundles2846.3.3 Event Types2846.3.4 Event2866.3.5 Event Listeners2906.3.6 Listener Registration2906.3.7 Observation Manager2916.3.8 Event Production2926.3.9 Event Filtering2936.3.10 Interpretation of Events2936.3.11 Deserializing Content2966.3.12 External Mechanisms2966.3.13 Location of List

20、eners2966.3.14 Persistence of Event Listeners2966.3.15 Vetoable Event Listeners2966.3.16 Exceptions2966.4 Locking2986.4.1 Discovery of Lock Capabilities2986.4.2 Lockable2986.4.3 Shallow and Deep Locks2986.4.4 Lock Owner2996.4.5 Placing and Removing a Lock2996.4.6 Lock Token2996.4.7 Session-scoped an

21、d Open-scoped Locks3006.4.8 Effect of a Lock3016.4.9 Timing Out3016.4.10 Locks and Transactions3016.4.11 Locking Methods3026.4.12 The Lock Object3056.4.13 Session Methods Related to the Lock Token3066.5 Searching Repository Content with SQL3086.5.1 The SQL Language3086.5.2 Database View3086.5.3 SQL

22、EBNF3136.5.4 SQL Syntax in Detail3146.5.5 Query Results3186.6 Node Type Registration3196.6.1 NodeTypeManager3196.6.2 NodeTypeTemplate3216.6.3 NodeDefinitionTemplate3226.6.4 PropertyDefinitionTemplate3236.7 Access Control3256.7.1 Access Control Discovery3256.7.2 Access Control Management3306.8 Bindin

23、g for Nodes3366.8.1 Constraints3366.8.2 Node methods3376.8.3 Mixin mix:bound3387 APPENDICES3397.1 Appendix A: Naming Conventions3397.2 Appendix B: Compact Node Type Definition3407.2.1 Grammar3407.2.2 Structure of a CND3417.3 Appendix C: XML Node Type Definition348AcknowledgementsThis specification i

24、s the collaborative product ofDavid Nuescheler (specification lead, Day Software),Peeter Piegaze (author, Day Software),and other members of the JSR 170 and JSR 283 expert groups, includingTim Anderson (Intalio),Gordon Bell (Hummingbird),Tobias Bocanegra (Day Software),Al Brown (FileNet),Dave Caruan

25、a (Alfresco),Geoffrey Clemm (IBM),David Choy (IBM),Jeff Collins (Vignette),Cornelia Davis (EMC),Chenggang Duan (Oracle),Roy Fielding (Day Software),Xaver Fischer (Opentext),Gary Gershon (Imerge),Stefan Guggisberg (Day Software),Stefano Mazzocchi (Apache Software Foundation),James Myers (Pacific Nort

26、hwest National Laboratories),John Newton (Alfresco),James Owen (BEA),Franz Pfeifroth (Fujitsu),David Pitfield (Oracle),Corprew Reed (FileNet),Julian Reschke (greenbytes),Marcel Reutegger (Day Software),Celso Rodriguez (Mobius),Steve Roth (BEA Systems),Victor Spivak (Documentum),David B. Victor (IBM)

27、,Dan Whelan (FileNet),Kevin Wiggen (Xythos),Jukka Zitting (Yukatan)as well as many others who contributed with corrections and suggestions.LicenseDay Management AG (Licensor) is willing to license this specification to you ONLY UPON THE CONDITION THAT YOU ACCEPT ALL OF THE TERMS CONTAINED IN THIS LI

28、CENSE AGREEMENT (Agreement). Please read the terms and conditions of this Agreement carefully.Content Repository for JavaTM Technology API Specification (Specification)Version: 2.0Status: FCSRelease: DD MMMM 2006Copyright 2006 Day Management AGBarfsserplatz 6, 4001 Basel, Switzerland.All rights rese

29、rved. NOTICE; LIMITED LICENSE GRANTS1. License for Purposes of Evaluation and Developing Applications. Licensor hereby grants you a fully-paid, non-exclusive, non-transferable, worldwide, limited license (without the right to sublicense), under Licensors applicable intellectual property rights to vi

30、ew, download, use and reproduce the Specification only for the purpose of internal evaluation. This includes developing applications intended to run on an implementation of the Specification provided that such applications do not themselves implement any portion(s) of the Specification.2. License fo

31、r the Distribution of Compliant Implementations. Licensor also grants you a perpetual, non-exclusive, non-transferable, worldwide, fully paid-up, royalty free, limited license (without the right to sublicense) under any applicable copyrights or, subject to the provisions of subsection 4 below, paten

32、t rights it may have covering the Specification to create and/or distribute an Independent Implementation of the Specification that: (a) fully implements the Specification including all its required interfaces and functionality; (b) does not modify, subset, superset or otherwise extend the Licensor

33、Name Space, or include any public or protected packages, classes, Java interfaces, fields or methods within the Licensor Name Space other than those required/authorized by the Specification or Specifications being implemented; and (c) passes the Technology Compatibility Kit (including satisfying the

34、 requirements of the applicable TCK Users Guide) for such Specification (Compliant Implementation). In addition, the foregoing license is expressly conditioned on your not acting outside its scope. No license is granted hereunder for any other purpose (including, for example, modifying the Specifica

35、tion, other than to the extent of your fair use rights, or distributing the Specification to third parties).3. Pass-through Conditions. You need not include limitations (a)-(c) from the previous paragraph or any other particular pass through requirements in any license You grant concerning the use o

36、f your Independent Implementation or products derived from it. However, except with respect to Independent Implementations (and products derived from them) that satisfy limitations (a)-(c) from the previous paragraph, You may neither: (a) grant or otherwise pass through to your licensees any license

37、s under Licensors applicable intellectual property rights; nor (b) authorize your licensees to make any claims concerning their implementations compliance with the Specification.4. Reciprocity Concerning Patent Licenses. With respect to any patent claims covered by the license granted under subparag

38、raph 2 above that would be infringed by all technically feasible implementations of the Specification, such license is conditioned upon your offering on fair, reasonable and non-discriminatory terms, to any party seeking it from You, a perpetual, non-exclusive, non-transferable, worldwide license un

39、der Your patent rights that are or would be infringed by all technically feasible implementations of the Specification to develop, distribute and use a Compliant Implementation.5. Definitions. For the purposes of this Agreement: Independent Implementation shall mean an implementation of the Specific

40、ation that neither derives from any of Licensors source code or binary code materials nor, except with an appropriate and separate license from Licensor, includes any of Licensors source code or binary code materials; Licensor Name Space shall mean the public class or interface declarations whose na

41、mes begin with java, javax, javax.jcr or their equivalents in any subsequent naming convention adopted by Licensor through the Java Community Process, or any recognized successors or replacements thereof; and Technology Compatibility Kit or TCK shall mean the test suite and accompanying TCK Users Gu

42、ide provided by Licensor which corresponds to the particular version of the Specification being tested.6. Termination. This Agreement will terminate immediately without notice from Licensor if you fail to comply with any material provision of or act outside the scope of the licenses granted above.7.

43、 Trademarks. No right, title, or interest in or to any trademarks, service marks, or trade names of Licensor is granted hereunder. Java is a registered trademark of Sun Microsystems, Inc. in the United States and other countries.8. Disclaimer of Warranties. The Specification is provided AS IS. LICEN

44、SOR MAKES NO REPRESENTATIONS OR WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO, WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, NON-INFRINGEMENT (INCLUDING AS A CONSEQUENCE OF ANY PRACTICE OR IMPLEMENTATION OF THE SPECIFICATION), OR THAT THE CONTENTS OF THE SPEC

45、IFICATION ARE SUITABLE FOR ANY PURPOSE. This document does not represent any commitment to release or implement any portion of the Specification in any product.The Specification could include technical inaccuracies or typographical errors. Changes are periodically added to the information therein; t

46、hese changes will be incorporated into new versions of the Specification, if any. Licensor may make improvements and/or changes to the product(s) and/or the program(s) described in the Specification at any time. Any use of such changes in the Specification will be governed by the then-current licens

47、e for the applicable version of the Specification.9. Limitation of Liability. TO THE EXTENT NOT PROHIBITED BY LAW, IN NO EVENT WILL LICENSOR BE LIABLE FOR ANY DAMAGES, INCLUDING WITHOUT LIMITATION, LOST REVENUE, PROFITS OR DATA, OR FOR SPECIAL, INDIRECT, CONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES

48、, HOWEVER CAUSED AND REGARDLESS OF THE THEORY OF LIABILITY, ARISING OUT OF OR RELATED TO ANY FURNISHING, PRACTICING, MODIFYING OR ANY USE OF THE SPECIFICATION, EVEN IF LICENSOR HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.10. Report. If you provide Licensor with any comments or suggestions in

49、 connection with your use of the Specification (Feedback), you hereby: (i) agree that such Feedback is provided on a non-proprietary and non-confidential basis, and (ii) grant Licensor a perpetual, non-exclusive, worldwide, fully paid-up, irrevocable license, with the right to sublicense through mul

50、tiple levels of sublicensees, to incorporate, disclose, and use without limitation the Feedback for any purpose related to the Specification and future versions, implementations, and test suites thereof.3511 PrefaceThis is version 2.0 of the Content Repository API for Java Technology specification (

51、Java Specification Request 283). Versions 1.0 and 1.0.1 of this specification were released under Java Specification Request 170.1.1 Documents IncludedThe specification includes: This document in Adobe Portable Document Format (jsr283.pdf). The Java source code for the API package javax.jcr and subp

52、ackages. A jar file of the API package javax.jcr and subpackages. The Javadoc produced from the javax.jcr and subpackages.In case of a discrepancy between this document and the Javadoc produced from the javax.jcr package, this document should be considered normative.2 Introduction2.1 MotivationAs th

53、e number of vendors offering proprietary content repositories has increased, the need for a common programmatic interface to these repositories has become apparent. The aim of the Content Repository for Java Technology API specification is to provide such an interface and, in doing so, lay the found

54、ations for a true industry-wide content infrastructure.Application developers and custom solution integrators will be able to avoid the costs associated with learning the particular API of each repository vendor. Instead, programmers will be able to develop content-based application logic independen

55、tly of the underlying repository architecture or physical storage.Customers will also benefit by being able to exchange their underlying repositories without touching any of the applications built on top of them.2.2 GoalsThe guiding principles governing the design of the API are:It should not be tie

56、d to any particular underlying architecture, data source or protocol.The API is, of course, essentially a set of Java interfaces, which can be implemented in a wide variety of ways. Hence, achieving this goal is not difficult in itself. The main challenge here is to allow enough flexibility in the A

57、PI so that it can be used for both hierarchical and non-hierarchical repository models. This is done by providing for both hierarchical, path-based addressing of content items and direct, UUID-based addressing.It should be easy to use from the programmers point of view.To this end, the API is design

58、ed to be as simple and straightforward as possible. In particular, it has a simple object model and concentrates on representing the core functionality of a content repository without venturing into areas that might be regarded as “content applications”.It should allow for relatively easy implementa

59、tion on top of as wide a variety of existing content repositories as possible.A concerted effort was made to ensure that it would be relatively easy to implement the API (especially at level 1, see below) on top of the repositories of most major vendors.However, it should also standardize some more

60、complex functionality needed by advanced content-related applications.Recognizing that a tension exists between this aim and the previous one, this specification has been split into two compliance levels as well as a set of optional features. Level 1 defines a read-only repository. This includes fun

61、ctionality for the reading of repository content, introspection of content-type definitions, basic support for namespaces, export of content to XML and searching. This functionality should meet the needs of presentation templates and basic portal applications comprising a large portion of the existi

62、ng code-base of content-related applications. Level 1 is also designed to be easy to implement on top of any existing content repository.Level 2 additionally defines methods for writing content, assignment of types to content, further support for namespaces, and importing content from XML.Finally, a

63、 number of independently optional features are defined that a compliant repository may support. These are transactions, versioning, observation, access control, locking and additional support for searching.3 The Repository ModelA content repository consists of one or more workspaces, each of which contains a tree of items. An item is either a node or a property. Each node may have zero or more child nodes and zero or more child properties. There is a sin