January 2010 - dna-issues - Jboss List Archives

[JBoss JIRA] Created: (DNA-617) NPE while updating indexes (during integration tests)

by Randall Hauch (JIRA)

NPE while updating indexes (during integration tests) ----------------------------------------------------- Key: DNA-617 URL: https://jira.jboss.org/jira/browse/DNA-617 Project: DNA Issue Type: Bug Affects Versions: 0.7 Reporter: Randall Hauch Assignee: Randall Hauch Priority: Blocker Fix For: 0.7 This happened on the nightly integration tests, but did not happen during the continuous integration tests. So while I'm not sure how repeatable it is, there is at least a stack trace: java.lang.IllegalStateException: Failed to initialize the repository with text content. at org.jboss.dna.jcr.DnaRepositoryStub.configureRepository(DnaRepositoryStub.java:140) at org.jboss.dna.jcr.DnaRepositoryStub.getRepository(DnaRepositoryStub.java:157) at org.jboss.dna.jcr.DnaRepositoryStub.getRepository(DnaRepositoryStub.java:41) at org.apache.jackrabbit.test.RepositoryHelper.getRepository(RepositoryHelper.java:68) at org.apache.jackrabbit.test.RepositoryHelper.getProperty(RepositoryHelper.java:150) at org.apache.jackrabbit.test.AbstractJCRTest.getProperty(AbstractJCRTest.java:442) at org.apache.jackrabbit.test.AbstractJCRTest.setUp(AbstractJCRTest.java:264) at org.apache.jackrabbit.test.api.RootNodeTest.setUp(RootNodeTest.java:47) at junit.framework.TestCase.runBare(TestCase.java:132) at junit.framework.TestResult$1.protect(TestResult.java:110) at junit.framework.TestResult.runProtected(TestResult.java:128) at junit.framework.TestResult.run(TestResult.java:113) at junit.framework.TestCase.run(TestCase.java:124) at org.apache.jackrabbit.test.AbstractJCRTest.run(AbstractJCRTest.java:406) at junit.framework.TestSuite.runTest(TestSuite.java:232) at junit.framework.TestSuite.run(TestSuite.java:227) at junit.framework.TestSuite.runTest(TestSuite.java:232) at junit.framework.TestSuite.run(TestSuite.java:227) at junit.framework.TestSuite.runTest(TestSuite.java:232) at junit.framework.TestSuite.run(TestSuite.java:227) at junit.framework.TestSuite.runTest(TestSuite.java:232) at junit.framework.TestSuite.run(TestSuite.java:227) at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:81) at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:127) at org.apache.maven.surefire.Surefire.run(Surefire.java:177) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:345) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1009) Caused by: java.lang.NullPointerException at org.jboss.dna.graph.search.SearchEngineIndexer.indexSubgraph(SearchEngineIndexer.java:294) at org.jboss.dna.graph.search.SearchEngineIndexer.index(SearchEngineIndexer.java:227) at org.jboss.dna.graph.search.SearchEngineIndexer.index(SearchEngineIndexer.java:135) at org.jboss.dna.jcr.RepositoryQueryManager$SelfContained.reindexContent(RepositoryQueryManager.java:334) at org.jboss.dna.jcr.RepositoryQueryManager$SelfContained.<init>(RepositoryQueryManager.java:292) at org.jboss.dna.jcr.JcrRepository.<init>(JcrRepository.java:593) at org.jboss.dna.jcr.JcrEngine.doCreateJcrRepository(JcrEngine.java:257) at org.jboss.dna.jcr.JcrEngine.getRepository(JcrEngine.java:175) at org.jboss.dna.jcr.DnaRepositoryStub.configureRepository(DnaRepositoryStub.java:120) at org.jboss.dna.jcr.DnaRepositoryStub.getRepository(DnaRepositoryStub.java:157) at org.jboss.dna.jcr.DnaRepositoryStub.getRepository(DnaRepositoryStub.java:41) at org.apache.jackrabbit.test.RepositoryHelper.getRepository(RepositoryHelper.java:68) at org.apache.jackrabbit.test.RepositoryHelper.getProperty(RepositoryHelper.java:150) at org.apache.jackrabbit.test.AbstractJCRTest.getProperty(AbstractJCRTest.java:442) at org.apache.jackrabbit.test.AbstractJCRTest.setUp(AbstractJCRTest.java:264) at org.apache.jackrabbit.test.api.RootNodeTest.setUp(RootNodeTest.java:47) at junit.framework.TestCase.runBare(TestCase.java:132) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 3 months

2
12
0 / 0

[JBoss JIRA] Created: (DNA-367) AbstractJcrNode.getReferences() Is Incorrect

by Brian Carothers (JIRA)

AbstractJcrNode.getReferences() Is Incorrect -------------------------------------------- Key: DNA-367 URL: https://jira.jboss.org/jira/browse/DNA-367 Project: DNA Issue Type: Bug Components: JCR Affects Versions: 0.3 Reporter: Brian Carothers AbstractJcrNode.getReferences currently returns all of the reference properties in that node. According to section 6.2.3 of the 1.0.1 specification, it is supposed to return all _other_ nodes that refer to it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 3 months

2
4
0 / 0

[JBoss JIRA] Created: (DNA-368) Referenced Nodes Can Be Deleted

by Brian Carothers (JIRA)

Referenced Nodes Can Be Deleted ------------------------------- Key: DNA-368 URL: https://jira.jboss.org/jira/browse/DNA-368 Project: DNA Issue Type: Bug Components: JCR Affects Versions: 0.3 Reporter: Brian Carothers There is not currently a check in AbstractJcrNode.remove() to see if the node (or any of its child nodes) are targets of references. Per section 7.1.6 of the 1.0.1 specification, this should cause a ReferentialIntegrityException to be thrown. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 3 months

2
5
0 / 0

[JBoss JIRA] Created: (DNA-642) DDL sequencer should accept optional configuration property listing possible dialects

by Randall Hauch (JIRA)

DDL sequencer should accept optional configuration property listing possible dialects ------------------------------------------------------------------------------------- Key: DNA-642 URL: https://jira.jboss.org/jira/browse/DNA-642 Project: DNA Issue Type: Feature Request Components: Connectors Affects Versions: 0.7 Reporter: Randall Hauch Fix For: 1.0 The DDL sequencer (which implements StreamSequencer) currently does not look at the properties in the StreamSequencerContext to look for the dialects that should be used. By supporting such an optional property, the DDL sequencer could be configured to only run certain dialects (perhaps even just one). And if the list were ordered, the DDL sequencer could use that order to determine the proper dialect should multiple parsers result in the same score. This certainly is imprecise, but it does offer the user a bit more control should they need it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 3 months

1
0
0 / 0

[JBoss JIRA] Created: (DNA-641) The DDL sequencer should allow specifying the dialect type in DDL comments

by Randall Hauch (JIRA)

The DDL sequencer should allow specifying the dialect type in DDL comments -------------------------------------------------------------------------- Key: DNA-641 URL: https://jira.jboss.org/jira/browse/DNA-641 Project: DNA Issue Type: Feature Request Components: Sequencers Affects Versions: 0.7 Reporter: Randall Hauch Fix For: 1.0 At the moment, the DdlParsers class looks for a leading "PARSER_ID = <DialectName>" at the beginning of the DDL stream. If this is not found, then the class attempts to automatically discover the dialect by performing a best fit. Unfortunately, the "PARSER_ID = <DialectName>" is not valid DDL, and thus can never be included in a real DDL file. Rather than look for this kind of leading statement, the DdlParsers should look for the first comment block and simply attempt to find the dialect names in the comment text. This should be done in a case-insensitive way, and would ideally count the number of occurrences of each dialect name (thus handling the case where an Oracle DDL file contained both "oracle" and "postgres" in the comment; hopefully the "oracle" term would appear more than others). This of course is very imprecise, but it is perhaps only 'better than' the use of non-DDL statements. It is also desirable that the DdlParsers class should be tolerant of incorrectly typing the DDL stream. For example, lets say a DDL file contains a comment containing "oracle" and no other dialect name, but this DDL file is actually for PostgreSQL and merely contains the word "oracle" because it was converted from another Oracle DDL file. In this case, if parsing with the PostgreSQL parser results in an error, the DdlParsers should start over, behaving as though the dialect typing was incorrect, and should perform a "best fit". -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 3 months

1
0
0 / 0

[JBoss JIRA] Created: (DNA-639) JcrTckTest Missing Two Test Cases

by Brian Carothers (JIRA)

JcrTckTest Missing Two Test Cases --------------------------------- Key: DNA-639 URL: https://jira.jboss.org/jira/browse/DNA-639 Project: DNA Issue Type: Bug Components: JCR, Query Affects Versions: 0.6 Reporter: Brian Carothers Assignee: Brian Carothers The JcrTckTest in dna-jcr is missing two test cases that are part of the JCR 1.0 TCK test suite (and in the dna-jcr-tck module): ElementTest and XPathLevelTwoTest. Additionally, the dna-jcr-tck tests has some SQL tests misclassified as Level 1 compliance tests. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 3 months

1
2
0 / 0

[JBoss JIRA] Created: (DNA-638) Delete the 'dna-jcr-tck' project, as it is no longer used

by Randall Hauch (JIRA)

Delete the 'dna-jcr-tck' project, as it is no longer used --------------------------------------------------------- Key: DNA-638 URL: https://jira.jboss.org/jira/browse/DNA-638 Project: DNA Issue Type: Task Components: JCR Affects Versions: 0.6 Reporter: Randall Hauch Priority: Critical Fix For: 0.7 The 'dna-jcr-tck' project used to contain a subset of the JR TCK unit tests. It is no longer used, and should be removed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 3 months

1
1
0 / 0

[JBoss JIRA] Created: (DNA-159) Federate/cache content from a remote JCR (and DNA) repository

by Randall Hauch (JIRA)

Federate/cache content from a remote JCR (and DNA) repository ------------------------------------------------------------- Key: DNA-159 URL: http://jira.jboss.com/jira/browse/DNA-159 Project: DNA Issue Type: Feature Request Components: Connectors Reporter: Randall Hauch Priority: Minor Fix For: Future Releases The primary use case for this feature is to allow an application to have a local DNA repository that is configured to be a local, cached copy of a single remote JCR repository. So, rather than having multiple sources, this use case would have a single source (using a connector to a remote JCR repository), and it would be configured to probably have a cache policy with a relatively short TTL. (Of course the TTL could be extended if the connector could listen to the remote repository to receive events, which would be propagated up to the local "federated" repository and would cause those particular changed instances to be purged from the cache. Ideally this could be made to be very lightweight and very easy to configure, maybe even using just an in-memory "integrated repository" (aka, cache). This use case is far superior to an implementation that uses remote calls for every operation. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 3 months

1
1
0 / 0

[JBoss JIRA] Created: (DNA-637) Write JOPR plugin to manage and monitor a JCR engine/cluster

by Randall Hauch (JIRA)

Write JOPR plugin to manage and monitor a JCR engine/cluster ------------------------------------------------------------ Key: DNA-637 URL: https://jira.jboss.org/jira/browse/DNA-637 Project: DNA Issue Type: Feature Request Components: Connectors, Federation, JCR, Tools Affects Versions: 0.7 Reporter: Randall Hauch Fix For: Future Releases Write a JOPR plugin that allows a user to manage and monitor a ModeShape engine or cluster. There are a number of things that can be monitored, but we'd want to come up with a good list of useful things. For example: - nodes in cluster - # of sessions for each repository - sources and their activity - events and journaling - search engine and it's use/update activity - sequencers and their activity - analyzers and their activity - executor services ? - other?? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 3 months

1
0
0 / 0

[JBoss JIRA] Created: (DNA-636) JcrConfiguration files should be able to specify node types by referencing one or more CND files

by Randall Hauch (JIRA)

JcrConfiguration files should be able to specify node types by referencing one or more CND files ------------------------------------------------------------------------------------------------ Key: DNA-636 URL: https://jira.jboss.org/jira/browse/DNA-636 Project: DNA Issue Type: Feature Request Components: JCR Affects Versions: 0.7 Reporter: Randall Hauch Fix For: 1.0 Right now it is not possible to load an entire configuration (including node types) from a file, unless the file contains the graph representation of the node types. It should be possible to specify in the configuration file the relative path (or URL) of one or more CND files, and then the JcrConfiguration should automatically load those CND files after it loads the configuration file. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 3 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

dna-issues January 2010