I have an OSGi-based, server side application that uses the filesystem to store scripts and configuration data.
In time, I'd like to move that application to 'the cloud', and that's not going to work well with its current dependency to file system access.
What I'd like to do is insert a JCR layer into this application, so it will still work in the current situation (regular files on the local filesystem), but will pave the way to a cloud situation.
I did find a file connector in modeshape, but I ran into a pretty severe incompatibility with OSGi, which hasn't been fixed. Besides, ModeShape pulls in LOTS of dependencies (about 6 MB, I think), which is a problem for me.
So I don't see any options besides starting to hack my own JCR implementation, which I am reluctant to do.
Any ideas?
Although you wouldn't be using JCR directly, using the Apache Sling ResourceProvider mechanism should allow you to move easily from filesystem to something else later, and it's OSGi-friendly as Sling is 100% based on OSGi.
You could start now by using Sling's Filesystem resource provider ( http://sling.apache.org/site/accessing-filesystem-resources-extensionsfsresource.html ) and later move to your own custom ResourceProvider, as needed.
The source code of the filesystem provider is at https://svn.apache.org/repos/asf/sling/trunk/bundles/extensions/fsresource - it's quite simple code that can be used as an example for creating your own ResourceProvider.
For your custom system the question would be how many Sling bundles you need to get that working - I don't know off the top of my head but would suggest using the Sling Launchpad to find out, it launches a vanilla Sling system with lots of bundles that you won't need, but you could try reducing it to the minimum that still allows the ResourceProvider mechanism to work.
You can also use Apache Commons VFS2, there is for example a JCR connector, or you can use webdav or a JDBC table. I use this in a commercial project on top of an atomic (git like) tree on top of a shared JDBC table.
Related
Is there a way to get any Apache Camel component "metadata" using Java code, like the list of options and other parameters and their types? I think some automatic help builder was mentioned somewhere that might be of use for this task without using reflection.
A way to get the registered components of all types (including data formats and languages) with java code is also sought. Thanks
Yeah take a look at the camel-catalog JAR which includes all such details. This JAR is what the tooling uses such as some of the Maven tooling itself, or IDE plugs for IntelliJ or Eclipse etc. The JAR has both Java API and metadata files embedded in the JAR you can load.
At runtime you can also access this catalog via RuntimeCamelCatalog which you can access via CamelContext. The runtime catalog is a little bit more limited than CamelCatalog as it has a view of what actually is available at runtime in the current Camel application.
Also I cover this in my book Camel in Action 2nd edition where there is a full chapter devoted on Camel tooling and how to build custom tooling etc.
This is what I've found so far
http://camel.apache.org/componentconfiguration.html
I have created a Web Content Management library for use in WebSphere Portal. At the moment I'm using import-wcm-data to import the library, then I need to add some additional propeties to 2-3 files on the server under Resource Environment Providers and then restart particular services so those changes are detected.
Can anyone explain the benefits of using a paa over writing a simple bash (or similar) script to automate this process?
I don't understand if I get any advantages when using paa, or is paa even capable of updating properties files and restarting services?
I have been working intensively with PAA files and I must say that it is a very stable way of deploying a app requirering multiple depl steps and components.
It does need a startup process but is well worth it in a multi server environment.
You can do all the tasks that you can do in a Ant file as well as using the wsadmin script interface. I only update res env settings and the such in WAS and do not touch any props files for that reason since all settings are stored in WAS.
In my experience, a PAA is not a good method if you're merely importing a content library.
I don't think I understand why you are doing the import manually and not syndicating, but even if there's a good reason not to syndicate, the PAA process was too involved and required too many precursor actions (deleting libraries, remove PAA, deploy PAA and then activate the portliest) to be a viable option for something as simple as importing a WCM library.
Since activating the portlets I was importing with the PAA was an extra step, I don't believe you can restart applications either.
Anticipating possible future issues, I decided to use Java-based Jackrabbit implementation (since it's the system with the highest performance according to the Symfony CMF docs) for the storage purposes. For the portal I'm developing I use at the moment Symfony CMF with PHPCR content repository feature + some related tables in a standard RDBMS (MySQL).
Unfortunetely I have a very little knowledge and almost none practical experience on content repository systems. So here's my question:
When using Jackrabbit with PHPCR-ODM from within Symfony CMF app, am I able to access the stored content (being Document objects as seeing from PHPCR-ODM) from other solutions than PHPCR-ODM - say, from Java Spring app?
In other words, if I wanted at some stage switch to Java, and not touching the storage (Jackrabbit / MySQL), but just creating Java equivalent Documents, would I able to do this? Or I need to do some more work like exporting the database, and then make some work with importing it again to e.g. mentioned Java based solution?
yes, you can access the content from java without having to change the content. we even did a proof of concept to read data from Magnolia and Adobe CQ via PHPCR ODM.
I am looking into graph database systems, but most of them seem to be either embedded or accessible via html request. I am searching for a standalone server, accessible via a java api, that supports acid (and clustering), preferrably open source.
I like neo4j, but I don't want to embed my db or access it with (slow) html requests, it has to be accessible by multiple systems. If I got it all wrong and neo4j is a super choice, please provide a link or name to a suitable driver, if you know one. Thank you.
Check out InfiniteGraph. It is not open source, but there is a free version for up to 1 million nodes and edges.
I'm working on a very simple web app, written in Go language.
I have a standalone version and now port it to GAE. It seems like there is very small changes, mainly concerning datastore API (in the standalone version I need just files).
I also need to include appengine packages and use init() instead of main().
Is there any simple way to merge both versions? As there is no preprocessor in Go, it seems like I must write a GAE-compatible API for the standalone version and use this mock module for standalone build and use real API for GAE version. But it sounds like an overkill to me.
Another problem is that GAE might be using older Go version (e.g. now recent Go release uses new template package, but GAE uses older one, and they are incompatible). So, is there any change to handle such differences at build time or on runtime?
Thanks,
Serge
UPD: Now GAE uses the same Go version (r60), as the stable standalone compiler, so the abstraction level is really simple now.
In broad terms, use abstraction. Provide interfaces for persistence, and write two implementations for that, one based on the datastore, and one based on local files. Then, write a separate main/init module for each platform, which instantiates the appropriate persistence interface, and passes it to your main application to use.
My immediate answer would be (if you want to maintain both GAE and non-GAE versions) that you use a reliable VCS which is good at merging (probably git or hg), and maintain separate branches for each version. The GAE API fits in reasonably well with Go, so there shouldn't be too many changes.
As for the issue of different versions, you should probably maintain code in the GAE version and use gofix (which is unfortunately one-way) to make a release-compatible version. The only place where this is likely to cause trouble is if you use the template package, which is in the process of being deprecated; if necessary you could include the new template package in your GAE bundle.
If you end up with GAE code which you don't want to run on Google's servers, you can also look into AppScale.