[JBoss JIRA] Created: (DNA-102) setProperty method in SequencerOutput interface should enforce limitations on property value types
by Greg Haber (JIRA)
setProperty method in SequencerOutput interface should enforce limitations on property value types
--------------------------------------------------------------------------------------------------
Key: DNA-102
URL: http://jira.jboss.com/jira/browse/DNA-102
Project: DNA
Issue Type: Bug
Components: API
Affects Versions: 0.1, 0.2
Reporter: Greg Haber
Priority: Minor
The setProperty method of the SequencerOutput method, as it currently exists, accepts arbitrary single Objects or arrays of Objects as property values via its use of "Object..." in the method signature. In DNA-77, it was suggested that the current method definition should be replaced with multiple type-specific methods, but it was decided to not do this, and instead recommend use of ValueFactory to create the values used in this method.
The problem with this is that, by leaving the interface as is and having use of ValueFactory be optional, it is easy for users to set properties to value types that are not currently supported (meaning that they will see a run-time error somewhere else in the code in these cases, rather than a compile-time or run-time error at the actual point where the issue was introduced (their misuse of setProperty).
One possible way to enforce this in the interface is to define the interface as throwing some sort of exception if the value is not an instance of an allowed class. Another solution would be a more substantial revision of the interface to mandate use of ValueFactory to create property values.
--
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
14 years, 11 months
[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
[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