jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul Skinner" <Paul.Skin...@gossinteractive.com>
Subject RE: [jira] Resolved: (JCR-245) Automatic repository shutdown
Date Fri, 09 Dec 2005 10:15:38 GMT
Hi Jukka,

I have just updated my JackRabbit and the JackRabbit build fails. I am
using java 1.4.2 and the failure is in the testGetDescriptorKeys()
method of the TransientRepositoryTest class. The code uses a java 1.5
specific method "Collections.addAll(keySet, keys);"

I am guessing that this method/code was added as a result of fixing
issue http://issues.apache.org/jira/browse/JCR-245 but prevents a
successful build if using a java earlier than 1.5


> -----Original Message-----
> From: Jukka Zitting (JIRA) [mailto:jira@apache.org] 
> Sent: 09 December 2005 09:54
> To: jackrabbit-dev@incubator.apache.org
> Subject: [jira] Resolved: (JCR-245) Automatic repository shutdown
>      [ http://issues.apache.org/jira/browse/JCR-245?page=all ]
> Jukka Zitting resolved JCR-245:
> -------------------------------
>     Fix Version: 1.0
>      Resolution: Fixed
> Committed the proposed TransientRepository class in revision 
> 355430 with the following changes:
> * Added a simple TransientRepository.RepositoryFactory 
> interface to allow greater control over the repository 
> initialization process
> * Added a two utility constructors
> * Added an initial test case for the TransientRepository 
> class (more complete unit testing would require a separate 
> test repository or setting up mock RepositoryImpl instances)
> > Automatic repository shutdown
> > -----------------------------
> >
> >          Key: JCR-245
> >          URL: http://issues.apache.org/jira/browse/JCR-245
> >      Project: Jackrabbit
> >         Type: New Feature
> >   Components: core
> >     Reporter: Jukka Zitting
> >     Assignee: Jukka Zitting
> >      Fix For: 1.0
> >  Attachments: TransientRepository.patch
> >
> > Currently Jackrabbit relies on two mechanisms for safely 
> shutting down a repository:
> >     1) client application invoking RepositoryImpl.shutdown(), or
> >     2) the shutdown hook installed by RepositoryImpl being 
> run Both of 
> > these mechanisms have problems:
> >     1) The shutdown() method is not a part of the JCR API, 
> thus making the client application depend on a 
> Jackrabbit-specific feature
> >     2) In some cases the shutdown hook is not properly run 
> (see issues 
> > JCR-120 and JCR-233) I think the JCR spec thinks of the 
> Repository and Session interfaces as being somewhat similar 
> to the JDBC DataSource and Connection interfaces. The 
> Repository instances have no real lifecycle methods while the 
> Session instances have clearly specified login and logout 
> steps. (DataSource.getConnection() = Repository.login(), 
> Session.logout() = Connection.close()) However the Jackrabbit 
> implementation defines an explicit lifecycle for the 
> RepositoryImpl instances.
> > This causes problems especially for container environments 
> (JNDI, Spring) where it is hard or even impossible to specify 
> a shutdown mechanism for resource factories like the 
> Repository instances. The current solution for such 
> environments is to use a shutdown hook, but as reported this 
> solution does not work perfectly in all cases.
> > How about if we bound the RepositoryImpl lifecycle to the 
> lifecycles of the instantiated Sessions. A RepositoryImpl 
> instance could initialize (and lock) the repository when the 
> first session is opened and automatically shut down when the 
> last session has logged out. As long as the sessions are 
> properly logged out (or finalized by the garbage collector) 
> there would be no need for an explicitly 
> RepositoryImpl.shutdown() call. The current behaviour of 
> pre-initializing the repository and shutting down during a 
> shutdown hook could be enabled with a configuration option 
> for environments (like global JNDI resources) in which the 
> shutdown hooks work well.
> --
> This message is automatically generated by JIRA.
> -
> If you think it was sent incorrectly contact one of the 
> administrators:
>    http://issues.apache.org/jira/secure/Administrators.jspa
> -
> For more information on JIRA, see:
>    http://www.atlassian.com/software/jira

GOSS is a leading Enterprise Content Management provider. GOSS ECM Suite delivers Web Content
Management, EDRMS, Email Management, Digital Asset Management, Capture and IDR and Hosted
GOSS  a leading UK supplier of Enterprise Content Management solutions has won a place in
the Deloitte Technology Fast 50 Awards 2005 for the second consecutive year.

This email contains proprietary information, some or all of which may be legally privileged.
It is for the intended recipient only. If an addressing or transmission error has misdirected
this email, please notify the author by replying to this email. If you are not the intended
recipient you may not use, disclose, distribute, copy, print or rely on this email. 


Email transmission cannot be guaranteed to be secure or error free, as information may be
intercepted, corrupted, lost, destroyed, arrive late or incomplete or contain viruses. This
email and any files attached to it have been checked with virus detection software before
transmission. You should nonetheless carry out your own virus check before opening any attachment.
GOSS Interactive Ltd accepts no liability for any loss or damage that may be caused by software

View raw message