Felix Meschberger wrote:
Hi,
rant
Hmpf, I like XML in Java - it is more than complicated
/rant
...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
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
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,
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
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
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
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 never
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
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
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
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
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
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
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 1024 in size
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
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
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
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
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
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
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,
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
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
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 *extends* ChildInfo, so
that SPI
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). I'm looking
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-entries nor
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
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
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
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:
D:propX:comment foo='bar' xmlns:xhtml=... xmlns:X=...This is
an
Justin Lipton wrote:
I like Julian's example of xhtml:emimportant/xhtml:em which is an
illustration of mixed content XML but it is also convenient where you have a
straight multivalued property e.g.
D:propX:contributorsX:contributorAngela
Schreiber/X:contributorX:contributorJulian
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
...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
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
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
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
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
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
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 IteratorChildInfo
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
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
https://issues.apache.org/jira/browse/JCR-1437.
BR, Julian
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
[EMAIL PROTECTED] wrote:
Author: mreutegg
Date: Fri Feb 29 05:01:42 2008
New Revision: 632309
URL: http://svn.apache.org/viewvc?rev=632309view=rev
Log:
JCR-1104: JSR 283 support
- support for prepared queries has been moved to existing Query interface
- removed PreparedQuery again
Seems this
[EMAIL PROTECTED] wrote:
Author: jukka
Date: Thu Feb 28 01:54:43 2008
New Revision: 631908
URL: http://svn.apache.org/viewvc?rev=631908view=rev
Log:
JCR-1430: mvn eclipse:eclipse inconsistent
- Use the the new jjtree-javacc goal in javacc-maven-plugin version 2.4
- Contributed by
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=631908view=rev
Log:
JCR-1430: mvn eclipse:eclipse inconsistent
- Use the the new jjtree-javacc goal in javacc-maven-plugin
version 2.4
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
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 :-)
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
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
David Rauschenbach wrote:
I am remoting SPI, so I have to care about this, and block unnecessary
invocations in my client. As it is, my client-side cache runs at around
95% cache hits! That's how many SPI calls I have to block and not
interpret literally, by answering them out of a cache of
David Rauschenbach wrote:
I wanted to pass this finding along, just to get it out there.
After JCR2SPI submits a batch with a new node, it performs a getItemInfos,
presumably to refresh the node and see what server-side items might have been
assigned. This ItemInfo response, by definition, as
Hi.
First of all, many thanks for Marcel for figuring out what was causing
the previous regressions.
That being said, I'm seeing a new one:
---
Test set: org.apache.jackrabbit.jca.test.ConnectionFactoryTest
Marcel Reutegger wrote:
might be related to https://issues.apache.org/jira/browse/JCR-1460
not sure why it still complains, because JCR-1460 had been fixed.
regards
marcel
Seems it was only fixed in one place...
BR, Julian
Tobias Bocanegra wrote:
hi,
On 4/12/08, Dave Brosius [EMAIL PROTECTED] wrote:
I notice that many of the classes in Jackrabbit lack a toString method.
Without them, it makes debugging code more difficult. My question is, is
that intentional?
i don't think that this was intentional - just lazy
Yannick PIERSON wrote:
Hi,
I would like to know if I'm on the good way to perform my aim (- I want to
replace the current user of the operating system (windows in this case with
IIS) by another one who could access to a directory thanks to webdav. And
then get and store some documents on this
if it is still
unclear I can give more details.
Regards.
Yannick
2008/4/18, Julian Reschke [EMAIL PROTECTED]:
Yannick PIERSON wrote:
Hi,
I would like to know if I'm on the good way to perform my aim (- I want
to
replace the current user of the operating system (windows in this case
with
IIS
Yannick PIERSON wrote:
The authentication is made thanks to IIS through webdav protocol.
So are you looking for a Java component to do WebDAV access to a remote
IIS server?
Tobias Bocanegra wrote:
...
- in a pure read-only env, start with 1 session for each request or
share the same session among all requests. if you think this could be
a performance problem, implement a static or dynamic session pool.
...
Hm. How is this going to work in a multi-threaded
Tobias Bocanegra wrote:
- in a pure read-only env, start with 1 session for each request or
share the same session among all requests. if you think this could be
a performance problem, implement a static or dynamic session pool.
...
Hm. How is this going to work in a multi-threaded
Yannick PIERSON wrote:
Hi,
I want to develop thanks to jackrabbit a WebDAV access to a remote IIS
server.
So I would like to know which classes I have to use.
I have ever started with this code :
Repository repository = new TransientRepository();
SimpleCredentials credentials = new
Hi,
I was expecting that Jackrabbit is detecting concurrent modifications to
a node, and reject them with an InvalidItemStateException.
However, this test:
public void testoverlappingUpdate() throws RepositoryException,
UnsupportedEncodingException {
String testcontent = base
Julian Reschke wrote:
...
However, this test:
...passes, although I would expect it to fail.
Sorry for the incomplete mail :-)
BR, Julian
Alexander Klimetschek wrote:
Hi Julian!
I think it's correct. The property testconcurrent/jcr:content/jcr:data
in session 2 is never put into the transient space *before* session 1
saves. It is fetched for the first time when you modify it. That you
Actually, it *is* fetched before (in the
Alexander Klimetschek wrote:
Am 22.04.2008 um 20:17 schrieb Julian Reschke:
I think it's correct. The property
testconcurrent/jcr:content/jcr:data in session 2 is never put into
the transient space *before* session 1 saves. It is fetched for the
first time when you modify it. That you
Stefan Guggisberg wrote:
According to Julian, it does not throw an exception for him. Which is a
bug.
it does throw an exception in my case.
See attached test case -- which passes over here.
Maybe it depends on config/pm settings/whatever?
BR, Julian
/*
* Licensed to the Apache Software
Jukka Zitting wrote:
Hi,
On Wed, Apr 23, 2008 at 3:31 PM, Julian Reschke [EMAIL PROTECTED] wrote:
See attached test case -- which passes over here.
[...]
Session session1 = testRootNode.getSession();
Session session2 = super.superuser;
These are the same session.
...
Oh well
David Nuescheler wrote:
I indeed get the expected exception, but not for
n1.getProp
n2.getProp
n1.setProp
n1.save
n2.setProp
n2.save
...which I hoped for.
i think it would be totally legitimate for a content repository to either
throw or not... personally, i would not support
OK,
sorry for getting back to this discussion late.
I modified the test case so that the InvalidItemStateException indeed
occurs with jackrabbit-core (see attachment).
I think we have consensus that JSR-170 doesn't require a store to behave
like that; it's truly optional.
Now, with the
Tobias Bocanegra wrote:
hi,
as the implementation of the new features for jsr283 have started, i
suggest to put the new jsr283 interfaces to jackrabbit-api instead to
core (where possible). this way, we can already figure out
inter-module dependency issues and people can start using experimental
Jukka Zitting wrote:
Hi,
In JCR-1564 I implemented JSR 283 -style namespace handling for both
core and jcr2spi (using common code in jcr-commons). The changes are
compliant with JCR 1.0 and don't require extra API methods, but they
did raise the question of whether we should more generally be
Stefan Guggisberg wrote:
On Wed, May 14, 2008 at 1:04 PM, Jukka Zitting [EMAIL PROTECTED] wrote:
Hi,
In JCR-1564 I implemented JSR 283 -style namespace handling for both
core and jcr2spi (using common code in jcr-commons). The changes are
compliant with JCR 1.0 and don't require extra API
OK,
I saw no feedback on this.
Unless there are some immediate objections, I'll thus open a ticket
against JCR2SPI inability to pass the Session.refresh() call down to the
SPI layer.
BR, Julian
Julian Reschke wrote:
OK,
sorry for getting back to this discussion late.
I modified
Alexander Klimetschek wrote:
On Thu, Jun 5, 2008 at 10:04 AM, Michael Wechner
[EMAIL PROTECTED] wrote:
I would suggest the following addendum to
http://jackrabbit.apache.org/mailing-lists.html
Guidelines for job and contract posting
---
If you are looking
Hi,
I just noticed that the jcr-commons Value implementations (such as
DoubleValue) seems to allow constructing Value objects where the
internal value is null, and then consequently throw Exceptions when an
attempt is made to retrieve the value.
Shouldn't these fail early instead (when
Jukka Zitting wrote:
Hi,
Sun's Java 1.4.x is reaching EOL status in October, so I was wondering
if there's still need for us to continue using Java 1.4 as the
baseline for Jackrabbit. Upgrading the minimum platform requirement to
Java 5 would give us a) some nice language features, b) the
Stefan Guggisberg wrote:
jsr 283 currently requires java 1.4 or higher. if jackrabbit 2.0 (i.e.
Yes.
the JCR 2.0 RI) would require java 5 we have a compatibility
issue.
Really? Why. Or does the RI need to prove that it can be implemented in
Jave 1.4?
i'd be ok with moving to java 5 if
Julian Reschke (JIRA) wrote:
[
https://issues.apache.org/jira/browse/JCR-1104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke updated JCR-1104:
Attachment: sharednodesapi.diff
Proposed new interface o.a.j.a.jsr.283
Manfred Baedke wrote:
Hi,
currently I am working on the integration of WebDAV binding extensions
into |org.apache.jackrabbit.webdav.simple.SimpleWebdavServlet|, using
the shareable node feature of jsr-283.
The implementation of the BIND method was straightforward and worked as
expected, but
Thomas Müller wrote:
Hi,
I believe there is a typo in 'isInvisibleInAllprop'. Should it not be:
isInvisibleInAllProp (uppercase 'P').
Regards,
Thomas
Not really. The PROPFIND directive is called allprop, and I'm just
using camel case to put the words is invisible in allprop together.
BR,
[EMAIL PROTECTED] wrote:
Author: dpfister
Date: Tue Oct 7 05:43:55 2008
New Revision: 702459
URL: http://svn.apache.org/viewvc?rev=702459view=rev
Log:
JCR-1789 - Provide access to cluster records
- introduce classes that provide structured access to record contents
- add tests that verify
[EMAIL PROTECTED] wrote:
Hello,
I'm looking for a library that gives me access to webdav resources like
this one from the slide-project:
http://www.docjar.com/html/api/org/apache/webdav/lib/WebdavResource.java
.html
Is the something similar in the jackrabbit project I can use?
Thanks in
Philip Cher wrote:
...
Is there anything wrong somewhere that might cause the text file not
editable? And is there anything else for me to do to make text files
editable besides mounting differently as I described above?
...
That's a Windows issue, not a Jackrabbit issue. It applies to *any*
Hi,
it seems that currently JCR2SPI assumes that the NoteIds returned for
referenceable nodes actually do contain the UUID of that Node -- if the
SPI implementation returns an absolute path based NodeID instead,
JCR2SPI's Node.getUUID() implementation fails.
Proposals:
Either
1) Decide
Sebastian Lindstaedt wrote:
...
Given that creation scheme there are nodes with names that start with an number (e.g. 9428beec5dd65d1b54985661ca3eefca)
and there are nodes with names, that start with a character (e.g
a980d10665f268b0ec6c13ebea43034f). Using the same
David Nuescheler wrote:
...
Since functionally the CMIS specification is a subset of the
JCR specification it allows a very simple and straight-forward mapping to
a fully compliant JCR repository such as Jackrabbit.
...
Yes, the more challenging part is the mapping *from* a JCR repository
Dominique Pfister wrote:
Hi,
After having had a first look at the CMIS specification, I decided to
start off with the jcr-cmis implementation. I therefore created a
jcr-cmis sandbox with the following initial structure:
jcr-cmis
-- + server
+ rest
+ ws
I intend to start working on
Jukka Zitting wrote:
Hi,
On Thu, Dec 18, 2008 at 12:55 PM, Angela Schreiber anch...@day.com wrote:
i just had a short discussion with marcel regarding
the current status of the jackrabbit-jcr-test project
and whether or not we should starting adding/modifying
tests related to new/changed jsr
imadhusudhanan wrote:
Dear All,
I have a Warning in the windows client saying An error while
copying some or all the files. I had extended the SimpleWebDavServlet
and written a custom doPut() method that overrides that of the
AbstractWebdavServlet so that any put request is redirected
imadhusudhanan wrote:
Sorry if thats so foolish. Kindly apologize. I m a newbie to JackRabbit
and learning the same. May I know which response I may deliver so that I
client says OK. take care.
Regards,
Madhu.
PUT is defined in RFC 2616, so the answer is there (for instance, 200
when
Thomas Mueller (JIRA) wrote:
[ https://issues.apache.org/jira/browse/JCR-2007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12680886#action_12680886 ]
Thomas Mueller commented on JCR-2007:
-
Julian - see the test
Hi there.
Now that JSR-283 is in public review, do we have a plan how to get the
Jackrabbit trunk implement the JCR 2.0 API?
Best regards, Julian
Jukka Zitting wrote:
Hi,
On Tue, Apr 21, 2009 at 4:40 PM, Serge Huber shub...@jahia.com wrote:
But I would miss the current name, as I agree it is good :)
Me too. How about if we just slightly modified it, say to Apache
Chemi or something similar?
Chemist
BR, Julian (helping to paint the
Jukka Zitting wrote:
Hi,
As a followup to the Jackrabbit 1.6 release plan I sent earlier,
here's a quick roadmap towards Jackrabbit 2.0.
...
+1 on the specific plan, and also thanks a lot for doing the planning work!
BR, Julian
+1 Approve the Chemistry project for incubation
BR, Julian
Marcel Reutegger wrote:
Hi,
On Mon, Apr 27, 2009 at 13:21, Julian Reschke julian.resc...@gmx.de wrote:
2) identify additional test cases that currently live in other Jackrabbit
projects that should be moved in jackrabbit-jcr-tests.
that should be easy, they live here:
https://svn.apache.org
Hi,
as a test, I tried to upgrade jackrabbit-core to JCR 2.0, by replacing
all instances of org.apache.jackrabbit.api.jsr283 by javax.jcr. I
found the following issues:
1) New methods on javax.jcr.Repository
The type BindableRepository must implement the inherited abstract
method
Julian Reschke wrote:
3) New methods on javax.jcr.observation.EventIterator:
The type EventJournalImpl must implement the inherited abstract method
EventIterator.getDate()EventJournalImpl.java
jackrabbit-core/src/main/java/org/apache/jackrabbit/core/observation
line 52Java Problem
Jukka Zitting wrote:
Hi,
Great stuff, thanks!
On Wed, Apr 29, 2009 at 5:30 PM, Julian Reschke julian.resc...@gmx.de wrote:
-- Permitting time, I will try adding workarounds (by adding stubs) for now
It would be good to accompany any new method stubs with a Jira issue
(new or existing
Julian Reschke wrote:
5) New methods on javax.jcr.Node:
...
jackrabbit-core/src/main/java/org/apache/jackrabbit/coreline 110
Java Problem
The type NodeImpl must implement the inherited abstract method
Node.getWeakReferences()NodeImpl.java
jackrabbit-core/src/main/java/org/apache
Julian Reschke wrote:
5) New methods on javax.jcr.Node:
...
jackrabbit-core/src/main/java/org/apache/jackrabbit/coreline 110
Java Problem
The type NodeImpl must implement the inherited abstract method
Node.setProperty(String, BigDecimal)NodeImpl.java
jackrabbit-core/src/main
101 - 200 of 14429 matches
Mail list logo
