Re: [jira] Created: (SLING-1804) instead of packaging bundles in the standalone JAR or WAR, provision them at runtime from a Maven repository
We often use sling with Servicemix 4, so we had to integrate it with Karaf. Since then, we exclusively use Karaf, even if we are not in need of Servicemix. The features Karaf gives us, such as the SSH console, features, etc. makes it very attractive for us. Karaf is now a top-level apache project that has matured immensely in the last year. -- Mike On Sep 24, 2010, at 4:20 PM, Justin Edelson wrote: > It has been almost a year since I seriously evaluated Karaf, so I > can't really speak to it. I will say that I am very happy with how > Launchpad handles bundle upgrades and that this is an important piece > of functionality for me. > > The change I have in mind is purely a matter of how the bundles are > retrieved (i.e. from the local Maven repository instead of extracted > from the JAR/WAR). How those bundles are processed will be exactly > what we already have in Launchpad. > > Justin > > On Fri, Sep 24, 2010 at 5:31 PM, Mike Moulton wrote: >> If your going to go this far, would it be worth looking at using Karaf as >> the basis of the launchpad? Given this functionality is already provided out >> of the box, with many other benefits. >> >> This is how we deploy all our sling instances, in a Karaf instance, either >> standalone or in a WAR. It is worth noting though, due to the nature of URL >> protocol registration, you can only register the mvn protocol provided by >> PAX in a JVM once. This has the side effect of only being able to deploy 1 >> instance of an embedded Karaf WAR into another container once. >> >> -- Mike >> >> >> On Sep 24, 2010, at 2:02 PM, Justin Edelson wrote: >> >>> Worth looking at, but AFAIK, the Pax URL handlers doesn't fully interop >>> with Maven's settings. Reading >>> http://wiki.ops4j.org/display/paxurl/Mvn+Protocol, it looks like mirrors >>> and proxies aren't supported. >>> >>> Justin >>> >>> On 9/24/10 3:25 PM, Felix Meschberger wrote: Hi, Could we leverage stuff from PAX/OPS4J here ? Namely the stuff they did around URL Handlers ? An option besides Maven could also be OBR, of course. Regards Felix Am 24.09.2010 20:48, schrieb Justin Edelson (JIRA): > instead of packaging bundles in the standalone JAR or WAR, provision them > at runtime from a Maven repository > > > Key: SLING-1804 > URL: https://issues.apache.org/jira/browse/SLING-1804 > Project: Sling > Issue Type: New Feature > Components: Launchpad >Reporter: Justin Edelson > > > something I've been thinking about for a few months, but never wrote > down... > > It would be nice to have the option to create a Launchpad JAR or WAR > which was only composed of Launchpad and the bundle list. At runtime, > Launchpad could download the artifacts referenced in the bundle list from > a Maven repository. > > With the work being done to extract the repository integration code from > the rest of Maven (i.e. to create Aether), this should be relatively > simple. > >>> >> >>
Re: [jira] Created: (SLING-1804) instead of packaging bundles in the standalone JAR or WAR, provision them at runtime from a Maven repository
It has been almost a year since I seriously evaluated Karaf, so I can't really speak to it. I will say that I am very happy with how Launchpad handles bundle upgrades and that this is an important piece of functionality for me. The change I have in mind is purely a matter of how the bundles are retrieved (i.e. from the local Maven repository instead of extracted from the JAR/WAR). How those bundles are processed will be exactly what we already have in Launchpad. Justin On Fri, Sep 24, 2010 at 5:31 PM, Mike Moulton wrote: > If your going to go this far, would it be worth looking at using Karaf as the > basis of the launchpad? Given this functionality is already provided out of > the box, with many other benefits. > > This is how we deploy all our sling instances, in a Karaf instance, either > standalone or in a WAR. It is worth noting though, due to the nature of URL > protocol registration, you can only register the mvn protocol provided by PAX > in a JVM once. This has the side effect of only being able to deploy 1 > instance of an embedded Karaf WAR into another container once. > > -- Mike > > > On Sep 24, 2010, at 2:02 PM, Justin Edelson wrote: > >> Worth looking at, but AFAIK, the Pax URL handlers doesn't fully interop >> with Maven's settings. Reading >> http://wiki.ops4j.org/display/paxurl/Mvn+Protocol, it looks like mirrors >> and proxies aren't supported. >> >> Justin >> >> On 9/24/10 3:25 PM, Felix Meschberger wrote: >>> Hi, >>> >>> Could we leverage stuff from PAX/OPS4J here ? Namely the stuff they did >>> around URL Handlers ? An option besides Maven could also be OBR, of course. >>> >>> Regards >>> Felix >>> >>> Am 24.09.2010 20:48, schrieb Justin Edelson (JIRA): instead of packaging bundles in the standalone JAR or WAR, provision them at runtime from a Maven repository Key: SLING-1804 URL: https://issues.apache.org/jira/browse/SLING-1804 Project: Sling Issue Type: New Feature Components: Launchpad Reporter: Justin Edelson something I've been thinking about for a few months, but never wrote down... It would be nice to have the option to create a Launchpad JAR or WAR which was only composed of Launchpad and the bundle list. At runtime, Launchpad could download the artifacts referenced in the bundle list from a Maven repository. With the work being done to extract the repository integration code from the rest of Maven (i.e. to create Aether), this should be relatively simple. >> > >
Re: [jira] Created: (SLING-1804) instead of packaging bundles in the standalone JAR or WAR, provision them at runtime from a Maven repository
If your going to go this far, would it be worth looking at using Karaf as the basis of the launchpad? Given this functionality is already provided out of the box, with many other benefits. This is how we deploy all our sling instances, in a Karaf instance, either standalone or in a WAR. It is worth noting though, due to the nature of URL protocol registration, you can only register the mvn protocol provided by PAX in a JVM once. This has the side effect of only being able to deploy 1 instance of an embedded Karaf WAR into another container once. -- Mike On Sep 24, 2010, at 2:02 PM, Justin Edelson wrote: > Worth looking at, but AFAIK, the Pax URL handlers doesn't fully interop > with Maven's settings. Reading > http://wiki.ops4j.org/display/paxurl/Mvn+Protocol, it looks like mirrors > and proxies aren't supported. > > Justin > > On 9/24/10 3:25 PM, Felix Meschberger wrote: >> Hi, >> >> Could we leverage stuff from PAX/OPS4J here ? Namely the stuff they did >> around URL Handlers ? An option besides Maven could also be OBR, of course. >> >> Regards >> Felix >> >> Am 24.09.2010 20:48, schrieb Justin Edelson (JIRA): >>> instead of packaging bundles in the standalone JAR or WAR, provision them >>> at runtime from a Maven repository >>> >>> >>> Key: SLING-1804 >>> URL: https://issues.apache.org/jira/browse/SLING-1804 >>> Project: Sling >>> Issue Type: New Feature >>> Components: Launchpad >>>Reporter: Justin Edelson >>> >>> >>> something I've been thinking about for a few months, but never wrote down... >>> >>> It would be nice to have the option to create a Launchpad JAR or WAR which >>> was only composed of Launchpad and the bundle list. At runtime, Launchpad >>> could download the artifacts referenced in the bundle list from a Maven >>> repository. >>> >>> With the work being done to extract the repository integration code from >>> the rest of Maven (i.e. to create Aether), this should be relatively simple. >>> >
Re: [jira] Created: (SLING-1804) instead of packaging bundles in the standalone JAR or WAR, provision them at runtime from a Maven repository
Worth looking at, but AFAIK, the Pax URL handlers doesn't fully interop with Maven's settings. Reading http://wiki.ops4j.org/display/paxurl/Mvn+Protocol, it looks like mirrors and proxies aren't supported. Justin On 9/24/10 3:25 PM, Felix Meschberger wrote: > Hi, > > Could we leverage stuff from PAX/OPS4J here ? Namely the stuff they did > around URL Handlers ? An option besides Maven could also be OBR, of course. > > Regards > Felix > > Am 24.09.2010 20:48, schrieb Justin Edelson (JIRA): >> instead of packaging bundles in the standalone JAR or WAR, provision them at >> runtime from a Maven repository >> >> >> Key: SLING-1804 >> URL: https://issues.apache.org/jira/browse/SLING-1804 >> Project: Sling >> Issue Type: New Feature >> Components: Launchpad >> Reporter: Justin Edelson >> >> >> something I've been thinking about for a few months, but never wrote down... >> >> It would be nice to have the option to create a Launchpad JAR or WAR which >> was only composed of Launchpad and the bundle list. At runtime, Launchpad >> could download the artifacts referenced in the bundle list from a Maven >> repository. >> >> With the work being done to extract the repository integration code from the >> rest of Maven (i.e. to create Aether), this should be relatively simple. >>
[jira] Resolved: (SLING-1400) OPTIONS request on / returns login form if "Allow Anonymous Access" set to false
[ https://issues.apache.org/jira/browse/SLING-1400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger resolved SLING-1400. -- Assignee: Felix Meschberger Fix Version/s: Auth Core 1.0.4 Resolution: Fixed Added integration tests from http://codereview.appspot.com/2252043 in Rev. 1001058. > OPTIONS request on / returns login form if "Allow Anonymous Access" set to > false > > > Key: SLING-1400 > URL: https://issues.apache.org/jira/browse/SLING-1400 > Project: Sling > Issue Type: Bug > Components: Authentication >Reporter: Bertrand Delacretaz >Assignee: Felix Meschberger >Priority: Minor > Fix For: Auth Core 1.0.4 > > > If "Allow Anonymous Access" is true (that's the default default) in > theorg.apache.sling.engine.impl.auth.SlingAuthenticator config, curl -X > OPTIONS http://localhost:/ correctly returns a 401 status. > If the setting is false, the same request returns 200 and the login form. > Not sure if that's really a problem, but I thought I'd report it as it caused > the WebDAV mount on / to become unusable with samples that recommend setting > that parameter to false. I'll change the samples to use > sling:authRequestLogin=true instead. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-1428) Failed Form Auth via AJAX Does not Return Status 403
[ https://issues.apache.org/jira/browse/SLING-1428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated SLING-1428: - Fix Version/s: Form Based Authentication 1.0.2 > Failed Form Auth via AJAX Does not Return Status 403 > > > Key: SLING-1428 > URL: https://issues.apache.org/jira/browse/SLING-1428 > Project: Sling > Issue Type: Bug > Components: Authentication >Affects Versions: Form Based Authentication 1.0.0 >Reporter: Jason Rose >Assignee: Felix Meschberger > Fix For: Form Based Authentication 1.0.2, Auth Core 1.0.4 > > > Posting: > j_username= > j_password= > j_validate=true > Returns status 200 and the HTML for the auth page. Looking at the > sessionInfo.json shows me that I'm authenticated as anonymous, as intended, > but the docs say I should have received a status code 403. > Authenticating as a known user does indeed work as intended. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-1745) Do not redirect AJAX requests with expired cookie to login form
[ https://issues.apache.org/jira/browse/SLING-1745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger resolved SLING-1745. -- Fix Version/s: Auth Core 1.0.4 (was: Form Based Authentication 1.0.2) Resolution: Fixed Added integration tests from http://codereview.appspot.com/2252043 in Rev. 1001058. > Do not redirect AJAX requests with expired cookie to login form > --- > > Key: SLING-1745 > URL: https://issues.apache.org/jira/browse/SLING-1745 > Project: Sling > Issue Type: Improvement > Components: Authentication >Affects Versions: Form Based Authentication 1.0.0 >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: Auth Core 1.0.4 > > > Currently there are two reactions possible if a request is sent with an > expired cookie: Either the cookie is just cleared (but ignored for > authentication purposes) [the default] or the client is redirected to the > login form. > Both reactions are not necessairily usefull if an AJAX (or an application) is > sending the request with the expired cookie. In this case a proper response > would probably be more appropriate. > See also the discussion at http://markmail.org/message/jwsvk6swnxvvfsyz -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-1428) Failed Form Auth via AJAX Does not Return Status 403
[ https://issues.apache.org/jira/browse/SLING-1428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger resolved SLING-1428. -- Fix Version/s: (was: Form Based Authentication 1.0.2) Resolution: Fixed Added integration tests from http://codereview.appspot.com/2252043 in Rev. 1001058. > Failed Form Auth via AJAX Does not Return Status 403 > > > Key: SLING-1428 > URL: https://issues.apache.org/jira/browse/SLING-1428 > Project: Sling > Issue Type: Bug > Components: Authentication >Affects Versions: Form Based Authentication 1.0.0 >Reporter: Jason Rose >Assignee: Felix Meschberger > Fix For: Auth Core 1.0.4 > > > Posting: > j_username= > j_password= > j_validate=true > Returns status 200 and the HTML for the auth page. Looking at the > sessionInfo.json shows me that I'm authenticated as anonymous, as intended, > but the docs say I should have received a status code 403. > Authenticating as a known user does indeed work as intended. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (SLING-1400) OPTIONS request on / returns login form if "Allow Anonymous Access" set to false
[ https://issues.apache.org/jira/browse/SLING-1400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12914628#action_12914628 ] Felix Meschberger edited comment on SLING-1400 at 9/24/10 4:10 PM: --- Implemented an alternate solution derived from http://codereview.appspot.com/2252043 in Rev. 1001056 The new method isBrowserRequest called from doLogin checks for the presence of the Accept header. If the header is present a browser request is assumed. The reason for only checking the browser is, that some AJAX requests in fact just send */* for the value of the header, which of course would fail the check for text/html. If the request is assume to not be a browser request and the HTTP AuthenticationHandler is enabled at least for preemptive operation (or fully enabled) a 401/UNAUTHORIZED status is returned. If the HTTP Authentication Handler is disabled, 403/FORBIDDEN response is returned assuming simple authentication is not possible for this non-browser client. If 403 is returned the X-Reason header is set to a reason for returning 403 instead of 401. was (Author: fmeschbe): Implemented an alternate solution derived from http://codereview.appspot.com/2252043 in Rev. 1001056 The new method isBrowserRequest called from doLogin checks for the presence of the Accept header. If the header is present a browser request is assumed. The reason for only checking the browser is, that some AJAX requests in fact just send */* for the value of the header, which of course would fail the check for text/html. If the request is assume to not be a browser request and the HTTP AuthenticationHandler is enabled at least for preemptive operation (or fully enabled) a 401/UNAUTHORIZED status is returned. If the HTTP Authentication Handler is disabled, 403/FORBIDDEN response is returned assuming simple authentication is not possible for this non-browser client. > OPTIONS request on / returns login form if "Allow Anonymous Access" set to > false > > > Key: SLING-1400 > URL: https://issues.apache.org/jira/browse/SLING-1400 > Project: Sling > Issue Type: Bug > Components: Authentication >Reporter: Bertrand Delacretaz >Priority: Minor > > If "Allow Anonymous Access" is true (that's the default default) in > theorg.apache.sling.engine.impl.auth.SlingAuthenticator config, curl -X > OPTIONS http://localhost:/ correctly returns a 401 status. > If the setting is false, the same request returns 200 and the login form. > Not sure if that's really a problem, but I thought I'd report it as it caused > the WebDAV mount on / to become unusable with samples that recommend setting > that parameter to false. I'll change the samples to use > sling:authRequestLogin=true instead. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1745) Do not redirect AJAX requests with expired cookie to login form
[ https://issues.apache.org/jira/browse/SLING-1745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12914629#action_12914629 ] Felix Meschberger commented on SLING-1745: -- Implemented the isAjaxRequest method which returns true if the request can be considered an Ajax Request in Rev. 1001056. If the request is an Ajax request (which is also expected to be a browser request), the login() method is not called and 403/FORBIDDEN is returned instead with the X-Reason header set to an user-readable string indicating the reason for login failure. > Do not redirect AJAX requests with expired cookie to login form > --- > > Key: SLING-1745 > URL: https://issues.apache.org/jira/browse/SLING-1745 > Project: Sling > Issue Type: Improvement > Components: Authentication >Affects Versions: Form Based Authentication 1.0.0 >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: Form Based Authentication 1.0.2 > > > Currently there are two reactions possible if a request is sent with an > expired cookie: Either the cookie is just cleared (but ignored for > authentication purposes) [the default] or the client is redirected to the > login form. > Both reactions are not necessairily usefull if an AJAX (or an application) is > sending the request with the expired cookie. In this case a proper response > would probably be more appropriate. > See also the discussion at http://markmail.org/message/jwsvk6swnxvvfsyz -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1400) OPTIONS request on / returns login form if "Allow Anonymous Access" set to false
[ https://issues.apache.org/jira/browse/SLING-1400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12914628#action_12914628 ] Felix Meschberger commented on SLING-1400: -- Implemented an alternate solution derived from http://codereview.appspot.com/2252043 in Rev. 1001056 The new method isBrowserRequest called from doLogin checks for the presence of the Accept header. If the header is present a browser request is assumed. The reason for only checking the browser is, that some AJAX requests in fact just send */* for the value of the header, which of course would fail the check for text/html. If the request is assume to not be a browser request and the HTTP AuthenticationHandler is enabled at least for preemptive operation (or fully enabled) a 401/UNAUTHORIZED status is returned. If the HTTP Authentication Handler is disabled, 403/FORBIDDEN response is returned assuming simple authentication is not possible for this non-browser client. > OPTIONS request on / returns login form if "Allow Anonymous Access" set to > false > > > Key: SLING-1400 > URL: https://issues.apache.org/jira/browse/SLING-1400 > Project: Sling > Issue Type: Bug > Components: Authentication >Reporter: Bertrand Delacretaz >Priority: Minor > > If "Allow Anonymous Access" is true (that's the default default) in > theorg.apache.sling.engine.impl.auth.SlingAuthenticator config, curl -X > OPTIONS http://localhost:/ correctly returns a 401 status. > If the setting is false, the same request returns 200 and the login form. > Not sure if that's really a problem, but I thought I'd report it as it caused > the WebDAV mount on / to become unusable with samples that recommend setting > that parameter to false. I'll change the samples to use > sling:authRequestLogin=true instead. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1428) Failed Form Auth via AJAX Does not Return Status 403
[ https://issues.apache.org/jira/browse/SLING-1428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12914622#action_12914622 ] Felix Meschberger commented on SLING-1428: -- Committed a generalized version of the functionality in Rev. 1001053. Now, the j_validate request parameter is supported by the SlingAuthenticator as follows: * If authentication succeeds, the request is terminated immediately with 200/OK (after calling the optional feedback handler) * If authentication fails, the request is terminated immediately with 403/FORBIDDEN (after calling the optional feedback handler) * If the extractCredentials method returns AUTH_FAIL and j_validate is set, the request is also terminated with 403/FORBIDDEN (without calling any feedback handler) > Failed Form Auth via AJAX Does not Return Status 403 > > > Key: SLING-1428 > URL: https://issues.apache.org/jira/browse/SLING-1428 > Project: Sling > Issue Type: Bug > Components: Authentication >Affects Versions: Form Based Authentication 1.0.0 >Reporter: Jason Rose >Assignee: Felix Meschberger > Fix For: Form Based Authentication 1.0.2, Auth Core 1.0.4 > > > Posting: > j_username= > j_password= > j_validate=true > Returns status 200 and the HTML for the auth page. Looking at the > sessionInfo.json shows me that I'm authenticated as anonymous, as intended, > but the docs say I should have received a status code 403. > Authenticating as a known user does indeed work as intended. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-1763) static resources on selector login page can't be loaded if anon access disabled
[ https://issues.apache.org/jira/browse/SLING-1763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger resolved SLING-1763. -- Fix Version/s: Auth Selector 1.0.2 Resolution: Fixed Declare the CSS, logo and signup page referred to by the default login page to not require authentication in Rev. 1001039. > static resources on selector login page can't be loaded if anon access > disabled > --- > > Key: SLING-1763 > URL: https://issues.apache.org/jira/browse/SLING-1763 > Project: Sling > Issue Type: Bug > Components: Authentication >Affects Versions: Auth Selector 1.0.0 >Reporter: Justin Edelson >Assignee: Felix Meschberger > Fix For: Auth Selector 1.0.2 > > Attachments: screenshot0.png > > > If anonymous access is disabled in the SlingAuthenticator, the selector login > page doesn't display correctly because the static resources of sling.css and > sling-logo.png can't be loaded -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (SLING-1763) static resources on selector login page can't be loaded if anon access disabled
[ https://issues.apache.org/jira/browse/SLING-1763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger reassigned SLING-1763: Assignee: Felix Meschberger > static resources on selector login page can't be loaded if anon access > disabled > --- > > Key: SLING-1763 > URL: https://issues.apache.org/jira/browse/SLING-1763 > Project: Sling > Issue Type: Bug > Components: Authentication >Affects Versions: Auth Selector 1.0.0 >Reporter: Justin Edelson >Assignee: Felix Meschberger > Fix For: Auth Selector 1.0.2 > > Attachments: screenshot0.png > > > If anonymous access is disabled in the SlingAuthenticator, the selector login > page doesn't display correctly because the static resources of sling.css and > sling-logo.png can't be loaded -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Created: (SLING-1804) instead of packaging bundles in the standalone JAR or WAR, provision them at runtime from a Maven repository
Hi, Could we leverage stuff from PAX/OPS4J here ? Namely the stuff they did around URL Handlers ? An option besides Maven could also be OBR, of course. Regards Felix Am 24.09.2010 20:48, schrieb Justin Edelson (JIRA): > instead of packaging bundles in the standalone JAR or WAR, provision them at > runtime from a Maven repository > > > Key: SLING-1804 > URL: https://issues.apache.org/jira/browse/SLING-1804 > Project: Sling > Issue Type: New Feature > Components: Launchpad > Reporter: Justin Edelson > > > something I've been thinking about for a few months, but never wrote down... > > It would be nice to have the option to create a Launchpad JAR or WAR which > was only composed of Launchpad and the bundle list. At runtime, Launchpad > could download the artifacts referenced in the bundle list from a Maven > repository. > > With the work being done to extract the repository integration code from the > rest of Maven (i.e. to create Aether), this should be relatively simple. >
[jira] Created: (SLING-1804) instead of packaging bundles in the standalone JAR or WAR, provision them at runtime from a Maven repository
instead of packaging bundles in the standalone JAR or WAR, provision them at runtime from a Maven repository Key: SLING-1804 URL: https://issues.apache.org/jira/browse/SLING-1804 Project: Sling Issue Type: New Feature Components: Launchpad Reporter: Justin Edelson something I've been thinking about for a few months, but never wrote down... It would be nice to have the option to create a Launchpad JAR or WAR which was only composed of Launchpad and the bundle list. At runtime, Launchpad could download the artifacts referenced in the bundle list from a Maven repository. With the work being done to extract the repository integration code from the rest of Maven (i.e. to create Aether), this should be relatively simple. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-1803) add coverage reporting of integration tests
add coverage reporting of integration tests --- Key: SLING-1803 URL: https://issues.apache.org/jira/browse/SLING-1803 Project: Sling Issue Type: New Feature Components: Launchpad Reporter: Justin Edelson Assignee: Justin Edelson I've tried both emma and clover. Looks like emma is the right choice as it is a little more flexible in terms of breaking apart the instrumentation from the test execution. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1428) Failed Form Auth via AJAX Does not Return Status 403
[ https://issues.apache.org/jira/browse/SLING-1428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12914451#action_12914451 ] Justin Edelson commented on SLING-1428: --- > Reconsidering this, I think the "j_validate" functionality would be a nice > functionality to be added to the Sling Authenticator for use by all > authentication handlers. +1 > Failed Form Auth via AJAX Does not Return Status 403 > > > Key: SLING-1428 > URL: https://issues.apache.org/jira/browse/SLING-1428 > Project: Sling > Issue Type: Bug > Components: Authentication >Affects Versions: Form Based Authentication 1.0.0 >Reporter: Jason Rose >Assignee: Felix Meschberger > Fix For: Form Based Authentication 1.0.2, Auth Core 1.0.4 > > > Posting: > j_username= > j_password= > j_validate=true > Returns status 200 and the HTML for the auth page. Looking at the > sessionInfo.json shows me that I'm authenticated as anonymous, as intended, > but the docs say I should have received a status code 403. > Authenticating as a known user does indeed work as intended. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-1802) ContentLoader does not update the content from a bundle when the bundle is updated.
[ https://issues.apache.org/jira/browse/SLING-1802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ian Boston resolved SLING-1802. --- Fix Version/s: JCR ContentLoader 2.1.2 Resolution: Fixed Fixed Bundles will now update content when the bundle is rebuilt. This only applies to file content and not to content loaded by other handlers (json, xml) > ContentLoader does not update the content from a bundle when the bundle is > updated. > --- > > Key: SLING-1802 > URL: https://issues.apache.org/jira/browse/SLING-1802 > Project: Sling > Issue Type: Bug > Components: JCR >Affects Versions: JCR ContentLoader 2.1.0 >Reporter: Ian Boston >Assignee: Ian Boston > Fix For: JCR ContentLoader 2.1.2 > > > If you create an updated bundle containing content to be installed by the > content loader, that updated content does not get installed. > You can use overwrite:=true, however if you do that the entire tree is > overwritten including any content from other bundles. > A workarround is to only allow one bundle to update any one folder, although > this may not be suitable for certain configurations. > This was discussed at http://markmail.org/thread/t4efmodaxofofjwr > One possible solution is to use the lastModified date of the bundle to > determine if new content should be uploaded. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (SLING-1802) ContentLoader does not update the content from a bundle when the bundle is updated.
[ https://issues.apache.org/jira/browse/SLING-1802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ian Boston reassigned SLING-1802: - Assignee: Ian Boston > ContentLoader does not update the content from a bundle when the bundle is > updated. > --- > > Key: SLING-1802 > URL: https://issues.apache.org/jira/browse/SLING-1802 > Project: Sling > Issue Type: Bug > Components: JCR >Affects Versions: JCR ContentLoader 2.1.0 >Reporter: Ian Boston >Assignee: Ian Boston > > If you create an updated bundle containing content to be installed by the > content loader, that updated content does not get installed. > You can use overwrite:=true, however if you do that the entire tree is > overwritten including any content from other bundles. > A workarround is to only allow one bundle to update any one folder, although > this may not be suitable for certain configurations. > This was discussed at http://markmail.org/thread/t4efmodaxofofjwr > One possible solution is to use the lastModified date of the bundle to > determine if new content should be uploaded. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1802) ContentLoader does not update the content from a bundle when the bundle is updated.
[
https://issues.apache.org/jira/browse/SLING-1802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12914433#action_12914433
]
Ian Boston commented on SLING-1802:
---
Using last modified of the bundle and comparing it to the last modified of the
resource in jcr appears to be a good way of determining if an update is
required. Determining the last update of a bundle is less easy as
bundle.getLastModified() gives the time when the bundle was ast modified in the
OSGi container, not last built. The BND Tool adds a Manifest Bnd-LastModified
header which is the build time of the bundle but this isnt present in
absolutely every bundle.
So
Math.min(Math.min(Long.parseLong((String)bundle.getProperties().get("Bnd-LastModified")),bundle.getLastModified()),entryUrlConnection.getLastModified());
should give a reasonable approximation for each item and be good for future
changes to Felix, should they happen.
> ContentLoader does not update the content from a bundle when the bundle is
> updated.
> ---
>
> Key: SLING-1802
> URL: https://issues.apache.org/jira/browse/SLING-1802
> Project: Sling
> Issue Type: Bug
> Components: JCR
>Affects Versions: JCR ContentLoader 2.1.0
>Reporter: Ian Boston
>
> If you create an updated bundle containing content to be installed by the
> content loader, that updated content does not get installed.
> You can use overwrite:=true, however if you do that the entire tree is
> overwritten including any content from other bundles.
> A workarround is to only allow one bundle to update any one folder, although
> this may not be suitable for certain configurations.
> This was discussed at http://markmail.org/thread/t4efmodaxofofjwr
> One possible solution is to use the lastModified date of the bundle to
> determine if new content should be uploaded.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Content Loader and Overwrite logic
On 24 Sep 2010, at 12:12, Felix Meschberger wrote: >> >> >> Use that, and fall back to Bundle.getLastModified() is missing? > > The correct thing is to use URLConnection.getLastModified(), which > unfortunately gives you the Bundle.getLastModified() in Felix but may at > the same time give you the correct answer ... > > How about this: Get both (if available) and assume the older (smaller > number) ? yes that appears to work ok, will commit in a moment. Ian
Re: Content Loader and Overwrite logic
Hi, Am 24.09.2010 13:06, schrieb Ian Boston: > > On 24 Sep 2010, at 11:57, Felix Meschberger wrote: > >> Hi, >> >> Am 24.09.2010 12:39, schrieb Ian Boston: >>> >>> On 24 Sep 2010, at 11:21, Carsten Ziegeler wrote: >>> Ian Boston wrote > > On 24 Sep 2010, at 11:06, Carsten Ziegeler wrote: > >> So if you >> want to update this content, you should update the corresponding bundle. > > Thats the bit thats not really working (unless I say overwrite:=true) Yes, right - that's why you should have overwrite:=true :) > as Felix said, perhaps the default should be the content gets updated if > the bundle gets updated, although thats going to break for anyone who was > expecting edits post bundle load to remain. Yepp, right, I think this would make more sense for the a default. >>> >>> There is one problem with using the lastModified timestamp per content >>> file, it comes from the URL, which comes from the Jar, and since that comes >>> from the temporary file where the jar is being installed from it may not >>> represent the last modified time of the bundle. In the case of a bundle >>> that has been posted over http, that is certainly the case. Not so certain >>> about a bundle that was installed via bootstrap. >> >> That's not entirely true, actually. >> >> IIRC the timestamp in fact comes from the URL but it comes either from >> the actual file inside the bundle JAR or it comes from the providing >> bundle's last modification time (Bundle.getLastModified()). > > Ahh, > Ok, although that is the time when the bundle was installed or updated, not > when it was last bundled. Yes. > Bnd-LastModfied looks like it gets updated when bundled (provided the Bnd > Tool is used) Yes, well for most bundles, this is probably usable nowadays ;-) > > Use that, and fall back to Bundle.getLastModified() is missing? The correct thing is to use URLConnection.getLastModified(), which unfortunately gives you the Bundle.getLastModified() in Felix but may at the same time give you the correct answer ... How about this: Get both (if available) and assume the older (smaller number) ? Regards Felix > Ian > > > >> >> Regards >> Felix >> >>> >>> Is this going to be Ok ? >>> Ian >>> >>> >>> Carsten -- Carsten Ziegeler cziege...@apache.org >>> >>> > >
Re: Content Loader and Overwrite logic
On 24 Sep 2010, at 11:57, Felix Meschberger wrote: > Hi, > > Am 24.09.2010 12:39, schrieb Ian Boston: >> >> On 24 Sep 2010, at 11:21, Carsten Ziegeler wrote: >> >>> Ian Boston wrote On 24 Sep 2010, at 11:06, Carsten Ziegeler wrote: > So if you > want to update this content, you should update the corresponding bundle. Thats the bit thats not really working (unless I say overwrite:=true) >>> Yes, right - that's why you should have overwrite:=true :) >>> >>> as Felix said, perhaps the default should be the content gets updated if the bundle gets updated, although thats going to break for anyone who was expecting edits post bundle load to remain. >>> >>> Yepp, right, I think this would make more sense for the a default. >> >> There is one problem with using the lastModified timestamp per content file, >> it comes from the URL, which comes from the Jar, and since that comes from >> the temporary file where the jar is being installed from it may not >> represent the last modified time of the bundle. In the case of a bundle that >> has been posted over http, that is certainly the case. Not so certain about >> a bundle that was installed via bootstrap. > > That's not entirely true, actually. > > IIRC the timestamp in fact comes from the URL but it comes either from > the actual file inside the bundle JAR or it comes from the providing > bundle's last modification time (Bundle.getLastModified()). Ahh, Ok, although that is the time when the bundle was installed or updated, not when it was last bundled. Bnd-LastModfied looks like it gets updated when bundled (provided the Bnd Tool is used) Use that, and fall back to Bundle.getLastModified() is missing? Ian > > Regards > Felix > >> >> Is this going to be Ok ? >> Ian >> >> >> >>> >>> Carsten >>> -- >>> Carsten Ziegeler >>> cziege...@apache.org >> >>
[jira] Created: (SLING-1802) ContentLoader does not update the content from a bundle when the bundle is updated.
ContentLoader does not update the content from a bundle when the bundle is updated. --- Key: SLING-1802 URL: https://issues.apache.org/jira/browse/SLING-1802 Project: Sling Issue Type: Bug Components: JCR Affects Versions: JCR ContentLoader 2.1.0 Reporter: Ian Boston If you create an updated bundle containing content to be installed by the content loader, that updated content does not get installed. You can use overwrite:=true, however if you do that the entire tree is overwritten including any content from other bundles. A workarround is to only allow one bundle to update any one folder, although this may not be suitable for certain configurations. This was discussed at http://markmail.org/thread/t4efmodaxofofjwr One possible solution is to use the lastModified date of the bundle to determine if new content should be uploaded. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Content Loader and Overwrite logic
Hi, Am 24.09.2010 12:39, schrieb Ian Boston: > > On 24 Sep 2010, at 11:21, Carsten Ziegeler wrote: > >> Ian Boston wrote >>> >>> On 24 Sep 2010, at 11:06, Carsten Ziegeler wrote: >>> So if you want to update this content, you should update the corresponding bundle. >>> >>> Thats the bit thats not really working (unless I say overwrite:=true) >> Yes, right - that's why you should have overwrite:=true :) >> >> >>> as Felix said, perhaps the default should be the content gets updated if >>> the bundle gets updated, although thats going to break for anyone who was >>> expecting edits post bundle load to remain. >> >> Yepp, right, I think this would make more sense for the a default. > > There is one problem with using the lastModified timestamp per content file, > it comes from the URL, which comes from the Jar, and since that comes from > the temporary file where the jar is being installed from it may not represent > the last modified time of the bundle. In the case of a bundle that has been > posted over http, that is certainly the case. Not so certain about a bundle > that was installed via bootstrap. That's not entirely true, actually. IIRC the timestamp in fact comes from the URL but it comes either from the actual file inside the bundle JAR or it comes from the providing bundle's last modification time (Bundle.getLastModified()). Regards Felix > > Is this going to be Ok ? > Ian > > > >> >> Carsten >> -- >> Carsten Ziegeler >> cziege...@apache.org > >
Re: Content Loader and Overwrite logic
On 24 Sep 2010, at 11:21, Carsten Ziegeler wrote: > Ian Boston wrote >> >> On 24 Sep 2010, at 11:06, Carsten Ziegeler wrote: >> >>> So if you >>> want to update this content, you should update the corresponding bundle. >> >> Thats the bit thats not really working (unless I say overwrite:=true) > Yes, right - that's why you should have overwrite:=true :) > > >> as Felix said, perhaps the default should be the content gets updated if the >> bundle gets updated, although thats going to break for anyone who was >> expecting edits post bundle load to remain. > > Yepp, right, I think this would make more sense for the a default. There is one problem with using the lastModified timestamp per content file, it comes from the URL, which comes from the Jar, and since that comes from the temporary file where the jar is being installed from it may not represent the last modified time of the bundle. In the case of a bundle that has been posted over http, that is certainly the case. Not so certain about a bundle that was installed via bootstrap. Is this going to be Ok ? Ian > > Carsten > -- > Carsten Ziegeler > cziege...@apache.org
Re: Content Loader and Overwrite logic
On 24 Sep 2010, at 11:21, Carsten Ziegeler wrote: > Ian Boston wrote >> >> On 24 Sep 2010, at 11:06, Carsten Ziegeler wrote: >> >>> So if you >>> want to update this content, you should update the corresponding bundle. >> >> Thats the bit thats not really working (unless I say overwrite:=true) > Yes, right - that's why you should have overwrite:=true :) > > >> as Felix said, perhaps the default should be the content gets updated if the >> bundle gets updated, although thats going to break for anyone who was >> expecting edits post bundle load to remain. > > Yepp, right, I think this would make more sense for the a default. Ok, I will open a jira and fix, just for files. Ian > > Carsten > -- > Carsten Ziegeler > cziege...@apache.org
Re: Content Loader and Overwrite logic
Ian Boston wrote > > On 24 Sep 2010, at 11:06, Carsten Ziegeler wrote: > >> So if you >> want to update this content, you should update the corresponding bundle. > > Thats the bit thats not really working (unless I say overwrite:=true) Yes, right - that's why you should have overwrite:=true :) > as Felix said, perhaps the default should be the content gets updated if the > bundle gets updated, although thats going to break for anyone who was > expecting edits post bundle load to remain. Yepp, right, I think this would make more sense for the a default. Carsten -- Carsten Ziegeler cziege...@apache.org
Re: Content Loader and Overwrite logic
On 24 Sep 2010, at 11:06, Carsten Ziegeler wrote: > So if you > want to update this content, you should update the corresponding bundle. Thats the bit thats not really working (unless I say overwrite:=true) as Felix said, perhaps the default should be the content gets updated if the bundle gets updated, although thats going to break for anyone who was expecting edits post bundle load to remain. Ian
Re: Content Loader and Overwrite logic
Ian Boston wrote > Ok, > So you cant split content between bundles > or > Have a bundle update content. > > > I think what I really want is something update:=true which looks at the > lastModified on every file and only updates it if the bundled file is later. > The overwrite functionality probably needs to stay. > The idea behind it, is that the content and the bundle form a unit, so the content installed by this bundle "belongs" to this bundle. So if you want to update this content, you should update the corresponding bundle. At least this is the intended use case behind it. As you can add several initial content instructions with different "path" attributes, you can usualy work around most problems. However your use case is not handled by this :( Carsten -- Carsten Ziegeler cziege...@apache.org
Re: Content Loader and Overwrite logic
On 24 Sep 2010, at 10:54, Felix Meschberger wrote: > > Do we need such a flag ? Shouldn't this be default ? > > Not really sure and not having thought of all the > backwards-compatibility consequences. Well that would make sense, at the moment an updated bundle doesn't result in updated content, having it do so will change backwards behaviour, logically if each file in the bundle is newer than the file in the jcr then it should be updated. The only time when this will cause a problem is if the file in JCR was edited after the bundle loaded it. We probably only want to consider this for files and not for things that modify properties. (.json, .xml etc) wdyt? Ian
Re: Content Loader and Overwrite logic
Hi, Am 24.09.2010 11:50, schrieb Ian Boston: > > On 24 Sep 2010, at 10:47, Carsten Ziegeler wrote: > >> Ian Boston wrote >> >>> contentFolder1/contentInFolder2.txt is missing, indicating that subfolders >>> are deleted when uninstall=false even if the content of the sub folder came >>> from another bundle. >>> >>> Bug or expected behaviour ? >> I think this is expected behaviour as you have "overwrite=true" - so >> installing a bundle with contents for the same node overwrites existing >> content. In your case contentFolder1 contains the contents of the last >> bundle installed. > > Ok, > So you cant split content between bundles > or > Have a bundle update content. > > > I think what I really want is something update:=true which looks at the > lastModified on every file and only updates it if the bundled file is later. > The overwrite functionality probably needs to stay. Do we need such a flag ? Shouldn't this be default ? Not really sure and not having thought of all the backwards-compatibility consequences. Regards Felix > > WDYT? > Ian > >> >> Carsten >> -- >> Carsten Ziegeler >> cziege...@apache.org > >
Re: Content Loader and Overwrite logic
On 24 Sep 2010, at 10:47, Carsten Ziegeler wrote: > Ian Boston wrote > >> contentFolder1/contentInFolder2.txt is missing, indicating that subfolders >> are deleted when uninstall=false even if the content of the sub folder came >> from another bundle. >> >> Bug or expected behaviour ? > I think this is expected behaviour as you have "overwrite=true" - so > installing a bundle with contents for the same node overwrites existing > content. In your case contentFolder1 contains the contents of the last > bundle installed. Ok, So you cant split content between bundles or Have a bundle update content. I think what I really want is something update:=true which looks at the lastModified on every file and only updates it if the bundled file is later. The overwrite functionality probably needs to stay. WDYT? Ian > > Carsten > -- > Carsten Ziegeler > cziege...@apache.org
Re: Content Loader and Overwrite logic
Ian Boston wrote > contentFolder1/contentInFolder2.txt is missing, indicating that subfolders > are deleted when uninstall=false even if the content of the sub folder came > from another bundle. > > Bug or expected behaviour ? I think this is expected behaviour as you have "overwrite=true" - so installing a bundle with contents for the same node overwrites existing content. In your case contentFolder1 contains the contents of the last bundle installed. Carsten -- Carsten Ziegeler cziege...@apache.org
Re: Content Loader and Overwrite logic
Hi, install/update the bundles like this: install test1 install test2 update test1 Right ? In this case, due to overwrite:=true, when updating test1, the subtree /content/contentFolder1 is replaced by what is provided by test1. Thus /content/contentFolder1/contentInFolder2.txt is in fact expected to disappear. While I can explain, what's going on, I am not really sure, whether it really is the correct thing... Regards Felix Am 24.09.2010 11:15, schrieb Ian Boston: > Hi, > I have been looking at the content loader and the overwrite/uninstall logic. > > > I have 2 jars. contenttest1 and contenttest2. Each jar has > > SLING-INF/content;overwrite:=true;uninstall:=false;path:=/contenttest > > content test 1 has > test1/src/ > test1/src//main > test1/src//main/resources > test1/src//main/resources/SLING-INF > test1/src//main/resources/SLING-INF/content > test1/src//main/resources/SLING-INF/content/contentFolder1 > test1/src//main/resources/SLING-INF/content/contentFolder1/contentInFolder1.txt > test1/src//main/resources/SLING-INF/content/contentTest1.txt > > content test2 has > test2/src/ > test2/src//main > test2/src//main/resources > test2/src//main/resources/SLING-INF > test2/src//main/resources/SLING-INF/content > test2/src//main/resources/SLING-INF/content/contentFolder1 > test2/src//main/resources/SLING-INF/content/contentFolder1/contentInFolder1.txt > test2/src//main/resources/SLING-INF/content/contentFolder1/contentInFolder2.txt > test2/src//main/resources/SLING-INF/content/contentFolder2 > test2/src//main/resources/SLING-INF/content/contentFolder2/contentInFolder2.txt > test2/src//main/resources/SLING-INF/content/contentTest1.txt > test2/src//main/resources/SLING-INF/content/contentTest2.txt > > > if I load bundles > contenttest1 > contenttest2 > contenttest1 > > In that order I would expect to see > /contenttest/contentFolder1/contentInFolder1.txt > /contenttest/contentFolder1/contentInFolder2.txt > /contenttest/contentFolder2/contentInFolder2.txt > /contenttest/contentTest1.txt > /contenttest/contentTest2.txt > > with > /contenttest/contentTest1.txt > /contenttest/contentFolder1/contentInFolder1.txt > from contenttest1 > > and > > /contenttest/contentFolder1/contentInFolder2.txt > /contenttest/contentFolder2/contentInFolder2.txt > /contenttest/contentTest2.txt > from contenttest2 > > > What I get is > /contenttest/contentTest1.txt > /contenttest/contentFolder1/contentInFolder1.txt > /contenttest/contentFolder2/contentInFolder2.txt > /contenttest/contentTest2.txt > > > contentFolder1/contentInFolder2.txt is missing, indicating that subfolders > are deleted when uninstall=false even if the content of the sub folder came > from another bundle. > > Bug or expected behaviour ? > Ian
Re: Content Loader and Overwrite logic
On 24 Sep 2010, at 10:35, Ian Boston wrote:
>
> On 24 Sep 2010, at 10:15, Ian Boston wrote:
>>
>> Bug or expected behaviour ?
>
>
> The registered bundle content contains no uninstall-paths so IIUC, nothing
> should have been uninstalled and yet the folders go awal
>
> x43543-2:contenttest ieb$ curl
> http://localhost:8080/var/sling/bundle-content.tidy.3.json
>
>
> "org.sakaiproject.nakamura.contenttest1": {
>"content-loaded-by": "25cced8c-72a4-4c80-9611-1b63f071c0d5",
>"content-load-time": "Fri Sep 24 2010 10:05:59 GMT+0100",
>"jcr:mixinTypes": ["mix:lockable"],
>"content-loaded": true,
>"jcr:primaryType": "nt:unstructured"
> },
> "org.sakaiproject.nakamura.contenttest2": {
>"content-loaded-by": "25cced8c-72a4-4c80-9611-1b63f071c0d5",
>"content-load-time": "Fri Sep 24 2010 10:05:41 GMT+0100",
>"jcr:mixinTypes": ["mix:lockable"],
>"content-loaded": true,
>"jcr:primaryType": "nt:unstructured"
> }
>
> Ian
DefaultContentCreator:252
-// if node already exists but should be overwritten, delete it
-if (!this.ignoreOverwriteFlag && this.configuration.isOverwrite()
&& parentNode.hasNode(name)) {
+// if the parent node already exists and should be overwritten,
delete it but only if uninstall is set to false.
+if (!this.ignoreOverwriteFlag && this.configuration.isOverwrite()
&& !this.configuration.isUninstall() && parentNode.hasNode(name)) {
parentNode.getNode(name).remove();
}
configuration.isUninstall() does not exists at the moment.
WDYT ?
or do we need a new flag update:=true ?
Ian
>
>
>> Ian
>
[jira] Commented: (SLING-1428) Failed Form Auth via AJAX Does not Return Status 403
[ https://issues.apache.org/jira/browse/SLING-1428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12914388#action_12914388 ] Felix Meschberger commented on SLING-1428: -- Reconsidering this, I think the "j_validate" functionality would be a nice functionality to be added to the Sling Authenticator for use by all authentication handlers. So here is my proposal for handling the j_validate request parameter: * If extractCredentials returns AUTH_FAIL and j_validate is set, a 403 is returned with the X-Reason header * During getResolver: - if resolver is acquired: call feedback handler and return 200 - if resolver not acquired: call feedback handler and return 403 with X-Reason header > Failed Form Auth via AJAX Does not Return Status 403 > > > Key: SLING-1428 > URL: https://issues.apache.org/jira/browse/SLING-1428 > Project: Sling > Issue Type: Bug > Components: Authentication >Affects Versions: Form Based Authentication 1.0.0 >Reporter: Jason Rose >Assignee: Felix Meschberger > Fix For: Form Based Authentication 1.0.2, Auth Core 1.0.4 > > > Posting: > j_username= > j_password= > j_validate=true > Returns status 200 and the HTML for the auth page. Looking at the > sessionInfo.json shows me that I'm authenticated as anonymous, as intended, > but the docs say I should have received a status code 403. > Authenticating as a known user does indeed work as intended. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Content Loader and Overwrite logic
On 24 Sep 2010, at 10:15, Ian Boston wrote:
>
> Bug or expected behaviour ?
The registered bundle content contains no uninstall-paths so IIUC, nothing
should have been uninstalled and yet the folders go awal
x43543-2:contenttest ieb$ curl
http://localhost:8080/var/sling/bundle-content.tidy.3.json
"org.sakaiproject.nakamura.contenttest1": {
"content-loaded-by": "25cced8c-72a4-4c80-9611-1b63f071c0d5",
"content-load-time": "Fri Sep 24 2010 10:05:59 GMT+0100",
"jcr:mixinTypes": ["mix:lockable"],
"content-loaded": true,
"jcr:primaryType": "nt:unstructured"
},
"org.sakaiproject.nakamura.contenttest2": {
"content-loaded-by": "25cced8c-72a4-4c80-9611-1b63f071c0d5",
"content-load-time": "Fri Sep 24 2010 10:05:41 GMT+0100",
"jcr:mixinTypes": ["mix:lockable"],
"content-loaded": true,
"jcr:primaryType": "nt:unstructured"
}
Ian
> Ian
Content Loader and Overwrite logic
Hi, I have been looking at the content loader and the overwrite/uninstall logic. I have 2 jars. contenttest1 and contenttest2. Each jar has SLING-INF/content;overwrite:=true;uninstall:=false;path:=/contenttest content test 1 has test1/src/ test1/src//main test1/src//main/resources test1/src//main/resources/SLING-INF test1/src//main/resources/SLING-INF/content test1/src//main/resources/SLING-INF/content/contentFolder1 test1/src//main/resources/SLING-INF/content/contentFolder1/contentInFolder1.txt test1/src//main/resources/SLING-INF/content/contentTest1.txt content test2 has test2/src/ test2/src//main test2/src//main/resources test2/src//main/resources/SLING-INF test2/src//main/resources/SLING-INF/content test2/src//main/resources/SLING-INF/content/contentFolder1 test2/src//main/resources/SLING-INF/content/contentFolder1/contentInFolder1.txt test2/src//main/resources/SLING-INF/content/contentFolder1/contentInFolder2.txt test2/src//main/resources/SLING-INF/content/contentFolder2 test2/src//main/resources/SLING-INF/content/contentFolder2/contentInFolder2.txt test2/src//main/resources/SLING-INF/content/contentTest1.txt test2/src//main/resources/SLING-INF/content/contentTest2.txt if I load bundles contenttest1 contenttest2 contenttest1 In that order I would expect to see /contenttest/contentFolder1/contentInFolder1.txt /contenttest/contentFolder1/contentInFolder2.txt /contenttest/contentFolder2/contentInFolder2.txt /contenttest/contentTest1.txt /contenttest/contentTest2.txt with /contenttest/contentTest1.txt /contenttest/contentFolder1/contentInFolder1.txt from contenttest1 and /contenttest/contentFolder1/contentInFolder2.txt /contenttest/contentFolder2/contentInFolder2.txt /contenttest/contentTest2.txt from contenttest2 What I get is /contenttest/contentTest1.txt /contenttest/contentFolder1/contentInFolder1.txt /contenttest/contentFolder2/contentInFolder2.txt /contenttest/contentTest2.txt contentFolder1/contentInFolder2.txt is missing, indicating that subfolders are deleted when uninstall=false even if the content of the sub folder came from another bundle. Bug or expected behaviour ? Ian
[jira] Closed: (SLING-1337) sling.jcrinstall.folder.name.regexp config property should be trimmed
[ https://issues.apache.org/jira/browse/SLING-1337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed SLING-1337. --- > sling.jcrinstall.folder.name.regexp config property should be trimmed > - > > Key: SLING-1337 > URL: https://issues.apache.org/jira/browse/SLING-1337 > Project: Sling > Issue Type: Bug > Components: Installer >Reporter: Bertrand Delacretaz >Assignee: Bertrand Delacretaz > Fix For: JCR Installer 3.0.0 > > > Extra spaces in the sling.jcrinstall.folder.name.regexp configuration > property cause trouble and are hard to see -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (SLING-1690) Reduce startup time of jcr install
[ https://issues.apache.org/jira/browse/SLING-1690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed SLING-1690. --- > Reduce startup time of jcr install > -- > > Key: SLING-1690 > URL: https://issues.apache.org/jira/browse/SLING-1690 > Project: Sling > Issue Type: Improvement > Components: Installer >Affects Versions: JCR Installer 3.0.0 >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > Fix For: JCR Installer 3.0.0 > > > The jcr installer scans the repository during the activate method; this slows > down the general startup time of the whole system. > The scanning should be done delayed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (SLING-1489) Upgrade JCR Install to JCR 2
[ https://issues.apache.org/jira/browse/SLING-1489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed SLING-1489. --- > Upgrade JCR Install to JCR 2 > > > Key: SLING-1489 > URL: https://issues.apache.org/jira/browse/SLING-1489 > Project: Sling > Issue Type: Improvement > Components: Installer >Reporter: Justin Edelson >Assignee: Justin Edelson > Fix For: JCR Installer 3.0.0 > > > JCR 2 added a NODE_MOVED event. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (SLING-1241) RegisteredResourceImpl.getInputStream() fails if bundle context storage has moved
[ https://issues.apache.org/jira/browse/SLING-1241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed SLING-1241. --- > RegisteredResourceImpl.getInputStream() fails if bundle context storage has > moved > - > > Key: SLING-1241 > URL: https://issues.apache.org/jira/browse/SLING-1241 > Project: Sling > Issue Type: Bug > Components: Installer >Reporter: Bertrand Delacretaz >Priority: Minor > Fix For: JCR Installer 3.0.0 > > > The OSGi installer's RegisteredResourceImpl class persists the full path of a > data file that it gets from BundleContext.getDataFile(). > If the filesystem folder that saves the bundle context's data is moved, the > path of that data file becomes invalid. > The RegisteredResourceImpl class should just store an identifier for the data > file, and use BundleContext.getDataFile() every time it needs to access the > actual file. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (SLING-1334) Jcrinstall should log folder priority values for troubleshooting
[ https://issues.apache.org/jira/browse/SLING-1334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed SLING-1334. --- > Jcrinstall should log folder priority values for troubleshooting > > > Key: SLING-1334 > URL: https://issues.apache.org/jira/browse/SLING-1334 > Project: Sling > Issue Type: Improvement > Components: Installer >Reporter: Bertrand Delacretaz >Assignee: Bertrand Delacretaz >Priority: Minor > Fix For: JCR Installer 3.0.0 > > > JcrInstaller.findPathsUnderNode(...) uses priorities computed by the > FolderNameFilter to decide whether to watch a folder or not. > Those priorities should be logged at the DEBUG level, for troubleshooting > cases where it's unclear why a folder is not watched. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (SLING-1148) osgi.installer should keep track of the bundles/configs that it installs, and persist that info
[ https://issues.apache.org/jira/browse/SLING-1148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed SLING-1148. --- > osgi.installer should keep track of the bundles/configs that it installs, and > persist that info > --- > > Key: SLING-1148 > URL: https://issues.apache.org/jira/browse/SLING-1148 > Project: Sling > Issue Type: Bug > Components: Installer >Reporter: Bertrand Delacretaz >Assignee: Bertrand Delacretaz >Priority: Minor > Fix For: JCR Installer 3.0.0 > > > Following scenario demonstrates the problem: > 1. Copy bundle B in repository under /apps/foo/install -> installer installs > bundle B > 2. Stop osgi.installer bundle > 3. Delete bundle B from repository > 4. Restart osgi.installer bundle -> bundle B stay installed, even though it > should be uninstalled -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (SLING-1560) Improve and clean up code
[ https://issues.apache.org/jira/browse/SLING-1560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed SLING-1560. --- > Improve and clean up code > - > > Key: SLING-1560 > URL: https://issues.apache.org/jira/browse/SLING-1560 > Project: Sling > Issue Type: Improvement > Components: Installer >Affects Versions: Installer Core 3.0.0, JCR Installer 3.0.0 >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > Fix For: Installer Core 3.0.0, JCR Installer 3.0.0 > > > In order to fix some outstanding bugs and to add new features, a code review > and clean up seems to be a good idea :) > This bug will keep track of all changes to the code that don't add new > features -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (SLING-1234) jcrinstall ignores install folders if path contains dots
[ https://issues.apache.org/jira/browse/SLING-1234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed SLING-1234. --- > jcrinstall ignores install folders if path contains dots > > > Key: SLING-1234 > URL: https://issues.apache.org/jira/browse/SLING-1234 > Project: Sling > Issue Type: Bug > Components: Installer >Reporter: Bertrand Delacretaz >Priority: Minor > Fix For: JCR Installer 3.0.0 > > > Folder names like /apps/foo.bar/install are ignored, but apps/foo/install > works. > This is due to FolderNameFilter.getPriority() returning 0 in the former case. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (SLING-1239) OSGi installer shouldn't remove bundles that it didn't install
[ https://issues.apache.org/jira/browse/SLING-1239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed SLING-1239. --- > OSGi installer shouldn't remove bundles that it didn't install > -- > > Key: SLING-1239 > URL: https://issues.apache.org/jira/browse/SLING-1239 > Project: Sling > Issue Type: Bug > Components: Installer >Reporter: Bertrand Delacretaz >Assignee: Bertrand Delacretaz >Priority: Minor > Fix For: JCR Installer 3.0.0 > > > Failure scenario: > 1. Install bundle foo 2.0.4 using the OSGi console. > 2. Copy V2.0.2 of same bundle in repository -> ignored by OSGi installer, > correct > 3. Remove bundle from repository -> OSGi installer removes it > At step 3. the bundle file removal should be ignored, as it was not installed > by our OSGi installer. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (SLING-837) Integrate JCRInstall integration tests with the main integration tests
[ https://issues.apache.org/jira/browse/SLING-837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed SLING-837. -- > Integrate JCRInstall integration tests with the main integration tests > -- > > Key: SLING-837 > URL: https://issues.apache.org/jira/browse/SLING-837 > Project: Sling > Issue Type: Improvement > Components: Installer >Affects Versions: JCR Installer 3.0.0 >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: JCR Installer 3.0.0 > > > JCRInstall integration tests currently fail since the test setup has not been > adapted to the new launchpad yet. In addition, these tests may cause the > build to breack due to PermGen space problems (at least on my box). Finally > all integration tests should probably run together. > So we should do this: > * in the short-term I switch off the JCRInstall integration tests > * Migrate the JCR Integration tests to the main integration tests > (launchpad/testing) > * Configure the JCR Integration tests in a build profile, which is not > active by default -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (SLING-1078) jcrinstall - take four
[
https://issues.apache.org/jira/browse/SLING-1078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler closed SLING-1078.
---
> jcrinstall - take four
> --
>
> Key: SLING-1078
> URL: https://issues.apache.org/jira/browse/SLING-1078
> Project: Sling
> Issue Type: Improvement
> Components: Installer
>Affects Versions: JCR Installer 3.0.0
>Reporter: Bertrand Delacretaz
> Fix For: Installer Core 3.0.0, JCR Installer 3.0.0
>
>
> After splitting the jcrinstall code for SLING-904, we have reviewed it with
> Felix and Carsten, and come to the conclusion that moving more logic to the
> osgi.installer module will help.
> Here are (rough) notes from our review session, on which I'll base the next
> (and hopefully last ;-) rewrite of jcrinstall.
> = Redesign =
> OSGi controller keeps track of all supplied resources, with states:
> installed, ignored, etc. It stores RegisteredResource objects which are
> derived from InstallableData.
> At startup, jcrinstall client informs osgi.installer of all installable
> resources which are present. Installer can then detect which resources are
> gone since last startup ("rendez-vous").
> OsgiController rendezvous method: client provides list of existing
> InstallableData, URL scheme ("jcrinstall://")
> OsgiController methods: resourceUpdated(InstallableData),
> resourceDeleted(InstallableData). Or maybe register/unregister resource.
> Use a Comparator to decide on bundle priorities: higher versions over lower
> versions, take into account the Maven -SNAPSHOT convention, and let clients
> provide a priority value as part of the InstallableData. Jcrinstall uses that
> priority to give precedence to bundles found in /apps over those found in
> /libs.
> jcrinstall must call rendez-vous if a watched folder is deleted - test what
> happens if for example parent folder (/apps) is deleted.
> Those /apps and /libs path come from the ResourceResolver search path, not
> hardcoded anymore.
> InstallableData methods: getURL, getDigest, getPriority + data access.
> InstallableData becomes a RegisteredResource inside the osgi.installer - do
> not hang on to InstallableData instances, to avoid problems if jcrinstall
> module goes away.
> OSGi console displays list of RegisteredResource objects, using a Servlet as
> the plugin to minimize coupling with webconsole.
> OsgiController admin APIs: executeScheduledOperations, getRegisteredResources
> (uninstall method?)
> Use a real worker thread.
> Handle resource priorities right before creating OSGi tasks, and remove the
> ones who are overridden by priority - installer walks the list of
> RegisteredResources, and creates OSGi tasks (install/uninstall/update etc.)
> based on that list.
> RegisteredResource has two state fields: desired and actual, and by comparing
> them we create OSGi tasks.
> The list of RegisteredResource is ordered by priority, to compute overrides,
> and grouped by "OSGi entity": which bundle or config the resource maps to.
> RegisteredResource.getEntityId() returns bundle ID, config PID, etc
> Modules structure: installer/osgi, installer/jcr, installer/jcr/testing
> = Code cleanup =
> Can we remove JcrInstallService? only used for testing
> NodeConverter can be in implementation package
> RunMode in ConfigNodeConverter should be removed - use folders only for
> override, to avoid confusion.
> Merge PropertiesUtil with its single user classRepositoryObserver:
> propertiesUtil.loadProperties(serviceDataFile) not needed anymore, if OSGi
> controller keeps the list of all registered resources
> Delay RepositoryObserver startup to make non-first startups faster?
> WatchedFolder scanning might be simplified
> Subclasses: DictionaryInstallableData, FileInstallableData
> InstallResultCode should go
> JcrInstallException should go
> OsgiControllerServices is implementation
> OsgiResourceProcessor can be removed
> MissingServiceException: unused?
> EventsCounterImpl -> make Activator the listener, and increment a static long
> volatile counter
> DictionaryReader -> move to tasks package?
> MissingServiceException can go?
> OsgiControllerTaskContext is not needed, pass OsgiControllerImpl?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (SLING-1106) jcrinstall downgrades bundle installed via web console
[ https://issues.apache.org/jira/browse/SLING-1106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed SLING-1106. --- > jcrinstall downgrades bundle installed via web console > -- > > Key: SLING-1106 > URL: https://issues.apache.org/jira/browse/SLING-1106 > Project: Sling > Issue Type: Bug > Components: Installer >Reporter: Carsten Ziegeler >Assignee: Bertrand Delacretaz >Priority: Minor > Fix For: JCR Installer 3.0.0 > > Attachments: ContextBundleUpdateTest.java.patch > > > When you update a bundle which has been installed by jcr install through > another channel like the web console, the bundle gets immediately replaced by > the version from jcr install. > Example: > JCR Install install Bundle A Version 1 > Web console updates Bundle A to Verson 2 > JCR Install downgrades Bundle A to Version 1 > (issue mentioned two distinct problems, moved first one to SLING-1147) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (SLING-931) Felix webconsole not restarted after upgrading via jcrinstall
[ https://issues.apache.org/jira/browse/SLING-931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed SLING-931. -- > Felix webconsole not restarted after upgrading via jcrinstall > - > > Key: SLING-931 > URL: https://issues.apache.org/jira/browse/SLING-931 > Project: Sling > Issue Type: Bug > Components: Installer >Reporter: Bertrand Delacretaz > Fix For: JCR Installer 3.0.0 > > > After upgrading the Felix webconsole from 1.2.6 to 1.2.8 via jcrinstall, by > copying the 1.2.8 bundle in a JCR repository folder that's watched by > jcrinstall, the webconsole bundle is not restarted. > AFAICS the failure scenario is: > - jcrinstall updates the webconsole bundle and starts a package refresh > -Several bundles that import the webconsole plugin interfaces are stopped and > restarted > -That causes more bundles to stop and restart, including eventually jcrinstall > -As jcrinstall doesn't persist the list of bundles that must be restarted > after the update, the webconsole restart is lost > Steps to reproduce: > Start the sling launchpad/app > Install the Felix shell and shell text UI services > (http://felix.apache.org/site/downloads.cgi) > Install and start the Sling runmode and jcrinstall bundles. > Uninstall the webconsole bundle using the Felix shell UI. > Install and start the Felix webconsole 1.2.6 using the Felix shell UI. > Refresh packages, from the Felix webconsole or shell. > Try to install the Felix webconsole 1.2.8 via jcrinstall, by copying it in > the repository under /libs/testing/install > Result: > /system/console does not display the console anymore > After starting the console bundle from the Felix shell, things are back to > normal -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (SLING-1666) Check and update tests
[ https://issues.apache.org/jira/browse/SLING-1666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler reassigned SLING-1666: --- Assignee: Carsten Ziegeler > Check and update tests > -- > > Key: SLING-1666 > URL: https://issues.apache.org/jira/browse/SLING-1666 > Project: Sling > Issue Type: Task > Components: Installer >Affects Versions: Installer Core 3.0.0 >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > Fix For: Installer Core 3.0.0 > > > We should update/enhance/check the current tests if they check everything, > especially with the changes to the it tests we might have lost some testing -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (SLING-1787) Unify symbolic names and check package names
[ https://issues.apache.org/jira/browse/SLING-1787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed SLING-1787. --- > Unify symbolic names and check package names > > > Key: SLING-1787 > URL: https://issues.apache.org/jira/browse/SLING-1787 > Project: Sling > Issue Type: Task > Components: Installer >Affects Versions: Installer Core 3.0.0, JCR Installer 3.0.0, File > Installer 1.0.0 >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > Fix For: Installer Core 3.0.0, JCR Installer 3.0.0, File > Installer 1.0.0 > > > The used symbolic names by the various parts of the installer (osgi > installer, jcr installer, file installer) do not really have something in > common, it would rather make sense to use a unified scheme, like > org.apache.sling.installer.core (today: ...osgi.installer) > org.apache.sling.installer.provider.jcr (today: ...jcr.jcrinstall) > org.apache.sling.installer.provider.file (today: ...install.fileinstall) > In addition, the package names should match these symbolic names: > - the api goes to org.apache.sling.installer.core > - the osgi impl moves to org.apache.sling.installer.core.impl.* > - the providers use org.apache.sling.installer.provider.XYZ.impl.* -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[VOTE RESULT] Release Installer Core 3.0.0, JCR Installer 3.0.0, and File Installer 1.0.0
The vote to release Installer Core 3.0.0 JCR Installer 3.0.0 File Installer 1.0.0 passed successfully with four binding votes from Carsten Ziegeler, Felix Meschberger, Justin Edelson, and Mike Müller - and a non-binding vote from Stefan Seifert. Thanks for checking and voting! I'll publish the artifacts now. Regards Carsten -- Carsten Ziegeler cziege...@apache.org
