[jira] Updated: (GRFT-125) Add UUID support

[Christophe Lombart (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GRFT-125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christophe Lombart updated GRFT-125:


Description: 
Until now, only the path was used to retrieve content and makes references. Of 
course, in some situation UUID becomes more important. Furthermore supporting 
uuid is mandatory if we want to support "reference" jcr type. 

Here is a proposal to support UUID : 

1/ Modify the PersistenceManager API : 
  * add method getObject(String uuid)
  * Is it necessary to overload methods used to manage versions and locks ? 


2/ Review the mapping descriptor in order to map a pojo attribute into the node 
UUID (readonly) : 

  

  From now, it is possible to specify the path attribute and/or the uuid 
attribute in the java classes. Both fields are optional. 
 So, we have to review the classes PersistenceManagerImpl and 
ObjectConverterImpl which depend strongly on the path attribute.

3/ Specify in a class-descriptor the jcr type "mix:referenceable ". This can be 
done with one of the following way : 
   a. In the class descriptor definition : 

   b. or in the primary node type definition associated to the java class

4/ It should possible to defined the uuid field in an ancestor class descrptor 
(similar to the path field descriptor)


  was:
Until now, only the path was used to retrieve content and makes references. Of 
course, in some situation UUID becomes more important. Furthermore supporting 
uuid is mandatory if we want to support "reference" jcr type. 

Here is a proposal to support UUID : 

1/ Modify the PersistenceManager API : 
  * add method getObject(String uuid)
  * Is it necessary to overload methods used to manage versions and locks ? 


2/ Review the mapping descriptor in order to map a pojo attribute into the node 
UUID (readonly) : 

  

  From now, it is possible to specify the path attribute and/or the uuid 
attribute in the java classes. Both fields are optional. 
 So, we have to review the classes PersistenceManagerImpl and 
ObjectConverterImpl which depend strongly on the path attribute.

3/ Specify in a class-descriptor the jcr type "mix:referenceable ". This can be 
done with one of the following way : 
   a. In the class descriptor definition : 

   b. or in the primary node type definition associated to the java class



> Add UUID support
> 
>
> Key: GRFT-125
> URL: https://issues.apache.org/jira/browse/GRFT-125
> Project: Graffito
>  Issue Type: Sub-task
>Reporter: Christophe Lombart
> Assigned To: Christophe Lombart
> Fix For: 1.0-a1-dev
>
>
> Until now, only the path was used to retrieve content and makes references. 
> Of course, in some situation UUID becomes more important. Furthermore 
> supporting uuid is mandatory if we want to support "reference" jcr type. 
> Here is a proposal to support UUID : 
> 1/ Modify the PersistenceManager API : 
>   * add method getObject(String uuid)
>   * Is it necessary to overload methods used to manage versions and locks 
> ? 
> 2/ Review the mapping descriptor in order to map a pojo attribute into the 
> node UUID (readonly) : 
>   
>   From now, it is possible to specify the path attribute and/or the uuid 
> attribute in the java classes. Both fields are optional. 
>  So, we have to review the classes PersistenceManagerImpl and 
> ObjectConverterImpl which depend strongly on the path attribute.
> 3/ Specify in a class-descriptor the jcr type "mix:referenceable ". This can 
> be done with one of the following way : 
>a. In the class descriptor definition : 
>  jcrMixinTypes="mix:referencable" >
>b. or in the primary node type definition associated to the java class
> 4/ It should possible to defined the uuid field in an ancestor class 
> descrptor (similar to the path field descriptor)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: dtd for custom_nodetypes.xml

[Jukka Zitting]

Hi,

On 2/23/07, ruchi goel <[EMAIL PROTECTED]> wrote:

Is this not a standard way to register nodetypes ?


No. You want to use the JackrabbitNodeTypeManager interface from the
jackrabbit-api API library. Like this:

   InputStream xml = new FileInputStream(CUSTOM_NODETYPE_CONFIG);

   Session session = ...;
   JackrabbitNodeTypeManager manager = (JackrabbitNodeTypeManager)
   session.getWorkspace().getNodeTypeManager();
   manager.registerNodeTypes(xml, JackrabbitNodeTypeManager.TEXT_XML);

The JackrabbitNodeTypeManager.registerNodeTypes() handles all the
required parsing and other details.

You can also use the JackrabbitNodeTypeManager.hasNodeType() method to
check whether a given node type has already been registered.

BR,

Jukka Zitting

Re: dtd for custom_nodetypes.xml

[Christophe Lombart]

On 2/23/07, ruchi goel <[EMAIL PROTECTED]> wrote:




*where CUSTOM_NODETYPE_CONFIG  is custom_nodetypes.xml
Is this not a standard way to register nodetypes ? This is only
dependent o Jackrabbit1.2 API !!



Following JCR-170, there is not a standard way to register node types.
I think this point will be in the JCR-283.

Re: dtd for custom_nodetypes.xml

[ruchi goel]

I am using the following to register node types from RMIserver:
*private static void registerNodeTypes(Session session)throws
   InvalidNodeTypeDefException, javax.jcr.RepositoryException, 
IOException {

   InputStream xml = new FileInputStream(CUSTOM_NODETYPE_CONFIG);

   // HINT: throws InvalidNodeTypeDefException, IOException
   NodeTypeDef[] types = NodeTypeReader.read(xml);

   Workspace workspace = session.getWorkspace();
   NodeTypeManager ntMgr = workspace.getNodeTypeManager();
   NodeTypeRegistry ntReg = ((NodeTypeManagerImpl) 
ntMgr).getNodeTypeRegistry();


   for (int j = 0; j < types.length; j++) {
   NodeTypeDef def = types[j];

   try {
   ntReg.getNodeTypeDef(def.getName());
   }
   catch (NoSuchNodeTypeException nsne) {
   // HINT: if not already registered than register custom 
node type

   ntReg.registerNodeType(def);
   }

   }
   }


*where CUSTOM_NODETYPE_CONFIG  is custom_nodetypes.xml
Is this not a standard way to register nodetypes ? This is only 
dependent o Jackrabbit1.2 API !!



Thanks,
Ruchi
Christophe Lombart wrote:

If you want to register new node type, I advise you to read the following
page : http://jackrabbit.apache.org/doc/nodetype/index.html.
We are using the custom_nodestypes.xml only for the unit test. Later, we
have to think about a more robust solution to register node types from 
the
ocm tools. Anyway, I didn't find  the dtd but it is quite simple to 
use it -

sorry



On 2/22/07, ruchi goel <[EMAIL PROTECTED]> wrote:


Hi,
   Where  can I finddtd for   custom_nodetypes.xml  used  for
registering   custom nodetypes ?

Thanks,
Ruchi