[jira] [Commented] (SM-4383) activation-api spec modification to CommandMap leads to invalid registrations and memory leak

["Michiel Hendriks (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/SM-4383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17102404#comment-17102404 ] 

Michiel Hendriks commented on SM-4383:
--------------------------------------

I was trying to write a test case and fix. But I've got no idea how to do this for code which replaces Java API using the _java.endorsed.dirs_ construction.

I see that the Geronimo had the [same issue|https://github.com/apache/geronimo-specs/commit/f13a82040950dc3174263ff5feea52f9dac2b740], and doesn't look like they have addressed it.

> 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
>            Priority: Major
>
> 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)