March 2009 - dna-issues - Jboss List Archives

[JBoss JIRA] Created: (DNA-78) Sequence ESB message for governance purposes

by Stefano Maestri (JIRA)

Sequence ESB message for governance purposes -------------------------------------------- Key: DNA-78 URL: http://jira.jboss.com/jira/browse/DNA-78 Project: DNA Issue Type: Feature Request Components: Sequencers Reporter: Stefano Maestri Assigned To: Stefano Maestri Fix For: 0.2 Sequence message from ESB message store can give useful informations from a SOA Governance point of view -- 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

15 years

2
5
0 / 0

[JBoss JIRA] Created: (DNA-218) Implement a Sequencer for Spring bean configuration files

by Ben Abernathy (JIRA)

Implement a Sequencer for Spring bean configuration files ---------------------------------------------------------- Key: DNA-218 URL: https://jira.jboss.org/jira/browse/DNA-218 Project: DNA Issue Type: Feature Request Components: Sequencers Reporter: Ben Abernathy Priority: Optional Fix For: 0.3 Implement a sequencer that can parse Spring 2.5.x bean configuration XML files and store information about each bean. In particular, look at storing information the bean's name and possibly its attributes including relationships with other defined beans (through refs). I haven't had a chance to identify any of the specific artifacts yet (documentation, demo, etc). I will create subtasks as necessary. -- 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

15 years

2
2
0 / 0

[JBoss JIRA] Created: (DNA-277) Fix all text files in source code to have consistent line feeds

by Randall Hauch (JIRA)

Fix all text files in source code to have consistent line feeds --------------------------------------------------------------- Key: DNA-277 URL: https://jira.jboss.org/jira/browse/DNA-277 Project: DNA Issue Type: Task Affects Versions: 0.3 Reporter: Randall Hauch Assignee: Johnny Verhaeg Priority: Minor Fix For: 0.4 Currently, all of the text files in our source code have a mixture of carriage returns and line feeds. And, our DNA preferences (for Eclipse) did not specify any special handling, so each developer's settings were used (and likely were the default settings for the platform). Regardless of the preference settings, however, Eclipse editors always keep the line termination characters used in each particular file, so if a file was created on Windows, it will have \r\n for all lines, even when that file is modified on Linux or OS X. There are a few cases where a file seems to have a mixture of line terminations. We should probably have a consistent line terminator in all files, and that terminator should probably be '\n', which is the line terminator on *nix, for a couple of reasons. First, the JBoss.org SVN repository is hosted on Linux, and being consistent probably helps somewhat. Second, some tools (including Git) rely upon the '\n' character for determining line feeds, so that rules out the Mac style line feeds ('\r'). Third, there really is no need to store multiple characters. We need to verify that the converting all files to use Unix line terminators is acceptable. If so, we need to convert all of the files (that need it), update the Eclipse preferences, and have all developers make sure their Eclipse preference settings are correct. -- 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

15 years

2
5
0 / 0

[JBoss JIRA] Created: (DNA-58) Create repository configuration and component

by Randall Hauch (JIRA)

Create repository configuration and component --------------------------------------------- Key: DNA-58 URL: http://jira.jboss.com/jira/browse/DNA-58 Project: DNA Issue Type: Task Components: Sequencers Reporter: Randall Hauch Assigned To: Randall Hauch Priority: Critical Fix For: 0.1 There needs to be a configuration object that wraps the sequencing service and makes working with the it easier. -- 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

15 years

3
19
0 / 0

[JBoss JIRA] Created: (DNA-282) Federation connector improperly handles root-level node with one projection of a non-root node from a single source

by Randall Hauch (JIRA)

Federation connector improperly handles root-level node with one projection of a non-root node from a single source ------------------------------------------------------------------------------------------------------------------- Key: DNA-282 URL: https://jira.jboss.org/jira/browse/DNA-282 Project: DNA Issue Type: Bug Components: Connectors Reporter: Randall Hauch Assignee: Randall Hauch Priority: Blocker The federation connector currently has a problem when configured to project a non-root node from a single source into the root node of the federated repository. The cache always has a root node with a specific UUID, and the single source's non-root node has a different UUID, so when the federation connector attempts to project that non-root node from the source into the root node of the federated repository, the cache is unable to store the node with the UUID from the source. This problem arose when working on DNA-281 - the test cases were changed to use the InMemory connector rather than the SimpleRepositorySource connector (used for testing only). The simple implementation didn't maintain UUIDs, whereas the in-memory implementation does. (This is one of the problems with using a "mock" or non-production implementation in tests.) So, although the code compiles, several of the federation connector's tests fail, and the problem also affects several of the JCR unit tests and the Getting Started repository example. Therefore, after these are fixed, the corresponding projects need to be added back into the POM 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

15 years

1
3
0 / 0

[JBoss JIRA] Created: (DNA-194) Implement update JCR capability

by Johnny Verhaeg (JIRA)

Implement update JCR capability ------------------------------- Key: DNA-194 URL: https://jira.jboss.org/jira/browse/DNA-194 Project: DNA Issue Type: Sub-task Components: JCR Reporter: Johnny Verhaeg Fix For: 0.3 -- 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

15 years

3
13
0 / 0

[JBoss JIRA] Created: (DNA-335) DNA's NodeTypeManager implementation does not allow multiple definitions with the same name

by Randall Hauch (JIRA)

DNA's NodeTypeManager implementation does not allow multiple definitions with the same name ------------------------------------------------------------------------------------------- Key: DNA-335 URL: https://jira.jboss.org/jira/browse/DNA-335 Project: DNA Issue Type: Bug Reporter: Randall Hauch The JCR Specification (version 1.0.1) does not preclude that there may be multiple property definitions with the same name, or that there may be multiple child definitions with the same name. JCR 1.0 (version 1.0.1) DOES say that there may be multiple residual definitions with the same name. However, the draft version of the JSR-283 specification does have a new section 4.7.15 that specifically addresses and allows multiple definitions with the same name, as long as they are distinguishable from the other definitions with the same name (for property definitions, this means the type must be different; for child node definitions, this means the required primary types attribute). There are a number of places where the logic is expecting a single property definition (or child definition) given a node type and a definition name. This is obviously flawed. Also, our logic to select the "best" property definition or "best" child node definition doesn't seem to be correct, in that it tends to favor less-restricted definitions that are lower in the type hierarchy rather than very good matching definitions higher in the type hierarchy. -- 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

15 years

2
9
0 / 0

[JBoss JIRA] Created: (DNA-101) potential user confusion between org.jboss.dna.spi.graph ValueFactory and ValueFormatException interfaces and similar javax.jcr interfaces

by Greg Haber (JIRA)

potential user confusion between org.jboss.dna.spi.graph ValueFactory and ValueFormatException interfaces and similar javax.jcr interfaces ------------------------------------------------------------------------------------------------------------------------------------------ Key: DNA-101 URL: http://jira.jboss.com/jira/browse/DNA-101 Project: DNA Issue Type: Feature Request Components: API Affects Versions: 0.2 Reporter: Greg Haber Priority: Trivial The new org.jboss.dna.spi.graph.ValueFactory and package org.jboss.dna.spi.graph.ValueFormatException interfaces may be potentially confusing to users that are using both DNA and the underlying JCR APIs in the same code. This is because there are interfaces with exactly the same names, and with very similar purposes (the JCR interfaces deal with instances of the javax.jcr.Value class, where the DNA interfaces are for standard Java objects), in the javax.jcr package. We should think about changing the names of the DNA interfaces to avoid such potential confusion. This is a very minor issue, I would not object if we decided to leave the interface names unchanged. -- 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

15 years

3
3
0 / 0

[JBoss JIRA] Created: (DNA-303) The workspace NamespaceRegistry implementation should be shared

by Randall Hauch (JIRA)

The workspace NamespaceRegistry implementation should be shared --------------------------------------------------------------- Key: DNA-303 URL: https://jira.jboss.org/jira/browse/DNA-303 Project: DNA Issue Type: Sub-task Components: API, JCR Affects Versions: 0.3 Reporter: Randall Hauch Fix For: 0.4 The JcrWorkspace class currently uses the GraphNamespaceRegistry, which implements DNA's NamespaceRegistry implementation on top of namespace mappings stored in a graph. While this works for a single ExecutionContext, having a shared implementation for multiple JcrWorkspace objects means that the update methods need to be done with the ExecutionContext of the user making the changes. This would require changing the design a fair amount. The NamespaceRegistry implementation would also need to be thread-safe. -- 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

15 years

1
2
0 / 0

[JBoss JIRA] Created: (DNA-301) Most state managed within the Workspace should be shared among multiple Session instances

by Randall Hauch (JIRA)

Most state managed within the Workspace should be shared among multiple Session instances ----------------------------------------------------------------------------------------- Key: DNA-301 URL: https://jira.jboss.org/jira/browse/DNA-301 Project: DNA Issue Type: Task Components: API, JCR Affects Versions: 0.3 Reporter: Randall Hauch Fix For: 0.4 Our current JcrWorkspace implementation is created to be used only by the one JcrSession instance associated with it. Currently, each Session would have it's own Workspace implementation, each of which would have its own copy of the namespace registry and node type manager. However, one common use case for JCR involves creating many Session instances for the same workspace (e.g., this is the web app scenario). This means that we'd have a lot of Workspace instances (same number as Session instances) each with their own copy of the data. In fact, the node type manager should actually be "owned" (at least logically) by the repository, per section 6.7.9: "There is one node type registry per repository, therefore the NodeTypeManager is not workspace-specific; it provides introspection methods for the global, repository-wide set of available node types." Therefore, a number of things that are currently in the JcrWorkspace implementation should be pulled out and reused for all JcrWorkspace instances created by the JcrRepository for the same logical workspace. This issue captures the set of tasks that are involved. -- 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

15 years

1
4
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

dna-issues March 2009