[
https://issues.apache.org/jira/browse/JCR-1323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christoph Kiehl updated JCR-1323:
-
Fix Version/s: 1.4.1
> When using QueryImpl.setLimit() and QueryImpl.setOffset(), t
[
https://issues.apache.org/jira/browse/JCR-1323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christoph Kiehl resolved JCR-1323.
--
Resolution: Fixed
Fix Version/s: 1.5
Thanks a lot for clarifying! Fixed in rev. 613221
[
https://issues.apache.org/jira/browse/JCR-1324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christoph Kiehl resolved JCR-1324.
--
Resolution: Duplicate
Assignee: Christoph Kiehl
Thanks for reporting but this is a knows
[
https://issues.apache.org/jira/browse/JCR-1196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12560259#action_12560259
]
Christoph Kiehl commented on JCR-1196:
--
Description for slow ChildAxisQuery by Ma
[
https://issues.apache.org/jira/browse/JCR-1323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christoph Kiehl resolved JCR-1323.
--
Resolution: Invalid
Assignee: Christoph Kiehl
This is expected behaviour as the iterator
[
https://issues.apache.org/jira/browse/JCR-1302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12557624#action_12557624
]
Christoph Kiehl commented on JCR-1302:
--
Thanks a lot Owen for tracking this down
[
https://issues.apache.org/jira/browse/JCR-1302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christoph Kiehl reassigned JCR-1302:
Assignee: Christoph Kiehl
> ArrayHits does not end properly when skipTo doesn
Jukka Zitting wrote:
I'm not saying it has to be the default, but it could be optional. I have a
patch for 1.4 that adds
a lockingStrategy attribute to the repository config (per repository), and it
has a few tweaks in
it. I can upload it for review. Our testing with 1.3.1 + FGL shows a tree-f
[
https://issues.apache.org/jira/browse/JCR-1251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12549493
]
Christoph Kiehl commented on JCR-1251:
--
Well spotted! I observed another gain of about 7% on my machine with
[
https://issues.apache.org/jira/browse/JCR-1251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christoph Kiehl resolved JCR-1251.
--
Resolution: Fixed
Committed in rev. 601562
> DescendantSelfAxisQuery creates too many obj
Marcel Reutegger (JIRA) wrote:
Finally committed a mix of christophs and my patch. The performance
characteristics are very similar to the attached patches.
I very much like the outcome! Thanks a lot for cleaning up!
Cheers,
Christoph
[
https://issues.apache.org/jira/browse/JCR-1251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12547620
]
Christoph Kiehl commented on JCR-1251:
--
Ah, you are certainly right. I'll use System.arraycopy instead. T
[
https://issues.apache.org/jira/browse/JCR-1251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christoph Kiehl updated JCR-1251:
-
Attachment: DescendantSelfAxisQuery-patch.txt
I'm getting a performance boost of about 40% o
Components: jackrabbit-core, query
Reporter: Christoph Kiehl
Assignee: Christoph Kiehl
Priority: Minor
Fix For: 1.4
In DescendantSelfAxisQuery.DescendantSelfAxisScorer.isValid() there is an
ArrayList and an Integer instance created on every call. Since
Ard Schrijvers wrote:
Since my "stuff//[EMAIL PROTECTED]" gives me 1.200.000, it makes
perfect sense
to users I think, that even with our patches and a working
cache, that
retaining them all would be slow. But if I set the limit to
1 or 10, I
would expect to have performance (certainly when
Ard Schrijvers wrote:
Query q = qm.createQuery("stuff//[EMAIL PROTECTED]", Query.XPATH);
if (q instanceof QueryImpl) {
// limit the result set
((QueryImpl) q).setLimit(1);
}
Since my "stuff//[EMAIL PROTECTED]" gives me 1.200.000, it makes perfect
sense to users I think, that even with o
[
https://issues.apache.org/jira/browse/JCR-1213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christoph Kiehl updated JCR-1213:
-
Attachment: JCR-1213-ckiehl.txt
Fixed a small glitch. And btw, there is still some javadoc
[
https://issues.apache.org/jira/browse/JCR-1213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christoph Kiehl updated JCR-1213:
-
Attachment: (was: JCR-1213-ckiehl.txt)
> UUIDDocId cache does not work properly because
[
https://issues.apache.org/jira/browse/JCR-1213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christoph Kiehl updated JCR-1213:
-
Attachment: JCR-1213-ckiehl.txt
I like Marcels idea to use the creation tick to identity the base
[
https://issues.apache.org/jira/browse/JCR-1238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12545975
]
Christoph Kiehl commented on JCR-1238:
--
Sounds good! +1
> Change default value for maxMergeD
[
https://issues.apache.org/jira/browse/JCR-1237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12545971
]
Christoph Kiehl commented on JCR-1237:
--
+1 to change the default for "respectDocumentOrder" to &qu
[
https://issues.apache.org/jira/browse/JCR-1236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12545755
]
Christoph Kiehl commented on JCR-1236:
--
What's the reason for changing the skin? I like the old one better
Jukka Zitting wrote:
Martijn and Ard, welcome to the team!
Great to have you both on board! Big welcome!
Cheers,
Christoph
Reporter: Christoph Kiehl
I find the following Exception in our log files from time to time. I don't know
how to replicate it and I couldn't find a ticket in Jira nor seemed the recent
changes on the participating classes in trunk handling this error:
java.lang.NullPointerException
Hi Ard!
Very nice analysis! It's indeed a very tricky bug ;) UUIDDocId should
not use WeakReferences on the one hand and equals() on the other hand.
Maybe we should better return the same instance of a CombinedIndexReader
in SearchIndex.getIndexReader() if possible and use a "==" comparison in
Marcel Reutegger wrote:
I'd like to keep a move operation cheap but I also agree that
hierarchical query operations need to be improved.
Same here. Making move operations expensive is a very high price for getting
fast queries. Although I'm not sure how common the usecase of moving big
subtr
Ard Schrijvers wrote:
Follow up: it seems that my mergeFactor was way to high (100) resulting
in many indexes. Setting it to 5 seems to improve trivial searches a
lot! At the same time, I had maxMergeDocs too small, resulting in many
indexes as well.
Is there any golden rule on how to tune th
Jukka Zitting wrote:
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 not
[
https://issues.apache.org/jira/browse/JCR-1064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christoph Kiehl updated JCR-1064:
-
Attachment: JCR-1064-4.patch
I like Marcels solution to distinguish between physical index version
Jukka Zitting wrote:
I hear a number of Apache projects have had good experience on using a
Confluence wiki as a kind of a CMS for editing their web sites. How
would you feel if we took the same approach in Jackrabbit? Write
access to the web site wiki would still be limited to committers.
I k
Thomas Mueller wrote:
Two more advantages of a hand-written parser:
- You can actually debug the parser. No chance with JavaCC or ANTLR
A very important point in my opinion! I learned a lot of Jackrabbits internals
by debugging.
Cheers,
Christoph
Marcel Reutegger wrote:
Thomas Mueller wrote:
use javacc for SQL2 parsing
I would use a hand-written recursive descent parser. I know I'm
probably the only one suggesting this...
what are the advantages of a hand-written parser over a generated one?
probably performance, but are there other
Bertrand Delacretaz wrote:
On 9/11/07, Christoph Kiehl <[EMAIL PROTECTED]> wrote:
...WDOT?...
I agree with Thomas that he'll probably be the only one to suggest a
hand-written parser ;-)
Ok ;) So does anyone know of any easier to understand solutions than using
javacc? Maybe
Thomas Mueller wrote:
use javacc for SQL2 parsing
I would use a hand-written recursive descent parser. I know I'm
probably the only one suggesting this...
Well, not quite ;) I asked because currently you need to have knowledge about
javacc to extend the parsers. I would like to make it easi
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-SQL2, the new SQL query
[
https://issues.apache.org/jira/browse/JCR-1114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christoph Kiehl resolved JCR-1114.
--
Resolution: Fixed
Committed changes in revision 572890 and 572891.
> Remove QueryResultImpl
Type: Task
Components: query
Reporter: Christoph Kiehl
Assignee: Christoph Kiehl
Priority: Minor
Fix For: 1.4
QueryResultImpl isn't used in Jackrabbit anymore. Instead LazyQueryResultImpl
is now used. See the discussion in JCR
[
https://issues.apache.org/jira/browse/JCR-1073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christoph Kiehl resolved JCR-1073.
--
Resolution: Fixed
Fix Version/s: 1.4
Committed patch in revision 572889. I'll open
Ard Schrijvers wrote:
Christoph Kiehl wrote:
I made some changes to the ChildAxisScorer while working on JCR-1041.
Unfortunately I don't have the time right now to check if I
introduced this bug.
I'll try to have a look later this day. Feel free to check
the affected revisio
[
https://issues.apache.org/jira/browse/JCR-1041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12524997
]
Christoph Kiehl commented on JCR-1041:
--
Fixed a little bug in ChildAxisScorer.skipTo() in revision 572885 as
Ard Schrijvers wrote:
when running the same very simple test below in the JR trunk a few times (~5
times) I get an ArrayOutOfBoundsException in the
ChildAxisQuery.ChildAxisScorer.indexIsValid(int i) on
Document node = reader.document(i);
Did anybody have this before? The simple test is below.
Jukka Zitting wrote:
Please cast your votes:
[x] +1 Approve the Sling project for incubation
[ ] -1 Don't approve the project, because...
Looking very much forward to it. Sounds like a _very_ interesting project.
Cheers,
Christoph
Ard Schrijvers (JIRA) wrote:
Ard Schrijvers commented on JCR-1064:
-
ps : is it possible to mark the current patch as deprecated or something?
I tend to remove invalid patches. Don't how others think about that. But I think
it makes no sense to keep a pat
[
https://issues.apache.org/jira/browse/JCR-1073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12522463
]
Christoph Kiehl commented on JCR-1073:
--
I'm afraid if we open up jackrabbit here we might run into more i
[
https://issues.apache.org/jira/browse/JCR-1064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12522442
]
Christoph Kiehl commented on JCR-1064:
--
I like the patch so far. Just a few comments:
LuceneQueryBuilder:
- I
[
https://issues.apache.org/jira/browse/JCR-1073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12522428
]
Christoph Kiehl commented on JCR-1073:
--
WDYT about removing QueryResultImpl from jackrabbit and you just add it
Ard Schrijvers wrote:
Hello,
there seems to be two LuceneQueryBuilder.createQuery methods, where the first
looks like:
public static Query createQuery(QueryRootNode root,
SessionImpl session,
ItemStateManager sharedItemMgr
[
https://issues.apache.org/jira/browse/JCR-1066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christoph Kiehl updated JCR-1066:
-
Attachment: QueryNodeFactory_2.patch
I like the patch. Just one thought:
I would prefer removing
[
https://issues.apache.org/jira/browse/JCR-1073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christoph Kiehl updated JCR-1073:
-
Attachment: patch.txt
A first shot how this might look like. I stumbled over QueryResultImpl which
Kiehl
Assignee: Christoph Kiehl
Priority: Minor
As discussed in
http://www.nabble.com/Total-size-of-a-query-result-and-setLimit%28%29-tf4280909.html#a12185543
a getTotalSize() method should be added to QueryResults.
--
This message is automatically generated by JIRA
[
https://issues.apache.org/jira/browse/JCR-1066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christoph Kiehl updated JCR-1066:
-
Attachment: patch_with_extendible_system_nodetypes.txt
I'm not really happy with all
Ard Schrijvers wrote:
Wellif I start implementing the 1:1 mapping simultaneously and have to
make this backwards compatible also for old indices, I am afraid that I have
to test all around the place.
As far as I can see the following needs to be done:
In LuceneQueryBuilder methods need t
Ard Schrijvers wrote:
Christoph Kiehl wrote:
4. Regarding sorting: We will still need our own sorting because we cache
the document order per subreader whereas lucenes sorting only caches per
reader which get invalidated after every write operation. But the initial
cache creation will be faster
Marcel Reutegger wrote:
Christoph Kiehl wrote:
Marcel Reutegger wrote:
1) New QueryHandler class
2) Introduce parameter in configuration
3) Auto-detect in SearchIndex
[...]
ok, I'm at a point where I think we should implement 3). I don't have
fundamental opposition against
Ard Schrijvers wrote:
So, WDOT about indexing properties in seperate lucene Fields, and about
possibly indexing more information of one property. My experience with
lucene, is that indexing tactically, eases querying a lot, and gains you lots
of performance. So, if you do agree on these changes,
[
https://issues.apache.org/jira/browse/JCR-1066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christoph Kiehl updated JCR-1066:
-
Attachment: patch.txt
rep:system was still missing
> Exclude system index for queries t
[
https://issues.apache.org/jira/browse/JCR-1066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christoph Kiehl updated JCR-1066:
-
Attachment: (was: patch.txt)
> Exclude system index for queries that restrict the result
Jukka Zitting wrote:
Hi,
On 8/17/07, Christoph Kiehl <[EMAIL PROTECTED]> wrote:
Thomas Mueller wrote:
That's a good idea! Implementations that can't support it efficiently
could then calculate the size only when required. What about
getTotalSize()?
Implementations should ma
[
https://issues.apache.org/jira/browse/JCR-1066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christoph Kiehl updated JCR-1066:
-
Attachment: patch.txt
Added a corrected patch which incorporates the suggested changes. You were
[
https://issues.apache.org/jira/browse/JCR-1066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christoph Kiehl updated JCR-1066:
-
Attachment: (was: patch.txt)
> Exclude system index for queries that restrict the result
Thomas Mueller wrote:
I'm not concerned about an implementation not being able to 'support'
setLimit(). I rather think of applications using that new method and at the same
time wish to find out the total number of matches, as written initially by
Christoph.
I understand.
keep the setLimit()
Marcel Reutegger wrote:
Hmm, after some thinking here's another proposal:
keep the setLimit() as is. but introduce a getSize() (or
getTotalMatches()?) on the QueryResult. This method always returns the
total number of nodes/rows independent of setLimit().
That was what I was trying to sugge
Ard Schrijvers wrote:
Ard Schrijvers wrote:
I did not know about the soon to be deprecated class.
Well, I thought Marcels suggestion implied that. To quote him:
"further development will then only happen on the new QueryHandler
implementation "
Yes you're right. I read it wrong and thought
Marcel Reutegger wrote:
1) New QueryHandler class
2) Introduce parameter in configuration
3) Auto-detect in SearchIndex
I prefer 1) because it makes it explicit. I have reservations regarding
3) because it introduces some magic. I don't like 2) because we probably
cannot come up with a sensib
Ard Schrijvers wrote:
I did not know about the soon to be deprecated class.
Well, I thought Marcels suggestion implied that. To quote him:
"further development will then only happen on the new QueryHandler implementation
"
Cheers,
Christoph
Marcel Reutegger wrote:
I would prefer a new QueryHandler class that extends SearchIndex or create a
common base class for both the current SearchIndex and the new
implementation. That way we can change the sample configuration for 1.4 to
the new implementation while at the same time existing
Ard Schrijvers wrote:
Since IMO this is such a performance and scalability improvement I want to
discuss the backwards compatability for older jackrabbit releases which have
an index which is not suitable for this new approach. Checking the current
index at startup and then fallback to old index
Hi,
while fixing a little bug in rev 566778 I became aware that there is no
possibility to retrieve the total result size of a query anymore if setLimit()
is used. But I need that information and I think I'm not alone. The question is
how to implement this? Should this maybe even be covered by
[
https://issues.apache.org/jira/browse/JCR-1066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christoph Kiehl updated JCR-1066:
-
Attachment: patch.txt
The first patch was incomplete
> Exclude system index for queries t
[
https://issues.apache.org/jira/browse/JCR-1066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christoph Kiehl updated JCR-1066:
-
Attachment: (was: patch.txt)
> Exclude system index for queries that restrict the result
[
https://issues.apache.org/jira/browse/JCR-1066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christoph Kiehl updated JCR-1066:
-
Attachment: patch.txt
This is an initial patch. I'm not fully satisfied with it be
URL: https://issues.apache.org/jira/browse/JCR-1066
Project: Jackrabbit
Issue Type: Improvement
Components: query
Reporter: Christoph Kiehl
Assignee: Christoph Kiehl
Priority: Minor
Fix For: 1.4
We already have code that
Marcel Reutegger wrote:
Christoph Kiehl wrote:
Well, I would prefer keeping the possible value set of "true" and
"false" since the name of the value implies that it is a boolean flag.
What about changing the the behaviour of Jackrabbit. If
forceConsistencyCheck is &
Ard Schrijvers wrote:
Christoph Kiehl wrote:
We could use IndexReader.getFieldNames() at startup to check
if such a
field already exists which means we have an index in the new
format and
then use this information in MatchAllScorer to decide which
implementation to use.
This is not
Jukka Zitting wrote:
Not having nested projects is not an issue to me, as I import the
projects "beside" each other, and generally do not care for the parent
projects, which I rarely (if ever) touch.
Exactly. My process of setting up a fresh checkout is:
$ mkdir jackrabbit
$ cd jackra
Marcel Reutegger wrote:
Ard Schrijvers wrote:
IMO, we should index more (derived) data about a documents properties
(I'll
return to this in a mail about IndexingConfiguration which I think we
can add
some features that might tackle this) if we want to be able to query
fast.
For this specific
[
https://issues.apache.org/jira/browse/JCR-1041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christoph Kiehl resolved JCR-1041.
--
Resolution: Fixed
Fix Version/s: 1.4
Added suggested patch with additional license
Hi!
First: This is definitely not supposed to become a discussion which IDE
is better!
I was just curious which IDEs Jackrabbit developers use. I generally use
Eclipse, but I've got some problems, as Subclipse still does not support
nested projects very well. Do you encounter this as well? A
Marcel Reutegger wrote:
For now I'm thinking about disabling consistency checks at all by
default and run them in a maintenance window at night. Unfortunately
this might be a bit dangerous if parts of the application rely on
certain nodes to be found by queries :/
WDYT?
I agree with you. We
[
https://issues.apache.org/jira/browse/JCR-1058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christoph Kiehl resolved JCR-1058.
--
Resolution: Duplicate
> Index segment lost after consistency ch
[
https://issues.apache.org/jira/browse/JCR-1058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christoph Kiehl reopened JCR-1058:
--
Assignee: Christoph Kiehl
> Index segment lost after consistency ch
[
https://issues.apache.org/jira/browse/JCR-1058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christoph Kiehl resolved JCR-1058.
--
Resolution: Fixed
> Index segment lost after consistency ch
: 1.3
Reporter: Christoph Kiehl
Priority: Critical
On one of our server it seems like a whole index segment got lost because all
nodes that were added just before the crash where not in the index anymore an
we got this in out log file:
[2007-07-06 10:52:08,067, INFO
Hi,
we've got very big indexes/workspaces on our production servers which have from
3,000,000 to 8,000,000 nodes and are still growing because of creation of
versions and adding new nodes.
When it happens that the VM in which Jackrabbit lives in crashes during a write
operation, Jackrabbit nic
[
https://issues.apache.org/jira/browse/JCR-989?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12519626
]
Christoph Kiehl commented on JCR-989:
-
Okay. What to do now? Based on the discussion on the dev list
(http
Marcel Reutegger (JIRA) wrote:
[
https://issues.apache.org/jira/browse/JCR-1051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcel Reutegger reopened JCR-1051:
---
Assignee: Marcel Reutegger (was: Christoph Kiehl)
We
Stefan Guggisberg wrote:
On 8/13/07, Felix Meschberger <[EMAIL PROTECTED]> wrote:
Hi,
Am Montag, den 13.08.2007, 10:31 +0200 schrieb Christoph Kiehl:
What do you think of option two in my original mail, regardless of when the new
nodetype management API is available?
Honestly, while I
Felix Meschberger wrote:
I favour neither of both :-) I would favor a real node type management
API, which would allow more fine grained control over the node type
registration process (such an API will be coming with JCR 2).
I see ;) I definitely like to see this happening, but this sound lik
qcfireball wrote:
Please refer to:
http://www.nabble.com/Reregistering-Node-Types-in-RMI-tf4253117.html
to see how to setup the ability to create new NodeTypes via RMI. Please
post any questions there. Thanks.
Please see my reply on the user list.
Cheers,
Christoph
Hi,
on the user list the question arose whether it is possible to reregister
node types via RMI. Currently JackrabbitNodeTypeManager doesn't expose
NodeTypeManagerImpl.registerNodeTypes(InputStream, String, boolean)
which allows to enable reregistration.
There are two options to implement thi
Thomas Mueller wrote:
Exceptions should never be used for orinary control flow (see also
"Effective Java" page 170). My suggestion would be:
SharedItemStateManager.java,
private boolean hasNonVirtualItemState(ItemId id) throws
ItemStateException {
...
if (id.denotesNode()) {
Felix Meschberger wrote:
Makes absolute sense, except for throwing the RuntimeException as you
noted in your own follow-up.
And yes, I agree, this would require a big code review. On the other
hand taking the pragmatic approach of fixing those places one after the
other as the issues are encoun
Christoph Kiehl wrote:
Maybe the following:
private boolean hasNonVirtualItemState(ItemId id) {
[...]
} catch (ItemStateException ise) {
return false;
}
[...]
}
should be rewritten to:
private boolean hasNonVirtualItemState(ItemId id) {
[...]
} catch
Felix Meschberger wrote:
I agree, that the cause must not be lost. But rather than logging the
cause inside loadBundle (in this case), I suggest the
hasNonVirtualItemState method should not ignore the exception and log
it.
IMHO, if an exception is thrown, the same message should not be logged
b
Hi,
while preparing the testcase for JCR-1039 I found a construct like this:
protected synchronized NodePropBundle loadBundle(NodeId id)
throws ItemStateException {
[...]
} catch (Exception e) {
String msg = "failed to read bundle: " + id + ": " + e;
log.error(msg
[
https://issues.apache.org/jira/browse/JCR-1041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12518568
]
Christoph Kiehl commented on JCR-1041:
--
Well, according to various sources
(http://martin.nobilitas.com/java
Julian Reschke wrote:
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
Jukka Zitting wrote:
To best manage the change I would like to start a separate
jackrabbit-jsr283 component that would contain tentative JCR 2.0
extension interfaces in org.apache.jackrabbit.jsr283. We wouldn't need
to make any backwards compatibility claims for that component, but any
other com
[
https://issues.apache.org/jira/browse/JCR-989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christoph Kiehl resolved JCR-989.
-
Resolution: Fixed
Fix Version/s: 1.4
committed in revision 563688
> Mod
[
https://issues.apache.org/jira/browse/JCR-1051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christoph Kiehl resolved JCR-1051.
--
Resolution: Fixed
Patch applied in revision 563673. Thanks Ard!
Please post a mail to the
1 - 100 of 237 matches
Mail list logo