Skip to content
This repository was archived by the owner on Jan 22, 2024. It is now read-only.

Frequently Asked Questions

Jump to bottom
Chuck Dumont edited this page Sep 2, 2014 · 28 revisions

My app works without the aggregator but fails when using it. How can I debug the problem?

The aggregator supports various query args that invoke debugging features. These query args are supported when debug or development mode are enabled. To use the query args, you need to be able to propagate query args specified in the URL for your application to the aggregator loader extension config. See the sample application's test.html and loaderConfig.js to see how this may be done. The following query args can be used to help debug your application:

optimize
Value can be simple (default), whitespace, or none. Controls the level of optimization/minification performed on JavaScript and CSS files.
showFilenames
If true
noCache
If true, then the aggregator will ignore any cached data and build the response from scratch. It will also include the Cache-Contrl:no-store header in all aggregator responses.
expandRequire
If value = log, then diagnostic information related to require list expansion will be written to the browser's JavaScript console
hasBranching
If false(default = true), then has! plugin branching will not be performed.
The debugging query args are disabled by default, but can be enabled by specifying one of the following console commands: ``` aggregator setoption developmentMode true ``` or ``` aggregator setoption debugMode true ``` Alternatively, if you don't have access to an OSGi console, you can add ```developmentMode=true``` or ```debugMode=true``` to aggregator properties file and restart the server. See [Options](../wiki/Options) for more details, and for descriptions of the features enabled by debug and development modes.

Note: depending on the console command processor installed in your OSGi framework, the command separator can be either a space or a colon. To see which separator you need to use, try entering the commands aggregator help and aggregator:help. The examples in this page all use the space separator, but if your command processor uses the colon, then you should adapt the examples accordingly.

You can also try enabling loader debugging by setting the dojo-error-api and dojo-trace-api features, as well as specifying loader trace logging options (see the trace property in loaderConfig.js.

The following console commands are useful if the servlet is not running in development mode, or when editing certain type of content who's changes won't be recognized in development mode (e.g. inlined CSS or LESS imports).

aggregator clearcache <servlet-name>
aggregator validatedeps <servlet-name> clean

See Console Commands for a complete list of the Aggregator console commands and their descriptions.

How can I decode loader generated aggregator requests?

Loader generated requests can be decoded in the browser client. Copy the URL you want to decode to the clipboard and then paste it into the console command below as indicated:

require.combo.decodeUrl("<paste URL here>")

Note that URL encodings are application version specific, so the client will be unable to decode a URL generated by a different version of the application.

See Decoding Aggregator request URLs for more details.

Why does my application take such a long time to load each time I restart the Aggregator?

The Aggregator serializes the cache meta-data used to keep track of cache files approximately every 10 minutes (if necessary) and when the bundle Activator stop() method is called. If you are repeatedly starting and stopping your test environment without doing a proper shutdown of the framework (i.e. just terminating the JVM), then it is likely that the cache meta-data never gets serialized and the cache needs to be rebuilt from scratch every time the test environment is started. This situation can be verified by looking in the server trace logs for output similar to the following:

INFO: Cache metadata for aggregator not found.  Removing existing cache files.

There are a few ways you can avoid this problem:

  • Do a clean shutdown of the framework instead of killing the JVM to stop the test environment
  • Wait at least 10 minutes after starting the test environment before killing the JVM
  • Stop the Aggregator bundle with the ss stop command in the OSGi console prior to killing the JVM
Clone this wiki locally