[
https://issues.apache.org/jira/browse/SM-4383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jean-Baptiste Onofré updated SM-4383:
-------------------------------------
Fix Version/s: (was: activation-api-1.2.1_2)
> activation-api spec modification to CommandMap leads to invalid registrations
> and memory leak
> ---------------------------------------------------------------------------------------------
>
> Key: SM-4383
> URL: https://issues.apache.org/jira/browse/SM-4383
> Project: ServiceMix
> Issue Type: Bug
> Components: specs
> Affects Versions: specs-2.8.0, specs-2.9.0
> Environment: ServiceMix 7.0.1 using
> org.apache.servicemix.specs.activation-api-1.1-2.8.0
> Reporter: Michiel Hendriks
> Assignee: Jean-Baptiste Onofré
> Priority: Major
> Fix For: activation-api-1.2.1_3
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> A common way for libraries to register their content handlers is via the
> CommandMap API (rather than using a mailcap file). For example BouncyCastle's
> bcmail does this (a lot).
> This is generally done in this way:
> {code:java}
> CommandMap commandMap = CommandMap.getDefaultCommandMap();
> if (commandMap instanceof MailcapCommandMap) {
> ((MailcapCommandMap) commandMap).addMailcap("application/pkcs7-mime;;
> x-java-content-handler=org.bouncycastle.mail.smime.handlers.pkcs7_mime")
> }
> {code}
> This is not a problem with the default MailcapCommandMap implementation. But
> with the overridden MailcapCommandMap, and subclassed OsgiMailcapCommandMap,
> of this spec this leads to a memory clean of duplicate CommandInfo instances,
> and for the OSGi case invalid registrations.
> Problem 1, invalid registrations:
> For OsgiMailcapCommandMap these programmatically added commands will be
> registered to the last bundle to get its mailcap file registered via the
> Activator:
> [https://github.com/apache/servicemix-specs/blob/master/activation-api-1.1/src/main/java/org/apache/servicemix/specs/activation/OsgiMailcapCommandMap.java#L45]
> If the Activator would nullify the "currentBundle" at the end of rebuilding
> the command map, then entries later registered via the CommandMap via code
> will not be associated to the last bundle.
> In
> [https://github.com/apache/servicemix-specs/blob/master/activation-api-1.1/src/main/java/org/apache/servicemix/specs/activation/Activator.java#L102]
> This would do the trick
> {code:java}
> commandMap.addMailcap("", null);
> {code}
> With that in place the call to createDataContentHandler will mostlikely fall
> through to finding the class via the classloader.
>
> Problem 2, memory leak:
> In the above example, calling addMailcap with the same value multiple times
> will result in multiple registrations.
> {code:java}
> commandMap.addMailcap("application/pkcs7-mime;;
> x-java-content-handler=org.bouncycastle.mail.smime.handlers.pkcs7_mime")
> commandMap.addMailcap("application/pkcs7-mime;;
> x-java-content-handler=org.bouncycastle.mail.smime.handlers.pkcs7_mime")
> // produces 2 entries
> {code}
> This is sadly a thing bcmail does with signing SMime messages.
> With the standard MailcapCommandMap implementation this has no effect as
> duplicated classnames are filtered out and the CommandInfo instance is
> created when on request.
> The overridden MailcapCommandMap simply appends every CommandInfo to the list
> without checking for duplicates:
> https://github.com/apache/servicemix-specs/blob/da08e2fd3ad8bdb026e5e655ae474f35638c52eb/activation-api-1.1/src/main/java/javax/activation/MailcapCommandMap.java#L301
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
