Skip navigation
All Places > Alfresco Content Services (ECM) > Blog > 2018 > June

This post will allow you create an additional filter to your datalist in a simple and fast way.


  • AIO project or failing [your-project]-platform and [your-project]-share
  • Alfresco SDK 3.0


  1. Overwrite js [] webscript files
  2. Overwrite config [] webscript file





Step 0:

First of all create your AIO project in your IDE.


Step 1:

Copy to your platform project path:

src > main >  resources > alfresco > extension > templates > webscripts > org > alfresco > slingshot > datalists


This will overwrite the [] js webscript file.


Edit file and add else if() block in the getData() function:

if (filter == null || filter.filterId == "all")
else if (filter.filterId == "MyCustomFilter")
     // Use non-query method
     var parentNode = parsedArgs.listNode;
     if (parentNode != null)
         var pagedResult = parentNode.childFileFolders(true, false, Filters.IGNORED_TYPES.concat(Filters.IGNORED_ASPECTS), 1, -1, REQUEST_MAX, "cm:name", true, null);
         allNodes =;



We have modified childFileFolders() function for a simple test but at this point you could implement your request to the repository saving all your response items in allNodes var.


Step 2:

Copy  filter.get.config.xml to your share project path:

src > main > resources > alfresco > web-extension > site-webscripts > org > alfresco > components > data-lists


This will overwrite the [] config webscript file.


Edit filter.get.config.xml file and add <filter tag line:

    <filter id="MyCustomFilter" label="Custom filter label" />


This new tag will show a new filter in the left datalist page menu.




If you want implement a complex repository query for your filter  check out and overwrite evaluator.lib.js and filters.lib.js files in platform project and modify its nested functions.



I hope it saved you time and have a nice day




A Smaller Tomcat Docker Image

Posted by nicdoye Employee Jun 11, 2018

Because images should be small and secure




For various reasons, at Alfresco, we are using Oracle JDK and CentOS for our base java image. On top of that we’ve ported the standard tomcat Dockerfile, to make a base tomcat image. Unlike the official tomcat images, we also ship a full JDK (and not just the JRE). Like the official images, we obviously ship the native tomcat library.


Other constraints mean that we are not yet in a situation to ship an image based on musl.


Purely as an experiment, how small can we make a glibc-based image that satisfies most of these constraints?




Even if we were able to ship based on Alpine Linux, there is a bigger issue: every binary (and library) on the image increases the attack surface area (and the maintenance overhead for us and our customers).




Finding out the size of a(n already pulled) image is pretty easy. Here’s an example:

docker inspect openjdk:8-jdk-alpine | jq '.[] | "\(.Size) \(.RepoTags[0])"'

Enter Distroless


Now running anything non-trivial on Docker’s scratch image is “unpleasant”. Luckily for us, those lovely people at Google have created Distroless which has a small base size of about 16 MiB. They have a base version and a specific version for java.


Sadly, the java version runs java -jar and because tomcat relies on having two jars to start (bootstrap.jar and tomcat-juli.jar) I couldn’t work out how to start it like that. (If you can show me how, I’ll update the article.)


Distroless uses libraries from Debian stretch, but is missing some that are needed to run java. Firing up debian:stretch from docker hub, installing openjdk-8-jre-headless or openjdk-8-jdk-headless and running ldd against the included binaries and libraries we see we are missing four, which we can COPY in: libzlibstc++libgcc_s and libapr-1 from a multi-stage build.




Now Distroless is already 12 MiB larger that Alpine, which is surprising, as it contains very little. Also, binaries and libraries compiled against glibc are also bigger: is 49% bigger; rt.jar is 87% bigger. Which means, from a pure size view the results are disappointing:


NameBase OSJava VendorJRE/JDKTomcatMiB
tomcat:8.5-slimDebian SlimOpenJDKJRE8.5213


The JRE image is 41% larger than Alpine, and the full JDK version bigger still. Clearly we’re a lot smaller than the other glibc-based images.



The security win over the tomcat:8.5-alpine is pretty small, too. There are only 61 packages (including OpenJDK) in that image and many of them do not contain libraries or binaries.


Over a full glibc-based Linux distro (even Debian slim) there is a win: Distroless base only contains glibclibssl and openssl; once we add the other 4 libraries, that leaves very little scope for security vulnerabilities. The downside is that we have to monitor the .debs containing libraries via an external mechanism and update accordingly.




Firstly, we haven’t created a OracleJDK on “Distroless but with Debian’s libraries replaced by CentOS’” image, which would be the most useful for Alfresco. I’ll leave that for another day.


Clearly, Alpine Linux is amazing in what it can squeeze in to such a small space, and only has a slightly larger attack surface.


From a security point of view, we have created something better than the other glibc-based distros, and if that’s important to you, then using Distroless is a viable option.


Image credit: "A cat on HMAS Encounter" by photographer not identified. [Public domain] via Wikimedia Commons.


This article has also been published on Medium.

Filter Blog

By date: By tag: