[jira] Updated: (JCR-989) Modify LazyQueryResultImpl to allow resultFetchSize to be set programmatically

2007-08-03 Thread Christoph Kiehl (JIRA) 

 [ 
https://issues.apache.org/jira/browse/JCR-989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christoph Kiehl updated JCR-989:


Attachment: (was: LazyQueryResultImpl.patch)

> Modify LazyQueryResultImpl to allow resultFetchSize to be set programmatically
> --
>
> Key: JCR-989
> URL: https://issues.apache.org/jira/browse/JCR-989
> Project: Jackrabbit
>  Issue Type: New Feature
>  Components: query
>Affects Versions: 1.3
>Reporter: Christoph Kiehl
>Assignee: Christoph Kiehl
>Priority: Minor
> Attachments: jackrabbit-api.patch, jackrabbit-core.patch
>
>
> In our application we have a search which only shows part of a query result. 
> We always know which part of the result needs to be shown. This means we know 
> in advance how many results need to be fetched. I would like to be able to 
> programmatically set resultFetchSize to minimize the number of loaded lucene 
> docs and therefore improve the performance.
> I know it is already possible to the set the resultFetchSize via the index 
> configuration, but this number is fixed and doesn't work well in environments 
> where you use paging for your results because if you set this number too low 
> the query will be executed multiple times and if you set it too high too many 
> lucene docs are loaded.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (JCR-989) Modify LazyQueryResultImpl to allow resultFetchSize to be set programmatically

2007-08-03 Thread Christoph Kiehl (JIRA) 

 [ 
https://issues.apache.org/jira/browse/JCR-989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christoph Kiehl updated JCR-989:


Attachment: jackrabbit-core.patch
jackrabbit-api.patch

I finally made it. Took me a bit more than a few days however ;)

I decided to create a new interface JackrabbitQuery in jackrabbit-api which 
includes the two methods setOffset() and setLimit() which will probably be part 
of JCR 2.0. This way you don't have to cast your Query instance to QueryImpl 
but rather JackrabbitQuery. This hopefully makes it more accessible to users 
and looks less like a hack. 

((QueryImpl) query).setLimit(123)

vs

((JackrabbitQuery) query).setLimit(123)

This opens the possibility to provide an RMI implementation to support those 
two methods over RMI as well.

Everything else was quite straight forward. There are two patches: one for 
jackrabbit-api containing the interface and one for jackrabbit-core containing 
the actual code changes. WDYT?

> Modify LazyQueryResultImpl to allow resultFetchSize to be set programmatically
> --
>
> Key: JCR-989
> URL: https://issues.apache.org/jira/browse/JCR-989
> Project: Jackrabbit
>  Issue Type: New Feature
>  Components: query
>Affects Versions: 1.3
>Reporter: Christoph Kiehl
>Assignee: Christoph Kiehl
>Priority: Minor
> Attachments: jackrabbit-api.patch, jackrabbit-core.patch
>
>
> In our application we have a search which only shows part of a query result. 
> We always know which part of the result needs to be shown. This means we know 
> in advance how many results need to be fetched. I would like to be able to 
> programmatically set resultFetchSize to minimize the number of loaded lucene 
> docs and therefore improve the performance.
> I know it is already possible to the set the resultFetchSize via the index 
> configuration, but this number is fixed and doesn't work well in environments 
> where you use paging for your results because if you set this number too low 
> the query will be executed multiple times and if you set it too high too many 
> lucene docs are loaded.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Assigned: (JCR-989) Modify LazyQueryResultImpl to allow resultFetchSize to be set programmatically

2007-08-03 Thread Christoph Kiehl (JIRA) 

 [ 
https://issues.apache.org/jira/browse/JCR-989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christoph Kiehl reassigned JCR-989:
---

Assignee: Christoph Kiehl

> Modify LazyQueryResultImpl to allow resultFetchSize to be set programmatically
> --
>
> Key: JCR-989
> URL: https://issues.apache.org/jira/browse/JCR-989
> Project: Jackrabbit
>  Issue Type: New Feature
>  Components: query
>Affects Versions: 1.3
>Reporter: Christoph Kiehl
>Assignee: Christoph Kiehl
>Priority: Minor
> Attachments: LazyQueryResultImpl.patch
>
>
> In our application we have a search which only shows part of a query result. 
> We always know which part of the result needs to be shown. This means we know 
> in advance how many results need to be fetched. I would like to be able to 
> programmatically set resultFetchSize to minimize the number of loaded lucene 
> docs and therefore improve the performance.
> I know it is already possible to the set the resultFetchSize via the index 
> configuration, but this number is fixed and doesn't work well in environments 
> where you use paging for your results because if you set this number too low 
> the query will be executed multiple times and if you set it too high too many 
> lucene docs are loaded.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (JCR-1009) JCR2SPI: add JNDI support

2007-08-03 Thread Julian Reschke (JIRA) 

 [ 
https://issues.apache.org/jira/browse/JCR-1009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julian Reschke updated JCR-1009:



OK, here's the plan:

- make RepositoryConfig referenceable (should we add that to the interface?)
- make o.a.j.s.jcrs2pi.RepositoryImpl referenceable
- generate references based on the RepositoryConfig's reference, adding 
StringRefAddrs for the parameters needed by o.a.j.s.jcrs2pi.RepositoryImpl to 
re-create the config
- implement a simple ObjectFactory inside o.a.j.s.jcrs2pi.RepositoryImpl, using 
this information


> JCR2SPI: add JNDI support
> -
>
> Key: JCR-1009
> URL: https://issues.apache.org/jira/browse/JCR-1009
> Project: Jackrabbit
>  Issue Type: New Feature
>  Components: SPI
>Reporter: angela
>Assignee: Julian Reschke
>Priority: Minor
>
> adding jndi support to jcr2spi was one of the improvements that came up 
> during the f2f.
> julian volunteered to take a look at it.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (JCR-1034) Unable to save session after saving a renamed node

2007-08-03 Thread Stefan Guggisberg (JIRA) 

 [ 
https://issues.apache.org/jira/browse/JCR-1034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Guggisberg resolved JCR-1034.


   Resolution: Fixed
Fix Version/s: 1.4

fixed in svn r562512

> Unable to save session after saving a renamed node
> --
>
> Key: JCR-1034
> URL: https://issues.apache.org/jira/browse/JCR-1034
> Project: Jackrabbit
>  Issue Type: Bug
>  Components: core
>Reporter: Edgar Poce
>Assignee: Stefan Guggisberg
>Priority: Minor
> Fix For: 1.4
>
>
>   TransientRepository repo = new TransientRepository(
>   "applications/test/repository.xml", 
> "applications/test");
>   Session s = repo.login(new SimpleCredentials("test", 
> "".toCharArray()));
>   if (s.getRootNode().hasNode("parent")) {
>   s.getRootNode().getNode("parent").remove();
>   s.save();
>   }
>   // create parent node
>   Node parent = s.getRootNode().addNode("parent");
>   
>   // create node to rename
>   parent.addNode("newnode");
>   s.save();
>   // rename node
>   s.move("/parent/newnode", "/parent/renamedNewNode");
>   // save renamed node
>   s.getRootNode().getNode("parent/renamedNewNode").save();
>   // try to save session --> FAILS
>   s.save();
>   s.logout();

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (JCR-1034) Unable to save session after saving a renamed node

2007-08-03 Thread Stefan Guggisberg (JIRA) 

[ 
https://issues.apache.org/jira/browse/JCR-1034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12517568
 ] 

Stefan Guggisberg commented on JCR-1034:


the real issue is that it is possible to save a renamed node without saving its 
parent.

a ConstraintViolationException should be thrown instead indicating that the 
parent
of a renamed node needs to be saved as well.


> Unable to save session after saving a renamed node
> --
>
> Key: JCR-1034
> URL: https://issues.apache.org/jira/browse/JCR-1034
> Project: Jackrabbit
>  Issue Type: Bug
>  Components: core
>Reporter: Edgar Poce
>Assignee: Stefan Guggisberg
>Priority: Minor
>
>   TransientRepository repo = new TransientRepository(
>   "applications/test/repository.xml", 
> "applications/test");
>   Session s = repo.login(new SimpleCredentials("test", 
> "".toCharArray()));
>   if (s.getRootNode().hasNode("parent")) {
>   s.getRootNode().getNode("parent").remove();
>   s.save();
>   }
>   // create parent node
>   Node parent = s.getRootNode().addNode("parent");
>   
>   // create node to rename
>   parent.addNode("newnode");
>   s.save();
>   // rename node
>   s.move("/parent/newnode", "/parent/renamedNewNode");
>   // save renamed node
>   s.getRootNode().getNode("parent/renamedNewNode").save();
>   // try to save session --> FAILS
>   s.save();
>   s.logout();

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Reopened: (JCR-1034) Unable to save session after saving a renamed node

2007-08-03 Thread Stefan Guggisberg (JIRA) 

 [ 
https://issues.apache.org/jira/browse/JCR-1034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Guggisberg reopened JCR-1034:



reopening, test cases fail legitimately

> Unable to save session after saving a renamed node
> --
>
> Key: JCR-1034
> URL: https://issues.apache.org/jira/browse/JCR-1034
> Project: Jackrabbit
>  Issue Type: Bug
>  Components: core
>Reporter: Edgar Poce
>Assignee: Stefan Guggisberg
>Priority: Minor
>
>   TransientRepository repo = new TransientRepository(
>   "applications/test/repository.xml", 
> "applications/test");
>   Session s = repo.login(new SimpleCredentials("test", 
> "".toCharArray()));
>   if (s.getRootNode().hasNode("parent")) {
>   s.getRootNode().getNode("parent").remove();
>   s.save();
>   }
>   // create parent node
>   Node parent = s.getRootNode().addNode("parent");
>   
>   // create node to rename
>   parent.addNode("newnode");
>   s.save();
>   // rename node
>   s.move("/parent/newnode", "/parent/renamedNewNode");
>   // save renamed node
>   s.getRootNode().getNode("parent/renamedNewNode").save();
>   // try to save session --> FAILS
>   s.save();
>   s.logout();

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Issue Comment Edited: (JCR-964) Cannot rebuild corrupt or missing search index from DataSource

2007-08-03 Thread Hitesh Shah (JIRA) 

[ 
https://issues.apache.org/jira/browse/JCR-964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12517524
 ] 

Hitesh Shah edited comment on JCR-964 at 8/3/07 6:26 AM:
-

I'm getting the same error, and my environment is not clustered yet.  I have 
removed the SearchIndex capability from my repository.xml file for performance 
and clustering considerations (we plan on clustering in the production setup).  
I'm only mentioning this because the "shut down -- remove index directories -- 
restart" option is not relevant in my case.



 was:
I'm getting the same error, and my environment is not clustered.  I have 
removed the SearchIndex capability from my repository.xml file for performance 
and clustering considerations.  I'm only mentioning this because the "shut down 
-- remove index directories -- restart" option is not relevant in my case.


> Cannot rebuild corrupt or missing search index from DataSource
> --
>
> Key: JCR-964
> URL: https://issues.apache.org/jira/browse/JCR-964
> Project: Jackrabbit
>  Issue Type: Bug
>  Components: indexing
>Affects Versions: 1.3
>Reporter: Noah Vihinen
>Priority: Blocker
>
> If the search index becomes corrupt, and the auto-repair process cannot fix 
> the search index (which is common in our experience), there is no way to 
> recover the jackrabbit instance.  The only possible work-around is when 
> you're working with a cluster, and you manually copy an intact index from one 
> of the other clusters.  It hasn't been determined whether this leads to other 
> issues though.
> Given a Jackrabbit repository, shouldn't it be possible to start the 
> repository on top of that single data source in the absence of a search 
> index, and have the search index rebuilt from the information in the DB?
> Below is the stack trace we get when restarting a repository with no search 
> index.
> 15:32:13,622 ERROR RepositoryImpl:389 - [main] Failed to initialize workspace 
> 'default'
> javax.jcr.RepositoryException: Error indexing root node: 
> a7479d92-4b59-4f44-978a-06da1ec7b8d1: Error indexing root node: 
> a7479d92-4b59-4f44-978a-06da1ec7b8d1: Error indexing root node: 
> a7479d92-4b59-4f44-978a-06da1ec7b8d1
> at 
> org.apache.jackrabbit.core.SearchManager.initializeQueryHandler(SearchManager.java:476)
> at 
> org.apache.jackrabbit.core.SearchManager.(SearchManager.java:231)
> at 
> org.apache.jackrabbit.core.RepositoryImpl$WorkspaceInfo.getSearchManager(RepositoryImpl.java:1643)
> at 
> org.apache.jackrabbit.core.RepositoryImpl.initWorkspace(RepositoryImpl.java:633)
> at 
> org.apache.jackrabbit.core.RepositoryImpl.initStartupWorkspaces(RepositoryImpl.java:386)
> at 
> org.apache.jackrabbit.core.RepositoryImpl.(RepositoryImpl.java:293)
> at 
> org.apache.jackrabbit.core.RepositoryImpl.create(RepositoryImpl.java:584)
> 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.BindableRepositoryFactory.getObjectInstance(BindableRepositoryFactory.java:81)
> at 
> org.apache.naming.factory.ResourceFactory.getObjectInstance(ResourceFactory.java:140)
> at 
> javax.naming.spi.NamingManager.getObjectInstance(NamingManager.java:304)
> at org.apache.naming.NamingContext.lookup(NamingContext.java:793)
> at org.apache.naming.NamingContext.lookup(NamingContext.java:140)
> at org.apache.naming.NamingContext.lookup(NamingContext.java:781)
> at org.apache.naming.NamingContext.lookup(NamingContext.java:140)
> at org.apache.naming.NamingContext.lookup(NamingContext.java:781)
> at org.apache.naming.NamingContext.lookup(NamingContext.java:140)
> at org.apache.naming.NamingContext.lookup(NamingContext.java:781)
> at org.apache.naming.NamingContext.lookup(NamingContext.java:153)
> at org.apache.naming.SelectorContext.lookup(SelectorContext.java:137)
> at javax.naming.InitialContext.lookup(InitialContext.java:351)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (JCR-964) Cannot rebuild corrupt or missing search index from DataSource

2007-08-03 Thread Hitesh Shah (JIRA) 

[ 
https://issues.apache.org/jira/browse/JCR-964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12517524
 ] 

Hitesh Shah commented on JCR-964:
-

I'm getting the same error, and my environment is not clustered.  I have 
removed the SearchIndex capability from my repository.xml file for performance 
and clustering considerations.  I'm only mentioning this because the "shut down 
-- remove index directories -- restart" option is not relevant in my case.


> Cannot rebuild corrupt or missing search index from DataSource
> --
>
> Key: JCR-964
> URL: https://issues.apache.org/jira/browse/JCR-964
> Project: Jackrabbit
>  Issue Type: Bug
>  Components: indexing
>Affects Versions: 1.3
>Reporter: Noah Vihinen
>Priority: Blocker
>
> If the search index becomes corrupt, and the auto-repair process cannot fix 
> the search index (which is common in our experience), there is no way to 
> recover the jackrabbit instance.  The only possible work-around is when 
> you're working with a cluster, and you manually copy an intact index from one 
> of the other clusters.  It hasn't been determined whether this leads to other 
> issues though.
> Given a Jackrabbit repository, shouldn't it be possible to start the 
> repository on top of that single data source in the absence of a search 
> index, and have the search index rebuilt from the information in the DB?
> Below is the stack trace we get when restarting a repository with no search 
> index.
> 15:32:13,622 ERROR RepositoryImpl:389 - [main] Failed to initialize workspace 
> 'default'
> javax.jcr.RepositoryException: Error indexing root node: 
> a7479d92-4b59-4f44-978a-06da1ec7b8d1: Error indexing root node: 
> a7479d92-4b59-4f44-978a-06da1ec7b8d1: Error indexing root node: 
> a7479d92-4b59-4f44-978a-06da1ec7b8d1
> at 
> org.apache.jackrabbit.core.SearchManager.initializeQueryHandler(SearchManager.java:476)
> at 
> org.apache.jackrabbit.core.SearchManager.(SearchManager.java:231)
> at 
> org.apache.jackrabbit.core.RepositoryImpl$WorkspaceInfo.getSearchManager(RepositoryImpl.java:1643)
> at 
> org.apache.jackrabbit.core.RepositoryImpl.initWorkspace(RepositoryImpl.java:633)
> at 
> org.apache.jackrabbit.core.RepositoryImpl.initStartupWorkspaces(RepositoryImpl.java:386)
> at 
> org.apache.jackrabbit.core.RepositoryImpl.(RepositoryImpl.java:293)
> at 
> org.apache.jackrabbit.core.RepositoryImpl.create(RepositoryImpl.java:584)
> 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.BindableRepositoryFactory.getObjectInstance(BindableRepositoryFactory.java:81)
> at 
> org.apache.naming.factory.ResourceFactory.getObjectInstance(ResourceFactory.java:140)
> at 
> javax.naming.spi.NamingManager.getObjectInstance(NamingManager.java:304)
> at org.apache.naming.NamingContext.lookup(NamingContext.java:793)
> at org.apache.naming.NamingContext.lookup(NamingContext.java:140)
> at org.apache.naming.NamingContext.lookup(NamingContext.java:781)
> at org.apache.naming.NamingContext.lookup(NamingContext.java:140)
> at org.apache.naming.NamingContext.lookup(NamingContext.java:781)
> at org.apache.naming.NamingContext.lookup(NamingContext.java:140)
> at org.apache.naming.NamingContext.lookup(NamingContext.java:781)
> at org.apache.naming.NamingContext.lookup(NamingContext.java:153)
> at org.apache.naming.SelectorContext.lookup(SelectorContext.java:137)
> at javax.naming.InitialContext.lookup(InitialContext.java:351)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (JCR-1038) java.lang.ArrayIndexOutOfBoundsException while importXML in Java 6

2007-08-03 Thread Stefan Guggisberg (JIRA) 

 [ 
https://issues.apache.org/jira/browse/JCR-1038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Guggisberg resolved JCR-1038.


   Resolution: Fixed
Fix Version/s: 1.4

fixed in svn r562403

thanks for reporting this issue!

> java.lang.ArrayIndexOutOfBoundsException while importXML in Java 6
> --
>
> Key: JCR-1038
> URL: https://issues.apache.org/jira/browse/JCR-1038
> Project: Jackrabbit
>  Issue Type: Bug
>  Components: xml
>Affects Versions: 1.3
> Environment: Linux
>   java version "1.6.0_02"
>   Java(TM) SE Runtime Environment (build 1.6.0_02-b05)
>   Java HotSpot(TM) Client VM (build 1.6.0_02-b05, mixed mode, sharing)
>Reporter: Martin Zdila
>Assignee: Stefan Guggisberg
> Fix For: 1.4
>
> Attachments: reports-dump.xml.gz
>
>
> Using:
> - Jackrabbit 1.3
> - Java:
>   java version "1.6.0_02"
>   Java(TM) SE Runtime Environment (build 1.6.0_02-b05)
>   Java HotSpot(TM) Client VM (build 1.6.0_02-b05, mixed mode, sharing)
> When importing attached XML, I get an exception:
> Caused by: java.lang.ArrayIndexOutOfBoundsException
> at java.lang.System.arraycopy(Native Method)
> at 
> org.apache.jackrabbit.core.xml.BufferedStringValue.append(BufferedStringValue.java:201)
> at 
> org.apache.jackrabbit.core.xml.SysViewImportHandler.characters(SysViewImportHandler.java:187)
> at 
> org.apache.jackrabbit.core.xml.ImportHandler.characters(ImportHandler.java:200)
> at 
> com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.characters(AbstractSAXParser.java:538)
> at 
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:461)
> at 
> com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:807)
> at 
> com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:737)
> at 
> com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:107)
> at 
> com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1205)
> at 
> com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:522)
> at javax.xml.parsers.SAXParser.parse(SAXParser.java:395)
> at 
> org.apache.jackrabbit.core.SessionImpl.importXML(SessionImpl.java:1116)
> ...
> If I use Java 1.5, then it works.
> java version "1.5.0_12"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_12-b04)
> Java HotSpot(TM) Client VM (build 1.5.0_12-b04, mixed mode, sharing)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (JCR-1038) java.lang.ArrayIndexOutOfBoundsException while importXML in Java 6

2007-08-03 Thread Stefan Guggisberg (JIRA) 

[ 
https://issues.apache.org/jira/browse/JCR-1038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12517502
 ] 

Stefan Guggisberg commented on JCR-1038:


reproducible  when specifying 

-Djavax.xml.parsers.SAXParserFactory=com.sun.org.apache.xerces.internal.jaxp.SAXParserFactoryImpl

> java.lang.ArrayIndexOutOfBoundsException while importXML in Java 6
> --
>
> Key: JCR-1038
> URL: https://issues.apache.org/jira/browse/JCR-1038
> Project: Jackrabbit
>  Issue Type: Bug
>  Components: xml
>Affects Versions: 1.3
> Environment: Linux
>   java version "1.6.0_02"
>   Java(TM) SE Runtime Environment (build 1.6.0_02-b05)
>   Java HotSpot(TM) Client VM (build 1.6.0_02-b05, mixed mode, sharing)
>Reporter: Martin Zdila
>Assignee: Stefan Guggisberg
> Attachments: reports-dump.xml.gz
>
>
> Using:
> - Jackrabbit 1.3
> - Java:
>   java version "1.6.0_02"
>   Java(TM) SE Runtime Environment (build 1.6.0_02-b05)
>   Java HotSpot(TM) Client VM (build 1.6.0_02-b05, mixed mode, sharing)
> When importing attached XML, I get an exception:
> Caused by: java.lang.ArrayIndexOutOfBoundsException
> at java.lang.System.arraycopy(Native Method)
> at 
> org.apache.jackrabbit.core.xml.BufferedStringValue.append(BufferedStringValue.java:201)
> at 
> org.apache.jackrabbit.core.xml.SysViewImportHandler.characters(SysViewImportHandler.java:187)
> at 
> org.apache.jackrabbit.core.xml.ImportHandler.characters(ImportHandler.java:200)
> at 
> com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.characters(AbstractSAXParser.java:538)
> at 
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:461)
> at 
> com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:807)
> at 
> com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:737)
> at 
> com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:107)
> at 
> com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1205)
> at 
> com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:522)
> at javax.xml.parsers.SAXParser.parse(SAXParser.java:395)
> at 
> org.apache.jackrabbit.core.SessionImpl.importXML(SessionImpl.java:1116)
> ...
> If I use Java 1.5, then it works.
> java version "1.5.0_12"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_12-b04)
> Java HotSpot(TM) Client VM (build 1.5.0_12-b04, mixed mode, sharing)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (JCR-1034) Unable to save session after saving a renamed node

2007-08-03 Thread Julian Reschke (JIRA) 

[ 
https://issues.apache.org/jira/browse/JCR-1034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12517500
 ] 

Julian Reschke commented on JCR-1034:
-

It seems that this breaks test test case 
org.apache.jackrabbit.test.api,SessionTest.testMoveConstraintViolationExceptionSrc,
 which seems to verfiy that an exception *is* thrown.

Unless that test case somehow is broken, I recommend to back out the change, 
and to resolve this issue as invalid.


> Unable to save session after saving a renamed node
> --
>
> Key: JCR-1034
> URL: https://issues.apache.org/jira/browse/JCR-1034
> Project: Jackrabbit
>  Issue Type: Bug
>  Components: core
>Reporter: Edgar Poce
>Assignee: Stefan Guggisberg
>Priority: Minor
>
>   TransientRepository repo = new TransientRepository(
>   "applications/test/repository.xml", 
> "applications/test");
>   Session s = repo.login(new SimpleCredentials("test", 
> "".toCharArray()));
>   if (s.getRootNode().hasNode("parent")) {
>   s.getRootNode().getNode("parent").remove();
>   s.save();
>   }
>   // create parent node
>   Node parent = s.getRootNode().addNode("parent");
>   
>   // create node to rename
>   parent.addNode("newnode");
>   s.save();
>   // rename node
>   s.move("/parent/newnode", "/parent/renamedNewNode");
>   // save renamed node
>   s.getRootNode().getNode("parent/renamedNewNode").save();
>   // try to save session --> FAILS
>   s.save();
>   s.logout();

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Continuum vs build failures

2007-08-03 Thread Julian Reschke 

Hi,

I can't help noticing that two out of three projects on 
 
are in status "build error".


With respect to Jackrabbit itself, this is because of a recent code 
change; maybe the test cases that now fail are incorrect, but either 
way, this really should be resolved so that other developers do not have 
to spend time figuring out what's wrong. In doubt, back out the change 
that causes the test case failure until the problem is understood and fixed.


Looking at SPI: I'm not sure whether this is an actual bug, or our 
config for "testcases to be skipped" is still incomplete? Last time we 
had success here was on July 23.


Finally, maybe it would be good if Continuum would send out emails to 
this list when builds break. Jukka, would that be feasible?


Best regards, Julian

Re: Sling Proposal

2007-08-03 Thread Felix Meschberger 
Good point. Just done that.

Regards
Felix

Am Freitag, den 03.08.2007, 10:13 +0200 schrieb Christophe Lombart:
> Maybe we can add this kind of info in the wiki.
> 
> Christophe
> 
> 
> On 8/3/07, Felix Meschberger <[EMAIL PROTECTED]> wrote:
> >
> > Hi Ransford,
> >
> > Am Mittwoch, den 01.08.2007, 13:46 -0700 schrieb paksegu:
> > > I have read the documention but I am still confuse on the purpose and
> > benefit of sling, can you please give me  a brief explanation of what is
> > does and where it applicable, say a usecase scenario.
> >
> > Basically, the intent of Sling is to be JCR-based web application
> > development framework. All content delivered is backed by actual
> > Repository Content (Nodes and Properties). As such, a request is
> > resolved against a Repository Node, loaded (using the JCR Mapper) into a
> > Java Object called the Content object, which is handed to a Component
> > object which in turn handles the Java Object representing the node and
> > renders the response.
> >
> > The uses of these are vast and way beyond my own imagination (David is
> > much better at that :-) ). But here are a few ones:
> >
> >
> > Wiki
> > 
> >
> > We built a Wiki system on Sling. Each Wiki page is a node (with optional
> > child nodes) in the repository. As a page is requested, the respective
> > node is accessed and through the applying Component is rendered.
> >
> > Thanks to the JCR Mapping and the resolution of the Component from the
> > mapped Content, the system does not care for what actual node is
> > addressed as long as there is a Content mapping and a Component capable
> > of handling the Content.
> >
> > Thus in the tradition of REST, the attachement of a Wiki page, which
> > happens to be in a node nested below the wiki page node is easily
> > accessed using the URL of the wiki page attaching the relative path of
> > the attachement node. The system resolves the URL to the attachement
> > Content and just calls the attachement's Component to spool the
> > attachement.
> >
> >
> > Digital Asset Management
> > 
> >
> > Day has implemented a Digital Asset Management (DAM) Application based
> > on Sling. Thanks to the flexibility of the Content/Component combo as
> > well as the service registration/access functionality offered by OSGi,
> > extending DAM for new content type is merely a matter of implementing
> > one or two interfaces and registering the respective service(s).
> >
> > Again, the management assets may be easily spooled by directly accessing
> > them.
> >
> >
> > Web Content Management
> > --
> >
> > Last but not least, Sling offers it self very well to implementing a Web
> > Content Management system. Thanks to the flexibility of rendering the
> > output - remmber: the system does not care what to render, as long as
> > the URL resolves to a Content object for which a Component exists, which
> > is called to render the Content - providing support for Web Content
> > authors (not PHP programmers but users out in the field) to build pages
> > to their likings can easily be done.
> >
> >
> > I hope these examples helped clarfiy a bit the scope of Sling and what
> > can be accomplished.
> >
> > Regards
> > Felix
> >
> >

Re: Sling Proposal

2007-08-03 Thread Christophe Lombart 
Maybe we can add this kind of info in the wiki.

Christophe


On 8/3/07, Felix Meschberger <[EMAIL PROTECTED]> wrote:
>
> Hi Ransford,
>
> Am Mittwoch, den 01.08.2007, 13:46 -0700 schrieb paksegu:
> > I have read the documention but I am still confuse on the purpose and
> benefit of sling, can you please give me  a brief explanation of what is
> does and where it applicable, say a usecase scenario.
>
> Basically, the intent of Sling is to be JCR-based web application
> development framework. All content delivered is backed by actual
> Repository Content (Nodes and Properties). As such, a request is
> resolved against a Repository Node, loaded (using the JCR Mapper) into a
> Java Object called the Content object, which is handed to a Component
> object which in turn handles the Java Object representing the node and
> renders the response.
>
> The uses of these are vast and way beyond my own imagination (David is
> much better at that :-) ). But here are a few ones:
>
>
> Wiki
> 
>
> We built a Wiki system on Sling. Each Wiki page is a node (with optional
> child nodes) in the repository. As a page is requested, the respective
> node is accessed and through the applying Component is rendered.
>
> Thanks to the JCR Mapping and the resolution of the Component from the
> mapped Content, the system does not care for what actual node is
> addressed as long as there is a Content mapping and a Component capable
> of handling the Content.
>
> Thus in the tradition of REST, the attachement of a Wiki page, which
> happens to be in a node nested below the wiki page node is easily
> accessed using the URL of the wiki page attaching the relative path of
> the attachement node. The system resolves the URL to the attachement
> Content and just calls the attachement's Component to spool the
> attachement.
>
>
> Digital Asset Management
> 
>
> Day has implemented a Digital Asset Management (DAM) Application based
> on Sling. Thanks to the flexibility of the Content/Component combo as
> well as the service registration/access functionality offered by OSGi,
> extending DAM for new content type is merely a matter of implementing
> one or two interfaces and registering the respective service(s).
>
> Again, the management assets may be easily spooled by directly accessing
> them.
>
>
> Web Content Management
> --
>
> Last but not least, Sling offers it self very well to implementing a Web
> Content Management system. Thanks to the flexibility of rendering the
> output - remmber: the system does not care what to render, as long as
> the URL resolves to a Content object for which a Component exists, which
> is called to render the Content - providing support for Web Content
> authors (not PHP programmers but users out in the field) to build pages
> to their likings can easily be done.
>
>
> I hope these examples helped clarfiy a bit the scope of Sling and what
> can be accomplished.
>
> Regards
> Felix
>
>