Encoder does not support custom encoding algorithms

[Tomas-Kraus]

1. The Encoder does not write the presence of the optional components (see C.2.5, C.2.5.1) in the initial vocabulary. In our case encoding-algorithms flag is not set although we register the encoding algorithm using:

Encoder.setRegisteredEncodingAlgorithms(…)

Fixed by introduction of a new method:

Encoder.encodeInitialVocabularyOptionalComponentPresence(…)

2. If any of the optional components of the initial vocabulary are present (see C.2.5.3), the Encoder does not write them to the output.

Fixed by introduction of a new method:

Encoder.encodeInitialVocabularyOptionalComponents(…)

3. The Encoder does not provide a way to map element QNames to an encoding algorithm URI. This is required to locate an algorithm implementation to encode the element’s content during processing.

Fixed by two new methods:

FastInfosetSerializer.setRegisteredQNameToAlgorithMappings(…) FastInfosetSerializer.getRegisteredQNameToAlgorithmMapping(…)

Please see attached Encoder.patch for the list of all required changes.

Examples how to use custom encoding algorithms can be found in the following test:

EncodingTest.testCustomEncodingAlgorithm()

Environment

Operating System: All Platform: All

Affected Versions

[current]

[Tomas-Kraus]

• Issue Imported From: https://github.com/javaee/metro-fi/issues/30
• Original Issue Raised By:@glassfishrobot
• Original Issue Assigned To: @glassfishrobot

[Tomas-Kraus]

@glassfishrobot Commented Reported by agladkowski

[Tomas-Kraus]

@glassfishrobot Commented agladkowski said: Created an attachment (id=4) Encoder.patch

[Tomas-Kraus]

@glassfishrobot Commented agladkowski said: Created an attachment (id=5) Please ignore the previous patch and use this one.

[Tomas-Kraus]

@glassfishrobot Commented oleksiys said: Hi,

first of all, thank you for the proposed patch! I have several comments/questions on it.

1) Ideas, described in 1. and 2. look good for me. As for 3. - IMO it's not good idea to add those methods to Encoder API. Encoder itself supports serialization with custom encoding algorithms via specific encodeXXX methods. And IMO it's up to higher level serializers, like SAX, StAX, to decide how to use Encoder API. From your patch I understood that you want to support QName -> algorithm mapping in SAX serializer. If you want to support such a mapping - probably the best solution could be introducing of a new SAX serializer, which will extend the SAXDocumentSerializer and add mapping logic there?

2) Regarding implementation of 1. and 2. It looks good, but I have some questions on it... a) KeyIntMap.hasInitialItems() probably it should be implemented as "return _readOnlyMapSize > 0"? because _size - is number of elements added during runtime (just mutable elements). Pls. take a look at KeyIntMap.size() implementation "return _size + _readOnlyMapSize;" b) encodeInitialVocabularyOptionalComponent() IMO is not correct. Similar issue as described in a)

Will appreciate your thoughts.

Thanks.

[Tomas-Kraus]

@glassfishrobot Commented File: Encoder.patch Attached By: agladkowski

[Tomas-Kraus]

@glassfishrobot Commented File: Encoder.patch Attached By: agladkowski

[Tomas-Kraus]

@glassfishrobot Commented Was assigned to oleksiys

[Tomas-Kraus]

@glassfishrobot Commented This issue was imported from java.net JIRA FI-30