Encoder does not support custom encoding algorithms

[Tomáš 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]

[Tomáš Kraus]

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

[Tomáš Kraus]

@glassfishrobot Commented
Reported by agladkowski

[Tomáš Kraus]

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

[Tomáš Kraus]

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

[Tomáš 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.

[Tomáš Kraus]

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

[Tomáš Kraus]

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

[Tomáš Kraus]

@glassfishrobot Commented
Was assigned to oleksiys

[Tomáš Kraus]

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