[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
[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
[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