Last thursday, i did the webinar about PHPCR and Magnolia CMS. You can download the slides or watch the recorded presentation (you need to register to see it). Thanks to all the attendees, I hope you enjoyed it.
There where some questions that i want to answer here on the blog to have the answers available to everybody.
Question : How reliable is Jackalope, can i trust my data to it?
Answer : Jackalope is still on the young side, but running successfully in a couple of real life applications. We also built a PHPCR API test suite that checks on many features. The PHPCR test suite is by no means as complete as the JCR technology compatibilty kit (TCK) testing suite. With jackalope-jackrabbit, the data is stored into Jackrabbit however. Jackrabbit is really mature and validates the data coming in over DavEx. In the very worst case when Jackalope totally fails, you could still write Java code or use Java tools to interact with Jackrabbit directly. In my experience I never needed to resort to that.
Question : You mentioned that same name siblings are not supported by Jackalope. Is there any particular reason for Jackalope for not supporting this? Is support coming, or is this a design choice?
Answer : Same name siblings is one of the optional chapters of JCR. Jackrabbit supports them, so it would be doable to implement them in Jackalope as well. It can be rather tricky to do it, having unique child names made a lot of the code easier. But if somebody wants to take the effort to implement it, I would be happy to provide support and help understanding implementation details.
The main reason to have them, by the way, is that JCR / PHPCR can import arbitrary XML documents, and such documents tend to have same name siblings, just think of a XHTML document for example.
Question : What if I need a particular PHPCR feature not yet implemented in Jackalope?
Answer : Jackalope is an open source project. Contributions are always welcome, and the community will help. Liip is also open to consulting work for such tasks. Note that there are a few chapters that will be impossible to implement with jackalope-jackrabbit until the jackrabbit side implements exposing them over DavEx. This is not impossible, but considerably more effort. The next major version of Jackrabbit, codename “Oak” will focus more on feature completeness over the remoting protocol.
Question : Where are queries executed? Is there any way to measure the impact on the Magnolia repository? (I wouldn't want my main sites performance to degrade dramatically) Is there some sort of cache or index on the PHPCR side?
Answer : Normal requests for nodes are cached by Jackalope for the PHP session. SQL2 or QOM queries however are not cached. The impact will not be higher than when implementing the functionality in Java in a custom module inside Magnolia CMS. The load should be slightly lower even, as the DavEx remoting is more low-level than the full JCR API. And the PHP application can life on its own separate server. Nontheless it makes of course sense to cache rendered pages or page-fragments on the PHP side. But that is an application level task.
Question : DavEx provides to the Jackrabbit used in the Magnolia CMS. Is there a way to connect to different repositories?
Answer : DavEx is an implementation specific protocol invented for jackrabbit to do remoting. Jackalope thus can talk to any Jackrabbit instance, and it has no problem opening several sessions with different servers. But connecting to any non-jackrabbit JCR implementation is not supported. JCR is an API, not a protocol. Note that there are ideas to generalize the jackrabbit-protocol into another standard called JSOP.
Question : Something is unclear to me: Are calls from Jackalope to the Jackrabbit repository bypassing Magnolia?
Answer : Yes, exactly. The Magnolia CMS DavEx module just provides a servlet that receives the requests and pipes them through to the jackrabbit DavEx layer. This is needed because Magnolia CMS runs Jackrabbit in its own process and does not use the DavEx remoting.
The following diagram shows the interaction between Jackalope, Jackrabbit and Magnolia CMS. The PHP application is talking to the PHPCR interfaces, implemented by Jackalope. Jackalope uses the HTTP based DavEx protocol to talk to the Jackrabbit DavEx handler which is exposed by the servlet Magnolia plugin. Magnolia CMS is accessed through web requests and uses its in-process connection to Jackrabbit to read data. If Magnolia CMS needs to know about data changes done by the PHP application, it would have to use the observation feature of Jackrabbit to listen for changes on the content.
When not using Magnolia CMS, you could also run jackrabbit standalone or use the .war archive in any servlet container like Tomcat.
Question : Is there also support for the other “direction”? A case where Magnolia would use a PHPCR-backed repo/app instead of being the master?
Answer : This is partially answered above – JCR and PHPCR are APIs for code, not a protocol. A PHPCR server implementation would need to expose its content over DavEx for jackrabbit to connect to it. Besides the effort to build that, the scenario does not make too much sense. PHP is typically used in request-response setup where all objects are lost after a request. Such a server would be extremly slow as it would spend most of the time bootstrapping. While there are solutions for building PHP application servers like react, i don't see a real benefit.
What can make sense is to configure Magnolia CMS to talk to a remote Jackrabbit rather than use the in-process Jackrabbit bindings. Then Magnolia CMS and the PHP client would both connect to the same repository outside of Magnolia CMS.
Question : Will the Magnolia DavEx Module be available as a Maven dependency?
Answer : It is available in the maven repository of Magnolia CMS. Here's the dependency snippet:
<dependency>
<groupid>info.magnolia.davex</groupid>
<artifactid>magnolia-module-jackrabbit-davex</artifactid>
<version>0.2</version>
</dependency>You can use the http://nexus.magnolia-cms.com/content/groups/public/ repository, which contains all public artifacts from Magnolia, CE and Forge, releases and snapshots.
Or – for just the Magnolia Forge projects, either of these, depending on what you're after: