@orotas - that's what I meant by "ugly" Generating JS (or CSS or JSON) with Sightly is possible, but because it uses HTML constructs, it looks weird. Although arguably the same thing could be said about JSP or ESP.

Correction - I take it back. Sightly can be used to generate JS. It's just a bit ugly because you still need to use HTML tags and you must be sure to use data-sly-unwrap. Sorry for the misinformation. The script name would look like controller.js.html (vs. controller.js.jsp).

No. Sightly (at least now) is only able to generate HTML. You could generate JS inside <script> tags in an HTML page, but you can't use Sightly to generate a standalone JS script. The same would be true for JSON, CSS, etc.

The bundle location should be a treated as an opaque identifier. Don't think of it "pointing" to anything. The version of the bundle should be determined by using the version, not the location.

I think you're missing my point. The fact that the bundle location does not change during your deployments is expected and is not a problem. If the bundle location changed during a deployment, that would be a problem as it would be specification violation.

As I said - you are seeing the expected behavior. In what way is this problematic?

Right, but you already have the bundle installed. So when you install a new version, the bundle is being updated. Both the Content Packages and the OSGI Console will automatically choose to perform an update if possible.

This is the expected behavior. Performing an *update* on a bundle does not change its location. See http://dev.day.com/content/ddc/blog/2010/01/bundleidentification.html

I was refererring to javax.jcr.Session. See http://www.day.com/maven/jsr170/javadocs/jcr-2.0/javax/jcr/Session.html#getUserID().But mostly you shouldn't be handling authorization in this. JCR has built-in authorization, so you do not need to implement the logic to handle "if the user has permissions...

Sutty-Does ResourceResolver.getUserID() / Session.getUserID() do what you are looking for? Your question doesn't really make sense to me as the outcome of creating a custom AuthenticationHandler is that your AuthenticationHandler decides what user is logged in. Your question makes it sound like you ...