Re: JCR mapping // proof of concept

[Sandro B�hme]

Hello Christophe,
thank you for reviewing the things.
Christophe Lombart wrote:
Sandro,
Thanks for your contribution, here is my first comments after a small 
review :
* Why set the  PersistenceManager  in the test area ? it is not our 
Because it is not really mature.
generic converter class ? It is not better to rename it to xxxxConverter ?
I don't need to use _this_ name. But because in this case more of the 
bean-->node type conversion is done at compile time with the 
BeanConverter, this has maybe more todo with persistance (insert(), 
delete(), update(),...). I'm not sure if xxxConverter is appropriate.

   If I understand, the target node type match to the class name and 
each class attributes have to match to a node property. I would like to 
Exactly.
suggest to used a mapping config file (like OJB or Hibernate) which will 
can gives more flexibility for the mapping  (like using proxies, ...). 
What do you think about that ?
You are absolutely right, not every property of an JCR item is mappable 
to a Java bean class or property. Therefore we need to specify the 
additional JCR properties.

Because Java beans and properties are mapped to node types you change 
beans in the same context where you change node types. This is why I 
would prefer to maintain the jcr properties and bean properties in a
single point - the class file. I will try to use x-doclet to specify 
e.g. the jcr-"value constraints" for a bean property (Maybe we can later 
use XMI to support "real" MDA). It should then be possible to completely 
maintain the nodetypes only with class files.
In short term I can only create new nodetypes out of classfiles because 
I think it will not be an easy task to migrate nodes from one type to 
another and maybe user input or converter classes are needed.


*  What is the goal of the BeanConverter ? It seems to be used only for 
the NodeType ? is it correct ?
It converts bean classes to node types at compile time. I will change 
the packagename because I think it should be something like 
nodetypeconversion or nodetypemanagement.

* Please use maven and not ant, it is used by all projects in the asf 
portal area. If you install maven, JAAS config is setup for you when 
running the unit test. See the file maven.xml. By this way, you can drop 
your hard coding on your own config folders.
In the project where I can hopefully integrate the mapping we can only 
use ant. So I need to find a solution for ant and maven.

* Can you add the ASF license in all files and more javadoc ?
Of course. I need some refactoring anyway.
I prefer to wait before check int  thoses files when the asf licence 
will be added and when we will have a more advance situation. Anyway, it 
This is absolutely ok.
Regards,
Sandro
is a good starting point.

Oliver, are you still interesting to work on this jcr mapping. If yes,  
I can  help Sandro in order to work faster and to commit something ASAP.

Regards,
Christophe
Here is the license :
/*
* Copyright 2000-2005 The Apache Software Foundation.
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
*      http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
[EMAIL PROTECTED] wrote:
Hello,
to Christophe and Oliver I sent (hopefully all) the files for a proof 
of concept
of three usecases for the JCR Mapping(I could not sent it to the 
mailing list
because it does not allow attachments):
1. Registering custom nodetypes according to a Java Bean model.
2. Persist a Java Bean.
3. Loading a Java Bean from the repository.

==>1. Creating the custom nodetypes is realized with JAXB.  The
BeanConverter class maps the Java structure to the
nodetype structure and marshalls the custom_nodetypes.xml to the
configured nodetype folder. I attached the /lib folder
with the jaxb libraries, a XML schema and the command line call (in the
generateNodeTypeDTD.bat file) if somebody want
to generate a new custom_nodetypes.xml file. I did not check the schema
against the spec yet, because it will change anyway.
Once the definition of the custom_nodetypes.xml file is stable, I would
like to create an Ant target and a seperate library
for generating custom nodetypes out of Java Beans.
==>2. Persisting simply works like that:
   PersistenceManager pm = new PersistenceManager(session);
   String relPath = pm.insert(folder);
==>3. Loading can be implemented this way:
       Folder loadedFolder = (Folder) pm.getObject(relPath);
All information for reading and writing a bean can be gained by the
class itself except the path where the
object is stored in the repository. This path acts like a unambiguous
database id.
++ limitations ++
o no complex properties can be saved (Folder.getDocument())
o collections are not yet supported
o deletion is not yet supported
o only the basic JCR Types (String, boolean,...) and java.util.Date are
supported
o the bean converter is not yet adapted to Graffito converter handling
o mixin's/Interfaces are not yet supported
++ next steps ++
o much more test cases need to be added and I'm sure according bug's
need to be fixed ;-)
o also delete the data created in the test cases
o pm.update and pm.delete() need to be added
o more atomic types (like Character,...) need to be added
o support for complex types
o support for collections
o support for interfaces
o make the namespace "graffito" configurable
o support for JCR features like searching, versioning,...
o creating an Ant target for registering Java classes as nodetypes
o refactor some responsibilties and names of some classes
o ...
++ configuration ++
I don't think it is ready for check in because the configuration is not
very clean at the
moment. I needed to delete the repository data (repotest/versions and
repotest/workspaces/default)
in order to get the tests to run. I've not very much experience with
maven. Your information for this
issue are very much appreciated.
Please tell me your opinions about all this. Thank you very much.
Regards,
Sandro

Zitat von LOMBART Christophe <[EMAIL PROTECTED]>:
 

No problem. I'm working on other area.
Christophe
-----Original Message-----
From:    Sandro B�hme [mailto:[EMAIL PROTECTED]
Sent:    Tue 4/5/2005 9:17 AM
To:    [EMAIL PROTECTED]
Cc:   
Subject:    Re: JCR mapping - step 2
Hallo again,

getting Graffito to run needed a little bit more time than I 
expected. What I have at the moment is not yet ready. But I hope I 
will have something until the end of the week.

regards,
Sandro
Sandro B�hme wrote:
  

Hello,
Christophe Lombart wrote:
    

Hi all,
I commited a small prototype (basic foundation to work together) 
for the JCR mapping framework. See in the jcr-mapping subproject.

Currently, it works like this :
* There is a converter class/cms object registered in a config file 
(see a example in 
jcr-mapping\src\conf\convertertest\converters.xml). This config 
file is very simple for this prototype.
* A simple converter class can be found in 
org.apache.portals.graffito.jcr.testconverter.
* It is possible to use custom JCR nodetypes or unstructured 
nodes.  This prototype is based on a node type called 
"graffito:folder"
* Check the
      
jcr-mapping/src/test/org/apache/portals/graffito/jcr/session/impl/JcrSessionTest.java 

 

  

<cid:[EMAIL PROTECTED]>to get more info
What about the next step  ? I think the following steps should be 
interesting :
* Add search capabilities
* More unit tests
* Build a more generic converter class. I'm thinking about a more 
advanced config file.  Something like :

<converters>      <converter class="org.mycmsframework.Folder"
      
converterClass="org.apache.portals.graffito.jcr.converter.GenericConverter" 
  

nodetype="graffito:folder" >
           <attributes>
                 <attribute name="description" />
                       <propertyNode name="graffito:description" />
                 </attribute>
           <attributes>
           ....
           <!-- add associations here -->        <converter>       
</converters>

* Any volonteer to continue this work ? Again, the code is still a  
      
yes, I would like to create a bean converter class at the weekend.
Regards,
Sandro
    

*prototype* and you are welcome to send us patches, comments, new 
enhancements, ...  I'm going to create a new component in JIRA.
      
    

Thanks,
Christophe