January 2009 - dna-issues - Jboss List Archives

[JBoss JIRA] Created: (DNA-264) Connectors may need to determine the MIME type for content

by Randall Hauch (JIRA)

Connectors may need to determine the MIME type for content ---------------------------------------------------------- Key: DNA-264 URL: https://jira.jboss.org/jira/browse/DNA-264 Project: DNA Issue Type: Task Reporter: Randall Hauch Assignee: Randall Hauch Some connectors may need to be able to determine the MIME type for content, and there's currently no way in the connector API to do that. The 'dna-graph' project does have MimeTypeDetector interface, but that's meant as a lower-level interface for an implementation. MimeType was designed to be the main entry point for general components, but that's currently in 'dna-repository' (and connectors don't currently require that). -- 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-91) Implement node type management

by Randall Hauch (JIRA)

Implement node type management ------------------------------ Key: DNA-91 URL: http://jira.jboss.com/jira/browse/DNA-91 Project: DNA Issue Type: Sub-task Reporter: Randall Hauch -- 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 months

3
13
0 / 0

[JBoss JIRA] Created: (DNA-253) Add support in the JBoss Cache connector for JBoss Cache 3.0.

by Randall Hauch (JIRA)

Add support in the JBoss Cache connector for JBoss Cache 3.0. -------------------------------------------------------------- Key: DNA-253 URL: https://jira.jboss.org/jira/browse/DNA-253 Project: DNA Issue Type: Thirdparty Change Reporter: Randall Hauch Fix For: 0.4 JBoss Cache 3.0.0.GA is available (as of Nov 19, 2008), so we should add support for using it in DNA's JBoss Cache connector. The connector is currently using 2.2.1.GA. 3.0.0.GA is supposed to be API compatible with 2.2.1.GA, but there are some deprecated methods and a new configuration format. Hopefully we're not using any deprecated methods, and the connector does almost no configuration (instead, it assumes that any cache that requires connfiguration will be placed inside JNDI, or the name of the configuration will be referenced by the JBossCacheSource. -- 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 months

2
6
0 / 0

[JBoss JIRA] Created: (DNA-114) Create MS Office file sequencer

by Randall Hauch (JIRA)

Create MS Office file sequencer ------------------------------- Key: DNA-114 URL: http://jira.jboss.com/jira/browse/DNA-114 Project: DNA Issue Type: Task Components: Sequencers Reporter: Randall Hauch Fix For: 0.2 Create a single sequencer that is capable of sequencing the MS Office files, including MS Word, MS Excel, and MS PowerPoint. All of the files' standard metadata (author, title, word count, page count, etc.) should be extracted, as should metadata specific to the different kinds of files. For example, the sequencer should extract all of the content of the Excel spreadsheets, while it should extract at least the slide titles (and ideally thumbnails). -- 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 months

2
8
0 / 0

[JBoss JIRA] Created: (DNA-153) Add support for Microsoft Word document metadata

by Randall Hauch (JIRA)

Add support for Microsoft Word document metadata ------------------------------------------------ Key: DNA-153 URL: http://jira.jboss.com/jira/browse/DNA-153 Project: DNA Issue Type: Sub-task Components: Sequencers Reporter: Randall Hauch Fix For: 0.2 -- 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 months

2
9
0 / 0

[JBoss JIRA] Created: (DNA-280) Create optimized versions of Location

by Randall Hauch (JIRA)

Create optimized versions of Location ------------------------------------- Key: DNA-280 URL: https://jira.jboss.org/jira/browse/DNA-280 Project: DNA Issue Type: Task Components: API, Graph Affects Versions: 0.3 Reporter: Randall Hauch Assignee: Randall Hauch Fix For: 0.4 The Graph API uses the Location class to represent the location (path and/or identification properties) of a node. So far, we haven't needed different implementations, but given that the current class has a number of optional member attributes and we'd like to add more, it is probably prudent to have different implementations that more optimally represent the combination of attributes that's possible. Currently, there are quite a few constructors and they are called in numerous places. However, every place that one is created, an ExecutionContext is available. Therefore, it seems like there are (at least) two valid approaches: 1) Change Location to an interface, create multiple implementation classes, define and implement a LocationFactory that instantiates the most appropriate implementation class, and add getLocationFactory() to the ExecutionContext. This approach mirrors the way that the properties and value types are created, but Location objects are not used as property values. It would even be possible to add a "with(LocationFactory)" method to ExecutionContext so that one can clone a context but specify the implementation of the LocationFactory that the clone should use. 2) Keep Location as an abstract class, but remove the constructors and replace with static factory methods. This would likely mean that there is a single set of implementations that never need to be customized. It also means that we could add methods that could return a new location with additional attributes set. For example: Location newLocation = location.with(uuid); Either way, we need to change the current implementation to be more flexible. I think the choice comes down to whether it's appropriate to be consistent with the factory-style approach used by property values, or whether Location is different enough and we know we'll only have a single family of implementations that don't need to be extended or customized. -- 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 months

2
7
0 / 0

[JBoss JIRA] Created: (DNA-88) Incorporate JCR TCK tests

by Randall Hauch (JIRA)

Incorporate JCR TCK tests ------------------------- Key: DNA-88 URL: http://jira.jboss.com/jira/browse/DNA-88 Project: DNA Issue Type: Sub-task Reporter: Randall Hauch -- 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 months

3
8
0 / 0

[JBoss JIRA] Created: (DNA-279) Various improvements to the Graph API

by Randall Hauch (JIRA)

Various improvements to the Graph API ------------------------------------- Key: DNA-279 URL: https://jira.jboss.org/jira/browse/DNA-279 Project: DNA Issue Type: Task Components: API, Graph Affects Versions: 0.3 Reporter: Randall Hauch Assignee: Randall Hauch Fix For: 0.4 The Graph API needs a few improvements, including: 1) add a request to verify the existance of a node (basically, this checks for existence and fetches the actual location) 2) add a way to copy a node by specifying the path of the desired location (in addition to the current mechanism of specifying the parent and inferring the name of the new node from the original). This could be accomplished by adding the desired name to the CopyBranchRequest, and then updating all of the RequestProcessor implementations to use this optional information. This may affect a number of classes. 3) make NamespaceRegistry.Namespace extend Comparable<Namespace> so that namespaces can be sorted naturally 4) improve the efficiency of the AbstractPath.equals(...) implementation, which is not efficiently iterating up the Path.Segment instances. -- 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 months

1
1
0 / 0

[JBoss JIRA] Created: (DNA-278) Create new utility class for determining validity of XML NCNames

by Randall Hauch (JIRA)

Create new utility class for determining validity of XML NCNames ---------------------------------------------------------------- Key: DNA-278 URL: https://jira.jboss.org/jira/browse/DNA-278 Project: DNA Issue Type: Task Affects Versions: 0.3 Reporter: Randall Hauch Assignee: Randall Hauch Fix For: 0.4 A namespace prefix in JCR must be a valid NCName, as defined by the XML specification. We need a utility to perform this checking. Currently, 'dna-common' is dependent upon only a minimal set of libraries (e.g,. logging and the optional JCIP annotations), and these do not have this utility. A few libraries do have such utilities, but then we'd be dependent upon a library just for one class. Implementation-wise, it doesn't seem to be too tough a nut to crack. The only trick is how to quickly identify whether a character matches one (or more) of the character classes (as defined by the spec). One approach would be to use ranges within each method, but that would require doing multiple math operations on each lookup. The other approach would be to precompute the information so that lookups are fast. Even with this latter approach there are multiple options for the structure: have a bit set for each class keyed by character; the other is to have a one bitmask for each character (in a map or array). The latter seems fastest (single index and a few bit operations) and smallest in memory footprint (only one data structure the size of the characters). -- 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 months

1
2
0 / 0

[JBoss JIRA] Created: (DNA-274) commons-beanutils 1.8.0 dependency needs to be uploaded to JBoss repository

by Johnny Verhaeg (JIRA)

commons-beanutils 1.8.0 dependency needs to be uploaded to JBoss repository --------------------------------------------------------------------------- Key: DNA-274 URL: https://jira.jboss.org/jira/browse/DNA-274 Project: DNA Issue Type: Bug Components: Development Environment Affects Versions: 0.4 Reporter: Johnny Verhaeg Assignee: Johnny Verhaeg Priority: Blocker Both dna-common-jdbc and dna-connector-jdbc-metadata depend on this library. -- 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 months

1
1
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

dna-issues January 2009