Custom Xtype For Pathfield BrowseDialog

Sometimes the xtypes provided by AEM doesn’t fulfill our requirements. So we need to design our custom xtypes on regular basis.


While working with xtype pathfield, I stumbled upon a use case/problem. I wanted a pathfield so that  I can choose the product under /etc/commerce/products/accunity/en_us/products hierarchy by a productName property.

Note: Generally, pathfield can show the nodes by its name or jcr:title.

Steps I followed:

  1. I created a widget of xtype:pathfield
  2. If I opened my  dialog, I could select any values under /content.
  3. So needed to set rootPath in the widget.
  4. The nodes under products are of type nt:unstructured. By default, pathfield doesn’t allow this types of nodes in the tree hierarchy.
  5. So added a property predicate: nosystem


Now the pathfield looked like this:

But still, it is a very tedious task for the author to select a particular product. I wanted pathfield to show the productName in place of node-name. So I decided to write custom xtype.

But how?

The first question here is how this tree structure shows up here:

So while debugging my dialog, I found, it calls currentPath.ext.json and shows the “name”property of  JSON in the tree hierarchy. 

So next step for me was to change this servlet.

The Next Question was from where this servlet is getting called.

The answer is browserDialog widget. Inside pathfield widget, it is calling browserDialog to show this tree structure.

Note: Go to browseDialog.js

Change this part:

Here is the updated browseDialog.js

We can’t make this change in the /libs section. So, I made my own xtype as productPathfield and add a custom browseDialog in pathfield.js with this modification.

Note: xtype pathfield doesn’t fulfill my requirements so needed to change it with productPathfield.

After all the changes, we can see our desired results here:

Please leave your precious comments of what you think about this approach. Happy to learn better solution for the same problem.

The Performance Guidepost

Imagine on a bright sunny day you open up your analytics dashboard and you notice the visitors graph going high and high and high and suddenly drops all of a sudden.

You will be wondering what is happening, only to find that your colleague had started a nice promotion and due to the promotion the website load increased multifold.

But what happened all of a sudden? Why the drop in visits? Ah… the promotion became too popular as it had gone viral in the social network and print media. And due to the heavy demand more number of users visited and the site could not take up the anticipated load and crashed.

A poor show, in spite the excellent job by marketing team.

What could have been done to avoid such situation and do not let the customer suffer and the drop in sales and site visitors?

Performance testing is the answer on anticipated site load.

What is Performance Testing?

Triple “S” check is a must for the public facing websites.

  • Speed – Determines whether the application responds quickly.
  • Scalability – Determines maximum user load the software application can handle.
  • Stability – Determines if the application is stable under varying loads.

And all three can be measured using performance testing.

Performance testing is the investigation done either to determine or to prove the response time, scalability and performance of the website to ensure that they will perform well under their expected regular workload, at peak load and uncover inconsistencies across different operating systems/devices.

The goal of performance testing is not to find bugs but to eliminate performance bottlenecks and tune the system for maximum load. This is also to determine the maximum threshold the website can take.

Common Performance Problems

  • Poor Response Time: Once the user performs an action and user has to wait for so long before the response is provided. This can lead to poor user experience.
  • Poor Load Distribution: Poor load distribution can cause slow response time by incorrectly assigning new site visitors to hanged up servers. If too many people are on the same server, they’re going to experience difficulties, even if the overall system is well under capacity. Check the sites of some of the big players and you will notice the site loads in a flash of moments.

Types of Performance Testing

  • Load Test: Generally a load test is conducted to understand the behaviour of a system under the specific expected load. It helps to identify the maximum operating capacity of an application as well as any bottlenecks and determine which element is causing degradation. E.g. If the number of users are increased then how much CPU, memory will be consumed, what is the network and bandwidth response time.

It also helps in measuring the response time, throughput rates, and resource-utilization levels, and to identify the breaking point, and the peak load the website can handle.

This can answer questions like, what is the maximum number of users that can use the system without any impact on performance and acceptable response time.

  • Stress Test: Stress testing refers to the testing of website to determine whether its performance is satisfactory under any extreme and unfavourable conditions, which may occur as a result of heavy network traffic, process loading and maximum requests for resource utilization. Stress testing enables to identify how the website behaves under extreme load conditions.

This will answer questions like, what is the maximum peak load the system can handle and determine if the system will perform sufficiently if the current load goes well above the expected maximum limits.

  • Soak / Endurance Test: This is usually done to determine if the system can sustain the continuous expected load, this helps in detecting potential memory leaks and utilization. Also to check the performance degradation when the system is being used for long duration.

This can answer questions like, if the promotion becomes very popular and the load of system is way beyond for a very long duration, can the system handle such situations?

  • Spike Test – Spike testing is a subset of stress testing.  A spike test is a type of performance test focused on determining reaction to a sudden large spikes in the load generated by users.

This can answer questions like, if the competitor, runs a promotion and we are unaware of it, due to such situations users visiting the site for similar promotions on our site, there could be sudden spike of users and if the system can handle such situations.


Lot of performance testing tools are available for different types of tests and it is quite difficult to cover all types of test using one.

Jmeter is one of the renowned open source tool designed to load test functional behaviour and measure performance.

Lets explore more about Jmeter and its functioning in the upcoming blog.


Performance Testing is a must before the website goes to market, as poor performance and inconsistent behaviour of the site may lead to inadequate reputation, poor user experience and will not meet the sales goals.

Hence its concluded that it’s a must to perform performance testing at initial stage of building website and regularly in different intervals. Analytics can help monitor the peak loads and help plan for performance testing. This can go a long way building customer trust, relation and not only retain but expand customer base. Lets read about that too in another upcoming blog.

Maven Dependencies Version Issue in AEM

In this post, I will explain package version issues for AEM package dependencies. Here is the scenario where I got this issue:

Issue Description

In one of my project, I had to create a tool for AEM that supports AEM5.6.1 and AEM6.x versions. For some dependencies, these AEM version instances (CQ5.6.1, AEM6.0, AEM6.1, and AEM6.2) needed to use different version of dependencies.

If I used an older version of these dependencies then my bundle did not work in AEM6.2 and remains in installed state. If I used the higher version of these dependencies then my code was not working for the older versions of AEM (CQ5.6.1, AEM6.0, AEM6.1).

Underlying Reason

Versions available for these package dependencies in OSGi container are not same as required by my bundle.
For example, lets take the case of cq-commons dependency.

AEM6.2 supports 5.9.22 version of cq-commons dependency.
AEM6.1 supports 5.8.32 version of cq-commons dependency.
AEM6.0 supports 5.7.12 version of cq-commons dependency.
AEM5.6.1 supports 5.6.4 version of cq-commons dependency.

Because of these different versions some of my java packages ( were not getting resolved.


Here are the list of steps, I followed, to resolve this issue.

Step 1

I have chosen the lowest version of available dependency i.e. 5.6.4 and added a dependency entry in the parent pom.xml file.

Step 2

I defined a property in <properties> section in my parent pom.xml file as mentioned below.

Note: – you can use whatever tag name you want but to make it readable I used this name.

Step 3

I have updated my <maven-bundle-plugin> as shown below-

Here I have used <DynamicImport-Package> tag. Now I have built my project for different AEM versions and it works fine for me in all AEM versions.

Here is the list of questions that may come in your mind:

Q1). What exactly <DynamicImport-Package> tag do?
It will add an entry in MANIFEST.MF file for the packages you mentioned in <bundle.dynamicImport.package> tag. MANIFEST.MF file entry is-

Q2). How bundle start working after using the <DynamicImport-Package> tag?
For answering this question-
First, we need to know about, How OSGi container works?
So, When you deploy your bundle into AEM OSGi container then first OSGi container checks that the available Java Packages versions are compatible with the versions of packages listed in Import-Package tag of your bundle MANIFEST.MF file. If version of Import-Package is not present then you will get an error as written below-

But if you defined these packages in <DynamicImport-Package> tag then OSGi container will not perform the versions checking for these packages and provides the available package definitions to your bundle at runtime.
i.e. using <DynamicImport-Package> is a kind of hack that short-circuits OSGi version checking process.

Note:- It is not recommended to use <DynamicImport-Package> with OSGi container.

Q3). Could we add multiple entries in <bundle.dynamicImport.package> tag?
Yes, you can add multiple packages using comma( “,”) delimiter. for ex.