Thanks for the reply!!! Backup: The backup part worries me a lot. In general do exports always not include version data? Sorry I haven't had a chance to play with Versioning yet. Are there any plans or JSR to address this. Maybe I am in the wrong here, but as I see it a CMS is really a form of database and as with any database to be used in an enterprise system you need the ability to do online back ups. Now for my home projects that's not an issue. Jackrabbit is awesome and really great to work with and I'd love to use it more at work, but this prevents that.
Server Mode: It turns out our problem getting the RMI server to run correctly was a stupid user error. My RMI expert didn't know you could specify 2 jars in the codebase when you start the RMI server. After you confirmed it should work as easily as I thought it should I pushed him some more and he figured it out. Thank you! Kevin Runde -----Original Message----- From: Jukka Zitting [mailto:[EMAIL PROTECTED] Sent: Thursday, April 27, 2006 1:37 PM To: [email protected] Subject: Re: Help using JCR-RMI Hi, On 4/27/06, Runde, Kevin <[EMAIL PROTECTED]> wrote: > 1) Backup: Is it possible to do an "online backup" of a repository and > if so how could this be done. The cleanest way is to use a system view XML export of your content. With binary properties included this will give you a complete content snapshot that you can easily copy or restore. The drawbacks of this approach are that the XML export can easily get pretty large, and that the export won't contain any version histories or custom nodetypes (you can't import the jcr:system tree even though it can be exported). > 2) Server Mode: I've seen the JCR-RMI package and tried to get a simple > server running, but keep running into issues. Has anyone gotten an RMI > server running in Java 1.5? If so could you share with me your Daemon > class and the startup options used when you run the Daemon. I saw a > HOWTO 0.2 in the mail archives, but that hasn't helped solve my issues. What sort of issues are you facing? The essential code I'm using is shown below: Repository repository = ...; // The local repository String name = ...; // The RMI URL for the repository RemoteAdapterFactory factory = new ServerAdapterFactory(); RemoteRepository remote = factory.getRemoteRepository(repository); Naming.bind(name, remote); // Make the RMI binding using java.rmi.Naming For a more complete example with a number of extra features see the registerRMI() method of the RepositoryStartupServlet class in the jcr-server webapp: http://svn.apache.org/viewcvs.cgi/jackrabbit/trunk/jcr-server/webapp/src /java/org/apache/jackrabbit/j2ee/RepositoryStartupServlet.java?view=mark up > 3) What are these RMI speed issues I see mentioned? Again I searched the > mail list, but didn't find any thing about it. The main performance issues with JCR-RMI are related to the very fine-grained remote access policy it uses. By design JCR-RMI uses little or no caching or clustering of data, so almost all JCR method calls using JCR-RMI cause network roundtrips. For example no properties of a retrieved node are cached client-side. Instead all Node.getProperty() and even Property.getValue() calls are performed over the network. Another issue is that all JCR object instances (Nodes, Properties, etc.) are backed by JCR-RMI using a separate Remote object. These constraints are there on purpose, as the main design goal of JCR-RMI has been to be as transparent and straightforward RMI mapping of the JCR API as reasonable. JCR-RMI is actually surprisingly fast given these design constraints, and I have no immediate plans to make major performance changes (there are a few minor streamlining issues remaining). One of the goals of JSR 283 is to come up with a way to make remote JCR easier and faster, so I'm holding back any major plans until the first public JSR 283 drafts are out. As a summary I'd say that JCR-RMI gives good enough performance for an editor or administrator client, but you generally wouldn't want to use it to back a web site or another heavily accessed frontend unless you use aggressive caching. A good solution for many deployments would be to have Jackrabbit deployed on the same container as the main application that uses it, and to use JCR-RMI to access the repository from other applications that don't run inside the same container. BR, Jukka Zitting -- Yukatan - http://yukatan.fi/ - [EMAIL PROTECTED] Software craftsmanship, JCR consulting, and Java development
