Skip navigation
All Places > Alfresco Content Services (ECM) > Blog > 2013 > July
If like me you have configured some custom transformers against the Alfresco repository in order to convert from one file type to another, you'll need to be aware of some changes that have been made in the 4.2 codeline currently available in the HEAD branch in SVN and in the latest nightly builds.

The major change is that the mimetype mappings which were previously defined via the Spring bean definitions have now moved to repository properties. This has the benefit that the Spring configuration is much simpler and sys admins can more easily change which transformers are used for specific transforms, as well as the priority assigned to them.

Today I added some default properties to the media-viewers add-on on Share Extras, which you may find useful as a guide to converting over any custom transformer configuration.

Previously in the project, the transformer mimetype mappings were defined on the transformers' Spring beans via the explicitTransformations property. Here is an extract.

<bean id='transformer.ffmpeg.flv'>


    <property name='explicitTransformations'>


            <bean class='org.alfresco.repo.content.transform.ExplictTransformationDetails'>

                <property name='sourceMimetype'><value>video/mpeg</value></property>

                <property name='targetMimetype'><value>video/x-flv</value></property>







This configuration configures this a transformer with the bean ID transformer.ffmpeg.flv, which is capable of converting an MPEG-2 file to Flash Video format (note that the transformation itself is performed by a separate worker bean since Alfresco 4.0, and that whilst not generally recommended, the explicitTransformation list can also be applied to that bean).

In 4.2.d onwards the explicitTransformation property is no longer used, so we must define the following repository properties in addition to the Spring configuration.

# Define a default priority for this transformer


# List the transformations that are supported




It is important to get the format of the properties right, with a prefix of content. followed by the Spring bean ID of the transformer (transformer.ffmpeg.flv in this case), followed by the suffixes above. First we define a numerical priority for this transformer, then each supported transformation must be listed separately, one on each line, with the source and target mimetypes identified by their default file extensions, which can be obtained from the mimetypes web script, e.g. http://localhost:8080/alfresco/service/mimetypes.

As per Alan's advice on this related JIRA ticket, you can simply add the properties to your installation's, and they will take effect immediately after a restart, but if your transformer config is packaged up in an add-on then you probably want to ship these properties with it, otherwise the transformer will be automatically configured to transform any mimetype into all others defined in the system (see this issue if you want to understand the consequences of this).

For the media-viewers project I utilised the ability of Alfresco Subsystems to pull in extended configuration properties placed on the classpath under alfresco/extension/subsystems. In this case I used the Transformers subsystem but perhaps thirdParty is also applicable for this, or you could even define your own custom subsystem!

I added the properties in a new file config/alfresco/extension/subsystems/Transformers/default/default/ in my project with the above contents (source). The config prefix is part of the standard project source layout and is removed from the classpath of the assets at build time, and the slightly obtuse file name ensures that different add-ons will not clash with each other if they both add additional properties (the file name can be anything, so long as it ends with the .properties extension.

Normally you would remove the explicitTransformations properties from the Spring configuration with these applied, in order to supress the warnings that are now output in the logs, but I made the decision to leave it in, in order to preserve backwards-compatibility with 4.0 and 4.1.

Thanks to the contributors davidyg and touchvignesh who reported these issues with the media-viewers add-on! The updated code is in the master branch on Github or you can grab a JAR file containing the latest code to try it out yourself.
CMIS 1.1

Content Management Interoperability Services (CMIS) 1.1 was recently approved as a standard by OASIS.   As a member of the CMIS Technical Committee from the beginning, I’ve always had a strong interest in this standard. And since joining Alfresco last year to provide technical leadership for our ecosystem of API’s, my interest is even keener. So I was glad to see the OASIS press release this morning, highlighting the strong support this standard is already receiving in the industry. And in particular, it was great to see that the press release included a quote from our own John Newton affirming Alfresco’s commitment to open standards and CMIS.

Unlike a lot of standards that get more complex over time, CMIS is moving in the direction of simplicity. For example, with the introduction in CMIS 1.1 of a Browser Binding, now even casual developers with some HTML and JSON skills can use CMIS to integrate content with their sites and applications. Richard Esplin’s recent post about the “Beauty of CMIS”  reminded me about the analogy between CMIS and the advent of SQL which simplified the lives of developers needing to access relational databases.   In a similar way, CMIS again simplifies our lives by making it possible to access content management data without needing to learn a new API.

If you want to learn more about the new features of CMIS 1.1, Jeff Potts provides a nice summary in his blog.   You may notice that a number of the CMIS 1.1 improvements Jeff mentions are just standardizations of patterns and API’s that Alfresco introduced years ago.   For example, the introduction of ‘Secondary Object-Types’ in CMIS 1.1 is a standardization of Alfresco’s ‘aspect ‘ modeling pattern.   That’s just another illustration of how Alfresco leads the way in content management standards. And if you want to start exploring CMIS yourself, you can see lots of examples in Jeff’s latest book, “CMIS and Apache Chemistry in Action”

I’m glad to see us making steady progress in the standardization of content API’s. Stay tuned to learn more about how Alfresco will leverage CMIS 1.1.

Filter Blog

By date: By tag: