jaggr-web and non-osgi sample - Implementation of review comments

[projsaha]

No description provided.

[buildhive]

OpenNTF » JavascriptAggregator #462 SUCCESS
This pull request looks good
(what's this?)

[chuckdumont]

To use ConcurrentMap in a thread-safe way, you need to use the putIfAbsent() method instead of containsKey() to add a key to the map only if it is not already there.

[projsaha]

Here are the pending work that needs to be completed.

1. Inclusion of serviceprovider extension. This will need a logic to read the initparams from the properties file kept in the WEB-INF/extensionPointsConf directory of the non-osgi sample. The key for initparams can be like initparam. in the properties file.
2. Implementation of following methods in PlatformServicesImpl -
   public URL getResource(String resourceName) - I think for the first method, the resources should be read from the classes folder in WEB-INF of the non-osgi sample
   public URI getAppContextURI() - This should point to the classes folder by default inside WEB-INF.
3. Support for configurations in aggrConfig.js -
   a. inlinedImageSizeThreshold - This is currently set to 0. This is bacause in the method protected String inlineImageUrls(HttpServletRequest req, String css, IResource res) in CSSModuleBuilder, imageUri.getPath() doesnt work for uris whose scheme is jar or classpath. I recommend having a util method like getPath() which returns uri.getPath() for normal uris and for uris whose scheme is classpath/jar, we need to remove the scheme part and then use getPath() on the remaining file uri.
   b. notice
   c. aggregator.properties - this will be part of the nonosgi sample after we implement the getResource() in PlatformServicesImpl
4. Handling of .less modules - this module wasnt getting loaded as part of the aggregated response for the non-osgi sample.
5. Replace the folder name "WebContent" with a unique the folder name for jaggr-core js resources. The reason is we want to use the jar generated by building jaggr-core and put it in the lib of the non-osgi sample. To access the js resources if it lies in WebContent folder, the path name would like "classpath:///WebContent/". This is very generic and it may clash with any other jar files which has "WebContent" as a folder.
6. The paramter moduleIds not part of request that is constructed from the non-osgi sample client - The request that is constructed from the non-osgi sample does not have js modules defined in moduleIds paramter, as is the case with osgi sample.
7. Remove the use of separate dojo war to cater to non-agregated resources. Currently to cater to non-aggregated dojo resources, we need to deploy additonal war with the dojo modules. The redirection happens in the loaderConfig.js where we redirect the request to the context root of the separate dojo web app.

[chuckdumont]

Thanks Projjwal!

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}