JCR mapping

2007-04-26 Thread Christophe Lombart

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

2007-04-26 Thread Felix Meschberger

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

2007-04-26 Thread JIRA
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

2007-04-26 Thread JIRA

 [ 
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

2007-04-26 Thread Stefan Guggisberg (JIRA)

[ 
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

2007-04-26 Thread Stefan Guggisberg (JIRA)

 [ 
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

2007-04-26 Thread David Nuescheler (JIRA)
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

2007-04-26 Thread Dave Erickson (JIRA)

[ 
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

2007-04-26 Thread Dave Erickson (JIRA)

 [ 
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

2007-04-26 Thread Julian Reschke (JIRA)

 [ 
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

2007-04-26 Thread Tobias Bocanegra (JIRA)

 [ 
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

2007-04-26 Thread Daniel Bloomfield Ramagem (JIRA)

 [ 
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

2007-04-26 Thread Ian Boston
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

2007-04-26 Thread Viraf Bankwalla
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.