Re: Smaller and Quicker Releases
Hi Roland, Am Samstag, den 19.01.2008, 21:23 +0100 schrieb Roland Weber: Hi Felix, * jackrabbit-classloader: There isn't much work going on here, apart from bugfixing. So there will be no reasons for new releases ! Even bug fixes need to be released. Are you suggesting we just drop the component? Definitely not, there will be bugfixes and we will not drop this. But we should certainly not raise the version number and create new releases just for fun. I would say the classloader component is largely in maintenance mode at the moment. [...] Again: No changes, no release, no management. Therefore we should strive for this separation. I don't quite understand how you would want to handle these no release components. By no release I mean, that there no mvn release call is done with the consequence of raising the version number, tagging etc. Of course we still distribute these components. Just depend on the released 1.4 version and delete the code from trunk? Or move them to a separate component in the trunk already? Of course, each component in Jackrabbit should always depend on a released version of any other component, be it external or internal to Jackrabbit, with the exception of dependencies on functionality added after the release. For example: Consider jackrabbit-core and jackrabbit-api: As long as there is no change in jackrabbit-api, jackrabbit-core 1.5-SNAPSHOT still depends on jackrabbit-api 1.4. After an addition to jackrabbit-api, which is used by jackrabbit-core, the latter will be modified to depend on jackrabbit-api 1.5-SNAPSHOT. But of course, everything we are still working on remains in trunk. The latter requires a new component build process, hence effort. Definitely is this required ! Currently it looks like Jukka is just doing a mvn release on the jackrabbit branch root, thus incrementing versions, tagging and packaging each component (aka module) refereced in the root pom.xml. What I envision is, that the mvn release is called on each module separately as appropriate and required. This also requires that we split the root pom.xml into two (as is also done in Apache Felix and Apache Sling and works quite well): One aggregator pom.xml at the root, which just contains the module references and a separate real parent pom.xml in its own subfolder. Where should issues be reported? To the JIRA for the main cluster, where there is still a JIRA component for the spun-off code? Or create the new JIRA project right away? That would imply effort again, at least at Infra. And if you don't do the preparations right away, you'll face a steep hill to climb if there is need for a new release. Not sure, whether this is really required right away. I think, the problem with JIRA is somewhat overstated. I don't think, that it is this problematic. We may well keep the current single-project setup but we will have to more intensly manage the version numbers. A reasonable approach seems to be to start with the undisputed components (JCRAPI, JCRSPI, JCRRMI) and learn by doing how much effort it is. Additional projects can always be spun off from the main cluster later. +1 Regards Felix
[jira] Commented: (JCR-1196) Optimize queries for DescendantSelfAxisWeight/ChildAxisQuery
[ https://issues.apache.org/jira/browse/JCR-1196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12560945#action_12560945 ] Ard Schrijvers commented on JCR-1196: - The above numbers are done with Jackrabbit trunk or 1.4 or an older version? In JCR-1213 we fixed the caching issue regarding DescendantSelfAxisWeight/ChildAxisQuery . Obviously, the caching is only measurable in consecutive calls. So perhaps Martin Zdila could do a new test with Jackrabbit 1.4, and specifically look at the time used for consecutive calls. That the first call takes longer we are aware of (though one single slower query at startup is perhaps acceptable). Shouldn't we close this issue since JCR-1213 is fixed and create a new one 'first execution for queries for DescendantSelfAxisWeight/ChildAxisQuery are slow when the number of hits is large and the parent nodes are divided over many different lucene indexes'. We largely resolved this issue by fixing the cache IMO. WDOT? Optimize queries for DescendantSelfAxisWeight/ChildAxisQuery Key: JCR-1196 URL: https://issues.apache.org/jira/browse/JCR-1196 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-core, query Reporter: Ard Schrijvers A query like /documents/en/news//[EMAIL PROTECTED] order by @modificationDate when there are many nodes ( 1.000) in /documents/en/news becomes very slow. I think the bottleneck is in something like recursive filters in lucene. First off all I'll try to find some stastistics about the performance, and describe the bottleneck. After that, a solution must be found, where we need to keep in mind that 1) these queries run faster and scale better (obviously) 2) moving a node must stay a cheap operation Also see: http://www.nabble.com/Search-performance--%3A-MultiIndex-tf4695559.html#a13421949 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1196) Optimize queries for DescendantSelfAxisWeight/ChildAxisQuery
[ https://issues.apache.org/jira/browse/JCR-1196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12560946#action_12560946 ] Martin Zdila commented on JCR-1196: --- I used Jackrabbit 1.4 and only consecutive calls for above tests. I can do other tests if you tell me so. Optimize queries for DescendantSelfAxisWeight/ChildAxisQuery Key: JCR-1196 URL: https://issues.apache.org/jira/browse/JCR-1196 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-core, query Reporter: Ard Schrijvers A query like /documents/en/news//[EMAIL PROTECTED] order by @modificationDate when there are many nodes ( 1.000) in /documents/en/news becomes very slow. I think the bottleneck is in something like recursive filters in lucene. First off all I'll try to find some stastistics about the performance, and describe the bottleneck. After that, a solution must be found, where we need to keep in mind that 1) these queries run faster and scale better (obviously) 2) moving a node must stay a cheap operation Also see: http://www.nabble.com/Search-performance--%3A-MultiIndex-tf4695559.html#a13421949 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1305) JNDI data sources with BundleDbPersistenceManager: UnsupportedOperationException
[ https://issues.apache.org/jira/browse/JCR-1305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting updated JCR-1305: --- Affects Version/s: 1.4 Fix Version/s: 1.4.1 Issue Type: Bug (was: Improvement) Yes, that would be nice. I recategorized this as a bug (incorrect use of DataSource) and tagged for 1.4.1. JNDI data sources with BundleDbPersistenceManager: UnsupportedOperationException Key: JCR-1305 URL: https://issues.apache.org/jira/browse/JCR-1305 Project: Jackrabbit Issue Type: Bug Components: jackrabbit-core Affects Versions: 1.4 Reporter: Thomas Mueller Assignee: Thomas Mueller Priority: Minor Fix For: 1.4.1 When using the org.apache.tomcat.dbcp.dbcp.BasicDataSourceFactory, the BundleDbPersistenceManager can not open a database connection via JNDI because the method DataSource.getConnection(user, password) is not supported. Instead, DataSource.getConnection() must be used for this to work. ConnectionFactory.getConnection should be changed to call this method if user name and password are empty. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Why has the Locked class moved to the spi-commons?
Hi, after updating to jackrabbit 1.4 I noticed that the Locked class has moved from the jcr-commons to the spi-commons package. Now, this may be a dumb question, but why this move? The Locked class has been a utility class which was usable with any jcr implementation as no jackrabbit specific code is required. Now I need dependencies to jackrabbit spi just in order to use this simple class :( Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
[jira] Resolved: (JCR-1305) JNDI data sources with BundleDbPersistenceManager: UnsupportedOperationException
[ https://issues.apache.org/jira/browse/JCR-1305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller resolved JCR-1305. - Resolution: Fixed Fixed in revision 613799 (trunk). Should I commit this change to 1.4 branch as well? I think yes. JNDI data sources with BundleDbPersistenceManager: UnsupportedOperationException Key: JCR-1305 URL: https://issues.apache.org/jira/browse/JCR-1305 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-core Reporter: Thomas Mueller Assignee: Thomas Mueller Priority: Minor When using the org.apache.tomcat.dbcp.dbcp.BasicDataSourceFactory, the BundleDbPersistenceManager can not open a database connection via JNDI because the method DataSource.getConnection(user, password) is not supported. Instead, DataSource.getConnection() must be used for this to work. ConnectionFactory.getConnection should be changed to call this method if user name and password are empty. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Why has the Locked class moved to the spi-commons?
Hi, On Jan 21, 2008 10:36 AM, Carsten Ziegeler [EMAIL PROTECTED] wrote: after updating to jackrabbit 1.4 I noticed that the Locked class has moved from the jcr-commons to the spi-commons package. Now, this may be a dumb question, but why this move? The Locked class has been a utility class which was usable with any jcr implementation as no jackrabbit specific code is required. Now I need dependencies to jackrabbit spi just in order to use this simple class :( Good point. AFAIK the main reason for the move are the five imports to name handling classes in spi-commons. We don't want to make jcr-commons depend on spi-commons and so once the name classes were moved, Locked had to follow. However, looking at the code in more detail, the only use for the name handling classes is to calculate the prefixed name of mix:lockable (it can't be hardcoded as mix: could be remapped). We could remove the dependency fairly easily with a Session.getNamespacePrefix() call. Luckily, to avoid breaking existing clients, we just deprecated the Locked class in jcr-commons instead of removing it. I guess the proper solution is then to file a bug about improper deprecation and we'll drop the @deprecated mark along with the spi-commons dependency in the 1.4.1 release. BR, Jukka Zitting
[jira] Created: (JCR-1331) Inproper deprecation of Locked class
Inproper deprecation of Locked class Key: JCR-1331 URL: https://issues.apache.org/jira/browse/JCR-1331 Project: Jackrabbit Issue Type: Bug Components: jackrabbit-jcr-commons Affects Versions: 1.4 Reporter: Carsten Ziegeler The Locked class in the jcr-commons package has been deprecated with 1.4 and moved to the spi-commons. However as this is a common class which does not depend on the spi, it should rather stay in jcr-commons. The dependencies to spi can simply be removed again. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Why has the Locked class moved to the spi-commons?
Jukka Zitting schrieb: Hi, On Jan 21, 2008 10:36 AM, Carsten Ziegeler [EMAIL PROTECTED] wrote: after updating to jackrabbit 1.4 I noticed that the Locked class has moved from the jcr-commons to the spi-commons package. Now, this may be a dumb question, but why this move? The Locked class has been a utility class which was usable with any jcr implementation as no jackrabbit specific code is required. Now I need dependencies to jackrabbit spi just in order to use this simple class :( Good point. AFAIK the main reason for the move are the five imports to name handling classes in spi-commons. We don't want to make jcr-commons depend on spi-commons and so once the name classes were moved, Locked had to follow. However, looking at the code in more detail, the only use for the name handling classes is to calculate the prefixed name of mix:lockable (it can't be hardcoded as mix: could be remapped). We could remove the dependency fairly easily with a Session.getNamespacePrefix() call. Luckily, to avoid breaking existing clients, we just deprecated the Locked class in jcr-commons instead of removing it. I guess the proper solution is then to file a bug about improper deprecation and we'll drop the @deprecated mark along with the spi-commons dependency in the 1.4.1 release. I filed a bug - thanks Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: Smaller and Quicker Releases
Hi, On Jan 21, 2008 10:18 AM, Felix Meschberger [EMAIL PROTECTED] wrote: Am Samstag, den 19.01.2008, 21:23 +0100 schrieb Roland Weber: The latter requires a new component build process, hence effort. Definitely is this required ! Currently it looks like Jukka is just doing a mvn release on the jackrabbit branch root, thus incrementing versions, tagging and packaging each component (aka module) refereced in the root pom.xml. Actually I do the mvn release tasks manually, as I'm not too comfortable with the idea of the build environment automatically committing stuff in svn. But the basic sequence is the same. BR, Jukka Zitting
Re: svn commit: r613799 - /jackrabbit/trunk/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/persistence/bundle/util/ConnectionFactory.java
Hi,
On Jan 21, 2008 10:48 AM, [EMAIL PROTECTED] wrote:
if (isNullOrEmpty(user) isNullOrEmpty(password)) {
Minor nit, I would rather use only null checks, as in:
if (user == null password == null) {
This way there is the option for someone to explicitly invoke
ds.getConnection(, ) instead of ds.getConnection():
param name=user value=/
param name=password value=/
Also, from the design perspective null, not , is used to mark
unspecified configuration options.
BR,
Jukka Zitting
Re: Why has the Locked class moved to the spi-commons?
Carsten Ziegeler wrote: after updating to jackrabbit 1.4 I noticed that the Locked class has moved from the jcr-commons to the spi-commons package. Now, this may be a dumb question, but why this move? that was probably by mistake. looking at the sources however showed that the class is still present in jackrabbit-jcr-commons, marked deprecated. I'm not sure what the reasons were to deprecated it. I'd rather keep it in jcr-commons, since it only has a dependency to the JCR API. we should probably clarify what classes belong to jcr-commons and spi-commons. here's what I think: - jcr-commons: contains classes that are useful for a JCR API client and have minimal dependencies. - spi-commons: contains classes that are useful for a JCR or SPI implementation. may have a dependency to jcr-commons, though I'd prefer to not have the dependency but there are classes that are in use by both API clients and implementations, e.g. en-/decoding classes. regards marcel
AW: Deadlock in XA Environment
hi marcel, ok thanks for the info. i think its a websphere specific featrure ;-) do you have any ideas what i have to test to find out what happens exactly ? BR, claus -Ursprüngliche Nachricht- Von: Marcel Reutegger [mailto:[EMAIL PROTECTED] Gesendet: Freitag, 18. Jänner 2008 11:03 An: dev@jackrabbit.apache.org Betreff: Re: Deadlock in XA Environment KÖLL Claus wrote: we have some time now jackrabbit (1.3) running in our pruduction environment but without xa enabled. We are running on websphere 5.1 and i have configured now a j2c resource adapter for jackrabbit. it works fine till i try to modify a node in the repository in a global transaction. if i only try a search everything works fine. i have taken a thread dump with the deadlock situation. what i can see comes the deadlock from the DefaultISMLocking$ReadLockImpl Class hope somebodycan help hmm, this looks strange. there is only one thread that is trying to downgrade its write lock. the only reason I can think of why this may block is that downgrade is called from a different thread than the initial write lock acquire. regards marcel
[jira] Commented: (JCR-1320) Support for Sybase
[ https://issues.apache.org/jira/browse/JCR-1320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12560966#action_12560966 ] Guido Jäkel commented on JCR-1320: -- The core reason seems to be, that Sybase don't allow to test a IMAGE-column to be NULL. \java\org\apache\jackrabbit\core\fs\db\DatabaseFileSystem.java:1215 selectFolderExistSQL = select 1 from + schemaObjectPrefix + FSENTRY where FSENTRY_PATH = ? + and FSENTRY_NAME = ? and FSENTRY_DATA is null; By help of SQuirreL, i've verified it: On Sybase select * from REP_FSENTRY where FSENTRY_DATA is null leads to Error: TEXT and IMAGE datatypes may not be used in a WHERE clause, except with the LIKE expression. SQLState: S1000 ErrorCode: 306 On mySQL (, where this collum data type is longblob), it works flawless. Any sybase guru out here? Support for Sybase -- Key: JCR-1320 URL: https://issues.apache.org/jira/browse/JCR-1320 Project: Jackrabbit Issue Type: New Feature Components: jackrabbit-core Affects Versions: 1.4 Reporter: Guido Jäkel Attachments: jackrabbit-core-1.4-sybase.jar To use Sybase as a database backend for all the components and different implementation, one need specific sybase.ddl-files to configure a schema sybase. Sybase don't seems to be compatible to one of the already existing schema. The following files are required: * org/apache/jackrabbit/core/persistence/db/sybase.ddl * org/apache/jackrabbit/core/persistence/bundle/sybase.ddl * org/apache/jackrabbit/core/fs/db/sybase.ddl * org/apache/jackrabbit/core/journal/sybase.ddl Thank you for support. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1309) Refactor DBMS support for JNDI datasources
[ https://issues.apache.org/jira/browse/JCR-1309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12560967#action_12560967 ] Thomas Mueller commented on JCR-1309: - I agree, all components of Jackrabbit should be able to get the connection via JNDI. This is already implemented in org.apache.jackrabbit.core.persistence.bundle.util.ConnectionFactory.getConnection which is used in BundleDbPersistenceManager and DbDataStore: For all bundle persistence managers and for the database data store, JNDI can be used to get the connection. In this case, use the javax.naming.InitialContext as the driver and the JNDI name as the URL. User name and password are to be left empty if they are already set in the JNDI resource. Example JNDI settings: param name=driver value=javax.naming.InitialContext / param name=url value=java:comp/env/jdbc/Test / I suggest all components use this mechanism instead of using DriverManager.getConnection directly. To do that, the following classes need to be changed: org.apache.jackrabbit.core.fs.db.DbFileSystem org.apache.jackrabbit.core.journal.DatabaseJournal org.apache.jackrabbit.core.persistence.db.SimpleDbPersistenceManager I suggest to deprecate org.apache.jackrabbit.core.journal.JNDIDatabaseJournal. This class is anyway not a solution if somebody wants to use an Oracle database over JNDI: should he use JNDIDatabaseJournal or OracleDatabaseJournal? Also, org.apache.jackrabbit.core.fs.db.JNDIDatabaseFileSystem and org.apache.jackrabbit.core.persistence.db.JNDIDatabasePersistenceManager should be deprecated. Refactor DBMS support for JNDI datasources -- Key: JCR-1309 URL: https://issues.apache.org/jira/browse/JCR-1309 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-core Affects Versions: 1.3.3 Reporter: Andy Key Our shop currently uses Oracle for most projects, most commonly in an application server (Tomcat, WebSphere, etc.), and use configured J2EE datasources. Unfortunately, many of the classes that fix quirks on specific DBMS force you to configure a JDBC connection (look at org.apache.jackrabbit.core.fs.db.OracleFileSystem for instance), which is a bad idea on an application server -- the application server should be managing resources like DB connections, etc. If you want to use an DbFileSystem based on an Oracle database, you can't use a datasource from a JNDI lookup. This in effect makes Jackrabbit unusable in clustered enterprise environments. It would be much better to refactor the current database support to separate the method that an implementation obtains its connection from its functionality. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1196) Optimize queries for DescendantSelfAxisWeight/ChildAxisQuery
[ https://issues.apache.org/jira/browse/JCR-1196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12560972#action_12560972 ] Ard Schrijvers commented on JCR-1196: - With the fixed caching I cannot imagine that 2.2 /jcr:root/gfr:devices/gfr:device/gfr:capabilityMap cca 14000ms!!! takes 14000 ms *after* the first execution. Can you attach your test case? You are sure you are measuring the time *after* the first time you execute the query? Can you tell me how large the resultset is (getSize()) when not using a limit/offset. If the resultset is in the order of 10^6 you might have performance issues when using paths in your query, even with the fixed cache. This is a known issue. Optimize queries for DescendantSelfAxisWeight/ChildAxisQuery Key: JCR-1196 URL: https://issues.apache.org/jira/browse/JCR-1196 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-core, query Reporter: Ard Schrijvers A query like /documents/en/news//[EMAIL PROTECTED] order by @modificationDate when there are many nodes ( 1.000) in /documents/en/news becomes very slow. I think the bottleneck is in something like recursive filters in lucene. First off all I'll try to find some stastistics about the performance, and describe the bottleneck. After that, a solution must be found, where we need to keep in mind that 1) these queries run faster and scale better (obviously) 2) moving a node must stay a cheap operation Also see: http://www.nabble.com/Search-performance--%3A-MultiIndex-tf4695559.html#a13421949 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Smaller and Quicker Releases
Hi, We have a relatively short term need to do patch releases and I don't want to introduce too big changes in the 1.4 (and 1.3) branch, so here's a proposal for an intermediate solution for patch releases until we reach a better consensus on what to do in trunk. In fact I think we should use something like this even after (or if) we split Jackrabbit to subprojects. JACKRABBIT PATCH RELEASES Granularity A patch release will only contain a single Jackrabbit component. Bug fixes to multiple components will go out in multiple patch releases. Version control Bug fixes targeted to a patch release should first be committed in Jackrabbit trunk, and then merged (preferably using svn merge where possible) to the appropriate branch. Fixes to issues that are no longer present in trunk (for example because of some refactoring) can be committed directly to a branch. Once all planned bug fixes have been merged or committed to the branch and any administrative changes (version number update, etc.) have been made, the component to be released will be tagged from the branch using a command like: svn copy -m 'x.y: Tagged component-x.y.z' \ https://svn.apache.org/repos/asf/jackrabbit/branches/x.y/component \ https://svn.apache.org/repos/asf/jackrabbit/tags/component-x.y.z The contents of the tag should never be changed. Issue tracker Patch releases will be tracked by assigning each of them a separate component-version (e.g. jackrabbit-core-1.4.2) tag in the issue tracker. All bug fixes to be included in a patch release should be tagged with the respective version tag. Note that this will likely cause problems later on by inflating the list of release versions, but hopefully by that time we have split the release process to more manageable subprojects. Parent POM The Jackrabbit parent POM (org.apache.jackrabbit:jackrabbit) will not be changed or included in a patch release. A component POM needs to explicitly override parent settings if it needs such changes in a patch release. Note that POM changes (apart from version updates) should normally not be needed in patch releases. Patch dependencies Bug fixes in patch releases should normally not depend on changes in other components or external dependencies. In case they do (and there is a solid reason for doing that), such updated dependencies should be explicitly declared in the component POM and clearly described in the patch release notes. Announcements Normal patch releases will be announced on the Jackrabbit dev@, users@, and announce@ mailing lists, but not on [EMAIL PROTECTED] Patch releases containing fixes to critical security issues will also be announced on [EMAIL PROTECTED] WDYT? BR, Jukka Zitting
Re: AW: Deadlock in XA Environment
Hi Claus, if you were using 1.4 you could extend the DefaultISMLocking class and add logging to the methods. e.g. log the thread name. then configure and use the new locking class in repository.xml. this would at least allow us to rule out (or prove) the different thread assumption. regards marcel KÖLL Claus wrote: hi marcel, ok thanks for the info. i think its a websphere specific featrure ;-) do you have any ideas what i have to test to find out what happens exactly ? BR, claus -Ursprüngliche Nachricht- Von: Marcel Reutegger [mailto:[EMAIL PROTECTED] Gesendet: Freitag, 18. Jänner 2008 11:03 An: dev@jackrabbit.apache.org Betreff: Re: Deadlock in XA Environment KÖLL Claus wrote: we have some time now jackrabbit (1.3) running in our pruduction environment but without xa enabled. We are running on websphere 5.1 and i have configured now a j2c resource adapter for jackrabbit. it works fine till i try to modify a node in the repository in a global transaction. if i only try a search everything works fine. i have taken a thread dump with the deadlock situation. what i can see comes the deadlock from the DefaultISMLocking$ReadLockImpl Class hope somebodycan help hmm, this looks strange. there is only one thread that is trying to downgrade its write lock. the only reason I can think of why this may block is that downgrade is called from a different thread than the initial write lock acquire. regards marcel
RE: NGP: Storage model
how would you build the path of a node accessed by uuid? Jukka Zitting wrote: Instead of the current node id's, the search index would need to contain the paths of the indexed nodes. Thus the //[EMAIL PROTECTED]:uuid='...'] query (or its equivalent) executed by getNodeByUUID() would return the path that can be used to access the node. Doesn't this imply that moving a node would need re-indexing all its child nodes because of changed paths, making a move a very expensive operation? Regards Ard BR, Jukka Zitting
Re: NGP: Storage model
Hi, On Jan 21, 2008 12:30 PM, Ard Schrijvers [EMAIL PROTECTED] wrote: Jukka Zitting wrote: Instead of the current node id's, the search index would need to contain the paths of the indexed nodes. Thus the //[EMAIL PROTECTED]:uuid='...'] query (or its equivalent) executed by getNodeByUUID() would return the path that can be used to access the node. Doesn't this imply that moving a node would need re-indexing all its child nodes because of changed paths, making a move a very expensive operation? It should be fairly easy to optimize this by just updating the changed path references in the search index for any nodes that haven't been changed during the move. BR, Jukka Zitting
[jira] Assigned: (JCR-1331) Inproper deprecation of Locked class
[ https://issues.apache.org/jira/browse/JCR-1331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting reassigned JCR-1331: -- Assignee: Jukka Zitting Inproper deprecation of Locked class Key: JCR-1331 URL: https://issues.apache.org/jira/browse/JCR-1331 Project: Jackrabbit Issue Type: Bug Components: jackrabbit-jcr-commons Affects Versions: 1.4 Reporter: Carsten Ziegeler Assignee: Jukka Zitting The Locked class in the jcr-commons package has been deprecated with 1.4 and moved to the spi-commons. However as this is a common class which does not depend on the spi, it should rather stay in jcr-commons. The dependencies to spi can simply be removed again. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-1331) Inproper deprecation of Locked class
[ https://issues.apache.org/jira/browse/JCR-1331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting resolved JCR-1331. Resolution: Fixed Fix Version/s: 1.4.1 Fixed in revision 613834. Thanks! Inproper deprecation of Locked class Key: JCR-1331 URL: https://issues.apache.org/jira/browse/JCR-1331 Project: Jackrabbit Issue Type: Bug Components: jackrabbit-jcr-commons Affects Versions: 1.4 Reporter: Carsten Ziegeler Assignee: Jukka Zitting Fix For: 1.4.1 The Locked class in the jcr-commons package has been deprecated with 1.4 and moved to the spi-commons. However as this is a common class which does not depend on the spi, it should rather stay in jcr-commons. The dependencies to spi can simply be removed again. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Smaller and Quicker Releases
Hi Jukka, ++1 I think this is a very valuable strategy moving forward for our patch releases. And it will probably also show, that we might handle the trunk in a similar manner as we would start handling the branch(es). Thanks for this proposal. Regards Felix Am Montag, den 21.01.2008, 12:11 +0200 schrieb Jukka Zitting: Hi, We have a relatively short term need to do patch releases and I don't want to introduce too big changes in the 1.4 (and 1.3) branch, so here's a proposal for an intermediate solution for patch releases until we reach a better consensus on what to do in trunk. In fact I think we should use something like this even after (or if) we split Jackrabbit to subprojects. JACKRABBIT PATCH RELEASES Granularity A patch release will only contain a single Jackrabbit component. Bug fixes to multiple components will go out in multiple patch releases. Version control Bug fixes targeted to a patch release should first be committed in Jackrabbit trunk, and then merged (preferably using svn merge where possible) to the appropriate branch. Fixes to issues that are no longer present in trunk (for example because of some refactoring) can be committed directly to a branch. Once all planned bug fixes have been merged or committed to the branch and any administrative changes (version number update, etc.) have been made, the component to be released will be tagged from the branch using a command like: svn copy -m 'x.y: Tagged component-x.y.z' \ https://svn.apache.org/repos/asf/jackrabbit/branches/x.y/component \ https://svn.apache.org/repos/asf/jackrabbit/tags/component-x.y.z The contents of the tag should never be changed. Issue tracker Patch releases will be tracked by assigning each of them a separate component-version (e.g. jackrabbit-core-1.4.2) tag in the issue tracker. All bug fixes to be included in a patch release should be tagged with the respective version tag. Note that this will likely cause problems later on by inflating the list of release versions, but hopefully by that time we have split the release process to more manageable subprojects. Parent POM The Jackrabbit parent POM (org.apache.jackrabbit:jackrabbit) will not be changed or included in a patch release. A component POM needs to explicitly override parent settings if it needs such changes in a patch release. Note that POM changes (apart from version updates) should normally not be needed in patch releases. Patch dependencies Bug fixes in patch releases should normally not depend on changes in other components or external dependencies. In case they do (and there is a solid reason for doing that), such updated dependencies should be explicitly declared in the component POM and clearly described in the patch release notes. Announcements Normal patch releases will be announced on the Jackrabbit dev@, users@, and announce@ mailing lists, but not on [EMAIL PROTECTED] Patch releases containing fixes to critical security issues will also be announced on [EMAIL PROTECTED] WDYT? BR, Jukka Zitting
[jira] Commented: (JCR-1331) Inproper deprecation of Locked class
[ https://issues.apache.org/jira/browse/JCR-1331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12560982#action_12560982 ] Carsten Ziegeler commented on JCR-1331: --- What about the version in the spi-commons? Shouldn't it be deprecated? Inproper deprecation of Locked class Key: JCR-1331 URL: https://issues.apache.org/jira/browse/JCR-1331 Project: Jackrabbit Issue Type: Bug Components: jackrabbit-jcr-commons Affects Versions: 1.4 Reporter: Carsten Ziegeler Assignee: Jukka Zitting Fix For: 1.4.1 The Locked class in the jcr-commons package has been deprecated with 1.4 and moved to the spi-commons. However as this is a common class which does not depend on the spi, it should rather stay in jcr-commons. The dependencies to spi can simply be removed again. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
RE: NGP: Storage model
Jukka Zitting wrote: It should be fairly easy to optimize this by just updating the changed path references in the search index for any nodes that haven't been changed during the move. I suppose updating the nodes that *have* changed. Furthermore, I do doubt wether this is that easy, because AFAIU you cannot update some lucene Field in a lucene document: the entire document needs to be reindexed. And this obviously gets very expensive for renaming some node with a large subtree below it. I must be missing something, but I really do not see how you can implement this efficiently without changing lucene code (which for a reason does never 'change' a Field but can only append a new document) -Ard BR, Jukka Zitting
[jira] Created: (JCR-1332) CLONE -Aggregate include ignored if no primaryType set
CLONE -Aggregate include ignored if no primaryType set -- Key: JCR-1332 URL: https://issues.apache.org/jira/browse/JCR-1332 Project: Jackrabbit Issue Type: Bug Components: indexing, jackrabbit-core Reporter: Jarle B. Hjortland Priority: Minor Fix For: 1.4 If the include element of an aggregate definition does not have a primaryType attribute then the include is never matched. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1332) CLONE -Aggregate include ignored if no primaryType set
[ https://issues.apache.org/jira/browse/JCR-1332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12560985#action_12560985 ] Jarle B. Hjortland commented on JCR-1332: - This issue seems to exist in 1.4 release version, I hade to set primary type on my includes. include primaryType=nt:unstructured*/*/*/include works but include*/*/*/include does not work CLONE -Aggregate include ignored if no primaryType set -- Key: JCR-1332 URL: https://issues.apache.org/jira/browse/JCR-1332 Project: Jackrabbit Issue Type: Bug Components: indexing, jackrabbit-core Reporter: Jarle B. Hjortland Priority: Minor Fix For: 1.4 If the include element of an aggregate definition does not have a primaryType attribute then the include is never matched. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1333) jackrabbit-jcr-rmi: Supplied javax.transaction.xa.Xid is assumed serializable, but is not on some environments.
jackrabbit-jcr-rmi: Supplied javax.transaction.xa.Xid is assumed serializable,
but is not on some environments.
---
Key: JCR-1333
URL: https://issues.apache.org/jira/browse/JCR-1333
Project: Jackrabbit
Issue Type: Bug
Affects Versions: 1.4
Environment: Linux (suse9) with websphere 6.1 invoking jackrabbit
client RMI
Reporter: Paul Gribben
Websphere provides a non-serializable javax.transaction.xa.Xid implementation,
causing ClientXAResource to fail with NotSerializableException when passing Xid
over RMI.
I have worked around this by converting the supplied Xid to a local
serializable Xid implementation that takes the supplied Xid parameters, and
implements hashCode() and equals() correctly:
private static class SerializableXID implements javax.transaction.xa.Xid,
Serializable {
/**
* Serial version ID
*/
private static final long serialVersionUID =
-1390620315181450507L;
private final byte[] branchQualifier;
private final byte[] globalTransactionId;
private final int formatId;
private final int hashCode;
public SerializableXID(Xid xid) {
branchQualifier = xid.getBranchQualifier();
globalTransactionId = xid.getGlobalTransactionId();
formatId = xid.getFormatId();
hashCode = xid.hashCode();
}
public byte[] getBranchQualifier() {
return branchQualifier;
}
public int getFormatId() {
return formatId;
}
public byte[] getGlobalTransactionId() {
return globalTransactionId;
}
public final int hashCode() {
return hashCode;
}
public final boolean equals(Object obj) {
if(obj == this) {
return true;
}
if(!(obj instanceof Xid)) {
return false;
}
Xid xidimpl = (Xid)obj;
if(formatId != xidimpl.getFormatId()) {
return false;
}
else {
return Arrays.equals(branchQualifier,
xidimpl.getBranchQualifier())
Arrays.equals(globalTransactionId,
xidimpl.getGlobalTransactionId());
}
}
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Smaller and Quicker Releases
+1
Re: NGP: Storage model
Hi, On Jan 21, 2008 12:51 PM, Ard Schrijvers [EMAIL PROTECTED] wrote: Jukka Zitting wrote: It should be fairly easy to optimize this by just updating the changed path references in the search index for any nodes that haven't been changed during the move. I suppose updating the nodes that *have* changed. Yes. :-) What I was trying to express were nodes that are moved but not otherwise changed. I.e. the only modification is the path change. Furthermore, I do doubt wether this is that easy, because AFAIU you cannot update some lucene Field in a lucene document: the entire document needs to be reindexed. And this obviously gets very expensive for renaming some node with a large subtree below it. I must be missing something, but I really do not see how you can implement this efficiently without changing lucene code (which for a reason does never 'change' a Field but can only append a new document) Good point. Though it shouldn't be too difficult to enhance Lucene to reuse a previously analyzed and indexed document as the basis of a slightly modified version. There's also the new document payload feature that might be useful in this regard. BR, Jukka Zitting
[jira] Commented: (JCR-1196) Optimize queries for DescendantSelfAxisWeight/ChildAxisQuery
[
https://issues.apache.org/jira/browse/JCR-1196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12560997#action_12560997
]
Martin Zdila commented on JCR-1196:
---
test method:
-
long time = System.currentTimeMillis();
final String queryString = ...;
final Query query =
session.getWorkspace().getQueryManager().createQuery(queryString, Query.XPATH);
final QueryResult queryResult = query.execute();
System.out.println(t1: + (System.currentTimeMillis() - time));
time = System.currentTimeMillis();
final NodeIterator ni = queryResult.getNodes();
System.out.println(size: + ni.getSize());
System.out.println(t2: + (System.currentTimeMillis() - time));
time = System.currentTimeMillis();
ni.hasNext(); // this single call consumes pretty much time (t3)!
System.out.println(t3: + (System.currentTimeMillis() - time));
time = System.currentTimeMillis();
for (int i = 0; ni.hasNext() i 1000; i++) {
ni.next();
}
System.out.println(t4: + (System.currentTimeMillis() - time));
results:
Measured second call of the test method (not first which takes longer).
Note that only first test measures t3, because it takes very long time which I
don't have. BTW isn't it another issue?
//gfr:capabilityMap
t1:406
size:11208
t2:0
t3:453864
t4:12
/jcr:root/gfr:devices/gfr:device/gfr:capabilityMap
t1:35358
size:11208
/jcr:root/gfr:devices/gfr:device
t1:169
size:11208
Optimize queries for DescendantSelfAxisWeight/ChildAxisQuery
Key: JCR-1196
URL: https://issues.apache.org/jira/browse/JCR-1196
Project: Jackrabbit
Issue Type: Improvement
Components: jackrabbit-core, query
Reporter: Ard Schrijvers
A query like
/documents/en/news//[EMAIL PROTECTED] order by @modificationDate
when there are many nodes ( 1.000) in /documents/en/news becomes very
slow. I think the bottleneck is in something like recursive filters in
lucene. First off all I'll try to find some stastistics about the
performance, and describe the bottleneck. After that, a solution must be
found, where we need to keep in mind that
1) these queries run faster and scale better (obviously)
2) moving a node must stay a cheap operation
Also see:
http://www.nabble.com/Search-performance--%3A-MultiIndex-tf4695559.html#a13421949
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (JCR-1331) Inproper deprecation of Locked class
[ https://issues.apache.org/jira/browse/JCR-1331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed JCR-1331. - Thanks! Inproper deprecation of Locked class Key: JCR-1331 URL: https://issues.apache.org/jira/browse/JCR-1331 Project: Jackrabbit Issue Type: Bug Components: jackrabbit-jcr-commons Affects Versions: 1.4 Reporter: Carsten Ziegeler Assignee: Jukka Zitting Fix For: 1.4.1 The Locked class in the jcr-commons package has been deprecated with 1.4 and moved to the spi-commons. However as this is a common class which does not depend on the spi, it should rather stay in jcr-commons. The dependencies to spi can simply be removed again. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1196) Optimize queries for DescendantSelfAxisWeight/ChildAxisQuery
[ https://issues.apache.org/jira/browse/JCR-1196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Zdila updated JCR-1196: -- Attachment: (was: jcr-repository-xml-dump.xml.tar.bz) Optimize queries for DescendantSelfAxisWeight/ChildAxisQuery Key: JCR-1196 URL: https://issues.apache.org/jira/browse/JCR-1196 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-core, query Reporter: Ard Schrijvers Attachments: jcr-repository-xml-dump.xml.bz2 A query like /documents/en/news//[EMAIL PROTECTED] order by @modificationDate when there are many nodes ( 1.000) in /documents/en/news becomes very slow. I think the bottleneck is in something like recursive filters in lucene. First off all I'll try to find some stastistics about the performance, and describe the bottleneck. After that, a solution must be found, where we need to keep in mind that 1) these queries run faster and scale better (obviously) 2) moving a node must stay a cheap operation Also see: http://www.nabble.com/Search-performance--%3A-MultiIndex-tf4695559.html#a13421949 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
RE: NGP: Storage model
Hi, On Jan 21, 2008 12:51 PM, Ard Schrijvers [EMAIL PROTECTED] wrote: Jukka Zitting wrote: It should be fairly easy to optimize this by just updating the changed path references in the search index for any nodes that haven't been changed during the move. I suppose updating the nodes that *have* changed. Jukka Zitting wrote: Yes. :-) What I was trying to express were nodes that are moved but not otherwise changed. I.e. the only modification is the path change. Clear :-) Good point. Though it shouldn't be too difficult to enhance Lucene to reuse a previously analyzed and indexed document as the basis of a slightly modified version. There's also the new document payload feature that might be useful in this regard. I am not aware of the 'new document payload' feature, but I think reusing an already indexed and analyzed document might be a handy lucene feature anyway. OTOH I thought it was really an important Jackrabbit part to not store any hierarchical data whatsoever because inefficient moves (though indexing it might not be seen as storing it and if we enhance lucene somewhat...). What I do like about your idea is that we can implement some queries much more efficient when we store path info: the current havy DescendantSelfAxisWeight/ChildAxisQuery can be implemented easier because we might be able to find all nodes that are valid according its path with a single lucene query (see JCR-1196 'Optimize queries for DescendantSelfAxisWeight/ChildAxisQuery' ) -Ard BR, Jukka Zitting
[OCM] Making the path field optional?
Hi, I'm currently trying to map some beans to jcr using OCM. It seems that currently a mapping is only possible, if my bean has a path field containing the path of the bean in the repository. Or if I want to add a new bean to the repo, I've to set the path on the bean first in order to tell OCM where to store it. I don't know if this has been discussed before, but I think this requirement somehow ties the beans to jcr which is not nice :) I'm wondering if there isn't a better way? Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
[jira] Commented: (JCR-1196) Optimize queries for DescendantSelfAxisWeight/ChildAxisQuery
[ https://issues.apache.org/jira/browse/JCR-1196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561005#action_12561005 ] Ard Schrijvers commented on JCR-1196: - t3 is 453 sec for ni.hasNext()!! This is indeed a different issue AFAICS. ATM, I am occupied with some other work, but I'll try to investigate the issue thie evening or tomorrow evening. I'll get back on this one, try to reproduce your numbers, and thanks so far for investigating the issue. By the way: did you implement a custom accessmanager? Optimize queries for DescendantSelfAxisWeight/ChildAxisQuery Key: JCR-1196 URL: https://issues.apache.org/jira/browse/JCR-1196 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-core, query Reporter: Ard Schrijvers Attachments: jcr-repository-xml-dump.xml.bz2 A query like /documents/en/news//[EMAIL PROTECTED] order by @modificationDate when there are many nodes ( 1.000) in /documents/en/news becomes very slow. I think the bottleneck is in something like recursive filters in lucene. First off all I'll try to find some stastistics about the performance, and describe the bottleneck. After that, a solution must be found, where we need to keep in mind that 1) these queries run faster and scale better (obviously) 2) moving a node must stay a cheap operation Also see: http://www.nabble.com/Search-performance--%3A-MultiIndex-tf4695559.html#a13421949 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1334) Deadlock with XA enabled
[ https://issues.apache.org/jira/browse/JCR-1334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Köll updated JCR-1334: Attachment: javacore.20080121.132210.2524.txt lock_output.txt lock_output.txt- I have added in the Methods of the DefaultISMLocking Class the calling Threadname javacorexxx - the javacore file of the deadlock situation Deadlock with XA enabled Key: JCR-1334 URL: https://issues.apache.org/jira/browse/JCR-1334 Project: Jackrabbit Issue Type: Bug Components: jackrabbit-core, jackrabbit-jca Affects Versions: 1.4 Environment: WebSphere Application Server 5.1 Reporter: Claus Köll Priority: Critical Attachments: javacore.20080121.132210.2524.txt, lock_output.txt Since we have configured a j2c resource adapter any modification to the repository ends with a deadlock. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: NGP: Storage model
Hi, On Jan 21, 2008 3:20 PM, Ard Schrijvers [EMAIL PROTECTED] wrote: I am not aware of the 'new document payload' feature, [...] That's pretty bleeding edge, I learned about it from Michael Busch during the last ApacheCon. See the reference on the last page of his presentation [1]. AFAIK it's not there yet but neither is NGP, so I'm hoping that by the time NGP does proper indexing that feature will be available. reusing an already indexed and analyzed document might be a handy lucene feature anyway. Agreed. Perhaps something to follow up with the Lucene guys. OTOH I thought it was really an important Jackrabbit part to not store any hierarchical data whatsoever because inefficient moves That's a good point, and there's certainly some indexing overhead that NGP would bring to such cases. It's good that we review the design and the implications to get a better picture of what the tradeoffs are. [1] http://us.apachecon.com/us2007/downloads/AdvancedIndexingLucene.ppt BR, Jukka Zitting
Re: Smaller and Quicker Releases
+1 regards marcel Jukka Zitting wrote: Hi, We have a relatively short term need to do patch releases and I don't want to introduce too big changes in the 1.4 (and 1.3) branch, so here's a proposal for an intermediate solution for patch releases until we reach a better consensus on what to do in trunk. In fact I think we should use something like this even after (or if) we split Jackrabbit to subprojects. JACKRABBIT PATCH RELEASES Granularity A patch release will only contain a single Jackrabbit component. Bug fixes to multiple components will go out in multiple patch releases. Version control Bug fixes targeted to a patch release should first be committed in Jackrabbit trunk, and then merged (preferably using svn merge where possible) to the appropriate branch. Fixes to issues that are no longer present in trunk (for example because of some refactoring) can be committed directly to a branch. Once all planned bug fixes have been merged or committed to the branch and any administrative changes (version number update, etc.) have been made, the component to be released will be tagged from the branch using a command like: svn copy -m 'x.y: Tagged component-x.y.z' \ https://svn.apache.org/repos/asf/jackrabbit/branches/x.y/component \ https://svn.apache.org/repos/asf/jackrabbit/tags/component-x.y.z The contents of the tag should never be changed. Issue tracker Patch releases will be tracked by assigning each of them a separate component-version (e.g. jackrabbit-core-1.4.2) tag in the issue tracker. All bug fixes to be included in a patch release should be tagged with the respective version tag. Note that this will likely cause problems later on by inflating the list of release versions, but hopefully by that time we have split the release process to more manageable subprojects. Parent POM The Jackrabbit parent POM (org.apache.jackrabbit:jackrabbit) will not be changed or included in a patch release. A component POM needs to explicitly override parent settings if it needs such changes in a patch release. Note that POM changes (apart from version updates) should normally not be needed in patch releases. Patch dependencies Bug fixes in patch releases should normally not depend on changes in other components or external dependencies. In case they do (and there is a solid reason for doing that), such updated dependencies should be explicitly declared in the component POM and clearly described in the patch release notes. Announcements Normal patch releases will be announced on the Jackrabbit dev@, users@, and announce@ mailing lists, but not on [EMAIL PROTECTED] Patch releases containing fixes to critical security issues will also be announced on [EMAIL PROTECTED] WDYT? BR, Jukka Zitting
Re: [OCM] Making the path field optional?
Hi Carsten, Yes this has been discussed before - actually just recently [1]. And yes, currently, OCM requires a path field to be able to do the mapping. This is comparable to the IDs used by other mapping products. Regards Felix [1] http://www.mail-archive.com/dev@jackrabbit.apache.org/msg09621.html Am Montag, den 21.01.2008, 14:29 +0100 schrieb Carsten Ziegeler: Hi, I'm currently trying to map some beans to jcr using OCM. It seems that currently a mapping is only possible, if my bean has a path field containing the path of the bean in the repository. Or if I want to add a new bean to the repo, I've to set the path on the bean first in order to tell OCM where to store it. I don't know if this has been discussed before, but I think this requirement somehow ties the beans to jcr which is not nice :) I'm wondering if there isn't a better way? Carsten
Re: [OCM] Making the path field optional?
When we started the first OCM prototype in 2005, there were 2 solutions : - Use a path attribute in each pojo . or - Use the path as an argument in many ObjectContentManager methods like ocm.insert(String path, Object object) The first solution has been selected because the path is good candidate for an object id. I don't know if this has been discussed before, but I think this requirement somehow ties the beans to jcr which is not nice :) I'm wondering if there isn't a better way? you are right. Maybe it is a bad influence from the ORM technologies :-) . I mean, having an id like the path or an UUID is maybe not necessary in our OCM framework. We can review if there is another alternative. br, Christophe
Re: [OCM] Making the path field optional?
Felix Meschberger wrote: Hi Carsten, Yes this has been discussed before - actually just recently [1]. Ups, totally oversaw this - sorry :( And yes, currently, OCM requires a path field to be able to do the mapping. This is comparable to the IDs used by other mapping products. Yes, but depending on my use case, I'm not required to have id attributes - like if I'm only reading stuff from a db, that's not required. And I never liked the mapping tools where I was forced to have an id field :) Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: [OCM] Making the path field optional?
Christophe Lombart wrote: When we started the first OCM prototype in 2005, there were 2 solutions : - Use a path attribute in each pojo . or - Use the path as an argument in many ObjectContentManager methods like ocm.insert(String path, Object object) The first solution has been selected because the path is good candidate for an object id. I don't know if this has been discussed before, but I think this requirement somehow ties the beans to jcr which is not nice :) I'm wondering if there isn't a better way? you are right. Maybe it is a bad influence from the ORM technologies :-) . I mean, having an id like the path or an UUID is maybe not necessary in our OCM framework. We can review if there is another alternative. Hmm, yes - I can imagine that it might be difficult to get everything working without the path (id). Currently I have the use case where I just want to store a bean at a specific path - the bean itself does not care about the path and I want to query these beans - but I don't need the path in the result. Now, it's not a big deal to add the string property to my bean, but still it doesn't feel nice :) So the addition of insert(String path, Object object) and not requiring a path field when reading beans from jcr would be sufficient for my use case :) Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: [OCM] Making the path field optional?
On Jan 21, 2008 3:06 PM, Carsten Ziegeler [EMAIL PROTECTED] wrote: Now, it's not a big deal to add the string property to my bean, but still it doesn't feel nice :) So the addition of insert(String path, Object object) and not requiring a path field when reading beans from jcr would be sufficient for my use case :) IMHO, supporting both solutions will add more confusion to the users. I would like to suggest to keep the current OCM API and the mandatory path attribute or remove the mandatory path attribute and refactor OCM API in order to add the path as argument of some methods. Christophe Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
[jira] Commented: (JCR-1305) JNDI data sources with BundleDbPersistenceManager: UnsupportedOperationException
[ https://issues.apache.org/jira/browse/JCR-1305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561016#action_12561016 ] Thomas Mueller commented on JCR-1305: - Fixed in revision 613898 (branch 1.4). JNDI data sources with BundleDbPersistenceManager: UnsupportedOperationException Key: JCR-1305 URL: https://issues.apache.org/jira/browse/JCR-1305 Project: Jackrabbit Issue Type: Bug Components: jackrabbit-core Affects Versions: 1.4 Reporter: Thomas Mueller Assignee: Thomas Mueller Priority: Minor Fix For: 1.4.1 When using the org.apache.tomcat.dbcp.dbcp.BasicDataSourceFactory, the BundleDbPersistenceManager can not open a database connection via JNDI because the method DataSource.getConnection(user, password) is not supported. Instead, DataSource.getConnection() must be used for this to work. ConnectionFactory.getConnection should be changed to call this method if user name and password are empty. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
RE: NGP: Storage model
Jukka Zitting wrote: That's pretty bleeding edge, I learned about it from Michael Busch during the last ApacheCon. See the reference on the last page of his presentation [1]. AFAIK it's not there yet but neither is NGP, so I'm hoping that by the time NGP does proper indexing that feature will be available. I am trying to understand what benefit you are aiming at: AFAIU (from the presentation and some email threads) the payload is used to store some extra info along with a term (currently). The per-document payload is a future feature? Am I correct in that you are aiming at storing and searching the path efficiently by using Payload? reusing an already indexed and analyzed document might be a handy lucene feature anyway. Agreed. Perhaps something to follow up with the Lucene guys. I'll ask on the lucene user-list and see wether I get some input. -Ard
[jira] Resolved: (JCR-1332) CLONE -Aggregate include ignored if no primaryType set
[ https://issues.apache.org/jira/browse/JCR-1332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger resolved JCR-1332. --- Resolution: Fixed Fix Version/s: (was: 1.4) 1.5 1.4.1 Added test case and fixed issue in trunk and 1.4 branch. svn revisions 613908 (trunk) and 613910 (1.4 branch). Thank you for reporting this issue. CLONE -Aggregate include ignored if no primaryType set -- Key: JCR-1332 URL: https://issues.apache.org/jira/browse/JCR-1332 Project: Jackrabbit Issue Type: Bug Components: indexing, jackrabbit-core Affects Versions: 1.4 Reporter: Jarle B. Hjortland Priority: Minor Fix For: 1.4.1, 1.5 If the include element of an aggregate definition does not have a primaryType attribute then the include is never matched. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1332) CLONE -Aggregate include ignored if no primaryType set
[ https://issues.apache.org/jira/browse/JCR-1332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger updated JCR-1332: -- Affects Version/s: 1.4 CLONE -Aggregate include ignored if no primaryType set -- Key: JCR-1332 URL: https://issues.apache.org/jira/browse/JCR-1332 Project: Jackrabbit Issue Type: Bug Components: indexing, jackrabbit-core Affects Versions: 1.4 Reporter: Jarle B. Hjortland Priority: Minor Fix For: 1.4.1, 1.5 If the include element of an aggregate definition does not have a primaryType attribute then the include is never matched. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
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
Re: NGP: Storage model
Hi, On Jan 21, 2008 4:38 PM, Ard Schrijvers [EMAIL PROTECTED] wrote: Jukka Zitting wrote: That's pretty bleeding edge, I learned about it from Michael Busch during the last ApacheCon. See the reference on the last page of his presentation [1]. AFAIK it's not there yet but neither is NGP, so I'm hoping that by the time NGP does proper indexing that feature will be available. I am trying to understand what benefit you are aiming at: AFAIU (from the presentation and some email threads) the payload is used to store some extra info along with a term (currently). The per-document payload is a future feature? Yes. I don't know when it's due in Lucene but once it's there, you should be able to store _and update_ payload data associated with a document. Am I correct in that you are aiming at storing and searching the path efficiently by using Payload? Yes. reusing an already indexed and analyzed document might be a handy lucene feature anyway. Agreed. Perhaps something to follow up with the Lucene guys. I'll ask on the lucene user-list and see wether I get some input. Cool, thanks! BR, Jukka Zitting
RE: NGP: Storage model
Jukka Zitting wrote: Yes. I don't know when it's due in Lucene but once it's there, you should be able to store _and update_ payload data associated with a document. Ah, I understand why you would like to use it: you can quite efficiently restore some path representation without touching the rest of the lucene document. Did not see however that you can actually query for the Payload values, so this still might be a problem, OTOH, I am not (yet) aware of the opportunities I'll ask on the lucene user-list and see wether I get some input. Cool, thanks! Keep you posted, -Ard BR, Jukka Zitting
[jira] Assigned: (JCR-1309) Refactor DBMS support for JNDI datasources
[ https://issues.apache.org/jira/browse/JCR-1309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller reassigned JCR-1309: --- Assignee: Thomas Mueller Refactor DBMS support for JNDI datasources -- Key: JCR-1309 URL: https://issues.apache.org/jira/browse/JCR-1309 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-core Affects Versions: 1.3.3 Reporter: Andy Key Assignee: Thomas Mueller Our shop currently uses Oracle for most projects, most commonly in an application server (Tomcat, WebSphere, etc.), and use configured J2EE datasources. Unfortunately, many of the classes that fix quirks on specific DBMS force you to configure a JDBC connection (look at org.apache.jackrabbit.core.fs.db.OracleFileSystem for instance), which is a bad idea on an application server -- the application server should be managing resources like DB connections, etc. If you want to use an DbFileSystem based on an Oracle database, you can't use a datasource from a JNDI lookup. This in effect makes Jackrabbit unusable in clustered enterprise environments. It would be much better to refactor the current database support to separate the method that an implementation obtains its connection from its functionality. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1309) Refactor DBMS support for JNDI datasources
[ https://issues.apache.org/jira/browse/JCR-1309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting updated JCR-1309: --- Affects Version/s: (was: 1.3.3) Fix Version/s: 1.5 Unless there is an objection, I will commit the changes to the 1.4 branch as well. Please don't. This is more a feature change than a bug fix, and IMHO shouldn't go into the branch. Let's target 1.5 with this change. Refactor DBMS support for JNDI datasources -- Key: JCR-1309 URL: https://issues.apache.org/jira/browse/JCR-1309 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-core Reporter: Andy Key Assignee: Thomas Mueller Fix For: 1.5 Our shop currently uses Oracle for most projects, most commonly in an application server (Tomcat, WebSphere, etc.), and use configured J2EE datasources. Unfortunately, many of the classes that fix quirks on specific DBMS force you to configure a JDBC connection (look at org.apache.jackrabbit.core.fs.db.OracleFileSystem for instance), which is a bad idea on an application server -- the application server should be managing resources like DB connections, etc. If you want to use an DbFileSystem based on an Oracle database, you can't use a datasource from a JNDI lookup. This in effect makes Jackrabbit unusable in clustered enterprise environments. It would be much better to refactor the current database support to separate the method that an implementation obtains its connection from its functionality. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1335) bad assumptions on QueryResult.getIterator() semantics in QueryResultNodeIteratorTest.testSkip()
bad assumptions on QueryResult.getIterator() semantics in QueryResultNodeIteratorTest.testSkip() Key: JCR-1335 URL: https://issues.apache.org/jira/browse/JCR-1335 Project: Jackrabbit Issue Type: Bug Components: jackrabbit-jcr-tests Reporter: Julian Reschke Assignee: Julian Reschke Priority: Minor testSkip() assumes that calling getIterator() a second time will return a new iterator of the same size. JSR-170 is silent on this. Forcing a server to implement this essantially means that the query result must be cached until there's no reference to QueryResult anymore. As this is a test of skip(), not getIterator(), the test should really refetch a new QueryResult in order to obtain a new iterator. (Note: The issue of the semantics of QueryResult.getIterator should be discussed by the JCR EG.) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1335) bad assumptions on QueryResult.getIterator() semantics in QueryResultNodeIteratorTest.testSkip()
[ https://issues.apache.org/jira/browse/JCR-1335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated JCR-1335: Attachment: JCR-1335.patch.txt bad assumptions on QueryResult.getIterator() semantics in QueryResultNodeIteratorTest.testSkip() Key: JCR-1335 URL: https://issues.apache.org/jira/browse/JCR-1335 Project: Jackrabbit Issue Type: Bug Components: jackrabbit-jcr-tests Reporter: Julian Reschke Assignee: Julian Reschke Priority: Minor Attachments: JCR-1335.patch.txt, mylyn-context.zip testSkip() assumes that calling getIterator() a second time will return a new iterator of the same size. JSR-170 is silent on this. Forcing a server to implement this essantially means that the query result must be cached until there's no reference to QueryResult anymore. As this is a test of skip(), not getIterator(), the test should really refetch a new QueryResult in order to obtain a new iterator. (Note: The issue of the semantics of QueryResult.getIterator should be discussed by the JCR EG.) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1335) bad assumptions on QueryResult.getIterator() semantics in QueryResultNodeIteratorTest.testSkip()
[ https://issues.apache.org/jira/browse/JCR-1335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated JCR-1335: Attachment: JCR-1335.patch.txt Proposed patch. bad assumptions on QueryResult.getIterator() semantics in QueryResultNodeIteratorTest.testSkip() Key: JCR-1335 URL: https://issues.apache.org/jira/browse/JCR-1335 Project: Jackrabbit Issue Type: Bug Components: jackrabbit-jcr-tests Reporter: Julian Reschke Assignee: Julian Reschke Priority: Minor Attachments: JCR-1335.patch.txt testSkip() assumes that calling getIterator() a second time will return a new iterator of the same size. JSR-170 is silent on this. Forcing a server to implement this essantially means that the query result must be cached until there's no reference to QueryResult anymore. As this is a test of skip(), not getIterator(), the test should really refetch a new QueryResult in order to obtain a new iterator. (Note: The issue of the semantics of QueryResult.getIterator should be discussed by the JCR EG.) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [OCM] Making the path field optional?
Christophe Lombart wrote: On Jan 21, 2008 3:06 PM, Carsten Ziegeler [EMAIL PROTECTED] wrote: Now, it's not a big deal to add the string property to my bean, but still it doesn't feel nice :) So the addition of insert(String path, Object object) and not requiring a path field when reading beans from jcr would be sufficient for my use case :) IMHO, supporting both solutions will add more confusion to the users. I would like to suggest to keep the current OCM API and the mandatory path attribute or remove the mandatory path attribute and refactor OCM API in order to add the path as argument of some methods. If I looked correctly there are only three methods which are problematic : insert, update, remove(Object). Now, insert can simply be changed by adding the path argument. So, this leaves us with update and remove, both using an Object - now this object should be an object that has been retrieved previously from the OCM, so perhaps we could use this fact for the implementation? Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
[jira] Commented: (JCR-1335) bad assumptions on QueryResult.getIterator() semantics in QueryResultNodeIteratorTest.testSkip()
[ https://issues.apache.org/jira/browse/JCR-1335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561062#action_12561062 ] Marcel Reutegger commented on JCR-1335: --- +1 for the patch bad assumptions on QueryResult.getIterator() semantics in QueryResultNodeIteratorTest.testSkip() Key: JCR-1335 URL: https://issues.apache.org/jira/browse/JCR-1335 Project: Jackrabbit Issue Type: Bug Components: jackrabbit-jcr-tests Reporter: Julian Reschke Assignee: Julian Reschke Priority: Minor Attachments: JCR-1335.patch.txt testSkip() assumes that calling getIterator() a second time will return a new iterator of the same size. JSR-170 is silent on this. Forcing a server to implement this essantially means that the query result must be cached until there's no reference to QueryResult anymore. As this is a test of skip(), not getIterator(), the test should really refetch a new QueryResult in order to obtain a new iterator. (Note: The issue of the semantics of QueryResult.getIterator should be discussed by the JCR EG.) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1335) bad assumptions on QueryResult.getIterator() semantics in QueryResultNodeIteratorTest.testSkip()
[ https://issues.apache.org/jira/browse/JCR-1335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated JCR-1335: Attachment: (was: mylyn-context.zip) bad assumptions on QueryResult.getIterator() semantics in QueryResultNodeIteratorTest.testSkip() Key: JCR-1335 URL: https://issues.apache.org/jira/browse/JCR-1335 Project: Jackrabbit Issue Type: Bug Components: jackrabbit-jcr-tests Reporter: Julian Reschke Assignee: Julian Reschke Priority: Minor Attachments: JCR-1335.patch.txt testSkip() assumes that calling getIterator() a second time will return a new iterator of the same size. JSR-170 is silent on this. Forcing a server to implement this essantially means that the query result must be cached until there's no reference to QueryResult anymore. As this is a test of skip(), not getIterator(), the test should really refetch a new QueryResult in order to obtain a new iterator. (Note: The issue of the semantics of QueryResult.getIterator should be discussed by the JCR EG.) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
AW: AW: Deadlock in XA Environment
hi marcel, i have opened a jira issue https://issues.apache.org/jira/browse/JCR-1334 and attached the logs please take a look at the logs thanks, claus -Ursprüngliche Nachricht- Von: Marcel Reutegger [mailto:[EMAIL PROTECTED] Gesendet: Montag, 21. Jänner 2008 11:09 An: dev@jackrabbit.apache.org Betreff: Re: AW: Deadlock in XA Environment Hi Claus, if you were using 1.4 you could extend the DefaultISMLocking class and add logging to the methods. e.g. log the thread name. then configure and use the new locking class in repository.xml. this would at least allow us to rule out (or prove) the different thread assumption. regards marcel KÖLL Claus wrote: hi marcel, ok thanks for the info. i think its a websphere specific featrure ;-) do you have any ideas what i have to test to find out what happens exactly ? BR, claus -Ursprüngliche Nachricht- Von: Marcel Reutegger [mailto:[EMAIL PROTECTED] Gesendet: Freitag, 18. Jänner 2008 11:03 An: dev@jackrabbit.apache.org Betreff: Re: Deadlock in XA Environment KÖLL Claus wrote: we have some time now jackrabbit (1.3) running in our pruduction environment but without xa enabled. We are running on websphere 5.1 and i have configured now a j2c resource adapter for jackrabbit. it works fine till i try to modify a node in the repository in a global transaction. if i only try a search everything works fine. i have taken a thread dump with the deadlock situation. what i can see comes the deadlock from the DefaultISMLocking$ReadLockImpl Class hope somebodycan help hmm, this looks strange. there is only one thread that is trying to downgrade its write lock. the only reason I can think of why this may block is that downgrade is called from a different thread than the initial write lock acquire. regards marcel
[jira] Updated: (JCR-1335) bad assumptions on QueryResult.getIterator() semantics in QueryResultNodeIteratorTest.testSkip()
[ https://issues.apache.org/jira/browse/JCR-1335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated JCR-1335: Attachment: (was: JCR-1335.patch.txt) bad assumptions on QueryResult.getIterator() semantics in QueryResultNodeIteratorTest.testSkip() Key: JCR-1335 URL: https://issues.apache.org/jira/browse/JCR-1335 Project: Jackrabbit Issue Type: Bug Components: jackrabbit-jcr-tests Reporter: Julian Reschke Assignee: Julian Reschke Priority: Minor Attachments: JCR-1335.patch.txt testSkip() assumes that calling getIterator() a second time will return a new iterator of the same size. JSR-170 is silent on this. Forcing a server to implement this essantially means that the query result must be cached until there's no reference to QueryResult anymore. As this is a test of skip(), not getIterator(), the test should really refetch a new QueryResult in order to obtain a new iterator. (Note: The issue of the semantics of QueryResult.getIterator should be discussed by the JCR EG.) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1330) repository.xml DTD doesn't allow DataStore element
[ https://issues.apache.org/jira/browse/JCR-1330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561096#action_12561096 ] Esteban Franqueiro commented on JCR-1330: - Shouldn't the org.jackrabbit.useDataStore system property be documented in the wiki too? Because although in RepositoryImpl's constructor it is asserted true in case the data store config is not null, in InternalValue it's used regardless of the case. So if the data store is not configured but the property is true (which is it's default value) then the processing in InternalValue is wrong. IMHO, this property should be removed altogether. Regards repository.xml DTD doesn't allow DataStore element Key: JCR-1330 URL: https://issues.apache.org/jira/browse/JCR-1330 Project: Jackrabbit Issue Type: Bug Components: config, docs Affects Versions: 1.4 Reporter: Eric Norman Priority: Minor Attachments: repository-1.4.dtd The repository.xml DTD at http://jackrabbit.apache.org/dtd/repository-1.4.dtd conflicts with the instructions in the wiki page at http://wiki.apache.org/jackrabbit/DataStore Adding the DataStore element as specified in the wiki page violates the DTD. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
NGP: Content- vs. location-addressed storage
Hi, The current jackrabbit-ngp sandbox contains two storage engines, journal and store, that are basically similar in that both store immutable binary records and that the storage engine is in charge of assigning identifiers to stored records. I think that this general storage model works very well with the NGP architecture as currently outlined. The crucial difference between the two engines is in how they organize the records and what kind of identifiers they use. The journal engine stores records in an append-only journal file (with a few exceptions for very small and very large records) and uses the location of the record within the journal as the record identifier. The store engine stores records as individual files named and identified using the SHA-1 hash of the record. The location-based addressing used by the journal engine is more performance- and space-optimized as the identifiers are compact (64 bits in current version) and accessing any record is at most a single disk read away. The engine also has good locality of reference as content created or modified in the same revision will be stored on adjacent disk locations. The content-based addressing used by the store engine is easier to implement, maps well to a distributed/clustered model, and is very easy to cache. However, the identifiers are larger (160 bits in current version) and accessing a record requires at least one index lookup on normal hardware. The engine will also automatically optimize storage of duplicate content even if no copy or versioning operations were used to create the duplicates. Both models have their benefits and drawbacks, and I haven't yet come to a conclusion which (if either) would be the best storage model for NGP. In this post I wanted to outline my current thinking on the matter and open up discussion for any comments or insights I'm probably missing. BR, Jukka Zitting
Re: failing tests
Hi, On Jan 21, 2008 5:01 PM, Julian Reschke [EMAIL PROTECTED] wrote: 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. +1 - is anybody looking at these? Not sure. I looked at them while preparing 1.4, but didn't have the cycles to come up with anything substantial so I just cut corners and disabled them for 1.4 as mentioned on JCR-1293. A more proper approach would have been to file real bug reports for the issues and have them recorded as known issues in the 1.4 release notes. - do we have JIRA issues (except JCR-1293 which seems to be something different)? Not that I know of. We should add a bug report about the failing tests after which it's OK to disable the tests as known issues. I'll do that tomorrow unless anyone beats me to it. BR, Jukka Zitting
Re: [OCM] Making the path field optional?
A path is pretty fundamental to jcr, not having one would be like not having a primary key for a bean retrieved from an orm solution. As most orm's require beans to specify a pk I do not see the problem with ocm doing the same. Trying to work around this I think would lead the ocm to making all sorts of assumptions including all objects are created via the ocm when there are times when working (esp. it would seem with client/server stuff) that the object may not have been originally retrieved via the ocm (I'm thinking value object patterns). -paddy
[jira] Assigned: (JCR-1330) repository.xml DTD doesn't allow DataStore element
[ https://issues.apache.org/jira/browse/JCR-1330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller reassigned JCR-1330: --- Assignee: Thomas Mueller repository.xml DTD doesn't allow DataStore element Key: JCR-1330 URL: https://issues.apache.org/jira/browse/JCR-1330 Project: Jackrabbit Issue Type: Bug Components: config, docs Affects Versions: 1.4 Reporter: Eric Norman Assignee: Thomas Mueller Priority: Minor Attachments: repository-1.4.dtd The repository.xml DTD at http://jackrabbit.apache.org/dtd/repository-1.4.dtd conflicts with the instructions in the wiki page at http://wiki.apache.org/jackrabbit/DataStore Adding the DataStore element as specified in the wiki page violates the DTD. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1330) repository.xml DTD doesn't allow DataStore element
[ https://issues.apache.org/jira/browse/JCR-1330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561243#action_12561243 ] Thomas Mueller commented on JCR-1330: - Hi Esteban, The system property org.jackrabbit.useDataStore is a 'kill switch' to disable the new code in InternalValue and do everything as before (not using BLOBInMemory and so on). This property should never be switched off, except if there is a problem with the data store, and you want to check if the new code is to blame. I don't think it is needed any longer, I will remove this property (and the old code) in the trunk. repository.xml DTD doesn't allow DataStore element Key: JCR-1330 URL: https://issues.apache.org/jira/browse/JCR-1330 Project: Jackrabbit Issue Type: Bug Components: config, docs Affects Versions: 1.4 Reporter: Eric Norman Assignee: Thomas Mueller Priority: Minor Attachments: repository-1.4.dtd The repository.xml DTD at http://jackrabbit.apache.org/dtd/repository-1.4.dtd conflicts with the instructions in the wiki page at http://wiki.apache.org/jackrabbit/DataStore Adding the DataStore element as specified in the wiki page violates the DTD. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-1330) repository.xml DTD doesn't allow DataStore element
[ https://issues.apache.org/jira/browse/JCR-1330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller resolved JCR-1330. - Resolution: Fixed DTD committed in revision 614128 (trunk) and 614129 (branch 1.4). repository.xml DTD doesn't allow DataStore element Key: JCR-1330 URL: https://issues.apache.org/jira/browse/JCR-1330 Project: Jackrabbit Issue Type: Bug Components: config, docs Affects Versions: 1.4 Reporter: Eric Norman Assignee: Thomas Mueller Priority: Minor Attachments: repository-1.4.dtd The repository.xml DTD at http://jackrabbit.apache.org/dtd/repository-1.4.dtd conflicts with the instructions in the wiki page at http://wiki.apache.org/jackrabbit/DataStore Adding the DataStore element as specified in the wiki page violates the DTD. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [OCM] Making the path field optional?
Padraic I. Hannon wrote: A path is pretty fundamental to jcr, not having one would be like not having a primary key for a bean retrieved from an orm solution. As most orm's require beans to specify a pk I do not see the problem with ocm doing the same. Trying to work around this I think would lead the ocm to making all sorts of assumptions including all objects are created via the ocm when there are times when working (esp. it would seem with client/server stuff) that the object may not have been originally retrieved via the ocm (I'm thinking value object patterns). Yes, I more or less agree, but :) I can use ORM without mapping the PK, for example in just reading use cases or I can even add new objects to the database if the PK is auto generated. Updating and removing are the things that do not work, but that's fine for me :) In addition I'm not sure if the analogy to a database really fits, in JCR the path is some kind of pk, but depending on your content model and your use cases, the path of an object can change (while a pk in a database never changes). Definitly a uuid would be the ultimate pk, but obviously you don't want to force to have a uuid for each and every node. So as a first step I propose to change the implementation of the OCM to allow the reading use case even if the path field is not mapped (to be honest I haven't checked if this is not working right now, perhaps it already works, so we don't have to change it). Second step would be to introduce an insert(String path, Object) method to add an object at the given path. In general, and I just talked with Felix about this offline, it would be interesting/nice to have an interface that does not rely on a path (string) as the input for methods, but on a Node. In many use cases I already have the Node where I want to query or insert objects. So this could simplify the handling. Perhaps it would also be worth to split or minimize the current OCM interface as things like versioning are not required for most use cases. WDYT? Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
