Home

News: Java Content Repository: TheServerSide Tech Brief

  1. "Everything is content," is David Nüscheler's mantra. David is the spec lead for JSRs 170 and 283, Java Content Repository. He talks about content and content repository, the JCR spec, JackRabbit and other JCR implementations, and about his work as CTO of Day Software. (Click here if you can't watch the video.) The Java Content Repository is a common, standardized API used by most Java-based, modern content management systems. It isn't tied to any underlying architecture, so its back-end can be a database, a WebDAV server, or even the file system. It allows users to import and export data between different back-ends. All of these while normalizing access control, searching, and versioning of the content repository in a system-independent manner. Learn more about JSR-170 JCR 1.0, JSR-283 JCR 2.0, and Apache JackRabbit after watching the brief. Watch other Tech Briefs

    Threaded Messages (32)

  2. I really like the Java Content Repository (JCR) API but the default reference implementation Apache JackRabbit is simply not suitable for any application that has a requirement for more than one concurrent/active session. The JackRabbit implementation from 1.1.x onwards has been plagued with performance and concurrency problems that appear practically impossible to remove without major architectural changes (which by the way the architect has accepted). - It is not transactional- or thread- safe and operates poorly in a clustered environment. Threads executing statements while another thread is actually closing the connection. Session transactions spanning multiple JDBC connections with no internal transaction co-ordination (XAResource)...... - It suffers occasional corruption which has resulted in a +10 hour JBoss restart at a customer site - apparently it reloads all digital resources irrespective of text extractor configuration. - Its database table structure makes it practically impossible to recover orphaned nodes and subtrees because of the occasional lost update. - Documentation is non-existent. What there is (and it is small) is not even maintained across changes. - Every release breaks the previous configuration or system behavior especially with undocumented config name changes. One has to look at the JIRA issue tracking system to determine what the new configuration should look like. - It has many performance problems especially when using the database persistence management in a clustered environment and storing large digital assets (10M..100M). The customer has now completely abandoned JackRabbit and it now piloting Exo and Alfresco. Fortunately the use of a standard API (JCR) and a small amount of bootstrapping code has made this transition easy with the Exo platform but sadly this cannot be said for the Alfresco solution. - William PS: I did ask the team at InfoQ how they managed to overcome the problems I identified. They never replied.
  3. William summarizes our experience 100%. JackRabbit is obviously not designed for any realistic production environment. My question is, is the Day implementation the same as JackRabbit? Can the CTO respond to this.
  4. William summarizes our experience 100%. JackRabbit is obviously not designed for any realistic production environment. My question is, is the Day implementation the same as JackRabbit? Can the CTO respond to this.
    As far as I can tell, Day's product line is not based on JackRabbit. I have a job in the real world where Day Software is one of the options we're looking at. Based on the complete feature set, I'm rather sure that JackRabbit is not the engine under their hood. I hope that David is reading this and can answer in more detail about exactly how this works. On a separate note: take a look at Alfresco when you get a chance. Pretty interesting open-source implementation. It's not geared to be just a reference, like JackRabbit; it's intended as a viable product. Cheers, E
  5. I'll second the recommendation to look at Alfresco. I've been playing with it on and off now for a few weeks and it seems like a fairly solid product. Certainly great from the point of view of wanting to build on top of it -- treating Alfresco as a 'platform'. Although not a JSR-170 expert by any means, I believe that the implementation in Alfresco is distinct from JackRabbit and the Day offering. It certainly implements level 1 and 2 of JSR-170 and there is much attention being paid to forthcoming evolutions of that. So far, I've had a great experience and it's pressing all the right buttons for me to use it for a few projects.
  6. I am excited to read all the positive feedback about JCR. I think I agree that Apache Jackrabbit is currently still a bit rough around the edges and lacks the nice packaging that would make it really easy to install in a scalable way. The quickly growing and very active Jackrabbit community is currently working on adding the nice wrapping around the core. It is important to stress though that Jackrabbit at its core is designed to be rock solid, fully transactional and very scalable if configured and tuned properly. Jackrabbit is also fully compliant with the JCR spec and therefore also supports JCR features like unstructured content, versioning, locking or XA-transactions according to the spec. The Apache Software Foundation has certainly made an important statement to make Jackrabbit a priority by graduating it to a "top level project" and therefore (similar to Apache Tomcat) making it more than "just an Reference Implementation". To answer the question about Day Software's commercial offering, I would like to state that in CRX (Day's commercial Content Repository) you will find a very "easy to install and use" content repository that features all the benefits of a commercial grade repository, while being 100% compliant with the JCR specification. CRX particularly addresses issues mentioned earlier in this thread alongside with a number of other enterprise requirements. The easiest way to have a look at CRX is to go to http://www.day.com/crx and download a trial version. Since CRX is installed in 5 minutes and offers a nice UI and different file server implementations it is probably the quickest way to get started with JCR infrastructure. [It's certainly my favorite way to get started with a new content repository based project ;) ] CRX is also the backing store of our flagship WCM product Communique which is used by many Fortune 2000 companies for most important web initiatives, proving the reliability and scalability required in enterprise environments. regards, david
  7. It is important to stress though that Jackrabbit at its core is designed to be rock solid, fully transactional and very scalable if configured and tuned properly.
    Ignoring the obviously weak (and insulting) cop-out at the end I noticed you stated "designed" and not "implemented" or "developed". Was this a slip or intentional? I also note you say "fully transactional" but not transactional correct or safe. There are many applications and frameworks that use transactions but that does not necessarily mean they are transactional safe - the integrity of the business business data and workflow has been correctly mapped to one or more underlying resource transactions. During my performance investigation I uncovered numerous issues with how transaction management is handled across the various subsystems of the JackRabbit implementation. The customer did look at Day CRX but it was found to be practically the same except for added value enhancements in terms of easy install and UI. David can you please state clearer the relation between the JackRabbit implementation and Day Software's CRX? You apparently passed up this opportunity. Now I am assuming when you talk about "fully transactional" you are referring to the use of the database for storage and not an actual filesystem which is obliviously not transactional. With regard to the use of a database back-end to support the storage of repository data (meta data and versioning data included) I refer you to following blog category that lists 3 blog entries related to transactional inspections performed against the software and transactional execution model of JackRabbit. JackRabbit: Automated Transaction Analysis Inspections http://blog.jinspired.com/?cat=40 For those that have a problem accepting the analysis from a commercial software tool you can visit the JackRabbit JIRA issue tracking system and search for issues related to transaction management , JDBC connection management and JCA. The mailing lists also provides a great deal of insight into thread safety issues still be addressed. I found JackRabbit the easiest JCR implementation to embed with an application (web and standalone server) and it support for the JCR specification appears complete. The mailing list is active and the team very responsive. But I could not recommend JackRabbit as it stands today for any production deployment that was not running on a developers workstation. By the way I do see that at least one other person has agreed 100% with my analysis. - William
  8. JackRabbit: Automated Transaction Analysis Inspections
    http://blog.jinspired.com/?cat=40
    Your blog doesn't allow comments, so I'm responding here. I haven't digged deeper at your results, but it seems like your tool is flagging generic issues that are not real problems in Jackrabbit. Jackrabbit handles most transaction semantics by itself on a level above the underlying database connection so things like an UPDATE before a SELECT in the same database transaction is not a problem. Likewise, Jackrabbit keeps a single database connection (as you noticed) per persistence component, but explicitly controls concurrent access and transaction boundaries for that connection, so simply labelling accesses from separate threads (as you've done) doesn't mean that it actually is an error. I guess it's a good example of not taking the output of your tools at face value. I'm not saying that the Jackrabbit code in question really is error-free (there are bugs in all non-trivial code), but the examples in your blog don't seem to conclusively indicate actual errors. The JXInsight tool itself looks pretty slick! I'd love to test drive it and dig deeper into the flagged issues to better qualify them.
  9. Comments are enabled on more recent messages. If you read the blog entry titled "Concurrent Transactional Access" you will see two threads accessing the same underlying connection managed by JackRabbit. Whilst one thread is processing a ResultSet created by the same connection another is committing on the same connection - which in most driver implementations invalidates ResultSets associated with the active transaction. The call stacks within the snapshots clearly point out the calling code - org.apache.jackrabbit.core.cluster.DatabaseJournal.synch(). This happens during Session.save(). Another transaction analysis inspection we have recently created but not yet released is the calling of java.sql.Connection.close() whilst a transaction is active. During testing against MySQL the customer did not run into this problem but when they migrated to DB2 the driver refused to perform the close operation. I think the cause here was again the clustering mechanism but I need to check the snapshots or diagnostics images to be sure. The other blog entries point out the underlying cause to lost updates the customer experienced which were caused by the transaction design (chopping) and the database design (referential integrity is not maintained by the database for child nodes). The data was in the database (we counted the recorded as it was impossible to see from the readable columns) but the program could never navigate to the nodes. The 10 hour startup after a local workspace corruption finally killed the use of JackRabbit. This was with only 25% of the operational data loaded into the repository. I believe during re-initialization of the Lucene index and other workspace data all digital artifacts were reloaded again and again. For your information I was one of those that remained supportive of the JackRabbit solution after I wrote some AspectJ aspects to circumvent the transaction bugs and concurrent thread operations. But to be honest I did this because when I did look around the alternatives did not look that much more mature and I had already spent time creating a software performance execution model to drive capacity planning for production. All of the issues mentioned in the blog have been validated by the development and testing team. No one is making up stories. Maybe some of the issues have been solved in the next release but for this project it was too late - the goodwill had run out. Sorry. - William
  10. two threads accessing the same underlying connection org.apache.jackrabbit.core.cluster.DatabaseJournal.synch
    Clustering support in Jackrabbit is quite new. Maybe this problem is already solved, if not please log a bug: https://issues.apache.org/jira/browse/JCR.
    Another transaction analysis inspection
    Maybe you should tell us more about your product?
  11. "Maybe you should tell us more about your product?" Thomas on the defensive and completely avoiding the issues raised. Instead trying to deflect the focus away. Lame. For your information when I first investigated the transactional issues I looked at own product because I did not believe the results. After running through our own tests I then created a completely separate adhoc tool based on AspectJ that would validate the observations. The output from the aspects did indicate the same transaction access patterns. That said I do believe that one of the inspections is not valid anymore since the 1.3 release. To be frank you do not need to be a genius to realize that once you have a number of distinct resource connections transactional accessed during a single repository session transaction you were always going to have transaction integrity problems in the event of faults unless a JTS transaction manager is used to coordinate the commit across multiple XA resources. Yes clustering is new but I cannot see how anyone could use a content repository without this being available. William
  12. filesystem which is obliviously not transactional
    This depends on what you do. Making a file system transactional is not so hard, you don't always need a database.
  13. > filesystem which is obliviously not transactional

    This depends on what you do. Making a file system transactional is not so hard, you don't always need a database.
    Well, actually, making a file system transactional in a performant and scalable way IS actually pretty hard. Building some sort of transactional service that stores data in a non-transactional file system is however easier. Not easier than using a database though.
  14. Hi William, Thanks for your comments and please let me apologize for the delay. As you may know as the Spec-Lead of JSR-170 Day Software wanted to make this JSR as open as possible within the boundaries of the JCP and therefore also wanted to make sure that the code that we used for the reference implementation was going to be used in a true open source project. This is why we initiated the Apache Jackrabbit project and that's also why we contributed our code for the Reference Implementation through the "Incubator" at the Apache Software Foundation. We are happy to see that the Jackrabbit community has grown into a mature Top Level Project at Apache and into a solid piece of infrastructure that is used by a growing number of products and projects. I would like to respond to your inquiry with respect to the relation between the Jackrabbit and the CRX codebase. It is true that we contributed a lot of the Jackrabbit codebase and we are actively working on both our commercial CRX offering and on the open source Jackrabbit project and try to leverage our efforts on one project on both ends. While we are fully committed to Jackrabbit and we are from a "code management" perspective interested in a codebase that is as close as possible (which gives us for example better QA coverage for both projects) we still retain a number of features or capabilities reserved for our commercial product for the time being. This happens due to licensing issues of third party components, lack of interest of the community or simply enterprise features that we choose to reserve to our commercial customers. You are cordially invited to contribute as much of your expertise to the evolution of Jackrabbit. As much as we all aspire to write perfect software, I am very happy about every new bug that is reported since after all it is the only proof of an active community and an actively evolving project. regards, david
  15. Hi David, Thanks for all your excellent work in the Java content repository field. I find it interesting that you mention the user interface in your comment. I mention my UI experience working with JCR implementations in my article on JSFCentral.com. Basically, I evaluated many Java CMS implementations (some JSR-170 compliant, others not) such as Magnolia, Exo Platform, Alfresco, OpenCMS, Daisy, etc. and I found that they all lacked UI design flexibility. I decided to stop evaluating solutions and to start building my own, using JavaServer Faces (JSF) on the front end and JackRabbit as the CMS backend. (This approach is mentioned by Dave Ockwell-Jenner above.) As a UI designer, the ability to customize the look and feel of a system using standard UI design tools and techniques is critically important to me. Since I switched from pre-packaged systems to JSF with an integrated CMS approach, I haven't looked back. A glorified, AJAX-enabled browser-based WYSIWYG editor is no substitute for professional UI design tools! While web-based content editing is ideal for end-users, it is not suitable for serious UI development. Trying to shoe-horn graphics, images, and HTML into a web application through various floating dialog windows is NOT my idea of fun. :-) Are there any plans to simplify the UI customization features of Magnolia or other CMS systems that you are aware of? Ian Hlavats JSFToolbox - Design JSF Pages in Dreamweaver
  16. Hi Ian, Thanks a lot for your comments.
    I mention my UI experience working with JCR implementations in my article on JSFCentral.com.

    Basically, I evaluated many Java CMS implementations (some JSR-170 compliant, others not) such as Magnolia, Exo Platform, Alfresco, OpenCMS, Daisy, etc. and I found that they all lacked UI design flexibility.

    I decided to stop evaluating solutions and to start building my own, using JavaServer Faces (JSF) on the front end and JackRabbit as the CMS backend. (This approach is mentioned by Dave Ockwell-Jenner above.)
    I think it depends what one is looking for. In my experience I found that there are quite a number of very different requirements that people try to "model" into the term CMS or WCMS. In my experience it may range from extremes like a Wiki/Filesharing/Mailarchive/Collaboration/Intranet (which I would say is all about information sharing) to a Corporate/Regulated/HighlyBranded/HighTrafficed/PublicWebsite (where I would say everything is about control and process). Personally, I believe that there are different solutions to the different requirements, but they all share the need for some heavy lifting around access control, versioning, search, structured and unstructureed content etc. which are very well served by a JCR compliant content repository. I think JCR enables people to build Content (Management) Applications very quickly without having to learn a proprietary interface, much like SQL allowed people to build Database applications much more efficiently, and I think that JCR really allows someone to use JSF directly and efficiently on top of for example Apache Jackrabbit.
    As a UI designer, the ability to customize the look and feel of a system using standard UI design tools and techniques is critically important to me. Since I switched from pre-packaged systems to JSF with an integrated CMS approach, I haven't looked back.

    A glorified, AJAX-enabled browser-based WYSIWYG editor is no substitute for professional UI design tools! While web-based content editing is ideal for end-users, it is not suitable for serious UI development.
    I guess i couldn't agree more. I think the idea of a WCMS really is to make the frequent and labor intensive "content updates or creation" as simple as possible but I don't think that any WCMS would like to be compared to Dreamweaver or even Photoshop when it comes to ease of use for a designer. In our projects we usually let site designers work in their favorite tools, and then take their output and have a very efficient way of creating so-called "Templates" from that, to allow business users to create their 100'000 pages worth of content with, yet retain the flexibility that the designer intended. I agree with you, that WCMSs in the past have focused a lot on the content author as the main audience, and I think it is time for our industry to think some more about the role of the site designer and integrate designer tasks well into our systems. regards, david
  17. I really like the Java Content Repository (JCR) API but the default reference implementation Apache JackRabbit is simply not suitable for any application that has a requirement for more than one concurrent/active session.
    As a member of the Apache Jakcrabbit project I'm obviously biased, but this is not my experience at all. Of course there are open issues with Jackrabbit (like there are in any actively developed product) and I'm sorry if you've been hit hard by some of them, but I think you are generalizing quite a bit there. See for example http://wiki.apache.org/jackrabbit/JcrLinks for a list of applications that are using Jackrabbit and/or JCR.
    The JackRabbit implementation from 1.1.x onwards has been plagued with performance and concurrency problems that appear practically impossible to remove without major architectural changes (which by the way the architect has accepted).
    Jackrabbit already had pretty good performance in the 1.0 release and both 1.2 and 1.3 releases introduced performance improvements for various use cases. What we are seeing is new users applying Jackrabbit in various different use cases that not all are equally well handled by the 1.0 architecture. In response to that we are implementing changes that allow Jackrabbit to deliver good performance to a wider range of applications. You are implying that Jackrabbit has poor performance in general which I think is unfair given that there are a number of applications that Jackrabbit already serves well. It seems like you've already abandoned Jackrabbit, but in case I'm wrong I'd be happy to discuss the specific issues you faced in more detail and see how we could address the problems. There's one issue in your list that I as the release manager find explicitly incorrect:
    Every release breaks the previous configuration or system behavior especially with undocumented config name changes. One has to look at the JIRA issue tracking system to determine what the new configuration should look like.
    All the Jackrabbit releases so far have been backwards compatible. No changes to existing configuration files or stored data should have been needed unless you've wanted to start using the new features available in more recent releases. So far we've seen no complaints about this so please let us know what your problems were! To summarize, Jackrabbit is already a good solution for many applications (especially if you need the full flexibility of the JCR API) and we are actively working on making Jackrabbit support new kinds of workloads and use cases. More and more people are adopting Jackrabbit as evidenced by the increase of user list subscriptions (blue line) at http://people.apache.org/~coar/users_jackrabbit_apache_org.png. We also have a very promising roadmap for Jackrabbit 1.4 later this year and 2.0 next year, so stay tuned for exciting new stuff coming up. :-) And, if it turns out that Jackrabbit isn't the right tool for you, you can always switch to another JCR implementation that better matches your needs. That's the true value of the API!
  18. Magnolia - Simple Enterprise Content Management - is arguably the first project using JSR-170 and specifically JackRabbit. As one of the founders, I dare to comment on this thread. The observations made here about certain inadequacies of JackRabbit may be true or not. If they are true, its excellent they are exposed, as it will help the JackRabbit project resolve them. But I think thats not the important point. The important point is that with JCR-170 we finally have a standard API that is really useful in the CMS world. I think all of us in the content managing world have and will benefit greatly from the existence of it. (discount those that miss the transition from non-standard to standard repository) The fact that a standard exists allows us to analyze its shortcomings and improve it. The fact that JackRabbit exists as a free and open source licensed fully compliant JSR-170 implementation is simply amazing if you think about it. Whatever JackRabbit suffers from can be fixed by any of us if we wanted to. Maybe it will, maybe not. But as Jukka put it, the standard is here and available for free (open standard!) so if you think you can do better, go ahead. You are really welcome, as we, at Magnolia (and any other JCR-170 compliant application that has a pluggable repository architecture), can simply switch to any compliant implementation. And thats pretty brilliant for all of us.
  19. JBoss Rules uses JackRabbit[ Go to top ]

    We've used JackRabbit as the basis for our BRMS, http://markproctor.blogspot.com/2007/05/brms-has-landed.html. It's been hard work, as the api isn't always obvious, and we are using it for more than just storing files, as it also does our meta data tagging and configurations. Performance seems ok, but we've yet to be battle tested, so I guess we'll find out soon enough :) Mark Proctor http://markproctor.com/
  20. Good Experience[ Go to top ]

    My experience with Jackrabbit has always been very good. Pretty easy-to-use API and decent enough architecture. Scales pretty well, and probably the prove is that very well known portals are built with this tool. In my opinion the Jackrabbit mailing lists have always been an amazing and helpful place, either for easy-to-solve-and-very-repetitive questions or for really more complex questions. Jukka and his team has always done a very good job. In my oppinion, very recommendable product. Of course, you have to heavily test it to see if really matches your scenario. I don´t understand things like suddenly putting a product in pre-production in your customer and then complain about all the unexpected problems found. Normally this kind of things require months of previous analysis (unless you´re already fire-stopping), participation in mailing lists to receive help and also, why not, help to improve all the difficulties. I´m pretty sure that if those problems are already Jackrabbit problems, Jukka's team would be more than happy to help or to incorporate the addequate SVN patches to Jackrabbit's trunk. Regards, Martin
  21. Great Community[ Go to top ]

    Hi All, As a relative newbie on JCR, I have found the JackRabbit community indeed very stimulating. Whenever I had a problem, I had replies (the plural is not a typo) within the day. This makes all the difference. (even from David himself who probably cumulates a dozen jobs. ;-) It's probably true that some corners aren't well polished yet. I haven't come across one yet myself but ... the API is brand new, that's probably to expect when playing early bird with cutting edge technology. (remember EJBs? We're almost 10 yrs down the line and they still suck :-) Keep up the good work! -Wolf Ps Any plans with DB4O as a content store?
  22. If you have a hammer, everything looks like a nail. If you have a hammer, everything looks like a nail. If you have a hammer, everything looks like a nail. Now I feel better...
  23. Everything is content[ Go to top ]

    Jackrabbit may has its problems in thread and XA‑handling, but please name me one database vendor who has not had issues in this highly complex area. But this is really not the point I want to make here. I rather believe that this discussion thread is missing the clue. JCR really shines when it comes to enterprise architectures, and I think in this context we need to understand Nuescheler's statement that "everything is content". From my modest point of view, the JCR API represents a completely new architectural layer, and this statement is true for most types of applications, not only for CMS. Let's have a look on what JCR is *not*: it is not a new middleware such as JDBC, or a persistence abstraction such as EJB3 or JDO, nor a OR-framework such as Hibernate or Toplink and much less an actual data storage. Much more, it is a new and compelling way to abstract data and control access to it. In a common J2EE architecture, JCR lays somewhere between the business logic and above the actual persistence layer. This opens way for thousands of new possibilities. It is an abstraction layer to all possible data sources, including relational DBs, object DBs, LDAPs, content and document repositories, files, etc.. JCR provides access to many consumers, not only Java clients, by exposing a uniform access path to its data to all sorts of clients. However, that Nuescheler's vision of "everything is content" becomes true, many things still need to happen. We need to build up a "JCR mindset", i.e. how we can model the information structure of an enterprise in JCR. There is an analogy with the 80s and 90s: many companies tried to design relational "enterprise data models" to define their core data entities of their respective businesses. Yesterday, we modeled services. Today, we should start to structure the information of our enterprises "the JCR way". All relevant storage players in the market should be forced to supply JCR APIs. For instance, I currently work with a major financial institution, more precisely in their electronic records management dept. where hundreds of terabytes of documents are managed using different world-class DMS products. None of these offers a JCR API yet. It would probably heavely facilitate the integration of these data sources if we had JCR on top of these systems. But what new problems would arise? How easy would it actually be? What if vendor A offers a complete different JCR structure and nodetypes from vendor B? Hence, I think the industry is still miles away from "everything is content". We are lacking the mindset and the experience. Still, at least to me, it is a very feasible way to go. The repository paradigm and JCR have such a huge potential that one day the discussion around it could even overrun the currently ubiquitous SOA debate. Juerg Meier Cambridge Technology Partners, Zurich A Novell Business
  24. Re: Everything is content[ Go to top ]

    What will happen with the major vendors in DMS for drivers is what happened with Oracle/DB vendors who dragged their feet on the JDBC levels: 1. Third parties will fill the void 2. the DMS with the best third party JCR driver will start getting all the new java projects 3. DMS's realize that relying on a third party as a primary or sole selling aspect for selecting your platform is a BAD IDEA and they release level 4 drivers. Documentum plans on a read-only driver last I read. Meanwhile, all it will take is a few of the major players using the big guys to decide to throw some resources at the JCR, and Jackrabbit becomes a SERIOUS player. The fact that some eager developers are so anxious for Jackrabbit indicates the demand for this is pretty high. I can't wait until the org I work for is in a position to chuck its current reliance of Documentum.
  25. Re: Everything is content[ Go to top ]

    To be honest I think there is a big difference between a content management system (solution) and a Java content repository such as rules & workflow engines. I always thought that most of the JCR implementations would provide a read-only interface on-top of existing repositories. During my time at HP OpenView were I tried hard (and hopefully succeeded) to convince them of the difference between a configuration management model and a configuration information model in the context of a ITIL CMDB I viewed the JCR API as the ideal adapter interface to standardize on for repository integrations. The JCR API should make it easy to layer the interface on top of existing information models today at least for level one (READ-ONLY) implementations. Unfortunately it seems the industry and open source community are more focused on creating another transactional database management solution rather than simplifying the creation of level one implementations. I hope in the next release of JCR that some effort is made to create a service provider interface that includes concrete and abstract implementations of the typical JCR components (session management, searching,...) so that the development effort to layer on top of an existing read-only information source is minimal. - William
  26. Re: Everything is content[ Go to top ]

    What will happen with the major vendors in DMS for drivers is what happened with Oracle/DB vendors who dragged their feet on the JDBC levels
    This scenario is well possible. Are out there already any 3rd party JCR "driver" vendors? -- Juerg
  27. For instance, I currently work with a major financial institution, more precisely in their electronic records management dept. where hundreds of terabytes of documents are managed using different world-class DMS products. None of these offers a JCR API yet. It would probably heavely facilitate the integration of these data sources if we had JCR on top of these systems.
    Do they accept a not transaction-safe solution?
    None of these offers a JCR API yet. It would probably heavely facilitate the integration of these data sources if we had JCR on top of these systems.
    This is a good example of the "If you have a hammer, everything looks like nail" Anti Pattern. You better use a domain specifc solution like this: http://www.compositesoftware.com/products/cis.shtml
  28. Do they accept a not transaction-safe solution?
    The JCR spec supports the notion of transactions. If an implementation supports them (support is non-mandatory), it's got to be the JTA. But as we know, the challenge with transactions is not defining an API (which is even a rather simple issue) but to implement it. That's the duty of the underlying datastore, a DMS for instance. So, things won't get any better or worse with JCR.
    This is a good example of the "If you have a hammer, everything looks like nail" Anti Pattern.
    You better use a domain specifc solution like this: http://www.compositesoftware.com/products/cis.shtml
    Right, I forgot to mention what JCR is not: it is not a data integration server such as the BEA Acqua Logic Data Services Platform (formerly known as "Liquid Data") or Composite Information Server. Their vendors should rather think about offering a JCR interface to their respective products besides WS and JDBC (by the way, doesn't your preferred anti-pattern also apply with JDBC?), thereby adding XPath search capabilities to this category of products. -- Juerg
  29. The JCR spec supports the notion of transactions. If an implementation supports them (support is non-mandatory), it's got to be the JTA.
    That's good to know, but you should post it here: http://issues.apache.org/jira/browse/JCR
    by the way, doesn't your preferred anti-pattern also apply with JDBC?
    No, it only applies to abuse of a tool or api. I would never compare JDBC with a hammer, it's more like a SwissTool.
    ...thereby adding XPath search capabilities to this category of products.
    Ever tried to parse a 1GB XML file with Dom4J?
  30. Refactor -> Change thread karma[ Go to top ]

    After reviewing the whole thread, I have to admit there is too much bad karma (also caused by me). That's not good. So, I wanna add this: - the JCR has a good api design - after this discussion, I guess JackRabbit will be soon the most reliable JCR - I would not hesitate to use JackRabbit in my own projects - David Nüscheler has excellent presentation skills - Eugene Ciurana is my one and only home video hero!
  31. Excuse my ignorance[ Go to top ]

    Excuse my ignorance.. but why do I need a content repository? Would the use of a content repository be restricted to storing things like documents?
  32. Re: Excuse my ignorance[ Go to top ]

    Excuse my ignorance.. but why do I need a content repository?

    Would the use of a content repository be restricted to storing things like documents?
    I usually try to describe a content repository as the best of both worlds between relational databases and the filesystem. While a relational Database allows you to deal with fine grained information in a transactional and scalable way, it is usually assumed that a file system is the right place to store more coarse grained information in larger files in a hierarchy and apply access control on top of that. A content repository covers both areas and therefore in my mind it is the next evolutionary step around persisting information (which we call content, in the context of a content repository). More importantly in addition to the capabilities that we find in databases and file systems the content repository also exposes concepts such as versioning, fulltext search or ordering which are concepts that I would argue every application needs today. In my opinion, the content repository is ideal to store (almost;)) any kind of information, and I will certainly never use a "lesser" content/information store for any of my applications. regards, david
  33. Re: Excuse my ignorance[ Go to top ]

    In my opinion, the content repository is ideal to store (almost;)) any kind of information, and I will certainly never use a "lesser" content/information store for any of my applications.
    You're still wrong, but you are moving in the right direction. ;-)