July 2009 - dna-issues - Jboss List Archives

[JBoss JIRA] Created: (DNA-452) Supply implementations for the different RequestProcessor methods in the federated connector

by Randall Hauch (JIRA)

Supply implementations for the different RequestProcessor methods in the federated connector -------------------------------------------------------------------------------------------- Key: DNA-452 URL: https://jira.jboss.org/jira/browse/DNA-452 Project: DNA Issue Type: Bug Components: Connectors, Federation Affects Versions: 0.5 Reporter: Randall Hauch Fix For: 0.6 The federated connector's fork- and join-processors don't override all of the process(...) methods for the different kinds of update requests. The default implementations do not work because of the fork and join separation. -- 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

14 years, 10 months

1
1
0 / 0

[JBoss JIRA] Created: (DNA-392) All sessions in a repository should share the same /jcr:system content

by Randall Hauch (JIRA)

All sessions in a repository should share the same /jcr:system content ---------------------------------------------------------------------- Key: DNA-392 URL: https://jira.jboss.org/jira/browse/DNA-392 Project: DNA Issue Type: Task Reporter: Randall Hauch Assignee: Randall Hauch Currently each JcrSession has its own copy of the /jcr:system content branch. Technically this is incorrect, since all of the information in this branch is common to and shared by all sessions/workspaces in the repository. One approach to making this work is to have a special workspace in the repository in which the content from the "/jcr:system" branch is placed, and have this workspace projected into each session. -- 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

14 years, 10 months

1
9
0 / 0

[JBoss JIRA] Created: (DNA-493) Integration tests should not be run via Maven by default

by Randall Hauch (JIRA)

Integration tests should not be run via Maven by default -------------------------------------------------------- Key: DNA-493 URL: https://jira.jboss.org/jira/browse/DNA-493 Project: DNA Issue Type: Task Components: Development Environment Affects Versions: 0.5 Reporter: Randall Hauch Assignee: Randall Hauch Fix For: 0.6 The dna-integration-tests project is currently included by default whenever 'mvn clean install' is executed. Now that they are taking considerable amount of time to execute (>1min), we should change the parent POM so that they are included only when specified via the command line. The benefit is that the developers don't have to wait for these integration tests to execute (unless they want to). But, to ensure no regressions, the continuous integration tests and the nightly Hudson jobs should be run with the integration tests enabled. -- 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

14 years, 10 months

1
4
0 / 0

[JBoss JIRA] Created: (DNA-483) RepositoryService Doesn't Expose Problems from startService

by Brian Carothers (JIRA)

RepositoryService Doesn't Expose Problems from startService ----------------------------------------------------------- Key: DNA-483 URL: https://jira.jboss.org/jira/browse/DNA-483 Project: DNA Issue Type: Feature Request Components: Graph Affects Versions: 0.5 Reporter: Brian Carothers Priority: Minor The repository service will work around problems with repository sources when it starts up, logging those problems to a local variable and not creating the corresponding repositories. However, this variable is not exposed, so callers cannot see why some repositories failed to start. -- 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

14 years, 10 months

1
3
0 / 0

[JBoss JIRA] Created: (DNA-486) Add integration test that uses the JPA connector

by Brian Carothers (JIRA)

Add integration test that uses the JPA connector ------------------------------------------------ Key: DNA-486 URL: https://jira.jboss.org/jira/browse/DNA-486 Project: DNA Issue Type: Sub-task Affects Versions: 0.5 Reporter: Brian Carothers Need to add a test for the JPA connector as well -- 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

14 years, 10 months

1
2
0 / 0

[JBoss JIRA] Created: (DNA-479) Workspace import does not work

by Randall Hauch (JIRA)

Workspace import does not work ------------------------------ Key: DNA-479 URL: https://jira.jboss.org/jira/browse/DNA-479 Project: DNA Issue Type: Bug Components: JCR Affects Versions: 0.5 Reporter: Randall Hauch Priority: Blocker Fix For: 0.6 The changes in DNA-466 did not change the JcrContentHandler implementation to use the new approach. The old way relied upon a SessionCache editor using a different batch, but that doesn't really work with the new GraphSession approach. Maybe the best way to fix this, at least in the interim, is to have a SessionCache instance for the workspace import. That would maintain the cache in memory (more than what is really needed), but it would save a ton of duplication. Several of the TCK unit tests are commented out because of this. -- 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

14 years, 10 months

1
5
0 / 0

[JBoss JIRA] Created: (DNA-492) BasicPathSegment Checks the SNS Index in equals But Not hashcode

by Brian Carothers (JIRA)

BasicPathSegment Checks the SNS Index in equals But Not hashcode ---------------------------------------------------------------- Key: DNA-492 URL: https://jira.jboss.org/jira/browse/DNA-492 Project: DNA Issue Type: Feature Request Components: Graph Affects Versions: 0.5 Reporter: Brian Carothers Priority: Trivial Since BasicPathSegment does compare the SNS index in the equals method, this does not prevent HashMap and HashSet from working correctly, but it does increase the likelihood of a collision. -- 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

14 years, 10 months

1
2
0 / 0

[JBoss JIRA] Created: (DNA-491) JodaDateTime Is Using Overly-Strict Equality Test

by Brian Carothers (JIRA)

JodaDateTime Is Using Overly-Strict Equality Test ------------------------------------------------- Key: DNA-491 URL: https://jira.jboss.org/jira/browse/DNA-491 Project: DNA Issue Type: Bug Affects Versions: 0.5 Reporter: Brian Carothers The JodaDateTime class, the default DateTime implementation for DNA, uses JODA DateTimes internally to represent instants in time in a time zone-neutral, machine portable fashion. By default, the equals method for JodaDateTime is using the DateTime.equals(Object) method[1]. This method checks that both objects represent equivalent logical instants AND have the exact same time zones AND are based on the same Chronology[2]. This implies that a date time representing 2:00 PM EST would not be ".equals" to another date time representing 1:00 PM CST on the same date, even though both represent the same logical instant. Additionally, DNA doesn't specify chronologies, leaving JODA to infer the chronology based on the date source. I recommend that we shift from using DateTime.equals(Object) to DateTime.isEqual(ReadableInstant)[3] internally to avoid these problems. This issue keeps the JPA connector from properly storing/reloading date properties on the TCK test. [1] - http://joda-time.sourceforge.net/api-release/org/joda/time/base/AbstractI... [2] - JODA Chronologies are basically types of calendar like ISO8660, Gregorian/Julian, etc. [3] - http://joda-time.sourceforge.net/api-release/org/joda/time/base/AbstractI... -- 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

14 years, 10 months

2
3
0 / 0

[JBoss JIRA] Created: (DNA-490) JPA Connector Does Not Always Compute SNS Indices Correctly

by Brian Carothers (JIRA)

JPA Connector Does Not Always Compute SNS Indices Correctly ----------------------------------------------------------- Key: DNA-490 URL: https://jira.jboss.org/jira/browse/DNA-490 Project: DNA Issue Type: Bug Components: Connectors Affects Versions: 0.5 Reporter: Brian Carothers The JPA connector has an off-by-one error that causes it to occasionally add two same-name siblings with the same SNS index. This behavior can be seen if the JPA store is used as the backing store for the JR TCK tests, as the data import contains two same-name siblings (/testroot/node2 has a multi-word name/jcr:xmltext) that both get the SNS index 1. -- 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

14 years, 10 months

1
2
0 / 0

[JBoss JIRA] Created: (DNA-489) JPA Connector Does Not Respect CreateNodeRequest.conflictBehavior()

by Brian Carothers (JIRA)

JPA Connector Does Not Respect CreateNodeRequest.conflictBehavior() ------------------------------------------------------------------- Key: DNA-489 URL: https://jira.jboss.org/jira/browse/DNA-489 Project: DNA Issue Type: Bug Components: Connectors Affects Versions: 0.5 Reporter: Brian Carothers The JPA connector (in BasicRequestProcessor) does not currently check the value of conflictBehavior() for CreateNodeRequests. This is a particular problem now that Graph.createIfMissing() has been replaced by Graph.create(...)...ifAbsent(), which relies on the conflictBehavior() semantics. -- 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

14 years, 10 months

1
2
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

dna-issues July 2009