Re: [jr3] Delayed Repository Initialization
On Mon, Mar 1, 2010 at 5:41 AM, Thomas Müller thomas.muel...@day.com wrote: The question is: should Jackrabbit 3 *require* (like now) that the credentials for the storage are included in the repository configuration? I think for some storage backends it should not require that. Instead (only in those cases), it should initialize the I am not clear what credentials you are refering to and how current jackrabbit works with backend login. If it's related to storage backend, it need always store on repository level. Repository initialisation will need the backend credential to ensure db schema is there. Session login credential shouldn't related to backend storage such as jdbc username/password. Unless we designed to map jcr session user to jdbc user. -Guo
Re: [jr3] Delayed Repository Initialization
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 # param name=user value=/ # param name=password value=/ 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=sapassword=xyz; RepositoryFactory factory = (RepositoryFactory) Class.forName(factoryClass).newInstance(); MapString, String parameters = new HashMapString, String(); 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(); MapString, String parameters = new HashMapString, String(); 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
Re: [jr3] Delayed Repository Initialization
Hi, -1 on defining this on this isolated level. This should be part of a broader concept of how to architect/structure JR3 and its backend connections. Regards Felix On 28.02.2010 16:40, Thomas Müller wrote: Currently Jackrabbit initializes the repository storage (persistence manager) when creating the repository object. If the repository data is stored in relational database, then the database connection is opened at that time. I suggest to allow delayed initialization (allow, not require). For some storage backends, the repository could initialize when opening the first session. Example: 1) String url = jdbc:...; RepositoryFactory factory = (RepositoryFactory) Class.forName(factoryClass).newInstance(); MapString, String parameters = new HashMapString, String(); parameters.put(url, url); Repository rep = factory.getRepository(parameters); 2) String user = ..., password = ...; Session session = rep.login(new SimpleCredentials(user, password.toCharArray())); This example uses a relational database as the storage. When creating the repository object, user name and password are unknown, so the repository could not initialize at that time. Only when the first user logs in, the user name and password are known. In this case, the user name and password of the session would match the user name and password of the storage backend, but that's actually not a requirement (it's just an example). The current Jackrabbit architecture doesn't support this 'delayed initialization' use case yet. I suggest that Jackrabbit 3 should support such delayed initialization. Whether or not we will implement storage backends that actually do use this mechanism is another question. Regards, Thomas
Re: [jr3] Delayed Repository Initialization
On Mon, Mar 1, 2010 at 11:50, Thomas Müller thomas.muel...@day.com wrote: String factoryClass = ...; String url = ...?user=sapassword=xyz; RepositoryFactory factory = (RepositoryFactory) Class.forName(factoryClass).newInstance(); MapString, String parameters = new HashMapString, String(); 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(); MapString, String parameters = new HashMapString, String(); 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). Couldn't this be done by a special wrapping Repository implementation? Supposing the configuration of the actual RepositoryImpl is dynamically configurable w/o repository.xml, as it is planned. I think the use case for short configs via URL (like ...?user=sapassword=xyz above) is valid and it's a good idea to support that. For performance reasons in a production instance it probably doesn't make a big difference, since there will typically be at least one (admin) session immediately logging in once the repository is up. Regards, Alex -- Alexander Klimetschek alexander.klimetsc...@day.com
Re: [jr3] Delayed Repository Initialization
Hi, Currently Jackrabbit doesn't support relayed initialization. Unless I misunderstood Felix, he would also like to get rid of this restriction. Just to clarify: my suggestion is *not* about requiring the repository is initialized when the first session is opened. It's also *not* about requiring that the JCR credentials are used to login to the backend storage (in most cases that's not a good idea). This idea is about *allowing* delayed repository initialization. The examples I gave are just for illustration and show *one* possible use case. Couldn't this be done by a special wrapping Repository implementation? That's problematic. Such a wrapper would have quite some overhead. The JCR API is not easily wrapable if you want to do it correctly: you would have to wrap almost every JCR interface and method, including Node and Property. That would be a relatively large memory overhead. You could use the Java proxy mechanism, but that is relatively slow (uses reflection). Regards, Thomas
Re: [jr3] Delayed Repository Initialization
On Mon, Mar 1, 2010 at 14:42, Thomas Müller thomas.muel...@day.com wrote: Couldn't this be done by a special wrapping Repository implementation? That's problematic. Such a wrapper would have quite some overhead. The JCR API is not easily wrapable if you want to do it correctly: you would have to wrap almost every JCR interface and method, including Node and Property. Only if you want to support credentials from Session.login() to be used dynamically for repository configuration, eg. as credentials for a JDBC connection. If all you want is to support short URLs in the RepositoryFactory.getRepository() you don't need to override Session... and as I just noticed, you can obviously do this in the RepositoryFactory (if it knows about JR's RepositoryImpl and can do dynamic configuration). So my +1 was a bit off... I don't see much use in this atm. If it is easy to change jr to allow for lazy initialization along the way, ok, but I wouldn't see this as having less priority compared to other planned changes in j3. Regards, Alex -- Alexander Klimetschek alexander.klimetsc...@day.com
[jr3] Delayed Repository Initialization
Currently Jackrabbit initializes the repository storage (persistence manager) when creating the repository object. If the repository data is stored in relational database, then the database connection is opened at that time. I suggest to allow delayed initialization (allow, not require). For some storage backends, the repository could initialize when opening the first session. Example: 1) String url = jdbc:...; RepositoryFactory factory = (RepositoryFactory) Class.forName(factoryClass).newInstance(); MapString, String parameters = new HashMapString, String(); parameters.put(url, url); Repository rep = factory.getRepository(parameters); 2) String user = ..., password = ...; Session session = rep.login(new SimpleCredentials(user, password.toCharArray())); This example uses a relational database as the storage. When creating the repository object, user name and password are unknown, so the repository could not initialize at that time. Only when the first user logs in, the user name and password are known. In this case, the user name and password of the session would match the user name and password of the storage backend, but that's actually not a requirement (it's just an example). The current Jackrabbit architecture doesn't support this 'delayed initialization' use case yet. I suggest that Jackrabbit 3 should support such delayed initialization. Whether or not we will implement storage backends that actually do use this mechanism is another question. Regards, Thomas
Re: [jr3] Delayed Repository Initialization
Hi, I would prefer to initialise the repository at first place and make sure everything is correctly for repository I wrote: *allow* delayed initialization (allow, not require). If user want delay the initialisation, may create the repository reference only when first accessed. If the credentials are included in the repository configuration (currently they always are; they have to be) then it's of course possible to initialize when the repository object is created. The question is: should Jackrabbit 3 *require* (like now) that the credentials for the storage are included in the repository configuration? I think for some storage backends it should not require that. Instead (only in those cases), it should initialize the repository when the first session is opened. Regards, Thomas
