incubator-graffito-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sandro Böhme <s.boe...@inovex.de>
Subject Re: JCR mapping // proof of concept
Date Wed, 13 Apr 2005 11:32:32 GMT
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.
> */
> 
> sboehme@inovex.de 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 <Christophe.LOMBART@sword-technologies.com>:
>>
>>  
>>
>>> No problem. I'm working on other area.
>>> Christophe
>>>
>>>
>>> -----Original Message-----
>>> From:    Sandro Böhme [mailto:s.boehme@inovex.de]
>>> Sent:    Tue 4/5/2005 9:17 AM
>>> To:    graffito-dev@incubator.apache.org
>>> 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:part1.02050001.08030303@sword-technologies.com>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
>>>>>
>>>>>
>>>>>       
>>>>
>>>>     
>>>
>>>
>>>
>>>   
>>
>>
>>
>>
>>
>>
>>  
>>
> 
> 

Mime
View raw message