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]

Reply via email to