New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Versioned ClientLibs: MD5 does not change when modifying an embeddeds clientlib category #1203

Closed
kwin opened this Issue Dec 12, 2017 · 4 comments

Comments

Projects
None yet
2 participants
@kwin
Copy link
Contributor

kwin commented Dec 12, 2017

Currently the MD5 calculation only happens in

return md5Cache.get(new VersionedClientLibraryMd5CacheKey(htmlLibrary), new Callable<String>() {
, in case the clientlib is not in the cache.
The cache entries are itself only invalidated via (based on the event topic: com/adobe/granite/ui/librarymanager/INVALIDATED).

Now consider the following use case

  1. Client library with category a embeds client library with category b
  2. MD5 for a is correctly being generated once
  3. The category name of client library b* switches to b

The client library's MD5 of a is not invalidated, as there is no OSGi event which invalidates the embedding client library. Therefore the client library is requested with the same URL (and therefore potentially being delivered in the wrong version from the client's cache).

If an embedded clientlibrary is moved out of an embedding clientlib (in the example from above by switching from b to b*, both libraries are correctly invalidated, i.e. the embedded as well as the embedding one) but the invalidation does not take place vice versa.

@kwin

This comment has been minimized.

Copy link
Contributor

kwin commented Dec 12, 2017

Another smaller related issue is that the input stream in

is not closed!

@justinedelson

This comment has been minimized.

Copy link
Contributor

justinedelson commented Dec 12, 2017

yikes. I thought that DigestUtils closed the stream, but it looks like it didn't. good catch.

In terms of the core issue, I would suggest that this is a product defect. please raise this with DayCare.

@justinedelson

This comment has been minimized.

Copy link
Contributor

justinedelson commented Dec 12, 2017

Created separate issue for the stream issue.

@kwin

This comment has been minimized.

Copy link
Contributor

kwin commented Dec 13, 2017

I further investigated and subsequently opened #1208.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment