Cool! That's what I wanted to know. I was thinking about those xml limitations too. But since I'm not familiar with JCR I was wondering if it was a great choice. Look promising. I'm eager to see your results. Good luck!
On 12/29/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Hi > > As I mentioned I am writing a "Property Management System". This is actually > a port of a Struts/Commons Configuration(CC) application that I wrote some > time ago. I have been using CC since it's early beta stages so I'm quite > familiar with it. There are a number of issues with CC, one being the xml > plugin. It does a nasty job of reading anything but simple xml structures. > One of the things that I like about Jackrabbit is that it is actually quite > "thin", and I get to choose my persistance layer (XML, DB, what have you..). > Also the fact that I can do automatic versioning is a nice feature. And not > to metion that it comes with Tag library, so that I can display information > quite easily in a jsp page. > > As I mentioned, I am going to look into it for the Shale/Clay configuration > after I have ported my application. By then I'll know if it is overkill or > not. > > Hermod > > -----Original Message----- > From: Alexandre Poitras [mailto:[EMAIL PROTECTED] > Sent: Wednesday, December 28, 2005 11:12 PM > To: Struts Developers List > Subject: Re: [shale] Dialogs and Convention over Configuration > > > Hey I like the idea of using Jackrabbit for configuration management > but if you do not need version control and security, isn't it a little > bit overkill? I mean why not use commons configuration then? We have > been using it in my corporation to manage environment properties on > the different servers and I have to say it's quite simple. There are > still some issues but I can't see why Jackrabbit would be a better > solution. Seems a bit too heavy for configuration use but I could be > wrong. > > What do you think? > > On 12/28/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Hi > > > > Back and reading mails instead of gift stickers :). > > > > I am going to dive into this pretty soon. I am currently building a > > "Property Management System" for our Internet application architecture > > which you might say is a simpler? form of the discussed configuration > > control, using Jackrabbit. I plan to take what I learn from this and then > > try to apply that into a configuration control for Shale/Clay. I'll get > > back to you when that time comes. > > > > Hermod > > > > -----Original Message----- > > From: Gary VanMatre [mailto:[EMAIL PROTECTED] > > Sent: Friday, December 23, 2005 4:15 PM > > To: Struts Developers List > > Subject: RE: [shale] Dialogs and Convention over Configuration > > > > > > > > >From: <[EMAIL PROTECTED]> > > > > > > Hei > > > > > > If we where to look into a better configuration control, I would suggest > > > taking > > > a close look at Apache Jackrabbit (JSR-170). This gives among a lot of > > > good > > > things, versioning. You can even run with (Embedded) Derby as a backend, > > > or just > > > a plain XML structure if you prefer. I have been testing it for the last > > > couple > > > of weeks as a possible storage for a web application. During this > > > testing, it > > > struck me that the configuration in Shale/Clay might be a good candidate > > > for > > > this. I guess I would have to rewrite the Configuration handler to read > > > its data > > > from this new store. One of the nice features in Jackrabbit is the > > > possibility > > > to have listeners on it, meaning one would be able to reconfigure Shale > > > "on the > > > fly" so to speak through a GUI quite easily. > > > > > > > Ya, that would be a great marriage. I'm not sure what the interface would > > look like but I > > suspect it would be just snapping in a abstraction of a resource resolver? > > From a web application, how would you specify a label or correct version? > > I guess I need > > to take a look at jackrabbit so I can ask better questions. > > > > If this is an itch you need to scratch, I'll help out in the refactoring. > > This type of integration > > might give Clay a new facet for not only creating reusable view fragments > > but > > also providing a interface to manage them within the product life-cycle. > > > > > > Gary > > > > > Hermod > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * > > > > This email with attachments is solely for the use of the individual or > > entity to whom it is addressed. Please also be aware that the DnB NOR Group > > cannot accept any payment orders or other legally binding correspondence > > with > > customers as a part of an email. > > > > This email message has been virus checked by the virus programs used > > in the DnB NOR Group. > > > > * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > Alexandre Poitras > Québec, Canada > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Alexandre Poitras Québec, Canada --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]