Why we need multiple clientlib categories and multiple servlet paths





could anyone please explain the use cases for below things.


We can mention multiple categories for client libraries, so what is the use case to define multiple categories? I  can use single category in JSP/HTML, defining as embeded and defining as dependency.


And same for servlets also we can define multiple paths, in which scenario we use multiple paths?





Accepted Solutions (1)

Accepted Solutions (1)





1.Best use case for a multiple clientlibs can be for optimised pages.You have 20 custom components out of which 4 of them can be used in homepage and all 20 in category pages. In this case, I will choose to create two clientlibs - clientlibs_homepage and clientlibs_all and will load clientlibs_homepage in the homepage. This ensures the page performance is at its best. There could many other use cases like this.

2. For servlets, take a use case of a CRUD operations where only read should be exposed to internet and all functions exposed to author instance. I will create two paths and I will whitelist the only one in the dispatcher filter.


Hope this helps,

Nirmal Jose

Answers (3)

Answers (3)



Every resource is having its one identity.

Like clientlib we have Categories, and for the servlet, we have path or resourceType.


what is your use case? I only know embed property where you can include multiple clientLib categories into one.


To recognize a resource, you need some identity and that is one, if you will have multiple, then how you will define it.




In general we use one category for one clientlib and we either invoke in either component/template we maintain or add as embed/dependency to other clientlibs we maintain using that category. General usecase for adding more than one category is to invoke the our own clientlib on the page/context which either shouldn't be modified to add this clientlib or don't have permissions.


Ex: For a custom clientlib used for dialog validation , can have a Category ID X and used as extraclientlibs on to the dialog but if the same validation is generic we can also mention one more page authoring category named cq.authoring.editor.sites.page or cq.authoring.dialog for all touch ui elements.


Similarly for servlets, we can have one servlet with multiple paths for example I have a user managment servlet to create/update/delete/get users I can define either one path with all HTTP methods or define different paths such as /bin/adduser, /bin/removeuser,/bin/updateuser, /bin/user/ and call services respectively




Hi @sathishreddy.,

This “categories” property of the String[] type identifies the categories into which the set of JS and/or CSS files within this cq:ClientLibraryFolder fall. The categories property, being multi-valued, allows a library folder to be part of more than one category (see below [0] for how this may be useful).


This value will be referenced when including the clientlib in the JSP of a component, as well as defining embedded clientlib inheritance at the template-level.
This categories property is also beneficial because it allows you to group several clientlibs into the same category, so one include can pull as many clientlibs that belong to that category with one CQ include.
For instance, if you place the following CQ includes into the <head>:

<cq:includeClientLib css="project.components" />
<cq:includeClientLib js="project.components" />

It might result in this HTML-output:

<link href="/apps/components/component1/clientlib.css?x32508" rel="stylesheet" type="text/css" />
<link href="/apps/components/component2/clientlib.css?x32508" rel="stylesheet" type="text/css" />
<link href="/apps/components/component3/clientlib.css?x32508" rel="stylesheet" type="text/css" />
<script type="text/javascript" src="/apps/components/component1/clientlib.js?x32508"></script>
<script type="text/javascript" src="/apps/components/component2/clientlib.js?x32508"></script>
<script type="text/javascript" src="/apps/components/component3/clientlib.js?x32508"></script 


[0]: https://docs.adobe.com/content/help/en/experience-manager-65/developing/introduction/clientlibs.html