You are viewing a plain text version of this content. The canonical link for it is here.
Posted to graffito-dev@incubator.apache.org by sb...@inovex.de on 2005/04/10 21:05:12 UTC
RE: JCR mapping // proof of concept
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 <Ch...@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
>
> >> <ci...@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
> >>
> >>
> >
> >
>
>
>
>
Re: JCR mapping // proof of concept
Posted by Sandro Böhme <s....@inovex.de>.
Hello Christophe,
>>> 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.
>>
> How do you see the notype management in this framework ? it is not clear
> for me what you plan to do, can you give more details ?
Nodetype management is for me, what I described in the paragraph. It's
creating nodetypes out of bean classes at the moment. Later, modifying
nodetypes out of bean classes would also fit in this category. But as we
would need to have a mechanism to migrate the nodes from one type to
another this might get more difficult.
>>> * 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.
>
>
> Let's start with ant and I will migrate your ant tasks in Maven. We will
> see later this issue.
Thank you for offering me your help!
Best regards,
Sandro
Christophe Lombart wrote:
> Sandro Böhme wrote:
>
>>> 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.
>
>
> ok for PersistenceManager, forget my idea :-)
>
>>
>>> 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.
>>
> How do you see the notype management in this framework ? it is not clear
> for me what you plan to do, can you give more details ?
>
>>
>>> * 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.
>
>
> Let's start with ant and I will migrate your ant tasks in Maven. We will
> see later this issue.
>
>> 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.
>>
> Thanks for the contrib - Let me know when you have something new. I'm
> reviewing the Graffito security and after that I can help you.
>
> Regards,
> Christophe
>
>
>
Re: back to graffito, rough times
Posted by Christophe Lombart <ch...@sword-technologies.com>.
David Sean Taylor wrote:
>>
> Could you please propose all API changes in detail prior to changing
> the API in the future? Likewise for me. Then we can discuss/vote on
> the change.
>
>
Of course, this is what I planned to do. I'm on vacation this week. So,
next week, I will make a proposal. Can you remember me the tools you are
using to make some UML diagram ?
Thanks,
Christophe
Re: back to graffito, rough times
Posted by David Sean Taylor <da...@bluesunrise.com>.
Christophe Lombart wrote:
> I works for me (at least with HTML doc).
>
Yes of course it does.
I was speaking of my 3 dependent projects on this code, not the Graffito
build.
> I would to change the Graffito object model. The Document class is
> interesting for Document management but not always for content management.
> It should be interesting to defined some "content" object without blobs.
>
Could you please propose all API changes in detail prior to changing the
API in the future? Likewise for me. Then we can discuss/vote on the change.
--
David Sean Taylor
Bluesunrise Software
david@bluesunrise.com
[office] +01 707 773-4646
[mobile] +01 707 529 9194
Re: back to graffito, rough times
Posted by David Sean Taylor <da...@bluesunrise.com>.
Christophe Lombart wrote:
> David Sean Taylor wrote:
>
>> Spent a day working with Graffito today
>> I guess Christophe is using the graffito-portlets too.
>
Regarding the jetspeed-services flag, I think I've broken the build.
Had no idea that you created a webapp in the demo distribution.
I will try to make the Jetspeed services flag configurable and default
it back to the way you had it. Im sorry but everyone of my builds broke
when i updated from Graffito yesterday
--
David Sean Taylor
Bluesunrise Software
david@bluesunrise.com
[office] +01 707 773-4646
[mobile] +01 707 529 9194
Re: back to graffito, rough times
Posted by Christophe Lombart <ch...@sword-technologies.com>.
David Sean Taylor wrote:
> Spent a day working with Graffito today
> I guess Christophe is using the graffito-portlets too.
Correct
> Didn't realize this.
> Was wondering why the hell my FileServlet wouldn't load (had to change
> my web.xml on all apps here)
> and then my Spring services failed to load (see my latest commit)
I works for me (at least with HTML doc).
>
> API changes with Date -> Timestamp
> Exceptions moved out of API..
>
> Perhaps we should develop against a snapshot
> Im going to have to track commits a little closer for things like
> servlet mapping location changes(sigh)
> I know we are not ready for a release but I need APIs that I can
> depend on.
>
I would to change the Graffito object model. The Document class is
interesting for Document management but not always for content management.
It should be interesting to defined some "content" object without blobs.
Christophe
back to graffito, rough times
Posted by David Sean Taylor <da...@bluesunrise.com>.
Spent a day working with Graffito today
I guess Christophe is using the graffito-portlets too.
Didn't realize this.
Was wondering why the hell my FileServlet wouldn't load (had to change
my web.xml on all apps here)
and then my Spring services failed to load (see my latest commit)
API changes with Date -> Timestamp
Exceptions moved out of API..
Perhaps we should develop against a snapshot
Im going to have to track commits a little closer for things like
servlet mapping location changes(sigh)
I know we are not ready for a release but I need APIs that I can depend on.
--
David Sean Taylor
Bluesunrise Software
david@bluesunrise.com
[office] +01 707 773-4646
[mobile] +01 707 529 9194
Re: document type mappings
Posted by David Sean Taylor <da...@bluesunrise.com>.
Christophe Lombart wrote:
> David Sean Taylor wrote:
>
>> Has anyone implemented a formal way to map from file extensions to
>> MIME media types? I find myself writing this kind of code in the
>> Graffito document viewer portlet, but Im sure its been done before....
>>
>
> Extracted from Slide :
>
that list more than covers my needs, thanks!
So if I add these mappings to Jetspeed's servlet web.xml, then
PortletContext.getMimeType should return the correct mapping, in theory...
--
David Sean Taylor
Bluesunrise Software
david@bluesunrise.com
[office] +01 707 773-4646
[mobile] +01 707 529 9194
Re: document type mappings
Posted by Christophe Lombart <ch...@sword-technologies.com>.
David Sean Taylor wrote:
> Has anyone implemented a formal way to map from file extensions to
> MIME media types? I find myself writing this kind of code in the
> Graffito document viewer portlet, but Im sure its been done before....
>
Extracted from Slide :
<mime-mapping>
<extension>txt</extension>
<mime-type>text/plain</mime-type>
</mime-mapping>
<mime-mapping>
<extension>html</extension>
<mime-type>text/html</mime-type>
</mime-mapping>
<mime-mapping>
<extension>htm</extension>
<mime-type>text/html</mime-type>
</mime-mapping>
<mime-mapping>
<extension>gif</extension>
<mime-type>image/gif</mime-type>
</mime-mapping>
<mime-mapping>
<extension>jpg</extension>
<mime-type>image/jpeg</mime-type>
</mime-mapping>
<mime-mapping>
<extension>jpe</extension>
<mime-type>image/jpeg</mime-type>
</mime-mapping>
<mime-mapping>
<extension>jpeg</extension>
<mime-type>image/jpeg</mime-type>
</mime-mapping>
<mime-mapping>
<extension>java</extension>
<mime-type>text/plain</mime-type>
</mime-mapping>
<mime-mapping>
<extension>body</extension>
<mime-type>text/html</mime-type>
</mime-mapping>
<mime-mapping>
<extension>rtx</extension>
<mime-type>text/richtext</mime-type>
</mime-mapping>
<mime-mapping>
<extension>tsv</extension>
<mime-type>text/tab-separated-values</mime-type>
</mime-mapping>
<mime-mapping>
<extension>etx</extension>
<mime-type>text/x-setext</mime-type>
</mime-mapping>
<mime-mapping>
<extension>ps</extension>
<mime-type>application/x-postscript</mime-type>
</mime-mapping>
<mime-mapping>
<extension>class</extension>
<mime-type>application/java</mime-type>
</mime-mapping>
<mime-mapping>
<extension>csh</extension>
<mime-type>application/x-csh</mime-type>
</mime-mapping>
<mime-mapping>
<extension>sh</extension>
<mime-type>application/x-sh</mime-type>
</mime-mapping>
<mime-mapping>
<extension>tcl</extension>
<mime-type>application/x-tcl</mime-type>
</mime-mapping>
<mime-mapping>
<extension>tex</extension>
<mime-type>application/x-tex</mime-type>
</mime-mapping>
<mime-mapping>
<extension>texinfo</extension>
<mime-type>application/x-texinfo</mime-type>
</mime-mapping>
<mime-mapping>
<extension>texi</extension>
<mime-type>application/x-texinfo</mime-type>
</mime-mapping>
<mime-mapping>
<extension>t</extension>
<mime-type>application/x-troff</mime-type>
</mime-mapping>
<mime-mapping>
<extension>tr</extension>
<mime-type>application/x-troff</mime-type>
</mime-mapping>
<mime-mapping>
<extension>roff</extension>
<mime-type>application/x-troff</mime-type>
</mime-mapping>
<mime-mapping>
<extension>man</extension>
<mime-type>application/x-troff-man</mime-type>
</mime-mapping>
<mime-mapping>
<extension>me</extension>
<mime-type>application/x-troff-me</mime-type>
</mime-mapping>
<mime-mapping>
<extension>ms</extension>
<mime-type>application/x-wais-source</mime-type>
</mime-mapping>
<mime-mapping>
<extension>src</extension>
<mime-type>application/x-wais-source</mime-type>
</mime-mapping>
<mime-mapping>
<extension>zip</extension>
<mime-type>application/zip</mime-type>
</mime-mapping>
<mime-mapping>
<extension>bcpio</extension>
<mime-type>application/x-bcpio</mime-type>
</mime-mapping>
<mime-mapping>
<extension>cpio</extension>
<mime-type>application/x-cpio</mime-type>
</mime-mapping>
<mime-mapping>
<extension>gtar</extension>
<mime-type>application/x-gtar</mime-type>
</mime-mapping>
<mime-mapping>
<extension>shar</extension>
<mime-type>application/x-shar</mime-type>
</mime-mapping>
<mime-mapping>
<extension>sv4cpio</extension>
<mime-type>application/x-sv4cpio</mime-type>
</mime-mapping>
<mime-mapping>
<extension>sv4crc</extension>
<mime-type>application/x-sv4crc</mime-type>
</mime-mapping>
<mime-mapping>
<extension>tar</extension>
<mime-type>application/x-tar</mime-type>
</mime-mapping>
<mime-mapping>
<extension>ustar</extension>
<mime-type>application/x-ustar</mime-type>
</mime-mapping>
<mime-mapping>
<extension>dvi</extension>
<mime-type>application/x-dvi</mime-type>
</mime-mapping>
<mime-mapping>
<extension>hdf</extension>
<mime-type>application/x-hdf</mime-type>
</mime-mapping>
<mime-mapping>
<extension>latex</extension>
<mime-type>application/x-latex</mime-type>
</mime-mapping>
<mime-mapping>
<extension>bin</extension>
<mime-type>application/octet-stream</mime-type>
</mime-mapping>
<mime-mapping>
<extension>oda</extension>
<mime-type>application/oda</mime-type>
</mime-mapping>
<mime-mapping>
<extension>pdf</extension>
<mime-type>application/pdf</mime-type>
</mime-mapping>
<mime-mapping>
<extension>ps</extension>
<mime-type>application/postscript</mime-type>
</mime-mapping>
<mime-mapping>
<extension>eps</extension>
<mime-type>application/postscript</mime-type>
</mime-mapping>
<mime-mapping>
<extension>ai</extension>
<mime-type>application/postscript</mime-type>
</mime-mapping>
<mime-mapping>
<extension>rtf</extension>
<mime-type>application/rtf</mime-type>
</mime-mapping>
<mime-mapping>
<extension>nc</extension>
<mime-type>application/x-netcdf</mime-type>
</mime-mapping>
<mime-mapping>
<extension>cdf</extension>
<mime-type>application/x-netcdf</mime-type>
</mime-mapping>
<mime-mapping>
<extension>cer</extension>
<mime-type>application/x-x509-ca-cert</mime-type>
</mime-mapping>
<mime-mapping>
<extension>exe</extension>
<mime-type>application/octet-stream</mime-type>
</mime-mapping>
<mime-mapping>
<extension>gz</extension>
<mime-type>application/x-gzip</mime-type>
</mime-mapping>
<mime-mapping>
<extension>Z</extension>
<mime-type>application/x-compress</mime-type>
</mime-mapping>
<mime-mapping>
<extension>z</extension>
<mime-type>application/x-compress</mime-type>
</mime-mapping>
<mime-mapping>
<extension>hqx</extension>
<mime-type>application/mac-binhex40</mime-type>
</mime-mapping>
<mime-mapping>
<extension>mif</extension>
<mime-type>application/x-mif</mime-type>
</mime-mapping>
<mime-mapping>
<extension>ief</extension>
<mime-type>image/ief</mime-type>
</mime-mapping>
<mime-mapping>
<extension>tiff</extension>
<mime-type>image/tiff</mime-type>
</mime-mapping>
<mime-mapping>
<extension>tif</extension>
<mime-type>image/tiff</mime-type>
</mime-mapping>
<mime-mapping>
<extension>ras</extension>
<mime-type>image/x-cmu-raster</mime-type>
</mime-mapping>
<mime-mapping>
<extension>pnm</extension>
<mime-type>image/x-portable-anymap</mime-type>
</mime-mapping>
<mime-mapping>
<extension>pbm</extension>
<mime-type>image/x-portable-bitmap</mime-type>
</mime-mapping>
<mime-mapping>
<extension>pgm</extension>
<mime-type>image/x-portable-graymap</mime-type>
</mime-mapping>
<mime-mapping>
<extension>ppm</extension>
<mime-type>image/x-portable-pixmap</mime-type>
</mime-mapping>
<mime-mapping>
<extension>rgb</extension>
<mime-type>image/x-rgb</mime-type>
</mime-mapping>
<mime-mapping>
<extension>xbm</extension>
<mime-type>image/x-xbitmap</mime-type>
</mime-mapping>
<mime-mapping>
<extension>xpm</extension>
<mime-type>image/x-xpixmap</mime-type>
</mime-mapping>
<mime-mapping>
<extension>xwd</extension>
<mime-type>image/x-xwindowdump</mime-type>
</mime-mapping>
<mime-mapping>
<extension>au</extension>
<mime-type>audio/basic</mime-type>
</mime-mapping>
<mime-mapping>
<extension>snd</extension>
<mime-type>audio/basic</mime-type>
</mime-mapping>
<mime-mapping>
<extension>aif</extension>
<mime-type>audio/x-aiff</mime-type>
</mime-mapping>
<mime-mapping>
<extension>aiff</extension>
<mime-type>audio/x-aiff</mime-type>
</mime-mapping>
<mime-mapping>
<extension>aifc</extension>
<mime-type>audio/x-aiff</mime-type>
</mime-mapping>
<mime-mapping>
<extension>wav</extension>
<mime-type>audio/x-wav</mime-type>
</mime-mapping>
<mime-mapping>
<extension>mpeg</extension>
<mime-type>video/mpeg</mime-type>
</mime-mapping>
<mime-mapping>
<extension>mpg</extension>
<mime-type>video/mpeg</mime-type>
</mime-mapping>
<mime-mapping>
<extension>mpe</extension>
<mime-type>video/mpeg</mime-type>
</mime-mapping>
<mime-mapping>
<extension>qt</extension>
<mime-type>video/quicktime</mime-type>
</mime-mapping>
<mime-mapping>
<extension>mov</extension>
<mime-type>video/quicktime</mime-type>
</mime-mapping>
<mime-mapping>
<extension>avi</extension>
<mime-type>video/x-msvideo</mime-type>
</mime-mapping>
<mime-mapping>
<extension>movie</extension>
<mime-type>video/x-sgi-movie</mime-type>
</mime-mapping>
<mime-mapping>
<extension>avx</extension>
<mime-type>video/x-rad-screenplay</mime-type>
</mime-mapping>
<mime-mapping>
<extension>wrl</extension>
<mime-type>x-world/x-vrml</mime-type>
</mime-mapping>
<mime-mapping>
<extension>mpv2</extension>
<mime-type>video/mpeg2</mime-type>
</mime-mapping>
<mime-mapping>
<extension>jpg</extension>
<mime-type>image/pjpeg</mime-type>
</mime-mapping>
<mime-mapping>
<extension>sgml</extension>
<mime-type>text/sgml</mime-type>
</mime-mapping>
<mime-mapping>
<extension>sgm</extension>
<mime-type>text/sgml</mime-type>
</mime-mapping>
<mime-mapping>
<extension>css</extension>
<mime-type>text/css</mime-type>
</mime-mapping>
<mime-mapping>
<extension>png</extension>
<mime-type>image/png</mime-type>
</mime-mapping>
<mime-mapping>
<extension>bmp</extension>
<mime-type>image/bmp</mime-type>
</mime-mapping>
<mime-mapping>
<extension>mpga</extension>
<mime-type>audio/mpeg</mime-type>
</mime-mapping>
<mime-mapping>
<extension>mp2</extension>
<mime-type>audio/mpeg</mime-type>
</mime-mapping>
<mime-mapping>
<extension>mp3</extension>
<mime-type>audio/mpeg</mime-type>
</mime-mapping>
<mime-mapping>
<extension>js</extension>
<mime-type>application/x-javascript</mime-type>
</mime-mapping>
<mime-mapping>
<extension>xml</extension>
<mime-type>text/xml</mime-type>
</mime-mapping>
<mime-mapping>
<extension>xls</extension>
<mime-type>application/vnd.ms-excel</mime-type>
</mime-mapping>
<mime-mapping>
<extension>ppt</extension>
<mime-type>application/vnd.ms-powerpoint</mime-type>
</mime-mapping>
<mime-mapping>
<extension>doc</extension>
<mime-type>application/msword</mime-type>
</mime-mapping>
document type mappings
Posted by David Sean Taylor <da...@bluesunrise.com>.
Has anyone implemented a formal way to map from file extensions to MIME
media types? I find myself writing this kind of code in the Graffito
document viewer portlet, but Im sure its been done before....
--
David Sean Taylor
Bluesunrise Software
david@bluesunrise.com
[office] +01 707 773-4646
[mobile] +01 707 529 9194
Re: JCR mapping // proof of concept
Posted by Christophe Lombart <ch...@sword-technologies.com>.
Sandro Böhme wrote:
>> 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.
ok for PersistenceManager, forget my idea :-)
>
>> 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.
>
How do you see the notype management in this framework ? it is not clear
for me what you plan to do, can you give more details ?
>
>> * 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.
Let's start with ant and I will migrate your ant tasks in Maven. We will
see later this issue.
> 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.
>
Thanks for the contrib - Let me know when you have something new. I'm
reviewing the Graffito security and after that I can help you.
Regards,
Christophe
Re: JCR mapping // proof of concept
Posted by Sandro Böhme <s....@inovex.de>.
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 <Ch...@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
>>
>>
>>
>>>
>>>
>>>
>>>>> <ci...@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
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>
>>
>>
>>
>
>
Re: JCR mapping // proof of concept
Posted by Oliver Kiessler <ol...@gmail.com>.
> 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.
sorry for being so quiet lately... I am currently very busy on
different projects, so I wasn't able to review the code. please go
ahead and help sandro with his work. I will try to get back to the
project as soon as possible.
regards,
oliver
Re: JCR mapping // proof of concept
Posted by Christophe Lombart <ch...@sword-technologies.com>.
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
generic converter class ? It is not better to rename it to xxxxConverter ?
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
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 ?
* What is the goal of the BeanConverter ? It seems to be used only for
the NodeType ? is it correct ?
* 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.
* Can you add the ASF license in all files and more javadoc ?
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
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 <Ch...@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
>
>
>>
>>
>>
>>>><ci...@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
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>>
>>
>
>
>
>
>
>
>