Hi.
I just spent some time starting to get familiar with JCR in general, and
with Jackrabbit and jcr-server in particular. Now that everything is up
and running (built from svn, running in Tomcat 5.0.x, just with all the
default settings), I've started to look into the actual WebDAV server
Brian Moseley wrote:
On 4/6/06, Julian Reschke (JIRA) [EMAIL PROTECTED] wrote:
[ http://issues.apache.org/jira/browse/JCR-389?page=all ]
Julian Reschke updated JCR-389:
---
Attachment: diffs
This patch adds DavException to the signature
Angela,
thanks for applying the patch.
In the meantime I've submitted a new test case for Litmus that checks
shallow copy functionality in particular
(http://mailman.webdav.org/pipermail/litmus/2006-April/000194.html).
Best regards, Julian
Hi,
svn up currently fails (when fetching externals) for me because
http*s*://svn.apache.org is not responding. Is this a known issue, or do
I need to find out why my checkout doesn't use http://svn.apache.org
(which seems to be fine)?
Best regards, Julian
Jukka Zitting schrieb:
Hi,
On 6/6/06, Julian Reschke [EMAIL PROTECTED] wrote:
Tomcat 5.0.28 was conf'd to use JDK5. Jackrabbit's workspace bootstrap
seems to try to create config files using XSLT and failed because of a
dependency on the JDK 1.4 transformer (bug???).
Hmm, that sounds
Angela Schreiber schrieb:
hi
in JSR-283 internal discussion it has been decided, that
the issue covering a service provider interface (SPI) should
rather not be part of the follow-up specification.
this offers the possibility to open the discussion for
a broader audience and the expert group
Hi,
today I was looking into extracting the query parser code for use in a
non-Jackrabbit project. This turned out to be feasible due to good
documentation and code modularity (thanks!). Except:
org.apache.jackrabbit.core.query.xpath.XPathQueryBuilder has a
dependency on
Jukka Zitting schrieb:
Hi,
On 7/26/06, Julian Reschke [EMAIL PROTECTED] wrote:
org.apache.jackrabbit.core.query.xpath.XPathQueryBuilder has a
dependency on org.apache.jackrabbit.core.SearchManager, for the sole
purpose of importing to constants for namespace URIs. Would it be
possible to get
Jukka Zitting schrieb:
Hi,
On 7/27/06, Marcel Reutegger [EMAIL PROTECTED] wrote:
I'm ok with putting the namespace and default prefix constants in
QName. But only for namespaces that are final and that's exactly the
problem with the xpath-functions namespace.
Good point. Another alternative
Hi,
I was playing around with the QueryNode trees generated by the Xpath
parser. What I found is that they seem to be the same for
/a/b and /a | /b
(confirmed by QueryParser.toString(node, xpath, nsresolver), which in
both cases produces /a/b).
This is a bug, right?
Best regards, Julian
Hi,
attached is a set of patches to reduce the number of JavaDoc warnings (I
guess we don't want to open an issue for that, right? :-).
Best regards, Julian
Index: src/main/java/org/apache/jackrabbit/name/Path.java
===
---
Jukka Zitting schrieb:
Thanks! Committed as related to the javadoc issue JCR-73.
Thanks.
In general I would prefer to process all patches through Jira for
better tracking of changes and contributions.
Ok. In this particular case, does it make sense to open a new JIRA issue
for each
Marcel Reutegger (JIRA) schrieb:
[ http://issues.apache.org/jira/browse/JCR-523?page=all ]
Marcel Reutegger resolved JCR-523.
--
Fix Version/s: 1.1
Resolution: Fixed
Applied patch with minor formatting changes.
...
Thanks!
Hi,
as far as I understand, the TCK is supposed to run against an L1 (==
read only) repository. For instance, the property tests certainly try to
find testable properties without having to create them...
Now, AbstractJCRTest.cleanUpTestRoot fails due to
UnsupportedOperationExceptions over
Tobias Bocanegra schrieb:
Usually I completely separate Javadoc from the source.
wow. how do you achieve this? i thought that the javadoc is inlined in
the source code?
regards, toby
Maybe the misunderstanding here is that that file actually is *input* to
the Javadoc creation process (==
Marcel Reutegger schrieb:
1) Why nt:base? What if / has a type with more properties?
If the element test is absent the type constraint defaults to the one
that includes all node types: nt:base
OK, makes sense, but maybe this could be clarified somewhere in the spec.
If a query does not
Julian Reschke schrieb:
Marcel Reutegger schrieb:
1) Why nt:base? What if / has a type with more properties?
If the element test is absent the type constraint defaults to the one
that includes all node types: nt:base
OK, makes sense, but maybe this could be clarified somewhere in the spec
elangodi kalaimani schrieb:
Hi ,
This is with regard to a problem faced while trying to checkin/check out
files from Dreamweaver 8.0 to jackrabbit 1.0.1.
After analyzing the http conversation, I found the following things happening,
- The mix:versionable property and the
Hi,
first of all thanks for adding the SPI stuff, and apologies for not
having done anything with it earlier (as I was among those who asked for
it being in SVN even if work in progress).
I have now started to look at the SPI interfaces with an eye how I could
implement them for the backend
Marcel Reutegger schrieb:
Hi Julian,
Julian Reschke wrote:
Does this mean that any item needs to have both a unique ID, and a
relative path (relative to what...?).
I've added JavaDoc to the ItemId interface, which describes the
semantics of the UUID and the relative path part of the ItemId
Jukka Zitting schrieb:
Hi,
Please welcome Julian Reschke as a new committer and PMC member of the
Apache Jackrabbit project. The Jackrabbit PMC recently voted to grant
committership to Julian and he accepted the nomination. The related
administrational work is also now taken care of.
Julian
Hi,
ok, here's another SPI related question that hopefully isn't as dumb as
the last one...
I'm currently looking at SessionInfo (in the SPI API) and
SessionImpl.logout() (in jcr2spi).
It seems that the Session logout is handled entirely by the transient
layer, and no SPI method is called
Hi Angela,
thanks a lot for the good explanation about how you got where SPI is
now. More inline...
Angela Schreiber schrieb:
I'm currently looking at SessionInfo (in the SPI API) and
SessionImpl.logout() (in jcr2spi).
It seems that the Session logout is handled entirely by the transient
Nicolas schrieb:
Sorry, there is a misunderstanding.
Of course, everybody (even me) know assertions were introduced in Java 1.4.
That is not the issue.
Actually, I forgot (and whas mislead by Eclipse).
The issue is: JR doesn't build with Eclipse JDK 1.4 support enabled. You
need to switch
Hi,
here's a short question: is there a particular reason, why, for
instance, RepositoryService.getRepositoryDescriptors() uses a result
type of Properties?
In theory, a Map should be sufficient, and would have the benefit of
better support in the Collections framework (such as
Angela Schreiber schrieb:
ja... we discussed that before. the reason is, that repository
descriptors are defined to be key-value String pairs and we
wanted to make that clear.
Well,
I really think that's a bad idea. Please reconsider it (keep in mind
that JDK 1.5 will provide typing
Hi,
it seems that constraints and values that are NAMEs in JCR are supposed
to be expanded names (suitable for QName.valueOf()) in SPI. Is this
correct? If yes, shouldn't the descriptions in the JavaDoc spell that out?
Best regards, Julian
Hi,
I'm currently trying to implement SPI on top of a level 1 store, and see
(when accessed through jcr2spi):
1)
testLogin(com.xythos.jcr.BasicSPITest)javax.jcr.UnsupportedRepositoryOperationException:
level.2.supported is not supported by this repository.
at
Marcel Reutegger schrieb:
I think both approaches have their disadvantages. Using a map requires
casting to Strings (we currently have to stick with 1.4, I think) and
Properties class exposes methods like store and load which are useless
(or even dangerous).
Well, SPI already uses generic
Jukka Zitting schrieb:
Hi,
On 10/27/06, Marcel Reutegger [EMAIL PROTECTED] wrote:
I propose we change the RepositoryService interface and use the two
descriptor
methods defined in javax.jcr.Repository: getDescriptorKeys() and
getDescriptor(). The implementation then can use whatever
Hi,
another request for clarification...
Right now, it seems that the SPI still contains session-level namespace
prefix registrations. My original impression of the SPI was that we
wouldn't need that, and all session-level prefix mapping would be local
to the transient level. Did I miss
Marcel Reutegger schrieb:
Julian Reschke wrote:
Right now, it seems that the SPI still contains session-level
namespace prefix registrations. My original impression of the SPI was
that we wouldn't need that, and all session-level prefix mapping would
be local to the transient level. Did I
Angela Schreiber schrieb:
yes. the idea:
i quickly hacked the assertAvailability in to have
a reminder. it doesn't work anyway and i didn't commit
the latest changes.
and yes, it was obvious, that you are trying to use
the spi. but you have to live with completely instable
code at the moment.
Hi,
I did mention that I'm working on an SPI implementation for an existing
store, and trying to get it up with jcr2spi, right?
Anyway, in the meantime I can login to my store, and get the root node;
so far, so good.
If I now try hasNodes(), I'm getting the ClassCastException below...:
Angela Schreiber schrieb:
yes. the idea:
i quickly hacked the assertAvailability in to have
a reminder. it doesn't work anyway and i didn't commit
the latest changes.
and yes, it was obvious, that you are trying to use
the spi. but you have to live with completely instable
code at the moment.
Hi,
I just hit another problem with respect to an SPI implementation that is
Level-1 (for now), when accessed by JCR2SPI.
Previously, this would fail early because JCR2SPI just assumed that it
could get the ValueFactory from SessionInfo. Now, it keeps going, but
doesn't have the
Angela Schreiber schrieb:
hi julian
why do you think the ValueFactory comes from the SessionInfo?
Because I was confused :-) (and had been looking at JCR's Session
interface immediately before).
as far as i know, the ValueFactory is retrieved from the
configuration. so, perhaps you simply
Angela Schreiber schrieb:
...
btw: there is a simple ValueFactory in the jackrabbit-commons
package. you may use this one or provide your own.
BTW:
That ValueFactory unfortunately isn't as generic as I would like: it
enforces Reference properties to use UUID syntax, which of course isn't
Angela Schreiber schrieb:
hi julian
that was exactly the reason for not 'hardcoding' the
ValueFactoryImpl as it is the case in jackrabbit.
if you look at the spi2dav project you will find
a slightly modified ValueFactoryImpl, that deals
with exactly this issue.
however i would argue, that it
Hi,
I noticed that we don't have JIRA components for SPI yet. Shouldn't we
create those, or do we want to rely on the mailing list?
Best regards, Julian
Hi,
I'm getting an NPE inside jcr2spi if my QPropertyDefinition returns null
upon getDefaultValues(). Looking at the JCR API for
PropertyDefinition, it seems to me that null and empty arrays have
different semantics, so SPI should support both...
Best regards, Julian
===
Marcel Reutegger schrieb:
Hi Julian,
Julian Reschke wrote:
How about using an intermediate structure like jackrabbit does and
expose the version histories that way?
I have to confess that I'm not sure how it currently does that
(pointer?).
jackrabbit uses the 6 highest digits of the uuid
Hi,
here's a question about ChildNodeEntries.replaceEntry(). With my SPI
implementation, I'm currently seeing lots of NoSuchItemStateExceptions
logged by that method, although no exceptions occur and the caller seems
to get correct results...
Is this a TODO in JCR2SPI, or does it mean that
Marcel Reutegger schrieb:
...
hmm, the more I think about it, we might have to deal with this issue at
other occasions. It may happen that a node is returned by a query that
has never been requested, but its parent node has. assuming that the
jcr2spi layer still has the old version of the
(sorry for the late reply - had a customer visit for most of the
previous week).
Marcel Reutegger schrieb:
the current design of the spi demands that the client on top of the spi
resolves paths to ids and vice versa. this design was actually just
borrowed from the jackrabbit implementation,
...while looking at the nt:file/nt:folder discussion, I recently wrote a
small tool for visualizing the node type registry.
It works by transforming an XML system-view export of
/jcr:system/jcr:nodeTypes to a dot file, which then can be fed into
Graphviz.
Should I add that to contrib
Hi,
I'm getting a ClassCastException in NodeImpl.getVersionHistory...:
java.lang.ClassCastException
at
org.apache.jackrabbit.jcr2spi.NodeImpl.getVersionHistory(NodeImpl.java:1115)
The implementation casts a Property to a VersionHistory here. Is that a
known issue?
Best regards, Julian
Angela Schreiber schrieb:
hi julian
Julian Reschke wrote:
Is that a known issue?
no.
hmm... and actually it works for me...
For the record: the code in JCR2SPI is fine, and the problem was caused
by me SPI implementation.
Best regards, Julian
Marcel Reutegger schrieb:
Hi,
Marcel Reutegger schrieb:
major parts of the jcr2spi currently rely on hierarchical caching
structure of nodes and properties. which means if an item is in the
cache it's ancestors are cached as well. this simplified the handling
of spi ids a lot because in
Hi.
During my regression tests with JCR2SPI and my custom SPI implementation
I found a difference that may indicate a missing feature in SPI. Or not.
What happens is that I have a custom node type which internally holds a
potentially huge amount of property definitions, and for that reason,
Angela Schreiber schrieb:
hi
sorry. i reread you mail multiple times, and i don't get
your point.
Sorry, I'll try to do better this time.
here is what jsr170 defines:
- that PropertyDefinition.getRequiredType() may be one of
STRING, BINARY, DATE, LONG, DOUBLE, NAME, PATH, REFERENCE,
Jukka Zitting schrieb:
Hi,
On 11/22/06, Julian Reschke [EMAIL PROTECTED] wrote:
No, the point is that in JSR-170 it is possible that for a given node
type N, the NodeType interface will only return residual property
definitions (because the set of property definitions on this node type
may
Jukka Zitting schrieb:
Hi,
The Jackrabbit restructuring I did yesterday rendered some new
Jackrabbit components (jackrabbit-api, etc.) without Maven 1 builds
and broke the Maven 1 builds of some other components (most notably
jackrabbit-core).
I could fix the broken and add the missing Maven 1
Hi,
I was recently refactoring my permission check support and came across
the following issue:
public boolean isGranted(SessionInfo sessionInfo, ItemId itemId,
String[] actions) throws RepositoryException;
The problem here is that in some cases (such as in add_node and
set_property),
Tobias Bocanegra schrieb:
hi all,
2 weeks ago we promised to contribute our package mechanism for jcr
content to the jackrabbit project [JCR-733]. after a lengthy
(internal) discussion we decided to completely re-develop a new
content archiver that is based on a filesystem-like abstraction of
Tobias Bocanegra schrieb:
well, it seems that they use now .sar as new extension:
In the past SAP developed the tool and named it CAR. The extensions
of all compressed files were named .CAR as well. In SAP release 4.6C
SAP decided to enhance the functionality of the CAR utility a bit.
Tobias Bocanegra schrieb:
Unrelated to that...:
- use a standard format for the archive (i.e. zip/jar)
If you use ZIP/JAR as format, how are you going to handle non-ASCII
characters in filenames in a portable way?
all non-valid filesystem characters are escaped using url-escaping %xx
or
Hi,
I am using jcr2spi on top of a custom SPI implementation, and was trying
to come up with test cases that check the locking semantics (because I
know they weren't complete in my implementation).
After some testing I realized that JCR2SPI already does lock checking
locally (see
James Hang schrieb:
We're having problems running an xpath query where a node name in the xpath
contains blank spaces.
For example, the following query won't work because of the blank space in
the name Node A:
/jcr:root//mypath/Node A//element(*, myType) order by @cx:created ascending
We
Hi,
I noticed that the Session implementations both in Jackrabbit and
JCR2SPI require that the Credentials object passed into the
impersonate() method actually is a SimpleCredentials object. The purpose
seems to be that the impersonating session can be remembered in an
attribute on the
[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.
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
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
some eternal scp loop
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:
Jukka Zitting schrieb:
[ ] +1 Accept JCR Mapping from Graffito
[ ] -1 Do not accept the component because ...
+1
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 identifier.
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,
-
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
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
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
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 dependencies
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
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
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
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,
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
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 team
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
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
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 and starting to act
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 Firefox 3.0 alpha
Hi,
I can't help noticing that two out of three projects on
http://jackrabbit.zones.apache.org/continuum/servlet/continuum/target/Summary.vm/fid/continuumProject
are in status build error.
With respect to Jackrabbit itself, this is because of a recent code
change; maybe the test cases that
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
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
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
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
-
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
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 'official
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
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.
+1
Builds and passes tests with Java 1.5.0 on Win XP.
BR, Julian
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
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
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
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 that a remote
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
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 encounter
Hi,
it seems that the recent refactoring (jcr commons) has broken JCR2SPI --
I see lots of stack overflows -- see
http://jackrabbit.zones.apache.org:8080/continuum/surefireReport.action?buildId=194projectId=17projectGroupId=6#org.apache.jackrabbit.test.TestAll.
BR, Julian
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
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,
1 - 100 of 14391 matches
Mail list logo
