This week we have released a next step of eXoJCR evolution.
What is new and major in version 1.12?
First of all eXoJCR it's an open-source implementation of JCR specification (JSR-170) and now it's under LGPL license (was AGPL). LGPL means freedom for use in closed (commercial, private etc) projects. Doing this step we want to get more feedback about JCR technology in real world usecases. At other hand lesser license opens us an opportunity to work with many JBoss teams and especially with Portal guys. GateIn portal it's a web face of a Content Repositories actually... as well as many other tasty features :).
But eXoJCR 1.12 is very interesting technically also.
Our new, big and #1 feature today - clustering.
It's not a very new option and we had a replication in 1.11. But it was designed for data synchronization between sites over Internet in on-line peer-to-peer mode (available since version 1.10). And then used by several our customers for a clustering in Intranet solutions. We gathered lot of feedback and real usecases and decided to re-implement it from the scratch in 1.12.
The new clustering goals mean intensively loaded Repository work in corporate network or a cloud. At same time a main look made on read operations scalability what is general for Web applications.
Technically the new cluster uses the same JGroups transport well known to us by 1.11 replication (and still used in asynchronous replication). But now the clustering work fully based on JBossCache. We rely on JBoss experience in this field. And we have implemented not trivial task - hierarchical JCR data caching over the JBossCache keeping a compatibility with existing persistence. We also reimplemented JCR indexer and locks support on JBossCache.
A complex work done and we're on a next iteration there.
Other main features of eXoJCR 1.12.0-GA since 1.11.2
- Lazy-load option for child nodes and properties read, improved items
dataflow for read/write operations
- Alternative data container optimized for read operations (consuming
less database queries). It's enabled by default.
- Support of Java6 and Java5 runtimes and JDK
- Database dialect can be autodetected (if not pointed in the configuration)
- Support for Values large of 2GiB
- Portal container configuration supports default definitions,
links and externally loaded parameters
- Support of MySQL/InnoDB database for multilingual content
- Concurrency improvements for Session registry and Values storage
- Concurrency improvements for XA transactions support (Repository
login and logout are faster now)
- Improved search based on Lucene 2.4
- Standalone container can use configuration stored in JBoss application server
configuration directory by default
- WebDAV server update-policy can be configured to different
versioning behaviour
- Two new REST services introduced:
* HTTP (RESTful) Backup agent with console client
* HTTP (RESTful) Repository management service
More info about inherited features from the previous versions 1.11.2 here.
eXoJCR 1.12 was tested on databases/JDBC drivers:
MySQL 5.1 MYSQL Connector/J 5.1.8
Oracle DB 10g (10.2.0.1) Oracle 10g (10.2.0.1)
PostgresSQL 8.3.7 JDBC4 Driver, Version 8.3-605
DB2 9,7 IBM Data Server Driver for JDBC and SQLJ (JCC Driver)
Version: 9.1 (fixpack 3a)
MS SQL Server 2005 SP3 JDBC Driver 2.0
MS SQL Server 2008 SP1 JDBC Driver 2.0
Sybase 15.0.2 JConnect v6.0.5 (Build 26564 / 11 Jun 2009)
Downloads of a standalone eXoJCR bundles available now.
Tomcat or EAR provides a network ready content server with several plain samples. It provides WebDAV and FTP (port 2121) services on the board.
eXoJCR 1.12.0-GA jars are on JBoss maven2 repo also.
There are short intro how to setup dev environment for eXoJCR 1.12.
Where you can see eXoJCR in action (soon):
eXoJCR 1.12 is a database of GateIn portal.
eXoJCR 1.12 also used in xCMIS - eXo's CMIS implementation.
And our services...
Lot of stuff... stay connected. Details more interesting.
Showing posts with label webdav. Show all posts
Showing posts with label webdav. Show all posts
Sunday, March 14, 2010
Wednesday, September 23, 2009
JCR based Content Management
Why JCR is good for Content Management?
JCR standard (Java Content Repository, JSR-170) prescribed several best-practices already existing in content-management. Versioning, locking, content types, observation XML export/import and search - all of them were already implemented and sold to customers. But each one in "a bit" different, proprietary way.
Sounds good! It is good actually!
JCR it is a software developers API not a content writers tool. But can be used pretty (and should) to create amazing content-oriented products and concentrate on goals.
In addition to mentioned features (versions, locks etc) JCR gives high-level abstraction on actual data storage. Content developer doesn't care about a content storage location (files, database, S3) and creates features on top of JCR Repositories.
Each Repository consists at least one Workspace. But when you can have several it will be naturally to implement workflow like "draft", "acceptance", "production" and "backup".
Workspaces support Corresponding Nodes (4.10.2), so content branching and update between workspaces are native to JCR. Lot of opportunities with it...
Discussing is One Repository Even an Option? It's interesting to apply JCR features for such question.
The question is wide and a business related but in some sense it can be satisfied for both sides.
JCR Repository can contains several Workspaces with data from very different sources (databases, files and even in-cloud like Amazon S3). Each workspace connects via configuration and actual data location is fully transparent for content users.
On other hand JCR specification might seem not complete as it doesn't cover network access to a content. But shouldn't. It's the Java API only.
Here JCR vendors make the game. For example eXo JCR and Jackrabbit have such option as WebDAV access to a Repository. That gives a great opportunity to use JCR hosted content in web-pages without coding.
Real example of JCR based CMS
eXo WCM 1.2. Distro comes with lot of cool options and it runs fully on JCR storage and brings many JCR features to a content users.
Interesting? Find more in the wiki.
I'll show here how eXo WCM leverages JCR features for Content creation and sharing.
Usecase: one Repository... distributed worldwide.
Our virtual European company will provide information from one of its partners in United States on the company's site Home page.
Download and install eXo WCM on virtual company host. Run it and open Home page http://localhost:8080/portal. (user: root, password:exo)
This is a default eXo WCM Home page. Let's customize company Home page with the partner content. Partner company runs similar WCM instance and both WCMs are configured in multi-db JCR mode.
We configure dedicated workspace "exo-partner1" on both WCMs. This workspace will be connected to a one physical database (e.g. on partner side).
In addition to a JCR's Workspaces the eXo WCM introduces concept of Drive. Drive it is a sub-tree of Nodes or whole Workspace. Drive provides additional logical layer to a content management and allows to create different UI presentations dedicated to tasks.
Connect "exp-partner1" workspace as a new Drive (Groups->Sites Administrator->Content Presentation->Manage Drives->Add Drive) with rights to administrative group (*:/platform/administrators).
Now data can be simple shared between the company and the partner in one Repository. Users can read/write this workspace content, e.g. in WCM SitesExplorer or via WebDAV. And they can don't know where and how actual data is located at all.
Customizing the company Home page. Another cool feature of eXo WCM it's switcher from Live to Edit mode makes this task pretty simple. Switch to Edit mode.
Now we can edit each page part just in few clicks. Let's change the Test part.
Go to Image Properties of the existing image and fix its link to a partner's image. WCM uses "collaboration" workspace for a content. But we have market investigation report in "exo-partner1" workspace. JCR path to the file in the workspace /reports-09-2009/web2.0-techs-fall2009.jpg. And Repository content available via WebDAV. So, we can point the file from the page with the URL http://localhost:18080/rest/private/jcr/repository/exo-partner1/reports-09-2009/web2.0-techs-fall2009.jpg
Fix background color of CSS in Advanced tab and the customization is done. Click save and see the Home page.
Cool! How simple we can do such work with eXo WCM and JCR.
In the example I have used eXo WCM features out of the box.
But the product is open for extensions and many custom needs can be added simple. E.g. the example can be improved with JCR Corresponding Nodes (4.10.2) feature. Then content from "exo-partner1" workspace will be cloned to "business" workspace with enabled versioning; additional operations on the content also can be implemented via Observation (8.3) or Action Extensions.
Conclusion
JCR spec designed as Java API but when it is used deeply in a CMS tool, all those features becomes available to users making a content development better. It is open specification and there are several open-source implementations of it. That gives a freedom of choose of CM product to a content providers. At other hand developers can create content-oriented applications independently on Repository implementation and work on features but not on storages. Useful!
Next version of JCR comes (JSR-283) , it was approved and it's time of implementation now.
On other side there are several projects of JCR integration/implementation in non-Java environments, e.g. Typo3 CR or Jackalope.
JCR standard is useful for CMS, that is about it actually.
JCR standard (Java Content Repository, JSR-170) prescribed several best-practices already existing in content-management. Versioning, locking, content types, observation XML export/import and search - all of them were already implemented and sold to customers. But each one in "a bit" different, proprietary way.
Application developers and custom solution integrators will be able to avoid the costs associated with learning the particular API of each repository vendor. Instead, programmers will be able to develop content-based application logic independently of the underlying repository architecture or physical storage.
Customers will also benefit by being able to exchange their underlying repositories without touching any of the applications built on top of them
Sounds good! It is good actually!
JCR it is a software developers API not a content writers tool. But can be used pretty (and should) to create amazing content-oriented products and concentrate on goals.
In addition to mentioned features (versions, locks etc) JCR gives high-level abstraction on actual data storage. Content developer doesn't care about a content storage location (files, database, S3) and creates features on top of JCR Repositories.
Each Repository consists at least one Workspace. But when you can have several it will be naturally to implement workflow like "draft", "acceptance", "production" and "backup".
Workspaces support Corresponding Nodes (4.10.2), so content branching and update between workspaces are native to JCR. Lot of opportunities with it...
Discussing is One Repository Even an Option? It's interesting to apply JCR features for such question.
The question is wide and a business related but in some sense it can be satisfied for both sides.
JCR Repository can contains several Workspaces with data from very different sources (databases, files and even in-cloud like Amazon S3). Each workspace connects via configuration and actual data location is fully transparent for content users.
JCR implementation can supports many persistent backends actually.
While SQL database connected Workspaces for a production, we on eXo have SimpleDB experimental support also. eXo JCR persistent layer has CRUD API and can be implemented independently on other features.
On other hand JCR specification might seem not complete as it doesn't cover network access to a content. But shouldn't. It's the Java API only.
Here JCR vendors make the game. For example eXo JCR and Jackrabbit have such option as WebDAV access to a Repository. That gives a great opportunity to use JCR hosted content in web-pages without coding.
Real example of JCR based CMS
eXo WCM 1.2. Distro comes with lot of cool options and it runs fully on JCR storage and brings many JCR features to a content users.
eXoPlatform Web Content Management solution is emerging to help webmasters who handle all tasks needed to run a website, including development, deployment, design, content publication and monitoring. WCM facilitates managing website easily. In addition, the Webmasters are no more the only actors in the spotlight. Each member in the community is welcome to collaborate and contribute depending on his/her rights. All these features contribute to make the website management agile and less onerous.
Interesting? Find more in the wiki.
I'll show here how eXo WCM leverages JCR features for Content creation and sharing.
Usecase: one Repository... distributed worldwide.
Our virtual European company will provide information from one of its partners in United States on the company's site Home page.
Download and install eXo WCM on virtual company host. Run it and open Home page http://localhost:8080/portal. (user: root, password:exo)
This is a default eXo WCM Home page. Let's customize company Home page with the partner content. Partner company runs similar WCM instance and both WCMs are configured in multi-db JCR mode.
We configure dedicated workspace "exo-partner1" on both WCMs. This workspace will be connected to a one physical database (e.g. on partner side).
In addition to a JCR's Workspaces the eXo WCM introduces concept of Drive. Drive it is a sub-tree of Nodes or whole Workspace. Drive provides additional logical layer to a content management and allows to create different UI presentations dedicated to tasks.
Connect "exp-partner1" workspace as a new Drive (Groups->Sites Administrator->Content Presentation->Manage Drives->Add Drive) with rights to administrative group (*:/platform/administrators).
Now data can be simple shared between the company and the partner in one Repository. Users can read/write this workspace content, e.g. in WCM SitesExplorer or via WebDAV. And they can don't know where and how actual data is located at all.
Customizing the company Home page. Another cool feature of eXo WCM it's switcher from Live to Edit mode makes this task pretty simple. Switch to Edit mode.
Now we can edit each page part just in few clicks. Let's change the Test part.
Go to Image Properties of the existing image and fix its link to a partner's image. WCM uses "collaboration" workspace for a content. But we have market investigation report in "exo-partner1" workspace. JCR path to the file in the workspace /reports-09-2009/web2.0-techs-fall2009.jpg. And Repository content available via WebDAV. So, we can point the file from the page with the URL http://localhost:18080/rest/private/jcr/repository/exo-partner1/reports-09-2009/web2.0-techs-fall2009.jpg
Fix background color of CSS in Advanced tab and the customization is done. Click save and see the Home page.
Cool! How simple we can do such work with eXo WCM and JCR.
In the example I have used eXo WCM features out of the box.
But the product is open for extensions and many custom needs can be added simple. E.g. the example can be improved with JCR Corresponding Nodes (4.10.2) feature. Then content from "exo-partner1" workspace will be cloned to "business" workspace with enabled versioning; additional operations on the content also can be implemented via Observation (8.3) or Action Extensions.
Conclusion
JCR spec designed as Java API but when it is used deeply in a CMS tool, all those features becomes available to users making a content development better. It is open specification and there are several open-source implementations of it. That gives a freedom of choose of CM product to a content providers. At other hand developers can create content-oriented applications independently on Repository implementation and work on features but not on storages. Useful!
Next version of JCR comes (JSR-283) , it was approved and it's time of implementation now.
On other side there are several projects of JCR integration/implementation in non-Java environments, e.g. Typo3 CR or Jackalope.
JCR standard is useful for CMS, that is about it actually.
Subscribe to:
Posts (Atom)
Posts
