Hi Tyson, Tyson Norris schrieb: > Hi Paul - > The architecture I am investigating is using a single JCR repository > (initialized in Tomcat as a JNDI resource), but leveraging multiple > applications to administer and render content. > The specific applications I am trying to use together are: > - Magnolia (community edition) > - Sling > > Background: > Magnolia is a CMS built on top of Jackrabbit that offers features like ACLs, > publishing, templating, and document management. All of this is accessed via > a web UI. > However, the templating system (of Magnolia 3.6 - I will mention 4.0 later) > is based on JSPs that must be managed via filesystem deployment. In addition, > the management of file assets (think images linked via HTML template) are not > easily integrated with templates via the repo, and must also be managed > within the filesystem. > > If we could leverage sling's templating and file serving abilities, the > system process for publishing content to other remote environments (which > magnolia has functionality for JCR repo, but not filesystem), our life would > be much easier. >
Interesting, indeed ;-) > That said, I now can access magnolia repo from sling and vice versa, but > there is some application-specific meta data that each requires, and in some > cases (when magnolia encounters sling meta data, like sling:resourceType) > disrupts the other application (magnolia uses some logic to create a property > named mgnl:sling:resourceType which is illegal...). Well, I don't know much about mangolia, but I would consider magnolia's munging of sling:resourceTyp to mgnl:sling:resurceType a bug ;-) > > I am now coming to the conclusion that since each application has some > dependencies on the data having some specific configuration in the repo, it > may be more work to integrate these (or simply get them to work together on > the same repo) than to build out the desired functionality in one or the > other. In that case we will likely build upon Magnolia, since it offers more > breadth of desired functionaliy, even if it is a bit clunky. I would say, Sling does not have any hard dependencies on the data. There is just the special sling:resourceType property, which is used to resolve handling scripts. If you are entirely based on primary node types, you do not even need sling:resourceType properties, since the default is to use the primary node type as the resource type. > > Please let me know if you have comments/suggestions on this approach. Well, I think, with respect to ACL and user management, we are certainly open to extensions in Sling, they may probably be easily implemented based on what Jackrabbit 1.5 (and later 1.6) offer in terms of JSR-283 access control. The rest may also be easily added to Sling (which is exactly what we do inside Day for our WCM product). Regards Felix > > Thanks! > Tyson > > > -----Original Message----- > From: Paul Noden [mailto:[email protected]] > Sent: Tuesday, February 10, 2009 7:50 PM > To: [email protected] > Subject: Re: tomcat + JNDI + sling 3 > > Hi Tyson, > >>>> Next, I have a question about using sling - I'd like to access my JCR >>>> repository via JNDI within Tomcat. > > I am interested to know more about the system architecture that you're > using. Is it a sling-enabled-jcr with tomcat via jndi, do you use > sling to administer the content and tomcat to generate an output, or > is tomcat generating output in parallel, or perhaps it is just sling > running with tomcat, or some other model... If you could be so kind as > to let us (me) know I'd appreciate it, as it'll stop us (me) guessing > ;-) > > I'm leading a project for an application which is using jcr to store > content alongside a traditional relational database, in the first > stage to handle the storage of large binary blobs and hierarchical > data. Having evaluated sling a couple of times for this project we > ended up not leveraging it's features in the current implementation. > But with an ongoing plan for development I imagine I'll be evaluating > the use of sling again in the future for the project (as well as for > other projects in which I am involved) and knowledge of other > implementations, and any feedback from the teams having done these > (other than my Day friends), can only assist with this assessment. > > Kind Regards, > > Paul Noden > > -------------------------------------------------------------------- > This email is intended only for the person or entity to which it is addressed > and may contain information that is privileged, confidential or otherwise > protected from disclosure. Dissemination, distribution or copying of this > email or the information herein by anyone other than the intended recipient, > or an employee or agent responsible for delivering the message to the > intended recipient, is prohibited. If you have received this email in error, > please immediately notify us by calling our Help Desk at (415) 581-5552 or by > e-mailing us at [email protected]. > >
