Community
Participate
Working Groups
There is a requirement from IBM to simplify maintenance and packaging of large numbers of GLA adapter configuration files. For example, for many log types, the adapter configurations have common components such as Sensor and Outputters. Another example is an application may want to package several versions of an adapter configuration, the only difference between them being the outputter to send the parsed data to different destinations. It would be useful to have the ability to fragment the adapter configuration to several files so that multiple files can reference the same configuration components. For example, the GLA Adapter Configuration Editor could include a check box and file name specification on the details pane of the following elements of the adapter configuration to save them as separate files: Adapter Context Sensor Extractor Parser Formatter Outputter Also, file specification for the above elements can be added to the GLA preferences page. These would be used when creating a new adapter so that configurations can be created from common components. Note, the Adapter file specification should be an absolute path. The file specification for the other elements can be a relative path, relative to the Adapter path. Relative paths can facilitate packaging of the files in a common directory structure.
A suggested implementation is to use XML External Entity References in the root adapter configuration xml file to reference the other component files. I'll attach a sample set of files. The advantage of that approach is that no GLA schema or run-time changes are required and there are no backward compatability issues.
Created attachment 33833 [details] zip containing a fragmented adapter configuration using entity references
I discussed with Elena from EMF team about this request and here are some things that makes the implementation really difficult: - per XML Infoset specification (http://www.w3.org/TR/xml-infoset/#intro.entities) entities are expanded and are not required to be reported by the processor - therefore serialization is not guaranteed - adding this support to EMF or customizing our save mechanism will be hard - similar to CDataSections and Comments, the XMLTypeDocumentRoot interface will need to be changed to support entities, this means a change not only in XMI but in Ecore itself I would rather suggest a model change that will allow us to achieve the requested behavior in a clean way (like using modeled references to objects stored in other resources). There is also a way in EMF 2.2 (containment proxies) which should allow us to split the content of a resource in several files, this will need some model changes and the serialized form will not follow the adapter schema (but will work in EMF) because of the why the resources are linked together.
Due to lack of resources this enhancement request is resolved as WONTFIX. Please feel free to reopen if you consider it's a required enhancement.
Closing.
As of TPTP 4.6.0, TPTP is in maintenance mode and focusing on improving quality by resolving relevant defects and increasing test coverage through test creation, automation, Build Verification Tests (BVTs), and expanded run-time execution. As such, TPTP is not delivering enhancements. As part of the TPTP Bugzilla housecleaning process (see http://wiki.eclipse.org/Bugzilla_Housecleaning_Processes), this enhancement is resolved as WONTFIX. For this enhancement to be considered, please re-open with an attached patch including the Description Document (see http://www.eclipse.org/tptp/home/documents/process/development/description_documents.html), code (see http://www.eclipse.org/tptp/home/documents/resources/TPTPDevGuide.htm), and test cases (see http://www.eclipse.org/tptp/home/documents/process/TPTP_Testing_Strategy.html).
