Re: poll on jcr query usage

[X] I primarily use XPath [ ] I primarily use SQL [ ] I use both XPath and SQL [X] ... use it /instead/ of the existing XPath or SQL languages. [ ] ... use it only for occasionally. [ ] ... not use it at all.

Re: SPI Contribution: Status

Angela Schreiber schrieb: hi i would like summarize the current status of the SPI contribution, after i spent a couple of days consolidating and testing the work done so far. ... Hi, we are using JCR2SPI with a custom SPI implementation on an existing system. I can report that this really wo

Build failure (one test case)

Hi, with the current Subversion checkout (528441), I'm getting a build failure because of one unexpected test case failure: --- T E S T S --- Running org.apache.jackrabbit.core.nodetype.com

Re: Build failure (one test case)

Jukka Zitting schrieb: Hi, On 4/13/07, Julian Reschke <[EMAIL PROTECTED]> wrote: with the current Subversion checkout (528441), I'm getting a build failure because of one unexpected test case failure: Hmm, you're right. And our Continuum installation seems to be stuck on

Another TCK build issue... (JDK vs XSLT?)

Hi, I've got a very strange build issue, where test cases fail only one one of my two development machines. I'm running JDK 1.4.2 and Maven 2.0.4 on both machines (one XP, one Windows 2003). The failure I'm getting is in org.apache.jackrabbit.test.TestAll: +++ Tests run: 1055, Failures: 0,

Re: [VOTE] Accept JCR Mapping from Graffito

Jukka Zitting schrieb: [ ] +1 Accept JCR Mapping from Graffito [ ] -1 Do not accept the component because ... +1

Re: NGP: Value records

Jukka Zitting wrote: Hi, I started prototyping the next generation persistence proposal discussed before, and would like feedback on an idea on how to store values in this persistence model. My idea is to store each value in a unique and immutable "value record" identified by a "value identifie

SPI F2F?

Hi, while work on the SPI API itself, and the various implementation parts in Jackrabbit progresses nicely, I'm wondering whether it would make sense to get interested people into the same room for a few days. Topics could be: - resolving remaining open issues with the SPI itself, - version

Re: jackrabbit-core maven build failure

Marcel Reutegger wrote: this is caused by a change that I did for JCR-920. I just fixed it a second ago. Merci. no, you don't. this is a somewhat expected result. one of the tests tries to parse malformed XML and checks if an exception is thrown. one side effect using java 1.5 is the fatal e

Re: SPI F2F?

OK, there wasn't any public feedback so far, so we have picked a date suitable for those who did show interest. We will meet on July 2 and 3 in Basel in Day's offices. People interested in joining should send a mail to Angela Schreiber, so that she can ensure we have sufficient meeting space

Re: XPath versus SQL in Jackrabbit

gsoap wrote: Hi, I want to know which one of XPath/SQL is fastest (optimal) while using Jackrabbit? It doesn't matter. Does jackrabbit first translates SQL into XPath before execution? Both are parsed into an abstract query representation. Is there any underlying overhead of translatio

Newbie Maven question

Hi, please excuse the newbie Maven question...: How are dependencies between things in the Jackrabbit source tree meant to work? For instance, contrib/jcr-navigator wants jackrabbit-core version 1.1-SNAPSHOT, which I can't (?) build from trunk, nor is available from repo1.maven.org. Best

Re: Newbie Maven question

Christoph Kiehl wrote: Julian Reschke wrote: For instance, contrib/jcr-navigator wants jackrabbit-core version 1.1-SNAPSHOT, which I can't (?) build from trunk, nor is available from repo1.maven.org. repo1.maven.org doesn't host SNAPSHOT dependencies. AFAIK Jackrabbit SNAPSHOT de

JIRA broken?

Hi, I'm having trouble creating new Jira issues -- Jira claims I'm not using a valid project (which of course is "Jackrabbit"). Does this happen for others as well? Best regards, Julian

JCR-1031 (RowIteratorImpl should make use of QueryResultRow.getValues())

Hi, in the JavaDoc for QueryResultRow, can we define how an SPI impl should behave when one of the properties in the row does not exist? Is null acceptable in that case? Best regards, Julian

Re: [jira] Commented: (JCR-388) add support for RFC 3253 to the simple server

angela (JIRA) wrote: [ https://issues.apache.org/jira/browse/JCR-388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12513525 ] angela commented on JCR-388: so... had a look at the changes and i found the following things. i already

Re: [jira] Commented: (JCR-388) add support for RFC 3253 to the simple server

Angela Schreiber wrote: but that's a different story isn't it? i was talking about the compliance class (and the method set). Probably. I just wanted to make sure that no time is spent on something that is broken in the spec... RFC 3253 defines a separate behaviour for version-controlled c

Re: [jira] Commented: (JCR-388) add support for RFC 3253 to the simple server

Angela Schreiber wrote: > ... leading to the question: will it cause problems if the dav-client can 'see' dav VersionHistoryResources and VersionResources that don't have a corresponding versionable dav resource? or would that be an negligible inconsistency? ... That shouldn't be a problem, bec

Re: Jira troubles

Jukka Zitting wrote: Hi, People have been asking about the recent unstability of the ASF Jira. It seems like the culprit is some external client that keeps requesting huge query results. The infrastructure team is upgrading Jira in a short while and will then be able to explicitly limit the size

Re: Jira troubles

Jukka Zitting wrote: Hi, On 7/27/07, Julian Reschke <[EMAIL PROTECTED]> wrote: Jukka Zitting wrote: People have been asking about the recent unstability of the ASF Jira. It seems like the culprit is some external client that keeps requesting huge query results. The infrastructure t

Re: [VOTE] Release Apache Jackrabbit 1.3.1

Jukka Zitting wrote: Hi, We're still lacking one binding +1 vote to make the release. It would be nice if someone could review the release candidate and/or the test failures Roy is seeing before Monday when I go offline for a full week (vacationing on the coast of the Arctic Ocean). Otherwise th

Re: [VOTE] Release Apache Jackrabbit 1.3.1

Roy T. Fielding wrote: On Jul 27, 2007, at 11:57 PM, Jukka Zitting wrote: If my reasoning is correct, I would treat the issue as a test case bug to be fixed in a future release, and not a blocker to 1.3.1. I don't consider it a blocker. I think it may have existed on 1.3.0 as well, since I re

Re: Jira troubles

Jukka Zitting wrote: Hi, On 7/27/07, Julian Reschke <[EMAIL PROTECTED]> wrote: still can't create new issues. Is this: [...] the same problem others are seeing? There's a number of problems being reported on various forums. They are all caused by Jira running out of memory

Re: Jira troubles

Bertrand Delacretaz wrote: On 7/30/07, Julian Reschke <[EMAIL PROTECTED]> wrote: ...It seems that *my* issue was caused by the fact that I'm running Firefox 3.0 alpha on my development machine. Once I used the latest FF 2.*, all was fine Yes, there's an issue between F

Continuum vs build failures

Hi, I can't help noticing that two out of three projects on are in status "build error". With respect to Jackrabbit itself, this is because of a recent code change; maybe the test cases th

Re: Continuum vs build failures

Angela Schreiber wrote: Looking at SPI: I'm not sure whether this is an actual bug, or our config for "testcases to be skipped" is still incomplete? Last time we had success here was on July 23. from what i see, the failing tests (4) and the error (1) are both due to problems with the XML-im

Re: JCR 2.0 extensions

Jukka Zitting wrote: ... What do you think? I guess there is some licensing stuff to figure out, but otherwise I think this would be the cleanest approach. ... Sounds exactly right to me. Best regards, Julian

Re: JCR 2.0 extensions

Jukka Zitting wrote: On 8/8/07, Christoph Kiehl <[EMAIL PROTECTED]> wrote: Sounds good. We just need to make sure that those jsr283 interfaces do not interfere with jsr170 interfaces because some Jackrabbit classes will need to implement both interfaces. But since jsr283 should be mainly backwar

Re: master plan for jsr 283 query implementation

Christoph Kiehl wrote: Marcel Reutegger wrote: well, those are actually just my thoughts how I think we should implement the query enhancements specified in JSR 283. there are basically three major blocks that we need to implement: - JQOM, allows you to programmatically create a query - JCR-

Re: Synchronized methods in ItemManager

Marcel Reutegger wrote: our official statement still is you may use multiple threads on a session that just read but a single thread on a session that writes. in - Could you please provide a pointer to that statement? - Also, we need to keep in mind that even if Jackrabbit allows that, JCR

Re: Synchronized methods in ItemManager

Marcel Reutegger wrote: Julian Reschke wrote: Marcel Reutegger wrote: our official statement still is you may use multiple threads on a session that just read but a single thread on a session that writes. in - Could you please provide a pointer to that statement? well, maybe 'officia

Re: Jackrabbit 1.3.2 and 1.4 release planning

Jukka Zitting wrote: ... The 1.4 release will be the next feature from Jackrabbit trunk. It will contain all the recent work on jackrabbit-core as well as both the OCM and SPI layers as new release components. There are still a number of issues open and I think I still need to open a few new iss

Re: [jira] Created: (JCR-1150) JCR2SPI: several performance improvements pointed out by Findbugs

Thomas Mueller wrote: Hi, I like FindBugs, and it would be great to have a good configuration in subversion. The same for PMD and Checkstyle. People can then use it or not, but don't have to duplicate the setup. Integer(int) constructor; use Integer.valueOf(int) instead This is Java 1.5. But

Re: [VOTE] Release Apache Jackrabbit 1.3.3

+1 Builds and passes tests with Java 1.5.0 on Win XP. BR, Julian

Re: Distribution of commons classes

Angela Schreiber wrote: i'd like to take up the discussion regarding distribution of the jcr-commons-classes and the related issue JCR-996 and come up with an proposal. it summarizes the findings of my initial efforts while working on JCR-996 on the current jackrabbit trunk. i tested the gen

Re: about lock tokens

Angela Schreiber wrote: Dominique Pfister wrote: Hi Paco On 08/09/2007, Paco Avila <[EMAIL PROTECTED]> wrote: Sorry, I missunderstood the code because confused "lock holder" and "lock ownser" concepts :( You're not the only one ;) "Lock owner" should rather have been named "lock creator",

Name/Patch refactoring

I'd like to urge everybody to have a look at the patches proposed by Angela for sanitizing the internal (Q)Name/Path interfaces: https://issues.apache.org/jira/browse/JCR-996 and https://issues.apache.org/jira/browse/JCR-1169 For the record; I have tested the changes with my S

Re: Moving contrib outside trunk and rename to sandbox

Jukka Zitting wrote: Hi, The components within jackrabbit/trunk/contrib are not included in our releases and whenever a release branch is created the contrib folder needs to be explicitly removed from the branch. To avoid that removal step and to make it clearer that the contrib components are

SPI observation: EventFilter lifecycle

Hi, here are some thoughts about the current SPI EventFilter interface: Proposal: document that getEvents only needs to accept EventFilter objects created by the same SPI implementation for the same SessionInfo (this reflects reality in JCR2SPI) Proposal: remove special case in getEvents for

Re: SPI observation: EventFilter lifecycle

Marcel Reutegger wrote: ... I'm working on a proposal that introduces a Subscription interface to the SPI, which should solve the above issue. here's a sneak preview: http://people.apache.org/~mreutegg/spi-event/proposal.png ... OK, as far as I understand this, we pass a Subscription obje

Re: SPI observation: EventFilter lifecycle

Marcel Reutegger wrote: Julian Reschke wrote: Question: do we expect many cases in which a client stops listening for events, but keeps the JCR session open? In this case it might be good if we could indicate that an EventFilter is not going to be used anymore, for instance using a dispose

Re: SPI observation: EventFilter lifecycle

Jukka Zitting wrote: Hi, On 11/1/07, Julian Reschke <[EMAIL PROTECTED]> wrote: Proposal: document that getEvents only needs to accept EventFilter objects created by the same SPI implementation for the same SessionInfo (this reflects reality in JCR2SPI) +1 There's no guarantee th

Re: regarding method SEARCH in webdav client

Jukka Zitting wrote: Hi, [taking this thread from users@ to [EMAIL PROTECTED] On Nov 27, 2007 4:35 PM, Ard Schrijvers <[EMAIL PROTECTED]> wrote: I am ATM not sure wether I can translate DASL into SQL (or at least 95%)(XPATH). I think they don't totally match. Julian probably knows all the de

Re: regarding method SEARCH in webdav client

Marcel Reutegger wrote: Hi Julian, Julian Reschke wrote: It's definitively non-trivial to get it sort-of working; reaching full compliance with the DAV:basicsearch may be impossible (unless by bypassing JCR's search). can you share some details? what kind of difficulties did you

JCR2SPI broken

Hi, it seems that the recent refactoring (jcr commons) has broken JCR2SPI -- I see lots of stack overflows -- see . BR, Julian

failing tests

Hi, I can't help noticing that we currently seem to have *various* test cases that occasionally fail. This is very disturbing, because I'm a believer in not checking in new code until tests pass. With the current failures it's very hard to be sure that a change is good, and I fear that the lo

Modularize Jackrabbit query parser?

Hi, under org.apache.jackrabbit.core.query, jackrabbit-core currently contains everything needed to *parse* JSR-170 query statements, both in "XPath" and "SQL". This part of the code is completely independent from jackrabbit-core (I have successfully borrowed it for use in a proprietary, JCR

Re: [jira] Reopened: (JCR-1343) Replace xerces for serialization by JAXP

Felix Meschberger wrote: Hi, Hmpf, I like XML in Java - it is more than complicated ...it is, in particular when older versions need to be supported. Is this still an issue with today's Java 1.4.2 ? What is the exact dependency on Java 1.4.x of Jackrabbit ? 1) Yes, I think that is t

Re: Modularize Jackrabbit query parser?

Marcel Reutegger wrote: Jukka Zitting wrote: - move it into jackrabbit-spi-commons. +1 to moving it to jackrabbit-spi-commons. +1 On the other hand, I can think of a few reasons for not doing that now, such as: - exposing the internal query tree as a "public" API may be problematic. I w

Re: Modularize Jackrabbit query parser?

Marcel Reutegger wrote: Jukka Zitting wrote: - move it into jackrabbit-spi-commons. +1 to moving it to jackrabbit-spi-commons. +1 ... Okay... Just those parts that are needed for JSR170 query parsing (that would be the query tree, the XPath and SQL parsers, but not SQL2 and QOM)? BR, Ju

SPI: setValue vs addProperty

Hi, currently SPI Batch distinguishes between adding a property, and setting the value of a property. In JCR however, this distinction does not exist. Thus JCR2SPI relies on it's knowledge of the node's state to decide which method to use. Of course, this fails in case of overlapping updates

Re: SPI: setValue vs addProperty

Angela Schreiber wrote: > ... Questions: 1) Should we update the Javadoc to clarify that this is what it is expected? yes. 2) Should we remove one of the signatures, because the distinction wasn't useful after all? rather not. you shouldn't be able to modify the value of a property that d

SPI caching, was: [jira] Resolved: (JCR-1361) Lock test assumes that changes in one session are immediately visible in different session

Hi, this issue made me think that we may be missing something in the SPI... So, is an SPI implementation allowed to internally cache things (for instance, with the SessionInfo implementation)? I would assume so (but maybe I'm wrong). If it is allowed to do that, shouldn't a Session.refresh()

Re: SPI caching, was: [jira] Resolved: (JCR-1361) Lock test assumes that changes in one session are immediately visible in different session

Angela Schreiber wrote: hi julian this issue made me think that we may be missing something in the SPI... So, is an SPI implementation allowed to internally cache things (for instance, with the SessionInfo implementation)? I would assume so (but maybe I'm wrong). If it is allowed to do tha

Re: SPI caching, was: [jira] Resolved: (JCR-1361) Lock test assumes that changes in one session are immediately visible in different session

Marcel Reutegger wrote: Julian Reschke wrote: The store the SPI implementation talks to internally may be on a separate machine, so verifying that something is up-to-date (for read access) would actually defy the caching in the first place, wouldn't it? IMO an SPI implementation was

Re: SPI caching, was: [jira] Resolved: (JCR-1361) Lock test assumes that changes in one session are immediately visible in different session

Marcel Reutegger wrote: Example - obtaining a directory listing: SPI2JCR currently gets the NodeInfo for the collection, then gets the ChildInfo iterator, then for each NodeId of a child fetches that child's NodeInfo. For a collection of N members, this translates to N additional roundtrips t

Re: Same name siblings

David Nuescheler wrote: On the other hand I would really like to give people a means to work with large anonymous unordered collections. I think a feature that would address the "I have a bag of objects and I just want to persist them without thinking of a 'name' for each" usecase, would definite

Re: Same name siblings

David Nuescheler wrote: On the other hand I would really like to give people a means to work with large anonymous unordered collections. I think a feature that would address the "I have a bag of objects and I just want to persist them without thinking of a 'name' for each" usecase, would definite

Re: SPI caching, was: [jira] Resolved: (JCR-1361) Lock test assumes that changes in one session are immediately visible in different session

David Rauschenbach wrote: Distraction: WebDAV notation is better for examples (nodes/collections end with slashes, items don't): a/ b/ c/ p1 p2 d/ Back to the discussion: also worth mentioning is why a requested-depth argument is missing from getItemInfos. It's just a little strang

Re: SPI caching, was: [jira] Resolved: (JCR-1361) Lock test assumes that changes in one session are immediately visible in different session

Marcel Reutegger wrote: David Rauschenbach wrote: My main problem with SPI is that if I return depth=1 results from getItemInfos (a NodeInfo for each subfolder), JCR2SPI ends up subsequently calling getChildInfos anyway, to find out what ALL the children are, regardless of the fact that I just

Re: SPI caching, was: [jira] Resolved: (JCR-1361) Lock test assumes that changes in one session are immediately visible in different session

Marcel Reutegger wrote: How would JCR2SPI that *all* children have been returned? good question! I don't know. I'm not that familiar anymore with the jcr2spi code. I remember a discussion with angela about a flag, which indicates that child node entries are complete. But I guess we never imp

Re: SPI caching, was: [jira] Resolved: (JCR-1361) Lock test assumes that changes in one session are immediately visible in different session

Julian Reschke wrote: At the end of the day, what we should do is *measure* the performance of JCR2SPI compared to native implementations. I'll try to submit a few tests soon. ... OK, I've got tests (not polished) and numbers. Scenario: A collection /a/b with 500 members, each 10

Re: SPI caching, was: [jira] Resolved: (JCR-1361) Lock test assumes that changes in one session are immediately visible in different session

Marcel Reutegger wrote: Hmmm, does that mean a batch read should also be allowed to return ChildInfo, with the restriction that it must be complete, when sent? That would be less expensive than returning ItemInfos for the children. But would it be useful? Maybe the more interesting question

Repository factory, was: SPI caching, was: [jira] Resolved: (JCR-1361) Lock testassumesthat changes in one session are immediately visible in differentsession

David Rauschenbach wrote: I should have elaborated on the Repository factory problem. Let's say someone implements the org.apache.jackrabbit.commons.repository.RepositoryFactory interface. They might have some constructor arguments, or some bean setters, for setting properties like target host

Other SPI design questions, was: SPI caching, was: [jira] Resolved: (JCR-1361) Lock testassumes that changes in one session are immediately visible in differentsession

David Rauschenbach wrote: Some other SPI deficiencies off the top of my head, while we're on the subject: 1. Default workspace name. They should not be specified in JCR2SPI. When you log into Exchange or an IMAP server, or a SQL Server, you get a default namespace (or database) based on what

Re: Lock token not removed when node is removed

Carsten Ziegeler wrote: Hi, when I delete a locked node from the repository, the lock token for this node is not removed from the session (I use a session scoped lock and remove the node in the same session). Below is the test code. ... Not sure why that is a problem in practice. Could you e

Re: Lock token not removed when node is removed

Carsten Ziegeler wrote: Julian Reschke wrote: Carsten Ziegeler wrote: Hi, when I delete a locked node from the repository, the lock token for this node is not removed from the session (I use a session scoped lock and remove the node in the same session). Below is the test code. ... Not

Re: Lock token not removed when node is removed

Carsten Ziegeler wrote: For instance, what about locks that get removed due to server-enforced timeouts, or by admin intervention? Hmm, sorry, I can't really follow you here. I'm removing a locked node and the lock token remains in the session. All you have to do is to check if a locked node

Re: SPI caching, was: [jira] Resolved: (JCR-1361) Lock test assumes that changes in one session are immediately visible in different session

Hi, I've been playing around with SPI-side caching of the result of getChildInfos() (keeping the associated NodeInfos in memory), and I can gain something like a factor of 8 for SPI access. So getting back to Marcel's ideas: Why don't we change things so that ItemInfo *extends* ChildInfo, so

Re: [jira] Resolved: (JCR-1390) TCK does not allow diverse Value types in setProperty

Jukka Zitting (JIRA) wrote: [ https://issues.apache.org/jira/browse/JCR-1390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting resolved JCR-1390. Resolution: Invalid Hmm, in fact there is a justification in the spec fo

Re: properties with XML-Values; patch

Hm, the code contains some ugly parts, I have to say. I'm not sure how exactly this is supposed to work, because JCR doesn't have an XML property type. Are you trying to map this to child nodes, or are you trying to persist this as a JCR string property? BR, Julian Angela Schreiber wrote:

Re: SPI caching, was: [jira] Resolved: (JCR-1361) Lock test assumes that changes in one session are immediately visible in different session

eturn ItemInfos instead of or in addition to ChildInfos (either by refactoring the class hierarchy so ItemInfo extends ChildInfo, or by just allowing both types in the Iterator). BR, Julian Marcel Reutegger wrote: Julian Reschke wrote: Why don't we change things so that ItemInfo *exte

Re: SPI caching, was: [jira] Resolved: (JCR-1361) Lock test assumes that changes in one session are immediately visible in different session

Angela Schreiber wrote: Julian Reschke wrote: - change the return value of getChildInfos so that size information is there (Iterator -> RangeIterator or Collection) didn't we have that discussion before? (JCR-1239) We didn't come to a conclusion (it's an open issue).

Re: SPI caching, was: [jira] Resolved: (JCR-1361) Lock test assumes that changes in one session are immediately visible in different session

Angela Schreiber wrote: Julian Reschke wrote: Why don't we change things so that ItemInfo *extends* ChildInfo, that doesn't make sense from my point of view. the usecase for the ChildInfo was to be able to build the HierarchyEntry for a Node where neither ids of the child-entri

Re: properties with XML-Values; patch

OK. 1) So first of all, we have a bug in Jackrabbit's WebDAV: When you set an XML-typed property, it persists some broken value, assuming it's a string. This needs to be fixed. If Jackrabbit can't store a property, the request needs to be rejected. 2) How to decide that: assuming the PROPPAT

Re: properties with XML-Values; patch

Roland Porath wrote: 2) How to decide that: assuming the PROPPATCH request has been parsed into DOM objects, the right thing to do is to check whether the child nodes of the property element (not the DAV:prop element) contain element nodes. In that case, the property type is not plain text, and f

Re: properties with XML-Values; patch

Roland Porath wrote: The issue is that Jackrabbit currently can't store XML-typed properties. That's a conformance problem. I think that's the heart of the matter. Are there plans to resolve that in the future? And in what way? Well. JCR does not support XML-typed properties, thus an extens

Re: properties with XML-Values; patch

Angela Schreiber wrote: ... so, i'd like to understand what is the goal of custom xml properties. ... Well, the same as using XML instead of text, I guess. Such as putting things like marked-up text into properties: This is an important change. In JCR (and therefore Jackrabbit), this ki

Re: properties with XML-Values; patch

Justin Lipton wrote: I like Julian's example of important which is an illustration of mixed content XML but it is also convenient where you have a straight multivalued property e.g. Angela SchreiberJulian Reschke There are obviously other ways of achieving this CSV, different property names (X

Re: QueryObjectModelTree has the wrong package declaration

Esteban Franqueiro wrote: It says core.query.qom instead of spi.commons.query.qom. Should I file a bug in Jira? SearchIndex imports the wrong class too. I think it should be done as part of JCR-1347. BR, Julian

Re: [jira] Commented: (JCR-1405) SPI: Introduce NodeInfo.getChildInfos()

...continuing on the mailing list; I think this exceeds what an issue tracker is good for. angela (JIRA) wrote: angela commented on JCR-1405: - julian: if you cant determine the childinfos upon creating the nodeinfo you should (as stated by the javadoc) simply ret

Re: [jira] Commented: (JCR-1405) SPI: Introduce NodeInfo.getChildInfos()

Julian Reschke wrote: ... Going back to the original discussion: what I think we need is a way to return NodeInfos, not ChildInfos. Right now, when browsing a collection of 1000 items, getting information about each node (timestamps, dates, ...) requires 1000 individual calls through SPI

Re: [jira] Commented: (JCR-1405) SPI: Introduce NodeInfo.getChildInfos()

Michael Dürig wrote: I think the idea of adding getChildInfos to NodeInfo was to cut down on individual calls to the SPI. In a call to getItemInfos an implementation may choose to return any number of ItemInfos in one single batch. By The problem, as far as I understand, is that the saving is i

Re: [jira] Commented: (JCR-1405) SPI: Introduce NodeInfo.getChildInfos()

Michael Dürig wrote: i.e. RepositoryService.getChildInfos() returns NodeInfos instead of ChildInfos. I'd favour such a solution. We might even want to further generalize it to RepositoryService.getNodeInfos(SessionInfo sessionInfo, NodeId[] nodeId) returning an Iterator of NodeInfo. Or am

Re: [jira] Commented: (JCR-1405) SPI: Introduce NodeInfo.getChildInfos()

Michael Dürig wrote: I missed something... the nodeId's are not available to jcr2spi (that is what getChildInfos was/is for). So +1 for Marcel's original suggestion for adding RepositoryService.getChildInfos(). ...the one for which Marcel already agreed it doesn't help for the problem we are

Re: [jira] Commented: (JCR-1405) SPI: Introduce NodeInfo.getChildInfos()

Michael Dürig wrote: RepositoryService.getNodeInfos(SessionInfo sessionInfo, NodeId[] nodeId) returning an Iterator of NodeInfo. Or am I missing something here? +1 for getting many NodeInfos in one call. However -- is your proposal for the calls passed in as parameter, or for their child nod

Re: [jira] Commented: (JCR-1405) SPI: Introduce NodeInfo.getChildInfos()

Michael Dürig wrote: ...we may want to rename it to getNodeInfos() then :-) Actually I'd prefer something along the line of getChildNodeInfos() to be more explicit and to clearly differentiate it from getNodeInfo(). Now we're talking :-) Let's change public Iterator getChildInfos(Sess

Re: [jira] Commented: (JCR-1405) SPI: Introduce NodeInfo.getChildInfos()

Angela Schreiber wrote: Michael Dürig wrote: i.e. RepositoryService.getChildInfos() returns NodeInfos instead of ChildInfos. I'd favour such a solution. We might even want to further generalize it to RepositoryService.getNodeInfos(SessionInfo sessionInfo, NodeId[] nodeId) i don't see the

Re: [jira] Commented: (JCR-1405) SPI: Introduce NodeInfo.getChildInfos()

Marcel Reutegger wrote: Julian Reschke wrote: Also, let's change public PropertyInfo getPropertyInfo(SessionInfo sessionInfo, PropertyId propertyId) throws ItemNotFoundException, RepositoryException; to public Iterator getPropertyInfo(SessionInfo sessionInfo, Prope

Build broken with revision 631547

Hi, I'm getting two failing observation tests, so does the build server. See . BR, Julian

Re: Build broken with revision 631547

Julian Reschke wrote: Hi, I'm getting two failing observation tests, so does the build server. See <http://jackrabbit.zones.apache.org:8080/continuum/component/buildResult.action?buildId=2673&projecGroupId=6&projectId=6&projectGroupId=6>. Can we please revert this c

Re: Expanding the scope of jackrabbit-jcr-tests

Esteban Franqueiro wrote: Hi. I agree. But maybe we should have a new package for this tests? Perhaps org.apache.jackrabbit.test.perf[ormance] or something like that. Regards, Yup, the latter is the package name I'm proposing for . BR, Julian

Re: Expanding the scope of jackrabbit-jcr-tests

Marcel Reutegger wrote: If we don't want to introduce a new module we can just as well use jackrabbit-core, where we already have tests. However I know that Julian will not be happy with that because he wants to use the tests without introducing a dependency to jackrabbit-core, right? I'd pre

Re: svn commit: r632309 - in /jackrabbit/trunk: jackrabbit-core/src/main/java/org/apache/jackrabbit/core/ jackrabbit-core/src/main/java/org/apache/jackrabbit/core/query/ jackrabbit-core/src/main/java/

[EMAIL PROTECTED] wrote: Author: mreutegg Date: Fri Feb 29 05:01:42 2008 New Revision: 632309 URL: http://svn.apache.org/viewvc?rev=632309&view=rev Log: JCR-1104: JSR 283 support - support for prepared queries has been moved to existing Query interface - removed PreparedQuery again Seems this

Re: svn commit: r631908 - in /jackrabbit/trunk: jackrabbit-core/pom.xml jackrabbit-spi-commons/pom.xml

[EMAIL PROTECTED] wrote: Author: jukka Date: Thu Feb 28 01:54:43 2008 New Revision: 631908 URL: http://svn.apache.org/viewvc?rev=631908&view=rev Log: JCR-1430: mvn eclipse:eclipse inconsistent - Use the the new jjtree-javacc goal in javacc-maven-plugin version 2.4 - Contributed by Stepha

Re: svn commit: r631908 - in /jackrabbit/trunk: jackrabbit-core/pom.xml jackrabbit-spi-commons/pom.xml

Julian Reschke wrote: [EMAIL PROTECTED] wrote: Author: jukka Date: Thu Feb 28 01:54:43 2008 New Revision: 631908 URL: http://svn.apache.org/viewvc?rev=631908&view=rev Log: JCR-1430: mvn eclipse:eclipse inconsistent - Use the the new jjtree-javacc goal in javacc-maven-plugin version

Re: [jira] Updated: (JCR-1437) add framework for performance tests

Julian Reschke (JIRA) wrote: [ https://issues.apache.org/jira/browse/JCR-1437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated JCR-1437: Attachment: JCR-1437.patch Proposed patch, with code moved into new

Re: SPI caching, was: [jira] Resolved: (JCR-1361) Lock test assumes that changes in one session are immediately visible in different session

OK, I finally obtained measurements for jackrabbit native and JCR2SPI (see proposed test in JCR-1437): jackrabbit-core: 3.35ms per iteration jcr2spi: 756ms per iteration Hopefully once the tests are checked-in, and the results are reproducible everywhere, we agree that there's a problem :-)

Re: SPI caching, was: [jira] Resolved: (JCR-1361) Lock test assumes that changes in one session are immediately visible in different session

Julian Reschke wrote: OK, I finally obtained measurements for jackrabbit native and JCR2SPI (see proposed test in JCR-1437): jackrabbit-core: 3.35ms per iteration jcr2spi: 756ms per iteration Hopefully once the tests are checked-in, and the results are reproducible everywhere, we agree

Re: [continuum] BUILD FAILURE: Apache Jackrabbit - Jackrabbit JCR to SPI - Build Def: Jackrabbit build with Java 1.4

Stefan Guggisberg wrote: seems like the following commit broke the continuum build: New Revision: 635569 JCR-1437: add dependency plus integration to jackrabbit-jcr2spi cheers stefan I already chatted with Jukka: Continuum doesn't respect the project build order (set in the pom.xml). I have

  1   2   3   4   5   6   7   8   9   10   >