[
https://issues.apache.org/jira/browse/QPID-7683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15926395#comment-15926395
]
Lorenz Quack commented on QPID-7683:
------------------------------------
* Some local variables in {{ListToAmqpListConverter}} are called {{map}}
instead of {{list}}
* In the {{MimeContentConverterRegistry}} we should throw an exception or at
least print a warning if two converters try to occupy the same slot.
i.e., two {{MimeContentToObjectConverter}} with the same mime type or two
{{ObjectToMimeContentConverter}} with the same object class and rank.
I think this is especially dangerous in a plugin architecture where the
implementations are largely independent.
Maybe we should even allow plugins to occupy the same slot and just put them
into an arbitrary order ([guava
multimap|https://github.com/google/guava/wiki/NewCollectionTypesExplained#multimap]).
* Was giving {{SerializableToJavaObjectStream}} the lowest rank intentional?
... hold your horses ... reviewing
{{MimeContentConverterRegistry#getBestFitObjectToMimeContentConverter}} it
looks like the converter with the *highest* rank gets picked. I found this
surprising. You maintained everything in a nicely ordered list and then tricked
me by picking the last entry instead of the first.
* The inner loop in
{{MimeContentConverterRegistry#getBestFitObjectToMimeContentConverter}} seems a
bit convoluted. Why do you go through the pain of making a copy and using an
iterator? I think this would be a simpler approach that would work: {code}
for (Map.Entry<Integer, ObjectToMimeContentConverter> entry :
_classToRankedMimeContentConverter.get(i).entrySet())
{
if (entry.getValue().isAcceptable(object))
{
potentialConverters.put(entry.getKey(),
entry.getValue());
}
}{code}
> Remove knowledge of 0-x encoders from the AMQP 1.0 protocol layers
> ------------------------------------------------------------------
>
> Key: QPID-7683
> URL: https://issues.apache.org/jira/browse/QPID-7683
> Project: Qpid
> Issue Type: Improvement
> Components: Java Broker
> Reporter: Keith Wall
> Fix For: qpid-java-broker-7.0.0
>
> Attachments:
> 0001-QPID-7683-Refactor-AMQP-1.0-module-to-avoid-knowledg.patch
>
>
> Currently the AMQP 1.0 protocol layer makes direct use of BBEncoder (0-10)
> and TypedBytesEncoder (supported by the Qpid Client for the encoding of
> list/map message content for 0-8..0-10). This prevents the 0-x encoders from
> being moved to their respective module.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
