Re: Jackrabbit integration tests in a separate component

Most of people run the build by default, if we turn on the integration test, it means will run most of the time and it is a big waste. I would suggest turn it off for install stage by default, but turn it on for deploy/release by default. Suggest dev to run integration test when there are big chan

Re: Per-repository thread pool in Jackrabbit

Interesting discussion. There are two problems we had been discussion from my understanding. 1. Global/Main pool or sub-pools for repository wide thread management. Marcel listed a few requirement that each of them may need a separate pool, every pool may have different pool size and other configu

Re: Using Eclipse for Jackrabbit development (Was: Is JCR-1972 going to be included?)

The article should still works, because it follow Michael's instruction. Just noticed it's quite old: August 15, 2007. I did a try for m2eclipse recently and it give much better experience than it's early version. It has a GUI to manage your pom (You don't need to check the pom model manual any mo

Re: Using Eclipse for Jackrabbit development (Was: Is JCR-1972 going to be included?)

On Mon, Jul 13, 2009 at 4:06 PM, Paco Avila wrote: > So using m2eclipse is the preferred way to deal with jackrabbit (subversion) Just personal preference, both tools works WELL. > and eclipse. If I use m2eclipse is necessary to run "mvn eclipse:eclipse" ? No necessary to run this command any more

Re: Code snippets on website no longer syntax highlighted

May caused by 404 error for page style: http://jackrabbit.apache.org/confluence/download/resources/confluence.ext.code:code/shStyles.css On Thu, Jul 16, 2009 at 11:30 AM, Alexander Klimetschek wrote: > Hi all, > > I noticed on http://jackrabbit.apache.org/first-hops.html that the > code parts are

Re: Performance of Jackrabbit

The size of uploaded file may affect the result significantly. I read some email that some one said the uploaded file are stored based on the hash value. This means your 15 unique files only stored/indexed once, it may not the real world case. I am not sure, can any one confirm :) Just FYI. I d

Re: Performance of Jackrabbit

On Thu, Jul 23, 2009 at 12:37 PM, Bart van der Schans wrote: > Iirc there's a similar problem with multi value properties when you > add a lot of values. > > Is there any room left in the current implementation to improve the > performance of those two use cases? Or did somebody already look at it

Re: Performance of Jackrabbit

> I tried using the Derby database to upload 375000 Documents. > > When i tried to add a document to this setup. It took more than 30 mins to > do a checkin, > The system CPU utilization was around 90% to 100% and the JVM heap size also > is around 1.5GB. When did you check out the document? Are y

Re: Performance of Jackrabbit

On Mon, Jul 27, 2009 at 2:56 PM, Ajai wrote: > > Hi Guo, > > Yes, i am adding a document to the repository. > Is there multiple ways to do a save? > > I am doing it the following way, > > fileNode = matterNode.addNode(fileName, "nt:file"); > fileNode.addMixin("mix:versionable"); > fileNode.addMixin

Re: Performance of Jackrabbit

On Mon, Jul 27, 2009 at 3:36 PM, Ajai wrote: > But i do have text extractors and indexes turned on. Sorry, I didn't know how the index affect your result. Good luck! -Guo

Re: Jackrabbit management API

On Thu, Sep 3, 2009 at 4:43 PM, Thomas Müller wrote: >> Think of the complexity of controlling the lifecycle of Derby that >> uses the DriverManager API in JDBC to startup and shutdown the >> database. > > Other databases provide betters ways. For HSQLDB and H2, you close the > database by executin

Re: JCR 1456 Database connection pooling

If connections pools works as an optional configuration for db pm, should be fine. Pool management is not needed at some circumstance, such as container managed datasource connections pool. Thanks! --Guo On Mon, Sep 7, 2009 at 6:47 PM, Martijn Hendriks wrote: > Hi Thomas, > > Existing configur

Re: JCR 1456 Database connection pooling

On Tue, Sep 8, 2009 at 8:27 AM, Martijn Hendriks wrote: > If you use a  JNDI DataSource (by using a javax.naming.Context class as the > driver in the descriptors) then that DataSource is used as-is. The only > change then is that Connection instances are not cached anymore in the DB > component

Re: Merging components

On Thu, Oct 22, 2009 at 8:55 AM, Stefan Guggisberg wrote: > i absolutely agree with thomas. 14 jars sound like way too much... Jackrabbit was build on different open source projects and much more complex than some simple utility library. The total number of jars doesn't concern with me once we ha

Re: Sling's use of Jackrabbit

Hi Felix, It's really necessary to get jackrabbit OSGified. As OSGi get very popular those days. If we don't do it from JR, all other people like sling will do it there. We just add correct OSGi headers all JR projects and that's it. By this way, JR won't affect on it's standalone application as

Re: Sling's use of Jackrabbit

On Fri, Nov 27, 2009 at 7:48 PM, Felix Meschberger wrote: > Hi, > > That's exactly why I intent to go this route. Great to see it happens, hope before 2.0 final release:) > > But it is important to understand that there are some use cases for > dynamic configurability of the embedded Jackrabbit i

Re: Sling's use of Jackrabbit

On Fri, Nov 27, 2009 at 8:20 PM, Felix Meschberger wrote: > Issue is that Jackrabbit is configured with a repository.xml file which > itself refers to optional classes. Most notably these are the > PersistenceManager classes along with their dependencies. So this > provides some issues with settin

Re: Sling's use of Jackrabbit

On Sat, Nov 28, 2009 at 6:22 PM, Felix Meschberger wrote: > That's what we currently do in the Sling embedded repository bundle [1] Hi Felix, Thanks for the reply during weekend:) I saw all dependencies jars are embedded to jackrabbit-server bunlde. Bundle-ClassPath: .,jackrabbit-jcr-rmi-1.4.1.

Re: Sling's use of Jackrabbit

On Mon, Nov 30, 2009 at 9:02 AM, Felix Meschberger wrote: > The problem of Jackrabbit Core is, that apart from implementing the > Jackrabbit API (which is imported in the bundle), it has its internal > API (for example the PersistenceManager interface or others). This > internal API is not properl

Re: Sling's use of Jackrabbit

On Mon, Nov 30, 2009 at 9:59 AM, Thomas Müller wrote: > I would do that only if there is an actual need for it. Do you have > another implementation? Persistence manager, data store, or journal? > If yes, would it be enough to just move the persistence manager > interface, or do we need to do some

Re: Sling's use of Jackrabbit

On Mon, Nov 30, 2009 at 10:44 AM, Thomas Müller wrote: > I would wait until it's a real problem. Trying to solve _potential_ > problems in advance is usually the wrong path. I understand it will take effort/risk to do it. Thanks for the discussion and all your hard works! -Guo

Re: Easy mock dependency

On Thu, Dec 10, 2009 at 3:42 PM, Martijn Hendriks wrote: > What about upgrading the EasyMock dependency from 1.1 to 2.5.2? +1 Before 2.0 release, I would suggest upgrade all our dependencies to latest stable release unless there are known issues. Those dependencies could be sit there for another

Re: change proposal DataStore

On Sun, Jan 24, 2010 at 11:28 AM, JOSE FELIX HERNANDEZ BARRIO wrote: > - Assign a datastore per workspace (customer) so it's possible to measure > (and limit) storage usage for a given customer You may looking for repository as multi tenant solution instead of workspace: http://wiki.apache.org/jac

Re: Out Of Memory Error while indexing

On Tue, Feb 9, 2010 at 1:23 PM, wrote: > > Oh my... sorry everybody for wasting your time, the problem is solved. > > I tried the solution with the search index configuration. It didn't work > for some reason, so I did some more debugging. > During that I found out that there was a bug in my code

Re: Jackrabbit 3: repository requirements

On Tue, Feb 9, 2010 at 3:55 PM, Jukka Zitting wrote: > Now that Jackrabbit 2.0 is out and the major JCR 2.0 feature work is > done, it's time to start looking ahead at Jackrabbit 3. We've talked > about this a bit already at Day and I'll be posting a summary of our > ideas for further discussion,

Re: Jackrabbit 3: extracting same name sibling support from the core

On Thu, Feb 11, 2010 at 11:54 AM, Thomas Müller wrote: > About SNS (same name siblings): what about moving that part away from > the "core"? Currently, the Jackrabbit architecture is (simplified): > > 1) API layer (JCR API, SPI API) > 2) Jackrabbit core, which knows about SNS > > After moving the

Re: Queries not working in Jackrabbit 2.0

On Wed, Feb 17, 2010 at 2:14 PM, Jacco van Weert wrote: > > Hello Marcus, > Yes that works, thanks... the only point is that probably this isn't > backupped by the docs. Not always working on 2.0-alpha12 (when has where condition) :( WORKING: select * from [nt:base] order

Re: [jr3] One workspace to rule them all

On Wed, Feb 17, 2010 at 7:26 PM, Alexander Klimetschek wrote: > Ack. Workspaces can be seen as the top level nodes in a supertree. Looks more like soft branch link in source control system. Then workspace concept may not need any more if we can manage soft link efficiently. -Guo

Re: [jr3] Plugin architecture

On Thu, Feb 18, 2010 at 10:02 AM, Bertrand Delacretaz wrote: > Do you really think Jackrabbit should allow its core plugins to go > away at runtime? No, it's just one of OSGi feature doesn't need here. > i don't mind providing osgi support at a higher level, the core however > should IMO not have

Re: [jr3] Plugin architecture

On Thu, Feb 18, 2010 at 12:07 PM, Alexander Klimetschek wrote: > The import/export XML methods are part of the JCR spec, so we cannot > easily change their well-defined behavior. Instead, to support large > dumps or backups, we should define an API at a lower level, that also > ignores type and co

Re: [jr3] monitoring/instrumentation/JMX

On Thu, Feb 18, 2010 at 1:26 PM, Justin Edelson wrote: > As I mentioned in the JCache thread, I'd like to have Jackrabbit expose > monitoring data (presumably via JMX). The most obvious place for this is > around caches, but I imagine there are other places where monitoring > data could be useful.

[jr3] Pluggable security handling

In JR2.0, there is a security workspace created for all repository. It may not necessary for all the repository use case. In JR3.0, we may have a pluggable security handling api outside core for following use case: * No security at all - up to application to handle security * Tech user login - li

Re: [jr3] Pluggable security handling

On Thu, Feb 18, 2010 at 3:28 PM, Angela Schreiber wrote: > Guo Du wrote: >> >> In JR2.0, there is a security workspace created for all repository. > > this is not true. Lesson learned: disable the security workspace by remove SecurityManager definination from repository.x

Re: [jr3] Synchronized sessions

On Fri, Feb 26, 2010 at 6:11 PM, Jukka Zitting wrote: > All we're trying to achieve here is ensure internal consistency even > when clients do something like the above (for whatever reason, > intentional or not). jdbc connection is not thread safe. jcr session works similar way and I prefer foll

Re: [jr3] Synchronized sessions

On Sat, Feb 27, 2010 at 8:47 AM, Thomas Müller wrote: > "consistency". I don't know of a relational database that allows you > to violate referential integrity, unique key constraints, or check > constraints - simply by using the same connection in multiple threads. jdbc server response for constr

Re: [jr3] Delayed Repository Initialization

On Sun, Feb 28, 2010 at 3:40 PM, Thomas Müller wrote: > I suggest to allow delayed initialization (allow, not require). For > some storage backends, the repository could initialize when opening > the first session. -1 Repository/storage is critical for most of application, I would prefer to init

Re: [jr3] Delayed Repository Initialization

On Mon, Mar 1, 2010 at 5:41 AM, Thomas Müller 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

Re: [jr3] Exception Handling

On Mon, Mar 1, 2010 at 9:32 AM, Michael Dürig wrote: > What about using something like a hash code (for example of the current > stack trace) as error code? These would then automatically serve as hash A good sample to deal with error messages: http://publib.boulder.ibm.com/infocenter/ltscnnct/v2

Re: [jr3] Delayed Repository Initialization

On Mon, Mar 1, 2010 at 10:50 AM, Thomas Müller wrote: > Currently, Jackrabbit requires to be able to create a database > connection when initializing. I was thought like this too :) > It depends on what you mean with "repository level". It doesn't make > sense to store the user name and password

[jr3] support transaction log

I am thinking of database transaction log in jackrrabbit. The log could be replayed to any point of time. http://en.wikipedia.org/wiki/Transaction_log It could be used as efficient backup/recovery/replication scenario. It's different from current cluster configuration which share some storage amon

Re: [jr3] support transaction log

On Thu, Mar 4, 2010 at 11:39 AM, Thomas Müller wrote: > It may slow down writes around 50%. I think it should be an "optional" > feature (some storage backends may not support it at all, and there > should be a way to disable / enable it for those backends that can > support it). I think we should

Re: [jr3] Micro-kernel vs. new persistence

On Thu, Mar 4, 2010 at 12:21 PM, Thomas Müller wrote: > I think the storage API should support some kind of "storage session" > (normally one storage session for each JCR session). For a relational > database, such a session could map to a database connection. I think the session.save() should be

Re: UserManager autosace issue

On Thu, Mar 11, 2010 at 10:51 AM, Felix Meschberger wrote: > I assume this is because the addMember method calls Item.save() while > the parent node has not been saved yet. > > Is this a known issue worth following up to ? It could be a bug as javax.jcr. Item.save() is @deprecated. -Guo

Re: [jr3] Store journal as nodes

On Fri, Mar 12, 2010 at 10:29 AM, Thomas Müller wrote: > The rest of the configuration (fulltext index configuration for > example, workspace names, security, data store configuration, cluster > configuration, node type registry) should be in the repository (as Configuration should be editable wit

Re: [jr3] Store journal as nodes

On Fri, Mar 12, 2010 at 10:52 AM, Thomas Müller wrote: >> cluster host information. > What is that exactly? In case of cluster db journal, the hostname of db connection. >> Configuration should be editable without boot the repository. > Why? Again, for db store, if db host changes after repositor

Re: [jr3] MicroKernel prototype

On Tue, Mar 16, 2010 at 6:46 PM, Thomas Müller wrote: > With the JDBC storage and the H2 database, this is about 14 times > faster than the Jackrabbit 2.0 trunk (0.2 seconds versus 2.9 seconds Thanks for the exciting result. In your opinion, which part make the most of performance contribution? D

Re: [jr3] MicroKernel prototype

On Wed, Mar 17, 2010 at 9:34 AM, Thomas Müller wrote: >> In your opinion, which part make the most of performance contribution? > It's hard to say. I would rather spend my time to work on the > prototype than to find out. To keep the prototype fast, it's important Understand it will take effort to

Re: [jr3] MicroKernel prototype

On Wed, Mar 17, 2010 at 4:45 PM, Stefan Guggisberg wrote: > jackrabbit is the reference implementation of JCR 1.0/2.0 and therefore has > to fully support all the spec'ed features (node types, same name siblings, > locking, access control, etc etc). I agree that the default distribution should com

Re: [jr3] MicroKernel prototype

On Wed, Mar 17, 2010 at 6:42 PM, Thomas Müller wrote: > I'm wondering what is the *most* problematic features to verify the > architecture: > - security > - orderable child nodes > - same name siblings > - locking > - transactions > - clustering > - observation > - workspaces > - node types > - la

Re: [jr3] MicroKernel prototype

On Thu, Mar 18, 2010 at 10:24 AM, Thomas Müller wrote: >> - security >> - locking >> - scalability (number of concurrent sessions and repository size) >> - transactions > OK, I will then try to implement (prototype) those features now. Hi Thomas, no push to those features. Take your time and prior

Re: [jr3] Node Identifiers / Corresponding Nodes

On Sun, Apr 18, 2010 at 10:36 AM, Thomas Müller wrote: > UUIDs: allows distributed creating of nodes. That's why the Jackrabbit > 3 data format should support UUIDs as node ids: for cloud storage > mechanisms. I am thinking of support path as ID, the use case could be file system based backend su

Re: No more Confluence

On Thu, Apr 22, 2010 at 10:08 AM, Jukka Zitting wrote: > So I'm wondering whether we should ditch Confluence and switch back to > publishing the site via svn and leveraging our MoinMoin wiki for all > the things where browser-based editing is desired. As Jackrabbit is mainly designed for content m

Re: FYI: Moving session-related classes to o.a.j.core.session

On Mon, May 17, 2010 at 10:16 AM, Jukka Zitting wrote: > These unrelated classes are mostly things like RepositoryImpl, > TransientRepository, RepositoryCopier, etc. to which many external > codebases are linking, so we can't move them. All class inside core has possible reference for user code ba

Re: Diagram of Jackrabbit remoting options

On Tue, Jul 20, 2010 at 1:00 PM, Marc Herbert wrote: > I tried to summarize Jackrabbit remoting options on a PDF diagram posted here: It is hard to access the information in a wrong ROTATED PDF file. The component diagram has too much package involved. Need focus on the components and their relat