Status of jcr-server
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 implementation. First step was to run the generic test suite Litmus (http://www.webdav.org/neon/litmus/), which currently reports a range of failures, some of which seem to be trivial (non wellformed request bodies not rejected with status 400), some not (such as If header evaluation problems, PROPPATCH tests all failing). In the mid-term, I'd like to contribute to jcr-server, both in fixing compliance problems, but also in adding features (Redirect support? Property datatype support). For now, what's the best way to start? If I'm sure I found an actual problem in the code, should I open a bug report over at http://issues.apache.org/jira/browse/JCR, then try to provide a patch? Also, what are the current goals for jcr-server? Is it just a proof-of-concept, or is it supposed to become a fully compliant implementation of the applicable RFCs? Is it supposed to follow the changes in RFC2518bis as well? Best regards, Julian
Re: [jira] Updated: (JCR-389) WebDAV server should treat non-wellformed XML in request bodies as error
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 of getRequestDocument(), and attempts to make sure that an exception is thrown when a request body is present but not well-formed (wrapping the InputStream with a BufferedInputStream and peeking at the first byte was the most reliable way I could think of to find out whether there actually was a request body). looks fine to me. i've used PushbackInputStream to do the same thing, but i don't have a preference either way. i'm throwing IllegalArgumentException in order to avoid changing the method signature, but i prefer the way you've done it. At a later point of time, we may want to return more details in the 400 response body, and that IMHO justifies the DavException. another change i've made to this method is to return null when there's no request content. this lets the servet layer behave differently if there's no content or if there's content but it can't be read. this is useful for caldav where a MKCALENDAR can have a request body but does not have to, and the servlet layer needs to know which is the case. That's correct, the patch does that as well (for instance, that's also required for OPTIONS and PROPFIND). Best regards, Julian
Re: [jira] Closed: (JCR-391) WebDAV method invocation trying to create a new resource should fail with 409 (Conflict) if parent resource does not exist
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
svn problem with svn.apache.org
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
Re: jackrabbit-server-1.0.1.war Premature end of file
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 suspicious, we had a similar issue earlier. Could you file a bug report? I'll take a better look at it. I don't have the log files anymore, so it wouldn't be a *good* bug report. As far as I remember, it was the same stack trace as reported in http://www.mail-archive.com/user-list@magnolia.info/msg03040.html: -- INFO info.magnolia.cms.beans.config.ConfigLoader ConfigLoader.java (load:110) 18.05.2006 16:36:54 Init content repositories INFO info.magnolia.cms.beans.config.ContentRepository ContentRepository.java(init:177) 18.05.2006 16:36:54 System : loading JCR INFO info.magnolia.cms.beans.config.ContentRepository ContentRepository.java(loadRepository:304) 18.05.2006 16:36:54 System : loading JCR magnolia INFO info.magnolia.jackrabbit.ProviderImpl ProviderImpl.java(init: 140) 18.05.2006 16:36:54 Loading repository at C:\Daten\Projekte \Magnolia\AccelsisWebsite\m agnolia-3.0-b1_with_tomcat\tomcat\webapps\magnoliaAuthor \repositories\magnolia (config file: C:\Daten\Projekte\Magnolia \AccelsisWebsite\magnolia-3.0-b1_with_tom cat\tomcat\webapps\magnoliaAuthor\WEB-INF\config\repo-conf \jackrabbit-derby-search.xml) ERROR info.magnolia.jackrabbit.ProviderImpl ProviderImpl.java(init: 175) 18.05.2006 16:36:54 Unable to initialize repository: Provider org.apache.xalan.process or.TransformerFactoryImpl not found javax.xml.transform.TransformerFactoryConfigurationError: Provider org.apache.xalan.processor.TransformerFactoryImpl not found at javax.xml.transform.TransformerFactory.newInstance (Unknown Source) at org.apache.jackrabbit.core.config.RepositoryConfig.internalCreateWorks paceConfig(RepositoryConfig.java:516) at org.apache.jackrabbit.core.config.RepositoryConfig.createWorkspaceConf ig(RepositoryConfig.java:571) at -- ...so maybe somebody is specifying an XSLT provider that doesn't exist in JDK5? Best regards, Julian
Re: SPI contribution to Jackrabbit
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 agreed on contributing the existing efforts to Jackrabbit, if this would be generally accepted. marcel and myself started with a jcr-to-spi project and added a spi-to-dav layer in order to be able to study the feasibility of the basic concept. this is still far from being completed, but if there is some interest, we would start with a contribution. more details, aims of an SPI will follow. we just need some time to clean up the work done so far (license header, project files, ) angela I am definitively interested. Best regards, Julian
Re-using the query parsers outside Jackrabbit
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 org.apache.jackrabbit.core.SearchManager, for the sole purpose of importing to constants for namespace URIs. Would it be possible to get rid of that dependency? Best regards, Julian
Re: Re-using the query parsers outside Jackrabbit
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 rid of that dependency? I don't see any reason not to, though it would be nice to avoid duplicating the constants. Putting the constants to QName sounds reasonable. Would you like to contribute a patch for that? QName would be ok for me but may be non-optimal for other use cases. But as long as nobody complains, QName is fine. PS. A related issue, we should perhaps update the XPath function namespace from the draft namespace http://www.w3.org/2004/10/xpath-functions we currently use to the official XPath 2.0 function namespace http://www.w3.org/2005/xpath-functions. I'm not sure if there will be backwards compatibility implications in doing this. As far as I can tell, it doesn't affect JCR compliance (the string doesn't appear in the spec). So that change would affect people who overwrite the internal fn prefix mapping? That may be a problem; not sure how big. Maybe just try it in the development branch first? Best regards, Julian
Re: Re-using the query parsers outside Jackrabbit
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 for breaking the dependency is simply to duplicate the namespace URI in the XPathQueryBuilder class until we are happy with putting it to jackrabbit-commons. Yep. Let's keep the issues separated. I'll open an issue for exactly the code dependency problem; and I'll add a patch with copies the namespace URIs into XPathQueryBuilder (note that this seems to be the only usage outside SearchManager, so the constants over there could be made private -- should I do that as well?). ... Best regards, Julian
XPath query parser issue?
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
Patches for JavaDoc warnings
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
===
--- src/main/java/org/apache/jackrabbit/name/Path.java (revision 427141)
+++ src/main/java/org/apache/jackrabbit/name/Path.java (working copy)
@@ -165,7 +165,6 @@
* @param jcrPath
* @param resolver
* @param normalize
- * @return
* @throws MalformedPathException
* @deprecated Use PathFormat#parse(String, NamespaceResolver)} instead.
*/
@@ -189,7 +188,6 @@
* @param relJCRPath
* @param resolver
* @param canonicalize
- * @return
* @throws MalformedPathException
* @deprecated Use [EMAIL PROTECTED] PathFormat#parse(Path, String,
NamespaceResolver)} instead.
*/
@@ -213,7 +211,6 @@
* @param parent
* @param relPath
* @param normalize
- * @return
* @throws MalformedPathException if coderelPath/code is absolute
*/
public static Path create(Path parent, Path relPath, boolean normalize)
@@ -991,8 +988,8 @@
/**
* Creates a new path element with the given qualified name and index.
* If the name is equals to the name of a special element, like the
- * [EMAIL PROTECTED] PARENT_ELEMENT},[EMAIL PROTECTED]
CURRENT_ELEMENT} or the
- * [EMAIL PROTECTED] ROOT_ELEMENT}, then it's instance is returned.
+ * [EMAIL PROTECTED] #PARENT_ELEMENT},[EMAIL PROTECTED]
#CURRENT_ELEMENT} or the
+ * [EMAIL PROTECTED] #ROOT_ELEMENT}, then it's instance is returned.
* p/
* the private constructor must never be called but from these 2
methods.
*
@@ -1017,8 +1014,8 @@
/**
* Creates a new path element with the given qualified name and index.
* If the name is equals to the name of a special element, like the
- * [EMAIL PROTECTED] PARENT_ELEMENT},[EMAIL PROTECTED]
CURRENT_ELEMENT} or the
- * [EMAIL PROTECTED] ROOT_ELEMENT}, then it's instance is returned.
+ * [EMAIL PROTECTED] #PARENT_ELEMENT},[EMAIL PROTECTED]
#CURRENT_ELEMENT} or the
+ * [EMAIL PROTECTED] #ROOT_ELEMENT}, then it's instance is returned.
* p/
* the private constructor must never be called but from these 2
methods.
*
@@ -1271,7 +1268,7 @@
* Returns false.
*
* @return false
- * @see PathElement#denotesName()
+ * @see Path.PathElement#denotesName()
*/
public boolean denotesName() {
return false;
@@ -1281,7 +1278,7 @@
* Returns true.
*
* @return true
- * @see PathElement#denotesRoot()
+ * @see Path.PathElement#denotesRoot()
*/
public boolean denotesRoot() {
return true;
@@ -1291,7 +1288,7 @@
* Returns false.
*
* @return false
- * @see PathElement#denotesParent()
+ * @see Path.PathElement#denotesParent()
*/
public boolean denotesParent() {
return false;
@@ -1301,7 +1298,7 @@
* Returns false.
*
* @return false
- * @see PathElement#denotesCurrent()
+ * @see Path.PathElement#denotesCurrent()
*/
public boolean denotesCurrent() {
return false;
@@ -1345,7 +1342,7 @@
* Returns false.
*
* @return false
- * @see PathElement#denotesName()
+ * @see Path.PathElement#denotesName()
*/
public boolean denotesName() {
return false;
@@ -1355,7 +1352,7 @@
* Returns false.
*
* @return false
- * @see PathElement#denotesRoot()
+ * @see Path.PathElement#denotesRoot()
*/
public boolean denotesRoot() {
return false;
@@ -1365,7 +1362,7 @@
* Returns false.
*
* @return false
- * @see PathElement#denotesParent()
+ * @see Path.PathElement#denotesParent()
*/
public boolean denotesParent() {
return false;
@@ -1375,7 +1372,7 @@
* Returns true.
*
* @return true
- * @see PathElement#denotesCurrent()
+ * @see Path.PathElement#denotesCurrent()
*/
public boolean denotesCurrent() {
return true;
@@ -1418,7 +1415,7 @@
* Returns false.
*
* @return false
- * @see PathElement#denotesName()
+ * @see Path.PathElement#denotesName()
*/
public boolean denotesName() {
return false;
@@ -1428,7 +1425,7 @@
* Returns false.
*
* @return false
- * @see PathElement#denotesRoot()
+ * @see Path.PathElement#denotesRoot()
Re: Patches for JavaDoc warnings
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 Javadoc fix, or should it be re-used when needed? Best regards, Julian
Re: [jira] Resolved: (JCR-523) QueryManagerImpl hardwires supported query languages
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!
org.apache.jackrabbit.test.api.TestAll against L1 repository?
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 here. Shouldn't the whole method only excute when isSupported(LEVEL2)? Or am I missing a parameter to set to keep the tests from trying to do the write accesses? Best regards, Julian
Re: package.html file found in the development tree
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 (== package level doc as described in http://java.sun.com/j2se/javadoc/writingdoccomments/index.html#packagecomments)? Best regards, Julian
Re: GetPropertyNamesTest.testGetPropertyNames
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 explicitly specify properties to select (in SQL this would be a 'select *') the properties of the node type specified by the type constraint are returned. in case of nt:base those properties are jcr:primaryType and jcr:mixinTypes. Yep. 2) It doesn't seem to me that the query specifies a type constraint, so why the check at all? this is because of the nt:base default described above. OK. 3) I thought support for jcr:score was optional??? It is kind of optional. If an implementation is not able to provide a jcr:score it can always return a dummy value. The spec says: As well, a score column will also be included, though it is not required that its contents always be meaningful. OK. I'll re-read the spec, and if I still think it needs clarification I'll open an issue. Thanks for the explanation. Best regards, Julian
Re: GetPropertyNamesTest.testGetPropertyNames
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. OK, I just re-read JSR170, Section 6.6.3.2 Type Constraint, and it doesn't mention a default constraint. On the other hand, I do agree that always having that constraint, and defaulting it to nt:base makes sense. However, I really think the specs needs to state this. Should I open a ticket? Best regards, Julian
Re: Dreamweaver to jackrabbit
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 jcr:isCheckedOut property, which are very vital for the versioning and checkin/checkout operations are not getting set on a node, while creating it and putting it in to the jackrabbit repository. -Basically these properties are set while saving a new node.But these are not set on initializing the DavResource properties.Why is this not getting initialized, On WebDAV request are these properties set? -Dreamweaver does not make a call directly to doCheckin() or the doCheckout() mathods.The request method is only PROPFIND, GET,LOCK, PUT, OPTIONS, MKCOL etc. How to make jackrabbit cater to the checkin/checkout operations with only the above mentioned request methods. Please keep in mind that what many clients call checkin/checkout has nothing to do with versioning. That is, it probably is the expected behaviour that new versioning happens at all. That being said, the interesting question is whether the client works (can it update the resource), and if it doesn't, how exactly it fails (that's where a complete HTTP trace would be useful). Best regards, Julian
SPI
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 I'm currently looking at. Many things are
obvious, but some or not... For instance, ItemId and friends confuse me...:
/**
* codeItemId/code...
*/
public interface ItemId {
public boolean denotesNode();
public String getUUID();
public Path getRelativePath();
}
Does this mean that any item needs to have both a unique ID, and a
relative path (relative to what...?).
Best regards, Julian
Re: SPI
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. Feel free to ask if anything is unclear. Great, thanks. So it's basically a correspondence identifier, right? Best regards, Julian
Re: New committer and PMC member
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, welcome to the team! Thanks, I'm looking forward to working on the code, and also to meet some of you next week. Best regards, Julian
SPI vs Session.logout
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 to forward the information that the Session isn't used anymore. On the other hand, the SPI implementation may want to free resources related to the SessionInfo, right? Am I missing something, or is this an oversight? Best regards, Julian
Re: SPI vs Session.logout
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 layer, and no SPI method is called to forward the information that the Session isn't used anymore. On the other hand, the SPI implementation may want to free resources related to the SessionInfo, right? Am I missing something, or is this an oversight? you don't miss anything, nor is it an oversight. it's simply an open issue and there are many opinions, that don't fit together. - initially the requirement was, that there is no (and never) a 'session' hold on the server-side (server in the broader sense). in this situation, both login and logout didn't make any sense, since they insinuate, that there might be some session hold below the SPI boundary. this was the very initial state, where no 'login' was present. Understood, and makes sense. - later on, some people claimed, that the 'SessionInfo' interface is lost in the SPI and that it should be define, how the SessionInfo is obtained. in this situation, we added the 'login' method (which is probably misnamed given the requirement). the current api reflects this state. - after that the login method has been a questioned in the first jsr283 f2f and later on, since people thought, that 'login' implies a stateful implementation. Of course it begs the question where logout is :-) - and currently there a multiple requests for a 'logout' method, in order to be able to keep some sort of Session identification on the 'server'. so... :)) since marcel and myself were busy with all kind of issues (mainly due to the id, that isn't an id any more), we didn't feel like fighting with opposed requirements and postponed the discussion (and a careful evaluation of all the pros and contras). Some thoughts: 1) an SPI implementation of course will need to know on whose behalf requests are made; so at the very least some kind of user identification is needed. We currently have that in SessionInfo. 2) In many cases, an SPI implementation will also need to authenticate, thus it will need credentials. That's also in SessionInfo. 3) In some cases, an SPI implementation will have to keep it's own sessions open communicating to it's backend (JDBC connections, for instance). Of course an SPI implementation can control their lifetime (for instance, implementing a pool), but knowing when a session for a particular user isn't needed anymore would be very useful in any case. So based on this I would recommend keeping SessionInfo, potentially rename login to something else (obtain?), and add a matching cleanup method (close)... Best regards, Julian
Re: SPI (jcr2spi) vs JDK 1.5
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 it to 1.5. It seems related to assertion (which is strange since as you said everybody know they were introduced in 1.4). I didn't investigate this issue any further but what I know is in Eclipse you need to enable Java 1.5 to be able to build the project. Actually, you don't need to switch Eclipse to 1.5. Just configure the Java compliance settings so that Generated .class compatibility and Source compatibility are set to 1.4 as well (which is not the default). I have had this questions a few times, this is why I brought it up when Julian asked about it. It is not a major issue, but can be annoying to new users and we should ease as most as possible their path I think. Best regards, Julian
SPI: usage of java.util.Properties in interfaces
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 Collections.unmodifiableMap()). Best regards, Julian
Re: SPI: usage of java.util.Properties in interfaces
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 anyway...). The current design makes it really hard to re-use an existing instance (what if somebody writes to it?) Best regards, Julian
SPI: question on QPropertyDefinition.getValueConstraints()/getDefaultValues()
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
SPI: level 2 support
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 org.apache.jackrabbit.jcr2spi.SessionImpl.checkSupportedOption(SessionImpl.java:829) at org.apache.jackrabbit.jcr2spi.SessionImpl.getValueFactory(SessionImpl.java:366) at org.apache.jackrabbit.jcr2spi.SessionImpl.init(SessionImpl.java:143) at org.apache.jackrabbit.jcr2spi.RepositoryImpl.login(RepositoryImpl.java:78) at org.apache.jackrabbit.jcr2spi.RepositoryImpl.login(RepositoryImpl.java:86) This is caused by the init code for SessionImpl which seems to require a ValueFactory. Is this by design (that is, do I need to support L2 in order to use jcr2spi), or a bug? Best regards, Julian
Re: SPI: usage of java.util.Properties in interfaces
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 Collections in one other place, so I really don't buy that one :-) Speaking of which, is there a particular reason why QNodeTypeDefinition.getDependencies returns a Collection, not a Set? 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 collection it prefers. That would work for me for this case. Best regards, Julian
Re: SPI: usage of java.util.Properties in interfaces
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 collection it prefers. How about remote clients that would prefer to get all the descriptors in one call? Good point. Please just make it a Map. Best regards, Julian
SPI: RepositoryService Interface vs Namespace Registry
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 something here...? Best regards, Julian
Re: SPI: RepositoryService Interface vs Namespace Registry
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 miss something here...? your original impression is correct. which specific method are you worried about containing a session local prefix mapping? Marcel, thanks a lot. I was reading things into the fact that the namespace related methods on RepositoryService take a SessionInfo parameter, so somehow I got to the conclusion that there's a relation to a JCR Session somewhere. Sorry for the confusion. Best regards, Julian
Re: SPI: ClassCastException in jcr2spi's NodeState
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. it's not finished yet and as long as i'm are still committing with 'work in progress' comments you can't even rely on the project to compile. Angela, thanks for the feedback. I do know that this is work-in-progress, and I didn't intend to criticize anybody. My understanding was that it's A good Thing for SPI if both the interfaces and the JCR2SPI layer are tested against other SPI implementations -- so that's what I'm doing. I fully intend to actually help with JCR2SPI once I start understanding things, and I think the best way to get there is to actually use it. So can I proceed by just commenting out that call; or are things more complicated than that? Best regards, Julian
SPI: ClassCastException in jcr2spi's NodeState
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...: java.lang.ClassCastException at org.apache.jackrabbit.jcr2spi.state.NodeState$ChildNodeEntries.get(NodeState.java:1509) at org.apache.jackrabbit.jcr2spi.state.NodeState$ChildNodeEntries.access$1(NodeState.java:1507) at org.apache.jackrabbit.jcr2spi.state.NodeState.assertAvailability(NodeState.java:196) at org.apache.jackrabbit.jcr2spi.state.NodeState.init(NodeState.java:131) at org.apache.jackrabbit.jcr2spi.state.WorkspaceItemStateFactory.createNodeState(WorkspaceItemStateFactory.java:155) at org.apache.jackrabbit.jcr2spi.state.WorkspaceItemStateFactory.createNodeState(WorkspaceItemStateFactory.java:121) at org.apache.jackrabbit.jcr2spi.state.entry.UUIDReference.doResolve(UUIDReference.java:83) at org.apache.jackrabbit.jcr2spi.state.entry.ChildItemReference.resolve(ChildItemReference.java:110) at org.apache.jackrabbit.jcr2spi.state.entry.ChildNodeReference.getNodeState(ChildNodeReference.java:120) at org.apache.jackrabbit.jcr2spi.state.WorkspaceItemStateFactory.createNodeState(WorkspaceItemStateFactory.java:99) at org.apache.jackrabbit.jcr2spi.state.CachingItemStateManager.resolve(CachingItemStateManager.java:168) at org.apache.jackrabbit.jcr2spi.state.CachingItemStateManager.getItemState(CachingItemStateManager.java:94) at org.apache.jackrabbit.jcr2spi.WorkspaceManager.getItemState(WorkspaceManager.java:328) at org.apache.jackrabbit.jcr2spi.state.TransientISFactory.createNodeState(TransientISFactory.java:145) at org.apache.jackrabbit.jcr2spi.state.entry.UUIDReference.doResolve(UUIDReference.java:83) at org.apache.jackrabbit.jcr2spi.state.entry.ChildItemReference.resolve(ChildItemReference.java:110) at org.apache.jackrabbit.jcr2spi.state.entry.ChildNodeReference.getNodeState(ChildNodeReference.java:120) at org.apache.jackrabbit.jcr2spi.ItemManagerImpl.hasChildNodes(ItemManagerImpl.java:205) at org.apache.jackrabbit.jcr2spi.NodeImpl.hasNodes(NodeImpl.java:634) This is because the code casts to LinkedEntries.LinkNode, but what the iterator returns is a UUIDReference. It seems to me that this can't be caused by my SPI doing something wrong; just probably different from what the other existing implementations do. Any idea what could be going on here? Best regards, Julian
Re: SPI: ClassCastException in jcr2spi's NodeState
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. it's not finished yet and as long as i'm are still committing with 'work in progress' comments you can't even rely on the project to compile. Angela, it seems that the recent changes in SPI have solved that problem for me. Thanks.
SPI: ValueFactory vs Level-1 implementations (part 2)
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 ValueFactory later on. This results in NullPointerExceptions once the ValueFactory is needed later, such as in at org.apache.jackrabbit.value.ValueFormat.getJCRValue(ValueFormat.java: 122) at org.apache.jackrabbit.jcr2spi.PropertyImpl.getValue(PropertyImpl.java :276) So maybe we should just state that for SPI, a Level-1 implementation *does* not to supply a ValueFactory, after all? The alternative probably would be to instantiate a simple ValueFactory internally, if the SPI implementation doesn't have one. Feedback appreciated... Best regards, Julian
Re: SPI: ValueFactory vs Level-1 implementations (part 2)
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 don't provide one in your config. Correct. am i missing something? No. angela btw: there is a simple ValueFactory in the jackrabbit-commons package. you may use this one or provide your own. Thanks for the pointer. Best regards, Julian
Re: SPI: ValueFactory vs Level-1 implementations (part 2)
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 always true. Would it make sense to lift that restriction? Best regards, Julian
Re: SPI: ValueFactory vs Level-1 implementations (part 2)
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 depends on the spi implementation what kind of ValueFactory it wants to use. and that was exactly the point, where i added the ValueFactory to the config together with the service. Understood and agreed. The SPI should provide it's own (and that's what I'm doing now...). Best regards, Julian
SPI: JIRA components
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
SPI: NPE in QValue.create
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 === java.lang.NullPointerException at org.apache.jackrabbit.value.QValue.create(QValue.java:135) at org.apache.jackrabbit.jcr2spi.nodetype.PropertyDefinitionImpl.getDefaultValues(PropertyDefinitionImpl.java:77)
Re: SPI: ItemInfo.getParentId()
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 of the versionable node to construct an intermediate structure to the version history of that node. the label of the version history node is the full uuid of the versionable node. Understood. For the record: in a previous project where we exposed version histories in the namespace we choose a similar approach. The trouble is that in the system I currently have I can't enumerate version histories *at all* (well, except by looking at every single node in the system and asking it for it's version history). can you at least search for version history uuids with a certain pattern? That would allow you to group your version histories in a sub node structure under jcr:versionStorage. But I guess when you say you can't enumerate them at all, that means it *is* impossible... Right. I don't have an API for that. I think that's indeed a specification issue. Can a client always rely on a node's ability to enumerate all children? well, according to the spec it can... I'd rephrase that slightly as the spec ignores the issue :-). JCR clients already have to deal with child nodes not showing up in the parent collection, for instance due to permission problems. I think requiring this makes many use cases extremely hard, if not impossible, to implement. what use cases do you have in mind? Well, this one for instance. Another one would be where the system exposes all referenceable nodes with a second path, consisting of a collection (/jcr:flat/) plus the UUID. That's an approach I've seen in use to provide users with an alternate, stable, identifier. The common pattern here is that the nodes exposed at a certain part of the namespace are just projections from somewhere else, and not something that is persisted under that name. Back in September, I claimed that implementing simple versioning was trivial, maybe I now have to take that back ;-) Best regards, Julian
SPI: question about ChildNodeEntries.replaceEntry (JCR2SPI)
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 my SPI implementation is
doing something wrong...?
Best regards, Julian
===
void replaceEntry(NodeState childState) {
// NOTE: test if child-state needs to get a new entry not
checked here.
try {
LinkedEntries.LinkNode ln = getLinkNode(childState);
ChildNodeEntry newCne =
ChildNodeReference.create(childState, nodeState.isf, nodeState.idFactory);
entries.replaceNode(ln, newCne);
} catch (NoSuchItemStateException e) {
log.error(Internal error., e);
}
}
Re: SPI: ItemInfo.getParentId()
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 parent node it will not
see the new child node entry in there for the node returned in the query.
...
I can resolve my original problem with the change below...:
---
src/main/java/org/apache/jackrabbit/jcr2spi/state/WorkspaceItemStateFactory.java
26 Oct 2006 12:20:08 - 1.2
+++
src/main/java/org/apache/jackrabbit/jcr2spi/state/WorkspaceItemStateFactory.java
3 Nov 2006 14:18:50 -
@@ -96,7 +96,8 @@
NodeState parent = (parentId != null) ? (NodeState)
ism.getItemState(parentId) : null;
if (parent != null) {
-return parent.getChildNodeEntry(info.getQName(),
info.getIndex()).getNodeState();
+ChildNodeEntry child =
parent.getChildNodeEntry(info.getQName(), info.getIndex());
+return child != null ? child.getNodeState() :
createNodeState(info, parent);
} else {
return createNodeState(info, parent);
}
...however once I do that - as expected - other problems surface.
Looking at JCR2SPIs NodeImpl and HierarchyManagerImpl it seems that the
only way to access a Node by absolute path is to recursively access all
parent nodes, visiting their children.
This seems to be not only inefficient, but may also cause a problem when
the given user doesn't have read access to all parent nodes...
Shouldn't we have something like:
NodeId RepositoryService.getNodeId(QPath path);
Best regards, Julian
Re: SPI: ItemInfo.getParentId()
(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, where the lower layers don't know about paths but the items just have forward and backward references (parent uuid, child node entries and property names). I'm not so sure if we should move this task to the server. I think in most cases a workspace is accessed in a traversal way. At least that's what most methods in the JCR are about. To get a node or a property you usually start from a node you accessed before. But you are right that this design will cause problems when there are ancestor nodes that cannot be accessed. It will also cause problems when collections are really, really big. in the meantime I realized that the IdFactory can do that for me, assuming it allows .createNodeId((NodeId)null, path); ...where path would be absolute -- which the one in spi2dav doesn't (why?). (As a matter of fact a createNodeId(Path) signature would be useful). the method createNodeId(NodeId, Path) is meant for ids that are relative to an existing id. createNodeId(String, Path) is what you are looking for. here, the String uuid parameter is optional. OK, thanks, works for me. So given the fact that the SPI API at least in theory has the capability to do the lookup without having to access the parent collections, shouldn't JCR2SPI use that when circumstances require that? 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 some cases they can be very volatile. think of same name siblings and parent nodes that become referenceable. Well, the current design doesn't work for my current back end; and even if I *could* change the back end, looking up nodes that have many children will still be very expensive. Does it make sense that I start trying to change JCR2SPI with respect to this? Best regards, Julian
(potential) contrib: node type graphing tool
...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 somewhere, possible in or close to jackrabbit-ntdoc? If so, are there guidelines how to organize something that isn't Java code at all (just one XSLT, potentially with instructions and examples)? Best regards, Julian
SPI: ClassCastException in JCR2SPI NodeImpl.
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
Re: SPI: ClassCastException in JCR2SPI NodeImpl.
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
Re: SPI: ItemInfo.getParentId()
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 some cases they can be very volatile. think of same name siblings and parent nodes that become referenceable. another issue with a non-hierarchical caching structure is the way how a save on an item is specified. if you have multiple disconnected item sub-tree fragments (which contain modified items) it will be impossible to find out whether one of the sub-trees is included in a save call. even though I'd also be in favor of only reading what is really necessary, this constraint seems to even demand that an implementation resolves the ancestor hierarchy. I understand the problem in general, but it certainly doesn't apply for the specific use case I have (having the contents of jcr:versionStorage not being enumerable). It seems to me that -- independantly of SPI -- we need to discuss whether this is legal behavior for JCR implementations. If it is, we need to define how this works with saving changes in general, and the transient layer in JCR2SPI in particular. If it isn't, that should be spelled out as well, because it may affect other implementors as well. In general, I think the assumption that if a user has read access to /a/b/c necessarily means (s)he also has access to /a and /a/b is flawed. Best regards, Julian
SPI: PropertyDefinition.getRequiredType
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, doesn't expose them at all; instead it reports residual properties of type UNDEFINED. In my JCR implementation, when I instantiate a Property and it's PropertyDefinition, I do look up the actual type, thus getRequiredType() does not return UNDEFINED. In JCR2SPI, this doesn't happen, as QNodeTypeDefinition doesn't have a call for that, and - similarly to other SPI aspects - JCR2SPI assumes that it has complete knowledge about the node type system. The result being that JCR2SPI's PropertyDefinition.getRequiredType() returns UNDEFINED. I'm not sure whether this is worth spending any work on, but I thought it wouldn't hurt to report it. Best regards, Julian
Re: SPI: PropertyDefinition.getRequiredType
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, BOOLEAN or UNDEFINED. OK. - If PropertyDefinition.getRequiredType() is UNDEFINED, then a Property having this definition may be of any type. OK. - The value of a property may never be UNDEFINED. Thus, Property.getType() will never return UNDEFINED. OK. - Node.setProperty: If the node type of this node does not indicate a specific property type, then the property type of the supplied Value object is used and if the property already exists (has previously been set) it assumes both the new value and new property type. Yes. if you want to point out, that the NodeTypeRegistry doesn't get informed about new registrations: that's a known issue (see TODO.txt) and covered by the jira issue, you created recently. 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 be very large), while Property.getPropertyDefinition() will return a non-residual definition (because in this case, the property name is known in advance, so the size problem above doesn't matter). I understand this is not the case for Jackrabbit, but for other stores, it may happen. What I'm trying to understand is whether this is a hole in SPI or not. Keep in mind that there are document management systems where the set of property types really is open-ended, such as in a generic WebDAV server. Best regards, Julian
Re: SPI: PropertyDefinition.getRequiredType
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 be very large), while Property.getPropertyDefinition() will return a non-residual definition (because in this case, the property name is known in advance, so the size problem above doesn't matter). Are you sure this is OK? At least it breaks the following symmetry: That's what I'm trying to find out... PropertyDefinition definition = property.getDefinition(); NodeType type = definition.getDeclaringNodeType(); assert Arrays.asList(type.getDeclaredPropertyDefinitions()).contains(definition); Question here is whether that symmetry is guaranteed (maybe JSR-283 can clarify that), and whether breaking the symmetry provides any useful additional information to the client... I would return the residual node definition from Property.getDefinition() unless the underlying more specific definition has been explicitly exposed through the NodeType API. Best regards, Julian
Re: Jackrabbit and Maven
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 builds, but since we're upgrading to Maven 2 in any case and since Maven 1 has been quite troublesome recently (the repository issue I mailed about on Friday seems to have reappeared, and I'm getting no quick help from [EMAIL PROTECTED]), I'd like to propose simply dropping Maven 1 and using Maven 2 for the main builds in trunk. Note that there are still quite a few contrib projects with just Maven 1 builds. I think we can upgrade them incrementally as time goes by. To make a mix of Maven 1 and Maven 2 projects work better, I enabled the install-maven-one-repository goal of the maven-one plugin in the Jackrabbit parent POM for Maven 2. This will make all artifacts installed to the local Maven 2 repository to automatically get installed also in the local Maven 1 repository. Jukka, thanks for all the hard work you did over the weekend (and the time to prepare for that before). Could you please confirm: with the new layout, Jackrabbit builds with Maven 2, except for some contrib components? Best regards, Julian
SPI: repositoryService.isGranted()
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), the ItemId may refer to an item that doesn't exist (yet),
so it's impossible for the transient layer to decide whether to produce
a NodeId or an ItemId.
Now in some case (such as when actions is {add_node}), the transient
layer could make an assumption about the type of the id based on the
action to be checked. However, this will get ugly when several actions
are checked in a single method call.
Thus, wouldn't it make sense to change the method signature to
public boolean isGranted(SessionInfo sessionInfo, Path absPath,
String[] actions) throws RepositoryException;
instead?
Best regards, Julian
Re: General Packaging mechanism
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 the content in jcr. a content archive (.car) will: ... Hi Tobias, you may want to avoid confusion with SAPCAR, which uses the same extension (http://www.easymarketplace.de/SAPCAR.php). Best regards, Julian
Re: General Packaging mechanism
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. Therefore, the internal structure of the compressed files slightly changed. Because of this, it was necessary to create a new extension. There the new extension .SAR was born and the new utility was named SAPCAR. however, finding a suitable, not used extension is almost impossible (http://filext.com/detaillist.php?extdetail=carSearch=Search). using .car seemed to be to most obvious and least known in the j2ee/java world. Point taken, but maybe it may make sense to consider to longer extensions, such as jcrcar. 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? Best regards, Julian
Re: General Packaging mechanism
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 %u. actually i haven't looked at how non-ascii characters are handled in a jar file, but obviously it works, since i can include such a file in a jar file: ... My understanding is that the JAR/ZIP format is silent on filename encoding. So a producer if these files will have to select an encoding, and the recipient need to select the same one. In general, this is not going to work unless everybody agrees to use UTF-8. [EMAIL PROTECTED] test]$ touch 到日本来.txt [EMAIL PROTECTED] test]$ ll total 0 -rw-rw-r-- 1 tripod tripod 0 Feb 21 14:44 到日本来.txt [EMAIL PROTECTED] test]$ cd .. [EMAIL PROTECTED] jcr-car]$ jar cvf test.jar test/ added manifest adding: test/(in = 0) (out= 0)(stored 0%) adding: test/到日本来.txt(in = 0) (out= 0)(stored 0%) [EMAIL PROTECTED] jcr-car]$ jar tf test.jar META-INF/ META-INF/MANIFEST.MF test/ test/到日本来.txt I think it's using the platform encoding, and you happened to try a character (can't tell from your mail) that can be represented in that encoding. Try a mix of special character (Euro sign, Hebrew, Arabic) in one filename, and retry :-) Best regards, Julian (P.S.: we had trouble using ZIP as a content container format two years ago for the reasons above; maybe the situation has improved but I really doubt that)
SPI: local vs remote checking
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 ItemStateValidator.isWritable()). This indeed works (in that the client sees a compliant JCR impl), but this still left me wondering whether this really is a good approach: (1) First of all, it leaves the question open whether an SPI implementation actually needs to implement the locking semantics, or whether *persisting* and *returning* the lock information is sufficient. In any case, this should be documented well. (2) It seems to me that we're doing more roundtrips to the server than necessary. This is likely to cause performance degradation for write operations to remote servers. Maybe this is something that the transient layer only does optionally, based on what the SPI server recommends? (There are other local checks (such as access and check-out state) here as well, but maybe we can focus on one aspect at a time...) Best regards, Julian
Re: Escaping node names in xpath queries
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 tried uri encoding the name, which replaces the space with %20, but that gives us this error: javax.jcr.query.InvalidQueryException: Lexical error at line 1, column 110. Encountered: 2 (50), after : %: Lexical error at line 1, column 110. Encountered: 2 (50), after : %: Lexical error at line 1, column 110. Encountered: 2 (50), after : % Is there a way to get around this? XPath goes against the document view of the repository, thus you have escape names using the rules in JSR 170, Section 6.4.3. For instance, a space character would become _x0020_. Best regards, Julian
Session.impersonate vs Credentials
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 credentials. JSR-170 however doesn't mention anything about that. So...: - is this just plainly unimportant? (such as in nobody uses impersonate anyway, it's simple enough to do a regular login) - is this a TODO? (the code in JCR2SPI's SessionImpl seems to indicate that...) - if it is, should we define an extension to SimpleCredentials that can hold the required information, so that we don't rely on a specific impl class? Best regards, Julian
Re: poll on jcr query usage
[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.
Build failure (one test case)
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 org.apache.jackrabbit.core.nodetype.compact.TestAll Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.094 sec Running org.apache.jackrabbit.test.TestAll Tests run: 1055, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 65.453 sec FAILURE! Is this a known issue? If not, how can I find out what test case is failing? (mvn -e doesn't seem to give me the information I'm looking for). Best regards, Julian
Re: Build failure (one test case)
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 so it didn't warn us. I'll fix the Continuum issue. ... Thanks. I broke the test case, I'll fix it. Sorry.
Another TCK build issue... (JDK vs XSLT?)
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: 0, Errors: 56, Time elapsed: 52,813 sec testExportSysView_stream_session_skipBinary_recurse(org.apache.jackrabbit.test.api.ExportSysViewTest) Time elapsed: 0 sec ERROR! [ stdout ] --- [ stderr ] --- [ stacktrace ] --- javax.xml.transform.TransformerFactoryConfigurationError: Provider org.apache.xalan.processor.TransformerFactoryImpl not found at javax.xml.transform.TransformerFactory.newInstance(Unknown Source) at org.apache.jackrabbit.core.SessionImpl.exportSystemView(SessionImpl.java:1194) at org.apache.jackrabbit.test.api.ExportSysViewTest.doTestWithStream(ExportSysViewTest.java:137) at org.apache.jackrabbit.test.api.ExportSysViewTest.testExportSysView_stream_session_skipBinary_recurse(ExportSysViewTest.java:96) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) +++ Some more investigation seems to show that mvn invokes junit's java through the system path, and if *that* Java is 1.5, I'm getting the error above. However, when I change things so that Java 1.4 should be invoked, the error warps into: +++ Tests run: 1055, Failures: 0, Errors: 56, Time elapsed: 59,094 sec testExportSysView_stream_session_skipBinary_recurse(org.apache.jackrabbit.test.api.ExportSysViewTest) Time elapsed: 0 sec ERROR! [ stdout ] --- [ stderr ] --- [ stacktrace ] --- java.lang.ClassCastException at javax.xml.transform.TransformerFactory.newInstance(Unknown Source) at org.apache.jackrabbit.core.SessionImpl.exportSystemView(SessionImpl.java:1194) at org.apache.jackrabbit.test.api.ExportSysViewTest.doTestWithStream(ExportSysViewTest.java:137) +++ ...which of course doesn't help a lot. Oh my. It's nice that things work on one machine, but I'd really really like to understand what happens here, and how to fix it. Any kind of help appreciated. Julian
Re: [VOTE] Accept JCR Mapping from Graffito
Jukka Zitting schrieb: [ ] +1 Accept JCR Mapping from Graffito [ ] -1 Do not accept the component because ... +1
Re: NGP: Value records
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. Duplicate values are only stored once in a single value record. This saves space especially when storing multiple copies of large binary documents and allows value equality comparisons based on just the identifiers. ...and gives you a cheap strong ETag for binary content. A value record would essentially be an array of bytes as defined in Value.getStream(). In other words the integer value 123 and the string value 123 would both be stored in the same value record. More specific typing information would be indicated in the property record that refers to that value. For example an integer property and a string property could both point to the same value record, but have different property types that indicate the default interpretation of the value. This is possible, but does it really help in the real world? Thus I'd see that just as a nice-to-have, and be prepared to take it out if it makes things harder in practice... ... Best regards, Julian
SPI F2F?
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, - versioning of the SPI with respect to future JSR-283 extensions, - whether and how to integrate SPI internally into jackrabbit-core, ...and so on. Questions: (1) do people feel this is a good idea at all? (2) what else should be on the agenda? (3) preferences for time and location? Feedback appreciated, Julian
Re: jackrabbit-core maven build failure
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 error that is logged to system out by the parser itself. jackrabbit cannot control this. Hm. Sounds like we need to raise a bug report with Sun, right? Best regards, Julian
Re: XPath versus SQL in Jackrabbit
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 translation between XPath or SQL or vice versa? Best regards, Julian
Newbie Maven question
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 regards, Julian
Re: Newbie Maven question
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 are hosted by this repository: http://people.apache.org/repo/m2-snapshot-repository/ But in this repository there is no 1.1-SNAPSHOT version. Since the reason for using a SNAPSHOT version is most likely to become aware of integration problems early it makes almost no sense to use 1.1-SNAPSHOT here. I would use either a stable version like 1.1, 1.2, 1.3 or use the current snapshot which is 1.4-SNAPSHOT. ... Understood. So these contrib projects probably just need to be updated to require 1.4-SNAPSHOT, right? Best regards, Julian
JIRA broken?
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
JCR-1031 (RowIteratorImpl should make use of QueryResultRow.getValues())
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
Re: [jira] Commented: (JCR-388) add support for RFC 3253 to the simple server
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 collections. I'm not completely sure what the issue is? A version controlled collection is a specific type of a regular version controlled resource, it just also records information about version controlled children... what i meant: http://www.webdav.org/deltav/protocol/rfc3253.html#version-controlled-collection.feature states the following: As with any versionable resource, when a collection is put under version control, a version history resource is created to contain versions for that version-controlled collection. In order to preserve standard versioning semantics (a version of a collection should not be modifiable), a collection version only records information about the version-controlled bindings of that collection. In order to cleanly separate a modification to the namespace from a modification to content or dead properties, a version of a collection has no members, but instead records in its DAV:version-controlled-binding-set property the binding name and version history resource of each version-controlled internal member of that collection. [...] A version-controlled collection has all the properties of a collection and of a version-controlled resource. In addition, the version-controlled-collection feature introduces the following REQUIRED property for a version-controlled collection. 14.1.1 DAV:eclipsed-set (computed) [...] Clarifying: the difference between a collection and a non-collection with respect to WebDAV versioning is that the version-controlled state of a collection *additionally* includes the binding-set (for the members), but not the members itself. however: the patch provided by jeremi and modified by rob does not distinguish between collections and non-collection resources. in both cases the underlying repository Node is made 'versionable'. consequently both collections and non-collections behave the same way (i.e. like version-controlled resources), which is from my understanding not what the RFC defines. see quote above. do i miss something? Hm, probably I'm partly confused because I've grown up with RFC3253 semantics, and haven't used collection versioning in JCR so far (the system I currently work on only can version leaf files + properties). It seems the counterpart of a version controlled collection in WebDAV would be a JCR node where all children have OnParentVersionAction=IGNORE, meaning they are always version-controlled independently of the parent. I'm not sure whether anything else can be exposed in a RCF3253 compliant way. We may have to ask Geoff for advice :-). Best regards, Julian
Re: [jira] Commented: (JCR-388) add support for RFC 3253 to the simple server
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, because it could also be cause of the VCR being removed, while versioning information was preserved. Best regards, Julian
Re: Jira troubles
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 size of query results, which should restore things back to normal. Maybe http://wiki.eclipse.org/Mylyn_Jira_Connector? Best regards, Julian
Re: Jira troubles
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 is upgrading Jira in a short while and will then be able to explicitly limit the size of query results, which should restore things back to normal. Maybe http://wiki.eclipse.org/Mylyn_Jira_Connector? Could be, especially now that myriads of people are getting introduced to Mylar/Mylyn thanks to Eclipse Europa... Hm, still can't create new issues. Is this: -- Create Issue Step 2 of 2: Enter the details of the issue... Errors * Error instantiating webwork.multipart.parser.class: com.atlassian.jira.web.JiraMultipartRequestWrapper(original message: null) You have not selected a valid project to create an issue in. -- the same problem others are seeing? Best regards, Julian
Re: [VOTE] Release Apache Jackrabbit 1.3.1
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 the release will have to wait a while (unless someone wants to take over managing the release). I have downloaded the 1.3.1 source, *not* checked the hashes (instructions?), but built and tested OK (Win XP, JDK 1.5). If this is sufficient for a vote, here it is: +1 Best regards, Julian
Re: [VOTE] Release Apache Jackrabbit 1.3.1
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 remember trying to test it and being unable to vote because of the failure (and not enough time to investigate it). Since nobody else has seen it, I just assume it is a local setup issue with maven. I just saw the same problem with trunk and JCR2SPI, in testing my SPI implementation. It seems it's triggered by the presence of pre-JDK-1.5 XML jars (Xerces, Xalan...). So no, it's nothing specific to the 1.3.1 release. Best regards, Julian
Re: Jira troubles
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 strangely. The latest news on infrastructure@ is that the Jira installation should get upgraded tomorrow, after which things will hopefully return to normal. I just noticed that others have been successfully creating new issues, so I investigated further. 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. Best regards, Julian
Re: Jira troubles
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 and Jira, see https://issues.apache.org/jira/browse/INFRA-1285 Recent Firefox builds send a Content-Type header with each multipart/form-data part, this might break a few webapps out there. Bertrand, thanks for the pointers. At least now I understand what's going on :-). Best regards, Julian
Continuum vs build failures
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 now fail are incorrect, but either way, this really should be resolved so that other developers do not have to spend time figuring out what's wrong. In doubt, back out the change that causes the test case failure until the problem is understood and fixed. 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. Finally, maybe it would be good if Continuum would send out emails to this list when builds break. Jukka, would that be feasible? Best regards, Julian
Re: Continuum vs build failures
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 XML-import (unbound prefix). if i remember correctly, this is caused by the xalan.jar shipped with jdk 1.4. has the configuration changed? otherwise i would expect that the build had never succeeded. It seems that the build started to fail once the test cases have been enabled :-) So I guess we need to decide whether we want the tests to work with JDK 1.4. If we do, we'll have to fix them so that they work with Xalan's serializer as well. Best regards, Julian
Re: JCR 2.0 extensions
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
Re: JCR 2.0 extensions
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 backwards compatible this shouldn't be a problem. Yep. In case we do ran up with compatibility issues, I think we have a good case to request a change in JSR 283. As far as I recall, we have at least one method signature that changed with respect to throwing exceptions... Or do you want to start a whole new branch where all jsr170 interfaces are replaced by jsr283 interfaces? We need to do that eventually, but I'd very much like to push the branch point as far ahead as possible to avoid getting stuck with two parallel actively developed codebases. Ideally we'd release 1.4 and perhaps even 1.5 with early JCR 2.0 features included before dropping JCR 1.0 from svn trunk and focusing on the real JCR 2.0 interfaces for the Jackrabbit 2.0 release. +1 Best regards, Julian
Re: master plan for jsr 283 query implementation
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 - JCR-SQL2, the new SQL query syntax - additional query features (joins, etc.) In a first step I already introduced temporary interfaces for the JQOM and implementing classes. I'd like to keep the current design of the query sub system for a while until we are ready to switch to the new JQOM as the basis for syntax independent query representation. That is, in a first phase my suggestion is the following: XPath---+ +---AQT+ SQL-+ +LuceneQuery | SQL2---JQOM+ AQT: abstract query tree And once the path SQL2-JQOM-LuceneQuery is stable: XPath---+ AQT (deprecated) | SQL-+JQOM-LuceneQuery | SQL2+ Comments and suggestions are welcome. +1. Sounds reasonable. Do you want to use javacc for SQL2 parsing? Looks good to me as well (sorry, somehow missed the original post). Best regards, Julian
Re: Synchronized methods in ItemManager
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 in general doesn't. So an application taking advantage of that may break on different JCR implementations. Finally, how does that translate to JCR2SPI and the SPI interfaces? It seems we need to clarify the thread-safety of spi.RepositoryService and spi.SessionInfo... ... Best regards, Julian
Re: Synchronized methods in ItemManager
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' is the wrong term. whenever these kind of questions arise on the mailing list, we tell people that reading from multiple thread is probably safe, while writing is not. searching the mail archive should give you some of those statements. I see. Note that you now said is probably safe :-) Finally, how does that translate to JCR2SPI and the SPI interfaces? It seems we need to clarify the thread-safety of spi.RepositoryService and spi.SessionInfo... I agree, we should definitively do that. Again, I think jcr2spi should be entirely thread safe for any kind of operation, while the SPI level is IMO debatable, because it is at a lower level. FWIW, we should make up our minds what we want to agree, and clearly document that. I don't care a lot about what we say, but I'm not convinced that guaranteeing more than JSR-170 says would be good for interoperability of clients. Best regards, Julian
Re: Jackrabbit 1.3.2 and 1.4 release planning
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 issues targeted for the release, so it might well be a few more months before the release is ready. In any case I'd very much like to push the release out during Q4 this year. ... Sounds good to me. In particular, I think that once JCR2SPI has been integrated as a top-level project, we should try to work on reducing code duplication between it and the monolithic Jackrabbit. BR, Julian
Re: [jira] Created: (JCR-1150) JCR2SPI: several performance improvements pointed out by Findbugs
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. But what you could do is:
Oops. Thanks for pointing this out. Will fix.
public class ObjectUtils {
public static Integer getInteger(int x) {
return new Integer(x); // NOPMD
}
}
Then change the code so this method is called instead of creating
Integer objects directly. Then if we switch to JDK 1.5, of if we want
to build our own cache, we have to change it only there.
makes inefficient use of keySet iterator instead of entrySet iterator
This should be changed if possible.
Best regards, Julian
Re: [VOTE] Release Apache Jackrabbit 1.3.3
+1 Builds and passes tests with Java 1.5.0 on Win XP. BR, Julian
Re: Moving contrib outside trunk and rename to sandbox
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 not parts of Jackrabbit releases I'd like to move the contrib folder one level up, outside jackrabbit/trunk. At the same time I'd like to rename the contrib folder to sandbox to better suggest that it's not just a static placeholder for code contributions, but an area where committers (and contributors) can play with new ideas without impacting Jackrabbit trunk. WDYT? Sounds good to me. BR, Julian
SPI observation: EventFilter lifecycle
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 for EventFilter array being null. These changes will allow the SPI implementation to early filter internal events, even before getEvents() gets called. Question: do we expect many cases in which a client stops listening for events, but keeps the JCR session open? In this case it might be good if we could indicate that an EventFilter is not going to be used anymore, for instance using a dispose() method. Best regards, Julian
Re: SPI observation: EventFilter lifecycle
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 object into getEvents(), and EventFilters are attached to the subscription? Works for me. Go ahead! Best regards, Julian
Re: SPI observation: EventFilter lifecycle
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 implementation can deserialize foreign EventFilters. That's already part of the Javadoc. The change I want to make is that it's also bound to a specific SessionInfo. Proposal: remove special case in getEvents for EventFilter array being null. +1 One can achieve the same result using a catchall EventFilter. And it seems JCR2SPI is doing that already. These changes will allow the SPI implementation to early filter internal events, even before getEvents() gets called. Nice. Question: do we expect many cases in which a client stops listening for events, but keeps the JCR session open? In this case it might be good if we could indicate that an EventFilter is not going to be used anymore, for instance using a dispose() method. I guess that's a relatively rare use case, so I'd just ignore it for simplicity. BR, Jukka Zitting Thanks for the feedback, Julian
Re: regarding method SEARCH in webdav client
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 details... 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). ... BR, Julian
Re: regarding method SEARCH in webdav client
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? Do you think an implementation is possible if you get access to the underlying index? Just listing some: - two-valued vs three-valued boolean logic - differences in system properties and node typing - scoping (depth 1) ...I was implementing the opposite direction (Jackrabbit query model - basicsearch), so what was hard in this direction may not be hard in the other one...
JCR2SPI broken
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
failing tests
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 longer we let the tests fail, the worse the situation will become (the broken window problem). In particular, I see failures in: testRestoreName(org.apache.jackrabbit.test.api.version.RestoreTest) testRemoveLabel(org.apache.jackrabbit.jcr2spi.version.LabelTest) testRevertReorderToEnd(org.apache.jackrabbit.jcr2spi.ReorderReferenceableSNSTest) So... - is anybody looking at these? - do we have JIRA issues (except JCR-1293 which seems to be something different)? BR, Julian
Modularize Jackrabbit query parser?
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, JCR2SPI-based server). As a matter of fact, around a year ago when the EG discussed the topic of query syntaxes, the way Jackrabbit handles queries was mentioned repeatedly as proof that supporting two different query syntaxes is not a big deal, as long as they can be parsed into a single internal representation. Therefore I'd suggest to either - move the query parser into a separate top-level project (with a dependency on jackrabbit-spi-commons), or to - move it into jackrabbit-spi-commons. On the other hand, I can think of a few reasons for not doing that now, such as: - with the work on the JCR 2.0 RI, query is a moving target, and - exposing the internal query tree as a public API may be problematic. Feedback appreciated, Julian
