Re: is XPath possible on property value?
Hi, On 2/19/07, Malligarjunan Sidduraj [EMAIL PROTECTED] wrote: Can we apply XPath on a particular Property value which is a type of application/xml. We can do XPath on JCR tree Hierarchy that I know. Ex : //[EMAIL PROTECTED] = 'wsdl' In that above example I want apply the XPath on Property value? Like //[EMAIL PROTECTED] = (XPATH Query) or some XPath Query on content? No, that's not possible. If possible, you might want to consider modifying your content model so that instead of storing XML in your properties you expand the content into normal JCR nodes and properties. BR, Jukka Zitting
Re: Errors with new cluster feature
Hi Miguel, writing to the journal log file should only be possible after having obtained an exclusive lock on the global revision file (R), located in the same directory as the journal log file (L). The exact sequence of operations is as follows: - exclusive lock is obtained on R - journal entry appended to log file L - revision counter is updated in R - exclusive lock is released on R This should rule out simultaneous writes to the log file L. Are you easily able to reproduce this issue, starting with an empty journal file? I could eliminate some small issues in the not yet released 1.2.2 branch, but I still would be very glad to know more about how and when this problem arises... Kind regards Dominique On 2/14/07, Miguel Ángel Jiménez [EMAIL PROTECTED] wrote: Hi, I'm trying the new cluster feature of Jackrabbit 1.2.1 and found some issues. Using FileJournal to synchronize state between instances, we are experiencing some errors that point to a possible corruption of the log file: 2007-02-14 10:34:00,911 ERROR [org.apache.jackrabbit.core.RepositoryImpl] Unable to start clustered node, forcing shutdown... org.apache.jackrabbit.core.cluster.JournalException: Unable to iterate over modified records: malformed input around byte 178 at org.apache.jackrabbit.core.cluster.FileJournal.sync(FileJournal.java :313) at org.apache.jackrabbit.core.cluster.ClusterNode.sync(ClusterNode.java :217) at org.apache.jackrabbit.core.cluster.ClusterNode.start(ClusterNode.java :164) at org.apache.jackrabbit.core.RepositoryImpl.init(RepositoryImpl.java :308) at org.apache.jackrabbit.core.RepositoryImpl.create(RepositoryImpl.java :573) at org.apache.jackrabbit.core.jndi.BindableRepository.createRepository( BindableRepository.java:174) at org.apache.jackrabbit.core.jndi.BindableRepository.init( BindableRepository.java:138) at org.apache.jackrabbit.core.jndi.BindableRepository.create( BindableRepository.java:125) at org.apache.jackrabbit.core.jndi.BindableRepositoryFactory.createInstance( BindableRepositoryFactory.java:59) at org.apache.jackrabbit.core.jndi.RegistryHelper.registerRepository( RegistryHelper.java:60) at com.germinus.xpression.cms.jcr.EmbeddedRepositoryFactory.getRepository( EmbeddedRepositoryFactory.java:50) at com.germinus.xpression.cms.jcr.JCRUtil.initRepository(JCRUtil.java :243) ... Caused by: java.io.UTFDataFormatException: malformed input around byte 178 at java.io.DataInputStream.readUTF(DataInputStream.java:639) at org.apache.jackrabbit.core.cluster.FileRecord.readCreator( FileRecord.java:242) at org.apache.jackrabbit.core.cluster.FileRecord.init(FileRecord.java :106) at org.apache.jackrabbit.core.cluster.FileRecordCursor.next( FileRecordCursor.java:101) at org.apache.jackrabbit.core.cluster.FileJournal.sync(FileJournal.java :303) ... 130 more Perhaps I'm wrong but looks like two instances are writing the file simultaneously. Is this behaviour known or misconfiguration? The journal log is placed in a shared folder on a Linux machine and exported by SAMBA to the instances. I have tested the lock file capabilities of the shared filesystem and they are ok. -- Miguel.
Re: [VOTE] Release Apache Jackrabbit 1.2.2
On 2/16/07, Jukka Zitting [EMAIL PROTECTED] wrote: Please vote on releasing these packages as Apache Jackrabbit 1.2.2. a non binding +1 from a user, hoping that devs will cast their positive vote soon ;) cheers fabrizio
RE: is XPath possible on property value?
Hi, We can search content based on the xpath in an xml file. If we import an xml under a particular node, you could make xpath search. For example consider the below xml Addresses Address NameOdyssey/Name Number50/Number AreaAdyar/Area CityChennai/City StateTN/State CountryIndia/Country /Address /Addresses If we import this under the node called 'ShoppingCentre', we could execute the query with the xpath '//ShoppingCentre/Addresses/Address/Name/jcr:xmltext' to get the Name node. I think Jukka has also meant the same. Regards, Nithya Mani Senior Developer, webMethods [EMAIL PROTECTED] IM: nithya_infravio (Yahoo) -Original Message- From: Jukka Zitting [mailto:[EMAIL PROTECTED] Sent: Monday, February 19, 2007 2:23 PM To: dev@jackrabbit.apache.org Subject: Re: is XPath possible on property value? Hi, On 2/19/07, Malligarjunan Sidduraj [EMAIL PROTECTED] wrote: Can we apply XPath on a particular Property value which is a type of application/xml. We can do XPath on JCR tree Hierarchy that I know. Ex : //[EMAIL PROTECTED] = 'wsdl' In that above example I want apply the XPath on Property value? Like //[EMAIL PROTECTED] = (XPATH Query) or some XPath Query on content? No, that's not possible. If possible, you might want to consider modifying your content model so that instead of storing XML in your properties you expand the content into normal JCR nodes and properties. BR, Jukka Zitting
Re: [VOTE] Release Apache Jackrabbit 1.2.2
On 2/16/07, Jukka Zitting [EMAIL PROTECTED] wrote: Please vote on releasing these packages as Apache Jackrabbit 1.2.2. +1 Release the packages as Apache Jackrabbit 1.2.2 cheers stefan
[jira] Created: (JCR-748) DatabaseFileSystem fails with Oracle database
DatabaseFileSystem fails with Oracle database - Key: JCR-748 URL: https://issues.apache.org/jira/browse/JCR-748 Project: Jackrabbit Issue Type: Bug Components: core Environment: JackRabbit 1.2.1 with a DatabaseFileSystem using an Oracle database Reporter: Martijn Hendriks The initialization of the repository fails because Oracle seems to convert empty strings to null values. This gives a problem as shown below. A possible solution might be to adjust the oracle.ddl in such a way that the FSENTRY_NAME column can contain null values. I don't know, however, whether this affects the rest of the persistence scheme. Feb 19, 2007 12:28:24 PM org.apache.jackrabbit.core.fs.db.DatabaseFileSystem createDeepFolder SEVERE: failed to create folder entry: / java.sql.SQLException: ORA-01400: cannot insert NULL into (MARTIJNH.WM9_REPOSITORY_FS_FSENTRY.FSENTRY_NAME) at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:187) at oracle.jdbc.ttc7.TTIoer.processError(TTIoer.java:241) at oracle.jdbc.ttc7.Oall7.receive(Oall7.java:543) at oracle.jdbc.ttc7.TTC7Protocol.doOall7(TTC7Protocol.java:1477) at oracle.jdbc.ttc7.TTC7Protocol.parseExecuteFetch(TTC7Protocol.java:888) at oracle.jdbc.driver.OracleStatement.executeNonQuery(OracleStatement.java:2030) at oracle.jdbc.driver.OracleStatement.doExecuteOther(OracleStatement.java:1950) at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:2591) at oracle.jdbc.driver.OraclePreparedStatement.executeUpdate(OraclePreparedStatement.java:452) at oracle.jdbc.driver.OraclePreparedStatement.execute(OraclePreparedStatement.java:526) at org.apache.jackrabbit.core.fs.db.DatabaseFileSystem.executeStmt(DatabaseFileSystem.java:1061) at org.apache.jackrabbit.core.fs.db.DatabaseFileSystem.createDeepFolder(DatabaseFileSystem.java:1370) at org.apache.jackrabbit.core.fs.db.DatabaseFileSystem.verifyRootExists(DatabaseFileSystem.java:1347) at org.apache.jackrabbit.core.fs.db.DatabaseFileSystem.init(DatabaseFileSystem.java:190) at org.apache.jackrabbit.core.config.FileSystemConfig.createFileSystem(FileSystemConfig.java:47) at org.apache.jackrabbit.core.RepositoryImpl.init(RepositoryImpl.java:239) at org.apache.jackrabbit.core.RepositoryImpl.create(RepositoryImpl.java:588) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-748) DatabaseFileSystem fails with Oracle database
[ https://issues.apache.org/jira/browse/JCR-748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12474150 ] Martijn Hendriks commented on JCR-748: -- I just tried to adjuste the oracle.ddl, but this still gives an error: the unique index constraint is violated. This happens as follows: - The DatabaseFileSystem.init() method calls verifyRootExists, which creates en entry for the root path / and name (which is converted to null). - Then RepositoryImplinit calls createDeepFolder for /meta. This calls the exists method for the root path / (line 1363 of the DatabaseFileSystem), and this method surprisingly returns false, which triggers the constraint violation. So it seems that handling null and values with Oracle is not so easy unfortunately... DatabaseFileSystem fails with Oracle database - Key: JCR-748 URL: https://issues.apache.org/jira/browse/JCR-748 Project: Jackrabbit Issue Type: Bug Components: core Environment: JackRabbit 1.2.1 with a DatabaseFileSystem using an Oracle database Reporter: Martijn Hendriks The initialization of the repository fails because Oracle seems to convert empty strings to null values. This gives a problem as shown below. A possible solution might be to adjust the oracle.ddl in such a way that the FSENTRY_NAME column can contain null values. I don't know, however, whether this affects the rest of the persistence scheme. Feb 19, 2007 12:28:24 PM org.apache.jackrabbit.core.fs.db.DatabaseFileSystem createDeepFolder SEVERE: failed to create folder entry: / java.sql.SQLException: ORA-01400: cannot insert NULL into (MARTIJNH.WM9_REPOSITORY_FS_FSENTRY.FSENTRY_NAME) at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:187) at oracle.jdbc.ttc7.TTIoer.processError(TTIoer.java:241) at oracle.jdbc.ttc7.Oall7.receive(Oall7.java:543) at oracle.jdbc.ttc7.TTC7Protocol.doOall7(TTC7Protocol.java:1477) at oracle.jdbc.ttc7.TTC7Protocol.parseExecuteFetch(TTC7Protocol.java:888) at oracle.jdbc.driver.OracleStatement.executeNonQuery(OracleStatement.java:2030) at oracle.jdbc.driver.OracleStatement.doExecuteOther(OracleStatement.java:1950) at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:2591) at oracle.jdbc.driver.OraclePreparedStatement.executeUpdate(OraclePreparedStatement.java:452) at oracle.jdbc.driver.OraclePreparedStatement.execute(OraclePreparedStatement.java:526) at org.apache.jackrabbit.core.fs.db.DatabaseFileSystem.executeStmt(DatabaseFileSystem.java:1061) at org.apache.jackrabbit.core.fs.db.DatabaseFileSystem.createDeepFolder(DatabaseFileSystem.java:1370) at org.apache.jackrabbit.core.fs.db.DatabaseFileSystem.verifyRootExists(DatabaseFileSystem.java:1347) at org.apache.jackrabbit.core.fs.db.DatabaseFileSystem.init(DatabaseFileSystem.java:190) at org.apache.jackrabbit.core.config.FileSystemConfig.createFileSystem(FileSystemConfig.java:47) at org.apache.jackrabbit.core.RepositoryImpl.init(RepositoryImpl.java:239) at org.apache.jackrabbit.core.RepositoryImpl.create(RepositoryImpl.java:588) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] Release Apache Jackrabbit 1.2.2
+1 Release the packages as Apache Jackrabbit 1.2.2 regards, toby On 2/16/07, Jukka Zitting [EMAIL PROTECTED] wrote: Hi, I have posted a candidate for the Apache Jackrabbit 1.2.2 release at http://people.apache.org/~jukka/jackrabbit/1.2.2/ See the included RELEASE-NOTES.txt file for details on release contents and latest changes. The release was made from the 1.2 branch after merging all the bug fixes listed in the release notes. Note that even though this is a patch release, I've included two clustering changes that are not strictly bug fixes on the grounds that the clustering feature is still in beta level. Please vote on releasing these packages as Apache Jackrabbit 1.2.2. The vote is open for the next 72 hours, and only votes from Jackrabbit committers are binding. The vote passes if at least three +1 votes are cast. [ ] +1 Release the packages as Apache Jackrabbit 1.2.2 [ ] -1 Do not release the packages because... BR, Jukka Zitting -- - [EMAIL PROTECTED] --- Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel T +41 61 226 98 98, F +41 61 226 98 97 --- http://www.day.com ---
Re: [VOTE] Release Apache Jackrabbit 1.2.2
Jukka Zitting wrote: Please vote on releasing these packages as Apache Jackrabbit 1.2.2. The vote is open for the next 72 hours, and only votes from Jackrabbit committers are binding. The vote passes if at least three +1 votes are cast. +1 Release the packages as Apache Jackrabbit 1.2.2 regards marcel
[jira] Resolved: (JCR-748) DatabaseFileSystem fails with Oracle database
[ https://issues.apache.org/jira/browse/JCR-748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Guggisberg resolved JCR-748. --- Resolution: Invalid there's a specialized implementation for oracle which addresses oracle's peculiar empty string handling: o.a.j.c.fs.db.OracleFileSystem DatabaseFileSystem fails with Oracle database - Key: JCR-748 URL: https://issues.apache.org/jira/browse/JCR-748 Project: Jackrabbit Issue Type: Bug Components: core Environment: JackRabbit 1.2.1 with a DatabaseFileSystem using an Oracle database Reporter: Martijn Hendriks The initialization of the repository fails because Oracle seems to convert empty strings to null values. This gives a problem as shown below. A possible solution might be to adjust the oracle.ddl in such a way that the FSENTRY_NAME column can contain null values. I don't know, however, whether this affects the rest of the persistence scheme. Feb 19, 2007 12:28:24 PM org.apache.jackrabbit.core.fs.db.DatabaseFileSystem createDeepFolder SEVERE: failed to create folder entry: / java.sql.SQLException: ORA-01400: cannot insert NULL into (MARTIJNH.WM9_REPOSITORY_FS_FSENTRY.FSENTRY_NAME) at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:187) at oracle.jdbc.ttc7.TTIoer.processError(TTIoer.java:241) at oracle.jdbc.ttc7.Oall7.receive(Oall7.java:543) at oracle.jdbc.ttc7.TTC7Protocol.doOall7(TTC7Protocol.java:1477) at oracle.jdbc.ttc7.TTC7Protocol.parseExecuteFetch(TTC7Protocol.java:888) at oracle.jdbc.driver.OracleStatement.executeNonQuery(OracleStatement.java:2030) at oracle.jdbc.driver.OracleStatement.doExecuteOther(OracleStatement.java:1950) at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:2591) at oracle.jdbc.driver.OraclePreparedStatement.executeUpdate(OraclePreparedStatement.java:452) at oracle.jdbc.driver.OraclePreparedStatement.execute(OraclePreparedStatement.java:526) at org.apache.jackrabbit.core.fs.db.DatabaseFileSystem.executeStmt(DatabaseFileSystem.java:1061) at org.apache.jackrabbit.core.fs.db.DatabaseFileSystem.createDeepFolder(DatabaseFileSystem.java:1370) at org.apache.jackrabbit.core.fs.db.DatabaseFileSystem.verifyRootExists(DatabaseFileSystem.java:1347) at org.apache.jackrabbit.core.fs.db.DatabaseFileSystem.init(DatabaseFileSystem.java:190) at org.apache.jackrabbit.core.config.FileSystemConfig.createFileSystem(FileSystemConfig.java:47) at org.apache.jackrabbit.core.RepositoryImpl.init(RepositoryImpl.java:239) at org.apache.jackrabbit.core.RepositoryImpl.create(RepositoryImpl.java:588) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-748) DatabaseFileSystem fails with Oracle database
[ https://issues.apache.org/jira/browse/JCR-748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12474173 ] Martijn Hendriks commented on JCR-748: -- I see now ; I'm sorry for the unnecessary post... DatabaseFileSystem fails with Oracle database - Key: JCR-748 URL: https://issues.apache.org/jira/browse/JCR-748 Project: Jackrabbit Issue Type: Bug Components: core Environment: JackRabbit 1.2.1 with a DatabaseFileSystem using an Oracle database Reporter: Martijn Hendriks The initialization of the repository fails because Oracle seems to convert empty strings to null values. This gives a problem as shown below. A possible solution might be to adjust the oracle.ddl in such a way that the FSENTRY_NAME column can contain null values. I don't know, however, whether this affects the rest of the persistence scheme. Feb 19, 2007 12:28:24 PM org.apache.jackrabbit.core.fs.db.DatabaseFileSystem createDeepFolder SEVERE: failed to create folder entry: / java.sql.SQLException: ORA-01400: cannot insert NULL into (MARTIJNH.WM9_REPOSITORY_FS_FSENTRY.FSENTRY_NAME) at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:187) at oracle.jdbc.ttc7.TTIoer.processError(TTIoer.java:241) at oracle.jdbc.ttc7.Oall7.receive(Oall7.java:543) at oracle.jdbc.ttc7.TTC7Protocol.doOall7(TTC7Protocol.java:1477) at oracle.jdbc.ttc7.TTC7Protocol.parseExecuteFetch(TTC7Protocol.java:888) at oracle.jdbc.driver.OracleStatement.executeNonQuery(OracleStatement.java:2030) at oracle.jdbc.driver.OracleStatement.doExecuteOther(OracleStatement.java:1950) at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:2591) at oracle.jdbc.driver.OraclePreparedStatement.executeUpdate(OraclePreparedStatement.java:452) at oracle.jdbc.driver.OraclePreparedStatement.execute(OraclePreparedStatement.java:526) at org.apache.jackrabbit.core.fs.db.DatabaseFileSystem.executeStmt(DatabaseFileSystem.java:1061) at org.apache.jackrabbit.core.fs.db.DatabaseFileSystem.createDeepFolder(DatabaseFileSystem.java:1370) at org.apache.jackrabbit.core.fs.db.DatabaseFileSystem.verifyRootExists(DatabaseFileSystem.java:1347) at org.apache.jackrabbit.core.fs.db.DatabaseFileSystem.init(DatabaseFileSystem.java:190) at org.apache.jackrabbit.core.config.FileSystemConfig.createFileSystem(FileSystemConfig.java:47) at org.apache.jackrabbit.core.RepositoryImpl.init(RepositoryImpl.java:239) at org.apache.jackrabbit.core.RepositoryImpl.create(RepositoryImpl.java:588) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
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
[jira] Assigned: (JCR-741) Handling of multiple residual prop defs in EffectiveNodeTypeImpl
[ https://issues.apache.org/jira/browse/JCR-741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke reassigned JCR-741: -- Assignee: Julian Reschke Handling of multiple residual prop defs in EffectiveNodeTypeImpl Key: JCR-741 URL: https://issues.apache.org/jira/browse/JCR-741 Project: Jackrabbit Issue Type: Bug Components: SPI Reporter: Julian Reschke Assigned To: Julian Reschke Priority: Minor org.apache.jackrabbit.jcr2spi.nodetype.EffectiveNodeTypeImpl currently rejects multiple residual property definitions, if they do not differ in getMultiple(). In fact, it should accept all combinations, so differing values for getOnParentVersionAction and other aspects should be accepted as well. See JSR 170, 6.7.8: For purposes of the above, the notion of two definitions having the same name does not apply to two residual definitions. Two (or more) residual property or child node definitions with differing subattributes must be permitted to co-exist in the same effective node type. They are interpreted as disjunctive (ORed) options. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-741) Handling of multiple residual prop defs in EffectiveNodeTypeImpl
[ https://issues.apache.org/jira/browse/JCR-741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12474224 ] Julian Reschke commented on JCR-741: Fixing this properly requires several changes. (1) Do not consider multiple residual prop defs when they differ in their OnParentVersionAction value, (2) Rewrite the transient layer so that in presence of multiple residuals it will pick the right one (such as for Property.getDefinition()). As (1) is simple and allows my SPI stack to continue to work for now, I'll fix that right away. For (2), I'd recommend to change getMatchingPropDef () as below: - only one method - each of the definition's aspects can be marked as don't care (by changing int-Integer, boolean-Boolean and allowing null values here). Feedback appreciated. Handling of multiple residual prop defs in EffectiveNodeTypeImpl Key: JCR-741 URL: https://issues.apache.org/jira/browse/JCR-741 Project: Jackrabbit Issue Type: Bug Components: SPI Reporter: Julian Reschke Assigned To: Julian Reschke Priority: Minor org.apache.jackrabbit.jcr2spi.nodetype.EffectiveNodeTypeImpl currently rejects multiple residual property definitions, if they do not differ in getMultiple(). In fact, it should accept all combinations, so differing values for getOnParentVersionAction and other aspects should be accepted as well. See JSR 170, 6.7.8: For purposes of the above, the notion of two definitions having the same name does not apply to two residual definitions. Two (or more) residual property or child node definitions with differing subattributes must be permitted to co-exist in the same effective node type. They are interpreted as disjunctive (ORed) options. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] Release Apache Jackrabbit 1.2.2
Hi Jukka, I was just pointed to some clustering issue, occurring with simultaneous processes that add/delete children on the same parent node. I was able to identify the source of this error and to fix it, and I would be very glad to include this fix in the upcoming 1.2.2 release. Could you defer the release for 1 or 2 days, or is it already too late? Cheers Dominique On 2/16/07, Jukka Zitting [EMAIL PROTECTED] wrote: Hi, I have posted a candidate for the Apache Jackrabbit 1.2.2 release at http://people.apache.org/~jukka/jackrabbit/1.2.2/ See the included RELEASE-NOTES.txt file for details on release contents and latest changes. The release was made from the 1.2 branch after merging all the bug fixes listed in the release notes. Note that even though this is a patch release, I've included two clustering changes that are not strictly bug fixes on the grounds that the clustering feature is still in beta level. Please vote on releasing these packages as Apache Jackrabbit 1.2.2. The vote is open for the next 72 hours, and only votes from Jackrabbit committers are binding. The vote passes if at least three +1 votes are cast. [ ] +1 Release the packages as Apache Jackrabbit 1.2.2 [ ] -1 Do not release the packages because... BR, Jukka Zitting
Re: [VOTE] Release Apache Jackrabbit 1.2.2
Hi, On 2/19/07, Dominique Pfister [EMAIL PROTECTED] wrote: I was just pointed to some clustering issue, occurring with simultaneous processes that add/delete children on the same parent node. I was able to identify the source of this error and to fix it, and I would be very glad to include this fix in the upcoming 1.2.2 release. Could you defer the release for 1 or 2 days, or is it already too late? Too late, unless the issue is a critical enough to justify voting -1 in the ongoing release vote. I'm planning to release 1.3 already in March, but if there's demand to get a fix for this issue out already before that, then an earlier 1.2.3 patch release is definitely possible. BR, Jukka Zitting
[jira] Updated: (JCR-750) [Patch] Adding history, tab completion, status info command and masked password input for jcr-commands
[ https://issues.apache.org/jira/browse/JCR-750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Klimetschek updated JCR-750: -- Attachment: jcr-commands-add-history-tabcompletion-status.patch A patch including all mentioned features. [Patch] Adding history, tab completion, status info command and masked password input for jcr-commands -- Key: JCR-750 URL: https://issues.apache.org/jira/browse/JCR-750 Project: Jackrabbit Issue Type: New Feature Components: contrib PMs Affects Versions: 1.1 Environment: Tested under Mac OS 10.4.8 Reporter: Alexander Klimetschek Priority: Minor Attachments: jcr-commands-add-history-tabcompletion-status.patch I have created this patch which improves the usability of the interactive jcr command line client. It uses jline (http://jline.sourceforge.net) for the input, which gives history, tab completion and masked password input. Tab completion completes on available commands and on the jcr children of the current node for command arguments. The login command now asks for the password if none is given, this uses the advanced password masking feature of jline to avoid the echoing of the password while typing (which is not possible using standard java System.in). I also changed the Maven 2 pom to version 1.3-SNAPSHOT to compile with the current jackrabbit trunk and to include a manifest file with the correct starter class. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
DBConfiguration at runtime?
All, Can I configure the db info at the runtime? Any API available in JCR/Jackrabbit? Is there any other way available to configure the db info rather than configuring in repository.xml Thanks Malligarjunan S.
