[
https://issues.apache.org/jira/browse/OAK-179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller resolved OAK-179.
Resolution: Fixed
Fixed in revision 1360591
Tests should not fail
[
https://issues.apache.org/jira/browse/JCR-3385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13412775#comment-13412775
]
Thomas Mueller commented on JCR-3385:
-
The problem is that the ports are also hardcoded
[
https://issues.apache.org/jira/browse/JCR-3385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller updated JCR-3385:
Attachment: JCR-3385-embedded-shared-db.patch
Alternative patch using an embedded database - a bit
[
https://issues.apache.org/jira/browse/JCR-3385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller resolved JCR-3385.
-
Resolution: Fixed
I have committed my patch now - not because it's better thank Jukkas patch
[
https://issues.apache.org/jira/browse/OAK-178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13412591#comment-13412591
]
Thomas Mueller commented on OAK-178:
and define an Oak namespace
Sure! How would I do
[
https://issues.apache.org/jira/browse/OAK-178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13412594#comment-13412594
]
Thomas Mueller commented on OAK-178:
Like this?
#P oak-jcr
Index:
src/main/resources
[
https://issues.apache.org/jira/browse/OAK-178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13412609#comment-13412609
]
Thomas Mueller commented on OAK-178:
I saw the following change is also needed:
#P oak
Thomas Mueller created OAK-179:
--
Summary: Tests should not fail if there is a jcr:system node
Key: OAK-179
URL: https://issues.apache.org/jira/browse/OAK-179
Project: Jackrabbit Oak
Issue Type
Thomas Mueller created OAK-180:
--
Summary: More real world benchmarks
Key: OAK-180
URL: https://issues.apache.org/jira/browse/OAK-180
Project: Jackrabbit Oak
Issue Type: New Feature
Thomas Mueller created OAK-181:
--
Summary: Observation / indexing: don't create events for index
updates
Key: OAK-181
URL: https://issues.apache.org/jira/browse/OAK-181
Project: Jackrabbit Oak
Thomas Mueller created OAK-178:
--
Summary: Query: index definition documentation and tooling
Key: OAK-178
URL: https://issues.apache.org/jira/browse/OAK-178
Project: Jackrabbit Oak
Issue Type
[
https://issues.apache.org/jira/browse/OAK-169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13410207#comment-13410207
]
Thomas Mueller commented on OAK-169:
Again about linked list: Jukkas has a point
[
https://issues.apache.org/jira/browse/JCR-3376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13409317#comment-13409317
]
Thomas Mueller commented on JCR-3376:
-
Thanks Jukka! I didn't consider the possibility
[
https://issues.apache.org/jira/browse/JCR-3376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller updated JCR-3376:
Description:
The TCK test SQLPathTest.testChildAxisRoot runs the following SQL-1 query:
SELECT
[
https://issues.apache.org/jira/browse/JCR-3376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller resolved JCR-3376.
-
Resolution: Fixed
Revision 1359213 allows for optional nodes to be in the result. For the test
[
https://issues.apache.org/jira/browse/OAK-169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13409228#comment-13409228
]
Thomas Mueller commented on OAK-169:
Iterating over all child nodes is always an O(n
[
https://issues.apache.org/jira/browse/OAK-169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13409228#comment-13409228
]
Thomas Mueller edited comment on OAK-169 at 7/9/12 7:05 AM
Thomas Mueller created JCR-3376:
---
Summary: TCK: SQLPathTest.testChildAxisRoot expected root node not
in result
Key: JCR-3376
URL: https://issues.apache.org/jira/browse/JCR-3376
Project: Jackrabbit
[
https://issues.apache.org/jira/browse/JCR-3376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller resolved JCR-3376.
-
Resolution: Fixed
Fix Version/s: 2.6
TCK: SQLPathTest.testChildAxisRoot expected root
Hi,
I agree with Felix. I don't currently see a need for Sling to bypass the
JCR API. If that would be needed, there is something wrong with the JCR
API or the JCR implementation.
About indexing:
Another potential Sling extension would be a custom Oak index provider
for optimizing the kinds
Hi,
I'm not sure what you mean here. I don't see Sling having it's own index
*mechanism*. Probably Sling will need specific indexes, but that's just
configuration, and not implementation (code)...
Being able to integrate totally different indexing mechanisms can be
useful if Oak can provide
[
https://issues.apache.org/jira/browse/OAK-155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller reassigned OAK-155:
--
Assignee: Thomas Mueller
Query: limited support for the deprecated JCR 1.0 query language
Hi,
The test case SQLPathTest.testChildAxisRoot runs the following SQL-1 query:
SELECT * FROM nt:base WHERE jcr:path LIKE '/%' AND NOT jcr:path LIKE '/%/%'
It expected the result to be
/jcr:system, /testroot, /testdata
Shouldn't / (the root node) also be part of the result? The
Hi,
Thanks a lot! I see the current Jackrabbit 2.x works as required by the
specification. I was worried there is a bug. Well, the specification is a bit
strange because the SQL expression ('/' LIKE '/%') should clearly return true.
But that's OK, there is no rule that a specification can't be
Thomas Mueller created JCR-3363:
---
Summary: DataStore garbage collection: test case
GarbageCollectorTest.testGC() is to lenient
Key: JCR-3363
URL: https://issues.apache.org/jira/browse/JCR-3363
Project
Thomas Mueller created OAK-155:
--
Summary: Query: limited support for the deprecated JCR 1.0 query
language Query.SQL
Key: OAK-155
URL: https://issues.apache.org/jira/browse/OAK-155
Project: Jackrabbit
[
https://issues.apache.org/jira/browse/OAK-155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13402996#comment-13402996
]
Thomas Mueller commented on OAK-155:
My current plan is to use a strict parser for both
Hi,
I would prefer if the Scalability and performance review would start
earlier.
Regards,
Thomas
On 6/28/12 1:43 PM, Jukka Zitting jukka.zitt...@gmail.com wrote:
Hi,
We missed pushing the 0.3 release out a month ago, but let's fix that
by cutting the release instead of 0.4 now at the turn
Hi,
Yes, we can do such a benchmark (the oak-bench component already has
the basics in place), though personally I don't see the single-node
case as a particularly interesting one to benchmark. Unless we want to
also target embedded systems, any truly performance-critical
deployments will
Hi Betrand,
FWIW, as a Sling user I agree that the freeze my view of the
repository for a while, whatever others are doing feature looks like
a useful one to expose over an Oak HTTP remoting layer.
Do you mean having a consistent snapshot of the data at a given point in
time? Yes, we want to
Hi,
I understand the point Felix is making. As of now, I would propose to drop
separate URI spaces.
I would also propose to drop the related MicroKernel branch/merge feature,
or at least not rely on the feature to be available. In my view, the
MicroKernel branch/merge feature which was
[
https://issues.apache.org/jira/browse/JCR-3321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller resolved JCR-3321.
-
Resolution: Fixed
Fix Version/s: 2.6
TCK: Strange XPath query
[
https://issues.apache.org/jira/browse/JCR-2686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller resolved JCR-2686.
-
Resolution: Fixed
I just saw we already have a GarbageCollector.close() method which does stop
[
https://issues.apache.org/jira/browse/JCR-2286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller resolved JCR-2286.
-
Resolution: Won't Fix
I don't plan to fix it in Jackrabbit 2.x
Implement
[
https://issues.apache.org/jira/browse/JCR-2998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller resolved JCR-2998.
-
Resolution: Won't Fix
We have SessionState debug logging options, I don't think we need anything
Hi,
- We can implement the polling approach (using a 0 timeout) but also have
the option to do blocking. Since this can be directly delegated to the
Microkernel (waitForCommit) the added complexity for this is minimal.
The complexity is still there, it's just one level below. Personally
I'd
it) and whether
this needs to be in the MicroKernel API is a different question.
Regards,
Thomas
On 6/19/12 9:27 AM, Thomas Mueller muel...@adobe.com wrote:
Hi,
- We can implement the polling approach (using a 0 timeout) but also
have
the option to do blocking. Since this can be directly
[
https://issues.apache.org/jira/browse/JCR-3340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13294941#comment-13294941
]
Thomas Mueller commented on JCR-3340:
-
As discussed offline with Mete we came
Thomas Mueller created JCR-3341:
---
Summary: GarbageCollector should fail fast if there is a problem
Key: JCR-3341
URL: https://issues.apache.org/jira/browse/JCR-3341
Project: Jackrabbit Content
[
https://issues.apache.org/jira/browse/JCR-3341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller updated JCR-3341:
Attachment: JCR-3341.patch
GarbageCollector should fail fast if there is a problem
[
https://issues.apache.org/jira/browse/JCR-3341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller updated JCR-3341:
Assignee: Thomas Mueller
Status: Patch Available (was: Open)
A patch for the 2.2 branch
[
https://issues.apache.org/jira/browse/OAK-138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13294318#comment-13294318
]
Thomas Mueller commented on OAK-138:
The data store that is currently in oak-mk
[
https://issues.apache.org/jira/browse/OAK-138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13294428#comment-13294428
]
Thomas Mueller commented on OAK-138:
OK, my personal opinion is still to use as few
Thomas Mueller created OAK-140:
--
Summary: PropertyState: data type of empty array property
Key: OAK-140
URL: https://issues.apache.org/jira/browse/OAK-140
Project: Jackrabbit Oak
Issue Type
[
https://issues.apache.org/jira/browse/JCR-?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13293408#comment-13293408
]
Thomas Mueller commented on JCR-:
-
Hi,
Well, I still don't know which version
[
https://issues.apache.org/jira/browse/JCR-?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13293452#comment-13293452
]
Thomas Mueller commented on JCR-:
-
Hi,
I suggest you first read all
[
https://issues.apache.org/jira/browse/OAK-138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13293499#comment-13293499
]
Thomas Mueller commented on OAK-138:
The log wrapper is a somewhat similar implementation
[
https://issues.apache.org/jira/browse/OAK-138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13293842#comment-13293842
]
Thomas Mueller commented on OAK-138:
I'm wondering why we have so many Maven projects
[
https://issues.apache.org/jira/browse/JCR-?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13292706#comment-13292706
]
Thomas Mueller commented on JCR-:
-
What version of Jackrabbit do you use exactly
[
https://issues.apache.org/jira/browse/JCR-?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller resolved JCR-.
-
Resolution: Not A Problem
Resolving as not a problem, because it works as designed in very old
Hi,
It says witching to DataStore.
Yes, you should do that. If you do, it wouldn't be stored twice.
Regards,
Thomas
On 6/7/12 4:59 AM, jacktu ch.shangr...@gmail.com wrote:
For my project, I find that the data is increasing really fast. I find
that
it is stored (likely)twice in Workspace and
[
https://issues.apache.org/jira/browse/JCR-?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13292730#comment-13292730
]
Thomas Mueller commented on JCR-:
-
To upgrade to a recent version of Jackrabbit, see
[
https://issues.apache.org/jira/browse/JCR-?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13292763#comment-13292763
]
Thomas Mueller commented on JCR-:
-
If using JCR 2.1.2, then I wonder why the data
Thomas Mueller created OAK-137:
--
Summary: Query: content index
Key: OAK-137
URL: https://issues.apache.org/jira/browse/OAK-137
Project: Jackrabbit Oak
Issue Type: Improvement
[
https://issues.apache.org/jira/browse/OAK-13?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13291001#comment-13291001
]
Thomas Mueller commented on OAK-13:
---
The index component is still under heavy development. I
[
https://issues.apache.org/jira/browse/OAK-13?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13291035#comment-13291035
]
Thomas Mueller commented on OAK-13:
---
I will take some more time until the index
[
https://issues.apache.org/jira/browse/OAK-13?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13291049#comment-13291049
]
Thomas Mueller commented on OAK-13:
---
Something (hopefully) less controversial:
What about
[
https://issues.apache.org/jira/browse/JCR-2666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13286418#comment-13286418
]
Thomas Mueller commented on JCR-2666:
-
In your patch, you have the following code within
[
https://issues.apache.org/jira/browse/JCR-2666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller updated JCR-2666:
Comment: was deleted
(was: In your patch, you have the following code within the loop
[
https://issues.apache.org/jira/browse/JCR-3313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13286519#comment-13286519
]
Thomas Mueller commented on JCR-3313:
-
(sorry I originally added this comment
[
https://issues.apache.org/jira/browse/JCR-3313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller updated JCR-3313:
Resolution: Fixed
Status: Resolved (was: Patch Available)
Thanks a lot for the patch
[
https://issues.apache.org/jira/browse/OAK-120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller resolved OAK-120.
Resolution: Fixed
Patch applied in revision 1344746
MicroKernel API: specific
Thomas Mueller created JCR-3324:
---
Summary: TCK: GetQueryTest.testGetQuery() unnecessarily uses a
same name sibling
Key: JCR-3324
URL: https://issues.apache.org/jira/browse/JCR-3324
Project: Jackrabbit
[
https://issues.apache.org/jira/browse/JCR-3324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller resolved JCR-3324.
-
Resolution: Fixed
TCK: GetQueryTest.testGetQuery() unnecessarily uses a same name sibling
Thomas Mueller created OAK-120:
--
Summary: MicroKernel API: specific retention policy of binaries
Key: OAK-120
URL: https://issues.apache.org/jira/browse/OAK-120
Project: Jackrabbit Oak
Issue
Hi,
I'm fine with getNodeByUUID() relying on the query system. The query
system on the other hand should be able to work even when no indexes
are available, falling back to tree traversal when all else fails.
Yes, that's the current plan.
This is not an urgent feature, but if no index is
[
https://issues.apache.org/jira/browse/OAK-117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13284818#comment-13284818
]
Thomas Mueller commented on OAK-117:
Sounds good! But I wonder if it would prevent us
Thomas Mueller created JCR-3321:
---
Summary: TCK: Strange XPath query in
OrderByMultiTypeTest.testMultipleOrder
Key: JCR-3321
URL: https://issues.apache.org/jira/browse/JCR-3321
Project: Jackrabbit
Hi,
The query engine in oak-core needs to normalize paths and names (convert
./name to name), for example for the TCK test
org.apache.jackrabbit.test.api.query.qom.NodeNameTest.testURILiteral. I don't
see a way to do the normalization within oak-jcr. The component that seems to
be able to do
Hi,
+1 to adding it to the parent POM.
Did you already figure out a way for us to integrate FindBugs checks
to to the test phase of the build so we could fail the build if
explicitly enabled FindBugs checks fail?
Would it be possible (until we have more experience) to only *log*
warnings where
Hi,
1) Would it make sense to start tracking more closely which Query tests
are passing? Right now all of them are marked as failing in the pom...
(and yes, I can do that, but I wanted to wait until it makes sense)
I ran the TCK test to find out what areas are missing or not working
correctly.
Hi,
The reason why I'm asking is that if we leave things as they are right
now, we won't notice regressions, because all of the tests are marked as
known failures. Thus, once the majority of functionality is there, we
should make the exclusions more fine-grained.
I see. Yes, if you have time,
Hi,
A minor issue: some of us use @see also javadocs and some not. For
example:
/**
* @see Object#hashCode()
*/
@Override
public int hashCode() {
return value.hashCode();
}
I find it kind of useless to write such javadoc tags, because javadoc
anyway adds a
Hi,
My thinking was to make this opaque to oak-core. That is, set the value
of the path property to the jcr path and let oak-jcr handle it. Unless
there is a case (which might well be) where we need to dereference such
paths properties from within oak-core this should work.
I don't think this
Thomas Mueller created OAK-98:
-
Summary: Source code formatting, code conventions, Javadocs
Key: OAK-98
URL: https://issues.apache.org/jira/browse/OAK-98
Project: Jackrabbit Oak
Issue Type
[
https://issues.apache.org/jira/browse/OAK-89?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13270297#comment-13270297
]
Thomas Mueller commented on OAK-89:
---
I have the same concerns as Michael. I believe if we
[
https://issues.apache.org/jira/browse/OAK-89?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13270312#comment-13270312
]
Thomas Mueller commented on OAK-89:
---
Yes, it makes sense to wait until we have real cases
Hi,
There is no plan (that I know of) to support SOLR for Jackrabbit 2.x. However,
for project Oak (the successor of Jackrabbit 2.x) there is a plan to support a
pluggable index, and very likely a SOLR will be one of the supported index
backends. It will take a while until this is available
Hi,
What I'm trying to achieve is for us to be easily able to support all
such deployments without trying to force everything to go through a
single mechanism like the repository.xml in Jackrabbit 2.x.
Yes, the repository.xml was problematic (for multiple reasons).
It's fine to have a utility
Hi Jukka,
I guess you wanted to write non-OSGi instead of plain Java?
Regards,
Thomas
On 5/6/12 9:51 PM, Jukka Zitting (JIRA) j...@apache.org wrote:
Jukka Zitting created OAK-87:
Summary: Declarative services and OSGi configuration
[
https://issues.apache.org/jira/browse/OAK-75?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13269429#comment-13269429
]
Thomas Mueller commented on OAK-75:
---
+1 for the patch!
node name filtering ... large node
[
https://issues.apache.org/jira/browse/OAK-75?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13269437#comment-13269437
]
Thomas Mueller commented on OAK-75:
---
globbing syntax for filter needs to be specified
[
https://issues.apache.org/jira/browse/OAK-75?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13269437#comment-13269437
]
Thomas Mueller edited comment on OAK-75 at 5/7/12 7:53 AM
...@gmail.com wrote:
Hi,
On Mon, May 7, 2012 at 9:02 AM, Thomas Mueller muel...@adobe.com wrote:
I guess you wanted to write non-OSGi instead of plain Java?
Essentially yes, but there's a subtle point here. Let me explain.
A specific non-OSGi setup could be something like repository.xml
-based
Hi,
+1
I also used the check-release.sh script, there were a few minor issues:
- gpg: BAD (but md5 and sha were GOOD)
- the script created two directories: -v and -p
- svn: URL
'http://svn.apache.org/repos/asf/jackrabbit/oak/tags/jackrabbit-oak-0.2.1'
doesn't exist
(there are 0.2.1/ and
Hi,
let's assume CoreValue.getString() could throw a
RepositoryException (when there is an error converting the value to a
string). If we do that, then we would have to add exception handling to
a
That examples seems a bit academic right now, as CoreValue.getString()
indeed never throws (it
Hi,
I wouldn't want to catch RuntimeException. I'd prefer if oak-core would
only throw OakException (extends RuntimeException), as suggested by
Michael Dürig.
+1
I also think it would be good if these Oak exceptions could carry
sufficient information to generate a JCR exception.
+1
The
Hi,
If the OakException wraps a RepositoryException, we extract that one and
rethrow it, it will come with an incorrect stack trace, no?
You mean, if we use throw ((OakException) e).getOriginalException() or
something similar when unwrapping?
So it seems
we need to re-wrap.
Not sure what you
[
https://issues.apache.org/jira/browse/OAK-75?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13267487#comment-13267487
]
Thomas Mueller commented on OAK-75:
---
my intention was to specify the 'path' filter
[
https://issues.apache.org/jira/browse/OAK-56?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13267514#comment-13267514
]
Thomas Mueller commented on OAK-56:
---
Your (new) deleteRecursive implementation doesn't
[
https://issues.apache.org/jira/browse/OAK-56?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13267516#comment-13267516
]
Thomas Mueller commented on OAK-56:
---
I'm fine with leaving the code in svn for now
Hi,
I suggest to check why it's using 100% cpu. A simple way to do that is to
use
jps -l (to get the process id)
Then get a few full thread dumps using
jstack -l pid
Then check in the full thread dump what's going on.
I guess the bottleneck is calculating the content hash (SHA-1
Hi,
Another likely CPU consumer is full text indexing, especially if
you're dealing with a complex PDF or Office document.
Yes, I forgot. By the way, if you don't need the full-text index, you can
disable it.
Regards,
Thomas
[
https://issues.apache.org/jira/browse/OAK-80?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13266510#comment-13266510
]
Thomas Mueller commented on OAK-80:
---
If we want to support an efficient remoting between
[
https://issues.apache.org/jira/browse/OAK-80?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13266605#comment-13266605
]
Thomas Mueller commented on OAK-80:
---
the long term goal
... Anyway, I don't see how that's
Hi,
My idea here is that any pluggable components passed to a
ContentRepositoryImpl or other core class should be already
initialized or be able to lazily initialize itself when needed.
I understand the concern about the lifecycle, but I would also like to
avoid reading from the repository in
Hi,
my preference was to just throw the jcr-exceptions where
ever this was appropriate and unambiguous. for example
namespaceexception, versionexception, constraintviolation...
I can't comment on NamespaceException, VersionException, and so on.
What I find problematic is, if almost all methods
[
https://issues.apache.org/jira/browse/OAK-73?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller updated OAK-73:
--
Summary: JsopReader and JsopWriter lack javadocs (was: JsopReader lacks
any javadoc description
[
https://issues.apache.org/jira/browse/OAK-73?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller resolved OAK-73.
---
Resolution: Fixed
Mainly fixed now
JsopReader and JsopWriter lack javadocs
[
https://issues.apache.org/jira/browse/OAK-73?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13261723#comment-13261723
]
Thomas Mueller commented on OAK-73:
---
Sure. Partially the documentation
501 - 600 of 1738 matches
Mail list logo
