Firstly because it neatly separates the JCR dependencies from the deployed application (no Jackrabbit files at all in the EAR/WAR, just the JCR API jar).
Secondly, it separates all of the configuration of JCR away from the application and into the application server (aka deployment time). The application has no requirement to know about anything but the single JNDI resource. Thirdly, it allows for easier management and monitoring of the JCR resource (ie: monitor the thread pool etc... allowing to see what the JCR resource utilises separate to the application that uses it, so you can see the separate CPU/Memory/Network usage of the JCR to the application - much more useful than the CPU/Memory/etc.. of the application and JCR bundled into one - or at least making it a lot more difficult to report on the separate stats). Lastly, it's the "vibe". ;) These were only the first that came to mind, there could be more. -- Cory On 09/09/2010, at 4:46 AM, Justin Edelson wrote: > Cory- > Just curious... why is the JCA packaging so attractive to you? > > Justin > > On Sep 8, 2010, at 1:32 PM, Cory Prowse <[email protected]> wrote: > >> Firstly, apologies for the duplicate email (bad network connection atm). >> >> I'll have a crack at it in a week or so, will probably pester the list for >> insights into code (or should I send to dev list? it seems to be mostly SCM >> commits). >> >> Shame to hear it might be deprecated as that would be my preferred >> deployment on JEE. >> >> -- Cory >> >> On 09/09/2010, at 3:07 AM, Jukka Zitting wrote: >> >>> Hi, >>> >>> On Wed, Sep 8, 2010 at 6:44 PM, Cory Prowse <[email protected]> wrote: >>>> I await with bated breath in hope of a JCA Jackrabbit guru to jump on it. >>> >>> We're a bit short on JCA gurus here, as AFAIUI none of the active >>> committers use JCA. >>> >>> The jackrabbit-jca connector was contributed quite a while ago [1], >>> but has since lacked an active maintainer. I and a few other >>> committers have applied patches that people have been contributing >>> against the JCA codebase, but so far none of those contributors have >>> stuck around long or consistently enough to become committers >>> themselves. >>> >>> I'd love to help out if there are people willing to look at fixing >>> some of the open JCA issues [2]. Without someone to maintain the JCA >>> codebase we'll eventually need to deprecate and drop it. >>> >>> [1] http://markmail.org/message/lx7tif4j5cyfy3vo >>> [2] http://s.apache.org/jackrabbit-jca-issues >>> >>> BR, >>> >>> Jukka Zitting >>
