JCR mapping
I'm going to continue the jcr mapping integration into Jackrabbit. Do we have to support maven 1 or only m2 is good ? I think it is possible to support both in the same project. I plan to refactor the pck name, is it ok to use : org.apache.jackrabbit.ocm br, Christophe
Re: JCR mapping
Hi Christophe, Welcome aboard ! IMHO we should drop m1 support for our development. Supporting both, will in my experience not work in the long run. For deployment this is another story, and AFAIK Jukka has done great work in supporting deployment to M1 repositories. On 4/26/07, Christophe Lombart [EMAIL PROTECTED] wrote: I plan to refactor the pck name, is it ok to use : org.apache.jackrabbit.ocm Fine for me. Regards Felix
[jira] Created: (JCR-889) Add bundle support for PostgreSQL
Add bundle support for PostgreSQL - Key: JCR-889 URL: https://issues.apache.org/jira/browse/JCR-889 Project: Jackrabbit Issue Type: New Feature Affects Versions: 1.3 Reporter: Miguel Angel Jiménez Sampedro Priority: Minor The class DbNameIndex does not work with this RDBMS since the RETURN_GENERATED_KEYS JDBC feature is not implemented in current PostgreSQL drivers. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-889) Add bundle support for PostgreSQL
[ https://issues.apache.org/jira/browse/JCR-889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Miguel Angel Jiménez Sampedro updated JCR-889: -- Attachment: postgresql.ddl This is the starting ddl I'm using on my tests with PostgreSQL. Add bundle support for PostgreSQL - Key: JCR-889 URL: https://issues.apache.org/jira/browse/JCR-889 Project: Jackrabbit Issue Type: New Feature Affects Versions: 1.3 Reporter: Miguel Angel Jiménez Sampedro Priority: Minor Attachments: postgresql.ddl The class DbNameIndex does not work with this RDBMS since the RETURN_GENERATED_KEYS JDBC feature is not implemented in current PostgreSQL drivers. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-888) javax.jcr.NamespaceException: : is not a registered namespace uri
[ https://issues.apache.org/jira/browse/JCR-888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12491977 ] Stefan Guggisberg commented on JCR-888: --- i tested with the FirstHop sample found here: http://jackrabbit.apache.org/doc/hops/FirstHop.java i was unable to reproduce the issue. could you please attach the soruce code of your FirstHops class? javax.jcr.NamespaceException: : is not a registered namespace uri - Key: JCR-888 URL: https://issues.apache.org/jira/browse/JCR-888 Project: Jackrabbit Issue Type: Bug Components: core Affects Versions: 1.2.3, 1.3 Environment: Windows XP, Eclipse 3.1, JRE 1.4.2 and 5.0 Reporter: Dave Erickson Using the first hops with both versions 1.2.3 and 1.3, the repository is created successfully the first time it is run. Subsequent attempts to login result in a javax.jcr.NamespaceException. DEBUG - Initializing transient repository INFO - Starting repository... INFO - LocalFileSystem initialized at path repository\repository Exception in thread main javax.jcr.NamespaceException: : is not a registered namespace uri. at org.apache.jackrabbit.core.NamespaceRegistryImpl.getPrefix(NamespaceRegistryImpl.java:538) at org.apache.jackrabbit.core.nodetype.NodeTypeRegistry.checkNamespace(NodeTypeRegistry.java:1292) at org.apache.jackrabbit.core.nodetype.NodeTypeRegistry.validateNodeTypeDef(NodeTypeRegistry.java:1415) at org.apache.jackrabbit.core.nodetype.NodeTypeRegistry.internalRegister(NodeTypeRegistry.java:1221) at org.apache.jackrabbit.core.nodetype.NodeTypeRegistry.init(NodeTypeRegistry.java:671) at org.apache.jackrabbit.core.nodetype.NodeTypeRegistry.create(NodeTypeRegistry.java:118) at org.apache.jackrabbit.core.RepositoryImpl.createNodeTypeRegistry(RepositoryImpl.java:571) at org.apache.jackrabbit.core.RepositoryImpl.init(RepositoryImpl.java:262) at org.apache.jackrabbit.core.RepositoryImpl.create(RepositoryImpl.java:584) at org.apache.jackrabbit.core.TransientRepository$2.getRepository(TransientRepository.java:245) at org.apache.jackrabbit.core.TransientRepository.startRepository(TransientRepository.java:265) at org.apache.jackrabbit.core.TransientRepository.login(TransientRepository.java:333) at org.apache.jackrabbit.core.TransientRepository.login(TransientRepository.java:388) at testing.FirstHops.main(FirstHops.java:24) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-862) unsynchronized access on 'itemCache' map in ItemManager
[ https://issues.apache.org/jira/browse/JCR-862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Guggisberg resolved JCR-862. --- Resolution: Fixed Fix Version/s: 1.4 fixed in svn r532720 unsynchronized access on 'itemCache' map in ItemManager Key: JCR-862 URL: https://issues.apache.org/jira/browse/JCR-862 Project: Jackrabbit Issue Type: Bug Components: core Affects Versions: 1.2.3 Reporter: Tobias Bocanegra Assigned To: Stefan Guggisberg Fix For: 1.4 the access 'itemCache' map in ItemManager is mostly synchronized by not via the ItemStateListener methods: [...] public void stateCreated(ItemState created) { ItemImpl item = retrieveItem(created.getId()); if (item != null) { item.stateCreated(created); } } [...] private ItemImpl retrieveItem(ItemId id) { return (ItemImpl) itemCache.get(id); } [...] this can result in a corruption of a map (eg subsequent accesses may result in a endless loop). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-890) concurrent read-only access to a session
concurrent read-only access to a session Key: JCR-890 URL: https://issues.apache.org/jira/browse/JCR-890 Project: Jackrabbit Issue Type: Improvement Components: core Reporter: David Nuescheler Assigned To: Stefan Guggisberg Even though the JCR specification does not make a statement about Sessions shared across a number of threads I think it would be great for many applications if we could state that sharing a read-only session is supported by Jackrabbit. On many occasions in the mailing lists we stated that there should not be an issue with sharing a read-only session, however I think it has never been thoroughly tested or even specified as a design goal. If we can come to an agreement that this is desirable I think it would be great to start including testcases to validate that behaviour and update the documentation respectively. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-888) javax.jcr.NamespaceException: : is not a registered namespace uri
[ https://issues.apache.org/jira/browse/JCR-888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12492011 ] Dave Erickson commented on JCR-888: --- Thanks for the quick response. I found out that the issue was due to a custom JRE. When I used the default 1.4.2 and 5.0 JRE's from Sun, there is no longer an issue. I will close this ticket. javax.jcr.NamespaceException: : is not a registered namespace uri - Key: JCR-888 URL: https://issues.apache.org/jira/browse/JCR-888 Project: Jackrabbit Issue Type: Bug Components: core Affects Versions: 1.2.3, 1.3 Environment: Windows XP, Eclipse 3.1, JRE 1.4.2 and 5.0 Reporter: Dave Erickson Using the first hops with both versions 1.2.3 and 1.3, the repository is created successfully the first time it is run. Subsequent attempts to login result in a javax.jcr.NamespaceException. DEBUG - Initializing transient repository INFO - Starting repository... INFO - LocalFileSystem initialized at path repository\repository Exception in thread main javax.jcr.NamespaceException: : is not a registered namespace uri. at org.apache.jackrabbit.core.NamespaceRegistryImpl.getPrefix(NamespaceRegistryImpl.java:538) at org.apache.jackrabbit.core.nodetype.NodeTypeRegistry.checkNamespace(NodeTypeRegistry.java:1292) at org.apache.jackrabbit.core.nodetype.NodeTypeRegistry.validateNodeTypeDef(NodeTypeRegistry.java:1415) at org.apache.jackrabbit.core.nodetype.NodeTypeRegistry.internalRegister(NodeTypeRegistry.java:1221) at org.apache.jackrabbit.core.nodetype.NodeTypeRegistry.init(NodeTypeRegistry.java:671) at org.apache.jackrabbit.core.nodetype.NodeTypeRegistry.create(NodeTypeRegistry.java:118) at org.apache.jackrabbit.core.RepositoryImpl.createNodeTypeRegistry(RepositoryImpl.java:571) at org.apache.jackrabbit.core.RepositoryImpl.init(RepositoryImpl.java:262) at org.apache.jackrabbit.core.RepositoryImpl.create(RepositoryImpl.java:584) at org.apache.jackrabbit.core.TransientRepository$2.getRepository(TransientRepository.java:245) at org.apache.jackrabbit.core.TransientRepository.startRepository(TransientRepository.java:265) at org.apache.jackrabbit.core.TransientRepository.login(TransientRepository.java:333) at org.apache.jackrabbit.core.TransientRepository.login(TransientRepository.java:388) at testing.FirstHops.main(FirstHops.java:24) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (JCR-888) javax.jcr.NamespaceException: : is not a registered namespace uri
[ https://issues.apache.org/jira/browse/JCR-888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Erickson closed JCR-888. - Resolution: Fixed This does not occur when the default 1.4.2_11 and 5.0 JRE's are used. It was only happening when using a custom JRE javax.jcr.NamespaceException: : is not a registered namespace uri - Key: JCR-888 URL: https://issues.apache.org/jira/browse/JCR-888 Project: Jackrabbit Issue Type: Bug Components: core Affects Versions: 1.2.3, 1.3 Environment: Windows XP, Eclipse 3.1, JRE 1.4.2 and 5.0 Reporter: Dave Erickson Using the first hops with both versions 1.2.3 and 1.3, the repository is created successfully the first time it is run. Subsequent attempts to login result in a javax.jcr.NamespaceException. DEBUG - Initializing transient repository INFO - Starting repository... INFO - LocalFileSystem initialized at path repository\repository Exception in thread main javax.jcr.NamespaceException: : is not a registered namespace uri. at org.apache.jackrabbit.core.NamespaceRegistryImpl.getPrefix(NamespaceRegistryImpl.java:538) at org.apache.jackrabbit.core.nodetype.NodeTypeRegistry.checkNamespace(NodeTypeRegistry.java:1292) at org.apache.jackrabbit.core.nodetype.NodeTypeRegistry.validateNodeTypeDef(NodeTypeRegistry.java:1415) at org.apache.jackrabbit.core.nodetype.NodeTypeRegistry.internalRegister(NodeTypeRegistry.java:1221) at org.apache.jackrabbit.core.nodetype.NodeTypeRegistry.init(NodeTypeRegistry.java:671) at org.apache.jackrabbit.core.nodetype.NodeTypeRegistry.create(NodeTypeRegistry.java:118) at org.apache.jackrabbit.core.RepositoryImpl.createNodeTypeRegistry(RepositoryImpl.java:571) at org.apache.jackrabbit.core.RepositoryImpl.init(RepositoryImpl.java:262) at org.apache.jackrabbit.core.RepositoryImpl.create(RepositoryImpl.java:584) at org.apache.jackrabbit.core.TransientRepository$2.getRepository(TransientRepository.java:245) at org.apache.jackrabbit.core.TransientRepository.startRepository(TransientRepository.java:265) at org.apache.jackrabbit.core.TransientRepository.login(TransientRepository.java:333) at org.apache.jackrabbit.core.TransientRepository.login(TransientRepository.java:388) at testing.FirstHops.main(FirstHops.java:24) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (JCR-674) String properties with invalid XML characters export as invalid XML
[ https://issues.apache.org/jira/browse/JCR-674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke reassigned JCR-674: -- Assignee: Julian Reschke String properties with invalid XML characters export as invalid XML --- Key: JCR-674 URL: https://issues.apache.org/jira/browse/JCR-674 Project: Jackrabbit Issue Type: Bug Components: JCR 1.0.1, xml Affects Versions: 1.1.1 Reporter: Joshua Levy Assigned To: Julian Reschke Priority: Minor As noted in the current JCR 1.0.1 maintenance draft, sections 6.4.1, 6.4.2.6, XML export of string properties that contain invalid XML characters isn't well-defined currently, since those characters are not permissible in XML. The proposed fix is to use base64 encoding for such values in System View. Most characters below #x20 are examples of this. Currently, these are escaped numerically in output (such as (amp)#0; ) but such escape sequences can't be parsed by the XML import methods. The current behavior is particularly problematic, because the user doesn't know the output is corrupt until later, when they try to import it and get InvalidSerializedDataException. If for some reason the base64 option is delayed, it might make sense, as an interim solution, to fail on export or to somehow patch import to relax its parsing and allow these escape codes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (JCR-862) unsynchronized access on 'itemCache' map in ItemManager
[ https://issues.apache.org/jira/browse/JCR-862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tobias Bocanegra reopened JCR-862: -- there are still some potential unsynchronized accesses: - itemExists(Path) calls evictItem() - itemExists(ItemId) calls evictItem() - dispose() does a cache.clear() - dump() accesses the cache as well unsynchronized access on 'itemCache' map in ItemManager Key: JCR-862 URL: https://issues.apache.org/jira/browse/JCR-862 Project: Jackrabbit Issue Type: Bug Components: core Affects Versions: 1.2.3 Reporter: Tobias Bocanegra Assigned To: Stefan Guggisberg Fix For: 1.4 the access 'itemCache' map in ItemManager is mostly synchronized by not via the ItemStateListener methods: [...] public void stateCreated(ItemState created) { ItemImpl item = retrieveItem(created.getId()); if (item != null) { item.stateCreated(created); } } [...] private ItemImpl retrieveItem(ItemId id) { return (ItemImpl) itemCache.get(id); } [...] this can result in a corruption of a map (eg subsequent accesses may result in a endless loop). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (JCR-763) Unable to create and login to different workspaces
[ https://issues.apache.org/jira/browse/JCR-763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Bloomfield Ramagem closed JCR-763. - Unable to create and login to different workspaces -- Key: JCR-763 URL: https://issues.apache.org/jira/browse/JCR-763 Project: Jackrabbit Issue Type: Bug Components: jca Affects Versions: 1.2.1 Environment: Geronimo 1.1.1, Java 5r10, Windows XP Reporter: Daniel Bloomfield Ramagem Attachments: stacktrace.txt, testservlet.war I'm using the Jackrabbit 1.2.1 JCA adapter and trying to have a Servlet create and use two separate workspaces. I get a java.lang.IllegalStateException: Inactive logical session handle called error when running the code below: Context ctx = new InitialContext(); Repository repository = (Repository) ctx.lookup(java:comp/env/jackrabbit); Credentials credentials = new SimpleCredentials(username, password.toCharArray()); Session session = repository.login(credentials); Workspace workspace = session.getWorkspace(); JackrabbitWorkspace jws = (JackrabbitWorkspace) workspace; jws.createWorkspace(ws1); jws.createWorkspace (ws2); Session s1 = repository.login(credentials, ws1); Session s2 = repository.login(credentials, ws2); System.out.println(s1.getWorkspace().getName() = + s1.getWorkspace ().getName()); System.out.println(s2.getWorkspace().getName() = + s2.getWorkspace().getName()); To make matters worse, when I comment out the lines for the creation of the second workspace (ws2), the code runs fine but I can't seem to login to ws1. On the file system the ws1 workspace directory got created OK. But the System.out.println prints default for the workspace name) Context ctx = new InitialContext(); Repository repository = (Repository) ctx.lookup(java:comp/env/jackrabbit); Credentials credentials = new SimpleCredentials(username, password.toCharArray()); Session session = repository.login(credentials); Workspace workspace = session.getWorkspace(); JackrabbitWorkspace jws = (JackrabbitWorkspace) workspace; jws.createWorkspace(ws1); //jws.createWorkspace (ws2); Session s1 = repository.login(credentials, ws1); //Session s2 = repository.login(credentials, ws2); System.out.println(s1.getWorkspace().getName() = + s1.getWorkspace ().getName()); //System.out.println(s2.getWorkspace().getName() = + s2.getWorkspace().getName()); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Jackrabbit 1.2.3, RecordInput/DatabaseJournal
I want to extend reimplemente DatabaseJounal (core.cluster), but there is a dependency on RecordInput which is a protected class (or at least default scope). So you cant extend AbstractDatabaseJournal except in the same package (perhaps thats the answer) Is there a reason for this, or was it an oversight. The reason I want to extend as I am embedding Jackrabbit into Sakai (www.sakaiproject.org) and I would prefer to use a DataSource rather DriverManager delivered connection even if I get the connection and keep it. Thanks Ian
Jackrabbit Scalability / Performance
Hi, I am working on an application in which documents arriving at a mail-room are scanned and placed in a content repository. I need basic functionality to add, locate and retrieve artifacts to the repository. JSR-170 provides these basic services, however the interface looks chatty. To address chattyness and performance issues associated with large documents, I am planning on exposing coarse grained business services (which use the local JCR interface). Given that these are scanned images, I do not need the document to be indexed. I do however need to be able to search on the metadata associated with a document. I was wondering if: Has anyone built an application similar to that described above? What version of Jackrabbit was used, and what were the issues that you ran into. How much meta-data did a node carry, what was the average depth of a leaf node, and how many nodes did you have in the implementation before performance became an issue. I am considering on building a cluster of servers providing repository services. Can the repository be clustered ? (a load balancer in front of the repository will distribute requests to a pool of repository servers.). How does the repository scale? can it handle 50Million artifacts (if the artifacts are placed on the file system does Alfresco manage the directory structure or are all files placed in a single directory) Is there support for auditing access to documents ? Is there support for defining archival / retention policies? Is there support for backups ? Thanks. - viraf - Ahhh...imagining that irresistible new car smell? Check outnew cars at Yahoo! Autos.