From dev-return-27425-apmail-jackrabbit-dev-archive=jackrabbit.apache.org@jackrabbit.apache.org Mon Mar 01 10:51:04 2010 Return-Path: Delivered-To: apmail-jackrabbit-dev-archive@www.apache.org Received: (qmail 35155 invoked from network); 1 Mar 2010 10:51:04 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 1 Mar 2010 10:51:04 -0000 Received: (qmail 97027 invoked by uid 500); 1 Mar 2010 10:51:03 -0000 Delivered-To: apmail-jackrabbit-dev-archive@jackrabbit.apache.org Received: (qmail 96970 invoked by uid 500); 1 Mar 2010 10:51:03 -0000 Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@jackrabbit.apache.org Delivered-To: mailing list dev@jackrabbit.apache.org Received: (qmail 96963 invoked by uid 99); 1 Mar 2010 10:51:03 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 01 Mar 2010 10:51:03 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of tmueller@day.com designates 207.126.148.88 as permitted sender) Received: from [207.126.148.88] (HELO eu3sys201aog102.obsmtp.com) (207.126.148.88) by apache.org (qpsmtpd/0.29) with SMTP; Mon, 01 Mar 2010 10:50:55 +0000 Received: from source ([209.85.218.217]) by eu3sys201aob102.postini.com ([207.126.154.11]) with SMTP ID DSNKS4ub9xKzrzT8DmY/UnSsDaro6y6yHL2C@postini.com; Mon, 01 Mar 2010 10:50:35 UTC Received: by bwz9 with SMTP id 9so1675889bwz.25 for ; Mon, 01 Mar 2010 02:50:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.204.39.200 with SMTP id h8mr2922127bke.97.1267440631517; Mon, 01 Mar 2010 02:50:31 -0800 (PST) In-Reply-To: References: <91f3b2651002280740y14b1ecdas5ed1f035870bbdea@mail.gmail.com> <91f3b2651002282141g183b7575u574978d130fd251e@mail.gmail.com> Date: Mon, 1 Mar 2010 11:50:31 +0100 Message-ID: <91f3b2651003010250i192413f1rf110b14081aa1693@mail.gmail.com> Subject: Re: [jr3] Delayed Repository Initialization From: =?ISO-8859-1?Q?Thomas_M=FCller?= To: dev@jackrabbit.apache.org Content-Type: text/plain; charset=ISO-8859-1 Hi, > I am not clear what credentials you are refering to I refer to the database user name and password that are currently stored in the repository.xml (except when using JNDI): http://jackrabbit.apache.org/api/1.5/org/apache/jackrabbit/core/persistence/bundle/BundleDbPersistenceManager.html # # > and how current > jackrabbit works with backend login Currently, Jackrabbit requires to be able to create a database connection when initializing. > If it's related to storage backend, it need always store on repository level. It depends on what you mean with "repository level". It doesn't make sense to store the user name and password of the database inside the database (I hope you agree :-) I would like to make repository.xml optional. To do that, the user name and password for the database need to be stored somewhere else. One solution is to provide them when creating the repository object. Example: String factoryClass = "..."; String url = "...?user=sa&password=xyz"; RepositoryFactory factory = (RepositoryFactory) Class.forName(factoryClass).newInstance(); Map parameters = new HashMap(); parameters.put("url", url); Repository rep = factory.getRepository(parameters); In this case the user name and password are included in the repository URL. This solution is almost what we have how (except there is no repository.xml). What I propose is: Jackrabbit should support the following use case as well: String factoryClass = "..."; String url = "..."; RepositoryFactory factory = (RepositoryFactory) Class.forName(factoryClass).newInstance(); Map parameters = new HashMap(); parameters.put("url", url); Repository rep = factory.getRepository(parameters); Session session = rep.login(new SimpleCredentials("sa", "xyz".toCharArray())); Here, the user name and password of the storage backend (for example a relational database) are not included in the repository URL. Instead, they are supplied in the first session that logs into the repository. Currently this use case is not supported. I suggest that Jackrabbit 3 support this as a possible use case (not necessarily as the default use case). > Unless we designed to map jcr session user to jdbc user. Not necessarily. The "Delayed Repository Initialization" is not related to how Jackrabbit works internally. Jackrabbit might still use only one JDBC connection for the whole repository. Or it might use a JDBC connection pool. Or it might use one JDBC connection per session. Regards, Thomas