[
https://issues.apache.org/jira/browse/JCR-1050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jukka Zitting updated JCR-1050:
---
Affects Version/s: (was: 1.3)
(was: 1.2.2)
[
https://issues.apache.org/jira/browse/JCR-927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jukka Zitting updated JCR-927:
--
Fix Version/s: 1.4
DatabaseJournal needs connection reestablishment logic
[
https://issues.apache.org/jira/browse/JCR-884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jukka Zitting closed JCR-884.
-
DatabaseJournal assigns same revision id to different revisions
[
https://issues.apache.org/jira/browse/JCR-789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jukka Zitting closed JCR-789.
-
PathElement.equals doesn't handle INDEX_UNDEFINED
-
[
https://issues.apache.org/jira/browse/JCR-799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jukka Zitting closed JCR-799.
-
AbstractJournal doesn't create deep paths for revision files
[
https://issues.apache.org/jira/browse/JCR-549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jukka Zitting closed JCR-549.
-
TransientFileFactory may throw ConcurrentModificationException on shutdown
[
https://issues.apache.org/jira/browse/JCR-571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jukka Zitting closed JCR-571.
-
jackrabbit JCA pom.xml
--
Key: JCR-571
URL:
[
https://issues.apache.org/jira/browse/JCR-947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jukka Zitting updated JCR-947:
--
Fix Version/s: 1.4
Affects Version/s: (was: 1.0)
XMLReader logs fatal error to system out
[
https://issues.apache.org/jira/browse/JCR-826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jukka Zitting closed JCR-826.
-
NodeTest.testAddNodeConstraintViolationExceptionUndefinedNodeType relies on
addNode(name, nt:base)
[
https://issues.apache.org/jira/browse/JCR-679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jukka Zitting resolved JCR-679.
---
Resolution: Duplicate
Assignee: (was: Jukka Zitting)
Duplicate of JCR-989
Add setLimit()
[
https://issues.apache.org/jira/browse/JCR-665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jukka Zitting closed JCR-665.
-
RMI: Property.getValue() fails with EOFException after many reads
[
https://issues.apache.org/jira/browse/JCR-543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jukka Zitting closed JCR-543.
-
DocViewSAXEventGenerator produces invalid SAX stream
Hi,
I'd like to streamline the Jackrabbit components in Jira (currently
core, xml, query, etc.) to better match the project structure in svn.
This would help us better track changes per release artifact.
See below for a proposed restructuring of the Jira components. In
short this change would
Why not for the jcr-mapping somerthing like :
jcr-mapping
ocm
nodetype-management
annotation
spring
On 8/8/07, Jukka Zitting [EMAIL PROTECTED] wrote:
Hi,
I'd like to streamline the Jackrabbit components in Jira (currently
core, xml, query, etc.) to better match the project
Hi Jukka,
Makes sense (incl. Christophe's comments).
Am Mittwoch, den 08.08.2007, 10:33 +0300 schrieb Jukka Zitting:
Hi,
I'd like to streamline the Jackrabbit components in Jira (currently
core, xml, query, etc.) to better match the project structure in svn.
This would help us better track
hi jukka
On 8/8/07, Jukka Zitting [EMAIL PROTECTED] wrote:
Hi,
I'd like to streamline the Jackrabbit components in Jira (currently
core, xml, query, etc.) to better match the project structure in svn.
This would help us better track changes per release artifact.
See below for a proposed
[
https://issues.apache.org/jira/browse/JCR-926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12518389
]
Thomas Mueller commented on JCR-926:
Hi,
Is there anything I can do to help speed up integrating the global data
Hi,
Now that the public review draft of JCR 2.0 is available we can start
implementing the changes and new features. We need to do this already
now for Jackrabbit to be ready for use as the JCR 2.0 reference
implementation when the standard becomes final.
The difficult part in implementing the
[
https://issues.apache.org/jira/browse/JCR-1040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela resolved JCR-1040.
-
Resolution: Fixed
the problem was caused upon creating the effective node type for the new
replacement node,
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
hi jukka
On 8/8/07, Jukka Zitting [EMAIL PROTECTED] wrote:
Hi,
Now that the public review draft of JCR 2.0 is available we can start
implementing the changes and new features. We need to do this already
now for Jackrabbit to be ready for use as the JCR 2.0 reference
implementation when the
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
Hi,
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 backwards
compatible
Incorrect node position after import
Key: JCR-1055
URL: https://issues.apache.org/jira/browse/JCR-1055
Project: Jackrabbit
Issue Type: Bug
Affects Versions: 1.3
Reporter: Marcus Kaar
I
Hi,
On 8/8/07, Stefan Guggisberg [EMAIL PROTECTED] wrote:
i'd definitely like to keep the finer granularity in core.
ideally there should be something like subcomponents
but prefixing would be fine with me.
Eventually (perhaps starting with Jackrabbit 2.0) we may want to start
having separate
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
[
https://issues.apache.org/jira/browse/JCR-1040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12518398
]
Julian Reschke commented on JCR-1040:
-
Confirming this fixes the problem I saw. Thanks, Angela.
JCR2SPI: remove
[
https://issues.apache.org/jira/browse/JCR-1037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12518402
]
Jukka Zitting commented on JCR-1037:
Do you have multiple sessions accessing the repository? Do you ever close the
[
https://issues.apache.org/jira/browse/JCR-937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12518405
]
Jukka Zitting commented on JCR-937:
---
There's a minimum size (default 128kB) per each cache that overrides the global
[
https://issues.apache.org/jira/browse/JCR-1055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Kaar updated JCR-1055:
-
Description:
I have found a behavior that does not seem to be consistent with the
spec:
After replacing a
[
https://issues.apache.org/jira/browse/JCR-1039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12518406
]
Tobias Bocanegra commented on JCR-1039:
---
+1 for this patch
Bundle Persistence Manager error - failing to read
[
https://issues.apache.org/jira/browse/JCR-1055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Kaar updated JCR-1055:
-
Description:
I have found a behavior that does not seem to be consistent with the
spec:
After replacing a
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 since jsr283
[
https://issues.apache.org/jira/browse/JCR-1041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12518422
]
Jukka Zitting commented on JCR-1041:
How about an alternative implementation of using just a TreeSet of Integers
[
https://issues.apache.org/jira/browse/JCR-1048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12518425
]
Jukka Zitting commented on JCR-1048:
Wouldn't a more appropriate fix be to simply change your repository
[
https://issues.apache.org/jira/browse/JCR-1037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12518434
]
Antonio Carballo commented on JCR-1037:
---
We have one session and is never closed due to the nature of the
Hi,
org.apache.jackrabbit.jsr283 is a good idea. In a new component, or in
jackrabbit-api.
But since jsr283 should be mainly backwards compatible
It's not. Some methods now return something that didn't before.
In case we do ran up with compatibility issues,
I think we have a good case to
Hi all,
I would like to propose a new Apache project named Sling. The proposal
text is attached to this message and can also be found at [1].
More information on Sling may be found in the Jackrabbit Wiki at [2].
I would like to have the discussion on this proposal to go on in
parallel in the
Very interesting initiative Felix! Still, I am wondering why this
would not start as a Jackrabbit contrib project, and I don't think I
have seen this in the attached proposal.
tia,
./alex
--
.w( the_mindstorm )p.
On 8/8/07, Felix Meschberger [EMAIL PROTECTED] wrote:
Hi all,
I would like to
Hello,
As mentioned in https://issues.apache.org/jira/browse/JCR-1051 I think there
might be some optimization in scalability and performance in some parts of the
current lucene implementation.
For now, I have two major performance/scalability concerns in the current
indexing/searching
On 8/8/07, Felix Meschberger [EMAIL PROTECTED] wrote:
Hi Alex,
Am Mittwoch, den 08.08.2007, 17:03 +0300 schrieb Alexandru Popescu ☀:
Very interesting initiative Felix! Still, I am wondering why this
would not start as a Jackrabbit contrib project, and I don't think I
have seen this in the
[
https://issues.apache.org/jira/browse/JCR-1039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Guggisberg updated JCR-1039:
---
Fix Version/s: 1.4
Affects Version/s: (was: 1.3)
1.3.1
Hi Alex,
Am Mittwoch, den 08.08.2007, 17:03 +0300 schrieb Alexandru Popescu ☀:
Very interesting initiative Felix! Still, I am wondering why this
would not start as a Jackrabbit contrib project, and I don't think I
have seen this in the attached proposal.
The reason for not simply adding it as
[
https://issues.apache.org/jira/browse/JCR-1039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Guggisberg resolved JCR-1039.
Resolution: Fixed
fixed in svn r563900 by committing patch.
Bundle Persistence Manager
Problem 2:
2) The XPath jcr:like implementation, for example : //*[jcr:like(@mytext,'%foo
bar qu%')]
The jcr:like implementation (for sql holds the same) is translated to a
JackRabbit WildcardQuery which in turn uses a WildcardTermEnum which has a
protected boolean termCompare(Term term)
JCR2SPI: improve ItemDefinitionProviderImpl.getMatchingPropdef to better handle
multiple residuals
--
Key: JCR-1056
URL:
[
https://issues.apache.org/jira/browse/JCR-1056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke resolved JCR-1056.
-
Resolution: Fixed
Changed as proposed with revision 563916.
JCR2SPI: improve
Hello,
and sorry for spamming, but I just want to share my findings/impressions, and
what I am posting I am willimg to implement and port to the JackRabbit trunk
(so if you bother to read it, and are positive about it, I will implement it
:-) )
(if you make it to the end of this mail, I also
Managing releases that span multiple projects does tend to be a pain in
Jira as the version field is specific to a project. This means you
cannot query for all tasks for a release across multiple projects unless
you create a separate release field (at least that has been our
experience here at
Hi,
On 8/8/07, Padraic Hannon [EMAIL PROTECTED] wrote:
Managing releases that span multiple projects does tend to be a pain in
Jira as the version field is specific to a project. This means you
cannot query for all tasks for a release across multiple projects unless
you create a separate
[
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
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);
52 matches
Mail list logo
