Re: Persisting beans in the content repository
Hi Christophe, A few people pointed out graffito already, and I was greatly impressed as I've said in a previous email. We have the same goal indeed and I also like the comments on hibernate which I find very valid. But as written on the page you've been liking to, there has been no release yet. Also surfing the svn repository, no code has been committed since december last year, so I thought the project was not developed anymore and nobody denied my impression on a previous post. Therefore, this was developped. Regards, Niko On Oct 12, 2006, at 5:36 PM, Christophe Lombart wrote: It seems that we have the same target : http://incubator.apache.org/graffito/jcr-mapping/index.html br Christophe On 10/10/06, Nicolas Modrzyk [EMAIL PROTECTED] wrote: Hi All, We've developed something called a bean coder for our application. We've made it open source in case other people would want to use it. With it, you can easily persist some java beans to the repository, and retrieve them at any time. The pretty cool thing is that it plays nicely with the repository searches facility so that you can quickly and easily retrieve some persisted objects from list or maps. A short tutorial is available at the following URL: http://www.openwfe.org/openwfe-jcr-beancoder.html Not sure this is suitable for everyone, especially developers concerned with more complete solutions (like ..?), but this has been working very well so far in our production environment, so just felt like we should contribute back something to the community. Regards, Nicolas John,
Re: Persisting beans in the content repository
Hi Alexandru, I did not try it, but I read the doc online for jcr-mapping: http://incubator.apache.org/graffito/jcr-mapping/simple-strategies/ introduction-strategies.html Graffito sounded way more complete when you want to write the whole mapping strategy. The bean mapper sounded simpler for basic functional use. We did not have more requirements than map the bean to the repository(with good speed) so that its fields were searchable using the regular query manager. Niko On Oct 12, 2006, at 6:11 PM, Alexandru Popescu wrote: On 10/12/06, Nicolas Modrzyk [EMAIL PROTECTED] wrote: Hi Christophe, A few people pointed out graffito already, and I was greatly impressed as I've said in a previous email. We have the same goal indeed and I also like the comments on hibernate which I find very valid. But as written on the page you've been liking to, there has been no release yet. Also surfing the svn repository, no code has been committed since december last year, so I thought the project was not developed anymore and nobody denied my impression on a previous post. Therefore, this was developped. Nicolas, all the above are valid points. However, the source base haven't changed a lot because it was stable enough (I am using it in production). Also, we (Christophe and myself) haven't done much work on it as both have been quite busy lately and also we were thinking on what new features should we include. I am wondering if you tried it before starting to work on your project ;-) ? ./alex -- .w( the_mindstorm )p. Regards, Niko On Oct 12, 2006, at 5:36 PM, Christophe Lombart wrote: It seems that we have the same target : http://incubator.apache.org/graffito/jcr-mapping/index.html br Christophe On 10/10/06, Nicolas Modrzyk [EMAIL PROTECTED] wrote: Hi All, We've developed something called a bean coder for our application. We've made it open source in case other people would want to use it. With it, you can easily persist some java beans to the repository, and retrieve them at any time. The pretty cool thing is that it plays nicely with the repository searches facility so that you can quickly and easily retrieve some persisted objects from list or maps. A short tutorial is available at the following URL: http://www.openwfe.org/openwfe-jcr-beancoder.html Not sure this is suitable for everyone, especially developers concerned with more complete solutions (like ..?), but this has been working very well so far in our production environment, so just felt like we should contribute back something to the community. Regards, Nicolas John,
Re: Persisting beans in the content repository
Christophe, Given the thing we like in our tool, is the fact that no configuration is needed, you just need a reference to the node you want to store the bean, could that be fitted in Graffito by any means ? Also, what Timur said on the thread on the server side: http://www.theserverside.com/news/thread.tss?thread_id=42547#219899 He had the api to also do the reverse. Meaning, he could create a bean from some data available in the repository. I could imagine use-cases where this could be useful. Would this be possible within Graffito ? Niko but there is a plan (at least some discussion) to move this tools inside jackrabbit. would that be committed in the contrib section ? would there be fo
Re: JCR Apps and Exchangable
Hi Frans, Your question is a bit like asking how to I move my application from postgresql to mysql given that both postgres and mysql are using SQL as a language to access the data. You even have tools to import/export data in both of them. As a short answer, you can't. Most of the cms have custom nodes that can be read but surely cannot be shown or handled properly by other CMS. 1. I just try to save my Magnolia data, and make another CMS that can read Magnolia data, because I find that Magnolia dont have feature to show the content in sort by date which for me it is a basic feature for CMS, and to make a module on top of Magnolia, I still cannot get the guide. I am crossposting to the user of magnolia. To create a module for it, you basically copy and paste an other module and start creating your own. The guys are busy with a industrial production-ready 3.0 version, so the documentation is still a bit behind. I don't understand your problem on sorting by dates, this is just a simple query on the jcr, and any of the CMS can do that (magnolia included). Hope I have, to some extend, answered your question. Do not hesitate to ask more on the project's user list. Regards, Nicolas,
Persisting beans in the content repository
Hi All, We've developed something called a bean coder for our application. We've made it open source in case other people would want to use it. With it, you can easily persist some java beans to the repository, and retrieve them at any time. The pretty cool thing is that it plays nicely with the repository searches facility so that you can quickly and easily retrieve some persisted objects from list or maps. A short tutorial is available at the following URL: http://www.openwfe.org/openwfe-jcr-beancoder.html Not sure this is suitable for everyone, especially developers concerned with more complete solutions (like ..?), but this has been working very well so far in our production environment, so just felt like we should contribute back something to the community. Regards, Nicolas John,
Re: Object-content mapping tool in Graffito
Hi, I had a look at Graffito before, and while it looked promising the site hasn't been updated since february, and no activity has been recorded for a while now (5 weeks ago the license header was updated). Does anyone knows what the status of the project is ? If the project is still moving then yes, this is a great move to do. Nicolas, On Sep 1, 2006, at 5:50 PM, Jukka Zitting wrote: Hi, The incubating Graffito project (http://incubator.apache.org/graffito/) is building a nice portlet-based content management framework. One of the design goals is to be independent of the underlying storage model using mapping tools to present a pure Java object model to higher level components. Graffito is currently is using Apache OJB to achieve this on top of relational databases, but they also want to support JCR content repositories as storage components. To achieve this they've already created a relatively complete object-content mapping (ocm) tool called Graffito JCR Mapping (http://incubator.apache.org/graffito/jcr-mapping/). There was recent discussion on the Graffito mailing lists about the ocm tool being ptoentially useful to other people as well, and that being a Graffito subproject probably doesn't give the tool enough visibility among JCR users. One idea would be to graduate the Graffito JCR Mapping subproject into a Jackrabbit subproject to get greater exposure. The initial response within the Graffito community was positive to this idea, so I'd like to ask for opinions also from the Jackrabbit community. Would you think that bringing in the ocm tool would be a good addition to the set on-top-of-JCR components we already have? There are a number of stakeholders to consider and practical issues to sort out to actually make the idea happen, but I can start taking care of those if there is general consensus that this would be a good move. BR, Jukka Zitting -- Yukatan - http://yukatan.fi/ - [EMAIL PROTECTED] Software craftsmanship, JCR consulting, and Java development
Re: web dav (only folders displayed when using custom repository)
Good morning, Regarding the following: http://article.gmane.org/gmane.comp.apache.jackrabbit.devel/6783/ One minor suggestion would actually to create a: jackrabbit-webdav-servlets jar file, instead of putting them into the webapp if possible. Main reason for that being that when using maven, you can rely on dependencies for jar files, but not for war files. My work now is extending some of the webdav servlets, and if there are in war file, as you described it in the link above, it makes it hard for others to keep in sync and extends those servlets. What do you think ? Nicolas, On Jul 11, 2006, at 2:12 PM, Nicolas Modrzyk wrote: Hey Angela, thank you for your answers again. I am planning on using the webdav framework from jackrabbit real soon now, so if there's any configuration task I can help on let me know. Regards, Nicolas, On Jul 10, 2006, at 10:14 PM, Angela Schreiber wrote: Nicolas Modrzyk wrote: Hi again, I am realizing only now, that even though I can define multiple handlers from the webdav xml configuration, I can't seem to be able to assign nodetypes/collections for each of them, even though it's possible to achieve this programmatically. you are right. you can't specify separate nodetypes mappings for the various handlers. the configuration is one of the issues that needs to be address for JCR-417. this has been discussed twice in the dev-list and i started with the split some time ago. however, i need some quite time to think about it carefully and perform some minimal test. kind regards angela
Re: web dav (only folders displayed when using custom repository)
Hey Angela, thank you for your answers again. I am planning on using the webdav framework from jackrabbit real soon now, so if there's any configuration task I can help on let me know. Regards, Nicolas, On Jul 10, 2006, at 10:14 PM, Angela Schreiber wrote: Nicolas Modrzyk wrote: Hi again, I am realizing only now, that even though I can define multiple handlers from the webdav xml configuration, I can't seem to be able to assign nodetypes/collections for each of them, even though it's possible to achieve this programmatically. you are right. you can't specify separate nodetypes mappings for the various handlers. the configuration is one of the issues that needs to be address for JCR-417. this has been discussed twice in the dev-list and i started with the split some time ago. however, i need some quite time to think about it carefully and perform some minimal test. kind regards angela
web dav
Hi All, I am written a class that extends the SimpleWebDavServlet from the jackrabbit webapp. It will give access to a custom jackrabbit repository. It's working great, except I can only see and handle folders. Any obvious reasons for that ? Did I mis-configured or forgot to do something ? Regards, Nicolas Modrzyk,
mysql for filesystem
Hi All, I'm trying to have a full mysql set up running with jackrabbit. I am getting this exception while trying to the simpledb ERROR org.apache.jackrabbit.core.fs.db.DbFileSystem DbFileSystem.java (init:368) 24.05.2006 09:53:08 failed to initialize file system com.mysql.jdbc.exceptions.MySQLSyntaxErrorException: Specified key was too long; max key length is 1000 byte Is the DbFileSystem not recommended ? Or am I doing something wrong ? Nicolas,
